タグ

webに関するmohayonaoのブックマーク (47)

  • 2015年Webサーバアーキテクチャ序論 - ゆううきブログ

    2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

    2015年Webサーバアーキテクチャ序論 - ゆううきブログ
  • 【翻訳】リッチなWebアプリケーションのための7つの原則 - from scratch

    はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。

    【翻訳】リッチなWebアプリケーションのための7つの原則 - from scratch
  • CORS(Cross-Origin Resource Sharing)について整理してみた | DevelopersIO

    ブラウザからAmazon S3に直接ファイルをアップロードしたい 先日、Amazon S3にファイルをアップロードするWebアプリを作ろうとして色々調べていたところ、S3にCORSという仕様のクロスドメインアクセスの設定をすることによって、ブラウザから直接S3にアップロードをする方法にたどり着きました。ただ、この方法を使うにあたってはCORSというクロスドメインアクセスの仕様をきちんと理解しておいた方が良さそうでしたので、まずはCORSについて自分なりに整理してみました。 なお、弊社の横田がCORSとS3についての記事を以前書いていますので、S3のCORSサポートに関する概要を知りたい方はそちらをご覧下さい。 CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 CORS ブラウザでAjax通信を行う際には、同一生成元ポリシー(Same

  • Paw.jsというのを書いたのと今から始めるマルチタッチイベント処理 - damelog

    どうも、連載予定は絶対に次回を書かないでおなじみの僕です。 Paw.js is 何 マルチタッチに対応してない、いわゆるfastclickを実現するものやtapイベントを発行するライブラリ、やたら機能が多くかつ特にtouchmoveでのイベント過多で処理落ちしかねないライブラリが多かったので、現実的に使うであろう範囲でめちゃ軽なやつが欲しかったので作りました。 Paw.js あなたがもしモバイルWeb開発者で60fpsを出さなければ死ぬのであれば使えばいいと思いますし、そんな必要が無いもしくはフリックやジェスチャも取りたいと言うのであればHammer.jsとか使えばいいんじゃないでしょうか。 シンプル, 小さい, 速い touchevent, pointereventのマルチタッチ対応 tap, doubletap, pressの3つのカスタムイベントを発行 fastclick機能 です。

    Paw.jsというのを書いたのと今から始めるマルチタッチイベント処理 - damelog
  • ブラウザキャッシュによる HTTP 高速化チューニング

    かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の3つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。

  • ssig33.com - ネイティブアプリ並のウェブアプリを云々

    なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気にわない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ

  • Ligature Symbols

    HTML & CSS Please copy & paste this code to your HTML file or Stylesheet. <p>Simple use for mailto link.</p> <a href="mailto:mail@example.com" class="lsf">mail</a> <p>Use tha icon with text.</p> <a href="http://twitter.com/" class="lsf-icon" title="twitter">Twitter</a> <p>Use tha icon with unicode.</p> <a href="http://amazon.com/" class="lsf-icon amazon">Amazon</a> /* CSS */ @font-face { font-fami

    Ligature Symbols
  • お客様の中にWebシンセプログラマはいらっしゃいませんか | g200kg Music & Software

    そろそろWebベースのシンセサイザーもなんとか作れる環境が整いつつあるのですが、今のところはまだ、音源部とシーケンサー部をまとめてクローズドなアプリにするしかありません。今後を考えるとここをどうするかが課題です。 やはり複数の楽器を同期運転したいですよね!! Web楽器のurlを指定してプラグインのように使う、というのができればなあ・・・ という事でまじめに考えて見た。 HTML5のpostMessageでクロスドメインの連携ができますので、ここにMIDIメッセージをのせてホストからWebシンセに送ります。パフォーマンスの問題もあるので今のところはやりとりするのはMIDIのみとして、音の出口はとりあえずそれぞれのWebシンセが WebAudioAPIなりを叩いて勝手に出します。 postMessageで送れるのは文字列のみなのでこんな感じのフォーマットにします。 "midi,90,3c,6

    mohayonao
    mohayonao 2012/06/25
    面白い!!!! / さっそく試してみました http://script-synthesizer.herokuapp.com
  • MIDI API (Editor's Draft)

    The editors' drafts of the Web MIDI API specification have moved; they are now available on GitHub. Please update your references.

  • いかにして『八尺様』は生まれたのか/Web怪談と現代のオカルト - デマこい!

    2ちゃんねるが誕生したのは1999年5月、ノストラダムスの大予言の直前だった。2chはオカルトと共に産声をあげた。現在ではオカルトの表舞台からUFOや国家の陰謀が消えて久しく、代わりにパワースポットや、くねくね・八尺様のような新世代のオカルトが人気を集めている。この10年ほどで奇譚や都市伝説はどのように新陳代謝してきたのだろうか。ネットでよく見かける怪談を時系列に並べてみたら、その変遷と発展の系譜が浮かび上がってきた。 キーワードは4つ: 「物語の複雑化」 「寺社でのお祓いはいつから常識になったのか」 「モンスターモノの完成」 「巻き込まれ型被害者から過失のある被害者へ」 ネットで頻繁にコピペ・拡散されている怪談のことを、ここではWeb怪談と呼びたい。また、各Web怪談の書き込まれた時期については洒落怖まとめサイト(http://syarecowa.moo.jp/)等を参考にした。 ※まと

    いかにして『八尺様』は生まれたのか/Web怪談と現代のオカルト - デマこい!
  • Beatonica ヒトの輪でつくる未来の楽器

    beatonica

    Beatonica ヒトの輪でつくる未来の楽器
  • 圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場

    圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場 JavaScriptをデプロイする際には、できるだけ小さくするために余計なスペースや改行を取り除き、さらに関数名なども変換して圧縮することがあります。しかし圧縮後のJavaScriptにバグが見つかるとそのままではデバッグしにくいため、いちいち元のソースコードに戻してデバッグしなければなりません。 Webサイト「HTML5 Rocks」の記事「INTRODUCTION TO JAVASCRIPT SOURCE MAPS」で紹介されたWebブラウザの新技術「Source Maps」は、圧縮状態のコードを実行していても元のソースコードを参照しながらデバッグできるだけでなく、CoffeeScriptのようなJavaScriptへ変換する言語であっても、

    圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場
  • Webサービス、最初の宣伝 - ゆーすけべー日記

    Webサービスのプロモーション?について個人的にまとめてみます。 Webサービスができたら想定するユーザーに使ってもらわないと寂しいところです。 そこでWebサービスを多くの人に知ってもらうための宣伝をしましょう。 今回はサービスを作った作者が一人でできる範囲を考え、 以下の3つの手段を使った初期のプロモーションについて僕なりのやり方を紹介します。 プレスリリース 自身のBlogでの紹介 Twitterでの拡散、はてなブックマークでの注目 今まで僕は個人で、もしくは「会社名義だけれども一人で」WebサービスiPhoneアプリを作った際に、 上記のツールを使いながら意図的に宣伝を行い効果測定をしてきました。 プロモーションのプロではもちろん無いながらも工夫と、ある程度の努力をしています。 中には全く不発のもあり、とはいえ、それはサービス自体がそもそも面白くないケースがあったりで、 だんだん

    Webサービス、最初の宣伝 - ゆーすけべー日記
  • ニッチなのに凝った趣味サイト教えろください : 気になる2ちゃんねる(n´・ω・`n)

    2012年03月21日 ニッチなのに凝った趣味サイト教えろください 1 :名も無き被検体774号+:2012/03/19(月) 04:08:29.27 ID:yZ2OwgAL0 できれば簡単なコメントつきで頼む 無人駅に行ってみた http://www5d.biglobe.ne.jp/~mujinsta/ 無人駅にいきまくってる人 2 :名も無き被検体774号+:2012/03/19(月) 04:13:24.44 ID:yZ2OwgAL0 清く正しい棚の作り方 http://www.coara.or.jp/~tt/books/bkshelf/bkfrm.htm 書店のおっさんが超細かく棚の作り方を解説してるサイト 55 :名も無き被検体774号+:2012/03/19(月) 13:11:36.74 ID:XWVQol5r0 >>2をちらっと見てきた 一人称が「われわれ」なところがツボっ

  • いまからPerl/Ruby/Node.jsやるならRackhubを使わない手はない - Cside::Tech

    自作Webアプリケーションのデプロイ先として Rackhub というのが新たな定番になると思っているので、このたび Kyoto.pm *1 で布教してきました。スライド: http://speakerdeck.com/u/cside_/p/vpsdotcloudrackhubRackhub: http://rackhub.net/Rackhubとは一言でいうと「環境構築済みのVPS」です。その何が新しいのか、何が嬉しいのか、など詳しいことは資料の方へ盛り込んだので、ぜひお読みいただければと思います。 ここからは参加しての個人的な感想になります。皆それぞれに問題意識を持っていて、それを解決するためにがっつり一人の時間を取るようにしているのだなぁと改めて感じました。僕は週5フルタイムでバイトしていたときは業務終了後や週末はぶっちゃけ結構だらけてしまっていたけど、今日紹介されてたライブラリやサー

  • ウェブ系エンジニアなら誰しも両手で数え切れないくらい思う「自分でモノをつくってかせぐんや!!」について - uzullaがブログ

    参考 http://monoist.atmarkit.co.jp/mn/articles/1203/14/news007.html http://blog.riywo.com/2012/03/15/003525 このデスクライトほしいな!!!(挨拶) ウェブ系サービスは、今では一人で全て作れるといわれるけど、実際にはわりと出来ない。 まずモノが出来るかどうか 多くの場合は、まずはスキル的にそもそも足りていない。 自分の想像図まで到達するのに、実際にやってみると自分のスキルでは過大なコスト(時間など)がかかり、挫折してしまう。 次にものがウケるかどうか これもマーケティングとかいうスキルといえるのだろうが、実際作ってもウケなければ仕方ない。*1 自分が思うに、山ほどある「週末作成ウェブサービス」のある程度の割合がこの状態。 リーチできるかどうか モノができていて、それなりにウケる前提があるな

    ウェブ系エンジニアなら誰しも両手で数え切れないくらい思う「自分でモノをつくってかせぐんや!!」について - uzullaがブログ
  • livedoor Techブログ : 住所正規化APIをロケタッチでリリースしたよ!1

    LINEPC から使えるようになって、自社サービスなのに wktk しながらハックしてた大沢Yappo和宏です。こんにちわ。初めましての人は初めましてね。 今回は、先日ロケタッチの API に、住所正規化 APIを追加したので簡単な紹介をします。 ロケタッチ API って何? ロケタッチ API は、ロケタッチのユーザーデータ、スポットデータ、チェックインデータ等にアクセスできる API です。 OAuth2 で実装されているので、どのような言語からも利用しやすくブラウザだけで完結するような JavaScript アプリケーション等にも気軽に導入する事が出来ます。 Perl の世界だと Amon2 という Web Application Framework の認証プラグインとしてAmon2::Auth::Site::Loctouchが CPAN にあるので、これを使うと簡単にロケタッ

  • ブログパーツやソーシャルボタンの類でアクセスログが残るのは当然だけどトラッキングされるのは当たり前にはなっていない - 最速転職研究会

    わたくしは立場上、実装がダメなことにはとやかく言いますがポリシーについてはとやかく言わないことをポリシーとしており、また個人的にも所属組織的にも付き合いがある企業様を痛烈に批判するというのはブーメランとか槍とか鉄砲玉とかソーシャルメディアガイドラインとか飛んできたりしてリスキーではあるのですが、どう見てもアウトだろこれ、と考えるに至りまして筆を取らせていただく次第です。 これ http://d.hatena.ne.jp/kanose/20120306/hbmbutton http://blog.dtpwiki.jp/dtp/2011/09/post-9367.html どう見てもアウトだろ。理由は単純で、そういう目的で設置されたボタンではないし、はてなブックマークボタンが設置されているサイトは、はてなの管理してないサイトなのではてなの裁量でやってはいけないからです。いつから「はてな」は「は

    ブログパーツやソーシャルボタンの類でアクセスログが残るのは当然だけどトラッキングされるのは当たり前にはなっていない - 最速転職研究会
  • Web系の人に求められていること

    サブタイトルは「私は如何にして心配するのを止めてWebを愛するようになったか」 2007年に発表したプレゼンですが、今にも通じるテーマだと思うので公開しました。 動きの速い業界ですが、抑えておくところを抑えておけば翻弄されずに前に進むことが出来るのではないかと考えています。Read less

    Web系の人に求められていること
  • Web登録フォームで半角や全角などの入力を強いる理由を考えてみた

    及川卓也 / Takuya Oikawa @takoratta 良く言われるが、この欄は全角で入力などと利用者側に強いるのはどうしてなんだろう。システム側で簡単に変換できるのに。前考えたのは利用者の入力したものを受付システム側で勝手に変更することに法的なリスクがあるのではないかということだったけれど、確認UIを出せば済むのでは? 2011-01-22 09:40:49

    Web登録フォームで半角や全角などの入力を強いる理由を考えてみた