べにやまぶろぐ

技術寄りの話を書くつもり

Colored Hashtag for Trello を v1.0.3 に更新しました

こちらの Chrome 拡張ですが、

jQuery のセレクタで無駄に引き直しているところがあったのでそこを修正しました。また、Plus for Trello 拡張を意識して、複数のハッシュタグがある場合に先頭のものを使用するようにしました。

詳しくはこちらの GitHub で。

セレクタの性能改善については、一回 .list-card-title で個々のカードを引きにいった後、そこで取得した shortID でもう一回 .list-card-details で色塗りする親をセレクタで引いていたのが性能劣化を起こしていたので parent() で済ませるようにしました。

実行速度的には timer1 をセレクタで引き直すもの、timer2 を parent() で引くものとしたとき

coloredhashtag.js:95 timer1: 15.673ms
coloredhashtag.js:101 timer2: 0.042ms
coloredhashtag.js:89 ----
coloredhashtag.js:95 timer1: 14.759ms
coloredhashtag.js:101 timer2: 0.028ms
coloredhashtag.js:89 ----
coloredhashtag.js:95 timer1: 17.747ms
coloredhashtag.js:101 timer2: 0.027ms
coloredhashtag.js:89 ----
coloredhashtag.js:95 timer1: 13.844ms
coloredhashtag.js:101 timer2: 0.028ms
coloredhashtag.js:89 ----
coloredhashtag.js:95 timer1: 12.155ms
coloredhashtag.js:101 timer2: 0.029ms
coloredhashtag.js:89 ----
coloredhashtag.js:95 timer1: 13.309ms
coloredhashtag.js:101 timer2: 0.028ms
coloredhashtag.js:89 ----
coloredhashtag.js:95 timer1: 12.999ms
coloredhashtag.js:101 timer2: 0.027ms

という感じでカード一つの処理あたり 10 - 20 ms 程度の性能改善が見込まれます。今回実行速度も測ってみて、クラス名で引きにいくのはコストかかる処理だということを再認識しました。

Trello のハッシュタグをもとにカードに色づけしてくれる Chrome プラグイン "Colored Hashtag for Trello" を Yeoman を使って作ってみた(その2)

↑ を作ってみたシリーズ、前回の記事 の続きです。

タイトルにもありますが、今回初めて Chrome 拡張機能を作るに当たって、以前 勉強会 に参加してから気になっていた YeomanChrome Extension Generator を使ってみました。

node.js のサイト から node.js および npm をインストールし、続いて Getting started with Yeoman | Yeoman にあるように

$ npm install -g yo bower grunt-cli

などとして Yeoman、Bower、Grunt を呼べる状態にします。

続いて Chrome Extension Generator に書いてある通り

$ npm install -g generator-chrome-extension

として準備完了。

$ yo chrome-extension

とするとシェルが起動し、インタラクティブに Chrome Extension のテンプレートを作成することができます。

$ yo chrome-extension
? What would you like to call this extension? Colored Hashtag for Trello
? How would you like to describe this extension? This is my first chrome extension
? Would you like to use UI Action? No
? Would you like more UI Features?
? Would you like to use permissions?
   create Gruntfile.js
   create package.json
identical .gitignore
identical .gitattributes
identical .bowerrc
...
grunt-contrib-imagemin@0.7.2 ../node_modules/grunt-contrib-imagemin
├── pretty-bytes@0.1.2
├── async@0.7.0
├── chalk@0.4.0 (ansi-styles@1.0.0, has-color@0.1.7, strip-ansi@0.1.1)
└── imagemin@0.4.9 (stat-mode@0.2.0, ware@0.3.0, rimraf@2.2.8, image-type@0.1.4, nopt@3.0.1, tempfile@0.1.3, fs-extra@0.10.0, imagemin-svgo@0.1.1, imagemin-pngquant@0.1.3, imagemin-jpegtran@0.1.0, imagemin-gifsicle@0.1.1, imagemin-optipng@0.1.0)

