Webアプリケーションエンジニアの id:shimobayashi です。 はてなでは開発プロセス改善などに関心のあるスタッフが集まる「すくすく開発会」*1があります。この記事では、すくすく開発会のこれまでと今後について紹介します。 すくすく開発会とは 活動事例: プロジェクトテンプレート講義 問題 解決策 結果 すくすく開発会の今後 この記事のまとめ すくすく開発会とは 開発プロセス改善などについて関心のあるスタッフが集まる有志集団で、すくすく開発会の「すく」はソフトウェア開発手法のスクラムを由来としています。 元々は各チームの開発プロセス改善を行っていたスタッフの情報交換やお悩み相談をするための場だったのですが、活動を続けるにつれてはてなの開発プロセス改善も行うようになりました。 定例会の実施が活動の中心で、毎週30分希望者が集まってお互いの困りごとを相談しあってチームの外からアドバイ

MIDAS TECH STUDY #2

モデリングの学び方：座談会 - connpassを見たよメモです。ディスカッション形式だったので、話の流れになぞらえてまとめていきます。 本日の話し手 この会でメインで喋られていたのは以下の方々 増田さん かとじゅんさん ミノ駆動さん hirodragonさん 藤岡さん 原田さん 高崎さん 本日の趣旨説明と増田さんの考えるモデリングに関して まずは下記の資料を使いながら今日の催しの趣旨説明と増田さんの考えるモデリングに関しての話があった。 speakerdeck.com 上記の資料にもあるが以下の話が冒頭で行われた 今回の話し手の属性に関しての話(共通的な部分もありつつも自社サービスを持つ人たち3人と、受託開発を主に行う人たち3人という構成) まずは前提の話としての増田さんのモデリングの考え方のダイジェスト説明 効果的なモデリングの考え方（要点をうまく表現する名前を見つける、認知不可の軽減

渡辺幸三氏のデータモデル大全を読みました。 業務システムを扱うエンジニアであれば必読と言える書なのでぜひ読んでみてください。 ドメイン駆動設計に関する課題感 さて、これを読みながらここ数年ドメイン駆動設計に感じていた課題を言語化してみました。 それは、「ドメイン駆動設計で語られるモデリングの領域がプログラミングに関するものに限定されすぎている」という点です。 これは「データの入出力[1]はドメインの主要な関心事ではない」というような主張にみられます。 確かにデータの入出力に関心を払わなければプログラミングに関心事を集中できます。 しかし、それはデータモデル大全の中で指摘しているようなプロセス中心のあり方という指摘そのものだと感じました。 コアドメインに集中する エリック・エヴァンスのドメイン駆動設計の中では「コアドメイン」に集中することの重要さを説いています。 確かに、事業にとって事業価値

Fastly の導入を検討している。検討しているだけで、導入していないので、参考にならないかもしれないし、間違っているかもしれないが、メモ。 動機 Varnish を使っていて、最初は Varnish の冗長化をしたい！だった。 まあそうなるよねえ。で、Fastly！となった。 ちなみに、Varnish を使ってる理由としては、以前も Jamstack を検討する - ゆーすけべー日記 Varnish で Stale-While-Revalidate を実現する - ゆーすけべー日記 で触れたとおり、 なるべく手間手前で、なるべく少ない箇所でキャッシュしたいからである。 Fastly でできること・したいこと Fastly でできることはたくさんあるので、その中でもしたいことを列挙。リバースプロキシ、ロードバランサの機能も含むのが便利。特に、パスごとに制御できる。なので、とあるパスはキャッ

うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ

IT系に身を置いていると、つい新しい知識ばかりを追いかけがちになるけど、CS的な基礎知識や、Linuxのコマンドとかの（もちろんソラでコマンド10個のオプションを言える必要は、無い)も当然大事なわけです。というか、土台となる知識が無いと、新しい知識がちゃんと身につきません。 だけど、普段使わない、手を動かさない分野のスキルはどんどん忘れていきます。歳をとると加速度的に忘れていきます。 そしてヤバいのは、分かっていることと、分かっていないこと、できること、できないことの区別がつかなくなることです。 人は分かる範囲でしか物事を理解しないので、「分かっていないことを知る」という行為を行なって「分かる範囲」を広げる、または最低でも維持する営みを続けていかないとどんどん判断する時に必要な材料が狭まっていきます。 Java 1.5の知識で、Java17時代の判断はできないですよね、10倍以上違うんだか

はじめに エンジニアリングマネージャーとは? メンバーのサポート・育成・評価 メンバーの状態観察 目標設定・人事評価 後進の育成 日常の労務管理 開発 プロダクトマネジメント エンジニアリングのリーダーシップ 採用・採用広報・アドバイザーの招聘 採用 採用広報 アドバイザーの招聘 他社との情報交換 終わりに はじめに 今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。 私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が

【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle

CI/CD Conference 2021 で使用したスライドです。 S3 オブジェクトを不必要に公開してしまったり、あるいは遮断されるべきネットワークが繋がってしまったりといったセキュリティ上の設定ミスは、可能な限り避けたいものです。 このようなインフラ層に対するテストを従来の CI/CD の一部として組み込む場合、「個別の設定項目が条件を満たすことを確認する」または「実際にデプロイした環境に対してアクセスしてみる」といった形でテストを行うことが一般的でしょう。 しかしセキュリティ設定には、「複数の設定項目が絡み合った結果、最終的なアクセス可否が定まる」かつ「実際にデプロイする前に影響範囲を知りたい」といった要求があり、上にあげたテストの形式とはあまり相性が良くないのが事実です。 この問題に対して有効な手法の一つが Automated Reasoning です。Automated Rea

こんにちは、サーバーサイドエンジニアの サイトウ (@gamu1012) です。 今回はエキサイト社とRadiotalk社の合同で行っている輪読会について紹介します。 輪読会とは 輪読会 人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。 Weblio辞書より引用 我々が行っている輪読会は下記の特徴があります。 全員が本を購入 章ごとに行う 事前に該当章を全員が読んでくる 議論中心 週に1回1時間程度 誰とやっているか エキサイト社とRadiotalk社のエンジニア合同でやっており、現在は8人で進めています。 年次は新卒入社1年目から中堅まで、専門領域や担当サービスなどもバラバラです。 本を選ぶ 上述のとおり、メンバーは領域、経