- Software Enginner
- Skill
- AWS(2024 AWS All Certifications Engineer)
- Go,TypeScript,Python,C++
- I’m interested in
- k8s
- Platform Enginner
- OSS Activity
- OSS
- My Tech Article
Engineer
Git関連のメモ
commitメッセージ Format: (): is optional feat: 新機能 fix: バグ修正 docs: ドキュメント変更 style: フォーマット変更 refactor: リファクタリング test: テスト作成 chore: けいびな変更 Conventional Commits レビューコメント 略語 意味 日本語訳 IMO In My Opinion 私が思うに、私の意見としては NITS Nitpick (あら探しをする、から派生して)細かい指摘 Q Question 質問 LGTM Looks Good To Me 私はいいと思います FYI For Your Information 参考までに WIP Work In Progress 作業中です TL;DR Too Long; Didn’t Read 長文なので要約を載せます GOTCHA I’ve Got You やったぜ! AFAIK As Far As I Know 私の知っている限りでは IMHO In My Humble Opinion 私のつたない意見では(控えめ)
Googleのソフトウェアエンジニアリング
メモ 早期に失敗し、高速に失敗し、頻繁に失敗せよ たくさんの目があれば、プロジェクトは意味があり順調に保たれる ソフトウェアは個人はなく、チームによって書かれる ソフトウェアエンジニアリングとはチームによる取り組み 共同作業の理想郷に達するための三本柱 謙虚 尊敬 信頼 失敗は選択肢の一つである 時々失敗することがなかったとすれば、十分に革新的ではないか、十分にリスクをとってないかのどちらかである 全か無かの専門知識 万人のために開発するな。万人とともに開発せよ 公正であるとの思い込みを捨てろ。システム全体で公正さを計測せよ ポストモーテム(事後検証3) インシデントを繰り返さないためのプロセス 小さな変更 200行以内 可能な場合は自動化、静的解析の自動化は最も重要な改善だった 設計レビューに相当な時間を費やす コード、ドキュメントにはオーナーがいるべき、オーナーが欠くと鮮度が失い、保守が困難になる ドキュメンテーションはコードと密結合しているためできるだけコードとして扱うべきWRITE THE DOCS ドキュメントに鮮度日付を付加する。 テストの比率 ユニットテスト:80% インテグレーションテスト:15% E2Eテスト:5% Beyonceルール
Hugoでブログを作成し、GitHub Pagesで公開する
自分のwebサイトをHugoを使用し作成しました。(このサイトです!)普段はNext.jsを使用しwebアプリを作成しているのですが、今回はHugoを使用することを決めました。選定利用としては様々なthemeがあり、利用や切り替えが楽、Markdownによるコンテンツ管理の容易さ、kubernetesのwebサイトで利用されており使ってみたかった点になります。 手順 環境 MacOS(Ventura) go version 1.22.3 構築 1. hugoのインストール brew install hugo 2. Hugoサイトの作成 hugo new site my-blog 3. PaperModテーマの追加 git submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod echo "theme = 'PaperMod'" >> hugo.toml 4. トップ画面の作成 hugo.toml baseURL = "https://kei-ta.github.io/kei-ta-blog-go/" languageCode = "ja" title = "Kei-Ta Blog" theme = "PaperMod" [params] defaultTheme = "dark" [params.profileMode] enabled = true title = "Kei-Ta Blog" subtitle = "This blog is my activity log." imageUrl = "https://kei-ta....
OCRのサンプルアプリケーション
概要 簡単なOCRアプリの実装を行います。様々なライブラリがあると思いますが、今回はTesseractを使用し実装してみます。デフォルトは英語のみですが、日本語の画像から日本語を抽出できるようにしたいと思います。 Tesseractとは Googleが主導して開発しているオープンソースのOCR(Optical Character Recognition、光学文字認識)エンジンです。OCRは、画像やPDFなどに含まれるテキスト情報を解析し、コンピュータが扱える文字データに変換する技術です。Tesseractは、その中でも高精度なテキスト認識を行うことができるツールとして広く利用されています。 主な特徴 オープンソース: 無料で使用でき、カスタマイズも可能です。 マルチプラットフォーム対応: Linux、Windows、macOSなど、さまざまなOSで動作します。 多言語対応: 100以上の言語データがサポートされており、日本語を含む多言語でのテキスト認識が可能です。 高精度: 特に印刷されたテキストの認識において非常に高い精度を誇ります。手書き文字にも対応していますが、精度は印刷文字ほど高くありません。 拡張性: 画像前処理や言語モデルのカスタマイズなど、OCR精度を向上させるための多くのオプションがあります。 環境 Mac OS Python 3.11.9 1. 準備 tesseractのインストール brew install tesseract 多言語データのインストール brew install tesseract-lang Pythonライブラリのインストール pip3 install pytesseract Pillow 画像の用意 下記のように画像を用意する ocr/ ├── test.png └── main.py main.py import os import pytesseract from PIL import Image os.environ['TESSDATA_PREFIX'] = '/opt/homebrew/share/tessdata/' # 画像ファイルのパスを指定 image_path = './test.png' # 画像を読み込む img = Image.open(image_path) # OCRを日本語で実行 text = pytesseract....
Podman
Podmanとは インストール方法 環境 マシン Mac Book チップ Apple M2 Pro メモリ 32GB OS 13.6.8 手順 1. podman CLIをインストール brew install pod man # バージョンを確認 podman -v # (出力)podman version 5.3.0 2. podman VMを起動 コンテナの起動
Terraform メモ
メモ Document terraform-provider-googleの場合、website/docsに格納 schema.Schema Type: 設定する値の型 (ValueType)。bool, int, float64, string, []interface{}, map[string]interface{}, *schema.Set などが含まれる。 ConfigMode: スキーマが属性として扱われるか、ブロックとして扱われるかを制御するオプション (SchemaConfigMode)。 Required: 設定が必須かどうかを示すフラグ。 Optional: 設定がオプションかどうかを示すフラグ。Required と併用不可。 Computed: プロバイダーがこの属性に独自の値を設定できるかどうか。Required とは併用不可。 ForceNew: 値が変更された際にリソースの再作成が必要かどうか。 DiffSuppressFunc: フィールドの差分を無視するカスタム関数。 DiffSuppressOnRefresh: 差分抑制機能がリフレッシュの際にも適用されるかどうか。 Default: 設定されていない場合に使用されるデフォルト値。 DefaultFunc: デフォルト値を動的に計算する関数。 Description: このフィールドの説明。ドキュメントやユーザー向けの説明に使用される。 InputDefault: 入力要求時のデフォルト値。 StateFunc: 値を保存または比較する前に呼ばれる関数。 Elem: TypeList, TypeSet, TypeMap の要素の型。 MaxItems: TypeSet, TypeList における最大項目数。 MinItems: TypeSet, TypeList における最小項目数。 Set: TypeSet 要素のカスタムハッシュアルゴリズム。 ComputedWhen: 再計算が必要になる設定の変更を指定。 ConflictsWith: 同時に設定できない他の属性を指定。 ExactlyOneOf: どれか1つだけ設定可能な属性群。 AtLeastOneOf: 1つ以上が設定されている必要がある属性群。 RequiredWith: 同時に設定が必要な他の属性を指定。 Deprecated: 廃止予定の属性であることを示すメッセージ。 ValidateFunc: 属性の値を検証するための関数。 ValidateDiagFunc: 値を検証し、診断情報を返す関数。 Sensitive: センシティブな情報を隠すためのフラグ。 ブロック ブロックを定義してるファイル terraform-provider-google/google/provider/provider_mmv1_resources....
Versionの指定方法について
概要 pakage.jsonなどのバージョン管理ファイルを見ると以下のように表記されている。 package.json "react": "^15.3.2" terraform terraform { required_version = "~> 1.8.0" required_providers { google = { source = "hashicorp/google" version = "~> 5.43.0" } } } ^や~の指定の仕方により、インストールされるパッケージをコントロールすることができる。 ^はキャレットと~はチルダと呼ばれており、今回はこれについて整理を行いたい。 ^ キャレット パッケージのバージョン番号の中で番左のゼロではない値を変更しない範囲でアップデートを許容する。 例 バージョン 許容範囲 1.6.0 1.6.0<= version <2.0.0 0.6.0 0.6.0<= version <0.7.0 0.0.6 0.0.6<= version <0.0.7 ~ チルダ パッケージが表記されていれば、一個下のバージョンのアップデートを許容する 例 バージョン 許容範囲 1.6.0 1.6.0<= version <1.6.1 1.6 1.6.0<= version <1.7.0 1 1.0.0<= version <2.0.0
開発プロセスについて
プロセス 要求定義 目的:何を作って欲しいのかを定義する 誰が作成する:企画(開発がサポートする必要あり) 成果物 企画書サマリ プロジェクトの目的 目的達成のためにないを作るのか 利用する人 利用することで得られる利益 どのように作るのか 期限 システム全体概要 要求一覧 行動シナリオ 参考資料 https://blog.nijibox.jp/article/user_scenario/ 要件定義 目的:何を作るかを定義する 誰が作成する:開発 成果物 画面要件 機能要件 設計 システムアーキテクチャの選定 API定義書 DB定義書 開発 テスト リリース 運用
開発参考資料
開発関連 要求定義 要件定義 MUST、SHOULD、MAY、REQUIRED、SHALLの解釈 ラベル レベル感 MUST、REQUIRED、SHALL 絶対に守るべき項目。 SHOULD、RECOMMENDED 特別な理由がない限りは守るべき項目。 MAY、OPTIONAL 完全に任意。 SHOULD NOT、NOT RECOMMENDED 特別な理由がない限りは禁止されている項目。 MUST NOT、SHALL NOT 絶対的に禁止されている項目。 設計 ソフトウェア設計原則入門 開発 データの信頼性 テスト 運用(SRE) ドメイン名の終活について ドメインの廃止にはそれなりのリスクがある -> 第三者にわたり、詐欺 ドメインを取得する前に考える ->組織が所有するサブドメインでいいか、現在のドメインを利用できないかなど ドメインのライフサイクル ドメインの廃止にはコストがかかる ->ドメイン名更新、証明書更新、ログ収集、廃止の申請などの工数 組織マネジメント マネージャーが「面倒なことをやってくれる人」と思われないためにやること 「面倒なことをやってくれる人」として終わらないためにする3つのこと 組織がこうありたいと思っていることを現実にすること マネジメント対象となるメンバーや関係者から情報を集める 自分が組織に対してどんな貢献ができるかを開示する 提案した改善案を実行に移し、成果を確認しながら調整する