Signet gem + HttpLog gemがよかった

Signet gem

以前紹介した

Rails OAuth Provider Example

を利用して OAuth2 client の挙動を確認していたが、OAuth2 gem という誰よりも大事な名前を使っている gem で試してみたところ、そもそも OAuth2 gem の挙動があやしいことに気がついた。どう考えてもメジャーなのにドキュメントと挙動が合ってないように見える。少なくとも上のデモアプリでは期待通りに token を取得することができない。そこで代わりに使ってみたのが ruby-toolbox ですぐ近くに見えるこれ。

googleapis/signet: Signet is an OAuth 1.0 / OAuth 2.0 implementation.

当然だけど Google が自前の SDK を書く際に OAuth の部分はこれにお任せにしているので、利用実績も十分に多いと言ってよさそう。

やってみたらサクッと動いた。なんだったんだ OAuth2 gem …

HttpLog gem

OAuth2 gem も Signet gem も内部で HTTP の部分は Faraday に依存していて、挙動をどうしても細かく確認したくなったのでしばらく log の設定をゴニョゴニョやっていたんだけど、外から設定を入れる方法がどうにもよく分からない。積極的に自分で Faraday を使ったことがないので。そこで別なアプローチを採ることにした。そのために活用できたのがこれ。

trusche/httplog: Log outgoing HTTP requests in ruby

完璧に意図通りではないが、概ね期待通りに動く。いろんな HTTP ライブラリの挙動を外部から logging できる。これはなかなか便利。

Rails + Browserify + Mithril + cmsxで動くもん書いてみた

作った

これはなにか

  • GitHub の活用の幅を広げていくにあたって Issue のテンプレートがほしいと思ってたけど、最終的には URL を作る必要があるので、それを作るものを作った
  • Rails である必要はまったくなかったけど、裏側の作り込みを考えると組み合わせ的にはよく使いそうな感じが再現できて満足
  • ついでに Material Design てなんだろうと思って、あえて完全な gem を作りようのない Semantic UI を使ってみた

参考になるのはここら辺。

すでに似たようなのは当然世の中にある。

あとはテンプレートのノウハウを集めて作るだけ。こんなのは実は GitHub 時代に入る前の BTS と呼ばれてる時代から言われてたこと。いちばん最初にへーと思ったのはシックスアパートの以下の記事でした。

TypePadのテストで使っている3つのツール - Six Apart ブログ

近況

  • Heroku の multi buildpack を試してみたかった
  • 何やら最近は Rails の AssetPipeline が不人気らしい
  • Browserify Handbook を読んで npm のポリシーのよさ、そのよさに乗った開発をできるよさを知った
  • Mithril 本を読んでとりあえず何か書いてみなきゃと思った

これで夏休み前くらいからちまちまやってたことが一応区切れた。満足ぢゃ。

歴史

自分のスペック的なものなど。こういう経歴なのでこんなこと考えるんだな、こいつは、みたいな判断材料に使ってください。

  • Ruby と CoffeeScript が好きだけど、対レガシー PHP 戦歴もそれなり
  • JavaScript のフレームワークは Backbone.js, Angular1 をつまみ食い程度に
  • 一応 Jasmine でテストとか書けなくもない（今後は Mocha + power-assert にしたい）
  • Node.js は単なるユーザー。bower もタスクランナーも安定しないので敬遠してたらいい具合に npm に集約されそうでラッキー。
  • Rails は Rails 3 時代を中心に少々
  • SPA には縁がないが、Hybrid モバイルアプリでサクッと動くもんを作りたい、みたいなことは思ってる

感想

  • Heroku の multi buildpack は楽ちん
  • ブラウザのロードを契機とせずに watchify で回すのも悪くないかも

cf.

heroku/heroku-buildpack-multi

