社内勉強会を主催しました

自分が今の会社でエンジニアとして幸せになるための手段の一つとして、技術に興味がある仲間を増やしたいという思いから勉強会を主催しました。勉強会を思い立ったきっかけは、KitchHikeのCEOでいつもお世話になっている@syokenzさんが、昔勤めていた会社で同じような動機から勉強会を作ったというエピソードを聞いて、自分もやってみようと思ったからです。

今回は初めてだったので今後の活動方針の話し合いと、残りの時間でLTの発表しました。自分のスライドはあんまり役に立つものではないですが貼っておきますｗ

http://slides.com/ryosukeigarashi/kokubunjistudy00#/

・The hottest device

・Scraping入門

やってみた感想としては、

・全員Mac使いだったのでMacの便利ツールとか共有できた

・それ以外にも自分が知らない情報をたくさん得ることができる

・人前でプレゼンする練習になる（社内の人だけなのでやりやすい）

・発表のネタを考えるのが楽しくて勉強のモチベーションになる

などなど、かなりいいこと尽くしでした。単純に楽しかったし。

今後しばらくはこのまま続けて、いずれはもっと輪を広げてみたいなと思ってます。

性格をコントロールする

前回の記事に引き続き、モヤモヤ系エンジニアの自己分析ｗ

前回の記事（愚直であれ - Persistence）では、とにかく愚直にやってみるということを書きましたが、そうと決めてもやはり勉強のスピードが出ないものです。

パターンとしては、①作りたいもの（目標）を考える、②それに向かって必要な知識を習得したりものづくりを始める、③作っていくうちに作りたいものがほんとうに必要なものかわからなくなってくる、④スピードダウン・停止、という流れです。愚直に突き進むことを徹底するなら③のステージになってもスピードを緩めない方がいいのですが、作りたい熱意・動機がそこまで高くないので③のステージで負けてしまうっていうパターンですね。愚直を突き通すには強い動機が必要であり目標を見失わないことが大切ってことが分かりました。

これはあくまで自分の例なので、この記事を読んでいるモヤモヤ系エンジニアの方すべてに当てはまるわけではないですが、このように自分の性格による行動パターンを認識して受け入れてあげることで自己嫌悪に陥らずストレスも少なくなるのではないでしょうか。

このことは、たまたま読んだ「つまみぐい勉強法」という本の中でも触れられていて、この本の中でも４つの性格ごとに適した勉強法が紹介されていました。（どれが一番いいとかは無しに）

IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)

本の中の言葉をそのまま使うと自分は「坂本龍馬タイプ」になったのですが、興味がすぐに移り変わるとか、すぐ飽きるとか、興味が無いことはできないとか、まさに自分の性格そのまんまが書かれていてちょっとビックリしましたが、そういうやり方でもいいんだという安心感を得られました。

このやり方だとスペシャリストにはなれませんが、ジェネラリストにはなれます。自分は「技術力を伸ばしたい」よりも「サービスを作りたい」という欲求のほうが強いというのは分かっているので、実は自分でも気づかぬうちに自分にあった最適な方法をしていたのかもしれません。

まとめ

• 愚直にやり続けるのは自分の性格に合わないので、自分が本当にやりたいテーマが見つかるまではいろんなことをつまみ食いし続ける（つまみ食いしながらも勉強は継続する事が大事）
• 途中で飽きたりしても自分の性格はそういうものと割り切り自己嫌悪しない。

おまけ

その優柔不断な性格を直した方がいいのでは？と思う人もいるかもしれません（自分もちょっと思ってるｗ）。でも自分の考えでは、性格はそう簡単に変えられるものではないし、いろいろな性格の人がいるからこそ多様性があっていいのだと思う。（ちょっと話は飛ぶけど、）一説によると、人類が他の生物よりも進化できたのは、他の生物は弱い種を淘汰しより優秀な種を残すことで生き延びる戦略をとってきたのに対して、人類は多様性を許容したからだと言われている。

それでも性格を変えたいという人には、このあいだ吉政忠志さんの転職に関する公演で教えてもらったマザーテレサの有名な言葉を紹介します。

思考に気をつけなさい、それはいつか言葉になるから。

言葉に気をつけなさい、それはいつか行動になるから。

行動に気をつけなさい、それはいつか習慣になるから。

習慣に気をつけなさい、それはいつか性格になるから。

性格に気をつけなさい、それはいつか運命になるから。

愚直であれ

技術エントリーではなく、気持ちの整理的なエントリーです。

技術力のなさを痛感

最近、転職活動をしていたり、技術力の高い人達と共同作業をさせてもらう機会があって、自分の技術力・知識量が本当に低いなということを痛感してます。特に転職活動については、自分が望むようなWeb系ベンチャー企業に対しては完全に力不足であることが分かりました。

自己分析

そんな凹むことが多いこの頃ですが、新しい気づきもあります。まず技術力については現状は現状として受け止めるしか無いとして、何が問題なのか自己分析をしてみましたところ、成長のスパイラルができていない事が分かりました。

