愛と勇気と缶ビール
預かり保育三日目。そろそろカウントすることもないか。 仕事は進んでいるのだが遅々としている。細かく確認しつつワンステップずつ進めているためだ。急いでいるときほどちゃんと計画しつつ、慎重に進める。その方が早く終わると分かっているからだ。しかし分かってはいてもあまりいい気分ではない。 預かり保育二日目。例によって、僕が預けられるわけではないのだが… 昨夜、特定の時間帯にしかできないデバッグをしていて寝るのが12時頃になった。そのため今朝は少し眠く、脳の働きが悪く感じられた。僕の思考力は明らかに睡眠時間に比例する。今日は休んで明日から再開するか、あるいはもっと早く切り上げるか。10:30からデバッグ開始可能だから、11:00には切り上げるようにするか。いやはや…。 早く終わらせて、ワインを飲みたい。 今日から新学期。長女は年長さんになり、次女は同じ幼稚園に入園する。といっても入園式はまだ先なので
High Performance Browser Networking - 愛と勇気と缶ビール
一部（？）に需要があったようなので、再掲。 実はまだ全部読んでおらず、物理層やトランスポート層の話を脱してアプリケーション層というかHTTPに来た所。 僕が主に興味を惹かれたのはTCP周りの話なので、その辺だけまとめる。読んだ本の要約？というのは、ヘタしたら著作権侵害というか内容そのものの引写しになってしまいそうで難しい。 話の前提 TCPは不安定で細い回線を前提として元々作られたプロトコルなので、現代の比較的安定した太い回線の上では非効率な部分が多々ある アプリケーションがデータ送り始める前にいわゆる3-way handshakeのための通信をえっちらおっちらやらないといけない。ここにかかる時間は、いかに帯域が広くともレイテンシに引っ張られてしまう。 この部分のロスはいわゆるHTTP keepaliveで回避できる、のだが... そうしてhandshakeした後にまたえっちらおっちらco
漢の家計簿、というiPhoneアプリを作った（無料です） - 愛と勇気と缶ビール
実は大分前に作って自分でしばらく使っていたアプリなのだけれども、紆余曲折を経てApp Storeに出たので一応紹介を。 元々、自分自身に「無駄な細かい支出を減らしてお金節約したいピョン」というモチベーションがあって、かといって真面目に家計簿をつけ続けるだけのマメさが自分にないことも分かっていたので、「だらしない人でも続けられる家計簿アプリが欲しいなー。iOS周りの勉強もしたことだし、現状なさそうだから自分で作るか」という流れで作りました。大体以下のようなコンセプトです。 支出を可視化して節約するのが目的なんだから、支出だけ記録できればいいか。収入はいらんだろう。自分の収入くらい分かってるし。 とにかく簡単に記録できることが大事だ、そもそもが面倒くさがりだから。 繰り返しもいいや。入力が面倒くさいわ。 あとは月の合計とか週の合計とかその日の合計が分かればいいや。グラフとか要らんわ。見ないし。
Maintainable JavaScriptにみる、コンテキストとアプリケーションロジックの分離 - 愛と勇気と缶ビール
個人的なこと 読書はいわゆる自己投資？にあたるものなのでケチるもんじゃないよなあ、とは思いつつも可能なら安い値段でより大きなリターンを得たいよねー、ということで最近はOreillyの半額セールに目を光らせるようになりました。英語は「拾い読み」がし辛いという欠点があるのですが、まぁ、安いし、全ての本にちゃんと訳が出るわけでもないので、ええかなぁと。 そんなわけで "Maintainable JavaScript" という本を読んでいたのですが、その中のEvent Handlingについての章が「おお、これこれ」という感じだったのでちょっと紹介。 Maintainable Event Handling jQuery覚えたぜ！って感じの人がとりあえずコードを書くと、だいたいこんな感じになりますね。ちなみに、これは別にjQueryがどうとかいう話ではなくて、本質的には生DOMでも他のライブラリでも
JavaScriptのお勉強をするときの話（環境構築編） - 愛と勇気と缶ビール
この記事は、JavaScriptを勉強して可能なら使えるようになりたいけど、どこからやっていいかよくわからない、という昔の僕みたいな人のためのガイドです。ちなみにいささかCUI寄りです。 初めに断っておきたいのは、僕が多少なりとも真面目にJavaScriptを勉強し始めたのは10ヶ月ほど前のことなので、いわゆるマスター的なヨーダでも何でもなく、未だ途上の何たらだということです。 開発環境を用意する JavaScript入門、みたいな紙媒体やWeb上の記事には、「JavaScriptは基本的にはブラウザ上で動く言語なので、特別な実行環境を用意する必要はありません！楽勝ですね！」みたいなことがよく書いてあるのですが、アホか、という話です。 ブラウザ上で動かす（場合が多い）言語であるからこそ、むしろ実行はめんどくさいです。 「ワイはとにかくDOMが操作できればええんや！言語仕様とかどうでもええわ
JavaScriptのテストについて本気出して考えてみた(3) - 愛と勇気と缶ビール
テストにおけるxhrのハンドリングについて 今までの記事は、「ブラウザで動くJavaScriptのテストを難しくしているのはDOMとxhrである」と最初にのたまった割にはDOMのことしか書いてないじゃないか、と鋭い人はちゃんと思ったのではないかと思う。 なのでJavaScriptにおける外部リソース操作の双璧をなすところのxhrについてもちょっと書く。 xhrによる外部リソースの操作を含むアプリのテストを（本物のサーバサイドアプリを使わずに）行う場合の方法は主に二つあると思っていて、 1. テストフレームワークの側で、xhrに対してレスポンスを返すようなモックcontroller(?)を書けるようにしておく 2. xhrそのものをモックオブジェクトにしちゃう 1. はつまり、pushによる自動化を行うようなフレームワークだと何らかの形でWebサーバを起動しているはずなので、その中でxhrか
JavaScriptのテストについて本気出して考えてみた(2) - 愛と勇気と缶ビール
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか？Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
JavaScriptのテストについて本気出して考えてみた(1) - 愛と勇気と缶ビール
一週間のうちまる一日くらいは、「あーあのJavaScriptコードのテストってどうするのがいいかしら？」と考えている。 嘘です。多分45分くらい。 考えている時間の長さはどうでもいいんだけど、JavaScriptのテストは場合によっては中々ややこしい問題に成り得る。DOMなどの外部リソースにタッチすることのない「純JavaScript（オレオレ用語です）」であればブラウザ上であろうとRhino上であろうとNode JS上であろうと(理論上は)テストを動かせるのだが…。 JavaScriptであろうとなかろうと、外部のリソースに依存している（外部のリソースを操作する）コードはそうでないコードよりテストが面倒になる。ファイルR/WやDBの操作などIO系は勿論そうだし、どこかのサーバに何かしらのプロトコルで話しかけるようなコードもしかり。 JSのテストがややこしくなるのは、JavaScriptの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
