こんにちは、 @kz_morita です。 今回は jq を使っていて、Json の null が入っているカラムを削除したいときの Tips をメモしておきます。 値が null のフィールドを削除する 以下のようにすると、null のフィールドを削除できます。 $ cat sample.json | jq 'to_entries | map(select(.value != null)) | from entries' 以下解説です。 まず今回の対象の json は以下のようなものです。 { "name": "Alice", "age": null, "address": { "street": "123 Main St", "city": "Wonderland" }, "phoneNumbers": [ { "type": "home", "number": "555-1234" } ], "isActive": true, "preferences": null } これが上記のコマンドを使用すると以下のようになります。 { "name": "Alice", "address": { "street": "123 Main St", "city": "Wonderland" }, "phoneNumbers": [ { "type": "home", "number": "555-1234" } ], "isActive": true } preferences と age カラムが消えていることがわかります。

こんにちは、 @kz_morita です。 AWS が提供する BI ツールである QuickSight にてマルチテナントなど環境を分離する際に参考になりそうな資料をまとめてみました。 資料まとめ 【開催報告】Amazon QuickSight Roadshow 東京 2023 2023 年 8月に行われたイベントの報告レポートです。QuickSight の色々な機能について触れられています。 以下に上記イベントの中のプレゼン資料をいくつかピックアップします。 フォルダとAPIを活用したシングルアカウントでの複数環境運用 フォルダ機能を使って、複数環境を分離して運用する方法について書かれています。 QuickSight におけるアセット管理 こちらは、QuickSight のアセットをコードで管理する方法について書かれています。 たとえば、開発環境と本番環境を用意している場合異なる環境間でアセットをコピーなどしてデプロイすると言った運用が考えられます。 その際に、アセットをコードとして管理されていると運用がしやすくなりそうです。 上記では Template 機能などが紹介されています。 分離された名前空間によるマルチテナンシーのサポート こちらは、公式サイトで QuickSight では名前空間を使って環境を分離する方法がサポートされていることについて説明されています。 Amazon QuickSight 埋め込みハンズオン > イントロダクション こちらは、QuickSight の埋め込み機能を用いてマルチテナントのアプリケーションを作成するハンズオン資料です。 こちらも名前空間を使用して複数環境用意する例がハンズオン形式で紹介されています。 QuickSightの名前空間機能を使ってマルチテナント用に環境を分離させる 上記も名前空間機能を使ってマルチテナント用に環境を分離させる方法について書かれています。

こんにちは、 @kz_morita です。 タイトルの通り、AWS CLI を使う時に環境変数で使用する PROFILE を指定しておくと便利だったのでメモしておきます。 AWS_PROFILE を使う 通常 AWS CLI をつかうときは以下のように --profile オプションを使ってプロファイルを指定します。 $ aws s3 ls --profile my-profile しかし、aws cli を連続で打つ場合などに毎回 --profile オプションを指定するのは面倒です。そこで、環境変数 AWS_PROFILE にプロファイル名を指定しておくと、--profile オプションを省略してコマンドを実行できます。 $ export AWS_PROFILE=my-profile $ aws s3 ls aws cli を使って、AWS の大量のリソースをセットアップしたいという時は使うと良さそうです。 その他の環境変数 その他に、AWS CLI でサポートされている環境変数としては以下のようなものがあります。 AWS_ACCESS_KEY_ID AWS_CA_BUNDLE AWS_CLI_AUTO_PROMPT AWS_CLI_FILE_ENCODING AWS_CLI_S3_MV_VALIDATE_SAME_S3_PATHS AWS_CONFIG_FILE AWS_DATA_PATH AWS_DEFAULT_OUTPUT AWS_DEFAULT_REGION AWS_EC2_METADATA_DISABLED AWS_ENDPOINT_URL AWS_ENDPOINT_URL_ AWS_IGNORE_CONFIGURED_ENDPOINT_URLS AWS_MAX_ATTEMPTS AWS_METADATA_SERVICE_NUM_ATTEMPTS AWS_METADATA_SERVICE_TIMEOUT AWS_PAGER AWS_PROFILE AWS_REGION AWS_RETRY_MODE AWS_ROLE_ARN AWS_ROLE_SESSION_NAME AWS_SDK_UA_APP_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_SHARED_CREDENTIALS_FILE AWS_USE_DUALSTACK_ENDPOINT AWS_USE_FIPS_ENDPOINT AWS_WEB_IDENTITY_TOKEN_FILE それぞれの詳細はいかのサイトを参照してみてください。

