3G回線をエミュレート出来る Network Link Conditionerの使い方

こんちは!basara669です。

レスポンシブのサイトなどが流行っていますが、そうした時に気になるのが3Gなどの回線速度が遅い場合の表示速度だと思います。

この回線速度をエミュレート出来る『Network Link Conditioner』の使い方を紹介します。
後半でWindowsやLinuxで似たツールを紹介していますが、基本的な対象者はMacユーザーです。

「イマドキCSS設計」の解説 – 後編:BEMとSMACSSと実際の運用について

こんにちは!basara669です。

勉強会で使った「イマドキCSS設計」の資料の解説の最終回で、BEMについてもう少し具体的な例を書きました。また、SMACSSについても軽く触れ、実際にこれらの概念を取り入れて、どのように運用したか書きました。

他の記事はこちら

「イマドキCSS設計」の解説 – 前編:css設計の必要性


こんちは!basara669です。

先日、勉強会で話した資料がかなり反響があって、様々な人に閲覧していただきました。

イマドキCSS設計

ただ、これだけだとコードしか無かったりよくわからない部分も多いと思うのでその時の勉強会で話したところも含め、解説していこうと思います。

ただ、書いたら量がかなり多かったので、3つに分割しました。。

「Color Sublime」ならSublimeText2のテーマが色々楽しめるぞ!

やっぱりなんだかんだSublime Text2を使っているbasara669です。

SublimeText2はthemeを変えてカラーリングを変更出来るのですが、いちいちインストールして、確認するのって意外とめんどくさいのと、どんなのがあるのかわかりづらいと思います。
Sublime Text2のカラーリングを探すのにとても便利なColor Sublimeを紹介します。

cssNite Sendai vol7 見てきました

またまた、仕事でCSSNiteに参加してきました。
仕事ですよ!
まぁ、牛たんは食べましたけどねw

利久の牛タンmgmg #痩せる気がしない

CSS Nite Sendai vol7で感じたこととかを書いていこうと思います。
CSS Nite in SENDAI, Vol.7 | CSS Nite in SENDAI

2013年はWeb制作の曲がり角

毎度プレゼンテーションが美味いなっていうのと資料の綺麗さとかエンターテイメント性とかすごいなと思います。
見る人はどう思うか、どうすると伝わるかをすごく考えられている方なので、プレゼンテーションという面で非常に勉強になるなと思っています。
こういうのは場数を踏むしか無いのかな〜。プレゼンうまくなりたいっすわ〜。

Webサイトの核をデザインするための最初の一歩

Web制作とはどうしたら良いのかを考えるようなセッションでした。
これからのWeb制作は本当に制作だけをやっているだけだとジリ貧になっていくという観点は岡山で聞いた中川さんのセッションと、とても似ているなと思います。
この中であったのはデザインだけをやっているだけで良いのかということです。デザインはWebの中の本当に一部。本来、最も大切なのはコンテンツ。
製作の中では、コンテンツはすでに良いという前提で作られていますが、本当にそうなのだろうか、そのコンテンツもデザインするのが今後のWebデザインの中で必要なのではないか?という内容でした。

コンテンツが良いかと聞くと、企業は80%がよいというそうです。しかし、ユーザーに聞くと8%しか良いと言わないそうです。つまり、10倍以上の乖離があります。
ということはコンテンツを善として考えるのはそもそも間違っているのではないか?ということです。

コンテンツのブレや間違いが起こらないようにするにはどのようにすればよいでしょうか?それは核を見つけることが大切になるそうです。
ほとんどの企業はwhat→How→Whyという順番で考えており、何をするのか、何を売るのかから考えることはとても簡単です。しかし、それでは本当に提供したいものがブレてしまいます。
なので、what→How→Whyの順番ではなく、why→How→whatから考えるべきであるというのが大切です。
Appleやディズニーなど成功している企業はこの順番から考えていて、確かに、Appleのように「世界を変える」や「人々を幸せにする」とかなぜそれをやっているのかという視点から考えている気がします。

この核を追求してあげることが、今後の製作に必要な視点だということです。
本当に僕も毎日仕事をしていて共感することが多かったです。確かにこのまま、ただ、製作をしているだけではダメで、こうした核を追求してあげることがとても大切だなと思いました。
この考え方を知る上で紹介されたのが下記の本です。

早速ポチっちゃいましたw

