♪8th Note♪: Codingアーカイブ

オープンアプリ開発の参考サイト

管理人

(2008年7月19日 23:27) | 個別ページ | コメント(0) | トラックバック(0)

　携帯を機種変してオープンアプリの実行環境を手に入れたので早速開発環境についてググってみました。正直何を今更ですね。本当なら去年にやっとくべきだったかも。

　それで調べて必要環境をインストールした結果、S!アプリ開発環境と同じでは？S!アプリは実機へ転送するのにキャリアとの契約とISDN回線が必要(一昨年時点、今は知らない)で個人で出来るものではないのですがオープンアプリは自前のサイトにアップロードして携帯にダウンロードして使えるのでiアプリ並みに手軽ですね。ドコモは他にeclipseにplug-in入れてやってたなぁ。

KDDI au 技術情報オープンアプリ (Java™)
http://www.au.kddi.com/ezfactory/tec/spec/openappli.html

第1回　オープンアプリ(Java)とJava実行環境
http://appget.com/contest/au2007/lecture/lesson1.html

とりあえず上記サイトより実装方法の確認をしてその後、どこまで拡張可能かやってみます。

AS3.0で3Dプログラミングの講座

管理人

(2008年6月22日 00:00) | 個別ページ | コメント(0) | トラックバック(0)

　AS3.0を使った3Dプログラミング講座がてっく煮ブログより連載されています。

AS3.0 で 3D プログラミングを１から勉強する (1) - てっく煮ブログ
http://d.hatena.ne.jp/nitoyon/20080616/as_3d_lessen1

AS3.0 で 3D プログラミングを１から勉強する (2) - 行列の導入 - てっく煮ブログ
http://d.hatena.ne.jp/nitoyon/20080617/as_3d_lessen2

AS3.0 で 3D プログラミングを１から勉強する (3) - 透視投影 - てっく煮ブログ
http://d.hatena.ne.jp/nitoyon/20080618/as_3d_lessen3

　AS3.0では3Dがサポートされているみたいですね。私が持っているFLASH 8 はAS2.0なので力技しかないｗ、これってFlexとAIRでも同じようにできるのかなぁ(実はFlexとAIRの区別がついてません、スミマセン…)

AIRのハブサイト

管理人

(2008年5月22日 23:46) | 個別ページ | コメント(0) | トラックバック(0)

これは以外。ActionScript版はあったのでこれが出てくるとは思わなかった。

AIR-users.jp - 日本の AIR ユーザのためのハブサイト
http://air-users.jp/

　最近AppleのAIRとかAdobeのAIRとか聞くがAdobeのって何それ？て感じだったのでちょっと調べてます。私が持ってるFLASHは8なので試せない気がするのですがFLASHアプリがWeb系のインターフェースが使えるように拡張されたものというイメージでよいのかな？競合するのは.netフレームワークとかGoogleデスクトップになるのかな？…まだ良く理解して無いです。

今日は凄い勢いでハブサイトが立ち上がってるのですが

管理人

(2008年5月21日 21:16) | 個別ページ | コメント(0) | トラックバック(0)

YAPC::Asia 2008 で Michael Schwern は「SEO に有効な独自ドメインを取って、もっと Perl 初心者が集まりやすい nice な Perl の情報を集めたサイトを作れ！」といったので Perl-users.jp ドメインを取って、ここに Perl-users.jp を開始します。(2008年5月20日)

というわけでPerlのハブサイトが誕生したみたいです。

Perl-users.jp - 日本のPerlユーザのためのハブサイト
http://perl-users.jp/

Perl-users.jpにインスパイアされてActionScriptのハブサイトが誕生。

AS-users.jp - 日本の ActionScript ユーザのためのハブサイト
http://as-users.jp/

さらにPHPもということでPHPのハブサイトまで誕生。立ち上げたのは百式の人だ。

PHP-users.jp - 日本のPHPユーザのためのハブサイト
http://php-users.jp/

今日は凄い日だなぁ…と家に帰ったらJavaScriptのハブサイトが誕生。ちょｗｗｗ

js-users.jp - 日本の JavaScript ユーザのためのハブサイト
http://js-users.jp/

おや？立ち上げたshi3zさんってマシン語の人？ブログ見に行ったら本当だった。

js-users.jpはじめました - shi3zの日記
http://d.hatena.ne.jp/shi3z/20080521/1211363628

同時多発で別々の人が同じデザインでハブサイトを立ち上げるというのも面白いですね。でも各サイトみたら全て「ノープラン」ってどんだけやりっぱななんだｗｗｗ

デザインは同じだけどCMSはバラバラなんですねぇ。この勢いだとサイト系言語のハブサイトが近日中にさらに増加するかもRubyとかPython辺りかな？あとJava(JSP,Servlet)、ASPも大穴かも。

Python-users.jp
http://python-users.jp/

