Go Conference mini in Sendai 2026 に参加しました

2026/02/21 に開催された Go Conference mini in Sendai 2026 に参加してきたのでそのレポート。
…と言いつつ、ほぼ観光の話。

だいたい時系列順。

地方カンファレンスは当日スタッフをするべし

地方カンファレンスを最高に楽しむにはどうするべきか？それは、当日スタッフをすることである。
当日スタッフはいいぞ。当日スタッフになると交流する機会が増えるのだ。

基本的にカンファレンスでは懇親会しか交流の機会が提供されないが、懇親会はカンファレンスの最後に開催されがちだ。
でもカンファレンス前やカンファレンス中に先に知っている人を増やしておくと、楽しさがグッと増える。
当日スタッフは事前準備や当日の作業を一緒にするので、自然と交流ができるのだ。
アウェイなイベントこそ、当日スタッフをやったほうが良い。

・・・というのを「PHPカンファレンス仙台2019」で気付いてから、なるべく当日スタッフをやるようにしている。
そして、今回も当日スタッフをやらせていただいた。
sendai.go の方は熟練スタッフばかりで、迷うところもほとんどなく、スタッフ業をしやすかった。

先に観光したっていい

当日スタッフも前日準備に参加できるということだったので、前日入りする予定だった。
午後休を使えば間に合うが、何となく全休を取り、午前中を観光に充てた。

先に観光するの、めちゃ良いかもしれない。
カンファレンス後は疲れ果てていることも多く観光する気力が残っていないので、先に観光するとガッツリ楽しむことができる。

実は親の実家が仙台なので、微妙に土地勘がある。
でも親の実家近辺を観光することはなかなかないので、改めて観光できて良かった。
自分が観光したところはここ。

  • 海鮮
    • 駅内の「すし三陸前」にした。そこまで混んでいないところが良い
  • ずんだシェイク
    • めちゃ美味しかった。前に来たときは無かった気がする。
  • 村上屋餅店
    • 店主の体調不良でお休みとのこと。お大事に。
  • こけしのしまぬき
    • 東北と言えばこけし。思ったよりも可愛いグッズが多くてつい買ってしまった。刺さる人には刺さる。
  • ほそやのサンド
    • 日本最古のハンバーガーショップらしい。ミートパティが手作り感があって美味しかった。
  • 朝市
    • 朝ラーに合わせて行ったら朝ラー以外は開店準備中だった・・・

  • 仙台辛味噌ラーメン
    • これも知らなかったので体験。美味しかったけどご当地感はあまり無いかな・・・

先にお土産を買ったっていい

お土産は最後に買う感覚が強かったが、「別に先に買ってもよくないか？」と思い、初日に購入して宅急便で送った。
仙台のお土産は駅ですべて揃うので良い。駅に無いものは藤崎（デパート）に行けばある。
以下のものを買った。

  • 笹かま
    • 酒の肴用。自分はだいたい鐘崎のを買う。色々な味があるので、1つずつ購入した。
  • なすの漬物
    • 現地で食べられなかったのでお土産で買った。これも酒の肴か。
  • 白松がヨーカン
    • 大人数に配るときは最中にするけど、今回は実家に送る用だったので羊羹にしてみた。なぜか宮沢賢治の銀河鉄道の夜とのタイアップ。それは岩手やん。

カンファレンス内

Kitchen Senoue の芋煮、りんごさんの似顔絵など、企画が多くあって良かった。
地方カンファレンスだとだいたいがセッションのみの構成になっていることが多いので、別の企画も実施できるバイタリティがすごい。

スタッフ業も特に大きな問題やバタバタすることも無く、平和に進んだ気がする。
スタッフ宛ての東京土産に「菓匠三全の萩の調の東京限定味」を持っていったところ、現地の方に好評だったので良かった。

スタッフ業をしているときはセッションを集中して聞けないことが多いので、実は1セッションしか聞いてない。
kuroさんの「nilとは何か」だけとても気になっていたので聞いた。たまに見かける内容ではあるものの、改めて理解できて良かった。

