月別アーカイブ: 2014年3月

Qiitaとブログの使い分け

おがた (@xtetsuji) です。

Qiitaという「プログラミングに関する知識を記録、共有する最適なサービス」が最近活発です。見やすく使いやすいインターフェースや、ウェブ開発者に人気のMac向けに専用エディタKobitoを提供したり、アドベントカレンダーの提供インフラを提供したりと、様々な工夫があります。

実際Qiitaは便利で、そっちに書き始めると、今まで開発系の話題を提供していた自分のブログとの使い分けに悩んだりすることがあったのですが、今のところ私は以下のような基準で使い分けています。

Qiitaの「趣旨」に明らかにそぐわない記事は自分のブログへ

Qiitaは「プログラミングに関する知識を記録、共有する最適なサービス」なわけで、一見技術的な話題でも「プログラミングに関する知識」とはいえないコンピュータの記事は自分のブログに書くようにしています。例えばGoogleドライブのフォルダ名称変更とかは、操作自体はsqlite3を使ったり技術的な話題なのですが、プログラミングに関する…とは若干離れていたので、Qiitaに書きかけたものの、最終的には自分のブログで記事を公開しました。

コンピュータからかけ離れたエッセーとかをQiitaに書くのは明らかに違いますよね。

あとどこかで指摘があったのですが、「自分のプログラミング勉強日記」といったタイトルのような連載ものもQiitaに書くべきではないといった意見もありました。そういう体裁のものは、得てして他の人に役立たない、他の有用な記事を埋もれさせるという理由もあると思います。そういうのは個人のブログを使うのが正解なのでしょう。

コンピュータの話題がTwitterで展開された場合も、直接Qiitaを使わずTogetterで「プログラミング」カテゴリとしてまとめて、Qiitaを使う場合もそれを引用する形にしたほうが再利用性も上がって良さそうな気がします。

自分の作ったものの紹介は自分のブログに書く

「○○を作りました」「○○をリリースしました」系の話題は、Qiitaよりも個人のブログのほうが良い気がします。紹介は知識というよりアナウンスに近いような気がするからです。

アナウンスを自分のブログで行った後で、それを引用する形で実際の使用例をQiitaに書くのは良い流れかもしれません。

自分のブログを育てるか、QiitaのSEOの力を借りるか

「共有すべきプログラミングの知識」があったとして、それをブログに書くかQiitaに書くか、悩ましい部分もあると思います。

まず自分のブログを育てたい、自分のブログ記事を多くしたいという思い。この場合は自分のブログに書くべきでしょう。

ただ、QiitaはKobitoを提供したり、もしかしたらあなたのブログよりもプログラミングの知識を書くための良いインターフェースを提供していることも事実です。

また、Qiitaには自分のGoogleアナリティクスを設定できるので、それをして計測してみるとわかるのですが、外部からの流入が自分のブログの比ではない事が多いと思います。Qiitaは相当SEO(検索エンジン最適化)に気を使っていると言えましょう。そこそこ有名なブログでない限り、自分のブログに書くよりQiitaに書いたほうがアクセス数は断然多くなります。せっかく書いたプログラミングの知識、より多くの人に見てもらいたいと誰もが思うわけで、そういう場合にはQiitaを使うのが正解と言えそうです。

こちらは質問サイト寄りですが、海外のStackOverflowも(2015年現在は日本語版サイトもありますが活発ではありません)SEOに相当力を入れていることが垣間見えて、日本語サイトを検索エンジンで検索してもStackOverflowが引っかかるくらいです。SEOの重要性をQiitaの中の人も意識しているのでしょう。

承認やコミュニケーションを求めている場合はQiitaを選ぶ

自分のブログを育てたいと思っても、プログラミングの知識を書くのもそうですが、多くのブログは他者とそれでコミュニケーションを取るインターフェースが不足していることが多いと思います。

Qiitaはコメント欄でもMarkdown、しかもGitHub Flavorに近いMarkdownが使えたり、他者からのフィードバックがもらいやすい環境となっています。

