加湿器を気化式からスチーム式に替えた

家電量販店で派遣販売員に声を掛けられるとついつい他社製品の仕様を訊いてしまいたくなるaikawameです。ごきげんよう。

はじめに

僕は冬になると唇や手の甲が荒れて血まみれになる。そのため加湿器は必需品なのだけれども、今まで使っていたシャープの加湿空気清浄器は気化式で、タンクの水が切れると悪臭を放ったり、定期的にフィルターをクエン酸洗浄しないと加湿能力が落ちたりと、手の掛かる子だった。そのため、メンテナンスフリーと言われるスチーム式に切り替えることにした。

選んだ製品とその理由

今回購入したのは象印のスチーム式加湿器、EE-RM50だ。Amazon等で￥17,000程度で販売されている。

象印 加湿器 木造:8畳/プレハブ洋室:13畳 スチーム式 フィルター不要 ホワイト EE-RM50-WA

スチーム式はその名の通り、水を沸騰させた蒸気で加湿する、ある意味古典的な仕組みだ。水を一度沸騰させるので、他方式のような雑菌の繁殖とは無縁なのが一番の特徴だと思う。一方でその構造上、電気代の高さは大きなデメリットとなる。

僕の場合は、月々の電気代が数千円上がっても、面倒な手入れから解放されて、いつも清潔でうるおいのある環境が享受できるのであれば、それで良いと思っていた。なので、デメリットについては目を瞑ることにした。

製品の印象

とりあえず製品を取り出しての第一印象は…。

「だっっっさ…(´・ω・｀)」

だった…。別に見た目には期待していなかったけれども、電気ポットとか炊飯器とか、その辺りの白物家電の派生デザインにしか見えない。少なくとも間接照明とかでシャレオツ目指してみました的な部屋にはとても置ける代物ではない、白物だけに。

ただ、悪い所ばかりでもない。買う前はそれ程とは思わなかったけれども、とても小さいのだ。

新旧製品を比較してみるとわかるが、スチーム式は言わば単なる湯沸かし器なので、ほぼタンクの容積しかない。それ程広くないマンションに住んでいるので、この省スペース性は助かる。

実際に使ってみて良かった所

加湿力

これはダントツだと思う。気化式では一番乾燥している真冬の時期では頑張っても40%程度までしか上がらなかったのが、余裕で50%を超えるようになった。むしろ標準運転では加湿されすぎて部屋がサウナみたいになるので、基本的にひかえめ運転で問題ないくらいだ。1LDKの16帖程度をこれだけ強力に加湿してくれるのは、流石蒸気の威力だと感心させられる。

あと、気化式とは加湿の質が違う気がする。気化式は部屋が少し寒くなる感じがするし、湿度が上がった感は余り無いのだけれども、スチーム式は数字以上にうるおった感があるし、蒸気なので部屋が少し暖かくなってくれる。基本的に加湿器を使うのは冬場だけなので、これは助かる。

清潔さ

これも素晴らしい。原理が電気ポットと一緒なので、雑菌の繁殖する余地が無い。超音波式や気化式はちょっと手入れをサボるとすぐに水がぬめってきて臭気を発するけれども、こちらは放置しても衛生面についてはほぼ問題無さそうだ。

手入れの楽さ

これはまだ手入れの時期になるまで時間があるが、基本的に月に一度クエン酸水を入れて煮沸すれば良さそうだ。気化式だとフィルターや水受けを水洗いしたり、埃を掃除機で吸い取ったりと、マメに手入れをしないといけないので、それよりはかなり楽になると思う。

良くなかった所

持続時間

これは加湿力とのトレードオフであって仕方ない所なのだが、真冬の乾燥した時期に標準運転した場合、6時間くらいでタンクが空になってしまう。ひかえめ運転ならば夜通しでもギリギリ保つが、寝る前に満タンにしておかないと若干心配になる。出来れば5リットルとかの更に大容量のモデルがあれば良かったと思う。

電気代

