404 Blog Not Found:Digest - 今日にでも使うべきJavaScriptの7つのテクニック
2007年04月25日12:00 カテゴリLightweight LanguagesBlogosphere Digest - 今日にでも使うべきJavaScriptの7つのテクニック 良質の記事だけに全訳したかったのだけど、時間もないので紹介と抄録。 Digital Web Magazine - Seven JavaScript Techniques You Should Be Using Today サンプルコードは、適宜書き換えてあります。 1. Branch when possible - 分岐はなるはやで これは実例を見た方が早いでしょう。クロスブラウザー対応のaddListener()を考える。機能だけを考えれば、以下でOK。 function addListener(el, type, fn) { if ( window.addEventListener ) { el.addE
404 Blog Not Found:怠翻 - JavaScriptでありがちな9つのシマッタ
2007年08月17日01:15 カテゴリ翻訳/紹介Lightweight Languages 怠翻 - JavaScriptでありがちな9つのシマッタ 私自身結構シマッタしちゃうので。 Nine Javascript Gotchas 尻カンマ注意 以下のコードはFireFoxでは動きますが、Internet Explorer (以下IE)では問題になります。 var theObj = { city : "Boston", state : "MA", } 最後にカンマが入らないよう注意しましょう。 浮気なthisは何を見てるやら 以下のコードで、thisは何を指しているでしょうか。 <input type="button" value="Gotcha!" id="MyButton" > <script> var MyObject = function () { this.alertMess
CSS のコメントの書き方コレアレ
CSSもHTMLと同じように、ソース中にコメントを挿入することができます。 /*と*/で囲った文字列がコメントになりますが、入れ子にすることはできません。また、他のプログラムにあるような「#」や「//」といった単一行コメントはありません。 適切なコメントを挿入することで、複数人での作業するときや、時間がたってから編集するときなどにコードの見通しが良くなります。ブラウザ間の差異を埋めるための宣言やハックなんかも、適用させるブラウザ名や理由などをきちんとコメントで書いておきたいですね。 僕は、スタイルをグループに分けて記述するときなど、コメントを目立たせるために次のように記述しています。 /* ------------------------------ Header ------------------------------ */ div#header { } . . /* -------
まつもと直伝 プログラミングのオキテ 第13回 プログラムを高速化する：ITpro
プログラムの高速化はプログラマにとって永遠の課題です。しかし，そこには知られざる暗黒面が隠れています。そもそも高速化に意味があるのかを調べなければなりません。次に，どの部分をどの程度高速化するのかが重要です。アルゴリズムの効率にも目配りが必要です。 コンピュータの処理速度は驚くべき勢いで向上しています。現在私たちが使っているパソコンは一昔前のスーパーコンピュータをしのぐ性能を備えていますし，半世紀前に登場したばかりの計算機と比較すると数十万倍の性能に相当します。 このように高速なコンピュータを持っているにもかかわらず，人間の欲望は限りがないものです。プログラムの実行速度はプログラマにとっての永遠の課題のようです。プログラムを高速化していると，「そんなに急いでどこに行く」という気になることもあります。 今回は，プログラムの高速化にまつわるさまざまな「秘密」と「限界」，そして「戦略」について解
FUSEを使ってはてなブックマークから POOKMARK Airlines へ乗り換える方法 - bits and bytes
Google Code で macfuse がリリースされたのをきっかけに、FUSEをみんながおもちゃにするに違いないと思ったのにだれもおもちゃにしていないみたいで、くやしかったので自分でおもちゃにしてみました。 FUSEの利点は、ファイルシステムという今まで数十年間使われてきた標準的なインターフェイスに任意のサービスをマッピングできるということにあります。数十年間、ファイルシステム上でファイルを扱うために様々なツールが開発されてきました。ファイルシステムにサービスをマッピングできるということは、数十年間蓄積されてきたファイルを扱うためのツールをそのままサービスを扱うためのツールとして利用できるということです。 例として WikipediaFS, view and edit Wikipedia articles as if they were real files を見てみましょう。このw
OutOfMemoryエラー発生!? GCがあるのに、なぜ？
今回の概要 本稿ではWebアプリケーションの開発プロジェクトで実際に直面したメモリに関するトラブル事例の中からjava.lang.OutOfMemoryErrorを題材としたTipsを紹介する。 帰宅直前に、突然電話が鳴り響く 業務を終えて帰宅しようとしたとある夜、突然電話が鳴る。相手は社内のプロジェクトのマネージャである。 「現在、テストを実施しているが、数分経つとOutOfMemoryErrorが発生してアプリケーションが落ちてしまう。再起動を掛けると、また順調に動くが、しばらく利用していると、同じようにOutOfMemoryErrorが発生する。メモリ不足のエラーなので、物理メモリを増やそうかと思っているが、物理メモリ増設の前に、アプリケーションという観点からメモリ不足を引き起こす問題がないか調査してほしい」 取りあえず、原因を探るために現場に急行した。 現場にてトラブルの詳細をヒア
JavaScript でブロックスコープを実現する: Days on the Moon
JavaScript には基本的にブロックスコープというものが存在しない。どうしてもブロックスコープを扱いたいときは function 式を使ったりする。 var a = 10; { var a = 20; print(a); // 20 } print(a); // 20 var a = 10; (function () { var a = 20; print(a); // 20 })(); print(a); // 10 だがやはりブロックスコープがあったほうが便利ということで JavaScript 1.7 では let 式、let 文、let 宣言が導入される。 var a = 10; let (a = 20) { print(a); // 20 } print(a); // 10 しかしこれでは対応するブラウザが Firefox 2 以降などに限られる。ところが、with 文とオブ
[ruby] RubyでHTMLとWebを操作するためのライブラリ、HpricotとWWW::Mechanize - Greenbear Diary (2007-02-05)
■ [ruby] RubyでHTMLとWebを操作するためのライブラリ、HpricotとWWW::Mechanize 今日は、RubyでWebサイトを解析するときに強い味方となるライブラリ、HpricotとWWW::Mechanizeを紹介します。 どちらも非常に強力なので、覚えておいて損はないよ！ 以下ではまずHpricotでHTMLを解析・編集する方法について解説します。 次に、「はてなダイアリーの自動更新」を例にWWW::Mechanizeの使い方を解説します。 Hpricot HpricotはHTMLを解析するためのライブラリです。 例えば「あるページのリンクだけを全部抜き出したい」と思ったとき、どうしますか？scrAPIを使う？でもscrAPIはやっぱり ちょっと使いたいだけなのにパーザ(Scrape)用のクラスを定義するのが面倒なんだよね！ Hpricotなら、たったこれだけで
![[ruby] RubyでHTMLとWebを操作するためのライブラリ、HpricotとWWW::Mechanize - Greenbear Diary (2007-02-05)](https://cdn-ak-scissors.b.st-hatena.com/image/square/b0dd2a08b2c0fff30d70543ed7fa340ebfeb5697/height=288;version=1;width=512/https%3A%2F%2Froute477.net%2Fd%2Fassets%2Fogimage.png)
コマンドプロンプトを使ってみよう！
ここでは、コマンドプロンプトの基礎知識・使用機会の多いと思われるコマンドを紹介しています。 初心者の方でも簡単なコマンドなら使えるように、できるだけわかりやすく解説するよう心がけました。
コードをセキュアにする10の作法…の覚え方 - 結城浩のはてな日記
Danさんが、コードをセキュアにする10の作法という翻訳を公開していました。 翻訳には特にツッコミはないのですが…正直、10個も覚えられません！ (>_<)ヒー！ ので、勝手に再配置。かっこの中がお作法の名前です。 各段階でチェックしよう！ 設計時に、 （セキュリティーポリシーを設計に織り込め） コーディング時に、 （セキュアコーディングの標準を採用せよ） （コンパイラーの警告レベルは最高に） テスト時に、 （有効な品質保証の手法を用いよ） もちろん実行時にも。 （入力を検証せよ） （他のシステムに送るデータは消毒(サニタイズ)しておけ） 迷ったときにはシンプルに！（シンプルイズベスト） デフォルトは拒絶、 （デフォルトで拒絶） 権限は最小、 （最小特権の原則を貫く） でもシンプル過ぎてはいけません。 （多重防御を実践せよ） これでちょっと覚えやすくなりました（私は）。内容は以下のページを
SubVersionやRMDB、他各種プログラミング用チートシート集:phpspot開発日誌
The Developer Cheat Sheet Compilation by FuzzyOpinions.com SubVersionやRMDB、他各種プログラミング用チートシート集。 気になったものをいくつかメモ。 CSS 2 Reference Card (PDF) CSS Useful Properties .htaccess Cheat Sheet Subversion Quick Reference (PDF) UML Quick Reference Card (PDF) Vim Commands Cheat Sheet XEmacs Commands Cheat Sheet 関連エントリ Prototype.js 1.5.0 のチートシート １ページに情報が集約されたCSSチートシート「CSS Cheat Sheet」 Ajax,Apache,CSS,CVS,HTML,JS
複数でサービスを作るコツ | ランサーズ社長日記
いいね！ 2 ツイート B! はてブ 88 Pocket 4 「個人サービスを作るコツ」というエントリーを書いたが、最近、個人ではなく、友人と2人でQuemlというモバイル検索メールサービスを始めた。 基本的には「個人サービスを作るコツ」とノウハウは共有できるが、複数でサービス企画して作っていく作業独特のコツもあると思う。と、いうことで、今回は「複数」にスポットをあてて、個人ではなく複数でサービスを作り個人以上の成果を得るためのコツを書き出してみた。 複数でサービスをつくるコツ １．決起集会を開く ２．ドメインを取る ３．サービスに名前をつける ４．リリース日を決める ５．常に連絡を取れる手段を用意する ６．予定を共有する ７．誰にも依存しない開発環境を用意する ８．良いものは良いという ９．タスクを明確化する 解説 １．決起集会を開く 「こういうサービスあったらいいよね。」というのは飲み
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
小野和俊のブログ:プログラマーが覚えておきたい英単語
小飼弾さんのブログで、やっちゃうとバカにみえちゃう英文法の間違いという記事があったのだが、読んでいて、こういう間違えやすい英語というのはプログラミングの世界でもあるなと思ったので、私が実際見たことある事例に絞って、プログラマー版を何点か。 * 小飼弾さんと秋元さんからいただいたトラックバックの内容に基づいて、一部追記しました。 たまに、フィールドやメソッドの名前で、「メモリにキャッシュする」というようなケースで使われる「キャッシュ」が cash になっていることを見かけるのだが、cash は現金という意味のキャッシュで、正確には cache。そんな間違いする人いないのでは、と言う人もいるかもしれないが、この間違いは実際に何度か見たことがある。 2. Programming - Programing 辞書的には programming (mが2つ) が正しい表記。ただ、Google などで検
CSS For Bar Graphs
Having a working knowledge of XHTML and CSS when developing applications is a big help in knowing what can be done client-side and what should be generated server-side. Recently we’ve had to tackle some interesting visualizations which we coded in XHTML and CSS. The method we used, while fairly simple, was a big help to the engineer and created a very flexible and inexpensive solution. We thought
プログラミングのノウハウ
プログラミングに関するノウハウは大きく 3つにわかれると思う。 (またもや強引な分類) 1. 普遍的なノウハウ アルゴリズム, データ構造, オブジェクト指向, ツールボックスアプローチ, λ計算, etc. 2. システムのノウハウ 言語処理系, 計算機アーキテクチャ, OS, ネットワーク, etc. 3. 雑多なノウハウ 恣意的なAPI, 恣意的な言語仕様, 各種ソフトウェアの設定, 各種コマンドラインオプション, ソフトウェアのインストール作業, 各種システムの仕様の違い, 「最新技術」, etc. プログラミングをする上では 3種類のノウハウすべてが多かれ少な かれ必要なのだけど、僕のような人は、ついつい 3番目の雑多なノ ウハウばかりが増えていってしまう。日々のネットサーフィンで得 られるノウハウは大抵これである。 雑多なノウハウというのは、「たまたまそうなっている」だけであっ
for 文 2.0(笑) - IT戦記
まぁ、かなり知られてる話ですが JavaScript は .(ドット) の計算がかなり遅い。まぁ、簡単なスクリプトなら問題にならないが。web2.0的には大違いなのであります。ちなみに、.(ドット) の計算に比較演算の 3 倍のコストがかかる（IEはとくに）。 ということで、for 文は下のように(比較に .(ドット) を使わない)書くくせをつけましょう。地道な差が大きなパフォーマンスを生みます。 // for 文 2.0 for(var i = 0, len = array.length; i < len; i++) { .... }各種ライブラリの for 文 1.0 を for 文 2.0 化するだけで、CPU 使用率がけっこう下がりました。 予断ですが、間違っても .(ドット) を避けるために with 文を使うようなことはやめてください。 with 文のコストは 比較演算の 8
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM わかりやすいコードを作成するための 6 つの方法 - Japan