こんにちは。先月からOMGに入社したmat_k2です。よろしくお願いします。

現在、フルスタックエンジニアを目指して、勉強の日々を送っています。ちなみに、フルスタックエンジニアについて世間ではいろいろと定義されていそうですが、個人的には「幅広い知識と、複数の得意分野をもっているエンジニア」のことだと認識しています。

「おすすめの本やコンテンツがあったら教えてください！」とチームチャットでお願いしてみたところ、kei-sさんの「（みなさん出番ですよ）」という心の声が聞こえたのか、弊社のエンジニアや、お手伝い頂いているフリーランスの方々から、怒濤のレコメンドをして頂けました（本当にありがとうございます！）

数で言うと、３０冊と８７コース（coursera）。以下に列挙してみます。

本

	体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 徳丸 浩 (著) 2011/3/3
	Rails3レシピブック 190の技 高橋 征義 (著), 松田 明 (著), 諸橋 恭介 (著) 2011/7/25
	アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技 ロバート・C・マーチン (著), 瀬谷 啓介 (翻訳) 2008/7/1
	プロダクティブ・プログラマ -プログラマのための生産性向上術 Neal Ford (著), 島田 浩二 (監訳) (翻訳), 夏目 大 (翻訳) 2009/4/27
	オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) アラン・シャロウェイ (著), ジェームズ・R・トロット (著), 村上 雅章 (翻訳) 2005/9/16
	情熱プログラマー ソフトウェア開発者の幸せな生き方 Chad Fowler (著), でびあんぐる (翻訳) 2010/2/26
	Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方 Eric Sink (著), エリック・シンク (著), 青木 靖 (翻訳) 2008/9/11
	オペレーティングシステムの仕組み 河野 健二 (著) 2007/10
	なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 2013/04/25
	詳解 Linuxカーネル 第3版 Daniel P. Bovet (著), Marco Cesati (著), 高橋 浩和 (監修), 杉田 由美子 (翻訳), 清水 正明 (翻訳), 高杉 昌督 (翻訳), 平松 雅巳 (翻訳), 安井 隆宏 (翻訳) 2007/2/26
	達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ ミック (著) 2012/3/16
	リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック Dustin Boswell (著), Trevor Foucher (著), 須藤 功平 (解説), 角 征典 (翻訳) 2012/6/23
	リファクタリング:Rubyエディション Jay Fields (著), Shane Harvie (著), Martin Fowler (著), Kent Beck (著), 長尾 高弘 (翻訳) 2010/2/27
	珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造 Jon Bentley (著), 小林 健一郎 (翻訳) 2000/10
	Rubyベストプラクティス -プロフェッショナルによるコードとテクニック Gregory Brown (著), 高橋 征義 (監訳), 笹井 崇司 (翻訳) 2010/3/26
	アルゴリズムイントロダクション 第3版 総合版 T. コルメン (著), R. リベスト (著), C. シュタイン (著), C. ライザーソン (著), Thomas H. Cormen (原著), Clifford Stein (原著), Ronald L. Rivest (原著), Charles E. Leiserson (原著), 浅野 哲夫 (翻訳), 岩野 和生 (翻訳), 梅尾 博司 (翻訳), 山下 雅史 (翻訳), 和田 幸一 (翻訳) 2013/12/17
	Webを支える技術 -HTTP、URI、HTML、そしてREST 山本 陽平 (著) 2010/4/8
	JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス Douglas Crockford (著), 水野 貴明 (翻訳) 2008/12/22
	ライト、ついてますか―問題発見の人間学 ドナルド・C・ゴース (著), G.M.ワインバーグ (著), 木村 泉 (翻訳) 1987/10/25
	Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン ジェフ・ゴーセルフ (著), ジョシュ・セイデン (編集), エリック・リース (編集), 坂田 一倫(監訳) (翻訳), 児島 修 (翻訳) 2014/1/22
	誰のためのデザイン?―認知科学者のデザイン原論 ドナルド・A. ノーマン (著), D.A. ノーマン (著), 野島 久雄 (翻訳) 1990/02
	ビジネスモデル・ジェネレーション ビジネスモデル設計書 アレックス・オスターワルダー (著), イヴ・ピニュール (著), 小山 龍介 (翻訳) 2012/2/10