これは目を瞑った部分ではあるが、消費電力が気化式の10倍もある以上、電気代もその程度を覚悟しておく必要がありそうだ。おそらくは、スチーム式を選ぶ上で一番のハードルになるのはこの電気代なのではないかと思う。

まとめ

今回加湿器を気化式をスチーム式に替えてみたが、手が掛からずに高い加湿能力を享受できるという点では非常に良い買い物だったと思う。ただ、見た目や、給水してからの持続時間、そして何より電気代の高さというデメリットがあるため、決して万人向けとは言えない所はある。高い維持費を払ってでも清潔でうるおいのある環境を手に入れたければお薦めだが、マメな手入れが面倒でなければ気化式の方に分がある。スチーム式加湿器は怠け者、拘り者のための利器と言えそうだ。

象印 加湿器 木造:8畳/プレハブ洋室:13畳 スチーム式 フィルター不要 ホワイト EE-RM50-WA

近鉄の新型名阪特急に物申す

気動車のことを「電車」と呼ばれると顔を真っ赤にして訂正したくなるaikawameです。ごきげんよう。

はじめに

近鉄が「新型名阪特急」の新造について発表した。

news.mynavi.jp

72両という製造数からして、アーバンライナーplusを置き換える計画なのだろう。僕は実家の庭から近鉄電車が見えるような環境で育ったし、アーバンライナーはリニューアル前も後も乗ったことがあって思い入れ深く、今回の発表には色々と思う所があったので、少し吐き出してみようと思う。

良くも悪くも変える近鉄

僕は近鉄には思い入れがあるけれども、「近鉄といえば？」と訊かれて即答できるようなキーワードが中々出てこない。

例えば、阪急の「マルーンの電車」、京急の「赤い電車」のように、固有の色を持っている会社がある。あるいは、名鉄の「パノラマカー」や小田急の「ロマンスカー」のように、看板列車を持っている会社がある。

翻って近鉄はどうか。通勤車両はここ30年程の間にマルーンレッド単色から白の入ったツートン、そしてシリーズ21へと激変している。特急車両も橙と紺のツートンが当初からの伝統だったのに、それが白基調に変わってしまった。

看板列車はというと、ビスタカーからアーバンライナーへ移り、伊勢志摩ライナーやしまかぜのような観光列車も出てきた。とはいえ、数で言えば何だかんだでアーバンライナーが花形で、今までなら「近鉄といえばアーバンライナー」とまだ言えたと思う。

それが今回の発表で見事に砕けた。恐らくアーバンライナーという愛称は変わるだろうし、仮に残ったとしても白基調でないアーバンライナーは、果たしてアーバンライナーなのか？と思ってしまう。

近鉄という会社は、良く言えば常に新しいことに挑戦しているけれども、悪く言えば節操なくあれもこれも変えているというのが率直な印象だ。何が正しいとははっきり言いにくいけれども、鉄道に関して言えば伝統というのは結構重要ではないかと思う部分がある。

郷愁に浸りたい

例えば、鉄道に少しでも興味があれば、地元の路線や旅先で乗った路線など、誰しも思い出はあると思う。そんな路線に久しぶりに乗ろうと思ったら、車両の形式も色も何もかも変わっていた。それって結構寂しくないだろうか。

無論、鉄道車両にも寿命はあるので、新型に置換えられていくのは仕方ないし、サービスの向上という点では歓迎されるべきだとは思う。一方で、外観というのは以前の世代から継承できる部分は必ずあるはずなので、そこは何かしら残してもらえないものかと思う。

例えば、京急などは「赤い電車」のイメージを守るために、塗装不要のステンレス車に敢えて塗装するという拘りを見せている。そこまでではなくても、JR東海のような、ほぼ全ての形式にコーポレートカラーを入れるというやり方も良いと思う。没個性と表裏一体ではあるけれども、東海圏の何処へ行っても橙色の列車がやってくるという安心感は、それはそれで悪くないものだ。

