Mac OSXでタイムマシーンのバックアップが重い

2013年1月20日 Mac OS X, 未分類, 高速化

Macで作業をしているとタイムマシーンが自動的に実行されて、タイムマシーンでバックアップ中にPCがよく固まるようになってきました。バックアップ先の外付けHDDの性能が悪いのか、単純にMacの内蔵HDDの性能が悪いのかわかりませんが、ひとつ気づいた点として毎回新たにバックアップされるサイズが多いことに気づきました。

一時間毎の実行にもかかわらず 4.46GBくらいバックアップしようとします。さすがこれは多すぎますよね。ファイルをダウンロードしたわけでもないのになぜかこの容量。なぜだろうと重い考えてみると、一つピンとくることが。
もしかしてキャッシュまでバックアップしてるんじゃないか・・・
実際、タイムマシーンの設定を見ると、除外フォルダがSpotlightのデータと、タイムマシーンのバックアップ先ディスクのみになっていました。つまりライブラリフォルダが復元作業のために必要としても、そのライブラリフォルダの中にある、Chromeのキャッシュフォルダやテンポラリフォルダまでもがバックアップの対象になっていたようです。

つまり、タイムマシーンでのバックアップ作業中にChromeが動かなくなったり固まったりするのは、キャッシュフォルダをタイムマシーンがロックをかけChrome上からキャッシュにアクセスできなくなっていたのが問題だったのではないかと予測することができます。もちろんあくまで推測ではあるのですが、この考えを元にタイムマシーンからキャッシュフォルダ、テンポラリフォルダ、そして忘れてはいけないのがlogフォルダを除外対象にします。

キャッシュ、一時、ログフォルダの除外

タイムマシーンを開いたら「オプション」をクリック。

何にも除外対象になっていません、キャッシュもログもおもいっきりバックアップされてしまいます。これはひどいですね。「+」を押して除外したいフォルダを選択します。

ディレクトリを 「Machintosh HDD(SSD)」 にしたあと、検索バーに「cache」と入力します。

検索対象に 「Machintosh HDD(SSD)」 を選択します。

種類でフォルダを選択します。

キャッシュフォルダがたくさん出てくるので全て選択して除外をクリックします。

これをあと二回繰り返して「logs」、「temp -template」を除外対象にします。

すると、一時間ごとのバックアップ時にバックアップされるサイズがかなり減ります。
さすがにバックアップ時に少しだけ重くなってしまうは仕方ないですが、すぐにバックアップが終わるようになるのでかなり快適に操作することができるようになります。

最後に

バックアップから除外したことによって復元に失敗してしまう可能性も少なからずあるので、自己責任でお願いします。

コメント

HTML5 History API を徹底的に試してみる

2013年1月18日 HTML5, Javascript

History APIとは

History APIはHTML5の機能のひとつで、ブラウザの戻る進むボタンのイベントを取得してページの内容を動的に変えることができるものです。なかなか便利な機能ではあったのですが、ちょっとつまずきポイントが多く、癖もかなりあるっぽいので徹底的に試してみようと思います。

スタック

ブラウザの履歴の一つ一つの記録をスタックといい、一つ履歴が増える度にスタックが増える。そしてHistoryAPIを使うとこのスタックをページ推移を行わなくても増やすことができます。 HistoryAPIによってスタックが増えた場合は、ブラウザの戻るボタンを押してもページ遷移が発生せず、何も起きない。それがHistory API。

スタックの追加

スタックを追加するには、このようにやります。 
history.pushState("hoge", null, "/hoge");Code language: JavaScript (javascript)
これで、履歴が一つ分増えます。これを実行すると、ブラウザの戻るボタンを一度押しても何も起きません。(ページ推移が発生しません) しかし、二回ボタンを押すといつもどおりページ推移が発生します。 しかし、このhistory.pushStateを使う前に必ず 
history.replaceState("index");Code language: JavaScript (javascript)
とします。 これをすることでGoogle Developer Tools もしくは Firebug上で 
history
と入力し、エンターを押すと、historyオブジェクトが見えるので、historyオブジェクトを展開し、stateプロパティを確認すると、そこがindexになっていることが確認できます。 必ずこれをやっておかないとめんどくさいことになります。

ブラウザの戻る・進むイベントを監視する

