「Javaパフォーマンス」はいい本だった - 愛と勇気と缶ビール
Javaパフォーマンス 作者: Scott Oaks,アクロクエストテクノロジー株式会社,寺田佳央,牧野聡出版社/メーカー: オライリージャパン発売日: 2015/04/11メディア: 大型本この商品を含むブログ (11件) を見る とても馬鹿っぽいタイトルになってしまったが、気にしないのである。 だいたいの内容としては、 パフォーマンス・チューニングに関する一般論 Java付属のモニタリングツール（jstatとかあれとかこれとか） JITコンパイル周りについて GCについて 等々がいい感じに、過不足なく書いてある。 既にJava10年選手で、GCのチューニングもしたことあるし、JVMとは戦友みたいなものだ…みたいな人にはおそらく必要ないだろうが、JVM周りのあれやらこれやらを知らない人（つまり僕のような）がとりあえずJava始めてみたときに、頭の中に見取り図を書くためにはこの本を読むのが
初めから厳密すぎるテストを書くのは筋悪なのではないかという話 - 愛と勇気と缶ビール
これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。 何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。 例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。 { valid: true, foo: 10, bar: 0 } で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のke
Linux KernelのLinked Listの実装が面白い件 - 愛と勇気と缶ビール
最近、Robert Love先生の本を暇な時にダラーと読んでいたりするわけですが、それの中にLinux Kernel内部で使われているLinked Listの実装が書いてあって面白かったので共有。 まず、Linked Listの一個一個のエントリを表すstructを定義します。 struct list_head { struct list_head *next, *prev; }; いやいやいやいや。いかにC力の低い僕でも流石にこれはあきません。騙されませんよ。前後のエントリへのポインタは確かにあるけれども、これにはデータを指すためのポインタがないじゃないの。おじいちゃんまたデータ忘れてきちゃったの？いやあねえ。 おじいちゃんは言った。「それはお前の短見というものじゃ。このLinked Listは以下のコードのようにデータ構造に埋め込んで使うものなんじゃよ。」そしてそれは正しかった。 st
Maintainable JavaScriptにみる、コンテキストとアプリケーションロジックの分離 - 愛と勇気と缶ビール
個人的なこと 読書はいわゆる自己投資？にあたるものなのでケチるもんじゃないよなあ、とは思いつつも可能なら安い値段でより大きなリターンを得たいよねー、ということで最近はOreillyの半額セールに目を光らせるようになりました。英語は「拾い読み」がし辛いという欠点があるのですが、まぁ、安いし、全ての本にちゃんと訳が出るわけでもないので、ええかなぁと。 そんなわけで "Maintainable JavaScript" という本を読んでいたのですが、その中のEvent Handlingについての章が「おお、これこれ」という感じだったのでちょっと紹介。 Maintainable Event Handling jQuery覚えたぜ！って感じの人がとりあえずコードを書くと、だいたいこんな感じになりますね。ちなみに、これは別にjQueryがどうとかいう話ではなくて、本質的には生DOMでも他のライブラリでも
ES5 features on iOS/Android's default browser - 愛と勇気と缶ビール
iOS, Androidのめぼしいバージョンのデフォルトブラウザについて、ECMAScript 5 compatibility table を使ってES5の対応度合いを調べました。既にありそうだなーと思いつつパッと見当たらなかったので。 どれもエミュレータで調べたものですし、特にAndroidについてはメーカーが手を入れてヘンテコリンなことになっている可能性も結構あるので、目安程度に。 全てのiOSデバイスが6.0以上、Androidデバイスが4.1以上になればstrict mode含めてやりたい放題（かも？）、ということが分かりますね。いつになることやら。 feature/os version ios-4.3.2 ios-5.0 ios-5.1 ios-6.0 android-1.6 android-2.1 android-2.3.3 android-3.0 android-4.0.2
メッセージングでまあまあ捗るかもしれない話 - 愛と勇気と缶ビール
この記事はJavaScript Advent Calendar(オレ標準コース)の13日めのエントリイになります。 ちなみに家に帰った瞬間、マシンの時計がずれて12/14になってて、大分一人で焦りました。てへぺろ。ぺろぺろ。 この記事の題材はJavaScriptにおけるメッセージング（もどき）です。 で、メッセージングって何やねんと JavaScriptで！メッセージング！というとその筋の人はwindow.postMessageを思い出すのかも知れませんが、 この記事では「メッセージング」という言葉をもっと広い意味に捉えて使っています。 だいたい、「あるオブジェクトがメッセージを受け取るオブジェクトを直接には知らなくても、特定の目的を持ったメッセージを投げて処理をさせることができるような仕組み」のことを「メッセージング」と呼んでいます。 すごい！すごい分かりにくい！ (ちなみにいわゆるプロ
memcachedとRedisの生存戦略、というかmemory allocation戦略 - 愛と勇気と缶ビール
ちょっとmemcached & Redisについて調べたのでめも。 ちなみに、生存戦略って言葉は最近Twitterでよく見るから使ってみただけで、実際に何かは知りません。歌か何かかな。 ちなみに見ているソースについては、memcachedは1.4.6、Redisは現時点でのgitの最新(多分)。 memcachedに関して、特定のサイズのchunkを管理するslab classっていうものがあるよーん、とかは説明するとめんどくさいので飛ばします。↓の記事とかに書いてあります。 http://gihyo.jp/dev/feature/01/memcached/0002?page=1 memcached 起動時の-Lオプションが付いてる場合、初めに全部mallocしちゃう。付いていない && DONT_PREALLOC_SLABSがdefineされている場合はchunkのpreallocate
本当はそれなりに面倒くさいJavaScriptとhistoryとAjaxのお話 - 愛と勇気と缶ビール
口上 historyとAjaxといえば、JavaScriptからある程度任意でhistoryのエントリをpushできるhistory.pushStateとか、history.replaceStateは既に大分有名になった感がある。 素晴らしい未来では、全てのブラウザにpushStateが乗っていて「location.hashを使ったAjax遷移が許されるのは10年前のブラウザまでだよねー」というハッピーな世界が実現するのだろう。が、今現在ではまだpushStateに対応していないブラウザのシェアも多く、Ajaxによる擬似画面遷移をモリモリ行うようなサイトではpushStateのある環境、ない環境の両方を考慮してやる必要がある。 (ちなみに、要件によっては「pushStateがないブラウザは通常の遷移で我慢しろ！」という割り切りも全然ありだと思う) 先に言っておくと、この記事は長いです。 環
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ページを開く
