ハイパフォーマンスブラウザネットワーキング輪講を社内でやっている話
ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Ilya Grigorik,和田 祐一郎,株式会社プログラミングシステム社 オライリージャパン 売り上げランキング : 94924 Amazonで詳しく見る by AZlink O'rreilyのハイパフォーマンスブラウザネットワーキングは日本語版が発売されたのを機に輪講形式で社内勉強会をやっている。先週の時点で8章の「モバイルネットワークの最適化」が終り、丁度折り返し地点である。 なぜ輪講形式にしたか 本の内容は、光ファイバーや無線の規格といった下のレイヤからHTTP2やWeb RTCの上のレイヤまでカバーしている。その範囲からして、アプリケーションエンジニアだけでやるよりも、インフラの人に解説してもらった方が面白いのでは、と思ったから。 例えばTLSの章に出てくる証明書チェーンの最
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
Gin Web Framework
Gin Gonic The fastest full-featured web framework for Golang. Crystal clear. Performance and productivity can work together Gin is a web framework written in Golang. It features a martini-like API with much better performance, up to 40 times faster. If you need performance and good productivity, you will love Gin. Low Overhead Powerful API You can add global, per-group, and per-route middlewares,
Railsが時代に合わなくなってきた - Qiita
追記 RailsでJS辛い問題に関しての結論：http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptがRailsから独立している Railsはとても堅牢。 モデル、コントローラ、ルーティングと、変にいじらない限りはほとんどテストが要らない。 必要なのは、モデルに新たにpublicメソッドを付けたときくらいだろう。 実際、バックエンドはそうそうバグが出ない。
HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
シニアエンジニアによるガラケー大戦回顧録に参加した
シニアエンジニアによるガラケー大戦回顧録 : ATNDに参加した。 この会合の主旨としては、当時の邪悪で不自由極まりないガラケーの開発姿勢が、如何に悲惨で惨めで肥溜めの中の蛭のようなものだったかを、非公開の会合で語ろうというものだ ガラケーの開発では、技術的に誤っている手法が実に多く使われていた。なるほど、不自由で貧弱なガラケーの実装が規格準拠しておらずバグだらけだったこともあろう。それにしても、ガラケーとは関係がないサーバーの中だけで完結する場所におけるクソもあった。何故そんなことになってしまったのか。 理由は、情報が公に出せず、したがって共有されなかったことだ。情報が共有されないため、表立って議論や相談が出来ない。その状態でかろうじて見つけたちっぽけな情報を元に、技術的に極めて劣っていながらも、何とか動くものを作り出していた。そして、その動くものを、正しいやり方だと勘違いしていたのだ。
他人のブログのアクセス数・被リンクを調査できる分析ツール 5 選 - Naifix
ブログを運営していると、他人のブログ（競合サイト）のアクセス数はどれくらいあるのか、どんなキーワードで集客しているのか、気になってきますよね。 競合サイトを調査するメリットは以下の 3 点。 具体的な目標を設定するさいの目安にできる モチベーションを維持するきっかけになる 自分のブログに足りない点を見つけられる 競合サイトの分析に関する解説はこちら ツールを使えば調査はそれほど難しくありません。本記事では、ライバルサイトを丸裸にする分析ツールを 5 つ紹介していきます。 他のブログのアクセス数が推測できる仕組み 他のブログのアクセス数を計測できるツールはいくつかあります。 独自のクローラーを走らせて分析していたり、主な検索キーワードの順位・CTR をもとに算出していたりと計測方法は様々。 なかには、無料で他サイトのデータを提供する代わりに、ユーザーの Google アナリティクスや Sea
#ガチJS でJavaScriptとフロントエンドの未来について熱い話をした - mizchi's blog
(追記): このブログで一部のJSをgithubに置いてたら 「The website abuses rawgit.com」という警告が出てました。現在修正しました。ご迷惑おかけしました。 @kyo_agoさんの主催で、 @mizchi(シングルページ系フロントエンドJSer) と @damele0nさん(ゲーム系HTML5のJSer)でJavaScriptについて話をした。すごく有意義な話だったので、会話を思い出せる限り書いてみる。 このエントリを読む前にこの記事を読むと幸せになれる。 幸せになりたいソーシャルゲーム系Webフロントエンドエンジニアが本気で考える HTML GUI ツール第一回 - damelog このまとめは僕の主観であり、僕が理解できた部分と自分の発言を一番覚えてるのでどうしてもそれが多めになりますが、ご容赦ください。ついでに酒入ってる。 iOS SafariのIE化
How Disqus Went Realtime with 165K Messages Per Second and Less than .2 Seconds Latency - High Scalability -
« Sponsored Post: Apple, Wargaming.net, PagerDuty, HelloSign, CrowdStrike, Gengo, ScaleOut Software, Couchbase, Tokutek, MongoDB, BlueStripe, AiScaler, Aerospike, LogicMonitor, AppDynamics, ManageEngine, Site24x7 | Main | Stuff The Internet Says On Scalability For April 25th, 2014 » Here's an Update On Disqus: It's Still About Realtime, But Go Demolishes Python. How do you add realtime functionali
最近ウェブでまかり通っている悪弊
《Update：死活問題だ》 ［本文が読めない modal overlay：image］ オモシロそうな記事だと思ってリンクをたどっていくと、「modal overlay」に遭遇する機会が増えてきた。 ユーザーが入力しないかぎり本文へは進めない例のウザったいダイアログのことだ。 頭にきた Andy Beaumont はそんなヒドいケースをいくつも集めて、つぎのようにいっている。 Tab Closed; Didn’t Read: “If you’re going to insist on obscuring your content with …” by Andy Beaumont: 05 December 2013 ＊ ＊ ＊ どうしても自分のコンテンツを読んで欲しくないのなら・・・ 最近ウェブでまかり通っている悪弊について Andy Beaumont いわく： A web
Sumallyのconsole.logが可愛くあざとい件 - PolyPeaceLight
普段の癖でSumallyを開いた時にWeb Inspectorを立ち上げるとconsole.logにメッセージがあることに気がついた。 なんだこれｗｗ 「We need couple of talented geeks. Are you the one? Check this out」 「探しものはなんですか？見つけにくいものですか？HTMLの中も、JSの中も、探したけれど見つからないのにまだまだ探す気ですか？それより僕と働きませんか？」 「コードやHTTPの通信を見て、まだまだ改善の余地あるな、と思ったあなた！僕らのチームに参加しませんか？」 「おおっと！Web Inspectorでチェックですか！そういう精神好きです。僕らのチームに参加しませんか？」 「We want you for our engineering team. Check this out」 うまいけど僕はそこで上記の
2014年のウェブシステムアーキテクチャ - stanaka's blog
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
スマホ時代の「気持ちのいい情報提供の仕方」はなんだろう？ : けんすう日記
スマホ時代の感覚の違い 最近、元livedoor社長の堀江貴文氏による「TERIYAKI」というアプリがリリースされました。 これは簡単に言うと「おいしいものを知っている人だけが投稿するグルメサービス」という感じで、食べログやRettyなどとはまた違ったアプローチで、お店を探せるようになっています。 月400円という値段ですが、これはかなりアリだなーと使ってみて思いました。 しかし一方で、アプリなら使うけど、PCだと使わなそうだなと思いました。食べログのほうが使いたいと思っちゃう。でもアプリだと、TERIYAKIのほうがいいなあ、と思ったのですよね。 これはなんでだろう？と考えてみたんですが、やはりPCとスマホでは、使う際の感じ方が全然違うからなのかもしれません。 スマホ時代の情報提供の仕方 この前、総アプリDL数が3000万とかいっている、超アプリ作りが得意なコミュニティファクトリーの松
無料でここまでできる→日本語を書くのに役立つサイト２０選まとめ
（例文／コーパス） ◯KOTONOHA「現代日本語書き言葉均衡コーパス」 少納言 www.kotonoha.gr.jp/shonagon/search_form 現代の日本語の書き言葉の全体像を把握できるように集められた約１億語収録の『現代日本語書き言葉均衡コーパス』をジャンルを指定したり、前後にくる言葉を指定した上で検索できる。用例を探したいときはまずここを当たる。 ◯コーパス検索ツールNINJAL-LWP for BCCWJ (NLB) nlb.ninjal.ac.jp/ 『現代日本語書き言葉均衡コーパス』を検索するために、国語研とLago言語研究所が共同開発したオンライン検索システム。上の少納言との違いは、名詞や動詞などの内容語の共起関係や文法的振る舞いを網羅的に表示できるところ。 たとえば「タバコ」を検索すると、用例が「タバコ＋助詞＋動詞」や「動詞＋タバコ」＋「タバコ＋助詞＋形容詞
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebAPIのこれまでとこれから
RFC7231のリファラに関するメモ
Yeomanではじめる爆速webアプリ開発
Internet ExplorerはIE特化アプリから一時的に日本を救ってくれたけど次回はもう助けてくれないよという警告
ShouldBee - テスト作業を限りなくゼロに
