直近で買って良かったもの

年末に買って良かったものをまとめて書く文化がありますが今は1月後半。しかしどうしても書きたくなってしまったので時期関係なく今残します。買ったけど自分にはあまり合わなかったものも書きます。

転職をきっかけに買ったものが多いので、転職に触れざるを得ませんが、退職ブログは絶対に書きたくなかったので、転職したという事と、今めちゃくちゃ楽しいという事だけ書いておきます。転職先はつながり承認タイプのSNSでは普通に更新してあるので見たい方はそちらを見てください。

良かったもの

PGYTECH OneGo Lite Backpack ブラック 22L

ものすごい大きさのノートPCを持ち歩く事になったため、既存の鞄では入らず、且つどさくさでカメラバッグを買えるチャンスだったので購入。

16インチノートでも無理なく入り、ヘッドホンを入れてもまだ余裕がある。カメラを入れる場所もかなり工夫されていて、リュックを肩にかけたまま出し入れできる。外側にペットボトルと折り畳み傘の両方とも差し込める。
重たいノートPCを背面に入れた状態でも自立するのも良い。
見た目はそこまで大きく見えないのにこれだけ入る事に感動してしまった。
悪い点は、当たり前だけど重いことと厚みがあって混雑する場所だと周りに迷惑がかかる事。重さにしても場所にしても、事前にわかっていればそこまで問題はない。

PGYTECH BEETLE カメラホルスター

リュックやベルトに固定し、これにカメラをカチッと固定するためのもの。
カメラを首からぶら下げるスタイルが苦手で手に固定するバンド的なものだけで過ごしてきたが、一瞬両手を離したいというケースに対応できず困っていた。
これはリュックに普段からつけていても邪魔にならないし、固定した時の安定感安心感も強く、手を話したいケースは完全に解決できる。
ただ、あまりその機会はなく、どちらかというと自身があれを買うならこれも買いたい的なコレクター的な要素で満足度が高い。

無印良品羽織れる電気ブランケット

リモートワークの際に一人しかいないのに暖房をつけるのが抵抗があり、且つ真上にあるため顔に直風が当たって辛かったが、電気毛布で完全解決した。
これをつけて以降家では冬将軍を見かけなくなった。
デメリットは有線の装備であることで、バッテリー型を買っておけばよかったかと少し思ったが、安全性と出力を考えるとこちらで良かったのではないかと思っている。

ぶっちゃけPGYTECHのリュックとこの電気ブランケットの事を書きたくて久しぶりに記事を書きました。

レコルト 自動調理ポット

野菜を田舎からもらうことが多く、ありがたいのだけどジャンクフードが好きな自身が手間を掛けずに美味しく食べるのが難しい。
ポタージュなら、、と思うことが増え、購入した。
今のところ作ったものはすべて美味しかった。
デメリットはよく言われている通りとても洗いにくいこと、　ポットの形状の都合で注ぐ時にたれやすいこと。前者は覚悟をしていたので特に問題がなく、後者は垂れないように反対側に倒したら熱々のポタージュが手に垂れてしまったが、まあここはもう仕方ない。大手が利便性重視の調理ポットを出したらもう少し増しになるのかもだけど、値段とサイズと見た目を重視したギリギリの妥協ライン何じゃないかという気もする。

普通だったもの

PUMA SOFTRIDE フレックス

靴。
アディダスのジョギングシューズがジョギングに使われないため非常に長持ちしていたが、ついに靴紐だけ切れてしまったので購入。
ファッションには相変わらず興味がないしおしゃれの土俵に上がる気はないものの、40を過ぎるとどんな靴を履けば良いのか悩ましくなって、結局今までのような色味の靴を買った。
意図せずして紐を結ぶタイプのものではなく、吐くときは立ったまま履ける上にスリッパみたいに走りにくいとかでもないのは良いポイント。
デメリットは普通の靴より脱ぎにくい所。
感動的に良い、がなかったので普通扱いへ。

Dell S3225QS-A

コロナでリモートワークが始まった際に買っていたモニターがどうにも目が辛く、買い替えることにした。
目に優しい物を探した結果、表示のクリアさと高リフレッシュレートが必要ということでこれ。
目にはなんとなく優しくなった、、気がする、、という事で、普通扱い。
元々のモニターはUSBハブ機能もあり、給電もでき、有線LANも繋げられたが、液晶の質的には厳しく60Hzが限界という事で買い替え。
デメリットは、前のモニターと違いUSBハブも給電機能も有線LANもないこと。これは買う前からわかっていたのでKVMとセットで買った。が、あまりうまく行かなかったので後述します。

