トーク

CoderDojo は子どものためのプログラミング道場です。
2011年にアイルランドから始まった国際的な非営利活動で、日本には204以上の道場があります。
各CoderDojoでは、チャンピオンと呼ばれる主催者と、メンターが、Ninja（参加者）と、プログラミングやものづくりを楽しんでいます。

CoderDojo 恵庭は2016年ごろから活動を開始し、2022年ごろから休眠状態でしたが、あることをきっかけに2024年に復活しました。
今回はそのエピソードと、100回以上にわたって活動してきたことで生み出されたドラマをご紹介します。

またCoderDojoには、メンターという立場で参加することができます。
今回のトークを通して、カンファレンスに参加しているTechな方々方を、地域のCoderDojoという魅惑の場所へ誘います。

Copilot や Cursor など生成 AI の普及により、コードを書くコストは劇的に下がりました。しかし、出力されたコードのレビューが開発の新たなボトルネックになっています。AIの出力を日々ひたすらレビューをしていて、生成AI登場以前より大変だと感じる方もいらっしゃるのではないでしょうか。
そこで本トークでは、レビュー負荷を低減する試みとして「AI による仕様と実装の一貫性チェック」の検証結果を共有します。
まず、仕様と実装のズレの原因を「仕様の解釈ミス」「情報漏れ」などのいくつかのパターンに分類します。サンプルプロジェクトにそれらのズレを仕込み、Cursor等のコーディングエージェントがどこまで自動検出できるかを比較します。
トークを通じて、皆さんのプロジェクトでも一貫性チェックを組み込むべきか、その判断材料を提供します。

ChatGPTやGeminiに何かをお願いする時、どれだけ詳しく指示を書いていますか？ 最近のLLMは非常に賢く、自動でWeb検索までしてくれます。少し曖昧な指示でも、よしなに情報を集めて回答してくれるため、「もう自分が詳しく知っている必要はないのでは？」と感じる瞬間もあるかもしれません。
このトークでは、ソフトウェア開発の「要求分析」をテーマとして、この疑問を検討します。 LLMに対し、要求分析の知識のない曖昧なプロンプトで要求抽出をさせた場合と、要求分析手法という専門知識を含んだプロンプトを与えた場合、そのアウトプットにはどのような差が生まれるのか、具体的な比較結果をお見せします。
LLMがそれっぽい答えを出してくれる今、私たちがこれからも専門性を高めていく意味はあるのでしょうか。このトークを通じてその答えを探っていきましょう。

クラウドといえばAWSのイメージが強いですが、私が関わっているプロジェクトではAzureを使っていました。そこでまずは基礎から学ぼうと考え、Azure Fundamentals（AZ-900）を受験し、無事に合格しました。
2024年卒エンジニアとして、業務ではまだ本格的にAzureに触れた経験がない中で、どのように資格の勉強を進め、何に苦労し、どう乗り越えたのか。
初心者目線での学習方法や活用した教材、モチベーションの保ち方など、これからクラウド資格を目指す方にも役立つ情報をお話しします。

現在は次のステップとして、AZ-204（Azure開発者向け中級資格）の取得を目指して勉強中です。その“その後”の話にも少し触れたいと思っています。

想定する聴講者
・クラウドに興味はあるけど、未経験の人
・AWS経験者で、Azureに興味がある人
・AZ-900の受験を検討している人

アンカンファレンスとは、参加者が主体的にテーマを提案し、グループで議論を行うイベント方式です。
技術的な話題だけに限らず、自分の立場で今気になっていることや悩みについて考えを深めたり、思いがけない視点や他者からの学びを得られることもあります。

「初めて聞いた」「聞いたことはあるけどよくわからない」「やってみたいけど自信がない」「アンカンファレンスならまかせろ」 な皆さん、ぜひ体験してみましょう！

