うなすけとあれこれ

2016年01月24日

mktakuyaからこのブログにプルリクが飛んできた話

blog name

このブログはオープンソースです。

特に主張などはしていませんが、このブログはunasuke/blogにて生成に関する部分や画像など、全てのコードを公開しています。

middlemanとh2oとVPSによるブログ構築にも書いたように、middlemanを使ってhtmlなどの生成をしています。

まだまだデザインの面でもいろいろしたいことはあり、外見が未完成ではあります。

@yu_suke1994 あとrss欲しいです

— あそなす (@asonas) 2015, 11月 24

Pull Requestが飛んできた。

うなすけさんのブログをfeedlyにぶち込んだらブログ名が"Blog Name"だったりURLが"blog.url,com"だったりしててアレだったのでPR送った。

— mktakuya (@mktakuya) 2016, 1月 19

というわけで、こういうPull Requestが飛んできました。

ライセンスが決まってなかった。

その場でPull Requestをmergeしてもよかったといえばよかったのですが、生憎とこのブログにはライセンスを定めていませんでした。その状態で他人からのPull Requestを取り込んでしまうのはあまりに危険と言える(？)でしょう。

というわけで、このブログはMIT LICENSEの元で公開することになりました。 Add license(MIT) · unasuke/blog@d418f1b

merge it

無事しました。

merge

このブログはプルリク募集中！

ではないです。

この記事にあるように、バグ修正とかは大歓迎ですが、見た目が大きく変わる変更や、新規記事の追加(！)はしてほしくないので……募集はしていません。

まあでもなんかあったらプルリクお待ちしております。

2016年01月24日
2016年01月19日

インターネット界隈の人たちで交流サバゲをするイベントに参加した

おなまえシール

2016年初サバゲ

インターネット界隈の人たちで交流サバゲをする - 良いあそなすちゃん に、参加しました。

追加装備

今回の参加にあたって、BDUなどを買いました。全部挙げると、ブーツ、BDU上下、スカーフ、ベルトですね。計16000円ほどでした。

ゲームルール

フラッグ戦、殲滅戦、人狼、昭和VS平成、サドンデスをやりました。

人狼

ゲーム開始前に1人1枚トランプをめくり、10以上なら狼、それ以外は村人とし、ゲーム終了時点で村人が生き残っていれば村人の勝ち、村人が全滅したら狼の勝ちというルールのゲームを行いました。

あまり銃弾の打ち合いはなく、銃声が聞こえると「えっなにこわいこわいこわいこわいこわいどっちどっち」とオロオロする感じで進んでいきました。後ろから撃たれました。

昭和VS平成

文字通り、昭和生まれさんチームと平成生まれさんチームに分かれて殲滅戦です。ただし、各チームに2人スパイがいて、ゲーム開始から2分後にスパイがコソコソと活動しだすというルールがありました。平成生まれさんチームは1敗2分けで、「財力だ」とか「経験の差」と悔しがりました。昭和つよい。

感想

もっと良い装備がほしいという物欲が刺激される非常に良くない最高の催しでした。

運動記録

2016年01月19日
2015年12月27日

やままハウスハッカソンの進捗報告

キンブレ

発端

うなすけとやままハウスハッカソンしたいねという話をしてた

— ありたそ (@alitaso345) 2015, 11月 10

しよう

— やまま (@kirikiriyamama) 2015, 11月 10

@kirikiriyamama 年末とか空いてたりしないんですか

— ありたそ (@alitaso345) 2015, 11月 10

@alitaso345 26とか〜

— やまま (@kirikiriyamama) 2015, 11月 10

@kirikiriyamama それでいきましょう

— ありたそ (@alitaso345) 2015, 11月 10

@alitaso345 ぶっこみ

— やまま (@kirikiriyamama) 2015, 11月 10

やりたかったこと

当日

pic.twitter.com/8U8YrppSVM

