InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
Deborah Hartmann アジャイルソフトウェア開発という高度に協調的な環境において、『Collaboration Explained: Facilitation skills for software project leaders(リンク)』と題されたJean Tabaka氏の本は対立、人と人とのコミュニケーション、時間的制約のような困難なマネジメントの問題に対する答えを示してくれる。ミーティングが嫌いで、しかも(あるいは)、改善していくべきだと確信しているなら、アジャイルプロジェクトに関わるか否かに関係なく、この本を読まなければならない。 Charles Humble Harold Abelson氏、Gerald Jay Sussman氏、Julie Sussman氏の『計算機プログラムの構造と解釈(Structure and Interpretation of Comput
第2版(2008年1月19日):翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
指導者として駆け出しの当初は、自分の言っていることを理解してもらうことにかなりのエネルギーを費やしました。ですから、私の素晴らしいコーチング戦略を長ったらしいスピーチで自チームの選手達に説明しました。選手に私の言いたいことを確実に理解させるために、「皆さん、分かりましたか?」と尋ねたものでした。皆がうなずいたので、私は満足でした。しかし、選手のプレーを見て、理解していなかったことが分かりました。 私の言ったことを聞いていないようでした。ですから、もっと大きな声で、より攻撃的に、そして対峙するような感じで話すようになりました。残念ながら、効果はありませんでした。私は自分の指導者にこう言いました --「才能がなくて耳の遠い選手が集まっても、大きな成果は上げられません」。するとこの指導者は、何もかも私の責任だと言いました。コミュニケーション調査の結果を見せてくれたのですが、この調査によって次のこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く