Lambda

2020年の日記

12月31日の日記

大晦日なので,1年を振り返ってみたい.

年が始まったことには新型コロナウイルスの流行がここまで広まるものとは思いもしなかった.様々な出来事が感染対策とともにある1年だったと思う.

まず,外出をするハードルは高くなった.Go Toトラベルの支援もあって,遠出は皆無ではなかったものの,近くまで行っても混雑していれば立ち寄りを取りやめるなど,気苦労があった.

そんなわけで今年は多くの時間を自宅で過ごした.幸い,自宅にこもるのは得意である.

ゲームのお供は,昨年から引き続き,エースコンバット7だった.結局,1年中お世話になった.ロスト・エンバーCitiesSkylinesも買ってみたのだけれど,長時間プレイには至っていない.時々Skyrimに散歩に行くのも相変わらず.

今年は,仏教関連の本をいくつか読んだ.悟らなくたって、いいじゃないかから入って,プラユキ氏の本苦しまなくて、いいんだよ。,ニー仏紙の本だから仏教は面白い!前編後編へと進んだ.仏教的な世界のとらえ方は興味深く,瞑想を中心としたソリューションももう少し踏み込んで理解したいと思っている.Twitterで話題だった発達障害サバイバルガイドも楽しく読ませてもらった.発達障害という医学的な問題が入り口になっているものの,規格化や,自動化といった技法で,必要なことを必要なタイミングで繰り返し実行できるようにする方法論は,エンジニアリングの思想に近い.エンジニアリングといえば,最近発売になった達人プログラマーの第2版を,いま読んでいるところ.

夏ごろに重兵装型女子高生 陸が届いたのだけれど,これは今年の届いて嬉しかったもの大賞.

CG関連は,プログラミング上の課題で躓いた部分で進捗があまりなく.それと,初秋にはを作っていた.これは思った通りに仕上がって満足している.DOKI for Shade3Dで正しいパストレーシングを手軽に使えるようになったことも大きかった.

振り返ってみると,ゲームと読書の時間が長く,何かを作っている時間は少し短かったかもしれない.ともあれ,今年もこのように年末を迎えることができた.お世話になった皆様に感謝申し上げる.皆さま良いお年を.

12月20日の日記

山中湖のパノラマ台に行ってきた.富士山が良く見える開けた場所で,晴れてさえいればいつ行っても景色を楽しめそうだ.ここでは,東から西に向かって山を見る格好になるので,夕暮れ時だと富士山はシルエットになる.

最近,風景写真を現像していると,写真は肉眼で見た以上に細部を描写していることに気づく.家に帰って写真を現像すると,自分が見てきたものよりも美しく仕上がることがあるのだ.昔は,目の前の風景を持って帰りたいと思ってシャッターを切ったものなのに,今では持ち帰った写真に,見てきた以上の風景が描写されている.

カメラのダイナミックレンジは肉眼に遠く及ばず,現地に立って風景を感じることは今でも大いに価値がある.一方で,その場にいても感じ取れないものをカメラを通して見ることも写真の面白さだと,最近はそんな風に思う.

12月9日の日記

昨日は,1台のサーバーの上にいろいろな機能を展開するのをやめて,機能ごとにサーバーを運用するようにすればよいのではないか,という話をした.コンテナ仮想化という技術はそうやって使うのだろう.うまく行けば,OSのバージョンが変わるとか,アプリケーションのメジャーバージョンアップだとかいった対応の見通しがよくなりそうである.

ところで,どんな仕組みにするにせよ,サーバーを運用する以上は日常のメンテナンスは避けて通れない.その作業は,いったいどうやればいいのだろうか?毎週のように新しいコンテナに入れ替えるのは手間だ.普通に考えればコンテナに入ってyum updateとかする方がよいのだろう.

とするとその作業は,メンテナンスの度に,コンテナの数だけ必要だ.楽をしようと思えばやり方はいくらでもあるのだろうけれど,何らかの仕組みを導入すればその仕組みを維持管理する手間が生じる.概念上は面白そうなのだけれど,運用できる形がイメージできるまでには,もう少しかかりそうである.

