portal shit!

長垂海浜公園には無料の駐車場はありません。有料のコインパーキングを利用する必要があります。料金、駐車可能台数、停めやすさをまとめています。

はじめに

福岡市西区の今宿に長なが垂たれ海浜公園という砂浜や遊具のある広い公園があります。波が穏やかで海を眺めてぼーっとするには良い公園なのですが（魚釣りをしている人もいます）、駐車場がありません。従って近所に住んでる人だけが訪れるスポットになっています。しかし最近、公園近くにいくつかコインパーキングができ、車でもアクセスしやすくなりました。公園と海に近いコインパーキングを五つほど紹介したいと思います。

なお JR 筑肥線の今宿駅前に広めのコインパーキングがいくつかある^*1ので、運転に自信のない方やこれから紹介する駐車場が満車の場合はそちらを利用しても良いと思います。今宿駅から長垂海浜公園までは歩いて 10 分程度です。

コインパーキング一覧

ライオンパーク今宿

唐津街道沿い。 5 台駐車可能です。街道沿いなので車の出し入れはしづらいと思います。右折入庫は難易度高いです。頭から突っ込んで出庫のときにニッチもサッチも行かなくなる可能性あり。必ずお尻から入庫したいものです。

駐車料金

駐車可能台数

5 台

出し入れのしやすさ

△

フラットパーク今宿

唐津街道沿い。一つ目の今宿ライオンパーキングのすぐ近く。 7 台駐車可能ですが小型か軽専用となっています。横幅が狭いので大きめの車で入庫してしまうと出し入れに難儀しそうです。

駐車料金

駐車可能台数

7 台（軽・小型専用）

出し入れのしやすさ

△

三井のリパーク 今宿駅前一丁目第２

唐津街道から少し入った住宅街の中にあります。広めの月極駐車場のうち、手前のオレンジ色の線の部分がコインパーキングで、 5 台止められます。時間あたりの駐車料金は 300 円と天神と同レベル。入庫したら最大料金を支払うつもりで利用するのが良いでしょう。前の道の車通りが少なく、駐車場も広いため出し入れはしやすいと思います。

駐車料金

駐車可能台数

5 台

出し入れのしやすさ

〇

今宿駅前１丁目パーキング

三井のリパーク 今宿駅前一丁目第２すぐ近くのコインパーキングです。民家の前庭部分がコインパーキングにしてあり、 3 台駐車可能です。時間あたりの料金はやはり高めです。こちらは紹介するコインパーキングの中で最も出し入れしやすいと思います。運転に自信のない方におすすめ。

駐車料金

駐車可能台数

3 台

出し入れのしやすさ

◎

國﨑真クリニック提携駐車場

医院併設の駐車場。日・祝日は最大料金の設定がありますが、平日と土曜日の昼間は最大料金の設定がないためご注意ください。100円/20分で非常に高額になる可能性があります。

駐車料金

駐車可能台数

25 台

出し入れのしやすさ

〇

ワイズパーキング今宿駅前1丁目

海辺のシェアオフィスSALTが入居するマリブ今宿シーサイドテラスの駐車場です。こちらも終日 1 時間あたり 300 円で、 500 円の最大料金が設定されています。 3 台駐車可能ですが一台は軽専用です。ちょっと駐車スペースが狭いかな？ 人気のパン屋、ヒッポー製パン所に最も近いです。

駐車料金

駐車可能台数

3 台（うち一台は軽専用）

出し入れのしやすさ

〇

以上、長垂海浜公園近くのコインパーキング情報でした。自分自身、今宿で住む場所を探していたときに車を停めて街をゆっくり見て回りたいと思っても車を止められる場所がなく難儀しました。長垂海浜公園や長垂海岸に遊びに行きたいという方のほか、今宿に引っ越しを検討されている方も街探索の際にお役立てください。長垂海岸では以下のような夕日が眺められます。是非海の近くに車を停めて夕日を眺めに来てください。

*1: 2021-08-01 更新: 駅前のコインパーキングが一つ減りました。マンション建設中です。また駅前のコインパーキングは以前は 60 分 100 円程度でしたが、現在は 60 分 200 円〜に値上がりしてきていますのでご注意ください。

