寝るところを確保してから、実はあまり片付けをしていない。対外的な理由としては「忙しかった」なんだけど、ホントのところは「寝られればいいや」だったかも。今日は仕事から離れて、部屋の片付けとか、昨日買った本(また SW だ)でも読んで過ごしてみよう。あ、夜はおでかけするけど。
いつの間にか時間は過ぎて行く。自分の部屋にも共用部屋にも時計がないのが敗因だと思われる。
関西支部のコジマさんが来堂。黒蜥蜴用の餃子をお客さんであるコジマさんにも手伝って頂く。餃子包みは僕が一番速いと思っていたら、意外にもよきゅんが一番速かった。。。ちょっと敗北感(笑)
黒蜥蜴へ移動。餃子を持っていったものの、フライパンを忘れて買いに行ったり。この日も黒蜥蜴は盛況。僕らも入れれば、常に満席状態といったところ。狭い店内に人が満載なので、中は結構暑くて、ずっと立ちっ放しのよきゅんはキツそうだった。最後の方は特に。まぁ、でもお客さんが来ないよりは来てくれた方がありがたいし、これはこれでヨシとするのが良いだろね。
予定していた片付けは段ボールを開けて、不用品をゴミ袋に入れた程度。読書の方は全くできずといった感じ。
今日は、「Pink in Red」を観たり、「オブジェクト指向プログラミング言語 Ruby」を読んだりして一日の大半を過ごした。
「Pink in Red」の映像って、画面の一部をズーミングしたときに、えらく荒い、、、というかモザイク状の画像になる。
家庭用の DV で撮影して編集した映像なのかな。あんまりライブ系 DVD とか観ないので他の作品と比較できないんだけど、これがもし演出だとしたら、かなりダメっぽい気がする。
この本、実は初版発売当時にも書店で手に取ったことがあった。パラパラと見たときの感想は「面白そうだけど難しそう」だった隼廚Α
当時は、プログラミングとは全く関係ない仕事をしてた(その部署にはパソコンが1台もなかった!)し、趣味のプログラミングも大したことはやってなかった。「オブジェクト指向」もなんのことやらさっぱりで(笑)
でも、いま改めて読み始めてみると、面白い。昔、理解できなかったことが理解できるようになっているので、また格別に。それから、まだ読んでないのだけれど、5章の「オブジェクト指向設計」は今後のためにも非常に参考になりそうなので楽しみ。
そう、これからオブジェクト指向な設計をしようと目論んでるのだ、僕は。都合により Ruby じゃなくて PHP で、だけど。。。
おぉ、凄い!
エピソード2の半年後、メイス・ウィンドゥの活躍を描いた小説「スター・ウォーズ 破砕点」の解説によると、「スター・ウォーズ トリロジー DVD-BOX」には、特典映像として「エピソード3プレビュー:ダース・ベイダーの誕生」が収録されているらしい! うひょ〜!
相手サーバの設定により、接続を許可してもらえないとき、僕は「reject された」と言っていたのだが、「refuse された」と言う人がいてその違いが気になった。
気にはなったが、結局違いがよく分からん。reject の方が拒否感が強いの?
僕がよく使うパターンとしては、「隊長!、メールサーバが DoCoMo から reject されてます!」というような感じだったのだけれど、これはどちらかというと refuse が正しいのか。
よくよくログを見てみると、「sender_was_rejected」と言う場合や「connection_refused」という場合がある。(DoCoMo 宛に限ったログじゃないので、念のため)
前者の場合、SMTP 接続は確立しているが、sender つまり エンベロープ FROM が許可されていないので拒否されたというもの(ドメイン指定受信とか)。後者の場合は SMTP 接続が確立する前に拒否されている。メールの「受け取りを拒否」するから reject で、受け取る前の段階での拒否なので refuse ということなのだろう。
はー、スッキリした。
Yahoo! と Sendmail 社で開発している「DomainKeys」のテスト結果が発表された模様。「CPUのオーバーヘッドは送信トラフィックで約7.8%,受信トラフィックで約15.2%だった」とのことだ。
Sender-ID の場合は、どのくらいパワーを消費するんだろう? PKI より軽い気はするけど。
▽ kdmsnr [受け取りを拒否するのを reject と言うみたいです。 * reject = refuse to accept *..]
ずっと、ずっと、ずーっとこれで最終巻だと思ってたので、味わい尽くして読んでやろうと考えていたら、、、あと1冊出すのね。読む前に気がついて良かった。
いま見ると5巻(平成8年11月29日初版)から「全12巻」として掲載されていたので、足掛け9年近くの想いが今まさにくじかれたよ(笑)
この大会の存在すら知らなかったのだけど、行ってみたら結構良かった。川原の芝生(っぽかったけど、もしかしたらカットされた雑草なのかも)の上に座って観るのは良いね。去年の東京湾大華火祭では、日中に充分熱せられたコンクリートの上に座っていたのでひたすら暑かったんだけど、それと比較したらかなり快適だった。川のすぐ近くだったので涼しかったし。
肝心の花火もなかなかどうして。観たことのないモノも結構あって楽しめた。
帰りがけに寄ったコンビニにモーニングが見当たらなかった。たまに売り切れる店なので、今日もそうなのかと思って、ちょっと離れた別の店へ。
しかし、ここにもモーニングがないィィィと諦めてスゴスゴと帰ってみたら、先週号が合併号だったのか。どうりで見つからない訳だ。
ところで「モーニング2」は、もう出ているんだな。コンビニには見当たらなかったので、書店で探さなきゃ。
声優の鈴置洋孝さんがお亡くなりになったそうだ。56歳だなんて若すぎる。「ブライト艦長の声優鈴置洋孝さん死去」より。
どこかへ出かけたい気分はあったものの、昨日からの体調の悪さと雨が降っていたのが合わさって、一日中家にいた。
そんななか、昨日、修理から戻ってきた iMac で、iTunes Match をオンにした。このサービスが始まった時には既に iMac が故障していたので、ほんとにようやく、という感じである。
まだ全部のアクションは終わってないのだけど、既に iPhone 端末からはひととおりの曲名が参照できる状態にはなったようだ。容量が足りなくて全ての曲を iPhone へ入れることができなかったんだけど、これで「あの曲を聴きたいのに今は入ってなかった!」ってことが無くなるのかと思うと凄いね。
でも、これ、WiFi も電波も入らない場所だと聴けないんだよね、きっと。ドライブ中には常に音楽をかけているんだけど、ときどき電波のないところを通るんだよなぁ、そういうときは iCloud 上にしかない曲はスキップとかしてくれるのかな?
ちょっと事情があって、npm install したパッケージ群(つまり node_modules ディレクトリ以下のファイル)も deb パッケージに同梱している。
deb パッケージをビルドするときには、Sass のコンパイルや JavaScript の minify などのタスクも実行するので、package.json 内の devDependencies なパッケージもインストールしておきたい。
この状態で node_modules ディレクトリを deb パッケージのアーカイブ対象にしておくと、コンパイル時にしか使わない npm パッケージもアーカイブされてしまい、ファイルサイズ的にもアーカイブ処理の時間的にも無駄が多い。
なにかうまい方法はないのかな?と社内チャットに呟いたら、npm prune コマンドでうまくいかないかな?というアドバイスをもらった。
ビルド時には普通に npm install し、その後に必要な処理を実行。deb パッケージを作る直前に npm prune --production
を実行することで、dependencies のパッケージだけを残して、devDependencies なパッケージは削除してくれた。
実は、前述の deb パッケージの作成時間が結構かかってしまっていて、長い待ち時間が発生していた。「こんな処理でいちいちストレスを感じていたらスピーディな開発なんてできないだろ!!」と思って、ビルド中のログを流し見していたら、node_modules 以下のファイルの処理にだいぶ時間がかかっていることに気付いて、今回の対応に至った。
npm prune --production
を実行し、アーカイブ対象を削ったことにより、deb のビルドを大幅にスピードアップすることに成功したので、これからはストレスも減るはず。
細かい改善だけど、ストレスのない気持ち良い開発をしたいと思っているオレ的にはとても満足(でももっと速くしたい)。
▽ yoosee [PHP で OOP は Perl で同じ事をやるのと同じかそれ以上に苦労するので、少なくとも学ぶという段階では Ru..]
▽ mu [http://www.alloha.info InsuRancE http://www.devonanal.com ..]