Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

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

  • Seleniumアレルギーのための処方箋 - Qiita

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

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

    昨年「Riot.js ソースコード完全解説」を書いたのですが、この1年でいろいろ状況が変わってしまいました。v2の間に相当コードが書き換わり、Riotも若干ぽっちゃり系に...(他の同種のライブラリに比べれば可愛いものですが)。そんな中、朗報です。近日v3がリリースされ、コードが整理されます。 参考: v3のロードマップ 稿では、改めて「ソースコード解説」を試みたいと思います。 2016年7月現在 でnextブランチにあるコードをもとに説明するので、日々変わってしまうけど、ご参考まで。オススメのコースは、次の通り。 この記事に目を通して全体像をつかむ 自力でソースコードを斜め読みし、もうちょっと深く理解する プルリクエストしたい部分について、深読みする がしがしプルリクエスト スクリプトのimport/export関係をざっくり図示してみました。以下にも主要ファイルを挙げておきます。 公

    Riot.js ソースコード完全解説 v3対応版 - Qiita
  • ブラウザテストツール総まとめ・2016年夏版 - Qiita

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

    ブラウザテストツール総まとめ・2016年夏版 - Qiita
  • そろそろ真面目に、HTMLで帳票を描く話をしようか - Qiita

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

    そろそろ真面目に、HTMLで帳票を描く話をしようか - Qiita
    ji_ku
    ji_ku 2015/10/14
  • 無謀にもJavaScriptなしでやってみる! Riot.js入門 - Qiita

    このチュートリアルでは簡単なWebページをRiot.jsで作ってみようと思います。読むのに必要な知識は、次の二つだけ。 HTML CSS 逆に不要な知識は、 JavaScript: AngularとかReactとか CSSの方法論: BEMとかSMACSSとか など。ただ、上記を把握していると、より「Riot.jsすげー」ってなるかも、なってほしいな。 Riot.jsを使うにあたって、モック作成や、静的ページだけなら、JavaScriptを書く必要はそれほどありません。このチュートリアルを通じて、次の2つのポイントを伝えられればと思います。 デザイン先行で作成ができる (開発後回し可能) HTML+CSSだけでもコンポーネントが作成できる Riot.jsとは 近年、AngularJSやReact、Backbone.jsなど、さまざまなJavaScriptフレームワークの名前を聞く機会が増え

    無謀にもJavaScriptなしでやってみる! Riot.js入門 - Qiita
  • Riot.js 2.0 を触ってみた — まだReactで消耗しているの? - Qiita

    楽すぎてどうしよう。が最初の感触。まだ3時間しか触ってないけど、もうこれでいいや感が半端ない、深夜2時です。 Angularなのか、Reactなのか、2015年が明けても毎週のように新しいJSフレームワークが出る中で、もう正直どうでもよくなってませんか? でも、これは触って楽しいはず。 Riotって何? Riotは、公式ページに A REACT- LIKE, 2.5KB USER INTERFACE LIBRARY とあるように、Reactを意識して作られた超軽量のUIライブラリで、ビュー部分(コンポーネント)に特化しているのが特長です。Vue.jsとかとも同類です。Riot 1.0も「超軽量」という点で、一時注目を集めました。 そのRiotが、2.0で趣向を変えてJSX的なプリコンパイルの仕組みを取り入れて、ReactとPolymerのいいとこ取りのような感じになっています。ただし、次の

    Riot.js 2.0 を触ってみた — まだReactで消耗しているの? - Qiita
  • Riot.js ソースコード完全解説 - Qiita

    追記・「Riot.js ソースコード完全解説 v3対応版」を公開しました。(2016/7/26) 2.0.7時点のコードを読みます。 Qiitaの記事としては、ボリューム感に溢れてますが、ひとつのライブラリとしては驚異的に短いです。各所で指摘されているように、結構サボった実装になっています。ただ、なんだかそれを指摘するのすら野暮という感じの、単純なロジックなので、優しい気持ちでぜひ。 読み解くにあたり、いくつか特徴を挙げておきます。 正規表現を多用する (かなりイージー) DOMのパースはinnerHTML頼り CoffeeScriptやJadeなどのコンパイラは含まない それ以外のライブラリ依存なし セミコロンが嫌いらしい Riot.jsは6つのスクリプトに分かれていますが、★印の3つが基的な部分です。この記事でも、この3つのみを扱います。 | ファイル | 機能 :-- | :--

    Riot.js ソースコード完全解説 - Qiita
  • Riot.js 2.2 情報まとめ - Qiita

    Riot.js 2.2 情報まとめ とりあえず、気付いたものをメモしていきます。随時更新。 家 公式ドキュメント(英語) 公式ドキュメント(日語) GitHub リポジトリ From React to Riot 2.0 - 背景説明のブログ記事 Gitter 公式フォーラム サンプル集(準備中) 開発情報 インストール riotはツールごとにリポジトリが分かれていません。 ブラウザ用のライブラリ コンパイラ CLIツール の3つが一緒くたになっています。各人のスタイルに合わせて、インストールしましょう。(追記・次のv2.3に向けて、サブモジュール化が進んでいます) ライブラリとして CDNから最新版。他のパターンはこちら。 コンパイラなし: https://cdn.jsdelivr.net/riot/2.2/riot.min.js コンパイラあり: https://cdn.jsdeli

    Riot.js 2.2 情報まとめ - Qiita
  • デザインワークをGitに含めるべき? 含めないべき? - Qiita

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

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