eji著

主にプログラミングや山登りの話などを書いていく予定

ISUCON6予選参加の振り返り

2016/09/18 に ISUCON6予選に参加した。

お題ははてなキーワードのような簡易的なWEBサービスで、3個のサービスで構成されていた。

  1. メインサービス
  2. スター機能用マイクロサービス
  3. スパム判定サービス

OSはCentOS7でその上で上記サービスが動くような構成であった。 言語はRubyを選択し、DBはデフォルトでインストールされたMySQLを使った。

当日の流れ

午前中

主に作業用のインスタンスの準備やアプリ改修の方針決めなどがメインだった。

12:00〜15:00

午前中に決めた方針に則り各自作業を進めた。 自分は予習が足りず、アプリのデプロイや設定ファイルの変更などがメインだった。

15:00〜18:00

修正の成果が出始めて上位に食い込むようになってきた。 この段階で色々とボトルネックが見え始めて修正が頻繁になりデプロイ頻度も上がってきた。 結局最後の5分頃まで修正をデプロイしていた。

結果予選を突破することができた。

反省

自分は予習が足りなくぶっつけ本番になってしまったのがすごく残念だった。 他のメンバーの作業に集中できるようにデプロイや設定ファイルの設置がメインだった。

本戦出場が決まったので、もう予習やチューニングの勉強をしておこうと思った。

cordovaで''Simulator session timedout.''が出る問題

cordovaからiosシミュレータを起動すると''Simulator session timeout''というエラーが出てしまう問題は、tmuxを使っていると出るっぽい。

Issues emulating ios - Ionic

Terminal.appを使えってことらしい。tmuxを使った回避策はまだよくわからない

開発合宿 in 山梨

先週の10/11〜10/13の間、山梨の八ヶ岳近くのコテージで開発合宿してきました。

eji / dev-camp-in-2014-10 — Bitbucket

目的は「普段とは違う場所でプログラミングを楽しむこと」ということで、
ある一つのものをみんなで開発するのではなく各自作りたいものや勉強したいものを決めて、
それぞれ黙々と作業するという形式の合宿でした。

きっかけ

f440さんと酒を飲んでいるときに「開発合宿したいね」という話題になり
「そういえば開発合宿的なものに参加したことないなぁ」
「一度やってみたいな」
と思い、企画してみました。

やったこと

合宿を開催するにあたり、以下のようなことをやりました。

メンバー集め

一番始めにやったことは参加メンバーの募集でした。
初めての開発合宿開催ということで、そもそもメンバーが集まるのか不安だったのではじめにメンバーを募集しました。

しかし、これはあまりよくありませんでした。

開発合宿をやろうと決めたのが9月の中旬で、開催日は10月頭を予定していました。2、3週間先でもなんとかなるだろうとかなり楽観的に考えていました。しかし10月は紅葉シーズンだったので、希望人数に合致するような宿は既に取られている状態でした。

宿決め

この時点で既に何名か参加希望者がいましたが宿が取れておらず、開催できない可能性が出てきました。
直前になって宿が取れず開催できませんと言うのは非常に良くないため、企画段階の参加者以外の参加希望者には今回はパスしてもらうことにしました。本当に申し訳ありませんでした。。。

アメンバーで泊まれそうな宿を見つけるということになりました。

宿あつめ

泊まる宿を探すために以下から宿を集めました。

  • 開発合宿の実績のある宿(ブログ等から集めた)
  • Airbnbに掲載されている貸別荘
  • 普通にじゃらん楽天などのサイトでコテージ探し

最初に開発合宿の実績のある宿をリストアップし、電話で問い合わせしてみましたが、やはり申し込み2、3週間前でしかも紅葉シーズンだということで埋まっていました。

次にAirbnbで貸別荘を探すことを検討しました。人数が多ければ普通に宿を借りるよりも安めに借りられたりするようで、かなり良いと思いました。ただし、やはり2、3週間先は既に埋まっているところが多く断念しました。

最後にじゃらんなどのサイトでコテージを探し、運良く今回泊まるコテージを見つけることができました。

交通手段、持ち物決め

宿が決まった後はだいぶ楽になりました。交通手段や持ち物決め、当日の食事はどうするかなどをSlack上で決めていきました。

宿の決め手

ほとんど宿の選択肢がなかったので決め手というのはほとんどないのですが、最低限以下がある場所にしました。

  • テーブルがある
  • スマホの電波がつながる

テーブルは腰を痛めずに作業するので必須と考えました。
またスマホの電波がつながる場所という条件は、宿のネット環境が良くない場合があると聞いたために必須にしました。
今のスマホはほとんどテザリング機能がついているので、それを使えば良いかと考えました。

後のサービスはそれほど重要ではないと考えたので、重視しませんでした。

結果

特に大きなトラブルもなく終えることができました。

反省点

オンシーズンはもう少し計画的に

