| @技術/プログラミング

ブログのアプリケーションサーバーには unicorn を使っていたのだけど puma に変えてみた。

2011 年から使っていたようなので丸 5 年は unicorn を使っていたことになる。 puma はスレッドセーフにしないと死ぬ、ということは聞き及んでいたのでおそるおそる変えてみたけどいまのところ問題なさげ。

手元で確認したときには scss のコンパイルで怪しい雰囲気があった(特定ページにアクセスしたあとレスポンスを返さなくなってしまう)ので 0.12.7 だった compass のバージョンを 1.0.3 に上げてみたところ問題が解決した。結果オーライということで深追いはしてないけど、リポジトリを見に行ってみたらメンテナンス停止しているようだった。最近はフロントエンドは JavaScript でやるのが当たり前ですもんね。

Lokka のフロントエンドは 2010 年頃ナウかった Ruby ベースの技術が満載で最近の傾向とは異なるので、フロントエンドで利用してる gem がメンテされておらず Ruby のバージョンアップ時のボトルネックとなってくることが考えられる。この前 Ruby 2.4.0 で動くか素振りしてみたけどダメだった。padrino-helpers 、 slim 、 haml 、 coffeescript (この機能は自分が追加した)あたりとどういう風に折り合いを付けていくか考えないといけない。

| @WWW

Transmit iOS

iPhone からブログ書くときに画像もアップロードしたいと思って iPhone から S3 にアップロードできるやつを調べた。 Lokka にはデフォルトでは画像をアップロードする仕組みないので自分の場合は手動で S3 に画像をアップロードするか Flickr に上げて参照するようにしてる。 iPhone からだと Flickr に上げても embed 用のコードを取得できない( Flickr の iPhone アプリでもモバイルサイトでも embed コードは表示されない)ので、 iPhone から S3 にアップロードするのが最適解となる。本当は投稿画面から S3 にダイレクトアップロードできるような仕組みがあればいいんだろうけどまだやれてない。そのうちやりたい。

で、 iPhone 用の S3 クライアント探してたんだけど、無料のやつはたいていウェブサービスになってて、複数のクラウドストレージを一元管理できるとかそういうやつだった。 AWS の Access Key Id と Secret Token を第三者に渡して万が一それが流出したら一瞬で巨大 EC2 インスタンスいっぱいたてられて Bitcoin 掘りに利用されてクラウド破産しそうだと思った。こういうの使うにしても AWS のルートアカウントではなく S3 だけにアクセスできる IAM アカウントを使うべきだと思う。面倒くさいと思ったのであきらめて 1200 円払って Panic の Transmit の iOS 版を買った。インターネットでも金がない者や情弱が危険に身を晒さなければならない。

Transmit 自体は良くできてて便利。 Mac ではケチって Transmit よりも安い ForkLift ってのを使ってるけど、S3 にアップロードしてあるファイルの URL 取得するときにバケットに独自ドメイン当ててあったら独自ドメインの URL で取得してくれたりと Transmit の方がおもてなしされてる感がある。細かいところが親切。ブログ用の画像のアップロード以外にもいろいろ使い道ありそう。

Panic, Inc.「Transmit」 https://appsto.re/jp/IPUR2.i

2019-09-22 追記

残念なことに Transmit は開発を終了していた。儲からないのだそう。 35,000 ドルの売上では人件費の半分も回収できないとのこと。

| @雑談

ANA のマイル貯めたくてマイルが貯まるクレジットカードのこととかいろいろ調べてみたけど、あれは富裕かつ時間にも余裕のある層の道楽という感じがする。普通に暮らしててもすでに結構豊かな暮らしをしてる人が、その出費でさらにポイントを得ていい思いをしようというものだと思った。庶民が同じようなやり方でマイル貯めようとしても無理だと思う。陸マイラーの人たちみんな平気で年間 500 万くらいカード決済してるっぽい。

