golang.tokyo #31(7/30) 参加メモ
golang tokyo
golang tokyoとは
- goを導入している企業のメンバーが集まり、普及を推進するコミュニティ
- オフラインでは頻繁にやってたが、オンラインになって久しぶり
- 今後もオンラインイベントを予定中
- 今回の内容はlogmiに後日記載される
1. httpルーティングライブラリ入門
- ISID(電通国際情報サービス) 宮原さん
- Goのルーティングライブラリってどう動いているのか、実際に実装してみて理解したことを共有
Webアプリケーションで使うライブラリ
Default Serve Max
- net/http ライブラリ
- 標準で使えるやつ
-
- routerとかが他の言語のルーティングと似てる
- パスパラメータを取得可能
-
- gorilla-muxに書き方は似てる
- パスパラメータを取得可能
共通点
- ハンドラの登録
- 呼び出しの登録
- 今回はこれらを行うのがHTTPルーティングライブラリとする
実際に作ってみた
- TinyRouter
- パスベースルーティング
- パスパラメータの取得に対応
- gorilla-muxの実装を参考
実装の概要
ベンチマーク
結果
- chiが遅い
- 比較回数が多い
- 基数木を用いるため
聞いた感想
- ルーティングの仕様はなんとなく使いながら理解していたけど、実装の内容を聞くと意外とシンプルなんだと思った。
- chiが遅くなった点について深堀りして欲しかった
- 木構造なら、エンドポイントの数がさらに増えた時にパフォーマンスが良くなる？
2. フューチャーのとある案件でGoを使ってみて実際のところ
リーダー視点でGoの良い所
- リーダー = 技術選定や処理方式の選定にメインで参加し、開発上の責任を持つ人
(導入してみて)良かったこと
- キャッチアップがしやすい・早い
- A Tour of Go をやればほぼ分かる
- ブラウザで動かせるので事前に勧めやすい
- 組み込みパッケージが揃っている
- A Tour of Go をやればほぼ分かる
- シンタックスシュガーが少ない
- フレームワークの差異がすくない
- コードの互換性が高い
- 適度に隙がある
- 小さいツールとか作りやすい
(技術選定で)困ること
実際の声
- コードが追いやすい
- リフレクションとか少ない
- 先達のコードをコピーしやすい
- 成功体験(コミット)を与えやすい
- 新人が新しい環境で貢献したい気持ちに答えられる
- 開発環境構築からコミットまで1，2日で進める
→ 言語仕様よりもドメイン知識に注力しやすい
A Tour of Goの他コミュニティからキャッチアップがしやすい
発展途上の点があって、初心者でもネタを公開しやすい
- メンバーの成長が実感できる
- 会社として外部露出のプラス
- 新しく参加した人が先達になる正のサイクルがまわる
Goでの開発の工夫編
プロキシ環境
WebAPI
- デファクトがないので採用技術はバラバラ
- ナレッジは他でも生きることが多い。(だいたいnet/httpのラッパーにすぎない)
- ポリシーに応じて選べる
AWS Lambda
多用途向けのシングルバイナリ
バッチアプリ開発
Webとバッチ処理のパッケージ構成をなるべく揃えておくと効果的
非機能面での注意点
- 1行ずつログを出さない
- 冪等な処理になっているか
- 未着チェック
- 起動時間になっても必要な物がない場合のエラー処理がなっているか
- ジョブの多重起動処理防止
- 部分取り込みを許容する場合に中断する方式になってないか
- リカバリ・再起動がしやすい設計か
テスト・品質
テーブルドリブンテストが有名
- テストコードが長くなりがち
- 正常系・異常系をテスト関数自体を分ける
- テストコードが長くなりがち
品質
- カバレッジをとる
- 注意：他の言語に比べ低くでがち
聞いた感想
- 前半のリーダー目線でのGoの導入に関する話は興味深かった。
- 研修で学ぶ言語と、実開発での使用言語との導線は考えるべき点と思った。
- 後半のGoの開発の工夫は、広範囲の内容で役立ちそうと感じた。
- せっかくの勉強会なのでひとつを深堀りしてみてもよかったとは思う。
3. 生産性の壁を突破しろ！ -Excelizeとjenniferによるコード自動生成-
ISID 佐藤太一さん
生産性 = コード生産量/ プログラマの人数×労働時間
- コードの品質が同じならば、量が多い方が生産性は高い
自動生成でコードを作成できれば、生産性が大いに向上できる
自動生成に向くコード
- 条件分岐が少ない
- データ構造が繰り返し
- 処理構造が繰り返し
自動生成のコードは書くこと自体が難しくなりがちなので、生産性があがる内容に適用していく
具体的な自動生成対象例(ドメイン駆動設計の用語)
- ValueObject
- Entity
- Repository
- SQLをそのまま使えるように
- GORMはパフォーマンスのネックになりやすいから使わない
自動生成ツール設計
生成物
- 自動生成コードの実装 → スライド参照
聞いた感想
- 自動生成のメリットと実装の具体例が挙げられていて、すごいと思った。
- Goで自動生成を実装するメリットとかを聞きたかった感
- コードの生産性という意味では、もっとパッケージ化されたtoBサービスを使いまわすとか、NoCodeで実装するとか手段は色々あるような気がする
4. Goで認証プロキシをつくってみた
悩み
- Goは認証仕組みが少ない
- 自前で毎回作るのは面倒
- 開発開始は認証なしで後から追加するのは難しい
- ローカルの認証が遅くて認証に時間かかる
要件
認証を強くしたい
良いライブラリがないので自作する！！→ wru
実装
- シンプルに作るために割り切る
ユースケース(本番環境)
- リバースプロキシとして動作
- OAuthとかOpenIDConnectのプロバイダーを複数同時利用可能
- ユーザ情報はcsvで読み取り
- オンメモリで持つ
- セッション情報は永続可能なストレージに保存
ユースケース(開発環境)
- リバースプロキシとして動作
- ユーザは登録一覧から選択
- ユーザー情報は環境変数から読み込む
セッション情報は温メモリ
セッションストレージ
- クッキーのようにサーバーからヘッダーで設定できる
Goっぽい話
- パラメータは環境変数からのみ取得
- envcofigを利用
- リバースプロキシ httputil.ReverseProxy
- ルーティング chi.Router
- ストレージ
- gocloud.dev
- 画面テンプレート
- go;embed
聞いた感想
- 認証認可についての理解がまだまだだと感じた。
- このライブラリの実装自体には2週ほどで作ったそうで凄いと思った。
- こういうライブラリって使ってみないといまいち理解が進まないと思っている。
セッション後の雑談
Goのモジュールにまつわるセキュリティ
ちゃんとメモしてなかったので気になる人は後日でるであろうLogmi Techの記事を参考にしてください。
全体の感想
- 久しぶりの勉強会聴講で、テーマも興味があるものでよかった。
- 各セッションの合間が短くて質問をする余白がなかった気はする。
入門Go言語仕様輪読会 2/18メモ
入門Go言語仕様輪読会 2/18
概要
Defined type:Nobisii
defined type 仕様書を読んだり、輪読会で議論するときに便利な概念
Goの型: defined type とそうでないものに分けられる(そうでないものに対する名称はないらしい)
defined typeのもの 1. 型定義によって宣言されたもの 2. 事前宣言されたもの(bool int など)
そうでないもの＝全て型リテラルで表されるもの、合成型
defined type を知ると分かること
- 型の同一性
- 代入可能性
- convert可能性など
型リテラル
型リテラル：8種類
SliceType
ArrayType
PointerType
MapType
InterfaceType
StructType
FunctionType
ChannelType
型定義による型宣言
type NewType SomeType
package main type S []int // defined typeでない type T int // defined type // int はdefined type
値xと型Tの関係性 Convert可能 代入可能 型が同一 この説明にdefined typeを使う
composite type // defined typeでない?<=微妙に議論がわかれる
type aliasは導入の型次第
type I1 int // defined type type I2 = int // defined type type I3 = []int // defined typeでない // type alias はメソッドを定義できる、型を置き換えして把握
型宣言のメリット
type A []int func (A) Sum() int { // メソッドをつけられる } // 代入をできないようにする:意味分けをする、エラーコードの分類など type A int type B A func main() { var a A var b B a = 1 b = 2 a = b }
Underlying types DQNEO
underlying
- 何かの下に横たわる
- 今回は背後霊ととらえる
なぜ重要なのか
- 代入可能性の条件に使われる
- Genericsで重要な役割
type MyInt int //MyIntのunderlying type はint
全ての型にはunderlying typeがある
int のunderlying type はint
3つのルール
- 1 事前宣言されたbool, string, numericのunderlying type は自分自身
- 2 複合型、型リテラルのunderlying typeは自分自身 struct{}
type User struct{ a int name string }
- 3 派生型、underlying typeの遡り 型のヒエラルキーがない
Methodの継承
- interface型: 継承される
- underlying typeで判断
なぜヒエラルキーがない？ → Goの誕生時に、大きいプログラムでは、木構造で型の継承関係を整理するのに時間がかかっている。型システムをクリアに保つ。型の階層がなくてもオブジェクト指向はできる
型を直接共有する
type ( B1 string B2 B1 B3 []B1// []B1, []B1, []B1 B4 B3 )
stringから[]byte,underlying typeが違うがconversionできる conversionのルールには使われる underlying typeが同じ場合は変換できる(十分条件)
sliece と underlying array サイズの大きさが違う、違う概念
type Slice struct { ptr *byte // <- underlying array len int64 cap int64 }
error型のルール
type error interface { Error() string }
代入可能性
type MyInt1 int
type MyInt2 int
func main() {
var i1 MyInt1
var i2 MyInt2
i2 = 99
i1 = i2 // コンパイルエラー
}
循環参照はそのままコンパイルエラーにできるのでそこではじく
LPF REV UP 2020(11/14)東京セッション参加メモ
LPF REV UP 2020
ABOUT
LPF REV UP 2020は普段LINEのAPIに関する勉強会や情報交換を行っている東京、関西、九州のコミュニティが合同で主催するカンファレンスです。2020のテーマは「開発者と共に。ユーザーを支えるLINEプラットフォーム」。
LINEの認定するLINE API Expertやテクノロジーパートナーを中心に、ミニアプリ、Messaging API、LINE Pay APIなど技術に関するセッションからwithコロナ時代に生まれている新しい体験やビジネスについてのセッションまで、幅広い内容のセッションをご用意しています。
LINE platformの目指すもの
- LINEはコミュニケーションアプリを中心にしつつプラットフォームを展開し、世界中の人と人、人と情報・サービスの距離を縮めることを目標として掲げている
- その為の大きな施策としてミニアプリの提供がある。
- ミニアプリはネイティブアプリとLINEAPIの活用のいいとこどりをできる
- その他、自治体との連携やLINEマーケットプレイスの提供、LIFFにおける広告マネタイズなど要望を受けながらプラットフォームの改善を図っている
ミニアプリ as a Service。-順番待ちソリューションのミニアプリ対応とグロースの軌跡
- LINE Messaging APIをつかった店舗順番待ち予約システム matocaの開発・販売について
- matocaはSaas型のLINEアプリ=出来上がったサービスとして提供し、契約したらすぐに使えるような体制
- 現在はMessaging API版とミニアプリ版がある
- ミニアプリ移行後LINE利用率が倍に、新型コロナの影響でサービス導入が増えた
- 実際に開発提供してみてミニアプリのいけてないポイント3点
LINEミニアプリではじめる日本のOMO
- OMOって何か？
- オンライン・オフラインを区別せず一体のジャーニー体験として捉え、これをオンラインの競争原理から考える
- ユーザが置かれた状況で、一番便利な手段を選択できること
- LINEのミニアプリはOMOを実現するのに現状の最適解
- LINEの普及率
- サービス連携がしやすい
- 利用ハードルが低い
- ネイティブアプリはコアなカスタマーが多く、ミニアプリはライトユーザへのリーチが高い傾向
- LINEを使った事例：CAFEモバイルオーダー(CX ORDERを利用)
- 数値、声で良い反響があった
通販で活用するLINEログインとMessaging API
- 主にアパレル系ECに向けたLINEサービスの提供について
- Reply型のBotはなかなか浸透しない。話題性はあっても売り上げに貢献しにくい。
- 収益を挙げるには、PUSH通知を効果的に使うと良いが、通常のWebのECサイトはLINEアカウントとの連携にハードルができてしまう。
- MessagingAPIでLINEログインを実現すると友達追加を自動的にできる。
これまでのサービスに新しい価値を！LINEからはじめる新たなUI/UX
- Messaging APIで単なるチャットボットを超えたコミュニケーションベースのアプリが作成可能である
- Messaging APIでUI/UXを実現するAPIの紹介
- デモ：ボランティアとボランティアを必要としている人をマッチングサービス
あなたならどう使う? 最新Azureレシピ for LINE Platform
- LINE APIとかけ合わせるのにつ使えるAzureの各種サービスの紹介
- 量が多いのと、テキストで逐一書くと長くなるので、スライド参照→スライド
- Q&Aを生成するCognitive Serviceや画像に写っている物体を認識して内容を返してくれるComputer Visionなんかは面白そう
「LINEマーケットプレイス」で実現する新たなLINE APIのエコシステム
- LINEマーケットプレイス:自社開発なしでLINEAPIと接続できるアプリケーションを提供する
- 複数アカウントの管理を可能にする専用のチャネルの提供する。複数のLINEアカウントを単一で管理することが可能できる
- LINE APIは一部違う所があるが、チャットベースのアプリケーションなら大体できる
- プラットフォーム利用料 利用料固定=月1万円 利用料=アプリの販売金額の20％
- 販売金額 3000円～10,0000円月額のみ
全体の感想
2019年のよかったもの
2019年よかったものを紹介します。何かの参考になれば幸いです。
アプリ部門 トリセツ
主に家電・ガジェット周りの取説を一元管理できるアプリ。
普段から読むわけではないが、いざという時にないと困る取扱説明書を管理できる。
家電の型番とかもまとめておけて、とても助かる。
Twitterで流れてきて使って見たのがとても良かった。
デバイス部門 Anker Soundcore 2
- 出版社/メーカー: Anker
- メディア: エレクトロニクス
防水のBluetoothスピーカーで、安価。
BluetoothなのでPC、タブレット、walkmanと接続して使っている。
風呂でゆっくりとした音楽が聞けるのが良い。
形がシンプルな直方体なので、立てて置くこともできる。
有線の安いスピーカーがやたらノイズを拾うので、Bluetoothスピーカーを買おうと探して値段の安さと評判の良さを見て買ったのがきっかけ。
漫画部門 BEASTARS
2019年の冬アニメにもなっている話題作。
作品の存在は昨年の時点でも知っていたのだけれど、Kindleでセールのときにまとめて買って読んだ。
草食・肉食動物が共に暮す世界で、主人公レゴシの己の欲望と倫理観の葛藤がとてもよく描かれている。
作画は近年の傾向と逆でアナログであり、ならではの荒さが特徴だと思う。
オススメ。
来年も良い買い物ができますように。
iOSDC 2019に参加した感想(2日目午後TrackE)
はじめに
2019年9月5~7日にかけて行われた、iOSDC2019に参加しました。
iOSDCとはiOS関連技術をコアのテーマとした技術者のためのカンファレンスです
2日目午後TrackEで聞いた発表の感想をざっくりと書いていきます。
目次
実践 CallKit/PushKitときどきバグ退治
本日の登壇資料こちらになります🙂
— ものくろ (@monoqlo) September 7, 2019
（一部登壇用で見づらい部分があるので後で上げ直すかもです）#iosdc #e
実践 CallKit/PushKit ときどき🐛退治https://t.co/ZVyv1CbRjF
概要
通話機能実装の必要性 : タクシー配車サービスにおいて、ユーザとタクシーを引き合わせるときに、詳細の情報伝達を素早く行える通話が必要。
この機能を構成する一部 : CallKit, PushKit, Twilio
- CallKit : 電話っぽいUIと周りの機能を実現するフレームワーク
- PushKit : VoIP電話に最適な通知ができるフレームワーク
- Twilio : VoIP通話を実現できるWebサービス。APIやライブラリを提供
Twilioが提供しているサンプルコードを参考にするとよい。
CallKit Tips
- 動作、挙動の細かいドキュメントがないので、地道に検証が必要
- 実機でしかUIを表示できない
- あとで通知ボタン消せない
PushKit/Twilio Tips
- 証明書更新しようね
- 証明書の切り替えを忘れないように
CallKitの割り込みバグは仕様なので要対処
感想
前日6日のLTでもCallKitに関するLTがありました。CallKitがWWDCで発表されて3年ほどで、OSのバージョンの割合や開発環境が出揃って実サービスに応用されてくるようになったということなのかと思いました。
こういったAPIも含め電話機能が民主化、オープンなものになったのだと感じます。
すべての人のためのアクセシビリティ対応
資料、実はちょっとだけ削ってまして、完全版はこちらになります。そんなに変わってないかも。 #iosdc #e https://t.co/wZ59p2Lg64
— akatsuki🍶 (@akatsuki174) September 7, 2019
概要
アクセシビリティとは
- 情報・サービス(機能)へのアクセスしやすさ、到達しやすさ
- あらゆる人があらゆる環境で利用可能に (not only 障がい者向け)
ユーザビリティとの違い : アクセスできた後へのフォーカスが強い。(実際のところ、施策自体は共通集合が多いと思っている)
障がい者は思ったよりも多いし、自覚がない場合もある。(近視も本来は障害の一つではあると思う)
アクセシビリティ対応を完璧にしようと思うと、大変なので、まずは意識する所から。
既存の設定を上手く行うだけでも、アクセシビリティ向けに色々対応できる。
今後はSwiftUIで対応が楽になっていく見通し。
アクセシビリティに配慮したデザイン
- タップ領域の確保
- 複数要素を入れた見た目のデザイン
- 色のコントラスト
- 極力文字を画像にしない (解像度・文字サイズ対応)
- スタイルの一貫性
- 閃光を伴う表現を避ける
ツール・ヘルパー
- Accessibility Inspector : XCodeのアクセシビリティチェックツール
- Dynamic Type : 文字・行間を自動で調整する機能(画像も別途調整)
- ColorTester : 色のコントラストを確認するツール
- Chromatic Vision Simulator : 色覚障害者にとっての色合いを確認できるツール
- アクセシビリティ・カラー・ホイール : アクセシビリティに対応した色を選ぶツール
Siriショートカット：Siriに話しかけて実行するマクロのようなもので、複数アプリにまたがった操作も可能。if/roopも対応
VoiceOver : Appleデバイスに内蔵のスクリーンリーダー
VoiceOverに適切に読まれるには、各自適切な情報の設定が必要
iOS13でより操作可能な範囲が広がり充実する予定
SwiftUIは標準パーツでアクセシビリティ対応済み。カスタムパーツも自動で対応。
ただし、正しいコンテキストに沿った読み上げには適宜設定が必要
アクセシビリティの広がりで、より良い世界が実現する(と思う)
アクセシビリティ対応をすすめるには
- 対応の必要箇所を見つける
- デザイナーとの共有(技術的に対応できる範囲を特に)
- 社内の理解を得る (ユーザ体験の向上を具体的に)
- 対応優先度を決めて対処(主要フロー、困る順を優先
対応方法
- 標準部品を使う
- 習慣化する
感想
細かい違いはあれど、iOSに限らず、AndroidやWebでもアクセシビリティ対応に必要なことはあまり変わらないだろうと思いました。
普通の機能と違って、アクセシビリティ対応はユーザテストやフィードバックを多く受け取るのが難しいことを上手く対処できるようになるとよいと思います。
使う側も必要と感じてなくとも、本質的には必要な状況を解決できるとうれしいと思いました。
まとめ・カンファレンス全体の感想
双方向のコミュニケーションを掲げるカンファレンスだけあって、終始楽しく参加できたのがよかったです。
こういった機会でいろんな話を聞くと、開発や勉強のモチベーションが上がるので、また頑張ろうと思います。
今後は、自分も発表できるような立場になってみたいですね。