というように Bower と Grunt が走り、Chrome 拡張機能の開発に必要なパッケージ群がセットアップされます。

ディレクトリ構成はこんな感じ。

$ ls -l
total 32
-rw-r--r--   1 beniyama  beniyama  7582  1  4 17:45 Gruntfile.js
drwxr-xr-x   7 beniyama  beniyama   238  1  4 17:45 app
-rw-r--r--   1 beniyama  beniyama   112 10  1 08:36 bower.json
drwxr-xr-x  23 beniyama  beniyama   782  1  4 17:45 node_modules
-rw-r--r--   1 beniyama  beniyama   893  1  4 17:45 package.json
drwxr-xr-x   7 beniyama  beniyama   238  1  4 17:45 test

この状態でもすでに manifest.json などに適当な値が入っている状態ですので、

$ grunt build

などとすると

$ grunt build
Running "clean:dist" (clean) task

Running "chromeManifest:dist" (chromeManifest) task
Build number has changed to 0, 0, 2

Running "useminPrepare:html" (useminPrepare) task
Going through  to update the config
Looking for build script HTML comment blocks

Configuration is now:

  concat:
  { background:
   { src: [ 'app/scripts/background.js' ],
     dest: 'dist/scripts/background.js' } }

  uglify:
  { 'dist/scripts/background.js': 'dist/scripts/background.js' }

  cssmin:
  {}
...

のように バージョン番号のインクリメントや JS ファイルの uglify、結合などをデフォルトで行ってくれます。package ディレクトリ下には Colored Hashtag for Trello-0.0.2.zip というような名前でパッケージが生成されますので、最終的に Chrome ウェブストアに登録するのはこのファイルになります。

開発フェーズでは、Chrome から直接ローカルのプロジェクトを読み込んで開発・テストを行うことができます。Chrome で chrome://extensions/ にアクセスすると『パッケージ化されていない拡張機能を読み込む』というボタンがありますので、そこから manifest.json のある app ディレクトリを指定すると下記のようになります。

f:id:beniyama:20150104182015p:plain

デフォルトでは Yeoman のアイコン画像をはめておいてくれます。また『リロード』というリンクを押すことで、grunt build し直したプロジェクトをブラウザに反映させることができます。livereload もサポートしているようなのでこの辺はソースを変更すると勝手に反映する、というのもできそうです。

ちなみに IDE ですが、IntelliJ IDEA を試してみたところなんと Grunt 用のコンソールが用意されていたりして、かなり開発しやすかったです。

f:id:beniyama:20150104182841p:plain

この Grunt Console を開くと

f:id:beniyama:20150104182853p:plain

のような小窓が開いて Gruntfile.js に定義されているタスクを GUI から呼べたりします。時代は Gulp という話も昔聞いたのですが、この辺ちゃんとサポートされていて驚きました。なんとなく Java の IDE というイメージを持っていましたが、web 開発全般で活躍してくれそうだったので PHP Storm に引き続き有償版を購入してしまいました。

次回は内部実装の話を書きたいと思います。


↓ 続きの記事

↓ 前回の記事

↓ Yeoman 周りの話題が出た勉強会

Trello のハッシュタグをもとにカードに色づけしてくれる Chrome プラグイン "Colored Hashtag for Trello" を Yeoman を使って作ってみた(その1)

あけましておめでとうございます、今年もよろしくお願いいたします。

年末はインフルエンザで寝込んでいたのですが、休暇中に作りたいものも一杯あったのでちょこちょここんなのを作ったりしていました。何気に元旦リリースです。

Colored Hashtag for Trello - Chrome ウェブストア

ちなみに GitHub はこちら。

GitHub - beniyama/colored-hashtag: Chrome extension plugin to color Trello cards according as their hashtags.

読んでの通り、Trello のタイトルにハッシュタグを含めるとそれに応じてカードの背景色を変えてくれます。

