Next.js でブログを書いて Vercel でホストしている話

今年の中旬に転職してから、まとまった量の TypeScript (React) コードを書くようになり、その流れで Next.js にも興味を持つようになった。Next.js の公式ドキュメントでは “CREATE YOUR FIRST APP” セクションでブログを作成している。チュートリアル的な内容とはいえ、写経していくと、それなりにきちんと動くものができあがる。Next.js および、ドキュメントを書いた方の力量は素晴らしいと思う。

一通り理解した後で、同じ内容を TypeScript で書き直し、CSS を SASS で置き換え、Vercel にデプロイした。しばらくは新規のブログ記事はこちらに書いていこうと思う。まだまだ道半ばなブログで、たとえば RSS フィードなどがないし、ページングなども実装されていない。それらについても折を見て実装していこうと思う。

今後ともどうぞよろしくお願いします。

SSH ログインがスタックする問題とその解決法

自前で管理している SSH サーバーにログインしようとしたら、次のメッセージで止まるようになった。 Last login: Fri Oct 21 21:53:19 2022 from 100.xxx.xxx.xxx ServerFault にあるこちらの質問と似た現象である。次のコメントが気になった。 This just happened to me. In my case it turned out that a recent change to my .bashrc file was causing an infinite loop (.bashrc was sourcing .bash_profile which was sourcing .bashrc, doh!) 実はこの SSH サーバーでもシェル (Zsh) の設定を変更したばかりであったので、もしかしたらこれかもしれないと思った。 しかし、そもそも SSH できないサーバーのシェルの設定をどうすればいいのだろう…と思ったが、次のようにすればよいだけであった。この環境では Bash の設定は変わっていないので、SSH 越しに Bash を起動すればよい。 ssh mahata@my-machine.example.com -t bash こうして起動した Bash からエディタを起動して . [Read More]

TypeScript におけるタプルの型

TypeScript では、要素数が限定された配列をタプルと呼ぶ。 タプル型には面白い特徴がある。 const foo = ["a", 1]; としたとき foo の型は [string, number] ではなく (string | number)[] になる。したがって、次のコードは failTuple の初期化時に型エラーになる。 const foo = ["a", 1]; // (string | number)[] const failTuple: [string, number] = foo; // 型エラー!! これを回避するための簡単な方法は、型を明示的に指定することである。具体的には次のようにする。 const bar: [string, number] = ["a", 1]; // [string, number] const successTuple: [string, number] = bar; as const をつけて変数を初期化することもできる。次の例では bar の型は readonly [string, number] となり、タプルの中身は変更できない。 const bar: [string, number] = ["a", 1]; // readonly [string, number] const successTuple: [string, number] = bar; // successTuple[0] = "b"; // エラー! [Read More]

JavaScript/TypeScript の Array.prototype.reduce() でハッシュを作る

JavaScript/TypeScript における Array.prototype.reduce() (以下、reduce() とする) は配列から単一の値を作るために使われるメソッドである。典型的には次のような使われ方をする。 const total = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].reduce((prev: number, curr: number) => { return prev + curr; }, 0); console.log(total); // 55 配列にある複数の要素を、単一の値に reduce (= まとめあげ) している、ということだ。 reduce で、配列を単一のハッシュに変換することもできる。次のような配列を考えよう。 [ { name: "ケンシロウ", style: "北斗神拳", strength: 10, }, { name: "ジャギ", style: "北斗神拳", strength: 5, }, { name: "レイ", style: "南斗聖拳", strength: 8, }, ]; これを次のように変換したいとする。 { "ケンシロウ": { "style": "北斗神拳", "strength": 10 }, "ジャギ": { "style": "北斗神拳", "strength": 5 }, "レイ": { "style": "南斗聖拳", "strength": 8 } } この変換は reduce を使うと簡単に実現できる。 [Read More]

ブログを書く理由

ブログを書く動機について、現時点でのメモを残しておこうと思う。

僕の職業プログラマーとしてのキャリアは、2005 年にブログサービスを作ることからはじまっている。ブログというサービスにはそれなりの愛着がある。

過去には Movable Type を「さくらのインターネット」でホストして、気が向いたときに記事を書いた。はてなダイアリーにも日記を書いていた。今ではどちらも閉じていて、履歴も残っていない。はてなダイアリーは、友人から「自分を特定できるような書き方の記事があるので (その記事を) 消して欲しい」と言われ、そのタイミングで「面倒なので全て消すか」と思い、アカウントごと削除した (補足: 一般に特定できるように書いてはいないが、近い人間からは推測がついてしまう、というレベル)。また、同じようなタイミングで自分でホストしていた Movable Type も消した。

