タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

developmentとsoftwareとarchitectureに関するbeth321のブックマーク (5)

  • 世界最強のソフトウェアアーキテクト

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! マーケティングソリューションカンパニー(MSC)開発部の小川雄大です。 昨年11月に子会社のクロコスからヤフーに移りまして、現在はヤフーで開発を行っています。みなさまどうぞよろしくお願いします。 MSC開発部では、ヤフーが世界最強を目指してどう取り組んでいくかについて議論する会を毎週開催しています。今回はそこで今年の1月に僕が発表した「世界最強のソフトウェアアーキテクト」について公開したいと思います。 今回はヤフーに入ってはじめての発表ということもありテーマをどうしていくかはかなり悩んだ部分なのですが、テクニックよりもアーキテクトが持つべきマインドを共有することが次につなげていく上で大切になると考えたので、多少抽

    世界最強のソフトウェアアーキテクト
  • アジャイルが否定したものを見直そう - arclamp

    2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で

    アジャイルが否定したものを見直そう - arclamp
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • Matz氏語る「今ソフトウェアはソフトじゃない」 - Engine Yard Blog

    先日Rubyビジネス推進評議会主催の第3回Rubyビジネスフォーラムが大阪で開催されました。 Ruby言語開発者、まつもとゆきひろさんが、『インターネットが変えるソフトウェアとビジネス。Rubyを例として』と題した基調講演を行いまいした。 その内容を紹介します。 計算機としてのコンピューター IBMの初代社長トーマス・ジョン・ワトソンの有名な言葉に、「コンピューターは全世界で5台くらいしか売れないと思う」と言ったとされています。 その数字は当時の計算技師の人数とENIACの計算性能から導かれた数でした。 ところが、今ではその数百万倍の処理能力をもつコンピューターが何億台もあります。 去年だけでPC出荷台数は3億台。スマートフォンとタブレットはそれを超える出荷がされています。 コンピューターは計算機としてのみ使われているわけではありません。 インターネットとの接続 今日、大阪まで松江から飛行

    Matz氏語る「今ソフトウェアはソフトじゃない」 - Engine Yard Blog
  • アーキテクチャ設計に品質特性を使おう - arclamp

    アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報

    アーキテクチャ設計に品質特性を使おう - arclamp
  • 1