寝る前にラーメン

ソフトウェアエンジニアです。絶賛デブエット中です。

Heroku Meetup #5に参加してきました

今回はmixiさんのセミナールーム的な場所で。
なんとピザとビールが支給され!
プレゼンスタイルでありつつも、
カジュアルな雰囲気が保たれたミートアップでした。 

前回はAddonプロバイダーの方が来日(?)してお話をするという、
英語が分からない人には辛いセッションでしたが(でもためになった)、
今回は日本で導入しているチームがサービスの宣伝も兼ねてHerokuの良さを語るというスタイルでした。

たしかにHerokuのメリットは分かりやすかったし、
導入の背中を押すのにはこっちのが伝わりやすいのかも。


具体的には、

はHeroku使ってるよ。

人的リソースが限られている場合は、
Herokuに面倒なところは任せてビジネスにフォーカスできるよ!

もちろんスケールアウトとか面倒なところもやってくれるよ。
(ここはIaaSのレイヤーでも既に言えることだけど)

アドオンがちょー簡単に導入できて、
機能追加ができるのは強力すぎるよ。
(具体的にはNew RelicPapertrailなんかがいいよって挙がった。
Papertrailは#4んときにプレゼンがあったね。) 

などが繰り返しメッセージとして押し出されていた。
前回もここらへんは触れられていた。


ちなみに、どのチームもこの前の(AWSに起因する?)Heroku障害について触れていて、そこは頑張ってくれ!という感じ。
でも、Heroku Statusの完成度には感服。 


総じて感じたのはHeroku(PaaS全般に言えることだけど)はインフラの知識があまりない場合にとても効果的。

ただ、やはりリージョン問題があるので、
直接話してみるとまだ踏み切れないでいる人は多いなという印象。

うちも日本リージョンが出たら即切り替えてもいいと思って情報収集をしているけど、
現状の西海岸だけだと日本からだと往復で200ms弱の上乗せがあるのでちょっと厳しいかなあ。。


あー早くHeroku使って楽したいよ(´・ω・`)
引き続き今後の動きに期待!

今日はありがとうございました:-)

いまさら2012年度の年度目標

気づいたら6月の終わりが見えてきた。。早いなあ。
TechネタをQiitaに投稿するようになってからはブログを書く機会が減ってしまいました。
ほんで、前から年度目標を書く書くと言って間があいてしまったので、今度こそ書く。
こっ恥ずかしいけども。。 

 

シンプルに3つで、

  1. 他人に価値を与えられる人になる。
    今まで気持ち的に誰かに依存していないと生きてけない人だったので、
    精神的に自立して生きていけるようになりましょうってところ。
    それで、周りの人、特に比較的新しい繋がりの人にも、
    なんらかの価値を与えられる人になりたい。

  2. 健康になる。体力つける。
    ジムは通ってます。
    今年の札幌IVSでもどなたかが「意思の強さは体力に依存する」 とおっしゃってたし、こんつめて仕事する上では体力は本当に大事だな、と日々感じているので。
    1回1時間を週3回ぐらい続ける。

  3. 英語でコミュニケーションとれるようになる。 
    読むのはほぼ問題ないけど、喋るとなるとなるとまだ不得手なので。
    海外いたときは嫌でも絡みがあるからいいけど、
    日本にいると退化するばかりなのでなんとかする笑
    今むりなので、夏明けぐらいから教室通うかSkype英会話か。。

を年度頭にばくっと決めて、ちょっとずつ取り組んでいる最中です。
具体的な行動目標書かないと宣言しても意味ないよ、って言われそうだけど許して。

 

エンジニアとしての目標ももちろん決めてあるんだけど、
どっちかというとこれらが今は先行していて、今までの自分らしくないす。

というのも、エンジニア人間でもっとギーク路線を極めていこうとしてた中で、
もっちょい人間臭いところで価値出せるようにしたいと思うきっかけがあったところ。

そういう意味で、こういう環境で働くって選択したのも悪くなかったかな、と思ってます。最近ね。

エンジニアの生産性と集中力、スタートアップと少しからめて

GWなのに具合が悪くて(´・ω・`)

もう寝ようと思っていたら、
WEB+DB vol.68 pp.2-3「プッシュ型メディアが生産性に及ぼす影響」
を読んで感化されたのでブログ書くことにしました!

全くまとまりのないタイトルで残念なのですが、自分の最近の働き方と絡めて感想を綴りたいなと思います。


記事の中では、 

知識労働の中でも、プログラミングは特に高い集中力が必要な仕事である。
十分に集中力の高まった状況(「ゾーン」と呼ぶ人もいる)に自分を持っていくのにはそれなりに助走時間がかかるので、1日に何度も入れるものではない。そのうえ、集中して仕事をするのにはかなりの体力も必要なので...

 とエンジニアはとても集中力が必要なんだよと説明しています

それにはとても共感していて、私自身もプロジェクト初期の設計段階や大事な認証部分などのロジックを考える時はひとりモレスキンを持って静かなカフェに篭ったりもしていました。

手慣れた実装や「刺身たんぽぽ」のような作業は集中力が浅い状況でも問題はないのですが、そういった作業は極力自動化されるべきですよね。


それを踏まえた上で「プッシュ型メディア」の影響について書かれています。

「集中力」を高めてゾーンに入って」コーディングしなければならないソフトウェアエンジニアにとって、このプッシュ型メディアの影響はとても大きい。
たとえ「Facebookに新しい投稿されたメッセージをチェックすること」そのものには10分しか費やさなかったとしても、せっかく入った「ゾーン」から引きずり出されてしまうのであれば、失われた時間は 10分よりはるかに大きくなる。

まさにその通りだと思っていて、TwitterFacebookからのプッシュ通知を全て受け取っていたら浅い集中力の領域から抜け出せないと思います。

これは「プッシュ型メディア」だけでなく、単純に近くの人に話しかけられたりすることも一緒ですよね。

自分も集中力の高さがウリだったので、作業中に話しかけられたり、喧騒な場所で作業をするのをとても嫌っていました。

今でもスカイプを起動していないのもこの理由です笑

とはいえ、それによって相手の作業が滞ったり、チームとしてのスピード感が無くなってしまうのは本末転倒なので、最近は極力即時的にレスポンスを返せるように努力しています。

いわゆるスタートアップと呼ばれるようなチームにおいては1人の領域がとても広いので、決まった領域のことを淡々とこなせばいい時間は非常に少ないと感じています。

圧倒的な集中力が必要なエンジニアリングとコミュニケーションの速さのバランスが難しいのですが、これにはソフトウェアエンジニア以外の人の理解が欠かせないと思います。


ところで、naoyaさんのブログにこのような記事があったのを思い出しました。

naoyaの寿司ブログ
"時間をこま切れにされたら、人は何ものにもなることができない"

その中で紹介されている吉本隆明さんの 『ひきこもれ』という本の中で

「分断されない、ひとまとまりの時間」をもつことがどんな職業にもかならず必要なのだとぼくは思います。

とあります。

ひとりでいると欝になるので引きこもって作業するのは好きじゃないのですが笑、「分断されない、ひとまとまりの時間」はとても大事で、その領域を極めるためには絶対必要なものだと思います。

差がつくのはこの時間の質に依るはずです。それがソフトウェアエンジニアの領域においては集中力だと思っています。


ソフトウェアエンジニアには集中力が必要です。

だからといって、エンジニアには仕様書以外渡すなとか笑、SNSは全くやらないほうがいいといった類いの主張ではありません。

ただ、そういった周りの理解がより高品質なサービスを生むと信じています。

自分もコミュニケーション量をうまく保ちつつも、集中力を高めて作業できるようにしてきたいなと思いました:-)

