2年ぶりの更新再開

実に2年数ヶ月ぶりになりますが、
ブログ更新を再開することになりました。

可能な限り社員全員で持ちまわって、
2日に一度ぐらいは更新していけたらいいなと思います。

いいなと思います！

高橋@MC

降参…ですっ。 ＞＿＜；

先日、Microsoft様に（モニターとして）いただいたWebサーバに、何かWebアプリケーションを入れて公開しようと立てた作戦の件…

やっぱり・・・というか、公開日の本日まだ公開できておりません。。。

原因は、追加した「試練」の項目なんです。

・どこかプログラムを1か所以上改造する。（別プログラムとの合体可）
・インストールしたプログラムの活用法も併せて提示する。

■今回学んだこと。
＜その１＞
ダウンロードできるWebアプリケーションって、既に使用目的が限定されてるものがほとんどで、インストールした時点でほぼ使用方法が決まっている。

＜その２＞
アイデア的に面白そう＆魅力的なWebアプリケーションは、そのサイトでのみ運用されていて、ソースやインストーラーを配布・公開していない。

他人様のアプリケーションの「パクり」と安易な「改造」では、
私が公開したい（皆様に楽しんでいただけそうな）ものは公開できない
ことが、よーくわかりました。。。
当たり前といえば、当たり前の話なのですが…

ともかく、仕切りなおします。

このオトシマエは是非改めて・・・
ちょっと煮詰まりすぎてしまったので、電気屋さんで充電してきます。

byこころ /（＞＿＜；）\

Webサーバで何しよう？

昨日の投稿にありますとおり、Webサーバをモニターとして頂きまして、ワタクシ個人的にちょっと（というより、かなり）やる気になってます。

とりあえずWeb公開はしてみたモノの、看板だけで何も中身がないのはモニターとしては失礼な気がするし、何より勉強になりません。

そんなわけで、作戦考えてみました！

＜作戦。その１＞
何か作ってみる！
無理です。。。プログラム勉強してるのですが、
Javaで足し算と引き算の結果を出すのが精一杯！
今から作ったプログラムの公開までに
どれだけ時間がかかるかわかりません。

＜作戦。その２＞
とりあえず何かWebアプリケーションを入れてみる。
これなら、できそう！
というか、できる。
でも、何も考えずにインストールだけするのはつまらないので、
自分に試練を課してみる。

・どこかプログラムを1か所以上改造する。（別プログラムとの合体可）
・インストールしたプログラムの活用法も併せて提示する。

自分に対するハードルを上げすぎるのは更新が止まって良くないので、
この程度にしておいてあげます。

最初のプログラムの公開は…

 

6月6日

 

思いつきと、「ぞろ目」な日を選んでみましたが、できるかなぁ。。。

とりあえず、Web検索してみたら↓のサイトがHitしたので、
今晩休む前にでも何を入れるか考えてみますね。

http://www.yumemaboroshi.net/

byこころ（P.N.）

Webサーバ公開してみました。

久々の投稿になってしまいました。

さて、先日連休前にマイクロソフトのスキルチャージプログラムのWebサイトでサーバマシンとOSセットのモニター応募がありまして、早速応募してみたところ、本当にサーバが事務所に届きました。

モニターの参加条件が
・届いたサーバでWebサーバを構築すること。
・構築したサーバを1年間公開しておくこと。

でしたので、
連休＋αを利用してWebサーバ構築と外部公開を行いました。

<エムキューブ実験場>
http://imocal.jp/

まだ、何もコンテンツがありませんが、今後既成のオープンソースソフトウェアをインストールしてみたり、自作のWebアプリケーションを公開していけたらいいなと思っています。

※アクセス解析のCGIは仕込んでいますので、ある程度誰がアクセスしたかは解るようになってますよー。

byこころ（P.N.）

P.S.もぅ、楽しいのでほぼ毎日サーバいじってます。

RIA

ずいぶん出遅れましたが、最近silverlightを知りました。

そのsilverlightとよく比べられているFlexというかFlashについては、
2年前（Flex2.0がでたころ。今はver3）にver1.5をやっていたのでその後も調査をしていました。

当時Flex環境は高価だったので、オープンソースのリッチクライアント開発環境「OpenLaszlo」をやってみました。
しかし、OpenLaszloは独自言語のため廃れゆく運命でした。

