けいむなさんの
「若い方達の文章はとても似ていると思うのですが同一人物ということはないですよねw」
という警鐘が気になって、過去の書き込みのログをチェック。
同一PC(cookie)から、異なるユーザ名での書き込みというのがある程度確認できだのだが、
というのは問題ではないと判断。 しかし1件だけ、ちょっと悪質な自作自演あり。 通常?のユーザ名と別ユーザ名を使い分け、また某アイドル名を騙ってコメント書き込んだ後にその内容に対して自身でコメントを書き込むなどをしており実際に他のユーザに誤解を与えていた。
確認できる範囲でそのユーザの書き込みを削除。 不毛な作業で疲れた。
Perl 5.8.x だと、Time::Local::gmtime できちんと範囲チェックが動作している(範囲外だと croak される)のだが、Perl 5.005_03 では必ずしもそうではないようだ。 WiKicker のデバッグ中に発見。
でソースを読んでみると、古い Time::Local では cheat サブルーチンで
している。同一年月での2度目以降 timegm 呼び出しでは %cheat キャッシュを使用して cheat サブルーチンを呼びにいかないので、範囲チェックが実行されないという塩梅。 つまり 2003年1月1日… で一度 timegm を呼び出すと2003年1月に関しては以降 cheat サブルーチンは呼ばれないため、次に 2003年1月33日…で読んでもエラーにしてくれないというわけ(最初に2003年1月33日…で呼んだ場合はちゃんとエラーになるので逆に厄介)。
Perl 5.8.0 以降に標準ではいっている Time::Local ではきちんと毎回チェックする。 うるう年・大の月/小の月も考慮してチェックされる(v5.8.0 より前のでは 31 より大きいかのチェックのみ)。
であり、CPAN では 5.005_03 でも動作する Time::Local パッケージ (1.05〜)が公開されている。
Time::Local 1.04 以降を PREREQ_PM にしてもいいのだが、5.005_03 な利用者にとってはインストールするのも面倒か。 最低限のエラーチェックを自前で用意して、互換になるようにした方がいいかな。
先週Webで見かけてからずっと気になっていたスント オブザーバーを購入。
(ヨドバシカメラは次の日の朝、Webで在庫を確認したら横浜店の在庫表示が無くなっていた。やはり展示品のみというのは確かで、在庫管理もきちんと働いている様子)。
ストラップのウレタン部を切るタイプ。 店員がびびりながら調整。 最初4つ分カットしたのだが、ゆるいので12時側をもう1つカット。計5カット。 これでもちょっと弛めなので、ピンの止め位置でさらに調整。 いい感じ。
ちなみに帰って箱を開けたらベルト調節の長さをチェックするためのメジャーがはいっていた。手に巻いてみたら5カットの目盛り。 ばっちりだったようだ。
電池の減りが早いことで有名なようなので、自分で交換もできるようになっているので電池を買っておこうかと。 しかし、電池交換担当者によると自然放電しやすい電池だそうで買っておかない方が良いとのこと。 やめておく。
リストトップ・コンピューターと銘打っているだけあって、いろいろモードや設定があって楽しい。 最初はちょっとわかりにくいが、慣れると一通り操作は覚えられそうだ。 ログブックは使う機会がないと思うので、覚えられないかもしれないけど。
参考基準高度設定用に、順次生活エリアの高度を調査せねば。
スキージャンプ・ペア2を1日遅れで購入。 DVDコーナーのレジ待ちの列で手にしている人を結構みかける。 大人気。
今日は時間がないので鑑賞はおあずけ。
今年もイラスト集は去年と同じくインプレスので。CD-ROM 2枚組の方。 CD-ROM 3毎組「年賀状CD-ROM 2007」より、こちらの方がバランスが良い。
5種類上がった候補をテスト印刷してチョイス。年号もイラスト集から選んで組み合わせて差出人宛名を入れて完成。
そういえばこの間母の実家跡を Google Maps で見つけたの思い出して見せてあげた。 「最近はこんなのも見られるんだ」と感心しつつ、故郷を思い出していたようだ。
年賀状作成にきたということで知人の住所が揃っているので、あの人の家やこの人の家の場所やらを上空から確認してみたり。 引っ越してしまって一度も訪問したことのない人が、「こんな所に住んでいるんだ」と興味津々。
今年は妻と3人で、駅前で中華料理屋で外食。
母「うちはお父さんがあまり外で食べるのが好きじゃなかったので、あまり連れていってあげなかったねぇ」
この nDiki はローカル PC 上で Emacs で記事ファイルを書き、出来上がったら Unison で Web サーバと同期させる形でアップロード・公開している。
この方法で一つ問題なのは「書きかけの記事ファイル」の扱いが面倒なこと。 書きかけの記事ファイルがある状態で Web サーバと同期するとそれが公開されてしまうのでまずい。しかし完成している記事ファイルがあるならばそちらは同期して順次公開したい。 同期する時には書きかけの記事ファイルを退避させればいいのだが、思いっきり面倒。
ということで手元で公開用 (Web サーバ と同期用)のディレクトリツリーと、ドラフト用(ローカルの Web サーバでのレビュー用)のディレクトリツリーを分けられるようにすることにした。 この2つのディレクトリツリーの差分となる草稿・更新ファイルは aufs を使うことで簡単に管理することができる。
aufs は stackable unification filesystem の一つ。 同様なものとしては UnionFS がある。 UnionFS よりも aufs の方が評判が良いようなので今回は aufs を使うことにした。
aufs では複数のディレクトリ(ブランチと呼ぶ)をオーバーレイさせて、1つのディレクトリとして扱うことができる。 公開用ディレクトリツリーに、ドラフト用ディレクトリツリーをオーバーレイさせることで、元のディレクトリには変更を加えることなく透過的に変更できる仮想的なディレクトリツリーを作ることができる。
Debian GNU/Linux sid へはkernel 再構築とあわせて module-assistant でインストールした。
以下のように3つのディレクトリを作ってマウントする。
mount -v -t aufs -o br:/home/naney/draft.naney.org=rw:/home/naney/www.naney.org=ro none /home/naney/next.naney.org
公開ディレクトリツリーは read only に、草稿用のディレクトリツリーは read - write になるように指定する。
これで /home/naney/www.naney.org 以下はいじらないまま、/home/naney/next.naney.org 上で草稿を書いたりファイルを編集したりすることができる。 /home/naney/next.naney.org 以下で追加したファイルや、変更したファイルは aufs が /home/naney/draft.naney.org 上に保存してくれる。
完成したものを /home/naney/draft.naney.org から /home/naney/www.naney.org に順次反映させ(移動し)、公開サーバへ同期することで公開していくことができる。
手元ではいろいろ書き散らせておけるのは、これは便利。
マウントオプションは他にいろいろあるようなので、こまかい設定は見直すかも。
ファイルシステムレベルの処理なので、アプリケーション側では何も手を加えなくてもよいのが良い。
今回は公開用とドラフト用としたが、公開用と未公開用をローカルでミックスして表示するようにしたり、複数ユーザのコンテンツディレクトリを仮想的に1つにまとめたりと、いろいろ面白い使い方ができそうだ。
ThinkPad X31 に入れている Debian GNU/Linux sid の Linux kernel を随分アップデートしていなかった(2.6.17 を使用中)。 今日 aufs を入れついでに、一緒に最新(2.6.23)をビルドすることにした。 Debian kernel パッケージ構築は去年の8月以来。
今回は linux-patch-aufs を入れておいて、aufs 用のパッチを当てる。
#apt-get build-dep linux-image-2.6.23-1-686 #apt-get install linux-source-2.6.23 linux-patch-aufs #exit $mkdir -p /usr/local/src/linux $cd /usr/local/src/linux $tar jxvf /usr/src/linux-source-2.6.23.tar.bz2 $cd linux-source-2.6.23 $make menuconfig $make-kpkg clean $fakeroot make-kpkg --added-patches put_filp,lhash,splice,ksize,sysfs_get_dentry --revision=sebastian.1.0 kernel_image $cd .. $su #dpkg -i linux-image-2.6.23_sebastian.1.0_i386.deb
パッチが一部 2.6.22 用で 2.6.23 には当たらなかったが、よしとしておく。 ここで再起動。次に MADWIFI と aufs をインストール。
module-assistant prepare module-assistant auto-install madwifi module-assistant auto-install aufs
いつも入れている shfs も同様に入れようと思ったがこちらはコンパイルエラー。 頻繁に使うわけではないので、とりあえずほっておくことにする。
コンパイルが面倒なのでそろそろ Debian 公式のを使おうかと思ったが、試してみたところ
ということ NG。 やはり自前でビルドしなければならないことを再確認。
17年ぐらい使ってきた炊飯器(91年製 タイガー 炊飯ジャー JNQ-0722 NP 直接加熱式 0.72L)に限界がきた。内蓋の蒸気口のプラスチック部品のポッチがもげた。 電源プラグも自分で修理して使ってきたけれどもういいだろう。 1991年製だからって「便利な電源スイッチつき」とはアピールしすぎなおちゃめな炊飯器だったのだが。
ということで炊飯器を新調することにした。調べたところサンヨーのやつがいいらしい。 価格.com で売れ筋ランキング1位は ECJ-JK10。 評判も良いしこれに決めた。 情報を集める前は「2万円弱ぐらいまでかなあ」と思っていたが、圧力 IH 炊飯器だと普及クラスでもそこそこするのな。
ヨドバシカメラで 39,800円。昨日の昼休みに見にいったらセール中で、36,800円。12月23日まではさらに下がって 33,800円というので家にメールして OK をとり、帰りに買って帰ってきた。 家電フロアですれ違った炊飯器を買って帰る人はみんな「おどり炊き」だった。大人気。
作り的には、圧力系ということもあり内蓋の構造などが複雑で、パッキンなんかもちょっと軟弱な感じで寿命はどれぐらいなのか気にかかるところだ。 10年使えるかなー。
で今日初炊き。
今までが今までだっただけに感動的に味が変わるのかなとちょっと期待したのだが、まあ流石に同じ米なので自分の舌ではそんなに味は劇的に変わった気がしなかった。
しかし米粒感ははっきり違う。 炊き上がりを見て「今までの炊飯器で炊いたのと見た目おなじぐらいの柔らかさだな」と思っていたのだが、口にしたら食感が違う。 新しい炊飯器の方が、固くないのに米粒感がしっかりあり、口のなかでばらける感じ。
そういう意味ではやはり数段おいしく炊けているなという評価。 うちごはんがより楽しくなった。
今年もクリスマスイブは平日なので、休日の今日にささやかなホームパーティーを。
昼間にデコレーションケーキ作って食べて、夜は近所の肉屋で買ってきたローストチキン。 ささやかだけれど家クリパ楽し。
naney.org メールサーバの移転に次いで、Web サーバの移転作業。
現行 Web サーバと Unison でファイル同期している Web コンテンツを、さくらのレンタルサーバへ Unison でファイル同期。
nDiki 用に DiKicker (WiKicker) を make install。
%bash $perl -MCPAN -e mkmyconfig $perl -MCPAN -e shell o conf makepl_arg PREFIX=/home/naney/local/WiKicker o conf mbuildpl_arg --install_base=/home/naney/local/WiKicker o conf commit notest install CGI::SpeedyCGI $tar zxvf WiKicker-0.420.tar.gz $cd WiKicker-0.420 $export PERL5LIB=$HOME/local/WiKicker/lib/perl5/site_perl/5.8.9 $perl Makefile.PL PREFIX=$HOME/local/WiKicker $make $make install
以前きっちり Module::Install で Makefile.PL を作っておいたおかげで、比較的スムーズにインストールできた(自画自賛)。
ちょっとはまったところは CGI::SpeedyCGI の make test を実行する(される)と SSH 接続がサーバ側から切られてしまうという現象にあったところ。 テスト用に大量にスクリプトが起動されるの検出して自動的に kick されたのだろうか。
さくらのレンタルサーバでは .htaccess Options が使えないようなので削除。 ExecCGI や MultiViews が有効になっているようなので問題なし。
Perl 5.005_03 用に書いてあったスクリプトについて、Perl 5.8.9 で文字化けしないように utf8 まわりを修正。
1時間毎に実行したい処理を列挙するシェルスクリプトを1つ作って、コントロールパネルから1時間毎に実行するように設定。
現行サーバでは任意の crontab を設定できたので、1時間毎はちょっと物足りない。 おいおい負荷にならない範囲で、外部から定期的に HTTP アクセスして処理を定期的に実行できるようにもするかな。
まだ動いていないスクリプトもあるけれど(大きいところだと NaneyOrgWiki (Wiki))現行サーバの解約日もせまっているので、サーバ移転させてしまうことに。
VALUE-DOMAIN で DNS サーバ設定を変更し www.naney.org でさくらのレンタルサーバにアクセスできるように A レコードを変更。
今のところ特に重い等もなく順調。 現行サーバでは深夜非常に重くなる時間帯があったのだが、それが無くなるのが嬉しい。 また容量が100MB*1から10GB*2になったので心理的にセーブしなくて良くなった。
年内に移行できて良かった良かった。
[ さくらのレンタルサーバ プレミアム ]
HipChat は first name と last name を要求するところがイケてないので last name を LEFT-TO-RIGHT OVERRIDE (LRO) U+202D にした。
IM によって入力方法が違ったりして U+202D の入力方法を覚えていないので HTML ファイルに書いたのを Web ブラウザで表示させてコピー&ペーストして入力。
Naney ‭!
と HTML ファイルに書いて Web ブラウザで「Naney !」と表示されているところを範囲選択しコピーし、そのあと HipChat の full name のところにペーストする。そして「!」をバックスペースで削除して保存。
去年まではチキンレッグだったのですが、今年は丸ごとローストチキンにしてみました。チキンレッグ同様コープので、口にあう味付けで満足です。ケーキも作ってもらって良いクリスマスパーティーでした。
日記に貼る写真を Flickr ではなく同じサーバに置くことにしたので、スマートフォンで撮った写真を都度 MacBook Pro にいったん移す必要が出てきました。
Xperia Z5 から PC にまとめて写真を移す際は Solid Explorer FTP Server を実行して PC から取りに行くようにしています。がちょっと面倒。
せっかく Synology DiskStation DS216j (NAS) を立てたのでここを経由する方法に変更しました。
これでスマートフォンから Solid Explorer や iFiles 2 で NAS 上の共有フォルダにコピーしておけば、MacBook Pro 側に自動的に同期されてすぐに写真を利用できるようになりました。 MacBook Pro 側で利用・整理が終わった写真ファイルを同期フォルダ上で削除しておけば NAS 側からも消えてくれるので二重管理にならなくて楽ちんです。
35mm フィルムで撮っているうちにチェキが欲しくなって instax mini 70 を買いました。初代チェキ instax mini 10 ユーザー(18年前の1999年12月28日購入)で400枚以上は撮っていたのですが、何年か前にもう要らないかなとカメラは処分しちゃってあったので、今回が2台目のチェキです。
イマドキなスクエアフォーマットの instax SQUARE SQ10 も気になりましたが instax SQUARE フィルムは高価で気楽に撮って楽しめなさそうなので instax mini フィルムのにしました。
以前使っていた経験から
の条件を満たすものから選びました。(チェキは寄るとパララックスがかなり発生するので)「接写モード用視差補正機能付き」、また明るいところで明示的にフラッシュを禁止できる「フラッシュ発光禁止モード」がある高機能な instax mini 90 とも迷ったのですが
とデフォルトの挙動的には instax mini 70 の方が使いやすそうだったので instax mini 70 にしました。
初代チェキは電源を入れた時に鏡胴がせり出す音や、撮影後にフィルムが出てくる時の音が爆音で耳障りなのがイケてなかったのですが、instax mixi 70 はさすがにそんなことは無くていい感じ。それから安定して立てて置いておけるのも何気にグッド。
久しぶりにチェキりましたが、撮った写真をすぐに見られるのやっぱ楽しいですね。
ちなみに初めて今回絵柄入りフレームタイプも買ったのですが、天地があるキャラクター物はかわいいけど横位置で撮るのに躊躇して撮影に制約が出てちょっと不便に感じました。普通の白いのが書き込みもできるし良いかな。
[ 製品レポート ]
今日は Spotify で「お気に入り」や「クリスマスソング」のプレイリスト作りをしてみた。「このプレイリスト内の曲をもとにしたおすすめ」で、あっ、これもこれもとなるのが楽しい。ただこれだと古い曲ばかりになってしまうので、最近の曲からも好きな曲を見つけていきたいな。
夜は今シーズン初の鍋。ちゃんこ。
サンクス。
— Naney (@Naney) December 23, 2018
GIZMON #Utulens pic.twitter.com/5HwXDs5m9U
先週の月曜日に渋谷スクランブルスクエアの新オフィスに移転してから1週間。
Google マップで職場設定をして経路検索したりロケーション履歴を修正したりしたいので Google マップに新オフィスの場所を追加した。いまだに Pixel 4 だと執務室は平和島に位置することになっているのが直るのにも貢献できるといいな。
Markdown ファイルを iA Writer で Web プレビューしたものを Google ドキュメントに貼り付けて共有する(記事1)時、画像データをデータ URL 化して Markdown ファイルに記述すれば一緒に貼り付けられることが分かった(記事2)。
でもやっぱり管理が面倒くさい。
そこまでするなら「別のアプリで self-contained HTML に変換」→「Web ブラウザで表示」→「コピー & ペーストで Google ドキュメントに貼り付け」を実行する方がいいのでは。いったん HTML に書き出すのが嫌だなと今まで思っていたけれど。
と思って調べたら、インストールしてある Marked 2 が self-contained HTML に変換できたし、Google Chrome で表示して全選択からのコピー & ペーストで画像付きで Google ドキュメントに貼り付けられた。
こちらの方法にしよう。
寒空。渋谷横丁。#photography
— Naney (@Naney) December 23, 2020
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/I2OIS9M9ec
「シルコット ピュアウォーター ウェットティッシュ」ワンプッシュで開けられて便利だ。去年出たムーミンデザインのが欲しかった。
— Naney (@Naney) August 24, 2020
2020年8月に「シルコット ピュアウォーター ウェットティッシュ」の本体を買う際、以前にムーミンデザインのものがあったことを知り、欲しかったなあと思ったのだ。
家にもウェットティシューを用意しておきたいなと最近思ってふと調べてみたところ、ムーミンデザインが今年も発売されていたのを知って、ビックカメラ 渋谷東口店で「シルコット ノンアルコール除菌ウェットティッシュ本体45枚ムーミン21」を買ってきた。やった。
社員証の更新用に写真撮影してもらった写真データを一昨日調整してプロフィール写真にしたのだけれど、ちょっと顔が赤い印象なのが気になってきた。特に縮小して表示されると気になる。色相と彩度をちょっと調整して差し替えた。
109#photography pic.twitter.com/u3cTcl5Ft9
— Naney (@Naney) December 23, 2021
今朝ぐらいから各 Tweet の表示回数が、自アカウント・他アカウント問わず表示されるようになった。
自分の Tweet のインプレッションは以前から Twitter Analytics で確認できるものだったとして、他アカウントのインプレッションが分かるようになったのはかなり興味深い。他のアカウントの Tweet 表示回数を眺めるなら最新ツイート表示よりもホーム表示の方が面白いな。
いいね数・Retweets 数に加えて表示回数という影響力の指標(のように感じられるもの)が増えることで、否が応でも他人と比較してしまうのは人間の性であり、憂いてしまうのも性である。
今回の変更に対する不満の声が多くタイムラインに流れてくるのも分かる (不満でなければわざわざ意思表明しない人が多いという非対称性がありつつ)。
他のアカウントのインプレッションが分かることは結構面白い。一方でもちろん心がざわざわしたりもする。 TweetDeck・Tweetbot・twitcle plus と Tweet 表示回数が目に入らないクライアントを併用してうまく心理的バランスを取りながら楽しみたい。そもそも恒久的な仕様になるかもわからないしね。
自分の Tweet の表示回数は強力な変動報酬 (variable reward) であり行動の習慣付けに対する影響力となる。プロダクト視点だと、リテンション向上につながるので表示できるなら表示した方がいいだろう。他人との比較というストレスを増やすので、他のアカウントの表示回数表示がプラスに働くかマイナスに働くかは未知数。これはリリースし実験結果をみて判断するのが良策なので、今回の動きはありだと思ってる。
Tokyo#photography
— Naney (@Naney) December 22, 2022
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/3xXqX5PVvl
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。