また「ストック」という仕組みがある種の承認欲求を満たしてくれるということを歓迎する人もいるでしょう。本来はサイト内ブックマークとしての役割の一つですが、それが可視化されているために、はてブ数やイイね数のような指標としても使われます(投稿が信頼できるものかの絶対的指標ではありませんが、参考にはなります)。また、多く「ストック」されている記事が分かるので、そういう記事は多くの人の役に立っていたり興味をひいていたりといった指標にもなるので、使う側も嬉しい機能でしょう。

アフィリエイトを中心にしたい場合には自分のブログを使う

先ほど挙げた「プログラミング勉強日記」にも似ていますが、多くの書籍を読んだ勉強結果を書いた上で、それらの書籍のAmazonアフィリエイトリンクを貼って誘導させようという記事はQiitaより自分のブログのほうが良いです。

Qiitaでのアフィリエイトに関する規定はどうもグレーなのですが、サービス利用規約第8条第4項第2号を読むと「広告、宣伝および検索サイト最適化を目的としてユーザー登録、投稿する行為」は「行ってはなりません」と書かれています。常識的な文献の引用として補足的にアフィリエイトリンクを貼った書籍へのリンクは問題とはされないと思いますが、全面的にアフィリエイトを目的としたような記事はQiitaの禁止事項にひっかかりかねないと解釈できます。そういう小遣い稼ぎを狙った記事は自分のブログに書くのが安全でしょう。

Qiitaの将来性

せっかく書いた記事も、Qiitaというサービスが無くなってしまったら消えてしまいます。そういったサービス継続性の心配は、どんなサービスを使う上でも心得ておく必要があるでしょう。

私が見るに、Qiitaを作っているIncrements株式会社は、Qiita:Teamといった課金プランも用意していて、いわゆるGitHubなどに見られるようなフリーミアムモデルを採用しています。つまり広告収入以外の収益源があるということです。これはサービス継続性を見極める一つの基準となるでしょう。

またIncrements株式会社の人達のインタビューなどが多数ネット上で公開されていて、そのサービス継続性やサービス育成への期待感が感じられること。GitHubとの連携や、GitHubとの機能補完といった、今や開発者の素養となったGitHubとQiitaの関係を見極めているといった部分は大いに評価できると思います。

私は、そういった判断材料を総合して、Qiitaがすぐに無くなってしまったりはしないと判断しています (あくまで私個人の判断なので、責任は持てませんが)。

Qiitaとブログを緩く連携させる

最後になりますが、Qiitaとブログを「連携」させる方法は色々考えられるでしょう。

Qiita側からは、ユーザのURLを設定できるので、そこにブログのアドレスを書いておけばよいでしょう。

ブログ側からは、Qiitaが出力するフィードをブログパーツとして載せる手が考えられます。フィードをブログパーツにするサービスはFeedWindなどがあります。探してみるとよいでしょう。

この情報がQiitaとブログを効果的に使い分けしたい人の一助となれば幸いです。

PerlBeginners#12 に参加してきました #perlbeginners

おがた (@xtetsuji) です。

2014年3月21日に行われた「PerlBeginners#12」に参加してきました。

今回は2月に転職して最初のPerlBeginnersだったのですが、今の会社の同僚の方とインターンの方々と一緒に行くという感じでした。

毎回人が足りないといった理由でトークしたりしていているのですが、今回はトークする人も当初から多かったし、環境が変わってトークする資料作りする余裕もなかったということもあって、トークはしないで聴く側に回ることにしました。

場所は水天宮駅近くの「日本橋公会堂」

今回はUstream無し

とはいえ前回に引き続きUstream配信をしようと思っていたのですが、当日の会場が建物の内側にある会議室で全然電波が入らなかったこともあって、Ustreamは断念。

当日のタイムテーブル

当日のタイムテーブルは結果的にこんな感じになりました。

ビギナーズという名前に相応しい程度の難易度が維持できているのも特徴でしょう。

詳細は割愛しますが、少し撮影した写真から。今回は iPhone 5 をテザリング用に入口近くに置いておいたので、Nexus 5での撮影です。Nexus 5を撮影用に使ったのは初めてだったのですが、ちょっと iPhone 5 より画質が悪いなって感じました。

