マキノ式ブログ

たいしたことじゃないんです。
期待した人、ホントすいません・・・

実は私の居る会社ではオフショアと並行して在中国日系企業向けのWEBサイト構築も行なっています。(日本向けでもやってます。)
このWEBサイト構築の要望は意外に多くクリエイティブおよび、それに付随するシステム部門で早急な効率化が求められています。

その効率化計画の一環としてSubversionを導入する運びとなったのですが、リポジトリの作成やスケルトンの準備など意外に面倒な作業が多いわけです。
通常のファイルサーバの様に気軽にというわけにはいきません。なにせクリエイターの方はEclipseを使ったりssh叩いたりしませんからｗ

そんなわけで、ちょこっと作ってみたのがこれです。TotoiseSVNと併用すれば一般人でも十分容易にSVNが扱えるかと思います。

裏マキノ式 EasySkeletonForSvn
http://www.makino-style.org/ura/index.php?EasySkeletonForSvn

要するに、プロジェクトのスタートアップ時に作るSVNのリポジトリ作成とスケルトンの作成をサポートしてくれます。
小さな便利ですがスタートアップ時、スケルトンの準備次第ではプロジェクトの初動コストを抑えることができます。こういうのは小さい積み上げなので

#改善とか問題とかありましたらコメントどうぞ

最近、あるお客様の会社内で品質向上委員会なるものが立ち上げられました。
そのテーマはそのものズバリ「品質の向上を如何にして実現するか」であります。
私の居る会社が発注をしていただいているということもあり、私もメーリングリストに加えてもらえました。
(H.S様ありがとうございますm(_ _)m)


これが社内委員会ながらメルマガを定期発行したりと、なかなか活発な議論が展開されております。
例えば、役に立つ仕様書というのは？役に立つ品質管理とは？といった原点ながら非常に重要な内容が話し合われており大変勉強になります。

私は、この社員およびパートナーを巻き込んでの「品質向上委員会」という試みの中にアジャイルな精神を見いだすことができました。
確かに、アジャイルといえば一見してスマートで華やかな名前（見える化やTDD、ペアプロなどなど）がつきまといます。

つまり、なにを言いたいのかといいますと・・・
アジャイルと立派に銘打っていない仕事（何かを成し遂げるという意味においての仕事）の中に、変化への対応と、次への準備というまさにアジャイルな精神を見いだすことができたことに驚きを感じているのです。
これまでは、私が未熟だったから見えてなかっただけなのですがorz

アジャイルと言う名前や勢力に何となく嫌悪感を持っている技術者の方々は多いと思います。（実は私もアジャイル関連の用語乱立にいささか食傷気味です。改善をカイゼン、看板をカンバン、見える化・・・・はっきり言って超嫌いですｗ）
でも、次はうまくやろう、何が悪かったのだろう？と思ったらそこが出発点だと私は思います。
アジャイルなんか気取らなくても、一歩一歩より良くしていく事が重要であって、説教臭くてお仕着せがましい価値やプラクティス、ドグマなんか気にする必要はないのではないでしょうか？：）

#誤解の無いように言っておきますが、アジャイルな精神や定義された手法は非常に有用ですし、私は好きです。でもそろそろ、宗教じみてきたアジャイルというブランドの棚卸しをやってのける必要があるのではないかと思う今日この頃です。

だから、正しくは「脱、アジャイルブランド」ですね。

アジャイル勘違い集
http://www.objectclub.jp/technicaldoc/xp/agile_misunderstanding
以前、大変お世話になった方々や友人が書いたFAQです。為になります。

コードを綺麗に保つ必要性を改めて理解しました。
プログラマはプログラミングを生業とする生き物であるゆえにプログラミングを好みます。乗ってるときは一種のトリップ状態にすら陥ります。

それゆえプログラマはコードを書き散らすのが好きな場合が多いです。特に覚えたてのころは楽しくて仕方がないため手に負えません。
しかし、テストコードを伴わない即物的欲求に従ったコードは誰も読むことのできない変更することの不可能な屑コードに成り下がります。
もし、テストを行わずに客先に成果物を提出できる心臓の持ち主ならこちらへ進んでくださいｗ
» 続きを読む

C#をやり始めて1ヶ月、言語仕様が似ているとはいえ違う環境での仕事は自分が思うように運びません。いまだ一人では何もできない赤ん坊状態で、辛いことこのうえないです。
そして、自分にとって合格といえるようなレベルの物がまったく作れないことが非常に口惜しく悔しくなります。
つい、心情的に
「クソッタレ、これがJavaならなぁ・・・・」
と思わずには居られないのですが、そこはそれ自分が門外漢であるという甘えがあるわけです。これは専門外の仕事をしたときに誰しもが抱く感情かもしれません。
さて、逆境にさらされて顕著になった自分のウィークポイントとしては
・アイデンティティがJavaに強く依存している
・焦燥感を上手に昇華できない
・プライドを捨てきることができない
の3つだと感じました。
特に最後のプライドを捨てきることができないというのは非常に致命的です。プログラマの真のプライドとは、安っぽい自尊心をどこまで捨てて技術を磨くかにかかっていると思います。

ここ1年ほど、私は「自分の成長をコントロール」するべきだと考え、なるべく弱点を自覚するようにしていますがなかなかどうして弱点というものは次から次へと出てくるものです。ｗ

#しかし、このC#によるGUIの経験はSwingによるアプリケーション構築へすすむ良い一歩になると思っています。

これは、C#村の話です。
C#村はMicrosoft谷の下流に位置する川辺の村です。C#村にはJava山から来た人と、Microsoft谷から来た人が暮らしています。村の人々は普段は仲良くしていますが、自分の信じる神様の話になると村を二分する大論争になります。

ある日、C#村に水を入れたらお湯になる魔法のADO.NET箱が届きました。Microsoft谷の人はゲイツの神託どおり大事に使いましょうと言いました。一方、Java山の人はゴスリングの十戒に則ってあれこれ試してみようと言いました。でも、クライアント町から来た人はお湯がでれば気にしないようです。
村の住人は再び仲良くなりましたが、やっぱり皆さん布教に余念がありません。
私？私はJava山のきこりどんです。

技術的なメモです。
サーバ側でなく、ローカル側でDataTableから特定のカラムでDISTINCTする方法についてのドキュメントです。
http://support.microsoft.com/default.aspx?scid=kb;en-us;326176

一見して非常に効率が悪いですがしょうがないです。
活用される局面としては、
・単純にSELECTしてきた時点でのDISTINCTが欲しい場合（一貫性が欲しい場合）
・取得した時点でのDataSetに対して複数のDISTINCT結果が欲しい場合
・よんどころなき事情がある場合
が考えられます。当然ですが、プログラム側で処理している以上、数百件オーダを超えるものは実用的ではないと思われます。（だってforeachで回してるだけだし）

私の場合は最後でして・・・・
・ADO.NETにおいて型付のDataSetを利用している場合でCRUDしつつ、DISTINCTされた結果も欲しくて、なおかつ複数のDataSetを用意できない状況
つまるところ、実装が仕様に激しく縛り上げられているわけであります。orz