トップ «前の日(06-28) 最新 次の日(06-30)» 追記

2004-06-29

_ 画像ビュワー

GV の GIF 機能復活ほか

実は特許失効当日にとびたさんのページをチェックしていたんだけど、動きがなかったので放置していた。

でも気づいたら窓の杜で紹介されていた。GIF 表示機能のほかにもいくつか追加があるらしいので落としておくかな。

slowview が開発停止 → シェアウェアバージョンへ移行

自分は使っていなかったんだけど、さすがに GV は薦めにくいということで slowview を最近あちこちのマシンにインストールしていた。しかし、

  • eps の画像が見れるのかと思っていたら画像内にあるプレビューを見ているだけだった
  • complete free 版の開発が停止してシェアウェア版に移行していた
    • (フリー版のダウンロードは継続)

なんだかなぁ。slowview 捨てて XnView をレジストしちゃおうかと思ったりする今日この頃。eps を安定して見れる完全フリーの実装は相変わらず ghostview くらいなのか。あれはさすがに画像ビュワーとしては他人に薦められない。困ったものだ。

Tags: Tool

_ Namazu for Win32

2.0.13

クラックの影響もあるのかもしれないが、配布アーカイブがあるんだかないんだか状態なので期待するのはやめる。

nkf

nkf 2.04 が cygwin 版とは言えパスの通っているところにあるのに、utf-8 のページをインデックス化できなかった。(インデックスはできるけど意味がない。)いったいこいつはどこでどうやって nkf を利用しているのだろうか?

nkf モジュールを使うようには設定していない Namazu for Win32 で、Perl.exe 以外のプロセスは起きないから、ひょっとして配布アーカイブの中に nkf とは違う名前でもう入っているのか? 調べたら Win32 では必要なものとして挙げられているのは

  • kakasi
  • ActivePerl

のみになっている。そうか、やっぱ外部の nkf は使ってないんだ。てことは逆に Namazu for Win32 で utf-8 のページをインデックス化するのはちと面倒ってことやな。

結論:Win32 で Namazu を使うときは utf-8 は不許可にしとけ

Tags: MS Tool

2006-06-29

_ Sunbird がよくなってきてる

The Sunbird Project - Standalone Calendar

Sunbird 0.3 alpha2 が alpha1 より明らかによくなってる。今までできなかった、時間の範囲を予めドラッグしておいてそこにイベントを書き込むという使い方ができるようになった。iCal みたいな使い方とか Google Calendar みたいな使い方と言えばいいだろうか。まぁとりあえず割と標準的な使い勝手に近づいたと。

イベントを作成するときのダイアログもだいぶうざさがなくなった。これくらいならあんまり違和感ないかな。サクサク感はイベント拾いまくってくれる Google Calendar の方が上だけど、iCal とはひょっとするといい勝負になってくるかもしれない。iCal はもとはたぶん遅くないんだろうけど、なんかアクションに効果がいろいろついてくるのでうざい感じが強い。

0.3 リリースに向けて着々と bug fix が進んでいるようなので、0.3 にはもう少し期待してみよう。

これでサーバ側で複数の iCal 形式のデータをうまいこと融合とかしてくれるシンプルな Web アプリと WebDAV があれば、スケジュール管理は手軽になってくれるかな? この辺は今までクライアントの選択肢がなさすぎて全然調べてないからなぁ。

Tags: Sunbird iCal

_ MeCab with Namazu 2.0.16

どうにも CahSen が落ちるので MeCab を試してみたら、Kakasi も ChaSen もモジュールを使っているのにこれだけモジュールではなく実行バイナリを exec しているのだった。超おせえorz

直しゃいいんだけど、放置して寝た。

Tags: MeCab Text

2007-06-29

_ +Lhaca の脆弱性に各社が対応し始めた

Symantec、+Lhacaの0-day脆弱性を悪用するウイルス発見 - 修正版配布も開始 | ネット | マイコミジャーナル

つーことでまぁとりあえず最悪の事態(バックドア設置など)はなんとか避けられそうなふいんき(なぜか変換できない)。

あとは 1.21 が正式版になるのかどうか。


2010-06-29

_ Emacsで改行を含む置換とxml-modeのindent-region

実際には6月30日のネタだけど長くなるのでずらして書くなり。

minibuffer では \n ではなく C-q C-j

Emacs で改行コードを含む置換をやったことがなかったか避けてきたらしく、今まで知らなかった。

調べると以下のように書かれている。

8.2 Editing in the Minibuffer

The minibuffer is an Emacs buffer, albeit a peculiar one, and ""the usual Emacs commands are available for editing the argument ""text. (The prompt, however, is read-only, and cannot be changed.)

Since <RET> in the minibuffer is defined to exit the minibuffer, ""you can't use it to insert a newline in the minibuffer. To do ""that, type C-o or C-q C-j. (The newline character is really the ""ASCII character control-J.)

Minibuffer Edit - GNU Emacs Manual

