引きこもりでもニートでもないのは部屋にこもって仕事をしてるからなんです

2015年11月6日金曜日

小ネタ：アプリ制作とデザイン

私自身は、自分のことをエンジニアだと思っていて、デザイナーでは決してないと思っています。あくまでもプログラムを作る人で、プログラムのデザインとかあまり関係ない、と昔は思っていました。

そうは言っても作ったプログラムを使ってもらうためには、例えば使いやすさとか、使いたいと思わせるような動きとか、それなりに(実際にはかなり)重要だったりするわけで、どうしてもプログラムの「デザイン」、専門的な言葉を使うならUI/UXとか、そういったことを意識しないと本当はいけないわけです。

では、普通にプログラムをエンジニアが作るとどうなるか？基本的にプログラムの機能を作る人が作るものなので、デザインにはそれほどこだわりがありません。もちろん、ボタンの位置とか(整列していないとかどのボタンが右で左で、的なこと)は意識しますが、ストレートに言えばどんなアプリを作ってもまるで業務用のソフトみたいな(今でいうならふた昔前くらいのデザイン、でしょうか)感じになってしまいます。

私自身、そういったプログラムを作ってきた(そしてそれでよかった時代でありクライアントでした)ので、ある時、上司から「君の作るもののデザイン、ダサすぎるね」と言われた時はショックであり混乱もしました。だって、動くんですよ。必要な機能も盛り込んでいますよ。それなのに、アプリの機能と関係ない部分ですから。

しかし、現在、というより時代の流れでしょうか、アプリはただ動くだけではなく、デザイン面での考慮が必須になりました。ですが、開発をしようとしても、開発環境を普通に揃えた状態では、どうしても昔ながらのダサい画面しか開発できない、という状況に変わりがなかったりします。

もちろん、デザインが素晴らしいアプリの開発ができないわけではなく、それなりの環境を揃えることで実現できるわけです。世の中に優れたデザインのアプリが存在するということがその証拠ですが、ではそれは何か。

私は最近までスマホアプリを開発していたので、Javaを使うことが多いのですが、Javaのみで作ろうとすると、どうしても限界が出てきます。そこでスマホでは(そして調べてみるとPCアプリでも)XMLを使ってデザインをする、という方法があります。これはデザイン面での開発にとっては便利であり、簡単でもあるので、私はやりやすいと思います。

もちろん、開発環境の中で、パーツのデザインを含めて提供するというスタイルもありますが、よく言えばデザインが統一される、悪く言えばダサくなりがちだったりするわけですし、逆に、XMLを使うスタイルでも、ごちゃごちゃしたデザインになりがちなので、それぞれに長短あるのですが、いずれにせよ、機能以外の面でダサいアプリを作ることは、あえてそれを狙うことをしない限り(ネタアプリみたいな感じですかね)、できないししなくていいし、そんな時代になったんだなぁ、と思います。

実は、以前言われた「デザインがダサい」という一言は、今でも心の中に引っかかっています。むしろ、もうそんなことを言われたくない、という気持ちに変化していて、どんなアプリを作るにせよ、多少なりともデザインを気にするようにはしています。どんな簡単なアプリでも、誰かが使うことを考えて作ります。

ざっくりですが、私が考えるデザインの順番は、
・まず見た目。見た目が悪ければ使う気は起こらないはず。
・次に使い勝手。ボタンやらコントロールやらの場所を考える。
というもの。どれだけ使い勝手の良いものでも、見た目が悪いとあまり愛着が湧かないというのは「モノ」を選ぶ際のポイントになってくると思います。確かに世の中には見た目より使い勝手重視と思われるものもたくさんあるにはありますが、その全てが万人に受け入れられているとは思えませんし(しかも受け入れられるためには条件がいくつか必要)、見た目が良ければとりあえず受け入れてくれるわけで、見た目を最初に考えるのが私のスタイルです。

2015年11月3日火曜日

