はてなブックマーク

2016-09-21 にあるとおり bouzuya/rally-client-example-vuejs で Vue.js 2.0.0-rc.6 を試している。 いろいろ問題はあったのだけど、一番の問題は何も考えずに import * as Vue from 'vue'; とすると HTML を template として扱ってくれない点だった。解決策は @ktsn が教えてくれた。 @bouzuya @kazu_pon この辺の話ではないですか？runtime build だと html のコンパイルはできないです。 https://t.co/zAynOoLKOq— katashin (@ktsn) September 22, 2016 template string を render function に変換する compiler が 2.0 からは分離されているようだ。standalo

bouzuya/whatwg-streams-fns および bouzuya/whatwg-streams-b をつくった。つくっている。 bouzuya/whatwg-streams-fns は WHATWG Streams 向けの utility library 。map や filter などの RxJS / xstream などにありそうな operator を提供する。ReadableStream や TransformStream などを生成する factory になるはず。まだ個数が不足しているのと RxJS などとは Model が違う点を考慮して増やさないといけない。 bouzuya/whatwg-streams-b は非公式な WHATWG Streams 実装。参考実装を勝手に npm package として公開したもの。whatwg-streams-fns をつくる

@hiroqn が書いた『実例とともに学ぶECMAScript 2015 〜Generator〜 – NET BIZ DIV. TECH BLOG 』を TypeScript で写経して Generator について学んだ。 関連 Tweet は次のとおり。 良記事 / “実例とともに学ぶECMAScript 2015 〜Generator〜 – NET BIZ DIV. TECH BLOG” https://t.co/UUPy4Byahe— bouzuya (@bouzuya) 2016年6月17日 https://t.co/o1QzLNXVzZ を写経 & 問題を解いた。TypeScript だと問題のある記述がぱらぱらとあった。ぼくの解答は↓。https://t.co/srBiykQeOG— bouzuya (@bouzuya) 2016年6月19日 結果の Gist は https

bouzuya/beater 0.4.1 をつくった。 bouzuya/beater#7 で Node.js v4 で動かないという Issue が来たので対応した。次のように version を上げた。 bouzuya/beater -> 0.4.1 bouzuya/beater-cli -> 0.2.4 bouzuya/beater-cli-reporter -> 0.4.2 bouzuya/beater-html-reporter -> 0.1.1 bouzuya/beater-reporter -> 0.3.0 実装としては TypeScript -> Babel の多段変換にした。以前この多段変換をやめたという記事を 2016-03-15 に書いた。今回はその逆だ。以前より TypeScript の経験値が上がったからか、心の余裕があったからか、逆に多段変換を選択した。 Type

2016-03-11 に bouzuya/rally-rxjs へ適用した TypeScript -> Babel の多段構成の回避方法を書く。具体的には、型定義として ES2015 (ES6) を使いながら target を es5 にすることで回避した。当該 commit は bouzuya/rally-rxjs#47ff4ca6d5c673e14275f3fa5bf7579d08b71465 。 2016-03-14 に書いたとおり、ぼくは typescript & babel 構成で苦労していた。 こうなった理由は TypeScript にある。 TypeScript の compiler option を target: es5 にすると、Promise の型定義が見つからず compile できない TypeScript の compiler option を target:

hubot-ping をつくった。1 日 1 Hubot スクリプトの 89 日目。 hubot-ping は外部からの ping に応答するための URL を提供する Hubot スクリプト。 これをつくった理由は、最近の Heroku にデプロイしている Hubot が idling するようになり、外部から ping を打つ必要が出てきて、そのための 200 OK を返す URL が必要になったから。 Heroku の idling 自体は以前から有名な問題で、Hubot を Heroku にデプロイした場合のあるあるのひとつと言っていい。従来の対応方法としては「環境変数 HEROKU_URL を設定する」のが正解だった。これは Hubot 本体が提供している Heroku の idling 問題への解決策である。この設定をすると 20 分ごとに Hubot が自分自身に ping

GitHub + Travis CI + Amazon S3 で git push で更新されるサイトをつくったので、その手順をメモ。 前提条件 GitHub のアカウントを持っている GitHub にリポジトリを持っている (例では bouzuya/bouzuya.net を使う) GitHub にリポジトリは Node.js のパッケージである (ルートにpackage.jsonがある) Travis CI のアカウントを持っている Travis CI の CLI をインストールしている (gem install travis) AWS のアカウントを持っている 概要 実現したい動きは次のとおり GitHub のリポジトリに git push origin master する Travis CI がリポジトリの更新を検知し Amazon S3 にデプロイ Amazon S3 にホストさ

最近はWIP(work in progress)ブランチをGitHubにPull Requestするようにしている。 GitHubのPull Requstの仕様としてブランチ名で追跡している(?)ので、後からブランチにコミットを追加してもきちんとPull Requestページにも追加されるし、git rebaseなどでコミットをひとつにまとめても問題ない。 そこで作業中(WIP)のブランチをとりあえずPull Requestするのがこのやりかた。 Pull Requestを作業完了してから実施すると、途中で指摘すれば修正できたけど作りきってしまったものをいまさら修正できないといった状況になることがある。コーディングに限らず、一般的な話としても、作業前や作業中に進捗を報告したほうが良いのと同じ理屈で、作業中のものでもPull Requestしておけば、それが見える可能性が増える、と。 例を書