こんにちは、 @kz_morita です。 今回は、 『関数型ドメインモデリング ドメイン駆動設計とF# でソフトウェアの複雑さに立ち向かおう』 という本を読んだので感想を書きます。 書籍について 『関数型ドメインモデリング ドメイン駆動設計とF# でソフトウェアの複雑さに立ち向かおう』 という本で、アスキードワンゴから出版されています。 2024 年 6 月 28 日に出版されているので割と新しめな本です。 以下のような目次の内容になっています。 推薦のことば 日本語版へ寄せて 訳者まえがき はじめに 第1部　ドメインの理解 第1章 ドメイン駆動設計の紹介 第2章 ドメインの理解 第3章 関数型アーキテクチャ 第2部　ドメインのモデリング 第4章 型の理解 第5章 型によるドメインモデリング 第6章 ドメインの完全性と整合性 第7章 パイプラインによるワークフローのモデリング 第3部　モデルの実装 第8章 関数の理解 第9章 実装：パイプラインの合成 第10章 実装：エラーの扱い 第11章 シリアライズ 第12章 永続化 第13章 設計を進化させ、きれいに保つ 著者紹介 訳者紹介 感想など X (旧 Twitter) でこの書籍が発売されたことをしり、関数型でドメインモデリングするという非常に興味深い内容だったので購入して読んでみました。 大きく分けて 3 部構成になっています。 1 部では、ドメインを理解することについて書かれていて、DDD でいうところの戦略的設計について書かれています。 2 部では、モデリングについてで型を使ってモデリングしていく方法について書かれています。 3 部では、実際に関数型でどのように実装するかという点を F# を使ってかなり具体的に書かれています。

こんにちは、 @kz_morita です。 日頃 Snowflake を使用してますが、その中でGROUP BY ALL と EXCLUDE の機能が便利だったので紹介します。 サンプルとなるテーブル 以下のようなオーダーテーブルのデータをサンプルとして使用します。 order_id customer_id order_date product_id quantity price 1 101 2024-01-01 501 2 10.00 2 102 2024-01-02 502 1 20.00 3 101 2024-01-03 501 1 10.00 4 103 2024-01-04 503 3 15.00 5 104 2024-01-05 504 5 25.00 6 101 2024-01-06 501 4 10.

こんにちは、 @kz_morita です。 今回は、『 達人に学ぶDB設計 徹底指南書 ～初級者で終わりたくないあなたへ 』という本を読んだのでその感想などを書いていきます。 書籍について 『 達人に学ぶDB設計 徹底指南書 ～初級者で終わりたくないあなたへ 』という名前の本で、翔泳社から出版されています。 https://www.shoeisha.co.jp/book/detail/9784798124704 目次は以下のようになっています。 第1章　データベースを制する者はシステムを制す 1-1　システムとデータベース 1-2　データベースあれこれ 1-3　システム開発の工程と設計 1-4　設計工程とデータベース 第2章　論理設計と物理設計 2-1　概念スキーマと論理設計 2-2　内部スキーマと物理設計 2-3　バックアップ設計 2-4　リカバリ設計 第3章　論理設計と正規化 ～なぜテーブルは分割する必要があるのか？ 3-1　テーブルとは何か？ 3-2　テーブルの構成要素 3-3　正規化とは何か？ 3-4　第1正規形 3-5　第2正規形 ～部分関数従属 3-6　第3正規形 ～推移的関数従属 3-7　ボイス－コッド正規形 3-8　第4正規形 3-9　第5正規形 3-10　正規化についてのまとめ 第4章　ER図 ～複数のテーブルの関係を表現する 4-1　テーブルが多すぎる！ 4-2　テーブル同士の関連を見抜く 4-3　ER図の描き方 4-4　「多対多」と関連実体 第5章　論理設計とパフォーマンス ～正規化の欠点と非正規化 5-1　正規化の功罪 5-2　非正規化とパフォーマンス 5-3　冗長性とパフォーマンスのトレードオフ 第6章　データベースとパフォーマンス 6-1　データベースのパフォーマンスを決める要因 6-2　インデックス設計 6-3　B-treeインデックスの設計方針 6-4　統計情報 第7章　論理設計のバッドノウハウ 7-1　論理設計の「やってはいけない」 7-2　非スカラ値（第1正規形未満） 7-3　ダブルミーニング 7-4　単一参照テーブル 7-5　テーブル分割 7-6　不適切なキー 7-7　ダブルマスタ 第8章　論理設計のグレーノウハウ 8-1　違法すれすれの「ライン上」に位置する設計 8-2　代理キー ～主キーが役に立たないとき 8-3　列持ちテーブル 8-4　アドホックな集計キー 8-5　多段ビュー 8-6　データクレンジングの重要性 第9章　一歩進んだ論理設計 ～SQLで木構造を扱う 9-1　リレーショナルデータベースのアキレス腱 9-2　伝統的な解法 ～隣接リストモデル 9-3　新しい解法 ～入れ子集合モデル 9-4　もしも無限の資源があったなら ～入れ子区間モデル 9-5　ノードをフォルダだと思え ～経路列挙モデル 9-6　各モデルのまとめ 付録　演習問題の解答 索引 感想など まず、この本を読もうと思ったモチベーションはテーブル設計 (主にマスターテーブル) を行ったときに、うまく言語化できないが使いづらい設計になったためどのあたりに問題があるのか？といった点を明確にしたいという点にありました。

