You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

FlashDevelop(フラッシュ・デベロップ)というActionScriptのエディターが非常に優秀で、これとAdobeがオープンソースで提供しているFlex SDKがあれば、お手軽かつ無料でFlashを作ることができます。 FlashDevelopはソフトの軽さと強力なコードヒント機能によってプロのFlasherから熱烈な支持を受けているエディターです。まずはコードヒント機能がどのくらい優れているか分かる90秒のライブコーディングビデオを用意しました。 FlashDevelop Code Hint Movie from clockmaker on Vimeo. コードの補間によってキータイプの量を劇的に減らせ、自動的に整形されるため見通しの良いコードが仕上がるのがおわかりになるかと思います。 では、そんな便利で高機能なFlashDevelopのインストール方法を紹介します。できる限り

図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ

これまでいろんな人のコードを見てきて、そのたび不愉快になることがあるので、ここで提案したい。 「check」っていう単語の利用、コーディング規約で禁止にしない？ 「check」って、実に使いやすい単語なんだよ。「ナントカをチェックする」というと、大抵の検証処理の名前としてOKな気がする。なぜなら抽象度が高すぎるから。言い方を変えると、大雑把すぎるから。大雑把だから、大抵のものに当てはまってしまう。また、「チェックする」という表現が半ば日本語になっていることも使いやすくしている要因だ。だからみんなcheckXXXという名前を使いたがる。 しかし、大雑把ということは、第三者から見て大雑把なことしかわからないってことだ。変数名やメソッド名を見ても大雑把すぎて何をやっているのかよくわからず、結局コードを読まなきゃいけなくなる。 かつて、nullCheckという名前のメソッドをしつこくdisったこと

ドットインストール代表のライフハックブログ

GC¥¢¥ë¥´¥ê¥º¥à¾ÜºÙ²òÀâ ÆüËܸì¤Î»ñÎÁ¤¬¤¹¤¯¤Ê¤¤GC¥¢¥ë¥´¥ê¥º¥à¤Ë¤Ä¤¤¤Æ¾ÜºÙ¤Ë²òÀ⤷¤Þ¤¹ ¥È¥Ã¥×¥Ú¡¼¥¸¥Ú¡¼¥¸°ìÍ÷¥á¥ó¥Ð¡¼ÊÔ½¸ GC ºÇ½ª¹¹¿·¡§ author_nari 2010ǯ03·î14Æü(Æü) 20:47:11ÍúÎò Tweet ¤³¤ÎWiki¤¬Ìܻؤ¹½ê GC¤È¤Ï¡© GC¤ò³Ø¤ÖÁ°¤ËÃΤäƤª¤¯»ö ¼Â¹Ô»þ¥á¥â¥ê¹½Â¤ ´ðËÜ¥¢¥ë¥´¥ê¥º¥àÊÔ Reference Counter Mark&Sweep Copying ±þÍÑ¥¢¥ë¥´¥ê¥º¥àÊÔ IncrementalGC À¤ÂåÊÌGC ¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È·¿GC LazySweep TwoFinger Lisp2 Pa

InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example Memorial Day Sale: Save up to 60% on InfoQ Dev Summit Boston (June 24-25)

今回は小ネタのmikioです。key/valueのレコードを高速に格納・参照・削除する仕組みが連想配列とかマップとか呼ばれて親しまれていますが、Tokyo Cabinetのオンメモリマップの性能をC++の各種実装と比較してみました。 以下の実装を対象として、100万レコードの格納と検索にかかる時間を計測します。キーと値は各8バイトの文字列とします。 Tokyo Cabientのオンメモリマップ（TCMAP） STL（C++の標準テンプレートライブラリ）のmapとmulti mapとset GNU拡張テンプレートのハッシュマップ Googleのdense hashおよびsparse hash テストコードはこちらに挙げておきます。具体的な操作としては、マップオブジェクトを生成し、バケット配列の要素数をレコード数と同じにチューニングし、ループを回してレコード群を格納します。なお、STLのマップ

日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ

特にサーバー用途では、CPUがシングルコアに戻ってくることは考えにくい。 マルチコアCPUの性能を活かすにはマルチスレッドに対応したサーバーの実装が必要になるわけですが、マルチスレッドなプログラミングは往々にして「高負荷になると固まる」とか「たまに落ちる」といった悩ましいバグと戦わなければならず、イヤです。 かといってシングルスレッドでは、近い将来 32コアCPU! などが出てきたとき、たぶん性能を発揮できません。 そこで、そこそこデバッグしやすく、それでいて多コアCPUでもスケールするという落としどころを模索しているのですが、ボトルネックはネットワークIO周りにあるだろう*1という前提の元で、ネットワークIO部分だけをマルチスレッドで動かし、それ以外の部分をシングルスレッドで動かすというアーキテクチャを考えています。 ロジックの部分はマルチスレッドで書いても共有リソースにアクセスする度に