パラボラアンテナと星の日記

あることないこと

wercker.ymlを元にCircleCI2.0用の設定ファイルを書いてみる!

設定ファイルがめっちゃ似てる

ので移行しようと思ったら瞬時に終わります。

手元にあったrails用のwercker.yml

phantomjsはdocker image内に入れてしまっています(諸事情でrubyのバージョンが古い)

# wercker.yml
box: hoshinotsuyoshi/ruby:2.1.3-phantomjs
build:
    steps:
        - bundle-install
        - script:
            name: timezone
            code: ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
        - script:
            name: rspec
            code: bundle exec rspec

yamlを書いてみる

このファイルとかを 参考に書いたのがこちら。

# .circleci/config.yml
version: 2
jobs:
  build:
    docker:
      - image: hoshinotsuyoshi/ruby:2.1.3-phantomjs
    working_directory: /home/ubuntu/hogehoge
    steps:
      - checkout
      - run:
          name: Install Ruby Dependencies
          command: bundle install
      - run:
          name: timezone
          command: ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
      - run:
          name: rspec
          command: bundle exec rspec

これで終わりです。

ローカルで試す この方法でcircleci buildして手元テストが動きました。

こちらの記事 も見ました。

circleci.com上では、まだビルドを試したりしていない。

#serverlesstokyo #2 参加レポート (lambdaを速くする話・Azure functionsのtrial・開発ツールの話が面白かった)

#serverlesstokyo行ってきました

#serverlesstokyo meetupに行ってきました。

先に全体的な感想

というのは冗談ですが、「なんでもかんでもFaaSに任せていこう」という主旨のお話が、どんどん続いていって楽しかったです ⚡

これを見れば発表内容が全部わかるスライド一覧

こちらです --> スライド一覧

スライド抜粋

スライド抜粋1: AWS Lambdaのチューニングの話

この話が今の業務の話に一番近く、内容も身近に感じました。

以下、このスライドの紹介している「Lambdaファンクションを速くする」方法。以下に(自分に関係ありそうなところだけ)抜粋を載せます。


  • コールドスタートを速くする
    • コールドスタートを減らす
      • そもそもコールドスタートを発⽣させない
        • 定常的にリクエストが発⽣するシステムではほとんど発⽣しない
    • Lambdaファンクションに対してPingする
      • 定期的にInvokeを⾏うことでコンテナが破棄されることを回避する
      • 5分間隔程度がオススメ
    • コンピューティングリソースを増やす
      • メモリ設定
      • コンピューティングリソースの割当を増やすことで初期化処理⾃体も速くなる
    • ランタイムを変える
      • JVMの起動は遅い
      • ただし、⼀度温まるとコンパイル⾔語のほうが速い傾向
    • VPCを使わない
      • そもそもLambdaと関係なくENIの⽣成とアタッチ処理は遅い
      • コールドスタートを速くしたいならデータストアはDynamoDBが鉄則
      • DBの問題でどうしてもVPCを利⽤したい場合はDynamoDB Streamsを利⽤した⾮同期反映を検討する *1
    • パッケージサイズを⼩さくする
      • サイズが⼤きくなるとコールドスタート時のコードのロードおよびZipの展開に時間がかかる
      • 不要なコードは減らす
      • 依存関係を減らす
        • 不要なモジュールは含めない
  • ファンクションの実⾏時間を短くする
    • コンピューティングリソースを増やす
      • メモリ設定 *2
    • 各⾔語のベストプラクティスに従う
    • グローバルスコープを有効に使う
      • 初期化コードをハンドラ外に置く *3
        • AWSのクライアントやDBコネクションなど
        • Pythonの場合、辞書型の初期化など
      • ファンクションのコンテナが再利⽤される際、これらも再利⽤される
  • 同時実⾏性をあげる
    • 同時実⾏性の⾼いアーキテクチャにして処理全体のスループットを向上させる
    • 同期でInvokeすると同時実⾏数の制限に引っかかってつまりがちなので⾮同期で Invokeするのがオススメ ⎻ なお、ほとんどのイベントソースからは⾮同期でトリガーされる
    • 1ファンクションの実⾏時間は可能な限り短くすること

「初期化コードをハンドラ外に置く」はサンプルコードがそうなっていることが多いので、自然とそうなっていることは多いと思います。 不要なコードは減らす、ベストプラクティスに従う、は、まぁそうですよね。(^^)

スライド抜粋2: Azure functionの話

MSのFaaSの話。

f:id:hoppie:20170121003648j:plain

これだけたくさんの言語をサポートしてて、rubyがないのが残念でなりません。

f:id:hoppie:20170121003638p:plain

このデモ環境 で試すことができる。

実際動かしてみましたが、結構分かりやすかったです。 操作画面は、AWS Lambdaのやつより、使いやすい印象。

スライド抜粋3: 利用されているフレームワークの話。

オープニング のこの話も面白かった。

f:id:hoppie:20170121003537j:plain