こんにちは、 @kz_morita です。 スプレッドシート上でサクッと集計したいケースに使えるちょっとした Tips を紹介します。 対象のテーブル 以下のような従業員と、部署と売上のカラムを持つようなテーブルを考えます。 employee_id employee_name department sales 1 Alice Sales 5000 2 Bob Sales 3000 3 Charlie Marketing 2000 4 David Sales 4000 5 Eve Marketing 3500 6 Frank IT 2800 7 Grace IT 3200 8 Henry Marketing 1500 UNIQUE と SUMIF で集計する まずは集計するキーを UNIQUE 関数で生成します。

こんにちは、 @kz_morita です。 開発をしていると技術選定する機会がよくあります。特にデータエンジニアリングをしているといろいろな周辺ツールを触り、技術選定することが多いです。 今回は、意思決定をする際に活用している ADR と意思決定マトリクスについて書きます。 意思決定マトリクス 最終的に、技術選定を行い決定する際によく活用しているものとして意思決定マトリクス (Decision making matrix) があります。 意思決定マトリクスとは、意思決定する候補と、その評価指標を表形式にまとめて最終的にどれを採用するか決める手法です。 例えば、今日の晩ごはん、カレーにするか、ハンバーグにするか、からあげにするか、サバの味噌煮にするかという意思決定をするとします。 意思決定の評価軸として、以下のようなものを用意してみました。 おいしいか つくるのが楽か 材料費 低カロリー 以下のような表にまとめます。 夕食案 おいしいか つくるのが楽か 材料費 低カロリー スコア カレー 5 4 2 2 13 ハンバーグ 4 3 3 3 13 からあげ 4 2 4 2 12 さばの味噌煮 3 3 4 5 15 (※ 説明用なので各指標のスコアは適当です。筆者はさばの味噌煮が好きです)

こんにちは、 @kz_morita です。 Warp というターミナルの存在は知っていたのですが、Ubuntu でも使えるということを知ったので、早速 インストールして使ってみようと思います。 https://www.warp.dev/ インストール手順 TOP ページ に行くとダウンロードリンクがあるのでポチッと押してダウンロードします。 (windows 版はまだないらしく、Waitlist に登録しておけるようです。) 自分は、ubuntu の環境なので .deb を落とします。 落としたらそのままインストールします。 Sign up 画面がでてくるので、指示通り Signup しました。 いろいろな機能 登録すると、いろいろな初期設定が行えます。テーマ設定とかできますがこの時点でリッチで良い感じです。 ひときわ目立つのが右側にある、Warp AI です。 例えばコマンドをど忘れしたみたいなときに AI に雑に聞けるのは非常に便利そうだなと思いました。 見た目の変更もいろいろできそうで、最初に開いた際に日本語フォントがデフォルトで明朝体っぽいものになっていたのが気になったので修正しました。 Ubuntu では Ctrl + , で設定画面を開くことが出来ます。 Appearance から設定をいじることができそうでした。 自分は一旦 DejaVu Sans mono に落ち着きました。 他にも自分で Theme を作って yml で管理することなどもできそうです。 https://docs.warp.dev/appearance/custom-themes また、Ctrl + Shift + P でコマンドパレットを開くことが出来て、そこから画面の分割など様々なことができそうです。（この辺は VSCode に似てるかなと思いました。）

こんにちは、 @kz_morita です。 普段 Docker を用いて開発環境を構築していますが、以下のようなエラーが発生しました。 {services名} Additional property additional_contexts is not allowed 今回はこのエラーの解消方法についてまとめていきます。 エラーの解消 今回は以下のような docker-compose.yml ファイルでエラーが発生しました。 あくまで一例です。 version:'3'x-hoge:&hogeadditional_contexts:- hoge=/path/to/hoge/services:python:build:context:.<<:*hogevolumes:- .:/app:sample_appports:- "8080:8080"- "8888:8888"environment:<<:*environmentエラー内容をみると、addtional_contexts というプロパティが存在しないために発生していました。 (再掲) {services名} Additional property additional_contexts is not allowed 公式サイトをみると、additonal_contexts は Docker の 2.17.0 に追加された機能で、それ以前のバージョンを使っている人がエラーになっていることがわかったのでアップデートをしてもらって解決しました。 Compose Build Specification | Docker Docs additional_contexts とは additional_contexts プロパティを使用すると、Docker Image をビルドする際に名前付きのコンテキスト情報を定義することができます。 今回は Dockerfile 側が以下のようになっていました。 FROM python:3.9-slim WORKDIR /app COPY --from=hoge hogefile.txt /hoge/ COPY requirements.txt . RUN pip install -r requirements.

