Movatterモバイル変換

株式会社はてな 取締役 組織・基盤開発本部長。2001年に創業メンバーの1人として有限会社はてな（当時）にエンジニアとして入社。その後「はてなブログ」の立ち上げや事業化を指揮。はてなのサービス・システムの開発本部長を経て、2022年5月より現職。組織開発及びシステム基盤開発を統括する本部長と人事部長を兼任し、経験を活かした多角的な組織開発に取り組む。代表作は Devel::KYTProf

株式会社ディー・エヌ・エー 常務執行役員。法学部法律学科からエンジニアへ転身し、2011年にDeNAに入社。Mobageおよび協業プラットフォームの大規模システム開発、オートモーティブ事業本部の開発責任者を歴任。2018年より執行役員としてDeNAのエンジニアリングの統括を務め、2019年より常務執行役員 CTOとしてより経営レベルでの意思決定にかかわることと、技術・モノづくりの強化を担う。2020年より常務執行役員として技術領域を担当しつつ、メディカル領域の新規事業を担当。

本セッションでは立命館大学情報理工学部情報理工学科教授の上原哲太郎先生と、同じく立命館大学法学部法学科教授の宮脇正晴先生を招聘して、AIと著作権、個人情報やThird Party Cookieの扱い、OSSライセンス、忘れられる権利やcoinhive事件のような法律と技術が絡み合うトピックスなどを取り上げて対談形式でお送りします（ここに書かれているトピックは仮のもので当日までに取り上げる内容は変更されることがあります）。

ソフトウェアの開発と運用にはライフサイクルが存在します。いわゆる「一般的な (ウェブ) アプリケーション」は書いて終わりではなく、サービスが続く限りは既存の機能を提供しながら新機能開発であったり不具合修正であったりを続ける必要があり、ソフトウェアは徐々にその形を変化させていくことはもはや周知の事実であると思います。つまりソフトウェアについても現実に存在する「モノ」のように定期的あるいは継続的なメンテナンスが必要なのですが、様々な理由からそういった治安維持が放棄されいわゆる「廃墟」と化してしまうサービスやコンポーネントが出てくるというのは現実として発生します。そしてえてしてそのようなコードこそ、理由はわからないものの動き続け、不思議と金を稼いでいるということも良くある話です。「金を埋む廃墟」は現実世界では最高の不動産かもしれませんが、ことソフトウェアでは通常そうも参りません。変化のスピードが早いためです。本セッションではそういったソフトウェア的廃墟ができる背景やその成り立ち、そして実際に廃墟をなんとか解決していく方法、廃墟を生みださない心意気、そしてにっちもさっちも行かない場合のための「廃墟で頑張って、できるだけ快適に暮らす」という生活の知恵を共有できればと考えています。

10年前、YAPC::Asia 2013で行われたあることをキッカケに「秋のエンジニアぶつかり稽古 2013」というイベントが開催されました。 当時のあの「事件」を、皆様は覚えていますでしょうか?あれから約10年が経過した2023年吉日、YAPC::Kyoto 2023にこの #ぶつかり稽古 が帰ってくることになりました！@kan さんと、antipop さんにより送り込まれた刺客 @kenchan さんが壇上でアツいぶつかり稽古を繰り広げます。乞うご期待！

WebAssembly(WASM)は近年Web以外にも活用の幅を広げており、Perlエコシステムにおいても、Perl処理系をWasmに変換してWeb上で動作させるWebPerlや、PerlからWasmを呼び出すためのCPANモジュールが登場しています。一方、実プロダクトでの活用シーンの情報はまだまだ少なく、WASM適用がどのようなシチュエーションで有効なのか、イメージが湧きづらい状態です。このトークでは、株式会社Helpfeelにおける独自記法パーサのWasm実装を例に、"普通"のWebアプリケーションへのWasm適用にトライする中での、適用先の検討、トレードオフ、具体的な活用例などをご紹介します。

久しぶりのシリーズ再開ということで、今回はPerl 5.32からそろそろ概要が見えてきている Perl 5.38 までの情報を簡単にまとめていきます。

