![Amazon.co.jp: 継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣: David Farley (著), 長尾高弘 (翻訳), 榊原彰 (その他): Digital Ebook Purchas](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f0a4cfb030e537c6dfb4d4389b73607a7f7c060/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F51TviYFYuML._SL500_.jpg)
当初はちょっとしたSOLID批判のつもりが、「藪を突ついて蛇を出して」しまったのですが、物事はそこから具体的で目に見えるものへと発展しました。仮に、近頃はSOLID原則が役に立たなくなっているのだとしたら、何に置き換えればよいのでしょう? あらゆるソフトウェアに通用する原則はあるのでしょうか? そもそも「原則」とは何を意味するのでしょう? 私は「仕事がたのしくなるソフトウェアならではの特性や性質がある」ということを確信しています。コードでそのような質が高まれば高まるほど、仕事もどんどんたのしくなります。しかし、何事もトレードオフですから、自分の置かれている状況をつねに考慮する必要があります。 そうした特性はたくさん存在しており、互いに重なりや関連がありますし、説明の仕方もさまざまです。ここでは私がコードで気にかけている要素を強く支えていると思える5つを選びました。選ぶ数はこれぐらいが丁度良
IDEs AppCode CLion DataGrip DataSpell Fleet GoLand IntelliJ IDEA PhpStorm PyCharm RustRover Rider RubyMine WebStorm Plugins & Services Big Data Tools Code With Me Quality Assurance JetBrains Platform Scala Toolbox App Writerside JetBrains AI Team Tools Datalore Space TeamCity Upsource YouTrack Hub Qodana .NET & Visual Studio .NET Tools ReSharper C++ Languages & Frameworks Kotlin Ktor MPS Amper Edu
Brainstorming a handful of new CSS organization acronyms August 26, 2022 When I first heard Nicole Sullivan talk about OOCSS, I thought “Oooh, smart.” When I read Jonathan Snook’s riff on that idea in SMACSS I thought “Oooh, smart.” When I heard Harry Roberts say “never use IDs in your CSS files” I said “Oooh, smart.” But when BEM and roboclasses came around… I didn’t have the same reaction. I nev
こんにちは、モバイル基盤部の@giginetです。 iOS版のクックパッドアプリでは、2019年頃より、大規模なアプリを複数のモジュールに分割するマルチモジュールの導入を進めてきました。 今回はクックパッドアプリのマルチモジュール化の戦略について、主に依存関係の解決という点に焦点を当てて紹介します。 クックパッドアプリとマルチモジュールプロジェクト iOS版のクックパッドアプリはコード量が多く、膨大なビルド時間が問題となっていました。また、同時に関わる開発者も多く、それぞれの機能間を疎結合にしたいという需要が大きくありました。 この問題を解決するために、2019年の初頭からiOSアプリのマルチモジュール化プロジェクト*1を開始しました。 以来、ここ2年で、モジュール分離を前提とした開発が大きく進みました。 現在では、アプリ全体のコードのうち、半分以上がモジュール分離され、アプリ全体が約25
このコンテンツ ライブラリは、Azure においてスケーラブル、安全で回復力がある高可用性のアプリケーションを設計するための体系化された方法を示します。 このガイダンスは、顧客エンゲージメントから学んだ実証済みのプラクティスに基づいています。 はじめに クラウドによって、アプリケーションの設計とセキュリティで保護する方法が変わりつつあります。 アプリケーションは、モノリスではなく、小さな分散サービスに分解されます。 これらのサービスは、API を介して、あるいは非同期メッセージングまたはイベントを使用して通信します。 アプリケーションは、需要に応じて新しいインスタンスを追加して水平方向に拡張します。 このような傾向により新たな課題が生まれました。 アプリケーションの状態は分散されます。 操作は並列かつ非同期的に実行されます。 障害が発生しても、アプリケーションは回復力があることが必要です。
DOCOMOMO JAPAN選定 日本におけるモダン・ムーブメントの建築(ドコモモ ジャパンせんてい にほんにおけるモダン・ムーブメントのけんちく)は、DOCOMOMO Japanが現存する近代建築として選定した建築である。2024年(令和6年)6月時点で、290件の建築が選定されている[1]。 DOCOMOMO Japanでは、1999年(平成11年)に日本の近代建築20選(にほんのきんだいけんちく20せん)を選定し、2003年(平成15年)9月には80件を加え、日本におけるモダン・ムーブメントの建築を100件選定した。その後さらに以下のように随時追加されている。 2005年追加選定(計115件) 2006年追加選定(計125件) 2008年追加選定(計145件) 2009年追加選定(計150件) 2013年追加選定(計164件) 2014年追加選定(計174件) 2015年追加選定(計
React is an excellent tool for building front-end applications. It has a diverse ecosystem with hundreds of great libraries for literally anything you might need. However, being forced to make so many choices can be overwhelming. It is also very flexible, you can write React applications in any way you like, but that flexibility comes with a cost. Since there is no pre-defined architecture that de
Paul Hammant's Blog: Legacy Application Strangulation : Case Studies Strangler Applications Martin Fowler wrote an article titled “Strangler Application” in mid 2004 (and “Strangler Fig Application” from early 2019). Strangulation of a legacy or undesirable solution is a safe way to phase one thing out for something better, cheaper, or more expandable. You make something new that obsoletes a small
Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか/入らないか」。「抽象的か/そうでな
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey(プログラミング言語Clojure作者)のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか? 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
少し前に,Facebookのロードバランサが話題になっていた. blog.stanaka.org このエントリを読んで,各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた. ざっくり検索した限りだと,Microsoft, CloudFlareの事例が見つかったので,Facebookの例も併せてまとめてみた. アーキテクチャ部分に注目してまとめたので,マネジメント方法や実装方法,ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする. 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた?)ロードバランサのアーキテクチャは,下記の論文が詳しい. Parveen Patel et al., Ananta: cloud scale load balancing
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く