Mithril

  • Mithril は m.withAttr の名前以外はマジカルさも少なく、素直に書けてよい感じ
    • ただ、class も何もないっつーのは逆に覚えにくいので、API が少ないと言ってもやはりリファレンスが手放せない予感がちょっとしてる
  • 単に form の各要素を監視して値を計算して DOM を更新するだけなので AngularJS が日本で有名になりはじめの頃のサンプルに近く、あまり Mithril 向きじゃないかなと思ったけど、独自タグとかディレクティブがないので普通に JS でループ処理したり、割と楽に書けた
  • JSX クソきもいとか言っちゃってごめんなさい。CoffeeScript + MSX ( JSX for Mithril ) 快適です。

ただ、きっちりした型が（言語的な意味ではない）あった方がよい場合もあるので、AngularJS なんて不要とか言うつもりもないし、足りないものだらけなので、大きなアプリを書こうと思ったら、スケールはするかもしれないけど、実装力高くないとつらそうだなとは思う。

cf.

npm + browserify

きっかけは

俺の最近のRailsのJS開発環境を教えてやる - Qiita

で Sprockets で require するのはいいけど development 環境では GET の log が溢れかえって困るなーなんてことを思っていた時に上の記事を見かけたことだった。一応去年のうちに Browserify の名前は知っていたみたいだけど、この時まですっかり忘れていた。

  • npm の package 管理と npm run でやりたいことはだいたいカバーできてよい。まだ minify とかちゃんと見てないけど、最適化が仕事の中心ではないと理解しているので、概ね満足。
  • Browserify の transform とか、JS が変換前提になりつつある今、Sprockets だけでそれについていくのはやはり厳しい
  • 一方で Browserify もあくまで npm の世界観の一部をブラウザの世界に持ってくるためのものであって、asset 管理を全部任せようとするのは無駄に仕事を複雑にするのでよくない。AssetPipeline の方が楽できることもある。

Rails との組み合わせ方だけど、

Using Browserify with Ruby on Rails

を参考に、npm run で必要なコマンドを叩くだけにした。browserify-rails/browserify-rails よさげだったけど、結局 package.json に書くようなことを Rails の config に書くことになり、rails server が動いてブラウザでアクセスしないと browserify が動かないので邪魔くさいということが分かってやめた。

自分なりに工夫したのは Heroku の buildpack としては先に Node.js が動いて npm install + postinstall で browserify が動くようにしたことと、どうせ Heroku で Procfile を使うので、watchify は foreman で起動するようにしたこと。1

cf.

AssetPipeline

  • 上手に gem になってる asset を扱わせた時の楽さは最強
  • 自分で asset を足していく場合、minify 済みの asset の扱いが苦手なので precompile 設定が外せず、面倒
  • require されてなくても対応拡張子に対してとりあえず変換が走るのうざい、vendor 以下に置いてしまえ

Material Design

いろいろ気づきはあったけど割愛。

Semantic UI

導入方法はともかく、記述量は増えるけど割と直感的に書ける気がする。リファレンス首っ引きにならずとも、たぶんこんな感じだよね？が通じるのは嬉しい。

twitter bootstrap のように標準の域に行くのは難しいかもしれないけど、なかなかよいものだと思う。

deploy時生成2にこだわってたわけ

  • repos を小さく保てる
  • git grep 時に minify した JavaScript が引っかかるとか不幸すぎる
  • gem の読み込みとか node_modules からの deploy 時生成なら repos に入ってないからよい

実際には全部 deploy 時に生成するのは難しく、例えば Semantic UI は npm install 時に自分で build も行おうとするので gulp 必須で build 済みの asset をどう扱うかを考えざるを得ない。

今回、

  • .gitignore 対象ディレクトリ以下に asset を –force add
  • git grep –exclude-standard –no-index で探すと asset が引っかからない

ということを知ったので、repos の容量に影響しやすい font などを除いてこの形でいいような気がする。（font はでかいので CDN で解決できるならそれがベストなのではないかと思う）

まとめ

今回、Browserify と Mithril の二つをメインのキーワードに据えて、ちょっとイマドキなフロントのコードを扱ってみたいということで形にできたのはとても満足している。

次は Electron かな？ いやーどうだろう。

  1. バックグラウンドに回ってしまうので終了が面倒くさくなるし、もし Un*x 的なプロセス管理とかに興味のない人にも開発に参加してもらおうと思った場合は間違いなくこの方がよい。 ↩

  2. rails の assets:precompile のようなもの ↩

