「締め切りは絶対に守るもの」と考えると世界が変わる
2011年にインプレスジャパンから「エンジニアとしての生き方」という本を出版して以来、書籍よりは「メルマガ（週刊 Life is Beautiful）」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」の本を出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社） 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術の本です。 「いつも締め切りに追われている」「締め切り間際にならないと本気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたい本です。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「
タバコやAKB商法の弊害を表す被搾取係数
「厚生労働省調査による、貧乏から抜け出す７つの方法」という記事に喫煙率と年収の相関関係のグラフが紹介されている。 この記事にある「タバコを吸ったら貧乏になるのか、貧乏だからタバコを吸うのか」という議論はさておき、この手の「常識のない若者や教育水準の低い人達から搾取する」というビジネスは他にもたくさんある。 代表的なものとしては、 タバコ パチンコ・スロットマシン 宝くじ 競馬・競輪・競艇 マルチ商法、ねずみ講 ソシアルゲームのアイテム課金 抱き合わせ商法（AKB48、ビックリマンチョコ） などがある。共通するのが中毒性もしくは謝幸性で、一回１００円、２００円という一見わずかなお金を少しづつ、かつ、継続的にかすめ取るのが特徴だ。その結果、上の記事にも書かれている様に、年収２００万円の人を、自分の健康に害を及ぼすタバコに、年に１６万円も費やすという非理性的な行動に走らせるのだ。 人々の生活レベ
ベジェ曲線の数と「達筆度」と
neu.Note+ 向けに曲線のスムージングのアルゴリズムを開発中。特に文字の場合、オリジナルの字形を崩さずにどこまで自動できれいなスムージングをかけられるかが勝負になる。 左の図で、一番左のものがオリジナル。iPad上に指で書いたものだが、手書き特有の「よれ」が見れる。それぞれのストロークは３０〜４０個のベジェ曲線から構成されている。 これに開発中のアルゴリズムを適用したものが真ん中のもの。隣接するベジェ曲線を組み合わせることにより、ベジェ曲線の数を減らしたもの。あまり減らしすぎると字形が崩れるので、そのバランスが難しい。結果としては、それぞれのストロークに含まれるベジェ曲線は６〜１３個に減っている。「よれ」がなくなり、かなりきれいになった。 これをさらに手動で最適化したものが一番右のもの。各ストロークに含まれるベジェ曲線は３〜９だ。ここまで来ると、「達筆」と呼べる。 この場合、アプリを
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
HTML5入門：アニメーションの実装方法３種
HTML5・CSS3のような新しい技術の問題点は、HTML4やらFlashなどの枯れた技術と違ってノウハウ・ライブラリ・ツールとかがまだ十分にそろっていない事。普及のタイミングもまだはっきりとしていないこの段階で手を出せない・出しにくいと感じている人が多いのも良く理解できる。 私から見れば、逆に「こんな楽しい状況は滅多にない」わけで、商売になるかならないかは二の次にしていろいろと試したくなる。 今日作ったのは、HTML5+CSS3上で可能になる（ただし現在ではWebkit独自の拡張を含む）３つのアニメーション・テクニックの比較（左に貼付けたものがそれ、Safari/Chromiumだとすべて動く。Firefox/OperaだとDOMとCanvasのみ（ただし別ウィンドウで開かないとCanvasが動かないークロス・ドメインセキュリティのバグか？））。 詳しくはソース（参照）を見ていただければ
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