12月8日の日記

末永く安定して運用することが必要なサーバは,データとアプリケーションを分離して何かあればコンテナごと入れ替える運用が楽かもしれないと考えている.

私の,ここ10年くらいのコンピュータの運用は,コンテナなどという仕組みには全く対応していない.まず,システムを構築し,修正やバージョンアップを欠かさず適用するなど,日々のメンテナンスを中心に運用計画を立てる.すると,5年くらい経って古いバージョンのファイルが残り続けて肥大化するとか,プログラム言語のバージョンアップにアプリケーションが対応できないだとかという問題が起こる.そうしてようやくデータのバックアップをとりはじめ,全く新しい環境を立てて総入れ替えするという大工事が始まる.大工事が必要だと確信してから実際にやる気を出すまでにも,年単位の時間が必要だ.

そうやってサーバの今後について考えていたら,冒頭の方法がぼんやりと見えてきた.きっと,一つのサーバなかに,いくつものアプリケーションとその関連データを詰め込んで結合させてしまうのがよくない.システムを交換可能なパーツに分解しておくべきなのだ.それが実現できるのがコンテナであるかどうか,まだお勉強が追い付いていないのだけれど.

12月3日の日記

GoogleのCOVID-19予測.公表されてから定期的に見ているのだけれど,予測が実態と全然あっていない.自身が公表した95%信頼区間さえ実際の値と大きくずれているということは,根本的に現象を正しく扱えていないといえる.

きちんとした記録はないのだけれど,SSで残しておいた北海道の入院,療養患者数の推移のグラフを置いておく.

こちらが11/17の表示.

こちらが12/03の表示.

11月16日の日記

平成22年版の労働経済白書を読んで,各消費費目の所得弾性値の推移に興味を持った.所得弾性値とはある費目への消費額の増加率を所得の増加率で割った値で,所得が1%変化したときの消費の増減%を表す指標である.

私が生まれた1980年代~90年代にかけて,人はお金を手にすると良い家に住み,電機や水道をふんだんに使い,移動にお金をかけた.そして,2000年代それは,良いものを食べて,良い家電を買い,教育にお金をかけるようになった.

11月14日の日記

池袋のワンダーパーラーカフェに行ってきた.クラシックなスタイルのメイド喫茶である.店内は落ち着いた雰囲気で,英国風のメイドさんが紅茶を入れてくれる.紅茶は大変美味しい.

接客も丁寧だ.話をしているときだけではなく,こちらが見ていないところの所作もいちいち丁寧なのが大変良い.視界の端でメイドさんが深々とお辞儀をしていたりする.そんなところ.

10月19日の日記

「並列プログラミング」でググっても「#pragma ompと書くだけ」という記事ばかり出てきて,forループを使ってベクトルの全成分を2倍するアルゴリズムより先の情報はほとんどない.マルチコアCPUで効率的に動作するプログラムに入門したいときには,「マルチスレッドプログラミング」でググるのが正解,ということに先ほど気づく.危うく入門する前に追い返されるところだった.

10月17日の日記

お勉強でどうにも理解できない壁があり,取り組んでは追い返されるということが続いて3カ月くらい経った.こうなってしまうと,少しやる気を出すくらいでは超えられず,次第に足も遠のく.とてもよくない.

10月1日の日記

読書ログ,「オプティミストはなぜ成功するか」.

著者は,学習性無力感の研究で知られる米国の心理学者,マーティン・セリグマン氏.楽観主義(オプティミズム)と悲観主義(ペシミズム)を比較し,これらの思考が人間にどのような影響を与えるかを論じている.曰く,悲観主義は人の能力を発揮しにくくし,また不健康にする.本書では,その対策として,認知行動療法を用いて楽観主義を学ぶことを薦めている.

原著は,その主張の通りLearned Optimismというタイトルなのだが,翻訳されて意識の高いタイトルになった.なぜ変えた?