また、Go初心者の方の登壇がいくつかあったのもとても良かった。
Go Conference は玄人向けのものが採択されやすい傾向があるように思うので、初心者の「やってみた」系の話は貴重だったりする。

まだまだ人口の少ない界隈だと思っているので、こういう話はもっとたくさん出たほうが良いと思っている。
これは Go Connect でも後押ししたいところ。

東北は酒がうまい

「日本酒と言えば新潟」なんて話も聞くが、個人の好みとしては東北や長野の酒が好きだ。
爽酒よりも薫酒が好きだからかもしれない。

仙台驛政宗、浦霞、伯楽星、宮寒梅、阿部勘あたりを呑んだ。

そして宮寒梅はさらに（PHPの）kuroさんからいただいたので、我が家の冷蔵庫に眠っている。
胃腸を整えたら、笹かま、なす漬けと合わせて呑むんだ・・・

まとめ

ということでGo Conference mini in Sendai 2026は最高だった。

2025年のコミュニティ活動まとめ

2025年はコミュニティ活動をがんばったのでまとめ。

カンファレンス

カンファレンス主催

PHP Sessionless Conference

https://fortee.jp/sessionless-conference-2024

初めてミニカンファレンスの主催をした。
カンファレンスというよりギャザリングやミートアップに近いもので、交流をメインに設計した。セッションみたいに「ただ聞いている」みたいなものではなく、参加者全員が主役として参加できるカンファレンスを目指した。
運営としては反省点が結構あったけど、イベントの成果としては非常に良かったように思う。
みんな朝からずっと話しっぱなしなのに、始発までずっと飲んで話してる人らがいてすごいなと思った。
イベントスタッフの人らからは「コミュニケーションシールカード」が好評だった。

コアスタッフ相当

コアスタッフや事前準備スタッフなど、当日以外もスタッフとして参加したもの。

PHPカンファレンス新潟 2025

https://phpcon.niigata.jp/

このカンファレンスの発生の経緯の都合上、スタッフとして参加。
hamacoさんやtomioさん、ariakiさんなど、カンファレンススタッフ猛者が多くいたのが特徴的だった。
スタッフ業としては本当に色々とあったけど、イベントとしてはある程度、満足のいただけるものができたようで良かった。

Go Conference 2025

https://gocon.jp/2025/

去年から引き続きでコアスタッフとして参加。
ぶっちゃけると、このカンファレンスはちょうどいい感じに手弁当感があって非常に好き。
スタッフとして非常に素晴らしい方々がいっぱいいて、特にluccaさんやbudougumiさんが話を前に進める的確な発言をしていて素敵だった。
そういう人らがある程度安定させてくれて、かつ若手な方々が新しい挑戦をしてくれていたので、非常にバランスの取れたイベントになったのではと思う。

XP祭り2025

https://xpjug.github.io/xp2025.html

去年から続いてスタッフとして参加。
アジャイル系のカンファレンス全般に感じるが、「スタッフが頑張りすぎない」という文化を持っていて非常に素敵だと思う。（言語系カンファレンスは気合と努力で押し通す傾向がある。）
締めるところをしっかり締めれば良いイベントは作れるんだなー！というのを毎年実感してる気がする。
スタッフもスクラムマスターやアジャイルコーチが多いので、話し合いも細かい袋小路に入ったりすることなくスッといくことが多い感じがする。

Go Workshop Conference IN KOBE 2025

https://gwc.gocon.jp/2025/

とても紆余曲折のあるスタッフ業だった・・・
詳しくは書かないけど、スタートアップの苦悩ってこういう感じなんだろうなというのを感じた。
カンファレンススタッフの経験が豊富なメンバーが少なく、性善説前提で話が進むことも多々あり、結構危うい部分もあったかなと思うものの、無事に良いイベントになったようで良かった。
でも、ワークショップが楽しいし身になることがこのイベントで少しは広がったのではないでしょうか。セッションもいいけど、セッションばっかりやってもね・・・もっと色々なカンファレンスでワークショップが取り入れられる世の中になってほしい。

