2015年1月20日火曜日

CSSの配色のパターンと命名規則

良いものはOSSから盗む

管理画面やWebアプリ用のBootstrapベースのテーマには色々と学ぶことが多い。
PagesのColorを見ていて、普段思っていることを書いてみる。


配色の変数の定義は色の名前ではなく機能で

$redとか、$blue、なんてのはNG!!

いずれ色を変えることもあるかもしれないけど、それよりもまず、base-colorとかcomplete-colorとか、配色の基本に沿った名前の方が汎用性がある。

Sassもコードなので、変更に強いコードを書くべき。
変更に強いコードを書くための鉄則は、変わりやすいものと変わりにくいものを分けること。
$whiteとすれば、背景色を黒に変更する時に、全て$blackに変えないとおかしなコードになってしまう。
$base-colorとしておけば、値を変えるだけで済む。


基本色のバリエーションは比較級を使う

配色では、基本となる色の明度や鮮度を上げ下げすることが多い。
SassやCompassでもそれ用の関数が用意されている。
(参考:A visual guide to Sass & Compass Color Functions
明度以外の関数も載っているので知らない人は見てみると良いかも)


変数名やクラス名には、比較級を使うとうまく収まる。

例) $color-success $color-success-darker $color-success-darkest ...


スタイルガイドを作成する

余談だけど、CSSは秘伝のタレのように、放っておくと継ぎ足されることが多い。
厄介なのは、タレと違って、コードが増殖するということ。
データは熟成するけど、コードは腐敗していくものなので、きちんとスタイルガイドを用意しておくべき。

スタイルガイドにどういったものがあるかは、The Style Guide Guideにまとまっている。

2015/02/09追加:

含まれていないものがあったので、追加。
SC5 Style Guide Generator

個人的には、

  • JavaScriptも絡むかなり動的なWebアプリ、がっつりドキュメント化したい時はHologramでがんばる
  • そうでなければとりあえずKSS
  • もしくはStyleDoccoかな...
といった感じ。


2015/12/28追加:

hologramの代わりにaigisという選択肢も出てきた。こちらはNode.jsで動くので環境を整えやすい。今後はaigisを使うと思う。

2015年1月12日月曜日

複数ブラウザでの動作チェックとCI

複数ブラウザチェックはもう地獄じゃないかもしれない

Seleniumを使ってがんばるのもいいけど、もうそれに労力を使うより、サービスを利用する方がはやくない?って気がしてきた。
人にやらせるより、機械にやらせるかサービスを利用する方が実は安上がりだったりもするし。

stackshareのBrowser Testingを見ると、どういうサービスやツールが利用されているのかが分かる。
BrowserStackとSauceLabsは試しているところだけど、このどちらかを使えば良いか?というと、一長一短がある気がするので書いておく。
まだ調べ終わっていないので、後日追記するかも。

対応プラットフォーム数はBrowserStackが上

BrowserStackは、対応プラットフォームとブラウザが多い。Yosemiteの導入がすぐにされた記憶があるので、併用を考えた理由がそれかも。
Chrome Extensionを入れれば、見ているサイトをBrowserStackを使って確認しやすくなる。
OSのバージョンとブラウザとブラウザのバージョンの選択でアイコンを使っているのでわかりやすい。

余談だけど、他のブラウザというと、IEやChromeなどPCのものだけっていう先入観がある人もいると思うので、あえてiPhoneとAndroidも対応していることを強調したい。(SauceLabsも対応している)
スマホでGoogle検索するとスマホ対応というラベルが出るようになった。
接触媒体としてはもうPCよりもスマホやタブレットでしょうと思う。ターゲットや利用シーンにもよるけど、見落とさないようにしないといけない。

BrowserStackにはAutomateプランもあるので、CIをやる場合もBrowserStackだけ契約すれば良いようにも思う。
けど、Pricingを見ると、Automateは高い。
うーん。できれば一本化したいところなんだけど。微妙。

OSSは無料で使えるっぽいんだけど、どうやってやるのか調べてない。


CIはSauceLabsで、OSSならzuulも使う

SauceLabsは、BrowerStackに比べるとカジュアルにブラウザを起動するのにはUI的に向いていないし、むしろ使いにくい。対応プラットフォームとブラウザも必要な分はあるんだけど、Chrome ExtensionではWindowsのバージョンが選択できないし、AndroidはLinux、iOSはOSXの中に入っているなど、ちょっと作り込みが足りない。