— やまま (@kirikiriyamama) 2015, 12月 26

とりあえず集合した後、おにやんまに行って美味しいうどんを食べました。ちくわ天最高。

うなすけさん(@yu_suke1994)が投稿した写真 -

うなすけのおにやんまの感想「丸亀製麺の上位互換だった」

— やまま (@kirikiriyamama) 2015, 12月 26

道すがら、近くに温泉があることが判明し、高まっていました。

道中で酒を大量に買い込み、会話がハイコンテクストであること、本名に「ゆ」が含まれるのが2人いた事から、ゆゆ式を見ないとダメという話になりつつ(伏線)やままハウスに到着しました。

なぜかやままハウスについた途端、言の葉の庭をNetflixで視聴し始めた結果、「金麦とチョコレートが食べたい」という気持ちになりました。金麦もチョコレートも買ってこなかったので、買いに行くことにしました。

買いに行く前に、ありたそさんが昨日クラブから直接大学、それからハッカソン参加ということで風呂に入りたいということになり、まず温泉に行きました。

温泉に行き、おもむろに僕らはサイゼリヤに行きました。なぜでしょう。全く覚えてません。

サイゼリヤでは、サイゼ飲みを極める！　コスパ最強イタリアンバルとしての『サイゼリヤ』初級～中級～上級編 ｜ ガジェット通信を参考にしながらとにかく頭の悪い会話をしました。

サイゼで「モバマスのアイドルは何のプログラミング言語を使っているのか」という議論が盛り上がってる。みくにゃんはRubyでミナミはPython。

— うなすけ(類い稀な偏差値) (@yu_suke1994) 2015, 12月 26

そして帰りに金麦、チョコレートを買い、僕、やままさんがゆゆ式を見たことがないのでゆゆ式を借りようとしたら、DVDの1巻、2巻がなく、代わりに僕が見たことがないアイドルマスターシンデレラガールズのアニメを1期分借りて帰りました。

上映会の幕開け

赤城みりあちゃんが登場した瞬間泣き出した人がいたり。

隣のおたく泣き出したんだけど

— うなすけ(類い稀な偏差値) (@yu_suke1994) 2015, 12月 26

ニュージェネがバックで踊るシーンで僕以外全員泣き出したり。

人が泣いている pic.twitter.com/AQ6yRalPWk

— うなすけ(類い稀な偏差値) (@yu_suke1994) 2015, 12月 26

新卒採用の話になったり。

新卒採用の話をしている pic.twitter.com/KUrskd5B7m

— うなすけ(類い稀な偏差値) (@yu_suke1994) 2015, 12月 26

誰かデレマスと新卒採用を絡めてリビルドで話してくれ

— ありたそ (@alitaso345) 2015, 12月 26

飛び出した発言

成果

酒飲んでアニメ観て銭湯入って酒飲んでアニメ観て酒飲むみたいな会でした

— ありたそ (@alitaso345) 2015, 12月 26

決めた、渋谷凛になる

— やまま (@kirikiriyamama) 2015, 12月 26
2015年12月27日
2015年12月23日

kosenconf 100 in 東京の副実行委員長でした。

名札

高専カンファレンス 100 in 東京

2015年12月19日、20日の2日間、電気通信大学で開催された高専カンファレンス 100 in 東京の運営に、副実行委員長として参加しました。

実行委員長であるところのなっちゃんの夢これをご覧になられた方はわかるかと思いますが、LINEで捕まった人間です。

会場ではウェイ系でしたが、ブログはしっとり系でいきます。

何してたどんな人か

当日までの準備で言えば、ミーティングの議事録はもっぱら僕が担当していました。また、スタッフ間のコミュニケーションには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人も分けるのか。分けた後、最後に合わさるのか。様々なパターンが存在しました。その中のどれを選択すれば、参加者間の壁は無くなるのか。かつ、時間、空間、予算の釣り合いが取れるのはどこか。

