Sidekiq

github.com

Ruby界隈はエコシステムがしっかりしてるなぁ

  • Redisが必要になる
  • クライアント → Redis ← Workerが処理
  • workerを増やすことはできる
  • workerが増えたときに同じジョブを実行することは?→Redisシングルスレッドなのでそこで担保
  • Redisが死んだときは?

    • 定期的に再接続してるから復旧したら再接続するみたい
  • タスク中にworkerが死んだら?

    • さすがにロストする
  • タスク実行中にプロセスが死んだときはどうなる?(redisに残ってる?)
    • redisに残っているというよりも、正常終了するときはredisにpushしてる
  • タスク実行中に正常終了SIGTERM投げれば正常に終了して次にリトライが走る -> SIGHUPとかSIGQUITではリトライが走らない
    • https://github.com/mperham/sidekiq/wiki/Signals をみると USR1 -> TERMをやったほうがよさそう
    • USR1を実行すると新規workerの開始を停止する。実行中workerは継続 -> TERMで停止する
      • 基本リトライが走る前提で処理を組むのは大前提

社内環境改善活動の話

この記事は Classi Advent Calendar 2016 - Qiita12日目の記事です。前日はhilotterによるエンジニア立ち居振舞い: 明日いなくなってもいいように仕事をする – hello-world.jp.netでした

www.wantedly.com この話を書こうと思ったのですが、既に結果は書かれてしまったのでそこに至るまでの経緯などを書きます

話の発端

現在Classi所属の社員は3人(他はベネッセ・ソフトバンク・ヒトメディアなどから参加してるメンバー)いるのですが、毎月1回副社長とランチをする会があります。その中でよいエンジニアを採用するにはどうしたらよいか?という話の中から出てきました。(ここでエンジニアとしてるのは3人共エンジニアであるため)

もちろん、会社の事業内容、雰囲気や技術で人を引きつけるということは基本的なところなのですが、それと同時に会社インフラも整備して社員を大切にしていることも重要という話をした記憶があります。

アンケートをとる

最初に3人でこういうものがほしい。というのをスプレッドシートに起こしました。椅子・本の定期購読・ウォーターサーバー・ディスプレイなどなど。これはエンジニアとしての主観だったのでそれと並行して、メンバー全員に対してGoogleフォームを使って金額が10万、20万と分けてアンケートを取りました。20万としてるのは深い理由はないのですが固定資産の都合上です。

その結果、ウォーターサーバー、無料コーヒー、お菓子などが上位に上がってきました。エンジニアからはバロンなどの高級椅子・キーボード・マウスなどが上がりやすく、他の職種からは本の購読・本棚などが上位に来てました。その結果以下のように決まりました。なおこれらはトライアルという形式を取っています。

選定・購入する

オフィスファミマ

こちらは副社長が決めてくださったので特に何もしなかったです。感謝。あと、スタバのポットサービス検討していたのですが、都度都度行くのが面倒だろうということで、オフィスファミマのカフェを頼んでます。両方共無料ではなくメンバー自身で購入してます。

ウォーターサーバー

当初はお店にあるようなショーケースにペットボトルを入れるという案もありましたが、コスト的なところを考えて最終的にはウォーターサーバーになりました。また、どこから購入するか最後まで探していました。結果、以下のような理由で 《公式》天然水ウォーターサーバーNo.1【コスモウォーター】の宅配水 にしました。

  • 月額費用
    • トライアルなので解約時に発生する金額を最小限にする
  • 衛生面
    • 自分たちで清掃するのは最小限にしたい

最初は消費量がわからなかったので水を12L✕2本頼んでいたのですがそれが2日半でなくなったので慌てて4本追加注文しました。この辺は水なので余裕持ってもよかったかもしれません。

椅子の購入

予算は30万と決めて、メンバーで実際に試し座りに行きました。その上で オフィス家具・中古オフィス家具通販のオフィスバスターズ から中古を購入しました。申し込んですぐに電話がかかってきてマジびっくりした...

