7インチ超のAndroidタブレットが続々登場

何やら急に7インチ以上のAndroidタブレットがたくさん出て来たみたいで訳が分からなくなりそうだったので、リストにしておこう。
これから買うならやっぱりAndroid3.0搭載のものが良さそう。ちょっと見たところ、仕様的には Eee Pad MeMOとXOOMが一歩抜きん出ている模様。


ASUS 「Eee Pad MeMO」
ASUS、7インチタブレット「Eee Pad MeMO」を発表--携帯電話機能も搭載
Eee Pad MeMO タブレット発表、感圧スタイラス対応＆デュアルコアSnapdragon 採用
ASUS EPad: like the EeePad, but with less ecstasy
ASUS Eee Pad MeMo – 7-inch Android Tablet Announced [VIDEO]

MOTOROLA 「XOOM」
MOTOROLA-XOOM 製品情報
Motorola、Android 3.0（Honeycomb）搭載タブレット「Xoom」を発表。2011年第1四半期にリリース
iPadを追撃せよ！モトローラの新タブレットはAndroid3.0マシン

DELL 「Streak 7」
［CES2011］Dell、7インチAndroidタブレット端末「Streak 7」を発表

Samsung 「GALAXY Tab」
Samsung、7インチのAndroidタブレット「GALAXY Tab」発表
Samsung Galaxy Tab 製品情報

AU (Samsung) 「SMT-i9100」
iPadの牙城を崩せるか！？auも7インチAndroidタブレット「SMT-i9100」を発表

NEC 「LifeTouch」
7インチはちょうどいい？NECのAndroidタブレット(LifeTouch)
NECビッグローブが7インチAndroidタブレット『Smartia』を12月6日に発売へ

Camangi 「FM600」
3G通信対応、7インチ液晶のAndroid搭載タブレット端末 (Camangi FM600)
Camangi製品情報


その他にもマイナーなメーカーからもたくさん出ているみたい。
パナソニックも「ビエラタブレット」なるものを開発中とか。

いずれにせよ今年のタブレット市場は楽しくなりそうだ。


---
2/15 追記
これは文章入力には良さそう。ATOKとキーボードでのコピー&ペーストは魅力的。
ATOKも“Ctrl＋c”も使えるキーボード付きAndroidポケットノート












.

Waveとは何か （pamela fox's blog - Why I Love(d) Wave より）

GoogleのPamela FoxさんがWaveについてブログに書いている。

http://blog.pamelafox.org/2010/12/why-i-loved-wave.html

読んでみて、今まで自分はWaveについてちゃんと理解していなかったんだなぁと思った。Waveの本質ってなんだろうか。

Wave is a flexible and generic platform, one that can be used for groups discussion, for diary entries, for event commentary, for surveys. Of course, there are existing solutions for doing each of those things - but there is not one solution that does all of them.

Waveは柔軟で汎用的なプラットフォームで、グループの掲示板、日記帳、イベントの感想ノート、アンケートなどが出来るの。もちろん、これらの事が出来る個別のソリューションはこれまでにもあったけど、全部の事が出来る単一のソリューションと言うものは存在しなかったわ。

The thing I loved about Wave is that I could start a wave about a topic, and that wave could evolve from a survey to a discussion to a photo album (like when I asked folks what color I should dye my hair next), or be a combination of all three at once. I didn't have to know at the beginning what it would be, I didn't have to carefully weigh all the different options, I could just start a wave and see what it became.

私がWaveを好きなのは、ひとつのトピックを開始したら、それが徐々に単なる質問からディスカッションに変わったり、さらに写真アルバムになったり（私が髪の色をどうしようかってみんなに尋ねた時みたいにね）、それら全部の組み合わせに発展したりするからなの。最初から「どんな風にしようか」って考えたり注意深く別の選択肢を検討したりしないと行けない訳じゃなくって、単にwaveを作ってそれがどうなって行くか見ればいいのよ。

Sure, you can do event planning with just text, but throw in a date picker gadget, RSVP gadgets and maps, and you've made planning that much more compelling. You can write your blog post drafts with just the native features of Wave, but after you throw in an approval gadget and blog post publishing robot, you've got a full blog post workflow in Wave, one that can be easily shared with your colleagues.

例えばイベントの企画を単に文章だけでする事も出来るけど、日付選択用のガジェットを貼りつけたり、RSVP用のガジェットや地図を付け加えたりすれば、それだけで企画がずっと魅力的なものになるでしょう。Waveのネイティブな機能だけを使ってブログの原稿を保存しておく事も出来るけど、投稿を承認する為のガジェットと実際にブログに投稿してくれるロボットを付け加れば、完全なブログ投稿システムが出来上がるわ。そしてそれを同僚達に使ってもらう事も簡単に出来るの。

なるほど、そう言う事だったのか。

- 内容のフォーマットが柔軟。
- 定型処理の自動化、システム化が出来る。
- 他人と簡単にシェア出来る。

という辺りがポイントになるのかな。

引用した部分に続いて、Waveを使って実現した2つの事例を紹介している。

- Google Waveのチーム内で、サーバーのサポート業務のシステム化をガジェットを組み合わせて行った例。
- 外部の開発者がWaveエクステンションをギャラリーに投稿してから一般公開されるまでのプロセスでのコミュニケーションをWaveで管理した例。


そして最後は、次の言葉で締めくくっている。

I hope that the ideas of Wave keep going, whether through other Google products or the ever-growing Wave open-source community, because I don't want to live in a world without them.

