Hi - Here's a short sampling of a few of the simple folk instruments whose construction Hi - Here's a short sampling of a few of the simple folk instruments whose construction is detailed on my webpage at http://www.ehhs.cmich.edu/~dhavlena/ This video was made in my back yard, on the spur of the moment and is not intended to be fancy music -- just to show some of the instruments, which include
Firefoxは多機能である上に、拡張機能を多数インストールするなどで、日に日にヘビーなブラウジング環境になりがちです。 海外のブログでは、様々なFirefoxの動作軽量化や速度向上についてのTip'sが多く書かれていますが、あてにならないもの、それはちょっと怖いな・・というカスタムも多いのでうかつには手を出せません。 一応ユーザーとして一通り試していますが、その中でも簡単で安全と思われ、効果を体感できたメモリマネジメント方法をご紹介します。 ご存じのように、Firefoxを利用してブラウジングしている際のメモリ使用量というのはかなりのサイズで、他のアプリケーションやWindowsの動作にも少なからず悪影響を及ぼしている場合があります。 下記の2点の設定は、Firefoxのメモリ使用方法を少しカスタムするだけで体感できるほど軽快に動作させることができるTip'sです。 ■メモリーキャッシュ
ソフトを立ち上げずに パッとクリップボードの画像を保存出来ます。 i_view32.exe /clippaste /convert=c:\test.gif クリップボードがテキストの場合 テキストの内容を画像ファイルにしてくれます。 他にも option.txt に便利なコマンドラインあり。 (ReadMore...) ソフトを立ち上げずに パッと撮る事が出来ます。 i_view32.exe /capture=1 /convert="c:\$U(%Y%m%d_%H%M%S).png" これで C ドライブに 日付をファイル名にした SS が出来る。 マウ筋に割り当ててやると いい感じ。 (ReadMore...)
EfficientJavaScript - Dev.Opera - 効率的な JavaScript 目次 この文書について 効率的な JavaScript ECMAScript eval や Function のコンストラクタを使うのはやめよう eval を書き換えよう 関数を使いたいなら function を使おう with を使うのはやめよう 性能を決める関数で try-catch-finally を使うのはやめよう eval と with は隔離しよう グローバル変数を使うのはやめよう 暗黙のオブジェクト変換に気をつけよう 性能を決める関数で for-in を使うのはやめよう 文字列は累積スタイルで使おう プリミティブの操作は関数呼び出しより速い setTimeout() や setInterval() には文字列でなく関数を渡そう DOM 再描画と再フロー 再フローの回数をでき
プログラマの方、もしくはプログラミングに興味のある方に質問です。web上の文章でこれは読んでおいた方がよい、あるいはこの文章は面白いという文章を教えてください。文学、エッセイ、哲学、宗教、経済、科学、コンピュータ等、分野は問いません。 例:http://cruel.org/freeware/hacker.html
<訳者より> 本テキストは英国のウエールズ大学のダニエル・チャンドラー博士による記号論への入門書のオンライン版であり、インターネット上で公開されているものです。このオンライン・テキストは評判が良く、1995年公開以来のアクセス回数は56万回(2004年2月時点)にもなっています。 訳者は2002年4月まで35年間、企業の研究所に勤務していたシステム分析が専門の技術者ですが、記号論の本の中に、「システム」という言葉がたびたび出てくることから記号論に興味を覚え、インターネット上で調べていたところ本テキストと出会いました。記号論の主要トピックスをソシュールの記号学および構造主義をベースに、丁寧に説明しており具体的な例も多く観念的でないことから、記号論を勉強してみたいと思っている人、記号論の勉強を始めたがよく分からず挫折した人にとって良い参考書になるのではないかと感じました(残念ながら、日本では、
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ1ヶ月ほど、私的Webサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね~」と話していたのが、非常~に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数(アクティブな人)が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界:すべてのソフトウェア開発が同じではない。 追記:インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
English only -----Original Message----- Subject: FW: Bjarne Stroustrup Interview about C++ (Joke I hope) Importance: Low On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's 'Computer' magazine. Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created. By the end of the interview, the in
Internetから集めたジョークの意訳です。日本語で面白くないものは外したり、若干アレンジしています。 Bjarne Stroustrup氏のインタビュー記事は、こちら Computer One Liners ペンティアムはコンピュータの中でとけて手でとけない 宇宙の秘密をお教えしよう: それは@鮪*蟻&^^^ NO CARRIER エラー:キーボードが接続されていません。続行するにはF1キーを押してください Cプログラムは動く。Cプログラムはクラッシュする。Cプログラマは燃え尽きる。 "ディスク#3を入れろ"と書いてあるけど、このコンピュータには2つしか口がないよ! ちょうど、最後のバグを直したところなんだ。 デバッグという作業がバグを取り除くことなら、プログラミングとはバグを注入する作業に違いない --- ダイクストラ "#define QUESTION ((bb) || !(bb)
ご存知の通り、はてなのシステムはほぼすべてPerlで書かれています。そもそも僕がはてなに入った一つの理由に、僕が一番得意とする言語であるPerlを使ってシステムを構築していたという点があったりします。 世の中にはたくさんのプログラミング言語があります。Perl、Java、Ruby、PHP、Python、C、C++、lisp、Smalltalk、Cobol...数え上げたらキリがありません。そして、プログラマはかならずと言っていいほど、どれかひとつ以上の言語を愛しています。好き、ではなく愛しているのです。 自分が愛しているものを批判されると感情的になりやすいのは人の常、プログラミング言語の差異に関する議論は炎上しがちで、よく宗教戦争だなんて言われたりもします。その中で、言語なんてどれも一緒だなんていう乱暴なまとめがされることもよくあったりします。 しかし、何年かプログラマというものを経験して
国際文化学部を創設するに当たり、情報科学系の教官が所属する大講座の名前をどうするかについてはかなり苦慮したところであるが、結局情報論に落ち着いた。この名称は講座の実態を必ずしも表しているというわけではないので、適正とはいい難い。情報論としたのは言語論、コミュニケーション論といった、他のコミュニケーション学科の大講座名との整合性を重んじたためであり、情報学としなかったのは図書館情報学的なイメージを避けるためである。 こうした学部の創設過程の中での議論でも感じたことであるが、情報論を構成しているわれわれ理科系の教官と、他の文化系の教官との間で、講座のキーワードである「情報」という言葉についての解釈がかなり食い違っているように思える。今日使われている情報という言葉の意味は人によってまちまちであり、混乱しているといえよう。ここでは訳語として登場した情報という言葉が日本語として変遷するさまを見なが
アジャイル・アライアンスの原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。
意識の高いシステム開発者の間では、すでに広く浸透しつつある「アジャイル開発」。アジャイル開発を取り巻く状況やそのあり方について、今一度、弊社エンジニアの視点から考察してみたいと思います。 ソフトウェア開発現場には、様々な課題が山積しています。例えば、短納期化が進んでいるにも関わらず、システムの複雑さは増していますし、安価な海外技術者を活用したオフショア開発が徐々に定着し始め、コスト競争が激しくなってきています。また、技術が多様化し、顧客の要求はより厳しいものになってきています。そういった厳しい開発現場の中で、技術者が長時間の残業を迫られたり、モチベーションを落としたりすることも少なくはありません。 「アジャイル開発」という言葉は、これらの課題を乗り越える切り札となる期待を背負って、キーワードとして広く使用されるようになったと考えられます。以下に示す「アジャイル開発宣言」や、アジャイル開発プ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く