SVGをプロジェクトで利用してわかったこと

SVGをプロジェクトで利用し始めてわかったこと。

ここ数ヶ月、やっとSVGを実際の案件で利用し始めて、様々なことを学びました。
ハマって時間を潰すこともあれば、便利だなと思うことも。
この記事では、いくつかの感想をまとめてみます。

デザインツールについて

SVGが作れるデザインツールも数多くあり、今ではphotoshopでも作れるほど。

Adobe illustlator
Adobe photoshop
sketch.app
Affinity Designer

…etc。
他にもあるとは思いますが、メジャーなもので上記の4つでしょうか。

上記で一番コーディングしやすいツールは Sketchです。一番綺麗なコードを出してくれると思います。
illustrator もまだ大丈夫ですが、結構余分な情報もエクスポートされます。
photoshop もエクスポートはできますが、シェイプであることが前提です。また、defs タグの中に style タグと CSSで色などが定義されたSVGファイルがダウンロードされるので、HTML内でclassが衝突し思わぬ事態が起こりやすいです。

今でもスタンダードなツールはadobe 製品です。
photoshopでも、SVG化が考えられる箇所についてはillustratortで作成し、外部ファイルとして埋め込むようにすることが大切です。

ブラウザ互換に苦労する

SVGは非常に複雑な仕様ですので、SVGを解析しレンダリングするブラウザでも、ちょっとした差やできることに違いがあり、結構苦労することがあります。
特にIE8対応がマストの場合(まぁなくなるとは思いますが)、SVGを利用する選択肢はできるだけ避けた方が吉かもしれません。

SVGを利用したアニメーションでも、IEでは transform-origin プロパティが効かなかったりします。*思い切って GSAP や Snap.svg といったライブラリを利用したほうが余計な手間がかからずすみます。
SMIL Animate は既に削除される仕様なので、今後は利用しないほうがいいでしょう。

ロード方法について

SVGは基本的にHTML内に直接埋め込まないと、CSSでのプロパティの操作や、JavaScript でのアニメーションを実装することはできません。
Jade では include を利用することでより便利になります。
もしくは、icomoon などでアイコンフォントに変換したほうが楽だと思います。

まとめ

SVGは既にプロジェクトで利用できますし、使いようによってはとても便利です。
しかし、便利さに目がくらんでしまうと、意外に痛い目にあってしまいます。
今回紹介したことだけではなく、プロジェクトの規模感や仕様に合わせ対策を練りましょう。

firefox の placeholder カスタマイズ注意点

Firefox で Placeholder をカスタマイズする時、
:-moz-placeholder ではなく ::-moz-placeholder を利用する

コーディングルール策定までの道のりその①

社内のコーディングルールをそろそろ決めなければ、、、

※ この記事はパブリックなメモです。

1 HTMLコーディング

HTMLバージョン

基本的にHTML5を使用する。

スペース

コードのインデントはスペース2つで表現する。

HTML タグの命名

必ず小文字で記述するものとする。

ID、Class の命名

IDについては、基本的には使用しないものとする。ただし、JavaScript によってなんらかの理由により使用せざる得ない場合は例外とする。

class の命名には、BEM 記法を採用する。

ページに依存する命名 ( .home-banner, .about-contents 等 ) は極力さけ、コンポーネント単位での設計を心がける。

画像の命名

画像の命名については、以下の通りとする。

接頭辞として、Block を利用する
次に、Element を指定する
最後に数字を付与する。10未満の場合は、接頭辞として0をつける。
各単語の接続詞としては、- (ハイフン)を利用する。

例

profile-text-01.jpg

profile-bg-01.png

テンプレートエンジンについて

特別な理由がない場合には Jade を採用する。なお、極力HTMLテンプレートエンジンを利用してマークアップすることを心がける。

2. CSS

ファイル命名

基本的に、メインとなるスタイルシートを記述するファイルは style.css と命名する。

ファイル分離について

CSSファイルは一つにまとめること。

@import によるCSSファイルの読み込みは

CSS設計を考えてみた

最近HTMLコーディングをすることが増えてきました。
レスポンシブWebデザイン(以下RWD) をする上で大切なことってやっぱりCSSの設計っすね。

何回かコーディングやって決めたことをメモします。

はじめに確認すること