昨年末に今年撮った写真アドベントカレンダーに参加したときに書いた写真で振り返る 2019 年 という記事があるが、今年の 3 月に事故って S3 バケットの画像を吹っ飛ばしてしまったので記憶を辿りながらちまちま画像を上げ直していた。改めて Z6 で撮った写真は良いなと思ってたところで NIKON から新しいフルサイズのミラーレスカメラが発表された。

Engadget | Technology News & Reviews

Find the latest technology news and expert tech product reviews. Learn about the latest gadgets and consumer tech products for entertainment, gaming, lifestyle and more.

japanese.engadget.com

重さはほぼ同じらしい。 USB-C による給電（バッテリーすっからかんの状態で USB-C ケーブルで給電して撮影する）ことが可能になったみたい。 Z6 は電源を入れた状態では充電できないのだが、バッテリーがない状態でも外部から電源を取りながら撮影することができるのでスタジオカメラマンとかウェブカメラとして使う場合には便利なのかもしれない。また、 Z6 では XQD カードか CFExpress カードでないと使えず、しかもシングルスロットなのだが、 Z5 だと SD カードでデュアルスロットになっているようだ。

kakaku.com で調べると Z6 の 24-70 f/4 レンズキットは Z5 が Z6 の上位機種ではなかったためか Z5 発表後に値上がりしてて 27 万円くらいになっている。一方で FTZ という F マウントレンズが Z マウントでも使えるようにするマウントアダプター付きの 24-70 f/4 レンズキットの方が安くなってて 24 万円弱で買えるっぽい。 Z5 の 24-50 f/4-6.3 レンズキットはヨドバシで 22 万円ちょいなのでこれだったら自分は Z6 の 24-70 f/4 FTZ 付きキットの方を激しくおすすめする。連写性能やボタン、サブディスプレイが省かれている Z5 よりも Z6 の方がよい。メディアに SD カードが使えないのはデメリットに見えるかもしれないが（ XQD は高いし別途カードリーダーが必要）、高画質で高速に書き込むためのコストだと思えばよい。

Z6 で撮った写真を以下に貼っておきます。

家で仕事するようになって 3 ヶ月以上経つのだけど、これまでは会社から貸与されている MacBook Pro のディスプレイのみで仕事していた。どうしても大きなディスプレイで仕事したいときは私物 iMac を使うなどしていたけど、職場のルールが厳しくなって私物のパソコンで仕事することができなくなったし、夏で暑くなってきて MacBook Pro 本体のキーボードを触るのがいよいよ厳しくなってきたので、平日の夜に車で会社まで行って会社に持ち込んでいた私物の Dell 4K ディスプレイを自宅に持ち帰り、外付けキーボードで仕事をするようにした。 MacBook Pro 本体のペチペチキーボードよりも Happy Hacking Keyboard の方が快適だ。

ただ、これまで机の上は真ん中に iMac 5K が鎮座していたのでディスプレイの置き場に困ることになった。最初は iMac を真ん中において左にディスプレイ、右に MacBook Pro を置いてみたが、首を 120 度くらい左右に振らないといけないので非常に仕事しづらかった。なので真ん中にディスプレイを置いて左に MacBook Pro 、右に iMac を置くようにした。こんな感じ。

Dell の 4K ディスプレイは入力端子が 3 つあって、 HDMI と Display Port 、 Mini Display Port を受け付けるようになっている。すでに Display Port <-> USB-C ケーブルは持っていたので、 HDMI <-> USB-C のケーブルを買い足して、仕事用の MacBook Pro と私物の iMac 5K の両方に接続してみることにした。

日中仕事しているときは MacBook Pro の外付けディスプレイとして使い、夜は入力チャンネルを切り替えて iMac の外付けディスプレイとして使う。

結構いい感じなのだが問題があって、自分が持っている Dell のディスプレイは P2415Q というやつで、このシリーズの 2016 年 2 月以降の出荷モデルだと HDMI のモードを 2.0 に変更することで 60Hz 表示が可能になるが、自分が持っているのは 2015 年モデルなので 30Hz でしか表示できなかった。

www.dell.com

30Hz 出力だと結構描画がかくかくする感じがあって地味にストレス。 Mini Display Port <-> USB-C ケーブルを買えば iMac からも MacBook Pro からも 4K@60Hz 出力できたのかもしれない。残念。

DHH が Twitter で言及していた記事がおもしろかったので著者の許諾をもらった上で翻訳しました。