このワークショップでは、アンカンファレンスに必要な道具や進行方法を紹介しつつ、実際にアンカンファレンスを行います。
皆さんの活動の中でも、アンカンファレンスが活用されるきっかけになれば嬉しいです。

時代の移り変わりに伴い、当然、ソフトウェアの設計・開発手法も変化・進化が続いていきます。
当時の開発現場で妥当とされた、あるいはベターと判断された設計・開発上の選択が、今となっては技術的負債、忌避すべき一手に変わっているものも少なくありません。

このセッションでは、発表者が新卒後20年間Webシステム開発に携わる中で進めた「当時はよかれと思って選んだ設計・実装の判断」が、時を経て、どのような技術的負債や後悔を生んだのか、蔵出しできる範囲で赤裸々に共有します。

「こうなるとは思っていなかった」「当時に今の知識やノウハウがあれば…」「自分でも実はちょっとどうかと思ってた（けど仕方がなかったんだ...）」と感じた瞬間の数々を、皆さんと一緒に振り返りつつ、未来の自分や誰かが幸せに開発できるような選択のための勘所や視座を、少しでも皆さんとともに掴んでいける場にできればと思います。

「あれっ? 刺さっちゃった?」
ブラウザの画面には「XSS」と書かれたダイアログが表示されている。
テストしていたのは海外製のWordPressプラグイン。報告窓口はどこだ? 英語でやりとりするのは気が重いし、そもそも対応してもらえるのかなあ...

このような場合にも活用できる、IPAを通して脆弱性を報告する方法を紹介します。

※2024年9月のゆるい勉強会で発表した内容の再演です

[対象者]
脆弱性報告をしたことが無い人
脆弱性を見つけてオロオロしている人

[話すこと]
脆弱性を見つけたらどうするか
IPAへ報告するメリット/デメリット
IPAへの報告の仕方

北海道、特に道北あたりですと、首都圏やオープンデータを推進している都道府県などに比べてあまり多くのデータは公開されていないのではないかと思います
なので、どのようなデータがどのくらいあるのかを調べて、可視化するところまでを発表できればと思っています
（国土数値情報がメインになりそうな気はしているのですが。。。）
DuckDBによる空間検索も登場する予定です

[対象者]
データの可視化に興味がある人

[話すこと]
見つけたデータ
可視化
分析

