| @Mac/iPhone

"Your Computer Isn't Yours" という記事が先週バズってた。

sneak.berlin

概略を説明すると、 Catalina の頃から Apple が Mac ユーザーのアプリ起動ログを勝手に収集していたが、 Big Sur の公開日にログ集約サーバーがダウンしてしまい、そのせいで Mac を使えなくなる人が続出して問題が発覚したというもの。 Rebuild の Episode 288 で触れられているので興味がある人は聞いて下さい。

この記事については日本語の翻訳もあってはてブで 500 ブックマークくらいついていたが、どうも機械翻訳されただけのようだったし、一部訳が違うのではと思われるところがあったので自分でも訳してみた。訳を原著者の Jeffrey Paul 氏にメールで送ったので恐らくそのうち本家に日本語訳が追加されると思う。

Your Computer Isn't Yours

2020-11-25 9:16 追記

日本語訳追加してもらいました。

sneak.berlin

起きていることをまとめると以下のような感じだ。

  1. Apple は Mac ユーザーのアプリ起動データを IP 付きで Apple のサーバーに集めている（ログ送信）
    • 各アプリの署名有効期限チェックやマルウェア対策のためということになっている
    • Mac から Apple への通信は暗号化されていない
      • ISP や CDN （ Akamai ）、ネットワークを盗聴している他人が内容を確認可能
    • この通信はユーザーが自分の意思で無効化できない（「Mac解析を共有」をオフにしても送信される）
  2. Mac （特に Big Sur でしか動かない Apple Silicon Mac ）を使いたければ利用ログ送信を甘受するしかない
    • Big Sur から、上述のログ送信や Apple 製のアプリは VPN やファイヤウォールを無視するようになった
    • OS の挙動を変更しようとすると Mac が起動しなくなる
  3. iCloud Backup は iMessage の秘密鍵も一緒にバックアップするので Apple がメッセージの内容を読むことができる
    • 自分自身が iCloud Backup 利用していなくても、メッセージの送信相手が iCloud Backup を使っていると自分が送ったメッセージが iCloud 上に保存される
  4. Apple はプライバシー保護を売りにしながらユーザープライバシーをなおざりにしている
    • iMessages/iCloud Backup のバックドアを放置している
    • 過去にアプリ開発者には HTTPS を強制しながら自分たちは OCSP の通信を平文で行っている
    • ログ送信の件について対応を発表したが、対応時期を明確にしていない

その結果、以下のような状況に陥ることが懸念されている。

  • Apple が集めている情報は NSA や FBI に筒抜けになる
    • Apple はアメリカ軍の諜報機関や FBI にユーザーログデータなどの閲覧を令状なしで認める協定を結んでいる
    • iCloud Photo や iMessage の内容を Apple だけでなく軍や FBI も見られるようになっている
  • ユーザー保護を隠れ蓑に Apple が力を増大させる
    • マルウェアから守る、を大義名分にして、ユーザーがどのアプリを動かせるかを Apple がコントロールできる可能性がある
    • 原理的には Apple が気に入らないアプリを起動できなくしてしまうことが可能

モバイルアプリの利用状況の収集は多分いろんなアプリがやっている。 Mac で Apple が集めている程度以上の情報を集めているアプリも多いだろう（位置情報を取得しているアプリなど）。なので最初この件については過剰に反応しすぎなのではないかと思っていたが、よくよく考えてみると自分の感覚の方が麻痺していたのかもしれない。アプリの利用履歴を IP アドレス付きで送るということは、どこで何をしているかがアプリ開発者に筒抜けだ。そしてそのログを公権力が自由に閲覧可能だとしたらいい気持ちはしない。

アプリと Apple の場合で決定的に異なるのは、アプリはそのアプリが起動している間（あるいはバックグラウンドでのログ送信を許可されている間）だけログを送信するが、 Mac に関して言うとずっーっと起動しっぱなしで使い続けるものなので、ログデータからユーザーの行動履歴・生活様式がわかってしまう。地図アプリで検索した場所の情報も送られていたということなので、 Jeffrey Paul 氏が書いているように、その人がこれから行く予定の場所もわかってしまう。

GDPR や様々なプライバシー保護は、アプリを作りサービスを運営する側としては正直厳しいなと思うところはあるけど、 Apple がアメリカ軍と結んでいる PRISM のような取り決めが存在すると、様々な個人情報が政府機関に流れてしまって、アメリカのサスペンスドラマのように個人の位置情報を携帯の使用履歴からいとも簡単に割り出せるようになってしまう。それはやはり恐ろしい世界だ。

