トップ «前の日(02-22) 最新 次の日(02-24)» 追記

2004-02-23

_ ちっちゃく昇進

することになりました。

Tags: 日々

_ Emacs と半角カナ

生 Emacs 21 で半角カナの入ったファイルを開いたら文字化けというかまともにマルチバイト文字が解釈されてなくてどうしようもなくなってしまう、という現象が起きていたのだが、これが解決した。

/* 生。というのは XEmacs の場合は問題なく読み書きできたから。Mule や Meadow も試していないがきっとそうだろう。 */

要するに文字コードを Emacs に自動判別させずに指定してやればよかった。問題の現象は sjis で半角カナを入れた場合には発生せず、euc-jp の「半角カナ」のときだけ発生し、また terminal に依存しないことから Emacs のコードの解釈の問題だとは早いうちに当たりがついていたんだけど、面倒だったのと、あまり直接的な回答が見当たらなかったので伸ばし伸ばしになっていた。

結論から言うと

  • 編集対象ファイルの中で Emacs に対し文字コードを指定する際の細かいルールが分かっていなかった。
  • 拡張子ごとに文字コードを設定することができるはずだと思ってはいたが、具体的にどういう設定方法になるのか分かっていなかった。

の2点が問題だった。今回、どちらも解決した。

  • -*- 方式は2行目に書いても有効にならなかった。1行目に書いたらちゃんと動作した。
  • 拡張子ごとの設定は (modify-coding-system-alist 'file "ファイル名のパターン" 'コード) で ok だった。
Tags: Tool

_ subversion 1.0 source

wakatonoの戯れメモ経由。

まだバイナリは全然できてないみたいだけど、1.0.0 のソースアーカイブが出ました!

来ちゃったか! ほな試すか!

Tags: Tool Web

2005-02-23

_ Linux か Mac かと思ってた

RSS なんかもこんな感じかも。

なんの話かっつーと Wiki コミュニティが Wiki 万能言い過ぎてねーかって話と、それを受けてたぶん sheepman 氏がいろんなものに当てはまるなーと思って伏せ字にしてみたところ、私は Linux, Mac を思い浮かべました、という話。

ただ、面白がって遊び倒さないといいも悪いも見えてこないってこともあるのよね。面白そうなものに飛びついてハマりつつ適度な距離感を見失わないバランス感覚をいつまでも大事にしたい。と言いつつ del.icio.us も MM も bloglines も mixi も Gmail もやってませんけどねorz

Tags: 日々 Web

_ Perl に疲れた、ってのは噂にも出てこないのか

textfile.org 経由で

プログラミング言語ユーザーの噂

  • ほとんどが言語オタクか日本人。
  • ドキュメントは書かず「ソースがドキュメントだ」とうそぶく。

言語ヲタだから Ruby を使うって噂なんすか。私は「昔は Perl 書いてました」って人が多いと思ってるし、それは定説になってるもんだとばかり。だぁって use strict でいちいち my してたら Perl で書くメリット半減でしょ。余計なことせずにいきなり書けちゃうのが Perl のよさじゃないのかと。で、use strict して my しまくるくらいなら Ruby で書いた方が同じことを実現するための記述量は小さくなると思うし、ちょっとでも OO で書きたいとか思ったらもうそれは雲泥の差でしょう。言語の環境を自由に用意できるのであれば、あとはライブラリの差をどう判断するかってところに落ち着くと思うんだけど、そういうもんじゃないのかな。

あと、ドキュメント重要。でもソースに書いてある。Wiki にも書くけど細かいことは RDoc*1 読め。が、今どきじゃないのかな。

なんかどうもここにある噂は単に作者の生態や有名な言葉が並んでるだけのような。ちなみにその作者まつもと氏は

Re:死にやがれ(/.-j)

ぶっそうなサブジェクトですが、アイディアレベルを含めて10個くらいの言語を思いついたようですな。

Tags: Ruby Perl