大井川鐡道やいすみ鐡道のような「保存鉄道」の取り組みが注目されるようになったのも、嘗て走っていた昭和の名車が姿形もそのままに残されているからであって、そうした需要があることからしても、伝統を継承していくことは長期的に意味があると思うのだけれども、いかがだろうか。願わくは、駅ホームの緑色したビニール屋根くらいは近鉄名物として後世まで伝えてほしいものだ。

おわりに

普段はこのカテゴリーも、社寺巡礼と同様に各地の鉄道を巡った記録を残す場所にしようと思っていたのだけれども、さすがに真冬は寒くて外に出るのが辛いので、ポエムでお茶を濁してしまった。早く春になってほしい。

あと、どうでも良い話だけれども、サクラ大戦で真宮寺さくらが「電車が来ました！」という名言を残したことは今でも忘れていない。

近鉄特急デビュー50周年記念 栄光の近鉄特急 [完全復刻版] ~2200系からビスタEX~ [DVD]

Chaliceでハマらないために

サーバーレスでAPIを作りたくて、Chaliceを使ってみた。非常にシンプルで、爆速でAPIを開発できそうだけれども、幾つか留意しておきたいポイントがあったので記しておく。なお、Chaliceについては他の記事で詳しく説明されているので、そちらを参照されたい。

qiita.com dev.classmethod.jp

自前の設定は自分で用意

.chalice 配下に config.json があるので使えそうな気がしたが、environment_variables で定義できるのはその名の通り文字列だけなので、ここに自前の設定ファイルのパスを定義して、別途呼び出すのが良さそうだ。

app.py以外のファイルの置き場所

公式でも言及されているし、やはりダメだったという感じだが、chalicelib 以外のディレクトリー配下にファイルを置いた場合、ローカルでは動作するが、デプロイすると動作しない。最新のChaliceだと chalice local で手軽にローカル開発ができるが、この点には注意しておきたい。

受け付けるContent-Type

Chaliceは特に指定しないとapplication/json以外のリクエストを 415 Unsupported Media Type で返してしまう。その他のContent-Typeを受け付ける場合は、次のようにオプションを指定する必要がある。

@app.route('/', content_types=['application/x-www-form-urlencoded', 'application/json'])

デプロイ時の依存関係に関する警告

pipでインストールしたライブラリー等を利用している場合、デプロイ時に次のような警告が出る場合がある。

Could not install dependencies:
MarkupSafe==1.0
You will have to build these yourself and vendor them in
the chalice vendor folder.

ここで公式の説明通りに自分でビルドして vendor 配下に設置したのだけれども、環境やPythonのバージョンも問題ないはずなのに一部のパッケージだけ警告が収まらなかった。

仕方ないのでとりあえず試しにとAPIを叩いてみたら、なんと普通に動いていた…。

原因については深く追えておらず不明だが、とりあえずデプロイ自体に問題無ければ一度APIを叩いてみると良さそうだ。

蛇足

折角なので、実際にChaliceで書いたコードと解説へのリンクを晒しておく。

github.com

aikawame.hateblo.jp

ChatWork向けIncoming Webhooks的なものを作った

ウェブサービスでアイコンがデフォルトのアカウントはみんなじゃがいもだと思っているaikawameです。ごきげんよう。

はじめに

僕の勤めている会社では、社内チャットにChatWorkを利用している。「ChatWorkが許されるのは小学生までだよねー」とかSlack派に煽られそうだけれども、僕自身はそんなに嫌いではない。ただ、Slackに比べて欲しい機能が足りていないのは事実だったりする。

その中でも特に、会社のメンバー間でも不満だったのが、Incoming Webhooksが無いということだった。これだけのためにエンジニアはSlackも使うという残念な状況が出来てしまっていた。

そこで、似たような仕組みを誰か作っていないかと探してみたが、要件を全て満たしてくれるようなイケてる子は見当たらなかったので、無いものは作るの精神でサクッと作ってみた。

作ったもの

出来上がったものはこちら。

github.com

標準でGitHub、Backlog、ScrapboxとSlackのAttachment structureに対応しつつ、基本的に設定とテンプレートの追加だけで対応サービスを増やしていけるので、サクッと作った割には良い感じになったと思う。