jQueryを使っていますが、jQueryの場合はこのように書くことでイベントが実装できます。 
$(window).on("popstate", function(_event){
    var state = _event.originalEvent.state;
    console.log("_event", _event);
    console.log("state", state);
});Code language: JavaScript (javascript)
これをソースコード内に記述して、 
history.pushState("hoge", null, "/hoge");Code language: JavaScript (javascript)
を実行して、ブラウザの戻るボタンをクリックします。 Google Developper Tools または Firebugのコンソールで確認すると、 state がindexになっていることがわかります。 これがハマりポイントでした。最初に history.replaceState(“index”); をしたことで、index と表示されたわけですが、これをやらないとここが、 null になってしまいます。 最初このstateの値は hoge になるものだと思っていたのですが、実はそうではなく、戻るページに設定されているstateらしいです。 構造的には「index -> hoge」 という構造になっています。 このあたりがややこしいので注意が必要です。

Tips

History APIは基本的に以上の仕組みさえ理解すればそれだけですんなりと使えますが、他にも覚えておくと便利な点をあげておきます。

history.state

現在のstateを確認できます。indexなのかhogeなのか。

history.back()

これを実行するとブラウザを戻ります。ページ内に戻るボタンを設置する場合はこのメソッドを使用します。ただ、対応していないブラウザもあるので機能を切り分ける必要があります。

history.forward()

これを実行するとブラウザを進みます

history.go(num)

指定した履歴へジャンプします。

history.length

現在の履歴の数を表示します

location.pathname

現在のドメインを覗いたディレクトリパスを取得します

location.search

現在のURLの?の後ろのパラメータを取得します
コメント

個人情報を持たないWebサービスの設計

2013年1月4日 アイデア

Webサービスを作るにあたってどうしても考えなければならないのが、個人情報の取り扱いについて。メールアドレスや名前をもらっただけでもそれだけでも個人情報になるし、IDやパスワードを与えても個人情報になる。Webサービス自体はとてもおもしろいものなのに、信頼できないサイトだった場合使ってくれないこともしばしばある。

このめんどくさい個人情報の取り扱いをなんとかしてパスする方法はないものかとこの記事では考えてみることにする。

個人情報とは何か

Webサービスを作るにあたって最低限必要なものを上げてみる。

  • お名前
  • メールアドレス
  • ID
  • パスワード
  • セッションID

最低限、このくらいは必要になるだろう。最後のセッションIDというのは、今ログインしているかどうかを判断するのに使う。クッキーで保持されているもののことです。

では、この5つの項目をパスすれば、個人情報をもたないWebサービスを作ることができるのではないかと考えてみる。

コンセプト

そもそもなぜ個人情報が必要なのかというと、自分専用のページを持つということにつきると思う。マイページ。Webサービス上で自分という存在をアピールすることができることがどんなWebサービスにおいても共通解であると思う。例えば、はてなブックマークも自分がはてブしたりすることで、そのWebページに対してコメントを書き加えられる。チラ裏みたいなことができる。

そういったものを提供できなくては、Webサービスとして成り立たないのではない。だけども、それをやってしまうと個人情報を持つことになる。ではどうすべきか・・・、はい、考えました。

限定公開URLという考え方

ユーザーに対してあなた専用のページを与えるのではなく、URLさえ知らなかければ誰もアクセスできないページを提供するということです。IDやPWなどは一切必要とせず、その限定公開URLをユーザーに対して提供する。しかも、仕様上何個でも限定公開URLを発行できる。ボード

誰にもURLさえ教えなければ、それを自分専用に使うこともできるし、他の人に共有することもできる。

限定公開URLにとどまらない

しかも、URLに限定することも実はなくて、「アイデンティケーションコード」を一つだけ持っていればそのコードに対してAPIによってPOSTしたりGETしたりすることによって、例えばChrome拡張にそのコードを登録するだけで、使えるようなサービスが運用できる。ちなみに、アイデンティフィケーションはIDの略なので、IDCODEという意味になってしまうが、ここはIDとは差別化したいのでそう呼ぶことにした。

ボード

この限定公開URLによって運用するWebサービスのことをこの記事では以下「ボード」と呼ぶことにします。限定公開URLがひとつのボードとして提供されるという意味からです。

問題点

ただ、ボードを提供するにあたって問題点となるのはやはり、限定公開URLなのにもかかわらず、第三者によって傍受されてしまう危険性があるということ、なので日記サイトとか、個人情報に密接に関わりそうそうなWebサービスはできるだけ避けたほうがいい。HTTPSを使わない場合は、更にそのリスクが高まる。

ではどんなWebサービスがいいのか

診断メーカーなどは、名前(ニックネーム)を入力するだけですぐに結果がもらえる。そういったWebサービスであれば、個人情報を持つリスクが最小限に抑えられる。

OAuthというやり方も

実はHTTPSを使わくてもある程度個人情報を保護できるやり方があり、OAuthを使ってログインすると、限定公開URLを使わなくてもある程度安全なWebサービスを運用できる。診断メーカーもそのうちの一つ。

コメント