渋谷で毎月開催される初心者向け落語会、渋谷落語を観てきました。

「渋谷らくご」3日目
7/14(日) 14:00-16:00

柳家わさび-垂乳根
台所おさん-愛宕山
風藤松原-漫才
林家正蔵-ねずみ

来場者 98名#シブラク

— 渋谷らくご (@shiburaku) July 14, 2019

5日間で10公演開かれるのですが、今回は上のツイートで紹介されている5公演目を観てきました。
まともに落語を観るのは初めてだったのですが、演者さんを紹介するペーパーも配られており、初心者へのハードルを下げている感じがしました。
4組とも面白かったのですが、柳家わさびさんに垂乳根が特に気に入りました。寿限無のような感じでしょうか。
柳家わさびさんの別の演目や、他の演者さんの垂乳根も観てみたいです。

落語は声色だけでキャラクターを使い分けて場面を想像させるのですが、同じ話を聴いても観客ごとに異なる世界を想像するのは読書に近い体験でしょうか。

8月の落語会では創作落語のネタを初披露する会が予定されているようです。創作落語では現代を舞台にした話もあるようなので観に行こうかと思っています。

はじめに

ここ数年、朝食メニューが固定化されてきたので、価格や栄養素を数値化してみます。

メニュー

毎日の朝食は以下の通りです。

• シェイク(COMP POWDER+プロテイン+豆乳)
• スムージー(ほうれん草+バナナ+ブルーベリー+豆乳)
• コーヒー

液体ばかりですね。

COMP POWDERは株式会社コンプが出している完全栄養食です。
http://www.comp.jp/products/powder.html

プロテインはゴールドスタンダードシリーズを飲んでいます。ダブルリッチチョコレート味が美味。 https://www.optimumnutrition.jp/goldstandard.html

豆乳はマルサンの調製豆乳です。
https://www.marusanai.co.jp/lineup/detail-63005/

メニュー詳細

シェイクで使われる材料の詳細です。

スムージーで使われる材料の詳細です。

コーヒーです。

合計697円…家で食べる朝食としては少し高いですかね。

今回は算数と理科のお話です。

たとえば、文字盤の半径が1cmのアナログ腕時計があるとします。

この場合、文字盤の円周は約6.28cmとなるので、秒針の先端は1分間で約6.28cm進みます。 (実際は文字盤の内側を秒針が通るので、秒針が進む距離は少し短くなりますが、面倒なのでここでは文字盤の端を秒針が通るということで話を進めます。)

半径15cmの柱時計の場合は、文字盤の円周は約94.2cmとなるので、秒針の先端は1分間で約94.2cm進むことになります。

時計の文字盤が大きいほど、円周も大きくなるので、秒針の先端のスピードも上昇します。
つまり…大きなアナログ時計を作れば、秒針が音速や光速を超えるのでは…🤔ということです。

See the Pen 秒針 by foresukecom (@foresukecom) on CodePen.

スカイツリー(634m)を秒針にした場合、秒針の先端は時速約95km(秒速66m)で進みます。

逆に、音速(秒速340m)を超えるのに必要な秒針の長さは約3.25km、光速(秒速300,000km)を超えるのに必要な秒針の長さは約2,866,242kmとなります。
太陽の半径が約700,000kmなので、光速を超えるための秒針を用意するのは大変そうです。

実際には特殊相対性理論によると「物質は光速に近づくにつれて質量が増える」ので、どれだけ大きな時計を作っても秒針が光速を超えることはできません。
でも半径が約3.25kmの時計なら国を挙げて頑張れば可能なのでは…と、ちょっと期待してしまいます。

蛇足

最近、factorioというゲームにハマってます。
ある惑星に不時着したプレイヤーが、鉄鉱石や銅鉱石、石炭、木などの資源を使って再び宇宙を目指す、というゲームです。 このゲームは採掘、運搬、加工を自動化し、効率的な工場を組み上げるのが楽しさの１つとなっています。

このゲームは止め時が難しく、もう少しもう少しとラインを改良していく内に、どんどん時間が溶けていきます。 週末にゲームを立ち上げたら10時間が経っていた、ということも珍しくありません。

はじめに

Golangを書いてて詰まったことがあったのでメモです。

本文

