Windows10 の無償アップグレード期限が迫ってきましたということで、昨日の記事 を参考に、まだアップグレードしていない環境のアップグレードにチャレンジしてみました。

以前に別の環境をアップグレードした時には右下に出ているアップグレードを促すアイコンからやってみたところ丸一日かかっても終了しなかったので、今回は昨日の記事にあったリンクへ飛んでやってみたところ、とくに手間取ることもなく半日かからずに完了。

環境にもよるとは思いますが、今からでも間に合いそうです。

ちょうどいま、上のバナーに アンテナハウスオンラインショップ で夏のボーナスキャンペーンやってるみたいです。 新しい OS に新しくなにか…とか。ハイ。

どちらもまだ間に合います。といいつつ。このへんで。

Tweet

Windows10 の無償アップグレード期限が迫ってきました。

私は４台更新し、内２台ノートとタブレットはすんなりいきましたが、デスクトップ２台は苦戦しました。
すんなり更新できる環境では１時間もかからないのですが、うまくいかないと丸１日かけてもアップグレードできないということも珍しくないようです。
なにしろ失敗が判明するのは更新開始から１時間以上経過したアップグレード処理の終盤です。
海外には２晩放置してやっと成功したというケースもあるようです。今からでは期限が切れてしまいます。
そのようなことの起こらないようアップグレードをつつがなく進行させるため事前にしておくことをまとめました。

• アップデートは MediaCreationTool から行う。
  https://www.microsoft.com/ja-jp/software-download/windows10
  アップデートは上サイトのツールから行った方が良さそうです。
  例のアレの「今すぐアップグレード」は私の環境ではなぜか動作しませんでした。
  MediaCreationTool でもローカルマシンなら DVD を焼いたり、USB メモリを用意しなくてもアップグレードできます。
• USB 接続している機器はマウスとキーボード以外すべて外す。
  ハブ１つ付いているだけで失敗することもあるようです。
  USB メモリも外します。
• HDD/SSD はシステムドライブ以外すべて外す。
  アップグレード時間が異常に増える場合があるようです。
  CD/DVD/BD、SD カード等は Windows10 のインストール用以外はドライブから出しておきます。
• Ramdisk を使っている場合はアンインストールする。
  テンポラリを設定していた場合は C ドライブに戻しておくのを忘れずに。
• アンチウィルス系はベンダーホームページを確認する。
  事前に Windows10 に対応した最新のバージョンにしておけば大体OKのようです。
• マルチモニタ環境ならメイン以外はケーブルを抜いてシングルにする。
• PCI/PCI-E の拡張カードも外せるなら外す。
  グラフィックカードは最新ドライバにしておけば問題ないようです。
• LAN ケーブルを抜いておく。
  LAN につながっているとアップグレードに異常に時間がかかる場合があるようです。
  私の場合はおそらくこれでアップデートに失敗しました。
  ダウンロード作業が終わってから抜きます。
  無線 (Wifi) の場合はつなげたまま更新して、もし失敗したら２回目はなんとか止めてみてください。
  すんなり成功した２台は無線接続でしたのでこの場合の処置は情報がありません。
• msconfig で Microsoft 製以外のサービスは止めておく。
  Microsoft 製か動作確認済みのアンチウィルス系以外は一時的に止めた方がいいようです。
  アップグレード後は戻しておきましょう。
• NFS が有効だとダメらしい（http://happysccm.com/2015/08/31/windows-10-upgrade-stuck-at-76/）
  この設定は多くのユーザー環境ではそもそも無効になっているものです。
  アップグレード前に管理者コマンドプロンプトで無効にする。
  Dism /norestart /online /Disable-feature /featurename:ServicesForNFS-ClientOnly
  とする。
  完了後は再度有効に
  dism /online /enable-feature /featurename:ServicesForNFS-ClientOnly
  dism /online /enable-feature /featurename:ClientForNFSInfrastructure

ここまですればおそらくアップグレードできると思います。
それでもだめな場合はさらに続きます。

• 75,76% で止まった場合はしばらく放置。
  １時間くらいしてから何事もなかったかのように進行する場合もあります。
  海外の２晩放置の事例はこのタイミングです。
  ただ30分待っても進まなければリセットして、周辺機器やデバイスを減らす、問題あるかもしれないソフトをアンインストールといった作業をしてから再挑戦した方がいいです。
  成功する場合はこのタイミングではそれほど長くは待たされません。
• 93% で止まる場合はあきらめてリセット。
  ここで15分以上止まる場合は非対応のソフトかハードが邪魔をしています。
  リセットして怪しそうなものを外したり、アンインストールしてみます。