Heroku JP Meetup #4に参加してきました

4/20(Fri)にATNDで見つけたHeroku JP Meetup #4に参加してきました!
あまり長いセッションではなく、短時間でしたがとても面白いイベントでした。

基本的にセッションは英語で、Heroku Add-onを提供している方がそれの解説をしてくれました。
主に3つで、、、 

  • IronMQ
    名前の通りMessageQueueを提供する。
    ローカルよりは遅いけど、Amazon SQSよりも早く動くよって。
     
  • WebSolr
    テキスト検索の話から順を追って解説してくれた。
     
  • Papertail
    集約したログをウェブから閲覧できる。
    検索もできるし、条件に合うログが吐かれるとメールをしたりiPhoneに通知したりできる。 

どれも興味深い内容。

そもそも自分は、お恥ずかしながらHerokuをまだ使ったことがなかったので、
紹介されたサービスの魅力に加えHeroku Add-onのパワーに驚きました。

またHeroku, PaaSの代表としての勢いも感じました。
ハードウェアを意識しなくて良いAWSも素晴らしいけど、
Herokuのようなサービスが地理的にも言語的にもどんどん広がっていってくれれば、
小さなサービスのイニシャルコスト(ほとんど人的なものだし)は大幅に減らせると思うので。

是非是非自分も使ってみたいのだけれど、
日本向けのサービスを中心に作っている今ではやはり西海岸からのレイテンシは無視できない(´・ω・`)

東京リージョン期待!のような旨をプレゼンに挟まれている方もいらっしゃったが、本当にそう。
マルチリージョンそろそろこないかなー

下部に貼り付けてある写真は、会場の様子。
(パソナさんのFacebook Pageから拝借) 

ちなみにパソナの社員さんはとてもフレンドリーで会場もとてもきれいだった。
会場のご提供ありがとうございました:-)

そしてこのような場を提供して下さったHerokuの関係者の皆さん、ありがとうございました:-)
こういったコミュニティの発展に、微力でも貢献していかなきゃいけないなと思いました。 

ONLAB Hackathonに参加してきました!

2/18~2/19の週末に行われたOpen Network LabのHackathonに参加してきました。
チームはいつものWondershakeのメンバー。

100人ぐらいのエンジニアが集まり、もうお祭りでした笑

大人数が黙々と作業をしていたのでどんな雰囲気になるんだろう、と思っていましたが、
会場は心地良い音楽と周りのチームの話し声が混ざって、とてもいい空気感でした。

f:id:thleave:20120218142503j:plain

私たちのチームは、「Wondershakeの業務では作らないようなアプリを作ろう!」と話していました。
いろんなアイデアが生まれ、中には他のチームが実際に作っていたアイデアもあったのですが笑、
結局このようなアプリを作ることにしました。 

f:id:thleave:20120222022216p:plain

どこかのソーシャルグラフを使ってそこでVoIP通話が出来るようにしたいと思っていたのですが、
Hackathonで出来る作業量では無いことに気づき笑

Twilioに頼っても現状では実装が難しいことが分かり、
録音した音声をリアルタイムにiPhoneに転送することにしました。 

f:id:thleave:20120222022858p:plain

これが意外にもウケて。
通話しなくていい気軽さと、
録音した音声が(止めない限り)エンドレスにリピートされる面白さが良かったのかな、
身内ではかなりの高評価でした。

Hackingの後は44チームによるプレゼン大会。

f:id:thleave:20120222023709j:plain

 (2分間で、iPhoneを2台使ってデモをするのはなかなか大変でした)

f:id:thleave:20120219182630j:plain

どのチームも面白いアイデアばかり。
また、モノは出来上がってないけど、プレゼンが面白いチームもいくつかあって笑
エンジニアという名前に甘えて、プレゼンをうまく出来ないのはダメだな〜と改めて思いました。

その後、みんなで懇親会&表彰。
36時間のHackingだったので寝てない人も多く、
自分を含め不思議なテンションの人が多かったかな笑

f:id:thleave:20120219191840j:plain

私たちのチームは、DNP大日本印刷)さんに特別賞を頂くことができました!
図書券5万円分です!これでオライリー本を買います笑

 

今回のイベントは本当に有意義なものでした。
運営の方々に本当に感謝しています。 

また、たった2日でもこれくらいの品質ものもが作れるんだという自信も生まれました。

エンジニアなんだから作ってナンボ。デモしてナンボ。
もっともっとモノづくりに励みたいなと思える2日間でした。 

Rails3で論理削除と多対多の関係を作ろうとしたら詰まった

Rails3で、以下のふたつを同時に実装しようとしたらダメだった。

  • rails3_act_as_paranoid
    テーブルにDATETIME型のdeleted_atを
    追加すると論理削除が簡単に作れるもの
  • モデル間の多対多の関係(habtm; has_and_belongs_to_many)

 どうダメかって、こんな風に怒られた。

SystemStackError (stack level too deep):

もちろん前者の rails3_act_as_paranoid を外せばうまくいく。

どうやらrails3_act_at_paranoidを使うと、

has_and_belongs_to_many :hogehoge

のところでエンドレスになっちゃう。

他の論理削除を実装する同様のgemも探してみたけど、
同じエラーを吐いたので諦めた。

素直にModelにdefault_scope書いてとりあえず蓋をした。

こういうのをforkしてひょひょいと直しちゃえる人に今年はなりたい、というかなるー