そこでまたFlexのスクリプト言語であるActionScript（以後AS）に戻って
FlexBuilderを使わずにフリーなAS開発環境↓
http://www.flashdevelop.org/

しかし、画面デザイン部分はVBのようにフォームにボタンを配置しながら作りたいというわがままから、
AS用GUIフレームワークAsWing↓
http://builder.japan.zdnet.com/news/story/0,3800079086,20360912,00.htm

ところで、RIA開発の嫌な思い出の一つに「デザインとロジックの分離の難しさ」があります。

2年前の業務では、
私が作った画面（ロジックも含む）を、別の人がデザイナーが望むレイアウトや動きに修正するという2段階開発をしていました。
このデザイナー修正をすると、画面の定義はもちろんロジックにまで手が入るのです。

修正する人は元のロジック解読からするので大変だったと思います。
更に、その後バグ修正がきたりすると大変です。
なぜなら、自分で作ったのに見たことのない構造になっていることがあったからです。

これらはFlexのせいではなく、カスタマイズしたCairngormフレームワーク（※１） や設計思想が悪かったからなのだと思います。
当時の設計書も、既存の画面遷移図などの画面設計書ではRIA設計をカバーしきれず、人力でなんとかしている状態でした。

そんな私には、silverlightの特徴のひとつである
「ロジックとデザインの切り離しを意識」
は魅力的です。他にも
「様々な言語（JavaScript、VB、C#、Ruby...）で開発可能」
「動作環境はWinXP SP2以降と狭い」（これは残念ですが…）
「単体技術ではなく他の技術との連携が前提」（手軽には試せない？）
といった特徴がある模様です。（※２）
まずは作ってみようと思います。

※１　adobe が提供しているFlex用フレームワーク。 他にデザインとロジックの完全分離を目的としたFlex用フレームワークとして「yui-frameworks」がある。
※２　これまた古いがFlexとsilverlightのわかりやすいまとめ資料
RIAと呼ばれるものまとめ (2007/5/19)
http://tech.nitoyon.com/misc/flex_and_wpf/

 

プログラマーの仕事について回る「文書作成」�@

ブログの更新もすっかり久しぶりになってしまいました。。。

私も１０年近くこの業界におり、ベテランといわれるような年になってきたわけです。
そこで、今回から、プログラマーの仕事ってどんなものなの？といったようなことについて、
後輩の方々に参考になるような記事を書いていこうかと思います。

今回は、プログラマーの経験に必ずついて回るような、「ドキュメント」について
少し書いてみようと思います。


＜プログラマーは、ただプログラムを書いているわけではない？＞

ＳＥやプログラマーの仕事というのはいつもプログラムを作成しているようなイメージがありますが、そうでもありません。
実は、「文書作成」のウエイトがかなり大きいものです。
（我々の間では「ドキュメント」という形で言うことが多いです。以下、「ドキュメント」という言葉を使っていきます）

ドキュメントといっても、いろいろ種類があります。
たとえば我々の仕事で言うと、このようなものがあります。
（職場によって、いろいろ言い方には差異があると思います）

・議事録
　→お客様との間での打合せや、社内での打合せでの決定事項をまとめたもの。
　　だいたい、駆け出しのころは必ず書く資料ですね。

・設計書、仕様書
→最終的にプログラムを作成して動くものを提供する、という過程で、各工程のインプット資料／アウトプット資料になるもの。
　プログラムを作成するときのインプットになる資料です。
　工程によって記述内容はかなり変わってきます。　

（※設計書・仕様書という言葉の使い方については、かなり人それぞれです。
　　たとえば自分では、
　　　・プログラムがどう動くのか、画面にはどう表示されるのか、という「使う人から見たふるまい」を定義したもの→仕様書
　　　・仕様書をもとに、内部的なつくりを記述したもの→設計書
　　という感じで使い分けていますね。

　例：「画面仕様書で、画面でどう動くのかを打合せで決定し、お客様の了解を得た」
　　　「画面設計書で、画面仕様書をもとに画面におけるプログラムのインプット・アウトプットを定義した」

・要求定義書
　→お客様のやりたいことを、文書レベルで記載したもの
　　「こうしたい、ああしたい」というような、お客様の頭の中で思っているような「絵に描いたもち」を、 文書にしたものと考えるとよいでしょうか。
　　よく絵や図を使用することが多くなる設計書だと思います。
　　（システムのことがわからないお客様にも直観的にわかるようなものにするため）

