今日の風景 転職しようとする人のモノマネです 本文 シリーズもののように、連番は付けているが、これが続くかどうかはわからないが、感触からすれば続くだろうなと思ったので連番にしようと思った。 一般的に、最近の企業ならば、面接者にコードを書かせるかと思われる。とある企業では、事前に聞いていたテストだったので、ここで種あかしするのは野暮であり、と同時に一部には「とある企業」の「とある」が分かってしまうので、曖昧にぼかすのだけれども、基本的に自分はREPLに甘やかされていて、それで通らないコードを提出してしまった。 なので、今からでもいいから「そのソース書きなおさせろ」と殴りこみをかけたいものだが、良識を分きまえているつもりなので、それは知なかったが、動かないコードが、あとから動かないと気がついて、面接会場から出るというのは、本当に恥かしい経験で、穴があったら入りたいどころか、穴二つ分作りたい気分

今日の十六茶 試してガッテン方式で入れている。 はじめに オライリー社から2013年に発売された『オープン・デザイン』という本は、率直に言ってしまえば、如何にもデザイナー向けの思弁的な議論のアンソロジーとなっている。それらは、直接的には技術的な洞察を与えるものではないだろうし、また同様に、それが直接的に業務に使えるものかといったらそうでもない。 そうではないのにも関わらず、この本は、プログラマにとって重要な本であることは間違いないと、僕は確信している。逆説的なことではあるが、この本が技術書でないからこそ、あまりにも無視され続けた本であると思うのだが、だからこそ、今読むべき本であると思う。 プログラマはデザインが下手であるという現実を直視する もちろん、デザインという言葉は多義的な言葉であることは間違いない。まず指摘できることは、日本語の場合、デザインという言葉は「設計」という言葉ではなく、

はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き

この記事について この記事はHeartRails Advent Calendar3日目の筈でした。 趣旨 HeartRailsに入社した。そこで、リモートを通じて受託開発などを行っている。ちょうど1ヶ月ほど経ったので、リモートワークに関しての所感をメモしておこうというのが今回の記事の趣旨。 なぜリモートワークをやろうと考えたの? 割と働き方で体調を崩すことが多くあったので、「これは自分の働き方を見直さないとマズイな」と思い、あまり一般的な働き方に囚われず、自分にあった働き方を見つけようと思ったのがきっかけ。そうなると、現状として二つの働き方があって、「リモートワーク」か、あるいは「短時間勤務」になるかなと考えたので、そのあたりを中心に見直した結果、HeartRailsの働き方がマッチしているかなと思ったので、そういう経路で働き始めたという経路。 リモートワークを中心にすることに関して不安は

はじめに そういえば、最近はUbuntuからWindows 8を使いなおしている。なんでWindows 8をあえて使っているのかというと、それはいろいろな人が「使いにくい」と言っていたからだ。だから、その使いにくさを体験したいために、あえて使ってみているんだけど、その評判と違って普通に使いやすくなっていて驚いた。 少なくとも以前みたいな「スタートメニュー地獄（何かのアプリをインストールするたびにフォルダが増えていくアレ）」はなく、基本的にスタートのタイル画面からアプリにアクセスすることを考えると悪くない。そしてそのタイル画面にアプリを登録するのも簡単だ。また、それらのライブアプリを並べることが出来るので、デスクトップ画面で何かを作業しながら、スケジュールを入力するのも楽だ。それらの基本的にアプリにしても検索を中心にアクセスするという意味ではUbuntuのUnityで慣れているので、悪くはな

はじめに 前回、非プログラマに対してプログラマに理解してほしいことというのを書いたら、なんかあとから伸びてきて、みんな思っていたことだったんだなーと思う反面、逆に一方通行に、プログラマだけが理解しろ！というのではなく、自分がプログラマとして働く上において、ちょっとだけ意識していることをあげておいたら、お互いにWin-Winかもね、と思う。そもそも、何かを要求するのに何も与えないというのも都合のいい話だろう。 もちろん、プログラマというのは一括りにできないし、前回の如く、当たり前にやっていることかもしれない。また「気を付けている」ということなので、気を付けている程度で本当はできていないかもしれない。 ただ、自分としては、非プログラマに対してこういうコミュニケーションが出来たら理想だなと思っている。そして、これはスタートアップの話である。すべての組織に適応できればベターだけど、そう簡単ではない