お金を使わなくてもポイントサイトでなんかやればマイルもらえるとかあるけど、 FX 口座開設して口座に入金して実際に取引をした上でポイントがもらえるとかそういうやつは、貯蓄額が限りなく 0 に近い自分にはできない。クレジットカードをじゃんじゃん発行しまくってポイントをもらうというやつも、ゴールドカードやアメックス、ダイナースのカード発行は審査が通らない。なのでマイル乞食ブログでよく紹介してある「ポイントサイトで貯めたポイントをマイルに変換して特典航空券を取得してビジネスクラスでハワイ旅行」みたいなのは、すでに現段階で年収 1000 万以上あるお金持ちにしかできない道楽という感じがする。

加えて仕事が忙しくなく、時間にも余裕がないとポイントサイトでちまちま募集案件を調べたり、様々なポイントを効率よいルートで交換していってマイルに変えたり、ポイントをもらうために 1000 円分だけわざとリボ払いになるようにカードの引き落とし額を調整する、とかいったことに時間を割くことができない。

なので陸マイラーになりたいと思ったらまずは

  • 年収 1000 万を目指す
  • 9 時 5 時で終わる仕事に就く

必要があると思う。しかしこんなのは 30 歳過ぎた人間が今から達成することは不可能で、若い頃にちゃんと勉強して医学部に入り開業医になるだとか、食いっぱぐれない資格を取得して士業に就くとかしないと無理っぽい。陸マイラーブログとかやってる人、大半が開業医か弁護士か司法書士か税理士(会計士は忙しそう)なんじゃないかと思う。あるいは政令指定都市の閑職公務員。小学生に戻って人生やり直すしかない。

| @WWW

Rusted window flame

アドベントカレンダー、去年は自分で一個作ってみた。

カレ主(カレンダー作った人 = 自分のこと)以上にほぼ毎日記事を書いてくれた人( trurusuke さん)がいて記事埋まったけど、 trurusuke さんのコントリビューションがなかったら全然スカスカだった。

自分でも複数記事書いたけど、一番最後は年明けの 2/27 に書き終わったりしてて最悪だった。

アドベントカレンダー、作るからには真剣にファシリテートしないといけない。軽い気持ちで始めると書いてくれる人に失礼だしそもそも誰も登録してくれない。仕事でプロジェクトをリードするのに似てる。よいアドベントカレンダーをファシリテートできる人は仕事やオープンソースソフトウェアプロジェクトや町内会、保護者会、学生サークル・社会人サークルなどでリーダシップを発揮することができると思う。自分はどれもさっぱりなのでカレ主になれるような器ではなかったのだ。


Adventar 、最近は登録されるカレンダーの数めっちゃ数増えてて、奇をてらいすぎてるものや個人の日記、カレ主にやる気がない(去年の自分)ものも散見される。 25 個の枠が埋まってない状態のやつが増えてきてるのではないかと思って 2012 年から調べてみた。 JSON API を用意してくれてた Adventar++ 。

⚡ curl -s http://www.adventar.org/calendars.json?year=2016 | jq '. | length'
530
⚡ curl -s http://www.adventar.org/calendars.json?year=2016 | jq '. | map(select(.entries_count==25)) | length'
125
⚡ curl -s http://www.adventar.org/calendars.json?year=2016 | jq '. | map(select(.entries_count>=20)) | length'
169
⚡ curl -s http://www.adventar.org/calendars.json?year=2015 | jq '. | length'
510
⚡ curl -s http://www.adventar.org/calendars.json?year=2015 | jq '. | map(select(.entries_count==25)) | length'
236
⚡ curl -s http://www.adventar.org/calendars.json?year=2015 | jq '. | map(select(.entries_count>=20)) | length'
281
⚡ curl -s http://www.adventar.org/calendars.json?year=2014 | jq '. | length'
311
⚡ curl -s http://www.adventar.org/calendars.json?year=2014 | jq '. | map(select(.entries_count==25)) | length'
142
⚡ curl -s http://www.adventar.org/calendars.json?year=2014 | jq '. | map(select(.entries_count>=20)) | length'
168
⚡ curl -s http://www.adventar.org/calendars.json?year=2013 | jq '. | length'
230
⚡ curl -s http://www.adventar.org/calendars.json?year=2013 | jq '. | map(select(.entries_count==25)) | length'
112
⚡ curl -s http://www.adventar.org/calendars.json?year=2013 | jq '. | map(select(.entries_count>=20)) | length'
129
⚡ curl -s http://www.adventar.org/calendars.json?year=2012 | jq '. | length'
42
⚡ curl -s http://www.adventar.org/calendars.json?year=2012 | jq '. | map(select(.entries_count==25)) | length'
27
⚡ curl -s http://www.adventar.org/calendars.json?year=2012 | jq '. | map(select(.entries_count>=20)) | length'
30

