JJUG ccc 2023 fallレポート
概要
Javaを触ったのは研修の時だけなエンジニアがJJUG ccc 2023 fallに行ってきたよ。
Session一覧 https://sessionize.com/api/v2/2gdy2o95/view/Sessions
謝辞
2人目の子供が生まれたばかりなのにワンオペさせてしまった妻には感謝です。 ケーキと大福と夕飯を買って帰りました。
各セッションの感想
ブランチ運用とデプロイフローを見直してリリースを楽にする
フィーチャーフラグの話があったので気になったのですが、ちょっとお寝坊してしまい聞けずでした。
ブランチ戦略は現場でもほぼ同じような構成になってますね。
フィーチャーフラグも同様にDBの値で見ています。
はやくmain(master)ブランチにマージしたいって動機はとても理解できるのですが、外すときにも再度テストしなくてはいけないし場合によっては外すのが怖い場合もあるし管理しないと忘れさられるのでフィーチャーフラグをつけるかどうかっていうのは毎度確認したいですね。
できればif文で入れたくないなーって思ってますが、リプレース案件だと致し方ないかもしれない。
レガシーなWebサービスから世界標準への挑戦
決済手段がクレジットカード、コード決済、コンビニ決済等いろいろな決済サービスが乱立する現代で各事業者がそれぞれのサービスと契約・導入するとどうしたって手間とコストがかかるからそれを一括して担うプロダクトってめっちゃ需要はあるよなーと思いました。 ただ、やっぱし各事業者ごとの実装が入ってしまうっていうのはあるあるで、OpenAPIにしたところできっとそういうのはなくならないんだろうなと思ったり。 APIドキュメントとしてSwaggerは知っていましたがRedoclyは初耳でした。ほぼ同じようなもののようですがカスタマイズしやすさや見やすさはあるみたいです。 redocly.com
RFC7807では開発においてHTTP APIのために新しくエラーレスポンスを定義するのを避けるために、プログラムが読み取れるような問題詳細（Problem Details）をapplication/problem+jsonまたはapplication/problem+xmlで定義しています。 qiita.com
GitHub Copilot / Copilot Chat で Java コーディングを最大限効率化する
AIなしでは仕事ができない時代がもうすぐやってきそう。 まだ遅くないと思うのでGithub CopilotやChatGPTを業務に生かせるよう積極的に使っていこうと思った次第です。
この辺りでも盛り上がっていたのでますます温度感高くなりました。
持続可能なデータアーキテクチャを実現したリアーキテクティング
以前使っていたWealthNaviの技術的なお話でした。
資産のチャートを出すのにすべてRDSから計算で出していたようですがレコードが増えるにつれて計算量が多くなるのは必然ですね。
以下は自前のチャートです。
RDSで最新のものだけ表示し、過去の値はDynamoDB（NoSQL）に保存。
とにかくサイズを小さくしないとコストがバカにならない模様です。
長い期間のデータをとるとき、ある程度データって間引いているのかな？
データ指向プログラミングの真実をお話しします
X(旧Twitter)上で見かけたけど何が良くないのか本も読んでなくてわからなかったので聞きたかったセッション。 データ・情報・知識の違いを明確にするのなるほどと思いました。
結局、型安全に倒したほうがいいよねって人類来ているはずなのに、また逆行するのが書籍の「データ指向プログラミング」が推奨しているのがイケてないというお話でした。
複雑って何っていうところのお話も深堀りされていてなるほどなーと思ったのでした。
コード読んでて「複雑！わからん！」ってなっているのは基本は偶有的複雑さなので改善可能な部分も多いと思いました。
だれでもエヴァンジェリスト
ニュース読め？
エンジニアやってたら積極的に最新情報を取りに行くべき？ アンテナはることは重要だけど、興味のあるベクトルって人によって結構違うよね。 一昔前は新聞読めって言われてたかもしれないけど、最近では新聞取らない人も多いし、テレビを見ない人も多いですよね。
チームの情報をアップデートしよう
積極的に情報集めてる人って割合的に多くない気がします。 チームのレベルがあまり高くないとか、個々人が情報を得てないとかだと、化石になってしまいます。 レガシーシステムの開発ばっかりやっていたときは、MVCだけやってれば幸せでした。
何次情報でもいい
言語やフレームワークの変更を追うっていうのは誰もができることではありません。 その他さまざまな情報をいろんな方がインプットして、翻訳して、世界に対してアウトプットしてくれています。 そういった人にありがとうと感謝しつつ、受け取った情報を翻訳してチームにアウトプットする役目も大切だなって思います。
【読書感想文】 徹夜しないで人の2倍仕事をする技術三田流マンガ論 ─三田紀房流マンガ論─
書籍の概要
ベストセラー『ドラゴン桜』をはじめ、ヒットを飛ばし続けるマンガ家・三田紀房。彼の活躍を支えるのは、長いキャリアを経て築き上げた“成功の方程式”だ。「徹夜はしない。でも締め切りは守る」「企画は考えて出すものではない」「ベタを貫け」など、あなたの仕事を抜本的に進化させるノウハウをまとめて紹介。結果を出したい人、必読！
大雑把な感想
この人の漫画はドラゴン桜やエンゼルバンクやインベスターZも好きで読んでます。
この本自体はすごく読みやすかったです。構成やまとめのポイントとか流石だと思いました！
本書を読んでITエンジニアにも通づるところがあったので気になったところをメモしておこうと思います。
パフォーマンスが上がる環境づくり
日本社会の仕事の進め方は、ある種美徳とされている、「頑張り」に頼っているところがあります。個人の頑張りはもちろん大切。だけど、それが辛い環境だったら持続不可能です。
アメリカ社会では人のモチベーションやパフォーマンスが最大となるような環境づくりや仕組みづくりに重きをおいているようです。
ITのプロジェクトにおいてもチームの個人の頑張りにたよる働き方ではなく、自然と個人のスキルが上がるような組織作りチーム作りが必要だと考えます。
締め切りは絶対やぶらなない
漫画家は締め切りに追われてるイメージありますね。著者は絶対破らないと説いています。
なぜ 、ネ ームが遅れるのか 。それはマンガのスト ーリ ーの構想がそもそも弱いからだ 。企画段階で面白い構想ができていれば 、 １話 １話を作っていくときに迷わない 。
ITプロジェクトにあてはめるとネームはシステムのアーキテクチャや開発プロセスですかね。盤石なアーキテクチャの上で開発するならフィーチャーを実装する際にあれこれ迷いが生まれないだろうし、 開発プロセスが決まっていれば毎回考えることが減って、いいと思います。
自己満足に時間をかけるのはムダでしかない
実装における自己満足ってどういうのがあるだろうか。命名とかシンタックスとかかな。
本書では続いて店を開け続けろという示唆をしていたため、さっさとリリースしろってことなんだろうな。
ITプロジェクトだとサービス停止や技術的負債のリスクとかあるから多少必要な部分もあると思いました。
「針の穴」
著者は漫画のネタを考えるときに針の穴ほどに狭い領域をネタにするらしい。
これはキャズム理論に通じるところだろうな。サービスの立ち上げの際はニッチのサービスを突き詰めるところから始めるっていう。
なんとか食べていける状態は危険
現状維持は他が成長するうちに自分が底辺になって危険だということはこれまで何度か耳にしてます。DMMの亀山会長も同様のことを言っていましたね。
会社、サービス、個人にとっても成長してこそ現状維持なのかもしれません。
まとめ
漫画家の働き方とエンジニアの働き方には通ずるところがあるんだなという気づきと、改めて普段考えているところの再確認になったなという一冊でした。
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/185f500d.ce12b7c9.185f500e.9f6974bc/?me_id=1278256&item_id=16174352&m=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Frakutenkobo-ebooks%2Fcabinet%2F7224%2F2000004947224.jpg%3F_ex%3D80x80&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Frakutenkobo-ebooks%2Fcabinet%2F7224%2F2000004947224.jpg%3F_ex%3D240x240&s=240x240&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
ウェブ系エンジニアがはじめて技術書展6行ってきた
技術書展とは？
新しい技術に出会えるお祭りです。
技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。
技術書を中心として出展者はノウハウを詰め込み、来場者はこの場にしかないおもしろい技術書をさがし求める、技術に関わる人のための場として『技術書典』を開催します。
モチベーション
技術書展自体はよくtwitterやtogetterでも話題に上がり存在自体は知っていました。
今まで行ったことのなかったのになぜ行こうと思ったのかというと、
- 前職で一緒に仕事をした人が出店するから
- DevOpsDays Tokyoで挨拶させていただいた方が出店するから
- モチベーションを保つため
です。
最近、以前一緒に仕事をさせていただいた1だった方と宅飲みした際に、技術書展にサークルとして出るという話を聞いてたのでせっかくなので挨拶がてら行こうかなーって思ってたのが一つです。
また、先日開催されたDevOpsDays Tokyoで挨拶させていただいた方（黄色い服の方）も出店すると言われたので後押しになりました。
最近はカンファレンスや勉強会に継続的に参加することでモチベーションを保とうと思っていることもあいまった感じですね。
行くぞ！
午後に行こうと思っていたけど、朝ごはん食べて軽く仮眠をとったら13時だった！
約1時間かけてサンシャイン池袋展示ホールへ。
感想1：Fun!
まず思ったことが、どのサークルも楽しそう！ってことです。
楽しくないとチームとして続けられないし、技術の習得も続けられないと改めて思いました。職場にも生かしたいなという思いです。
あと、どこかの書籍で職場以外のコミュニティーに属しておくことも大事だよって言ってたので、そのうち勉強会でもなんでもなにかしらのコミュニティーに入りたいな。
感想2：ちょっと外の領域
普段、自分はWebアプリケーションを触っているので、Web系言語や組織論のようなところに興味があるのですが、ニキシー管やラズベリーパイを使ったハードウェア系、機械学習系、組織論系、テスト系、デザイン系、ボードゲーム系とか自分の領域からちょっと出たところのものが多くあって良い刺激になります。
JavaScriptのライブラリをつかって機械学習をして姿勢判定を行うやつなんてまさに自分が手を出そうとしていたところなので、面白そうです！（まだ読んでない）
感想3：知ってる人が結構いる
・以前一緒に働いた人
・DevOpsDaysTokyoで挨拶した人
・DevOpsDaysTokyoでカメラマンしてた人
・大学の学科が一緒だった人（顔忘れててごめんw）
購入本
情報を得るのにお金がかからない時代に、自費で製本して、買う人がいる、ってなんかいいですよねぇ。
DevOpsDays Tokyo 2019行ってきたよー Day1
Summary
DevOpsってよく聞いてたけど、よくわからんかったけど、いろんな人の話を聞いてDevOpsってサービスを開発して運用するための新しい働き方、組織のあり方、文化を作ること、なんだなあと思いました。 そのためには開発だけではなく事業部や編成などステークホルダーを巻き込んで文化を変えていくパラダイムシフトが必要そうだと言うことがわかりました。
講演
Lessons Learned Since The Phoenix Project
How do you migrate over 75,000 of the most demanding software engineers from infrastructure built up over decades of high-intensity work into a common engineering system based on modern software development technologies and best practices? This is exactly the challenge faced by Microsoft as they moved to their One Engineering system, a globally distributed 24x7x365 service hosted in Azure DevOps. Edward Thomson will explain how we did it, the lessons that we learned along the way, and some of the technical challenges that still remain.
The DevOps逆転だ！ 究極の継続的デリバリー[ 原題: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ] という著名な本があることを始めて知り、その著者の方の講演でした。ITオフィスでの運用における問題に対する対処、改善、組織改革を小説として書いた本のようです。読んでみようかと興味はあるのですが、結構分量があり、パラパラとめくると読み進めるの大変そうだなーと^^;
楽天ブックス: The DevOps逆転だ！ - 究極の継続的デリバリー - ジーン・キム - 9784822285357 : 本
—
Service Operation Centered Development - サービス運用をまんなかにおいた開発
サービス運用をまんなかにおいた開発についてお話します。
僕は2010年から楽天の大阪支社でウェブアプリケーションエンジニアとして仕事をしています。僕のいる部署は中規模から小規模のたくさんのサービスを担当していて、1つのチームまたはグループでサービスの開発と運用の両方を担当しています。
サービスの開発と運用の両方を担当しているため、僕らはサービスの運用のことを常に考えながら開発に取り組んでいます。運用のことを考えずに開発をすると全てが自分たちに跳ね返ってくるからです。 このセッションでは、サービスの運用をまんなかに置いて開発をするときに、どのようなことを考えるか、また、どのように他のチームや組織と向き合うか、について自分の経験を元にお話したいと思います。
Service Operation Centered Development - Speaker Deck
こういうチームで働きたいよね。
問題があるときは個人に問題を求めるのではなく場に問題があると考えたいです。
カーブの先を見るというのも、先を見越して勉強するとか、今後くる流れを見据えておくとワタワタしなくなって良さそうです。人生においてもカーブの先を見通しておきたいですね。
—
Behavioral Driven Development in DevOps: beyond the development!
In DevOps world is always a challenge monitoring the websites and application business and features health when it gets to the production environment. Testing and granting everything is working as expected, after deployed to production, is tough, and sometimes looks impossible.
During the website/web application development, we usually apply some techniques to achieve that: TDD and Automated Tests, BDD using a gherkin family tool and so on. It is often focused on Development itself and the automation usually finalizes on the last build to production.
BDDを行う上でシナリオを記述するのにガーキン言語というのを使おうと言う話がありました。
Given(前提), When(条件), Then(ならば), And(かつ), Or(または)などを使って自然言語で書こうという方針のようです。Gherkin Reference : Cucumber.
サービスがでかすぎて全部をテストしようとするとテスト兵士が必要なほどタイヘン！そんなリソースは現実的に用意できないし工期も伸びてしまう。だから必要十分なE2Eの自動テストを導入しよう！ということですね。
BDDな自動テストを書くことで、フロントから見た仕様がわかりやすくなる、自動テストが回る。という点でBDDは魅力的に思えます。今の開発にどうしたら導入できるか考えていきたいです。