インターネットラジオの録音に関する考察（その４：番組表の詳細設計(仮)）

本当ならラジオの番組表は後で作るつもりでいたので、現段階で書くことはなかったはずなのですが、ちょっとデザインを考えているうちにまとまった考えが浮かんだので、仮の設計をしておこうかな、と。

まずこのブログを普通に読んでいる方はおそらく日本人だと思われます。日本語で書いてるし当たり前ですかね。では、そんなあなたに質問。番組表と聞くとどんなイメージをお持ちですか？

おそらく、新聞のラテ欄と同じレイアウトのイメージなのではないかと。画面上にテレビ局が並び、下に行くに従って未来の番組になっていくものです。当たり前といえば当たり前なレイアウトですよね。新聞に限らず、テレビでもラジオ(というかradiko、らじるらじる)でも同様、局が上に来てます。

ということは、このデザイン以外ありえない、ということになりそうですが、実はそうでもないんです。海外のテレビ、しかも多チャンネルな国(アメリカとか中国とか)だと、テレビの番組表は局が横に、時間は左から右へ進んでいく、というのが多いみたいです。CSのチューナーも昔はそんなスタイルだったような記憶があります。

これはなぜか。私自身、それほど海外の事情に詳しいわけではないのでわかりませんが、おそらくは「慣れ」から来ているのではないか、と推測します。

「番組表」の画像検索をしてみると顕著ですが、日本語で「番組表」と検索をすると、基本的に(日本人には)見慣れたスタイルのアレが出てきます。では、英語で「TV Listings」「TV Schedule」と検索するとどうなるか。まぁ多彩なデザインが出てきます。

先ほど書いた、表が日本と逆(局名が左側にある)のもあれば同じのもあったり、古い新聞だと何時からどこのチャンネルで何をやるかが列記されているだけだったりとか、おそらく共通フォーマット的なものが存在しないんでしょう。

だから、日本の場合はおそらく新聞の表現方法がデファクトスタンダードになり(テレビ・ラジオ雑誌もこの表現を踏襲)、デジタル化された現在でもこの表現方法が一般化しているということは言えるでしょう。もちろん、日本人は文字を上から下へと読む習慣があるので、それに倣って造られた表現方法なのだとも考えられますし、そもそも新聞は縦長の紙面なので、それにマッチする表現方法がこれだった、とも考えられます。

逆に、海外ではそう言った新聞などでの番組表の表現方法が確立されておらず、デジタル化された段階で見やすい番組表を模索した結果、横長の画面であるテレビにマッチしたスタイルである、日本とは逆のスタイルになった、または、文字の読む習慣から考えれば右に目線を動かすタイプの方が読みやすかった、という理由があるのかもしれません。

では、私(純粋な日本人です)が作るとしたらどんなデザインになるのか。おそらくですが、どちらも採用しそうです。ユーザーに任せる部分というか。

これには理由があります。
先にちらっと書きましたが、昔のCSチューナーはいわゆる日本式ではない番組表を採用していました。日本製ですが(東芝だったかな？)。理由はわかりませんが、おそらくは、チャンネル数があまりにも莫大なため(そしてこれは現在の海外の事情ともおそらく合致すると思われますが)、「日本式」の番組表では画面に表示されるコンテンツの数があまりにも少なすぎるため、逆にしたのではないか、と思われます。

さて、ネットラジオに話を戻しますが、今回選びたい局は実はかなりの量になります。私自身は現在東京在住なので、それだけでも結構な数の局になる(radikoだけで13局、NHK3局＋AFN Tokyoだけとしても)のですが、そこにコミュニティFMを幾つか加えればなかなかのコンテンツ量です。それを「日本式」で見るのが果たして見やすいのかどうか(もちろん、番組表を取得できれば、という条件はあるにせよ、radiko参加局とNHKは確実に取得できるはずなのだから)。