この決断には後悔している。

自分のブログの一番の読者は自分だと思う。何かを検索したときに自分のブログ記事がひっかかる確率は高い。昔の自分が解決した困りごとでも、時間が経てば解決方法を忘れてしまう。そうなったときに頼りになるのは昔の自分からの便りである。それを捨てるなんてとんでもない!!

昔の自分の記事を読むと恥ずかしい気持ちになることもある。たとえば 2012 年に自分が書いた JVM の実行オプションのメモ書きを読むと、「君はそんなことも知らなかったのか…」という気持ちになる。でも、こういう記事こそ消してはいけないものだと今は思う。こういう記事のおかげで、今の自分は昔より「少しはマシだ」と思える。

自分が、自分のために、ブログを書いている、というスタンスは大事にしていきたい。過去には Google Analytics を入れてアクセス解析をしたこともあるけど、Google Analytics 4 へのアップデートがアナウンスされたタイミングで、ブログからアクセス解析機能を落とした。自分のためのブログに、他人がどのくらい訪れるか気にするのは変だと思う。もちろん、書いていることが自分以外の誰かのためになれば嬉しいけど、主目的ではない。

同じような理由から、ブログをバズらせたいとは思わない。むしろ、バズりたくない。少なくとも自分の手で、ブログ記事をソーシャルメディアで拡散するようなことはしない。

ブログを公開することで、未来の自分に今の自分の理解を伝えたい。公開することで、間違ったことを書かないように自分自身を律したい。昔の自分の記事を「ばかばかしい記事だ」と思えるのであれば、それは喜ばしいこと。そういう気持ちで、今はブログを書いている。

ボタン画像のクリック時にボタンを枠線で囲む方法

転職にともないフルスタックエンジニアとして仕事をするようになったので、フロントエンド技術にも手を出すことが増えてきた。この領域は不得手で苦労している。 先日、仕事の一部としてボタン画像 (i.e., <button /> の中に <img /> を入れて、画像をクリック可能にしたもの) を実装した。このとき、クリック後のボタンには「選択済み」であることを示すために枠線をつけたいという要望があり、この課題にどうアプローチしたかについて、メモを残そうと思う。 パターン1 (JavaScript を使わないパターン) 先に実装を示す。 See the Pen VEYRqX by mahata (@mahata) on CodePen. ボタンの縦幅と横幅を 104px 取っている。これは 100px の画像に、二本ずつ 2px のボーダーを入れるため 100 + (2 * 2) で 104px と計算している。 初期状態ではボタンに透明なボーダーを入れており、ボタンが押されたとき (= :focus 擬似クラスが有効になったとき) にボーダーの色を red に変更している。 次の部分はボタン内の画像を中央寄せするために書いている。 .button { display: flex; justify-content: center; align-items: center; ... } 画像は縦幅と横幅が 100px で表示しているため、透明なボーダーの中にぴったり収まる。 パターン2 (JavaScript を使うパターン) こちらも先に実装を示す。 See the Pen VEYRqX by mahata (@mahata) on CodePen. [Read More]

アジャイル、スクラム、エクストリームプログラミング

アジャイルとエクストリームプログラミングの関係について、同僚と色々と話をした。この記事は自分自身の理解内容をメモする目的で書いた。 アジャイルとは何か? 「アジャイル」の原典はアジャイルマニフェストであり、ここに書かれている価値観のことを「アジャイル」と言う。 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも 個人と対話 を、 包括的なドキュメントよりも 動くソフトウェア を、 契約交渉よりも 顧客との協調 を、 計画に従うことよりも 変化への対応 を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 ここで気づくことは 2 点ある。 ひとつは旧来のソフトウェア開発手法を否定していないことだ。「左記のことがらに価値があることを認めながらも」と言っている。旧来の「プロセスやツール、ドキュメント」などにも価値を認めているのである。単に「それより価値のあるものがある」と述べているに過ぎない。 もうひとつは「How」がまったく書かれていないことである。すなわち「で、どうすればいいの?」についてはアジャイルマニフェストの範囲外、ということである。そして、この How にあたる部分が「スクラム」であり「エクストリームプログラミング」である。 スクラムとは何か? 「スクラム」の原典はスクラムガイドである。この資料ではスクラムの定義を次のようにしている。 スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。 この「軽量級フレームワーク」はソフトウェア開発に限定したものではない。「スクラムガイド」本文には “ソフトウェア” や “プログラム” という言葉は現れない (注: 前書きに一箇所だけ出てくる)。つまり、スクラムはあらゆる種類のモノ作りに対応しているが、これをソフトウェア開発に適用するとなると、それ相応の解釈が必要になる。 この解釈の違いがスクラム開発のバラエティを生んでいる。つまり「スクラムで開発をしています」と言うチームが複数あるとき、そのプラクティスの詳細は異なることが多々ある。 エクストリームプログラミングとは何か? 「エクストリームプログラミング」の原典は同名の書籍である。この書籍の第七章の見出しは次の通りである。 7.1 全員同席(Sit Together) 7.2 チーム全体(Whole Team) 7.3 情報満載のワークスペース(Informative Workspace) 7.4 いきいきとした仕事(Energized Work) 7.5 ペアプログラミング(Pair Programming) 7.6 ストーリー(Stories) 7.7 週次サイクル(Weekly Cycle) 7.8 四半期サイクル(Quarterly Cycle) 7. [Read More]