*1 RDoc は Ruby のコードにドキュメントを埋め込むタイプのもので、http://raa.ruby-lang.org/project/rdoc/ にある。Ruby 1.8 以降標準添付。イメージとしては javadoc, phpdoc を簡単にしたような感じ。いちばん簡単な使い方は class, def の直前にコメントを書いておいて、'rdoc -c CHARSET .' とするとカレントディレクトリ以下のコードをパースして HTML のドキュメントが生成される。これ以上は各自ぐぐるか自分で試すこと。たぶん自分で試すのがいちばん早い。

_ グループウェアは窮屈だから Wiki にしました

対グループウェアとしての Wiki

グループウェア、ダメ!

そうなんです。

面白くないんです、グループウェアは。なぜなら先にフローが決まってしまうから。と勝手に思ってるけど本当は Notes とかまともなグループウェアは使ったことがない。ただ、なんかお試しできるツールをいくつか触った感じは

窮屈。

DOS 時代のデキの悪いソフトをつかまされたような、手順を縛られたとても窮屈な感じがするのです。これをこうするためにはこっちのこれをこうする必要がある、とか。そんなことしるか!と。こちとらマニュアルなんて一切読まない、直感的に使えないソフトは全部クズだと思っている人間だぜ。*1

つーことで実は今の環境でも最初にグループウェアの導入を模索してみたんだけど、結局導入したのは PukiWiki のみでした。選んだ理由は、前にも書いたような気がするけど、

  • 当時としてはかなり画期的な valid xhtml を吐く仕様(を目指していた)
  • PHP は使うから、PHP だと将来的にもカスタマイズとかできていいかもと思った*2
  • 記法が比較的複雑な構文をカバーしているので、まともにドキュメントが書ける
  • BugTrack プラグインがあった
  • PHP だけ動けば使える(RDBMS とかバージョン管理システムとか Pear とか sendmail とか要らない)

かな。

1.3.2 かなんかを使って、当時まだ Windows サーバしかなかったので改行周りの問題がものすごく大量に出たけど頑張っていちいちつぶしていって*3、分からんなりにいじるのが面白くて、そうこうしてるうちにあーこれはこういう使い方をするとこういう情報のストックや更新なんかに便利だなというところが見えてくる。Wiki にしてよかったことは「使い方を自分で考えることができた」こと。

メール連動とか便利かもしれないけど、どれだけ便利か分からないのにサーバをセットアップしなきゃいけないのは面倒でいや。目の前に居る人間との共同作業が前提だし、メールは記録として使えるけど基本的にはメッセンジャーと Wiki と face to face のコミュニケーションで足りる。*4RDBMS も要らないし、Wiki そのものが考え方を理解するのにちょっと苦労するという問題はあっても、使い始める負荷を比べると、自分にとっては グループウェア >> Wiki だった。

Wiki 信者の戯れ言でしょうか。信者ってつもりはないんだけどな。ページやナビゲーションが簡単にごちゃごちゃしてわけ分からなくなるとか、新たに使ってもらうためにはどうしても記法のとっつきにくさって問題は残るし。でも「高度な自動化が必要なければこんなに便利なものはない」とは思ってるし、「とりあえず Wiki でできないか考える」というクセはついてるかも。よくよく考えると Wiki って全然たいしたことないんだけど、その欲張らなさというか、機能の少なさがかえって自由で気持ちいい、って感じ。

文房具としてコンピュータを使うための Wiki

その前にまず脱線。Web としての Wiki に自分が感じている画期的な点は

  • 存在していないページにリンクが張れる
  • 特別な検索ツールを用意しなくても検索できる

この2点。素朴な HTML 直書きから入った人間の素直な気持ちです。いやほんと、Web としてはこれ以上の意味はないんじゃないかと。応用としてはいろんなよさが出てくるんだけど。

