スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

2年目SE、プロマネやります。(4話) 

前回のあらすじ:
開発環境の選択、その1。
RubyとRuby on Railsを知りました。




 Ruby on Rails(ルビーオンレイルズ:RoRと略されることもある)は圧倒的な開発効率を誇るWebアプリケーション開発のためのWebフレームワークです。Railsの用意した道のりに沿って開発することで、短時間で高機能なWebアプリケーションを構築することができます。
WebプログラマはRailsに乗るべきか? - @IT

(※太字は僕がつけました。)

読めば読むほど、これしかない、と思わされた。

短時間で高機能。
Javaで言うところのStrutsとHibernateとSpringを組み合わせたようなフレームワーク。
XMLがいらない。
すぐにコツが把握できる。

その殺し文句に見事にやられっぱなしだった。
これならば、オブジェクト指向のプログラミング経験がない友人と一緒に開発してもイケる気がする(注1)。

問題は、僕自身もRubyはやったことがないので、言語については勉強する、ということくらい。
幸いにして、Javaで、Struts、Springは実戦で使ったことがある。
Hibernateはやったことはないけれど、Hibernateがカバーする「O/Rマッピング」の概念は、同じく実開発で経験済みだ。

もはや予想は確信。
あとは、方針さえ固まれば、多分友人も納得してくれるだろう。
そう思い、今度はRuby on Rails本家を見てみることにした。

Railsに必要なのは、サーバーはApache(もしくはlighttpd)、DBはMySQL(PostgreやOracleもOK)、そして言語としてRuby。
サーバーやDBに関しては、ずいぶんと選択肢はあるようである。
サーバーはやっぱりよくわかってないので、後で精査は必要だと思いつつ、とりあえずApacheを記憶に入れておく。
DBは、Oracleは今まで使ってて使いやすいけど、無料ではないので却下。
脳内の知名度で、MySQLでいいんじゃない? と安易な気持ちで決定した。

あとは……、と思ったところで、ふと「ScreenCast」なる文字が目に留まった。

「15分で作るブログ」
「FlickrAPIを使ったアプリ(5分)」
(※それぞれ本当は英語です。意訳なのであしからず)

なかなかのうたい文句。
なんとはなしにクリックしてみることにした。
この後、僕も、後日それを見た友人も、これでRuby on Railsでの本気の開発を即決することになるとは、夢にも思わなかった。

続きます!

注1:一緒に開発することになっている友人(クライアントでもあり)。手続き言語についてはちょっと知識があるんだそうです。

※裏話・私見については続きを読むにて。

続きを読む

スポンサーサイト

その悪意の根源は(悪意) 

ミステリーの用語として、「フーダニット」、「ホワイダニット」、「ハウダニット」という言葉があります。
おそらく、"Who Done It?"とかって書くのが語源でしょう。

いわゆるミステリのテーマの分類用語で、順に「誰がやった(犯人当て)」、「どうしてやった(動機当て)」、「どうやった(方法当て)」という意味です。

で、今回はフーダニットとホワイダニット(特にホワイダニット)をたっぷり盛り込んだお話のご紹介。

東野圭吾作「悪意」です。

白状してしまえば、僕は東野圭吾作品はたいがい好きなので、多少の色眼鏡は入ってしまっているとは思いますが。

久しぶりに鳥肌が立ちました。
人間の心の暗さと、レトリックの複雑さに。

ええ。マジ、すげえ。

フーダニットの部分はわりと予想がつくんです。でも、その後の動機部分のところについては完璧にだまされた。
この人の文章には一行とて無駄な部分がなかったんだな、と最後の行まで読み進んだところで愕然としました。
この人の頭の中はどうなってるんだろう。と真剣に思いましたね。

余談ですが、個人的には加賀刑事がお気に入りです。
あの推理力・洞察力とかで、探偵じゃないところが現実っぽくていいですね。
ついでに今住んでるところの警察署にいる設定なのも個人的に親近感あってマルです。笑。

悪意
悪意東野 圭吾

おすすめ平均
stars犯人の動機は?
stars面白い試み
stars仕掛けがたくさんだが
stars期待すると。。
starsうーん・・・

Amazonで詳しく見る
by G-Tools

ときどき止まらなくて困ります。 

「なんかねー、どうも画面遷移がうまくいかないんよ。
 これは、やっぱアレかなー。
 マヤが悪い?
 いや、でも、マヤはちゃんとできてると思うんだよなぁ。
 つーことはダイコンかな。
 ダイコンのどっかが腐ってるのかなー。
 あー。もしかしてココー?
 お。よっしゃー。生き返ったー!」

