[技術書つまみ食い] 『Emacs 実践入門』第一回

この本は一体?

Emacs24 に対応した比較的新しい本。ざっと写経しながら動作を見ていきました。

写経結果

こういう設定ファイルになりました。

今のini.el

とりあえずまとめ

去年まで、わりとカオスな設定だったけど、色んな elisp を package の奴に入れ替えたりとかしてスッキリしたかも。
やっと elisp にも慣れて来たので、もうちょい複雑な関数を自分で書いてみたい。

カテゴリー: 技術書つまみ食い | コメントする

[技術書つまみ食い] 『MongoDB イン・アクション』第四回

[技術書つまみ食い] 『MongoDB イン・アクション』第三回 の続きです。

3章 MongoDB を使ったプログラムの作成

前回は TwitterAPI の検索結果を MongoDB へ格納するところまでをやりました。
今回は格納されているデータを使って Web 画面に Tweet の内容を表示させます。

ハマったので fix

まぁ、ハマったって程では無いですが、やっぱり TwitterAPI の最新の仕様への対応は必要ですね。erb の一部に修正が必要でした。
当該箇所(p63)のサンプルコードは下記の通り。

  <body>
    <h1>Tweet Archive</h1>
    <% TAGS.each do |tag|%>
      <a href="/?tag=<%= tag %>"><%= tag %></a>
    <% end %>
    <% @tweets.each do |tweet| %>
      <h2><%= tweet['text']  %></h2>
      <p>
        <a href="http://twitter.com/<%= tweet['from_user'] %>">
          <%= tweet['from_user'] %>
        </a> on <%= tweet['created_at'] %>
      </p>
      <img src="<%= tweet['profile_image_url'] %>" width="48" />
    <% end %>
  </body>

現行の TwitterAPI のレスポンスには from_user とかが無いので、実際に格納されているデータの構造を javascript シェルで覗いて、対応するように修正しました。
修正版は下記の通り。

  <body>
    <h1>Tweet Archive</h1>
    <% TAGS.each do |tag|%>
      <a href="/?tag=<%= tag %>"><%= tag %></a>
    <% end %>
    <% @tweets.each do |tweet| %>
      <h2><%= tweet['text']  %></h2>
      <p>
#       <a href="http://twitter.com/<%= tweet['from_user'] %>">
        <a href="http://twitter.com/<%= tweet['user']['screen_name'] %>">
#         <%= tweet['from_user'] %>
          <%= tweet['user']['screen_name'] %>
        </a> on <%= tweet['created_at'] %>
      </p>
#     <img src="<%= tweet['profile_image_url'] %>" width="48" />
      <img src="<%= tweet['user']['profile_image_url'] %>" width="48" />
    <% end %>
  </body>

動作結果

sinatra サーバーを立ち上げてアクセスしたら、ちゃんと動いている事が確認できました。
twitter_archive

とりあえずまとめ

Twitter みたいに、レスポンスのデータ構造がコロコロ変わるようなサービスと接続するアプリケーションを作るにあたって「とりあえずレスポンスを丸々保存しておいて、使うときに調整する」みたいなアプローチは超強力と言わざるを得ないですね。スキーマレスって、アタマでは理解していたつもりだったけど、思っていた以上に楽だって事が分かりました。
ココまでで第1部がおしまい。次から第2部4章です。これまでとは違って、少し複雑なアプリケーションを作るようなので、書いたソースは随時 github にプッシュしながら進めていこうかと思います。
以上!

カテゴリー: 技術書つまみ食い | 1件のコメント

[技術書つまみ食い] 『MongoDB イン・アクション』第三回

[技術書つまみ食い] 『MongoDB イン・アクション』第二回 の続きです。

3章 MongoDB を使ったプログラムの作成

この章は、The Twitter Ruby Gem を使って Twitter の検索結果を取得して MongoDB へ突っ込んでいくというサンプルです。

ハマったので fix

写経なので、一言一句間違いなくソースをタイプして動かしたんですが、動きませんでした。( uninitialized constant Twitter::Search (NameError) )
gem i twitter したあと、require ‘twitter’ して下記のコードを動かすっていう部分です。(p59)

  def save_tweets_for(term)
    Twitter::Search.new.containing(term).each do |tweet|
      @tweets_found += 1
      tweet_with_tag = tweet.to_hash.merge!({tags: [term]})
      @tweets.save(tweet_with_tag)
    end
  end

