http://engineering.flipboard.com/2015/02/mobile-web/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 ものごとが進化すると、利用するユーザの満足度はあがるので、それを用意する作業量はツールの改善に従って最終的には減っていくのか？ スマホが登場して、アプリ上でのスワイプなどの直感的にできる操作や表現の幅が広がり、またディスプレイも改善。では、プロダクトをつくる側がそれに慣れてくると、作業量が減るのか？いや、現実は逆。同じことを実現する作業量は減っても、トータルでは減らない。ブラウザとアプリにまたがって、双方のメリットを取り込もうと、もっとレベルの高いUIを目指した競争が続いています。 David BellonaがTwitter Universityでの

マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。 1) 非同期 & 可視化が進む GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。 2) マネージャの役割が変わる 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。 プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向

Reactは当初、「Huge step backwards（これではメンテできなくて、かえって大きく後退してしまっている。）」「Rethink established best practives（皆が積み上げてきたベストプラクティスを変えようとしている。）」と揶揄されたりもしましたが、最近は他のJavaScriptフレームワークにもその思想の一部が反映されるようになって、メインストリームに近づきつつあるようです。 さて今回Facebookが、React Nativeを発表 & オープンソースとして公開して話題になっていますが、Tom Occhinoは React.js Conf 2015のキーノートスピーチで、「一度書けば、どのプラットフォームでもうまく動作する。」ではなく、「一度覚えれば、どのプラットフォーム向けにも書けるようになる。」ものであることを強調しています。 同社の開発メンバ

http://greensock.com/css-performance 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 GreenSockが、「アニメーションのパフォーマンスは、CSSが常に優れているというわけでない。」という観点からベンチマーク調査した結果を公表。それに対して、GoogleのPaul Irishが反論。詳細やりとりはサイトを確認していただければと思いますが、ポイントはコメント欄で交わされている結論かと。 Paul Irish 独立したtransformコントロールを必要とする場合、CSSのみのアプローチではelementのカウントが膨れ上がるので、JavaScriptの方が相当よい結果を残す。それ以外のケースでは、理想的な実装がされているという前提に立てば、両者のパフォーマンスは同

http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか？その障害がゆっくりと起きたらどうか？ システムをどのようにスムーズにデグレードさせることができるか？ システムは想定以上の負荷にどう対処するようになっているか？ 大きな障害が起き

http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers/answer/Jeff-Darcy? 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 スポーツにしろ、勉強にしろ、仕事にしろ、何をやるにもその特定の分野でトップ1%人は尊敬するほどすごいのですが、本人が長く続けつつ努力をしてきたことが垣間見えるので、なぜ優秀なのかというのが理解できる範囲。ただし、そのさらにトップ10%、いわゆる世の中でその分野のトップ0.1%の人というのは、すごすぎて、どうしてそうなれるのかが分からないと実感することがあります。議論している時に、数歩先の真理を理路整然と突然読み取って指摘されるような、驚くようなセンスを見せつけられる経験を数

シングルページアプリ向けの各フレームワークをGoogle Trendで比較したグラフがLars Eidnesのブログに掲載されてますが、AngularJSの伸びが他を圧倒しています。一方で、アーキテクチャ上の課題は、コミュニティの声もあり、かつ当事者である開発チームも認識していたところ。そして、それに対する答えとしては、バージョン2.0で大幅に書き直すという流れになっています。 AngularJS 2.0については、「野心的だが険しい道のり」というタイトルの記事がGuardianに掲載されてますが、 ES6の採用 Web Componentsとの親和性のアップ （双方向バインディングをどうするかまだ決まってないが）Reactの考え方に近づいてきている （1.3のサポートはしばらく平行して続くと発表されたが）本当にスムーズな移行を提供できるのか? がポイントだとSeb Ceveyはまとめてい

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のインライン化 レンダリングをブロックしないように、急ぎでないアセットの取

Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。 同社のAPIは現在、 エンドポイント: 106 バージョン: 65 APIクライアント: 6 ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。 1) ユーザが利用するバージョン情報の把握 ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で保管している。それ以降、ユーザ企業はバージョンのことを意識することなく、最初のバージョンのAPIを利用し続けることができるようにしている。ユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。 2) バージョンと機能の整合性 YAMLファイルでバージョンとその振舞いの情報

http://youtu.be/uwnjDXtJufs 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 44分前 コンポーネントベースのviewレイヤのライブラリであるReactを、実際に使ってみた感想についての発信が増えてきているので、まとめてみました。（4)はFluxの話も入ってます。） 1) Reactとは？ E4E Developer Conf 2014の講演でFacebookのBen Andersonは、Reactを採用しているサービスを挙げています。 Facebook / Instagram / GitHub (Atom) / Khan Academy (with Backbone.js) / Mozilla Firefox (for Paneis) / NY Times / Reddit (stor

https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿

https://www.youtube.com/watch?v=VkTCL6Nqm6Y 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 OSCON 2014におけるInstagramのWebチーム責任者であるPete Huntの講演。PeteはInstagramに異動する前は、FacebookのPhoto/Video/Product Infraチームに在籍。 今回は、InstagramのwebサイトInstagram.comにおいて、シングルページアプリの課題である最初の読込みスピードを上げるために、どのような工夫をしたかについて紹介してくれてます。 Instagram.comのJavaScriptファイルは、縮小化後で9.5MB & gzip圧縮後で2.5MB。そのサイズだと、一つのファイルにまとめ