K&F CONCEPT 77mm True Color&超低反射 CPLフィルター

写真を撮る時に光が邪魔なことがあったため、よくなるんじゃないかと思って購入。
確かに無いよりあった方が良いことはあるが、違いがあるな、以上のケースにまだ出会わない。
それもそのはずで、正面からの光は普通に入ってくるため、自身が一番抑えたかった逆光には特に効果がなかった、、、

自分には合わなかったもの

Anker KVM Switch

モニターと同時に買い替え。
これが悪いというより自分が調べていなかっただけなんだけど、60Hzが限界だった、、、
目のためには120Hzにしたいが、それが無理なので結局KVM経由ではなく直接HDMIケーブルをつなぐことになってしまった。
当然不便で、ノートPCを繋げる際はUSB-CケーブルとHDMIケーブルの両方が必要で前よりも手間が増えているし、モニターも自動で切り替わらないため片方の画面をオフにしてから片方をつけたり、Macはスリープのあとのモニタ出力OFFまでが長いためモニター側のスイッチを押して入力を切り替えたり、かなり涙ぐましい状態になっている。

また、これは不勉強で本当に知らなかったのだけどMacは切り替え後にスリープ的な状態になって、そこから戻しても、キー入力は受け付けなくなるという問題があり、追加で不要な入力機器を直結し、スリープからの復旧はそっちを触る必要が出来てしまった。

ので、120Hzのために捨てたものが多く、かなり不便な状態になってしまった、、、

SENNHEISER ACCENTUM Wireless

転職してちょいちょい出社するようになったため、会社用ヘッドホンを購入。
会社に置きっぱなしにできるかわからなかったため、ある程度の小ささとバッテリーと音質のバランスを考えこちらを購入。
合わなかった点は、自分の頭が大きすぎて頭と耳への圧迫感がきついところ。長時間つけっぱなしにしたいが、そこが厳しくて辛くなってきたら外すような使い方をしている。
ただ、最近ノイズキャンセリングはすごいなと思いました。

TAMRON 28-300mm F/4-7.1 DiIII VC VXD (A074)

遠くを撮影したいケースが増えてきたので、かなり厳しい家庭内稟議を通して購入。かなり厳しいのは奥様が厳しいというわけじゃなく、自身が家の中で高ものをバンバン買える空気にしたくなく勝手に厳しくしています。
ある程度覚悟はしていたが、自分が思っているよりも画質が好みと違っていた。
もちろん暗いレンズだったから、というのはあるが、自分は周辺も含め解像度がバチッとしているものが好みだというものが分かった。
多分200mmのA075か、もしくは再度家庭内で土下座を繰り返して純正のSEL70200G2辺りを買うと満足するのだろうと思う。前者はひょっとしたらまた上を見てしまうかもしれないので、買い替えるなら後者だろう。

久しぶりに書く記事がこんなので良いのかというのはあるんですが、技術的な事はもう少し肌感を取り戻して実績を出してからにしたいと思います。
家で仕事をする人はとにかく電気ブランケットを買ってください。

PHPのシステムをHHVMに載せた時に動かなくて直した所一覧

php hhvm

PHPの既存システムをHHVMに載せ、その後サービスを維持しつつHackに変え、静的型付けやモダンな書き方により、堅牢なものに変えていくことを目的に試験環境を構築しハマりつつも大体動いたレベルの所まで行ったのでここに残しておく。

phpconには行ってないけどHHVMの注目度も上がりそうだし役に立つかもなので今日書く事にしました。

