2019-04-08

golangでoverrideを実現するためには

golang

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側が呼ばれる原因なのかもしれません。

skatsuta.github.io

2019-02-28

ローカルにいっぱいあるgitリポジトリの管理を考える

雑記開発

これまであんまり意識せずに適当なディレクトリにバカスカcloneをかけていたわけですよ。複数のリポジトリ触ることがあんまりなく、ほぼ1つのリポジトリだけで完結する日々。まあモノリシックなRailsをメインの仕事にしている私にはそれで十分だったわけです。

話は変わって、今年に入ってから本格的に副業始めました。知り合いからちょっとしたチケットをもらってお小遣いを稼ぐ、という活動はやってましたがお仕事として本格的にコードを書く日々に突入したわけです。

現場はmicroservice的な複数リポジトリでサービスを管理している会社で言語はGolang。必然的にGolang的なディレクトリ管理が必要になってきます。となると、これまでの無秩序カオスな管理方法だとストレスマッハなのです。あれ？あれどこいったっけ？あれ？

最初は、普段使っているPecoのブランチ一覧選択よろしく、GOPATH以下を適当に抽出して選択する方法を取ろうとShellを書いていたわけなんですが。やはり先人の知識、すでに同じようなことを解決している方が当然いらっしゃるわけですな(｀･ω･´)

blog.kentarok.org

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でキーバインド設定したい等あればお好みでどうぞ

ようやくこれでまともなリポジトリ管理ができるようになれそうです。

2019-02-12

個人的に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くらいの出費ですね。

とりあえずこんなもんですかね。今後もなんか良さそうなものがあったら書いていこうと思います。参考になれば。

2019-01-27

Empyrion9.3の更新内容を確認してみる

雑記ゲーム

普段遊んでるゲームの話です。新しいバージョン来てましたね。中見る限りだとBugFixが中心。 Empyrion、LEGOとか好きな人にはオススメします。宇宙船作るの楽しいですよ(｀･ω･´)

steamcommunity.com

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機体の追加等でしたね。他には特になし

後は細かなバグ対応などがちらほら。特に目新しいものはないんですが、安定性が高くなったことは良さげです(｀･ω･´)

2019-01-21

SREをどう始めるべきか？のヒントを貰った一日について

えらく遅い投稿となりましたが、2019/01/18(金)に開催された、SRE Loungeに参加してきました(｀･ω･´)ゞ sre-lounge.connpass.com

f:id:gdgd-shinoyu:20190121032208j:plain:w400 — フードがうまい

金曜日の19:00開始というスケジュールでしたが、ほとんど席が埋まってました。実際にSREを運用している企業の事例を聞いたり、懇親会で盛り上がっていろんな会社さんと話をしたりしていましたが、かなり面白い話が聴けて、3時間あっという間でした。

講演中の資料は以下です。公開していただき感謝。

speakerdeck.com

※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といったように今の品質がどうかを計測し、評価者に定量的な数値を元に評価してもらうことが可能になります。

「俺がいるからこの目標が達成できている」を自信持って言えるようにしっかり測定して追っていく。正しく結果と評価を結びつけることも大切ですね。

他にもいろいろと考えたことや書きたいことがありますが、今日は一旦このへんで(｀･ω･´)

2019-01-15

キーボードは自作できる時代になってた

雑記

www.itmedia.co.jp

昨日行ってきました(｀･ω･´) 偶然、前の職場で昔一緒に仕事していた方と遭遇したのがこの日最大のハイライトでしたｗｗ

自作キーボードに関しては、以前からこんな記事をみることがあり、すごく興味あったんですよね(｀･ω･´) makezine.jp

そのうち体験してみたいなぁと自作キットの購入ページ眺めて感じていたんですが、ラズパイも放置している現状、作れる気がしなかったので手を出してませんでした。が、お試しキットが廉価で販売してまして、まずはそれから体験してみるのもありかな？と。

f:id:gdgd-shinoyu:20190115012206j:plain:w400 — 軸がバラ売りされてたのがツボ

お試しキットと言いながら、基板にはんだ付けするタイプのもので本格度が見え隠れします。

f:id:gdgd-shinoyu:20190115013852j:plain:w300 — 基板の設計者?名が書いてある

はんだ付けするのかれこれ15年ほど前が最後だったので、はんだごて買って練習するところからですかね..._(:3」∠)_

写真は取れなかったんですけど、売り物としては、このお試しキット以外に個人制作の本や、キーキャップセットが販売されていたようです。ただ、helixといった自作キット系はおいてなく、売り切れ状態だったみたいです(´・ω・`)残念

意外とキートップのセットが高い。デザイン性のあるキーキャップのセットが販売されていたんですが、1万ちょい～2万5000くらいの価格帯でしたね。お値段高い分、一般的なキーボードより打ちやすそうな形状ではありますが。

自作キーボードの人口はまだ少ないので低価格化できるほど供給量が確保できてないんだろうなぁ、と感じました(´・ω・`) もちろん、必ずしもセットのキートップを買う必要はなく、その気になれば自作することもできるみたいですし、本気な方は自作を試してみると良いかと思います。 blog.livedoor.jp