わしが動かした時点の The Twitter Ruby Gem のバージョンは 4.4.2 ですが、Twitter:Search は既に存在していませんでした。
Twitter API への get だけであっても、認証済みクライアントを使うことが推奨(もしくは強制?)されている影響っぽいっすね。
下記の様に、まず Twitter::Client のインスタンスを作って、search メソッドで検索すれば結果が出てきます。※ ***** の部分は適宜用意したものをセット

  def save_tweets_for(term)
    client = Twitter::Client.new(
      consumer_key: "*****",
      consumer_secret: "*****",
      oauth_token: "*****",
      oauth_token_secret: "*****"
    )
#   Twitter::Search.new.containing(term).each do |tweet|
    client.search(term).results.each do |tweet|
      @tweets_found += 1
      tweet_with_tag = tweet.to_hash.merge!({tags: [term]})
      @tweets.save(tweet_with_tag)
    end
  end

とりあえず動く事が確認できたから、次回は initialize で @client を作って使い回すように修正してから続きをやりましょう。

とりあえずまとめ

写経してるとこういう事もあるよね!
次回は、収集した tweets を sinatra で表示するところをやります。
以上!

カテゴリー: 技術書つまみ食い | 1件のコメント

[技術書つまみ食い] 『MongoDB イン・アクション』第二回

[技術書つまみ食い] 『MongoDB イン・アクション』第一回 の続きです。

2章 JavaScript シェルから使う MongoDB

環境

こっからハンズオンでガリガリやっていくわけですが、わしの環境を紹介しておきます。
OS: MacOS X 10.8.2
MongoDB: v2.2.2
こんだけ。MongoDBv2.2.2 を落としてきて、解凍して起動しただけです。

cd mongodb-osx-x86_64-2.2.2/bin
./mongod --dbpath=/Users/yancya/data/db/

CRUD 操作

いわゆる CRUD 操作をガリガリやっていきます。
シェルの起動は簡単

./mongo

だけ!
次にデータベースへの接続。tutorial という名前のデータベースへ接続します。
そんなデータベース作った覚えがない?問題ない!無くても繋がるw 実体は最初に insert するときに勝手に作られる。

> use tutorial

[Create]

> db.users.insert({username: "yancya"})

[Read] 挿入したレコードに _id という名前でハッシュが付与されているのが分かります。これがプライマリキーです。

> db.users.find()
> db.users.find({username: "yancya"})
> #=> { "_id" : ObjectId("50e5a5cf87d9241065406c71"), "username" : "yancya" }

[Update] 条件と更新内容を喰わせます。単なる set 意外にも unset とかイロイロあります。

> db.users.update({username: "yancya"}, {$set: {city: "adachi-ku"}})

[Delete] 条件がなければ全件消去します。

> db.users.remove({username: "yancya"})

[Create or Update] _id が無ければ insert、あれば update します。

> db.users.save({username: "yancya"})

インデックス

インデックスは昇順(1)降順(ー1)で指定できる。ネストの奥にも指定できたりする。

> db.users.ensureIndex({username: 1})
> db.users.ensureIndex({address.town: -1})

おまけ

insert, find, update, remove, save らは function なので、() を抜いて実行してみると実装が画面に表示されてきて楽しいよ。javascript のソースがそのまんま出てくる。

とりあえずまとめ

わりと簡単に使えて楽しいね!

> db.users.count({"address.town":"aoi"})

とかもある。
適切にインデックスつけていけば、集計とかもガリガリできそうだし、大変興味深いですね。
次回、3章は MongoDB を使ったプログラムの作成です。Ruby のドライバで接続してイロイロやりましょう。20ページくらいだけど、今回カツカツだったので、2回に分けたりするかも。
以上!

カテゴリー: 技術書つまみ食い | 1件のコメント

[技術書つまみ食い] 『MongoDB イン・アクション』第一回

この本は一体?

先日パラっと読んだ『NoSQL データベース ファーストガイド』に出てきた MongoDB について、手取り足取り教えてくれる本です。立ち読みしたら、Ruby と javascript を使って説明していきますって書いてあったので、うひょーって思って買っちゃいました。NoSQL の中でも、わしの手の届く範囲内で一番役に立ちそうなのはドキュメント指向の奴だと感じたので、とりあえず代表的な MongoDB に入門してみて、手応えを感じようという趣旨で読みます。

1章

ドキュメント指向DBとは

ザックリ言うと、ハッシュマップにユニークなID付けて、そのまま保存しちまえっていう発想のDBなのでしょう。非正規化側に振り切った考え方ですね。BSON っていう独自のバイナリ形式で保存するようです。

