2011年07月02日
最近のデザイン改変に思うこと
最近、いろんなモノのデザイン改変が気になります。
昨年あたりから、いろんな企業が有名なデザインを新しくしているので、
いろんな想像をめぐらせてみて、自分勝手ではありますが、感想を書いてみようと思います。
ピックアップするのは次の５つ。
綾鷹
数々のマイナーチェンジを経て、
３月に、現在（右側）のデザインに落ち着いたようです。
現在のデザインでは、フロントにお急須のイラスト。
以前前面にあった、シブい家紋みたいなロゴマークは、ペットボトルのふたに移動しています。
このデザインの意味は、
「このペットボトルのお茶は、他のと比べて一番急須で入れたお茶に近いです」
ということのようです。
現在の綾鷹オフィシャルに書いてある通りです。
「これまでのペットボトル入りお茶にはない、
急須で入れた緑茶のような本格的な味わいを目指して」（以下略）
綾鷹のデザインの変遷は、
ブランドコンセプトの変容と関係が深いと想像しています。
最初は、「上林春松本店さまの奥深い歴史的味わい」を
売りにしようと考えたのでしょう。
そのため、”シブい家紋的マーク”が全面に出ていたのですね。
「上林春松本店さまと共同開発できちゃうなんてオレたちすごい！」
みたいな感じで。
それが次第に、
↓
「でもさ…歴史的味わいっていうより、お急須でいれる、あったかいお茶って感じだよね」
「“ペットボトルなのに急須でいれたお茶の味”ってほうがスゴイんじゃない？」
↓
「そっちのほうが売れるかもね！」
「美味しいのがいちばんだもんね！」
そして、現在の（ちょっとチープな）急須のイラストになったのでしょう。たぶん。
気になるのは…
- 「綾鷹」という名前が急須のイラストとマッチしてない（初期のイメージのまんま）
- 急須のイラストがチープ
- ペットボトルの形が寸胴（たくさん入ってるほうが良いけど）
- 家紋のほうがカッコイイ
綾鷹おいしい。です。
それにしてもコンセプトの変化を
こんなにクルクルとデザインに反映できるなんて、すごいなぁ。
ちふれ
平成19年の創業60周年、平成20年のちふれ化粧品誕生40周年を迎え、
“そっと”パッケージデザイン（と企業イメージ）を変えたちふれ。
（↑わかりにくいですが、左側が新しいほうです）
（↑右側が新しいほうです。逆になっちゃってすいません）
その変化に、好感を抱いたのはあたしだけではないはず。
気になるところ
- パッケージのフォントや、字の大きさ・太さが変わり、読みやすくなった。
- “こっそり”、“そっと”デザインを変えたところが、控えめなブランドイメージに合っている。
- 「基本的なところは何も変えない」をパッケージにも貫いている。
- 変化によって、利用者をびっくりさせない。
- 広告費やデザイン費を感じさせない。
「約40年前、100円化粧品からスタートしたちふれ化粧品の姿勢は今も変わりありません。」
というちふれ（ちふれ化粧品について ｜ ちふれ化粧品の約束 : ちふれ化粧品）。
“変わらない”の良さも大事なんだなぁと、ちょっと感動させられます。
社長が男性で、ＣＭに出てきた時はびっくりしたけど。
明治
これも去年の話ですが、
ずーっと親しまれた巨匠作のロゴが変更されました。
賛否両論あるようですが、
結果的に売上が上がったらしいですから、
やはりプロのお仕事ですよね。
「ふくよかで柔らかな書体、親しみのある小文字を使用することによって、
「食と健康」の企業グループらしい明るさと、お客様一人ひとりとの
あたたかいつながりを表現しました」
とあります。
（ブランドマーク・スローガン｜明治について｜企業情報｜株式会社 明治）
う〜ん。
でも気になるなぁ。
- バランスが悪い気がする。
- 特に、字の間隔…かなぁ。
- 変更に伴って、パッケージの他の字体（chocolateなど）が迷走してる気がする。
- チョコレートってそんなに子供向けなものじゃないよね…？ 板チョコだけかな…。
ムヒ
もっと気になるのはこの変更。
明治と酷似している。
実は明治より先に変更していたのに、
気づかれたのは明治より後…（ＣＭが後だったんだな）。
無印良品のロゴに似てるって意見もあるようで。
「ムヒ ロゴ」で画像検索すると、明治のロゴが同じ数ヒットするこの現実。
以下のブログがすごく詳しくて、
ご意見にも賛成…。
このブログのコメントにあった、
「ボクの予想では、ムヒの社長が明治みたいなロゴにしてくれって発注したんじゃないかなと思う」
という意見に、
あたしの苦い思い出が反芻されて悲しいのであります。
変更の経緯からして、さすがにそうではないと思うけど…。
ロゴの意味。
いつか…、書いてみたいです。
上部のツールバーが黒くなったのをはじめ、
プラス1機能の追加も（これはデザインじゃないか）。
特にカレンダーの変更には少々の驚き。
変わったとこは…
- 角丸をやめて、枠線を消したことで、表示範囲が広がった。
- 画像リンクでなくテキストリンクになった部分が使いやすい。
- なんか動かないこともあったスクリプト部分がちゃんと動く。
- 以前のデザインも、変わらず使うことができる。
流行を取り入れたって部分も大きな変化です。
Webデザインの流行は、刻々と変わり続けていて、
2.0の頃は、つるっとした、ピカピカなボタンと、リッチ（っぽい）UIが流行ってましたよね。
CSS3.0が出た当初から、角丸が流行っていて（twitterなど）。
そして今回、googleは、フラットでペラペラなデザインになりました。
より強く、シンプルさが追求されるようになってきた感じです。
デザインの好みとか流行どうこうよりも、
「みんながWebを使う時代、誰でもWebを楽しむ時代」を反映している気がします。
もっとマーケットを広げる必要がありますし。。。
長々と私見を書きましたが、、
公式の「Google カレンダーのデザインの変更 - Google カレンダー ヘルプ」は必読です。
誰でも使う汎用的なツールだからこそ、この変更に関しては、もうなんだかものすごく難しいこといっぱい考えてるんだろうなぁ。
次はSQLの続きを更新しなくっちゃ。
2011年05月04日
vimtutorの一部始終（画面キャプチャで）
vimtutorやったよ！（Lv.1）
mac air を手に入れてから、早くも３週間が経過いたしました。
先日とある勉強会に行った際、macならviでしょみたいな雰囲気にヤラれ、試しにvimtutorやったので記録します。
vimtutorのはじめかた
- ターミナル.app を立ち上げる
- vimtutor と入力する
これだけです。
vimtutor一部始終
- ようこそ
- 1
- 1.1 : カーソルの移動
- 1.2 : VIMの起動と終了
- 1.3 : テキスト編集-削除
- 1.4 : テキスト編集-挿入
- 1.5 : テキスト編集-追加
- 1.6 : ファイルの編集
- 1... : 要約
- 2
- 2.1 : 削除コマンド
- 2.2 : その他の削除コマンド
- 2.3 : オペレータとモーション
- 2.4 : モーションにカウントを使用する
- 2.5 : より多くを削除するためにカウントを使用する
- 2.6 : 行の操作
- 2.7 : やり直しコマンド
- 2... : 要約
- 3
- 3.1 : 貼り付けコマンド
- 3.2 : 置き換えコマンド
- 3.3 : 変更コマンド
- 3.4 : c を使用したその他の変更
- 3... : 要約
- 4
- 4.1 : 位置とファイルの情報
- 4.2 : 検索コマンド
- 4.3 : 対応する括弧を検索
- 4.4 : 間違いを変更する方法
- 4... : 要約
- 5
- 5.1 : 外部コマンドを実行する方法
- 5.2 : その他のファイルへ書き込み
- 5.3 : 選択した書き込み
- 5.4 : ファイルの取込と合併
- 5... : 要約
- 6
- 6.1 : オープンコマンド
- 6.2 : 追加コマンド
- 6.3 : その他の置換方法
- 6.4 : テキストのコピーとペースト
- 6.5 : オプションの設定
- 6... : 要約
- 7
- 7.1 : オンラインヘルプコマンド
- 7.2 : 起動スクリプトの作成
- 7.3 : 補完
- おわり
ようこそ
ほうほう。
vimとかEmacsとか今更とか、やったことないあたしみたいな人間には。賛否両論まぶしいのです。とりあえず使えるようになりたいです。そんでなんかサササッとコーディングしたいじゃんかっこいいじゃん♪
2011年04月05日
なんとなく書いていたSQLとOracleを最適化する方法 （6/10）
久々の更新になってしまいました。
演算子を使用した場合でも索引を使用する！
使用するためのポイント箇条書き。
- 等価演算子(=)、比較演算子を使用した場合は、索引は使用できる
- NOT EQUAL(!=)の場合、索引は使用されない → ヒント句を使用するか、他の演算子の使用を検討する
- AND演算子で指定するいずれかの列に索引が存在する場合のみ使用される
- IS NULL演算子を指定した場合、Bツリー索引は使用されない
- IN演算子では使用されるが、NOT IN演算子では使用されない
- LIKE演算子は、索引列がCHAR型・VERCHAR2型で、条件が前方一致の場合、索引を最も効果的に使用できる。（中間・後方一致でも使用できるが、パフォーマンスが最適でない場合がある）
第７回へ続く…！
2011年02月28日
なんとなく書いていたSQLとOracleを最適化する方法 （5/10）
索引が何か理解できたら、ここからが本題です。
ちゃんと索引が使用されるSQLを書く方法があるんですね！この連載５〜７回目を通して、解説したいと思います。
索引を使用するSQLの記述
（１）索引列の演算・関数の記述ルール
基本ルール ）where句で索引を作成した列を変更した場合、索引は使用されない
基本対処 ）索引列ではない側を変更するようにする
× Select ENAME from EMP where SALALY * 1.1 > 950;
○ Select ENAME from EMP where SALALY > 950 / 1.1;
× to_char(HIREDATE, 'YYMMDD') = '110228';
○ HIREDATE = to_date('110228', 'YYMMDD');
EX.3 索引列で演算子を使っている（ || , % など）
（２）索引列の内部変換
基本ルール ）索引列に対して異なるデータ型の比較を行う場合、内部変換が発生して索引が使用されない。
基本対処１ ）比較する列が同じデータ型になるようSQLを変更する。
基本対処２ ）索引列ではない側が内部変換されるようにする。
× EMPNO = 7788
× to_number(EMPNO) = 7788
○ EMPNO = '7788'
次回（６回目）は演算子を使用した場合の細かい対処法を、
連載７回目はwhere句以外の句で索引を使用する方法をご紹介します。
2011年02月27日
なんとなく書いていたSQLとOracleを最適化する方法 （4/10）
やっと連載４回目のスタートです。
前回までで、現状のSQLの問題点を判別する方法は明らかになりました。いよいよ、SQLを最適化する具体的方法に移っていきます。といっても、「SQL最適化＝索引をちゃんと使う」という一点が主目的です。
というわけで今回のテーマは、「索引」です。
索引とは
索引とは、表のデータを検索するときのパフォーマンスを向上させるためのオブジェクトです。Oracleでは、B*ツリー・ビットマップなどの種類の索引が利用できます。また、表とは別のオブジェクトとして必要に応じて定義することができます。
わかりやすく書いておきますと、本で言う、目次のことですね。どこに何が書いてあるか、目次を探せばすぐにわかります。Oracleでは、必要な索引は、自分で列を抽出して作成することができ、表とは別のオブジェクトとして管理します。
索引を作成する目的は、特定のキー値が含まれる行へのポインタを提供することによって、DBへのアクセス高速化を図ることです。つまり、SQLチューニングは、効果的に索引を使用できるSQLを書くための手法がメインテーマなんですよね。
索引の特徴
- 表データからの独立 ： 表データから独立しているので、索引それ自体を一つのオブジェクトとして管理・使用できます。
- アプリケーションからの独立 ： 当然、DBを使用しているアプリケーションからも独立しています。アプリケーションからDBへ要求した処理のレスポンスが遅い時は、アプリケーションをいじることなく、インデックスを作成したりメンテナンスしたりすることができます。
- 自動メンテナンス ： 表データが変われば、インデックスもメンテナンスが必要です。Oracleでは、こういったメンテナンスは自動で行ってくれます（デフォルト）。ただし、索引の自動メンテナンスは、索引が無い場合のDML処理と比較して約３倍のリソースを消費するとのことです。
索引の種類
- Bツリー ： 一般的な索引です。ツリー構造で索引エントリにアクセスできるようにした索引です。
- ビットマップ索引 ： Enterprise Editionのみで利用できる索引です（こちらは解説では使用しません）。
索引を作るべき列とは
以下のような列には、単一列に個別に索引を作成することを検討します。
- where句で頻繁に使用されている列
- アクセスしたい行数が総行数の15%未満の列
- 結合を行うために使用されている列
- カーディナリティ（列値の一意性）が高い列
以下のような列には、複数列に索引を作成することを検討します（コンポジット索引/複合索引/連結索引）。
- where〜andで指定された各列のカーディナリティが低い
- 問合せでアクセスする列数が少ない
索引作成時に考慮すべきこと
索引作成には、リソースやメモリ、一時表領域が必要ですので留意すべきです。
索引を作成したけど、効果がでないよぅ〜
そんな時は…
索引のメンテナンス
４回目はここまでです。
次回からいよいよ、SQLの記述自体を検討していきますよ！
