  |
はてなキーワード: ユーザーインターフェースとは
はてながまたしても改悪をして、はてブの黄色スターを表示させなくなった。一部カテゴリだけだが。
https://bookmark.hatenastaff.com/entry/2020/03/31/180820
そのせいで、困ったことになった。有力な情報を得ることが難しくなったのだ。
現状では、（はてブで）有力な情報を得るには、「人気のコメント」を見るしかない。しかし、ここで表示されるのは、初期に人気になったコメントだけだ。最近になって上がったコメントは、まだ星が三つぐらいしか付いていないので、表示されない。また、表示されるのはトップの 10件ぐらいであって、それに次ぐ重要性のコメントは表示されない。
こうなると、あとは全部のコメントを一つ一つシラミつぶしに見ていくしかない。しかし、そんなことをしたら、すごく時間がかかるので、いちいちやることはできない。結果的には、重要なコメントを見るのを諦めるしかない。
※ はてブを見ている滞留時間も減少することになるので、はてな（株）という会社にとっても損になる。
以前では、そうではなかった。星が三つぐらい付いている最新のコメントだけを拾い上げて読むことができた。また、星が 10個以上も付いているコメントだけを拾い上げて読むことで、11位～20位ぐらいの有力コメントを見ることもできた。とても便利だった。
※ はてブを見ている滞留時間も多くなっていたので、はてな（株）という会社にとっても得になっていた。
現状の「黄色スターの表示なし」というのは、はてブというシステムそのもの自殺行為であるにすぎない。「いいね」をなくした、フェイスブックやツイッターみたいなものだ。SNS としての魅力を大きく損なっている。
はてなは、これまでたびたびユーザーインターフェースの改悪をやって来たが、今回の改悪は最悪のものであって、ほとんど「はてブとしての独自性の喪失」を意味する、自殺行為だとしか思えない。アポトーシスか。頭がコロナに感染したのか。
現在、コロナに関する情報を、はてブ経由で仕入れようとしているのだが、大幅に不便になったせいで、情報取得に支障をきたしている。まったく、困ったことだ。はてブは、コロナ拡大の一助として、ユーザーインターフェースの改悪をやってしまったようだ。
※ 最近になって、私の環境では、黄色いスターを付けることもできなくなってしまった。バグだね。
【 追記 】
別件で、次の項目もある。 http://bit.ly/2ugJWDm
【 後日記 】
元に戻りました。４月14日。
ユーザーのキーボード入力を収集して広告に活かすというオメガ株式会社のプレゼン資料らしきものが少し話題になっている。
オメガ株式会社自身の着せ替え機能付きキーボードアプリANYTYPEのAppStoreページ。
実際にインストールして軽く使ってみた。
・着せ替えは普通に使えた
・レビュー数274件って感じでユーザー数は既にそれなりにいるっぽい
・軽く使ってみた感じだと、フルアクセスを許可して使えるようになる機能には「絵文字キーボード」「顔文字キーボード」「広告サジェスト」「入力と連携した演出」があった
・「ミッキー」と入力すればキーボード上部でディズニーランドHPのリンクが表示された
・「野球」と入力すれば米アニメっぽい野球GIFがキーボード全体にさらっと流れてクスッときた
・ANYTYPEから他のキーボードに変更するのが難しい気がするがこれ普通なのかね
［フルアクセスを許可］の設定をオンにすると、入力内容（パスワード、クレジットカード番号などの個人情報）の収集や、ユーザーインターフェースの操作の記録についてのメッセージが表示されますが、ANYTYPEはこれらを一切行いませんので、安心してご利用ください。
appstore説明文にこういう風に書かれてる。自社のこのアプリでは入力情報の収集はしてないのだろう。サジェスト機能とかのためにキーボードフルアクセスが必要なのだろう。プレゼン資料が本物なら自社のキーボードアプリでは情報収集しないが、提携企業のキーボードアプリでは情報収集するということなのだろう。
当社は、広告表示最適化のために、広告識別ID、利用アプリ、特定の入力情報を本アプリから当社が運用するサーバーに送ることにより取得し、善良な管理者の注意義務をもって管理します。
でも利用規約にはこういう風に書いてある。appstore説明文と矛盾してる気がするけど問題ないのかな。
appstore説明文に書かれてるけど、どこにその機能あんの？
appstore説明文に書かれてるけど、どこにその機能あんの？
オメガ株式会社では、独自に収集した膨大な量のビッグデータを人工知能で解析し、個々のユーザーに合わせて欲しいときに欲しい広告が配信できる世界初の広告配信技術を開発しております。
公式サイトで上記のように謳ってたからてっきりこのアプリで情報収集したビッグデータで広告サジェストに活かしてるのかと思ったけど別にこのアプリでは情報収集してないらしい。appstore説明文で情報収集しないと明記してるのは心強い。利用規約が少し矛盾してる気がするが多分大丈夫なのだろう。
このアプリは問題ないとしても、プレゼン資料にあるような情報収集行為はAppleとの規約違反になりそうだけど大丈夫なんだろうか。
複数人でやったり、社員雇ったりしたけどだいたい得手・不得手というか好き嫌いがわかってくる。
こんな感じ。★（苦手・嫌い）☆（得意・好き）
営業：★★★
打ち合わせ：☆☆☆
他人への依頼：☆
進行管理：☆☆☆
請求：☆
ほとんどしない。初期に異業種交流会とか出たけど、苦痛でしかない上に成果ゼロ。今はほとんど紹介だけで成り立っている。
嫌いではない。直接会うことでスムーズになることもあるし、相手の感じもわかるからできるならやりたい。
ただ、頻繁にあると手を動かす時間が無くなるし、なにより疲れるからあんまり頻繁にやるのは嫌い。
打ち合わせの結果、どうやって課題解決を考えるか。手持ちの技術と人的ネットワークを使って考えるのは楽しい。
経験から割と外すことは無くなったけど、見積り作成はギャンブルみたいなものなので神経が磨り減る。
見積書メールを送る前に何度も躊躇する。何年やっても慣れないストレスはある。
プログラム中心の案件の仕様書作成はそれほどでもないが、ホームページ制作の場合はデザインメイン／ユーザーインターフェースメインになるのでスパッとした解が出しにくくて嫌い。
ちょー楽しい。万能感を得られる。これだけやっていたい。
しかしこれだけやってると多分年収が3分の1以下になることは何となくわかる。顧客が自分に求めているものはこの部分に立脚した企画や進行へのマネジメントだと思っているので。
今もデザインは外注するけど、気苦労のわりにこちらの実入りが少なくてできればやりたくない。
「他人への依頼」と反するかもだが、信頼できるパートナーにお願いするのであれば進行管理は楽。
問題はその信頼できるパートナーが少なくて、いくつも案件が重なった時…クラウドソーシングとか使ってる人をマジで尊敬する。あんな品質が安定しないものを使う気にはなれない。
これまでスケジュールをオーバーしたこととか炎上・泥沼化したことは無い。
そもそもそういう案件やクライアントは打ち合わせ時点でお断りするからだが。
月末の発行がついつい翌月10日発行くらいになってしまうことも…
ひとりなので、発行が遅れて入金が遅れるのは全然気にしない。
なんでこんなに請求書を建てるのが苦手なんだろう…ものすごい億劫。
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
8月21日頃にはてなブックマークのユーザーインターフェースが大幅リニューアルされ、かなり不評でユーザー離れが懸念されていた。 http://bookmark.hatenastaff.com/entry/2017/08/21/210000
その後ユーザーが増えたか減ったかははてなにしか分からないだろうが、一般ユーザーからも観察可能なホットエントリに付くブックマーク数で推測してみたい。
| 2017年8月(31日除く) | 605011 |
| 2017年9月 | 622388 |
2.9%増加した。
| カテゴリ | category | 2017年8月(31日除く) | 2017年9月 | 増減 |
|---|---|---|---|---|
| 世の中 | social | 14624 | 14305 | 98% |
| 政治と経済 | economics | 14190 | 12896 | 91% |
| 暮らし | life | 18972 | 19460 | 103% |
| 学び | knowledge | 12753 | 14225 | 112% |
| テクノロジー | it | 19858 | 21200 | 107% |
| おもしろ | fun | 7536 | 7380 | 98% |
| エンタメ | entertainment | 12020 | 12068 | 100% |
| アニメとゲーム | game | 12496 | 12332 | 99% |
| 合計 | 32830 | 34160 | 104% |
4.1%増加した。
学びカテゴリ、テクノロジーカテゴリでユーザー数の大幅な増加があり、政治と経済カテゴリで大幅な減少が見られた。
若干の増加トレンドが今後も継続するのか、ただのゆらぎなのかは今後も見守っていかないと判断できない。ただリニューアルはユーザー数の減少には繋がらなかったようだ。
はてブは一般的に休日に数が落ち込む。日毎に細かく見ると8月はお盆があった分ブクマ数が伸び悩み、9月は敬老の日、秋分の日の週末、理由は分からないがいつもよりブクマが多かった。これが若干の増加として現れた可能性が高いように思う。
今回はMMO関連。
真面目に答えず、出来る限り嘘と虚構を織り交ぜて答えていきたい。
まあ、関心がないわけではないが。
ひとつ列挙してみよう。
1.実装したユーザーインターフェースは、よほど未完成でない限り大きく変えてはいけない。
2.バランス調整に弱体化を用いてはならない。
3.プレイヤーキャラの性能を、レベルデザインから逸脱させてはならない。
4.仕様の穴をついたプレイ方法や、外部ツールを用いさせてはならない。
5.中国人を参加させてはならない。
10.初級者が中級者に迫ることはあっても、初級者が上級者に迫ることはあってはならない、
言っておくが、元ネタのノックス当人も十戒の正当性を自負しているわけではないからな。
私としてはややガチ勢よりだが、どちらも間違ってはいないと思っている。
勝てば喜ぶし、負ければ泣く。
そして、それらは本気であればあるほど増幅する。
だが「楽しむ」ことが本質ならばこそ、それらも蔑ろにはできない。
本気になればなるほど楽しめるから、プレイや思いに労力をかけられる。
これがガチ勢だと私は考えている。
ではエンジョイ勢はそれらを忌避することで、楽しむことからも遠ざかっているのか。
答えはNOだろう。
楽しむことと拘りが密接に関係こそしていても、イコールではないので絶対条件ではない。
むしろ、楽しさを遠ざける側面があることも間違いではないのだ。
まあ、もちろん健全かどうかっていうのはあるだろうけれど、そういうのは「個」の問題だよな。
一応は答えるが、いつも以上に雑に答えるからな。
まあ、色々あるのだろう。
例えばダウンロードサイトのサーバー管理の維持に費用がかかるからとか、ダウンロード版のほうが安かったらパッケージ買う人がいなくなるだとか。
……ああ、「物理的価値がなくなっているのに、値段が同じことに納得がいかない」という主張であることに今さら気がついたよ。
まあ、企業の利己的な理由である可能性もあるだろうけれど、ここでは別の例を出して肯定的に捉えてみよう。
確かちょっと前、週刊少年ジャンプの電子版が雑誌より高いとかで話題になった。
「高い高い」という声もあったが、はてブだと「電子版のほうが安くあるべきという価値観は普遍ではない」とかいう意見が主だったと記憶している。
ゲームと漫画は違うだろうけれど、物理的価値が必ずしも個人にとってプラスではないというのは、他のものにも適用していいんじゃないだろうか。
少なくとも私はゲームソフトを入れ替える作業や、ソフトを保管するのが手間だと思っているし、むしろパッケージ版こそ安くあるべきだとすら考えている。
……そうだ、君はこう考えてみたらいいんじゃないかな。
「ダウンロード版が高い」のではなくて、「パッケージ版が安い」のだと。
ほら、なんだかお得な気持ちになってきただろう。
たぶん技術じゃなくて、リスクをどこまで許容するかの話なんだよな
※なお、初稿はエレベーターとか結構書いてた模様。全部エスカレーターに直した。指摘thx
勿論解決できることもある。
例えば、全員がみっちり並んで載っても余裕の耐荷重設計とか、点検整備体制とかな。
でもな、エスカレーター上で歩いて登っても大丈夫なようにしろよってのは、無理な話だ。
だってさ、コケたり滑ったり、落ちた時に被害が甚大ですってのが本質なんだもの
しかもよ、動くエスカレーター上で更に登っちゃう人ってのは、基本急いでる人だろ？
国会議事堂前でずっとエスカレーター載ってる人と、歩いてる人に差があるのはわかるが、
普通の駅なら、1分は違わないだろ。
1分を惜しむ人ってのは、急いでる人だ。
で、急いでる人が動くエスカレーターの上で「コケないようにしろ」ってのが、要求になるわけだ。
そりゃ無理だろ。
あと、急いでる人が動くエスカレーターの上で「他人にぶつかって迷惑をかけないようにしろ」とかな。
これは技術で解決する話じゃないのよ。
あくまでもマナーやルールや法律じゃなくて、エンジニアリングの話にするなら、
明日から日本中で一律エスカレーターの稼働を止めるしか無い。これなら単なる階段になる。
登れるようにみえるのが悪い、というのであれば登れないユーザーインターフェースにするというのもひとつの手だろう。
登りたい、それでいて登りたくない相手に迷惑をかけないようにしてほしいというのであれば、
完全に区切る、1人用のエスカレーターが2つ出来るってのも簡易な解決策だろう。
でもな、結局のところ、
「やるなと言われているし、急いでる時コケたり他人にぶつかったりするリスクも理解しているが、
急いでるし、登れるように見えるし、ルールで縛らずにエンジニアリングで解決しないメーカーが怠慢だ」
って言い方をする奴には、きっと付ける薬は無い。
一人用でも走って登りたがるだろうし、登れないのを無理に解決したりするだろう。
痛ましい事故があって、その結果施設側が全面的に使用を禁止、他の施設でも撤去に向かうパターンだ。
「メーカー側は以前から歩かないようにとの啓蒙を進めていたが、今回の将棋倒しの事故での死傷者数を鑑みると何らかの社会的な」
急いでて足を踏み外した人が怪我をするのはある程度自業自得なんだろうが、
ルールに従ってエスカレーターに止まって載っていた人が巻き込まれるのはやり切れないな。
いくら啓蒙してもベンチで寝るなら、そもそも寝られないように区切るってやりかただな。
電車のベンチシートの凹んでる座席とか、途中にある手すりとかも同じ系統だな。
エスカレーターで区切りができて、登れないようにする。
荷物持った人は不便になるだろうが、まあ世の中そういうもんかもしれない。
歩いて登ったら危ないから、片側を開けると荷重が偏って危険だから、詰めて乗ると危険だから
と言われてていうことを聞かずに歩く奴は、残念な人ってことだ。
エスカレーターしかなくても止まって載るのがルールなら止まろう。
うちの親はテレビのチャンネル設定とかビデオの録画でさえまともにできない……
急速炊飯や予約炊飯もできないし
彼らは機械の説明書やユーザーインターフェースに書かれている文字が何語だと思っているのだろう
自由ってなんじゃらホイ。好き放題できること。なんだけど、たとえば五億もっとるのは自由？そりゃ一文無しよりは自由。じゃあ個人資産１００億は？ほんとに5億＜100億なの？
っていう話を今日してて。セフレの数もそうで。セフレ五人もいるとか自慢してくるヤツがいる。でもそれ自由？親友もそう。10人もいるのに親友なの？ホントに親友？ｗぼっちよりは自由かもだけど。1人でも深い親友いれば
そっちのがいいって意見も一理ある。以上総括して、自由って量じゃないんだよ。じゃあ何。多様性、バライエティなんだよ。アタリマエ？
たとえば。深い関係のカノジョがいる。カノジョとはいろんな話ができる。なんでも気兼ねなく話せる。これバライエティ。友達もただ多いだけじゃなく、いろんな友達がいる。
JKのメル友が友達の話よくする。みんな同じ高校とかバイト仲間とかなの。狭い世界で似たような価値観の人どうし集まってるの。楽しいかもしらんけど、もっと色んな人と交流して新たな発見があったほうがもっと楽しい。
若くて時間が余りあるのに勿体ないって思う。人生というゲームのユーザーインターフェースは何だと思う？と聞くと「身体」という答えが返ってくる。俺は「意識」。意識がUIじゃん。
身体というのはバイオハザードみたいな捉え方だね。FPS。「外」から「身体」を操作する、という観点。これに対して、「意識」を介して「心」や「身体」を操作するという観点もアリ。
FPSだと「心」がない。「心」があるのがこの人生。だから「身体」と「心」の両方の上にあるもの、「意識」という観点が重要なんだよね。わかる？もっとも身体と心は見る角度の違いで明確には区別できない。
意識が自由なのが本当の自由。バライエティがダンチだから。さあご飯食べよって時に、いつも同じ食べ方しかできない。これほど悲しいことはないよ。さまざまな楽しみ方のレパートリーがあり、
楽しみ方の着眼点があり、それらを組み合わせて新たな楽しみ方を作り出す創造性もある。そんな人とは雲泥の灯火だよな。子供のおもちゃで迷路組み合わせて迷路作るやつがあって、
パッケージに「組み合わせ○○億通り！」って書いてある。同じようなパーツ組み合わせても同じようなものしかできない。これ、バライエティがないの。もっといろんなパーツを集めないといけないな？
日頃から意識していれば、違いのわかる男になる。いろんな手持ちの札があるから、組み合わせていろいろ作れる。それが楽しいんじゃないか。情操教育ってなによ！色の違いを教えてカラフルにみれるようにする。
レールに乗って生きることに慣れると忘れてしまうんだ。レールから外れるのにもう大変な努力が必要。レール、確かに便利だけど不自由をもたらすから気をつけな。確実に不自由もたらすから。
得意な領域があって自信があるのなら、
その領域の応用範囲から攻めるといいよ。
俺も、プログラミングばっかしてきたけど、デザインなんて事もするようになったし。
ルートとしては、「プログラミング」→「ユーザーインターフェースの最適化」→「インダストリアルデザイン」→「デザイン」って感じ。
資料集めまくったり、自分で絵を書いてみたり散々やったけど、一つ前のスキルの延長上だから気が楽。
あとは、気になった点は徹底的に調べるって事ぐらいかな。
月収半分ぐらい本に持ってかれたりするし。
あとは、ニュース記事を自分の領域で解釈してみるってのもやった。
これで、いろいろと底上げできる。
当レポートは、Vistaをパスして、XPから乗り換えを検討している、
ぶっちゃけRC版の時点で書ける内容です。まあせっかく発売したんで。
=====
まえおき
結論
困ったこと
ソフトの動作状況
当方環境、状況、遍歴：
Windows 7 32bit Ultimate版です。RC版の使用経験はありません。
今回はXP→7への移行です。
ここしばらくのOS遍歴
Vista 32bit(絶望)(1年)→XP 64bit(絶望)(1年)→XP 32bit(2ヶ月)→7 32bit(今)(2日)
PCのスペックは、Pen4D 820、Radeon X1950、メモリ2GBです。
CPUが未対応で、XPモードは動かず。というわけでXPmodeのレポートはありません。
(この時点でこのレポートは8割の意義を失った！)
いい感じです。
すんげえ微妙なスペックに入れましたが、パフォーマンス的には問題ありませんでした。
UI(ユーザーインターフェース)の操作感はVistaから見ても、格段に進歩していると感じました。
特にタスク切り替えは非常に優秀。
見た目KDE＋操作感はUbuntuのNautilus＋MacのFinderって感じでしょうか。
Winオンリーユーザよりも、そっち系ユーザへのアピールが強いかな？という印象。
新規購入の場合ははProfessional以上がいいんじゃないかと思います。
XPmodeの対応なんかもありますが、イザって時の問題解決の手段がHome版だと足りない OR 面倒な事が多いので。
(大事なこと) ソフトやドライバをインストールする前に、必ず手動で復元ポイントを作ったほうがいいです。マジで。
今このPCが動かなくなると困るなーって時はOSのアップグレードをしちゃ駄目です(7に限った事じゃないけど)
かといって、デュアルブートはあんまりホイホイやるもんじゃないです。
簡単にできるよーってレポートも多いですが、よほど慣れているならともかく
後でいろいろと面倒になるのがデュアルブートとMBRいじりってもんですので。
(昔ほど致命傷にはなりにくいですが)
アップグレード版でもXPの環境を7に持ち越すことは、ほとんどできません(Vistaは問題なくいけるとのこと)
ファイルは保持できますが、どのみちクリーンインストールすることになります。
(Cドライブにwindows.oldというフォルダが作成され、旧環境のユーザーフォルダやProgram Files等が格納されます)
しかし、その後の動作が不安定だったので、再度CDbootからクリーンインストール。
どっちでもインストーラの動作は同じはずなのですが、なぜかそれで問題は解決しました。
というわけで、不安な人はフォーマットしたCドライブにインストールした方が良いかもしれません。
ハードディスクにファイルやフォルダを残しておくと、前環境のアクセス権等も一部継承されることがあります。
(NTFSの場合のみ。SSD等の理由でFATでフォーマットしてる方は関係ないです)
そのため、ファイルやフォルダが読めなくなったり、消せなくなることがあります。
自信のない人は 絶対に Cドライブをフォーマットしてからインストールした方がいいです。
改善方法などは↓この辺を参考に
http://builder.japan.zdnet.com/sp/windows-7/story/0,3800092267,20394364,00.htm
それでも駄目な場合は
ファイルプロパティを開いて所有者やアクセス権を確認、変更したりすると直ることもあるのですが、
これってHome版でもできるのでしょうか…。報告くださる方、よろしくお願いします。
(ちなみに裏技としては、FATフォーマットのHDDなりUSBストレージなりを用意して、
1-CD LinuxからPCを起動。読めなくなったファイルを前述の外部ストレージに待避……
とかするとファイル読み出せたりすることもありますが、普通はこんなアホなことはしません。
ただまあ、パーミッションとかが分からない場合は、むしろ簡単かも)
他でこの手のパーミッション関係に引っかかってるって人の話きかないから家だけなのかなあ？
Radeonのアスペクト比固定拡大機能が使えなくなりました。
同様の現象を改善された方もいらっしゃるようですが
当方環境ではどうにもなりませんでした。
Vistaからの移行の場合は気にしなくても問題ないのですが、
XPまでサポートのパーソナルファイアーウォール系のソフトは、ほぼ全滅です。
インストールできてもシステムに悪影響を及ぼす場合もあります。
動作報告があってもインストールの際には十分注意してください。
フリーならComodoあたりをおすすめしておきますが、これがベストってわけではないです。
エクスプローラ干渉系のソフトもいろいろ問題抱えてますので注意。
ぴたすちおとかZLToolsとかGmoteとか諸々のフリーソフトとか…
一部機能を切ったり設定変えたりすれば動くこともありますが、問題が起きたときに
どのソフトのせいなのか分かりにくくなるので、古いソフトとは決別する覚悟も必要です。
Aero切ってまで古い常駐ソフトを使いたい場合はXPに帰ることをお勧めします。
動作を確認したソフト等
Sandboxie 3.40(3.38で支障がでました、3.40でもフルスクリーン化に問題が残ってます)
MagicDisc(Daemon Tools、Alcoholは未対応だそうです)
StExbar(無いと不便なんで助かりました)
FullScreenWin(7でも動きました)
Avast
http://d.hatena.ne.jp/mamoruk/20090327/p1
「いちばん」かどうかはわかりませんが、うちの会社の製品ではpythonを主力に使った自然言語処理を含む製品を販売しているので、実際の感想を。
うちでは、pythonを元データの整備のための運用バッチ処理から、客が最終的に手にする情報の生成、実際に客が使うWEBインターフェースまで、pythonを主力にしています。
別のチームが作った別の製品ではS2Struts(JAVAね。)でWEBを作っている部分もありますが。
mecabが使えて、Unicodeが使えて、正規表現が使えれば、まあ、どの言語を使ってもそんなに大差はないのではないでしょうか。
あとはsennaのような日本語用の全文検索エンジンなども使いますが、そこらへんに近い部分は基本的にC++で書きます。
pythonとは言っても、速度を重視する部分はやはり迷わずC++です。
C++で書いたものはswigを使うか、又はC言語で手書きのbindingを使ってpythonに接続します。
でもこないだswigでつないで製品をリリースしたら、WEBからの並列アクセスにswigがうまく対応できず、リリースした日に急いで手書きbindingを書いた経験があります。swigの使い方はきちんと理解していないので非常に難しい。
nltkとか、wordnetの話はたしかに使えそうかもと思ったことはありますが、nltkはうちでは使っていません。
うちの会社では自然言語処理の研究段階から自社で行っているので、nltkにあるようなできあいのルーチンを実戦投入する事はなく、基本的に地味に自分達でpythonで書いています。
自然言語処理と言っても、核心の処理はやはり泥臭い個別事例への対処が多いです。不要語処理とか。
自然言語処理のアルゴリズムは8割程度の精度を出すのは簡単で、すぐに思いつきで書けるものですが、残り2割の精度をいかに埋めて行くかが、頭のいい人とそうでない人の差が現れる部分だと思います。
どうしてもいいアルゴリズムを思いつかない場合は、泥臭い個別事例処理がうねうねと並んだプログラムになります。学術的なものではなく商売になればいいので、うちはとりあえずそれで十分。（これは自然言語処理に使う機械学習のアルゴリズムたちも同様。というか自然言語処理と機械学習て、区分けがあいまいな部分が多いですよね。）
そういう感じなので、pythonの可読性の高さは非常に有効。
また、変数名や関数名などをexplicitに書く文化も業務で使うのに適していると思います。（他の言語でもexplicitに書けばいいだけですが、それを言語開発者自身が推奨するほど強調はしていないですよね。）
英文の処理で、wordnetの辞書データの一部を研究に使った記憶はある。
しかし、あそこまで精緻な辞書データを使う程高度な処理は今の所必要ない。
うちで自作した不要英単語辞書と、特別扱いする英単語辞書で間に合わせていたと思います。（その辺記憶があいまい。）
djangoは非常に明快で、快適。
画面の機能を追加するのに、例えばS2Strutsのアクションの定義の煩雑さに比較すると、天と地との差ほどにdjangoは簡単。
あと、pythonを使える開発者は日本には少ないとの事ですが、うちでもそれは同様です。
しかし、自分の隣の席の同僚はperlに非常に熟達していて、彼はすぐにpythonの達人に変わりました。
優秀な方にとっては言語なんて何をつかってもあまり変わらないみたい。
プログラムを書けるということはプログラムを設計できるという意味じゃない。ルールを知っているのと囲碁を打てるのが違うように。
ルールを覚えたら、次は定石を覚えないといけない。覚えなくても打てるが、とても傍から見ていられない囲碁になる。同じように、プログラム言語を覚えたら、プログラミングの定石を覚えなければならない。プログラミングの定石は、まず次の二つが大事。
これは武道で言えば型、球技で言えば素振りに相当する。つまり、「こう来たら、こう対応する」ということを考えずにできるようにしないといけない。「並べ替えろ」といわれたらクイックソート、表引きといわれたらハッシュが出てくるように勉強する。で、きちんと抑えれば碁やスポーツと同じでそのアプローチの弱点も分かるから、頓珍漢な場所で使うことも無くなる。
アルゴリズムとデータ構造は、きちんとした教科書一冊で基本をたっぷりと勉強できるから、あまり苦労しなくて済む。
で、次なんだけど分割統治（モジュール化）と情報遮蔽って考え方を徹底的に自分の意識に刷り込む。これはモットーみたいなものなので必ずしもみんなが意識しているわけじゃない。だけど、ある程度大きなプログラムを書くときには決して避けて通れない。だから、この意識は徹底しておくほうがいい。分割統治のコツは合理的な分割。たとえば囲碁プログラムをどうやって組めばいいのか分からなければ、全体を
と言う風に分割して、それぞれについて独立して考える。それでも大きすぎるなら盤面描画を
のようにさらに分割する。合理的な分割であれば、分割するほど分かりやすくなるはず。
分割統治を行うと、それぞれのモジュール間のデータのやり取りが出てくるのでモジュール間インターフェースが必要になってくる。このとき、情報遮蔽の考え方を使う。情報遮蔽は「見せなくてもいいデータは見せない。見せなくてもいいアルゴリズムは見せない」と言うもの。銀行の細かい仕組みを知らなくても、ATMの使い方を知っていればお金を下ろせるように、モジュールの実装方法を知らなくてもインターフェースを知っていれば使えるようにするためのモットーが情報遮蔽。
情報遮蔽をきっちりやって薄くて小さいインターフェースのモジュールを開発するすると、モジュールの交換が簡単になる。たとえば木目生成のもっといいアルゴリズムを思いついたとき、モジュールのインターフェースが薄くて軽いなら、同じインターフェースを持つ別の木目生成モジュールを作って差し替えることができる。インターフェースが込み入っていると、差し替え自体もうまくいかない。
分割統治と情報遮蔽にも今では定石があって、デザインパターンと呼ばれる。これはクラス分割と役割分担の定石集みたいなもの。
ここまで抑えるのに、学生なら半年くらいでいいはず。あとはこれを意識しながら、組みたいプログラムの分野の文献を読み漁り、自分でも書いちゃ壊し、書いちゃ壊しを続ければいい。目を肥やして経験をつめば、規模を克服する力も付いてくる。