ブラウザのリロード自動化2011秋

※ 2011秋っていうのは自分用に書いてあるだけで、決して 2011 年の本当の最新情報ではないです1。

何年も前からいろんな形でくり返し出てきてる話だけど、みんなもっと楽しようぜ。いったいオレたちは何回リロードすればいいんだい？

まとめ

ということで今回はブラウザのリロード自動化の話。どういう形でこれを実現しているのか調べてみた。

Rubyist 的には LiveReload がイチオシなんだけど、まだ開発途上な部分がアレコレあって Windows 環境にはややつらい。2それでも Windows で動かしようのない npm 依存のものよりはマシだし、使い勝手はいいと思う。

以下の記事もあわせて読みたい。

背景

  • View や CSS、効果系の JavaScript の編集は細かい変更を目視で確認しながらくり返すことになりがち
  • 広範囲に渡る変更の場合、多くのページを開きまくる必要がある
    • 思いがけない影響が出ていないとも限らない

ダルい

ダルいのは機械に任せてしまおう。

自動化の実現方法

大きく以下の2通りに分かれる。

  1. やみくもに reload する ( 数秒おきとか )
    • どちらかというとオークション監視向け
  2. ファイルの変更を監視して reload させる

reload方法

  • HTML の中に JavaScript を仕込んで location.reload
    • OS、ブラウザを選ばないが HTML を書き換える必要がある（手で？ 自動で？）
  • OS の機能などでアプリの操作を自動化 ( AppleScript or WSH or AutoHotKey … )
  • ブラウザの拡張で
    • MozRepl, Firebug, LiveReload, …

ファイルの変更監視方法

できるだけ OS レベルでサポートされている方法が軽いし速いが、力ずくでも監視できる。説明がこみいってしまうので詳細は割愛。

監視と通知が分離していない形態もある。

ファイルの変更通知方法

  • 直接エディタやブラウザからファイルの status を取得
  • XMLHTTPRequest で status を渡す
  • WebSocket <- New !

ブラウザのautoreload拡張

では具体的なツールの話。

やみくもにreloadする

ファイル監視系

監視ツールと組み合わせる系

多少手間は増えるけど速い。リソース的にも多少有利？

vogue

http://aboutcode.net/vogue/

  • node.js + npm 依存
  • 各ページに reload 用の js を噛ませる必要がある
    • user script で噛ませる方法もあるらしい
  • ブラウザを選ばない

試してない。

livereload系

LiveReloadが超気持ちいい2011 へ。個人的にはいちばんのオススメ。

nodejuice

nodejuiceがヤバい2011へ。ヒトバシラーが増えるといいな。

自分で組み合わせてなんとかする方法

頑張るのが好きな人向け。あるいは頑張った人たちの歴史。

ほか

もう一度まとめ

ブラウザの自動リロードについては何年も前から様々な工夫がなされてきている。どれを使っても自分の目的が達成できればそれでよいとも言えるが、最近は LiveReload など完成度の高いツールが出てきていて、もう少し導入が楽になれば一気にブレイクするんじゃないかと感じている。

こうしたツールは1ページしか書かないうちは、あるいはあまり HTML, CSS, JavaScript を多く書かないうちはメリットを感じないかもしれないけれど、CSS や JavaScript は予想外に影響範囲が広くなりがちなので、あるところだけをいじっているつもりがうっかり別な場所を壊していたということも十分あり得る。

最近はそういう事故を防ぐためにも上に挙げたツールで押さえておきたいページを全部自動でリロードさせるという使い方をしているが、これはなかなかよい。マシンの負荷は当然上がるが、リロードという作業は完成するまでやり続ける単純作業なので、導入に多少コストを掛けても十分お釣りがくるし、安心感がまるで違う。もちろんチェック自体を目視ではなくシステムによるテストに置き換えていくなどの工夫もできるだろうが、目視でなくては確認できない効果は目視せざるを得ない。そういう意味では完全に CI に置き換えが効くわけでもなく、エンジニアにもデザイナにも嬉しいツールだと思う。