運用・効果を計測する

オフィスファミマは毎週補充に来てくれるので特にやることはありませんが、カフェで使っているドリップマシンは毎朝掃除(といっても、キレイキレイで拭いてるだけ)してます。また、毎週月曜日に軽くウォーターサーバーの清掃も行ってます。この辺は最初から気づいた人がやると運用よりも最初は自分がやったほうが回ると考えているためです。5分〜15分ぐらいで終わるので朝にTwitterを見てる時間をこちらに回すだけです。

これらは月末にGoogleフォームでアンケートをとり次の改善に使っていく予定です。

今回は却下・保留にしたもの

以下のようなものは今回は却下・保留にしました。

  • キーボードなどは個人の好みの差と値段が激しすぎる
  • 本などは楽に申請するフローを決めないと承認する上長の負荷が上がる

公平性と区別

これはあくまでも私見なのですが、何を導入するという基準には「公平性」と「区別」が必要になると考えてます。

公平性というのは職種・契約形態に関わらず全員が平等に受けられるものを整備することです。例としては今回採択した3つとも公平性にあたると考えています。あとは通常のディスプレイなどもそうですね。弊社は椅子に座ってノートPCを使っている人が多いためこの辺を整備すると生産性が上がることは目に見えてます。これまで仕事で外部ディスプレイを使ったことがない人に対しては、どのぐらい効率が上がるのかイメージも湧かないでしょうから、とりあえず使ってみてくださいと言う形で半強制的に貸与してもよいかと思っています。

区別は職種によってある程度異なるものを整備する必要があるのではないかと考えています。例えば、デザイナーは通常のディスプレイではなく高解像度のディスプレイにするとか、マーケティングは外出が多いからWifiルータやデモ用のiPadを貸し出せるなどもあるかもしれません。現在はこのあたりはまだ手をつけれていないのですが直に整備が必要になる部分かと思います。

感想

これらは約1ヶ月〜1ヶ月半の話だったのですが、社内の環境を改善していくという目的に対してトップダウンボトムアップがうまく働いた例かなと思います。上がお金やビル側などの複雑な調整をし、下が予算などの制約の中で持っている経験などから最適解を出せたのではないかなと思っています。環境改善は一時的なものではなく会社がある限りずっと続くものなので、メンバーのニーズや会社規模などに応じてこれからもみんなが働きやすい環境を作っていければと思います。

wantedly

こんな感じで会社を作っていくことに興味がある方は是非お願いします www.wantedly.com

明日は

kyottyyのコーポレートサイトをLinuxからS3+Lambdaにした話です

buildersconで知ったkuba-awsを触ってみた

この記事は Classi Advent Calendar 2016 - Qiita 7日目の記事です。前日はkitaharamikiyaによるFabric Beta によるテストアプリの配信 - Qiita でした。

12月3日に builderscon - Discover Something New に行ってきました。そこでkubernetesをAWS上で動かすという紹介をやっていたので、自分でも試しに触ってみました。と言ってもほとんどチュートリアルをやっただけです。事前にお断りしますがこれがClassiのサービスに入るわけではありません。ただこういう素振りは手を動かしてこそ身になります。

github.com

なおバージョンは0.9.1です。

完成図

チュートリアルを進めた結果ざっくりとこんな感じのものができました。 f:id:hs_hachi:20161207000814p:plain

ローカル環境から kube-aws validate --s3-uri=<S3URL> と実行すると、事前に作成したS3へ設定ファイルがアップされました。その後、 kube-aws up --s3-uri=<S3URL> を実行するとCloudFormation経由で図に書いてあるRoute53へ登録を行ったり、VPC作成、ELBなどの設定が行われて、kubernetesを使う準備ができます。

それぞれを複数台,MultiAZになっているので、仮にどちらかのサーバがダウンしてもAutoScaleが働いて別サーバが立ち上がる構成になってます。実際のプロダクション環境の場合は多重障害を懸念するのと、サーバ負荷の関係でNodeサーバは3台以上立ち上げる構成にすると思います。実際にサンプルアプリを配置すると各NodeにそれぞれDockerがビルドされました。

