2010/1/30 5.0.307.1 dev版での本機能実装を確認した。 Google Chromeは軽くてサクサク動く素晴らしいWebブラウザですが、その反面メモリを暴食します。一個一個のタブや一個一個の拡張がそれぞれに独立しているので、タブを沢山開いたり動作中の拡張を増やせばその分メモリを沢山食います。独立しているから、タブを閉じたり拡張の動作を中止すれば綺麗さっぱり副作用なくその分だけメモリを開放すると言う行儀良さも兼ね備えます。(ご参考：動作の遅くなったGoogle ChromeにChromeタスクマネージャーでメモリ最適化 - 適宜覚書はてな異本) ですけど、あっちもこっちも見たいとなると結局あれやこれや開いてメモリを使ってPC自体を使いにくくしてしまう…とか。あっちを立てればこちらが立たず、と言うか人間欲張りですよね。「メモリを使わずにタブを開いたままに出来ないかなあ」と無い

様々な開発プロジェクトを横断的に見ていると、情報共有という面で大きく2つに分類されるようだ。 プロジェクトに自信が有るところは「情報を見せる」 プロジェクトの進捗、問題等が一目で分かるようにTrac等で公開されている。 Trac等を参照することにより、現時点の状況がすぐに分かる。 プロジェクトの状況について、担当者全員が同じ認識を持っている。 資料や情報の在処が明確にまとめられているので、あちこちを探し回る必要がない。 事前の情報共有が出来ているので、打合せでも本題に関する議論が直ちに始まる。 プロジェクトに自信が無いところは「情報を隠す」 プロジェクト管理は誰かのメモか頭の中で行われており、部外者には全く分からない。 手作業で進捗をまとめているので、現時点の状況が分かるのは次の日だったりする。 プロジェクトの状況について、各担当者間で認識が異なる。 資料や情報の在処が不明確。各担当者が自

言ってることはわかるけどさ。 サービスが大きくなったり国際的になることに意味ってあるのかなあって最近考えるんだ。 まず、自分の作ったサービスが大きくなって、ユーザーが増えたら、サービスの最初のころ楽しんでくれた自分の仲間はきっと面白くなくなると思う。だってそこで増えるライトユーザーは馬鹿だし、外人は言葉が通じないから。サービスを使って金儲けしようと胡散臭い連中も集まってくる。そうしたらクレームや訴訟もやってくるだろう。そんなの面倒すぎる。mixiだってGREEだって、最初はちょっと知ってる人が始めた面白いサービスだから友達に紹介してもらって毎日のようにアクセスして楽しかったよ。だけど今じゃ子供の出会い系と業者の巣じゃない。ヘボいゲームなんてやりたいわけじゃないし。 サービスが大きくなれば、お金は儲かるかもしれない。会社も大きくなるかもしれない。でも、それっていいこと？ 「お金持ってるんでし

2009年10月31日12:30 カテゴリMediaiTech #twitter と #blog の一番(大きく|見落とされる)違い これを見て気がついた。 日本のツイッターの未来予想図は、2004年のブログブームを振返れば見えてくるかも。 : ワークスタイル・メモ 我々が、一番重要な違いを一番あっさり見落としていることに。 「ほとんどの人々」ではない。私も見落としていたので。「私」でもない。見落としていたのは私でもないので。 blogとtwitterの一番の違い。それは前者が一般名詞であり、後者が固有名詞であるということである。blogはサービスの総称であり、twitterはTwitter, Incが営むWebサービスである。(余談だが、ja.wikipediaではまだ Obviousが運営していることになっているがこれは古い。en.wikipediaは現状を反映している)blogとtw