Paying remote workers differently solely depending on their zip code is immoral. If you can afford to hire from both San Francisco and St Louis, you can afford to pay both the same for the same work. If you can't afford SF rates, that's fine too! https://t.co/A1nJkPlimG

— DHH (@dhh) May 25, 2020

Salesforce の Product Manager 、 Blair Reeves さんの記事。

Paying Remote Employees Fairly | Blair ReevesPaying Remote Employees Fairly – Blair Reeves

I’ve been a vocal proponent of “remote” working for pretty much all of my career in technology – which, as it happens, started off in a fully remote gig. (Thanks, IBM!) My belief all along &#…

blairreeves.me

僕は自分のテクノロジー業界でのキャリアのすべての期間をリモートワーク擁護者として過ごしてきた。それは自分自身のリモートワークの経験から始まった（ありがとう IBM ！）。以前も書いたことがあるが、リモートワークというものは破壊的なテクノロジーでその優位は揺るぎない。このことは自明なのでここでは労力を割かない。

今週、 Facebook が一部の従業員に対して好きなところに住んでリモートワークすることを認めた（訳注: Zuckerberg says employees moving out of Silicon Valley may face pay cuts ）ことで、これまでたびたび論争になっていたリモートワーカーへの報酬についての議論が再燃した。この問題は究極的にはリモートワーカーにいかに "公平に" 支払うか、ということだ。このことが報酬についての議論を難しくしている。たくさんの会社がこの件に悪戦苦闘しているが、それはよこしまな理由からではない。

とはいえ、正しい議論と間違った議論があると思う。現実主義によって多少脚色されている。

現実的な観点では、テック部門の人件費をサンフランシスコやニューヨーク以外のレートに切り詰めるということだ。たとえば Facebook の Product Marketing Manager の初任給から 20% 削減された金額だとしても、ウィンストン・セーレムやジャクソンビル、リトル・ロック、ブルーミントン（訳注: すべてアメリカの地方都市）に住んでる人には魅力的に思えるだろう。多くの雇い主が給与額で競争するような状況が我々にとっては望ましい。機会が増えることは常に望ましい。だからどんどんやって欲しい。

上記を踏まえた上で主張するが、生活コストに応じた給与額の調整はとても不公平だしよくない習慣だと思う。同じ仕事をして同じ価値を発揮している人には同じ給料を支払うべきだ。

何が変わったか

最近までフルリモートで働くことは多くの人にとって選択肢になかった。もし X 社で働きたいと思ったなら、 X 社のオフィスがある大都市に引っ越す必要があった。それが取引だった。

しかしこれまで自分が働いてきたソフトウェア企業では、ほとんどの人の仕事はオンラインかつリモートでこなすことが可能だったし、実際にそうしていた。そう、すべてだ。プロダクトマネジメント、エンジニアリング、デザイン、オペレーション、マーケティングなどなど。リモートワークに懐疑的な人でさえ心の底ではこのことはわかっている。そしていま、（訳注: コロナウイルスの影響でリモートワークをするようになり）長い間信じられてきたリモートワークの優位性が実際に証明されてしまった。リモートワークで問題ないのだ。リモートワーク懐疑主義者達が間違っていたことが完全に証明された。

言い換えれば、従業員を大都市圏に住まわせることのビジネス面での合理性は崩壊したということだ。多くの人がニューヨークのような大都市に住みたいと思っているが、大都市に住むことは会社の成功にとって重要ではないし実際には無関係だ。ソースコードの善し悪しにどこで書かれたかは関係ない。ユーザーストーリーも、デザインモックアップも、販促資料もだ。テンペ（訳注: アリゾナ州の人口 16 万人の都市）でできることはメンロパーク（訳注: Facebook の本社があるシリコンバレーの都市）でもできる。

（ここはインターネットなのであら探しが好きな人もいるから捕捉しておくと、確かにある種の人たちは実際にビジネス上の理由で特定のエリアに住む必要があるだろう。具体的には顧客対応が必要な仕事、営業やカスタマーサクセスだ。これらの職種は希な例外としておく）

生活コストベースの報酬の理論的根拠が生活費が高い大都市に住む従業員への配慮なのだとしたら、もし雇用者が大都市の労働者を好まなくなったとしたらどうなるだろう？ 違う言い方をしてみよう。「なぜ生活費が安い場所に住んでる連中が必要以上のお金を欲しがるんだ？」という問いをひっくり返すと「なぜ会社はサンフランシスコに住んでる連中が必要なんだっけ？」になる。