パールビジナーズ?

まさかの「パールビジナーズ」。

PBパールビジナーズ

予約の際に聞き間違えたとかでしょうか。

基調講演 by @dokechin

基調講演の冒頭より、@dokechin さん。この写真だと白バックで飛んでしまって見えないですが、スライドのキャラクターは娘に書いてもらったとのこと。資料公開に期待しましょう。

PB基調講演の様子

もともと、Mojoliciousを使って色々なサービスを作って公開している@dokechinさん。「テストではまったお話」は Test::More の is 関数の内部で悩んだという話など。

この辺りのブログ記事が発端でしょう。

このあとのビギナーズセッションでもNYTProfの読み方について質問したりといったやりとりが続きました。

ビギナーズセッションより

ビギナーズセッションの中で、仕事で主にインフラを担当されているという方からmod_perlについての質問が出て、なんか会場の雰囲気から私が回答する感じになって、少し語らせてもらいました。

最近のmod_perlはApacheやPerlの最新版に対応していない部分はあるのですが、Perlの後方互換性の高さから、特に理由がなければ最新版の一つ前を使うという方針でも問題無いのではないかといった話。また、RHEL7ではApache2.4採用の兼ね合いから、Apache2.4にまだ対応していないmod_perl2がコアモジュールから排除されてしまったことへの注意点などをお話させていただきました。ただ、mod_perlの開発は他の mod_{プログラミング言語} の開発と比べても昔も今も活発に行われているほうなので、心配ある方はmod_perlのSubversion http24開発ブランチをウォッチしたりしてみると良いかなと思います。

mod_perl で何か質問がありましたら、@xtetsuji にお気軽に質問ください。応えられる範囲でお答えします。

YAPCでやりますと言ったものの出来ていないmod_perl系の活動もそろそろやらんきゃなぁと思った次第です。あと、自分が自己満足でネットに書いた記事が実際に読まれて参考にされているということに少し驚きました。今は少し私生活に余裕が無い感じですが、これから少しずつ自分が持っている情報を出していければと思った次第です。

@maka2_donzoko さんがいらしていて、「Acme大全2013」の宣伝をしていました。あの書籍は良書なので、1500円のもとは取れると思います。

LT

LTは @__papix__ さん、@tsucchi さん、そして主宰の @ytnobody さん、最後に飛び入りで @magnolia_k_ さんがお話されました。コード無しの精神論(スピリチュアルトーク)から、コードを交えた解説まで、バランスが良かった印象でした。

@__papix__ さんが語っていた話は、コミュニティやオープンに活動しようと思いつつできない人が恐れていることが杞憂であることを突いた、良い指摘だったと思います。ネットの向こうにいるプロのプログラマの人達は、ほぼみんな業界を良くしていこうという優しい人達ばかりです。変なコードを公開しても優しく指摘してくれたり直してくれたりすることが多いので、それだけでも勉強になると言って良いでしょう。

@tsucchi さんのお話では、異常な努力のもとに成り立っているモジュールの紹介がありましたが、一時期誰もが使ったCGI.pmの中身の異常さは語り尽くせないものがありますね。また、SQLなどのパーサ系のバッドノウハウ満載モジュールも、中身を見てその異常な努力に驚愕することがあったり…。そういう異常な努力の上に出来たモジュールを使わせてもらうことは良いとしても、自分自身が異常な努力をすることは、時間的にも健康的にも良くないなと感じました。時には自分自身が率先して異常な努力をしないといけないことも人生の中にありますが、そういうときのために普段は体力を温存して普通の勉強をしてレベルアップしていったほうがいいと思います。

以下のまとめが的を射ているなと思いました。どうしても難しい処理にたいして難しいコードを書いてしまうときはきっとあるけど、簡単な処理を難しく書くことはやめてほいたほうがよい。

  • 難しい処理をしているときに難しいコードを書いてしまうのはしょうがない
  • 簡単な処理を難しく書いてしまっていないか

