  |
はてなキーワード: メモリとは
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
聖アドレスは聖アライメントの聖水が求められるJustice Before Anthologyのネガティブな聖なる生を授けます。
ゆえもって聖アドレスを与えるフォイする悪辣マシンは恋するカザフスタンで夕日を見る必要があります。
また、聖アライメントの精であるゲル状生命体と指定した聖アドレスのメモリ間の行進情報のやり取りでは Say YES! を受け取ることができます。
一旦普通に読み終えてから、いやいやいや、今なんか妙なこと書いてあったぞ！？
と思って同じ章にもう一度目を通したけど、当然そんな文章はどこにもなかった。さっき確かに同じ画面を見ながらその文章を読んだはずなのに……。
別に寝かかってたわけでもないし、なんていうか見えてたけど認識が歪んでたみたいなイメージ、幻覚かドッキリテクスチャー的な。
→ Googleでそうしてたというだけの話。もっと前にあったカタカナ語で末尾の「ー」を省略するルール（インターネット→インタネット、メモリー→メモリ、ヘッダー→ヘッダ）と同じで、決まりでもなんでもない。
→ タブ文字によるインデントはスペース2文字分にも3文字分にも変更可能。エディターによっては1段目だけ4文字分、それ以降は2文字分ずつ深くなるようにもできるので、自分が見やすいように変えられる。
→ スペース幅はフォントによって決まるので、フォントと文字サイズに依存してしまう。「スペースでインデントせよ」とするならフォントも指定しなければ無意味なのに、そういう規約は皆無。
→ CUI時代ならともかく、今はプロポーショナルフォントをどこででも使えるので、コーディングにも普通に使ってよい。これも前出1-3と同様にフォントの問題なのにフォント指定はされない。
→ lintを使うべき。また等幅フォントであっても文字幅は一定にならないし、文字間隔も揃わない。桁が揃うのみ。しかし数字ならともかく「英単語の桁揃え」とは？ そもそもインデント以外でコメントなどを桁揃えするのは悪例として知られているはず。
→ それが問題だろうか。画面表示上の心配なら無用。表示時（ユーザーに見えるとき）はプロポーショナルフォントになる。
→ 文字間隔が一定になるのはプロポーショナルフォント。コーディングにおいては「見ること」よりも「読むこと」のほうが大事。
これを読んで、2年前のまで勤めていた前職の会社の元上司を思い出したので書く。
納期の厳しいしごとをしていた時期。連日残業の嵐。炎上気味のプロジェクトに中途で入ってきたのがヤツだった。
「このままではうちのチームから死人が出るぞ」そう言って上に掛け合い、チームメンバー3人の増員と作業効率アップのため、開発メンバー全員のPCのデュアルディスプレイ化とメモリ増設を勝ち取った。環境改善にチームの士気は上がる。「俺のようによそから来た人間には仕事の改善提案が求められているんだ。こう言う交渉は任せてほしい。」当時はその言葉にすごく魅力を感じていた。
半年後、一兵卒で業務を遂行していたヤツは、いつしかチームリーダーになっていた。気難しい古参社員や、仕事のできないお調子者などよそのチームでは持て余していたメンバーを見事な人心掌握術で使いこなし、ぐいぐい成果を上げていた。そんなある日、ヤツが言った。「チームの環境改善のために残業と休出を無しにしよう。」
この提案が引き金となって、暗黒の日々が始まった。仕事量が減らないのに、残業できないため早出を強いられるようになった。昼休みもあってないようなものだった。ヤツは「人件費削減」を成果とアピールして出世し、自身の人件費はアップさせたようだった。一方俺は健康を害し、体重が10kg落ちた。こんな働き方は限界だと感じて残業申請をするとヤツに詰められた。「定時に仕事が終わらないのはお前が無能だからだ。俺は管理者の仕事としてチームの生産性を上げた。お前も担当の職務として俺の期待に答えろ」言葉だけなら正論だが連日朝一のミーティングで大勢の前で晒されるのは耐えられなかった。チームメンバーはヤツに心酔しており、俺は職場で孤立、3ヶ月後、逃げるようにして退職した。
退社後、人づてに前職の現状を聞いた。ヤツのやり方に耐えられず退社する人間が俺以外にも数人出たようだった。ヤツの独裁政治はますます進んだようで、中途で入る前の会社から部下を引き抜き回りを固めていると言う。最終的には「仕事のできるイエスマン」しか生き残れない不毛な職場になってしまったのだ。
今となっては辞めてよかったと心底実感している。記事を読んで昔を思い出したので思わず書いてしまった。ここまで読んでくれてどうもありがとう。
なんであんなに朝から晩まで気に食わない政治家のことを考え続けられるんだろう
そいつの失点になりそうなニュースなら鬼の首取ったように興奮しながら嘲弄コメントを付け
そいつの加点になりそうなニュースなら顔真っ赤にしてなんとか腐そうとし。
その時間と精神的・脳メモリ的リソースを自分の人生に使おうと思わないんだろうか？
あれだけのエネルギーの浪費をたとえば２年やめたら、すごい豊かな人間関係が拓けたり大型の資格が取れたりすると思う。
その２年の間あなたが憎い政治家の監視活動をお留守にしたせいで国政が傾くかと言ったら
あこがれの英字キーボードを手に入れたから早速会社のパソコンに接続してみた。会社のパソコンは Windows 7。解像度もメモリも CPU も悲劇的な支給パソコンをなんとか使えるレベルで動かしてくれる頼もしいやつ。
「カシュカシュカシュ」
う〜ん、シングルクォーテーションとダブルクォーテーションがうちやすい！ あとアットマークをシフトを押しながら入力するのは新鮮かな。
「コトコトコト」
スペースキーが広い！ 打ちやすい！ ついつい連打しちゃう。キー配列になれるのは時間がかかりそうだけどハッカーみたいでかっこいい。だけどちょっと、ううん、かなりストレスフルなことが一点あって、日本語を入力しようとしたらキー配列がJIS配列になっちゃうんだ。いちおう英字配列にはキーコンビネーションで切り替えられるんだけど、キートップの印字とちがうじゃない。ほら '*' が '(' だったりさ。
今思えば英語入力にわりきって使えば良かったって思うよ。でも往々にしてわりきるのって無理でしょ。
こまったときのグーグル頼み。グーグルさんに日本語キーボードのパソコンで外付け英字キーボードを上手く使う方法はないのって聞いてみた。そうしたらいろいろおすすめしてくれたから、まあ、このくらいの苦労はしないと英字キーボードを買った意味はないよねって、というかこっちから苦労を買ってやろうって、ふふんと思いながらいろんなページを確認したの。業務中だったけど。
それで、レジストリを書き換えてやればいいって書いてあるページを見つけた(http://blog.heiichi.com/?eid=792239)。書き換えるのは
パス : HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/i8042prt/Parameters キー : LayerDriver JPN, OverrideKeyboardIdentifier, OverrideKeyboardSubtype
か。でもレジストリエディタってなんか使いづらいし、怖いなあ。おっとそういえば業務のデファクトスタンダードアプリ Excel で、拡張コンテキストメニューから「読み込み専用で開く」ためにレジストリを書き換える PowerShell スクリプトを作ったんだっけ。マイクロソフトオフィスがアップデートするたびにレジストリ書き換えられるもんだから、あたまにきて作ったんだっけ……。
New-ItemProperty -Force -Path 'Registry::HKEY_CLASSES_ROOT/Excel.Sheet.12/shell/OpenAsReadOnly' -Name ddeexec -PropertyType String -Value "[open("%1",,1,,,,,,,,,,,,1,,1)]"
よっし、エンジニアならコンポーネントの再利用だな、ってスクリプトをコピーしてぺたぺた(スクリプトは超危険なので割愛！)。パスをかえて、値はこれで、そうそう現在の設定を確認して英字配列と日本語配列を自動で切り替えるようにしたいな、むふふ、なんてつなげたばかりの英字キーボードですくりぷとすくりぷと書いていたの。
そんで実行。エラーか。ふむふむああええおお、パスまちがえちゃった。
こんどこそ実行。エラーなく終わって、ちゃんとキーの名前と値が入っている。さてさてそれでは再起動しましょう。
「ブイーン」
これ面倒なんだよなー。ハードディスクの暗号化解除っと。あれ、起動画面に移らないなあ。メモリチェックが走っているのか。ふーん。
……おわらないんだけど………………………………………………。おそるおそる画面をみたら、
「Windowsが起動できませんでした。システム管理者に連絡してください。」
うっわーーー。ブルースクリーンだーーー。はじめて見たーーー。本当にブルースクリーンででるんだなあ。
正直このときはラピュタをみつけたパズーの気分だったかも。ぼくの場合はこの先にはわくわくなんてなかったけどさ。だんだん、やべー、これやべー、これやべーや、これすごくやばいよね、って正気にもどった。そんで隣のお仲間にバレる前に強制終了。ふう。多分再起動中だっておもってくれたよね。
だいじょうぶだ Windows は軍用にも使われる堅牢性の高い OS だ。これくらいのエラーは普通再起動したらいつもと同じように退屈な起動プロンプトがでるはず。そうやって自分をまず信じる。それが一番大事。
まずは軽い深呼吸。そして電源オン。
「ブイーン」
ハードディスクの暗号化解除は BIOS レベルだから変わらないのか。Windows は予期されない終了をしたって？ そのとおり！ 気にせずに君はいつものように平常心で起動してくれたまえ。
あかんわ。これ完全にあかんわ。二回起動して二回だめって、これなんかいやってもダメなパターンはいったよね。エンジニアのはしっくれだけどそれくらいはわかる。
とりあえず電源を落として、気持ちを落ち着かせるために散歩しよう。ああ、今日は雲がきれいだなあ。風もふいていてはるだなあ。どうしよ。ぼくも答えはわかっていたんだけどね。管理部にごめなさいしてリカバリ DVD をかりてくればいいんだよね。でもさ、ただの箱になったパソコンはお客様のものっていう派遣の立場だしさ、絶対に原因追求でレジストリいじったことを告白させられるしさ、ああなんか春と秋ってにてるよね。
あとさブルースクリーンになった原因もわかったの。ふいにあああれだなって思い浮かんだんだけどさ、スクリプトつかいまわしちゃったせいで OverrideKeyboardSubtype キーの型を DWORD じゃなくて String にしてたのよ。ぜったいにこれで起動シーケンスで致命的エラーはいてんだろうなって。
そんな風に思いながら、自席に戻って、もう一回電源起動。もう一回よく画面を確認する。……むむ自動修復だと。よかろう最後の望みだ。かなえてやろうじゃないか。へー最後に記録した正常状態にシステムを復元するのか。なんか説明書きに「最近インストールしたプログラムとか消えるかもね。ハハッ。」て書いてあるけど、しばらくインストールなんてしていないし、初期状態に戻んなかったらまあいいよって感じ。ポチッとな。
そんでもって三十分から一時間経ったかなあ。あまりにも時間がかかるからトイレの個室で頭をかかえてたの。自席に戻るとパソコンの電源が落ちているわけ。さてとこれはラストチャンスだ。なんのチャンスかわかんないけどラストであることはあきらかだよね。そして電源をいれた。
この時ばかりは神様に祈ったね。だって計算機はプログラムしたようにしか動かないから、お祈りなんてしても意味ないもんね。だから神様にお祈りしたの、どうかおねがいします、今後はこれにこりてレジストリなんてぜったいにいじりませんので、この計算機が正しく動くことを祈ってくださいって。
結局、無事復旧できた。なにひとつ異常なく Windows 7 は立ち上がって来て、みなれた壁紙がでてきた。おそるおそるレジストリを確認したら、ちゃんとぼくがいじくるまえにもどっていた。ありがとう Windows！ ありがとう自動修復機能！ いちおうありがとう神様！
それでも外付け英字キーボードで日本語入力したいんだーて人はここらへんを見たら幸せになれるよ。
ＵＳＢ英語キーボード付けた。（英語、日本語キーボードの共存、KeyboardTypeOverride） 202122 (http://202122.iku4.com/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3/%EF%BD%95%EF%BD%93%EF%BD%82%E8%8B%B1%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E4%BB%98%E3%81%91%E3%81%9F%E3%80%82%EF%BC%88%E8%8B%B1%E8%AA%9E%E3%80%81%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89)
USBポートに対しての設定だからブートで失敗することはないと思うよ(ブルースクリーンを発生させたもののことば)。
いちおうこれを書くにあたって、自宅のパソコン Windows Vista で再現できないかためしてみた。検証内容は以下の二つ。
結論としては両方とも大成功！ ちゃんとレジストリエディタから編集したら、英字キーボードで日本語入力が快適にできるようになったし、 DWORD を String に変更したらブルースクリーンがでるようになったし！ Vista だと会社の Windows 7 ではできた自動修復ができないし！ なんかブートセクションとデータセクションが分けられるようになったのって Windows 7 かららしいし！
だけどここは会社じゃなくて自宅だから、メイン OS の Ubuntu で Windows 領域をマウントして華麗に chntpw を叩いてレジストリを修復できる。そう Linux ならね。
メモを取ろうと身構えてるのに、耳から入ってきた情報をその場で書きだそうとしたら、もうついさっき何言われてたか全然思い出せない時の焦る感じヤバい。
そうこうするうちに話が進むからどんどん消えていくし。
なんでみんな聞きながら書けるのかマジでわからん、書く機能と聞きながら理解する機能が完全に片方ずつしか機能しない感がある。
しかも機能を切り替えるときに処理落ちして情報取りこぼしたりして余計混乱する。
直接ならまだしも、うっかり電話とか取ってしまうと、相手の名前や番号メモするとかがびっくりするぐらいできなくてポンコツ感すごい。
3ケタの番号4回言い直してもらってまだミスってたり、
相手がいう名前を聞き取れなくてヌマダ、カマダ、アガタ、タマダと迷走して最終的にハマダさんで相手がそれだ！って言ったから繋いだらヤマダさん宛だったとか。
得意分野に関する話で一旦全部聞いて筋道立てて覚えてられるようなことなら後から書き出してなんとかできたりすることもあるけど、
知らないことや単発情報はどうもメモリを食いつぶすのが早いし、そこそこ覚え違えてたりするしなー。
道の説明とか、3回曲がったらもう確実に覚えられないし。
自分の記憶力とかが信用できなさすぎるのはこれまでに嫌というほど味わったけど、それでもまだ失敗する。
そんなに意識してなかったけど、そういえば学校でも先生の話聞きながらノート取ろうとすると最初の3文字ぐらいで先生が何ていったかわかんなくなって迷子になるから、
先生が話してる間は教科書で補助しつつ話をしっかり聞いてインプットするのに注力して、後から板書と教科書を頼りにノート作ってたな……。
教科書とかプリントっていう正解の道しるべがあるからなんとかなってたけど、仕事の指示とかはそういうの全然ないことが多くてつらい。
初めて聞く話を聞きながらうまくメモるのに、俺の知らないみんなやってるコツとか、なんかあるなら誰か教えてくれ。
そもそも字を書くのがだいぶ遅いとかはあるかもしれない。
第1期叡王戦を勝ち抜いた山崎隆之叡王と、第3回電王トーナメント優勝ソフト「PONANZA」による2番勝負、「第1期電王戦」の第1局が一週間後の4月9日・10日に行われるので、勝敗予想を書いてみた。
2014年の第3回電王戦から、ソフトの事前貸出・改良修正不可・マシン統一などが義務化された。このルールは今回の電王戦までずっと変わらない。
ではこのハンディ有りルールでのプロ棋士と将棋ソフトとのレーティング差はどのくらいか？
プロ棋士の発言をもとに結構てきとーに計算してみた。
| 年月日 | ソフト推定レート | 前年との差 |
|---|---|---|
| 2013.4.6 | 1650 | - |
| 2013.11.11 | 1735 | +85 |
| 2014.12.7 | 1800～1850 | +65～115 |
| 2015.12.23 | ? | ? |
| 年月日 | ソフト推定レート | 前年との差 |
|---|---|---|
| 2013.11.11 | 2020以上 | - |
| 2014.12.7 | 2100以上 | +80 |
| 2015.12.23 | ? | ? |
だいたい1年につき、プロ棋士側から見てソフトがR80～100程度上昇している、と言えそう。
また、先手番と後手番では事前に研究しなければならないゲームツリーの量が大幅に違うことから、勝率がかなり変わるようである。
永瀬六段の発言を真に受けるとすると、本来勝率約52％の先手番と後手番の差が約80％（R300）もの差になっている。
昨年（2014.12.7）の時点でAperyとSeleneがプロ棋士先手でR1825くらいとして、昨年の時点でPonanzaが半年分リードしていて+40～50、この一年で+80～100と考えると、
今年のPONANZA（2015.12.23ver）は先手番でR1945～1975程度、後手番は+300としてR2245～2275ぐらいなのではないだろうか。
使用されるPCが去年より弱体化（5960x→6700k,メモリ64GB→32GB）しているが、それでもせいぜいR30くらい下がる程度だろう。
プロ棋士側の現在のレーティングは山崎叡王がR1766。（ちなみに羽生四冠はR1923）
数字の上では山崎叡王の先手番期待勝率は約23～26％、後手番は約5～6％。なので山崎叡王が後手番である第1局については、どうも勝てる確率は絶望的に低いと思われる。
一方で先手番の第2局については一発入る可能性も否定出来ない。
しかし、二日制になり局面誘導の練習がやりずらくなったこと、PONANZAはSelene等他ソフトに比べて事前研究対策が上手であること、
今回のPONANZAが相当強いという情報があることなどを考えると、すんなりと勝たせてはもらえないだろう。
もちろんソフト側にバグや、かなり有効なハメ手が存在すればもっと差は縮まると思われるが、山崎叡王の発言から推察するに、今回のPONANZAにはそれもなさそう。
以上を踏まえて
本命 山崎叡王 0-2 PONANZA
対抗 山崎叡王 1-1 PONANZA
と予想する。
個人的には、事前貸出有りで、かつ先手で勝利したとしても、それは駒落ちしてさらに下手側が先手になるようなものだと思っているので、別に感動したりはしなさそうだなぁ。
まあそれでも山崎叡王が1勝でもすれば、あまり深く考えない将棋ファンは喜ぶだろうし、興行としてはありかもね。
日本将棋連盟とドワンゴは、一般人が平等でないと気付いてしまいそうなルール（駒落ち、森下ルール、持ち時間に差をつけるetc…）を避ける傾向にあるようなので、
これ以上プロ棋士側に有利なルールを制定するとなると、使用するPCのスペックをさらに下げるしかないだろう。
しかし、例えばCPUをXeon4個から6700k1個に変えても、一般人にはスペックダウンしたことがよくわからないが、
デスクトップPCから、ノートPCやタブレットに変わるとさすがにハンディがあるという印象を拭えない。
また、スポンサーであり対局PCを提供しているガレリアは一応ハイスペックPCが売りのブランドなので、
これ以上スペックを落とすことはブランドイメージに傷がつきかねないだろう。
よって、「プロ棋士は将棋ソフトにもう勝てないのか」という問いについては
「『多くの一般人から見て公平に見えるルール』で七番勝負を行う場合、名人でさえも（バグやかなり有効なハメ手等を見つけないかぎり）勝ち越すことはかなり難しい」
と言えそう。
ちなみに、事前貸出なし（レート+400以上、角落ちくらい？）、PCのスペック制限をしない（クラスタ化でレート+400）と仮定すると、1945+800=R2745となる。
2013年の第２回電王戦ルールでは、もはや１勝も出来ないだろう。
何を作りたいかというとマルチプレイヤーのブラウザゲームが作りたいんだよね。
俺の開発用のceleron 1コアのメモリ1GB環境では重すぎる。
isoファイルを10000個同時にダウンロードしてるぐらい重すぎる。
ページの読込みがなかなか完了しない。
こんなクソ重いフレームワークはそれなりのサーバスペックがないとパフォーマンスに影響が出すぎるので除外したい。
phpのフレームワーク一般に言えるんだけどプロジェクト毎にプロジェクトルートのなかにフレームワークのコアファイルを置くのがなんか嫌だ。
nodejsはシングルスレッドなので負荷の高いサイトで使うのは厳しそう。
pythonでもgolangでもwebsocketは使えるのでnodejsにこだわる必要もないしvert.xを使う選択肢もある。
日本ではvert.xの話題あんまり盛り上がってないよね。どこかの企業さんが実践で使いましたって記事を書いたら会社の知名度が上がると思う。
scala,golang,elixirこの3つの選択肢でいいのかな。
でも負荷の高いブラウザゲームやってる会社ってrailsとかphpだよね。
redisをうまく活用しとけばあんまりそれ以外でボトルネックとなるようなことって無いのかな。
スクエニさんのオンラインのドラクエもどうやってるんだろうね。
あと海外のブラウザゲームってほとんどがaws使ってるのでaws使えばいいのかな。
でも怖いよね高額料金を請求されたらさ。
金儲けの為にサイトを作らないとawsは使ってられない気がする。