フレームワークとして採用したのはChalice。AWS Lambdaを使ってAPI環境を実行できるサーバーレスフレームワークだ。Lambda界隈だとServerless Frameworkが強いとは思いつつも、個人的にnodeよりはPythonの方が好きなので、こちらを選んだ。というかLambdaはPythonでしか使ったこと無い…。

苦労したこと

Chalice周りとか、普通の実装については割とすんなり行ったと思う。面倒だったのは主にWebhookで送られてくるJSONの解析や、テンプレートのフォーマット周りだった。

前者については、これはもう地道にやるしかなかった。ScrapboxはSlackのAttachment structureに対応していたし通知も1種類だったから一瞬だったけれども、GitHubとBacklogは曲者過ぎた。さすがに全てのパターンを網羅するのは辛いので、とりあえず業務で使っている部分だけテンプレートを用意して、あとは無視する形でお茶を濁している…。この辺、Webhookの共通フォーマットとか作ってもらえないものだろうか、Attachment structureみたいに。

後者については、ChatWorkで使える装飾が少なすぎて辛かった。Attachment structureでは色やリンクを指定できる所をどうやって表現しようとか、段々と考えるのが面倒になってきたので、とりあえず最低限タイトルと本文だけでいいやという感じに落ち着いた。

おわりに

会社でX2ChatWorkを導入してみた限りでは概ね好評で、既存のSlackへの通知はほぼChatWorkに置き換えた。この勢いならばSlackの撲滅は近そうだ。もし、ChatWorkを使いつつIncoming Webhooks的な仕組みも欲しいという方がいれば、是非とも試していただきたい。そして星くれ。

チャットワーク【公式】活用ガイド

平成30年の初詣

神社の境内で馬鹿笑いしている人を見るとモスクで同じことをしたらどうなるのかなんて想像してしまうaikawameです。ごきげんよう。

はじめに

年末年始は1年の中で最も神社に人が集まる時期だ。特に初詣の時期は神社が賑やかになるので、平素から参拝している神社でもついつい写真に収めてしまう。というわけで、この年末年始に参った神社についてまとめておきたい。

御礼参り

僕はここ数年、師走の中頃になると、氏神様である新宿諏訪神社と新宿総鎮守である花園神社へ御礼参りに出掛けている。その1年の御礼のためと、翌年の御神札を頂くためだ。本当はお伊勢さんまで参拝したいのだけれども、さすがに東京からは遠いので、数年に1度しか参れていないのは残念なところではある。

昨年はバタバタしてしまい、御礼参りは最終週の平日になってしまったけれども、無事に済ませて御神札も取り替えることが出来た。

初詣

初詣については元旦にすべきか2年参りか迷い所ではあるけれども、基本的にその年々の気分で決めている。今年は元旦だと起きるのが辛い気配だったので、先に参ろうと日が変わる前から氏神様に並ぶことにした。

実は諏訪神社へ夜に参拝したのは初めてで、松明を焚いていたりお神酒が振る舞われていたりと賑やかだったのには驚いた。しかも先着500名で宝船（枕元に敷くアレ）まで頂いてしまった。2年参り、アリだな。

続いて花園神社へは6日に参拝。こちらは毎年のことながら凄い人だかり。新宿で遊びがてら寄った感じの若者がやたら多い。まぁ、神社が潤うことには違いないので、僕はそこまで毛嫌いしているわけではない。ただ、御手水で柄杓に口付けるのだけはやめてね（にっこり）。

更に9日、仕事始めということもあり、出社前に東京大神宮へ参拝。お伊勢さんへ直接参れていないので、せめてもと毎年東京大神宮か芝大神宮のどちらかには参拝するようにしている。こちらは参る度に感じるのだけれども、鳥居の前で一礼している人が靖國神社を超えるのではないかというくらい多い。

会社でも初詣

僕が勤めているのはバリバリのウェブ系スタートアップなので縁がないかと思っていたけれども、意外にも会社として初詣に出掛けることになっていた。しかも神田神社へ。この時期大混雑の、あの神田明神だ。