メールの仕様も深く立ち入っていくと尋常ならざる複雑さになっていくといった話の中で触れられたYAPC::Asia Tokyo 2011 での RJBS氏によるトークは以下です。

主宰でもある @ytnobody さんのお話では「べからず」のお話。氏が今まで指摘されてきた色々な「クールではない」点について一つずつ解説したお話でした。これも時代によって変わる価値観ではありますが、一頃に比べてだいぶ落ち着いたPerl界隈では、今もしばらくはこの価値観で行って問題はないと思います。

こういうプロ同士の実践の中から題材に上がる情報が生で聴けるのも、PerlBeginnersのような勉強会の魅力ですね。

飛び入りLTをした @magnolia_k_ さん、brewっぽいビルドツールをCPANで公開したりといったアクティブな方。今回も、自分が使ってバグを踏んだモジュールの作者に、英語で意見を送ったりパッチを送ったりということを臆することなくやっても意外と大丈夫なんだよといったことを語って私を含めた聴衆を勇気づけていました。良い話。

懇親会

木曜日とはいえ、次の日は春分の日で祭日だったため、期せずして「週末」となってしまい、ただでさえ居酒屋が少ない水天宮駅周辺で居酒屋難民になってしまいました。

とはいえ、多少さまよって店を見つけて入ることができました。3500円で2時間飲み食い放題はお得でした。

確か8人集まりました。懇親会でディープな話が聴けるのも、こういった勉強会の醍醐味。

各人の最近の業務やPerlとの関わりとか、次回に向けてどうするかとか、色々な話で盛り上がりました。

次回は5月あたりになりそうな予感。PerlBeginners#13も楽しみです。

Station TV i for Macから映像も音も出なかった意外な原因

おがた (@xtetsuji) です。

ずいぶん以前に、iPhoneやiPadでフルセグが観られる「SoftBank SELECTION デジタルTVチューナー SB-TV02-WFPL」というものを買って、iPhoneやiPadでフルセグを観ていました。iOSでの視聴は問題無く、それだけでもそこそこ重宝するものでした。

私は普段はMacBook Airを使っているので、これがMacでも使えると聞いて、2000円の追加出費をしてソフトウェア「Station TV i for Mac」を買いました。iPhone/iPadアプリは無料だというのに…。

その時はAmazonダウンロード販売を利用して購入しましたが、結果的にソフトウェアを起動してもEPG番組情報を取れるところまで進むものの黒い画面のまま画面も映らないし音も出ないという状況が続いていました。

もともと Station TV i for Mac は、画面キャプチャ能力を持っているアプリが起動していると、起動すらできないという厳しすぎる制限があって、Evernoteすら終了させないと起動すらできないというソフトウェアです。Evernoteに画面キャプチャ能力があるのかすらよく知らないのですが、とりあえずStation TV i for Macが起動できるところまで、普段常駐しているソフトウェアを終了させても、黒い画面のままという状態は脱することができませんでした。

サポートに電話してもそういう症状は無いらしく、諦めてiPhone/iPadのみで使っていましたが、今日古いMacBook Airを出してきて、ふとStation TV i for Macを起動させたら、なんと長い時を経て動いたのです。もしやと問題の切り分けをしていたら意外なことが分かりました。

  • ローカルマシンの8080番ポートが開いていると、黒い画面のままという症状になる

私は自分のMacBook Airからは自宅サーバにSSHをして使っていて、自宅サーバで8080番ポートで待ち受けているのSquid HTTPプロキシサーバへ SSH の ~/.ssh/config で「LocalForward 8080:localhost:8080」という設定を入れていました。つまり手元の8080番のTCPポートが自宅サーバのSquidの8080番ポートに繋がっている状態、手元の8080番ポートがHTTPプロキシサーバに見える状態になっていたのです。

この設定をオフにして新しいMacBook AirでStation TV i for Macを起動させてみると、なんと画面が映るではありませんか。

