Googleフォトで写真のバックアップ環境がようやく整った

Googleフォトでましたね。

長年の課題デジカメ&iPhoneの写真をどうするか問題がGoogleフォトの無料化で90%くらい解決しました。
紆余曲折を経て、ここ数年はデジカメとiPhoneの合わせて15000枚程の写真を、iPhoto(現在の写真アプリ)に保存してました。iPhotoライブラリはデフォルトのままだとMBAのハードディスクの容量が一杯になるので外付けHDです。
ただ、これだとノートパソコンでいつでも気軽にみれないし、外部(オンライン経由)からもみれない。
その解決策としてiPhotoの野良プラグインで定期的にGoogle+にアップロードするというもの。一度に行えるのは1000枚までだし、「ここからこの写真まで」というのも手動で選んで管理しないとダメでした。
Google+へのバックアップはrawファイルじゃなかったので、バックアップはたまにrsyncで別の外付けHDDに行うというからりアクロバティックな技も用いてました。

で、今回のGoogleフォトのリリースでiPhotoを使うのは辞めて、Googleフォトで一括管理することになりました。

既存ファイルのGoogleフォトへの移行作業が結構大変でした。
iPhotoやMacの同期ツールがあるけど、これだと既存Googleフォト(G+移行分)とiPhotoとiPhoneの写真が重複する可能性があります。
そこで、一旦Googleフォトの削除を行いました。Webだと相当時間がかかるため、MacもiPhoneの同期も止めてiPhoneアプリから削除を行います。

予め想定してたのですが、iPhoneアプリで削除を行うとiPhoneの写真も消えてしまいます。私の場合はiPhotoに置いてたので問題なかったですがこれは少し焦りますね。Googleフォトに「バックアップ」のつもりが「同期」状態になってます。Macだと「バックアップ」感覚ですね。Googleフォトから写真けしてもiPhotoから消えるわけではない。
余談続きでいうと、iPhoneアプリのバックアップはバックグランドで動いてるくれません。アプリ立ち上げとかないとダメなんです。謎仕様。

これで、GoogleフォトとiPhoneの写真は綺麗さっぱりなくなりました。
あとは、既存ファイルに関してはMacアプリでiPhotoライブラリのデータをGoogleフォトにバックアップすればOKです。rawファイルをアップロードする事もありすごい時間はかかります。1ファイル20秒程なので数日はかかりそうですが、たまに自動で出来上がるイベントを眺めたりして過ごしてます。

最近はデジカメで写真を取ることは滅多になくiPhoneばかりなので、たまにGoogleフォトのiPhoneアプリを立ち上げバックアップ取っていけば安心ですね。

さらにApple熱が下がり、次はAndroidへのスイッチが確実だと思った今回のI/Oでした。

めでたしめでたし。

0

あとで読むサービス→Evernote

Reederのソファーアイコン(Readability)を邪魔だな〜と思い続けて半年、ふと思い立ってサインアップしてみたら非常に便利でびっくり。
Readabilityの他、Read it Laterinstapaperとか所謂「あとで読む」サービスの名前は聞いた事あったけど、使う事ないだろうと思っていました。
本文抽出してスクラップなんて便利だけど普通にサイトみればいいと思ってたけど、Readabilityを通すと読むという行為がほんと楽しい。
ついでにRead it Laterinstapaperも使ってみたけどこれらもまた良い感じ。昔の紙copiを彷彿とさせるものがあります。
2chのまとめサイトはサイドバーやヘッダーからあれなので会社で見る時ドキドキするけど、この手のサービスを使えば読みやすくなる。そういう使い方もありな気がする。
その流れで最近TL上でよくみかけるiftttもサインアップしてみた。これもすばらしい。こんなサービスを作ってみたかった。

各サービスのレビューは色んな所で説明されてるので割愛してキャプチャだけ。
元のページ
Readability
Read it Later
instapaper
スマホのクライアントも試してないし、サンプルはこの1ページのみだけど
Readability→Read it Rater→installer
の順で見やすいけどReadabilityはスマホのアプリがないので今はRead it Raterを使ってます。

ちなみにgoogle trendではinstapaperが一番らしい。

そんな事より変態的な使い方としてはやはり後で読む系のサービスをEvernoteで読んでみたいので少し調べてみた。

■Read it Later
iftttでは既読にするのをtriggerにEvernoteに送れる
APIではArticle View(旧Get Text Only Version)でとれる

■Readability
iftttではスターをつけるのをtriggerにEvernoteに送れる
APIでは/articles/{article_id}で全文とれる

■instapaper
instapaper自体がevernote対応してるので、Likeした時にevernoteに送る事ができる
iftttでのトリガーはない
iphoneアプリだとevernoteへ送るボタンある
APIでは/api/1/bookmarks/get_text{bookmark_id}でとれる。
bookmarksだけどこれが「後で読むリスト」の事だと思う。

iftttでは「後で読む」しただけではどれもEvernoteに送ってくれない。
cronでAPIを叩いて新しい登録があればevernoteへ保存というのは可能。
これをサービスとしてできたらいいなとは思うけど、もうこの手サービスは懲り懲りという感もあるので誰か作ってくれないかな。