【読書メモ】エクストリームプログラミング

近く転職する予定なのだが、転職先で上司になる予定の人から勧められたので『エクストリームプログラミング』を読んだ。 冒頭の「推薦の言葉」のセクションが実にうさんくさい。次のような言葉が並ぶ。 ソフトウェア開発は本来とても楽しいものだ。新しい価値が世の中に提供されることに、自分自身も仲間も、時には競合相手でさえも興奮を隠せずワクワクしてしまう。しかしやり方を間違うと、関係者が次々と不幸になっていってしまうこともある。XP はこうした不幸を避け、人間関係を良好に保ち、それぞれが仕事を楽しみながら求められる成果を出していくための方法論だ。(略)。 小野和俊 株式会社アプレッソ 代表取締役社長、株式会社セゾン情報システムズ CTO 他にも: XP は私の人生を変えた。(略)。本書は「XP とは何か」だけでなく「よりよい仕事・よりよい人生を送るための道」を示している。(略)。 懸田剛 Agile459 代表、日本 XP ユーザーグループ創立スタッフ 『エクストリームプログラミング』は技術書ではないのか? 「不幸を避ける」? 「人間関係を良好に保つ」? 「よりよい人生を送る」? これは自己啓発本なのか? 本書を読み進めることで、この「推薦の言葉」の意味が理解できた。僕のような XP に慣れていない人間には、XP は「ペアプログラミング」や「テスト駆動開発」のようなプラクティスを指す言葉のように思える。しかし XP は単なるプラクティスではなく、それがもたらす「価値」や「原則」にも重きを置いている。本書では XP が大事にする原則のひとつとして「人間性」が挙げられている。 「人間性」の章は次のようにはじまる。 人間がソフトウェアを開発する。このシンプルで逃れようのない事実によって、利用可能な方法論の多くがその効果を失っている。ほとんどの場合、ソフトウェア開発は人間の欲求を満たしていない。人間の弱さを認めていない。人間の強さを活用していない。ソフトウェアを人間が開発していないかのように振る舞えば、関係者にかかるコストが高くなり、人間の欲求を認めない非人道的な行為によって、人間性が失われてしまう。こうしたことは、高い離職率に伴うコストや組織の崩壊、クリエイティブな行動の機会損失など、ビジネスにとっても好ましいことではない。 これも含め、本書はソフトウェア開発に関わる人間的な側面を丁寧に記述している。たとえば「よいチームとは?」「よい見積もり (スケジュール)とは?」など。そういう問を深堀りして得られたプラクティスが、ペアプログラミングでありテスト駆動開発である、という感じだ。 ところで XP を採用していないチームに XP を導入するのは大変そうだと思っていた。本書を読んでも「大変そうだ」という感想は変わらない。本書の第 16 章は XP を組織に導入したブラッド・ジェンセン氏 (Senior Vice President of Sabre Airline Solutions) へのインタビューである。ひとつ面白い Q & A がある。 Q: XP の導入は簡単ではなかったと思います。 A: そうですね。最初は 3 分の 1 の人が懐疑的です。その他の 3 分の 1 はすぐに取り入れてくれて、残りの 3 分の 1 は様子を見ています。最終的には、80~90 % が取り入れてくれます。10~20 % は、嫌々 XP を使います。3~5 % は、絶対に取り入れてくれません。ペアを組もうとしなかったり、コードの所有権を主張したりするプログラマーがいたら、解雇する勇気を持つべきです。残ったチームがあなたを助けてくれるはずですから。 [Read More]

仙台旅行 in 2022