検索とかどうすんの

単なるハッシュマップの集合を保存していますってだけだと、検索とか集計とか困るんじゃないの?極端な話、ファイルとして積んでおいて grep とか awk でゴリゴリ処理するのと何が違うの?っていう疑問に対してはセカンダリインデックスという考え方で対応するようです。B-tree インデックスなのでDBげです。ココ大事だから7章でガッツリやるぜ。

レプリケーション

レプリカセットって単位を3ノードくらいで組む。1つがマスターあとはセカンダリ。マスター転けたらセカンダリがマスターに昇格、マスターだったノードが戻ってきたらセカンダリとして参加。みたいな事を自動でサクッとやれるっぽいっす。

スケーリング

自動シャーディングにより、複数のノードに自動的にデータを分散配置する仕組みでサーバー増やしまくれるぜいぇーい!

コマンドシェル

いわゆるDBコンソールは javascript ベース!SQL は使わないけど、なじみの言語だろうからいいよね!

ドライバ

だいたいある!

ユーティリティ

dump, restore, export, import は普通にある。sniff(経路監視), stat(ポーリング)なんかもある。

制約とか

ジャーナリングするとはいえ、ベースはオンメモリーだから、メモリー沢山積んでるマシンじゃないと実用的じゃないよ。要するに 64bit OS にしとけってこと。

とりあえずまとめ

大体分かったから、とりあえず CRUD とかさせてくれ。な。2章でそれをやるらしい。16ページくらいしかないから明日やるわ。
以上、「読む+このエントリ書く」まで2ポモドーロ也。寝る!

カテゴリー: 技術書つまみ食い | 1件のコメント

DevLove2012 に参加してきたっす

はじめに

12月15日、16日と、DevLove2012 に参加してきました。各セッションでメモを取った中から、特に印象に残った事をサクっと列挙しておきます。1週間経って揮発しそうだから、急いで書かなきゃいかん。

1日目

1-1 『周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』中村洋さん

「ええと思ったら、やっていこう」というメッセージを実体験を交えて話して下さいました。某海岸沿いSIerとは・・・

1-2 『Social Change 〜ソフトウェア開発者が経営者になるまでと、これからの戦略〜』 倉貫義人さん

「製造業からサービス業へ」「フレームワークをRoRに統一し、ノウハウを共通化したのは経営判断」そして、某海岸沿いSIerとは・・・

1-3 『エンジニアの未来』 まつもとゆきひろさん

「なんだかんだ言って、楽天の社内公用語英語化は成功していると言っていい。何を言われても自分を信じて突き抜ける奴は強いね」

1-4-1 『スーパーはカーになりたかったITドカタとコミュニティ、そしてマサカリ』 瀬宮新さん

ソースコードを公開してモヒカン達からマサカリを食らったら、それに対して素直に取り組めばレベルアップ出来ますよというお話。ベジータ「今すぐオレを半殺しにしろっ」そういう事ですね。

1-4-2 『STNの向こうの世界線を目指せ』 伊藤宏幸さん

「今そこにある思考停止」に警鐘を鳴らす内容。涙無くしては聞けないお話でした。STN(そんなの ただしく ない)とは、少しでも教科書から外れた者を権威や形式にとらわれて脊髄反射で叩いてしまうというような事。正しさ至上の場によって傷つけられ倒れてゆく者の事を考えて!チームワークを大事にしましょう!という、魂の叫びを聞き、感動しました。

1-5 『どうしたら良いシステムが作れるのか〜あなたが進むべき道を決めるためのアーキテクチャとマネジメントの話〜』 鈴木雄介さん

リーダーの素養を持つアーキテクトげなマネージャーが、これから求められるのではないか。「アジャイル=組織論」

1-6 『SIerとWeb系はココが違う!キャリアチェンジしたエンジニアが見た両者の現場から』 高井直人さん

酔っ払ってて面白かったです!「高井さん=スゲー頭が良い!」「後工程はお客様」←これの意味がわかりませんでした。一番伝えたいことだったみたいなんですがw

1-7 『どこでも生きていけるエンジニアを目指した後に見えるもの』 増井雄一郎さん

MobiRuby の作者の増井さん。風呂でもコーディングしちゃう風呂グラマー。「気になった技術を深く、半歩先へ行くように習得してゆくべし」「好きなことだけやろうとすると、どんどんニッチになっていくので、市場の広い海外へ行かざるを得ない」

1-渾身会

