Quipper組織変更と41歳CTOの今後 - Masatomo Nakano Blog
最近、自分自身に関わる人事で大きな変更があった。久しぶりにブログを書いてみる。 結論から言うと、先月まで、プロダクト、開発組織、技術の3つを担当していたのだが、プロダクトと開発組織を完全に移譲することになった。 その結果、自分のレポートラインとしては移譲した人だけが部下という形になった。Quipperを始めた6年半前、最初のエンジニアに入ってもらって以来の少なさだ。これは自分としてはなかなか大きな変化である。 振り返ってみると、Quipperが始まってから6年半、Web/アプリ事業会社のCo-founder/CTO としてありがちなコースを歩んできた(最初はタイトル的にはCTOではなかったけど)。初期はとにかくコードを自分でがりがり書き、サーバーの面倒も見るし、とにかく何でもやるエンジニア。そして組織の拡大とともに段々とコードを書く時間が減っていくというやつだ。 特にリクルートグループ入り
Quipper買収されてました - Masatomo Nakano Blog
元DeNA創業メンバーの渡辺氏が創業した「Quipper」をリクルートが約48億円で買収、現状と今後の狙いを聞いた このこと自体を決断したのはそれなりに前なので、自分の中では今更な感じがありつつも、大きく取り上げられると、やっぱりなかなか感慨深いものがある。 みんなもなんか書いてるし、せっかくのタイミングなので、自分も何か買収される側の変化みたいなものを書こうと思って書き始めてみたのだけど、そこまで大きな変化みたいなものがなかったことに気づいた。というのも買収後、元々Quipperがやっていたこと/やりたかったことの方向性が変わったわけでもなく、ただその方向を強く加速してもらっているという感じなので、とても自然に進んでいる。 上の記事の中でCEOである渡辺さんがモビルスーツという喩えを使っているがまさにそんな感じ(モビルスーツ本当はよく知らないので雰囲気で！)。うまく、PMI(post-m
Quipper現在の状況と積極採用中について - Masatomo Nakano Blog
ここ1、2年、東京オフィスでは積極採用をしていなかったのだが、事業拡大につき積極的な採用を再開している。表に出している公式の求人情報とは別の角度でQuipperとはどういう会社で、どういう人を求めているのか、みたいなことを書いてみることにした。 Quipperの今までと現在の状況 Quipper、創業5年目に入ったところ。最初の3年間はピボットの連続で、教育周りでいろいろなことをやってきたが、3年目の終わりくらいからサービスを絞り、成長フェーズに入っている。スタートアップ初期の荒波、生きるか死ぬかみたいなフェーズは終わっている感じだと思う。そこを楽しんでみたいと言う人にはちょっと遅いかもしれない。今はその次の成長フェーズで、そこを楽しみたい人にはぴったりのタイミング。初期の荒波は、それはそれで正直楽しいのだけど、落ち着いてプロダクト/サービスに集中し良いものを作る！というのは今のフェーズだ
リリース力 - Masatomo Nakano Blog
って、大事だなーと思っていてエンジニアの力の差が大きく出るところだと思っている。 新規サービス 新規アプリ ちょっとした社内ツール プロジェクトの進め方の改善 大き目のリファクタリング とかなんでも、とりあえず始めることは簡単だ。ただ、それを形にしてリリースしたり継続するのは難しい。 データベースのマイグレーションが必要だったり、最後の細かいUI調整もなかなか時間がかかる。色々な環境でのテストも必要だ。 技術的以外な部分でも、関係者との調整や、ユーザーへのお知らせ、面倒なことが多い。 開発者なら誰でも実感値あると思うけど「だいたいできた」から「リリース」までの距離はだいぶ遠い。自分の感覚としては「だいたいできた」で良くて半分くらい。楽しいのも最初の半分、後半は楽しくないことが多い。飽きも来る。 (これらの面倒なことを減らすのが、Quipper CTOである自分の役目だとも思っている、がそれ
resque-scheduler (resqueでcronみたいなことをする) - Masatomo Nakano Blog
resqueシリーズ。 前回 も resque-scheduler について少し触れたのだけど。resque-schedulerのメインであるcron的に使う機能について書いてなかったのでメモ。deployについても書いた。 cronと比較して *nix系のシステムだと、伝統的に、何かを定期的に実行したいcronを使うのだけど、アプリケーションからcronを使う場合、いくつかの使いづらい点がある。 アプリケーション本体から離れた場所でcronの動きを管理しないといけない。通常、/etc/crontab 等をメンテナンスしないといけないのだけど、そこはアプリケーションの外側なので、メンテナンスするときにアプリケーション側で使っている方法を使いづらい(SCMもそうだし、deployとかも別で考えないといけない)。 cronから起動する場合、起動する環境について考えないといけない。環境変数が代表
Rails 3 + mongoDB + HAML + Rspec + Jquery のインストール - 2 - Masatomo Nakano Blog
(2010-08-30: Rails 3.0.0がリリースされたのでそれにあわせて更新。generator関連が少し変わってる) 前回 の続き。 主に FactoryGirl と MongoMapper の話。基本的に何も考えなくてもそのまま使えるのだけど。 まず、設定。 spec_helper.rb で、 config.use_transactional_fixtures = true を config.use_transactional_fixtures = false にする。そうしないと、ActiveRecord::TestFixtures が呼ばれてしまうのだが、ActiveRecordを入れてないので落ちる。 そもそもMongoDBにはトランザクションとかないのでfalseでいい。 後は、ActiveRecordで使う場合と同じように、FactoryGirlの定義の読み込みを
Google App Engine / Python 上での開発で最初から知ってればよかった、ってことをいくつか - Masatomo Nakano Blog
ここ数ヶ月、Google App Engine/Pythonを使い、初めてちょっとしたものを作ってみているのだけど、開発初期から知っておけばよかったなー、と思うノウハウ/tips的なものをずらずらと書いてみる。 基本的な環境設定は、 以前書いた まま。 0. 公式ドキュメントを良く読む 言うまでもなく、だけど、 マニュアル はもちろん、 この辺 の下の読み物も、流し読みだけでもしておいたほうがいい。 datastoreとmodel的なところ 1. key nameを使いこなす key nameは、レコードの作成時に指定できる(RDBでいう)primary keyの別名みたいなもの。primary key自体は自動的で作成されるので開発者が指定できるのはkey nameだけ。 key nameをうまく使うことで、datastoreを使いやすくすることができる。特にdatastore上で"un
退職しました - Masatomo Nakano Blog
やめちゃった。 8年半前に創業直後だったこの会社に入って、ほぼ0から色々なものを作り、動かし、それなりに会社は大きくなり、立場的にもそれなりに偉くなり、給料もそれなりに貰って、居心地は悪くなくて、そうなんだけど、その一方で、自分にとって刺激は少なくなり、なんとなく楽しさが減っていた、という感じ。自分自身なんとなく安定してしまっている、という状況自体がなんとなく怖かったりもした。 それでも、暇なら色々と遊べるのだけど、日々やらないといけないことは全然減らなくて、忙しいんだけど何か刺激がない、みたいな悪い状態に陥っていた。 会社のことを考えてみても、多少老害になりそうな自分が辞めることで、新陳代謝したほうがいいのかなー、というのもある。よく知っているだけに思い切ったことができなくなっていることも多いし、なんとなく偉そうにしている自分も嫌だったりした。 前にも少し書いた ように基本的にいい会社に
Google App EngineとPythonでの素直な開発環境の構築(TDDができるように) - Masatomo Nakano Blog
追記: 続編的なものを書いた。 今年は色々なことに手を出してみよう、ってことで少し前からGoogle App Engine(以下GAE)で、あるモノを作っている。モノ自体は近いうちに公表できると思う。 基本的に、Pythonと標準っぽいフレームワークだけでやってみている。作っているものがそれなりにシンプルなのと(だからこそGAE!)、GAEでそれなりの規模の開発をするのが自分自身初めてということもあり、あまり色々なレイヤーを重ねて手こずりたくなかった、ってのがその理由。 ただ、GAE初心者なので、「いやいやそれは今時ないよ」「XXの方が100倍いい」とかあったら教えてくれると嬉しいので今のところの環境を書いておくことにした。今ならスイッチ可能。 今作っているものがJSONファイルを入出力するだけのものなので、HTML生成パートみたいのはない。 1. フレームワーク 上にも書いたように、今回
MongoDBドキュメント日本語訳一部完了のお知らせ - Masatomo Nakano Blog
ぼちぼち進めてきた MongoDB の日本語訳ですが、その中の大きなセクションの一つである Developer Zone の 翻訳 が完了しました。Developer Zone内のすべてのページは完全に英語版と同期しているはずです。 Developer Zoneとは このセクションでは、MongoDBの特徴、仕組み、基本的な操作、MongoDBを使ってアプリケーションを開発する開発者はどういうことに意識した方がいいのか、と言ったことが書かれています。 MongoDBで開発をする人はまず一読しておくべき内容です。 目次 チュートリアル マニュアル コネクション データベース コマンド データベースの複製 fsync コマンド インデックス関連コマンド Last Error コマンド Windows サービス 動作中の処理の参照と停止 Validate コマンド List of Databas
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