今回、東京近郊は紅葉シーズンということで、直前の宿の申し込みはほとんど不可の状態でした。
もう少し余裕を持って(最低でも1ヶ月前)宿を探した方が良かったかなと思いました。

ただ、勢いで企画した物はなるべく新鮮なうちに実施しないと醒めてしまうので、長期的過ぎるのも良くないのかなぁと思いました。

食事付きにする

今回食事は適当で良いかということで素泊まりプランにしたのですが、自炊は皿洗いなどの手間がかかり外食は移動に時間を取られるので
食事付きにすれば良かったなと思いました。

まとめ

あまりうまくまとめられてないけど、初めての開発合宿企画は無事成功した(?)ので少し自信がついた。

そろそろ次回の企画を考え始めてみる。

VagrantでDockerを使う方法のメモ

VagrantでDockerを使ったことがなかったので軽く調べてみた。以下自分用のメモ

VagrantでDockerを使う方法

VagrantでDockerを使う方法は2種類ある。

  1. Provisioner
  2. Provider

Provisioner

Vagrant 1.4 から provisioner として docker が追加された。

これはVirtualBoxVMWare等にインストールしたVM(このVMは、CoreOSやCentOSなどconfig.vm.boxに指定してインストールしたOS)にdockerを入れるためのもの。

この方法は以下の利点と欠点がある。

  • 利点
    • 自分の好きなOSをDockerのホストにできる(ただこれはあまり嬉しくない気がする)
  • 欠点
    • マシンのリソースを食う(プロジェクトごとにVMを立ち上げることになるため、メモリやCPUを食う(はず))

Provider

Vagrant 1.6 から docker が provider として加わった。

この方法は以下の利点と欠点がある。

  • 利点
    • マシンのリソースを食わない(プロジェクトごとにコンテナを動かしてもVagrantがホストを提供してくれるので動くVMは1個だけ(のはず))
    • Dockerコンテナでコマンドを実行する方法が用意されている
    • Provisinerと比較して立ち上げが速い(はず)
  • 欠点
    • Provisionerと比較して欠点は見当たらなかった

まとめ

VagrantでDockerを使う方法を調べたらProvider使っている記事やProvisioner使っている記事があって、結局どっち使うのが良いのか分からなかったので調べて簡単にまとめてみた。

どちらもそんなに大きく変わらないから使いやすそうな方で良い気がするけど、自分はPCを外で使うことが多いからリソースを食わないProviderの方が向いているなと思った(ただしリソースの使用率をはかった訳じゃないから間違っている可能性ある)

って書いておきながらまだDocker入れてない。今いる場所のWiFi環境がひど過ぎて(環境しまくりでブチブチ切れる)Dockerどころじゃない。。。

Appleの発表前日にMacを買ったのでメモ

今日2014/9/9にAppleの発表があるんだけど、むしゃくしゃしてその前日の9/8に新しいMBPを届くように購入した。

セットアップのメモを備忘のため残しておく(細々としたのは割愛)

手動で設定

セキュリティ系

FileVaultを入

秘密のファイル漏れたらおわっちゃうので初めにFileVaultでホームを暗号化しといた。
負荷が気になったけど、最近は全く気にないらしいってことで「入」にした。

ファイアウォールを入

家の外のホットスポットとか良くつかうのでファイアウォールは入にしておいた。
「入」ってなんだ?

その他

gitのインストール

さいしょはgit入っていないので入れておく

Homebrewのインストール

もろもろパッケージ入れるのに必要

brew-caskのインストール

もろもろパッケージ入れるのに必要

自動で設定

シェルスクリプトbrewbrew cask叩いて終わり。