生活費が高い/安い場所で、労働者がゆとりのある生活を送るために必要な報酬はいくらだろう、というのはよく議論の的になる。ただ、こういう問いの立て方は問題に対する間違ったアプローチで、どのくらいの生活費がかかる場所に住むかというのは完全に個人の問題だ。もしサンフランシスコに住んでる人が自分の収入の大半をサンフランシスコに住むために使いたいとしたら、それは結構なことだし、その人自身の選択だ。一方でもしサンマテオ（訳注: シリコンバレーの街。 YouTube の創業地）でリモートワークをしている（あるいはオフィスで働いている）人が、 リトル・ロック（訳注: アーカンソー州の人口 18 万人の街）に住んでいる同僚と全く同じ働きをしているとして、どうして一方は給料を優遇されてもう一方は減額されないといけないのだろうか？ もしリトル・ロックの従業員には子どもがいて年老いた親の面倒も見ていたとしたら？ 一方でサンマテオの従業員は独身で単身者だったとしたら？ 必要な額を考慮するとき、こういった個人の家庭の事情は考慮されないのはどうしてだろう？ つまり、生活コストによる給与の調整は、従業員はこういう風にお金を使うべきという本質的に不適切な思い込みに基づいて行われている訳だ。生活費の高い大都市に住むことは価値のある選択で、そうでない選択は価値がないと言っているに等しい。

例えば GitLab はこんな風に公言している。

もしみんなが標準的な給料を受け取ったら、所得の高いエリアに住んでる人たちは所得の低いエリアに住んでいる人たちに比べて可処分所得が少なくなってしまう。

えーっと、はい。これがポイントだ。

住む場所の選択によって発生する生活コストの違いは不可避的に、誰かにとっては補助金的なものであり、誰かにとってはペナルティのようなものなのだ。多くの人が住みたがる、生活コストの高い大都市に住む人に対して企業が高い給料を払う義理はないのだ。どこに住むかというのは、これまでもこれからも消費選択の問題に過ぎない。その選択の問題が今日、よりくっきりと明らかになったのだ。

インターネット全体で労働力の供給と需要が行われる

生活コストを報酬の決定に加味する件に関してよく言われることの一つに、労働力の需要と供給の問題がある。すなわち、市場メカニズムが地域ごとに異なる給与額を規定するので、企業はその地方の基準に従って支払うしかないのだと。 GitLab のような、完全にリモートで従業員を採用している会社がよくとるアプローチだ。彼らは報酬調整の式を公開している。

この方法の問題点は、 "労働力供給" の定義だ。オフィスへの出社を求める企業にとって、潜在的な労働力というのは会社の半径 20 マイルに住んでいる人々のことだ。しかしリモート企業では、 "インターネット全体" が潜在的な労働力だ。（もっと実務的な言い方をすると、裁判所の管轄権の及ぶ居住者全体だ。あとで詳しく述べる。）これらの観点から、フォート・ウェイン（訳注: インディアナ州の人口 25 万人の街）に住んでいる労働者にとって、彼女の住んでいる街には "競争相手" がいない（企業側からしても、労働者側からしても）。メンフィスやスポーケン、シュリーブポートあたりの人だってそうだ。企業が市場経済の仕組みによって給料を減額調整しようとするのは、本当のところ仕事ぶりとは無関係に懲罰的に給料を下げようとしているということと同じなのだ。ある従業員の地理的選好によって補助金を出すのは、組織としてビジネス的に意味のないひいきをしていると表明しているのと同じだ。

ある人はこのモデルを "底辺への競争" （訳注: 規制緩和でかえって経済全体が貧しくなること。底辺への競争 - Wikipedia）と見るだろう。僕は違う。機会の拡大だと捉えている。もしどこか別の場所により少ない給料で与えられた仕事を完璧にこなす人がいたとしたら、その人に仕事をしてもらうのが合理的だ。これは Menlo Park で働き一年で 50 万ドルを稼ぎ出す Facebook のエンジニアにとって驚異だろう。ほとんどのリモート企業が希少な才能を必要としていることを考えると、バンガー（訳注: メーン州の街）やリノ（訳注: ネバダ州の街）で仕事をしている人にとっては、幾ばくか値切られたとしてもリモートワークの報酬は充分によい、中の上レベルの給与になるだろう。

ではここで質問だ。このやり方はどこまで認められるだろう？

