GitHub Advent Calendar 2024の14日目の記事です。昨日はwa-chan222さんの未経験から始めたGitHub活用の基本と学びでした。 はじめにフューチャー社内の有志メンバーでGitブランチフローの規約を作成しました。 ひとまずは形になったので紹介します。 Gitブランチフロー規約 | Future Enterprise Coding Standards ※GitHub/GitLabを利用し、トランクベース開発を採用しないアプリケーション開発を想定しています。 内容へのフィードバックは、Issueかツイッター宛にメンションを入れてコメントを貰えると幸いです。 なぜ今更Git？Gitは2005年に公開され、2007年のGitHub登場以降、バージョン管理ツールとして爆発的に普及しました。現在では、業界のデファクトスタンダードと呼べるほどの地位を確立しています。 公開

はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、

すでに多くの方々にお手に取っていただいておりますが、オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。みなさまご購入いただき、ありがとうございます。初版をお買い求めになられたい方は今すぐ書店にダッシュ！ トレードオフこそが設計である良い設計とか読みやすいコードみたいな話題はTwitterではバズりやすい話題です。 読みやすいコードの話題ではいろいろなレイヤーの話が出てくるのですが、因数分解すると、だいたいいくつかのカテゴリーに分かれるように思います。 命名規則とか書き方のルール 従うべきクラス構造、アーキテクチャ構成の導入 サービスの境界をどこに引くか、どのようなときに設計手法を選ぶか、どのアルゴリズムを選ぶか 名前や命名規則の統一とか書き方の統一とかは用語のリストを作

アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの

Real World HTTPでも紹介したネタですが、お仕事で受けている技術コンサル中に質問をいただいた時に、微妙に本で紹介した内容では少し足りなかったので、改めて整理のためにブログ記事にしてみました。次回、本が改訂されることがあればこのブログエントリーの内容も入れて加筆したいと思います。 Real World HTTPだとGoを使っていましたが、フロントとサーバーを同時にいじるので、本エントリーではNext.jsをサンプルに使います。Next.jsでプロジェクトを作って（npx create-next-app@latest –ts)、適当なプロジェクト名を入れてアプリケーションの雛形を作っておいてください。 Next.jsでは、1つのスクリプトファイルを作成すると、それがサーバーAPI(/pages/api以下)と、フロントの画面(/pages/以下のapi以外)になります。Next.j

はじめにTIG DXユニット 1の真野です。echo → 生net/http → gorilla/mux → go-swagger, gqlgenの経歴でGoのHTTP APIを実装してきました。本記事では最近業務でヘビーユーズしているgo-swaggerについての開発Tipsをまとめました。 背景フューチャーではGoを採用する案件が増えて来ており、その際にgo-swagger というツールを利用することが多いです。 2 理由はWeb APIのスキーマを駆動に開発することに慣れているという開発文化（DBレイヤのERDやデータフローを駆動に開発することは今も多い）や、リリース後の保守や将来のマイグレーションを考慮しなるべく特定のDSLに依存したくないというポリシーを強く持つこと、開発前にある程度固く機能数を洗い出して工数見積もりや開発スケジュールに活かしたいといった大人な事情など、色々相性が

はじめにTIG DXユニットの真野です。フューチャー技術ブログの運営の1人です。未来報を運営している岡田さんなどと一緒に、気持ちは草の根活動で外部発信に携わっています。 IT企業の技術ブログ運営は、ある一定の質をキープしながらも、投稿頻度を高め・それを継続することが求められ、周囲の期待値もあるので中々気を抜けない仕事だと思います。単発ならともかく、継続することは忍耐が必要なので特に大変です。運営していてこれはナレッジだなと感じたことをまとめていきます。 2020/09/08 続編を公開しました: フューチャー技術ブログで行っている連載企画が良いよって話 技術ブログの大変なところ≒記事ネタを探すところ熱心な寄稿者が複数いて、運営からの声掛け無しで記事が集まるのであれば非常に楽ですが、たいていの組織やチームはそうでないと思います。また、本業は記事を書くことではなく、自社プロダクトの開発やシステ

Home Tags GoTips連載 GoTips連載 タグの記事 8 投稿 6 著者数 188 総シェア数 0 Twitter 0 Facebook 97 はてブ 91 Pocket Go tipsということで、シンプルネタを投稿します。 検索窓に入れると「printデバッグでいつまで消耗しているの？」とか「printデバッグにさようなら」とかサジェストされつつも、根強く生き残っているのがprintデバッグです。むしろ、非同期だったり並列処理が増えてくると、同期的に動くデバッガーが逆に使いにくかったりもありますし、デバッガーを使うにしてもブレークポイントを仕掛ける場所のあたりをつけるためにprintデバッグの力を借りたりもあるし、いっそのことprintデバッグの方が進化しろ、と個人的には思っています。

はじめまして。TIG DXユニット 1の亀井です。 はじめに みなさん、Swagger使ってますか？ Swaggerや周辺ツールについては 某先輩の記事 にて丁寧に解説されていますので、 本記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。 前提私が在籍しているプロジェクトでは、REST APIは golang でフロントエンドを Vue.js + TypeScript で構築しています。 短期間・高品質での構築を実現するためにSwaggerを設計ドキュメントとしてだけではなく、コード自動生成やモックサーバーに活用させることで徹底したスキーマファーストな開発を行ってきました。 というわけで、今回は下記のツールを利用することを前提として規約を作成しています。 go-swagger: Goアプリケーションのハンドラ、リクエスト/レスポンス

他の言語になれた人が、初めてGoを書いた時にわかりにくいな、と思った部分はどのようなところがあるのか、難しいポイントはどこか、という情報を自分の経験や、会社の内外の人に聞いたりしてまとめてみました。まだまだたくさんあるのですが、多すぎるのでまずはこんなところで。コンテナで開発することがこれからますます増えていくと思われますし、その時にコンテナとの相性が抜群なGoをこれから使い始める人もどんどん増えていくと思います。 Goは特に言語のコアをシンプルに、何かを実現するときはそのシンプルな機能を組み合わせて実現しよう、というコンセプトです。つまり、他の言語で実現したいこと・できていることに比べて、Goは組み合わせ（イディオム）でカバーする領域が広くなります。そのあたりのとっかかりになる情報を提供することが、これからGoを触る人にとってつまずきを減らすことになると思います。 Go Conferen