当日スタッフ

コアスタッフではなく当日に参加したもの

PHPカンファレンス 2025

https://phpcon.php.gr.jp/2025/

実は初めてトラック担当をした。台本を運用可能な状態にしたり、シフトを決めたり、当日以外の作業が多く大変だった記憶。

PHPカンファレンス関西 2025

https://2025.kphpug.jp/

deroさんの部下になって音響まわりを担当。音響は大変・・・！！

一般参加

スタッフをせずに参加したもの。

Gopher's Gathering

https://connpass.com/event/329963/

sivchariさんやkaramaruさんと遅くまで飲んだり、はてなの方々にとてもお世話になった記憶。
特にTL上でだけ認知していた今日の三井君さんと初めてご対面できたのが良かった。

PHPerKaigi 2025

https://phperkaigi.jp/2025/

PHPerKaigiは楽しいので毎年参加してるけど、ほとんでセッションを聞いてないかも。知り合いと話したり、思いついたことをコードにしてみることに時間を使ってる気がする。k1LoWさんとちゃんと話したのはここが初めてかも。ナチョス美味しかった。

Kotlin Fest 2025

https://2025.kotlinfest.dev/

「Kotlinなんもわからん勢」として、今年も引き続き参加。Kotlin/WASMに未来がありそうに感じて、AIくんにコード書いてもらって試してた。

TinyGo Conference 2025

https://conf.tinygo-keeb.org/2025/

オープニングをきいて、はんだづけをして、ランチを食べて、はんだづけをして、LTとクロージングをきいて終わった。
TinyGoに見せかけたはんだづけのカンファレンスだった。

開発生産性カンファレンス2025

https://dev-productivity-con.findy-code.io/2025

ケント・ベックにサインもらえたし、ジーン・キムと直接質問できたのでファンサ満足度が高かったものの、スタッフの質はもう少しどうにかならんのか。（サテライト会場で雑談すな）

勉強会

主催

PHP勉強会@東京

計13回実施。（体調不良などで参加できていない回あり）
今年はついに「PHP勉強会@東京in関西」が実現したのが良かった。
他イベントのコラボ、楽しいと思うのでもう少し考えていきたい。

Go Connect

計8回実施。
そろそろワンオペではなく他のスタッフも募集したい。1人でもいいんだけど、1人だと僕の都合で開催できないことが多いので。

PHPer x 日本酒の会

計3回実施。
単発で終わるかなと思ったら意外と四半期に一回やってる。
このイベントは「いかにゆるふわにできるか！！」なので、当日のノリで決めることも結構多い。

一般参加

  • 企業勉強会 計9回
  • Asakusa.go 計1回
  • Funabashi.dev 計1回
  • golang.tokyo 計4回
  • Kyoto.go 計5回
  • PHP Lovers Meetup 計1回
  • PHP勉強会in新潟 計1回
  • 技術倶楽部 計1回
  • 渋谷（桜丘）でもくもく会 計3回
  • もくもく会@池袋 計1回

行きすぎ！！

登壇など

カンファレンス登壇

  • PHPカンファレンス関西 2025（パネルディスカッション）
  • Go Conference 2025（ワークショップ）
  • Go Workshop Conference IN KOBE 2025（ワークショップ）

勉強会など

SpeakerDeckにあがっているもので6件（あげてないものもいっぱいあるはず）

まとめ

今年は頑張りすぎたので、来年はもう少し落ち着かせたい。

ホスピタリティを捨てろ

この記事は 技術イベント・カンファレンス運営のノウハウ（2枚目） Advent Calendar 2025 の記事です。1日目が空いていたので、今さらながら埋めます。

