0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
9つのチームロールでチームワークを強化する / ベルビンチームロール - mtx2s’s blog
スティーブ・マコネル（Steve McConnell）の著書『More Effective Agile』の第6章で、「ベルビンのチームロール理論」なるものが紹介されている。そこに、「Plant」や「Shaper」「Resource Investigator」など、聞き慣れない9つのロール名が並ぶ。チーム内でこれらのロールのバランスが取れていることと、チームのパフォーマンスの間には、高い相関があるそうだ。 そう言われると興味を持つ。ベルビンチームロールとはどのようなものだろうか。しかし残念なことに、同書からはほとんど情報を得られない。書かれているのは、先の9つのロールそれぞれに関する短い説明文と、次の引用にある記述ぐらいだ。 この理論では、チームにおいて人々がどのように行動するか、人々がどれくらい協力して作業を行うと考えられるか、そして各役割の候補者をどのように選択するかを評価する。 202
ソフトウェアを設計するということ - 満足せる豚。眠たげなポチ。
『オブジェクト指向入門』という本がある。今は第2版が出版されていて、原則・コンセプトをテーマにしたものと方法論・実践をテーマにした二分冊になっている。この本はオブジェクト指向によるソフトウェア構築 (Object-Oriented Software Construction) とはなにかについて、緻密に基礎の基礎から話を積み上げ、その全体像を描き出す他にない名著だ。ぼくはまつもとゆきひろさんが推薦する本として最優先に挙げていたのを見て当時出ていた第一版の翻訳を買って読んだ。 最近になって必要があって読み返して驚いたのだけど、今でも自分の設計の指針となっているベースはとことんこの本の内容だった。技法ではなく、設計をするというときに考える思考の観点はこの本からもらったもので、その観点を実現するにはどんなことを理解し考えないといけないかをその後学んで実践し続けてきたのだということに気付くことがで
ソフトウェアをリプレースする前に考える三つのこと - ローファイ日記
個人的には三つの基準があるという話。 そのソフトウェアが十分に古く、十分長い間保守されていないか そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか 1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。 ただ、ここで重要なのは、2.や3.との兼ね合いかなと思っている。 例えば2.が1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。 開発者が退職してしまった Hoge言語に関するドキュメントが全然なくて学習が困難 という感じであればリプレースは検討に入れていいかもしれない。 しかし、こ
ソフトウェア開発におけるムダ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Alan Shalloway氏のWastes of Software Developmentが良い記事でしたので、抜粋・意訳にてご紹介します。 僕のトレーニングではいつもトヨタ生産方式の話やStandishのレポートの話をしています。 7つのムダのうち特に作り過ぎのムダをなくすことはとても重要で（もちろんほかも重要）、これがないと頻繁に継続的に顧客に価値あるフィーチャーを届けることはできなくなるからです。 さらに開発のプロセスの中で、常にどこにムダがあるのかを考えて改善していくことはチームに課された責任でもあります。 例えば思いつく限り以下のようなものはムダです。 使わない機能たくさんのオプション設定読まない仕様書読まない報告書やたらと体裁にこだわった文書更新されない文書目的のない会議決定事項が守られない会議遅いPC小さいディスプレイ行動の監視目的
すばらしいソフトを作るには、カリスマが講演 ― ＠IT
記者という職業柄、これまで非常に多くのプレゼンテーションを見てきたが、プレゼンテーションの1枚目が半裸の女性モデルの写真だったのは初めてだった。 2月13日、14日の予定で東京・目黒で開催中の「デベロッパーズ・サミット2008」で講演したFog Creek Softwareの創業者でCEOのジョエル・スポルスキー（Joel Spolsky）氏のプレゼンテーション「Joel on Developers Summit――素晴らしいソフトウェアを作るということ」は、型破りに楽しく、なおかつソフトウェア開発者にとって示唆に富む内容だった。 スポルスキー氏は米マイクロソフトのExcelチームで、Excel用マクロ言語を、後にVBAと呼ばれることになるモダンなオブジェクト指向言語に置き換える仕事でプログラムマネージャを務めたことがあるなどソフトウェア開発のベテランだが、エッセイの書き手としても名を馳せ
ソフトウェア開発の品質と、ソフトウェアの品質は、分けて考えたほうがいいんじゃないか - きしだのはてな
ふと「ソフトウェア品質のxxx」みたいな文章を見つつ、基本としてはソフトウェアがいかに仕様どおりになっているか確認する話だったので、これってソフトウェア品質じゃなくて、ソフトウェア開発品質だよなーと思った。 実際、ソフトウェア開発の品質と、ソフトウェアの品質には相関はあると思う。とくに1990年代まで、まだITという言葉があまり使われず、OA、つまりオフィスオートメーションがソフトウェアの主な開発対象だったときには、データがちゃんと入ってデータがちゃんと届けられるということが主な処理だったため、ソフトウェア開発の品質と、ソフトウェアの品質はほぼ一致していたと思う。 そういう中で、ソフトウェア品質として、ソフトウェア開発の品質が研究された。 実際、ソフトウェア開発プロセスの基本コンセプトのひとつは、「よいプロセスがよいソフトウェアを作る」ということで、ソフトウェアプロセスの本を見ると必ずとい
辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか？ nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。（最近無くなったらしいけど）グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が
旧・Macの手書き説明書 - FC2 BLOG パスワード認証
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
バッドノウハウと「奥が深い症候群」
計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。 バッドノウハウは、ソフトウェアの複雑怪奇な仕様が歴史的に引き ずられ、根本的な改善は行われないまま、そのノウハウが文書によっ て受け継がれることによって蓄積が進行する。Unix 上で広く使わ れているツールとしてはTeX, Emacs, sendmail, bind, perl, gnuplot, procmail などは、役に立つツールであると同時に、その 複雑怪奇な仕様によって長年に渡ってユーザを苦しめ続け、バッド ノウハウの温床として悪名が名高い。こうしたツー
フリーソフト作者の自衛のための手段としてのオープンソース化と、自衛のための「寄付は受け付けないよ」 - outsider reflex
Latest topics > フリーソフト作者の自衛のための手段としてのオープンソース化と、自衛のための「寄付は受け付けないよ」 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « タブのコンテキストメニューが正常に機能しなくなった？ （The context menu on tabs doesn't appear anymore?） Main メールのヘッダに埋め込む用に文字列をBase64エンコードする » フリーソフト作者の自衛のための手段としてのオープンソース化と、自衛のための「寄付は受け付けないよ」 - May 16, 2010 Togetter - まとめ「ユーザの自由、作者の自由」 夜フクロウというMac OS X用のメジャーなTwi
GPLの境界線
GPLを利用するにあたって度々議論されるのが「プログラムの境界」という問題である。GPLソフトウェアを改良または組み込んで別のソフトウェアを作成すると、頒布する際に新しく作成したソフトウェアのライセンスもGPLにしなければならない。ここで注意しなければいけないのは、どこまでがそのソフトウェアの「境界」なのかということである。言い換えると、どこまでが「GPLソフトウェアを組み込んだ」状態なのかということである。自分のソフトウェアをGPLで頒布しようと考えている人にとっては、境界線はあまり意識しなくてもいいテーマである。優れたGPLソフトウェア資産は利用し放題のワンダーランドである。しかしGPL以外のライセンスを利用したいと考えている人にとっては、どこまでならGPLのソフトウェアを利用しても構わないのか？ということを明確に把握していないと、後で著作権法違反で訴えられることになってしまうので注意
Big Sky :: C++で軽量Webサーバ書いた。
書いたといっても結構前からあったのですが、いらん所を削ぎ落として軽量Webサーバとして仕立て上げました。 軽量とは言えど、CGIを使って結構色々動きます。 例えば、ソースアーカイブを解凍したらCGIがあって、apacheから見える場所にコピーして...とか面倒くさかったりしますよね。 おれは今すぐWebサーバを起動したいんだ！そして今いるディレクトリのファイルをWebサーバからサーブしたいんだー！ って事ないですか？blogソフトウェアをダウンロードして今すぐ試したいけど、apacheインストールされてなかった...とか悲しすぎます。 今回紹介する"tinytinyhttpd"(tthttpd)はそんな、小さい様で大きな問題を解決出来るかもしれないソフトウェアです。 mattn's tinytinyhttpd at master - GitHub tiny tiny httpd http:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OSS活動の活発さと評価の関係について
Mac OSXで使える起動するだけのPostgreSQL·Postgres.app MOONGIFT
IK.AM
PragPub May 2012 | What Makes an Awesome Command-line Application? | The Pragmatic Bookshelf
分散リポジトリ型時代のソフトウェア構成管理
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
