久々に sinatra app を作った - id:onk のはてなブログ
「いつもの」が結構ありそうなので書いておく。 app.rb ペラ 1 でツラくなったときの対策はだいたい sonots パイセンの ちっちゃくはじめておっきく育てる sinatra アプリの作り方 に書いてあって、これは今でも有効なので読んでおくと良いです。 ディレクトリ構成 REPO ├── app.rb ├── bin/ ├── config/ │ ├── database.yml │ ├── initializers/ │ └── locales/ ├── config.ru ├── Gemfile ├── Gemfile.lock ├── helpers/ ├── models/ ├── public/ └── views/ sinatra らしさをなるべく残してある 例えば config/boot.rb を用意するかは非常に悩んだのだけれど、起点は app.rb であって欲しい
チームに浸透させるのが近年では難しくなっている - id:onk のはてなブログ
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
AWS Lambda でコンテナに入れた Sinatra を動かす - id:onk のはてなブログ
何番煎じか分からないけど、最近やったので。 前提知識 AWS Lambda + Amazon API Gateway で HTTP リクエストを受け付けることができる AWS Lambda ではコンテナイメージを動かせる New for AWS Lambda – Container Image Support | AWS News Blog AWS Lambda で Sinatra アプリを動かすための公式サンプルがある https://github.com/aws-samples/serverless-sinatra-sample つまりコンテナ化した Sinatra アプリを Lambda 上にデプロイして HTTP リクエストを受け付けることができる。 動かす準備はもう全部整っていて、お手軽そうですね。 Ruby アプリを Lambda で動かすコンテナイメージを作る Sinatra
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