と、職場でぶつくさ言いながら、シーサー(今回はあえてカタカナにしております)というフレームワーク(http://www.seasar.org/)について自習しておりました。

もし会社でこれが採用されるような日が来たら、きっとこんな会話ばかりがあちらこちらで繰り広げられて、本気で話してるのに冗談扱いされてしまって、何も知らない重役から怒られるーみたいな、面白職場になるんだろうなぁ、と一人妄想しておりました。

プログラムの話してるのに、マヤさんの超絶クッキングみたいなイメージが頭から浮かんで離れません。
きっと、ダイコンを使った沖縄っぽいお料理なのでしょう。
空腹は最高のスパイスですよ、とか考えながらシーサーがくんくんにおいをかぐわけですね。

あー。誰かこの妄想の連鎖を止めてーーー。

100と-100(ストレスフリーの仕事術) 

社会人になって、早いことにもうすぐ一年半。
仕事の仕方にも慣れ、後輩もできて、そして仕事は順調にキャパオーバーに向けて右肩上がりで増えていく……。

……なんてこと(特に最後)は、とりあえずまだ、わが身には起こってはおりませんが。
早いうちから、仕事をうまいこと管理する術というのは知っておいて損はないだろうと思うのです。
仕事のやり方を覚えることと、仕事の「効率のいい」やり方を覚えることは、おそらくまったく別でしょうから。

という前フリで、今回はこの本でも出してみようかと思います。

ストレスフリー仕事術」。

百式の管理人の田口さんが翻訳してらっしゃるこれ。
個人的にはかなりオススメでございます。

中身をものすごくばっさり要約してしまうと、
 ①日々のやらなければいけないことを全部書き出す。
 ②書いたものをやるのかやらないのか決める。
 ③リマインダーやリストにして整理する。
 ④毎週、達成状況をチェックして、新しく増えたやることなども使っているリマインダーやリストに反映させる。
ということだと思います。

聞いてみると、ふーん、なんだよ、で終わるのだけれど。
なんか一時期やったことあるよ、なんても思ったのだけれど。

ためしにこれ読みながらやってみて、よくわかりました。
今まで、自分のなんと甘かったことか。
なんと三日坊主で終わってたことか。

①が徹底されてなかったり、④が続かなかったりと、今まで自分がやってたことは、ずいぶんと穴が多かったことに気づかされました。

で、今、ためしに、とばかりに、これを一ヶ月ほど続けた上での状態なのですが。
正直、悪くないと思います。というより、思った以上にいい具合に続いています。
やってることが、定期的に頭を掃除しているようなものだからかもしれません。

IQサプリで言うところのスッキリ!を、仕事で感じることができるので、忙しくて目が回るー、なんて言ってる人にこそ、こっそりと教えてあげたいですね(笑)

余談ですが、③で言うところのリストやリマインダーとして、目標管理ツール - checkpad.jpRemember The Milkなんかがいいんではないでしょうか。
僕は前者を使っております。

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則
ストレスフリーの仕事術―仕事と人生をコントロールする52の法則デビッド アレン David Allen 田口 元

二見書房 2006-05
売り上げランキング : 453

おすすめ平均 star
star本当は大切なこと。
starGTDエッセンス-本編もいいけど、田口氏のまえがき、あとがくがすばらしい

Amazonで詳しく見る
by G-Tools

2年目SE、プロマネやります。(3話) 

前回のあらすじ:
ユーザーに概要を聞いて、何するかリストアップしました。




リストアップしたものを見ながら、今度はどれから手をつけるべきか、私は考えた。

まずは、概要設計からだろうか。
機能を決めて、設計書を作ってユーザーに見せる。
順序としては間違っていないように思える。
けれど、なんだかすっきりしない。
説明がしづらいけれど、しいてあげれば、「なんとなくこっちからだと考えにくい」気がする。

ほかの選択肢も考えてみる。
UIやDBなんて、概要が決まらなきゃ前に進ませられるわけもないし、残るは開発環境の構築。

いわゆるハード的なお話。

なんとなく、ぴんときた。
自分の経験ではハード面なんて、ほとんど触ってないけど、何を使って、どう作るかくらいは最初に決めてあったほうが、精神的に楽そうな気がする。
この辺は、一回決めればそうは動かないだろうから、立ち位置が定めやすい気がした。

「よし。じゃあ、まずはハードからってことで」

というわけで、開発環境の模索から入ることにした。

開発環境といえば、
・サーバー
・クライアントPCの環境
・開発に使う言語
・開発に使うDB

あとは思いつかなかったけど、とりあえず、これは動かす上で最低限だろうと判断する。

まずはサーバー。
……はっきり言えば、お手上げである。
自分の会社の例を参考にしてみるけれど、そんなン百万だかン千万だかするようなものができるわけがない。
自宅サーバーを立ち上げるのか、どこかのサービスを借りるのか、いまいち想像ができない。
とりあえず、クライアントで作ってみて、それをサーバーに乗せられるくらいのものができてから考えることにしよう、と割り切ることにした。
ここは金額面含めて、ユーザーと要相談としておこう。

ならば、と、次は言語。
果たして何がよいだろう。

自分がやったことのあるものをためしに列挙してみると、COBOL、VB、Java。
どうせなら、自分のフィールドで、と、この辺りから選ぶべきなのだろうか。

だが、一緒に開発する友人は、このどれも知らない。

Javaで、オブジェクト指向の話から、サーブレット、MVC、そんなことを説明するだけで、どれだけの時間がかかるかわからない。
少なくとも、僕は会社で研修してまで教えてもらって、約3ヶ月近くはかかった記憶がある。
それでは、始めるだけで相当先になってしまう。

正直言って、これだと、つらい。
しかし、だからといって、そのほかの言語がどういうものか、わからない。

さて、どうする?

半ば袋小路に陥りながら、@ITをぼんやりと見ていたときのことだった。

当時、トップページにあった、この記事が妙に目を引いたのである。

WebプログラマはRailsに乗るべきか? - @IT

「Ruby on Rails……?」

興味本位で記事を読むうち、私の中で何かがつながりあっていくような音を聞いた。

「これ……、もしかしたら、よくね?」

ひとつの答えを見つけた、と思った。


続きます!


※裏話、私見については続きを読むへどうぞー。

続きを読む

近況報告。 

どうもご無沙汰しております。
PCの買い替えやら何やらですっかり間が空いておりました。

徐々に環境も整ってきましたので、もう少ししたら再開いたしますです。ハイ。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。