LocoはRailsにインスパイアされたRustの新しいフレームワーク垂直スケーラビリティと効果的なテストによる金融取引システムのパフォーマンスと効率の最大化 Peter Lawrey氏はJavaチャンピオンであり、Chronicle SoftwareのCEOとして、開発者を鼓舞してソリューションのクラフトマンシップを高めることに情熱を注いでいる。経験豊富なソフトウェアエンジニアとして、Lawrey氏はソフトウェア開発プロセスにおけるシンプルさ、パフォーマンス、創造性、革新性を奨励することに努めている。
簡単に - ソフトウェア開発のマニフェスト
ソフトウェア会社の経営者は、かつてエンジニアだった人でさえ、大部分はビジネススクールプログラムの卒業生です。彼らは、販売、マーケティング、マクロ経済学の視点からこの業界を見ます。そして、先行者利益 - または、もっと一般的に速く動く人 - が優位であるという信条によって動きます。 最初であることはよいですが、最高であることの方がよりよいでしょう。初期の検索パイオニアYahoo!は、Googleが優れたアルゴリズム、ビジネスモデル、そして、リーダシップチームでずっと後に検索マーケットに入ってきた時に、このことを発見しました。もちろん、ある時点で会社が参加するのは遅すぎることもあるでしょう。例えば、今になって、検索のGoogleのリーダシップポジションに挑戦することを考えるのは難しいでしょう。しかし、業界優位のレースはマラソンであり、スプリントではありません。トラックの最初の1、2周は、長期間
アジャイルマニュフェスト：ソフトウェアアーキテクトの視点
まず、最も重要なのは、アーキテクトが間違っている可能性があるということです。これは、私が詳細な事前技術設計を作成し、Sprintを改良中に開発チームに提示した後に起こりました。私が考えていなかったケースや考慮に入れなかったケースに関連する質問がありました。ほとんどのケースで、初期設計は不完全または非実用的であり、追加の作業が必要であることが判明しました。 大きな事前設計により、チームメンバーの創造性と自律性が制限されます。これは、チームメンバーが既に付与されているレシピに従う必要があるためです。心理学的な観点からは、著者でさえも、後になってそれを変更する方向に傾いたり、変更に消極的になるかもしれません。その欠陥を認めるのではなく、正しいことを証明しようとするかもしれません。 アーキテクトは、正確な詳細設計を事前に提供するのに苦労するため、チームのボトルネックにもなります。常に事前設計を提供
インクリメンタルなアーキテクチャアプローチ
原文(投稿日：2019/01/18)へのリンク 世界中のアプリケーションのほとんどのうち、おそらく90%は、モノリシックなアプローチで動いている。オーバーエンジニアリングを避けるために、私たちはシンプルなアーキテクチャから始めて、必要に応じて進化させなくてはならない、Randy Shoup氏はReactive Summit 2018でこう語った。彼は最近発表したプレゼンテーションで、小さく始まり、やがて大規模でグローバルなインターネット会社に成長した企業での経験、その期間にアーキテクチャがどのように進化したのか、そして、新しい会社や新製品を始める時のIT観点からの提案について説明した。 Shoup氏はeBay、Google、Stitch Fixで働いた経験があり、現在はWeWorkのエンジニアリング担当VPを務めている。彼が取り上げた最初の事例はeBayだった。1995年の3日間の週末プロ
プロジェクトではなく、プロダクトで思考せよ
プロダクトを中心に構築された組織は、エンドツーエンドで作業を監視する。Conwayの法則を逆転して、プロダクトに基づいた長期的なチームを確立することにより、組織が安定すると同時に、作業の管理と優先順序付けが容易になる。レトロスペクティブはプロダクト管理の強力なツールだ – 継続への自信を与え、組織に対するリスクや損失の可能性のあるものを素早く見つけ出せるようにしてくれる。 アジャイルコーチでトレーナ、講演者、コンサルタントのArdita Karaj氏は、eXperience Agile 2018で、“What’s my product”と題した講演を行う。同カンファレンスは10月1～2日、ポルトガルのリスボンで開催される。 InfoQではeXperience AgileをQ&Aや要約、記事などでお伝えする予定である。今年のテーマは“人々を通じた改善”だ。 世界各地から集まった業界のトップリ
あなたはイノベーションの障害か
私の比喩の中の水(と摩擦)の大部分は文化を指し示しています。その企業全体の文化、そして、その文化の中で機能する下位文化も含みます。例えば、運用担当者は変化に抵抗します。彼らはイノベーションによって判断されるのではないからです。パフォーマンスとシステムの稼働時間で評価されます。これによって現状を維持することにもっとも価値を置く文化が育まれます。この文化が開発者のほうに移っていくと、次第にビルドの失敗に関心を払う文化になっていきます。これは必ずしも悪いことではありません。これによってしっかりとしたテストとより良いコードが生まれるようになります。しかし、新しいビジネス要件と厳しい納期の中に投げ込まれるとかつては自由に動き回っていた開発者チームでも変化に対する抵抗が増します。安全でリスクを呼び込むイノベーションを回避することに固執する方が健全な場合もあります。 リスク回避は文化に埋め込まれ、構造、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より
Shopifyはいかにしてモジュラモノリスへ移行したか
Airbnbにおける大規模サービスの構築 - QCon Londonでの講演より
なぜアーキテクチャ図を必要とするのか？
システムをマイクロサービスに分解するには
Ron Jeffriesが、開発者は"Agile"を捨てるべきと発言
Zip Slipディレクトリトラバーサル脆弱性の影響は多くのJavaプロジェクトに
オラクル、オープンソース化後にMission Controlチームを解雇
GoogleのStackdriverモニタリングがKubernetesのデプロイ向けサポートを強化
GitHub Checks APIにより、アプリは高度な継続的インテグレーションが可能に
TSDoc - TypeScriptソースコードのドキュメント化フォーマット
Kubernetesはキャズムを越えたか？
マイクロサービスの未来がITワールドを変革：Uwe Friedrichsen氏がmicroXchg Berlinにて
GoogleのData Loss Prevention APIがセキュリティデータ管理の新たな方法を提供
