2015年12月23日
高専カンファレンス 100 in 東京
2015年12月19日、20日の2日間、電気通信大学で開催された高専カンファレンス 100 in 東京の運営に、副実行委員長として参加しました。
実行委員長であるところのなっちゃんの夢これをご覧になられた方はわかるかと思いますが、LINEで捕まった人間です。
会場ではウェイ系でしたが、ブログはしっとり系でいきます。
何してたどんな人か
- 副実行委員長業
- アイスブレイク担当
- 社会人
- カンファ参加7回目
- 運営スタッフ2回目
当日までの準備で言えば、ミーティングの議事録はもっぱら僕が担当していました。また、スタッフ間のコミュニケーションにはSlackを使用したのですが、そのSlackの準備をしました。公式wikiの更新も、ある時期までは僕が行っていました。副実行委員長らしい仕事といえばそれくらいです。
アイスブレイク担当としては、どのような企画を行うかの決定、タイムテーブル作成、当日説明用スライド作成、台本作成、部屋割り作成、当日の司会を行いました。
当日行ったアイスブレイク以外の仕事は、1日目はクロージングトーク、2日目は複数トラック発表の補佐、基調講演・LTの司会と銅鑼です。
つらつらと思い出
夢これの発表中にあったあのLINEのやり取りは、6月10日でした。そこから6ヶ月かけて様々な準備をしてきました。まずは、とりあえず目標としていた新春カンファレンスの実行委員長のひとり、RooandQooさんにアタックして新春カンファレンスの記録を頂きました。そのあとでスタッフを集め始めたりと、いろいろ動き始めました。
キックオフミーティングは8月11日に行われました。それから6回のミーティングをして、当日を迎えたわけです。
言い出しっぺのなっちゃんは強い信念というか、目標というか、思想を持っていました。おびなたさんに話してもらいたいというのもそうですし、アイスブレイクで打ち解けてもらいたいというのもそうです。僕はそのような思想を持ちあわせていない代わりに、その意見が実現可能であるか、困難であれば何から解決していくか、などの相談役として方向修正をするという役目でした。ごく初期は。スタッフが増えていくにつれ、そういった僕の役目は消失していきました。
例えば今回は電気通信大学で開催しましたが、手っ取り早く広い場所を借りる(回線も用意する)ならある企業のスペースを使わせてもらったほうがいいのではないかと思っていました。また2日間開催も当初は反対していました。
そこで「いや、電通大でやりたい」「2日間開催したい」という委員長の強い意志には何度も感心というか、尊敬というか、力を感じました。そしてそれは間違っていなかったと思います。
共有Dropboxのファイル更新通知のたびに上がってくる素晴らしいデザインを見るたび、カンファが形になっていくように感じられ、焦り、緊張、期待が大きくなっていくのを感じました。
アイスブレイクについて
僕がメインとなって担当したアイスブレイクの話をしていこうと思います。
アイスブレイクは、様々な事情(後述)により、本格的に動き始めたのは11月25日頃です。この時点で開催1ヶ月を切っています。絶対に真似しないでください。
実行委員長が「200人参加申請なかったらカンファ行かない」という旨の発言を前日にしていました。この時期(11月終盤)の参加者登録は確か150人程度で、僕はまさか200人もいかないだろうと思いつつも、アイスブレイクで許容できる人数の上限を200人としました。
結果的に参加申し込みは200を超え、1日目の参加者も141人と、まさかこうなるとは、という感じでした。
その後、アイスブレイク班(なっちゃん、僕、くりむぞんさん)のみでミーティングを重ね、最終的にアイスブレイクの全体が決定したのは12月9日(開催10日前)、当日使用する全ての物品の用意が完了したのは12月19日(開催当日)でした。絶対に真似しないでください。
目標としたこと
僕がアイスブレイクで目標としたのは、「なるべく多くの人と、がいいけど、最低1人、できれば2人の人と打ち解けてもらうことを目指す」ということです。
大きな開催となり、全国津々浦々から人が集まります。高専カンファレンス100の懇親を支える技術 - Labo Memoにある全国高専マップには、日本の北から南まで付箋が貼られています。
となると、twitterでフォローしてるけど会ったことがない人、twitterで見たことはあるけど会話はしたことがない人、初対面の人、などなど、コミュニケーションを行うのに壁を超えなければいけない人がたくさん居ます。
その壁を取り除き、顔とアカウント名を一致させたり、新たなフォロワーを増やしたりする、打ち解け合いのお手伝いをしたかったのです。
そして必ずやりたかったことは、「ものをつくる」ことです。その場で初めて会う人とも、「共にひとつのものを作り上げる」という体験を共有できれば、きっと壁はなくなるでしょう。それに、話をして「はい、終わり」では、あまりにも寂しすぎます。
そのためにどうするべきかというのは、短い時間ながらも様々な案を出しあい、これはどうか、これで本当に会話が広がるのか、と何度も検討を重ねました。そもそも200人全員で何かをするのは無理があるのはわかりきったことですが、それを4つの部屋に分けるとして、その部屋の中ではどうするのか。50人で何かをするのか。その50人も分けるのか。分けた後、最後に合わさるのか。様々なパターンが存在しました。その中のどれを選択すれば、参加者間の壁は無くなるのか。かつ、時間、空間、予算の釣り合いが取れるのはどこか。
それらのアイデアと、制約の中で生まれたアイスブレイクが、当日みなさんの体験したものとなります。
結果
僕の担当した202教室では、参加者同士の話し声、笑い声が絶えないよい雰囲気、望んでいた雰囲気を作り出すことができました。
前述の通り、アイスブレイクの物品の用意が完了したのが当日早朝だったということもあり、各部屋の司会、補佐それぞれには事前にスライドと台本を読んでもらうという、リハーサル全く無しのぶっつけ本番で挑んでもらうことになってしまいました。その結果として、最強人間を作ることができなかった部屋もありました。
冒頭でSNSを禁止したこともあり、アイスブレイク中の感想はあまりtwitterからは拾うことができませんでした。それでもアイスブレイク終了後、「楽しかった」というツイートがいくつかあり、とても嬉しかったです。
スタッフルームに帰ってきた後も、他のスタッフから良かったという言葉を聞くたびに、くずおれるかと思いました。
司会業ですが、僕は完全に経験で殴ったようなもので、他の部屋の様子がまったく予想できませんでしたが、感想ツイートからはうまくいったようです。ありがとうございました。
アイスブレイクの成果物(伝説巻物、最強人間)は、懇親会の会場に掲示しました。懇親会の最中は僕は完全にテンションがおかしくなってしまい、それらを掲示したことへの反応を伺うのをすっかり忘れていました。どうだったでしょうか。他の部屋、チームの伝説や最強は、思いもよらないものがいくつもあって、とても面白かったです。
裏話
アイスブレイクについて
ところで、このカンファのスタッフは17名とwikiには書いてあります。しかし、こまめにwikiをチェックしていた方がいれば覚えていらっしゃるかもしれませんが、実はもう1人スタッフがいた時期があります。mktakuya君です。
当初はmktakuya君がアイスブレイクの企画担当でしたが、どうしても当日に来ることができなくなってしまい、やむなくアイスブレイクの担当を僕へと移すことになりました。これがアイスブレイクの準備開始が遅れた原因です。
彼がアイスブレイクの担当であれば、また違った高専カンファになっていたことでしょう。
アイスブレイクの部屋割り
200.times do
puts "#{%w(101 102 201 202).sample} #{%w(A B C D).sample} #{%w(1 2 3 4).sample}"
end
値はそのまま採用したわけではなく、各部屋、各グループの人数が均等になるよう調整しました。
コミュニケーションツールについて
スタッフ間のコミュニケーションツールとして採用したのはSlackですが、初期にはidobataも検討していました。Slackを採用した理由、idobataを採用しなかった理由は特に覚えていないので、どちらを使ってもコミュニケーションには支障がなかったと思います。
ミーティングについて
アイスブレイク担当者のみで行った小規模なミーティングを除く、全てのミーティングは計7回行われましたが、その全てがピクシブ株式会社で行われました。ピクシブ株式会社様、ありがとうございます。
スタッフパーカーについて
スタッフパーカーは、TMIXで発注しました。とは言え、これについてはスポンサードしていただいたわけではなく、希望者各自が自腹で購入するという形式になっています。
テーマについて
今回のテーマは「Dreaming」ですが、案の中に「new daybreak」というものがありました。僕はこれが好きです。(言葉の響きが好きなだけで、テーマにしたかったわけではないです)
開催前日について
湯河原温泉「おんやど恵」の足湯フログラミングは開発合宿の新しいスタンダードになる - スパイスな人生
開催前日の18日まで、TMIXの開発合宿に参加していました。合宿中、僕がアイスブレイクの準備を行っている横であそなすさんがサブスクリーンをもりもり開発していくという、ある意味高専カンファレンス合宿とも言える時間が存在しました。
会議室が24時間使えるというのは本当にありがたかったです。
18日は宿泊用の荷物を持って移動を繰り返し、泊める約束をした肉好き君を迎えに行ったりして、前日の時点で脚がつらかったですが、1日目で崩壊しました。
歩数
ご確認ください。
2日目はとにかく脚がつらかったです。体調で言うなら、1日目のアイスブレイクでやらかしたのか、ずっと喉が痛くて、1日目の帰りに龍角散のど飴を買ってずっと舐め続けるという緊急対応をしました。2日目には90%くらい回復していました。
まとめ
とにかく、高専カンファレンス100 in 東京は終わりました。皆さんには楽しんでいただけたようで、こちらも嬉しいです。
参加者の皆様、お忙しい中お越しいただき、ありがとうございます。発表者の皆様、素敵で、面白い発表をありがとうございます。
スタッフの皆さん。個人の都合もあることでしょうが、そのような貴重な時間を、高専カンファの成功のために費やしていただき、ありがとうございます。素敵なデザインも、快適な回線も、打ち解け会えたアイスブレイクも、楽しい様々な発表も、目移りする複数トラック発表も、横で盛り上げるサブスクリーンも、しっかりしたtwitterアカウントの運用も、当日用意する様々な物品も、それら全てをまとめ上げ、高専カンファレンスを成功へと導いてくれたリーダーシップも、心から感謝しています。
「最初から3桁のナンバリングにしていてよかった」という意見がありますが、「最初に4桁のナンバリングにしておけばよかった」と嘆く日がいつか来るかもしれませんね。
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日
3回めの移動
はてなダイアリーから、tumblr、さくらのレンタルサーバー上のwordpressと渡り歩いてきた"うなすけとあれこれ"が、さらにもう一回引っ越しをしました。今回は、さくらのVPSとmiddlemanを組み合わせたものとなっています。
移動の理由
仕事でwebサービスを構築していくうちに、webサイトを構築する上で必要となる様々な知識が、以前と比べて格段に増えました。それに伴い、今までは用意された編集エリア、用意されたブログテーマには満足できなくなり、一から構築してみたい、という気持ちが大きくなってきました。
また、wordpressを使っていると、その管理が思ったよりも手間がかかるものであることがわかりました。定期的なアップデート、セキュリティ対策、壊れた時の対処などに振り回されるのには嫌気が差しました。
ということで、静的なhtmlを生成することによる懸念事項の減少、新しい技術の勉強なども兼ねて、middlemanでブログを構築することにしました。
移動の顛末
middlemanとh2oとVPSによるブログ構築
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年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が多いですね。まだ全然聴けてません。
感想
また行きたいです。
ふーゆた、はたっく、本当にありがとうございます。