あぼぼーぼ・ぼーぼぼ

のんびり生きたい

Go Conference 2022 Spring参加レポ

gocon.jp

楽しかった〜〜

ぼく自身は会社で「Go書いていくぞ!」って状況に最近なって、すぐこういう大きいカンファレンスに参加してもどうせ内容ついていけないだろうなぁとか思ってたのですが、もちろんわからないやつもあるけど総合的にめっちゃ楽しめましたね。

本イベントはRemoというバーチャルスペースみたいなやつで開催されたのですが、ぼくは目が悪いわりにメガネかけるの嫌なので普段オフラインのカンファレンスだと会場のスライド見えなかったりするのですがオンラインだとその心配もないし、かといってウェビナーみたいな完全オンラインよりもよりオフラインっぽい体験もできました。

ビンゴは敗北しました。

Books for Gophersもはじめて見るzennの本とかに出会えてよかったですね。Real World HTTPポチりました。

Ask The Speakerって正直オフラインだとちょっと苦手だったんですが、オンライン良かったなー。

ハンズオンでは並行処理のやつをやりました。画像処理を直列で行なっており、エラーを返したい場合にerrgroup使って改善する内容でした。

womenwhogotokyo.github.io

# Before
pkg: github.com/WomenWhoGoTokyo/codelab/image-slender
BenchmarkExecute-8             1        15631215834 ns/op
BenchmarkExecute-8             1        15678542917 ns/op
BenchmarkExecute-8             1        15646132792 ns/op
BenchmarkExecute-8             1        15650187375 ns/op
BenchmarkExecute-8             1        15648852125 ns/op
BenchmarkExecute-8             1        15643782416 ns/op
BenchmarkExecute-8             1        15648781000 ns/op
BenchmarkExecute-8             1        15621613166 ns/op
BenchmarkExecute-8             1        15679038125 ns/op
BenchmarkExecute-8             1        15682719750 ns/op
PASS
ok      github.com/WomenWhoGoTokyo/codelab/image-slender        156.840s

# After
pkg: github.com/WomenWhoGoTokyo/codelab/image-slender
BenchmarkExecute-8             1        3343736083 ns/op
BenchmarkExecute-8             1        3245626500 ns/op
BenchmarkExecute-8             1        3247878583 ns/op
BenchmarkExecute-8             1        3235497875 ns/op
BenchmarkExecute-8             1        3237273625 ns/op
BenchmarkExecute-8             1        3240670125 ns/op
BenchmarkExecute-8             1        3238193791 ns/op
BenchmarkExecute-8             1        3235271583 ns/op
BenchmarkExecute-8             1        3249393500 ns/op
BenchmarkExecute-8             1        3237992000 ns/op
PASS
ok      github.com/WomenWhoGoTokyo/codelab/image-slender        32.727s

あとはブース回ったり(あんまり回れなかった)

docs.wantedly.dev

というわけで、18:00前くらいで僕はあがったのでLTは見れてませんが、総じてRemoを使った今回のGo Conferenceは体験良かったなと思いました!カンファレンスみたいな会場が複数あったりそれぞれブース単位で何かしてるようなイベント、ウェビナーとかYouTubeライブだけじゃなくてバーチャルスペースあると全然違いますねー。

一個だけ言うなら会場出入りしたとき(例えばTrack AからTrack Bに移動したとき)にデフォルトでマイクがONになってしまうのがちょっと微妙でした(テーブル一緒になった方のマイクがONになっててハウリングしちゃってたり)。あれイベント自体で強制OFFとかに変えられるのかな〜。

Go Conferenceに関わった方々ありがとうございました!!

『チームトポロジー』を読んだ

www.amazon.co.jp

『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』を読みました。

上長と話してるときにこの本の話が出て、「今回の組織設計で一部この本を参考にね〜」みたいな話があり、それなら僕もこの本読んで同じ思考の枠組みを獲得してから今の組織を捉えたいなーと思って読みました。

