ゲームをしていると頭がわるくなるといいますが、ゲームデザイナーの人はだいじょうぶなのですか？ （小5・男の子） ゲームデザイナーの人はおもしろいゲームを作るために、いろいろとそうぞうして、いろいろなことを考えますよね。そうしてなかまとたくさん話し合ってゲームを作っていきます。だからゲームデザイナーの人のあたまのはたらきはいいと思います。 一方、まいにちゲームを「やっている」人たちは、ゲームをうまく動かすために脳の中で決まった神経（しんけい）の流れが作られてしまいます。そうするとできるだけ脳のいろいろな場所に信号を送らずに手が動くようになってしまうので、その他の部分のはたらきがわるくなってしまうんです。脳には前頭前野（ぜんとうぜんや）といって「うまい手順を考える」ところがあります。決まったことをくりかえす「ゲーム」は、ここをあまり使わないのです。あたまの中で今までおぼえてきたいろいろなことを

このページでは、独学で英語を学習する場合どんな教材をどのように使えば高い英語力が身につくのかを、一学習者としての立場から、さまざまな英語学習法に関する本と私自身の経験をもとに考えていきます。

はてブ何をもってspamとするか。その閾値が人によって様々であり、価値観も多様であるが故、ブックマークという行為や言説に於いてコンフリクトが発生する。 纏めをやるかと思ったんだけど、はてブ米なんかを拾っていくしかないっぽかったり途中で意見が変わった人もいるので興味がある人はgorilla-bootsさんの『ゴリラブーツがスパムなんて、みんなとっくに気付いているよね』に収録されている記事から、はてブスパム関連と思われる記事をピックアップして読むことをお薦めする。私が記憶している限りgorilla-bootsさんが何らかのコメントを書いているというケースは殆ど無い。遡ったわけではないので印象だけど殆ど無いと思う。そんなgorilla-bootsさんが「いろいろとごめんなさい。もうちょっとだけ、はてなで続けてもいいかな(ノー｀)」と書いておられるのが印象的だった。この一文が無ければ恐らく私は何も

焼酎の味のタイプ別による分類 焼酎選びに困ったときなどに、私他多くの方からの飲んだ感想等から作成した分類表です。 あくまでもご参考までに・・・。

職場に女性が少なく、「出会う機会が少ない」とされるエンジニア。しかし恋愛を楽しんでいるエンジニアも必ずいる。2006年は「いい人」や「ただの友達」で終わらせず、次のステップに進むために、まずは前回のおさらいからしておこう。 前回のマーケティング編でご紹介したとおり、20代～30代の女性1047人を対象にエンジニアとの恋愛経験についてアンケートを実施したところ、4割の女性が「エンジニアと恋愛経験がある」という実態が判明した。さらにその４割の女性を対象に、「エンジニアの好きなところ」を聞いたところ、「優しさ」と「包容力」「マメさ」がダントツであった。やはり、女性にとって、その３大モテ要素は欠かせないようだ。 さあ、ここからが本題。その部分は努力でなんとかなるにしても、やはり気になるのが「どこで」「どのように」出会い、「どんなおつき合い」をしているかという現実的な問題だ。エンジニアの場合、女性か

Finding your IP Address is essential to understanding your Online Privacy. So why not make it fun and sexy? Personal Information about you and your computer is revealed to every Web Site that you visit. This information can be linked with other information and used for things like Identity Theft and other types of Cybercrime. While some people are choosing to use a Web Proxy to remain Anonymous wh

Voice Delivery System ホームページ音声読み上げサービスを提供しています。音声読み上げサービスは、インターネットに誰もが使いやすい手すりをつけるをコンセプトにサービスを提供しています。 vds(Voice Delivery System) 私たちは「インターネットに手すりをつける」をビジョンにvdsサービスを提供します。vdsはホームページやウェブアプリケーションのテキスト情報をリアルタイムに音声変換し利用者に届けます。vdsを利用することでホームページを見るメディアから聞くメディアに成長させる画期的なサービスです。また、特殊なアプリケーションを必要とせず、日本語を基本とし多言語（オプション）にも対応したユニバーサルなサービスです。 vdsは３０カ国以上の言語であらゆるWebサイトやWebアプリケーションを「見る」に加え、なめらかな音声読み上げによる「聴く」ことを可能に

thinkweb2.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、thinkweb2.comが全てとなります。あなたがお探しの内容が見つかることを願っています！

カーネル読書会という奇妙な名前のコミュニティ活動を行っている。横浜Linuxユーザグループ（YLUG)の有志と一緒になってわいわいがやがや回数を重ねること60数回である。次回は7月6日にmixi.jpのバタラさんを招いてmixiの急速な会員増にどうシステムをスケールアップしたかというお話を伺う。 発端は1999年の春頃YLUGのメーリングリストにLinuxカーネルのシステムコールの実装方法についてわたしが質問していろいろなやりとりの後、ソースコードをみんなで読むという会があったら面白いですねという話になり、言い出しっぺの法則ということで、第一回カーネル読書会が、1999年4月28日に開催されることになった。http://www.ylug.jp/modules/pukiwiki/index.php?history 参照。 最初のうちはまじめに（？）、ソースコードの断片を持ってきて皆でわいわい

プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。 ポインタによって字面では変数が登場しなくても参照、変更される事もあるので油断禁物である。 またグローバル変数が嫌われるのは、ソースコードを局所的に調べていてもその代入、参照の範囲がつかめないからである。別のディレクトリに格納されている見た事も聞いた事もないファイルで変更されていて、当該ディレクトリをgrepしただけでは発見できなかったりする。 ローカルな変数ならばソースコードを静的に読解していけば、宣言、代入、参照それぞれが局所化しているので簡単に理解できる。 変更の影響もローカル変数ならば局所化されているがグローバル変数だとどこに影響が発生するかよくわからないのである。 さてブレークポイントを設定し、そこで実行が停止したとする。最初の仕事はその関数がどこから呼ばれ

