モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演よりSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Git15周年 - GitHubとGitLabに聞く
原文(投稿日：2020/04/07)へのリンク 2005年4月7日、今からちょうど15年前、Gitはセルフホストの可能な完成度に到達した。すなわち、コードをコミットするためにGit自身を使用できるようになったのだ。今日、Gitは最も広く使用される開発ツールのひとつとなり、開発者がコードを管理する方法を大きく変えている。InfoQは今回、GitHubの上級(Distinguished)ソフトウェアエンジニアであるJeff King氏、GitLabのシニアデベロッパエバンジェリストであるBrendan O'Leary氏と、Gitの持つ重要性について話す機会を得ることができた。 Gitは元々、LinuxカーネルのSCM問題に終止符を打つために、Linuxの作成者でメンテナであるLinus Torvalds氏の手によって生まれた。氏は当時のLinuxが使用していたSCMであるBitKeeperの代
スクリプト言語としてのGo
原文(投稿日：2020/04/23)へのリンク ハイパフォーマンスなネットワークシステムや並列システムを開発するプログラム言語として、Goの採用が拡大していることから、開発者たちはこれをスクリプト言語として使用することに熱意を持ち始めている。ただし現在のGoは、そのままではbashやpythonの代用としては使えないため、これには多少の努力が必要だ。 CodelangのElton Minetto氏が説明しているように、そのパワーや簡潔さ、goroutineのサポートなど、スクリプト言語として使用する上でのGoには多くのアピールポイントがある。GoogleのソフトウェアエンジニアであるEyal Posener氏は、Goをスクリプト言語として使用するさらなる理由として、豊富なライブラリが使用可能であることと、言語自体が簡潔であるためスクリプトのメンテナンスが容易であることを挙げている。やや違う
夜のよい睡眠に向けたエンジニアガイド
Financial Timesで働いている間、私はチームが完全なグリーンフィールド方式でコンテンツAPIの新世代を構築するのを助ける機会がありました。この新しい機能をすべてをどのように再構築、デプロイ、保守するかを選択できる、自己組織化されたチームを作る権限を与えられました。技術スタックのすべての側面を選択できましたが、サポートモデルを定義する必要もありました。完全に説明責任があり、それを知っていたので、それを念頭に置いて構築しました。この説明責任により、運用サポートモデルを以前のプロジェクトとは異なる方法で見ることができました。 当初、私たちの実装は非常に不安定で、APIが定常的に利用できなかったり、さらに悪いことに、信頼できないデータを提供したりしていました。これにより、最初の主要な消費者であるft.comサイトの新しいバージョンは、APIがダウンした場合にキャッシュを使用してデータを
分散型アジャイルチームによる作業から学んだこと
原文(投稿日：2019/05/09)へのリンク 分散型チームでは、同僚との対面によるコミュニケーションが頻繁に行えないことが、コミュニケーションの成立を通常よりも難しくしている、とABN AMRO BankのスクラムマスタであるShabi Shafei氏は言う。氏は、アムステルダムで開催された"Agile, Testing, DevOps Showcase 2019"において、分散型チームを優れたアジャイルチームへと転換させる方法について講演した。 分散型チームが直面する大きな課題は、チームメンバ間の物理的な距離によるものだ、とShafei氏は言う。"同僚と定期的に、物理的に会えなければ、信頼やオーナシップ意識を築くのは難しい"、とする氏は、さらに、分散型チームでは文化の違いがより顕著になる、とも述べている。 Shafei氏が提案するのは、互いに協力を望む規範の確立に注力することである。有
テスト駆動開発：実はそれは設計技術です
テスト駆動開発（TDD）は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか？失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは本当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演
カンバンはどのように動作するか
CT (Cycle Time)は、アイテムを完了させるのにチームが必要とする平均時間です。 リトルの法則の力学はすばらしいものです。ソフトウエア開発の複雑な状態を説明し、解決策をもたらしてくれます。次のケーススタディを分析するために、Diagrams of Effects2を活用します。この図は、非線形のシステムやふたつ以上の効果や影響がシステムの振る舞いに影響を与える場合を分析するのに優れた効果を発揮します。 ケース1: チームのスループットを増大する Adamはふたりの開発者とひとりのテスターで構成するチームのコーチで、企業の幅広い製品のメンテナンスに責任を持っています。この企業は2013年に製品のマーケティングに投資を行い、なんとか顧客を2倍に増やしました。今、Adamのチームの受けるサポートリクエストは増大しています。しかし、CEOはチームのサイズを大きくするつもりはありません。
なぜアーキテクチャ図を必要とするのか？
正しいドキュメントの適切なバランスを見つけるために、次のエクササイズをチームで試してみよう。まず各同僚に、技術ドキュメントに本当に必要なもの、そこに含めるべき図の種類について質問する。彼らの意見を集約して、ブレインストーミングを実施し、チームにとって本当に必要なものについて合意をとる。チームの外部に、追加の要求を持つ影響力のあるステークホルダーが1、2名いるかもしれない。彼らのニーズを考慮することもまた、アーキテクトの責務だ。以上に基づいて、ステークホルダーのニーズを満たす適切な量とレベルの技術ドキュメントを作成する。もし開発者がドキュメントの真の価値を理解し、その価値を保つことに関心を持てるなら、進んでドキュメントに貢献し、適切に保守してくれるだろう。最終的に、全員がハッピーになる。しかし、もしその必要性を理解しなかったり、気にしないのなら、それについてはほとんど忘れてしまって構わない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
継続的デリバリの今後10年を予想する
Terraform、Docker、Kubernetesなどのテストを自動化する - Yevgeniy Brikman氏のQCon SFでの講演より
Managing Failure Modes in Microservice Architectures
GitHubが脆弱性ワークフローを改善してCVE採番機関に
Googleのソフトウェアエンジニアリング文化
Pulumi Crosswalk - AWSのインフラストラクチャ・アズ・コード
マイクロサービスを始める時にすべきこと - Ben Sigelman氏のQCon Londonでの講演より
イベント駆動システムに対する批判的見解 - Bernd Rücker氏のQCon Londonでの講演より
MicrosoftがSurfaceやHyper-Vで使用しているUEFI Coreをオープンソースとして公開
サーバーレスによる大変革
AmazonがSQSを更新し、SQSはAWS PrivateLinkを使用するAmazon VPCエンドポイントをサポート
多すぎるスクリプトは継続的デリバリーをダメにする