そもそもどんな本なのかたいして知らずに買ったのですが、「チームファーストで考えてチームを適切に分ける」ことの重要さが書かれていましたね。そもそもの問題はチームの境界と責任が曖昧なことによる認知負荷、ふむふむ。

この本の読み方としてはやっぱり「今の自分が所属する組織にチームタイプを当てはめて」「チームがうまくやるためにはどういうインタラクションをすればいいだろう」と考えながら読むのが楽しいなと思いました。

たとえば〜機械学習エンジニアが集まって、機械学習による様々な機能を内部向けにはAPI経由で提供するチームだからコンプリケイテッド・サブシステムチームかな〜とか。ただしX-as-a-Serviceというよりは、プロダクト開発チームとスクラムは組まないけど共通のKPIを持って施策を提案したり開発したりするので一定期間はコラボレーションインタラクションで働くのが効果的かな〜とか。その場合、技術的にはどの程度共有していくべきかな、あまり強く共有しすぎると認知負荷が高まるから基本APIドキュメントベースのやり取りで、結合テストなどの際にレイテンシとか含めて共有できたほうがいいな〜とか。

たとえば〜検索に関する専門的な領域を扱うチームで、内部的にはAPIを提供してサービスを使ってもらうのでコンプリケイテッド・サブシステムチームかな。ただそもそも「検索」の責任と境界ってなんだろなー、責任と境界をハッキリわけたければ逆コンウェイでチームを分けてインタラクションを設計しないといけないが、共通のKPIを達成するうえでは実はコラボレーション気味に働いたほうがいいのでは?とかとか。

そうやって今あるケースに当てはめて、「効果的なチームとしてふるまい、活動するには?」と色々思考していくと面白いですねԅ( ˘ω˘ԅ)

ミクシィにおける Go 活用事例 〜 #gocon 2022 Spring 前夜祭(非公式)〜 参加メモ

mixi.connpass.com

各発表と気になったところ〜(発表資料見つけたら追記)

Go移行におけるJSON-RPC対応

speakerdeck.com

せっかくRPCつかうならスキーマ駆動開発したいですよね〜。RESTとRPCが両方あるから、RESTにも対応できるOpenAPIを選んで、JSON-RPCに対応させつつスキーマ駆動開発をしていくという感じで。なるほど〜となりました。

あとドキュメントのデプロイがGitHub Actionsで自動化されてるのはいいな〜いいぞ〜と思いました。

gRPCはUdemyの教材で学んだことがあるけど、JSON-RPCとOpenAPIあたりは疎いので、一通り手を動かして学んでみるか〜という気持ちになりました!

aboy-perry.hatenablog.com

TIPSTARを支えるGoとGoogle Cloud

Goの採用背景のひとつにメンバーのモチベーションをあげていて、たしかにモチベーションあるとやっていきが生まれやすいよなーと思いました。

「言語仕様がシンプル」なことに対してぼくは最初「こんなこともできないのか...」って思いがちだったんですが、同じようなコードが書かれているので読みやすくて書きやすいかもなって感覚に徐々になってきてます。(ただまだ標準パッケージが引き出しが少ないので、素早く手が動く、というレベルにはほど遠いけど...)

あと紹介されていたGo 1.16のGo:embed、Go 1.17のtesting T.Setenvが便利そうなので、この辺の情報知れたのよかったよかった。

TIPSTARに関するGoの採用背景とかはこちらの記事でも話されてるみたい。

engineer-lab.findy-code.io

モンストとGoとBazelと

(モンストのバックエンドってRubyだったんだ)

面白かったのが、2014年当時のGo採用理由のひとつに「hashicorpとか、使っていたOSSがGoに置き換わっていたから、今後Goを読み書きできたほうがいいかもね」っていうのがあったことですね。

hashicorp/terraformとかもGo製ですね。近々Goの訓練として、この辺の有名なGo製のOSSをコードリーディングしようと思ってるのですが、「読めるOSSが増える」というのは新技術をキャッチアップするメリットのひとつかもな〜。