SauceLabsはどちらかというと自動テストを専門としている感じ。
Pricingを見ると安いけど、プランごとに時間が決まっているのが気になる。
とりあえずCIを始めたいなら、SauceLabsの方が安いし気軽かな。
APIもあるし、自動化が捗りそう。
BrowserStackもAPIはもちろんある。

OSSでは無料で使えるらしく、時々Githubで.zuul.ymlを見かける。
やり方もWikiに書いてある
いずれお世話になるかもしれない。

2015年1月11日日曜日

Rustを習得したい

実は去年(2014年)の抱負だったのだけど、実践できなかったし、今年こそRust 1.0が出る予定なので、記事にして晒しておこうと思う。所謂新年の抱負です。


第二プログラミング言語候補

プログラミングが義務教育になるというのなら、プログラマーはプログラミング言語を少なくとも3つ以上は流暢に使えないといけないわけじゃない!!

冗談はさておき、時々、Rubyが苦手とする、もしくは得意としない分野を他の言語で解決したいという場面がある。
どういう時かというと、並列処理をしたい時(Rubyでもできるけど)と、 低レイヤーなこと、もしくは何かの拡張を書きたい時。

並列処理の場合、


DockyardはElixirで行くらしい

低レイヤーや何かの拡張やモジュールを書く場合、

  • C/C++
かな。
ものによるとけど、Apache/Nginx/DB/RubygemsでC拡張あたりが対象。
Luaも候補に入るのが普通なのかもしれないけど、何ができるのかはよくわかってない。結局Cとセットで使うのかな?って印象。mrubyもCを使える方が良い。ので、C/C++一択にしてる。


あと、処理系が入っていない環境向けの場合、

かな。環境によっては、Bash/Perl/Pythonでも良いと思うけど。


すごく漠然としてるけど。個人的にはそんな感じ。ちなみにフロントエンドでのJavaScriptはそれなりに使える。あれはもう共通言語なので除外。


Goも習得せねばとは感じている

Goブームの第2波のようなものが去年か一昨年くらいからあって、Go製のツールがちらほら出てきた。
Python/C++で書かれるものが、Goで書かれるようになったという印象。今話題のDockerやその周辺ツールもGo製。HerokuのCLIGithubのCLIもGoになりつつある(なった? Github CLIをGoに移行するIssue)

Goを読み書きできる方が幅が広がるし、ちょっとしたツールならGoで作ってしまう方が良いのかもしれない。


GoよりもRustが好きかも

Goをディスるつもりもないし、使わないつもりもないし、GoとRustを比較するのがそもそも間違いという点があるかもしれないけど、個人的にはRustの方が好きかもしれない。

Goの文法はシンプルでそれがいいんだ!というのも一理あると思う。
けど、Goを書いていて、引っかかる点がある。
なんとも言葉に言い表し難いんだけど、「ぱっと書いたコードだから綺麗にしたい(インデントとかではなく設計的に)」という時に、その方法がないというか、よく分からない。なるべくGoの文化に合わせておきたいけど、でもジェネリックとか使いたいじゃん、みたいな感じ...。ジェネリックはいずれ実装されるのかな。あと、ものすごくどうでもいいことだけど、「public = 大文字で始まる」というのがいただけない。Printlnとか。


読んでいて共感した記事:

パターンマッチを使いたい場面はある。知ってれば使いたくなるという場合に、Goにはそれがないというのが多いのかも。
個人的に、GoはPHPに似ていて、真剣にお付き合いするのではなく、時々会って良いとことダメなところを感じながら過ごす感じで接してるかもしれない。
別に嫌いでもないし、いいところもあるんだけど、合わない。そんな感じ。


なぜRustなのか

やっと本題

Rustを選ぶにあたって重視しているのは以下の点

  • 安全なプログラミング
  • 高水準言語のようなシステムプログラミング言語
  • パッケージ管理(Cargoとcrates.io)
  • FFI
  • 簡単に始められそう


安全なプログラミング

並列処理を書くときに、競合状態や、意図しないメモリの操作などは避けたい。とくに、Cで書く場合、ポインタという低レイヤな操作をすることがあるけど、これを間違うと非常に危ない。メモリのどの番地をさしているかのようなものなので、並列処理関係なく、間違った時点で他のクリティカルなデータが見えたりしては大変なので、基本的に触りたくない。(けど、Cでやる=ポインタは大概ついてくる)