慎重な反論を紹介しよう。論理的に考えれば、世の中のテック系の仕事がすべてリモートワークへ移行すると、アメリカ中から条件のよい仕事はなくなってしまって、すべて外国に奪われてしまうだろう。結局のところ、ハイデラバード（訳注: インドの大都市）やキエフ（訳注: ウクライナの首都）、ラゴス（訳注: ナイジェリアの旧首都）に住んでる連中も充分に賢くて、アメリカのテック企業で必要とされる水準の働きをするだろう。文字通り 1990 年代にはソフトウェア産業でエンジニアリングの領域はオフショアの波に呑まれてしまうだろうと言われていた（ 90 年代後半にはマジで大問題だと認識されていた）。しかしそうはならなかったどころか、アメリカ国内のエンジニアや頭脳労働者の求人は拡大する一方だ。恐らくこの傾向は続くだろう。主にアメリカで使われることを想定したプロダクトを作っている会社はアメリカ人の労働者を重要視する。リモートでの雇用は国境ほどには州境を気にしない。精々法規制や税金のことくらいだ。

（政策決定の観点からすると、アメリカのリーダーたちは、高給の仕事を大規模にオフショアすることを規制すべきだ。代替案のないグローバリゼーションがいかにアメリカの労働者階級の雇用を悪化させたかという興味深い議論がある。しかしこの議論は別の投稿で行うとしよう。いまは企業レベルの話をしている。）

報酬の話になると、多くのアメリカ人がバンガロール（訳注: インドの IT 産業の中心地）に住んでいる Puja やイズミル（訳注: トルコの大都市）に住んでいる Mustafa に、パロアルト（訳注: シリコンバレーの街。スタンフォード大学やヒューレット・パッカードがある）に住んでいるプロダクトデザイナーと同額の給料を払うのは不合理だと言うだろう。僕はこういうのは自己中心的だと思うし、 Puja や Mustafa も同意しないだろう。彼らが確実に同じ価値を会社に対して提供しているのなら、同じ額の給料を支払うのが正しいはずだ。もし Puja と Mustafa が王様や女王様のような暮らしをしたとしても気にする必要はない。それでいいじゃないか。ひどく安い給料でオフショアの人々を雇うのは、本人の意思で決めることができない生まれた場所に基づいて労働者にペナルティを与えているようなもので、自分の意思で住む場所を決めた人に対して給料の調整を行うのよりももっと正当化できない。

人件費が高くなりすぎやしないかって？ さぁ、どうだろう。確かに人件費は高くなるだろう。しかし例えば GitLab は 5 億ドルも VC から調達している。従業員に公平に支払う余裕はあるはずだ。じゃあ Microsoft や IBM のような、何千人も雇っていて物価の安い国ではアメリカでの給料よりも低い給料で従業員を雇用している会社はどうだろう？ 僕には答えがわからない。ただ、正しいことは常に正しい。人は国籍によらず平等に給料を支払われるべきだ。バンガロールで雇われてる人がアメリカ人よりも給料が少なかったとしても、バンガロールの標準的な給料に比べたらずっといいじゃないか、という現実主義的な反論があるのはわかってる。審判を下せる問いではない。でもこれって公平かな？ いや、まったく公平じゃない。

Day one

企業が従業員に特定の場所に居住してもらう必要がある場合には、その土地に応じた給料を支払うことが正当化できる。でもそうでない場合には — 多くのソフトウェア開発の仕事が当てはまる — 労働市場ってのはかつてなく広がっていて深さもある。

この数ヶ月、もしくは数年でこの激震の勝者と敗者がはっきりするだろう。どういう結末になるかは誰にもわからない。しかし給料の良いテック企業で働くには西海岸か東海岸に住まなければならないという制約は崩壊し、我々の社会と産業は随分よくなるだろう。リモートワークは会社にとってもチームにとってもよい。従業員にとっても、その家族やコミュニティーにとってもよい。みんながリモートワークを好きになれるわけじゃないが、オフィスで働くのだってそうだ。（リモートがよいかオフィスがよいかについて、これまで個人の好みが問題になったことはないはずだ）

リモートワークは津波のように我々の上にのしかかったわけではない。近い将来に関していうと、いくつかの企業はリモートワークを躊躇し続けるだろう。僕はコロナ禍がリモートワークを推し進めるだろうと楽観しているが、油断はできない。僕の考えは間違っているかもしれないが、大躍進ではなくとも小さな一歩を踏み出すことになるだろう。ところで確信していることもある。僕がシリコンバレーで長期の商業ビルの賃貸契約をすることは決してないだろう。

