[徳力] 日本のウェブは遅れているのではなく、急速に進みすぎたのではないかという仮説
ITmediaの岡田さんによる梅田さんのインタビューに端を発した、「日本のWebは残念」論争ですが、梅田さんの人物考察が一段落するのに併行して、いろいろと日本のウェブの特徴についての考察が始まっているようです。 せっかくの機会なので自分の考えも、まとめておきたいと思います。 （海部さんのエントリに刺激を受けて、アテネの学堂のイメージ） 今回の議論に目を通していて、個人的に気になったのは下記のあたり。 ・nobilog2: Web日本語文化圏、私なりの考察 ・梅田氏と「アテネの学堂」 – Tech Mom from Silicon Valley ・日本のネットが「残念」なのは、ハイブロウな人たちの頑張りが足りないからかも知れない（追記あり）：小鳥ピヨピヨ ・無名が主役になれる日本は世界のパラダイス（たとえばラーメン） – [ f ]ふらっとどらいぶログ いずれも米国のネットに対して、日本のネ
![[徳力] 日本のウェブは遅れているのではなく、急速に進みすぎたのではないかという仮説](https://cdn-ak-scissors.b.st-hatena.com/image/square/fce58eaae20f5139f86296e5fcd2a0ebbb3e80cc/height=288;version=1;width=512/http%3A%2F%2Fblog.tokuriki.com%2Fwp%2Fwp-content%2Fuploads%2F2015%2F09%2Fdefault.png)
くそなモデムがバカ売れした理由についても話す - はてなポイント３万を使い切るまで死なない日記
この前のエントリを、サポートが評判よかったのでモデムが売れまくったという話に受け取ったひとが多かったが、それは間違いなので補足したい。 そもそも世の中にサポートが良くてヒットする商品なんてない。サポートがよくてヒットするなんてことがあったら、大変な美談になって“ちょっといい話”になるところだとは思うが、現実はもっと夢がないものなので、そもそもモデムがなんでヒットしたのかについて補足しようと思う。 サポートではモデムが売れない理由は簡単だ。サポートがよいことによる販売数量の増加効果は購入した人のリピートか、まわりのひとへの口コミ効果によってしかあらわれないからだ。つまり売れた後に中長期的に効果が現れるパラメータであって、最初に売れる理由にはならない。 じゃあ、最初に売るために必要なのはなにかというと、まあ、人間がモノを購入する過程をモデル化して以下の順序で脳内シミュレーションすれば推測が可能
あるRuby on Railsプロジェクトのふりかえり - yuum3のお仕事日記
昨年末から始めた、Ruby on Rails を使ったある仕事がひと段落したので、ふりかえってみました。 この仕事で作ったWebアプリの詳細は書けませんが、画面数 60、テーブル数 15 と小規模のものでした。システムはところどころに難しい部分はありました、UIは一部に Ajax(JQueryを使用)を導入し使い勝手を高めています。 1. ソースコードが少ない！ 書いたRubyコードの行数を合計すると 約3600行 しかありませんでした！ 1画面あたり 60行しか書いてない !! ・・・「あんまり仕事してないじゃん！」と思わずつぶやいてしまいまました ^^); やはり、Ruby on Rails は生産性が高いと言われる通りです。 ただし、だらだらとコードを書かないように以下のように注意しました。 共通部分はモジュール化しMix-inで共有 継承による機能の共有は設計が難しくなりますし、委
電子工作の経験がなくても、誰でもハードウェアを自作できる時代が来ていた！ : akiyan.com
電子工作の経験がなくても、誰でもハードウェアを自作できる時代が来ていた！ 2009-06-07 『電子工作』 なんとなく興味はあるけど、電気回路なんてまったくわからないし、はんだごてとか使うのもやたら危なそうだし...というイメージが（少なくとも個人的には）ある電子工作の世界。 そんなイメージは、とあるセミナーでぶっ壊されました。 なんと、最近の電子工作の世界は「プログラミング未経験でもperlでCGIやPHPぐらいならできそう」と同じくらいのところまできていたのです。 たとえば、PCを使わずに「人が通ったことをセンサーで感知して、自動的にtwitterにpostする機械」を、電子工作経験がほぼゼロの僕でもちょっとがんばれば作れそうと思えるぐらいでした。 「できたらいいなあ」が「やればできちゃう」ぐらいになってて、なんだか、視野がぐぐっと広がった感じがしてかなりテンションがあがりました。
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