「起動時に手元にHTTPプロキシサーバが起動しているかポートスキャンしているのか?」と新たな謎仕様を疑ったりしたのですが、ローカルの8080番ポートにLocalForwardしている設定を試しに1080番ポートにしてStation TV i for Macを起動して、sshとStation TV i for Macを再起動してみても映るではありませんか。よく分かりませんが、Station TV i for Macは、起動したマシンの8080番ポートを見て、開いている(もしくは開いていてそれがHTTPプロキシサーバのポートである)ことを確認すると、映像も音も出さないらしいということが分かりました。

自宅限定ではありますが、普段使いのMacBook Airでフルセグが観られるようになって、ようやく快適になりました。

録画対応のマシンも今ではだいぶ安くなりました。欲しい。

浄輪寺にある関孝和の墓に行ってきました

昔は数学をやっていた、おがた (@xtetsuji) です。

3月15日(土曜日)に関孝和の墓に行ってお参りしてきました。江戸時代の大数学者です。

行ってみたかった

よく「東京の人は東京タワーに行かない」とか言われますよね。いつでも行けると思って行けない効果。最近も、札幌にずっと住んでいる人が北大のポプラ並木を見たことがなかったとかそんな話があって、自分も東京に相当長く住んでいるけど、そういう場所あったかなぁと考え直しました。

確かに東京タワーにも東京スカイツリーにも行ったことがない。かろうじて、都庁は良く行っているし東京ディズニーランドには行ったことがある程度。

昔勉強していて、今も勉強しなおしたいと思っている数学。そうだ、前々から興味があった関孝和の墓に行ってみようと思ったのでした。江戸時代の大数学科のお墓参りをして、改めて数学を勉強するぞと気合いを入れようと

行ってみた

検索してみるとすぐ場所が分かります。

一番近い場所に至る方法は、都営バスの「白61」という新宿と練馬車庫を大回りして運行している系統に乗って「牛込弁天町」というバス停で降りること。降りたすぐ近くに関孝和の墓がある「浄輪寺」にたどり着けます。

浄輪寺への入口

浄輪寺への道路からの入口はこんな感じ。「都史跡 浄輪寺」という石碑があるのですぐ分かると思います。

浄輪寺の入口の石碑 関孝和の墓、浄輪寺の入口

特に入るのに何か必要なわけではないので、とりあえず気を使いつつ入ります。

境内は普通の寺で普段は静かな場所です。通常の墓地となっており、関孝和の墓はその奥まった部分にあります。道は狭いので、知らずに入っていくにはちょっと勇気が要りますが、入っていくとすぐ分かります。

関孝和の墓

境内はそれほど広くないし大体一本道なので、都によって立てられた看板が目に入って、すぐ関孝和の墓の場所は分かると思います。

関孝和の墓の正面

看板には生い立ちや、その偉業の数々が書かれています。とても簡潔に分かります。

関孝和ってどんな人

江戸時代の数学者(和算家)です。詳しくはWikipediaの解説を読むと良いと思います。

例えば、高校時代に習ったことがある人もいる、あの「行列式」を世界で最初に見出した人でもあります。江戸時代に中国からもたらされた算術が日本国内で高度に発展した「和算」の中でも、取り分け「算聖」と呼ばれるまでになった人。後になって数学史研究者によって、西洋数学よりも数々の事実を先に発見していた人として、今に知られるようになりました。

墓はパワースポット?

大学が池袋の近くにあったころは、ときどき雑司が谷霊園を通り道にしていたことがありますが、あの墓地にも文豪の墓があったりして、良い散歩スポットだったことを思い出しました。

関孝和の墓、今あるのは二代目の墓とのことですが、ここにもともと関孝和が埋葬されたのかと感じると、特に何かをお願いしたわけではないですが、何かパワーがもらえたように感じます。そんな清々しい気分を味わいました。

暗いイメージが先行する墓場ですが、今を切り開いてくれた偉大な先人に敬意を表すキッカケになることは良い事はないか、今回の「墓参り」を通じてそう思わせてもらいました。

最近は帰省時期が悪く、自分の先祖への墓参りがここ数年できていないことが思い出されます。良くないですね。今年は彼岸の時期に帰省して、先祖の墓参りができるようにしたいと思います。