本書においては,楽観主義と悲観主義は「自分への説明スタイル」の違いであると定義する.これは,自身にとって好ましくない事実を言葉で表現する際の傾向や癖のことだ.楽観主義による自分への説明スタイルは一時的,特定,外向的と特徴づけられる.一方,悲観主義のそれは,永続的,普遍的,内向的である.

野球選手がフライ球を落としてしまったという例で,その違いを見てみよう.楽観主義はこの状況を「ボールが思ったよりも飛んでね。もう少しで取れるところだったんだが(外向的かつ一時的)」と説明する.一方,悲観主義は同じ状況を「取れるボールだったのに僕が取れなかったんだ(内向的)」と説明する.

悲観主義は無力感によって人を行動から遠ざけ,意欲の低下や人間関係からの疎外などの問題を引き起こす.こうした悲観主義の弊害に対処する方法として,本書の後半では自身の説明スタイルを可視化し,より楽観的な説明スタイルに目を向ける認知行動療法のアプローチを紹介している.

最後に,本書は楽観主義が無条件に良いものだとは主張しない点を補足しておく.楽観主義は慎重さを欠くという負の側面も持っている.そのため,設計や医療など失敗のリスクが大きい場面においては,悲観主義に基づく慎重な行動が求められる場合があるのだ.本書の主眼は,楽観主義と悲観主義の優劣ではなく,無自覚な悲観主義から生じる弊害とどのように向き合うかという点にある.

9月16日の日記

今日のできごと.

  • 課長「かすぱ君,ソフトAのライセンス使用数が増えてきてるから追加で買っておいて」
  • 私「承知した」
  • 私「ソフトAの使用者数が増えてきたので追加で買わせてください」
  • 部長「いまのライセンスじゃ足りないの?」
  • 私「ライセンスのログがもらえないので定性的ですが,週に1~2回は使えないという声が届く状態で」
  • 部長「その人たちが使えなかったとして何か問題があるのかって話」
  • 私「仕事は遅れるでしょうが個別の事案までは把握していません」
  • 部長「全員が自由に使える数を用意しろという要求なら飲めない,順番待ちをすれば済んでいるのだろう?」
  • 私「では本当に首が回らなくなったらまた来ますから,その時はすぐ買ってくださいね」

部長も悪意があって言っているのではなくて,課長の伝言で来るのはやめろ的なことを言いたかったようである.問題なのはソフトAはインフラという位置づけで整備されてきた経緯があって,調整しながら使うとか待たなければならないという話自体が新しい概念だということ.部長は,ソフトの価値をわかってから来なさいねというお説教をしたつもりだったのが,Excelって全員のパソコンにインストールする必要あるの?1日何時間使ってるの?みたいな問答に発展してしまった事故.

ソフトAなんて喫煙所で部長の耳に入れて注文書切るだけだろと思っていた課長,私をちょっと指導してやろうと考えた部長,真に受けた私,不便なまま取り残されたユーザーの誰も幸せにならなかった話.

9月12日の日記

些細なことでカチンときてふてくされて以降,無限に腹が立つ.すでに怒りは具体的な内容を過ぎて,皮肉めいた抽象的な内容に入っており何が問題なのか自分にもわからなくなってきた.困ったなぁ.

こういうときは,おとなしくしているのが自分なりの身の振り方なのだけれど,傍から見ると疲れているとか暇をしているとかいう風に見えるらしく,あまり良い結果を生まなかったりとか.

9月9日の日記

Google mapsで国立公園に「広々とした自然豊かな公園です」みたいな投稿が付いててもにょる.

とはいっても,投稿した人が特別に見当違いなことを書いているとも言い難い.きっとGoogle先生に「この“公園”について教えてください」と聞かれて,わざわざ回答したのだろう.都市公園(娯楽施設)と自然公園(保護区)を同じ公園というカテゴリで管理することに無理があるのだ.

8月26日の日記

複雑なマルチタスクは脳の健康に悪かった模様.20分計算待ちしているあいだにあっちの仕事,5分待つので文献の読み込み,1分処理待つのでTwitterとかで4-5件並列でやってたら色々壊れて精神力を完全に持っていかれた.

