「自分で管理しているシステムなら、手を加えられるけど、外部のサービスやウェブサイトはどうしても手を出せない…」こんなもどかしい経験、一度や二度はしたことがありませんか？しかし、プログラムを書くことにそれほど抵抗がないのであれば、ブラウザ拡張機能を自ら作成することが、この問題への解決策のひとつになります。

このセッションでは、ブラウザ拡張機能の開発の魅力を、実際の開発エピソードを交えて紹介します。外部サービスも、自分の手でカスタマイズし、使い勝手を向上させたり、効率を良くするアプローチを紹介します。そして、初めての拡張機能開発でも迷わないステップや、作成にあたっての考え方も紹介します。

プログラミングのスキルを活かして、ウェブの世界をもっと自分好みに、もっと効率的にしませんか？外部のサービスに自分の手を加えて、毎日の業務やブラウジング体験を向上させる方法を手に入れましょう。

みなさん、好きな言語や好きな技術はありますか？ その技術を使って開発した経験は？
…働くようになってから、「技術と初めて出会った時のようなトキメキ」はまだ残っていますか？

個人開発をしたい（している）けれど、”作るものが思い浮かばない”という壁にぶつかる人も多いでしょう。
かく言う私もその中の1人です。

このセッションでは、普段ハッカソンの運営をしている私が出会った「好きなものを使って」「好きなように開発する」学生たちの事例をもとに、凝り固まった考えを捨てて開発する”お遊び開発のススメ”についてご紹介します。

話すこと

• 過去に学生や私が開発したプロダクト（一部抜粋）で紹介
• 凝り固まった考えを捨てるには

話さないこと

• 個人開発のやり方
• プロダクトに関する”詳細な”技術話

対象者

• 若者のパワーが欲しい方
• アイデアの刺激を受けたい方

twitter(X)に何かあるたびに話題になるmastodonやmisskeyのような非中央集権型マイクロブログサービスが構成するネットワークは"fediverse"と呼ばれます。これらは主にActivityPubというプロトコルで接続されていますが、ActivityPub仕様は大枠を定めているだけであり、実際に現在のfediverseに参加するには単にプロトコルの仕様書に書かれていること以上のノウハウが必要になります。

このトークでは、Perl版ActivityPubサーバ"Actub"を紹介しながら、fediverseに参加するサーバアプリを作成するために必要なノウハウについて概説します。

内容としては、Builderscon 2019で発表したものをベースとして、Perlでの実装方法と、その後のfediverse界隈の変化に対応した最新の状況についてお話しします。

Site Reliability Engineering (SRE)が近年話題ですね？SRE本が出てから早6年、既に「近年」ではないという説もありますが、ますます盛り上がってきている分野であります。
SREというロールがあるにせよないにせよ、皆さんも似たようなことは日頃やっているはずです。
他の人がどんなSRE的取り組みをしているか気になりませんか？気になりますよね？

LINE スタンプという、多くのユーザーがいるサービスで、実際に日々行っている(比較的小さな)SRE的な取り組みをご紹介します！

対象

• SREというロールで仕事をしている人
• SREというロールではないけどDevOpsとかそういう仕事をしている人
• SREというロールの人がどんな仕事をしているか気になる人

Honoの最新メジャーバージョン「v4」をリリースします！

Perlに対する最大の誤解の一つに「型がない」というものがあります。実はPerlは単に型があるに留まらず、C言語などと異なり「型安全」ですらあるってご存知でしょうか?Perlの型の扱いは実にユニークで、Perlを主言語としない方もPerlの型を通して型(type)という概念を一段と深く学べるでしょう。

• What is type?
• Static vs Dynamic
• Textual vs Contextual
• Why typed that way?
  • Scalar (≒ Union?)
  • Array, Hash and beyond
  • bless it with the class

皆さんはUIの実装を楽しんでますか？マークアップ、Webフロントエンド、GUI、ネイティブアプリ等、ドメインや技術は様々ですが、アプリケーションには必ずUIがあり、それを実装する作業があります。このUI実装の技術についてはよく語られる一方、UI実装者のモチベーションについてはあまり語られていません。本セッションでは発表者の15年ほどUIに関わってきた経験を通して、UI実装の魅力やどのように楽しめばいいのかをご紹介します。

話すこと

• UI実装のモチベーション
• UI実装技術の歴史
• UI実装とUIデザインの関係

対象者

• UI実装が楽しい人
• UI実装が楽しくない人
• UI実装者のモチベーションを知りたい人