• 言語設定を英語にする。
  コントロールパネルの地域と言語で言語設定を「英語（米国）」に変えてみます。
  同時に「UNICODE 対応出ないプログラムの言語」も変更します。
  これでうまくいくケースもあるようですが、ユーザー名が日本語の場合はダメです。
  その場合は英語名の管理者ユーザーを作り、そのユーザーでログオンしてアップデートしてみます。
• フリーズしているかの判断は Numlock で。
  アップグレードの進捗状況が表示はおおざっぱ過ぎるため動作しているか不安になります。
  通常処理中は円グラフのグレーの部分が脈動しているのですが、グレーのまま色が変わらなくなることもあります。
  また HDD のアクセスランプが点滅すれば動作していると言えますが、10分以上点滅しないこともしばしばです。
  そんなときは Numlock キーを押して LED の点灯状態が変わるか動作で生きているかを判断します。
• 「Windows10 upgrade stuck」と%の数字でググる。
  日本語でググるとキャンセル方法ばかり出てくるのでほとんど役に立ちません。
  英語で検索すれば最初の20個までに対処方が見つかることが多いです。

ここまでして更新できなければ私にはわかりません。

なおこれらの対策は Microsoft の公式見解とは一切関係なく、すべて一個人の見解です。
これらの対策によって生じた損害に付いての責任は負いかねます。

Tweet

Python で OOP

Python のクラスオブジェクトの初期化処理は__init__メソッドに書くと思っていた。いや、実際に__init__がその役割を持っているのは事実だが、なんと、クラスを継承した場合、継承されたクラスの__init__は何もしなけりゃ呼ばれない。えぇぇぇえ。なんでこんな仕様なのか、色々すったもんだがあって今更変えられないとかパラメタ付きはどうするとか面倒があるんだろうけど、ともかくきっぱり呼ばれない。一番元のクラスを定義するときにobjectを継承するとsuper()関数が使えたりするが、super(ClassName, self).__init__()なんて記述は呼ばれないからこそ書かなくちゃいけないわけで、たいした解決にはならない。しかも、多重継承した場合、super().__init__()では最も左に（最優先の位置に）記述されたクラスの__init__しか呼ばれない。いったいどうしろというのだ。クラスの意義の一つには実装の隠蔽があるはずなんだが、objectを継承しているのかとか、__init__が定義されているのかとか使う側がソースレベルで知らないといけないってのはどう考えても間違っているだろ、これ。

他人の書いた Python プログラムのメンテで困ったことになる。継承されちゃってるクラスにインスタンス変数を用意したかったのだが、__init__メソッドがない。ってことは継承してる先では__init__を呼んだりはしてないわけで、__init__を加えるとしたら継承してる先（当然複数箇所）全部に__init__を呼ぶ処理を加えなくちゃいけない。いや、そもそも継承してる先にも__init__なんてないので、ってところで気付く。汚染じゃないか。__init__汚染とでも名付けようか。

しかたがないので、インスタンス変数アクセスに getattr() 関数を使う。格好悪いし馬鹿馬鹿しいが、そういう言語でそういうシステムなのだと思うことにする。迷惑ついでに迷惑なのが__call__メソッド。インスタンスを関数として呼んだ時に来るエントリー。困ったねぇ、検索性ゼロじゃん。どこで呼んでるかのキーワードがなくなってしまう。機能の一意性とかメンテナンス性とか捨てて「ヘイ、こんな風に書けちゃうんだぜ、格好良い」って思いたけりゃ使えばいいけど、仕事で使うのは勘弁してくれ。

加えて最悪なのは__getitem__メソッド。インスタンスをマップとして呼んだ時に来るエントリー。これも検索性ゼロだよ。どうやってメンテすんだよ。しかも__getitem__メソッドだけでも使えるのだが、その状態でインスタンスを参照すると {}（Pythonでの空のマップ）になる。これ、if 文で False 扱いだぞ（インスタンスの存在を単純な if 文で判断できない）。

教訓。Python で OOP は真似事程度にしておけ。あと、3000 行超えるとか複数ファイルになるなら別の、できたら静的型付けの言語にしておけ。

必殺技

C で開発していた頃、ある程度の規模のプログラムに発展すると構造体に関数ポインタを配置して OOP 的なアプローチになったりしていた。デバッグとかメンテナンス性は悪くなる。その後 C++ を使うのが一般的になり、メンテナンス性はまだしも C++ に対応したデバッガでのデバッグは容易になった。
メンテナンス性を下げる最大要因は同じ名前のメソッドがひたすらあちこちにあること。ポリモーフィズムの暗黒面がメンテナンス性を下げる。標準的すぎるメソッド名に重要なロジックを隠しちゃダメってことだ。名が体を現してるうちはまだいいが、そんなものはすぐ破綻して、なんでこんな名前のメソッドでこんなことをってなる。

名前があればまだ良い方で、C++ にはオペレータという必殺技がある。もちろん殺されるのはメンテナ。記号に独自の意味を付加するのは勘弁して下さい、マジ迷惑。Scala は謎記号の宝庫で、そこが微妙に好きになれない理由の一つ。Dispatch とかできたら使いたくない。 無駄に継承が深いのも考えもの。ロジックとして1ファイルに収まってて欲しいようなことまであちこち見ないといけない。書いた奴はメンテナンスのことなんて考えてない。

さて、ある程度の規模のプログラムがさらに発展するとデータのやり取りに柔軟性を持たせるため、特定処理向けインタプリタになってしまうことがある。もちろんデバッグとかメンテナンス性は死ぬほど悪くなる。普通、独自インタプリタの独自スクリプトにはドキュメントは無く、加えて文法エラーすら教えて貰えない。 独自インタプリタって、作るのはきっと楽しいんだろうなぁ。でも俺にメンテナンスさせないで下さい。

JavaScript さんこんにちは

某掲示板を読んでいたら『未だに HTML の飾り付け程度に思ってる人は別だけど、経験上、その手の人は他の知識も時代遅れだったりするからめんどくさい』なんて書き込みがあり、JavaScript なんざ HTML の飾り付け程度、と思っているのでもうちょっと調べてみようかと思った次第。

JavaScript のブラウザ以外での環境を一変させたのが Node.js。Node.js ってjQuery のような何かを実現する JavaScript のライブラリかと思っていたら、JavaScript 実行環境も含んでいた。.js って付けるなよ紛らわしい。C# における.NET Framework。それなら納得。Node.js をインストールする。

Node.js に標準に備わってる ZLIB の説明を見て（あぁ、文書化されてるって素晴らしい）主に gzip や zlib の話なので所謂 ZIP ファイルは標準では扱えないということのようだ。これでモチベーションは半分以下になる。npm で各種ライブラリをインストールするそうな。調べるとなんとも乱立状態のカオス。OCaml のOPAM やHaskell の Cabal や Python の PyPI でわかるように、碌な文書化もされてない寄せ集めで何をしろと、「こんなもの」をどうしろと。モチベーション駄々下がり。もう俺「他の知識も時代遅れだったりするからめんどくさい」でいい。そもそも Node.js はWeb サーバを構築するためのツールなんだし。いや、それでも ZIP ファイルは扱うだろ。仕事でメンテしてる Scala + Lift の Web サーバも ZIP ファイルは扱ってるぞ（たまたま Java のライブラリに標準で入ってるだけとも言えるが）。

Electron も Node.js を使ってるんで、標準で用意されてない処理でカオスなのは必至。ちゃんとした ZIP ライブラリを探すところからってのは泣きそう。とはいえ、OCaml の状況に比べれば利用者が多いというだけでも Node.js の方が断然有利。多分。

ともかく、JavaScript をいわゆる LL 的にサクっと書いてサクっと動かすには Node.js が適切なのだと判断。やっぱり名前がおかしいよなぁ。.js は余計だろ。で、しかも Windows と Linux で、多分 Mac OS X でも同じ JavaScript で同じように動くプログラムを書けそうだ。ココ重要です。はっきり言ってこれ（マルチプラットフォーム）がなけりゃ手を出してない。

Node.js のライブラリ文書をざっと眺めると、それなりに、特にネットワーク関連が充実してるようだ。でも多分 Python の方が充実してる。前述したように ZIP ファイルは標準では扱えない。何故か XML も標準では扱えない。なんだってぇええ。モチベーションが負の数になっちゃうよ。なんでこんなのが流行ってるんだろう。
Unix システムコール程度のライブラリ環境でも書ける程度のサンプルを書いてみる。OCaml では色々と標準的にあってもよかろうにと思う程度に足りない部分があったが、Node.js + JavaScript ではそういう部分はなかった。Array と Object と String が機能豊富だからだろう。Scala や Python と同程度の記述で書ける。
どんな素晴らしい言語でもへっぽこな環境やライブラリしかなかったら見向きもされない（OCamlがまさにそう）。どんなしょぼい言語でも適切な環境やライブラリが他に無いなら使われる（かつてのUnix/DOS/WindowsとC）。JavaScript は言語仕様は面白いんだが、開発実行環境はまだ微妙ですな。

Tweet