読者です 読者をやめる 読者になる 読者になる

カラクリサイクル

『輝かしい青春』なんて無かった人の雑記

自分のすべてのブログから Google Analytics を除去した

と言う話。


昨日、

the.nyarla.net

と言う記事を書いた事を切っ掛けとして、

アクセス数の把握って、ぶっちゃけ Google Analytics を使うまでもなくね?

と思ったので、 Google Analytics でのアクセス情報の収集を止めました。


ちなみに僕の場合、Google Analytics はほぼアクセス数の推移ぐらいしか見てなくて、 この機能ははてなブログのアクセスカウント機能使えば問題ない、って感じだったので、 こう、サックリと Google Analytics を削除出来ました。

しかしながら、他に色々な Google Analytics の機能を使ってたりすると、 多分こうもサックリとは行かないだろうし、また、オウンドメディアとかそう言うのだと、 アクセス解析は重要な指数を把握するためのツールとして有用だと思うので、 その手のメディアを運営しているのであれば、 Google Analytics とか使ってた方が良いと思う。


とりあえず、僕にとっては Google Analytics は使ってる意味も特に無かったので、 使用するのを止めた、って話でした。

まあ、取り留めもない話だけれども。一応お知らせまでに。

誰が為にブログを書くのか

ここ最近、ブログで収益を上げられる様になるために、 ブログの運営を改善しようかと思って、アクセス解析や、 あるいは、データ分析の結果をブログ運営へ反映させる、 みたいなコトへの取っ掛かりを掴もうとして、色々調べていたのけれども、 どうも、自分の中で、何か噛み合わなさが有って、それって何なのだろう、 と思いを巡らせた結果、

僕はブログを、たた単純に自分のために書いている

と言う事実に気が付いた、というか気付いてしまった。

それで、その 『ただ、自分のためだけにブログを書いている』 という状態の何が問題か、と言うと、 つまるところ、ブログ運営の改善を行うための動機である、

ビジネスとして 、あるいは、個人的な オウンドメディアとして 成立するブログにする

と言うのは、或る種、『収益を上げる・収益に繋げる』 ためのブログであって、 『ただ単純に、自分を満たすためのブログ』とは『違っている』し、 また、僕が過去に敏感な話題をブログで扱って来たため、その手の、

ビジネスとしてブログ運営する

という行為そのものと、とても相性が悪い、と言うかどうがんばっても良くない。

そのため、この手の事をしようと思うと、別のブログを立てる必要が有るんだけど、 前述の通り、僕が自分のブログを書く動機と言うのは、

自分を満たすため

という性質が有るため、過去の自分の体験から、その手のブログを作っても、 実際にはほぼ更新しない、と言う結末になっているため、

……あれ、手詰まり?

という感じになってしまった。


まあ、これは自分の意識を変えれば良いだけの話なのかもしれないけれども、僕の性質から言って、 自分が気乗りしないコトを長々と続けられるほどには我慢強くないので、まあ、

ブログで収益を上げて云々

は、止めておいた方が良いかなぁ、なんて結論になった。

それと僕の場合、ブログの更新の頻度を上げると、勝手にアクセスが増える、 と言うのを経験しているので、まーアクセス数を上げるためにには、 ブログの更新の頻度と上げるしかないのかなーなんて考えています。

まー自分に向かないコトを行っても自分が擦り切れるだけなので、 とりあえず、無理にアクセス解析とかせずに、気楽に更新とかしていけば良いかな、 なんて結論に至ったので、とりあえず、アクセス解析についてはあんまり難しく考えないでおこう。そうしよう。うん。

『そして、 Vivaldi だけが残った』

という状態へ、自分の PC 環境が収束しつつある話。


最近、 PC をもうそろそろ買い替えたい、と思っている中で、

Mac 最近飽きてきたし、ここは Windows とか使ってみるのも良いかな

なんて考えていて、そこへ考えが行く度に、普段、僕が良く使っているアプリケーションである、

  • Reeder for Mac での RSS/Atom Feed の消費
  • iTunes での音楽鑑賞と iOS の同期

等々、を、

どうやって乗り換えるかなーコレ

って成っていたのだけれども、昨日、気合い、というか、何となくのその場の勢いとか使って、

  • Reeder for Mac → FeedBin + Instapaper (Web)
  • iTunes → Google Play Music (Web + 聴き放題)

に変えてみた所、思いのほか快適だったので、色々調子に乗って、こう、色々とアレやコレやを行ってみたところ、

『そして、 Vivaldi だけが残った』

という状態になりました。なんでや。


それで、僕が普段使っているアプリケーションなどなど、を、

Web ブラウザ (Vivaldi) に集約する

