大阪でリモートワークをすることにしました

さらば東京。

10/1 から大阪に引っ越しをし、コベリンの業務をリモートで行うようにしました。10年間住んだ東京、関東から引っ越しをすることとなります。

なんで引っ越しをするのか

リモートワーク自体はただの手段で、本当の目的は俺が引っ越しをしたかったから。なんで引っ越しがしたいのかって言うと東京に疲れたからかなぁ。何がどう疲れたのかと聞かれても特に答えられないけど、10年間住んだんだからまぁ、そんなもんやろって感じ。

奥さんも快く了解をしてくれました。ありがたいありがたい。

最後に住んだ椎名町

進学のために東京に出てきて大学の近くの調布市に。そのあと、コベリンへの入社をきっかけに埼玉へ。最後はコベリンのオフィス移転と俺の結婚に伴う同棲開始をきっかけに椎名町へ。椎名町はかつて「トキワ荘」があった町なので、町を上げてトキワ荘を推していたのが印象的でした。

近所の公園にはトキワ荘のモニュメントが。このモニュメント、しっかり手塚治虫の名前も掘られていますけど、彼はあんまりトキワ荘には住んでないんですよね。

近所にあったとんかつ屋。家の近くに良い感じのお店がなかった中このとんかつ屋だけは値段が安くて美味しかった。

有名な松葉。トキワ荘との関連性がなかったら、このお店が残ることもなかったんじゃないのか？と思わざるを得ないようなお店。

松葉の向かいにはトキワ荘の跡地とモニュメントがありました。今では出版社になっているようで建物の面影なんかはありませんね。

近くにはトキワ荘通りお休み処なるものも。ときどき企画展なんかをやっているようですが、そう言えば入ったこと無いや。

高校生の時にまんが道を読んだ影響でトキワ荘は憧れがあった。大学に進学してから聖地純連として行ったのもいい思い出。去年の初夏に奥さんと家探しをしていたころ、赤羽の不動産屋に連れて行ってもらったのが今の物件だった。物件巡りをしていたときに急に見覚えのある風景の場所に出たと思ったら椎名町。高校のときに憧れたトキワ荘の近くに住むことになろうとは思わなかったなぁ。

会社まで歩いてだいたい30分くらいのいい距離。飲めるお店のバリエーションはあんまりないけれど、住んでいて面白いところでした。

コベリンオフィスの案内

デスクを片付けた。

10月からはリモートワークなのでコベリンオフィスの俺のデスクは余ります。余ったスペースをなんか使いたいなぁーって思いがあるので、なんかやります！一応、ネタの考えと提案はやっているので今週か来週あたりにアナウンスをできるけど。

業務内容は今までと変わらずに進めていく感じ。完全リモートワークを行うことを念頭に置いて会議やコミュニケーションを取るための設備や環境、ルール作りをやってきました。

そんなわけで、大阪に住むのでそっち方面の人は相手してください。

www.amazon.co.jp

引っ越しして落ち着いたら燻製会とかやりたい。あと、ホームシアター的なものを作ろうかなって思いがある。

Googleカレンダーの内容をLineに通知するくんを作った

Google カレンダーの内容通知、 slackには簡単に連携できるけど、Lineはその限りでもないなーって思ってた。

家族のカレンダーをファミリー・グループのカレンダーで共有しているのだけれど、明日何があるのかとかを適当なチャットサービスに通知してほしい思いはあった。カレンダーアプリが通知してくれるしカレンダーを見に行けば良いんだけど、最近は会社でもG Suiteを導入してきたこともあってカレンダーが若干煩雑気味になってしまってる。

家族の予定だけをLineに通知してくれ〜って思ってたら、 Google Apps Script が簡単そうだったのでｼｭｯと作ってみた。

github.com

とりあえずファミリーカレンダーのみ。

Google Apps Script はWeb上で気軽にjsを動かすことができるんだけれど、モダンなjsが書けないこととバージョン管理ができないこと、テストができないことが嫌でなんとかしたかった。

