日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ 先日、ソフトウエアエンジニアの中で、この話題がバズってましたね。有名なコミッタさんを雇おうとしたら、会社の偉い人が「プログラマーに年800万円なんてのは馬鹿げてる! プログラマーに出せるのは年400万円までだろう!」と言い放ったという話です。 >> 著名なOSSコミッタを年収400万円で雇おうとした

プログラマの面接をするときには実際にコーディングをしてもらうべきという話は良く聞くが、もうちょっと細かくどういうお題を出したら良いかとか、どういう風に評価したら良いかとかの話はあんまり聞かない気がする。せっかくなので、ユビレジでの面接で私がコーディングについて確認するときのパターンを、いくつか紹介してみようと思う。 実際にコードを書いてもらうパターン 候補者がどのくらいプログラミングできそうかの予備情報がない場合に、簡単なアルゴリズムを書いてもらうことが多い。例としては、 Linked Listを書いてください Stackを書いてください など。ここで、おもむろに int main(int argc, char* argv[]) { などと書き始める人は、あまり良い印象をもたれない。 class Stack などと書き始める人は上よりは期待できる。 このとき、わざと出題で詳細をあまり明らか

以下の文章は、Peter Norvig による Teach Yourself Programming in Ten Years の日本語訳である。 本翻訳文書については、以下の方々にご教示を頂きました。ありがとうございました。 Shiro Kawai さん：誤訳の訂正 三好博之さん：誤訳の訂正 竹中明夫さん：2001年7月改版分の訳、誤訳の訂正（共訳者にクレジット） Toshihiko Ono さん：誤訳の訂正 アクビさん：訳注３に関する情報 どうしてみんなそんなに急ぐの？ どの本屋に足を運んでも、『7日で学ぶ Java』といったハウツー本を見かけるし、そのそばには Visual Basic や Windows やインターネットなどについて、同じように数日や数時間で学べると売りこむ本が無限のバリエーションで並んでいる。Amazon.com で以下の条件で検索してみたところ、 pubdate

こんにちは！今年の春からWeb系企業でHTML/CSSデザイナーとして働きだしたキラキラ女子（を目指してる）のあんちべ（23）です！よろしくお願いします！私は普段自社のWebサービスのCSSなどを書いている*1のですが、最近データマイニングに興味を持ち始め、データを分析して、自社サービスの売り上げ改善に貢献したいなーと思うようになりました！でも。。。私は文系出身で統計学とか全然わからない*2し、プログラミングも得意じゃない*3し、高価な統計解析ソフトを買うのも辛いです。。。無い無い尽くしですね＞＜；！そんな私に救いの手が！インストール作業不要で、便利な統計処理機能が色々あって、しかも無料という素晴らしいソフト*4を発見しました！その名も"Incanter"です！なんでも、 Lispっていう古くから使われてきた実績のあるプログラミング言語で動いてて、Lispの文法でどんな処理をすればよいかを

10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

僕は結城浩さんのことが好きなんだなぁ。彼の書いた「文章を書く心がけ」は自分が執筆をするときにも何度もお世話になった。彼の日記などに時々かいま見える「読者によりよいものを届けよう」という真摯な態度には好感を感じる。以前の僕は宗教と名の付くものが全て嫌いだったのだが、敬虔なクリスチャンである彼の日記を読んでいるうちに、その嫌悪感が軽減した。結局のところ、どんな集団にもいい人もいればわるい人もいるということなんだ。 では、わるい人に対してどう対処するのがよいのか。1601年生まれの哲学者バルタザール・グラシアンはこう言っている。 人の中傷は無視せよ。黙殺で答えることが賢明だ。身の潔白を明かそうとしてペンの力に訴えてはいけない。書かれたものはいつまでも残るから敵を懲らしめるどころかその名を留める手助けをしている。忘却に勝る復讐はない。 なるほどね。400年も経つけども、人間の社会はあんまり変わって

Shiro Kawai 11/20/2000初出、3/29/2002更新 Cに慣れたプログラマがSchemeのコードを見て面食らうことのひとつは、 無名の関数やローカル関数の多用だろう。 特に実行効率に敏感なプログラマにとっては「関数呼出しは高価」 という感覚が染み着いているため、 至るところに散りばめられたlambdaに眉をひそめてしまうようだ。 しかしSchemeにおいては、 コード上に関数が書いてあるからといって 実行時にスタックフレームの生成やレジスタの退避などのオーバヘッドが起こるとは限らない。 例えば関数の最後に別の関数を呼び出す末尾呼び出し(tail call) はただのjumpインストラクションに置き換え可能だ。 ここでは、Cプログラマを対象に、 lambdaで生成される関数群が実際にどのように実行され得るのかを書いてみたい。 (なお、Schemeの規格ではlambdaフォ

技術的負債についてはじめて知ったのは、マーチン・ファウラーの「技術的負債」というエントリーでした。 技術的負債 システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンなどスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 (中略） このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界で市場機会の優位性を得るために負債

昨日のDroidKaigiの@operandoOSさんのセッション Android学ぶを君へ。生き抜くためのナレッジ共有の中で『ひたすらクソコードを書く』という話がありました。 もちろんこの話はほんの一部でしかないんですが、とても印象に残りました。 誰と話したか忘れてしまったんですが、懇親会で 「クソコードでも公開した方がいいんじゃないか」みたいな話が出て、なるほどなぁと思ったのでちょっと思考を整理しておきます。 書けば何がクソコードかわかってくる 何も書かないよりクソコードでもいいからまず書いてみる方がいいと思います。 そもそもクソコードっていうのはよいコードの基準があってこその価値観なんですよね。書かなくても何がよくて何がクソかわかるよって人もいると思うんですけど、自分はやっぱり頭で理解するより書いて理解する方が腹落ちしやすいです。 例えば、GoFのデザインパターンはよくある問題を

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

以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ

自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ

前のブログ開設から合わせて9年？ですかね。結構長くやってますな。 更新頻度は少なくなってきてますが、ぼちぼち続けます。読んで下さっている方には、これからも、よしなに。 今年の振り返りとして、読んで、良かったな、と思った本の紹介。 ▼ プログラムはこうして作られるプログラマの頭の中をのぞいてみよう 作者: 平山尚(株式会社セガ)出版社/メーカー: 秀和システム発売日: 2013/09/25メディア: 単行本この商品を含むブログ (5件) を見るプログラミング関連の本で、全くの初学者向けのものとしては、私が知っている中で最良。用語より概念と構造を先に教える、という私の標語？に合致しています。これこれこういう用語がある。その用語はこういう意味・定義である、というのは、その語を知らない人にとっては、用語と概念を一緒に憶える必要があって、それは負担。そうでは無くて、これこれこういう論理構造や概念があ

新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら

相変わらずExcel VBAを使いまくってる日々なので腹にためてることをちょっと書き込もうと思った。なんか前にも書いたかもしんない。知らない。 以下はバッドノウハウの類も含むカオス内容。 if文内に書いた条件は全て評価されることに注意する。CやJavaのようなショートサーキットタイプではない。 それでもif文の評価コストに慎重にならないこと。 他言語で&&で置き換えられる内容をif文のネストで表現している奴を見たらVB出身を疑うことができる。 変数の通用範囲がプロシージャレベルであることに注意すること。ブロックで通用範囲が消えたりしない。 Dim hoge as New ClassNameとした場合、hogeが始めて使われる場所で変数にNewしてSetされる。その後プロシージャ内でこの宣言が実行されたとしてもNewされることはない。プロシージャレベルでのオブジェクトの使いまわしが怖いならA

はじめに @__boronium による 「じゃあC++はどうなの？」 という疑問にお答えするコーナー。元のPython版はhttp://d.hatena.ne.jp/ponkotuy/20111216/1324021461 でどうぞ。 ちなみにg++4.6.1 -O2 -std=c++0xでコンパイル。 はじめる前に補足 微妙に間違った参考のされ方してたので補足しておくと、こいつはどういう訳か「データの入力が圧倒的に多いのにその殆どは参照すらされずに捨てられる場合」に一番早いコンテナ、という極めて稀なパターンに特化した測定なので、そゆ場合にしかアテになりません。 Vector #include <vector> int main() { const int size = 10000000; std::vector<int> v = {1,2,3}; for(int i=0; i<size