えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3：メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順１

こういう問題が流れてきた。 まつひろのガレージライフ: 幼児が数分で解けるのに大人が解けない算数（？）の問題 「幼稚園児が５〜１０分で解けるのに、プログラマなどの頭脳労働職の高学歴の方が解くのに１時間もかかる」とあるけど、これ1時間かかるの、プログラマとしてあまりよくないんじゃないのかなーと思った。 ので、プログラマ的に解いてみる。 改めて書き出すとこう。 8809=6 3333=0 7111=0 5555=0 2172=0 8193=3 6666=4 8096=5 1111=0 1012=1 3213=0 7777=0 7662=2 9999=4 9313=1 7756=1 0000=4 6855=3 2222=0 9881=5 3333=0 5531=0 5555=0 2581=??? 問題は英語だし語呂合わせじゃない。幼稚園児にわかるということでそこまで複雑なルールでもない。なんらか

思ったことを。 デバッガについては、こういう記事がある。 圧縮後のJavaScriptやコンパイル後のCoffeeScriptでも、ブラウザ上で元のソースを参照できる新技術「Source Maps」登場 － Publickey 「Source Maps」じゃなくても、なんらかブラウザ側でのサポートは行われていくと思う。 どっちにしろ、JavaScriptをデバッグするにもブラウザのサポートは必要なわけで。 ライブラリの依存関係とかも、ビルドツールとJSライブラリリポジトリが整備されていくんじゃないかなー。そのくらいの勢いはでてきてる気がする。 あと、CoffeeScriptとJavaScriptを両方知らないといけないという話も、複数人で開発するなら、全員が両方しる必要はなくて、コアなメンバが知っておけばいい。 そもそも、複数人で開発するときに、全員がJavaScriptのprototyp

ふと「ソフトウェア品質のxxx」みたいな文章を見つつ、基本としてはソフトウェアがいかに仕様どおりになっているか確認する話だったので、これってソフトウェア品質じゃなくて、ソフトウェア開発品質だよなーと思った。 実際、ソフトウェア開発の品質と、ソフトウェアの品質には相関はあると思う。とくに1990年代まで、まだITという言葉があまり使われず、OA、つまりオフィスオートメーションがソフトウェアの主な開発対象だったときには、データがちゃんと入ってデータがちゃんと届けられるということが主な処理だったため、ソフトウェア開発の品質と、ソフトウェアの品質はほぼ一致していたと思う。 そういう中で、ソフトウェア品質として、ソフトウェア開発の品質が研究された。 実際、ソフトウェア開発プロセスの基本コンセプトのひとつは、「よいプロセスがよいソフトウェアを作る」ということで、ソフトウェアプロセスの本を見ると必ずとい

テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち

よくアルゴリズムの話とかすると「アルゴリズムとか業務で使わないから。ライブラリあるから」みたいな話が出ますね。今日もTwitterでkumagiさんが「競技プログラミングが業務で役に立たないって言ってる人は・・・」って話してたわけです。 でもまあ、アルゴリズムの勉強ってのは、実装したい問題をいかに効率のいいプログラムに落とすかっていう話なんで、プログラムを組むっていう業務をしていたら必要ないとは思わないはずなんで、「アルゴリズムいらない」っていう人がやってる業務はプログラミングじゃないんじゃないのかと思ったりするわけです。 で、noritunaさんが「コーダー」を挙げてて、こういう文脈でよく出るんだけど、これはちょっと違和感あって、「コーダー」は誰かが書いたプログラムをコンピュータに入力するだけくらいの語感で、別に「プログラマ」という職種が必要になるサポート的業種で、でも実際は「プログラマ

さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか？テストか？UIデザインか？となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと

この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基本的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういう本で勉強すればいいか、ぼくの知ってる本からまとめてみました。

イデアルITスクールというところで、１時間ほど話をしてきました。 プログラマとしてやっていくために大事なことというテーマ。 資料を作らずに、というか構想すら練らずにやってしまったので、ここで整理とまとめと補足を。実際にこれをしゃべったというのではなくて、だいたいこんなことをしゃべろうとしてたという内容をかなり盛って書いてます。 当然ですが、プログラマの仕事はプログラムを書くことです*1。 プログラマとしてやっていくためには、どこで動くプログラムを書くか、なにをするプログラムを書くかということを意識することが大事です。 ということで、まずはプログラムが動くところがどう変わったかという話。 1970年代ころは、デバイスを動かすためのプログラムが多かったのではないかと。 あと、ここには書いてないけど、業務アプリはほぼメインフレームで動いてたと思います。 それが、1980年代くらいからパソコンが出