動画（coursera）

	Computer Science（Software Engineering・Systems&Security・Theory 計85コース ）
	Functional Programming Principles in Scala

まだ読み切っていないけど、読んでみたい or 読んでいる本＆動画

• つくって学ぶプログラミング言語 RubyによるScheme処理系の実装
• パターン認識と機械学習
• Machine Learning
• The Art of Computer Programming Volume 1
• SEがはじめて学ぶ在庫管理
• グラス片手にデータベース設計 生産管理システム編
• グラス片手にデータベース設計 ‾会計システム編
• グラス片手にデータベース設計‾販売管理システム編
• ハイパフォーマンス ブラウザネットワーキング

いやはや、勉強あるのみですね。 知識の吸収とその実践を繰り返しながら、これから着実に成長していきたいです。

こんにちは。さねまつです。Growth Hackerゆるくクビになって5月半ばからエンジニアに戻ってます。

今hubot-scriptブームが社内でぼくと1syoだけに吹いてます。さらに、「そろそろちゃんとした使えるものを作ってよ(1syo)」と煽られてます。

omg-hubot

1syoが作ったリスト

• travisci
• airbrake
• sebastian

kei-sが作ったリスト

• deploy-announce

ぼくが作ったリスト

• hubot-tantanmen
• hubot-phonetic-alphabet
• hubot-53cal-jp
• hubot-google-transliterate

たしかに!! しかも一番使えるゴミ収集情報botは勝手にページスクレイピングしてて怒られるやつだ。まだまだ作るぞ。

背景

最近、エンジニアチャットをhipchatからslack(+hubot)に変えました。

hipchat pros

• iphoneクライアントの出来が良い push notificationちゃんと来るなど
• 画像を上げると、s3直アドレスになるので、アップローダー代わりになる 特にiphoneからの場合便利
• ユーザー数5までは無料、そこからはユーザー課金(乗り換え2014-05-15当時, 現在2014-06-20はユーザー数無制限)

slack pros

• ユーザーのアイコンが表示される 重要
• 画像を上げるとslackのユーザー認証が間に入るので、正しい権限のある人だけがアクセスできる
• 他サービスとのintegration 5までは無料、そこからはユーザー課金

slackのintegration課金をひとまずすり抜けようと、通知系をhubotに集約してます。 github, hubot, newrelicの3本に抑えてる。 さてslackの課金体型変わったらどうしよ?

以上デース

こんにちは。kei-s です。

先日 Tokyo Rubyist Meetup で開催された eコマースとRails – Spreeの全て というイベントに登壇しました。 そこで、サービスで Spree をどのように利用しているかについて20分ほどお話ししました。

Spree とはなんぞや、などについては過去に発表した資料をご覧ください。

• How a small team built an e-commerce service w/ Ruby on Rails and Spree // Speaker Deck
• Spree のモデリング解説 第一弾 – OMG Tech Blog

スライド中では、なぜ Spree を選んだのか、Spree の良いところ悪いところ、カスタマイズの方法などを説明しています。

今回 Tokyo Rubyist Meetup に登壇して、日本には Spree に興味がある方が思った以上にいたことに驚きました！ まだまだ日本での導入事例が少ないなか、知見を共有できて嬉しいです。

また、一緒に登壇した Degica の @shioyama さんと発表前とお話しして、実際に Spree を使っている方と情報交換でき、とても勉強になりました。

登壇をお誘いしていただいた Tokyo Rubyist Meetup 主催の @pwim さん、ありがとうございました！

こんにちは。さねまつです。2月からGrowth Hackerになってみました。

Growth Hacking

Growth Hackingチームは自分一人がフルコミットで、あとはデザイナーが週に1日分ぐらい時間を割いています。

まず結果は?

自分で立てた目標数値を達成出来ていない。

どんな目標立てたの?

大きく目標は、サイト全体のコンバージョンレートに置いた。

グロースハッカーなのにユーザー獲得じゃないの?

スタートにあたって重たい順に倒していくことにした。商材のリピート間隔と、リピート率と、から言うと”現時点では”重たいのがそこだったので。

どういうことしてるの?

仮説立てるのに必要なだけの数字継続的に計測できるようにする。

数字計測して課題となるポイントを洗い出す。

課題に対して仮説を出して、効果とコストを見積もる。

効果とコストからスコアを計算して、スコアの高い順に着手。

