AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり - Kengo's blog
Accelerate 第1版（以下単にAccelerateと呼ぶ）はDevOpsに関するトレンドを抑えるうえで基本となる本なのですが、もはや古く最新の知見が書いてあるとは言えません。State of DevOpsは毎年アップデートされているのですがコンテキストを丁寧には抑えてくれず、背景を含めて読み解くのが難しいという印象があります。どうもAccelerate 第2版がそろそろ出るらしいんですが、とりあえず現時点での自分の理解をまとめておきます。 端的に言うと、これらは安定したソフトウェアを高速に顧客に提供できる良い開発チームの特徴を踏まえ、皆さんの組織で再現可能にするための研究であり指針です。当然「良い開発チームがあれば常に良い問題解決ができる」というわけでも「ここで定義された良さが組織問わず普遍的である」というわけでもありませんが、顧客の課題に立ち向かうための組織設計において良い仮説を
プログラミング言語が抱える課題を解決するには言語を乗り換えるのが一番いい、かもしれない - Kengo's blog
この記事は集まれKotlin好き！Kotlin愛好会 vol.47の懇親会でちょっと触れた内容を、膨らましてブログ用にまとめ直したものです。 注意点として、Java用静的解析OSSの開発保守を長年やってきたJavaプログラマがKotlinに乗り換えて1年経ったころに書いている、という強力なコンテキストがあります。また「何十年前の話をしてんの？」という部分が多く存在しますが見逃してください 🙇♂️ プログラミング言語の成長はすべてを解決する どんなプログラミング言語にも固有の問題は必ずあります。私が一番長く書いてきたプログラミング言語であるJavaでも、いくつかの課題が指摘されてきました： 不要な同期を取りすぎている（StringBuffer, Hashtable, Vectorなど） シリアライズ・デシリアライズが遅い（Serializableインタフェース） コレクションにどのような
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
2022年10月1日に開催された #postdev での発表です
オブジェクト指向か関数型か、という話題に私達はどう接するべきか - Kengo's blog
私がコードを書くときには「オブジェクト指向でいくか、それとも関数型か？」みたいなことはほとんど気にしていません。特にオブジェクト指向については人によって定義から違うこともままあるため、この手の議論がとても遠回りになることも多いと感じます。 ただきしださんのLT資料を拝見して、もしかしたらまだ需要があるのかなということで、この話題にどう接するべきか考えていることを書いてみます。 どう書くべきかはコンテキスト次第 結論から書くと、どのようにコードを書くべきかはチームや解決したい課題、利用言語や既存資産などのコンテキストによって変わります。 ので「何がオワコンでこれからは何が来る」みたいな議論は、チーム内という限られたスコープでのみ有効なはずです。 チームよりも広い場で議論する場合は、「どういったコンテキストにおいてどのような書き方をするか」のように若干抽象的なテーマが適切でしょう。 言い換える
勝手を知らないプロジェクトにPull Requestを送るときに気にしていること - Kengo's blog
初心者向けのPull Request（PR）作成方法はopensource.guideをはじめとして数多く見るのですが、もうちょっと突っ込んだというか中級的な内容の記事を読みたかったので自分で書きます。題材として主に直近で書いた大きめの機能追加用PRを使っています： github.com 修正や新機能を入れる利点を明確に伝える 何かを提案する場合、その背景には必ず動機となる利点があるはずです。これはとても単純に伝えられることもあれば、テストやグラフを作成しないと伝わりにくいものもあります。 今回の変更では、GitHub Actions workflowの定義ファイル簡素化とパフォーマンス改善が利点でした。定義ファイルが簡素化されることはドキュメントで簡単に伝えられますが、パフォーマンスは測定しなければわかりません。よってパフォーマンス検証用のリポジトリを作成し測定を行うことで、ビルド時間が
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
考察：Reactive Workflowが生まれた背景とその狙い - Kengo's blog
人に説明するのがスムーズにできなさそうなので、理論武装というか順序立てて話すためにこの記事をまとめる。 対象 ブラウザから利用するマルチプラットフォーム向けウェブアプリケーションの開発 モバイルのネイティブアプリ開発は含まない（知らないので） 利用言語はJava, JavaScript/TypeScriptを想定するが、特に言語に依存しない認識 開発経験はあるが、情報や経験が少なくて「よりよいプロダクト開発」の理想が描けない方への一助として作成 TL;DR 状況やベストプラクティスが目まぐるしく変わる現代において、すぐに変化できるソフトウェアを保つこと・ヒトの手をできるだけ空けることが重要。 かつてIaaSがAPIを提供し環境管理の多くを自動化したように、各種サービスがAPIやWebhookを通じてDevelopment Workflowの多くを自動化してきている。 多くの視点や知見を活か
Generative Team Design
There is a lot of talk recently about the importance of psychological safety in relation to teams and innovation. This talk is largely stemming, it seems, from this NYTimes article covering new research from a team at Google. While I think it is wonderful that people are starting to think and talk about the importance of psychological safety and indeed empathy, there is more to these cultural prac
Webアプリエンジニアに贈る アプリケーション開発におけるサーバーレス流の考え方 / The concept of serverless in application development
昨今、アプリケーションをつくるのに、様々な手段があります。「フルサーバーレス」はその一つで、マネージドサービスを駆使し効率的にアプリケーション開発を行うことができます。とはいえ、「アプリ開発」とひとことでいっても、必要な作業は多岐に渡ります。本セッションでは、Amazon EC2 に Play Framework + Scala で Webアプリ を構築する流れを比較対象の例にとり、サーバーレスで開発する場合の「考え方」を話します。言語や実装パターンの話よりも、典型的なWebアプリの開発手法がサーバーレスにおいても適用できるのか、またはまったく考え方を変えなければいけないのか、という議論が焦点です。
Gaijin Engineer in Tokyo
Being a foreign software engineer in Tokyo has its ups and downs. If you work in a company of foreigners you’re mostly shielded from the experience, but if you work in an actual Japanese company there’s going to be some things that will shock you, some things that will amuse you, and doubtless many things that will frustrate you. This is a run-down of my own personal experiences. As with anything,
技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（前編）。デブサミ2018 － Publickey
最近の立ち位置としてはライオンと一緒にされていまして、テストを書いていないプルリクエストとかに対して、却下の代わりにこの画像が張られるみたいな形で、一種の恫喝の代わりに使われています。 が、本人はきわめてジェントルな人で、いましゃべってるところを見て、このライオンとはキャラが違うなとお感じになっていただければ嬉しいです。 ついて行くべき変化とスルーしていい変化 昨今の技術の現場でよくあるのは、フロントエンド疲れ。JavaScriptの新しいフレームワークや、開発方法論とか、そういうのがどんどん登場して、また新しいものが出てきたと。 2年前に標準とされていたものがすっかり過去のものになってしまっていて、Gruntはどこに行ってしまったんだとか、Backbone.jsはどこに行ってしまったんだとか。 そうした変化に追いつけずに、疲れてしまうわけです。 かと思えば、一種の限界集落。よく言えば安定
技術者は構想・利益なき繁忙に陥っていないか 意味のない忙しさに…｜超える技術｜日経BizGate
本当に意味のある忙しさなのか 技術者はとにかく忙しい。技術開発競争に明け暮れて、目の前にある課題を一刻も早く解決しようとサービス残業も厭わず働きに働いている。上司に指示されているわけでもないのに、土日も自主的に出勤して仕事に没頭する。 そうした苦労の末にようやく開発した製品を出荷してそれで終わりかと思いきや、そうは問屋がおろさない。市場に出してから予期せぬ問題が発生する。それが技術上の問題であれば、何はさておき開発者自身が現場に出向いて問題解決にあたらなければならない。本来であれば、技術サポート部隊に引き継ぐべき仕事であるが、技術の粋を集めた新製品では、開発者自身が現場に駆けつけないと埒があかない場合も多い。次の開発をかかえながら、現場のトラブルにも対応しなければならない技術者は、まさに体がいくつあっても足りないほどだ。 しかし、こうした忙しさは果たして本当に意味のある忙しさなのであろうか
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
Agile and DevOps の歴史をチェリーピック
Developer Productivity Survey
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について // Speaker Deck
How to Write a Git Commit Message
Cloud Monitoring as a Service | Datadog
entr(1) - Run arbitrary commands when files change