Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている！
Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている！ クロスプラットフォームでオープンソースな IDE 環境、Visual Studio Code が公開されたので試してみた。 拡張を入れなくても、デフォルトで JavaScript の「自動 Lint」「Grunt、Gulp 連携」「デバッグ」が動いた。なんだかすごく便利そうな予感。 Windows 環境で起動してみたらこんな画面だった。 なんか黒いが、色は好みにカスタマイズできるし、プリセットからも選べる。 フォルダーを開くことから始まる Visual Studio Code にはプロジェクトの概念はない。 [File] > [Open Folder] からフォルダーを開けばよい。 ためしに、過去に作った Node.js 製の livereloadx のフォルダーを開いてみた。 左側に
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()
jQuery を高速に使う CSS セレクタの書き方
jQuery は CSS セレクタで要素を選んで処理できるのが魅力的ですね。そんな jQuery ですが、CSS セレクタの書き方次第で速度が大幅に変わってきます。 ここでは jQuery の内部処理を疑似コードで示しつつ、jQuery を高速に使うためのポイントを５つに絞って紹介します。 何度も同じセレクタを実行しないクラスだけを指定するのは禁止#id を積極的に使う途中までの結果を再利用する子供セレクタ(>)を使うと速くなることがある ※ この記事は jQuery 1.2.6 のソースコードを元に記述しています 1. 何度も同じセレクタを実行しない 改善前 // 例題 1 $("div.foo").addClass("bar"); $("div.foo").css("background", "#ffffff"); $("div.foo").click(function(){alert
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,
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 に反映しようすると破綻します。 簡単な例として、よくあ
JavaScript フレームワークがデータバインディングを実現する４通りの手法
最近流行りの JavaScript MV* フレームワークは、どれもデータバインディングをサポートしているが、実現方法はフレームワークによって異なる。 この記事では、各種フレームワークがどのようにモデルの変更を検知しているかを次の 4 つのパターンに分類して紹介する。 モデル クラス方式 (Ember.js、Backbone.js、Ractive.js、Knockout.js など) 力ずく方式 (AngualrJS) モデル書き換え方式 (Vue.js) Object.observe 方式 (Polymer) パターン名は私が勝手に名づけたものだけど、このへんの雰囲気が理解できれば、フレームワークごとの個性が分かるだろうし、利用イメージもわきやすいんじゃないかと思っている。 1. モデル クラス方式 「モデルとして扱えるのはフレームワークが用意したモデル クラスのインスタンスだけ」という
ConEmu 突っ込んだら Git for Windows の Git Bash がカッコよくなった
Git for Windows の Git Bash の配色がイマイチだなーと思ってググってたら、Console2 だとか ConEmu を使うと楽にできるっぽいことが、Stack Overflow とか英語のブログで見つかった。 そこで、ConEmu を試してみたら色々と幸せになった (Console2 はそのままでは日本語が使えなかった。解決方法はあるらしいけど…)。 左が Git Bash、右が ConEmu さん。 アンチエイリアス効いてるし、色もオサレ。 起動から色を設定するまで ConEmu を起動すると、初回は設定の保存場所などを確認される。お好みで答えて [OK] を押すと、タブ化した MS-DOS プロンプトみたいなのが立ち上がってくる。 [Win] + [N] を押すと新しいタブを開始できる。 上のキャプチャーのように、どんな環境のタブを開始するかをメニューで聞いてきて
全角半角混在の文章で 1 行に半角何文字分あるか調べる方法
「ソースコードは 1 行あたり 80 文字以内」とか「コミットログは横幅 72 文字以内」とか、文字数に関するルールはいろいろある。 ルールを徹底するには機械的に判定したい。と思って、簡単なスクリプトを書こうとした瞬間、意外と「1 行あたりの文字数」をカウントするのが難しいことに気付いた。 たとえば、「あA」は「全角 1 文字＋半角 1 文字」なので半角 3 文字分としてカウントしたい。 しかし、UTF-8 の世界では「あA」の文字長は 2 だし、バイト数は 4 (あ=0xE38182、a=0x41) である。 EUC-JP や Shift-JIS の時代なら、単純に「あA」は 3 バイトなので「半角 3 つ分」とすぐ分かったのだけども… (逆に文字長を調べるのが面倒だった)。 はて、どうするか？ というのがこの記事でいいたいこと。 East Asian Width を見よ いろいろとググ
Git for Windows でレポジトリー上の CR LF を LF に変換する手順
Git for Windows では改行コードが「レポジトリー上は LF」「ワーキング ディレクトリーは CR LF」となるように、git config の core.autocrlf が true となる状態でインストールされる (インストーラーでデフォルトの [Checkout Windows-style, commit Unix-style line endings] を選択した場合)。 Windows 以外の文化圏の人は CR LF を見ると CR がゴミに見えるので、妥当な設定だろう。 標準設定の autocrlf が true のときに、レポジトリー上に CR LF なファイルが紛れ込んでいないか調べたり、紛れ込んだ CR LF を LF に変換したかったのだけど、この手順が少しややこしかったので記事にまとめておく。 (autocrlf を false にして clone した
Vagrant で作ったり壊したりできる Windows 環境を手に入れるまでの手順
最近話題の Vagrant さんは「Linux の環境を作ったり壊したりして開発とか試験が楽になるよ」と紹介されることが多いけど、Windows の環境だって作ったり壊したりしたい！ いろいろ調べつつ環境を作ってみたので、その手順を共有しておく。 完成イメージはこんな感じ。コマンドプロンプトから vagrant up をしたら VirtualBox 上に Windows Server 2012 R2 の環境が準備されて、そこにリモート デスクトップで接続している。 いろいろいじったあとに vagrant destroy したら環境は消え去って、vagrant up したら、また、まっさらな状態から使える。 ちょっと注目してほしいのは、ゲスト OS の C:\vagrant にホスト側の Vagrantfile がマウントされているところ。このあたりの処理は Vagrant-Windows
CVS レポジトリを Git に変換した手順とか注意点とか
この前、10 年以上前に趣味で作っていたフリーソフトについてメールで質問が来た。もはや完全に記憶から消えているだけでなく、いま使っている PC にソースコードもない。何も分からない、答えられない。 そのままでは古いソースコードも成仏しきれない。供養するために、古い HDD を引っ張り出して探したところ、自宅サーバーをやってた HDD の中に CVS レポジトリーが見つかった。せっかくなので、Git に変換して GitHub で公開してみた (その１, その２)。これで成仏できるだろう。 そこで、この記事では CVS レポジトリーを Git に移行した手順をまとめておく。レガシーな CVS から Git に移行したい人の参考になるとうれしい。 git cvsimport の使い方 Git には git-cvsimport というコマンドがある。CVS の履歴を Git に変換してくれる。 C
D3.js の Data-Driven な DOM 操作がおもしろい
D3.js は「ビジュアライズ用のライブラリー」だと紹介されがちなんだけども、意外にも D3.js にはグラフを描画する機能がない。 D3.js のトップページには次のように書いてある。 D3.js はデータからドキュメントを生成するためのライブラリーです。D3 は HTML, SVG, CSS を使ってデータに命を吹き込みます。Web 標準を重要視しているので、独占的なフレームワークに縛られません。強力なビジュアライズ用のコンポーネントと data-driven な DOM 操作手順を組み合わすことで、モダン ブラウザーの能力を最大限に活用できます。 D3.js is a JavaScript library for manipulating documents based on data. D3 helps you bring data to life using HTML, SVG
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
Windows でも git difftool --dir-diff でシンボリックリンクを使う方法
git difftool --dir-diff が便利だよ、という話を git difftool --dir-diff が便利すぎて泣きそうです で書きましたが、１つ宿題が残っていました。Windows では一時ファイルがワーキング ディレクトリーへのシンボリックリンクにならないので、Unix や Mac に比べて、少しだけ不便だよ、という話です。 そこで、Windows でもシンボリックリンクを使えるようにしちゃおう、というのがこのエントリーの趣旨でございます。 Windows 向けの応急処置パッチ Git for Windows 1.8.3 で動作確認しています。OS は Windows 7 (64 ビット)。 C:\Program Files (x86)\Git\libexec\git-core\git-difftool のパッチがこちら。 --- git-difftool Sun
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
Bugzilla に登録してあるバグをプログラムから更新する方法
会社で BTS として Bugzilla を使っているんだけど、修正したあとに手作業で Web インターフェースから書き込むのが面倒になってきたので、自動化してみた。 コミットしたとき (Git の場合は push したとき) に、コミットメッセージからバグ番号を読み取って、対応するバグにメッセージを書き込みつつ、FIXED にすればよい。 情報がなくて困ったのが、バグにコメントを書いたり、FIXED にする方法。この部分の処理を抜き出してみた。 #!/usr/bin/perl -I/path/to/bugzilla -I/path/to/bugzilla/lib use strict; use Bugzilla; use Bugzilla::User; use Bugzilla::Status; use Bugzilla::Bug; use utf8; &update_bug(1, "ほ
SourceTree が Git のグローバルな無視リストを書き換えて困った話
#ignore thumbnails created by windows Thumbs.db #Ignore files build by Visual Studio *.obj *.exe *.pdb *.user *.aps *.pch *.vspscc *_i.c *_p.c *.ncb *.suo *.tlb *.tlh *.bak *.cache *.ilk *.log *.dll *.lib *.sbr この辺の拡張子は、Windows 関係の開発で自動生成されたり、中間ファイルだったりするファイルなので、確かにコミットする必要がないことはない。 .gitconfig に excludesfile がないときに発動 セットアップ時に、最初のダイアログには [Allow SourceTree to modify global Git and Mercurial config f
UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!!
UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!! 先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。 いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!! それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみたブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめ の2本立てでお送り
Git で複数ブランチを同時に扱いたいなら git-new-workdir が便利
Git で管理してるレポジトリーで、いくつかのブランチを別々の場所にチェックアウトしたいことがある。 たとえば GUI なツールでブランチ間の比較したい 同時に実行して比較しつつテストしたい ブランチ間でファイルをコピーしたい ドキュメントの生成結果を別ブランチで管理したい といったときに、必要になる。 ブランチの個数だけ clone しちゃえば用は足りそうなんだけど、でかいレポジトリーだったら時間もディスク容量ももったいない。 git-new-workdir を使うべきでしょう！ 先日、「git-new-workdir を使えばワーキング ディレクトリーを複数を作れて便利」と書いてあるブログを読んだ。 git-new-workdir が便利 - #生存戦略 、それは - subtech git-new-workdir の usage を見てたら、別ブランチのワーキング ディレクトリー作成
LiveReloadX 0.2.0 公開！ 除外ファイルを指定可能になったよ
LiveReloadX 0.2.0 を公開した。 新規インストールするなら今まで通り npm install -g livereloadx で、バージョンアップするなら npm update -g livereloadx でどうぞ。 以前のバージョンでは、監視対象のフォルダー配下のファイルが更新されるたびにブラウザーをリロードしていたので、たとえば、git で管理しているフォルダーを監視していると、git commit するたびにブラウザーがリロードされるという悲しい状態だった。 そこで、除外フォルダーやファイルを指定できるようにした。 たとえば、cache フォルダーを監視から除外したいときは とすればよい。 また、デフォルトでは html, shtml, css, js, jpg, gif, png, cgi, php など、Web 開発に一通り必要そうな拡張子のみを監視するようにした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