自分一人でやって、半日や一日で終わらないストーリーはやらない。

入れてく策はoptimizely上で対照実験しながら入れていく。この辺は普通のA/Bテスト。 optimizely上だけでjQuery書いて差し替える場合と、コードベースに片方display: none; で突っ込んでoptimizely上でdisplay: blockに書き換える場合がある。 一定数の効果が見られる流入を与えて、勝者が出たらviewにちょろちょろっと書いてたcssやjavascriptをあるべき場所に書き直す。 俺のバリューってoptimizely上でちょろっとjQuery書くそれなの?って思うとアレ?って気がしないでもない。

こんなの。

1
2
3

$('body:not(.mobile) .main-header-guide__search').css('display', 'none');
$('body:not(.mobile) .test-search').css('display', 'block');
$('body:not(.mobile) input.search-box__search-input.test-search').attr('placeholder', 'サイト内を検索　例：アンダーリム');

結果が出てればいいんだけど、全体的な要因で伸びてる以外は誤差レベルなので、growth hackingやってます!って言いたいだけになってる。

マズイ。

はじめ思ってたこととそうでもないこと

A/Bテストどんどんやっていこう!と思ってたけど、なかなか進まなかった。 数字の根拠が足りなくて説明できないことが多かった。

もやっとしてた。「グロースハッカー」読んでたらいい定義があった。

グロースハッカーはマーケターとエンジニアのハイブリッド – ライアン・ホリデイ『グロースハッカー』

なるほど! マーケティング!? マーケターだったのか俺は。 定義でもやもやが解決するってのはそんなこと無いんだけど、ちょっと進んだ。もうちょっとエンジニアタスクに時間割ければ色々出来そうな気がしてたのに、数字計測したり根拠考えたりばっかりしててどうなるんだろう、って思うこともあったけどマーケターなら仕方ないな。

これから

GrowthHackにおいて一番大事なこと | symsonic

facebook: 10日以内に7人以上の友人と友達になる割合をKPI

とかairbnbでプロのカメラマンに部屋の写真を撮ってもらうとかそういうキラーKPI見つけるしないと。

立てるべきだった目標

• 事業が成長する魔法のKPIをみつける
• お客様が流入する魔法のチャネルを発掘する
• そしてそれらの土台作り

ぼくがabテストを一番うまく扱えるんだ！ex-zyngaですし

マーケターやデータマイナーっぽい意識を持ってるとちょうどいいのかも。

募集

一緒にGrowth Hackingやりたい人募集!

まとめ

事業を育てるぞ。

こんにちは。さねまつです。

カラーとモノクロをtoggleするbookmarklet書きました。toggle-monochrome

インサイト

なるほど〜ってなっただけでそんなになかった。既にちゃんと考えられている!

おまけ

generater-bookmarkletがgruntからgulpになってておっってなった。

そしてドヤ顔で同僚に見せに行ったら「アクセシビリティーチェックのそういう拡張あるよ」って教えてもらいました!!なるほど!そっちを使ったらいいと思います。

see

• 色を色で見ないで｜1 pixel｜サイバーエージェント公式クリエイターズブログ
• https://twitter.com/hail2u_/status/436742409376903168

以上デース

こんにちは．さねまつです．弊社オーマイグラスの共同創業者二人(清川・六人部)は両方とも非エンジニアです．そういう環境ってどうなの?

結論

• メリット・デメリットふつうにある
• 論理的ならいいんじゃない?

メリット・デメリット

挙げるほどのメリットもデメリットもなかった．あと，書き出してみたらだいぶひとによってしまった．うっ．

オーマイグラスだと清川がオペレーション，バイイングを見ている．六人部が開発，サービス側を見ている． 六人部はアジャイルサムライでいう「荒ぶる四天王: 時間、予算、品質、スコープ」の話を知っていてまあ調整するならスコープだよね，というのを頭では理解してくれている．やりやすい．常にそうかって言うとそうでもない．もちろん，「とはいえ」みたいなことはある．やっぱりビジネスだし．ある程度は仕方ない．あとgithub issueでやりとりできるから楽．

論理的とは

特に清川はシステムに対しては一歩引いてみている．ただ，やっつけで組み込むべきところとシステムにちゃんと載せるときの区別はしっかりしている．

