5/10にLaunchable を導入する手順を紹介するウェビナーやります!

Launchable を導入する手順をデモを交えて紹介するウェビナーやります!
今回は僕がやるのですが、どちらかというと概念の話より、実際のコマンドや導入の手順などを重点的に説明しようと思っています。(まだ資料作り中なので) RailsRSpecを利用して説明しますが、コマンドの使い方などは他のテスティングフレームワークやビルドツールでも同じように使用できるのでRailsRSpecを使っていなくても参考になると思います!
もちろん新しく追加された機能の紹介などもしますので、過去のウェビナーに参加していただいている方にも新しい発見を提供できるのではないかなと思っています。

ということでぜひ見に来てください!!!!

zoom.us

AirPodsをMacに強制的に接続する

AirPods Proの自動切り替え機能、MacからiPhoneへの切り替えは便利なんだけど、逆はうまく行かないことが多い。というかMacに繋げてたはずなのにちょっとiPhone弄った時に切り替わってていざミーティングしようと思ったらMacに繋がってなかったりとかして焦る。

で、この前 Rebuild.fm 聞いてたら id:miyagawa が「Alfredで接続後に音を鳴らすようにしてる」って言っててそれだ!!って思ったので真似てみた。いやマジでこの最後に音を鳴らすというのがメッチャ頭良いというかナイスハックで自分の耳で繋がってることが確認できるので素晴らしい!!

 やること

  1. bluetoothAirPodsに接続
    1. トグルとかにすると逆にわかりにくいので接続のみ
  2. MacサウンドAirPodsにする
    1. たまに繋がってるのに音が聞こえないことがあるのは別のスピーカとかになってる
  3. 音を鳴らす
    1. 自分の耳で準備が出来たことを確認できるので確実

という感じのことをします。

Install BluetoothConnector

Install BluetoothConnector .

コマンドラインからBluetooth接続弄れるやつを入れる

$ brew install bluetoothconnector

AirPodsMAC addressを調べる

これ簡単でさっきインストールしたbluetoothconnectorを引数無しで実行すると一覧が表示される

$ bluetoothconnector
Error:
MAC Address missing. Get the MAC address from the list below (if your device is missing, pair it with your computer first):
f6-ad-d5-d0-c2-d1 - MX Ergo
fc-66-cf-6a-52-d1 - iPhone
4c-ef-c0-a6-52-b1 - Echo-FHW
34-df-2a-4a-a2-41 - AKG Y50BT
3c-bf-60-6c-62-32 - iPad
f0-5c-d5-e5-d2-42 - Yoshiori’s AirPods Pro

Usage: BluetoothConnector [--connect] [--disconnect] [--status] [--notify] [<MAC address>]
  See 'BluetoothConnector --help' for more information.

例えば俺のAirPodsMAC addressは f0-5c-d5-e5-d2-42

Install SwitchAudioSource

Install SwitchAudioSource .

コマンドラインからMacのオーディオ設定弄れるやつを入れる

$ brew install switchaudio-osx

AirPodsの名前を調べる

さっきの一覧にも出てたんだけど一応 SwitchAudioSourceコマンドでも確認してみる

$  SwitchAudioSource -a -t output 
DELL U2720Q
ATR2100x-USB Microphone
MacBook Proのスピーカー
Yoshiori’s AirPods Pro

シェルスクリプト用意

#!/bin/bash
AIR_PODS_ADDRESS=f0-5c-d5-e5-d2-42 # Your AirPods MAC address
AIR_PODS_NAME="Yoshiori’s AirPods Pro" # Your AirPods name

/usr/local/bin/bluetoothconnector -c $AIR_PODS_ADDRESS
for ((i=0 ; i<10 ; i++))
do
    if [ "Connected" == $(/usr/local/bin/bluetoothconnector  -s $AIR_PODS_ADDRESS) ]; then
        sleep 1
        /usr/local/Cellar/switchaudio-osx/1.1.0/SwitchAudioSource -s  $AIR_PODS_NAME
        sleep 1
        say -v samantha Connected
        break
    fi
    sleep 1
done

AIR_PODS_ADDRESSAIR_PODS_NAMEを自分のに書き換えて実行すると強制的に実行したMacに接続するようになる。

Alfredに登録

f:id:Yoshiori:20210413171228p:plain

最高便利! ちなみにオリジナルはafplanyで音を鳴らしてる。(最初sayに違和感あったんだけどsamanthaに喋らせるようにしたらそれで良くなっちゃった。)

SwitchBot の DeviceID は Bluetooth アドレスと一緒

そのものズバリな記事がなかったので書いておくとタイトル通りです。

github.com

とかを使おうとすると

