昨年あたりから、Macやめたい病を患っていたのですが、2度の故障を経て、重たい腰を上げました。別にWindows使いたいわけもなく「ローカルが煩わしい」だけなので、Windowsアプリは一切インストールしていません。で、どうやって暮らしてるの? というお話です。 TL;DR このあたり↓を組み合わせていけば、クラウド生活可能: GCP (or AWS) Codeanywhere (or Koding or Cloud9) VPCネットワーク + VPN (IPsec+L2TP) + DNS Figmaほか、Webサービス各種 追記・この記事を書いていたら、AWS Cloud9が発表されました。選択肢が増えて何よりです。 はじめに 本稿は、筆者が「Mac断ち」あるいは「ローカルマシンから解脱(げだつ)」する過程で見えてきた、ベスト(かも)プラクティス集に近いものです。 よく使うテキストエディ

「めんどくさそう」先入観で敬遠していたのですが、仕様を見たらそんなでもなかったので書き残しておきます。手っ取り早くコードを見たい方はこちらをどうぞ。 ユーザとして、ソースマップに接する機会は多いですが、AltJSを作るとかでもない限り、あまり提供側に回ることはないかもしれません。私自身、次のような疑問というか誤解を抱えたまま、深入りしなかったクチです...。 誤解1: ソースマップを作るにはASTを作る必要がある → 実際はもっとシンプル 誤解2: なんかすごいエンコード(AAAA;AACA;AACA;AACA...)がされてる → ただのBase64 よく見かけるソースマップの説明記事(というほど、記事自体ないけれど)では、「ソースを構文解析してASTを構築して...」という手順が出てくるのですが、 ソースマップにASTは必要ありません。 もちろん、実際にAltJSを作るならASTの作成

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

GitHubのスターは2016年7月30日調べ。ただし、登場年によるバイアスが激しいので、この件に関してはあまり参考にならないですね...。 E2Eテストツール Nightwatch 総合的なE2Eテストツール。WebDriver実装(独自)と、アサーションライブラリが一体となっているのが、使いやすいような使いにくいような。 http://nightwatchjs.org/ https://github.com/nightwatchjs/nightwatch 書き方はこんな感じ。 module.exports = { 'Demo test Google' : function (client) { client .url('http://www.google.com') .waitForElementVisible('body', 1000) .assert.title('Google')

近年、JavaScriptでコードを書こうとすると、お膳立て7割、コード書き3割みたいな事態がざらにあります。「お膳立て」の例としては、Gulp, Babel, Sass, PostCSS, WebPack, Rollup, Browserifyほか数限りなく。 たしかに、一旦フロントエンド開発に慣れてしまえば、お膳立てにかける時間は短縮することが可能です。でも、これを初学者に強いるのはツラすぎる...! 覚える方はともかく、 教える側がツライ。 今回、未来なJavaScriptやCSSの文法で書いても、よしなにとりなしてくれるWebサーバ「Felt」を作ったので、ご査収ください。 (2016/7/19 関連ツールとの比較を追記しました) GitHub: https://github.com/cognitom/felt npm: https://www.npmjs.com/package/

npmはJavaScriptのパッケージマネージャです(今更感)。依存するライブラリはpackage.jsonに登録されていき、npm installだけで必要なライブラリが読み込まれます。と書くとシンプルな話ですが、実は結構奥が深いのです。そんなnpmのdependencies5種類、ちゃんと使い分けしてますか? 本稿では、順番に見ていきたいと思います。(npmのドキュメントも見てね) dependencies devDependencies peerDependencies optionalDependencies bundledDependencies

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