GitHub PatchWork Tokyoにメンターとして参加させていただきました
メンターが足りてないのでGitとGitHubを使ったことがある人でメンターやってもいいよって人は是非ご登録ください！ 12月19日 GitHub Patchwork Tokyo https://t.co/AsS18Qv08u
— Takafumi Ikeda (@ikeike443) December 12, 2015
9月に参加させていただいたGitHub Patchwork Tokyo、自分的にはとても楽しいイベントでした。
上のツイートを見かけて、参加者は満員なのに、メンターはその時点で募集人数の半分くらいしか埋まっていなかったようだったので、 他のメンターを呼びに行く係 くらいにはなれるかもしれないと思って、参加させていただくことにしました。
まだ小さい子供がいる身としては、特に夕方以降の動ける時間が限られるため、なかなか週末のイベント等には参加しづらい状況なのですが、幸いにして10:30〜14:00という昼間の時間帯だったのもポイントでした。
会場も前回と同じ、dots.。
イベント＆コミュニティスペース - dots.[ドッツ] in 渋谷
dots.はPatchworkのときにしか入ったことがないので、つまり自分がdots.に来るのも2回目なのですが、広いしキレイだしオシャレだしで、こういうイベントのときには本当に良いですね。
Scott Chacon氏
今回もGitHubのスタッフの方々も何名か参加されていて、その中のひとりで、GitHub共同創業者の Scott Chaconさん が開催の挨拶をされていました。
日本語勉強中とのことでしたが、喋り始めが「あのー」からだったあたり、すでにマスターされている印象。
イベント終了後、アイドルばりにツーショット写真の列ができていたのも、その人柄からでしょうか。
Git-it Electronの日本語化
前回同様、教材としてGit-it Electronが使われていましたが、今回はGitHubの日本人スタッフの ikeike443 こと池田さん が日本語訳を追加したバージョンが用意されていました。
確かに前回私がやったときは、まず英語を読むのに苦労したので、これはとてもありがたい対応ですね。私のように英語が苦手な人でも、非常にとっつきやすくなっています。
メンターとして参加してみて
正直なところ、それこそ先日のPatchworkで始めてプルリクエストを出してみた程度のレベルのGit＆GitHub力なので、どこまでサポートできるのか不安でした。
ただ、参加されている方はエンジニアばかりでもなく、むしろIT系の営業だったりデザイナーだったり、ふだんコマンドラインなど触らないような仕事をされているという方も多くいらっしゃり、課題の内容というよりは、最初の環境構築的なところでひっかかってしまうケース（特にWindows）なども多かったので、その辺りはフォローできたかな、と思います。
たまにGitの仕組みのような質問を受けて、変な汗をかきながらシドロモドロに答えたりしつつも、それでも一緒になって問題解決ができたりすると、やっぱり楽しいですね。
この日もランチタイムにはピザとドーナッツが振る舞われました。（ドリンクも無料で提供されました）
写真でもあれば良かったんですけど、そういう余裕はありませんでした。。。
青山学院大学 古橋大地教授
この日のゲストとして、オープンソースやオープンデータの意義などについて、 青山学院大学の古橋大地教授 のスピーチがありました。
古橋氏はOpenStreetMapの活動を率いていらっしゃる方でした。
OpenStreetMap Japan | 自由な地図をみんなの手に/The Free Wiki World Map
OpenStreetMapが目指しているのはオープンな地図情報ということで、商用利用や印刷・配布などに規約で制限がついてしまうGoogle Mapなどとは異なり、印刷も配布も商用利用も可能なものを作ることにあるそうです。
東日本大震災や2010年のハイチ地震のときなどにも、マッパーと呼ばれる方々の活動によって、震災発生後すぐに現地の道路情報が整備されていき、避難所の情報などを提供されたそうです。
この整備されていく様子を映像化したものを見せていただきましたが、とても圧巻でした。
また、OpenStreetMapの地図データ形式であるgeoJSONは、実はGitHubも対応していて、Gistでも良いのでgeoJSON形式のデータをあげると、GitHub上でマッピングされるそうです。これを利用して、OpenStreetMapのデータのやり取りなどで、GitHubを活用されているとのこと。
Mapping geoJSON files on GitHub - User Documentation
GitHub堀江さんの話によると、どうやらGitHubには地図オタクの方がたくさんいるそうで、こうした対応に一役買っているようです。
また、今後はオープンな空撮データ(OpenAerialMap)も作っていきたいということで、関連して以下のような活動もはじめられたようです。
ドローンで災害地を救え！世界初の救援隊「DRONE BIRD」始動（古橋大地（DRONE BIRD隊長）） - READYFOR (レディーフォー)
OpenStreetMapの存在は知っていたものの、こんな風に展開しているとは知らなかったので、とても興味深かったです。
最後に
GitHub PatchWorkは、とても楽しいイベントです。
今後も開催されるようなので、そのときはまたお手伝いなどさせていただければなーと思います。
Gitが、おもしろいほどわかる基本の使い方33〈バージョン管理、SourceTree、Bitbucket〉
- 作者: 大串肇,久保靖資,豊沢泰尚
- 出版社/メーカー: エムディエヌコーポレーション
- 発売日: 2015/05/26
- メディア: 単行本
- この商品を含むブログ (3件) を見る
Apple Musicか、Google Play Musicか、それが問題だ
Apple Musicのお試し期間が終了して、シルバーウィークキャンペーン中に登録したGoogle Play Musicのトライアル期間の終わりも近づいてきたので、そろそろどちらかに決めないといけない時期に来ました。
結論：Google Play Music
自分はGoogle Play Musicにすることにしました。
理由：とりあえず安い方にした
実は自分好みな楽曲の取り揃え的には、若干Apple Musicの方が分がある印象でした。
が、細かい差分を考慮しても、そもそもどちらにも聴いてみたい音楽が大量にあるんですよね。
であれば、自分がメインで使っている端末がAndroidですし、また10月18日までに登録したことで月額料金が780円で良いこともあり、当面は安く済む方を使っておこうと思った次第です。
YouTube Redも期待
（まだ日本では使えませんが）YouTube Redという、YouTubeに広告が入らなくなるサービスも、Google Play Musicを契約していると使えるらしい？ということなので、それも少し期待。
見始めると止まらないので、ふだんはなるべくYouTubeは見ないようにしているのですが、オフラインでバックグラウンド再生できるようになるのであれば、使ってみたい気がします。
音楽系以外でも、どうしても子供が騒ぐのを止めたい時などに、YouTubeにあるカーズの映像などを見せたりするので、いざというときのために、それをダウンロードしておくという使い方もできそう。
曲のアップロードも便利そう
これは、そもそものGoogle Play Musicが提供していた機能ですが、手元にある音楽データをアップロードしておくことで、同期できる様々なデバイス上で聴くことができます。
ストリーミングサービスとなったGoogle Play Musicには、すでに自分が持っているCDもあったりしますが、わざわざ取り込む手間が省けるので、こちらにあればそっちを聴けますし、まだ足りないものも多くあるので、そういったものは自分で取り込んでいたものをアップロードすることで、Google Play Musicアプリ内でまとめて管理できます。
今まで、メインで使っているXperia Z3には、Android File Transferで直接MP3を放り込んでいたのですが、Google Play Musicを経由させることで、楽曲の管理などもやりやすくなりました。
iTunesからも取り込むことができるようなので、そちらで管理していた人でも活用できそうですね。
Android版Apple Music
ギリギリ自分のトライアル期間中に公開されたのですが、正式版になる前にトライアルが終了してしまったので、最初のバージョンでしか使えませんでした。（その後、一度アップデートが入っているので、後述の問題は改善されているかもしれません）
Apple Music - Google Play の Android アプリ
ベータ版ということもあり、若干不安定なところは見受けられましたが、
Android版Apple Music、2枚組だとトラックNoでソートされててつらい。しかも1曲目は2枚目のやつがきてるし。 pic.twitter.com/ESpexX27TQ
— Umi Uyura (@umi_uyura) November 14, 2015
UIはきちんとAndroidに最適化してきていて、これはわりと使いやすい印象でした。
あとAndroidユーザー的には、
- ダウンロードした楽曲の保存先をSDカードにできない
- 操作用のウィジェットがない
といったあたりが対応されると、より活用できるのかな、と思います。
伏兵、Amazon Prime Music
先日、突如発表されたAmazon Prime Music。
Amazonプライム会員であれば、追加費用なしで100万曲が聴き放題になるというサービス。
Amazonプライムは年額3,900円なので、月換算すれば320円。値段だけ見たら非常にお得なのですが、いかんせん楽曲のラインナップがありませんので、プライム未加入の自分には、あまり引きはなかったですね。
今のところはプライム会員向けのオマケという感じでしょうか。
Amazonプライムは動画の見放題サービスも始まったので総合的にはお得感はありますが、自分は会員ではないこともあり、現時点では候補にはなりませんでした。
ただ、Amazonミュージックで検索した結果に、Prime Musicで聴ける対象かどうかが表示される点は良いと思いですね。
Apple MusicもGoogle Play Musicも、サービスの対象ではない楽曲やアーティストになると、突然iTunesやGoogle Playのページに飛ばされたりするので、せめて飛ばす前に別途購入が必要なものなのかわかるようにして欲しいところです。
最近聴いているもの
学生時代にプログレッシブ・ロックというジャンルにハマったわけですが、それ関連の解説が豊富な OFFICE CHIPMUNK を見ながら、あの頃聴きたかったアルバムを物色しています。
超絶技巧やインプロヴィゼーションも好きですが、どちらかというとYESやRenaissanceなど、クラシカルなメロディでダイナミックな展開をみせるようなものが好きなんですけど、そんな中で、最近パワープレイ中なのは「CAMEL」。
プログレに詳しい方々からすれば、なぜ聴いていなかったの？という感じの有名ドコロですが、確かに昔一度「スノーグース」あたりを聴いた気がするのですが、その時は思ったよりインパクトがなかったんですよね…。
あらためて今回聴いてみると、ホント、なぜ今まで聴いていなかったというくらい、私が求めていたプログレ成分はこれだ！という感じでした。
とりあえず「蜃気楼（Mirage）」から始めて、「白雁（スノーグース）」「月夜のファンタジア（MOONMADNESS）」あたりを聴いています。
- アーティスト: キャメル
- 出版社/メーカー: USMジャパン
- 発売日: 2013/03/20
- メディア: CD
- この商品を含むブログを見る
ザ・スノー・グース~白雁~(2013年ヴァージョン)(紙ジャケット仕様)
- アーティスト: キャメル
- 出版社/メーカー: マーキー・インコーポレイティド
- 発売日: 2014/09/25
- メディア: CD
- この商品を含むブログを見る
- アーティスト: キャメル
- 出版社/メーカー: USMジャパン
- 発売日: 2013/03/20
- メディア: CD
- この商品を含むブログを見る
まとめ
この辺のCDを中古で買うとしても、安くても1枚1,000円前後はしてしまうので、その金額でこれだけの音楽を聴き倒せるのは、自分的にはとてもお得です。
また１年くらいしたら状況が変わっているかもしれませんので、他のサービスの動向も伺いつつ、楽しもうと思います。
Alloy with Jadeでincludeを使う
私は普段Titanium開発をする際、ViewをJade、StyleをStylusで書いています。
今回、Viewの中でJadeの include を使ってみようとしたところ、上記のalloy.jmkだけではエラーになってしまうようだったので、少し修正してみました。
alloy.jmkの修正箇所
上記のalloy.jmkの中で、Jadeに関する処理をしている部分に、以下のように手を加えました。
// jade event.alloyConfig.xml = []; wrench.readdirSyncRecursive(view_root).forEach(function(view) { if (view.match(/\.jade$/)) { event.alloyConfig.xml.push(view.replace(/\.jade$/, ".xml")); var jadeOption = { filename: path.join(view_root, view), // ←１．includeを使えるようにする pretty: (event.alloyConfig.deploytype === "development"), compileDebug: (event.alloyConfig.deploytype !== "production") }; fs.writeFileSync( path.join(view_root, view.replace(/\.jade$/, ".xml")), jade.compile(fs.readFileSync(path.join(view_root, view)).toString(), jadeOption)(event)); } }); // Files that start with '_' , // because is to use in `include` of Jade, it should be deleted here event.alloyConfig.xml.forEach(function(view) { // ←２．include済みXMLは削除しておく if (view.match(/^_\S*.xml$/g)) { fs.unlinkSync(path.join(view_root, view)); } }); // ~jade
ポイントは２箇所あります。
１．includeを使えるようにする
はじめ、include を使ってみたところ、 the "filename" option is required to use "include" with "relative" paths というエラーが出力されました。
index.jade
Alloy
Window
include ./_index_body.jade
_index_body.jade
Label Hello, World
どうやら、 include で取り込む対象ファイルを相対パスで指定するためには、Jadeコンパイル時に filename を指定する必要があるようでした。
そこで、上記の １． の部分のようにパスを取得し、 jade.compile のオプションとして渡すようにしたところ、コンパイルが通るようになりました。
２．include済みXMLは削除しておく
上記の問題は解決されたのですが、次にAlloyコンパイル時に、include済み.jadeを.xmlに変換したファイル（上記の例では _index_body.jade ）がエラーになってしまうようになりました。
includeされるファイルは、includeした方の.xmlに取り込まれる形になるため、Alloyコンパイル時には不要なものなのですが、プロジェクトのviewフォルダ内にある.xmlは全てコンパイル対象となるからです。
そこで、Alloyコンパイルする対象を分別するために、以下のようなルールを設けることしました。
- includeするファイルは、ファイル名を
_で始める
そして、alloy.jmkに ２． のコードを追加しました。
これは、ひととおり.jadeをコンパイルした後で、ファイル名に _ が付いている.jadeについては、対応する.xmlを事前に削除するというものです。
これにより、Alloyコンパイル時にはinclude済みの.xmlは存在しないため、エラーは発生しなくなります。
alloy.jmk全体
上記の修正をしたalloy.jmkです。
Alloy with Jade & Stylus, and Stylus Extend Notati ...
ついでに、JadeとStylusを設定して、 include を使っている状態のサンプルプロジェクトです。
まとめ
Alloy XMLには Require という仕組みがありますが、この場合、あるViewに別のViewを連携するような感じなので、コントローラが分離されるなど、データのやり取りなどが複雑になってしまう場合があります。
Jade側でincludeする仕組みでは、include対象を取り込んだXMLを生成することになるため、同一のViewやコントローラ内で扱える点が便利かな、と思います。
何か使いドコロがあれば、使ってみようと思います。
- 作者: 井上誠一郎,土江拓郎,浜辺将太
- 出版社/メーカー: 技術評論社
- 発売日: 2014/10/31
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
Titaniumでオブジェクトの中身をダンプする
普段Emacs + Titanium(Appcelerator) CLIで開発をしているのですが、少し不便なのが、デバッグのときにオブジェクトの中身を確認したいとき。
Appcelerator Studioなら、ステップ実行しながらオブジェクトの中身をGUIで確認できたりするわけですが、わざわざエディタと別にStudioを開いておくのも面倒なので、よほどの時でないと使っていなかったりします。
ブラウザでは console.dir() という便利出力を使えたりしますが、残念ながらTitaniumでは使えません。
ちょっと変数の中身をみたり、ちょっとした動きの確認程度のことであれば Ti.API.debug() を絨毯爆撃してデバッグしていますが、オブジェクトを指定した場合、 [object Object] のような出力になってしまうので、 for...in などで展開して出力したりしていました。
が、どうやら以下のようにしてあげると、ダンプできるもよう。
Ti.API.debug(JSON.stringify(someObject));
なるほど、 JSON.stringify でオブジェクトを文字列化して出力してあげれば良かったのか・・・この技、知らなかった。
ChromeのDeveloper ToolでTitaniumアプリをデバッグできる TiInspector も以前少し使っていたのですが、Titanium SDK 3.5.x以降で使えなくなってしまったのが残念。
参考
確かな力が身につくJavaScript「超」入門 (確かな力が身につく「超」入門シリーズ)
- 作者: 狩野祐東
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/10/30
- メディア: Kindle版
- この商品を含むブログを見る
WiMAX 2+とカケホライトと私
約1ヶ月半くらい前、9月も終わりの頃、いよいよ覚悟を決めてWiMAX 2+へ移行しました。
加えて、普段使っているドコモ回線契約も新しい料金プラン「カケホーダイライト」に変更したので、１ヶ月使ってみた感想でも書いてみようと思います。
WiMAX 2+へ移行した
昨年WiMAX契約を更新したときは、迷った末に見送りました。
主な理由としては、
- WiMAXは主に自宅回線として導入しているのに、WiMAX 2+は速度制限がかかるのは辛い（当時はまだ可能性でしたが）
- WiMAX 2+はデバイスプラス（機器追加オプション）ができない
- 自宅に人がいない時間帯は、外でWiMAXを使えた
というものでした。
現在も事情としては変わっていないので、正直なところ変えたくはなかったのですが、WiMAX 2+の全国展開の完了ととともに現行WiMAXは速度が3分の1も落ちることになり、そしていずれはなくなるだろうということになってしまったので、これはもう継続するか止めるかを決める時期かな、と思い始めたわけです。
WiMAX(2+)を継続した理由
このタイミングで決めたのは、まあ対応端末へ無料で乗り換えられるというキャンペーンが9月末までだったためです。
結局先に述べたような事情というのはあまり変わっておらず、基本的に自宅回線としてWiMAXを残すしか、ほぼ選択肢がない状況でした。
一番問題であった速度制限に関しては、いちおうUQコミュニケーションズとしても改善していくというリリースを出したので、まあそれほど期待はしていないものの、こういう事情なので、変えるなら少しでも損が少ないタイミングの方が良いと思い、決断しました。
選んだ端末＆プラン
タダ替えで選べる端末はホームルータータイプもありましたが、持ち運びやすいモバイルルータータイプのHUWEI製のW01にしました。
Speed Wi-Fi NEXT WiMAX 2＋ W01 マリン HWD31SLU
- 出版社/メーカー: UQコミュニケーションズ
- メディア: エレクトロニクス
- この商品を含むブログを見る
理由としては、
- 基本的には自宅回線用だが、家族で出かける場合には外でも使えそう
- （追加料金はかかりますが）au LTEオプションが使えるので、帰省や旅行時にも使えそう
- 奥さんも自分も、実家がWiMAXはおろかPocket WiFiも電波が届かない田舎なので…
といった感じです。
代わりに、まだしばらくは使えるWiMAX（1の方）は捨てることになるので、速度制限から逃れるすべはなくなった形になります。
カケホーダイライトへ移行した
ちょうどWiMAX 2+への移行を検討している頃に、ドコモからも新しい料金プラン「カケホーダイライト」が発表になりました。
今使っているXperia Z3へ機種変更したのが昨年11月。
そのときは、それまでの料金プランを変更する気はなかったのですが、分割払いにするには新しい料金プランへの移行が必須ということで、 不本意ながら カケホーダイ＋パケットSという組み合わせに変更せざるを得ませんでした。
ふだんほとんど通話をすることがない自分にとっては、2,700円もする定額プランは不要、となると実質値上げになるため、その分をカバーすべく、データ通信に関してはパケットSを選択しました。
当時はWiMAX 2+の移行を見送ったこともあり、オプションのデバイスプラスを使うことで、外でのデータ通信はカバーできていましたので、加えて外出先の公衆無線LANなどを利用することで、月々のデータ使用量は2GBで収めることができていました。
そんな感じだったので、月額の料金が安いカケホーダイライトが発表されたときは即変更しようと思ったのですが、よくよく条件を見てビックリ。
パケットSは対象外！！！
当然企業として売上が必要ということは理解しますが、ユーザーとしてはまったく納得がいかない条件です。
そうなると、通話プランが2,700円から1,700円と1,000円下がるかわりに、パケットプランを3,500円から5,000円と1,500円アップしなければならないので、実質500円アップということになります。
以前は存在した 通話の利用頻度が低い人に合ったプランが欲しい だけなのに、なぜか 通話プラン安くしてあげるから、より高いパケットプランに変えてね という意味がわからない交換条件のため、そのときはいったんはカケホーダイライトへの移行は見送っていました。
長期利用割引（ずっとドコモ割）があった
ところで、そういえば自分はドコモユーザーとしてかれこれ15年超です。
その場合、長期利用割引が適用され、パケットMが800円割引になるのでした。（ついでに言うと、パケットSも600円引きではあった）
あらためて、その差分を考慮すると、ほとんど使わない電話料金を下げ、+300円でパケットMにできるとも言えます。
先に書いたとおり、結局WiMAX 2+へも移行せざるを得ない状況になってきて、デバイスプラスが失われることを考えると、この＋3GB分をテザリングに回せば、外でもくもくするときなどにも使えます。
そういったことを踏まえ、まんまとキャリアの策にノセられている感に納得出来ない面はありつつも、カケホーダイ・ライト＋パケットMに変更することにしました。
１ヶ月使ってみて
カケホーダイライトに移行してみて
10月末にXperia Z3のデータ使用量を確認したところ、約4.0GBでした。
うち、1.6GBはMacBook AirやNexus 7のテザリングで使っていて、スマートフォンの通信量は2.4GB。
スマホでも、あきらかに大きなデータや動画を観たりはさすがに控えていますが、それでも以前よりパケット量は気にせず使っていてこのくらいなので、スマホ＋テザリングで5GBあれば、普段使いとしては充分なようです。
問題は5分を超えると有料になる通話プランですが、対策として、とりあえず試しに指定した通話時間が近づくと教えてくれるアプリを入れてみました。
Call-Timer - Google Play の Android アプリ
が、この1ヶ月間、5分以上の通話をすることがなかったので、まあ問題なさそう。
WiMAX 2+に移行してみて
そもそも自宅の位置が山に近いあたりのせいか、WiMAX(1)時代も2Mbps前後だったのですが、あまり変わりませんでした。
あと、やはり3日間3GB制限は厳しいですね。
特にITエンジニアとしては、開発環境のアップデートなどで、大きなデータをダウンロードすることは度々発生します。
つい最近もXcodeのアップデートなどありましたが、4GB近くありましたので、その時点で翌日の速度制限確定です。
こういう場合、Xcode単独ではなく、関連してSDKだったりシミュレータだったり周辺ツールのアップデートなども発生したりするので、1日で終わらなかった場合、翌日に持ち越されたアップデートは地獄です。
まあ、こればっかりは仕方がないので、制限のなかでやりくりして行こうと思います。
- 出版社/メーカー: HTC
- 発売日: 2015/01/10
- メディア: Personal Computers
- この商品を含むブログ (9件) を見る
ネット非接続状態でEmacs起動時にEmacsWikiへの通信がエラーになってしまう問題が解決した
以前から気になっていたのですが、インターネットへ接続していない状態でEmacsを起動するとエラーが発生してしまい、.emacsの読み込みが中途半端な状態になってしまう現象がありました。
これは、パッケージインストールツールのauto-installにて、起動時に EmacsWiki に掲載されているパッケージ名を読み込むために呼び出している auto-install-update-emacswiki-package-name が、EmacsWikiへのとの接続を確立できないためにエラーになっているようでした。
ネットワークが繋がっていないときということで、頻繁に起きるものでもないこともあって放置していたのですが、ふと気になってきて調べて始めたところ、以下のツイートを見つけました。
@rubikitch auto-installの
(auto-install-update-emacswiki-package-name t)
がEmacsWikiが落ちているとフリーズするようです。、
— Kazuki Yoshida (@kaz_yos) 2013, 3月 5auto-installのメンテナをされている@rubikitch氏とやりとりで、このツイートへのリプライの中で、
というものがありました。
私の環境にはHomebrewでwgetを導入してはいるのですが、もしかしたらそれがうまく検出されていないのかもしれない、と思い、明示的にwgetを使うように auto-install-use-wget を t に設定してみたところ、ネットワークが切断された状態でもエラーにならず、Emacsが起動してくれました。
(when (require 'auto-install nil t) (setq auto-install-use-wget t) ; <-- 入れた (auto-install-update-emacswiki-package-name t) (auto-install-compatibility-setup) )
ただ、環境によっては、逆にwgetを使っていることで？フリーズしてしまうケースなどもあったようなので、一概にこの設定で良いかはわかりません。
たまに外で作業している場合などでネットの接続状態が悪いと、この問題でEmacsが不完全に起動してしまい、 (auto-install-update-emacswiki-package-name t) 部分をコメントアウトして起動しなおしていたりしたのですが、これで気にしなくてもよくなりそう。
環境
| 項目 | バージョン | 備考 |
|---|---|---|
| OS | Mac OS X 10.10.5 | - |
| Emacs | 24.5.1 | Homebrew版 |
| auto-install | 1.58 | - |
| wget | 1.16.3 | Homebrew版 |
Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例
- 作者: るびきち,佐々木拓郎
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2014/08/25
- メディア: 大型本
- この商品を含むブログ (8件) を見る
FlycheckでESLintの設定を育てるときのメモ
Flycheckを導入しているものの、普段は一緒に導入している flycheck/flycheck-pos-tip でエラー箇所をポップアップさせて、その部分を修正していくという使い方をしています。
先日、EmacsでESLintを使える環境を作って、自分好みの設定を模索しようとしているのですが。
まだ、ほとんど推奨設定の状態ということもあり、そのまま使うといろんな所でエラーやら警告やらが出てきます。
そのあたり、ひとつひとつエラーの内容を調べつつ、自分的に無視するか有効にするかを判断していくわけですが、さすがに似たようなエラーも大量に出てくるため、ある程度まとめて調べたいと思うようになりました。
エラーになっているルールを調べる方法
先に述べたとおり、通常の使い方としては flycheck/flycheck-pos-tip でエラー箇所にポップアップを表示しています。
が、この方法ではエラーの説明は表示されていますが、ESLintの設定を変更するためには知りたいルールの ID がわかりません。
そこで、まずはFlycheckの使い方を調べたところ、エラーの情報を知るには以下の3つの方法がありそうでした。
| コマンド | 機能 |
|---|---|
C-c ! l M-x flycheck-list-errors M-x list-flycheck-errors |
現在のバッファの全てのエラーの一覧を表示する |
C-c ! C-w M-x flycheck-copy-errors-as-kill |
現在位置のエラーメッセージをKill-ringにコピーする |
C-u C-c ! C-w C-u M-x flycheck-copy-errors-as-kill |
現在位置のエラーメッセージとIDをKill-ringにコピーする |
ピンポイントで知りたい場合は、 C-u をつけた flycheck-copy-errors-as-kill でエラーの ID を取得することができます。
しかし、現状は大量に出てくるエラーを、ある程度まとまって調べてしまいたいこともあり、 flycheck-list-errors でリスト表示したものをベースに、設定をいじる方が効率が良さそうです。
ただ、ここでも一つ問題が。
ルールを示すのは、リストの中の ID の部分なのですが、デフォルトだと幅が狭すぎて、IDが読めません。
特に、React用のプラグインなどはIDも長くなりがちなので、このままではちょっと使いにくいです。
エラーリストの幅を変える
どうやら flycheck-error-list-format にエラーリストの幅設定があるようだったので、.emacsに以下のような感じで設定。
(eval-after-load 'flycheck '(custom-set-variables '(flycheck-error-list-format [("Line" 4 flycheck-error-list-entry-< :right-align t) ("Col" 3 nil :right-align t) ("Level" 8 flycheck-error-list-entry-level-<) ("ID" 20 t) ; <- 初期値は6 ("Message" 0 t) (" (Checker)" 8 t)]) ))
初期値 6 の ID の幅を 20 に設定してみたところ、私の環境では、それなりに識別できそうになりました。
もう少し広げても良いかなー、と思いつつ、これで多少カスタマイズが捗りそうです。
※2016/05/14 追記
flycheck-error-list-format のフォーマットが変わったようなので、それに合わせて設定を変更しました。
環境
| 項目 | バージョン | 備考 |
|---|---|---|
| OS | Mac OS X 10.10.5 | - |
| Emacs | 24.5.1 | Homebrew版 |
| Flycheck | 0.25snapshot (20151106.559) | MELPA版 |
参考
仕事ですぐ役立つ Vim&Emacsエキスパート活用術 (SoftwareDesign別冊)
- 作者: Software Design編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2016/04/09
- メディア: 大型本
- この商品を含むブログ (2件) を見る