こんにちは、 @kz_morita です。 5/26 にオフラインで開催された技術書典 16 にサークル参加してきました。 今回は、同僚の方に誘われてボードゲームを制作して頒布してみて、面白かったので内容を書いていこうと思います。 以下のサークルに参加しました。 極地分析所 ボードゲーム制作 きっかけは、同僚の方にデータエンジニアリング関連でボードゲームを制作する予定だけど興味あります？といったお誘いでした。 たしかその時はなんとなくボードゲームを作成したいといった内容しか決まっていなく、じゃあ実際に何を作ろうかおというところから話し合いを行うことになりました。 どんなボードゲームを作るかという点も決めるために、最初にチームのみんなとボードゲームで遊んだりしてイメージを膨らませました。 自分は全くしらなかったのですが、 ボードゲームアリーナ というサイトがあるそうで、数多くのボードゲームをオンラインで遊ぶことができます。 オンライン飲み会とかでこの辺りで遊ぶの楽しそうだなと思いました。 色々考えた結果、 ボードゲーム自体のルールなどはシンプルなほうが良い 既存ゲームにデータエンジニアリング関連のニュアンスを追加する といった方針が決まり、データ系の職種を集めてプロジェクトを成功させるという世界観の麻雀のようなゲームになりました。 主にみんなで、牌の種類（役職）や、上がり役、特別なカード (知識カード、イベントカード)、そのほか細かいルールなどを考えていきました。 各カードにはフレーバーテキストが書かれているのですが、全カードダブりなく別々のフレーバーテキストを載せました。 この時に ChatGPT など、流行りの生成AI をフル活用しました。100 パターン近くのテキストを頭で考えるのは非常に骨が折れるため、これは非常に助かりました。 また、ボードゲームについての解説と紹介されている役職や知識に関する解説を行うガイドブックも同時に執筆しました。 こちらは電子版のみの用意となりました。 そして、ボードゲーム自体の印刷は、ボードゲーム専用の印刷所があるらしくそちらを利用していました。 萬印堂 初めて、ボードゲームを作りましたが、大変だった反面かなり新鮮で面白かったです。 技術書典 16 で売ってみて 当日池袋サインシャインシティへ、制作したボードゲームを引っ提げて参加しました。 ボードゲーム制作費用の関係もあり値段も本に比べるとやや高く、またターゲット層もデータ系の職種でやや狭いということもあり購入してもらえるか心配でした。 しかし、予想よりも反響がありそこそこの数を売ることができました。 ボードゲームということで、面白がって立ち止まってくれる方も多く、いろんな方が話を聞いてくれて非常にありがたかったです。 特にデータエンジニアをやっていたり、データ系の職種として働いている人に結構刺さりがよく、チームで遊んでみます！といった声をいただいたりして非常に嬉しい限りでした。 実際にいただいた声で、確かになーと思ったのは、会社に置いておきたいから解説本も物理本で欲しかったという話や、今リモートで働いているのでオンラインで遊べるようにならないですか？ということがあり、これはむちゃくちゃ確かになーと思ったりしました。 オンライン化結構大変そうですが、作ってみたら面白いかなと思ったのでおもむろに作り出すかもしれません。 まとめ 今回は、技術書典 16 でボードゲームを頒布してみた話を書きました。 ボードゲームをワイワイ作るのも楽しかったですが、実際に購入してくださる方や面白がってくれるととても嬉しいですね。 前回サークル側で参加したのが、技術書典 7 で 2019 年 だったので 5 年ぶりになるのですが非常に楽しかったです。 次は本も執筆して頒布したいなと思いました。 こういうお祭り的なイベント非常に好きなので、来年も参加したいなと思います。