　　文章の性質的に、そのためある程度の経験がないと、作ることが難しい資料だったりします。
　　お客様と仕様を詰める力が必要になってきます。

・プロジェクト報告書
　→上で書いてきたものがお客様に対してのものであれば、これは社内の人への説明資料となります。
　　だいたい、今月（年だったり週だったりします）に、どんなプロジェクト運営がなされていたか、ということを
　　社内の上司や先輩に報告するための資料です

　　・このプロジェクトは今月何パーセントの黒字だった（赤字だった）
　　・このプロジェクトの状況は今月どんな感じだったか
　　・プロジェクトの人員の稼働はどれくらいか（残業が多すぎないか？士気は？）
　　・全体としてどれくらいの進捗率か。

　といったことが書かれてくると思います。
　（来年度から、工事進行基準による会計が我々の業界でも使われますが、その際月単位で見たときどうなのか
　ということののウエイトが非常に高くなってくると思います。また機会があれば調べて、説明したいと思います）

・・・などでしょうか。

実は「プログラム」も、ソースコードは人にわかりやすく記述する必要があるので、「ドキュメントの一種である」 ということをいう人も結構いらっしゃいます。
そういう意味では、常に「ドキュメントを作っている」という業種であるともいえるでしょうか。


＜ドキュメントってどんなものを書くの？＞

では上の中から、今回は「議事録」についてピックアップして、どんなことを書くのかを経験をもとに書いてみようと思います。
（経験のある方はいくつか意見があると思いますが、コメントなどで残していただければうれしいと思います）

・議事録

　　上でも書きましたが、「だいたいのプログラマーが最初に作成する資料」だと思います。

　　何が決まったかということを記録に残すというのは、われわれの業界でも一つの技術でもあります

　　例：
　　たとえばプログラムを作成するとき、お客様とやり取りをしていて、
　　「何がきまったの？これは言ったの？言わないの？こういう動作じゃなかったの？」
　　と突っ込まれたとき、
　　「いやいや、これはここでこう決まった（決めていただいた）じゃないですか」
　　というためのいわば「証拠」になるわけです

　　また、お互いに議論に夢中になり、結局何が決まったか、ということが落ちてしまうことも多々あります。
　　そういうときに、「ああ、こう決まったんだよな」ということが残る「資料」ともなるわけです。

　●記述するレベル
　　どこまで書くの？というと、打合せの性質しだいにもよりますが、だいたいが
　　上にあげたような性質から「決定事項だけ」、を簡潔に残すというのが多いのではないかと思います

　　また、少し砕けた会合の場合は、雑談レベルまで残すという場合もありますし、
　　誰が何を発言した？ということまで詳細に残す方もいらっしゃいます

　　いずれにしろ、
　　　・決まった事項は何か？
　　　・誰が、いつまでに、何をやるのか？（その後のアウトプットにも関連してきます）
　　　・後になって、出席者間で「言った、言わない」ということを防ぐ
　　　・出席していない人でもわかるようにする

というような位置づけがあるのではないかと思います。


今回は、
　・ドキュメントと言われるものの種類
　・ドキュメントのうち「議事録」にピックアップ
して説明してみました。

次回は、プログラムを作成するためにインプットとなってくる、「設計書／仕様書」について、書いていこうと考えています。
それでは。

柳下＠Mcube

PHPから各種ウェブサービスにアクセスするためのライブラリ集 2008年2月版

覚書
http://phpspot.org/blog/archives/2008/02/php_20082.html

簡単にWebサービスにつなげるＡＰＩがあるのは便利デスネ。

ちなみにPEARライブラリとしてなので、すこし敷居は高いですが。

20080130-01 開発自動化

【特選フリーソフト】生産性の高いWeb開発環境 Ruby on Rails 
http://itpro.nikkeibp.co.jp/article/COLUMN/20060424/236113/
最近巷で噂のruby on rails。

設計即ソース吐き出し、実行できる、というのは開発者の永遠の望みだったりするし、
管理する側でもコストダウンを図れるため効率的な方法だとされています。

この点で少し社内で話していたときに、こんな記事がありました。

カテナ、旧システムをソフト開発方法論『Lyee』のプログラム構造に自動変換する体系などを発表
http://ascii24.com/news/i/soft/article/1999/11/09/605453-000.html