ServerlessFramework、 apexが人気。

会社内でもこの2つを使っていますね。


以上です。

*1:DynamoDBに書き込まれてからRDBMSに非同期で書き込まれる、ようにする。

*2:「メモリ設定」なのであるが、増やすと、比例してCPU割当も増えるとのこと。

*3:「const s3 = new AWS.S3();」みたいなのをハンドラの外に置くという話かな。

静的解析ツール「RubyCritic」のUIが良くなっていたので紹介したいです!

この記事は feedforce Advent Calendar 2016 - Adventar の2日目の記事です。

1日目は 源義経のシンプルな考え方が好き - Marketing book でした。良い話だ。(ちなみに大河ドラマ平清盛だった年は、我が家では後白河院の評価が高かったです。懐かしい。)


RubyCriticのご紹介

rubyエンジニアなのでrubyのことを書きます。

RubyCriticrubyコードを静的解析するツールです。rubygemで提供されています。

単純な使い方としては、$ gem install rubycritic するなりbundler使うなりしてインストールし、

$ rubycritic .

を実行します。$ rubycritic ./app ./lib のように、指定のディレクトリだけを対象にして実行することもできます。

実行すると./tmp/rubycritic/の下に解析結果がhtmlで保存され、ブラウザが起動して閲覧することができます。

version3.1.0(先月リリース)で大幅なUI改善がありました! 🎉 色付きになってわかりやすくなりました。以下gifアニメ。

f:id:hoppie:20161202053159g:plain

このissueこのPRで、ゴリッと入ったようです。 🎅

色の使い方とかは、コード解析のSaaSであるCodeClimateに似てるな、と思いました。 CodeClimateのグラフとかはこんな感じ -> CodeClimate - Google画像検索

RubyCritic version 3.1.0の出力イメージ

とある大きめのサイズのrailsプロジェクト*1を手元にクローンして、rubycriticを走らせてみました。

トップ画面

f:id:hoppie:20161129065614p:plain

モジュールごとの解析結果一覧

f:id:hoppie:20161129065555p:plain

smellの一覧

f:id:hoppie:20161129065600p:plain

コード上の問題箇所の表示

f:id:hoppie:20161129065551p:plain

ズームインできる(gifアニメ)

https://cloud.githubusercontent.com/assets/1394049/20687781/2e02c952-b601-11e6-9677-fb567ab6bcf5.gif

(ちなみに、以前は以下のように、モノクロ〜な感じでした。)

以前のトップ画面

f:id:hoppie:20161129065548p:plain

RubyCriticの中身をちょっと覗いてみる

RubyCriticは、以下のruby解析用Gemに依存しています。

  • reek
    • reekにおいて定義された、smell(コードの"臭う"箇所)を検出します。
      • reekのドキュメントによると、smell は、「コードが読みにくい、または保守しづらい場所を示唆するもの」とのことです。
    • smellの一覧はこちらです。
  • flay
    • コードどうしの類似度が高い部分を検出します。
  • flog
    • 複雑度の高い部分を検出します。

Churn and Complexity のグラフ の見方等について

このグラフの意味は、こんな感じです。

f:id:hoppie:20161202070926p:plain

Complexity

Complexity は、ABC(Assignment/Branches/Calls)のサイズです。低いほど良い。 RuboCopにもABCサイズを測るやつがありますが、 それと似たような感じだと思います。

Churn

Churnは、ファイルのコミット回数(=ファイルの変更回数)です。 裏側ではgitを叩いてチェック(!!!)していました。

ソースを読む限り、gitの他にはmercurialとかに対応しているっぽいです。

これも低いほど良い、とのことですが、歴史の長いリポジトリほど高くなるのは仕方ないので、あくまで相対的に他のファイルと比較するものだと思います。

Rating

ファイルごとにRatingがつきます。これはA〜Fで表され、色は緑〜赤で表されます。Aに近いほど良い。

前述のComplexitysmellの量が、このRatingに影響します。

こんな感じで計算している様子でした。

reekが検出するsmellのカスタマイズについて

reekが検出するsmellはだいぶ個性的なので、もしかしたらルールによっては、使う人の肌に合わないものもあるかもしれません。

リポジトリのトップにyamlファイル(.reekファイルまたはconfig.reekファイル)を置くことで、reekが検出する特定のsmellをカスタマイズして抑制することができます。

READMEのこのあたりにやりかたが書いてあります。

まとめ・感想

reekのsmellは個性的なので、うざく感じるかもしれませんが、とりあえず走らせてみると、何か気づきがあるかもしれません。

CodeClimateと似ているかもしれませんが、コードの内容を外に漏らさずに、手元のみで完結できるというのは、選択肢が増えて良いと思いました。

メリークリスマス。

追伸

feedforce Advent Calendar 2016 - Adventar の3日目はこちらです

hanocha.hateblo.jp

参考リンク

github.com

github.com

github.com

github.com

*1:今回railsアプリであるrubygems/rubygems.orgを使いました