日常の道具としての Wiki に感じるよい点は

  • オープンな技術で実装されているし Web ベースなのでプラットフォームを選ばないことが多い
  • なおかつ LL で実装されているものが多く、準備が楽
  • したがって localhost に実験環境とか自分用の Wiki を用意しやすく、道具を Wiki に一本化しやすい*5
  • ファイルが添付できるとますます成果を Wiki に集約させやすくてよい
  • Web ベースなので作業する機械とデータの保存場所を分離しやすい
    • 特定のクライアントマシンの中を探さないと必要なデータが出てこない、そしてその人は休んでてどこにあるか分からない、とかいう複数の人間が絡んだ作業のときに陥りやすい事故を簡単に防げる
    • データの保守と機械の保守を分離しやすい。自分の機械が壊れたときの損失を減らしやすい。
  • 検索できる*6
  • ファイルの管理を意識しなくてよい

ここまでくると Wiki 信者と言われても文句は言えないのかな。でもここに WikiWay の精神はたぶん全然出てきてないと思う。

Tags: Net Wiki

*1 なのに Emacs を使っている :-)

*2 結局カスタマイズするとアップグレードしにくいのでほとんどしなくなった

*3 本家にはほとんどフィードバックしてません。ごめんなさい。

*4 メッセンジャーは書いたページの URL を飛ばすのに重宝する。「ここに書いたんだけど読んでみてくれ」とすぐ言える。ネットワークの規模がでかくなったら irc にしようかなと模索中。あ。Wiki は他のツールと組み合わせると効果的、というのはこういうところからも感じているんだな。自分は。

*5 環境が縛られるのはいやだけど道具がバラつくのは邪魔くさくてきらい、というわがままな自分にぴったり。

*6 バイナリデータでも添付してコメントつけとけばすぐ検索できるようになる。もちろん画像についてはアルバムソフトなんかに頼った方が目的の画像に到達しやすいと思うけど、データの 5W1H の一部でも書いてページに貼付けておくだけで、いろんなデータが一気に再利用しやすくなるってことは自分にとってすごく嬉しい。最近でこそ OS がバイナリファイルに対してまで grep の機能を提供したり、さらにインデックスもバックグラウンドで起こして高速に検索できたりするけど、特定の OS の機能によらずにこれが実現できるのがよい。


2006-02-23

_ その他の雑酒2を飲んでみた

プレミアムモルツを箱買いした客にこれを試飲でプレゼントするのって、ものすごいセンスだと思うんだけど、もらったものはとりあえず試してみる。

すげー。ビールの風味が全然ない。

果汁系の味のしないチューハイとして飲めばこんなもんかなと思うけど、これで第3のビールって売り方はないだろ。

Tags: 日々 Food

_ 高林さん引っ越したのか

いやなブログ: 0xcc.net

RSS を読んでて全然エラーとか出ないから気づかなかった。(つーか上のエントリ見落としてるんだけど。)

なんで分かったのかというと、見慣れないリファラがあったから。

Tags: Web

2009-02-23

_ less 使いが lv を使えるか

長年 less を使っているが、いちばんの理由は

previous page [w] <-> [z] next page

のキーバインドを使っているから。調べたけどこれと同じ操作は lv では実現できないみたい。

man を見てみると

previous page [b] <-> [space] next page

なんてのがある。うーん、[b] が [shift] + [space] ならよかったんだけど。それか

previous page [b] <-> [f] next page

かな。この方がまだ我慢できそうな気がしないでもない。

lv 使いはみんなどのキーバインド使ってるんだろう? 個人的には z/w がいちばん直感的で好きなんだけどね。


2011-02-23

_ 今さらRails3メモ - その4: Modelのちょっと変わった基礎 -

Model は奥が深く、また Rails は Fat Model にしろ、の哲学なので長くなりそうということで小出しにする。

ActiveModelをincludeすればなんでもModelに

Rails 2 以前は ActiveRecord と密結合していたけれど、Rails 3 以降で多くの機能が ActiveModel に切り離された。ActiveRecord を使うアプリの場合はあまり関係ないけど、ActiveRecord から切り離されたということは

DBMS 関係なく Model の機能を利用できる

ことを意味する。

Model のクラスメソッドとインスタンス

Model のクラスメソッドには table_name, human_name などがあるが、Model.new したオブジェクトには存在しない。

ましてや Model.all, Model.find の検索結果に至っては Array なので .table_name, .human_name などのメソッドは存在しない。(しばらく悩んでしまった。アホすぎる。)

