ブックマーク / www.hsbt.org (5)

  • rails の pull 型デプロイへの質問 - HsbtDiary(2015-10-22)

    rails の pull 型デプロイへの質問 昨日の発表直後は時間がなくて質問への受け答えがあまりできなかったんですが、発表後にぶらぶらしていた時にもらった質問が鋭い内容だったので紹介します。 No SSH ポリシーは反発もでたり、チームへの浸透は難しいのではないか minne チームは選任のインフラエンジニアがおらず、アプリケーションの開発チームが兼務してインフラを作っていたので、コードでインフラを作るというのはすんなりと受け入れられた(と思う) pull 型デプロイだと、更新漏れが起こったり、あるサーバーだけが調子わるくてデプロイが失敗したということが起こった時の検知が難しいと思うんですがどうやってますか その通りで問題は把握しているがまだ具体的な解決策は作れてない状態。デプロイ後にコードのリビジョンなどを kvs に突っ込んで、サーバーすべてが更新されたことを検知してアラート、と

    rails の pull 型デプロイへの質問 - HsbtDiary(2015-10-22)
    deeeet
    deeeet 2015/10/23
  • Hashicorp Product Meetup で発表してきた - HsbtDiary(2015-08-05)

    ■ Hashicorp Product Meetup で発表してきた とっても合成写真ぽいですが、packer について発表してきました。 http://engineer.wantedly.com/2015/08/06/hashicorp-product-meetup.html 主催である wantedly さんがいい感じのまとめエントリを公開しているので、当日の発表資料などは上記のエントリから参照してください。 今回は packer とは何するものぞ、というのと今のところの僕の理解でのユースケースってのを発表してきました。 packer 単なるイメージ作成ツールじゃなくて、完全に冪等性を確保した provision ツールと組み合わせると、綺麗な差分管理が行われている OS イメージを自動化して作成することが出来る神ツールってことを伝えたかったんですが、たぶん半分くらいしか伝わってないと

    Hashicorp Product Meetup で発表してきた - HsbtDiary(2015-08-05)
    deeeet
    deeeet 2015/08/08
  • 雑に出来ないって言わない, Asakusa.rb 第302回 - HsbtDiary(2015-04-04)

    ■ 雑に出来ないって言わない マーケット、ビジネスサイドからの issue に対して「これは無理です」「出来ません」というエンジニアを散見する。エンジニアと名乗る人にとって出来ないことはなくて、省略された部分を補うと「(指定された期日までに現在のリソースでは)出来ません」となるはずなのに、括弧の部分を省略している人が多い。 ようは、issue がはっきりしていて後は達成するだけというフェーズにおいては、 知識レベルや技術力が低いので学習しながら進めていると、期待している期日までに達成することが困難 技術力は備えているものの金か人が不足しているのでリソースを調達しながら進めていると、期待している期日までに達成することが困難 の2つしかないわけだ。上記のような状況において「出来ません」な場合に出来ることは、issue を削る、リソースを新たに投入する、期日を延ばすというQCDのどれを諦めるかと

    雑に出来ないって言わない, Asakusa.rb 第302回 - HsbtDiary(2015-04-04)
    deeeet
    deeeet 2015/04/06
  • devise をあまりオススメしない理由 - HsbtDiary(2015-01-20)

    ■ devise をあまりオススメしない理由 いまいち使うのに気が乗らない理由はこんな感じ コントローラレイヤ以降に作用する gem は inspect が物凄くやりにくい、params ないし、必要なコンテキストを全て揃えた上で、コントローラを new して action を呼んで、みたいなこと、考えただけでもだるい テストを書いていたとしても、環境要因、特にセッションとクッキーに影響して挙動が変わる箇所が多すぎるので、全ての環境で正しく再現することが難しい フルスタックすぎることから Rails よりも devise にロックインされることの方が多くなって負債化する そもそも devise で便利になることの多くは、自分で作ってもわけない物が多い 使うからには、devise のコードも全部読むし、PR も投げるしという前提かつ、上のようなことを全て乗り越えるつもりなら僕は止めません!

    devise をあまりオススメしない理由 - HsbtDiary(2015-01-20)
    deeeet
    deeeet 2015/01/21
  • [ruby] rubyspec is 何 - HsbtDiary(2014-08-17)

    ■ [ruby] rubyspec is 何 CRuby(MRI Ruby とか Ruby とか呼び名に議論はあるだろうけど、jruby, rubinius と区別するためにこう書く)では、ランタイムをぶっ壊してないかということを確認するためのテストスイートを 3 つ用意している. RubyCI を見ればわかるのだけど、それらは make test make test-all rubyspec の3つのことを指している。なお、test は ruby 体のテスト、test-all は標準添付ライブラリのテストスイートである。今日は rubyspec について解説しようと思う。 rubyspec とはもともとは ruby の仕様そのものを書こうというプロジェクトで(色々あれこれあって、なぜ今の形になったかをここに書くには余白が足りなすぎるので省略する、ヒントは[ruby-dev:46350]

    [ruby] rubyspec is 何 - HsbtDiary(2014-08-17)
    deeeet
    deeeet 2014/08/18
  • 1