てっきり \n や \\n で改行を表現するのかと思っていたけど、ハードタブを入力するのと同じく C-q に続けてコードそのものを入力するらしい。

ちなみに普段編集している際には Enter も C-j も C-m も同じように改行してくれるけど、

C-mCR
C-jLF

は厳密に区別されるので注意。また自分の環境では C-q RET は CR が入力された。これはもしかしたら設定で変更できるかもしれないけど、C-q C-j で覚えてしまう方が楽な気がする。

ところで、上記以外のコントロールコードも何がどれに割り当てられてるか知らないな…。と思ったらここにあった。

Control character - Wikipedia, the free encyclopedia

これだけ分かればとりあえず足りる、のかな?

xml-mode の indent には改行が必要

なんで改行コードを含む置換をしたくなったかと言うと、OOo の template の XML ファイルを編集する際に indent がなくて見にくかったから。Emacs の xml-mode で indent できるよって教えてもらったけどできなかったので、改行コードが要るのかと思って試してみたらこれが bingo.

具体的には

replace-string で > を >C-qC-j に置換

した。

Tags: Emacs

2012-06-29

_ 『リーダブルコード』を読んだ

良い。

簡単なものが大半を占めているのがとても良い。簡単でそれで効果がある。簡単だから続けられる。リファクタリングとかおおげさな言葉を使わなくても可読性向上のためにできることがたくさんあり、それらをきちんと説明してくれている。

変数名一つ、コメントの修正やコメントの追加による段落分けだけでも可読性は大きく向上する。難しい理屈やデザインパターンなど知らなくても、それらを知っている、大幅に構造を整理し、シンプルで強力なプログラムを作ることのできる力のあるプログラマを、コメント一つで助けることができる。

ざっくり

とりあえずあいまいな名前、tmp, length, limit などは今すぐコードを検索して見直したらすぐに効果が出そうだ。

3章「誤解されない名前」では自分でも悩んでいた first/last, begin/end の使い分けに明確な指針を示してくれて、とても助かった。boolean を返す場合に is, has, can, should を使うというルールは確かに自分も使っていた。これはオープンソースのコードや各言語、ライブラリ、フレームワークを読んでいるうちになんとなく身に付いたものだろう。

7章「制御フロー」、8章「巨大な式」については本当にしょっちゅう話題にのぼるので、おさえておくとよいと思う。

心に留まったもの

仕事しない行
if ( cond )
  ;    # 何もしない
elsif ( cond )
  ;    # 何もしない
else
  ...  # 何かする
end

を否定していない。

この書き方、たぶんきらいな人はきらいだし、コードチェッカは杓子定規に弾いてくる可能性の高い書き方だけど、個人的にはアリだと思っている。その方が書きやすく読みやすければそれでいいと思う。同じ考え方の人がいて嬉しい。

目立ちすぎる値、多すぎる値はテストコードを見にくくする

プロダクトコードよりもテストコードの方が荒れやすいが、特に境界値をいろいろやろうとしてひどいことになることはよくある。

そうしたときになぜそうなってしまったかを考えると、たぶん上の理由が多い気がする。

ライブラリを知る

書かなくて済むことを書かないためにも、言語、ライブラリを知ることが大切だ。リファレンスを読み、サンプルコードを読み、実装を読もう。

レビューのお供に

『リファクタリング:Rubyエディション』の序文にこうある。

私は、会議やコードレビューの席にはハードカバーの『リファクタリング』をかならず持ち歩いて、武器としても防具としても活用した。私は自分の仕事と(より強く)ソフトウェア開発の技に情熱を注ぎ込んでいたので、同僚のデベロッパたちの多くは、私がこの本を抱えて彼らのキュービクルに向かってやってくるのを見ると戦々恐々としていたようだ。もっとも、会議でたびたびこの本の内容を参照して発言していたわけではない。

以前、自分は後輩のコードを逐一レビューしていた。その際、指針が自分でもしっかりしていなかったので、なんとなく気持ち悪いとか、単に長いとか、そういう感じのレビューになってしまい、結局役に立っていたのかよく分からないとか時間が掛かる割に効果を感じてもらえていない*1、仕事の進め方や分担が変わったなどの様々な理由で現在はあまりレビューはしていない。

『リーダブルコード』に出てくるポイントははじめにも書いたがとても簡単で効果の出るものが大半なので、特にコードのバラツキに悩んでいたり指導に悩んでいたりするならレビューのお供に使えると思う。ほぼ言語は関係ないノウハウだし。

この本には以前なら大量のコードを読んで初めて気づいたような良い作法が、とてもコンパクトにまとまっているので、自信のない人には特にオススメしたいし、自分が良いと思っている作法を効果的に後輩に伝えられずに悩んでいる人*2にもオススメしたい。

もう一度。本書の内容の大半は簡単なことだ。だから良い。

これからは以前よりは納得がいって効果の高いレビューができるかな。

Tags: Book

*1 コードが良くなるわけでも実装のスピードやデバッグのスピードが上がるわけでもない

*2 つまりオレだ!