仕事は暇でもタスクスイッチばかりでは終わるものも終わらぬ.

8月23日の日記

PCの作業環境を見直し.最初はBashを使おうなどと思い立ってシェルをいじり始めたのだけれど,納得のいくものにならならず,cmdに戻ってきてしまった.結局整ったのはフォントだけで,Rictyフォントを導入することとなった.これは見やすくて良い感じ.

ターミナルのHyperとエディタのAtomあたりは試したいので,環境整備はもう少し続ける.

8月16日の日記

先日,初めて車を買おうと中古屋に下見に行ったのだけれど,適当にあしらわれて帰ってきてしまった.一言目から「すぐに価格交渉できないのであれば紹介する車はありません.どうして今買わないんですか?」という調子.

訪れたのは,一般の中古車販売店ではなくディーラーの中古車部門.「詳細が決まっていないのであれば個別のご紹介はできませんが,弊社の売りはここです.他社さんとの違いを見てください」みたいな営業トークを聞く場所かと思っていたのだけれど,そういう話はほとんど聞けなかった.最新世代と1世代前の車が在庫にあったので,どう違うのか聞いてみても「違いは特にないですよ.カタログを見てどちらでも良いとお考えなら安い方でいいんじゃないですか?」みたいな感じ.忙しいときなら購入が近い人を優先するのもわかるけれど,お客は私しか居らんかったのになぁ.

営業氏が頼りにできないとなると,中古車を選ぶのも難しくなる.現地で車種と年式だけ見て選べと言われても,技術的情報がないとどこから選べばいいのやら.中古車販売サイトや,自動車雑誌のスペック比較をくつか目を通してみたものの,これは細かすぎて頭に入ってこない.そんなときは,Wikipediaを見るのが良いというのが最近の発見で,車種ごとのページを見ると〇〇シリーズの××年式が年代順に並べられ,前世代との違いが簡潔に書かれていて非常に便利である.いや,Wikipediaて….

余談だけれど,パソコン選びでも似たような状況はあり得るだろうな.私はパソコンを知っているので選ぶのに困らないけれど,いま着目しているモデルは前世代とどう違い,ライバル企業の同世代はどれにあたるかを追いかけるのに一番便利なのはおそらくWikipedia.

8月10日の日記

雑学.かつて首都圏を走っていた205系という列車には,通勤時ラッシュ時には座席を収納し,すべて立席とすることで収容人数を最大化した通勤型車両があった.付けられた愛称は「ワキ204」.正式な型はサハ204.ワキは有蓋車(貨車)の型名で,さながら有蓋車に人を載せて運ぶようであることからそう呼ばれた.

もちろん呼ぶ方も冗談で言ってるんだけど,好きな名前なので雑学としてご紹介.

7月23日の日記

過去の自分の愚かな行いを振り返って自分を責めるという考え方を,主にフィクションで,時々はリアルでも見る.私は共感しないのだけれど,ああいう考えはどうして出てくるのだろう?

例えば,私は高校時代にネトゲをやっていて大学受験に落ちたのだけれど,当時のネトゲプレーヤーである自分を責めるべきであろうか?今にして振り返れば,もっと勉強しておけばよかったという反省はある.けれど,そうできる状況になかった人を「あなたはこうすべきだった」と非難するのは妥当ではないと思うのだ.

ネトゲに熱中したあの興奮のなかにあって,机に向かうことがどれだけ困難だったかを振り返れば,結果は起こるべくして起こったとしか思えない.そもそも論として「ネトゲに出会わなければ」という思いはないではないが,いずれにせよ,それはネトゲに興じる当時の自分を責める気持ちはない.

あと1回懸垂ができればSASUKEをクリアできた,そんな思い出を誰しも持っているものだろう.けれども,あの日の出来事を「頑張ればよかった」という粗い解像度でとらえ,腕の疲労感もすっかり抜けきった今この時点から非難するのは妥当だろうか?自分を責めるということは,当時の自分が知りえた情報,持っていたリソースを無視したうえで,単に結果が出なかったことを指摘ことでしかないのではないか?