http://thechangelog.com/128/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社のJustin Searlsが、the changelogのpodcastで、Lineman.jsについてのインタビューに応えています。 Linemanは、JavaScriptのフロントエンドアプリ開発におけるコマンドラインツール。AngularJS / Ember.js / Backbone.js などがフレームワーク、Grunt / Gulp がビルドタスクの自動化ツールとすると、Linemanは慣習 & 設定（convention & configuration）ツールという位置づけのようです。各フレームワークにおいて、アセットの構築、サーバのmock、ファイル変更時

http://engineeringblog.yelp.com/2014/08/announcing-pre-commit-yelps-multi-language-package-manager-for-pre-commit-hooks.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Yelpでは、コードレビュー前にgit hookを利用してコードのチェックをしていますが、 プロジェクトごとにhookのbashスクリプトをコピペ/修正するのが面倒。 lintツールなどを利用するには、プロジェクトで使っている開発言語以外の言語用のパッケージマネジャーでインストールしなくてはいけないケースがある。 nodeのプロジェクトで scss-lint（Rubyで書かれている。）を利用する際、プロジェク

http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 長期的な大規模プロジェクト、かつ修正頻度が高い場合は、DRYよりはメンテ性を最優先にしたCSSを書くべきという、Ben Frainの方法論です。長文ですが、よくまとまってると思います。 1) テクノロジーとツール プレプロセッサ 長期のプロジェクトにおいて重要なのは、テクノロジーではなく、何ができて、どう進めるかというアプローチ。 Sass / LESS / Stylus / Myth などどれでも、しっかり書かれていれば、必要なときにいつでも統合はできる。プレプロセッサは

http://benalman.com/news/2012/05/multiple-var-statements-javascript/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 まあ、好みの問題もあるので、嫌な人にとっては嫌なんでしょうが、、 JavaScriptで、例えば先頭で var をまとめて定義 & 値を代入する際に、 var foo = 1, bar = 2; でなく、 var foo = 1, var bar = 2; と、varを並べたほうが、メンテ性も見た目を揃えるにもよいのではないかという、Ben Almanの2年前のブログが最近いくつかtweetされてたので、チェックしてみました。 そもそも、 複数varを並べるのは無駄だし、初心者っぽい。 単独varの方が見た目がよい。

Pinterestは、サーバの一部を本番から外し順次アップデートするという方式でデプロイをしています。それが起因してページ全体を無駄にリロードさせている状況を改善するための取り組みを紹介しています。 背景 Pinterestのサイトでは、JavaScript + XHRにより、ページ内で必要なコンテンツだけが、クリックされた際に適宜更新されるようになっている。 ユーザが最初にPinterestのサイトにアクセスすると、サーバはブラウザに対しJavaScriptのバンドルを読込ませ、そのバンドルがサーバにあるソフトウェアのバージョンとの一致を確認する仕組み。 デプロイする際は、サーバの10%をオフラインにし、アップデート完了後、本番に戻すという作業を繰り返している。つまり、新しいバージョンのソフトを載せたサーバと古いものを載せたサーバが混在している状態になる。（Varnishの相対するバージ

http://blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 開発言語やフレームワークの比較は、参考になるところはありつつも、その結果、不愉快な気分になる人がいるわけですが、それを懸念して、「（これを読んだ人は、他人の）意見を読んでいるだけだと思い返してほしい。貴方にどうすべきだと言ってるのではなく、自分にもしくはチームのために何がよいかは自分で判断すべきこと。」と前置きして、Henrik Joretegが、JavaScriptフレームワークについて私見をシェアしています。 反対意見も併記しようと思ったのですが、TwitterやHNでの反応がまだないようなので、注目すべきコメ

https://www.youtube.com/watch?v=ZQ5_u8Lgvyk 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Casey MuratoriのGameTech Conference 2004での講演。 コードを再利用したいと皆言うけれども、いざ実践となるとなかなかうまくいかない。 ことの背景の解説とその解決策の方向性について、キャラクターアニメーションパッケージの開発を通じてCaseyが学んだことをシェアしてくれています。10年経っても変わらず、またゲーム以外の開発においても、当てはまることが多いかと。 インテグレーションのオプション あるコンポーネントをAPIを用意してゲームに組み込むインテグレーション作業と、その作業がどれだけゲームの完成に効果がある（ゲームプレイの完成とい

http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Harry Robertsがブログで、CSSのプロジェクトをうまくスケールさせるためには、詳細度の影響をうまく抑えて、メンテナンス性を高めることがポイントだと解説しています。 どれだけ思慮深くソースの順や継承関係を整理しても、詳細度がトリガーになった上書き起きると、それまでの努力が台無しになる。詳細度のタチが悪いのはオプトアウトできないこと。 であるが、その悪影響をうまくコントロールする策としては、 CSSにおいてセレクタとしてIDは使わないこと。クラスを使うことを上回るメリットはない。そもそも、IDでできることはクラスで