Content-Length: 275171 | pFad | http://b.hatena.ne.jp/honeybe/development/
「ソフトウェア開発に役立つビジュアル思考～UMLとマインドマップ」講演のust録画です：An Agile Way：オルタナティブ・ブログ
「ソフトウェア開発に役立つビジュアル思考～マインドマップとUML」という長寿講演をustream で録画してもらいました。はじめての録画でしたが、スライド画面と立ち位置の関係もちょうどよく、なかなか見れるものになっています。 この講演自体は、ちょっとずつ修正しながら、過去５回くらい講演しています。北海道、匠塾、など。。ソフトウェア開発を、もっともっと、右脳的に、ビジュアルに、直感的にすることで、創造性を引き出し、仕事を楽しくしたい、そんな思いをこめています。 アジェンダはこんな感じ。スライドはこちら（http://www.slideshare.net/hiranabe/using-mind-maping-and-uml-effectively-in-software-development） マインドマップの紹介。ソフトウェア開発で使える場面マインドマップの例題ワーク UMLの紹介。ユース
戦いたくない戦場での戦いを強要されるご時勢 島国大和のド畜生
何のことは無いゲームの話題。寝れないので酒を入れたついでに書いた。 最近のゲームで出来のいいヤツは、何１０億とかけてる。（以後、エゲツないゲームと呼称） なかなかそんなプロジェクトはないんだけど(日本製だと、実名を挙げれる程度)、それでも、自分たちが作るようなフツーのゲームもそれらと比較される。 ユーザーが比較する分にはかまわないんだ。払う金額一緒だからさ。 発注者や、業界人が、その区別がついていないのは、頭悪いなと思う。お前の払う金額はあのゲームの1/10以下だよ。みたいな。 ちなみに、自分みたいなびみょーな開発者でも、昔はエゲツないゲーム作りたいなと思ってた事もある。それでも、最近のエゲツないやつ（主に外国産）は土俵が違う。正直ああいうのは作りたくない。やだ。マジでやだ。 予算が潤沢なら、スキルアップの為にやるのもいいけど。 （外国産が予算潤沢なのは、アメリカは市場が広いし、中韓は人件
第4回 コードレビューについて | gihyo.jp
はじめに 「プログラミングに関する雑多な事柄」がテーマの本連載、第4回は「コードレビュー」について取り上げたいと思います。 コードレビューの方法 コードレビューは、文章のレビューと似ています。文章と同様にコードの場合も、人に見てもらうことで、わかりづらい部分や冗長な部分など、さまざまな問題点が見つかります。 自分の書いた文章を人にレビューしてもらうには、たとえば、文章をメールで送ります。この場合、レビューのフィードバックはメールの返信という形で受け取れます。 コードレビューの場合も同様の方法で行えます。コードレビュー用の市販ツールなどもありますが、人に見てもらってフィードバックを得るということが一番大切ですから、特に方法にこだわる必要はないと思います。 コードレビューのメリット それでは、コードレビューに具体的にどんなメリットがあるのか見ていきましょう。 コメントの充実 コードを書いた本人
受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは？ - livedoor ディレクター Blog
こんにちは、小久保です。今回は受託開発事業と自社媒体事業におけるディレクターの意識の違いについて書きたいと思います。 弊社はもともとウェブ関連のSI事業から始まっており、私が入社した5年前もほとんどの仕事がウェブの受託開発・運用でした。 そこから紆余曲折がありながら、現在のメディア事業中心の会社へと変化してきたわけですが、その過程における組織変更はまさに試行錯誤の連続でした。 以前、面白法人カヤックの柳澤社長が「受託開発と自社開発の両立」という記事を書かれていましたが、この記事を読んだときに「やっぱりどこも同じような悩みをかかえているんだなぁ」と激しく共感したことを覚えています。 ところで皆さんは、受託事業と自社媒体事業について一般的にどのようなイメージを持たれているでしょうか？ 弊社が事業シフトの過渡期にあったときに頻繁に出ていた声は以下のようなものでした。 受託 = クライアントに詰め
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
MySQL :: Developer Zone
"The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect Oracle's product development plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material, code, or functionality, and should not be reli
steps to phantasien t(2007-07-06)
昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会
Part1 オープンソース/C言語に学ぶ「ソースコードの読み方」：ITpro
「Code Reading―オープンソースから学ぶソフトウェア開発技法」（毎日コミュニケーションズ発行，写真1）という本があります。私はこの本の監訳者ですから，やや自画自賛になってしまいますが，ソースコードの読み方を主題にした本はほかにはあまりありません。技法からツール，データ構造，アーキテクチャ，さらには実際にコードを読んで利用する実例まで紹介している網羅的で良い本だと思います。 この本の「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家，他人の筆づかいを研究しなかった偉大な画家，同僚の肩越しに技を盗まなかった腕のよい外科医，副操縦席で実地の経験を積まなかった767機長――果たして，そんな人たちが本当にいるのでしょうか？ たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち，他の人の
googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]
昨日に続きますが、ディベロッパーサミットでgoogleの開発プロセスについて聴講してきました。Googleは一味異なるプロセスや組織をお持ちのようです。請負開発をされている方には新鮮なのではないでしょうか。工藤氏はGoogleのインフラ寄りの話、小松氏は開発プロセスの話で講演されていました。サービスインフラも開発プロセスも私にとっては身近な話ですが、ここでは、小松氏の講演について書こうと思います。講演では、極めて異例/エキセントリックというプロセスは話されていませんでしたが、以下は、特徴的と感じました。 異なる観点から複数のレビューを実施していること。いわゆるperspective-based readingを実施しているそうです。役割分担型レビュー（reviewというよりはおそらくinspection）で、セキュリティやユーザインタフェースの観点から見たデザイン/ソースコードの妥当性検証
![googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]](https://images.weserv.nl/?url=https%3A%2F%2Fcdn-ak-scissors.b.st-hatena.com%2Fimage%2Fsquare%2F7f2a4ced7f91e578679d11d5fcc8f34c5d080289%2Fheight%3D288%3Bversion%3D1%3Bwidth%3D512%2Fhttps%253A%252F%252Fblogs.itmedia.co.jp%252Fmt-static%252Fsupport%252Fassets_c%252Fuserpics%252Fuserpic-83-100x100.png&q=12&output=webp&max-age=110)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/honeybe/development/
Alternative Proxies:
github を用いた開発フローテンプレート
発注者ビューガイドライン（ダウンロード可能） | 発注者ビュー検討会 | NTTデータ
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー (2007-09-07)
IBM developerWorks:わかりやすいコードを作成するための6つの方法