と思ったら意外にも空いていて、すぐに受付を済ませられてしまった。そして拝殿へ。昇殿参拝は久々だったけれども、やはり気が引き締まる。

おわりに

兎にも角にも、初詣は無事に済ませられた。今年もこれから各地の社寺を巡りたいと思っている。

冴えない彼女の育てかたを全巻読んだ

コミケでサークル入場者が「見ろ、人がゴミのようだ！」と言っているのを見ると「フ…貴様もこの世界からすればゴミのようなもの…」と心の中で呟いてしまうaikawameです。ごきげんよう。

はじめに

ネタバレは無しの方向で。

冴えない彼女の育てかた、通称冴えカノ。僕にとっては今の所唯一まともに読んだライトノベルだったりする。そっち系の趣味というと、20代まで所謂美少女ゲー（というかエロゲーですぼかしてごめんなさい）をちょくちょくやっていたくらいで、今は基本的にアニメ専門という感じ。アニメ繋がりだと、漫画原作ならば面白ければ読むことはあっても、ラノベ原作となると時間的な所で中々手を出せずにいた。

そんな僕がアニメ1期でどハマりして全巻読破、しかもコミカライズ3ルートまで全て網羅するくらいなので、冴えカノは凄いと思う。最終巻を買ってから暫く経つが、漸く踏ん切りをつけて読み切ったので、つらつらと思うがままに綴っていく。

何が良かったのか

冴えカノが僕の琴線に触れた所は2点あって、作品全体がエロゲーの文脈で綴られていることと、同人活動を主題にした作品であるということだ。

前者については、作者の丸戸史明先生がそもそもエロゲー畑の方で、しかも蛭田信者という筋金入りなので、さもありなんという感じがする。エロゲーというと僕らの世代だと葉鍵が鉄板だけれども、僕はあの手のあざとさは若干苦手で、それよりも初期蛭田作品のようなドタバタコメディーと重厚なドラマが入り交じったような作風を好んでいたりする。そういう意味では、冴えカノの主人公は底抜けにバカで妙に熱いあたり、ドンピシャなのだ。どこかの鳴○孝○君とは正反対だな…。いや、○ge作品は好きだけれども。

閑話休題。

後者については、完全に個人的な理由になるけれども、僕自身も20台の頃同人活動をやっていたことが大きい。色々あってエンジニア業に集中することにはなったけれども、締切前の修羅場感とか、コミケ出展の高揚感、あとはクリエイターの矜持など、当時があったからこそ共感することばかりだった。

特にクリエイターの心情表現が熱い。クリエイターの世界を扱う作品としては直近だとSHIROBAKOが有名だけれども、あれはどちらかと言えば叙事的だと思う。というか、そう思えるくらいに冴えカノがドロドロとしたクリエイターの内面をよく描いているのかもしれない。特にアニメや原作準拠コミカライズで描かれていない先の話に至っては、一般人からすれば狂っているとしか思えないような、狂いすぎていてファンタジー扱いされそうな場面が出てくる。

でも、クリエイターの世界に足を突っ込んだ人ならわかるのだろうけれども、あの世界は創作があらゆる他の事象に優先するという意味では確かに狂っていると思う。そういう人達の生々しい心情表現をラブコメに混ぜて一つの作品に昇華しているのが、冴えカノの凄い所だ。

創作とは何なのか、才能とは何なのか

僕は、創作というのは公開オナニーだと思っている。少なくとも同人界隈においては。だってそうだろう、純粋に自分が理想としているものを形にして世に出して、それによって満足を得ているのだから。R-18の同人誌など、「私はこういうシチュエーションでの絡みが一番抜けます」と宣言しているようなものだ。そして、その公開オナニーの持続力こそが才能だと思っている。これ、割と真面目な話。