Googleの他の製品、あるいはどんどん大きくなって来つつあるオープンソースWaveのコミュニティを通してWaveの数々のアイデアが続いて行く事を願っています。だってそれらが無くなった世界でなんて生きたくないから。

Waveに対する愛情がひしひしと感じられる。
彼女の願う通り、Waveで培われたアイデアや技術はこれからも生かされて行くだろう。


追記：
早くもこんなのを作り始めている模様。
http://blog.pamelafox.org/2010/12/google-shared-spaces-why.html
http://blog.pamelafox.org/2010/12/google-shared-spaces-how.html

Waveのコードが25万行なのに対してShared Spacesはたったの5000行と言うのも面白い。







.

商品コードを主キーにするべきではない理由

リレーショナルデータベースのテーブルの主キーの設計については「ユニークになる項目だから必ず主キーにしないと行けない」というわけではなく、多くのDB設計者の間でも

- ID派（あえて別に自動採番のIDを付ける）
- コード派（ユニークになるものは出来るだけ主キーとする）

の2つに分かれる様だ。特に近年はRuby on Railsに代表される様に数値型の単一キーの存在を前提として作られているFrameworkが増えて来た事もあって、ID派の存在感が増しているらしい。

それぞれメリット・デメリットがあってどちらがいいのかはケースバイケースになるのかも知れないが、自分の場合はこれまでの業務システム開発の経験から、どちらかと言うと自動採番のIDを使う方がメリットが多いのではないかと思っている。やっぱりなんだかんだ言っても、「どうしてもこのマスターのコードを変えたいんだけど」と言われるケースが何度かあって、コードを主キーにしている場合に結構面倒な作業になってしまった事があるからだ。

ただ今回はあるプロジェクトにおいて「コード派」の技術者の方をやんわりと説得する必要があったので、「ID派」の根拠になりそうな情報を少し調べて見た。せっかくなので今回参考にさせてもらったサイトの引用とURLなどをまとめておこうと思う。

まずその前にひとつ思った事は、「主キーにする為にあえて付与したID」の事は「サロゲートキー（代理キー）」と言うよりも、「人工キー(Artificial Key)」と呼ぶ方がしっくり来る気がするという事だ。もちろん引用は原文のままにしておいた。

「サウスポーなSEの独り言 - テーブル設計」
テーブル設計上、どっちが良いか(…)ですが、私はお客様の要望が無ければサロゲートキーを採用します。
ナチュラルキーの代表的なものである顧客IDや社員番号、商品番号等は先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。そしてその決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。...

「ぼそっと - 人は何故PKに人工キーを用いるのか」
メリット
- 変更に強い
- 自然キーの場合、複合キーがめんどくさい
- 最近のデータベースアクセスソリューションもの(平たく言うと、広義の意味でのORM)と相性が良い
デメリット
- 関連が分かりづらい
- ベテランの技術者は自然キーに慣れている人が多く、なかなかコミットしてくれない
- 既存システムはまだまだ自然キーのものが多いので、他システム連携的なところとは相性が悪いことが多いくらいにしか思っておらず、ようするにビジネス的な変更がシステムに与える影響を小さくする、一種の粗結合的なものだと思うのですが、...

「@IT - システムの寿命はコードで決まる！」
業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。...

「Life goes on - 楽々ERDレッスンを読んでいます」
アプリ側の視点からすれば、業務コードを主キーに使うような下のような設計はもうありえないと思います。（...）主キーには業務上で一意に識別されているコードではなく、意味もないIDを使いましょうというのが今の主流だと思います。...

「Hot Heart, Cool Mind. - 主キーの設計①」
これはかなり以前からある論争で、大雑把にいうとコード派とID派という二つの立場の間で戦われている。
コード派 ...　ユーザの目に触れるデータ項目（典型的にはコード）を主キーとする。複合主キーを許す。
ID派 ...　ユーザの目に触れないデータ項目（自動生成したID）を主キーとする。複合主キーを許さない。...

「A.R.N [日記] - ID or not ID」
たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるような場合、いったいいくつ項目持てばいいのかわからないくらい項目が増える場合がある（まぁ大半は設計が悪いだけだったりするのだけど、ID派の立場を取ればそもそもそのような状況はおこらないことを考えれば欠点には違いない）。
個人的には、複合主キーだとマスタに履歴を持つようなケースで変な主キーを選択しなければならなかったり、主キーを更新せざるを得ない場合があって気持ち悪いので、ID派ではあるけど、絶対にIDじゃなければダメだということを説得できるだけの論点が見出せないのが実情。...

「DBFlute - サロゲートキーと複合主キー」
ナチュラルキーをPKにするということは、業務に直結していて実装上でも直感的でありながら、 直結しているがために業務の変更の影響をもろに食らうということにつながります。確かに変更が発生するのは仕方のないことではありますが、 その影響は最小限にしたいものです。そのためには、テーブル間の依存関係を薄くすることが重要です。
サロゲートキーを導入することで、テーブル間の依存度合いは減り、業務変更のインパクトも(何もしない状態よりは)少ないものになります。 複合主キーの場合の方が効果は顕著ですが、単一キーでも同じ話です。例えば、ExampleDB の商品テーブルは、単一のナチュラルキーである商品ハンドルコードでユニークですが、商品IDというサロゲートキーを利用しています。 商品ハンドルコードは、業務で利用する値であり、業務変更でコード値の構成変更が発生する可能性があると想定したものです。