ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
ポータブルなwebアプリケーションとそのインフラの未来の一考
naoya さんのポータブルな Web アプリケーションを受けて最近思ってることをば。140 文字で時々書いてるんだけど、まとまりがないので一回まとめておきます。 12-factor app ステートフルなアプリケーションについては、Heroku の人が提唱してる 12-factor app というのが現在の状況をよく表してます。 The Twelve-Factor App The Twelve-Factor App（日本語訳） Heroku や他の PaaS によってもたらされたこうした一種の”制約”によって、アプリケーションの新しいカタチが生まれてきています。引き算によって新しい価値が生まれてきているわけですね。 とはいえ、PaaS は PaaS でそれぞれに独自の仕様を持っているわけですが、Heroku の buildpack という仕組みを使って、Heroku とインタフェース仕様
フラットにするより組織図を反転すればよいのではないかという考え方 - ワザノバ | wazanova
http://6brand.com/the-upside-down-org-chart.html これまで、GitHub、Valve、Treehouseなど、フラットでマネージャのいない自己管理型の会社を紹介してきましたが、今回SquareのJack Dangerは自らのブログで、伝統的な組織図を反転させた発想での会社運営を提案してます。 1) 伝統的な組織図 トップダウン型のこの組織図は、エンジニアが大会社で働きたくないという要因になっている。「仕事がイヤだから辞めるのでなく、ボスがイヤだからやめる。」と言われるように、ベテランのエンジニアを引き止めるためだけに「昇進」させ、質の悪いマネジャーを生んでいるテク企業も多い。また、マネージャーは（よい人であっても）階層のある組織にいると配下にネガティブなプレッシャーをかける傾向を指摘されている。 一方、自己管理型のフラット組織は、多少の組織内
Pythonが大好きな女子大生がGoogleSWEインターンに参加するまでの話 - ぴよぴよ.py
PythonといえばGoogle!! (? そんなわけで先週末まで、 Googleのソフトウェアエンジニア(SWE)インターンに参加してきました。 本当は参加した内容について書きたいのですが、 どこまで話していいのかわからないので、 参加するまでの話をメインで書こうかと思います。 昨年の春まではオブジェクト指向が何かさえ知らなかった 一応プログラムを書くのアルバイトをしてたにもかかわらず、 適当に書いてました。('ω`) ひどい話です。 そんなレベルのプログラマーでした。 昨年はGoogleBOLDインターンに参加 昨年はGoogleBOLDインターンに参加させていただきました。 BOLDインターンは学部女性や障がいのある方を対象としたインターン。 SWEインターンに比べるとかなりゆるいインターンですが、 プログラミングが大好きな多くの女子大生と知り会うことができ、 とても貴重な体験でした
Facebookの継続的デプロイメント - ワザノバ | wazanova
https://www.facebook.com/publications/514128035341603/ 1日500件、3,000ファイルに及ぶ本番アップ フロントエンドのコードは1050万行、内850万行がPHP 開発エンジニア1,000名とリリースエンジニア3名 QAやテスターは存在しない 自分でプロジェクトを選ぶ & 自己責任のカルチャーが強い。 1/3のファイルが一人のエンジニア、1/4が二人のエンジニアでメンテされている。 フロントエンドの本番コードベースは一つのものを共有 日常業務ではローカルのgitを利用。本番アップ可能になれば、中央のレポジトリにマージして、それからSubversion（過去の経緯で使っている。）にコミットする 同じエンジニアがコードをコミットする間隔は中央値で10時間 本番にプッシュする前に、担当エンジニア自身でのユニットテストを終え、同僚によるコード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
