Object.observe の死 (ECMAScript の提案取り下げ、V8 からも削除予定)
1年前の記事 JavaScript フレームワークがデータバインディングを実現する４通りの手法 では、Object.observe() について次のように説明した。 JavaScript オブジェクトが変更されたときにコールバックを呼んでくれる API データバインディングの実装が簡単になる Google Chrome には実装済み ECMAScript 7 に提案中 提案が通れば MV* フレームワークの実装がシンプルになってハッピー 将来を期待されていた Object.observe() であったが、2015 年 11 月頭、ES Discuss メーリングリストへの An update on Object.observe という投稿で、ECMAScript からの提案が取り下げられて、V8 エンジンからも年内に削除される予定であることが表明された。 Object.observe()
Vue.js が data に渡した値を激しく書き換える件について
最近、JavaScript の MV* フレームワークの中で Vue.js が少しずつ注目を浴びてきているようであります。 5分でわかるVue.jsと、jQueryで頑張ってはいけない理由 | 株式会社インフィニットループ技術ブログ Vue.jsから手軽に始めるJavaScriptフレームワーク - Qiita 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog そんなわけで、自分も Vue.js (v0.10.5) を触ってみたのですが、data で渡した値を激しく書き換えるところに面食らったので記事にしておきます。 自作クラスのオブジェクトを Vue.js に渡すと壊される 何らかのビジネスロジックを持ったモデルを作って、それを Vue.js のデータバインディングで HTML に反映しようすると破綻します。 簡単な例として、よくあ
Windows の Jenkins で JENKINS_HOME を別のフォルダーに変更する方法
Jenkins を Windows 環境に MSI ファイルで導入すると、デフォルトでは C:\Program Files (x86) にインストールされる (64 ビットの場合)。 Java の実行環境を同梱してくれていたり、自動でサービスに登録してくれたりして嬉しいのだけど、気になるのが JENKINS_HOME が C:\Program Files (x86)\Jenkins になってしまう点。ジョブやワークスペース、プラグインなどのデータなどが Program Files の下に置かれてしまう。Windows 的な作法では「アプリケーションのデータは ProgramData や AppData に置きましょう」となっているので少し気持ち悪い。 JENKINS_HOME を変更するには環境変数を設定したらいけそうなんだけど、MSI から導入した場合は環境変数ではなく jenkins.
Vagrant で作ったり壊したりできる Windows 環境を手に入れるまでの手順
最近話題の Vagrant さんは「Linux の環境を作ったり壊したりして開発とか試験が楽になるよ」と紹介されることが多いけど、Windows の環境だって作ったり壊したりしたい！ いろいろ調べつつ環境を作ってみたので、その手順を共有しておく。 完成イメージはこんな感じ。コマンドプロンプトから vagrant up をしたら VirtualBox 上に Windows Server 2012 R2 の環境が準備されて、そこにリモート デスクトップで接続している。 いろいろいじったあとに vagrant destroy したら環境は消え去って、vagrant up したら、また、まっさらな状態から使える。 ちょっと注目してほしいのは、ゲスト OS の C:\vagrant にホスト側の Vagrantfile がマウントされているところ。このあたりの処理は Vagrant-Windows
Windows で Chef するときに PATH で混乱しないように専用のコンソールを作った
話題の Chef をいまさら試したくなって、手元の Windows 環境に環境を作ってみた。 http://www.getchef.com/chef/install/ からインストーラーをダウンロードしてインストールした。Cygwin を使うと無駄にはまるし、ぐぐるといっぱい出てくる「gem から入れる手順」は公式サイトでは見つからなくなっている。 すべてデフォルトでインストールすると、C:\opscode\chef にファイルがいっぱい展開されていた。 PATH に追加される 2 つのフォルダー インストーラーから Chef を入れると、PATH に C:\opscode\chef\bin C:\opscode\chef\embedded\bin の 2 つが追加される。 C:\opscode\chef\bin には Chef 関係のプログラム (chef-solo, knife など.
K-means 法を D3.js でビジュアライズしてみた
クラスタリングの定番アルゴリズム K-means 法（K平均法）の動作原理を理解するために、D3.js を使って可視化してみました。 図をクリックするか [ステップ] ボタンを押すと、1ステップずつ処理を行います [最初から] ボタンを押すと、最初の状態に戻ります [新規作成] ボタンを押すと、N (ノード数) と K (クラスタ数) の値で新しく初期化します 古いブラウザーではうまく表示できない可能性があります (IE 10、Firefox 25、Chrome 30 で動作確認しています) K-Means 法とは 英語版 Wikipedia の k-means clustering - Wikipedia, the free encyclopedia の手順に沿って実装しています。 英語版の手順をザックリと書くとこんなイメージになります。 初期化: N 個のノード (丸印) と K 個の
Node.js の fs.watch() と fs.watchFile() の違い
Node.js のファイル監視の API には fs.watch() と fs.watchFile() の 2 つがある。 微妙に機能がかぶっているし、使い分けが分かりにくかったので調べてみた。 公式情報を見る まずは公式のドキュメント (v0.8.0)を見てみた。 fs.watchFile(filename, [options], listener) Stability: 2 - Unstable. Use fs.watch instead, if available. Watch for changes on filename. fs.watch(filename, [options], [listener]) Stability: 2 - Unstable. Not available on all platforms. Watch for changes on filename,
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
Node.js 0.12 では yield が使えるのでコールバック地獄にサヨナラできる話
Node.js の次のメジャーバージョン 0.12 で yield が使えるようになります。 そのおかげで、JavaScript のコールバック地獄に光が差し込むのです。ああ、さようなら、コールバック地獄。 7 年ごしで実現した yield 2006 年、Firefox 2 のリリースと同時に yield は JavaScript 界に登場しました。随分と前の話ですね。 登場した当時は JavaScript 界隈でけっこう話題になっていました。 JavaScript 1.7 の yield が凄すぎる件について - IT戦記 Latest topics > JavaScript 1.7のyield文ってなんじゃらほ - outsider reflex JavaScript 1.7 の新機能: Days on the Moon 登場したときにはインパクト大きかったものの、結局 Firefox
git commit --amend を省力化する方法
Git で最後のコミットを修正するときには git commit --amend を使うんだけども、いままでは git add . git commit --amend エディターが立ち上がって、前回のコミット メッセージが表示される エディターを終了させる としていた。 この作業は何度も繰り返すと面倒だったので、man を調べてみると --no-edit なるステキなオプションを発見した。 --no-edit を使う --no-edit を指定すると、上の手順はこうなる。 git add . git commit --amend --no-edit コミット メッセージはそのままに、コミットの中身だけを書き換えられる。エディターが立ち上がらないので楽チン。 -a でさらに省力化 さらに git add . も省力化できて とすればよい。 コマンド一発になった。超楽チン。 注意点は次の 2
Google Chrome で超手軽にスマホ向けデザインを確認する方法
最近、Google Chrome のデベロッパー ツールにスマートフォンでの表示を確認する機能があることを知りました。 いままでは、レスポンシブデザイン Web デザインをするときに、ちまちまとブラウザーのサイズを変えたり、Web サービス (Responsive Design Testing とか Responsive Web Design Test Tool とか) を使っていたのですが、こちらの手順のほうがお手軽なので紹介します。 設定は超簡単！！ Google Chrome のデベロッパー ツールを開いて、右下の歯車のアイコンをクリックします。 左側から [Overrides] を選んで、[User Agent] と [Device metrics] にチェックを入れます。 これだけです！ Google Chrome 32 からは設定方法が変わっています。ちょっとややこしい。 右上
Git で複数ブランチを同時に扱いたいなら git-new-workdir が便利
Git で管理してるレポジトリーで、いくつかのブランチを別々の場所にチェックアウトしたいことがある。 たとえば GUI なツールでブランチ間の比較したい 同時に実行して比較しつつテストしたい ブランチ間でファイルをコピーしたい ドキュメントの生成結果を別ブランチで管理したい といったときに、必要になる。 ブランチの個数だけ clone しちゃえば用は足りそうなんだけど、でかいレポジトリーだったら時間もディスク容量ももったいない。 git-new-workdir を使うべきでしょう！ 先日、「git-new-workdir を使えばワーキング ディレクトリーを複数を作れて便利」と書いてあるブログを読んだ。 git-new-workdir が便利 - #生存戦略 、それは - subtech git-new-workdir の usage を見てたら、別ブランチのワーキング ディレクトリー作成
ファイル編集したら即ブラウザー再読込させる LiveReloadX を作った
Web 開発してると、ソースを編集して、ブラウザーをリロードして、という作業の繰り返しになりがちだ。ソースを編集したら、自動でブラウザーをリロードしてくれるような夢のツールがあれば便利そうだ。 この分野では CodeKit や LiveReload などが有名なんだけど、もれなく有料だったり GUI だったりする。そこで、LiveReload のオープンソースな部分を参考にしつつ、コマンドラインで使える LiveReloadX というものを作ってみた。 特長はこんなところ。 Node.js を使ってるので Windows/Mac/Linux 問わずに動かせる 開発環境のブラウザーだけでなくスマートフォンのブラウザーもリロードできる 無料 インストール方法 インストールは超簡単！ Node.js をインストールする。 コマンドラインで npm install -g livereloadx を
Node.js＋CoffeeScript でソースマップを使ってデバッグを楽にする方法
以前、jQuery 1.9 のソースマップ対応で圧縮版でもデバッグが簡単になった話 を書いたけど、Node.js でソースマップする方法を紹介する。 何がうれしいかというと、Node.js で CoffeeScript や TypeScript、JSX なんかを使ったときに、例外に含まれるスタックトレースに変換前の位置を表示できる。 やり方は簡単。source-map-support というモジュールを require() するだけ。 ためしに使ってみた GitHub に動かし方が書いてあるので、その通りにやってみる。 こんな感じの demo.coffee があったとする。 require 'source-map-support' foo = -> bar = -> throw new Error 'this is a demo' bar() foo() npm install sourc
-webkit-text-size-adjust: none を絶対に設定してはいけない理由
PC 版の Google Chrome や Safari で見たときにユーザビリティーが落ちるから。 以上。 で終わってしまうと記事にならないので、ちゃんと説明しておく。 そもそも -webkit-text-size-adjust とは何か iPhone や Android のブラウザーは、縦向き (Portrate mode) と横向き (Landscape mode) の文字サイズを自動調整する機能がある。 これを制御するのが CSS の -webkit-text-size-adjust である。 文字サイズ自動調整の具体例 次のような HTML をスマートフォンで表示してみる。 <!DOCTYPE html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width,initial-
jQuery 1.9 のソースマップ対応で圧縮版でもデバッグが簡単になった話
jQuery 1.9 がリリースされました。1.9 の新機能の中ではあまり注目されていませんが、ソースマップに対応したのが地味に便利そうです。 というのも、圧縮版の jquery.min.js を使っていると 何か問題が起きたときにスタックトレースを眺めても jQuery の部分が意味不明 デバッガーで jQuery のソースにステップインしても意味不明 といった理由で、開発中には非圧縮の jquery.js を使うことが多かったわけです。 それが、1.9 からはソースマップに対応したので圧縮版のままでのデバッグが簡単になってます。 超簡単な使い方 ソースマップに対応したブラウザーは現時点では Google Chrome のみなので、Google Chrome の手順を説明します。 (Firefox はソースマップへの対応を計画中らしい) 事前準備を忘れずに Google Chrome で
はてなブックマークの入れ替わり激しくない人気エントリーを見る方法
はてなブックマークのトップページがリニューアルして、新しいデザインへの不満が一通り出つくした感があるけど、人気エントリーのアルゴリズムが改善された件について触れてる人をあまり見ない。 人気エントリーの入れ替わりが激しくなった いままでは人気エントリーはキャッチーなやつで固定化されていたんだけど、今回の改善で、人気エントリーの入れ替わりが激しくなった。 公式にもアナウンスはされていて、トップページとカテゴリページをリニューアルしました - はてなブックマーク日記 によると 滞留や偏りをなくすためにアルゴリズムを変更いたしました。一定時間でコンテンツが入れ替わるよう更新性を高めています。その日にしかチェックできない、新鮮なエントリーが楽しめるようになりました。人気エントリーのアルゴリズムは、今後も継続的に改善してまいります。 とある。 いままでは「ブックマーク数」至上主義だった いままでの人気
GitHub で clone するときは SSH じゃなく HTTP を使ったほうが高速
GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20～60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total
text-hatena.js を GitHub に移動した
2005 年ごろに作成して放置していた text-hatena.js について、twitter で @nitoyon さん、2005年くらいのtext-hatena.js をGitHub等に公開は可能でしょうか？ tech.nitoyon.com/javascript/app… — テラまこさん (@teramako) 12月 17, 2012 というツッコミを受けたので GitHub で公開してみました。 nitoyon / text-hatena.js - GitHub いま text-hatena.js のコードを読み返すと、グローバルな名前空間を汚染してたり、Object.extend() を定義してたりと、いろいろ酷い。 当時は今に比べると JavaScript の知識も浅かったが、浅いなりに prototype.js のコードを読んだり、真似したりして勉強していたことを思い出し
Flickr の Set 内の写真一覧を更新する Ruby スクリプトを作った
身内向けの写真ブログを Flickr を使ってやってます。 非公開で写真をアップロードして、Set の Guest Pass 機能と組み合わせて、URL を知ってる人だけが Set の写真を見られる、という形で運営してます。 さて、Set に写真を追加していけば更新できるわけですが、毎回 Flickr を開いて作業するのが面倒になってきました。Set 内の写真が増えてくると、UI がもっさりしてくるのも嫌でした。 となれば、Flickr の API を使って、スクリプトで自動処理したくなるのがプログラマ心情でございます。 さっそく作った ということで、Flickr の API とにらめっこしながら作ってみました。 require 'flickraw' require 'date' require 'set' # load conf and set API key and access to
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
