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が最近リリースされ、重要な変...
以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。 ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。
【アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の本当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。 最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、
The Rational Edgeより：シリーズ最後の4回目となる本稿では、企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについてPeter Eelesが解説する。 筆者による本シリーズの第1回目「ソフトウェアアーキテクチャって何なの？（前編）」は、ソフトウェアアーキテクチャとは何かについて書いた。2回目「ソフトウェアアーキテクトの役割」はソフトウェアアーキテクトが果たす役割の特性について説明し、3回目「ソフトウェアアーキテクティングのプロセス」はソフトウェアアーキテクティングのプロセスの基礎にあるテーマ、つまり特性について考察した。シリーズ最後の4回目となる本稿では、企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについて説明する。 大まかにいえば、ソフトウェアアーキテクティングとはコスト削減、品質向上、スケジュールどおりの引き渡し、要件
The Rational Edgeより：もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいう（作業完了の責任者である）プロデューサーならば、ソフトウェアアーキテクトは（作業を成功させ、最終的に利害関係者のニーズも満たす立場にある）監督だといえる。4回シリーズの2回目となる本稿では、ソフトウェアアーキテクトの役割について解説する。 今回は、ソフトウェアアーキテクチャを説明する4回シリーズの第2回目（第1回目は「ソフトウェアアーキテクチャって何なの？」を参照）となる。第1回目ではアーキテクチャとは何かを明確にした。そこで、今回はアーキテクチャの作成責任者であるアーキテクトについて考える。アーキテクトの役割はおそらく、どのソフトウェア開発プロジェクトにおいても最もその手腕を問われるものだろう。アーキテクトはプロジェクトの技術責任者であり、最終的にはプロジェクトの成否について技術面の責任
Landscape トップページ | < 前の日 2007-01-15 2007-01-17 次の日 2007-02-27 > Landscape - エンジニアのメモ 2007-01-17 ソフトウェア見積りを読了 当サイト内を Google 検索できます * ソフトウェア見積りを読了この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [本] ソフトウェア見積り―人月の暗黙知を解き明かす スティーブ マコネル / Steve McConnell / 田沢 恵 / 溝口 真理子 / 久手堅 憲之 発売日: 2006/10 amazon で詳しく見る bk1で詳しく見る スティーブ・マコネルの『ソフトウェア見積り』を読了した。 『ソフトウェア見積り』は、ソフトウェア開発における工数や期間を見積もる方法について詳細に解説した本。見積もりについて学んだことのない私に
「アート・オブ・プロジェクトマネジメント」で強くオススメされてたので読む ―― これはスゴい。ドキュメンタリーとして夢中になって読めるだけでなく、プロジェクトが危機に陥ったときの「べき/ベからず集」しても、ものすごく有効な一冊なり。 どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策…プロジェクトがパニックに瀕したとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる。本書を通じて学んだ危機管理マネジメントは、次のとおり。 プロジェクトが危機的状況のとき、あらゆる手段を使って、自分の感情をコントロールせよ。感情は事実をゆがめ、判断を誤らせ、解決への手段の一つ一つに邪魔をする 「危機」は、すぐに数字にならない。必ずタイムラグが発生している。だから、危険な数値が今出ているということは、既に危機的状況に突入している、ということだ 問題に対処するとき、絶対
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く