ソーシャル素人がソーシャル系ビジネスをやりながら学んだこと - ひがやすを技術ブログ
2010になって、私は感じました。ITの流れが変わった。 これからの主役は、エンタープライズではない、ソーシャル系のビジネスだと。 勘違いしないで欲しいのは、エンタープライズ系のビジネスがだめだと言っているわけではないということです。今という瞬間なら、エンタープライズ系のビジネスは重要でしょう。 しかし、儲からないし、未来はない。 これが下記のエントリにつながってきます。 SI業界からはさっさと抜けだしたほうがいい http://d.hatena.ne.jp/higayasuo/20110111/1294718077 サービスを考える人と、プログラムをする人は、求められているスキルが違うから、両方をやるのは難しいんじゃないというような、眠たいコメントもあったけど、誰もができるようなことをしてたんじゃ、それは金になりません。 誰もができないことができるから金になる。人と差別化できなければ、そ
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
2011年のPaaSはAmazonの独り勝ちか? - ひがやすを blog
AmazonからBeanstalkが発表されました。 http://aws.typepad.com/aws_japan/2011/01/introducing-amazon-beanstalk.html Beanstalkを間違っているけど、分かりやすく例えると制限のないAppEngineのようなものです。 GoogleからはApp Engine for Business(4Bと省略)、SalesforceからはVMforceが登場し、2011年のPaaSは、これらの技術の戦いになるでしょう。 どの技術が勝つのか予想する前に、PaaSには、二つの分野が存在することを理解しておきましょう。ソーシャル系などのスケールアウトが必要な分野とそれ以外です。 それぞれの分野で必要とされるものが違うので、分野ごとに勝者を予想する必要があります。 スケールアウトを必要としない分野で求められるのは、制限の無
AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ
AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
PHPを叩く人にガツンと申し上げたい - ひがやすを技術ブログ
よって、PHPを「学ぼう」とするのは、時間の無駄だと弾言する。学ぼうとするから報われない。ただ必要な時、必要な呪文を、必要なだけ唱えればいいのだ。それ以上をPHPに期待するのは間違いだ。「なぜ」を問うてはならない。 PHP叩きって毎年必ず起こるじゃないですか。で、だいたいの結論が、PHPは「動くWebを作るには最適」でそれ以外はだめなんだということになってる。 俺からみると、PHPでさくっとできることは、たいていのLLで、同じようにさくっとできる気がする。デフォルトで用意されている呪文を一発唱えればいいという話も、そんな呪文を移植すればいいだけの話。移植もそんなに難しくはないでしょう。 デプロイや環境を用意するのが簡単だというのは、簡単にまねできない気もするけど。 だから、不思議なんですよ。PHPが「動くWebを作るには最適」いうなら、同じようなことは他の言語でもできるだろうと。 PHPは
自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力
進化し続けることはオープンソースにとって必須なわけではない - ひがやすを技術ブログ
「毎日毎日動きを続けていると、適切な大きさの問題がつぎからつぎに生まれる」 「それさえ生まれれば、インターネット上にはそれを解決する人が現れる。新聞にクロスワードパズルが載っていたらそれを解く人がいるように、それをみんなが解いていく」 それがオープンソースなんだと。 出展はこちら。 http://www.1101.com/umeda_iwata/2008-11-18.html もともとは、Matzともっちーの対談から生まれたものですね。見たことある人も多いでしょう。目からうろこが落ちた人は少ないかもしれないけど。 Rubyについていえば、上記のことは正しいと思います。Rubyが成功しているのが一番の証拠。ただし、それがオープンソースのすべてなわけではない。オープンソースは、そんな一言で語れるものではない。 別に俺が正解を知っているわけじゃないけど、機能が足りないうちは、いろんな人にその問題
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