まずやったこと

  1. 既存PHPプロジェクトをDocker上に展開できるように用意
    何度も試行錯誤することが目に見えていたため、環境構築・再現がしやすい事が必須と考えた
  2. HHVMをDocker上でビルドできるように
    Ubuntuだとそれ程困らないが、元の環境がCentOSだったため、自分でビルドするものを用意した。元はCentOS6系だったが残念ながらそちらでのビルドはハマりどころが多すぎたためCentOS7にした。githubとDocker hub両方に上げておいた。


    suzuki0keiichi/docker_centos7_hhvm · GitHub


    suzuki0keiichi/centos7_hhvm Repository | Docker Hub Registry - Repositories of Docker Images

    Dockerfileの方はRUNが大量に書いてあるビルドスクリプト同様のものなので、Docker上で動かさない場合でもビルドするのには役に立つかも。
    10/12追記 静的解析などに使用するhh_serverコマンドは$USERが設定されていないと動かないため、Dockerで起動したそのまま(root)の状態だと実行できないので気をつける。
  3. 1で出来たもののPHP部分だけを2に差し替え
  4. httpdとかの設定を追加
    mod_rewriteとmod_phpでのベタな構成だったため、追加でProxyPassMatchを入れるだけで良かった。

 ProxyPassMatch ^/(.+.(hh|php)(/.*)?)$ fcgi://127.0.0.1:9000/PHPSOURCEROOT/$1

はまりどころ

「不具合まで再現する」をポリシーとしてPHPを再現しているHHVMだが、残念ながらまだ差異がある所がある。

ここからの説明では「さすがにそんなコードを書くほうが悪い」と思われる所が出て来るかもですが、旧石器時代且つ自分が書いたものではないのでお察し下さい、、、

大きく分けると際のある場所には32種類あった。

  • 各組み込み型、関数の微細な挙動の違い
  • 組み込み型や組み込み型を継承した型のオブジェクトのシリアライズ、get_object_vars等のオブジェクト全体に対する操作
  • evalやpreg_replaceなどの中でのevalが実行されるスコープの違い 10/13修正
各組み込み型、関数の微細な挙動の違い

今回出会ったのは幸い一件だけだった。

2件の問題に遭遇した。

一件目はfile_get_contentsでhttpヘッダーを渡す際にヘッダーの改行文字の扱いで、PHPの場合はCRLFでもLFでも正常にヘッダーが送信されるが、HHVMの場合ではLFだとヘッダーのフォーマットがおかしくリクエスト先サーバーにBad Requestを返されてしまう。


hhvm/http-stream-wrapper.cpp at 07f8201682818abdcc0aa581c9eaa991b2b04965 · facebook/hhvm · GitHub

この辺りが問題と思われるので、報告すれば修正してもらえるかも。

英語コミュニケーションの億劫さであんまり自分でやる気がない、、、

 

二件目はpreg_replaceで/eした場合のevalが実行されるスコープの違いだった。

(preg_replaceの/eは現在非推奨となっている)

通常のevalの方はselfもローカル変数も正しく参照できた。

PHPの場合はpreg_replaceが動いた箇所によってselfが何を指しているかちゃんと理解されたり、外で宣言されているローカル変数だったりを使うことが出来る。

HHVMの場合はpreg_replaceでselfを指定するとphpレベルで解決できない旨の警告メッセージが表示される。また、ローカル変数も見つけられなかったようなので、とりあえずstatic変数に入れるという不安な形で実現させた。

動くには動くが、非常にモヤモヤするので解決策を探して行きたい。

当初この差異はeval系全般における問題と勘違いして別カテゴリで書いていたが、実際にはpreg_replaceのみに起こる問題だったため関数個別の問題のカテゴリに移しました。

組み込み型や組み込み型を継承した型のオブジェクトのシリアライズ、get_object_vars等のオブジェクト全体に対する操作

全部の組み込み型かは不明。今回あったのはSimpleXMLElementとDOMDocumentだった。

serialize関数を呼んだ際にphpのエラーログとして通知してくれるケースもあれば、unserializeの時に何故か抜け落ちるケースも有る。後者は特定がかなり難しい。

しかし問題箇所さえ分かってしまえば対応は結構簡単で、__sleepと__wakeupの際に上手く組み込み型を保存しなくても済む状態にすれば良い。

継承してしまっていてコードの変更が大変そうに見える場合でも、privateなプロパティーとして持つように変更し、__callで中継してやることで影響箇所を小さくすることが出来る。

 

大体こんな事をやったら今回実験対象だったシステムは動くようになった。

これから先に同じことをやろうとする人たちのお役に立てば幸いと言うか、ぜひHHVMに乗り換えていってもらってHHVMをFacebookと一蓮托生じゃない感じにして頂けたらと思います。

技術的負債がいかに問題かをどう伝えるといいのか

