建築エコノミスト 森山高至『新国立競技場の工事費が下がらない理由』
昨年、連載いたしました「新国立競技場をめぐる議論について」なのですが、 この問題が広く世間で建築工学や建築文化をめぐる問題の共有につながれば 本望です。 思いのほか多くの方々に読んでいただいたみたいで、 いろいろとご質問などもいただきまして、ありがとうございました。 新国立競技場の建設コンペをめぐる議論について 1（ザハはイラク出身の建築家） 新国立競技場の建設コンペをめぐる議論について ２（アンビルドアーキテクトと磯崎新） 新国立競技場の建設コンペをめぐる議論について ３（新国立競技場コンペ応募資格） 新国立競技場の建設コンペをめぐる議論について ４（ザハの仕事と今の国立競技場） 新国立競技場の建設コンペをめぐる議論について ５（建築と哲学の諸問題） 新国立競技場の建設コンペをめぐる議論について ６（新国立の募集要項と大きさ） 新国立競技場の建設コンペをめぐる議論について ７（脱構築とは
神が降りてきた、の危うさ - kionachiの日記
僕がシナリオライターになったのは２００３年のことで、もう散々あちこちで話したことだけど、スタッフが突然いなくなって急遽その穴埋めで入ったのがきっかけだった。 とにかく書ければいいから、の危険極まりない一言でスタートしたライター稼業だったけれど、幸運にも大学がストーリー作りについての勉強もできる学科（映像学科）で、モノは違えどシナリオを書いた経験もあり、何より自分自身が物語に興味があったことも手伝って、なんとか形にして世に送り出した。 で、それがジワジワと評判になって、シナリオの依頼が来るようになるのだけれど、当時はまだ追い込まれれば書ける、という妙な自信があって、現にそれが上手く行っていたのでそうそう悩む事もなかった。作品数は増え、ファンだという人も増えていった。 しかし、本来出せる実力は、悲しい程に育ってなかった。たまたま空気の合った『泣きゲー』ブームとの親和性は、その後やって来る萌えゲ
電車の中で泣く赤ちゃんについての当たり前のお話: 不倒城
下記を読んで考えたこと。最終的には当たり前の話に着地しますんで暇な人だけどうぞ。 Togetter:子供が車内で騒いでいたら 舌打ちぐらいはしてもいい？ そもそもこの話自体「ケースバイケースじゃね？」の一言で終わりっちゃ終わりなんですが、若干の一般化を試みてみます。 最初に自分の立場を明示しておくと、私は三児の父親です。上の長男は6歳で、だいぶ分別もつきましたので、公共の場に限らず注意されたら静かに出来ますし、派手にすっころびでもしなければ泣くこともありません。 一方、下の二人は双子の姉妹で、両方2歳になってひと月くらい経った辺りです。こちらは泣きます。割と頻繁にぎゃんぎゃん泣きます。 まず前提として。個人差もあると思うんですが、少なくとも2歳から3歳くらいまでの乳幼児は、どんなにいい子だろうが、何をどうやっても泣く時は泣きます。 2歳くらいまでの乳児というのは、ようやく社会性めいたものが
コードを理解できない人間がソフトウエアの記事を書く怖さ
数年前、他社のプログラミング雑誌を書店で立ち読みしていたとき、その雑誌の編集後記を見て違和感を覚えました。「私はコードは全く理解できないが、間違っていそうな個所は編集者の勘でわかる」と書いてあったのです。「それはおかしいんじゃないか」と思いました。 好意的に解釈すれば、自分にはできないプログラミングができる執筆者に対する尊敬の念が、このような文章になったのかもしれません。編集者としての感覚を誇りたい気持ちもあったのでしょう。たしかに、編集業務の経験が長ければ、「何かがおかしい」という勘で誤りを発見できることがたまにあります。しかし、技術的な誤りをすべて勘で見つけられるわけがありません。 掲載するコードの内容が正しいかどうかをチェックするのは、プログラミング雑誌の編集者にとって重要な仕事の一つです。意味がわからない箇所があれば筆者に確認するべきでしょう。コードがわからないのは恥じるべきことで
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋
下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 （以下、原文の和訳です） 原文：http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な
Hokkaido.pm #11に参加した報告とTestとDocumentの甘い関係に関して - その手の平は尻もつかめるさ
Hokkaido.pm #11に参加してまいりました． 以下が僕の発表スライドです． Hokkaido.pm #11 from moznion 言いたいことは大体スライドに書いてある通りで， TestとDocumentは同じ方向 (どちらも正しいソフトウェアの動作について論じている) を向いている 従って協調できるのではないか 協調するメリット Documentの不整合や陳腐化を防げる DocumentとTestをそれぞれ別個に書くよりもコストを低減出来るかもしれない 方法は2つあると思う Documentにテストケースを埋め込む方法 TestからDocumentを生成する方法 という感じです． “TestとDocumentを同居させる方法”というのは割と以前からある考え方っぽくて，PythonではDoctestというテストモジュールが一般的なようですし*1，JavaScriptにおいては
「自分が見たいものを世の中に生み出せ」 Twitter創業者ジャック・ドーシーが初めて語った”成功のためのリスト”
ジャック・ドーシーのStartup School 2013でのスピーチを全文書き起こし＆翻訳。「今までにやったことがないことをします」と前置きした上で、彼が感銘を受けた2冊の本と、ドーシー自身が作成し、日々実践している"あるリスト"の内容を紹介しています。少し長いですが、起業家はじめビジネスに身をおく人は必見のスピーチです。 今日はすごくたくさんの方に来て頂きました。ありがとうございます。 今日はいつもとは違うこと、今までに一度もやったことがないことをします。これまで私の人生の岐路で役に立った本をいくつか朗読したいと思います。 私からはこれらのポイントをご紹介しますが、これらの本からたくさんの教訓を学ぶことができます。皆さんもお時間があればご自身で読んでみてください。 他人になんと言われようと、自分自身にとって重要なものを創造せよ 初めに画家のロバート·ヘンリー著「アートスピリット」をご紹
さくらのVPSに来る悪い人を観察する その２
さくらのVPSにアタックしてくる人たちを、ハニーポットなど使いながらその行動を観察した記録です。観察日記。 今回のネタは以下2つです。 ＊SSH honeypot(Kippo)を使った悪い人の行動観察、アンケート ＊/cgi-bin/php (Apache Magica攻撃)の観察 なおこのスライドは、2013年12月7日のSecurity Casual Talks(すみだセキュリティ勉強会)での発表資料です。 http://ozuma.sakura.ne.jp/sumida/ またスライド中、動画は以下のURLで閲覧できます http://youtu.be/gp3SBjZNWHURead less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Path photo by Ryuta
Path photo by Ryuta
Path photo by Ryuta
Path photo by Ryuta