スーパーコーダーならともかく。でもそれってツールを使いこなす技量と大差ない。 ということを上げているんだけど、なんでこれが理由になるのか分からない。「スーパープログラマーでもいつも生産性が高いとは限らない」ことの理由としてならわかるけど、体制が変わらない/変えられないことの理由としてはさっぱり分からない。誰か解説して。 Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記 ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？僕はスーパーじゃないからわからないけど。 もとのエントリは単に「個人の能力差はとても大きいのにそれを無視して属人性をなくそうとするのは間違ってる」というだけの話。 Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記 という話が間違っていると思うからみんな反応するんだと思

遺伝子を効率よく改変するゲノム編集研究の第一人者で米ブロード研究所のフェン・チャン主任研究員は、エボラ出血熱やジカ熱の早期診断技術を開発したことを明らかにした。ウイルスの遺伝情報が…続き 受精卵のゲノム編集、なぜ問題　優生思想と表裏一体 ［有料会員限定］ ゲノム編集食品　販売容認、条件満たせば安全審査なし ［有料会員限定］

そうそう、以前Twitterで「Pythonの例外を投げる関数と投げない関数では呼び出しコストに差があるのか」的な話があったときに書いたコード、このまま埋もれても無駄だし貼付けておこう。 import timeit print timeit.Timer("foo(1)", setup=""" def foo(x): if x: return None else: return x """).repeat() print timeit.Timer("bar(1)", setup=""" def bar(x): if x: return None else: raise NotImplemented """).repeat() [0.24111700057983398, 0.22863888740539551, 0.22955012321472168] [0.23151803016662598

シャープは現在、「電子辞書」のオープンプラットフォーム化を進めている。同社の電子辞書「Brain」（ブレーン）シリーズで、広範なWindows CEベースのアプリケーションをインストール可能にするほか、今春には「エディター」などの実用アプリケーションを公開すべく、準備を進めている。 「電子辞書のオープン化」とはどのような戦略なのか？　そして、なぜそのような戦略をとるのか？　事業責任者の方に話を聞いた。 踊り場にさしかかる電子辞書市場 Windows CE採用がオープン化の引き金 シャープの電子辞書には、2つの製品ラインナップがある。一つは「Papyrus」（パピルス）。モノクロ液晶ディスプレーを使い、シンプルな電子辞書として開発された製品で、従来の主力商品である。 もうひとつが今回の主役である「Brain」。カラー液晶ディスプレーを採用した高付加価値モデルにあたる。市場では「ワンセグ内蔵電

昨年の10月に刊行された書籍Ajaxセキュリティは，発刊直後に購入したが，しばらく積ん読になっていた。最近になって読み始めたのだが，いささかあきれる結果となった。HPの現役エンジニア2名の著作，一人は元SPI Dynamics社(WebInspectの開発元，HPが買収)出身，GIJOE氏の監訳ということで期待していたのだが，残念である。 残念だと思う主要な理由は，脆弱性への対策が十分に示されていないことだ。Ajaxであってもインジェクション系脆弱性が発生する可能性があること，むしろ従来型のWebアプリケーションよりもその可能性が広がることは説明されているが，肝心の対策が不十分だ。 本書第四章の後半には，対策として入力検査（バリデーション）が示されている。 4.6 適切な入力検査 4.7 リッチなユーザ入力のバリデーション しかし，入力検証だけでは，任意の文字入力を許す場合の対策はできない

「毎日毎日動きを続けていると、適切な大きさの問題がつぎからつぎに生まれる」 「それさえ生まれれば、インターネット上にはそれを解決する人が現れる。新聞にクロスワードパズルが載っていたらそれを解く人がいるように、それをみんなが解いていく」 それがオープンソースなんだと。 出展はこちら。 http://www.1101.com/umeda_iwata/2008-11-18.html もともとは、Matzともっちーの対談から生まれたものですね。見たことある人も多いでしょう。目からうろこが落ちた人は少ないかもしれないけど。 Rubyについていえば、上記のことは正しいと思います。Rubyが成功しているのが一番の証拠。ただし、それがオープンソースのすべてなわけではない。オープンソースは、そんな一言で語れるものではない。 別に俺が正解を知っているわけじゃないけど、機能が足りないうちは、いろんな人にその問題

以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに

pixivの文芸版のようなサービスはありますか - はてな人力検索 で質問した内容の補足説明です。 pixivのような感じで、絵の代わりに文章を投稿できるサービスを探しています。長い小説だけでなく、短い作品がいっぱい投稿できるような場を想定しています。下記の「参考」でリンクしたように「はてなハイク」のキーワードページがイメージに近いのですが、さらに各投稿にタグづけして分類できる機能が欲しいと思っています。 ※「ないから俺がやる」という同好の方には1000ポイント〜差し上げます。*1 具体的には、次のような条件を満たすサービスを探しています。 できるだけ必須 ひとつの文章をひとつの作品として投稿することができる 必ずしも小説形式に限らず、小話、構想、一発アイデアなども作品として投稿できる 作品ごとに、閲覧者のタグ付けによって分類することができる 閲覧者が作品ごとに評価ポイントをつけることがで

うごメモの規約違反投稿通報に、ポイントが支払われるようになった。 本日より、掲載ガイドラインに違反している不適切な作品を通報いただいたユーザーさんへ、はてなポイントの付与を開始します。 うごメモはてなで通報を受けた作品を、はてなの管理者が確認して不適切であると判断、非公開とした際に、その作品について最初に通報いただいた方にはてなポイントを 5ポイントを付与します。 http://d.hatena.ne.jp/ugomemohatena/20090123/1232690426 なんなんだ、これは。金銭や即物的報酬は自発的動機を低下させるのは常識と思う*1。第一、それ無しで人を集めて有用な行為を起こさせるのが、Webのコミュニティ運営のキモではないのか？実際、人力検索ではポイント目当ての糞の様な回答が跋扈しているではないか。 しかも、５円。報酬は、その行為の価値を定義する機能も持つ。例えば、

ソフト名：GNU ddrescue 開発者：Antonio Diaz氏 ライセンス：GNU GPL v3またはそれ以降 配布元：http://www.gnu.org/software/ddrescue/ddrescue.html GNU ddrescueは，読み出しエラーが多発するような壊れかけの記録媒体からデータを回収するツールです。読み出し可能なデータを先に回収する方式を採用しているので，一刻を争う事態でもより多くのデータを救出できます。 HDDに不良が生じた際，最も重要なのはデータをいち早く回収することです。不良の原因がコントローラか機械的なものかを問わず，多くの場合で時間経過と共に問題が大きくなってしまい，回収できないデータが増えるからです。 データ回収のポイントは「問題なく回収できるデータを優先して作業」することです。読み出しエラーが生じるデータにこだわってリトライを繰り返すと，

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル

27年ぶりのYUKIライブ 2024/8/11。僕は埼玉の戸田市文化会館で行われた”YUKI concert tour “SUPER SLITS” 2024”に参加した。前にYUKIの歌声を聴いたのは1997/05/27の代々木第一体育館。実に27年の歳月が経ってしまった。 なぜそんなに間が空いたのか。なぜ、それでも参加しようと思ったのか…

不特定多数に向けたWebアプリを作ってて、力を注ぐところがプログラミング技術（設計なども含む）から別の領域へ移っていくんだなぁ、と感じる。 「どうやって作るか」から「何を作るか」へ 私の場合、Rails使ってみたいな〜という技術的興味を満たすところからスタートしたような気がする。会社の仕事じゃJava一辺倒だったし、RubyやRailsに触れようと思ったら、プライベートな時間に何かを作ってみるしかなかった。最初は、自分ひとりが使えればよかったし、日常的に使うレベルにまで作りこもうとは思ってなかったので、RubyやRailsを使うことに意義があった。 でも、どっかで、ふと、みんなに使ってもらえるものを作ってみたいな〜と思った。 そこから、目的が別のところへシフトしていった。作る以上、なるべく多くの人に使ってもらいたいというのは、当然の欲求だと思う。そうすると、「どうやって作るか」よりも、はる

1980年代の終わり、職場の先輩は自作プログラムで検査データを1枚のフロッピーにバックアップしていた。後にデータを全ロスする羽目になるのだが、記録メディアは複数用いて交互にバックアップを取らなければならないという、基本を知らなかったのである。コンピューターが専門というわけではないから仕方が無いが、「辛い教訓」というのは昔からある話。これを避けるのが管理者というものである。 元記事から一次ソースを見るとthe journalspace data had two large drives in a RAID configuration [journalspace.com]とあるから、「なんだ、単にバカやってただけ」「こういうのはバックアップとは言わない」だけの事。 ミラーを使って、かつバックアップを実現する事は当然可能。マシンをもう一台用意して rdist か rsync で複製作って、そいつ