だとすれば、選局可能なチャンネルが少なければ「日本式」でも構わないし、多くて見にくい、となればそれ以外の方法も選択肢があっていい、という考え方はあっていいと思います。

今回は開発の中でもデザインに特化した内容でしたが(にも関わらず絵を一切掲載しないという暴挙に出ましたが)、アプリを作るときにはどうしてもこういうことも考えないといけないよね、と思い、書いてみました。今後も割とこういうデザインネタは多く書くことになるとは思います。

インターネットラジオの録音に関する考察（その３：聴取・録音機能の詳細設計）

前回のポストで、ストリーミング配信ラジオの聴取・録音方法についてまとめました。で、それをもとに詳細設計をする、ということなんですが、これも前回書いた通り、バックグラウンドで必要なソフトを立ち上げるだけでいいわけです。

もうちょっと細かく言うと、
・選局する(聴取・録音するラジオ局を選ぶ)
・聴取の場合は聴取のためのソフトを立ち上げる
　＃rtmpdumpだったりffplayだったり
・録音する場合は録音のためのソフトを立ち上げる
　＃rtmpdump/ffmpeg

聴取するだけなら実は本当にこれでよく、局を変える時もその都度立ち上げたり終了させたり、というだけでいいんですが、問題は録音です。今聴いている局を今から録音する、というシチュエーションは現状では考えにくく(昔のFMではよくやってましたね。好きな曲が流れるまでずっと待っていて、かかった途端に録音ボタンを押したり、あらかじめ録音ボタンと一時停止ボタンを押しておき、一時停止ボタンを解除する、というアレ。懐かしいなぁ・・・)、予約録音をするのが一般的なのではないか、と思います。

すると、予約のための機構を作らなければならない、ということになります。
予約録音自体は、rtmpdumpでもffmpegでも、開始時刻を指定することができないため、アプリ内で予定時刻になったら(実際にはアプリ起動から録音開始まで若干のタイムラグがあるので開始時刻の数秒前に)起動し、そこから指定された時間録音する、というやり方で実装できそうですが、問題はその開始時刻の指定とタイムラグの調整になります(調整レベルの話は内部でごにょごにょになりそうなのでメインは開始時刻指定ですね)。

そこで、番組表の話が持ち上がってきます。
最近のテレビ(地デジ化された後のテレビ、と言い換えてもいいですが)にあるEPG、いわゆる番組表機能は非常に便利です。今何をやっているかもわかりますし、録画したい番組を選んであれこれできたり。個人的にはあれを作りたいですね。やり方がイマイチ見えてないですが。

番組表ができれば、録音のための開始時間はそこから取得できるわけですし、予約などのやり方も簡単にできるようになるはずです。ただ、これについてはおそらくすぐにリリースはできないんじゃないかな、と。だって、やり方が見えないもの。

もう一つ、予約録音に必要な事があります。PCのスリープ解除にまつわる機能です。普段から電源を入れっぱなし、画面も消えない、という状況はまぁ考えにくいわけで、スリープ解除(及び必要があれば録音作業終了後のスリープ設定)をする必要はありますよね。

とりあえず、今できる事は最低限聴取と録音の機能ですね。あとは開発言語をどうするか、というこちらの都合がありますが、まぁそれはどうでもいいことなので。

開発言語の話で一つ思い出したことがあります。最初の設計段階でスマホアプリでは再生機能のみ、としたのですが、この理由は至って簡単。容量の問題が起こるからです。

録音した音源をスマホからその都度PC側に移動させる、という作業を誰もが行うというのであれば、スマホで録音するのは結構都合のいいことのように思えます。が、普段の生活で意識的にPCへデータを移動させることは普通のユーザーはやらないでしょうし、そもそもPCを持っていないスマホユーザーもいるわけで、ずっとスマホにデータを入れっぱなしにしているということは、間違いなくストレージ容量の不足を招くわけです。