非常に面白かったです。酔っ払った人達によるLTなんかもあって。中でも Atlassian JP の中の人が大変面白かったです。「Atlassian 超いい!」あと、協賛のオライリーさんからのプレゼント「ソフトウェアアーキテクトが知るべき97のこと」を頂きました。ぼちぼち読んでます。

2日目

2-2 『テストに開発をもっと駆動させたい』 諸橋恭介さん

「テストの目的として、それが正しいからとか、品質が上がるからというのはちょっと強すぎる。開発しやすくするためというのがしっくりきます」「どう動くかをテストするのではなく、何がしたかったかという事をテストすると考える」「素振り重要」

2-3 『「ドメイン駆動設計」という仕事の流儀』 増田亨さん

「利用者の気持ちになって、そのドメインの言葉で『しゃべる』ことから始めよう」「たくさん本読め!」「原則・パターンとの付き合い方は、それらを北極星として使う事だ。今、自分がどの辺にいるのかを確認するために使う」

2-4-1 『不惑の生存戦略』 塩谷啓さん

「生存の定義は職を維持する事と意に沿わぬ仕事をしないこと。意に沿わぬ仕事を強いられる事は死」

2-4-2 『プロフェッショナル 語源の理解』 上田佳典さん

なんか、ずっと 猪木 でした。

2-5 『リーダブルコードを読んだ後』 須藤功平さん

Ruby コードの感想戦【第1回】WikiRに取り組みました。「まず、コードを読んで、読む人に気持ちになりましょう。その気持ちで書いてみましょう」

2-6 『勉強会コミュニティがぼくのエンジニア人生にもたらした事。あと、NoSQLとの付き合い方。』 桑野章弘さん

「これからの勉強会はカジュアルにいつでも、どこでも、だれでも開催できるようになればいい」「勉強会を立ち上げるときには思い切ってゲストを呼ぶとイイよ。みんないい人だから来てくれるよ」「お客様の先にイイ事あるよ」

2-クロージングセッション 『Can we change the world?』 市谷聡啓さん

「稲作は生涯に多くても60回くらいしか出来ないってね」」そして、某海岸沿いSIerとは・・・

まとめ

情熱あふれる沢山のエンジニアから、元気を貰いました。わしも仕事がんばろうっと。(小並感)

カテゴリー: イベント | コメントする

[技術書つまみ食い] 『NoSQL データベース ファーストガイド』第一回

この本は一体?

2011 年 5 月 1 日の発売日に買って、ペラペラっと見て本棚の肥やしになってた。
200ページ弱で、字も大きいので、本気で取り組めば半日くらいで読み終わりそう。しかし、そこまでガッツリ取り組むほどの内容ではない。
なんで今更読もうと思ったかというと、先日「全文検索エンジンgroongaを囲む夕べ 3」というイベントの Ust を見て、「RDB じゃないデータストアって、かなりカジュアルに活用されるようになったなー。ナウいなー」とか思ったからでした。

Chapter 1

NoSQL と言っても、「No! SQL!」とか、そう言うんじゃなくて「Not only SQL」ですんで。
RDB(リレーショナルデータベース)の理論は 1969 年に提唱されたが、ハードウェア性能が足りて無くて実現出来なかった。
しばらくの間は階層型データベース(ディレクトリ構造みたいなあれ)、ネットワーク型データベース(重複を潰した階層型?)が主流でした。
その後、近年のハードウェアの進化で RDB が実用的なパフォーマンスで登場したようです。

RDB の強み

  • データの一貫性
  • 正規化
  • SQL
  • 実績やノウハウ

RDB の弱み

  • 大量データの書き込み
  • インデックス付きのテーブルへの更新
  • スキーマ変更
  • 即応性

じゃ、NoSQL はどうなん

とりあえず key, value みたいな単純な構造のデータを超大量に書き込むのが得意だね。
あと、単純だからこそ、ぶつ切りにして複数のサーバーに分散させて読み書きする事が出来たりする。
ぶつ切りに出来るってことは、サーバーを増やすだけで簡単にスケールアウトできるって事。これは有利ですね。
まぁ、キャッシュとかログとかに使うのが良いんじゃないかな。

NoSQL ってどんなのがあんの?

揮発性key-valueストア:memcached, (Redis)
要するにメモリー上に key, value のセットを置いて、高速にアクセスするよって事。
DB が落ちたらデータも消える。

永続性key-valueストア:Tokyo Tyrand, Flare, ROMA, (Redis)
ディスク上に key, value のセットを置いて、高速にアクセスするよって事。
DB が落ちても、再起動したらデータは残ってるよ。