逆にはてなブックマーク→後で読むサービスとかでもいいか。

本文抽出というのはブログだと結構な精度でできるのだけど、ブログでないもの(サービス系サイト)とかだと俄然精度が下がってしまう。
そもそもどこが本文なのかというのは主観でしかみれないし、ミスった時のリカバーが難しい。
そんな理由でhatebteでは実装してない。という言い訳を最後にしてみる。

0

マークアップエンジニア

IT戦記 – マークアップエンジニアはどこへ向かうべきか(を考えてたらカッとなって LL の資料公開)

どこへ向かうかはしらんが、マークアップエンジニアネタを書きたくなった。
昨今の制作会社では、次のような3タイプのマークアップエンジニア(コーダー)に分かれます。

  1. 旧来のテーブルレイアウトでしか組めない人間
  2. フルスタイルでしか組めない人間
  3. そして両方使いこなせる人間

一番いいのはもちろん3番です。
受託開発では新しくつくるサイトはフルスタイルであっても、一年以上前につくったテーブルレイアウトのサイトの修正という仕事は多々あります。
jcode.plを使ったperlのフォームの修正があるように。。
それらをこなすためには、枯れた技術というものはしっかり理解してなくてはなりません。

という理由で少し残念なのが2番目のフルスタイルでしか組めない人間。
社内では一定の評価はされるものの実務ではこのように足をひっぱることもあります。
ここ1,2年でこの業界に入った若人に多いです。

そして、もっとも残念なのが1番のテーブルでしか組めない人。
ぶっちゃけ会社にはいりません。
年でいうところの30才手前に多いです。
若き頃DWを使いごりごりテーブルレイアウトしていた人たちですね。
うまく(X)HTML+CSSの波に乗り損ねた人たちは、必死で枯れた技術にしがみつこうとします。
「ユーザーはそんなこと気にしてない」と。
確かに少し上流の仕事をしていたら、その辺の技術習得は疎かになるかもしれないけど、僕が一番この手の人間が情けないと思うのは、そのフットワークの重さ。
この移り変わりの激しい業界では、常にアンテナはって新しいトレンドを追いかけないとだめなのにそんなところで停滞してるはどうかと思う。

世間でいうWeb2.0なサイトがテーブルで組んでますか?

0

CSSNiteについてまったく関係ない俺が一言

俺の意見なんてどうでもいいんだろうけど、気持ちを文にするいい練習材料になるので書いておこう。

まず俺のスペック

  • 業界歴は4年くらい
  • 現在も制作会社勤務
  • 最初の1年はデザイン、コーディング、プログラム
  • 残りの3年はメインはプログラム、たまにコーディング
  • プログラム系のセミナーは何回か行った。(YAPC asiaも)
  • CSSNiteも一回行った。

俺が考えるCSSNiteが嫌われるの根底の理由は3つ。

      主催者が嫌い
      エンジニアがコーダーを見下してる
      (エンジニアからして)セミナーの質が低い

の気がします。

1に関しては、CSSNiteに行ったが、確かにうっとしい。個性が強いだけでは済まされない人間性。
(景品を取りに行く)客に走ってくださいと行ってみたり、前回のCSSNite前夜祭のネタと同じものやってみたり。
CSSNite前夜祭は無料、CSSNiteは有料で同じネタっておかしくない?
そして、なんでそんな偉そうなの?

2つ目に関していえば、認めたくはないがそれはある。
逆も思われるだろう。システム馬鹿と。
java使いがperl使いを見下しperl使いがphp使いを見下す。
そして、php使い(だけじゃないけど)がさらにHTMLコーダーを見下す。

そして3つ目。
クオリティが低い。
大阪だったのもあるけど、ふつーうの兄ちゃん姉ちゃんが普通の話しをしてくれる感じです。
ドリの使い方なんかを。
クオリティより量なんでしょうか。
イベントの数が多い多い。
多いのはいいけど質も高めて。

どんだけ~。

0

Google Gears

Google Gearsでました。
オフラインでもWEBアプリケーションが使えるというものです。

はじめの感想としては、「最新のデータ取得するにはネットにつなぐんでしょ」「フィードが全文配信じゃなければどうするの」ってが正直なところ。
GmailがGoogle Gearsに対応しても最新のメールとれないと意味ないやん。。。
Google Readerでフィードの半分だけみて、あとはネットつないでから、っていうのはいくら新物好きの僕にも全然魅力的じゃありません。
昔ダイヤルアップ接続時代に、とりあえずページを読み込んで、切断してオフラインで読むという行動に相通づるものがあります。
これから対応するアプリが色々でてくるだろうけど、さっそく対応を発表したのがタスク管理ツールのRemember The Milk
むしろこっちの方がアプリ内で完結するという理由でGoogleGearsの魅力を引き出してると思う。

ただ、このGoogle Gearsはよく考えれば何もオフライン時に使わなくてもローカルに保存する機能というのをうまく使えば普通のブラウジングがかなり高速化するのでないでしょうか。
必要な時に必要な分だけ取得しながらブラウジングしていく。
もしくは、オフラインがメインとなるアプリでたまに通信を必要とするもの。
こんな使い方があってもいいのかもしれません。