こんにちは、 @kz_morita です。 今回は、 データエンジニアリングの基礎 という本を読んだのでその感想です 書籍について 書籍名は、 『データエンジニアリングの基礎 ―データプロジェクトで失敗しないために』 です。 この本は、2024 年 03 月に日本語訳版が出版されたばかりの本です。 書籍の内容は以下のような感じです。 Ⅰ部　データエンジニアリングの基礎と構成要素 1章　データエンジニアリング概説 1.1　データエンジニアリングとは何か 1.2　データエンジニアリングのスキルと活動 1.3　組織内でのデータエンジニアリング 1.4　結論 1.5　参考資料 2章　データエンジニアリングライフサイクル 2.1　データエンジニアリングライフサイクルとは何か？ 2.2　データエンジニアリングにおける主要な底流 2.3　結論 2.4　参考資料 3章　適切なデータアーキテクチャの設計 3.1　データアーキテクチャとは何か？ 3.2　良いデータアーキテクチャの原則 3.3　主要なアーキテクチャの概念 3.4　データアーキテクチャの例と種類 3.5　データアーキテクチャの設計にかかわるのは誰か 3.6　結論 3.7　参考資料 4章　データエンジニアリングライフサイクルにおけるテクノロジの選択 4.1　チームのサイズと容量 4.2　市場投入までのスピード 4.3　相互運用性 4.4　コスト最適化とビジネス価値 4.5　現在vs.未来：不変テクノロジvs.一過性テクノロジ 4.6　設置場所 4.

こんにちは、 @kz_morita です。 久しぶりに、 『達人プログラマー』 を読んだので感想などをまとめます。 書籍について 書籍名は、 『達人プログラマー』 です。 現在は第2版がでてますが、もっていたのは初版だったので初版を読みました。 内容は、以下のとおりです。 序文 まえがき 第1章　達人の哲学 1 猫がソースコードを食べちゃった 2 ソフトウェアのエントロピー 3 石のスープと蛙の煮物 4 十分によいソフトウェア 5 あなたの知識ポートフォリオ 6 伝達しよう！ 第2章　達人のアプローチ 7 二重化の過ち 8 直交性 9 可逆性 10 曳光弾 11 プロトタイプとポストイット 12 専用の言語 13 見積もり 第3章　基本的なツール 14 プレインテキストの威力 15 貝殻（シェル）遊び 16 パワーエディット 17 ソースコード管理 18 デバッグ 19 テキスト操作 20 コードジェネレータ 第4章　妄想の達人 21 契約による設計 22 死んだプログラムは嘘をつかない 23 [表明]プログラミング 24 いつ例外を使用するか 25 リソースのバランス方法 第5章　柳に雪折れ無し 26 結合度の最小化とデメテルの法則 27 メタプログラミング 28 時間的な結合 29 単なる見かけ（ビュー） 30 ホワイトボード 第6章　コーディング段階 31 偶発的プログラミング 32 アルゴリズムのスピード 33 リファクタリング 34 テストしやすいコード 35 邪悪な魔法使い（ウィザード） 第7章　プロジェクトを始める前に 36 要求の落とし穴 37 不可能なパズルを解く 38 準備ができるまでは 39 仕様の罠 40 丸と矢印 第8章　達人のプロジェクト 41 達人チーム 42 どこでも自動化 43 容赦ないテスト 44 すべてはドキュメント 45 大きな期待 46 誇りと愛着 付録A リソース 1 専門の学会 2 図書の充実 3 インターネット上のリソース 4 参考文献 付録B 演習問題の解答 付録C クイックリファレンスガイド 訳者あとがき 索引 .

こんにちは、 @kz_morita です。 今回は、 『プログラマー脳』 を読んだので感想を書きます。 書籍について 書籍名は、 『プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ』 で秀和システムから出版されています。 以下のような内容となっています。 Part 1 コードをよりよく読むために Chapter 1 コーディング中の混乱を紐解く 1.1 コードにおけるさまざまな種類の混乱 1.2 コーディングに影響を与えるさまざまな認知プロセス 1.3 それぞれの認知プロセスが協調的に動作する仕組み 本章のまとめ Chapter 2 コードを速読する 2.1 コードの速読法 2.2 記憶のサイズ制限を克服する 2.3 読めるコードよりも見えるコードのほうが多い 本章のまとめ Chapter 3 プログラミング言語の文法を素早く習得する方法 3.1 文法を覚えるためのテクニック 3.2 フラッシュカードを使って文法を素早く覚える 3.3 物忘れを防ぐには 3.4 文法を長く記憶に留めるには 本章のまとめ Chapter 4 複雑なコードの読み方 4.1 複雑なコードを理解するのが難しい理由 4.2 認知的負荷を軽減するテクニック 4.3 ワーキングメモリに負荷がかかっているときに使える記憶補助ツール 本章のまとめ Part 2 コードについて考える Chapter 5 コードの深い理解に到達する 5.1 「変数の役割」フレームワーク 5.2 役割とパラダイム 5.3 プログラムに関する知識を深める 5.4 文章を読むこととコードを読むことは似ている 5.