成長のスパイラルは、以下の①〜④で回ると考えています。

①物事を始める ②壁にぶつかる ③壁を乗り越え達成感を得る ④次のステップへのモチベーションが湧く

しかし、自分の場合は②の部分で諦めてしまうことが多く成長のサイクルが回っていませんでした。②で止まった後どうなるかというと、以下のようなループになります。

①物事を始める ②壁にぶつかる ③モチベーションが下がる ④今やっていることより他の事のほうが面白そうに見える

②で止まってしまう人のパターンとして、簡単に言うと「根性なし」な性格なんですが、もっと深く行動心理について調べると、「心理的なストレスに弱い」ということらしいです。それに壁を登ることを楽しくできないようであれば、エンジニアには向いてないんじゃないかなとも思いましたが、それを決めるのはまだ早いです。

ストレスに弱いのは生まれ持った性格と育った環境によるものなので仕方ないですが、成功体験をたくさん積んで自分に自信が持てればある程度は変えられるのではないかと思います。そのためには、一度決めたことを愚直にやり続ける事が大事だと考えています。「継続は力なり」っていう言葉は知っているし重要性も理解していると思っていたけど、全然わかっていなかったことに気づけました。

それから技術的な自分のポジションもわかったことは多きな成果です。自分はやっとホイミとかギラとか覚えたくらいのレベルです。何故それがわかったかというと、相対的に自分よりがレベル高い人たちが自分の周りにたくさんいるから。だからそういうところに飛び込んでみるっていのもやって良かったと思います。

あと課題として見えてきたことは、アルゴリズム力（つまり論理的に思考を組み立てる能力）が無いということ。自分はサービス指向が強いのでWeb系のフレームワークとかライブラリばかりを使っていたけど、それって用意された道具を使っているだけで、プログラマとしての基礎体力はアルゴリズム力何じゃないかと思った。これがないとコピペはできるけど1から作ることができない人になります。

まとめ

• やると決めたことを脇目もふらず愚直にやりきる
• 困難に立ち向かうことを楽しむようにする
• アルゴリズムの勉強をする

すごいディーラーリストを作った

ドルパ（公式）のディーラーリストが見づらいって思うので、Railsの練習がてら「俺が考える最高のディーラーリスト」を作りました。

すごいディーラーリスト for ドルパ31

最高の〜〜〜と言いつつ完成度は50%です。100%を目指していましたがドルパが終わってしまいそうなので、やりたいことの半分ができたので公開に踏み切りました。残りの50%はUI部分なので使ってもらってフィードバックを得て次のドルパまでに100%にしようと思います。（なのでUIはほんとにやっつけです。すごい使いづらい。）

やりたかったこと

技術課題として主に2点がありました。

• ディーラーサイトのスクリーンショットとRSSを自動収集して表示する（できました）
• AngularJSを使ってページングや検索・フィルタリングが柔軟にできる（間に合わず）

技術的なこと

Qiitaに投稿しました。

Ruby - Rails4+MongoDB+Herokuでサイトのサムネイル画像を保存・参照する方法 - Qiita

Qiitaにも書きましたが、無料でホスティングしたかったので画像をBinaryでDBに保存したのが今回チャレンジしたことの１つです。

HerokuのMongoHQは無料で500MBまで使えるので、1つ100KBで単純計算で5,000枚まで行ける計算です。計算だったんですがそんなに詰め込めないようでした^^;

Everyday Railsを写経する（その1）

最近とあるプロジェクトに参加させてもらって、そのお陰でテストコードを書く機会に恵まれたのは良いのだけど、なにせほとんど書いたことないものだから全然わからない。ということで「Everyday Rails… Aaron Sumner 著 et al. [Leanpub PDF/iPad/Kindle]」を使って勉強を始めました。

今日は「３．モデルスペック」の前半、DRYにするの前まで。モデルのvalidationとmethodのテストの書き方について勉強しました。ここでモデルのmatcherについて書くのはDRYじゃないので、リファレンスのURLだけにしておきます。

rspec/rspec-expectations · GitHub

methodのテストで便利なものにchangeというmatcherがあります。値が変更されたかどうかを検証するのと、メソッドチェインで.from（元の値）、.to（変更後の値）、.by（差分）も同時に検証できる。サンプルはリファレンスの「Composing Matchers」にあります。

Ginza.rb #10 に行ってきた！

銀座周辺のRubyistが集まる勉強会に行ってきました。

会場がすごい

会場はリクルートライフスタイルさんの会議室でした。大部屋に座れる階段みたいなのがあってリラックス出来る感じでした。他に畳部屋や南国部屋があって素敵すぎる会議室でした。お菓子とコーヒーもサービスして頂いてありがとうございました。

初参加の人が多い