今年は多くのコミュニティイベントにスタッフとして参加しました。また、コロナ禍前からカンファレンススタッフとして細々と活動しています。そうした経験の中で重要だと感じたのはユーザーコミュニティのイベントでは「ホスピタリティを捨てろ」ということです。後述しますが、企業コミュニティではホスピタリティを追い求める戦略は有効に思います。

ホスピタリティとは

いわゆる「おもてなし」というやつです。参加者のことをねぎらい、不便なく快適に過ごせるように、スタッフがあれやこれを行い、参加者に無駄な手間をかけさせないことを指します。

なぜホスピタリティを捨てるべきなのか

いくつかの理由があります。

自分が気持ちよくなっているだけでは？

なぜ多くのスタッフはホスピタリティを持ってカンファレンス運営を行うのでしょうか？
深堀りして内省すると、「自分がそうなりたいから」「親切な人だと思われたいから」「感謝されると気持ちいいから」といった理由にたどり着くように思います。

もちろん、スタッフが気持ちよく作業をできるということはとても重要なことです。ですが、ホスピタリティという言葉とは裏腹に、動機は参加者のことをあまり考えていないことが多いのではないでしょうか。

線を引いて分断する

ホスピタリティを発揮するとどうなるでしょうか？おそらく結果的に、「私はサービスを提供する人です。あなたはサービスを受ける人です。」といったような、わたしとあなたは違う立場ですよという線を意識させる行為になります。

さて、我々エンジニアは線を引くことについて危機感を持たねばなりません。ソフトウェア開発の歴史では

  • 開発と運用を分ける
  • 設計する人と実装する人を分ける
  • ビジネス部門とIT部門を分ける

というようなことを行い、大失敗を繰り返してきました。こういった線を引くことの有害性は徐々に認識されてきています。昨今では、役割の境界を意図的に曖昧にし、価値提供までの一連の流れをワンチームで行うことが一般的です。

では、ホスピタリティを発揮して、サービスを提供する人とサービスを受ける人の間に線を引くのはなぜですか？線を引くことにより、どのような有益性を得られ、どのようなユーザー体験を実現できますか？

専門的なスキルである

世の中の職業には、ホスピタリティを提供する職業があります。例えば高級料理店のホールスタッフや、遊園地のキャストなどが当てはまります。彼らはホスピタリティを発揮することで収入を得ていると言っても過言ではありません。言うなれば、高いホスピタリティの提供とは、エンジニアリングと同じように、専門的なスキルであるということです。ホスピタリティについての知識や豊富な経験なしに、高いホスピタリティを提供することは難しいでしょう。

よって、ホスピタリティに重点を置くのであれば、金銭で解決したほうが良いです。つまり、プロのイベントスタッフに依頼したり、クロークサービスや飲食提供の付いた会場を選定することで、より高いホスピタリティを実現できます。ですが、ユーザーコミュニティでの草の根カンファレンスでは、こういったことに金銭をあまりかけられないのが実情です。ですので、高いホスピタリティを提供するのは、ユーザーコミュニティのカンファレンスよりも、比較的に予算を注ぎ込みやすい企業カンファレンスのほうが得意でしょう。

代わりに求めるものは

では、ホスピタリティを捨てて、我々は何を求めるべきなのでしょう。僕は「一緒にカンファレンスを作り上げる体験」を提供することが重要に思います。

具体的な例を見ていきましょう。

勉強会でよくある光景として、セッションをした後に飲食込みの懇親会を行うことがよくあります。このとき、セッションが終わったタイミングで懇親会の準備が終わっていないことが稀にあります。この場合、どうするべきでしょうか？

ホスピタリティの高いイベントの場合、参加者の手間をかけさせないためにスタッフで懇親会の準備を行います。この間、参加者は準備が終わるのを待つ流れになります。ですが、待つというユーザー体験は得てしてあまり良くないものです。暇ですからね。手間をかけさせないために良くない体験を提供してしまいます。