プロジェクトの最初にやらなければならないのは、まずは把握することです。以下のこと必ず最初に確認しましょう。

対応ブラウザ

最近ではIEの対応もほとんどなくなりつつある気がします。あってもIE9まで。プログレッシブエンハンスメントでの対応。

命名規則

BEMを導入する。ページ名に依存した命名をせずに、コンポーネントごとの命名をすること。また、モジュール名で簡潔にイメージできる命名を心掛ける。

モジュールのリストアップ

デザインカンプをすべて確認し、どのようなコンポーネントが存在するかリストアップする。

HTMLコーディングルールの確認

.editorcofigなどのツールを利用して、個人の環境に左右されないことが大切。

コーディング時

コーディングする時に注意すべきこと。

Sass

導入するが、過度のネストは厳禁。コンパイル後のCSSを意識して書くこと。納品案件の場合、最後にはSassを切り捨てることもある。

IDでのスタイリングは極力避けること。

!important の利用は極力避けること。

メディアクエリーは、Sass 内に直接ネストして埋め込むこと。

・ファイル命名規則

ScssファイルはBEMで記述した一つのモジュールに、一つのファイルが対応するように命名。クラス名でファイルを開くことができるため、効率がいいと考える。

どんどんSassファイルを増やせるように、css-globbingの導入は必須。

姓名判断について考えてみた

最近忙しい忙しいばかり唱えている呪術師石原です。

実はプライベートで12月にパパになります。
子供ができるということは、父親になること。ダメパパになりそうですね。

子供が生まれる時に、絶対にしなければいけないのが名前決め。

我が家ではかれこれ数ヶ月名前を決めるために悩みに悩み、
残り2ヶ月の今でもさっぱり定まっていないのが現状なんです。

原因は、姓名判断。

僕は全く神様だとか、信仰だとかを気にしない人間で、もちろん占いの類もそう。
姓名判断もこれまで聞いたことはあったけれども、世の中でこんなに広まっているとは。
たいてい、周りの経験者方に聞いても8割ぐらいは参考になさったそうで。

これまで数え切れないぐらいDOMに命名してきた僕が提案しても、姓名判断で突っ込まれる。うーんどうしたものか。

大体、姓名判断ってなんなのと思い調べてみました。

姓名判断の歴史

実は、画数の考え方（日本式姓名判断）の歴史は80年ちょっとです。

姓名判断の歴史は80年ちょっと｜ことだま「名前」占い水蓮オフィシャルブログPowered by Ameba :

姓名判断の理論の基礎的内容は熊﨑健翁によって広く世に広められ、熊﨑が姓名判断の源流と広く認知されているが、熊﨑は姓名判断の理論を開発したのではなく、明治時代の易者・林文嶺と言語学者・永杜鷹堂が理論化したものを大衆向けによりシンプルにしたものが熊﨑の姓名学である。

姓名判断 – Wikipedia

どうやら、現在広く使われている姓名判断って熊崎健翁という方が昭和に入って発表した「熊崎式姓名判断」というものを元にしているようで。

はは、一つ根拠をつかんだ

よくある姓名判断サイトについて

複数の姓名判断サイトをみたところ、画数から

・天格 : 苗字の画数
・外格 : 苗字の一文字目と名前の最後の文字の画数
・人格 : 苗字の最後の文字と名前の最初の文字の画数
・地格 : 名前の画数
・総格 : 苗字と名前を合わせた画数

を計算し、各格の画数に応じてあらかじめメッセージを用意し結果を出力する。

中には、

var TenChiGai = RndVal(Math.pow(Ten * Chi * Gai, (1.0 / 3.0)) * 30.0, 10);

みたいな形で格を計算し、メッセージを出すようなものを。いくら流派によって判断が変わるとはいえ、こんな算出方法本当にあんのかいな。

結論

画数調べるって言って、上記のようなサイトで調べてるので、そこを丁寧に説明。
あわよくば自分で作って、自分がつけたい名前の結果を満点にして、ばれないように嫁さんに知らせよう。

– – –

補足

面白い Github のリポジトリ見つけた。

暮らしの姓名判断
https://github.com/MasakatsuNakamura/seimei-kurashi
0 forks.
0 open issues.
Recent commits:

composer.lock, ma-nakamura
'test', ma-nakamura
'test', ma-nakamura
あじあ姓名うらないに集約, ma-nakamura
README修正, Masakatsu Nakamura

Sketch 3 の魅力

どうも。@1shiharaTです。
今度「Sketch 3 勉強会 in NAGOYA」を開くついでに集客がうまくいっていない(汗) ので記事を欠かさせていただきます。

Sketch の魅力

Sketch 3 は、Bohemian Coding 社が開発・販売している Mac 用のベクタードローイングソフトです。

ベクタードローイングソフトといえば思いつくのは、米 Adobe 社が開発・販売している Illustrator
もしくは Inkscape などが頭に浮かぶかも知れません。

Sketch はベクタードローイングソフトという名を冠しながら、
ピクセルを前提にしているという不思議なソフトです。

「新規開発が事実上中止となっている Adobe Fireworks の後継ソフト」

というキャッチコピーを良く聞くかもしれませんが、
実際に使っている身としては、その機能・操作性を大きく凌駕しているのではないかと感じています。

そこで Sketch の魅力について、幾つか上げていこうと思います。

1. 軽い。Mac に特化している。

Adobe 製品を使っていると感じる、重いという感覚。
誰しもその胸にしまいながら、仕方なく使用しているという方も多いのではないでしょうか？

Sketch はとにかく軽いです。さくさく軽快に動きます。

起動・操作のレスポンス供に Adobe 製品とは比べ物になりません.

Apple のフレームワークを活用し、ネイティブアプリとして開発されているため、iCloud やバージョン機能などもフルに取り込まれています。

2. 細かい操作性。

Sketch のユーザーインターフェースは、初見で見た時に「こんなシンプルでまともなの作れんの？」と不安を覚えることがあるかもしれません。

しかし、シンプルイズベストとはよく言ったもので、そのUIにすべてがつまっています。

キーセットを覚えるまでは慣れないかもしれませんが、
(といっても自然に使える程度) ほとんど Adobe 製品と同じような感覚で使用できます。

上記のGIFのような操作はもちろん、
これに Shift キーを合わせて使用すると 10px ずつマージンを測りながら移動できます。

3. シンボル・スタイルの共有

Fireworks にはお馴染みの機能である、シンボル機能も Sketch には搭載されています。

ボタンを繰り返し設置したり、
h1,h2,h3 などのHTMLタグに合わせてスタイルを共有したり。

より、コーディングの時のことを頭で考えながら作ることができるようになりました。

4. 充実した書き出し機能

Sketch はベクターベースのドローイングソフトですが、
豊富な書き出し機能により、 Web デザインにもより使いやすいものとなっています。

png, jpg といった従来のフォーマットはもちろん、
svg,eps, PDF での書き出しも容易です。

シェイブやレイヤーをスライスする時も、一々選択範囲を指定せずとも、簡単にスライスすることができます。

5. プラグインによる拡張

Sketch は、jstalk で機能拡張用のプラグインを書くことができ、その多くが Github などで公開されています。

最近では、 Sketch toolbox というアプリでプラグイン管理をすることができるようになりました。(まだベータ版ですが)

sketch-mesure : レイヤーの幅や高さ、丸みなどの情報を別レイヤーとして自動生成してくれます。
content-generator : 写真やテキストのダミーを自動生成してくれます。
日本語版も配布されています。
Duplicator : 素の状態でもレイヤーをコピーしやすいですが、このプラグインを使用することでより柔軟に複製することが出来ます。

6. ページ・アートボード

イラストレーターではおなじみのアートボード、
Fireworks でお馴染みのページが Sketch には容易されています。

Web サイトを作る時に、ページ毎にファイルを分けて保存するとなると、
ファイル数も膨大になりがちですが、
Sketch では、一つのファイル内で完結することができます。

また、アートボードも作成できるため、
一つのページ内に、PC・タブレット・モバイルのデザインを作成しつつ、
ページ毎にデザイン制作を進めていくことができます。

もちろん、前述した「シンボル」機能もページ・アートボードを超えて共有することができます。

これにより、いくつかのページをコンポーネントデザイン用のページに当てて、シンボル機能を使用し、ページごとにコンポーネントを挿入するなんてことも可能です。

7.その他地味に使えるところ