もちろん、クラウドへの移行や外部デバイス(SDカードだったりそういうの)への移動も視野に入れるとしても、それでも容量は無限にはなりえない。だとしたら、スマホでの録音は行わないほうが良い、と考えます。スマホからPC側に録画予約ができる機能が実装できるならいいですが、それって相当難しくない？

インターネットラジオの録音に関する考察（その２：ストリーミング配信方式のまとめ）

前回のポストでは、とりあえずの設計をやってみました。基本的に一人でやることなので(以前も書いた通り、似非アジャイル開発です)、小さい機能を作って最終的に組み立てる、というやり方になる以上、ざっくりと頭の中に完成図があればいいわけです。

で、機能面でのメインとなるのは、

普段自分が聴取するであろうラジオ局を聴取する/録音する

というものです。まぁ当たり前の機能ですね。では、その方法について軽くまとめましょう(というか、自分も久しぶりにこの機能の実装をすることになるので、以前の調査結果をまとめておかないとわけがわからなくなるんです)。

インターネット上で配信されている(かつ私が普段聴取するであろう)ラジオはおおよそ、以下の形式で配信されています。
・Radiko(民放ラジオ各社)・・・RTMP
・らじるらじる・・・RTMP/WMA(WMAは2015年8月末で配信終了)
・AFN・・・要調査(HLS？)
・JCBA・・・RTMP
・CSRA・・・WMA？

ざっくりいうと、配信形式は３種類に分かれます。で、それぞれの方式に対応した聴取・録音の仕組みを作らなければいけない・・・のですが、これらを一から作ることは私にはとてもできません。で、どうするかというと、それぞれの方式に対応した聴取・録音ソフトをあらかじめ取得しておく必要があるわけです。

ググって調べてみると、RTMPに対応するソフトが「rtmpdump」、それ以外であれば「ffmpeg」が必要になり(聴取・録音ソフトでフリーのものはこれを使っていることを公言しているものもあるし、おそらく有償のものでも同様なんでしょうね)、アプリ的にはこれらをバックグラウンドで実行させることで聴取・録音を可能にしている、と考えられます。

ちなみに、この聴取・録音をするためのコマンドラインはとても簡単で、例えば、今ちょうど私が聴いているAFN Tokyoの聴取ならば、

ffplay "http://4613.live.streamtheworld.com/AFNP_TKOAAC"

また、それを録音するならば(例として10分録音)、

ffmpeg -i "http://4613.live.streamtheworld.com/AFNP_TKOAAC" -t 600  -vn -c:a copy "~/rec.m4a"

と一行コマンドを実行するだけで済むわけです(ffmpegの再生版がffplay)。本当はもうちょっと細かい技が必要になるのですが、それはおいおい紹介するとして(というか私も調べながらの制作を行うので・・・)。

ということで、聴取・録音機能のやり方をまとめることで詳細設計の大枠が出来上がってきました。次回はこの機能について詳細設計をもう少しまとめてみたいと思います。

インターネットラジオの録音に関する考察（その１：開発再開前夜）

今年初めの頃、Mac用のインターネットラジオ録音アプリを作ろうとしていましたが、他にやりたいこともあり、単体の曲だけ選択し録音機能を実装する、というところでいったん開発が停止していました。

ふだんはMac使いではあるものの、開発の都合からWindowsマシンも持っていたりしますし、仮想環境にもWindowsの古いバージョンが入っていたりするので、実際のところ録音にはWindowsマシンで他の人が作っているアプリを使うことで(あえて何とは言いませんが)何とかなっていました。

ただ、今年の9月からだったか、NHKのストリーミング形式が変わったことで、アプリの録音機能が正常に動作しなくなり、NHKの録音(午後4時からやってる気象通報を録ってました)ができなくなってしまいました。まぁアプリのバージョンアップをすれば済む話なのですが、自分で作ることができるのに他人のアプリを使い続けるのもなぁ、なんて思いながら、しかもNHKの録音した音源に関して言えば、今のところあってもなくてもいいものだったので、とりあえず放置プレイをしてあるわけです。

