トーク

みなさんは日頃 git コマンドのうちいくつのサブコマンドを利用していますか？ブランチの切り替えのためにまだ checkout を利用していますか？ そもそも今使っている git のバージョンはいくつですか？

このLTでは筆者が最新版の git で使えるおすすめのサブコマンドや設定項目を独断で次々と紹介します。ここで学んだものは今日から早速使っていきましょう！

OSDNはマニュアル日本語化プロジェクトにとっても便利なサービスでしたが、現在崩壊状態にあります。人々がこれにどう立ち向かったかについて簡単にお話しします。

APIのテストをどのように行なっていますか？

curlでの実行をはじめ、Postman、HTTPie、Scenarigoといったツールを使って実行していることもあるでしょう。
チームでの保守のしやすさ、CIへの組み込みやすさといったさまざまな観点でこれらのツールを整理した上で、私が業務でも利用している"推し"のAPIテストツールをどのように利用しているかを紹介します。

現在、Perlの開発をしているPaul Evans氏は、こんなことを言っています。

“Perlをもっとよくしていくには、公開されている機能をギリギリまで使い倒して、できる人たちに「そんな無茶なやり方よりもっといい方法がある」と言わせるといい”
-- Blog: Charsbar::Note 「London Perl Workshop 2016に行ってきた 」より引用

実際、氏の取り組みが、try/catch, class構文といったperlの進化に繋がっています。

graphql-jsを忠実にPerlに移植するプロジェクトを進めると、型表現や非同期処理など普段使いのPerlでは難しい問題に直面しました。
が、その問題を解決することは、プログラミングをする根源的な楽しみでした。

本トークでは、移植時に必要になったType-Aliasや実際の移植結果を紹介します。

私はEmbedded SREとして日々業務に取り組んでいます。

Embedded SREの魅力は、開発チームに参画し、信頼性の向上に努め、Opsに関する知見を持ち込むこと、と同時に、開発チームが必要とする開発基盤のニーズを見出し、全体最適化を図るようプラットフォーム組織に働きかけることです。

Dev組織とOps組織の狭間に立ち、仲介者となることで両者の強みを最大限に引き出す、このどっちつかずな立ち位置が、以外にも私にとってはとても動きやすく、気に入っています。

本セッションでは、そんなEmbedded SREの魅力と開発組織への影響についてお話したいと思います。

キーワード

• Embedded SREとは？
• どっちつかずの立ち位置で開発チームとプラットフォームチームの帽子を被り分ける
• サイロ化破壊装置としてのEmbedded SRE

技術的負債とその改善について、失敗を共有するスタイルでアジャイル開発の考え方について話します。
これまでの開発の中でたびたびわからん殺しされ、後から振り返ると技術的負債を作り込んできました...

アジャイル開発については、慣れ親しんでいるXP（エクストリームプログラミング）のプラクティスをベースにします。
XPのプラクティスを知ると「こういう考え方は全然していなかったな」と思い至り、心に深く沁み入ります。
プラクティスの実践で同様の失敗を回避できている感覚があり、ここで紹介する考え方は発表者が"好む"考え方です

・「リリースした後直します」は絶対タイミング来ないよ！！
・要件を満たす最小限の実装
・既存の実装は最小限なので、要件の追加に合わせて大きく作り変えることも1つのリスペクト
・機能追加しやすくなるようにまずリファクタリングする
・機能追加にちょっとずつ混ぜ込む負債返済

サーバー監視 SaaS である Mackerel の OpenTelemetry 対応の一環として、ラベルつきのメトリックを自在に引くための PromQL エンジンを開発しました。PromQL は Prometheus というオープンソースの監視ソフトウェアで使われているクエリ言語です。

新卒エンジニアが初めて携わったこの大型開発の裏側とそこから得た学びを共有します。リリース10年目を目前にする SaaS に、 OSS に依存する大きな機能追加を行うエンジニアリングをみなさまにも追体験していただきます。

こんなことを話します：

• なぜ PromQL を選択したか
• 既存のシステムを壊さずに生かすアーキテクチャ設計
• どこまでを OSS に任せ、どこからを自分達で作るのか
• 素早く動くものを作るためのマインド
• OSS の挙動を広く・あるいは深く理解するための道具

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

どの言語をどこまで対応するのか、時刻の表記、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に限らない提言としてお話します。

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

プロジェクトを始める際にこういうドキュメントがあると楽だったよという経験談を話します。インセプションデッキ、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エディタでの実装

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

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

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