代わりに、参加者に一緒に準備を手伝ってもらうのはどうでしょうか。参加者に手間をかけさせるわけです。ですが、よく考えてください。「手伝ってください！」と言われて嫌な気持ちになりますか？実際はあまりならないように思います。むしろ、「頼られて嬉しい」と感じる人のほうが多いでしょう。

また、共同作業はコミュニケーションのきっかけとしてとても良く機能します。エンジニアはコミュニケーションが苦手な方が多いです。そして、コミュニケーションが苦手な人にとって「話題を探す」というのは難易度の高いものです。見ず知らずの人を相手にしたときに、話題を必死に考えて「今日はいい天気ですね」と声をかけるよりも、「机の反対側を持ってもらってもいいですか？」と声をかけるほうが圧倒的にラクですよね。そして、一度コミュニケーションを取ってしまえば、再び話しかけることは最初に話しかけるよりも簡単なことが多いです。

また、一緒に何かを成し遂げるという体験は、良い体験になりやすいです。成し遂げる内容が容易だとしてもです。

ホスピタリティの捨て方

では、具体的にどのようにすればホスピタリティを捨てられるでしょうか？
僕自身が主催したミニカンファレンスである PHP Sessionless Conference （以下ピセカ）では以下のようなことを行いました。
これらを行うことによりホスピタリティを捨てられ、全体的にユーザー体験や満足度が高まったように感じます。

当日スタッフチケット

ピセカは有料イベントでしたが、一般参加と同じように当日スタッフチケットを有料で販売しました。

なお、各スタッフのチケットの内容は以下のようになっています。

一般チケット
一般参加者として参加するためのチケットです。

当日スタッフチケット
一般参加者としてだけでなく、カンファレンスの設営や撤収にも携われるお得なチケットです。

やりがい搾取みたいな内容ですね。
このようになるべく一般参加者とスタッフの条件をなるべく揃えることで、参加者とスタッフの間に無意識に線を引くことを低減させています。お金を払うことで、「自分はスタッフでもありつつ、客でもあるんだ」と意識できます。なお、当日スタッフだけでなくコアスタッフも有料にしていました。

スタッフマニュアルへの明記

無意識への働きかけでは効果は薄いので、ちゃんとスタッフマニュアルに明記をすることで意識的にも働きかけました。

以下はスタッフマニュアルからの引用です。

（当日スタッフは設営と撤収をメインとした募集ではありますが）スタッフは参加者から質問がきたりすることもあるかと思います。その際は、以下のマインドセットを持っていただけると嬉しいです。

  • ホスピタリティを捨てる
    • 「おもてなしをする心」はもてなす側ともてなされる側という線を引いてしまうので、家に置いてきてください。
  • 代わりに共創の精神を持つ
    • 参加者と一緒にカンファレンス作り上げることを念頭においてください。

例えば参加者が困っていたときに「代わりにやる」ではなく「一緒にやる」という選択肢を取れると良いと思っています。

背中を見せる

文章だけ書いても普段の行動に呑まれてしまうのが人間なので、率先して自身で行動する必要もあります。例えば

  • 少しでも手が空いているときは率先して参加者に話しかける
    • 参加者と同じように会話をすることで、相手との垣根を減らし、会話をしていい、したほうがいい空気を醸成させる
  • 参加者と一緒に撤収する
    • 机や椅子の片付けは共同作業をしやすいので、司会から参加者にも手伝うように伝える

まとめ

ホスピタリティを捨てるのは、マインドセットを変えることに近いので、簡単なことではありません。
ですが、相手のことを深く考え、思いやると、「何かをやってあげる」という行為はあまり相手に良い体験を与えません。
何かをやってあげるのではなく「一緒に作り上げる」ことを重視すると、スタッフも参加者も幸せになると思います。

duck typing がわからんので調べてまとめる

「Goはダックタイピングだよ」と言われるケースをちょくちょく見かけたものの、本当にそうなの？となっていたので調べた。ここらへん、実はPHPがとても良い例になりそうなので、GoとPHPのコード例を出していきます。

