現在、フルスタックエンジニアを目指して、勉強の日々を送っています。ちなみに、フルスタックエンジニアについて世間ではいろいろと定義されていそうですが、個人的には「幅広い知識と、複数の得意分野をもっているエンジニア」のことだと認識しています。
「おすすめの本やコンテンツがあったら教えてください!」とチームチャットでお願いしてみたところ、kei-sさんの「(みなさん出番ですよ)」という心の声が聞こえたのか、弊社のエンジニアや、お手伝い頂いているフリーランスの方々から、怒濤のレコメンドをして頂けました(本当にありがとうございます!)
数で言うと、30冊と87コース(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 |
Computer Science(Software Engineering・Systems&Security・Theory 計85コース ) | |
Functional Programming Principles in Scala |
いやはや、勉強あるのみですね。 知識の吸収とその実践を繰り返しながら、これから着実に成長していきたいです。
]]>今hubot-script
ブームが社内でぼくと1syoだけに吹いてます。さらに、「そろそろちゃんとした使えるものを作ってよ(1syo)」と煽られてます。
たしかに!! しかも一番使えるゴミ収集情報botは勝手にページスクレイピングしてて怒られるやつだ。まだまだ作るぞ。
最近、エンジニアチャットをhipchatからslack(+hubot)に変えました。
slackのintegration課金をひとまずすり抜けようと、通知系をhubotに集約してます。 github, hubot, newrelicの3本に抑えてる。 さてslackの課金体型変わったらどうしよ?
以上デース
]]>先日 Tokyo Rubyist Meetup で開催された eコマースとRails – Spreeの全て というイベントに登壇しました。 そこで、サービスで Spree をどのように利用しているかについて20分ほどお話ししました。
Spree とはなんぞや、などについては過去に発表した資料をご覧ください。
スライド中では、なぜ Spree を選んだのか、Spree の良いところ悪いところ、カスタマイズの方法などを説明しています。
今回 Tokyo Rubyist Meetup に登壇して、日本には Spree に興味がある方が思った以上にいたことに驚きました! まだまだ日本での導入事例が少ないなか、知見を共有できて嬉しいです。
また、一緒に登壇した Degica の @shioyama さんと発表前とお話しして、実際に Spree を使っている方と情報交換でき、とても勉強になりました。
登壇をお誘いしていただいた Tokyo Rubyist Meetup 主催の @pwim さん、ありがとうございました!
]]>Growth Hackingチームは自分一人がフルコミットで、あとはデザイナーが週に1日分ぐらい時間を割いています。
自分で立てた目標数値を達成出来ていない。
大きく目標は、サイト全体のコンバージョンレートに置いた。
スタートにあたって重たい順に倒していくことにした。商材のリピート間隔と、リピート率と、から言うと”現時点では”重たいのがそこだったので。
仮説立てるのに必要なだけの数字継続的に計測できるようにする。
数字計測して課題となるポイントを洗い出す。
課題に対して仮説を出して、効果とコストを見積もる。
効果とコストからスコアを計算して、スコアの高い順に着手。
自分一人でやって、半日や一日で終わらないストーリーはやらない。
入れてく策はoptimizely上で対照実験しながら入れていく。この辺は普通のA/Bテスト。
optimizely上だけでjQuery書いて差し替える場合と、コードベースに片方display: none;
で突っ込んでoptimizely上でdisplay: block
に書き換える場合がある。
一定数の効果が見られる流入を与えて、勝者が出たらviewにちょろちょろっと書いてたcssやjavascriptをあるべき場所に書き直す。
俺のバリューってoptimizely上でちょろっとjQuery書くそれなの?って思うとアレ?って気がしないでもない。
こんなの。
1 2 3 |
|
結果が出てればいいんだけど、全体的な要因で伸びてる以外は誤差レベルなので、growth hackingやってます!って言いたいだけになってる。
マズイ。
A/Bテストどんどんやっていこう!と思ってたけど、なかなか進まなかった。 数字の根拠が足りなくて説明できないことが多かった。
もやっとしてた。「グロースハッカー」読んでたらいい定義があった。
グロースハッカーはマーケターとエンジニアのハイブリッド – ライアン・ホリデイ『グロースハッカー』
なるほど! マーケティング!? マーケターだったのか俺は。 定義でもやもやが解決するってのはそんなこと無いんだけど、ちょっと進んだ。もうちょっとエンジニアタスクに時間割ければ色々出来そうな気がしてたのに、数字計測したり根拠考えたりばっかりしててどうなるんだろう、って思うこともあったけどマーケターなら仕方ないな。
GrowthHackにおいて一番大事なこと | symsonic
facebook: 10日以内に7人以上の友人と友達になる割合をKPI
とかairbnbでプロのカメラマンに部屋の写真を撮ってもらうとかそういうキラーKPI見つけるしないと。
ぼくがabテストを一番うまく扱えるんだ!ex-zyngaですし
マーケターやデータマイナーっぽい意識を持ってるとちょうどいいのかも。
一緒にGrowth Hackingやりたい人募集!
事業を育てるぞ。
]]>カラーとモノクロをtoggleするbookmarklet書きました。toggle-monochrome
なるほど〜ってなっただけでそんなになかった。既にちゃんと考えられている!
generater-bookmarkletがgruntからgulpになってておっってなった。
そしてドヤ顔で同僚に見せに行ったら「アクセシビリティーチェックのそういう拡張あるよ」って教えてもらいました!!なるほど!そっちを使ったらいいと思います。
以上デース
]]>挙げるほどのメリットもデメリットもなかった.あと,書き出してみたらだいぶひとによってしまった.うっ.
オーマイグラスだと清川がオペレーション,バイイングを見ている.六人部が開発,サービス側を見ている. 六人部はアジャイルサムライでいう「荒ぶる四天王: 時間、予算、品質、スコープ」の話を知っていてまあ調整するならスコープだよね,というのを頭では理解してくれている.やりやすい.常にそうかって言うとそうでもない.もちろん,「とはいえ」みたいなことはある.やっぱりビジネスだし.ある程度は仕方ない.あとgithub issueでやりとりできるから楽.
特に清川はシステムに対しては一歩引いてみている.ただ,やっつけで組み込むべきところとシステムにちゃんと載せるときの区別はしっかりしている.
「それスケールするの?」は前何度か聞かれた.根性でなんとかなるところとそうじゃないところ,再現しないところに注意を向けてくれる.
エンジニアチームで最近話しているのは,エンジニアチームを社内周りから見た時の見せ方.エンジニアリソースが貴重なので,少しずつしわ寄せが他のチームに行っている.主には会社の優先度に沿って実装していくけど,ともすれば気まぐれであれはしないこれはする,優先度もわかりにくいようにみえる (のではないかなあ)
社内周りから見るとエンジニアチームは恵まれている.ただ,スタートアップなので開発ばっかりしていればいいかというとそうではないので難しいところもある. やることめちゃめちゃふえると,やらされてる感もある.自分でやってる感大切.
書いてて思ったのは,創業者二人がエンジニアチームのことを理解はしていてエンジニアチームの成果にはコミットしているけど,エンジニアチームのあり方にはコミットしていないので,チームとしてどうありたいの,みたいなのをチーム内でもチーム外にも模索していく必要があるなあと思いました.
]]>先日 Kuniaki.rb というイベントの第一回が開かれ、 そこで Spree のモデリングについて LT をしました。
(Spree とはなんぞや、などについては Sapporo RubyKaigi 2012 で発表した資料をご覧ください。 https://speakerdeck.com/kei_s/ruby-on-rails-and-spree )
(スライドの途中から本題が始まります)
スライド中では、
Product
と Variant
LineItem
と InventoryUnit
という対比をしています。 前者の組は、サイト上に掲載する商品に関するモデルです。後者の組は、注文されたアイテムに関するモデルです。 詳しいことはスライドに図示しているので、そちらを見てみてください。
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 |
|
see: 求人の際に「自社のコードベースがどれくらい健全か」というのをアピールする視点を持つとよいのではないか、と思いました。 – Sooey
いや、一番大きいコードベースはWordPressな気もする… メガネスタイルマガジンOMG PRESS
1 2 3 4 5 6 7 8 9 |
|
そんなことはなかった。
]]>日本語化だ。
passenger v4対応。バージョン上げたらフォーマット変わってmuninで取れなくなった。
パンくずリストのmicrodata対応。
:)
バグ修正。bundle —jobs=4 の並列bundle使いたかった。 deploy用のserverにbundler v1.4.0.pre.2 入れた。 そしたらcap deployできなくなった。 1.4.0.rc.1で直ってます!
バグ修正。 一度閉じられたけど食い下がって説明して取り込んでもらった。
バグ修正は踏んだからだけなので、普通だナー。
]]>こんにちは。さねまつです。オーマイグラスのメガネエンジニアです。
やりたいこといっぱいあるのでエンジニア募集してます。We’re Hiring!
1 2 3 4 5 6 7 8 9 10 11 |
|
国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 | Find Job ! Startup
王道構成です。Chef, Vagrantをチームとしては使っていないので、一世代遅れ(?)かもしれない。
コンプリートコントロールです。
Q: エンジニアの役割、だいたいwebできちゃったら、定期的な特集コンテンツや、セールぐらいしかなくなるのでは?
A: そうでもない
やっていることはwebサイト制作ではなく、事業を作っています。ジギョつくです。
webで売る→おわり
卸から仕入れ(買い取り、委託)→受発注→入庫→webで選ぶ→問い合わせなどカスタマーサポート→5本お試し配送→お試し→返送→着荷→レンズ加工→配送→提携店舗→アフターサービス→請求書など→会計→おわり
全部自社で持っています。プライベートブランドもあります、社内にメガネ加工のプロフェッショナル雇っている、物流のプロフェッショナルもいるので、全部にシナジーが効きます。メガネ加工の専門学校があるって知ってた? 俺は知らなかった。webって一部だ。
ヤバイところから継ぎ接ぎにしていく
継ぎ接ぎなんだけど、数年後の完成形に向けてバランスよくしていく
Q: エンジニアの役割、だいたいwebできちゃったら、定期的な特集コンテンツや、セールぐらいしかなくなるのでは?
A: そうでもない We’re Hiring!
]]>.travis.yml
のギャラリー作ってます。オーマイグラスの.travis.ymlはこんなかんじです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
サービスレベルで実運用してる.travis.yml
見たいですよね!!! 観測範囲だとこのぐらい。
他にもご存知でしたらpull requestください。 https://github.com/sanemat/soryu
以上デース
]]>Travis-CIでテストを落とした時に、capybaraか何かタイミングのせいで失敗した!(だからオレは悪くない!)と思い込めたら、歯車アイコンの’Restart Build’を選んでbuildを再キックします。
弊社オーマイグラスはprivate なreposもテストしたいので、Travis PRO使ってます。Restart Buildは、pro関係なく、自分にadmin権限あればrestartできます。権限足りないと押せないみたい。
なおcli clientからだと
$ travis restart 57.1
で実行できるらしい READMEより
pro関係あるのは、’feedback & support’ のtabです。ここからメッセージを送ると、サポート宛にチケットが切られて、メールでやりとりします。ぼくがオーマイグラスにJoinしてからの一年弱で2回(2012-12-25, 2013-01-30)問い合わせしてます。開発者がそのまま返事くれるので、伝言ゲームにならないのがよかったです(当時)。
タイミングで落ちるテストは近いうちに直します!!!
以上デース
]]>ローカルのcrontab, 特に管理してなくてうっかり消しました。
wheneverで書いてリポジトリ管理しておくとうれしいですね。
1 2 3 4 5 6 |
|
こんな感じ。sebastian
heroku エコシステム駆使するとか、空いてるサーバーにいれちゃうとか、ちょっと考えてめんどくさくなったのでローカルのまま運用してます。
どれ使ってもいいんじゃないでしょうか(未確認) https://www.hipchat.com/docs/api/libraries
pure rubyの使うと取り回し良さそうなのですが、ひとまずbash版で動いているのでほっといてます。パイプで動くとunixのテコの原理に載ってる気になれてよい。
1
|
|
設定管理は大げさじゃないのがいいなとdotenv使ってます。まあまあ便利。
see: The Ruby Toolbox – Configuration Management
朝会開始の時間に自分が出社してないと発言しないので、あれだ。可視化されますね。
以上デース
]]>商品情報簡単に編集できるといいね、ということでなかむらくんに通報するためのbookmarkletをいくつか作りました。
技術的にはYeomanでbookmarkletを作ってみた話です。もう少し細かく言うと、yoでbookmarklet用のtempleateをgenerateして、gruntで変更をwatch, 変更あったらminifyしてbookmarkletとして出力しています。変更をwatch~というのもgenerateしたtemplateに書いてあるので、やるのは grunt server
実行するだけです。
1 2 |
|
app/main.js を編集していくと保存するたびに dist/bookmarklet.js にbookmarkletを作成します。処理内容はgeneratorがGruntfile.js を生成していて、そこに書いてあります。
coffeescriptで書けたらいいなーというのはgruntfile書けば良さそうで、あとGruntfile自体もcoffeeで書けるそうだ(伝聞)。
こちらはリンクだけ。やりたいことを最短で満たしたしいいやこれで。
商品ページからjQueryで要素拾って、管理画面の対応するeditページをopen
編集ページのパーマリンクへリンクあり
before:
after:
ヤッター! (メールってフォーマットだるいですねというのはまた別のお話)
以上デース
]]>