今回のテーマは、RubyWarriorというRubyを学習するために作られたゲームで遊ぼうというものだったので、割と参加しやすく初参加の人が多かったようです。私も初参加の人でした。私の場合は、参加しやすいテーマだったっていうのと、タイトルの『Rubyの力で道を切り拓け！』ってところに刺さることろがあり思い切って参加してみました。

複数人でのライブコーディング

RubyWarriorはコードを書いてゲームを進めるシステムなので、複数人でひとつのコードを書くという作業が新鮮で面白かったです。人前でコード書くっていうのはホント頭が真っ白になります。ゲーム自体はかなり良く出来てるなという印象でした。beginnerモードでも意外と難しく、時間がなかったので最後までいけませんでしたが、最後までクリアしたいと思います。

KPT

毎回振り返りをやっているのは良い習慣だな～と思いました。K(Keep)、P(Problem)、T(Try)は覚えておこう。

Rails+Mongoってどうなの？

次の個人的なプロジェクトでRails+Mongoで作ろうかなと考えていて、でもRailsのActiveRecordつかったらMongoのスキーマレスの良さがなくなっちゃうんじゃないかなーって思っていたので質問してみました。立ち話で最後までお話できませんでしたが、やっぱりActiveRecordとMongoの思想はちょっと違うからあまりオススメできないって感じでした。自分はよくMongoとNode.jsを一緒に使っていて、スキーマレスならではの柔軟性やコードとの親和性が高いのがすごく好きなんですが...DBを取るかフレームワークを取るか難しいところです。

あと、試しところRails4.1に対応したMongoのドライバはまだなく、Rails4.0だとmongoidの4.0.0.beta1もしくはmongoid_rails4というgemが対応しているようです。まだインストールしかしてないですが。

懇親会

• いろいろな人と仕事についての話や、キャリアについてお話ができたのはいい刺激になりました。全員とはお話できませんでしたが、また機会があればお話したいです。
• Googleグラスとか360度カメラとかガジェットをさわらせてもらった。Googleグラスの空間にディスプレイがある感じかっこいい！ただ、メガネしないとボケることがわかったので度付きグラスも作ってください。360度カメラはほんとに死角なし！天井とか地面とかどうやってとってるんだろう。専用のアプリがなくてもぐるぐる見れるのはすごいですね。

最後に

運営の方々ありがとうございました！

『ドラッカーさんに教わったIT技術者が変わる50の習慣』

概要

タイトルにちょっと問題ありだが内容は素晴らしい。

タイトルの「ドラッカーさんに教わった〜」という表現は、実際にドラッカーが本の内容を教えたわけではないので適切でないかもしれない。「ドラッカーさんの教えをIT技術者にあてはめた〜」が正しい。更に言うとドラッカーではない本からの引用も多数ある。という細かいツッコミはあるとしても、書かれている内容はどれも大変良いものでした。全部書き出すわけにも行かないので、特に意識しておきたい（自分に欠けていると思われる）内容をまとめておく。

対象読者

内容としては大きく分けて、3/5がプロジェクトメンバーとしての習慣、2/5がプロジェクトリーダーとしての習慣となっているが、現在の立場に関係なく新入社員もCEOも読めばいいと思う。

内容メモ

01.知的労働者としての特性を意識する

私たちは知的労働者です。私たちは、命令にしたがって行動するのではなく、自分で考えて意思決定をしなければなりません〜 ITエンジニアは自分を軸に判断していると仕事がうまくいきません。社会、顧客、会社、周囲のエンジニアなど、自分以外の何かに対する貢献を意識すると、自分の感情以外の部分で判断することができるようになります。

『貢献する』という意識が、IT技術者としてのすべてのスキルの根底になるということです。

20.仕事の品質を向上させる

金銭的な報酬を求めるのではなく、自分自身の能力・仕事・成長を報酬として考える〜 自分のやった仕事は、自分の作品だと考える〜 こういう気持ちで仕事をしていくと、仕事の品質を高めることは手抜きのできない重要な事になるのではないでしょうか？〜 これは、自分自身のモチベーションアップにもつながるはずです。

前向きなマインドの持ち方ですね。

28.誤りを誠実に謝罪する

謝罪は、決して相手に許してもらうためにするものではない〜 自分を正当化して逃げ回っても、問題はついて回ります。〜 先延ばしすれば、忘れられるのではないかという期待は、あなたの心の弱さであり、全くの幻想です。時間が経つほど、事態は必ず悪化します。

謝るときも、逆に謝られる時も、感情は脇に置いて論理的に対応することが大切です。

37.メンバーのプロセスを管理する

最終的に完成した仕事の品質は、個々の仕事の品質の総和です。ここの仕事の品質が充分でないのに、全体の品質が良いということはありえません。

テストだけが品質ではないということです。

まとめ

この他の習慣も全て大事なことなんですが、すごくざっくりまとめてしまうとこういうことなのかなと思いました。

『すべての行動や判断は、目的意識を持って、論理的に行うべし』

ドラッカーさんに教わったIT技術者が変わる50の習慣