おおっ！whoisで掛かったので探ったら現在、立ち上げ中の書きかけｗ多分明日当たりに公開かな？失礼！別ドメインで既存ユーザーサイトありました。→http://www.python.jp/Zope/

Ruby-users.jp - 日本のRubyユーザのためのハブサイト
http://ruby-users.jp/

Rubyは既にありました！ドメイン取得日が最近じゃないので違うデザインの既存サイトかなと行ったら同じデザインでビックリ。どうもドメイン保持者は特に活動もなく静かに持っていたそうですが、周りの状況から駆り出される形で立ち上げることになった模様です。白羽の矢ｗ

java-users.jpはドメインあるみたいだけどホスト名無しのサイトがありませんでした。既存ユーザサイトがあるから今回の立ち上げには乗らないかもですね。

日本 Java ユーザグループ
http://www.java-users.jp/contents/

後はASPだけかな？

BSDLのバグ管理ツール「OpenTask」

管理人

(2008年4月18日 03:46) | 個別ページ | コメント(0) | トラックバック(0)

　似たようなシステムにbug-zeroやtracがありますが、最近のバグ管理はウェブツールを使うことで修正サイクルが早くなりました。以前はエクセルシートをメールに添付して修正・確認が完了して一巡するまで次の報告が出せないといったパイプラインの無いCPUみたいな運用だったので随分違います。

３つを単純比較してみると

trac

言語：Python
ライセンス：BSDL
主な機能：タスク・バグ管理、リポジトリ管理

bug-zero

言語：PHP
ライセンス：無償ソフト
主な機能：タスク・バグ管理

OpenTask

言語：PHP
ライセンス：BSDL
主な機能：タスク・バグ管理

tracが一番機能も充実しているしSubversion使っているならお勧めなのですが導入が少し手間かもしれないですね。bug-zeroとOpenTaskはOSSかどうかの違いぐらいだし最近のウェブサーバーはPHP導入率も高いので手間も少ないと思います。

Open Tech Press サイブリッジ、タスク管理ツール「OpenTask」をオープンソースで公開
http://opentechpress.jp/news/08/04/16/1214247.shtml

OpenTask
http://opentask.jp/

産総研の安全なC言語コンパイラ

管理人

(2008年4月15日 23:14) | 個別ページ | コメント(0) | トラックバック(0)

　C言語のトラブルと言えばメモリ管理周りにプログラマーにとって想定外の操作が発生した場合に暴走したりSegmentation fault で強制終了したり、最悪なケースではそれが脆弱性となりクラックされることですが産総研よりFail-SafeなC言語コンパイラが公開されたとの事。このコンパイラを用いて既存のサービスをコンパイルすることで実行時メモリへの不正アクセスを防止できるらしい凄い夢のような技術です。因みに記事を見る限りではC++は対応していないっぽいですが、メモリ管理で手間の多いC言語だけでも十分有効だと思います。

産総研 RCIS Fail-Safe C 安全なC言語コンパイラ
https://www.rcis.aist.go.jp/project/FailSafeC-ja.html

Open Tech Press 産総研、メモリ安全性を確保したC言語コンパイラを開発
http://opentechpress.jp/developer/08/04/14/2235212.shtml

最近の新人研修ってどうなんだろう？

管理人

(2008年4月13日 05:15) | 個別ページ | コメント(0) | トラックバック(0)

　就職氷河期世代から見ると、売り手市場なのか条件がゆるくなったのか明らかに専門教育を受けていない人の割合が増えたなと思う。別にそれ自体は悪いことではなく研修体制もそれに合わせて充実させることが求められるのかなと思います。

　今までは工学系学生が多く就職していたのがそうでも無くなったので専門学校や大学等で習う情報基礎っぽいのも盛り込む必要がありますね。具体的に言うとUNIXのコマンド操作とかTCP/IPの常識あたり、ウェブシステムを開発する上で作業効率や品質に大きく影響の出るところなのでスクリプト学習だけで終わらせるのは勿体無い。出来たらC/C++まで盛り込んで言語耐性を強化したい(多言語の食わず嫌いを無くしたい)狙いもあるけど余裕無いかな。流石にマシン語も無いかな…バイナリ耐性あると文字化けやファイル破損の調査とかに使えるんですけどね。

　そんなこと考えていたら株式会社ディノで新人研修の模様が公開されていました。ブログの方は全て読みましたが内容の充実ぶりに圧巻。会社の研修なのに歴史やタイピング、そしてライセンス周りまでやるとは力の入れ様が違い過ぎる。

スタートアップ研修記
ディノのエンジニアのつくりかた

動画共有SNSzoome～training2008
http://zoome.jp/training2008/movie_list/

　また新人が利用する端末にmac(Windows以外)を使用するというのは良いアイディアです。別に同じ事をWindowsでも出来るわけですが一旦今まで使っていたツールを全て使えなくすることで気持ちの切り替えと学習効率を上げる効果があるのではと思います。私が学生の時はWindows端末はあったものの情報教育は全てSolarisで研究の時はOS無しのPCだけ渡されてLinux構築して使ってました。

