portal shit!

7 月 10 日に #100DaysToOffload に挑戦する宣言をしてからしばらくは調子よく記事を書けていたが、後半にだれてしまった。 11 記事以上書かなければならないところ、 9 記事しか書けなかった。

宣言後に最初に書いた記事は、昨年末のセールで買った新しい Kindle Paperwhite についての記事。ホーム画面がリッチになって目移りしてしまい本が読めなくなったというチラウラ記事だが、 Twitter で nagayama さんからリプライをもらって設定で回避できることを知った。情報を発信するところに情報が集まってくる良い例だと思った。

Kindle Paperwhite を新しいのに買い換えたが本を読まなくなってしまった

Kindle Paperwhite 初代をずっと使っていた。 7 年くらい使っていてまだまだ使えそうだったが、ページ送りが遅いのと本体容量が少なくて、新しい本を追加できなくなってきてたのでセール...

portalshit.net

一番反響があったのは、エンジニアの求人を出している会社の顔ぶれが変わってきているという記事。一昔前は受託開発をやっている会社かウェブサービスをやっている会社が雑にエンジニア（ HOW ）を募集していて、何（ WHAT ）をやるかはエンジニアを採用したあとに顧客や状況に応じて考えるという感じだった。いまのエンジニア求人は何か解決したい課題があって起業された会社（ WHAT ）がエンジニア（ HOW ）を採用しようとしている感じ。 WHAT と HOW の主客が逆転しつつあるのでは、ということをまとめて書いた。

HOW から始まったテック企業の時代が終わり WHAT から始まったテック企業の時代が来るのかもしれない

最近、エンジニアの求人の広告を見るといかにもテック企業のものが減っていると感じる。 10 年くらい前、ウェブ系のソフトウェアエンジニアの求人といえば受託をしている会社（ウェブ制作会社）か、自社で...

portalshit.net

Numbers に関しての記事は、 Vim 、 Day One 、 Notion 、 WorkFlowy 、 Journler 、Yojimbo 、 Evernote などこれまでいろんなドキュメントエディター・オーガナイザーを使ってきて実現できなかったことが Numbers を使うとできるということをまとめようとして書いたが若干不完全燃焼感があった。例として出した登山の計画がニッチすぎたかもしれない。一般的な旅行の予定を Numbers で立てる、みたいな感じで紹介すればよかったかも。そういや Numbers のテンプレートに旅行計画ありますね。 Mac ユーザーで表計算ソフト使ってる人はわざわざ MS Office 入れて Excel 使ってるかもしれないけど Numbers はもっと評価されてよい。

Numbers をデジタルスクラップブックとして使う

公共交通機関を使って登山に行くときは結構綿密に登山計画を立てる。登山口まで行けるバスはコミュニティバスのようなものが多く本数が少ないため、乗り継ぎや行程の時間管理に失敗すると登山できなくなったり...

portalshit.net

Z6 の良さについては、オペミスで吹っ飛ばした過去写真の整理をしていて改めてその良さを伝えたいと思い立ち書いてみた。 NIKON は株価が低迷しているが、 Z は本当によいのでおすすめ。撮った写真をすぐに Bluetooth でスマートフォンに転送しつつ位置情報も付与してくれる機能が特に気に入っている。ちなみに NIKON は公式には Z 6 や Z 7 という Z と 数字の間にスペースを入れた名称にしているが、ググラビリティが最悪なので正式に製品名を Z6 や Z7 （スペースなし）にした方がよいと思う。

あらためて NIKON Z6 の良さ

昨年末に今年撮った写真アドベントカレンダーに参加したときに書いた写真で振り返る 2019 年 という記事があるが、今年の 3 月に事故って S3 バケットの画像を吹っ飛ばしてしまったので記憶を辿...

portalshit.net

家の近所の長垂海浜公園の駐車場についての記事は本当にしょうもない記事という感じがあふれているが、たまにこういうのを書きたくなる。近所に住んでいる人間でないとわからない情報をインターネットに載せて社会貢献したいと思い、わざわざ夜に散歩してたときに写真を撮って回って記事化した。この手の記事は短期的にはアクセスが伸びないが後からじわじわと伸びてくる予感がある。 Garage Band でのアナログレコードの録音方法の記事 は 10 年以上前の記事だけどいまでもコンスタントにアクセスがある。

長垂海浜公園近くの駐車場（コインパーキング）情報

長垂海浜公園には無料の駐車場はありません。有料のコインパーキングを利用する必要があります。料金、駐車可能台数、停めやすさをまとめています。2023 今宿花火大会 8/3 20:00 ~今日（20...

portalshit.net

ブログは書かなくなると更新が滞ってしまうので、あまりクオリティの高いものを書こうと思わず、もっとライトな感じで更新していきたい。

なお、この記事を含めて 2020 年の記事は 40 記事なので、残り 5 ヶ月で 60 記事書かないといけない。一月あたり 12 記事は結構大変だ。

一年間で 100 記事ブログを書く、という試みがあることを知った。

100 Days To Offload

Can you publish 100 posts on your blog in a year?

100daystooffload.com

今年は 4 月から 5 月にかけてはよくブログを書いていたが、子どもの学校が再開されて、ブログを書いていた朝の時間帯に子どもの学校の身支度などをしないといけなくなって、仕事前にブログに書くということができなくなっていた。 6 月は一記事しか書けていない。これはいけないなと思ったので、 #100DaysToOffload の試みに参加してみることにする。何でもいいから Twitter に書くようなライトなことでいいのでとにかく書くべし、というやつだ。

Posts don’t need to be long-form, deep, meaningful, or even that well written. If there are spelling and grammar mistakes, or even if there’s no real point to the post, so what? What’s important is that you’re writing about the things you want to write about.

短いとか中身がないとかタイポや日本語的におかしいとか気にせず、とりあえず 2020 年に 100 記事書くことを目標に頑張ってみる。今年は 6 月までで 30 記事書いていたので、残りの半年で 70 記事書かなければいけない。今年は残り 174 日なので、だいたい 2.5 日に一記事書く計算だ。月ごとでは 11.6 記事、週ごとだと 2.8 記事だ。うーん、結構しんどそう。達成できるだろうか。

表示していた Google Adsense の広告を外した。自動広告をオンにすると本文の途中など意図しないところに広告が掲載されまくってしまって大分読みづらい。かといって記事下に入れる程度だとまったくクリックされなくて貼ってる意味がなかった。加えて、ここ一年間で数度行われた Google のコアアルゴリズムアップデートで検索流入が 1/3 くらいになってしまって PV が激減してしまった。 Google としてはどこの馬の骨とも付かない個人がやってる泡沫ブログにトラフィックを流してインターネットの果実を分け与えるつもりはないのだろう。 Adsense 広告の読み込みでサイトの読み込み速度も少し遅くなっていたし大分すっきりした。

消した理由で一番大きいのはアルゴリズムやリターゲティングによる広告のむなしさだ。 Amazon アフィリエイトなど自分の意思でレビューしたり紹介したアイテムの広告ではない広告が自分のブログに表示される必然性はない。アルゴリズムやリターゲティングによる広告は、掲載される場所はどこでもよくて、たまたま空いてたから表示されました、というような間に合わせ感がある。自分が楽天で見た商品の広告が自分のブログに延々表示される様を見て、こういう広告を表示し続けることで自分のブログの価値が毀損されているような気がしてきた。一つ前の翻訳記事がバズって結構アクセスがあったが、翻訳元のブログには広告が表示されていないのに翻訳した自分のブログには広告が表示されていて、自分が広告を入れていることで元の記事の価値も下げているような罪悪感もあった。

元からブログで儲けようとは思っていなかったが、ブログを書くことで得られる一番の利益というか目的は、広告によって小銭を稼ぐことではなく、ブログを書くことで自分自身の価値を高めることだと思う。ブログによってインターネット上でのプレゼンスを高めて知名度を獲得したり、ブログを書いたり運用したりすることで技術的な知見を得てスキルアップにつなげられる。それらを自分の給料に上乗せできるような仕組みを作っていくことが大切なのかなと思った

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

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

だいぶ放置していて、いまは 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

Archive ページにこだわってしまう理由、グラフを表示させてみて（ブログ過去記事をカテゴリーごとに集計してグラフ化 - portal shit!）何となくわかった気がする。過去記事ページというのはブログの書き手にとってはアクティビティダッシュボードなのだ。ジョギング系アプリ使ってる人なら記録をあとから振り返ることがあると思う。それと同じで、自分が過去にどのくらいの頻度、密度でブログを書いていたかを自分は知りたいと思うのだろう。その用途に適しているのが過去記事ページというわけで、 Archive ページの使い勝手の改善は自分のブログアクティビティをふり返りやすくしたいという欲求の表れだったのだと思う。

ちなみにグラフを作ってみたことで、 2006 年頃に異常な数の記事を書いていたことがわかったし、かなり内容のない記事（新聞やテレビを見た感想）ばかり書いていたことがわかって興味深かった。 2007 年からは記事の数が減るが、これは Twitter を使い始めたからだと思う。2009 年頃、病気療養を終えて就職しようとしているあたりからプログラミング関係の記事の数が増え、実家を出て福岡のブラック企業に勤め始めてからは記事数が減った。

あまり ASP 型のブログを使ったことがないのでよく分からないが、こういうカテゴリーごとの Chart 機能はないような気がする。一時期、ダイエット日記を書いていたはてなブログにはアクセス解析機能とアクセス数の統計機能はあったが、自分のブログアクティビティを振り返る機能はないと思う（ PRO になればあるのかもしれない）。

自己満足的なブログの書き手にとっては、どれだけ読まれたかももちろん気になるけど、どれだけ書いたかも重要なのではないかと思う。読まれたかというのは結果であり、書いたかというのはプロセスというか、自分の頑張りだ。仕事をする上では結果にフォーカスにしなければ意味がないけど（使われない機能を作ってリリースするのは自己満足）、ブログは趣味なのだからプロセスの部分（自分の頑張り）が可視化される仕組みがあってもよいと思う。

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

ブログというものが生まれたとき、誰も 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 年分からしか公開されていないみたいだった。

タイトルのみの記事一覧ページはなく、一覧性は高くない。本文込みの一覧ページの上部に、年ごとの絞り込み 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!

最後にこのブログ。

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

考察

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

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

多分自分しか見てなくて月間の PV も 10 しかない Archives ページで、これまで年を選択していない場合は直近一年間の記事だけを表示するようにしていたのを全期間表示するようにした。このブログは 1300 記事くらいあって、全部一気に取得するとそれなりにレスポンスが遅くなる（ 2 秒弱かかる）。待ってる時間が少々長くなるのでローディングスピナーを表示するようにしてみた。

結構いい感じで気に入っている。使ったのは以下。色の変更なども簡単だった。

GitHub - davidhu2000/react-spinners: A collection of loading spinner components for react

A collection of loading spinner components for react - davidhu2000/react-spinners

github.com

React Spinners

A collection of react loading spinners

www.davidhu.io

全期間の記事が表示されるとカテゴリーごとに絞り込んだときにそのカテゴリーで通算何件くらい記事を書いているのかが確認しやすくなってとてもよい。完全に自己満足のサイト改善。