トップ «前の日(03-18) 最新 次の日(03-20)» 追記

2003-03-19

_ PukiWiki 1.3.4 リリース

pukiwiki.org

あちこち XSS 脆弱性とか、そのほかの bug fix が施されてます。

このサイトは本体内部までガシガシ手を加えているので、アップデートは 1.4 待ちにして放置です ;;

Tags: News Web Tool

_ FreeStyle Wiki とか Hiki とか

ほほー。PukiWiki より速かったら乗り換えちまおうかな?(笑) フォーマットの違いをどうすんのかが問題ですが、Wiki ってほんと伝染というか増殖しますな。作ってみたくなる気持ちも分かるけど。

まー国産 Wiki が増えてくれりゃいろいろ楽になるので嬉しいんですが。

Tags: Web Tool

2004-03-19

_ USB で KNOPPIX 起動

512MB なんてのは論外だと思うんだが。どうも自分はどんどん主流から外れていっている気がするなぁ。32MB に Putty と鍵入れて「これでインターネットに繋がりさえすればどこからでも自宅サーバでおれ環境だ」とか考えているのはおかしいのか?

Tags: Tool

2005-03-19

_ DNS と NTP

うちの接続環境が復旧したので気づいたけど、firewall がきつくなったと言っていた環境で、DNS があまりに遅い。でも DNS はそこに限定されているのでコネクションの瞬発力が恐ろしく低いことに。何をするにも最初の2テンポ、3テンポくらい遅れる。(キャッシュされてしまえば速いんだけど。)いやー機械が遅かったり自分ちの接続がなかったりして気づかなかったけど、これはちょっとひどいかもしれん。ちょっと相談してみよう。

で。

Ring Server Project が NTP サーバのサービスを開始

一定レベルの精度を実現できるサーバだけで提供されているらしいので割と安心していいかな。mfeed の方はどうなるか分からない(ような気がする)ので今度はこっちにしようかな。もっと ISP が普通に NTP 提供してくれりゃいいのにね。

Tags: 日々 Net

2008-03-19

_ Komodo Edit を触ってみた

特に理由はないんだけど Komodo IDE のフリー版のような位置づけの Komodo Edit というものが出ていたのでちょっとだけ試してみた。

ActiveState - Free the dragon! - Dynamic Tools for Dynamic Languages

以下 Komodo Edit 4.3.0 Mac 版の感想。

いいなと思った点

  • eclipse より断然軽い
  • Emacs キーバインドが eclipse よりマシな気がするけど気のせいかもしれない。C-x 2 でウィンドウ分割できるように読めるんだけど実際にはできない。
  • コードの折りたたみがごちゃごちゃ設定しなくてもワンクリックでできる
  • 結構いろんな言語に対応している
  • バックグラウンドで勝手に構文チェックとかしてくれる
  • コードスニペット機能(再利用しそうな断片を保存しておける)
  • 選択範囲を外部コマンドに投げたり結果を受け取ったりできる
  • FTP と SSH に対応(なんで WebDAV に対応してないんだろう)

試してみてないけど気になってる良い点

DOM インスペクタとかあるし、URL のマッピング機能があるので Web のフロントエンドの開発にも便利なのかも。

別に気にならない点

  • メニューは英語

気になる悪い点

  • Emacs キーバインドで Meta キーを Command にしか割り当てられない
  • カーソルのブリンクを止められない
  • Extended Unix Code を扱えない
    • ShiftJIS はイケた
    • でも ShiftJIS の diff が使いものにならない(UTF-8はイケた)
  • Diff の UI がよくない。タブに開いているファイル同士をサクっと比較とかできればいいのに。
  • CVS にも Subversion にも対応してなくてローカルヒストリ機能もない
  • コマンドを投げる際に(MacOSX版は)/bin/sh を呼ぶので、せっかく整えてある便利環境が全然活かされない
  • 外部コマンドの出力に日本語が入っているとうまく処理できないっぽい

なんか文句ばっか言ってるな。

まぁ実際日本語を扱うには厳しい点がいくつもあるので、普通の人にはオススメしにくいなぁというのが正直なところではあるけれども、外部コマンドなんて使わなくて UTF-8 しか使わないっていうならそこそこ幸せになれるかもしれない。

[2009-09-04 追記]

Windows だと notepad++ の方がいい気がする。Mac では UTF しか使わないなら CotEditor 以上 eclipse 未満的な感じで使えるかも。YAML と diff に対応しているのが個人的には嬉しいしオススメポイント。

v5 が出てたので試してみた。iso-2022-jp, shift_jis, euc-kr には対応してるけど euc-jp には対応していないorz なにそれ。


2009-03-19

_ PHP使いは正規表現についてだけ間違っているわけじゃない

簡易チェックですと本文に言い訳が書いてあってもダメなんだってことが分かってない。(文字が目立つ目立たないは関係ない。)簡易チェックで意味がありませんと title に書いてないと検索した人を間違った情報に呼び寄せちゃうからダメってことが分かってない。正しい情報のように呼び寄せちゃう段階でダメなの。

はっきり言うけど、文字の装飾でどうにかなると思っているなら Web が分かってないよ。

で、実は解決策は簡単で title を

正規表現を使ってメールアドレスかどうか調べるフリをする

にしとけば ok. これで正しい情報を求めている人は寄ってこない。正しい情報なんか求めてないからとにかく簡単に動くコードを見せろやという人はやはり寄ってくるだろう。でもそういう人は目的がそもそも違うんだからいいの。


というかメールアドレスチェックになぜみんなそんな必死だ。

メールアドレスをチェックするシーンというのはいくつかパターンがあるけど、大別して

  • ユーザーの入力したアドレスにちゃんとメールが届かないと困る場合
  • ユーザーの入力したアドレスが間違っていてメールが届かなくてもそれは自己責任て言っちゃえる場合

の二つに分かれる。

前者なら実際にメールを送信して confirm させればいいだけで、別に正規表現で正確に判別できる必要はない。文字列上のチェックでは正しいメールアドレスかどうかは判別できても、実在するかどうかは分からない。*1後者も同じで、メールが届いても届かなくてもいいんなら正確に判別できる必要がそもそもない。これが分かっていればバカな正規表現チェックなんかしない。

もう一つ、良心的で力の足りない開発者は正規表現を使った中途半端なチェックを「じゃあもうちょっと厳密にすればいいのかな」と浅はかに考えてしまう。こういう良心的で力の足りない開発者がいると

実在するメールアドレスを登録できない

というおかしな問題が起きる。実はこれがいちばんタチが悪い。

だから本当はこう指摘すべきなのだ。

メールアドレスを正規表現でチェックする手法そのものが間違いです。チェックできた気になるだけです。

と。

実際にはこんな簡単に割り切れないケースが出てくるのは百も承知よ。でもさ、バータリーがバータリーだって自覚できるようにリードしてあげるのが先輩の役目だろ? ダンコーガイやあっきーなが言いたいことはそういうことだよ。

なんでそういうことを思うかというと、

携帯電話会社仕様のメールアドレスチェック正規表現を JavaScript で作っているところが意外に多い

から。

これ、やめてね。迷惑だから。なんで迷惑なのかはもう上に書いてある。読んで分からなかったら Web 開発やめよう。それがみんなの幸せだ。

Tags: Mail PHP Web

*1 もちろん confirm の仕組みを用意するのは単なる正規表現チェックよりも面倒くさい。