タグ

ブックマーク / nowokay.hatenablog.com (35)

  • ソフトウェアエンジニアの人数に関するフェルミ推定 - きしだのHatena

    以前から、日のプログラマってどのくらいいるんだろう?って思ってて、なんとなくの数字を思い浮かんでいるので、メモ的に書いておきます。 2〜3倍の差はあっても1桁は違わんだろうなーくらいの誤差感です。 まず、プログラマ全体の数。どうも、20万人〜100万人くらいな感じ。かき集めて200万人はいなさそう。 IT人材白書2017の「情報処理・通信に携わる人材」が100万人ちょい。 ある程度の機能を持ったプログラムをドキュメントやチュートリアルを見ながら自分のコードで書けるというのは、5万人〜10万人くらいではないかなと。 を買ったりして自分で勉強する人が3〜5万人。 小さなアプリケーションをひとりで作れるレベルだと1〜3万人。 自発的に勉強会に出る人は5000人〜1万人。東京に6000人、大阪700人、福岡300人くらいかなー。*1 高階型がわかるとか、高階関数がわかるとか、ある程度「プログラ

    ソフトウェアエンジニアの人数に関するフェルミ推定 - きしだのHatena
  • コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena

    おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId

    コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
  • ソニーデジタルペーパーを買った。これはいいものだー - きしだのHatena

    発表されたときから興味があって、その値段のせいで買うのを躊躇していたソニーデジタルペーパー、なんかレビューみてたら一瞬気を失っていて、その間に注文してしまっていたようです。 ひとこと。これはいいものだー。 ソニー デジタルペーパー DPT-S1 出版社/メーカー: ソニー発売日: 2013/12/03メディア: エレクトロニクスこの商品を含むブログ (1件) を見る 表示 大きいことはいいことだ。 パタヘネやWEB+DB PRESSが実物以上の大きさで表示できるのは、とてもいいです。これで、アルゴリズムデザインみたいなでかいを裁断する気になります。 ブラウザ機能もあって、文字の多いサイトを読むのにもいい感じ。 通常の大きさのだと見開きで表示できるサイズなのですが、見開き表示のモードがないのが当に残念。 4枚表示でも読めるのですけど、横向きで2枚表示が欲しい。 ただ、電子書籍を読んだり

    ソニーデジタルペーパーを買った。これはいいものだー - きしだのHatena
  • プログラムの難しさの階層 - きしだのHatena

    プログラムを理解するのは、まあ難しいです。 でも、その難しさには階層があります。 よく、変数は箱だとか箱じゃないとか議論になりますが、何人か初心者に教えた感じでは、変数自体でつまづくことはあまりないので、実際はそんな例えをしなくても「変数は変数だ」で充分だったりします。 デバッガでステップ実行しながら変数の内容を見ればいい。 で、条件分岐くらいは結構つまづくことはなくて、単純な演算と条件分岐だけが必要なプログラムであればまあそれなりに書けるようです。 ぼくも、一番最初に自分の意図で作ったプログラムは input "ワカレミチガアル。ドウスル? 1:ミギ 2:ヒダリ"; a if a = 1 then print "ガケニオチテシニマシタ" else print "ライオンニカマレテシニマシタ" みたいなものでした。こういった条件分岐をたくさん並べてアドベンチャーゲームっぽいものを作った人は

    プログラムの難しさの階層 - きしだのHatena
  • プログラマでメシを食う話 - きしだのHatena

    今日やってきた話 職業人講和20140403 from なおき きしだ あらすじ ・技術力の格差がでかくなってる ・会社は教育してくれない ・勉強するとちょっと自由になる ・勉強することはたくさんある ・10年とか20年とか勉強する必要がある ・モチベーションが必要 ・Twitterに情報もモチベーションもある ・Facebookにローカルな情報がある ・勉強会とかでモチベーションをたもつのがいい コミュニティ 福岡IT関連勉強会 福岡の水曜飲み会コミュニティ「水どう」の代表になりました - きしだのはてな ソフトウェア工学 論理学 作者: 野矢茂樹出版社/メーカー: 東京大学出版会発売日: 1994/02/18メディア: 単行購入: 24人 クリック: 175回この商品を含むブログ (80件) を見る統計学が最強の学問である 作者: 西内啓出版社/メーカー: ダイヤモンド社発売日:

    プログラマでメシを食う話 - きしだのHatena
  • プログラマ業界の二分化 - きしだのHatena

    プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく2つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その2つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で

    プログラマ業界の二分化 - きしだのHatena
  • プログラムの生産性をあげるためには - きしだのHatena

    前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛

    プログラムの生産性をあげるためには - きしだのHatena
  • プログラマが勉強すること - きしだのHatena

    今日もプログラマになる勉強する人のところで話をしてきました。 で、また適当にいろいろ書いてました。 http://www.slideshare.net/nowokay/20140228-31742219 今日は特に、この図の内容についてまとめておきます。 ※ このエントリは、主に今日の話を聞いた人を対象としています。前提や補足については省略しています。 まずはプログラミング言語を プログラマというのは、利用者に直接サービスを提供することはできません。コンピュータの上でプログラムを動かして、そのプログラムを使ってもらうことでサービスを提供します。 ※組み込みは前提から外しています。 そのプログラムも、コンピュータで動くものを直接記述することは現実的にできません。 なんらかのプログラミング言語で、プログラムを書くことになります。つまり、プログラマの仕事は直接的にはプログラミング言語をいじくる作

    プログラマが勉強すること - きしだのHatena
  • コミュニティに入るか入らないかでエンジニアとしての幸福度がかわる - きしだのHatena

    以前、「勉強会に参加しないと不幸になる話」というのをアップしました。 勉強会に参加しないと不幸になる話 - きしだのはてな このときは、勉強会x勉強会という枠だったので、「勉強会」と表現していますが、実際にはコミュニティに参加しないと不幸になる話でした。 あと、ここでの幸せ・不幸せというのは、エンジニアとして、という話で、エンジニアリング能力があがるとか、エンジニアリングの活動がやりやすいとか、エンジニアリングの活動が評価されるとか、エンジニアリングの話題を共有できる仲間が増えるとか、そういう観点です。 エンジニアとしての幸せ以外にも、人生にはさまざまな観点の幸せがある、ということは最初に補足しておきます。 会社が教育機能をもっていない エンジニアとしての幸せに大切なのは、エンジニアリング能力を上げていくことです。 ただ、2013年の産業経済省IT人材白書の概要に IT企業に対して、201

    コミュニティに入るか入らないかでエンジニアとしての幸福度がかわる - きしだのHatena
  • 英単語帳を買ったら思いのほか面白かった - きしだのHatena

    プログラム作業中に困ったときに検索してひっかかった英語技術文書を読む程度だと、辞書をひくことなく英語が読めるのだけど、技術解説になるとちょっとつらいし、ブログにのってる意見になると知らない単語が増え、ニュースになると知らない単語の頻度があがって、そして問題は、技術とは関係ない普通の文章になると知らない単語だらけ、っていう感じの単語力なので、これはどうにかしないとなーと思ってたのでした。 で、この2月のエントリで 「読解にある程度困らない語彙数というのは、8000語程度」 「とにかく、8000語程度は何も考えずに覚えてしまったほうがいい」 とあったので、時間ができたらやろうと思ってたのだけど、やっと時間ができる可能性がでてきたので、紹介されてたアルクのSVLというのを基準にした単語のを探して買ってみた。 時間のない人のための、気の英語学習法 - アスペ日記 Amazonで探すと、頻出1

    英単語帳を買ったら思いのほか面白かった - きしだのHatena
    tknzk
    tknzk 2013/05/17
  • プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな

    プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか?」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自

    プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
  • 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の問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか

    MVCは死んだ。MOVEするときがきた - きしだのHatena
  • ファーストサーバの手順の問題点 - きしだのHatena

    えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3:メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順1

    ファーストサーバの手順の問題点 - きしだのHatena
  • ネットワークに自信のない人は東大講義の情報工学概論Aを見よう - 2012-01-28 - きしだのはてな

    東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。 http://ocw.u-tokyo.ac.jp/ その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。 その中で、情報工学概論Aというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。 こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。 http://ocw.u-tokyo.ac.jp/lecture?id=11314&r=609526321 ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくとい

    ネットワークに自信のない人は東大講義の情報工学概論Aを見よう - 2012-01-28 - きしだのはてな
  • 作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな

    さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか?テストか?UIデザインか?となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと

    作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな
  • アルゴリズムの勉強のしかた - きしだのHatena

    この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういうで勉強すればいいか、ぼくの知ってるからまとめてみました。

    アルゴリズムの勉強のしかた - きしだのHatena
  • プログラマになるための勉強をしている人の前で話をしてきた - きしだのHatena

    イデアルITスクールというところで、1時間ほど話をしてきました。 プログラマとしてやっていくために大事なことというテーマ。 資料を作らずに、というか構想すら練らずにやってしまったので、ここで整理とまとめと補足を。実際にこれをしゃべったというのではなくて、だいたいこんなことをしゃべろうとしてたという内容をかなり盛って書いてます。 当然ですが、プログラマの仕事はプログラムを書くことです*1。 プログラマとしてやっていくためには、どこで動くプログラムを書くか、なにをするプログラムを書くかということを意識することが大事です。 ということで、まずはプログラムが動くところがどう変わったかという話。 1970年代ころは、デバイスを動かすためのプログラムが多かったのではないかと。 あと、ここには書いてないけど、業務アプリはほぼメインフレームで動いてたと思います。 それが、1980年代くらいからパソコンが出

    プログラマになるための勉強をしている人の前で話をしてきた - きしだのHatena
  • プログラマならいつかは読んでおきたい(と言っておけばかっこいい)本10冊 - 2010-11-26 - きしだのはてな

    昨日の技術力をあげたいプログラマが読んでおかないと話にならない10冊は自体にはあまり意味がなくでその技術分野が大事で、あとエントリーレベルのものが多かったので、今日は読み甲斐のあるを。 棚に飾っておくとかっこいいです。あと、屋でまとめて買って持って帰れるなら、値段的にも重さ的にも、尊敬します。 ぼくが持ってないや持っててもほとんど読んでないがかなり含まれてます。「この人こんなも読んでるんだー」などと無用に尊敬したらダメですよ。むしろ、そのように誤解させて尊敬させるためのです。 アルゴリズムデザイン 作者:Jon Kleinberg,Eva Tardos共立出版Amazon読んで面白いし、アルゴリズムカタログじゃなくて設計方法の解説が多いので、とてもいいです。途中までは読んでるので続きを読まねば。 あとアルゴリズムのとしてはアルゴリズムイントロダクションが定番ですが、

    プログラマならいつかは読んでおきたい(と言っておけばかっこいい)本10冊 - 2010-11-26 - きしだのはてな
  • 2010-11-25 - きしだのはてな - 技術力をあげたいプログラマが読んでおかないと話にならない本10冊

    ここにあげたじゃなくてもいいので、同じ分野でなにか読むとか、に書いてあるほど詳しくなくてもそれなりに知識をもっておくべき。 アルゴリズムクイックリファレンス 作者: George T. Heineman,Gary Pollice,Stanley Selkow,黒川利明,黒川洋出版社/メーカー: オライリージャパン発売日: 2010/04/26メディア: 単行(ソフトカバー)購入: 11人 クリック: 656回この商品を含むブログ (72件) を見る まずはアルゴリズム。クイックって書いてあるけどぜんぜんクイックじゃないw。各言語で書かれた入門書を読んでもいいと思う。 実際のプログラムにアルゴリズムの知識を活かすということを知りたいならプログラミングコンテストチャレンジブックがおすすめ。 プログラミングの基礎 ((Computer Science Library)) 作者: 浅井健一

    2010-11-25 - きしだのはてな - 技術力をあげたいプログラマが読んでおかないと話にならない本10冊
    tknzk
    tknzk 2010/11/25
  • そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか? - きしだのはてな

    Java入門ブックガイド(入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか? 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac

    そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか? - きしだのはてな