おまけ画像

3月15日、今年は厳冬でまだまだ冷えている感じではありましたが、境内の入口近くの木には元気に花が咲いていました。桜はまだとして、梅とかかな。病気の連続、そして2月からの新生活で色々忙殺されている中、少し心が癒された感じがしました。

関孝和の墓の近くに咲いていた花

 

Twitterのお気に入りツイートを振り返ってみて気づいたこと

おがた (@xtetsuji) です。

今回の記事は、ちょっと「気がついたから考えてみた系」のただのエッセーです。

Twitterにはツイートの「お気に入り」という機能があります。よく「ふぁぼ」とか言われるものです。ここではRTのように、Favということにします。

「あとで読む」はもう読まない

Favは「あとで読む」的な意味合いもあるとは思うんですが、世の中「あとで読む」とタグ付けされたものは、大抵あとで読まれないという法則があります。

自分も大量のブックマークをDeliciousに投稿したりしていますが、「あとで読む」というタグ付けは使わないようにしています。逆に「何度も読みたい」というタグ付けにして、一度は必ず目を通す、目を通すまでブラウザのタブは閉じないようにするという流れにしています。そういうようなタグ付けの工夫をすることによって、Deliciousブックマークの内容をあとで活用できることが多くなってきました。Delicious側が過去ブックマークの表示機能を高速化したというのも大きいです。使いやすい。

TwitterのFavも、この「あとで読む」的意味合いが多少なりともあると思います。もちろん、Fav結果がツイート主などにも伝わるのでそのツイートへの同意を示す意味合いや承認的意味合いもあるでしょう。ただ、このFav、あとで見返すことができるようになっているのに、しないのはもったいないなと感じた次第です。Deliciousブックマークの振り返り運用が最近うまくいっているからこそ思ったことなのかもしれません。

サードパーティのTwitterクライアントでは既に全てのFavをたどれないかもしれません。その場合はTwitterの公式クライアントか公式ウェブを使えば、少なくとも1000ツイートFav程度ならたどることができます。この理由は後述。

Favより自分の手法でメモしておいたほうがあとで検索できる