ということで Model の定義情報はクラスに聞け。

ただし

当たり前だけど ActiveRecord ベースでない Model には table_name などは存在しない。最終的には connection を張って取得してるらしい。

カラム定義は Model.columns に

Model.columns に必要な情報が入っている。inspect のコードを参考にすると

Model.columns.map { |c|
  "#{c.name}, #{c.type}"
}

なんてことをするととりあえず欲しい情報は取れると思う。form field の自動セットとかたぶんできる。

Validation

  • validates がなくて値が不正などの DBMS レベルのエラーの場合はアプリケーションの例外画面がいきなり表示される
  • validates で引っ掛かったら Flash*1 でエラーメッセージを出せる

Rails 3 以降は validator は ActiveModel に属すので、それっぽいプロパティと validator を用意すれば DBMS は無関係に Form を作ったりすることもできる。

validates_* なヘルパーはクラスメソッド

これ分かってなくてハマった(情けない)んだけど、validate 関係のメソッドはクラスメソッドなのでそこからインスタンスメソッドは利用できない。要するに

こういうこと。

validatorの目視チェックを破壊的メソッドで

Ruby on Rails Guides: Active Record Validations and Callbacks

validator がちゃんと動いているかどうかは

The bang versions (e.g. save!) raise an exception if the record is invalid. The non-bang versions don’t: save and update_attributes return false, create and update just return the objects.

ということで ! のついている破壊的メソッドでデータを保存しようとすれば例外が上がって目視しやすい。

  • create!
  • save!
  • update_attributes!

non-bang version(! のついていないメソッド)は false が返るだけだし、rails console で実行していると保存に失敗しても何らかの値がセットされた状態でオブジェクトが表示されるので、

瞬間的に保存に失敗したことを認識しにくい

ので、目視チェックは破壊的メソッドで、と覚えておくと便利。

参考

idはcreateできないのでseed dataを作る際に注意が必要

Model.create( {} )

の際には id を与えることができない。自動で振られてしまうので。ただし

m      = Model.create( {} )
m[:id] = 1
m.save

とすると id を指定できる。

cf. Twitter / Dai Akatsuka: @wtnabe Model.create(:id = ...

これの何が問題かというと、id で relation を作る seed data を作っている場合に困る。

fixture の場合はこれは問題にならない。なぜなら ActiveRecord の奥底で直接 INSERT INTO を呼んでいるから。したがってデータの作り方によって

db:fixtures:load はできるけど db:seed はできない

場合がある。

find_by_sql() で複雑なSQLをそのまま書く

Arel は確かにすごいんだけど、複雑な SQL を OO のメソッドチェインだけで実現するのはやはりホネ。素直に SQL を書いた方が簡単なケースはやはり少なからずある。

  • Model.find_by_sql( ) で複雑な SQL をそのまま書ける
    • ちゃんと sanitize というか quote してくれる
  • Model.find_by_sql( [SQL, VAL, VAL] ) で変数への値の埋め込みができる*2

この際、join を使った検索結果を console で確認しているとちょっとハマる。console ですぐに目視できる結果は Model 内に定義されている attibute だけなのだ。

しかし実際には join した table の attribute もそのままアクセスできる。これは

Model.find_by_sql().each { |e|
  e[:attr]
}

Model.find_by_sql().first.attributes

で確認できる。ここで確認できる attribute にアクセスするロジックを自由に書ける。

Tags: Rails Ruby

*1 Rails用語のFlashね

*2 軽く読んでみたけど DBMS の binding 機構を活かしているかどうかまで読みきれなかった…。


2013-02-23

_ Coderetreat in Fukui (2013-02-23) に参加してきた!

久しぶりのペアプロイベントだ!と思い、行ってきました。

今回のファシリテータは QuickJUnit / チェンジビジョンの近藤さんでした。

Hiroki Kondo (kompiro) on Twitter

会場スポンサー永和システムマネジメント、ランチスポンサーはチェンジビジョンさんでした。

改めて、ありがとうございました!

準備

日程的にはあとからどんどんきつくなっていったけど、決めたことだし仕方がないっすね。2週間くらい前から仮実装をTDDしてみたりしてました。完成はしなかったけど。

で、準備はですね、やった方がいいですね。なんでかっていうと45分のペアプロはやることがてんこ盛りで結構ハードだからです。この話は後述。

※ 先週の kanazawa.rb meetup #6 で序盤イベントに集中していなかったのは、このイベントの準備と仕事の両方のメドが立っていなかったからでした(笑) すげーつらい時期だった。

簡単にcoderetreatを紹介

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design.

  • practice が目的。いろいろやってみよう。
  • 45分1セッションでライフゲームを題材にペアプロする
  • 複数セッションを継続させることはできない。次のセッションでは前のセッションの内容は参照せずに行う。(コードは破棄する)
  • ペアも言語も自由に選択
  • セッションの45分は厳守だが休憩時間は割と自由

Structure of a Coderetreat

この辺読むといろいろ書いてあるので facilitate する場合は熟読すべし :-)

