Archive for the ‘開発’ Category
月曜日, 3月 30th, 2009
先週の金曜日に 創る心とおもてなし― 第1回 Webエンジニア料理対決 というイベントに食べる側で参加させて頂きました。Web エンジニアが料理対決をするというおもしろいイベントで、技術評論社さんと、 COOKPAD さんとの主催するものです。
COOKPAD は毎日のようにチェックしています。お世話になっております！今回は COOKPAD さんの会社で開催されるという事で、とても楽しみでした。コンロが何カ所もあるキッチンがあって、うらやましい。電化！電化！
壁は大きなホワイトボードになっています。
料理対決の模様は Ustream.tv で生中継されていました。
われらが Yahoo! JAPAN チームのみなさん。この COOKPAD エプロンは非売品だそうです。 
リクルートメディアテクノロジーラボチームのみなさん。
COOKPAD チームのみなさん。
今回のテーマはフライパン料理対決ということでした。
Yahoo! チームはキムチオムライス。１辛〜３辛まで辛さが選べます。お客さんの好きな辛さを選んでもらうのがおもてなし。3辛でも、クリームとチーズのソースとからめると、辛さがまろやかになって美味しいです。卵が半熟で嬉しい感じでした。
リクルートメディアテクノロジーラボチームのフライパン料理はタコスです。高そうな牛肉とかエビとかの素材な上に、具の組み合わせは食べる人の自由なので、ちょっとずるい気もしましたが、それもおもてなし。アボガドソースやチリソースなども手作りされたのでしょうか？種類がたくさん合って迷います。美味しかったです。
COOCPAD チームは餃子でした。何種類かあったようですが、二種類しか食べられなかった。普通の餃子と納豆餃子を頂きました。手際が良く出来上がるのが早かったので、ちょと冷えて固くなってましたが、美味しかったです。納豆は納豆の味が強過ぎたかも。納豆チャーハンのときみたいに軽く洗えば良かったかもしれません。
ゲストの本業シェフ、ソエジマさん。料理を手伝ったり試食をされたりしてました。プロに試食されるのは緊張するだろうな。タコス試食中。
ご飯のあとはライトニングトークとセッションでした。
料理と開発の共通点などが話題になりました。ただ、美味しいものを食べたあとは頭がぼーっとするので、難しい事は料理の前が良かったです。
面白いイベントだったので、これからも続けて頂きたいです。
あと、COOKPAD ではエンジニア大募集中だそうです。女性が多い華やかな職場っぽいですよ。
結局、どのチームが勝ったの？
Posted in 食す, 開発 | No Comments »
水曜日, 5月 7th, 2008
メモ
コードリーディングの目的
- チーム開発内で他の人が書いたコードを読む
- ライブラリの動作の仕組みや設計などのテクニックを勉強する為
- コーディングに困ったときに類似のプロジェクトを参考にする
- ドキュメントが無いのでコードを読む
- オープンソースのコードを読む
メリット
- 優れたコードからテクニックやベストプラクティスを学べる
- 良いコードと悪いコードの違いを見分けられるようになる
予備知識
Java, PHP, C言語はそれぞれ、オブジェクト指向言語、スクリプト言語、構造化言語であるが、「ある処理から別の処理を呼び出し、その結果を受け取る」という階層構造と「基本的に上から下に動作し、数種類の繰り返し構文や文紀行文で処理順序を変える」という動作をみれば、同じ手続き型言語。
手続き型言語のソースコードを理解するポイントは
- モジュールの構成と役割
- アルゴリズムとその意図
- データ構造と意味
解析方法
- 静的解析：プログラムを動作させずにコードその物を読む。大局的な視点からモジュールの構造を把握するのに役立つ。
- 動的解析 ：プログラムを実行させながら読んで行く。特定箇所を掘り下げるのに役立つ。
- ボトムアップアプローチ：枝葉のコンポーネントの機能から把握して行く。
- トップダウンアプローチ：まず全体を把握し、詳細なコンポーネントを把握していく。
心得と道具
メモを取り続けていく。コードリーディングを進めて行く途中で、「今何を調査中か」を書いておく。分かった事をどんどんメモって残す、不要になったメモは捨てる。付箋紙が便利。ソースコードは 1 と l（エル） 、0（ゼロ） と o（オー）が判別できるフォントで行番号付で印刷する。
実践
- 全体構造を把握する
- システムやプロダクトの全体を説明している文書
- README ファイル
- ディレクトリ構成
- 実際にビルドしたり動かしてみる
- 静的解析
- 手続き型言語では各モジュールのエントリポイントからシーケンス図を描いてコールグラフを把握すると処理の流れがみえてくる。Unix/Linux の C のソースなら main 関数、Windows の C ならWinMain 関数などから。
- ディレクトリを検索できる仕組みが有ると良い。Windows ならエクスプローラ、Unix なら $find . -print | xargs grep -n “キーワード”
- ひらメソッド
- 動的解析
- IDE を使っているなら、ブレークポイントを付けて動かしてみる。
- コールスタックを確認する
- ステップ実行して動作を観察する
- 実装の意図を汲む
- クラスや関数の名前に着目。＞自分が実装する時も注意したい点。
- 単体テスト用のコードがヒントになるかも
参考：プログラミングの光景 第五回 コードリーディングについて 高林哲さん
WEB+DB Press Vol.34, 37?
Posted in 開発 | No Comments »
火曜日, 5月 15th, 2007
某通信会社の交換機エンジニアの人と電話で話をした時の話。アルファベットの確認で交換機エンジニアの方が「Nancy の N ですね？」と仰った。突然ナンシーという知らない人が出てきたので「？」となったのだけど、それはフォネティックコード（通信表）と言って、電話や無線での通話で文字の綴りを確認する符丁らしい。ソフトウェアでも 「T」 を 「テー」 と言ったりするけど、あんな感じ。そして分野によっても方言があるらしい。組織によってもあるのかも。
おもに固有名詞を使うみたいだ。和文の物もあって、一覧を見ると、いかにも古き良き日の日本っぽい。
フォネティックコードとは - はてなダイアリー
Posted in 開発 | No Comments »
金曜日, 11月 17th, 2006
まだ前プロジェクトが完全収束していないのですが、新しいプロジェクトが始まりました。またVB.NETの日々です。
しばらくC#で書いていたので、思わず行末に ; つけてしまったり、for文やらの書き方忘れてしまってたりで、かなりイライラしています。
がっつり残業、の日々がまだまだ続きます。無論、お肌の調子はすこぶる悪いです。
Posted in 開発 | No Comments »
木曜日, 9月 28th, 2006
Sさんが Subversion をサーバーに入れてくれたので、ちょっと使ってみる。
選択肢
・Apacheを使ってHTTPで（WebDAV使って）
・Subversion自体を単独で使う（Subversionのプロトコルで）
・SSHで使う
とりあえず、Subversion を単独で使ってみることになった。make して install して完了だったらしい。Subversion 用に作ったユーザーのルートに移動して nakaya というリポジトリを作る。
> svnadmin create nakaya
> ls nakaya/
README.txt conf/ dav/ db/ format hooks/ locks/
conf/のなかの svnserve.conf を適宜修正。
anon-access = read
auth-access = write
password-db = passwd
このとき、行の先頭にスペースを入れないように気をつける。
次に同じく conf/ の中の passwd に適宜追加。
[users]
# harry = harryssecret
# sally = sallyssecret
nakaya = password
以上で準備完了。
クライアントとしていろいろあるみたいですが、TortoiseSVN を使ってみる。日本語化も対応している。インストールしたら、エクスプローラ上にて右クリックで Subversion の操作ができる。まだ恐る恐る触ってる程度です
参考
・Subversion によるバージョン管理
・ankhsvn Visual Studio.NETプロジェクトをSubversionで管理するためのツール
Posted in 開発 | No Comments »
火曜日, 8月 22nd, 2006
最新刊より一つ前になるのですが、WEB+DB PRESS Vol.33 で GREE の岩崎匡寿さんが GREE 内のチーム開発環境について執筆されていました。その中で、GREEでは社内連絡用と仕様をWikiで連携していると書かれています。
それに倣って、うちの会社にもwikiを導入できないかと思い、とりあえず社内サーバーにインストールしてSさんと使ってみる事にしました。ちょっと使ってみてわかったのですが、うちの会社の場合、wikiを効率的に使えるように改善すべき点がいくつか洗い出せました。
・wikiとは何か、ということを広める（ここからかー）
・wikiの文法を知らなくても簡単に書き込めるモジュール作成
・顧客情報、開発情報を書く時の標準フォーマット策定
・IMなどの会話情報をwikiにポストするプログラムの作成
などなど。
私は最近まで、ソフトウェアには一から十までそろった仕様書が必要だ、と頑なに考えていたのですが、何十人、何百人という規模の開発ならまだしも、一人もしくは数人で開発するソフトウェアではあまり形式ばった仕様書は必要ない、と感じるようになりました。形式ばった仕様書にこだわりすぎて開発スピードが落ちるのは、何のために書いているのかわかりません。最低限の情報を詰め込んだものをwikiなんかで全員に共有できれば十分なのではないでしょうか。何が重要なのかを十分考慮する必要はありますが。
それから、お客様への訪問履歴と作業内容、開発状況などを書いていけば、顧客台帳や開発状況が一覧できるデータベースが出来上がるはずです。
大きい会社が仕様書や開発体系をきっちり（？）決めているのは、大人数の作業効率を管理しやすい様に、そうせざるを得ないからで、それに倣って小さい会社がそのまま大きい会社の真似をしてスピードや効率を落とすのは良くないと感じます。
WEB+DB PRESS編集部 / 技術評論社(2006/06/22)
Posted in 開発 | No Comments »
木曜日, 8月 10th, 2006
新しいプロジェクトはASP(C#)+SQL Serverで開発予定。クライアント側のUIについては、必要ならばNetAdvantageなんかも使ってみようと思う。
技術検証の為、でプロトタイプを作って見る。初めてSQL Server 2005を触ってみた。
ユーザーの考え方。
Windows 認証を利用して、OS に登録されているユーザーを SQL Server で使うことができる。これは、複数の SQL Server がネットワーク内に存在する場合、Active Directory と組み合わせて使うのに便利（らしい）。
もうひとつは、SQL サーバーにユーザーを作成する方法。こっちの方法はなぜか上手く行かなかった。ログインユーザーを作成する際にエラーが出る。OSによって使えないコマンドがあるみたい。今回の環境は w2k Server なので、w 2003 Server だと上手く行くのかもしれない。
Visual Studio 2005 との連携
Visula Studio 2005 をインストールすると SQL Server Express と管理ツールも一緒にインストールされる。これで、別にDBMSをインストールしなくてもDBが使える。が、今回は別サーバーに SQL Server 2005 をインストールしたので、リモート接続とする。 SQL Server 2005 はデフォルトではリモート接続が出来ない設定になっているので、”SQL Server セキュリティ構成”というツールを使って設定しなおす。参考→ http://www.microsoft.com/japan/sql/ssj/tips/01.mspx
さらにVS2005にはデータベースエクスプローラが付いてて、開発に使うDBを操作するのに便利。
Posted in 開発 | 6 Comments »
土曜日, 6月 3rd, 2006
※読前メモ。いつにもまして文章がまとまっていません。
ゴールデンウィークの後半から一日も休みなしで、殆ど朝から深夜まで働いていました。でも、変に元気です。後からドッとくるのかも。今日は久々に休日だったのでマッサージに行ってきました。
今回の仕事を終えて（まだ残件はあるけど）改めて思ったことがあります。いい大人が何人、何十人と集まっているのに、何でプロジェクトの進捗は遅れてしまうのでしょうか。これは皮肉でも愚痴でもなくて本当に疑問に思っていることです。これまで「スケジュールは順調です」というプロジェクトは見たことがありません。私のまわりだけだろうか？
「熊とワルツを」に書いている、リスクの多いタスクをこなすことは成長するチャンスだ、というのは同感です。でもリスクにもほどがある場合がある。
何を基準に予定を立て、進捗率を計算すればよいのか。「画面数」という人が多いとおもうけど、単純にそれでは計れないことが多い。「一機能X日といっても、その技術者の技量によるし、その幅は広い。技術について熟知していて、マネージメントもできる人じゃないと、その進捗基準を見極めるのは難しい。でもそんな人はそうそういない。→コーディング、テストする人たちとの認識のズレ。→正確な計画が立てられない。進捗の遅れ
技術検証が十分でない、もしくは技術検証時に想定できない様な問題が起きるとシステムの土台が揺らぐ→基本的な部分の見直し→全体の手直し発生→進捗の遅れ
不思議とそういう基準が定まっているプロジェクトってない。そもそも、そんなもの無い？プロジェクトマネージャやプロジェクトリーダー個人の裁量に任せられるのか？
これについてはまたこの本を読み終わった時に考えた事を追記。
あと、この言葉も面白いと思ったのが、ブルックの法則。
遅れているソフト開発に人員を追加すると、さらに遅れるという法則
どんな現象にも名称がついているのですね。
こういうことを学術的に勉強をしてみたいとも思うけど、やはり現場でソリューションを探るほうが効率がよいのかな？テストケースは身近にゴロゴロしてるし。
これと同じようなことが身近に起こっている。システム作っても現場の流れとか仕組みが変わって、キリが無い。現場の体制を変えるのは、実際、難しい。けど、だらだら続けても双方にメリットが無いと思うのだけど。ああ、なんか愚痴愚痴書いてしまってる気がする。
これって、ソフトウェア開発に応用できるのか？と最近思ってきた。工場のラインのように成果が明確でないし。明確な測定基準を作ればよいのか。
ToDo:これもヨムベシ。Joel on Software
Posted in 開発 | No Comments »
水曜日, 4月 12th, 2006
学びて思わざれば則ち罔し。
思いて学ばざれば則ち殆うし。
ソフトウェアの仕事だと、
・資格や知識を持ってて理屈はこねられるのだけど自分で作れない。
・作業は出来るけど、本質を理解してないから応用できない。
昔の人もこういうことを言ってるくらいだから、どんな分野でも通じることなのだろうな。”学んで思わなければ”ならないと感じる今日この頃。
多くの本を読み、多くの人を知り、多くの人を理解することによってあなたの視野は広がり、あなたは善良で純粋な人間になり、他の人のために役立つ人間になるでしょう。
巴金（ばきん）『第四病室』
良い言葉を知った。
via. 田中紀男さんの会計事務所HP > 古典に学ぶ
Posted in 開発 | No Comments »
日曜日, 4月 2nd, 2006
最近はオープンソースじゃない製品を使って開発をしているので、機密事項上、ブログに書けることが少ないのですが、昨日味わった敗北感を書きとめておく。
今、開発でユーザーズインターフェイス側に使っているのはある会社のパッケージソフトです。VBのフォームとJavaScriptを足したような開発環境で、基本的な機能しか備えていないので、ちょっと面倒な処理は自分で書かなければなりません。
配列に入った重複した値をまとめる、というコードを書きました。一応形的には出来上がったのですが、きれいなコードではありません。多分、数ヵ月後、自分でも読むのに苦労するだろう、というコードです。
Sさんに「もうちょっと良い書き方ないですかね？」と相談したら、鮮やかに解決案を提案してくれました。行数にしたら、5,6行の違いですが、コードが読みやすくなるし、パフォーマンスも飛躍的に向上する書き方でした。
最低限のある物を使って読みやすい、実行しやすいコードを簡単に書けるSさんに敗北感を感じ、ヘコミました。自分は Geek にはなれません。でもこういう場面に一年に何回か遭遇すると、感動します。
学生時代の微分積分の先生が「いかに楽をして解くかを考えるときれいに解ける」と言っていました。こういう人は先生に向いていないのではないかと思ったけど、出来る人は確かに楽に解いている（書いている）。
こんな私でも、半年に一回くらい自分でも信じられないくらい、奇跡的に美しくて機能的なコードが書けることがあるから、この仕事が楽しいのだと思います。そして他の人の綺麗な考え方に遭遇できるのもこの仕事の楽しい所です。
Posted in 開発 | No Comments »
