『RustによるWebアプリケーション開発 設計からリリース・運用まで』という本を共著で書きました - Don't Repeat Yourself
RustのWebアプリケーション開発に関する書籍を共著で執筆しました。1年くらい執筆していましたが、出版時期などが定まってきたので内容の紹介を込めて告知の記事を書きます。9/26刊行予定です。予約よろしくお願いします。 RustによるWebアプリケーション開発 ↓AmazonのURL（アフィリエイトなし） www.amazon.co.jp 数年前に書籍を執筆した際に、「次はWebアプリケーションの実装に関する本を書きたい」と記事に書き残していたのを今見つけたのですが、有言実行できたようです。 どんな本か？ Rustってバックエンド開発に向いてるの？ 著者について 目次とトピックの簡単な紹介 はじめに 第1章 本書で開発するアプリケーション 第2章 開発環境の構築 第3章 最小構成アプリケーションの実装 第4章 蔵書管理サーバーアプリケーションの設計 第5章 蔵書管理サーバーの実装 第6章
個人開発でもADR （アーキテクチャデシジョンレコード）を書くことの利点 - laiso
起業なのか請負開発か趣味のプロジェクト（ペットプロジェクト）かによって状況は異なりますが「私のチームの開発者は私１人だけです」という個人開発においても、ADRは有効なツールとなりえます。 ADRとは何か？ ADR（アーキテクチャデシジョンレコード）は、ソフトウェアアーキテクチャにおける重要な設計判断とその根拠、影響、関係する検討事項などを記録した文書です。 一見、現代的な響きですが、その実態はシステム設計ドキュメントの一部です。 "ADR"で検索すると真っ先にヒットするアーキテクチャの入門書『Design It! ―プログラマーのためのアーキテクティング入門』では、ADRは「アーキテクチャ手法に対する開発者寄りのアプローチ」と説明されており、アーキテクトと開発者自身がアーキテクチャに関する意思決定を記録し、共有するための手法として位置づけられています。 アーキテクチャデシジョンレコード（A
プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog
カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上（複数スプリントにまたがるもの）の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください！」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ
「目標」を使って人やチームを元気にしよう────『アジャイルチームによる目標づくりガイドブック』の著者に聞く。
「目標」を使って人やチームを元気にしよう────『アジャイルチームによる目標づくりガイドブック』の著者に聞く。 仕事の「目標」は、どこへ向かって走れば良いかを示す地図のようなもの。 しかし、あまり良くない「目標」が設定されてしまうと、「この仕事に意味はあるの？」という疑念が生まれたり、仕事のコミュニケーションに齟齬が生まれてしまう場合もあるように感じます。 そこで今回は、『アジャイルチームによる目標づくりガイドブック』の著者である、株式会社カケハシのいくお (小田中 育生)さんに「人やチームを元気にする目標設定」についてお話をお聞きしました。 『アジャイルチームによる目標づくりガイドブック』著者、株式会社カケハシ エンジニアリングマネージャー。 2009年に株式会社ナビタイムジャパン入社。研究開発部門に配属。プロダクトや開発プロセスのカイゼンを推し進め、アジャイルとの出会いから社内でスクラ
コードレビュー開発者ガイド
コードレビュー開発者ガイド はじめに コードレビューとは、コードの作成者以外の人がコードを調べるプロセスです。 Google ではコードとプロダクトの品質を維持するためにコードレビューを実施しています。 このドキュメントは Google のコードレビューのプロセスとポリシーに関する正規の解説です。 このページでは私達のコードレビュープロセスを概観します。このガイドはさらに二つのドキュメントに分けられます。 コードレビューの仕方: コードレビュアーのための詳細なガイド CL 作成者のガイド: CL をレビューしてもらう開発者のための詳細なガイド コードレビュアーはどんな観点でレビューすべきか？ コードレビューは次の観点で見るべきです。 設計: コードはうまく設計され、そのシステムにとって適切か？ 機能性: コードは作成者の意図通りに動作するか？ユーザーにとってコードの挙動は適切か？ 複雑さ:
Go製アプリケーション/ライブラリにおけるメンテナンス性を重視したGoのバージョン管理戦略 - Diary of a Perpetual Student
2024-08-28 GOTOOLCHAIN=auto時にはtoolchainディレクティブに指定したものより新しいGoがインストールされていても戻るわけではないという話を追記しました。 Go言語では半年に1回メジャーリリース（マイナーバージョンの更新）がやってきます。ちょうどこの8月にGo 1.23がリリースされたばかりです。Go言語のメジャーリリースは最新2つ分までサポートされるポリシーであることがhttps://go.dev/doc/devel/releaseに書かれています。現在であればGo 1.23やGo 1.22はサポートされており、Go 1.21はサポートが切れているということです。 また、サポートされているバージョンでは、不定期でマイナーリリース（パッチバージョンの更新）がやってきます。バグ修正や脆弱性対応がメインですね。 Goがリリースされると、Goでアプリケーションを作
Terraform担当大臣 - laiso
“Platform Engineering”という私的よく見かけるが意味を調べたことのない用語No.1のトピックについて書かれた本がO'Reillyからearly releaseされているので読んでる。まだ第一部しか公開されてない。 learning.oreilly.com その中に出てくるアプリケーションチームがTerraformコードを管理することで起きがちな問題について共感したので紹介する アプリケーションエンジニアリングチームがIaaSクラウドのあらゆるものを求めるようになったとき、多くの企業は、各チームに独自のクラウドインフラストラクチャを独自の構成でプロビジョニングする権限と責任を与えることが、摩擦の少ない方法だと判断しました。 実際には、これは、構成管理とインフラストラクチャプロビジョニングに精通した、兼業のクラウドエンジニアリングチームになることを意味していました。 繰り返
コントリビュートで沢山の人が救われる。mattn氏が語る、好循環を実現するアウトプット活動の仕組み
コントリビュートで沢山の人が救われる。mattn氏が語る、好循環を実現するアウトプット活動の仕組み 2024年8月6日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS（オープンソースソフトウェア）の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023年 GitHub Stars。著書に『みんなのGo言語』（2016年、2019年に改訂2版、技術評論社、共著）、『Go 言語プログラミングエッセンス』（2023年、技術評論社、単著）がある。関西在住。 X:@mattn_jp GitHub 前回はアウトプットのためのお題選びに際して、巷のエンジニアがよく選びがちな TODO アプリについてお話させていただきました。 いった
技術顧問の道（１）技術顧問を引き受けるまで｜コープさっぽろDX
はじめまして。株式会社えにしテックの島田と申します。 ご縁があって、2022年末からコープさっぽろデジタル推進本部の技術顧問を務めています。 技術顧問をすることになった経緯や今何をやっているかを書いてほしいという話を、コープさっぽろDX(note)の担当をしているかわぐちさんから受け、2回にわけて、そのあたりのことを書かせていただきます。 1回目となるこの記事では、技術顧問を引き受けるまでと、引き受けるにあたって考えたことについて記述します。 ポイント・ステージ制度の統合プロジェクトの技術支援コープさっぽろの仕事に携わらせていただいたのは、ポイント・ステージ制度の統合プロジェクト（以降、ポイント統合プロジェクト）からです。 「オールコープ」を目指して。ポイント・ステージ制度の統合への道のりとこれから プロジェクトに加わったのは、上記記事の林崎さんと同じくらいのタイミングで、2021年11月
「IT業界の開発体制いろいろ」の図解が興味深い→「開発の形は十人十色」「おおまかな部分としては良い資料」開発担当者から様々な声
タマゴケ @s5ml 運用までやってくれるベンダを捕まえられないなら、運用設計は自社でやらなきゃならない。そして運用設計を真面目にやるのは開発完了後になるから、そこから運用渡しするときにトラブって後の祭りになる タマゴケ @s5ml 自社開発はよく知らないけど、社内にいるんだから運用部門としっかり連携してやるか、DevOpSで開発メンバが運用までやるんでしょきっと。 委託開発だと納品物出来上がるまで顧客の運用部門の人は基本的にシステムに触れないので、改善要望も出せない（製造請負の場合） タマゴケ @s5ml 当たり前だけど、運用まで受けてくれるベンダはものすごくお高くつくし、顧客～ベンダの依存度が上がるので、諸刃の剣ではある。それが嫌なら顧客側も真面目に運用のこと考えるべし。 ベンダとしては開発要件になければ運用のことまで考えようとしないし、業務知らないから考えられない。
独力でWebサービスを開発・構築できるフルスタックエンジニアへのロードマップ─幅広いスキルを「Udemy夏のビッグセール」で学ぶ！ - はてなニュース
Webで新規サービスを立ち上げる際に、UIからインフラ周りまで一人で面倒を見られるエンジニアは、少人数のスタートアップでなくとも非常に頼れる存在です。どんな課題に直面しても技術力で乗り越える、そんなスキルフルなエンジニアに憧れる方も多いでしょう。 この記事では、フロントエンドのプログラミング（JavaScript周辺）からサーバーサイド、インフラ、さらに開発手法まで、Web開発で必要になるさまざまなレイヤーのフルスタックなスキルの現在地と、関連するUdemyの講座を紹介します。 株式会社ヘンリーでVPoEを務める松木雅幸（@songmu）さんの執筆です。 フルスタックエンジニアに必要なスキル さまざまな講座でまとめて学習してみよう Udemyでは夏のビッグセールを開催中！ ※この記事は、株式会社ベネッセコーポレーションによるタイアップ広告です。記事末に、はてなブックマークした方にAmazo
LocalStack 実践入門 | AWS アプリケーション開発ワークショップ
📕 この Zenn Book について LocalStack はローカル環境や CI 環境で実行できる AWS エミュレーターです。この Zenn Book は、LocalStack に実践的に入門するワークショップです。LocalStack の基礎から LocalStack を使った AWS アプリケーション開発（Python コード実行・pytest 単体テスト実行）まで体験できます。 🚀 環境構築不要 ワークショップでは GitHub Codespaces を使うため、ラップトップ上に環境構築をする必要がなく、ブラウザですぐに試せます。 ⭐️ 登場する AWS サービス（順不同） ・Amazon SQS ・Amazon S3 ・AWS CloudFormation ・AWS SAM ・AWS Lambda ・Amazon CloudWatch Logs ・Amazon API G
開発生産性のために効率が必要なら、ヒトよりもシステムやプロセスを観察したい
この記事は前作 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する に続き、とはいえ効率を含む開発生産性的なものと向き合わねばならないチームや組織に向けた3作目です。そろそろ開発生産性がゲシュタルト崩壊してきた。 前提、わりと普通な話を述べているつもりだが、円滑になりきれないチームでは普通ないし妥当に至るハードルが思いのほか高いと感じる今日この頃。 人的効率主義に対するアンチテーゼの補足編 安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する 開発成果を念頭に起きつつも、どこかで一定の効率が必要なことを疑う余地はない。チームや組織の中長期を俯瞰すると正面から成果に向き合えるタイミングばかりではないので、そ
SRE NEXT 2024スライドまとめ｜kyon_mm
カンファレンスに全然参加していないけど、あとで勉強するためにリンクまとめておきます。また、8/19の21:00頃から公開されたスライドの感想を話していこうかとおもいます。（そちらのリンクは最下部） 信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。 SRE NEXT 2024のテーマは「Beyond NEXT」です。SRE NEXT 2023で掲げた価値観 Diversity、Interactivity、Empathyを大切にしつつ、SREの担う幅広い技術領域のトピックや組織、人材育成に対してディスカッションやコミュニケーションを通じて、新たな知見や発見を得られる場にします。 https://sre-next.dev/2024/ Reliable S
開発生産性カンファレンス 2024を堪能してきました - $shibayu36->blog;
dev-productivity-con.findy-code.io 自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。 興味深かったセッション 顧客価値向上による開発生産性向上 顧客価値を高めるという観点にフォーカスした発表でした。 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作 一元的品質は、高めれば高め
2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
ADRはじめました - エス・エム・エス エンジニア テックブログ
こんにちは！夏ですね。@kimukei です。 今回は、弊プロジェクトのカイポケリニューアルで ADR を導入しましたというお話です。 ADRとは、「Architecture Decision Record」または、「Architectural Decision Records」の略でアーキテクチャ上で重要な決定を記録するドキュメントです。 詳しくは「DOCUMENTING ARCHITECTURE DECISIONS」 や「Architectural Decision Records」をご覧ください。 また ADR については、以前弊社の酒井が登壇したイベントでも触れられておりますので、こちらの記事もあわせて読んでみてください。 tech.bm-sms.co.jp ADR を導入しましたってエントリは巷には溢れかえっているので、今回はちょっと趣向を変えて実際に私たちが運用している ADR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長期運用プロダクトの開発速度を維持し続けるためのリファクタリング実践例
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
無料で楽しむ Go サーバー開発のススメ