はじめに 自分の基本はプログラマとして、サーバーサイドのサービスをゴリゴリ書くのが仕事だ。しかし、仕事をするとなると、いろいろな人が絡んでくる。もちろんマーケティング担当や戦略担当の人もいる。そして、僕はそういう人たちが実際にやっていることはわからないけれど、それはたぶんそういう人たちが「プログラマってどういう仕事なのか？」ということがわからないのは一緒なのだろうと思う。もちろん、お互いに相手の仕事を理解して、それに合わせてどういう風なことを共有して作ってもらうか、というのを話し合う機会は重要だ。 たぶん、自分たちがどのように仕事をしていて、どのように情報を共有してもらえれば、仕事がスムーズにいくのか、ということを説明しないことには、たぶん「プログラマが理解されない」ということを嘆いても仕方ないと思う。なので、まず自分が「プログラマとしての自分」が考えていることを共有する必要があるなあとい

はじめに 現在、自分はスタートアップをお手伝いしている。そして、現在はどんどんユーザーをスケールさせようということで、士気が上がっている。エンジニアも入れたい。そのような前向きな雰囲気になっていて、とても心地良いのだけれど、ただ、その上で、今クリティカルになっているのは、伝達経路であったり、あるいは振っているタスクが適切に配られずにいびつになっている状態があるよねということを、戦略の人と話したりする。 周りを見渡してみると、実はこの問題は自分たちだけの問題ではなく、ベンチャーによくある問題であることに気がついた。例えば急成長しているベンチャーにおいて、評価制度が適切ではなかったり、あるいは他に適性がある人間がちゃんと配分されていなかったりすることがある。そのことによって、優秀なエンジニアが流出したり、あるいはプロジェクトの失敗率が上がったりする。 これらの問題を、個人の問題として片付けるこ

はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ

これはつらぽよ Advent カレンダー13日目の筈でした。 正直なことをいうと、僕の素行は余りにも良くはなかった。少なくとも、職歴は大きな穴が開いているところが幾つかあるし、やっと掴んだ職歴についても、一年続くのがやっとで、なかなか長続きすることはなかった。 経歴的に言うと、元々僕は製本工場でアルバイトを一年間ほど続けていた。何の本を製本していたのかと言えば、アルバイト雑誌とか、あるいは風俗案内用の小冊子とか、そのあたりを製本していた。もしかしたら、貴方がアルバイトを探そうと思って手に取った、無料で配布されている冊子だ。恐らくそういう類の本は、背表紙がホッチキスで止められていると思うけれども、あのホッチキスが止められる前の、裁断された紙を重ねて機械に放りこむということをやっていた。この作業は若干面白くて、紙を揃えて入れなければならないのは当然なのだが、この紙を一枚ずつ取り出すために、紙の

エンジニア、とくにWebエンジニアであったり、スタートアップに関わるようなエンジニアであると特にそうだが、ある人物の判断基準を「コードで書けるかどうか」で考えてしまう傾向にある。もちろん、なんらかの情報技術で世界に躍進するという野望を持っている場合、コードを書けて悪いことはないし、そもそもプログラミングとは如何なる行為なのか、ということを肌で感じておくことは、経験としてとてもよい。しかし、それは自分のようなポンコツエンジニアにとってはオプショナルなものなんじゃないか、と最近感じつつある。 それは、幾つかの経験を経て見たときに、「元エンジニア」の人であったり、あるいはエンジニアをやりつつ、会社をやっている人達と話をしてきて、あんまりソリが合わないことを少しずつ感じているからだ。逆に、今お手伝いしている人とは、現時点では、自分としては不満無く作業が出来ている（もちろん、相手はどう考えているかは

まず自分が反省したことから始める。 仕事で、余りにも茶化されたり、細かいことを言っていったりしていたので、少々怒ってしまって、それで少し乱暴な行動に出てしまったことがあった。そのことを持って「あいつはダメだ」みたいなことを知人に愚痴ったりしていると、「いや、お前の言うことはわかるけど、お前がやるべきミッションというのは、そういうダメな人にとっても優しい環境を作ることなんじゃないのか」と言われた。それは本気でその通りだなあと思って、自分の浅はかさを恥じると共に、そういう風に忠告してくれる知人がいることにとても感謝したりしていた。 自分も、変に向上心つーかプライドのあるタイプなので、どんどん技術を磨きたいと思う一方で、そういう「向上心を持つ」ことを正義と考えると、向上心を持たない人間に対して、段々と苛々し始めるというのはあると思う。しかし、そういう風に苛々しはじめて、あーだこーだ言い始めるのは

ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。 元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュ

暫くスタートアップのお手伝いをしている。最近やったのだと、下のような感じ。 jeffh/sniffer · GitHubを使ってSphinxでDocstringをぶん投げる DjangoとJenkinsを連帯させ、ローカルでテストを廻す blockdiagを使ったモデル関係の整理 Muninを導入して、落ちる原因になってるサーバーリソースの監視 Hipchatを使っているので、GitHubやPivotal Trackerを連携させる Hipchatの遊び心としてHubotの導入 django開発の基礎としてBeProud社の『Pythonプロフェッショナルプログラミング』を薦める そんな感じ。上のことがどれだけ効いているかはわからないけれど、自分が楽しんでやれる環境に整備し、あとは他の人にも「だいぶ楽になったなー」という気持ちになれれば、こっちとしては万々歳。もしかしたら半分くらいは自己満

最近、とあるスタートアップのお手伝いを細々と続けている。自分は全く分からないのだけれども、ベンチャーの人材獲得が厳しいらしい、みたいな記事を読んでいた。そこであげられていた言語は、PHPとRubyだったが、自分はPythonを使っていて、結構仕事を探すのに苦労したりしていた。当然のことながら、自分のスキルセットが余りにもWeb向きではないし、さすがにポテンシャル云々とも言ってられない歳ではあるので、仕方ないかなと思いながら、今のベンチャーで、いろんな雑用的な仕事を行ったりしている。 で、そこのベンチャーで「Pythonの仕事なかなかないんですよねー」みたいな話をしたら、「あれ、Pythonの仕事、至る所にあるよ」と言われて、あれ、これって何かミスマッチが起きているのかなと思ったりもした。お金は寂しがり屋であるから、お金のある人のところにいくんやで、という話があったか、仕事も「元々仕事が多い

最近になって、オブジェクト指向がよくわからないという御仁とご一緒することになった。別段、それ自体が悪いことではない。確かに、その人の書いた、以前のコードというのはめちゃくちゃであった。当然のことながらif文は何十にも繰り返されているし、その中でネストが3つにも4つにも増えていくという恐るべきコードだ。そして、どうやら僕の前に、教えてくれた人がいるらしく、その人に「オブジェクト指向というのを教えてもらったから、もう少し上手く書けるようにになっている筈だ」ということを言っていた。 僕はそのことに、特段ケチをつけたいとは思わない。誰だって無知から始まる。僕もオブジェクト指向にとんちんかんなことを言って恥をかくことがある（もしかしたらこれからもね！）。無知が恥なのではなく、学ばない姿勢が恥なわけだから、僕はそういうのはいいなあ、と素直に思える。しかし、どうも僕は引っ掛かっていることがある。それをメ

とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基本的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシを食う数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ

下の本を読んでいた。 プログラミングの基礎 (Computer Science Library) 作者: 浅井健一出版社/メーカー: サイエンス社発売日: 2007/03メディア: 単行本購入: 17人 クリック: 409回この商品を含むブログ (105件) を見る この本はどういう本かといえば、OCamlという、関数型言語と呼ばれる中でも、あまり有名ではないほうの言語（というと失礼だけど）を使ってプログラミングの基礎を学ぶという本。そういうと、OCaml好きな人には怒られるかもしれないけれども。 良いにしろ、悪いにしろ、関数型言語の特徴は、個々のパーツを作って云々という部分が非常にクリアーになっているところであるな、とは思う。というのも、下手に「代入」を使わないことによって、むしろデータ操作の流れがクリアになるし、余りに大きいパーツにしてしまうと、そもそもその流れ自体がよくわからなくなる

はじめに こんにちは。以前まで蟲！虫！蟲！ - #!/usr/bin/bugrammerという、はてなグループで技術的な記事を書いていました。しかし、さすがに、はてなブログの優遇っぷりと、はてなグループの場末感で、もうそろそろ空気を入れ替えなければいけないんではないかと悩んだ結果として、はてなブログに移転するということになりました。 で、たぶん既存のデザインテーマとか使えばいいんでしょうけど、CSSくらいは少しかじっておいたほうがいいよなー、とは常に思っていて、前回の日記もCSSをかなりいじりました。なので、今回も自力でデザインしたいなーという思ったわけです。 しかし、この「デザイン」という奴が、プログラマーにとっては曲者で、割と近い処で仕事をしているのにも関わらず、実際に「デザイン」ってなんだよ、っていう話になると全くわからない。 そういうときに、「だったらじゃあ自分でデザインのフローを