もちろん,再び同じ場面に出くわしたら,あるいは出くわさないためにはどうすべきか,未来のために反省する点は大いにある.けれどもその反省は,かつての自分が当時の制約の中でできることをやったという評価を貶めるものではないはずである.

7月21日の日記

レポートや修士論文の作成に際してを読んでいて勉強になったのでメモ.

参考文献リストにおいて,複数いる著者の一部をet al.で省略する場合には,省略される人は2名以上となるようにする.et al. はラテン語で「et alii(男性)」,「et aliae(女性)」,または「et alia(中性)」の省略形.意味は,英語のand othersに相当する.Other"s"であるから,省略される人は複数名である.すなわち,著者が2名のときには,そのうち1名を省略してet al.とはせず,<1人目> and <2人目>と表す.また,省略形であるから,et al.のようにピリオドが必要.et al.をイタリック体で表記するのは,ラテン語はイタリック体で書くという組版ルール.

ラテン語名をあまり扱って来なかったので,ラテン語はイタリックという組版ルールはきちんと認識していなかった.

6月17日の日記

論文を読んだ.著者は人工知能は人間を超えるかなどで有名な松尾豊先生.

  • 松尾豊. なぜ私たちはいつも締め切りに追われるのか. [URL]

ふざけてはいるがきちんと組み立てられた論文であり,楽しく読めて一定の納得がある.楽しく技術論をやるという姿勢を大いに見習いたい.

6月7日の日記

最近,散歩に出歩かなくなったなと感じ,その理由をいろいろ探っていた.

単に忙しくなったとか,故郷と比べると人も車も圧倒的に多くて一人になれる場所がないとか,川や高台など自分の好きな場所が近所にないなどいくつか原因がありそうだ.そして,どうやら一番の原因は,近所が袋小路だらけでつまらないからだと気が付いた.

近所の道は,幹線道路から私道がくし状に発達して,街区同士の横のつながりが殆どない.都市計画なきまま農地がばらばらに宅地化されたのだ.あらゆる道が袋小路で,道幅も最低限.法律で決められた最低限の空地です,みたいな公園があれば良い方で,商店なんかあるはずもない.

狭い袋小路を奥まで行って引き返してくるか,人通りも車通りも多い幹線道路に沿って歩くかの2択では,どうにも散歩に作業感が出てしまって非常によくない.都市計画って大事なんだなと思う次第.

6月5日の日記

Framework vs. Toolkit vs. Library(Stack overflow)「フレームワークとツールキットとライブラリはどう違うのですか?」が面白かった.Jörg W Mittag氏の答えのうち,ライブラリとフレームワークの違いの部分をざっくり意訳.

ライブラリとフレームワークの最も重要で決定的な違いは制御の反転が起こるかどうかです.

どういうことでしょうか?あなたがライブラリを呼び出すときには,そのプログラムをあなたが制御しています.一方で,あなたがフレームワークのもとでプログラムを書くときには,制御の反転が起こります.つまり,フレームワークがあなたのコードを呼び出します.(これはハリウッドの原則と呼ばれているものです.「私を呼び出さないで,必要な時はこちらから連絡しますから」)これがフレームワークの定義です.制御の反転が起こらないフレームワークは,フレームワークではありません.(.NETさん.あなたのことですよ)

通常,プログラム全体を制御するコードはフレームワークの方に書かれており,あなたが書くコードはフレームワークに用意された空白を埋めるためにあります.

4月4日の日記

旅行の計画を立てる必要があって,宿を探していた.場所は中核市未満の地方都市,目的は観光.そこで,老舗のシティホテルに目を付けた.ホテルのエントランスにバス停があって,駅や空港から直行バスが運行されるなど,旅行者を受け入れる都市の顔といった風格を漂わせるところだった.子供のころから名前だけは聞いたことがあり,いささかながら愛着もあった.

ところが,宿が決まりかけた頃に一つの問題が浮上した.ホテルに大浴場がないのだ.何日か滞在する宿だし,他に選択肢があるなら大浴場はあった方がいい.同伴者である妻とも相談した末,近くの別の宿を取った.ビジネスホテルだったが,大浴場を売りにしているところであった.