下落傾向かと思ったけど調べてみたらそんなことなくて大体毎年 50% 弱くらいみたいだった。最初の年の 2012 年が枠埋まり率高い。個人的には闇アドベントカレンダーと寿司アドベントカレンダーがあった 2013 年がアツかった気がするのだけど枠埋まり率は 45% で 2015 年と大差ない。各年の 20 枠( 80% )以上埋まり率も調べてみたけど同じような傾向だった。

すべての情報を表にまとめると以下のような感じ。

2012 年 2013 年 2014 年 2015 年 2016 年
カレンダー数 42 230 311 510 530
25 枠埋まり (率) 27 (64%) 112 (48%) 142 (45%) 236 (46%) 125 (23%)
20 枠埋まり (率) 30 (71%) 129 (56%) 168 (54%) 281 (55%) 169 (31%)

最初の年を除いて、大体半分弱の全枠埋まり率、半分強の 20 枠以上埋まり率であるということがわかった。クラウドファンディングみたいに 12/1 までに枠埋まり率が 8 割に達しなかったらカレンダー不成立としたらどうかと思った。その方がスリルがあるしだるいアドベントカレンダーが量産されたりしないと思う。運営におかれましてはクラウドファンディング的システムの導入を検討してもらえたらうれしいです。あと携帯からも見やすいようにレスポンシブウェブデザインにして欲しい。

それにしてもだるい。


この記事はアドベントカレンダーだるい Advent Calendar 2016の三日目の記事でしたが一日遅れて書いています。四日目は空いていて五日目は ouka_puyo さんです。


追記 2019-09-22

2016 年の数字が 2016 年 12 月頃のものだったのでデータを取り直した。 2017 年、 2018 年のデータも追加してグラフも作ってみた。

カレンダー数 20 枠埋まり (率) 25 枠埋まり (率)
2012 42 30 (71%) 27 (64%)
2013 230 129 (56%) 112 (48%)
2014 311 168 (54%) 142 (45%)
2015 510 281 (55%) 236 (46%)
2016 567 300 (53%) 262 (46%)
2017 639 357 (56%) 300 (47%)
2018 832 460 (55%) 394 (47%)
Adventar 実数 Adventar 割合

こうして見ると 2 年目から 20 枠埋まり率と 25 枠埋まり率に大きな変化はないことがわかる。年数が経過するにつれてアドベントカレンダーに参加するユーザーの質が変化するのではと思ったが、 201X 年代でブログをやってる人となると結構変わり者でユーザーの質に変化はなかったのだろう。

| @WWW

Untitled

Docker で rep2 を動かす - portal shit!

なぜ 2016 年にもなって rep2 を使うのか。実は2ちゃんねるはほとんど見ていなくて、まちBBSを見ている。特に大人になってから他県から移り住んできたような人だと住んでる町に同級生や昔からの知り合いというのがいないので町のちょっとした情報というのがきわめて入って来にくい。近所の人たちは自分の親かそれよりも上の世代の人ばかりなのでなかなか気軽に情報交換するということもできない。となるとネットで情報収集したいと思うけど、そういうのができる場所はまちBBSしかないような気がする。

ブログは今どきやる気がある人しかやってないので情報が少ない。情報あったとしても福岡だと天神だとか博多だとか薬院だとか人が集まる場所の情報がほとんど。自分が住んでる町の情報にはなかなかたどり着けない。 Twitter は検索しても出てくる情報にばらつきがある。たとえば住んでる町の名前で検索しても、同じ地名が横浜や姫路にあったりして効率が悪い。そもそも Twitter は町の情報よりもその人の思ったこと、感じたこと、やってることがメインなので効率的に情報を収集できない。 Facebook は基本的に情報が閉じられているし、知らない人から情報を集めるというより知ってる人の近況を読む場所という感じ。 mixi はどうだろうかと思って、 10 年ぶりくらいにアカウントを作って自分が住んでいる町のコミュニティに参加してみたけど誰も人がいなくて閑古鳥が鳴いてた。