沢山の方がチャレンジしては上手く行ったんだが行ってないんだがみたいな結果に終わるコレに自分もチャレンジしてみようと思う。
上手く行ってるか分からないのは自分が技術者だからなんだけど。

まず技術的負債って言葉で、何か悪いものがたまって行くのはわかると思うが、どのくらい深刻なのかは伝わらないよな。
それと、プログラムが日に日に複雑になって行くというのがなかなか他に似たようなケースがなく、何が大変なの？という感じなんだと思う。
特に少しだけ、小規模なプログラムをかじったことがある人には。
彼らはやり方を知ってる分アレを取ってきてアソコに出すだけでは？何が大変なの？とふざけた事を思うだろう。

プログラムをメンテし続けた人にしか分からないこの難しさを別の形でイメージしやすいもので伝えないといけないんだと思う。

ここからがチャレンジ。

まず、プログラムというのは矛盾があっては行けないルールブックのような、法律のようなものです。
矛盾があると、プログラムは止まったり壊れたりしてしまいます。
出来るだけ避けないといけないです。

なので、時間がなくて、その場を取り繕うような適当な、厳密に言うと嘘があるルールを定義してしまうと、後で矛盾が出やすくなってしまいます。

このまま突き進むなら、嘘をつき続けたり、嘘をつくための更なる嘘をつくことになります。
どんどん巨大なルールブックになって行くのに、過去に定義したルールも含めて少しの矛盾も許されなくて、その上で嘘を隠し通さなければいけません。
数カ月から数年に渡ってものすごい複雑な嘘を矛盾無くつき続ける、と考えるとかなり苦しいものであることがイメージ出来るんじゃないかと思います。

これが世に言う技術的負債です。

しかし、一つ目の嘘の後に訂正の機会をもらえると、"さっきは勢いでああ言っちゃったけど、正確には違うんだ。こう言う事なんだ。"と訂正出来ます。
その後は正直に、自然にルールブックにルールを追加して行くことが出来ます。
嘘がないルールブックなので、新しいルールが増えてもどこに影響するかが分かりやすいため、矛盾が起こりにくいです。

この訂正作業が世に言うリファクタリングだったり負債の返済です。

長い期間をかけてルールブックを大きくして行きたいなら、適宜この作業を組み入れた方が合理的と言えます。
たとえ1度も適当なルールを作ったことが無くても、過去に作ったルールが全て未来を予見して作ってる訳では無いので、新しいルールに合わせて訂正しないと嘘になるケースがあります。
この場合もやはり訂正の機会を適宜設けた方が良いと言えます。

ここまで。
大分乱暴なところもあるけど、厳密さより伝わりやすさを重視した。
どうかなーやっぱ伝わんないかなー。

Scala.jsで各種コードの変換結果を見てみる

scala

どんな形で変換されるのかが知りたいケースがあったので調べた。

(主にjsのフレームワークのサンプルをScala.jsで書くとどうなるか等の用途)

変換後にはオブジェクト宣言部とかオーバーヘッド的なものが沢山生成されるが、今回の描きたい所ではないので省いてある。

valのメンバ変数がどのように変換されるか

defがどのように変換されるか

overloadがどのように変換されるか

scala.js.Arrayの操作がどのように変換されるか

ifの最後の評価結果の代入がどのように変換されるか

パターンマッチがどのように変換されるか

最初見た時からわかってたことではあるが、人間が読むコードではないなという感想。

便利だった赤ちゃんグッズを忘れないうちに書いておく

赤ちゃん

スイマーバ

赤ちゃんのクビにつける浮き輪。赤ちゃんがフワフワ浮いている状態になっていて可愛い。

お風呂に入れる際も親が両手を使えるので、実用面でも便利な模様。

ただ、ちょっとしたことで外れる可能性もあるので必ず目を離さないこと。

ミラーレス一眼 + Eye-Fi + Flickr(Proアカウント)

コンデジやスマホのカメラを使っていた時は分からなかったのだけど、明らかに画質が違う。また、Eye-Fiを使って(ほぼ)容量無制限なサイトに上げられる環境が出来上がると、撮影する量も変わってくる。うちはNEXを買った。個人的にはタッチフォーカスが付いているものがおすすめ。レンズ沼には嵌らないよう、最低限のレンズだけで済ませること。Flickrは類似サービスのどれでも良いが、閲覧権限のデフォルトはprivateにしておいたほうが何も考えずに撮影できて良い。