プライバシーの侵害のみならず、プラットフォーマーである Apple の匙加減次第で、ユーザーが使えるアプリが決まるという状況も好ましくない。たびたび iOS の App Store で起こる Apple の恣意的な審査基準改変などはその一端だ。 Hey の件で Apple とやり合った DHH は痛烈に Apple を批判するとともに、かつて邪悪な Microsoft に対抗するための救いとも言えた Apple が以前の Microsoft 以上に邪悪になってしまったのが嘆かわしいと Twitter に書いていた。学生の頃、 Mac を広める活動をやって大学のクラスの半分の同級生のラップトップを Mac にしたというエピソードや、 Rails の開発でも Mac を激推ししたという話は胸熱だった。応援してきた Apple が Evil になってしまい、人一倍残念に思っているのだろう。

Apple はかつて "The computer for the rest of us" というコピーで Macintosh を宣伝していた。しかし今日、 Mac は彼らのコンピューターになってしまったのだ。

| @雑談

今年も寒くなって SIERRA DESIGNS のマウンテンパーカーの記事へのアクセスが増えてきた。シェラデザインのパーカーを買っても問題ないか（友だちから馬鹿にされないか）確認しているのだろう。検索キーワードは「シェラデザイン ダサい」というのが一番多い。

SIERRA DESIGNSのマウンテンパーカー

SIERRA DESIGNSのマウンテンパーカー

桜がぼちぼち開花し始めたここ数日、皆様におかれましてはいかがお過ごしですか？ 今日は一昨年から気に入って着てるSIERRA DESIGNSのマウンテンパーカーについて語らせてもらいたいと思います...

portalshit.net

防寒に関しては登山やキャンプをして思うところが増えてきたので、自分の考えをまとめておこうと思う。ちなみに以前、ゴアテックスのジャケットを買ったときに書いた記事では「あまり暖かくないがこれでいいのだ」的なことを書いていたが、登山を始めて寒さのなんたるかを理解するようになってゴアテックスを街中で着るのはやめた。

ARC'TERYX のパーカーを買った

ARC'TERYX のパーカーを買った

去年、嫁さんに強請られて GORE-TEX のコートを買わされた。自分はシェラデザインの 60/40 マウンテンパーカー/ショートパーカーを三着持っていて（SIERRA DESIGNSのマウンテ...

portalshit.net

寒さの原因と対策

寒さの原因は雨、風、気温があって、登山用の防寒着はそれぞれの要因別に作られている。

  • 雨
    • 雨ガッパ（レインウェア）
    • ゴアテックス
  • 風
    • ウィンドシェル
    • ゴアテックス
    • ロクヨンパーカー
  • 気温
    • 中綿入りジャケット
      • ダウン
      • 化学繊維

ゴアテックスのジャケットは雨と風由来の寒さは防げても、あまりに気温が低いときや立ち止まっているとき（休憩中など）は防寒の役に立たない。そういうときにはダウンや化繊など中綿の入った服が必要になる。以下順に見ていく。

風

標高の高い山だと晴れてるのに風がビュウビュウ吹いていて寒いということがある。バイク乗りの人が温かい季節でも革ジャンを着るのと同じ感じで風から体を守るための上着が必要になる。それがウィンドシェルと呼ばれるものだ。雨具でも風はしのげるが、登山などでは動きながら防寒しなければならないので湿気や熱を外に逃してくれる方がいい。というわけで風が強い時には薄手のウィンドシェルを着る。風の寒さだけから身を守り、体から出る熱や湿気は外に逃してくれる。

夏の北アルプスの稜線で爆風に吹かれている著者。 Patagonia のフーディニジャケット（通称「パタゴニアのシャカシャカ」）で風を凌いでいる。

雨

雨の寒さは濡れることによる寒さだ。濡れると水の冷たさで寒いし、水は蒸発する（乾く）ときに体温を奪うのでダブルで寒い。それに風が当たると低体温症まっしぐらだ。その状況から身を守るのが雨具だ。レインウェアは登山では必須アイテムで、レインウェアがない状態で雨に降られると夏でも低体温症になって死んでしまう。ゴアテックスのジャケットは防水でありながら透湿性があり、汗をある程度外に放出してくれる。おかげで自転車通学の中学生が着る雨合羽のように雨には濡れなかったけど合羽の下は汗でびしょ濡れということにはならない（と言われている）。

低気温

