App Engine でのモデル定義

Google App Engineでは、データストアとして、よくあるDBではなく独自のDBを使い、テーブル定義をしなくても、db.Modelというクラスを作れば、簡単にデータを保存できます。 http://code.google.com/intl/ja/appengine/docs/datastore/overview.html で、確かに、ちょっとしたものを作る分にはそれでよいと思うのですが、きっと中の人は何かツール使ってると思うんですよね。データ定義がコード内にしかないのは、ちょっとどうよと思うわけです。その辺のテーブルデザインツールが使えないというのもちょっとなと。例えば、カラム(App Engine的にはプロパティ)の型に何が使えるかを、リファレンスを見ないと分からないわけです。 ということで、App EngineとPythonの練習を兼ねて、ちょっとしたツールを。 http://klabs.appspot.com/ 全ての型を入れていないし、順番入れ替えも、そもそも削除もできないってどういうことよ、ってな感じですが、これから遊びながらいろいろ付け足したいと思います。

Aptanaはんぱねー

色々ふらつきながら、Aptana入れました。 単にHTMLエディタとしての期待だったのですが、どちらかというとAjax関連に力を入れているようですね。新規プロジェクトを作ろうとすると、途中でこんな画面が出てきます。 うは、名前すら聞いたことがないものもある。かと思うとMicrosoft Ajaxなんてものまで入っている。はんぱないっすね。 こちらのシリーズが役に立ちそう。 http://www.atmarkit.co.jp/fwcr/rensai/ajaxrecipe01/ajaxrecipe01_1.html —

戦後日本最大のコンペ

磯崎新の「都庁」―戦後日本最大のコンペ 平松 剛 文藝春秋 2008-06 売り上げランキング : 1048 おすすめ平均 権力者とアナーキスト 新宿の都庁を通していろんなことがわかる本 Amazonで詳しく見るby G-Tools <p> 最近日曜の新聞の書評は割とよく目を通しますが、今日はこれ。 </p> <p> 人間ドラマ的な内容も面白そうですけど、やはりその世界の仕組みが面白そう。<br />たとえば、都庁の設計が最終的には丹下健三になったというは昔から僕も知っていて、<a href="http://ja.wikipedia.org/wiki/%E6%9D%B1%E4%BA%AC%E9%83%BD%E5%BA%81%E8%88%8E" target="_blank">wikipedia</a>にも載ってます。<br />しかし、実際に建てたのは誰かというとよく分からなくて、例えば<a href="http://www.kajima.co.jp/tech/office/ex/ex7_00/index2.html" target="_blank">鹿島</a>とか<a href="http://www.shimz.co.jp/tw/works/01office/20.html" target="_blank">清水</a>とか入ってるみたいですけど、本当はもっといろいろ入っているような気がする。設計が重要で、実際の施工は重要ではない?<br />けど最近だと、例えば赤坂サカスとかミッドタウンは三井不動産が作ったんだね、というのは分かるけど、設計をやっているわけではなくプロジェクト管理ということで、設計がどこかというのはあまり出てこない。<br />あるいは昔家庭教師をやっていたところのお父さんが竹中工務店の人で、俺が作った、ということで<a href="http://ja.wikipedia.org/wiki/%E3%81%A1%E3%82%83%E3%82%84%E3%81%BE%E3%81%A1%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC%E3%82%BA" target="_blank">ホテル阪急インターナショナル</a>に連れて行ってもらったことがありますが、こちらは設計も施工も竹中で、確かに「俺」が作ったんだなという感じ。<br />設計においては、個人(と言っても丹下事務所とか磯崎事務所は大所帯だとは思いますが)事務所も大手デベロッパーも並列で、大手は設計だけやることもあるし全部やることもあるし。そんな中で、誇りを持って俺が作ったと言える構造とか、興味深いです。 </p>

こみゅぷらす Community Launch 2008

午前中フットサルに行っていて大幅に遅れました。すみません・・・ 飲みながら、テクニカルな話を聞いたり、他人のコーディング姿を見る、最高ですね! お話しさせていただいた内容から。 ・テストしやすいコード設計はまだまだ必要 ・Source AnalysisのVB版が出るかは全く分からないし、実際はなかなかルール作りも難しいとすると、まずはコードメトリクスというのも検討するか ・新人さんが、1年間ひたすらテストばかりをやらされるというのはやはりつらそう。でもよいテスト仕様が書ける技術は絶対必要なのでがんばってください。 はじめて学ぶソフトウェアのテスト技法宗 雅彦 by G-Tools

有償稼働率