1. 画像の切り抜き・貼り付け

Sketch は画像の編集が苦手なのですが、
なんとかごまかせます。

例えば、ダブルクリック後に選択範囲を決めコピペすると、
その選択した範囲のビットマップ画像を別レイヤーとして作成してくれたりします。

2. Photoshop、Illustrator からコピペ

その他デザインソフトから、コピペでデータを受け渡しもできます。
ベクターベースのレイヤーでしたら、ほとんど誤差なしで Sketch に貼り付けることができます。

いかがでしょうか？
上記のことは、Sketch 3 の機能ほんの一部です。
10月18日の Sketch 3 勉強会 in NAGOYA では、こもりまさあきさんにもっと詳しくわかりやすく Sketch 3 の解説をしていただけますので、
是非ご来場ください！

Sketch 3 勉強会 in NAGOYA + Webデザインと開発の未来

postfix

もう季節も変わったことが感じ取れるほど、暖かくなってきました。
弊社では暑がりばかりなため、あと2週間もすれば冷房を入れ始めるのではないかと思います。

さて本題ですが、この度レガシーなPHPで稼働しているシステムを新サーバーに移行する案件を引き受けました。

内容としては、

apache + php 5.1.6 + MySQL で動作する一般的なWebアプリケーション
クライアントが現制作元との契約を切り、コスト削減のためにシステムを移行するため、情報開示に非協力的。
4月末日で現在の制作会社との契約を切るため、急いで対応して欲しい。( この時点が4月25日ほど。 )

この情報のみが受注前に与えられ、やる、やらないかの2択。

一見、博打のような案件です。黒い。ドス黒い。

… ですが、金額が結構な高単価だったため、引き受けました。

まぁ、そのおかげで全く経験のなかったことをやれたのですが、
それと引き換えに睡眠時間を奪われました。

また、sugimotoさんにもTwitterから助けて貰い、本当に迷惑をおかけしました。

メモ用にちょっと記事を書いてみます。

移行の開始

新サーバーはさくらのVPS SSD 4G プランを採用しました。
正直、VPSの中ではSSDがこんな低コストで使えるのはここだけなんじゃないかな。( 海外も含めるといっぱいあるかもしれませんが。 )

まぁ、正直クライアント的にはもっと安いレンタルサーバーにしたかったみたいです。
それではいざ蓋を開けた時にどうもできないということになるといけないので、VPSに。

さくらのVPSを借りてもらい、手続きをしてもらったのですが、やり取り上のミスで実際に新サーバーが使えるようになったのが25日。あと5日しかない。

とりあえず、chef で環境を構築。

そこで旧サーバー元からやっとこさFTP、DBなどの必要情報を貰い中身を見てみると…….

な、なんじゃこりゃー！

現状のWebアプリケーションを動かしているのは、

サイト本体のデータが入ったサーバー
サイトの管理画面が入っているサーバー

上記２つに別れているということがわかりました。

なおかつ、2 の管理画面が入っているサーバーと、本体が入っているサーバーとではphpのバージョンも、apacheのバージョンも、Mysqlのバージョンも違うことも判明。

これ以上サーバーは借たくない。無慈悲なクライアント。

まぁ、なんとかやってみました。

これはすごい。便利すぎるmacアプリ2個見つけてしまった件【作業効率化】

PageLayersとSlicy。

今後の作業が激変しそうなmacアプリを2個も見つけてしまいました…..

僕が知らなかっただけでしょうか。そうだとしたら今まで相当損をしていたような気がします。

そこまで思わせるような作業の短縮には持って来いのアプリを紹介します。

WordPress Widget Customizer – Tips.

WordPress 3.9 から追加された「Widget Customizer」でのTips。

「Shift + クリック」で、ウィジェットをクリックすると、カスタマイザーの方でウィジェットが開く。

ウィジェットにマウスホバーすると、フロントのウィジェット部分がフォーカスされる。

ソースは

wp-includes/class-wp-customize-widgets.php  
wp-includes/js/customize-preview-widgets.js

あたりを参照。

テーマ関係なく動作するはずですが、テーマによってはバッティングするかも。

それだけ。

transmitのディスクマウント機能 × codekitが便利すぎる

最近本格的にsassやlessなどのcssプリプロセッサを使い始めた1shiharaです。