他、店舗では自作コーナーもありました。この記事の冒頭で紹介しているITmediaさんの記事通りの設備とサービスですね。自分が行ったときも2、3名ほど作業をしているみたいでした。いざとなったら相談することもできそうですね。

まずはお試しキットを作ってみて、慣れていきたいと思います。

2019-01-11

WSLのzsh、tmuxのコピペが動いてなかった(´・ω・`)

小ネタ

そういえば動いてないな～と放置していたんですが、最近本格的に触っている時間が増えてしまい、困っていたので対応しました。Macではreattach-to-user-namespaceを使いますがwslでは"win32yank.exe”ってのが該当します。Macで使っていたtmux.confの部分をこれに差し替えて再読込させてみたんです。

shinoyu/.tmux/tmux-Windows_Linux.conf:1: command not found: bind-key
shinoyu/.tmux/tmux-Windows_Linux.conf:2: command not found: unbind
shinoyu/.tmux/tmux-Windows_Linux.conf:3: command not found: bind-key
shinoyu/.tmux/tmux-Windows_Linux.conf:4: command not found: bind-key
shinoyu/.tmux/tmux-Windows_Linux.conf:5: command not found: unbind-key
shinoyu/.tmux/tmux-Windows_Linux.conf:6: command not found: bind

なんでや( ﾟдﾟ)

Macだとbrew使うと普通に新し目(2.7とか)入るんですよ。もともとターミナル環境はMac先行で整備していたので、新し目バージョンの設定に沿ってconf書いてました。しかしwsl環境では読めず。

おもむろにtmux -VするとこのときのTmuxは2.1(´・ω・`)

# tmux -V
tmux 2.1
# sudo apt install tmux                                                                                                     
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
tmux はすでに最新バージョン (2.1-3build1) です。
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 0 個。

最新なんですよねぇ。どうもこのバージョンが引っ張っているパッケージは古いらしく。まあバージョン古いですからね、仕方ないですね。

# cat /etc/os-release                                                                                                         NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"

どうやらtmuxは2.4くらいから設定の記法に破壊的変更が加わっているらしく、2.7に合わせてた設定を2.1で読もうとすると、そんなコマンドねぇ！エラーが出てくるわけです。(´・ω・`) https://qiita.com/akinoriikeda/items/867b9d9a074538815886

おそらく、Macと同じく2.7以降に上げれば解決するはず。ただしUbuntuの向いてる先が古い、ということでtmuxを自前でビルドしてしまいます。

https://github.com/tmux/tmuxをcloneします。git tagを叩くと、2.8のタグが切られていたので、ブランチをこれに切り替えてビルド。

手順

sh autogen.shを実行

 autogen.sh: 15: autogen.sh: aclocal: not found

ビルド失敗したので足りないライブラリ入れる

sudo apt-get install autoconf autogen

sh autogen.shをして次は成功
./configureを叩いて、configure: error: "libevent not found"
sudo apt install libevent-devで依存パッケージ追加して再度./configure。正常に終わる
make実行。エラーtty-term.c:24:21: fatal error: ncurses.h: No such file or directory
調べてみると、これも必要らしいsudo apt install libncurses5-dev
パッケージ入れてmake。通った。そのままsudo make install

一度tmuxのセッション落として、

# tmux -V
tmux 2.8

ここまでやって、最新入りましたね(｀･ω･´) 一度すべてのtmux落として再度上げ直したら正常にtmuxでコピペができるようになりました。

無気力生活 (ノ ´ω｀)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

golangでoverrideを実現するためには

ただ、上記で上書きしきれないパターンがある

ローカルにいっぱいあるgitリポジトリの管理を考える

個人的にQOLを上げてくれるものたち

スマホの防水ケース

ネスカフェ ゴールドブレンドコク深めカフェラテ用

黒烏龍茶のパック

Empyrion9.3の更新内容を確認してみる

変更点

Oviraptor Update:

Gameplay

Optimizations:

Visuals / UI:

Updated PDA Functionality:

Playfield Update:

POI Update:

SREをどう始めるべきか？のヒントを貰った一日について

SREとはなにか？の理解

感じたこと

心の声

懇親会の話題

キーボードは自作できる時代になってた

WSLのzsh、tmuxのコピペが動いてなかった(´・ω・`)

手順

ただ、上記で上書きしきれないパターンがある

スマホの防水ケース

ネスカフェ ゴールドブレンド コク深め カフェラテ用

黒烏龍茶のパック

変更点

Oviraptor Update:

Gameplay

Optimizations:

Visuals / UI:

Updated PDA Functionality:

Playfield Update:

POI Update:

SREとはなにか？の理解

感じたこと

心の声

懇親会の話題

手順

ネスカフェゴールドブレンドコク深めカフェラテ用