そうは言っても、「録音できないんだったら自分で作ればいいじゃない」というアントワネット型思考(笑)が頭をよぎる以上、作らなければならないのかなぁ、と思っています。

ということで、ちょっと開発に時間を費やしてみたいと思います。

・・・とここまでならいつもの調子なのですが、その前に、作るにあたっての設計や実際のコードのサンプルなどもブログにアップしてみたいと考えていて、今後しばらくは設計やコードをひたすらブログにあげてみようと思います。

で、とりあえずの設計(いわゆる基本設計、全体像、Perspective)をこんな感じにしてみようと思います。
・一応Mac用アプリとして開発を開始。
・スマホ(iPhone/Android)用アプリも作る予定(ただし録音機能は付けない予定)
・余力があればWindows用も作ってみる
・聴取可能な曲は普段AM/FMで聞いているものを網羅(※)
・番組表は新聞ラテ欄的なデザインで
・プレーヤー自体のデザインもそれなりのものにする

まぁ、他にもいろいろと出てくるのでしょうが、最初のバージョンはシンプルな状態で出したいですね。誰かが使ってくれるのならその段階で要望も出てくるのでしょうし。

それから、もう一つこだわりたいのはやはりデザインでしょうか。直感的なデザインは外せません。機能重視はもちろんなのですが、それによってゴチャゴチャしたデザインになるのは個人的には許せないです。シンプルなのがいいです。シンプルで直感的。

ラジオのデザインと言えば、あくまでも個人的には、ですが、昔のラジカセのデザインは嫌いではありません。同世代(40歳代)のオジサンには共感してもらえると思っていますが・・・。が、あれはシンプルとは言い難いですね。どっちかというとゴチャゴチャ。ボタンがいっぱい付いているのがカッコよかったんですけどね、昔は。

ということで、しばらくラジオネタで引っ張ります。次回はコードを幾つか載せてみますのでお楽しみに。

2015年9月30日水曜日

小ネタ：ブログにコードを貼り付ける

ブログを書いていて、とてもやりたいことの一つに、ブログで作成したコードの一部とかを公開することでした。自分でプログラム作成をするときに参考にするサイトでも、コードのところだけ別の枠に囲まれていて、色やら行数やらついていたりして、カッコイイじゃん！俺もやりてーなー！とずっと思ってはいたのですが、なかなかそこまでに至りませんでした。

で、ちょっと手が空いたときに調べてやってみたのですが、最初はよく分からなくてうまくできなかったのですが、きちんと時間をとって調べてみると、意外と簡単だったりしました。ということで、このブログにも仕込んで見ました。

ちなみに、ブログでプログラムコードのところが↓こんな風になるのを、シンタックスハイライトというらしいです。

<!DOCTYPE HTML>
<html>
 <head>
  <title>Online or offline?</title>
  <script>
   function update(online) {
     document.getElementById('status').textContent =
       online ? 'Online' : 'Offline';
   }
  </script>
 </head>
 <body ononline="update(true)"
       onoffline="update(false)"
       onload="update(navigator.onLine)">
  <p>You are: <span id="status">(Unknown)</span></p>
 </body>
</html>

(w3cのサイトからコピペしてきましたごめんなさい)

これはブログに限った話ではなく、コードを色付けしたりして読みやすくする、というのがメインの目的です。まぁ私のブログ文字多めなんで、これにコードを入れたらもっと文字多くなっちゃって大変ですがねぇ。それはともかく。使い方は他のサイトを参考にしていただくとして(現時点で一番参考になったのはこのサイト。日本語で説明されていることもありますが、元のサイトのリンクも入れてくれていたのは助かりました。感謝いたします)、導入の要点をまとめておきます。

