はてなブックマーク

弊社Slackには、 #salad という社員のサラダの注文を管理運用するチャンネルが存在する。このチャンネルでは主にBROS TOKYOというフィットネスラウンジで月額契約している人を対象としたサラダの注文を管理運用している。 1ヶ月契約して毎日食べ続けると800円弱というお手頃価格で結構ボリュームのあるサラダを頼めて、好きなトッピングを3点選べて、体にも良いのでオススメだ。ちなみに私は契約していない。 今回はこのSlackチャンネルの運用についてお話したいと思う。 注文フローの確立まず運用を開始するにあたって、注文フローを確立しなければならない。そこで以下の内容が確立された。 ・以下のフォーマットで書き込むこと: [注文番号, 受取予定時間, 注文内容] ・12:30までに注文完了すること ・全員が注文を終えた後でランダムで1人が全員のサラダを取りに行く それに伴い、注文フローは初日に

MNTSQ社でソフトウェアエンジニアをやっております西村と申します。 弊noteへのご来訪まことにありがとうございます。 本日は弊社の開発環境をご紹介いたします。 開発言語弊社では基盤部分をRuby on Railsで開発しております。一部、OCR処理は都合でJavaを利用したり、機械学習はPythonが得意ですのでPythonを利用しております。 レビュー環境 リリースブランチや開発ブランチへの直接プッシュは禁止しております。GitHubでブランチを保護する方法につきましては、以下の記事などをご参考ください。 [GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | Developers.IO リリースブランチや開発ブランチに変更を加えるには、Pull Requestを介して行います。Pull Requestのレビューは必須となっており、少なくとも一名が

こちらのURLで実践編を公開予定でしたが、noteの機能的に難しいようでしたので、新たに下記ノートにて公開しました。 興味のある方は、なにはともあれ、こちらのページからBOT API Trial Accountを取得しておいてください。 事前準備公開までの間、下記ノートを参考に開発環境を整えてください。細かく書いていますが、非常に簡単で手数も少ないです。 事実上無限にスケールLINE BOTに関しては早速下記のような設計上の課題が指摘されています。 大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ文中に書かれている通り、MQ系の非同期処理の仕組みを利用することがベストですが、非エンジニアにとって、求められる知識量が増えますし、労働集約的な管理コストも増加します。 Google App EngineにはTaskQueueというAPIが備わっており、シームレスにキューイングの

本稿は俗にいう「能書きは要らない」の能書きにあたる文章であり、以下のようなノートを公開するに至った背景事情の説明です。 典型的な失敗例サービスを立ち上げたら思いのほか話題となりアクセスが集中。サーバが落ちてしまい、当初の勢いは持続せず。そうこうしているうちに大手ベンチャーから類似サービスがリリースされ、VCと交渉していた資金調達も失敗。手詰まり。 本シリーズの狙いまず、インターネット黎明期であればともかく、解決手段がいくらでもある現在においても上記のような事例が後を絶たないことに対しての個人的苛立ちがあります。 経営者も技術者も愚昧であった場合、上記のような事例に対して同情の余地はありません。しかしながら、当たるサービスを企画できる経営者のレベルに技術者のレベルが追いついていないというケースも多いのではないでしょうか。 現在、ヤフーに取り上げられようが、テレビで取り上げられようが、ほぼ落ち