ドキュメント指向データベース:MongoDB, CouchDB
スキーマレスが特徴。JSON とかみたいに、データ構造ごと保存して使う感じかね。

列指向データベース:Cassandra, HBase, HyperTable
特定のカラムだけを大量に取得したり、一括更新したりするのが得意なデータベース。
単一カラムだけ見れば key-value げなので、key-value と同じく、大量データの読み書きが得意っぽい。

ってな具合に分類出来るよ。

NoSQL はどういうときに使える?

基本的には RDB が何でも出来ちゃうから、出番は無い。
でも、とにかく速度、とか、とにかくスケーラビリティっていうようなケースが出てきたら、RDB を補完するために呼んであげてね。

とりあえずまとめ

RDB がデータのストックに向いているとすれば、NoSQL はフローの扱いに向いている感じなんでしょうね。
Chapter 2 からは実際に memcached やら Tokyo Tyrant、Redis, MongoDB, MySQL+HandlerSocket の実演です。
MySQL+HandlerSocket とかはちょっと面白そうな感じがする。
まぁ、次回がいつになるかは知りませんけれども。

カテゴリー: 技術書つまみ食い | 1件のコメント

SyntaxHighlighter Evolved のテスト

とりあえずこれでいいが、Qiita みたいに Markdown で記述できるプラグインを探した方が良いかもしれんなぁ。ナウいし。

css

div#header {
    border: medium solid #ddd;
}

ruby

(1..10).each {|n|
  puts n
}

JavaScript

var a = "hoge";
alert( a );
カテゴリー: Blog | コメントする

[技術書つまみ食い] 『プロになるための JavaScript 入門』第一回

まさかの表紙買い

表紙が美しかったので、パラっと立ち読みしたら結構面白そうだったので買ってしまった。適当に内容をメモ。

第一章

歴史

「JavaScript とはなんぞや」
「ECMAScript の各実装のうちの一つ」

  • Mozilla 系の実装 = JavaScript
  • Microsoft 系の実装 = JScript
  • Adobe 系の実装 = ActionScript

Java アプレットへのカウンターとして産まれました。Java って名前付けたら流行っちゃったw
IE の JScript がやりたい放題な実装だったから互換性もへったくれも無くて大変だった。
標準化団体を作って収束を図ったら、なんとか軌道に乗ってきた。
ES3 ならだいたいどんなブラウザでも動く。
ES5 は、いわゆるモダンブラウザならだいたい動く。
いい加減、ES5 = JavaScript と言っても良い時代が目の前にあると言っていいだろう。

特徴

var hoge とか言って、型付け無しで宣言するからよろしくな!動的型付けでっす!
インタプリタ言語です!コード書いたら、そのままブラウザで実行できたり、V8 で単独実行出来たりするからよろしく!
関数は第1級オブジェクトだからよろしく!クロージャ的なアレですね!静的スコープとか流行ですよね。
もちろん、オブジェクト指向言語です!あ、でも「継承・ポリモーフィズム・カプセル化」とかは無いし、Ruby みたいに全部が全部オブジェクトってわけじゃないよ。プロトタイプベースって奴でさぁ。
オブジェクト指向の3原色ってのがありまして「メッセージ色」「クラス色」「インスタンス色」って具合です。それぞれの濃さで、その言語のオブジェクト指向の色が決まっていくのではないでしょうか?
JavaScript はっていうと、クラス色とインスタンス色の間くらいにいるイメージですね。

写経環境について

おまえ、Chrome 使ってんの?
「コマンド+オプション+J」押してみ?
はい!環境出来た!すぐ写経を始めろ!

とりあえずまとめ

この本、普通の厚さなんだけど、薄い紙を使ってて 460 ページ以上ある。
Twitter とか Blog で見慣れた文体で書いてあるので、非常に読みやすい。
“JavaScript 文法の学習とは「A だと思った?残念!B でした」ということを何度も確認していく作業にほかなりません。” だそうです。
気が向いたら2章に手を出すかもしれないし、いきなり3章に飛ぶかもしれない。つまみ食いなので気まぐれに。

カテゴリー: 技術書つまみ食い | コメントする

子どもの写真、動画をいかに保存するか

この記事は子育てエンジニア advent calendar 2012 : ATNDの 12/5 のエントリです。

はじめに

掲題の通り、子どもの写真、動画をいかに保存するかについて書きます。

子どもが産まれると、やたらめったら撮影する親がいますね。私もそのひとりです。
あ、親ばかエントリなので、写真を貼っておきますね。