Nominal Typing

まず一番わかりやすいものから。その型であるとするには、「その型だよ」と宣言する必要があるというもの。PHPやJavaが採用している。

例えば、「にゃーんと鳴く」という猫インターフェースを定義する。このとき、ツイッターで「にゃーん」と鳴いているエンジニアおじさんを区別できるのが Nominal Typing 。

PHP は Nominal Typing を採用している。

<?php  

// Iterator型と認識される  
class CharacterIterator implements Iterator  
{  
    // ...  
}  


// Iterator型と認識されない  
class CountIterator  
{  
    // ...  
}

Go は 後述する Structual Typing を採用しているので、Noming Typing ではない認識。

// Stringer を宣言していないが Stringer である  
type MyULID struct {  
    // ...  
}  

func (u MyULID) String() string {  
    // ...  
}

structural typing

その型がインターフェースの形をしていれば、そのインターフェースを満たしていると見做すもの。GoやTypeScriptが採用している。

例えば、「にゃーんと鳴く」という猫インターフェースを定義する。このとき、Structural Typing ではツイッターで「にゃーん」と鳴いているエンジニアおじさんも猫であると見做す。

Goは structural typing を採用している。上述のコードを再掲。

// Stringer を宣言していないが Stringer である  
type MyULID struct {  
    // ...  
}  

func (u MyULID) String() string {  
    // ...  
}

PHP は structural typing は採用していない。以下のコードの MyULID は toInt() を実装しているが、 Intable とは見做されない。

<?php

interface Intable  
{  
    function toInt(): int;  
}  

// MyULID は Intable ではない  
class MyULID  
{  
    // ...  

    public function toInt(): int  
    {  
        // ...  
    }  
}  

function output(Intable $i) {  
    echo $i->toInt();  
}  

$id = new MyULID();  
output($id); // 型エラー

duck typing

変数や値がそれを呼び出し可能であれば、それを呼び出せるというもの。PHPやRubyが採用している。

例えば、$cat に meow() というメソッドがあれば、meow()を呼び出せるというもの。

PHPは duck typing を採用している。下のコードは mixed 型の変数から meow() を呼び出しているが、meow()が存在していれば実行できるし、存在していなければエラーとなる。だが、少なくとも型チェックは通過する。

<?php

function getMeowable(): mixed  
{  
    // ...  
}  

$meowable = getMeowable();  
$meowable->meow();

Go は duck typing ではない認識。以下のコードは meowable が Meow() を実装しているにも関わらず、コンパイルエラーとなる。

type Meowable interface {  
    Meow()  
}  

// Cat は Meowable  
type Cat struct{}  

func (c Cat) Meow() {  
    // ...  
}  

func getMeowable() any {  
    return Cat{}  
}  

func main() {  
    meowable := getMeowable()  
    meowable.Meow() // コンパイルエラー  
}

まとめ

typing PHP Go
nominal o x
structural x o
duck o x

nominal typing であり、 duck typing である PHP が少し異例な気がしてきた。

GoConnect#3 レポート

「Go Connect #3」を10/23に開催しました。

https://gotalk.connpass.com/event/331992/

データ

参加者

概要 人数
申込者数 24人
参加者 17人
キャンセル済み 7人
無断キャンセル 0人

参加率は71%でした。
無断キャンセルが無いことはありがたいですね。

アンケート結果

今回は初めて「普通」と回答された方がいらっしゃいました。
この人にとって楽しいイベントになるように改善していきたいですね 💪

ふりかえり

良かったこと

名札

前回の #2.1 から始めている取り組みですが、名札を準備しました。
おかげで、自己紹介がラクだったのではないかな？と思います。

なお、名札の準備はその日の昼休みが消し飛んだりするくらいには大変です。
ただ、リピーターの方の分は前回のを使いまわして少しでも省力化を図っています。
ということで、自分のためにもリピーターを増やすために頑張っていかねばなりませんね。

最初の飲み会の輪