github.com

以上です!

Udemyの『Go言語で学ぶ実践gRPC入門』を受講した

Udemyの『Go言語で学ぶ実践gRPC入門』を受講しました ٩( ᐛ )و

www.udemy.com

Goに関する基本的な情報はわりとネット上に無料で見つけられたので、実践的・応用的な内容を期待して購入しました。

この講座は、gRPCのサーバーとクライアントをGoで実装するので、手を動かしながらGoが学べました。Goに関しては一定知っている前提で進むので、手を動かす訓練として機能しました。

あとそもそもgRPCをよく知らなかったので、そこの理解に頭を使いました。講座の半分くらいはgRPCとProtocol Buffersの説明なので、gRPCの基礎と実装例を学びたい人にはいいかなと思います。

欲を言えばテストコード書くレクチャーもあると良かったなぁ。

コードはGitHubに置いてあります。

github.com

『技術者のためのテクニカルライティング入門講座』を読んだ

www.amazon.co.jp

技術文書を書くにあたって新たな発見があればいいな〜と思って読んだけど、新しい発見はあまりなかった。ただ書いてることの多くは大事ではあることだなーと思った。

自分がマーカーを引いていたところ辺りを振り返りながらざっくり整理...したいけどあんまりマーカーが引かれてないので書くことがない _:(´ཀ`」 ∠):

全体を通して、読み手を意識するってのと、目的を持って論理的に書くってことが重視されている。

直近でtoBプロダクトのユーザーマニュアルに関わりそうなので、第5章のユーザーマニュアル・取扱説明書のところは役立つかもしれない〜。

『採用基準』を読んだ

www.amazon.co.jp

一言でいうと「リーダーシップが重要である」みたいなことが書いてあった。

以下自分がマーカーを引いていたところ辺りを振り返りながらざっくり整理。

コンサルティングプロセスとリーダーシップ

コンサルといえば地頭の良さが大事だと思われがちだけど、それは一部分に必要なものに過ぎず、リーダーシップが重要。

  1. 経営課題の相談を受ける(関係構築力、包容力、リーダーシップなど)
  2. 問題の解決方法を見つける(地頭、問題解決方法の引き出しの多さなど)
  3. 問題を解決する(洞察や感受性、精神力、粘り強さ、リーダーシップなど)

このプロセスを仕組み化できると強そうだなー。

問題解決スキルと問題解決リーダーシップ

  • 問題解決スキル(MECE、ロジカルシンキング、仮説思考、フレームワークなどを使って問題を整理・分析し、解を見つけるための技術)
  • 問題解決リーダーシップ(課題の定義から、分析の設計、関連する組織や人とのコミュニケーションを含む一連の問題解決プロセスにおいてリーダーシップを発揮すること)

スキルは書籍とかネット上に転がってそこから学べるけどリーダーシップは実践が必要なのよね。

リーダーとマネージャーとコーディネーター

  • リーダー(成果達成のために必要な役割)
  • マネージャー(管理のために必要な役割)
  • コーディネーター(交渉を仲介する役割)

リーダーとマネージャーは別物だけど、マネージャーにリーダーシップも求められることが多いよね。

リーダーシップは全員に必要

  • リーダーは組織に一人いればいいというのは間違い
  • 全員が自分にできる範囲のリーダーシップを発揮する

これがこの本のなかでは一番刺さったところですね...!! 組織全員がリーダーシップを発揮すればものすごい価値を生めそうだ。

リーダーがすべき4つのこと

  1. 目標を掲げる(チームが目指すべき意欲的なゴールを定義すること)
  2. 先頭を走る(マラソンの先頭グループやファーストペンギンの大変さを理解し、失敗したときのリスクや責任に覚悟を持つこと)
  3. 決める(必要な情報が揃っていなくても決断し、物事を前に進めること)
  4. 伝える(まったく同じ人間はいないということを理解し、自分の考えを言葉で伝え続けること)

伝える、とかは見落としがちだけどまさにって感じ。

リーダーシップキャパシティ

  • 組織全体でのリーダーシップの総量のこと
  • 現状を変えるために必要なのは、スーパースターなどではなく、組織のあらゆる場所で、目の前の変革を地道に主導するリーダーシップの総量を増やすこと
  • リーダーシップキャパシティが不足すると、例えば非常時対応が困難になる

このあたりもビビっときた。とくに非常時対応、プロダクト開発においては障害対応を容易にイメージできた。

役職思考とリーダーシップ

  • 問題があったときに「それを解決するのは誰の役割(責任)か」と考えるのが役職思考
  • 問題があったときに「こうやったら解決できるのでは?」と考えるのがリーダーシップ

結構役職思考で考えるときあるので意識したい。

リーダーシップはスキル

  • リーダーシップの実践を繰り返し小さい成功を積み重ねながら成長していく
  • 徐々に自分が解決できる問題が増えたり影響を及ぼせる範囲が広がる

自分にできる範囲からやっていくぞ٩( ᐛ )و

(未解決)既存プロジェクトでXcode PreviewsにUIが表示されないのでワークアラウンドを試している

iOS #2 Advent Calendar 2020

本当は解決したら書こうと思ったのですが、年を越しそうだったので現状のメモとして記しておきます。

環境

  • Xcode12.0
  • Swift5.3
  • .swiftファイルが700程度あるプロジェクト
  • Build PhasesでSwiftLint, swift-formatなどなどをRun Scriptとして動かしてる
  • Deployment Info targetはiOS12以上

事象

Xcode Previewsでプレビューが表示されない

f:id:aboy_perry:20201225110737p:plain

SwiftUIファイルはなんでも良いと思いますがテンプレートから生成後、コンパイルエラー回避でiOS13以降の修正をしています。

import SwiftUI

struct SwiftUIView: View {
    @available(iOS 13.0.0, *)
    var body: some View {
        Text( /*@START_MENU_TOKEN@*/"Hello, World!" /*@END_MENU_TOKEN@*/)
    }
}

struct SwiftUIView_Previews: PreviewProvider {
    @available(iOS 13.0.0, *)
    static var previews: some View {
        SwiftUIView()
    }
}

メモ

エラーとワークアラウンド

Updating took more than 5 seconds

f:id:aboy_perry:20201225113324p:plain

プレビュー表示の際AppDelegateの application(_:didFinishLaunchingWithOptions:) を通るらしいので、たしかに結構処理が書かれていたので中身を起動できる程度にほぼほぼコメントアウト

ref https://koze.hatenablog.jp/entry/2020/03/09/090000


Automatic preview updating paused

f:id:aboy_perry:20201225113601p:plain

Run Scriptが悪さしてるかもとのことなのでBuild PhasesのRun Scriptのうち起動できる範囲(SwiftLintやswift-formatなど)の「For install buids only」にチェック。

ref https://stackoverflow.com/questions/58490010/swiftui-automatic-preview-updating-paused-always


Cannot preview in this file - Connection interrupted: send previewinstances message to agent

なんかfirebase-ios-sdkが悪さしてる説があるのでバージョンアップしてみる(ただ前段でdidFinishLaunchingWithOptionsの処理をコメントアウトした際にFirebaseApp.configure()もコメントアウトされている)。

f:id:aboy_perry:20201225113957p:plain

ref https://developer.apple.com/forums/thread/662370

ref https://github.com/firebase/firebase-ios-sdk/issues/6574


RemoteHumanReadableError: Connection request timed out

f:id:aboy_perry:20201225114059p:plain

よし、ワカラン


いったんフォーラムで見つけた策を試してみる。 Build Active Architecture Only をNOにして、 Excluded Architectures に arm64 を指定。

変わらず。

ref https://developer.apple.com/forums/thread/657913?answerId=628433022#628433022

というわけで未解決です

同じ問題にぶつかったぜ〜という方や、もし「これじゃね?」と知ってる方がいたら情報お待ちしております 🙏