f:id:beniyama:20150104012317p:plain

こんな感じ。

Trello はデフォルトでもハッシュタグを打つと都度色の違うラベルを薦めてくれるようですが、ラベルはラベルで他の用途に使っていたりもするので背景色をまるっと変えてしまいました。

例えば自分のチームだと、ストーリーに紐づくタスクにはストーリー番号をハッシュタグで打って、ラベルでは『障害』とか『ToDo』とかのタスク種別を管理するようにしているのですが、結構(ストーリー)番号で確認するのって確認コストがかかってしまってコミットしたストーリーをきちんと終えるのにどれだけのタスクが残っているのかわかりづらかったりしていました。

なので色づけして、色がついているタスクはストーリーに紐づいているので優先度が高く、かつどのストーリーにどのタスクが紐づいているか色の種類でぱっと見でわかるといいなと思って作ったのが今回の作品になります。

色とか自分で設定できたらいいなとかはあるんですが、一旦リリースしてまずはチームとか、部内からのフィードバックもらいながら改善できればと思います。あと今回は兼ねてから気になっていた Yeoman の generator-chrome-extension を使っての、しかも初のブラウザ(Chrome)拡張機能開発で、コード自体はたいしたことないものの色々勉強することが多かったです。特に Trello って AJAX の極みというか、かなり柔軟な UI なので拡張機能もいろいろ考えること多くてそれはそれで大変でした。

その辺のトピックも追々ブログに書いていければと思います。

↓ 続きの記事を書きました

GitLab 7.5.3 でマージリクエスト時のコミットログが大量に表示される問題が解消

GitLab 7系に上げてから出ていた表記の問題、下記の stackoverflow にあるようにブランチ比較に使われている git ラッパーの Rugged のバグに起因するものでした。マージリクエストを作成するとブランチ間の差分コミットが全履歴分?出てしまって画面で diff を表示できない、そもそもブラクラになってしまうというものでした。

これも stackoverflow に書かれているように Gemfile.lock の Rugged のバージョンを 0.21.2 に手で修正して bundle install をやり直すことで回避できていましたが、ようやく最新の 7.5.3 で正式に解消されたようです。

GitLab 7.5.3 Release | GitLab

GitLab 7.5.3 updates Rugged to 0.21.2 to solve issues with 'finding too many commits'. This issue could cause the PostReceive job triggered by a git push to take a very long time and consume a lot of memory.

Docker Hub と GitHub を連携させて、SparkR を RStudio から呼び出せるコンテナイメージを公開してみた

バージョン : Spark 1.1.0

長ったらしい題名ですがそのまんまです。以前書いた お手軽に Spark と SparkR を触るための Dockerfile 書いてみました。 - べにやまぶろぐ で Apache Spark と SparkR をセットアップして RStudio とつなげてみたもののそれからメンテナンスできてなかったので Spark も 1.1.0 になったことだしと思って更新しました。

こちらが GitHub です。

ところが Spark のビルドってすごい時間かかるのでもういい加減構築済みのイメージ提供しましょう、ということで今回初めて Docker Hub に登録してみました。

こちらは Docker Hub。

Docker Hub ですが、GitHub に Dockerfile 載せておけば push が走るたびに docker build を自動的に流せる Automated build が便利すぎます。詳しい解説は Docker Hubの使い方とGitHubからのDockerイメージ自動ビルド:いまさら聞けないDocker入門(終)(1/2 ページ) - @IT にあるので割愛しますが、ローカル PC をひいひい言わせなくてもクラウドでビルドして出来上がったら勝手にリポジトリに登録して docker pull とかすれば誰でも使える状態にしてくれます。

f:id:beniyama:20141202011403p:plain

Docker Hub へは GitHub のアカウントでログインできますし、GitHub の README.md も勝手に Docker Hub のページに同期してくれるので、いちいち同じ説明を書く必要がありません。よく考えられてるなぁと思います。

README にも書きましたが、

