トーク

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つのリスペクト
・機能追加しやすくなるようにまずリファクタリングする
・機能追加にちょっとずつ混ぜ込む負債返済

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトを始める際にこういうドキュメントがあると楽だったよという経験談を話します。インセプションデッキ、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配列以外の配列の紹介
・別配列を覚えるうえでの障害
・別配列を使っていてどのような利点があるのか
・別配列を使うための設定