ソーシャル素人がソーシャル系ビジネスをやりながら学んだこと - ひがやすを技術ブログ
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 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
受託開発に未来はない? - ひがやすを技術ブログ
私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
DIコンテナの必要性 - ひがやすを技術ブログ
DI コンテナの起動が遅いなら、起動が速いのを作ればいいじゃない 何度か書いているとおり、DIはテストをしやすくすることが一番のメリットであり、オンプレミスの世界では、今でもある程度有効です。ただ、appengineの世界では、テストする環境が整えられているので、DIを使う必要はないということです。 http://d.hatena.ne.jp/higayasuo/20091115/1258245284 DIを使ったことがある人はわかると思うけど、DIには、ある程度のめんどくささがあります。appengineの世界では、DIがなくてもテストが簡単にかけるので、わざわざめんどくさいことをする必要はないでしょう。 appengineの世界でテストがどれくらい書きやすいのかは、次のustをみればわかります。 http://www.ustream.tv/recorded/6377235 技術的には、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
