サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
大そうじへの備え
havelog.aho.mu
この記事は前作 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する に続き、とはいえ効率を含む開発生産性的なものと向き合わねばならないチームや組織に向けた3作目です。そろそろ開発生産性がゲシュタルト崩壊してきた。 前提、わりと普通な話を述べているつもりだが、円滑になりきれないチームでは普通ないし妥当に至るハードルが思いのほか高いと感じる今日この頃。 人的効率主義に対するアンチテーゼの補足編 安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する 開発成果を念頭に起きつつも、どこかで一定の効率が必要なことを疑う余地はない。チームや組織の中長期を俯瞰すると正面から成果に向き合えるタイミングばかりではないので、そ
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か？ 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
心機一転がんばります 車のサブスクを提供する KINTO やトヨタのモビリティビジネスのITを支える内製開発部隊である KINTOテクノロジーズ株式会社に6月1日付で入社しました。 通算4社目 ついに転職回数も3回を迎えて通算4社目に至りました。これまで経験した会社いずれとも異なった環境で、良い意味でギャップと新鮮さを味わいながら社内をキャッチアップしているところです。:) KINTOテクノロジーズという名前とは裏腹に組織全体としては KINTO 以外にもさまざまなモビリティビジネスに関わっており、さらに独自のチャレンジの機会もあってやれることが盛りだくさんの気配です。 KINTOテクノロジーズ株式会社に興味がある/よくわからないけど話を聞いてみたい等があれば @ahomu か任意の連絡手段でお気軽にコンタクトください。 入社したてですので語りはそこそこに取り急ぎのご報告でした。 みなさま
目次 開発生産性を掘り下げるサービスたち 生産性 = 産出量 / 投入量 生産性を向上させる3側面による整理 ①メソッド（生産方式や業務処理方法） ②パフォーマンス（能率や業務実施効率） ③ユーティライゼーション（計画や活用のうまさ加減） (余談) SPACE フレームワークについて 生産性関連データの可視化で何を見いだせるのか アウトカムの厳密な可視化は難しい 機能としてはアウトプットの可視化に比重が寄る 生産性の可視化を必要としないこともある 可視化された情報から何ができるのか アクティビティ傾向の変化や異常の発見 意思決定における再現性の担保 説明責任における透明性の担保 総じて、すべきでは無いこと 速度と量の回し車にしない 意味を見いだせない指標を運用しない どうぞご健康で！ 開発生産性を掘り下げるサービスたち 開発に関わるインテリジェンスを提供する SaaS には国内では私が勤め
｢なぜこんなに必要？｣ にうまく答えられなかった当時 当時の役員から組織の頭数に対して、そんな旨の問いを投げかけられたことがありました。ポジションの内訳や開発規模に対する"必要性"を中心に話したはずですが、わざわざ内製で安くない人件費を投じている文脈で期待される +α の成果に対して十分な説明を行うことはできなかったように思います。 技術畑でない役員と話すにあたっては当たり前ですが自社の経営目標とビジネス一般の理屈にチャネルを合わせて話をする必要があり、当時は自身にそれが求められていたことを改めて意識するタイミングでした。 相応の学習や技術の乗換をしていれば Tier 2 ソフトウェアエンジニアの価値が直ちに崩壊する可能性は今のところなさそうですが、作れます！使えます！以外で説明可能な「自身のバリューのテーマ性とキャリア」の獲得が市場価値の持続的な向上に不可欠であることの確信が深まります。
App Router でトラディショナルな動的 SSR 既存〜今後のコンポーネントの互換性を踏まえて React を前提とし、フレームワークの分散を抑制するため Next.js を選び、多少の冒険ではあったが App Router での開発にトライしています。 今後は現在 Ruby on Rails のモノリシックコードベースで展開されている複数プロダクトを分割し、それぞれを Next.js で水平展開し直していくイメージです。 で、まずは App Router のフルパワー（サバクラに渡る重厚なキャッシュ機構）を要しない、ログインする操作こそあれだページの9割9分が Server Components としてレンダリング可能な領域をリプレース中。 つまり // app/layout.js export const fetchCache = 'default-no-store'; expo
画面幅、メディアクエリに依存した要素の表示切り替え React + CSS Modules を使っている前提イメージ JSX 上で表示・非表示の分岐が明示されてほしい CSS を掘らないと分からないのは見通しが悪く感じる matchMedia() ベースの Hooks にすると SSR で難儀する 一貫性のためにサーバーサイドコードで頑張るのも億劫である 表示・非表示だけなら純粋な CSS で実現したい display: contents を使ってみた メディアクエリで display: none と block を切り替えれば良いという単純な話ではなく、親要素が Flexbox や Grid だった場合を想定する必要があるので、表示されている状態ではボックスモデル的に虚無になってほしい。 contents これらの要素は自身のために特定のボックスを生成しません。擬似ボックスやその子ボック
慎重な見積もりは苦しい 本来、どんぶり勘定の見積もりでも 6-7 割の精度はあるはず（きっと） ドメイン知識やコードベースをそれなりに掌握している必要はある 慎重に見積もりの精度を高めるのは責任を伴う約束のせい じゃあ最初から約束しなければいい 慎重に見積もってもどうせ事故るときは事故る とはいえステークホルダー向けに「いつまでに終わらせる」意志の表明は必要 意志を尊重し、目論見が外れても咎められないことが求められる 見積もりの心理的安全性ともいえる 正確な見積もりと約束に時間をかけるよりも、いつまでに終わらせるという意志力と、想定より伸びても咎めない寛大な心でいきたい — あほむ｜副業転職 Offers の overflow (@ahomu) September 8, 2023 見積もりと計画を捨て、約束を破れ 一般的に理性的な見積もりは遠大な計画になりやすい 責任と約束のために不明なバ
当記事における便宜上のティア定義 2022年3月ごろのメモ書きを清書？した記事なので時空が捻れている箇所があれば目を瞑っていただきたい。今や同様の論説を他でも見かけるようになっている気がする。 この記事ではソフトウェアエンジニアの市場価値および報酬について言及する。その上でシニアとかミドルとか曖昧にやり取りされるエンジニアのレベル像を以下にざっくり整理する。 Tier 1 職務経歴書やアウトプットが分かりやすく魅力的に映るクラスタ 就業年数や有力企業の在籍経験などを背景に特定領域における専門性や業務実績を獲得していることが多い 自発的な事業へのアジャストやリーダーシップの発揮も強く期待されやすい、されてしまうのだ... Tier 2 Tier 1 には及ばないが（分かりやすいトロフィーがないだけの場合も含む）即戦力なクラスタ 技術スタックに難がなければ多くの開発現場で一定のパフォーマンスを
迫り来る年の瀬に物欲を振りかえる まじめな振り返りをブログエントリにしたいなと思いつつ、無心で書けるラクなエントリに逃げるわたくし。 今年は大きな散財もなくつつましく暮らしたはず...。2017年を見返そうと思ったら2017年は書いてませんでした ^q^ PowerCore Fusion — モバイルバッテリー兼 USB 充電器 Anker の PowerCore Fusion 5000mAh は今年ぶっちぎりの使用頻度と活躍度です。コンセントに刺して USB 充電器として使えるだけでなく、本体がモバイルバッテリーにもなっているので一人二役のコンパクトさです。 これまで持ち歩いていた モバイルバッテリー本体 モバイルバッテリーを充電するための USB ケーブル コンセントに挿して使う USB 充電器 の3点の役割が PowerCore Fusion ひとつに集約されるので出張族としては荷物
Web ページの高速化セミナー WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」 - WCAN | Doorkeeper 先日、2018年9月15日にひっさびさに WCAN に登壇させていただいて Web パフォーマンスチューニング....のなかでもページロード速度の高速化を中心にセミナーとワークショップを行わせていただきました。 下記はそのときの資料です。今回は Web サイト制作者向けのセミナーとして企画したので、Web アプリ開発勢が好きそうなテクニカルな話はすべて割愛しています。 ウケが良かったような気がするネタ なにがウケるか読みがつかなかったので、とりあえず色々盛り込んでみました。会場では下記のあたりがウケが良かったような....気が...する。 格安 SIM の回線は、大手キャリアのプロパー回線と比べる
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
正式リリースに向けての開発で表面化した不都合 以前、アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）で紹介したように、SSR で生成した HTML を CDN ( Fastly ) でキャッシュできるように「ユーザー依存情報はクライアントサイドで非同期に取り扱うというアプローチ」をとっていました。それによって発生していた不都合と解決に関する追加情報です。 ユーザー依存情報が非同期でレイアウトされる問題 ユーザー依存情報が非同期で解決されるということは、そのような情報を扱うコンポーネントの矩形は Web ページが一度レンダリングされたあとにレイアウトされます。つまりこの記事でも紹介されたところの「ガタンッ」的なユーザー体験が生じます。 ログインと非ログインが、全く同じサイズの矩形を確保するようなビジュアルデザインになってい
新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ
流行りの monorepo 風味と DDD 風味？ 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web
たくさんある道具をどのように組み合わせるか 今回はコード設計編のつもりでしたが、ビルド周りを先にまとめることにしました。主にパフォーマンス上の都合ですが、心がけたポイントは次の点です。 画一的なバンドルではなく、適切なバンドルを選択的に配信できるようにする 適当な粒度で Code Splitting できるようにする ひとつのツールに何でもかんでもやらせない（ webpack、お前のことだよ！） ビルドのパイプラインを短く、シンプルに済ませる（できることを全てやろうとしない） タスクランナーは前回述べた通り make を利用しています。同僚が使っているのを見てパクりましたが Self-Documented Makefile の手法が、タスク名忘れに優しくてよかったです。 npm run したら npm scripts が一覧で出てくるのと似たようなやつです。 このシリーズの他の記事はこちら
新規開発したプロダクトについて ｢世の中に URL は出ているが、まだ正式公開していない｣という微妙な位置付けなのでプロダクト名と詳細は避けつつ述べます。短めの開発期間で急いでつくって、慌てて年末にβ版をリリースしたところです。 次の動きに向けてまったりしたり、Inside Frontend の開催に向けて四苦八苦しているところでメモ書きです。 このシリーズの他の記事はこちら。 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離 依存するパッケージの厳選 新しい技術、ライブラリを試すこと、それらを使って生産性の向上にチャレンジすることは必要です。とはいえ、程度が過ぎると逆に生産性を下げかねない
本日は Web ページのパフォーマンスを向上させるためのノウハウをギチギチに詰め込んだ書籍のご案内です。 超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる（Amazon.co.jp） 本書の目次（技術評論社 Web サイト） はじめに（技術評論社 Web サイト） @1000ch との共著で進めていましたが、いよいよ 2017年11月23日に発売されます。紙の書籍は Amazon.co.jp ですでに予約注文の受付が開始されています。 また、Gihyo Digital Publishing で電子書籍版も同日発売予定となっていますが、あくまで予定です。そんなにお待たせすることはないと思います。 ハッシュタグは #超速本 または #チョッパヤ本 です。好きなほうをお使いください!! 本書の構成 本書の実態は、以前に WEB+DB PRESS で連載していた「Webフロ
HTML + CSS & JavaScript が式に見えて、どこかをカッコで括らないと落ち着きがないのですが、私だけでしょうか...。 さておき、インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンのご紹介です。 恐れ多くもカバー裏に推薦コメントを寄せさせていただいたご縁もあり、恵贈賜りました。 コーディング Web アクセシビリティに続いて Heydon Pickering 氏の訳書です。原著の軽妙な語り口とユニークすぎるジョークの訳に苦労するような趣もあったようですが、読み手としては軽く読めるのでわりと好きです。 推薦コメント ≒ 読書感想文 一見して見慣れない「インクルーシブ」という主題だが、フロントエンド開発の本質をよくにとらえている。利用環境がどのような条件下にあっても使用に耐えうる堅牢な実装は、サービスやコンテン
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
3. その他 SPA にありがちな懸念点の検討 書き終わって読み直すに、いくつかの方法論は浮かぶが思った以上にやってみねぇと分からんという感じです。 ここでは SPA + SSR における完全な HTML を生成するサーバーサイドと、SPA + BFF (Backend For Frontend) くらいのゆるやかなサーバーサイドを別のアプローチとします。どのみち完全に静的な HTML と API サーバだけで複雑な SPA を成り立たせるのは無理があるので BFF の支援は前提に入ります。 また、SPA + SSR のダルさの根源は node の CPU ぶん回し対策や、キャッシュサーバーの管理などを伴うキャッシュストラテジーの煩雑性と定義します。単純に SPA + SSR を実現するだけなら道具も成熟してきているので、さほど難しくはなくなってきているという扱いにしておきます。 3-1.
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル（App Shell）アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
時間依存メディアの概要と対応方針の草稿 本記事は WCAG 2.0 A (シングルエー) に準拠する場合を想定して、時間依存メディアに関する内容の要約と対応方針の力加減をまとめたものです。 ようは時間依存メディアの項を読むのが苦しいのでマイルドにしてみた結果です。対応方針ほか諸々の内容はツッコミを受けて逐次修正される可能性があります。 対象 「時間依存メディア = 音声または映像」 であり、同時に 「同期したメディア = 音声付きの映像（動画）」 と読み替えて概ね問題ない。 「時間依存メディア」は、時間の経過に従って再生中の内容が連続的に変化する「音声、映像または両方を含むメディア全般」を指す。また、仕様書の中に登場する「同期したメディア」は、特に「音声と映像の両方を含むメディア（音声と動画が同期して変化するメディア）」を指す。 分類と必要な対応 音声しか含まないメディア → 書き起こしテ
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
物欲というか実用品というか 2015年に買って良かったと思ったもの ::ハブろぐ に引き続き、2016年の買い物を晒していきたいと思います。さほど物欲が強いほうではないつもりですが、今年は後半になってからまとまった投資を行いました。 作業環境 いかんせん外部ディスプレイに繋ぐのが面倒というか、どうせ Spaces で仮想デスクトップを切り替えるからなぁ、という気持ちがあってディスプレイなしで、MacBook Pro 15インチの画面をそのまま活かすスタイルです。 これがなかなかどうして。揃えたのは次に示す3つのアイテムだけですが、キーボードの打鍵音が騒々しい以外は非常に快適に使えています。HHKB って、打鍵のエネルギー少なめで良いですね。 打鍵音がうるさいキーボード キーボードは無刻印ではありませんが、墨色のUS配列にしました。ちょっと高さが気になるなぁと思っていたところ、木製のパームレ
アクセシビリティを担保するプロセス作り この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。 UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。 ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent C
捉え方と考えの整理 Web アプリケーション開発屋として Web アクセシビリティをどのように捉え、どのように付き合っていくべきかの考えを書いてみます。昨今の Web サービスにおいてアクセシビリティは Web の領域だけで果たされるものではなくアプリとかも含めてだよね、という向きはありますが話が広がりすぎるので今回は Web の中に留めます。 自分が Web におけるアクセシビリティとは何なのか？と考えるときは「多様なクライアント環境に対する配慮」と「制限をもつユーザーに対する配慮」の2面で捉えています。前者はあくまで Web に関する技術的な配慮であり、後者は Web に限らず包括的なアクセシビリティとしての配慮またはその社会的要請です。 多様なクライアント環境や Web に対するニーズへの配慮 Web ページを参照できるユーザーエージェントやデバイスの数が多いのは言うまでもなく、これ
フレーム描画のタイミング制御モデル 今更 requestAnimationFrame() だなんて Can I use を見ても IE 10 ですら実装していて、世界の 9 割以上で動作しうるカバレッジなわけですが改めて setTimeout() との違いを表現しうるサンプルをこさえてました。 それぞれの仕様の詳細や挙動についてはそれこそ今更なのでググっていただくとして、この記事ではサンプルについて曖昧な説明を添えていきます。 CodePen - setTimeout vs requestAnimationFrame (with CSS Transitions) See the Pen setTimeout vs requestAnimationFrame (with CSS Transitions) by Ayumu Sato (@ahomu) on CodePen. 比較のポイントとシ
ある要素内の状態による外界への影響を封じ込めて最適化を促す CSS Containment Module で定義される contain プロパティは will-change と同じようにブラウザが処理を最適化するために開発者から提供できるユーザーエージェント向けヒントとして機能します。 ヒントの目的はcontain の対象要素が親兄弟に影響を及ばさない独立した部分木であることを宣言し、各種の影響を contain の対象要素の中に封じ込めることです。 使うときは contain プロパティに既定の値として用意された size | layout | style | paint | content | strict のいずれかを指定します。content と strict は複合指定のエイリアスなので、本文では size layout style paint の4つについて個々の説明をします。
次のページ
このページを最初にブックマークしてみませんか？
『ハブろぐ - havelog.ayumusato.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