冴えカノは、まさにこういったクリエイターの本質的な部分を緻密に描くことで、創作とは、才能とはという問いに対する答えをそれぞれの登場人物を通して表現していると思う。巷ではキャラが皆頭おかしいとかキ○ガイとか言われて久しいけれども、これもまた、普通の神経ではガチの創作なんて出来やしないことを示唆しているように思えてならない。実際の同人の世界にも、頭のネジが何本か抜けたような人がわんさかいるし。しかも、そういう人ほど凄い作品を作っていたりするから、あの界隈は面白いし、だからやっぱり創作はイカれた行為なのだ（異論は認める）。

そんな世界をリアルに描写しているから、冴えカノもまた面白いのだ。

少しだけ自分の話

少しだけ自分の話をすると、僕の場合は同人活動において、持続力が足りなかったと思う。創作自体は好きだったとしても、すぐスランプに陥って、プログラミングの方に浮気して、なかなかネタが出なかった。しかも、作品を創ることだけでなく、サークルの運営も好きだったので、ガチで創作一筋の人達に敵う訳が無かった。いや、別に同人なので誰に勝つとか負けるとかは無いのだけれども、それでも本業以外の時間の大半を割いてやるだけの価値があるのか？と自問した時に、最終的には余暇も含めてエンジニア業に集中すべきだという結論になった。

今でもこの判断は正しかったと思っている。というのも、僕にとってはエンジニア業も創作なのだ。公私含めて。しかも、同人でやっていた時よりもスランプは短い（それでもあるが）し、他に浮気するようなものも無い。晴れて自分もガチで創作一筋の人になれたというわけだ。まぁ余暇に鉄道旅行したり社寺を巡っていたりはするので、キチ○イクリエイターの域には達していないと思うけれども、そこが才能というやつで、僕は余暇を100%プログラミングに注ぎ込む才能は無いというだけのことだ。それは多分自分でも制御し切れない部分なので、あとは代わりに与えられた「器用貧乏」という才能を活かしていくということになるのだろう。

とは言いながらも、どこかでまだ、本物のキ○ガイクリエイターへの憧れがあるから、冴えカノに惹かれるのだろうな。

おわりに

冴えカノはライトノベルという形での刊行だし、表面上はゆるいラブコメなので、SHIROBAKOであれば手に取れた層でもこれはさすがに…となりがちかもしれない。でも、冴えカノは読めば読むほどクリエイターの光と闇の世界に引き込まれていくこと間違いないので、あの世界に興味のある方は一度読んでみると良いと思う。ちなみに、僕はこの作品の真骨頂は後半部分だと思っているので、アニメやコミカライズではなく原作をお薦めしておく。

ちなみに、僕の推しは紅坂朱音です。

冴えない彼女の育てかた13 (ファンタジア文庫)

ブログとQiitaの使い分け

ブログとQiitaに同じ内容の記事が上がっているのを見るとティム・バーナーズ＝リーにジャンピング土下座させたくなるaikawameです。ごきげんよう。

はじめに

僕はQiitaアカウントも持っているのだけれども、ブログを始めてみてどちらにどんな記事を投稿するのかを決めておかないと後々面倒だと思ったので、まとめておく。

Qiitaに書くこと

Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。

とあるように、Qiitaはその目的を明確に定義している。なので、まずはQiitaに書くことを整理してみる。

プログラミングや周辺技術に関する知見

• プログラミング
• インフラ技術
• 開発に役立つツール

ブログに書くこと

一方で、ブログに書くことは早い話がQiitaに書くこと以外の全てとなるが、一応整理してみる。

技術的でない記事

• 鉄道
• 社寺巡礼
• アニメ・ゲーム等
• その他趣味など

このあたりは考えるまでもない。

プログラミングには関係の無い（薄い）技術的な記事

• 自作PC
• デジタルガジェット

このあたりは若干プログラミングも絡んできそうだけれども、プログラミングが主でなければ全てブログに書く。

プログラミングに関係はあるが知識ではない記事

• 作ってみた
• 書評
• ポエム

作ってみた系は若干ややこしくなりそう。成果物についての説明はブログに、その途中で得た知見は切り出してQiitaに書くのが良さそうかな。

結論

• 知見はQiitaへ
• 主張はブログへ

蛇足