会場の感想

会場は福井の永和システムマネジメントとチェンジビジョンが入っているビルでした。当日は朝7:00の電車に乗った辺りからあれよあれよと雪が舞い始めてうわーなんだこれって感じになりましたが、会場の雰囲気はとてもよかったです。

途中のブレイクで社内見学させてもらいましたが、社員の書いた本が飾ってある棚があって、「小さな書店の技術本のコーナー」くらいの量があるんですよ、これが。しかも「そういやあれもこれも見たことあるぞ、おい」という本ばかり。知ってて買った本もあるけど知らずに買った本も何冊もあって、なんだこの会社はと改めて思ったのでした。

しかもアレ、業務じゃないんですって。信じられない。

イベントの感想

疲れた!(笑)

実は1/3は休んでたんだけど、それにしても疲れました。まぁ、割と疲労のピークには来てましたが、それにしても久しぶりのペアプロイベントはとても疲れました。

でも楽しかった。正しい coderetreat を facilitate するのはちょっと大変そうだけど、この感じを取り入れた何かをするのはとても面白そうだなと思いました。

永和の岡島さんが仰ってましたが、このイベントはコミュニケーションなんですよね。プログラミング言語で、自然言語でコミュニケーションする、それもほぼ45分頭をフル回転させる。そしてより良い何かを目指す。より良い設計かもしれないし、セッション開始時に絞った特別なポイントかもしれないし、一歩でも完成に近づけるための戦術だったりする。

これがむちゃくちゃ面白くて疲れる。

1セッション目はお互いに面識もないし、ちょっとぎこちない感じなんだけど、2セッション目からはやることも見えてるし、各自それぞれの目的でもってこのコミュニケーションが始まります。自分の知らない言語に触れてみたいという思いだったり、さっき思いついたけど達成できなかった実装とか。お互いの人となりは知らないんだけど、少なくともあの空間においてはネタに事欠かない状態なのです。不思議な共有と加速があります。

TDDBCでペアプロしてみた経験はあったけど、業務の中ではやってないし、やるとしても先に目標と時間が読めるものを使って「教える」感じでしか使っていなかったので、この戦闘モードのペアプロというか、こんなのマジで毎日続けてるやつらいるのか?っていうくらい疲れました。45分の縛りが回復を助ける意味にも疲労を倍加させる意味にも働いてるんでしょうね、これ。

あとペアプロやるとソッコーで仲良くなれますね。飲み会よりコストパフォーマンスいいな。車で行けるし、こういうのもアリだな(笑)

個人的な反省

教えてもらう気まんまんで行ったんだけど、そろそろ自分は教えることもできるんだなぁということに気づくことが多かったです。そして周りは型型な人たちばかりだったのに対して自分だけゆるふわだったので「Rubyを教える」感じの時間が長くなってしまって、あれーこういうイベントだったかなぁ?みたいな気持ちになったのはちょっとあります。

でもこれはこれでペアの方にとって新しくて面白い体験だったのかもしれないし、そうであったならよかったなと思います。ペアプロって言っておきながらだいぶ一方的にドライバやり続けててダメじゃんと思ったりもしたけど、今思うとあれはアリっちゃアリなんだろうなぁと。

