Wantedlyは、運命のチームや仕事に出会えたり、人脈を広げ、ビジネスの情報収集に使えるビジネスSNSです。
![Wantedly(ウォンテッドリー)はたらくを面白くするビジネスSNS](https://cdn-ak-scissors.b.st-hatena.com/image/square/0cedd53b3265824d8da9f51471f395435d23df96/height=288;version=1;width=512/https%3A%2F%2Fwantedly-assets.wantedly.com%2Fstatic%2Fvisit%2Fog_images%2Fog-com.jpg)
Wantedly インフラチームエンジニアの藤田 (@dtan4) です。今回は、社内で運用している PaaS である Paus の紹介をします。 社内 PaaS の必要性Wantedly ではデプロイ環境として本番環境とステージング環境が用意されていました。ここで、エンジニアが増えるに連れステージング環境の順番待ちが起こるようになってきました。原則として、フィーチャブランチはステージング環境で動作確認をした後本番環境にデプロイすることになっています。そのため、ステージング環境での確認が遅れることは新機能 / 修正のリリース速度低下につながっていました。 また、新サービスを開発する際の動作基盤構築にかかる工数も問題になってきました。従来だと新しいサービス向けの動作基盤を構築するのに丸1日費やしていました。これはリリース前の検証環境においても同様です。このため、メインサービスの www.wa
こんにちは、WantedlyのWebエンジニアの高松です。 このエンジニアブログでも何度かReact関連の話題が出ていますが、WantedlyではReact + Reduxを中心としたWebフロントエンドの技術スタックを導入して開発しています。 今回はスタックの導入方法や勘所について、詳しく解説してみたいと思います。特に既存のRails環境にReactなどの導入を検討していらっしゃる方の参考になれば、と思います。 今回の内容は以前発表した以下のスライドを元にしています。 これまでのWantedlyのフロントエンド開発 まず、今回のスタック導入前のWantedlyのフロントエンド開発がどのようなものであったのかについてご説明します。 Wantedlyの開発リポジトリを参照すると、最初のコミットは2011年9月になっています。現在は社内でもマイクロサービス化の動きが始まっていますが、基本的にW
はじめまして、WantedlyのユーザグロースチームでAndroid開発をしている 吉岡といいます。 今年の4月に新卒入社しまして、インターンだった頃は� ビジネスメッセンジャーのSync を、そして今は Wantedlyの会社訪問アプリ および 就活インターンアプリ を開発しております。 まれに勉強会などにも出没しますので、どうぞよろしくお願いします。 さて、Wantedlyのプロダクトづくりを象徴する「ディレクターの居ないチーム」。 トップダウン的に愚直にコードを書くのではなく、プロダクトに関わるエンジニア一人ひとりが 課題を見つけ、アプローチを考え、実装し、検証までを行うことが求められます。 グロースハックを成功させるため、Android版は 毎週1回リリース というとんでもなく早いサイクルを設定しています。そしてこのサイクルを実現するため、4月から 継続的に開発方式を見なおしていま
ユーザファーストと聞いて、何を思い浮かべるだろうか?よく、ユーザの声をしっかり聞いていないからユーザファーストではないとか、顧客第一ではない、なんて話を聞くけど、それは全くのナンセンスだ。 ユーザは自分のほしいモノはわかっていないし、無責任まず大前提として、ユーザは自分がほしいものは分かっていない。いくらグループインタビューを重ねても、そこからipodは生まれなかっただろうし、Appleもユーザヒアリングはしないことで有名だ。それから、ユーザに「このボタンの位置についてどう思いますか?」と問われれば、「そうですね、もっと右にあったほうがいいと思います」と、意見を言わないと!いう善意から、責任も伴わない思いつきの意見をどんどんいう。だから、ユーザに「どう思うか」と聞くのは愚の骨頂だ。 長期的視点と短期的視点それから、ユーザファーストという時に、それはユーザにとって短期的にいいものか、長期的に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く