Python製の静的サイトジェネレーターSphinx(https://www.sphinx-doc.org/ja/master/ )は、reStructuredTextやmarkdownといった軽量マークアップ言語を使用して、静的なWebサイトやPDFなどを生成できます。Pythonの公式ドキュメントもSphinx製です。

本ワークショップではSphinxと便利な拡張機能を使用して、自分が作成したドキュメントがWebサイトとして構築されインターネットに公開できるところまでを行います。
以下の記事の内容をベースにワークショップ用に再構成する予定です。
https://gihyo.jp/article/2024/06/monthly-python-2406

外部へ公開するためにGitHubを使用するので、参加する方はGitHubのアカウントを事前に用意してください。

セキュリティインシデントは誰もが避けたいトラブルですが、万が一の事態に備えは十分でしょうか？
インシデント発生時の対応力は、事前の準備で大きく左右されます。特にクラウド環境では、従来のオンプレミス環境とは異なる課題があり、適切な事前準備が不可欠です。
本トークでは、デジタル・フォレンジック研究会から2025年5月に公開された「証拠保全ガイドライン」の補足資料「クラウドフォレンジックについての参考情報」をもとに、パブリッククラウド環境でのセキュリティインシデント対応に必要な事前準備や知識について解説します。

「仕事には関係ないけど、この技術面白そう」と思ったことはありませんか？
私は、あります。
「面白そう」っていう軽い気持ちで試したことが、実は仕事やいろんなところで生きてくる。そんな経験はありませんか？
私は、あります。（2回目）
そんな、「仕事に関係ない技術探求の魅力」を、５分でサッとお話します。
果たして、５分で伝えきれるのか！？
LTで語り切れなかった続きはブログで！

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発でもう１つ重要なnpmモジュールを１つのアプリケーションにまとめ配布可能な形にするバンドラーがどう依存解決をして、そのアプリケーションをバンドルしているか、バンドラーの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発の型システムを支える重要なライブラリであるTypeScriptがnpmモジュールの型解決をどう行い整合性をとっているのか、VSCodeの型補完Intellisenseはどう機能しているのか、d.tsとは何か？ TypeScriptの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発でもう１つ重要なnpmモジュールを１つのアプリケーションにまとめ配布可能な形にするバンドラーがどう依存解決をして、そのアプリケーションをバンドルしているか、バンドラーの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

みなさんには自分が考えたさいきょうのプロンプトを持ち込んでいただきます。
プログラム、画像生成、エージェントなんでもござれの無差別決戦になります。
場にいる全員の度肝を抜いた人が優勝です。（その場で話し合って決めます）

北海道からぬいぐるみ（売り子）を連れて、東京の技術書典に飛び込み参加してみました！
オンラインで参加したことは何回もあったけど、実際に会場に足を運ぶと全然違う！！！

このセッションでは、
・技術書典に行ってみたリアルな体験（北海道→東京）
・会場の雰囲気や売り子としてのぬいぐるみの活躍
・周囲のブースの“空間づくり”の工夫がすごかった話
・技術書典がきっかけで、自分でも本を作り、2週間後に初出展した話

を、シマエナガ目線（？）も交えながらゆるっと語ります。
「行ってみたいけど、ちょっと勇気が出ない」
そんな人に向けて、「たぶん、(ぬいぐるみがいれば)大丈夫」と、希望も込めてお話しします！

電子回路の勉強をしはじめて発生する厨二病のひとつに，抵抗器のカラーコードを何にでも当てはめはじめるイキりがあります．今回はそのイキりを正面から知識として活用してもらい，手元にある抵抗器をつかって，指定の合成抵抗を最も早く組み上げられる「E12系列炭素被膜抵抗合成抵抗ピッタリ最強王」を決定します．

CPUアーキテクチャの話って、難しそうで遠い存在に感じませんか？

macOSの歴史をたどると、そこにはCPUの都合・設計思想・気持ちが現れています。
本セッションでは、AppleがPowerPCからIntel、さらにApple Siliconへと至るまでのCPUアーキテクチャの変遷を軸に、各時代のOS設計やハードウェアとの関係性を探ります。

• なぜPowerPCではマルチコア・省電力が難しかったのか
• なぜIntel移行が行われたのか
• NeXTSTEPの精神とClassic Mac OSの“心”の融合
• なぜAppleは自前でチップを作る決断をしたのか

macOSの歴史を通して、CPUとお友だちになりましょう！

一生で一番大きい買い物
　　　
「家」

しかし、これは自分の一生を大きく左右するにもかかわらず
・専門用語が多く
・慣習慣例も多く
・提供元によってルールが異なり
・「やってはいけないこと」をやれてしまい
・決めなければいけない要素数が多すぎ
・しかも短期間で決めなければいけないタイミングが突然やってくる
・運要素もある

と、まじめに取り組めば子育てと並び生涯最高難度を誇るイベントといっても過言ではないでしょう。

ここで登場するのが生成AI。
膨大なルールをうまく取りまとめてわかりやすく説明することが得意です。
うまく使って一生のイベントを乗り切って後悔のない家づくりをする方法を皆さんと共有できればと思います。

GoFのデザインパターンって、名前だけ聞いてわかった気になってませんか？
本セッションでは、アニメを題材にGoFのデザインパターンを高速かつ印象的に・楽しく解説します。

例えば…
＊この中に1人、妹がいる! から学ぶSingleton
＊バカとテストと召喚獣の秀吉の眼差しで Strategy パターンとむきあってみる
＊名探偵コナンからAdapterを理解する