GMOペパボでは、分散オブジェクトストレージを実現できるPerl製のソフトウェアであるMogileFSと、300本以上の大容量のHDDを搭載したオンプレミスなサーバ群を組み合わせて、大規模なオブジェクトストレージを実現しています。これを活用して、写真共有サービスの30days Albumの写真・動画をホストしたり、さらにS3互換のREST APIを開発してS3ライクに利用できるプライベートオブジェクトストレージとしても利用できるよう拡張してきました。運用を始めた2008年時点で1TB程度だったオブジェクトストレージは、2023年1月現在では4PBを超えており4000倍以上の規模まで成長しました。本トークでは、十数年かけて4PBまで成長したオブジェクトストレージをどのように運用してきたのかハードウェアからアプリケーションにかけて横断して紹介します。アジェンダ - MogileFSを利用したオブジェクトストレージのアーキテクチャ - キャパシティを意識したストレージのライフサイクル管理 - サービスの特性を考慮したREST APIの実装 - S3互換のプライベートオブジェクトストレージのS3移設

クラウドファースト、クラウドバイデフォルトなどと言われるようにクラウドサービス前提にシステムの構築運用がなっています。インターネットにおける重要な基盤技術のひとつであるDNSにおいてもクラウドサービスが使われるようになっています。本トークでは、さくらのクラウドのDNSアプライアンスサービスに行われたDNS水責め攻撃と呼ばれるDDoS攻撃の内容およびその対策について紹介します。また、対策にあたって作成したDNSサーバへ負荷をかけるベンチマーカを題材にハイパフォーマンスなベンチマーカを作る上で必要な要素も紹介します。アジェンダ- さくらのクラウド DNSアプライアンスとは(Perlも使っているよ)- DNS水責め攻撃とその実際- GoによるハイパフォーマンスなDNSのベンチマーカ作成- さくらインターネット SRE室の取り組み

超軽量のウェブフレームワークであるhonoにおいて、高速な動作を中心で支えているのがルーターです。honoは現在、内部では3つのルーターの実装を持っていますが、構築したアプリケーションのルーティングに応じてそこから自動で選択されて、実行時には最適な1つが利用されるようになっています。発表の前半では3つのルーターの紹介と、そこから1つが選択される仕組みについてお話します。後半では、ルーターの実装が追加されていった経緯と、そこにつながるPRがOSSとしてのhonoになにをもたらしたかについて、PR作成者側の視点で感じたことをお話します。

Perl Mongerの皆さんもウェブアプリケーション開発を行う上で切っても切り離せないものの1つがJavaScriptかと思います。皆さんも聞き馴染みがあるであろうESLintやBabelやWebpack、esbuildやPrettierやTypeScriptなどなどあらゆるJavaScript関連のツールは内部的にJavaScriptのASTを操作し、それらを組み合わせることで成果物を生成しています。このトークではJavaScript(ECMAScript)を扱う上でのASTの概要について紹介した後に、実際にハンズオン形式でASTを利用したJavaScriptのソースコードの変換や生成の片鱗を体験していただけるような構成になる予定です。※ ASTとは何かという話であったり、AST自体の詳細に踏み込んだりなどはしない予定であくまで「戯れる」ことがメインの発表になるかと思います

PerlのCPANモジュールのSys::PageCacheはLinux上のページキャッシュを調整したい時に使われてきました。このようにシステムプログラミングが必要な場面でPerlが使われることがよくありました。しかし最近はSys::PageCacheの代替として使えるGo製のcubicdaiya/cachectlのようにGoで作られる事例も出てきています。cubicdaiya/cachectlは元々cgoを使ってシステムコールをC言語経由で実行していましたが、以前私がpure Go実装に書き変えています。また大量のファイルが置かれているディレクトリに対しても利用できるlsとして、私が作ったllsもGoからシステムコールのgetdents64を直接呼び出すことで、pure Goで実装しています。そこで本発表ではGoでシステムプログラミングをする方法について、私が経験したことをベースにお話しします。参考：https://developers.prtimes.jp/2021/09/15/decommissioning_old_storage_list_a_dir_29million/https://github.com/catatsuy/llshttps://github.com/cubicdaiya/cachectl

