次バージョンを決めた
自作ソフトの現バージョンは 0.3 なのだけれど次バージョンは 1.1 に決めた。
メジャーバージョンを 0.X から 1.X に上げているのは大きな機能がたくさん増えるため。
なぜ 1.0 ではなく 1.1 なのかというと 1.0 だとユーザに初公開と勘違いされるかもしれないから。初公開ではなくバージョンアップですよーというのがユーザに伝わるメリットは３つ。
- メンテナンスしてるよーというのが伝わる
- ユーザがたくさんいるからバージョンアップしたと思ってくれるかもしれない
- 個人的に更新履歴を見るのって楽しい（私だけ？
Firefox 32.0 リリースノート
まったく関係ないけどブラウザって結構な速度で JavaScript や CSS の標準規格への準拠を進めてるなーと思った。
バージョン番号に最終更新日を含めるべきか？
自作ソフトの現バージョンは 0.3 と 0.3.20140712 の２つともを正式なバージョンとしている。
他のサイト様に紹介いただいてソフト一覧に並ぶことがあると思いますが、このとき紹介いただくサイト様ごとにデザインが違い最終更新日があるサイトもないサイトもありますよね。そんなときにこんな感じで適切に使い分けてくれたらなーという思いをこめたからです。
最終更新日の記載があるサイト
| ソフト名 | バージョン | 最終更新日 |
|---|---|---|
| ソフト | v1.0 | 2014/xx/xx |
| 私のソフト | v0.3 | 2014/07/12 |
| ソフト | v1.0 | 2014/xx/xx |
最終更新日の記載がないサイト
| ソフト名 | バージョン |
|---|---|
| ソフト | v1.0 |
| 私のソフト | v0.3.20140712 |
| ソフト | v1.0 |
・・・なのですがコノザマダヨ
動作環境をわかりやすくするためのバージョン番号
最近では OS に限らずブラウザや IDE などにサードパーティ製のソフトウェアやアドオン、プラグインなどが増えてきました。
しかしソフトウェアの動作元のバージョンアップでソフトウェアが動かなくなることもあるので動作環境を明らかにすることは重要です。そのとき動作元が（あまり頻繁に数字が増えないような）メジャーバージョン番号をユーザにわかりやすく周知させているとよいです。
なぜかというと Windows OS のようにバージョンごとに異なる名前が振られていると動作環境の記述が冗長になるからです。以下の例は同じ動作環境の2種類の書き方です。
わかりやすいが冗長 動作環境: Windows Vista, Windows 7, Windows 8 以上 簡潔だが例えば Windows 8 ユーザには動作するかどうかが知識がないとわからない 動作環境: Windows Vista 以上
バージョンアップごとに無機質な数字ではなく名前を振りたくなる気持ちもわかりますが、メジャーバージョン番号を周知させてください。
インライン SVG がうまく表示されない
インライン SVG というのは HTML に直接記述できる SVG です。こんな感じ。
<body> <svg> <path /> </svg> </body>
そのインライン SVG が HTML 圧縮ツールのせいでうまく表示されませんでした。というのも input タグのような閉じタグのないタグは HTML ではスラッシュがいりません（あってもよい）。そのため HTML 圧縮ツールは文字数を減らすためスラッシュを消していました。
しかし SVG は XML であり XML はスラッシュが必須です。 HTML 圧縮ツールが SVG のスラッシュを消していてうまく表示されなかったのです。
対応策
プリミティブ型や構造体の FirstOrDefault
とてもよい本でした。
C#ショートコードプログラミング第2版 【▲→川俣晶の縁側→技術関連執筆情報】
この本に null 許容型を使えばプリミティブ型のデフォルトと区別をつけられるよーって書いてありました。
var v = (new int?[] { 1, 2, 3 }).FirstOrDefault(p => p == 0); if(v == null) { } else { // v にごにょ }
そんな都合よく null 許容型に変えられるわけないでしょ（笑
どちらも一長一短ありますが私ならこうします。
var v = (new int[] { 1, 2, 3 }).Where(p => p == 0); if(v.Count() == 0) { } else { // v.First() にごにょ }
LINQ というか関数型大好きマンになってしまった。もう少し純粋度の高い関数型で大きなプログラム書きたい。
gulp-slim が日本語を含むファイルのコンパイルに失敗する
結論から書くと、私の環境は Windows で gulp-slim は Slim のコンパイルに Ruby 実装を使っていた。 Windows で Ruby を使うときの文字コードの問題で失敗していたようだ。
環境変数 RUBYOPT に -EUTF-8 を設定すれば成功する。
WindowsでEncoding.default_externalをUTF-8にするには - すがブロ
gulp-slim がエラーメッセージを握りつぶしていたことと、 Node.js 上で走る gulp-slim を表面的に使っている限りは Ruby が走っているなど知るところではないので原因の特定に時間がかかった。
Ruby 書くのではなく使う人にこの手の問題を意識させないで欲しいよね。
Stylus ではまった点
CSS プリプロセッサというと Sass と Less の２強という感じですが Stylus もおすすめですよ。
Stylus は文法も覚えやすく１日もあれば使いこなせますが２点だけはまったのでメモ。
割り算をするときはかっこでくくる
margin (500px / 3)
font プロパティや border-radius プロパティなどは CSS でも / を使うプロパティがあるのでそれと区別をつけるためでしょう。
calc() 関数の中の変数は展開されないので % 演算子でフォーマットする
container-margin = 500px margin 'calc(%s / 3)' % container-margin
Bug when using CSS calc function · Issue #687 · LearnBoost/stylus · GitHub
ここに書いてありました。
