タグ

ブックマーク / qiita.com/cognitom (5)

  • そろそろ真面目に、HTMLで帳票を描く話をしようか - Qiita

    帳票といえばPDFとして生成するのが一般的でしょうか? でも、2015年の今、あえてHTMLで描くのがホットです(個人的に)。ミリ単位で設定された高度な帳票も、CSSを駆使して簡単に作ることができます。業務システムでもモダンブラウザを選択することが増え、@pageなども積極的に使えるようになったこと、SPA(Single Page Application)の台頭、いろいろと条件が揃ってきました。 書いてたら結構長くなっちゃったので、さくっとコードだけ見たい方は、Paper CSSリポジトリをどうぞ。 はじめに HTML帳票のメリット 2015年現在、HTML帳票を選択する幾つかのメリットがあります。 ライブリロードで、リアルタイムなスタイル調整 バックエンドではなくフロントエンドで生成できる 前者は、gulpやGruntの普及で、CSSにしろHTMLにしろ、リアルタイムにプレビューできる環

    そろそろ真面目に、HTMLで帳票を描く話をしようか - Qiita
  • Riot.js ソースコード完全解説 v3対応版 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昨年「Riot.js ソースコード完全解説」を書いたのですが、この1年でいろいろ状況が変わってしまいました。v2の間に相当コードが書き換わり、Riotも若干ぽっちゃり系に...(他の同種のライブラリに比べれば可愛いものですが)。そんな中、朗報です。近日v3がリリースされ、コードが整理されます。 参考: v3のロードマップ 稿では、改めて「ソースコード解説」を試みたいと思います。 2016年7月現在 でnextブランチにあるコードをもとに説明するので、日々変わってしまうけど、ご参考まで。オススメのコースは、次の通り。 この記事に目を通し

    Riot.js ソースコード完全解説 v3対応版 - Qiita
  • Seleniumアレルギーのための処方箋 - Qiita

    何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先

    Seleniumアレルギーのための処方箋 - Qiita
  • ブラウザテストツール総まとめ・2016年夏版 - Qiita

    WebサイトやWebアプリケーションの文脈(フロント寄り)で、E2E関連ツールを整理してみます。いろいろありすぎるようでいて、「結局Seleniumかよっ」ていう話ですが...。ただ、クロスブラウザテストが不要であればNightmareは簡便な選択肢としてオススメです。個人的な見解はまとめ参照。 (当初『E2Eは「End to end」の略ですよ。まとめ』と題したのですが、「E2E」という用語がそれほど浸透していない?ようなので、改題しました) 以下、目次を兼ねて並べてみました。E2Eの文脈でないものも一部含みますが、全体像を把握するために入れてあります。変なところあれば、コメントでご指摘くださいませ。 E2Eテストツール | 使っているもの | 開発言語 | GitHub★ :-- | :--: | :--: | --: | --: Nightwatch | WebDriver | Ja

    ブラウザテストツール総まとめ・2016年夏版 - Qiita
  • デザインワークをGitに含めるべき? 含めないべき? - Qiita

    Gitに限らず、バージョン管理システムで、コンパイルされたバイナリや、自動生成されたスクリプトを含めないというのは、プログラマの間では通念になっていると思います。それでは、デザインワークは? というとあまり扱いが統一されていません。 | コンパイル後のファイル | ソースファイル :--: | :--: | :--: ソースコード | 含めない | 含める デザインワーク | ? | ? デザインワークもコンパイルが当たり前に 従来、手作業でアプリケーションからエクスポートして、リポジトリに入れていましたが、現在その必要はほぼなくなりました。まだこの1,2年の話ですが、デザインワークでも「ソース」になる.sketchや.psdファイルから成果物を自動生成(コンパイル)するのが一般的になりつつあります。 面倒なスライスの切り出しといった作業は、もう過去の話です。一度ツールを設定してしまえば、

    デザインワークをGitに含めるべき? 含めないべき? - Qiita
  • 1