カバレッジ
最近考えていることです。
カバレッジいちいち自分で取るのは不毛だから外部サービス使ってGitHubに出てくれるのが一番いいと思ってる
— いとおちゃん (@i315chan) August 23, 2018
YAPC::Okinawa 2018 ONNASON に行った
3月3日に行われたYAPC::Okinawa 2018 ONNASONに行ってきた。「ブログを書くまでがYAPC」とずーっと思ってたから今書くぞ！
YAPC::Asiaのときは毎年行っていたけど、YAPC::Japanになってからは初参加だった。そもそも沖縄に行くのが初体験だったのでずっとワクワクしてた。
初めての沖縄
沖縄には1週間前からインターネットの知り合いたちと居た。沖縄本島の北端や島などいろんなところに行って、とにかく楽しめた！！
これは沖縄本島最北端の辺戸岬の様子です。
これは沖縄の橋です（ここらへん）。
前夜祭
チケット買うのを完全に忘れていて、行きそびれた。東京でやってたときのヤップシーより積極的に情報収集に動かないと負けるので気をつけましょう。
本編
いくつか印象に残ったトークがあった。タイトルと発表者はサイトのものです。
HTTP/2にまつわる事実と誤解 Kazuho Oku
Fastlyという大きなCDN事業者だからこそできる膨大な検証をしているなという感じだった。ときどき遅くなるというのは、なんとなく知っていたものの、ここまで計測したグラフなど示されるとフムーとなるのでよかったです。HTTP/2にある機能はまだまだ知らないものもたくさんあるので機会があれば使ってみたい。
GUEST: 新屋 良磨
正規表現のあいまい性により、Perlの正規表現の方式ではめちゃくちゃ時間がかかるパターンがあり、難しいという話だった。こういうのはすごく数学が出てきて、理解はできなかったけどおもしろさは伝わってきた。聴いていて楽しいトークでした。
Inlineモジュールの世界 moznion
Inlineモジュールなるものを初めて知った。これはPerlのコードの中でCやJavaのコードを埋め込んで実行できるというものだった。Perlで書かれたプログラムの資産というものは大量にありそうだし、デモで紹介されていたPerlでNumPyを扱う話はおもしろかった。
Lightning Talks
まかまかさんがすごかった。LTの熱気は会場にいないとわからないから、カンファレンスに参加する理由のひとつかも。
これは会場の恩納村にある沖縄科学技術大学院大学のキャンパス内です。
懇親会
オリオンビール飲み放題ですごかった。沖縄の人ともうちょっと交流すればよかったのだけど、あんまり話せてなかったのが残念。
次回
次回はYAPC::Tokyo 2018らしい。沖縄からだいぶ遠くなってしまったけど、行きやすい。
感想
一緒に沖縄滞在していた人が「沖縄の若者」と評していた、沖縄のヒートシンカーさん（@codehex）を生で見れたのがよかったです。今回は話せなかったのですが、またいつかのYAPCでぜひ！！
xspfを連結するやつ作った
Chinachuを使っているとxspfをVLCから開いたりする。ザッピング的なことを行いたかったのでURLをまとめたxspfファイルを作るスクリプトを書いた。
使い方はこんな感じです
# Usage: ruby xspfjoiner.rb [xspf_file ...] % ruby xspfjoiner.rb *.xspf > channels.xspf
例です
% cat channel_a.xspf <?xml version="1.0" encoding="UTF-8"?> <playlist version="1" xmlns="http://xspf.org/ns/0/"> <trackList> <track> <location>https://example.com/path/to/channel_a.m2ts</location> <title>Channel A</title> </track> </trackList> </playlist> % cat channel_b.xspf <?xml version="1.0" encoding="UTF-8"?> <playlist version="1" xmlns="http://xspf.org/ns/0/"> <trackList> <track> <location>https://example.com/path/to/channel_b.m2ts</location> <title>Channel B</title> </track> </trackList> </playlist> % ruby xspfjoiner.rb *.xspf > channels.xspf % cat channels.xspf <?xml version='1.0' encoding='UTF-8'?> <playlist version='1' xmlns='http://xspf.org/ns/0/'> <trackList> <track> <location>https://example.com/path/to/channel_a.m2ts</location> <title>Channel A</title> </track> <track> <location>https://example.com/path/to/channel_b.m2ts</location> <title>Channel B</title> </track> </trackList> </playlist>
REXML::Formatters::Pretty を使うとそのままできれいなXMLができる。だがしかし、それだとタグの中にスペースが入ったりするとVLCがスペース入りのURLを開こうとしてしまっていたので、widthオプションに適当に大きめの数字を指定すると改行されなくなるのでそうした。
ちなみに、 REXML::Formatters::Default だと何もせずにVLCが扱えるXMLを吐くけど、終了タグと開始タグが1行になるなど、それはそれでちょっといやだったのでがんばったのがこだわりポイント。
最近Webサービスを気軽に作ることができなくなった気がする
昔話
昔（2009〜11年くらい）はみんなTwitter APIを使うだけのWebサービスを大量に作ってた。ブラウザで動くTwitterクライアントだったり、診断系だったり、あとはTwitterとなんかのAPIをマッシュアップ（死語）させるやつを作ってた。最近の若者は、あんまりWebサービスを作ってインターネットに公開していないような気がする。今はアプリ開発の人もいるからそっちに流れてるのかもしれないけど。
気軽に作れない理由
これは結論から言ってしまうとWebサービスを作って公開するのに考えることが増えたという話だ。
Webサービスを公開するのに、最低限ローカルの開発環境とWebサービスをホスティングする環境（自宅サーバ、VPS、IaaS、PaaS、なんでも良い）の2つがあればよかった。今もそうだ。でも、今はそれだとダサいと言われるようになってしまった。
Ansible, Chef, Itamaeのようなプロビジョニングツール、それはそんな難しくないけど、Dockerでコンテナ仮想化、それにともなって実行環境もECSだったりGKEだったり使うとかっこいいみたいな感じになっている。何が言いたいのかというと、Webサービスを作って公開して10人でも100人でも使ってくれることに喜びを感じるまでのプロセスが長い。これは完全に個人の意見なのですが、一部のエンジニアは心が狭い人がいて、オシャレな構成になってない状態で公開してもDocker使ってないと笑われたりするかもしれないですよね。そんな気持ちでWebサービスを公開したいわけじゃない。
あとは技術以外にも最近プライバシーのことでいろいろ言われるようになって、ちょっとむずかしいことをしたくなったら利用規約やプライバシーポリシーをちゃんと書かないと危なかったりする。雑なサービスが作りづらい。つらい世の中だ…。
どんどんやってみて欲しい
このエントリは自分に対する戒めの気持ちも込めて書いている。作りたくなったらその気持ちは大切にして、どんなしょぼいアーキテクチャだろうがスケールしないシステムだろうがとりあえず作ってみたらいいと思う。
僕自身もまだDocker完全に使いこなせないし、頭ではわかっているつもりでもどういうコマンドを打ったら期待通りに運用できるのか全然わからない。構成管理ツール、仮想化、難しいと思うならとりあえずやらなくて大丈夫。最初からAWSやGCPでイケイケな環境で動かそうとかしなくていいと思う。VPS借りるとか、まあVPSはちゃんとセキュリティ対策しないと全方位に迷惑かけるのでそれも難しいようであればレンタルサーバを借りてめちゃくちゃ負荷かけて怒られたらいいと思う（個人の意見です）。
プログラミング言語だってなんでもいい。PHPが簡単だと思うならPHP使えばいいし、Rails使ってバカにされようが、Webサービスのアイディアを思いついたもん勝ちで、公開しないのが一番よくないことっぽい。
がんばりましょう！！
最後に
ところでなんでこんな話書いたのかというと、最初にも言ったけどあんまりWebサービス作ってる若者いないなぁと思うからです。このエントリでいうところの若者とは、中学生〜高校生くらいでプログラミングを趣味でやってる人たちのこと。最近みんなアプリばっか作ってるよね。アプリのほうが覚えることは多くてもみんなそれ覚えてるので、学習するのが簡単になっている気がする、シュッと作って雑に公開できるのは一昔前はWebだったけどいまはアプリになっている。アプリもいいけど最近Webサービス作りたくなったのでどんどんやっていくぞ。
日付で管理する最悪なバージョン管理システムを作った
授業の課題をCで書いて提出しないといけなかったので、最悪なバージョン管理システムを作りました。
システムプログラミング基礎で発表した最悪なバージョン管理システムの詳細です https://t.co/mHth1drYaj
— いとお (@i315) 2016, 1月 16日付ベースのバージョン管理であれば、誰でもファイルを覗くことができるでしょう。上司がバージョン管理システムなんて使いたくないと言っているような職場でも安心して使えますね。
Date version control で dvn です。QWERTY配列では s と d は隣同士にあり svn と打とうとするとタイプミスを誘発しやすいため、それを狙ったコマンド名にしています。
流れ
% dvn
dvn - Date version control
Usage:
dvn init
dvn commit [message] [file]
dvn log
dvn initでカレントディレクトリに.dvnディレクトリを作るdvn commitでコミットしたいファイルとメッセージを指定してコミットdvn logでコミットログを参照
コミット間の差分は、diff を使って頑張るという感じです。ディレクトリ同士で diff を取ればそれっぽくなります。
まとめ
作ってみてわかったのが、日付によるバージョン管理は人類を破滅させるのことにつながりかねないのでやめたほうがいいですねということです。
% dvn init
Initialized dvn repository.
Recommend: Initial commit `dvn commit 'Initial' *`
% ls -a
./ ../ .dvn/
% echo "foo" > a
% dvn commit 'Add a' a
Commit 2016-01-16T16:16:58+0900: Add a
% tree -a .dvn
.dvn
└── 2016-01-16T16:16:58+0900
├── .dvn.metadata
└── a
1 directory, 2 files
% echo "bar" >> a
% dvn commit 'Update a' a
Commit 2016-01-16T16:17:20+0900: Update a
% dvn log
2016-01-16T16:16:58+0900: Add a
2016-01-16T16:17:20+0900: Update a
% tree -a .dvn
.dvn
├── 2016-01-16T16:16:58+0900
│ ├── .dvn.metadata
│ └── a
└── 2016-01-16T16:17:20+0900
├── .dvn.metadata
└── a
2 directories, 4 files
% colordiff -r -u .dvn/2016-01-16T16:16:58+0900 .dvn/2016-01-16T16:17:20+0900
diff -r -u .dvn/2016-01-16T16:16:58+0900/.dvn.metadata .dvn/2016-01-16T16:17:20+0900/.dvn.metadata
--- .dvn/2016-01-16T16:16:58+0900/.dvn.metadata 2016-01-16 16:16:58.000000000 +0900
+++ .dvn/2016-01-16T16:17:20+0900/.dvn.metadata 2016-01-16 16:17:20.000000000 +0900
@@ -1 +1 @@
-Add a
\ No newline at end of file
+Update a
\ No newline at end of file
diff -r -u .dvn/2016-01-16T16:16:58+0900/a .dvn/2016-01-16T16:17:20+0900/a
--- .dvn/2016-01-16T16:16:58+0900/a 2016-01-16 16:16:58.000000000 +0900
+++ .dvn/2016-01-16T16:17:20+0900/a 2016-01-16 16:17:20.000000000 +0900
@@ -1 +1,2 @@
foo
+bar
Let's Encryptとnginxでお金をかけずにHTTP/2サーバを立てる話を書いた
最近話題のLet's Encryptを使って無料でSSL証明書を取得し、最近のnginxでHTTP/2サーバを立てる話を書きました。ピクシブ株式会社 Advent Calendar 10日目の記事です。
Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive]
この記事を書いた経緯
皆さんはWebサービスで一発当てたいと考えたことはないでしょうか。私はあります。Webサービスで一発当てるためには、もちろんアイディアも重要ですがサービスの信頼性も大切です。今時、HTTPSで暗号化されていなかったり、オレオレ証明書でHTTPS通信を実現しているページに誰が個人情報を入力しますか？HTTPSに対応するには、証明書を買う必要があり、どんなに安くても年間3000円くらいはします。
いいドメインを取ろうとして、イケてる横文字のgTLDで取ろうとするとだいたい年間の維持費が高いです。公開したWebサービスが軌道に乗り始め、それで1年で3000円とドメイン代以上儲けることができればいいでしょう。しかし、大失敗したときはどうでしょう。大損です。
革新的なシステムを持ったLet's Encryptはなんと無料でドメイン認証（DV）証明書を得ることができます。最高の証明書を無料で得て、どんどん小金を稼ぎましょう。
技術ブログ作った
http://itochan.hatenablog.com/ は技術の話を書きます。 http://itochan.hateblo.jp/ は技術以外の話を書きます。
