Heroku を利用した Quipper の開発事例紹介Tech Compass Vol.6 “Love Heroku?” の発表資料です http://techcompass.jp/study/06/
Quipper で最初のリリースなので振り返る - @banyan's blog
5月に Quipper に入ってやっと最初のリリースが迎えられそうな中、チームのメンバー全員がなぜかブログを書き始めた。なんなのこれ... Quipper のスピード感 自分の強みを生かすこと on Quipper Github Issues を利用したリリースマネージャのお仕事 Quipperでのおじさんエンジニアの立ち位置 QuipperでHTML5アプリを作ってる話 Quipperのエンジニアのblog day（ステマじゃないよ） でも @banyan さんが日記書くまでは寝るわけにいかない。 — 北市真 (@KitaitiMakoto) October 22, 2013 同調圧力は見て見ぬふりをしてたけど、外部のブログ圧力に負け僕も書くことにします。 Pull Request の粒度 6月に最初は開発者4人でスタートして、8月に Android 開発者の @dagezi さん、9月
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
Quipper のスピード感 - @kyanny's blog
先日、ブログ記事を読んでいて autodoc というツールを見つけた。 Rails の Request Spec から自動的に API ドキュメントを生成するというもの。コードとドキュメントが食い違ってしまう問題を解決できるかも、と思って試しに Quipper 社内で紹介してみた。 当初は「良さそうだね、でも今使っている API サーバー用フレームワークでは使えないようだし、こまごまと不満もあるので、いずれ Rails に乗せかえるときにでも再検討しよう」なんていう反応を予想していた。自分の担当箇所でちょっと使うくらいが関の山だろうなと。しかしその予測は見事に外れた。 紹介した当日、我々が API サーバーを書くのに使っている grape という gem で autodoc を利用するのは骨が折れそうだということがわかる。にもかかわらず翌日、 API サーバーを Rails にマイグレーシ
Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
自分の強みを生かすこと on Quipper - mizchi's blog
今リリース前にしてはタスクがあんまりないのでブログ書いてみる。 Quipperに入社してから一ヶ月半ほど経過した。それで感じたことをあれこれ書いてみようと思う。 あんまり熱心に書くと前の会社に入ったばかりのことを思い出して恥ずかしくなったりするので、ほどほどにする。 エンジニア文化の共有 会社に入ってまず最初にやることは、エンジニアが文化を共有することだと思う。 どんなマインドかは、僕より Quipper のスピード感 - @kyanny's blog とかを読んだ方が伝わるはず。 QuipperはOSS文化というかRuby文化的なものを強く志向している感じがあって、そこらへん馴染みやすかった。 入社してからやったこと まず前提として、ベンチャーなので整った教育制度などはない。(そもそも自分も研修など期待していない)。 エンジニアとしての文化を共有しているから、最初からすぐ仕事に入れた。具
起業から2年半たち、Quipper学習プラットフォームが形になってきた | 戦略｜DIAMOND ハーバード・ビジネス・レビュー
DeNA共同創業者の渡辺雅之氏の連載5回目。Quipper設立から2年半がたち、ようやく事業のかたちが出来あがってきた。「プラットフォーム」という概念をつくるのは簡単だが、ゼロから作り上げるのはいかに難しいか。 Quipperは最初からプラットフォーム型のサービスを目指している。 つまり、学習コンテンツの「作り手」と「学び手」の双方を顧客として持ち、その中間に立って制作・配信・管理・課金などの各機能を提供する役割を担いたい。 プラットフォームはゼロから立ち上げるのが難しい業態である。コンテンツがなければ学び手を集められないし、学び手が集まっていないところにコンテンツの作り手も来ないからだ。この鶏と卵のような関係を上手に発展させ、良循環を実現しなければならない。 細分化された学習コンテンツを端から自力でつくっていくことが不可能な以上、幅広い「作り手」に利用してもらえるプラットフォームを目指す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