昔、引っ越しをするときにSuumoとかをスクレイピングしてスプレッドシートに貼り付けるくんを作ろうとしたけど、結局ローカルでjsかけない問題が嫌でスプレッドシートの関数で頑張ったのおいい思い出。

その辺りをいい加減今回は解決したくて、ちゃんと家初環境を作った。

qiita.com

ググるとBabelとかBrowserifyとか使うと良いよ！ってのはわかったんだけど、じゃあ具体的にディレクトリとかどうするのがいいの？とかってなるといい感じの情報がなかった。

そのあたりのあれこれを自分流にいい感じにしたのが上の記事。Babelでググるとgulpを使った〜とかの情報もでてきて中々にnoisyだった。そんなことをしたいわけじゃない。

久々にGASを使ったけどちゃんと環境を作ってやれば全てがいい感じだった。これだったTypeScriptとかkotlinJSとかでコード書いたりできそうだなって思いましたまる。

プログラミング言語の例外

大抵のプログラミング言語に備わっている機能の1つが「例外」。

例外的状態を表現して例外からの回復やリソースの開放、エンドユーザへの通知に利用される機能。なんだけど、この「例外」という機能がいまいちしっくりこなくて、例外について考える夜が年に２〜３回ある。ここで客観的な例外の機能と自分の持っている疑問をまとめておこうかなぁと思った次第。

qiita に書こうかなとも思ったけど、「よくわかりませんでした」って書くとぶっ殺されそうな気がするのでやめる。

例外的状態ってなに？

例外的状態という言葉があって、この状態を表現する機能が例外だとされていると思ってる。で、例外的状態ってものが何なのかわからない。そこで例外的状態でない状態を考えて、それでないものが例外的状態とする。

例外的状態でない状態が何なのかと言えば、多分契約が満たされている状態なんだと思う。

契約プログラミング - Wikipedia

契約が満たされている状態は、 wikipedia からの引用をすると、

事前条件 (precondition) サブルーチンの開始時に、これを呼ぶ側で保証すべき性質。

事後条件 (postcondition) サブルーチンが、終了時に保証すべき性質。

不変条件 (invariant) クラスなどのオブジェクトがその外部に公開しているすべての操作の開始時と終了時に保証されるべき、オブジェクト毎に共通した性質。

これらを満たしている状態が契約を満たしている状態と言えるっぽい。コンテキスト、仕様によって事前条件や事後条件は変わってくるのだと思う。事前条件や事後条件、不変条件を満たしているにも関わらずプログラムが失敗をするのならそれは例外といえるのかもしれない。

ちょっと前に話題になった例外アドベントカレンダーからこの記事が気になった。

qiita.com

記事の後半の方でファイルのI/O処理に関して例外的状況になり得ることを示している。ここで例えをHTTP通信を行う実装について考えてみる。

あるURLへアクセスをしてHTTPのbodyを取得するプログラムだ。この事前条件は何だろうか。

• そのURLのドメインが存在する、名前解決ができる
• HTTPのコネクションを貼ることができるデバイスが提供されている
• リクエストをするURLのパスやHTTPのヘッダー、body、その他のパラメータが間違っていない

何となくこんなところだろうか。それに対して事後条件は

• 目的のデータが得られる

たぶんこれだけだ。

そうなると例外的状況はいくつか思いつく。

• 接続中に何らかの理由で接続が遮断されてしまった。デバイスのエラーなど
• サーバーに何かがあって正しいレスポンスが得られなかった
• 存在していると思ったURLにデータがなかった

これらは全部例外的状態なのだろうか。「存在していると思ったURLにデータがなかった」は割とよく起こりうる。HTTP404のレスポンスが得られる場合だ。

しかし、HTTP通信を行う仕組みを作る上でHTTP404を想定しないでコードを書くだろうか？

例外的状態は場合によるのか

HTTP通信の仕組みを作るときにHTTP404を想定しないでコードを書く事がありえるのだろうか。

全体のシステムの中で「このURLには必ずデータがある」と仕様書などで定められていたならば、例外的状態になりえるようにも思う。逆に、とくにそう言った仕様がないのであれば例外なのか。

