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()
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
タッチ操作に対応した画像ビューワーをJavaScriptで作るならD3.jsが便利
スマホやタブレットで写真を表示していると、ピンチでズームしたり、ドラッグで移動したりができて便利なので、あれを Web 上で実現してみたくなった。 最近のブラウザーでは touchstart や touchmove イベントでタッチ情報を取れたり、イベントの touches でマルチタッチを扱えたりするので、実現するための基盤はそろっている。 適当なライブラリーがあるかと思って探してみたが、意外と苦労してしまった。 Hammer.js が使えない タッチを扱うためのライブラリーとしては Hammer.js がメジャーらしい。スワイプ・ピンチ・ドラッグなど、各種イベントにも対応していて、これを使えば一発解決してくれそうだ。 ところが、画像ビューワーを作るには不向きだった。困ったのは次の 2 点。 ピンチやドラッグは個別には動くが、組み合わせたときに「表示位置」と「倍率」の関係を自前で計算する
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
git difftool --dir-diff が便利すぎて泣きそうです
Git の 1.7.11 から git difftool コマンドに --dir-diff というオプションが追加されたのですが、これがライフ チェンジングだと思ったので紹介します。 --dir-diff 登場以前の git difftool は「ファイルごとに順番に差分を表示していく」ことしかできず、使い勝手はいまいちでした。それが、--dir-diff オプションの登場で状況が一変したわけです。 こんな感じの使い心地だよ ある Git レポジトリーで dir1/a.txt と dir2/c.txt を編集したとしましょう。 この状態で git difftool --dir-diff または git difftool -d を実行してみると・・・。 はい、差分のあるファイルが一覧で表示されました。 (difftool に WinMerge を設定して、メニューから [ツリー表示] を有効
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
rsync の複雑怪奇な exclude と include の適用手順を理解しよう
rsync は便利なんだけど、オプションが多くて難しい。特にややこしいのがファイルを選別するための --exclude と --include オプションだ。 man を読んでもイメージがつかみにくかったので、ググったり、-vvv の結果を見たり、ソースを読んだりしつつ調べてみたところ、3 つのルールを理解すれば何とかなりそうなことが分かった。 この記事では、その 3 つのルールをなるべく分かりやすく説明する。 ルール1: 指定順に意味がある コマンドライン引数は、通常、どの順番に指定しても同じ挙動になることが多い。しかし、rsync の include と exclude に関しては、指定順が意味を持つ。 man にも出てくる例で説明しよう。MP3 だけをコピーするには次のようにする。 -av はコピーするときのお決まりのオプション。ネットワーク越しにコピーするときは、-avz として圧
ファイル編集したら即ブラウザー再読込させる LiveReloadX を作った
Web 開発してると、ソースを編集して、ブラウザーをリロードして、という作業の繰り返しになりがちだ。ソースを編集したら、自動でブラウザーをリロードしてくれるような夢のツールがあれば便利そうだ。 この分野では CodeKit や LiveReload などが有名なんだけど、もれなく有料だったり GUI だったりする。そこで、LiveReload のオープンソースな部分を参考にしつつ、コマンドラインで使える LiveReloadX というものを作ってみた。 特長はこんなところ。 Node.js を使ってるので Windows/Mac/Linux 問わずに動かせる 開発環境のブラウザーだけでなくスマートフォンのブラウザーもリロードできる 無料 インストール方法 インストールは超簡単！ Node.js をインストールする。 コマンドラインで npm install -g livereloadx を
これがスマートフォン向けサイトを作るときの viewport 設定３パターンだ
スマートフォン向けの Web サイトを作るとき、viewport の設定次第で使い勝手が大幅に変わる。 最近はレスポンシブ Web デザインが流行してるけども、その大前提として viewport の設定パターンを抑えておくのは重要だろう。 この記事では、viewport の設定によって、見た目・使い勝手がどう変わるかを解説する。 パターン1: 何も考えずに HTML を書く まずは、viewport を指定せずに、単純な HTML をスマートフォンで表示してみる。 <!DOCTYPE html> <head> <meta charset="utf-8"> </head> <body> <img src="/images/logo-ja.png"> <p>色んな素材がごった煮になった様子をお椀で表現しています。 湯気が<strong>「てっく」</strong>に見えるのが隠し味になっていま
-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 で
Jekyll の 0.12.0 でシンタックス ハイライトが便利になった
※ これは Jekyll アドベントカレンダー の 25 日目の記事です このブログの生成にも利用している Jekyll が約 1 年ぶりにバージョン アップして 0.12.0 になった。RubyGems に公開されているので、gem update で更新できるはず。 この記事では、0.12.0 で個人的に注目している「シンタックス ハイライトに関する改善点」を 2 つ紹介する。 Jekyll の良さについては、俺の最強ブログ システムが火を噴くぜ で記事にしているので、知らない人はそちらからどうぞ。 Redcarpet 2 のサポート まず 1 つ目は Redcarpet 2 のサポート。 Redcarpet は GitHub の中の人によって開発されている Markdown パーサーて、GitHub Flavored Markdown が使えるのが大きな特徴。 これまでも Jekyll
俺の最強ブログ システムが火を噴くぜ
ブログを「はてなダイアリー」から、自分のサーバーに移転しました。 せっかく移転するなら、2012 年の流行を取り入れた挑戦的なブログにしてみたい！と思い、構想から半年、ついにこの日を迎えることができました。 せっかくなので、凝ったところを自慢させてください。 これが俺史上最強のブログ システムだ ブログ システムとして Jekyll を採用 Jekyll のプラグインを自作 (はてな記法対応、英語ブログとの統合) 履歴管理は GitHub を利用、git push で自動でデプロイ コメント欄には DISQUS を採用、旧ブログへのコメントはインポート済み HTML5 マークアップ、CSS3、レスポンシブ Web デザインでのモバイル対応 盛りだくさんですね。 詳しく説明していきます。 ブログ システムとして Jekyll を採用 最近では WordPress を選ぶのが普通でしょう。Wo
英語ブログを新調した話と移転計画 - てっく煮ブログ
放置していた英語ブログをこのブログと同じデザインに統一した。英語ブログ、以前は MovableType を使ってたんだけど、いろいろ面倒になったので Jekyll で作り直した。Jekyll は Github Pages に使われている静的コンテンツ ジェネレータ。Ruby で作られていて、コードはシンプル、プラグイン機構もあるので、カスタマイズしやすい。Jekyll については次のページが分かりやすかった。Big Sky :: Jekyllで始める簡単ブログソースコードは https://github.com/nitoyon/tech.nitoyon.com で公開している。このブログも移動させようと準備中せっかく英語ブログも新調したので、このブログも http://tech.nitoyon.com/ja/blog/ あたりに移動させようと準備している。理由としては色々あるんだけど、ざっ
コンプガチャだけじゃない!? ガチャに潜む確率の罠 - てっく煮ブログ
twitter をみていたら、こんなツイートが回ってきました。 モバゲー・GREEが確率明示しないのは、搾り取るためというよりは、クレーム対応減らすため。1％でSR、って書くと「100回引いたのに出ない。詐欺だ」。確率だから、って説明すると彼らはこう返す「だから、100回に1回出るんでしょ？」さあ、どう返そうか。 2012-05-06 17:15:49 via モバツイたしかに「1% のガチャを 100 回引いたら当たる」と思い込んでしまう人は多そうです。では、1% のガチャを 100 回引くと、どれぐらいの人が当たり、どれぐらいの人が当たらないのでしょうか。1% のガチャを 100 回引いて当たらない確率は？さっそく計算してみましょう。1 回ガチャを引いて当たらない確率は です。当たる確率は なので 1% と求まります。2 回ガチャを引いたときに、1 度も当たらない確率は です。つまり、
意外と多い!? Web フォントに対応していない環境 〜2012 年の Web フォント事情〜 - てっく煮ブログ
html5Web フォントは「Web サイトにオリジナルのフォントを埋め込む」ための技術です。現行のブラウザーは全て Web フォントに対応している状況です。そんな状況であるため、絶対にコピペできない文章を作ったったwwww は Web フォントに依存したコンテンツでしたが、特別な配慮はせずに公開しました。しかし、公開後、Web フォントが適用されなかった複数の方から「コピペできるんだけどどういうこと？」「意味が分からない」というコメントがよせられました。そこで、Web サーバーのアクセスログを解析して「Web フォントに対応していない環境」がどの程度あったのかを調べてみました。４種類のフォーマット一口に Web フォントといっても、フォントのフォーマットは WOFF・TTF・EOT・SVG の 4 種類あります。今後は WOFF フォーマットが標準になっていくのですが、現在ではサポートし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jekyll のカテゴリーとタグの指定方法 3 パターン