Hugo のサイトへ引越しをした
Hugo のサイトへ引越しをした ということで、長らく (のわりには記事を書いてないけど) お世話になった Tumblr へさよならをして、Hugo+Netlify で記事を書いていこうと思います。
書いたものの参照が消えるのはよくないかと思って過去のサイトも基本残しているのだけど、あまりそうこだわらずに新しいものをつくったら消していってもいいのかなあ。
今後はこちらを更新します。 https://site.hacklife.net/
Hugo のサイトへ引越しをした ということで、長らく (のわりには記事を書いてないけど) お世話になった Tumblr へさよならをして、Hugo+Netlify で記事を書いていこうと思います。
書いたものの参照が消えるのはよくないかと思って過去のサイトも基本残しているのだけど、あまりそうこだわらずに新しいものをつくったら消していってもいいのかなあ。
今後はこちらを更新します。 https://site.hacklife.net/
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。
まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。
じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれはそのままその1行の修正をしてはいけないのではないかと開放閉鎖原則や局所化なんて言葉がまっとうに学習している開発者なら頭をよぎるわけです。
すると、ここで1行の修正だったものがもう1万行を対象にした再設計の開発と化けます。1万行はなにをやっているのかを洗い出し、さてこれは本来どういう役割のものがこの1万行のごった煮に混ざっているのかを考え直し、あれ、これはともすると既存の業務に影響出るんじゃねーのと気付いて今その仕事をやっている人に話を聞きに行き、これはそもそもなにがやりたい仕事なんですか？と業務分析から始めることになります。オペレーションを変えることになると、そのための説明や調整をして回ったり、オペレーションの変更コストを業務担当の人が払ってくれない場合は、その影響先への説明や調整も自分でして回ります (会社のために必要なら調整するよって引き取ってくれる土壌があるとここが開発者の負担から離れて、結果改善速度が早くなります)。
最後はそうやって理解できた全体像から、今採るべき手段はなにが総合的に考えて最適なのかをその都度意思決定するのですが、その意思決定にあたって必要なこととしてこれだけ考えています。
作業者として1行言われるがままに直すこともできるかできないかで言えば当然できます。ただ、その結果、そうやって思考停止で目の前の要望を持っている人の希望を叶え続けると、最後に誰のためにもならないシステムができあがり、誰の手にも負えなくなります。そのことを知っていて、真剣に開発者という仕事に向かいあっている人ほど先ほどのようなロジックで今自分が採るべき手段はなにかをよく考えます。
作業を請負うのでなく事業会社の社員として開発者として働くというのは、要望を持ってくる人へ応えるのが仕事ではなく、それをきっかけに会社にとって一番よい形を技術という自分の強みを活かして考えるのが仕事です。アウトソースで開発をするのでなく、自社に開発者がいて働いているというのはそういうことだと思ってます。『たまたま要望を言ってくる人がコンピューターとか苦手だから代わりにやりたいことをやってあげる仕事』ではけしてないのです。あくまで会社だったり事業だったり、その先のお客さんのために必要なことをするために働いてます。そこへの尊重が基礎にあり説明コストが低く、開発者が本来一番やるべき仕事 (コードを書いて事業を前に進める) へ集中できるというのが『開発文化がある』という状態だろうなというのを最近考えます。
こんな面倒なやつとして振る舞わなくても「おっけ、おっけ、すぐやっとくよー」と言ってばんばん直してばんばんリリースできるシステム開発をやっていける環境で働きたいものですね！
私からは以上です。
irb より iRuby/iRails がいいよと言われたので、試してみた。
Mac OSX へのインストールログ。途中で怒られてあれこれ足したから、その人の環境によってけっこう違いそう。
brew install python3
brew linkapps python3
pip3 install ipython pyzmq tornado Jinja2 jsonschema
pip3 install "ipython[notebook]"
brew install autoconf automake zeromq
gem install iruby
gem install pry pry-doc awsome_print gnuplot rubyvis nyaplot
そういえば、以前にレオさんの記事「Railsエンジニアに役立つJupyter NotebookとiRuby」を見かけて読んでいた気はする。
豪華な食事といって量が増えるのはおかしい。品質が高まってほしい。と思ったけど、ソフトウェアも同様で、機能を増やすよりは、すでにある機能の使い勝手を高める方が完成度上がると思った。
(via lovecake)
情報見つからずわりとはまったのでメモ。
require 'net/imap'
imap = Net::IMAP.new('imap.gmail.com', 993, true)
imap.login 'username', 'password'
imap.select 'INBOX'
uids = imap.uid_search ['TO', 'sunaot', 'SUBJECT', 'こんにちは'.force_encoding('ASCII-8BIT')], 'utf-8'
日本語で検索したいときは、uid_search に charset を指定できるんだけど、そのときは force_encoding してやらないと正規表現のマッチのところで Encoding::CompatibilityError が起きてエラーになるのでした。
なお、mail gem の imap retriever による find は charset をオプションとして受け付けないので、yalab さんのこの pull request の取り込みが待たれます。活動が止まってるわけではなさそうだから、テストを追加すると取り込まれたりするのかなあ。
個人的な経験を書きますが、ぼくはエンジニア生活 10 数年で 5 社を転職して渡り歩いています。そして、その 5 社すべてでなにかしらの勉強会なり研修なりといったものをやってきました。
そして、それが仕事であろうとなんだろうと自分がエンジニアに研修なり説明会なりをするときは、自分がもらったものを返すつもりでやってきました。そのときそのときは当然所属している会社があるわけですが、その会社のため (だけ) にやったことは一度もありません。プロジェクトによって参加している人の立場も発注元だったり受託開発の常駐エンジニアだったり様々だったので、あくまで一人のエンジニア同士として自分が伝えられることをなるべく伝わるような言い方で伝えるということをやってきました。その中では所属会社へ都合の悪い話も出たりしますが、これは所属会社へのコミットメントとは別の話です (PHP 使ってる会社で PHP の悪い点を説明するとか)。
そして、これらの準備は多くの場合、自分の時間を使ってやってきました。これが良いことだとは思いません。ただたんにそうしないと時間がとれない程度に別の業務も抱えていたというだけの話です。
ではなぜそんなことをしていたか。それが書きたいことです。
実際、gist にあれこれそういうテキストを公開していますが、あれらも大半は業務時間なんて使わずに自宅で朝まであーでもない、こーでもないと書いたものです。たいして得にもならないことをなぜするのかと言ったら、それは自分が肩に乗せてもらってる先人への感謝の気持ちがあるからです。いまやそれがいきすぎて、「それが自然な行為で、そういうものだ」と思ってるからです。
今のシステム開発は一人で一からすべてを体験して学んで理解しようとするにはあまりに複雑すぎます。「学習の高速道路」なんて言葉がありましたが、これに乗るのはアドバンテージではなく最低条件のように見えます。
この高速道路はただ乗りもできますが、ただ乗りしてたどり着けるところには限界があります。この限界は「大渋滞」という言葉で 2004 年にも言及されていました。
最も効率のよい勉強の仕方、しかし同質の勉強の仕方で、皆が、高速道路をひた走ってくる。結果として、その一群は、確かに一つ前の世代の並のプロは追い抜いてしまう勢いなのだが、そうやって皆で到達したところで直面する大渋滞を抜け出すには、どうも全く別の要素が必要なようである
これは将棋の羽生さんの言葉ですが、エンジニアにとってこの「全く別の要素」のひとつはまず間違いなく「アウトプットすること」だと思います。
アウトプットは give & take の文脈で語られることもあります。
自分がアウトプットをすると、フィードバックをもらえます。これは通常自分が書いたテーマに関するものになるので、自分の関心ごとだけに関する情報を集められることになります。
つっこみを入れてくれる人は識者であるケースも多いので、想像もしなかったような指摘をもらえることもあります。これは自分の枠内で進みがちな学習を大きくジャンプさせてくれるきっかけになります。
これらはアウトプットの利点として正しいです。ただ、一つの側面だけを語っているように感じ、やや自分の過ごしてきた世界と違うようにも思います。
実際にエンジニアとして過ごしてきて感じるのは、今のエンジニア生活を支えている「それぞれが少しずつ give し合う」という習慣の強さです。一つ一つの give に対してメリットを求めようとすると、正直さしてありません。よほど注目される情報であれば反応も大きくやりがいも感じるでしょうが、ほとんどの情報はその時点では他の情報に価値が埋もれてたいして注目もされないでしょう。割に合わないと思うことでしょう。
しかし、エンジニアとして過ごしていくうちに、そういう小さな情報に助けられる機会がいかに多いかを実感していくと思います。自分が何時間も困っていた現象をすべて解決してくれるような内容を、解決した問題としてブログに書いていてくれるような人もいます。それでも、コメントやソーシャルブックマークのようなアテンションはさしてないでしょう。ただ、間違いなくそういうものに支えられてエンジニア生活を送ってることに気づくと思います。
たとえば、Rubyist で Rails を使っていれば、いつか前島さんのブログに出会うでしょう。名前を意識するかはわかりませんが、このブログがなかったら困ったという日本人 Rails 利用者はかなり多いでしょう。ひょっとすると、Rails コミッタ松田明さんを知らなくても前島さんのブログは知っているという人もいるかもしれません。それくらい、今のエンジニアはこうした情報に支えられて生きてます。
発表や雑誌記事、書籍、発表資料の公開についても同じことが言えます。発行されるすべての書籍、リファレンスマニュアル、論文、ソースコード。すべてに自分で目を通せればいいのですが、物量と時間の制約上、そうはいきません。その中で、読むべきものを絞ってくれる、見落としていたものを紹介してくれる、自分の知恵を共有してくれる、といった誰かの give のおかげで、読むべき書籍を絞れたり、新たに見つけたり、自分の理解を深めたりといったことができています。
これまで何年もそうやって学んできたので、自分の学んだことは自分の知識だという意識はほとんどありません。もらったものをその情報をくれた人へ返すことはもう不可能な量になりました。でも、それでいいと思ってます。自分がもらったものは、機会を見つけていくらでも次の人へ返していきます。
これからエンジニアになろうという人は、いろいろな本や文章に出会うでしょう。それをどうやって学ぶかというのももちろん大切なことなのですが、この文章を読んだ人はエンジニアの give の輪に参加したんだということに気づいてぜひ自分の give を始めてみてほしいです。意気込んで始めてみたものの反応がなくてがっかりするかもしれません。でも、そんなものです。気にせず続けてみてください。一発かぎりのインパクトよりも続けていることへ敬意を払われやすいというのもこの輪のルールです。
世治にはあえて言わないが（笑）…ブログでは言っちゃうが（笑）…
世治の好きなポイント、いきやすいポイントを熟知しているので
イントロ最後をコードAでステイして
そのままAメロあたまをAmajor7で半音テンションを付ければ
あとは勝手に世治が美メロを構築してくれると信じて
「はい！どうぞ」と。
見事な美メロを描いてくれました。
海外有名美大へ通う美大生に教えてもらったこと。一晩かけて完成品に向けてデザインが進むプロセスを話ししながら過程の写真を見せてもらった。めちゃくちゃおもしろく、刺激を受けたので自分の理解としてメモ。
本人はかなり論理的ではない話し方をするので、それを基本的に論理的に思考するぼくが自分が理解できる形に落としてしまっている。このため、大切な要素は抜け落ちしている可能性が大いにある。ただ、本人の説明をそのまま載せると「こう、ええなあと思った」とかそんなんで終わってしまうので、こうなっている。あしからず。
きっと、「よさそうな要素」を探すためにやっているあたりの試行錯誤やそこで作っているものは、定番のパターンに基づくものが多いんだと思う。プラ板に傷つけてみるとかアルミホイルをくしゃくしゃにしてみるとか、複数の模様のパターンがあればつなげて組合せにしてみるとか。そういうのを実際につくってみて試してみているうちに、定番の要素と定番の要素が組み合わさったアイデアとかが出てきて、そういうのの積み重ねで、全体でみると新しいアイデアに見えるものが生まれてくるのだろう。
そこで何を採るか、何を採らないかの判断が結果へ大きく影響を与えるのだろうが、そこは「ええなあと思ったから」の一言だったりしたので、なかなかむずかしい。
QConTokyo 2012 へ参加するので、参加予定トラックを書いてみる。現地に行きながらあのセッション聞かないとかその眼は節穴なの？というようなやつがあったら教えてほしい。
なんか書こうと思ったことがあったのに光の速さで記憶から消えていった。なんだっけ。
あ、そうそう。唐突だけど、退職金というものについて計算してみた。
退職金をもらえる会社というので働いた経験が大変少なく、今後もそういう会社で働く機会はあまりない人生を送りそうな予感がするので、不幸にも退職金がない人はどの程度の不利益をこうむり、どんな準備をすればいいかを知りたかったのだ。
「一部上場企業 退職金」でぐぐってみると、退職金の相場というのは 2000 万円 〜 3000 万円といったところらしい。サバを読んで現在 30 歳だとして、65 歳定年までに 3000 万円が貯められる年収がもらえるなら、退職金がないデメリットを補えると言っていいだろう。本当はここに複利での運用益が載るので大分有利なんだけれど、そこはいったんおいておく。
年収の中から年間約 90 万円を積み立てておくことができれば、運用益が 0 の預金をしておいたとしても十分に元がとれる。仮に運用益を 5% で計算すると、40 万円 〜 45 万円の積み立てで十分退職金を賄える計算になる。
もっと圧倒的に不利なのかと思っていたけれど、年間このくらいの額で自分の職業人生を満足いくように生きていけるのであれば、何もひとつの会社に縛られるリスクを負ってまでほしいものではないなあと確認することができた。
注意点として、退職金は税務上とても優遇されるし、一方投資した場合の税率はバカにならない高さなので実際は上で書いたほど気楽な数字ではない (給与へ課税され、さらに運用益へ課税され) 。ただ、そのあたりが気になるのであれば、自分で調べて考慮した商品 (たとえば年金保険とか) を組み入れたポートフォリオにするなり、確定拠出年金を使うなり、選択肢はある。倒産による転職を余儀なくされる可能性なんかを考えると、投資元本保証型の年金保険にでも入っておくほうが退職金よりもあてにしやすい気はする (投資元本保証の前提として、途中解約しない前提。途中解約の可能性があるなら自分で運用が無難かなあ) 。
そして、やっぱり複利は偉大だ。こうして数字を見ると貯金しないといかんなあと思わされる。