たまたまなんですが、最初に飲み物が置いてある場所を囲って飲み会の輪ができていたのは良かったですね。
勉強会の最初の「1人でさみしくPCを眺める時間」を撲滅したいと常々思っています。
再現性があるか怪しいので、どうにか再現方法を見つけたいところ。

アフター飲み

convtoさんがお声がけいただいたことで、4人くらいでアフター飲みが開かれました。🍻
とても楽しかったですし、アフター飲みの声掛けが自然と発生するような空気を作り出していきたい。

改善すること

参加人数の伸び悩み

前回の反省を活かして告知を定期的にやっていたんですが、あまり効果は出ず・・・
僕はGoConnectにはもっとポテンシャルがあると思っているので、もっと人数を増やしていきたいところです。
パイ的な話としても、golang.tokyoさんやAsakusa.goさんはわりと参加者確保に成功しているように見えるので、Gopherがいないというよりも、僕の広報力不足なのかなという感じです。
チャネルの洗い出しをするためにも、アンケートに「GoConnectを何で知ったか」を入れるべきかなぁ・・・

Goの勉強 低レベルプログラミング

Goの勉強をやり始めたのでメモ。
「プログラミング言語 Go」を読んでる。

  • Go言語は安全性についての特性を多く持っている。
    • 文字列の減算はできない。
    • スライスなどの組み込み型の内部への直接的なアクセスを防ぐ。
    • 関数の機械語のコードにアクセスできない。
    • ゴルーチンがどのOSスレッドで実行されているか知ることができない。
    • 変数の実際のアドレスが変わっても、ポインタで同じようにアクセスできる。
  • 背後にある詳細を隠蔽することで、Goのプログラムは移植性が高い。
  • ただし、最高の性能を達成したいなどの理由により、これらの安全性を犠牲にしたい場合がある。
  • unsafe パッケージは通常のプログラムではほぼ使われない。

unsafe.Sizeof、Alignof, Offsetof

  • unsafe.Sizeof はバイト数の大きさを返す。
    • 例えば float64 は 8 バイト、文字列は 16 バイト（2ワード）
  • コンピュータはこれらの値が適切に整列されているときに最も効率的にメモリへ読み書きできる。
    • つまり、 float64 のアドレスは8の倍数であるべき。
    • 合成型の値の大きさは、穴があるかもしれないので、フィールドの大きさの合算よりも大きくなる可能性がある。
fmt.Println(unsafe.Sizeof(struct {  
    bool  
    float64  
    int16  
}{})) // 24(3ワード)  

fmt.Println(unsafe.Sizeof(struct {  
    float64  
    int16  
    bool  
}{})) // 16(2ワード)  

fmt.Println(unsafe.Sizeof(struct {  
    bool  
    int16  
    float64  
}{})) // 16(2ワード)
  • unsafe.Alignof は必要な整列を返す。
    • おそらく、つまり、先頭のアドレスが何バイトの倍数であるべきか。基本的に1ワードよりも大きく整列されることはないので、8バイトより大きくなることはない？
  • unsafe.Offsetof はフィールドに対して構造体の先頭からのオフセットを穴も考慮して返す。
  • これらの関数は名前にも関わらず安全である。

unsafe.Pointer

  • unsafe.Pointer 型は、いかなる変数のアドレスでも保持できる特殊なポインタである。
    • 通常のポインタから unsafe.Pointer を通して値を参照することはできない。（型が不明なため）
    • 比較可能であり、ゼロ値は nil である。
  • 普通の *T を unsafe.Pointer に変換することができる。
  • unsafe.Pointer を *T に変換することもできる。
    • 結果として任意の値をメモリに書き込むことができるため、型システムを破壊する。
  • unsafe.Pointer を uintptr に変換することができる。
  • uintptr を unsafe.Pointer に変換することもできる。
    • 同様に型システムを破壊する。
  • 多くの unsafe.Pointer の値は、普通のポインタの実際の数値的なアドレスへの変換とその逆変換に関する仲介を果たす。
  • 以下のコードは引越しさせるGCの考慮が抜けているため、正しく動作しない可能性がある。
    • 2行目に到達するタイミングで変数 x のアドレスは変わっている可能性があるため。