• ブログとQiitaに同じ内容を投稿するのは技術者としてあるまじき行為なので絶許。
• Qiitaにブログへの踏み台記事を投稿するのは人としてあるまじき行為なので絶許。

Qiita 人気の投稿

キーバインド 復活のKarabiner

JISキーボードを見ると半角/全角キーにセメダインを流し込みたくなるaikawameです。ごきげんよう。

はじめに

macOS Sierraになってから、IMEのトグルやEmacsキーバインドを設定していたKarabinerというツールが動かなくなってしまった。当時は暫くEl Capitanを使い続ければ良いやくらいに思っていたものの、昨年の夏に転職してSierraの入ったMacを手にしたことで、強制的に代替策を検討する必要に駆られてしまった。

当時はKarabiner-Elementsという後継ツールはあったものの、単一キーの入れ替えにしか対応していなかったので選択肢とはならなかった。そこで代わりとして不十分ながらもHammerspoonを使っていたのだけれども、Karabiner-Elementsがここ数ヶ月で正式リリースを経て格段に進化していたらしい。これは試さない理由は無い。

作ったもの

というわけで、論より証拠で自分用のキーバインド設定を作ってみたのがこちら。

github.com

Karabiner時代とは違い、設定ファイルは分割できて、JSONで書けるようになっている。それぞれのファイルの内容は次のような感じだ。

emacs_key_bindings.json

本家サイトからもEmacsキーバインドの設定はインポートできるのだが、僕は主にブラウザー向けとして、C-s/C-rで検索したり、C-x b/C-x kでタブを開閉したり、テキスト入力にもオレオレ設定が必要なので、全部自分で書くことにした。あくまで個人用途に書いたものなので、

• 除外するアプリケーションは自分の使っているものしか書いていない（iTerm2、Sublime3、IntelliJ）
• CapsLockを有効にしていると使えない
• 左側のCtrl/Optionキーしか使えない

等の制限があるが、書き換えるのは簡単なので自由に利用してもらって構わない。

for_japanese.json

僕はUSキーボードを使っていて、IMEの切り替えは右Optionでトグルしている。これはPC-98を愛用していた頃のXFERキーの名残だったりする。そもそもUSキーボードを使っているのも、「PC-98みたいにスペースバーが長いから」というのがそもそもの理由だったりする…。

閑話休題。こちらの設定では右OptionによるIMEのトグルが実現できる。別のキーに替える時の参考にもどうぞ。

windows_key_bindings.json

こちらはWindows時代の名残で、ブラウザーの更新はやっぱりF5だよねというやつ。くれぐれも攻撃には使わないように。

おわりに

この3ファイルを作った所で、僕が必要としているキーバインドの条件は全てクリアされたので、めでたくHammerspoonからKarabiner-Elementsに移行完了できた。僕はKarabinerがKeyRemap4MacBookと呼ばれていた頃から使わせてもらっていたこともあり、今回ばかりはと寄付もさせてもらった。macOSの仕様変更にも負けず、更に使いやすいツールに育ててくれた作者のtekezo氏には感謝するしかない。

コードギアス 反逆のルルーシュＩ 興道

元日によせて

渋谷の年越しカウントダウンを見ると上空から水溶き片栗粉を散布したくなるaikawameです。ごきげんよう。

はじめに

あけましておめでとうございます。早いもので平成も30年となりました。今年からはいよいよ本格的に記事を書いていこうと思いますので、どうぞよろしくお願いします。

今年の抱負

一年の計は元旦にありと言うけれども、僕は今年の抱負というのを具体的には掲げないようにしている。年初に抱負を掲げると、それに縛られてしまうと考えているからだ。自らの可能性を狭めてしまうようにも思う。それよりも、時々で見つけた興味対象に打ち込んで、面白おかしく過ごしていければと思っている。

こうやって言うと少し格好付けた感じになるが、結局の所は目標や抱負を掲げた通りに実行するのが大の苦手というだけだ。何かをやろうと思っていても、他に強い興味対象が出てくるとすぐに目移りしてしまう。なので、先に決めていたことなど足枷にしかならない。