下準備としてスクリプトのリンクを追加しておくこと。参考リンクでは<head>セクションの一番最後(もちろん</head>タグの直前ですよ)に追加、とありますが、これは昔ながらのお約束ですが、近頃(少なくとも2015年の時点)では<body>セクションの一番最後(</body>の直前)に仕込むのが流行りらしいです(速度向上とか)。このサイトでは流行りに負けて<body>セクションの最後に記載してみました。
実際に使う場合、コードを<pre>タグで囲むだけでよいみたいです(参考にしたサイトは情報が古めだったので、実際に元サイトに行ってみるとそう書いてある)。
使い方例：
```
<pre class='brush: ○○; html-script: true;'>
コードの内容
</pre>
```
上記例の「class=brush:○○」のところに使っているコードの名前をここを参考にして記入します。もしhtmlの中のスクリプトだということであればその次の「html-script」項目をTrueにすればよいはずです。
ただし、<pre>タグに囲まれたコードの中で、一部エスケープ文字を使用する必要があります。各言語で異なると思いますが、上記の例で言えば、HTML(XML)の場合は(少なくとも)行頭の「<」はエスケープ文字(「<」)に直しておく必要があります。そうしないと表示が崩れます。＃本当は「>(>)」もやらなきゃいけないみたいですが、＃Bloggerでは行頭を直したら行末は勝手に修正が入ってしまいましたとさ。

ちなみに、これは私が使っているBloggerの場合ですが、おそらく他のブログサイトでも同様でしょう。ちなみに、スクリプトリンクの追加は(Bloggerの場合)テンプレートのHTMLファイルをいじる必要があります。まぁコードを載せようなんて人は「その筋」の人たちでしょうから、元のHTMLファイルを壊す、ということもないと思いますが(笑)。

まだ使い方があまりわかっていませんが(つか元サイトがあまりにも説明少なすぎる気が)色々と調べてみて、わかってきたらまとめて解説してみようかな、と思っています。

2015年9月29日火曜日

古いネットブックへのWindows 10導入顛末

仕事、という内容でもないですが、皆さんの参考になるかと思い、古いネットブックにWindows 10を導入した顛末をお知らせしたいと思います。

結論から言えば、成功しました。そして、かなり使えるらしい(私は使っておらず、使用者である妻の弁)とのことですので、押入れに突っ込んであるネットブックや中古で持ち運びに便利なマシンをお探しの諸兄には福音かもしれません。

ただ、そこに至るまでの道のりは実はすごく長かったです。試行錯誤の結果成功したと言っても過言ではないです。なので、その長かった道のりには触れず、最短でインストール成功する方法をお知らせします。

まず、用意するもの。

ネットブック本体(今回はAsusのEEE PC 1000Hをストック状態で用意)
メモリを積めるだけ(メーカー公称1GBでしたが2GB積めるらしい)
SSD(中古とかの安いので十分)
Windowsのメディア(今回はWindows7とWindows10の二つを用意)

基本的に、Windows7はWindows10にするための踏み台みたいな状態です(もとのネットブックはWindowsXPだったので、そもそもはWindows7をインストールするつもりで買ってあった)。

そして、もしネットブックが現役ならば、データのバックアップをしておいてください。基本、クリーンインストールしますので。

手順を簡単に書くと、

Windows7インストールの前段階として、BIOSを最新版にアップデートする
HDDをSSDに交換し、メモリも最大限積めるだけ積む
Windows7をクリーンインストールする
Windows7用のメーカー提供ドライバの最新版をインストールする
Windows Updateを行って最新の状態にしておく(※オプション)
Windows10にアップデート(引き継ぎなしで行う)
必要に応じてWindows10用のドライバをインストール

直接Windows10をクリーンインストールでもよかったのですが、今回は後で述べる事情があり、Windows 7を一度インストールしたうえでの作業になっています。

注意点を順を追って説明していきます。

