「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
オブジェクト指向は継承で多態するプログラミング - きしだのHatena
オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人には、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがちに思います。 実際はカプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけです。 さまざまな人のオブジェクト指向の定義 本来ならどのように継承こそがオブジェクト指向なのかという説明をするんですが、かなり長くなりそうなので、とりあえずはいろいろな人たちのオブジェクト指向の定義を抜き出してみます。 「ここに挙がってるのはオブジェクト指向の一派にすぎない」というような意見もありますが他の派閥についてまとまって定義され共通認識になっているようなものは見当たらないので、プログラミングの指針には なりづらいと思います。 ストラウストラップ C++を産んだストラウストラップは「C++の設
プログラムを教えて理解されない場合は教える技術の不足 - きしだのHatena
プログラムが組めるとプログラムが教えれると思いがちだけど、教えることは別の技術です。 教えてもなかなか理解してくれないとき、プログラミングに向いてないとさえ言う人もいますが、教える側の教える技術の不足です。 教えることも技術のひとつだと気付けば、教えてもなかなか理解してくれないときに技術の不足であるということにも思い至れると思います。技術の不足であると気付けば、改善もしていけます。 そして教える技術というのは、インストラクショナルデザインという名前で系統だてて整理されています。 たとえばそのまま「インストラクショナルデザイン」など、タイトルにインストラクショナルデザインが含まれた書籍もたくさん出ています。 インストラクショナルデザイン―教師のためのルールブック 作者:島宗 理発売日: 2004/11/01メディア: 単行本 他にも、タイトルにはインストラクショナルデザインとついてないけどイ
ソフトウェアエンジニアの人数に関するフェルミ推定 - きしだのHatena
以前から、日本のプログラマってどのくらいいるんだろう？って思ってて、なんとなくの数字を思い浮かんでいるので、メモ的に書いておきます。 2〜3倍の差はあっても1桁は違わんだろうなーくらいの誤差感です。 まず、プログラマ全体の数。どうも、20万人〜100万人くらいな感じ。かき集めて200万人はいなさそう。 IT人材白書2017の「情報処理・通信に携わる人材」が100万人ちょい。 ある程度の機能を持ったプログラムをドキュメントやチュートリアルを見ながら自分のコードで書けるというのは、5万人〜10万人くらいではないかなと。 本を買ったりして自分で勉強する人が3〜5万人。 小さなアプリケーションをひとりで作れるレベルだと1〜3万人。 自発的に勉強会に出る人は5000人〜1万人。東京に6000人、大阪700人、福岡300人くらいかなー。*1 高階型がわかるとか、高階関数がわかるとか、ある程度「プログラ
Java SEバージョンアップでのトラブルの話が面白かった - きしだのHatena
Java Day Tokyo 2015で、NECのJava SEバージョンアップでのトラブルの話が面白かった。 Java EEアプリケーションサーバの開発現場で見たJava SEの実際 資料はこちらで公開されてるので、資料に書かれてることはそちら参照という感じで、どんな話だったか書いてみます。 Java Day Tokyo 2015 アプリケーションサーバーを提供する中でJava SEをバージョンアップしたときに出て来たさまざまなトラブルの話と、Java SE 8から導入されたMetaspaceの話が主でした。 Java EEは機能が標準化されているので、アプリケーションサーバーはカスタマーサポートで差別化をはかるしかない、顧客から見ると、Java SEやOSまで全て含めてアプリケーションサーバーなので、全部対応していく、という話をされていました。 Javaにもそれなりにバグはあって、アプ
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
勉強会に参加しないと不幸になる話 - きしだのHatena
昨日のOSC福岡2013の「勉強会x勉強会」セッションで飛び込みLTしたときのプレゼンに加筆して公開しました。 追記：福岡の人はFacebookの福岡IT関連勉強会に参加しておくと、勉強会情報が得やすいと思います。
ソフトウェア工学は失敗している - きしだのHatena
特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
CPUはオワコン - きしだのHatena
FPGAでCPUを組んでると、フェッチ部やデコーダ部で足し算や掛け算をしようとして、そんなことしたらCPUの意味ないなーと思ってしまうことがありました。 で、よく考えたら、FPGAでロジックを組むならCPUの意味はないんです。 だいたい、ひとつの処理実行するのに何クロックかかってんですか！と。 CPUでは、計算効率をよくするためにパイプラインという仕組みが使われています。 最近では、18段とかのパイプラインもあるようです。 ここで、18段のパイプラインのうち、実際に計算を行うのは2段か3段だったりします。残りの15段くらいは、命令や計算結果を読んだり書いたりしているだけです。 このパイプラインも、ほとんどはメモリの読み書き、それも命令の読み込みに多くが使われます。 であれば、CPUにしなければ、18段全部計算に使えるんじゃね？という話になりますね。 決まりきった計算を行うのに、いちいちメモ
「2冊目の本のほうがわかりやすい本」の誤謬 - きしだのHatena
関係ないけど、誤謬(ごびゅう)を「ごしん」と読んでた時期がわたしにもありました。 で、本題。 先日「C++の授業を受けて理解できなかった人が、RubyでRailsをやったら簡単に理解した、Rubyすばらしい」という話がTwitterで流れていた。 ただ、これをもって、Rubyで授業やるとわかりやすい、と単純に考えてはいけない。 確かにC++はヘッダファイルやポインタみたいな、混乱ポイントがあるわけだけど、教育用途なら1ファイルに全部書くことでヘッダファイルからは逃れれるし、C++のライブラリつかえばポインタはあとまわしにできる。Rubyでも文法を淡々と初心者に教えれば「わけわかんない」という感想だけで終わらせることもできる。 なにより、このご時勢にプログラムの最初の授業をC++でやってる先生の授業がわかりやすいはずがない。わかりやすさに気をつける先生なら、JavaかC#かRubyか使ってい
九州大学医学部のほうから来たKさんの開発した「ゴーストfor文」がものすごい - きしだのはてな
九州大学医学部のほうから来たKさん*1が開発した「ゴーストfor文」がものすごい。 普通の大人なら、1分で指定回数繰り返すfor文が書けるようになる。 やりかたは下の図を見てね。 変数iを使って5回繰り返す場合 ・iを①、②、④に入れる ・5を③に入れる ・答えは for(i = 0; i < 5; i++) これでインド人に勝てます！ なお、普通に書いてるだけじゃないかという批判にKさんは Cなどでfor文の書き方を知っている人はいっぱいいます。でも、Cをやってこなかった文系学生だって一杯いるのです。そういう人がお魚のイラストで簡単にfor文が書けるようになればそれでいいじゃないですか。 などと反論しているようです。 参考：東大医学部現役合格生の開発した「ゴースト暗算」がものすごい - Togetter *1:東京からみた場合
システムはどのくらいのデータを扱うか。 - きしだのHatena
ちょっと気になったので調べてみたら、営業のためのデータはどんな業態でも一社だいたい月10億件くらいで頭打ちっていう感じになった。 追記 2011/9/17 15:54 業態を比べたいので、国内の最大シェアっぽい企業で比べてます。 世界に広げたとしても、実業にからむなら、だいたいは会社が分かれてシステムも分けるだろうし、トヨタの販売台数が世界770万台、国内130万台でせいぜい6倍というのを見ても、一体だとして10倍の差は出ないし。 トヨタの2011年国内販売台数、130万台の見通し | ロイター 追記ここまで コンビニ 最初にたくさんデータが発生しそうだと思って考えたのがコンビニ。 フランチャイズ協会のデータによると、全国の店舗数が43690店舗、月間客数が13億人で、客単価が600円。 http://www.jfa-fc.or.jp/particle/42.html 一番でかい7-11の
クラウド時代のトランザクション（2009-02-09 - きしだのはてな）
今のデータベースシステムでは、トランザクションはACIDという考え方が基本になってます。 これらの用語の頭文字をとってACIDです。 Atomicty 原子性：トランザクション中の処理は全部行われるか全く行われないか Consistency 一貫性：トランザクションが完了したとき、データの状態が正しい Isolation 分離性：複数のトランザクションが実行されても、完了してないトランザクションが他のトランザクションに影響しない Durability 永続性：トランザクションが完了したら、その状態は保存される。 ただ、分散システムでACIDを適用しようとすると、複数のサーバーで処理を分担させたときに一台のサーバーがこけてたらトランザクションが全く行えないとか、トランザクションマネージャーがボトルネックになってしまうとか、スケールアウトしにくくなってしまいます。 Brewerという人が、一貫
RDBMSの時代の終わりが見えてきた - きしだのはてな
クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonのSimpleDB。どれも、基本的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
