ニセ科学入門
大阪大学サイバーメディアセンター 菊池誠 この論文は大阪大学大学院文学研究科文化形態論専攻広域文化形態論講座文化基礎学専門分野共同研究「科学と社会」(代表者: 溝口宏平)報告書(平成16年2月発行)に掲載されたものです。基本的には大阪大学の全学共通教育科目として毎年開講しているオムニバス講義「科学と人間」の中で私が担当している「科学とニセ科学の間」の回のレジュメを拡大したものです。 マイナスイオンの項に追記しました。でも、まだよくわからない(2006/2/23) はじめに 論文にしてはケッタイなタイトルなの で、面食らっておられるかたも多かろう。現代市民社会の特に日常生活と科学とのか かわりを考えるとき、私個人は「ニセ科学」の問題は極めて重要であると考えるのだ が、恐らくはこの問題に注目していない研究者（自然科学者・科学論者・社会科学者 を問わず）がほとんどだろうし、それどころか問題の存在
やねうらお―よっちゃんイカを買いに行ったついでに家を買う男 - グラフ理論ならこれを読め！
うちの会社では「グラフ理論を小学校のうちに学んでおかないから、そういうことになるんジャイ！(｀ω´)」とか冗談とも本気とも取れないような会話が平気で行き交う。それほどグラフ理論は大切な分野なのにプログラマには見過ごされがちだ。ただ、グラフ理論にはいい本が少ない。そこで、グラフ理論ならこれを読め！という本を紹介する。まずは、入門書としては、左の本がお勧め。 大学の教科書としてよく採用されているのが左の「最適化とグラフ理論 技術者のための高等数学」値段も手ごろだし、高校卒業程度の知識でも読めると思う。 「そんな入門書ではなくて、もっと詳しい本は無いか？」とid:Ozyさんに聞かれて私が勧めたのは、シュプリンガー・フェアラーク東京シリーズの「グラフ理論」 このシリーズは黄色い表紙とお馬さんのマークが目印だ。 これより詳しい本となると日本語で読めるものは発売されていないと思う。「グラフ同型判定問題
小野和俊のブログ:徹夜をしてはいけない理由
どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。
チームリーダー日記 : 開発現場の力を底上げするための活動は、誰が先頭切ってやるの？
開発現場の力を底上げしていくのは、少なくとも半年単位で継続活動していく必要があると思う。 結果が出るまで、実績は一時的に落ちたり伸び悩んだりする。 (中長期で見れば、大いに伸びる可能性があると思うけど) 結果が出るまでの投資(成果賞与の遺失分？)は誰がするのか？ 末端社員ですか？ 違うよね。 偉いさん？ 話が合う人ならいいんだけど、話が合わないひとが活動に加わると、アレなんだよね。 ■ さて、私事ですが、昨日、源泉徴収の紙を貰いました。 昇格したにもかかわらず、年収は微微増でした。 （このご時世、給料が出るだけでもいいじゃないか、という意見は置いといて） なぜかというと、残業が大幅に減少したからです。 残業を減らすことは良い事だと思って活動した結果、自分の収入は減りました。 時給は増えたじゃないか、とか言われてもね。 組織と個人の利益が一致してない、当社の仕組みです。 （短期的な視点だけど
WEB+DB PRESS「DI時代のアーキテクチャ設計入門/第1章、第2章」を寄稿 (arclamp.jp アークランプ)
WEB+DB PRESS Vol30（2005/12/22発売）の特集1「DI時代のアーキテクチャ設計入門」において、第1章と第2章を寄稿しました。共著はギガプライズ田中さんです（ブログ：天使やカイザーと呼ばれて）。 第1章は「DI時代のアーキテクト - ソフトウェアアーキテクチャを見据えた設計とは」。僕はアイデアのみで田中さんが執筆。アーキテクトに焦点を当て、プロジェクト開発での実装を実現するための開発のフレームワークが重要だと書かれています。具体的には規約をどのように運用していくべきかということですかね。ま、DIには一切関係のない内容のですが（ｗ、DIであればこうした運用に柔軟性が出るという指摘を行っています。 第2章は「DI時代のJava EE（J2EE）アーキテクチャ - DIの本質とその効果的な導入とは」。僕が執筆。個人的には良い感じに書けたと思っています（某記事での反省をいかし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
