どうも、最近ブログネタが溜まっているのに更新が追い付いていない管理人ですが、今回はYAPC::Hiroshima 2024というカンファレンスイベントに参加してきたので、その感想について書いてみる。
因みにこういう大規模なイベントに参加するのは今回が初めてだ。
まずこのイベントが何なのかについてだが、公式サイトによれば以下のように案内されている。一言で言えば広島で「お好み」について話すイベントと言えるだろう。Perlであっても、なくてもどっちでもいい感じ。
YAPCはYet Another Perl Conferenceの略で、Perlを軸としたITに関わる全ての人のためのカンファレンスです。 Perlだけにとどまらない技術者たちが、好きな技術の話をし交流するカンファレンスで、技術者であれば誰でも楽しめるお祭りです！
今回のYAPC::Hiroshima 2024は｢what you like｣がテーマです。職種、ロール、プログラミング言語、技術要素... あなたのさまざまな｢お好み｣を語ってみてください。
登壇者は錚々たる面々であり、なんととほほのＷＷＷ入門で有名な杜甫々氏も来られているという、かなり凄い内容だった。ある程度の年齢層の方であれば、とほほのＷＷＷ入門にお世話になった方も少なくないのだろうか？私もその一人なので、来る目的の半分くらいはこれだった。
ここ最近私は技術関係のアウトプット先を増やそうと悶々としており、社内外を問わず色々と顔を広げていく活動をしていた。
社内であれば大勢が集まる雑談チャンネルで話を持ち掛けたり、チーム内で話ができる場を設けたり、社外であれば、それっぽいDiscordチャンネルに入ったり、Slackを探したり、果てはジモティで話し相手が見つからないか探してみたり、手当たり次第に探していたところに三宮.devというコミュニティを発見したのだ。そしてここでYAPC::Hiroshima 2024に参加する人はいませんか？という話がされており、そこでこのイベントに出会った。とにかく飢えていた私は参加を決めた。
当日新神戸から広島へ新幹線で向かい、その日のうちに帰る弾丸スケジュールにした。
本当は前日に入り、翌日に帰ることを考えていたのだが、実は参加を決めた時点では骨折しており、根本的に行けるかどうかが見通せず、ホテルを取れずにいたため「行けたら行く」でスケジュールした結果、こうなってしまったという悲しい話がある。
結果的に骨折は良くなったのだが、その頃には連休のためホテルが抑えられなくなっていたのと、歩けるようになっただけであって、完治したわけではなかったので無理をしない方向に倒した。ビビりだと思う。かつて高熱を出しても命を削りMMOをプレイしていた人間とは思えないビビり方だ。
因みに早起きが苦手なので12時に広島入りするという大遅刻計画となった（開場は9:45）
まず受付に入り、名札に自分の名前とお好みを書いた。テストコードを書くことや、PerlということでCGIがあった時代と絡めて「昔のインターネット」や「個人HP」について書いてみた。
最初の登壇を聞きに行った。到着時間の関係で既に始まっていたのと、この為に買ったマシンのセットアップが不十分でセットアップをしていたらほとんど何も聞けていなかった。
その登壇が終わったら昼食だったのだが、端末を鞄に戻すのに手間取り机のある席が取れず、椅子しかない席で気合で食べる羽目になった。仕出し弁当が用意されていて、なかなか美味しかった。飲み物を買ってき忘れる体たらくだったが、幸いここで補給できたので助かった。（昼あるし、なんか出るだろうと過信してやってきたのが当たった形だ）
昼食を終え、実際の傍聴を始めることにした。以下は聞いて思ったことを書いているだけなので、実際の発表内容とはそんな関係がない。
まずはSongmu氏の「Blogを作り、育み、慈しむ - Blog Hacks 2024」を傍聴することにしたが、私もブログを書いているのでこれは非常に共感できるものがあった。それとオタク特有の早口の良さというのも共感できる要素だった。
私もこのブログというかサイトはHTML手書き時代から数えれば2002年からやっているわけで今年で22年になるが、何故そこまで続けられるのかと聞かれれば、それは「ブログを書くこと（サイトを作り続けること）が好きだから」だ。ブログというか個人サイトいうのは一国一城である。執筆者や管理人はそこの主で、文字通り何でもできる。これはすごく楽しいと思う。私はそれが好きだから続けられている。
それにWeb技術者として見た場合、ブログを始めとした自分のサイトを持つというのはHTMLセマンティクスやアクセシビリティ、SEO、通信プロトコルやLinuxなど、様々な観点の勉強にもなる。サイトを作るというその行為そのものが技術経験になりえるのだ。ブログシステム、CMSを作るという領域まで行けば、それはもう立派なプログラマーだと思う。変なプログラミングスクールなどに通う必要など全くない。それ自体をポートフォリオとして出すことさえ可能だ。
自分の好きを語れる場としてのブログ、別にブログである必要もなく、個人サイトでもいいのだが、これを持つというのは一つのアイデンティティを持つことにも繋がり非常に良いと思うので、興味がある人には是非やってほしいと思う。
特に「Webをやりたいのですが、何を学べばいいですか？」というような人には大変お勧めできると思う。どっかのフリマアプリのクローンを作ってポートフォリオというよりは採用担当にも響くだろう。
しかし凄いのは900記事以上も古くから積み上げた記事があるという点だった。私はサイト移転を数えきれないほど繰り返してきており、その都度過去のコンテンツが失われているという悲しい状態なので、今後は保持していけるようにしたいと思っているし、正直ブログの破壊的変更を伴わないようにしたいと考えている。
実際、直近でははてなダイアリー＞WordPress＞adiaryで記事の移行をしているが、この三回の移行では全記事の移行に成功している（記事の数が少ないからできたことではあるが…）
記憶が確かなら、中学のころから今までに書いた記事の総量は1,000を優に超えるはずである。何故なら昔の私は毎日しょうもないことを書いていたからだ。MMORPGをしていた時は毎日の成果を書いていたものだし、色々な妄想を書いたりもしていた。ブログのほかにもMMOサービス側に設置されていたOpenSNS的な奴にもよく書いていた。そういったSNSやmixi、Qiitaなどの傍系も含めれば5,000記事ほど書いていてもあまり不思議ではないが、いずれも現存しないため確認はできない。
今でもブログを書くペースよりネタが増えるペースのほうが早いので多分今後も変わらず増え続けるとは思うのだが、年々ペースが落ちている感は否めない（やることが増えて書く暇が減っている）。とはいえ、Twitteから距離を置いてからは書く量が目に見えて増えているので、これはブロガー的にはいい傾向だろう。
この事についてSongmu氏と懇親会で熱く語れればよかったのだが、当日の私はそこまで頭が回っていなかったのが悔やまれる。
次にこんぼい氏の「非同期な開発体制を支えるドキュメント文化」を聞きに行った。いや会議室を変えていないので、そのまま居座っていただけだが。
この議題についてはかなり興味があり、というのも仕事ではドキュメントの整備状況が悪く、声をかけても実装が優先で書いている暇がないというのが実情としてあった。正直私も書くようにはしてるのだが、後手になっている感じは否めない。
聞いていて思ったのは全てのやり取りをドキュメントベースにすれば実現できるのではないか？ということだ。同期コミュニケーションをすべてやめて、ありとあらゆるコミュニケーション手段をドキュメントベースにするということだ。こうすればドキュメントから仕事が生まれるので、ドキュメントがないとか、古いというのは起きないように感じる。
ドキュメントに関する不明点はどう聞くのか？という部分については、もうそれは従業員のメンタルモデルをバキバキに鍛えていくという方向になる気がするので、どこまで実現性があるのかは判らないが、一つの手法としてありだなというのは感じた。
この内容を何とか実業務に生かしていけないかも考えていきたいところだ。
その次はaereal氏の「好きな技術《コト》で、生きていく技術」を拝聴することにした。相変わらず会議室を動いていないが、恐らくこれは私のお好みが、偶々この会議室に集中していたということなのだろう。
内容的には自分の好きな技術をどうやって仕事で使っていくかという部分と、その難しさについての内容だったと思う。これは私も実業務で引っかかることがよくあり、どうすればメンバーが使いたい技術を業務で使わせてあげることができるかという点についてはよく考える。
まぁぶっちゃけた話無理だと思っている。例えばメガバンクのシステム開発をしているとして言語やフレームワークのCanaryやNightylyの新機能を使いたい！と言われてもそんなものは許せない。勿論、それで不具合が出来ないことを立証できれば可能とは言えなくはないが、現実的に不可能だ。何ならその機能は将来的に破壊されたり、削除される可能性もある。その後のことを考えれば無理無理の無理だ。
とはいえ、メンバーは使いたいのだ。私からは無理としか言えないが、無理しか言わないと「この人に話しても埒が明かない、レガシーは嫌だ！モダンがいい！」と思われてしまう。その対策を考えたかったので、このトークを聞きたかったのだ。
結論から言うと「自分が選べる立場になる（CTOとか）」や「個人開発で使う」ということだった。前者については非常に納得できる内容で、私は正直そのためだけにその立場につく努力をしているといっても過言ではない。
私にも使いたい技術や手法はある。それは「システムを楽に安全に保守できる技術」だ。要するに古く枯れた技術とか、テスト容易性に長けた実装手法などだ。しかしこんなのは面白みがまるでない。特にテストなんて誰も書きたくないし、テスト容易性が高い実装は疎結合で何を書いているかが分りづらいのだ。テストがドキュメントになるといわれても、そんなことより動けばいいのである。
何故それがやりたいかというと、私は職務経験上炎上案件に多く入っており、残業地獄を経験してきていたり、実稼働しているシステムでクソのようなバグを多々踏み抜いてきており、こういうのを避けたいからだ。現職でも時間外対応をしているのを見るとウッとなってしまう。
勿論、私の提案によってそれらが全て解決するかといえば、そんな保証はないし、一個も解決しないどころかより悪くなる可能性だってなくはない。私もやってみないとわからない。ただ個人的な経験や世間を眺めていると、少なからずマシになるのではないかという期待はある。
そういうので私はある程度その辺りを良しなにできる立場まではやってきたものの、次に立ちはだかる壁として出てきたのがメンバーの希望をどこまで採用するかだ。これはメンバーのモチベーション低下や、新規採用にも影響する可能性があり、判断が難しい。しかし事業として見た場合、安定して動いているシステムが求められるのは間違いないと考えている。
そこで後者の個人開発といいたいところなのだが、仕事でやっているだけの人には響きづらいし、個人でやったからこそ仕事にも持ち込んで実績にしたいという人もいると思うのが難しいところだ。とはいえ個人開発の実績はよほどの規模のものでない限り知れており、エンタープライズ開発では無意味なことも多いと思う。例えば個人開発で実験的な機能を使って動いていても、それがエンタープライズでも同様にいくとは限らない。
ここ本当に難しいと思っていて、どうしていけばいいのか悩むところだが、正直なんかいい感じで妥協しつつやっていくしかないのだと思う。何に対しても言えることだが、世の中には銀の弾丸であったり、正解というものはないのだ。
強いて言えば事業として見た場合は最小限のコストで、最速のスピードで、最大限の売り上げを出せるシステムを作れることが正義であり、自分がやりたいことをやるという部分とはどうしても乖離していくので、その辺りをなんか上手いことできるのが最良だとは思う。
それをするためには常日頃から様々な経験を積み、手札を増やし、できる限り多くの選択肢を取れるようにしておけることが大切であると、聞いていてそう感じた。これは開発もそうだが、開発以外もそうだと思う。
手札が多ければ選択肢が増やせるので、AがダメでもBがやれるし、最悪Cでもいい、どれかやれればいいという状況が作れる（いわゆる松竹梅というやつだ）。メンバーは他人なのでどうにもならないが、少なくとも自分だけはそういう状態であれればいいのではないかと思う。
最後にazumakuniyuki氏の「古い技術について—SMTP現代事情つまみ食い—」を聞くことにした。
これは先日Value-DomainのドメインをさくらのレンタルサーバーのメールでSPF, DKIM, DMARC対応させた私にとっては興味深かったからだ。
まず登壇者が関西弁だったので親近感が凄く湧いた。何故なら私は神戸に住んでいるからだ。
今まで何となく使っていたSPFやDKIM、DMARCなどの仕組みが分かったのは非常に参考になったし、今までSPFがあったのに何でいきなりDKIMやDMARKが出てきたのかについてもよく分かり、非常に良かった。
早速DMARKのpをnoneからrejectに変更することにした。レポート設定などの他の部分も今後設定していきたいと思う。
またBIMIやARCといったRFCになっていない規則もあるということで、新しい情報を入手する機会になったのもよかった。
アフタートークみたいなやつ？登壇者による話題指定のLTが行われていた。これも面白かった。ただおじさんの自語りみたいな感じだったので若い人にどれほど通用するのかは若干怪しかった。概して年配者の話というのは年少者にとっては老害トークだと思っているが、耳を傾けてくれた人がいるのであれば、それはいいことだと思う。本当は相手の年齢とか情報の新旧とか、そういった部分なしに話が聞けるのが一番だとは思うが、まぁこの話を書いている私自身がおじさんなので何とも言い難いところである。
シニアクラスになってくると、まぁみんな似たり寄ったりで、私もそんな感じなので共感する部分が多かった。特にRSSを読むという部分については私もやっていて、個人的なオススメはTinyTinyRSSだ。サーバー設置型のRSSリーダーで、PCとスマホアプリで既読状態などを同期しながら読めるスグレモノだ。さくらのレンタルサーバーに建てる方法については以前記事にしたこともあるので興味のある人は参考にしてみてほしい。前述の内容はオンプレ向けだが、確かクラウド環境向けにDockerを利用したデプロイもできたと思う。
TinyTinyRSSはカスタマイズ性が高く、正規表現によるフィルターも備えているので広告記事とかを柔軟に弾くこともでき、正規表現の勉強にもなるのでオススメだ。複数ユーザーを作成して共有したりすることもできるので、任意のグループの中で共有するといったこともできるだろう。
コロナ化などでリモートワークやイベントのオンライン化が盛んになったが、参加している感がなかったり、同時視聴があったり、盛り上がりを出すのが難しいとか、中には演出でよくわからないことをしたというような話もあった気がする。またオンラインが長かったことの弊害で、スライドの文字が小さくなったり、下に書き込みすぎて、現実世界だと後ろの人が見れなくなるという弊害も出てたとかあって面白かった。個人的にはオフラインとオンライン両方のデュアルだとよいと思う。オンラインでは話せないこともはやっぱあると思うので…ｗ
最近の人はあまり知らないらしいが、昔はよく言われていた話だ。コードを書かない誘惑が増えたり、マネジメントで書かなくなるといった話。実際仕事をしていても「コードを書かなくなった」という声はよく聞くし、私も書かなくなったと思う。
個人的には前職でテックリードの地位に就いて以来、MTGや調整ごとをする機会が爆発的に増えた。転職して現職に来て一旦はただのメンバーになったが、改善活動をしているうちに似たような感じになってきている。但し前職でも現職でもコード自体は書いており、恐らく打ち込んだコードの数だけで言えば前々職以前でSESのプログラマーをしていた頃と謙遜ないどころか、増えている可能性さえある。ただ、意識していないと書かなくなってしまうので、その辺りを上手くしようと日々何とかしている。
AIが推論して書いてる間に自分で書けるという話が面白かった。また、コードを書くという体験が失われるというのは一つ面白い観点だと思った。書く時間がない人が時短で書くとかそういうのには向くとか、ChatGPTを壁打ち相手として使うのはいい案だと思った。私もChatGPTを一時期壁打ち相手として使っていたのだが、結局生身の人間と話したほうがいいなと思えてきたので最近はやっていない。AIは次第にやり取りが破綻するのと「ガイドライン上話せない」とか言い出すからだ。Jailbreakさせるとある程度話すようになるにはなるのを個人的には知っているのだが、この状態になると会話が破綻しがちでイマイチよくない（AIの認知に関して変な副作用があるのだと思う）
まさに私がここに来た理由だった。人との繋がりを作るのは大切なことで、上手いこと人を巻き込んでいける人になれるとよいのだと思う。
そして最初は誰しも最初は一人、ぼっちだが、そこからこういった場を使って、繋がりを増やしていく、自分をアピールできるようにしていく。
例えば名札にSNSのアイコンを貼る、QRを付けるとか、私はこの人ですとアピールできるようにしていくとか、その上で日々「何とかの人」として認知されるようにしていくと、徐々にぼっちから抜け出せていくというのがあった。
また過去にはブログを作っただけで声をかけられたという事例もあるようで、ブログを書いたり、今ならツイートをしていくというのも一定の効果があるという話を聞いた。何なら私もそれを目的として今この記事を書いている節があるくらいだ。
SNSアイコンシールみたいなのは個人的にも検討していきたい。いやまぁTwitterそんなに書いてないのがあれだが、私の場合は自分のサイトに誘導するのでも良さそうだ。
これは杜甫々氏のトークだった。杜甫々氏は広島在住である。サイトにも書いてあるので、杜甫々氏のファンであればご存じだろう。
内容的には、あのサイトの成り立ちや、杜甫々氏の経歴などであり、これはは非常に聞いていて面白かった。まさに伝説というか、伝説だった。
メモリが5KBしかない世界でどうやって処理をするか、メモリがオーバーフローするとどうなるかみたいな、興味深いお話が多々聞けた。バンク処理辺りはファミリコンピューターでよく使われていた処理そのもので面白かった。PC98については私も幼いころに使っていたので懐かしい気持ちになった。
後何より響いたのは、残業規制がなく、何もかもが自由だったころの時代の話だ。先輩と自分でどっちが実装を担当するかで喧嘩したというのもよかったし、全体的に非常に良かった。
正直この話を聞きに来たようなもんである。余りに良すぎて、これはもう一生モノの経験である。
また杜甫々氏のインターネット歴は1988年からで36年にもなり、インターネット老人会の会長を目指されているとのことで、私より遥かに大々先輩であられた。
実務的な部分についても、言語やフレームワークなどのEoLが短いという話があり、これはかなり納得した。ぶっちゃけAWSやGitHubでさえNode.jsのあの短すぎるリリースサイクルにまともに追従できてないように見えるので、実際問題短いと感じているし、昨今のフレームワークと言語とライブラリの複合技は全てのEoL内にバージョン整合を取るというのが個人的にかなり難しいと感じており、何とか見直せないかは検討していきたいところだ。
YAPCのメインイベントと呼ばれることもある部分らしい？多分大抵のイベントにある参加者同士の懇親会だ。
初参加ということもあり、ぼっちムーヴを極めすぎた結果、登壇者と話せなかったのが残念だったが、何名の方とはお話をさせて頂くことができ、今後も継続的にこのような会に参加することへの意義や、自分が登壇することでぼっちを回避できるなどといった様々な利点を聞くことができたので、有意義なものとなった。
特に大井町pmの方からかなり強く背中を押してもらえたのもあり、今後精力的に活動していきたいと感じた。幸い行きの新幹線の中でLTネタを考えていたら無駄に出てきたし、普段からブログネタを作っては書かずに腐らせているので、考えれば話すネタ自体はたくさんある（普通の話も真面目な話も不真面目な話も闇の話も何でも）
問題としてはLTになれていない部分があるので、プレゼン資料の作成や実際の話とかがへたくそなところだろう、この辺りは実務でも役に立つと思うので場数を踏んで鍛えていきたいところだ。
まず参加してみて色々身になったというのと、このイベントに参加する前に参加したDevFest: Kobe Developer Dayである程度懇親会の動きを学べていたので、それなりに動けたのは良かったと思う。
反省点としては、余り人に話しかけられず、特に登壇者と一切話せてなかったので、ここは次回改善したい（一体何のために懇親会に参加したのか…。ちなみに前回は登壇者がぼっちだったので話しかけられたというオチがある。）
またLTに関しても以前blessing software KOBEのLT会でやったこと自体はあるので、慣れておくために継続的にやっていき、次回は何か出せるようになりたいところだ。
まずはやってみる、次に続けてみる、続けるというのは三日坊主を連続してるだけでもある種の継続だと思うので、これもやっていきたい。
かつて人生を賭してまでやっていたMMORPGからはもう離れてしまい、続けられなくなってしまっているが、幸いこのサイトだけはずっと続いている。移転でコンテンツが消えてたりしていて、最早残っているコンテンツはカウンターの数字くらいだが、それでも脈々と続けられているので、これからは過去を捨てずに続けていくというのをやっていきたい。個人サイトはその人の顔、外観のイケてなさなど全部ひっくるめて、その人自身であるということも聞いたので、今後とも私の顔として成熟させていければと思う。私が私であり、渡したり得るのはきっとこのサイトがあるからなのだ*1。
因みに私のインターネット歴は1995年からなので今年で29年になり、インターネット老人会の会員を勝手に自称している。
PerlのクラスはPythonみを感じる奥ゆかしい作りになっている。
ファクトリ関数でオブジェクトを生成して、そのオブジェクトの参照を引き回すことで実現してる感じ。
| Env | Ver |
|---|---|
| Perl | 5.34.0 |
ファイル拡張子は.pmが一般的だと思われる。ファイル名とクラス名がリンクしているためPath/To/UpperCamel.pmが多分いい
ハッシュに突っ込んでいく方式
# これがクラス名になる。PATH::TO::NAME構文で書く
package Example;
use strict;
# コンストラクタ
# 第一引数にはpackageのフルパスが入り、第二引数以降に通常引数が入る
sub new {
# 祝福することでインスタンスオブジェクトを生成できる
my $self = bless({}, shift);
# フィールドに値を突っ込む。これがプロパティになる。アクセサはない
$self->{hoge} = shift;
$self->{piyo} = shift;
# インスタンスを返す
return $self;
}
# メソッド
# 第一引数にはインスタンスオブジェクトが入る。アクセサはない
sub get_hoge {
my $self = shift;
return $self->{hoge};
}
1;
オブジェクト生成時にアサインする方式
package Example;
use strict;
sub new {
my ($class, @args) = @_;
my $self = bless({
hoge => shift @args,
piyo => shift @args
}, $class);
return $self;
}
sub get_hoge {
my $self = shift;
return $self->{hoge};
}
1;
ディレクトリ構成
├─library
│ └─Example.pm
└─main.pl
コード
クラスのコードは前述の内容
use strict;
# useするモジュールのパスを指定するおまじない
# パスにはクラスファイルを格納している根本のパスを指定する
# 標準モジュールは区別されるようで、この行の下にuse IPC::Open2;とか書いても、ちゃんと本来のモジュールが読み込まれる
use lib './library';
use Example;
# コンストラクタ呼び出しは()で囲まないとエラーになる
my $ex = Example->new("aaaa", 123);
print $ex->{hoge}."\n";
print $ex->{piyo}."\n";
print $ex->get_hoge."\n";
基底クラス
package Example;
use strict;
sub new {
my $self = bless({}, shift);
$self->{hoge} = shift;
$self->{piyo} = shift;
return $self;
}
sub get_hoge {
my $self = shift;
return $self->{hoge};
}
1;
子クラス
package ExampleChild;
use strict;
use parent 'Example';
sub new {
my ($class, @args) = @_;
my $self = $class->SUPER::new(shift @args, shift @args);
$self->{fuga} = shift @args;
return $self;
}
1;
仮引数を名前付きで取るかshiftで取るかは微妙に悩む。shiftの方がPerlらしい気もするし、変数名を変更するときの手間を考えると楽ではある。しかしshiftは読みづらいし、名前付き変数を列挙したほうが読みやすい気もする。
今回Perlをある程度書いてみた感じ、Perlはかなり書き方が自由に感じたし、そこはかなり楽しかったが、コーディング規約という面で見ると自由すぎると困る部分もあるし、判り易いほうがいいのでshiftは避けたほうがよさそうだ。
しかし普段JSを書いたりしている中で、クラスとは新しいオブジェクトを返す関数なのでは？と思っていたので、その辺りの解像度が上がったのは良かった。
ぶっちゃけまともにPerlを書くのはこれが初めてなので、クラスとは直接関係ないサイトもある。
perldoc.jpは公式ドキュメントの日本語訳らしい。今も更新されている。