こんにちは、 @kz_morita です。 今回は 『エンジニアリング組織論への招待』 を読んだので感想を書きます。 書籍について 書籍名は、 『エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング』 で、技術評論社さんの方から発売されています。 以下のような内容になっています。 Chapter 1　思考のリファクタリング 1-1　すべてのバグは，思考の中にある 1-2　不確実性とエンジニアリング 1-3　情報を生み出す考え方 1-4　論理的思考の盲点 1-5　経験主義と仮説思考 1-6　全体論とシステム思考 1-7　人間の不完全さを受け入れる Chapter 2　メンタリングの技術 2-1　メンタリングで相手の思考をリファクタリング 2-2　傾聴・可視化・リフレーミング 2-3　心理的安全性の作り方 2-4　内心でなく行動に注目する Chapter 3　アジャイルなチームの原理 3-1　アジャイルはチームをメンタリングする技術 3-2　アジャイルの歴史 3-3　アジャイルをめぐる誤解 3-4　アジャイルの格率 Chapter 4　学習するチームと不確実性マネジメント 4-1　いかにして不確実性を管理するか 4-2　スケジュール予測と不確実性 4-3　要求の作り方とマーケット不安 4-4　スクラムと不安に向き合う振り返り Chapter 5　技術組織の力学とアーキテクチャ 5-1　何が技術組織の“生産性”を下げるのか 5-2　権限委譲とアカウンタビリティ 5-3　技術的負債の正体 5-4　取引コストと技術組織 5-5　目標管理と透明性 5-6　組織設計とアーキテクチャ 感想など この本を読もうと思ったきっかけは、普段エンジニアリングをしている中で組織についてやメンタリングについて興味を持ったことです。 本自体は以前から気になっていたしかなり有名な本であるので読んでみようと思いました。

こんにちは、 @kz_morita です。 GitHub の Copilot とても便利なので、neovim でも利用してみました。 とても簡単に設定できたのでおすすめです。 Copilot について GitHub Copilot はAI によるコーディングアシスタントで、かなり精度の良いコード補完が特徴です。 個人向けのプランも有り、１ヶ月あたり 10 ドル (2024年4月14日時点で、1500円ほど) で導入することができます。 詳細は以下を参照してみてください https://docs.github.com/ja/copilot/copilot-individual/about-github-copilot-individual Setup それでは Copilot の neovim への導入ですが公式が、copilot.vim というプラグインを用意してくれているのでそれを利用します。 https://github.com/github/copilot.vim 自分は Package Manager に Dein を使用していて、init.vim に以下のように書いています。 let s:toml_file = '~/.config/nvim/dein.toml'let s:toml_lazy_file = '~/.config/nvim/dein_lazy.toml'if dein#load_state(s:dein_dir) call dein#begin(s:dein_dir) call dein#load_toml(s:toml_file, {'lazy': 0}) call dein#load_toml(s:toml_lazy_file, {'lazy': 1}) call dein#end() call dein#save_state()endifそのため、インストール自体は、dein.toml に書くだけです。

こんにちは、 @kz_morita です。 Ubuntu で apt update などを実行したときにエラーがでて、調べながら対応したのでまとめます。 NO_PUBLEY エラー 以下のようなエラーです。 アップグレードできるパッケージが 1 個あります。表示するには 'apt list --upgradable' を実行してください。 W: 署名照合中にエラーが発生しました。リポジトリは更新されず、過去のインデックスファイルが使われます。GPG エラー: http://repo.mysql.com/apt/ubuntu bionic InRelease: 公開鍵を利用できないため、以下の署名は検証できませんでした: NO_PUBKEY HOGEHOGEHOGEHOGE (HOGEHOGE 書いてるところは仮の文字列で、状況によって異なります) このエラーは PUBLIC KEY が見つからないので再度ダウンロードしてくる必要があります。 以下のような、コマンドで追加できます。 $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys HOGEHOGEHOGEHOGE 例えば、Google Cloud のような ubuntu の keyserver 以外から取得する際は以下のようなコマンドになります。 $ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add - 署名照合中にエラー 以下のようなエラーです。 W: 署名照合中にエラーが発生しました。リポジトリは更新されず、過去のインデックスファイルが使われます。GPG エラー: https://dl.yarnpkg.com/debian stable InRelease: 以下の署名が無効です: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.

こんにちは、 @kz_morita です。 今回は Redash の Query Results についてまとめます。 Redash の Query Results Redash は OSS の BI ツールで、各種データソースと接続して SQL を書いたり簡単にグラフなどの Visualize を作成したりできるツールです。 Redash には Query Results という仕組みがあります。 https://redash.io/help/user-guide/querying/query-results-data-source Query Results は、Redash 上で作成されたデータをソースとしてクエリをかける仕組みです。 Redash ではクエリを作成すると ID が振られるのですが、このクエリ同士を JOIN してクエリを書くことが出来ます。 SELECTa.name,b.categoryFROMquery_100asaJOINquery_500asbONa.id=b.id上記は、queryID が 100 のクエリ結果と、500 の結果を JOIN している例です。 query_{queryID} というテーブル名で参照することが出来ます。 Redash のクエリ結果を JOIN するので、別データソース（例えば MySQL と Snowflake のテーブル）を JOIN するといったことが出来ます。 SQLite 注意点として、Redash の Query Results で書く SQL は SQLite になります。

