タグ

ブックマーク / postd.cc (95)

  • 60 (フレーム・パー・) セカンズ:Pinterestの描画パフォーマンス最適化のケーススタディ | POSTD

    今日はWebサイトやWebアプリの描画パフォーマンスをどう改善したらいいのか、ということについて取り上げようと思います。私たちWeb開発者にとって、この分野は比較的新しく注目し始めたエリアで、 ユーザエンゲージメントとユーザ体験 に影響があるため重要です。 フレームレートはWebにも影響がある フレームレートとは、 連続した イメージを端末がスクリーンに映し出すレートのことです。秒間フレーム数(FPS)が低ければ肉眼で個別のフレームを判別でき、FPSの数値が高ければユーザにとっては反応が速いと感じられます。ゲーム業界ではおなじみの概念となっているものですが、Webにも当てはまるのです。 長時間に及ぶイメージのデコード、不必要なイメージのリサイズ、重いアニメーションとデータ処理はすべてフレーム落ちを起こす可能性があり、結果としてフレームレートは下がり、jankが多いページになってしまいます。

    60 (フレーム・パー・) セカンズ:Pinterestの描画パフォーマンス最適化のケーススタディ | POSTD
    efcl
    efcl 2015/07/04
    Gone In 60 Frames Per Second: A Pinterest Paint Performance Case Study の翻訳 結構前のPinterestのスクロール改善前の話
  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
    efcl
    efcl 2015/06/14
    Code Review Best Practices の翻訳
  • ReactをjQueryの数行に要約する | POSTD

    Reactが素晴らしい理由は、UIをアプリケーションの状態の純粋関数にできるからだ」いうような話を聞いたことがあるでしょう。しかしそれだけではなく、不変性と仮装DOMを利用して動作するということも聞きますよね。その上、保存、読み込み、取り消し、それにタイムトラベル・デバッグと呼ばれるすごい機能まで自由に手に入れられる。でも知っていますか? Reactの核となるアイデアを利用し、その恩恵に預かるのにこれらのことは必要ありません。jQueryの数行にしてお見せします。 <span id="colored-counter">0</span> <input id="color"></input> <button id="inc"></button> <script> $('#color').on('keyup', function () { $('#colored-counter').css('

    ReactをjQueryの数行に要約する | POSTD
    efcl
    efcl 2015/04/23
    jQueryで書いたコードにReactのアイデアを適応して、状態の変更とDOMへの反映へと処理を分けていく話。 Virtual DOMやimmutabilityについても触れている
  • FacebookのFluxアーキテクチャの始め方 Part 1 | POSTD

    私のように、Reactを使ってより進んだことがしたいと考えたなら、おそらく Flux に注目した経験があると思います。ざっと目を通してタブを閉じ、JavaScript開発者としての自分の人生を見直したことでしょう。 もしReactになじみがなければ、私の記事 「React入門」 を読んでみてください。 Fluxとは? Fluxは、遠目には始めるために複雑な手順を踏まなければいけないように映ります。しかし、 GitHubにあるexample を見てみれば、これがどのように機能するのかが実に明確になってきます。 簡単に言うと、Fluxは美化された 出版-購読型モデル のアーキテクチャです。データはシステム内を一方向に流れ、そこから様々な利用者が必要に応じてデータを取得します。これについて考えるには、私たちの体に例えてみると簡単です。 イベント – 血液 血液は私たちの体内を一方向に流れています

    FacebookのFluxアーキテクチャの始め方 Part 1 | POSTD
    efcl
    efcl 2015/04/08
    Fluxの役割紹介
  • NginxでHTTPS : ゼロから始めてSSLの評価をA+にするまで Part 1 | POSTD

    数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report

    NginxでHTTPS : ゼロから始めてSSLの評価をA+にするまで Part 1 | POSTD
    efcl
    efcl 2015/03/20
    サイトをSSLで運用するまでの話
  • 完璧なJavaScriptフレームワークを求めて Part 2 | POSTD

    テンプレートがHTML内に存在しており、よく使われる手法です。見た目がナチュラルで、HTMLが自然にタグを内包しているので理にかなっています。ブラウザが <script> 要素のコンテンツをレンダリングしないため、ページレイアウトが崩れません。 テンプレートがAjaxを用いてロードされるケース Backbone.View.extend({ 'template': 'my-view-template', 'render': function() { $.get('/templates/' + this.template + '.html', function(template) { var html = $(template).tmpl(); }); } }); コードは外部HTMLファイルに記述され、 <script> タグを追加しなくても済むようになっています。しかしHTTPリクエストの

    完璧なJavaScriptフレームワークを求めて Part 2 | POSTD
    efcl
    efcl 2015/03/19
    "どんなプロジェクトも良いドキュメンテーションなしでは遅かれ早かれダメになると思っています"
  • モノモーフィズム(単相性)について – JavaScriptのパフォーマンスを例に | POSTD

    JavaScriptのパフォーマンスに関する講演やブログ記事では、よく単相的コードの重要性が強調されています。しかしながら、モノモーフィズム(単相性)/ポリモーフィズム(多相性)とは何なのか、それがどうパフォーマンスに影響してくるのかということについては、あまり分かりやすく説明されていません。私自身の講演でも、<< 1.良い型、2.悪い型 >>的な二者択一のスタイルに要約してしまうことが少なくありません。パフォーマンスに関するアドバイスを求められることがありますが、そういう時に最もよくリクエストされるのは、 モノモーフィズムとは実際のところ何なのか 、ポリモーフィズムがなぜ生じ、それがなぜ悪いのか、ということを説明して欲しいというものです。 困ったことに、そもそも「ポリモーフィズム」という用語そのものが相当に多重定義されています。昔ながらのオブジェクト指向プログラミングにおいては、 ポリモ

    モノモーフィズム(単相性)について – JavaScriptのパフォーマンスを例に | POSTD
    efcl
    efcl 2015/03/16
    V8のインラインキャッシュの仕組み。 polymorphicとmegamorphic、IRをもうけての最適化、パフォーマンスへの影響。 Shape(Hidden Class)などについて
  • 2015年に向けたJavaScriptアプリケーションアーキテクチャ Part 1 | POSTD

    私はかつて自分はアーキテクトだと名乗ったことがあります。これを裏付けるため、今やウソだらけの複雑な話を設計しなくてはならなくなっているので、ある意味これは当のことですね。冗談はさておき、2015年を目前としてJavaScriptコミュニティのアプリケーションアーキテクチャの状況について目を向けてみるのは有益なことだと思います。合成、関数型の境界、モジュラリティ、不変データ構造、CSPのチャネルと、その他に関連するいくつかのトピックについて書いてみたいと思います。 合成 アーキテクチャのレベルでは、JavaScriptで大規模なアプリケーションを作成する方法に関してここ数年で少なくとも一つの根的な変更がありました。機械の細かい違いにより生み出される単一指向性の データバインディング、不変データ構造と、仮想DOM (どれも興味深い問題ですね)などを除けば、多くの開発者が一つのキーコンセプト

    2015年に向けたJavaScriptアプリケーションアーキテクチャ Part 1 | POSTD
  • JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD

    この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

    JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
    efcl
    efcl 2015/02/03
    console APIを使ったデバッグ方法の色々。 console.traceとObject.observeの組み合わせなどについて
  • 多種多様な基準から見るプログラマの市場価値 | POSTD

    私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは?」( 当社は時給ベースで給与を計算します )ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル(600円から60,000円)まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ

    多種多様な基準から見るプログラマの市場価値 | POSTD
    efcl
    efcl 2015/01/15
    OSSのコントリビュート、物価、StackoverflowのReputation、資格の評価軸について
  • Haskellのエンジニアは二流なのか?(答えはノーである) | POSTD

    挑発的なタイトルによって誰かが気分を害してしまう前に、私はこの問いに対する答えも書いてしまうことにしました。答えは“ノー”です。しかしこのテーマには、なかなか興味深い議論があるのです。HaskellやErlangや、特にClojureなどのあら探しをするつもりはないのでしょうが、Piaw NaはQ&AサイトQuoraの あるアンサー で以下のようにコメントしています。 プログラミング言語を固定するのは二流のエンジニア/コンピュータサイエンティストである証です。 [中略] 私がErlangのサーバに携わるポジションの採用をした時も、Erlangのスペシャリストだと言うエンジニアより、優秀なオールラウンダーのエンジニアを雇ってErlang(これに限らず何でも)を学ばせてそのポジションを埋める方が断然いいと感じました。 Na氏の意見は1990年代に設立されたGoogleAmazonなどの技術

    Haskellのエンジニアは二流なのか?(答えはノーである) | POSTD
    efcl
    efcl 2014/12/23
    "Pythonを学ぶ人は、それで職を得ようとして学ぶのではない。本当にプログラミングが好きで、既に知っている言語では満足できないから学ぶのだ。" 「Pythonのパラドックス」
  • Makeについて知っておくべき7つのこと | POSTD

    Make は、様々なタイプのファイルのビルド作業を自動的に行ってくれるシンプルかつ強力なツールです。しかしながら、makefileを書く際に問題にぶち当たるプログラマもいれば、Makeの基知識がないことで、既存のものを再発明してしまうプログラマもいます。 Makeの働き デフォルトでは、Makeは一番目のターゲットから開始します。このターゲットのことをデフォルトゴールと呼びます。 Makeはカレントディレクトリのmakefileを読み込み、一番初めのルールで処理を開始します。しかし、Makeが完全にこのルールを処理する前に、ルールが依存するファイルのためのルールを処理しなければなりません。各ファイルそれぞれは、自身のルールに従って処理されます。 実はこれは、各ターゲットの再帰的アルゴリズムになっています。 ターゲットをビルドするルールを見つける。ルールがないようであれば、Makeはうまく

    Makeについて知っておくべき7つのこと | POSTD
    efcl
    efcl 2014/12/18
    Makefileのパターン。
  • テクニカルライティングの将来 ー GitHub上のAsciidocで技術書Pro Gitを協働執筆 | POSTD

    Pro Git第2版の驚くべき冒険と最終的なツールチェーン ほぼ6年前、私はApressから執筆が予定より遅れていたPro Gitと呼ばれるの手伝いの誘いを受けました。結局原著者が書き続けないことを決めて、私が最初から書き直して2009年8月頃に最終的に出版されました。最初の3章あたりは、私はWordでを書きました。そして編集者に文書を送って、しばらくして最終的な版を手にしました。 この3章のあとで、私たちが執筆と技術的な編集段階のためにMarkdownに切り替えて、同意された編集のためにだけWordへ戻るように提案したとき、私はやめようとしていました。一旦が完成したら、私はすべての内容をMarkdownへ再び戻したので、それを私が作成したWebサイトにおいてオンラインで発表できました。幸運にも、原著者は著作をクリエイティブ・コモンズ・ライセンスとすることでApressと同意しました

    テクニカルライティングの将来 ー GitHub上のAsciidocで技術書Pro Gitを協働執筆 | POSTD
    efcl
    efcl 2014/12/15
    https://github.com/azu/promises-book/ もAsciidocで書いた。Atlasまだ使えなかったので、CI使ってビルドとか自動化してた。
  • それでも独自のCSVを書くつもりですか? | POSTD

    一部誤訳の指摘があったため、修正しました!ご迷惑おかけして申し訳ございません! あなたは自分でCSVを書いてみたいですか? フィールドはコンマで区切り、行は改行で分けます。簡単ですよね。数行書けば勝手が分かるというものです。 でも、ちょっと待ってください。 フィールド内にコンマがある場合は? ダブルクォート(”)で、該当のフィールドを囲みましょう。簡単ですね。 では、ダブルクォートで囲めるフィールドに例外はあるのでしょうか? フィールド内にダブルクォートがある場合は? フィールド内の各ダブルクォートに対して、ダブルクォートを二重化して適用しましょう。そうすれば元のダブルクォートをエスケープすることができます。 なお、二重化したダブルクォートと空フィールドを囲んでいるダブルクォート( ...,"",... )を勘違いしないように気を付けてください。 フィールド内に改行がある場合は? その場合

    それでも独自のCSVを書くつもりですか? | POSTD
    efcl
    efcl 2014/11/14
    CSVのパースについて
  • Optimizelyを使ってクビになりかけたワケ ~統計学が苦手なマーケターへの薦め~ | POSTD

    (訳者注: 検定手法について、この記事には一部内容が古い部分があります。Optimizelyは現在、両側検定を採用し、独自開発したより精度の高い統計手法(Stats Engine)でテスト結果を表示しています。Stats Engineに関する記事: 日語 ・ 英語 ) 私たちがSumAllでA/Bテストを一斉にスタートさせて6ヶ月が経ち、あまりよくない結末を迎えました。それは勝算があるとした結果のほとんどが新規ユーザーの獲得改善にはつながらなかったことです。それどころか、私たちは失敗したのです。そして私の一番の責任はユーザー獲得の増加であるということを考えると、当に最悪の状況でした。私にとっても、私のキャリアにとっても、そしてSumAllにとっても。 過去に A/BテストとWebサイト・パーソナライゼーションの会社 に勤めていた経験から(はっきり言うとMonetateはOptimize

    Optimizelyを使ってクビになりかけたワケ ~統計学が苦手なマーケターへの薦め~ | POSTD
    efcl
    efcl 2014/11/11
    A/Bテストの片側検定と両側検定の違いについて "A/Bテストをしているのではなく、自分の仮説を確かめているだけ"
  • マイクロサービス – 分散された大きな泥だんご | POSTD

    モノリシックがダメだからといって、マイクロサービスが解決策になるわけではない ソフトウェア開発業界は流行に左右されやすいという証拠に、今マイクロサービスが、いたるところで大騒ぎされています。”次の大ブーム”だと思う人もいるでしょう。また、(10年前に”上出来”と見なされたような)大型のSOA、サービス指向アーキテクチャが単に軽量化して進化したものだと捉える人もいるでしょう。私は現在のマイクロサービスアーキテクチャに関しては好意的に見ています。しかし、だからといってこのアーキテクチャは決して万能薬ではありません。言うまでもないことかもしれませんが、多くの人が間違った理由でマイクロサービスに飛び付いているように思えるのです。 これは私の講演でよくお見せするスライドで、 以前ブログにも書きましたた が、ソフトウェアシステムを開発するにはいろいろな方法があります。まず、昔ながらのモノリシック(一枚

    マイクロサービス – 分散された大きな泥だんご | POSTD
    efcl
    efcl 2014/11/06
    "優れたマイクロサービスアーキテクチャをつくる上で必要な設計思想と分散戦略は、優れた構造のモノリシックシステムをつくるために必要なものと同じ"
  • GitLab flowから学ぶワークフローの実践 | POSTD

    Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys

    GitLab flowから学ぶワークフローの実践 | POSTD
    efcl
    efcl 2014/10/23
    GitLabのブランチのワークフロー
  • エンジニア向け技術書購入の裏側 | POSTD

    この数ヶ月というもの、プログラマーを執筆することを薦めている記事をいくつも見かけてきています。このような記事ではそれぞれ少なくとも少しは役に立つアドバイスを提供しており、最終的には同じようなアイディアへとつながる結論に達していました。 自分のブランド構築のためにを執筆するべき . この結論は私からすると正確で非常に残念なものです。を執筆するということに対する圧倒的な理由がブランド構築というのであれば、これから著者になるであろう人々はブランド構築をすることで何らかの利得があるという人(そして、時間を無駄遣いする人)だけになってしまいます。 そこに至るまでの道のり インターネットが原因だというのは明白です。誰もがといっていいほど多くの人が動画や楽曲、そして書籍を無料でダウンロードできることを知っています。「違法ダウンロード」に関する意見は反対意見からプライドに満ちたものまでと様々です。

    エンジニア向け技術書購入の裏側 | POSTD
    efcl
    efcl 2014/10/20
    海外の技術書事情。 印税だけだと暮らせない問題はやっぱり多いんだな。leanpub薦められてる
  • 優れたエンジニアを採用できないワケ | POSTD

    あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、

    優れたエンジニアを採用できないワケ | POSTD
    efcl
    efcl 2014/10/15
    雇用する側が考えるべきことについて
  • さあGoを始めよう!環境構築,”Hello World”から簡単なバックエンドサーバーまで | POSTD

    Goは、 信頼できる賢い人たち によって作られた愛すべきささやかなプログラミング言語で、 現在も成長中の大規模なオープンソースコミュニティ によって、継続的に改善が続けられています。 Goの基原則はシンプルであることですが、時折、約束事が分かりにくいこともありますね。以下では、私がどのようにしてGoプロジェクトを始め、どのようにGoのイディオムを使っているかを紹介したいと思います。一緒に、Webアプリケーション用のバックエンドサービスを構築しましょう。 環境の構築 新規プロジェクト Webサーバの作成 ルートの追加 複数APIへのクエリ 並列化 シンプルさ 追加演習 環境の構築 最初のステップは、もちろんGoをインストールすることです。オフィシャルサイトに用意されている、 お使いのオペレーティングシステム用のバイナリディストリビューション を使ってください。MacでHomebrewを使

    さあGoを始めよう!環境構築,”Hello World”から簡単なバックエンドサーバーまで | POSTD
    efcl
    efcl 2014/10/14
    golangでRESTのバックエンドを書くチュートリアル