ソフトウェアエンジニアの人数に関するフェルミ推定 - きしだのHatena
以前から、日本のプログラマってどのくらいいるんだろう？って思ってて、なんとなくの数字を思い浮かんでいるので、メモ的に書いておきます。 2〜3倍の差はあっても1桁は違わんだろうなーくらいの誤差感です。 まず、プログラマ全体の数。どうも、20万人〜100万人くらいな感じ。かき集めて200万人はいなさそう。 IT人材白書2017の「情報処理・通信に携わる人材」が100万人ちょい。 ある程度の機能を持ったプログラムをドキュメントやチュートリアルを見ながら自分のコードで書けるというのは、5万人〜10万人くらいではないかなと。 本を買ったりして自分で勉強する人が3〜5万人。 小さなアプリケーションをひとりで作れるレベルだと1〜3万人。 自発的に勉強会に出る人は5000人〜1万人。東京に6000人、大阪700人、福岡300人くらいかなー。*1 高階型がわかるとか、高階関数がわかるとか、ある程度「プログラ
作って理解するWebフレームワーク - きしだのHatena
前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((
作って理解するDIコンテナ - きしだのHatena
DIコンテナ使ってるけど、アノテーションってなんなの！って聞かれて、作ってみたらわかるよと答えてみたので、自分でも作ってみました。 よくわかった。 「DIコンテナ使うと何がいいの？」ということも、作ってみるとわかります。あと「DIって何がいいの？」に関しては、「DIはちょっとコードを書くのが楽になるだけで、それだけあっても仕方ない、大事なのはコンテナ」と答えるようにしてますが、コード比率からもそれがよくわかります。 続編としてWebフレームワークも作っているので参考まで。 作って理解するWebフレームワーク - きしだのHatena まずはコンテナを作る とりあえず1ソースの状態で。 こんな感じで、管理する型を登録できるようにします。 static Map<String, Class> types = new HashMap<>(); static void register(String
乱数のたのしい話と遺伝アルゴリズム - きしだのHatena
金曜日の「プログラマのための数学勉強会＠福岡」で乱数の話をしてきました。 プログラマのための数学勉強会@福岡 #3 - connpass で、乱数の生成だとか、クイックソートや素数判定などの乱択アルゴリズムの話とかをしました。 乱数タノシイヨ 乱数のたのしい話 from なおき きしだ その中で、遺伝アルゴリズムで巡回セールスマン問題(TSP)を解くというのをやってみました。遺伝アルゴリズム、すいぶん昔から名前は知ってて、どういうアルゴリズムかも知ってて、実装もそんな難しくないと知りつつ、書く機会がありませんでした。なので、この機会に書いてみようと。 とりあえず最初に完全にランダムでTSPを解いてみます。 TSP with random ぐちゃぐちゃですね。 下部のグラフはその時点での最短距離。最初に距離が短いものをみつけていくけどだんだんみつかりにくくなる、という感じになっています。 1
ぼくの実装した最弱のディープラーニング - きしだのHatena
8月の頭からディープラーニングを実装していたのを、先日、プレゼンしてきました。 プログラマのための数学勉強会@福岡 - connpass ぼくの実装した最弱のディープラーニング from なおき きしだ ※追記 2023/4/12 SpeakerDeckにも置いてます https://speakerdeck.com/kishida/weakest-deep-learning-i-implemented GPU対応したり、ドロップアウトとかミニバッチとかいろいろ実装して、結構つよくなってます。 ちゃんと学習してくれないこと以外は。 ソースはこんな感じになってきています。 https://github.com/kishida/neuralnet/tree/CorrectOperationAsCCN GPU対応にはaparapiを使っています。JavaでGPUコードが書けるスグレモノです。 ap
ネットワークに自信のない人は東大講義の情報工学概論Ａを見よう - 2012-01-28 - きしだのはてな
東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。 http://ocw.u-tokyo.ac.jp/ その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。 その中で、情報工学概論Ａというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。 こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。 http://ocw.u-tokyo.ac.jp/lecture?id=11314&r=609526321 ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくとい
パーセプトロンからSVMでの画像認識まで、機械学習エントリのまとめ - きしだのHatena
なんかJJUGナイトセミナーで機械学習をやるっぽくて、定員100人が40人キャンセル待ちとかになってますね。 【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催 - 日本Javaユーザーグループ | Doorkeeper ということで、予習用だか復習(になるかわかんないけど)用に、2008年になんか機械学習をやってたときのエントリをまとめてみます。 今でこそ機械学習はなんかもりあがってるけど、2008年にぼくがやってたとき「ところで機械学習やってなんになるの？」ってよく言われてました。ぼくも「いや、なんかそこに機械学習ってものがあるから実装してる」みたいな答えをしてた気がします。特に目的はありませんでした。 たまたま サポートベクターマシン入門 という本を見かけて、なんか実装してみたくなっただけです。 変な力がありあまってたっぽい。 機械学習ことはじめ
プログラムの生産性をあげるためには - きしだのHatena
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
プログラマが勉強すること - きしだのHatena
今日もプログラマになる勉強する人のところで話をしてきました。 で、また適当にいろいろ書いてました。 http://www.slideshare.net/nowokay/20140228-31742219 今日は特に、この図の内容についてまとめておきます。 ※ このエントリは、主に今日の話を聞いた人を対象としています。前提や補足については省略しています。 まずはプログラミング言語を プログラマというのは、利用者に直接サービスを提供することはできません。コンピュータの上でプログラムを動かして、そのプログラムを使ってもらうことでサービスを提供します。 ※組み込みは前提から外しています。 そのプログラムも、コンピュータで動くものを直接記述することは現実的にできません。 なんらかのプログラミング言語で、プログラムを書くことになります。つまり、プログラマの仕事は直接的にはプログラミング言語をいじくる作
今どきのJava Webフレームワークってどうなってるの？ - きしだのHatena
昨日のSeasar2のエントリについたコメントなどで、「とはいえ代わりに何つかうの？」みたいな話が出てたので、とりあえずJava EEのWebフレームワークについて簡単にまとめてみます。 Java SE 8+Java EE 7+lombokで書いていますが、基本的なところはJava SE 7+Java EE 6でも大丈夫です。 なので、今どきとは書いてますが、基本的には2009年12月のJava EE 6ということで、実はすでに4年近くたってます。 何も考えてない なんも難しいこと考えないなら、やっぱJSPが楽ですよね。 なんでも書けちゃう。 <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content=
Seasar2を新規案件に採用するのはそろそろやめたほうがいい - きしだのHatena
Seasar2の機能追加停止が宣言されてから、すでに6年弱たっています。 Seasar2.4に対する追加要望があれば、もちろん検討します。ただし、大きな変更や追加はもうないでしょう。 Seasar2の今後のロードマップ 2008-01-29 - ひがやすを blog 後継になる予定だったSeasar3も開発が中止されて3年たちました。 Seasar3開発中止 2010-08-06 - ひがやすを blog ここでSeasar2.5を出す方向で動くということでしたが、実現しませんでした。 あのころSeasar2に関わっていた人も、ScalaがメインになったりNode.jsをさわったり、不本意ながらPHPをさわったり、さわってみるとPHPもそれほど悪くなかったり、やっぱりPHP気に食わなかったりと、いろいろな道を進んでいます。 DIコンテナ自体の機能も時代遅れ感がでてきており、関連プロダクトも
『フカシギの数え方』 おねえさんといっしょにみんなも25万年数えよう - きしだのHatena
組み合わせ爆発について、おねえさんが教えてくれて壮大で切ない結末を迎えるという動画が話題になっていました。おねえさんの決意に感動すること間違いなしです。 そこで、ぼくたちもおねえさんと一緒に25万年数えるためのプログラムを作ってみました。 LinkedList#popメソッドが、最後からとってくるんだと思ったら最初からとってきてたという勘違いではまったけど。 工夫なく計算してるので、6x6マスの時点で5分くらいかかります。 考え方としては、始点から上右下左と移動して、移動先でも上右下左と移動して、移動できなくなったら戻るという感じでやってます。 あと、最初に右に行くパターンと下に行くパターンは対称なので同じ回数ずつあるということから、最初は右に行ったことにして、最後に２倍してます。 まあでも、この程度の工夫では25万年が12.5万年になるくらいで、根本的な解決にはなりません。 計算量として
おねえさんを組み合わせ爆発から救う：無駄を省いてBDDを作る - きしだのHatena
おねえさんを組み合わせ爆発から救うために、経路を二分決定木として表しました。 http://d.hatena.ne.jp/nowokay/20121016#1350351212 前回の二分決定木を見ると、「1:2」「1:3」を通るとした場合、あとはどのような選択をしても単純な経路にならず「F」にたどりつきます。同様に、両方通らない場合も「F」になります。 このように、それ以降はどのような選択をしても結果がひとつに決まるという場合、それ以降のツリーを省略すると、決定木がすっきりします。 また、それ以降の分岐が等しくなる場合をまとめることもできます。そうすると、単純な二分決定木ではとても画面におさまりきらなかった2x2マスの経路も表示できるようになります。 このような図はツリーではなくなっているので、二分決定図、BDD(Binary Decision Diagram)といいます。この図では、「
おねえさんを組み合わせ爆発から救う：ZDDがおねえさんを救う - きしだのHatena
おねえさんを組み合わせ爆発から救うために、経路をBDDとして表しました。 http://d.hatena.ne.jp/nowokay/20121017#1350435805 ところで、「F」に至る経路で、ある辺を通るとした場合に即「F」となっているものが半分あります。 その節点を使うとしたときに、結果が偽になるのであれば、それは節点ごと不要だと言えます。そこで、そのような節点は省略してしまいます。 このような図を、ゼロ抑制BDD(Zero suppressed BDD)、略してZDDと呼びます。 「F」をすべて省略することもできます。ただし、BDDとは違って、どちらでも同じ結果になる場合も、それぞれの接続を表示する必要があります。 そうすると、2x2マスの経路でも、次のように表すことができます。かなり節点の数が減っていることがわかります。 「T」に至るパスの数が、経路の数です。 さまざまな
おねえさんを組み合わせ爆発から救う：完結編おねえさんは星になった - きしだのHatena
おねえさんを組み合わせ爆発から救うために、経路をZDDとして表したら、すっきりと経路情報が扱えました。 http://d.hatena.ne.jp/nowokay/20121018#1350528607 あとは、このZDDを効率よく構築できれば、おねえさんを救えそうです。このZDDの構築には、クヌース先生の開発したSimpathアルゴリズムを使うと非常に効率よく構築できます。 前回生成したZDDを見ると、同じノードにまとまっているものがいくつかあることがわかります。特に後半になるとどんどん同じパターンになるものがまとめられていきます。 つまり、この経路問題のZDDを構築するときには、いかに同じパターンになるものをまとめるかが鍵になるということです。 Simpathでは、辺の端だけに注目して、同じパターンになっていればそれ以降のノードを使いまわすという考え方で、ノードをまとめていきます。 つ
勉強することで何がいいのか実力者がいないことでデメリットはあるか - きしだのHatena
「この辺を勉強してどういう良いことがあったか教えて欲しい。」というコメントがついてた。 良いこととして、一番は、まあ勉強するのが楽しくなった、ということなのだけど、それは循環してるので置いておいて。 実務的に一番いいのは、プログラムを組むのが楽になったということ。 とくに、本質的な間違いが少なくなっていくので、後戻りが減るというのが楽。組んでみたけど動かない、途中でそれ以上組めなくなる、というのが少ない。まあ、ミスはあるので、そこの修正はするけど。 あと、できないことができないとわかりやすい。そのデータの持ち方でそのデータ数でその処理ではその精度の要求は満たせない、ということが原理的に判断しやすくなる。なので、むだな努力をしない。そして、どの条件を緩和すれば要求が満たせるかにも気づきやすい。 初見のライブラリや言語、ツールの理解が早くなる、とかも。 もちろん、前のエントリにも書いたように「
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
リレーショナルデータベースのインデックス実装とクエリー最適化 - きしだのHatena
データベースの勉強に、かわいいデータベースができました。 http://d.hatena.ne.jp/nowokay/20120817#1345197962 で、ここに、インデックスを実装してみました。今回はハッシュインデックスとツリーインデックスを実装してます。 こんな感じでインデックスが追加できます。 //インデックス追加 shohin.addIndex("shohin_id", IndexType.HASH); shohin.addIndex("price", IndexType.TREE); kubun.addIndex("kubun_id", IndexType.HASH); joinの高速化 で、実際にインデックスを張って処理が速くなるか試してみます。ベンチマークとしては手抜きですけど、参考にはなると思います。 shohinテーブルに10万件、kubunテーブルに1万件のデータ
FizzBuzzはこれまで不要だったとしてもこれからは必要 - きしだのHatena
どうも、FizzBuzzがどうこうという話題を目にするなと思ったら、こういうエントリがあったらしい。 職業プログラマがFizzBuzz書けない理由 - muo-notes 趣旨としては「FizzBuzz書けなくてもプログラマとしてメシくえてるんだから、FizzBuzz書けない人をバカにするのはおかしい」ということだと思う。 ここで、このように書いてある。 彼らがFizzBuzzを書けないのは、おそらく彼ら自身が社会的価値を生む上で必要ないからであって彼らが無能だからではないということ。 とはいえ、次の記事にもあるように、受託開発の終わりが叫ばれるような時代に、FizzBuzzを書けない人が、今後もこれまでと同様な社会的価値を生んで行けるようには思えない。 受託ソフト開発会社は、もう終わり！ | 日経 xTECH（クロステック） 市場環境としては、このように書いてある。 国内中心に事業を展開
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
