週末ラボ

Excelシートの文字入力がめちゃくちゃ遅いときの対処

2020-08-11T19:15:00.004+09:00

Excelで文字入力を続けていると、次第に入力スピードが遅くなっていってどうにも作業が滞ってしまうという問題にぶち当たりました。

1つのセル内にわらわらと文字を打ち続けていると、次第にどんどん遅くなっていって、一文字一秒くらいのスロースピードになっていきどうにも作業が滞ってしまうのです。作業できなくなるので本当に困っていました。

この問題の回避策について書きます。

あらかじめ言及しておくと、うちのExcelは2010という古いバージョンなので、別のバージョンで同じように回避できるかどうかは判りません。

解決するしないあればコメントいただけますと幸いです。

「Excel 文字入力遅い」くらいで検索すると、2パターンの記事が出てきます。

オートコンプリートが問題なのでこの機能をオフにすれば解決する
1セルに文字数が多すぎることが問題なので、文書が多いものはWordを使うべし

オートコンプリートをオフにしても関係なかったようで、自分の状況に該当するのは後者の文字数が多すぎるほうでした。検索してもこれ以上の情報が見つからなかったので、これに対する自分の回避策を残しておきます。

現象が発生する条件

発生条件を整理しておきます。

1セルに文字が多い。500文字くらいで遅延がでました。

とくに改行がある文章ほど顕著に遅延が発生します。改行数が多いほど遅延はひどくなるようです。

Excelの再起動はもちろん、シートの再作成、Windowsの再起動しても、文字入力が遅くなる問題は解決されませんでした。入力するセルを移動して、まっさらなセルに移すと文字入力の遅延問題は発生しなくなります。つまりシート全体が重いわけではないようです。

回避方法

Excelのセルの文字入力の仕方がいくつかあるようで、工夫することで回避できました。

セルに直接マウスカーソルを持って行き、ダブルクリックして文字入力を行うと遅くなります。

編集するセルをクリックして選択状態にしておき、数式バーをクリックして文字入力を行うと文字入力は遅くはなりませんでした。

ダブルクリックして文字入力を行う

数式バーをクリックして文字入力を行う

入力文字が遅くなる原因は、おそらくセル内での文字の折り返しを文字入力のたびに再計算してしまっていることだと思います。

数式バーをクリックするやりかたのときは、セル内の文字は、一部しか表示されなくなるので、この計算が省略できるということかと。

もう一度言いますが、うちのExcelは2010なのでご留意ください。

ということで、自分はこの発見によりExcelでもスムーズに文字入力が行えています。

検索しても情報がなかったので、この記事を書きました。この情報が誰かの一助となれば幸いです。

では、よきExcelライフを！

買ってよかったもの4つ→生活が豊かになります

2020-06-28T23:55:00.001+09:00

買ったことによって、生活が快適になったものをご紹介します。

自分はあんまりものを買いません。物欲もないほうです。とはいえ、ヘッドホンやスピーカー、あれやこれやと人並みに試してみた過去はあります。
そのほとんどはこれがないと生活が行き届かないというほどではありませんでした。熱狂に駆られて購入しても、数年後には押し入れで眠ることも珍しくないわけです。そういう感じで、ものに過大な期待をしないようになりました。
それでもこれには助けられたなというものがあります。

ということで、いわゆる競合プロダクトをあれこれ精査したうえでのベストバイではありません。紹介するのは、個人的な経験をもとにしたもので、今まで見向きもしなかった自分にとってはいわば盲点となっていたものでした。

買ってよかったものを先に言うと、AirPods、無印良品の羽毛布団、腹巻、JETSTREAMのボールペンの4つです。
布団はやや高価ですが他はそうでもありません。自分にはとても価値がありました。
破損してしまっても、すぐ買いなおすものばかりです。

iPhoneやMacBookなど、これらは革新的だし自分の生活や仕事で欠かせないしかなり生活を豊かにしてくれています。（毎日12時間以上、MacBookの前にいますが）。ただ、あまりに今更なので除外しています。

お分かりのとおり、個人的な状況や主観に偏っているものばかりです。
記事を見る人にとって新しい情報となることを願っています。それが価値となれば幸いです。

AirPods

ワイヤレスイヤホンです。
自分の持っているのは、AirPodsの2世代目です。\17,800です。

普通のイヤホンと違うのは、AirPodsを付けていることを意識しないできいられるというところです。
集中モードに入るのに音楽が欠かせないですが、AirPodsを付けたまま席を立つことができる、トイレに行くことができるというのが一つの手間を完全にゼロにしてしまうすごい革命だと思いました。音楽がすでに終わっても、ずっとそのまま装着していることもよくあります。
配線を気にすることが完全になくなったことで普通のイヤホンに戻れなくなりました。

手軽さというより、気軽さが素晴らしいです。
気分が軽いという状態を実感しました。

以前、AKGのワイヤレスヘッドホン（わりと高価でした）を使っていました。ただ、重くてボリュームがあるのと、熱がこもるのとで、ずっと装着することができませんでした。さらにバッテリー持ちが悪いこともあって、ワイヤレスではあまり使わなくなっていました。
AirPodsはすべて解決しているので、使い続けていても苦になりません。

AirPodsを充電するのにカバーケースに入れるだけでできる手軽さもものすごくよいです。

AirPods with Charging Caseを購入する - Apple（日本）

無印良品の羽毛布団

これは去年末に買ったものです。4つのなかでは新参者です。羽毛布団とプラス毛布がよかったです。4万円くらいです。
軽くて、あったかいです。今までの布団は冬場はとくに重量がありました。

布団やベッドの選択が難しいのは、試してみることができないからでしょう。
店頭で試しに寝てみるくらいでは、実際のところは解りません。

冬場や夏場、季節の変わり目に睡眠が浅い日が何日かあります。深夜に冷え込んだり、布団が合わないことが多いです。こられを対策しようと調整していくなかで、無印良品の羽毛布団に出会いました。実に快適です。

グレー羽毛掛ふとん・二層式です。シングルで消費税込39,900円です。
他に普段、春秋は同じ無印良品の一層式の羽毛布団を使っていたので、こんなもんかなと思っていたのですが、二層式になり、羽毛の量が増えることでふわふわ加減がぐんと増しました。空気を含んでぷるぷるです。厚みがあるのにめちゃくちゃ軽いです。
無印良品の羽毛布団のよいところは、たんに製品がよいというだけではなく、入手しやすいという側面も大きなポイントでしょう。

羽毛布団と毛布だけでは、まだ3月の一番寒いときには、真夜中に目が覚めてしまうくらい寒くなるようです。なので来シーズンは、同じく無印良品のアクリル毛布を買い足す予定です。
気候は地域にもよるので参考になるかどうかは解りませんが、情報が少しでもお役立ていただけますと幸いです。

グレー羽毛掛ふとん・二層式／Ｓ１５０×２１０ｃｍ通販 - 無印良品

腹巻

使用しているのはグンゼの普通の腹巻です。1000円くらいです。
二つに折って臍と下腹部にまいています。

自分は、やせ形であるせいもあって体が冷えやすいようです。
とくに夏場です。夏場の室内は冷房で体温調節がおかしくなる季節でした。
仕事場でもつねに長袖にシャツを完備しています。寒くて凍えているだけではなくてお腹が痛くなり、ずっとトイレにこもる日もあるくらいです。
体調の不調と向き合うのは難しくて、体調が悪くなってからどうしたものかと考えあぐねても何にもならず、体調が良好なときは気を掛けることも意識しないのです。

解決してくれたのが、腹巻です。
夏場に、お腹を温めるという発想はまったくありませんでした。しかし不思議ですが冷蔵の室内でも、冷房のないところでも俄然、体調がよくなりました。お腹が痛くなるということもあまりなくなりました。おそらく汗をかいても、お腹から身体が冷えるということがなくなったからでしょう。

きっかけはワイドなショーという番組です。RAG FAIRの土屋礼央さんが出演されていて、夏場でも腹巻がよいという話をされていたことで試してみようと思ったのです。なんでもRAG FAIRはほぼ全員、腹巻ファンだそうです。

以来、自分は春夏秋冬、24時間欠かさず（入浴時と洗濯時以外）腹巻を付けて生活しています。
すでに2年くらい愛用しています。お腹が痛くなって、1日の半分くらいが無駄になるというのがほとんどなくなりました。

[グンゼ] 腹巻愛情腹巻綿リッチリブ男女兼用 H1000

JETSTREAMのボールペン

なめらかな書き心地にこだわって作られた三菱鉛筆のJETSTREAM（ジェットストリーム）というインキのボールペンです。
文房具を気にしている人にとっては、めちゃくちゃメジャーなものですが、見た目は普通のボールペンです。
本体は約100円です。0.5mmを使っています。インクがなくなったら、芯だけを交換する替え芯が5本で300円です。

書き心地がめちゃくちゃなめらかです。撫でるように書くことができます。
自分は仕事のツールとして、日常的にボールペンが手放せません。

以前は身に着けるものの一つとして、それなりの逸品に憧れを持っていました。
一時期は何千円もする、人の目を引くような個性的なボールペンを使っていました。これもめちゃくちゃ質感がよく気に入っていはいたのですが、重量があり、書き心地が鈍く、持ちにくいという難点がありました。（イタリアのDALLAITIというメーカーのウッドマーブルのボールペンでした）
ボールペンというものの商品の幅をあまり気にしていなかったのです。

ボールペンウッドマーブルAKR63G DALLAITI ダライッティイタリアブランド

知人に教えてもらい、行き着いたのは100円のボールペンでした。
書き心地が最高です。紙を撫でるようにすべらせるだけで、しっかり軌跡を残すことができます。なめらかさと軽さと入手しやすさが最高です。以来これをずっと使っています。根元の所が割れてしまったりしましたが、すぐに買い換えました。
めちゃくちゃ安価であるというのは、おまけみたいなもので、気軽に使いやすい逸品に出会えたことに感謝です。

DALLAITIのボールペンも、工夫してJETSTREAMの替え芯が使えるように改造してみましたが、それでも100円のボールペンのほうがお気に入りで、ずっと使っているのはこちらのほうです。

三菱鉛筆 uni ジェットストリームスタンダード油性ボールペン 0.5mm 黒 [1本] SXN15005.24

三菱鉛筆ボールペン替芯ジェットストリーム 0.5 黒 5本 SXR-55P

まとめ

おすすめ4つでした。
もちろんこれが自分の生涯の唯一無二の4つ、などというつもりはありません。これからも増えることを期待しています。

わりとこの4つに共通していることは、

高価ではなく、特別なものではない（大事にしまっておくのではない）
日常的に使う（使いまくる）
軽い（疲れない）
入手しやすい（壊れてもすぐに買い替えられる）

日常的に使うものは、より精査してストレスをゼロに近づける工夫をすることが大切な気がします。
時々は周りにあるモノを見直して、時々は世の中の常識を疑うぐらいの姿勢が必要に思いました。

不便さを意識し続けて、ある時、ぴったり「これ」というものに出会えると、その瞬間から生活が快適になるわけです。
不便だなあと思うことと、便利だなあと思うことがあってこその発見に思います。

以上です。
よろしければコメントで、あなたの便利アイテムを教えていただけますと幸いです。

WindowsとMacのどちらを選ぶべきか→どっちでもよい

2020-06-21T23:25:00.001+09:00

Windowsパソコンを選ぶべきか、MacOSを選ぶべきかについて考えてみます。
パソコンを始めて買う人、もしくはWindowsを使っていてMacが気になる人、またはその逆の人向けです。
自分はWindowsもMacも使って、デザインや開発もWebもWebじゃないこともやってました。

先に結論を言うと、どっちでもよいです。
身もフタモありませんが、必要に応じて覚えればよいだけです。
ただゲームがしたいならWindows（とくに自作）をおすすめします。

この記事は、次の4つからできています。
WindowsとMacのそれぞれの特徴、Windowsを選ぶべき人、Macを選ぶべき人、まとめとアドバイスです。

パソコンは道具なので、それを使って何をやるか、何をやりたいかのほうが重要です。

WindowsとMacのそれぞれの特徴

WindowsとMacの特徴をまとめておきます。

基本的にはWindowsでもMacでも、大枠できることに大きな違いはありません。
ひと昔前は、グラフィックス系の仕事はMacのほうが強いと言われていました。細かなことはさておき、その理由はグラフィックス系の仕事ではMacの比率のほうが高かったことが大きな要因です。現在はそれほどMacの使用比率は高くもありませんし、グラフィック系のソフトウェア（PhotoShop、Illustratorなど）もWindowsにしか対応していないソフトウェア、Macにしか対応していないソフトウェアという縛りもそれほどなくなりました。

WindowsとMacの特徴を、デザイン、価格、選択肢、販路、市場シェア、対応ソフトウェア、セキュリティ、顧客満足度の8つの項目でそれぞれまとめてみます。

デザイン

ハードウェアもソフトウェアも、デザインはMacのほうが優れています。
パソコンにデザイン要素が必要なのか、疑問に思われていたような黎明期からMacはデザインにこだわっていました。
今でも同じように必要のない、という意見は耳にします。とくに業務上など、必要のない人には無用の要素かもしれません。
ただ、Macのデザインは見た目だけではなく、設計、耐久度、省電力性、梱包や配送、開封時、メンテナンス、廃棄時のリサイクルにいたるまでに及んでいて、一貫して高品質を提供する姿勢が見て取れます。
Windowsが一貫性に乏しいことは昔から揶揄されています。

価格

価格はWindowsのほうが有利でしょう。
10万円以下で入手できるMacはほとんどありません。安くてもWindowsマシンならば、いろいろな選択肢があるので、目的に合わせたパソコンが見つかりやすいはずです。ただMacに使われる部品は、どれも高品質で、高価格帯のものが備えられていることが多くて、単純な比較は難しいかもしれません。
Windowsのほうが有利と言いましたが、たとえばMicrosoft Surfaceは決して割安には思えません。このあたりもピンキリなので要注意です。

選択肢

Windowsパソコンの形状や構成は多種多様で、Macに比べて選択肢が幅広いです。
Macはモデルが限られていて、カスタマイズができるものその自由度は低いです。
WindowsはOSやパーツを個別に購入して組み立てて自作することができるので、自由度は無限です。
ただし自作をする場合は、メーカー品のノートブックのような軽量化を求めるのは無理があります。

販売方法

MacはAppleでしか買えません。
ほとんどの場合はMacはAppleStoreやAppleStoreOnlineでしかMacを入手することはできません。
MacはmacOSとセットです。
マイクロソフトはハードウェアの製造をしていないので、Windowsは様々なメーカーの販売するパソコンから購入できます。
Windowsだけを個別で購入することもできます。

市場シェア

直近（2020年5月）の市場シェアは87%がWindowsで、9.6%がMac、残りはLinuxなどその他のOSが使われているようです。
Windowsが圧倒的です。
世の中にあるパソコンはほとんどWindowsといえるでしょう。

Operating system market share
https://netmarketshare.com/operating-system-market-share.aspx

対応ソフトウェア

ビジネス用途やゲームなど、対応しているソフトウェアはWindowsのほうが多いです。
Windowsに対応しているゲームの数はMacの8倍ほどあります。
市場シェアからも、たくさんの人が使っているWindowsにソフトウェアを対応させるのは当然のことでしょう。

セキュリティ

Windowsは市場シェアが大きいがゆえに、情報を盗むことを目的とした悪意のあるソフトウェアに狙われやすいようです。
Macがコンピュータウィルスに狙われないわけではないものの、犠牲になる可能性はものすごく低いでしょう。
ただWindowsにはWindows Defenderというセキュリティソフトが最初から守ってくれているので、一般的な使い方ではそれほど気にする必要はなくなっています。
問題が起こりやすいのは、Windowsを更新せずに古いまま使っているケースでしょう。

顧客満足度

MacとWindowsの満足度調査では、Macは、信頼性、サービスエクスペリエンス、電話の保留時間などのカテゴリでほかのどのWindowsよりも高い評価を得たというデータがあります。
Apple StoreでもAppleのカスタマーサポートでも、Macを使っている以上は一律で対応してくれることが一因かもしれません。
Windowsが不安定になったときは、マイクロソフトではなくて通常はパソコンメーカーが対応することになります。故障はソフトウェアが原因かもしれないしハードウェアが原因かもしれません。はっきりと特定するのはかなり骨が折れるでしょう。別々の会社と話をする必要があるかもしれません。故障の特定が困難な場合、本当にサポートが受けられるのでしょうか。

2010 Reliability and Service Survey: Desktops | PCWorld
http://www.pcworld.com/article/211081/2010_reliability_and_service_survey_desktops.html

Reliability and Service: Laptops | PCWorld
http://www.pcworld.com/article/211402/reliability_and_service_laptops.html