$ docker pull beniyama/sparkr-docker
$ docker run -d -p <YOUR PORT>:8787 -t beniyama/sparkr-docker

などとして

$ boot2docker ip
The VM's Host only interface IP address is: 192.168.xxx.xxx

で boot2docker vm の IP を確認、そして http://192.168.xxx.xxx:<YOUR PORT>にアクセスすれば SparkR 梱包済みの RStudio をすぐ使えますので是非お試しいただければと思います(初期アカウントは rstudio/rstudio)。

↓ 昔の記事

Intel Edison Breakout Board Kit で遊んでみる(その2)

Intel Edison Breakout Board Kit で遊んでみる(その1) - べにやまぶろぐ の続きです。

本当は今頃センサつなげているはずだったんですが GPIO 周りの調査していたり、そもそも Breakout Board Kit には Analog Input がないらしい(Intel Edison Board for Arduino にはある) というところでもたついているので今回は乾電池で Edison 動くか実験してお茶を濁そうと思います。

参考にするのはこちらのドキュメント。

Hardware guide によれば

The left pin (the square one) on J2 is +V battery; the right pin is ground.

とあり、かつスケマには BAT1 / BAT2 とあるので J2 を使ってみます。

今回、横着して手で接触させて動作確認したいだけなのでちゃんと起動しているかは J3 側の USB を母艦と接続して screen でコンソールを確認します。

ちなみに J3 は

J3 is a micro USB FTDI serial-to-USB converter. The Linux console will output serial stream to this USB connector.

というようにシリアルのインタフェースを提供してくれます(前回つないだのはもう一方の J16 でした)

f:id:beniyama:20141126012541j:plain

USB 接続後、母艦の Mac 側で

screen /dev/cu.usbserial-AJ035HM1 115200 -L

などと実行します(cu.usbserial- の後は違う文字列になっているかもしれません)。

その上で、今回とりあえず手元にあった単三のエネループ2本直列につないで 2.5V 弱供給してくれる乾電池パックの線を J2 に接触させてみます。

f:id:beniyama:20141126010716j:plain

LED がチカチカし始め、コンソールには

f:id:beniyama:20141126020607p:plain

などと流れ始めて boot の予感。

f:id:beniyama:20141126020641p:plain

なんか Battery Over heat exception とか出てる...

f:id:beniyama:20141126020720p:plain

途中なんかこけてるけどとりあえずログインまでたどり着きました。

一応 boot はしましたが、とても雑なのでもう少しちゃんと配線してログ見てってとこは引き続きやっていこうと思います。特に 2.3.1 Boot voltage selection – DCIN signal の辺り読んでいると最低限 boot しただけっぽいので。もう少し読み込む必要あり。

ちなみに J2 は

J2 is the battery connector. If you want to power the breakout board with a rechargeable lithium-ion battery, attach it to J2. (Refer to Figure 2 for battery polarity.) When you attach a rechargeable lithium-ion battery, the breakout board will recharge the battery whenever power is applied via J21 or J22, or via J3 (when the board is attached to a USB host).

などとあって USB 給電からの充電なんかもできるそうです。こちらも併せて試してみたいところ。

↓ 前回の記事です

AJITO(アジト)×キャリア・ラボラトリー アドテク勉強会(11月21日開催)に参加してきました #ajiting

VOYAGE さんの AJITO で開催されている勉強会 http://careerlaboratory.jp/archives/656 に参加してきました。

登壇者との距離が非常に近くて、いろいろと貴重なお話を聞かせていただきました。メモの公開許可を頂きましたので、おそらく差し支えないであろう範囲で書かせていただきます。