「大規模ソフトウェアの効率的な理解(その1、2、3、4、5、6)」などという大袈裟なタイトルでブログを書いたが、今回は一気に実践編ということでフリーソフトウェア定番のデバッガ gdb の実践的使い方について記す。 プログラマの日々には、プログラムを書くためのエディタ、プログラムをコンパイル(あるいは実行)するためのコンパイラ(あるいはインタプリタ)、そしてプログラムを理解するためのデバッガという三種の神器が必須である。 この定番はわたしの場合xemacs/gcc/gdbである。前々職(DECという会社に務めていた)の場合、それぞれプロプライアトリな物を使っていたので微妙に異なるがやることは一緒である。 gdbは何のために利用するかというと、プログラムを理解するために利用する。デバッガなんだからデバッグのために利用するというのは、gdbの底力の半分も利用していないと言ってさしつかえない。 g

この「大規模ソフトウェアの効率的な理解(その4)」で巨視的理解、微視的理解という視点を紹介した。前者はソフトウェアをマクロから見ていわば俯瞰する。いわば鳥から見た図だ。後者は細部から全体像を把握する。いわば蟻の目である。地面にはいつくばっている。そのどちらの視点も忘れてはならない。Google Earthみたいに、自由に宇宙から眺めた視点からぐんぐんズームアップしていって、一つ一つのビルまではっきりくっきり見えるミクロの視点まで自在に動きまわらなければならない。 また、「大規模ソフトウェアの効率的な理解（その5）」で動的理解、静的理解という視点を紹介した。デバッガで1ステップ1ステップ実行するのは、微視的な動的理解であり、ソースコードを一行一行読むのは微視的な静的理解である。 リグレッションテストというのは、自動化テストの一種で、あらかじめ予想される出力結果を準備して、ソフトウェアを実行し

ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな

規模の把握 大規模ソフトウェアの理解はいろいろな観点からのアプローチがある。ソースコード一式(通常tarballと呼ばれている)を入手し、適当なディレクトリに展開する事からはじまる。tarballではなく、CVSのようなソース管理システムから直接入手する場合もある。 tar.gzというような形式の場合、$ tar xvzf XXXX.tar.gz というようなコマンドで展開する。$ cd XXXX してざっとディレクトリをながめる。通常、READMEないしINSTALLなどのファイルがあるので最初にそれを良く読む。またDocsなどというドキュメントを置いておく場所があれば、その中になにがあるかをざっと見る。 いきなりソースコードを変更するのではなく、このようにディレクトリ構造を調べたり、規模の把握をしたり、おおまかな骨格を理解するようにする。ディレクトリ構造は当該ソフトウェアの物理的構造を

遥か昔に下記のようなものを書いた。1999年当時私はオラクルの開発部隊に所属していた。1998年に米国ネットスケープがそのコードをオープンソース化し、世間ではいったいオープンソースとは何かということが良く知られていなかった頃の話だ。当時の様子がよくわかるので再録する。ちょっと長くなるが読んでほしい。 日経ソフトウエア1999年9月号、77ページ 掲載 よしおか ひろたか Eric S. Raymondは、「The Cathedral and the Bazaar」という有名な論文で、フリー・ソフトウエア(後にオープン・ソース・ソフトウエアと呼ばれるようになる)がどのように開発されていくか、そして発展していくのか、一般の人々にもわかりやすい形で解説した。従来型の大規模ソフトウエアの開発を「Cathedral(大聖堂)」型開発、オープン・ソースの考え方に基づいた開発を「Bazaar(市場)」型

レガシーエンコーディングのプロジェクトなんかやったものだから中途半端に各種OSSの実装に詳しくなった。ノートPCには、開発環境が残っているので、ちょっとコードを覗いてみっか、という敷居がぐぐっと下って、すぐに当該ディレクトリにcdしてfindそしてegrepだ。 中途入社の方の日報に下記のような感想というか所感を見付けたので、早速返事を書いた。 >> サポート業務全般に言えるのだが、どこを調べれば >> よいという経験やノウハウが足りないので時間が >> かかってしまいます。これから知識や経験を >> 身に付けていかなくてはいけないと感じました。 わたしの返事：> どのように調べたかログをとっておくと後から > 役に立つのでおすすめです。 > > そしてそれを公開すれば、新人にも役にたつし > 達人からの突込みも期待できるので、自分の > 役にもたちます。 ログだよログ。そーゆーわけで、た

コードを読まないで理解するというと何やら心眼で読めとかテレパシーを使えとか、そーゆー荒唐無稽な方向に走れという事ではなく大局的に理解しましょうという話である。 カーネル読書会のネタで今回はmallocのお話だったのだが、そこでRubyのささださんがいらっしゃっていて、GC(ごみ集め)と記憶域管理の関係について熱い議論が沸騰し、その後いろいろブログなどでフォローされていたりする。 わたしもRubyでmallocやGCがどう実装されているか興味があったのでoprofileで実行プロファイルをとってみたりした。日頃利用しているノートPCでRubyのテストプログラム(test/runner.rb)を実行してoprofileしたのは先日ブログに書いたとおりである。 「それとわたしのノートPCではキャッシュミスを測定できないので、Xeonのマシンでキャッシュミスを測定すると面白いと思った。GCの時ぼろ

http://www.readersdigest.com/ リーダーズダイジェストのオンライン版 プレーンイングリッシュで書かれているので、 timeとかよりも、役立ちます。

Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題