OmniAICreator/Qiita-1.07M huggingface dataset:
小売業界の価値を解き放ち、アリババクラウドで持続的な利益性を達成する

> 本記事は[こちらのブログ](https://www.alibabacloud.com/blog/unlock-value-and-achieve-lasting-profitability-with-alibaba-cloud-for-retail_601861?spm=a2c65.11461433.0.0.4ee353559N4sIW)を参考にしています。
> 翻訳にはアリババクラウドの[ModelStudio](https://www.alibabacloud.com/en/product/modelstudio)([Qwen](https://www.alibabacloud.com/en/solutions/generative-ai/qwen))を使用しております。

小売業界は、サプライチェーン、顧客行動、データの増加、持続可能性、労働力、インフレーションにおいて大きな変革に直面しています。勝つためには、小売業者は価値創造の手法を見直し、持続可能な成長を促進する新たなビジネスモデルと顧客向けオファーを採用する必要があります。クラウド技術の利用は、より優れた顧客体験、強化されたセキュリティ、効率的な運営を提供することなど、さまざまなメリットをもたらすため、小売業界で需要が高まっています。クラウドソリューションによる小売業界のメリット
在庫情報のリアルタイム追跡、管理、更新は小売業者にとって困難です。クラウドソリューションは、在庫情報をオンラインで利用可能かつアクセス可能な形で提供します。AIなどの高度な技術を活用することで、分析を強化し、正確な在庫と配分レポートを作成できます。AI駆動のCRMは、小売業者が顧客をより深く理解し、個性化された体験を提供する機会を与えるため、ショッピング体験がより予測可能になります。購入履歴、広告エンゲージメント、調査回答などの貴重なデータを追跡・分析できるようになることがAIの助けとなります。クラウドサービスのおかげで、従業員たちはシームレスで協調的、効率的なワークフローを楽しむことができます。クラウドコンピューティングは、ビデオ会議、ライブストリーミング、チャットアプリなど、ツールを通じてデータの一元化ビューを提供し、小売業各部门の業務を合理化します。クラウドベースのサービスは、すべてのビジネス機能を統合し、サプライチェーンの可視性を高め、エンタープライズアプリケーションをサポートします。また、機密データを保護するための多様なセキュリティサービスも提供します。小売業者は、クラウドサービスの実装とその本来のポテンシャルを引き出すことが難しいと感じることがあります。Click2Cloudは、クラウドソリューションの導入に関するベストプラクティスを提供して、この問題を簡素化しました。AIアセスメントからリアルタイム分析まで、最良の洞察を提供するために、AI駆動の移行計画、プロトタイプ、AIレポートが、円滑なクラウド移行のための包括的なロードマップを提供します。さらに、異なるクラウドプロバイダーを評価し、比較し、お客様に最適な選択肢を提案します。[小売業向け解決策](https://www.alibabacloud.com/ja/solutions/retail)として、[アリババクラウド](https://www.alibabacloud.com/ja/solutions/retail)を推奨しています。機能、価格、信頼性、互換性を検討した結果、アリババクラウドが最適であると判断しました。アリババクラウドの包括的なミッションクリティカルな小売業向けソリューション、クラウドサービス、ハードウェアにより、顧客とのやり取りにおける喜びとスピードが向上します。アリババクラウドで小売業の成長を加速する
アリババクラウドは、小売業界を再定義するための幅広いクラウド、データ分析、AI能力を提供しています。デジタルトランスフォーメーションを推進し、顧客の旅の各ステップで無接縁なオムニチャネル体験を実現することにより、成長を促進します。世界中の主要小売業者の専門知識と実践に基づいたアリババクラウドの小売業向けソリューションは、企業をデジタル時代に繁栄させる手助けとなります。アリババクラウドを利用することで、小売業者はエンタープライズクラスのセキュリティとプライバシー、最先端の基礎モデル、AI駆動アプリケーションを獲得できます。AIによって新しい洞察を得て、バリューチェーン全体で利益性を向上させます。アリババクラウドのAI駆動型産業解決策は、小売業者がクラウド技術を手軽に導入し、顧客獲得と維持、ショッピング体験の向上、商品陳列とサプライチェーン操作の効率化を実現することを支援します。アリババクラウド小売業向けで価値を解放し、持続可能な利益を達成する！• データ分析と店舗技術を活用して、顧客との関係を強化し、顧客との接触点でショッピング体験を向上させる。• エコシステム全体でデータをつなげることで、パフォーマンスを最適化し、回復力があり持続可能なサプライチェーンを構築する。• 生産性、協作、顧客満足度を向上させる小売業向けソリューションで、従業員を活性化させる。• 顧客のショッピングジャーニー全体でデータ源を統合して、包括的な顧客視点と明確な洞察を得る。免責事項：ここに表明される見解は参考のみであり、必ずしもアリババクラウドの公式見解を代表するものではありません。
Google Cloud Certified - Associate Cloud Engineer 合格体験記：Cloud Digital Leaderの経験を活かして一発合格！

## はじめに

前回、Google Cloud Digital Leaderの試験で得た教訓を活かし、今回は**Associate Cloud Engineer**の資格取得に挑戦しました。念入りな学習の結果、無事に一発合格することができました。本記事では、その学習方法や試験対策について詳しくご紹介します。

https://qiita.com/abachan/items/179bc1b03ca07fe04142

## 目次

1. [Associate Cloud Engineerとは？](#associate-cloud-engineerとは)
2. [Cloud Digital Leaderとの違い](#cloud-digital-leaderとの違い)
3. [学習計画の立て方](#学習計画の立て方)
4. [使用した教材とツール](#使用した教材とツール)
5. [試験当日の流れと注意点](#試験当日の流れと注意点)
6. [まとめ](#まとめ)

## Associate Cloud Engineerとは？

**Google Cloud Certified - Associate Cloud Engineer**は、Google Cloud Platform（GCP）の基本的な運用や管理、デプロイメントに関する知識とスキルを証明する資格です。具体的には、以下の能力が求められます。

- GCP上でのアプリケーションのデプロイと管理
- クラウドソリューションのモニタリングと運用
- 基本的なセキュリティの確保
- GCPリソースの設定と管理

https://cloud.google.com/learn/certification/cloud-engineer?hl=ja

## Cloud Digital Leaderとの違い

以前取得したCloud Digital LeaderとAssociate Cloud Engineerの主な違いは、試験内容の深さと範囲にあります。

- **Cloud Digital Leader**: クラウドの基本概念やGCPのサービス概要、ビジネス価値に焦点を当てた内容。
- **Associate Cloud Engineer**: GCPの具体的なサービスや操作方法、実践的なスキルに重点を置いた内容。

そのため、Associate Cloud Engineerの方が技術的な知識や実務経験がより求められる試験と言えます。

## 学習計画の立て方

### 1. 学習期間の設定

Cloud Digital Leaderの経験を踏まえ、約2週間の学習期間を設定しました。週に20〜30時間の学習時間を確保し、計画的に進めました。

### 2. 学習内容の整理

以下のトピックを重点的に学習しました。

- GCPの主要サービス（Compute Engine、App Engine、Kubernetes Engineなど）
- IAM（Identity and Access Management）の設定と管理
- ネットワーキング（VPC、サブネット、ファイアウォールなど）
- ストレージサービス（Cloud Storage、BigQuery、Cloud SQLなど）
- モニタリングとロギング（Cloud Monitoring、Cloud Logging）

## 使用した教材とツール

### 1. Udemyの動画コンテンツで基礎知識を固める

https://www.udemy.com/course/2022gcp-associate-cloud-engineer-google-cloud/

### 2. Udemyの模擬試験で演習

https://www.udemy.com/course/google-cloud-associate-cloud-engineer4200/

### 3. 試験前の最終確認
**Google Cloud Skill Boost**
Google Cloudが提供する公式の学習プラットフォームで、試験に向けたコースやハンズオンの受講が可能です。無料で利用できるため、最新の情報やサービスの詳細を学習するのに役立ちます。 


**Cloud Digital Leader公式模擬問題**
Googleが提供する公式の模擬問題集です。無料で受験可能で、本番と似た形式の問題に取り組むことができます。試験前に一度解いておくことをおすすめします。

## 試験当日の流れと注意点

### 1. 試験形式

- **試験時間**: 120分
- **問題数**: 50問
- **出題形式**: 単一選択および複数選択

### 2. 試験当日のポイント

- **時間配分**: 1問あたり約2分を目安に解答。難しい問題は一旦飛ばし、後で見直す戦略を取りました。
- **冷静さの維持**: 模擬試験での経験から、焦らず冷静に問題に取り組むことができました。

## まとめ

Cloud Digital Leaderの教訓を活かし、計画的かつ念入りな学習を行った結果、Associate Cloud Engineer試験に一発合格することができました。特に、ケーススタディ形式の問題に慣れるための模擬試験や、実際の操作を経験するハンズオンラボが効果的でした。

これからAssociate Cloud Engineer試験を目指す方は、以下のポイントを意識すると良いでしょう。

- **計画的な学習スケジュールの設定**
- **多様な教材の活用**
- **実践的な経験の積み重ね**

最後までお読みいただき、ありがとうございました。皆さんの合格を心より応援しています！
【OutSystems】AutoNumberは連続性が保証されない

## はじめに
OutSystemsでの開発において、エンティティを作成する際にAutonumber機能は非常に便利で利用する人も多いかと思います。
しかし、実際に使用してみて「あれ？」と思うことがあったため、その事象について紹介します。

## 動作環境
- OutSystemsの**バージョン 11**
- Oracle

## 事象
OutSystemsのAutonumberは、基本的に新しいレコードが作成されるたびに一意の番号を自動的に付与します。
しかし、実際にアプリケーションを運用していると、**新規データの挿入時に番号が連続しない**現象が発生しました。
下記の例では、下から順にレコードを挿入したにも関わらず、飛び飛びの番号が割り当てられてしまいました。

<img width="150" alt="image.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945506/6c16738b-2423-7e59-9d5e-c28f4e85998f.png">

この現象について[OutSystemsのforum](https://www.outsystems.com/forums/discussion/89191/primary-keys-auto-number-ids-append-issue/)を確認したところ、Autonumberは一意性の保証されるが、連続性は保証されないとのことでした。

## おわりに
Autonumberが連続しないという問題は、トランザクションのロールバックや並行処理、非同期処理の影響を受けるため、トランザクションの管理を適切に行うことで最小限に抑えることはできます。
ただし、OutSystemsの内部処理に依存している部分も多く、完全に回避することは難しいです。 
そのため、登録順にレコードを表示したい場合などがある場合は、Autonumberを使用したIdでソートするのではなく、別の属性を用意して対応することが良さそうです。

## 参考記事
https://www.outsystems.com/forums/discussion/89191/primary-keys-auto-number-ids-append-issue/
自己学習用お勧めDocs3選 + 個人運営の技術ブログ4選

私は、趣味が技術Docs読み漁りなのですが、愛用しているサイトやブログがいくつかあるので紹介します。

## Docs3選
### 1. [ネットワークエンジニアとして](https://www.infraexpert.com/)
**ネットワーク系の知識**（L2/L3、ルーティングプロトコル）がひとまとめになっています。これのおかげで**新卒2年目の終わりにCCNPを取れました**。

### 2. [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web)
**Web系技術については全てある**といっても過言ではないです。クラウドエンジニアの私に**Webの基礎**を教えてくれました。
（ちなみに、初めて調べたのは**CORS**について。）

### 3. [Cloudflare Learning Center](https://www.cloudflare.com/ja-jp/learning/)
**DNS？証明書？分からない人はまずここで調べてみましょう**。3つの中で、1番重宝しています。
（最近よく調べるのは**証明書とメール認証方法**について）

MDN Web DocsとCloudflare Learning Centerは英語で読めば、英語学習にもなって一石二鳥です。

他には、個人が運営してるような技術ブログもマニアックなネタの宝庫で好きです。

## マニアックな個人ブログ4選
### 1. [ねこまるのADフリーク](https://pkiwithadcs.com/)
AD DS、Kerberos認証の認証基盤のいろはを勉強する時非常にお世話になりました。富士通のActive Directory指南書より読みやすく、初心者向けです。

### 2. [Jake WalshCloud, DevOps, EUC, Infrastructure and more…](https://jakewalsh.co.uk/)
Azure×Terraformのための入門書、かつ英語の学習にもなるので一石二鳥のブログです。私はここにあるソースコードの写経から初めてTerraformを使えるようになりました。

### 3. [Ilya Grigorik](https://ilya.grigorik.com)
ShopifyのDistinguished Engineerの個人ブログです。「**意思決定を効率よくするには**」や、「**リスクは軽減するものでなく管理するもの**」といったマネジメントよりのソフトスキルについてのアイデアを吸収できます。
また、[High Performance Browser Networking](https://hpbn.co)にアクセスすると、オライリーから出版されている彼の著書「High Performance Browser Networking」を無料で読めるというとんでもない特典付きです。

### 4. [Alibaba Cloudの忘備録](https://www.bigriver.jp/)
Alibaba Cloudとありますが、Azureがメインテーマです。特にAzure Virtual Desktopのみ扱っている新のマニアック技術ブログで、1年目非常にお世話になりました。最近は更新が止まっているので少し寂しいです…。

ここまで読んでいただきありがとうございます。

Xではエンジニアに有益な発信をしていますので、ぜひフォローよろしくお願いします！！

https://twitter.com/satan_engineer
つよつよエンジニアへの第一歩: 新卒が初案件で得た教訓

# はじめに
こんにちは！
[「Develop fun!」を体現する！ Works Human Intelligence Advent Calendar 2024](https://qiita.com/advent-calendar/2024/advent-works-hi) 🎄
19日目を担当する k_uki512 です！🎉

私は、今年4月に新卒として入社した新米エンジニアです。
全体研修・部門研修を経て、現場配属され、10月から開発案件を任されるようになりました。
現在は小さい案件が中心ですが、初めて正社員として開発する上で様々な学びがありました。今回は僕が10月～12月の案件で学んだことを共有していきます。

## この記事を読んでほしい人

- 来年からエンジニアとして就職する新卒生・未経験エンジニア
- 個人開発の経験はあるが、企業でのチーム開発の経験は無い人

新卒の立場からお話しするので、<b>主にエンジニアを目指す学生がターゲットになります。</b>

## 筆者の経歴（前提）
- 情報系の学部を卒業
- 大学時代のキャッチアップは独学が中心
- 個人開発・開発インターンの経験はあるが、ゴリゴリのチーム開発は初めて

# 教訓１：目的とゴールを常に頭に置く

自分の中で、これが一番大事だと思っています。

目的は「タスクや物事を実施する理由」、ゴールは「達成したい最終地点」を指します。これらを明確にすることで、タスクに対する行動指針がはっきりし、スムーズな遂行が可能となります。

たとえば、上司に修正したソースコードを説明するMTGを想定します。この上司は案件の詳細を把握していないとします。目的とゴールを考えずにMTGに臨むと、ただ修正内容を述べるだけになり、上司には案件の全体像や修正の正当性が伝わりにくくなります。

そこで、MTGに臨む前に以下のような目的とゴールを意識します。

- 目的：修正内容に承認を得て、本番環境に変更を反映する
- ゴール：修正に至った背景と、その妥当性を上司に理解してもらう

このように目的とゴールをはっきりさせると、準備すべき内容が見えてきます。この場合には、修正の背景を説明する資料や、妥当性を示す証拠、説明する順序といった準備が必要です。

小さい案件から目的とゴールを意識する習慣をつけることで、より大きな案件にも柔軟に対応できるスキルが身についていくと考えます。


# 教訓２：目先の利益を追いすぎない
ここで私が学んだのは、<b>「修正に直接関係するコードだけでなく、修正が影響を及ぼすサブシステム全体も、多少時間がかかっても理解すべき」</b>ということです。

私は「ログイン機能」の不具合修正を担当していました。不具合の原因を調べたところ、「ログイン可能なユーザーかどうかを判定するSQLをDBに送信している箇所」に問題があると判明しました。

そこで私は、仕様調査を中断し、直接関係するソースコードのみを確認した状態で不具合修正を行い、PRを提出しました。

しかし、修正内容を説明するレビューを行った際に、<b>「画面上ではうまく動作しているが、ソースコード上では、成功している理由が曖昧」</b>といった状況になりました。

「タスクを早く完了させたい」という気持ちが強いほど、仕様調査をおろそかにしがちです。
サブシステム全体の処理フローを理解できるまでソースコードを読むことで、エンジニアとしての力が身につき、今後の案件にも対応できる能力を養えると感じました。

# 教訓３：チーム開発であることを意識する
ここでお伝えしたいのは、「製品開発は、過去・現在・未来にわたる大きなチーム開発である」ということです。大学時代には基本的に独学で開発を行っていたため、自分の書いたコードを他人に説明する機会は少なく、「今作っている機能や修正がとりあえず完了すれば良い」という甘い気持ちがうっすらとありました。

しかし、一つの既存製品を開発するということは、「過去にその機能を開発した人がいて、未来には自分が開発した機能に手を加える人がいる可能性がある」ということです。

このことを念頭に置き、

- 過去に開発した人の意図をソースコードから汲み取る
- 未来の担当者を意識して、可読性や保守性の高いコードを書く
といったことを大切にする必要があると学びました。


# 最後に
今回は、僕の社会人エンジニアとしての初案件で学んだことをまとめてみました。
案件の規模自体はまだまだ小さいものの、若手のうちから意識しておくことで後々大きな価値となると思える学びをたくさん得ることができました。

これからも、新たな学びを得つつ、既に学んだことにも意識して開発をしていきます。

文字の分量が多めの記事になってしまいましたが、ここまでお読みいただきありがとうございました。
Verylの（自分が提案・実装した）便利機能を紹介する

# Verylの（自分が提案・実装した）便利機能を紹介する

[Veryl](https://veryl-lang.org)は新興のHDLです。開発初期から機能の提案や実装などで、協力させていただいております。石谷が提案したVerylの便利機能を紹介したいと思います。

## `clock`/`reset`型

RTL設計においてクロック・リセットは特別な信号ですが、従来のHDLにはそれらを特別扱いする機能は無く、通常の信号として扱われます。ですので、順序回路を記述する際は、毎度毎度、クロック・リセットを指定する必要があり、非常に面倒です。

```verilog
always_ff @(posedge i_clk, negedge i_rst_n) begin
  if (!i_rst_n) begin
  end else begin
  end
end

always_ff @(posedge i_clk, negedge i_rst_n) begin
  if (!i_rst_n) begin
  end else begin
  end
end
```

また、クロック・リセット以外の信号も指定できるので、バグの元になりえます。

VerylはRTL設計に特化したHDLなので、クロック・リセットを表す特別の型として、`clock`/`reset`型が導入されています。これらの型を導入することで、Verylコンパイラはどの信号がクロック・リセットかを簡単に判別できるようになり、モジュールに入力されるクロック・リセットが１組しかない場合、`always_ff`でクロック・リセットの指定を省略することができます。

```verilog:元のVeryl
module ModuleA (
  i_clk: input  clock,
  i_rst: input  reset,
  i_d  : input  logic,
  o_d  : output logic,
) {
  var d: logic;

  assign o_d = d;

  // クロック・リセットを指定しなくても良い
  always_ff {
    if_reset {
      d = 0;
    } else {
      d = i_d;
    }
  }
}
```

Verylコンパイラは`i_clk`/`i_rst`がクロック・リセットだと判別できるので、SystemVerilog生成時にこれらの信号を`always_ff`文に自動的に挿入します。

```verilog:生成されたSystemVerilog
module project_ModuleA (
    input  logic i_clk,
    input  logic i_rst,
    input  logic i_d  ,
    output logic o_d  
);
    logic d;

    always_comb o_d = d;

    always_ff @ (posedge i_clk, negedge i_rst) begin
        if (!i_rst) begin
            d <= 0;
        end else begin
            d <= i_d;
        end
    end
endmodule
```

複数のクロック・リセットが入力されている場合、クロック境界を跨ぐ際に適切な処理ができていないと、重大なバグに繋がります。この種の問題の検出には、高価なEDAツールの導入が不可欠です。(自分が導入したわけではないですが)Verylでは、ある信号がどのクロックドメインに所属するかを指定することができるので、意図しないクロック境界跨ぎを検出することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/144465/5c313a1f-5062-25c3-85a5-aa922d2fe60b.png)

## リセットの抽象化

リセットの記述は、ASCIでは非同期リセット/負極性、FPGAでは同期リセット/正極性で記述するのが良いとされています。しかし、この両方に適応した記述を従来のHDLで記述することは非常に困難です。

```verilog:ASICの場合
always_ff @(posedge i_clk, negedge i_rst_n) begin
  if (!i_rst_n) begin
  end else begin
  end
end
```

```verilog:FPGAの場合
always_ff @(posedge i_clk) begin
  if (i_rst) begin
  end else begin
  end
end
```

しかし、Verylでは、`reset`型とリセット時の動作を記述する`if_reset`の導入により、リセットの極性および同期・非同期は隠匿され、SystemVerilogコード生成時に選択できるようになっています。つまり、以下のVerylコードから対象に適したリセット論理を持つSystemVerilogコードが生成できると言う訳です。

```verilog:Veryl
always_ff {
  if_reset {
    d = 0;
  } else {
    d = i_d;
  }
}
```

## `if`式と`case`式

最近のオシャレ言語では、従来、制御構文であった`if`や`case`が式として使えることが多いです。文中で同じ変数に代入する場合、これらの構文を式として使えると、代入が一か所だけになって、(ちょっとだけ)記述を簡略化できます。
例えば、カウンターの記述は`case`式を使うと、以下の様に書くことができます。

```verilog
count = case {i_up, i_down} {
  2'b10  : count + 1,
  2'b01  : count - 1,
  default: count
};
```

式なので、当然、以下の様にも書くこともできます。

```verilog
count += case {i_up, i_down} {
  2'b10  : +1,
  2'b01  : -1,
  default: 0
};
```

しかし、SystemVerilogには`if`式/`case`式は無いので、これらの記述は三項演算子を使って展開されます。

```verilog: 生成されたSystemVerilog
count <= ((({i_up, i_down}) ==? (2'b10)) ? (
    count + 1
) : (({i_up, i_down}) ==? (2'b01)) ? (
    count - 1
) : (
    count
));
```

処理系によっては、`if`文や`case`文と違って、MUXの最適化が効かないので、合成で不利になるかもしれません。
#クリスマスなので、勉強会運営委員会の1年を振り返る 2024

この記事は アイスタイル Advent Calendar 2024 25日目の記事です。

# 💭 ごあいさつ
皆さん、こんにちは。そして、メリークリスマス！🎄
良い勉強会日和ですね。
例年、クリスマスに活動をご紹介させていただいている私たちですが今年も活動内容や来年に向けてレポートを作成しましたので公開します！
今回の記事で弊社および当委員会に興味をもっていただけたら幸いです🍰

▼ 過去の勉強会運営委員会のアドカレ記事
2021

https://techblog.istyle.co.jp/archives/9360

2022

https://qiita.com/sakaguchii/items/a7250df7c741e3bd289d

2023

https://qiita.com/muratak-dev/items/e96b94adb0ece77a4bca


# 📚 勉強会委員会とは
勉強会運営委員会とは、2021年から本格的に始動したアイスタイル内で様々な勉強会を企画・運営し、最終的にはアイスタイルのエンジニアの市場価値を上げまくろうという組織です。

# 🎄 2024年のふりかえり
では早速今年の活動を振り返っての座談会をレポート形式でお送りします。

## ① 月次会改造作戦

弊社では去年から「月次会」という形でエンジニアが情報共有やナレッジをシェアする場を設け、勉強会委員会が運営していました。

### 月次会とは
毎月、部署ごとに発表者を募り業務上の成果やチームでの取り組みなど様々なテーマでオンラインで発信する場です。
苦労した点やうまくいった点を共有することで他部署に対しても知見が広がることや、発表者のアウトプット能力の向上やリモートワークでコミュニケーションが減る中で「この人はこういうことをしているのか」というのを月次で触れることでコミュニケーション面での向上を図る場になっています。

この月次会ですが、
・毎月のファシリテーション
・毎月ドキュメントを用意
・発表者が誰かを見つつタイムスケジュールを管理
・毎月のアンケート集計
などなどなど…毎月の運営のコストがかかっており、実は大変でした…！

「運営コストをどう減らすか」という話し合いの中で「月次会に限らず情報発信の場をエンジニアみんなで盛り上げるようになれたらいいよね！」という発言からそちらの方向性に舵を切り、無事2024年中に勉強会運営委員会が都度面倒を見なくても自走する月次会を作り上げることが出来ました！

こちらについては内容がボリュームたっぷりなため別の記事でご紹介します！

また自走化とは別の施策として月次会に「自己紹介タイム」を導入しました。
もともとは「エンジニアがナレッジを共有する場」として運営していたのですが「せっかくみんなが集まる場だし、これから一緒に業務を行うメンバーになるのだからここで自己紹介しても良いのでは…？」という思い付きから導入してみたのですが、今ではすっかり恒例の時間になりました。
リモートワーク環境になり、他の部署の人がいつ入社したのか、どんな人なのか…というのが分かりづらくなってしまったからこそ、こういった時間を継続していきたい所存です。

## ② 蔵書整理

### 💻電子書籍サービス試験運用
リモート環境でも会社が管理している蔵書をエンジニアが読めるようにしたいという目的のもと電子書籍サービスの試験運用を行いました。結論から述べると利用数とコストを比べた結果、採用することは見送りましたが、「会社が管理している蔵書を利用しやすくしよう」という目的をもとに後述の別の取り組みへとつながりました。

### 📚本棚の整理及び管理方法の電子化
弊社では技術書の本棚があるのですが、現在のリモート業務体制が導入される以前から運用されていたということもあり紙での管理になっていました。現在のリモート環境において「何の本が会社にあるか分からない」「出社して本棚に行ってみたら誰かが借りている最中だった」という課題感が出てしまうため、これを解消すべく管理表をスプレッドシートで行うよう変更しました。

## ③ テク子の部屋
去年（ https://qiita.com/muratak-dev/items/e96b94adb0ece77a4bca ） に引き続き今年もテク子の部屋を開催しました！

### 🍍テク子の部屋とは
Slackハドルミーティングを使ったラジオ番組風のトーク社内イベントです！
業務への取り組み方から、アイスタイルに所属する前の話、他にもプライベートの過ごし方やデスクの上の紹介などなど、「普段のその人がどんな人か分からない」というのを解消できたらいいな～ということを目的として企画を運営しています。


## ④ イベントに関する取り組み
今年の社内外での勉強会（イベント）に関連する開催や、開催協力についての振り返りです
### 🎅去年のアドカレの振り返り開催
みんなで作ったアドベントカレンダーを書いてそのままにするのはもったいない！ということでオフラインでの振り返り会を開催しました！
各々の記事の内容をオフラインで振り返るのはもちろん、「いいね数賞」「文字数ベスト賞」などなど賞を作りお祭り感を出しながらピザや飲み物を囲んでワイワイ楽しむ振り返る会となりました。

### 📝LT共同開催
「リプレイス事例」「フロントアーキテクチャ改善NIGHT」というテーマのLTを共同開催＆登壇しました。
それぞれ当日の発表概要や資料などは下記connpassよりご確認ください

https://hireroo.connpass.com/event/310150/

https://istyle.connpass.com/event/311938/

### 🚩JSConf JP 協賛
2024年11月23日に開催される「JSConf JP 2024」にスポンサーとして協賛しました！

https://jsconf.jp/2024/

詳しくはこちらの記事をご覧ください！

https://techblog.istyle.co.jp/archives/9661

https://techblog.istyle.co.jp/archives/9708


## ⑤ Qiita記事執筆推進活動
毎年恒例になりつつアドベントカレンダーですが、今年も無事全部の日付が埋まったカレンダーを準備することが出来ました👏👏
また、夏に開催された「Qiita Engineer Festa 2024」にも委員会より宣伝し複数人の方が参加してくれました！

https://qiita.com/official-campaigns/engineer-festa/2024
# 👋 最後に
来年も引き続き元気よく活動していこうと思います！
お読みいただきありがとうございました。良いお年を！
抽象クラスとジェネリクスを組み合わせて活用する

# はじめに

こんにちは、Gakken LEAP のエンジニアの okamoto です。
Javaで複数種類のCSVファイルを読み込み、それぞれに対応した処理を行うコードを実装した際、ファイルごとに異なる型でデータを管理する必要がありました。
この際に、抽象クラスとジェネリクスを活用することで、拡張性や再利用性が向上しました。
本記事ではその際に活用した各技術の簡単な紹介と、それらを組み合わせたアプローチを紹介します。

# ジェネリクス（総称型）とは

簡潔に表すと「いろんな型に対応できる箱を作る仕組み」 です。
ジェネリクスを使って定義する際には<>の中に任意の文字列を入れられますが、
T（type）を入れるのが一般的です。
※他にもE（element）やK（key）V（value）などもあります。

```java
// 型を後から決める箱
class Box<T> {
  // ...省略
}

// 使うときに自由に型を決められる
Box<Integer> intBox = new Box<>();
Box<String> strBox = new Box<>();
Box<Object> objBox = new Box<>();
```

# ジェネリクスにおけるワイルドカードとは

上記のように<>内で型を明確に指定しなくても宣言することができる仕組みで、
「箱の中身の型が曖昧」な場合に利用できます。
型の上限(? extends [Type])、下限(? super [Type])を制限することもできますが、本記事では割愛します。

```java
// 型を後から決める箱
class Box<T> {
  // ...省略
}
// どんな型のBoxでも参照可能
Box<?> wcBox = new Box<String>();
wcBox = new Box<Integer>();

Object data = wcBox.get(); // 取り出すときはObject型になる
```

# 抽象クラスとは

すべての実装を行わず、サブクラスたちで共通化したい処理のみ実装し、
その他は曖昧なまま定義を行い、それを継承したサブクラス側で具体的な実装をする、
「共通の機能を持たせるための『ひな形』」です。

```java
// 抽象クラス
abstract class Hoge {
    abstract void printClassName();
    void printHoge() {
        System.out.println("Hoge");
    }
}
// サブクラス1
class Fuga extends Hoge {
    @Override
    void printClassName() {
        System.out.println("Fuga");
    }
}
// サブクラス2
class Piyo extends Hoge {
    @Override
    void printClassName() {
        System.out.println("Piyo");
    }
}
Hoge fuga = new Fuga();
fuga.printHoge();      // 出力：Hoge
fuga.printClassName(); // 出力：Fuga
Hoge piyo = new Piyo();
piyo.printHoge();      // 出力：Hoge
piyo.printClassName(); // 出力：Piyo
```

# 抽象クラスとジェネリクスの組み合わせ

以下はジェネリクスを使用した抽象クラスと、それぞれ異なる型でデータ管理するサブクラスです。

```java
// 抽象クラスをジェネリクスで定義する
abstract class InputCsv<T> {
    private T csvData;
    public T getCsvData() {
        return csvData;
    };
    public void setCsvData(T inputCsvData) {
        csvData = inputCsvData;
    };
}
// サブクラス1
class Csv1 extends InputCsv<Entity1> {
    // csv1用の処理
}
// サブクラス2
class Csv2 extends InputCsv<Entity2> {
    // csv2用の処理
}
```

これらのクラスを作成し、下記のようにループの中でワイルドカードを使用してインスタンスを生成することで、処理対象のCSVファイルが増えたとしても大きく手を加える必要がなくなります。

```java
// 読み取り対象のCSVリストを順に処理する
for(String csv : csvList) {
    // ファイル名から利用するインスタンスを取得する
    InputCsv<?> inputCsv = getCsvInstanceService.get(csv);
    // ...後続の処理
}
```

# おわりに

本記事では、抽象クラスとジェネリクスを組み合わせた柔軟で拡張性が高い実装を紹介しました。
さらに型安全性を高めるには今回は割愛しているワイルドカードの上限を設定することで実現できるかと思います。

## エンジニア募集

Gakken LEAP では教育をアップデートしていきたいエンジニアを絶賛大募集しています！
ぜひお気軽にカジュアル面談へお越しください！
https://gakken-leap.co.jp/recruit/
Aerospaceで外部ディスプレイにWorkspaceを固定する設定方法

この設定を書いておくと、0-9のWorksapceを外部ディスレプイに固定できる。

```
[workspace-to-monitor-force-assignment]
1 = 'secondary'
2 = 'secondary'
3 = 'secondary'
4 = 'secondary'
5 = 'secondary'
6 = 'secondary'
7 = 'secondary'
8 = 'secondary'
9 = 'secondary'
0 = 'secondary'
```
ハッカソンで結果を出すためのTips集

# はじめに
この記事は「[ソニックガーデン 若手プログラマ Advent Calendar 2024](https://qiita.com/advent-calendar/2024/sonicgarden-junior)」21日目の記事です。

ソニックガーデンでは、若手を対象に「弟子ハッカソン」という社内ハッカソンを実施しています。
このハッカソンは、2024年2月から始まり、12月まで毎月開催され、記事投稿時点で合計11回が実施されています。
それに加えて、私自身も社外のハッカソンにも参加していたりと、それなりの回数のハッカソンを経験することができました。

その中で、自分なりのハッカソンのTipsがまとまってきたので、ご紹介したいと思います。

## 準備編
### 早く始める
できる限り早く始めましょう。時間は多い方が良いです。
始めれば楽しくなって開発も進みます。
また使う技術によっては、手続き等に時間を要する場合があります。
実際に遭遇したケースでは、「証券会社のAPIを使いたいが、口座開設が必須で開設に1~2週間かかるため間に合わない」などがありました。

### チームならリーダーを立てる
リーダーを立てることで、物事を決めるときにグダリにくくなり、スピードを出すことができます。
本当はみんなが全てのことを理解して主体的に動ければ最高です。
でもそれは難しいので、便宜上でもリーダーを立てておくと良いです。

### 審査員一覧をはじめに眺めておく
ハッカソンは技術系なのかビジネス系なのかでカラーが結構違います。
それはテーマだけでなく、審査員の人選でも大きく左右します。
なので、誰に対して発表するのかを最初に意識しておきましょう。

成果物だけでなく、プレゼンの内容にも「技術用語をどれくらい使うか」などの点で影響してきます。
可能であれば、プレゼンのリハーサル時、審査員になりきるつもりで見直してみると良いかもしれません。

## アイデア出し編
### 評価観点が公開されているなら、全て意識しておく
評価観点が公開されているということは、その観点を踏まえて評価されるということです。
採点方法についてはさまざまですが、「それぞれの観点について投票される」のような方法の場合、観点を外すと悲惨なことになります。
極端な例ですが例えば、４つの観点があり各25点配分の場合、一つの観点を無視しただけで最高点が75点になります。
そのため可能ならば、全ての観点への回答を用意しておきたいです。

### 個人参加の場合でも、可能なら誰かとブレストして案を出す
一人で考えていると思考が硬直しがちです。
他者と話すことでアイデアにも化学反応が起きます。
他チームと被らせないためにも、自分だけでなく人のアイデアも取り入れてユニークなアイデアを出しましょう。

### 無難に安定、ではなく攻めて優勝を狙う
ハッカソンでは基本的に上位しか賞がないので、攻めましょう。
ハッカソンは安定ではなく優勝を狙いに行くゲームです。

### 思いついた中でも、自分が興味のあるものを作る
楽しく作れるからです。楽しいと時間が多く使えてクオリティも上がります。
そして、知っているジャンルなら自分の中に情報や経験があることでしょう。
結果的にプレゼンに説得力が出たり、自信を持って話すことにもつながります。

### 「楽しさ」を意識する
結局ツールとしての良さって、「使っていて楽しいか」に左右されると感じます。
アイデア出しの時点でのワクワク感はある程度信用して良いと思います。

### LLMは使うなら何かと組み合わせる
LLMはみんな使うので、単品だけだと「またか......」という印象を与えやすいです。
個人的には「裏側に人間がいる」と錯覚させられるような捻りがあると良いと考えています。
つまりは、視覚や聴覚も使うとか。

## 実装
### 技術検証をする
何か問題が起こると、最悪それまでの全てが吹き飛びます。後から発覚して大きな手戻りを引き起こすより、事前に技術検証をしましょう。
例えばAPIならば、単体で叩いて問題なく使用できるか検証できるはずです。


### deployする
基本、実際に触れた方がイメージが良いです。
必須ではないので、動かないくらいならローカルで動かせば良いでしょう。

### プラスアルファを考える
ハッカソンが終わった時、大体「あれができていれば」、「これ追加できたな」とか思いつきます。
そして、そういったプラスアルファが勝負を分けることも多いです。
それを期間内に捻り出して、成果物に追加しましょう。

## プレゼン編
### プレゼンはリハーサルをする
大体の場合、リハーサルをすると問題が発覚します。
本番で問題が発覚しても手遅れです。事前に洗い出しておきましょう。
もし余裕があれば、動画撮って見直せれば最高です。意外と、喋る時の癖は気がつけないものです。
そして、本番はリハーサル通りにしましょう。
余計なことをすると、未知のバグとの遭遇などイレギュラーの原因になります。

### プレゼン用の原稿を書く
プレゼンの内容がよくなります。
それだけではなく、不測の事態への備えにもなります。
プレゼン本番はアガってしまったり、イレギュラーで内容が飛んだりします。
そういった場合も原稿があることで、道から逸れたときに戻るための道標になります。
原稿を書く時間がない場合は、箇条書きにして喋る内容を整えておくだけでも良いです。
ないよりはだいぶマシになります。

# まとめ
以上、ハッカソンで結果を出すためのTips集でした。
結局のところ、ハッカソンの結果はアイデアや実装力で決まるのですが、これらに気をつけることで「落とし穴」の数は減らせるはずです。
皆様のハッカソンライフがより良きものになるよう、役立てば幸いです。

-----

「[ソニックガーデン 若手プログラマ Advent Calendar 2024](https://qiita.com/advent-calendar/2024/sonicgarden-junior)」22日目は@Ito-Misakiです。お楽しみに！
JS7®コントローラー／エージェントの自動登録スクリプト記事公開

JS7®では、JOCコックピット／コントローラー／エージェントのインストール後に、JOCコックピットのWEB GUIからコントローラー／エージェントを登録しなければいけませんが、スクリプトを使用してのコントローラー／エージェントの自動登録ができるようになりました。

弊社山下が連携方法記事を公開しましたのでお試しください。
https://qiita.com/Yoshitami/items/01b29099e3b7b9161f90
英語が苦手な私がオフショア開発に挑んだ話

# はじめに

はじめまして！
普段はAWSの設計構築や、Pythonでバックエンド開発をしている5年目エンジニアです。
今回は、今年1年で最も刺激的だった「オフショア企業[^1]と共同開発した経験」から得た学びについて共有します :flag_in: :curry: :fire:
本記事はオフショア開発の経験に基づいていますが、国内案件にも役立つヒントがあると思います。
ぜひ最後までご覧ください！
[^1]: オフショアとは、コスト削減や効率化を目的に、海外の企業や拠点に業務を委託したり、開発を行ったりすること

# プロジェクトの概要

本プロジェクトの目標は、旅行会社の既存会員基盤を廃止するため、1から新しい会員基盤を構築することでした。
以下に、プロジェクトの特徴をまとめます。

- **開発期間：** 要件定義から設計、実装まで約1年間
- **チーム構成：** 日本人2名＋インド人7名（※ブリッジエンジニア[^2]は不在・・・）
- **開発手法：** アジャイル開発
- **コミュニケーション：** 週1回のオンラインミーティング
- **技術スタック：** 詳細は割愛

[^2]:ブリッジエンジニアとは、海外企業と日本企業の橋渡しをする人、日本企業に代わって海外企業に指示を出し、管理するエンジニアのこと

# ぶつかった壁

### 言語・文化の違い

英語が苦手な私には議論するだけでハードルが高いのですが、その上コミュニケーションスタイルの違いや、働き方の文化的な違いに戸惑いました。
YES/NOだけをとっても、ニュアンスの違いで認識の齟齬が発生することもありました。

### 正確なビジネスロジックの共有

日本人である私でも、なぜこうするのか？と思うような要件があったり、日本特有または旅行会社特有のビジネスモデルがあったりと、用語や概念を共有するのに苦労しました。

### 双方向コミュニケーションの不足

特にオンライン会議では一方的な情報共有になりがちで、現地チームの意見や疑問を引き出すのが難しかったです。

# 課題解決のために実施したこと

これらの課題を解消するため、インドに1週間滞在してワークショップを開催しました。
以下に、その具体的な内容を紹介します。

### アイスブレイク

ワークショップの冒頭では、参加者の自己紹介に加えてクイズを出してもらうなど、リラックスできる雰囲気を作りました。
また、ランチやティータイム（日本にも欲しい！）では現地の料理を一緒に楽しみ、退勤後にはショッピングやディナー、スポーツを通じて交流を深めました。

### ビジネスロジックと目標の共有

事前に準備したドキュメントを使い、ビジネスの背景や目標を重点的に説明しました。
使用した手法やドキュメントは以下の通りです。

#### インセプションデッキ

> インセプションデッキとはThoughtWorks社のRobin Gibson氏が考案したものでアジャイル開発の現場でも多く取り入れられる「これからスタートするプロジェクトの全体像（目的・方向性・優先順位・開発環境など・コストや人材・背景）をプロジェクトメンバーが相違なく認識する為に作成するドキュメントです。

https://crowd.itpropartners.com/pieceblog/4158

![代替テキスト](https://crowd.itpropartners.com/pieceblog/wp-content/uploads/2020/08/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88-2020-08-29-17.25.40.png)
上記の10個ある質問の中から下記の4つを作成しました。
- 我々はなぜここにいるのか
- エレベーターピッチ
- やらないことリスト
- トレードオフスライダー

#### カスタマージャーニーマップ

> カスタマージャーニーは、顧客の日常生活から、購入の検討段階、実際の購買（利用）段階までに接触しうるさまざまなタッチポイントについて、包括的に捉えるものです。

https://satori.marketing/marketing-blog/how-to-make-customer-journey-map/

上記の他にも、AWSのアーキテクチャ図、ER図、日本特有の用語や概念をまとめたドキュメントなどを作成していきました。

### 成果物の作成

:star: ここから先の内容は2チームに分かれて実施しました :star:
（私ともう一人の日本人メンバーも1人ずつチームに入ります。）

- ユーザーストーリーマッピング
- ユースケース図
- 画面設計書
- API仕様書
- モックアップ

### チーム間レビュー

作成した成果物をチーム間で共有し合い、相互レビューを実施しました。
担当外の部分に対する質問や意見交換を通じて、プロジェクト全体の理解を深めました。

# 効果的だったポイント

ワークショップを通じて得た成果を、私なりの解釈で説明していきます。

### 合意形成を効率化

リアルタイムの議論を通じて、その場で解釈の違いを修正しました。
また、ホワイトボードを活用してアイディアを視覚化しながら議論を進めることで、イメージを具体的に共有することができました。
結果、迅速な合意形成が可能となり、後工程への移行をスムーズに行うことができました。

### 双方向コミュニケーションの強化

シャイなメンバーからも意見が引き出され、活発な議論が行われました。

### 独創的なアイデアの引き出し

ブレインストーミングやディスカッションによって、現地チームならではの新しい視点やアイデアが生まれました。

### 信頼関係の構築

オフショアパートナーはトップダウン型の指示に従うことが多い一方、今回のワークショップでは、私たちもメンバーの一員として各チームに参加することで、同じ目線でディスカッションができました。
結果、現地チームのモチベーションアップにも繋がったと思います。

# まとめ

様々な困難があるオフショア開発にワークショップを取り入れるのは効果的！

# おわりに

今回の経験は、先輩社員のリードやチーム全体の協力があってこそのものでした。
帰国後、私自身もこの経験を活かして、社内でワークショップを開催してみました。

この記事を読んでくださった皆さんも、ぜひオフショアや国内チームで試してみてください！:sparkles:
Azure 理想と現実


# 構成

![スクリーンショット 2024-12-17 15.53.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/44351/92e2f24e-2a7d-0ea3-efdc-1dc31929a0ba.png)

# 

| 理想        |　現実        | 理由         |
|:-----------|:------------|:------------:|
| Microsoft Entra ID   | Microsoft Entra ID | WebアプリのログインをSSOに！ |
| DNS (パブリック)       | DNS (パブリック)    | パブリックDNS ゾーン        |
| Vnet                 | Vnet               | 仮想ネットワーク            |
| Front Door (Premium) | -                  | Premiumが高い             |
| Front Door (DDoS保護,WAF) | Front Door (WAF)| Front Door (Premium)を採用しないため<br>せめてFront Door (Standard)でWAFだけでも。。。|
| Static Web App (プライベート エンドポイント) | Static Web App (パブリック) | Front Door (Premium)を採用しないため<br>https://qiita.com/kaihei777/items/9e5695dd955c572fdb54       |
| Static Web App (API)    | Static Web App (APIリンク)| Front Door (Premium)を採用しないため |
| -                    | Functions (仮想ネットワーク統合)  | Front Door (Premium)を採用しないため |
| DNS (プライベート)       | DNS (プライベート)    | プライベートDNS ゾーン        |
| Azure Database (高可用)     | Azure Database  (高可用)          |
| Virtual Network Gateway      | Virtual Network Gateway    | 運用管理用VPN  |
| Storage (BLOB)      | Storage (BLOB)    | ストレージ アカウント  |
| Application Insights     | Application Insights   | パフォーマンス監視,エラー検出,アラート  |
| Backup Vault      | Backup Vault    | ストレージやデータベースのバックアップ |
2024 年 マイクロソフト製品・サービスの脆弱性を振り返る

いよいよ今年も終わりが近づいてきています。みなさん、今年のセキュリティはどうでしたか？
わたしは相も変わらずマイクロソフト製品やサービスの脆弱性を対応して、世の中の脆弱性を分析して過ごしました。

ということで、今年のマイクロソフト製品・サービスで修正した（公開した）脆弱性を振り返ってみましょう。
注意：この記事の内容は、公開時点（12月18日）の情報に基づいています。この後、脆弱性の修正が出た場合は統計に変更が生じます。


## マイクロソフト製品サービスの脆弱性の総数
2024年、マイクロソフトは合計で1093件のマイクロソフト製品・サービスの脆弱性を修正しました（Chromiumなど、マイクロソフト以外の組織によって管理されているコンポーネントの脆弱性を除く）。

昨年は957件の脆弱性を修正しており、脆弱性の数だけを見ると、「増加」ということになります。しかし、セキュリティ研究の進展により新たな脆弱性や攻撃手法が日々発見されることや、サポートしている製品数の増減などがあるため、一概に脆弱性の数が製品の安全性を直接示すわけではありません。
それと、今年の脆弱性が増加している一つの要因としては、今年からマイクロソフトは、製品利用者が更新作業を必要としない脆弱性（主にクラウドサービスの脆弱性）についても、CVEを採番し情報を公開し始めまたことも挙げられます。(参考：Microsoft [透明性の向上に向けて : クラウドサービス の CVE の公開について](https://msrc.microsoft.com/blog/2024/07/toward-greater-transparency-unveiling-cloud-service-cves-ja/) )　今年は、製品利用者が更新作業を必要としない脆弱性として、23件の脆弱性を公開しました。

製品別の脆弱性修正数を見ると、Microsoft Windows製品が676件と最も多く、次いでSQLサーバー、Microsoft Office関連製品（SharePoint含む）、AzureサービスおよびAzure管理ツールが続きます。Windowsは多岐にわたるコンポーネントを含み、製品数も多いため、脆弱性が多くなる傾向にあります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3031633/31975f59-e33e-db26-1ab1-03eb4622c87d.png)

図1: 製品カテゴリ別の脆弱性修正数 


## ゼロデイの状況
修正プログラムが公開されるよりも前に悪用を確認していた脆弱性（いわゆる “ゼロデイ” の脆弱性） は、26 件でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3031633/b29eb798-78e8-eb64-ed3d-1fbc067d65ff.png)
図2: 製品カテゴリ別のゼロデイ脆弱性の数と影響
Server製品カテゴリは、Microsoft Exchange の 1 件
Microsoft Office 製品カテゴリは、MIcrosoft Project, Microsoft Publisher のそれぞれ 1 件

悪用されるマイクロソフト製品の脆弱性の多くは、特権の昇格、セキュリティ機能のバイパス、なりすましといった種類に分類されます。この分類の脆弱性では、攻撃者はすでにユーザーのIDとパスワードを入手して認証できる状態にあるか、フィッシングなどでユーザーを騙して脆弱性を悪用します。脆弱性を利用することで、サンドボックス環境を抜け出してコードを実行したり、管理者などの高い権限を取得して目的を遂行しようとします。
今年は、Windowsのゼロデイ脆弱性が報告されたコンポーネントは多岐にわたり、特定の「注目される」コンポーネントに偏ることなく、さまざまな攻撃手法がみられました。



## 脆弱性を見つめていると
今回は、ざっくりと、速報版として、マイクロソフト製品・サービスでの脆弱性の統計をご紹介しました。
ちなみに、私が今年一番注目した脆弱性の悪用は CVE-2024-7971 (Chromium) と CVE-2024-21338 (Windows Kernel) です。みなさんはどれですか？

ソフトウェア・サービスの脆弱性は、新しいトピックではありません。でも、悪用された脆弱性の詳細な分析、マイクロソフト以外の製品も含めた脆弱性の分析をして、そしてそれらを毎年継続していくと、色々な事が見えてきます。
このあたりの詳細な話を書きたかったんだけど、ながーーーーーくなって終わらなくなってきたので、今日はこの辺で.... またどこかでみなさんに共有したいなと思ってますので、興味のある方はぜひその機会に色々ディスカッションしましょう。


それでは、みなさま Happy Holidays 🎁
Google Cloud Certified - Cloud Digital Leader合格体験記：AWS経験者が挑んだ結果と攻略法

## はじめに
AWS Solution Architectの資格を持っていた私は、GCPの**Cloud Digital Leader**試験も容易に合格できるだろうと高を括っていました。しかし、結果は**不合格**。AWSの知識だけでは通用しないGCP特有の壁を痛感しました。

この記事では、私の経験をもとに以下の点を詳しく解説します。

- **1回目の不合格の原因**
- **2回目に合格するまでの勉強方法**
- **Cloud Digital Leaderに合格するためのポイント**


## 目次
1. [Cloud Digital Leaderとは？](#cloud-digital-leader%E3%81%A8%E3%81%AF)
2. [AWS Solution Architectの知識で挑んだ1回目の結果](#aws-solution-architect%E3%81%AE%E7%9F%A5%E8%AD%98%E3%81%A7%E6%8C%91%E3%82%93%E3%81%A01%E5%9B%9E%E7%9B%AE%E3%81%AE%E7%B5%90%E6%9E%9C)
3. [勉強方法：2回目の受験までのロードマップ](#%E5%8B%89%E5%BC%B7%E6%96%B9%E6%B3%95%EF%BC%9A2%E5%9B%9E%E7%9B%AE%E3%81%AE%E5%8F%97%E9%A8%93%E3%81%BE%E3%81%A7%E3%81%AE%E3%83%AD%E3%83%BC%E3%83%89%E3%83%9E%E3%83%83%E3%83%97)
4. [試験内容とGCPのポイント](#%E8%A9%A6%E9%A8%93%E5%86%85%E5%AE%B9%E3%81%A8gcp%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88)
5. [おすすめの参考書と学習ツール](#%E3%81%8A%E3%81%99%E3%81%99%E3%82%81%E3%81%AE%E5%8F%82%E8%80%83%E6%9B%B8%E3%81%A8%E5%AD%A6%E7%BF%92%E3%83%84%E3%83%BC%E3%83%AB)
6. [まとめ：合格への秘訣](#%E3%81%BE%E3%81%A8%E3%82%81%EF%BC%9A%E5%90%88%E6%A0%BC%E3%81%B8%E3%81%AE%E7%A7%98%E8%A8%A3)

---

## Cloud Digital Leaderとは？
**Google Cloud Certified - Cloud Digital Leader**は、Google Cloud Platform (GCP) の基本的な知識やクラウドのビジネス価値を理解していることを証明する資格です。

- **技術的な知識は不要**
- **ビジネス視点**でクラウドのメリットやGCPのサービスを学ぶ
- クラウドの入門資格としてもおすすめ

公式サイトでは、以下のように説明されています。

https://cloud.google.com/certification/cloud-digital-leader

---

## AWS Solution Architectの知識で挑んだ1回目の結果
AWS Solution Architectを取得していた私は、「クラウドの基礎知識なら余裕でしょ」と思い、完全に勉強せずに試験に臨みました。ところが...

- クラウド全般の知識 → **解ける**
- GCP特有のサービスや仕様 → **わからない！**

具体的には、こんな問題が解けませんでした。

> GCPの**Anthos**はどのようなユースケースに向いているか？

AWSのEKSやFargateしか触れたことがなかった私には、「Anthosって何？」状態でした。

### 結果：不合格
ここで初めて「GCPの勉強が必要だ」と痛感しました。

---

## 勉強方法：2回目の受験までのロードマップ

2回目の試験で合格するために、以下のステップで学習を進めました。

1. **参考書で基礎知識を固める**
2. **Udemyの模擬試験で演習**
3. **試験前の最終確認**

### 1. 参考書で基礎知識を固める
**『図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書』**
クラウドの概念やGoogle Cloudのサービスを体系的に学ぶのに適した書籍です。フルカラーで図を用いた解説があり、初めてクラウドを学習する方でも理解しやすい内容となっています。

https://amzn.asia/d/0On4Wsv

### 2. Udemyの模擬試験で演習
**Udemyの模擬試験コース**
Udemyでは、Google Cloud Digital Leader試験対策の模擬試験コースが提供されています。例えば、6回分の模擬試験を収録したコースがあり、実践的な問題演習を通じて試験形式に慣れることができます。

https://www.udemy.com/course/gcpgoogle-cloud-digital-leader6/?couponCode=ST21MT121624


### 3. 試験前の最終確認
**Google Cloud Skill Boost**
Google Cloudが提供する公式の学習プラットフォームで、試験に向けたコースやハンズオンの受講が可能です。無料で利用できるため、最新の情報やサービスの詳細を学習するのに役立ちます。 


**Cloud Digital Leader公式模擬問題**
Googleが提供する公式の模擬問題集です。無料で受験可能で、本番と似た形式の問題に取り組むことができます。試験前に一度解いておくことをおすすめします。

---



## まとめ：合格への秘訣
AWS経験者だからといって油断せず、GCP特有のサービスやビジネス価値を理解することがCloud Digital Leader合格のカギです。

### ポイントまとめ
1. **参考書で基礎知識を固める**
2. **Udemyの模擬試験で演習**
3. **GCPの公式リソースで最終確認**

GCPを体系的に学ぶ良い機会にもなるので、ぜひ楽しんで勉強してみてください！
高速の通信をするには

### どのように処理速度を早くするか
>すべての高速ネットワーク設計者が心に刻むべき基本原理を以下に記す。
`「帯域でなく、スピードを最適化する設計をせよ」`
従来のプロトコルは、回線上のビット数を最小化するように設計されていた。小さなフィールドを利用し、それにバイトやワードに詰め込んでいた。しかし、今や豊富な帯域が使えるように設計すべきである。IPv6の設計者は明らかにこの原理を理解していた。

### ハードウェアによる処理速度改善
>ハードウェアで高速なネットワーク・インタフェースを開発することである。しかし、プロトコルが非常に単純でない限り、そのハードウェアは第二のCPUとプロトコル・プログラムを持つプラグイン・ボードとしての意味しか持たない。ネットワーク・コプロセサをメインCPUのような高価なものになるのを避けるには、遅いチップを採用しなければならない。すると、メインCPUはその待ちの間に他の仕事をすればいいと考えるのは都合の良すぎる考えである。さらに二つの汎用CPUが通信を行うときは競合状態に陥る可能性があるので、二つのプロセサが正確に同期するための精巧なプロトコルが必要になる。プロトコルを単純にし、メインCPUにその仕事をやらせるのが最善のアプローチである。

* コプロセサとは

### ヘッダーを最適な大きさにする
>ギガビット・ネットワークでは、パケット・レイアウトも重要項目である。ヘッダーはその処理時間を減らすためにできるだけ少ないフィールドを持つようにすべきである。フィールドは十分な大きさを持ち、かつ処理の効率のためにワード単位に揃える必要がある。十分な大きさとは、古いパケットがまだネットワーク上に存在しているのに順序番号が一巡してしまうとか、ウインドウ・フィールドが小さすぎて受信者が十分なウインドウ・スペースの通知を行えないといった問題を起きないようなという意味である。

### 送るデータサイズも大きくする
>ソフトウェア・オーバーヘッドを削除し、動作を効率するために、最大データサイズも大きくすべきである。高速ネットワークでは、1500バイトは小さすぎる。この理由により、ギガビット・イーサネットでは最大9KBのジャンボ・フレームを扱えるようになっているし、IPv6 は64KBを超えるデータグラムをサポートしちえる。

### フィードバックによる遅延を少なくする
>高速プロトコルにおけるフィードバック問題について考えてみよう。比較的長い遅延ループがあるので、フィードバックを避ける必要がある。
...
スライディング・ウインドウ・プロトコルを利用した伝送速度の決定がある。受信者は送信者にウインドウ更新を送るが、それには長い遅延が含まれる。これを避けるために、速度準拠プロトコル(rate-based protcol)の利用が望ましい。速度準拠プロトコルでは、送信者と受信者があらかじめ合意したレートを超えない範囲で、送信者は好きなだけデータを送ることができる。

### あらかじめリソースを予約することでジッターを減らす
>送信者、受信者、ネットワーク全てが、コネクション設定時に必要なリソースを予約する手法が効率的である。あらかじめリソースを予約することは、ジッターを減らすという効果もある。まとめると、高速ネットワークの設計は否応なしにコネクション指向になるということである。

* ジッターがぼやぼやしてきた

https://bookplus.nikkei.com/atcl/catalog/23/03/16/00728/
会社で写真係をするときの心得

![banner-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3468574/156d2216-7a51-5cad-703a-75b06db772c2.png)

はじめに
---
IT部門といえば、同じ業界の先人の皆さまからのインプットも多ければ、
それと同じくらい自社の取り組みについてのアウトプットも多い部門ですよね！

とはいえ、
:woman_tone2: 「自社の取り組みを紹介したいから、写真もつけて記事を作ってほしい！」や
:man_tone1: 「採用ページを作りたいから、個人の写真を撮ろう！」 と話が上がったものの、
:innocent:「どんな写真をどう撮ったらいいのか...」となってしまうタイミングはちらほらとあるかと思います。

そんな方の助けに少しでもなれば...と、今回は気軽に写真を撮れるような記事を書けたらと思います！ :camera_with_flash: 


<font color="red">主役はなるべく中心に、余白は多めに！</font>
---
「上手い写真の撮り方」で調べると、
「写真は引き算」だったり「全体のバランスをみて...」みたいなお話が多く出てくるかと思います。

<font color="red">一旦難しいことは考えなくて大丈夫です！！</font>
スマホやノートPCの画面で表示するような記事の写真サイズであれば、
今やスマホ :calling: も多機能な一眼レフ :camera:  も優秀なので、トリミング上等！といった品質の写真を撮ってくれます。

写真の主役をなるべく中心に映して、
撮影環境やオフィスの環境次第ではありますが、なるべく余白を作ってシャッターを切りましょう！

余白が欲しい理由
---
後から記事に写真を埋め込む際に、
もしかしたら正方形に切り取ったうえで埋め込みたい場面が出てくるかもしれません。
気にしてみると、Web上の様々な記事ページはいわゆる写真の縦横比が意外とバラバラだったりします。
そして個人写真であれば、余白が多いと副産物としてそのままQiitaやSlackなどのアイコン画像にも活用できます。
<font color="gray">（専任の会社の方と協力して記事を作成する場合や、特に紙媒体の場合は余白が多いと喜ばれることも多いように思います）</font>


＋αで出来たらいいこと
---
1. 何枚か連写して撮りましょう！ :camera_with_flash:  :camera_with_flash:  :camera_with_flash: 
まばたきだったり、ブレだったりで後から確認したときに、
せっかくの写真が使えなかったら悲しいので、データは多い方がいいです。リスクマネジメントです！

2. なるべくスマホの広角レンズは使わないでください！
機種によっては会社のメンバーが歪んで写ってしまうかもしれません！:wavy_dash:

3. できるだけ部屋は明るく！写真の雰囲気も明るくなります :bulb:


よくIT業界でみられる個人写真のイメージ
---
某体育で音楽な方のMVのような章になってしまいますが、IT業界における自社メンバー紹介写真の構図講座です。
添付している公開ページに使用している写真は私や弊社メンバーが撮影したものです。参考に添付します。

**①証明写真のように背景が無地の壁の前で直立**![15432b89-d417-8b11-5c1a-016bd60e9291.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3468574/6647ff7e-c7e3-6842-4a8f-90c38b45ea1a.png)

**②着席してPCで作業中**（もしくはIT業界おなじみのろくろを回しながら）

https://wake-career.jp/media/female-web-engineer-career-interview-ichinose-polaorbis 

**③会社や部署の看板の前に立って**

https://sg.wantedly.com/companies/company_3091436/post_articles/939101 

**④社内のキレイな会議スペースや机、椅子があれば**

https://www.green-japan.com/company/9183 

とくに②の普段の業務中のような写真は、一番撮りやすくて記事にも使いやすいと思います！


最後に
---
スマホやカメラも日々IT技術と同じく進化し続けています。
システム構築と同様に頼れるものには頼りつつ、なるべくその場の雰囲気やメンバーのよさを発信する材料になればと思います。
【Laravel】Vercel環境でのPostgreSQL接続

## 手順
1. Nodeのバージョンを18系に指定
1. `vercel.json`を設定
1. `config/database.php`の設定

## Let's implement it!!
### 1. Nodeのバージョンを18系に指定
#### VercelのConsoleから設定を行います。

![スクリーンショット 2024-12-18 15.22.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3334980/11dbd946-572a-cbb7-dc5d-622207769a57.png)

#### `package.json`内にて、Nodeのバージョンを指定します。
```json:package.json
{
    "private": true,
    "type": "module",
    "scripts": {
        "build": "vite build",
        "dev": "vite"
    },
    "devDependencies": {
        "autoprefixer": "^10.4.20",
        "axios": "^1.7.4",
        "concurrently": "^9.0.1",
        "laravel-vite-plugin": "^1.0",
        "postcss": "^8.4.47",
        "tailwindcss": "^3.4.13",
        "vite": "^5.0"
    },
    "engines": {
        "node": "18.x", // ここ
        "npm": "10.x"　// ここ
    },
    "volta": {
        "node": "18.20.5",
        "npm": "10.9.2"
    }
}
```

普通はこれでいいと思いますが...。
僕の環境では「20系」からの変更だったので、各ライブラリが動作しなくなりました。

以下を実行し、18系にあったパッケージをインストールし直しましょう。

```bash
rm -rf node_modules package-lock.json
```

### 2. `vercel.json`を設定
```json:vercel.json
{
    "version": 2,
    "framework": null,
    "builds": [
        {
            "src": "public/**/*",
            "use": "@vercel/static"
        },
        {
            "src": "api/*.php",
            "use": "vercel-php@0.7.3"
        }
    ],
    "routes": [
        {
            "src": "^/(css|js|images|fonts|storage)/(.*)",
            "dest": "/public/$1/$2"
        },
        {
            "src": "^/favicon.ico",
            "dest": "/public/favicon.ico"
        },
        {
            "src": "/(.*)",
            "dest": "/api/index.php"
        }
    ],
    "env": {
        "APP_NAME": "アプリ名",
        "APP_ENV": "production",
        "APP_URL": "ドメイン",
        "VERCEL_DEMO_MODE": "true",
        "APP_CONFIG_CACHE": "/tmp/config.php",
        "APP_EVENTS_CACHE": "/tmp/events.php",
        "APP_PACKAGES_CACHE": "/tmp/packages.php",
        "APP_ROUTES_CACHE": "/tmp/routes.php",
        "APP_SERVICES_CACHE": "/tmp/services.php",
        "CACHE_DRIVER": "array",
        "LOG_CHANNEL": "stderr",
        "VIEW_COMPILED_PATH": "/tmp/views",
        "SSR_TEMP_PATH": "/tmp/ssr",
        "NODE_PATH": "node"
    }
}
```

### 3. `config/database.php`の設定
```php
'pgsql' => [
    'driver' => 'pgsql',
    'url' => env('POSTGRES_URL_NON_POOLING'),
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'forge'),
    'username' => env('DB_USERNAME', 'forge'),
    'password' => env('DB_PASSWORD', ''),
    'charset' => 'utf8',
    'prefix' => '',
    'prefix_indexes' => true,
    'sslmode' => 'require',
],
```
ShredOSでNVMe SSDのデータを消去する

# ShredOSでNVMe SSDのデータを消去する

PCを廃棄するときにストレージが物理破壊できればいいんですが、近くに破砕サービスを提供している事業者がないとか、そもそもリース機で破壊できないとかあると思います。
最近のマシンだとデータ消去用ユーティリティが内蔵されているものもありますが、微妙に古いマシンではそういうユーティリティが期待できないこともあります。
この文章ではNVMe SSDのデータをShredOSで消去する方法を記述します。

## 必要なもの

- 適当なWindowsPC
- 16GBくらいのUSBフラッシュメモリ

## ShredOSのダウンロード

公式サイト
[shredos.x86_64](https://github.com/PartialVolume/shredos.x86_64)

とにかく最新のものをダウンロードします。
2024年12月時点での最新版は ShredOS version v2024.02.2_26.0_x86-64_0.37 (Latest Release) です。
USBフラッシュメモリにインストールするので ShredOS .img x86_64bit for USB Vanilla をダウンロードします。

## イメージフラッシュツールのダウンロード

公式が推奨している通り[Rufus](https://rufus.ie/ja/)か[etcher](https://etcher.balena.io/)をダウンロードします。
この辺は好みの問題なのでどちらでもいいと思います。

## イメージフラッシュツールでShredOSをインストールする

ダウンロードしてきたShredOSの.isoイメージをイメージフラッシュツールでUSBフラッシュメモリに展開します。

## 破壊作業

### USBフラッシュメモリを対象PCに接続する

起動ディスクとして認識させる必要があるのでUSBハブとかは使わないほうが無難です。

### PCを起動する

F1だったりF2だったりF8だったりF10だったりF12だったりしますが、とにかく「起動デバイス選択」画面を起こします。
どのキーが対応してるかはPCのマニュアルに書いてあるはずなので、頑張って探してください。

ShredOSはBIOS/UEFIの両方に対応していますので、BIOS/UEFIの設定とかは基本的に不要なはずです。

### USBフラッシュメモリから起動する

USBフラッシュメモリが選択肢の中にあるはずですので、それを選択します。
場合によっては「Legacy」「UEFI」の2つで表示されている場合がありますが、その場合はUEFIでいいです。

### 画面を切り替える

ALT + F2キーでコマンド入力用の画面に切り替えます。

### SSDのFrozenを解除する

SSDが起動時にロックされた状態になっているので、スリープ状態にしてSSDに電源を落とした状態と認識させてロックを解除します。

```
rtcwake -m mem -s 5
```

一瞬スリープに入って数秒後(コマンド的には5秒後)に再起動してきます。

### 対象のNVMe SSDのデバイスファイルを探す

```
ls /dev/nvme*
```

ぞろぞろと出てくると思いますが、1つしか搭載していなければたぶんnvme0なんじゃないかなと思います。
今回は /dev/nvme0 として進めます。

### 暗号化的消去を指定してのフォーマットコマンド

とりあえずフォーマットします。

```
nvme format /dev/nvme0 -s 2 -n 1
```

#### 暗号化的消去ができない場合

[NVME-FORMAT(1)](https://github.com/linux-nvme/nvme-cli/blob/master/Documentation/nvme-format.txt)

-sオプションは0から2まで選択可能です。
0はちょっと意味が分からないのですが、1のほうは少なくとも何かしら削除はしてくれそうです。
0 : secure eraseを要求しない
1 : ユーザーデータの消去を試みる
2 : 全ユーザーデータの暗号化的消去を試みる

```
nvme format /dev/nvme0 -s 1 -n 1
```

### さらにサニタイズする

ユーザーデータが消えていれば基本的には大丈夫なんじゃないかなとは思いますが、念には念を入れておきます。
nvme-cliではデータ消去用のコマンドであるsanitizeがありますので、これ用いて消去します。

```
nvme sanitize /dev/nvme0 -a 4
```

コマンドは一瞬で終わったように見えますが、これはあくまで「デバイスにサニタイズ命令を発行したら終わり」という挙動なためで、裏ではデバイスが頑張って削除しています。
進行状況についてはデバイスに直接聞いてみるしかないようなので、聞いてみるコマンドを投入します。

```
nvme get-log /dev/nvme0 -i 0x81 -l 512
```

```
       0  1  2
0000: ff ff 01
```

ff ff 01 になっていれば終了です。電源を切ってUSBフラッシュメモリを取り外しましょう。

## 参考

- [arch linux - ソリッドステートドライブ/メモリセルの消去](https://wiki.archlinux.jp/index.php/%E3%82%BD%E3%83%AA%E3%83%83%E3%83%89%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%89%E3%83%A9%E3%82%A4%E3%83%96/%E3%83%A1%E3%83%A2%E3%83%AA%E3%82%BB%E3%83%AB%E3%81%AE%E6%B6%88%E5%8E%BB)
- [nvme-cli](https://github.com/linux-nvme/nvme-cli/tree/master/Documentation)
- [nvmeコマンド逆引きマニュアル(2/2)](https://qiita.com/ken-yossy/items/443d5c8768347ca7488f)
mruby-yabm-samplesのご紹介

mruby on YABMは対応するSOCによってrtlbm-mruby, bcmbm-mruby, admbm-mruby, armbm-mrubyの4レポジトリに分かれています。当初それぞれのレポジトリにrubyのサンプルコードを入れていたのですが、共通で使えるコードもあるので、以下のレポジトリを作りまとめました。

https://github.com/yamori813/mruby-yabm-samples

rtlbm, bcmbm, admbm, armbmはアーキテクチャ依存で、それ以外は機能毎にカテゴリを分けました。

ここの中のgpioにあるmorse.rbはモールス信号をLEDで点滅するコードです。このコードにはサブルーチンが必要で、rtlbmの中のsub_hsc.rbやbcmbmの中のsub_whr_g.rbなどと一緒にコンパイルする必要があります。

コンパイルする時はサブルーチンやクラスのファイルを先の引数してメインのコードのファイルを最後にしてmrbcに渡します。

いくつかのコードは[RuboCop](https://qiita.com/yamori813/items/e10681a5371c2774b680)で整形してあります。

iotは一般的にはInternt of ThingsですがInternet of Testだったりもします。このディレクトリにあるthingspeak.rbを一ヶ月くらい前からbcmbmで動かしていて安定度を確認しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/fc006762-049c-f054-c4f7-ac1076e83e44.png)

現在のところ連続して11万回以上アクセスできているようで、かなり安定しています。

整理できてないところもあるので、ぼちぼち整理して行きたいと思います。

このレポジトリーはまじりっけのない100% rubyなレポジトリです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/ca479d57-1fea-88a0-a37e-d3cb38a324bb.png)
Flutter configコマンドをリセットする

## 設定確認
```bash
flutter config --list  
```
```
All Settings:
  enable-web: (Not set)
  enable-linux-desktop: (Not set)
  enable-macos-desktop: (Not set)
  enable-windows-desktop: (Not set)
  enable-android: (Not set)
  enable-ios: (Not set)
  enable-fuchsia: (Not set) (Unavailable)
  enable-custom-devices: (Not set)
  cli-animations: (Not set)
  enable-native-assets: (Not set) (Unavailable)
  enable-flutter-preview: (Not set) (Unavailable)
  enable-swift-package-manager: (Not set) (Unavailable)
  jdk-dir: /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
```

## リセットコマンド
- 空のパスを設定するとリセットになる
- jdk-dirをリセットしてみる
```bash
flutter config --jdk-dir=""  
```

```
All Settings:
  enable-web: (Not set)
  enable-linux-desktop: (Not set)
  enable-macos-desktop: (Not set)
  enable-windows-desktop: (Not set)
  enable-android: (Not set)
  enable-ios: (Not set)
  enable-fuchsia: (Not set) (Unavailable)
  enable-custom-devices: (Not set)
  cli-animations: (Not set)
  enable-native-assets: (Not set) (Unavailable)
  enable-flutter-preview: (Not set) (Unavailable)
  enable-swift-package-manager: (Not set) (Unavailable)
```
消えました！

## 参考
- [Flutter公式](https://docs.flutter.dev/reference/flutter-cli)
非エンジニアが開発オンボーディングに参加してみた -追加機能開発・カタログ編-

# はじめに

こんにちは、社会人8年目で元ITコンサルのふるすです！  
今年7月、社内公募を通じてDevRelへ異動しました。

私の異動の経緯については、[こちらの記事](https://qiita.com/furusu_y/items/a5465c1b99fa2a031a02)を読んでいただけますと嬉しいです！

私たちの開発部門には、新卒社員や中途社員向けのオンボーディング課題があります。今回、私もその課題に挑戦し、多くの学びがあったため、この体験を皆さんに共有したいと思い記事を書くことにしました。

## オンボーディング課題

オンボーディング課題には以下のような種類があります。それに加え、社内ツールに慣れるための課題や新たに加入したメンバー向けの課題も提供されています。

- **デザインクリティーク**
- **Javaの動画学習 & グループワーク**
- **追加機能開発課題**

WHIのオンボーディングについてさらに詳しく知りたい方は、以下の記事もぜひご覧ください。

1. [2022年、3大がっかりだった開発オンボーディングを皆で楽しくした話](https://qiita.com/e99h2121/items/888165fafcb03e249f0e)
2. [WHIの開発オンボーディングに迫る！Vol.1 オンボーディングのこだわりポイントとは？](https://note.com/works_hi/n/ncef79cf102ef)
3. [UI/UXチームのアンナさんによるデザインクリティークのご紹介記事](https://qiita.com/annafuru/items/d14817d090e414ad34cb)

今回は「追加機能開発課題」に焦点を当ててお話しします。

## 追加機能開発課題とは？

簡単に言うと、「既存の連絡帳アプリケーションにどのような機能を追加すればより良いものになるかを考え、実際にその機能を実装してみよう」というものです。

私はJavaの実装経験がありませんし、最後にプログラミングしたのは新卒研修以来です。。果たしてほかの業務をしながら課題、できるんだろうか…

＼為せば成る　為さねば成らぬ　何事も…／
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827898/7e2f285b-8310-1e1b-035e-45ceb75b106c.jpeg" width="330px">




それでも、非エンジニアとして開発チームの業務の理解を深めるために、この課題を最後までやり遂げることを決めました…！

## カタログを作るぞ

既存の機能は以下のようになっていました。

- *データ登録、削除、編集機能*
- *排他制御*

これに新たな機能を加えるためには、まず「利用者の想定」を明確にする必要があります。コンサルタント時代、私は常に「この機能はお客様のどんな課題を解決できるのか？」を考えて仕事をしてきたので、カタログ作成はそんな私にとってとても楽しい作業でした！

わたしが作成したカタログ最終版を簡単にまとめるとこちらのとおり。

### 1. 利用ユーザー

- スマホでSNSを活用し、「推し活」を行う人々
- 特にSNS上でグッズ交換をしている方々

### 2. ユーザーの課題

- 複数のコンテンツを追いかけることで、「誰とどこでどのように知り合ったのか」がわからなくなる  
  - 推しの数は10〜25コンテンツが最多というデータもあった 
    ([参考情報](https://prtimes.jp/main/html/rd/p/000000508.000006388.html))
- グッズ交換をしたことがある人の中で、SNSを通じて行っている人は60%以上  
  ([参考情報](https://www.nikkei.com/article/DGXZQOUC2436I0U4A920C2000000/))
- 複数の人とSNSでグッズ交換をすると、追い切れずタスク漏れが発生する
- 漏れが生じると、取引がスムーズに進まず、双方に不利益が発生する

### 3. 解決方法（本アプリのメリット）

- *連絡先が整理されている状態を理想とする*
- *ジャンルタグを追加することで、自ら情報を紐づけられるようにする*
- *ステータス管理を行い、タスク漏れを防止する*

## 学んだこと

- **ユーザーの課題を解決するにはどうしたらいいかを第一に考え、吹っ切れろ**  
  「これは連絡帳アプリと言えるのか？」という迷いが発生したり、「カタログってこんなんでいいのかな？」だったりといまいち思い切れなかったが、先輩や上長からフィードバックを受けて吹っ切れたらユーザーが本当に使いやすいアプリが見えてきた。

- **やはり根拠は大事**  
  なぜそれが課題なのか、なぜ解決しないといけないのか…の前提となる根拠の部分がデータとしてあると強い自信になるし、当然ながら説得力が増す。

- **適切なスコープにしよう**  
  カタログを書いているうちにいろんな機能を実装してみたくなってしまった。でも自分の力量がわかっていないのにあれもこれもと手を出し始めたら収集がつかなくなる。しっかりと優先順位をつけてまずは必須の機能から順番に片づけていこう（これはプロジェクトマネジメントに全く同じことが言える…今までさんざん言ってきたこと）。

ここまでお読みいただきありがとうございました！
2相コミットについて調べたので書く

# 概要
- Firestoreの裏側の仕組みについて調べてた
- 2相コミットというワードについて調べたので理解のために記す
- なんか間違えてたらマサカリください

# メモ

## 分散データベースとは

* 言わずとも
* 複数サーバにデータ、またはデータベースを分散して管理する仕組み
* BigQueryとかSpannerとかSnowflakeもそういう類のものだと思ってる（厳密には違いそうだけど）


## 分散データベースで困ること

サービスや仕組みによって、色々あると思いますが、ここではトランザクションだけにフォーカスします。

スケーラビリティを達成するため、複数サーバにデータベースがあるので、データの整合性の担保に課題がある。 

分散データベース（中身は3台、A,B,Cというデータベース）へ書き込みを行いたい。となった場合、ユーザーからはクエリを投げ、A,B,Cそれぞれにコミットすれば良いがそう単純な話ではない。

Aが失敗した場合どうするのかーとか、A,B,C全部にちゃんと書き込めたのかーとか色々考える必要がある。


## 2相コミット（2フェーズコミット）

ここで「2相コミット」という方法をメモする。

https://e-words.jp/w/2%E3%83%95%E3%82%A7%E3%83%BC%E3%82%BA%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88.html

簡単に書くと「コミットを2回に分けて実行する」という方法。

1. 1段階目にマネージャーみたいな機能（Coordinatorと呼ぶらしい）が、書き込む分散サーバすべてに問い合わせを行い、コミットできるか確認を行う
1. 全てコミット可能と確認ができれば、2段階目としてデータの更新を行う


という2段階を取るので2相コミットと呼ばれる。なるほど


絵があるとわかりやすいので下記ありがたい記事引用

https://itmanabi.com/2phase-commit/


## この方式を利用しているサービス

ぱっと調べた見た感じつかってそうなサービス

* Google Cloud Spanner
    * https://cloud.google.com/spanner/docs/transactions?hl=ja
* Amazon Aurora
    * https://aws.amazon.com/jp/blogs/news/binary-logging-optimizations-in-amazon-aurora-mysql-version-3/
悲観ロックと楽観ロック

# 楽観ロック
楽観ロックは、データ更新時に競合「きょうごう」があまり発生しないことを前提としています。
バージョン番号を使用してデータの一貫性を確保します。

## 実行順番
1. テーブルから目標データを取得する
```
Product product = productRepository.findById(productId);
```

2. データの存在を確認する
```
if (product == null) {
    throw new RuntimeException("Product not found");
}
```


3. データを更新する
```
product.setQuantity(newQuantity);
```

4.保存時にバージョン番号をチェックする

```
productRepository.save(product);
try {
    productRepository.save(product);
} catch (OptimisticLockingFailureException e) {
    retryUpdate(productId, newQuantity);
}
```

# 悲観ロック

悲観ロックは、データ更新時に競合が頻繁に発生することを前提としています。
データをロックし、他のトランザクションが変更するのを防ぎます。

## 実行順番

1. トランザクションを開始する
```
@Transactional
```

2.データをロックする、悲観ロック（PESSIMISTIC_WRITEモード）を使用して、他のトランザクションからの変更を防ぎます。
```
Product product = entityManager.find(Product.class, productId, LockModeType.PESSIMISTIC_WRITE);
```

3. トランザクション内で安全にデータを更新する
```
product.setQuantity(newQuantity);
```

# まとめ
楽観ロック：
データ更新の競合が少ない場合に適しています。バージョン番号を利用し、不一致があれば例外をスローして再試行します。主にシステムのパフォーマンスを重視する場面で使われます。

悲観ロック：
データ更新の競合が頻発する場合に適しています。データを明示的にロックし、他のトランザクションによる変更を防ぎます。一貫性を重視するシステムで効果的です。

選択基準：
データ競合の頻度が低い → 楽観ロック
データ競合の頻度が高い → 悲観ロック
LTのアクセシビリティ

## はじめに

先日、人生で初めてLTに登壇しました。中身は「Trusted Tester認証を取得したらアクセシビリティに関して理解が深まった話」です。

https://skword.connpass.com/event/333884/

これにLTで参加する上で、色々と登壇資料もアクセシビリティにちゃんと配慮しなければいけないと考え、LT資料を作成しました。そのことについて、いくつか書き出してみたいと思います。

## 喋るべきものはすべてスライドに書き込む

耳の不自由な方であれば、スライドに書かれたこと以外の情報はわかりません。なので、話すべきことはすべてちゃんとスライドに書き込みました。画像を用いることもありましたが、画像にもちゃんと説明を添えました。こうすることによって生まれるもう一つのメリットとして、登壇者側も何を喋ればいいか迷わなくなります。スライド自体がカンペにもなります。

## スライドに書いていることは全部喋る

目の不自由な方であれば、スライドほど非アクセシブルなものはありません。支援技術を使えるわけでもありません。なので、スライドに書いてあることはすべて読み上げるようにしました。自分がスクリーンリーダーとしての役割を果たしました。ちゃんと小さなギャグもスライドに仕込んでおいたので、それも読み上げました。

## フォントを見やすくする

こちらが、実際に登壇した際に使ったスライドの1部です

![LTで登壇したスライドの1部](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267174/6bc49156-8b86-f6ac-1272-59454502edcf.jpeg)

[ディスレクシア](https://shigoto4you.com/udfont/)の方でも読みやすいフォントファミリーにしようと思い、モリサワフォントのBIZ UDゴシックを使用しました

https://www.morisawa.co.jp/products/fonts/bizplus/

そして、小さめの字は用いないようにしました。小さい文字を使うと最前列の方ぐらいしか読めません。（余談ですが、たまにLTでコードを載せたりする方がいますが、ほとんどの場合字が小さすぎて全く見えません。何を書こうとしてるのか、それすらもわからないので意味がないです。）

そして、下線を引いたり、太字にしたり、より読みやすい配慮にしました。

一つのスライドの中にたくさんの文字を詰め込まず、複数スライドに分ける工夫もしました。これによって行間が空きやすくなり、より読みやすくしました。

## 章始めごとに目次を出す

章のはじめごとに、目次を出すようにしました。そして、これから話す章を強調するようにしました。

![目次が書いてあるスライド](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267174/0ce1112c-e873-3d60-b3d6-504764db31df.jpeg)

これによって、今全体でどのくらいの部分を話しているのかが把握できたり、今どのことを話そうとしているのか見通しが良くなると思い、目次を用意しました。これはアクセシビリティと多少違うかもしれませんが、わかりやすさを重視しようと思い、目次を用意しました。そしてスライドの上部にも、現在の章のタイトルも載せるようにしました。

## LT資料の共有をブログで

https://qiita.com/mu_tomoya/items/73c4f8a89a27b601eb34

こちらが、先日登壇した際の内容をブログ用に書き起こしたものです。
LT用に書いたスライドだったので、自分で読み上げる前提、大勢の前で見てもらう前提で書きました。
これを、ただpdf化したり、SlideShareにあげては正しくアクセシビリティを担保されるのかが心配だと思いました。画像化したものをすべてaltで読ませるのは果たして良いのだろうか、そう考え、Qiitaに書き起こすことにしました。Web媒体であればあとは正しくこちらがちゃんと書けばアクセシビリティを担保できるので、ブログに書き起こすことにしました。ブログであれば見出しも利用できるので、altのみの文章に比べて表現の工夫ができます。

## 反省点

5分のLTというのはやはり短いもので、喋りたい内容を詰め込みすぎました。そのせいで喋るスピードがものすごく早くなってしまいました。これはもっとちゃんと練習したり、削るところを増やせばよかったなと、とても反省しました。自分がスクリーンリーダーとしての役割を果たさなければいけないのに、早くしゃべって聞き取りづらかったらアクセシビリティどころではないです。

## 終わりに

以上が自分が登壇した際に、アクセシビリティに関して工夫をしてみたLTの話でした。みなさんもぜひ参考にしてみてください。