タグ

developmentとdeveloperに関するluccafortのブックマーク (4)

  • スタートアップでのプロダクト開発はRailsで必要十分

    僕と共同創業者のSuinは2013年に起業してShouldBeeというプロダクトをPHPで作りはじめた。 起業する前にプロトタイプをPHPで1〜2週間程で開発し簡単なセールスを行ない1件の受注を獲得した。これはよい感触だと感じSuin氏を誘い起業に乗り出した。 その後もプロダクト開発はPHPで行っていたが当時はPHPに不満を感じていた。そのころの僕達は顧客数が伸び悩む原因をプロダクトの機能不足や開発速度が遅いからだと考えてしまった。後にこれはまったく検討違いな判断だったと気がつく。 格的に顧客がつき、たくさんの利用がはじまるとPHPで作られたこのプロトタイプではフィードバックにすばやく対応できないことや、自分達のモチベーションのためにならないと考えScalaでの全面的なフルスクラッチを実施することを決定してしまった。バックエンドはScalaで記述し、フロントエンドReact+Redux

    luccafort
    luccafort 2018/04/03
    スタートアップ、とにかく早くリリースするというのが第一義であって技術的課題は最悪後回しにしてでもMVPに徹するべきというのわかるんだけど現実にそれを行える自信がない。
  • 社内障害情報共有のススメ - Hatena Developer Blog

    こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。 障害情報を社内共有する理由 サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。 障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。 そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために

    社内障害情報共有のススメ - Hatena Developer Blog
    luccafort
    luccafort 2018/02/23
    過去に起こった障害とその対応ってぼくはものすごく大事な資産だと思ってるのでめちゃくちゃわかる。当たり前のことなんだけど意外とこれがきちんと出来てるところは少ないんですよね。
  • シドニーの会社から仕事の相談が来た

    働きたくない自分はフリーランスをしつつ脱受託を目指してMarkdownエディタアプリを作ったりしている。兼ねてから海外仕事が欲しくて、ロンドンに旅行した際に現地のミートアップでライトニングトークをしたりと地道に活動をしている。アプリのマーケティングも兼ねて書いている英語ブログは、先日書いた記事がバズって1700ものclapsを獲得した。そんな折に、オーストラリアの会社からお声がかかった。その経緯と自分の取っている戦略について書きたい。 概要海外仕事は自己投資・さらなる刺激・報酬アップが狙い相談主は自分のアプリのユーザさんだったブログは効果的な営業活動人の紹介はリスク回避の効果がある求人サイトは基的に不利プラットフォームに自分を埋もれさせないための戦略自己投資・さらなる刺激・報酬アップが狙いまず、海外仕事を取りたい理由は主に以下の3つ: 英語レベルを上げたい面白い事がしたい報酬を上げ

    シドニーの会社から仕事の相談が来た
    luccafort
    luccafort 2017/09/24
    非常によい知見。やっていることは「まあそうだよね」という話なんだけどこれに海外、英語となると中々情報が少ないので有用。
  • 「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog

    はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機

    「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
    luccafort
    luccafort 2017/08/08
    例えばA機能を実装しようとしたときに先にB機能を実装したことでA機能の意味がほぼなくなってしまってissue自体をCloseされたら場合各実装をrevertしていくのだろうか?あと入れ替えミスとかが怖い。
  • 1