BIOSのアップデート
基本的に、Windows7に対応しているマシンはWindows10にも対応していると考えてよいです。Windows7より上位のOS対応のBIOSアップデートがあればそれをインストールすればよいですが、私の場合はWindows7版が最新でした。
SSD・メモリ換装
メモリは、あればあるほどよい、とは言いますが、まずWindows7にする時点で、どんなにメモリを積んでも3GBまでしか認識されないという制限があります(ネットブックでIntel Atomを積んでいるマシンは32bit版しかインストールできないらしいので)。したがって、最大でも4GB(OS側が3GBとして認識)を選ぶ必要があると思います。また、Windows10では32bitでも4GBを認識している、という情報もあるのですが、そもそも32bitOSが4GBのメモリを認識するのか(いわゆる「3GBの壁」の解消がされたのかどうか)わかりません。
SSDについては、必須ではないです。SSD自体、読み込み速度は相当早く、例えばアプリ起動など、いわゆるサクサク「動く」という点では非常に有効ですが、書き込み速度(データをダウンロードしたりファイルを保存したりという作業に影響)が遅いということもあり、私は躊躇したのですが、HDDを積んでいるネットブックのHDDスペックは基本的に低速(回転数が遅い＝読み書き速度が遅い)であり、SSDへの換装により、書き込み速度も向上しました(どんだけ遅いHDDだったんだ、ということにもなりますが・・・)。
Windows 7のクリーンインストール
HDDを換装したのであればバックアップはあとでなんとかなりますが、そうでなければインストール作業前にバックアップは必須です。クリーンインストールで注意する点は他にありませんのでこんなところで。
Windows 7用ドライバインストール
これが意外と大事です。少なくともメーカーで提供しているドライバは全部最新のものを入れておいてください。私はグラフィックスドライバを入れていなかったため、このあとのWindows10インストールで失敗しています。
Windows Update適用(オプション)
実は、私の環境ではこれをしなくてもWindows 10のインストールはできました。というか、Windows Updateがどうしても動かなかったんです。エラー回避方法はいくつかあるので試してみたのですが、どれもうまくいかず、「諦めた」というのが正解かもしれません。これができていれば、もしかするとWindows 10にはしなかったかもしれませんので、よかったのか悪かったのか・・・(これがWindows7経由でWindows10にした理由です)。
Windows 10インストール
クリーンインストールではなく、アップデート(OS起動中にインストール作業を行う)で行いました。この時、前のOSの情報を引き継がないオプションでインストールしました。こうしないとインストールができませんでした。また、更新プログラムのダウンロード・インストールもこの時点では行わないように選択しました。やはりこちらもうまくインストールできなかったので。
Windows10用ドライバのインストール
基本的にWindows7の時もそうですが、実はOSで認識したハードウェアのドライバは正常に動いており、わざわざ変える必要もないかもしれません。どちらかというとハードウェアメーカー側で最適化されたドライバと考えています。私はこの作業を一部しか行っていません(タッチパッドと電源管理のドライバだけはいれておきたかったので)。

このためにかけたコスト概算ですが、

ネットブック本体：¥15,000
OSパッケージ：¥12,000(Windows7 Home 32bit)→Windows 10のDSP版はもう少し高かったです
メモリ(2GB/1枚)：¥3,000(中古)
SSD(128GB)：¥8,000(中古)

しめて¥38,000 ナリ。本体をすでに持っているのであれば、最大23,000円で、すでに本体側の改造済ということならOS料金だけで現役マシンになれる、というお話でした。

ちなみに、個人的には古いネットブックではWindows 10の魅力が半減するかなぁ、というのがちょっと使わせてもらった感触です。デスクトップOSとしては今までのWindows(7まで)を踏襲したものなので、可もなく不可もなし、といったところです。また、今回のインストール作業ではクリーンインストールをメインでやっていますので、余計なサービスやアプリが入っておらず、かなり軽快に動作します。

しかし、当たり前の話ですがタブレットモードがなく、さらに画面タッチもできないのは、タブレットモードに慣れている状態の私には退屈というか面倒というか、ちょっと違和感があります。

登録: 投稿 (Atom)