この絵を手で書いてるときに思ったのがこちら。MongoDBと似てるとなるとお金かかりそうな気がする。

普通にプロビジョニングをするのか、Dockerなどでインフラもアプリもまとめるのかはサービス次第なのですが自分はアプリケーションサーバなど頻繁に変わるものはDockerにしたいタイプです(Amazon LinuxのDocker Imageもできましたし)。可能な限りベンダーロックインは避けたいのでECSもなぁという気持ちはあります。

まだきちんと調べきれてない/触れていないところ

  • 上の図では書いてますが、controllerとetcdの通信経路。(AZをまたいで通信してるのか?)
  • 不要になったDocker Imageを廃棄する方法

明日は

未定らしいです。なければ frontrend 勉強会に行ってきた記事でも書きます

9月から教育サービスClassiで働いてます

この記事は Classi Advent Calendar 2016 - Qiita 5日目の記事です。

Classiにまつわる技術ネタを書きたかったのですが、入社以来ほとんどコードを書いておらず技術ネタがないので転職エントリー書きます。

なぜ教育だったのか?

積極的に次の仕事を考えていたわけではないのですが、定期的に自分のスキルを棚卸ししてて1年ぐらい前から自分のスキルはこのままでいいのかなと思い続けてました。幸いにして前職は同僚・給料・開発環境に恵まれていたのですが、今の上司に「遊びに来ませんか?」というメッセージをもらって「お、なんか有名な @sasata299 からだ」という軽い気持ちで話を聞きに行った覚えがあります。

最初は今の上司である佐々木がインタビューを受けてた記事を読んで(リンク忘れた)是非一緒に働いてみたいという気持ちだけだったのですが、それに加えて、経済を回すという+世の中に還元できることをしてみたいなぁというのがありました。

教育は大抵の人が通るところでそういうところで働けると言うのは社会的意義があるのかなと思ってます。自分の甥や姪が何年かすると自分が作ったサービスを使っているかもしれないことを想像すると楽しみです。先生や生徒がClassiを使って少しでも楽になりました、成績があがってやりたいことができるようになりましたと言ってもらえるサービスを作って行きたいです。個人的にはどうしても教育を受けれない人とかにも同じものを提供できたら最高ですね。

技術的な話

弊社ではインフラはAWS,DBはMySQL(Aurora)を使ってますが、マイクロサービスで構成されていることもあり、サーバサイドはRails, PHP, フロントはAngular,React, Backboneと複数言語で構成されています。これは過去の経緯からそうなっているので、正直現時点ではあまりポジティブな理由ではありません。この辺は常にどうしようか?と言うのは議論されているところです。そのうちサーバサイドはRailsに寄せるのではないかなと思っています。(フロントはReact or Angular2 or Vue.js?)

これまでMySQL,Java,プライベートクラウド(AWSも少し使っていた)がほとんどだったので、ぜんぜん違う技術を使ってみたいというのも転職理由の1つです。また、経験や年齢的にマネジメント中心になっていたので実際に手を動かしてコード書いてたり、アーキテクチャ考えたりしてる方が好きなのでそちらもやりたいのです。

前職では人数も潤沢に揃っておりスペシャリストもたくさんいたので、他の領域に手を出しにくかった部分がありました。また自分の中ではエンジニアはインフラもサーバもフロントもできないとダメだと思っているので、まだ始まって2年のサービスでエンジニアも不足しているチームでは手を出しやすそうな雰囲気ではあります。また、いままではサーバサイドは1年弱ぐらいNode.js書いたけどほぼJavaだけでした。今後の将来を考えたときに、1つの言語で食べていくと言うのは厳しいと思ってました。

自分は不器用な部類の人間だと思うのですが、不器用だからこそたくさんの事をできないと生きていけないと思っています。