あなたは新卒N年目、リードエンジニアのポジションが板についてきた中堅エンジニアです。ある日の朝、あなたが仕事を始めるとおもむろにCTOがやってきて、にこやかにこう言いました。「君、来月からEMね！」……さてどうする！？

ソフトウェアを開発し、ユーザーに価値を届ける活動の中での肝心要、それが「チームでの協働」。
ここでは私が経験したメンバー・テックリード・マネージャー・CTOの4つのロールを切り口として、メンバーレイヤだからこそ発揮できるリーダーシップ・フォロワーシップとは？から、マネージャーロール1日目から使えるヒント、CTOへのジャンプアップに必要な準備まで、ぎゅっと濃縮してお届けします！
「チームでの協働をいい感じにしたい」「プロダクトの価値を最大最速でデリバリーしたい」と思う開発者の皆さんにとってのぼうけんのしょ＝セーブポイントとなるようなトークを目指します。おたのしみに！

いつも通り、開催時にはそろそろ全容が見えてきているであろう Perl 5.40 の新機能などを紹介します。

技術選択と聞いてみなさんはどんな印象を受けますか?
かっこよくてキラキラしている? 難しくて泥臭い?

プロダクトに採用する技術の正解とは何でしょうか? そもそも正解ってあるのでしょうか?

職業ソフトウェアエンジニアとして、人生の大半を費す仕事で触れる技術はなるべくなら楽しく好きなものにしたいです。
しかし同時にプロダクト・事業を成功させることも大切です。

職業人としての「正解」と趣味人としての「正解」は相容れないものなのでしょうか?

このトークでは仕事・趣味を通じてさまざまなプロダクトを立ち上げ・運用してきた体験を通じて「好き」を「正解」に近付けるためのエッセンスについてお話しします。

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

• 業務で合理的な技術選択を果たすための観点
• 教育や採用・コミュニティ貢献について
• 趣味開発の選択にどのような軸を持つか

Goは並行処理で知られていますが、アクターモデルを導入することで、
さらに洗練された並行処理ができるようになります。

このセッションでは、アクターモデルの基本的な考え方とGoで実装する際の具体的な手法と効果、
実際の導入例をもとに詳しく解説します。
メッセージベースのコミュニケーションを中心としたアクターモデルが耐障害性や拡張性にどのような影響をもたらすのか、
EIPについてやProtoActor、Ergoといったツールキットも交えてお話しします。
Goとアクターモデルの組み合わせによるすこしだけ違うプログラミングパラダイムを探求してみましょう！

言語を問わず利用できるEvent SourcingはCQRSとの組み合わせだけでなく、そのエッセンスは様々な仕組みに取り入れることができます。
マイクロサービスアーキテクチャ化、大規模なデータ処理の改善、CDC、
分散システム・リアクティブシステム構築などではほぼ必須のテクニックとなっています。
しかし、ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
分割しすぎて時系列を無視したイベントなどなど。
当然いくつかは実際にやってしまったこともありますが、
このセッションでは実体験をもとにEvent Sourcingとは何かを説明しながら、
何をすべきでやるべきでないのかを楽しくお話します！

「プログラミング楽しい！」という気持ちで今の世界に飛び込んで、15年以上が経ちました。何度かの転職も経て、業務で扱う言語も、流行りの技術も、様々な変遷をしてきました。また自分自身も加齢やライフステージの変化により生活スタイルなど大きく変わりました。

そんな中でも、今も昔もずっと変わらずに続けているのが「趣味プログラミング」です。
そのときそのときに興味を持ったものを題材として、自分の好きなようにコードを書き、自分の作りたいものを作る。自分だけのための「趣味」としてのプログラミングです。

ただ自分が楽しむためのものでしたが、その趣味プログラミングを通じて様々な学びがあり、出会いがあり、多くの経験を得ることができました。私のこれまでの趣味プログラミングの話、取り組むときの思考、起きた変化などを紹介し、趣味プログラミングの楽しさをお伝えし「プログラミングが好き」な仲間を増やしたいと思います。

「隙間家具OSS」は私が考えた言葉で、クラウドサービスやミドルウェアなど、システムを構成する大きなコンポーネントの間にあるちょっとした隙間をうまく繋ぐためのソフトウェア(特にOSS)のことです。

数年来、私は「隙間家具OSSを作るのが趣味です」と公言しています。そして、このような小さなソフトウェアをOSSとして開発し続けることで、ソフトウェアエンジニアとして生きていく上で、いろいろと重要なことを学べることを実感しました。

このトークでは、小さく実用的なソフトウェアを開発することを通して得られた「よいこと」をお伝えします。