C++にはスマートポインタというのがあるようで、うまく使えばそういうのは避けられるのかもしれないけど、C++って複雑そうっていう印象だけで避けて生きてきている。(すみません)

IPAのレースコンディションの一般的対策が解りやすいのだけど、ここに書いてある対策法の一つがアクセス権によるもので、RustはそれをOwnershipという仕組みので言語自体に取り入れている。
そしてさらに2つ大事な点があって、これがコンパイル時に厳格にチェックされるのでミスを未然にほとんど防げるということと、他の開発者が書いたコードもそのチェックがされているということ。C/C++で、何が怖いかというと、自分の書くコードもそうだけど、自分がよくわかってない場合に、他人のコードを取り込むこと。コンパイラが優秀なのはありがたい。ちなみにエラー文も解りやすいし親切。

とはいえ、Rustはシステムプログラミング言語なので、リスクのある危険なコードを許容するためにunsafeというのがある。区別されるだけでも個人的にはすごくありがたい。


高水準言語のようなシステムプログラミング言語

Rust by ExamplesHyperPencilを見ると分かるけど、HLLのような簡潔なコードを書ける。Brooksの生産性不変の法則が正しいのなら、記述量は少ない方が良い。


パッケージ管理

Bundlerのようなパッケージ管理がある言語の方がありがたい。RustにはCargoとそのセントラルレポジトリのcrates.ioがある。CargoがBundlerのようなもので、crates.ioはRubyでいうところのRubygems.org。Rustをインストールすると、Cargoも一緒にインストールされる。素晴らしい!

Goには公式のセントラルレポジトリにあたるものがなく、各ライブラリのダウンロード数は見れないし、検索もGo Searchという、公式なのか非公式なのかよく分からないbootstrapそのままのサイトでやるしかない。レートはgithub上のimportで読まれてる件数とリポジトリのstarの件数からなんだろうか。


FFI Rubyの拡張をRustでも書ける

実は、他のプログラミング言語を習得しようとしたきっかけが、「Rubyだと遅い > 高速化したい > 並列化したい > でもRubyも使いたい > C拡張 > C怖い」なので、この点はすごく大事。全て別言語でやるってのもいいんだけど、普段からRubyが良いし、Rubyに必要な分は自分で補えるようになりたいという個人的な強いこだわりがある。

もともと本来の目的だけど、今はそれほど必要に迫られていなくて試していない。
けど、参考になる情報があるのではっておく。