書いていて疲れてきた(´・ω・`)

Perl文化に触れてきた(YAPC::Asia TOKYO 2014に参加してきました)

YAPCは帰ってブログを書くまでがYAPCということで(炭酸麦茶飲みながら)ブログを書いています。ブログ書くのはホント久しぶり。

以下では参加した経緯と自分が良いなと思った発表、イベントの全体的な感想を簡単に書いていきたいと思います。

YAPC初参加!

YAPC::Asia TOKYO 2014に参加してきました。今回がYAPC初参加です。

以前からYAPC良いよと先輩(@tk0miya)から色々と言われていたのですが、Perl使っていないし(仕事ではPHPRubyJava、趣味でGoとかHaskell)なんで、行ってもボッチプレイしそうだなぁと思っていて行かぬまま2年くらい経過しました。

なぜ今回参加したかというと今の業務に関係のありそうな発表(データ分析、モバイルアプリ開発)と、興味がある低レイヤーの発表があったので申し込みしました。ほんとPerlとは無関係です...

参加した結果を一言で述べるなら「また次回も参加しよう」です。
目的の発表が聞けて満足したというのもありますが、それ以上にPerlコミュニティの熱さや懐の深さなどPerlの文化的なものに触れられたからというのが大きいです。

自分はあるコミュニティに属さずに一人で勉強ばかりしていたのですが、こういうイベントに参加して色々とやってみようという意欲が沸いてきたり何かのコミュニティに属して貢献したいと思ったりとプラスになる面がかなりありました。イベントの企画・運営した方々にはとても感謝しています。

またイベントが終わった後のパブでも@941さんをはじめ、初めて会ったのにも関わらず気さくに一緒にビール飲んだ方達(名前を聞いていなかった。。。)とも楽しくお酒が飲めて、良いコミュニティだなと思いました。

(無礼は承知ですが)Perlという言語はこれから爆発的に流行る言語ではないのかもしれないのですが、この言語を中心に育まれたコミュニティの文化というものはこれから色々な言語に引き継がれていくのかなぁと、(まともな思考ができない状態で)そう思いました。

良かったなと思った発表

以下は個人的に良かったなと思った発表です。

現在とあるECサイトの簡単なデータ分析業務の技術的サポート(ETL、Tableauのサポートなど)をしているのですが、今までWEBアプリやモバイル(Android)しかやったことがなく、データ分析についてはほとんど独学で素人同然でした(現在進行形)。そのため、データ量に対するアーキテクチャの決定やミドルウェアの選定などの指標があまり体系的に理解していませんでしたが、この発表を聞いて「こんな風にアーキテクチャ決めてけばいいのかな」と(なんとなくですが)指標のようなものが分かり、役立てていけそうだと思いました。

業務でAndroidをやっていて、gueei/AndroidBinding · GitHubをよく使っていたという経緯もあり、アクティビティ間でモデルの状態を共有するにはどうすれば良いかなど非常に共感して聞けたというのが大きかったです。

またアプリのバージョン管理についてもモバイルアプリ固有の管理方法など共感するものがありました。

自分の場合はBtoBのAndroidアプリで、アプリが配布先のお客さんによって使っているバージョンが異なり、リリースした過去のバージョンのアプリもバグフィックスなどサポートしなければならず、この辺のバージョン管理の本とか管理手法のデファクト的なのが出ても良いんじゃないかなぁと思いました。

これはGitHubの内部構造やリリース方法について知ることができたのが大きかったです。
かなり技術的な内容なので、あとでスライドをみて色々調べたいなと思っています。

(自分は全くPerlを使っていないので、場違い感が半端なかったのですが...)
Perlを知らない自分でも静的解析のつらみのようなものや楽しさのようなものが伝わり、何よりトークがうまかったので、自分は非常に楽しく聞けました。

(泥臭いことも必要だなぁと再認識)

イベント全体的な感想

以下はイベント全般に関する感想です。イベントをより良いものにしたいという思いがあり、多少辛口になってます...

  • 席が足りない

今回は参加者が多かったということもあると思いますが、もう少し広い部屋が良いなぁと思いました。
でも床に座っても問題なかったのでこれで良かったのかなとも思ったり。。。

  • 発表間の移動時間が欲しい

見たい発表が教室をまたがっていることが多く、かつ、次の発表がすぐに始まってしまうので、2,3分程度トイレ休憩、移動時間があったら良いのかなぁと思ったり。

でも発表の数とかスケジュール考えるとこれでも良いかなぁとおもったり。

結局

不満なかったです!すごく快適に過ごせました。


あ、やっぱ部屋で無限コーヒー飲めたら良いかも。。。。

さいごに

Perlという文化の熱さや寛容さというものに触れられて非常に有意義なイベントでした。Perlを書いたことがない人でも気軽に参加できる良い場だなと感じました。

次回も参加したい!


余談

Acme本買いました。すごく楽しみで電車の中で開きました。目の前の女性がこっちを見ていました。

また居酒屋でこのブログを書きながらAcme本開きました。そしたら隣のカップルがひそひそこっち見てなんか言っていました。

f:id:eji:20140830223525j:plain

みんなAcmeに嫉妬しているんですね(´・ω・`)

BeagleBoneBlack(Angstrom)で公開鍵を生成する方法

BeagleBoneBlack(BBB)からgithubにアクセスさせようと思い公開鍵を作ろうとしたが、ssh-keygenが見つからない。

調べてみるとどうやらBBB(AngstromLinux)ではdropbearkeyコマンドを使うと良いらしい。

組込み環境で利用することを想定しているらしい。

Dropbear is particularly useful for "embedded"-type Linux (or other Unix) systems, such as wireless routers.

鍵は以下のコマンドで生成できる。

# RSAで2048bitの鍵をid_rsaというファイルに保存
$ /usr/sbin/dropbearkey -t rsa -s 2048 -f id_rsa

追記

↑の方法でdropbear形式の鍵は生成できるんだけど、Githubとかにアクセスするときになぜか怒られて使えないので、以下のコマンドでopenssh形式の秘密鍵に変換してあげないといけないようだ。

$ /usr/sbin/dropbearconvert dropbear openssh 秘密鍵(dropbear)のパス 出力先のファイル

ちょっと面倒なので、別のサーバーでssh-keygenを使って鍵のペアを生成した方が楽そうだ。。。