風呂は欲しいよな,という率直な感想.最初の候補に挙がったシティホテルには,良い立地と,老舗としての風格があった.シティホテルならではのもてなしにも期待が持てた.そうであっても,時代のニーズに合った設備を持っていないというのは苦しいな,と感じながらの決断であった.

自分も,老舗のデパートとか,老舗のホテルとかそういうものに愛着を感じる年になった.そういう目線を持って初めて見えてくる現実もあるものだな,と思った話.

3月25日の日記

何らかの指摘を受けたとき,よほど見当違いのものでないかぎりは,それに答えるために思考を働かせる過程は良い訓練になる.指摘を受けたことは嬉しくなかったが,気を付けるようにしてみると,何らかの改善があったという経験は誰にでもあるだろう.

しかし,中にはこうした経験を「苦しんだから,成長できた」と考える人がいて,あまり好ましくない認識だと思う.成長の原因はあくまでも受けた指摘に答える過程であって,苦しみは副作用である.人に伝える場面では,因果関係を明確にして「指摘は人を成長させる」という側面について述べるべきであろう.

良薬口に苦しは,その薬が良薬であることが前提である.因果関係が混乱して「苦かったから良薬であるはずだ」という考えに至っても,それは信仰にすぎない.

3月10日の日記

先日乗ったあずさ11号(立川-茅野)では,GPSでログを取っていた.

それぞれ,時刻-移動距離と,移動距離-速さをプロットした.

まず,時刻-移動距離の関係は,横軸は時刻,縦軸は営業キロである.プロットは,列車は11:29に定刻通り八王子駅を出発し,ほぼ一定の速さで茅野に向かったことを表している.途中,甲府駅付近で線が水平になっているのは停車時間である.記録の終端は茅野駅で列車を降りた時点であるが,プロットは茅野駅まで届いておらず,GPSの移動距離と営業キロが一致していない.甲府駅の停車位置は営業キロとGPSの記録がほぼ一致していることから,距離の不一致は,甲府駅以降で生じたものである.原因には,GPSの記録精度が悪い場合と,営業キロとGPSの移動距離が異なっている場合の2種類が考えられる.現時点ではどちらの影響が主であるかは不明である.

次に,移動距離-速さの関係は,横軸は営業キロ,縦軸は速さである.図中のプロットは八王子駅を出て徐々に速さを上げ,走行中はおよそ100 km/hで移動していたことを表している.線が途切れている箇所は記録の欠損により速度が不明な箇所で,主な原因はトンネルなどで測位ができなかったためである.列車は線形にあわせて加減速するため完全な等速運動ではないが,走行中の速さはおよそ80 km/h ~ 120 km/hで,大きな減速はみられなかった.甲府駅より前の区間と甲府駅より後の区間を比べると,甲府駅より後の区間の方がわずかに速い.区間の線形が良いため実際に速く移動しているのか,移動距離が実際より短く計測されたことが影響しているのかは不明である.

営業キロとGPSの移動距離が一致しない問題については,今後取得する記録とも照合して検討し,記録の精度向上につなげたい.

また,今回の乗車中に大きなトラブルはなかった.今後,ダイヤ改正や大幅な遅延に遭遇するなどした場合には,この記録を通常運行時の記録として活用したいと思う.

3月1日の日記

列車の編成写真に挑戦した.

2020年2月29日 あずさ15号(15M) 撮影場所: 中央東線(岡谷 - みどり湖間)

軌道がよく見える場所で構図を決めながら列車を待っている時間は楽しい.

2月26日の日記

論文の冒頭4行を書くのにまる1日かかる.納得のいくものが書けたからよかったものの,あまりの遅筆に自分でも驚く.

この種の遅筆は簡単に改善できるものではない.文章としての体裁が整って進むべき方向性が決まったあとならば,小さな単位で単語や文節の入れ替えを繰り返していけば良いのだけれど,頭の中のイメージから文章を紡ぎだす段階では,ある程度の大きな単位で文を書いては消す作業が要る.そして文章の構成や大きな変更は,作文に関する経験的な引き出しへの依存度が高いので,小手先のテクニックではどうにもならぬという話.

