ソーシャル素人がソーシャル系ビジネスをやりながら学んだこと - ひがやすを技術ブログ
2010になって、私は感じました。ITの流れが変わった。 これからの主役は、エンタープライズではない、ソーシャル系のビジネスだと。 勘違いしないで欲しいのは、エンタープライズ系のビジネスがだめだと言っているわけではないということです。今という瞬間なら、エンタープライズ系のビジネスは重要でしょう。 しかし、儲からないし、未来はない。 これが下記のエントリにつながってきます。 SI業界からはさっさと抜けだしたほうがいい http://d.hatena.ne.jp/higayasuo/20110111/1294718077 サービスを考える人と、プログラムをする人は、求められているスキルが違うから、両方をやるのは難しいんじゃないというような、眠たいコメントもあったけど、誰もができるようなことをしてたんじゃ、それは金になりません。 誰もができないことができるから金になる。人と差別化できなければ、そ
SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
App Engineのユニーク制限を正しく理解しよう - ひがやすを技術ブログ
Google App EngineではRDBMSのようなUnique Indexをサポートしていません。ユニーク制限を実現する場合は、トランザクション中でKeyを使ったgetとputを組み合わせる必要があります。 ここでは、email addressがユニークだったらそれを確定してtrueを返し、そうでない場合にはfalseを返すコードを考えます。 最初にトランザクションを使わないコードを見てみましょう。KeyFactory.createKeyの最初に引数は、kindといってテーブル名みたいなものです。 public boolean putUniqueEmailAddress(String value) { DatastoreService ds = DatastoreServiceFactory.getDatastoreService(); Key key = KeyFactory.cr
Bigtableの使い方教えます - ひがやすを技術ブログ
GAE/Jを使うのに一番戸惑うのが、データのストレージがRDBMSではなく、Bigtableなことでしょう。 JOINが使えなかったり、WHERE句でORが使えなかったり、これまで慣れ親しんでいた方法が軒並み使えません。 これらの制限は、Bigtableに限ったことではなく、KVS(Key Value Store)型のクラウド系のデータベースではみんないえることだと思います。 最初、私も戸惑ったんだけど、いろいろ触っているうちに気付きました。昔、AS400でやってたころと一緒ジャンと。AS400とは、IBMから出ているオフコン(?)ですね。今は、System iと呼ばれているようです(最新だとまた違うようですが)。 AS400のファイル(テーブル)は、キーもしくはインデックスでアクセスします。インデックス(論理ファイル)は、ある行の特定のカラムがソートされていて、物理ファイル(テーブル)へ
ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ
ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒
奥さんにささげる - ひがやすを技術ブログ
奥さんっていっても妻のほうじゃなくて、http://developer.cybozu.co.jp/kazuho/のほうね。 昨日のTokyo Cloud Developerで、kazuhoとBigtableの話をしてたんだけど、ちょうど、松尾さんからいい資料があるといわれてみてみたらとてもすばらしかった。松尾さん、ありがとうー。 http://sites.google.com/site/io/under-the-covers-of-the-google-app-engine-datastore もう既に見ているかもしれないけど、一応ご報告。 Google App Engine(Bigtable)の内部のデータのもちかたが詳しく説明されています。 これをみずに、Bigtableは理解できない。 奥さんじゃない人も、App Engineに興味のある方は見るといいよ。
10年泥で広がれエンジニアの輪 - ひがやすを技術ブログ
＠ITの記者の方に広がれエンジニアの輪の取材を受けました。 取材の途中で、あの「10年は泥のように働け」「無理です」――今年も学生と経営者が討論の記事を書いた方だと知って超びっくり。 取材するに当たって、私の過去のblogの記事や他のイベントで話したことをかなり調べていたようで、すごい仕事熱心だということが、伝わってきました。 ネットの文章だけで人を判断するのは、かなり危険ですよ。リアルに会わないとわからないことのほうが多いものです。 後、取材のときに超勘違いをしてました。FxUGの横田さんに紹介してもらったのですが、なぜかKvasir/Soraの横田さんだと勘違いしてました。 どっちの横田さんもごめんなさい。m(_ _)m 広がれエンジニアの輪を全部読み直してみて(これまでは一部の人しか見てなかった)、otsuneのリアルな顔を知ることができてよかった。 の顔しか知らなかったから。 広が
DRYについてのよくある誤解 - ひがやすを技術ブログ
WEB+DB PRESS vol.49で、「現場で役立つDRYの基礎知識」が特集されています。とても、良い記事だと思うので、ぜひみなさん、読んでください。 ただ、ちょっと補足をしておきます。 記事の中で、DRYは、「達人プログラマー」の中で、とりあげられ、Railsによって広まったとされています。確かに、Rubyの世界ではそうかもしれないけど、DRY原則というのは、ERモデリング(DOA)の世界では、ずっと「One Fact In One Place」という言葉で知られてきました。 ERモデリングにおける正規化は、「One Fact In One Place」を具体的に実現するための手段です。 DRYという言葉そのものを広めたのは、間違いなくRailsです。しかし、DRYの考え方そのものは、昔からあったし、「One Fact In One Place」という言葉も、昔から有名だったというこ
報酬にこだわらないとプログラマの地位は低下するよ - ひがやすを技術ブログ
プログラマーはお金とは無縁の存在です。 プログラミングに誇りを持ちたいなら単価を上げること - ひがやすを blogには全く賛成できません。 なぜなら「プログラム」は本質的に経済的価値を持っているわけではないので、プログラムを作る人、すなわちプログラマーは本質的に経済的価値をもつ存在ではないからです。 こう思っている人は、そこそこいるかもしれないけど、だからこそ、プログラマーの地位が低いんだと断言しておこう。プログラムは本質的に価値がないって思っているのがそもそも間違い。 良いプログラムは価値がある。元の山本さんの話にも出てくるけど、きちんとしたプログラムによって、システムは、サクサク動くようになり、業務上の使い道が大きく広がるのです。 価値のあるものからは、対価(金)を得なくてはならない。 エンジニアに限った話ではないけど、自分の成果に対する報酬は、こだわるべきだ。じゃないと優秀な人が入
メタプログラミングの光と影 - ひがやすを技術ブログ
メタプログラミングとはソースコードを生成するプログラミングのことです。メタプログラミングによって生成したソースコードは、eval関数で実行することができます。 メタプログラミングとは、ロジックを直接コーディングするのではなく、あるパターンをもったロジックを生成する高位ロジックによってプログラミングを行う方法、またその高位ロジックを定義する方法のこと。 メタプログラミング - Wikipedia だから、eval関数は、手段であり、メタプログラミングそのものではない。これは弾さんが指摘してますね。 evalだけがメタプログラミングの技法ではないし、またevalはその威力ゆえ最後の選択肢とすべきだ。 弾さんのパフォーマンスの指摘に対して、miyagawaさんが、「必ずしもevalが遅いとは限らない」と指摘してますね。 メタプログラミングとevalのベンチマーク - Bulknews::Subt
「RDBMSの時代の終わりが見えてきた」についてそろそろ一言言っておくか - ひがやすを技術ブログ
2008-12-12 いくつか誤解を生みそうな表現があるので、それをまずは指摘しましょう。 プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。ORマッピングがそれです。 これが、意図的かはわからないけど、ミスリードを生んでいます。「RDBMSの時代の終わりが見えてきた」というタイトルで、こういう書き方をすると、「ORマッピングによって、すでにRDBMSからの脱却の準備は始まっている」という風に読めるでしょう。これが、ミスリード。 JPAが大切だと思っているのは、永続パラダイムの転換に、コーディングを変えることなく対応できるからです。もちろんJPA+RDBMSのシステムをJPA+非RDBMSに切り替えれるという話ではなく、プログラマのコードの書き方の対応の話です。 これをもう少し、噛み砕くと、JPAのJPQL(SQLもどき)を使えば、SQLとしては統一されていない複
開発の生産性を目に見えて向上させる方法 - ひがやすを技術ブログ
12/28から1/2まで、石川県の七尾市(かみさんの実家)にこもって、ずっとSlim3の開発をしてました。超生産性があがったよ。Slim3 Strutsがもう完成したくらい。 何で生産性が向上したかというと、ネットに遮断されていたから。これは、がちで利く。 特にTwitterにへばりついている人にとっては、その効果が高いと思う。Twitterは、コミュニケーション力を上げるけど、生産性は驚くほど下がる。みんな、うすうす気付いていると思うけど(笑)。 とはいえ、東京に戻ってきたら、ネットは覗くけど、Twitterは、ほどほどにしたいと思う。 話は変わるけど、コメントに質問のあった「Seasar2入門」の発売日は、2月の初旬になりそう。SAStrutsとS2JDBCの本です。 私が、コンサルで教えていることをそのまま本にしました。ページ数も230ページくらいなので、さらっと読めて、ぴたっと頭に
日本とシリコンバレーの泥事情 - ひがやすを技術ブログ
マドル・スルー（muddle through） シリコンバレーの流儀とも言われる、この言葉。まるで、泥の中に放り入れられたかのように、上下も左右もわからなければ、解決策も見当たらず、出口がどこにあるのかさえも見えない。その泥の中から顔を出すためには、頭で考えているだけではだめで、体を動かし、もがきながらも行動に移さなければならないと、渡辺は自身の経験を振り返って言う。起業直後に襲いかかる極めて困難な状況をマドル・スルーしながらクリアした者だけが、シリコンバレーでは生き残れる。 日本では、否定的な意味で使われることの多い10年泥問題ですが、シリコンバレー的に、この困難を乗り切れたものだけが、成功できると前向きにがんばるほうが成功しそうだよね。 泥の中にいる困難を嘆くより、泥から抜け出して成功することを目指してがんばったほうがいい。
女性に「何度も同じことを言わせるな」と怒ってはいけない - ひがやすを技術ブログ
女性に「何度も同じことを言わせるなよ」と怒った経験のある男性は、きっと多いよね。俺もそうだし。でも、そんなことで怒っても、余り意味がない。女性はそういうもんだとあきらめて、何度も同じことを言ってあげたほうが、腹が立たない分、実は得なのです。 例えば、うちのかみさんが、ダイエットのためにコアリズムをはじめたとします。コアリズムって何?ってかたは、こちらを見てください。 http://www.exabody.jp/disp/CSfLastGenGoodsPage_001.jsp?GOODS_NO=69590&af_id=17&banner_id=kaiadw クワバタくびれ大作戦でやっていたあれです。 かみさん:ウェスト2cm細くなった!!! 俺:おめでとう ほめることは、何度繰り返しても違和感はないよね。 かみさん:体重が変わらない(あるいはちょっと増えた)。 俺:ある程度の筋肉もつくだろう
10000時間プログラミングまで後5年 - ひがやすを技術ブログ
彼によると、伝説的なプログラマーのビル・ジョイのような人や、ビル・ゲイツや、ビートルズのようなバンドの成功も、「10000時間の努力」と、いくつかのタイミングが支配しているのだそうです。 おれは、30才になるまでほとんどプログラミングをしてこなかった。時間にして、200時間くらいだろう。まぁ、典型的なSIerのSEだったからね。仕様を考えることと、レビューしかやってこなかった。 でも、2000年にXP(eXtreme Programming)と出会ってから変わる。プログラミングに興味を持ち、社内フレームワークだとか、アプリケーションサーバだとかを作り始める。2002年にはSeasarの開発も始めた。 毎日、2時間はプログラミングしてきたかな。今でも平均したら、2時間くらいはやってるだろう。ざっくり、年間700時間とする。 するとこれまでプログラミングをしてきた合計時間は、200 + 9 *
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
クリエータを大切にする会社 - ひがやすを技術ブログ
会社のトップが老害だと、その会社で、働いている人は、将来を不安に思うことでしょう。特にSI業界では、昔、凄腕の開発者(あるいはマネージャ)がトップに着くと、昔と今の状況のギャップから不幸な老害を起こしやすいものです。 詳しくはこちらをどうぞ。 SI業界の老害が若手と下請けを蝕む理由 うちの会社(電通国際情報サービス)がどうかというと、幸いなことに老害の被害が少ないんじゃないかと思います。 なぜかっていうと、CEOや社長が電通出身だから。古いSIのやりかたを知らないんです。もちろん、知らないことが良いとは限りませんが、昔のSIを経験しているからこそ起こる老害がないんです。トップがそうだと、その影響で経営層も老害を引き起こしにくくなります。 うちのCEOは、クリエイティブ出身で、いくつか有名なCMも手がけていたみたいなんですが、そのCEOに言われたことがあります。 お前はクリエイティブの連中と
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
