HTML5+α @福岡 feat. html5jえんぷら部レポート
HTML5+α @福岡 feat. html5jえんぷら部に行ってきた。
福岡でHTML5+α ＠福岡とhtml5jエンタープライズ部で合同勉強会を開催しました。
今回はハンズオン形式の勉強会を、次の３つのテーマで皆さんにyeomanを触ってもらいました。
- いろいろなgruntを使ってみよう
- いろいろなgeneratorを使ってみよう
- generatorを作ってみよう。
今回私が担当するのは「ggeneratorを作ってみよう。」と言うテーマです。
yeoman-generator
yeomanを使ったことがある方はご存知かもしれませんが、yeoman-generatorは、yoコマンド実行時に動作するモジュールです。
yoコマンドの本体とも言えます。
そんなyeoman-generatorが開発者に提供してくれる機能は、大きく分けて以下の２つです。
- generatorによる新規プロジェクトの生成
- subgeneratorによる、定型的なプロジェクトのメンテナンス。
generatorの作り方
今回はそんなyeoman-generatorが呼び出すgeneratorを、generator-generatorを使って作成しました。
最終的には次の3つの内容を持ち帰ってもらうような内容のハンズオンです。
- yoコマンドがどのようにgeneratorを認識するのか？
- generatorの作り方（質問とその質問内容に応じたテンプレートの作り方。）
- subgeneratorの作り方（テンプレートの連携と改変、generator用の環境変数の持ち方）
ハンズオンの資料は次のURLに公開しています。 https://github.com/MSakamaki/GeneratorAPI
今回はそんなテーマで、約4時間のハンズオンを行いました。
ハンズオン中の雰囲気はTogetterまとめを見てもらえれば。
感想
今回はゼロからgeneratorを作成しましたが、やはりゼロから作るのは大変です。
実際に運用する場合は、generatorの構築コストを考えると、既存でangular-generatorやbackbone-generatorなどの優秀なgeneratorが多数存在するので、そちらを使うことの方が多く、滅多な事では新規でgeneratorを作成することはないでしょう。
しかし、yeomanチームのblogにUse the new .extend() method instead of util.inherit と言う記事があります、 そこでは次のマイルストーンでは複数のgeneratorを連携させ、アプリケーションを構築出来るようにしたいとあります。 そうなれば、既存の優秀なgeneratorに、社内ルールのsubgeneratorを連携し、なるべく少ないコストで社内ルールに則ったプロジェクトの改修が容易にできるようになるのではないでしょうか？
GruntやBowerにスポットがあたりがちなyeomanですが、yoコマンドのsubgeneratorを使った定型的なプロジェクトの改変は、大規模開発や長期運用する上で個人的には凄くマッチすると思っています。
今回は時間の関係上mixinやテスト用ヘルパによるgeneratorの品質保持をテーマに含めることができなかったので、機会があれば、次回はそちらをやってみたいと思います。
リンク
FireFoxOSで使えるweb開発環境について
この記事はFirefox OS Advent Calendar 2013 16日目の記事です。
FireFoxOSでのアプリ開発環境
FirefoxOSアプリケーションを開発するにあてって、自分なりに色々まとめたり、実感できたこと
webアプリ？
FireFoxOSアプリケーションはWebアプリ！と言われるようにHTML+css+javascriptで作成する事ができる。
実際、Web、フロント系開発のスキルををもってるとスムーズに理解することができるし、 WebサイトやWebアプリケーションを少し弄るだけでFireFoxOSアプリとして再構築することができる。
しかし個人的には、「Webアプリ」で得られる最大のメリットは、日々進歩するweb開発環境の恩恵が直に受けれるという点がかなり大きいと思ってる。
yeoman
そんな思いを込めて、フロントエンド開発環境「yeoman」について12月16日にLTしたスライドを紹介 https://docs.google.com/presentation/d/14KGzc5hZHexiuWfZ2B2ZJjDIDGqvbp0rGXIXNsIB43w/edit?usp=sharing
ここのスライドのとおり、yeomanを使うことで、フォルダの構成や初期ファイル、そしてJSライブラリ依存関係解決などがほぼコマンド一発で行われるため、楽にアプリケーション開発をスタートできる。
さらにはGruntを使うことで、開発作業で必須のサーバ機動、テスト、デプロイがほぼ自動化できる。 （本来はgruntタスクは結構書き込まなければならないものだが、yoコマンドでほぼ自動生成される。）
generetor-firefoxos
yeomanもgruntもfirefoxos用のものが有り、使えばコマンド一発で環境構築とエミュレータへのデプロイ、マーケットアプリ登録用のzipまで作成できるようになる。
注意したいのはyeomanのfirefoxosジェネレータは
- generator-firefoxos
- generator-firefox-os
- generator-fxos
と、数種類確認できるが 個人的には一番多機能でありgrunt-firefoxosを内部に持つので「generator-firefoxos」テンプレートがおすすめ。
それでは良いFireFoxOSアプリ開発ライフを！
Table要素をレイアウト調整にしか使ってなかったエンプラエンジニアがW3CのTable仕様を読んでみた時の話
この記事は HTML5 Advent Calendar 2013 - Adventar の10日目の記事です。
Table要素をレイアウト調整の目的以外で使ったことがなかった自分だったのですが。
先日参加させてもらったHTML5マークアップカフェ(HTML5Expertの記事)でちゃんとTable要素の仕様を読んでみると、こいつが本当はすごいできる子だということに気が付かされたので、拙い英語力を使いW3Cの仕様書をがんばって翻訳しながら色々調べてみた。
そのテーブルがデータなのか？レイアウトなのか？
読み始めて、いきなりこれである。
Tables should not be used as layout aids.
テーブルをレイアウト目的で使うべきではありません。
去年まで<div>、<table>、<br>だけで作られた画面レイアウトを量産していた自分としては、この一文が本当に重くのしかかる・・・
続けて読んでみると、レイアウトか非レイアウトかを明示したい場合はこんな感じで属性をみて判断できるかもしれないよ～という表が
レイアウト目的 かもしれない Table要素の判断方法
- role="presentation"が指定されているとき
- border属性にゼロが設定されて、属性が非準拠になっているとき
- cellspacing属性にゼロが設定されて、属性が非準拠になっているとき
- cellpadding属性にゼロが設定されて、属性が非準拠になっているとき
レイアウト目的ではない かもしれない Table要素の判断方法
- captionが使われているとき
- theadが使われているとき
- thが使われているとき
- headersとscopeの組み合わせが使われているとき
- border属性 にゼロ以外が指定されたとき
- CSSを使い明示的に枠(borders)を可視化しているとき
上記はあくまで目安なんで間違ってる可能性があるよー、とも記載されているが、今後マークアップする上で、こういった事を心がけておくのは大事なんだろうなと思う。
いや、そもそも上で言ってるようにTable要素でレイアウトするなという話になるか・・・
borderの値の謎
そして読んでて一瞬だけ「？」となったborder属性の項
上のほうの説明に
The border attribute may be specified on a table element to explicitly indicate that the table element is not being used for layout purposes. If specified, the attribute's value must either be the empty string or the value "1".
border属性はTable要素に指定できます。 そのTable要素がレイアウト目的で使われているかどうかを明示することが可能です。属性の値は空文字 か "1"でなければいけません。
そして下に
he use of the border attribute with the non-conforming value 0 |Probably a layout table
( border属性にゼロが設定されて、属性が非準拠になっているとき | レイアウトを目的としたテーブルかもしれない )
The use of the border attribute with a value other than 0 | Probably a non-layout table
(borderの属性にゼロ以外の値を持つ | レイアウトを目的としてないテーブルかもしれない )
説明では 空白か"1"で、とあるのに、見分けるための指標ではゼロかゼロ以外かで書いてあるのでここで小一時間悩んでしまった・・・
空白も1も両方非レイアウト扱いになるんじゃなかろうかと迷ったのだが
- 推奨されるマークアップはborder要素を空白か"1"で。
- 一概に空白か"1"では（過去の資産もあり）判断できないので、border属性が非適合なのかどうかで見よう。
と言う事だろうか？
英語力が足りない自分の翻訳不足なのか、目安なので深く考えずにおくのが正解なのか・・・
w3c/web-platform-tests
ちょっとTable要素が理解できたので、Test the Web ForwardにTableのテストケースを何かしら投稿してみた。
コミットしてもらえるようなテストケースが良く判らないので tr要素のrowIndexのテストケースをコピーして、sectionRowIndexのテストケースを作る。
コピー元のテストケースでは何故かHTMLではなくJavaScriptで生成したタグ要素に対してのテストケースしか行われておらず不思議に思うも、 やらないよりはやった方がいいよね！と、HTMLタグの場合も含めたテストケースも追加して作ってみた。
で、動かしてみるとテストケースが真っ赤に・・・
どうやらjavascriptで生成したところは問題なく動作するようだがHTML要素の同じケースのテストで落ちまくってしまっている。
調べてみると、HTMLソースでは、こう書いた場合
<table> <tr> <th></tr> <td></td> </tr> <table>
ブラウザ開発ツールのElement (FireFoxだとインスペクタ)で見るとtbody要素が勝手に補完されている。
<table> <tbody> <tr> <th></tr> <td></td> </tr> </tbody> <table>
FireFoxもChoromeも同様の動作をするようで、どこかにそういった仕様があるのだろうか？（ちょっと見つけきれなかった）。
軽く読んで触っただけで、これだけ色々見つけることができたHTML5マークアップの世界、本当これからも色々試したり調べててみたいもの。
時間があれば、次は同じTable要素のScope属性を見てみたい。
明日はyoshiki katoさん！バトンよ続け！