Windowsを選ぶべき人

WindowsかMacかで比較すると、どうしても違いを見て、あれこれ言う構図になってしまいがちです。優位性は何をやるために使うのかという目的次第なので、性能を比較して、どちらが優位かという批評はほとんど意味がないと思います。

特徴を比較する上では、対応ソフトウェア（とくにゲーム）、コストパフォーマンスを優先したい人はWindowsがおすすめです。

ゲームをやりたい人はWindowsのほうがおすすめ

パソコンを購入したら何が何でもパソコンゲームをやりたいという人にはWindowsがおすすめです。これは明確に言えます。
基本的にパソコンゲームはWindowsで遊べるように作られていて、そのなかでMacにも対応しているゲームがちらほらあるという感じです。

WindowsにもMacにも対応しているゲームは、具体的にはマインクラフト、フォートナイト、荒野行動などです。
Macに対応していないゲームは、レインボーシックスシージ、PUBGなど（今後の対応などは解りませんが）

ゲームをやる人には自作がおすすめです

ゲームはグラフィック性能が求められます。
なので、ビデオカードが搭載されているパソコンを用意する必要があります。
Macはモデルごとにカスタマイズはできますが自由度はほとんどありません（しかもけっこう割高です）。対してWindows自作パソコンは構成を自在に選別できるだけでなく、市販に近い性能でもめちゃくちゃ安くできます。もちろんそのためには知識が必要です。
ただ、ゲームをモチベーションに行動すできる人は、パソコンの自作もゲーム感覚で楽しめると思います。長くいろいろと楽しみたい人は、パソコンの知識はあらゆるところで必要にもなってくるでしょうし、そこで得た知識は必ず役に立つことでしょう。

Macを選ぶべき人

WindowsとMacはそんなにできることに大きな違いがあるわけではありません。なので、どちらを使用しても大差はないのです。

ただ特徴を比較する上では、デザインや満足度を優先する人にはMacがおすすめです。

Macのデザインが気になる人はMacがおすすめ

「Windowsパソコンを選ぶべきか、MacOSを選ぶべきか」
この問いに行き着いた人は、Macを選ぶべきだと思います。
パソコンのほとんどはWindowsなのです。ソフトウェアもWindowsに対応しているものが圧倒的に多いわけです。なのに、この問いに行き着くということは、Macが気になっているといえる気がします。

Appleのサポートはよいです

個人的な経験則からも、Macのサポートに助けられたことは何度もあります。
Macの修理をリペアセンターに出すときは、クロネコヤマトが集荷に来てくれます。
iMacでもMacBookでも、本体を渡すだけで専用の梱包材で梱包して持っていってくれます。めちゃくちゃスムーズです。
その後の修理の状況もオンラインで追跡できるので安心でした。
もちろん、全員の問題が解決するかどうかは解りませんし、他のメーカーの対応でもっとスムーズな対応があるかもしれません。
修理対応の期間は10日や2週間を目途にと、わりと長めに指定されます。仕事で使っている人は、パソコンが2週間も手元からなくなるのは致命的でしょう（郵送以外にも直接持ち込みする方法もあります）。ただ、自分の場合はほとんど、予定よりも早めに修理が終わって戻ってきました。

まとめとアドバイス

WindowsとMacについて書いてきましたがいかがだったでしょうか。
大枠は、どちらを選んでも大差はないので、好きな方を選べばよいでしょう。時間とエネルギーを裂きたくない人は、自分が慣れているほうが圧倒的に楽なはずです。

Windowsを使っている人は、Macは使いにくいとよく耳にします。
どうしてそうなるかというと、Windowsに慣れている人が、Macを操作してWindowsならできたことが同じ操作でできずに迷ってしまうということかなと思います。
こういうことが何度もあると、Macは使いにくいという結論になるのかもしれません。迷ったら後ろ向きに諦めてしまわずに、さくっと調べて知識を積み上げていけばよいわけです。それだけのことだと思います。迷ったときこそ、スキルアップのポイントなのです。

ただ始めて使う人、ゲームをしたい人、それによくわからないと言う人はWindowsを選べばよいと思います。世の中のほとんどのパソコンはWindowsなので標準的なパソコンを使っておいて、仕事でもなんでも困るということはありません。（Windowsを所持していることで「Windowsが使える」と就職に有利になったりはしないでしょうが）

以上です。
ではよきパソコンライフを！

Mac選び(2020年版)→おすすめはMacBook Air

2020-06-10T23:20:00.000+09:00

Macが欲しいけれどどれを選べばよいかとお悩みの人向けです。
パソコン全般に、それほど詳しくない人向けに書いています。
自分は20年以上のパソコン経験者です。WindowsもMacも使い、デザインも開発もWebもWebじゃないこともやってました。

Macモデルの最近のアップデートをまとめます。
去年2019年にMacBook Pro16インチ（旧15インチ）が発表されました。
そのあと、MacBook Airの2020年モデルが発表されて、5月にMacBook Pro13インチが新しくなったばかりです。発表内容はご存知の通り、大きく変わったのはキーボードでした。
また、6月のWWDC（appleの開発者向けイベント）でARM版の格安Macが発表されるのではという噂があります（ただし発売は2021年とか）。

さて、現時点（2020年上半期）の自分の一押しはMacBook Airの上位モデルです。
これはまさに今自分のほしいMacモデルでもあります。

ということで、先におすすめを言ってしまいましたが、この記事は次の4つから出来ています。
MacBook Airをおすすめしたい人、おすすめの根拠、安く買う具体的な方法、買うときのアドバイスです。

MacBook AirとMacBook Proのスペック比較とかベンチマーク比較とか、何が変わったかとかは出てきません。
この記事は具体的な情報を比較して批評するというよりは、経験からくる所感を語っています。数字は客観的な指標ではありますが、極端な性能ではない限り普段使いには影響しないのです。
なんせ自分は2020年モデルを所持しているわけではありませんｗ　持ってないのにあれこれ言うわけなので業が深い記事なのです。

MacBook Airをおすすめしたい人

MacBook Airをおすすめしたいのはこんな人です。

出費を抑えたい人

基本的には自由に好きなMacを買ってくださいというのが前提なわけですが、できるだけ出費を抑えたいというのは万人の方針だと思います。

何かを始めたい人

Macに限りませんが、何のために買うのかというのははっきりしているほうがよいです。
今使っているのが古くなったという理由で、なんとなく買ってももちろんかまいませんが、買い替えるものに何を期待するのかというのは大切なことです。

→こういうことを始めるのに適しています: ブログ、プログラミング、ホームページ作成、写真管理、イラスト、2Dグラフィックス（PhotoShopやIllustratorなど）、インターネット、映画／アニメなどの動画視聴（Netflix、Hulu、Amazon Prime、YouTube)、ショッピング、株取引、SNS、スケジュール管理、文書作成、旅行計画、そのほかの事務作業、ブラウザゲーム、などなど。
→こういうことには適していません: 動画編集（たとえばYouTuberを目指している人）、3Dゲーム（グラフィックの性能が必要なもの。ブラウザゲームや軽量なものを除きます）

動画編集やゲームはランク上のMacBook Pro(16インチ)かiMac(27インチ)が必要となるかもしれません。グラフィック性能を使うためです。この辺のところだけでも押さえておけば、大体のことは快適に扱うことができるはずです。

MacBook Airはエントリモデルなので、性能面が心配かもしれませんが大丈夫です。
仕事でも趣味でも使えます。
今自分が毎日使っている型落ちのMacBook Pro 13インチよりも、おすすめしている2020年のMacBook Air（上位モデル）は倍くらい性能が上なのです。

たとえば、動画編集やゲームが気持ちよく動かなかったりするのは、性能差というより用途の違いです。軽自動車に馬力がないと言っているようなものです。普段使いであれば何も問題ないでしょう。

MacBook Airがおすすめの根拠

ノートもデスクトップも含めて、現時点（2020年上半期）ではMacBook Airの上位モデルがおすすめです。
MacBook Airがおすすめの理由では、構成がシンプルであることです。

Macモデルはいずれも製品の完成度が高いです。
ただ、MacBook Airをおすすめする根拠としては、MacBook Airが突出しているというよりも、どちらかというとMacBook ProとiMacに個人的にマイナスポイントがあります。
ただ、マイナスポイントとはいえ、収束するところはいずれも割高であるというのが根本の理由です。
躯体はよいものです。なので、気にしない人には関係のないところです。

MacBook Proのマイナスポイント

MacBook Proのマイナスポイントは、言わずもがなTouch Barです。

Touch Barとは、キーボードのF1からF12の部分をディスプレイ式のタッチスクリーンになっているものです。
使用するアプリケーションによって切り替わり、操作などがワンタッチでできるように補助してくれる機能です。
キーの表示をカスタマイズすることもできるようです。

MacBook ProのTouch Barなしモデルは2019年になくなってしまっていて、MacBook ProはいずれもTouch bar搭載モデルだけになってしまいました。
これがすこぶる評判が悪いです。
新しい機能なので、慣れている人ほど違和感が感じるのか、どうもプラスアルファの付加価値があまり功を奏していないようです。

自分も個人的にあまり好ましく思っていません。
たとえばTouch Barだけ別売りで3万円くらいするとしたら買うでしょうか。自分は買いません。
Touch Barは標準のファンクションキー(F1～F12)に固定しておくことができるので、不便というわけではないらしいです。ただ、それならば最初から物理キーでよいわけです。

MacBook Proは不要なTouch barが搭載されている分、割高であると言えます。
MacBook Proももちろんよい製品ですが、MacBook Pro 13インチではなくてMacBook Airをオススメしている最大の理由はここです。

MacBook Airはスペックも形状もMacBook Pro 13インチと似ています。ほとんど同じです。唯一の決定的な違いはTouch barの搭載有無くらいなのです。MacBook AirはMacBook Pro 13インチのTouch barなしモデルと言ってもよいくらいなのです。

iMacのマイナスポイント

iMacのマイナスポイントはドライブです。
ディスク容量が割高です。

今ではスマホもメモリタイプのドライブ(SSDと言います)が主流ですが、いまだに円盤が回転するタイプのディスクが軸になっているところが残念です。MacBook Proなどで使用されているドライブとは接続形式も違っていて、かんたんに言うと旧式で遅いものが使われています。

現状は残念です。SSDの選択は必須に思えますが、そちらを選ぶとプラス3万円くらいになり、かなり割高になってしまいます。
そのくらいの出費が許容できる人はよいかもしれません。ただ、これはさすがに次のアップデートで改善されると思います。おそらくSSDが初期選択で、現状と同じ価格になるでしょう。あるいは予想以上の大幅なアップデートがあってもおかしくありません。

なので、iMacがほしいという人は待つのがよいです。
iMacは次のアップデートに期待です。

MacBook Airの上位モデルがおすすめの理由

おすすめとして挙げているのは具体的には、上位モデルとされるMacBook Airの1.1GHzクアッドコアCore i5プロセッサ（Turbo Boost使用時最大3.5GHz）、512GBストレージのモデルです。価格は、134,800円（税別）です。

下位モデルと上位モデルの違いは、CPUと容量だけです。
CPUのアップグレードで＋\10000、容量が256GBから512GBのアップグレードで+\20,000という違いです。
とくに、CPUのアップグレードが割安に思うのでおすすめです。

下位モデルではダメなのか、というとそんなこともありません。性能差は時間のかかる処理のときに影響があるというだけで、普段の使用時に体感としての違いはほとんどないはずです。
下位モデルの価格は104,800円（税別）なので、どちらを優先するかはその人がどのくらいに出費を抑えたいかによります。

安く買う具体的な方法

出費を抑えるに越したことはないでしょう。
Macモデルは新品でも安く買える方法があります。これはいろいろなところで紹介されていると思います。ただし、代わりに犠牲になるのは時間です。なので必要なら、待たずにさっさと行動するほうをおすすめします。

初売りに買う

毎年1月2日に、Appleストアやオンラインストアでは初売りをやっています。
対象のApple製品や購入者にギフトカードが贈られるというもので、ギフトカードはApple製品の購入に使うことができます。

2020年は、MacBook Pro (13インチ)は24,000円、MacBook Airは12,000円分がギフトカードとして還元されていました。

整備調整品を待つ

初期不良など何らかの理由で返却された製品を、点検を行って改めて販売されているものが整備調整品です。
通常の販売価格よりもおよそ15％くらい割引で買うことができます。カスタマイズなどはできません。

整備調整品はオンラインで買えます。自分が使っているMacBook Pro13インチも整備調整品を購入したものです。
Appleの厳しい検査に合格したものなので普通にサポートも受けられます。

ただ、製品には限りがあり、お望みのモデルや構成を買うのは大変かもしれません。待っても現れない可能性もあります。（今見ると2019年5月発売のMacBook Pro15インチしかありませんでした）

Apple品質を保証します。
Apple認定の整備プロセスを経て品質が保証された新品同様の製品です。1年間の製品保証が付いています。

認定整備済製品 - Apple（日本）
https://www.apple.com/jp/shop/refurbished

中古品を買う

中古品を探すことも選択肢としてあってよいと思います。
ただ、Macは売るときに価格が落ちないのと同じように、中古で買うときもそれほどの割安感はありません。

使用からアップデートや保証が打ち切られる年月が近いと思うと、あんまりかなあという気もします。型落ちの買い替えを繰り返すというのも手かもしれません。ただ頻繁に買い替えるのは、セットアップなどにわりと時間を取られるので、自分はおすすめはしません。
中古であることをまったく気にせず1円でも安くという人はよいでしょう。

パソコンを買うときのアドバイス

経験則からのアドバイスできることはないか考えてみました。

MacBook Airをおすすめしましたが、もちろん人によります。
Macを買うのにあんまり神経質になって性能比較を気にする必要はないと思います。
大切なのは、何に使うかという用途のほうです。用途がはっきりしていないと、選択肢もはっきりしません。
新しい手帳を使うように、始めたいこと、変えたい習慣をふんだんに盛り込んで可能性を膨らませるほどよいと思います。

もちろん、買ってから想定していた用途とは別にどんどんと興味が他に移ることはあります。これは素晴らしいことで、いろいろなことに興味の矛先が向いて、始められることが増えることはよいことです。人は変わっていくものなので。

ただ甘い言葉に惑わされないようにしたいです。
「買って損なし」「所有欲が満たされる」なんていう言葉に気を付けましょう。購入だけをすすめるような言葉に翻弄されるのはよい結果にならなりません。

自分の経験の上では、パソコンに詳しくなるほど、最新のパソコンにこだわらなくなります。パソコンに限らないかもしれません。弘法筆を選ばずというと大げさですが、ミーハーさが減って、仕事道具として成立してくるわけです。消耗品として割り切ることができてきます。ただ、どんなパソコンでもよいというのは違って、余裕が出てくるせいか「こだわりがこじれてくる」感じです。これがないと嫌だとか、これはないほうがむしろよいとか。どんどんこじれてきます。
（記事内に書いたようにTouch Barはないほうがよい部類です）

パソコンを買う機会は、たまにしかないことです。
パソコンに詳しくなりたい人は、今後のスキルアップのための糧になります。できるだけ仕様についてなど調べて、他のパソコンとも比較しながら、できるだけ時間をかけてあれこれ悩むほどよいと思います。
パソコンに詳しくなるつもりがない人は、詳しい人のおすすめに習うのがよいでしょう。できるだけ時間を使わないほうがよいと思います。

だらだら書いてしまいましたが以上です！
あなたによきMacライフがやってくることを願います！