風や雨はなくても気温自体が寒い時もある。低気温には中綿（インサレーション）入りのジャケットが有効だ。インサレーションとは生地内に化学繊維やダウンが封入されていることを意味する。登山では山頂に着いて休憩するときやテント泊するときに着用する。動いていないときは体が冷えるので、体からの熱を閉じ込めておく必要がある。そういうときにダウンや化繊の綿入りジャケットを着る。自分はパタゴニアのナノパフを持っているけど、山でも日常生活でも使っている。

ナノパフは化繊で洗濯機で雑に洗えるけど、汚さない前提ならダウンの方が軽くて温かい。ダウン自体は雨に弱く、濡れると空気の層を作る役割を果たせなくなるのでめっちゃ寒い。なのでもこもこのダウンジャケットを単独の上着にするのはおすすめできない。ダウンは薄くて軽いものを選び（ユニクロのウルトラライトダウンは便利そうだ）、その上からゴアテックスなどを着ると完璧だ。

登山の休憩中、 Patagonia のナノパフジャケットを着て寒さを凌いでいる著者。

結論 普通の人にゴアテックスの高いジャケットはいらない

ゴアテックスのハードシェルジャケットは山で風や雨が強い状況で動いてるときに寒さを凌ぐことを目的に作られているので、無風で雨も降っておらず、重い荷物も斜面もない街中でゴアテックスを着ていても体からの熱が少ないので寒いだけだ。 Patagonia や ARC'TERYX のゴアテックスジャケットはかっこいいが、値段が高い割に低気温での寒さを凌げずコストパフォーマンスが悪い。

日本の東北地方以南に住む現代人の日常生活で、風や雨（雪）の寒さを考慮しなければならない状況は稀だろう。移動は公共交通機関か車だろうし、雨に降られたり風に吹かれたりは家や職場から駅まで移動する間の 10 分程度のことだろう。こういう状況では化繊の中綿入りジャケットが便利だ。風や雨を考慮したゴアテックスのジャケットを街中で着てもオーバースペックというか、防寒の役割を果たせない。

友だちの結婚式で 11 月の松本に行ったときに ARC'TERYX のゴアテックスジャケットを着ている著者。松本の街は晴れの氷点下で、このとき着るべきはゴアテックスジャケットではなく中綿入りのジャケットだった。

加えて、今回記事を書くために ARC'TERYX の Alpha SL を引っ張り出してみたら何と縫い目のところを埋めてあるシームテープがところどころボロボロになっていた。買ってから 7 年経つが、単独では防寒性能が高くないこともあってここ 3 年は登山のときに雨具として持っていくのがもっぱらでほとんど着ていない。買ったときは 5 万円くらいした気がするのでめっちゃコストパフォーマンスが悪い。

そういうわけで、登山をする予定がない普通の人は中綿入りのジャケットを買うのがおすすめです。もし予算に余裕があれば上でも触れている Patagonia のフーディニジャケット（通称「パタゴニアのシャカシャカ」）を追加で買われることをおすすめします。パタゴニアのシャカシャカは非常にコンパクトに畳めるウィンドシェルで、何かと重宝する。山で寒いときはもちろんのこと、真夏にはクーラーの冷気から身を守ることもできる。 Kaizen Platform 退職時に元同僚の @glidenote さんが餞別としてプレゼントしてくれたが、もらってからの 3 年半、外出するときはほぼ常に持ち歩いている。

一年中着られて超おすすめです。セールのときに買えば 1 万円くらいで買えます。

| @ブログ

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

カテゴリーごとに最新記事 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 でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

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

| @Mac/iPhone

仕事用の MacBook Pro が新しいやつになったので備忘のために設定方法をメモしておきます。

以前書いた通り、自分は Google Chrome の Profile を二つ作ってノーマルの Chrome と Canary チャンネルの Chrome （ベータよりももっと攻めてるやつ）の二つを使い分けている。仕事用が Canary Chrome でノーマルが私生活用。 Slack からのリンクや Google Drive の URL は仕事用の Canary Chrome で開くように Choosy を使って設定している。 Cloud で Profile が同期される都合上、こうするしかない。

その Canary Chrome への 1Password のインストール方法がちょと特殊で、公式サポートフォーラムの以下の記事の通りにやる必要がある。

1password.community
  1. rm ~/Library/Application Support/Google/Chrome Canary/NativeMessagingHosts/2bua8c4s2c.com.agilebits.1password.json
    Canary Chrome の 1Password 用設定ファイルを削除（存在しない場合もあり）
  2. ln -s ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/2bua8c4s2c.com.agilebits.1password.json ~/Library/Application\ Support/Google/Chrome\ Canary/NativeMessagingHosts/
    ノーマル Chrome の 1Password 用設定ファイルのシンボリックを Canary Chrome の設定ディレクトリに張る
  3. Canary Chrome 再起動