うちの言葉では直接率。 SIをやるのは正社員の終身雇用を守るため? SIの現場にいればわかるけど、いつも案件があるわけではないから、有償稼動していない時間というのは存在する。その有償稼動していない時間は、企業的にはできるだけ減らしたい。正社員をいっぱい抱えると、どうしても有償稼動していない時間が増える。だから、案件の状況によって変わる部分を下請けでカバーするという構造。 大きな仕事をやる分にはまだどこかにお願いすればカバーしてもらえるからいいですけど、2週間とか1カ月とかの仕事でいちいちよそにお願いしてられないです。そんな状況で、直接率をたとえば90%にキープしようとすると、90%に達するまでは仕事を受け入れ続け、緊急の割り込み仕事(商談支援・見積などが典型)が入ると、その個人は簡単にオーバーフローします。それでいながら、原価管理をプロジェクト単位で行いますので、他人に頼むオーバヘッドが大きいと判断すれば、かりにその人の直接率が低くても仕事を依頼するとは限りません。(不機嫌な職場ってまだ読んでませんが、こんなこと書いてますかね??) プロジェクトのコストを考えるときに、人件費中心で考えるのはやめられないですかね。仕事が少なくても人件費はかかるんです。と同時に、人間はいろいろな目的に使うことができるんです。自分たちの開発はそんなに完璧ですか?次の開発のためにやっておくべきことなんて山ほどありますよね?プロジェクトごとの原価管理なんてやってないで、個人も組織もレベルアップに時間を使わないと。それをやって自分たちがアウトプットするものの価値を高めていかないと、目先の直接率を上げたところで、総崩れですって。 単価ではなくて、自分たちが提供するものの価値を上げる。価値って言うと抽象的になってしまいますが、価値の一つの例はリリースまでの時間。今3ヶ月で提供しているものを3週間で提供できるようになれば、それは提供できるものの価値が大きく上がっています。そこまで来れば、直接率という概念で考えて40%くらいでも成り立つんじゃないかな、とこれは根拠レスですが。 大丈夫、そうなっても雇用危機にはなりません。「間接時間」でやるべきことはまだまだあります。これをやっておけば次の仕事は1年かかっていたものが1か月でできるようになる、ということであれば、そこに人を投入すべきです。 夢物語ではないと思っているんですけどね・・・ (まとめ) ・SIerの価値は、様々なSIを経験することによりアウトプットの価値を高めるところにある ・原価管理、特に人件費の管理を変えることにより、アウトプットの価値を向上させるための活動を充実させよう ・そのためにはまだまだこの業界、人は足りないはず   不機嫌な職場~なぜ社員同士で協力できないのか (講談社現代新書 1926) 河合 太介 おすすめ平均 よりよいコミュニケーション環境を目指して 第5章、最終章がポイント 共感はしたけれど 本の主張には賛同できるが… 協力体制構築のヒントあり Amazonで詳しく見るby G-Tools

原価の分からない製造業があるのだろうか

http://itpro.nikkeibp.co.jp/article/COLUMN/20080528/304481/ どなたが書いていたのか忘れてしまったのですが、ソフトウェア開発の原価は作業工数だけですか? 測りやすいものだけを測ってないですか?ライトの下だけを探してないですか?

続App Engine

http://typecast.typepad.jp/t/typecast/30321/232075/23583278/list_comments などを参考に、otherで認証成功。 softbankerはれっつごー!

ドラッカーの泥へのスタンス

今さら参戦する気もないですけど、読み終わったので。 テクノロジストの条件 (はじめて読むドラッカー (技術編)) 上田 惇生 おすすめ平均 ぜひ読んで! 7000年後の課題にいかに対応するのか。 トホホ、ペーペーの及ぶところでは、なかったです 異色の切り口と感じました MOTの原点 Amazonで詳しく見るby G-Tools <p> やはりテイラーの話になります。<br />テイラーは熟練なるものは存在しないと断言しました。それまでは技術は長年の修行によって熟練させるものでした。それをテイラーは、すべての仕事は分析可能とし、方法に従って仕事をすれば誰でも第一級の賃金を得られるようになるとしました。<br />「生産」において生産性が向上したのは、別に機械のおかげではなく、知識を適用したからということです。 </p> <p> で。まず「生産」なのかという問題があります。そしてそれ以上に重要な問題が、知識を適用できているのかということです。さらに、適用しているつもりで硬直化させていないかということもあります。 </p> <p> 苦労は必要だと思いますけど、それは未来への投資としての苦労ですよね。ある意味気持ちの持ちようでもあるんですけど。 </p> <p> 最後のインタビューでの情報論もちょっと面白かったです。今のところ、情報のほとんどは組織やグループの内部のことについてのものだと。一番大事な市場や経営環境や技術変化についての情報は未整備のままであると。<br />しかし、2005年のインタビューの割にはちょっと古いような気もします。今は外の情報と中の情報が完全に分離してしまっているような気がします。どうしても中の情報が必要な時は、頑張って探しますが、しかし、基本的には何かを知りたいときは、まずGoogle。なぜなら中の情報は探しにくいから。だから知的作業の生産性が上がらないのではないかな。 </p> <p> &#8212;<br /><a href="http://www.accesstrade.net/at/c.html?rk=0100382v0044mz" target="_blank"><img alt="ビジネス+Bamboo パソコンに思いを書きとめよう。" src="http://www.accesstrade.net/at/r.html?rk=0100382v0044mz" border="0" /></a> </p>

Google App Engine SMS認証問題

喜び勇んで登録しようとするも Verify Your Account by SMS ページで認証エラー問題に引っかかる。 料金徴収につなげるためにこんな認証にしたんでしょうかね。

Light and Shade

実行委員として立候補しながら本当の意味で何もせず、当日も懇親会のみ参加という暴挙。 にもかかわらず温かく迎えて頂きありがとうございました。 正味時間と標準時間のお話とか、7日単位のイテレーションで移動平均とか、短時間で濃いお話を聞くことができ、感謝感激です。6.6に向けても頑張りますよ。 さて、今回思ったのが、「みんな悩んでる」。いろいろ活動していても、実はみんな悩んでるんだな・・・いや、逆だ! みんな悩んでいても、明るく活動している! 人それぞれ悩みはあるでしょう。けど僕みたいに頭が真っ白になってじめじめしていたら周りにまで不幸を広めてしまうだけ。 影があるなら光がある。なくすものさえない今がチャンス。Light and Shade!