まぁ、先日あったHTML5勉強会のお陰です。
windowsの時にはいちいち変換→アップロードという手順を踏まなければならなかったので、すごくめんどくさいという印象でした。
しかし、どうやらcodekitというソフトを使用すると簡単にできるみたいですね。
そこから実際に使い始めて見た印象ですが、

神っすね。もう普通の作業並みのスピードを保っていられる。
しかも、ブラウザもオートリロードしてくれるので至れりつくせりです。
でもね。それも所詮ローカル環境のみの話だろと。思っていたんですよ僕は。
クライアント様にとりあえずトップだけでも先にサーバーにアップして欲しいなんて言われると諦めてたんですよ。

一回一回保存してtransmitにドラッグアンドドロップ。

結局こうなるのかと。

いやいや、でも待てよ。いちいち普通の開発者さんたちがこんなこと繰り返してるのか？

やっぱり大事なのは探究心ですよね。

探し始めてまずmac fusionというサーバーをFinderに表示するソフトを見つけたのですが、いろいろあって結局使えず。
それでもへこたれずに探しました。

くそー。transmitってmacで一番使えるFTPクライアントじゃないのかとか。
もうね、多少なりとも恨みも入ってました。
意地でも探してやる。みたいな感情もありましたね。
でもよく考えるとtransmitって正直使い倒したことないんですよね。少なくともごく平凡なFTPクライアントとしてしか使っていませんでした。
ちょっといじくってみるかとtransmitを触っていたんですが、

そこには気になる「ディスクマウント機能」の文字が!!!!!1111
気になってwebサイトを見てみると僕が探していた機能がそこには書いてありました。