確かに内製が望ましいです

管理人

(2008年4月11日 03:29) | 個別ページ | コメント(0) | トラックバック(0)

　タイトルに釣られて読みましたが、確かに設計と実装を分けるデメリットは恐ろしい。昔からウォーターフォールモデルの開発形式は続いていますがシステム開発に関しての実態は上から下に一方的に流れるのではなくてＶ字型に戻ってくるのを実感しています。それも上から下へ流すのは早いけど、折り返して上っていくのには時間が掛かる。また工程のレベルと担当者が一致していることが多く良く考えられた図だなと思います。(後半上りになる工程は機能テスト→単体テスト→結合テスト→総合テスト→納品→仮運用といった内容です)

　ちょっと脱線しましたが、プログラマが仕様→実装→テストを行うことができれば理想です。まず社内でこの３つ工程を請負っているならなるべく分業しないようにしたほうがいいですね。仕様の伝達コストが下がるだけでなくモチベーションに大きく影響します。実装すべきプログラムが多くて一人で出来ない場合は実装のみ社内分業して仕様とテストに専念すると良いと思います。仕様だけ決めて実装とテストを切り離すと結果的に無責任になったり仕事がつまらなくなったりしますからね。

　また要件定義に関わる人は技術者とはまた違う考え方が出来る人じゃないと勤まらないというのもそうですね。以下のエントリー見てどこまで要件定義でどこから基本仕様か区別できなかった自分に反省しています。勿論顧客が基本仕様作成することもありますが、仕様を作成する人は実装能力ではなく運用経験豊富な人が必要だと最近思うようになりました。特に顧客とは別にエンドユーザが存在するシステムにおいてはユーザビリティのプロフェッショナルにUIの設計をお願いし顧客が要件定義と一緒に出してきた画面仕様に手を加えて指摘・説明・修正して欲しいと思っています。例えば個人情報の取得方法等は技術的重要度が低く要件定義のように見えるのですが実は仕様じゃないのかと思います。これも運用経験の豊富な方に仕様を決めてもらったほうが見込み客の損失を最小限にするフォームの設計をやってくれると思います。そういう意味で要件定義と基本仕様は分けた方が良いものが出来そうな気がします。これが技術者がヒアリングすると簡単に実装可能なことは顧客の言うままハイハイ聞いてそのまま仕様にしてしまいサービス開始後にエンドユーザから使いづらいとか、登録フォームの必須が多すぎて見込み客を逃しているのではないか？といった運用面の問題を指摘されたりと言った事になりかねないです。と言うかごめんなさい。私が基本設計に関わった時の一例です。

　現実は要件定義から基本仕様が顧客、基本仕様丸写しの基本設計とそれを元にした詳細設計が一時請負、実装とテストが下請けという問題の多すぎる構造なんですよね。この構造だとどうしても担当している工程に大きな影響を与える上流部分が他社の作業範囲って事です。分業した筈なのにルールが干渉している…。社内だとすぐに声かけて話し合ったりレビュー実施すればいいのですが、他社になるとスケジュール合わせとメールや電話での質問とやっているうちに一週間経ってしまう事もありました。

プログラマが仕様を決めればいい - GoTheDistance
http://d.hatena.ne.jp/gothedistance/20080410/1207832176

確かに内製が望ましいですの続きを読む

システム開発って楽しくないよね

管理人

(2008年4月 9日 13:57) | 個別ページ | コメント(0) | トラックバック(0)

　デスマーチとか現代の3K、ITドカタって言われてるシステム開発ですが、特にプログラマーだと上流工程の不甲斐無さにイラついたり、いい加減なマネージメントに巻き込まれたり大変です。そう思っているプログラマーも数年後には上流になって前任者と同じ過ちを繰り返していると思うのですが…。そうは成りたくない。

なぜプログラミングが楽しくなくなったのか・日本的ソフトウエア観（1）ビジネス-最新ニュースIT-PLUS
http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT2z000003042008

　丁度思っていることと同じ内容の記事を見つけました。その通りですね。今後に期待。

　プログラマの地位が低いというか顧客が強すぎです。結局間違った意味での「お客様は神様」でお金払う側の方の意見が強くなる。本当に良いシステムを作るのならば本物の経営コンサル入れて自動化以前の運用からしっかり見直すべき。またそのメリットを納入するハードウェアの縮小化・システム開発コストの節約になることを主張すべきです。売上金額が下がれば営業は嫌がるでしょうが…。開発としてはスマートに高性能なシステムを開発できた方がやりがいがあります。

議事録のプロ：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20080328/297379/

　これは凄い！前から「会議は物事を決定する場である」と聞いてきたのですが実際は、討論・脱線・先送りの現場になることが多くてなかなかうまくいかないのですが、これだけハッキリと決めるべきことを明示すればうまくいくかも。もう伝言ゲームはうんざりですからね。