株式会社はてなでは長年の運用によりPerlでのWebアプリケーション開発知見は溜まっていますが、Goにおけるベストプラクティスが定められていません。Goを採用しているチームはそれぞれで試行錯誤しながら開発を進めています。

この状況を見かねて、Goにフォーカスしたチーム横断のタスクフォース「Goサブ会」を設立しました。社内外のGo知見の輸出輸入を活発に進められるような工夫を検討しながら実施しています。

またさらにここから分離した「標準化分科会」も少人数で実施し、社内でのGo Webアプリケーション開発におけるガイドラインの設立を目指して活動を進めています。

本セッションでは「Goサブ会」および「標準化分科会」オーナーである私から、どのようにしてこれらのタスクフォースを回しているのか、現在どのような成果が出ていて今後の展望としてどのようなことを考えているのか事例を交えつつ紹介いたします。

私は、今年で9周年を迎えたソーシャルゲームのサーバの保守・運用に従事しています。今回は、既存のサービスに対して新しい取り組みを行う模索として、Perlで動いているサーバに対してAPI通信を行ない、クライアントとして振る舞うプログラムをGoで書いてみるという挑戦をしました。このような挑戦をするに至った経緯や、ぶち当たった壁・それを通して感じたことなどをお話できたらと思います

話すこと

• この挑戦をするに至る個人的キャリア上の動機
• Perlで仕事を覚えた人間が、今Goに触れてみて感じたこと
• 9年間熟成された、弊社独自のAPI仕様書を紐解いてみる
• 初心者だからこそ、車輪の再発明をしないように気をつけよう！知名度のあるOSSに乗っかろう！…その気持ちが引き起こした失敗と成長
• 同じ仕事を何年もやり続けて、なかなか挑戦の機会が与えられなくても、自分で挑戦の機会を作り出すことはできる

SHOWROOMのサーバーサイドアプリケーションは、オンプレ時代のインフラを前提としたPerlのアプリケーションでした。

その後コストや運用負荷の観点から一部コンポーネントをAWSマネージドサービスへ移行したのですが、
その際さまざまな問題がありアプリケーション側の改修も含めてそれらを解決したので、
本発表ではその知見を共有したいと思います。

弊社ブログ「SHOWROOMインフラのマネージドサービス移行」の内容の一部を少し深くお話しする予定です。

今の時代、ソフトウェア無しでは事業の成長はありえません。
しかし、実際にソフトウェアを作るとなると様々なことを決める必要があります。
あのときの決断が技術的負債の根本原因になってしまった…そんな経験が自分もあります。

そこで今回は現場で技術選定を行ったり、ソフトウェアを作る時に必要な考え方やテクニックをご紹介します。

話すこと

• シンプルとはなにか
• 問題を解決するための技術選定の勘所
• 小さく、素早く、リリースする

キャッシュはパフォーマンスを劇的に改善する効果がある反面、一度使うと簡単にはやめられない複雑性と中毒性があります。
その特性から「キャッシュは麻薬」と言われ、安易な利用は忌避されています。

しかし、キャッシュがもたらすパフォーマンスの改善効果は無視することはできず、コンピュータの世界において有効活用されているのも事実です。

そこで今回は実際にキャッシュを使う時に陥りやすい問題を取り上げながら、実際の活用例を説明します。

話すこと

• キャッシュが有効な例と失敗例
• キャッシュを実装パターンと始めるときの勘所

対象者

• アプリケーション開発などでパフォーマンスに苦労したことがある人
• キャッシュを利用したサービスの運用で苦労ｗしたことがある人
• キャッシュを利用したことがないが、怖いなと思っている人
• とにかく今すぐパフォーマンス改善したい人

このトークでは、私が実務でイチからバックエンドアプリケーションを開発する際に実践している手法について紹介します。

近頃私はTypeScriptでバックエンドAPIを開発していますが、今回はPerlで簡単な事例を作って解説する予定です。
決して真新しい内容ではないでしょうが、この技術選択をした背景と理由を交えたトークにします。

対象者 中級者～上級者向け

• クリーンアーキテクチャの実践例を見たい方
• 手続き型プログラミングの手法が気になる方
• アプリケーション設計にの知見を深めたい方

話すこと

• 技術選択の背景と目的
• コンポーネント構成と依存関係
• 純粋関数とビジネスロジック
• 目的別のテスト
• 利点と試行錯誤している箇所

深く話さないこと

• クリーンアーキテクチャとDDDの定義
• ビジネスロジックの定義
• 細かいプログラミングのテクニック