ただ、その結果として今もそれなりに楽しく生きられているので、悪くはないと思っている。僕がもっと堅実な人間だったとしたら、ソシャゲ黎明期にえいやっと業界に飛び込むような真似もしなかっただろうし、人に誘われてホイホイ転職なんてこともしなかっただろうから、エンジニアとしてそれなりの経験を積めたかどうか逆に怪しい。

どうせ根底部分の性格は大人になってからはそうそう変わらないし、その性格を有効活用することに注力した方が良いだろうということだな。

蛇足

今年は3度目の年男らしい。一応戌年なのだけれども、誰か僕に忠誠心を分けてください。

中の人について

スタバでドヤ顔している人を見るとMacを叩き割りたくなるaikawameです。ごきげんよう。

はじめに

所謂ブログというやつの最初の記事に自己紹介とか痛すぎないかと思ったけれども、意外と色々なブログを巡ってみても自己紹介記事のあるブログが余り見当たらなかったので、逆に書いてみたくなった。

年齢

昭和57年（1982年）生まれ。PC-98誕生の1ヶ月後に生を受ける。

住んでいる所

東京都新宿区、歌舞伎町の銃声が聞こえてくるくらいの所。

主に住んでいた所

• 三重県鈴鹿市、サーキットのF1レースが聞こえてくるくらいの所。生誕から高校まで。
• 滋賀県彦根市、夏になると彦根城のお堀が臭ってくるくらいの所。大学の4年間。
• 滋賀県大津市、「中二病でも恋がしたい！」の主人公自宅の近所。仕事で3年ほど。

言葉

伊勢弁と近江弁のごった煮。
京滋圏の人からは名古屋人と思われ、それ以外からは京都人と思われやすい。東京弁には意地でも染まらない。

仕事

ウェブ系のエンジニア。サーバーサイドを中心に、インフラやフロントもぼちぼち。

• 2005年から新卒でSIerに入るも、すぐに辞める。
• 2007年から携帯電話向けのサービス開発に携わる。
• 2010年からソーシャルゲームの開発に携わる。
• 2017年から普通のウェブ系スタートアップへ。

好き

プログラミング、鉄道、社寺巡礼、アニメ、音楽、ソニー

嫌い

チャラい系、煙草、現金決済、カタカナ語、運動、Apple

性格

見た目は紳士、中身は中二。決して厨二ではない（ここ重要）。
普段は口外しないが、大抵は「俺はあいつらとは違う」みたいなことを考えている。「中二病でも恋がしたい！」については、「厨二病でも恋がしたい！」に改名すべきだと壁に向かって言い続けているが、なかなか聞き入れてもらえない。

コミュ障と言うと意外な顔をされるが、大のコミュ障。
中学に入るまでは担任の教師ともまともに話せなかった。大人になってから一般人に擬態することを覚え、仕事でマネージャー的な立場だったような時期もあるが、本当は人よりもPCとキャッキャウフフしていたい。

なぜブログを始めたのか

一番の理由はタイトルにもある年齢。「エンジニア35歳定年説」なるものも囁かれる中で、寄る年波に抗うおっさんエンジニアの生態について書き綴っていくのは、それなりに意味のあることではないかと思ったため。

ちなみに、ブログを書こうと思ったことは何度かあった。ただ、文章を書くのは割と好きなのだが、凝り性なのでついつい時間を掛けてしまい、これでは続かない、と最初の記事も公開せずに投げ出してしまうことの繰り返しだった。

そんな事情もあり、とにかくその時々に思った内容をあっさりと書いていくことを念頭に、無理せず続けていければと思っている。ちなみに、大晦日に最初の記事を公開したのは、年明けだと在り来りだからに決まっている。皆まで言わせるな。

これからのこと

僕は健康でいられる限りはエンジニアという人種であろうと思っている。また、生涯中二病なのも変わらないと思っている。その辺りを軸に、僕の興味対象となる技術や時事ネタ、鉄道・社寺巡礼など趣味の話をつらつらと綴っていきたいと思う。