開発現場で Docker をどこで使うか考えてみた
Shin x blog Advent Calendar 2013 の 16 日目です。 最近話題の Docker 色々と触っています。 触ってみる中で、普段の開発現場でどのような用途に使えそうなのかを考えています。こうだ！という結論が出ているわけではないのですが、一度書き出してみます。 前提 Webシステムの開発現場を想定しています。 言語は普段使っている PHP ですが、内容にはあまり関係無いです。 開発機には Mac OSX を使っています。 検証環境（サンドボックス） まず一番に思いつくのが、検証環境としての利用です。Docker を使えば、OS のみがインストールされている状態のコンテナを手軽に作成できるので、そこでミドルウェアのインストール、設定などを自由に行い、検証が済んだら、破棄します。 OSX 環境では Docker は動かないので、Vagrant + VirtualBox
Haskell での例外処理 - あどけない話
リツイート数が30を超えたので、Haskell での例外処理について説明します。僕が思うに、Haskell での例外処理が分かりにくいのには、2つ理由があります。 ライブラリの混乱 パラダイムの違い 歴史的経緯により、Prelude にも Control.OldException にも Control.Exception にも catch があります。歴史的経緯を説明するのは面倒なので、これだけ覚えて下さい。「Control.Exception だけを使って、それ以外は忘れる」 そもそも純粋関数型で catch とか言われても分からないかもしれません。Haskell では、純粋な関数と IO とでは、例外処理の方法が異なります。命令的な catch などを使うのは IO です。純粋な関数には Maybe か、Either を使います。 純粋な関数 純粋な関数では、原則として例外を投げてはい
Backbone Antipatterns - Shine Solutions Group
Backbone.js deserves a lot of credit for bringing MVC to mainstream client-side Javascript development. That said, many beginners ask what the ‘right way’ of doing something with Backbone is. The bad news is that there’s not necessarily a ‘right way’ – it all depends on the problem you are trying to solve. The good news is that there are definitely some ‘wrong ways’ that you should avoid on your w
Backbone Is Not Enough - Shine Solutions Group
Having spent the last 18 months or so working with Backbone.js, I’ve formed the following opinion: Backbone is not enough for building large single-page applications (SPAs). Sure, you and your team may be able to get your app across the line, but you’ll probably end up with a lot of code and may even reinvent a couple of wheels unless you’re extremely diligent about refactoring, code reviews, docu
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
オレオレ認証局の適切な運用とName Constraints - kazuhoのメモ置き場
オレオレ認証局が忌避されるべきものとされてきた理由は、X.509 PKIが保証する安全性は、最も信頼性が低い認証局（trusted root）のそれに等しいからです。 しかし、X.509 v3以降ではName Constraintsが導入され、「特定のドメインに対してのみ証明書を発行可能な認証局」を定義できるようになっており、同constraintをcritical key usage extension*1として宣言したルート証明書を安全な経路で配布、インストールすることができれば、上記のようなX.509 PKIの系全体に対する影響は発生しないことになります*2。 ここで問題になるのは、どの程度のウェブブラウザがName Constraintsに対応しているのか、という点になりますがhttps://news.ycombinator.com/item?id=5194103によると、Chro
第7回 エンジニアなら、一生学び続けるのは当たり前――社内勉強会を重視する社風から生まれたドワンゴ主催「歌舞伎座.tech」 | gihyo.jp
IT勉強会を開催するボクらの理由 第7回エンジニアなら、一生学び続けるのは当たり前――社内勉強会を重視する社風から生まれたドワンゴ主催「歌舞伎座.tech」 IT勉強会に突撃レポートし、開始のきっかけや、運営ノウハウなどについてお聞きしていく本連載。もっともこれまでは、有志による手弁当のコミュニティについてレポートを続けてきました。しかし、昨今では企業がより主体的にコミュニティ活動を支援したり、勉強会を主催する例も増えています。そこでは、自ずとコミュニティとのつきあい方や、距離感が重要になるでしょう。 そこで第7回目では「niconico」（ニコニコ動画）でおなじみのドワンゴが主催する勉強会「歌舞伎座.tech」をご紹介します。2013年11月14日（木）に開催された「#2」では、歌舞伎座タワー14階の同社セミナールームを会場に、「11/14開催なのでC++11/14のお話」と銘打って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Home · kenokabe/kenokabe.github.io Wiki · GitHub