PHP-erはダメな言語でいかにまともなものを作るかっていうマイナスからのスタートだし、 JavaScript-erは何もないところで何か動いて楽しいっていう０からのスタートだし、 Ruby-erはRuby好きって言ってるだけだし、 Java-erはJavaの仕様にしか興味がないし。 Scala-erは生ぬるいこと言うと狩られるし、 Smalltalk-erは過去の栄光語ってるだけだし、 COBOL-erは苦労話しか出ないし、 FORTRAN-erはプログラムに興味ないし、 Perl-erは同窓会みたいだし、 Python-erは仲間探すの大変だし、 Erlang-erはどこにもいないし、 C-erは目先の仕事にしか興味ないし、 C++-erはC++の復興にしか興味ないし、 C#-erはWindowsにひきこもるし、 ActionScript-erはAdobe税はらうのに大変そうだし、 O

ここんところ、SIという業態はもうダメという話になってます。 で、エンタープライズ(=企業向けシステム)というのは、SIという業態で開発されるので、エンタープライズ=SIという前提で、企業向けシステムは面白くないという話になっています。 そこから、企業向けアプリは面白くないからサービスを作りましょう、という流れになって、GREEやDeNAなどに人材が流れてます。 実際は、サービスや企業向けというアプリケーションの種類と、SIや内製、パッケージという構築側の業態は独立なので、別に語るべきです。 たとえば、このインタビューを見ると、ゲーム業界もSI化していて、面白くなくなっていそうなことが伺えます。 稲船敬二氏は，何を思い，何を考え，何を目指してカプコンを辞めていくのか。渦中の氏に直撃インタビュー また、GREEやDeNAが提供するゲームは急激に大規模化していて、おそらくSI形態での開発が増え

「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？ 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac

Java SE 7 にはクロージャーが入るという話があった。 楽しみにしていた。 結局、クロージャーが入るという話はなくなった Java EE 6 は、この秋にリリースされるという話だった。 いまは秋だ。 Java EE 6はリリースされていない。 JWebPaneがJavaでのWebソリューションになるという話だった それ以来JWebPaneの話は聞こえてこない。 JSRで決まった仕様がいけてないという批判がある。 けれども、一番の問題は、JSRで決まりかけたものが、結局は提供されないということが多いことだ。 JSRでアナウンスされたものが、まったく実用化されていないし、いつのまにかそのJSRから外れている。。 もう、だれもJSRなんて信じてない。 Javaの現在の問題というのは、Mapのリテラルがないとか関数型がないとかいう話ではなく、約束を守れてないということだ。 今年の春のJava

昨日の続き。 PHPの価値が相対的に落ちてJavaの価値があがっていく PHPとJava Windows Azureでは、PHP対応もあるらしい。 また、GAE/J上でPHPを動かしたら一緒ではないかというコメントもあった。現状ではGAE/J上でPHPを動かす環境が未完成であったとしても、先のことを言うのであればこちらも完成度があがっていくことを考慮する必要がある。 ただ、これらを考慮したとしても、PHPの相対的な価値が下がったという意見には変わりがない。 PHPがこれまでもっていた「動かす環境が確保しやすい」という特権がなくなったということをもって、PHPの相対的な価値が下がったといっているからだ。実行環境の確保という点では、PHPがもっていたほかの言語に対する優位性がなくなった。 また、Google App EngineによってPythonではなくJavaが強くなったというのは、今まで

Chicoryを使ってRustをコンパイルしたwasmをJavaから呼び出してみました。 JVMでWebAssemblyにコンパイルしたRustのコードを動かす - きしだのHatena ただ、結構呼び出しがめんどいので、Javaインタフェースを定義したらなんかメソッド呼び出しで使える、というよく見かけるやつを作ってみます。 Rustのコードはこう。 #[no_mangle] pub fn add(left: i32, right: i32) -> i32 { left + right } #[no_mangle] pub fn sub(left: i32, right: i32) -> i32 { left - right } #[no_mangle] pub fn mul(left: i32, right: i32) -> i64 { (left as i64) * (right as