自分仕様なMacBookの快適なところ - ザリガニが見ていた...。
iPadは場所を選ばず手軽に使えて便利なのだが、結局のところ、MacBookの代わりにiPadで作業しようとする限り、MacBook以上に快適に作業できることはなくて、現状ではiPadでの作業はMacBookに比べて冗長になる。（もちろん、iPadでしかできない作業とか、iPadが得意な作業というのもあって、例えば、現在地を絶えず追跡しながらカーナビのように地図アプリでナビゲーションするとか、PDFをまるで紙の本のように再現するとか。） たぶん、長年MacBook（のようなマウス＆キーボードUIのパソコン）を使ってきて、その環境での作業が慣れているせいもあるかもしれない。それに、そもそもマウス＆キーボードUIには25年以上の歴史があり、その中で常に進化し続けてきた。今のMacBookは、すべてがマウス＆キーボードUIに最適化され、かなり成熟した作業環境になっているはずなのだ。さらには、自分
Snow Leopardを上書きインストールしてみた - ザリガニが見ていた...。
OSをバージョンアップする時は、現在の作業環境はそのままに、OSの機能だけバージョンアップできるのが理想だと思う。具体的には、アップルメニューのソフトウェアアップデートのような気軽さでバージョンアップしたい。 しかし、OSの内部に大きな変更があると、それまで使ってきた環境がOSの動作に思わぬ悪影響を与えることが多かった。だから、トラブルを最小限にするため、新規インストールして、必要なファイルを手作業で地道にコピーするのが一番信頼性が高い。ところが、ここ数年のMacBookにインストールしてきたソフトウェアは（UNIX系のソフトウェアも含めて）半端なく多い。手作業で移行なんてもはや考えられず、従って、移行アシスタントや上書きアップデートを試みることになる。 60GBの外付けHDに、Snow Leopardを実験的に何回かインストールして、大きなトラブルがないことは確認できた。いよいよ、メイン
マルコフ連鎖で日本語をもっともらしく要約する - ザリガニが見ていた...。
そもそも、マルコフ連鎖とは何なのか？全く聞いたこともなかった。そして、文章を要約するのはとっても高度なことだと思っていて、自分のレベルではその方法を、今まで思い付きもしなかった。 しかし、以下のようなシンプルなRubyコードでそれが出来てしまうと知った時、目から鱗である...。一体、何がどうなっているのだ？コードを追いながら、マルコフ連鎖を利用するという発想の素晴らしさを知った！ 作業環境 MacBook OSX 10.5.7 ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] mecab utf8環境でインストール済み マルコフ連鎖に出逢う rssを流し読みしていると、以下の日記に目が止まった。（素晴らしい情報に感謝です！） MeCabを使ってマルコフ連鎖 一体何が出来るコードなのか、日記を読んだだけではピンと来なかっ
MacBook Leopardのクリップボードを最もシンプルかつ自由に拡張してみる - ザリガニが見ていた...。
クリップボードっていうのは、（おそらく）一日一回はお世話になるはずのコピー＆ペーストをする時のコピーデータの一時的な保管場所のこと。にも関わらず、普段使っている分にはクリップボードは目に見えることもなく、コピー＆ペーストの仲介人としてひっそりと、でも確実に処理をこなす縁の下の力持ち的な存在なのだ。 もしもクリップボードがない世界*1を考えてみると、それは相当使い難いOS環境になってしまうだろう。（はてな日記の下書きとしてスティッキーズに書いたとしても、さて、どうやってアップロードしようかと悩んでしまう...。） このとっても便利なクリップボードという仕組みは、OSX標準では常に一つのクリップボードだけが提供されてきた。そうすると、みんな考えることは同じで、複数のクリップボードを使い分け出来たら便利なんじゃないだろうかと。試しにgoogle:OSX クリップボード等で検索してみると、様々なク
restful_authentication + ruby-gettext + form_forで権限管理付きログインページの雛形を作る（日本語版） - ザリガニが見ていた...。
restful_authenticationに権限(role)管理を追加して、実用的に利用するカスタマイズ例として、Restful Authentication with all the bells and whistlesを参考にいろいろ考えてみた。コードを読みながら、次第に以下のような疑問や考えが浮かんできた。 メール送信処理のきっかけに、なぜobserverを利用するだろうか？ observerはコールバック（before_createとかafter_save等）を外部のオブザーバーオブジェクトで処理するようなもの。 モデル自身のコールバックとして処理しても良いはず。 restful_authenticationの実装を見ると、コールバックの中で条件によって処理を分岐するために、モデルの状態をインスタンス変数にわざわざ保存している。 例：@activated = true、@forg
restful_authenticationでパスワードを忘れた時の処理を考える - ザリガニが見ていた...。
パスワードは必ず忘れられる運命にある...。開発者側の立場であれば「パスワードくらい自分でちゃんと管理しておくべき」と言いたくなる。しかし、自分がユーザーであれば、パスワードを忘れて不便を感じている時「パスワードを忘れた場合」なんてリンクがあると、多少は救われた気がする。そこをクリックすれば、パスワードをリセットなり、再発行して、再びログインできることを夢見ている...。 ところで、restful_authenticationには「パスワードを忘れた場合」の処理は特にない。特に無いけども、最初にユーザー登録した時、アクティベーションを促すメールで、ユーザー名とパスワードも送信している。開発者側の立場であれば「過去にメールを送信しています。ご自分で検索してみてください。」で終わりにしたい。しかし、自分がユーザーであれば、「過去のメールは消えてしまった。」とか「自分のパソコンじゃないから検索で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
