@numa08 猫耳帽子の女の子

明日目が覚めたら俺達の業界が夢のような世界になっているとイイナ。

DIYでカウンターを作った

前の家に住んでいたときからカウンターというものに憧れを持っていた。キッチンで料理をしたものを一時的に置く場所として、サクッとスタンディングでご飯を食べる場所として、酒でも飲む場所として。

前の家では結局カウンターを作ることはなかった。かわりに昔使っていた本棚をカウンター代わりで運用していた。

引っ越ししてからはちゃんとやるぞって思いを高めるために工夫をしながら作っていった。

モチベーションを強制的に上げる

やろうやろうと思っても結局やらないことは世の中にたくさんある。その解決策の1つとしてものを買ってしまいやらざるを得ない状態を作る方法があると思う。今回はその方法をチョイスして引っ越し直後の片付けも終わってない状態で木材を購入した。

今回はマルトクショップで2x4材を購入した。

shop.woodworks-marutoku.com

後、壁に2x4を立てるためのお約束のディアウォールも。

木材は2本でカット、送料込みの3,600円。ちょっと高い。後から気がついたけどホームセンターで購入して送ってもらったほうが安かったようだ。とは言え今回の目的はモチベーションを強制的に上げることだったので仕方がないとも言える。

天板を探す

ちょうどいい天板を探してインターネットの巡回をしたけど結局一駅隣にあるホームセンターで買うのが良かった。2千円くらいのパイン材をカットしてもらった。あと見た目を調整するためにブライワックスも。

本当は適当に使ったらメルカリか何かで使いさしを売っちゃおうと思ってたけど、水場のためのワックスなのでメンテナンスのためにとっておくことにした。ブライワックス自体に撥水機能は無いしニスを塗ると混ざるそうなので水で濡れて禿げたところにパッチのごとくワックスを当てていくんだと思う。

足場を探す

壁側の反対側の足場には適当なカラーボックスを利用しようかと思っていたけど、粗大ごみかメルカリアッテ送りを考えていたPCデスクがあったので再利用した。高さが低く感じたので床材を使って高さを増している。

床材とデスクの間には耐震用のグニグニのやつを入れてるのでちょっとやそっとじゃ壊れないはず。

完成

ある日一気にブライワックスを塗り組み立てをやって完成した。とりあえずmac book airGoogle Homeを並べておけばオシャレ感が出る気がする。

コーヒー関連の器具も並べることができて収納にも役立っていて嬉しい。

タブレットtorneアプリを入れておくとテレビも見れるので朝ごはんを食べるときに便利。

あこがれのカウンターをDIYで作ってみた。木材が思いの外硬かったりネジ止め強度が出なかったりして大変だったけど持ってた端材とかでなんとかなって助かった。とりあえず捨てるときのことは考えていないけど、長く住むのならこれでいいんじゃないかなって感じ。

ホームシアター的な空間を作ってみた

ミニスーファミが来たのでスト2をやるさま。

前回の記事で引っ越しをしたらホームシアターを作りたいなーとか書いた。

numa08.hateblo.jp

あと、ホームシアター的なものを作ろうかなって思いがある。

Amazonで買えるものを使って作ってみましたよ。あんまり高級なものは利用していないつもり。今のところニトリで注文をしたカーテンがまだ届いていないので昼間はあんまり使えないけど。

Amazon で買ったもの

まずはプロジェクター。

中華製のやつ。Amazonで見てみると同じ商品だけど値段や発売元が違うものがあるような。最近のアクションカメラ事情と同じで同じラインの製品の余剰パーツとかを組み合わせているのかなと予想。値段は2万円を切る格安プロジェクターだけれど、3000ルーメンの明るさで昼間の部屋でも使えないことはない。台形補正やピント調節はアナログな仕組みで自動での調節はない。とは言え、一度場所を決めたら固定するものだし問題ないかなと思ってる。

ファンの音が若干気になると言えば気になるけど収録して実況でもしない限りは問題ないと思う。

次はスクリーン。

ただの白い布に縁をつけただけやろって感じの商品。とりあえず写すことができればいい。四方と長辺の中央に穴が空いていてフックを掛けることができるようになっているので我が家では上からフックで吊るし下は文鎮をぶら下げている。ぐちゃぐちゃにするとすぐにシワになりそうだしアイロンをかけるにも大きすぎるのでメンテナンス性は皆無と言って良いかも。そのあたりが気になるようになってきたらちゃんとしたスクリーンの導入を検討したい。

そして分配器。

HDMIが5系統1出力、光デジタルへの音声分離もできる。5系統あるけど

で埋まってる。これ以上なんか増えた場合には同じ分配器をもう一個買ってネストしたハブにするかプロジェクターのもう一つの入力系統に刺すかを考えたい。

プロジェクターを配置するのに良い感じの台とかは存在しなかったので天吊り金具を導入した。

あと、買ったものじゃないけどサウンド。

ONKYO GX-D90 アンプ内蔵スピーカー WAVIO/ハイレゾ対応 木目 GX-D90(Y) 【国内正規品】

ONKYO GX-D90 アンプ内蔵スピーカー WAVIO/ハイレゾ対応 木目 GX-D90(Y) 【国内正規品】

4年くらい前にPC用に購入したやつを流用している。サブウーファーを配置して2.1chにするかサウンドバーを導入するアップグレードを検討はしているけど当面これでいいかな。

配置のために用意したもの

ホームセンターで色々と仕入れた。

水道工事コーナーにあった金属のプレートに穴が空いたやつとパイプに引っ掛けるやつ。家には出窓部分があるのでそこに踏ん張り棒を装着。踏ん張り棒にパイプに引っ掛けるやつをつけてそこから金属のプレートを中継しプロジェクターを天吊り金具を使ってぶら下げている。

配置した状態はこんな感じ。

やってみて

でかい画面でイカをやるのは面白いし、映画を見るのも映画館的な雰囲気があって良い。

ただプロジェクターの設定かも知れないが発色が若干おかしい気もしている。でかい画面の前には些細な問題とも思える性格だけど気にする人にはよろしくない。

プロジェクターと固定器具だけで2万円未満、分配器もつけると3万円から4万円くらいでホームシアター的環境を作ることができた。サウンドシステムの増強を最低限でもやれば6万円程度くらいか。普通のプロジェクター1台未満の値段で環境を作ることができそうだ。

当面の課題は、部屋を暗くするソリューションが無いこと。カーテンの到着が待たれる。

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

さらば東京。

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とかでコード書いたりできそうだなって思いましたまる。

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

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

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

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) -> {}

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

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

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

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

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

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

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

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

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

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

放課後のプレアデス - Wikipedia

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

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

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

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

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

そして明日の世界よりー

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

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

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

HARD THINGS

HARD THINGS

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

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

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

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

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

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

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