You must set your Bot's Device ID in the Press Mode or Switch Mode Bot Settings (Advanced Settings > Bot Settings)

 と書いてあって、Device ID が必須だぜ!! Advanced Settings > Bot Settings から設定できるから設定しような!と書いてあるんだけど Device ID の求め方は書いてない。

で、まぁ、自分で API 叩いて取得してみた

  1. iOS アプリのプロフィール > 設定 > アプリバージョンを 10 回タップすると開発者向けオプションが出てくるのでそこから token を手に入れる(これは上記 README にも書いてある)
  2. それを使って curl でデバイス一覧持ってくる
$ curl "https://api.switch-bot.com/v1.0/devices" -H "Authorization: ${token}" | jq .
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   318  100   318    0     0    309      0  0:00:01  0:00:01 --:--:--   309
{
  "statusCode": 100,
  "body": {
    "deviceList": [
      {
        "deviceId": "xxxxxxxx",
        "deviceName": "電気",
        "deviceType": "Bot",
        "enableCloudService": true,
        "hubDeviceId": "xxxxxxx"
      },
      {
        "deviceId": "xxxxx",
        "deviceName": "Hub Mini",
        "deviceType": "Hub Mini",
        "hubDeviceId": "000000000000"
      }
    ],
    "infraredRemoteList": []
  },
  "message": "success"
}

で、取得できるんだけど取得して値を見たらそのデバイスBluetooth Device Address と一緒だったってオチ。 アプリからデバイス情報開くと「BLE MAC」 っ書いてある項目がそれです。わざわざ API 叩かなくてもすぐに出てきますよというお話。

ググってもあんまり情報出てこなかったからメモがわりに残しておく

SLURP 頼んでみたけど俺には微妙だった(コロナのせいかも知れない)

さて、好きな珈琲豆のサブスクが終わってしまったので色々なものを試してみてます。

yoshiori.hatenablog.com

で、今回試してみたのは

www.slurp.coffee

スラープはヨーロッパの一流焙煎家から
2週間、または4週間おきに
スペシャルティコーヒーをお届けする定期便。
どこの焙煎家のコーヒーが届くのかは
箱を開けるまでのお楽しみ。
2021年は海外から届くこだわりコーヒーで
新しいコーヒーライフを始めませんか? 

 ということで色々試そうと思ってた機会だしちょっと楽しそうだなと思って注文してみた。

https://twitter.com/yoshiori/status/1356086277020340224?s=20

で、今日やっと届いた。

f:id:Yoshiori:20210206201713j:plain

ちょうど焙煎から 3 週間くらい経って届いた感じ。なんか Best before 11.7.2021 とか書いてあるけどそれは流石に厳しいやろ……

珈琲のお土産は大変ありがたいのですが、出来れば豆で買ってきてほしいという話 - 宇宙行きたいにも書いたんだけど、珈琲豆って結構鮮度が大事。一般的には焙煎 3 日後から香りの抜け始める 14 日後までが飲み頃とされてる。

なんかたまに「3週間後くらいが実は一番美味しいように焙煎してます」的なこと謳ってるサブスクとかもあるんだけど、なんの根拠も無い。本気でそう思ってるんだったらその焙煎 3 週間後の豆で品評会とかで他の新鮮な豆よりも高い評価とったりして欲しいんだけど、そういうのもない。

まぁ、話ずれちゃったけどちょっとこれは厳しいなぁと。コロナのせいで遅くなっているのかも知れないけど、まぁだとしたらコロナ治るまではやっぱり頼めないなぁと思った。やっていることは楽しそうだしちょっと興味あっただけに残念。日本の焙煎所とも契約してるっぽいのでそっちからの発送に当たったら大丈夫だったかも知れないけど毎回そんな博打もしてられないしね。

f:id:Yoshiori:20210206202753p:plain

 

https://twitter.com/yoshiori/status/1356086277020340224?s=20

電池のふりをするやつがスマートホーム的に便利!

f:id:Yoshiori:20210130000536j:plain

季節外れにクリスマスツリーの話をするんだけど、うちのクリスマスツリーはツリーに巻いてあるライトとは別にてっぺんの星も光るようになってる。

けど、部屋の照明は時間が来ると自動で着くのにツリーだけわざわざそこに行ってスイッチ入れるのはめんどくさくなってきて、飾っているのにスイッチを入れなくなってきてしまっていた。

せっかく「子供にクリスマスシーズンになると毎晩ツリーがついている」という経験をさせようと思ってたのにこれは良くないと思ったので自動化することにした。

