最終更新: 2017-09-06T19:57+0900
写真も動画もとってない(追加予定)。
場所は左のフロントフォーク。フォークがねじれたときに緩めて締める下の方のブラケットに、元からあったブレーキホースのガイド共々共締めした。おもちゃを構造部にってどうよとは思ったが、ここがベストポジションだと思ったんだよねえ。次点はウィンカーの上、ヘッドライトの上部を固定するボルトに共締めして。次次点はハンドルバー。どんどん上方に移動して目立ってくるのが嫌。目立てば盗難を警戒しないといけなくなる。安くなっても 16000円はしたのだから。というか、カメラを構えるとか撮影するとかいう行為がひどくプライベートで恥ずかしいことに感じられるので(鏡を見るとか食事もそう)、他人に気取られたくないというのが第一。その点 lowerブラケットの横だと、正面からはヘッドライトの右、ウィンカーの下、シュラウド内側の黒プラスチックを背景にして収まることになる。ハンドルをロックした状態ではシュラウドに包み込まれて手をつっこむ隙間もない。シュラウドとカメラがぎりぎり接触するので半センチほどブレーキホースガイドを押しのけたくらいのぴったりさ。
ホームセンターで L字の短いステーを1つと M10のキャップボルト(アーレンキーで回せるやつ。携帯ツールで一番太い、自転車のクランクを外すときに使うのが合う太さだった)・ナットを1組買ってきて、あとは NECKER付属のマウントを使った。プラスチックがしなるとかすぐ割れたとか聞くけどもとりあえずは。付属してきたティーメジャーのような形のステーに開いてる、三脚穴ではない方の穴は 1cm。買ってきた L字ステーに2個開いてる穴も 1cm。だからステーとステーの連結は M10のキャップボルトにしたんだけど、共締めさせてもらうフォークのロアーブラケットピンチボルトは M8。穴が大きすぎるので M8のワッシャー(9円)だけまた買いに行ったさ。
ステー単体だと素手で曲げるのは難しいんだけど、2個を連結してその先に重いカメラ(※)が乗っていれば結構しなる(それは 3Mの VHB(=付属品画像に見える赤いシールのやつ)をそのまま間に挟んでるのも理由だろうけど)。明日の録画がどれだけひどいか、ましてカメラが脱落しないかが心配だ。USBケーブルを既設のケーブル類と一緒にハンドルに固定したので、NECKERの特長のひとつである USBケーブル一体型の防水キャップが一体のままである限りは、スポークに届く位置までは落ちなさそう。ストラップホールはケーブル一体でないキャップには付いてた。直径方向に 2mmの穴が貫通してるだけなのでケータイストラップみたいなのは使えないけど。
※三脚穴に対応したネジはカメラのアクセサリだろうと、ビックもヨドバシも近くにはないし、カメラを売ってるなら電気屋も同じだろうと2件寄ってみたんだけど、つまんないね。何を売ってるんだろう。高すぎるメモリーカードをずらずら並べて、プリンターのカートリッジを一面に並べて、(パッケージ版の!)ゲームソフトを扱う一角があって、それってこち亀を全巻陳列するくらいの場所の無駄だし、客にそこから選ばせるのもまた無駄だし。ソニーのアクションカムの実物(※コードにつながれていたので本物だろう)が画像で見るよりひとまわり小さかったのと、持ったときに中身の詰まった重さを感じるのが全体のごく一部で、全体としてものすごく軽い(でもたぶんバッテリーは入ってなかったんだろうな。バッテリーは中身詰まってるし、総重量のおよそ 1/5を占めるみたいですよ)というのが発見できただけ。欲しいものは置いてないし見逃せないものもないし、ホームセンターの目移りするわくわく感との落差よ。昔は電気屋のチラシって眺めてるだけで楽しめたのにね。
マイクは電源ボタンの反対側。数少ない YouTube動画では高音が反響したような耳障りな音ばっかり聞こえてくるので、素の状態からどうにかしてましにしなければいけない。参考にできる NECKERの成功例は?
「共締め」ってどう読むのか正しい言葉なのか検索したときにヒットしたたいそうなお役立ちサイト>「ねじ」のゆるみ ねじのことならコムウエル・フジサワ。勉強になります。
連番だと PCにコピーしたときに名前がかぶる可能性が高いし、動画の撮影開始時刻、終了時刻という重要な情報がファイルの作成日時、更新日時という失われやすい場所にだけ(※)保存されてるというのも不安なので。※映像から読み取れればいいんだけどね。
/* [NECKER V1P] renamer.js NECKER V1 Plusが保存する動画ファイル CAR_XXXX.MOV, SOS_XXXX.MOV, TLP_XXXX.MOV の連番部分(XXXX)をファイル作成日時(YYYYMMDDHHMMSS)で置き換える。 CAR_XXXX.MOVで確かめた限りは、ファイルの作成日時と更新日時は 動画の撮影開始時刻と終了時刻と一致するようですよ。 SOS_XXXX.MOVはちょっと特殊かもしれないけど。 メモリーカードから PCにコピーした場合、ファイルの更新日時は維持されるけど 作成日時はコピーした日時(コピーファイルの作成日時)で上書きされるみたいですよ。 だからこのスクリプトはメモリーカード内の \DCIM\100__DSC フォルダで実行しないとダメですよ。 */ var FSO = new ActiveXObject("Scripting.FileSystemObject"); var Dir = FSO.GetFolder("."); var FAC = {Normal:0, ReadOnly:1, Hidden:2, System:4, Volume:8, Directory:16, Archive:32, Alias:64, Compressed:128}; var Reg = /^(CAR|SOS|TLP)_[0-9]{4}\.MOV$/; for (var it = new Enumerator(Dir.Files); ! it.atEnd(); it.moveNext()) { var file = it.item(); if (file.Attributes & (FAC.ReadOnly+FAC.Hidden+FAC.System+FAC.Volume+FAC.Directory+FAC.Alias)) { continue; // 属性持ちには触らない。非ファイルには用がない。 } var m = Reg.exec(file.Name); if (! m) { continue; // NECKERの動画ではない。 } var t = new Date(file.DateCreated); var time = ("000"+t.getFullYear()).slice(-4) + ("0"+(1+t.getMonth())).slice(-2) + ("0"+t.getDate()).slice(-2) + ("0"+t.getHours()).slice(-2) + ("0"+t.getMinutes()).slice(-2) + ("0"+t.getSeconds()).slice(-2); var newname = m[1]+"_"+time+".MOV"; for (var i = 1; i < 10; ++i) { // 無印と(2)から(9)までリネームを試します。 try { file.Name = newname; break; } catch(e) { newname = m[1]+"_"+time+" ("+(i+1)+").MOV"; } } }
カウルが写ってるのは昼の動画よりポイントが高いが、空の狭さが大きなマイナス。マウント位置を下げてやや上向けるか?
だいたい4分の1のサイズに圧縮してる。ナンバーは元から読めません。止め絵の画質的にもスピード感的にも品質設定をフルHD/30fpsの方にしようかな(<画質は良くならないわりに動きの滑らかさは低下するので、やっぱり 720/60fpsがいい)。DSC-HX30Vで以前撮ったフルHD/60fpsの動画もあるんだけど、音が全然違うよね。低音があるおかげであちらは聞きやすい。NECKERのも YouTube動画から予想してたよりはましな音で、ミュートするまでではなかったが。
画面の一部に夕焼け空が写ってる場面では肝心の前方が暗くつぶれてしまってた。旧機種ではホワイトバランスをはじめ細かくセッティングをしていたらしいが、自動調整で面倒を解決とはいかなかったか。
右下のカメラ名と時刻表示は消せない。DSC-HX30Vがするように字幕扱いでもなく、画面に埋め込まれてる。
最終更新: 2017-05-16T22:39+0900
index.rbのパーミッションをすべて落としたんだって。そうやるんだ。
日記を書くと長々待たされたあげくエラーになって、どうも category.rbに原因がありそうだとキャッシュを削除したり再作成しようとしたらそれも長々待たされる理由になって、parserキャッシュを含めて cacheフォルダをあらかた掃除したらとうとう更新(update.rb)だけでなく参照(index.rb)も終わらなくなっていたらしく、index.rbが夜の間に止められていました。
詳細はここに書いた>http://tdiary-users.osdn.jp/cgi-bin/wforum/wforum.cgi?mode=allread&no=6793&page=0
evalの第3引数を "category.rb:619:#{ymd}p#{idx}"
(619は #{__LINE__}
とかが使える?)にしてシンタックスエラーを引き起こすもとを探ったら、5年前のこの日(20111209)の日記が原因だったとかね。実はときどき日記の更新がエラーを起こすのは経験してたんだけど、変更自体は反映されてたし、裏で延々実行が続いてるということもなかったので知らんぷりしてたんだ。それが5年?
この日記はいろいろ魔改造が施されてるので CPU酷使の原因が category.rb にあるとは限らないし、そうであると考える理由も今のところ持っていません。実際5年間深刻な問題は起こっていなかったわけで。ただ、index.rbを止められたのをきっかけに category.rbを修正したら昨日からの問題が解消したので 、index.rbのパーミッションを怖々元に戻してみて今のところ過負荷は生じていないみたいだってことです。最初は x-math.rb(これは evalよりも大胆かもしれない print関数の乗っ取りをやっています)とその他エラーメッセージに出ていたいくつかのプラグインに原因があると疑って試行錯誤していたので、もはやなにが原因でなにが奏功したのかは藪の中といってよいでしょう。
コメントするために GitHubのアカウントを取った。デフォルトのプロフィールアイコンがあまりにもクソ雑魚ナメクジだったので、あわててペンタブ付属のフォトショップエレメンツ9を起動した(初回起動だった)。スカートの中に光源を配置したり、円形のグラデーションをアルファチャネルに設定したり、フォトショップはやりたいことが探せばちゃんとできるようになっている優秀なプログラムだった。自分の想像の及ばないすごいこともできるのだろう。でも Windowsネイティブではないから、数字入力フォームで[End]キーを押してもカーソルが末尾に移動しなかったり、リストで先頭の文字をタイプしても項目が選択できなかったり、戸惑うけど我慢するしかないね。使いたいもんね。
正直なところリンクを張るにあたってどれを指せばいいのかよくわからなかった。ブランチ作成、コミット、マージ、ブランチ作成、リバート、マージ、ブランチ作成、コミット、コミット、マージ、の最後のマージを指すつもりで #596のプルリクエストにリンク(※2番目の方)を張ったんだけど、これでいいの? ていうか活動の流れと全貌がさっぱりわからん。
昨日「もうGitは怖くない: 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記」を読んで理解したにわか知識によると、コミット(リバートももちろんコミット)とマージは同じ種類の実体(コミットオブジェクト)によって表されるらしい。ただし、コミットは親が1つでマージは親が2つ。親というのは変更の元にしたコミットオブジェクトのこと。親子それぞれがファイルシステムのスナップショットとでもいうものを保持しており、その差分を求めることで変更の内容がわかる。ブランチはコミットを継ぎ足す先を指し示す先導役で(実体は refs/heads/の中)、先導役が異なればコミットの列は別方向に伸びていく(枝分かれしていく)。枝分かれして以後の変更の蓄積としてのブランチは、たとえば masterブランチを構成するコミット集合との差集合を求めれば出るとか。
とりあえず4章でストップしてた『[単行本] 濱野 純(Junio C Hamano)【入門Git】 秀和システム』をまた読んでるけど、もう7年も前の本ですよ、これ。いやぁ(略)。アマゾンのカスタマーレビューを読むと gitが幅広い人に使われてるのが想像できるんじゃないかな。
- シンタックスエラーをうまく回避して日記サービスの利用者が信頼済みコードのコンテキストに這い出ることができるのかはよくわかりません
たとえばこういう日記を書く(※アンダースコアは例によってスペースに読み替える。日記サーバーが Windowsでないなら cmd /C dir
は ls
にするとか)。
! [cat] title _ _BODY _BODY=File.new("./zzz.txt","w").write(`cmd /C dir`)#
古い category.rbは以下のように保存しておいたプラグインロード時のバインディングで evalをする。
@conf.shorten(eval(body.untaint, @binding))
evalされる bodyの中身はこうなっている。
text = apply_plugin(<<'BODY', true) <pre> BODY BODY=File.new("./zzz.txt","w").write(`cmd /C dir`)#</pre> BODY
通常はユーザー入力たる日記のソースは ERB(eRuby)スクリプトに変換されたものがそっくり <<BODY
~BODY
で囲まれて apply_pluginへ引き渡され、セキュアモードなら $SAFE=4
で実行される。
上の例ではユーザーの入力した日記がほぼそのまま(※リダイレクト記号(<>)は <>に変換されたりする)、3ステップある(3ステップに分断された) Rubyスクリプト(1.apply_plugin, 2.定数(BODY)代入, 3.定数(BODY)参照)の2ステップ目を構成している。apply_pluginの文字列引数ではなく、apply_pluginと同列の Rubyスクリプトである。
index.rbのディレクトリに zzz.txtファイルが作成されたりしてませんか? ウチだけですか? シンボリックリンクがどうとかパーミッションがどうとかでも結果は変わりそうだけど……。そもそもセキュアモードでないならこれができても良かったんだっけ?
うーん、どうなんでしょうね。日記ホスティングサービスの制限っていうのがわからないんだよね。たとえば(tDiaryをベースにしてる?) Hikiだと単独のプラグインメソッド呼び出ししか許さないように独自にプラグイン記法をパースしていて、ただの文字列埋め込み({{"ここにタグなりなんなりを自由に書く"}}
)すらできなかったりする。もちろんそれができるとなんの工夫も必要のない XSS脆弱性が悪意ある不特定の書き手に晒されるわけで、今思うと当然なのだけど。
最近は(といって一年半前の日付だ)「[第一] クラウドへの移行を始めます」というアナウンスがあったりもして、クラウドなんてさっぱりですよ。ユーザー単位で仮想化されていて(※)、悪さをしても損をするのは自分ばかりなりけりってことになってんだろうか。
※「仮想化する」って意味を十分に説明していない気がする。何を仮想化したの? 仮想化されたそれがどうしたの? 「仮想マシンを専有していて」と書くとどうだろう。実態にあっているだろうか。
参考@2016-12-24>「原理原則で理解するDocker - Qiita」 例えば Dockerなら、プロセス毎の名前空間という、仮想化よりはゆるい仕組みによっている。
悪さの想定内容がそもそも古いんだよなー。能力の誇示や破壊なんてのは昔の話で、いまどきはみーんなお金だもんなー。お金になるから、お金になることを、する。
ぼそり。typo? >refeter
class FakeCGI < CGI def refeter; nil end def user_agent; nil; end def mobile_agent?; nil; end def request_method; 'GET'; end end