仙台市内の実家に住んでいる両親に孫の顔を見せるべく、先月末 (2022年05月) に妻子を連れて帰省した。第二子は人見知りの激しい時期で両親にはあまり懐かなくて少し残念。それでも家族全員、総じてよい体験ができたのではないかと思う。

記録のため、乳幼児連れで楽しめた場所をメモしておこうと思う。

JRフルーツパーク仙台あらはま

「JRフルーツパーク仙台あらはま」は 2021 年に開業した施設である。2011 年の東日本大震災で被災した場所を整地し、営業している。子どもに果物狩りを体験させたくて訪れた。年間を通して様々な種類の果物狩りをさせてくれる。僕たちが訪れた時期はいちご狩りのシーズンであった。

JRフルーツパーク仙台あらはまのマップ

土曜日であったにも関わらず、僕たちの他にもう一組しかビニールハウスにおらず、かなり広い空間を楽しむことができた。いちごも甘くて美味しいものが生っており、親子ともに大満足であった。

いちご狩り

海岸公園馬術壌

子どもに馬を間近で見る機会を持たせたく、訪れた。前述の「JRフルーツパーク仙台あらはま」とは近い場所にある。乗馬レッスンなどもしているようだけど、僕たちは「引き馬 (インストラクターが引いてくれる馬に乗る)」と「餌やり体験」だけ楽しんだ。長男は怖がったので引き馬は途中で断念したものの、餌やりは楽しめたようである。

まだ乳児である次男は特に何もできなかったけど、彼が引き馬を楽しめる年齢になったらまた来てもいいかと思った。

引き馬体験

南小泉交通公園

仙台市にいくつかある交通公園の内、滞在先から行きやすかったのが南小泉交通公園である。長男はまだ自転車に不慣れなので、自動車がばんばん走る道路に出す前に少しトレーニングを積ませたいと思っていた。園内で貸し出している三輪車に慣れるのに手間取ったけど、それなりに楽しめているようであった。

【読書メモ】第2版 ゼロからはじめるデータベース操作

ソフトウェア技術者としての自分の弱点のひとつに「SQL の読み書きが遅い」というものがある。僕は長らく「RDBMS の ACID 特性には価値があるけど、SQL はいまいち表現力が低くて書き心地の悪いものである」と考えていた。さらに言えば「ACID なデータストアを扱うための何らかの DSL が、将来的に SQL を置き換えるだろう」とすら考えていた。

この予想は大外れであった。現代では RDBMS ではないデータストアさえ SQL (もしくは SQL ライクな) インタフェースを備えるようになり、SQL を自在に使いこなせないと日々の仕事に差し障るようになった。つまり、SQL を自在に扱うことのできない僕は、仕事に支障が出るようになってしまったのだ。これはまずい…。

そこで SQL を読み書きする訓練のため、参考書を探すことにした。SQL 関連書籍のレビューを読み漁ると、ミックさんの本の評判がとても良い。最初の一歩として、彼の書籍の中でも「初級」とラベリングされている『SQL 第2版 ゼロからはじめるデータベース操作』を読むことにした。

これは実際のところ、かなり易しく書かれた本である。それでも僕程度の SQL 力だと学べることも多くあった。具体的には CASE 式やウィンドウ関数の読み書きは不得意であったが、それらの機能についても馴染むようになった。「馴染む」と言えば、この本は各章に練習問題がついている点が素晴らしく、読んだ内容を手に馴染ませられるような作りになっている。

また、MySQL, Oracle, SQL Server, DB2, PostgreSQL を対象として書かれている一方で、それらが標準 SQL に準拠していない場合はその旨の記述がある点も素晴らしい。おかげで MySQL での練習もスムーズに行うことができた。ちなみに、この本では「ウィンドウ関数は MySQL では使えない」という記述があるが、MySQL 8.0 以降ではサポートが追加されている。これは余談になるけど、前回の「使い捨て可能な MySQL の実験環境」という記事は、この本の練習問題をこなすための環境構築時に書いたものである。

ところで、練習問題の想定解は書籍のサポートページに掲載されている。 しかし、このページで提供されているファイルは SJIS でエンコードされており、UTF-8 環境では文字化けに悩まされることになる。僕は次のシェルスクリプトで UTF-8 に変換した上で、もろもろの操作を行った。

#!/bin/bash

find . -type f -name '*.sql' | while read -r file
do
    echo "$file"
    iconv -c -f sjis -t utf-8 "$file" | tr -d '\r' > tmpfile
    mv tmpfile "$file"
done
exit