vagrant-serverspecを使ってプロビジョニング結果をテストする
全国1000万人のVagrant利用者のみなさんこんにちは。 Vagrantいいですよね！そしてインフラの状態をテストするserverspecもいいですよね！この2つがシームレスに統合されるとかなりうれしいですよね！ ということで本日12/2にvagrant-serverspecというプラグインがリリースされたので早速紹介します。 インストールインストールは簡単です。いつも通りvagrant plugin install vagrant-serverspec としてください。 コード自体は https://github.com/jvoorhis/vagrant-serverspec で公開されています。まだバージョン0.0.1なので、問題を見つけたらPR送るなりIssueを切るなりすると良いと思います。 使い方使い方も簡単です。まずVagrantfileを見てみましょう。 これは何をやって
BackboneマンがAngular勉強会いってきたけどそんなに好きになれなかった話 #ng_jp - mizchi's blog
最初に僕のポジションは表明しておくけど、今までbackbone.js, というかそのラッパーであるchaplin.jsべったりの環境で開発してて、今のプロジェクトをゼロから作り直す機会があるので次バージョンのためのライブラリ選定のためにとりあえず比較として angularを試した見た程度の人間なので、深くは理解してない。 Angularのメリット 僕の浅い理解と勉強会での話を総合した感じ レールに乗り切った時の開発効率が半端ない レールがしっかり敷かれているので開発者の能力差が問題にならない HTMLがテンプレートなので意味的な乖離が少ない ビューモデルに対する操作が一貫していてテスタビリティがある 自分もモジュラリティがあるHTML/CSSは幻想だと思っているので、HTMLに直接属性を書くのは別に構わないと思っている。 ただ、集団開発でも開発者の能力差が問題にならない、という発表をしてい
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
AngularJS 20min #ng_jp
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
フラットにするより組織図を反転すればよいのではないかという考え方 - ワザノバ | wazanova
http://6brand.com/the-upside-down-org-chart.html これまで、GitHub、Valve、Treehouseなど、フラットでマネージャのいない自己管理型の会社を紹介してきましたが、今回SquareのJack Dangerは自らのブログで、伝統的な組織図を反転させた発想での会社運営を提案してます。 1) 伝統的な組織図 トップダウン型のこの組織図は、エンジニアが大会社で働きたくないという要因になっている。「仕事がイヤだから辞めるのでなく、ボスがイヤだからやめる。」と言われるように、ベテランのエンジニアを引き止めるためだけに「昇進」させ、質の悪いマネジャーを生んでいるテク企業も多い。また、マネージャーは（よい人であっても）階層のある組織にいると配下にネガティブなプレッシャーをかける傾向を指摘されている。 一方、自己管理型のフラット組織は、多少の組織内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
