Google App Engineで遊んでみる。２

　　　2. GAEのインストール

http://code.google.com/intl/ja/appengine/

まず、上記サイトからGAEのアカウントを作成する。
Googleのアカウントがあれば基本問題無いはず。
分かりにくいのはSMS認証のとこぐらいか。
キャリアを選んで携帯のメールを入力すると、
認証コードが携帯に送られてくるのでそれを入力するだけ。

アカウントを作ることでアプリをGAEにデプロイできるようになる。

アカウントができたら、開発環境を整備する。
具体的にはGAE SDKのインストール

http://code.google.com/intl/ja/appengine/downloads.html

↑のリンクからイメージをダウンロードして展開。
APPファイルがあるのでアプリケーションディレクトリにでも突っ込む。
で、実行。


/usr/local/binにシンボリックリンク貼る？って聞いてるので、OK。


貼れたらしい。
確認してみる。

[masato@mac] $ ll /usr/local/bin/*.py
lrwxr-xr-x   1 root  wheel  137  7 27 16:23 /usr/local/bin/appcfg.py -> /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/appcfg.py
lrwxr-xr-x   1 root  wheel  152  7 27 16:23 /usr/local/bin/bulkload_client.py -> /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/tools/bulkload_client.py
lrwxr-xr-x   1 root  wheel  144  7 27 16:23 /usr/local/bin/dev_appserver.py -> /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py
[masato@mac] $                                                                [~]

appcfg.py , bulkload_client.py , dev_appserver.pyが使えるようになっていればOK
こいつらを使って実際にデプロイ作業とかを行う。

とりあえず、これでインストールは完成。

　

Google App Engineで遊んでみる。１

Google App Engineで遊んでみるシリーズ

1. インストール、、、の前に
2. GAEのインストール
3. HelloWorldを動かしてみる
4. webapp framework
5. .....

今更な感じもあるが、GoogleAppEngine(以後GAE)で遊んでみる。

ちなみに、GAEとは、pythonで作ったWebアプリをGoogleのインフラ上で動かすことができるサービス。
現時点ではpythonのみだけど、今後はperlとかでも開発できるようになる・・・らしい。
AmazonのEC2に似た感じのサービスだけど、後発な分だけ色々と便利なようだ。とりあえず遊んでみる。
なお、このブログでは開発環境として、OSX10.4を利用する。

1. インストール、、、の前に

早速遊んでみたい所だけど、GAEを動かすためには、pythonのバージョンが2.5.2以上でなくてはならない。
うちのMacは、、、

[masato@mac] $ which python
/usr/bin/python
[masato@mac] $ python -V
Python 2.3.5

ということで全然だめ。
まずはpythonのインストールから始める。

http://www.python.org/download/
上記サイトでpython最新版のイメージをダウンロード。
中のインストーラを起動する。



終わったら確認してみる。

[masato@mac] $ which python
/usr/local/bin/python
[masato@mac] $ python -V
Python 2.5.2
[masato@mac] $

これでOK,バイナリの格納場所も変わったみたいだね。

次へ

レバレッジ勉強法 読破

リバレッジリーディングやリバレッジシンキングに続くリバレッジシリーズ。
リバレッジ勉強法とは又ストレートな題名だ。

この人の本に共通して言えることは、書中でも嫌というほど繰り返されている通り、

『対費用効果を最大にせよ。』

である。（ただし、費用は単純に金銭的なモノに限らず、時間なども含む）

本書も例に漏れず、勉強することの対費用効果を最大にするためにはどうしたら良いか、というテーマに沿って書かれている。
内容は大きくわけて、上記を意識的に行うことのポイントと、そのための具体的なハウツーに別れている。

読んでみてポイントだなーと思ったのは次の２点、

• ・目的意識をもって勉強する
• ・分野を集中して勉強する
  

ただなんとなく英語が必要そうだなぁ・・・と思って勉強をしてもなかなか続かない。勉強することにより発生するメリットを明確にしたうえでとりくむことが必要。うーん、耳がいたい。
また、ちょっとやる気が出たときには欲張ってあれもこれもとなりがちだけど、それも結局は続かない。目的意識を持ったならそれに集中するほうがリバレッジは高い。
言われてみれば全くその通りだが、普段はなかなか忘れてしまいがちな所だとおもう。


あと、ハウツーのところで、即使える。と思ったのは資格試験対策の所の

• ・勉強する前に過去問を解くべし

というところ。
勉強してないから当然とけるはずが無いのだが、問題にあらかじめ触れておくことで勉強しなくてはならないところと、勉強しなくてもいいところが明確になる。
これは、なるほど！と思った。

これ以外にもちょっとしたコツ的な内容も多いので、読んでみて損はないと思う。
文章量も多くないから通勤時間とかによいかな。

レバレッジ勉強法

posted with amazlet at 08.07.24

本田直之
大和書房
売り上げランキング: 4512

Amazon.co.jp で詳細を見る

PROLOGE　勉強とは「いつか役に立つ」ものではない
LEVERAGE.1　あなたの「ビジネス偏差値」は？
LEVERAGE.2　何を勉強するかを決める
LEVERAGE.3　ラクに勉強できる「仕組み」づくり
LEVERAGE.4　成果に直結するスケジューリング
LEVERAGE.5　どんな試験にも受かるテクニック
LEVERAGE.6　挫折しない英語マスター術
LEVERAGE.7　最速で情報を「勉強する」法
LEVERAGE.8　勉強しやすい環境をつくる

彼にGoogleは必要ないのか

同期と飲んだ時の話。

彼曰く、Googleは使えない。

• GoogleDocs

使えない。
アップロードしたらレイアウトが狂った。実用に堪えない。
そもそも容量制限があって役に立たない。
画像をいくつか貼ったPowerPointをアップロードできない。
どんな用途で使えというのか。

• GoogleMap

使えない。
VPNから接続したらAjaxがうまく動かなかった（？）。
ルート検索もできない。役に立たない。
ユーザビリティの面で言えば、既に他のサービスも同様のことができる。

• GoogleCalender

使えない。
仕事で使っているOutlookと同期がとれないようでは話にならない。
Excangeサーバを使っている以上GCalだけではなんともならん。
え？ソフトを介すれば？そんなの知らん。

• Gmail

使えない。
アーカイブしたら見えなくなってしまう。
仕分けルールでディレクトリごとにわけたほうが便利だ。
検索？それだったらOutlookだってできる。
２Gが無料？ローカルのOutlookだったら無制限だ。

• その他Goolgleのサービス

知らん。

• 検索エンジンとしてのGoolgle

ブログばっかり引っかかって使えない。
Yahooの方がましだ。

• で、でも、どこでも使えるってメリットがあるよ。

会社で使えないと話にならない。
むしろ会社以外で使えてもメリットにはならない。


ITを知らないおばちゃんの発言ではなく、それなりに活躍している（？）SEの発言です。

お前が使いこなせてないだけじゃないか。というのは簡単です、が。
もしかしたら俺らが無理をして使っているだけなのかもしれない。と感じた今日この頃。

俺らにしてみたら、そうやって最新のサービスを使うのは正直楽しいものですが、
それじゃエンドユーザはついてこないのかもしれない。

日本の検索エンジンの利用率、GoogleよりもYahooの方が高い理由がちょっとだけわかったきがします。

次世代メモツールとしてのEverNote

http://evernote.com/

しばらく使っているが、かなりいい。
次世代Webサービスの中でもかなりの『当たりサービス』なんじゃないかな。
googleの各種サービスと同じような印象を受ける。


ポイントを纏めてみる。まずはいいところ。

• プラットフォームにこだわらないところがいい。

WebでもWindowsでもはたまたiPhoneでも使える。（ただしMacはOSX10.5以上必須・・・（T-T）
これだけのためにiPhoneを買おうかと思ったぐらい。
まさに、『どこでも』メモがとれる。メモツールとして、この『どこでも』というのはかなり重要なポイントなんじゃないだろうか。

• メモの形式にこだわらないところがいい。

テキストはもちろん、画像や音声でもメモが取れる。
そしてそれらを一元管理できてしまう。テキストだけのメモツールならたくさんあるが、画像も管理できるのはなかなかないのでは？
画像が使えることで、iPhoneとの親和性がかなり高くなってる気がする。
あー、まじでiPhone欲しい。

• 管理の仕方がいい。

最近のWebサービスではもはや常識的ともいえる管理体系、『タグを付けて』『検索する』。
evernoteではきちんとこの仕組みを踏襲している。
有料版では、画像内の文字検索までしてくれるようだ。

悪いところとしては。

• ツールのユーザビリティがまだまだ。

webツールはAjaxを基本とした作りになっているようだが、直感的な操作性とまでは行っていない気がする。たまにjavascriptのエラーが起こるのもイマイチ。
Windows版クライアントの操作性も改善の余地あり。特に日本語との親和性が良くないらしく、テキスト入力をしているときの挙動が少し怪しい。
OSX版クライアントはバージョンの問題で動かせなかった。残念。


改善して欲しいところはいくつもあるものの、コンセプトが非常に素晴らしいサービスだと思う。有料版へのアップグレードも念頭に置きつつしばらく使ってみたい。

なお、inviteはいくつか余っているので、コメントかメールで言ってくれれば招待します。

アーキテクチャとはなんであろう。

かの有名な ぼそっと にて色々と興味深い見解を述べられていたのでノッてみる。
（chiba_さんごめんなさい）


http://d.hatena.ne.jp/chiba_mk3/20080714/1216050596
http://d.hatena.ne.jp/chiba_mk3/20080715/1216135665

まず、俺が思うアーキテクチャ

アーキテクチャとは、構造である。

構成じゃなくて構造だと思います。少なくともITアーキテクチャについては。言葉遊びですけど。
この言葉って「構造化プログラミング」から来てると思うんですよね。

構造化プログラミングは、順次・分岐・繰り返しのみでプログラムするってのがポイントですが、それに加えて、システムを機能単位で分割して組み合わせる、という意味もあります。
サブルーチンの概念ですね。
この「機能単位で分割されたものを組み合わせる」という概念はOOPでもAOPでも変わりません。つまり、現在作られてるシステムはほぼ全て「構造化された」システムである、と言えると思います。

よって俺は、

構造化されたシステムの構造のことを、我々はアーキテクチャと呼んでいる。

と考えます。

つまり、コンポーネントだったりサブルーチンだったりはたまたクラスだったりの組み合わせ方。がシステムのアーキテクチャである。

と私は考えます。

さて、ここまでを踏まえて、俺が違和感を感じたところはここです。

やっぱり、そもそもの言葉の意味的に考えると、「アプリケーション・アーキテクチャの確定＝各問題領域毎のフレームワーク・コンポーネントを組み合わせて要件に適したフルスタックフレームワークを構築すること」と考えても差し支え無いような気がしてきました。

フレームワークを構築することは、アーキテクチャを確定させることの一部でしかないと思うんです。俺は。
確かにフレームワークを確定させれば、システムの大枠は決まります。
でもフレームワークが担うのはあくまで汎用的な機能だったり処理パターンであって、システム独自の機能というのは別途開発しなくてはならないはずです。
その独自の機能のところの構造まで確定させて初めて、アーキテクチャの確定と言えると思います。
全部作れ。と言ってるわけではないです。
インターフェースで下位のクラスの挙動を束縛したり、UML等で概要だけ決めたり、代表的なところだけ作って後はそれを模倣させたり、と構造を確定させる手段は色々とあると思います。
ここまでやらないといけないから、アーキテクトって大変なんですね。多分。


と、俺の理想とするアーキテクト像を元に、言いたいこと言ってみました。

若干後悔していますが、異論もお叱りも認めます。ごめんなさい。

泥カンなんつーもんがあったらしい。

昨日あったらしい。今日知った。

http://www.atmarkit.co.jp/news/200807/14/todai.html

SIerしか知らないので、興味はそこに集中するんだけど、なんじゃこりゃって感じ。
「SIerはウェディングプランナーのようなもの」ですか・・・。
「管理業務がSIerのメインの仕事」ですか・・・。


俺の所感では、
SIerって、非常に幅の広い仕事だと思うんだよね。
お客にシステムを導入するのが仕事でしょ？
そのためには当然管理も必要だし、仕様を固めることも必要だろう。
でもそれがメインじゃなくね？
ベンダーを利用するならその知識も必要になってくる。
自分で作るなら作れるだけの技術も必要だろ。
作って終わりじゃなくて保守もしないといけないだろうし。
そこまで全て踏まえた上でのインテグレーションじゃないのか？
プランニングだけして丸投げするのがSIなのか？

と、ここまで書いて、もしかしたら＠ITに情報操作を食らってるだけなのかもしれないと思い、ほかの人のブログを色々と見ると・・・非常によく纏まったブログを発見。西岡さんblogより

http://nishioka-blog.com/2008/07/it.html

SI代表として。

• たとえばSIerはウェディングプランナーみたいなもの。
• SIは開発のみじゃない。営業とか企画とか全部あわせてのこと。
• 物を作るところで全体を管理している。マネージメントしている。

＠ITの記事よりは、納得できる発言。
　（開発だけではなくて）マネージメント中心になるよね。
というニュアンスだったのかもしれない。

そういう言い方だと、確かに現状として否定できない部分は多い。
前職でもみんな画一的に、
「技術はそれなりに押さえつつ、目標はマネージャーです！」
って声を大にして言っちゃう人、多かったし。

個人的には非常に不満かつ不安だけど、それが日本のSIerなのかなぁ。
でもそれって情報部門とかシステム子会社の役割じゃないの？
そんなSIerって、必要なの？

フレームワークの弊害かも

初めて仕事でJavaを使った時には既にStrutsが使われていて、
実際のところServlet,JSP,JavaBeansを使ったMVCモデルなアーキテクチャって作ったことがない。
作ったことがないどころか、多分これからも作ることはない気がする。

別にMVCモデルに限定した話じゃなくて、
たとえば、データアクセスとかもjdbcでばりばりコーディングすることはないだろう。

これってかなりやばくない？
本質、わかってなくない？
jdbcでトランザクション管理とか組めるのか？俺。

という危機感を最近感じる。