タグ

2015年3月26日のブックマーク (5件)

  • デプロイ自動化とServerspec

    Serverspecの献ありがとうございました.とても面白かったです.詳しい書評はすでに素晴らしい記事がいくつかあるので,僕は現チームでどのようにServerspecを導入したか,どのように使っているかについて書きたいと思います. Serverspec導入の背景 今のチームではサーバーのセッアップおよびデプロイにChefを使っている.にも書かれているようにこのような構成管理ツールを使っている場合はそのツールを信頼するべきであり,Serverspecのようなテストツールは必要ない.僕らのチームもそのような理由でServerspecの導入には至っていなかった. しかしアプリケーションが複雑になりChefのレシピも混沌とするようになるとそれは成立しなくなる.見通しの悪いレシピはChefへの信頼度を落とす.信頼度の低下はデプロイ不信に繋がり人手(筋肉)によるテストが始まる. サーバーの数がそ

  • websec-room.com - websec room リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • 【初心者向け】各OSのTCP通信チェックコマンド入門 | DevelopersIO

    最新版は以下となります。 https://dev.classmethod.jp/etc/ec2-tcp-port-check-command-2018/ こんにちはコカコーラ好きの梶です。 EC2では色々なOSが構築できますよね。構築後の通信確認はどのように実施してますか? 各OSで他のインスタンスへTCP通信確認のために、ツールをインストールしたり、ICMPなどの別なプロトコルで確認するためにSecurity Groupを一時解放していませんか? 構築直後の状態で、簡単にTCPポート疎通確認可能なコマンドをご紹介します。 Amazon Linux,Ubuntu,Windows2012R2,CentOSについて自分も忘れやすいのでまとめてみました。 どなたかのお役に立てれば幸いです。 Amazon Linux 動作確認AMI:amzn-ami-hvm-2014.09.2.x86_64-eb

    【初心者向け】各OSのTCP通信チェックコマンド入門 | DevelopersIO
  • Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi

    Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい>< みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか!?というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の3テーブルは、例えば次のようになる(PostgreSQLの場合): -- immutableなマスタ。 create table records ( id serial

    Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
  • 論理削除はなぜ「筋が悪い」か

    「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」(トランザクション)は不定形(どのテーブルをどのように修正するかはアプリケーション依存)だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる(というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが