未分類

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

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

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

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

1 HTMLコーディング

 

HTMLバージョン

基本的にHTML5を使用する。

スペース

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

 
HTML タグの命名

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

ID、Class の命名

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

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

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

画像の命名

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

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

例

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:

 

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 や バージョン機能などもフルに取り込まれています。

Artboard 2

2. 細かい操作性。

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

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

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

9bc78e0013062bcf047c408041ebc0a2

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

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

sketch-share

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

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

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

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

5bfd179df55e0d0adc312e3bedff44aa

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

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

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

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

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

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

  • sketch-mesure : レイヤーの幅や高さ、丸みなどの情報を別レイヤーとして自動生成してくれます。
    2014-10-07 22.06.20

  • content-generator : 写真やテキストのダミーを自動生成してくれます。
    日本語版も配布されています。

  • Duplicator : 素の状態でもレイヤーをコピーしやすいですが、このプラグインを使用することでより柔軟に複製することが出来ます。

25272d8a99674f5396f3a86eef1f6f03

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

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

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

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

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

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

sketch-workflow

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

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

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

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

2. Photoshop、Illustrator からコピペ

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

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

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

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

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

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

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

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

3つの「アダプティブwebデザイン」

アダプティブwebデザイン。

こちらもレスポンシブwebデザインが考えられた際に時同じく考案された手法です。

Responsiveが「応答性」なのに対し、

Adaptiveは「適応性」という意味。

いろいろ調べ直した結果、
今現在では、4つのアダプティブwebデザインという概念？があるような気がしました。

一つは、先ほど紹介した、メディアクエリーを利用したアダプティブデザイン。
しかし、こちらはなんだかレスポンシブwebデザインの下位互換として広まっています。

そして２つ目が、
デバイスごとに適応させたサイトを作る方法のこと。

ユーザーエージェントごとにスマートフォン専用サイトや、タブレット専門サイトにリダイレクトさせるものアダプティブwebデザインだそうです。

気になる3つ目は、RWDを内包した概念とした立ち位置のAWD。

以下の図をみるとよくわかります。

title

プログレッシブ・エンハンスメントは、最新のブラウザにはよりリッチに、古いブラウザには最低限の見れるものを、というあの概念です。

RWDというのは、 AWDという考え方の中の一つの手法でしかない、というわけです。

最後は、ユーザーのコンテキストに合わせて表示する内容を切り替えるAWD。

レスポンシブからアダプティブへ – 必要な情報を、必要なときに、必要としている人へ

性別、場所、年齢、といったユーザー属性や、ユーザーの行動を分析し、それに合わせたサイト設計をする。

ということらしいです。

上記の記事・元になったスライドでは、主にセンサーを利用した判別方法を使用していました。

確かに、

  • wifiにつながっている時だけ、背景で動画を流す。
  • 高齢者向けにサイトを用意する

なんてこともできますよね。
ポータルサイトでも、アクセスした地域によってスタートページを変えるということも今までよくあったと思います。

これは、結構面白い考え方だなと感じました。

レスポンシブwebデザイン + アダプティブwebデザイン　＝　？

………ってことで、

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

  • これからのデザインはアダプティブ web デザイン。

  • センサーや位置情報を利用したもの

  • RESS ( Responsive web design + Server SIde Compornent )を使用してデバイスごとに適応。

WordPress Development Bookmarks.md

Ghostに移行した後の記事がWordPress関連という、なんとも言えない感じ。

ってことで、WordPressに関するリソースを僕なりにまとめてみました。
あとでGithubなんかに公開したいと思います。
案外時間かかるもんですね。これから更新し続けようと思います！

もし、おすすめのツールとかありましたら教えてください。

元ネタは https://github.com/dypsilon/frontend-dev-bookmarks

github : https://github.com/1shiharaT/WordPress-Developement-bookmarks

WordPress Development Bookmarks

2013/11/11 ~ 14日 Bookmarks.

2013/11/11 ~ 14日に読んでおお！と思ったweb関連記事まとめ。

1. ink

レスポンシブなEmailを作成できるフレームワーク

  • tool 、Framework

2. Glyphs

アイコンPSD

http://glyphs.bulb9.com/

3. SVGeneration

SVGをGUIで。Data URLでの取得も可能。

http://www.svgeneration.com/

4. OpenNote

Evernote、 MicroSoft OneNoteライクなwebアプリケーションを作成できる。
(ライセンスはどうなのか知らない。)

http://stardrive.us/OpenNote/index.php?folderID=7399&noteID=6936

5. Free vectors icons for download and Icon font | Flaticon

Photoshopのプラグインまで用意してあるフラットなiconセット。

http://www.flaticon.com/

6. Formoid – Beautiful CSS Form Generator

お問い合わせフォームを簡単に作成可能なアプリ。無料版だとformanoidの表記がフッターに入る。

http://formoid.com/