「SSP:FluctでのBlue-Green Deproyment事例」 (@_nishigori さん)
  • @_nishigori さん : adingo の DevOps エンジニア
  • Fluct SSP で blue green deployment を実現している
  • AWS の Route53 を使ってバランシング対象を切り替えている
    • ELB & autoscaling
    • EC2 instance & puppet
    • service in (green)
    • service out (blue)
  • 最初から設計していたわけではなく、結果的にそうなった
    • impression 増大でサーバに同梱している CookieSync は他に逃したかった
    • オンプレを徐々に AWS に移行した
    • オートスケーリングをスケジューリングしている
    • サービスインしていないほうで ServerConfiguration もデプロイも全て試せた
    • AWS での Management Console 上での操作が辛かった
    • ELB の Pre-warming には事前に電話での申請が必要だった
    • AWS-Cli は JSON ばかりだった
    • Elastic beanstalk もあるがそこまで AWS にロックされたくなかった
    • 突然 EC2 instance が reboot したりする
    • 息を吐くようにインスタンスを上げ下げしたい
  • aws 用デプロイツールを作った
    • YAML で設定を書ける
    • ELB なんちゃって warm up ができる(徐徐に負荷を上げる)
  • 今後は AMI にして構築済みのイメージをデプロイするようにしたい
  • その先に RDB などはつながっていない
    • DB は blue green にするコスト見合っていない
  • 切り替えは 20分以上かかる
  • テストについて
    • cookie を焼けたかのテストはインスタンス上げたときにテストしていて、落ちたらサービスインできないようになっている
    • テストをした環境が本番になるといいなという気持ち
「Scalaのアドテク事例」(@katzchang さん)
  • Zucks Ad Network : スマホ向け課金型広告ネットワーク
    • Scala : 広告配信サーバ
    • PHP : 管理画面
    • Scheme (Gauche) : バッチ処理
      • fluentd と連携させて使っている
      • Scala より質問が少ないくらいなじみやすい (SICP の本の読書会をやっている)
  • Fluentd, Tomcat, AWS, GitHub, New Relic(モニタリング)...
  • Scala : 少量で高いスループットを安定して処理する必要がある
  • 最初は Java で書いていた
    • 広告配信はフィルタの連続 : Function, Predicate クラスを独自実装
    • 不具合なくしたい == ぬるぽなくしたい Option クラスを独自実装
      • Scala は Option 便利
    • IDE がしっかりしていてリファクタリングができる
      • IDE は IntelliJ
  • Scala のつらくないところ
    • プログラマの確保、みんな書ける
    • GC 問題、たまに応答ないけれど全体としては稼げてるのでとりあえず問題ない(たまにフルGCかかるけど全体的には商売で稼げてる、許容できないとしたらそもそも JVM 向いてない)
  • つらいところ
    • コンパイル遅い、sbt 複雑すぎる(マルチプロジェクト構成の資料がない)
      • 普段は立ち上げっぱなしでコマンド打ったりしている
    • パフォーマンスの予測がつかないところがある
    • リリース後5日感がサーバ台数増やしてチューニングの時間を稼いでいた
    • 直接 DB につながず、内部にハッシュマップを持たせて掲載しているメディアの情報等を引いていた
      • 恐ろしく遅かった
      • ベースになる JSON のマッパーの実装が悪かった疑惑(罠)
    • Tuple で ((int),(int)) のハッシュマップ使っていたりしたとき New Relic で見たときサーバリソースの3割使っていたりした
      • Hash 値計算に時間がかかってた
      • Case クラスをキーにすることで解消、全体のスループットが2割くらい上がった
        • pre compile されたハッシュコードを持っている??
        • 3,000 件の get に 50ms かかっていた
      • Scala のバージョン 2.1 くらい
    • toList とか気軽に使わない
      • 数メガから数百メガのファイルを読まないといけないとき全行一気にメモリに全部載せてしまっていたので、一行一行処理してやるようにした
      • Java の BufferedStream だとあまり問題にならないだろう
  • Tomcat => とりあえず servlet でもそれなりのパフォーマンスは出る
  • ID をもらって広告をハッシュマップで返す
  • New Relic 見るとどのプロセスがリソース使用しているか一目で見える

参考)