リモートワークをしていて、地方に住んでいるからという理由で給料を少なくされたらやっぱりいい気もちはしない。同じ仕事をしているのに、自分だけコンビニの 100 円コーヒーで我慢しないといけなくて、同僚はスターバックスのコーヒーを飲んでる、という状況を想像してみて欲しい（自分にはそういう経験がある）。会社の中で所得の格差がありすぎると、ただでさえリモートワークでは同僚と雑談する機会が少なくて打ち解けにくいのに、より一層個人個人の間に壁を作ってしまって会社やチームになじむことができないと思う。日本国内では居住地による所得格差はアメリカほどには大きくないかもしれないが、コロナウイルスの影響でリモートワークが普及するにつれ、同じような問題に直面するケースが出てくるかもしれない。そのとき、リモートワーカーは決して安い給料に甘んじてはいけないと思う。

75 件ほどあった tech.portalshit.net の記事を取り込んだ。実家に住んでいた 10 年前に始めた技術ブログで、最初は Rails 製の Mephisto 、その次に Jekyll で構築した。まだ GitHub Pages の仕組みが存在する前で、自前で用意したさくら VPS に git push すると自動でビルドして記事が公開されるような仕組みを作ったりしてた。

Jekyll のデプロイ手順を改めた

だいぶ前の記事では Jekyll は Git の hook を使って公開してると書いてた。しかし記事の本数が増えてくると、 jekyll コマンドで生成した静的なファイルも Git でトラックす...

portalshit.net

職業プログラマーになろうとしてもがいてた頃にやってたブログで、いま読み返すと「頑張ってたんだな」感があっていなたい記事が多い。

インスタンス変数

一個前の記事（Rubyがエレガントだって言われるのがわかってきたような気がする | tech.portalshit.net - CakePHP, Rails, JavaScript）をcxxさん...

portalshit.net

だいぶ放置していて、いまは S3 で静的サイトとして公開していたのでそのまま放置でもよかったが、 10 年前と違って何でも一カ所にまとめて書いておきたいという気持ちが強くなって取り込むことにした。ブログはトピックを混ぜずに一つのトピックにフォーカスした方がよいと 10 年前は考えていたのだけど、最近の世の中のブログ記事の読まれ方は変わってきていて、一人の人のブログをフィードリーダーに登録して読むというより、 SNS をだら見していて流れてきた記事を適当に消費するというスタイルに変わってきているので、一つのブログに一つのテーマという書き分けは不要になったと感じる。

tech.portalshit.net を取り込んだおかげで Archive ページのグラフに占める技術記事の割合が増えた。

ちなみに取り込みは以下のようなコードを書いて SQL の INSERT 文に変換した。

require 'yaml'
require 'pathname'

files = Dir.glob(File.join(__dir__, '_posts', '*.markdown'))
files.each do |file|
  content = File.read(file)
  _, header, body = content.split('---')
  header_yml = YAML.load(header)
  title = header_yml['title']
  tags = header_yml['category']
  tags = tags.is_a?(Array) ? tags.map(&:downcase) : [tags&.downcase]
  slug = Pathname.new(file).basename.to_s.sub(/\d{4}\-\d{2}\-\d{2}\-(.+?)\.markdown/, '\1').gsub('_', '-')
  body = body.strip.gsub(/\n/, "\\n").gsub('\'', '\'\'')
  created_at = File.birthtime(file).to_s.sub(' +0900', '')
  updated_at = File.mtime(file).to_s.sub(' +0900', '')
  puts <<~EOS
    INSERT INTO entries(title, user_id, category_id, slug, markup, type, draft, body, frozen_tag_list, created_at, updated_at) VALUES('#{title}', 1, 6, '#{slug}', 'redcarpet', 'Post', 0, '#{body}', '#{tags.join(',')}', '#{created_at}', '#{updated_at}');
  EOS
end

Rechars という React のチャートライブラリを利用して、 Archive ページにカテゴリーごとに記事を集計してグラフ化する機能を作った。

Single Page Apps for GitHub Pages

recharts.org

グラフの Bar にカーソルを載せると Tooltip が表示されて、具体的な件数がわかる。