最初からツリーについていたライトはツリーに巻くやつも上で光ってる星も電池式だった。これをなんとかコンセントから取れるようにするとスマートコンセント的なのを使って簡単に制御できるのでその方向で考えた。スマートコンセントで扱うときはソフトウエアスイッチで ON/OFF するのではなくハードウェアスイッチでするものでないと扱いにくいのでそれで探した。

ツリーにぐるぐる巻くやつはこれを買って解決した。

問題は上にある光る星である。これは特殊な形をしているので星ごと変えることが出来ない。でも電池式。しかしこれは ON/OFF はハードウェアスイッチなのでなんとかその電池を制御できれば良さそうだった。最初は IoT 電池みたいな商品ないかなぁとか探してたんだけど良いものがなかった。でもちょうど良さそうなものを見つけた。

 電池のふりをするやつ、しかもケーブルはすごく薄くなっている。これなら行けそうだと思ったので早速取り付けてみた

f:id:Yoshiori:20210130002647j:plain

 いい感じに蓋も閉まった。

f:id:Yoshiori:20210130002725j:plain

これであとはスマートコンセントにつなげてそのコンセントに「クリスマスツリー」と名前を付ければ終わり。

スマートコンセントは僕はハブもいらないし GoogleHome にも Alexa にも対応しているこれを使っている。

 以上、電池のふりをするやつ(正式名称なんていうの?)が便利というお話でした。
 

Coffey っていう大好きなサービスが終わった。

『愛してその人を得ることは最上である。愛してその人を失うことは、その次によい。』

ウィリアム・M・サッカレー

shironel.com

僕はコーヒーはエンジョイ勢なんだけど、家にいるときはハンドドリップで入れるのが好きです。なんていうかその方が美味しいとかよりもその一連の所作が落ち着くっていうのが一番の理由だと思う。

で、僕には Coffey の仕組みがすごく生活にマッチしてて最高だったので感謝の気持ちでここに記録として残しておきます。

まずは月2回届くというのが凄く良くてコーヒーって一般的には焙煎 3 日後から香りの抜け始める 14 日後までが飲み頃とされてる。その期間にちょうど飲み終わって次のが届くっていうのが理想だと思うんだけど、月 2 回ってちょうどそのくらいのペースになる。まずこれが本当に最高だった。

 次に好きだったのが、20gx2 とか 20gx4 とかの個別包装の豆に追加で日常使いの 100g を追加できること。僕は平日は仕事中にコーヒーを飲むのであまり冒険したり新しい味を楽しむより、好きな味のコーヒーが飲めることが嬉しいんだけど、日常使いの 100g があることでそれを実現できる。

 僕は届いた 100g の豆は雑にこのグラインダーに入れておいて毎日入れるときに挽いて CHEMEX で入れるっていうのをやってる。

まずはこの日常飲むためのいつものコーヒーが安定して手に入るのが好きだった。 

f:id:Yoshiori:20200518134016j:plain

次に毎回色々な味を楽しむ方は 20g の個別包装になっているのも凄くよかった。最初は僕はさっきの電動グラインダーしか持っていなかったので扱いに少し困ってたんだけど、休日に何度か飲んでみたら凄く新しい発見があって美味しかったのでめちゃめちゃ楽しかった。

楽しすぎてこの 20g を休日に楽しむためだけにハンドミルを探すようになった。結局スチームパンクっぽいデザインが気に入ってカリタのミルを買った。

カリタ Kalita コーヒーミル 手挽き KH-5#42039

カリタ Kalita コーヒーミル 手挽き KH-5#42039

  • メディア: ホーム&キッチン
 

 そうなってくると休日は 20g しか入れないので別のドリッパーが欲しくなってきてそれも探して買った。これは Coffey で売ってたのが可愛かったのでそのまま Coffey で購入した。

f:id:Yoshiori:20200720160752j:plain

平日は安定した味が楽しめて休日は新しい出会いがあるっていうコーヒー生活は凄く幸せだった。毎回添えられてくる手紙も可愛くてキッチンのコーヒーコーナーの壁に貼ってた。

f:id:Yoshiori:20201121175537j:plain

さて、そんな大好きだった Coffey がサービス終了することになった。コーヒー生活が Coffey に依存しすぎてて代替えサービスを探すのが難しい。月2回送ってくれるところは何個かあるんだけど、一種類を送ってくるだけか数種類なんだけど 45g ずつを三つとかそういうなんというか安定の平日用とチャレンジを楽しむ休日用みたいな生活に慣れすぎてしまって悩ましい。

f:id:Yoshiori:20201220143656j:plain

そんな完全に依存してしまったサービスが終了するのは悲しいけど関係者の方(半分以上知り合いなんだけど)にはお疲れ様でしたという気持ちと感謝の気持ちでいっぱいです。あなた達のおかげで僕は新しいコーヒーの楽しみ方を知りました。

