リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近

NewsPicksの広告配信システム（アドサーバー）を構築した際に高速に処理するためにアーキテクチャや設計上工夫したポイントの説明資料です。

はじめに ReduxはSingle Store、immutableなState、副作用のないReducerという３つの原則を掲げたFluxフレームワークです。しかし他のフレームワークと違って提供しているものは最小限で、とてもフルスタックとは言えない薄さです。そのためすべてにおいて定番と言える書き方が定まっているわけでもなく、どうしようか迷ってしまうことも少なくありません。その筆頭とも言えるのが 非同期処理 の扱いです。コミュニティでは今でもさまざまな方向に模索が続いていますが、よく使われているものだとredux-thunk、redux-promiseあたりでしょうか。Reduxに限定しないのであればreact-side-effectというものもあります。こちらはTwitterのモバイルウェブ版で使われていますね。どれを使っても非同期処理が可能になりますが、それはあくまで道具であって、設計の

初心者に最初にぶち当たるのが『環境構築』という大きな壁なんですよね。そこで何割の人がスタートラインにすら立てずに挫折するだろうか…5割は超えるかもしれない…— ビタワン@社畜ちゃん②巻2/27発売予定 (@vitaone_) 2017年2月5日 環境構築が壁で、楽しい（かどうかは人によるが）プログラミングにたどり着けなくてモチベーションが、というのはわかるが、環境構築を経験してその辺の洞察身につけてもらわないと現場で困る、というような話もあって、二ヶ月速習でiOSエンジニア、みたいな講習はその視点欠けててダメ— 現場の声 (@mizchi) 2017年2月5日 よほどよくできた環境でもない限り、何作ろうとしても初動でうまいこといくケースが少ないので、それを解決するための勘と体力は絶対に必要なんだよなー— 現場の声 (@mizchi) 2017年2月5日 僕も完全独学でプログラミング始めたの