サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
kozy4324.github.io
Linux独特の/usrとか/etcのディレクトリ構造ってどういったルールになっているんだろうと疑問を持ってググってたら辿り着いたのがFHS(Filesystem Hierarchy Standard)という仕様。 http://www.pathname.com/fhs/ 2012年9月現在のバージョンは2004年1月にアナウンスされた2.3が最新。PDFにして45ページの軽量なドキュメントだったので、ざっと読んだ内容をメモ。 FHSに書いてあること トップディレクトリ以下階層にあるべきディレクトリ/ファイルとオプショナルで存在するディレクトリ/ファイルの定義 それぞれのディレクトリ毎の用途/利用目的 これを理解すれば、例えばあるソフトウェアの設定ファイルはこのディレクトリにインストールされログファイルはこのディレクトリ以下に出力される、といったことが理解しやすくなる。具体的にはrpmでイ
mongoシェルからの基本的な操作をいろいろやってみる。 データベースの選択 mongoシェル接続時に指定する(省略時にはtestデータベースに接続)。接続後に変更する場合はuseを利用。グローバルなdb変数に問い合わせれば現在選択中のデーターベース名が返ってくる。 $ ./mongo sample MongoDB shell version: 2.0.4 connecting to: sample > db sample > use hoge switched to db hoge > db hoge
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 > db.things.stats() { "ns" : "test.things", "count" : 10000, "size" : 560008, "avgObjSize" : 56.0008, "storageSize" : 1396736, "numExtents" : 5, "nindexes" : 1, "lastExtentSize" : 1048576, "paddingFactor" : 1, "flags" : 1, "totalIndexSize" : 335216, "indexSizes" : { "_id
OctopressのRakeを実行したところ、Gemfile.lockで固定しているRakeのバージョンに対して新しいバージョンのRakeをactivateしてるって怒られた。 rvm使ってるんでgemset使えって話なんですが、ワークアラウンドが用意されていたのでメモ。 rakeを実行した際のメッセージは以下。 $ rake -T rake aborted! You have already activated rake 10.0.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this. /Users/kozy/.rvm/gems/ruby-1.9.2-p318/gems/bundler-1.1.1/lib/bundler/runtime.rb:31:in `block in setup' /Us
なにをもってそのプログラムが「変更に強い」と言えるのか、小一時間ほど考えてみたので文章化してまとめておく. 変更が簡単に行える まず思いついたのがコレ. ただ「簡単」という表現がまだ曖昧なのでそこから連想してみる. バグが混入しづらい、壊れない テストが容易 時間がかからない 変更箇所が明確で局所化されている 変更後もソフトウェアの複雑性が増さない お、最後のがなんかしっくりきた. 変更を繰り返しても複雑性が増さなければ上の4つも保たれると. 「変更に強く」するためにすること 次に普段自分がプログラム書く時にやることベースで挙げてみる. 基本OOPなんですが. クラス/モジュール分割を適切に行い将来発生しうる変更が局所化されるようにする インターフェイスを抽象化しオブジェクト同士の依存関係をシンプルかつ疎結合となるようにする 共通インターフェイスを持つオブジェクトの交換により機能追加/変更
npmモジュールのバージョニングについて調べてたらその標準仕様SemVerっていうのを発見したんだけど、よく読むとnpmモジュールのそれとは微妙に違うものになってるようなのでそこらへんまとめておく。 http://semver.org Semantic Versioningということで、バージョニングに意味を持たせようという話。公開されたAPIを持つライブラリなどが新しいバージョンをリリースする際、例えばそれが後方互換を保っているリリースなのか、機能追加もなくAPIがまったく変更しないバグFIXのようなリリースなのかをバージョン番号の上げ方で表現しようと。 このspecification自体もこのバージョニング仕様に則っており現在はv2.0.0-rc.1。その前バージョンv1.0.0は同サイトで公開されている。 SemVer v1.0.0 - http://semver.org/spec/
週末にアジャイルがダメとかダメじゃない理由を7つほど考えようとしたけれどもどちらもそんなに思い浮かばないので自分がどういうモチベーションでアジャイルプラクティスを導入しているかという話を書いておく アジャイルがダメとかダメじゃない話題が盛り上がっておりますが、ソフトウェア開発プロセスには銀の弾丸なんてなく当人が置かれたコンテキスト抜きだとその議論はむずかしいよね、と思っております. アジャイルがいいとかだめとかじゃなくてアジャイル開発プロセスのどこがうちの組織にあって、どこがうちの組織にあわなかったみたいな話のがよっぽど有意義だと思う— Kazuho Okuさん (@kazuho) 2013年3月22日 禿しく同意. というわけで自分が開発リーダーやらせてもらってる今のチームでアジャイルプラクティスを導入した動機の話をエントリーにまとめてみます. なおこのエントリーのタイトルが長くなったこ
GitでmasterとかHEADって言っているやつはいずれかのコミットの参照つまりリファレンス(ref)ですよっていう話で、そこらへん確認したことをメモ. なおドキュメントを頭からしっかり読んだりソースコードを確認したわけではなく、コマンド叩いたベースで確認しただけなので間違った認識の場合はご勘弁. 確認したGitのバージョン
このページを最初にブックマークしてみませんか?
『kozy4324.github.io』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く