The Modular Monolith: Rails Architecture
One of the hardest things about building a startup is handling the rapid growth in team and technology. The best way to build software with a team of three engineers is different than with ten engineers, or twenty, or fifty. Make a change to your process today, and you’re doing it too soon. Wait until tomorrow, and it feels too late. We’ve been mindful of this while building Root. When we started
個人で運用している Web サービスをどう管理しているか 2018年版 - r7kamura - Medium
個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。 実験には Heroku を利用習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。 メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる（昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほど
スタートアップでのプロダクト開発はRailsで必要十分
僕と共同創業者のSuinは2013年に起業してShouldBeeというプロダクトをPHPで作りはじめた。 起業する前にプロトタイプをPHPで1〜2週間程で開発し簡単なセールスを行ない1件の受注を獲得した。これはよい感触だと感じSuin氏を誘い起業に乗り出した。 その後もプロダクト開発はPHPで行っていたが当時はPHPに不満を感じていた。そのころの僕達は顧客数が伸び悩む原因をプロダクトの機能不足や開発速度が遅いからだと考えてしまった。後にこれはまったく検討違いな判断だったと気がつく。 本格的に顧客がつき、たくさんの利用がはじまるとPHPで作られたこのプロトタイプではフィードバックにすばやく対応できないことや、自分達のモチベーションのためにならないと考えScalaでの全面的なフルスクラッチを実施することを決定してしまった。バックエンドはScalaで記述し、フロントエンドはReact+Redux
Amazon Aurora
Amazon Auroraというクラウド上のRDBMSサービスがある。2015年の7月末にGAロウンチしたばかりのサービスだが、世界各国のユーザに非常に好評のようだ。 https://aws.amazon.com/rds/aurora/ Auroraをどう見るか、でクラウドの受け入れ度合いや現状の把握に使えると個人的には感じている。個人としてはAuroraほど画期的なサービスはDBでは今までなかったし、RDBMSの歴史の新しい1歩として認識している。ただあまりのシームレスさ、移行容易性、利用の簡便さに凄さに逆に気づきにくい状況がおきている。結果としてマーケティング的なムーブメントにはなりにくい状況で、個人としてはむしろそれが望ましいとも思っている。静かに深く世の中を変えていく、そんなサービスだ。ちなみにグローバルではOracleやSQL Serverからの移行が後を絶たない。理由の多くは、
プログラマの3大美徳と子育て — Medium
これを書いているのは12/21ですが、「子育てプログラマ・ITエンジニア・Webデザイナー Part 2 Advent Calendar 2015」でふと見たら間が抜けていたのでさっと12/9の分を埋めてみます。 私は3歳と2歳の二人の子供がいる、Web系システムのサーバー側を主に見ているプログラマです。普段の私の子育てに関しては以前書いたこちらの記事をどうぞ！ 俗にプログラマの３大美徳と言われるものがあります。「怠惰（laziness）」「短気（Impatience）」「傲慢（Hubris）」という一見逆説的な3種類の性質がそれぞれよりよいプログラマになるために役に立つ、というのです。 ざっくり言うと… 怠惰であれば「面倒だな」と思う事はどんどんプログラムを介してコンピューターにやらせるという方向にいくでしょう。短気であれば「良くない」と思った物に対してイライラして、改善を行おうとするで
社内なら謝らなくて良いカルチャー
社内で仕事をしているとき、指摘や指導をすることがあるが、まだうちのカルチャーに慣れていない人は、すぐに「すいません」と謝る。でも、それは良くないよ、と言っている。 仕事の仕方や成果物に対しての指摘というのは、別に悪いことをしたからな訳ではないのだから、謝る必要などない。私に謝って欲しくて指摘している訳ではないのだ。 謝るってことは、私を向いて仕事をしていることになる。それは良くない。仕事はあくまでユーザやお客さまを向いてするものだ。社内の人に向いて仕事をするのではない。 だから指摘に対して謝る必要はない。良い仕事をしてもらいたい、成長してもらいたいから指摘をしているのだ。社長の顔色なんて見なくていい。良い仕事をすればいい。 同じチームにいて、良い仕事をして、成長していきたいというベクトルがあっているなら、謝ることなんてないのだ。そういうカルチャーの会社であり続けたいと思っている。 もちろん
お値段28億ドル、Slack 「秘伝のタレ」
「で、Slack はどうしてあんなにうまくいってるの？何かしら特別なこと、したんでしょ？」車載の Bluetooth スピーカーから声が響く。「なんであれ、彼らにしたのと同じことをして欲しいんだ。」電話で話していたのは、見込みクライアントである有名 SaaS プロバイダーの CEO。自社製品デザインの見直しをうちに頼みたいらしい。上述のような質問を受けたので、これまでに数えきれないほど繰り返してきた説明を彼にもすることにした。 実際のところ、過去一年間、毎日この質問をクライアントや投資家、デザイナー仲間から受けてきた。みんな「Slack 大成功の秘密」をなんとか探ろうとしていたわけだ。Slack は今ではすっかり世間を取り込んでしまったかのように思える。評価額は圧巻の28億ドル、何十万ものユーザー数をほこり、常識はずれの速度で成長中だ。 Slack に関する質問がどうして僕のところに来るか
チャットを業務で運用する際の心がけ
エンジニアの職場でチャット（IRC, HipChat, Slack etc.）はごく自然な連絡ツールになっているだろうと想像しますが、僕のように非エンジニア社会で業務にチャットを取り入れようとするとそれなりの抵抗を受けます。 抵抗を示す人がチャットに慣れていない、あまり経験がないという場合もあれば、「どうせこんな感じでしょ」という少ない経験がそのすべてであると思い込んでしまうという人類全般に見られるあるある現象による場合もあるでしょうが、たしかにチャットを使えばすべて上手くいくなどということもなく、その意味でそうした思い込みも一概に間違っているとは言えず、他のさまざまなツールと同様にチャットもまた副作用的な問題を少なからず抱えているとは言えるわけですが、そのような事々もいくつかの点に注意を払っておけば大した問題ではなくなる、というのが僕の考えです。 もしエンジニアの職場でチャットが上手く使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://medium.com/how-to-create-startup/%E6%99%AE%E9%80%9A%E3%81%AE%E4%BA%BA%E3%81%A7%E3%82%82%E5%9B%9E%E3%81%9B%E3%82%8B%E4%BB%95%E7%B5%84%E3%81%BF-%E3%81%AA%E3%82%93%E3%81%A6%E4%BD%9C%E3%82%89%E3%81%AA%E3%81%84%E3%81%BB%E3%81%86%E3%81%8C%E3%81%84%E3%81