トーク

サービスの多言語化対応を推し進める時、実装方法の検討はもちろんですがそれ以前に考慮すべきポイントがいくつかあります。

どの言語をどこまで対応するのか、時刻の表記、RTLといったローカライゼーションはどうするか、設定はどう切り替えるのか、既存の直書き箇所をどう洗い出すかなど、先に知っておけば楽しく多言語化対応を進められます。

2023年8月に私が対応した事例を元に、入門編として押さえるべきポイントを話します。

サービスの安定した提供に監視は欠かせません。効果的な監視にはサービスの動向を占めす重要なシグナルが必要で、そのためには実装に立ち入って収集しなければなりません。
しかしシグナルの種類に応じて収集経路や集積先が異なったりすることもあるでしょう。ローカルやテスト実行時には柔軟に経路や集積先を変えたいこともあるでしょう。

OpenTelemetryは監視に関する概念やメタデータの仕様と、シグナルを集めるSDK, そしてシグナルを収集・送信するデーモンからなるエコシステムです。

このトークではOpenCensusやOpenTracingなどの先行プロジェクトを踏まえたOpenTelemetryの説明に始まり、本番稼動するサービスで導入し運用する際の知見をお伝えします。
あまり日本語情報の少ないCollectorのカスタムビルドやAWS Lambdaの独自拡張ビルドなどにも触れます。

毎年4月が近づいてくると、謎の美意識と焦燥感に駆られ、コードを書くことになる。あるいは、日頃役に立つソフトウェアを作っている反動なのか、もしくは意味を問うことに疲れただけかもしれないが、ノンセンスへの憧憬に突き動かされて、コードを書く。そうして4月の訪れと共に、あまり役に立たない、いや全く役に立たないソフトウェアをデプロイする。

こうして私は、この何年か、4月1日に何らかのソフトウェアを発表してきた。ただ無意味なのではおもしろくないから、せめてそこに技術を詰め込んだ。それは例えば、ジオコーディングの技術であり、文字を描画する技術であり、言語モデルの技術である。

技術を磨くことで、私たちはまったく役には立たないが、少しだけおもしろい、そういうものを作ることができる。そういうことを発表します。

プログラミング言語はプログラマの書いた通りに忠実に仕事をしてくれますが、書かれたことしかしてくれないのも困りごとです。
プログラマが表現したいこと・達成したいことと、プログラミング言語が行ってくれることの間にある溝は自明ではないものの、一方では無視できないものです。
この溝を埋め、人間にとって快適にコードを書いてくため、メタプログラミングや静的解析といったキーワードに触れつつ、これまで書いてきたものをベースにその考え方や手法について語ります。
以下のようなトピックについて触れる予定です。

• プログラマを助ける言語上の機能とエコシステム
• メタプログラミング、静的解析
• 人間のためのプログラム

企業がソフトウェアの開発を行なっていく上で重要なことに採用活動があると思います。
企業選びをする際に優秀なエンジニアと一緒に働きたいと考える人も多いのでは無いでしょうか？そんな中で、皆さんの会社はどんな選考フローでどんな採用基準を用いて選考を実施していますか？

私自身、エンジニアとして採用活動に関わり母集団の形成や、選考フローの構築、実際の面談など幅広い業務を担当し、採用活動自体がとても好きになりました。
本発表では、エンジニア採用の重要性や難易度の高さを念頭に起きながら、選考フローの構築方法や選考基準の設定、具体的な面接での問いかけ方法などのノウハウについてお話しします。

より詳細には以下のような内容をお話しする予定です:

・選考フローや面接内容の構築方法について
・選考基準を如何に設定し、それを測る質問をするか
・採用活動のフィードバックループをどう回すか

私の所属する会社では、長年 Perl を用いた開発を行ってきました。
ここ数年で Go言語 への移行を進めていますが、大量にある Perl 資産を即座に全てGoに移行することは出来ず、並行運用しながらサービスの開発を行っています。
並行運用を行うということは、それだけ運用コストが発生します。

弊社のある試算では Perl のコードを全て Go に移行しきるまでに約 10年 の期間を要するのではないかと出ており、ここまでの長期間の保守を行うことは困難さがあります。

そこで、Perl から Go の移行を加速するための、Perl XS と Cgo を用いた Go の連携や、モダンなコンテナ環境、モダンなデプロイフローの構築など
Go への移行を円滑に行えるように取り組んでいる内容をお話します。

みなさんは15年以上動き続けるPerlのアプリケーションを見たことはあるでしょうか。私の周りには、数は減りましたが、そのようなアプリケーションがたくさんあります。その多くは積極開発フェーズではなく、いわゆるメンテナンスフェーズという状態です。
このようなアプリケーションでは、例えばそれぞれのフレームワークが違うとか、最初に書いた人の個性が大いに現れているとか、同じアプリケーションでも、いわゆる"雰囲気"が違うなど、一言では言い表せないような、様々な状態になっています。
積極開発されていないため、このような状態はもしかしたら「荒れ地」に見えるかもしれません。しかし、メンテナンスフェーズにあるからこそ、見えてくることもあるのではないでしょうか。
この発表では、古いPerlアプリケーションを運用する経験において、私が考えていることを整理し、Perlに限らない提言としてお話します。