こんにちは、 @kz_morita です。 開発のフェーズに応じてスピードを大事にする、質を大事にするみたいな会話はよくあります。 プロトタイピングをつくっているフェーズにおいて質を犠牲にしてスピードを重視した結果、スピードが落ちるという経験を最近しました。 頭では質を高めるとスピードも上がるという点がわかっていたのですが、失敗を経験したので振り返ってみます。 質とスピードについて 結論は以下のスライドにすべて書いてあります。 質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） / Quality and Speed AWS Dev Day 2023 Tokyo Edition - Speaker Deck 内部品質とスピードはトレードオフではなく、相互に高めあう正のフィードバックループということです。 今回の開発では、BIツールを用いてダッシュボードをプロトタイプするということを行っていて、その最中に品質が落ちた結果スピードも落ちるということを経験しました。 具体的には以下のような問題がおきました。 ペアプロを実施していて Pull Request のレビューを Skip した結果、情報共有不足で重複したデータモデルをつくってしまった データモデリングの設計が甘く、名前と実態が一致しないためにわかりづらいモデルができてしまった 質が落ちる原因 今回の件をうけ、品質が落ちる原因は以下にあると考えています。 スピードを優先したつもりの手抜き 知識不足 スピードを優先したつもりの手抜き Pull Request レビューをスキップしたというのがこちらの問題かなと思います。 他にもテストを書かなかったり、場当たり的なパッチのような開発をしたりというのがこちらに当たるかと思います。 一見短期的に早く仕上がるように見えるのでこういった開発をしがちなのですが、実際にツケが回ってくるのは思っているよりも早いです。 今回はそれを身をもって実感しました。 私は特にこれをやってしまいがちなので気をつけたいです。 期日が明確にあるタスクなど終わらないのではというプレッシャーから逃れるためにこういった手抜きをしてしまいがちです。 一見スピードを優先しているように見えて、楽な開発を選んでいるだけなのではないかという点は問い続けていきたいと思います。 知識不足 データモデリングの設計が甘かったのは、知識不足が原因だと考えています。 甘いと言いつつ、実際にモデリングした当初はこれがベストだと思っていました。しかし、実際にプロトタイプをつくっていく中でこのモデルだとうまくいかなかったり、わかりづらいという点が見えてきました。 これは、手抜きをしたというよりは、プロジェクトの進行にともなってプロジェクトに関する知識 (技術的知識、ドメイン知識) が増えことによるものです。 基本的に、プロジェクトが進行するにつれて開発者の知識はどんどん増えていくためプロジェクトの後期でされた意思決定ほど精度が高くなります。 そのため、アーキテクチャを考える時に意思決定をできるだけ遅らせるように設計するという点が非常に重要になってきます。 また、知識がアップデートされたタイミングで既存のシステムもアップデートしていくという点が非常に重要だと再認識しました。(リファクタリングをしよう) 今回の件で、知識がプロジェクト進行により増えていき過去のシステムが古く違和感を持つようになることを身をもって経験しました。 まとめ 質とスピードについて振り返った内容を書きました。

こんにちは、 @kz_morita です。 BigQuery はいままでちゃんと触ったことがなかったのですが、使用する機会がありそうだったので、料金について調べたまとめです。 料金体系 まず大きく分けて、以下の２つがあります。 ストレージ料金 コンピューティング料金 コンピューティング料金のほうがいくつかプランがあり検討する必要があります。 それぞれ見ていきます。 ストレージ料金 ストレージ料金は、BigQuery へデータを保存するのにかかる費用です。 無料枠として、毎月 10 GiB まで利用できます。 ストレージには、アクティブストレージと、長期保存用のストレージがありそれぞれ価格が違います。 また課金対象を論理バイトにするか、物理バイトにするかも変更することができるようです。 物理バイトは、最適化などがされたあとのバイト数なので料金が安くなることもありそうです。 （利用には条件がありそうです。） 料金は 2024/03/31 時点で以下の用になっています。(asia-northeast1 Region) 以下はすべ 1 月あたりの金額です Active logical storage: $0.023 per GiB Long-term logical storage: $0.016 per GiB Active physical storage: $0.052 per GiB Long-term physical storage: $0.026 per GiB くわしくは以下公式サイトを参照してください https://cloud.google.com/bigquery/pricing#storage コンピューティング料金 コンピューティング料金は大別して以下の２種類があります。 オンデマンド料金 容量の料金 (スロット時間単位) オンデマンド料金は、クエリによりスキャンされたデータに対して課金がされるものです。 無料枠として 1TiB が利用できます。 できます

