http://en.wikipedia.org/wiki/Curse_of_knowledge 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 GoogleのIlya Grigorikがプレゼン [1] において、TLSをもっと活用できるデフォルト設定をnginx側にしてほしい、つまり設定できるだけでは人々は気づかないのでデフォルトをどれにするのかというのが重要なのだと説明する文脈で例えにだしたのが、「Curse of knowledge」 The curse of knowledge is a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems

https://www.youtube.com/watch?v=nlt4XKhucS4 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 CloudFlareのWAF (Web Application Firewall)は、HTTPリクエストをフィルタリングし、 SQLインジェクション コメントスパム XSS DDoSアタック WordPressなど特定のアプリを狙った攻撃 などの攻撃をネットワークのエッジで、つまりサーバに到達する前に守ってくれます。 適用するフィルタリングルールは、オープンソースのOWASPなどの共通ルール 5,682件 + CloudFlare内製のルール 102件 + 顧客企業がカスタムメイドしたルールの総計で、それが全てのリクエストに当てはめられます。その処理速度は平均1ms以

会社のビジョンやカルチャーは、長期に続く活力あるチームであるために本当にすごく大切だなと感じることがこの数年の間に何度かありました。 では、その「本当に」「すごく」というのは具体的にどれくらい重要なのでしょうか？ PandoMonthlyの２時間に及ぶ長いインタビューの最後に、WorkdayのCEOであるAneel Bhusriが、「ほとんどの人がそう思ってないけど、自分だけは強く信じていることは何？」という質問に答えて、 「うちの会社にとって、カルチャーはプロダクトよりも大切だ。」 と言い切っています。よいカルチャーが、よいプロダクトづくりに必ずつながるという彼の長年の経験から得た確信がそう言わせているのかと。 また、Ernie Millerは "Human-Driven Development" と題したブログで、 幼い頃から人は「なぜ？」と質問する。その理由を知りたいという衝動はなく

https://www.youtube.com/watch?v=FEs2jgZBaQA 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 CSSconf EU 2014におけるGoogleのAddy Osmaniの講演です。CSSのパフォーマンス向上に役立つツールを40個+ 紹介してくれてます。 背景 パフォーマンスの最適化において、 ベースラインとしてやること 最小化（minification） 結合（concatenation） 画像の最適化 圧縮（GZip, Zopfli） 非同期スクリプト キャッシュの利用 WOFF2フォント CSSスプライトを使う リダイレクトをしないこと スピードアップ パフォーマンス向上に重要なCSSのインライン化 レンダリングをブロックしないように、急ぎでないアセットの取

https://www.youtube.com/watch?v=Iebb5dXaScE 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 GopherCon 2014における、PoptipのCEOであるKelsey Falterの講演。同社はCNN、ESPN、L’Orealなどメディア & コンシューマグッズ大手に、ソーシャルメディアコンテンツの分析やアンケートのプラットフォームを提供しているNew Yorkのスタートアップです。 最初はNode.jsで開発したが、スタートアップにありがちな大手顧客の対応のためのスケールアップと、平行して資金調達活動を続ける中での時間がないバタバタの状況で、 インスタンスが落ちるとシングルポイント障害点になってしまう。ホストしているサーバの障害やアプリのクラッシュなどが

http://www.youtube.com/watch?v=1Evwgu369Jw 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約2時間前 大筋意味はわかるし、表面的な日本語訳もできるし、英語で話すときも使うんだけど、100%ニュアンスの理解ができてない英単語に時々出くわします。ほとんどはわかったふりして日常を過ごしてしまうのですが、その単語が重要なキーワードだと、さすがに腹落ちさせないとまずいと思うのですが、今回は運良く、”empathy” のわかりやすい説明を見つけました。 開発のチームづくりの話題を取り上げると、よくでてくる単語が “empathy”です。辞書だと、「共感」「感情移入」という日本語訳になります。オフィスに集ってチーム一丸となって働くとき、またリモートで働くチームをまとめるとき、いずれも

https://medium.com/on-product-management/20201872f369 2 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 昔の職場で月曜日の朝イチに日程会議というものがありました。社内の全プロジェクトのフェーズごとに目標日程と実績日程が表に記載されていて、全員の前でスケジュールの進捗を報告する、はい、過酷な会議でした。成果をだすために担当は相当頑張った目標を掲げるので、スケジュールは概ね遅れます。（最初の目標設定が甘いと、それはそれで当然怒鳴られる。）遅れたスケジュールの理由を問いただされて、曖昧に逃げようとすると、「質問にきちんと答えろ!」と怒鳴られる。「では来週までにどうにかします。」と答えると、「来週でなくて、日付で答えろ！」とまた恫喝される、逃げ場のない会議

http://blog.pop.co/post/67465239611/why-we-chose-api-first-development POPは、簡単にビジネス/アイデアをかたちにするために、1分でドメイン/スタートページ/メアドを用意できるサービスとのこと。彼らが、「APIファースト」で開発しようとした理由を紹介してます。 1) 将来APIを提供できるように 機能を追加する都度、APIが既に準備できているかたちになるので、将来APIを第三者に提供するときもスムーズ。 2) フロント/バックエンドの分離 バックエンドのテンプレートコードがフロントエンドのクライアントビューとやり取りしない仕様にすることで、将来の開発に負の資産を残さない。 3) スケーラビリティ フロント/バックエンドそれぞれを独立してスケールさせることができるので、将来的にメリットがでるはず。 4) 開発言語のバリア