awkは、Perlとは異なり、Webアプリケーションを作ることには向かず、昨今この用途で使われることはほとんどありません。

しかし、私はawkが好きです。諦めません。gawkはTCP/IP通信と拡張ライブラリをサポートしており、すなわちWebアプリケーションをつくれます。

そこで筆者は、以下を実装したブログシステム (https://github.com/yammerjp/awkblog) をつくりました。これはawkで実装されている点を除けば、MVCパターンのよくあるWebアプリケーションです。

HTTPサーバ
HTMLテンプレートエンジン
PostgreSQLとの通信
Cookieとセッション管理
ユニットテスト
OAuthとログイン

このセッションは、awkでの実装の紹介を通して、フレームワークやライブラリに隠蔽されたWebアプリケーションのあらゆるトピックを俯瞰します。

ゴールが分かっていないプロジェクトを進めるときに「アジャイル」に進めるといいよ、というのはよく知られていますが、そのときに認識を揃えながら前進するためにどんなドキュメントが必要とされるのかはチームによって様々です。

プロジェクトを始める際にこういうドキュメントがあると楽だったよという経験談を話します。インセプションデッキ、WBS、ロバストネス分析、各タスクの解像度、曖昧さと実装者の裁量のバランス、最終責任時点、といったキーワードにピンときたら聞きに来てください。

弊社では主にスタートアップの企業に対して技術支援事業として、開発業務を行っています。

今回はtoC向けのレンタルスペースの予約サイトの開発について紹介します。
該当のサービスで基本的には1つのアプリケーションで動いているため、サービス全体が利用できない状態になった際に、
外部連携の処理もできなくなり、予約したユーザが部屋に入れなくなる可能性がありました。

そのような現象が発生した場合の影響が大きいため、外部連携処理を既存の処理とは切り離すことで、既存サービスの影響を受けることなく実行できるような改修を行いました。

以下のような内容を発表します。

• 可用性向上のためのアーキテクチャ
• 運用コストをかけないための工夫
• 無停止での移行の方法と検討した内容
• 万が一、不具合が発生した場合のロールバックの方法

OpenAIのChatGPTは、各界の注目を集めています。このセッションでは、ChatGPTプラグインの開発過程と企業間のAPI連携の将来についての実体験に基づく洞察を共有します。

セッションの内容

1. API連携の現状: 現代における企業間API連携のフローについて解説します。
2. ChatGPTプラグインの道のり: プラグインの開発からリリースまでのプロセスを、具体的な事例を交えて語ります。
3. 未来への洞察: ChatGPTプラグイン開発を通じて得られた経験から、技術の進展がもたらす可能性についての個人的な見解を共有します。
4. 企業間プロトコルの進化の展望: 近い将来、企業間のコミュニケーションにおいて予想される変化と、その影響について考察します。

対象者

• AIの進化がエンジニアの仕事に実際に与えた影響に興味のある方。

世界初のコンシューマー向け VR デバイスである Oculus Rift DK1 が登場したのが 2013 年、今年 2023 年はちょうど 10 周年にあたります。
残念ながらスマートフォンほど “当たり前” の状態まで普及していませんが、それでもメディアで見かける機会が増え “珍しい” ものではなくなってきているように感じています。

私は VR/AR/MR を総称する XR 技術が大好きです。大好きだからこそずっと XR 技術を推し続け、頭はひとつしかないのに VR HMD を何台も買い続けています。
Apple Vision Pro の発表で XR 技術は今まで以上に注目されていくはずです。XR が初めての方も Oculus Quest 2 を買ったけれど最近取り出していない方も、今改めて XR をはじめる最初の一歩の踏み出し方をお伝えします。

iPad + magic keyboardやChorme OS、Surface Goなど、タブレットとノートPCのモードを切り替えて使用できるデバイスがあります。
画面を指でタッチ操作する事もできるし、トラックパッドでポインタ操作もできます。物理キーボードを切り離してスクリーンキーボードでも操作します。

そのようなデバイスに対応したwebアプリケーションを作る場合、OSやブラウザ、ontouchstartイベントの有無などからUIを出し分ける従来の方法ではうまくいきません

このトークでは、OSやブラウザを判別せず、ユーザーの操作方法に応じてUIと機能を出し分けする方法を解説します

• スマホ・タブレット・パソコンを、「タッチ操作 or マウス操作」と「小さい画面 or 大きな画面」のマトリクスで考える
• スタイルと機能を分けて考える
• Scrapboxのwikiエディタでの実装

技術選定というのは非常に難しいと思っていまして、技術選定はプロダクト自体の未来を見据えるので
プロダクトの開発速度に大きいかつ直接影響を与えながら採用や広報にも影響を与えるので
スタートアップやベンチャーにおいての技術選定の重要度は高いと考えています。

高いのに技術選定は難しいです。例えば、自分がバックエンドが強いエンジニアだったとしてもフロントエンドの技術選定を行わないといけない場面があったり、そもそもこの技術は未来があるのか予測することは本質的には未来予測と一緒で不可能だからです。

ただ、情報を集めることで成功確率を上げたり、筋が悪い技術を選んでしまうリスクを下げることができるので
そういったことを実例をもとに話せればと考えております。

私はスタートアップやベンチャーの新規事業の中でシステムのリプレイス作業が必要な場面を何度も見てきました。
機能追加を行うたびに不具合が発生してしまったり、簡単そうな修正を行うだけでも何週間やときには何ヶ月かかるという話もよくあります

私がプロダクトを作るときはシステムリプレイスが必要ないように作ろうと決めて開発しています。
結果、今のところリリースから約4年になりますが、システムのリプレイスが必要といった状態にはなっていません。
今後、リプレイスの予定も今のところはありません。

どうすればスタートアップでも技術的負債をためずに開発しつづけることができるかといったことや、速度を優先して技術的負債をためてしまった場合の対処方法などを話せればと考えています。
このトークはプロダクト開発をいった話を軸に技術選定、チーム作りなど話題が多岐に渡る予定です。

最近よく聞かれます。「なぜKubernetesを採用したのですか？」
ネタバレしてしまうと、当時の機能でECSと比較するとKubernetesに分があった、というのが大きな要因です。
ただ、Kubernetes楽しい（楽しそう！）というのも要因としては含まれていて、
Kubernetesのがっつり運用をやってみたい、というモチベーションで入社したメンバも（私含めて）いるのも事実です。
様々な要件があるなか、「好きだから」で技術選定をするのは良い面も悪い面もありますが、
様々なツラミもある中しっかり運用できているという点ではうまくやれていると思っています。

Kubernetesの運用を始めて7年経ったChatworkインフラの今や、改めてその好きなところを振り返りつつ、
たとえば今この時点で再度技術選定できるならどうするか、といったお話もできればいいかなと思っています。

本トークはソフトウェアエンジニアとしてのキャリア設計について演者が考えてきたことを、「育児」と「スキル」というトッピングを交えて話します。

演者はソフトウェアエンジニアで、IC (individual contributor) として働いています。昔は仕事でもプライベートでもコードを書いていればそれで幸せでしたが、40代になって思うところが増えてきました。特に、家事と子育てに大きな時間を使うようになったことで、キャリアについて考えなければならないことが増えました。よって一つ目のトピックは「育児」です。

さて演者のキャリアを振り返ると、まずまずうまく行ったなという部分と、あまりうまく行かなかった部分があります。特にハードスキル・ソフトスキルの研鑽については、もっと別の道があったのではないか、これから何のスキルを伸ばしていくか、日々悩んでいます。そこで二つ目のトピックは「スキル」です。

みなさんはPerlのコードを実行した際の警告やエラーでプログラムの行番号やファイル名が出たのを見たことがありますか？ エラーや警告が出ているのはわかるけど、どのコードが原因で出ているのかさっぱり分からない、と思ったことはありませんか？
このトークではPerlのスタックトレースやその周辺の仕組みについてざっくばらんに語ります。スタックトレースという概念について興味を持ってもらえれば幸いです。

主なトピックとしては以下を予定しています。

• warn,die
• caller
• Test::More,Test2
• __FILE__,__LINE__
• 他言語との比較？

あ、もちろんCarpモジュールの話もします (なぜなら広島だから)。

エンジニアの皆さんは日々効率化を進めていると思います。
ですが、自分のキーボード入力を効率化しようと思ったことはありますでしょうか。
とても小さなことですが、仕事道具ですし、PC操作にはキーボード入力が伴います。

キーボードはQWERTY配列がデフォルトです。この配列は無駄が多く、右手首を痛めやすいものとなっています。
実は、QWERTY配列以外にも配列が存在します。英語入力向け、ローマ字入力向け、日本語入力向けがあります。
英語入力向けのDvorak, Colemanは聞いたことがある方もいるのではないでしょうか。

本発表では、ローマ字入力向け配列であるEucalyn配列を習得した筆者が実体験から以下のことを話します。
・QWERTY配列以外の配列の紹介
・別配列を覚えるうえでの障害
・別配列を使っていてどのような利点があるのか
・別配列を使うための設定

商品の注文や口座間送金など、二重に行われてほしくない処理をネットワーク越しにリクエストし、通信に失敗したとき────クライアントはリトライするかもしれません。
しかし、直前のリクエストでサーバ側の処理が正常に完了していたら、1回でよい処理が複数回行われてしまいます。

この課題を解く鍵は"冪等性"。
「同一リクエストに対して結果が変わらない」仕組みをサーバが備えれば、クライアントは安全にリトライできるようになります。
そして、その実現手段として注目したいのが、POST/PATCHリクエストを冪等にするためのプロトコル、Idempotency-Key Headerです。

本セッションでは、IETF draftとして提出されているIdempotency-Key Headerの背景・コンセプト・現在の動向を解説し、HTTPリクエストにおける"安全なリトライ"について掘り下げます────