開発生産性のために効率が必要なら、ヒトよりもシステムやプロセスを観察したい
この記事は前作 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する に続き、とはいえ効率を含む開発生産性的なものと向き合わねばならないチームや組織に向けた3作目です。そろそろ開発生産性がゲシュタルト崩壊してきた。 前提、わりと普通な話を述べているつもりだが、円滑になりきれないチームでは普通ないし妥当に至るハードルが思いのほか高いと感じる今日この頃。 人的効率主義に対するアンチテーゼの補足編 安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する 開発成果を念頭に起きつつも、どこかで一定の効率が必要なことを疑う余地はない。チームや組織の中長期を俯瞰すると正面から成果に向き合えるタイミングばかりではないので、そ
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
ES6 class で Component 書いたら react-devtools で Unknown になったので対応した
react-devtools で Unknown がでる場合 タイトル長いですね。ともかく、ES6 class で Component を書いたら react-devtools で Unknown になってしまった話。 facebook/react-devtools について、無いと死んでしまう！ってほどの有り難みは感じていないのですが、いざ開いたときに Unknown だと残念なので対応しました。 辛い見た目 export default class MyComponent extends React.Component {} のように書いたら、コンポーネント名が取得できず Unknown だらけになりました。 <Top Level> <Unknown> <div> <h1>Hello World!</h1> <Unknown index="0" tabs="..."></Unknown
勉強会資料シェア Getting Started with RequireJS
げりんぐすたーてっど うぃず りくわぃあーじぇーぇす ということで、社内勉強会でRequireJSの入門資料をこさえたのでシェア。 利用したデモファイルセット http://d.aho.mu/S4mh なんとなくRequireJSが動くセットです。スライド中のr.jsによるビルドコマンドや、gruntを利用したビルドも試せるようになっています。 おさえるべき要点 いくつかの要点だけ記事内に文字列でおこしておきまする。 モジュラーと依存関係 Webサイト → Webアプリ への流れが明確になってきてフロントエンドが複雑化してきている今、1つのJSファイルにつらつらとCSSのようなノリで書き連ねる時代は終わりつつあります。 ParisJS #10 : RequireJS このあたりについては、上記の素晴らしいスライドから、Figureを拝借しました。個々のJavaScriptの粒度が揃えてモジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
