技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選（新規開発のメモ書きシリーズ1）
新規開発したプロダクトについて ｢世の中に URL は出ているが、まだ正式公開していない｣という微妙な位置付けなのでプロダクト名と詳細は避けつつ述べます。短めの開発期間で急いでつくって、慌てて年末にβ版をリリースしたところです。 次の動きに向けてまったりしたり、Inside Frontend の開催に向けて四苦八苦しているところでメモ書きです。 このシリーズの他の記事はこちら。 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離 依存するパッケージの厳選 新しい技術、ライブラリを試すこと、それらを使って生産性の向上にチャレンジすることは必要です。とはいえ、程度が過ぎると逆に生産性を下げかねない
yahoo/fluxible による SPA + Server Rendering の概観
Single Page Application + Server Rendering yahoo/fluxible を使って、Single Page Application と Server Rendering の良いとこ取りのアーキテクチャを目指す。ある程度の複雑性と引き換えに、双方の利点で双方の欠点を打ち消し合うことができるため、全体的には良好なユーザーインタラクションを期待できる構成。 なぜ Single Page Application なのか 画面遷移時するたびにJavaScript/CSS のパースと評価をしなくて良くなる 画面遷移時のトランジションを柔軟に適用できる 画面遷移をまたがった実装が可能になる（あくまで可能になるだけ） なぜ Server Rendering するのか 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰
現場のプロが教えるHTML+CSSコーディングの最新常識 ー の読書感想文
「その書き方、古くない？」 東京きてから仲良くさせていただいている高梨ギンペイさんが共著でWeb制作系の本を出版されたということで、さっそく拝読しました。初見から「その書き方、古くない？」というオビの煽りが素晴らしいですね。 帯の煽りどおり、古い知識をいい感じにアップデートしてくれそうなコンテンツです。 HTML/CSS とその周辺知識について網羅 個々の内容はライトで読みやすい 随所にモダンなツールチェインの解説も入る アクセシビリティ・パフォーマンスとかもある 時々、急激に難解な分野が入る(!) HTML5と呼ばれた頃よりも前の時代(HTML4, XHTML!!)からのアップデートも意識された本書では、モダンなHTML/CSSの知識を、わりと基礎のほうからフォローされています。 かと思いきや、CSSアニメーションのところでGPUレンダリングの話が入ったり、総合格闘技っぽいパフォーマンス
ブラウザのPOSTリクエストは、リダイレクトさせるとGETに化ける？ ::ハブろぐ
POSTがGETになってる？ 前回のエントリーにもつながっている話ですが、ブラウザからフォームでPOSTされたものがリダイレクトされたときの挙動について。挙動が理解できると、化けるってのも失礼な表現なんですが。以下、化けた理由と、HTTP周りの実装の話をつらつらと。 普通のHTMLなフォームからPOST <form action="post_receiver" method="post" enctype="multipart/form-data"> <input type="file" name="imageFile" /> <input type="submit" value="画像をアップロードしてやんよ" /> </form> 上記のようなHTMLなフォームから、POSTした際にサーバー側でうまくPOSTデータを受け取れないことがありました。 echo $_SERVER['REQUE
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
