portal shit!

2020 年、時系列でふりかえるとこんな感じだった。

できたこと

今年できたこと
1. 一切れ 3000 円のステーキ肉を焼く
2. ハンモック入門
3. 山で肉まんや焼売を食べる
4. 車を買い換える
5. Rebuild サポーター登録
6. ハワイ旅行
7. ブログの刷新（ ActiveRecord 化、グラフ表示）
8. ジョギング再開
9. 脊振山・金山縦走
10. 友だち（ taketin さん）とキャンプ

— morygonzalez (@morygonzalez) December 27, 2020

ハワイ旅行

ハワイで最近の SUV に乗って Car Play に感動した。車の買い換えを検討するきっかけになった。ハワイ楽しかったのでまた行きたい。

金がないのでマイル乞食をして特典航空券でハワイ旅行に行った

貧乏でも細切れの工夫でマイルを貯め、家族三人分の特典航空券でハワイへ行った体験を綴る。特典航空券は人気路線で取りにくく355日前予約や会員ランクの不利さに苦労した話、ハワイ島とオアフ島でのレンタ...

portalshit.net

ブログの ActiveRecord 化

脱 DataMapper できた。

Lokka の ActiveRecord 化と 2020 年に Ruby で CMS を作ることの考察

7 年間眠っていたブランチを起こして、 Lokka の ActiveRecord 化に取り組み始めた。元のブランチは hrysd さんが取り組んでいたやつだ。 ...

portalshit.net

ブログ UI 刷新

トップページの見た目、アーカイブページにグラフを表示するようにした。ブログ記事を書いてきた実績が可視化されるとやる気が出る。

ブログ過去記事をカテゴリーごとに集計してグラフ化

Rechartsを使ってアーカイブページにカテゴリ別の記事数を棒グラフで表示する機能を作成。Tooltipで件数確認、Legendクリックで表示切替を実装したが、非表示時にLegendの色をトー...

portalshit.net

ウッドデッキの塗り替え

サンドペーパーをかけて塗り直した。

庭で焼き鳥

バーベキューに飽きて焼き鳥おじさんになった。

ハンモック入門

ウキグモ Light ＆ ウンカイ Light 購入。

自粛生活でハンモックハイキング欲が高まり色々買った

自粛期間中にGRiPSのブログを見てハンモックハイキングとウルトラライト装備に傾倒。AXESQUINのハンモックやアルコールストーブ、ウッドストーブなどを購入し、テント不要で軽量化できる点や燃料...

portalshit.net

UL クッカー購入

アルコールストーブ、チタンカップ、メスティン、アルミフライパンなどなど。

山で肉まん・焼売・炊飯

カップラーメンとおにぎりからの卒業。メスティンでの炊飯はめちゃ美味くて感動する。

山で焼売

EvernewのTi570チタンカップと蒸し皿、BelmontのBM-076蓋を買って山で焼売を蒸した。風で蓋が飛ばされトレッキングポールと粘着で回収する羽目になったが、チタン製は軽く扱いに注意...

portalshit.net

車の買い換え

スバルインプレッサから Jeep Compass へ。ハワイ旅行でアメ車の SUV に乗って車に対する考え方が変わり、車を買い換えたくなった。国産車はディーラーとの交渉がわずらわしすぎて値引き交渉やオプションがほとんどない外車になってしまった。アメ車はアホみたいにガソリン喰って笑える。プラスチック部品の質が悪い（ゴルフ 2 を思い出す）。

インプレッサを手放した

7 年前に買ったスバルのインプレッサを手放した。試乗車落ちの車で買ったとき 5000km くらい走行していた。それから 7 年ちょい所有して 68000km くらい乗った。手放したときの走行距離...

portalshit.net

ソロで脊振山・金山を縦走

2 年ぶりのソロ縦走。盛夏にソロで 20km 歩いてつら寂し楽しかった。

脊振山・金山縦走

脊振山から金山まで約21kmを日帰り縦走。暑さと疲労でコーラを何本も飲み、途中で座り込む場面もあった。稜線歩きは快適だが笹藪や痩せ尾根に要注意。下山ルート選択でバスに間に合わず長距離舗装路歩きが...

portalshit.net

腕時計の買い替え

Pebble Time Round から Apple Watch へ。

Pebble から Apple Watch に買い替えて生活が便利になった

Pebble Time Round が充電不良で寿命を迎え、こっそり Apple Watch に買い換えた経緯を説明。Apple Watch による通知の賢さ、Macや1Passwordのロック...

portalshit.net

朝駆け登山

明け方前に出発して日の出を山頂で見るというやつをやった。

友だちとキャンプ

家族以外とのキャンプは初めてだった。複数の男手がある状態でのキャンプは楽だった（力仕事を分散）。食事は taketin さんが作ってくれて超楽だった。

秋の志高湖キャンプ

志高湖で元同僚父子とキャンプ。taketinが高級グリルでピザやビールを振る舞い、自分はインスタント中心の気楽な食事で楽しむ。ハンモック禁止で急遽テント泊になったがよく眠れ、朝は湖や山の写真を撮...

portalshit.net

ジョギング再開

年末から走るようになった。Apple Watch でリング閉じたい病にかかった。走るときに聞くのは Podcast よりも音楽の方が良い（ Podcast だと気が散る）。

一切れ 3000 円の肉を焼く

肉屋で ¥880/100g のリブロースを厚さ 3cm でカットしてもらった。良い肉を低温調理すると柔らかくなりすぎてブヨブヨになった。和牛は普通に焼いてうまくなるように育てられてるのかも知れない。

Rebuild サポーターに登録

RAW エピソードと Extra エピソードが聞けて全文検索できるようになった。全文検索できると N さんが昔言ってたあの話をもう一回聞きたいというときに便利。サポーター向けの機能差別はもうちょいあってもよいのではと思ったけど（ Rebuild を聞くに際してお金払わなくても困ることがない）、実利を得るためというより支援のためにみんな入っているのかな。

できなかったこと

今年できなかったこと
1. Lokka の ActiveRecord 対応を master に merge する
2. iOS / Mac のプログラミングを勉強する
3. Rust を勉強する
4. ブログを 100 記事書く（ 100DaysToOffload ）
5. 体重を維持する（太ってしまった）
6. 英会話の勉強
7. ソロでハンモック泊する
8. 阿蘇高岳に登る

— morygonzalez (@morygonzalez) December 27, 2020

こっちは箇条書きで。

• Lokka の ActiveRecord 化を master に merge
  • あと一歩のところで燃え尽きてしまった
• iOS / Mac のプログラミング
  • 毎年やりたいと思ってやれない
  • Xcode がでかすぎる＆重すぎる
• Rust の勉強
  • ちょびっとやってたけど難しくて途中でやめてしまった
• 英会話の勉強
  • 会社の制度でレアジョブを始めたけどなかなか時間を捻出できない
  • 休みには休みたくなってしまう
• ブログを 100 記事書く
  • 11 月に重めの翻訳記事を書いて燃え尽きてしまった
• 庭の屏の塗り替え
  • ウッドデッキの流れで塗り替えたかったが梅雨入りして夏が来て冬になってしまった
• 体重の維持
  • 前回リモートワークをしていたとき（ Kaizen Platform 時代）はリモートワークしながら減量できたのに今回は太ってしまった
• ソロでハンモック泊
  • ハンモックを買ったはいいが、ソロで山に泊まりに行けていない
• 高い山に登る
  • 今年は標高 1500m 以上の山（ハワイーの Pu'u Kalepeamoa は除く）に登っていない
  • 火山規制が解除されたので阿蘇高岳に登りに行きたかったが、休日にソロでの外出はなかなか難しい
  • 年に一回は久住か祖母山、九州脊梁の山（標高 1700m 程度）に登りたい
• 仕事でめざましい成果を残す
  • いつも通り

いつものようにあまりパッとしない一年だった。

インデックスページをいじって各カテゴリーの最新記事 4 件を配置するようにしてみた。最近の個人サイト復興ブームでみなさんインデックスページを工夫されているのを見ていて真似したくなってやった。

昔ながらのブログだとインデックスページというのは最新の記事 10 件くらいが表示されていて、「次へ」を押すと古い記事が出てくるという構成になっている。以前のこのブログもそうだった。

しかし自分自身が他人のブログで「次へ」を押して次々に記事を読んでいくということをやった記憶がほとんどない。自分のブログでだって何か目的があって特定のキーワードで検索したあとに引っかかった記事を読むという感じなので、時系列に本文とセットで記事が 10 件ずつ表示される UI というのは意味をなしていないと思った。そもそもインデックスという名称なのに最近の記事数件しか表示していないのはおかしい。インデックスというからにはすべての記事の目次になるべきだ。

このブログはカテゴリーがあるので、サイトマップを作るとするとこんな感じになると思う。

+----------+        +------------+        +-----------+
|          |        |            |        |           |
|   Blog   +---+--->+  Category  +------->+   Entry   |
|          |   |    |            |        |           |
+----------+   |    +------------+        +-----------+
               |
               |
               |    +------------+        +-----------+
               |    |            |        |           |
               +--->+  Category  +---+--->+   Entry   |
                    |            |   |    |           |
                    +------------+   |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                     |    |           |
                                     |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                          |           |
                                          +-----------+

第一階層がインデックスページで、第二階層がカテゴリートップ、そして各記事がある。なのでインデックスページは二階層目の一覧ページになっているのが望ましいはずだ。しかし伝統的なブログはカテゴリーという記事をまとめる概念がありつつも、インデックスページから各記事ページへ直接遷移するのが主な導線だった。常に最新の記事が時系列順に並んでいるだけでは味気ないし、常連の読者ではないコンテキストを知らない訪問者には不親切だろう。

しかも SNS の隆盛で個人のブログのインデックスページが参照される機会というのはとんとなくなってしまった。個人が書いたブログ記事は SNS 経由で読まれ、個別記事だけが読まれる。インデックスページやトップページが読まれることはほとんどない。 SNS でシェアされている URL をクリックして個別記事を読んで、それ以上そのブログのほかの記事を読むことなく離脱してしまう。前後のコンテキストは無視して、一つのコンテンツだけがつまみ食いされてしまう。そんな流れにあらがいたいと思った。

これまで関連記事を記事下に表示するなどやってきたが、気に入っていくつか記事を読んで「ホーム」（ = インデックスページ）を訪れたユーザーがもう少しブログを深掘りしてみたくなるようにインデックスページを各カテゴリーの最新記事一覧とするようにしてみた。このブログは現在カテゴリーが 13 個あるので、それぞれから 4 件ずつ記事を取得すると 52 記事になる。全カテゴリーからまんべんなく 4 記事ずつ取得して表示するのは簡単なようで結構難しい。普通の SQL ではできない。 OR マッパーではまず無理だろう。

いろいろ調べてみた結果、 MySQL では GROUP_CONCAT というのが使えそうだった。以下のような SQL を書いた。

select entries.id
from entries
inner join (
  select
    category_id,
    GROUP_CONCAT(id order by created_at desc) as entry_ids,
    max(created_at) as last_created_at
  from entries
  where entries.draft = false
  group by category_id
) as grouped_entries
on grouped_entries.category_id = entries.category_id
and FIND_IN_SET(id, entry_ids) between 1 and 4
order by last_created_at desc, entries.id desc;

GROUP_CONCAT と FIND_IN_SET という関数を組み合わせることで、各カテゴリーから作成日の降順に記事を 4 件ずつ取得できた。このクエリでは記事 id のみ取得して、もう一回 DB に記事を取得するクエリを ActiveRecord で投げる。 ActiveRecord でクエリを組み立てるときは N+1 が起こらないように関連テーブルを JOIN する。

query = <<~SQL
  select entries.id
  from entries
  inner join (
    select
      category_id,
      group_concat(id order by created_at desc) as entry_ids,
      max(created_at) as last_created_at
    from entries
    where entries.draft = false
    group by category_id
  ) as grouped_entries
    on grouped_entries.category_id = entries.category_id
    and find_in_set(id, entry_ids) between 1 and 4
  inner join categories on categories.id = entries.category_id
  order by last_created_at desc, entries.id desc;
SQL
entry_ids = ActiveRecord::Base.connection.select_all(query).rows.flatten
entries = Entry.includes(:category, :user, :tags, :comments).where(id: entry_ids)

PostgreSQL のときに最初に取得した entry_ids の並び順通りに結果が受け取れるかは怪しいが、 MySQL の場合は一回目のクエリで取得した id 順に各レコードが ActiveRecord のクエリ結果として取得できた。あとはこれをカテゴリーごとにグルーピングして View でよろしくやれば良い。

なお各カテゴリーはカテゴリー内の最新の記事の作成日で降順ソートするようにしている。例えば現在のインデックスページの最下部には音楽カテゴリーがあるが、これは音楽についての記事を最後に書いたのが一年以上前だからだ。もしいま音楽の記事を書けば音楽カテゴリーがトップに浮上するようになっている。

見た目に関しては各カテゴリーの記事最新一件は大きなサイズで表示している。最も最近書かれた記事なのでより多く人の目に付いた方がよいだろうという考えだ。またすべての記事にサムネイルというか、アイキャッチ画像を表示するようにした。画像がない記事に関してはデフォルトのサイトアイコン画像を表示するようにしている。やっぱり視覚的に情報を捉えられるのは重要だ。画像がごちゃごちゃ表示されるのを嫌う人もいるかもしれないが、テキストだけでは人間の認知というのはどうしても追いつかない。

あわせて今回、インデックスページの冒頭部にこのサイトについての説明文を載せることにした。ながしまきょうさんや r7kamura さんがやっているののパクりだ。伝統的なブログのインデックスページは初めて訪れた人のことを無視しすぎていたと思う。そのブログ自体について説明するページがあるブログは少ない。最初の記事でブログを始めた経緯みたいなことが書かれたきり、そのブログは何なのか、誰が書いているのかが書かれることは希だ。きちんとブログについての説明ページと著者についての説明ページがあっても、左右のサイドバーやトップのナビゲーションの端っこに押し込まれて見られることはない。これではいけないだろう。というわけでインデックスページの一番目立つ位置にブログと自分自身の簡単な紹介を入れた。

ブログはなぜ衰退したかを考えてみると、 Facebook や Twitter の隆盛はあるにせよ、ブログ自体に初めて訪れた人に読まれるための工夫が欠けていたのだと思う。誰も自分のブログの継続率を計測したりコホート分析したりはしない。読者が前後の記事を読んでいることを前提に書かれた記事やサイト構成では初めて訪れた人はどうやっても離脱してしまう。特に書き手が芸能人でもない一般人の場合はなおさらだ。誰も RSS フィードを購読していないし、ほとんどの読者は初めて訪れる人なのだから、そういう人たちが読んでブログのテーマや著者の人となりが分かる構成にしていかなければならないのだと思う。でないと SNS でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

この新しいインデックスページが正解なのかどうかは分からないが、ブログ衰退の流れにあらがっていきたい。

去年の春からキャンプするようになった。何度かキャンプをしに行くうちに、キャンプというのは思ったほど気軽に行けるものではなくてかなり段取りが必要なアクティビティであることが分かってきた。

キャンプ道具沼問題

まずはお金がかかる。テントなど一式道具を揃えればその後はお金がかからないと思っていたけどそんなことはなさそうだ。ホテルや旅館に泊まる旅行だと一回の旅行で最低でも 2 万円くらいは宿泊代がかかってしまう。キャンプなら精々キャンプ場に払うお金くらいだから気軽に行けるに違いないと思っていたが、全然そんなことはない。確かにキャンプ場に払うお金は高くても 5000 円程度だが、キャンプに行くと周りの人たちのキャンプ道具の充実ぶりに圧倒されて、キャンプに行くたびに道具を買い足してしまい、結局ホテルや旅館に泊まるのと変わらないくらいの出費になってしまう。いわゆる沼というやつで、これはいくら道具を買ってもキリがないのだと思う。道具が増えれば車が手狭になり、車にルーフキャリアーを付けたり、物置が手狭になって物置の増設、最終的には大きな車への買い換えなどで底なし沼的に出費が膨らんでいく。キャンプなら宿泊費を安く抑えて遠出ができると思っているとしたら多分それは大間違いで、キャンプに手を出したが最後、その後は後戻りができないキャンプ道具沼で死ぬまでキャンプの呪縛から解放されることはなくなってしまうだろう。

キャンプ場混みすぎ問題

次にキャンプ場混みすぎ問題だ。ホテルや旅館に泊まる旅行だと事前に宿の予約をしないといけないのが面倒で思い立った日にいきなり旅行に出かけることは難しい。いまは便利な世の中なのでインターネットでポチポチとやれば当日中にその日の宿を見つけることは不可能ではないが、当日だと高かったり宿を見つける作業が大変でわずらわしかったりする。キャンプならば宿の予約のような面倒な作業から解放されて思い立ったが吉日的におもむろに出かけてテントを張り、豪快に野外飯を作って適当に寝て、翌日はチェックアウトの時間など気にすることなく目が覚めた時間に起きて適当に帰ればいい、実に気楽に泊まりがけの遠出ができるはず、と思っている人がいるかもしれない。実は全然そんなことなくて、キャンプ場も大抵予約しないといけなくて、いきなり行って利用できるキャンプ場というのは非常に限られている。というかほとんどない。そもそもキャンプ場の予約システムは IT 化されておらず、ウェブサイトから予約申し込みをすることができない。電話で予約というところが圧倒的だが、電話で予約が完結するならまだマシな方で、酷いところだと電話後に FAX や文書のやりとりが発生したり、最も面倒なところだと事前の打ち合わせで実際にキャンプ場に訪れる必要があるところもある。なぜこういうことになるかというと、キャンプ場をやっているのは大きな会社ではなく個人か自治体だからだ。

個人経営キャンプ場

そもそもキャンプ場の利用料というのは高くはない。テント一張り 1000 円くらいのところから、高いところでも 5000 円くらいだ。 30 区画あったとして、週末にすべて予約が入ったとしても ¥5000 × 30 区画 = ¥150000 の売上だ。毎日 15 万円の売上があるわけではなく、キャンプ場は土曜日しか混まず平日は基本的にほとんど利用者がいないと考えられ、平日の収益はほとんどゼロなはずだ。加えて毎週末満員になるわけではなく、週末に天気が悪ければお客さんは来ない。しかも雨天のキャンセルの場合はキャンセル料を取らないキャンプ場が多いので、週末雨が降らなかったとして月の収益は 15 万円 × 週末 4 回 = 60 万円くらいとなる。この規模の個人経営のキャンプ場が予約システムの構築にお金をかける余裕はないだろう。家族経営でキャンプ場の維持管理をするだけでいっぱいいっぱいだろう。

自治体運営キャンプ場

意外かもしれないが、キャンプ場は自治体が運営しているものが多い。子どもの頃に子供会や学校の行事で訪れたキャンプ場は大抵自治体運営のやつだ。こういう自治体運営のキャンプ場も IT 化されておらず、平日 9 時から 5 時までの間に自治体の施設管理課か、自治体が運営を委託しているシルバー人材センター的なところに電話して空き状況を確認する必要がある。電話で予約が完結すればラッキーな方で、その後さらに書面での申込みや一度往訪しての打ち合わせが必要だったりする。なぜそうなっているかというと自治体の条例で決まってるからだ。何とか町施設利用条例みたいなやつがあって、利用者は利用したい日の 30 日前までに書面で申し込み、一度利用内容を説明して役場の承認を得ること云々、みたいなやつだ。こういう条例的なやつが足かせになってウェブで申込み完結、みたいな状況にはならないのだろう。それでも自治体運営キャンプ場は無料かお金がかかっても信じられないくらいに安いので利用者が殺到するから、ウェブ化して利用者の使い勝手を改善しようということにはならないし、役所の担当の人は日々申込み者からかかってくる電話や送られてくる書類の対応に労力を割かなければならない。

全然予約できない

キャンプ場は利用料が安いこと、土日に需要が集中すること、キャンプは雨が降ると中止せざるを得ないこと、予約システムがウェブ化されていないことによって、予約はすさまじいほどに面倒くさい作業になっている。利用料が安いのでみんなとりあえず何ヶ月も前から週末の予約を野放図に入れる。すると「今週末は天気がよさそうなのでキャンプでも行こうかな」というくらいののろまがキャンプ場に問い合わせたときにはどこも埋まっていて「おととい来やがれ」的な対応を受けることになる。全然気軽に行けるものではないのだ。むしろ金さえ払えば確実に泊まれるホテルや旅館を利用する旅行の方が手軽だ。

結論 キャンプに行くためには金と時間が必要

というわけで、キャンプは全然手軽ではないし、旅館やホテルに泊まる旅行に比べてお金を節約できたり自由気ままに行えるアクティビティではないということをわかってもらえたらと思う。天候やキャンプ場の予約の難易度も加味すると、キャンプはできて年に 2, 3 回なのではという気がする。 10 回も 20 回もキャンプに行ける人はお金もキャンプ場探しをする時間もある人だけだ。マイルを貯めて毎年特典航空券@ビジネスクラスでハワイに行くような人種こそがキャンプを趣味にしていそうだ。

blog.8-p.info の過去記事ページの真似をして、 Archive ページにタグを表示するようにしてみた。

タグはあまり使っていなかったのだけど、一覧で記事タイトルだけ並んだときその記事にどんな内容が書いてあるのかを把握するためにはタグが便利だなと思い直し、タグを表示させてみることにした。いくつか過去のタグが付いていない記事にタグを振ってもみた。

このブログは技術情報からポエム、日々の日記まで何でもありのごった煮ブログなので、カテゴリーによる情報分類には限界がある。現在 13 個のカテゴリーがあるが、記事数にバラツキがあり、情報分類としてあまり機能していない。カテゴリーの粒度をもっと荒くして緩い分類に変更し、そこから先はタグによって超細かくラベリングすると情報の分類としてはまともになるのではないかと思った。

いま、カテゴリーの内訳がこんな感じ。

- "雑談":303
- "技術/プログラミング":272
- "映画/ドラマ/テレビ":150
- "Mac/iPhone":134
- "WWW":113
- "散財":95
- "旅行/ハイキング":70
- "ブログ":69
- "音楽":63
- "読書":34
- "写真":32
- "料理/食事":31
- "労働":27

もっと緩い分類にして以下みたいな感じにするとよさそう。

- 雑記
- パソコン・インターネット
- 見た・読んだ・聞いた
- 出かけた・撮った・食べた

カテゴリーとタグの使い分けは 10 年以上前から悩んでいる気がする。

タグはいっぱい付けないとダメですね

現在流行しているタグによる情報の分類は、とても中途半端で使い勝手が悪い。これまでのカテゴリ分類の代用として、もしくはタグクラウドを表示して自己満足に浸る以外には、あまり役に立たない。それはこのタ...

portalshit.net

情報分類の手法でありつつコンテンツの内容そのものを指し示すものでもあるからだろう。インスタグラムで #ラーメン #からの #うどん とかやってる投稿を見るととても嫌な気持ちになるのだけど、そういうことがされるくらいにタグというものは不安定なもので、正しく使おうとか気負わず、もっと緩く使えばいいのかもしれない。

もう廃れてしまったが、フォークソノミーが勢いを取り戻して、情報の発信者ではなく受け取り側がコンテンツにタグ付けできるような世の中になるとおもしろいのかもしれない。

フォークソノミー - Wikipedia

ja.wikipedia.org

secondlife さんがはてなブログの記事などを引き払って新しいドメインで個人ブログを作ってた。

心のざわめきを無くして日記を書くということ / secon.dev への移転 - A Day in the Life

このブログや、2nd lifeの記事、また無くなってしまったはてなグループ SubTech に書いていた記事をsecon.dev ドメインに移転した。あわせて、ブログシステムを、はてなブログから静的ジェネレータのによる生成に切り替えた。心のざわめきをなくして日記を書くということ日...

secon.dev

secondlife さんは今年の春まで世界一周旅行をしていて、ブログで旅行の様子を書いていたが、数ヶ月前に Google Photos が突如過去に Ticker API で取得した写真の URL を無効化して折角の旅行の写真が閲覧不能になるということが起こっていた。

【今月二度目】 Google Picker API がら取得した Google Photos の画像が利用できない、ヤァ!ヤァ!ヤァ! - A Day in the Life

これは日記に画像を貼り付けできない、悲しみのポエムである。一度目は3月10日(JST)あたりから発生していて、Picker API で取得した画像が数分後には403になる。3月13日ごろ直ったが、発行されるサムネイルのURLが仕様が変わったのか、めちゃ長くなった。二度目は3月25...

secon.dev

同じ現象は cho45 さんもブログに書いている。

Google Photos が発狂してから - 氾濫原

lowreal.net

結局お二方とも Google Photos の利用をやめてしまったようだ。

Google Photos 依存からの脱却 | tech - 氾濫原

lowreal.net

Google Photos の画像をダウンロードして、ブログの画像を別の画像に差し替える - A Day in the Life

Google Photos は様々な Web サイトから Google Photos にアップロードした写真を貼り付けできるjpgをママ貼り付けでき、サムネイルサイズも自由なサイズを選べ、Google の高速なサーバ経由で配信され、しかもアップロードしたオリジナルファイルもダウン...

secon.dev

ブログサービスやストレージサービスを使うと楽だが、サービス提供者の胸三寸で機能が利用できなくなってしまうことがある。

secondlife さんの冒頭の記事は「心のざわめき」についてがメインのテーマだ。記事を書く度にはてなブックマークでのリアクションを気にしてしまってよくないので、それらのリアクションから遠い場所に移転する、という趣旨だ。

プラットフォームが提供するサービスは便利だったりコンテンツを生産するモチベーションを与えてくれたりする反面、プラットフォームへの依存度が高まったり、ときにはプラットフォームがもたらすネットワーク効果が負の副作用をもたらしたりする。そういうのに疲れた人は自前でウェブサイトを運用するようになる。

ながしまきょうさんはもっと早くにプラットフォーム依存を脱却しようとしていて、一時は Twitter さえもやめて自サイトで Microblogging していた。

個人ウェブサイトへ

hail2u.net

自分はプラットフォームに依存せずにこれまでブログをやってきた。一時期画像のアップロード先に Flickr や Google Photos を使うことを試したけど、最近の記事ではやめていて完全に自前だ。さくらインターネットや AWS といったインフラ部分では IaaS に依存しているが、オペレーションの部分は自分で行っている。ソフトウェアエンジニアとして腕を磨くのが目的だったけど、だんだんとプラットフォームの足かせから自由でありたいという理由が大きくなってきている。

プラットフォームの中でブログを書くと、自分の書いたものがプラットフォームの中の一コンテンツでしかなくなってしまう。自分のブログなのにどこかの知らない人が書いた記事が「関連記事」として表示されてしまう。自分はそういう場所には違和感がある。

インターネットの端っこにいる人たちから「ウェブ縄文時代」に退行していくのではないかと思う。

CGMサービスの矜持について - 氾濫原

lowreal.net

7 年前に買ったスバルのインプレッサを手放した。試乗車落ちの車で買ったとき 5000km くらい走行していた。それから 7 年ちょい所有して 68000km くらい乗った。手放したときの走行距離は 73000km 弱だった。いい車だった。特に車検や修理などで他のメーカー製の代車に乗るときにその良さが身にしみた。重くもなく軽くもないハンドル、急にかかりすぎないブレーキ、高すぎず低すぎずちょうど良い運転時の視点、大きくもなく小さくもないボディサイズなどなど。以前乗っていたゴルフ 2 に近い感覚で乗ることができて好きだった。

乗ろうと思えばまだまだ乗れたが、もろもろ事情があって手放すことにした。

6 月下旬に手放すことにして近所の中古車屋に査定を頼んだが、車が古すぎて値段が付かないと言われてしまった。そもそも 3 月からのコロナ危機の影響で中古車相場が激変し、買い取り相場が大きく下落していたらしい。しかし転機があって、 7 月に九州で豪雨があったことで車がたくさん流されて廃車になり、中古車への需要が高まっているようだった。改めてネットで一括見積もりを申し込んでみたところ二社から連絡があり、家まで査定に来てもらった。最初は 5 万と提示されたが、二社で競り合ってもらって最終的には 13 万 5 千円まで提示額を上げることができた。

なお、中古車買い取り業者は不動産屋のように腹黒いというか何を考えているかわからないので、素人は簡単にだまされてしまうと思う。よく中古車の売却についてのブログ記事などで一括査定を頼むべしと書いてあるが（アフィリエイトリンクが仕込まれているのであまり信じてなかった）、本当にその通りだと思った。さらには同時に家まで来てもらって競り合ってもらうのがよいと思う。一対一の交渉だと「他社と交渉せず今すぐ決めてくれることを条件にこの値段を提示します」的なことを必ず言われる。絶対に一社だけとの交渉でハンコをついてはいけないと思う。

ちなみにインプレッサを売却する際に中古相場を調べていて、ついでにゴルフ 2 でも検索してみた。そしたらなんと 200 万円近い価格の車両がゴロゴロ…。自分がゴルフ 2 GTI を手放したときはゼロ円査定で廃車にされるということでただで引き取ってもらった。ゴルフ 2 にはぶつけていたところがあったし、アンダーカバーがないせいで雨が降るとエアコンベルトが鳴く問題があったり、運転席側のパワーウィンドウが怪しかったりしたが、エンジンや機関系には全く問題がなく、走行距離も 80000km 程度で当時生き残ってるゴルフ 2 GTI としてはかなり良い状態だったと思う。ゴルフ 2 を買った頃は熊本で運転していてたまにゴルフ 2 同士ですれ違うことがあったが、いまではほとんど姿を見かけなくなった。 5 年前のヨーロッパ旅行でもギリシャで一度とクロアチアで一度見ただけだった。出回る玉が減って売り手市場になっているのだと思う。

「もしあのとき手放さずに今も所有していれば…」とちょっと後悔したが、 10 年間のゴルフ 2 の維持費は自動車税と車検を通すだけでも 100 万円を超えただろうし、人生そんなもんだよなという気がしてしまった。自動車という財は個人が所有していることになってはいるが、結局は借りているのと同じような状況だと思う。ローンの他に税金や保険料を払う必要があり、払えなくなると手放さざるを得なくなる。一般的な商品と異なり、一度買えば維持費がかからず半永久的に所有できるタイプのものではない。クラシックカーの値段にはその辺の税金苦行に耐えたことの対価も含まれているのかもしれない

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

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

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

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

portalshit.net

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

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

最近のエンジニア求人は、従来のウェブ系企業から、インターネットを使って既存の市場を効率化するビジネスモデルにシフトしている。2000年代のITベンチャーはテクノロジーが中心だったが、現在は対象市...

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 年以上前の記事だけどいまでもコンスタントにアクセスがある。

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

長垂海浜公園周辺に無料駐車場なし、近年コインパーキングが増えて車で行きやすくなった。公園近くと今宿駅前の計5〜6カ所を比較し、料金、台数、出し入れのしやすさを詳述。医院提携駐車場は平日昼に最大料...

portalshit.net

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

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