はてなブックマーク

自分ではコーディングやコマンドの実行などを行わずプロンプトによる指示だけで進める、いわゆる「バイブコーディング」で開発を行った。 Cloud Storage に csv ファイルが入っているだけの状態から、 BigQuery Data Transfer Service の定期実行で BigQuery にデータを転送、そしてそのデータを dbt で加工することで目当ての集計結果を得る、ということを実現できたので、かなり簡素ではあるが一応データパイプラインと呼べるものを作れたのではないだろうか。 元々自分は AI コーディングに詳しくなく、プロンプトエンジニアリングに関する知識も何もない。 そういう自分が、 バイブコーディングでどこまで出来るのか、何ができるのか、何は難しいのか、について感触を得るために、やってみた。 そのため、精度や効果を高めるための工夫などは何もしていない。Claude C

最近『データエンジニアリングの基礎』という本を読み始めた。 この本の冒頭で、データエンジニアリングやデータエンジニアの定義は曖昧で、人によって言っていることがバラバラだという話が出てくる。そこで著者たちは自分たちなりの定義を示し、それに則ってデータエンジニアリングの全体像を解説することを試みている。 「データエンジニアリング」が指すものが定まっていない、というのは自分も日々実感している。指すもの、イメージするものが、人や組織によって違いすぎる。 単に言葉の定義の問題ではなく、「データエンジニア」と称される人が実際に何をやっているのかは、組織によって本当にバラバラだと思う。 そんな状態なので、各組織の各データエンジニアが何をしているのか外からはよく分からないだろうし、データエンジニアが何に面白さを感じているのかも世間に伝わりづらいと思う。 この記事では、私が HERP のデータエンジニアとし

「30歳からのプログラミング」と題したこのブログを書き始めたのが 2016 年 3 月。 そこから月日が立ち、立派なアラフォーとなったわけだが、私はこれまで 3 年以上継続して働いたことがない。プログラマに転身する前も含めて、である。一度もない。 3 年経つ前に、必ず無職になってしまう。労働して貯めた貯金を食い潰しながら無職生活を送り、カネが無くなりそうになってまた働く、ということを繰り返している。 だが、今の勤務先(株式会社HERP)に入社したのは 2021 年 10 月 1 日であり、入社してからもうすぐ 3 年になる。 つまり、 3 年以上労働を続けることになる可能性が高い。 仮にこの記事を投稿した直後に退職を決意したとしても、引き継ぎや有給休暇の消化などで、さすがに 9 月末までは在籍していると思う。そうなれば 3 年到達である。 今までの会社を辞めてきた理由は様々だ。同様に、今の

dbt を使おうとすると、profile や target、config、property など、様々な概念が出てくる。 それらをあまり理解できていなくても、何となく動かすことはできるかもしれない。 しかし、これらの概念を理解していないと、意図した通りに動かしたり他者が記述した設定内容を理解したりするのは難しい。 この記事では、最初は理解が難しいこれらの概念について、「model の出力先の設定」を題材にして説明していく。 dbt runした際にどこにテーブルやビューが出力されるのか、設定を読み解いて理解できるようになることを目指す。 この記事の内容は dbt のバージョン1.8.5で動作確認している。 データウェアハウスは BigQuery を使用する。 概要 どのデータウェアハウスのどのテーブルにあるデータを使うのか、データの出力先はどこになるのか。 そういった設定には「profile

UNIX やそのツールはどのような考えに基づいて作られているのか解説した本。 UNIX が開発されていくなかで培われていった文化や考え方について書かれている。 www.ohmsha.co.jp UNIX が具体的にどのように動いているのかではなく、 UNIX はなぜそのように動いているのか、ということが主題。 そのため、 UNIX に限らずソフトウェア開発全般に適用できるような内容になっている。ソフトウェアだけでなく「ものを作る」こと全般に応用できる内容も多いかもしれない。 私も、現時点では UNIX そのものに対する熱意や探究心はあまりないので、 UNIX について知るためではなく開発の参考になる考え方がないかと思って読んだ。 9 つの定理が紹介されているのだが、まず思ったのは、「言うは易く行うは難し」という感じの定理ばかりだなということ。 例えばシンプルに保て、小ささを維持しろ、という