[browser-shot width=”700″ url=”http://www.kevinleary.net“]

なんて時間の無駄だったんだ。結構、1,2時間ぐらいは時間たってました。
transmit様悪口いったりしてすみませんでした。
やっぱり最強のFTPクライアントソフトの名は伊達ではなかったんですね！

ということでこの機能で一体どんなことが出来る解説します。

1. sublime textにファイルごと突っ込んでそのまま編集＆保存。

sftpなんていらなかったんだ…..

でも、バックアップには気をつけよう。

2. codekitにもそのまま突っ込んでそのままコンパイル。

コンパイルされたファイルも当然サーバー上にそのまま吐き出される。

テキストエディタで保存するだけでコンパイル × アップロードも完了。

3. FInderのUIでファイル操作が可能になる。

しかも結構軽い。

でも探したらかなり有名な機能だったんですね。

はぁ、もっと前から知っておけばバリバリのsass使いに慣れたのに。。。。

【nginxはやい】AWSにサーバーを移行しました。その際のメモ。

先月のAWS(Amazon Web Service)の勉強会に参加した時に決意したこと。

 AWSでサーバーを構築して見せる！！(ドンっ)

…みたいな感じだったんですが、nginxでつまづき気づけば2週間。

いやー、やっぱりサーバーって難しいです。

この2週間黒い画面とにらめっこでなんとか今日解決しました。

長かった。そして長かった。ホントーにながかったです。

nginxのconfigファイルとどれだけにらめっこしたか….

そして結局php-fpmのほうの設定という熱い展開でした。

苦労したのでメモっときます。

ちょっと寄り道 – Amazon Web Serviceについて

Amazon Web Service(以下AWSとします)は、かの有名な米Amazon社が提供するクラウド・コンピューティングwebサービスのことです。

Iaas呼ばれているサービス形態ですが、他にはwindows Azureや、

Google Apps engineが有名どころです。

クラウド・コンピューティングについては以下の記事が参考になるのではないかと。

5分でわかるクラウド・コンピューティング – アットマークIT

平たくいうと、PC(サーバー)をインターネットを通じて借りるといったサービスです。

AWSのメリットといえば安い。早い。そして簡単にできる。
とよく言われています。

僕もAWSについては早い段階から知っていたのですが、今まで使う機会が中々ありませんでした。

実際に使うにはクレジットカードとPCがあれば使用出来ますので、是非試して下さい。

nginx(エンジンエックス)について

nginxとはオープンソースのWebサーバです。
webサーバーには他にも様々な種類があります。
普段皆さんがよく使っているapache(アパッチ)や、
Microsoft製のIIS(Internet Information Services)というものもあります。

前者の２つ、nginxとapacheはオープンソースであり、大抵のOSに対応していますが、
後者のIISの方はwindows上でのみ稼働します。

コチラはよく使われているものですね。

(no title)

Responsive and Adaptive Design

レスポンシブ & アダプティブ webデザイン

すっかり普及しているレスポンシブwebデサイン ( 以降 RWD )。
しかし、問題点も数多くあります。

UXを考えたUIを表現しにくい。デバイスごとに最適化しにくい。

デスクトップとモバイル機器の違いは何も画面サイズだけではありません。

使う「場所」も違えば、操作するツールも違う。

ニーズを持つユーザー層や、接続するスピードも違います。

デバイスごとに最適化されているサイトと、
レスポンシブでCSSの範囲で作られているサイト。

どちらが優れたUXをもたらすデザインを考えやすいのか。

いうまでもないと思います。

パフォーマンスが落ちる。

スマホがいくら高性能になってきたからといっても、

デスクトップ・ラップトップとの性能差は大きな壁として存在しています。

javascriptの処理スピード。
ネットへの接続状況。

javascriptがandroidのあの端末だけ異常に重い…….

なんてこともよくある話です。

構成から実装まで複雑である。

RWDでもしフレームワークを使わずに、
一から設計、実装をやる。

経験したことがある人にはわかると思いますが、
多大な時間と労力がかかるものですよね。

開発費用にコストがかかる。

多くの人が未だに、

RWD = ワンソースマルチユース

ワンソース？ = コストが低いのでは？

と考えている方がまだまだいます。

しかし現実は、デバイスごとにサイトを作成するのと同程度、
または、それ以上にコストがかかってしまうこともあります。

( もちろんやり方によっては、RWDで制作することにより、コストを削減できます。)

以上、RWDの問題点について簡単に書き出してみました。

レスポンシブwebデザイン。
確かに多様化するデバイスの中、
我々制作者が対応していくには必須の技術だと思いますが、
まだまだ考えるべき課題はたくさんあります。

レスポンシブwebデザインで以下に効率よく制作するか。
にいては、

Web Design Process for The Fiture – こもりまさあきさん –

のスライドがものすごく参考になるので是非目を通してみて下さい。

( 実際に僕もセミナーで発表をきいたのですが、衝撃的でした。)

臨機応変に手法を変える。

僕は別にレスポンシブwebデザイン自体がダメだとは思っておりません。

上記のデメリットについては、

Responsive Web Design is Not the Future

から拝借させて頂きましたが、
僕は、

A Response to ‘Responsive Web Design is Not the Future’

の意見に賛成です。

技術者の努力・知識によって解決出来る問題もたくさんあります。

そこで僕は、

レスポンシブwebデザインで素晴らしいサイトを作るためにどんな手法があるのか、
これからのレスポンシブwebデザインはどう変わっていくのか。

調べてみました。

レスポンシブwebデザインに広まっている誤解

今のレスポンシブWebデザインは誤解されている

といった文献も見受けられました。

「今のレスポンシブWebデザインは誤解されている」英の著名デザイナーAndy Clarke氏が話す3つの修正点

Responsive and Adaptive Design: Defined

RWDはあくまでも可変するものです。

これがレスポンシブ。

.container{
    width:90%;
    max-width:1200px;
    margin:0 auto;
}

そしてこれが、アダプティブ。

.container{
    width:700px;
}
@media only screen and (max-width: 767px) and (min-width: 480px) {
    .container{
        width:420px;
    }
}
@media only screen and (max-width: 767px) {
    .container{
        width:300px;
    }
}

例とすると、

MR.SIMON COLLISON

が典型的なAWDとして紹介されています。

メディアクエリーを利用していますけど、
コンテンツの配置・幅自体は３段階しか種類がありませんね。

RWDは、デバイスのサイズに常に応答する(サイズが可変する)物。
という考え方が、どうやら海外では主流なようです。

でも、このやり方でもいいと思うんですけどもね。僕は。

もちろんクライアントには説明しますが、

予算は少ないけれど、スマートフォン・タブレットでも見たい。
という方にはぴったりなような気がします。

各メディアクエリーの最小幅に合わせないと崩れるというのがちょっとたまに傷ですが。