手順書通りに運用作業を実施したかどうかを確認するチェックリスト。仕様書のバグを見つけ出すチェックリスト。ユーザーへのヒアリング事項の漏れをなくすチェックリスト――。 ITの現場では，さまざまなチェックリストが利用されている。あなたは，そんなチェックリストにどんな印象を持っているだろうか。 「日経SYSTEMS」11月号でチェックリストの特集を担当することになり取材を始めたところ，現場のITエンジニアから意外なくらい否定的な意見を聞いた。それは，「管理部門が押し付けてくるもので，現場では役に立たない」「現場で重大な作業ミスが起こるたびに，その再発防止策として増えていく負の遺産だ」といったものだ。 要するに，チェックリストは現場の“嫌われもの”。現場のITエンジニアは，渋々使うか，形式的に使うフリをしている，とのことだった。 現場で改良し「手放せないツール」に 一方，取材を進めるうち，「チェッ

最近、ああこれ面白いなっていうゲームのシステム部分を参考にして色々試行錯誤して自作ゲームを作っている。 それをオリジナルだと言い張るつもりも毛頭ないのだが、テンプレってこうして作られるのではないかともふと思った。 なんか、よくわからん。 ドラクエとかFFとかのRPGってジャンルはテンプレなんだろうけど、 元々更に昔のゲームシステムのパクリとも言えるような。 ノベルなんか文字が生まれた時点でのシステムのパクリと言えなくもない。 いや、そこまではいくらなんでも言いすぎだとは思っているんだ。 ただ、じゃあその線引きはどこからなんだろう？ 漫画のトレスなんかはパクリ疑惑としてよく上がるけど、 そもそも漫画ってシステム自体が手塚治虫とか(もっと昔に遡るのかもしれないけど)の考えたもののパクリじゃないのか。 …システムであればパクリじゃないのだろうか。システムってなんだ。

朝4時台起きセルフメソッド 自分のため(セルフ)の朝４時台起きメソッド。 これはそういうことなんだ。。。 朝が暖かくなる５月半ばから 朝４時台に起きることを目標に試行錯誤していく。 まずは２日間だけ試した記録。 時間設定 ＋朝４時台とは 午前４時～午前４時４０分ならOK ＋寝る時間 午後９…

Twitterの二度目のブームで、Twitterとは…みたいなことを書く人が多いんだけど、よく見かけるのがTwitterのブームがsecondlifeのブームと同じ匂いを感じるという意見。 これってTwitterが流行し始めた2007年にも言われていて、Twitterとsecondlifeのブームが同時期だったので言われやすかったんだけど、結果はご存じの通り。当時自分が書いた記事を紹介しておく。 SecondlifeとTwitterの流行り方の違い／ついでにTwitterを使ってみての感想 : ARTIFACT ―人工事実― それなのに、何のひねりもなく2007年と同じようなことを言う人がいて驚く。「私は2年前のTwitterの流行を知りません」と自ら告白しているようなもの。 最近のTwitterの話題だと、企業の参入が多いから、そこでsecondlifeと似てると思うのだろうか。2007

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 前回、書いた話ですけれど、気を付けると効果が高いのに、案外とミスる人が多いので、もう一度詳しく。 悲しいことに、わたしがメンテしているシステムで、顧客マスタの請求先、売上トランの請求先に空白があるシステムがあります（まぁ、全部トリガーで埋めるように直したのですが）。 本当にひどい話で、見るたびに血圧が上がります。 これらの設計をしたときに確かにユーザー側は、「空白のときは」とか、「未入力のときは」とかいっています。しかし、ユーザーは空白であって欲しいといったのではなく、「2回入力したくない」ということをユーザーの言葉で説明したに過ぎないのです。 ですから、プロとして普通に言い換えないといけない。 リプレイスがあれば、そのタイミングで直すべきなのですが、プロジェク