tmp := uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b)  
pb := (*int16)(unsafe.Pointer(tmp))  
*pb = 42
  • 以下のコードは誤りである。
    • new で生成した変数はどこからも参照されておらず、すぐにガベージコレクタにより回収されるため。
pT := uintptr(unsafe.Pointer(new(T)))
  • よって、 uintptrの値はすべて「以前のアドレスを含んでいる」とし、 unsafe.Pointer から uintptr への変換や uintptr を使う操作の回数を最低限にするべきである。
    • 可能であれば、1つの式の中に含めたほうが良い。
  • reflect パッケージなどの uintptr を返すメソッドを使用する場合は、なるべくすぐに unsafe.Pointer 型に変換するべきである。

cgo を使った C のコードの呼び出し

  • 多くのパッケージが、その実装の言語に関係なく C と互換性がある API を公開している。
    • go では cgo がそれにあたる。（が、唯一ではない）
    • このようなツールを 外部関数インターフェース(FFI) という。
    • cgoを使うのは、C の API が複雑であり、かつ性能が重要である場合である。
      • API が単純であれば、Go に移植している。
      • 性能が重要でなければ、 os/exec を使って呼び出せば良い。
  • cgoは import "C" の前に書いたコメントにより、コンパイラのオプションを指定できる。
    • #include など。
    • #cgo を使うことで、Cのツールチェーンに対する追加のオプションを指定できる。
  • C.bz_stream などのように C. を付けることで、Cの API を使用できる。
  • C.uint と uint は同じ幅だが、型としては区別される。
  • Cに渡すポインタは基本的に unsafe.Pointer を使用する。
  • CのライブラリをGoに組み込むだけでなく、GoのライブラリをCに組み込むことも可能。

もう一つの注意書き

  • 高級言語は隔離層があることにより、安全で頑強、そして移植性の高いプログラムを書ける。
  • unsafe はその隔離層を通り越すため、プログラマは自分の責任で unsafe を使用する。
  • unsafe を使用すると、主に移植性と安全性でコストやリスクが発生する。
  • 可能な限り reflect と unsafe の使用は避けたほうが良い。

GoConnect#2.1 レポート

「Go Connect #2.1」を10/2に開催しました。
なお、いつものLT会ではなくOST（Open Space Technology）を実施しました。

Go Connect #2 - connpass

データ

参加者

概要 人数
申込者数 15人
参加者 7人
キャンセル済み 8人
無断キャンセル 0人

参加率は46%でした。脅威の50%切り。

アンケート結果

OSTはリベレイティングストラクチャーの1つなので、「会議の占拠」や「会議からの排除」が減るのではという仮説でアンケートを取っていました。
が、普段から喋る人が多かったという結果でした。

ふりかえり

良かったこと

無事に開催できた

僕も人生で2回目のOSTだったので、無事に開催できるか不安でしたが、どうにか無事に実施できました。
また、当日と前日で「仕事が忙しくなったので・・・」というキャンセルが大量発生していましたが、どうにかOSTできるだけの人数が集まりました。

濃い話がきけた

OSTは参加者がネタを持ち込むので、運営側はその場になるまで一切どのようなテーマになるかわかりません。
が、とてもGoらしい濃いテーマが集まりました。

全員が話せていた

セッションをするとどうしても「喋る人」と「聞く人」に別れてしまいますが、OSTは全員が「喋る人」になれるのがいいですね。

改善すること

ちょっと別件でいそがしかったので、告知をさぼりがちでしたね。週1くらいでちゃんと集客したほうがいいですね。

また、OST中にコントロールしたい欲がたまに出ていたので自重が必要だなと再認識しました。
なんかスクラムマスターやってた頃を思い出しますね。