今年の梅雨頃、マチマチというウェブサービスできて地元の人とお店や病院の情報などをやりとりできるという話だったので、これこそ求めていたものだと思って飛びついたけど、お前がこの町の最初のユーザーだから一ヶ月以内に 5 人ユーザー集めろや、できなきゃマチマチ上のコミュニティは閉鎖な、という厳しいルールだった。嫁さんはこういうのは一切興味ないし近所の人はじいさんばあさんばかりなので当然 5 人もユーザーを集めることはできず終了した。そもそも近所に知り合いがいないからネットで情報を集めたいと思ってるのに知り合いはお前が人力で集めろというのは難易度が高いと思う。

まちBBSは30代以降みたいな人たちが皆好き勝手に自分が書きたいことを書いているけど、最近できたあの店はどうだとか、あそこの病院はよくないだとか、どこそこの店が閉店して別の店になる、移転する、などのような情報を仕入れることができる。当然匿名掲示板なので嘘やネイティブ広告(工作員による宣伝投稿)も時々はあるけど、まぁ読み手もそれは織り込み済みなので特に問題はない。少なくとも SNS よりかは格段に情報に触れやすい。掲示板はトピックが決まっていて、多少脱線することはあってもそのトピックについて話すので、福岡の今宿の話かと思っていたのに横浜の今宿だったみたいなことはないし、失恋してつらいさみしい、今年の夏に別れた彼氏と行った今宿の花火大会の写真です、みたいなおセンチツイートを目にすることもない。 2016 年になったいまでも掲示板が一番情報を集めやすいのかもしれないなぁと思った。

| @WWW

VPS 上で Docker を動かし、 rep2 1 入りのコンテナを運用するようにした。

ホストの 81 ポートをゲストの 80 ポートに向けてマッピングし、ホスト側の Nginx で localhost:81 にプロキシするようにした。

まちBBS のスレッドの >>1 の記事があぼーんになる現象を直したので快適に閲覧できるようになった。

https://github.com/yaasita/docker_rep2 を docker hub から pull してきて最新版の rep2 を使うようにちょこちょこっと修正し、共有ディレクトリ内のコンテンツを /var/www に置くように修正した。なのでホスト側で PHP を編集したものがゲスト側に反映されるし、コンテナを落としてもデータが残り続ける。最高便利。

Docker 、これまでなかなかユースケースが思いつかずいまいち便利さがわからなかったのだけど、手元に PHP 入れたくないとかごちゃごちゃしたセットアップしたくないとかいうときに異常に便利。 rep2 のようなレガシー PHP 環境が必要なソフトを動かすのにもってこいだと思う。

このブログも Docker で運用できないか考えてみたい。


  1. PHP 製のサーバーインストール型2ちゃんねるビューアー。 

| @技術/プログラミング

むかしやってた映画のブログ( WordPress )のデータをこのブログに取り込もうとしたら、 mysqldump しといたデータが文字化けして読めなかった。 映画ブログのデータベースの文字コードは utf-8 にしてたけど、 Dreamhost の MySQL サーバーの defualt-character-set がおそらく latin1 になっていたと考えられ、 mysqldump するときに utf8 のデータが latin1 として export されてしまい文字化けを起こしていたっぽい。

vim で開いて e ++enc=utf8 してみたり、 nkr で変換しようと試みたり、ググって出てきた Perl のスクリプトで変換しようと試してみたけど直らなかった。この変換は MySQL 自身にやらせないとダメなのではと思い、以下を試したがダメ。

  • [x] latin1 で DB 作成し latin1 で import 、 utf8 で export
  • [x] latin1 で DB 作成し utf8 で import 、 utf8 で export

結局、 Stack Overflow にあった以下の方法で解決できた。

一旦文字化けしたまま utf-8 の文字列として import し、以下の SQL を流す。

UPDATE [table_name] SET [column_name] = CONVERT(BINARY CONVERT([column_name] USING latin1) USING utf8);

やっぱり MySQL で化けたデータは MySQL で直すしかないみたいだった。