それらのアイデアと、制約の中で生まれたアイスブレイクが、当日みなさんの体験したものとなります。

結果

DSC_7513

DSC_7523

DSC_7522

僕の担当した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月23日
2015年12月15日

RubyKaigi 2015に参加した

壇上

初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さんありがとうございます。

スタートアップの若者に大企業で働くことのメリットについて解説してる

— SHIBATA Hiroshi (@hsbt) 2015, 12月 12

スタートアップの若者です。

koicさんとなかよくなる

koicさんは弊社と何かと関わりの深い(参考spice life様と合同勉強会を開催しました - 株式会社永和システムマネジメント アジャイル事業部)永和システムマネジメントさんの方なのですが、何かと予定が合わず今までお会いすることができませんでした。お会いできて良かったです。rubykaraokeではお世話になりました。

感想

とにかく界隈に知り合いがほとんどいなくて、気持ちがつらいというのがあります。僕は「きっと何者にもなれないお前たち」の「お前たち」のほうなので、とにかく人前に出て行かないと知ってもらえる機会なんてないんですね。

というけでせっせと手を動かしてなんか作って顔を出していきたい気持ちが高まっています。よろしくお願いします。

そして、発表者の方々、スタッフの方々、楽しい時間をありがとうございました。

追記

hsbtさんに直談判した件、こんな感じです。これに加えて自分でもPull Requestを送りたいと思います。

2015年12月15日
2015年11月24日

rubygemを２つ作って公開した

rubygem 2つ

それは今年の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月24日
2015年11月23日

CircleCIでmiddlemanのdeployを自動化した

Circle ci

まずは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月23日
2015年11月08日

つよいCSSを書きたい

読んだ本

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年11月08日
2015年10月23日

Fitbit Chargeを買った

Fitbit Charge

Fitbit Chargeとは

一言で言ってしまえば高性能万歩計だと思います。 Fitbit Charge™ ワイヤレス活動量計・睡眠計リストバンド

隣の席の人が買ってて羨ましくなったので買いました。

使ってみての感想

つけごこち

もともと鬱陶しいからと腕時計をせずに今までの人生を歩んできました。そこに突然こういうものを身につけ生活するようになると、とても違和感があります。 まずノートパソコンのキーボードが使いづらいです。手首をべたりと密着させながらキータイプするほうなので、左手が動かしにくいです。金属製の留め具で傷をつけるのもいやですし。 なので、Tex Yoda(外付けキーボード)を使うことが一気に増えました。持ち運びも運動になるしいいのかも…… 大きさはLでちょうどいい感じです。

情報

僕がFitbit Chargeで一番魅力的だと思っている機能は、睡眠時間の計測とアラーム機能です。特に何も設定しなくても、睡眠を自動で感知して記録してくれるので、自分が何時間眠ったかなどがわかって便利です。

Fitbit アプリ画面

他にも、登った階数、歩数、距離を自動で計測してくれます。歩数は、同期している状態で歩くとリアルタイムに数値が更新されていくので見ていて楽しいです。

とれない情報

Fitbit Chargeでは、心拍数、体重、体脂肪率、摂取カロリー、摂取した飲料の量は計測できません。自分で入力してやる必要があります。体重と体脂肪率(身長を設定しているとBMIも)くらいは1日にそう何度も量らないので、都度入力してやるのはいいとします。しかしそれ以外の摂取カロリーなどの値はまったく計測できません。自分で入力してやればいいとしても、それはちょっと面倒すぎると思います。

いつか体内に機器を埋め込んでこういう値も取れればいいな……

まとめ

いろいろな数値が可視化されるのは見ていて楽しいです。

来月の健康診断に引っかかりたくない……

2015年10月23日
2015年09月23日

middlemanとh2oとVPSによるブログ構築

h2oのbuild

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は慣れているし、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日
新しい投稿
古い投稿