自分の場合、メモっておきたいツイートは自分専用のプログラムで自分用IRCチャンネルに投稿してIRCボットにログを取ってもらうようして (簡単なコンセプトは以前トークした「クリップボード監視と外部コマンド実行 #chibapm」のスライドを参照) います。ボタンひとつでログファイルに残るので、便利でガンガン使っています。ログファイルの検索も簡単なので、あとで「あのツイート、コピーしておいたけどなんだったけなー」といった時にも役立ちます。

TwitterのFavツイートは事実上あとで検索できないし、自分で書いたプログラムで回収しようとしてもTwitter API1.1のレートリミットの制限で指定時間内に数百ツイートしか回収できないようで、自分がFavするツイートは「これぞ」といったもののみに最近はしています。Tweetbot for iOSというクライアントでも2012年くらいのツイートまでしかたどれませんでした。これはTwitterクライアントが悪いわけではなく、Twitter社の提供するTwitter API1.1での制限です。

気になったツイートのロギング手法については、こんどいくつか解説してみたいと思います。

というわけで、私のFavには特別な思いがこもったものが多いのですが、それを振り返ってみようとして気づいたことを書いてみたいと思います。実際にツイートを列挙して振り返るのは今度にしようと思います。

Twitterを始めたきっかけ

Twitterは2006年頃からあるサービスですが、当時ブログや公での発言にあまり積極的でなかった私は「マイクロブログ」と称していたTwitterに対しては距離を置いていました。

ただ、2008年頃からジワジワとTwitterは日本でも影響力を増していきます。2009年9月のYAPC::Asia TokyoではTwitterを主要な連絡手段にするというアナウンスがあって、そこで半ば負けた気持ちでTwitterに登録したのが2009年9月9日でした。

最初のツイート。敗北を認めた感じが伝わってきます。当時は2008年くらいまで多忙を極めていて、ネットのトレンドなどが追えていなかったことがあって、Twitterは流行らず消えると考えていたり、とにかく勘が鈍っていたような気がします。

その後、試行錯誤しながらツイートしていきますが、Twitterの楽しさというか活用法も分かってきて、同報通信的用途や自分のライフログ的用途に活用していくようになります。特に2011年3月の東日本大震災前後でTwitterの活用が広がっていったり変化していったような気がします。

他のブログ記事でも書きましたが、2011年からは勉強会でトークするようになったり、ブログを開設したり、対外的な発言も積極的に行うようになって、Twitterとの連動も広がっていきました。

震災に対外的活動デビューにと、2011年は節目の年でした。

Favを振り返って分かったこと

2009年9月9日から2014年3月16日までの間に、私のFavツイートは1000ちょっとあるようです。https://twitter.com/xtetsuji/favorites にアクセスして、たどれる最初のFavまでたどって、Chromeのデベロッパーコンソールで document.getElementsByClassName(“tweet-text”).length を打った結果です。最初はよく分からずブックマーク代わり程度にFavを使っていたので、厳選してこの数というわけではないです。

とはいえ、Twitterのウェブインターフェースでは、たどれるFavの数に制限は無さそう(3200制限はあるかもしれない)なんですが、どうも2012年11月4日以前のツイートのFavの取り消しができないっぽい。もしかしたら私だけの現象かもしれませんが、Twitterは定期的に仕様を変えてきているので、何らかの要因はあるのかもしれません。特定の人にだけ起こる不具合というのもTwitterにはあって、それを踏んでいるのかもしれません。

当時はフィードリーダーの代わりにTwitterのURL付き投稿をブックマーク感覚でFavしていたのですが、あとで検索できないということもあって、このフィードリーダーのブックマークがわりとしてFavを使うのは、本当に大切なFavツイートを見返せないから良くないなと今になって追っている次第です。

次回は

実際に同感して付けたFavツイートを振り返って、当時または今の自分がどう考えるか、時間を見つけて少しずつ振り返ってみたいと思います。

Mac版Googleドライブのディレクトリを変更する方法

おがた (@xtetsuji) です。

Mac OS X 版の日本語「Googleドライブ」アプリを入れると、ホームディレクトリに「Google ドライブ」という名前のディレクトリが作られて、特にコマンドラインで扱いづらいので名前を変更したいんだけど…という話です。

はじめに

$ cd ~/Library/Application Support/Google/Drive/

ls をすると

$ ls 
CrashReports/                   snapshot.db-shm
FinderExt.bundle/               snapshot.db-wal
cacerts                         sync_config.db
cloud_graph/                    sync_config.db-shm
lockfile                        sync_config.db-wal
mach_inject_bundle_stub.bundle/ sync_log.log
snapshot.db

といった感じ。今回は設定が入った sync_config.db が主役です。

念のためバックアップ

$ cp sync_config.db sync_config.db.bak

情報書き換え

sqlite3コマンドを使って設定情報をUPDATEします。今回はホームディレクトリ直下に “Google Drive” というディレクトリとすることにしましょう。

Googleドライブアプリをいったん終了させて、以下のように

$ sqlite3 sync_config.db "UPDATE data SET data_value='$HOME/Google Drive' WHERE entry_key='local_sync_root_path'"

とコマンド入力をすれば良いです。date_value= 部分を適宜書き換えればOK。

実際のディレクトリ名の変更も忘れずに。Googleドライブアプリを終了したあと

$ cd
$ mv "Google ドライブ" "Google Drive"

を実行してリネーム(Finderでやってもいいです)。そしてアプリを再度起動するとよいでしょう。

エラー「Googleドライブ フォルダが見つからないため…」が出た場合は設定が間違っている可能性があるので、バックアップを戻してもう一度精査してください。

設定は自己責任でお願いいたします。

今回は「Google ドライブ」アプリ バージョン 1.8.4357.4863 で検証しました。

実際いまはどうしているの?

結局Googleドライブアプリはアンインストールしてしまいました。どうも馴染めなかった。どうせGoogleドライブ特有のファイルをダブルクリックしたらブラウザに飛ばされるのであれば、最初からGoogleドライブのトップ画面にブラウザで飛んだほうが便利だし、ブラウザ上ではドラッグアンドドロップでアップロードとかが出来るので、特にブラウザで不便を感じないというのもありました。

同期系のストレージであればDropboxが、WebDAV系ストレージであればBox.comがあるので、ひとまずGoogleドライブはそれらとは違う使い方をしているという感じです。

参考

Mac OS X で /var/folder の中身を削除したら画面からアイコン画像が消失した

おがた (@xtetsuji) です。

今回は完全に「やっちゃダメ」シリーズと、日頃からどうするべきか考えるシリーズ。

/var/folders 消してアイコンが消えていった事件

酔っていて電車に座れたので、MacBook Airを開いてファイル整理をしていたんですが、find / -size +250MB などとして無駄な大きなディレクトリを探そうとしていたら、”/var/folders” というのがあって、中を見ても明らかにキャッシュでしかなかったので躊躇なく rm -rf しました。

そうしたら、しばらくしたらドックや(Command-Tabで出てくる)タスクスイッチャーや、デスクトップ上のアイコン画像がどんどん消え始めました。名前だけ出てきてアイコンはないけど存在しないはずのアイコンの影はあるといった感じ。Finderから見えるファイルのアイコンも消えていきました。恐ろしい!

ドックから消えたアイコン画像

Windowsでも似たようなことがあったときに再移動したらアイコンキャッシュが戻ったので再起動してみたものの、全く直る様子なし。

あとで調べてみたら、やはり /var/folders はキャッシュディレクトリのようでした。例えば 新・OS X ハッキング! (56) 新世代のOS Xユーザへ(4):情報の宝庫「/var」 | マイナビニュース が詳しい。その他にも /var/folders で検索してみると出てくるのですが、これ関連でトラブルに陥って結局直せない人が多いという印象でした。前出の記事ではログアウトしたら消えるディレクトリのはずが、再起動しても戻らなかったりしました。

私も色々やってみた挙句、自分の症状も治らなかったので、結局6日前に取っていたTime Machineのバックアップを引き上げて復帰させたという感じ。ちょうど平日は仕事で忙しくてそれほど個人用MacBook Airにファイルを置いたりしていなかったので、まだ傷口が浅かったです。

ちなみにTime Machineからの復元方法は、いったんMacを終了させて、Time Machineディスクをつないでおいて電源投入時にCommand-R を押しっぱなしで起動させること。これで復元ウィザードが出るので、あとは画面に従って復帰していきます。この方法だとOSイメージごとまるまる復元されるので、たとえばMountain LionのTime MachineイメージをMavericksに復元させるとMountain Lionに戻るくらいまるまる書き換えてくれるものです。

とりあえず6日前に戻して、あとは取り戻す必要のあるファイルを、GitHubやBitbucketから取ってきたり、Dropboxを同期させたりして対応しました。

既にトラブルが起こっているときにTime Machineを接続して、その時の記録も取られているので、バージョン管理やオンラインストレージの管理下ではないディレクトリのファイルも部分的にTime Machineで取り戻せるとは思いますが、まぁ自分の場合は6日の変更内容がほとんどGitHub、BitBucket、Dropbox上のものだったので助かった感じ。

教訓

  • /var/folders はキャッシュディレクトリだけど、巨大だからといって軽く扱ってはダメ
  • Time Machineは日頃から励行したい
  • 何かあったときに面倒なので、Time MachineディスクはローカルUSB接続が面倒だけど速いしオススメ
  • ファイル類はなるべくバージョン管理して外に出すようにして、GitHubやBitbucketに日々pushする習慣をつけておくとよい。またDropboxなどのオンラインストレージを活用するのもよい
  • Google Chromeのオンライン同期は素晴らしい。ブックマークとかは直前のものがそのまま同期された
  • 酔ってパソコンを操作するときは、ファイル整理とか失敗すると危険な作業はしない

色々と教訓を得ることができました。