開発環境のためのDocker再入門 - ひげろぐ
色々と開発環境を整理したくて3年くらい前に触ってみたきりだったDockerに再入門。 既存のVagrantで構築していた開発環境、vm.boxで指定しているイメージがダウンロードできなくなっていたり、Chefでプロビジョニングしていたところが動かなくなっていたので、直すより新しく作り直した方が早いかなと言うのがきっかけ。 前に試したときはDocker Compose的なものがなく（見つけられなかっただけかもしれないけど）、公式のコンテナも少なかったので、まだ本格的に使うには色々辛みがあるなと結論づけてそっとじしたのだった。 以下つらつらとメモ。 VagrantとDockerの使い分けについて 開発環境として定番のVagrantとの使い分けについては以下のページが簡潔でよくまとまっていて参考になる。 個人開発環境をvagrantで建てるべきか、dockerで建てるべきか 個人的には何かサーバ
iPad Pro 12.9インチ雑感 - ひげろぐ
iPad Pro本体（Wi-Fi版の128GB）は11月下旬、Apple Pencilは12月頭に入手。 軽く使用感をメモしておこうかなと思いつつもぐずぐずしていたら9.7インチ版が出たりとか、すっかり今更感が出てしまった。 ともあれざっくり言うと主な用途は写真閲覧、手書きメモ、電子書籍（主に技術書）、出先でマルチディスプレイ。 ロジクールの外部キーボードも購入したが、これは結局今は使っていない。 こうしたガジェット類はノリで買ってはみたものの文鎮化する、なんてこともまれによくあるけど、このiPad Proはかなりアクティブに使っているかんじです。 写真閲覧 写真閲覧デバイスとして一眼レフで撮った写真などを閲覧するにはかなり良い。 大きいから細部まで見えるし、コントラストが高く見栄えがする。 アプリはデフォルトの写真アプリ。 ただこの用途だと取り回し的に9.7インチの方がいいように感じてい
リファクタリングのいつ - ひげろぐ
リファクタリングのタイミングはいつなのかという問いについて。 ベストなのは開発と並行して。 書いたばかりのコードはリファクタリングしやすい。 時間が経つほど内容を忘れていくのでリファクタリングしにくくなる。 ありがちなのは「時間が余ったらリファクタリングしよう」 時間は得てして余らないものなので、リファクタリングの機会は永久に来ない。 リファクタリングは余った時間でするものではない。 むしろ時間を余らすためにリファクタリングすると言ってもいいくらい。 リファクタリングによってコードがシンプルで修正しやすい状態に保たれるため、開発スピードを保つことができるからだ。 （という口車を使ってリファクタリングの時間を確保しよう！） リファクタリングは「外部から見た振る舞いを変えずに実装を変えること」なので、振る舞いを変えるものを「リファクタリング」とは呼ばない。それは単なる「修正」。 リファクタリン
テストコードのリファクタリング - ひげろぐ
TDDBC 福岡2でのTDDの失敗ケースとは何かという質疑応答から。 テストコードにもリファクタリングが必要 昔はテストコードがメンテ対象であるという意識が薄かった 見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる 素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう たくさん書くのではなく必要十分書くことが大切 書き散らすと「テストケース爆発」を起こす テストコードもメンテし続けるためにリファクタリングして行く必要がある テストコードもプロダクトコードと同じようにテストのGreenの状態が維持されていることで、既存のコードが壊れないことを保証しつつリファクタリングしていくことができる。 （ただしテストが無条件でオールグリーンになるみたいな酷い壊し方をしてしまう心配は
現代ソフトウェア開発の三本柱 - ひげろぐ
しばらくTDDBCで聞いたネタを雑感を交えつつ復習的にちょっとずつ書いて行ってみようと思う。 そういうわけでぐぐれば他で書いてあること多めです。あと網羅的には書かないです。ｇｄｇｄです。 三本柱とは 和田さんが考える三本柱は以下の通り。 バージョン管理 テスティング 自動化 バージョン管理 TDDのイベントだったので深くつっこみしなかったけど和田さんの考えでは最重要とのこと。 テストや自動化はなくてもなんとかなるが、バージョン管理はないと死亡確定。 「セーブなしでRPGクリアとか無理ゲーじゃないですか」みたいなことを言っていた覚えが。 雑感 未だそんな無理ゲーに挑んでる現場も少なくないような気がします。 ところでこれは後々の懇親会で聞いたことだけど、Subversion等を経ずにGitを使う分散バージョン管理ネイティブが出て来始めているようだ。 個人的には初めて分散バージョン管理システムを
Chefの運用をする際の鉄則一条 - ひげろぐ
手動で設定してはならない 手動で設定してはならない。 コレ。 大事なことなので二度言いました。 少なくともChefのカバーする設定範囲を手動で直接触ってはいけない。 一度でも手動で設定を行うと、次にChefを動かすのが怖くなる。（間が開くとなおさら） 加えて例え例外的にでも手動設定を許すと、他にChefで管理しているインフラに関しても、手動設定をしていないと言い切れる自信がなくなり、いつでもChefを実行して大丈夫という勇気が持てなくなる。 逆に必ずChef経由で行うことを守っていればTDDライクにサーバー構築できる楽しいChefライフが送れます。 後で必ずChefのレシピに反映しておけばいいんじゃないの 忘れるから。絶対忘れるから。 Chefの実行に時間がかかるんだけど run_listに対象のレシピだけを含んだjsonを作って実行してあげればOK 緊急事態なんだ！ なら仕方ない。何にで
b-mobile WiFi - ひげろぐ
すぐに使いたい事情ができたのでゲットした。b-mobile Fairとともに。 日本通信 bモバイル・WiFi ルータ WiFi ルータ機能付 SIM フリー端末 BM-MF30 日本通信 bモバイル・フェア 1GB SIMパッケージ 120日間 なお以前から検討していた光ポータブルレンタルは手元に届くまで半月程度かかるようなのでさくっと諦めた。 SIMフリーiPhone5のテザリングも待てなかった。（iOS5でDocomoSIM無理になるんじゃって気配もあるしなあ） ともあれこれで旅の宿を探すときにWifiの有無を確認せずともよいし、キャンプツーリングにも心置きなくでかけられるってもんだ。 月々の維持費2000円ちょっとで日本全国ほとんどのエリアで使える回線を手に入れたと思うと悪くない。 b-mobile Fairなので使いすぎれば月々どころか数日で8000円飛んでいくものだが、利用頻度
chef-soloで作業環境構築の自動化 - ひげろぐ
さくらのVPSを契約して放置しておいたままだったので、これを機に環境構築をしてみることにした。 なお現状はユーザーakahigeの追加とsshの設定だけ済ませた状態になっている。 すべての設定はChef経由で行うこと というルールでChefで同じ環境をいくらでも作れるものを目指してみよう。 Chefサーバーのセットアップはめんどくさいのでchef-soloでがんばる所存。 Rubyのインストール とはいえChefの動く環境はChef以外で作らないといけない。 このあたりを省略するならシェルスクリプトによる自動化か、Chefが動くところまでセットアップした仮想マシンのイメージを使うほかなさそうだ。 必要なパッケージのインストール $ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.r
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ひげろぐ - 結論を急がない