昔は不器用だからこそ1つのものに専念したいと思ってたのですが、確か高校時代の進路相談で先生から不器用だから逆にたくさんのことできないとダメだぞと言われたことがありました。その意味がここ数年でわかってきた気がします。ITが求められること、できることが増えたからこれだけ知っていればサービスは作れない。自分がその道だけで食べていけるスペシャリストではないので、数年後どうなっているかもわからない。だからこそ幅を広げることが必要かなと思います。

あとは色々なことを知ると考え方の応用が効いてきます。Node.jsを勉強してたときに、その考え方とか構文とかがJava8の書き方やRubyの書き方にもすんなり入れました。もちろん最低限の物を吸収しなければいけないし、幅を広げると言っても取捨選択は必要なので、今のところは以下のように絞ってます。(と、書いてて思ったのですが、大して幅が広くないw)

  • サーバ: Ruby, Rails, PHP:軽く見る
  • フロントエンド: React, JavaScript, CSS設計やコンポーネント、Angular,Vue.js:軽く見る(フロントエンドは正直カオスすぎて自分の中では一番ふわふわしてる)
  • インフラ・クラウドAWS(AWSは中のサービスが多いので絞ってる)、Docker、セキュリティ、GCP:軽く見る、Azure:捨ててる
  • マネジメント: 一応見ておく
  • 人工知能・AI:流し見程度
  • ネイティブアプリ:捨ててる
  • IoT:捨ててる

が、今年はプロダクションレベルのコードをほとんど書けてないので来年こそ書きたいです(切実)

wantedly

技術・組織的な課題は色々ありますが、教育サービスを作っていきたいと思ってる方はぜひ。 www.wantedly.com

明日は

kitaharamikiya による Fablic Beta によるテストアプリ配信です

buildersconに行ってきた感想

builderscon.io

駆け足で感想書く。

tl;dr

  • 人口密度高くて盛り上がっている感がすごかった
  • 生mattnさん見たかった
  • 多様性がものすごかったので次回は全く違いものばかり聞いても面白いかもしれない
  • 土曜にイベントがあると日曜日ガッツリ触れるからいい
続きを読む

IntelliJ + php + fuel + xdebug + vagrant でリモートデバッグする

PHP(Fuelフレームワーク)を触ることがたまにあるのでリモートデバッグの方法をメモする。書いてみたけどPHP自体よくわかってない

vagrant のIP 192.168.33.10
ローカルのIP 192.168.33.1

root@vagrant-ubuntu-trusty-64:~# php -v
PHP 5.5.9-1ubuntu4.20 (cli) (built: Oct  3 2016 13:00:37)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

ディレクトリ構成

blogの下にfuelのコード一式が入っている f:id:hs_hachi:20161116015908p:plain vagrantconfig.vm.synced_folder "./html/blog", "/data", owner: "www-data", group: "www-data"をしてるところ以外は特記するところはない。

ゲスト側の設定

php周りのインストール

add-apt-repository ppa:ondrej/php5-5.6
apt-get update
apt-get install -y php5 php5-fpm nginx php5-cli php5-xdebug

/etc/nginx/conf.d/php.conf の設定

server {
    # バーチャルサーバが使用するアドレス、ポートを指定
    listen 80 ;

    # サーバの公開ディレクトリを指定
    # /data をローカルと同期してる
    root /data/public;
    # インデックスページを指定
    index index.php index.html index.htm;

    # URIごとにどのファイルを配信するか設定
    location / {
        # 指定したパスにファイルが存在するかどうか
        if (-f $request_filename) {
            # キャッシュの有効期限を設定
            expires 30d;
            break;
        }
        if (!-e $request_filename) {
     rewrite ^(.*)$ /index.php?q=$1 last;
        }
    }

    location ~ [^/]\.php(/|$) {
        # PATH_INFO 部の分割に使用する正規表現を指定
        # 一つ目 ( .+\.php ) は $fastcgi_script_name の値になり、二つ目 ( /.+ ) は $fastcgi_path_info の値になる
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        if (!-f $document_root$fastcgi_script_name) {
            return 404;
        }
        # FastCGI サーバへリクエストをプロキシする
        #fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        # スラッシュで終わる URI の後に追加されるファイル名を設定
        # $fastcgi_script_name の値になる
        fastcgi_index index.php;
        # 設定ファイルを読み込む
        include fastcgi_params;
        # 環境設定を与える
        fastcgi_param PHP_IDE_CONFIG serverName=192.168.33.10;
        # FastCGI サーバに渡されるべきパラメータを設定
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
    }
}

