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

Make admin page smartphone friendly · Issue #225 · lokka/lokka

Lokka の管理画面をスマートフォン対応させた。携帯から記事を投稿したりスパムコメントを削除したいなと思うことがあっても Lokka の管理画面はモバイルフレンドリーではなくて非常に厳しかった。とても便利になったと思う。ドッグフーディング最高。

専業フロントエンダーではないのでマークアップと CSS コーディングは適当だけどこの様に寝床でごろんとしながらでも駄文を投稿できるようになって便利。 Lokka ご利用中の方はご活用ください。

ダッシュボード

記事一覧

投稿画面

Rusted windown flame

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

できる Mac OS X Advent Calendar 2015 - Adventar

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

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

Soulver と Calca - portal shit!

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


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 さんです。

Untitled

Docker で rep2 を動かす - portal shit!

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

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

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

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

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ちゃんねるビューアー。 

乗るしかない、このビッグウェーブに、という感じで Let's Encrypt を使って無料の証明書をゲットし、ブログを https で公開するようにした。

証明書の設定とか難しそうで敬遠してたのだけど、実際やってみると思ったより簡単だったが、いくつかはまりポイントあったので書いておきます。

自サイト内の 'http://' を 'https://' に書き換える

CSS やテンプレート内で http://hogehoge.com となっているところを //hogehoge.com に変える。本文中の画像の URL も 'https://' に書き換える。ちまちました作業。 Amazon の画像の URL も https に対応したドメインに変えないといけない。

S3 に独自ドメイン当てて使っている場合、ここも証明書がいる

画像は S3 から配信していて、独自ドメイン( resources.portalshit.net )を当てて使ってたんだけど、ブログ本体を SSL にしたのに画像配信サーバーとの通信が非 SSL なので mixed content といって怒られる。

S3 単体で独自ドメインを使って SSL 通信することはできないので、 CloudFront を経由して CloudFront に Let's Encrypt で作った証明書を登録して使う。この S3/CloudFront 用の証明書の発行・登録のプロセスが若干面倒くさい。更新のときに手順忘れてそうで心配。 Let's Encrypt プラグインを使うようにした方がよさそう。

他、 Route53 で CNAME 当てて S3 に向けていたのを CloudFront を向くように変える必要もあり。

個人ブログごときで CloudFront を使うことになるとは思わなかった。

Lokka の管理画面が SSL 通信に対応してない

やっと mixed content の警告消えて記事を書こうとしたら、なんと管理画面が SSL 非対応でブログにログインできない。 Padrino の url メソッドが protocol の指定を出来ないようだった。オーバーライドとか試してみたけどうまくいかなくて困ってたところ、 rack-ssl-enforcer という gem を発見した。こいつを RACK_ENV=production のときだけ use するようにして乗り切った。 'http://' となってるのを Rack 層でえいやっと 'https://' に書き換えてくれる。

感想

Let's Encrypt 、本当に簡単で最高便利だと思った。オレオレ証明書発行するより楽っぽい。いい世の中になったと思う。ただ有効期限が短いので更新を忘れないようにしないといけない。更新の自動化までやってしまいたい。

ウェブサーバーを Nginx から H2O に変えるのとかまでは手が回ってないので自動更新と一緒にやりたい。

Google Reader 死んだ後、 The Old Reader 使ってる。 Feedly は高すぎてとてもじゃないけど使えなかった。無料で使うという手もあるけど、自分にとってフィードリーダーは気になるブログを放り込んどいて斜め読みし、後からおぼろげな記憶を頼りにキーワード検索して情報にアクセスする場所なので、全文検索できなかったら意味なかった。なので当然有料プランを利用することになる。

The Old Reader のプレミアムアカウントは安くて、初年度は年間 10 ドルで使える。見た目もスッキリしていてその名の通り古き良き Google Reader を彷彿とさせる。前 Feedly をちょっと試したときは UI がリッチすぎて重く使いたいという気にさせられなかった。このくらいシンプルな方がフィードのコンテンツを読むという用途には向いてると思う。購読対象のブログの UI がリッチすぎるので中身だけ手っ取り早く読みたくてフィードリーダーを使っているのだから、フィードリーダー自体の UI がリッチになっていったら本末転倒感ある。少なくとも自分にとっては。

The Old Reader はフィードの更新間隔がクソで、プレミアムアカウントのユーザーが登録しているフィードは 30 分おきにフィードをフェッチするとあるんだけど、全然そんなことなくて、平気で 4 時間遅れたりする。偏りがあって、頻繁に更新されるブログのフィードは頻繁にチェックされるけど、頻繁に更新されないブログのフィードはあまりチェックされないみたい。クローラーのつくりとしては正しいのかもだけど、利用者としては不満が残るなぁ。