SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
「この〜を導入すると、なんとこうなりました！どうです？わかりやすいと思えませんか？」 - mizchi's blog
主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され
タッチタイピング矯正器としての無刻印キーボードが良いという話と、無刻印の辛い点 - mizchi's blog
これみて思い出した。 私はブラインドタッチが出来ない - はてな村定点観測所 僕も昔は右手のホームポジションが右に一個ずれてた我流で、たまに手元見ながらタイピングしちゃう癖があったんだけど、HHKB無刻印にしたら綺麗なフォームになってたので、ちゃんとタッチタイピングしたい人はHHKB無刻印使うといいと思う。 PFU Happy Hacking Keyboard Professional2 墨/無刻印 英語配列 USBキーボード 静電容量無接点 UNIX配列 WINDOWS/MAC両対応 ブラック PD-KB400BN 出版社/メーカー: PFU発売日: 2006/03/23メディア: Personal Computers クリック: 192回この商品を含むブログ (23件) を見る HHKB無刻印炭、たしか前職で @shishi4tw が使ってるのみてあーこれカッコイイと思って買ったんだけ
2時間縛りでd3.js挑戦してみた - mizchi's blog
何この記事 あんちべという人から無茶ぶりがきたので対応した mizchi、d3ブログ書いてくれた呑む— 3D円グラフ皆殺し (@AntiBayesian) 2014, 3月 2 @AntiBayesian D3まだ極めてないです— 高意識エネルギー (@mizchi) 2014, 3月 2 @mizchi 2時間やろう、早く極めたまえ— 3D円グラフ皆殺し (@AntiBayesian) 2014, 3月 2 @AntiBayesian おっしゃ待ってろ— 高意識エネルギー (@mizchi) 2014, 3月 2 前提 よく誤解されるんですが、D3.jsはグラフ描画ツールではなく、JavaScriptでSVGを生成するためのjQuery風DSLで、DSLとはいえかなりローレベルなライブラリです。SVGはベクタグラフィックスを生成する規格。ブラウザ上のSVGは、図形を書けるDOMであり、他
エンジニア Mac アプリ 環境 おすすめ - mizchi's blog
Macで捗るオススメのアプリひたすら書いてくわ : IT速報 が余りにも消化不良だったので書く。 (タイトル考えるの面倒臭かったのでワードサラダ風) homebrew入れる brewfileをつくる brew bundle おわり 以下、最近作った ~/brewfile です。デスクトップアプリもbrew caskから突っ込む。 もういろんなサイト巡ってアプリを入れて回る時代は終わったんだよ、爺さん tap phinze/homebrew-cask || true tap homebrew/versions|| true update || true install brew-cask || true install git || true install hg || true install ag || true install gist || true install gibo ||
巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