try catch に一家言あり最近 https://blog.ojisan.io/my-new-error/ というブログを書きました。この記事ではResult型の導入やエラー監視ツールにデバッグ可能なログを出させる技術について解説をし、自分の考える理想のエラーハンドリングを書きました。しかし職場の7年物の既存実装に正しいエラーハンドリングを持ち込むのは難しかったです。そこで本セッションでは理想のエラーハンドリングプラクティスやそれを支える要素技術について解説し、現場でどうやって段階的にエラーハンドリングや監視体制を改善していけたかという話をします。

正規表現。Perlが最も愛されそして(不当にも)憎まれる理由の一つ。しかし今や正規表現をサブ言語として持つ言語はPerlに限りません。本talkではこの最も人気のある言語内言語に関して(再び)時間が許す限り型って、もとい語っていきます。* regexp? what is it?* $supported_by ~~ @most_major_languages;  * but how (much)??    * Unicode support?    * assertions?    * modifiers?* use CPAN;  * Regexp::Assemble;  * Regexp::Common;* Irregular expressions  * qr{(func?(?:tion)((((?:(?>[^()]+)|(?2))*))))}* (ir)?regular questions (?:from|by) the audience* ReDOS - Regexp considered harmful!?

タイトルは [Kyoto.pm Tech Talks #01](http://kyotopm.github.io/) リスペクトです。はてなの Perl プロダクトは薄いフレームワークを志向して、データベースとのやり取りに DBIx::Sunny や DBIx::Handler::Sunny を用い、主に SQL を書いて暮らしていました。最近、私はこの世界に ORM を持ち込みました。PofEAA によるデータソースのアーキテクチャの 4 分類、我々が何を考えてどのパターンを選んだか、必要になって書いたプラグイン等、ORM の無い世界に ORM を入れていくに当たって考えたことと、その実践。Perl Monger なら一生に一度は書くといわれる ORM を書いていく様子を、Rails の ActiveRecord に慣れ親しんだ現代の目線も交えつつお送りします。

MySQLのデータを全文検索したい場合、よくあるアプローチとしては以下の3つが考えられます。1. MySQLのデフォルトのストレージエンジンInnoDBの全文検索機能を使う。2. 別途Elasticsearchを用意し、アプリケーションでMySQLとElasticsearchのデータを更新し、検索はElasticsearchで行う。3. 別途Elasticsearchを用意し、Logstashを使ってMySQLのデータをElasticsearchに同期する。1.は手軽に全文検索を実行できますが、InnoDBの全文検索はあまり速くありません。2.はMySQL、Elasticsearchのどちらかのデータ更新に失敗した場合のケアなどでアプリケーションが複雑になります。また、Elasticsearchが起動していない期間はデータの更新ができなくなります。3.はデータの削除に対応するのに追加の設定が必要です。また、Logstashはサービスとして起動するのでLogstashの死活監視も必要です。上記の通り、よくあるアプローチはそれぞれ課題があります。そこで、これらの課題を解決すべく、今回MySQLのデータをGroongaに取り込むツールとGroongaに対してHTTP経由でクエリーを発行できるPerl用のGroongaクライアントモジュールを作成し、これらを組み合わせてMySQLのデータをPerlからGroongaを使って全文検索できる仕組みを作りました。これによって、Groongaを使ってMySQLのデータを高速に全文検索できます。また、この仕組みでは、アプリケーションからはMySQLのデータのみを更新すれば良いため、アプリケーション側で更新処理を変更する必要がありませんし、Groongaが起動していなくてもデータの更新が可能です。さらに、データの削除についてもデフォルトで対応しているので追加の設定は必要ありません。またサービスではなく、定期的に同期を実行する仕組みなので安定しやすいです。Groonga独自のクエリーを覚える学習コストとGroonga⇔MySQL間のデータをマッピングする設定は必要ですが、そこまでやってしまえばMySQLのデータをほぼリアルタイムでGroongaに取り込みPerlから最新のデータを高速に全文検索できます。本発表では、どうやってPerlからGroongaを使ってMySQLのデータを全文検索するのか、その仕組みと上記で紹介したよくあるアプローチの課題がこの仕組みでどのように解消されるのかを紹介します。

prototypeは、Perlのサブルーチンの引数の振る舞いを変える機能です。一見するとただの記号の並びに見えるprototypeですが、実は身近なところに潜んでいて、Perlプログラムを支えているのです。このトークでは、そんなprototypeについて魅力や活用法などを交じえながらお話しする予定です。* try/catchから始めるprototype入門* こんなにあるぞ！！ prototype* 気になるあのサブルーチンのprototype、コッソリ教えます* prototypeを使う/使わない理由

タスクを定期的にexactly-onceで実行する仕組みを2020年代に構築するとしたらどんな方法があるでしょうか?cronを動かすホストをひとつだけ用意する……それはSPOFと表裏一体です。Cloud Nativeという言葉が広がりつつある今、クラウドサービスの力を借りてスケーラブルなcron alternativeを実現できないでしょうか?世にあるFaaSなどはat-least-onceは実現されていてもexactly-onceはなかなか実現されていません。しかしわたしたちはexactly-onceを求めているのです。自然界にexactly-onceはあるのです。今回は、クラウドサービスを組み合わせてタスクをexactly-onceで定期的に実行するシステムの構築を探求し実現した事例について紹介します。さらにこのシステムを数年運用して遭遇した出来事やその解決策についてもお話しすることでcron alternativeの《リアル》についても紹介します。予定しているトピック:- 共有排他ロックの実装- 統合されたエラーレポートの実現扱う主なキーワード:- AWS Step Functions- cron- Observability

Cloudflare PagesとCloudflare D1を組み合わせることで、外部サービスを使わずにデータを永続化したWebアプリケーションを簡単に作成できるようになりました。さらに、tRPCを組み合わせることで、エンドツーエンドで型安全な環境を加えることができます。本トークでは、シンプルなWebアプリケーションの作成を通して、Cloudflare PagesやCloudflare D1, tRPCの魅力をお伝えしたいと思います。

Perlのバイナリに同梱して配布されるモジュールはコアモジュールと呼ばれます。 YAPC::Japan::Onlineではそこからいくつかを紹介しましたが、時間の都合で紹介しきれなかったものや、その後重要度が増したものもあります。このトークではそのような、知っておくと役に立つ、あるいはそうでもないコアモジュールを時間の限り紹介します。

YAPC::Asiaで憧れたハッカー集団の末席に、新卒という形で頭から飛び込んだのが約10年前。YAPCを始めとした様々な技術コミュニティにお世話になり、時にはスタッフや運営・スピーカーとして貢献しながら、少しずつ歩を進めてきました。キャリアとしては事業会社のエンジニア・リードエンジニアを経て、現在はCTOとしてエンジニアリングだけでない様々なロールを担っていますが、これまでのキャリア選択の傍らには常に「ハッカー」への憧れがありました。いつしかそれが自分への呪縛となっていたこと、そして様々な葛藤と試行錯誤を経て、ようやくそれから解き放たれつつあることに、最近気づきつつあります。エンジニアとして、時にはロールを変えながらサバイブする皆さんに。またかつての悩める自分に、ちょっとしたヒントをおすそ分けできるようなトークにしたいと考えています。

OSSのジョブキューシステムであるFireworqはGoで書かれていますが、TheSchwartzやMogileFSなどのPerlプロダクトにおけるジョブキュー部分の実装に大きな影響を受けて開発されました。FireworqはHTTPでやりとりするため言語非依存で、ジョブがたくさん溜まっている状態でもパフォーマンスが下がらない、キューを動的に複数作成できるなどの特徴があります。このトークでは、Fireworqのこれらの設計に至った経緯や、はてなブックマークのシステム内で実際に運用する上で見えてきたベストプラクティスなどを紹介します。

みなさま日々Webアプリケーションのデプロイにいそしんでいるかと思います。デプロイの風景は数年前と比べるとだいぶ様相が変わっています。Perlなどの開発言語は一緒であっても、デプロイの形態は変わっているという方が多いかと思います。このトークでは、歴史のあるWebアプリ開発言語であるPerlの例を元に2000年頃のCGIとレンタルサーバーを用いたデプロイから、現代のFaaSによるデプロイまでをたどる旅をご紹介します。トークタイトルの「デプロイ」が指す範囲* Webサーバーへの反映方法  * 例    * FTPやscpによるアップロード    * git pullやtarball, dockerなどを用いたPull型デプロイ* Webサーバーの更新方法  * 例    * ファイル更新だけで完了する形態    * プロセスの入れ替えを用いたGraceful restart    * サーバ毎のローリングリスタート* Webアプリケーションから各端末へコンテンツを配信するためのWebアプリケーションの駆動形態  * 例    * CGI    * mod_perl    * FastCGI    * Plack/PSGI    * サーバーレスこのトークで語る内容* Perlによる各デプロイの形態の解説・デモこのトークの対象者* Webアプリケーション開発者* Webアプリケーションがどのように開発され、Web上にデプロイされてきたかを知りたい方

マルチテナントを提供する上で一番の悩みどころはどこでしょうか。私はテナント毎のデータの分割とセキュリティの確保、そして共有情報の分割です。この一つの答えに私がtryした結果が、PostgreSQLの活用です。PostgreSQLにはRow Level Securityをはじめとした様々な機能があり、アプリケーションから意識することなく、マルチテナントを実現することができます。現実的な負担の無い設計を実現しながらも、十分なパフォーマンスを出したい。そんな欲張りな皆さんに必ずcatch（納得）してもらえるような実践的なテクニックから、実際の設計における技術選定の勘所をお伝えしたいと思います。# 対象者- Webサービスなどでマルチテナントを実装したいと考えている人- 既存のマルチテナントで苦しんでいて、リプレースを考えている人- シングルテナント形式で実装に限界を感じている人

HonoというWebフレームワークをつくっています。Honoは速いです。ただし、それだけではありません。HonoはどんなJavaScriptのランタイムでも動きます。少なくとも、CloudflareWorkers、Deno、Bun、FastlyCompute@Edge、Lagonの6つのランタイムで動きます。本トークではHonoがなぜどこでも動くのか、そのために努力していることを紹介します。

サービスの運用では開発環境やステージング環境で入念に動作検証をしても本番環境では想定していない事態が起きます。サービス障害発生時に障害に対して適切な対応を取れるかどうかはユーザーへの影響度に大きく起因します。また、全ての障害を100%なくすことは現実的ではないため発生してしまった障害について「調査・分析・対応」をできるようにしておく必要があります。一方で障害対応は一部のエンジニアが「調査・分析・対応」行ってしまい中々ノウハウが他のエンジニアに広まっていかず属人化してしまうという課題があります。そういった課題に対してGMOペパボでは「Playbook」の運用や「障害対応訓練」の実施などを通して解決へアプローチを行いました。本セッションはサービスの運用で発生する障害対応に課題を感じている組織やエンジニアを対象として属人化してしまいがちな「障害対応能力」そのものにフォーカスをし、どのように向上させるのかというノウハウを紹介します。

私のキャリアの直近3~4年は、地方のエンジニア採用を通じて労働環境づくりや、技術コミュニティづくりをして今後も貢献してきたいと考えております。今後、労働力減少や少子高齢化に伴う問題などを通じて、関東一極型の働き方は難しくなり、より関西やそれ以外の地域でのエンジ二アの活躍場所や、居住地を含めた柔軟な働き方は避けられなくなっていくと思っています。私自身の経験を通じて、地域ITコミュティの重要性や京都のエンジニアが活躍することにより来る明るい未来についてお話したいと思います。

新規サービスをPerlで開発する事例は減りました。しかし、Perlで開発され、現在も利益が出ているサービスはあります。弊社のサービスもその一つです。今後もサービスを出来るだけ長くユーザーに届けるために、弊社ではバックエンドをPerlで開発する決断をしました。この決断の背景と、モダンPerlへのリプレイスの過程を紹介します。紹介の一部は吉祥寺.pmで発表済みで、当日のYAPCではより詳細に発表できればと思います。https://speakerdeck.com/masashi_sutou/jin-nian-yatutakoto-20nian-yi-shang-sok-kuwebsabisunoripureisu-shu-itakodosi-gamodankamotosi-uperl

私の初めてのOSS体験にはPerlが深く関与しています。PerlのおかげでOSS活動が始められたと言っても過言ではありません。私はこれまでOSSに対して多くのpull reuqestを送り、マージされたものは1000を超えます。多くは自分のOSSに対してのものですが、それ以外でも、海外を含む数百以上のリポジトリにpull requestが取り込まれています。 pull requestを送ることに対して最初は心理的障壁があるのはよくわかります。しかし、慣れてしまえば怖くありません。実際、私が送った変更の中には、コードを一文字だけ直したものや、単純作業によるものも数多くあります。 本トークでは私が実際に送ったPull Requestを幾つか取り上げながら、そういうどのようにすれば多くの人がOSSに貢献できるようになるかを話したいと思います。具体的には以下のようなテーマについて取り上げます。- Perlに小さなモジュールが多いからこその貢献のしやすさ- 貢献しやすいリポジトリを見つける方法- pull requestを送る上での心構え- 技術選定するときにまずPull Reuqestを送ってみるということ- OSSを引き継ぐことの美味しさ- OSSを他者に引き継ぐことの感慨- OSSを始める方法

「カイゼン」は業務や作業に対して今ある状態の問題やより良くなるアイデアに気付き、解決し続けることでより良い状態へ昇華し続けることを指し、一般的に改善とは区別されます。私たちエンジニアがカイゼンを行うにあたって何に取り組むべきでしょうか。この悩みについて、新卒3年目が1年間かけて行った日常業務における業務負荷の調査と、そのカイゼンのために行った活動、その影響について紹介します。このトークでは8年以上運用が続いているPerlで作られたソーシャルゲーム運用を題材に、1回のデプロイに数時間かかる作業の工数の削減や、週に何度も行われる定形作業の自動化、エンジニア以外にも作業できる人を増やした資料の整備など話す予定です。これにより、メンバーを希望の別チームへ配属させるなど、チームの人数減少に耐えられる体制を築きました。以下の悩みを持つ方に聞いて欲しいテーマとなっています。- 運用の手作業が多くて開発の時間が取れなくて困っている- どこからをカイゼンすれば良いのかわからなくて始めから躓いている- 自主的にチームと関わるにはどうすればいいのかわからないといった悩みがある

所属しているLaunchable Inc, ではユーザーの自動テスト基盤からデータを送ってもらうためにコマンドラインツール launchableinc/cli (以下 cli ※Python製)をユーザーに提供しています。 我々のサービスを利用してくれているユーザーはエンタープライズな規模から小さいチームまで、使用しているOS、CIプラットフォーム、言語のバージョンなどユーザーによって異なるため多岐に渡ります。それによりcliを開発/運用する上で様々な問題に直面してきました。 本発表ではそのような多岐にわたるユーザーの環境へ提供するためのcliの技術スタック/開発体制など紹介しながら今まで遭遇した課題とその対応策の一部を紹介したいと思います。 本発表を通して開発の参考になればと思っています。

システム・アプリケーションの稼働環境として、AWS EC2を採用しているケースも多いと思いますが、その際にシステム・アプリケーションの監視をどう行うかが課題になるケースがあると思います。その解決方法の一つとして、私達は「CloudWatchエージェント」というAWS公式ツールを利用してEC2内に出力されるログをCloudWatch Logsに転送し、CloudWatchにて監視する方法を採択しました。今回はそれに関して、CloudWatchエージェントの紹介、および具体的にCloudWatchにて監視を行い、最終的に異常発生をSlackで通知する...といったことをAWSだけで実現する方法について、紹介したいと思います。

karupaneruraさん ｢Javaの実装をPerlでテストする｣nasa9084さん ｢Kubernetes SIG-docs jaへのお誘い｣永島　薫さん ｢ワンライナーでちょっと楽に確認するNOSコンフィグ｣nuggedさん ｢Intro and invitation to Perl and Koha Conference in Helsinki, 14-16 August, 2023｣Shunさん ｢chatGPTと文字コード｣tkzwtksさん ｢はてなのPerlブートキャンプご紹介｣moznionさん ｢Prefix Treeによる高速ルーティングテーブル実装｣