コードで書くとこうなる。

sealed class HttpResponse

data class Success(val responseCode: Int = 200,val header: Map<String, String>, val body: ByteArray)
data class Failure(val responseCode: Int, header: Map<String, String>, val body: ByteArray)

fun httpRequest(request: Request): HttpResponse {
  // 省略
}

// 顧客データを取り出す
// 顧客データはいつも /clients にあるし、サーバーは絶対にレスポンスをするのでそれ以外は例外
val client = (httpRequest(clientsRequest) as Success).body

// 商品データを取り出す
// 別システムが出力しないことがあるので、失敗を考慮
val response = httpRerquest(itemRequest)
when(response) {
  Success(_,_, body) -> {}
  Failure(code,_,body) -> {}

こういうこと？まじで？見ての通りコメントによる補強が必要な実装となった。もしもコメントが無かったらこの２つの処理でレスポンスの取扱が異なる理由を知るにはドキュメントを見返す必要が出てくる。（そして、往々にしてコメントは忘れられる）

１つの仕組みになっている方が良い気がする

結局今回の疑問はこういう「場合によっては例外だけど場合によっては例外じゃない」のは正しいのかどうか分からなくなった点。上の例だといつでもHTTPのレスポンスに対してSuccessなのかFailureなのかを想定したコードを書くのが適切だと思う。その結果、例外という仕組みは消え去った。

他にも例えばファイル読み書き時のIOExceptionなんて例外もある。OSから上がってくる割り込みとかどうすればええねん、って思う一方で「OSが割り込みをしてくることも有るし、それを想定したコードを書くべきなのでは？」とも思う。

結局、例外とはあるいは例外的状態とは何なのか、今のプログラミング言語で利用されている例外処理の機能は適切なものなのかが分からなくなったという話。

どう死ぬかより、どう生きたかを考えて生きたい

渚にて【新版】 人類最後の日 (創元SF文庫)

最近は読書感想文ばっかりだなぁ。

Hard Things を読んで次はフィクションかなぁと思い読む本を探していた。そう言えばガイナックスのアニメはサブタイトルにSF小説のタイトルを使っていたなぁと思い「放課後のプレアデス」のwikipediaのページを開いた。

放課後のプレアデス - Wikipedia

最終話のタイトルは「渚にて」。以前から気になっていた本だったことを思い出した。

第三次世界大戦が勃発し、世界各地で４７００個以上の核爆弾が炸裂した。戦争は短期間に終結したが、北半球は濃密な放射能に覆われ、汚染された諸国は次々と死滅していった。かろうじて生き残った合衆国の原潜〈スコーピオン〉は汚染帯を避けてメルボルンに退避してくる。オーストラリアはまだ無事だった。だが放射性物質は徐々に南下し、人類最後の日は刻々と近づいていた。そんななか、一縷の希望がもたらされた。合衆国のシアトルから途切れ途切れのモールス信号が届くのだ。生存者がいるのだろうか？　最後の望みを託され、〈スコーピオン〉は出航する……。読者に感動をもって迫る永遠の名作。

ポストアポカリプス。直接的な難を逃れオーストラリアに住む人々の物語。SF的ギミックと言うよりも仮想の世界の中で人々がどう生きるのか、どう死んでいくのかをそれぞれの人々の目線で描くスタイルが自分の好みと一致した。

スコーピオンの艦長はアメリカ軍人の潜水艦艦長として。彼の部下でオーストラリア海軍の将校は一家を支える父親として。アメリカ軍人を愛した女性も叶うことの無い恋だと知っていてもそれでも一人の男性を愛した女性として。それぞれが最後の時を迎えた。その生き様、死ぬことへの恐れよりも誇りを失うことを恐れる人々の姿に心が震えた。

そう言えば、昔似たようなテーマのゲームが有ったなと思って記憶を掘り起こしてみた。「そして明日の世界より――」だ。

そして明日の世界よりー

こちらは人類が完全に滅亡するわけではなく一部の人の生存の可能性が残されていた。ただ、主人公たちは生き残ることよりも今を精一杯生きることに価値を見出していずれ訪れるであろう人類の再興の日のために遺産を残す。

どちらの作品も生きることに絶望することなく精一杯生きることが美徳であると表現されていた。一日居日を無駄にすることなく、あるいは無駄にすることすらも価値を持った一日だと振り返ることができるように生きていきたいものだ。

HARD THING -これからスケールしたい会社で働くときに読むべき指南書の一つ-

HARD THINGS

本を読んで、CEOって大変だなぁと素直に思った。投資家やベンチャーキャピタルから出資を受けて創業CEOとして経営を回すことはこの世で最も難しいことの一つだ。成果が出なければCEOは取締会から解雇されて、経験も成功事例もあるCEOに後継を奪われる。その結果、自分が成したかった夢やビジョンを諦めることになる。

自分は経営者やましてやCEOではないけれど、4人だけの会社で限りなく経営に近いことも考えて社員を努めている。だからこそ、経営者やCEOが何を考えるべきなのかを知りたくてこの本を読んだ。その動機は著者が文中で述べているように「CEOのマニュアルがない」からだ。

実際の所、成功事例や失敗事例はある。しかし、マニュアルはない。「こうすればうまくいく」というお手本のような解答例は無い。そんな物はこの世に存在し得ないことが、この本を通して学んだ一番の事実だ。

もしも一緒に会社に誘った友人を解雇しなければならなくなったら。もしも雇った社員が友達が経営する会社の社員だったら。もしも、出資者に対する大切なスピーチの日に妻が病気で倒れたら。そんな事象にたいするマニュアルは存在しない。著者のベン・ホロウィッツが何を行ったのか、どう考えて行動をするのかという行動指針の提示はあるけれど具体的な行動内容は提案してくれない。それはその時の人間関係や緊急性と言った状態によって定まるものだからだ。

ただ、この本から学んだもう一つのことは誰もがこういった悩みを抱えているという事実だ。誰もが解決できない問題を前に眠れない夜を過ごしたり後悔をしたり時には失敗を、時には成功をしている。マニュアルがないこと、誰もが悩むこと、これがこの世にCEOが存在する限り揺るぎない事実として存在し続ける。

この本を読んでCEOを目指すのももしかしたら、ありかもと思った。少なくとも、今の会社を大きくして社員を雇い組織をデザインするときにもう一度読むだろう。

解答のない荒波の世界の中で生きていく時の羅針盤や地図とは言わずとも、望遠鏡として非常に素晴らしい本だった。

ルールをハックする喜び 「俺たちは異世界に行ったらまず真っ先に物理法則を確認する2」感想

2巻出ましたね！おめでたい！！

友人の @kaname_aizuki氏のデビュー作「俺たちは異世界に行ったらまず真っ先に物理法則を確認する」の2巻が出ました！！

俺たちは異世界に行ったらまず真っ先に物理法則を確認する 2 (ファミ通文庫)

前作のレビューはこちら。

numa08.hateblo.jp

ザザと一緒に新たな街ウルテラを訪れた幹人たち。そこではギルドの頂点を決める“大精霊祭”を前に活気づいていた。初めて見る精霊魔法に興味津々の一同、さらに大会のルールを聞いて驚愕する。前衛の精霊使いと後衛の補助役のタッグ戦―「これってなんかロボコペみたいじゃねえ!?超楽しそお!!」どうにかして出場するために動き出す幹人たちだったが…。精霊魔法も分析、解析!ますます盛り上がる高専生たちの普通じゃない超英雄譚、第2弾!

前回はおっかなびっくり世界の法則を調べ、なんやかんやあってギルドを結成し強敵を倒した高専生の彼らですが今度はちゃんと「ルール」のある大会に出ることに。

そう、ルール。残念ながら、理系の人間はルールが大好きなんです。

そもそもルールとは公平に勝負をするめるために用意されたもの。向かい合う者同士、自分の持ってる実力を発揮するための物だと思う。しかし、高専生というか理系の人間と言うのはこういうルールの隅を突きたくなる。

試験とかで問題文に不備が無いかを真っ先に探すタイプの人間になってしまいます！！

そんなわけで彼らが出場することになった大精霊祭。ルールはシンプル、精霊を使って陣取りをして一定時間以上自分の陣地を埋めたほうが勝ち。

FPSなんかのフラッグ戦と同じルールですね。

ただし、序盤で判明する驚愕の事実。それは「精霊の定義が曖昧」！！

ワクワクしますね。どんなものでも認められればそれは精霊になるんですから。現実世界でのロボコペに出場できなかった彼らはそのリターンマッチのつもりで大精霊祭に臨みます。ルールブックを熟読し違反しないギリギリのラインで、彼らの持つ技術者倫理に反しないレベルで。

ルールの中で無茶をする、自分が大学のときにサークルや実験なんかで良い成績を出すのは彼らのような人間だった気がします。そして、それは今も限られたルールやリソースの中で最大限、普通とは違った発想ができる人間の方が、優れているかどうかは知りませんが面白いし一緒に何かをやりたい、そんな魅力的な人間だと思います。

そんな、人間として個人的には魅力的、社会的に見た時は明らかな異端の彼らの冒険の第2幕。人間関係も前回より濃いものになって開幕です。

秩父ウィスキー祭に行ってきた

第4回秩父ウィスキー祭に行ってきたので、レポです。

秩父ウィスキー祭 2020 | JAPAN ATTRACTIONS

当日券はないよ

レッドアローで行きました。池袋から乗車をしますが、西武百貨店の地下には日本各地の駅弁コーナーがあります。駅弁を食べると旅感が出ますね。

車内放送で秩父ウィスキー祭の当日チケットは既に売り切れたと放送されていました。4回目の開催となると人気が出てくるのか前売り券で終わってしまうようです。来年以降参加をされる場合は気をつけたほうが良さそう。

入場券代わりのグラス

面白いことに入場券を使ってテイスティンググラスと引き換えることができました。このタイプのグラス、以前は東急ハンズで見かけたのですが最近はないようなので有り難いですね。

ただひたすらにウィスキーを飲む

入場料4000円で出展ブースの殆どのウィスキーが試飲可能。いわゆる飲み放題です。また、一部有料試飲もあって、普段よりお安くレアなウィスキーを試すこともできるようです。

非常にピート、そして麦の香りの強いウィスキー。調べるとシングルモルトとして市場に出回ることはほぼなかったそう。わりと麦がエグいので万人にはお勧めできないけれど、この子を使ったブレンデッドを探して比較などをすると楽しそう。

アイラ島のウィスキーだけど水色のボトルの方はアイラ島のピートを利用していない。アイラ島といえばピート！と思っていたが、この蒸留所は麦にこだわってウィスキーを作っているとのことで面白い。水色のボトルのものが蒸留所のベンチマークモデルで、この子をベースに麦の種類が異なるもの、ピートを加えたものとシリーズが続く。

スコットランドの麦を利用したものはチーズのようなフレーバーが、アイラ島の麦を利用したものはより味が濃く変化をしたような感じ。そこにピートを加えたもの、より強くピートを加えたものと続いていくが、ベンチマークモデルを試した後だと完全に舌で味が分解されて面白い。

ピートが非常に強く効いている。しかし飲みくちは水割りのように滑らかなので、案外苦手な人にも勧められるかもしれない。自分はいつもウィスキーを飲んだことがない人、苦手だけど挑戦したい人にはグレンフィディックを勧めるのだけど、その次の一杯として良いのかも。

本当はもっと色々と飲んだのだけど、ちゃんとレポートを残してあるのはこれだけだった。

会場となった秩父神社。境内の外では出店が出ていて祭りを盛り上げている感じ。もつ煮込みがうまかった。

帰る

ベロンベロンに酔っ払ったので秩父で一泊。本当は翌日は車でも借りて観光をしようと思っていたのだけれど、宿が寒すぎて風邪を引いたのでおとなしく帰って寝ました。

レッドアロークラシックに乗れたのでラッキー。