/etc/php5/fpm/php.ini に追加

[xdebug]
zend_extension="/usr/lib/php5/20121212/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_host="192.168.33.1"
xdebug.remote_handler=dbgp
xdebug.remote_port=9001
xdebug.remote_autostart=1
xdebug.idekey="phpdebug"
; annot accept external Xdebug connection: Cannot evaluate expression 'isset($_SERVER['PHP_IDE_CONFIG'])' 対策
xdebug.extended_info=1

Intellijの設定

ディレクトリ構成のところで設定しているIP, /dataの設定以外に、Language & Framework > PHP > Debugのportを9001にする メニューの Run > Break at first line in PHP scriptにチェックを入れる(デバッグをOFFにしたいときはこれを外す) メニューの Run > Start Listening For PHP debug Connection を選択する ブラウザなどで http://192.168.33.10/hello/a にアクセスするとブレークポイントに止まる。 f:id:hs_hachi:20161116020529p:plain

ちなみに

  • php.iniに書いたxdebug.idekeyはなくても動いた
  • controllerにブレークポイントに置くと止まるが、自分で作ったクラスだと止まらないことがある。その時は呼び出し前にブレークポイントを漬けてF7でStepInする(多分フレームワークの規則に従ってないだけ?)
  • Rubyを書くこともたまにあるがIntelliJで書いてる。Javaで書いてたときも使ってたから体がこれに慣れてるし、1つのIDEで複数言語を書けるのは非常にコスパがいい

技術選択とQCDのトレードオフという結論がない話

経緯としては受託開発会社にiOSアプリの開発を依頼したら、Objective-C(Obで作ると言われて「え?Swiftじゃないの?」とエンジニア陣がざわついた。

同僚とオンライン・オフラインで話してたけどこれは難しい。iOSアプリ開発には詳しくないけど、技術的な制約がないのにObjective-Cかとなるのはすごいわかる。Java8の時代にこれからJDK1.4で開発しなさいと言われたらFXで有り金全部溶かした人の顔になる。AppleがこれからSwiftを使ってねと言ってて、これからObjective-Cを書ける人も少なくなってくる。書ける人が少なくなるということは、メンテコストも高くなる。

ただ、相手の会社からしたら、今のメンバー構成でQCDを守るためにはこの選択が最良と判断したのだろう。相手のスキルとかは知らないが、会社にノウハウが溜まってない技術をお客のサービスに納品するというのはリスクが高い。内製開発と受託開発ではそもそもビジネスとしてのゴールが違うのでどちらも間違ってないから余計辛い。(もちろん最初に「この技術」でという制約があれば話が別だけど今回はなかった)

言語ではないが自分もそれまで使ったことがない技術をお客のサービスにいれたことがあった。新しい技術を使わないと問題を解決できない可能性があることを伝え、技術検証も含めてスケジュール・費用はきちんと頂いて仕事をした。

自分は検証とか好きなので自宅で素振りして会社にフィードバックしてたがそれがすぐ使えるかというとそういうわけではない。ビジネス・技術の制限事項や、そもそも今のチームで運用ができるのかというところまで考える必要がある。明日自分が倒れたらコスト・リスクが高くなる技術はみんなを不幸にする。それをなくすためにもスケジュール・費用は必要なものなのだ。それがないときは出してないものは成功するか失敗するかのスタートラインにも立ててないので、出してからその負債を返すか考えたほうがいい気がしてきた。今回は負債が大きすぎるのと、それをやると後辛いんだよなぁ...

ああ、結論がない。