2015年12月15日
初RubyKaigi
地域RubyKaigiも参加した覚えがなくって、これが初めてのRubykaigiでした。
発表の内容とかはtogeterなど見ればわかると思いますし、それぞれについて感想を書くのも疲れたので、印象に残っていることを書きます。
matzと迷子になる
1日目、道がわからないままに新橋駅から歩いていると、偶然matzをお見かけしたので、声をかけて道をご存知か尋ねたら知らないとこのことでした。2人でgoogle mapを見ながら歩いて、道を間違えて引き返したりしました。天候の話くらいしかできませんでした。
hsbtさんに直談判する
1日目にruby 2.3.0-preview2がリリースされましたが、それ関連で、あることが気になり始めました。
経緯
僕はrbenv-default-gemsを使っているのですが、これ、default-gemsの置き場が.rbenv/直下なんですね。で、何が困るかというと、rbenvの更新のたびにuntracked fileの表示が出てうざったいのです。じゃあ.gitignoreに追記すればいいじゃないかという事も考えました。しかし、rbenvのいちプラグインにすぎないrbenv-default-gems(それでも作者は同一人物ですが)のファイルの都合を、rbenvが見るのは違うと思います。なので、default-gemsの置き場を.rbenv/plugins/rbenv-default-gems/にして、rbenv-default-gemsの.gitignoreにdefault-gemsを追加する、というのが筋の通った実装だと考えました。
さてそんなPull Requestでも書こうかと思っていると、なんとすでにその前段階とも言えるPull Requestが存在しました。
Allow overriding default-gems location by cdlm · Pull Request #4 · rbenv/rbenv-default-gems
しかし、rbenv-default-gemsは最後のcommitが2013年4月で、このissueAbandoned? · Issue #13 · rbenv/rbenv-default-gemsにも全く反応がありません。停滞しています。
なので、ruby-buildにcommitしておられるhsbtさんにそのへんどうなってるのか直談判しに行きました。後で気づいたのですが、僕はてっきりrbenv organization が爆誕 - HsbtDiary(2015-11-26)を読んでhsbtさんがメンテナになったと思い込んでいたのが、よく読んでみるとメンテナはmislavさんでした。
それでもhsbtさんは僕の話を聞いてくださり、mslavさんに伝えておくとの好意的な回答をしていただけました。hsbtさんありがとうございます。
スタートアップの若者です。
koicさんとなかよくなる
koicさんは弊社と何かと関わりの深い(参考spice life様と合同勉強会を開催しました - 株式会社永和システムマネジメント アジャイル事業部)永和システムマネジメントさんの方なのですが、何かと予定が合わず今までお会いすることができませんでした。お会いできて良かったです。rubykaraokeではお世話になりました。
感想
- Rubyだいすき
- Railsだいすき
- プロジェクトの停滞きらい
- 御社ステッカーすき
- LTとか発表いっぱいしていきたい
とにかく界隈に知り合いがほとんどいなくて、気持ちがつらいというのがあります。僕は「きっと何者にもなれないお前たち」の「お前たち」のほうなので、とにかく人前に出て行かないと知ってもらえる機会なんてないんですね。
というけでせっせと手を動かしてなんか作って顔を出していきたい気持ちが高まっています。よろしくお願いします。
そして、発表者の方々、スタッフの方々、楽しい時間をありがとうございました。
追記
hsbtさんに直談判した件、こんな感じです。これに加えて自分でもPull Requestを送りたいと思います。
2015年11月24日
それは今年の5月のこと
smartnews社でのパーティーで、今年の抱負として「rubygemを2つ作ります」と宣言したのを、僕以外に覚えている人がいるでしょうか。
まあそれでも人は宣言したことはやるので、まとまった休みに重い腰を上げて人生初rubygemの制作に取り掛かりました。
その当時からgemにするならあれとあれ、というのは決まっていたのに、半年も先延ばしにするとは……
rubygemの作り方
$ gem install bundler
$ bundle gem gem_name
これで雛形は出来上がりです。あとはやっていきましょう。
rubygems.orgにアカウント作ってもcredentialを落とすところはないし、あちこちに書いてあるAPIへのリンクやドキュメントもないのでそこは少し手間取りました。書いてあるそのままを実行すればよかったです。
ceifpar
unasuke/ceifpar
これはRubyとrmagickでjpegのexif削除、サイズ変更ツールを作った話をgemにしたものです。
コマンドライン上でのみの操作だったものをメソッドに切り出し、テストを書いてgemの形に仕上げました。もともとがgemでなかったものをgemにしたので、commit logを見ればgemの作り方がなんとなーくわかるんじゃないかなと思います。そんなところまでわざわざ見る人はいないでしょうが。
ruboty-shibuyarin
unasuke/ruboty-shibuyarin
これはRubotyプラグインを作成したもので、まだ未完成(セリフの追加が終わっていない)ですが呼びかけに対しての応答はできるのでとりあえず出してしまえ、という感じのものです。テストの書き方がわからない。
テスト
それぞれでtest frameworkが違います。ceifparはminitestで、ruboty-shibuyarinはrspecです。まだまだどちらが書きやすいとかはなく、どっちにしてもどう書けばいいかでうんうん悩みながら書いています。
ceifparの方は画像を加工するので、testデータとして画像を持っておくべきかどうか考えましたが、画像の加工に関してはrmagick(imagemagick)を使用しており、どちらかと言うと責務はこちらにあるものではない、と判断しました。なので、ceifparの方のテストはjpeg判断と比率正規化のもののみとなりました。
rubotyの方はいろいろな方のリポジトリを見ましたが、どうにも呼び出しがわからず、今後の課題とします。
gemを作ってみて
終わらせると「こんなものか」と拍子抜けしますが、やってみる前は右も左もわからない状態でした。
こんな規模のgem、作れたところで自慢にも何にもならないのでしょうが、初心者からすると偉大な一歩に思えるものです。仕事でRails触り始めてもう1年が経とうとしている人が初心者を名乗るのもおかしいですが。
でも僕にとっては大きな一歩だと思っています。よっしゃやったるでという感じ。
とりあえず宣言したことをやり遂げたので満足です。あとセリフ追加します。
2015年11月23日
まずはdeploy方法
さてmiddlemanでbuildした記事は、どこかにdeployしないと公開されません。github pagesでもいいですし、herokuでも、Amazon S3でもいいでしょう。
ただ、僕はさくらのVPS上でh2oを動かしているので、それにそったdeployをする必要があります。
middleman-deploy
どのような方法でdeployするにしても、middleman-contrib/middleman-deployを使うことになると思います。これは便利です。
rsyncを用いてdeployしようと思い、このような設定をconfig.rbに書きました。
activate :deploy do |deploy|
deploy.method = :rsync
deploy.host = "blog.unasuke.com"
deploy.path = "/var/www"
deploy.user = ENV["MIDDLEMAN_USER"]
deploy.port = ENV["MIDDLEMAN_PORT"]
deploy.flags = '-rltgoDvzO --no-p --del'
deploy.build_before = true
end
deploy.userとdeploy.portが環境変数になっているのは、一応このblogのリポジトリは公開になっていて、この設定も誰でも見られるようになっている状態で、sshが繋がるポートを明記するのが危険だからです。
この状態で、
$ bundle exec middleman deploy
を実行すると、buildされ、deployされます。
自動化
さて、これをいちいち手でやるのは面倒です。なので、CIサービスを使って自動化してやります。今回はCircleCIを選びました。理由は使い慣れているからです。
とはいっても、masterにmergeされたら自動でdeployくらいの設定なら、こんなにも書かなくてよく、多分、ただdeploymentの項目だけ書けばいいと思います。
machine:
timezone: Asia/Tokyo
ruby:
version: 2.2.3
dependencies:
pre:
- gem install bundler -v 1.10.6
override:
- bundle install --jobs=4
test:
override:
- bundle exec middleman build
deployment:
publish:
branch: master
commands:
- bundle exec middleman deploy
ただ、よくわからないのは、この場合testとして何を実行すればいいのか、ということです。今はbundle exec middleman buildが成功することをテストのpassと見なしていますが、Circle CIではこの前段階にcompileとしてmiddleman buildが行われてしまうので、2重にmiddleman buildが走ってしまい、時間の無駄です。(さらに、deploy.build_before = trueなので、計3回のbuildが走り時間の無駄)
まとめ
2015年11月08日
What’s “つよい”
See the Pen verbose style sheet by Yusuke Nakamura (@unasuke) on CodePen.
例えば上のようなCSSは、bootstrapも使っていない、Sassも使っていないので、次のように書き直せると思う。めんどいのでSlimも使う。
See the Pen better style sheet by Yusuke Nakamura (@unasuke) on CodePen.
さて、これも.boxの中のclassにも.boxが先頭についていて冗長、共通化できそうなものを切り出してこう書くとしたら。
See the Pen more better style sheet by Yusuke Nakamura (@unasuke) on CodePen.
さて3段階にわたってCSSを綺麗にしたつもりだが、まだまだ改善できるところがあるかもしれない。「つよいCSS」というのは、破綻しにくく、変更に強く、とにかくつよいCSSのことだ。
CSSをもりもり書いたここ数週間
ここ数週間は、ひたすらCSSを(Sassを)もりもり書いていて、とにかく上に書いたようなことを意識しながら作業していた。途中で以下の本を買ってもらって読んだ。
作業の途中で読んだので、CSSの書き方がページによって変わってしまった(後でなんとかした)。とはいえまだ読みきれてはいないし、書き方を意識したとはいえど、まだまだな点も多い。
classの名前も悩む。どこからどこまでを1つのclassでまとめるべきか判断がつきにくい。複数のページで共通化できるのはどの要素だろうか。これはこのページ限定のスタイルだろうか。paddingであるべきかmarginであるべきか。そもそもこれはbootstrapで用意されているから書く必要はなかった。思い通りの値にならないと思ったらあっちのスタイルが適用されていた。こっちのグレーとそっちのグレーは違う色だった……
Photoshopとエディタとブラウザを何度も行ったり来たり、見比べたり、カラーコードをコピペしたり。とにかく大変だった。でも見やすくなったと思うし、キレイになった。
CSSの設計
BEMやSMACSSなどのCSSの設計についての指針はある。だが、専属のフロントエンドエンジニアがいない現状では導入は難しい。bootstrapを使っておおまかにレイアウトし、それなりにページごとに分けたSassで無難な名前のclassでスタイルを書いている。何人もがCSSを書いているので、書き方に差異もある。最近書いていくぶんには破綻もあまりないけど、消しきれていない昔のCSSのために打ち消すスタイルもあったりなかったり。
CSS
CSS難しい。いっぱい書けばできるようになるんだろうか。
2015年10月23日
Fitbit Chargeとは
一言で言ってしまえば高性能万歩計だと思います。
Fitbit Charge™ ワイヤレス活動量計・睡眠計リストバンド
隣の席の人が買ってて羨ましくなったので買いました。
使ってみての感想
つけごこち
もともと鬱陶しいからと腕時計をせずに今までの人生を歩んできました。そこに突然こういうものを身につけ生活するようになると、とても違和感があります。
まずノートパソコンのキーボードが使いづらいです。手首をべたりと密着させながらキータイプするほうなので、左手が動かしにくいです。金属製の留め具で傷をつけるのもいやですし。
なので、Tex Yoda(外付けキーボード)を使うことが一気に増えました。持ち運びも運動になるしいいのかも……
大きさはLでちょうどいい感じです。
情報
僕がFitbit Chargeで一番魅力的だと思っている機能は、睡眠時間の計測とアラーム機能です。特に何も設定しなくても、睡眠を自動で感知して記録してくれるので、自分が何時間眠ったかなどがわかって便利です。
他にも、登った階数、歩数、距離を自動で計測してくれます。歩数は、同期している状態で歩くとリアルタイムに数値が更新されていくので見ていて楽しいです。
とれない情報
Fitbit Chargeでは、心拍数、体重、体脂肪率、摂取カロリー、摂取した飲料の量は計測できません。自分で入力してやる必要があります。体重と体脂肪率(身長を設定しているとBMIも)くらいは1日にそう何度も量らないので、都度入力してやるのはいいとします。しかしそれ以外の摂取カロリーなどの値はまったく計測できません。自分で入力してやればいいとしても、それはちょっと面倒すぎると思います。
いつか体内に機器を埋め込んでこういう値も取れればいいな……
まとめ
いろいろな数値が可視化されるのは見ていて楽しいです。
来月の健康診断に引っかかりたくない……
2015年09月23日
wordpressからmiddlemanへ
wordpressからmiddlemanへの移行は、今まで(はてなダイアリーからtumblrへ、tumblrからwordpressへ)のお引越しとは違う、極めて大規模な物になることが予想されました。理由は、 「記事の移行が発生する」 からです。
むしろ何故いままでのブログ移転では記事の引っ越しをしていないか、という話ではあります。しかし、今回の移転は記事の移行が必要になる理由が2つありました。
維持費がかかる
wordpressはさくらのレンタルサーバー スタンダードを使って運営していました。これを残しておくとなると、月額515円の維持費が発生します。なので、新しいブログに移転するタイミングでサーバーを解約してしまいたかったのです。
アクセス数の多い記事がある
Slackに関する記事、windowsとubuntuのdualbootに関する記事などは定期的なアクセスが発生しており、検索流入もそれなりにあるのでぜひとも残したいという気持ちがありました。
移行にあたって考慮した点
以前の記事を残しつつ、新しくブログを作るにあたって考慮したのが、以下の項目です。
以前のURLからアクセスできるようにする
ありがたいことに、記事へのリンクを記載していただいているwebページもありました。それらのリンクを変更することなく新しいブログへ誘導させたいと思いました。
記事はmarkdownで書く
wordpressの頃は、markdownモードがあるにも関わらず、直接htmlを書くか、あるいはmarkdownで書いてからhtmlに変換して編集エリアにペーストしていました。それをやめ、すべてmarkdownで書くことにしました。
ブログの外見は自分で書く
すでに存在するテーマ等は使わず、自らSassを書いて一からデザインすることにしました。
最新の技術を取り入れていく
最新の技術を勉強する上で重要なのは、実際に使ってみることだと思っています。h2oの使用を決めたのも、この理由によります。
ブログ移行
それでは、ブログ移行までの道のりを綴っていきます。
現状確認
worpressで運営していたunasuke.comは、78個の記事、309の画像、日ごとに100前後のアクセス数をもつブログでした。ドメインはお名前.comで取得したものをさくらに登録して使用していました。主な流入は検索によるものでした。使用しているwordpressのバージョンは4.2系、有効になっているプラグインは13個ありました。
wordpressから、なにに移行するのか
静的サイト構築ツールはいくつも存在します。その多さはStatic Site Generatorsを見ていただけると分かります。僕が候補として考えたのは、以下の5つです。
Octopressは、その特徴的なfaviconで使用しているブログがすぐ分かります。あのfaviconが好きになれなくて使わないことにしました。Hugoは、記事生成のスピードが凄まじいと話題ですが、Goで書かれていることもあり、Goのエコシステムが未知なことと、今後の記事生成で不満が出てきたら乗り換え先として考えることにし、今回は使わないことにしました。SpinaはRails製CMSとのことで少し触ってみましたが、(unasuke/spina-test)ドキュメントが殆ど無いこと、そもそもCMSであることから使わないことにしました。最終的に残ったJekyllとmiddlemanでだいぶ悩みましたが、会社や所属するコミュニティでmiddlemanを使っていること、先輩にmiddlemanを勧められたことにより、middlemanを使用することに決定しました。
さくらのレンタルサーバーから、なにに移行するのか
レンタルサーバーをやめ、自由度の高いVPSに移行することは決めていましたが、その先は3つ候補があると思っています。
ConoHaは不安定であることが友人の使用例からわかっていたので使わないことにしました。AWSとさくらで迷いましたが、これまで使っている会社であること、信頼性に関して実績があることからさくらのVPSを使用することに決定しました。
Apacheから、なにに移行するのか
これについても3つの選択肢がありました。
これについては、最新の技術を取り入れていくという目標があるので、迷わずh2oを使用することに決定しました。
wordpressから記事と画像のエクスポート
記事の移行のために、wordpressから記事を移行する作業をしました。移行にはmdb/wp2middlemanを使用しました。エクスポートしたXMLを、
% wp2mm wordpress.2015-07-25.xml
とし、すべての記事について手作業でmarkdownに変換しました。markdownに変換する、以下の様なオプションもありましたが、試したところ画像の処理がうまくいっておらず、やはり手作業は必要でした。
% wp2mm wordpress.2015-07-25.xml --body_to_markdown true
また、画像も撮影した時点のファイル名となっていたのを、意味のある名前に変更、年ごとにディレクトリを分割などの作業を行いました。
体感では、この作業が一番長く時間がかかったように思います。markdownized · unasuke/blog@e0658de
middlemanの設定を整える
middlemanは素で使うのではなく、ブログ用の拡張であるmiddleman-blogを適用させて使うことにしました。記事のURLをwordpressの頃とほとんど変えないなどの設定をconfig.rbに書いていきました。他にも、livereloadの設定や、layoutの設定などを整えていきました。History for config.rb - unasuke/blog
サイトのデザインをしていく
デザインをする上で、以下の条件をつけました。
- 基本的に白と黒(に近い色)のみを使う
- Sassを使う
- 単位にはなるべく%を使う
これは、色が増えると調和を取るために考えなければいけないことが増えるのを避けるためと、画面サイズ、解像度になるべく依存しないようにするためです。Sassは慣れているし、bootstrapもSassに移行するとのことでAltCSSのデファクトスタンダードとなりつつある(ような気がする)からです。
また、会社のデザイナーさんに教わったことですが、白と黒(#fffと#000)の組み合わせはコントラストが強くて良くないそうなので、純粋な白、黒は使用しないことにしました。
結果的に現在のようなものになりましたが、これで決まったわけではなく、今後も修正は続けていきます。
web fontをどうにかする
web fontも興味があったので使ってみることにしました。どのフォントを使うにせよ、サブセット化(使う文字だけ収録されたフォントファイルをつくる)は日本語を使う以上は避けられないと考えました。3846masa/japontを使って動的にfontを生成しようかとも考えましたが、とりあえずはM+Web FONTS Subsetterを使うことにしました。それにあたって、ブログ内で使われている文字を抽出する必要があり、以下の様なスクリプトを使って文字を抽出し、web fontを作成しました。
VPS serverの初期設定
server OSにはUbuntu 14.04 LTS amd64を選択しました。
まずはOSのインストール、SSHの設定、iptablesの設定を行いました。
% sudo vim /etc/ssh/sshd_config
% sudo service ssh restart
% sudo apt-get install iptables-persistent
% sudo invoke-rc.d iptables-persistent save
h2oのビルド
以前の記事URLから、新しい記事のURLにリダイレクトさせるために、正規表現が必要になると考えました。具体的には、
# old url
http://unasuke.com/diary/2015/yapc-asia-tokyo-2015/
# new url
http://blog.unasuke.com/2015/yapc-asia-tokyo-2015/
このようになります。categoryがすべてtagに統一されたので、URLからcategoryを除いたものへとリダイレクトさせてやりたいのです。
まずは、h2oが素で正規表現を用いたroutingを行えるかどうか確認します。
# h2oのビルド
% sudo apt-get install locate git cmake build-essential checkinstall autoconf pkg-config libtool python-sphinx wget libcunit1-dev nettle-dev libyaml-dev libuv-dev
% sudo apt-get install unzip zlib1g-dev bison
% wget https://github.com/h2o/h2o/archive/v1.5.0-beta4.zip
% unzip v1.5.0-beta4
% cd h2o-1.5.0-beta4
% cmake -DWITH_BUNDLED_SSL=on .
% make
% sudo make install
% h2o -v
h2o version 1.5.0-beta4
OpenSSL: LibreSSL 2.2.2
はいりました。ひとまずexampleの設定を使って立ち上げてみましょう。
% pwd
/home/hoge/h2o-1.5.0-beta4
% h2o -c ~/h2o-1.5.0-beta4/examples/h2o/h2o.conf # conf内のpath指定があるので注意
これで8080番ポートにアクセスするといい感じになにか見れると思います。ちなみに、example/h2o/h2o.confを以下のように書き換えると、URLにポートを指定せずに接続することができますが、h2oの起動に管理者権限が必要となります。
# to find out the configuration commands, run: h2o --help
# 秘密鍵とかも消す
listen: 80
hosts:
"127.0.0.1.xip.io:80":
paths:
/:
file.dir: examples/doc_root
access-log: /dev/stdout
では、このyamlでワイルドカードが使えるかどうか試してみます。
# to find out the configuration commands, run: h2o --help
# 秘密鍵とかも消す
listen: 80
hosts:
"127.0.0.1.xip.io:80":
paths:
/:
file.dir: examples/doc_root
"/test/test":
file.dir: examples/doc_root
"/*/test":
file.dir: examples/doc_root
access-log: /dev/stdout
この設定でh2oを立ち上げたところ、/test/testにはアクセスができましたが、/hoge/testにはアクセスできませんでした(not found)。なので、mrubyなどでなんとかしてやる必要があると感じました。
ひとまず、mrubyをインストールします。
% sudo apt-get install mruby libmruby-dev
mrubyのインストールができたら、h2oをmrubyを使えるようにしてもう一度buildします。
% cmake -DWITH_BUNDLED_SSL=on -DWITH_MRUBY=on .
% make
% sudo make install
% h2o -v
h2o version 1.5.0-beta4
OpenSSL: LibreSSL 2.2.2
mruby: YES
なにも考えずにh2oの最新版Release H2O version 1.5.0-beta4 · h2o/h2oをbuildしたら、どうやらmruby拡張のAPIがRackベースのものに変更になったらしく、そのサンプルコードを動かしてみてもどういう動作をするのかが全く読めなかったので、Rack based APIに変わる前でvulnerability修正がされているRelease H2O version 1.4.5 · h2o/h2oを使うことにしました。
ひとまずexamples/h2o_mruby/h2o.confを以下のように変更します。
# to find out the configuration commands, run: h2o --help
listen: 80
# host名はサーバーのドメインに設定してもよい
hosts:
"127.0.0.1.xip.io:80":
paths:
/:
mruby.handler-file: examples/h2o_mruby/hello.rb
access-log: /dev/stdout
そしてアクセスすると、次のような文字列が返ってきます。
hello from h2omruby. User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10105) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.99 Safari/537.36 New User-Agent:new-Mozilla/5.0 (Macintosh; Intel Mac OS X 10105) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.99 Safari/537.36-h2omruby path:/ host:hoge method:GET query:
では、mrubyをつかって旧URLから新URLへのリダイレクトをさせるように、やっていきます。
まず、旧URLの形式ですが、次のようになっています。
http://unasuke.com/#{カテゴリー(diary,howto,info,review,about-me)}/#{記事公開年(2013から2015)}/#{記事タイトルっぽい英文}/
これに一致する正規表現を以下のように作成しました。
reg = Regexp.compile("(diary|howto|info|review|about-me)(/.*)")
さて、mrubyはrubyとは違い、組み込み向けなので正規表現は標準の状態では使用できません。mgemというmruby用のgemを組み込んでmrubyをコンパイルし直す必要があります。しかしh2oがbuildするmrubyには既にmattn/mruby-onig-regexpが組み込まれているので、正規表現が使えます。(気付かずに自前でbuildしてた)
class HelloApp
def call(env)
h = "hello"
m = "from h2o_mruby"
ua = env["HTTP_USER_AGENT"]
new_ua = "new-#{ua}-h2o_mruby"
path = env["PATH_INFO"]
host = env["HTTP_HOST"]
method = env["REQUEST_METHOD"]
query = env["QUERY_STRING"]
# この辺を追記
reg = Regexp.compile("(diary|howto|info|review|about-me)(/.*)")
result = "#{reg =~ path}\n $1=#{$1}\n $2=#{$2}\n"
msg = "#{h} #{m}.\n User-Agent:#{ua}\n New User-Agent:#{new_ua}\n path:#{path}\n host:#{host}\n method:#{method}\n query:#{query}\n"
[200,
{
"content-type" => "text/plain; charset=utf-8",
"user-agent" => new_ua,
},
["#{msg}\n\n#{result}"]
]
end
end
HelloApp.new
できました。これをドメインを見てリダイレクトさせるかどうか判断させ、さらに実際にリダイレクトさせればいいわけです。リダイレクトさせるには、301を返してやればいいので、このようになります。
class HelloApp
def call(env)
path = env["PATH_INFO"]
reg = Regexp.compile("(diary|howto|info|review|about-me)(/.*)")
result = "#{reg =~ path}\n $1=#{$1}\n $2=#{$2}\n"
[301,
{
"Location" => "https://blog.unasuke.com#{$2}"
},
[]
]
end
end
HelloApp.new
無駄な部分もありますが、実際にこれでリダイレクトができました。
このmrubyを使用した最終的なh2o設定ファイルは次のようになりました。
listen: 80
listen:
port: 443
ssl:
certificate-file: /hoge/path
key-file: /hoge/path
hosts:
"unasuke.com:80":
paths:
/:
mruby.handler-file: /home/blog/redirect.rb
"unasuke.com:443":
paths:
/:
mruby.handler-file: /home/blog/redirect.rb
"blog.unasuke.com:80":
paths:
/:
redirect: https://blog.unasuke.com/
"blog.unasuke.com:443":
listen:
port: 443
ssl:
certificate-file: /hoge/path
key-file: /hoge/path
paths:
/:
file.dir: /hoge/path
access-log: /hoge/path
access-log: /hoge/path
error-log: /hoge/path
pid-file: /hoge/path
あとは、middlemanでbuildした記事を適当なディレクトリに配置してやれば完成となります。(疲れたのでまた後で書きます)
参考
middleman
ubuntu
h2o
mruby
SSL
2015年09月23日
3回めの移動
はてなダイアリーから、tumblr、さくらのレンタルサーバー上のwordpressと渡り歩いてきた"うなすけとあれこれ"が、さらにもう一回引っ越しをしました。今回は、さくらのVPSとmiddlemanを組み合わせたものとなっています。
移動の理由
仕事でwebサービスを構築していくうちに、webサイトを構築する上で必要となる様々な知識が、以前と比べて格段に増えました。それに伴い、今までは用意された編集エリア、用意されたブログテーマには満足できなくなり、一から構築してみたい、という気持ちが大きくなってきました。
また、wordpressを使っていると、その管理が思ったよりも手間がかかるものであることがわかりました。定期的なアップデート、セキュリティ対策、壊れた時の対処などに振り回されるのには嫌気が差しました。
ということで、静的なhtmlを生成することによる懸念事項の減少、新しい技術の勉強なども兼ねて、middlemanでブログを構築することにしました。
移動の顛末
middlemanとh2oとVPSによるブログ構築
2015年08月24日
前夜祭
PHP帝国の逆襲！（を願うPHPerが話す最近のPHPについてのクイックツアー PHP7対応版）
PHPはこわくないよ PHPerが話す最近のPHPについてのクイックツアー #yapcasia #yapcasiaE - Togetterまとめ
途中で来て、最後の方だけ聞いていました。
PHP7が速いとか、最近のモダンなサービス(Slack)でもPHPを使っているところはまだあるとか、負債のない言語はないとか、グワッとつくり上げるにはやはりPHPでは？みたいな話でした。
自分はPHPは書いたことがなくて、使ってると言ってもWordpressぐらいなものですし(近々捨てる)、あまり興味が無いです。
けどこういうアツい人がいる言語、とても幸せものだなと思います。こういうでかいカンファレンスでD言語のアツい人とか見たこと無いもの……(需要を優先という面で見れば仕方ないのかもしれないけれども)
はてなブックマークのトピックページの裏側
はてなブックマークのトピックページの裏側 in YAPC::Asia Tokyo 2015
はてブのトピックページはこう作られている！ 中の人による実装解説 #yapcasia #yapcasiaE - Togetterまとめ
とんでもなく学術！って感じでした。形態素解析とか……うわぁ……わからないぞ
はてブ10週年とのことですが、使ってないです。
技術ブログを書くことについて語るときに僕の語ること
ホッテントリ入りの極意から哲学まで！ はてなエンジニアが語る技術ブログを書くことについて #yapcasia #yapcasiaE - Togetterまとめ
まとめると、
- タイトルが9割
- 先頭に話題の単語を持ってくる
- アメリカ、アカデミックは強い
- 平日の朝に投稿しろ
- 夜書いた文は朝読み直せ
- 哲学を持つ
- ブログは俺の場所
だいたいこんな感じなように思いました。
僕(ら)はやはり多くの人に読んでもらいたい文章を書くし、その指標のひとつとしてはてブ数を見ます。なので、はてブ数はあればあるほどうれしいものです。そのためにはタイトルとか工夫しないと読んでもらいづらいから、勉強になりました。
ssig33.com - Docker についてアメリカの大学で工学博士から英語で話を聞いてきました
一方で、
「先頭しか読まない」って分かってるならちゃんと人々がエントリ読んでいくような仕組み作るのがはてなのお前らの仕事なんじゃないのかと思って、それについても質問しようと思ったのだけどもう無駄だなと思って聞かなかった。
これも至極まっとうな意見だと思っています。タイトルによらず、いい記事はいい記事で、そういう小手先の細工でリーチしにくいとかしやすいとか本質ではないのでは？と思います。
「ブログは俺の場所」というのはすごく納得できるのです。じゃなきゃなんで僕ははてなダイアリーを捨てtumblrを捨て、わざわざ面倒でお金のかかるWordpress in レン鯖を選んだのだという感じです。俺の場所は俺が作る。
1日目
メリークリスマス！
Perlの父 Larry Wall が描く『指輪物語』 そしてメリークリスマス！ #yapcasia #yapcasiaA - Togetterまとめ
ちょっと遅れて入ったら同時通訳の機械がなくてウオーとなってました。
とりあえずLoRの映画とか小説読みたくなりました。
I FAIL GOOD
しましょう。
Effective ES6
Effective ES6
これからのJavaScriptを知ろう！ Effective ES6 #yapcasia #yapcasiaC - Togetterまとめ
はじめから柔軟性のある言語として設計されたのが功を奏したのかここまで広まったけど、反面罠や謎が多くなってしまったのでしょうか。開眼する必要まで出てきたJavaScript。
ES5から6年経ち、ES6では何が新しくなったのでしょう。
- Class
- Arrow function
- などなど
ではAltJSの立場はどうなるんでしょう？多分syntaxの好みぐらいになって、わざわざcoffeeを選ぶ理由もなくなっていくかもしれないですね。かといって最新のブラウザでES6はまだサポートされていません。だからbabel。
- Jqueryはどうなる → ライブラリの中は気にしない(そんなに影響はないmodule以外は)
- ライブラリを書く側は？ → npmでどれに準拠してるかわからないし調べるのも大変 完全にES5に準拠したものを公開がベター
- No more AltJSとは？ → 価値としては減ったcoffeeは大部分はES6でAltJS→仕様がでかい型とか
TypeScriptの立ち位置はまだでかいかも……でもどうせbabeるのならAltJS使おうがES6だろうが関係ないのかも？と思いました。この辺どうなんでしょう。
HTTP/2 & クラウド時代のウェブアプリケーション実行基盤
HTTP/2時代のウェブサイト設計
H2Oは先を行く！HTTP/2時代にむけたウェブサイト設計のポイント #yapcasia #yapcasiaD #http2 - Togetterまとめ
HTTP/2最高ですね。描画までが速いし、配信も速いし、とにかく速い。
はやくぼくのかんがえたさいきょうのブログをh2oでやりたいです。個人ブログのくせして暗号化とかめっちゃ頑張りたいです。無駄に差先端を走っていたいです。
Let’s Encryptのスケジュール、遅れているような？？
【sponsored contents】若手エンジニア達の生存戦略
若さは特権!?~若手エンジニアの生き方~#yapcasia #yapcasiaD - Togetterまとめ
- 個人としての発言は上に届きにくいからチームとして発言する
- 若手だから無責任なこと言っちゃえ→じゃあやってね
- 何故貢献するのか
- 業界として盛り上げていきたい
- ブログが役に立ったから恩返し
- 輪の中に入って行きたい
- 就活に有利
- Perlのモットーだから
- 情報を発信すると、情報が入ってくる
- 一生プログラマとして食べていけるのか
- 目の前の問題に必死になってるだけで、未来とかぶっちゃけよくわからん
- 楽しく仕事を続けていきたい
- 楽しく、でも楽じゃなく
papixさんは若手なのか……
言語は違えどだいたい感じてることは同じで、お金がほしいし貢献していきたいしいろいろなことに手を出していきたいし。
Electron: Building desktop apps with web technologies
WEB技術を使ってデスクトップ開発！Electronとは!? #yapcasia #yapcasiaA - Togetterまとめ
こんな大規模化カンファレンスで40MBのgit clone薦めてくるし正気かよ、と思いました。案の定回線は不安定になったようです。
Nuclide こんなのあったのか。
electronで何ができるのか、ということに始終徹した発表だったように思う。
クロスプラットフォームなデスクトップアプリも簡単に作れる時代になって、とてもいい。
esa.io - 趣味から育てたWebサービスで生きていく
esa.io - 趣味から育てたWebサービスで生きていく // Speaker Deck
趣味からサービスへ！esa.ioの中の人に学ぶプロダクト開発 #yapcasia #yapcasiaA - Togetterまとめ
とにかく開発の仕方の違いを思い知らされました。Heroku使っているのもあって、出先でスマホだけで変更のcommitからdeployまで出来るのは超カッコイイし、価値の提供がとにかく速いと感じました。
自分プロダクツも、たぶんURLを持つと意気込みや愛着が違うのでしょう。Herokuで自動生成されるstill-hoge-7828.herokuapp.comなんてURLのプロダクトに愛着が湧くでしょうか。
2日目
3分でサービスのOSを入れ替える技術
突然のCM放映に対応せよ！3分でOSを入れ替える技術 #yapcasia #yapcasiaE - Togetterまとめ
- 制限がイノベーションを生む
- 自由が利くと何でもやってしまいからダメ
- 一気にではなく、使えるもので置き換えながら楽にしていく
インフラをコードで表現していく、とにかく自動化できるように。
このノウハウ(Blue-Green deploymentなどなど)が必要になるくらいtmixも周知されたいものだなぁ。ばんばかスケールアウトしたいです。
ソーシャルゲームにおける AWS 移行事例
209分かかった処理を90分に!?実例に見る、RDS移行 #yapcasia #yapcasiaE - Togetterまとめ
Single-AZにした後からMulti-AZにするまでの変更も複数のAZに保管されるならまあ、一時的にはいいんじゃないでしょうか？
しかし稼働中のものを入れ替えるのは考えることが多くて大変(sessionの保存とか)だと思いました。
カンファレンスネットワークの作り方
YAPCの2000人をインターネットに繋げる!! CONBUが語るネットワーク構築舞台裏 #yapcasia #yapcasiaB - Togetterまとめ
カンファでのネットワーク、非常にありがたいもので、どのように構築しているのか気になったので見に行きました。
意外や意外、機材はconbu側が持っているとのことです。それで2000人規模のカンファに対応できるのすごいな……
コアネットワークのライブラリ化、クラウド時代の勝利という感じがします。
感想
前夜祭と2日目には銅鑼Tシャツを着て行きました。esaの方々、鶉さん、naoyaさん、その他いろいろな方に銅鑼を叩いていただけたので嬉しかったです。すみませんでした。
Perlと銘打っておきながら何もかもを受け入れるYAPCはすごいです。いろいろな方と交流出来ました。懇親会ではしらなかった分野の話、これからどうしていくべきななどの話、アレは本当にダメみたいな話をして、楽しかったです。なぜ僕は懇親会に銅鑼Tシャツを着て行かなかったのでしょう。本当に悔やまれます。
ちはみに、1日目と2日目の間に出来事がありました。LTぐらいはできそうな感じなので、どこかで話します。
さて、Beaconはどうなるのでしょう。
2015年08月19日
コミケ初体験
コミケの存在は知っていたけど、毎夏毎冬にまとめを読んだり大量のツイート群を読んだりで満足していました。
そこに、友人のふーゆた君がサークル参加するということなので、僕も売り子をするかわりにサークルチケットで入場させてもらうことになりました。
またそれとは別に、情報共有おじさんの発案によりコミケでtmixのチラシを配る事にもなりました。
よって、コミケ初体験で、サークル側、設営側、一般側の3つの体験をすることになりました。設営というのも違う気がするけれど。
-1日目 チラシ配布
とにかく疲れたのであまり思い出したくない。
1日目 売り子
目の前でドンドン新刊が消えていくのは見ててとても気持ちのいいものです。
この後にチラシ配りもありましたが、とにかく疲れたのであまり思い出したくない。
2日目 チラシ配布
2日目には参加せず、チラシを配るだけでした。とにかく疲れたのであまり思い出したくない。
3日目 一般参加
この日は音楽系のサークルがたくさんあるので、始発参加することにしました。
待機列はこんな感じでした。とにかく汗がどんどん出てきて体力がガンガン減っていきます。東から並んで、入場即西の壁サークルに向かいましたが、まったく並ばずに買えて(かめりあさんにCD渡してもらって、「がんばってください！」って言えて感激)最高の体験をしました。
昼ごろ、ぶらぶらしてたら突然「かにTの人ですよね！それ欲しいんですけど、どこで買えますか？！」みたいなことを聞かれました。ちなみにこんなTシャツです。
戦利品
CDが多いですね。まだ全然聴けてません。
感想
また行きたいです。
ふーゆた、はたっく、本当にありがとうございます。
2015年07月20日
あらすじ
入社後すぐにサバゲ部に入部し、何もかもをレンタル&貸してもらって屋内フィールドでサバゲデビューをしたうなすけ。適度に物欲を刺激された直後、追い打ちを掛けるように予定される屋外サバゲ。その日程は、給料日の数日後であった。そして給料日当日、情報共有おじさんと共にサバゲショップに向かったうなすけの運命やいかに……
武器を買いました
買ったのは、東京マルイ MP7A1(フルセット)と、東京マルイ コルト M1911A1ガバメント(エアーコッキングガン)、あとBB弾とか手袋とかです。
給料日ということでテンション上がりつつも、使い過ぎはヤバいと自分に言い聞かせた結果、出費は6万円強に収まりました。よかったですね。
サバゲ当日
いつの間にか参加人数が膨れ上がって(計5人)、レンタカーを借りることになったりしました。情報共有おじさんのお陰で、集合場所、遅刻勢のピックアップ、会場までの道のり案内がスムーズにfacebook messenger上で執り行われました。
実際の会場がこちらです。サバイバルゲームフィールド HEADSHOT（ヘッドショット）
写真など
蜂の巣とか蜘蛛の巣があって虫苦手な人は絶対無理だなって思いました。
tweetたち
感想
今回のイベントは、カウント戦(撃たれたら自陣に戻ってカウンターを押して復活)とかフラッグ戦(撃たれたら退場、敵陣のフラッグを取ったら勝ち)を何回もやっていく感じでした。初心者の僕はあまり立ち回りとかもわかってないので、撃たれたけど、どこからかがわからないということも多く、復活できるカウント戦のほうが好きです。(適度に退場しないと暑さでやられてしまうので、やり過ぎないよう注意)
それでも回数を重ねていくうち、1対1の打ち合いになったり、自分が見つかるより先に相手を見つけることもできるようになりました。
フィールド内ではマスクをつけるので、顔がだいぶ隠れます。そのおかげか？知らない人に話しかけられる(話しかける)ことのハードルがずいぶん下がる気がします。なんかフィールド内では男性より女性と多く話してました。何なんでしょうね。
あと、迷彩 + 武器 + 眼鏡 + ポニテとか最強だなって思いました。
夏場の屋外はとても暑く、熱中症対策もしっかりしていく必用があることを思い知らされました。水分はたくさんとってるはずなのに頭が痛くなったりするので、逸る気持ちを抑えて休憩をこまめに取っていきました。
テンションが上って、サバゲ終わったあと温泉行こうとなったのは結果的にすごく良かったと思います。帰ってベッドにダイブ出来ましたから。
まとめ