ぜひ多くの人に使ってほしいなぁと思う。

  1. 一部アッチッチの開発版があるけど、技術的には新しくない。いや、新しくなきゃいけないってもんでもないけど。 ↩

  2. 正解はあるのでそれに忠実にしたがっているなら苦労はない。 ↩

レゴマインドストームが Mac 対応してる

教育を語っておきながら Windows にしか対応してないなんて日本の製品みたいなこと言ってんじゃねーよと思っていたんだけど、去年出たやつが Mac でも動くじゃないか。

うわあああああ。

たけぇ。4万か。

いや別に今すぐ欲しいってほど欲しくはないんだけど、一つ障害が減っちゃったなぁと思って。

なんで突然マインドストーム？って思ったでしょ。マシン語の話をしてて思い出したのさ。マシン語で書くわけじゃないけど、今の子どもが自分たちの時代のように実機でのめり込めるような低レベルなものっつったらやっぱマインドストームだべ、と思い出したの。

スウィングガールズ

うーん。

いやまぁ楽しいんだけど。同じ監督とはいえウォーターボーイズと同じすぎませんか。特に竹中直人は起用すべきでなかったと思う。あまりに印象が似てしまう。

こういう分かりやすい展開でもう少し高校生というずるい年代を外した映画って出てこないかな。

About

例によって個人のなんちゃらです

Recent Posts

Categories

Tool 日々 Web Biz Net Apple MS ことば News Unix howto Food PHP Movie Edu Community Book Security Text TV Perl Ruby Music Pdoc 生き方 RDoc ViewCVS CVS Rsync Disk Mail FreeBSD Cygwin PDF Photo Zebedee Debian OSX Comic Cron Sysadmin Font Analog iCal Sunbird DNS Linux Wiki Emacs Thunderbird Sitecopy Terminal Drawing tDiary AppleScript Life Money Omni PukiWiki Xen XREA Zsh Screen CASL Firefox Fink zsh haXe Ecmascript PATH_INFO SQLite PEAR Lighttpd FastCGI Subversion au prototype.js jsUnit Apache Trac Template Java Rhino Mochikit Feed Bloglines CSS del.icio.us SBS qwikWeb gettext Ajax JSDoc Rails HTML CHM EPWING NDTP EB IE CLI ck ThinkPad Toy WSH RFC readline rlwrap ImageMagick epeg Frenzy sysprep Ubuntu MeCab DTP ERD DBMS eclipse Eclipse Awk RD Diigo XAMPP RubyGems PHPDoc iCab DOM YAML Camino Geekmonkey w3m Scheme Gauche Lisp JSAN Google VMware DSL SLAX Safari Markdown Textile IRC Jabber Fastladder MacPorts LLSpirit CPAN Mozilla Twitter OpenFL Rswatch ITS NTP GUI Pragger Yapra XML Mobile Git Study JSON VirtualBox Samba Pear Growl Mercurial Rack Capistrano Rake Win RSS Mechanize Sitemaps Android JavaScript Python RTM OOo iPod Yahoo Unicode Github iTunes God SBM friendfeed Friendfeed HokuUn Sinatra TDD Test Project Evernote iPad Geohash Location Map Search Simplenote Image WebKit RSpec Phone CSV WiMAX USB Chrome RubyKaigi RubyKaigi2011 Space CoffeeScript Nokogiri Hpricot Rubygems jQuery Node GTD CI UX Design VCS Kanazawa.rb Kindle Amazon Agile Vagrant Chef Windows Composer Dotenv PaaS Itamae SaaS Docker Swagger Grape WebAPI Microservices OmniAuth HTTP 分析基盤 CDN Terraform IaaS HCL Webpack Vue.js BigQuery Middleman CMS AWS PNG Laravel Selenium OAuth OpenAPI GitHub UML GCP TypeScript SQL Hanami Document SVG AsciiDoc Pandoc DocBook Develop Jekyll macOS Node.js Vite Heroku Transformer AI Data Cloud Wasm