2月22日の日記

AIきりたんというものを耳にした.

歌声合成のチューニングをいい感じにやってくれるとかそういう技術のようだ.魅力的な技術が出てきて,皆で遊べるのは本当に喜ばしいなと.久しぶりに新技術で興奮した案件.

2月20日の日記

社内の衛生に関する会議に出席した.

司会「今日現在,当事業所内では,新型コロナウイルスの感染は確認されていません」

産業医「しかし,すでに感染した方が我々の中に居てもおかしくない状況です」

のイントロから出席者がざわつき,「かすぱさん,昨日出張に行ってましたけど大丈夫ですか?」などの質問が飛び交った.

あのまま投票の流れだったら明日からリモートワークを命じられたかもしれない.汝は陽性なりや.

2月16日の日記

ニューラルネットワークの調整が難しい.構造を変えると緩やかに精度が変化するというのが理想なのだけれど,現実は突然何かが暴れて全く精度がでなくなったり,単体では良さそうだった構造を2つ同時に採用すると全然ダメだったりする.改善の道筋が,簡単には見えてこない.

2月11日の日記

先日,WF2020Wで写真を撮ってきた.いつも,楽しく撮影させてもらえることに感謝したい.撮っていたら商業作品の作りこみに感心することがあったので,この気づきについて話したい.

フィギュアを撮影する場合,人物を撮影するのとは違った難しさがある.フィギュアは基本的に動かないので,見栄えのいい構図はカメラマン自身が探さなければならない.例えば,私が腕の角度を少し変えてほしいとしても,フィギュアがそれに応じてくれることはない.だから,撮影の度に「この構図はポーズの見え方が良いが,表情が今ひとつ」「こっちの構図は表情が良いが前髪の形が良くない」などと言いながら,試行錯誤をするのである.

作品によっては,少しカメラの位置を下げるだけでぐっと印象が良くなったり,構図によって全く異なる雰囲気に見えたりすることもあり,試行錯誤のなかから作品の魅力を引き出すのは撮影の醍醐味といえる.

企業ブースで撮影をしているときに気が付いたのだけれど,企業の作る商業作品には,明らかにこの構図で撮ってもらいたいと意図された,ポーズや表情などのパーツがぴたりと収まるカメラアングルが少なくとも1つある.そして,どの作品もそのアングルがちょうど正面を向くように展示してある.正面から撮ると,パッケージ写真の構図になると思えばいい.

例として,企業ブースで正面から撮った写真をいくつか載せた.こっちは正面の作り込みがあまい例です,みたいなのは出しにくいので,ここでは触れない.

商業作品は正面の造りこみが特に優れており,もはや展示台の正面から撮るだけで,誰が撮っても同じようにいい感じに撮れるとさえ言える.少なくとも,撮影時にちょっと横に動いてみるくらいでは正面の良さには到底かなわなくて「深みのある写真を撮りたかったらお買い上げして設置のしかたからライティングまで全部自分でやってくださいね」と言わざるを得ない.それくらい際だって正面の構図のできが良い.

当たり前のことを書いているだけなのだけれど,ありきたりな感想を抱く前に,私は「良い構図で撮らされている」のだということを心に刻んでおきたいと思った次第.

2月2日の日記

一年ほど前から本格的にメンタルを壊して,仕事の量を減らしたり薬を飲んだりしていた.ここ半年くらいは快復したと言ってもよい状態になっている.

寝食は問題なく,生活はそこそこ楽しい.特に快復を実感するのは,映画を見に行ったり,旅行に出かけたりするような,具体的な行動を伴う余暇を楽しめるようになったことである.傍から見ても,自発的に外出をして,楽しそうに過ごしていれば,大丈夫そうに見えるのではないか.

一方で,未だに尾を引いている問題もあって,趣味でいうと,CGを描くとか,プログラムを書くことができないままになっている.自分の頭の中にあるイメージをアウトプットする類の仕事が,全くといっていいほど脳に受け付けてもらえなくなってしまった.