という作業をした結果、大体、こういう感じで Vivaldi に集約出来た:

  • Airmail 3 for Mac → iCloud Mail (Web) + Inbox for Gmail (Web)
  • iTunes (音楽) → Google Play Music (Web + 聴き放題を Subscribe)
  • Franz (Slack, Twitter, Instragram) → Slack (ピン止め) ・Twitter, Instagram (Web パネル)
  • Reeder for Mac → Feedbin (Web) ・ Instapaper (Web)
  • MacPass (Keepass Client for macOS) → Keeweb (Web・AWS S3 + Dropbox Sync)

ちなみに、このエントリを書いている今もなおこの環境で生活してるんだけど、 なんと、驚くほど何も困らなかった。と言うか、すべてを Web 化した影響で、 事実上、 Vivaldi さえ有れば Windows だろうと Mac だろうと、 あるいは Linux や BSD でも困らない環境になったので、こう、感無量というか、

おおおおお、時代は正になんでも Web や!

という感じになったので良い。


しかしながら。

実際、この環境を使う上で、いくつか問題が無いわけでは無くて、事実、幾つかの問題は有り、おおよそ、

  1. 維持費が結構かかる (Google Play Music とか)
  2. iOS デバイス同期云々が面倒 (特に Linux でこの環境を再現する場合)
  3. Vivaldi が結構リソースを食う (特に Web サービスを Pin 止めしまくってる場合)

という感じの問題が有ったりする。

まあ、 3 番に関しては、マシンリソースを盛ればなんとかなるとして、 1 番が結構つらい。って言うか、年額でのサービス支払いへの固定費がモリっと増えた。つらい。

それと、2番の iOS の云々については、 Mac や Windows を使ってる限り、 特には問題とはならないんだけど、仮に Linux に乗り換えたりした場合、

  • iOS の開発は無理 (Mac でしか出来ないからナー)
  • iOS のバックアップは iCloud Backup ベースか Windows VM を使う事になる

と言うコトになるので、まあ、この辺りも考えモノだなぁ、と。

特に iOS を iCloud Backup ベースで管理するとなると、基本、 iCloud Drive のストレージを容量をマシマシして契約しないと、 多分バックアップの容量が足りなくなるので、その辺りも固定費が増える。つらい。

あとはまあ、開発とかも VPS 立てて Web-based Terminal で云々をすると、さらに維持のための固定費が増えるので、 まあ、あんまりこれ以上は増やすのはどうかなぁ、なんて思ってます。でもなんか増えそうだけども。


まあでも、今、 Web だけで生活する、っていうの、マネーはかかるけど、 それなりには出来るっぽいので、 IT 文明としては 良い時代になったなー、なんて思ってます。

と言うことで、今回は以上です。はい。

ストック・フロー・ストリーム

今日、なんとなく自分の 個人 Slack を復活できないかーと思って Slack いじってた時に、 ちょっとした気づきを得たので、今日はその辺り書いてみます。


今まで、 チームでの情報共有 とか、あるいは、 情報の整理・共有 という文脈では、

情報にはストック型とフロー型の二種類が有る

と言われている、と僕は認識していて、実際、この二つの分類で大体の情報は分類出来る、 と僕は思ってたんですが、今日 Slack をいじってた時に、

情報の性質は、 ストック型ストリーム型 が両極端にあって、 フロー型 という性質の情報は、ストック型とストリーム型の情報が混ざった姿なのではないか?

という事に気が付きました。

それで、ここで言う ストリーム型の情報 とは何かっていうと、 基本的なイメージとしては、 Twitter のタイムライン とか、あるいは Slack での日常的な会話 、 もしくは、 LINE のでコミュニケーション とかを思い浮べるとイメージすると良いかなー、なんて思うんだけど、 ああ言う場での会話って、基本的には、その場で流れていく類いのモノ、というイメージじゃないか、と思うんです。

そして、情報の流れ を、 水の流れ に例えると、

  • ストック型の情報流れを堰き止める必要が有る 類いのモノ
  • フロー型の情報一時的に流れの上に浮べておく必要が有る 類いのモノ
  • ストリーム型の情報流れるままにする必要が有る 類いのモノ

と言う感じなんじゃないかなー、と。

つまり、情報の性質としては、ストック型 の様な、 流されるモノを留めておく必要が有るモノ と、 ストリーム型 という、 流れて行っても基本は構わないモノ の両極端の性質が有って、 その間はなだらかなグラデーションになっている 、 と言うのが、まあ、 情報の性質の本質ではなかろうか というのが、今回、思い至った話の内容ですね。はい。


それで、上記の話を総合して実際にソフトウェアに当てはめると、 大体、

  • Wiki はストック型
  • Qiita や esa.io 等は、ストック型からフロー型の中間
  • ブログや RSS/Atom Reader で読めるフィードの類いは フロー型
  • Twitter や Slack などの Chat as a Service は基本ストリーム型で時々フロー型

と言う感じなんじゃないかなーと、個人的には思っています。

