enbug diary(2009-06-26)
_ Shift_JISなファイル名を含むZipファイルを解凍する 要するにタイトルの通りなんですが、 よく知られているように、 Windowsで日本語を含むファイル名があったとき、 Zipファイルの中にはそのままShift_JISでエンコードされたままの文字列が入ってきます。 そして、Linuxとか、普通UTF-8を使うことになっている環境で展開しちゃうと、unzipが頭悪くて、うまく変換してくれたりはしません。 もっと悪いことに、Shift_JISは2バイト目にASCIIコードで言うとバックスラッシュ相当のコードが入っていたりするんで、 これをunzipがパスの区切りだと勘違いして、変なディレクトリを掘ってくれたりとか、もう勘弁してくださいって状態になります。 Ubuntuとかには、対策済みのunzip-jaとかがあるらしいんですが、 私の使っているMandriva Linuxにはそんな
enbug diary(2008-04-05)
_ プログラマがやっちゃいけないこと その1 既存のコードをいじっているとする。 既にあるものに合わせて書くのが原則である（少なくとも、そう信じられている）。 名前の付け方とか、インデントとか。 しかしながら、明らかにそうしてはいけない場合がある。 それは私が「ゴミにゴミを積み重ねてはいけない」と言っているやつで、 既にあるものが腐っていたら、同じように腐ったものを集積させちゃいかん。 ところが、怠け癖がついているのか、思考停止なのか、 そのまま突き進みたがる人がいて困る。 コードってやつは、最初やることが少ないうちはざっくり書いちゃえば済んでしまうし、それでいいことが多いんだけど、 拡張に伴って、段々そのままじゃ駄目になってしまうことがある。 そういうときにサボるとゴミになる。 そして、そのゴミを目にした者がまたゴミを積み重ねると、どうしようもなくなっていくのである。 _ なぜ社長がプロ
まつもとゆきひろ�結城浩，Rubyを語る - enbug diary (2007-06-24)
_ まつもとゆきひろ×結城浩，Rubyを語る たまには、ざっくばらんに書かせてもらいます。 結 変えようとするところが，スゴイと思います。変えないほうが楽ですよね。 私には全く信じがたい言葉です。 まともなソフトウェア開発をやっている人間なら、決してこんな言葉は吐かないはず。 普通、ソフトウェア開発をやっている人間には次のパターンが存在するように思います。 もう関心がないので、実は放置したいと思っているか、実際にそうしている。 やる気あり。どんどん改善できるところはやりたい。でも既存のユーザを無視できないので、そう簡単には変更できない。 やる気あり。もういっぱい変えたくてたまらないし、実際にそうしている。ユーザなんて知ったことではない。 私が思うに、結城さんが言っているのは最初のパターンで、 こんなのはまともな状態とは言えないのだから、 変えない方が楽とかじゃなくって、何もしないのが楽って
enbug diary(2006-12-12)
_ Pythonで新しいメンバーの登録を禁止してみる 何かこの前の続きみたいな内容ですが、 話の出所は全然別です。 そいつが言うには、Pythonでは、 あらかじめ使用するインスタンス変数（attribute）を宣言できないのが気に入らない、とのこと。 要するに、本来 obj.attr = hoge とするところで、 obj.atr = hoge などと簡単に間違えることができて、 しかもちっとも文句も言われないのが気に入らないと。 アクセサーを使うというのが正しい方向性なわけですけど （そもそも外部から内部構造を覗くのはオブジェクト指向的にはよろしくない）、 内部実装では当然のように直アクセスするわけだし、言いたいことは分かります。 無ければ作るべし。 def forbidNewAttributes(klass): """Forbid creation of new attributes
enbug diary(2005-06-15)
_ バージョン番号の衰亡 私自身の考えでは、三つの原因があると思います。 一つはマーケッティング上の理由。 メジャー・バージョンを上げないとニュースになりません。 昔Slackwareがいきなりがばっとバージョンを上げた時から、 商業的関心が薄いプロジェクトでもこの傾向が散見されるようになったと思います。 これは三つ目の理由と関連があります。 二つ目は、記事にも挙げられてますが、 バージョン管理システムの普及、および、テスティング・フレームワークの普及。 このおかげで、開発者サイドから見て、 安定版と開発版を明確に区別してしまうことの利点がかなり消失してしまいました。 コードを相当書き直しても、新しい機能を追加しても、 不安定化する危険度をかなり抑え込むことが出来るようになりました。 今や区別する根拠はせいぜい非互換な変更を加えなければならないとか、 テストが十分ではないと考えられるとか、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
