Makuakeでサポートしたキーボード「Taptek」が届いた
これです。(`・ω・´) www.makuake.com
これまで使っていたMajestic Minilaと同じくらいの大きさで半分の薄さ(下が今回のやつ)
持ち上げてみてもかなり軽い。カタログスペック的には500gくらいらしく、持ち運びする人には嬉しい重量。
打鍵感はとてもいい感じです。カチカチ感あるのと、軽く押し込んだだけで反応してくれるので軽やかな入力感ありますね。サイズが一回り小さいので誤入力が頻発していますが、じきに慣れるとは思います。
バランスが取れていて非常によいキーボードです。14000の価値十分にありますね!
こいつで一番オススメなのが、プロファイルを3つまで登録できるところですかね。
家でWindows, 外出Linux、会社Macの環境でもう一台のMinilaを持ち歩いて使っているんですが、前使っていたMinilaだと直近繋いだところを優先的につなぎに行くので端末切り替えるときが地味に面倒だったんですよね。結局つなぎ直さないといけないという。
その点こいつは、Fn+1-3キーで端末切り替えられるので手間が省けていいっすねー。
あとは有線とBluetooth両対応なのがいいです。メカニカルで両対応のキーボード数少ないんですよね。
概ね利用感には満足なんですが、使ってて気になったところがいくつか(´・ω・`)
- Fnキーが左下に鎮座し、その右にCtrl
- ここはCtrlがいてほしい(´・ω・`)
- めちゃくちゃ押しづらいので、caps lockにCtrl割り振って使うことに
- 傾斜がない
- 筐体を薄くするためだとは思うんですが、キーボードの裏面にあるあの傾斜がないんですよね(´・ω・`)
- 小型なので大きく問題にはならないんですが、やはりこれまでと感覚変わるので違和感。
- バックライトカラー変更キーを誤爆しやすい
気になっているのはこれくらいですかね。まだ一日も使ってないので継続して触ってみましょうかねー。
独り言チャンネルのすすめ
Slack使ってる人は今すぐできる。やろう。
かなり前の話ですが、こんな話題がありました。
世間的にはTimesで名が通っている分報。 恥ずかしながら、これ知ったの昨年末くらいでした(´・ω・`) その時はまだ有用性に気づいてなくって、「ああ、こんなやり方やってるところもあるんだなー」と感じたくらい。
私、今副業でお手伝いしている会社がありまして、そこでは他にも副業エンジニアとしてJoinされている多くのメンバーがいます。 副業先のSlackでは副業エンジニア用のパブリックチャンネルが用意してあって、そこでいろいろコミュニケーションしてます。そこで「稼働します」と表明して作業開始!みたいな運用ですね。
とある副業メンバーが、稼働スタートのスレッドにリアルタイムな作業の進行状態とか調べた内容とか、お気持ちを書いていくんですね。そこで出てきた話題に対して自然に社員とか他副業メンバーがコメントしていく。
あれ?これ意外とすごいんじゃない?という気持ちが湧きました。今その時困っていること、確認したいことを気軽に投稿でき、コメントする方も流れで背景とかがわかるので気軽にコメントしやすい。 人の質問に対してコメントするのって、相手の状況とか鑑みなきゃいけないので結構考えちゃうじゃないですか?独り言で状況が流れているならそれみれば良いので、レスポンスのスピードも上がる。
独り言書く方からみても、あくまで自分の気持ちとか考えを書いていくだけなので、見る人のことを意識する必要がないんですよね。だから正直に困ったことをかけるし、わからないことを分からんと言えるわけです。
各メンバーの善意で成り立つコミュニケーションから、お互いが抱える問題が自然に解決していく。すごく良い活動だと思います。
あと、個人的に一番有益だったのは作業のログを残せることですね。 作業している時の思考って、後から結構思い出せないんですよ(´・ω・`)ブラウザのタブを大量に開く癖のある人はわかるかもしれないんですが、その時何調べてたか覚えてないんですよね。なぜそれを調べようと思ったのか、何が困っていたのかを、あとから振り返ることは難しいんですよねぇ。自分だけ?
これが独り言を書いていくことでクリアになる。あとから調べたことをブログにするとかどこかに投稿するとかなったときでも振り返りやすく、改めて調べ直すこともする必要がなくなる。全てはそこに書いてあるからだ。
こういう気付きがあり、自分も 率先して独り言と言う名の分報を書くようになりました。
まだ試してない方、一度試してみましょう( ・`ω・´) おすすめです。
golangでoverrideを実現するためには
golangは継承がない言語ではありますが、メソッドのオーバーライドを行うことができます。
embedded使います。 本来はinterface定義して解決した方がいいんですけども、使っているパッケージでinterface定義されていないやつのMock作るとき等、これで解決しないといけなさそうなケースがありました(´・ω・`)
// embeddedされる側 type BaseModel struct { Name string } func (b *BaseModel) Talk() string { return fmt.Sprintf("name is %s", b.Name) } func (b *BaseModel) Action(in string) string { return fmt.Sprintf("%s, actively %s.", b.Talk(), in) } func NewBaseModel(name string) *BaseModel { return &BaseModel{ Name: name, } } // embeddedする側 type ModelA struct { BaseModel ActionName string } // Actionだけ定義してBase側を上書きする func (m *ModelA) Action(in string) string { return fmt.Sprintf("%s, %s %s.", m.Talk(), m.ActionName, in) } func NewModelA(name, action string) *ModelA { model := &ModelA{ BaseModel: *NewBaseModel(name), ActionName: action, } return model }
な定義があったとして、
package main import "fmt" func main() { dog := NewBaseModel("bog") fmt.Println(dog.Action("run")) cat := NewModelA("cat", "selfishness") fmt.Println(cat.Action("run")) }
で動かす。
name is bog, actively run. name is cat, selfishness run.
期待通りの動作はする。うーん、単純なものならこれで動くのか。
例えば、外部にリクエスト投げるモジュールがあったとして、そいつの送信部分だけ外部に送らないようにする処理で上書きしてやれば、Mock化が簡単にできそうな気がします。
ただ、上記で上書きしきれないパターンがある
今仕事でやってるFirestoreの実送信部分。上書きしたはずが、上書き元が呼ばれてしまうんですよね。
直接オブジェクト作ったところで呼ぶ分には期待通り動きそうですが、メソッドのレシーバーでembedded元が指定されているとそっち呼んでしまうのかな(´・ω・`)あとで検証しますか
多分この[メソッド定義とメソッド呼び出しの真実]あたりが、embedded側が呼ばれる原因なのかもしれません。
ローカルにいっぱいあるgitリポジトリの管理を考える
これまであんまり意識せずに適当なディレクトリにバカスカcloneをかけていたわけですよ。 複数のリポジトリ触ることがあんまりなく、ほぼ1つのリポジトリだけで完結する日々。まあモノリシックなRailsをメインの仕事にしている私にはそれで十分だったわけです。
話は変わって、今年に入ってから本格的に副業始めました。知り合いからちょっとしたチケットをもらってお小遣いを稼ぐ、という活動はやってましたがお仕事として本格的にコードを書く日々に突入したわけです。
現場はmicroservice的な複数リポジトリでサービスを管理している会社で言語はGolang。必然的にGolang的なディレクトリ管理が必要になってきます。となると、これまでの無秩序カオスな管理方法だとストレスマッハなのです。あれ?あれどこいったっけ?あれ?
最初は、普段使っているPecoのブランチ一覧選択よろしく、GOPATH以下を適当に抽出して選択する方法を取ろうとShellを書いていたわけなんですが。やはり先人の知識、すでに同じようなことを解決している方が当然いらっしゃるわけですな(`・ω・´)
ghq。そういえば昔この記事見て試そうとしていた記憶が呼び起こされます(´・ω・`)なんでやらなかったんだっけ?まあいいか。
早速これをセッティングしていきます。Golangのスクリプトですが、homebrewにもあるらしいのでこっちで入れます。
brew install ghq cat <<EOS >> "$HOME/.gitconfig" [ghq] root = ~/src EOS
合わせて環境変数GOPATH=$HOME
を設定しておきます。これやっておくとghqでGolangのものもghq list
されるようになります。強い。
ただ、これだけだとghq list
した結果をgrepするなりの作業が必要になってしまうので、peco等のインクリメンタルサーチツールで挟んであげます。
ghq list --full-path | peco --prompt "[find repository]" --layout=bottom-up
個人的にpecoには--prompt付けたい派です(`・ω・´) 上のコマンドにエイリアス貼るなりzleでキーバインド設定したい等あればお好みでどうぞ
ようやくこれでまともなリポジトリ管理ができるようになれそうです。
個人的にQOLを上げてくれるものたち
タイトルどおり、我が家で使っていて便利なものを雑に紹介します。 誰得ですが、いいぞ。
スマホの防水ケース
https://www.amazon.co.jp/gp/product/B073D6NNVD
一年くらいヘビーに使ってますが(主に嫁が)これといって問題なく使えてます。
風呂でもスマホ触れるのつよい。自分は結構拒否感あって使ってなかったんですが、積んでる電子書籍消化したくって長風呂ついでに使ってみたところすごく快適でした。
指紋認証と書いてますが、効いた試しがありません_(:3」∠)_風呂入って水滴ついてるせいでしょうか。
ネスカフェ ゴールドブレンド コク深め カフェラテ用
https://www.amazon.co.jp/gp/product/B075D831SB
スーパーの一角で稀に見る商品。よくおいてあるのはBossのラテベースですが、それよりこちらの方が豆のコクがあって重宝してます(`・ω・´)
ミルクとこれがあれば手軽にカフェラテっぽい何かが飲めます。さすがにちゃんとしたエスプレッソで煎れたものより味は落ちますが、手軽に飲むにはこれくらいがちょうどいいです。
1本で12杯。ミルク1杯250ml利用と仮定すると、大体60円くらいでしょうか。スタバの1/7くらいで一杯飲めます。オススメ。
黒烏龍茶のパック
https://www.yodobashi.com/product/100000001003599690/
自分が買ったのは、肉のハナマサにある同型品、だったと思う。
値段も400円程度で52パック入りだったはず。これ使う前は3日に1回くらい、烏龍茶のペットボトル買ってたんですけど、煮出すようにするとだいぶ出費減りました。1lのお湯に1パックいれて1時間くらいがちょうどいいです。
どうでもいいんですが、手軽に手に入るペットボトル烏龍茶、ローソンのプライベートブランドが一番おいしいと思います。サントリーのOEMなんですけど、どうして本家より飲みやすいんでしょうね(´・ω・`)謎
これも3日に2lで170円くらいだったものが、煮出しで、8円+ガス水道代で大体20円行かないくらいでしょうか。2l作っても40円行かないので、1/4-1/5くらいの出費ですね。
とりあえずこんなもんですかね。今後もなんか良さそうなものがあったら書いていこうと思います。参考になれば。
Empyrion9.3の更新内容を確認してみる
普段遊んでるゲームの話です。 新しいバージョン来てましたね。中見る限りだとBugFixが中心。 Empyrion、LEGOとか好きな人にはオススメします。宇宙船作るの楽しいですよ(`・ω・´)
We just released the EXPERIMENTAL version of Alpha 9.3, which adds the final part of the stabilizing, optimization and bug fixing update for Alpha 9.
とりあえず、Ver9のバグ修正や最適化がこれで終わりらしい
変更点
Oviraptor Update:
- Added Oviraptors to cold areas on Temperate Planets
Oviraptorが温暖な惑星の寒冷地にも出現するようになったらしい。 温暖な惑星の寒冷地ということは、Aquaの極地付近とか山岳とかですかね。
- Integrated new group behavior a) when friendly:
- adults are traveling, young are playing around them
- if player gets close to the group, the young do sometimes start to play around him and follow him around for a while b) when attacked:
- adults attack the attacker
- young will try to stay/hide behind the adults and they do not attacked
- if all adults are killed, the young will run away
友好的だと、大人のMOBの周辺に子供MOBがいるという、草食獣的な挙動をするらしき。 プレイヤーが近づく(get close to)と、子供MOBがプレイヤーに寄ってきたり、ついてきたりするらしい。 このhimってどこに掛かってるんだろう。プレイヤーだと思うんだけども(´・ω・`)
何らかの攻撃を加えるなりすると、大人のMOBが攻撃してきます。子供MOBは攻撃してこない。 大人MOBを倒すと逃げていく。よくある動きみたいですねー。
Gameplay
- Player's volume capacity now includes that of Player Armor and equipped Boosters
- Improved SI Debris Pickup: when the block that was placed just ago falls down because of SI, you can pick it up again
重量システムの容量に、プレイヤーの装備してるアーマーとブースターパックの容積も含むとのこと。 後は、建物にブロックくっつけた瞬間に崩落したら、ブロックのまま回収できるらしいです。
- CTRL + SHIFT + LMB add/remove 1000 stack to/from construction queue
SHIFT+左クリックで10、CTRL+左クリックで100の作成予約ができてましたが、そこに1000のパターンが追加されるとのこと。あんまり使うケースないかなぁ。
- Only Spotlights are now switched on/off when pressing L in a vessel
乗り物に乗ってる時にLでライトのOn/OFFが切りかられるらしい。普段からつけっぱなしなんであんまり意識してなかったんですが、あると便利なのはべんりですね。
Optimizations:
- Optimized terrain shader > pls let us know if you noticed a performance improvement
地形シェーダーを最適化したらしい。
- Optimized Deconstructor with instant-speed or after longer 'offline' time (e.g. DSL)
デコンストラクタの処理速度が見直しになった?ちょっと意図がよくわからないですねー(´・ω・`)
Visuals / UI:
- Added 'dynamic item grids' that only show enough rows for the current grid content plus one empty row if the grid is editable
新しいUIが追加になったらしい。うーんよくわからん(´・ω・`) たまにコンテナの中身たくさんあるのに表示①がずれたりしていたあの問題の修正でしょうかね。
- Added more stone floor textures (Concrete Block)
コンクリートにテクスチャ追加
- TextureEditor now supports HeightOffset + HeightContrast
テクスチャツール使用時に余白の指定ができるようになった?
- Moved On/Off buttons to left in Constructor UI (so they are not hanging in air)
コンストラクタのOn/OFFボタンの移動らしい。機器にアクセスしたときの画面の話っぽい?
- Improvements to Terrain Decoration
地形表示の改良。どういうことなんだろう(´・ω・`)
Updated PDA Functionality:
自分PDAあんまりやってないんですよね(´・ω・`) マルチプレイヤーで即座に通知されたり、操作感の改善がはいったっぽい?
Playfield Update:
- Updated start planet in Akua-Omicron scenario: added Talon Defence POIs, removed HUD markers for settlements etc
オミクロン開始時惑星で、タロン集落のPOIに変わってタロンDeffenceが出現するようになった?
-Updated playfields: using hud distance, added defence pois, other tweaks
敵敷地から離れてるときの友好度の増減数値を調整したんでしょうか?
- Updated POI distribution on several playfields
敵敷地内の建物の配置場所を調整したらしい。タロンとか端っこに固まってましたからね...
- Using now white markers in playfield.yaml for all POIs that have Faction: None
所有者がいないPOIが白マーカーで表示されるようになったらしい
POI Update:
建物やBluePrint機体の追加等でしたね。他には特になし
後は細かなバグ対応などがちらほら。 特に目新しいものはないんですが、安定性が高くなったことは良さげです(`・ω・´)
SREをどう始めるべきか?のヒントを貰った一日について
えらく遅い投稿となりましたが、2019/01/18(金)に開催された、SRE Loungeに参加してきました(`・ω・´)ゞ sre-lounge.connpass.com
金曜日の19:00開始というスケジュールでしたが、ほとんど席が埋まってました。実際にSREを運用している企業の事例を聞いたり、懇親会で盛り上がっていろんな会社さんと話をしたりしていましたが、かなり面白い話が聴けて、3時間あっという間でした。
講演中の資料は以下です。公開していただき感謝。
※Speee天野さんの資料は見つけられなかった(´・ω・`)
詳細は資料を見ていただくとして、参加して私が感じたことや考えたことを書いていきたいと思います。
SREとはなにか?の理解
まずはSREとはなんぞや?的な話を私の理解でまとめてみます。SREと聞いてほとんどの方はこの本を思い浮かべると思います。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
Google社で昔から様々なサービスを提供し蓄積してきたベストプラクティスをまとめた本です。SRE本はGoogle社の事例であり、取り入れる企業の状況によって、SREでやるべきことは異なります。
しかし、SREを進めるときの考え方はおそらくどの企業でも共通だと思っていて、私個人的にはこのような認識を持っています。
「サービスを安定させて、顧客に最高のユーザー体験を提供し続ける」
これまでの開発・運用と大きな違いはなく、唯一違いがあるとすれば、「何をもってサービスを安定していると言えるのか?」を定量的に評価し、運用で得た知識を共有することを強制することにあると思うわけですね(`・ω・´)
そのためにはまず、顧客に提供すべき基準であるSLA(サービスレベル契約)と、プロダクト側の目標値としてのSLO(サービス レベル目標)を定義します。合わせてSLOを評価するためのSLI(サービスレベル指標)を決めます。一般的には可用性やレイテンシがよく使われるかと思います。
目標値やそれを計測するための指標が決まると、エラーバジェット(許容できる停止時間)を算出できるようになります。例えばSLOが可用性99%で評価される場合、1%は「機能リリースのために使っていい停止時間」として扱えます。システムの信頼性を100%にするのは難しい、ならば許容できる範囲を決めてそれを守ればいい。
....始めて触れる考え方で、いい意味でショック受けました。使っていい停止時間が見えることで、気持ち的に余裕が出てくるのはいいですね。失敗しても基準値中に収まる、これが認識できるようになると必要以上にリリースを怖がることがなくなり、新機能や後述するToilの削減をガンガン反映していくことができます。
とはいえ、実際に障害を0にすることはできず、起きるときに発生してしまうのが奴らです。SREの文脈では、ポストモーテム(障害報告書)を”正しく”運用します。障害を失点と考えず次の学びとする。そのために発生した障害についてかなり詳細に記述する必要があるようです。
- 発生したこととその影響範囲
- その緩和や解消のために行われたアクション
- 根本原因
- 再発防止策
これらの情報を元に、発生した問題を集合知に変えたりシステム自体を改修するなどして、次回同じ問題が発生することを防ぐ活動をします。単にお偉様に報告するだけの資料ではなく、その後の改善を主目的に行う。当たり前に行っていきたい考え方ですね。
そしてSREといえばToilが多く語られます。定常的な運用作業、という体で扱われていることが多そうですが、ぱっとイメージするのは度重なる不具合調査とか、ぬくもりある手作業リリースといった運用のめんどくさい作業。こういった作業を自動化したり、そもそも運用を変えたりしてToilを削減していき、本来のプロダクト開発に使う時間を確保することが求められます。SRE本のGoogleの事例ではToilの作業を全体の50%以下に制限するルールだったそうです。後の50%は顧客価値向上のためのプロダクト開発に使う。
そもそもToilはいびつな運用を行っているために発生するもの、と私は思ってます。自動化してワンポチでリリースできれば一日に何回もリリースを行うことが可能だし、障害を発生させない仕組みに変更することでそもそも障害調査をする必要がなくなったり。 プロのエンジニアとして働いているのであれば、少ない労力で最大の効果を上げるよう振る舞うのは義務です。そのためにもToilを発見し、倒していく。継続し続ければ顧客価値向上の速度が更に上がり、ビジネスの結果にも繋がるでしょう。
感じたこと
SREを実践している3社の話を聞きましたが、やはり各社によって捉えかた違ってましたね。 メルカリさんでは事業の成長に沿ってSREを進化させ続けることに関心が多くあったり、一方グノシーさんでは、SREとは何で何をもって評価するのか?に関心が寄っているように感じました。SpeeeさんではSREを実践する組織づくりやメンバーの評価を見ているようで。
各社とも要求される品質も、必要とされるスピードも異なっているので当然のことなのですが、SRE本に忠実に運用するより何が自社にマッチしたSREなのか?を意識した上で運用を検討するほうが、よりワークするかと感じています。
弊社でもSREを導入したい、といった声は度々上がっており「弊社のSRE」を実践した後に、成果をこの場で発表できるようになるとGoodですよね(`・ω・´)がんばります。
とても興味ある話多かったです。弊社でもこれからやっていく感出てきたので事例つくって発表するなり、なんらかの形で貢献 できるようにしたい(`・ω・´)#srelounge
— しのゆ (@shinoyu) 2019年1月18日
心の声
SRE、いろいろ流派あって、会社ごとに運用全然違うんですよね...各社どういった定義しているのか知りたい #srelounge
— しのゆ (@shinoyu) 2019年1月18日
メンバーの得意領域で補って面で拾えること大事そう #srelounge
— しのゆ (@shinoyu) 2019年1月18日
割り込み多すぎてToil Limit is なに?状態で辛い #srelounge
— しのゆ (@shinoyu) 2019年1月18日
スクラムとかチケット駆動で開発してるならToil計測簡単に始められそう。ベロシティ計測、チケットをラベル化して集計。など #srelounge
— しのゆ (@shinoyu) 2019年1月18日
ビジネス側向けに手順まとめて、これ通りやれば大丈夫、みたいなコミュニティケーションはよくやってる(`・ω・´)テックだけじゃなくてビジネスも巻き込んでToil撲滅できるの最高では? #srelounge
— しのゆ (@shinoyu) 2019年1月18日
問い合わせフロー整備かなり効く。Toil削減に直結する #srelounge
— しのゆ (@shinoyu) 2019年1月18日
弊社まだSREをちゃんと運用し始めれていないこともあって、SREやってて楽しいことを聞いてみたい(´・ω・`) #srelounge
— しのゆ (@shinoyu) 2019年1月18日
懇親会の話題
懇親会は他の会社の方と結構話しました。
SREを運用している会社の方は全体の3-5割ほどでしょうか。これから導入し始めたい、といった弊社と近しい状況の方も多く話が盛り上がったのですが、経験者が少なくやり始めるのが大変という状況が伺えました。登壇して発表された方でもSRE経験者の採用に苦労している旨の話があるらしく、少ない人数でなんとかうまく回している、状況が実情なんだろうなーと感じました(´・ω・`)
新人を育成する、といった意見もありましたが、SREの領域だとエンジニア経験がかなり問われる気がします。障害のニオイや、対応の勘所といったスキルはある程度修羅場をくぐってこないと身に付き難いものですし。経験者を付けてOJTするにしても長期を見据えないと大変そうだなーという印象です。
後、記憶に残っているのは、SREエンジニアの評価をどうするか問題がありました。 もともとインフラ寄りの仕事である以上、どうしても正常に運用が回っている状況では必要性が感じられ難くく、評価し辛い話が生まれそうです。解決する手段として、SLOやSLIといったように今の品質がどうかを計測し、評価者に定量的な数値を元に評価してもらうことが可能になります。
「俺がいるからこの目標が達成できている」を自信持って言えるようにしっかり測定して追っていく。正しく結果と評価を結びつけることも大切ですね。
他にもいろいろと考えたことや書きたいことがありますが、今日は一旦このへんで(`・ω・´)