ただ、それならそれで最速で環境を準備できるようにしておくべきだった。いつもGemfile書いてbundle叩いて…を儀式のようにやっていたんだけど、45分という縛りがつくとこの儀式の時間がない。本当にないんです。ちょっと誤算でした。Eclipseで1クリックで新規プロジェクトを作るのと同等の時間で準備できなきゃいけなかった。反省。

そして使えると言った言語の分、これを用意しておくべし、ということでした。

もう一つは出だしですね。変に聞こうとしすぎてお互いに「うーんどっちでもいいですね」みたいな時間ができてしまうとすぐに残り時間がなくなっちゃう。設計や実装の選択肢をあらかじめ自分の中にもっと用意しておけば、もっと濃くできたんじゃないかなぁという思いがあります。もちろんペア次第ではあるんですけど。

ただ、今振りかえると、そして coderetreat.org の記述を読むと、これを実現するためには言語は揃ってた方がいいっすね。みんな Java はできそうな感じだったし、本当は Java で揃えた方が

Structure of a Coderetreat

をなぞりやすかったんだろうなと思いました。

あとは道具。

Eclipseが使えないと仲良くなれないw 普段のイベントと違ってMac使いも少ないし、みんなIDE使ってるし、これはやっぱ真面目に普段は使わないけど共通言語にする環境は用意しといた方がいいなぁと思いました。Eclipseよりは軽いし、もうちょっとNetBeansと仲良くなっておこう。

※ おまけ。RSpecでshouldをバンバン使ってしまって、ちょっと今後に対して一部悪い印象を与えた可能性あるなぁと思いました。expectの練習が不足してました。

今考えるライフゲームの構成要素

あくまで自分の考える要素です。以下の要素についてそれぞれ考えて設計、実装できるような気がします。

  • 見た目表現
  • 初期状態のセット方法
  • セルのロジック
  • セルの集合の扱い
    • セルの状態(世代管理)
  • 見た目の有限フィールドとゲームの無限フィールド

これを事前に考えておくことができると、どこをどう攻めるか、濃いペアプロができると思います。

取り組み方のポイントのメモ

  • ペアプロと言語と環境
  • TDDでやるか否か
    • TDDはどこでも題材にできるが、そうじゃないやり方は「好きな場所だけ作る」のはやりにくい
  • ペアプロと教えることと参加者の得ること

TDD が coderetreat では推奨されています。自分もできるならやった方がいいと思いますし、今回は参加者にチェンジビジョンの方が混ざってらしたので、そこかしこで TDDBC が自然と展開されて、「うおーTDDすげぇ」みたいな感想が多かったです。なにこの超お得イベント。

その他の会話

  • 今回参加者分かんなかったですね
    • 分かんない方が学生さんが参加しやすいかと思いまして
    • はーなるほど。学生の参加って課題ですよねー。
  • request specってそんないいすかね?
    • stub, mockばかり使ってると実際のデータでうまく動かないごく単純なパターンを見落としたりすることがあったのと、stubが邪魔で変更しにくくなったことがあったので、自分は最近ModelとRequestを中心にやってます。
  • BackboneとかでフロントでJSの比率増えてくるとReuqestよりControllerの方がやりやすいような。
    • それはあるかもしれないっすね。そこまで自分はやったことないんで分かんないですけど。
  • RubyのblockってSmalltalkみたいですね。
    • うぉ。自分はSmalltalk書けないけど、SmalltalkとLispはパクってるらしいですね。
  • RubyはRailsが強くて迷わなくて済むからいいですね。
    • そうですね、そのうえで何をどう実現する、何のためにどういう活動をする、という話に集中できていいと思います。いつまでもツールの話をやらなくていいのは楽っす。
  • 中学校の数学みたいで面白いですね
    • (セッション一つ、0から8の数字を0と1に変換することだけに費やしましたw)
  • JavaScriptてvar付けないとどうなんの?
    • globalにぶちまけちゃうから意図せず壊れる可能性あるよ
Tags: Study