7. Typeform

ダイナミックなお問い合わせフォームの構築ツール。無料プランあり。

https://www.typeform.com

8.Dropzone.js

ドラッグアンドドロップでアップロード出来るエリアを表示するjavascriptライブラリ。

Dropzone.js : http://www.dropzonejs.com/

WordPress でレスポンシブ対策には必須のプラグイン？「BJ Lazy Load」

投稿内の画像を自動で遅延ロード、最適化、リサイズ、キャッシング。
さらには、画面の解像度までみて判断してくれる優れもの。

WordPressでレスポンシブwebデザインを実装するならもはや必須的なプラグインだと思います。

遅延ロードというのは、画像が表示領域に入るまでは別の画像 ( 極端にサイズが小さいもの 、透明の画像とか) を表示しておいて、表示領域に入った際に読み込むというテクニックです。

もちろん、レスポンシブwebデザインでなくても使えますので、ぜひともご参考にー。

BJ Lazy Load

情報収集の取り組み

HTML5名古屋 #10で20分程お話しをさせていただきました。

前に軽くまとめていたのですが、今回発表者が少ないということで。

かなり簡素な作りになってますｗ

情報収集に関しては人それぞれ方法があると思うので一概には言えないですが、

僕の場合はこんな感じです。

こもりまさあきさんのSNSフィードも情報がものすごく早いので、
是非！

https://www.facebook.com/proteanim?fref=ts

デザインツールのあれこれ

HTML5名古屋 #11 で「デザインツールのあれこれ」というテーマでLTをしました。

スライド内で紹介できなかったものも多々あったので、
(非常に) 簡単に書き出してみました。

Photoshop Plugin

1. BlendMeIn

ベクター素材をPhotoshop内で表示。ライセンスにはご注意を。

→ BlendMeIn

2. Flat Icon

フラットなアイコン素材をPhotoshop内でクロール・挿入。

→ Flat Icon

3. Ink

幅・高さ。Opacityといったのレイヤー情報を「_Ink」ディレクトリ内に、レイヤーとして書き出し。

→ Ink

4. Socail Kit

FacebookやTwitterなどのPSDテンプレートを用意。

→ Socail Kit

5. Zeick

選択したレイヤー(文字・シェイプなどのベクターに限る)を、ワンクリックでSVG書き出し。

→ Zeick

6. Random user generator

ランダムなユーザー画像・情報を表示・挿入可能に。

→ Random user generator

7. SUBTLE PATTERNS PHOTOSHOP PLUGIN

高品質なパターン素材をPhotoshop内でクロール・挿入。

→ SUBTLE PATTERNS PHOTOSHOP PLUGIN

8. PNG HAT

選択したレイヤーをBase64や、png・2xでの書き出しが一瞬で可能に。

→ PNG HAT

9. LAYER CONTROL

複数のレイヤー・グループのリネームや、使用していないエフェクトの削除

→ LAYER CONTROL

10. render.ly

命名規則に従うことで、一つのPSDファイル内でページを分けて書き出しできるように。

→ render.ly

11. composer

複数のレイヤー・グループ操作が可能に。

→ composer

12. Renamy

先に紹介したLAYER CONTROLより、柔軟なリネームが可能です。
また、よく使われる単語をサジェストで表示してくれます。

→ Renamy

13. Slash

名前・キャラクターの予想通り、スライスのためのphotoshopプラグインです。
しかし、自動で連番をつけたり、ディレクトリ階層を再現したりと他のスライス拡張ツールよりも多機能
。

→ Slash

14. Transform each beta

photoshopの時間がかかる作業の一つである、レイヤーのリサイズがしやすくなるスクリプトです。
各レイヤーの起点はそのままに、大きさだけリサイズできます。

→ Transform each beta

For Sketch.

https://gist.github.com/1shiharaT/9368608#file-design-tool-md

Sublime Text 3 からEvernoteへ。~ そしてマークダウンで ~

普段僕はVimかSublime Text 3を主力のエディタとして使用しています。

特にSublime Textでは手軽に拡張できるPackage Control という機能があります。

先日、Package Control – the Sublime Text package managerをしらーと見ていると、おもしろそうなプラグインを発見したので、
感想を書き綴ります。

Sublime TextからEvernoteへ

元々、SublimeText2用にプラグインがあったのですが、
そこからフォークしてフォークして作られたプラグインです。

https://github.com/bordaigorl/sublime-evernote

SublimeText3からEvernoteへマークダウンを保存できるというプラグインなのですが、
なぜエディタは人をそこまで突き進めるのか謎ですねホント。
別に他のでいいんじゃねと。

上記のgifでもちょっとでてますが、タグやノートの設定なども可能です。

まぁでも、便利ですね(ほっこり)。
作成していただいた方に感謝です。

ちなみに

Vimではもっと高機能なevervimがあります。
うーむ。すごい。