something tech.

梅仕事2026

Sat, 06 Jun 2026 23:00:00 +0900

気を抜いて生活していたら、梅仕事が今年初めての記事になってしまいました。去年、スーパーで全然梅を見ないと書いたんですけど、今年もなかなか売っているのを見つけるのに時間がかかりました。去年は結局ふるさと納税で梅を入手したので去年の相場は結局分からないんですが、今年は500g1000円くらい、ロピア(何を買っても割と安い)で1kg1599円(税別)でした。高いですね。天候不順などが理由で3年連続梅が不作だそうです。

今年の梅はサイズの表記がない南高梅ですが、L~2Lくらいのサイズはありそうです。多少の傷はありましたが、今年は梅酒だけで梅シロップを作らないことにしたので、多少の傷は問題無かろう、ということで1つもハネずに使用しました。

今年は梅も普通の南高梅、割けも果実酒用のホワイトリカーとしましたが、砂糖はすずらん印のてんさいグラニュー糖としました。昨年パッケージデザインが新しくなった、と聞いたのを思い出して、オッ、となったので。

なんやかんやグラニュー糖、というか粉末状の砂糖を使って梅酒を仕込むのは初めてかもしれません。過去使用した梅酒用の砂糖でもっとも細かったのは中ザラ糖で、粉末・・・というには結晶が大きいですね。梅酒の仕込みではゆっくり溶けて濃度に変化が発生する氷砂糖が良い、とされていますが、どんなもんでしょうか。

結晶の大きい砂糖に比べて密度が高いので、酒を入れた後でも浸透には少し時間がかかりましたし、ポコポコと気泡が上がっていました。

扨、昨年の梅酒の味見です。昨年は紫宝梅というちょっと変わった梅の実を使用しました。

梅シロップはかなりきれいなピンク色でしたが、梅酒は1年も経つと退色してしまっていて、ピンクというよりは琥珀色、という感じでしょうか。年数の経った梅酒ともちょっと違うような、クリアだけど色づいている、そんなようなきれいな色です。

味・・・というか、香りがすごく良いですね。砂糖も酒もごくごく普通の、ホワイトリカーと氷砂糖でしたので、雑味のようなものはなくて、梅の香りがダイレクトに出ている感じがします。梅の酸味、みたいなものも若干感じるような、甘めの梅干しをお酒にしたような、スッキリとした良い感じです。

年々気温が高くなっているからか、今年の南高梅は少し完熟気味だったので、今年の梅酒も香りが楽しみです。

ではまた来年。

2025年買って良かったもの

Sun, 28 Dec 2025 20:00:00 +0900

今年は主に園芸と料理の年でした。また、2024年9月末から札幌で一人暮らしを始めたので、自分で選んだ日用品が増えた年でもありました。 2024年に買って良かったものブログを書かなかったので、2024年に買って、今でも買って良かったな、と感じているものも入れておきます。

園芸

道具・資材

KINGJIM テプラハーフカッター
- ハーフカット機能がついていない機種を使っているテプラユーザは全員買った方がいい。剥離紙を剥がすときのストレスがないのはもちろんのこと、きれいに剥がれることで、貼った後に剥がれにくくなる。
Kaiju Plant 園芸シート
- 室内で植え替えをするには必須と言っても良い。
ベラボン・プレミアム
竹炭畑
- 用土は主に、ベラボン・プレミアムと竹炭畑、軽石、ゼオライトを混ぜたものを使っている。ベラボン・プレミアムが高いのと、竹炭畑がその辺ではあまり売っていないのが難。

植物

斑入りバオバブ

初めて買った高級めな植物で、今でも我が家の中で最も高級な植物。のはず。シマムラ園芸で購入。昨年の冬は見るも無惨なほどに落葉してしまったけど、夏ごろ、また葉が吹いてくれた。

いまはまた冬なのでちょいちょい落葉している。多分年末年始に函館に帰省したタイミングで、室温がグッと下がる見込みなので、がっつり落葉すると思われる。

アングレカムディスティカム

洋ランの一種。葉っぱを見てるだけでも可愛いし、気が向いたら花も咲かせてくれる。サンシャインシティ世界のらん展2025で、ナーセリーイデさんから購入。

ドリナリアリギデュラ

着生シダの一種らしい。枯れ葉のような部分と、細長い茎的な部分の2パートがあり、ちょっとかわってる。板付だと乾かしすぎてアレだったので、今は鉢に植えた状態でつるしている。サンシャインシティ世界のらん展2025で、Tropical Exotiqueさんから購入。

これでドリナリアが好きになり、他の品種も買ってしまいました。

アスパラガスプルモーサスナナス

購入時はおつとめ品で、50円とかだった。カインズで購入。

カンパニュラダークゲットミー

めっちゃ咲いてくれて、満足度が高かった。ジョイフルエーケーで購入。枯れずに元気なので、またたくさん咲いてくれることに期待している。

ネメシアグッピー

こちらもめっちゃ咲いてくれて満足度が高かった。香りも良い。ジョイフルエーケーで購入し、こちらもまたたくさん咲いてほしい。

カーネーションピンクアンドプラウド

カーネーション、と言いつつ花は小さめ。花の色がかわっていて、濃いピンクと薄いピンクが入り交じった花を咲かせる。割と最近の品種っぽい。百合が原公園ガーデンショップで購入した。

サニーレタス(のタネ)

2024年末くらいからサニーレタスを実生で育てた。多分ジョイフルエーケーで購入。室内にサニーレタス栽培エリアがあると、葉物野菜をいつでも摂取できるという点がものすごく良い。もちろんスーパーとかでサニーレタスを買ってくることもできるけど、近年は野菜が高いし、何より葉物野菜は日持ちしないので。。。

全盛期は、取っても取っても食べきれないくらいだった。

モンステラデリシオーサ ‘タウエリー’(のタネ)

串鳥

Tue, 02 Dec 2025 00:00:00 +0900

本記事は吉祥寺.pmについての25個の小さな話、またはMagnolia.Kの雑記 Advent Calendar 2025 2日目の記事です。昨日はKaitouさんの大吉祥寺.pmのPCが入るサコッシュを勝手に作ったお知らせ #kichijojipm でした。吉祥寺.pm、ロゴが可愛いのでサコッシュになっても映えますね。ちょっとほしいけどPCをサコッシュに入れて持って歩くことはなさそう・・・

扨、実は吉祥寺.pmは昨年の大吉祥寺.pmに行っただけで、通常の吉祥寺.pmに行ったことも無く、吉祥寺自体も大吉祥寺.pm以外に1回行ったことがあるかないか、というレベルなのですが、吉祥寺.pm公式のX Post によれば、吉祥寺の美味しいもの情報でも可、ということなので、吉祥寺の美味しいものとして串鳥をご紹介いたします。

なんかアドベントカレンダー熱が再燃したので、初めての吉祥寺.pmアドベントカレンダーを作りました

吉祥寺の美味しいもの情報でも可ですhttps://t.co/jVZZWhByxx #kichijojipm
— 吉祥寺.pm (@kichijojipm) November 10, 2025

串鳥

串鳥は北海道札幌市に本社を置き、本日時点で北海道に31店舗、仙台に5店舗、そして吉祥寺に店舗のある焼き鳥チェーン店です。なお、筆者は現在北海道札幌市在住で、前述の通り吉祥寺にはほとんど行ったことがないため、串鳥吉祥寺南口店にも行ったことがありません。本記事中の写真は串鳥東区役所前店で撮影しました。

まさか誰も、吉祥寺.pmのアドベントカレンダーの2日目にして札幌の焼き鳥屋の話を書くとは思わなかろう。

噂によれば、吉祥寺南口店は駅から武蔵野公会堂方面に出た時、駅前すぐにあるようです。

以下、串鳥で食べたものの写真を掲載します:

串鳥といえば鶏ガラスープ。これはサービスで出てくるもので、ポットで出てくるので好きなだけ飲めます。写真を撮るのを忘れたのですが、お通しとしてこれとともに大根おろしが出てきます。

噂によると吉祥寺南口店では大根おろしが出てこないという話もあるので、一度確認しに行きたいところです。

ひな皮、手羽先、つくね(梅しそ)。これは東区役所前店特有のやつだとおもうんですが、「店長のおまかせセット」なるものがあり、この日はそれが少し安いです、ということだったので頼みました。もちベーコン、串鳥以外で見たことない気がする。

岩下の新生姜豚巻き、焼きカチョカヴァロ。チーズが焼かれてるとなんか食べたくなりますよね。

ぽんぽち、豚味噌海苔巻き、豚しそ巻き。豚を巻いた、豚味噌海苔巻きと豚しそ巻きも串鳥といえば、のメニューの一つですね。

鳥ももハニーマスタード、チキン南蛮。チキン南蛮はなんかフェアメニュー的なやつでした。

コラボグッズ

最近、串鳥と島村楽器のコラボアイテムが発売されまして、地元企業とのコラボグッズは嬉しいな〜など思いながら買いました:

改めて島村楽器のお知らせ一覧を眺めていると、ここ最近で九州乳業やら矢場とんやらとのコラボもやっているらしく、各地元企業がフィーチャーされるというのは良いことだな、と思います。

締めの一句

しってるか
吉祥寺にも
串鳥が

Tech Rock Festival 2025.11.22

Wed, 26 Nov 2025 21:57:45 +0900

2025年11月22日に新宿SUNFACEで開催されたITエンジニアによるITエンジニアのためのライブイベントTech Rock Festival Day3に参加してきました。ハッシュタグは#TechRockFestival でした。そういえば、昨冬に配信ライブやったんですが、それのブログ書いてなかった・・・

イベント自体の開催経緯は2023年のレポートを参照のこと。

毎年出演希望者が増えており、今年はなんと3回の開催となりました。例年同様開催地は新宿である一方、現在私は札幌在住で、ギターやエフェクターを持って移動するのがなかなか大変なため、今回はギターではなくボーカルでの参加としました。

機材

今回は初めてのボーカル・・・ということで、あまりむやみやたらに機材投入ができなかったのですが、それでも唯一どうしても使ってみたかったのがワイヤレスインイヤーモニターです。以前ボーカルに少しだけ挑戦したときはボーカル慣れしていないというのもあり、自分の声を見失ってしまって全然音が取れなかったため、イヤホンで確実に自分の声をモニターしたい！と思ったのでした。プロが大規模な会場で使うような大型のものから、近年では小型・安価なものも複数販売されていますが、その中でも今回はXvive XV-U4 を購入し、使用しました。

価格もそれなりに手頃(購入時点で34,100円)で、余分なケーブル等が必要無く、本番でも単に挿して音を流してもらえば良い、ということで選択しました。モニタリングイヤホンはまぁ何でもいいかな、と思ったので、ある程度信頼できそうなメーカーのモニタリングイヤホンの中で価格が手頃だったSennheiser IE100 PRO を選びました。

結果としては大満足で、PAさんには「ワイヤレスイヤモニを使いたい」ということを伝えていただけであとは当日合わせだったのですが、何の問題も無く使用することができました。唯一の欠点はUSB micro-B充電である、という点ですね・・・

バンドと演目

今回のバンドは、バトルプログラマーヨシセという名前で、アニソンやらボカロやらをやるバンド、ということで結成しました。なんなのだこの名前は・・・今回もキーボードあり編成で豪華でしたが、なんやかんやどのバンドにもキーボードがいる感じになっていてすごいな、と感じましたね・・・

面子:

nasa9084 (Vo)
takasp (Gt)
capytan (Ba)
Hano (Key)
うつぼ (Dr)

曲目:

テレキャスタービーボーイ
アンノウンマザーグース
月光花
怪獣
ヒトリノ夜

次

打ち上げでも話をしたんですが、次はなんかこう、訳の分からん楽器で組んだ訳の分からんバンドをやりたいんですよね・・・あと、打ち上げで、誰も知らないギターリフを弾いたらドボン、という闇のゲームに参加したんですが、全然指が動かなかったので、そろそろちゃんとギターも練習しないと何も弾けなくなるな、と思いました。

YAPC::Fukuoka 2025

Tue, 25 Nov 2025 23:42:00 +0900

2025年11月14日〜15日に福岡工業大学で開催された、YAPC::Fukuoka 2025 に参加してきました。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。Xハッシュタグは前回に引き続き#yapcjapan でした。

前回の函館から約1年ぶり、福岡での開催は2017年以来2度目で、YAPC::Japanとしては初めての2日間開催となりました。

今回は2日間フルでの開催ということで、前日木曜日に博多入り、金曜、土曜とYAPCに参加して、日曜日に帰るというスケジュールで臨みました。

前日

普段の業務で実は福岡にいるメンバーとの関わりがあるのですが、現職に入社してこの方福岡に出張の用事が無かったため、福岡のメンバーと会う機会が無かったので、昼ご飯を一緒に食べました。

なんやかんや都合が合わなかったりして、全員と会うことはできなかったのですが、かれこれ数年オンラインでやりとりをしていた人と「初めまして〜」するのはなかなか感慨深いものがありますね。

その後、カーシェアを借りて、FUKUOKA EFFECT に行きました。札幌はもう既に園芸店は冬期休業・時短営業に入っているため、普通に園芸店が営業していて、商品もしっかり並んでいる、というのはやはり暖地だな、というのを感じました。

アガベ、多肉、庭用の苗、プランター類が多い印象でした。札幌はプランター類が多い販売店は今のところ見つけられてないんですよね・・・

エケベリアカンテ、白丁花、ヒサカキ「残雪」を購入しました。白丁花もヒサカキも観葉植物・・・とはちょっと違うと思いますが、斑入りで観葉っぽいし、シェードガーデン用にも良い、ということなので室内でも育つでしょう。多分。

夜ご飯は牧のうどんで肉うどんを食べました。

Day 1

扨、YAPC::Fukuoka 2025一日目ですが、朝からパンストック天神店に明太フランスを買いに行ったら遅刻しました・・・。パンストックが開店前から並ぶ店なのは知っていたんですが、平日なので多少マシかと踏んだんですが・・・結局1時間並びました。途中でYAPCのオープニングに間に合わないことは分かってたんですが、後に引くことはできませんでした。

パンストックのパン、何を買っても美味いので福岡に行く機会があれば是非。

その後パンをもぐもぐしつつ会場へ。最寄りの福工大前駅から、あちこちに現在地と受付までの地図を置いておいてくれたので、迷わずにたどり着くことができました。

一日目は以下のセッションを聴きました:

近年はだらだらと廊下で知り合いと話していることが多くてあまりセッションを聴くということをやっていなかったのですが、今回は結構話を聴きました。

今回懇親会はDay 2の夜ということだったので、何人か捕まえて飲みに行きました。

Day 2

二日目、もちろん遅刻しました。9時半は早いって。。。

二日目は以下のセッションを聴きました:

ゲストゲストトーク
やり方は一つだけじゃない、正解だけを目指さず寄り道やその先まで自分流に楽しむ趣味プログラミングの探求

二日を通して、すぎゃーんさんの趣味プログラミングの話が良かったですね。近年は何かとコードを書かないことがうれしいと言われがちですが、個人的には共感できなくて、コードを書くのが一番楽しくてこの仕事をしているのに、コードを書くところを持って行かれたら一番良いところがなくなっているだろう、と思っていたのですが、すぎゃーんさんの発表では「コードを書くのって楽しいよね！」を主張してくれて、なんだか救われたような気持ちになりました。

二日目は懇親会があり、いろいろなひとと話せました。良かった良かった。ビールを飲むカメラマンや、次回のYAPCのco-organizerやろうよ、等と声をかけたりかけられたりする[@karupanerura](https://x.com/karupanerura] sanと@magnoria_k sanを眺めたりもしました:

水の配達でゴタゴタした件

Thu, 06 Nov 2025 02:47:58 +0900

Context

4階建てマンションの4階に住んでいる
- 宅配ボックスはオートロックの外側にある
ローリングストックも兼ねて、ミネラルウォーターを購入し、煮炊きに使用している
- ミネラルウォーターの銘柄等に特別なこだわりは無い
自家用車を持っており、現実的な距離にコストコがある
- コストコで水を買ってくることは可能だし、Amazonで買うより安い
- が、車から部屋までの持ち運びが大変(特にオートロックの鍵を開けるところ))なので宅配で購入したい

Timeline

2025.10.28

Amazonでミネラルウォーター(550mL×24本×2箱)をセールで購入。このとき、置き配設定は「置き配を使用しない」に変更した。宅配ボックスに入れられてしまうと、取り出すだけでも大変。

既に一度同じ設定で宅配ボックスに入れられてしまったことがある。しかも2箱まとめて、ギリギリのサイズの宅配ボックスに。

そのときは水注文後、水到着前に追加の注文で置き配設定を宅配ボックスに変更してしまった。置き配設定が注文ごとではない可能性が高い(UI上から)ため、諦めて宅配ボックスと部屋を2往復した。

その間宅配ボックスは開けっぱなしで。

2025.10.30 20時前

Amazonから、宅配ボックスに配達した、とのメール通知がきた。ご丁寧に宅配ボックスの写真付きで。この日は昼ご飯に出た以外は外出をしていない==配達時は在宅していたのは間違いないし、インターホンは鳴っていない==在宅確認もせず宅配ボックスに配達していることも明らか。

メール通知の内容や、宅配ボックスの窓から覗く限り550mL×24本×2箱がまとめて一つの宅配ボックスに入っている。流石にまとめて運ぶのはしんどいし、そもそも外から部屋まで自分で運ぶならコストコで買った方が安いのでサポートに連絡を入れることにした。

サポートに連絡をしたところ、設定状況などから配送業者が独断で行ったものと断定、配送業者に荷物回収の上再配達するよう連絡してくれるとのこと。また、配送業者には置き配設定を必ず確認するよう指導を入れてくれる、とのこと。

サポート終了後に来たメールによると、配送業者には回収の上再配達をするよう依頼したので、対応に1~3日待てとのこと。ローリングストックの水だし、まだ流石に凍るほどの気温ではないので気にせず承知した。

2025.11.06

6日経ったが再配達がまだこないので再度サポートに連絡した。

対応確認で時間を取らせるよりも、一度返金するので再注文してもらった方が早いのではないか、との提案があり、確かにそっちの方が確実っぽい気がしたので了承することに。注文がセール中であったため、現在価格と差額が発生するが、その点はどうなるのか、と確認をしたところ、クーポン対応をする、との返答だった。これで懸念は無くなったためその条件で了承し、問い合わせ終了。

アカウントを確認したら差額分のギフトが登録されていたため再注文をした。

サポートの人に聞いても仕方ないことだろうからきかなかったけど、宅配ボックスに入っている水はちゃんと回収されるのだろうか・・・

#### 2025.11.12追記

後日談というか、今回のオチ。水は結局回収されず、管理会社に連絡をして宅配ボックスをあけてもらえ、という謎の指示。管理会社から費用を請求されたらそれもAmazonが支払う、とのこと。

中の商品はどうすればよいのか、と聞いたところ、それはそのまま納めてくれ、とのこと。

重いから注文している、とはいえ、運べない訳ではないので、回収をしてくれないのであれば管理会社に問い合わせて無闇な負担をかける意味も無く、今回は自分で運ぶことに。まぁ、Amazonとしては商品はそのままあげるからごちゃごちゃ言わないで今回はそれでおさめてほしい、ということなんだろうけれど・・・

配送業者にはちゃんと申し伝えておく、ということなので今回は2箱分がタダになったということで水に流すことにします。水だけに。

苗字が変わりました

Thu, 18 Sep 2025 01:30:00 +0900

社内を含めて、私のことを実名で呼ぶ人は片手で数えられる程度しかいないので、実際問題として影響はほぼないのですが、6月2日付けで苗字が変わりました。

なお、結婚ではありません

多分ほとんどの人がやったことがない/やることがない手続きなので、ネタとして記録しておきます。

経緯

というほど経緯は特にないのですが。

両親が離婚した
父方の親戚とは疎遠/あまり関わりたくない
母方の親戚とは仲が良い
結婚したとしても(一般に)男性側の姓に揃えることが多そうなので、自分の姓を変更する、という機会の発生率が低そう
- そもそも結婚の予定はない
結婚/離婚を伴わない改姓の手続きをやったことがある人は少なそう
- 多少調べたけど、あんまり個人のブログ記事とかでの情報は無い
- ブログネタとして面白そう
母方の氏の方が珍しい
- 珍しい名字の方が強い(?)
実生活で苗字で呼ばれることはほぼないので影響が少なそう面白半分でやってもまぁ大した問題はない

ということで改姓に至りました。

手続き

改姓の手続きは大きく分けて2ステップで、まず家庭裁判所の許可を得て、その後住んでいる場所の市区町村役場で手続きをする、という形です。

家庭裁判所からの許可は、子の氏の変更許可から書式をダウンロードして、記入して、収入印紙、返信用切手、戸籍謄本と併せて住所地の家庭裁判所(私の場合は札幌地方・家庭裁判所)に送るだけです。概ね悩まずに記入できるとは思いますが、「申し立ての動機」だけちょっと悩みました。が、結果としては大した理由は必要無くて、「父母の離婚に伴い、母の戸籍に入籍したいため」で十分でした。

氏の変更手続き、とは言うものの、氏は戸籍に紐付いたラベルの様なものであるため、氏を変更する==父の戸籍から抜けて、母の戸籍に入るor自分の戸籍を別途立てる、という形になるようでした。

一度自分の戸籍に分けてしまうと、母の戸籍に入ることはできないようで、私はどっちでも良いな、と思ったため、後で選択がきく、母の戸籍に入る、を選択しました。

家庭裁判所に送る戸籍謄本はは、自分の戸籍謄本と父母の戸籍謄本と記載がありますが、父の戸籍に入っている状態では、自分の戸籍謄本(全部事項証明書)に父の情報も入っているため、父に別途戸籍謄本を取ってもらう必要はありませんでした。

また、兄弟姉妹まとめて手続きをする場合、兄弟姉妹の情報も入っているため、複数戸籍謄本を取る必要はありませんでした。

つまり、まとめると、

子の氏の変更許可申立書 x 1
- 変更をしたい人数 x 800円の収入印紙を貼る
自分の戸籍謄本(全部事項証明書) x 1
母の戸籍謄本(全部事項証明書) x 1
返信用郵便切手変更をしたい人数 x 封筒の切手代

を封筒に入れて家庭裁判所に送れば良い、です。

問題が無ければ(私は妹の前科前歴がない、の記入漏れがあったため電話が来た)、2〜3日で許可するよ〜というお手紙が届きます。

そのお手紙を持って市区町村役場(私の場合は札幌市東区役所)の戸籍関連手続きをする窓口に行けばシュッと手続きしてくれます。そんなに回数こなす手続きでもなさそうなのに、スムーズに対応してくれました。

場合により戸籍情報の更新に少し時間がかかるらしく、1週間以上経ってからマイナンバーカードの上書きをしにきてね、ということだったので、翌週もう一度区役所に行きました。

その他変更の手続き

結婚した人がよく言っていることでもありますが、氏が変わると当然クレジットカードなどの名義変更も必要です。これが面倒だよ！ということだったのですが、マイナンバーパワーなのか、単に時代が良くなっているだけなのか、web/アプリで完結するものも多く、思ったよりは面倒では無いな、という印象でした。

一部住民票等を求められるものもありましたが、片手で数えることができる程度でしたし、住民票はコンビニで発行することもできるので、まとめて印刷して、封筒に入れて、まとめて送るという感じで、それほど手間ではありませんでした。

免許証の変更手続きも、警察署に行かなければならないのは若干面倒ではあるものの、窓口でほとんどの情報を印刷した書類を発行して、わずかな部分をちょちょいと記入して提出するだけでした。

便利な世の中になったものですね。

"怠惰な人のための"キッシュ

Tue, 19 Aug 2025 00:00:00 +0900

キッシュ、という料理をご存じでしょうか。惣菜や冷凍食品としても売っていることがありますし、スターバックスでもベーコンとほうれん草のキッシュが定番商品として売っているため、知っている人も多いかもしれません。

とはいえ日本人にはあまりなじみがなく、家でキッシュを焼く、という人はあまり多くはないような気がしますが、作ってみると意外と簡単です。

個人的には、料理が面倒な時こそキッシュ、という感じなので、雑に作れるレシピをご紹介します。作業時間だいたい5分くらい、作り始めてから焼き上がるまで大体40分くらいでできあがります。焼いている間はつきっきりである必要も無いので、混ぜて、流し込んで、焼くだけの簡単レシピです。

材料はこちら:

冷凍パイシート 1~2枚 (容器に敷けるくらい)
卵 3個
生クリーム 100mL
具材
塩
こしょう

塩、こしょう、卵はまぁ家にあるでしょうし、冷凍パイシートは保存がきくので、作る直前に特別買ってくる必要があるのは生クリームくらいでしょうか。

具材は適当な量を入れます。ベーコンやほうれん草など、それっぽいものがあればそれで良い感じになりますし、生のほうれん草ではなく冷凍のほうれん草をつかってもいいですし、スーパーによっては冷凍のベーコン入りほうれん草ミックスを売っている場合もあり、そういったものをそのまま使っても良いでしょう。わたしはキノコがダメなので入れませんが、キノコを入れてもよいでしょうし、ジャガイモやサーモン、ズッキーニ、ミニトマト、ベーコンの代わりにウインナーなどなど、案外雰囲気で適当なものを入れても美味しくなります。汁気がなければ大体大丈夫です。多分。

チーズがあれば雑にたくさん入れるとなお美味しいです。我が家は最近はモッツァレラチーズ、カマンベールチーズ、パルミジャーノレッジャーノ、ピザチーズ、あたりを常備しているのでこのあたりを適当に入れています。

今回は玉ねぎのみじん切りと挽肉を雑に炒めて、適当に味付けをして具材としました。

焼くときの型は、キッシュ型があればもちろんそれを使ってもいいのですが、油を塗ったり、型に合わせてパイシートを伸ばしたりする必要があり、多少手間がかかるかもしれません。私のオススメは取っ手が取れるフライパンです。私はティファールの22cmのフライパンを使っていますが、各社似たようなものを出しており、ニトリだと1,000円前後くらいで買えると思います。テフロン加工でパイ生地がくっつきませんし、取り出す際にも取っ手をつけて取り出せるので、取り回しがしやすく便利です。

世間で売られている冷凍のパイ生地は11cm x 18cmくらいの長方形タイプと、18cm x 18cmくらいの正方形タイプの２種類がありますが、フライパンを使う場合はどちらでも大丈夫です。長方形タイプの場合は2枚敷くとよさそうです。

冷凍パイシートは調理しはじめに冷凍庫から出しておきます。割とすぐ溶けるので、事前に出して解凍しておく必要はありません。

また、この時点でオーブンを180度に予熱しておきます。

型に合わせて伸ばしても良いのですが、私は面倒なので、フライパンに押し込める程度に溶けたらグッと押し込んでソレでよし、としています。サイズもなんか足りていない気もしますが、気にしません。

空焼きもした方がサクッと焼けて良い感じになるという噂もあるのですが、面倒なのでそれもしません。

何故か札幌では200mL以上の生クリームしか販売が見当たらなかったので計量をします。生クリームは多分100mL==100gでは無いと思うのですが、まぁ大差は無いだろう、ということではかりで量っています(洗い物が減るので)。 100mL売りの生クリームがあれば、割高ではありますがそちらが便利だとは思います。

卵を3つ入れます。こちらもサイズによって違いはあるとは思うのですが、面倒なのでサイズを気にせず3個、としています。特に困ったことはありません。

塩こしょうを適当に入れます。あればナツメグも入れると良い香りがします。塩こしょうは思っているよりも多く入れるとちょうど良いです。特に冷めてからも食べる場合は、気持ち多めに入れておきましょう。

塩分が気になる人は、こしょうを多めにすると、なんとなく良い感じになります。

具材を入れて混ぜます。私はあるものを適当に入れます。

ほうれん草なども、生なら生のまま、冷凍なら凍ったまま入れてしまいます。火が入るのに時間がかかったりしているのかもしれませんが、なんとかなります。ちゃんと火が通ってないとおなかを壊しそうなもの(挽肉とか)や、火を通さないと食感が邪魔になったりしそうなものは予め火を通しておきます。

ざっと混ぜ合わせたら、パイシートを敷いたフライパンに流し込みます。テフロン加工フライパンなので、パイシートからはみ出ても大丈夫です。味には変わりありません。見ての通り、パイ生地ものばしていないので、角がそのまま飛び出ています。

ピザチーズとかがあれば適当に乗せておくと良い感じです。

後は180度で20~30分くらい、卵液が固まるまで焼きます。私は大体、雑にオーブンの最大時間にセットして、別途キッチンタイマーで20分くらいはかります。上面が良い感じの焼き色になったら大体焼けているので、箸かなんかをさして、固まっているかどうか判別します。固まっていなかったら適当に5分くらいずつ追加で焼く、という感じで、焼いている間は本を読むなどしています。

KubeCon Japan 2025

Wed, 25 Jun 2025 20:00:00 +0900

2025年6月17日/18日に開催されたKubeCon + CloudNativeCon Japan 2025 に参加してきました。また、その前日16日にCo-located EventとしてJapan Community Day の一部としてDoc Sprintというイベントを実施しました。

KubeConはKubernetes のイベントで、Cloud Native Computing Foundation (CNCF)が主催しています。日本での開催は初めてということで、コミュニティからの期待も大きかったのですが、結果としては大盛況で、1500枚のチケットが完売だったということです。

Doc Sprint

本祭の前日に、Co-located eventという形で、会場の近く、NTT DOCOMO Open Lab in OdaibaでJapan Community Dayが開催されました。 Japan Community Dayでは、いくつかのセッションがあったほか、Kubernetes Upstream TrainingとDoc Sprintを開催しました。

Doc SprintはKubernetesのドキュメント(の、特に日本語翻訳)にコントリビュートしよう！というイベントで、私や、@junya__okabe がKubernetes SIG Docs日本語localizationチームapproverとして初めてのコントリビュートをサポートするという企画でした。

当日はめちゃ簡単good-first-issueを用意することに成功したのもあって、実際に4人のnew contributorが誕生しました。

景色も大変良く、大変良い会場でした。

KubeCon本祭

本祭は概ね廊下をうろうろして知り合いと話したり、ブースを冷やかしたりしていました。ヘイシャもプラチナスポンサーということで、なかなか大きなブースを出していました:

Job boardもあり、ペンが置いてあったので、コントリビューター募集のメッセージを書いておきました(“Job"ではないけど・・・):

あんまりたくさんのセッションは聴かなかったのですが、一番面白かったのは初日の最後のコマに発表のあった、2-Node Kubernetes というセッションでした。要するに、HA構成K8sが3ノード以上必要なのはetcdが3ノード必要だからで、etcdは3台あっても1台までしか落とせないので、ならば(leader electionさえなんとかすれば)耐故障性は3ノードと変わらないし、edgeでコストを落とすこともできてハッピーじゃん、という話でした。

2日目の昼には、Kubernetes Upstream Training Japanの一員として、発表をすることもできました。個人のプロポーザルは通らなかったんですけど、パネルディスカッションのプロポーザルが通って本当に良かった。

梅仕事2025

Thu, 12 Jun 2025 21:13:00 +0900

今年も梅の季節がやってきました。なんかスーパーで全然梅を見ないんですけど、いまどきの札幌の民は梅仕事はしないんですかね？今年はちょっと変わった梅の実を使いたいなぁ、ということで、ふるさと納税で紫宝梅『ミスなでしこ(R)』という、紫色の梅を手に入れました。きれいなピンク色のシロップができるということで、楽しみですね。

1kgで寄付金額8,000円、4kgで寄付金額20,000円ということで、どうせ2kgは使いますから、4kgの方を選びました。一応説明に寄れば大玉(M〜L)ということなんですが、結構小ぶり(M?)の実が多い様に感じました。まぁ例年スーパーで買う青梅はLLのものを買うため、余計にそう見えた、ということもあるかも知れませんが。

スーパーで買うような物と比べて、かなり傷物が少なく、結局不安があってハネた実は1つという好成績でした。

今回使う梅以外の材料はこちら。梅の方に変化を入れたので、色がきれいにでそうな氷砂糖、上白糖、ホワイトリカーです。梅酒を1瓶、梅シロップを2瓶作り、余った1kgは妹に分けてあげました。

瓶はPET製の果実酒瓶を選びました。昨年使ったモノとは違うんですけど、同じく角形で収納に便利そうです。

実の形がまん丸ではなくて、すこしとがったような形をしています。

作り方は例年通り、洗って、拭いて、ヘタを取って、砂糖と積み重ねて、梅酒の方には酒を入れる、というだけ。店頭にあった瓶の在庫の都合で2日に分けて作業しました:

例年、梅仕事をした後は以前に漬けた梅酒を味見しているので、今年も味見しておきます。

昨年の梅酒は何の影響か、すごくしぼんだ状態ですね。 1年くらいだと、多少しわが入っていることは多くて、その後また酒を吸って膨らんでくるんですが、ここまでしぼんでしまってもまた膨らんでくるんでしょうか？

ほんの少し水を足した、いわば水の梅酒割、くらいの割り方で割ってみました。 1年モノとは思えないくらい丸い感じで、コレはホワイトリカーが良かったのか、中ザラ糖が良かったのか、悩ましいところです。

そして1年越しに気づいたんですが、昨年のラベルが1年間違っていました。上からマッキーで訂正しておきました。

また来年。

チカの南蛮漬け

Tue, 04 Feb 2025 23:18:01 +0900

この季節一番美味い魚といえば、そう、チカですね。私はチカを見たら買わないではいられないという奇病にかかっているため、今シーズンは既に3〜4回購入しています。

チカはワカサギを少し大きくしたような小型の魚で、今時期は比較的大型のものが安価に販売されています。 Wikipedia によるとチカは20cmほどに育つ、ということですが、今回買ったチカはおおよそ全長13cm程度でした。

当然(?)チカは南蛮漬けにしていきます。

材料はこちら:

チカ、玉ねぎ、などです。今回は彩りに玉ねぎを入れました。パプリカは高いので、玉ねぎのみとすると経済的です。我が家では地獄の様な量の玉ねぎを入れます。今時期の札幌で販売されている玉ねぎは大変大きく、写真では玉ねぎ2.5個が映っていますが、実際のところ流石に多いな、と思ったので1つ減らしましたが、それでもかなりの量です。

また、漬け地として、

酢 1cup
砂糖大さじ6
醤油大さじ8
出汁 2cup
唐辛子小口切り適量を混ぜておきます。野菜の量を抑えれば半分でも良いです。また、私は出汁パックをつかって出汁を引きますが、面倒であれば出汁の素を湯で溶いたものを使用しても良いと思います。その場合、出汁の素は塩や砂糖が含まれている場合が多いと思いますので、適宜醤油や砂糖の量は調節してください。面倒であれば気にしなくても誤差だとは思います。

まずは野菜をスライスしていきます。以下は前回作ったときの玉ねぎスライス動画です:

この時は小ぶりな玉ねぎだったので、10個ほど投入した気がします。

野菜スライスのコツは、包丁を十分に研いでおく、という点にあると思います。前の日までに研いでおいてください。

次にチカの処理をします。流石にこのサイズになると以前やったように単に揚げてはい終わり、というわけにはいかず、うろこを取り、頭を取り、背から開いてワタと背骨を取ります。 Youtubeで調べると解説されている動画もあるので参考にすると良いと思います。やはりコツは包丁をよく研いでおくということです。

あとの手順は小さいチカやワカサギで南蛮漬けを作るのと同様です。

片栗粉をつけて揚げて:

漬け地に突っ込んで:

野菜も入れて:

適当な容器に入れて一晩冷蔵庫で寝かせます:

この量だと、一人だと2~3日はこれを食べ続けることになります。ご注意ください。

ベトナムに行ってきた

Sat, 21 Dec 2024 00:00:00 +0900

標題の通り、ベトナムに行ってきました。主目的は学生時代からの付き合いであるところの@chamaharun と@ne_saya の結婚式ですが、ベトナムまで行ってそれだけというのもアレなので、多少観光もしてきました。

0日目: 札幌→東京→ホーチミン

先日札幌に引っ越したため、結婚式会場のフーコック島までは、新千歳→羽田→ホーチミン→フーコックという経路でした。乗り継ぎの都合なども勘案して、21:15新千歳発、深夜に羽田発、早朝ホーチミン着という計画としたため、せっかくなのでホーチミンで一泊することとしました。新千歳をでるときはなんとなくおなかが空いていなかったので夕食抜いてしまおうか、と思ったのですが、なんだかんだ羽田で飛行機を待っていたらおなかが空いたので、お値段が手頃だったうどんを食べました:

国際線ではエコノミーでも酒が飲めるんだった、ということで、寝酒に梅酒をもらったのですが、十分にエアコンが効いてるし、と思ってストレートで頼んだら、結構多くて結局ちびちびやっていたら飲みきれませんでした:

機内食で朝食、パンケーキですって声も聞こえていた気がしたけど、手元に来たのはフレンチトースト:

1日目: ホーチミン

ホーチミンまではJAL便だったので、ギリギリまで日本語で楽ちんでした。

ホーチミンに早朝について、ホテルのチェックインもできないので、フロントの人に「どうしたら良いと思う？」と聞いたところ、すぐ横にカフェがあるから、いったん休憩して、その辺散歩してきたら良い感じにホテルからのシャトルバスがでるから、それで観光行ってきたら良いんじゃない？ということだったので、それに従うことにしました。

まずはすぐお隣のHIGHLANDS COFFEEで一発目のベトナムコーヒー:

HIGHLANDS COFFEEはチェーンで、ベトナムでは割とどこにでもあるというか、スタバのようなモノらしい。スタバはスタバで同様にその辺にあるけど。全然数が違う。日本で言うと、ドトールとかその辺かな、と思いました。

35k VND==大体200円くらい。安い。氷がやばい。

そして道路。噂に聞いていたベトナムの原付。やばい。

散歩していたら見つけたミニストップ。おでん(という名前の多分別の食べ物)が売られていたけど、この気温で食べる奴おるんか、とは思いましたね:

そうこうしている間に良い感じの時間になったので、ホテルに戻ってシャトルバスに乗車。行き先一覧に高島屋があって、安心感ありそうだったし、ユニクロとかが入っていて、現地限定のやつとかあるのかしら、と気になったのでいったん高島屋へ。見慣れたロゴで安心感がすごい:

限定のTシャツはあったけど、日本でＴシャツ買うのと変わらない値段で悩んでいる間に買ってくるのを忘れました。

高島屋は安心感がありまくって、ロイズがあったり:

白い恋人があったり:

で、ちょっと安心感がありすぎるくらいでした。

一通り高島屋を見た後は徒歩で無印良品へ。株主なので。(特に関係ないけど)

無印では限定のトートバッグが売っていて、これは結構安かったので買いました:

79k VNDなので、日本円だと500円弱くらい。

他にもダイソーがありました:

店頭のポップ、日本語で書かれていたけど誰が読むのか。

マツモトキヨシがあったり:

焼き肉ライクがあったり:

ビアードパパがあったり:

日本のお店がそこここにあるので、気持ち的にはすごくなんか安心感(?)がありました。

一発目のベトナム飯はコムタムという奴にしました。肉が美味そうだったので。

結果としてはあまり好みではなく、肉は固く、完食できませんでした。すまん。お値段としては800円くらい？ベトナムの飯としてはちょい高めかもしれないですね。

お口直しにスタバ。strawberry açaí with Lemonade 75k VND。まぁ、日本とあんまり変わらない値段設定ではありますね。普通に美味しい。安心。

Kubernetes Upstream Training in Japan at CNDW2024

Mon, 02 Dec 2024 23:58:44 +0900

最近イベントレポートばっかりですね？

先日、CloudNative Days Winter 2024 というイベントがございまして、私自身は結局いろいろの都合で参加しなかったのですが、これに合わせる形でKubernetes Upstream Training in Japan をオンライン・オフラインハイブリッド形式でで実施しました。

資料等はGitHub にアップロードされています。

Kubernetes Upstream Training in Japanは、Kubernetes にコントリビュートをしてみたいけど何から始めれば良いのかわからないという人向けに、初めてコントリビュートをするまで、の解説をしたり、コントリビュート体験をしてもらったりするイベントです。実際に現役でKubernetes関連プロジェクトのメンテナー・コントリビューターが講師陣をしているという豪華なイベントです。

今回は渋谷スクランブルスクエアにあるCyberAgentさんのセミナールームを借りて、オンライン・オフラインのハイブリッドで開催しました。

引き続きkubernetes/website にコントリビュートしたい方も募集しています。よろしくお願いします。

植物用のライトスタンドを作る

Thu, 28 Nov 2024 23:39:00 +0900

最近園芸にハマっておりまして、鉢植えを本棚の上に置いているのですが、部屋の向きや、季節の都合で日当たりがあまり良くなく、ライトを設置したくなってきました。しかし、本棚の周りにはライトを設置できるような突起物はなく、賃貸であるため壁に穴を空けるのも避けたいところです。ならばスタンドを、というところですが、手頃な値段のモノはサイズが微妙であったり、あるいはオーダーメイドだとサイズはぴったりだけど高い、ということで、手頃な値段でぴったりのモノを手に入れたい、という意志の元、DIYでライトスタンドを作ることにしました。

材料はこちら:

G-Fun という、アルミフレームの一種で、中空のアルミの棒をコネクタで繋ぐことでいろいろなモノを作れます、という商品です。簡単に組み立てられて、剛性もある、ということで何かと便利な奴です。強度データもすべて揃っており、すべり、引き抜き、モーメントなど、どれくらい耐えられるのかも分かるため、安心して荷重のかかるものを作ることもできます。

総額は(近所のDCMで)4,387円でした。

今回必要な工具は3mmと4mmのレンチとゴムハンマーです。

今回は何十キロもあるものを乗せる訳ではないため、見た目優先で一番細いSシリーズを選択しました。

本棚の天板サイズが幅1200mm、奥行き339mmなので、1000mm + ストレートコネクタ + 100mm + ストレートコネクタ + 100mmで概ね1200mmということにしました。将来組み替えたり、パーツを他のものに使い回したりする可能性を考慮して、ホームセンターでシュッと買える既製品で組める様にしましたが、よりぴったりサイズのものを作りたい人はG-Funオンラインストアでは切断してもらうこともできますし、専用カッターも販売されています。足は奥行きに合わせた長さ、高さは手元の植物にあわせて600mmとしました。高さは後で変更するかも。

端が露出する部分はキャップをつけて・・・(ここでゴムハンマーを使う)

一番長い棒と短い棒を繋いで・・・(ここで3mmのレンチを使う)

良い感じに組み立てて・・・完成！

あまりにもぴったりすぎて、ちょっとずれただけで足が落ちてしまいそうなので、家にあった鬼ピタを小さく切って固定しました。ガッチリ張り付いて、かつ剥がしたいときにはきれいに剥がせるので一本持っておくのがオススメです。何かと便利。

実際に電気をつけた様子がこちら:

良い感じですね。Amazonでライティングレールやら何やらを買ったので、後でつけようと思っています。

札幌に引っ越した件

Fri, 08 Nov 2024 17:33:18 +0900

標題の通りです。転職はしていません。

札幌の人、かまってください。

今のところ月に1回〜2回程度東京に行く予定があるので、関東の人もかまってください。

以上です。

YAPC::Hakodate 2024

Mon, 21 Oct 2024 10:00:00 +0900

今月の頭に北海道は函館市で開催されたYAPC::Hokkaido に参加してきました。

YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。

前回の広島に続いて、2024年二度目のYAPCで、北海道では2026年の札幌以来の開催ですね。

生まれ/親の実家が函館ということで個人的にはなじみのある土地で、いつも通り個人スポンサーで一般参加の予定だったんですが、@karupanerura さんからお誘いを受けたので、まぁせっかくならということで、いつぶりか分からない、当日スタッフとしての参加でした。担当としては「広報」という名前ではあったものの、札幌からの参加(先月末に埼玉から札幌に引越をしました)で車があること、カンファレンススタッフ経験がありなんとなくで動けること、コアスタッフがバタバタしていて上手く役割分担ができなかったこと、などから実際には買い出しやら遊撃やらをするような感じのムーブをしました。

前夜祭

前夜祭は函館市民会館での開催でした。久々にチラシのトートバッグ詰め作業をしたり、@papix さんとともに寿司ややきとり弁当を受け取りに車で回ったり、ビールが足りなかったので買いに行ったり。

皆さん寿司は食べることができましたか。私は食べられませんでした。割とこういう場面ではメシが余っている印象がありますが、即完売でしたね。。。

スタッフでも腹を空かせている人がそこそこいたようで、追い出し後にピザを注文するなどの一幕もありました。以下は治安の悪い顔でピザとビールを摂取するカメラマンの様子です:

本祭

本祭ははこだて未来大学で開催され、参加者の皆さんは専用のバスがチャーターされたようです。はこだて未来大学は車がないと厳しいですからね・・・

当日スタッフとしては朝はスポンサーブース設営手伝い、受付手伝い、うろうろしてブースの写真を撮ってDiscordに流す、ゴミ袋やスケッチブックを買いに行く、問題がありそうなところの報告や、人手が足りないところの手伝いをする、などをしました。

トークプロポーザルは残念ながら通らなかったのですが、それをそのまま突っ込んだLTプロポーザルは通り、それなりにウケたので大変良かったですね。

終わった後は最終居残り組として残って、余ったノベルティを懇親会場に運ぶ、ということで車を積極活用しました。

懇親会

車を運転して懇親会場に向かいましたが、JPA が運転代行代を持ってくれるということで、懇親会でビールなどを摂取することができました。助かりますね。

運転代行って初めて使ったんですが、なかなか面白い経験でした。

懇親会後、案の定(?)papixさんはベロベロでした:

風物詩という感じがしてわびさび(?)ですね(?)

当日スタッフは大変久々ではありましたが、たのしかったですね。

Tech Rock Festival 2024.09

Mon, 09 Sep 2024 23:00:00 +0900

2024年9月8日に新宿SUNFACEで開催されたITエンジニアによるITエンジニアのためのロックイベントTech Rock Festival 2024.09に参加してきました。

イベント自体の開催経緯は昨年のレポートを参照のこと。

実は今年の開催は7月にもあり、7月は観客として参加する予定だったのですが、ちょうど開催タイミングに新型コロナウイルス感染症に感染し、参加することができず、9月の回のみの参加と相成りました。

機材

ギターは昨年に引き続きYAMAHA PACIFICA 112V でした。

弦も変わらずElixir Optiweb 09-42です。今シーズン(?)は弦もいろいろ試しはしたんですが、やはり一番保つのはElixirですね・・・それでも月に一度は換えていますが。他に良い弦があれば教えてください。

エフェクターは昨年使用したZOOM G1 FOURをメルカリで売却し、代わりにGT-1000Coreを導入しました。G1 FOURは同時使用できるエフェクトが5コだったのでかなり縛りがある感じだったんですが、GT-1000Coreは(値段も高いですが)かなり自由に音を作れて楽しいですね。

GT-1000 はBluetoothも搭載しており、iOSアプリでパッチの編集ができる様なのですが、GT-1000Coreはできず、とはいえこの小さい画面ですべてをいじるのは大変だな、ということで調査をしたところ、MIDIでパッチをいじることができる、しかもBleutoothでワイヤレスでMIDIをいじれるようにするアイテムもあるということが分かったため、基本的にはこれを使ってiPad miniのGT-1000用アプリでパッチの編集をしていました。

また、クラウドファンディングで入手したCASIOのDIMENSION TRIPPER も投入しました。元々ワイヤレス+チューナー+小型マルチでぴったりサイズのボードを使っていたのでDIMENSION TRIPPERを乗せることができなかったため、ボード自体も新調しました。

DIMENSION TRIPPERの個人的不満点として、トランスミッターのギターとの接続部がプラスチックで取り付けにくい、傷などが不安という点があります。これを解消するために、部屋のその辺に転がっていたレザーの端切れと適当な金具を使って延長パーツのようなモノを作って接続部としました。便利。

コレをつかって変な音を出そうと画策もしたのですが、結局いい音ができず、これはただの拡張スイッチの様な形式で使用しました。

チューナーはまっすぐ貼り付けたハズだったのに何故か気づいたら曲がっていました。一度直したのに、また曲がったので、こいつは性根が曲がっているのだと思います。もちろんチューナーとしても使っていますが、ミュートスイッチとしても便利に活用しています。

パッチケーブルは引き続きOYAIDEのソルダーレスですが、最近はOAYIDE P-6.3L /OYAIDE P-6.3TL という奴が頭が極小で最高なのでコレを使いたいと思って、DIMENTION TRIPPERの接続はコレを使っています。制御信号なので別にこんなに良いプラグを使わなくても良いのですが、小さいボードとしては小さい頭のプラグは正義です。

パワーサプライは引き続きVITAL AUDIO VA-05 MkII 。GT-1000Coreをメルカリで買った時にOYAIDEのカレントダブラーケーブルが付属していた(正直単体で買うにはたっけえケーブルですね)ので、これを使っていますが問題無く動いています。若干短いので長いものが欲しい気もするんですが、高いので困っています。

エフェクターボードからアンプまではやはり引き続きCANARE LC03 だったかCANARE LC05 だったか(長さが違うだけ)を使いました。

アンプは今回は(他のバンドとの兼ね合いを考慮して)JCM2000でした。今回はGT-1000Coreに音の良いアンプシミュレータが入っているためリターン挿しでアンプに依存しない安定したサウンドを目指しました(というほどがっちり音作りしたわけではないけど)。

ピックはMASTER 8 JAPAN INFINIX-U JAZZ type with Hard Grip 0.88mm とPlanetWaves by D’Addario Medium を使いました。後者は昔Black ICEという名称で売っていて、すごく好きなんですよね。最近全然手に入らなくて困っていたのですが、秋葉原のヨドバシに何故か在庫があり、購入することができました。

builderscon 2024

Tue, 13 Aug 2024 18:53:37 +0900

builderscon 2019が終わった後、牧さんからbuildersconを引き継ぎ、builderscon tokyo 2020をやるぞ！と言ってから新型コロナウイルス感染症が流行り、そして開催を見送り、数年が経ち、そして今年、ようやく、buildersconを開催することができました。

公式ブログで記事を書いているときにも気持ちを書こうとはしたんですが、なんかもういろんな気持ちがぐっちゃぐちゃになってて、文章にまとまらないんですよね。ということで飲み会に誘ってください。ちょっとしばらくはバタバタする見込みになっており、必ず行きます！とは言えない状況なのですが、できるだけ行きます。

大吉祥寺.pm

Tue, 16 Jul 2024 13:18:40 +0900

東京都は吉祥寺で開催されているイベント、吉祥寺.pmの10周年記念イベントとして大吉祥寺.pm が2024年7月13日に開催されたので、参加してきました。参加者がたくさんいることももちろんそうですが、10周年というのは本当にすごいですね。

受付をしたら名札とおみくじをもらいました。

ランチに食べたいものを書いておくことで、スタッフの方でよしなにグルーピングをしてくれるそうでした。こういうイベントではなんだかんだ知り合いと話をしてしまいがちなので、新しいコミュニケーションが促進される企画は大変良いモノですね。

全体の内容としては、テーマが「いままでと、これから」ということもあってか、技術をゴリゴリというよりはコミュニケーションやキャリア、歴史といったモノが中心でした。トークとしては一定のコンテキストで、という感じではあったものの、より広く適用できそうと言うか、上手にコミュニケーションをしていくのが大切ですね、という内容で納得感のあるものでした。

昼ご飯は和牛油そばという奴を食べたんですが、すごく味が濃くて多かったです:

私が現在住んでいる埼玉県朝霞市から吉祥寺は電車だといったん新宿まで出て(右下のほう)、その後吉祥寺に向かう(左)というルートを取る必要があり面倒だったので車で行ったのですが、車だと結構近いですね。駐車場は多少高いようにも思えますが、上限のある駐車場が結構たくさんあるので、駐める場所にも困りませんでした。朝から一日大吉祥寺.pmに参加し、懇親会に出て、二次会で深夜まで駐めていても2,500円ということで、終電を気にしたり、暑い中乗り換えをしたり・・・ということを考えれば全然安いかな、と思いました。

というわけで改めて、10年続いているイベントはすごい！

OSC 2024 Hokkaido

Tue, 16 Jul 2024 12:45:17 +0900

2024年6月29日に開催されたOpen Source Conference 2024 Hokkaido に行ってきました。

例年参加しているので概ねいつも通り、という感じではあるので一応レポートを残しておきます。

今回は諸諸の都合により前日の日中に札幌入りして、土曜日は本祭、日曜日の昼の便で帰るという弾丸ツアーでした。

金曜日の夜は関係者前夜祭で石鍋亭へ。変わらず美味しいですね

石鍋亭へ向かう途中見てしまったダイコクドラッグの閉店のお知らせ。札幌駅は工事の関係もあってどんどんいろんな店が閉店していてさみしいですね。

当日のブースの様子はこんな感じです。一応Kubernetes SIG Docs Japanese Localization teamとしての参加ということにしてありましたのでスライドを流すなどしていましたが、冷房直撃でちょっと寒かったので、あまりここには座っておらず、その辺をふらふらしていました。ステッカーの類くらいは作っても良かったかな、と(毎年)思っています。

昼ご飯は特に決めていなかったのでカレーカンファレンスに。

道警さんのブースで投資詐欺に注意！というチラシも配っていました

最後は新千歳空港でかま栄のかまぼこを買って帰りました。本当は大丸で買いたいんだけど、今回は時間が無かったので。。。札幌、あるいは小樽にに行く人は是非買って下さい。

Expression Knob

Mon, 17 Jun 2024 00:52:00 +0900

エクスプレッションペダル、というものがありますね。ギター用のエフェクターやその他電子楽器等のボリュームやらパラメータやらを足で操作するためのペダルですが、その中身は非常に単純です。とはいえペダルとして作るには上手く駆動部分を作る必要があって簡単にはいかないのと、足で操作せずとも、マルチエフェクターのフットボリューム機能を使えるとエフェクトループの任意の場所でボリュームを調整できると便利ということがあり、より単純な形として「エクスプレッションノブ」を作成したので記録しておきます。

使った材料は次の通り:

秋月電子で揃えれば260円+送料程度で済みます。後で紹介する既製品だと安くても4,000円程度はしますから激安ですね。

操作対象のエフェクターはBOSS GT-1000CORE です。聞いたところによるとHX STOMPとかはエクスプレッションペダルの仕様が違うようなので注意。

ボリュームは10kΩBのモノであれば多少サイズが違ったりスライドボリュームだったりしても大丈夫なはずですが、端子の仕様が違ったり(多分大体同じですが・・・)、対応しているツマミが違ったりすると思いますので、適宜調整してください。ツマミはお好みのモノを選んでください。

今回は気分で3.5mmのミニジャックを使用しましたが、これもステレオであれば任意のジャックで良いはずです。エフェクター側は基本的に6.3mmの標準プラグだと思うので、6.3mmのジャックだとケーブルが手に入りやすくて便利かも知れません。今回は隙間に突っ込みたかったので小さい端子を選びました。どうせパッチケーブルは自分で作りますし。

ケースも任意のモノで問題ないでしょう。サイズが良い感じだったのと、コントロール信号が通るだけなら良いか、ということで今回はプラスチックケースにしました。

回路図は次の通り:

実体配線図としてはこんな感じ:

その辺にあった適当なケーブルで配線をして、適当にケースに穴をあけ、パーツを組み込んで完成です。穴は適当な細いドリルで下穴を開けた後にステップドリルなどを使ってちょうど良い大きさになるまで穴を拡張するときれいに空けることができます。プラケースなら電動ドリルを買わなくても、手で十分空けることができます。

あとは手頃なステレオケーブル(ヘッドホン用とかがその辺に転がっていますね？ソレを使ってテストをしましょう)でエフェクターと接続して、動作確認をすれば良いでしょう。

まだエフェクターボードには組み込んでいませんが、便利に活躍してくれることを祈っています。

なお、作るのは面倒だけどほしい！という人は既製品も販売されているようです:

El Garatge (5,573円)
LAGOON SOUND (3,800円)
electro-harmonix (コンパクトエフェクタータイプ 7,680円)
Old Blood Noise Endeavors (スライダータイプ 8,250円)

以上です。

梅仕事2024

Mon, 03 Jun 2024 12:18:34 +0900

6月ですよ！今年も梅酒を漬けましたので記録をしておきます。

今年の材料は以下の通り:

梅: ヤオコー和光丸山台店で売っていた南高梅1袋。多分1kgくらい。
砂糖: 日新製糖の中ザラ糖1kg。中ザラ糖でつけるのは2020年以来ですね。
酒: 美峰酒類製造、酔仙酒造販売のホワイトリカー「果実の泉」1.8L

今年はカインズでPET製の果実酒瓶が売っていたので、そちらを使用しました。丸いガラス瓶は「ぽい」んですけど、割れそうで気を遣うし、床面効率も良くないんですよね。

最後にテプラでレシピを記録。これまで買っていたガラス瓶はだいたい説明書にメモを書いておく欄があって、それを切って使っていたのですが、今回はなかったのでテプラでメモをすることにしました。

昨年の梅酒はこんな感じになっていました:

昨年はホワイトリカーに氷砂糖という、かなり標準的なレシピで作りましたので、ザ・梅酒という感じのスッキリとした味でした。

また来年お会いしましょう！

git-gutter to diff-hl

Sun, 26 May 2024 11:00:00 +0900

これまで、emacs上で行ごとの変更状況を表示するのに、git-gutter.el を使用してきました。約4年前から使用しており、今現在でも問題なく動いているため特に不満はなかったのですが、emacs-jpでdiff-hl の話を聞き、見た目が良いな、と思ったのでdiff-hlに移行しました。

git-gutterの見た目:

diff-hlの見た目:

fringeを使用するようになったことでフレームが少しスッキリしました。

問題が一点だけあって、私は普段macOS上でemacs-mac を使用しているのですが、frameを複数に分割したとき、一番左のwindowでは問題なく表示されたのですが、右側のwindowでは縦フチが表示されませんでした。

emacsを起動した後に手動で(fringe-mode '(9 . 8))などとしてfringeの幅を広げると上手く表示される一方、default-frame-alistに広げた幅を入れても何故か上手く表示がされない状態で起動してきたため、diff-hl-modeを有効化した後に幅を広げないと上手く調整がきかないのか、と思ったので、次のようにdiff-hl-modeを呼び出してset-frame-parameterする形で解消しました:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


;; show git diff parameter on fringe
(use-package diff-hl
 :ensure t
 :diminish
 :hook (magit-post-refresh . diff-hl-magit-post-refresh)
 :init
 (global-diff-hl-mode)
 ;; somehow the left line is not drawn well without setting left-fringe
 ;; parameter after diff-hl-mode is enabled
 (diff-hl-mode)
 (set-frame-parameter nil 'left-fringe 9)
 (diff-hl-flydiff-mode))

正直イマイチ感がすごいので、良い解決方法をご存じの方がいたら教えてください。

Kubernetes Upstream Training Japan 2024-03

Mon, 01 Apr 2024 23:20:00 +0900

かれこれ半月ほど経ってしまったのですが。

昨年末にCloud Native Computing Foundationの日本チャプターとしてCloud Native Community Japanが発足しまして、そのサブチャプターとしてKubernetes Upstream Training Japanが立ち上がり、第一回のイベントとしてKubernetes Upstream Training Japn 2024-03 を実施しました。

資料などはGitHubのリポジトリに上がっているので見ていただくと良いのですが、要するにKubernetes にコントリビュートをしてみたいけど何から始めれば良いのかわからない・・・という人向けに、Kubernetesコミュニティではどのように普段コミュニケーションをとっていて、どういう手順でコントリビュートをすれば良いのか、という解説をしたり、実際にコントリビュート体験をしてもらったりするイベントでした。

なにせKubernetesというのは世界中で使われている大きなソフトウェアで、英語がさらっと読める人は良いのですが、日本人としてはやはり英語が苦手だという人も多いですし、まして技術力が求められ(そうに見え)るところに飛び込んでいくというのはなかなか勇気が要るモノです。そんな人の背中を押して、日本のKubernetesコミュニティをもっと盛り上げていこう、というのがこのイベントの目的であるわけです。

次回開催はいつになるか不明ではありますが、Kubernetes(特にkubernetes/website )にコントリビュートしたい！という人は積極的にサポートしていく所存でありますのでお気軽にご連絡ください。

情報認識学研究室工藤先生の最終講義に行ってきました

Tue, 12 Mar 2024 13:30:00 +0900

大学時代の恩師であるところの工藤峰一教授が退官なさるということで、最終講義と祝賀会に行ってきました。

4月からは新しい方が着任なさるという話ですが、研究室の名前も変わるかも知れませんし、PRMLくんももう見られなくなるかもしれないですね

PNGの仕様を眺める

Fri, 16 Feb 2024 21:40:00 +0900

このブログは現在、Hugo という静的サイトジェネレータを使用してページを生成しているのですが、このHugoには多くの便利機能があり、そのうちの一つがImage processing です。

テンプレートの中で、ほんの数行のコードを書くだけで、画像のサイズを調整したり、切り抜いたり、あるいはぼかしたりすることもできます。これまでのところ、このブログでは画像のサイズは結構適当で、場合によっては表示の幅が変わってしまって見栄えが良くないということが(たまに)ありました。

そこで今回、HugoのImage processing機能のうち、Resizeを使用して、実際にサイトが表示されるときの画像を良い感じにしようと思ったのですが、サイト全体の画像描画部分にhookをかけたところ、エラーが出てビルドができなくなってしまいました。エラーメッセージの大半はファイルパスで、今回は本筋ではない上に長いので端折るとして、重要そうなところを抜き出すと次の様な感じ:

1
2


execute of template failed at <$image.Resize>: error calling Resize:
: resize : png: invalid format: invalid checksum

要するに、Resizeしようとしたときに、checksumが合わないので対象のpng画像ファイルがおかしい、ということらしいんですよね。しかしこれまでこのブログを更新してきて、(パスとかが間違っていない場合に)画像が表示されなくて困ったこともないし、そもそもpngファイルにchecksumがあるなんてことも知らないし・・・

golang/go#43382 での会話を見たところによるとどうやら、pngファイルには「チャンク」と呼ばれるモノが存在して、これが無視できることも多い(特に実際に表示する時には不要なモノが多い)けれど、Goのimage/pngは今のところはそれらを無視せず、エラーを吐くことになっている、ということらしい。

エラーの対象となったファイルを、issueの説明に書かれているようにpngcheckにかけてみると次のようにCRCエラーがあることが分かりました:

1
2
3
4
5
6
7


$ pngcheck -v arch-1.png
File: arch-1.png (272304 bytes)
 chunk IHDR at offset 0x0000c, length 13
 1082 x 778 image, 32-bit RGB+alpha, non-interlaced
 chunk zTXt at offset 0x00025, length 188903, keyword: mxGraphModel
 CRC error in chunk zTXt (computed c3f0b5f1, expected 1ce878d9)
ERRORS DETECTED in arch-1.png

なるほど、zTXtというチャンクがあって、そこのCRCが間違っている、ということらしいですね。キーワードはmxGraphModelということで、分からないけど多分グラフに関連したモノが入っているのでしょう。確かにこのファイルはdraw.ioで書き出したもので、書き出しの時に編集情報のようなものを埋め込むオプションを有効にした気がするので、それがどこかのタイミングで壊れ、今回のエラーにつながった、という流れの様です。

Introduce Tree Sitter to Emacs

Wed, 14 Feb 2024 23:20:00 +0900

近年、テキストエディタ/IDEの機能はますます複雑となり、プログラミング言語の数は増え、その組み合わせは膨大なものとなっています。元来テキストエディタはそれぞれがそれぞれの実装でそれらの組み合わせを実現してきましたが、自動補完、定義ジャンプ、ドキュメントの表示など、概ねその基本的な機能は同じであるにもかかわらず、すべてのエディタ開発者はそれぞれが車輪の再発明を行う必要があったのです。その問題を解決するために設計開発されたのがLanguage Server Protocol(LSP)であり、ここ数年で多くのテキストエディタが採用したことにより名前くらいは知っているという人も多いのではないでしょうか。

Tree-sitter はある意味でLSPあるいはLanguage Serverと呼ばれるものに似ています。Tree-sitterは、プログラミング言語の文法から構文解析器を自動生成するパーサージェネレーターツールであり、またそれを使用した構文解析ライブラリです。

Tree-sitterは任意の言語を解析できる汎用的なツールで、動作が速く、依存が少ないツールです。2018年にGitHubからリリースされ、emacs 29.1ではbuilt-inの機能として使えるようになりました。

Emacs x Tree-sitterの仕組みと導入

emacsでTree-sitterを使うには、2つの条件があります:

使用したい言語のパーサーが実装されている
Tree-sitterに対応したmajor modeが実装されている

使用したい言語のパーサーが実装されている

当然のことながら、Tree-sitter用に文法が定義されている必要があります。使用したい言語のパーサーが既に誰かによって実装されているかは、available-parsers のリストを参照すると良いでしょう。概ね、メジャーどころの言語は実装されておりほとんどの場合困ることはないと思います。各言語の文法定義(grammar)はJavaScriptで定義し、tree-sitter CLIを使用してC言語のソースコードに変換し、最終的にはそれをコンパイルして使用します。

emacsの場合、~/.emacs.d/tree-sitter/ディレクトリにコンパイルされたダイナミックリンクライブラリを置くことで読み込むことができます。予めコンパイルされたものを置く、でも良いのですが、treesit-install-language-grammarを使用すると文法をダウンロードしてきて配置してくれるため簡単です。treesit-install-language-grammarを使用するには、まずtreesit-language-source-alistに言語とgitリポジトリのペアを定義します。その後treesit-install-language-grammarに言語を渡すことでgit cloneからコンパイル、配置まで行ってくれます。

例えば、YAML用の文法を導入するには次の様に定義します:

1
2


(setq treesit-language-source-alist
 '((yaml "https://github.com/ikatyang/tree-sitter-yaml")))

そして、(treesit-install-language-grammar yaml)(もちろんM-xでやっても良いと思います)とするとYAML用の文法がインストールされます。私はこの手のものはemacsの起動時に自動で導入されてほしいので、次の様にしました:

1
2
3
4
5
6
7
8
9


(setq treesit-language-source-alist
 '((yaml "https://github.com/ikatyang/tree-sitter-yaml")))

(dolist (element treesit-language-source-alist)
 (let* ((lang (car element)))
 (if (treesit-language-available-p lang)
 (message "tree-sistter: %s is already installed" lang)
 (message "tree-sitter: %s is not installed" lang)
 (treesit-install-language-grammar lang))))

Tree-sitterに対応したmajor modeが実装されている

emacsでTree-sitterを使用したい場合、残念ながら、LSPを使用するときのように、単純にパッケージを追加すればすべての言語でよしなに動く・・・という風にはなりません。emacsでは今までのところ、major modeがシンタックスハイライトを提供するためには主に正規表現などが使用されてきました。正規表現を利用したシンタックスハイライトと、Tree-sitterを使用したシンタックスハイライトは大きく違うため、ほとんどのmajor modeではそのままTree-sitterを採用する形にはならず、Tree-sitter専用のmajor modeが提供される形になっています。emacs29ではメジャーどころの言語に対するTree-sitter対応モードが提供されています。

手動でこれらのモードを拡張子ごとに設定しても良いのですが、major-mode-remap-alistを設定することで、従来のmajor modeをそのままTree-sitter対応のモードに切り替えることができます。

例えば、yaml-modeの代わりにyaml-ts-modeを使用する場合次の様に設定します:

1
2
3
4
5
6


(add-to-list 'major-mode-remap-alist '(yaml-mode . yaml-ts-mode))

;; or

(setq major-mode-remap-alist
 '((yaml-mode . yaml-ts-mode)))

この設定によって、yaml-modeでバッファが開かれる場面ではすべてyaml-ts-modeが使用されるようになります。今のところ、hookなどの設定は移行されないため、これらは個別に設定を移行する必要があります。

YAPC::Hiroshima 2024

Mon, 12 Feb 2024 02:51:00 +0900

2024年最初のテックカンファレンスとして、YAPC::Hiroshima 2024 に参加してきました。

YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。

広島に来たのは2017年にOSC2017 Hiroshima 以来2度目です。前夜祭、アフターイベントがあるうえ三連休に絡んでいるということで、木曜日の午後に広島入りして、月曜の夜に帰るという4泊5日という計画としました。なお、弊チームではPerlを使用していないため業務ではなく趣味なのですべて自費です。

前夜祭

前夜祭は本編と同じ会場で、2本のトーク(?)と番宣リレーという企画がありました。以下ハイライトです:

妻から連絡が来たが「登壇中です」のみを返す実績を解除しました。
— そーだい@初代ALF (@soudai1025) February 9, 2024

登壇しながら明日のLTの資料作ってる #yapcjapan
— そーだい@初代ALF (@soudai1025) February 9, 2024

そーだいさんクラスになると登壇しながら資料を書ける、学びですね(?)

本編

本編は3トラックで開催されました。次のセッションを聞きました:

コミュニティと共に生きる - キャリアの螺旋と人生を変えた瞬間
(再演) 関数型プログラミングと型システムのメンタルモデル
Blogを作り、育み、慈しむ - Blog Hacks 2024
非同期な開発体制を支えるドキュメント文化
PerlでつくるフルスクラッチWebAuthn/パスキー認証
平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜
ライトニングトーク
キーノート

どのセッションももちろん最高だったんですけど、やはり最高of最高はとほほさんによるキーノートでした。

正直これまでカンファレンスで話を聞いたどのレジェンドよりも「実在の人物だったんだ・・・」感がありました。いやまぁそりゃ、実在の人物でしょうけれども。

個人スポンサーノベルティはこてでした。SmartHRさんもこてを配っていたのでもらいました。右手と左手で、ひっくり返すのに便利かとおもったので。この時はまさかあんなことになるとは思ってもいなかった・・・！

懇親会

今回はなんと懇親会あり。YAPCとしては実に5年ぶりの懇親会だそうです。永遠に時間が足りないですね。困った。

二次会

各社による半公式二次会があるのも知ってたんですが、なんとなくまぁ申し込みをしないでおいたんですよね。野良二次会やりたくて。なので野良二次会をやりまして、同じ会社の人と実質初めましてですね、Slackではお世話になってます的な話をするなどしました。

YAYAPC::Hiroshima

アフターイベントとしてYAYAPC::Hiroshima にも参加しました。なんだかんだ三日間。すごい。

テーマは"What you live"ということで、オフラインだからこそ話せること、ということで、まぁTwitterを見てもらうとわかるのですが、インターネットで共有はできないものの、みんなわかる・・・！という感じで、うめき声みたいなツイートが発生していました。

ぼーっとしている間にLT枠が埋まってしまっていたので、応募すればよかったかな〜などと思っていたのですが、当日、タイムテーブルミスったからLT枠がある、ということで飛び入りで怪しい話をさせていただき、なんと賞まで頂戴いたしまして、結果的に個人スポンサーノベルティのこてが2本と相成りました。いやー、これにはびっくり。大変ありがたいことです。

終わった後は12人ほどで飲みに繰り出しまして(17時頃)、途中人が多少入れ替わりつつ飲み続け、23:30頃に解散しました。

これは死んでる @songmu san #yayapc #yapcjapan pic.twitter.com/vFajihV2vC
— nasa9084@某某某某(0x1f) (@nasa9084) February 11, 2024

そして解散した後は深夜だというのに一人でお好み焼きを食べるなどしました。お好み焼き美味しい。

Tall Titlebar Issue on macOS Sonoma

Tue, 06 Feb 2024 01:45:02 +0900

私は普段、railwaycat/emacsmacport を使ってインストールしたemacs-mac を使用しているのですが、何故かmacOSをSonomaにアップグレードしたらタイトルバーが太くなりました。

macOS SonomaにしたらEmacsのタイトルバーが太くなった…！によると、次の設定を入れるとなおるようです:

1
2


(tool-bar-mode 1)
(tool-bar-mode 0)

うーん、起動も遅くなったっぽいし、workaround感がすごい。わかんないですけどなんかフレームの初期化に失敗しているとかそういう感じなんでしょうか。

emacs-macの方で修正を入れてくれている様子なので、リリースされるまではこのworkaroundでしのいでおくくらいしかできなさそうです。

THEO解約レポート

Mon, 05 Feb 2024 22:00:00 +0900

2024年、新NISAが始まりましたので、手数料が高いTHEOを解約して新NISAに移すことにしました。LINE証券と同様、記録を残しておきます。

2018年9月3日: THEO登録、10,000円/月で積み立て設定
2018年10月15日: 初回入金
2020年2月20日: 20,000円/月に積み立て設定変更
2022年3月28日: 10,000円/月に積み立て設定変更
2023年12月29日: 最後の積み立てが終了

総積立額は880,000円、トータルリターンは330,325円 (+37.54%)でした。

以上です。

LINE証券解約レポート

Wed, 31 Jan 2024 21:15:00 +0900

あけましておめでとうございます。本年もよろしくお願いいたします。世間では新NISAが話題ですが皆さんいかがお過ごしでしょうか。

扨、LINE証券がサービス終了ということで、LINE証券で積み立てていた投資信託をメインの証券口座に移管して、新NISAに突っ込むべく売却したのでレポートとして記録に残しておきます。

銘柄はeMAXIS Slim米国株式(S&P500)、タイムラインは次の通り:

2022年5月: 積み立て開始、積立額は17,000円/月
2022年12月: 積立額を27,000円/月に増額
2023年11月: 最後の積み立てが終了

保有数は215,920口、積立総額は443,000円、本日(2024年1月31日)時点で概算評価額は561,607円、評価損益は+118,583円、評価損益率は+26.76%でした。

以上です。

ワイヤレス送信機用延長シールドを作る

Thu, 28 Dec 2023 01:47:40 +0900

現在、ギターを練習するとき、有線でケーブルをつなぐとイスで踏んでしまったり、あちこちに引っかかってしまったりして不便なので、LINE6 Relay G10TII というワイヤレス送信機を使っています。

今使用しているギターはYAMAHA PACIFICA 112V なんですが、このギター、サイドにジャックがあるんですよね。そうすると、ワイヤレスの送信機、特にG10TIIやBOSS WL-20 の様な四角いタイプの送信機を挿すとかなり飛び出る格好になってしまい、オフィスチェアに座って練習をしていると(単にオフィスチェアとギター練習の相性が悪い、という点はさておき)ぶつけて折ってしまいそうで不安になります。

一応L字のアダプタは付属していたような気もしますけれど、丸みのあるギターの側面にL字アダプタを挿しても、結局違う方向にはみ出るのはあまり変わらないな、ということでL字プラグに短いケーブルがついている、いわば「延長ケーブル」を作りました。

なお、何故ライブ前に作らなかったのか、という問いには答えられません。

材料

任意のL字プラグ
- 今回はオヤイデの超小型な奴。使ってみたかったので。
任意のフォンジャック
- 今回はTOMOCA JS-504 。見た目が良かったので。
- 千石電商とかでもっと安いのも買えるけど、送料がかかるので通販だと実質TOMOCA JS-504一択。秋葉原によく行く人は千石電商秋葉原本店の2階か、ラジオ会館のトモカ電気プロショップに行くとソレっぽいモノが売っています。
任意の単芯シールドケーブル
- 今回はCANARE GS-6 。ど定番だし、たまたま安く売ってたので。
- PACIFICA 112Vの場合は25cm位用意すればちょうどよさそう
何か絶縁する奴
- 無くても良い。フッ素テープとか熱収縮チューブとか。ホームセンターとかで買ってきても良いし、ご家庭に在庫している適当な熱収縮チューブを使っても良い。
任意の半田
- 材料というか工具というか？

工具

任意の半田ごて
半田吸い取り線
- 無くても良いけど、ミスした場合を考えると持っていた方が良い。
任意のニッパーまたはカッターまたはまたはワイヤーストリッパー
テスター
- 無くても良いけど導通チェックはした方が安心
(オヤイデのSuperSlimシリーズを使う場合)任意のプラスチック/ゴムハンマー
(熱収縮チューブを使う場合)任意のヒートガン
- ドライヤーなどでも代用できるけど、あった方が便利
ツールクリップ
- 土台に腕とクリップがついていて、はんだ付けする対象を固定できるやつ
- これもなくても良いけど、ケーブルのはんだ付けは細かいし、ケーブルは意外とのたうち回ってはんだ付けが難しいのであった方が良い。

作成手順

目算で外側の被覆を剥く
シールド線をほぐす
L字プラグをつける (以下オヤイデSuperSlimの場合)
1. シールド線をざっくり二つに分けて芯線に巻く
2. 芯線を剥く
3. カバー？ハウジング？をはずしたオヤイデSueprSlimに差し込みTIP(+)にはんだ付けする
4. クランプ側面の穴からはんだを流し込む
5. 導通チェックをする
6. 熱収縮チューブを差し込んで加熱して収縮させる
7. カバーをつける
8. 樹脂キャップを乗せてプラスチックハンマー/ゴムハンマーで叩いてはめ込む
フォンジャックをつける (以下TOMOCA JS-504の場合)
1. フォンジャックのカバーを差し込む (これを忘れてはんだ付けするとやり直しになるので注意。私はやり直しました)
2. シールド線を適当にまとめる
3. 芯線を剥いて二つに分ける
4. シールド線、芯線の順にはんだ付けをする (フッ素テープやビニールテープなど絶縁するモノの用意があれば絶縁しておくと安心)
5. カバーをつける
完成!

実際にギターに挿す

実際にギターに挿すとこんな感じ:

Tech Rock Festival 2023

Mon, 25 Dec 2023 23:32:00 +0900

2023年12月23日に新宿SUNFACEで開催されたITエンジニアによるITエンジニアのためのロックイベントTech Rock Festival 2023に参加してきました。

経緯

事の発端は某GAFA社長であるところの@jyoshise sanによる次のツイートでした:

エンジニア界隈で楽器やってる人、秋ぐらいにライブやりませんかー！？
— jyoshise (@jyoshise) June 22, 2023

どうやら、エンジニア界隈、結構音楽やっている奴いるぞ、ということで立ち上がったプロジェクトですが、翌日にはGitHub Repositoryが立てられ:

Repo立てましたー！https://t.co/4OqYjugBBr https://t.co/ncT3tKxWDG
— jyoshise (@jyoshise) June 23, 2023

7月の頭には申し込み締切、13日にはバンド振り分けが終わり、会場も決まり、練習を進めて、先週の土曜日ついに開催となりました。演者がエンジニアという都合上、大きめのテックカンファレンスとかぶらないようにしなければいけないということで調整の結果、12月末は目立ったテックカンファレンスもないだろうということで12月23日の開催となりました。

概ね演者だけで会場は一杯だったのですが、一般オーディエンスも募集していました。

バンドと演目

私たちのバンドは3-way handshakeという名前で、当初バンドに振られた連番が3であったことから、3に関連する技術っぽい言葉でバンド名っぽくもある、というところでこの名前になりました。

面子は以下の通り:

そして曲目は次の通りでした:

深夜高速 / フラワーカンパニーズ
ばらの花 / くるり
歩いて帰ろう / 斉藤和義
群青日和 / 東京事変

機材

ギターはYAMAHA PACIFICA 112V です。

正直に言うと、当初600シリーズを買おうと思ったけど某アニメの影響で全然買えなくて、妥協で買ったギターではありますが、良いギターだと思います。

弦はElixir Optiweb 09-42です。

エフェクターはZOOM G1 FOUR ですべてを済ませました。練習ではTHR10II Wireless に無線で繋いでいるので、有線でやるのはやだな〜と思って、LINE6 Relay G10SR を購入してエフェクターボードでも無線で接続できるようにしました。

チューナーはG1 FOURにもついてはいるんですが、手前に専用のモノを用意した方が見やすいし、ミュートもできて便利だな、と思ったのでtc electronic POLYTUNE3 を入れました。miniだと黒があってよかったんですが、シュッと手に入らなかったので普通のサイズにしました。

2023年買って良かったモノ

Sat, 16 Dec 2023 02:09:00 +0900

もう2023年も終わりますね。2022年の記事は主に車とアクアリウムでした。今年は主に喫茶系とギターですね。

喫茶系

Fellow ODE Gen2
- 正直クソ高いけど、使いやすいしはやく安定した挽き目で弾いてくれるのでとても良いです。家庭用には珍しくノッカーがついているのも良いところ。
ニトリドリップカップ
- 小さくて取り回し抜群。1杯分を入れるには全然困らない。
HARIO 茶茶ドリッパー・ブーケサーバーセット
- 茶の類いのモノを淹れるのにめっちゃ便利。サーバーはアイスではとても便利だけど、ホットは熱くて持てなくなるので注意。
サーモス真空断熱ティーポット
- 温かい飲物が美味しい季節になったので買ってみた。保温性能はもちろんマグカップよりは圧倒的にいい(1時間そこそこは保温してくれる)けど、それよりもコーヒーサーバーとして使える小型の断熱ポット、というモノが便利。調べた感じではこれが唯一解。なおティーストレーナーは要らないと思います。
LOVERAMICS BEANS DOSING TRAYS
- James Hoffmannコラボの、コーヒー豆を計るためだけの器。絶対必要なモノではないけど、かわいいしテンションが上がるのでオススメ。

ギター関連

YAMAHA PACIFICA112V
- ぼざろ影響で600シリーズが在庫無くて112Vにしたけど、ちょっと弾くくらいならこれで全然十分。600シリーズ欲しくなってきてるけど。
G7th Performance 3 ART Capo Black
- ちょっとカポとしてはお高いけど、かなり使いやすいです。
ねこだまり工房/自家製クリア蜜蝋ワックス陽だまりの香り
- 好みの香りだった。限定品らしくsoundhouseではもう販売終了しているけど、ネット通販ではまだ手に入るところがありそう。
MASTER 8 JAPAN INFINIX JAZZ TYPE HARD GRIP
- このシリーズは全部揃えてみたけど、HARD GRIPタイプがグリップ感が強くて良い。薄さはお好みで。INFINIX-Uでもよい。
PEDALTRAIN NANO
- 超小型エフェクターボード。G10SR 、Polytune3 、G1 FOUR でぴったり、という感じの構成。電源はVITAL AUDIO POWER CARRIER VA-05 MkII が良いサイズ。マルチはGT1000-coreを買うか検討中。
アルトベンリ
- ちょっとサイズが合わないのでティッシュを詰めて使っている。
HERCULES GS414B PLUS
- 安定感抜群。

日用品など

コクヨマスキングテープテープカッターカルカットクリップタイプ
- 一般的な用途としてはおしゃれマスキングテープ用のカッターとして使んだと思うけれども、普通の黄色いマスキングテープにつけて使っている。手で切るとぐちゃっとなってしまうこともあるのでとても便利。
[RLJ] 引き出しミニサイズ (後付けタイプ) ミニ引き出し
- 正直コスパはどうなのか、という感じはある。作りはチープだし、有機溶剤っぽい匂いが永遠に取れない。が、まぁ便利は便利。私が買った時より値上がりしていてコスパは更に悪化してそう。
鬼ピタ魔法のテープ
- めっちゃ強力。きれいに剥がせるといううたい文句に嘘はないけど、貼り付け面が弱ければ壊れてしまいそうな位には強力。ギターのエフェクターをエフェクターボードにつけるのにも使っている。
uxcell 丸平頭ローレットつまみ M2x8mm ハンドクランプねじ
- 手で回せるねじ。無線化しているErgodashの背面プレートを開けたり閉めたりするのが簡単になった。
[PureSino] アームバンド
- カーディガンなどの袖を止めるのに便利。基本的に袖まくりしているので。1セット持っていたハズなんだけど、行方不明だったので買ったが、やはり便利。
ラムマウント(RAM MOUNTS) MagSafeマウント
- 便利ではあるけど、高いMagSafe充電器を追加で買う必要があるのはコスト的に結構厳しめかもしれない。
SwitchBot カーテン第3世代
- SwitchBot カーテンからの買い換え。一世代しかしらないけど、何故か第3世代らしい。従来品よりはやいし、静かに動かすこともできるし、取り付け、取り外しも簡単になっている(構造としては変わらないけど、作りが改善されている)し、位置調整がメチャクチャ簡単になっている。従来品(Amazonによると第2世代)より2,000円高いけど、こっちを買った方が良いです。
BREENHILL テーブルマット 100x40cm
- ほんとは120x40とかがほしいんだけど、無かったので妥協した。100x40でも珍しいです。マウスパッドとして良いかどうかは分からないけど、トラックパッドを使っていて、ただ何か敷物が欲しいくらいの人にはお勧めできる。裏面に滑り止めがついているけど、これは余り期待しない方が良い。

書籍

あかね噺
- 買った時はまだ4冊だったのに今は9巻まで出ている。ジャンプは続きが出るのがはやくて良いですね。
江戸前エルフ
- アニメ化もされた。アニメも良いです。
お前、タヌキにならねーか？
- タヌキになりたい。
Dr.STONE
- セールで50%ポイント還元だったので買った。理系の人ないし理系っぽいテーマが好きな人は好きだと思う。
ボボボーボ・ボーボボ
- 同じく50%ポイント還元だったので。なんか最近ボーボボ見る機会多い気がするんだけどなんで?
葬送のフリーレン
- 紙をkindleに買い換え。特に言うことは無いです。

すごい味噌汁

Tue, 05 Dec 2023 18:47:06 +0900

いつからか、風邪の時に作る謎の味噌汁がある。少なくとも、実家で作っていたモノではなくて、関東に引っ越してきてから作り始めた。どういうきっかけだったかは不明で、多分妹がどこかから聞いてきたモノを魔改造して完成した。

レシピは次の通り。

材料

出汁
味噌
ニンニク
生姜
ピーマン
たまご

なお分量はすべて「適量」である。ニンニクは一かけ、生姜はニンニクと同じくらいの量、ピーマン一つ、たまご一つ、といった感じ。出汁は出汁の素の類でかまわないし、ニンニクと生姜はそれぞれチューブでも良い。生のモノを使うともちろんより美味しい。

個人的には出汁の素は大体入れるが、気にならなければ出汁入りの味噌を使っても良い。生姜とニンニクが十分に強いので、なんなら出汁がなくても気にならないかもしれない。

調理手順

湯を沸かし、出汁を取る、乃至出汁の素を溶かす
味噌を溶かす
ニンニクと生姜をすりおろして入れる
溶きたまごを回し入れる
ピーマンを入れる

ピーマンに火が通ったな、と思ったら完成。ピーマンは食感が残る程度でも美味しいし、クタクタになってもそれはそれで美味しい。細切りにしても良いし、写真のように輪切り？にしても良い。ワタを取ることを考えると、細切りの方が簡単。

溶きたまごを回し入れるときは、(味噌汁的/出汁的には良くないかもしれないが、生姜とニンニクがそもそも最強なので気にしないこととする)汁が沸騰している状態で少しずつ入れると、ふわふわの良い感じになる。たまごは十分に溶いてあっても良いし、雑にやってもそれはそれで美味しい。白身のごろっとした塊とか美味しいですね？そういうことです。

生姜とニンニクが入っているので、食べ終わる頃にはポカポカしてきて、元気になる。気がする。「味噌汁」と呼ぶには強い味がするけれど、美味しいのでヨシ。

UCC Cafe@Home

Fri, 06 Oct 2023 00:45:18 +0900

先日、SCAJ というでかいコーヒーのイベントに行ってきました。面白かったモノをいくらか買ってきたのですが、そのうちの一つがUCCのCAFE@HOMEです。

どうやらインターネットで調べた感じでは現在の形でのCAFE@HOME自体は5年くらい前に発売されたものでそんなに新しい商品という感じではなさそうなのですが、今年の3月に同シリーズから新しいデカフェのものがでたということで大きく宣伝していた、ということのようです。

CAFE@HOMEはレギュラーコーヒーの粉を1杯分ごとに真空パックすることで美味しくコーヒーを飲める、という趣旨のシリーズのようです。カップに乗せて使うタイプのフィルターも付属しているので(コーヒーを淹れる道具がない人でも)気軽に美味しいコーヒーを淹れられる、小洒落たデザインで贈り物にもぴったり、という感じですね。

私は現状普通のコーヒー豆は十分すぎるほどにあるので(ちょっと消費が追いついてないくらい、サブスク加入しているため月一で追加補給される)、今回は3種類のデカフェを2つずつ、合計6個のセットを購入しました。

内容はこんな感じ:

コーヒーの他、前述の様にフィルターが付属しているのと、説明書も入っていました。

開封してフィルターをセットするとこんな感じです:

一般的にコンビニやらスーパーやらで購入できるドリップバッグと比べるとしっかりとしたフィルターで、普通の台形フィルターに似た感じで使えそうな気がしました。真空パックで香りを閉じ込めている、というだけあって、安いドリップバッグのようにフィルター部分がカップの中のお湯に浸かるような構造ではないですね。

説明書にはフィルターをカップにセットし、コーヒーを手で開封して粉を入れる、という形で書いてありますし、実際カップにセットしないと流石に安定しなさそうなので手順としてはあっているとは思うのですが、粉末が入った袋が真空パックされているということで説明書のように立てに袋を割いてきれいにフィルターに粉を入れる、というのは少し難しいように感じました。私は粉を少しカップの中にこぼしました。基本的にハサミで切った方が良さそうです。

粉は中〜粗挽きくらいでしょうか。開けた瞬間良い香りがしたので、香りを閉じ込めている、というのが実際に感じられました。普段私が挽いているのよりはちょっと粗目かな、と感じました(普段はV60とかを使っているので、細めに挽いています)が、台形フィルター用の粉としては特別粗いということもないと思います。ドリップバッグはあまり買ったことがないのですが、かすかな記憶に残るドリップバッグの粉よりも粗目に思えるので、そういう意味でも自信のようなものが感じられます。

お湯を注ぐと、まぁもちろんふくらむというほどのことはないです。

できあがりはこんな感じ。今回淹れた黄色い奴はカフェオレでも美味しい、ということなので牛乳を入れる予定で100mLのお湯で多分できあがりが80mL位だと思いますが、結構濃いめに見えますね。牛乳を入れても良い感じの色です。香りはまぁ、もちろん挽き立てに匹敵するとかそういうことは無いんですが、それでも牛乳を入れてもまだちゃんとコーヒーの味・香りがする感じで、悪くないと思います。

デカフェのコーヒーは正直そんなに美味しいものは多くない(香りがない、よりは、デカフェだな、という味がする)という印象がありますが、少なくとも牛乳を入れて飲んだ感じは割と悪くないです。

10g260円なので100g2600円と日常使いのコーヒーとしては高いですが、ドリッパー付きで手軽にコーヒーが淹れられるし、パッケージはおしゃれだし、という点も含めて、贈り物としてはアリだと思います。興味がある人は横浜か吉祥寺の店舗、またはCOFFEE STYLE UCC ONLINE SHOP で買えるようです。

所属がLINEヤフー株式会社になりました

Sun, 01 Oct 2023 23:10:05 +0900

転職タグはつけたものの転職ではないです。

2023-10-01を以て所属がLINE株式会社からLINEヤフー株式会社に変わりました。

以上です。

y-or-n for kill modified buffer

Tue, 26 Sep 2023 23:13:06 +0900

emacs 29.1はuse-packageやeglotの同梱、tree-sitterのネイティブサポートなどが大きな変更として話題ですが、他にも非常に多くの変更があります。

そのうちの一つが、変更が加えられた後保存されていないbufferをkillしようとしたときの質問です。これまで、編集があるbufferのkillはyesまたはnoの二択でしたが、第三の選択肢、save and then killが加えられました。

もともと(fset 'yes-or-no-p 'y-or-n-p)としてyまたはnで返事をすることが記憶された私の体はこれに順応することができず、毎回yで止まってしまいます。そこでこれを再びy-or-nに置き換える方法を探したのですが、まだまだみんなemacs 29.1を使っていないのか、情報が全然ありませんでした。しかし(多分)唯一の記事として、Kill Unsaved Emacs Buffers UX: Replacing Yes/No/Save with Meaningful Options というブログ記事を見つけました。この記事は単純にy-or-nにするのではなく、もう少し踏み込んでいるのですが、それはさておき、これによるとkill-buffer--possibly-save という関数で実装されているようです。 adviceをしても良いけれど、できれば関数全体をコピペして置き換えるみたいなことはやりたくないがどうしたモノか、と思っていたところ、use-short-answersという、何やらよさげな変数名が目に入りました。

describe-variableで説明を見てみると、non-nilの時にyes-or-no-pの代わりにy-or-n-pを使うための変数、ということらしいということが分かりました(どうやら28.1で導入された様子。知らなかった)。(setq use-short-answers t)として試したところ、上手い具合にy/n/sで確定できるようになりましたので、正解だったようです。

yes-or-no-pの説明を確認してみても、

If the ‘use-short-answers’ variable is non-nil, instead of asking for “yes” or “no”, this function will ask for “y” or “n”.

と書いてありました。

というわけで、(fset 'yes-or-no-p 'y-or-n-p)を(setq use-short-answers t)に置き換えて解決、という感じでした。めでたしめでたし。

Exa to Eza

Mon, 18 Sep 2023 21:26:50 +0900

2020年にexaをインストールしてから、3年半弱lsの代わりとしてexaを使用してきました。設定としては以下のような感じで、exaに何やらオプションを足した奴をlsのエイリアスとして、追加でll、la、llaを設定している感じです:

1
2
3
4


alias ls="exa -Fgh --git --time-style=long-iso"
alias la="ls -a"
alias ll="ls -l"
alias lla="ls -la"

で、不定期でやってるローカルのツール更新というか、brew update && brew outdatedをしたところ、exaのバージョンが(なんかよく分からない感じで)上がっていたので更新内容をチェックしに行ったところ、exa is unmaintained, please use the active fork eza instead というコミットが打たれていて、eza を見に行ったら実際活発に開発されていて、7月末からすでに10回のリリースが行われているようでした。個人的にはexaで困ってはいなかったモノの、2年以上リリースが打たれていないのも事実ですし、ezaのリリースノートを見る限りセキュリティフィックスなどもあるようなので、置き換えをしました。

手順

brew install eza
sed -ie 's/exa/eza/' .zshrc
brew uninstall exa

今のところ特に使用感は変わった感じはしないですが、一つだけ気づいたのはsymlinkのサイズ表示が変わったくらいですかね。

Migrate Helm to Vertico Stack

Sun, 10 Sep 2023 19:48:46 +0900

世の流れ的には、HelmといえばKubernetes用のパッケージマネージャーを思い浮かべる人が多いと思いますが、私にとってはHelmといえばやはりemacsのパッケージを思い浮かべます。emacs-helm(以下helm)は所謂fuzzy finder的なモノの一種で、emacsを使っていない人は雑にfzfとかpecoみたいな絞り込みをemacsでできるようにするやつ、と思えば想像しやすいと思います。

helmはなかなか歴史の長いパッケージで、2012年5月15日にanything.elからForkをしたというコミットが打たれています。私個人としては2015年7月にhelmを導入したっぽい記録(commit /tweet )が残っています。そこから数日前まで、かれこれ8年余りの期間にわたってhelmを使ってきました。使ってきた、とは言っても導入したときに多少使い勝手の調整をして以来、ほとんど設定は変えておらず、機能的にもhelm-M-x、helm-find-files、helm-show-kill-ring、helm-buffers-listくらいしか使っていませんでした。基本的にはMELPAからインストールされる最新版を使っていたのですが、8年使っていてもアップデートで壊れた記憶は多分1回くらいしかなくて、かなりの頻度でコミットが打たれているのに安定していた、という印象があります。

8年の間にも、Ivy/Counsel が話題になったり、icomplete-vertical-mode/fido-vertical-modeという補完UIが標準に追加されたりと、いろいろと流行が変わっていたのは認識はしていたのですが、まぁなんやかんやあり8年間helmを使い続けてきました。

そうこうしていたところ、最近emacs 29.1がリリースされ、同じく長らく使用してきたuse-package (どのタイミングで導入したのかは不明ですが、GitHub上でのfirst commit で既に導入済みだったっぽいのでhelmより長く使っていることになります)がemacs標準搭載となりました。use-package以外のパッケージに関する設定はuse-packageを使ってやっていて、他のパッケージがインストールされていないときにインストールするというのもuse-packageでやっていて、という感じなのですが、そうなるとuse-packageは誰が入れてくれるんだ、ということになり結局use-packageだけはpackage-installを直接呼び出すことでインストールしていたのですが、use-packageがbuilt-inとなったことで、晴れてpackage-installの直接呼び出しも不要となりました。その変更ついでに、いろいろと設定を見直したりとか、ローカルでのみ設定されていた諸諸をGitHubにpushしたりとか、そんなことをやったのですが、その一環として(?)helmからvertico に乗り換えてみました。

helmからverticoに移行して一番の大きな違いは、helmはそれ自体が巨大パッケージで、いろいろなモノがhelmでまかなわれていましたが、verticoはそれ自体はかなり小さく保たれていて、いろいろなパッケージを組み合わせることで同じような機能を実現する、というところです。個人的にはでかいフレームワークより小さいライブラリ類を組み合わせてアプリを書く方が好きなので、そういった意味でもverticoは好きになることができそうです。

今のところ組み合わせているものはmarginalia とorderless の二つ。

marginaliaはminibuffer completionに何やら情報を足すやつでM-xでコマンドの簡単な説明が見られたり、find-fileでファイルのパーミッションやら最終更新時間やらが見られるようになります。インストールしただけでも情報が見れるようになって便利なのですが、そのままだとファイルの更新時間が2023 Sep 10みたいなかんじで月名を使った表示になっており、分からなくはないんですけど日本人としてはやはり2023-09-10と数字を使って表現してくれた方がぱっと見でわかりやすいので、次の様にadviceでmarginalia--time-absoluteを置き換えることで数字表記に修正しました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


(defun marginalia--time-absolute--month-number (time)
 "Format TIME as an absolute age but use month number instead of month name."
 (let ((system-time-locale "C"))
 (format-time-string
 (if (> (decoded-time-year (decode-time (current-time)))
 (decoded-time-year (decode-time time)))
 " %Y-%m-%d"
 "%m-%d %H:%M")
 time)))
(advice-add 'marginalia--time-absolute :override #'marginalia--time-absolute--month-number)

orderlessは候補の絞り込みをするときに、完全一致や前方一致だけでなく、fuzzy matchをしてくれるようになるやつで、たとえばabcと入力するとa.*b.*c.*にマッチする奴を返してくれるようになります(多分これは触らないと便利さはわかりにくい・・・)。

梅仕事2023

Mon, 12 Jun 2023 14:14:25 +0900

皆さん、6月です。6月と言えば、そう、梅の季節ですね。今年もあちこちで梅が売られており、例に漏れず買ってきて梅酒を漬けました。今年はちょっと面倒な気持ちになったので、梅シロップは作らない予定です。

昨年の梅酒はこんな感じです。昨年は黒糖を使って漬けたため、色がすごいことになっています。味見をしたところ、もう少し熟成感というか、まろやかになるといいな、という感じでした。

今年は見てのとおり透明です。ここ数年は日本酒を使ったり、泡盛を使ったり、黒糖を使ったりと変わり種の梅酒を漬け続けていましたので、今年はホワイトリカー、氷砂糖という至って普通のレシピで作りました。

また来年お会いしましょう

Fellow Ode Gen2を買った

Thu, 11 May 2023 22:00:00 +0900

みなさん、コーヒーは好きですか。私は豆でコーヒーを買ってくる位には好きで、ミルで豆を挽いてコーヒーメーカーで雑に淹れる、という感じでやっております。

扨、そんな私ですがこれまでコーヒーミルはメリタのパーフェクトタッチIIという電動ミルを使っていました。

これは大学生の時に買ったやつで、掃除もろくにしないで雑に使っていたため、かなりひどい見た目になっていますね。定価は多分12,000円くらい？で、当時ビックカメラあたりで5,000円くらいで購入しました。電動ミルとしてはかなり手頃な値段で買える割にプロペラ式ではない(プロペラ式のミルは安いけど引いた後の粉の粒度が安定しない)ミルということで、私のコーヒー生活をかなり豊かにしてくれたと思っています。

とはいえ値段なりの問題はいくつかあって、最大の問題は微粉と静電気でした。すごく微粉が出るし(微粉が多いと雑味が多くなる、と言われている)、粉受けがプラスチックなので静電気で粉受けの内側にくっつく、ダマになる、挙げ句粉受けの外も粉だらけになるという感じでした。エントリーモデルとしては最高だと思うんですけどね。

まぁそんなわけで毎回キッチンをコーヒーだらけにするのがストレスだなー、良いミルが欲しいなー、と思っていたところ、Fellowという会社からの最新ミルであるODE Gen2というミルが日本でも発売になるということで予約して購入しました。値段は61,600円。高いですね。私はちょうどボーナスが出たので高いなーと思いながらポチりました。

参考にしたレビュー動画はこちらです:

このミルの何が一番良いかというと、静電気防止機能とノッカーがついているところで、前述の通り静電気が主なストレスの原因だったのと、粉を落としきるためにパーフェクトタッチを叩いていたので、ノッカーがあるのはすごくいいと感じました。

販売ページはこちら: Fellow ODE Brew Grinder Gen 2

届いたモノがこちら:

まず、デザインが良いですよね。安っぽさを感じさせないですし、大きなダイヤルが使いやすそうです。

挽いた粉を比較してみましょう。

黄色い皿に入っている方がパーフェクトタッチIIで挽いた粉です。微粉が静電気でダマになっているのが見て取れますし、静電気で皿の壁面に細かい粉がついてしまっています。一方ODE Gen2で挽いた粉は粒度が一定で、静電気もひどくありません。まぁ、(定価ベースで)値段が6倍くらい違うので、同じ結果では困るのですが・・・

粉受けも見てみましょう。

粉受けにもほとんど粉が残っていません。良いですね。

スペック的には、フレンチプレスで使えるくらいの粗い挽き目から、マキネッタ用にもなんとか使えるかな、位の範囲で挽けるようです。

以上です。

YAPC::Kyoto 2023に参加してきた

Tue, 21 Mar 2023 00:54:00 +0900

COVID-19の影響を受け多くのテックカンファレンスがオンラインのみの開催となり、数年ぶりにオフラインのテックカンファレンス、YAPC::Kyoto 2023 に参加しました。 YAPC::Kyotoは2020年に開催予定だったものの、COVID-19の影響で開催を延期していましたが、今年ようやく、YAPC::Kyoto 2023として開催されました。

YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。

京都はおそらくOSC 2018 Kyoto 以来で、約5年ぶりに京都に来た、という感じです。今回はちゃんと会場であるKRP近くの東横イン(東横イン京都五条大宮)を確保することに成功し、前日祭の前日夜に京都に着き、本祭の翌日夜に東京に帰るというスケジュールでした。

初日は到着が遅かったこともあり、深夜に#yapcramen することとなりました。

#yapcjapan #yapcramen https://t.co/xjNb09VCXW pic.twitter.com/uAcIisYkGG
— nasa9084@某某某某(0x1f) (@nasa9084) March 17, 2023

YAPC::Kyoto 2023 前日祭

マスクの着用は当人の判断に委ねる、という発表が政府からあったものの、まだまだ感染が気になる今日この頃、今回のYAPCでは前夜祭ではなく前日祭という形で前日イベントが開催されました。ボケボケしていたらチケットがすべてはけてしまっており、当日になってもキャンセルがなかったので仕方ないから京都観光でもするか、と京都駅〜四条付近をうろついていたら参加率的に補欠全員繰り上げ、という連絡が運営からあったため途中からではあるものの前日祭に参加しました。

なお昼ご飯は蕎麦の実よしむらでそばづくし膳とそば茶クリームプリンを食べました。

pic.twitter.com/nbEJmygDYb
— nasa9084@某某某某(0x1f) (@nasa9084) March 18, 2023

客単価あげていこうな pic.twitter.com/6zKjaRyFqK
— nasa9084@某某某某(0x1f) (@nasa9084) March 18, 2023

参加したのは東西対抗LTマッチからだったんですが、LTというモノを見るのも久々でしたし、LTは初めてという人が多数LTをしていてなかなか良かったですね。LTでも容赦なく@dankogai sanからコメントが入るのはこれがオフラインのYAPCだ！！という感じでした。

心に残った一言は「数の暴力にはオートスケールは無意味」です。

「数の暴力にはオートスケールは無意味」わかる #yapcjapan
— nasa9084@某某某某(0x1f) (@nasa9084) March 18, 2023

終わった後は@gomaaburamax や@tomio2480 、学生たちと飲みに行ったり、さらにははしご酒で@sweet_potato_hs と飲みに行ったりしました。

YAPC::Kyoto 2023

今回はなんと(!)寝坊をしなかったためオープニングから参加することができました。めでたし、めでたし。

#yapcramen pic.twitter.com/GLVTpUlqcH
— nasa9084@某某某某(0x1f) (@nasa9084) March 19, 2023

やはり印象に残ったトークは@moznion sanのソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死すですね。ゲストトークなためベストトークに投票できなかったのが残念です・・・。特に、「そして人類は廃墟を越える遺跡に出会っていくのであるが・・・」という話の後に@uzulla sanから「古墳はどうですか」などという質問が上がっていたのは面白かったです。

「古代文明の古墳はどうですか」「古墳は無理ですね、作り直しましょう」「なるほどありがとうございます！！！」#yapcjapan
— uzulla (@uzulla) March 19, 2023

皆さん金の弾丸で廃墟をなんとかしていきましょう。

Air Bangle

Tue, 21 Feb 2023 23:00:06 +0900

あけましておめでとうございます。11月頃にMakuakeで応援購入したApple watch用のバングルが届いたので開封しました。

購入したのはAir bangle のべっ甲カラーです。 Air bangleはその名の通り、世にも珍しい(?)バングル型のApple watchバンドです。鯖江のメガネ作りの技術で作られているそうです。

箱はこんな感じで、思っていたよりも高級感があります。クラウドファンディングで作られたモノはもっとがさつな袋に入ってくるものだと思っていたのですが、そうでもないようです。

中にはアダプタと本体、取扱説明書が入っていました。取説の内容はほとんどQRコードで、Apple watchへの装着方法や着け心地の調整方法などは動画で確認することができます。保証も一年ついていて安心です。

色はこんな感じ。Makuakeのページ上で見たイメージよりは濃い色に見えます。

購入したのはApple watch 38/40/41mm用のサイズ4(17〜18.5cm)です。これまではソロループのサイズ9や、ブレイデッドソロループのサイズ8がちょうどいい、と思っていた位の腕の太さです。

おまけ(?)として専用のスタンドもついています。簡単な作りではありますが木製で悪くないです。

表から見ると木目が良い感じですが、実際は突板で、裏から見るとMDF材まんまなので表からだけ見ましょう。(makuakeのページを見るとチェリー突板/MDF材、とのことです)

Apple watchに固定するプレート部分もきれいです。安モノだとこういう部分があまりきれいではなかったりするんですよね。

実際にApple watchに装着する際はこのアダプタを使用します。アダプタは購入時に黒かシルバーから選ぶことができますが、私のApple watchはミッドナイトカラーなので黒にしました。もちろん、きちんとロック部分も実装されています。

平置きタイプのドックなどは使えないと思いますが、Amazonで売っている安価な横置きタイプの充電スタンドであれば問題無く使用できます。

今回購入したべっ甲カラーはまだ正式には発売前なのでクラウドファンディングが終了した現在は購入することができませんが、第一弾で販売された3色は公式サイトから購入できるようなので、気になった人は購入してみてください。サイズは38/40/41mm Apple watch用と42/44/45mm Apple watch用でそれぞれ5サイズ展開、届いた後にサイズが合わなかった場合も無償で交換してくれるそうです。

なお、予想していたことではありますがキーボード操作をするときは邪魔になりますので、キーボード操作をするときはソロループ、外出時はAir bangleといった使い分けが必要そうです。

2022年買って良かったモノ

Sat, 17 Dec 2022 00:15:00 +0900

まぁ定番のネタですが、今年もいろいろ買ったので見ていきましょう。

車関連

Honda N-ONE
- 思ったより乗っているので、次に買い換えるときはもっとお金を掛けても良いな、という気持ち
Anker PowerDrive III Duo
- 最近はカーチャージャーもUSB-Cのが有るんですね
Anker PowerLine Ⅲ Flow USB-C & ライトニングケーブル
- 車関連ではないけど車で使っているので。絡まない
サムライプロデュース超吸水サムライタオル大判 Lサイズ
- 洗車後はこれでほぼ一発
クロックススウィフトウォーターエクスペディション
- 永遠にサンダルを履いている。これは運転用です

アクアリウム

ミナミヌマエビ
GEX グラステリアフィット 200LOW
コトブキ工芸ミニフィットフィルターMF
- 寝室で一晩中動かしてても平気なくらい静か
GEX クリアLED ピテラ
- 小さくて明るくて可愛い。神。

ゲーム

Pokémon LEGENDS アルセウス
Nintendo Switch Proコントローラー
- 勝手に動かないコントローラー、快適・・・

ガジェット類

グリーンハウス iPhone巻取り式充電ケーブル USB Type-C ライトニングケーブル
- 鞄に入れておくケーブルは巻き取り式派なんですよね
グランサンクブルーハムハム i select iPhoneケース
- ガジェットかどうかは微妙。ブルーハムハム可愛いですね
TALENANA for Apple Watch フィルム
- 柔らかくないタイプのフィルム
SwitchBot 温湿度計プラス
- APIの検証用に買っただけだったんだけど、プラスじゃない奴と比べて圧倒的に見やすい

日用品など

ビホウマスク AG抗菌+ダブルフィルタ横ワイドまっ白なやさしいマスク(個包装) 30枚入
- 別にこれ自体とかAG抗菌とかダブルフィルタとかに特別こだわりがあるわけではないけど、大きいサイズのマスクはきつくなくて良い
アイリスオーヤマ家具転倒防止伸縮棒ML ホワイト
- 今年、地震多かったですね。本棚が全然揺れなくなった
ジョイジェルタブ食洗機用洗剤
- 継続購入ではあるけれど、他の洗剤も使ってみてやっぱりこれが良くて戻ってきた
レノアリセット柔軟剤
- 完全に、ではないけど明らかにしわが少ないと思う
バルクオムシャンプー
- 高いけど匂いが好き。だけど高い

書籍

以前から継続的に購入している続き物のコミック・小説などは除く

二つのファイルの共通行(または共通しない行)を得る

Wed, 28 Sep 2022 23:59:17 +0900

例えば、サービスAでは登録されているけれどもサービスBには登録されていないユーザの一覧を得たい、という様な場合。もちろんdiffでよしなにやることもできますが、commも便利です。

例えば次の様にリストがあるとします。

サービスAのユーザーリスト(users_a.txt):

1
2
3
4
5


alice
bob
charlie
dave
oscar

サービスBのユーザーリスト(users_b.txt):

1
2
3
4
5


charlie
isaac
justin
mallory
oscar

これらに対してcommを使うと次の出力が得られます:

1
2
3
4
5
6
7
8
9


$ comm users_a.txt users_b.txt
alice
bob
 charlie
dave
 isaac
 justin
 mallory
 oscar

TABで揃えられた列がそれぞれ左から、Aにだけ存在する行、Bにだけ存在する行、Cにだけ存在する行、となっています。これだけだと別にそれほど便利ではないんですが、commはそれぞれの行を非表示にする事もできます。それぞれ、非表示にしたい行を-1 -2 -3で指定します。

Aだけに存在する行を表示する:

1
2
3
4


$ comm -23 users_a.txt users_b.txt
alice
bob
dave

両方に存在する行を表示する:

RenovateでGitHub Actionsで使っているHugoを更新する

Tue, 27 Sep 2022 01:53:45 +0900

GitHub ActionsとHugoを使用して静的サイト生成を行う場合、peaceiris/actions-hugo を使用するか、自分で適当にHugoをインストールするかのいずれかが一般的だと思います。このブログでは、セットアップ当初はpeaceiris/actions-hugoを使っていたのですが、最近debパッケージを自分でインストールする方式に切り替えました。 gohugoio/hugoのreleases から直接debパッケージを持ってきているので、peaceiris/actions-hugoとは違いlatest指定をする事ができず、Hugoの更新を手動で行う必要があり、ちょっと面倒だな〜と感じていました(しかもHugoは結構開発が活発で、更新もはやいんですよね)。

仕事のリポジトリでは最近renovateがどんどん導入されているので、これを機にrenovateを導入することにしました。

HugoのバージョンはGitHub ActionsのWorkflowファイル内にenvで指定されていて、もちろん標準状態のrenovateはこれを検知・更新してくれません。これに対応するには、regexManagers を使用します。

regexManagersは正規表現でバージョン番号を引っかけて更新してくれるmanager で、fileMatchとmatchStringsという二つの正規表現を書くことで使う事ができます。

fileMatchはその名の通り、どのファイルを監視するかを指定する正規表現で、今回はGitHub Actionsの設定ファイルを監視して欲しいので、デフォルトのgithub-actions managerが監視する正規表現をそのままコピーしてきて使用しました。

1
2
3
4


"fileMatch": [
 "^(workflow-templates|\.github\/workflows)\/[^/]+\.ya?ml$",
 "(^|\/)action\.ya?ml$"
]

matchStringsはバージョンを引っかけるための正規表現で、datasource、depName、currentValueの三つの値をキャプチャするか、datasourceTemplate、depNameTemplate、currentValueTemplateで値を指定する必要があります。datasource(datasourceTemplate)とdepName(depNameTemplate)はバージョンを比較するためのデータソースと依存の名称で、今回はGitHub上にあるgohugoio/hugoリポジトリのリリースと比較をしたいため、datasourceTemplateにgithub-releasesを、depNameTemplateにgohugoio/hugoを指定しました。currentValue(currentValueTemplate)は現在のバージョン番号を表す値で、これはGitHub Actionsの設定ファイルに書かれている値なので、matchStringsで引っかけてキャプチャします。

1
2
3
4
5


"matchStrings": [
 "HUGO_VERSION: (?<currentValue>.*)"
],
"datasourceTemplate": "github-releases",
"depNameTemplate": "gohugoio/hugo"

設定ファイル全体としては次の様になります:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


{
 "$schema": "https://docs.renovatebot.com/renovate-schema.json",
 "extends": [
 "config:base"
 ],
 "regexManagers": [
 {
 "fileMatch": [
 "^(workflow-templates|\.github\/workflows)\/[^/]+\.ya?ml$",
 "(^|\/)action\.ya?ml$"
 ],
 "matchStrings": [
 "HUGO_VERSION: (?<currentValue>.*)"
 ],
 "datasourceTemplate": "github-releases",
 "depNameTemplate": "gohugoio/hugo"
 }
 ]
}

これで無事renovateがHugoのバージョンをチェックしてくれる様になりました。めでたしめでたし。

GitHub PagesをActionsからデプロイする形式に変更した

Thu, 01 Sep 2022 01:58:19 +0900

2022年9月1日現在、このブログはmarkdownファイルからHugoを使って静的サイトを生成し、GitHub Pagesで公開しています。元々GitHub Pagesにページをデプロイするには、生成済みページを入れた専用のブランチ(一般にgh-pages)を用意するか、生成済みページを入れたディレクトリを用意するか、という二択で、いずれにせよページを生成してから生成されたページをGitHubにpushする必要がありました。前者の場合gh-pagesブランチはmainないしmasterブランチとは一切関係の無いコミット履歴となり、ぱっと見よく分からないですし、後者の場合gitのcommit logにサイト生成のコミットが入ってしまいきれいではありませんし、CIでbuild/pushをしている場合ローカルに毎回pullする必要も発生します。当サイトでもgh-pagesブランチに生成済みページをpushする運用となっていました。

ところが最近、GitHub Actionsから直接GitHub Pagesにページをデプロイできる様になったというではないですか。これは試してみるしかない、ということで設定を変更してみました。

まず、リポジトリのSettings > Pagesから、SourceをGitHub Actionsに変更します。

次に、GitHub Actionsのworkflow設定をactions/starter-workflows を参考に書き換えます。重要なのは2点で、actions/upload-pages-artifactを使って生成済みページをartifactとしてアップロードする点と、actions/deploy-pagesを使ってGitHub Pagesにデプロイをすることです。

1
2
3
4
5


steps:
 - name: Upload artifact
 uses: actions/upload-pages-artifact@v1
 with:
 path: ./public

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Grant GITHUB_TOKEN the permissions required to make a Pages deployment
permissions:
 pages: write  # to deploy to Pages
 id-token: write  # to verify the deployment originates from an appropriate source

environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}

steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@v1

多分artifactのアップロードとページのデプロイは同じJob内で実施しても問題無く動くとは思いますが、actions/deploy-pagesのREADME によると専用のJobに分けることが推奨されているようです。

梅仕事2022

Sun, 05 Jun 2022 19:45:00 +0900

皆さん、6月です。6月と言えば、そう、梅の季節ですね。今年も近所の西友で梅やらでかい瓶やらが店頭に並んでいたので買ってきました。このブログでは2020年からしか記録をつけていないのですが、成人してから毎年梅酒と梅シロップを漬けており、梅酒はほぼ手を付けていないので4L瓶が実家にも現在の家にも並んでいます。そろそろ一升瓶を入手して瓶詰めでもしようか、などと考えています。

扨、もちろん今年も梅酒/梅シロップを漬けましたので記録しておきます。今年のレシピはこちらです:

梅: 近所の西友で購入した青梅一袋。多分1kgくらい(で売ってるのが普通のはず？)
砂糖: 西表島産黒糖1kg
酒: ホワイトタカラ果実酒の季節 1.8L

昨年はかねてからやってみたかった、梅酒用の日本酒を手に入れて日本酒梅酒を漬ける、ということをやりましたので、今年は砂糖の方で変化を入れてみました。酒はこの季節どこにでも売っている果実酒用ホワイトリカーの定番、果実酒の季節です。度数は35%です。適当な焼酎で漬けても良いんですが、黒糖を使うこともあり度数が高めのモノを使った方が良いだろうと考え果実酒の季節を選びました。

梅を洗って、

水分を拭き取りながらへたを取り、砂糖と交互に積み、

酒を注ぎます

余談ですがこの黒糖、カレールゥにしか見えないのは私だけでしょうか

巷にあふれるレシピを見ると、へたのところに水分が残りやすいので注意とか、傷があったらそこから腐るので除けた方が良いとか書いてありますが、多少へたのところに水分が残ってたり傷があっても多分大丈夫です。大きな傷があるモノとか、傷のところが柔らかくなっているモノは除けておきましょう。今回は一袋の内1つだけ傷のところがすこし柔らかかったため除けました。

梅は金気を嫌う、という話が有るので私はへた取りは爪楊枝でやっています。ボウルもプラかなんかの奴で、金属製じゃない奴です。まぁ金属のボウルに入れたところでどれだけ影響があるのか分からないですが。

黒糖特有だと思うんですが、アクのようなモノが浮いてきました。

最後に、瓶に付属していたラベルに年月日とレシピを記録して貼り付けておきます

あとはしばらく数日ごとに瓶を揺すって、砂糖が溶けたら放置して3ヶ月くらい経ったら飲むことができます。1年くらい置くとなお良いでしょう。私は永遠に放置します。

続いて梅シロップを漬けます。レシピはこちら:

梅: 近所の西友で購入した青梅一袋。多分1kgだろうという想定。
砂糖: カップ印の三温糖1kg

こちらも氷砂糖のレシピが一般的だと思いますが、今年は三温糖にしてみました。店頭で今年は三温糖にしようかな、と思って買ってきたのですが、昨年も三温糖を使ったようです。まぁ良いでしょう。

酢を入れるレシピもありますが、今年は酢を入れないでやってみることにしました。

以上です。

N-ONEを買いました

Sat, 28 May 2022 23:57:21 +0900

標題のとおりです。N-ONEを買いました。現行の新型N-ONEではなく、前期型のN-ONEです。グレードはツアラーで、ターボ、パドルシフト、クルーズコントロールなどがついています。納車時走行距離は46,710kmでした。

5月21日(土)に納車、今日車祓をしてもらってきました。

以上。

Kustomizeのimages transformerをCustomResourceでも使う

Wed, 25 May 2022 18:19:05 +0900

皆さんはKustomizeのimages transformerは使っていますか？kustomization.yamlに書く、こういうやつです:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - deployment.yaml

images:
 - name: old-image
 newName: new-image
 newTag: v1.0.0

kustomization.yamlにこのimages:というブロックを書くと、deployment.yamlでimage: old-imageと書かれている部分がimage: new-image:v1.0.0に置き換えられます。これがimages transformerと呼ばれるもので、kustomizeのドキュメントではImageTagTransformer のところとか、exampleのimages transformer のところとかに説明が書いてあります。

扨、Kubernetesの大きな強みの一つとして、CustomResourceDefinitionを使用して独自のリソースを作成することができる、というものがあります。世の中にはいろいろなOSS CRDがありますが、今回話題にしたいのはDeploymentなどのようにコンテナイメージを指定するタイプのCustomResourceです。例えば、Argo WorkflowsのWorkflowリソースでは次の様にイメージを指定します:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
 name: batchjob
spec:
 entrypoint: main
 templates:
 - name: main
 container:
 image: old-image

しかしこの場合、kustomization.yamlでイメージを指定しても、old-imageを置き換えてくれません。

BlogカードShortcodeを実装した

Fri, 29 Apr 2022 15:26:59 +0900

例えば、はてなブログだとブログカードと呼ばれるこういうの:

が有ったり、wordpressだとプラグインでこういうの:

が有り、リンクをなんだか良い感じに表示してくれます。このブログでつい先日まで使っていたGhostでも、こういうの:

が有りました。

一方、現在使っているHugoには標準機能でこういったものを表示する機能はありません(twitterとかYoutubeはあるんですけど・・・)。しかし、無ければ作れば良いじゃない、ができるのがHugoの良いところです。

Hugoにはshortcode という機能があり、例えば標準のtwitter shortcodeだと、

{{< tweet user="nasa9084" id="1519598305554362370" >}}

と書くと

牛乳はさ、牛乳-like飲物よりうまいんだよな
— nasa9084@某某某某(0x1f) (@nasa9084) April 28, 2022

の様に展開されます。なので今回は

{{< web-embed url="https://example.com" >}}

というshortcodeを作ってみようと思います。調べてみると同様の実装をしている人もいましたので、それを参考にしつつ実装していきます。

まず、URLからデータを取得してくるにはHugoのgetJSON を使うと良さそうです。残念ながらOGP情報などを取得する方法は用意されていないようなので、指定したURLからOGP情報をとってきてJSONとして返す様なプロキシ的なサーバが必要そうです。cloud functions for firebase + javascript で実装している人もいれば、Netlify Functions + javascript でやっている人もいるという感じでしたが、やはり個人的にはGoがシュッと読み書きできて早いし、Cloud Functionsなどで常時稼働させておくには認証とかのことも考える必要がありありそう(まぁ無くてもいいっちゃいいけど、よくわからん踏み台にされても面白くない)で面倒だな、ということでちょっと困ったんですが、OGPプロキシサーバは特に状態を持っておらず、hugo buildする間だけ存在してくれればいいので、GitHub Actionsのサービスコンテナとしてプロキシを動かすことにしました。ローカルでテストビルドするときもdocker runすれば良いだけなので簡単です。

ハンドラの実装は次の通りです:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


url := r.URL.Query().Get("url")
if url == "" {
 http.Error(w, `{"message": "url parameter is required"}`, http.StatusBadRequest)
 return
}
log.Printf("request URL: %s", url)

ogp, err := opengraph.Fetch(url)
if err != nil {
 http.Error(w, fmt.Sprintf(`{"message": "error fetching OGP", "error": "%s"}`, err.Error()), http.StatusInternalServerError)
 return
}

if err := ogp.ToAbs(); err != nil {
 http.Error(w, fmt.Sprintf(`{"message": "error converting relative URLs to absolute URLs", "error": "%s"}`, err.Error()), http.StatusInternalServerError)
 return
}

var body bytes.Buffer
if err := json.NewEncoder(&body).Encode(ogp); err != nil {
 http.Error(w, fmt.Sprintf(`{"message": "error encoding OGP info to JSON", "error": "%s"}`, err.Error()), http.StatusInternalServerError)
 return
}

w.WriteHeader(http.StatusOK)
body.WriteTo(w)

コード全体はここにあります。リポジトリを作ったときにhugo用のディレクトリをルートディレクトリではなく一段掘ったサブディレクトリにしておいたおかげで気軽にディレクトリを追加できたので良かったですね。

Migrate Ghost to Hugo

Sat, 23 Apr 2022 02:52:34 +0900

いつの頃からだったか、もう記憶もあやふやではあるけれど、ブログプラットフォームとしてGhost を使っていた。twitter を見る限り、2017年の11月頃には既にGhostを使っていて、確かこの時はDockerでセットアップしていた様な記憶がある。

Ghost、すごい勢いでアップデートされてってて結構アプデが手間
— nasa9084@某某某某(0x1f) (@nasa9084) November 9, 2017

Ghostは結構更新が頻繁で、特にdocker-composeとかも使わずに運用していたので(使っても良かったんだけど、当時はDBもsqliteを使っていてコンテナ一つと永続ボリューム一つ、という単純な構成だったので使わなくて良いか、と思っていた)微妙にイメージの更新が面倒で、container-up というツールを書いてみたりもした。

その後自宅にKubernetesクラスタをセットアップしてKubernetes管理になり、データベースもMySQLに切り替え、最終的にはGCPのfree tierを使ってon VMで運用していた。 Ghostを使い始めた頃はバージョンもまだ1系だったけど、今となっては4系になって、相も変わらず活発に開発され、admin UIも大分変化した。

時代の流れとしては当然といえば当然なのだけれど、Ghost 5.0ではMySQL 8が必須となるということで、最近MySQLの更新をしたところ、頻繁に外形監視がfailする様になった。どうやらリソース不足でレスポンスを返せなくなっていたようだった。free tierのVMなのでe2-microインスタンスを使っているため、さもありなんといった感じ。

もちろん多少のお金を払ってもう少し良いVMにしても良いのだけれど、それほど頻繁に書いているわけでもないブログを運用するためだけに月数千円の出費はいかがなものか、大して書いてもいないのだから静的ページ生成でも良いのではないか、静的ページ生成ならデータベースもいらないしGitHub pagesで配信できて無料ではないか、などと思い、k8s.io でも使っているHugo に乗り換えることにした。

参考にしたのはこのページ。多少古い記事だけど多少調整すればなんとかなるだろう、と思い見切り発車した。結果なんとか移行はうまくいき、このページが表示されています。

移行手順

まず、ghostToHugo をダウンロードして、Ghostから出力したjsonファイルをHugoにインポート。(ghostToHugoはDarwin_x86_64のバイナリを使ったけど、apple siliconのmacOSでもrosettaで普通に問題無く動いた)

1

$ ./ghostToHugo -p blog.web-apps.tech something-tech.ghost.2022-04-22-02-57-56.json

Google Cloud Storageにアップロードしていたバックアップから画像ファイルを取り出してimagesディレクトリに配置した。

1

$ cp ${PATH_TO_BACKUP}/content/images ./blog.web-apps.tech/images

イメージのパスをちょっと調整。

1
2


$ find . -name '*.md' | xargs sed -ie 's/__GHOST_URL__//g'
$ find . -name '*.md' | xargs sed -ie 's/\/content\/images\//\/images\//g'

front-matterをYAMLに変更。

1
2
3


$ cd blog.web-apps.tech
$ hugo convert toYAML
$ cd ../

そのままではすべての記事が年のディレクトリ以下にまとまって入っていて画像管理が大変そうなので次のスクリプトで構成変更。

GitHubがgit://を無効にした件

Sun, 20 Mar 2022 14:14:15 +0000

TL;DR

GitHubからgitプロトコル(git://github.comで始まるURL)でgit cloneする設定になっている人が居たらSSHプロトコル(git@github.comで始まるURL)を使うように設定変更しましょう

wez/weztermという端末エミュレータを知って、使ってみようかと思い、ドキュメントに従ってbrew tapしたときのことでした。次の様なエラーが発生して、tapできません。

$ brew tap wez/wezterm
==> Tapping wez/wezterm
Cloning into '/opt/homebrew/Library/Taps/wez/homebrew-wezterm'...
fatal: remote error:
The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.
Error: Failure while executing; `git clone https://github.com/wez/homebrew-wezterm /opt/homebrew/Library/Taps/wez/homebrew-wezterm --origin=origin --template=` exited with 128.

指定された記事を見てみると、git://で始まるURLでのアクセス==gitプロトコルでのアクセスを無効化したようです。自分の.gitconfigを見てみると、確かに https://github.com の代わりに git://github.com を使うという設定がされています。

[url "git@github.com:"]
pushInsteadOf = git://github.com/
pushInsteadOf = https://github.com/
[url "git://github.com/"]
insteadOf = https://github.com/

GitHubによるとこれまでもgitプロトコルでのアクセスは読み取り専用だったようですが、ご丁寧にpushInsteadOfで git@github.com を使用するという設定まで書かれているので、これまで問題無く使えてしまっていたようです。自分でもなぜこういう設定にしたのか記憶にないのですが、これは単にSSHプロトコルを使用すれば良いだけ、ということのようでしたので修正しました。

[url "git@github.com:"]
insteadOf = https://github.com/

GitHubの想定としてもどうせread-onlyだから使っている人なんてほとんどいないだろう、ということで引っかかる人も居ないでしょうが、メモとして残しておきます。

Retrospective: 2021

Thu, 30 Dec 2021 02:00:00 +0000

1月

動画編集がちょっと楽しくなってきた頃で、毎日AmongUsの動画を作って上げてた。AmongUsやるDiscord鯖を作ったのもこのあたり。DaVinci Resolveでモーショングラフィックスやり始めてみてめっちゃ楽しかった。

案外それっぽいモーショングラフィックスとか作れるもんだなーと思うなど https://t.co/mhuQFVErv4
— nasa9084@某某某某(0x1b) (@nasa9084) January 23, 2021

この時期に買ったコミックスでまどろみバーメイドが面白いです。kindle unlimited加入者は5巻まで読めるので読んでください。特にお酒が好きな人。

nasa9084/broadcast-memo リポジトリを作った。

2月

Switchbot APIを発見したのでnasa9084/go-switchbot を作った。相変わらず動画は毎日アップしてた。

それ以外はまぁ特になし

3月

オフィス移転して、新宿から四谷になった。まぁ、目下リモートワークであんまり影響はなし。

異動乃至転職をしよう、と割と真剣に考え始めた。チーム内で真面目にやろうとしてる人を見て面倒だなって感じてしまったので、チームから心が離れてるな、と強く自覚したのが理由。

ergodash2台目(bluetooth化)を作った。今も使ってます。

nasa9084/switchbot-exporter を書いたけど、あんまり見てない。

この辺で動画投稿ペースは落ちてきた。

4月

笑顔のたえない職場ですというコミックスが面白いです。

スピーカーを買い、モニタを増設し、大体今のデスク環境が整ったのがこの辺。

5月

バイオリンを買った。結局練習は続いていません。Ankerの新製品であるところのwebカメラを買って、最近のwebカメラってこんなに画質いいんだ！と驚いたり。

社でやったゴールデンウィーク自由研究発表会で良かった発表ランキング1位を獲得した。なお内容は各社の牛乳でヨーグルトを作って比較してみたという内容でした。

LINE MOBILEからLINEMOに乗り換えた。メイン回線は変わらずiij mio。

6月

UNDERTALEめっちゃ面白かった。

7月

1回目の新型コロナウイルスワクチンを接種した。

8月

2回目の新型コロナウイルスワクチンを接種した。

異世界失格が面白いです。

Huawei Band 6を買って、割と満足はしてた。が、今はapple watchに乗り換えてしまったので使ってない。南無。プール行ったときだけ使ってます。

なんだかんだ真面目に仕事をしてました。

9月

iPhone 13 miniとiPad miniを買いました。iPhoneは9年ぶりです。

10月

Engineering Infrastructure室からLINE Platform Developmentセンター1 Communication and Service Integration室のSREチームに異動しました。使ってる技術も、業務知識もガラッと変わったので何も分からなくなりました。今も何も分からん。

社内のエンジニアレベルも上がり、昇給し、異動前にやってた業務がきちんと評価してもらえた事がわかりめでたしめでたし。

あとはapple watch買いました。

11月

LINEスタンプを作り始めた。iPad Proはこのために買った(が1年放置してた)。皆さんスタンプ買って下さい。

かんたんないきもの - LINE スタンプ | LINE STORE

たまに使えるかも知れない、ゆるふわかんたんな形の生き物(?)です

まぁまぁ使えそう - LINE スタンプ | LINE STORE

たぶん、まぁまぁ使えそうなスタンプです

とにかく帰りたい - LINE スタンプ | LINE STORE

とにかく帰りたい人の為のスタンプ

うちでよく使いそうなスタンプ - LINE スタンプ | LINE STORE

我が家では割とよく使われそうな雰囲気のスタンプ

丸い目をした奴ら - LINE スタンプ | LINE STORE

奴らは丸い目をしている

初めてエアコンの清掃業者を頼んだりした。正直思ってたよりきれいになってかび臭さも一切なくなったので、清掃頼んだことない人はやった方が良い。

ansible.builtin.fileのmodeパラメータは頭に0が必要

Mon, 13 Dec 2021 10:45:28 +0000

多分ほとんどのケースでは気にすることもなく0755とか0644とか書くと思うんですが、特殊な属性を付ける必要があるときに困るよ、という話。

世の中にはSUIDとかSGIDとかスティッキービットとかいう、特殊な属性がありまして、例えば基本のファイルパーミッションが0755でSUIDを指定したいという場合はchmodで言うとchmod 4755 path/to/fileといった感じになるんですけれども、ansible.builtin.fileのmodeパラメータでは以下の様に書くとパーサが10進数として解釈して訳の分からんことになってしまいます。

1
2
3


ansible.builtin.file:
 path: path/to/file
 mode: 4755

これはこう書く必要があります:

1
2
3


ansible.builtin.file:
 path: path/to/file
 mode: 04755

もしくはこう:

1
2
3


ansible.builtin.file:
 path: path/to/file
 mode: '4755'

これは例えば、結構古いAnsible playbookなんかで、

1

file: path=path/to/file mode=4755

とか書いていたやつを書き直したりしたときに注意が必要です。

まぁ、公式ドキュメントに書いてあるんですけど、そうは言ってもみんなそんなに細かいところまで読んでないでしょ、という。

You must either add a leading zero so that Ansible’s YAML parser knows it is an octal number (like 0644 or 01777) or quote it (like ‘644’ or ‘1777’) so Ansible receives a string and can do its own conversion from string into number.

人生初Apple Watch (series 7)

Tue, 19 Oct 2021 23:49:46 +0000

これまで私は基本的にAndroid端末を使うことが多く、初めて持ったスマートフォンであるGalaxy Sを始め、ほとんどのスマホ人生をAndroid端末とともに歩んできました。これまで最初で最後のiPhone端末はiPhone 5のみで、今回iPhone 13 miniを購入したのは8年ぶりの事です。 Androidユーザであったために買えなかったAppleデバイス、それがApple Watchです。Androidデバイスでも使えるスマートウォッチはもちろんあります。私もfitbit Versa を使っていました。しかし、Apple Watchには遠く及びません。iDでの決裁もできない(現行のfitbit Versa 3/Senseはsuicaには対応している)し、何よりソロループがありません。一日の大半をPCに向かってキーボードをカチャカチャするという虚業に従事していますから、時計のバックルというのは結構いづい(注：大半の人に伝わらない表現なのは理解しているけど他の表現がない)のです。

そんな私もiPhoneを買ったことによりApple Watchが買える！という事でApple Watch series 7を購入しました。

iPad mini 6を買って1週間半経った

Tue, 19 Oct 2021 23:29:54 +0000

みんなが待ってたiPad。そうiPad miniです。私は過去に会社のお下がりでもらったiPad mini第2世代を使っていたことがありますが、その後iPad Pro 第一世代(2018)に買い換え、今に至ります。Youtubeや読書に使用するにはちょっと大きいな、と思いつつ、なんだかんだ便利に使ったり使わなかったりしていました。iPad miniは良いサイズだったな、なんて思いながら。とはいえ、iPad Proのベゼルレスデザインを体感すると、(ちょっとダサい)従来のiPad miniに戻る気にはなれず、ベゼルレスデザインのiPad miniがでたら買おうと思っていました。

そして今年、第六世代iPad miniとしてベゼルレスデザインのモノが発売されたので購入しました。なんだかんだ安くはないので、一晩悩んだ結果発売日に入手することはできず、10月9日到着でした。

今回購入したのはスペースグレイのiPad mini 第六世代 Wi-Fi + Cellularモデル、ストレージは256GBです。iPad Proも256GBのモノを使用していて、ストレージが大きく余っているので正直256GBは多すぎると思ったのですが、64GBか256GBという二つの選択肢を考えたとき、64GBは流石に小さすぎるだろう、と考え256GBを選択しました。MacBook Proですら256でストレージが余っている(最近ゲーム実況動画編集をするようになって、動画の為に外付けSSDを買ったけど)ため、iPad miniのストレージも枯渇することはおそらく無いと思います。

ケースは安定の公式Smart Folioを購入。iPad Pro用のモノとは異なり、アップルのロゴがエンボス加工されています。これはこれで良いですね。

iPad Proとサイズを比較するとこんな感じ。ざっくり半分くらいの大きさです。身長176センチ(最近1センチほど伸びました)の私だと片手でホールドできるくらいのサイズ感です。

著作権的なアレをアレするためモザイクをかけていますが、マンガを読むのに非常にちょうど良いサイズです。おそらく小説やビジネス書など、他の書籍にも良いでしょう(技術書は大判の事も多いしiPad Proの方が読みやすいかも知れない)

本機はiPad Airと同じくtouch IDですが、個人的にはiPadはface IDの方が良いかな、という気がしました。家の中で使うことが多い端末ですから、マスクをしている事も無いため、face IDの方がボタンに指を持っていくという動作が不要なため便利です。また、これは慣れの問題もあるとは思いますが、ボリュームボタンが画面左上部(ランドスケープでは左下)というのは少し操作しづらいように感じました。これはiPad Proとボタンの位置が違うから戸惑っているだけかも知れません。画面の向きによってボタンの方向が変わる(右側、上側が+になる)のは直感的で良いので、iPad Proにもバックポート(?)してほしいものです。

DroneCIでパイプライン全体をfailさせずに後続のジョブを停止する

Mon, 18 Oct 2021 07:38:35 +0000

例えばmono repoで特定のディレクトリに変更があったときにだけジョブを実行したい、という様なケース。DroneCIのconditionはディレクトリ単位での変更でステップを実行するかという分岐はできません。かといってfailさせてしまうと、対象のディレクトリに変更がない場合はいつもfailする事になり、実際に問題があってfailしているのかどうなのか分からない、という事態に陥ります。

そんなときは exit 78 すると良いようです。 exit 78 したステップはsuccess、後続のステップは実行されず、(depends_on で設定しているような)後続のパイプラインは実行されます。

Reference

How to exit a Pipeline early without Failing

iPhone 13 miniを買った

Sun, 26 Sep 2021 13:19:01 +0000

新型コロナウイルス感染症ワクチンの副反応(ということにした)で、iPhone 13 miniを購入しました。色はミッドナイトで、128GBのモデルです。日々のご飯の写真くらいしか写真は撮らないし、大きいスマホは好きになれないのでminiを選択しました。これまで使用していたPixel 4が64GBのモデルだったので、ストレージは倍になったことになります。AppleCare+ 盗難・紛失プラン for iPhone 13 miniもつけて、107,600円でした。最後にiPhoneを使っていたのはiPhone 5なので、実に8年ぶりくらいのiPhoneです。

iPad miniも買いましたが、買うかどうか一晩悩んだ結果発売日に届きませんでした。

以下開封写真です:

bashのhere-documentは一時ファイルを作成するらしい

Wed, 08 Sep 2021 09:33:25 +0000

皆さん使ってますか、here-document。bashでいうとこういう奴:

1
2
3
4
5
6


cat <<EOF
this
is
here
document
EOF

出力はこう:

this
is
here
document

複数行に渡るテキストをリテラルとして表現したい場合に便利ですね。で、shellscriptからREST APIにリクエストを投げたくて、here-documentを使ってJSONをべたっとスクリプト内で書いてたんですけど、こんなエラーが出てました(パスはもちろん違いますよ。念のため。):

/path/to/shellscript/using/here-document.sh: line 179: cannot create temp file for here-document: No space left on device

全然知らなかったけど、here-documentって一時ファイルを作成するんですね。確かめてみます。

$ docker run -it --rm centos:7 bash
[root@8017e5e28d6e /]# yum install -y strace
(中略)
[root@8017e5e28d6e /]# cat <<EOF > script.sh
> cat <<EOS
> foo
> bar
> baz
> EOS
> EOF
[root@8017e5e28d6e /]# strace -f bash script.sh |& grep tmp
[pid 61] stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
[pid 61] faccessat(AT_FDCWD, "/tmp", W_OK) = 0
[pid 61] statfs("/tmp", {f_type=OVERLAYFS_SUPER_MAGIC, f_bsize=4096, f_blocks=6159700, f_bfree=4601655, f_bavail=4282999, f_files=1572864, f_ffree=1414766, f_fsid={val=[3003212711, 622231591]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
[pid 61] open("/tmp/sh-thd-1631118709", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3
[pid 61] open("/tmp/sh-thd-1631118709", O_RDONLY) = 4
[pid 61] unlink("/tmp/sh-thd-1631118709") = 0

/tmp/sh-thd-1631118709 に書き込みをしている様子が見て取れます。

Huawei Band 6を買った

Mon, 30 Aug 2021 04:12:05 +0000

TL;DR: 割と良い。

スマートウォッチは長いことfitbit versa を使用していたのですが、最近プールに行くようになり、プール内で使用できるレギュレーションに対応したスマートウォッチ/スマートバンドが欲しいと思っていました。

私が行っているプールのスマートウォッチ/スマートバンドのレギュレーションは次の様になっています:

ベルト幅が30mm以下でディスプレイがベルト幅および厚みから出ないものは使用可能
柔らかい素材のカバー等で覆えば使用可能
シリコン製カバーまたはウォッチスーツで覆えば使用可能

fitbit versaは一つ目のレギュレーションにマッチしていないため、柔らかい素材のカバー・シリコン製カバー・ウォッチスーツで覆えば使用可能、ということです。とはいえ、fitbit versaはもう2世代型落ちのモデルです。ディスプレイを覆うカバーを見つけるのがそもそも難しい(あるにはあるけど)ですし、シリコン製カバーは何故か6個単位でしか売っていないため、私の結論としてはレギュレーションにマッチするスマートバンドを買うのが早い、となりました。

じゃぁなにを買おうか、と考えたときに、私はPixelユーザですしfitbitのユーザでもありますから、Googleによるfitbitの買収を受けて、fitbitから良い感じの新製品が出るのを待ちたいという気持ちもありますから、あまりコストを掛けるわけにもいかないな、と考え、選択肢は自然とHuaweiかXiaomiの二択となりました。

いろいろ検討しましたが、最終的にはmi band 6 の丸っこいデザインより、Huawei Band 6 の四角いデザインの方が通知などが見やすそうですし、画面もほどよく大きい、という事でHuawei Band 6を選択しました。

以下開封写真です。

外箱はこんな感じ。一応amazon.co.jp販売の日本正規代理店品と書かれたモノを購入したのですが、日本語はシールで修正しているような外箱でちょっと不安な感じがあります。まぁ気にしても仕方ないでしょう。安いし。

箱を開けると本体がこんな感じで入っています。まぁわかりやすいはわかりやすいですね。

箱に入っていたものはこれで全部です。本体、充電ケーブル、WARRANTY CARD、クイックスタートガイドですね。クイックスタートガイドは本当に必要最小限の情報だけが書いてあるという感じで、詳細はWebから説明書をダウンロードしてね！という事でQRコードが書いてありました。

今のところ購入から二週間弱使用しましたが不満点は次の二つです:

HUAWEI BAND 6、お値段も含めて割と満足してるけど、保護フィルムにまともなのがなさそう（これはこのクラスのものに気を使いすぎかも）なのと、ツイートをしたときに通知が来ちゃうのが微妙ポイント
— nasa9084@某某某某(0x1b) (@nasa9084) August 27, 2021

まぁ保護フィルムはこのクラスの製品に保護フィルムをつけようというのが間違っているのかも知れませんが。ツイートをしたときに通知が来ちゃうのは、「tweetをしました」という通知が一瞬通知欄に出るためそれを認識してしまっている、という事でHuawei Band側の問題と言うよりはtwitterアプリ側の問題の様な気もしますね。

あとはまぁ、ウォッチフェイスを作ってみた、みたいなブログを書こうと思ってはいたんですが、環境のセットアップがまぁまぁめんどくさそうというか、バンドとスマホの情報同期にはHuawei Healthというアプリをスマホにインストールするんですが、ウォッチフェイスを作ってテストするにはこれのベータ版？開発版？をインストールしなければならないということなのでやめました。諦めて既製のウォッチフェイスを使うことにします。

以上です。

剥がれかけたSesame 3を貼り直す

Thu, 12 Aug 2021 13:20:12 +0000

弊宅ではCANDYHOUSEのSESAME3 というスマートロック製品を使用していて、付属の両面テープで貼るだけ、剥がすときも跡が残らず便利！という最高の製品なんですが、最近少し剥がれてきてしまいました。

電池切れや故障などの有事に備えて鍵は持って歩いているので問題ないと言えば問題ないのですが、そうは言っても不便な思いはしたくないですし、完全に剥がれてしまってからバタバタするのもイヤなので張り直しをしました。

公式から交換用の両面テープも販売されてはいるのですが、明らかに3Mのコマンドタブですし、割高っぽい印象を受けたので近所のカインズで購入してきました。(実際比較してみるとヨドバシ.comでは8枚で300円弱なのに対し、CANDYHOUSEから買うと4枚で350円と倍程度の値段設定となっています)

たまたまカインズに行ったときに思い出して適当に買ってきてしまったため私はMサイズを購入しましたが、元々ついていたモノと比べると多分Lサイズだったので皆さんはLサイズを購入すると良いです。カインズではどのサイズも値段が同じでしたが、ヨドバシ.comではLサイズが若干安いようです。

SESAME本体の形に合わせてコマンドタブをカットし、貼り付けます。剥がすときに引っ張る部分は電池ボックスの中に折り込んでおきます。

無事しっかり貼ることができました。めでたしめでたし。

aタグのping属性

Mon, 02 Aug 2021 14:55:54 +0000

私は基本的に業務・趣味の両方でGoを書いていると言うこともあり、ソースコードの管理はGOPATH方式で管理しています。しかしGOPATH方式で管理していると、ライブラリの挙動確認やらなんやらで使う書き捨てのコードをどこに置くか、という問題がある。 src/github.com/nasa9084/... に置くというのも一つの手ではあるものの、社内のGitリポジトリやらGitHubやらにアップするつもりもないコードを他の、GitHubやらなんやらで管理されているリポジトリと同じ場所に置くと一覧性や検索性が下がるし、やりたくはないので、普段はそういった直ぐにいらなくなるコードは src/practice というディレクトリに配置しています。

毎回書き殴った後に削除をする、というまめな性格はしていないので、結果として二度と日の目を見ないことがほとんどなコード片が貯まっていくので定期的にクリーンアップを行っています。書き殴りのコードとはいえ、何かヒントが残っているかもしれないので、削除前にチラチラと内容を確認しながら削除していくのですけれど、そういえばそんなの調べたな、なんて思うコード片がたまに見つかったりする訳です。

今回発見したのはタイトルにもあるとおり、aタグのping属性です。W3C発行(発行、という表現が正しいのかどうかもよく分かっていないですけど)のHTML仕様が廃止となり、WHATWGのHTML仕様、HTML Living Standardに置き換えられる、との話を6月頃に見て、なるほどなーなんてちょろっと調べて、HTML Living Standardではaタグのping属性ってのがある、という情報にたどり着き、そして実際どんな挙動なのか、とコードを書いた、という経緯だったと思います。

実際のコード片がこちら: index.html:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<!doctype html>
<html lang="en">
 <head>
 <meta charset="UTF-8"/>
 <title>Document</title>
 </head>
 <body>
 first page
 <a href="second.html" ping="http://localhost:8080/ping">second</a>
 </body>
</html>

second.html:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<!doctype html>
<html lang="en">
 <head>
 <meta charset="UTF-8"/>
 <title>Document</title>
 </head>
 <body>
 second page
 </body>
</html>

main.go:

dateコマンドで簡単な時間計算をする

Tue, 13 Jul 2021 03:52:44 +0000

shellscript内で時間計算をしたい事がある。例えば、「最終実行から10分経過していたらxxxをする」という様なケース。定期的にファイルを生成したい、といった簡単なユースケースであれば、findコマンドあたりでファイルの変更タイムスタンプを調べるといった方法でも実現可能ではあるけれど、「ファイルの中に記載された時間から10分経過しているかどうか調べる」なんて事もあるでしょう(あった)。 shellscriptで時間の計算するのって面倒そうなんだよな・・・と思っていたのですけれど、私のユースケースだとそれほど難しくなくて、dateコマンドで大体なんとかなるという事が分かったのでメモしておきます。

時間を比較する

二つの時間を比較したい。これは対象の時間がUnix時間で表現されていれば非常に簡単で、dateコマンドを使用する必要すら無く、test乃至[で普通に比較ができます。もちろん取り扱いは数字として取り扱うことになるので、比較演算子として-ltか-gtを使用します。

1
2
3
4
5
6
7
8


# 1626146220 = 2021-07-13T12:17
# 1626146340 = 2021-07-13T12:19
if [ 1626146220 -lt 1626146340 ]; then
 echo hello
fi

# Output:
# hello

対象の時間がUnix時間で表現されていない場合、Unix時間に変換して比較するのがおそらく最も簡単です。dateコマンドで一度時間をパースして、Unix時間の形で出力します。パースには-d / --dateオプションを使用します。Unix時間として出力するためのフォーマット文字は%sです。

1
2
3
4
5
6
7


if [ $(date -d '2021-07-13T12:17' +%s) -lt $(date -d '2021-07-13T12:19' +%s) ]
then
 echo hello
fi

# Output:
# hello

-d / --date オプションは一般的なフォーマットの日付文字列をよしなにパースしてくれます。詳しいフォーマットはGNU Coreutilsのマニュアルなどを見ると良いでしょう。

n分前/n分後を求める

扨、ここからが本題なのですが、n分前/n分後を計算してみましょう。といっても、dateコマンドを使用すると非常に簡単に求めることが可能です。

まずは現在時刻から1時間後を求めてみましょう。-d / --dateオプションに加算したい時間を渡すだけです。

1
2
3
4
5
6


date +%R
date -d '1 hour' +%R

# Output:
# 12:34
# 13:34

hourの他にも、yearやmonth、day、minuteなどそれっぽいモノは大体使用することができます。珍しいところだとfortnight(2週間)を使うこともできます。単に1 hourと書くのがなんとなく気持ち悪いという人はnowやtoday、thisなどを使用してより自然言語っぽい感じで書くこともできます

梅仕事2021 (2)

Fri, 18 Jun 2021 15:34:24 +0000

先だって梅シロップを漬け、既に半分以上梅シロップを消化してしまった今日この頃、大分遅くなってしまったものの今年も梅酒を仕込みました。就職で関東に出てきてから今年で4L瓶が5本目と相成りました。本年は面倒くさがっている間にあれよあれよと日が経ってしまい、近所の西友では4L瓶が買えなくなる始末でありましたがなんとか4L瓶を調達する事に成功し、無事仕込みを済ませることができました。

今年はあまり時間が無かったこともあり、梅は近所の西友で調達した南高梅(大玉)です。割と傷も少なく良い香りのする梅で、西友侮りがたし、といったところですね。おそらく1kgと思われる袋が980円(税抜)でした。

酒は今年は初めて日本酒を使用。実は以前から日本酒で梅酒を仕込むというのはやってみたいと思ってはいたのですが、通常店頭で販売されている日本酒は梅酒を仕込むには度数が足りないため、梅酒(乃至果実酒)用のものを調達する必要がある、という面倒さがあり、店頭でそういった梅酒用の日本酒が販売されているのを発見したことがなかったため、これまでは挑戦してきませんでした。今年はむやみやたらにAmazonのポイントが貯まっていたという事もあり、Amazonでいろいろと探したところ、果実酒用の日本酒が販売されていたためこちらを購入しました。

苗場酒造という酒蔵の苗場山「果実酒用日本酒」、度数が20%のものです。Amazon で本体価格が1,800円、送料が500円です。

日本酒を使うのは初めてのため、砂糖は特に奇をてらわず一般的な氷砂糖を使用しました。

作り方は特に例年と変わらず、洗ってへたを取った梅と砂糖を瓶に入れ、上から酒を注ぎ入れるだけです。日本酒の場合米の甘みがあるため砂糖は控えめで良い、という事でしたので、酒に付属してきたレシピにあわせて氷砂糖の量は500gとしました。例年は1kgで使用しているため、例年の半分です。

このあとは砂糖が溶けるまでは時々振ってあげて、砂糖が溶けたら放置です。自家製梅酒大体3ヶ月程度からが飲み頃と言われていますから、9月くらいになったら味見をして、そのあとはまた数年放置されることとなります。

最後に、昨年は2017年に漬けた梅酒を飲んで締めたようなので今年は2018年に漬けた梅酒を飲んで締めようと思います。

ラベルによると2018年は久米仙と氷砂糖を使用したようです。泡盛ですね。意外と癖もなく、飲みやすく仕上がっています。

今年の梅酒も美味しく漬かることを祈って。

梅仕事2021 (1)

Wed, 26 May 2021 07:53:09 +0000

向暑の候皆様いかがお過ごしでしょうか。近所の西友で梅酒関連の商品が店頭に並びはじめているのを見て季節を感じる今日この頃です。

例年梅酒と梅シロップを漬けるわけですが、漬けっぱなしで放置している梅酒はさておき梅シロップはできればシーズン中に二回は仕込みたい、という気持ちがあり、店頭で梅の実を発見してとりあえず購入してきました。

まだ出始めですから、まだかなり青い実ではありますが、急ぎ一発目の梅シロップを仕込みました。

手順自体は例年とそう変わるモノではなく、昨年梅シロップをつけていた空き瓶をアルコールで消毒した後、洗って水気を切りへたを取った梅の実と砂糖を交互に積んでおいておきます。昨年は中ザラ糖を使用した、との記録がありましたが今年は気分で三温糖をセレクトしました。特に深い理由はありません。三温糖はしっとりとしており、積み上げるのも容易ですし、粉末状なので隙間にも入っていきやすく取り扱いがしやすい様に感じました。氷砂糖はうまく積んでいくことを考えると意外と難しいです。

うまいこと梅を砂糖の中に埋める事ができ、上から見ると梅が出てしまっているということもありませんから、今年は酢を入れない方針で行ってみようと思います。

大粒の実が店頭に並びはじめたら梅酒も漬けたい所存です。

最近のWebカメラってすごい、の件

Sun, 16 May 2021 15:08:14 +0000

どうもAnker大好き人間です。ケーブル類は大体Ankerだし、Thunderbolt 3 Dock もAnkerだし、充電器もヘッドホンもAnkerです。

そんなAnkerから、新しくWebカメラが発売されたということで、購入したらすごかったのです。

購入したのはAnker PowerConf C300 。Amazonで7,990円で購入できます。LogicoolのStreamCam を買いたいな、と思っていたところのAnkerからの新商品、値段も半額以下、という事で即購入に至りました。

箱は最近よくあるぴったりでしっかりしたタイプの箱です。ぴったりすぎて開けるのにちょっと時間がかかる奴ですね。高級感はあります。写真ではざらざらしたかんじのテクスチャっぽく見えますが、これは印刷で、手触りはすべすべです。

これまでのAnker製品によく入っていたHappy/Not Happyカードではあんく、“WHAT DO YOU THINK OUR WORK?“というカードが入っていました。PowerConfシリーズではこの紙なんでしょうかね。ケーブルはType-C to Type-Cケーブルが付属しています。この手のWebカメラは本体からケーブルが伸びている事が多いので、ケーブル交換ができるのはとても嬉しい点ですね。

外部ディスプレイを使っていると、Webカメラは大体ディスプレイのUSBポートを使うと思うんですが、Type-CからUSB-Aに変換するためのコネクタも入っているので安心(?)です(Type-Cの仕様的には全然安心じゃないんですが)

プライバシー保護用の蓋みたいなものもついているのはなんだか時代を感じさせますね。

これまで使っていたWebカメラと並べた様子はこんな感じ。サイズは結構大きくなりましたね。

古い方のカメラで、ライトをつけないとこんな感じでした。一般的なご家庭は大体そうだと思うんですが、壁に机をくっつける配置にしていると夕方以降逆光になる、という問題があり、顔がとても暗くなります。

結果として、ライトを購入して明るさを確保したりなんかしている人も多いと思います。私もその一人でした。ライトをつければまぁもちろん明るくはなります。

新しいカメラではこの通り。ライトなしでも頭が適当にボサボサなのがバレて恥ずかしいくらいには明るく映ります。これは本当に感動。

比較用にライトをつけてみました。むしろちょっと明るすぎる位ですね。これはライトはもうお役御免かもしれません。

加えて、専用のアプリで細かい設定をする事ができます。解像度の調整、fps、画角、明るさやコントラストなどが設定できるほか、人の顔を追跡するような設定もできます。このアプリの良いところは、他のメーカーで良くあるような、常駐させておかなければ設定が反映されないような類いのモノではなく、設定したらアプリを閉じても設定が反映され続ける、というところですね。

総じて、非常に満足度が高く、コストパフォーマンスに優れた商品だと思いました。流石Anker。

RAMマウントをQi対応にする

Tue, 27 Apr 2021 03:26:23 +0000

バイク乗りの皆さん、スマホホルダーは何を使っていますか？色々と選択肢はありますが、しっかりとしたものを使いたいと考えた時、RAMマウントを使っている人も多いでしょう。

加えて、バイクからUSB電源を引いてスマホを充電している人もいるでしょう。そうした場合、どこぞに駐車をして、スマホを取り外すたびにケーブルを抜いて、また走り出すときにケーブルを挿して、というのは少しばかり面倒じゃないでしょうか？

世の中、面倒だという事柄にはそれを面倒ではなくするソリューションがあるもので、無接点充電対応のスマホホルダーなるものが販売されています。

こういったモノを購入しても良いのですが、やはりスマホをしっかりホールドしてくれるという点でできれば安心安全のRAMマウントを使い続けたい気持ちがありました。そう考えていたところ、世の中には防水仕様のQi充電器というモノが存在するという事を知りました。

正直この手のものは屋内で使うモノだと思っていたので、どういうユースケースがあって防水仕様になっているのかはよく分からないのですが、私にとっては渡りに船、幸いなことに超薄型という事なのでなおのこと私のユースケースにぴったりということで商品がこちらです

友人の@tagucch に誕生日プレゼントとして送ってもらいました。感謝。

2021-05-06追記: Pixel 4とは相性が悪かった(Pixel 4ではうまく充電できず、iPhone XRで試したら充電できた)ため、本品はiPhoneを使っている妹に譲りRAMマウントは再びQi非対応となりました。無念。iPhoneユーザは本商品で問題ないはず。多分。

扨、実際これをRAMマウントに設置できるか、というところが問題ですが・・・

RAMマウントは汎用のスマホホルダーですので、ちゃんと余裕があります！ここに適当に突っ込んでみたところ、スマホのホールド感も問題なく設置できそうです。

何故か丸い両面テープも付属していたので、おあつらえ向き、という感じで適当に両面テープで(本当は屋外用の両面テープを使った方がいいんでしょうが&屋外用の両面テープも持っては居るのですが)ぺたっと

うまく貼ることができました。これ自体は普通のUSB給電ですので、これまでケーブルを挿していたUSBポートからケーブルを抜き、代わりにQi充電器のケーブルを挿します。

キーをオンにしてスマホを設置したところ無事に充電できました。 RAMマウントは中心部分は回転しないので、スマホの取り付け・取り外しも問題ありませんでした。

めでたしめでたし。

Desk Tour 2021.04

Sun, 11 Apr 2021 15:12:31 +0000

COVID-19が猛威を振るい、自宅で勤務するようになり早一年、少しずつ機材を増やし、入れ替え、作業環境を改善してきました。自分のデスクを紹介するDesk Tourの流行も少し落ち着いたところではありますが、ここで一度デスク環境を記録がてらご紹介します。

Overview

全体像としてはこんな感じ。デスクはニトリの組み合わせフリーデスクプレフェを使用しています。天板の幅は140cmです。最近腰痛がアレでアレなので、昇降デスクにしたい気持ちがあります。写真には写っていませんが、イスはアーロンチェアを使用していて、足下にはエルゴノミクスフットレストを置いています。

ディスプレイはLG 27UK850-W という4K 27インチのディスプレイ2枚をモニターアーム(右がHP 、右がエルゴトロン。HPのものもエルゴトロンのOEM商品なのでロゴ以外は実質同じ)で設置しています。右はHDMI接続、左はDisplayPort接続でつないでいて、わざわざType-C接続のモニタを買う必要が無かったな、と思っています。

モニタの上

マイクはAKG LYRA です。USB type-Cで接続するタイプのコンデンサマイクで、AnkerのType-C to Type-Aケーブルを使用して接続しています。Rode PSA1 というマイクアームを使用して、マイクがモニタの上に来るように設置しています。マイクアームにはSwitchBot 温湿度計をくっつけています。

ウェブカメラは大昔に安く購入したバッファロー BSW20KM15 というものを使っていて、最近の良い感じのウェブカメラに買い換えたいな、と思っています。ロジクールのStreamCam とか良さそう。まぁ特に不満は感じていないですが。

日中は窓が机の奥にあるので特にライトとかは必要無いんですが、夕方になるとすぐ暗くなるのでライトも用意しました。UlanziのVL49 というライトをなんかぐねぐねするやつで設置しています。モニタ裏のアームにクリップ(の強い奴)で止めるような形です。

手元

手元はこんな感じ。トラックパッドが結構好きなので、Magic Trackpad 2 を使用しています。Magic Trackpad 2用のリストレストを使用しています。

キーボードはErgodash を使用していて、最近BLE Micro Pro で無線化しました。配線が減ってデスクの上がすっきりし、最高ですが時々接続が不安定になります。キーボード用のリストレストはFILCO Majestouch Wrist Rest “Macaron” の17mm厚を使用しています。ちょっと厚いので、12mmの方でも良かったかな、という感じ。

ゲームをするときはロジクール MX Master 3 for Mac とRazer Tartarus Pro を使ってます。Razer Synapse、Macにも対応してくれ。

スピーカーはFostex PM0.1e を最近買いました。電源ランプがまぶしすぎるのでサランネットの裏に養生テープを貼って調整しています(結果、白かったランプが緑になった)。ゲームを配信するとき等に使っているヘッドホンはSoundCore Q30 で、ヘッドホンラックにぶら下げています。。

switchbot-exporterを書いた

Tue, 23 Mar 2021 09:00:00 +0000

先だって、SwitchBot APIのGo言語用クライアント実装であるgithub.com/nasa9084/go-switchbot を書いた、という記事を書きましたが、これを使用してPrometheusでSwitchBot温湿度計の情報を収集できるswitchbot-exporter を書いてみたので紹介します。

switchbot-exporterはblackbox exporter のように、起動時にはターゲットを指定せず、Prometheusがメトリクスを収集する際にrelabel_configでターゲットを与えるタイプのexporterです。起動時に必要な情報はSwitchBotアプリから取得できるOpenTokenのみです。OpenTokenはコマンドラインオプションか、環境変数SWITCHBOT_OPENTOKEN経由で渡すことができます。

1
2
3


$ switchbot-exporter -switchbot.opentoken=blahblahblah
# or
$ SWITCHBOT_OPENTOKEN=blahblahblah switchbot-exporter

docker image も用意してありますので、例えばKubernetes上で動かすこともできます:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: switchbot-exporter
spec:
 revisionHistoryLimit: 3
 selector:
 matchLabels:
 app: switchbot-exporter
 template:
 metadata:
 labels:
 app: switchbot-exporter
 spec:
 containers:
 - name: switchbot-exporter
 image: nasa9084/switchbot-exporter:0.1.0
 ports:
 - protocol: TCP
 containerPort: 8080
 env:
 - name: SWITCHBOT_OPENTOKEN
 valueFrom:
 secretKeyRef:
 name: switchbot
 key: opentoken
---
apiVersion: v1
kind: Service
metadata:
 name: switchbot-exporter
spec:
 ports:
 - protocol: TCP
 port: 8080
 targetPort: 8080
 selector:
 app: switchbot-exporter

このようにして起動した後、README に記載のあるようにprometheusの設定をします

SwitchBot APIのGoクライアント、go-switchbotを書いた

Thu, 25 Feb 2021 03:17:53 +0000

SwitchBot は所謂IoT機器を扱っているメーカーで、温度計を専用のハブ経由でインターネットに接続し、アプリから室温を確認したり、室温によってエアコンの設定を変更する、などといったホームオートメーションに役立つガジェットを複数販売しています。

しかし、それらのデータを確認できるのはSwitchBotのアプリからか、Bluetooth経由だけ、という状況で、私もHTTPのAPIを用意してくれたら良いのに、とずっと思っていました。

ところが昨日、社のSlackで、こちらのissue を共有してもらい、どうやら昨年12月ごろにはHTTPのAPI が使えるようになっていたっぽいことが分かりました。

我が家にはHub Miniもあり、インターネットに接続してある状態ですから、早速次の手順でtokenを手に入れて試してみました:

スマホでSwitchBotのアプリを開く
プロフィールタブ > 設定と進み、アプリバージョンを10回連打する
開発者向けオプションが表示されるので、開いてトークンを取得する
Authorizationヘッダにトークンを入れ、https://api.switch-bot.com/v1.0/devices にGETでリクエストを投げてみる

結果、確かに自宅のSwitchBotデバイスの一覧を取得することができました。

こうしちゃいられねぇ！と深夜に書いたGolang用のSwitchBotクライアントがこちらです:

https://github.com/nasa9084/go-switchbot

ドキュメントはpkg.go.inなどで見て下さい: https://pkg.go.dev/github.com/nasa9084/go-switchbot 今回はFunctional Option PatternとGoogleっぽいAPIの合わせ技構成にしてみました。

例えば、デバイスの一覧を取得したい場合は次の様にすると取得することができます。

1
2
3


client := switchbot.New("SET_YOUR_SWITCHBOT_OPEN_TOKEN")

physical, virtual, _ := client.Device().List(context.Background())

第一返値のphysicalはSwitchbotデバイスの事で、第二返値のvirtualは赤外線で通信するデバイスの事です。SwitchBot APIでは、SwitchBotデバイスの事を物理デバイス、赤外線で接続するデバイス(エアコンなど)のことをvirtual remote deviceと区別して扱います。

API rate limitは1,000 request / dayとなっていて、あまり多いという訳ではないですが、例えば数分に一回、あるいは一時間に一回室温を取って記録するようなPrometheus Exporterを記述するといったことが捗ると思いますので、SwitchBotデバイスを使っている方は是非使ってみて下さい！

Firefox 83で導入されたピンチズームを無効にする

Tue, 02 Feb 2021 06:49:47 +0000

11月7日にリリースされたFirefox 83 では、タッチスクリーン/タッチパッドを搭載したデバイスでのピンチズームがサポートされました。

が、私としてはスクロールしたいだけなのにズームされてしまったりと誤動作が多く、使いづらいなーと感じましたので、無効化しましたが、設定画面からは無効化できなかったのでメモを残しておきます。

about:config を開く
zoomで検索しapz.allow_zoomingをfalseに設定する

以上です。

チカの南蛮漬け

Fri, 29 Jan 2021 13:17:22 +0000

チカはワカサギを少し大きくしたような小型の魚で、北海道では割とよく食べていた魚でした。上京してからはほとんど売られているのを見ず、たまに近所の西友や東武百貨店池袋店地下の鮮魚売り場で売られているのを見る程度です。

天ぷらやフライなどで食べられることもある魚ではありますが、我が家では専ら南蛮漬けとして食卓に並んでいました。チカを見かけるとついつい買ってしまうのですが、今日も買ってしまったので南蛮漬けの紹介をします。

材料はこちら。チカ1パック(100gあたり127円で、250gくらい入っていました)、玉ねぎ、パプリカです。我が家では実際のところ、魚より野菜が大量に入っている南蛮漬けが好きなこともあり、チカに対してかなりの量の野菜を入れます。玉ねぎは時期的に新たまねぎが売られていたので新たまねぎにしましたが、普通の玉ねぎでも問題ありません。チカも売っていなければワカサギを使うこともできます。パプリカは時期が悪いのか若干高かったです。

まずは野菜を切っていきます。

これを

こうして

こうです。パプリカはスライスすると水分が結構出ます。

キッチンペーパーなどを敷いたバットに乗せ、軽く塩をして冷蔵庫で休ませ、少し水を抜きます。

次は玉ねぎ。写真は二つですが結局三つ使いました。

皮を剥いて、

こうです。

パプリカと同じく、キッチンペーパーなどを敷いたバットに載せ、軽く塩をして冷蔵庫で少し休ませます。特に、普通の玉ねぎを使う場合は空気にさらすことで辛味が抜けるので空気に触れる面積を広くするようにほぐしておきましょう。

このぐらいのタイミングで漬けダレ用の出汁を引いておきます。面倒なら出汁の素をお湯で溶いても良いです。

チカは軽く洗って、水気をしっかり切り(キッチンペーパーなどを使って！)ます。我が家ではワタなどは取ったりしませんが、気になる人は腹を開いてワタを抜いても良いと思います。

何か手頃な袋などに入れて、

片栗粉をまぶします。

袋に空気を入れて適当に振るとうまくまぶすことができます。

ピンボケしていますが、漬けダレです。砂糖大さじ3、醤油大さじ2、減塩醤油大さじ2(無ければ普通の醤油でもOK)、酢100cc、出汁200cc、輪切り唐辛子を適量です。これに揚げた魚やらなんやらを突っ込めば大体美味しいです。玉ねぎ3、パプリカ2だと、更にこの倍量で漬けダレを作ります。

漬けダレができたら、適当に温めた油を用意し、

チカを突っ込みます。写真では三匹しか入れてませんが、温度が下がりすぎないように適当に突っ込みます。この後更に四匹くらい突っ込みました。

なんか雰囲気で火が通ったっぽくなったら軽く油を切って、熱いうちに漬けダレに落とします。なんか泡が大きくなってきたり、良い感じの色がついたりしてきたら火が通ったと思って大丈夫でしょう。あとはひたすら、

揚げて、

ageて、

漬けダレへ。

冷蔵庫で休ませて少し水分を抜いた野菜と和えて、

偏りが発生しないように保存容器に詰めるなり皿に盛るなりして完成です。一晩おいたくらいが一番美味しくて、4日程度は日持ちします。

Soundcore Life Q30

Tue, 26 Jan 2021 06:42:34 +0000

最近、Among Us というゲームにはまっておりまして、友人とのプレイ動画をYoutubeで配信なぞしているのですが、その際、リモートワークで自宅勤務になってからあまり使用されていなかったヘッドホンを使用しています。

これまで使用していたヘッドホンは某社の社長からお下がりで頂いたbeats studio wireless なんですが、多少年数が経っているというのもあり、充電ポートがmicroUSB type-Bです。オフィスで使っている分には、専用のケーブルを一本用意しておいて、退勤時に充電するという運用でうまくいっていたものの、ここしばらくは自宅のケーブル類をなんとかtype-Cに統一しようとしていたことも相まってmicroUSBのケーブルを自宅で出しっぱなしにするというのは避けたいという気持ちが強くなりました。

そんなわけでtype-C充電のヘッドホンがほしいな〜と思っていたのですが、beatsの新しめのモデルは相変わらずmicroUSB充電で、かといってSONYとかBOSEとかの上位モデルを買うかというと、Anker PowerExpand Elite とか買っちゃったのでちょっと散財しすぎかな、と思っておりました。

そんな折に目に入ったのがSoundcore Life Q30 でした。

ヘッドホンを購入しよう、と思ったときに個人的にはいくつか条件があり、まず一つは上述のtype-Cで充電できること。加えてオーバーイヤー型であること、ANC がついていること、というあたりを条件としました。Soundcore Life Q30は多少形が好みではない感じがあるものの、どうせ基本は自宅で使うだけだし、価格も安いという事で購入に踏み切りました。

Soundcoreはみんな大好きAnkerのサブブランド(?)で、これまでにはスピーカーを購入したことがありました。Web上のレビューも悪くなく、比較的安心して購入することができました。

箱はAnker製品にありがちなシンプル・・・という路線ではなく、Soundcore製品にありがちな写真+文字という感じのおしゃれな箱。最近(といってももう数年単位とかだと思いますが)こういう箱のオーディオ製品多いですよね。

しかし梱包レベルはAnkerという感じ。ケースに入ったヘッドホンがそのまま箱に入っています。ウケる。

ケーブル類は小さい巾着袋に入って同梱されていました。この巾着が結構触り心地が良いです。

付属していたケーブルはUSB type-A to USB type-Cケーブルと、AUXケーブルです。このAUXケーブルでつないで有線で音楽を聴けばハイレゾにも対応しているとか。そんなに音質のいい音楽を最近は聴かないので、あまり意味は無いですが。

飛行機とかで無線NGな時に音楽を聴きたい人にはいいかも。

中の仕切りは固定されているわけではなく、ただの梱包材だった模様。

梱包材を外してしまうと収納方法が分からなくなりそうですが、そういった可能性も考慮してか収納方法のタグがついてました。安心。

装着感としては側圧が結構やさしめな様に感じます。眼鏡をかけて数時間装着しても痛くありませんでした。

まだ使い始めなので音質等はレビューできませんが、以上、開封レビューでした。

Anker PowerExpand Elite 13-in-1 Thunderbolt 3 Dock

Fri, 22 Jan 2021 07:47:47 +0000

Ankerが最近(といっても国内の販売開始は12月中旬頃だったはずなので、かれこれ一ヶ月は経過している)発売した、PowerExpand Elite 13-in-one Thunderbolt 3 Dockを購入したので、unboxing & review noteを書いておきます。

実はこの商品自体は海外では大分前に発売されており、個人的には国内の発売を今か今かと待ち望んでいた形でした。発売即購入・・・といきたかったのですが、そこはAnker。良さそうな新商品はすぐに完売と相成ってしまったのでありました。

個人的にこの商品を選んだのは、以下のような理由があります:

USB Type-Cポートが複数ある
- USB Type-Cポートが4つあり、うち二つはThunderbolt 3ポートです。一つはPCとつなぐことになるため、都合2つUSB Type-Cのポートが増える計算になります。弊宅ではケーブルをできるだけUSB Type-C to USB Type-Cに統一しようとしているため、USB Type-Cポートを増やすことができるというのが最優先事項でした。
余計なポートが少ない
- USB Type-Cポートを増やすというのが主目的なため、多くのドックにありがちな「いろんなポートがついてるよ！」は無駄でしかないという気持ちでした。光デジタルオーディオやSDカード、USB Type-AやEthernetも正直不要です。が、世の中の人はたくさんポートがついているものをほしがっているのか、Type-Cのポートを増やすだけ、という物はほぼ存在しておらず・・・
比較的小さい
- 世の中のドックは大きいんです。USB Type-Cポートを増やしたいだけなのに(以下略
比較的安い
- 大体このスペック(Thunderbolt 3 dock)だと約3万というのは最も安い方の値段で、高い物だと4万〜5万程度します。同時に発売されたThunderbolt 3ではないほうのドックは2万円程度ですが、Type-Cポートが少ないのです。

現在の配線はこんな感じです。最初、PowerExpand - ディスプレイ間もtype-C to type-Cケーブルでつないでみたのですが、何か遅延があるのか、カクついているのか、マウスカーソルの動きに違和感がすごかったので、試しにHDMIでつないでみたところ、違和感がなくなったためHDMIでの接続としました。ウェブカメラはディスプレイのtype-Aポートにつないでおり、これをPowerExpandまで引き延ばすと取り回しが良くなさそうだったので、ディスプレイとPowerExpandの間にもう一本type-A to type-Cのケーブルを配線し、ウェブカメラは引き続きディスプレイのダウンストリームポートに接続するという形にしました。

現状マイク(AKG Lyra)とキーボード(Ergodash)がPCに直接接続されているので、これをPowerExpandに接続する形にまとめられれば、PCのポートは一つで済むという事になり、取り回しが非常に楽になりそうです。マイクはtype-C接続なのでそのまま特に問題なく接続できそうですが、キーボードはmicro-Bなので、今更micro-Bのケーブルを増やしたくもないですし、どうするかはちょっと検討することになりそうです。

以下unboxing。

2020年買って良かった物

Wed, 23 Dec 2020 16:38:13 +0000

世間の波に乗って、書いてみる。

ガジェット類

Anker PowerWave 10 Pad(改善版)
- ワイヤレス充電器は安物だったり、ノベルティでもらった物だったりしか使ったことがなかったためあまりいい印象がなかったが(といってもこれも別に高くはないけど)、改めてちゃんと買って見たら充電速度も十分でかなり良い。
サンワサプライケーブルトレー(メッシュ・汎用タイプ) CB-CT5
- クランプでデスク下に付けるタイプのケーブルトレー。デスクの上が大分すっきりした。キーボードの配線だけは現状どうしようもないので、なんとかしたい。
スリムな人間工学的なリストレストマジックトラックパッド2世代
- 明らかにアレっぽい感じの商品名で、実際梱包の感じがアレだったけど商品自体はそこそこちゃんとしてる。机との相性が良くないのか、手首がかゆくなる事がちょいちょいあったけど、これを使い始めてからはそういったことも無くなった。
Twelve South BookArc for MacBook (Space Grey)
- 結構ずっとほしかったものの、スタンドだけでこの値段は・・・と思ってためらっていたが、最終的に購入し、机の上が広くなったので大変満足。

メガネ関連

SIMON アンチフォグ
- このご時世、メガネをしている人は絶対買った方が良い。これを使っていないで「マスクすると眼鏡が曇るから・・・」というのは甘え。マジで全く曇らなくなり世界が変わるので、最寄りのビックカメラ or amazonで即購入してください。
メガロックミニ
- 軽めのフレームで、視力が悪くて薄型レンズにしているひとに特にオススメ。

キッチン用品類

Iwatani たこ焼きプレート CB-P-TAF
Iwatani 焼肉プレート小 CB-P-Y2
- 我が家で使用しているIwataniのカセットコンロをホットプレートのごとく使用することができる焼き肉プレートとたこ焼きプレート。大阪の人が「たこ焼きは絶対ガス火で作った方がいい」という気持ちも分かるようになったし、ちゃんと油が下に落ちる焼き肉プレートはかなり快適。ホットプレートと違って、熱源とプレートが別売のものなので、どちらかが使えなくなってもダメになった物だけ買い換えればよい、というのも大変よいところ。
貝印バターケース
- バターケースというより、バターカッターとして使用。カットした後のバターは山崎実業バルブ付き密閉バターケースに入れている。個包装のカット済みバターより安く、同程度の利便性を得られるのでバターをよく使う人にオススメ。
OXO シリコンスパチュラ M
- 実家にいたときはゴムべらなんて製菓の時にしか使わないと思っていたけど、料理に使っても便利と言うことを実家を離れてから知ったので、100円のじゃなくてそこそこちゃんとしたのを買った。溶ける心配も無いし(100円のは柄が溶けそう)、使いやすい。
超強力マグネットフック Cosego 6個入
- こちらも100円の物から買い換え。磁力も強く、割と何でも掛けることができて便利。4人前用のパエリアパンくらいの重さになると、一つでは支えきれなくなる程度の力がある。
山崎実業戸棚下調味料ラック
- 細かい調味料類(こういうのとかこういうの、なおこれらはあまり良くなかった)を置いておくのに便利。

バックアップはちゃんと取りましょう、という話

Tue, 06 Oct 2020 06:18:33 +0000

諸般の事情・・・というか単純に本ブログを動かしていたサーバーがどうやら壊れたようで(すぐに作業できる場所に置いてない)、とりあえずクラウド上に同じような環境を作ってバックアップからリストアしたんですが、最後にバックアップ取ってから何本か記事を書いていた物が消失しました。

皆さんちゃんとバックアップは定期的にとりましょう。

以上です。

Rakuten Mini unpacking

Sat, 13 Jun 2020 11:27:54 +0000

昨日、何かと今話題のRakuten Mini (C330) が届きましたので、開封・セットアップしました。

外箱はシンプルな感じ。このタイプの箱、最近流行ですね。届いた内容物としては、

Rakuten Mini
Rakuten Mini初期設定方法のご案内
Rakuten Mobile eSIM版 START GUIDE

の三つでした。

箱の底面には何も書いてありません。ちょっと作りが甘いというか、蓋が大きいように見えます。が、Appleの作りの良い箱とかはぴったりすぎてちょっと開けにくいので、これくらい緩い方がむしろ開けやすいかも。

開けると早速端末がお目見え。小さくて可愛いです。色はクリムゾンレッドを選択しました。少し落ち着いた感じの赤で良い感じ。

付属品はこんな感じ。本体の他、ペライチの説明書、充電用のケーブル、充電アダプタ、イヤホン変換ケーブルが入っていました。

充電アダプタは5V1Aで、急速充電には対応していないようです。多分。写真でもわかるとは思うんですが、コンセント側が少し小さい台形になっているので、コンセントの状況によっては使いづらいかもしれません。

説明書は小さく、半分に折りたたまれているだけの紙なので、情報は非常に少ないですね。

イヤホン変換ケーブルはPixel 4だと付属していなくて、Google Storeで1,320円なので、有線のイヤホンを使いたい人には嬉しいかも。私は使いませんが・・・。

本体を保護していたフィルム？を剥がしたらこんな感じ。つやのある色で、あまり安っぽい感じはありません。Rの文字とFelicaマークは銀色です。白は背面が白、側面がシルバーなので、側面がメッキっぽい感じの赤とかだったらやだなぁ・・・と思っていたのですが、そんなこともなく、違和感のない色合いになっています。

カメラは(イマドキのスマホはだいたいそうですが)若干飛び出ています。が、0.5mmに満たないくらいしか飛び出ていないので、あんまり気にする必要はなさそうです。

写真で言うところの左下の角にストラップホールがあり、これは最近の端末としては結構珍しいように思えます。

画面側。まぁ特筆すべきことは特にないですね。画面向かって右側に電源ボタンと音量ボタンがあります。

サイズ比較のため、SAPICAと重ねてみました。普段はPASMOを使っているんですが、東武カード一体型のため、写真には使えなかったんですよね・・・

幅はカードと同じか少し小さいくらいで、長さはカードより長いです。こうしてみるとかなり小さいですね。

起動するとホーム画面はこんな感じです。なんだかちょっと高齢者向けあるいは子供向けの端末っぽい気もしますが、小さい画面で扱いやすい、なかなか悪くないホーム画面だと思います。ベゼルが大きいスマホは久々に持ったので、ちょっと違和感があります。

初期IMEはiWnn IMEとか言うやつで、わたしはATOKに入れ替えました。フリック入力は思ったより余裕で、twitterくらいなら全然不便を感じません。一方でQWERTYキーボードによる入力はやはりちょっと厳しい感じ。入力自体はできますが、ちょっと疲れてしまいそうです。

まぁ1円で手に入り、Felica搭載、顔認証でロック解除ができ、ジーンズのコインポケットに入る小ささ、回線料金も一年は無料ですから、興味があったら申し込んでみても良いのではないでしょうか。特に、Falicaを搭載していない端末をメインで使っている方は決済用端末として購入してみても悪くは無いと思いますよ。事務手数料も無料というか、むしろポイントでプラスになりますしね。

梅仕事2020

Sat, 06 Jun 2020 16:53:33 +0000

6月ですね。梅の季節でございます。数日前から近所の西友でも梅の実やらなんやらが店頭に並び始めまして、あぁ6月か、と感じる次第です。 20歳になった6月から毎年梅酒やら梅シロップやらを作ってまして、シロップはまぁ家族も飲みますし、そもそもそれほど(少なくとも年単位では)日持ちする物ではありませんから、作っては消費し、という感じですが、梅酒は(あまり自宅で酒を飲まないので)毎年4L瓶が増え続けています。就職して関東に出てくるまでに作った物は実家に置いてきてしまったのですが、どこかのタイミングで引き取りたい気持ちがありますね。まぁそこまでの物を置いてきたとはいっても、関東に出てきてからかれこれ4年、4L瓶も今年で4本目、札幌に置いてきた物と合わせると8本になりますから、なんとか圧縮するなりする必要がありそうです。

扨、今年は池袋にある東武百貨店の地下食料品売り場で南高梅を購入してきました。約1kg(1kgをちょっと超えるくらい)で1500円でした。2kgほど買いましたので、3000円ですね。スーパーで買うと大体1000円/kg位ですが、そこは百貨店、実も大きく、傷がほとんど無い良い梅です。

梅酒用にはまだ青い実を、梅シロップ用には比較的熟していそうな黄色い実を選んできました。

20歳の時に作ったときに、このように水に実を漬けて、あく抜き(?)をせよという情報を見たため、何も考えずに毎年このように水に漬けていますが、わりとさっとあげてしまうので、実際効果というか、意味があるのかどうかは不明です。

瓶は特に特別な物は使用していなくて、西友で買ってきました。680円です。昨年梅シロップに使用した瓶は洗うのをサボって放置したため、再使用するのはちょっといやだな、と思ったので捨ててしまいました。

さっと水で洗った後(本当はちゃんと洗った方が良いと思うんですけど、でかくて洗いにくいのでさっとで済ませてしまいます。毎年。特に問題は発生していません)、アルコール製剤を拭きかけて消毒します。特に梅シロップは酒が入らない分、ちゃんと消毒しておかないと変なことになりかねません。

例年は氷砂糖を使用して作っていたのですが、今年は何の影響やら氷砂糖が完売だったので、思い切ってザラメを選択してみました。1kgあたり228円です。

まずは梅シロップを仕込んでいきます。

水からあげた梅の実をキッチンペーパーで拭いて水気を取り、爪楊枝でへたをとり、砂糖に埋めます。瓶に梅を敷き詰める、砂糖を上からかける、梅を敷き詰める、砂糖をかける、という感じです。

梅は金気を嫌う、というはなしがありますが、これはまぁいろいろと理由があるようで、曰く、梅の酸で金属が腐食するので金属の道具を使うのは良くない、だとか、曰く、金属の道具では梅の実を傷つけやすく、傷がつくとカビなどの原因になったり、見た目や味が悪くなったりするから良くないのである、だとか。まぁ理由がないということは無いはずですので、素直に先達の言葉に従い、金属の道具を使わずにやっていきましょう。

梅シロップは酢を入れるレシピと酢を入れないレシピがありますが、個人的にはむやみに発酵されたりカビられたりしても困りますし、液体が入った方が呼び水的な感じで早くできるかな、という気持ちで酢を少量入れています。効果のほどは不明です。今年はたまたまリンゴ酢があったので、これを使用してみました。大さじ三ほど適当にかけておきます。

梅シロップの仕込みが終わったら次は梅酒です。今年は宝酒造の「果実酒の季節」を使用します。近年どこのスーパーでもよく売られている甲類焼酎ですね。毎年梅酒を仕込んでいますが、実は果実酒の季節は使ったことがありませんでした。特にここ数年は麦焼酎で漬けてみたり、泡盛で漬けてみたりしていたので、ホワイトリカー自体使用していませんでした。

毎年氷砂糖でやっていたので、酒の方をいろいろ試していたのですが、今年は前述の様にザラメを使用しており、砂糖側の条件を変えたので、まぁ果実酒用のホワイトリカーなら余計な匂いもなかろうということでこれを選んでみました。1.8Lで1258円です。

開封してみて驚いたんですが、この「果実酒の季節」、全然匂いしないんですね。まぁ、もちろんアルコールの匂いは多少しますが、それでも全然匂いがない。なるほど、確かにこれは果実酒向きっぽい。

梅酒も最初の手順はシロップと同様です。梅を水から取り出し、キッチンペーパーで拭き、へたを取り、敷き詰め、砂糖をかけ、敷き詰め、砂糖をかけ・・・です。

詰め終わったら上から酒をドバドバと流し込みます。ザラメを使用しているからだと思いますが、すでに茶色い色です。これはなんかちょっと楽しみですね。

この後は数日ごとに軽く振るなり混ぜるなりしてあげて、梅のエキスを抽出していきます。氷砂糖だと大体3ヶ月から半年くらいで飲めるようになるんですが、ザラメでも同様なのかどうかはよくわかりません。まぁそもそも一年以上経たないと味見もろくにしないので、気長に待つことにします。

最後に2017年、つまり就職で関東に出てきた年の梅酒を引っ張り出してきて一杯やりました。大分角も取れて飲みやすくなっていましたね。この年はレシピを瓶に貼っていなかったので、どういうレシピで作ったのかはよく覚えてないんですが、とりあえず美味しかったのでよしとします。

AKG LYRAを購入した

Mon, 01 Jun 2020 08:29:47 +0000

ようやく緊急事態宣言が解除され、むやみにガジェットを買う理由がなくなってしまった皆様、いかがお過ごしでしょうか。

新型コロナウイルス感染症拡大防止の観点から、ﾍｲｼｬでも数ヶ月ほどリモートワーク(余談ですがWFH、という字面をついついWTFと空目してしまうのは私だけでしょうか)をしてきたわけですが、弊宅にはまともなマイクというものがありませんでした。しばらくはかなり前に購入したWebカメラ、BuffaloのBSW20KM15 の音声入力を使っていたのですが、何度か聞き取りにくい、と言われたので(大半は問題ないと言ってくれたのですが、まぁ理由付けのようなものです)、ある程度のUSBマイクを購入することを決意しました。

とはいえ、社内外でおすすめされたオーディオテクニカ AT2020USB+ はそれこそみんなリモートワークをしているのが理由、と言わんばかりにどこを見ても在庫がない、という状態です。在庫復活はいつになることやら、、、と思いながらSOUNDHOUSE を眺めていたところ、AKG LYRA という何やらよさげな見た目をしたマイクが一押しっぽい感じでしたので、つい勢いで購入しました。今となってはAKG LYRAもお取り寄せ、となってしまっていますが、購入時点では1週間ほどで入荷予定ということでしたので、まぁそれくらいなら待とうか、ということで即注文、5月22日に届きました。

This is my new gear、な訳です。Youtubeではすでにそこそこ国内外のレビュー動画が投稿されており、それをぼーっと眺めたりもしていたので、そこそこサイズが大きい、というのはわかっていたのですが、届いてみたら予想以上に外箱が大きく驚きました。

適当に何かサイズ感のわかる物はなかろうか、と思って手元を探したのですが、どうにもしっくりくる物がなく、唯一しっくりきたのがNINTENDO SWITCHでしたので、比較のために置いてみたのが次の写真です。

なかなかのサイズ感ですね。この手の物はスタンドと本体がバラバラになっていて、到着してから自分で組み立てる、ということになるのが良くあるパターンだと思うのですが、本製品はすでにガッチャンコされた状態で梱包されているので、外箱が大きくなったようでした。

なんて入り方をしているのでしょう。。。

取り出した本体がこちら。比較用にティッシュの箱を置いています。外箱の比較もティッシュでよかった説。結構良いサイズですね。まぁけっして小さくはありませんが、そこそこ重量があり安定していますし、高さもそこそこあるので普通の姿勢で安心してしゃべることができます。

音質ですが、他のマイクは使ったことがないので、はっきり言って良くわかりません。しかし、ちゃんと聞こえてはいるようです。良かった良かった。PCとの接続はANKERのC2Cケーブルを使っていますが、特に問題ないようです。

個人的にはマイク側のMUTEボタンと、ZOOMなどのミュートが連動できたらなお良いと思うのですが、どなたか方法をご存じだったら教えて下さい。

rustで書かれたlsの代替コマンドexaをインストールしてみた

Wed, 20 May 2020 02:54:27 +0000

twitterでおのかちお氏(鍵垢なのでここでは紹介できないが)がexa というlsの代替コマンドを試してみている、ということでスクショをアップしており、これがなかなか良さそうであったので、探してインストールしてみました。

website の説明によると、

A modern replacement for ls.

トのことで、色をつけれたり、早かったり、tree viewができたり、Gitのステータスを表示できたりするらしい。

macの場合、homebrew でインストールできるようなので早速インストールしてみます。

1

$ brew install exa

very easyですね。使ってみましょう。

なるほど、デフォルトの表示はlsと同じくgrid viewなんですね。ホームにディレクトリしかないのでわかりにくいですけど、字が太いですね。あとklaussinani/hyper-pokemon を使っている都合で、色は表示されません・・・

アイコン付きで表示してみましょう。アイコンを表示したい場合は--iconsオプションをつければ良い、とのこと。

おや、表示されないですね。これは困った。まぁこの手の問題は(見た目から言っても)フォントがインストールされてないために発生しているのだろう、とあたりをつけつつ、issueを検索します。

するとどうやら nerd fonts というフォントがアイコン表示用に使用されているようです。これをインストールしてみます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$ brew tap homebrew/cask-fonts
==> Tapping homebrew/cask-fonts
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-fonts'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 35658 (delta 8), reused 9 (delta 5), pack-reused 35639
Receiving objects: 100% (35658/35658), 6.07 MiB | 3.34 MiB/s, done.
Resolving deltas: 100% (25786/25786), done.
Tapped 924 casks (973 files, 7.8MB).
$ brew cask install font-hack-nerd-font
Updating Homebrew...
Error: Cask font-hack-nerd-font exists in multiple taps:
 homebrew/cask-fonts/font-hack-nerd-font
 caskroom/fonts/font-hack-nerd-font

おや、エラーが出ましたね。今回追加したhomebrew/cask-fontsというtapと元々あったcaskroom/fontsというtapの両方に同名のパッケージがあったようです。詳細を見てみましょう。

Gmail Filter as Code

Fri, 08 May 2020 01:00:00 +0000

@yamamoto_febc さんのブログ記事で、jessfraz/gmailfilters というツールを知りました。なんでも、GmailのフィルタをTOMLで管理するツール、とのこと(実際の使用例などはkakakakakkuさんの記事で紹介されています)。それは素敵っぽい、ということで触ってみたところ、実際良い物っぽい感じはあったものの、TOMLというのが(個人的に)つらいし、releasedなバージョンではexportができない(機能自体はmasterにあるものの、一年前に機能開発されてからリリースが打たれていない、という点がちょっと不安)という二点が気になりました。特にTOMLはどうにも好きになれず、やはりYAMLで書きたい、という気持ちが強かった+GWの自由研究が決まらなかったので自前で書き直し、これをGmail as Code (今はfilterしか管理できないけど、他の設定も管理できるようにしたい)からgmac と名付けました。

YAMLで設定したい
— nasa9084@某某某某(0x1b) (@nasa9084) April 27, 2020

GMaC - Gmail as Code

大枠の挙動としては、jessfraz/gmailfiltersとそれほど変わりません。Gmail APIをgoogle.golang.org/api/gmail/v1 を使用して叩いているのも同じです。 jessfraz/gmailfiltersと比較して、違う点として次の様なものがあります:

TOMLではなくYAMLで設定を記述する
Gmail Web UIに比較的近い設定項目
- jessfraz/gmailfiltersも実装しているArchiveやDeleteなどはもちろん実装
- 条件/アクションを個別に設定する形にした
  - jessfraz/gmailfiltersみたいに全部まとまってるとわかりにくくない？
- larger_thanやsubject、has_attachmentといった条件も追加
- starやimportant、category(私は使ってないけど)といったアクションも追加
OAuthの際に認証/認可ページを自動で開き、OAuth callbackも受ける
- jessfraz/gmailfiltersはURLと、OAuth tokenをコピペする必要がある
credentials.jsonおよびtoken.json (OAuthの認証ファイル)を特定の場所に置き、そこから読み込む
- jessfraz/gmailfiltersは毎回ファイルパスを指定する必要がある
kubectl-likeなサブコマンド配置
- get/applyが個別に行え、(k8sに慣れている人は)比較的なじみやすいはず
- jessfraz/gmailfiltersはオプションフラグで挙動を変える方針っぽい
CIで使いやすい(と思う)
- credentials.jsonを標準入力から読める
- OAuth refresh tokenを環境変数で指定できる
- jessfraz/gmailfiltersはファイルからのみ
(そこそこ)ちゃんとテストを書いている
- 全部とはいえないけど・・・
- jessfraz/gmailfiltersはほとんどテストがなくてちょっと怖い
(そこそこ)ドキュメントを整備してある
- README.mdを頑張って書いた

逆にjessfraz/gmailfiltersがサポートしている、queryOrやarchiveUnlessToMeは実装していません。ORとか普通に書けばよかろう。

Manage with CI

実際に、GitHub Actionsを使用して自分のGmail Filterを管理するように設定しました。管理用のプライベートリポジトリにfilters.ymlとしてフィルタの設定ファイル(これ自体も gmac get filters -o yaml > filters.yml として出力したもの)と、次のGitHub Actions設定ファイルをおいてpushごとに適用するように構成しました。

YOBYBO CARD20

Mon, 27 Apr 2020 08:56:45 +0000

2020-05-19追記: 外出時にPixel 4との組み合わせで使用したら、音の途切れが激しく、正直使い物にならなかったので、「不良品では？」と問い合わせをしたら返品・返金対応となりました。見た目、サイズ感、装着感などは良かっただけに残念です。

先だってMakuakeで応援購入したCARD20 が届いたので、開封レビューします。

CARD20は非常に薄い左右完全独立型のワイヤレスイヤホンで、クラウドファンディングプラットフォームMakuakeで出資を募っていました。私も1月末頃に支援をし、紆余曲折あり(コロナのせいであれこれあったらしい)本日手元に届きました。

なお、多くの「提供」記事がウェブで展開されていますが、本記事は提供を受けたわけでもなく、自分で買っての感想です。

特筆すべきはその薄さで、この手のTWSイヤホンでも比較的標準と思われるサイズ感のAVIOT TE-BD21f のケースの厚さが3cm弱程度なのに対し、CARD20はなんと1.3cmと、TE-BD21fの約半分の厚さです。Pixel 4 (ファブリックケース付き)より若干厚いかな、という程度です。

CARD20の13.4mm世界最薄クラスのボディは、お財布やジーンズのコインポケットにしまうことができ、コードや収納の煩わしさから解放されます。

との説明がプロジェクトページに書かれていたものの、さすがに1.3cmのものを財布に入れたら邪魔そうではあります。とはいえコインポケットに入るのはなかなか良さそうです。

また、近年は店頭で販売されるイヤホンの大半がカナル型ですがCARD20はインナーイヤー型です。これは個人によってプラス評価になるかマイナス評価になるかというのはかなり分かれるところですが、左右完全独立型のワイヤレスイヤホンの選択肢はほとんど存在しない(AirPodsとその類似品+αくらい)現状で、カナル型があまり得意ではない私としてはかなり心が惹かれる製品となっています。ウェブ上でさっと調べても、「カナル型ではない点が惜しい」との記述を見ますが、個人的にはカナル型じゃないからこそ、「買い」でした。

外箱は至ってシンプルで、製品を上面から見た写真が白い箱に印刷されています。蓋と内箱がぴったり吸い付くようなサイズ感で構成された箱、しろい外観、余計な物が書かれていないデザイン、最近流行のデザインともいえますが、Appleっぽさがありますね。

箱底面にはケースからだしたイヤホンの写真と、モデル番号をはじめとした一通りのスペックが記載されています。Bluetoothのバージョンは5.0、MakuakeのプロジェクトページによるとQualcomm QCC3020を使用しているようです。TWS Plus対応ということなのですが、ざんねんながらPixel 4はTWS Plusに対応しておらず、あまり恩恵を受けることはなさそうです。

連続再生時間は約4時間、ケースのバッテリーが約16時間分充電できるようなので、合計で約20時間使用可能とのこと。AVIOT TE-BD21fが約7時間+約18時間の合計約25時間、SONY Xperia Ear Duoが約4時間+約16時間の合計約20時間なので、サイズの割には標準的な使用時間となっているように思えます。

箱には記載がありませんが、防水性能はIPX4ということなので、少なくとも雨が降る、汗をかく、くらいでは問題がないようです。

開封すると直ぐに本体が入っています。注文時にロゴなしバージョンを選択したため、イヤホン本体にはロゴが入っていません。プロジェクトページや箱に描かれていたものよりは深い黒で、光沢感もあまりきつくなく、高級感もありなかなか良い色だとおもいます。

表面は天窓設計によりイヤホン本体の一部が見えています。これにより、気づかないうちになくなっていた、ということがなくなるとのことですが、実際はどうなんでしょうか。タッチコントロール対応と言うことで、おそらく銀色の部分をタッチして操作することができるのでしょう。AVIOT TE-BD21fはボタン式で、うまく押さえて操作しないと耳にさらに押し込む形になってしまうという感じだったので、タッチで操作できるのはプラスポイントです。(感度が悪いor良すぎる、ということがなければ)

裏面には技適をはじめとした各種法令関係のマークとバッテリー容量、電源関連情報、生産国、モデル名などが書かれています。平面に対して垂直に充電ケーブルを挿すのはどうなのか、とおもわなくもないのですが、この薄さなら仕方が無かったのでしょう。充電ケーブルはUSB Type-Cです。

付属品として説明書と充電ケーブル。ケーブルはUSB Type A to Type Cのそれほど長くない物です。説明書は英語と日本語で記載がありますが、日本語の一部が中国語？になったりしていて微妙に怪しさがあります。

本体ケースを空けるとこんな感じ。空けるときに若干イヤホンに干渉するようで、すこしイヤホンがぐらっとします。取り落としてしまうほどではないのでとくに問題はありませんが、繰り返し開け閉めしていたらすこしイヤホンが傷つくかもしれません。

YOBYBOロゴとL/Rの文字はエンボス加工というか、すこし周りから浮き出たような処理になっていて、高級感があります。

閉じると真ん中が光ります。充電残量の表示でしょうね。多分。

イヤホンの内側はこんな感じ。ケースから取り出す際、少し取り出しにくいかも、という印象をうけましたが慣れれば多分大きな問題ではないでしょう。

充電端子部分に絶縁フィルムがついているので、これを剥がして充電を開始します。

まだ音楽を再生していないので音や接続の安定度などについてはなにもコメントできないのですが、開封してみての見た目だけでいうならかなり満足度が高い商品となっていると思います。AVIOT TE-BD21fやXperia Ear Duoのケースや本体がプラプラしいのに対して、CARD20はそういった安っぽさはあまり感じられません。

新型コロナウイルス感染症の影響を受けてリモートワークをしていますから、ワイヤレスのイヤホンを使用する機会が激減してはいるのですが、機を見て使ってレビュー記事でも書けたらな、とはおもっています。

ギョーザ×ラザニア

Sun, 19 Apr 2020 06:20:25 +0000

ラザニア（単数形: lasagna）あるいはラザニエ（複数形: lasagne）は、イタリアのカンパニア州ナポリの名物である、平たい板状のパスタの一種、またはそれを用いたパスタ料理。イタリア語の発音ではラザーニャやラザーニェに近い。

料理の場合は、イタリア語で「オーブンで焼き上げたラザニア」を意味するラザーニャ・アル・フォルノ (lasagna al forno) と呼ぶこともある。深さのある耐熱容器に、ベシャメルソース、ミートソース、ラザニア、チーズを何層か重ね、最上段のベシャメルソースに焼き色がつくようにバターを乗せて、オーブンで焼いたもの。

餃子、すなわち薄いパスタ(小麦粉なので大体一緒です)と挽肉の集合体にトマトソースとチーズを載せて焼いたら大体ラザニアになりそう、ということで作りました。ベシャメルは面倒なので省略します。適当にホワイトソースを買ってくるとか、フレークタイプのホワイトソースとかを買ってくれば良い感じになる可能性がありますが、家になかったので諦めます。

我が家には三割うまい!! の冷凍餃子が常備されておりますので、これをゆでていきます。お好みによっては焼いても良いかもしれませんが。

玉ねぎが余って(？)いたのでいれようと思い立ち適当に炒めていきます。このあと適当に刻みニンニクを加えて香りを足してみたりしました。

トマトソースはこちらを使います。カルディで買えるもので、結構便利です。

だばぁ。軽く水分を飛ばしましょう。お好みでなんかハーブとか入れても良いかもしれない。

耐熱皿にゆでた餃子を並べます。

ソースをかけます。

チーズ。

オーブン/オーブントースターで良い感じになるまで焼きます。餃子もソースも予め火を通してるので、チーズが良い感じになればOK。

お好みでバーナリングしましょう。香りが立ってより旨そう感が増します。

いざ実食。これはまぁラザニア的な物体として十分戦えます。ベシャメルを入れたらもっとラザニアになりそうではありますが、そこまでやるともうそれは普通にラザニアを作った方が良いかもしれません。

アーロンチェアリマスタード

Wed, 15 Apr 2020 09:24:39 +0000

諸般あり、オフィスでも使用している、最高の椅子と名高いアーロンチェアをかなりお安く購入できるという機会を頂戴したので、COVID-19の影響を受けて完全にリモートワークをしていることもあって購入を決意しました。

おそらくオフィスで使用している物は旧型のアーロンチェアなのですけれども、今回購入したのは(新品なので当然ですが)現行の「アーロンリマスタード」、型番で言うとAER1B23DW ALP G1 G1 G1 BB BK 23103というものです。

注文をして支払いをしてからちょうど一週間で届きました。販売元はGregory Lyon社で、アーロンチェアをはじめとするハーマンミラーのオフィシャルディーラーです。

箱には取り扱いや持ち上げる際は二人でやりなさい、との注意書き。重いからとのことではありますが、重さよりも大きさがやばくて、我が家の階段(我が家は一階に玄関があり、内階段を上って二階が居住スペースという構成)は幅がぴったりで、手すりの上を通さないとだめでした。購入を検討している方は要注意。

箱を空けると中から箱が。これは多分スペーサーですね。

外箱は下部が空いていて、上からスポッと取り外すことができます。

ご対面！！！そうそう、これですこれ。うひょー。

説明書が座席下のノブにかかってました。特に結ばれているとかいう訳ではなく、棒状の物に引っかかっているだけなので、はさみとかも必要無く取り外すことができます。むしろ配送途中に取れなかったのがすごい。

デスクに合わせるとこんな感じに。机の上があまりきれいではないのはご愛敬と言うことで・・・

ちなみにこれまで使っていた椅子はニトリのリカルドPUブレスレザーBK でした。これはこれでなかなか良い椅子だったので、ちょっと手放すのが惜しい、という気持ちがしています。スペースはあるし、とりあえず置いておいても良いかな・・・ゲームするときとか、本読むときはふかふかしてる方が嬉しいですね。

アーロンチェアは基本的に保証が12年なので、長いお付き合いになる見込みです。よろしく。

2020年3月時点での自宅機材・消耗品類まとめ

Sun, 12 Apr 2020 10:05:44 +0000

自分用のメモみたいなものですが、現時点(2020-04-12)で自宅で使用している家電や道具、消耗品類などをまとめてみます。

家電類

冷蔵庫: SHARP SJ-GW35C 。2016年製、幅60cm、定格内容積350L。
食器洗い乾燥機: Panasonic NP-TH1 。2018年製、幅550mm×奥行344mm×高さ598mm、庫内容量が約50L。後継機がNP-TH2, NP-TH3と出ているためすでに生産終了ではあるが、それほど大きな変更はない模様(小物ホルダーがついたり、庫内の棚の仕様が変わったり、というマイナーチェンジくらい？)。
洗濯乾燥機: TOSHIBA TW-127X7R 。2019年製。洗濯脱水容量が12kg、洗濯乾燥容量が7kgで、2019年8月時点では業界トップクラスの洗濯容量、業界最大の乾燥容量だったらしい(今はどうか、については調べていないので知らない)。操作がタッチパネルなのはちょっと特徴的かも。残念ながら洗剤等の自動投入機能はついていないが、後述の様にプッシュ式の(はかる必要の無い)洗剤を使用しているため不便はない。
炊飯器: TIGER JPH-A100 。2017年製を型落ちで買ったので大分安く買えた記憶がある。最近釜を欠けさせてしまったので買い換えたいが、釜だけでも2万以上するのでためらっている。
オーブンレンジ: SHARP RE-SS8D。2016年製で、すでに公式ページなし。所謂過熱水蒸気オーブンレンジ、というジャンルに当たる物っぽい。庫内容量23L。
ミキサー: T-fal ミックス＆ドリンク。定格消費電量300W、最高容量600ml。特に不満なし。
スロークッカー: TWINBIRD EP-D819W 。たまに作る煮物に便利。
エスプレッソメーカー: NESPRESSO U。すでに公式ページがなくなっている模様。製造年は不明・・・。水のタンクを右側に置いたり左側に置いたり奥に置いたりできる変わったマシン。現行の低価格帯マシンだとリストレット(25ml)が選択できないけど、本機は対応。牛乳で割ることがほとんどなので、あまり薄くならないので嬉しい。
コーヒーメーカー: TIGER ACX-S060 。大学生の、それも割と早い時期に買ったやつなので、もう結構な年数使っている気がする。定価は6000円だけど、購入時はセールかなんかで2000円くらいで買った記憶がある。サーバーがステンレスなので割る心配がないというのが嬉しいところ。
低温調理器: ANOVA 。Wi-Fiなしの2014モデル(多分2018年製とかそれくらいの奴)。
加湿空気洗浄機: SHARP KC-G50 。所謂気化式のもの。
掃除機: Dyson Cyclone V10 fFluffy 。言わずもがな。

キッチンウェア

鍋類: T-fal インジニオ・ネオグランブルー・プレミア(セット10) を基本に、ニトリの鍋やIKEAのフライパン、就職祝いでもらった圧力鍋などを適当に使っている。最近なぜかパエリアパンが仲間に加わった。IKEAの激安(300円くらい)フライパンはクソ便利だったのに、ラインナップからなくなってしまって悲しい。
計量カップ: OXO アングルドメジャーカップ(中) 。まぁそんなに真面目にはからないので、500mlの水が入るカップ、位の使われ方をしている。不憫。
ゴムべら: OXO シリコンスパチュラ M
まな板: アサヒクッキンカット
包丁: 三徳(火造り三徳) とペティ(槌目MV鋼強化木ペティ) を使っている。いずれも合羽橋つば屋さんのもの。

消耗品類

食器洗い用洗剤: JOY GELTAB 。洗浄力の高い粉末洗剤と油汚れにききやすいジェルが一つにまとめられたタイプのすごいやつ。コスパより性能重視。Amazonでセールのときはだいたいこれの超特大サイズというやつが割引されてお得なので、セールの度に追加購入するとだいたい良いペース。
衣類用洗剤: アタック ZERO ドラム式専用。プッシュタイプの容器で、軽量がすごく簡単。
衣類用柔軟剤(1): フレアフレグランスドレッシーベリーの香り。特に深い理由はないけど、安かったときに一度買ってから、これもamazonのセールで安くなりがちなので継続して使っている。匂いは結構強め。
衣類用柔軟剤(2): ハミング LINNE 無香性。前述のフレアフレグランスは結構香りが強くて、バスタオルに使うとちょっと微妙な感じだったのでバスタオルを洗うときはこっちを使う。
手洗い石けん: ミューズノータッチ泡ハンドソープ香りが残らないキッチン用。amazonの2月のセールで安かったので、前々から使いたいと思っていたノータッチタイプの物にした。料理中に手を洗っても香りが残らないタイプで、料理を結構する人間には結構お勧め。

PC/周辺機器類

PC: MacBook Pro 13inch 。2018年のモデルで、Core i7 4コア 2.7GHz、16GB RAM、256GB SSDの構成。エンジニアが使うマシンとしては良くある構成だし、特に言うことはない。
タブレット: iPad Pro 11inch + Apple Pencil 。絵を描きたくて買った。が、あんまり活用できていない。最近は#posemaniacs 描いてるけど、へた。
スマートフォン: Pixel 4 。モバイルPASMO使いたいけど、PASMO一体型クレジットカードではオートチャージができないらしく、おこ。
モニタ: LG 27UK-850-W 。USB-PD対応の4Kモニタがほしくて購入したもの。DP OUTはついていない。amazonでめっちゃ安かったのでこれにした。HPのシングルモニターアーム (エルゴトロンのOEM)と合わせて使用している。
プリンタ: NEC MultiWriter 5600C 。A4カラーページレーザープリンタで、AmazonだったかNTT-Xだったか、まぁその辺で激安だったので購入した。基本的に写真を印刷することがないので、インクジェットインクジェットより使いやすい(気がする)。

Bauhutteのデスクごとチェアマットを購入した

Fri, 10 Apr 2020 15:44:39 +0000

昨今の情勢を受け、私もかれこれ一ヶ月以上自宅でリモートワークをしています。自宅でリモートワークをするということは、机に向かう、すなわち椅子に座る時間が圧倒的に増える(一日あたり8時間くらい増えていますね)ことになるわけです。弊宅は賃貸かつ床が(多分)木製のフローリングで、長時間椅子に座るとなると椅子のキャスターによる床の傷つきがきになります。

なにかチェアマットを敷いた方がよかろう、結構椅子を動かすタイプの人間であるからして大きめの物を選ぶべきであろう、という判断の下、大きく、見目もよろしそうであったBauhutteのデスクごとチェアマット(160cmx130cm) を購入しました。

なおamazonのリンクをはってはいる物の、たまたま楽天のポイントが貯まっていたので楽天で購入しました。

届いてみて、確かにこれは大きい。なかなか良いサイズだ、と思ったのですが、さて敷いてみよう、とすると幅がなんとも惜しい感じでありました(これは我が家のデスクとの相性、という話で商品自体が悪いわけではないので注意)。机はニトリの組み合わせデスク、幅140cmの天板に特に何の変哲も無い脚を付けて使っていますが、左脚の外側から右脚の外側までが約135cm、左足の内側から右脚の内側までが約125cmなので、完全に両脚で踏ませることも、内側に収めることもできない、かといって長辺を横向きにすると長すぎるという程度の幅です。前述の様になかなか大きいサイズ、長辺が160ありますから、きれいにカットするのもなかなか困難です。

厚さが1.5mmですから、まぁそれ自体はたいした問題ではないのですが、裏面の滑り止めがくせ者です。確かに滑らないのですが、表面もなかなかグリップ力があるせいか、座った状態で椅子を動かすとマットが波打ち、机の脚のところで引っかかって、机がギシギシ言うのです。

これはちょっとなんとかしたい、と思いチェアマット用の滑り止めを別途amazonで物色中です。また、来週新しい椅子が届く予定なので、椅子が変わったらまた違うのかもしれない、とは思っています。

総じて、現状としては「惜しい」という評価をするしかないのですが、机の幅などの条件が折り合えば、商品の見た目やさわり心地などはなかなか悪くないと思いますので、チェアマットを探している方は検討してみてはいかがでしょうか。

2020-04-11 追記

ニトリのすべり止めテープを貼ったところ、改善しました。三辺(長辺x1、短辺x2)に貼ると長さ4メートルのテープをちょうど良い具合に使い切る感じです。現状は机の脚の一本だけチェアマットにのっている状態で、のっている側の長辺と前後の短辺にすべり止めテープを貼っています。全くギシギシ言わなくなったので、大変良いですね。

2020-05-01追記

裏面の滑り止め加工が裏目に出たのか、ニトリの滑り止めテープが剥がれてきました。つらい。

誕生日パエリア

Wed, 08 Apr 2020 15:38:24 +0000

先日、無事誕生日なるものを今年も迎えることができたのですが、twitterやらfacebookやらに欲しいものリストを貼った結果、皆様いろいろと贈ってくださり、本当にありがとうございます。

ところで、欲しいものリストにパエリアパンなど入れていなかったのですが、なぜか届きました。

家広そうだし入って無くても送ってみっかと思ってポチってみた?
— TᗩKᑌᗰI KOᗷᗩYᗩᔕᕼI (@chamaharun) April 8, 2020

全く以て意味がわからないですね。しかし贈ってくれたのに使わない、というのもなんなので、パエリアを作ることにしました。

なお誕生日パエリアというタイトルですが、今日誕生日、というわけではありません。

材料はこちら。アサリ小パック、パプリカ一つ、鶏肉一枚、エビ、イカ、トマト、米、サフラン、玉ねぎ、ニンニク。鶏肉は一口大に切って軽く塩こしょうしてあります。玉ねぎとニンニクはみじん切りしておきましょう。また、アサリは砂抜きをしました(が、食べたらガリッといった。なんでや。) トマト、パプリカは適当に切りましょう。イカはカット済みのものを買いました。

ちなみにこの中で一番高かったのは(多分)サフランです。サフラン高い。

こちらが件のパエリアパンです。四人前作れるらしい。大きくて端の方に火が入りにくいのではないかと心配です。

さび止めの油が塗ってあるらしいのでそれを飛ばした後、オリーブオイルを適当に熱して、肉やら魚介やらを炒めます。

火が通ったものから一旦どけておきます。特にアサリは火を通しすぎると縮んでしまうので、開いた時点でどけておいた方がいいでしょう。多分。なんかすでにパエリアの匂いがする気がしてきます。

追いオリーブオイルをして、玉ねぎとニンニクを炒めます。ちょっと焦げ付いている？ようなところはこそいでおいた方が良いでしょう。多分これがうま味ってやつです。多分。

玉ねぎがしなっとしてきたら、生米を突っ込んで炒めます。大きいのでフライパンの様に振ることはできません。

どんな状態になったら米に火が通ってきた、といえるのかはよくわかんないんですけど、それっぽい感じになったら水とコンソメ、サフランを加えて一煮立ちさせます。コンソメは多分予めお湯か何かで溶いておくか、顆粒のものを使った方が良かった気がする。

煮立ったらパプリカを入れます。インゲンを入れたい人はここで入れましょう。

トマトさんを入れるタイミングがわからなかったので、「パプリカと同じ赤だしいけるっしょー」とここで投入。まぁ大丈夫。赤いし。

少しぐつぐつさせた後、よけておいた肉やら魚介やらを再投入します。これもタイミングが不明だったので気分で入れました。だいたいなんとかなる。

この状態で十分ほど強火で煮込みます。

十分経ったら弱火にして、水がなくなるというか、どろっとした感じになるまで煮ます。これもなんとなく雰囲気で。多分やり過ぎると焦げる。

良い感じになったら火を止めて、適当なアルミホイルとかで蓋をして(できてない)五分ほど蒸らします。結構これで雰囲気変わるんで大事。

五分経つとこんな感じで汁っ気が飛びます。マジで。

最後によしなにパセリングして完成。うまいです。あと簡単。魚介とかサフランとかそこそこするので、結構自炊ものとしてはお高めだけど、まぁ一回くらいやってみても良いんじゃないでしょうか。なお二人で四人前は多いです。注意。

context.WithTimeoutに0を与えるとどうなるのか

Wed, 08 Apr 2020 04:17:35 +0000

当然と言えば当然なんですけど、特に panic とかそういうことはなく、一瞬でタイムアウトします。まぁ、どうと言うことは無いですが、設定ファイルとかで未定義時に0が来るような実装になっている場合はなんか処理する(0の時は処理をしない、というのは多分あんまりなさそうですし)必要がありますね。

1
2
3
4
5


ctx, cancel := context.WithTimeout(context.Background(), time.Duration(0))
defer cancel()

<-ctx.Done()
log.Print("timeout")

https://play.golang.org/p/63DkfIEImjv

もうちょっと細かい話

さすがに短すぎるので、もう少し細かい実装の話。

context.WithTimeoutは内部的には特別な実装は無くて、context.WithDeadlineをtime.Now.Add(timeout)に対して呼んでいます。

で、context.WithDeadlineは返値を返す前にtime.Untilを使って現在時刻とデッドラインまでの差分をチェックしていて、これが0以下ならその場でキャンセル関数を呼んでいます。

まぁそんなわけで、余分な待ち時間が発生することもなく、time.WithTimeoutを呼んだ時点でちゃんとタイムアウトされる、ということでした。ちゃんちゃん。

Goで(メールサーバを用意せずに)メールを送る

Mon, 06 Apr 2020 10:13:42 +0000

単純な興味というか、特にこれで何かを作るというわけではないのだけれど、ふと思い立って調べてみたら意外と情報が無かったのでメモを残しておきます。

Goでメールを送りたい、と思ったとき、Googleで検索してみると、net/smtp パッケージを使ってgmailのSMTPサーバを使用する、とかSendGridを使用する、とかそういった例ばかりが目につきました。これらはもちろん便利であることは疑いようもない(自前でメールサーバの管理とかやってられないし)んですけど、こういったSMTPサーバやらsendmail/postfixやらを使わなくても、本来SMTPではメールを簡単に送れるはず(なんと言っても「Simple Mail Transfer Protocol」ですから)、と思いました。とはいえじゃぁどうしたら良いのか、と思ったとき、Goを用いた例というのはぱっと見当たらないのです。仕方ないのでtelnetを使用した例を見ながら、telnetでどうやれば自分のgmail宛てにメールが送れるのか、というのを試しました。

具体的な手順というのは、次の様なものです。なお、以下の手順では(macにtelnetが入っておらずインストールして環境がごちゃごちゃするのも面倒だったので)centos:7のDockerコンテナを使用しています。

# nslookup -type=mx gmail.com
Server: 192.168.65.1
Address: 192.168.65.1#53
Non-authoritative answer:
gmail.com mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
Authoritative answers can be found from:
# telnet gmail-smtp-in.l.google.com 25
Trying 74.125.204.26...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 6si12301456pjb.7 - gsmtp
HELO smtp.gmail.com
250 mx.google.com at your service
MAIL FROM:<nasa9084@example.com>
250 2.1.0 OK 6si12301456pjb.7 - gsmtp
RCPT TO:<XXXXXXXXXX@gmail.com>
250 2.1.5 OK 6si12301456pjb.7 - gsmtp
DATA
354 Go ahead 6si12301456pjb.7 - gsmtp
Subject: Test via telnet
From: nasa9084
To: nasa9084.gmail
Hello, world
.
250 2.0.0 OK 1586166529 6si12301456pjb.7 - gsmtp
QUIT
221 2.0.0 closing connection 6si12301456pjb.7 - gsmtp
Connection closed by foreign host.

無事自分のgmailアカウントにメールが届きました。この手順をGoでやってみます。

Anker SoundCore Motion B

Wed, 01 Apr 2020 17:05:46 +0000

自宅では(も)職場と同じくMacBook Pro 13inchを使っていて、デスクに向かうときはLGの4Kモニタをクラムシェルモード、USB type-C接続で使っているんですが、まぁ普通モニタのスピーカーというのはあまりいい音はしません。まぁ、おまけみたいなものなので仕方ないんですけど。そんなわけでモニタからは音を出さず、音はPCのスピーカーから出してました。

私は基本的にあまりPCで音楽を聴く、ということはしない人間なので、特にそれでも不満はないままここまで来たんですけど、先月から新型コロナウイルス感染症(COVID-19)流行のあおりを受けてヘイシャでもリモートワークで仕事をする、という形になりました。そうすると、これまでは帰宅後食事やら風呂やら、の後くらいから寝るまでしか自宅ではPCに向かっていなかったのが一気に一日中へと伸びました。ミーティングの類いもzoomで行うことになり、これを機にスピーカーでも買おうかな、なんて思っていたところ、Ankerがリモートワーク特集でいくつかの商品(元々は4種類か5種類くらい対象商品があったんですけど、売り切れたのか現在は3種類になってますね)が半額、その中にBluetoothスピーカーもある、という話を聞きまして、購入に踏み切りました。

今回購入したのはSoundCore Motion B という商品です。一年半位前に発売された商品で、Bluetooth接続、IPX7規格の防水性能、最大12時間連続再生可能なバッテリーというのが売りの商品です。また、こちらの商品は二台を一台のPCにつなぐことで二台で一つのステレオとして使用できる(わかりにくい)という機能もあります。せっかく半額なのだし、二台買っても一台分、二台でつなぐとどんな感じなのかもちょっとやってみたい、ということで二台購入しました。

届いた商品がこちら。Ankerらしく、小柄なパッケージです。発送はAmazonが代行しているようで、Amazon Japanからの荷物として届きました(が、箱はAmazonの箱ではありませんでした)。輸送用の段ボール箱も小さめだったため、一瞬「二個頼んだよな・・・？」と不安になりましたが、ちゃんと二個入ってました。

箱の上面には商品の売りと内容物が書いてあります。内容物が少なすぎて、左側のWhat’s In The Boxと右側の内容物の間が開きすぎていて戸惑います。

側面。完全防水と12時間再生、との記載があります。完全防水とのことですけど、仕様としてはIPX7なので、防水特性としては1mの水深に30分浸かってもOK、という感じですね。

箱下部のテープ(?)を剥がして開封。飾り気のない白い箱が姿を現します。右側にプルタブ(?)があるので、付属品がはいっている箱で蓋されている、という状態ですね。

白い箱を取り出すと、本体が姿を現します。充電器とかと同じく、薄い袋に入っています。

内容品を取り出した様子。おなじみHappy? Not Happy?の紙とUser Manual、充電ケーブルが入っていました。充電ケーブルはMicro USB Micro-Bです。User Manualはちゃんと各国語で書かれています。

二台積んだ様子。わかりにくいですけど、上部にボタンがついています。これに充電ケーブルを挿して、左右で使用します。

ステレオで接続する場合はまず両方のスピーカーを起動し、ステレオモードにします。スピーカー同士がつながった後(状態変化がわかりにくい・・・)、PCに接続します。 PC側の表示は一台分として表示されます。二台バラバラに管理する必要はない、ということですね。

で、肝心の音ですが、もちろんモニタやPC本体の音より圧倒的に良いと思います。スピーカーとしての音質がすごく良いかというと、まぁBluetoothの時点でそこそこ、という感じだと思いますが、私としては特に問題ない音質です。きちんと右、左から別々に音が出ていて、センターの音はセンターあたりから聞こえている様な気がします。パッケージにもBig Soundと記載がありましたが、音量は大きめだと思います。音量設定を下記スクリーンショットくらいに設定していますが、MBPのスピーカーで音量をバーの真ん中位に設定したときと同じくらいの音量がでています。

まぁみんながみんな二台買うのがいいかというと、それはよくわかんないですけど、すごく高いものという訳でもないので、そこそこのPC用スピーカーを探している、というかたはこれを機に二台えいっと買ってみても良いのではないでしょうか。

サーモンをAnovaでやる

Tue, 03 Mar 2020 05:30:29 +0000

昨晩の晩ご飯として、サーモンを低温調理でやりましたので、記録に残しておきます。なお、使用したサーモンは刺身用のサーモンを使用しています。多分刺身用じゃなくても良いとは思うんですが、ちょっと怖かったので。

使用するサーモンはこちら。近所の西友で割引になっていたもので、300g前後で600円弱だった気がします。二人分です。

水気を適当に拭いた後、半分にざっくりと切ってステンレスのトレー？バット？に置きます。実家にはバットというものは存在しなかったんですが、使ってみると非常に便利です。100均でも売っているので、適当に数枚そろえておくとなんだかんだ重宝します。

塩と水と砂糖を何やら混ぜ合わせたものに浸します。細かい分量はオライリーさんの「家庭の低温調理」を参照してください。なお、私は紙の本を買いましたが、電子書籍で買ってiPadかなんかに表示しながら調理するのがおすすめです。結構厚い本なので、とにかく取り回しがしにくいので。

我が家のバットでは若干サーモンが液体から出てしまうので、キッチンペーパー的なものに液体をしみこませて上からかぶせておきました。この状態で20分ほど放置します。

その間に水槽(というかバケツですけど)を暖めておきます。今回は52度でやります。水道から普通にお湯(できれば少し温度設定をあげたもの)をためるとあたため時間が短縮できます。多分。

20分経過したものがこちら。あんまり見た目は変わってない気がします。

流水でさっと洗って余分な塩気を落とし、ペーパーで水分をとります。なんか筋がピロピロしててキモい。

キャノーラ油をまんべんなくまぶし、ジッパーつきの袋に投入します。写真のものはIKEAの袋です。まだ袋の口は閉じていません。

いわゆる水圧法で空気を抜き、袋の口を閉じて52度で20分やります。あたためている間にソースを作ったりするのですが、昨日はパスタを作ったりもしたので、結局40分くらい放置してしまいました。「家庭の低温調理」には30分までと書いてあったのですが、まぁ40分でも大丈夫です。

ソース単体の写真は取り忘れてしまったんですけど、味噌とディジョンマスタード、蜂蜜、レモン汁、すりおろした生姜、ごま油とキャノーラ油をよしなに混ぜたモノです。適当にスプーンで混ぜても案外ちゃんと乳化するもんですね。

ソースをかけた後七味をかけていますが、買ってから大分たった七味なので、辛みも香りも何もない物体になってしまっていました。

おいしかったです。まる。

emacs/lsp-mode + goplsでGo用のLSP環境を設定する

Fri, 07 Feb 2020 08:19:29 +0000

Language Server Protocol (以下LSP)はこれまでエディタ/IDEが独自に実装する必要があった、補完や定義参照、静的解析によるエラー分析などをサービスとして実現するためのプロトコルです。 LSPを実装したクライアントは、Language Serverを提供している言語であれば何でも補完や定義参照、静的解析といった便利機能を使用することができます。

Microsoftが2016年にその仕様を公開してから、多くのエディタ用のLSPのクライアント実装が作られ、また各種言語用のLanguage Serverも公開されています。

Go言語も例に漏れずLanguage Serverの実装がいくつか存在します。今回は準公式提供のgopls を使用して設定してみます。もちろんemacsにも複数のLSP Client実装がありますが、今回はlsp-mode を使用します。

まずはemacs用のパッケージをインストールします。次のモノをpackage-installかpackage-list-packagesか、そのあたりでよしなにインストールします。

lsp-mode
lsp-ui
company-lsp

インストールできたら、(私はuse-packageを使っているので)設定ファイルにuse-packageの設定を入れておきます。ついでにgo用の設定も入れておきましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


;; Golang
(defun lsp-go-install-save-hooks()
 (add-hook 'before-save-hook #'lsp-format-buffer t t)
 (add-hook 'before-save-hook #'lsp-organize-imports t t))

(use-package go-mode
 :ensure t
 :mode (("\\.go\\'" . go-mode))
 :init
 (add-hook 'go-mode-hook #'lsp-go-install-save-hooks))

;; Language Server
(use-package lsp-mode
 :ensure t
 :hook
 (go-mode . lsp-deferred)
 :commands (lsp lsp-deferred))

(use-package lsp-ui
 :ensure t
 :commands lsp-ui-mode)

(use-package company-lsp
 :ensure t
 :commands company-lsp)

goplsのインストールもしましょう。

Flutter環境構築 with emacs

Sat, 18 Jan 2020 15:18:55 +0000

ここ数日、FlutterでAndroidアプリを書く、ということに入門してみています。 Androidアプリの開発自体は大分前(無印Galaxy Sを使っていた頃なので、EclairとかFroyoとかの頃)にすこしだけやったことがあるんですが、そのころと比べるとかなり簡単に、きれいなアプリがシュッと動いて、ちょっとばかし感動しています。

扨、Flutter/Android開発の環境構築ですが、ほとんどのドキュメントがAndroid Studioを前提としており、私のようなemacsユーザがどうしたらいいのか、ちょっとばかし躓きそうなので、メモがてら残しておきます。

なお、基本的な手順は公式サイトに準じます。また、環境はmacOS Catalina バージョン 10.15.1、emacsはbrewで入れるemacs-mac 26.3です。 Flutterのバージョンは執筆時点でv1.12.13+hotfix.5でした。

Flutter SDKのインストール

公式サイトのダウンロードリンクからFlutter SDKをダウンロードしてきて解凍、任意の場所に配置します。私はなんとなくで$HOME/.local/flutter以下に配置しています。

1
2
3


$ wget https://storage.googleapis.com/flutter_infra/releases/stable/macos/flutter_macos_v1.12.13+hotfix.5-stable.zip
$ unzip flutter_macos_v1.12.13+hotfix.5-stable.zip
$ mv flutter $HOME/.local/

配置できたらPATHを通します。私はzshを使っているので、$HOME/.zshrcに以下の行を追加しました。

1
2


# Flutter SDK
export PATH="$PATH:$HOME/.local/flutter/bin"

PATHを通したら、flutter --versionでちゃんとPATHが通っているかを確認します。

Android SDKのインストール

公式サイトの手順ではAndroid Studioを入れろとのことですが、emacsを使う予定なので、Android Studioはインストールせず、Android SDKのみをインストールします。 Android Studioのサイトへアクセスし、DOWNLOAD OPTIONS をクリックしてCommand line tools onlyのところからmacOS用のCommand line toolsをダウンロード、Flutter SDKと同様に適宜配置してPATHを通すか、簡単にbrew cask install android-sdkとします。私は今回はbrewで入れました。(Flutter SDKもbrewで配布されていますが、Flutter SDKは少し古かったので、公式からダウンロードしてきた方が良さそうです)

brew cask install android-sdkをしたときにもメッセージが出ますが、android-sdkを使用するにはJDK 8が必要なので、brew cask install adoptopenjdk8としてJDKもインストールしておきます。

2019年の振り返り

Wed, 08 Jan 2020 04:58:54 +0000

‌

2020年に入って早1週間が経過しましたが、皆様いかがお過ごしでしょうか。一年の振り返り！みたいのはあんまりやるつもりがなかったのですが、あまりにもみんなやっていて目につくので、これはやった方が良い物なのか・・・と思い直し、遅ればせながら振り返ってみようかと思います。

1月

そういえば2018年振り返りみたいなブログ書いてないんですが、2019年は心おだやかに生きたいと思っております
— nasa9084@某某某某(0x1a) (@nasa9084) January 3, 2019

twitterによると、2019年は心おだやかに生きたいというのが目標だった様子。あまり心穏やかには生きられませんでした。合掌。

そういえば昨年は年明け早々インフルエンザにかかったんでした。

一月はLOCALのイベントに行ったり、YAPC::Tokyoに行ったりしていた様子。ここ半年はカンファレンス/勉強会参加数も減ってきてしまっているので、ここらでちょっと頑張りたいところです。

2月

ONIconをやったり、自作ケーブルを作り始めたり。

gomaconfやcookpadtechconfもこのあたりだったようです。

3月

ペティナイフが欲しい
— nasa9084@某某某某(0x1a) (@nasa9084) March 1, 2019

ペティナイフ、ネット上でもいろんな人が「便利！」って言ってて、しかしまぁ三徳で不自由してなかったんですけど、買ってみたら実際メチャクチャ便利で、正直三徳よりペティを使うことの方が圧倒的に多い。

LINE.goというイベントを開催したのも3月でした。

朝ご飯 pic.twitter.com/PLRDDJEOCY
— nasa9084@某某某某(0x1a) (@nasa9084) March 4, 2019

ご神体は今も職場の机にまつられています。なんと今は鳥居もついています

4月

皆さん技術書典の進捗どうですか
— nasa9084@某某某某(0x1a) (@nasa9084) April 2, 2019

今もまた、技術書典の進捗に追われています。

たいした意味もなく近所のコインランドリーで枕を洗濯した結果、ドラム式洗濯乾燥機がほしくなってる
— nasa9084@某某某某(0x1a) (@nasa9084) April 12, 2019

この後勢いよくドラム式洗濯機を買いました。最高。

5月

PyCon mini sapporoが5月だったらしいです。GoConでしゃべったのもこのあたりだったらしい。

改めて。でかい。 pic.twitter.com/zO9TLfdhy8
— nasa9084@某某某某(0x1a) (@nasa9084) May 29, 2019

OSC19doも5末〜6始でしたね

6月

鰹節食べ放題 pic.twitter.com/c6ouIwcHis
— nasa9084@某某某某(0x1a) (@nasa9084) June 11, 2019

ところで、まとめを書くのも疲れてきました。

7月

Golang 101を開催したのが7月だったようす。またやりたいんですが、会場が難しいですね。

進捗です pic.twitter.com/cbZGgdeHiA
— nasa9084@某某某某(0x1a) (@nasa9084) July 27, 2019

次の技術書典に向けて、これの第二巻を書いています。

趣味サーバーのインフラを再構成した件

Mon, 06 Jan 2020 09:06:45 +0000

明けましておめでとうございます。本年もどうぞよろしくお願いいたします。

扨、もう一昨年になりますが、趣味サーバーのインフラをKubernetesで整えた件という記事を投稿しました。その後紆余曲折ございまして、これらを再構成しましたので、改めて記録に残しておこうと思います。

紆余曲折

まずは紆余曲折とは？という話から始めましょう。

当時、Kubernetes用のPersistent VolumeはGlusterFSを使用していました。最初はこれで問題なかったのですが、一部のアプリケーション(具体的にはRedmine)を動かしていく上で、非常に速度が遅い、ということが問題となりました。調査の上、どうやら遅い原因がGlusterFSであり、Cephに置き換えることである程度速度を改善することができそうだ、という見込みが立ったため、前述の記事を投稿してから約二ヶ月後にGlusterFSをCeph RBDへと置き換えました。

その後、NTT-X Store でSSDが安かったため、12台ほどSSDを購入、すべての物理ボリュームをHDDからSSDに置き換え、RAID1+0で再構成しました。同時に、以前はローカルボリュームを直接使用していたOpenNebulaのストレージ部も分散構成にするべく、物理マシン上に直接Cephを構成、これをOpenNebulaとKubernetesでシェアする形にしました。

これでうまくいったか？と思ったのですが、どっこい、どうやらDL360G6のRAIDカードとSSDの相性(しかもファームウェア単位)が悪いらしく、一週間〜一ヶ月程度で、故障もないのにRAIDから抜けてしまう、という問題が発生しました。

on Kubernetes on OpenNebulaで稼働していた本ブログの運用にも影響が出たため、一旦本ブログを(今は亡き)CloudGarage へと退避、SSDの交換をNTT-X Storeへと申請しました。

その後無事SSDは新品交換され、その間に某社から廃棄するということでいただいてきたDL360G7が三台ほど導入されたため、これを基盤として再度プライベートクラウド基盤を構築することと相成りました。

現在の構成

再構成した、とはいえ、構成は大きくは変わっていません。 IaaS基盤としてOpenNebula/KVMを使用しているのも変わりませんし、コンテナ基盤としてKubernetesを使用しているのも変わりません。

強いて言えば、本ブログのストレージは最近までSQLiteを使用していましたが、外部MySQLへと移行したくらいでしょうか。

物理層

物理サーバとしては前述の通り、DL360G7を使用しています。適当にメモリを増設しており、それぞれ次の様になっています。

8コア16スレッド、36GB
8コア16スレッド、47GB
8コア16スレッド、49GB

メモリの量はできるだけそろえたかったんですが、~~計算が面倒~~うまくそろえることができませんでした。

OSはCentOS 7を使用しています。最初はCentOS 8でやろうとしたんですが、もろもろパッケージがうまくインストールできず、7に落ち着きました。なんとかなってくれ。

これらに、OpenNebulaおよびCeph MIMICをインストールしてあります。Ceph Nautilusにアップデートしたいんですが、安定しているのだろうか・・・

VM層

OpenNebula/KVMを使用したIaaSの上にVMをポチポチと立てられるようになっています。OpenNebulaのストレージはCephを使用しています。VMも基本的にはCentOS 7を使用しています。

また、DBやPrometheusなど一部のアプリケーションをVMとして構築してあります。以前はK8s上でPrometheusなども管理していたのですが、(主にストレージの)管理が面倒だったので、今回はVMにDockerをインストールして個別に起動しています。

コンテナ層

コンテナ基盤はKubernetesで、相も変わらずKubespray を使用して構築しています。便利便利。現在はKubernetes 1.16.3です。

PersistentVolume用のStorageClassはPM上のCephをOpenNebulaと共用で使用しています。手前味噌ですが、Ceph RBDをKubernetesのStorageClassとして登録するを見ながら設定しました。

Service type LoadBalancerの実装としてMetalLB を、Ingress実装としてNGINX Ingress Controller を導入してあります。また、HTTPSの証明書を自動設定するため、cert-manager を導入しています。以前はうまくインストールできないことがあり困ったりもしたのですが、今回は特にトラブルもなくスムーズに導入できました。だいぶCRDの構造が変わっていたので、以前導入していて、再度構成する必要がある人は注意が必要かもしれません。

証明書を取得する方法はDNS01で、CloudFlareを使用しているのも変わりません。

go-openapi を書き直しています

Fri, 20 Dec 2019 08:15:39 +0000

本記事はGo2 Advent Calendar の20日目の記事です。昨日はyaegashiさんによる、jsonx.go でした。

皆さんはOpenAPI Specification というモノをご存じでしょうか。OpenAPI SpecificationはJSONまたはYAMLでREST APIを表現するための仕様で、現在バージョン3.0.2 が最新です。いわゆるSwagger の後継で、バージョン1系、2系がSwagger、3系以降がOpenAPI、ということになっています(Swaggerなら聞いたことがある/使っているという人も多いのではないでしょうか)。

OpenAPI Specificationは人間にも機械にも(比較的)読みやすい仕様書として、コード生成や、ドキュメントページの生成に使用することが可能です。

個人的には専らコード生成に使用しており、Go言語向けの実装としてgithub.com/nasa9084/go-openapi (以下go-openapi)を実装・公開しています。 go-openapiは2017年ごろから細々と実装を続けており、(多分)二番目か三番目には古いと思われるOpenAPIのGo実装です。

基本的にはただひたすらOpenAPIのオブジェクトをGoの構造体として定義、値のバリデーション関数を用意しているといったもので、特別な機能はほとんどありません。 YAMLのパーサも、go-yaml/yaml を使用しており、自前では実装していません。

そんな中、@goccy さんが、encoding/jsonとコンパチなインターフェースを持ったYAMLパーサを開発した、という話を耳にし、これを機に、とgo-openapiの実装を一から書き直し始めました。もともと、パースは完全にgo-yaml/yamlに依存しており、Unmarshal系のメソッドも実装していなかった(途中から全部書くのはつらかったので・・・)ため、一部バリデーションに必要な関数を埋め込んだりもできなかったので、書き直したいとは思っていたのです。

現時点ではまだマージしておらず、書いている途中なのですが、大きな変更点として次の様なものがあります。

もともとパブリックだったフィールドをすべてプライベートに変更し、ゲッターをはやした
各構造体に対応するUnmarshalYAML()メソッドをすべてコード生成するようにした
YAMLパーサはgithub.com/goccy/go-yaml に乗り換えた
rootオブジェクトを各構造体に埋め込むことで、バリデーションをとりやすくした

今後はよりコード生成に便利なメソッドを追加していきたいと思っています。

時間の都合で今日はここまで。技術的な話が全然無い記事になってしまった・・・

builderscon tokyo 2020やるぞ！という話

Tue, 03 Dec 2019 09:00:00 +0000

buildersconは「知らなかった、を聞く」あるいは英語で “Discover Something New"をスローガンとした、IT技術者向けの技術カンファレンスです。2016年、2017年、2018年、2019年と@lestrrat さんが主催として開催してきて、私もコアスタッフとして関わってきました。

そんなbuildersconですが、2020年は子育てで多忙な@lestrratさんに代わり、私(@nasa9084 )が主催として開催に向けて準備を進めていくことになりました！

まぁ、今のところはやるぞ！という話だけで細かい話はこれからですが、皆さんどうぞよろしくお願いいたします。

net/http.ClientにHookをかける

Fri, 01 Nov 2019 05:48:19 +0000

昨日のこと。jszwedko/go-circleci というパッケージを使用してCircleCI EnterprizeのAPIを叩くという処理を実装していたのですが、どうにもうまくいかない。正直に言ってこのパッケージはドキュメントがしっかりしている、という訳ではないし、エラーメッセージを見ても何がだめなのか(そもそも現在使用しているCircleCI Enterpriseで使用できるかもよくわかっていなかった)わからない。

しかしまぁ、自分でHTTP requestを作ったりしてあれやこれややるのもまぁ面倒であるので、なんとかデバッグしたいと思ったのですが、外部のパッケージをフォークして変更を加えてデバッグする・・・という様なことはもちろんやりたくないわけです。

このパッケージは*http.Client を指定できます。*http.Clientはインターフェースではなく構造体なので、別の実装に置き換えるということはできません。が、その実装はほぼほぼ後述するhttp.RoundTripperなため、http.RoundTripperをラップして、HTTP requestとHTTP responseをログに吐けばまぁ、何が問題かわかるだろう、と考えました。そんなモノは誰かがすでに書いているだろう、というのはさておき、http.RoundTripperを実際にいじってみるということはやったことがなかったので、勉強がてらnasa9084/go-logtransport なるものを書きました。書いていく途中で、考えたことなど、記録に残しておくのも良さそうと思ったため、本記事とします。

http.Clientとhttp.RoundTripper

Go言語でHTTPのリクエストを発行するには基本として*http.Client というものを使用します。簡便のため、GET 、POST 、Head についてはパッケージグローバルの関数も用意されてはいるのですが、これらも内部的にはパッケージグローバルで宣言されたDefaultClient という*http.Client が使用されています。

*http.Clientはゼロ値で使用できるようにまとめられた構造体で、DefaultClient は*http.Client{}と宣言されています。

普段はこの*http.Clientを使用してHTTPの通信を行うわけですが、実は*http.Clientはそれほど多くの機能は持っていません。実際、持っているフィールドはたったの4つ(Go1.13時点)しかないのです。*http.Clientはリダイレクトやクッキーなどの一部の処理だけを受け持っていて、実際のHTTP通信のほとんどはフィールドとして保持しているhttp.RoudTripperが行います。

http.RoundTripperはインターフェースとして定義されていて、自由に差し替えをすることができます。特に指定していない場合は*http.Transportがデフォルトの実装として使用されます。 Goの他の標準パッケージの例に漏れず、http.RoundTripperは非常にシンプルなインターフェースで、次の様に定義されています。

1
2
3


type RoundTripper interface {
 RoundTrip(*Request) (*Response, error)
}

RoundTrip()がHTTP requestを受け取り、HTTP responseを返します。つまり、requestのログをとり、子RoundTripperのRoundTrip()を実行し、Responseのログをとってそのまま返す、という様なラッパーを書けば良さそうです。

1
2
3
4
5
6
7
8
9


func (t *Transport) RoundTrip(r *http.Request) (*http.Response, error) {
 // Requestのログをとる

 resp, _ := t.Transport.RoundTrip(r)

 // responseのログをとる

 return resp, nil
}

実際にrequestとresponseのログをとるには、net/http/httputilパッケージのDump系関数が使用できます。今回はクライアント側の実装なので、httputil.DumpRequestOutとhttputil.DumpResponseを使用します。

空文字列確認は長さをとるべきか？

Wed, 09 Oct 2019 07:02:52 +0000

TL;DR

s == ""とlen(s) == 0は等価

文字列比較か、長さ比較か

Go言語で文字列が空かどうかを調べるには次の二つの方法があります。

1
2
3
4
5
6
7
8
9


// 1: 文字列を空文字列と比較する
if s == "" {
 // do something
}

// 2: 文字列の長さが0かどうか調べる
if len(s) == "" {
 // do something
}

標準パッケージ・サードパーティパッケージともに、どちらの書き方も散見されます。どちらを使うのが良いのでしょうか？

答えはどちらでも良いだそうです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


package benchmark_test

import "testing"

var somethingString = "hogehogefugafuga"

func BenchmarkCompareString(b *testing.B) {
 for i := 0; i < b.N; i++ {
 if somethingString == "" {
 }
 }
}

func BenchmarkCompareStringByLength(b *testing.B) {
 for i := 0; i < b.N; i++ {
 if len(somethingString) == 0 {

 }
 }
}

このコードに対して go tool compile -Sした結果が以下。 BenchmarkCompareStringとBenchmarkCompareStringByLengthでは同じ内容となっています。

Unuboでアプリケーションをサクッとデプロイする

Thu, 26 Sep 2019 15:10:40 +0000

Unubo というPaaSっぽいものが出てきたようなので触ってみました。まだリリースされたばかりのようで、クレジットカードの登録もせずに無料で使用できます。

とりあえず適当にリポジトリを作って動かしてみました。登録・ログインを済ませたら、使用したい機能を選択します。今回はGoのアプリケーションなので、AppsセクションにあるGoのアイコンを選択しました。

次の画面でアプリケーション名を入れ、デプロイ先のリージョンを選択します。 DBと接続する場合はDBと同一リージョンじゃなきゃ接続できないそうです。

最後に、細かい設定をできる画面になりますので、必要な情報を入力します。ここでは、とりあえずGitHubとの連携をして、リポジトリを選択するだけであとは放置します。

最後にDeployボタンをポチッとしてデプロイされるのを待ちます。どうやら、Deploy成功からアクセスできるようになるまで若干タイムラグがあるようなので、気長に待ちましょう。

有料プランが出てから価格設定や無料枠がどうなるかわかりませんが、まぁぼちぼち便利に使えそうですね。

技術書典7でGo言語の本を頒布します

Thu, 19 Sep 2019 01:00:00 +0000

今週末はいよいよ技術書典7ですね！

今回はGo言語の標準パッケージの解説本を頒布予定です。

web-apps.tech: サークル詳細ページ

当初の予定では全パッケージを詳解！みたいな予定だったんですが、ページ数が増えまくった結果、残念ながら26個しか詳解できませんでした。

108ページで一冊1,000円、電子版もあるよ、の予定です(電子版と両方での割引をどうしようか今考えてます)。サークルスペースは「か11C」です。

社用Gitサーバでは社用のメールをつかう.gitconfig 〜社内ドメインを外に漏らさない編〜

Sat, 24 Aug 2019 04:36:12 +0000

GitHubのコミットログ、コミットした人のアイコンが出ていてとてもわかりやすいですよね。コミットとアカウントの紐付けにはどうやら、コミットに紐付けられたメールアドレスが使用されているようです。そうなると、コミットに紐付ける(git config user.email=...とかやるアレです)メールアドレスはアカウントに登録してあるメールアドレスにしたいものです。

しかし、会社ではGitHub Enterprise(GHE)、私用ではgithub.com を使用している、と言った場合はどうでしょうか。コミットに紐付けたいメールアドレスがリポジトリによって変わる、ということになってしまいます。

調べてみると、そういった場合、次の様に.gitconfigにIncludeIfのブロックを設定することでうまく回避ができそうということがわかり、しばらく設定していました

1
2


[IncludeIf "gitdir:~/src/GHE_DOMAIN"]
path = "~/.gitconfig.ghe"

~.gitconfig.gheには次の様に書かれています。

1
2


[user]
email = 社用メールアドレス

私はGo言語をよく書くのと、ghq を使っている都合上、gitのリポジトリを配置するパスが$(GOPATH)/src/GIT_DOMAIN/USERNAME/REPOSITORYという形式になっているため、リモートリポジトリのドメインを指定することでうまいこと社用GHEの時だけ設定を上書きすることができていたのでした。

そしてこれは、どのPCでも使用できるように、dotfilesリポジトリとしてgithub.com にpushしていました。

その結果、会社の人から、「社内のサービスのURL(この場合はGHEのURL)はセキュリティ的な理由から外に出さないようにしてほしい」と連絡を受けました。すぐさま該当のブロックは消したのですが、そうするとメールの設定が自動でされなくなってしまい不便です。リポジトリのパスを変更するというのも、せっかくの統一的な操作に違いが出てしまい、不便です。

そこで思いついたのが、こういったセンシティブな情報を別のプライベートリポジトリに分け、Makefile でインストールを自動化するという方法です。

パブリックなdotfilesリポジトリにある.gitconfig には次の様に書いてあります。

[include]
path = ~/.gitconfig.secret

.gitconfig.secretはその名の通り、秘匿情報を含んだ.gitconfigで、プライベート化されたdotfiles-secretリポジトリにおいてあります。dotfiles-secretリポジトリはmake installとしたときにgit cloneされ、さらにそのディレクトリ内のMakefileにより配置されます。dotfiles-secret/.gitconfig.secretには先ほどのIncludeIfブロックが書かれており、同リポジトリ内の.gitconfig.secret.ghe(名前を少し変えました)を読み込みます。

これで、全体の使い勝手をほとんど損なうことなくどのマシンでも(dotfilesが配備済みなら)同様に設定することができました。

Makefileは特にdotfilesのリストを持たないよう記述しているため、新しいdotfileが増えても、特にMakefileの変更をする必要も無く安心です。

hubコマンドにGitHub Enterprise環境を追加する

Thu, 22 Aug 2019 10:30:00 +0000

hub コマンドをご存じでしょうか。インストールしてalias git=hubと設定するだけで、gitコマンドからGitHubの操作ができるようになる優れものです。特に個人的にはgit createとするだけでGitHub上にリポジトリが作成される、というのが非常に便利だと思っています。

さて、皆さんの会社ではgitサーバはどのように構築されているでしょうか。いろいろな選択肢がありますが、それなりの規模だとGitHub Enterprise(以下GHE)を利用している、という会社も多いと思います。実際、現職ではGHEを使っています。

そのような場合、趣味/個人の開発ではgithub.com、会社ではGHEと使い分けることとなりますが、GHEでhubが使えないとすると非常に不便です。そう考えて調べてみると、Web上では、hubをGHE環境で使うには環境変数を使うとする設定例が散見されます。

しかし実は、hubは複数環境での使用をサポートしているんです。設定方法は至って簡単で、$HOME/.config/hubに設定を書き足すだけです。実際に見てみましょう。

すでにhubを使っている場合、cat $HOME/.config/hubで設定を見ることができます。私の場合、次のようになっていました(oauth_tokenは潰してありますが、実際にはトークンが入っています)。

1
2
3
4


github.com:
- user: nasa9084
 oauth_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 protocol: https

どんな項目かは明らかですね。ここに会社のGHEの環境に関する情報を追記します。まず、自社のGHEのアドレス以下/settings/tokensを開きます。Generate new tokenボタンをクリックし、新規でPersonal access tokenを発行します。名称はわかりやすい物を任意で付けてください。hubはリポジトリを操作するコマンドですから、scopeはrepoを与えれば十分でしょう。画面下部のGenerate tokenボタンをクリックすると、トークンが発行されますので、これをコピーしておきます。

手元のエディタ(お好みの物を使用してください)で$HOME/.config/hubを開き、設定を追加します。

1
2
3
4


YOUR_GHE_DOMAIN:
- user: YOUR_USERNAME
 oauth_token: YOUR_TOKEN
 protocol: https

オブジェクトのキーとしてGHEのドメインを、userはGHEでログインに使用するユーザ名を使用します。oauth_tokenに先ほど生成したPersonal access tokenを設定し、保存します。保存できたら、hubでGHEにアクセスができるようになっているはずです。

実際に使うと、次の様にどのホストを使用するか聞かれ、好きな方を選べるようになっています。

1
2
3
4
5
6
7


$ git create
Select host:
 1. github.com
 2. YOUR_GHE_DOMAIN
> 1
Updating origin
https://github.com/nasa9084/REPOSITORY_NAME

Raspberry Pi zero W + IR

Tue, 30 Jul 2019 15:11:28 +0000

家で~~転がっていた~~使われないでいたRaspberry Pi zero Wを使って、家庭内のリモコン機器を自動化しようと思い立ち、秋葉原くんだりまで行って諸々部品を買ってきました。

ゴミを二つほど生成したのち、最終的に動くモノができましたので備忘録的に残しておきます。

pic.twitter.com/e55qxX5GL6
— nasa9084@某某某某(0x1a) (@nasa9084) July 29, 2019

主に「格安スマートリモコンの作り方」を参考にしました。部品を購入した店は秋月電子で、商品ページの下の方にある「店舗情報」のリンクをクリックすると店内のどの棚に商品があるのかわかり便利です。どの部品も特に珍しい部品ではないため、商品自体がなくなっているようなことは(Pi zero用ユニバーサル基板をのぞき)まず無いように思えます。また、手持ちで0Ω抵抗が(なぜか)在庫してあったため、ジャンパ線代わりに使用しています。一番見つけづらかったのがPi zero用ユニバーサル基板ですが、これは店の中ではなく、外のRaspberry Pi関連部品が置いてあるところにありました。

上記のQiita記事はさほど古いモノではないため、価格も変わってなかったように思えますが、動くモノができるまでにゴミを二つほど生成した都合上、三倍程度のコストがかかりました。回路周りや半田付けがあまり得意ではない人は覚悟(というほどの額ではないですが)しておいた方が(材料を余分に買っておいた方が)良いでしょう。

余談ですが部品を購入した際、近くのあきばおーでTranscendのmicro SDが安くなっていたため、大して使い道も考えずに32GBのモノを5枚ほど購入しました。

ほとんどの情報は参考にしたQiita記事にまとまっているため詳細は端折りますが、変更点として赤LEDを足してあります。ピカッと可視光が光るので、実行されたということを確認するのに便利です。

参考記事には実際の配線図だけはなかったので、紹介します。

上図が部品面、下図が半田面です。MOSFET 2N7000は平らな面が図の上側、MOSFET IRFU9024NPBFは放熱板(?)が図の下側、赤外線LEDは欠けている側(カソード？)が図の右側、赤LEDは欠けている側が図の左側、赤外線受光モジュールOSRB38C9AAは受光部が図の上側を向くように配置します。私は受光モジュールは図の下方向に向けて折り、受光部が天を向くような形にしました。ブレッドボード上で配線してそのまま基板に移植したような形になっているため、複雑な配線もなく比較的簡単かと思います。 IRFU9024NPBFの左下はジャンパなので、半田面で配線してもかまいません(私は0Ω抵抗を使用した関係で部品面を通しています)。

実際に配線したもの。右側に温度センサを追加しています

赤外線コードの学習・実行も参考記事通りpigpioを使用しましたが、毎度SSHしてコマンドを実行するのは面倒なため、GoでAPIサーバを実装しました。Goで赤外線をGPIOでいい感じにアレするようなパッケージが見当たらなかったので、GoからPythonのスクリプトを叩くという残念なコードになっております。いいパッケージがあれば誰か教えてください。

systemdかなんかでデーモン化したりなんかして起動しておくと、例えば、

1

$ curl http://raspberrypi.local/playback?key=light:off

とかすると部屋の電気が消せます。素晴らしい。

今のところ外部に公開してはいないのですが、外部に公開すると他のサービスとの連携(例えばIFTTT)ができないので、公開したい気持ちがあります。とはいえ、外からむやみに部屋の電気をあれこれされても困るし(だれもやらないとは思いますが)、そのまま公開するのも難しいな、と思っているところです。

とりあえずは扇風機とか、そのあたりをなんかいい感じにアレしたいですね。

NATSを触ってみた

Wed, 06 Feb 2019 07:52:05 +0000

NATS はCNCF (Cloud Native Computing Foundation)によってホスティングされているメッセージングシステムです。軽量で高パフォーマンスかつスケーラブルなのが特徴だそうです。オランダのSynadia社が中心となって開発を行っていますが、オープンソースソフトウェアなのでGitHub 上で今トリビュートすることもできます。 Go、NodeJS、Ruby、Java、C、C#、Nginx用のクライアントライブラリはSynadiaによってサポートされており、そのほかにもPythonやElixir用のクライアントなどが存在します。 NATSのサーバ自体(gnatsd)はGoで書かれているため、バイナリ一つで起動できるほか、、公式DockerコンテナイメージやKubernetes用のOperator も用意されているため、簡単に構築・運用することができます。本記事でも、Dockerで起動したサーバを使用しています。

NATSでは3種類のメッセージングモデルを利用することができます。

Publish/Subscribe
Request/Reply
Queueing

今回はPub/SubとRequest/Replyを試してみます。

サーバを立ち上げる

実験に先駆けて、まずはサーバを立ち上げます。今回はmacOS High Sierra環境のため、docker for macで起動してみます。

1

$ docker run --rm -d --name nats -p 4222:4222 -p 6222:6222 -p 8222:8222 nats:1.4.0-linux

nats:1.4.0-linuxは執筆時点(2019-02-06)でnats:latestです。ここで三つのポートを空けていますが、それぞれ用途は次の通りです。

:4222: client port
:6222: route port
:8222: http port

それぞれの詳細な説明は割愛しますが、本記事ではクライアントからの接続だけを試してみますので、4222番ポートだけの開放でも問題ありません。

Publish/Subscribe

まずは標準的なPub/Subモデルから試してみます。NATSのPub/SubはRedisなどと同様、Wikipedia でいうところの「トピックベース」なPub/Subです。NATSではトピックのことをSubjectとよびます。 NATSのSubjectは階層構造をとることができ、.(ドット)で区切って表現します。Subscriberはこの階層構造の一部にワイルドカードとして*(アスタリスク)を使用することができます。また、>を使用して下の階層すべて、を表現することもできます。例えば、Subscriberがfoo.bar.*を購読している場合、foo.bar.bazやfoo.bar.quxなどのメッセージを受け取ることができますが、foo.bar.baz.quxは受け取ることができません。一方、foo.bar.>を購読している場合、foo.bar.baz.quxも受け取ることができます。

サンプルコードとして、次のようなものを書いてみました。

Publisher

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


package main

import (
 "log"

 nats "github.com/nats-io/go-nats"
)

func main() {
 nc, err := nats.Connect("localhost:4222")
 if err != nil {
 log.Fatal(err)
 }
 defer nc.Close()

 if err := nc.Publish("subjectFoo", []byte("bodyBar")); err != nil {
 log.Fatal(err)
 }
}

Subscriber

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


package main

import (
 "log"

 nats "github.com/nats-io/go-nats"
)

func main() {
 nc, err := nats.Connect("localhost:4222")
 if err != nil {
 log.Fatal(err)
 }
 defer nc.Close()

 sub, err := nc.Subscribe("subjectFoo", callback)
 if err != nil {
 log.Fatal(err)
 }
 log.Printf("Subject: %s", sub.Subject)
 log.Printf("Queue: %s", sub.Queue)
 ch := make(chan struct{})
 <-ch
}

func callback(message *nats.Msg) {
 log.Print(string(message.Data))
}

それぞれ、適当なファイルに保存し、go runで起動します。あらかじめSubscriber側を起動しておくことで、Publisherを起動した際にメッセージ(今回は"bodyBar")が(Subscriber側で)Printされるはずです。ポイントは*nats.Conn.Subscribeが非同期な関数で、メッセージを受け取った際にcallback関数が呼ばれる、というところです。今回のサンプル中では<-chとしてブロックしていますが、何らかの方法でブロックしないと、受け取る前にmainが終わってしまうので注意が必要です。同期処理したい場合には、*nats.Conn.SubscribeSyncを使用することで次のように書き換えられます。

初めての自作ケーブル

Mon, 04 Feb 2019 17:00:46 +0000

こんばんは。以前記事にしたように、現在、職場でErgodox EZ というキーボードを使用しています。これは元々は自作キーボードの一種で、左右分割型のキーボードです。

Ergodox EZでは、右のキーボードと左のキーボードはTRRSケーブルという、4極のイヤホンケーブルみたいなケーブルで接続されています。今まではとりあえず購入時に付属していたケーブルを使用していたのですが、だんだん肩が開いてきて、長さが足りないなーというお気持ちになってきました。どうせならおしゃれなケーブルがいいなぁと思いながら通販サイトで探したのですが、このTRRSケーブル、あまり需要がないのか、種類が多くありません。

じゃぁ自作キーボード勢はどうしてるのだろうか、と思って調査したところ、諦めて売っているものから選ぶか、自作するか、という選択肢のようでした。自作すれば自分好みの色や長さで作れるし、ケーブルくらいなら作れそう！ということで自作ケーブル沼に入門してみました。

今回作ったのはこちら。遊舎工房さんで販売されている、自作ケーブルキットです。はじめは部材を個別にそろえて作ろうと思っていたのですが、自作キーボード界隈のDiscordサーバで聞いたところ、最初はこちらのケーブルキットが個別にパーツをそろえるよりも安くておすすめ、と言うことなので早速遊舎工房さんに向かい購入してきました。

セットの内容を確認していきましょう。まずはプラグ。4極の3.5mmフォーンプラグです。Ergodox EZは向かって奥の方にジャックがあるため、L字型なのはうれしいですね。

次は熱収縮チューブ。こちらは購入時に色を選ぶことができます。今回は無難に白を選択しました。

こちらはパラコード。元々はパラシュートなどのひもに使われるらしいのですが、今回はケーブルカバー的なものとして使用します。こちらも色を選ぶことができ、黒を選択しました。

これはスリーブです。パラコードの上からかぶせておしゃれ感を演出します。これ、なんて調べたら売ってるのを見つけることができるんでしょうか。

最後にケーブル本体。50cmです。上からパラコードをかぶせるため、なんかよくわからない色です。

実際に作業していきます。まずはパラコードの中にケーブルを通していきます。パラコードの中には白いひもが入っていますが、これを抜いてあいたスペースにケーブルを通します。ちょっとずつ、パラコードを縮めてひっぱってを繰り返して、ケーブルが全部入りきるまで差し込みます。

こちらが挿入し終わったもの。パラコードはケーブルより長めに用意されているのですっぽり隠れました。

さらに上からスリーブをかぶせます。スリーブの端は非常にほどけやすく、最初入れるのが難しかったです。要注意。

片方の恥をテープで留め、ケーブルを露出させました。露出させた長さはプラグに合わせてあります。

被覆を剥いた状態。四軸のケーブルです。非常に細いため、被覆を剥く時に切ってしまわないかドキドキでした。予算に余裕があればケーブルストリッパーを用意してもいいかもしれません。

ケーブルを端子に半田付けしていきます。冒頭にも書いたように、「ケーブルくらいなら作れそう！」とか思ってましたが、これめっちゃ難しいです。3.5mmフォーンプラグなんで、端子もめっちゃ小さいです。上の方(写真中黄色の線)から付け始めてしまったので、余計難易度が増しました。

反対側の半田付け。これを始める前に端子のカバーと熱収縮チューブをケーブルに通しておきます。そして二度目はさすがに学び、きちんとケーブルの長さを端子にそろえる、下から半田付けを始める、などにより少しきれいにつけれるようになりました。

残念なことにテスターを用意していなかったのでテストしていませんが(大丈夫か？)、この時点で導通とショートしてないかをテストしておくべきでしょう。

半田付けが終わったら熱収縮チューブをネジの直前まで持ってきて温めます。最初はヒートガンを買おうと思ってたのですが、秋葉原で売っていたものはamazonで売ってる安いやつより高かったのと、思ったよりサイズがあってびびったので購入には至りませんでした。Discordで聞いたところによるとドライヤーでもいける、ということだったのでドライヤーで挑戦しましたが、十分収縮しました。

最後にケーブルの端子カバーをはめて(ぴったりのサイズなので、熱収縮チューブをつけた後は非常に通しにくい)完成です。会社に行かないとErgodoxがないので動作確認ができていませんが、無事使えることを祈っています。

このほかにも部材をいくつか購入してきてあるので、もう少しケーブル作りをやって行ってみようと思います。

追記: 使えませんでした

zero memory allocation slice filtering

Mon, 04 Feb 2019 07:30:29 +0000

次のように、あるスライスをフィルタリングする関数を書くことがあると思います。

1
2
3
4
5
6
7
8
9


func FilterFoo(arr []string) []string {
 b := []string{}
 for _, e := range arr {
 if IsFoo(e) {
 b = append(b, e)
 }
 }
 return b
}

簡単なベンチマークを書くとわかるように、この関数は返値となるスライスの長さ+1回のメモリアロケーションを行います。一般に、メモリアロケーションの回数は少ない方がパフォーマンスがよく、可能ならばアロケーション回数0を目指したいものです。

今回の場合、次のように書くとメモリアロケーション回数0回の関数を書くことができます。

追記 b := arr[:0]とすると、基底配列に影響が出るので一概に比較できない、とご指摘を受けました。実際に使用する際は副作用に注意しましょう。

このやりかたって引数に副作用あるので、わかってないで使うと危ないような…https://t.co/iKXrXHUD3N https://t.co/CMrAYGJrdA
— Yoichiro Shimizu (@budougumi0617) February 4, 2019

append は引数を弄ってしまうので動作が異なりますね。 / “zero memory allocation slice filtering” https://t.co/JFFDJlfIQA
— mattn (@mattn_jp) February 5, 2019

追記終わり

Majextand

Mon, 28 Jan 2019 08:55:49 +0000

ラップトップスタンド、というものをご存知でしょうか。いわゆるノートPCを傾けたり、高さを変えるために使用するアイテムです。折りたたみができるものや、PCに貼り付ける小型のものなんかもあります。貼り付け型のものとしては、Kickflip が人気です。今回紹介するのも貼り付け型で、その名もMajextand といいます。特徴としてはとにかく薄い。そしてその薄さにも関わらず、6段階の高さ調整ができる、という点です。

まずはパッケージ。すっきりとしたパッケージです。商品名をggって出てくるブログに掲載された写真では何やら筆文字で書かれているようなパッケージが見られますが、現行品ではなくなったようです。

裏面はこんな感じ。スタンドを使用して画面を高くすることで猫背を防ぎ、頚椎の姿勢を正します。また、18インチ以下のラップトップであれば基本的には使用できます。非常に薄いため、インナーケースなどに入れる場合にも引っかかりません。

パッケージ自体にテープなどは使用されておらず、Majextand本体と同じように引き出す形となっています。パッケージ自体が本体と同じような構造になっているのは素敵な感じがしますね。

本体を取り出しました。非常に薄く、切れ目が入ったただの鉄板と言われても信じてしまいそうです。測ってはいないのですが、他のレビュー記事によるとだいたい10円玉と同じ厚さとのこと。薄い。しかし、薄さに対して、若干重い気はします。スタンドという用途ですから、強度を確保するには仕方ないのかもしれませんが。

このように引き出して使います。(本当は手前をまず引き出して、奥側は高さ調整のために使う)

MacBook Pro (13-inch, 2018)のスペースグレーの底面に貼り付けるとこんな感じ。両面テープは非常に強く、意図的に剥がさなければ剥がれてしまうということはなさそうです。今回購入したMajextandはグレーで、MacBookのスペースグレーとは若干色味が違いますが、すごく目立つということはなく、安心しました。

購入したばかりでまだ活用できていないのですが、これから使っていきます。

年越し鴨南蛮

Sat, 19 Jan 2019 05:27:16 +0000

もう1月も半ばを過ぎ、まもなく2月が来る、というところで今更感を拭うことができない話題なのですが、2018年末(実は時間的には年が明けていたが)に年越しそばとして鴨南蛮を作りました。

さて、鴨南蛮なので鴨肉が必要です。今回はbuilderscon の肉会などでお世話になっているミートガイさんから鴨の胸肉を購入しました。

こちらが回答した鴨肉をAnovaでやったやつです。温度は忘れたんですが、大体1~2時間くらいやったやつです。

軽く塩をした後、熱したフライパンで焼き目をつけていきます。皮を下にして、高めの温度でさっとやります。

焼き目をつけた鴨肉です。いい色ですね。

油がたくさん出ます。

鴨から出た油でネギを焼きましょう

ネギを焼いている間に鴨を切ります。幸せのため少し厚切りにしましたが、鴨はすこし薄めでもいいかもしれないです。

最後にそばの上に盛り付けて完成。うまい。

jessevdk/go-assetsでファイルを埋め込む

Thu, 17 Jan 2019 07:47:13 +0000

Go言語の素敵なところの一つとして、最終的な成果物を1バイナリに収めることができる、という点にあると思う。結果として、非常に簡単にコマンドラインツールなどを配布することができる。しかし、例えばコード生成を行うようなツールでテンプレートファイルを別途持っているような場合や、アプリケーション中で使う画像などを含む場合など、Goのソースコード以外のファイルを必要とする場合、全てを1ファイルで、とはいかない。

そのような場合に便利なのがjessevdk/go-assets である。以前は多くの人がgo-bindataを使用していたと思われるが、作者がやめてしまったため、使えなくなってしまった。代替としてこれが便利。 jessevdk/go-assetsを使用するには、まずjessevdk/go-assets-builder を使用する。これは、指定したファイルをGoのソースコードに埋め込んで、それらを扱うためのAssetsというオブジェクトを作成してくれるツールである。

インストールは簡単で、go getするだけ。

1

$ go get github.com/jessevdk/go-assets-builder

インストールできたら、次のように使う。

1
2
3


$ ls assets/
foo.html.tmpl bar.png
$ go-assets-builder assets -o assets.go

すると、assetsディレクトリの内容が埋め込まれたassets.goが生成される。今回は特にパッケージ名を指定していないのて、package mainとして作成された。必要なら-pオプションでパッケージ名を指定することもできる。生成されたあとは、実際に使いたいソースコード内で次のように使う。

1
2
3
4


f, _ := Assets.Open("/assets/foo.html.tmpl")
// in production, need to handle error
defer f.Close()
// Do something with f

ここで作成されたfはos.Fileと同じインターフェースを備えている。要するに、os.Openを使用したときと同じように操作することができる。

また、Assetsという変数を別に使いたいときは、go-assets-builderでパッキングするときに-vオプションで変数名を指定することもできる。ディレクトリ全体ではなく、個別のファイルを指定することもできる。

きちんとやるnet/http

Tue, 08 Jan 2019 07:31:50 +0000

皆さん、net/httpパッケージは使っていますか？ Go言語の標準パッケージであるnet/httpはPythonなどの標準HTTPパッケージに比べ、人間にとっても取り扱いがしやすいため、そのまま使用している方が多いかと思います。しかし、このnet/httpパッケージ、簡単に使えるように見えて結構落とし穴が多いのです。

1. Response Bodyはクローズする必要がある

次のコードを見てみましょう。

1
2
3
4
5
6
7
8
9


resp, err := http.Get("https://example.com/api")
if err != nil {
 return nil, err
}
var t T
if err := json.NewDecoder(resp.Body).Decode(&t); err != nil {
 return nil, err
}
return &t, nil

クライアントライブラリなどでよく書きそうな処理ですね。何も問題ないと思いましたか？公式ドキュメントを見てみましょう。

It is the caller’s responsibility to close Body.

Bodyをクローズするのは関数を呼んだ人の責任、とあります。そうです。Response.Bodyは Close()しなければならないのです。ちゃんとクローズされていない場合、次のリクエストでkeepaliveコネクションの再利用がされず、パフォーマンスの悪化やコネクションリークを起こす可能性があります。

2. Response Bodyを最後まで読む

Response Bodyをきちんとクローズするように修正したコードが次のようなコードです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


resp, err := http.Get("https://example.com/api")
if err != nil {
 return nil, err
}
defer resp.Body.Close()
var t T
if err := json.NewDecoder(resp.Body).Decode(&t); err != nil {
 return nil, err
}
return &t, nil

deferを使うことできちんとクローズできているはずです。さて、問題はないでしょうか？いいえ、これだけだとまだkeepaliveコネクションの再利用がされない恐れがあります。

gitにもaliasの指定ができる件

Wed, 12 Dec 2018 06:16:37 +0000

tl;dr

.gitconfigにもaliasの登録ができる
- [alias]ブロックにaliasを登録する
tagsで単数・複数の悩みを解消する
discardで変更を取り消す
unstageでaddを取り消す
uncommitでcommitを取り消す
ignoreで.gitignoreを生成する

git aliases

この記事は今すぐalias登録すべきワンライナー by ゆめみ① Advent Calendar 2018 の6日目の穴埋め記事です。こちらのアドベントカレンダーは今すぐalias登録べきワンライナーということで、みなさん.bashrcや.zshrcのaliasについて記事を書いてらっしゃいますが、実は.gitconfigという、gitコマンドの設定を書いておくファイルにもaliasの指定ができます。誰もshellのaliasとは言ってない！(・・・はず)ので、いくつか.gitconfig用に便利なaliasを紹介していきましょう

aliasの登録方法

.gitconfigは基本的にiniファイルです。そのため、次のように登録します。

1
2
3


[alias]
aliasname1 = some command 1st
aliasname2 = some command 2nd

簡単ですね？ [alias]というブロックを作成し、alias名=コマンドの形で記述します。このときコマンドはgit xxxの形で実行される、xxxの部分のみを指定します。

例えば、

1
2


[alias]
stat = git status

と指定すると実際の実行時にはgit git statusという形で実行されてしまいエラーになるので注意しましょう。 gitのつかないコマンドを実行したい場合は頭に!をつけます。

1
2


[alias]
ls = !ls

このように記載すると、git lsでlsが実行されます。

`git tags`

git tagというコマンドがありまして。まぁみなさんご存知でしょうが、tagの一覧を出したり、新しいtagを作ったりするコマンドです。これ単体では特に問題がないのですが、リモートリポジトリと合わせて使うと、ちょっと悩みが発生します。 git tagコマンドでタグをつけた後、リモートリポジトリにpushするときのコマンドはgit push --tagsです。これはtagをまとめてpushするので、複数形なんでしょう。しかしです。tagの一覧を出すときに使うのもgit tagと単数形なんですね。ついついgit tagsと打ってしまいませんか？

そんなあなたはこんなaliasを登録しておきましょう

1
2


[alias]
tags = tag

地味ですが、これで単数形か複数形か悩まずに済みます。

git repositoryの初期化ルーチン

Fri, 07 Dec 2018 03:19:52 +0000

おそらくみなさんもgit repositoryを作る時、毎回だいたい同じような手順で初期化をするのではないでしょうか。メモがてら、自分の初期化ルーチンをまとめておきます

tools

使用しているツールは以下の通り:

hub : .zshrc でgitコマンドにエイリアスを張ってます
gitignore.io : 先日記事を書いたように、git ignoreコマンドとして使ってます
git-license : 自作のサブコマンドです

routine

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 新しいリポジトリ用のディレクトリを作成
$ mkdir new-repository
$ cd new-repository
$ git init
# GitHub上にnasa9084/new-repositoryリポジトリを作成
# hubコマンドの機能
$ git create
# まずは空の状態で初回コミット
$ git commit -m 'initial commit' --allow-empty
# .gitignoreを作成(今回はgo言語プロジェクト向け)
$ git ignore emacs,macos,go > .gitignore
$ git add .gitignore
$ git commit -m 'add .gitignore for emacs,macos,go'
# LICENSEを作成
$ git license -u nasa9084 mit > LICENSE
$ git add LICENSE
$ git commit -m 'add MIT License'
$ git push -u origin master

ここまでがルーチンで、ここからMakefileを作ったり開発したりします。

x/crypto/openpgpでデータを暗号化する

Mon, 26 Nov 2018 10:15:09 +0000

OpenPGPはPGP(Pretty Good Privacy)をベースとした暗号化フォーマットです。 Go言語でもgolang.org/x/crypto/openpgp という準標準パッケージで提供されています。

PGPは公開鍵暗号としてメールの暗号化等でよく使用されますが、パスフレーズを用いた対称暗号として使用することもできますので、今回はこちらを紹介します。

TL;DR

暗号化にはSymmetricallyEncrypt()を使用する
復号にはReadMessage()を使用する
- prompt次第で無限ループする恐れがあるので注意

暗号化

x/crypto/openpgpパッケージでパスフレーズを用いてファイルを暗号化するには、SymmetricallyEncrypt関数を使用します。シグネチャは次のようになっています。

1

func SymmetricallyEncrypt(ciphertext io.Writer, passphrase []byte, hints *FileHints, config *packet.Config) (plaintext io.WriteCloser, err error)

順番に見て行きます。まずは引数から。

第一引数であるciphertextには、暗号化されたテキストを出力するio.Writerを与えます。*os.Fileなどを与えてもいいですが、*bytes.Bufferなどを与えてその後*os.Fileにコピーする方が良いでしょう。可読なテキストではなく、バイト列が出力されます。

第二引数のpassphraseはその名の通り、パスフレーズを与えます。

第三引数のhintsには暗号化するファイルのメタデータなどを含むことができますが、単純にnilを与えても良いです。

第四引数のconfigで暗号化方式や乱数エントロピーソース、圧縮アルゴリズムなどを設定することができます。設定しなければ乱数としてcrypto/rand.Readerが、ハッシュ関数としてSHA-256が、暗号化関数としてAES-128が、現在時刻としてtime.Nowが、RSAのビット数として2048がそれぞれ使用されます。圧縮はされません。

返り値は二値で、io.WriteCloserとerrorです。返り値のio.WriteCloserに暗号化したい内容を書き込むことで暗号化が行われます。必ずCloseする必要があるので忘れないように注意しましょう。

使用例

1
2
3
4
5
6
7
8


func encrypt(in io.Reader, out io.Writer, passphrase []byte) error {
 // omit error handling
 w, _ := openpgp.SymmetricallyEncrypt(out, passphrase, nil, nil)
 defer w.Close()

 io.Copy(w, in)
 return nil
}

復号

暗号化したファイルを復号するには、ReadMessage関数を使用します。Decrypt〜のような関数ではないので注意が必要でしょう。関数のシグネチャは次のようになっています。

Generator Pattern

Wed, 21 Nov 2018 08:09:23 +0000

Generator PatternはGo言語における並列処理パターンの一つで、goroutine-safeな値列の生成などに使用することができます。

コードを見た方が早いと思いますので、コードを掲載しましょう。次の例は複数のgoroutineから共通の連番を採番したいときに利用することができます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


func GenInt(ctx context.Context, max int) <-chan int {
 ch := make(chan int)
 go func() {
 defer close(ch)
 for i := 0; i < max; i++ {
 select {
 case <-ctx.Done():
 return
 case ch <- i:
 }
 }
 return ch
}

返された<-chan intからintの値を取得するようにすることで、重複のない連番を取得することができます。 Go言語において、chanは複数箇所から値の取り出しを行うことができますが、chanに入力された一つの値はどこか一箇所からしか取り出すことができません。そのため、lock等を使用しなくとも、必ず重複無く連番を取得することができます。 lockを使用した場合、若干動作が遅いため、可能であればlockを使用しないで、chanを使用して実装できるとより高速な、Goらしいコードとすることができます。

LINE DEVELOPER DAY 2018に参加した

Wed, 21 Nov 2018 02:51:41 +0000

LINE DEVELOPER DAY 2018 はLINEの技術に関して紹介するイベントで、2018年11月21日に開催されたので、参加してみました。

開催地は白金台の八芳園です。初めて来たのですが、厳かな日本庭園なんですね。ちょっと気後れしてしまいます。

八芳園の入り口にはDEVELOPER DAYのロゴ入り暖簾が下がっていました。

会場の建物に向かうには庭園を抜ける必要があり、八芳園を少しですが楽しめるのはなかなか良かったように思います。

受付は外にあり、非常に良い雰囲気でした。雨だったとしても建物の中でやれる様なプランはあったのでしょうが、雰囲気が大きく変わっていたと思いますので、雨じゃ無くて良かったですね。

GitHubのイベントに行ったときなんかも思ったのですが、会場の壁でこういうことをできるのは企業主体のカンファレンスのすごいところだなーと思います。これだけで雰囲気が結構違うとは思うんですが、コミュニティ主体だとここにお金をかける意味はあんまり無いので、やろうという話にもならないことが多い気がします。

写真を撮った時点ではまだオープニングセッションの最中だったので稼働はしていなかったのですが、会場では通常の発表の他、ポスターセッションも行われるようでした。

カメラを向けても止まってはくれなかったのでちょっとぶれちゃってますが、歴戦のカンファレンススタッフであるとりいさんもスタッフ参加とのこと。

LINE DEVELOPER DAY 2018は参加費無料で、約1300人の動員(予定)だそうです。

git ignoreコマンドで.gitignoreを取得する

Tue, 13 Nov 2018 02:07:39 +0000

割とみんな知ってるのかもしれないですが。

git-xxxという名称で実行可能ファイルをパスの通ったところに配置すると、git xxxというgitのサブコマンドの形で実行することができるようになります。これを利用したのが拙作git-license で、git license [option] license_name > LICENSEの形で実行するとLICENSEファイルを簡単に作成することができます。その他、git configでエイリアスを指定して、サブコマンドとして登録することも可能です。

同様にして、git ignoreで`.gitignoreファイルを簡単に取得できるようにしてみましょう。

おそらく現代では多くの人が.gitignoreの生成やテンプレート化をして、あるいはテンプレート化されたものを利用しているのではないでしょうか。GitHubのWUI上でリポジトリを作成するときにも生成することができますし、そのさい使用される.gitignoreファイルとしてgithub/gitignore が提供されています。

今回紹介するのはgitignore.io というサービスです。

gitignore.ioはその名の通り、.gitignoreファイルを生成するサービスです。基本的な使い方は非常に簡単で、ブラウザでアクセスして、テキストボックスに必要な言語、OS、エディタやIDEなどを指定していくだけです。指定が終わったらCreateボタンを押すことで、選択した対象用の.gitignoreテンプレートを全て含んだ.gitignoreファイルが作成されます。これを保存すれば良いですね。

しかし、その他の作業をコマンドラインから行なっていると、いちいちブラウザでアクセスして、マウスで操作して・・・というのが非常に面倒に感じます。

大丈夫です！gitignore.ioではもちろんAPIを提供しています(というか、WUIで生成された.gitignoreのURLがそのままAPIのURL)。次のように実行してみます。

1

$ curl https://www.gitignore.io/api/go,emacs,macos

https://www.gitignore.io/api/の後ろに、カンマ区切りで必要なものを列挙して行くだけで、簡単にコマンドラインから.gitignoreファイルを取得できます。

ここまでやったらもう少し簡単にしたいですね？いちいちURLを打つのは面倒ですし、忘れてしまうかもしれません。せっかくなのでgitのサブコマンドとしてgit ignoreとできるようにしてみましょう。次のコマンドを実行してみます。

1

$ git config --global alias.ignore '!gi() { curl -L -s https://www.gitignore.io/api/$@ ;}; gi'

もしくは、~/.gitconfigファイルの[alias]のセクションに次のように設定しても良いでしょう。

1
2


[alias]
ignore = !curl -L -s https://www.gitignore.io/api/$@

$@は引数をそのまま渡すという変数です。このように設定をすることで、git ignoreとしてgitignore.ioのAPIを利用することができるようになります。実際に使用する時は次のように使用します。

1

$ git ignore go,emacs,macos

言語や環境のリストは全てまとめて一つの引数のため、カンマの後にスペースを入れないことに注意です。指定できる環境の一覧はgit ignore listとすることで表示できます。

標準出力をそのままリダイレクトして、.gitignoreファイルに書き込めばプロジェクトの初期設定として使用できるでしょう。

jessevdk/go-flagsでサブコマンドを実装する

Tue, 06 Nov 2018 05:01:49 +0000

Go言語を用いてコマンドラインツールを開発する際、皆さんはフラグのパースやサブコマンドの実装にどんなパッケージを使用していますか？標準のflagパッケージのほか、、spf13/cobra 、alecthomas/kingpin などもよく使われているようです。私は専ら、jessevdk/go-flags (以下go-flags)を使用しています。 go-flagsはその名の通り、基本的にはオプション/フラグの解析用パッケージで、ドキュメントもフラグ解析に関するものがほとんどです。しかし、go-flagsでは、サブコマンドの実装も可能です。今回はこれに焦点を当ててご紹介していきます。

go-flagsでは、親コマンドにサブコマンドを登録する、という形でサブコマンドを実装していきます。サブコマンドは構造体として実装し、それぞれがオプションを格納する構造体を兼ねる形となります。終端の、実際に何かの動作をするコマンドは Commander interfaceを実装している必要がありますが、中間のサブコマンド(docker containerのような、グルーピングのためのサブコマンド)はこれを実装していなくても構いません。 Commander interfaceの定義は次のようになっています。

1
2
3


type Commander interface {
 Execute(args []string) error
}

非常に単純ですね。argsにはコマンドでパースされなかったあまりの引数が渡されます。実際の実装例を見てみましょう。

1
2
3
4
5
6
7
8


type subcommand struct {
 verbose bool `short:"v" long:"verbose"`
}

func (cmd *subcommand) Execute(args []string) error {
 // some exec
 return nil
}

サブコマンドを実装したら、親のコマンドにサブコマンドとして登録します。ドキュメントを見ると、Command構造体に登録する関数があること、Parser構造体はCommand構造体が埋め込まれていること、がわかります。通常、go-flagsパッケージを使用する場合はパッケージグローバルのParse関数を使用することが多いと思うのですが、サブコマンドを実装する場合はトップレベルのパーサーを自分で作る必要があります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


type options struct {
 // ...
}

var opts options // global option
var parser = flags.NewParser(&opts, flags.Default)
var subcmd subcommand

func init() {
 parser.AddCommand("subcmd",
 "subcommand",
 "",
 &subcmd,
 )
}

func main() {
 if _, err := parser.Parse(); err != nil {
 if fe, ok := err.(*flags.Error); ok && fe.Type == flags.ErrHelp {
 os.Exit(0)
 }
 log.Print(err)
 os.Exit(1)
 }
}

このように登録することで、subcmdという名前のサブコマンドが使用できるようになりました。go run main.go subcmdなどとすると、subcommand.Execute関数が実行されます。実際にはParser.AddSubCommandのエラーをハンドリングしたりなど、もう少しやらなければならないことはあると思いますが、基本的には以上です。

Ergodox EZを購入した

Wed, 31 Oct 2018 05:57:26 +0000

割と今更感もなくはないのですが、Ergodox EZという分割キーボードを購入しました。 Ergodoxは基本的には自分でパーツを揃えて組み立てる、いわゆる自作キーボードの一つですが、オープンソースで設計などが公開されており、その設計を使って完成品を販売しているのがErgodox EZです。今回は公式サイトから購入しました。

構成は次のようなものです。

Color: BLACK
Tilt kit/Wing Rest: YES
Keycap: Blank
Switches: Cherry MX Blue

以上で$325、日本円で37,125円でした。送料がかかるという情報も多かったのですが、送料は無料で、関税が2000円ちょいくらいかかりました。

wing restの箱は凹んでいました。。。まぁ、ペラッペラのビニールだけの状態で渡航して来たので、こんなものでしょう。箱自体はしっかりしており、多少凹んでも中の本体には影響ありませんでした。

いつ使うのかよくわからないワッシャーと、キートップ・スイッチの交換に使う道具、謎のステッカーがついていました。 web上には日本語の情報がなく、ごく最近のことだと思うのですが、現在販売されているErgodox EZにはCIY という機構が組み入れられています。キースイッチが半田付けされておらず、いわゆるソケットのようなものに刺さっているため、自分でキースイッチを交換できる、というものです。このため、自作のErgodoxか、キーボードの故障を覚悟の上での改造のみで可能だった、一部のキースイッチのみ交換する、などが簡単に行えるようになっています。

現在は会社で使っています。やはりエンターキー周りがなれず、slackでちょいちょい誤爆しますね。できるだけJIS配列に近づけた構成にしており、現在のファームウェアはnasa9084/qmk_firmware のdevelopブランチで管理しています。今の所レイヤーはうまく使いこなせていないため、いいかんじの知見があれば教えてほしいところです。

ファームウェアのコンパイル時、arch linuxの場合、sudo pacman -S avr-libcする必要があったほか、macosの場合、brew install avr-gccする必要があったのですこしハマりました

Ceph RBDをKubernetesのStorageClassとして登録する

Tue, 23 Oct 2018 07:08:35 +0000

Kubernetesで何らかの永続データを保存する場合、通常PersistentVolumeと呼ばれる永続ストレージを使用します。Persistent VolumeはNFSなどのネットワークストレージを直接指定することもできますが、ボリュームを手動で用意する必要があり、非常に面倒です。そのため、ブロックストレージサービスをバックエンドとしてdynamic provisioningと呼ばれる、自動でボリュームを作成する機能も用意されています。

dynamic provisioningを使用する場合、バックエンドのprovisionerをStorageClassと呼ばれるリソースに登録しておきます。クラウドでKubernetesを使用している場合はAWS EBSなどを使用するでしょう。

オンプレミスや自宅でKubernetesを使用している場合、GlusterFSやCeph RBDを使用することができます。今回はCephを使用してPersistentVolumeを作成するまでの流れを説明しましょう。

下準備

今回はOpenNebula上にCentOS 7のVM(2GB RAM/1Core CPU)を3台用意し、構築を行いました。バージョンはmimicです。/dev/vdbにCeph用のディスクがあるとします。それぞれ、Chronyで時刻同期の設定、firewalld無効化、SELinux無効化状態で構成しました(本番ではちゃんと設定してくださいね！)。また、ceph-1 ceph-2 ceph-3という名称でアクセスできるよう、hostsファイルを書いて、SSHの鍵もコピーしました。

インストール

まずは公式サイトを参考に各サーバへリポジトリの追加をします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


/root@ceph-N# rpm --import 'https://download.ceph.com/keys/release.asc'
/root@ceph-N# cat < EOF > /etc/repos.d/ceph.repo
[ceph]
name=Ceph packages for $basearch
baseurl=https://download.ceph.com/rpm-mimic/el7/$basearch
enabled=1
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.asc

[ceph-noarch]
name=Ceph noarch packages
baseurl=https://download.ceph.com/rpm-mimic/el7/noarch
enabled=1
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.asc

[ceph-source]
name=Ceph source packages
baseurl=https://download.ceph.com/rpm-mimic/el7/SRPMS
enabled=0
priority=2
gpgcheck=1
gpgkey=https://download.ceph.com/keys/release.asc
EOF

リポジトリの追加ができたら、各サーバへceph-deployをインストールします。

調布技研でKubernetesの薄い本を出します

Tue, 25 Sep 2018 11:04:55 +0000

調布技研、という怪しい団体がありまして、私はそこに所属しています。調布技研は主にSlack上で与太話をしている集団で、インフラとかの検証なんかを共同でやっていたりします。

来る10月08日に、技術書典という、技術系同人誌のイベントが開催されますので、そこで「色んなところでKubernetesを動かす本」という同人誌を出す予定です。

先ほど、無事入稿が完了しました。

私は「おうちKubernetesの作り方」と題して、自宅を含むオンプレでKubernetes環境を作るためのあれやこれやを執筆しました。ベースとなっているのは「趣味サーバーのインフラをKubernetesで整えた件」でもご紹介した私の自宅Kubernetes環境で、小規模ならばプロダクションにも使える環境です。

物理本1冊500円(電子版つき)、電子版のみは400円での頒布となる予定ですので、ぜひお買い求めください。場所はか16です。

なお、冒頭の画像はタイトルをミスった表紙です。

日本仮想化技術(株)を退職します

Tue, 18 Sep 2018 09:19:26 +0000

レギュレーション

タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。
— laiso?? (@laiso) August 1, 2017

本題

私事ですが、2018-09-20を以て日本仮想化技術株式会社を退職し、2018-10-01付けでLINE株式会社へ就職します。

以上。

ingress-nginxで諸々設定する

Sun, 16 Sep 2018 17:06:14 +0000

ingress-nginx を使用している際に、nginxに何か設定をしたいと思ったとき。例えば、nginxは初期状態では、アップロードできるファイルの上限は1MBなのですが、これをもっと大きくしたいとき、nginxでは次のように設定します。

client-max-body-size 5m;

これをingress-nginxでも設定したいと思ったとき、どうしたら良いか。

まぁ、簡単な話で、annotation で設定値を与えてあげれば良いです。この場合だと、次のようにします。

1
2
3


metadata:
 annotations:
 nginx.ingress.kubernetes.io/proxy-body-size: 5m

設定できる値はingress-nginxのドキュメントに記載されています。 client-max-body-sizeを指定するのにproxy-body-sizeと設定することに注意です。

builderscon tokyo 2018

Mon, 10 Sep 2018 06:10:44 +0000

過日、かねてより準備してきたbuilderscon tokyo 2018 が開催され、そして終了しました。

Opening

例年、buildersconでは主催の@lestrrat さんがオープニングでお話をしているのですが、今年はなんと動画を作りました。

それがこちら。

オープニングムービーなので7分程度ですが、かなり気合いの入った動画となっております。詳しい情報は「builderscon tokyo 2018 オープニング作成の裏側」で紹介されています。

記事中でも解説されていますが、この動画、「The Stanley Parable」というゲームのオマージュとなっています。残念ながら開催時点で私はプレイしたことがなかったのですが、昨日プレイしました。面白い。ナレーションがナレーションのくせにこう、感情的なんですよね。怒ったり、悲しんだり。是非皆さんもプレイして(もしくはYoutubeとかでプレイ動画をみて)みてください。

Talk

2016年の初開催からコアスタッフとしてやってきた私ですが、今年はスピーカーとしても参加することが出来ました (スライドはこちら )。残念ながら一度は落選しており、キャンセルされた枠に滑り込む形でしたが、2016年はCfP落選、2017年は業務都合で当日参加出来ず、そして2018年は穴埋め登壇と、着実に進歩しています。来年は是非、きちんと「通った」スピーカーとして参加したい・・・！

twitterで私が話している時間帯のツイートを見ると、「Kubernetesがゲシュタルト崩壊」と複数の方に書かれていて、メダパニを書けてしまった気分です。しかし話題が話題なだけに仕方なかったんや！

スタッフとして

上でも書きましたが、今年は三年目のコアスタッフ参加でした。初年は北海道からのリモート参加、去年は当日に絡む仕事は出来ず、だったので、実質まともに参加したのは初めてです。いくつかoctav(buildersconウェブサイトのバックエンドAPIサーバ)の修正を書き(マージされたとは言っていない)、当日スタッフのまとめ役をしたりしました。

当日スタッフのまとめは正直上手く出来たとは言えず、他のスタッフ(Discordの設定とか当日スタッフの担当割りの細かい調整をしてくれたtoriiさん、諸々印刷などしてくれたuessyさんに多大なる感謝を・・・)の助けを得てなんとか大きな問題無く終えることが出来ました。

タスクはまだ残っているので、これから一週間くらいかけてがしがしやっていきます。

来年は今年よりももっとコミットしていきたい所存です。

来年に向けて

buildersconのコアスタッフSlackでは、すでに来年の企画に向けて侃々諤々といった様相です。buildersconは他のカンファレンスに比べ、自由度が高い(と思っています)ので、何か面白いことをやりたい、と思ったかたは是非スタッフに参加してみてください。(そのうちスタッフ募集が始まる・・・はず)

fitbit versa三日目レビュー

Tue, 04 Sep 2018 14:46:50 +0000

fitbit versa を使い始めて 3日ほど経ったので、現時点での感想をば。

電池の持ちは前情報通り1日で20%〜25%減る程度
- 常時接続・Keep-AliveウィジェットはともにON
- 夜にお風呂/シャワー上がってから、翌日お風呂/シャワーに入るまで、で1日。
  - お風呂/シャワーの間に充電100%
画面つける動作の反応が悪い、という情報があったが、そんなに気にならない
歩数計は少し過敏な様で、実際歩いた歩数より多い気がする
- PCでの作業でも反応してる気がする
本体が防水でも、バンドが水を吸うと水に過敏になる
- 明日からはCLASSIC BANDに取り替えてみる
結構変な方向を向いてしまう
- ベルトをもう一つ締めれば回らなくなるけど、今度は少しきつい
安い画面保護ガラスフィルムを買った
- 一部のレビュー通り、縁が若干浮いている様だけど、気にならないレベル
腕時計をつける習慣が無かったことは、お風呂の時以外常時つけていると案外気にならない
Androidアプリは若干バグってる
- 後述。
versa上で動くアプリはあんまり無い
- もっと増えたら楽しいのに・・・・(しかしどんなアプリが欲しいかというと思いつかない)
versaの時計盤の種類も(よさげなのは)そんなに多くない
- まぁ、頑張ろう
階数カウントは何を基準にカウントしてるのか謎。
天気予報、スマホ側で設定できる画面があるけど結局現在地しか表示できてない。
- よくわからん。
アラーム、もう少し長く鳴って欲しい

Androidアプリのバグ

Android用のfitbitアプリが若干バグってました。すでに報告済みですが、まぁパッとは治らない様子。仕方ない。具体的には、睡眠のページを開き(このときは問題ない)、睡眠の日別詳細を開いて戻ると、なんとデータの一覧が増殖する。尚動作環境はZenfone 5Z、Android 8.0.0。

睡眠のページ。問題はなさそうに見える。

睡眠の日別詳細ページを開いて戻ってきた画面。同じデータだが、画面表示が増えている。

もう一度詳細を開いて戻ってきた画面。増える。増える・・・。

EC2インスタンスからEKS上のアプリケーションにアクセスしたい

Sun, 02 Sep 2018 03:04:50 +0000

TR;DR

KubernetesのServiceで、Internal LoadBalancerってのがあるので、それを使うと良い

Internal LoadBalancer

皆さんはEKS、もう使ってますか？私は使っています。業務システムをリプレースで新規開発する的な案件で、新システムの基盤がEKSという感じです。EKSはネットワークが素敵に気持ち悪い感じになっており、普通はKubernetesのクラスタ内部っていうのは、外側と別のサブネットを作る訳なんですが、なんとEKSが所属するVPCと同じサブネットで接続できるようになっています。

そんなわけで、同一VPCに存在したり、VPC PeeringしたりなんかしちゃってるEC2インスタンスとEKS上のPodはIPアドレスベースでは普通に接続がとれちゃったりするんです。 EKS上のアプリケーションから、EC2インスタンスへアクセスしたいときは、普通にEC2インスタンスのIPアドレスやら内部エンドポイントへアクセスすれば良いですね。EC2インスタンスが動きっぱなしならまぁさほどIPも変わらんでしょう(雑)。

しかし逆は問題です。PodのIPは勿論割り振られてはいますけれど、これはPodが再生成されると勿論変わってしまいます。アプリケーションは動きっぱなしだから変わらない、なんて言うこともできないです。EC2インスタンスはインスタンス上でアプリケーションの更新なんかもしちゃうかもしれないですけど、EKS上のPodに乗ったアプリケーションの更新は普通、Podの再作成が伴います。Podの再作成が起きると、勿論IPが変わります。

そうすると、やはり考えるのはServiceをつくることですね。外部からアクセスするためにはそうしますから、同じように考えるのが普通です。しかし、ここで問題が発生します。普通に外部向けに公開するのと同じようにServiceを作成すると、グローバルIPが当たってしまい、プライベートIPベースで接続できる状況では接続ができないのです。困った。

まぁドキュメントちゃんと読めよって話なんですが、Kubernetesのドキュメントを読むと、Internal LoadBalancerってのがちゃんと書いてあります。AWSの方のドキュメントには無かったのでちょっと盲点でした。annotationで次の様に指定します。

1
2
3
4
5
6


# ...
metadata:
 name: my-service
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
# ...

これだけで、type: LoadBalancerで作成されるELBが内部向けのものになります。internal-なんちゃらみたいなエンドポイントです。IPアドレスもしっかりプライベートIPです。最高。後ろの0.0.0.0/0のところで、アクセスできるIPレンジ制限できるのかなーなんて希望的観測を持ちましたが、全然関係ありませんでした。ちょっと気持ち悪いのは、普通にパブリックDNSで名前引きができてしまうことですかね。全然関係ない外部のネットワークとかでも(パブリックDNSに名前があるので)名前解決ができてしまって、かつプライベートのアドレスが帰って来るという不思議な体験をすることができます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


$ nslookup internal-xxxxx.us-west-2.elb.amazonaws.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
Name: internal-xxxxx.us-west-2.elb.amazonaws.com
Address: 192.168.187.214
Name: internal-xxxxx.us-west-2.elb.amazonaws.com
Address: 192.168.222.128
Name: internal-xxxxx.us-west-2.elb.amazonaws.com
Address: 192.168.109.84

うーん、まぁ実害は無いんでしょうけど。

fitbit versaを購入したので開封の儀

Sat, 01 Sep 2018 14:48:35 +0000

スマートウォッチ的なものが欲しいなーと思ったので、fitbit versa を購入しました。 fitbit versaはその名の通り、fitbit が今年(2018)の6月に発売したスマートウォッチです。トップの写真からもわかるように、若干Apple Watch に似ています。元々、Huawei Watch が欲しいなーと数年前に思っていたんですが、(当然ながら)新しいモデルが出ており、これがまた初代のHuawei Watchとは全く方向性の違うスポーツタイプ。これはちょっと・・・と言うことでPebble もいいな、と探してみると、いつの間にやらサポートが終わってしまっていました。よくよく調べると、Pebbleはfitbitに買収されたとのことでした。かといってApple Watchを買うかというと、私はAndroid ユーザですから、そういう選択肢はありませんでした。

そうこう考えながらいろいろ検索したりなんかしていたんですが、fitbit versaが実質的にPebbleの後継であるという情報を見たり聞いたりしました。お値段もお手頃で、これならまぁいざ微妙でも、買い換えもできるかな、という気持ちもあり、購入に踏み切りました。(fossilの新しいやつもよさげなんですが、ドルで見た金額と円で見た金額が大幅に違って萎えました)

外箱はこんな感じです。fitbit versaは、通常モデル(シリコン？ゴム？のバンド)が3種類と、SPECIAL EDITION(布バンド)が2種類の計5種類で展開されています。元々海外モデルではSPECIAL EDITIONにのみNFCが搭載されているという違いがあったようなのですが、日本版では機能的違いは無いようです。通常モデルの黒と、SPECIAL EDITIONのグレーですごく悩みました。本体の色はグラファイトの方が良さそうだし、バンドも布の方がよさげに見えたんですが、布バンドは濡れたら乾くまで時間かかりそうなので、ゴムバンドのほうが良いのかな・・・と・・・(店頭で悩み続けたので若干怪しかったかも？)。でもまぁ、本体の色はブラックよりグラファイトの方がよさげでしたし、ゴムバンドは純正の交換バンドとして売ってるから、後で買うこともできるか、ということでSPECIAL EDITIONのグレーにしました。今回ビックカメラで買ったんですが、ビックカメラではカードの様なものをレジに持って行くんです。で、商品を受け取ってみたら箱の右下に「PLUS EXTRA CLASSIC BAND」の文字・・・。

帰ってから開封してみたら、案の定通常モデルと同じクラシックバンドが付属してました。ついてるなら早めに言ってほしかった・・・あれだけ店頭で悩んだ私の時間とは・・・。!

本体の画面を保護していたフィルムを取ってみて気づいたんですが、小さなクッションのようなものがついてました。ボタンが押ささらない様にとの配慮なんでしょうけど、こういう細かい気遣いは初めて見たので少しだけ感動しました。

非常に軽く、そしてエッジが削られているので薄く見えるため、非常にスマートです。写真で見る限りではベゼルが結構幅広なのが気にかかった(最近はZenfone 5Zを使っていることもあり、ベゼルは小さい方がいいなーと思っていた)のですが、実際画面をつけてみると、意外と気になりませんでした。

元々腕時計など、腕に何かをつけるという習慣がないので、どうなるかわかりませんが、しばらく使ってみようと思います。

趣味サーバーのインフラをKubernetesで整えた件

Thu, 23 Aug 2018 04:53:46 +0000

趣味でサーバー運用をしています。札幌在住の大学生時代から運用を開始し、引っ越しに伴い朝霞へ移設、現在はコミュニティで使用している自宅外のラックへ移設されましたが、変わらず動いています。この「趣味サーバー」は購入当初からKVMをベースとした(OpenNebula を使用しています)プライベートクラウド基盤として使用してきました。今も変わらずベースはOpenNebula/KVMなのですが、この度晴れてKubernetes を中心とした構成に組み替えたのでご紹介します。尚、サーバ台・電気代・インターネット代を除くソフトウェア料金は基本的に無料で済んでいます。

物理層

このプライベートクラウド基盤は3層で構成されています。

その最も下の層が物理層です。その名の通り物理サーバそのものですね。物理サーバとしてDELLのR410(ヤフオクで1万弱で購入・4コア8スレッド×2、メモリ16GB)とDL360Gen6一号機(会社の処分品をもらってきた・4コア4スレッド×2、メモリ24GB)、DL360Gen6二号機(会社の処分品をもらってきた・4コア8スレッド×2、メモリ24GB)の三台で、それぞれubuntu 16.04LTSがインストールされています。落ち着いたら18.04LTSにアップデートしたい。基本的に電源やLANは冗長化されておらず、電源やNICに問題があると即死亡となります。

VM層

物理層の上に構成されているのがVM層です。OpenNebula/KVMを使用しており、Web UIからポチポチッとVMを作成できます。今回Kubernetesで整える前は、VMとしてnginx インスタンスを作成し、外からの80/443ポートへのアクセスを捌くリバースプロキシとして使用していました。本ブログも長らく単体VM上のDocker コンテナとして稼働していました。基本的にVMにはCentOS 7をインストールしています。今回の構成変更で、VMは基本的にKubernetesのノードとして使うように変更、直接VM上で動作しているのはオブジェクトストレージを提供するminio とブロックストレージを提供するGlusterFS のみとなりました。尚、GlusterFSクラスタの構成にはheketi を使用しました。

コンテナ層

最も上の層がコンテナ層です。ここまでの話からわかるように、Kubernetesクラスタを構成しています。四台のCentOS 7をクラスタノードとして使用、Kubernetes自体の構成管理はkubespray を使用しています。現在はKubernetes 1.11.1です。本ブログもKubernetes上のコンテナとして動いています。 Persistent VolumeとしてVM上に構成したGlusterFSを使用、本ブログ等のバックアップ先としてminioを使用しています。当初はVM上に構成したnginxインスタンスをそのままリバースプロキシとして使用していましたが、本ブログを含めたアプリケーションを順次Kubernetesクラスタ上のコンテナとして移設していった結果、nginxのVMだけ別になっていることに不便を感じるようになりました(リバースプロキシの設定は手作業で設定しなければなりませんし・・・)。しかし、VM上のnginxリバースプロキシを廃するためには、二つの問題点がありました。

素KubernetesではIngress が使用できないため、ホスト名ベースの振り分けが出来ない
Let’s Encrypt の証明書を管理するVMがいなくなる

これらを解決しないことにはnginx VMを削除できません。解決のためにまず、kind: Ingressを使用するための実装としてingress-nginx を使用することにしました。Ingressが使用できるようになることで、クラスタ外のリバースプロキシを挟まずともホスト名ベースの振り分けが出来るようになります。 ingress-nginxはService type: NodePortでも使用できるのですが、折角なのでService type: LoadBalancerを使用したいですよね？type: LoadBalancerを使用するための実装としてMetalLB を使用することにしました。これにより、ingress-nginxに対してクラスタ外のIPアドレスを割り当てることが出来るようになります。

次に、Let’s Encryptの証明書を管理するため、cert-manager を導入しました。cert-managerはkubesprayの導入時にアドオンとしても導入することが出来、今回はkubesprayのアドオンとして導入しました。これはその名の通り、証明書をKubernetesのリソースとして管理することが出来るツールです。最初はLet’s Encryptのacme api v02に上手くアクセスできない、ワイルドカードでの証明書取得が出来ないなど躓きましたが、Let’s Encryptに上手くアクセスできない問題は最近のkubesprayで比較的新しいバージョンのcert-managerを導入することで解決できました。ワイルドカードでの証明書が取得できない問題は、元々webroot(HTTP01)で証明書を取得していたのが原因のため、DNS01へ切り替えました。Gehirn DNS を使用していましたが、上手くいかなかったためCloudflare DNS に切り替え、事なきを得ました。

これらにより、nginx VMを廃し、ルーターでの80/443のNAPT設定をすべてKubernetesクラスタへと向けることが出来るようになりました(OpenNebulaやminio等へのアクセスはtype: ExternalNameを使用)。 VMがぐっと減り、ストレージ用途以外のVMを直接触らなければいけないことも減りました。めでたしめでたし。

使っているものまとめ

confd + initContainerでAlertmanagerの設定をSecretに逃がす

Mon, 20 Aug 2018 08:06:47 +0000

TL;DR

Alertmanagerの設定には一部Secretが含まれる
- バージョン管理システムに入れたくない
initContainerでconfdを使って設定ファイルを生成する
- Alertmanagerの設定の一部をSecretに格納できる

confd

kelseyhightower/confd は非常に軽量な設定ファイル管理ツールです。基本的にはテンプレートエンジンですが、多くのバックエンドデータストアからデータを持ってきて、設定ファイルに書き出すことが出来ます。また、事前処理や事後処理を行うことが出来るので、例えば設定ファイルを書き換えたあと、リロードする、というところまでconfdで行うことが出来ます。

Install

Go言語で書かれているため、インストールは非常に簡単で、バイナリをダウンロードしてきて実行権限を与え、パスの通ったところに置くだけです。バイナリはリリースページからダウンロードすることが出来ます。

使用方法

confdを使用するためには、三つのものを用意する必要があります。

テンプレートリソース
テンプレート
データストア

テンプレートリソース

テンプレートリソースには、どのテンプレートを使用して、どんなキーでデータストアからデータを取り出し、完成した設定ファイルをどこに置くのか、事前処理・事後処理はどんなものかを記述します。書式はTOMLで、慣れ親しんだ(慣れ親しんでない？)iniファイルの様に気軽に書くことが出来ます。/etc/confd/conf.d以下に配置します。

テンプレート

テンプレートはその名の通り、設定ファイルのテンプレートです。ここに、データストアから取り出したデータを合わせて設定ファイルを作成します。書式はGo言語のtext/template に準じます。/etc/confd/templates以下に配置します。

データストア

そして、データストアにデータを入れる必要があります。

confdは、データストアとして、次のものをサポートしています(2018/08/20現在)

etcd (GitHub: coreos/etcd )
consul (GitHub: hashicorp/consul )
dynamodb
redis (GitHub: antirez/redis )
vault (GitHub: hashicorp/vault )
zookeeper (GitHub: apache/zookeeper )
rancher metadata-service (GitHub: rancher/rancher , rancher/metadata )
AWS Systems Manager パラメータストア
環境変数
ファイル

Alertmanager

Alertmanager はPrometheus からのアラートを受け取り、適切にハンドルするためのアプリケーションです。Alertmanagerの設定はYAMLで記述するのですが、SMTPのパスワードやSlack のIncoming Webhook URL 等、平文でバージョン管理システムに入れるのは躊躇われるデータを含みます。しかし、環境変数などから設定をすることも出来ないため、平文で記述するか、何らかの方法で設定ファイルを編集してから使う必要があります。特に、Prometheus/AlertmanagerはKubernetes と併せて使用されることが多いため、出来ればKubernetesのSecret機能を使用したいところです。そこでconfdをinitContainerで使用して、設定ファイルを生成します。

まず、テンプレートを作成します。Alertmanagerの設定ファイルを用意し、後から挿入したい部分をテンプレート文字列で置換しておきます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


global:
 slack_api_url: {{getenv "ALERTMANAGER_SLACK_URL"}}

route:
 receiver: slack

receivers:
 - name: slack
 slack_configs:
 - channel: "#alert"

今回は例なので、細かい設定の一切を省いた形にしました。上記の内容で、alertmanager.yml.tmplとして保存しました。

ファイナルカツカレーをつくった

Wed, 15 Aug 2018 14:04:46 +0000

連休も終わりで、明日から出社するのがつらいのでファイナルカツカレーを作りました。ファイナルカツカレーは要するに、ファイナルカレーにカツを乗せたものです。ファイナルカレーはいちばんおいしい家カレーをつくるに書かれているカレーで、我らがバイブルであるめしにしましょう(4) で紹介されています。素晴らしいカレーであるとのことなので、やはりカツは素晴らしいカツを乗せたいものと思いますので、超級カツ丼の時にもやった、低温調理カツでやっていきます。

まずはタマネギを炒めていきます。これは一個分です。結構大きめのタマネギを買ってきました。割とざっくりした粗みじん切りです。昨日包丁を研いだので目が痛くない。強火で炒めて、焦げ付きそうになったら少し水を足す、という作業を繰り返します。

良い感じになったら香味野菜類を追加します。にんじん・セロリ・ニンニク・ショウガ・ホールトマトですね。めしにしましょうではミキサーでやっていく風に書かれていましたが、我が家にはミキサーが無く、このために買うのも何かと思ったので、にんじんはみじん切り、セロリとニンニク・ショウガはすりおろしてみました。ニンニクをすりおろす小さいおろし金でセロリみたいな大きいものをすりおろすのはつらいです。ホールトマトは缶でしか売ってなかったので余りました。どうしよう。ここでバターをちょいと加えます。切れてるバターが便利でした。

水分が飛んできたらスパイスを足します。ターメリック・レッドチリ・クミン・コリアンダーです。これらは基本のカレーを作るのにも使える、基本的なスパイスなので、まぁ買っておいても良いでしょう。我が家は以前基本のカレーを作るのに買ったので、冷蔵庫に入ってました。

もうペーストです。ドライカレーとかの方が近い見た目。鍋を振るとひっくり返せます

肉です。豚肩ロースを適当な大きさに切り、梅酒と少々の醤油につけたものです。1時間くらい前につけて冷蔵庫にぶち込みました。梅酒は自家製です。今年つけたのを使いました。カツを乗せるので肉はいらないかとも思ったのですが、一応。

ペーストに肉をぶち込みます。つけ汁もそのまま。ちょっと緩くなります。このまま少し炒めます。

良い感じになったのでコンソメ汁を投入。300mlのお湯にコンソメキューブを溶かしたものです。300ml入る良い感じのマグカップが無くて難儀。ローリエとはちみつ、醤油を加えて煮込みます。45分ほど煮込んだら、カレールゥを適当に突っ込みます。

煮込んでいる間にカツをやっていきます。カレーにカツをのせることで人間は幸せになるのです。これは昨晩仕込んだ豚肩ロースで、Anova を使用して、62度で24時間やったものです。めしにしましょうではカツをやるのに63度12時間でしたが、24時間やるつもりだったので1度下げました。それにしてもまずそうである。

切ったもの。断面は素晴らしいですね。カツにしましょう。

カツです。

断面。スマホです。むしろこのまま食べたくなってきます。

実は以前にも一度、五島軒のカレー缶を使ってカツカレーを作ったのですが、超級カツを乗せるとカレーが見えなくなるのが欠点です。左上のお茶はジャスミン茶です。沖縄でさんぴん茶を飲んでから飲めるようになりました。というかむしろハマってます。

ファイナルカツカレーは、罪の味がします。人間が幸せになるためにはやはりカレーにカツをのせねばならないと、そう感じるものです。ファイナルカレー自体は少し薄い味というか、もういっこカレールゥを足してもよかったかもしれないです。

外部サービスをIngress backendとして使用する

Tue, 07 Aug 2018 02:20:57 +0000

TL;DR

Service type: ExternalNameを使用する

External Service

Kubernetes では、Ingress を使用することで、ホスト名ベースのロードバランシング/リバースプロキシを行うことが出来ます。その際、プロキシ先としてKubernetes上のService を指定するのですが、場合によってはKubernetesクラスタ外のサービスをプロキシ先としたい場合があります。例えば、弊宅の環境では、次の様にプロキシしています。

基盤であるOpenNebulaのダッシュボード以外は*.web-apps.techとして、Kubernetesへとルーティングしています。

ところで、本ブログは現在Kubernetes上へ移行作業中です。今のところはまだ、Kubernetes上へ載せていません。しかし、折角プロキシの設定が減っているので、blog.web-apps.techもIngressリソースとして管理したいです。

そこで使用できるのがService type: ExternalNameです。ExternalNameとして外部サービスを登録することで、Ingressのバックエンドとして使用できるようになります。

設定

設定はごく簡単で、次の様にします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


---
apiVersion: v1
kind: Namespace
metadata:
 name: external-services
---
apiVersion: v1
kind: Service
metadata:
 name: ghost
 namespace: external-services
spec:
 type: ExternalName
 externalName: 192.168.1.41 # 本ブログのローカルIP

今後も何かの拍子でKubernetesに載せたくないサービスが増える可能性もあるため、external-servicesとして名前空間を分離しました。このように設定すると、kubectlからは次の様に見えます。

ingress-nginxを使用してオンプレでもIngressを使用する

Mon, 06 Aug 2018 05:37:02 +0000

TL;DR

ingress-nginxを使用するとオンプレでもIngressを使用出来る
MetalLBと組み合わせる

Ingress

IngressはKubernetes の機能の一つで、L7 LoadBalancerの機能を持ちます。先日紹介した type LoadBalancerは、L4 LoadBalancerで、クラスタ内のDNSで名前解決をし、IP制限などをすることが出来ます。それに対し、Ingressでは、HTTPSの終端となることが出来、ホスト名ベース・パスベースのルーティングを行うことが出来ます。

通常、オンプレでKubernetesを構築した場合、Ingress Controllerと呼ばれる、Ingressを作成する機能が無いためにIngressを使用することが出来ません。しかし、折角Kubernetesを使用しているのに、ホスト名ベースのルーティングをクラスタ外のロードバランサーに設定するのは面倒です。どうせならIngress、使いたいですね？

そこで使用できるのがingress-nginx (GitHub: kubernetes/ingress-nginx )です。ingress-nginxはその名のとおり、nginxを使用したIngress Controllerです。Ingressリソースの作成時に、nginxの設定をConfigMapとして保存することでIngressの作成を実現します。

Install

MetalLBをインストールしている場合、次の二つのコマンドを実行することでインストールできます。

1
2


$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/cloud-generic.yaml

二行目のコマンドはドキュメント上では docker for macのコマンドとして記載されていますが、type: LoadBalancerが使用できるクラスタ一般で使用できます。

インストールが完了したら、ingress-nginxのサービスにIPアドレスが割当たります。

1
2
3
4


$ kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default-http-backend ClusterIP 10.233.50.56 <none> 80/TCP 2d
ingress-nginx LoadBalancer 10.233.47.246 192.168.1.100 80:30431/TCP,443:30017/TCP 2d

実際にブラウザでingress-nginxのIPアドレスにアクセスしてみて、default backend - 404と表示されれば正常に動作しています。

MetalLBを使用してオンプレでもtype: LoadBalancerを使用する

Sun, 05 Aug 2018 15:02:11 +0000

TL;DR

MetalLBを使用することでオンプレ(not on OpenStack)に構築したk8sでもtype: LoadBalancerを使用できる

type: LoadBalancer

kubespray 等を使用して、Kubernetes をオンプレ(on OpenStackを除く)で構築した場合、通常、type: LoadBalancer を使用することができません。これは、type: LoadBalancerは通常CloudProviderにより管理されており、オンプレ(on OpenStackを除く)でk8sを構築した場合にはCloudProvider連携が無いためです。

しかし、k8sを使用するからにはtype: LoadBalancerも使用したいですよね？NodePortなどで代用するにも、ポートがバラバラになってしまって面倒です。そこで使用できるのがMetalLB (GitHub: google/metallb )です。 MetalLBを使用すると、type LoadBalancerの作成をフックしてアドレス割り当てとアドレスの広報を行ってくれます。

Layer 2 mode

MetalLBにはLayer 2 mode(以下L2 mode)とBGP modeがあります。これらのモードはアドレス広報の仕方が違い、L2 modeではARP/NDPで、BGP modeではその名の通りBGPでアドレスの広報を行います。通常、自宅を含むオンプレ環境ではBGPを使用していないと思いますので、L2 modeについて解説します。

L2 modeでは、特定のノードへアクセスを集中させ、kube-proxyによって各サービスへトラフィックを分配します。そのため、実態としてはロードバランサーが実装されている訳ではないことに注意が必要です。単体ノードにアクセスが集中するため、これがボトルネックとなり得ますし、アクセスが集中することになるノードが何らかの理由でアクセスできなくなった場合、フェイルオーバーに10秒程度かかる可能性があります。

requirements & installation

導入は非常に簡単ですが、以下の要件を満たしている必要があります。

他にネットワークロードバランシングの機能が無いKubernetes 1.9.0以降
MetalLB対応表に記載のあるネットワークで設定されていること

これに加え、MetalLBで使用することのできるIPv4アドレスを用意しておく必要があります。私の環境ではk8sのノードが192.168.1.0/24にあるため、192.168.1.100から192.168.1.159までの60個のアドレスをMetalLB用としました。

要件を満たしていることが確認できたら、MetalLBのインストールを行います。 MetalLBをインストールするには、次のコマンドを実行します。

1

$ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.2/manifests/metallb.yaml

Helm を使用してインストールすることもできますが、Chartが最新版ではないので注意しましょう。

次に、次のようなConfigMapを作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: ConfigMap
metadata:
 namespace: metallb-system
 name: config
data:
 config: |
 address-pools:
 - name: default
 protocol: layer2
 addresses:
 - 192.168.1.100-192.168.1.159

これでMetalLBのセットアップは完了です。パブリッククラウドで使用するように、type: LoadBalancerを作成するとアドレスプールからIPアドレスが割り当てられ、アクセスできるようになります。アドレスプールは複数用意することができ、特定のアドレスプールからIPを割り当てたい場合はtype: LoadBalancerのアノテーションにmetallb.universe.tf/address-pool: <ADDRESS_POOL_NAME>を追加します。

Liveness/Readiness Probe

Thu, 26 Jul 2018 05:09:35 +0000

Kubernetes によるヘルスチェックには、Liveness ProbeとReadiness Probeと呼ばれる二つのものがあります。これらは混乱しがちな一方、日本語による情報が多くない(2018/07/26現在で、Google検索の1ページ目にヒットするのが4件ほど)ため、ここで一つ情報をまとめておきます。

共通

Liveness ProbeとReadiness Probeの設定は共通で、DeploymentやPodのマニフェスト内で、containersの中にlivenessProbeとreadinessProbeとしてそれぞれProbe spec を記述します。

次の項目を設定することが出来ます。

failureThreshold
- Success状態の時、何回失敗したらFailureになるか。最小で1回。
- Default: 3
initialDelaySeconds
- コンテナが起動してからヘルスチェックを始めるまでの秒数。
- Default: 0
periodSeconds
- ヘルスチェックの間隔。最小で1秒
- Default: 10
successThreshold
- Failure状態の時、何回成功したらSuccessになるか。最小で1回。
- Default: 1
timeoutSeconds
- ヘルスチェックのタイムアウト秒数。最小で1秒。
- Default: 1
httpGet
- ヘルスチェックでアクセスするhttpエンドポイントの情報を書く。

httpGetの項目は次の様な項目を持ったobjectを書きます。

host
- 対象のホスト名。
- Default: PodのIP
httpHeaders
- リクエストのカスタムヘッダ指定。{name: HEADER_NAME, value: HEADER_VALUE}の形のオブジェクトの配列で書く。
port
- アクセスするポート番号または名称
path
- アクセスするパス。
scheme
- アクセスする際のスキーム。
- Default: HTTP

Liveness Probe

一つ目はLiveness Probeです。公式ドキュメントには次の様に書いてあります。

livenessProbe: Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy . If a Container does not provide a liveness probe, the default state is Success.

Future Pattern

Wed, 04 Jul 2018 15:33:02 +0000

Future Patternは非同期処理パターンの一つで、ある処理を別のスレッドなどで実行し、結果を後で(=未来で)受け取るような処理に用いられるデザインパターンです。特徴としては、外側に見えている関数などの処理を実行するオブジェクトは、処理を別スレッドに委譲し、後で結果を得ることの出来るFutureと呼ばれるオブジェクトを即座にメインロジックへと返却することです。

言葉で書いても、何だかよくわからないので、コードを見てみましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


/* package, import part */

func main() {
 in := make(chan int)
 out := Double(in) // この時点では結果は得られない
 go func() {
 for i := 0; i < 10; i++ {
 in <- i
 }
 close(in)
 }()
 for d := range out {
 fmt.Println(d) // ここで結果を得る
 }
}

func Double(in <-chan int) <-chan int {
 out := make(chan int)

 go func() {
 for i := range in {
 out <- 2 * i
 }
 close(out)
 }

 return out // Futureオブジェクト
}

main関数から呼び出されたDouble関数は、与えられた数を二倍する関数ですが、二倍する処理は呼び出された時点では実行せず、即座にchannelを返します。この、変数名outのchannelがFutureオブジェクトです。そのため、数を二倍した結果は、Double関数を呼び出した時点では得られず、後でoutchannelから得ることとなります。

array/sliceに対する存在確認関数のベンチマーク

Tue, 26 Jun 2018 08:30:22 +0000

Pythonでいうところの、次の様な条件式を実現する関数を書きたかった。

1
2
3
4
5


ls = ["foo", "bar", "baz"]
s = "baz"

if s in ls:
 print("FOOBAR!")

対象がリストの時、普段なら普通にfor文を回すのですが、今回やりたかったのは定数値の一覧にあるかどうか、だったのと、定数の数も少なかったので、とりあえずで以下の様に実装していました。

1
2
3
4
5


func something(s string) error {
 if s != "foo" && s != "bar" && s != "baz" {
 return errors.New("value invalid")
 }
}

流石に雑すぎるので、リファクタリングしよう、と思ったのですが、「はて、for文挟んだら遅くなったりしないだろうか」などと考えてしまったのでベンチマークを取りました。

TL; DR

素直にfor文を回しても大して問題はなさそう

result

今回取ったベンチマークは6種類です。

for-range文を回す
for文を回す
map[string]struct{}を集合として取り扱ってみる
&&, ||でつなぐ
switch文を使う
sort.SearchStrings()を使う

6番目のsort.SearchStrings()を使う方法はstackoverflow に書いてあった方法で、二分探索をしてくれるというのでやってみました。

結果は次の通り。

BenchmarkInByForRange-4 200000000 9.34 ns/op 0 B/op 0 allocs/op
BenchmarkInByFor-4 100000000 10.1 ns/op 0 B/op 0 allocs/op
BenchmarkInByMap-4 200000000 7.79 ns/op 0 B/op 0 allocs/op
BenchmarkInByAnd-4 1000000000 2.85 ns/op 0 B/op 0 allocs/op
BenchmarkInBySwitch-4 2000000000 1.39 ns/op 0 B/op 0 allocs/op
BenchmarkInBySortSearchStrings-4 10000000 179 ns/op 32 B/op 1 allocs/op

まぁ予想通りではあるものの、sort.SearchStrings()を使う方法は遅いですね。これはこの関数の「事前にリストがソート済みであること」という条件のために関数内でソートをしてるからだと思われます。(実際、ソート済みのリストを使って、関数内でソートをしないようにすると1/4くらいにはなる)

Amazon EKSがGAだと言うので触ってみた

Wed, 06 Jun 2018 02:52:04 +0000

AWSのmanaged Kubernetesで、これまでプライベートベータだったElastic Container Service for Kubernetes がGAになったということなので、さくっとクラスタを作成してみました。¹

参考にしたのはAWS公式、EKSのGetting Started Guide です。

まずはEKSのページを見てみようとしたところ・・・ぶっ壊れてますね！これはなんかアレですね。 gettext的なのが上手くいっていないように見えるので、画面下から英語にしてみます。

無事、正しいと思われるページが表示されました。なんか、How it worksの説明の図がちょっとぼやけて見えるのは環境のせいでしょうか。

扨、ここからGetting Startedしていきます。

まずはEKS用のIAMロールを作っていきます。 IAMロール作成画面のサービスリストにEKSが追加されていますので、これを選択します。

ユースケースは一つしかなく、選択済みになっています。

フムー。

IAMロールが出来ました。

CloudFormationでクラスタを組んでいきます。今のところ、EKSが使えるリージョンはUS West(Oregon) (us-west-2)とUS East(N.Virginia) (us-east-1)の二カ所です。今回はUS Eastでやっていきます。

CloudFormationでCreate Stackをやっていきましょう。 S3 template URLが用意されていますので、これを入力します。 template URLはhttps://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-06-05/amazon-eks-vpc-sample.yamlです。

Viewしてみるとこんな感じです。なるほど。

細かい設定的なところは全くいじらず、さくさく進めていきます。Stack nameはGettingStartedにしました。

できた。

Outputのタグを選択して、SecurityGroupsとVpcIdとSubnetIdsを(一応)メモっておきます。²

次にkubectlの設定をしておきます。最新のkubectl(1.10以降)をインストールしておいてください。まだインストールしていない場合はEKS側でも配信しているようなのでそれを使ってもOKです。

EKSでは認証にheptio-authenticator-awsを使用するようなので、こちらもドキュメントに従い導入します。私はいろいろ考えるのが面倒だったため、go getしました。

1

$ go get -u -v github.com/heptio/authenticator/cmd/heptio-authenticator-aws

ヘルプを表示して、正常に導入出来たかざっくり確認します。

1

$ heptio-authenticator-aws help

ここで注意なのですが、ガイドではDownload and Install the Latest AWS CLIのところにOptionalってついてるんですが、これはほぼ必須です。 AWS CLIがないとクラスタに接続出来ないので、AWS CLIをインストールしておきます。

超級カツ丼をAnovaでやった

Mon, 04 Jun 2018 10:00:00 +0000

めしにしましょうに出ていた、超級カツ丼をAnovaを使ってやってみました。

まずはお湯を予熱しておきます。58度です。給湯器で温度を上げたお湯を使うと調理開始が早くなる、ということを学びました。

今回のお肉はこちら。近所の西友で97円/100gのアメリカ産豚肩ロース522gです。

適当にIKEAのジップロックっぽいやつに入れて空気を抜いておきます。前回に比べて重いせいか大きいせいか、あまり上手く空気を抜けませんでした。ちょっと不安だったものの、まぁイケるでしょとそのままやっていきです。

投入。今回は24時間(!)やっていきます。

24時間たったお肉がこちら。おいしくなさそう。

タマネギをスライス(スライサーなどないので包丁で薄切り)していきます。指を少しそぎました。痛い。

肉は四分割しました。ブロックの向きによっては二枚でも良かったんですが、油の方向的にこうなりました。

衣をつけた様子。塩こしょうを振って、小麦粉→卵→パン粉→卵→パン粉です。

揚げました。200度の油で20秒です。

卵でとじて御飯の上にドーンしたのがこちら。卵でとじる作業は戦争なので写真を撮っていませんでした。

アツい。

大変柔らかく、おいしかったです。一部筋っぽいのが残ってたところもあったので、下処理とかした方が良かったのかもしれないですね。あと、二人分にしては多かったので次はもう少し人数を確保した方がよいと思いました。

Anovaが届いたのでHello Worldした

Wed, 30 May 2018 13:24:37 +0000

去る5月12日、肉の祭典であるところのbuilderscon 低温調理肉会 2018 Spring が開催されました。その名の通り、Anovaで低温調理された肉をひたすら食うというイベントで、大変に楽しみにしていました。が、家を出るぞ！という段になってKubeCon の時にやらかしたぎっくり腰を再発し、行くことかなわず、気づいたらAnova をポチってしまっていました。

[^amzn]

そのAnovaが我が家に届いたので、真空低温調理のHello Worldとも言えるローストビーフをつくりました。

ネット上でブログ記事とか見てると、筒状の箱に入っている写真も多いのですが、最近は普通の箱に入ってくるようです。

中に入ってた紙には基本的な加熱時間なんかも書いてあります

Anovaさんとご対面。かれこれ一年近く買うか悩んでたので、ようやく、といったお気持ちです。

我が家にあった鍋だと、使えなくはないのですがもう少し余裕がほしいと感じたのでAnovaさんの異名を持つ@lestrratさんのブログ記事を参考にして、バケツを購入してきました。近所(と言っても徒歩10分からのバスで10分程度かかる)ホームセンターで、トンボニューセレクトバケツ15L を購入(余談ですが、このバケツは食品衛生法適合商品なので調理に使うことに何の問題もありません)。

お湯を張ってanovaをセット。温度表示も摂氏に変更しました。 58度にセットして余熱しておきます。

今回調理したのはこちらの牛肉モモブロック862円。近所の西友で購入しました。

適当に筋を取ってからスパイスをまぶしていきます。今回はローストビーフ用スパイスなるものが牛肉に付属していたので、それを使ってみました。

IKEAのジップロック的な袋に入れて、空気を適当に抜きました。¹

肉を投入。クリップなんかで袋を止めると良い、みたいな記事が多かったのですが、ぱっと使えそうなクリップが無かったのでどこのご家庭にもあるであろう緑の養生テープでとめておきました。この状態で2時間やっていきます。

できあがったものがこちら。見た目は良くないです。

フライパンで焼き目をつけていきます。ガスバーナーがほしい。

切ってみました。素晴らしいピンク色。

スライスしたものがこちら。ローストビーフを良い感じに薄くスライスするの、難しいですね。誰かこつを教えてください。

最終的に御飯の上でドーンな感じになりました。温玉もanovaでやったやつ。ちょっと堅かった気がします。

おいしかった。

袋を水につけて(水が入らないように)、空気を抜くとそこそこ真空っぽい感じになります。 ↩︎

slimduetを使って海外でインターネット接続を確保する

Mon, 07 May 2018 08:50:39 +0000

先日、初めて海外に行ってきたんですが、その際、slimduet というeSIM(ソフトウェア的な設定で通信事業者を変更出来るSIM)を使用してネットワーク通信をしたので、設定方法などをまとめておきます。

前提

端末はFREETELのKiwami 2 (Androidのバージョンは6)、行き先はデンマーク/コペンハーゲンです。

設定

SIMを購入する

slimduetを使用するには専用のeSIMが必要ですので、公式サイトやAmazon(記事執筆時点では在庫なし)から購入しておきます。

SIMカードの価格はは2000円を切る程度です。

slimduetのアプリをインストールする

slimduetを使用するには、専用のアプリをインストールする必要があります。 Google Playでslimduet と検索し、インストールします。

勿論、この段階では別途データ通信が出来る必要があります。

プランを購入する

slimduet SIMを端末に挿入してから、行き先に併せたプランを購入します。この段階では、Wi-Fiなどのデータ通信が出来る必要がありますので、空港やホテルのWi-Fi等を使用するか、日本国内にいる内に購入しておきます。

slimduetアプリを起動すると、行き先の検索画面が表示されますので、行き先を入力し検索します。今回はデンマークですので、「デンマーク」と入力し、検索バー横のルーペボタンを押します(キーボードのGoやDone、エンターなどでは検索されないので注意)。

おすすめプラン、ということでデンマークで使えるプランが表示されますので、選択します。

国別プランを選択すると画面が変わり、1日間、3日間などのプランが表示されますので、日程にあわせた期間のプランを選択します。

クレジットカードなどで購入手続きをした後、画面下部の「私の電話番号」を押し、購入したプランが表示されていることを確認します。

また、この段階でSMSで購入したプランについてメッセージが来るはずです。

電話番号を切り替える

自動電話番号切り替えに対応した端末では、プランの「詳細」から、「携帯電話番号の切り替え」を押すことで切り替えることが出来ます。

Kiwami 2は対応していないため、SIM Toolkitを使用して番号の切り替えを行います。 AndroidのアプリドロワーからSIM Toolkitを起動します。

SIM Toolkitを起動すると、SIMの一覧が表示されるので、slimduetかな？と思われるものを選択します。

SIMを選択したら、「携帯電話番号を切り替え」、「ご利用する携帯電話番号を選択してください」の順で選択します。「携帯電話番号を切り替え」のあと、「設定」を選択したくなりますが、こちらではないため注意します(図の赤枠で示した部分を選択します)。

購入したプランが表示されますので、選択します。

APNの設定をする

電話番号の切り替えが出来たら、APNの設定をします。 Androidの設定から、「SIMカードとモバイル通信」の設定画面を開きます。

「モバイルネットワーク設定」を開き、データ通信を有効にする、データローミング、にそれぞれチェックを入れます。

「アクセスポイント名」の設定画面を開き、右上の + からAPNの設定を追加します。名前は適当なもの(slimduetなど)を入力し、APNを uinternetとして保存します。

保存したら、作成したAPN設定を選択します。この時点でデータ通信が出来るようになっているハズです。

この時点でデータ通信が出来ない場合、通信事業者を適切なものに設定する必要がある可能性があります。

KubeCon + CloudNativeCon Europe 2018にいってきた

Mon, 07 May 2018 07:08:58 +0000

過ぎし5月1日〜5月6日、出張でKubeCon + CloudNativeCon Europe 2018 に行ってきました！

KubeConはKubernetes(k8s) のイベントで、Cloud Native Computing Foundation(CNCF) が主催するCloudNativeConと併せた開催でした。今回の開催地はデンマークはコペンハーゲンのBella Centerで、実に4000人以上が参加したとのことです。 twitterハッシュタグは#kubecon で、一部#cloudnativecon も使われていたようです。

私個人としては初海外で、初日の移動で腰をぎっくりするなど、トラブルに見舞われながらも、なんとかこんとか行ってきました。

finnair

今回、飛行機はFinnair を使用しました。成田空港からヘルシンキ、ヘルシンキからコペンハーゲンの一回乗り継ぎです。成田空港からヘルシンキは約10時間、ヘルシンキからコペンハーゲンは約1.5時間のフライトです。

成田空港からヘルシンキのフライトでは、機内に備え付けのヘッドホンがノイズキャンセラー付きで、意外と音もよく、また、機内食もそこそこおいしかったため、比較的お勧め出来る航空会社かと思います。成田空港からヘルシンキのフライトはJALも含めたコードシェア便だったため、機内の放送では日本語でも放送される点が安心感があって良いなと感じました。

The Square

今回とったホテルはコペンハーゲンの繁華街にほど近いThe Square というホテルです。繁華街に近いため、観光にも困らず、飲み会をした後にも戻りやすい立地でした。

近所にはNETTO という24時間営業の比較的安いスーパーや、お土産の購入等にも便利なIrma という高級スーパーもあり、買い物には困ることがありませんでした。

繁華街まで脚を伸ばせば、Hard Rock Cafe や、国内でも一時期話題となったSuperdry¹などもあります。

また、今回のKubeConのパーティーがTivoli garden での開催だったため、パーティー会場がホテルの隣のブロック、という点でも非常に良い立地でした。

ホテルそのものも、おしゃれで、清潔な感じのホテルでした。シャワーが出ないということもありませんでしたし、最低限のアメニティも揃っていました。

冷蔵庫が壊れていたのか、中の飲み物等を冷やしてくれないのだけが少々残念でした。

KubeCon + CloudNativeCon Europe 2018

KubeCon + CloudNativeCon Europe 2018は非常に多くのトラックがあり、その多くのスライドがPDFで公開されています。

スライドはスケジュールからダウンロードすることができます。また、@superbrothers さんが一気にダウンロードするスクリプトを書いてくださっているので、こちらを使用することも出来ます。

I created a script that downloads all KubeCon + CloudNativeCon Europe 2018 slides from Sched! ? https://t.co/FyD1zhJbNk #KubeCon

Kubernetesのセキュリティのベストプラクティス by Ian Lewis

Thu, 19 Apr 2018 05:18:30 +0000

Japan Container Days v18.04 で表題のセッションを聞いたので、まとめました。

スライド資料

Kubernetesのセキュリティのベストプラクティス(SpeakerDeck)

APIサーバへの攻撃を防ぐ

RBACでPodに付与される権限を絞る

Podにはシークレットが自動でマウントされるため、不正アクセスにより読み込まれてしまうと危ない

FirewallでAPIサーバへのアクセスについてIP制限を付与する

いざ、シークレットが漏れた場合でも、APIサーバにアクセスされてしまわないように、ファイアウォールでIP制限をかけておくと良い

NetworkPolicyでDBへの接続が許可されるPodを制限する

大体の場合、重要なデータはDBに有るため、DBへのアクセスを絞ることで安全性を上げる

example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
 name: redis
spec:
 podSelector:
 matchLabels:
 name: redis
 ingress:
 - from:
 - podSelector:
 matchLabels:
 name: guestBook

ホストへの攻撃を防ぐ

次の三つを併用すると良い

non-rootユーザでPodを実行する

example:

1
2
3
4
5
6
7


kind: Pod
apiVersion: v1
metadata:
 name: security-context-demo
spec:
 securityContext:
 runAsUser: 1000

読み込み専用ファイルシステムを使用する

example:

1
2
3
4
5
6
7


kind: Pod
apiVersion: v1
metadata:
 name: security-context-demo
spec:
 securityContext:
 readOnlyRootFilesystem: true

no_new_privs

forkしたプロセスが強い権限を持てないようにする

Raspberry PiのヘッドレスインストールでWi-Fiを設定する

Wed, 18 Apr 2018 09:17:54 +0000

uzullaさんがブログでこんなことを書いてた。

しかし…/boot/のどこかに起動後実行されるスクリプトがあれば楽なのにな…（そこで無理やりwifi情報を書き込めば良いわけで）ヘッドレスRaspberry Pi Zero w(h)のコンソールやネットワークなど初期設定についてメモ - uzullaがブログ

私も過去何度かRaspberry Pi Zeroのヘッドレスインストールをしてまして、実はヘッドレスインストールの時にWi-Fi情報を書き込めるファイルがあるのです。

/boot/wpa_supplicant.confというファイルで、ここにWi-Fiの設定を書き込んで起動すると、raspbianが/etc/wpa_supplicant/wpa_supplicant.confに良い感じにコピーしてくれます。

上記uzullaさんのブログでいうと、「microSDのファイルを編集」の時に一緒に書き込んでおくと、起動時にその情報を使ってWi-Fiをつかんでくれます。あとはnmapするなり、ルータやらDHCPサーバやらのリース状況を確認するなりでラズパイに割当たったIPをゲットしてssh pi@xxx.xxx.xxx.xxx的にSSHするか、avahi/bonjourをつかってssh pi@raspberrypi.local的にSSHするかでログインできます。

wpa_supplicant.confの書き方は、上記uzullaさんのブログ記事の、「Raspberry Pi Zero wにWifiを設定する」ってところを見るか、こことかここにジェネレータを作ってくれてる人がいるので、利用して生成すると良いと思います。パスワードは平文でOKなので、適当な文字列を突っ込んで手元で書き換えると安心かもしれないです。

なお、NOOBSでやるときは、wpa_supplicant.confとsshは/bootではなく、ルートディレクトリにおけばOKです。さらに、recovery.cmdlineと言うファイルのquietという部分をvncinstallに書き換えることで起動したNOOBSにVNC接続できるようになります。

TOTPを実装する

Fri, 30 Mar 2018 17:03:45 +0000

ここ数年で多くのサービスで採用されてきている二要素認証ですが、皆さん使っているでしょうか。私は実は最近までは面倒であまり使っていなかったのですが、ようやく重い腰を上げてあちこち設定しました。そのうち、近年特によく使われているのがTOTP(Time-Based One-Time Password)と呼ばれるアルゴリズムです。 TOTPアルゴリズムはRFC6238 で定義されたアルゴリズムで、サーバとクライアントが共有する秘密鍵および現在時刻から確認用のコードを生成するものです。 RFCやWikipedia を見てわかるよう、かなり簡素なアルゴリズムで、一つ一つ理解していけば比較的簡単に実装することができます。 Go言語のコードを実例に、サンプルコードを実装してみます。

HOTPとTOTP

TOTPアルゴリズムとよく似たものに、HOTP(HMAC-Based One-Time Password)と呼ばれるアルゴリズムがあります。これは、サーバとクライアントが共有する秘密鍵と、「何回目の認証か」から確認用のコードを生成するアルゴリズムです。 HOTPアルゴリズムは(勿論)アルゴリズムですから、ある計算手順であり、秘密鍵と認証回数を引数にとって認証用コードを返す関数として表すことができます。この、認証回数という引数に対して、現在時刻を入力したものがTOTPです。認証「回数」というくらいですから、値は正の整数値です。時刻を整数として入力するため、UnixTimeを使用します。

実際にはUnixTimeそのままで入力すると1秒ごとに認証用コードが変わってしまい実用できではありませんから、ある秒数を一周期として、現在が何周期目なのか、という値を入力します。

TOTPを実装する

扨、前置きはこれくらいにしてTOTPアルゴリズムを実装します。次の式で表されます。

\begin{eqnarray*} TOTP(K, T_0, X) &=& HOTP(K, T(T_0, X)) \\ T(T_0, X) &=& \frac{(CurrentUnixTime - T_0)}{X} \end{eqnarray*}

$K$は共有秘密鍵です。
$T_0$は数えはじめの時間で、通常はUnix epoch、すなわち0を使用します。
$X$は一周期の秒数で、規定値は30秒です。(実際、多くのサービスが30秒ベースです)

プログラム実装は以下の様に書いてみます。

1
2
3
4
5
6
7


func TOTP(k string, t0, x int) int {
 return HOTP(k, T(t0, x))
}

func T(t0, x int) int {
 return (time.Now().Unix - t0)/x
}

簡単ですね。上記の内、定義されていないのはHOTP(K, T)だけとなりました。

Golang: 配列からスライスに変換する

Fri, 16 Mar 2018 02:19:13 +0000

TL;DR: slice := array[:]で変換できる

Go言語にはリストの様なものが二つあります。配列(固定長)とスライス(可変長)です。一般に、Go言語で配列を扱うことは多くないでしょう。実際、多くのパッケージ(標準パッケージを含む)が要求するのはスライスです。

とは言っても一部のパッケージでは配列を取り扱っているものがあります。例えば、crypto/sha512を見てみると、以下の様な関数が存在します。

1

func Sum512(data []byte) [Size]byte

ここで、Sizeは同パッケージ内で宣言されている定数で、値は64です。つまり、この関数は64バイトの長さを持った配列を返します。

この関数は与えられたデータからSHA512チェックサムを計算するものです。勿論、返ってきた値をそのまま使用することもあるとは思いますが、そのままの値は人間可読な値では無いため、hexdigestを得たいと思うでしょう。

Go言語にはもちろんのことながら、encoding/hexパッケージが存在し、簡単に16進文字列を得ることができます。 16進表記の文字列を得るためには、次の関数を使用します。

1

func EncodeToString(src []byte) string

引数に注目します。要求されているのはbyteのスライスです。

Goでは、配列とスライスは基本的に別物ですから、以下の様に書くことはできません。

1
2
3
4


h := sha512.Sum512("foobar")

// 型エラーが発生する
EncodeToString(h)

そうは言っても、配列とスライスは非常に似ています。次のように書きたくなりますね。

1
2


h := sha512.Sum512("foobar")
EncodeToString([]byte(h)) // 配列をスライスに変換したい

しかし、次のようなエラーを生じます。

cannot convert sha512.Sum512("foobar") (type [64]byte) to type []byte

型変換はできないようです。どうしたら良いのでしょうか。

Go言語では、配列の範囲インデックスを使った場合、返される値はスライスとなります。

1
2


a := [3]string{"foo", "bar", "baz"}
s := a[0:2] // sはスライス

また、インデックスを省略することもできます。開始値を省略すれば、0を与えたものと見なされますし、終了値を省略すれば、配列の最後までを切り取ります。

Let's Encryptでワイルドカード証明書を取得する

Tue, 13 Mar 2018 23:00:00 +0000

先日twitterでサポートされたと発表されたLet’s Encryptのワイルドカード証明書ですが、本日未明、正式にcertbotがワイルドカード証明書に対応したと発表されました !¹

早速ですが、実際にワイルドカード証明書を取得してみます。

尚、今回対象とした環境は以下のとおりです。

CentOS 7
リバースプロキシとしてnginx
DNSはGehirn DNS

では、作業していきます。

CentOS 7でcertbotを使用する場合、大抵はyumでcertbotをインストールしていると思いますので、まずはアップデートします。

1

$ sudo yum update

出力は省略しますが、certbotが0.22.0にアップデートされます。 0.22.0はワイルドカード対応バージョンですので、問題ないですね！

公式のマニュアルでは、dns-pluginを使うよう書いてありますが、Gehirn DNSのプラグインは無いため、今回は手動で行きます。以下のコマンドを実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


# certbot certonly --manual --preferred-challenges dns -d *.web-apps.tech --server https://acme-v02.api.letsencrypt.org/directory
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): nasa.9084.bassclarinet@gmail.com
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: a

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: y
Starting new HTTPS connection (1): supporters.eff.org
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for web-apps.tech

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.web-apps.tech with the following value:

qiGA8Vep17l0nYJ1O1AdF68D9iT7bL5Mpoe3j7-Caag

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

上記のようにTXTレコードを追加するようにメッセージが出たら、指定された値をDNSに追加します。 Gehirnでは以下のような形になります。

sygを使用したgraceful shutdown serverパターン

Sat, 10 Mar 2018 15:42:54 +0000

github.com/nasa9084/syg を使用すると、手軽にシグナルとコールバック関数のマッピングを行うことができます¹

これを使用し、SIGINTを受けてgraceful shutdownできるHTTPサーバを実装してみます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


package app

import (
 "context"
 "net/http"
 "os"
 "time"

 "github.com/nasa9084/syg"
)

type Server struct {
 server *http.Server
 closed chan struct{}
}

func NewServer() *Server {
 http.HandleFunc("/", longlongHandler)
 return &Server{
 server: &http.Server{
 Addr: ":8080",
 },
 closed: make(chan struct{}),
 }
}

func (s *Server) Run() error {
 // os.Interrupt　= syscall.SIGINT
 cancel := syg.Listen(s.shutdown, os.Interrupt)
 defer cancel()

 err := s.server.ListenAndServe()
 <-s.closed
 return err
}

func (s *Server) shutdown(os.Signal) {
 s.Shutdown(context.Background())
 close(s.closed)
}

func longlongHandler(w http.ResponseWriter, r *http.Request) {
 // なんか長い処理のつもり
 time.Sleep(10 * time.Second)
 w.Write([]byte("hello"))
}

mainからは以下の様に呼びます。

Golang: 手軽にシグナルをListenしてcallback関数を呼ぶ

Tue, 06 Mar 2018 14:32:00 +0000

Go言語でシグナルを取り扱いたい場合、osパッケージおよびos/signalパッケージ、syscallパッケージを使用します。

具体的には、以下のようにします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


func main() {
 sigCh := make(chan os.Signal, 1)
 doneCh := make(chan struct{})

 signal.Notify(sigCh, syscall.SIGINT)

 go func() {
 sig := <-sigCh
 fmt.Println(sig) // (1)
 close(doneCh)
 }()
 <-done
}

実際には、(1)の様に受け取ったシグナルを出力するだけではなく、何らかの処理を行うことになるでしょうし、goroutineのリークを避けるためにシグナルの待受をキャンセルする必要が有りますから、contextを使用してfor-selectループを書くことにもなるでしょう。

例として、HTTPサーバをシャットダウンするような処理を考えます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


func main() {
 sigCh := make(chan os.Signal, 1)
 doneCh := make(chan struct{})
 ctx, cancel := context.WithCancel(context.Background())

 signal.Notify(sigCh, syscall.SIGINT)

 s := &http.Server{
 Addr: ":8080",
 Handler: http.DefaultServeMux,
 }

 go func() {
 for {
 select {
 case sig := <-sigCh:
 sig := <-sigCh
 s.Shutdown(context.Background())
 close(doneCh)
 case <-ctx.Done():
 return
 }
 }
 }()

 if err := s.ListenAndServe(); err != http.ErrServerClosed {
 log.Println(err)
 cancel()
 return
 }
 <-doneCh
}

シグナルを受け取って、関数の呼び出し(ここではs.Shutdown())をしたいだけなのに、チャンネルを作って、goroutineを立ち上げて、となんとも大仰です。 goroutineで呼び出す関数の中でfor-selectループを使っているため、行数も長くなってしまっています。

strings.Builderとbytes.BufferのWrite系関数のベンチマーク

Mon, 05 Mar 2018 15:00:00 +0000

TL; DR

平均して見るとstrings.Builder#WriteXXXの方が速そう

strings.Builder

Go 1.10からstrings.Builder構造体が追加されました。公式ドキュメントには、

A Builder is used to efficiently build a string using Write methods. It minimizes memory copying. The zero value is ready to use. Do not copy a non-zero Builder.

と説明が書かれています。おそらく、これまで文字列の組み立てをする際にはbytes.Bufferを使っている場合が多かったと思われますが、そういった目的の選択肢として作られたようです。が、説明を読んでもいまいち違いがわかりません。

とりあえず、bytes.Bufferとstrings.Builderでは速度面で違いがあるのか調べるべく、ベンチマークを実施しました。

条件

実行した環境

MacBook Air
- MacOS Sierra 10.12.6
- CPU: Core i7 1.7GHz
- メモリ: 8GB

実行する関数

Write
WriteByte
WriteRune
WriteString

exec

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90


$ for i in {1..10}; do go test -bench . | tail -n +4 | head -n 8 && echo; done
BenchmarkBuilderWrite-4 10000000 129 ns/op
BenchmarkBuiderWriteByte-4 200000000 6.47 ns/op
BenchmarkBuilderWriteRune-4 200000000 7.61 ns/op
BenchmarkBuilderWriteString-4 30000000 92.4 ns/op
BenchmarkBufferWrite-4 50000000 196 ns/op
BenchmarkBufferWriteByte-4 300000000 9.40 ns/op
BenchmarkBufferWriteRune-4 200000000 8.18 ns/op
BenchmarkBufferWriteString-4 50000000 217 ns/op

BenchmarkBuilderWrite-4 10000000 189 ns/op
BenchmarkBuiderWriteByte-4 100000000 10.5 ns/op
BenchmarkBuilderWriteRune-4 100000000 10.4 ns/op
BenchmarkBuilderWriteString-4 30000000 157 ns/op
BenchmarkBufferWrite-4 50000000 238 ns/op
BenchmarkBufferWriteByte-4 100000000 19.9 ns/op
BenchmarkBufferWriteRune-4 100000000 15.5 ns/op
BenchmarkBufferWriteString-4 30000000 422 ns/op

BenchmarkBuilderWrite-4 10000000 131 ns/op
BenchmarkBuiderWriteByte-4 200000000 7.58 ns/op
BenchmarkBuilderWriteRune-4 200000000 8.48 ns/op
BenchmarkBuilderWriteString-4 30000000 113 ns/op
BenchmarkBufferWrite-4 50000000 199 ns/op
BenchmarkBufferWriteByte-4 100000000 10.4 ns/op
BenchmarkBufferWriteRune-4 200000000 12.0 ns/op
BenchmarkBufferWriteString-4 50000000 382 ns/op

BenchmarkBuilderWrite-4 10000000 122 ns/op
BenchmarkBuiderWriteByte-4 200000000 7.45 ns/op
BenchmarkBuilderWriteRune-4 200000000 8.44 ns/op
BenchmarkBuilderWriteString-4 30000000 155 ns/op
BenchmarkBufferWrite-4 50000000 264 ns/op
BenchmarkBufferWriteByte-4 200000000 7.08 ns/op
BenchmarkBufferWriteRune-4 200000000 10.1 ns/op
BenchmarkBufferWriteString-4 30000000 413 ns/op

BenchmarkBuilderWrite-4 20000000 117 ns/op
BenchmarkBuiderWriteByte-4 200000000 6.81 ns/op
BenchmarkBuilderWriteRune-4 200000000 6.87 ns/op
BenchmarkBuilderWriteString-4 50000000 219 ns/op
BenchmarkBufferWrite-4 20000000 101 ns/op
BenchmarkBufferWriteByte-4 200000000 6.22 ns/op
BenchmarkBufferWriteRune-4 200000000 12.2 ns/op
BenchmarkBufferWriteString-4 50000000 513 ns/op

BenchmarkBuilderWrite-4 10000000 161 ns/op
BenchmarkBuiderWriteByte-4 200000000 8.36 ns/op
BenchmarkBuilderWriteRune-4 200000000 8.24 ns/op
BenchmarkBuilderWriteString-4 30000000 109 ns/op
BenchmarkBufferWrite-4 50000000 296 ns/op
BenchmarkBufferWriteByte-4 100000000 10.6 ns/op
BenchmarkBufferWriteRune-4 100000000 11.4 ns/op
BenchmarkBufferWriteString-4 50000000 484 ns/op

BenchmarkBuilderWrite-4 10000000 133 ns/op
BenchmarkBuiderWriteByte-4 200000000 7.16 ns/op
BenchmarkBuilderWriteRune-4 200000000 8.10 ns/op
BenchmarkBuilderWriteString-4 30000000 194 ns/op
BenchmarkBufferWrite-4 50000000 190 ns/op
BenchmarkBufferWriteByte-4 200000000 5.51 ns/op
BenchmarkBufferWriteRune-4 200000000 8.72 ns/op
BenchmarkBufferWriteString-4 50000000 281 ns/op

BenchmarkBuilderWrite-4 10000000 136 ns/op
BenchmarkBuiderWriteByte-4 200000000 11.4 ns/op
BenchmarkBuilderWriteRune-4 50000000 28.0 ns/op
BenchmarkBuilderWriteString-4 10000000 119 ns/op
BenchmarkBufferWrite-4 20000000 144 ns/op
BenchmarkBufferWriteByte-4 100000000 16.0 ns/op
BenchmarkBufferWriteRune-4 200000000 8.43 ns/op
BenchmarkBufferWriteString-4 50000000 248 ns/op

BenchmarkBuilderWrite-4 10000000 130 ns/op
BenchmarkBuiderWriteByte-4 200000000 7.83 ns/op
BenchmarkBuilderWriteRune-4 200000000 7.13 ns/op
BenchmarkBuilderWriteString-4 30000000 99.0 ns/op
BenchmarkBufferWrite-4 50000000 202 ns/op
BenchmarkBufferWriteByte-4 200000000 10.7 ns/op
BenchmarkBufferWriteRune-4 100000000 13.8 ns/op
BenchmarkBufferWriteString-4 50000000 452 ns/op

BenchmarkBuilderWrite-4 10000000 146 ns/op
BenchmarkBuiderWriteByte-4 200000000 7.89 ns/op
BenchmarkBuilderWriteRune-4 200000000 8.24 ns/op
BenchmarkBuilderWriteString-4 30000000 122 ns/op
BenchmarkBufferWrite-4 50000000 248 ns/op
BenchmarkBufferWriteByte-4 100000000 31.7 ns/op
BenchmarkBufferWriteRune-4 100000000 25.4 ns/op
BenchmarkBufferWriteString-4 30000000 413 ns/op

Source

ベンチマークスクリプトのソースは以下の様になっています。

Go言語で文字列を処理する

Mon, 05 Mar 2018 14:00:00 +0000

Go言語のregexpパッケージを使用した正規表現の処理は、一般的なスクリプト言語の処理速度と同程度で、正規表現を使用しない処理に比べてパフォーマンスがよくありません¹。そのため、可能であるならregexpパッケージを使用しないようにすべきです。しかし、すべての処理を自分で書くのは大変です。標準パッケージにも文字列を処理する関数が数多く用意されています。

`strings` パッケージ

stringsパッケージはその名の通り、文字列を取り扱うパッケージです。 UTF-8でエンコードされた文字列(普通の文字列)をそのまま取り扱います。

判別系

`Contains`

1

func Contains(s, substr string) bool

Contains関数は、sの中にsubstrが存在するかどうかを返します。 Pythonで言うところのsubstr in sに相当します。正規表現ならば、substrとのmatchで真偽値をとることに相当します。

example

1
2
3
4
5


fmt.Println(strings.Contains("hogefugapiyo", "fuga"))
// Output: true

fmt.Println(strings.Contains("hogefugapiyo", "foo"))
// Output: false

`ContainsAny`

1

func ContainsAny(s, chars string) bool

ContainsAny関数はsの中に、charsに含まれる文字のいずれかが存在するかどうかを返します。つまり、charsは文字列ですが、扱いとしては文字の配列であると考えた方が良いでしょう。

正規表現で表すなら、/[${chars}]/の様な表現と考えられます(${chars}は置き換える)。

example

1
2
3
4
5


fmt.Println(strings.ContainsAny("hogefugapiyo", "abcd"))
// Output: true

fmt.Println(strings.ContainsAny("hogefugapiyo", "1234"))
// Output: false

`HasPrefix`

1

func HasPrefix(s, prefix string) bool

HasPrefix関数は、sの頭がprefixと等しいかどうかを判別します。正規表現で^を使った文字列マッチに相当します。

YAPC::Okinawa 2018 ONNASONに行ってきました

Sun, 04 Mar 2018 13:44:24 +0000

YAPC::Fukuoka 2017 HAKATA (行ってきたときの記事はこちら )に引き続き、YAPC::Okinawa 2018 ONNASON に行ってきました。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした(#yapcokinawa もよく使われていたようです)。

沖縄は昨年6月にOSC 2017 Okinawa で行って以来二度目です。 YAPC当日はすごい雨で、YAPC::Hokkaidoで大雪だったことを思い出し、「端っこでYAPCをやると何かが起きるのでは」などと言われる具合でした。

今回は直前までホテルが取れなかったものの、過去のYAPCでホテルを取らずに行って適当になんとかなったので、なんとかなるだろうと思っていましたが、直前に東横インを確保できたので、宿無し旅行ではありませんでした。

YAPC::Okinawa 2018 ONNASON

今回は会場がOIST だったため(OISTは那覇市内から車で約一時間)、多くの人がスタッフが手配した往復バスでの参加となりました。そのため、寝坊する人は少なく(いなくはなかったようです)、私もオープニングから参加できました。

オープニングはCodeHex 氏。

オープニングを行ったA会場は非常に広く、なんと全席にコンセントがついているという素晴らしいホールでした。

ノベルティはこんな感じ。特筆すべきはDeNAさんのQi充電器でしょうか。しかし私はQi対応端末を持っていないので使えないのが残念・・・・毎度恒例、ネコトーストラボさんのサイリュームもあります。

YAPC::Hokkaidoから行われてきたチェックインスタンプラリーもココで一区切り。コンプリート特典として、JPAのラクダさんのシャチハタスタンプをいただきました。

トークでは、「レイヤー0(電波)からレイヤー8(交渉事)までできる人を募集しています」や、「無曖昧でない」など、会場がどっと沸く名言(迷言？)がいくつか飛び出ました。

個人的には、@moznionさんのInlineモジュールの話や、新屋さんの正規表現の話が非常に面白かったと思います。特に、正規表現の話ではバックトラックと曖昧な正規表現の相性が悪い、といった技術的な話にとどまらず、文脈自由文法など、計算理論にまで踏み込んだトークとなっており、OISTという会場でのトークに相応しい素晴らしい内容だったと思います。

次回のお話

次回YAPCは東京だそうです！現在はまだテザーサイトがある程度で、日程、会場は調整中とのことでした。

cut vs. parameter expansion

Mon, 26 Feb 2018 08:07:11 +0000

TL;DR:: bash/zsh parameter expansion is faster than cut.

which is faster?

Consider you want to take out hostname from URL or IP with port like some.mysql.server:3306 or 192.168.1.10:3306 using bash/zsh. There are some way to do this.

The first way is using cut command:

1
2


$ TARGET="192.168.1.10:3306"
$ echo ${TARGET} | cut -d ":" -f 1

Now printed 192.168.1.10 on your screen.

The second way is using “shell parameter expansion”, which is functions of bash/zsh built-in. You can use shell parameter expansion like below:

Goでコマンドラインオプションを処理する

Sat, 24 Feb 2018 03:22:28 +0000

TL;DR

github.com/jessevdk/go-flagsが便利

flagパッケージ

コマンドライン・ツールを作ろうと考えたとき、避けては通れないのがコマンドラインオプションを如何に処理するか、ということです。

Go言語では、標準パッケージにflagというパッケージが存在し、これを用いることでコマンドラインオプションをパースすることが出来ます。しかし、flagパッケージでは、ロングオプションとショートオプションを一度に定義することが出来ず、また、ロングオプションであろうとショートオプションであろうと-XXXという、ハイフンが一つつく形式のオプションとなります。これはあまり一般的ではなく¹、便利とも言いにくいでしょう。

そこで便利なのが、jessevdk/go-flags パッケージです。

go-flagsパッケージ

jessevdk/go-flags パッケージは、その名の通り、コマンドラインオプションを取り扱うパッケージです。ショートオプション、ロングオプションはもちろんのこと、ショートオプションをまとめて指定する、同じオプションを違う引数で複数回指定する、環境変数からの読み込み、デフォルト値の指定などに対応していて、一般的なオプションの処理に幅広く対応出来ます。オプションは構造体として定義出来るため、パースした後の処理で取り回すのも簡単です。

簡単な例を見てみましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


type options struct {
 Name string `short:"n" long:"name" description:"listen address"`
}

func main() {
 var opts options
 if _, err := flags.Parse(&opts); err != nil {
 // some error handling
 return
 }
 fmt.Printf("Hello, %s\n", opts.name)
}

パッケージ宣言やインポートの節は省略していますが、上記をmain.goとして実行すると、以下の様に出力されます。

kubesprayを使用してkubernetes clusterを構築する(2)

Fri, 23 Feb 2018 14:45:49 +0000

3ヶ月ほど前に、kubesprayを使用してkubernetes clusterを構築するという、kubespray とkubespray-cliを使用してKubernetesクラスタを構築する記事を書きました。しかし、kubespray-cliはすでにdeprecatedだということなので、kubespray-cliを使用せずにkubesprayでクラスタを構築する手順をまとめておきます。

要件

kubesprayを使用してkubernetesクラスタを構築するための要件は以下のようになっています。

ansible 2.4以降とpython-netaddr (python-netaddrを忘れがちなので注意)
- pip install ansible netaddr
Jinja 2.9以降(ansibleの依存でインストールされると思います)
構築先サーバがインターネットに接続できること
構築先サーバでswapが無効化されていること
構築先サーバでIPv4 forwardingが有効になっていること
- sysctl -w net.ipv4.ip_forward=1する(再起動するまで)
- /etc/sysctl.confにnet.ipv4.ip_forward = 1と記入する(再起動後)
Ansibleを実行するマシンから構築先サーバにSSH鍵が渡されていること
ファイアウォールが無効化されていること
- ファイアウォールの設定をしっかりできる人は有効でも

また、kubesprayには(kubespray-cliのような)inventory生成ツールが付属されており、これを利用する場合はpython3系である必要が有ります。

構成

前回の記事同様、以下のIPを持った三台のサーバを対象として構築してみます。

192.168.1.11
192.168.1.12
192.168.1.13

それぞれ、IPv4 forwardingが有効化され、firewalldを無効化し、Python 3をインストール済みのCentOS 7のサーバとします。また、kubesprayを実行するローカルマシンから、各サーバのrootユーザにSSH鍵を配置¹済みとします。

手順

準備

まず、kubesprayをダウンロードします。

1
2


$ git clone https://github.com/kubernetes-incubator/kubespray
$ cd kubespray

リポジトリのクローンが完了したら、ansibleなどの依存モジュールを導入します²。

1

kubespray$ pip install -r requirements.txt

次に、ansible用のインベントリを作成します。

1
2
3


kubespray$ cp -rfp inventory/sample inventory/mycluster
kubespray$ declare -a IPS=(192.168.1.11 192.168.1.12 192.168.1.13)
CONFIG_FILE=inventory/mycluster/hosts.ini python3 contrib/inventory_builder/inventory.py ${IPS[@]}

IPSは対象サーバのIPに合わせて定義をします。また、環境によっては、python3コマンドではなく、pythonコマンドでPython 3が実行される場合も有ります。適宜読み替えてください。

Generates LICENSE file: git-license

Wed, 21 Feb 2018 04:56:49 +0000

When we create a new repository on GitHub , we can choose an open source license.

We choose an OSS license, then, LICENSE file is put into the new repository.

Now, I’m usually using hub command to create a new repository. I’ll do below to create:

1
2
3
4
5
6
7
8


$ mkdir my_new_repository
$ cd my_new_repository
$ git init
#
# ... some code writing and commit ...
#
$ git create # git command is aliased to hub
$ git push -u origin master

In this flow, I can write description for repository¹, set homepage², make the repository private³, but I CANNOT choose LICENSE. I can choose and create LICENSE file on the GitHub web page, or I can copy from my other repositories because its content is fixed. However, I don’t do that.

テキストを列ごとにそろえて出力する

Mon, 29 Jan 2018 07:13:10 +0000

TL;DR: 標準パッケージtext/tabwriter を使用する

コマンドラインツールで標準出力を良い感じにそろえて出力したい場合があります。例えば、docker では、以下の様に出力されます。

1
2
3
4


$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8caad461b4a4 redis "docker-entrypoint.s…" 5 days ago Up 5 days 0.0.0.0:6379->6379/tcp redis-svr
329c9f9be035 mysql "docker-entrypoint.s…" 5 days ago Up 5 days 0.0.0.0:3306->3306/tcp mysql-svr

このような map、あるいは構造体の配列 の様なものを、きれいに表形式の様に列をそろえて出力したい場合に便利なのが標準パッケージのtext/tabwriter です。その名の通り、タブ区切りの文字列を良い感じに出力してくれるパッケージです。

text/tabwriterで定義されているのはいくつかの設定用定数と、Writer構造体のみです。 Writerは(勿論)io.Writerインターフェースを実装しています。

使用方法は通常のio.Writerとはすこし変わっていて、最初にWriter.Init() で初期化し、任意回数Writer.Write() で書き込みをした後、Writer.Flush() で整形した文字列を出力します。 NewWriter() 関数はWriter構造体をnew()した後Init()するのと同等です。

Writer.Init()関数及びNewWriter()関数に与える引数は以下の様になっています。

名前	型	内容
`output`	`io.Writer`	`Flush()`したときの出力先
`minwidth`	`int`	1セルあたりの最小幅(パディングを含む)
`tabwidth`	`int`	タブ文字の幅(スペースの個数と等しい)
`padding`	`int`	パディング¹
`padchar`	`byte`	パディング文字²
`flags`	`int`	調整用フラグ

最後の引数である、調整用フラグには0(標準状態)を与えるか、パッケージ定数の論理和を用いて設定を与えます。

Vagrant/vmware-fusionでハードウェア仮想化を有効にしたVMを作成する

Thu, 28 Dec 2017 04:29:59 +0000

vmware fusionを使用している場合、仮想マシンのCPU設定でこの仮想マシンでハイパーバイザアプリケーションを有効にするにチェックを入れることで仮想マシン内でKVMを動作させることができるようになります。ドキュメントには載っていませんが¹、Vagrant + vmware-fusion pluginの構成でも設定することが可能です。 Vagrantfileに以下の記述を追加します。

1
2
3


config.vm.provider "vmware_fusion" do |v|
 v.vmx["vhv.enable"] = "TRUE"
end

vmxの設定をする方法自体は公式ドキュメントにも記載がありますが、詳細がありません ↩︎

container-upというツールを書いた

Fri, 22 Dec 2017 04:23:39 +0000

container-up というツールを書いたのでご紹介。

背景

このブログはghost というブログエンジンで動いています。動作環境としてDocker を使用していて、Ghostの公式イメージを使用しています。過去の経緯から、単体のDockerコンテナで動作させており、永続データはDockerボリュームとしてマウントしている形です。

扨、Docker ComposeやKubernetesなどのオーケストレーションツールを使っている場合、コンテナのバージョンアップは比較的簡単に行うことができます。たとえば、Docker Composeを使用している場合、docker-compose upで、新しいイメージで作成したコンテナに差し替えることができます。

しかし、Dockerを単体で使っている場合、基本的には手作業で差し替えを行う必要があります。 Ghostコンテナの更新時は手作業でBlue-Greenアップグレードを行ってきたのですが、Ghostはかなりアップデートのペースが速く、毎度コンテナを差し替えるのが面倒になってきました。それを楽にするため、container-upを作りました。

インストール

Go環境がある人

Go言語の環境がすでにある人は、以下のコマンドで使用できるようになります。

1

$ go get github.com/nasa9084/container-up

それ以外の人

Go言語の環境がない人は、Releases ページから自分のOSに併せてバイナリをダウンロード、パスを通してください。 windows, linux, macos向け、それぞれamd64版のバイナリを用意してあります。動作確認はmacos、linux(CentOS 7)のみ行っています。

これら以外の環境の人は、予めdep をインストールした上で以下のコマンドでコンパイルしてください。

1
2
3
4


$ git clonse https://github.com/nasa9084/container-up.git
$ cd container-up
$ dep ensure
$ go build -o container-up main.go

コンパイルしたら、任意の場所にバイナリを移動し、パスを通してください。

使い方

基本的な使い方は、引数にコンテナ名またはコンテナIDを渡すだけです。

1

$ container-up CONTAINER_NAME

与えられたコンテナと同じ名称のイメージを使用して、ボリュームやネットワークなどの設定はそのままに新しいコンテナを作成し、差し替えます。 :latestなイメージを使用している場合、docker pullした後にこのコマンドを実行することで、最新のイメージから作られたコンテナに差し替わるということです。

もとのコンテナは--rmオプションをつけて起動していた場合を除いて、_oldContainerというサフィックスが付いた状態でstopします。なにか問題があった場合は、このコンテナに戻すと良いでしょう。

もし、元のコンテナが必要ない場合は、--rmオプションをつけると、差し替え時に削除します。

1

$ container-up --rm CONTAINER_NAME

:latestではないような、バージョンタグが付いたイメージを使用していて、新しいバージョンのイメージを使いたい場合などのため、新しいイメージ名を指定して実行することもできます。

Kubernetes-powered Docker for mac is released!

Thu, 14 Dec 2017 05:03:01 +0000

DockerCon EU 2017で、DockerがKubernetesを統合・サポートすると発表されましたが、本日ついにKubernetesサポート版Docker for macが(Edgeリリースですが)リリースされました！

これにより、macを使用している場合は(おそらく過去最も簡単に)開発用Kubernetesクラスタを起動することができるようになりました！

この記事では、Docker for macでKubernetesを立ちあげる手順をまとめておきます。

Kubernetesの起動手順

Docker for macのStable版を利用している場合、Edge版をインストールする必要があります。 Install Docker for mac のページから、Edge Channelのインストーラをダウンロードし、インストールします。 Dockerを終了させておけば、Stable版を自分でアンインストールする必要はありません¹。 Edge版をインストールし、Dockerの設定画面を開くと、以下の様にKubernetesタブが追加されています！！

Kubernetesタブで、Kubernetesの有効化・無効化を簡単に切り替えることができます。

Enable Kubernetesにチェックを入れ(Show system containersはお好みで)、Apply & Restartボタンを押すと、「Kubernetesの初回インストールは少し時間かかるけど、インストールする？」という確認画面が出るので、Installを押します。

一応プログレスバーが出るのですが、余り意味はありませんでした・・・数分でインストールが終わります。

無事インストールが終了したら、Closeを押したあと、設定画面を閉じます。

この時点で、DockerメニューにもKubernetesのステータスが表示されています。

今回私はShow system containersをオンにしたので、docker ps²するとKubernetesの動作に必要なコンテナが起動しています。 DNS、API Server、Etcd、Scheduler、Proxyと最小限の構成ですね。

kubectlが自動でインストールされるのかどうかは・・・・わかりませんでした。(すでにインストール済みだったため) kubectlがインストール済みの場合、自動でコンフィグが追加され、以下のコマンドでcontextを選択することで操作できるようになります。

$ kubectl config use-context docker-for-desktop

kubectl get nodesすると、確かに1ノード構成でクラスタが立ち上がっているのがわかります。

Edge版の初回起動時にアンインストールされます ↩︎
docker container lsと打つのは面倒ですね ↩︎

go-sqlrow

Wed, 13 Dec 2017 02:44:32 +0000

この記事はGo2 Advent Calendar 2017 13日目の記事です。昨日は@kami_zh さんの Goで標準出力をキャプチャするパッケージを書いたでした。

go-sqlrow

Go言語で標準パッケージを使用してRDBMSからデータを取ってくるには、以下の様に書きます¹。

1
2
3
4
5
6
7
8
9


type Person struct {
 ID string
 Name string
}

db, _ := sql.Open("dn", "dsn")
row, _ := db.Query(`SELECT id, name FROM person where id='foo'`)
var p Person
row.Scan(&p.ID, &p.Name)

SQL文を発行するまではいいのですが、最後の行、sql.Row#Scanがくせ者です。上記の例のように、sql.row#Scanは可変長個のポインタを引数にとり、それらにそれぞれ値をセットします。この例では値の数が2つのため大きな問題ではありませんが、値の数が増えた場合などは非常に面倒です。また、テーブルの構造が変わった場合なども非常に面倒です。

この問題を解決するため、go-sqlrow という小さなパッケージを作りました²。これは上記のrow.Scanを代わりにやってくれるパッケージです。

機能・使い方は簡単で、先ほどの例を次の様に書き換えます。

1
2
3
4
5
6
7
8
9


type Person struct {
 ID string
 Name string
}

db, _ := sql.Open("dn", "dsn")
row, _ := db.Query(`SELECT id, name FROM person where id='foo'`)
var p Person
sqlrow.Bind(row, &p)

後は内部でrow.Scan相当の処理を行います。 unexportedなフィールドはencoding/json同様、sql.Rowとの対応がとれませんので、注意が必要です。

Parcel + Riot.js

Tue, 12 Dec 2017 15:00:00 +0000

この記事は Riot.js Advent Calendar 2017 13日目の記事です。昨日は@supple さんによるRiot+ElectronでMarkdownエディタを作るでした。

tl;dr

Parcel というJavaScriptのモジュールバンドラを触ってみた
webpackなどと比べて設定ファイルなどもいらずとても簡単
ホットリロードな開発サーバを簡単に実行できる
Riotと組み合わせるのもそれほど難しくない

Parcel + Riot.js

Parcel というJavaScriptのモジュールバンドラが話題なのでさわってみました。国内で話題になっている元の記事は「webpack時代の終わりとparcel時代のはじまり」。 React との組み合わせで記事を書かれています。

個人的にはRiot.js が好みなので、Riot.jsとの組み合わせで触ってみました。尚、webpackは挫折したため比較できません。

Parcel/Riot.jsのインストール

npmを使ってインストールします。

1

$ npm install -g parcel-bundler riot

source code

ディレクトリ構造

以下の様なディレクトリ構造だとします。なお、練習用のため、動作確認に関係ない部分は適当に削っています。

src/
|- index.html
|- index.js
|- package.json
|- app/
| |- App.tag

index.html

1
2
3
4
5
6
7
8


<!doctype html>
<html lang="ja">
 <head></head>
 <body>
 <App></App>
 <script src="index.js"></script>
 </body>
</html>

index.js

1
2
3
4


import riot from 'riot'
import './app/tags'

riot.mount('App')

App.tag

1
2
3
4
5
6
7


<App>
 <h1>Hello, parcel world!</h1>

 <script>
 import riot from 'riot'
 </script>
</App>

package.json

package.jsonはnpm init -yで作成しました。

kubesprayを使用してkubernetes clusterを構築する

Thu, 30 Nov 2017 09:04:06 +0000

注意: 情報が古くなっています。新しい情報にあわせて記事を書いたので、そちらをご覧ください。

kubespray はproduction readyなkubernetes(k8s)クラスタを構成できるツールです。 Ansible をベースに作られているため、任意のサーバでk8sクラスタを構成できます。

今回は、3台のVMを用意してクラスタを構成してみます¹。

検証環境

今回用意したVMは以下の構成です。

2Core
8GB RAM
80GB HDD
CentOS 7

IPアドレスは以下の様になっているものとします。

192.168.1.11
192.168.1.12
192.168.1.13

また、kubesprayを実行するローカルの環境はmacOS Sierraです。各ホストのrootユーザに対してSSH鍵は配置済み、firewalldは無効化されているとします。

requirements

実行する環境に、Ansible が必要なため、pipでインストールします。²³

1

$ pip install ansible

install kubespray-cli

kubespray自体もpipでインストールします。

1

$ pip install kubespray

prepare

設定ファイルを生成するため、kubespray prepareを使用します。

1

$ kubespray prepare --nodes node1[ansible_ssh_host=192.168.1.11] node2[ansible_ssh_host=192.168.1.12] node3[ansible_ssh_host=192.168.1.13]

deploy

以下のコマンドでk8sクラスタをデプロイします。

1

$ kubespray deploy -u root -n flannel

今回はflannel ネットワークプラグインで構成しました。 kubesprayは、次のネットワークプラグインを使用してクラスタを構成することができます。

あとは構成が終了するのを待つだけです。

GitLab Docker: initial runners registration token

Wed, 22 Nov 2017 01:17:14 +0000

GitLab はRuby on Railsで書かれたオープンソースのGitサーバアプリケーションです。おそらく、オープンソースのGitサーバとしては最もよく使われているものではないでしょうか。 GitLabは他のOSS Gitサーバアプリケーションと比べて、非常に多くの機能を持っています。 GitLab-CIもその一つで、GitLab上で自動テストを回すことができます。

この、GitLab-CIを使用するにはrunnerと呼ばれる、CI環境用のホストを追加する必要があります。このとき、Registration Tokenという登録用トークンが必要なのですが、REST APIで取得することができません。そのため、Dockerを用いた自動構築時に少々困りました。

解法

GitLab omnibusの設定項目でRegistration Tokenの初期値を設定することができます。 docker runする際のオプションに、以下を追加します。

1

-e GITLAB_OMNIBUS_CONFIG="gitlab_rails['initial_shared_runners_registration_token'] = 'HOGEHOGETOKEN'"

もし、ほかの理由ですでにGITLAB_OMNIBUS_CONFIGの指定がある場合、セミコロン区切りで複数の値を指定することができます。たとえば、初期パスワードを与えている場合は、以下の様にできます。

1

-e GITLAB_OMNIBUS_CONFIG="gitlab_rails['initial_root_password'] = 'FUGAFUGAPASSWORD'; gitlab_rails['initial_shared_runners_registration_token'] = 'HOGEHOGETOKEN'"

ここで指定した値をrunnerの登録時に与えれば、OKです。

1

docker exec GITLAB_RUNNER_CONTAINER_NAME gitlab-runner register -n -r HOGEHOGETOKEN --run-untagged --executor docker --docker-image alpine:latest --url http://GITLAB_URL --docker-volumes /var/run/docker.sock:/var/run/docker.sock

このとき、GITLAB_RUNNER_CONTAINER_NAMEとGITLAB_URLは適宜置き換えてください。

Application Specific Context

Tue, 21 Nov 2017 04:21:58 +0000

元ネタは@lestrrat さんの「Abusing type aliases to augment context.Context 」。

golangを用いてHTTPサーバを作る場合、ルーティングを定義するのに以下の様な関数を用います。

1

http.HandleFunc(path string, handler func(w http.ResponseWriter, r *http.Request)

もちろん、http.Handleを用いる場合もありますし、gorilla/mux などのライブラリを用いることもあると思います。ここで重要なのは、func(w http.ResponseWriter, r *http.Request)という引数の方です。

多くの場合、アプリケーションのハンドラ内ではデータベースなどの外部アプリケーション・ミドルウェアを用いることになります。しかし、golangのHTTPアプリケーションでは、ハンドラ関数の形式がfunc (w http.ResponseWriter, r *http.Request)と決まっています。引数の追加はできないため、引数以外の方法でDB接続情報などを渡す必要があります。

これまで、golangでWebアプリケーション開発を行う場合によく用いられていたデータベースコネクションの保持方法は、dbパッケージを作成し、そこにパッケージ変数として持つ方法かと思います。が、グローバルな変数はできるだけ持ちたくないですよね。

そこで、Go 1.8から追加されたcontext を使うことができます。http.Request にはcontext.Contextが入っていて、Request.Context() でget、Request.WithContext() でsetできます。

context.Contextに値を持たせる方法で最初に思いつくのはContext.WithValue() を用いる方法ですが、これは値を取得する度にtype assertionをする必要があり、あまりよくありません。これを解消するため、自分で型を定義するのがよいでしょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


package context // internal context subpackage

import (
 "context"
 "errors"
)

type withSomethingContext struct {
 context.Context
 something *Something
}

func WithSomething(ctx context.Context, something *Something) context.Context {
 return &withSomethingContext{
 Context: ctx,
 something: something,
 }
}

func Something(ctx context.Context) (*Something, error) {
 if sctx, ok := ctx.(*withSomethingContext); ok {
 if sctx.something != nil {
 return sctx.something, nil
 }
 }
 return nil, errors.New(`no asscosiated something`)
}

このように定義をすることで、毎回type assertionをする必要もなくなり、すっきりします。

GNU MOファイルの構造

Mon, 06 Nov 2017 09:08:27 +0000

GNU MOファイルの内部構造について、最小限ですが解説します。

Travis CIでdockerのバージョンを最新にする

Wed, 18 Oct 2017 09:17:00 +0000

Travis CIでDockerfileをテストする等、dockerを使用したい場合、以下の様に.travis.ymlに記述することでdockerを有効にすることできます。

1
2
3
4


sudo: required

service:
 - docker

が、その際のdockerのバージョンは17.03.1¹と、最新版ではありません。特に問題なのが、multi-stage build は17.05からの機能であるということです。 Travis CIで使用できるdockerでは、multi-stage buildを使用したDockerfileはビルドすることができず、常にfailedとなってしまいます。

解決方法

Travis-CIでDockerのバージョンを上げるには、以下の記述を.travis.ymlに追加します。

1
2
3
4
5
6
7
8


sudo: required

service:
 - docker

before_install:
 - sudo apt-get update
 - sudo apt-get install -y -o Dpkg::Options::="--force-confnew" docker-ce

dockerの再起動などの処理は必要ありません。以上の記述により、Dockerのバージョンが最新版にアップデートされ、multi-stage buildも使用できるようになります。

2017年10月18日現在 ↩︎

Kolla-AnsibleでOpenStack Ocata環境を構築する

Wed, 04 Oct 2017 06:12:37 +0000

OpenStack Kollaを用いると、比較的簡単にOpenStack on Docker環境を構築することができます。今回はKolla-Ansibleを使用してall-in-one構成で4.0.0(Ocata)環境を構築してみます。

Kolla-ansible precheckで発生するエラーの対処

Fri, 29 Sep 2017 14:20:16 +0000

「OpenStack Kolla(Ocata)環境の構築」を参考にOpenStack Kollaのセットアップを行っていたら、エラーが出ました。

Functional Option Pattern

Tue, 26 Sep 2017 01:44:53 +0000

Fuctional Option PatternはGo言語において構造体の初期化時にオプション引数を与えるためのデザインパターンで、元ネタはRob Pike氏のSelf-referential functions and the design of options 、Dave Cheney氏のFunctional options for frendly APIS です。

Go言語には他の言語でオプション引数やキーワード引数と呼ばれる、省略可能な引数が存在しません。通常は大きな問題は無いのですが、しかし、構造体の初期化時には、省略可能引数がほしくなる場合もあります。

Dave Cheney氏の記事にもある例を見てみましょう。

例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


type Server struct {
 listener net.Listener
}

func NewServer(addr string) (*Server, error) {
 l, err := net.Listen("tcp", addr)
 if err != nil {
 return nil, err
 }
 srv := Server{listener: l}
 go srv.run
 return &srv, nil
}

よくある構造体の初期化関数です。初期化が上手くいけば、ポインタとnilを、上手くいかなければnilとエラーを返す形になっています。

go-redis, redigo, boltのベンチマークを取ってみた

Thu, 07 Sep 2017 04:40:01 +0000

tl;dr

データベースに接続済みの状態からstringで値をセット・ゲットするベンチマーク
- BoltのGetがめちゃめちゃ速い
- go-redisよりはredigoの方が速い
- Boltのセットがメモリアロケーションすごく多い

result

1
2
3
4
5
6
7
8
9


$ go test -bench .
BenchmarkRedisSet-4 10000 246527 ns/op 249 B/op 9 allocs/op
BenchmarkRedisGet-4 5000 231569 ns/op 225 B/op 9 allocs/op
BenchmarkRedigoSet-4 5000 204545 ns/op 70 B/op 4 allocs/op
BenchmarkRedigoGet-4 5000 209392 ns/op 80 B/op 6 allocs/op
BenchmarkBoltSet-4 10000 166142 ns/op 34287 B/op 57 allocs/op
BenchmarkBoltGet-4 1000000 1140 ns/op 488 B/op 8 allocs/op
PASS
ok practices/redis-bolt-benchmark 8.705s

source

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82


package rbbench_test

import (
 "testing"

 "github.com/boltdb/bolt"
 redigo "github.com/garyburd/redigo/redis"
 redis "github.com/go-redis/redis"
)

var redisOpts = &redis.Options{
 Addr: "localhost:6379",
 Password: "",
 DB: 0,
}

func BenchmarkRedisSet(b *testing.B) {
 client := redis.NewClient(redisOpts)
 defer client.Close()
 b.ResetTimer()

 for i := 0; i < b.N; i++ {
 client.Set("key"+string(i), "value", 0).Err()
 }
}

func BenchmarkRedisGet(b *testing.B) {
 client := redis.NewClient(redisOpts)
 defer client.Close()
 b.ResetTimer()

 for i := 0; i < b.N; i++ {
 client.Get("key" + string(i)).Val()
 }
}

func BenchmarkRedigoSet(b *testing.B) {
 conn, _ := redigo.Dial("tcp", "localhost:6379")
 defer conn.Close()
 b.ResetTimer()

 for i := 0; i < b.N; i++ {
 conn.Do("SET", "key"+string(i), "value")
 }
}

func BenchmarkRedigoGet(b *testing.B) {
 conn, _ := redigo.Dial("tcp", "localhost:6379")
 defer conn.Close()
 b.ResetTimer()

 for i := 0; i < b.N; i++ {
 redigo.String(conn.Do("GET", "key"+string(i)))
 }
}

func BenchmarkBoltSet(b *testing.B) {
 db, _ := bolt.Open("bolt.db", 0600, nil)
 defer db.Close()
 b.ResetTimer()

 for i := 0; i < b.N; i++ {
 db.Update(func(tx *bolt.Tx) error {
 b, _ := tx.CreateBucketIfNotExists([]byte("bucket"))
 b.Put([]byte("key"+string(i)), []byte("value"))
 return nil
 })
 }
}

func BenchmarkBoltGet(b *testing.B) {
 db, _ := bolt.Open("bolt.db", 0600, nil)
 defer db.Close()
 b.ResetTimer()

 for i := 0; i < b.N; i++ {
 db.View(func(tx *bolt.Tx) error {
 _ = string(tx.Bucket([]byte("bucket")).Get([]byte("key" + string(i))))
 return nil
 })
 }
}

二重にプロキシされたRancher Serverのリバースプロキシ設定

Mon, 04 Sep 2017 10:25:25 +0000

常時SSLの環境で二重にリバースプロキシされた環境のRancherは、公式ドキュメント通りの設定を行っても正常に動作しません。 X-Forwarded-ProtoがHTTPSの状態でRancher Serverまで届くように設定することで問題を解消できます。

Rancher-HAProxyでHSTSを設定する

Sat, 02 Sep 2017 16:49:12 +0000

HSTSはHTTP Strict Transport Securityの略で、HTTPでの接続を強制的にHTTPSへと変更するようウェブブラウザへ伝達するセキュリティ機構です。 Rancher-HAProxyでロードバランシングしている場合にもHSTSを使えるように設定してみました。

io.Writer.Write()とfmt.Fprintf()のBenchmark

Sat, 02 Sep 2017 04:30:59 +0000

tl;dr

基本的にio.Writer.Write()を使用するのが高速なようです。

result

1
2
3
4
5
6


$ go test -bench . -benchmem
BenchmarkWrite-4 30000000 48.7 ns/op 16 B/op 1 allocs/op
BenchmarkWriteWithBytes-4 500000000 3.95 ns/op 0 B/op 0 allocs/op
BenchmarkFprintf-4 20000000 91.5 ns/op 0 B/op 0 allocs/op
BenchmarkWriteTo-4 100000000 10.0 ns/op 0 B/op 0 allocs/op
BenchmarkWriteWithBufferBytes-4 300000000 4.31 ns/op 0 B/op 0 allocs/op

source

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


package main_test

import (
 "bytes"
 "fmt"
 "io"
 "net/http"
 "testing"
)

var s = "Hello, my world"
var bs = []byte(s)
var buf = bytes.Buffer{}

type NullWriter struct{}

func (w *NullWriter) Write(b []byte) (int, error) {
 return len(b), nil
}

func BenchmarkWrite(b *testing.B) {
 var w io.Writer = &NullWriter{}
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
 w.Write([]byte(s))
 }
}

func BenchmarkWriteWithBytes(b *testing.B) {
 var w io.Writer = &NullWriter{}
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
 w.Write(bs)
 }
}

func BenchmarkFprintf(b *testing.B) {
 var w io.Writer = &NullWriter{}
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
 fmt.Fprintf(w, s)
 }
}

func BenchmarkWriteTo(b *testing.B) {
 var w io.Writer = &NullWriter{}
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
 buf.WriteTo(w)
 }
}

func BenchmarkWriteWithBufferBytes(b *testing.B) {
 var w io.Writer = &NullWriter{}
 b.ResetTimer()
 for i := 0; i < b.N; i++ {
 w.Write(buf.Bytes())
 }
}

sync.WaitGroup

Fri, 01 Sep 2017 07:03:07 +0000

Goroutineを使用して複数の処理を並列で実行、すべてが終わったら次の処理に進みたいという場合があると思います。 Goroutineでデータのリストを作るという処理を考えます。データの順番は関係なく、すべてのGoroutineでのデータがそろったら次の処理をしたいという設定です。この場合、単純に考えると以下のようなコードになりますが、以下のコードではデータがそろう前に次の処理が行われます。

1
2
3
4
5
6
7


datalist := []string{}
for i := 0; i < 10; i++ {
 go func() {
 // something w/datalist
 }
}
fmt.Println("next step")

このような場合に、sync.WaitGroupを使用します。 sync.WaitGroupは基本的にはただのカウンタですが、カウンタがゼロになるまで処理を待つことができます。言葉で説明してもわかりにくいと思いますので、ソースコードを見てみましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


datalist := []string{}
wg := sync.WaitGroup{}

for i := 0; i < 10; i++ {
 wg.Add(1) // Goroutineの数だけカウンタを増やす
 go func() {
 // something w/datalist
 wg.Done() // カウンタを減らす
 }
}
wg.Wait() // カウンタが0になるまでブロックする
fmt.Println("next step")

上記の様にすることで、for文の部分ではGoroutineで並列に実行しつつ、次の処理は並列実行部分が終わってからという動作をさせることができます。

Go 1.9 is released

Mon, 28 Aug 2017 01:41:47 +0000

先日2017年8月24日にGo 1.9がリリースされました。ダウンロードページからダウンロード可能です。

最大の変更点はGo1.9rc1 is released! でもお伝えしたように、Type Alias でしょう。型名に対して別名をつけることができる機能です。

また、そのほかにも多くの変更が加えられています。リリースノートはこちらです。

以下では、いくつか変更点を見ていきます。

Ports

Go 1.9から新しく2つのOSと1つのプロセッサアーキテクチャがサポートされています。

POWER8

IBMのPOWER8プロセッサがサポートされています。 GOARCH=ppc64またはGOARCH=ppc64leで使用することができます。

FreeBSD

FreeBSD 9.3で動作します。。。が、すでにFreeBSDはサポート切れです。(なんでや・・・・) Go 1.10からはFreeBSD 10.3+で動作する様になる予定です。

OpenBSD 6.0

OpenBSD 6.0がサポートされました。かわりに、Go 1.9ではOpenBSD5.9をサポートしていません。

Parallel Compilation

パッケージの関数を並列コンパイルできるようになりました。並列コンパイルはデフォルトでONになっており、無効化するには環境変数でGO19CONCURRENTCOMPILATIONを0に設定します。

Vendor matching with ./…

これまで、./...というディレクトリ表現はvendorディレクトリも含んでいました。しかし、go testの場合などvendorディレクトリは含まれない方がうれしい場合も多く、実際glide nvなどでvendorディレクトリを含まないディレクトリマッチングが実装されていました。 go1.9からは./...にはvendorディレクトリが含まれないようになり、vendorディレクトリにマッチさせたい場合は./vendor/...と書く必要があります。

Moved GOROOT

Go 1.9から、GOROOTが移動となりました。起動されたパスから自動でGOROOTを探索します。これにより、Goのインストールパスが違う場所に移動しても、Goのツール類は継続して使える用になりました。

Compiler Toolchain

複素数の割り算がC99準拠となりました。

Doc

長い引数リストは省略されます。これはgo docで生成されるコードの可読性向上のためです。また、構造体フィールドのドキュメンテーションがサポートされました。go doc http.Client.Jarなどでどうなったのか確認することができます。

env

go env -jsonフラグによりJSON出力することができるようになりました。

Test

go testコマンドに-listフラグが追加されました。これに正規表現で引数を与えることで、テスト名・ベンチマーク名・Exampleテスト名を調べることができます。

Vet

vetコマンドがより強化されました。

docker-machineでRancherOSを使う

Thu, 24 Aug 2017 02:14:41 +0000

docker-machineとそのメリット

docker-machine は仮想マシン上にDocker Engine をインストールするツールです。 docker-machineコマンドを使用することで、Dockerホストを作成・管理することが可能です。 docker-machineを使用してDockerホストを作成すると、

1

$ docker-machine env <MACHINE_NAME>

でシェル評価可能なDocker接続情報を得ることができ、

1

$ eval $(docker-machine env <MACHINE_NAME>)

とすることにより、そのセッション内ではあたかもローカル環境のDockerの様にコンテナを操作することが可能となります。

docker-machineで使用するOS

扨、通常docker-machineでDockerホストを作成すると、インストールされるOSはBoot2Docker ですが、docker-machineでは、ホスト作成時のコマンドラインオプションでisoイメージやシェルスクリプトを指定することでOSやDocker Engineのバージョンを変更することができます。

RancherOS

Boot2Dockerに類似したOSとして、RancherOS があり、rosコマンドを使用することでインストール後でもDockerのバージョンを簡単に切り替えることができます。

RancherOSは以前、仮想マシン環境のサポートとして、Vagrant 用の環境を提供していましたが、現在(2017年8月)では、すでにサポートが終了しており、docker-machineを使用するようにというアナウンスが出ています。

そこで、今回はdocker-machineを使用してRancherOSを立ちあげてみようと思います。

docker-machineでRancherOSを立ちあげる

公式ドキュメント上に示されたコマンドをそのまま使用しても、途中でエラーが出てしまい(エラーが出ること自体は記述されていますが)、docker-machineをの大きなメリットである、docker-machine envが使用できません。

エラーを回避するためには、Rancherのリポジトリ上にあるインストールスクリプトを指定します。

1

$ docker-machine create -d virtualbox --virtualbox-boot2docker-url https://releases.rancher.com/os/latest/rancheros.iso --engine-install-url https://raw.githubusercontent.com/rancher/install-docker/master/17.06.sh

インストールが完了したら、docker-machine lsコマンドで実行中のDockerホストの一覧を表示することができます。

1
2
3


$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
ros - virtualbox Running tcp://192.168.99.100:2376 v17.06.0-ce

Docker Engineのバージョンを切り替える

せっかくRancherOSを使用しているので、Docker Engineのバージョンを切り替えてみましょう。 Docker Engineのバージョンを切り替えるにはRancherOS上でrosコマンドを使用するのでした。

Docker multi-stage builds

Thu, 17 Aug 2017 02:06:00 +0000

Docker 17.05から、新機能としてmulti-stage builds というものが導入されました。これは、コンテナイメージをより最適化するために有用な機能で、Dockerfileからコンテナイメージをビルドする際にビルド依存のライブラリ/環境とランタイム依存のライブラリ/環境を切り分けることができる機能です。

具体例を見てみましょう。 Go言語で書かれた何らかのアプリケーションをコンテナ上で動かすことを考えます。以前までであれば、以下のような二つのDockerfileを用いて作成します。

まずはビルド用Dockerfileです

1
2
3
4


FROM golang:1.7.3
WORKDIR /go/src/github.com/someone/foo/
COPY app.go .
RUN GOOS=linux go build -a -o app .

つぎに、実行用のDockerfileです。

1
2
3
4


FROM busybox:latest
WORKDIR /root/
COPY app .
CMD ["./app"]

このようにすることで、ビルド時にはGo言語のビルド環境が入ったコンテナを、実行時は(Go言語環境は不要なので)busyboxコンテナを使用することで、実行イメージを小さく抑えることができます。しかし、このように二つのDockerfileを使用する場合、コンテナイメージのビルド手順が煩雑になる、複数ファイルのため管理しにくいなどの問題がありました。

multi-stage buildsを実装されたことで、以下のようにDockerfileを一つにまとめることができます。

1
2
3
4
5
6
7
8
9


FROM golang:1.7.3 AS build
WORKDIR /go/src/github.com/someone/foo/
COPY app.go .
RUN GOOS=linux go build -a -o app .

FROM busybox:latest
WORKDIR /root/
COPY --from=build /go/src/github.com/someone/foo/app .
CMD ["./app"]

一行目のAS build、九行目の--from=buildがポイントです。

Go1.9rc1 is released!

Wed, 26 Jul 2017 01:24:00 +0000

Go1.9rc1がリリースされました！そこで、Go1.9のリリースノートをさらっと見てみようと思います。 (まだrc1なので、今後変更される場合があります。ご注意を)

全部見ていくと、結構な量になりそうなので、すぐに影響のありそうな部分だけ、軽く見ていきましょう。

type alias

Go1.9ではType Aliasというものが導入されます。これはその名の通り、型に別名をつけられるというもの。言葉で説明するより、コードを見た方が早いと思いますので、コードを用意しました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


package main

import (
 "fmt"
 "log"
)

type T1 struct {
 ID string
 Name string
}

type T2 = T1

func main() {
 t := T1{
 ID: "id",
 Name: "Taro",
 }
 log.Println("call t1.Call()")
 fmt.Println(t.Call())

 log.Println("call t2.Call2()")
 fmt.Println(t.Call2())

 return 0
}

func (t *T1) Call() string {
 return "hello, " + t.Name
}

func (t *T2) Call2() string {
 return "hi, " + t.ID
}

go1.8以前ではsyntax errorになるこのコードですが、go1.9では正常に動作し、以下のような出力をします。

Riot.jsにSass(SCSS)を導入する

Wed, 19 Jul 2017 01:15:00 +0000

Riot.jsでは、標準でスタイルシートにLessを使用することができます。その際の使用方法は簡単で、スタイルタグにtypeを指定するだけです。

1
2
3


<style type="less">
 ...
</style>

扨、ここで、イマドキな皆さんはLessじゃなくてSass(SCSS)を使いたい！と思うかもしれません(思いますよね？) なので、Sassを使えるようにしてみましょう。

基本方針

基本的には、riot.parser.css.sassにSassのコンパイラ関数を作成するだけです。 riot.parser.css.sassには、引数として、

タグ名
stylesheet が渡されます。この、第二引数をコンパイルして返す関数を作成すれば良いのです。

ランタイムコンパイルでSass(SCSS)を使用する

ランタイムコンパイル時はsass.jsを使用します。 <head>タグ内で、https://cdn.rawgit.com/medialize/sass.js/v0.6.3/dist/sass.jsを読み込むなどすれば良いでしょう。その上で、タグのマウント前に以下の記述を追加します。

1
2
3
4


riot.parsers.css.sass = function(tagName, stylesheet) {
 var result = Sass.compile(stylesheet);
 return result;
};

gulp-riotプリコンパイルでSass(SCSS)を使用する

glup-riotでプリコンパイルする際にSassを使用するには、node-sassを使用して、gulpfile.jsに以下のように記述します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


var gulp = require('gulp');
var riot = require('gulp-riot');
var sass = require('node-sass');

gulp.task('riot', function() {
 gulp
 .src('app.tag')
 .pipe(riot({
 parsers: {
 css: {
 sass: function(tagName, stylesheet) {
 var result = sass.renderSync({
 data: stylesheet
 });
 return result.css.toString();
 },
 },
 },
 }))
 .pipe(gulp.dest('./'))
 ;
});

Vagrantで起動したVMからBOXを作る

Tue, 11 Jul 2017 02:39:00 +0000

Vagrantで、centos/7等の標準的なBOXをベースにカスタムしたVMを保存しておいたり、配布したりするためにBOXを作る手順です。自分用のメモとして。

VM内での操作

VBoxGuestAdditionsを導入する。

以下のソースを適当なファイルに保存する。(ここでは$HOME/ins.shとします。) このとき、二行目はVirtualboxのバージョンに合わせて適宜書き換える。リストはこちら

1
2
3
4
5
6
7
8


yum install -y wget kernel kernel-devel perl gcc
wget http://download.virtualbox.org/virtualbox/5.1.18/VBoxGuestAdditions_5.1.18.iso
mkdir /media/VBoxGuestAdditions
mount -o loop,ro VBoxGuestAdditions_5.1.18.iso /media/VBoxGuestAdditions
sh /media/VBoxGuestAdditions/VBoxLinuxAdditions.run
rm VBoxGuestAdditions_5.1.18.iso
umount /media/VBoxGuestAdditions
rmdir /media/VBoxGuestAdditions

保存したスクリプトを管理者権限で実行します。

1

sudo bash ins.sh

yumをきれいにする

軽量化のため、yumをきれいにします。

1

sudo yum clean all

ゼロ埋めして消す

圧縮効率向上のため、ゼロ埋めして消します。

1
2


sudo dd if=/dev/zero of=/EMPTY bs=1M
sudo rm /EMPTY

ホストからの操作

BOXを作成する

1

vagrant package

** box listに登録する

YAPC::Fukuoka 2017 HAKATAに行ってきました

Mon, 03 Jul 2017 02:04:00 +0000

今回は言われました！「ブログを書くまでがYAPC!」と言うことで、YAPC::Kansai 2017 OSAKA (行ってきたときの記事はこちら )に引き続き、YAPC::Fukuoka 2017 HAKATA に行ってきました。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。

福岡および九州は初めてでしたが、いや、暑いですね。特にYAPCの翌日は非常に天気が良いものの、梅雨の湿気もあり、観光をしていて汗だくでした。

今回も大阪同様ホテルはとらず、適当にやっていくことに。意外となんとかなるものです。

YAPC::Fukuoka 2017 HAKATA

今回も例に漏れず(?)寝坊でオープニングには間に合わず。今回はPerl6の話は余り多くなかった印象です。

セキュリティの話、コンテナの話、テストの話など、非常に多様なセッションがありました。

今回のノベルティはなぜかモバイルバッテリーが二つも入っていたり、米が入っていたり、染み抜きペンが入っていたりととても面白い内容でした。あ、いつものサイリュームも入ってましたよ。

個人スポンサーノベルティはビーチサンダル。これからの季節に良いですね。

LTをしてきました。

今回はLTもしてきました。タイトルは「嗚呼素晴らしきemacs 」です。

ベストトーク賞

YAPCでは恒例のベストトーク賞ですが、今回は徳丸さんのゲストセッションがベストトーク賞に選ばれました。しかしご多忙な徳丸さん。クロージングの時点ですでに帰還してしまってました。仕方ないので徳丸さんの会社にお勤めの方が代理で受け取ることに。なんと賞品を渡す人は徳丸さんのセッションを聞いていなかったようで・・・ベストトークを聞いていなかった人が代理の人に賞品を渡すという、なんとも面白い事態でした。

ベストLT賞は@codehex さんで、YAPC::Okinawaの宣伝でした。

懇親会

懇親会ではPixivさんから抽選でプレゼントをいただきました。 Pawooのロゴ入りのモバイルバッテリー(これで今回三つ目)です。

次回のお話

次回YAPCは3月に沖縄で開催予定です。

Fujitsu FACOM128Bを見てきた

Tue, 06 Jun 2017 01:45:00 +0000

Open Source Summit Fujitsu Museum Tour )で、富士通沼津工場まで行って、現在動作する世界最古のコンピュータであるリレーコンピュータ「FACOM128B」を見てきました。

Fujitsu FACOM128B は1958年に作られたリレー式自動計算機で、富士通沼津工場に置かれているものは1959年製です。Fujitsu Webサイトから申し込みをすることで、中学生以上なら見学することができます。

圧巻です。エンジニアなら一度は見ておくと、感動ものです。

emacs-macでtwittering-modeを使った際に毎回PINを聞かれる問題の解消

Tue, 09 May 2017 00:49:00 +0000

twitterのクライアントとして、日頃からemacs上で動くクライアントの"twittering-mode"を使用しています。ところが最近、新しいmacにインストールしたemacs-macでtwittering-modeを起動すると、毎回twitterのPINを聞かれるようになってしまいました。毎回、毎回、起動時の暗号化フェーズで

Encrypt failed Exit

と言われ・・・・以前使っていたmacではこのようなことが無かったため、困っていたのですが、以下の手順により解決できました。

背景

結論から言うと、これはGnuPGのバージョンが新しくなったことによる問題でした。 GnuPG2.1.0から、gpg-agentとpinentryと呼ばれる二つのソフトウェアの利用が必須となりました。 twittering-mode事態はgpg-agentやpinentryが必須でも基本的に問題なく動作するようにはなっているハズ・・・でした。しかし、これらのソフトウェアの必須化に伴って、これまで標準入力から入力できていたパスフレーズが標準入力から入力できなくなっており、そのために暗号化に失敗して毎回PINを聞く・・・という状態になっていたようです。

解決策

みんな大好きarch wiki に解決策がありました。まず、~/.gnupg/gpg-agent.confに以下のように記述します。

allow-loopback-pinentry

つぎに、~/.gnupg/gpg.confに以下のように記述します。

pinentry-mode loopback

最後に、gpg-agentを再起動します。コマンドラインから、

1

$ gpgconf --kill gpg-agent

でgpg-agentを再起動できます。

以上で、twittering-modeが正常に使用できるようになるはずです。

MySQL on docker macな開発環境でローカルからMySQLに接続する

Tue, 02 May 2017 06:57:00 +0000

MySQLをdocker上に立てることで、ローカルの環境を汚さずにMySQLを使ったアプリケーションの開発を行うことができます。特に、練習段階や、動作確認などの場合、 test_hogehoge な感じのデータベースやテーブルを作ってしまい、後片付けをしないために汚くなっていく、なんてこと、あるんじゃないでしょうか。

さて、MySQL on dockerへの接続、今までローカルにMySQLを入れて開発していたのでちょっと躓きました。

1

$ docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD password mysql:latest

上記のように起動した場合、次のようにコマンドを実行することで接続することができます。

1

$ mysql -u hoge -p -h 127.0.0.1 --port 3306

特にポイントなのが、-h 127.0.0.1の部分。localhostにしてしまうと、socketで接続しようとして、エラーになっちゃうんですね。ここでしばらく悩みました。。。

以上、簡単ですがメモがてら。

golang: net/httpでBASIC認証

Tue, 02 May 2017 05:06:00 +0000

golangでベーシック認証するのはどうしたら良いのかなー。って思ってたら、net/httpでhandlerに渡されるhttp.RequestにBasicAuth()というメソッドが生えてました。これはBASIC認証用のユーザ名、パスワード、ヘッダ解析のフラグという値を返してくれます。なので、

1
2
3
4
5
6
7
8
9


func handler(w http.ResponseWriter, r *http.Request) {
 username, password, ok := r.BasicAuth()
 if !ok {
 return
 }
 if username == "hogehogeuser" && password == "fugafugapasswd" {
 // something
 }
}

とすることで認証することができます。簡単、簡単。なお残念ながらダイジェスト認証はサポートされていない様子。

YAPC::Kansai 2017 OSAKAに行ってきました

Sun, 05 Mar 2017 04:12:00 +0000

12月のYAPC::Hokkaido 2016 SAPPORO (行ってきた時の記事はこちら )に引き続き、YAPC::Kansai 2017 OSAKA に行ってきました。

今回もブログを書くまでがYAPCとは言われなかった気がします。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。

私にとって、大阪はもちろん、関西自体が初めてで、かなり余裕のあるスケジュールを組んだために、どう時間を過ごしていいか悩むといった自体に。空港に降り立ち、まずどうしよう、という状態ですね。困った。

仕方がないので大阪出身の友人に、「大阪観光ってどこいったらいいのかな」と聞いてみたのですが、「まぁたこ焼き食べたりしたら？」と今ひとつ役に立たない返事。まぁ食べますけど！それでも心斎橋とか難波に向かうとよいと教えてもらえたので、Googleマップ先生に頼りつつ、難波へ向かいました。

結果、何をしたかというと、札幌からの移動前に新しく購入したスマホ用のあれこれをビックカメラで購入するという、大阪まできて何をやっているのかというなんとも残念な行動となってしまいました。

ホテル探し

今回、北海道から関西まで、勿論飛行機で移動したわけですが、実はホテルも取らずに(!)、YAPC以外は無計画での旅行でした。とりあえずYAPC前日くらいはホテルに泊まらねば朝起きれない！ということで、ホテル探しをしました。運良く会場(MOTEX ホール )の近くに割と安く宿を取ることができました。

こちらがそのお部屋の写真。シングルの部屋を5,500円(500ポイント適用後)でとったのですが、入ってみてびっくり、ツインの部屋でした。安かったものの、なんとなく豪勢な感じ。

夜ご飯は近くのお店でたこ焼きを食べました。十八番というお店で、後で調べたら結構有名っぽいですね。美味しかった。たこ焼きを塩で食べるというのは初体験でしたが、これもなかなかです。

YAPC::Kansai 2017 OSAKA

開けて翌日。微妙に寝坊したおかげでオープニングには間に合いませんでした。

一番印象に残ったトークは「Vue.jsで作るSPAから学ぶMVVM、非同期処理、その光と影」ですね。タイトルにVue.jsと入っているにもかかわらず、Vue.jsという言葉が出て来たのは一度きり、SPAの話のはずなのに、「SPAはやめよう」と、なんだかタイトルに釣られた感が半端ない内容でした。勿論内容も素晴らしく、「ブラウザはドキュメントビューアなんだからリッチなインターフェースを作るものではない」「ブラウザでリッチなインターフェースを作るのはなんでもVimでなんとかしようとするようなもの」「とはいっても作らなきゃいけない時もある」という、SPAはやるべきじゃないけど、現状やらなきゃいけないことはどうすれば良いのか、その時MV*はどのように構成したらいいのかといった、きちんと筋が通っていて、とても面白い話でした。

次に印象に残っているのが、「Webアプリケーションのキャッシュ戦略とそのパターン」です。こちらも「キャッシュは使わないほうがいい」という、タイトル詐欺みたいな話でしたが、非常に納得のいく内容でした。

ベストトーク賞の投票で票を入れたのは「Webエンジニアに知ってほしいRDBアンチパターン」です。内容もさることながら、やはり喋りが素晴らしいんです。とっても練習をしていると聞いています。

ランチタイムはスポンサー企業の方と昼食をいただきました。今回交通費支援をいただいたので、その対価のようなものです。実際には、企業に関わるお話は結局あまりしなかったのですが、会場の近くはあまり飲食店がない印象で、昼食を取るのも大変そうでしたので、大変助かりました。

YAPC::Kansai 2017 OSAKAのステッカーはこんな感じ。札幌の時のものと並べてはるには、上下を揃えるのが難しい形状で、ちょっと難儀します。

次回のお話

次回YAPCは福岡で開催だそうです。YAPC::Fukuoka 2017 HAKATA すでにチケットも発売されています。

その後は沖縄、東京が企画されているそうです。是非回りたい。

InfluxDBを触ってみた

Sat, 18 Feb 2017 09:45:00 +0000

NoSQLを使うことも一般的になってきた昨今ですが、NoSQLの一種に、時系列データベース (Time Series Database; TSDB)と呼ばれるものが有ります。 TSDBはその名のとおり、時系列データを取り扱うことに特化したDBです。サーバ監視したログデータや、センサデータなんかを取り扱うことが得意なDBということですね。

そのうち、DB-ENGINES のDB-Engines Ranking of Time Series DBMS で一位を取っているInfluxDBを触ってみました。

InfluxDBの公式ドキュメントはInfluxData | Documentation | InfluxDB Version 1.2 Documentation にあります。

参考にした資料・実行環境

今回はQiita/DockerのInfluxDBとGrafanaでdweet.ioのデータを可視化するの前半を参考に、Docker上でInfluxDBを実行してみました。なお、上記の記事中では、~~tutum/influxdb~~というイメージを使用していますが、現在はInfluxDBオフィシャルのイメージが提供されていますので、そちらを利用します。最新の安定版を利用しますので、InfluxDBのバージョンは1.2.0です。

InfluxDBコンテナを起動する

早速InfluxDBコンテナを起動してみます。

1
2


$ docker pull influxdb
$ docker run --name influxdb_test -p 8083:8083 -p 8086:8086 influxdb

これだけです。簡単ですね。Exposeしているポートの中身は以下のようになっています。

8083: Admin Web インターフェース
8086: HTTP API

Admin UIにアクセスする

Admin UIにアクセスしてみます。 InfluxDBにはWebアクセスできるUIがついています。

まずはコンテナのIPを調べてみましょう。

1

$ docker inspect influxdb_test

HostConfig > NetworkSettings > Networks > bridge > IPAddress にコンテナのIPが記載されています。今回は172.17.0.2だったとして進めます。

Python 3でbottle-websocketを使う

Tue, 10 Jan 2017 17:05:00 +0000

Python 3でbottle-websocket がそのままでは動かなかったので簡単にメモしておきます。

解決方法

通常通りpip install bottle-websocketしてから、 pip install karellen-geventwsすると動作するようになります。 karellen-geventwsはGeventWebSocketのforkで、Python 3に対応しています。

学生が勉強会/コミュニティを運営するということ

Sat, 17 Dec 2016 06:37:00 +0000

この記事はIT勉強会/コミュニティ運営 Advent Calendar 2016 に寄せて書いた記事です。執筆者は@nasa9084 です。前日の記事は一般社団法人LOCALさんの一般社団法人LOCAL のご紹介でした。

まずはじめに

あまりネット上、特にブログで自己紹介をする機会というのは多くなく、このブログ単体で言うならば、とある理由があって以前書いていたブログから移行してきたばかりなので、自己紹介というものをすこしはしているのですが、折角の機会でもあるので、ある程度きちんと自己紹介から始めさせていただくこととします。どうもこんにちはnasa9084 といいます。現在試される大地であるところの北海道は札幌市に住んでいる大学生(0x17歳)です。来春4月から、東京で就職予定ですが、卒業論文の進捗が芳しくありません。 PyCon JP というカンファレンスのスタッフをしたりしています。

「でじぽろ」という勉強会

昨年のから今年の10月まで、札幌ででじぽろ という勉強会を主催していました。でじぽろはIT技術初心者、もう少し具体的に言うと

UNIX/Linuxに興味がある/使ったことがある
プログラミングに興味がある/すこしやったことがある

といったレベルの方を対象として月に一回開催していた勉強会です。

私と、@chamaharun の二人で主催をしていて、内容としては

HTTP入門
SQL入門
プログラミング言語大横断
Linuxディストリビューションの紹介

なんかをやったりしていました。

勉強会を開催するということ

扨、少しばかり前置きが長くなってしまいましたが、そろそろ本題であるところの運営に関する部分の話をしなきゃいけないですね。今回はIT勉強会/コミュニティ運営 Advent Calendar ですから、多くの大事なところは他の大人な方々が書いてくれてますので、今日は私が特に気をつけたほうがいいと思っていることだったり、おすすめの方法論だったりについて書きましょう。

持ち出しはしない

勉強会を継続的に運営するにあたり、主催者やスタッフの財布からお金が出ていくことは避けたほうがよいと思います。楽しいことがしたいと思って始める(であろう)勉強会ですが、事前準備や当日の運営、終わったあとの処理など、結構な時間や労力がかかります。これは大きな負担で、この上開催にお金がかかるとなると、金額が大したことない額だったとしても、継続するのは心理的に困難になるでしょう。せっかく立ち上がった勉強会も、「主催のお金がないので継続開催できません」では悲しいものがあります。初回開催など、立て替える必要がある場面はあると思いますが、開催後にでも精算を行って、主催者・スタッフのマイナスが無いようにしたほうがよいです。

自分に強制する、という選択肢

多くのコミュニティ運営者は、「勉強会やコミュニティの運営は仕事ではないので、開催しなければならないという意識を持って開催するのはつらいからやめたほうがいい」と言っている様に思います。わたしも多くの部分で賛成ですが、個人の性格だったり、勉強会の目的次第では、「強制的に開催する」という選択肢もある、と覚えておいてください。

私が主催していたでじぽろの目的の一つに、「主催も勉強する」というものがあります。初心者向けなんて謳っているけれど、主催も学生だから、一緒に勉強していきましょう！ということです。加えて、主催である私も、@chamaharun も、比較的怠惰な性格をしています。そこで、でじぽろ運営にあたって、一つルールを決めました。それが、「つらくても、話すネタがなくても、とにかく月に一回開催する」というルールです。

不定期開催というのは、心理的負担も減りますが、それと同時に、気づいたら二回目の開催がないまま時間だけが過ぎていた、なんてことになりやすい開催方式でもあります。定期的に開催することを自分に義務付けることで、勉強会を開催することが習慣になります。継続開催を目標の一つとする場合、この選択は大きな助けともなってくれることと思います。 でじぽろは、このルールのおかげで、一年間毎月開催することができたと思っています。

あまり深く考えない

勉強会を主催するということは、実はそれほどハードルの高いことではありません。「とりあえず気が向いたからはじめてみた」くらいの気持ちで十分です。でじぽろも、はじめは友人との呑みの席で、「なんか勉強会とかやってみたいよね」で始まったのでした。皆言ってることでは有りますが、仕事ではないのです。辛かったり、つまらなかったらやめていいんです。そして、気が向いたらまた新しく始めてみたらいいと思いますよ。

懇親会をする

個人的にこれはとても重要なことだと思っているのですが、懇親会はぜひやったほうがいいと思います。4日のエンジニアコミュニティのつくりかたでも書かれていましたが、懇親会が本編だと考えています。多くの場合、勉強会で発表されることは、今の御時世ですから、検索したら出てきます。わざわざオフラインで集まってスクリーンの前で発表なんて聞かなくてもいいんです。それでもやっぱり勉強会/コミュニティに集まるというのは、人と人との出会いが重要だからだと思います。そして、発表のときというのは、座っているうち8割9割の人は質問もしないですし、発表後に発表者に挨拶に行ったりもしません。これでは、休みの日に、わざわざ集まっている意味は無いと思います。

懇親会を開催することで、大勢の前の発表では言えないことだったり、発表するほどでは無いけど趣味で触っている新技術の話だったり、そういったものに大きな意味が有ります。twitterやfacebookでつながりを持つことに意味があるんです。

「学生が」勉強会を運営するということ

扨、それなりの量を書いた(気になっている)のですが、他の記事を書いている方々は皆さん大人(学生ではない)の方々ですね。ココで一つ、「学生が勉強会を運営すること」のメリットを考えてみます。

pyorgというパッケージを作りました

Mon, 12 Dec 2016 17:19:00 +0000

この記事はEmacs Advent Calendar 2016 の、13日目の記事で、執筆者は @nasa9084 です。前日はfujimisakariさんのプログラミングに役立つelisp10選でした。

org記法でブログを書きたい

全国のEmacsユーザの皆さん、org-modeは使っていますか？私は使っています。普段Pythonを書く私にとって、#はコメントアウトのイメージで、#を見出しに使うmarkdownは(ダメってほどじゃないですけど)なんとなく好きになれません。Emacsユーザということもあり、細かいメモを取るときや、スライドを作るときはorg-modeを使っています。

そんなわけで、慣れ親しんだorg記法。ブログを書くときも使いたいと考えました。しかし、マークダウンで書くことができるブログや、或いはorgで書いたものをwordpressにアップすることができるelispなんかも有りましたが、どうもしっくり来ません。そんな折に運用していたWordPressが使えなくなり、このブログシステムを作りました。 Pythonで使えるorg記法パーサも探したのですが、どれもブログで使えるようなものではなく、自分で変換機構も作成することにしました。最初はブログシステムの中にorgをHTMLに変換するフィルターを作ればいいかな、と思って書き出したのですが、コレがなかなかうまく行かず。最終的にパーサとしてパッケージ化したので、そのお話をさせていただこうと思います。

正規表現の置換だけで実装してみた

org記法を使いたいとは言っても、ブログ記事を書くのに使いたいだけなので、チェックボックスや時間に関する部分など、org-modeの大部分は必要ありません。文字の装飾部や見出し、リストが実装されれば十分です。ですので、最初はわざわざ構文木などを作らずとも、単純に正規表現で置換すればいいのではと考えて実装を始めました。しかしコレが大きな間違いだったのです。

問題の１つめは、ネストしたリストを使えないことでした。単純に正規表現で行ごとに置換していく都合上、ネストしたリストを解析することができません。この段階で、ネストしたリストは使わないことにしよう、と考えました。しかし、実際に実装してみてわかったのですが(気づくのが遅い)、問題はそれだけではありませんでした。リストが始まったことや終わったことを判断できないのです。いま置換している行はリストの始めなのか(つまり<ul>が必要なのか)、真ん中なのか、終わりなのか、判断することができないのです。これは困りました。

スラッシュ

更に大きな問題が潜んでいました。斜体とリンクです。ご存知のように、URLは区切り文字としてスラッシュを多用します。また、org-modeでは斜体をスラッシュで挟んだ形で表します。このせいで、URLの一部が斜体としてマークアップされてしまう事態が発生しました。これはちょっと困ったものです。とりあえず斜体を使わないこととしましたが、これには不満が残ります。

結局パーサとしてパッケージ化

更に、テーブルの実装ができないなど、org記法が使える！というには不満点が多すぎました。そんなわけで、改めて外部モジュールとして、org記法のパーサを書きました。org記法で書かれたテキストを読み込み、解析し、抽象構文木を生成します。そこからHTMLを出力することも可能です。GitHub上でソースも公開しています(nasa9084/py-org )。コレをブログシステムに組み込むことでorgでブログを書くことができるという寸法です。また、当初予定してはいなかったのですが、gitのsubmoduleで管理するのはバージョンアップの際などいろいろと面倒なので、パッケージ化してPyPIへとアップしました(pyorg )。現在はバージョン0.1.3として、見出し、リスト、テーブル、リンク、画像、引用、文字の強調を実装済みです。今後、少しずつ拡張予定ですが、当面はリファクタリングを進めようと思っています。

以上、pyorgのお話でした。

YAPC::Hokkaido 2016 SAPPOROに行ってきました

Fri, 09 Dec 2016 16:34:00 +0000

ブログを書くまでがYAPC!とは言われなかった気がしますが書きます。

昨年で終了したYAPC::Asia Tokyoから一年、新生YAPCとして開催されたYAPC::Hokkaido 2016 SAPPORO に参加しました。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは#yapcjapan でした。

当日の札幌はすごい雪で、東京発の飛行機が飛ばないという事態が発生、登壇者もなかなか札幌まで到達できず、スタッフさん達はなかなか大変な一日だったのではないかな、という印象です。

スペシャルセッションである対談セッションは、Amazon Web Service、Google、Microsoft、さくらインターネットというクラウド大手4社が集って対談を行うという、非常に豪華な一時間でした。基調講演はrebuild.fmのmiyagawaさんで、CDNのお話という、これまた普段はなかなか聞くことができない内容でした。そのほか、emacs界隈で有名なsyohexさん、あちこちの界隈で有名な小飼弾さんなどなど、、、なかなかに濃い内容でした。

今回は複数抽選が有り、Azure本(Azureテクノロジ入門 )とLINEビーコンが贈呈されました。私も運良くAzure本に当選し、頂くことができました。ありがたい・・・

当日チケットは1,000円なのに、前夜祭、懇親会がそれぞれ3,500円という、不思議なチケット価格が少しおもしろかったように思います。次回YAPCは2017年3月4日に大阪で、YAPC::Kansaiとして開催される予定です。

Pythonとわたし

Mon, 05 Dec 2016 08:13:00 +0000

この記事は、PyCon JP Advent Calendar 5日目へ寄せて書いた記事です。執筆は@nasa9084 です。昨日は寺田さんによる、PyCon JPの立ち上げという記事でした。

Pythonと私の想い出

PyCon JPアドベントカレンダーのテーマは「Pythonと私の想い出」だそうです。私が初めてまぁそれなりと言える程度にかけるようになったプログラミング言語がPythonでした。なんどもCに挑戦しては挫折し、を繰り返していたのですが、Pythonのおかげで簡単なプログラムはかけるようになったんでした。

扨、すでに行き先がよくわからなくなってきているこの記事ですが、もう少し私とPythonとの関わりを書いていきましょうかね。

Pythonを使う理由

もともと、私はHTMLから、ソースコードというものをエディタで書く、という世界に入ってきたんです。小学校高学年くらいの頃だったでしょうか。最初はホームページビルダーでWebサイトを書いていたんですが、当時(今でもあるのかな？)、小学生でも使えるJavaScript集みたいなサイトがありまして、例えば、headタグの直後にコピペするとなんかカーソルにきらきらしたのがくっついてくるようになる、とかですね、今となってはとっても懐かしい感じのものがたくさんあったわけですよ。そんなのをコピペするために、ホームページビルダーでソースコードビュー的なものを開きまして、コピペをしていたわけですね。 HTMLなんてまだまだ書けなかった私ですが、なんとなくルールがわかるんですね。そうすると、なんだか無駄っぽいのがあるわけですよ。そういうのを、ちょこちょこと手作業で消していってみるわけです。今思うと、リファクタリングのはしりみたいなもんです。これが私のソースコードを編集することの原点だったんです。

ときは流れまして、Pythonという言語に出会います。聞くところによると、この言語、インデントをきちんとしないと動作しないそうじゃないですか。だれが書いてもそれなりに読みやすいコードになると。もともとソースコードを綺麗にするのが楽しくてソースコードを触り始めた私ですから、これはとても気に入りました。そうして私はPythonの世界にずぶずぶと浸かっていくのでありました・・・

GitHub Repository

現在、私のGitHubリポジトリ(https://github.com/nasa9084 )の数は、ちょうど20だそうです。自分が主となって開発しているものの、意味づけという理由があったりしてOrganizationを切り分けているものもありますから、20以上30未満、といったところでしょうか。このうち、主にPythonで書いているリポジトリは10個程度で、半分には届かないものの、かなりの割合を占めています。

PyCon JP 2016

2016年はPyCon JP 2016のスタッフをしました。PyCon JPは東京開催で、もちろんスタッフの多くは東京(または東京近郊)在住で、オフラインミーティングや作業日の開催地も東京です。一応、都合のつく限りリモートでも参加をするんですが、これがなかなか難しいのです。解決方法はまだわからないのですが、来年は東京で就職なので、遠方のスタッフがもっと溶け込みやすいようになにか頑張りたいと思っています。

Eureka

実は、このブログのシステムもPythonで書かれています。構成としては、プログラム部がbottle + beaker + jinja2、アプリケーションサーバがuWSGI、HTTPサーバがnginxという構成です。現状、JavaScriptは一切使っていないため、(特に管理画面において)残念な仕様の部分が多いです。なんとかしたい。ブログ移転で違うシステムになりました。

まとめ的な

そろそろ長くなってきましたし、もうなんの話かわからなくなってきましたので、この辺で終わりにしようと思います。とりあえずですね。何が言いたいかというと、Pythonはいいぞということです。ぜひPyCon JP 2017にもお越しください。

builderscon tokyo 2016 を開催しました！

Mon, 05 Dec 2016 04:34:00 +0000

過ぎし2016年12月3日、builderscon tokyo 2016を開催しました。 builderscon tokyo 2016には(一応)コアスタッフとして、初期のウェブサイト制作等を行いました。 blogを書くまでがbuilderscon!ということなのでブログを書きましょう。

いやね、builderscon スタッフの皆さんすごい人が揃いすぎてて、私のような若造がリモート参加だと、ちょっとしたすきに話が進んじゃってて。なかなか大変です。ただ、そんなすごい人たちが色々と決めたり準備を進めたりするのを見るのはすごく勉強になりました。

当日のトークは、php.iniの話だったり、ビールサーバーの話だったり、キーボードをつくる話だったり、ほんとなんか、尖った話が沢山でした。

トークもね、一応応募したんですが、当然の如く落選しました。コレは仕方ないですよ。私もトーク採用フローに参加しましたけど、他のトークのほうが聞きたかったですもん。

次はbuilderscon tokyo 2017の開催が決まっています!今度は1000人規模ですよ！ builderscon tokyo 2017

興味のある人はとりあえずSlackに入ってみるといいですよ。 builderscon slack invite form

something tech.

梅仕事2026

2025年買って良かったもの

園芸

道具・資材

植物

斑入りバオバブ

アングレカムディスティカム

ドリナリア リギデュラ

アスパラガス プルモーサス ナナス

カンパニュラ ダークゲットミー

ネメシア グッピー

カーネーション ピンクアンドプラウド

サニーレタス(のタネ)

モンステラ デリシオーサ ‘タウエリー’(のタネ)

串鳥

串鳥

コラボグッズ

締めの一句

Tech Rock Festival 2025.11.22

機材

バンドと演目

次

YAPC::Fukuoka 2025

前日

Day 1

Day 2

水の配達でゴタゴタした件

Context

Timeline

2025.10.28

2025.10.30 20時前

2025.11.06

苗字が変わりました

経緯

手続き

その他変更の手続き

"怠惰な人のための"キッシュ

KubeCon Japan 2025

Doc Sprint

KubeCon本祭

梅仕事2025

チカの南蛮漬け

ベトナムに行ってきた

0日目: 札幌→東京→ホーチミン

1日目: ホーチミン

Kubernetes Upstream Training in Japan at CNDW2024

植物用のライトスタンドを作る

札幌に引っ越した件

YAPC::Hakodate 2024

前夜祭

本祭

懇親会

Tech Rock Festival 2024.09

機材

builderscon 2024

大吉祥寺.pm

OSC 2024 Hokkaido

Expression Knob

梅仕事2024

git-gutter to diff-hl

Kubernetes Upstream Training Japan 2024-03

情報認識学研究室 工藤先生の最終講義に行ってきました

PNGの仕様を眺める

Introduce Tree Sitter to Emacs

Emacs x Tree-sitterの仕組みと導入

使用したい言語のパーサーが実装されている

Tree-sitterに対応したmajor modeが実装されている

YAPC::Hiroshima 2024

前夜祭

本編

懇親会

二次会

YAYAPC::Hiroshima

Tall Titlebar Issue on macOS Sonoma

THEO解約レポート

LINE証券解約レポート

ワイヤレス送信機用延長シールドを作る

材料

工具

ドリナリアリギデュラ

アスパラガスプルモーサスナナス

カンパニュラダークゲットミー

ネメシアグッピー

カーネーションピンクアンドプラウド

モンステラデリシオーサ ‘タウエリー’(のタネ)

情報認識学研究室工藤先生の最終講義に行ってきました