この記事では、 Web API で文字列の可逆圧縮を行う方法について書いていく。 任意の文字列を圧縮し、そして圧縮された文字列のリテラル表現から元の文字列を復元できることを目指す。 以前書いたように、 Node.js なら文字列の可逆圧縮は簡単に行える。 numb86-tech.hatenablog.com また、 JavaScript でデータの圧縮を行うためのライブラリも、探してみれば色々と見つかる。 だがこの記事では、ブラウザ環境でも動作するコードを、ライブラリに頼らずに実装していく。 完成したコードは成果物の節に載せてある。 この記事に出てくるコードの動作確認は以下の環境で行った。 Deno 1.29.1 TypeScript 4.9.4 Compression Streams API Compression Streams API は、データの圧縮や展開を行うための API で、

Next.js のv13.1.0で追加されたskipTrailingSlashRedirectを使うことで、 trailing slash に関する挙動を自由に設定できる。 この記事では、skipTrailingSlashRedirectによって具体的にどのようなことが可能になったのかを見ていく。 動作確認はv13.1.1で行った。 環境構築 まずは Next.js の環境構築から。 $ yarn create next-app sample --ts こうするとsampleというディレクトリが作られるので、そこに移動して作業を進めていく。 まず、next.config.jsのbasePathに"/app"を指定する。 /** @type {import('next').NextConfig} */ const nextConfig = { reactStrictMode: true, b

前回読んだ『Joel on Software』の Joel Spolsky が、ソフトウェア開発者の採用について論じた一冊。 自身が優秀な開発者であり経営者でもある Joel が、多くのソフトウェア開発者が採用に対して何となく感じていることを平易な文章で明快に説明していく。 詳しく調べてはいないが、本書の内容も基本的に Joel on Software で公開されている記事をまとめたものだと思う。 例えば「第 2 章 優れた開発者を見つけるには」は、以下の記事を翻訳したものになっている。 エッセイ集なので採用業務について体系立てて論じているわけではないが、それゆえに非常に読みやすい。しかし内容は薄くない。 「分かってはいるが実践は困難」「この基準を満たす開発者がどれだけいるんだ」と思いたくなる内容もあるが、主張している内容はいずれも真っ当なものばかり。 Joel 自身が本書の内容を実践して

Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。 Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。 ひとつひとつの章がかなり短い(長いものでも 20 ページくらい、短いものだと 4 ページほど)ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。 技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。 無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。 本書に収録されているのは 2000 年から 2004 年に書かれた記事なので

この記事では、 Unicode において表示不可能な文字を表現する「置換文字」について説明する。 この記事に出てくるコードの動作確認は以下の環境で行った。 Deno 1.26.0 TypeScript 4.8.3 概要 Unicode において、表示しようとした文字が何らかの理由で表示不可能なとき、黒い菱形に白いクエスチョンマークが書かれた文字が表示される。 「�」がそうなのだが、環境によっては表示されずカギカッコの中が空白になっているかもしれないので、画像も載せておく。 この文字を「置換文字」と呼ぶ。 サロゲートペアとして不正なケース 文字が表示不可能な例として、サロゲートペアとして正しくないケースがある。 サロゲートペアや Code Point の概要は以前書いたので、必要ならこちらを読んで欲しい。 numb86-tech.hatenablog.com Code Point のうち一部

この記事では、 JavaScript で文字コードを扱う際に知っておくべき概念である Code Point や Code Unit、サロゲートペア、といったものについて説明していく。 また、具体的にそれらの概念を使ってどのようにコードを書いていくのかについても扱う。 この記事に出てくるコードの動作確認は以下の環境で行った。 Deno 1.26.0 TypeScript 4.8.3 Code Point (符号位置) プログラムで文字を表現する方法は複数あるが、 JavaScript では Unicode という方法を採用している。 Unicode ではあらゆる文字に対して一意の値を割り振ることを目的としており、この値のことを Code Point (符号位置)という。 Code Point は 16 進数の非負整数で、文章中で表記するときは接頭辞としてU+をつける。 例えばAという文字の

この記事では、継続渡しスタイル(continuation passing style、以下 CPS)の概要と、CPS の活用例を書いていく。 この記事に出てくるコードの動作確認は TypeScript の4.7.4で行っている。 後続の処理を引数として渡す 関数が終わった後に実行される後続の処理をその関数の引数として渡すスタイル、そういったプログラムの書き方を、 CPS と呼ぶ。 例えば、以下のようなコードがあるとする。 const getLength = (str: string): number => str.length; const n: number = getLength("hello"); console.log(n); // 5 getLength("hello")の結果をnに代入し、それを使ってconsole.logを実行している。 getLengthを CPS に書き換

Node.js には Stream というインターフェイスが用意されており、これを使うことでデータをストリーミングできる。 Stream を使うことで、データの全てをメモリに保持するのではなく、少しずつ順番にデータを処理していくことが可能になる。 この記事では、Stream の基本的な使い方について説明していく。 WHATWG で定義している Stream はまた別の概念なので、注意する。この記事で扱っている Stream は、それとは別に以前から Node.js に実装されている Stream である。 以下の環境で動作確認している。 Node.js のバージョン 16.15.1 使っている npm ライブラリ @types/node@16.11.43 ts-node-dev@2.0.0 typescript@4.7.4 環境構築 まず最初に、手元で実際にコードを動かすための環境を構築す

CDN のエッジサーバにコンテンツをキャッシュしておくことで、コンテンツのダウンロードを高速化できる。 エッジサーバは物理的にユーザーに近い場所にあり、レイテンシが小さくなるため。また、エッジサーバは配信に最適化されているため、その点でも高速化が見込める。 しかし、ただ CDN を導入すればそれだけで最適なキャッシュを行ってくれるわけではない。 そもそも、全てのコンテンツをキャッシュしてもらいたいわけではない。ウェブサイトによっては、キャッシュして欲しくないコンテンツ、キャッシュされたら困るコンテンツも存在するはず。 キャッシュする場合も、短期間だけキャッシュさせたいコンテンツもあれば、可能な限り長くキャッシュさせたいコンテンツもある。 そしてそういったことは CDN には判断できないので、開発者が明示的に設定する必要がある。 つまり、CDN を効果的かつ安全に使うためには、CDN の使い

Docker への入門の一環として、自分で Dockerfile を作成し、それを使って Node.js アプリを Docker Container で動かしてみる。 Hello World Dockerfile を使うことで、既存の Docker Image を編集して新しい Docker Image を作ることができる。 具体的には、Dockerfileという名前のファイルにコマンドを記述していくことで、その内容に基づいた Docker Image を作成できるようになる。 例えば以下の Dockerfile では、FROMとCMDというコマンドを使っている。これらのコマンドの意味は後述する。 FROM node:16 CMD [ "echo", "Hello World" ] カレントディレクトリに上記のDockerfileがある状態で% docker build -t sample

トレイトを使うと、任意の振る舞いを抽象化し、それを複数の型に持たせることができる。 この記事では、トレイトの基本的な使い方を見ていく。 Rust のバージョンは1.55.0、Edition は2018で動作確認している。 基本的な書き方 例として、IceCreamとEnglishClassという 2 つの構造体を用意した。 共通するフィールドはひとつもないし、それぞれに独立して存在する異なる型だが、トレイトを使うことで「ある同じ振る舞いを持ったグループ」として抽象化できる。 struct IceCream { unit_price: f64, flavor: String, } struct EnglishClass { hourly_price: f64, hour: f64, difficulty_level: String, } 今回の例では、小計価格を計算する振る舞いを持たせること

Prisma は、Node.js の ORM。 この記事では、導入方法、基本的な使い方について説明したのち、Prisma を使って簡単な API サーバを作ってみる。 Node.js のバージョンは16.13.2、MySQLのバージョンは8.0.28という環境で、動作確認している。 使用している npm ライブラリのバージョンは以下の通り。 @prisma/client@3.11.0 @types/node@16.11.26 prisma@3.11.0 ts-node-dev@1.1.8 typescript@4.6.2 MySQL のインストール ORM である Prisma を試すためには、まずデータベースをセットアップしないといけない。今回は MySQL を使うことにする。 この記事では Homebrew を使ってインストールしているが、他の方法でももちろん問題ない。 % brew

この記事では、GraphQL を利用したアプリを Next.js で構築していきながら、GraphQL の初歩について書いていく。 GraphQL のクライアントもサーバも、Apollo を用いる。 また、できるだけ型安全に開発したいので、graphql-codegenで型定義ファイルを生成する方法も扱う。 利用しているライブラリのバージョンは以下の通り。 @apollo/client@3.5.10 @graphql-codegen/cli@2.6.2 @graphql-codegen/typed-document-node@2.2.7 @graphql-codegen/typescript-operations@2.3.4 @graphql-codegen/typescript-resolvers@2.5.4 @graphql-codegen/typescript@2.4.7 @type

サーバ・クライアント間の通信を gRPC で行う場合、インターフェイスを定義した共通のファイルから、サーバとクライアント双方のコードを生成することができる。 この記事では、インターフェイスの定義ファイルを作成するところから始めて、gRPC を利用した単純なウェブアプリを作っていく。 gRPC についての概念的な説明などは扱わず、実際に手元で動くウェブアプリを作ることで、gRPC を使った開発についてイメージしやすくなることを意図している。 Next.js では API Routes を使って API サーバを作ることができるが、それを gRPC クライアントとして実装する。 そのため、リクエストの流れは以下のようになる。 Frontend == (REST) ==> API Routes == (gRPC) ==> gRPC Server 動作確認は Node.js のv16.13.2で行

2 年ぶりに労働し始めたことでブログの更新頻度が露骨に落ちているが、文章を全く書いていないわけではなく、折に触れて社内で長文を投下している。 社内向けの怪文書ばかり書いていて、パブリックなブログを全然書けない。— なむ (@numb_86) 2021年12月29日 内容は本当に個人的なものというか、自分が考えていることや思っていることを書いているだけで、ブログと同じノリでやっている。 これは私だけがやっているわけではなく、例えば代表の庄田も最近考えていることや意識していることを scrapbox に書いていて、いくつかはブログの一部として社外にも公開されている。 自分の考えを文章にすることは私にとって自然なことなので深く考えずに書いていたのだが、その結果、会社から特別手当が支給された。 勤務先の HERP ではクオーター単位で全社的な振り返りを行っているのだが、そのタイミングで、会社が掲げ

React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい

「科学的な営業」に興味があり、その分野の定番のひとつである『THE MODEL』を読んだ。 どのように営業プロセスを構築し機能させるのかについてコンパクトにまとまっているので、特に BtoB SaaS を提供している企業で働いている開発者は、一度読んでおくとよいと思う。 www.shoeisha.co.jp なんとなくの印象だが、「営業」というものについて、自分とは縁遠いもの、別の世界のもの、という感覚を持っている開発者は多いかもしれない。 自分もそうだった。むしろ、かなり悪い印象を抱いていた。 新卒で入った信用金庫の営業スタイルが絵に描いたような根性論、精神論だったのが大きい。 「飛び込み営業をすれば嫌がられるし、何度も訪問すれば怒られる。それでも諦めずに通い続けることで根性を認めてもらえて、取引してもらえるんだ」ということを役員が真顔で語っていたし、「昔は「契約するまで帰りません」と玄

技術選定を行う前にまず、どのような開発組織にしたいのか、どのように事業を進めていきたいのか、そこを整理しないと上手くいかない。 そんなことを最近考えていたので、ブログに書いておく。自分は書くことで思考を整理していくので。 この記事では、「技術選定」そのものについて書いていく。 そのため、個別のライブラリの良し悪しを判断する手法などについては扱わない。もっと抽象度の高い、どのような考え方や態度で技術選定に臨むべきか、というようなことを書いていく。 また、作りたいものを作れるか、仕様を満たせるか、セキュリティ上の問題はないか、などの当然の前提は省く。 そういった「最低条件」を満たした技術が複数あったときにどうやって選ぶのか、という意味での「技術選定」を扱う。 お互いの「納得感」のためにもまずは軸を明確にする 技術選定について考えたり誰かと議論したりする際には、「自分たちは今、どういう観点を基準

Rust の所有権や借用に関する学習メモ。 Rust のバージョンは1.52.1、Edition は2018で動作確認している。 所有権 変数を値に束縛すると、変数はその値の所有者であり、その値の所有権を持っていると表現される。 以下のコードでは、_xは"foo"の所有者であり、"foo"の所有権を持っている。 fn main() { let _x = "foo".to_string(); } 変数がスコープから外れたら、その変数が所有している値は破棄される。言い換えれば、メモリが解放される。 Rust では{}でスコープを作れるため、以下のような挙動になる。 fn main() { { let _x = "foo".to_string(); // メモリに "foo" が格納される } // _x がスコープから外れ、その際に "foo" がメモリから破棄される } このような方法でメモ

2019 年の夏に前職を辞め、そのまま無職として過ごし今年の 10 月にようやく再就職して働き始めた。 何か事情があって働けなかったわけではなく、プログラミングの能力を伸ばすために敢えて就職しなかった。 自分にとってそれなりに重要な期間だったと思うので、記録を残しておく。 予め断っておくが、何か「すごいこと」を成し遂げたわけではない。「すごくないプログラマ」が少しでもすごくなりたくて勉強していた話に過ぎない。 「すごいプログラマ」が「すごいこと」をした話を読みたければ、以下の記事などがよいと思う。 会社をやめて約1年プログラミングの勉強に費やしたことに対する満足と後悔 | blog.ojisan.io 2年間の独学をふりかえって – Happy Coder 予防線を張ったところで、本題に入る。 背景や動機 プログラミングの勉強をするために前職を辞めたわけではなく、退職の理由は別にある。 そ

個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。本当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし

エッジサーバからのレスポンスは速い。 コンテンツを CDN のエッジサーバにキャッシュしてそれを返すようにするだけで、ウェブサイトの速度は目に見えて改善される。 特に、リクエストの度にサーバで動的に生成されるコンテンツの場合、キャッシュを利用することで大きな恩恵を受けられる。パフォーマンスが改善されるだけでなく、オリジンサーバの負荷軽減にもつながる。 しかしコンテンツを動的に生成するということは、リクエストの度に生成されるコンテンツが変わる可能性があるということであり、キャッシュを利用するのが難しい。全てのリクエストに対して同じコンテンツが生成されるのであれば、わざわざリクエストの度に生成する必要はないからだ。事前にコンテンツを用意しておいてそれを返せばよい。ビルド時にコンテンツを生成する SSG(Static Site Generation)などがその一例。 リクエストの度にコンテンツが

Cloudflare Workers KV は、Cloudflare のエッジサーバからアクセスできる、グローバルなキーバリューストア。 Workers スクリプトからアクセスして使う。 各エッジサーバ毎に存在するのではなく全てのエッジサーバが共有するストアであるため、API など様々な用途で使える。 そしてエッジサーバで動くため、レイテンシが小さくなるというメリットもある。 この記事では、既に Cloudflare Workers を利用しているサイトに Workers KV を導入する手順を見ていく。 まず、名前空間を作成し、それを Workers と紐付ける必要がある。 名前空間の作成は Cloudflare のダッシュボードからもできるが、ここでは CLI ツールの wrangler を使う方法を紹介する。 Workers スクリプトのディレクトリで、以下のコマンドを実行する。wr