eslint-cli のマニュアルには –ignore-path という設定が説明されていて、
Command Line Interface - ESLint - Pluggable JavaScript linter
そこに
eslint --ignore-path .gitignore file.js
のように .gitignore と組み合わせる方法が紹介されているのだが、これはあぶない。具体的に言うと
git では無視されないけど eslint では無視されるファイルが生まれる
可能性がある。
今回自分が喰らったのは
*~
Emacsen 使いなら分かると思うんだけど、こんな「普通の glob」で踏み抜くとは思わず、なぜか意図通りに lint で警告されないとウンウン2時間も時間を消費してしまいましたとさ。
ちなみに本当に悪さしていたのは ESLint ではなく
ESLint では https://t.co/xAT9N8H56e を使って ignore ファイルを解析していますので、 .gitignore と異なる解釈になる場合はバグ報告して頂ければと思います。
— Toru Nagashima (@mysticatea) May 7, 2018
なのだそうです。うーん、なるほど。
Evo に機種変して PocketWiFi と iPod touch を不要にするという取り組みの中でいちばん後回しになったのが
iTunesライブラリの取り込み
だった。結論から言うと
iSyncrを使って同期することにした。
後回しにできた理由
- iTunes ライブラリには自分で rip したものと PLUS で買ったものしかない
つまり、DRM フリーの楽曲しかない。これなら余計な手間を掛けずに iTunes 包囲網から外れることができるのは分かっていた。
iTunesを捨てる気はない
iTunes はまぁよくできてる。Windows で使う場合は遅くてやってられないとかイロイロあるだろうが、実によくできた仕組みだ。「同期」という操作によって必ずバックアップが作成できる。iPod, iPhone に何かあってもそのバックアップからすぐに元に戻せる。
また iTunes Store の窓口にもなっているし、日本の iTunes Store のしょぼさを理解したうえでもとても便利なものだ。もう何枚もアルバムを買っているし、今後この窓口を捨てるのは自分にとってはちょっと現実的じゃない。今なら Amazon mp3 という選択肢も日本にできたが、あれの規模も結局期待したほどじゃなかったし、楽曲は提供してくれているが管理手法は提供していない。だったら iTunes で一本化しておいた方が楽ちん。
ついでに言うと今後一切 iOS と縁を切るかというとそれも現実的じゃない。アプリ配信のプラットフォームが iTunes である以上、これを切るのは無理だよね。
iSyncrにした理由
あんまりたいした理由はない。
- 割と紹介されている
- 値段が手頃
- とりあえず同期さえできればよかった
iSyncrの利用手順
- Android 上にアプリをインストール1
- 起動して「準備」
- SD カード上に iSyncr アプリと license key が生成される
- PC/Mac と Android を接続し、メモリーカードとしてマウントする
- 「カード」上の iSyncr アプリを PC/Mac から起動する
- iSyncr と iTunes が起動する
- 同期したい「リスト」を選んで「同期」を開始
- 待つ
- SDカード上にリストに含まれる「データ」2が転送されているのでこれを利用する。
ちょっと戸惑ったけど、
PC/Mac 上で起動するアプリを Android 上にインストールする
という形になっている。そのため、Windows 用、Mac 用が明確に分かれているのは注意が必要。
ちなみに再生には最初から入っていた「音楽」アプリを使っている。操作性はイマイチだけど、まぁこんなもんかなぁと思って我慢してる。
- MacBook + MacPorts に移行
- やっと時代（Leopard）に追いつく。しかしTerminalにタブがついたくらいしか自分の使用感は変わらないのであった。
- EPWING広辞苑4ヶ月以上経ってやっと封を切る
- Retrospectiva 試す
- GEOM(FreeBSD) と ufs のお勉強
- FreeNAS 試す
- Selenium IDE 試す
- Ustream のアカウント取って試してみる
- なんも流してないけど
- xrea+更新
- 行ってみたかったカレー屋を制覇
- 行ってみたかったそば屋を制覇
こんなもんか。ひどい生活してる気がするけど、気にしないでおこう。
意外と早くできたな。
うむ。めがねは合っている。
しかし、オヤジがうるさい。
たぶん他の人から見ればオレもこのオヤジみたいにうるさい人間なんだろうと思うとあんまり悪く言えないのだが、それにしたってどうだろうという感じがしなくもない。メガネのセレクトと腕は確かかもしれないだけに、うーん。
まぁいずれにせよ合わないメガネで苦しむ日々とはおさらばできたのだから、よしとしなきゃいかんのだろな。
今回はあえてインチキくさい感じを前面に出してみました。会う機会のある人はビックリしてください。
- fancyURL, magicalURL
- [49] FancyURLとMagicalURLモードで複数blog運用
- scaffold
- Lost-Season: Rails、CatalystのScaffoldを比較
magicalURL はともかく、fancyURL って Nucleus 用語？ 少なくとも Nucleus 界隈発祥のように見えるんだけど、どうなんだろ。fancyurl.com っていうサービスもあるけど、そっちが先か？
scaffold はあれか。skelton とかそんな感じの言葉に置き換え可能なものかな？
山下達郎は本当にいいな。絶対番組 DVD（Super Audio）を出すべきだと思うんだけどどうだろう。
初めて知った。なんかゴールデンウィークスペシャルでものすごい 80年代セレクトが炸裂してる…。本当に今80年代って流行ってるんだなぁ。どんぴしゃすぎて何が流れても大笑いしてしまう。
カタログとか取説とか保証書とかいっぱい出てきた。とりあえずなんかあったときの連絡先とかっていう意味で取ってあったんだな。
大きめの封筒がいっぱい。これはあれだな。封筒でカタマリを作って通信記録とか書類とかまてめてたんだな。今そういうの自分ちには全然必要ないから無意味にかさばる封筒がたくさんになってしまった。
使いかけの履歴書もいっぱい出てきた。うーん。
2000年頃のものも出てきた。いろいろ捨てた。こうして考えるとずいぶん経ってんだなぁ。
XREA SUPPORT BOARD - s46 で tDiary にエラーがでます
header を送出する CGI は non parse header で動かせということでした。
Zope とおんなじだ。
Web アプリケーションサーバ。ただ違うのは Java そのものを含んでいないこと。Java は Java の SDK を別途インストールせんなん。で、単独でも動くし、Apache との連携も可、と。あ、あと、コンテンツが自動的に ODB には入らない。
でもなぁ、やっぱスクリプトな自分としては Java って大げさだよな。開発効率もそんなに良くなさそうだし。（だからゴマンとツールが出ているんじゃないかと邪推してしまう。）
考えると Zope ってよくできてるな。ZODB と Python の問題さえクリアすれば最強な気がするよな、やっぱ。
大学サークルの新歓活動もメッセンジャーで (CNET Japan 松村blog)
正直ネットワークが整っているということはうらやましいが、メッセンジャー、しかも msn メッセンジャーなんて気持ちの悪いものをみんなが使っているって状況はちょっといやだなぁ。
Yahoo Messenger とか MSN Messenger を何の疑問も持たずに使っているのだとしたら、SFC 的にはリテラシーないんじゃないの？と言いたくなってしまうが。。。
しかしうまく広げられそうにないので説教講座 snapshot の方では取り上げないのであった。
sitecopy -f サイト定義
sitecopy -s サイト定義
で ok かな。
説教講座の場合、手元でファイルを修正するコンテンツと Wiki, tDiary でリモートサイトが直接更新されるコンテンツが混在しているので、両方の動作が必要なのであった。今回は「サイト定義」の部分にダウンロードしたいディレクトリを個別に指定することで対応している。
あ、tDiary のダウンロード指定し忘れてた。
PHP の混入したファイルから pure HTML を wget で生成するので、
毎回全ファイルのタイムスタンプが更新されている
んだから、まぁ当然と言えば当然。ということで
state checksum
の記述を追加。さー次回以降どうなるかなー。
成功！
ftp の upload は sitecopy がよさげということで導入したのだが、
すでに存在しているディレクトリをいつまでも作成しようとダダをこねる
という困った現象が起きていた。これは
- すでにリモートサイト上にディレクトリがあり
- そこに大量にアップロードするのに sitecopy を利用した
という前提がある。このとき、sitecopy -c をせずに sitecopy -i としたのだ。これには理由がある。sitecopy -c は local のデータを remote と同じものとみなすだけなので、以降 sitecopy -u とやってもまったくデータが転送されない。sitecopy -c 以降に修正した分しか反映されないのだ。
しかし逆に sitecopy -i では remote にデータがないかのように振る舞う。つまり、すでにサイト上にあるディレクトリを新規に作成しようとしてエラーが出る。しかもこれを何度もくり返す。
おーい、なんでこんなものをみんな優れたツールだなんて言うんだよ。信じちゃったじゃないか。
一応 -k オプションでエラーがあっても続行するということは可能なのだが、なんかそれも気持ちよくないので、~/.sitecopy の中身を見てみた。こんな感じの記述があやしい。
<item><type><type-directory/></type><filename>perspective</filename></item>^M
この perspective ディレクトリは新規作成しようとはしない。見るとここに書かれていないディレクトリでエラーが出ているようだ。よしよし。
<item><type><type-directory/></type><filename>cm/puki</filename></item>^M
な感じでどんどん記述を足していく。
エラー解消
ところでこのファイルはなぜ改行コードが cr なんだろうか。。。
自宅サーバのファンがうるさくなってきた。やっぱサーバ用のマシンじゃないのに 24時間連続運転はきついか。
はて。電源交換？ ファンだけ交換できないかな。別に電源が不調なんじゃないしな。
http://www.zdnet.co.jp/news/0305/07/cjad_horikoshi.html
weblog にも実際に意義があったろうし、現在もあるでしょう。それを否定する気はないのですが、blog 賛美は好きになれません。つーかまず blog という単語がなんかいやだ。なんつーか 2ちゃん的な音便なんでしょうが、元の意味がいたずらに分からなくなる言葉遊びはそのコミュニティの外に居る人間を締め出しに掛かってんじゃねーか、と勘ぐりたくなります。これが acronym だとか言うならいいんですがね。
で、話を元に戻すと blog 賛美は好きになれないのです。blog そのものはどうかというと、別にどうとも思いません。日記でしょ？ いや、「個人の日常を記述したもの」という本来的な意味での日記のことを言ってるわけじゃなくて、Web 上によくある日記。Web 上の日記って、そりゃー内容は千差万別で、本当にその日起きたことを書いてあるものもあれば、非常に高度な技術メモだったり、思索の吐露だったりすることもあります。
blog もそういうもんでしょ。役に立つ blog もそうでない blog もある。そんでいいじゃん。ジャーナリズムがどうだ、なんてのはたまたま目立った事例を取り上げているだけで、それが本質なのかというとそんなことはないでしょう。逆に、個の発信する良質なジャーナリズムが…なんてことを今さら声高に言うってことはですよ、
あんたは WWW をなんだと思っていたのだ
と問いたくなります。WWW ってのはもともとインタラクティブなメディアなのです。マスメディアじゃねー。
てのが今まで思っていたことなのですが、タイミングがないし、独立したページで書くほどの分量にもなりそうにないので書かずにおりました。いいタイミングをくれてありがとう > ZDNet
ところで、このコミュニティ形成の比較って話はなかなか面白いですね。ツールとサービスの登場により一気に個人ジャーナルサイトが華開いたのであれば、強力なコミュニティの形成も別に不思議じゃない。でも逆に言うと、日本以外でもツールに頼らないテキストサイトはフツーに存在してたわけだし、そういう地道な下地が必要だったんじゃないかとも思うんですけどね。そういう地味なテキストサイトでの情報の発信をしていた人がなんとか書くことだけに専念したいと願っていたからこそツールができ、その普及により文化が華開いたわけでしょ。実は個人的にはこういう地味なサイト（見た目がどうとかではなく）の方が好きで、一応理由もあるのですが、それはまた別な機会に書こうと思います。