こうした類の仕事には,ゴールがおぼろけにしか見えないまま,とりあえず方針を決めて進んでみることが必要となる場面がいくつもある.メンタルを壊してからというもの,方針に迷うような状況に出くわすと,その場で思考が停止し,頭の中が真っ白になってしまうのだ.好奇心に駆動されて解決に向かって考えが巡る感覚を失ってしまった.

とはいえ,こんな文章が書けるのも,脳が動かない状態から少しは快復している証拠である.最近では,記憶が残っているうちに,自分の身に起こったことをまとめておきたい思うようにもなってきた.落ち込んだ時の気分や体調の変化,病院に行った感想,飲んだ薬と効き具合,家族や会社とどのように付き合ったかなどを書き残すというのを,小さな目標にしている.

そんなわけで,メンタルを壊すというのは本当に恐ろしいことである.皆様もどうか無理はしないでいただきたい.

2月1日の日記

我が家には10インチのAndroidタブレットがあって,主に読書に使っている.機能的に不足はないのだが,使い勝手は微妙である.プリインストールされているアプリをホーム画面から消すことができなかったり,画面を縦置き表示のまま回転させない設定が無かったりするなど,お節介なわりに痒いところには手が届かない.また,機種はファーウェイのMediaPad T3 10なので,アメリカとファーウェイの対立が激しくなって以降,Androidとしての改善も期待できなくなった.

そんな経緯もあって,このタブレットを読書専用機として仕立て直すべく,OSの換装ができないか検討した.だが,結果は芳しくなく,仕組み的にハードルが高そうである.というのも,Android自体がハードウェアの構成にあわせてコンパイルされたバイナリを使うのが基本であって,とりあえず汎用品を入れれば動くといった仕組みにはなっていないらしい.公開されているAndroid系ディストリビューションも,ファーウェイの,しかもタブレットまでカバーしているものは見当たらなかった.

変わった使い方に手を出したければ,ハードウェア選定の段階からそれができそうな機種を選んでおくべし,というのが今回の教訓.手元のタブレット君は適当にダイエットをして騙しだまし使っていくこととなった.無念.

1月26日の日記

私は,時々ブラウザのcookieをクリアするようにしている.そして,cookieを消すと,各種のWebサービスのログイン状態が解除される.以前はさほど気にならなかったのだけれど,最近はかなり不便だ.サービスにログインしていないとまともにwebを見ることすらままならないので,cookie削除後には何度もログイン画面を見ることになる.

一昔前のWebサービスは,ホーム画面に最新の記事や人気のトピックなど万人受けする情報を表示している場合が多かったので,新着記事を確認する程度では,ログインしているかどうかはあまり重要ではなかった.例えば,初期のニコニコ動画では,コメントをしなければログイン状態を意識する必要がなかった.少し意味は違っているが,Amazonは今でもログイン状態はあまり重要ではなくて,いざ購入という段になるまで自分がログインしていないことがほとんど意識されない.

それに比べると,近頃のWebサービスは,アクセスをすると自分のアカウントのホーム画面が表示されるという動作が一般的になっており,ログインしていない状態では必要とする情報がほとんど表示されない.例えば,noteはホーム画面に自分がフォローしている作者の新着記事が出るので,ログインするまでは新着があるのかすらわからないし,Twitterに至っては,ログインするまでタイムラインそのものが表示されない.

Cookieを消すという習慣から,webのパーソナライズが着々と進行していることを実感するこの頃.

1月18日の日記

ようやく日記を更新しようとしてみたら,予想していなかったディレクトリの付け替え作業が発生したりしていた.当サイトは年単位で日記を格納するディレクトリを分ける仕様になっており,年越しは今回が初めてだったためだ.

さて,最近読んだ記事で良かったものを一つ紹介したかった.

自然科学や工学にまつわる短編は好きで,インターネット黎明期にはそういったものをよく読んでいたのを思い出す.この類の短編はSNSでは話題になりにくいようで,近年では目にする機会も少なくなった.