「それスケールするの?」は前何度か聞かれた．根性でなんとかなるところとそうじゃないところ，再現しないところに注意を向けてくれる．

社内では

エンジニアチームで最近話しているのは，エンジニアチームを社内周りから見た時の見せ方．エンジニアリソースが貴重なので，少しずつしわ寄せが他のチームに行っている．主には会社の優先度に沿って実装していくけど，ともすれば気まぐれであれはしないこれはする，優先度もわかりにくいようにみえる (のではないかなあ)

社内周りから見るとエンジニアチームは恵まれている．ただ，スタートアップなので開発ばっかりしていればいいかというとそうではないので難しいところもある． やることめちゃめちゃふえると，やらされてる感もある．自分でやってる感大切．

まとめ

書いてて思ったのは，創業者二人がエンジニアチームのことを理解はしていてエンジニアチームの成果にはコミットしているけど，エンジニアチームのあり方にはコミットしていないので，チームとしてどうありたいの，みたいなのをチーム内でもチーム外にも模索していく必要があるなあと思いました．

こんにちは。kei-s です。当ブログやっと二人目の執筆者です。

先日 Kuniaki.rb というイベントの第一回が開かれ、 そこで Spree のモデリングについて LT をしました。

(Spree とはなんぞや、などについては Sapporo RubyKaigi 2012 で発表した資料をご覧ください。 https://speakerdeck.com/kei_s/ruby-on-rails-and-spree )

(スライドの途中から本題が始まります)

スライド中では、

• Product と Variant
• LineItem と InventoryUnit

という対比をしています。 前者の組は、サイト上に掲載する商品に関するモデルです。後者の組は、注文されたアイテムに関するモデルです。 詳しいことはスライドに図示しているので、そちらを見てみてください。

Spree の日本語情報はあまり無いので、第二弾ができるといいなあと思っています。

こんにちは。さねまつです。弊社サービスで一番大きいのはspreeを使ったアプリケーションです。

それ以外に、sinatraで商品画像確認・rails4でデータ周りを扱うなどの衛星アプリがあります。まだ一つの巨大なアプリでギリギリまかないきれる感じですね。まかないきれてるのかな。いつかはSOA。

see: I-Tier: Dismantling the Monoliths – Groupon Engineering Blog

一番大きいアプリケーションのrake stats:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ bundle exec rake stats
+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |  4393 |  3456 |      58 |     396 |   6 |     6 |
| Helpers              |   925 |   720 |       0 |      87 |   0 |     6 |
| Models               |  8680 |  6763 |     189 |     789 |   4 |     6 |
| Libraries            |  9723 |  8065 |     118 |     409 |   3 |    17 |
| Controller specs     |  1207 |   985 |       0 |       1 |   0 |   983 |
| Feature specs        |  6177 |  4627 |       0 |       5 |   0 |   923 |
| Helper specs         |   398 |   351 |       0 |       0 |   0 |     0 |
| Lib specs            |  1182 |  1005 |       0 |       0 |   0 |     0 |
| Model specs          | 12829 | 10834 |       0 |      23 |   0 |   469 |
| Routing specs        |    13 |    11 |       0 |       0 |   0 |     0 |
| Service specs        |  1508 |  1283 |       0 |       0 |   0 |     0 |
| Validator specs      |    50 |    44 |       0 |       0 |   0 |     0 |
| View specs           |   119 |    89 |       0 |       0 |   0 |     0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                | 47204 | 38233 |     365 |    1710 |   4 |    20 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 19004     Test LOC: 19229     Code to Test Ratio: 1:1.0
$ date
2013年 11月19日 火曜日 13時21分26秒 JST

see: 求人の際に「自社のコードベースがどれくらい健全か」というのをアピールする視点を持つとよいのではないか、と思いました。 – Sooey

いや、一番大きいコードベースはWordPressな気もする… メガネスタイルマガジンOMG PRESS

1
2
3
4
5
6
7
8
9

# wordpress-3.7.1-ja
$ find . -type f | xargs cat | wc -l
  338509
# spree master
$ find . -type f | xargs cat | wc -l
  224648
# omg-mono-app master
$ find . -type f | xargs cat | wc -l
  656648

そんなことはなかった。

こんにちは。さねまつです。ギョームのpull requestを思い出しつつ書いてみた。

contribution事例

kei-s

• Fix transration in ja spree/spree_i18n

日本語化だ。

• Fix for Passenger version 4 barttenbrinke/munin-plugins-rails

passenger v4対応。バージョン上げたらフォーマット変わってmuninで取れなくなった。

libkazz

• Html with microdata, for google SEO zachinglis/crummy

パンくずリストのmicrodata対応。

fukajun

:)