1Password が Chrome とのやりとりに使う JSON ファイルをノーマル Chrome と Canary Chrome で共通化してしまうようだ。これで Canary Chrome でも 1Password が使えるようになる。

| @散財

Pebble Time Round

4 年前の誕生日に嫁さんに買ってもらった Pebble Time Round をずっと使ってる。

純正革ベルトは購入後割とすぐに異臭を放つようになってしまった。革ベルト自体がくさいのではなく自分の手首の垢がベルトに染み付いて異臭を放ってるみたいだった。

おまけに充電部が皮膚と触れるせいで端子がさびてしまい購入半年で充電しづらくなってしまった。

その後ベルトをナイロン製の NATO のやつに変えて臭いも端子のサビも（肌が直接充電端子に触れなくなったので）幾分かましになったが、最近また調子が悪い。

Pebble は自分が Pebble Time Round を購入した年の年末に FitBit に買収されて終了した。

Yahoo! - 999 Unable to process request at this time -- error 999

Yahoo! - 999 Unable to process request at this time -- error 999

japanese.engadget.com

その FitBit も Google に買収されてしまった。

Yahoo! - 999 Unable to process request at this time -- error 999

Yahoo! - 999 Unable to process request at this time -- error 999

japanese.engadget.com

結構きついのがソフトウェアの更新が止まってることだ。有志がメンテナンスしてくれているが、いつ iOS のアップデートに追従できなくなるかがわからない。

なんだか書いていて暗澹たる気分になってきたが、二日はバッテリーが持つし、小さくて軽いし、 E-Ink なので常時時間を確認できるしで良いところもたくさんある。厚みが薄くて見た目がいかにもスマートウォッチ然していないのも良かった。それでいて万歩計、睡眠トラッキング、スマートフォンへの通知の受け取りにも対応しているので神デバイスだったと思う。腕時計へプッシュ通知が届くことの便利さに慣れたらなくては困ると感じるだろうから壊れたら観念して Apple Watch を買おうと思うけど、 Pebble Time Round のような感覚では使えないのだろうなと思う。

| @WWW

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

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

心のざわめきを無くして日記を書くということ / 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

【今月二度目】 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 が発狂してから - 氾濫原

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

lowreal.net

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

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

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

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

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サービスの矜持について - 氾濫原

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

lowreal.net

| @WWW

山に行ったときに山頂でコーヒー入れて飲むの好きで、その様子を「純喫茶 山頂」などと言って Twitter に投稿してた。

そしたら嫁さんに同じようなことを動画でもっとイケてる感じでやっている人がいることを教えてもらった。

TikTok - Make Your Day

TikTok - Make Your Day

www.tiktok.com

Tasty がその人の動画を一本にまとめてるのが以下。

Falke Omdal さんという、ノルウェー人のアウトドア写真家のようだ。フィヨルドを見下ろす崖の上に腰掛けてコーヒー入れたり、カヌーでどっか行ってコーヒー入れたり、山の上にテント張って焚き火でお湯わかしてコーヒー入れたりしてる。山で焚き火台使わず地面に直で焚き火するの、日本でやったらめっちゃ怒られそう。

Falke さんがすごいのは、山にハリオやケメックスのコーヒーサーバーや、ガラスのコップを持って行ってるところだ。登山用品はとにかく軽い方が良いし、かさばるものは避けられがちだ。軽くて小さく、重ねられる丈夫なものが好まれる。ガラスの容器やコップは重いしかさばるし割れやすいので全然登山向きではない。でもやっぱりコーヒーは金属製の容器よりもガラスのサーバーにドリップする方がうまそうに見える。

地面直の焚き火にしろ山でガラス容器を使うことにしろ、登山で常識とされていること（少なくとも日本では）から自由な発想で山での時間を過ごしているところがとてもうらやましい。

ちなみに自分もこの前家の近くの山に登ってみたときに真似して動画撮ってみたけどあまりいい感じにできなかった。簡単そうに見えるけどちゃんと三脚で固定したり、コーヒー入れる人とは別に撮影する人が必要だと思った。編集のテクニックも必要だ。長い動画をアップしてもあまり見てもらえないっぽい。必要な部分だけを残してつなげ、 30 秒くらいで終わる動画にしないと見てもらえなそうだ。