勉強会に長年出ていて思うこと
こんにちは @saka です。
吉祥寺.pm Advent Calendar 2025 - Adventar 11日目の記事です。
## いつから参加してたっけ？
勉強会自体は 新卒当時の会社の先輩に連れて行ってもらった2008年くらいの勉強会だったかな？もう昔すぎて覚えていない...
connpassを見返してみると吉祥寺.pmに初めて参加したのが
で、そこからご縁ができた方も増えました。
これ以前にも参加したかったのですがタイミングが合わず気がついたらすでに満席というのを２〜３度繰り返した記憶。ようやく参加できたなぁ。。。って思ったのを覚えています。
Magnoliaさんを会社に招いてプチ飲み会もさせてもらったなぁ。(随分前のお話し)
前回の大吉祥寺.pmでは昔一緒に働いていた人に何人か思いがけなく会うこともできました。そこからその人が開催する別の勉強会に参加するなんてこともありました。
懐かしい人たちに会えるのもまた良き。
## 長く参加していて良いなと思う部分
類似の話題の変遷を感じることができることだと思っています。
話す人は違うこともありますが、前回と何が違うんだろうか？っていうのを気にしながら自分は聞いています。
自分が直接知らないテーマでも技術の螺旋を擬似体験できるところが良いところ。
で、帰ってから手元でそれを参考にしながら、色々やってみるのが面白い。
## 吉祥寺.pmにこれから参加しようと思う方へ
なかなか参加できてないのですが、吉祥寺.pmに関しては懇親会が本体だと思ってます。
実際に本編で話された内容を突っ込んで話することも当然できますがそれ以外にも話が発展することが多く、そこで学んだことも今の業務に役立っていることが多いです。
懇親会で聞いた話で、障害対応の避難訓練や体制構築の話はそこから色々調べた思い出。
## 最後に一句
きちぴーで
重要なのは
懇親会
10年ぶりのScala day2:Scala3になっての変更点
Scala Features | Scala 3 — Book | Scala Documentation
と
Why Scala 3? | Scala 3 — Book | Scala Documentation
を読んでScala2から3の変更点を少し理解。
もうimplicitくんはいないのね。
不透明型？？？後で利点について整理しよう。
次はこちらへというところで時間切れ
今日は家庭の方で色々あったのであまり時間が取れなかった。
意識しないで読み始めたけどThe Scala Book 結構量あるな
全部理解しなくても簡単に使うのには支障がないんだろうけど、適切なクラスの実装ができなさそうなので一通りScala3ベースでの基本を理解しておこう。
明日も続く。
10年ぶりのScala day1:とりあえずHelloWorld
Scalaの人材がいないっていうつぶやきを見て、久しぶりに触ってみるやり取りになったので、実際に始めてみた。
自分が触ってた最後の年が2014年なので2.11か。
いまは3.4.2らしい。
入門 | Scala Documentation
公式に行ったら、ずいぶんと親切になっててびっくり。
無事にsbtのinstallもできたのでVSCode +metalを利用して一旦起動。
昔使ってたIntelliJのディレクトリだけ残ってたのでそこにsbtプロジェクトを作成。
今の会社がVSCodeなのでIntelliJのライセンス更新やめちゃったんだよな...
それだけ自分磨きをサボっていたということなので、反省しつつ一旦はVSCodeで進める。
coursierのPATHを通してなかったのでsbtコマンドが見つからないという初心者ムーブをかましつつ
```
$ export PATH="$PATH:/Users/sakamotomitsuru/Library/Application Support/Coursier/bin"
$ export PATH="$PATH:/Users/sakamotomitsuru/Library/Application Support/sbt/bin"
```
sbtコマンドが動くのを確認。
```
$ sbt
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jline.terminal.impl.exec.ExecTerminalProvider$ReflectionRedirectPipeCreator (file:/Users/xxxxxxx/.sbt/boot/scala-2.12.19/org.scala-sbt/sbt/1.10.1/jline-terminal-3.24.1.jar) to constructor java.lang.ProcessBuilder$RedirectPipeImpl()
WARNING: Please consider reporting this to the maintainers of org.jline.terminal.impl.exec.ExecTerminalProvider$ReflectionRedirectPipeCreator
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[info] welcome to sbt 1.10.1 (Oracle Corporation Java 12.0.1)
[info] loading settings for project hello-world-build-build from metals.sbt ...
[info] loading project definition from /Users/sakamotomitsuru/IdeaProjects/scala3/hello-world/project/project
[info] loading settings for project hello-world-build from metals.sbt ...
[info] loading project definition from /Users/xxxxxxxx/IdeaProjects/scala3/hello-world/project
[success] Generated .bloop/hello-world-build.json
[success] Total time: 2 s, completed 2024/07/26 23:44:52
[info] loading settings for project root from build.sbt ...
[info] set current project to hello-world (in build file:/Users/sakamotomitsuru/IdeaProjects/scala3/hello-world/)
[info] sbt server started at local:///Users/xxxxx/.sbt/1.0/server/002700689fa0a333c4e0/sock
[info] started sbt server
sbt:hello-world> run
[info] running hello
Hello world!
I was compiled by Scala 3. :)
[success] Total time: 0 s, completed 2024/07/26 23:45:04
```
動かしてみて気がつく。
sbtの起動ログに`Oracle Corporation Java 12`っていうのがある。
普段開発していない環境だというのがよく分かる。
Java更新はされないのねと思いつつopenjdkのパスを通してJavaのバージョンが上がったことを確認
```
$ echo 'export PATH="/usr/local/opt/openjdk/bin:$PATH"' >> ~/.zshrc
$ echo 'export CPPFLAGS="-I/usr/local/opt/openjdk/include"' >> ~/.zshrc
$ source ~/.zshrc
```
```
$ java --version
openjdk 22.0.2 2024-07-16
OpenJDK Runtime Environment Homebrew (build 22.0.2)
OpenJDK 64-Bit Server VM Homebrew (build 22.0.2, mixed mode, sharing)
```
もう一度HelloWorldにトライ。
```
$ sbt
copying runtime jar...
[info] welcome to sbt 1.10.1 (Homebrew Java 22.0.2)
[info] loading settings for project hello-world-build-build from metals.sbt ...
[info] loading project definition from /Users/xxxxxxxxx/IdeaProjects/scala3/hello-world/project/project
[info] loading settings for project hello-world-build from metals.sbt ...
[info] loading project definition from /Users/xxxxxxxxx/IdeaProjects/scala3/hello-world/project
[success] Generated .bloop/hello-world-build.json
[success] Total time: 1 s, completed 2024/07/26 23:52:57
[info] loading settings for project root from build.sbt ...
[info] set current project to hello-world (in build file:/Users/xxxxxxxxx/IdeaProjects/scala3/hello-world/)
[info] sbt server started at local:///Users/xxxxxxxxx/.sbt/1.0/server/002700689fa0a333c4e0/sock
[info] started sbt server
sbt:hello-world> run
[info] compiling 1 Scala source to /Users/xxxxxxxx/IdeaProjects/scala3/hello-world/target/scala-3.4.2/classes ...
[info] running hello
Hello world!
I was compiled by Scala 3. :)
[success] Total time: 3 s, completed 2024/07/26 23:53:12
sbt:hello-world>
```
ああ、なんかそれっぽくなった。今日はここまで。
明日はそのまま 入門 | Scala Documentation の 「次のステップ」 に進むことにする。
最終ゴールとしては、Cloud Runにアプリケーションをデプロイしたいものがあるのでそこまでやる。
PS4リモートプレイアプリでPS4に接続する際にPSN(PlayStaionNetwork)ログインで「サーバとの接続を確立できませんでした(18.xxxxxxxxxx)」エラーとなる場合の回避策
勉強会の記事とかじゃないです。すみません。
忙しかったのが少し落ち着いたのでPS4でもやるかと思ったらリモート接続できなくて30分ほど調べたので備忘録として残しておきます。
概要
こう言う状態をどう回避するか？と言う話。
なぜこの記事を書いたのか？
WIndowsだと回避手順を解説する動画とかが出回っているが、私はMacだったのでその方法が使えなかった。(もしかしたら似た方法で回避できるのかもしれないけど)
ちなみにその動画は「PSN サーバーとの接続を確立できませんでした」でgoogle検索すると上の方に出てくるはずなのでリンクは貼りません。
多分、自分の検索力が弱くてこの方法を見つけられなかっただけなんだろうけど、将来の自分ためのメモとして残しておく。
手順
セキュリティソフトのファイアーウォール機能をOFFにするだけです。
以下、説明
Sonyの別のサービスだけど、回避手順の参考になったので載せておく。
この手順の中でPSNの記述が出てくる。
このPlayMemoriesOnlineと言うアプリとPS4のリモートプレイアプリの立ち位置が同じなのでは？と考えたので同じ手順できないか？を試してみた。
この手順の中でPSNのアカウント管理画面にサインインできるか確認してくださいと言う記述がある。
セキュリティソフトウェア(※)のファイアーウォール機能を無効にします。
と言う記載があるのでその通りにすること。
この状態でもう一度PS4への接続を行ったら自分はログインできるようになった。(ちなみに自分は手順にあるキャッシュの削除などはやってない)
※ ちなみに使っていたセキュリティソフトは「カスペルスキー インターネットセキュリティ」のchrome拡張を入れていた。それ以外のセキュリティソフトやchrome拡張なしの場合に同じような状況を引き起こすかどうかは検証していない。
chrome拡張の表示
どれがファイアーウォール機能に該当するのかわからなかったので、ONになっていた以下の機能を全てOFFにした。
* ウェブ保護
* Webトラッキング
* ネット決済保護
* 危険サイト診断
ただし、Sonyさんのページに書かれているように、設定をOFFにするのは一時的にすること。ログインできたら忘れずに元に戻してください。
(もし。このページを見た誰かが同じようにやって戻し忘れても責任は負いません)
これで久しぶりにtsushimaにいける。
13-c-3 社内システムの構造と設計、実装のはなし
選んだ理由
- 今触っているサービスではオープンな部分の機能追加よりも、社内向けの情報を表示したり、連携したりする改修のほうが多いので、その参考に。
- よくあるダメダメな社内システムに対する改善を会社に伝えるときの参考。
ポイント
- 社内システムほど他システムとの連携をかんがえる。
- JSONAPIで連携するのが良さげ。
- OAuth流行、支配的になっている。
- WebAPIの使用制限(googleMap,他OpenWebAPI)
- トラフィック・レスポンスタイムを考慮する必要あり
- コストを払うのは誰なのかを意識すること
社内システムについて
- 性能より、機能があることのほうが優先される
- Long LifeCycle
- TargetUserが自分
問題点
- 情報と権限を管理する人が別
- 情報と機能の冗長化（悪い意味で）
- UXの欠如
- 自動化の障壁
- 全部入り -> アップデート不可能
- 社内システム連携 -> 危険極まりない
権限の分断を最小限に。
- 参照権限はフラットに、複数の方法で見れるように
- UIはAPIを使うのがBest
- 単機能ツールの連携で実現する -> アップデート容易性を担保する
- 機能はAPIとして公開する
- API互換性を担保すれば後ろ側を変えても問題ない
- プロトコル
- データ構造
- ドキュメントに頼らないことが大事
- 意味の一貫性
- Success -> OKとか
- クライアント要件の普遍性と不変性
- クライアントを含めて社内システムです
- 長期運用のことを考えると
- 見た目の分かり易さ
- アップデートの容易さ
- テストの容易さ
大事なのはコレ
- 1 times curl >>> 100 pages dosc
- ease to try >>> performance
- loosely coupled >>> strict protocol
「いま」欲しいものだけを作る
- 優先度ハック
- 機能を切り刻む
- 逆優先度ハック
- 細かい機能追加タスク
- 今いらないならあとで。
- 細かいからいつでもできるでしょう。
- 後でやればいいなら、今は作るな。
- 要件定義は難しい
- 開発・運用の前提がアーキテクチャをシンプルにする
社内システムほど試しやすいものはない -> だからいっぱい試してみようー。
13-b-2 グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～
このセクションを選んだ動機
同一チームでChefベースで構築されているImmutableなインフラがあるが、
自分が担当している方にも展開できるようにまずは基礎知識として蓄えたいと思った
Chefとは？
- Chef is Infrastracture as a Code
- 冪等性が担保されている(何も入っていない別のサーバに対して実行する場合の話のはず)
- altertableとかまでChefで行う場合は別テーブルに回避して、importするとかの処理を入れないといけない)
- Mutable-Infrastractureと相性良い(Immutable-Infrastractureであっても十分有用性はある)
導入背景
- Chefによる効率化
- オペミスの回避
- リードタイム改善（インフラチームに発注してからサーバをアプリチームに提供できるまで）
導入前の状態
導入
- 構成
chef
|- role
|- cookbookA
|- cookbookB
|- nodeの属性
- ChefSoloとChefServerの選択について
- 内製したChefBridgeについて
- nginxがstaticなファイルを提供
- GreeChefClient = ChefSoloのラッパーも準備している
- 自動テスト機能付き
- 汎用的につくられているだけあり、複雑
- 自社でCookbookを作成(以下により使える人を育成)
- 学習コストが高いが、Chef使える人を増やしていった(入門ChefSoloと初心者Chefアンチパターンは必読)
- 入門Chef Solo - Infrastructure as Code
- [和訳] 初心者Chefアンチパターン by Julian Dunn #opschef_ja « CREATIONLINE, INC.
- 社内用チュートリアル ... これはさすがに見つからない…
- 公式 docs.opscode.com 特にResources and Providers Reference — Chef Single-page Topics らしい
- 学習コストが高いが、Chef使える人を増やしていった(入門ChefSoloと初心者Chefアンチパターンは必読)
テストを書く
- テストの方法
- Serverspec/TestKitchen : ブラックボックステスト
- chefspec : ホワイトボックステスト
- FoodCrinic : Lintツール
- テストを書く理由
- TDD的な開発の後押し
- リグレッションを防ぐ
- ドキュメント代わり
- 本番サーバの構築テスト
- TestKitchen
- 単体test環境みたいなもの？
- [WIP](=進行中の作業)でPullRequestを投げる
- github - jenkins - ChefBridge で自動テスト
- 共通node設定はYAMLでjsonに変換して使用
事件：Jenkinsサーバに繋がらなくなった
- VertualBoxのHost-Only-Networkのルーティングが変わったため
- Chefで更新をかけるときは要注意
テストに時間がかかると...
Chef導入により改善された運用
- 何かしら障害があり、構築logが見たい場合
- 以前：screenコマンドで手動保存したものを検索
- Chef導入後 : 実行logはDBに保存(Chefのレポートハンドラ -> fluentd -> DB)
Chefを使うことによる利点として感じたこと
- インフラ構築の高速化
- インフラドキュメント= テストコード
- Chefにすれば、vagrantで同じ環境作りやすそう。
(ただ、その環境を使ってアプリの単体試験をするとなると、ローカルPCのスペックが要求される)
- Chef導入する際に、それにより何がデキるようになるのか？を意識してログやテスト方法を設計されていた？