sanemat

• Require version file for checking capistrano version bundler/bundler

バグ修正。bundle —jobs=4 の並列bundle使いたかった。 deploy用のserverにbundler v1.4.0.pre.2 入れた。 そしたらcap deployできなくなった。 1.4.0.rc.1で直ってます!

• Use line_item price instead of variant price in return_authorization spree/spree

バグ修正。 一度閉じられたけど食い下がって説明して取り込んでもらった。

おわり

バグ修正は踏んだからだけなので、普通だナー。

Answer: そうでもない

こんにちは。さねまつです。オーマイグラスのメガネエンジニアです。

オーマイグラス株式会社

やりたいこといっぱいあるのでエンジニア募集してます。We’re Hiring!

技術要素

1
2
3
4
5
6
7
8
9
10
11

URL：http://www.ohmyglasses.jp
サービス名：メガネ通販 Oh My Glasses
プログラミング言語：Ruby 2.0, JavaScript
フレームワーク：Ruby on Rails 3.2, Spree
インフラ：Amazon EC2
WEBサーバ：Nginx
アプリケーションサーバ：Apache, Passenger
プロキシサーバ：
サーバOS：Ubuntu
DB：Amazon RDS(MySQL), Amazon ElastiCache(Memcached)
各種ツール：Pivotal Tracker, GitHub, Travis CI, Jenkins, HipChat, Yammer,

国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 | Find Job ! Startup

王道構成です。Chef, Vagrantをチームとしては使っていないので、一世代遅れ(?)かもしれない。

コンプリートコントロール

コンプリートコントロールです。

事業を作る

Q: エンジニアの役割、だいたいwebできちゃったら、定期的な特集コンテンツや、セールぐらいしかなくなるのでは?

A: そうでもない

やっていることはwebサイト制作ではなく、事業を作っています。ジギョつくです。

想像

webで売る→おわり

実際

卸から仕入れ(買い取り、委託)→受発注→入庫→webで選ぶ→問い合わせなどカスタマーサポート→5本お試し配送→お試し→返送→着荷→レンズ加工→配送→提携店舗→アフターサービス→請求書など→会計→おわり

全部自社で持っています。プライベートブランドもあります、社内にメガネ加工のプロフェッショナル雇っている、物流のプロフェッショナルもいるので、全部にシナジーが効きます。メガネ加工の専門学校があるって知ってた? 俺は知らなかった。webって一部だ。

具体例

• システムにほぼ載せずにスタート
  • eg. 遠近両用レンズ お問い合わせベースでスタート中
• いい意味のハリボテで出して、知見がたまったらリファクタリング
  • eg. お試しカートと購入カート 2013-04, リファクタリング 2013-08
• やってみたら選択と集中的に違ったわー
  • eg. 楽天出店 2012-12, 一時引き上げ 2013-06

なぜなら

• システムにあまり載せずにハリボテで出す
• そもそもビジネスになるの?などやってみないとわからない
• リーーーーーーン
• 仕入れ、配送、会計、ブログなどギョウミーな部分が宝の山で残ってる

それおもしろいの?

• ユーザー軸での串刺しカスタマーサポート統合やユーザー体験の向上 おもしろい
• 仕入れとか会計とか頭に乗っかってなくてあんまり面白くなかった(現時点 実績ベース)

やるべきこと, やりたいこと

• 二年ぐらいはルーチンワークにならないやるべきことがいっぱいありそう
• 右肩上がりだけど、骨組み太くしていくだけだと階段状に底上げされないので、エンジニアリングでなんかしなくては
  • = エンジニアリングで革命出来る余地がある
  • 具体的に何かはまだワカンネ

ヤバイところから継ぎ接ぎにしていく

継ぎ接ぎなんだけど、数年後の完成形に向けてバランスよくしていく

Q: エンジニアの役割、だいたいwebできちゃったら、定期的な特集コンテンツや、セールぐらいしかなくなるのでは?

A: そうでもない We’re Hiring!