これは２０世紀の記事です。
だいぶ前から開発自動化の考えがあったのですね。

しかし、いまだに新開発手法がどんどん生まれているということは、自動化というのが
いかに難しいか、ということをある意味婉曲的に示しているともいえるでしょう。

実際開発をやってみるとわかりますが、自動化というのはなかなか難しいものです。
作る過程でも複雑な業務ロジックを組み込まなければならないわけですし、
さらに作った後でも追加要望や拡張などは当然あるものです。
そこまでカバーしていく、というのはなかなか簡単な開発自動化ツールだけでは
難しいでしょう。

そんなことから、開発自動化には、必ず限界がある、というのが私の考えです。
（前に所属していた会社でもよく言いきかされてきました。）
しかしだいぶ前からこれほどの自動化プロジェクトがあったのだとしたら、
業務知識をバリバリに蓄積することにより、ビジネスチャンスはあるのかもしれない、
のですかね。

。。実際に適用するのはかなり難が必要だとは思いますが。

Mr.Kappa@mcube

20080129-01 受験戦争

http://www.chunichi.co.jp/article/living/life/CK2008012902083200.html

公立の中高一貫教育校ができた、というのはずいぶん前に話は聞いていましたが。。。
最高二十七倍。軒並み五−十五倍　とはすごい人気ですね。

しかし今の時代少子化になり、大学ももう無受験時代が近づいているというのにもかかわらず
これだけ人気が集中する学校が出てしまうと、学校間の格差が大きくなっているのではないかと気になります。
公立の中高一貫が私立の中高一貫に刺激を受けてできた、というのにも関わらず、
かえってそれが受験戦争を白熱化させているというのは、なんとも皮肉なものですね。

お役所としても、受験というものについて、考える時期が来ているのではないでしょうか。
いっそのこと、少子化が進んで最終的に無受験になるのだとしたら、入学枠をもっと広げて、
大学でしっかり学ばせ、大学の卒業を厳しくする、などの手段をとるようにする、ということに力を入れることの
ほうが、国にとっても良いことだと思うのですが。

寒い日々が続き、会社に来てお湯を沸かして暖を取るような感じです。
受験生の皆さんも風邪にはくれぐれも気を付けてください。

柳下＠ＭＣ

MCなひとたち。

MCの人を簡単にご紹介。
思いついた順不同です。

Mr.nobu…
カテゴリになってしまった愛すべき部長お代理様。
僕にいつも「1機死ねばいいのに…」っていいます。…目が合えばかならず。
僕は何機死んだかわかりません。
いつか「１機死ねばいいのに…」って言ってやる！

Mr.Kappa…
チーフアーキテクト様。技術野郎ソロ軍団。
MCの最先端。ピーキーなカリカリチューニング。
ちなみにいま僕は彼に「一機死ねばいいのに」って言われました。

Mr.めそ…
品質管理担当者。FUJIロック。週末弱る人。（なぜだろう…）
自分の品質管理はしょんぼりですが、システムの品質管理はいい塩梅です。
今、僕の体ににホッカイロ4つくっつけていきました。あったかい。
彼女は何時でも何人でも受付中？らしい。

Mr.ぴるど…
開発部長様。長老。通称たりばん。
品質管理担当の人曰く、（中略…）「ダビデ像」…あー確かに似てるかも。
社長の人曰く、米ぐらい炊けるようになろうよ・・・
チーフアーキテクトの人曰く、心の支え。

Mr.アズマックス…
MCのネクストジェネレーション。兼スイマン。
システム屋の一匹狼ネットワークエンジニア。
新風起こせるか？！

Mr.社長
MCの社長様。(そのまんまですが。）
一緒にプラレールで遊ぶ仲。
社長と僕は１０年以上の付き合いになりますが、思えば遠くへ来たもんだ。

Ms.女王様?!
大黒柱様。百人力。経理部担当。
プライベートな話、年賀状で挑戦状を受けてしまいました。
どう返そうか困りながら、年賀状出す時期を逃してしまってます。

Mr.まげ
これ書いてる人。毎日５０機ぐらい死んでるので、
１００機ぐらい増殖してます。これがリスクマネージメントの成果です。
ついでに、経営管理部長です。

以上、雑文失礼しました。
みんながんばろー！