ただ、この辺りの話は感覚の話でもあるし、また、人によっては違和感が有るかもしれない話なので、 話半分に聞いて頂ければ問題ないんですが、上記のような情報を取り扱うツールを作るとなると、 今回気がついた内容の話については、まあ、ある程度は気を付ける必要があるのではないかなー、と個人的には思います。


と言う事で今回の雑文は以上です。はい。

macOS Sierra の package manager に nixpkgs を使ってる話

僕は以前、 Homebrew が Google Analytics のトラッキングがどうのと言う問題で揉めてた時に、 Homebrew を使うのを止め、Homebrew から NetBSD のパッケージマネージャである、

  • pkgsrc + pkgin

に乗り換えていました。

しかしながらその後、

pkgsrc + pkgin もなにかイケてないなー

という感が強まったため、今度は、

  • Gentoo Prefix

に乗り換えようと決心、そしてその後、環境構築とかもして、

さあて、使い始めるとするか

ってなった次の日に macOS Sierra がダウンロード可能になってインストールとかしたため、

なんか色々と (Gentoo Prefix が) 動かないし、そもそもこれメンテされてるの?

と言う、ちょっとしたつらみを感じる状態になっていました。

そして、

今さら Homebrew 使うのもアレだし、 pkgsrc + pkgin もなんかなーだし、 Gentoo Prefix も動く気配も無いし、どうしたもんかなー、 macOS でのパッケージマネージャ

と思ってた時に、

そう言えば、昔 NixOS っていう変わった Linux とか有ったよな

と思い出したりして、

あれ、これ (NixOS のパッケージマネージャ)ってもしかして OSX (macOS) でも使える?

と気がつき、かつ実際に使ってみたら、結構使えるモノだったので、今現在、 僕は macOS Sierra でのパッケージマネージャとして、

を使っています。


それで、この nixpkgs という パッケージマネージャ、色々と独特かつマイナーで、 僕が気がついた特長としては、

  1. パッケージの定義に関数型言語な独自 DSL を使っている
  2. パッケージ間依存地獄が 基本的に無い (ただし競合とかは流石に有る)
  3. 不要となったパッケージ郡をコマンド一発で一掃できる

と言う感じのパッケージマネージャです。

それでいてさらにnixpkgs が凄い、と個人的に感じるのは、 パッケージマネージャ というレイヤーで、

通常では システムに両立出来ないパッケージを、 分離しつつ共存させられる

という点です。

これ、どういう事が出来るかっていうと、すごく雑な説明になるんだけど、

開発環境を docker 化して、パッケージ依存関係をシステムから分離する

と言うような事を、 パッケージマネージャ のレイヤーで出来る、という感じです。

つまり、例えば Java を使ったソフトウェア開発 をしていたとして、 或るプロダクトでは最新の Java のバージョン を、 別のプロダクトでは一つ前のバージョンをそれぞれに依存関係として要求される 、という様な状態な時、通常であれば、 VM や Docker でシステム丸ごとコンテナ化して云々かんぬん 、ってするところを、 nixpkgs では、環境の定義ファイルを用意して、それをコマンドに読み込ませて使えば、 VM とか docker とかを独自に用意せずに、効率よくシステムに併存させることが出来る、 というのが nixpkgs に出来る事です。

またこういった機能を実現している故か、

  • コマンド一発で、不要になったパッケージを一掃出来る

と、これまた凄く良い機能も実装されているので、その点でも結構便利です。

ただし、このパッケージ一掃コマンド、時と場合によっては、と言うか、システムに、

このパッケージは恒久的に必要です

というフラグが立ってない場合、

微妙に吹っ飛ばされたくないパッケージを吹っ飛ばされる

という事も時々有るので、それはそれは要注意だったりしますが。


ちなみに、ここまで書いたこのエントリで、 nixpkgs や、あるいは NixOS (nixpkgs を使った Linux Distro) に興味を持たれれば良いな、 とは思うのですが、いかんせん nixpkgsNixOS は独特に過ぎるので、ぶっちゃけ、 取っ付きにくさは結構あります

また、nixpkgsNixOS の日本語情報、ってほぼ無いに等しいので、 何か判らない事などが有る場合、基本的には英文の情報に当たらざるを得ません。

さらには、2016年11月中旬現在 、nixpkgs とか NixOS の公式ドキュメントの類いは、 ただ今絶賛整理中で、部分的に Wiki とか 公式ドキュメントとかでバラバラしている状態なので、 その点でも情報が探しにくいです。

ただ、そうは言っても、 nixpkgs という NixOS で採用されたパッケージマネージャは強力だし、 また、NixOS は DevOps とか Infrastructure as Code と言う文脈においても結構、相性が良いので、 ま、興味を持たれた方は、

を覗いて見ると良いんではないかな、と思います。


と言う事で以上。本日の雑文はこれで終わります。