デベロッパーズサミット2013に参加した - rabbit2goのブログ
昨日(2013/02/15)は目黒雅叙園で行われていたデブサミ2013に参加してきた。今年も相変わらず参加者が多く、休憩時間に混んでいる通路を通って他の部屋に移動するのは大変だったけど、開発の最前線で闘う（あるいは現場から逃げ出してきた？）開発者の熱気を感じるイベントだった。 沢山の講演の中でほんの一部のセッションしか参加できなかったものの、今回は大きな会社の講演よりも個人レベルに近い形での発表がずっと興味深かった。せっかくHTML5の話を聞きに行ったのに、Windows95から始まるインターネットの変遷を延々と説明されても白けてしまう。聞き手としては、技術開発の最前線で、今何が起こっているのか知りたいのだ。そんな中、特に良かったのは下記の2つの講演だった。 NoSQLの野心的な使い方〜Apache Cassandra編〜（岸本康二さん） NoSQLの正しい理解・誤解の紹介。Cassand
「詳解Objective-C 2.0（改訂版）」を購入した - rabbit2goのブログ
Objective-Cのバイブルとも言える荻原剛志先生の「詳解Objective-C 2.0」の改訂版が出ていたので購入した。前回の出版から2年半ほどしか経っていないが、iPhoneの爆発的な普及によりObjective-Cのニーズが高まり、情報の更新が必要になったようだ。 書籍の前書きには下記のように記載されている。 本書は、2008年出版の『詳解Objective-C2.0』に新たな内容を盛りこんで再構成したものです。 以前の本と見比べてみたところ、下記の点が大きく変わっていた。 ブロックオブジェクト(Blocks, GCD)の説明が追加されていた。（14章） 並列処理で、NSOperationの説明が追加されていた。（19章） MacOS XとiOSで異なる箇所の説明が追加されていた。（但し、章単位でMacOS Xのみの内容（17章）とか、節単位でiOSには該当しない(NSConne
Xcodeの静的解析機能が便利だ - rabbit2goのブログ
最近、Xcodeの静的解析機能が面白いので、iPhone開発時によく使うようになった。以前は別途インストールしたclang analyzerを使っていたけれど、今はXcodeの“Build and Analyze”メニューから呼び出せるので手軽だ。 Running the analyzer within Xcode この静的解析機能を使うと、興味深い指摘をしてくれるのでいろいろ試してみた。開発環境は下記の通り。 MacOS X 10.6.4 (Snow Leopard) Xcode 3.2.4 メモリリークの可能性 下記のコードを解析させると、「アナライザ結果」として"Potential leak of an object allocated on line ..."が指摘される。 - (NSString*)test1 { NSString *data = [[NSString alloc
Objective-Cの宣言プロパティにはまる - rabbit2goのブログ
iPhoneの開発において、Objective-C 2.0で導入された宣言プロパティ(declared property)にはまったので覚え書。プロパティ経由でアクセスする度にリファレンスカウンタが増加してしまい、結果としてリークするという状態が発生した。単に参照しているだけなのだから、インスタンス側の状態は何も変わらないハズだし、変わって欲しくない。それなのにリファレンスカウンタが増えてしまうとは、一体どういうことなのか？ 試しにこんなテストコードを書いて、いろいろ調べてみた。 NSLog(@"(1) %d", [self.selectedImage retainCount]); NSLog(@"(2) %d", [self.selectedImage retainCount]); NSLog(@"(3) %d", [self.selectedImage retainCount]); プ
Agile Tour Osaka 2010に参加してきた - rabbit2goのブログ
昨日はAgile Tour Osaka 2010に参加してアジャイルを勉強してきた。一言でアジャイルと言っても、言葉を使う人によって、スタンスや方法論が微妙に異なっていたりするが、その幅広い考え方を柔軟に受け止めるのがアジャイルの特徴かも知れない。会場にはそのような多様なバックグラウンドを持ちながらアジャイルを目指す人が多く、非常に活気のあるイベントだった。 http://www.agiletour.org/osaka.html 10月30日 AgileTourOsaka2010 以下、講演メモの抜粋に感想を付記してみた。 チケット駆動開発がAgileになる理由 〜No Ticket, No Commit!〜あきぴーさん チケット駆動開発の基本的な考え方や、その導入効果について紹介。障害も仕様変更も全てチケットで統一して管理することで、成果物を管理しトレーサビリティを確保できる。 Redm
Amazon EC2でBitNamiのTracを利用する - rabbit2goのブログ
Amazon EC2のAMIリストを見ていたらTrac導入済みのものを見つけた。最近は単なるLAMPだけではなく、目的に応じてTracやRedmineがインストール済みのAMIがいろいろ公開されているらしい。このAMIはBitNamiが提供しているもので、UbuntuにTracが既に導入済みとのこと。AMIなので直ぐさま利用可能な状態にあるわけだ。 Trac Cloud Hosting, Trac Installer, Docker Container and VM http://aws.amazon.com/articles/Community/4382 試しに利用料金が最も安いMicro Instance*1を選んで起動させてみた。 Announcing Micro Instances for Amazon EC2 Tracのバージョンは0.12。プロジェクトリスト画面は "http:
日本的な働き方 - rabbit2goのブログ
先日の朝日新聞に田中和彦氏のエッセイ記事が載っていた。朝早くに職場へ来てランチを手っ取り早く済ませつつ仕事を続け、夕方になるとさっさと帰ってしまうアメリカ人の働きぶりと、ランチタイムにのんびりする日本人を比較した考察だ。もちろん、どちらが良いとか悪いという問題ではなく、それぞれのお国柄もあるし文化の違いもある。だから、記事の主人公であるIさんは、両者を比較した上で、このような結論を冷静に下している。 確かにアメリカ流の仕事は密度が濃い。だからと言って、日本人がそれを見習うべきだとも思えない。Iさんはひそかにこう考えている。「ダラダラした働き方こそ日本人に合っているのでは」 http://www.asahi.com/business/topics/hataraku/TKY201010110121.html 上手い結論だと感心しつつ記事を読み終えたのだけど、その通り、日本の会社では「忙しい」を
DoxygenとPlantUMLを組み合わせて使う - rabbit2goのブログ
以前にTracのプラグインと連携させて動かしたPlantUMLを、今回はDoxygenから使ってみた。下記のサイトに概要が載っているので分かると思うけど、目標は「ソースコードのコメントに書いた記述に従ってPlantUMLにUML図面を生成させ、これをDoxygenが出力するHTMLの中に含める」ことだ。 Integration with Doxygen documentation tool 動作環境は下記の通り。 MacOS X 10.6.4 (Snow Leopard) MacPorts 1.9.1 graphviz @2.26.3_2 (MacPorts) doxygen @1.7.1_0 (MacPorts) 手順は下記の通り。 環境変数にGRAPHVIZ_DOTを設定する。 $ export GRAPHVIZ_DOT=/opt/local/bin/dot ソースコードにコメントを記
優れた開発者の条件 - Basic
周囲にはいろいろなソフトウェア開発者がいるけれど、彼らを観察していると、優れた開発者にはある共通の性質があることに気づく。例えば、こんな感じ。 質問ができる 渡された資料を噛み砕き、関連する情報を集め、何を作るのか認識できるくらいなら普通のレベル。優れた開発者は、そこから自分がやるべき事について意図を説明できるし、確認のための質問もたくさん出して来る。質問の量とソフト開発の実力は、そのまま比例するのではないかと思う位だ。逆に言うと、何も質問をしてこない開発者は、自分だけの理解で満足してしまっているので、その理解を他人に確認してもらうこともなく、要求されたものとは全く異なるものを作ってきたりする。 大局的なモノの見方ができる どうでも良いことを細かく突っ込むことが出来る人は多いけど、そのスタンスから一歩引いて広い視点から見た場合の課題を指摘できる人は少ない。例えば、過去に発生した障害を教訓と
必要なのは改善を継続する力 - rabbit2goのブログ
あるソフトウェア開発関係のイベントに参加した同僚に感想を聞いてみた。 特に目新しい情報は無かった。発表されている事例は当たり前のこと。やっていることは自社と変わらない。 それはその通りかも知れない。品質改善に関して全く新しいアイデアはなかなか出てくるものではないし、銀の弾丸なんて存在しないものなのだ。皆、日々の業務の合間に知恵を絞って少しずつ改善を続けているのであり、一発大逆転のホームランという改善策なんてあり得ない。実際に取り組んでいる手法だって、基本的にそれほど大きく変わるものではないと思う。 強いて違いを言うのなら、改善活動が上手く行く組織というものは、小さな活動を継続的に徹底して行うという実行力が優れているように思う。「忙しい」「いつかはやりたい」「面倒だ」と言い訳を並べるチームは、ずっとその理由を言い続けるものだし、仮に着手しても直ぐに放り投げてしまうことが多い。「当たり前のこと
やっぱりベテランは使えない - rabbit2goのブログ
ソフトウェア開発の現場にいるベテランには、他の人の手本となるような達人もいるけれど、その一方で見習ってはいけない悪い見本の人も少なからずいる。その一例。 開発資料を作らない 「ソースコードを読めば分かる」「資料を書くのは労力の無駄」と豪語して資料を何も作らない。後からフォローする人は、そもそも何をやっているコードなのか？などコードの設計思想や背景を読み取れないので苦労する。 自分の立場を分かっていない 開発チームを良い方向へ導くとか、若手の指導を行うという積極的な態度に欠ける。チームへの協力的な姿勢が無く、組織のあり方とか、ビジネスの方向性といった視点を持っていない。 知識を共有しない 「自分の持っている知識は大したことない」と謙遜するそぶりを見せながらも、自分からは決して情報発信を行わない。他人の情報には文句を付けるのに、自分からは何も出そうとしない。 新しい技術に挑戦しない 歳をとって
Tracのwikiに図面を入れる（PlantUML編） - rabbit2goのブログ
Tracのwikiに図面を入れるの続き。GraphvizやMscgenも良いけど、やっぱりUMLの図面が欲しいと思うことは多いはずだ。そこで今回はUMLの図面を入れてみる。テキストで記述したスクリプトからUMLを描くためのツールとして、PlantUMLというJavaのソフトがある。 テキストで記述して図に出力するUML記法·PlantUML MOONGIFT このツールをtracから呼び出すプラグインを作ってくれた人がいた（ページの履歴を見る限り、つい最近のようだ）ので、早速テストしてみた。動作環境は前回と同じ。 PlantUML 導入対象 Open-source tool that uses simple textual descriptions to draw UML diagrams. Graphviz PlantUmlMacro – Trac Hacks - Plugins Mac
Trac0.12の便利な機能 - rabbit2goのブログ
前回はTrac 0.12の更新を行ったので、今回は新しい機能を紹介してみたい。メジャーバージョンアップなので新機能が多数含まれている。詳細は本家の情報を参照してもらうとして、ここではユーザーにとって嬉しい改善点をピックアップしてみた。 Highlights Translation of Trac in your language, using Babel. Multiple Repository Support per environment Improved Wiki, more powerful syntax and nicer user interface with automatic preview in side-by-side editing mode Improved Ticket user interface, with editable comments and auto
そのプライドが邪魔をする - rabbit2goのブログ
仕事で経験を積むにつれと、大体のことは自分で出来るようになるし、発生する問題に対しても対処できるようになる。ソフトウェア開発なら、自分でソースコードを書くだけではなく、要件定義や効率的なテスト作業が出来たり、確実なプロジェクトの管理を行えるようなものだ。なるほど、頼りになるベテランとはこんな人のことを指すのかと感心する反面、これぞベテランの対応だと思わざるを得ない場面にも度々遭遇する。例えば、こんな時だ。 勉強会の案内が来た時、題名を読んだだけで「自分には関係ないこと」と門前払いする。 新しい技術の話が出た時、内容を知らないのに「○×みたいなものでしょ」と独りよがりの論評を行う。 若手が出した改善提案に対して、客観的な評価より自分の経験に基づく判断を優先させてしまう。 問題点をアレコレと指摘できる反面、それを解決するための自発的なアクションを取らず常に評論家の姿勢を貫く。 世の中の新しい技
Tracのwikiテンプレートを利用する - rabbit2goのブログ
Tracのwikiには予めテンプレートを用意しており、新規ページに作成時にはこれを使うようにしている。目的は下記の通り。 記載項目の共通化 例えば、wikiページに目次やナビゲーションを表示する下記のプラグインは全てのwikiページで利用しているが、こんな項目を新規のwikiページへいつも書くのは面倒だ。テンプレートに予め記載されていれば書く手間が省けて都合がよい。 TracNavMacro – Trac Hacks - Plugins Macros etc. TocMacro – Trac Hacks - Plugins Macros etc. 同様に、見出し項目（構成）やプロジェクト固有の情報もテンプレート化して準備しておくと記載が統一されて便利だろう。 マクロの記載 Tracプラグインを幾つも導入していると、その記載方法が直ぐに思い出せなくて困ることがある。標準のwiki記法に記載さ
Snow LeopardならTracのインストールは簡単 - rabbit2goのブログ
以前ならTracのインストールは面倒で気軽に導入できるものでは無かったのだけど、今はとても簡単だ。Snow Leopardの場合、MacPortsを導入後、下記のコマンドを叩くだけでよい。 $ sudo port install tracこれだけで、PythonやSubversionなど関連するソフトまで全てまとめて導入してくれる。trac-adminを使ってプロジェクトを作り、tracdをサーバとして動作させれば直ぐに利用可能だ。 $ /opt/local/bin/tracd -p 8080 --basic-auth "*",/Users/foo/trac/users, -e /Users/foo/tracMacOS XにはApacheがインストール済みなので、実はApacheとの連携も簡単だったりする。mod_pythonを使う方法より、fcgiで使う方が手っ取り早いだろう。手順はTr
全ての仕様にURLを付けたらどうか？ - rabbit2goのブログ
tracの障害チケットに目を通していたら、該当する仕様としてこんな記載が載っていた。 ○×仕様書の□ページの上から△行目に記載されている〜について... 大きな偏見だと思うけど、Word等で記載されたダラダラとした文章が並ぶ仕様書を見ると「これは要注意」という黄色いランプが点滅してしまう。複数のセンテンスから成る文章全体で一つの仕様が構成されるという趣旨は分かるけれど、そもそも「どこからどこまでが一つの完結した仕様」なのか分からないし、他の資料との紐付けがやりにくい。例えば、上記のような書き方では、資料に追記・削除が行われたらレイアウトが崩れ、意味を成さない記述になってしまうので、後から見た人は関連する箇所を辿れないことになる。 仕様書は小説でもエッセイでもないのだから凝った表現は不要であり、もっと形式的な書き方に力を注ぐべきではないかと思う。だから仕様書の記載では章立てを確実に行い、個々
XP祭り関西2010に参加してきた - rabbit2goのブログ
昨日はXP祭り関西2010に参加してきた。たくさんの人が集まっていたので少々驚く。時代の流れはアジャイルなのだろうか？XPやチケット駆動開発の講演より参考になった点を抜粋。 倉貫義人さん Social Change! ソニックガーデン SonicGarden 倉貫義人のブログ アジャイル開発の本に載っているのは開発の真ん中のみ。その前後の作業は載っていない。だから受託開発のような現場でアジャイルを持ち込むと上手く行かなかった。 受託開発は基本的に製造業型のビジネスモデル。買う時が最高品質なので、ここに合わせて開発、テストを行うが、クラウド型サービスでは使っている時点が最高品質。考え方の切替が必要だった。 アジャイルをやっているという実感は無いが、日々の取り組みとしてはごく普通のこと。自分が変われば、周囲を巻き込んで上手く行くもの。 あきぴーさん 【公開】XP祭り関西2010発表資料「チケッ
アナタの常識、ワタシの非常識 - Basic
仕様書に書かれている内容や、tracのチケットにコメントされている記載をチェック。確かに日本語の説明文が書かれているけれど、何だか意味が通じないので担当者に問い合わせを行う。しかし、その回答はなぜか怒ったものが多い。 「この仕様書の記載は常識です」 「そのような説明は当たり前です」 「良識の範囲内で記載しています」 確かに当人にとっては「常識」のことなのだろうけど、それが開発チーム全員の常識と一致するかと言うとかなり怪しいと思う。常識とは「各自がそれぞれ勝手に思い込んでいるもの」であって、決して「全員の共通の認識」と合致するとは限らないのだ。ソフトウェア開発に関わる人なら、一つの仕様書に対して開発者全員の認識を合わせることがいかに大変なことか分かってもらえると思う。 特に日本語の文章の場合、明確な主語が無くても暗黙のうちに伝わってしまうし、少々説明が欠けていてもあうんの呼吸が伝わってしまう
開発プロセスと技術の相関関係 - rabbit2goのブログ
上手くソフトウェア開発が出来るチームは、開発プロセスも良好だし、技術・スキルもそれなりに高いようだ。細かく見ていけば問題が無いわけではないけれど、それらは許容範囲内に収まっているし、絶えず改善活動を行っているせいか昨年の状態より良くなっていることが明らかだ。「良好なプロセス→高いレベルのアウトプット→さらにスキルアップ」という正のサイクルがうまく回っているように見える。 その一方、リリースしたソフトウェアにデグレばかり出しているチームは、開発プロセスも悪いし、技術的な問題も多く、スキルの課題も少なくない。毎日残業をしている割には抜本的な対策が取れておらず、「障害が多い→対策に追われる→レベルを上げる余裕が無い→さらに障害が生まれる」という負のサイクル（死のサイクルか？）にはまり込んでいるようだ。 不思議なことに「プロセスは良いけれど、技術が追いついていない」とか「技術はあるけれど、プロセス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