Launchable ではまた仲間を募集します!!

Launchable に join した!! - 宇宙行きたい

にも書いたのですが半年くらい前から Launchable で働いています。
で、また若干名エンジニアを募集するのでそのアピールです。

実際何やっている会社なのかとかは AI Powered Test Automation | Launchable, Inc.

このへんを読んでください。

なので僕からは実際に働いていていいなって感じているところをアピールしようと思います。


一緒に働くメンバーがマジでみんな優秀

まずはなにはともあれ川口さんと働けるのが最高。

ちょっと昔話になっちゃうんだけど、それこそ昔は CI は XP とかの文脈で語られはするけれどもなんというか GoogleAmazon みたいな大企業がやっている遠い世界の出来事みたいな感じだった(少なくとも俺にとっては)。
そんななか Hudson が出てきて一気に気軽に導入できるようになったんだよね。当時も Apache Continuum とか他にも CI ツールはあったけど、 Hudson の導入のしやすさというかおもてなしは群を抜いてた。
僕は未だに覚えてるんだけど、当時「hudson 試してみるか〜」って思ったら jar をダウンロードしてきて「java -jar hudson.jar」を実行するだけだった。データベースを別に用意したり tomcat たてたりとか何もいらない。コマンド一発でサーバ起動してもうそっからすぐに CI 導入できる状態にできた。そんな手軽さもあってか hudson はどんどん普及していき jenkins になり、もう CI の代名詞みたいな感じになったと思う。なんというか僕にとっては CI を民主化したみたいな感覚のソフトウェアです。(そのあとの Travis CI の出現も大きいと思ってます)

で、そんなソフトウェアとコミュニティを作った人と働けるのが楽しい。
特にまだ立ち上げ時期なのでいろいろな機能の取捨選択をしたり、どう柔軟性をもたせておくかとか、これは決定を先送りにしても大丈夫とかそういうのを含めて一緒に議論できて開発をしているのが本当に楽しい。
あたりまえなんだけど、コードレビューもしてくれるし設計の相談にものってくれるしね。マジこれは本当に最高。

他のメンバーも優秀で本当に日々驚く。共同創業者の Harpreet もそうなんだけど、みんなエンジニアリングとか技術とかに対する理解がメチャメチャ深い。元エンジニアの人たちが多いからなのかもしれないけど、「詳しいですね」とかそういうレベルではない。僕や他のエンジニアが知らないプロダクトを教えてくれたりするし、普通に僕が調査で書いたジャーナルとかにも気軽に適切なコメントくれる。
本当に純粋に優秀なメンバーが揃っているんだろうなと思うけど仕事していて一緒に仕事する人にストレスを感じないのはすごく良い経験。


作ろうとしているものの価値が魅力的

スローテスト問題ってそれこそ昔から言われている問題だけどもそこに真っ向から取り組んでいるのが個人的にはすごく魅力的です。
変に世の中に存在するかどうかわからない問題に取り組むのではなく実際にすでに存在している問題、しかもあまり良い解決策が出てない領域なのでやればやるだけ価値が出る的な問題。そこに仕事として取り組めるのはすごく楽しいです。

だって絶対に将来の自分を助けるためにもなるから。
なんとかコアのロジックは見え始めているけど形にするためにはまだまだ色々やることがいっぱいな状況なのですごく楽しいです。


完全リモートだけどリモート慣れしてる

コロナ以降、リモートで業務している人も多いと思いますが、ウチは元々リモート前提だったのでいろいろな仕組みがリモート前提で作られています。
意思決定やディスカッションなどもリモートや時差があること前提で考えられているのでそこにストレスを感じることはあまりありません。
例えば意思決定には DACI フレームワークが使われていて、どういう経緯で物事が決まったかわかるようになってます。
自分の知らないところで話し合われた結果だけ降りてくるとかそういうのではないっていうだけでもやりやすいし、自分も気軽に 「xxx について決めたいと思うから DACI 書くね」とか「xxx っていうふうにしようと思うんだけど他の意見ある人いるなら DACI 書きます」とか言えるのでやりやすいです。

ということで募集中です。

条件とか詳しくはリンク先をみてください。

www.launchableinc.com
まだまだシードラウンドなのでやらなきゃいけないことも盛りだくさんです。
でもチームビルディング含め色々なものが出来上がっていく過程を経験しながらチャレンジできるのはすごく楽しいです!

僕は「何を作るか」も大事だけどもそれよりも「誰とやるか」が大事だと思っています。
共感して一緒に作っていけるエンジニア募集です!

興味があったら是非応募してください!!!

 

 

kohsuke.hatenadiary.com

ninjinkun.hatenablog.com