[C#]要素をすべて掛ける（乗算する）

2016-06-28T11:02:00.000+09:00

要素をすべて乗算したかったんです。
すべて足し合わせるのは、Sumを使えばいいのですがLINQには乗算はありません。すべて掛けるなんて、あんまり使わないしね。
ExcelにはPRODUCT関数というのがあるらしく、値の積を計算するもののようです。このキーワードを知っていたら手早く探せたかも…。

Aggregateを使う

掛けるときはAggregateを使うとスマートでした。

int product = list.Aggregate((now, next) => now * next);

Aggregateコードは、LINQを使わずに展開すると下のコードと同じものです。

int next = 1;
foreach (int now in list) {
    next *= now;
}
int product = next;

めでたしめでたし。

サンプルソース

int[] list = { 1, 2, 3, 4 };

// すべて足す
int sum = list.Sum();
Console.WriteLine(sum); // 10

// すべて掛ける
int p = 1;
foreach (int val in list) {
    p *= val;
}
Console.WriteLine(p); // 24

// すべて掛ける
int product = list.Aggregate((now, next) => now * next);
Console.WriteLine(product); // 24

機会があったら覚えていくスタンス

さて、余談ですがAggregateはMSDNでは次のように説明されています。

Aggregate<TSource>(IEnumerable<TSource>, Func<TSource, TSource, TSource>)
シーケンスにアキュムレータ関数を適用します。

なんのこっちゃ、ぜんぜんわかりません。
LINQは使い方を知れば便利そうと解るけれど、インテリセンスやMSDNからの習得は難しいものもあるようです。
サンプルのコードがあって、こういう風に使うんだという一例があれば、なんとなくわかるし習得も容易ですね。

日頃よく使わないメソッドはやっぱりその挙動にも不安が残るものです。何度も検証しないと手放しで任せられないし、乗算のコードに展開したものを書いても、そんな目くじらを立てるほどのロスがあるわけでもありません。
意地でも新しいことを覚えないというスタンスはどうかと思いますが、片っ端から習得しようとしてもほとんどは出番がなく使わないままなのが現実です。
なので、機会があったら覚えていこうというくらいでいいかなと。

もちろんそのすべてを習得して自在に連携している人もいるでしょうし、それが理想モデルです。
けれど、自在に扱える人も右往左往しながら習得したはずですよ。

以上です。よきLINQライフを！

Calculate product with LINQ
http://stackoverflow.com/questions/252333/calculate-product-with-linq

Azureでwoffを使う

2016-06-14T11:56:00.001+09:00

AzureのWebSitesにアップロードしたサイトに、ずっと出てたエラーです。
VS2015でサイト作成すると、最初からbootstrapが標準装備されていてアイコン用のWebフォントとしてglyphicons-halflings-regular.woffが付いてくるのです。

Failed to load resource: the server responded with a status of 404 (Not Found)

というエラーが2つ出てました。「glyphicons-halflings-regular.woff」と「glyphicons-halflings-regular.woff2」が見つからないと言っているらしい。

アイコン用のWebフォントは、woffが見つからなかったりブラウザが対応してないときは、svgやらttfやらが代替として使われます。表示に支障がないので放置してたわけですが、このたび解決しました。

web.configに設定する

ファイルの種類で弾かれているみたいで、woff形式を許容するようにweb.configに設定を追加すればいいらしい。
エラーが気持ち悪いのでcssで弾くようにしようかとも思っていたけれど、どう考えてもこっちのほうが本線でした。

<system.webServer>
  <staticContent>
    <mimeMap fileExtension="woff" mimeType="application/font-woff" />
    <mimeMap fileExtension="woff2" mimeType="application/font-woff" />
  </staticContent>
</system.webServer>

WOFF files return 404 (Not Found) in Azure Web Sites
http://www.codepal.co.uk/show/WOFF_files_return_404_in_Azure_Web_Sites

ばっちりです。

デバック環境がローカルで、サーバーにアップロードして動かないケースというのは、起こってみないと気付かないものですね。こういうのが経験と呼ばれるものになっていけばいいなあ。
というか、標準装備してるんだから、最初から設定しておいてくれりゃいいのにね。

はい、おしまい。

[C#]絵文字の対策

2016-06-13T08:26:00.002+09:00

MySQLにインサートしようと思ったら、

MySQL Error： Incorrect string value

というエラーで止まってしまいました。

どうやら対象の文字のなかに絵文字があって、そいつが引っかかっていたようです。
1文字2バイトで表現される普通の文字と違って、絵文字は1文字が4バイト構成で表現されていて、そいつらはサロゲートペア文字というようです。

対策を考える

対策として考えたのは2つ。

MySQLのDBを1文字4バイトに対応させる方法
絵文字を除去してしまう方法

ううむ。これって、4バイトへの対策はMySQLに丸投げしてるだけだし、絵文字除去も臭いものにフタという感じで、見方によってはどちらも雑な気がします。

そもそも絵文字なんて気にもしていなかったわけだし、晴天の霹靂のようにエラーが発生してから、どうしようかなあなんて考えている時点で遅くて、とりあえず一時しのぎの対策を講じようというのは少し危険ですね。
まあ、そんなこと言っていても始まらないので対策に飛びつく前に、少しだけ落ち着いて全体を見渡しておきましょう。
抑え込むだけではなくて、それぞれの対策の要点を理解したうえでどちらか都合のいいほうを選ぶという分には、きっと少しはマシでしょう。

DBを1文字4バイトに対応させる

MySQLは5.5以降からUTF8MB4に対応しているようなので、設定してあげればよいようです。
現在のテーブルごとの文字コードを確認するのと、指定のテーブルのキャラクターセットをutf8mb4に変更するSQLです。

-- 現在の文字コードの確認
show table status from データベース名;

-- テーブルのキャラクターセットを変更
alter table テーブル名 default character set utf8mb4;

※
なお、今回は除去する方針をとったので絵文字対応後の行追加は未検証です。

絵文字を除去する

絵文字を判別して除外する方法です。もしくは、よくある「〓（下駄）」のような文字に置き換えておくというのも手かもしれません。

// 絵文字を除外する
text = new string(text.Where(n => !Char.IsSurrogate(n)).ToArray());

// 絵文字を〓に置換
text = new string(text.Select(n => Char.IsSurrogate(n) ? '〓' : n).ToArray());

どちらも、やっていることは、Char配列に分解してから、一文字づつサロゲートペア文字かどうか判別しているだけ。
そのあとくっつけなおして文字列型に戻しています。

まとめ

ということで勉強になりました。
ちなみに、自分は絵文字を排除するように対応しました。
DBの設定を変えられないわけではないけれど、要件上では「めちゃくちゃ頻度が少ない」のと「残しておいて有用なことはない」と判断できたからです。
強引に除去しただけなので、文章のつながりが解らなくなるのも出るかもしれないけれど、それはやむなしってことで。

iOSやAndroidもサポートしちゃっている絵文字なので、もっと自在に扱えるようにならないといけなさそうな時流ではありますね。
しかし、この話、ちゃんと理解しようとすると深そうです。なのでこの辺で〆ておきますです…。

[C#]GraphicsPathから各点の情報を取得する

2016-04-25T08:18:00.000+09:00

GraphicsPathはおなじみのパスデータを扱うクラスです。
描画時には、GraphicsPathはそのまま、GraphicsのDrawPathメソッド／FillPathメソッドの引数として利用することができるので、中身を意識する必要はありませんね。

GraphicsPathの各点の情報は、PathDataプロパティで取得することができます。
後述しますが、GraphicsPath.PathPointsプロパティとGraphicsPath.PathTypesプロパティで点を拾っても同じなのですが、GraphicsPath.PathDataプロパティを使うほうが効率的です。

GraphicsPathのPathDataプロパティを使う

PathDataには、Points（PointFの配列）とTypes（byteの配列）を持ちます。PointsとTypesの配列数は必ず同じになります。
Pointsで座標点を表し、Typesでは点の種類を表します。Typeとして持つのは、直線であるか曲線であるかというような情報です。

0	始点
1	直線
3	ベジェ曲線（3点セット）
128	終点

0は始点。128は終点です。128はビットフラグですので、直線からの終点は129、曲線からの終点は131となります。
ベジェ曲線は、3つ続きで表現されます。直前の点から伸びるハンドル、次の点へ伸びるハンドル、次の点座標の3つが1つのセットとなります。

各点を描画するコード

理屈はさておき、各点を描画してみます。

ソースコード

文字のアウトラインパスに、イラストレータ風にいうところのパスとハンドルを描画してみます。
Form上にPictureBoxを置いて、Buttonをトリガーにしています。

// using System.Drawing;
private void button1_Click(object sender, EventArgs e) {
    string str = "永";

    Graphics g = this.pictureBox1.CreateGraphics();
    g.SmoothingMode = SmoothingMode.HighQuality;
    

    // 1.文字のアウトラインの描画
    float fontSize = 200f;
    FontFamily fontFamily = new FontFamily("メイリオ");

    GraphicsPath path = new GraphicsPath();
    StringFormat format = new StringFormat();
    path.AddString(str, fontFamily, (int)FontStyle.Bold, fontSize, Point.Empty, format);

    g.FillPath(Brushes.LightGray, path);


    // 2.パスデータをとりだす
    PathData pathData = path.PathData;

    PointF[] points = pathData.Points;
    byte[] types = pathData.Types;
    int pointCount = points.Length;
    
    // 3.パスとハンドルを描画する
    PointF prev = PointF.Empty;
    for (int i = 0; i < pointCount; i++) {
        PointF p = points[i];
        byte t = types[i];

        if ((t & 3) == 3) { // 曲線
            this.DrawHandle(g, prev, p);

            i++;
            p = points[i];
            this.DrawHandle(g, points[i + 1], p);

            i++;
            p = points[i];
            this.DrawPathPoint(g, p);
        } else if ((t & 1) == 1 || t == 0) { // 直線
            this.DrawPathPoint(g, p);
        }

        prev = p;
    }

    g.Dispose();
}

// ポイントのサイズ
private const float POINT_SIZE = 5.0f;

// パスを描画する
private void DrawPathPoint(Graphics g ,PointF p) {
    g.FillRectangle(Brushes.Red, p.X - POINT_SIZE * 0.5f, p.Y - POINT_SIZE * 0.5f, POINT_SIZE, POINT_SIZE);
}

// ハンドルを描画する
private void DrawHandle(Graphics g, PointF p1, PointF p2) {
    g.DrawLine(Pens.Blue, p1,p2);
    g.FillEllipse(Brushes.Blue, p2.X - POINT_SIZE * 0.5f, p2.Y - POINT_SIZE * 0.5f, POINT_SIZE, POINT_SIZE);
}

このコードを実行するとこのようになります。

いい感じですね。

コードの解説

上のコードは、1.文字のアウトラインの描画、2.パスデータをとりだし、3.パスとハンドルの描画という3つの工程から出来ています。

1.文字のアウトラインの描画

「永」という文字を描画するためのコードです。
GraphicsPathのAddStringメソッドで、座標の取得対象になるパス情報を生成しています。
生成したGraphicsPathは、GraphicsのFillPathメソッドで描画しています。

2.パスデータをとりだし

PathDataプロパティにより、パス情報を取得します。
パス情報は、座標点のPointsプロパティと、点の種類を示すTypesプロパティに分かれます。

3.パスとハンドルの描画

PathData.Typesにより点の種類を判別しながら、パスとハンドルを描画しています。
パスは四角、ハンドルは丸と線を描画しています。
曲線の座標点は、一つ前の点から伸びるハンドル、次の点から伸びるハンドル、次の点座標の3つが1セットとして記録されています。

点の種類を判別するために古典的なビット判定を使っています。

(t & 1) == 1　→直線
(t & 3) == 3　→曲線

注意点：GraphicsPath.PathData.PointsプロパティとGraphicsPath.PathPointsプロパティ

GraphicsPathにはPathDataプロパティの他に、GraphicsPath.PathPointsプロパティとGraphicsPath.PathTypesプロパティがあります。
GraphicsPath.PathData.Pointsプロパティも、GraphicsPath.PathPointsプロパティも、まったく同じなのですが、ここで注意してもらいたいことがあります。

プロパティというものの性質から、単に保持している値を拾ってくるだけという印象がありますが、GraphicsPathの内部では、動的に持っている値を必要に応じて座標点の配列として出力するようにできているようです。そのため、参照するだけでもものすごく重たいのです。

例えば、ループ内で次のようなコードを書いてしまうと、参照のたびに処理が入るので結構な非効率なのです。

for (int i = 0; i < pointCount; i++) {
    PointF p = path.PathPoints[i];
    byte t = path.PathTypes[i];
  
    // ... 処理
}

GraphicsPathのPathDataプロパティを拾っておいて、そこからPointsとTypesを参照するのがよいでしょう。

PathData pathData = path.PathData;
PointF[] points = pathData.Points;
byte[] types = pathData.Types;
int pointCount = points.Length;

for (int i = 0; i < pointCount; i++) {
    PointF p = points[i];
    byte t = types[i];
  
    // ... 処理
}

以上です。

[C#]BinaryReaderのReadInt32が遅いとき

2016-04-18T09:14:00.002+09:00

ファイルの読み書きを高速化する

テキストファイルを読み書きするにはStreamReader／StreamWriterを使えばいいのでお手軽です。
テキストファイル以外のバイナリファイルだったり、すべてを読み込むわけにはいかない大きなファイルを扱うときには、BinaryReaderを使うことになるでしょう。

また、繰り返しReadInt32を繰り返し呼んでいるところは、その度にじりじりとファイルアクセスしています。これが首を絞めるということはあまりないかもしれませんが、ファイルアクセスはメモリアクセスと比較すると当然ながら低速です。
速いに越したことはないはずなので、高速化していきましょう。
改善案としては、ReadInt32メソッドを繰り返し呼ぶところを、ReadBytesメソッドで一気読みしてからBitConverter.ToInt32で分離させます。

BitConverterとは

BitConverterはバイナリ配列(byte[])の必要なところを、型変換してくれるクラスです。
BitConverter.ToInt32メソッドは、バイナリ配列と、開始位置を指定してあげれば、その部分のint値が取り出せます。

ReadInt32だけでなく、ほかにもReadDoubleメソッドやReadSingleメソッドも用意されているので、同様の改善ができそうです。
ただし、ReadStringメソッドは、最初からデータサイズ込みの可変長なので、もう一つ奥のほうに手を伸ばさないと難しそうですね。

部分的なまとめ読みができる

データファイルが大きくて、そして全部の情報はいらないというときに、部分的にまとめ読みできるというワザができるわけです。
読み込みだけでなく、書き込みについても同様です。
当方、あんまりファイルアクセスに関わるコードを書かないので勉強になりました。

大きさが定まっていないデータの構造は、必要なところだけを読み込み／書き込みできるように工夫しておくほうが効率的ということですね。

具体例

具体的なサンプルとして、GraphicsPathのパスデータ(PathData)を書き出したバイナリファイルを読み込む処理を考えることにします。
パスデータ(PathData)の座標(Point)の配列をたっぷり持っています。

呼び出し側のコード

using System.Drawing;
using System.IO;

// 呼び出し側

fileStream = new FileStream(fileName, FileMode.Open, FileAccess.Read, FileShare.Read);
binaryReader = new BinaryReader(fileStream,Encoding.UTF8);

// 他の処理

int pointCount = binaryReader.ReadInt32(); // パス数
Point[] points = this.ReadPathPoints(binaryReader, pointCount);

1.BinaryReader.ReadInt32で読み込むコード

// ReadPathPointsメソッド
private Point[] ReadPathPoints(BinaryReader binaryReader, int pointCount) {
    Point[] points = new Point[pointCount];
    for (int i = 0; i < pointCount; i++) {
        int x = binaryReader.ReadInt32();
        int y = binaryReader.ReadInt32();

        points[i] = new Point(x,y);
    }
    return points;
}

2.ReadBytesとBitConverter.ToInt32で読み込むコード

// ReadPathPointsメソッド
private Point[] ReadPathPoints(BinaryReader binaryReader, int pointCount) {
    byte[] b = binaryReader.ReadBytes(pointCount << 3);
  
    Point[] points = new Point[pointCount];
    for (int i = 0; i < pointCount; i++) {
        int x = BitConverter.ToInt32(b, i << 3);
        int y = BitConverter.ToInt32(b, (i << 3) | 4);
    
        points[i] = new Point(x,y);
    }
    return points;
}

※
ビット演算を使っていますが、ビット演算による高速化の恩恵は誤差のレベルです。

速度評価とまとめ

ざっくり処理速度の評価です。
改良ポイントの評価としてはややアバウトですので、参考程度に思ってください。

ReadInt32呼び出しのときは、2388msでした。
改良して669msになりました。処理時間が1/4になりました。

やったね。

ということで、やや限定的ではありますが、左から右に負荷軽減できるテクニックとして勉強になりました。
おしまいです。

バイナリ・ファイルを読み書きするには？［C#、VB］
http://www.atmarkit.co.jp/fdotnet/dotnettips/669bincopy/bincopy.html

[C#]DataTableからDictionaryを作る

2016-04-13T16:33:00.000+09:00

DataTableからDictionaryに変換する方法です。

DataTableからDictionaryに変換

Dictionaryは連想配列と呼ばれるように、キーを指定すると、対応する値を返してくれるデータ構造です。
配列を一つ一つ照合するのではなく、ハッシュテーブルという構造によって、効率よく値を引っ張ってきてくれます。
データサイズが大きく、繰り返し利用するものほど、この恩恵によるメリットが大きくなるでしょう。

また、DataTableは、DBとの親和性も高いので、大きいサイズを取り扱うことが多くなります。
任意の行を拾うのに、DataViewのRowFilterメソッドを使う方法もありますが、やや複雑ですし、ものによっては大げさになりがちです。

さくっと、値だけを拾ってきたいというときに、Dictionaryに変換しておく方法を知っておくと何かと便利です。

ソースコード

// ダミーのDataTableを作成します
DataTable table = new DataTable();
table.Columns.Add("name");
table.Columns.Add("mail");
table.Columns.Add("sex");
table.Columns.Add("age");

table.Rows.Add("杉浦 光", "sugiura_hikaru@example.com", "女", "42");
table.Rows.Add("戸塚 人志", "toduka_hitoshi@example.com", "男", "72");
table.Rows.Add("熊井 知史", "kumai_tomofumi@example.com", "男", "24");
table.Rows.Add("高木 朝陽", "takagi_asahi@example.com", "女", "44");
table.Rows.Add("平田 ちえみ", "hirata_chiemi@example.com", "女", "39");
table.Rows.Add("溝口 隆博", "mizoguchi_takahiro@example.com", "男", "50");
table.Rows.Add("椎名 長利", "shiina_nagatoshi@example.com", "男", "30");
table.Rows.Add("谷 フミヤ", "tani_fumiya@example.com", "男", "27");
table.Rows.Add("黒崎 勝久", "kurosaki_katsuhisa@example.com", "男", "69");
table.Rows.Add("浦野 真一", "urano_shinichi@example.com", "男", "54");

// DataTableをDictionaryに変換します
var dictionary = table.AsEnumerable()
    .ToDictionary(
        row => Convert.ToString(row["name"]), 
        row => Convert.ToString(row["mail"])
    );

Console.WriteLine(dictionary["溝口 隆博"]);
// ●出力結果
// mizoguchi_takahiro@example.com

長いですが、ほとんどはサンプルのためのTableを生成しているだけで、変換してるところは一行です。

var dictionary = table.AsEnumerable()
    .ToDictionary(
        row => Convert.ToString(row["name"]), 
        row => Convert.ToString(row["mail"])
    );

TableクラスのAsEnumerableメソッドでLinQを使えるようにします。
ToDictionaryで、Dictionary化させます。
キーと対応する値を指定します。ここではnameをキーに、mailを値に設定しています。

抽出して変換

AsEnumerableメソッド以降はLINQが使えますので、必要な条件を満たすアイテムのみを抽出することもできます。

ソースコード

// 条件を指定して変換（女性のみ抽出）
var dictionaryWomanOnly = table.AsEnumerable()
    .Where(row => Convert.ToString(row["sex"]) == "女")
    .ToDictionary(
        row => Convert.ToString(row["name"]),
        row => Convert.ToString(row["mail"])
    );

Console.WriteLine(dictionaryWomanOnly.Count());
// ●出力結果
// 3

Transform a DataTable into Dictionary C#
http://stackoverflow.com/questions/19712958/transform-a-datatable-into-dictionary-c-sharp

[C#]Graphics.DrawStringとGraphicsPath.AddStringのサイズを合わせる

2016-04-05T11:49:00.001+09:00

さて。
Graphics.DrawStringメソッドとGraphicsPath.AddStringメソッドはどちらも文字の描画を扱うときに使うメソッドです。
困りごととして、フォントサイズの指定の仕様がそれぞれで異なっていることです。

この記事は、以前に書いた[C#]文字のアウトラインを描くへの補足です。

Graphics.DrawStringメソッドの引数は、Graphics.DrawString(String, Font, Brush, PointF, StringFormat)という指定に対して、GraphicsPath.AddStringメソッドは、GraphicsPath.AddString(String, FontFamily, Int32, Single, Point, StringFormat)です。
Graphics.DrawStringメソッドの呼び出しのFontオブジェクトのフォントサイズをそのまま、GraphicsPath.AddStringメソッドの4つ目の引数に指定すると、AddStringのほうが一回り小さく描画されます。

どちらのメソッドにも72fを指定したときの描画は下のようになります。青がGraphics.DrawString、オレンジがGraphicsPath.AddStringです。

Graphics.DrawStringメソッドとGraphicsPath.AddStringメソッドのフォントサイズの指定には、単位に違いがあり、そのため同じ数値を指定しても出力が異なってしまうようです。

Graphics.DrawStringメソッドに指定するFontは通常Point単位に対して、GraphicsPath.AddStringメソッドに指定するemSizeはPixel単位なのでした。
ということで、単位を合わせるために、変換してあげればよいわけです。

調べたうちでは、3つの方法がありました。

font.Heightプロパティからemサイズを計算する
font.SizeInPointをPixel単位に変換する
FontオブジェクトをPixel単位で生成する

ただし、シビアな精度ではいずれも万能ではありません。
数値計算の誤差だと思いますがサイズによって、またフォントによっても、わずかながらズレが出ますのでご注意ください。

1.font.Heightプロパティからemサイズを計算する

ほしいのはpixel単位のemサイズです。

方法 : フォントメトリックを取得する‎
https://social.msdn.microsoft.com/Search/ja-JP?query=%E3%83%95%E3%82%A9%E3%83%B3%E3%83%88%20%E3%83%A1%E3%83%88%E3%83%AA%E3%83%83%E3%82%AF%E3%82%92%E5%8F%96%E5%BE%97%E3%81%99%E3%82%8B%E2%80%8E%20&pgArea=header&emptyWatermark=true&ac=4

emサイズとは、文字がすっぽりおさまる正方形のサイズです。上の図でいうと、アセントとディセントに少しのスキマを足した大きさになります。
Fontオブジェクトのfont.Heightプロパティは、文字の高さ（一行分の高さ）をPixel単位で取れます。図では、行間に相当します。
これをもとに、Pixcel単位のフォントのemサイズを計算してあげます。

font.GetEmHeightメソッドは、フォントのデザイン単位がとれます。デザイン単位とは、emサイズを2048としたとき（フォントによりますが）の、メトリックのサイズ情報です。同じくデザイン単位の行間はfont.GetLineSpacingメソッドを使って取得できます。

float emSize = (float)font.Height * font.FontFamily.GetEmHeight(font.Style) / font.FontFamily.GetLineSpacing(font.Style);

これでPixel単位のemサイズが取れました。

ソースコード

// using System.Drawing;
string str = "Hello World!";

Graphics g = this.pictureBox1.CreateGraphics();
g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.AntiAlias;
g.SmoothingMode = SmoothingMode.HighQuality;

PointF point = new PointF(5.0f, 15.0f); // 文字を描画する原点（左上）

float fontSize = 72f;
FontFamily fontFamily = new FontFamily("メイリオ");

// Graphics.DrawStringによる描画
Font font = new Font(fontFamily, fontSize); // →単位がPoint
g.DrawString(str, font, Brushes.LightBlue, point);

// GraphicsPath.AddStringによる描画
float emSize = (float)font.Height * font.FontFamily.GetEmHeight(font.Style) / font.FontFamily.GetLineSpacing(font.Style);

GraphicsPath path = new GraphicsPath();
StringFormat format = new StringFormat();
path.AddString(str, font.FontFamily, (int)font.Style, emSize, point, format);
g.DrawPath(Pens.OrangeRed, path);

g.Dispose();

実行結果

これを実行させると、このようになります。

ばっちり、ぴったりです。
青く塗られているほうがGraphics.DrawString、オレンジのフチがGraphicsPath.AddStringによる描画です。

2.font.SizeInPointをPixel単位に変換する

PointをPixelに換算する方法です。
1inch=72pointです。一度、inchに置き換えてから、pixelに変換する方法で計算できます。

float emSize = (float)g.DpiY * font.SizeInPoints / 72.0f;

3.FontオブジェクトをPixel単位で生成する

Fontオブジェクトの生成時に、単位を指定することができます。
通常、単位を省略すると単位はpointになるのですが、GraphicsUnit.Pixelを指定することで、最初からpixcel単位のフォントサイズにしておくことができます。

ソースコード

// using System.Drawing;
string str = "Hello World!";

Graphics g = this.pictureBox1.CreateGraphics();
g.SmoothingMode = SmoothingMode.HighQuality;

PointF point = new PointF(5.0f, 15.0f); // 文字を描画する原点（左上）

float fontSize = 96f;
FontFamily fontFamily = new FontFamily("メイリオ");

// Graphics.DrawStringによる描画
Font font = new Font(fontFamily, fontSize, GraphicsUnit.Pixel); // →単位がPixel
g.DrawString(str, font, Brushes.LightBlue, point);

// GraphicsPath.AddStringによる描画
GraphicsPath path = new GraphicsPath();
StringFormat format = new StringFormat();
path.AddString(str, font.FontFamily, (int)font.Style, font.Size, point, format);
g.DrawPath(Pens.OrangeRed, path);

g.Dispose();

72pointの指定は、Pixel換算だと96pxなので、fontSizeは96にしています。

わずかなズレが出ます

フォントによって、まちまちでズレが出ました。
Georgiaフォントを使用して、「1.font.Heightプロパティからemサイズを計算する」で描画。

Georgiaフォントを使用して、「2.font.SizeInPointをPixel単位に変換する」で描画。

算出方法によって、こちらはぴったり。

また大きいサイズだとぴったりなのですが、小さいサイズを指定するとぴったりにならずにズレが出ることがあります。

フォントサイズ 72ポイント、「2.font.SizeInPointをPixel単位に変換する」で描画。

フォントサイズ 36ポイント、「2.font.SizeInPointをPixel単位に変換する」で描画。

内部の計算誤差なのかなあ。フォントによるズレも、フォントサイズの指定を大きくすることで軽減されるようです。
誤差としてはたぶんだいたい1pixel以内に収まるものなのかなあと思います。
というわけで、いずれも精度的には万能ではありませんので、シビアな見当が必要な方はご注意ください…。

はい、以上です。
文字の描画サイズについてでした！

Font in 'GraphicsPath.AddString' is smaller than usual font
http://stackoverflow.com/questions/2292812/font-in-graphicspath-addstring-is-smaller-than-usual-font

[js]サイズに合わせた画像の縮小

2016-02-21T21:05:00.001+09:00

画像を任意のサイズに縮小するときの計算方法について説明します。
ソースコードにはJavascriptを使っていますが、なるべく言語に依存しないようにするつもりです。

この手の計算は、寄り付かない人には、ものすごく苦手意識があるのではないかと想像します。
落ち着けば、大変な計算はぜんぜん出てきません。
また、理屈を簡潔に語るよりも、計算から感覚的にイメージがつかめるほうがよいと思ったので、わりとくどくど説明しています。

画像を任意のサイズに合わせる

画像を任意の矩形サイズに合わせたいとします。
やってくる画像のサイズはまちまちですが、なるべく画像の全容が見えるようにして、収まらない部分は切り落としてしまうことにします。

当然ですが、幅と高さにサイズを指定して、強引にギュッとゆがめてしまうのは画像にもよろしくありません（変倍というやつです）。
幅と高さは同じ比率（等倍）で収めるものとします。

横長画像か縦長画像かを判定する

画像によって、処理の仕方は2パターンあります。
横長の画像は左右が余るようにしたいですし、縦長の画像は上下を余るようにしたいですね。

具体的な数をもとに考えることができるように、例として、フラミンゴの画像とヒマワリの画像を使います。
それぞれの画像サイズはこちら。

		幅	高さ
A	フラミンゴの画像	450px	300px
B	ヒマワリの画像	400px	400px
描画先の矩形サイズ		100px	80px

フラミンゴの画像とヒマワリの画像を、描画先の矩形サイズに合わせて縮小したいとします。

それぞれの縦横の比率を比較することで、どちらに合わせる画像かを判別させます。

フラミンゴの縦横比率（幅／高さ）= 450px / 300px = 3/2 = 1.5
ヒマワリの縦横比率（幅／高さ）= 400px / 400px = 1.0
描画先の矩形の縦横比率（幅／高さ）= 100px / 80px = 5/4 = 1.2

縦横比率の関係は、
フラミンゴ（1.5）　＞　描画先の矩形（1.2）　＞　ヒマワリ（1.0）
となっています。

描画先の矩形よりも縦横比率が大きいものは横長として扱えばよく、小さいものは縦長として扱えばよいことが解りますね。

切り出す画像と縮小率を計算する

必要となるのは、画像のどの部分を切り出して、どのくらい縮小すればいいかという2つです。
ひとまず横長画像について考えます。

先に縮小比を求める

どのくらい小さく（または大きく）すればいいのかを考えます。

横長の画像は左右に余りますので、画像の高さを、描画先の矩形の高さに合わせると考えると解りやすいですね。

縮小比 = 描画先の矩形の高さ／画像の高さ
です。

※縮小と書いていますが、計算式には縮小と拡大の区別はありません。画像が小さくて、描画先の矩形のほうが大きいときは、縮小比が1よりも大きくなるだけですね。

切り取り領域を決める

画像から領域を切り取り、縮小することで、描画先の矩形に合わせます。
どの部分の領域を切り取ればいいかを求めます。

・高さ
高さはそのまま、画像の高さを描画先の矩形の高さにするだけです。

切り取る領域の高さ = 画像の高さ

・幅
幅について考えます。
切り取る領域の幅に縮小比を掛ければ描画先の矩形の幅になるはずなので、切り出し幅を求めるためには逆に縮小比で割ってあげればよいでしょう。

描画先の矩形の幅 = 切り取る領域の幅×縮小比
なので、
切り取る領域の幅 = 描画先の矩形の幅／縮小比
で計算できます。

・切り取りの開始位置
また切り取りの開始位置は横幅の画像は左右に余る分を、少しずらせばいいことが判ります。
画像の幅と切り取り幅の差分があまりの部分ですので、真ん中の部分を切り取るためには、差分を等分すればよいですね。

ということで、
切り取りの開始位置 = (画像の幅 - 切り取り幅) / 2
で計算できます。

縦長の画像のときの計算

縦長の画像も同じように計算しましょう。
縦長の画像の場合は、縮小比は幅の比率になります。

縮小比 = 描画先の矩形の幅 / 画像の幅

・幅
切り取る領域の幅 = 画像の幅

・高さ
切り取る領域の高さ = 描画先の矩形の高さ／縮小比

・開始位置
開始位置は、上下の位置を決めます。
縦の切り取りの開始位置 = (画像の幅 - 切り取る高さ) / 2
で計算できます。

ソースコード

サンプルとして、画像をロードし、幅250px、高さ100pxに合わせて縮小するソースコードを載せておきます。
なお、言語はJavascriptです。
html内にcanvasのidを持つcanvasタグが配置されているものとします。

var imageFile = "/Images/ヒマワリ.jpg";
var id = "canvas"
var canvasWidth = 250;
var canvasHeight = 100;

var canvas = document.getElementById(id);
canvas.width = canvasWidth;
canvas.height = canvasHeight;
var context = canvas.getContext('2d');

var image = document.createElement('img');
image.src = imageFile;

// 準備
image.onload = function () {
    var imageWidth = image.width;
    var imageHeight = image.height;

    // ①縮小比を計算
    var scale = 1.0;
    if (imageWidth / imageHeight > canvasWidth / canvasHeight) {
        scale = canvasHeight / imageHeight;
    } else {
        scale = canvasWidth / imageWidth;
    }

    // ②切り出し領域を計算
    var clipWidth = canvasWidth / scale;
    var clipHeight = canvasHeight / scale;
    var clipX = (imageWidth - clipWidth) / 2;
    var clipY = (imageHeight - clipHeight) / 2;
　　
    // ③drawImageメソッドの呼び出し
    context.drawImage(image, clipX, clipY, clipWidth, clipHeight, 0, 0, canvasWidth, canvasHeight);

};

解説

計算に使っている変数をざっとリストアップしておきます。

imageWidth	画像のオリジナルサイズの幅
imageHeight	画像のオリジナルサイズの高さ
canvasWidth	指定矩形の幅
canvasHeight	指定矩形の高さ
scale	縮小比
clipX	切り取り領域の開始X座標
clipY	切り取り領域の開始Y座標
clipWidth	切り取り領域の幅
clipHeight	切り取り領域の高さ

準備として、画像を読み込んでから処理されるようにしたいのでonloadイベントに記述しています。

①縮小比を計算

縦横比率を比較し、横長の画像と、縦長の画像に分けて縮小比率を計算しています。

※
完全に横道にそれますが、割り算は掛け算に比べてものすごく遅いです。
(imageWidth / imageHeight > canvasWidth / canvasHeight)
は、下のようにも書けます。
(imageWidth * canvasHeight > imageHeight * canvasWidth)
こちらのほうが高速です。

②切り出し領域を計算

画像の切り出し領域を計算しています。
横長でも縦長でも縮小比が解れば同じ計算式で導くことができます。

※
ただし不要な演算が増えているので注意。

③drawImageメソッドの呼び出し

canvasのdrawImageメソッドを呼び出しています。
drawImageは、canvasにイメージを描画するためのメソッドです。
drawImageは引数の多い9つあるのを使っています。

context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh)

sx,sy,sw,shで描画元からコピーする矩形を指定し、dx,dy,dw,dhで描画先の矩形を指定します。

以上で終わりですが、もう一つだけ足しておきます。

おまけ

上記は、できるだけ画像を矩形いっぱいに広げて収めるという要件でした。
そのため矩形よりもはみ出た領域は切り取られてしまいます。

替わりに、画像を切り取ることなく、画像の全体を矩形に表示したいとします。
こういうのもありそうな話です。

こういう感じですね。

横長画像か縦長画像かを判定するために縦横比率を比較しました。
この判定を反転させます。

上のソースコードでいうと、
if (imageWidth / imageHeight > canvasWidth / canvasHeight) {
を
if (imageWidth / imageHeight < canvasWidth / canvasHeight) {
にする。
するとあら不思議。

幅と高さのどちらを基準にサイズを合わせるか、というのを逆転させればよいので、これだけでできるのです。

おしまい。

[C#]2つの集合の差分を調べる

2016-02-09T23:27:00.000+09:00

集合が2つあって、片方にはなくて、もう片方には存在する要素の差分を調べます。
例として、常用漢字にある漢字で、JIS第1水準にはない漢字を調べるコードを書きます。

常用漢字とJIS第1水準とはなにかをざっくり

常用漢字
https://ja.wikipedia.org/wiki/%E5%B8%B8%E7%94%A8%E6%BC%A2%E5%AD%97

常用漢字とは「現代の国語を書き表す場合の漢字使用の目安」として、国が選定した漢字です。2136字あります。

JIS漢字コード
https://ja.wikipedia.org/wiki/JIS%E6%BC%A2%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89

JIS漢字コードの第1水準漢字とは、日本工業規格において定められた漢字コードのうち使用頻度が高いとされている漢字です。2965字です。

常用漢字はよく使われる目安として出版物や教育に関わるようです。方や、JIS漢字コードはコンピュータ上の日本語表示の文字コードとして作られていたもの。第4水準という一度も見たことのない漢字まで一通り決められています。ざっくり理解ですが、作られた目的は全然違うようです。
しかし、どちらもよく使われる漢字同士なので似通った集合なわけですね。

常用漢字は2136字で、JIS漢字コードの第1水準漢字は2965字です。もちろん、最初から人力で調べる気はありませんので、プログラムに頼りましょう。

コード

常用漢字とJIS漢字コードの第1水準漢字のリストは、こちらのサイトを参考にさせていただきました。

漢字辞典オンライン
http://kanji.jitenon.jp/

漢字のリストは、2つともテキストファイルにしてます。
ここに置いておきます。

// using System.IO;

private void button1_Click(object sender, EventArgs e) {
        
    string joyo = this.ReadFile("常用漢字（2136字）.txt");
    string jis = this.ReadFile("JIS第１水準（2965字）.txt");

        // 差分を拾う
    string sabun = new string(joyo.Where(n => !jis.Contains(n)).ToArray());

    Console.WriteLine(sabun);
}

private string ReadFile(string file) {
    StreamReader reader = new StreamReader(file);
    string text = reader.ReadToEnd();
    reader.Close();

    // 改行を省いておきます
    text = text.Replace(System.Environment.NewLine,"");

    return text;
}

実行結果

上のコードを実行した結果です。

丼刹拉訃恣哺惧羞貪喩彙楷毀嗅傲慄箋瘍辣憬摯踪嘲諧錮緻曖璧籠鬱

はい。
30文字ヒットしました。

解説

解説と言うほどのことはしていませんが、コードはサンプルとなる文字列を拾ってくる部分がほとんどです。
「常用漢字（2136字）.txt」、「JIS第１水準（2965字）.txt」のファイルは実行ファイルの直下に必要です。
ファイルの存在確認すらしてないコードなのでご注意ください。

なんだかんだで、主要な処理は下の一行です。

string sabun = new string(joyo.Where(n => !jis.Contains(n)).ToArray());

joyoにある文字を走査して、jisに存在していない漢字を文字列として再構築しています。

stringはcharの配列として利用できますので、そのままLinqのWhereメソッドを利用します。
jis.Contains(n)は、joyo内の1文字（n）がjis内に含まれていたらtrueを返します。
joyo.Whereメソッドは、否定演算子（!）があるので含まれなかったものだけを戻していきます。
最後に、charの配列から文字列stringを生成してます。

途中にある否定演算子（!）をなくせば、「どちらにも存在する要素を調べる」コードに早変わりします。

string sabun = new string(joyo.Where(n => jis.Contains(n)).ToArray());

こちらのコードでは、常用漢字とJIS第１水準のどちらにも該当する漢字が抽出できます。

おまけに

サンプルとして使用した常用漢字と第1水準漢字のことばかり喋っていますが…。
（知らなかった分、気づきが多かったです）

JIS第1水準は3000字近くあるので、常用漢字を包含しているかと思いきや、そういうわけでもないんですね。
というのも、常用漢字は最近（2010年）に改定されていて、差分文字の多くはそのときに追加されたもののようです。

「丼」とか。たしかに近年になって頻度が増えたのでしょう。
「嵐」とか「韓」とか。流行りとかではないのかもしれないけれど、文化ってそういうものですものね。
「鬱（うつ）」が常用に、というのはいい気はしません。

もちろんJISの漢字コードを改定するわけにいかないですからね。

はい、以上です。
お粗末さまでした。

Windows.oldフォルダは消していいのか？

2016-02-02T18:09:00.001+09:00

知らないうちに増えているフォルダをみると、どうしていいものかわからなくなります。
まして、結構サイズが大きかったりする。
なんとなく、特殊な名称をしているので、わからなくはないですけれど。

結論から。
→放置で勝手に消えます。

Windows.oldフォルダとは？

Windows.oldフォルダは、Windowsアップデートのときにつくられます。
何かあったときに戻せるように古いシステムファイルが保管されたフォルダということです。
このフォルダは、アップデート後28日が経過すると勝手に削除されるらしいので、基本的には放置でよさそうです。

勝手に消えるということがどこかに書いてあるわけではないので、見ず知らずのフォルダが増えていたらギョッとしますね。
Windowsフォルダはシステムドライブの直下にあって、Windowsのシステムまわりを少し触ったことがある人には馴染みがあるでしょう。
システムドライブのすぐ下のフォルダには下手に触らないほうがいいと思うのは普通のことなのですが、サイズを調べてみるとやたらと大きいので、知らないとこれはどうしたものかと思ってしまいます。

ドライブの残りの容量に不安があるなど、少しでも余計なファイルを残しておきたくないという人は、Windowsに入っている「ディスククリーンアップ」というツールを使うことで手動で削除することもできます。

Windows.oldフォルダを削除する

「ディスククリーンアップ」を使うことで、Windows.oldフォルダだけでなく、アップデート時にシステムが据え置きしているファイルも消すことができます。これが結構大きいです。

システムにかかわるファイルやフォルダの移動や削除などを直接操作するというのは、あんまりよろしくありません。どこでどういう操作がどこに関わってくるのかを理解してやらないといけないからですね。Windowsが用意している「ディスククリーンアップ」というお掃除ツールがあるので、できるだけお任せするほうがいいでしょう。

ディスククリーンアップ

スタートメニューから、「Windows管理ツール」のなかの「ディスククリーンアップ」を選び、起動させます。

あるいは「コントロールパネル」→「システムとセキュリティ」→「管理ツール」から探すこともできます。

しばらくして画面がでます。「システムファイルのクリーンアップ」を押します。

ドライブを聞いてくるので、システムドライブ（通常はCドライブ）を選択します。
「どのくらいの空き容量を作成できるのか計算しています。」という画面が出ます。しばらく待ちましょう。

削除するファイルに並んでいるリストが増えました。

リストのなかから、とくに大きいのは、「以前のWindowsのインストール」と「一時Windowsインストールファイル」です。足して7GBほどありました。
「以前のWindowsのインストール」にチェックする操作が、Windows.oldフォルダーを削除する操作になります。
「一時Windowsインストールファイル」は、セットアップに使用された一時ファイルなので、削除しても問題ありません。

必要な項目にチェックをつけて「OK」を押します。

「このコンピューターにある不要なファイルを整理しています。」という画面になります。
途中で、「以前のWindowsのインストールまたは一時インストールファイルをクリーンアップすると、コンピューターを以前のバージョンのWindowsに復元することはできなくなります。この操作を実行しますか？」というメッセージがでます。「はい」を押します。

以上です。
Windows.oldフォルダがなくなっているのを確認しにいきましょう。

Windows.oldフォルダという馴染みのないフォルダの出現を不審に思ってしまうのは、おかしなことではないと思います。アップデートのたびによくわからないディスク容量の増減があって、そこに気づくことができるのは、それだけ日ごろから気を配っているからですね。
ではでは。

Windows.old フォルダーを削除する方法 - Windows ヘルプ
http://windows.microsoft.com/ja-jp/windows-8/how-remove-windows-old-folder

Windowsがしゃべりだしたときの対処

2016-01-22T12:17:00.000+09:00

びっくりしますね。まずは落ち着きましょう。
Windowsがとつぜんしゃべりだして、このような画面が出ました。

「終了」を押すと、画面は閉じられてナレーターは終了します。

ナレーター（音声案内）について

これは画面上の操作を音声案内で読み上げる、ナレーター（音声案内とも）と呼ばれる機能です。
すべてのWindowsに便利機能として搭載されているようです。

ナレーターを起動／停止させるショートカットキーは、Windowsキー+Enterです。なぜか、とてつもなくアクセスしやすいショートカットがわり当てられているのです。
知らずに、このショートカットをうっかり叩いてしまうことでナレーターが起動してしゃべりだすという仕掛けなのです。

とくに仕事で利用している人は、PCの音量設定がどうなっているか、意識すらしていないのではないでしょうか。そこで、とつぜん機械音声でしゃべりだすわけです。
没頭していた作業が吹っ飛ぶほど、周りの目が一気に集中してしまって、困惑の渦中に放り出されてしまいます…。周りにいるのが知っている人たちだけならまだしも、出先の移動中や、カフェなんかで、おもむろにしゃべりだされてしまうと考えるだけでも疲れてしまいますね。

おそらく、多くの人にとっては不要と思われる機能なので、ナレーターを無効にしておきましょう。

ナレーターを起動しないようにするには

ショートカットは理解できたものの、今後間違えないというのは本人がコントロールできることではないので、ナレーターのほうを起動させないように設定しておくのが無難でしょう。
ナレーターの設定のなかに、キーボードショートカットを無効にするような項目があればいいんですが、ないのですよね。

ショートカットを無効にするのにレジストリをいじる方法や、ナレーター自体を削除してしまう若干乱暴な方法もあるようですが、ソフトウェアに制限を掛ける方法が解りやすかったのでご紹介します。
レジストリ同様、普段さわることがないところですが、意味も解らないままレジストリを操作するよりも安全です。

なお、画面はWindows10ですが、Windows8でも同じ操作で制限することができます。

ナレーターが起動しないように制限します

ソフトウェアを許可しないというWindowsの機能を使って、ナレーターを起動しないように制限します。

Windowsロゴを右クリックするなどして、コントロールパネルを開きます。
コントロールパネルから「システムとセキュリティ」に行きます。

下のほうにある「管理ツール」を開きます。

見知らぬアイコンがたくさん並んでいます。「ローカルセキュリティポリシー」を探しましょう。

→「名前空間 '～' は、既にストア内の別のファイルのターゲット名前空間として定義されています。」というメッセージが出ても、無視してOKを押しましょう。

ソフトウェアの制限のポリシーに行きます。

「ソフトウェアの制限のポリシーが定義されていません」と表示されている場合は、右クリックメニューを呼び出して「新しいソフトウェアの制限ポリシー」をクリックします。
すでに適用されているときは必要ありません。

追加の規則を右クリックしてメニューを呼び出し「新しいパスの規則」をクリックします。

参照から、ナレーター（Narrator.exe）を探すか、パスに「C:\Windows\System32\Narrator.exe」と入れて、OKを押します。

以上です。お疲れ様でした。
これでナレーターの起動が許可されなくなりました。
ショートカットを間違えて押してしまっても、Windowsはうんともすんともいいませんよ。

Windows 8 でナレーターが起動しないようにしたい
http://pasofaq.jp/windows/admintools/win8nonarrator.htm

iPad Proのサイズ感についてまとめる

2015-09-10T16:21:00.001+09:00

Appleイベント Hey Siri, give us a hint. Apple公式

昨晩のイベント（現地10時）でiPad proが発表されました。
大きめのiPadです。何がproなのかは謎ですが。
発表内容を、ざっとさらいます。

発表内容

iPhone 6sとiPhone 6s Plus 発表

CPUなどのスペックとカメラのアップデート。
新色、ピンクが登場。
タッチよりさらに押し込み感知する「3D Touch」搭載。

iPad Pro 発表

新しい大きめのiPad。スピーカーがすごい。キーボード兼用カバーの「Smart Keybord」、「Apple Pencil」と組み合わせられる。

iPad mini4

薄くなって、パワーアップ。

Apple Watch

新デザインと新色が登場。

Apple TV

機能強化。Siriやアプリに対応。リモコンのデザインも新しくなった。

20秒でわかるApple新発表のまとめ
http://www.lifehacker.jp/2015/09/150910_20sec_apple.html?utm_content=buffer80257&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

ほぼ前評判通りの発表

iPhone 6sの登場が期待されていて、新色＋3D Touch搭載というほぼ予想通り、前評判通りの発表。
メインはiPad Proですね。
またしても新しい解像度のサイズが出現したことで、アプリ開発者は大変ですね。解像度に依存せずシームレスに表現できるアプリがいいのでしょうけれど、やっぱりデバイスごとに使いやすくデザインされているもののほうが勝るのでしょう。iPad miniとiPad Proは用途が異なるように思うので、異なる用途を想定したUIであるほうが好ましいと思われるので。

iPad Proのサイズ感をまとめる

新しく発表されたiPad Proのサイズ感をまとめてみます。
iPad Proの大きさは、幅220.6mm×高さ305.7mm×厚さ6.9mmです。（→公式より）

この大きさは、A4よりも少し大きく、MacBook Pro13インチ（Retinaディスプレイモデル）よりも若干小さいサイズです。

また、iPad mini4を二つ並べたよりも大きい。文庫本を4つ並べたよりも大きいようです（文庫本がA6なので当然ですが）。

iPad Air2がB5よりも少し小さめのサイズです。
厚さ6.9mmというので、2枚重ねてもMacBook Pro13より薄いのだからすごい。持った感じはどんな感じなんだろうか。MacBook Pro13のディスプレイ部分だけを手に取ってる感じだろうか。

現行のiPadとiPhone 6sを並べたサイズ感はこのようになります。
iPad Pro、iPad Air 2、iPad mini4、iPhone 6s Plus、iPhone 6s。

iPad Proとは？

さて、今後の展開についての妄想です。
iPadは3つのサイズ展開をすることになります。ご存じiPad Pro(A4)とiPad Air(B5)とiPad mini(A5)ですね。

もちろん売れっ子なのはiPad Air2だと思われる。iPad mini4はおまけみたいなポジションでしょう。iPhone6を持っている人は、わざわざiPad miniを使う意味があんまりないからです（使っている人はいるかもしれないけれど）。

しかし、今回なんといってもProである。
何がProなのかというと、やっぱり機能てんこ盛りにするフラッグシップモデルとしてのProなのではないかと思う。つまり新しい技術はiPad Proから始まって、iPad AirとiPad miniに卸していくような構図を予想すればいいのではないでしょうか。
そうではないと、Proと銘打つ理由がないではないですか。

「3D Touch」なる技術もiPadにも搭載されることになるのだろうけれど、iPad Proはさらに先んじてパワーアップしていくのではないかとそういう感じで期待したい。
個人的に妄想しているのを吐き出しておきます。1週間くらい充電しなくてもいい長時間バッテリーとか、ディスプレイのリフレッシュレートが倍くらいになって、ビデオカメラも同様にパワーアップしたらとてつもなく（Retinaディスプレイ並のインパクト）すごいなあ、とまあ、このくらいで。

ただ大きいだけのProとか認めませんよ！

MeCabにWikipediaの単語を追加する

2015-08-11T22:54:00.001+09:00

ニュースコンテンツに含まれる用語・単語を抽出するような、いわゆるキーワード抽出がやりたいなあと思ったので、その過程で試せるMeCabとWikipediaの単語登録をやってみました。
達成目標はあんまり高くなくていい。それっぽいことができたらいいかなくらいで、さくっといろいろ動かしてみるというところを目標にしています。
参考にしているサイトや記事が2011年なので、なんとも今更って技術なのかもしれません。MeCabもWikipediaもすごいってことですね。
Windows向け、使用言語はC#です。

ざっと紹介する内容は下の通りです。

MeCabをインストールする
Wikipediaのページタイトルを辞書登録する（ダウンロード→CSVに変換→辞書ファイルに変換→辞書ファイルを登録する→まずは動かしてみる）
Wikipediaから除外したほうがいい単語を考える

MeCabを導入してみる

MeCabをインストールします。

MeCab - Wikipedia
https://ja.wikipedia.org/wiki/MeCab

MeCabとは

文章を解析して、名詞や動詞、形容詞などの文節に区切ってくれるソフトです。
形態素解析と呼ばれます。

こういう感じです。

すもももももももものうち
すもも名詞,一般,*,*,*,*,すもも,スモモ,スモモ
も助詞,係助詞,*,*,*,*,も,モ,モ
もも名詞,一般,*,*,*,*,もも,モモ,モモ
も助詞,係助詞,*,*,*,*,も,モ,モ
もも名詞,一般,*,*,*,*,もも,モモ,モモ
の助詞,連体化,*,*,*,*,の,ノ,ノ
うち名詞,非自立,副詞可能,*,*,*,うち,ウチ,ウチ
EOS

MeCabのWindows版をインストールします

以下のサイトからWindows版のexeファイル「mecab-0.98.exe」をダウンロードする。
http://sourceforge.net/projects/mecab/files/

「mecab-win32」→「0.98」→「mecab-0.98.exe」をダウンロードします。
インストール時に聞いてくる文字コードは、UTF-8を選択しました。

MeCabのWindows版をインストールしてみる : 走りながら考えるエンジニア
http://handsrecs2nd.seesaa.net/article/140090025.html

MeCabを使ってみる

とりあえず実行してみる。
MeCabを実行するためにバッチファイルを作ります。

"C:\Program Files (x86)\MeCab\bin\mecab.exe" in.txt -o out.txt

in.txtは、解析した文章を入れて、テキストファイルにしたものです。
バッチファイルで上を実行すると解析結果がout.txtに出力されます。

入力テキストはニュースから拝借しました。他意はありません。

人工知能創造的な仕事奪う?(2015年8月9日(日)掲載) - Yahoo!ニュース
http://news.yahoo.co.jp/pickup/6170034

実行結果はこのようになります。

入力テキスト

人工知能研究に、新たにディープラーニングというアイデアが出現。『ターミネーター』や『攻殻機動隊』など、空想の世界が現実味を帯びてきた。

出力結果

人工 名詞,一般,*,*,*,*,人工,ジンコウ,ジンコー
知能 名詞,一般,*,*,*,*,知能,チノウ,チノー
研究 名詞,サ変接続,*,*,*,*,研究,ケンキュウ,ケンキュー
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ
、 記号,読点,*,*,*,*,、,、,、
新た 名詞,形容動詞語幹,*,*,*,*,新た,アラタ,アラタ
に 助詞,副詞化,*,*,*,*,に,ニ,ニ
ディープラーニング 名詞,固有名詞,組織,*,*,*,*
という 助詞,格助詞,連語,*,*,*,という,トイウ,トユウ
アイデア 名詞,一般,*,*,*,*,アイデア,アイデア,アイデア
が 助詞,格助詞,一般,*,*,*,が,ガ,ガ
出現 名詞,サ変接続,*,*,*,*,出現,シュツゲン,シュツゲン
。 記号,句点,*,*,*,*,。,。,。
『 記号,括弧開,*,*,*,*,『,『,『
ターミネーター 名詞,固有名詞,一般,*,*,*,ターミネーター,ターミネーター,ターミネーター
』 記号,括弧閉,*,*,*,*,』,』,』
や 助詞,並立助詞,*,*,*,*,や,ヤ,ヤ
『 記号,括弧開,*,*,*,*,『,『,『
攻 名詞,固有名詞,人名,名,*,*,攻,オサム,オサム
殻 名詞,一般,*,*,*,*,殻,カラ,カラ
機動 名詞,一般,*,*,*,*,機動,キドウ,キドー
隊 名詞,接尾,一般,*,*,*,隊,タイ,タイ
』 記号,括弧閉,*,*,*,*,』,』,』
など 助詞,副助詞,*,*,*,*,など,ナド,ナド
、 記号,読点,*,*,*,*,、,、,、
空想 名詞,サ変接続,*,*,*,*,空想,クウソウ,クーソー
の 助詞,連体化,*,*,*,*,の,ノ,ノ
世界 名詞,一般,*,*,*,*,世界,セカイ,セカイ
が 助詞,格助詞,一般,*,*,*,が,ガ,ガ
現実味 名詞,一般,*,*,*,*,現実味,ゲンジツミ,ゲンジツミ
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
帯び 動詞,自立,*,*,一段,連用形,帯びる,オビ,オビ
て 助詞,接続助詞,*,*,*,*,て,テ,テ
き 動詞,非自立,*,*,カ変・クル,連用形,くる,キ,キ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
。 記号,句点,*,*,*,*,。,。,。
EOS

一応さくっと動きました。
これでも画期的で楽しいですが、分断され過ぎて残念。
人工知能、攻殻機動隊が残念ですね。
辞書として単語を追加してあげることで、この辺は回避できます。
しかし、単語一個一個を手作業で辞書を作るのは大変なので、Wikipediaの単語リストを拝借して登録してみます。

Wikipediaのタイトルリストから辞書を作る

Wikipediaのタイトルリストのダウンロード

Wikipediaから見出しリストをダウンロードします。
こちらからダウンロードします。
jawiki-latest-all-titles-in-ns0.gz
http://download.wikimedia.org/jawiki/latest/

wikipediaのタイトルリスト（jawiki-latest-all-titles-in-ns0.gz）をこちら（http://download.wikimedia.org/jawiki/latest/）からダウンロード。適当なディレクトリ（home/foo/bar）に解凍します。

fukushimuのメモ帳 [mecab] mecab辞書にwikipediaのタイトルリストを追加 [wikipedia][はてなキーワード]
http://fukushimu.blog.shinobi.jp/mecab/-mecab-%20mecab%E8%BE%9E%E6%9B%B8%E3%81%ABwikipedia%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%88%E3%83%AB%E3%83%AA%E3%82%B9%E3%83%88%E3%82%92%E8%BF%BD%E5%8A%A0%20-wikipedia--%E3%81%AF%E3%81%A6%E3%81%AA%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89-

なお、Windowsでgzファイルを解凍するには、それなりの解凍ソフトが必要です。ご注意ください。
自分は、Lhaplusで解凍しました。

HoeHoe.com - Lhaplus
http://www7a.biglobe.ne.jp/~schezo/

Wikipedia見出しリストからCSVを作成

見出しリストは、155万行くらいの単語リストです。
こんなんです。

辞書ファイルに変換する前に、ちょっとだけ内容のケアをしてあげます。
CSVから辞書ファイル(.dic)を作成するのに、カンマが単語内に含まれているものは、別の文字に置き換えるなどの対応が必要なのです。
また、後述しますが、キーワードとしてあってもどうしようもない単語も含まれていますので、これを除外するにも、そのまま使うのではなくて、なんらかの置き換えが必要になってくるでしょう。

コンソールアプリとして、さくっとC#で書きました。

using System.IO;
using System.Text.RegularExpressions;

static void Main(string[] args) {
    // 引数の１個目をWikipediaのオリジナルデータとする
    
    if(args.Length == 0 || !File.Exists(args[0])){
        return; // 指定なしかファイルなし
    }

    string wikipedia = args[0];
    string csv = "wikipedia.csv";

    StreamReader reader = new StreamReader(wikipedia, Encoding.UTF8);
    StreamWriter writer = new StreamWriter(csv, false, Encoding.UTF8);
    try{
        while (!reader.EndOfStream) {
            string line = reader.ReadLine();
            int length = line.Length;

            double max = Math.Max(-36000, -400 * Math.Pow(length, 1.5));
            if (length > 1){
                line = line.Replace(',', '_'); // カンマを置換

                writer.WriteLine("{0},0,0,{1},名詞,固有名詞,*,*,*,*,{0},*,*,wikipedia_word,", line, max);
            }

        }
    }catch(Exception ex){
        Console.WriteLine(ex.Message);
    }finally{
        reader.Close();
        writer.Close();
    }

    Console.WriteLine("おわり！");
    Console.ReadKey();
}

カンマ区切りなので、カンマがあるワードだけ置換しておきます。

はい、これで、実行。
100万行以上あるので、計測用にタイマー仕込もうかなとも思ったけれど、動かしてみたら10秒くらいで終わりました。このままでいいことにします。
ただし、出来上がったwikipedia.csvファイルは170MBくらいある。なかなかでかいですね。

CSV（wikipedia.csv）を辞書（.dic）に変換

辞書ファイルをつくるには、MeCabをインストールしたところにある、mecab-dict-index.exeを使うらしい。

"C:\Program Files (x86)\MeCab\bin\mecab-dict-index.exe" -d "C:\Program Files (x86)\MeCab\dic\ipadic" -u wikipedia.dic -f utf8 -t utf8 wikipedia.csv

上を実行。
できた。
wikipedia.dicファイル、223MBでした。（サイズは目安です）

作った辞書をMeCabに登録する

eCabインストール先のetcフォルダにあるmecabrcファイルを書き換えます。

自分のところでは、C:\Program Files (x86)\MeCab\etc\mecabrcでした。
mecabrcは何の拡張子とかついてませんが、メモ帳かなんかで編集すればいいかと。

userdic = "（dicのあるディレクトリ）\wikipedia.dic"
を追加して上書きする。

MeCabを走らせてみる（検証その１）

さあ、実行してみましょう！
ぶっこんでみます。
使う文章は、先ほどと同じテキストです。

入力テキスト

Wikipediaを辞書に登録した出力結果

人工知能 名詞,固有名詞,*,*,*,*,人工知能,*,*,wikipedia_word,
研究 名詞,サ変接続,*,*,*,*,研究,ケンキュウ,ケンキュー
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ
、 記号,読点,*,*,*,*,、,、,、
新 名詞,一般,*,*,*,*,新,シン,シン
たに 名詞,固有名詞,*,*,*,*,たに,*,*,wikipedia_word,
ディープラーニング 名詞,固有名詞,*,*,*,*,ディープラーニング,*,*,wikipedia_word,
とい 名詞,固有名詞,*,*,*,*,とい,*,*,wikipedia_word,
う 感動詞,*,*,*,*,*,う,ウ,ウ
アイデア 名詞,固有名詞,*,*,*,*,アイデア,*,*,wikipedia_word,
が 接続詞,*,*,*,*,*,が,ガ,ガ
出現 名詞,サ変接続,*,*,*,*,出現,シュツゲン,シュツゲン
。 記号,句点,*,*,*,*,。,。,。
『 記号,括弧開,*,*,*,*,『,『,『
ターミネーター 名詞,固有名詞,*,*,*,*,ターミネーター,*,*,wikipedia_word,
』 記号,括弧閉,*,*,*,*,』,』,』
や 助詞,並立助詞,*,*,*,*,や,ヤ,ヤ
『 記号,括弧開,*,*,*,*,『,『,『
攻殻機動隊 名詞,固有名詞,*,*,*,*,攻殻機動隊,*,*,wikipedia_word,
』 記号,括弧閉,*,*,*,*,』,』,』
など 助詞,副助詞,*,*,*,*,など,ナド,ナド
、 記号,読点,*,*,*,*,、,、,、
空想 名詞,固有名詞,*,*,*,*,空想,*,*,wikipedia_word,
の 助詞,連体化,*,*,*,*,の,ノ,ノ
世界 名詞,固有名詞,*,*,*,*,世界,*,*,wikipedia_word,
が 接続詞,*,*,*,*,*,が,ガ,ガ
現実 名詞,固有名詞,*,*,*,*,現実,*,*,wikipedia_word,
味 名詞,一般,*,*,*,*,味,アジ,アジ
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
帯び 動詞,自立,*,*,一段,連用形,帯びる,オビ,オビ
て 助詞,接続助詞,*,*,*,*,て,テ,テ
き 動詞,非自立,*,*,カ変・クル,連用形,くる,キ,キ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
。 記号,句点,*,*,*,*,。,。,。
EOS

いい感じ。
攻殻機動隊はいけました。だけど、wikipedia_wordが邪魔してますね。

たに名詞,固有名詞,*,*,*,*,たに,*,*,wikipedia_word,
とい名詞,固有名詞,*,*,*,*,とい,*,*,wikipedia_word,

こういうのが引っかかってしまうのとややこしい。
固有名詞じゃないのに固有名詞扱いされている語句がヒットしてますね。
こういうのは、あらかじめ除外しておくすることにしましょう。

Wikipediaの見出しリストの除外条件を考える

省ける語句がものすごいありそうなので、除外条件を考えます。

どっちかというと、わりときつめに条件設定しておくほうがいい気がします。
Wikipediaの追加単語に求めているのは、長い単語を優先的にくっつけてほしいというものだからですね。
短すぎる単語とか、マイナーすぎるのはわりとどうでもいい。
条件によって省かれてしまうものは、あんまり優先的な用語ではなかったと諦めてしまってもいい。

記号から始まっている: 記号から始まる単語は除外。ただし、拡張子の登録はあってもいいので.だけ許す。 [!"#$%&'()\*\+\-\.,\/:;<=>?@\[\\\]^_`{|}~]
数字は除外: ただの数字が単語としてあるので除外。ただし0から始まるものだけ残す。007とかあるから。
_アンダーバー＋(曖昧さ回避)は除外
_アンダーバー＋([カテゴリ])は除外: 括弧内でカテゴリが指定されているようです。
これで単語を登録していても無駄なので除外。
_ アンダーバー入りは除外: Wikipediaのタイトルルールなのでしょう。アンダーバーでサブタイトルを指定していうようです。
このページタイトルで単語がヒットすることは絶対にないと言えるので、アンダーバー入りは除外としてしまいます。
(曖昧さ回避)、（[カテゴリ]）も含めて除外対象にしてしまいます。
数字+年、数字+年代は除外しない: 1030年とかが固有名詞として登録されるのはどうかと思うけれど、キーワードとして考えるなら一単語として抽出できるほうが有用な気がするので残す。
数字+年+出来事は除外: 「1935年全豪テニス選手権」というタイトルがあるようです。
こういうのは除外することにします。単語として絶対ヒットしないから。
数字＋月＋数字＋日（日付）は除外しない: 固有名詞としてはもちろん不適切。違和感ありますが、西暦と同じで、キーワードとして考えるなら抽出できるほうがいいので残す。
ひらがな2文字を省く: ひらがな2文字で、Wikipediaにしかない言葉というのをあんまり期待しなくてよさそう。
もともとある辞書で網羅できているものとする。
上の出力結果でも出ているけれど、「たに」「とい」を辞書から除外する。

条件のとこだけだと、ソースはこんな感じですかね。

if (length <= 1){

} else if (line.IndexOf("_") >= 0) {
    // アンダーバー入りは除外
} else if (Regex.IsMatch(line, "^[1-9][0-9]*$")) {
    // 数字
    // 0から始まる数字は残す
} else if (Regex.IsMatch(line, "^[0-9]+[年][代]?$")) {
    // 数字+年
    writer.WriteLine("{0},0,0,{1},名詞,固有名詞,*,*,*,*,{0},*,*,wikipedia_year,", line, max);
} else if (Regex.IsMatch(line, "^[0-9]+[年][^代]+$")) {
    // 数字+年+文字
} else if (Regex.IsMatch(line, "^[0-9]+[月][0-9]+[日]$")) {
    writer.WriteLine("{0},0,0,{1},名詞,固有名詞,*,*,*,*,{0},*,*,wikipedia_date,", line, max);
    // 日付
} else if (Regex.IsMatch(line, "^[!\"#$%&'()\\*\\+\\-\\,\\/:;<=>?@\\[\\\\\\]^_`{|}~]")) {
    // 記号から始まっている（.「ドット」以外）
} else if (Regex.IsMatch(line, "^[ぁ-ん]{2}$")) {
    // ひらがな2文字
} else { 
    writer.WriteLine("{0},0,0,{1},名詞,固有名詞,*,*,*,*,{0},*,*,wikipedia_word,", line, max);
}

除外条件は、年や日付を単語に入れるかどうかなど好みで決めればいいかと。条件はあくまでご参考に。

コストについて

double max = Math.Max(-36000, -400 * Math.Pow(length, 1.5));

この謎の式は参照元のサイトにならって、そのまま使っています。どうやらコストと呼ばれるものらしいです。
値が小さいほど、出現率が高い。
つまりこの式は、長い単語ほど重宝しようという意味のようです。なんか解らないでもない。
しかし、数式自体はよく解らないのでそのまま触らないことにします。

http://mecab.googlecode.com/svn/trunk/mecab/doc/dic.html
コストは,その単語がどれだけ出現しやすいかを示しています. 小さいほど, 出現しやすいという意味になります. 似たような単語と同じスコアを割り振り, その単位で切り出せない場合は, 徐々に小さくしていけばいいと思います。

はい、実行。
まあまあ。
20秒くらい掛かりました。
できたファイルは130MBくらいあるなあ。気にしてても仕方ないからいいや。
同じように、これで辞書ファイルをつくります。

MeCabを走らせてみる（検証その２）

そして、さっきのテキストもう一回実行してみる。

入力テキスト

Wikipedia辞書を使った出力結果

人工知能 名詞,固有名詞,*,*,*,*,人工知能,*,*,wikipedia_word,
研究 名詞,サ変接続,*,*,*,*,研究,ケンキュウ,ケンキュー
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ
、 記号,読点,*,*,*,*,、,、,、
新た 名詞,形容動詞語幹,*,*,*,*,新た,アラタ,アラタ
に 助詞,副詞化,*,*,*,*,に,ニ,ニ
ディープラーニング 名詞,固有名詞,*,*,*,*,ディープラーニング,*,*,wikipedia_word,
という 助詞,格助詞,連語,*,*,*,という,トイウ,トユウ
アイデア 名詞,固有名詞,*,*,*,*,アイデア,*,*,wikipedia_word,
が 接続詞,*,*,*,*,*,が,ガ,ガ
出現 名詞,サ変接続,*,*,*,*,出現,シュツゲン,シュツゲン
。 記号,句点,*,*,*,*,。,。,。
『 記号,括弧開,*,*,*,*,『,『,『
ターミネーター 名詞,固有名詞,*,*,*,*,ターミネーター,*,*,wikipedia_word,
』 記号,括弧閉,*,*,*,*,』,』,』
や 助詞,並立助詞,*,*,*,*,や,ヤ,ヤ
『 記号,括弧開,*,*,*,*,『,『,『
攻殻機動隊 名詞,固有名詞,*,*,*,*,攻殻機動隊,*,*,wikipedia_word,
』 記号,括弧閉,*,*,*,*,』,』,』
など 助詞,副助詞,*,*,*,*,など,ナド,ナド
、 記号,読点,*,*,*,*,、,、,、
空想 名詞,固有名詞,*,*,*,*,空想,*,*,wikipedia_word,
の 助詞,連体化,*,*,*,*,の,ノ,ノ
世界 名詞,固有名詞,*,*,*,*,世界,*,*,wikipedia_word,
が 接続詞,*,*,*,*,*,が,ガ,ガ
現実 名詞,固有名詞,*,*,*,*,現実,*,*,wikipedia_word,
味 名詞,一般,*,*,*,*,味,アジ,アジ
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
帯び 動詞,自立,*,*,一段,連用形,帯びる,オビ,オビ
て 助詞,接続助詞,*,*,*,*,て,テ,テ
き 動詞,非自立,*,*,カ変・クル,連用形,くる,キ,キ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
。 記号,句点,*,*,*,*,。,。,。
EOS

ほぼほぼいい感じです！
いやー、おもしろーい！

単語の除外条件やら、キーワード抽出するためにもっと都合のいいやりかたがあると思うので、さらにここからの調整は必要かもしれません。
しかし、まずはさくっと動かすことができたのでよしとします。

以上です。ではでは。

待ってましたiPod touch 6th！

2015-07-17T19:40:00.002+09:00

おかえりなさい。ようこそ、地球へ。
待ちに待ったiPod touch 6世代目です。
やっぱりiPodは不滅でした。

http://www.apple.com/jp/shop/ipod

iPod touch 6thこっそり登場

3年間放置されっぱなしのiPod touch／iPod nano／iPod shuffleがこのたびアップデートされました。

買い切りのデバイスとして楽しい。やっぱりiPod touchは有用でしょう。
ドローンに乗せてもいいし。
汗まみれの手で触ってもいい。ジョギング用にiPhoneを持ってくのは大げさだったからちょうどいい。
すばらしすぎる。
若干無茶な使い方をしてもいいわけです。
2年縛りのiPhoneにその大役はきつい。

何が変わったのか

内部スペックが大幅強化！いまどきのゲームもサクサクできるはず！
カメラがよくなった！　iPhone6のように、カメラが背面からちょっと出っ張ってるように見えるけど…。と思ったけれど、以前から出っ張ってましたね。机に置くと、出っ張り分がじゃまでがたがたします。
サイズは、5thとまったく同じ！
カラーバリエーションはいまどきのシルバー、ゴールド、スペースグレイに、ナゾのピンクとブルーの5色！（＋おなじみのレッド）
以前のは、カラーバリエーションで並べて見てるとキレイなのだけど、1色選べと言われると難しかった。今回のカラーバリエーションは1色1色にパワーを感じる。
128GBが増えた！
iPod nano／iPod Shuffleはカラーバリエーション以外変化なし！泣ける！

誰向けか？

昔のiPod touch持ちが買い換えるのかな。
iWatchがリッチマン向けとすれば、iPod touchはiPhoneでは贅沢だと思う人向けですかね。
そこそこの楽しみと、知的好奇心の探究、節約術を駆使してiPhone使いに追いてやろうとする人向けでしょうか。iPhoneほしいけれど電話はいらんという層はもういないだろう、さすがに…。iPod touchのアップデート待ちの人ってどのくらいいたのでしょうね。
Android持ちが、iPhoneに手を出すよりもとiPod touch持ちになるとかそういうのはどうでしょう。

iPhoneを含むスマホは、本体代と基本料金の2年縛りなのだから、15万円くらいのどでかい買い物なのです。（気になる人は、ちゃんと計算してみてください）
家で使えればいい人には、3万円くらいでiPhoneと同等の楽しみが手に入るなら、すばらしいことだと思う。

これが最後のアップデートとかありえる？

さて、ここまで、テンション高らかに書いてきたけれど、AppleサイトのメニューにはiPodの文字はもはやなくて、しかもこれだけ引っ張っておいてアップデートはこっそり扱い…。
iPod nanoもカラーバリエーションの変更だけで、そのほかの変更はない。iPod nanoの次のアップデートはいつだよとか考えると少し切なくなってきますね。消えるのか？　消えちゃうのか？
Appleさんからしたら、iPhoneがこれだけ好調ななか節約対象になるデバイスの意味って確かにあまりない。
Apple Musicにかこつけて、かろうじてiPod touchだけでもアップデートしておこうという感じが見えてしまうなあ。次のアップデートが来年とかそういう感じはまるでしない。次は何年後？
これが最後のアップデートとかありえるのか…？

しかし、何よりコンパクト。これはほしい。
iPhoneとiPod touchの二台持ちになってやるぞー。

Yahoo!からの迷惑メールの配信を解除する

2015-07-08T13:41:00.000+09:00

Yahoo!メールに大量の宣伝メールが…。
Yahoo!発信の宣伝メールが、Yahoo!アカウントに大量に来る。久しぶりにアカウントのメールボックスを見ると何十件も来てて埋もれている…。
Yahoo!ショッピングは何となくわからないでもないけれど、Yahoo!パートナーとか、Yahoo!トラベルとか知らないよ～。
ざっとまとめてゴミ箱に放り込むという作業があって、当然開封すらしません。本当に何の意味があるのかも解らない。ユーザー目線としては完全に迷惑メールです。アカウントの大元であるYahoo!からじきじきに配信されているという、迷惑メールにも関わらずはっきり堂々と送られてくるという、何とも逃げ場のない、まるで追い込み漁の魚になった気分です。

で、配信停止できないかなあと重い腰を上げることになる。
迷惑メールのフィルタに登録して、全部削除されるようにして対処している人もいるかもしれません。
そもそも最初から送ってほしくないわけだけど、Yahoo!アカウントとのトレードオフのようです。昔は、楽天でも、そういうメールを大量に送ってくるようなサービスは敬遠されてた気がするけれど、今はあんまり気にする人がいないのでしょうか。送られてくるということは、それなりに効果があったり、毎週楽しみに読んでいる人もいるんでしょうか。その辺りがナゾすぎる。調べようと思うほどの興味もないのですが。

Yahoo!デリバーとやらも配信停止にしとく

Yahoo!デリバーなんて、まったく記憶にないし、登録した覚えもないのだけれど、どうやら登録されているらしい。

Yahoo!デリバーを設定すると、Yahoo! JAPAN又は提携先企業から、新商品、各種セール、お買い得情報などのお知らせが届くようになります。もちろん登録は無料です。
現在、あなたはYahoo!デリバーに登録されています。

そして、登録しないに設定するして次に行くと、注意するメッセージが出る。
めんどくさい作業だなあ。

「Yahoo!デリバー」の登録解除依頼を確認しました。「Yahoo!デリバー」の登録を解除すると、Yahoo!メールの転送サービスはご利用いただけなくなります。また、「Yahoo!デリバー」の登録解除後に、メールソフトやスマートフォンなどのモバイル端末からYahoo!メールのPOP/SMTPアクセスをご利用になると、「Yahoo!デリバー」に再度自動登録されますのでご注意ください。

どうやら、Yahoo!メールの転送サービスを利用する人は、Yahoo!デリバーの登録が必須のようです。転送サービスというのを平たくいうと、スマホでチェックしたい人ということですね。スマホでメールをチェックしたいなら、迷惑メールの受信が義務付けられるという、すごいね、最大手は。
Yahoo!メールをスマホで使うのはやめたほうがいい。Yahoo!メールがメインでなくてよかったー。
まあ、無料のメールアカウントはそれぞれ何かしらあるでしょうけれど。
というわけで、自分は完全解除させます。はい、解除。

登録解除要求を受け付けました。処理が完了するまでには約5営業日かかります。

ナゾの5営業日。もうやだ、この作業。ナゾがナゾを呼ぶ。解除に5営業日かかるってなんだよ。
こうやってYahoo!の森に迷うんです。
まあいいや。さくっと解除。後は、もう知らん。何か発生しない限りもう忘れることにします。

モノホンの迷惑メールは多様化してて、フィルタリングもイタチゴッコだしもっとさらに悪質です。
配信が解除できるだけマシと言えばマシなのだけど、上場してる最大手様がそんなハードル落としていいのか。やりたい放題だなあという印象ですね。Yahoo!だけではないし、今更ですけどね。世の中もっと便利になってほしいです。

おしまいです。
ではよいYahoo!ライフを。

WWDC2015まとめ、iPodなくなる？

2015-06-09T12:04:00.001+09:00

Appleのイベントが日本時間で8日の26時からありました。
WWDCはWorld Wide Developers Conference 2015の略です。つまり開発者向けイベントですね。

WWDC2015さっぱりまとめ

OS X El Capitan（エル・キャピタン）

OS X Yosemiteが10.10なので、OS X El Capitanは10.11でしょうか。

iOS 9

iOSの新しいバージョン。

Swift 2

詳細はよく解りません。何が変わったのでしょう。オープンソースになるらしいです。

WatchOS 2

AppleWatch用の新しいOSのバージョンです。

Apple Music

ストリーミングサービス。要するに月額いくらで、音楽聴き放題のサービスってことですね。使用にはネットワーク接続が必須ですか。ダウンロード版もあるかもしれません。

こんな感じです。さっぱりしたものです。開発者向けだもの。
来年のWWDC2016とか、もうそのまま数字があがるだけなんじゃないでしょうか。
大胆予想！でもないか。新OS X（10.12）、iOS 10、Swift 3、WatchOS 3、Apple Music 2？
ほんとにさっぱりしたものです。

そしてiPod消える

そして、大切なのは、AppleのページのメニューからiPodが消えてしまったことです。

これは新しい別のサービスを追い求めるために、自社での競合するサービスをどんどん縮小させていくということでしょうか。一部の少数派ファンを排除していく仕掛けでもあるわけです。iPodがメニューからなくすってのは、もう将来的に完全にiPodはなくなってしまうという予告なんでしょうか？ MusicからiPodが入手できるとかそういう変化なのでしょうか。

こっそりアップデートがあるんじゃないかと狙っていたけれど、もちろんこっそりなくなるというのもありえるのか…。
なくなってしまうなら、入手できるのは今のうちなので、これはこれでそれなりに悩ましいですね。
現在は、AppleトップページのストアからiPodストアにいけます。

iPodストア - iPod touch、iPod nano、iPod shuffleの購入 - Apple Store（日本）
http://store.apple.com/jp/ipod

また認定の整備済製品で格安に手に入れるという方法もあります。

しんみりしますね

もはや音楽をポケットに入れるような時代ではないんだなあ。
iPhoneと比べたiPod touchの優位性なんて、理屈の上でのことだけで、実際は誰も気にしていないということなのです。
世の中iPodだけではありませんが、iPodが引っ張ってきたものは大きくて、しんみりしてしまいます。

It's only rock and rollのポスターは2009年のもの。
sonyのwalkmanブランドは健在だけれど、これを尻尾切りするようなものですよね。

しかし新しいMusicサービス始めるのにiPod消すってなんだよ！と思わなくもないです。Apple Musicに対応させるデバイスをつくるつもりはないのでしょうか。
AppleWatchは単独では通信できないので、ストリーミングなんて無理ですよね。

もはやYouTubeではPVをいかに稼ぐかというところが軸になっています。それと同じように今後のアーティストの展開は、CDの売り上げを伸ばすかよりも、いかに繰り返し再生されるかというところに尽きるのかもしれません。再生されていくらみたいな感じでしょうか。

今後何が出るやら楽しみ

これだけ音楽に注力していて、iPhoneも大きくしておいて、小型の音楽専用デバイスの肩身が狭くなっていることには違和感しかない。せめてiPod nanoやiPod touchは去年くらいにわずかでもアップデートしてあげればよかったのに…。かわいそすぎる。

Apple、Beatsの30億ドルでの買収を正式発表　ブランドは残す
http://www.itmedia.co.jp/news/articles/1405/29/news041.html

しかし、これだけiPhoneが流通しちゃえば、音楽だけのデバイスの必要性はないのかもしれないね。音楽が聞きたいならiPhoneで聞けばいいっていうのは、そりゃそうだ。懐古主義はダメなのか…。
さてさて、今後何が出るやら楽しみではあります。

WunderlistがMicrosoftグループに参加

2015-06-03T22:49:00.002+09:00

ちょっとびっくりした。
サンマイクロシステムズがOracleに買収されたときのような軽い躍動感を感じました。

Wunderlistは、言わずと知れたマルチデバイスが売りのシンプルなタスク管理のサービスですね。
自分もよく利用してます。

Wunderlist | To-do リスト、リマインダー、タスク管理 - App of the Year!
https://www.wunderlist.com/ja/

Wunderlistにしてみれば、これはすごいことだ。
Microsoftにしてみれば、なんだろう。

MicrosoftはTODOリストも作れないのか…。
もちろんそんなことはないと思うけれど。
Officeに統合されて、カレンダーとも連携が取れるとかそういうことにはなるのだろうか。

自分も使ってるのでよく解るのですが、WunderlistのTODOリストの何がよかったのかというと、シンプルで余計な機能がないからよかったのです。
タスクの管理は、シンプルでないと目が散って集中できない。
便利というのが多機能性ではないということは、いろんなところで一般化されてきたことなのだけど、サービス統合とかは、ものすごく嫌な予感しかしない。

Microsoftの思惑は、要するにWunderlistユーザーをOfficeに誘導しようというものなのだろうな、という想像はできる。
Microsoftアカウントが使えるようになるとかは、めちゃくちゃありそうですね。

Wunderlistが消えてなくなってしまうようなことはないだろうけれど…。
今後のWunderlistのアップデートに注目です。

Windows10の無料アップグレードが怖すぎる

2015-06-02T00:22:00.001+09:00

Windows10がついに7/29にアップグレードできるらしく、うちにもお知らせが届きました。
予約受付という不思議な画面が現れます。

このエントリは個人の印象だけで書いてます。
長年培われた信頼と同じように、不信感も培われているので仕方ないのです。
決してWindows10が嫌いなわけではないけれど、たぶん使うことになるのだろうけれど、そこそこ恩恵を感じることにもなるとも思うのだけど、あまり歓迎する気分ではないのです。こっちからにじり寄る分には幾分か注意もできるけれど、向こうから来られるとこれはもう逃げるしかない。そんな感じなのです。

アップグレードの告知が強引すぎる

うちのWindwos7のタスクトレイに謎のWindowsアイコンが現れる。

Windows10への無料アップグレードの予約画面が表示される。なんというか、ものすごい押しつけがましい。Windowsのアップグレードの文言も強引になってきた。
随所でこの手法が見られる。ライセンス認証手続きや、セットアップ後のMicrosoftアカウント作成時にも感じた手口だ。
推奨する方法を、あたかも必須のように誘導して、他の選択肢を隠しておく。わけもわからずに、誘導されるがまま囲い込んでいくわけですね。すぐ終わりますとか言って、契約書に名前だけ書かせる詐欺に近くて怖すぎる。

こんなの解りにくさという弊害しかなくて、本質的な囲い込みに失敗してることに気付いてほしい。いわゆるパソコンの初心者というのは解らないことに対してはすごく敏感で、これは難しいものだ、と判断すると、もう理解しようとはしてくれないのだ。
日本語訳の問題なのかもしれないけれど、とにかくやめてほしい。それほど初心者のつもりのない人間としても、はっきり嫌気がさしてくる。

不安要素はたっぷり

無料はわかった。として、無料だからいいかというと絶対にそれはない。
Windowsはアップグレードが苦手なんです。無料を謳えば、MacのOSXやiPhoneのiOSと肩を並べられるかというとそんなことはあり得ない。
いろいろと苦労するのは解りきっている。だから、今のうちに考えられるポイントを考察しておきたい。

どうしてもWindows10に恋心を抱いていて、中身がどうなってもいいから、いち早くレビューしたい、触りたいという人（専門用語で人柱と言います）は懸念なんて不要で、思う存分胸躍らせていればいいと思います。そういう楽しみかたはあってもいいはずだ。
だけど実務的には、外見のために中身を犠牲にするのは本末転倒のように思う。

バックアップをとっておくこと

簡単ですなんて言いながら、バックアップは誰もが推奨するところでしょう。バックアップが推奨されるということは、やっぱりそれなりの覚悟が必要ということなのです。
具体的なやり方はそれぞれで調べてほしいですが、システムイメージをまるごと取っておくことと、そのあとの復元手順をも調べておくのがいいと思います。

アップグレードに掛かる時間はどのくらいか

ものすごく気になる。無料で簡単、自動、なんていうと、一瞬で切り替わるような印象を受けるけど、そんなことはない。ディスク空きが3GB必要とかいうのは、なにかをダウンロードしてきて展開して、処理するためのスペースなのだ。3GB分の処理が必要なのです。
Windows8からWindows8.1のアップグレードや、Windows8.1からWindows8.1 updatedへのアップグレードにどのくらい時間を使ったか覚えていますか？
とてつもない労力を使った人もいるはずで、その人たちの阿鼻叫喚のようなレビューは今でも散見できる。

朝、パソコンを立ち上げて作業しようとすると忘れていた更新がおもむろに始まって、一日仕事ができない、メールも見れないとかありそうで怖い。

Microsoftアカウントは必須になるのか？

Windows8.1 updatedなんかはセットアップ後にMicrosoftアカウント取得の手続きが始まる。
アップグレードは自動で開始されるとあるので、おそらくWindows10でもその次のログイン時にアカウント取得せよという手続きが発生するのではないかと。
これがわりと面倒だと思う。
アップグレード後、シームレスにすぐにログイン画面が表示されて、前日の作業の続きが進められるかというとそんなことはないだろう。
ログイン画面にたどり着くまでに、いろいろ設定を聞いてくるはずだ。

アップグレード後、既存の状態に戻せるか？

これは、まず戻せない。アップグレード後、何かあって、失敗した、元の状態に戻したいと思ったときにはすでに手遅れだったりする。
もちろんイメージごとバックアップを取っておいて手動で元に戻すということは可能なはずです。ただし、これを理解して自分で調べて、自分で操作して、やり方を知っている必要があって、これが難しいと思う人には簡単ではないかもしれない（そんなことを言っていては何もできませんが）。自動でやってもらっても、戻すのは手動である理解が必要なのです。

さらに、アップグレードが無料だからといって、Windows10からのクリーンインストールは不可能でしょう。インストールしなおすには、前のバージョンのディスクなりでクリーンインストールしたあとに、再びアップグレードをしないといけない。ずっとそうだった。まあWindowsに限らずiOSとかもその辺はそうなのだけど。
Windows7やWindows8のライセンスで、Windows10でのクリーンインストールがさくっとできるんだったらいいのになー。

そもそも問題なんて起こらないという見方もできる

悲観的なことばっかり書いたけれど、楽観的なことも書きます。

いろいろ問題が起こったときに大変だ、と書いたけど、問題なんて起こらないという考え方もある。
何故ならWindows10とは謳っているけれど、中身はWindows8.1 updatedの延長だからですね。Windows8.1 updated2もしくはWindows8.2と呼んでもいいかもしれない。前バージョンから変わってないのだから問題なんて起こらない。一部のアプリケーションが動かなくなることもありえない。そういう見方もある。

だからMicrosoftが「まったく新しいWindows」とか言えば言うほどユーザーとしてはイメージダウンだったりする。今回のはスタートメニュー復活なので、さすがに新しい連呼はなさそうだけど、替わりに「特別なOS」という意味不明な称号がありますね。

ここまで強気で押している以上、ほとんど変わってない説は有力な気がする。
しかし、それでもWindows7からのアップグレードはやっぱり怖いかなあ。

まとめると、やっぱり安心して予約するわけにはいかない

要するに、予約受付＋無料によるキャッチーなトラップで、そのあとの手続きが面倒なのが一つと、アップグレードによるリスクを見越しておかないと大変な目に合うのではないかと危惧しています。

カンタンっていうのは、何と比べて言ってるのかというと、Windowsの昔のバージョンと比べてしかない。確かに昔のバージョン（2000とか、XPとか）に比べれば、アップグレードが自動更新で済むなんてカンタンと言えるかもしれない。
だけどそのまま手放しで任せられるかというと、まったく任せられない。

そして様子見ばっかり。Windows10へのアップグレードは思うのほか進まない。結局みんなWindows7に留まるとか。Windows8に移行が進まなかったのと同じようなことがあっても不思議はない。これは仕方ないことです。アップグレードする必要がないのに強引にアップグレードさせるのはどうだろう。企業さんとかでは、無料アップグレードの予約ボタンを押さないでくださいとかアナウンスされているのだろうか。

カンタンですよと、すり寄ってきて、更新ボタンを押させる手口が嫌すぎる。7/29にパニック続出にならないことを願います。

今すぐWindows10アップグレードを予約しましょう
無料で簡単。心配はいりません。

怖すぎるでしょ。
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

[C#]DataTableをさくっとつくるには

2015-05-17T17:26:00.004+09:00

何かと便利なDataTableです。
DataTableを扱って何かするときに、慣れれば難しいところはありませんが、とにかく冗長的な印象があります。
まずダミーデータの準備に労力が費やされてしまうことがあって、結構面倒なのです。
そういうDataTableについて、ちょこっと記法に気を付けることで、記述内容を大幅に削減してしまおうというのがこのエントリのテーマです。

DataTableを作成するためのコード

DataTableの作成は①DataColumnを追加して列（スキーマ）を準備、そのあと②データを格納させるDataRowを追加する必要があります。

DataColumnを追加して列（スキーマ）を準備

まず、DataTableのインスタンスをつくる。これはそのまま。

DataTable table = new DataTable();

列となるDataColumnを追加します。
個人情報のようなものが格納されるとして、普通は、こんな感じになりますね。

table.Columns.Add(new DataColumn("name"));
table.Columns.Add(new DataColumn("ruby"));
table.Columns.Add(new DataColumn("sex"));
table.Columns.Add(new DataColumn("age"));
table.Columns.Add(new DataColumn("birthday"));
table.Columns.Add(new DataColumn("married"));
table.Columns.Add(new DataColumn("prefecture"));

はい、これ。
工夫すると、こう書けます。

string[] columnList = { "name", "ruby", "sex", "age", "birthday", "married", "prefecture"};
table.Columns.AddRange(columnList.Select(n => new DataColumn(n)).ToArray());

文字列の配列をもとに、DataColumnの配列を作って一気に追加しています。
たった2行に収まりました。もちろん強引に1行にもできます。

データを格納させるDataRowを追加する

次に、行となるDataRowを追加します。
DataTableに準備した列（スキーマ）に合わせた行を作成するので、DataTableのNewRowメソッドを呼び出して、新しい行になるDataRowを拾ってあげます。
DataRowに設定する値を入れて、改めて、DataTableのRowsプロパティに追加する。
（覚えたてのとき、自分にはこの操作が意味不明でした）
コードにすると、こんな感じです。

DataRow row = table.NewRow();
row["name"] = "三村 瑠璃亜";
row["ruby"] = "みむら るりあ";
row["sex"] = "女";
row["age"] = "32";
row["birthday"] = "1982/7/16";
row["married"] = "既婚";
row["prefecture"] = "茨城県";
table.Rows.Add(row);

これで1個のデータです。結構なカタマリになります。

DataTableのRowsプロパティのAddメソッドには、オーバーロードとしてobject[]を指定することができます。
なので、上のカタマリは、下記のように書いてもいいのです。

table.Rows.Add("三村 瑠璃亜", "みむら るりあ", "女", "32", "1982/7/16", "既婚", "茨城県");

はい、1行です。
行に追加した順番に気を付ける必要がありますが、テストパターンとして内容に変化を付けるときなどは、こちらのほうが見やすいようにも思います。
もちろん、テストデータらしく、hogehogeとかaaaとかだったら、どの列のデータなのかは見失いやすいので注意が必要ですが…。

サンプルコード

ということでざっとDataTableのダミーデータを作成するためのサンプルコードを載せておきます。

// DataTableのダミーデータを作成する

// DataColumnを追加して列（スキーマ）を準備
DataTable table = new DataTable();
string[] columnList = { "name", "ruby", "sex", "age", "birthday", "married", "prefecture"};
table.Columns.AddRange(columnList.Select(n => new DataColumn(n)).ToArray());

// データを格納させるDataRowを追加する
table.Rows.Add("三村 瑠璃亜", "みむら るりあ", "女", "32", "1982/7/16", "既婚", "茨城県");
table.Rows.Add("山崎 隆", "やまざき たかし", "男", "32", "1982/10/3", "未婚", "東京都");
table.Rows.Add("滝 慢太郎", "たき まんたろう", "男", "31", "1983/6/30", "未婚", "福岡県");
table.Rows.Add("石塚 浩正", "いしづか ひろま", "男", "29", "1985/3/1", "既婚", "熊本県");
table.Rows.Add("中西 光", "なかにし ひかる", "男", "55", "1959/2/22", "既婚", "福島県");

コピペコピペでNewRowメソッド呼び出しによる長く平坦な記述よりも、よっぽど表データっていう感じがしますね。

[C#]クエリ文字列を操作する

2015-05-09T22:05:00.000+09:00

ご存じ、URLの後ろにくっついてるパラメータをクエリ文字列と言います。

クエリ文字列を扱うときにDictionaryに変換する自作関数をセコセコ作ったり、またくっつけるための関数を作ったり、そういう操作をしていたのですが、HttpUtility.ParseQueryStringメソッドでまるっと操作できるようです。

HttpUtility.ParseQueryStringメソッドを使う

HttpUtility.ParseQueryStringメソッドはクエリ文字列を引数に、NameValueCollectionオブジェクトを返します。
NameValueCollectionは、Dictionary型のようにキーより値が参照できます。
HttpUtility.ParseQueryStringメソッドが返すNameValueCollectionは、ToStringメソッドで、&と=でつなげたクエリ文字列がそのまま返ります。部分的に値を変更して改めてクエリ文字をつくるような操作もお手の物です。

サンプルコード

// using System.Web;
// using System.Collections.Specialized
// ダミーのURLです
string url = "http://www.hogehoge.co.jp/index.htm?var1=%u3042%u3044%u3046%u3048%u304a&var2=abc&var3=12345";
Uri uri = new Uri(url);
string queryString = uri.Query;

Console.WriteLine(queryString);
// ?var1=%25u3042%25u3044%25u3046%25u3048%25u304a&var2=abc&var3=12345

// ①クエリ文字列からNameValueCollectionを生成
NameValueCollection query = HttpUtility.ParseQueryString(queryString,Encoding.UTF8);

// ②クエリの値を確認
foreach(string key in query.Keys){
    Console.WriteLine(key + "=" + HttpUtility.UrlDecode(query[key]));
}
// var1=あいうえお
// var2=abc
// var3=12345

// ③クエリの値を変更
query["var1"] = "かきくけこ";

// ④クエリ文字列を再生成
Console.WriteLine(query.ToString());
// var1=%u304b%u304d%u304f%u3051%u3053&var2=abc&var3=12345

コードの解説

①クエリ文字列からNameValueCollectionを生成
ダミーURLをもとに、HttpUtility.ParseQueryStringメソッドを使用してクエリ文字列からNameValueCollectionを生成します。

②クエリの値を確認
NameValueCollectionオブジェクトに値がどのように格納されているかクエリの値を確認します。

③クエリの値を変更
キー（var1）に対応するクエリの値を変更します。

④クエリ文字を再生成
NameValueCollectionオブジェクトのToStringメソッドを呼び出すと、=と&で結合されたクエリ文字列が生成されます。

※
NameValueCollectionはSystem.Collections.Specializedというあまり聞きなれない名前空間にあります。
HttpUtility.ParseQueryStringメソッドのために、using System.Web;が必要です。（要System.Web.dll参照）

NameValueCollectionをDictionaryに変換する

NameValueCollectionはDictionaryに似ているのですが、Linqが使えません。
何かとDictionary形式のほうが使い勝手がいいとお考えの人は、変換してあげてください。

Dictionary<string,string> dic = query.Keys.Cast<string>().ToDictionary(n => n, m => query[m]);

それではよきクエリ文字ライフを！

MySQL For ExcelがExcelシート保存時にマクロ警告を出す

2015-04-07T11:06:00.000+09:00

Excelシートの保存時にマクロ警告が出る。
マクロなんて使った覚えはない。便利なソフトが台無しだ。
警告内容は、こんな感じ。

次の機能はマクロなしのブックに保存できません
・定義名で保存されている excel 4.0 関数
これらの機能が含まれるファイルを保存する場合は、［いいえ］をクリックし、［ファイルの種類］ボックスでマクロ有効ファイルの種類を選択してください。
マクロなしのブックとして保存する場合は、［はい］をクリックしてください。

先にいうと、アドインとしてMySQL For Excelが動いてた。
そういえば、MySQLをインストールしたな、と。MySQL For Excelがどういう悪さをしていたのかは知りませんが、これをアンインストールしたら現象が解消されました。
なお、うちのExcelはExcel2010です。

原因調査

マクロなんてそもそも使ってない。
「定義名で保存されている～」という意味がそもそも解らなかったので、そこから調べるはめになる。「定義名で保存されている excel 4.0 関数」というメッセージで検索すると、当然マクロ関係の話や名前の定義にたどり着く。身に覚えのない人は、そこからなかなか先に進めないわけです。
名前の定義やマクロなんか使ってないシートの話なので、謎は深まるばかり。
知らないうちにショーカットが機能しちゃったのだろうか。

名前の定義について

名前の定義とは、セルの範囲に名前を付けて解りやすくしておく機能。範囲選択を自分でつけた名前を利用することで、無機質なセルの整理整頓をしやすくしておけるというもの。

【名前の定義】セル範囲に名前をつける
http://kokoro.kir.jp/excel/name.html

でも自分はそんな機能まったく使っていなかった。

※Excel2010の名前の管理は、「数式」タブ→「定義された名前／名前の管理」から確認できます。

シートの問題ではない気がする

仕方ないので、手当たり次第にいろいろ試してみる。

シートをコピーして新規シートにペーストしても同じ警告メッセージ。新規保存のときには出ないけど、開いて上書き保存するときに出るようだ。
計算も何もないリストアップしただけのシートですら、開いて、即保存で、同じメッセージが出る。

これはおかしい！　シートの問題じゃないだろう。
ひょっとして、ウイルスか？と頭をよぎる。冷や汗…。Excelシートに感染するとか、そういうあれか？

MySQL for Excelのアドインがあやしい

オプションを調べていると、MySQL for Excelがアドインに追加されていた。

※「ファイル」タブ→「オプション」→「アドイン」で拡張機能が確認できます。

そういえば、昨日MySQLサーバーをインストールしたので、そのとき一緒にインストールされていた。
いかにもあやしい。どういうツールなのか調べてみるけれど、この先もMySQL for Excelを使うことはない気がする。
試しに消してみる。

アプリケーションの削除から、さくっとアンインストール。

そしてあっさり解消

あっさり、解消。いやあ、よかったよかった。
ガサツな解決方法だけど目をつむりましょう。

完全にMySQL For Excelを犯人扱いしてしまっているけれど、うちのマシンが特異環境かもしれないので、そのあたりはご留意お願いします。
双方の顔を立てるような解決策はないものか、もう少し掘り下げてもよかったかもしれない。けれど申し訳ないけれど元の環境に戻してあれこれするほど興味が沸きそうにない（どちらかというと一刻も早く忘れたいと思ってこの記事を書いている）ので、この辺で〆。

ありがとうございました。