http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/Steve Soundersがブログで、HTML Importで広告を非同期で読込むことでパフォーマンスの悪化を回避するテクニックを紹介してます。 スクリプトの読込みはウェブサイトのパフォーマンスが悪化する要因になるので、Google Analytics / Tweet ボタン / FacebookSDK / Google+のfollowボタンなどは、非同期で読み込める手法をとっているが、広告はdocument.writeを使ってるため、それができない場合が多い。 現状ではHTML importsは、linkタグではなく、それに続くscriptタグでレンダリングがブロックされる。（HTML importsはChrome Canaryで、Experi

http://blog.mailgun.com/post/we-just-open-sourced-flanker-our-python-email-address-and-mime-parsing-library/ MailGunは、2012年にRackspaceが買収したYcombinator出身の会社で、開発者向けにメール送信API & サービスを提供しています。7月にメアドバリデーションAPIであるGuardpostをオープンソース化したのに続いて、今回は、Pythonベースのメアド/MIMEパーサライブラリであるFlankerを発表しています。 1) mime Pythonの標準パーサライブラリは、小さなメッセージには早いが、大きくなると問題になるので、Flankerをつくることにした。一番のポイントはヘッダーのパース。Flankerはメッセージ全体でなく、ヘッダーのみをパースす

http://matt-welsh.blogspot.com.au/2013/08/rewriting-large-production-system-in-go.html Go言語の４周年をテーマにしたgolang.orgのブログで紹介されていた、GoogleのMobile Web Performanceチームに所属するMatt Welshのブログです。大規模な本番システムの作り直しにGo言語を採用した経験を語っています。 1) 背景 C++のオリジナルのコードベースは問題なく作動していたが、何年も複数の目的の違うプロジェクトで共有されていたため、スピーディーに改修するのが難しくなっていた。（何のシステムなのか具体的に書いてないのは残念。。） イメージフォーマットをトランスコードするライブラリはC++で完璧に動作していたので、そのまま残し、それ以外を全てGo言語で書き直した。 元のコード

https://www.twilio.com/engineering/2013/11/04/http-client スマホアプリ <-> サーバ間や、サーバ <-> 3rd partyツール間でHTTPリクエストを送ることは一般化してますが、その性能をあげるための工夫を、Twilioがエンジニアブログで紹介してます。 サーバの様々なHTTPポートに接続し、エラーパターンをシミュレートして、クライアント側が適切にハンドリングしているかどうか確認するライブラリが、Githubで公開されてます。 1) コネクションエラー サーバが遠隔にあるマシンに接続できない場合、HTTPリクエストが完了しないのでConnectionErrorが返ってくるだけで具体的な理由はわからない。 ここでまずできることは、タイムアウトの設定。connect () は通常即座に完了するか、失敗するかのどちらか。Twilio

http://code.flickr.net/2013/06/14/pre-generating-justified-views/ Flickrがエンジニアブログで、クッキーを利用して、写真ストリームの表示アルゴリズムを改善した事例を紹介しています。 1) 写真ストリーム表示のアルゴリズム ブラウザのviewportの幅と写真のリストの取得 最大可能な高さとそれに呼応して変更される幅に従って、写真を行方向に順に並べていく 横幅がviewportよりも長くなれば、横幅がサイズ内に納まるまで高さを下げる 2) 以前の問題点 viewportの横幅を知るために、このアルゴリズムをブラウザ全体で実行する必要があった。 各写真データがどのようなサイズであるべきなのかが、アルゴリズムを走らせてからでないとわからないため、写真データのダウンロードがプロセスの終わりにならないと開始できなかった。 3) 改

http://www.quora.com/Stripe-company/What-engineering-problems-and-challenges-is-Stripe-solving  本題とは違いますが、Quoraのページはログインしないと閲覧できないのがいつもイラっとしますね。 さて、それはさておき、Y-combinator出身で決済ソリューションを提供するStripeのCTOであるGreg Brockmanが開発におけるチャッレンジについて答えています。同社のサービスは開発コミュニティからの評判がよいことで知られてます。 「Amazon, Appleなど15年変わってない決済のレガシー（だけど巨大な）勢力よりもよいソリューションをつくる」という前置きで、 Product オンライン決済および関連ツールを再設計するという考え。決済はかなり複雑なので、UX / 法的&会計的要件 /

[Podcast] http://5by5.tv/changelog/100 GoogleのRob PikeとAndrew GerrandがThe Changelog PodcastでGoプログラミングについてインタビューを受けてます。 Goは３年半前に最初にリリース。Cのようなローレベル言語とRubyやPythonのようなスクリプト言語と中間の位置づけ。C++のようい何でも機能があるものではなく、シンプルであることがコアバリューで一貫性がある言語。 使ってもらうとどれだけ生産的で早いが実感できる。先日のプロジェクトで全部のテストプログラミングが8ミリ秒で実行できた。プログラマにとって効率的だが、コンピュータにとっても効率的。 Rubyのように同じことをあらゆる書き方で実現できるのではなく、一つではなくてもある程度決まった書き方でロジカルに解決するのが、プログラマー間での共通の理解、コード