ディズニーランド

ディズニーランドでろくろ(息子)

運動会

運動会(娘)

データ量について

うちにある撮影機材は下記の通りです。

  • コンデジ(PowerShot G9)
  • ハンディカム(CX-12)
  • ミラーレス一眼(NEX-7)

コンデジの写真は1枚につき14〜15MBくらいのサイズです。あまり連写がききませんので、データ量はたいしたことありません。ハンディカムは8GBのメモリースティックに100分くらい撮影できます。動画を撮影したいシチュエーションは運動会やお遊戯会などのイベントに限られ、1回の撮影はせいぜい20〜30分程度なので、これもデータ量はたいしたことがありません。
一方、ミラーレス一眼はアブナイです。写真1枚につき23〜24MBくらいのサイズで、1回に11連写くらい出来ます。ディズニーランドや運動会などの1日がかりのイベントで撮影していると、2,000〜3,000枚くらい撮ってしまい、64GBのSDカードが1日で埋まってしまいます。これがフルサイズの一眼レフだったりしたら、もっと大変なんでしょうね。

現在、写真ライブラリのサイズは400GBくらいです。2TBの外付けHDDに保存しているので、容量については、まだまだ余裕があります。しかし、本当に問題なのは容量ではありません。

データ保全について

子どもの写真ライブラリはかけがえのないものですので、絶対に失わないように保全したいものです。

HDD

外付けHDDだけに保存するのでは、機器としての冗長性もなければバックアップも無い状態なので不安です。RAID1 で冗長化するとか、ファイルサーバーと同期するなどの対策を行いたいところですが、結構お金がかかってしまうので、なかなか実現できません。

Flickr

ファイルサーバーを導入する代わりに、私は Flickr の Pro Account を契約しました。2年間で$48でした。これで写真をフルサイズのまま無制限にアップロードすることが出来ますので、万が一、手元のHDDがクラッシュしたとしても、全件ダウンロードすれば復帰できることになります。このように家の外に保存することで、地理的な冗長性を実現することができます。ただし、クラウドといえども事故が無いわけではないですし、いつ、どんな理由でアクセス出来なくなるか分かりませんから、全幅の信頼を寄せることは出来ません。一応のバックアップとしての位置づけです。

BD-R

先日、BD-R へ書き込みが出来る外付けドライブを購入しました。イマドキの Blu-ray は2層で50GBもの容量を持っており、バックアップメディアとして、ある程度は使い物になるように思います。そろそろ普及してきた感がありますので、これからどんどんメディアが安くなってくれる事を期待しています。
ただ、不安が無いわけではありません。今まで CD-R や DVD-R を使ったバックアップというのは多少やっていましたので、先日、試しに12年程前の CD-R を開いてみたところ、すでに読み込めなくなっていました。BD-R はもう少し堅牢なのではないかなと期待しているものの、光学メディアに対する不安は払拭できません。バックアップに作成したディスクについて、1〜2年に一回は点検を行うとか、全量焼き直すとかしたほうが良いのかもしれません。

全部残す事に意味はあるのか

ここまで書いておいてなんですが、こういったデータ保全への意欲は、程々になるように抑制したいと考えています。何千、何万、将来的には何十万、何百万もの写真を、動画を、いつ、誰が見るのでしょうか。そういう巨大なデータについては、適当にお蔵入りしてしまえばいいのです。
その代わり、気に入った写真や動画についてはいつでも見られるように整理しておくことが大事だと思います。

Facebook

2,000〜3,000枚も撮影すると、10枚くらいは良く撮れている写真が混ざっているものです。そういう出来の良い写真は Facebook のアルバムにまとめて友達限定で公開しています。生き馬の目を抜く Facebook においては、そういう武器を持たねば生き抜くことが出来ないのです(暗黒微笑)。と、冗談は別として、Facebook のアルバム機能は結構よく出来ていて、見やすいと思います。

Facebookアルバム

Facebookアルバム

やっぱりプリント

かみさんはパソコンで写真ライブラリを見るたびに「出来の良い奴だけプリントしてアルバムを作りたい」と言っています。やっぱり最後はそこに落ち着くのでしょうか。古い写真なども、アルバムは残っているけれどもネガは紛失しているというケースが多い気がします。これから年に1冊くらいは作っていこうと思います。

さいごに

もっと良いデータ管理の方法などがあれば、お教え頂けるとうれしいです。
最後までご覧いただき、ありがとうございました。

カテゴリー: 育児 | コメントする