Hokuriku.rbのアンケートネタです。 それぞれの言語について、以下の5段階でアンケートに応えて頂く感じで。 業務で使っている（公開プロジェクトを含む） 業務外で使っている 触ったことがある 興味はある どーでもいい 言語候補（順不同） プログラミング言語一覧 - Wikipediaより、流行っぽい言語を中心に適当にピックアップ。 C C++ C# Objective-C COBOL FORTRAN Pascal Java Visual Basic .NET Groovy Perl Python Ruby Brainf**k Whitespace シェルスクリプト Erlang Haskell LISP OCaml Scala Scheme SQL ActionScript Javascript PHP VBScript Smalltalk Io (Iolanguage) Ioke

私は基本的に、C++でソース書くときはやたらめったらconst付けます。 なぜならHaskellが好きだからです(ぇ じゃなくて、状態の変更によるバグを減らすためです。 しかし、他人が書いたソースを見てると、オブジェクトのconst操作を考えて設計されてないことが けっこうあり、Is〜とかGet〜といった名前の関数の中でメンバの状態を変更してたりします。 これはとくに、JavaやC#のようなconstメンバ関数がない言語からC++に移植するようなときに 起こりやすいのですが、C++でもconstメンバ関数の存在を知ってか知らずかconstが付いてないことが多々あります。 書籍でいうと、『Game Programming Gems』では明らかにconst操作なメンバ関数にconst付いてないですね。 C++で大きなプログラムを組む際は、元となるコード(移植元やライブラリ)がオブジェクトのco

さあ、ここからどんどん暗黒面に突っ走りますよ！（つまりは愚痴です） 結構前に、余ったCOBOLエンジニアがたくさんいるから COBOL の仕事を創出するんだ、みたいな記事を読んで、「バッカじゃないかしら」と思ったのだけれども、図らずも不景気で わたしの周辺の環境もそうなってきました。 なるほど、仕事はないけれど社員はクビに出来ないってなると、不景気は品質による淘汰ではなくって、品質悪化を加速するのね...orz などと、グチグチ言ってみるも、現実はどうにも変わらない。 「その人を追加されるとチーム全体のパフォーマンスが落ちる」という人をどんどんチームに叩き込まれて、人が増えたのだから稼ぎも上げろということを言われます。ムチャを現場に押しつけて・・・とは思いますが、出来ない人を社内失業させない、という要件からすれば、出来ない人のための仕事を用意できないようなウチのチームの作り方は、背任と言っ

2009年07月06日14:30 カテゴリ書評/画評/品評Lightweight Languages 教科書はいらない - 書評 - PHP逆引きレシピ 翔泳社片岡様より献本御礼。 PHP逆引きレシピ 鈴木憲治 / 安藤建一 / 山田直明 / 八木照朗 / 山本義之 / 河合勝彦 ある意味実にPHP的な一冊。PHP本は、これ一冊あれば十分だと強く感じた。 PHPを使うにしても、使わないにしても。 本書「PHP逆引きレシピ」は、「PHPでプログラミングを習う」のではなく、「PHPで動くWebサイトを作る」に徹した一冊。PHPは後者に特化した言語である故に、前者には徹底的に向かない。本書を読めば、PHPを全く知らないプログラマーにもそれがわかるし、PHPを日時使っている人も、そのことが改めてわかるはずだ。 目次 - | PHP逆引きレシピ オフィシャルサポート より 第1章　準備 1.1　サー

http://risky-safety.org/~zinnia/d/2009/06/#20090607-t0-h3-p4 私に関しては、いらなくね? と思ったことは記憶の近傍では無いように思います。似たようなこと何度も書いてる気がしますが、いい機会なのでちょっと自分の考えてることのうち、強く思っていることをまとめてみたいと思います。当たり前な感じの内容ですが。 現状、たぶん asynchronous な処理する時の道具って select/epoll/kqueue ループ + callback coroutine thread process とあって、パフォーマンス的な観点を考えると前者2つはコア使い切れないので、パフォーマンスを考えないといけないソフトウェアがこの世から滅亡しない限り後者2つのどちらかは必要だと思っています。 thread vs process に関しては、よく proc