こんにちは、 @kz_morita です。 今回は、 『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』 という本を読んだので感想を書きます。 書籍について 書籍名は 『GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ』 で翔泳社から発売されています。 https://www.shoeisha.co.jp/book/detail/9784798183916 以下のような内容になっています。 第1部　リモート組織のメリットを読み解く 第1章　世界最大のリモート組織「GitLab」 第2章　リモート組織によって得られるメリット 第2部　世界最先端のリモート組織へ移行するためのプロセス 第3章　リモート組織を構築するためのプロセス 第4章　リモートワークで発生する問題と対策 第3部　GitLabが実践するリモート組織を活性化させるカルチャー醸成法 第5章　カルチャーはバリューによって醸成される 第6章　コミュニケーションのルール 第7章　リモート組織におけるオンボーディングの重要性 第8章　心理的安全性の醸成 第4部　GitLabが成果を出すために実践している人事制度や業務ルール 第9章　個人のパフォーマンスを引き出す 第10章　GitLab Valueに基づいた人事制度 第11章　マネージャーの役割とマネジメントを支援するためのしくみ 第12章　コンディショニングを実現する 第13章　L&Dを活用してパフォーマンスとエンゲージメントを向上させる</p> 感想など まずこの本を読もうと思ったモチベーションは、リモートワークでの働き方やドキュメント文化など日頃の開発業務で重要な点についてなにか知見が得たいというものです。 私はリモートワークから徐々にオフィス出社が増えてきて、現在所属の会社でも週一で出社しています。 基本的に出社日を揃えているので同じ日にオフラインで作業しているのですが例外的に遠方に住んでる方などが、一部リモートワークで働くいわゆるハイブリッドワークで働くこともあります。 しかし、ハイブリッドワークだとオフライン組とオンラインの人でどうしても情報量の差が出てしまう。例えば意思決定がオフラインの場でなされていて、オンラインの人に伝わってなかったりすることしばしば起きていました。 このような問題に対する解決策や、そもそもリモートで協働する際に重要なことなどが学べるかなーと思い本を手に取りました。 実際に読んでみて、リモートワークを前提としてコミュニケーションの方法や、徹底した GitLab handbook を用いた働き方など、参考になるところが多かったです。 ローコンテキストな文章を心がけるということや、非同期でのコミュニケーションについて多く書かれていました。 本文内で登場する かすれたインクは鮮明な記憶にまさる 言葉もとても印象的です。

こんにちは、 @kz_morita です。 Pytest を初めて触ってみたのでメモです。 前提のプロジェクト構成 以下のような ディレクトリ構成の python プロジェクトを想定しています。 . ├── poetry.lock ├── pyproject.toml ├── src │ ├── main.py │ └── utils │ ├── __init__.py │ └── utils.py └── tests ├── __init__.py ├── conftest.py ├── test_main.py └── utils ├── __init__.py └── test_utils.py src ディレクトリと、tests ディレクトリに別れているような標準っぽいものです。 poetry を使って package 管理などをする前提です。 pythonpath などの指定 tests ディレクトリから、src ディレクトリをみにいくために設定が必要でした。 設定は pyproject.toml もしくは pytest.ini、.pytest.ini などファイルに書くことができます。 下記は、pyproject.toml に書く例です。 [tool.pytest.ini_options] pythonpath = "src" testpaths = ["tests"] 基本の assert src/main.

こんにちは、 @kz_morita です。 Hono と Bun 気になっていたフロントエンドの技術ですが、ちょっとしたツールを作る際に画面側も用意したいとなったので、つかってみた際のメモです。 https://hono.dev/ https://bun.sh/ 結論から言うと、上記の公式サイトの Setup と、React を導入する際に以下の記事を参照したらサクッと構築できました。 HonoでAPI付き雑React SPA最小 Install まずは、Bun のインストールから実施します。 # Install Bun $ curl -fsSL https://bun.sh/install | bash .profile (各個人の環境に合わせたもの。.bashrc とかでもOK ) に以下追加 $ export PATH="$PATH:$HOME/.bun/bin" 反映 $ source ~/.profile パスが通ったら確認します。 $ bun --version 1.0.29 $ bunx Usage: bunx [...flags] <package>[@version] [...flags and arguments] Execute an npm package executable (CLI), automatically installing into a global shared cache if not installed in node_modules.