ただ、このセッション。確かにその通りだと思うのですが、これは長谷川さんだからできるので、1製作者でできるかな〜とは思いましたw
僕もそういうことを指摘出来る製作者になりたいです。

Web制作の変化の波に乗りおくれるな!

こもりさんは、本当に色々な技術を知っているな〜!といつも思いました。
CSSプリプロセッサ辺りやCSSフレームワークの辺りはよく知っている内容だったのですが、Static Site Generatorなどはあまり詳しくなかったので非常に勉強になりました。
次に作るサイトは基本技術者ばかりのところのサイトだったので、jekyllを使ってみようかと思ったのですが、他のも使ってみたくなってしまいましたw
特にデモがとてもうまく、僕もこんな風に作れるんじゃないか!って思ってしまいますw

企業の中にいるとなかなか、新しい技術を採用出来ないのですが、頑張って取り入れていきたいなと思います!

まとめ

結局3人の方のセッションで共通していたのは、これまでの製作フローやこれまでの製作パターンのままではダメだということ。
個人的には製作側から考えると、Flashが減り、プログラマーがフロントエンドに来たことで劇的に変化してきたと思います。そして、様々な作業が自動化されてきて作業が減ったことで、これまでのワークフローのままでは確実に取り残されます。
僕もモンハンばっかりやってないでちゃんと勉強しないとな!
ではでは

Chrome の DevToolsを使って iOS6 と iOS7 のMobile Safariをデバッグする方法

iOS6のMobile Safariから、PC上のSafariのWeb inspectorを使ってデバッグ出来るようになりました。でも、便利といえば便利なんですが、Safariの Web inspectorって若干不便なんですよね。
というか、使い慣れていないので、イマイチ使いこなせてないです。

やっぱり慣れているChromeでデバッグをしたいという方もたくさんいらっしゃると思うので、ChromeのDevToolsを使って、iOS6やiOS7のMobileSafariに使う方法を紹介します。

ios-webkit-debug-proxyのインストール

まずはios-webkit-debug-proxyというものをインストールします。
これをインストールするには、HomeBrewがインストールされていないといけないので、brewコマンドが使えるようにしてください。
※インストールされてない方は下記の記事を参照しながらインストールしてください。

HomeBrewがインストールされている状態でターミナルから下記のコマンドを入力します。

[c]
brew install ios-webkit-debug-proxy
[/c]

HomeBrewがインストールされていない場合はこちらの記事を参考にインストールをしてください。

HomeBrewのインストールの仕方 | 黒い画面 | basara669.com

iOSデバイスの用意

iOS6でも、7でも良いので準備します。これはiOSのシミュレータでも動作します。
実機であれば、USB接続をして、設定からWebインスペクタをONにしてください。
iOSシミュレータであれば、立ち上げればOKです。

次に任意のページを開いておいてください。

プロキシを立ち上げる

下記のコマンドを売って、先ほどインストールした、ios-webkit-debug-proxyを立ち上げます。

[c]
ios_webkit_debug_proxy
[/c]

chromeで下記にアクセスします。

http://localhost:9221

そうすると、下記の様なページが出ます。

シミュレータでも実機でも検証したい方を開きます。
そうするとこの通り!!
iOSのMobileSafariをDevToolsから見ることが出来ます。
※モンハンのページ開いてたのがバレバレだ〜!w

実機が写ってないのでわかりづらいですが、こんな感じで慣れ親しんだDevToolsでサイトの検証ができちゃったりします。
そんなに難しくないので気になるのはやってみてください。
ではでは

Bower 超入門!使い方を解説してみる!

最近ちょいちょい聞くbowerなんですけど、一体に何に使えるのか良く聞かれるのでざっくり解説してみました。
機能には関係ないですが、発音は「バウワー」だと思います。「ボワー」という方もいらっしゃいますがw

bowerの概要

