サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
numb86-tech.hatenablog.com
この記事では、Embulk を使ってデータ転送を行う方法について述べていく。 今回は題材として Amazon RDS から Google Cloud の BigQuery にデータを転送する。Embulk の実行はローカルマシンで行う。 使っている Embulk のバージョンは0.9.25。 0.10や0.11だと異なる手順や設定が必要になると思われるので注意。 事前準備 まずは Amazon RDS のインスタンスを作成する。今回はデータベースの種類は MySQL にした。バージョンは8.0.35。 ローカルマシンから Embulk を実行する都合上、パブリックアクセスを「あり」にしておく必要がある。そして、セキュリティグループを適切に設定し、ローカルマシンの IP アドレスからのアクセスを許可しておく必要もある。 作成後は$ docker run -it --rm mysql mysq
Terraform では GitHub の Branch protection rule を管理する resource が提供されている。この記事ではそれを使って rule を定義する方法について扱う。 動作確認は Terraform のv1.7.4で行った。 Branch protection rule は、指定したブランチに対してルールを設定する仕組みで、pull request に対してレビューを必須にする、特定のテストをパスしないと merge できないようにする、などのルールを設定することができる。 GitHub の UI から設定可能だが、Terraform で管理していくこともできる。 Terraform には GitHub Provider が提供されており、その中には Branch protection rule を扱う resource もある。そのためそれを使えば、T
この記事では Docker Desktop 上で Kubernetes クラスタを作り、実際に動かしながら、Kubernetes の基本的な仕組みについて説明していく。 動作確認は以下の環境で行った。 Docker Desktop 4.22.1 Kubernetes 1.27.2 事前準備 Kubernetes の有効化 Docker Desktop のダッシュボードから設定画面を開き、Enable Kubernetesのような項目を有効にすると Kubernetes を使えるようになる。 kubectlコマンドが使えるようになっていれば問題ないはず。 $ kubectl -h kubectl controls the Kubernetes cluster manager. コンテナイメージの用意 sampleという名前で、以下の内容のウェブサーバが動くコンテナイメージを作成しておく。 i
Unix プロセスとはどのようなもので、どのような特徴を持つのか、平易な文章と簡潔なコードを使って解説していく一冊。 tatsu-zine.com プロセスID、プロセスの親子関係、標準ストリームといった、プロセスに関する基本的な概念について説明していきながら、プロセスに対する理解を深めていく。 あくまでも入門的な内容だから、ということもあるだろうけど、とにかく読みやすい。 各章が短いので少しずつ読み進めていくことができるし、本書全体も 100 ページ超なので、気付いたら読み終えていた。 実際にコードを実行して確認できるのもいい。 forkで子プロセスを作ってそのpidやppidを確認したり、forkが値を 2 回返すことを確認したり、シグナルを送ってプロセスを終了させることができることを確認したり、といったことを繰り返していくことで、理解が深まっていく。 環境構築が簡単なのもよい。Uni
スクラムのように見えるがスクラムではない、機能していないスクラムを「ゾンビスクラム」と名付け、なぜそれが発生するか、いかにそこから回復すべきかを説いた一冊。 ゾンビスクラムという、上手くいっていない状態を題材にすることで、本来はどうあるべきなのか、どのような状態を目指すべきなのかが、自然と理解できるようになっている。 www.hanmoto.com スクラムガイドの内容がシンプルすぎることが、スクラムフレームワークの実践の難しさの一つになっていると思っている。 PBI には何を書けばいいのか、リファインメントはどのように行うのか、各種スクラムイベントはどのように進めればいいのか、具体的な方法はほとんど記述されていない。 組織や事業によって状況は異なるのだから、具体的なことが書かれていないのは当然だとは思う。 それに、何か具体的な方法論を書いてしまうと、どれだけそれを「一例である」と断ったと
「リスク」をどのように捉え、どのように向き合っていくべきなのか説いた一冊。 用語や概念の整理をしつつ、具体的にどのように取り組むべきかを論じていく。 2003 年頃に出版されたということもあってか、ソフトウェアの受託開発を念頭に置いた説明が多いが、基本的な考え方はそれ以外のプロジェクトにも適用できるはず。 bookplus.nikkei.com リスクを取らずに済むのであれば、そうすればよい。わざわざ危ない橋を渡る必要はない。 だがリスクと利益は切っても切れない関係にあり、成功を掴むためにはリスクを避けて通ることはできない。 著者らは、「リスクのないプロジェクトに手を出してはいけない」とまで言う。 しかし同時に、リスクを無視するのも愚かな行為であると主張する。 不確定性を数量化し可視化すること、過去のデータを活用すること、あたりがリスク管理の中心的な考え方なのかなと読んでいて思った。 未来
MySQL には SQL Mode という設定があり、この内容によって、許容される構文やデータの妥当性チェックのルールが変化する。 この記事では SQL Mode の確認方法や設定方法の他、設定内容によって挙動が変化する例を見ていく。 動作確認は MySQL のバージョン8.0.28で行った。 環境構築 まずは動作確認用の MySQL コンテナを用意し起動する。 % docker run --name test_db -dit -e MYSQL_ROOT_PASSWORD=password mysql:8 以下のコマンドを入力するとパスワードを求められるので、先程MYSQL_ROOT_PASSWORDとして設定したpasswordを入力する。 % docker exec -it test_db mysql -p 確認と設定 現在の SQL Mode の設定内容はsql_modeというシステ
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
http://numb86.net/tech/react-runner/ クリックするとジャンプするので、ひたすら障害物を避けていく。 今回の技術的な目的は、Reactに慣れること、Jestによるテストの実践、Gitのよりスマートな利用、といったあたり。 Reactではアニメーションをどうするのか気になったので、その実験という意味合いもある。 まあまずまず、だろうか。 やはりまだまだ、Reactには慣れていない。どう書くのがベターなのかがよく分かっておらず、「取り敢えず動くものは作れるけど……」というレベル。もっと経験を増やして、ひたすら素振りをして、慣れていくしかない。 Gitも、まだまだ。単純にコミットを積み重ね、それをマージしてプッシュして、くらいなら問題ないが、イレギュラーなことをやろうとすると、苦しい。 まあこっちは、いろんなケースを経験することで自然に慣れている気がしているが。
この記事では Base64 やbtoa、そしてbtoaの挙動を理解するために必要な Latin1 について説明していく。 この記事に出てくるコードの動作確認は以下の環境で行った。 Deno 1.28.3 TypeScript 4.8.3 概要 Base64 はデータのエンコード方式の一種。 全てのデータをa~z(26 文字)、A~Z(26 文字)、0~9(10 文字)、そして+と/を合わせた計 64 文字、さらにそこに=を組み合わせたテキストで表現する。 そうすることで、扱えるデータに制限のある環境において、その制限を超えたデータを扱えるようになる。 例えば電子メールではテキストデータしか扱えないが、バイナリデータを Base64 にエンコードしてしまうことで、問題なくバイナリデータを送信できるようになる。あとは受信側で Base64 をデコードすればよい。 他にも、 Data URL で
前回読んだ『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 環境構築 まず最初に、手元で実際にコードを動かすための環境を構築す
Amazon Web Services(以下 AWS)の入門書。 AWS やその前提となる知識について、非常に平易に解説している。理解を促すための図も豊富で、分かりやすい。 AWS を学ぶ最初の一冊としてオススメ。 gihyo.jp AWS が提供しているサービスは多岐に渡り、独自の用語も多い。 そのため全体像を掴みづらく、入門者の心をへし折りやすい技術だと思う。少なくとも自分は何度もへし折られてきた。 できることが膨大すぎて、どこから手を付けていいのか分からない。 調べ物をしていても、次から次へと知らない用語が出てきて途方に暮れる。 結果、ググって出てきた記事の内容を模倣してお茶を濁す。取り敢えずやりたいことは実現できているのだが、自分がどんな操作をしたのかは分かっていない。本当に、「言われた通りにやったら動いた」というだけ。 これではいつまで経っても自分で考え判断できるようにはならない
CDN のエッジサーバにコンテンツをキャッシュしておくことで、コンテンツのダウンロードを高速化できる。 エッジサーバは物理的にユーザーに近い場所にあり、レイテンシが小さくなるため。また、エッジサーバは配信に最適化されているため、その点でも高速化が見込める。 しかし、ただ CDN を導入すればそれだけで最適なキャッシュを行ってくれるわけではない。 そもそも、全てのコンテンツをキャッシュしてもらいたいわけではない。ウェブサイトによっては、キャッシュして欲しくないコンテンツ、キャッシュされたら困るコンテンツも存在するはず。 キャッシュする場合も、短期間だけキャッシュさせたいコンテンツもあれば、可能な限り長くキャッシュさせたいコンテンツもある。 そしてそういったことは CDN には判断できないので、開発者が明示的に設定する必要がある。 つまり、CDN を効果的かつ安全に使うためには、CDN の使い
Docker の volume は、コンテナが使うデータを永続化するための仕組みで、これを使うことでコンテナのライフサイクルとは別にデータを管理することができる。 また、network という機能を使うことで、コンテナ間で通信ができるようになる。 この記事では、volume と network の基本的な使い方を見ていく。 コンテナを削除すればそのなかにあるデータも削除されてしまう 基本的に Docker のコンテナは、一度作ったものを長く大切に使い続けるのではなく、作成と破棄を繰り返して使うことが多い。 そしてコンテナを破棄すれば、コンテナのなかにあるデータも当然失われてしまう。 MySQL のコンテナで試してみる。 まずコンテナを作り起動させる。 % docker run --name test_db -dit -e MYSQL_ROOT_PASSWORD=password mysql
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」という用語がタイトルに入っているが、これは今後は使われなくなってい
TypeScript には条件型(Conditional Type)という機能があり、これを使うと型定義に条件分岐を持ち込むことができる。 この記事の内容は TypeScript のv3.9.5で動作確認している。 条件型の基本 T extends U ? A : Bが、条件型の構文。 TがUに割り当て可能なときはA、そうでないときはBを意味する。 そしてtype Example<T> = T extends U ? A : B;のように、ジェネリック型と組み合わせて使う。 ジェネリック型については、以前記事を書いた。 numb86-tech.hatenablog.com 条件型とジェネリック型の組み合わせ例を示す。 以下のIsStringは、渡された型引数Tがstringに割り当て可能なときはtrueを、不可能なときはfalseを返す。 type IsString<T> = T exte
次のページ
このページを最初にブックマークしてみませんか?
『30歳からのプログラミング』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く