カテゴリごとに表示・非表示を切り替えることも可能。グラフ下のカテゴリー名（ Legend ）をクリックして切り替えられる。

ただし残念なことに Bar を非表示にしたときに Legend の表示を変化させるのが難しくてできていない。

仕事で使ってる Looker とか Redash であれば Legend をクリックして表示・非表示を切り替えることができ、それに連動して Legend の色をトーンダウンさせたりする機能が付属しているが、利用した Recharts にはその機能がなかった。 Bar の表示・非表示切り替えも標準サポートされていなかったので、 GitHub の Issue の情報を頼りに無理矢理実装した。

Toggle an element in chart by clicking legend · Issue #590 · recharts/recharts

I don't think set opacity is enough for toggling an element in chart. The tooltip will still show the element number and a dot will appear when mouse over the chart. reference to #329 I have to rem...

github.com

コードはこんな感じ。結構汚い Hack で、 Bar の表示・非表示を、表示用のキー文字列に空白を追加するかしないかで切り替えている。

  // クリックされたアイテムが `this.state.disabled` 配列の中にすでに存在していれば除外し、
  // 存在してなければ追加する
  selectBar(event) {
    let dataKey = event.dataKey.trim()
    if (this.state.disabled.includes(dataKey)) {
      this.setState({ disabled: this.state.disabled.filter(item => item !== dataKey) })
    } else {
      this.setState({ disabled: this.state.disabled.concat([dataKey]) })
    }
  }

  render() {
    return (
      <ResponsiveContainer height={500}>
        <BarChart
          data={this.state.data}
          margin={{
            top: 20, right: 20, left: 0, bottom: 20,
          }}
          style={{ fontSize: '14px' }}
        >
          <CartesianGrid strokeDasharray="3 3" />
          <XAxis dataKey="year" />
          <YAxis />
          <Tooltip labelStyle={{ color: '#000', fontWeight: 'bold' }} itemStyle={{ margin: '0 2px 0 4px', padding: '0' }} />
          {// Legend クリック時のコールバックに `this.selectBar` を指定する }
          <Legend onClick={this.selectBar} />
          {/*
            `this.state.categories` 配列と `this.state.disabled` 配列の内容を比較し、
            `this.state.disabled` に追加済のカテゴリーは dataKey に空白を追加することで非表示に
          */}
          {this.state.categories.map((category, index) => {
            let dataKey = this.state.disabled.includes(category) ? category + " " : category
            let color = this.colors[index % this.colors.length]
            return(<Bar key={index} dataKey={dataKey} stackId="a" fill={color} />)
          })}
        </BarChart>
      </ResponsiveContainer>
    );
  }

ずっと過去記事をどうやって効率よく見せるか（自分自身が効率よく読むか）ばかり考えている。一つ前の記事では絞り込み UI について書いた。

Archive ページの絞り込み UI をセレクトボックスに

一個前の記事のキャプチャにあるように、従来テキストリンクだった年とカテゴリーの選択をセレクトボックスにした。 git log -S したところ去年（ 2019 年）の 11 月頃に変更を行ったみ...

portalshit.net

ブログというものが生まれたとき、誰も 10 年以上にわたってインターネットに文章を書くことを考えていなかったと思う。多くの人は途中で脱落してブログを止めたり飽きてほかのところ（ Facebook や Twitter ）に移ったりしただろう。ただ、同じ場所でしぶとく書き続けている人たちもいる。自分もその一人だ。

そういう人たちにとって、過去に自分が書いた記事をどうやって閲覧するかというのは大きな問題だ。過去記事を探すのに本文込みの一覧ページをページネーションしていくのはあまりにも効率が悪すぎる。一覧でガッと見たい。

というわけで、インターネット老人にしか用のない機能かもしれないが、過去記事一覧ページの UI/UX は非常に大きなテーマだと思う。問題点と対策を整理してみた。

過去記事が溜まることの問題点は、過去記事が探しづらくなることだ。対策としては各記事に関連記事へのリンクを表示する方法と過去記事の一覧ページを用意して探しやすくすることがあると思う。

過去記事の一覧ページは以下を満たしていて欲しい。

1. 記事を一覧できること
   • 一覧性が重要なのでページネーション、本文は不要
   • 記事の作成日（公開日）順に並んでいて欲しい
2. 記事を絞り込めること
   • 年やカテゴリーで絞り込めるとよい
3. 件数がわかること
   • どの時期にどの密度でブログを書いていたかがわかるため

10 年以上続いてるブログを書いてる人たちは多かれ少なかれ同じような問題（過去記事へのアクセシビリティ）を抱えているはずで、他の人たちがどうやっているのかを調べてみた。以下は長く続いているブログの Archive ページ。

Hail2u

ながしまきょうさんのブログ。

雑多な記録

ウェブ開発に関する話題が中心でしたが、もはやそれに限らず備忘録に近いものです。

hail2u.net

ブログのトップ自体が過去記事インデックス（タイトルのみ）になってる。本文を含む記事一覧ページはない。静的に生成してあって速い。絞り込むような UI はない。

氾濫原

関連記事のアルゴリズムやデザインなどを結構パクらせてもらっている cho45 さんのブログ。

アーカイブ - 氾濫原

lowreal.net

本文込みの一覧ページとは別に年がずらっと並んでいる。記事の一覧はない。クリックすると年月ごとの記事一覧（本文込み）が表示される。記事を書いた時期を覚えておく必要がある。

Daring Fireball

Markdown の生みの親、 Apple ブロガー John Gruber のブログ。

Daring Fireball: Archive

daringfireball.net

本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトルのみ）がある。このブログの Archives ページの UI に近い。検索窓があるが、 DuckDuckGo のサイト内検索に飛ばされる。スマートフォン用の画面がなく非常に見づらい。

hitode909の日記

hitode909 さんのブログ（はてなブログ）。

記事一覧 - hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

blog.sushi.money

本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがあるが、一覧性は高くない（ページネーションが必要）。グローバルフッターに年月ごとの記事一覧へのリンクがあるほか、サイドバーにもカレンダー式のアーカイブ導線がある。「月別アーカイブ」は年をクリックすると月別のアーカイブ一覧が展開表示される。デフォルトだと今年（最新年）が展開表示されている。年・月・カテゴリーそれぞれの記事数がわかるのは便利だと思う。

Tatsuhiko Miyagawa's Blog

Blog Hacks の著者 miyagawa さんのブログ（ Medium ）。 Bulknews 時代からの過去記事がいっぱいあるはずだけど現在は 2011 年分からしか公開されていないみたいだった。

Archive | Tatsuhiko Miyagawa’s Blog

A blog about software engineering, podcasting, gadgets, and productivity.

weblog.bulknews.net

タイトルのみの記事一覧ページはなく、一覧性は高くない。本文込みの一覧ページの上部に、年ごとの絞り込み UI が表示されている。年を選択すると月ごとの絞り込みができる。はてなブログに近い。

Medium が酷いのはこのアーカイブページへの導線で、トップページには最近の記事が数件表示されるだけで、過去記事への導線はページ下部に申し訳程度に置いてあるのみ。しかも Medium というサービスの利用規約ページへのリンクと並んでいるので存在に気がつきにくい。

先日の記事（ 蟻地獄と個人ブログ - portal shit! ）では Medium はまとも陣営に分類したけど、個人のブログ内で回遊することを極力できないようにしようとしているのが伝わってくる。蟻地獄感ある。

Island Life

『ハッカーと画家』などポール・グレアム本の翻訳もされている shiro さんのブログ。

Archive/l0

Island Life

blog.practical-scheme.net

本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがある。年による絞り込みがあり、少し前のこのブログの Archives ページに近いが、 2002 年から記事があるので年のリンクが 19 個ある。 10 年後、 20 年後のことを考えると UI 上の問題が発生しそうだ。

portal shit!

最後にこのブログ。

portal shit!

森井ゴンザレス（ morygonzalez ）のブログ。 ブログを書くこと、プログラミング、インターネット、 Mac の便利なソフト、働くこと、ランニングについて書いています。

portalshit.net

本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトル、カテゴリー、日付が表示）がある。年やカテゴリーによる絞り込みができる。

考察

Hail2u 、 Daring Fireball 、 Island Life など記事のタイトル一覧が表示されるタイプが好みだ。 Medium の一覧性のなさは最悪だが、年月の絞り込み UI はおしゃれだと思った。

個人的にはこのブログの Archives ページが一番使いやすい。自分で作っているので当たり前だ。スマートフォンでの閲覧性も問題ない。記事一覧の状態で本文で絞り込めるやつがあれば完璧なので、少ししたらチャレンジしてみたい。