こんな感じでカテゴリ、商品名、価格を持った構造体のスライスがあるとします。

type product struct {
	category string
	name     string
	price    uint64
}
showcase := []product{
	{"果物", "りんご", 120},
	{"果物", "バナナ", 100},
	{"果物", "みかん", 70},
	{"肉", "鶏もも", 250},
	{"肉", "豚バラ", 300},
	{"肉", "カルビ", 450},
}

で、このスライスから果物の価格だけ10円引きします。

for _, v := range showcase {
	if v.category == "果物" {
	    v.price -= 10
	}
}

こんな感じで書いたのですが、上のfor文だとshowcaseの中身は変更されません。
変数のスコープを考えてなかったのが原因です。 変数vはfor文の中でしか使えないので、いくらvの中身を変更してもshowcaseの中身は変わりません。

for i := 0; i < len(showcase); i++ {
	if showcase[i].category == "果物" {
		showcase[i].price -= 10
	}
}

上のように要素を指定して直接変更すればshowcaseの中身を変更することができます。

はじめに

ChromeBookにUbuntu入れようとしたら、キーボードとトラックパッドが反応しなくなりました。
＼(^o^)／

[ChromebookのFile Systemへの書込み制限を解除する方法 ― Write-Protect-Screwの外し方 C300MA編] (https://chromesoku.com/rw-filesystem-on-chromebook/)

詳しくはリンク先の記事に書いてありますが、ChromebookはWrite-Protect-Screwというネジで物理的にファイルシステムへの書き込みを制限しているようです。

僕が持っている端末とはモデルが違うのですが、似たような仕組みだろうということで精密ドライバを使って分解してみました。
Write-Protect-Screwらしいネジが見当たらないので、改めて組み直したのですが、キーボードとトラックパッドが反応しなくなってしまいました。
やってしまった…

さようならChromeBook。今まで楽しかったよ。

はじめに

お仕事でGolangのテストコードを書くことになったのでお勉強しました。
テスト対象は以下のプログラムです。

毎朝のルーティンを明文化し、以下の処理をしています。

• 降水確率40%以上なら傘を装備する。
• 冬、もしくは最低気温が5度以下ならコートを装備する。

以下の通り、4つの命令と2つの条件分岐で構成されています。

テストの種類

カバレッジとはテストの網羅率のことを指しています。
「どのパターンのテストを行えば、必要な範囲のテストが完了したのか?」の指標となります。
「必要な範囲」については、C0カバレッジ、C1カバレッジ、C2カバレッジ…とカバレッジの種類によって異なります。

それぞのカバレッジについて簡単に説明していきます。
※C3以降もありますが、よく使われるのはC2までみたいなので、今回は省略します。

C0カバレッジ(命令網羅)

すべての命令を最低1回は実行する、というテストケースを満たせばカバレッジが100%になります。
以下のパターンを実行すれば、すべての命令を実行することができるので、C0カバレッジ100%になります。
「降水確率が50%、季節は冬、最低気温12度。」

C1カバレッジ(分岐網羅)

すべて条件分岐の組み合わせを通る、というテストケースを満たせばカバレッジが100%になります。
今回はTrue/Falseの分岐が2つあるので4パターンの組み合わせでテストを行う必要があります。

具体的には以下のパラメータでテストをやればOKです。

C2カバレッジ(条件網羅率)

すべての条件の組み合わせを通る、というテストケースを満たせばカバレッジが100%になります。
C1カバレッジと似ていますが、C1カバレッジは条件分岐の結果をすべて通ればOKですが、C2カバレッジではすべての条件の結果を通る必要があります。
今回のケースだと、「冬か?」と「最低気温が5度以下か?」という2つの条件のそれぞれに対してTrue/Falseの組み合わせを試す必要があります。

そのため、④の条件分岐を2つに分割し、以下のパターンのテストが必要になります。

具体的には以下のパラメータでテストをやればOKです。

12月いっぱいで今の会社を退職します。
次の職場でもがんばるぞい！

コーヒーサーバを手に入れました。
ありがとうサンタさん、来月はクレカ支払い頑張るよ。

マグカップが汚い…黒色のマグカップを使えば汚れが目立たなくていいのでは🤔

ステンレスフィルタを使うのは初めてなのですが粉が残りますね。フィルタを洗うのも手間なので、普段はペーパーフィルタを重ねて使った方が手軽そうです。

電気ケトルから直接お湯を注いでいるのですが、注ぎ口が広いのでまともに「の」の字を書いてドリップすることができませんでした。 注ぎ口が細くなっている電気ケトルかヤカンが欲しくなります。

どうせなら、自宅でコーヒー豆を挽いたり、焙煎したり…沼が広がります。

Pocketから以下のメールが届きました。

2016年、2017年には上位5%になったことを祝福するメールが届きましたが、ついに2018年は上位1%のユーザになれたようです。

I'm in the top 1% of readers on @Pocket for 2018! Here's how much I read this year: https://t.co/CvC454chzZ #MyYearInPocket

— foresuke (@foresukecom) 2018年12月23日

自分が登録した記事の中から人気がある記事をピックアップしてみるとQiitaの記事が多いみたいです。
やはりQiitaはSEOに力を入れているのか閲覧者が多いようですね。

ちなみに、2018年12月21日時点では全記事数が9,720ページ、未読記事が2,289ページ、既読率76.5%という状況です。 2017年2月4日時点では全記事数が4,887ページ、未読記事が800ページ、既読率83.6%でしたので積読が捗っているようです。

毎日、未読率を出したり、未読記事からランダムでSlackに投稿するようにしましたが、まだ手緩いようです。todoリストと連携して毎日記事を読むように仕向けましょうか…

しかし…プレミアム会員にもなっていない自分が上位1%のユーザになれてしまうとは…
若者のPocket離れが深刻ですね。 Pocketなら気になる記事を後から読み返すことも簡単に出来るし(実際は読み返さないけど)、PocketのArticle Viewなら邪魔くさい広告が表示されないから集中して記事が読めて便利ですよ!
みんな使いましょう!!

はじめに

Golangというと、クロスコンパイルが特徴の1つとして挙げられます。
クロスコンパイルにより、Macで書いたコードからLinuxやWindows向けの実行ファイルを簡単に生成することができます。そのため、業務で使う便利ツールを作ってチーム内に配る、といったことも容易に行えます。
今回は僕がGolangを書き始めたばかりのころ、他の環境で動かすツールを作ったときに驚いた思い出ばなしです。

サンプルコード

実際のコードとは違いますが、当時は以下のようにエラーが発生したらpanic()で処理を中断させるコードを書いていました。

で、このコードを以下のようなディレクトリ構成の中に配置していました。log_analysisが1つのプロジェクトというイメージです。

tmp
└── tanaka
    └── azunyan_prpr
        └── tools
            └── log_analysis
                └── main.go

このコードをmitchellh/goxを使ってクロスコンパイルすると、以下のように各プラットフォームに対応した実行ファイルが生成されます。

$ gox
Number of parallel builds: 3

-->   freebsd/amd64: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->      netbsd/arm: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->       linux/386: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->      darwin/386: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->   windows/amd64: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->     openbsd/386: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->   openbsd/amd64: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->     windows/386: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->      netbsd/386: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->     freebsd/arm: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->    darwin/amd64: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->       linux/arm: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->     linux/amd64: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->     freebsd/386: _/tmp/tanaka/azunyan_prpr/tools/log_analysis
-->    netbsd/amd64: _/tmp/tanaka/azunyan_prpr/tools/log_analysis

$ ls -1
log_analysis_darwin_386
log_analysis_darwin_amd64
log_analysis_freebsd_386
log_analysis_freebsd_amd64
log_analysis_freebsd_arm
log_analysis_linux_386
log_analysis_linux_amd64
log_analysis_linux_arm
log_analysis_netbsd_386
log_analysis_netbsd_amd64
log_analysis_netbsd_arm
log_analysis_openbsd_386
log_analysis_openbsd_amd64
log_analysis_windows_386.exe
log_analysis_windows_amd64.exe
main.go

log_analysis_windows_amd64.exeがWindows(64bit)向けの実行ファイルになるので、Windows10のD:\tools配下に置いておきます。
log_analysis_windows_amd64.exeを実行すると、読み込むべきsample.logが存在しないのでpanic("ファイルないよ")が実行されます。