バンボ

赤ちゃんを固定しつつ座らせておける椅子。すわり心地は悪くないらしく、あまり赤ちゃんも嫌がらない。椅子の前面にテーブルも付けられるため、食事もそのまま可能。水に濡れても大丈夫なのでお風呂にも入れておくことが出来る。

だっこ紐

買うのは当たり前なのだが、メーカーや製品によってかなり合う/合わないがあるので必ず試着すること。うちではエルゴというものにした。取り急ぎで買っていた(別に安物でもない)抱っこ紐が普通だと思っていた時にエルゴを試着して、密着度、安定度の違いに驚いた。

iPad + iBallz

高いが両親にも配布する事。特に奥さん側。Facetimeの設定まで終えておくと、何かある度に気軽に顔を見せられて良い。奥さんが赤ちゃんと触れている時間が長いうちが多いと思うので、その都度両親と連絡を取っていると赤ちゃんと両親も仲良くなったり、少しの間任せておけたりする。また、前述のFlickr等の閲覧アプリも設定しておくと、都度のイベント写真も自由に見せることが出来る。

iBallzはiPadに装着する衝撃吸収用のアクセサリで、iPadの四つ角にゴムボールをつけるジョブズなら卒倒するようなデザインをしている。赤ちゃんを持つ家ならその価値はあり、少し落としたり倒した程度では何も起きない。(商品サイトにデモ映像があるのでそちらを見たらわかると思います)

ウォーターサーバー

震災直後に不安を感じて導入。うちではアクアクララにした。会社自他はそこまで重要じゃないが、震災後の色々な不安に悩まされずに冷たい水、熱いお湯が出てくるのは便利。ミネラルが含まれるものは飲み過ぎた際に不安もあるため、ROのもので良かったと思っている。金額は結構するので、震災が無かった際も入っていたかは微妙。

業務用ドライヤー(2014/9/4 追記)

高出力＆コードが長いため射程距離が長く、子供が自由に移動しても対応できる。また本体、コード共に丈夫な場合が多い。Amazonなどで探すと大体数個のメーカーに絞られるが、多分どれでも良い。うちではNobbyにした。

jberkel/android-app.g8を使ってハマった所メモ

android scala sbt

大して今更書く成果は無いんだけど誰かのお役に立てば

  • Windowsでプロジェクト作成を行おうとすると死ぬ
    • ディレクトリ関係の問題の模様。自分のとこだけかも。
  • プロジェクトさえ別OSで作ってしまえばその後はWindowsでも使える
  • sbtの0.12系以上じゃないとsbt立ち上げ時にライブラリが見つからない
    • 設定方法自体が間違ってるかもだけど、sbt 0.11軽だと2.9.1の方を見に行ってしまいjarが見つからなかった。
  • JDK7だとproguardが対応してなくて死ぬ

Smarty側に特に手を入れずにQuercus上で動かしたった

php quercus

前回話しに上げた変更の

  • property_existsの内部でissetFieldを使わせない
  • getFieldでnullの時に次の候補(staticとか__get)とかに行かせずにnullを返す

と言うものでまず最初の爆死がなくなり、次はnullオブジェクトに対してisTrustedTagを呼ぼうとして死、と言う部分だったがこの部分はissetを追っていった所null判定が単純に間違っていた事が分かった。

 

issetの中でもプロパティに対して行うものはissetFieldを呼ぶが、ここで比較しているnullが単純なNullValue.NULLとの!=になっていた。

isTrustedTagの件は実際に比較先はVarで、実際の値がNullValueであるため、比較した結果非nullと言う扱いになって関数を呼びだそうとし、死と言う流れになっていた。

 

Value型はeqと言う関数で比較するようになっているように見えるのと、PHPのissetに関しては値がnullの場合はfalseなはずなので、eqを使うほうが正しい。

この部分を試しに書き換えた所、Smarty側には何も手を入れず、簡単なテンプレートをエラー無く表示することができた。

 

Quercusって修正を送りたい場合どーすると良いんだろう。

 

今回Quercusの中身を見をみた感想としてはかなり統一感があって見やすい＆探しやすいコードになっているように思えた。

githubでPull Request募集したら結構協力者いると思うんだけどなあ。

仕様だってPHPの完全互換を目指す部分は揉めないだろうし。