Goでも書けるのか調べた気がするんだけど、GoのFFIが微妙か、両方の言語にGCがあるのが良くないってのを見かけた気がして(情報元を忘れた)、やってないんだけど、今見たら、できなくはなさそう。改善したのかな?偏見だったのかも。(汗


簡単に始められそう

1.0が出て、日本語の情報も増えればの話だけど、インストールは簡単だし、実行も簡単。


Sublime textでRustの自動補完をしたい場合は、RustAutoCompleteを使うと良い。Rustのソースコードracerを入れる必要があるけど、インストール手順はそれぞれ書いてある。


1.0が出るまでは、言語の仕様変更がまだまだあるだろうし、crates.ioにあるライブラリが追いつくのもそれぞれ時差があるだろうから、標準ライブラリを使ってちょっとしたコードを書くところからやっていってる。
毎回rustcを叩くのは面倒なので、今はRubyのGuardでやっているけど、そのうちcargo-watchというのを入れてみようかなぁ。


Rustには、パターンマッチやジェネリックやら、モダンなプログラミング言語が持っている機能が最初から備わっている。
そういう点でも触れていて楽しい。
Borrow Checkerとはまだ仲良くなれていない。
HaskellやC++をやっていれば、すんなりできそうな知らない概念のようなものがあるように思うし、
それを公式のドキュメントで説明しているものはなさげ。なかなか敷居が高いようにも思う。
けど、1.0リリースまでにはなんとかそれなりにRustできるよ!って言えるようになりたい。


追記: 他のサンプルコード

coreutilsのRustの実装が参考になるかも。
前にwcの実装ってどうなってるんだろうと気になってソースを見てみたときに、Cのwcの実装を見て、機能の割にコードがたくさんでびっくりしたことがあったなぁ。Rustのwcは、コメントがほとんどないけど、1/3くらいかな。速度は測ったことがないけど、Cの方が速いんだろう。

2015年1月4日日曜日

ChefやAnsibleを使うときに気をつけておきたいこと

前の記事で、書きそびれていたので、続き。


主にチーム体制に関する内容で、Chef/Ansibleに関するノウハウではありません。


チームメンバーも触れるようにしておくこと

保守や引き継ぎの難易度を上げる要素の一つが、誰でも触れるのか?という点だと思う。
具体的に言うと、本番の環境とは切り離された、独立した開発環境があり、かつ、
複数人の人が操作方法を知っている、やったことがある、といったこと。

開発当初は直接サーバ上でやってたりして、環境が分かれていないケースがあったりすると思うし、
誰かの環境からでないとデプロイできない環境というのは割と 多いと思う。
けど、やがて煙が立って炎上していくというのは、多くの人が経験したり、させたりしてるんじゃないかな。

ChefやAnsibleでも、同じような話を聞くことが何度かあった。
おそらく共通しているのは、他に触れる人がいない脆弱なチーム体制なんだと思う。
インフラは任せっきりで、何がどうなっているか、その人が辞めて初めて、把握してないことに気がつく。
結構クリティカルだと思う。


やってみようという努力

じゃあ、それが誰のせいなのか?前任者?チーム?
自分はチームとその人の両方の責任だと思う。


実は、READMEを見れば、sandbox的な環境での試し方(Vagrantでとか)、
ServerSpecで期待通りになっているかの確認方法とか書いてあるのに、見落としているかもしれない。
その人がどういう性格や思考の人で、どういうスタイルでやってたか、だいたいわかってればこの辺はクリアできると思う。
わかっていなければ、コミュニケーションや情報共有不足というチームとその人との関わりに問題があったのだと思う。

この人がいなくなるとまずいという危機意識は健全だと思うので、
インフラをやらない人でも、Chef/Ansibleに興味を持つことは良いことだし、
時折、どうやっているか聞いたりすればいいんじゃないかな。
そこで、実は本番で直接やっているとか、その人にしか触れない環境があったりすれば、
それがリスクが高いということには気がつくだろうし、
後になればなるほど技術的負債になる可能性も高くなるかもしれない。


コミュニケーションしないと生まれないものがある


インフラに限ったことじゃないけど、継承されにくいものというのは、明文化ができてないのではないかと思う。
その人が個人事業主で一人でやってるのならいいけど、その人とともに失われるものが多いと、組織としてはまずいはず。
ソフトウェアは芸術作品のように完成して終わりということがほぼないため、保守開発という工程がある。
そういった場合に職人芸であっては困るはず。

なので、ドキュメントを書くのだけど...
ドキュメントを読んだ人はちゃんとフィードバックしているだろうか?
大人になると怒られるのは嫌だし、そもそもバカだなんて思われたくはないけど、
誰でもわかりやすいドキュメントを書けるとは限らないのだし、
良いドキュメントを書くスキルを身につようとしている途中かもしれない。

「ドキュメントは誰にでもわかりやすく」と漠然としたことを平気で言う人もいるけど、
「日本語を母国語として、中学校卒業レベルの学力を有する人」という人を前提に、
チーム内で読まれるべきドキュメントを書く人なんているだろうか?
そんな時間があるんだろうか?

チームのドキュメントはチーム内のメンバーが読んでフィードバックしないと良くならないと思う。
どこまで書くべきなのか、何か不足していないか、
ドキュメントの問題ではなくチーム内で勉強会をして底上げする方がいいんじゃないかなど、
チームのレベルに合ったドキュメント作りは、フィードバックと周りのサポートがあってこそできると思う。
それがなくてもドキュメントを書ける人がいるかもしれないけど見かけたことはない。
ドキュメントを読まなくても、できるケースはあるけど。


個人的に、ドキュメントは簡潔な方がありがたいので、少ない方が嬉しい。
そのために、省略できるものは省略すべき。
省略するためには、チーム全体の知識や経験を増やす必要が出てくる。
ので、誰でも触れる環境がある必要があるし、実際に触らせることも大事だと思う。
それが言いたかった!


次は、また書きたい欲が溜まればCSSについて書くかもしれない。