bowerはWebに特化したパッケージマネージャーです。
こういうと慣れない方だと頭痛くなってしまう感じですが、そんなに難しくなくて、色々なアプリがインストールできたり出来るツールだと思ってください。
極端なことを言えばMacのappStoreみたいなものですww(え?違う?w
なので、これを使えば、いちいちサイトに行かずともコマンドから、jqueryやangularなどがインストールすることができます。

どうやって使うのか

使い方はターミナルからこのコマンドを打てばすぐ使えます。

[c]
npm install -g bower
[/c]

これだけでインストール完了です。

ライブラリを入れてみる

試しにanuglarを落としてみます。

[c]
bower install angular
[/c]

最新のバージョンがインストールされました。
また、特定のバージョンを入れたいという場合であれば、下記の様な感じでバージョンを書けば、そのバージョンのものがインストールされます。

[c]
bower install angular#1.2.0-rc.1
[/c]

こうすると、他のバージョンがインストールされます。
いちいちサイトに行くのはめんどくさかったので捗ります

何を落としたか記録をしておく

bowerにはそれ以外にどのようなライブラリを落としたか記録することができます。例えば何かの案件で下記のようなライブラリをインストールしたとします。

  • jquery
  • bootstarp
  • angular.js
  • underscore.js

何を使っているかまでは覚えていたり刷るのですが、どのバージョンを使っているかまでは覚えているのは大変だと思います。
これをjson形式で管理できたりします。

[c]
bower init
[/c]

このコマンドで今の状態jsonファイルに残すことができます。
この際にこの一式のプロジェクトのバージョンや名前が確認されます。適宜入力を行ってください。
この記事では、「testApp」でversionは0.0.1としました。

入力が完了すると、component.jsonというファイルが出来ます。

中を見るとこんな感じになっています。

[c]
{
“name “: “testApp “,
“version “: “0.0.1 “,
“dependencies “: {
“angular “: “~1.2.0-rc.2 “,
“jquery “: “~2.0.3 “,
“bootstrap “: “~3.0.0 “,
“underscore “: “~1.5.1 ”
},
“ignore “: [
“**/.* “,
“node_modules “,
“components ”
]
}
[/c]

dependenciesというところで、使っているライブラリが定義されているので、仮にライブラリがない状態であっても、このバージョンをそのままインストールすることができます。
試しにインストールしたライブラリを削除し、bowerの機能を使って、ファイルを復活させてみます。

[c]
bower install
[/c]

↑のコマンドを打つとファイルが復活したかと思います。

他の人が作ったライブラリ集を使ってみる

このライブラリ集なのですが、他の人が作ったものが世の中には公開されています。
例えばangular.jsに関わりそうな物を探す場合は、下記のようなコマンドで探すことが出来ます。

[c]
bower search angular
[/c]

このコマンドを打てば、angularに関する様々なcomponent.jsonを見ることが出来ます。

また、自分が作ったものも公開することができたります。

[c]
bower register SomeName
[/c]

[SomeName]部分には自分のプロジェクトの名称を入れてください。

まとめ

ざっくりとですが、bowerについて簡単にまとめました。
普通にダウンロードするほうがラクって思われる部分もあるかもしれませんが、後々のメンテナンス性やチームとの共有などを考えるとbowerを使うほうが捗る場合が多いように思います。
とても便利なので、ぜひ使ってみてください。

ではでは

cssをより良く書くために気をつけている12のこと

最近ガジェットなエントリーばかりだったので、たまにはちゃんとした技術的なエントリーを・・。

CSSはとても簡単な言語で、誰でもすぐ書けるようになるんですが、とても壊れやすいものだと思います。
簡単に無駄なコードは増えやすいですし、無駄が無い方がブラウザのレンダリングはもちろん早いです。
今回はCSSを書く上で、メンテナンス性を保ちつつ、パフォーマンスの高いCSSを書く上で気をつけていることを書いていこうと思います。
CSSを書く上で気をつけているポイントは、とても普通なことですが、こんな感じですw

  1. IDのルール
  2. クラスのルール
  3. タグのルール
  4. 細かい書き方のルール

この辺りで書き方で気をつけるべきポイントを書いていこうと思います。

必要以上にセレクタを指定しない。

IDは1つしか適用出来ないので、一番強力なセレクタです。
あえて他のセレクタと一緒に指定する必要はありません。

[css]
// bad
ul#someid {..}
.menu#otherid{..}

// good
#someid {..}
#otherid {..}

[/css]

子孫セレクタを使いすぎない

子孫セレクタを使いすぎると非常に脆いCSSになってしまいます。
下記の様なコードの場合、何か1つでも抜けるとすぐCSSが適用されてしまいます。

[css]
// very bad
html div tr td {..}
[/css]

複数のクラスに適用するなら1つのクラスにまとめる

下記のようなCSSを作るくらいならば、1つのCSSのクラスをしたほうがメンテナンスしやすいですし、後から見てもわかりやすいです。

[css]
// bad
.menu.left.icon {..}

// good
.menu-left-icon {..}
[/css]

ダイレクトな指定を心がける

例えば下記の様なHTMLがあったとしたら、

[html]
<ul id="navigator">
<li><a href="#" class="twitter">Twitter</a></li>
<li><a href="#" class="facebook">Facebook</a></li>
<li><a href="#" class="dribble">Dribbble</a></li>
</ul>
[/html]

個別のclassがあるので、aまで指定するのではなく、その上のレベルで指定をしていきましょう。

[css]
// bad
#navigator li a {..}

// good
#navigator {..}
[/css]

短く書けるものは短く書く

使えるのであれば、短いプロパティを使っていきましょう。

[css]
// bad
.someclass {
padding-top: 20px;
padding-bottom: 20px;
padding-left: 10px;
padding-right: 10px;
background: #000;
background-image: url(../imgs/carrot.png);
background-position: bottom;
background-repeat: repeat-x;
}

// good
.someclass {
padding: 20px 10px 20px 10px;
background: #000 url(../imgs/carrot.png) repeat-x bottom;
}
[/css]

無駄なセレクタの指定はしない

他の所でも書いていますが、セレクタの指定はなるべく最低限にしたほうが良いです。

同じようなCSSを書かない

書いていると忘れがちなのですが、結構同じようなCSS書いてしまいますよね。
そういうのは書かないようにしましょう。
sassを使っているのであれば、@includeなどをうまく使うのが良いと思います。

[css]
// bad

.someclass {
color: red;
background: blue;
font-size: 15px;
}

.otherclass {
color: red;
background: blue;
font-size: 15px;
}

// good

.someclass, .otherclass {
color: red;
background: blue;
font-size: 15px;
}
[/css]

再利用できるCSSはまとめる

HTMLの書き方にも影響してくるのですが、全体的なものに使えるもの(例えばボタンのShadowやpaddingなど)を指定して、個別に変更あるもの(例えば背景色)は個別にしていくと良いです。

[css]
// bad
.someclass {
color: red;
background: blue;
height: 150px;
width: 150px;
font-size: 16px;
}

.otherclass {
color: red;
background: blue;
height: 150px;
width: 150px;
font-size: 8px;
}

// good
.someclass, .otherclass {
color: red;
background: blue;
height: 150px;
width: 150px;
}

.someclass {
font-size: 16px;
}

.otherclass {
font-size: 8px;
}
[/css]

わかりづらい名前をつけない

CSSのclassなどの名前は略しすぎてしまうと、その後読んだ人がわからなくなってしまいます。
多少長くなってしまっても良いと思うので、わかりやすい名前を指定しましょう。

!importantsを使わない!

使っちゃいけないと思いつつついつい使っちゃうのですが、使わないほうが良いです。

宣言の順番を決めておく

コーディング規約などで書く宣言内でどのプロパティを呼ぶのか決めておくと、読みやすさが上がります。

[css]
.someclass {
/* ポジショニング */
/* サイズ */
/* 背景色や文字色 */
/* その他 */
}

[/css]

改行をうまく使う

改行が無く、連続でつなげてしまうと、見づらいCSSになってしまいます。なるべく改行などを入れてあげると読みやすいです。
また、値が複数になる場合なども、改行してあげるとより読みやすくなります。

[css]
// bad
.someclass-a, .someclass-b, .someclass-c, .someclass-d {

}

// good
.someclass-a,
.someclass-b,
.someclass-c,
.someclass-d {

}

// good practice
.someclass {
background-image:
linear-gradient(#000, #ccc),
linear-gradient(#ccc, #ddd);
box-shadow:
2px 2px 2px #000,
1px 4px 1px 1px #ddd inset;
}
[/css]

いかがだったでしょうか?
冒頭でも書きましたが、CSSは簡単に書けるのですが、とても脆いものです。
なるべくOOCSSに則って書くのが良いと思います。
偉そうに書いているのですが、なかなか全部出来ているということもないです。
ただ、心がけながら書くと少しだけ綺麗にかけたりするので、少しだけ心がけて書くとよりよいコードになる気がします。

パフォーマンスの高いCSSの書き方についてとても良くまとまっているのが下記の2サイトになります。
英語なのですが、コードを一緒に読めば読めると思います。
読んでみるととても勉強になります!

Google’s best practices for efficient CSS selectors

MDN’s guide to writing efficient CSS

Grunt.jsの始め方 -cssmin,watch編-

前回、sassのコンパイルを行なってみたので、今回はcssminやwatchなどを使ってみたいと思います。

Grunt.jsの概要だったり、インストールが知りたい方は過去記事参考にしてください。

Grunt.jsの始め方 -Grunt.jsの概要編-
Grunt.jsの始め方 -インストール編-
Grunt.jsの始め方 -タスク編集とsass編-

Grunt.jsを使ってcssをminifyしてみる

前回のファイルを利用して、cssをminify化してみようと思います。

Grunt.jsの始め方 -タスク編集とsass編-

今回はGrunt.jsを使って実際、sassのコンパイルを行なってみたいと思います。

Grunt.jsの概要だったり、インストールが知りたい方は過去記事参考にしてください。

Grunt.jsの始め方 -Grunt.jsの概要編-
Grunt.jsの始め方 -インストール編-

gruntfile.jsの書き方

Gruntのタスクはgruntfileというjavascriptファイルに記述します。
まずそのgruntfileの書き方です。

[c]
module.exports = function (grunt) {
grunt.loadNpmTasks(‘プラグイン名’);
grunt.initConfig({
タスク
});
grunt.registerTask(‘default’, [ ‘使用したプラグイン’]);
}
[/c]

1行目はgruntを使うおまじないみたいなものなので、こう書くものだと思って下さい。
2行目で、このプロジェクトで使用するプラグインの名称を書きます。
3行目の「grunt.initConfig」でタスクを登録します。
最後の「grunt.registerTask」でタスクを実行していきます。

gruntのプラグインをインストールしてみる。

package.jsonを使って、gruntをインストールしましたが、プラグインも同様にインストールします。
どのようなプラグインがあるかは、サイトで確認してみましょう。

grunt5

サイトを見てみもらえると分かる通り、非常に沢山のプラグインがあります。
これらの中からどのように選べばよいでしょうか?

プラグインの選び方

  • gruntチームが作っているプラグインは頭文字に「contrib-」と入ってる
  • それでも何を入れて良いか迷ったら、全部入りのプラグイン「contrib」

「contrib-」と入っているものであれば、まず間違いありません。
今回は全部入りの、「contrib」を使ってみようと思います。

package.jsonを下記のように書きます。

[c]
{
"name": "my-project-name",
"version": "0.1.0",
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib":"~0.6.1"
}
}
[/c]

最後の行に「grunt-contrib」のVer0.6.1をインストールするように書きました。
下記コマンドを打って、インストールしてみてください。

[c]
npm install
[/c]

そうすると「node-modules」の下に「grunt-contrib」というファイルが出来上がったと思います。
これでインストールが完了しました。

Grunt.jsを使ってsassを使ってみる

それでは実際にsassをコンパイルしてみます。

[c]
module.exports = function (grunt) {//最初に書く
grunt.loadNpmTasks(‘grunt-contrib’);//プラグインの読み込み
grunt.initConfig({//タスク登録
sass: {//プラグイン名
compile:{//タスク名
files:{
‘style/css/main.css’:’style/sass/main.scss’
},
},
},
});
grunt.registerTask(‘default’, [ ‘sass’]);
};
[/c]

まず最初に使用するプラグインについて書きます。
使用するプラグイン名称にタスク名とどのファイルをコンパイルするかを書きます。
今回はタスク名をcompileと名づけました。
ファイルの指定のしかたは、「cssファイル:sassファイル」で指定出来ます。

今回はstyleという配下にsassとcssというフォルダを作り、その下のファイルをコンパイルしようと思います。

最後に、どのタスクを実行するか書きます。

コンパイルしてみましょう。

[c]
grunt
[/c]

これで、cssファイルが出来たと思います。
次回はもう少しプラグインの紹介を出来たらと思います。

ではでは

Grunt.jsの始め方 -Grunt.jsの概要編-

最近何かと話題のGrunt.jsなのですが、Grunt.jsについてこの間とある勉強会で話して来ました。

Railsとか勉強会!【春だから・わっくわっく!4/24(水)懇親会付き!!】Railsで最速Webアプリモック制作・A/B testing in Rails ・快適CSS Preprocessorなど

まぁ、微妙だったのはRailsとか勉強会って言ってるのに、Grunt.jsの話をしちゃったので聴講者が若干( ゚д゚)ポカーンって感じでしたね。。
結構冷たい目が厳しかったです。。

その際に話したGrunt.jsのことでも書いておこうかなと。。

Scroll to top