2017年10月28日土曜日
Google Homeでスケジュールを読み上げる方法
標準の設定では「OK,Google,きょうの予定をおしえて」や「OK,Google,今日はどんな日?」でスケジュールを読み上げてくれます。
ところが、「カレンダーに関連するものは見つかりませんでした」や「すみません、お役に立てそうにありません」と回答されることがあります。2017年10月に日本でも発売されたばかり。
(1)理由はわかりませんが「今日の予定を教えて」で反応しないことがありました。「きょうのスケジュールを教えて」といえば、確実に反応しました。
(2)Google Homeで検索されるカレンダーは、Googleカレンダーの「メインカレンダー」のみのようです。Google Homeに登録しているアカウントのメインカレンダーに予定を追加してみてください。
(3)Google Homeが読み上げるカレンダーは、開始時刻が決まっているものだけのようです。終日のカレンダーは読み上げてくれませんでした。
この点に気をつけると読み上げてくれるようになりました。なかなか便利です。
ちなみに、「Google Homeに比べてGoogle Home miniは音質が悪い」という評判があります。たしかに音楽を聴くには、Google Home miniは低音が弱め。音楽スピーカーとしてではGoogle Homeのほうが良いと思いますが、ラジオを聞いたり、ニュースを聞いたりという使い方をする分にはまったく気にならない音質だと思います。
2016年5月3日火曜日
Ubuntu 14.04LTSから16.04LTSにアップデートする手順
Ubuntu 16.04LTS が2016/4/22(日本時間)にリリースされましたね。
UbuntuのLTS (Long Term Support)版は5年間のセキュリティアップデートなどのサポートが付いているので、 急いで次版にアップデートする必要も無いでしょうが、 せっかくなので最新版への更新手順をメモします。デスクトップ版であればGUIからも更新できますが、コマンドを前提の手順を示します。
普段のアップデート手順
下記コマンドで普段のアップデートは実施しているかと思います。
$ sudo apt-get update
$ sudo apt-get upgrade
下準備
バックアップなど必要に応じて作業しておいてください。
do-release-upgradeコマンドがない場合はパッケージを追加してください。
$ sudo apt-get install update-manager-core
手順1
まずアップデート前のバージョンを確認しておきます。
$ lsb_release -d
Description: Ubuntu 14.04.4 LTS
デスクトップ版であれば、ログイン時にバージョンも表示されています。
手順2
リリースチャネルを確認
$ cat /etc/update-manager/release-upgrades
「Prompt=lts」になっていれば、LTS版のみが更新対象となります。
手順3
$ sudo do-release-upgrade
2016/5/3時点では、 実行しても新しいリリースがないと表示されるかと思います。
新しい Ubuntu のリリースをチェックしています 新しくリリースされたものはありません
これは「http://changelogs.ubuntu.com/meta-release-lts」にまだ16.04LTSが記載されていないから、だと思います。
またSSHからコマンドを実行した場合にも警告メッセージが表示されることがあります。万が一に備えてリモートではなく直接マシンにログインしたほうが良いです。
手順4
手順3でダメな場合は、「-d」オプションを付けて開発版も対象にしてしまいます。
$ sudo do-release-upgrade -d
手順5
アップグレードの確認メッセージが表示されます。
アップグレードを開始しますか? XX 個のパッケージが削除されます。XXX個の新規パッケージがインストールされます。XXXX個のパッケージがアップグレードされます。 合計 978 M をダウンロードする必要があります。このダウンロードは約 3 分かかります。 アップグレードをインストールするのに数時間かかることがあります。ダウンロードが完了してしまうと、処理はキャンセルできません。
yを押して続行します。
ダウンロードと展開が始まります。それなりに時間がかかりますので、そのまま正座で待機します。
手順6
パッケージの削除するかどうかを質問されます。削除する場合はyを入力して続行します。
古いソフトウェアを検索しています パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 データ構造を構築しています... 完了 データ構造を構築しています... 完了 サポートが中止された(あるいはリポジトリに存在しない)パッケージを削除しますか? 258 個のパッケージが削除されます。 パッケージの削除に数時間かかることがあります。 続行する[yN] 詳細 [d]
手順7
再起動の確認メッセージが表示されます。 再起動する場合はyを入力して再起動します。
手順8
起動が完了すると、ログイン画面に「16.04LTS」の表示が確認できます。 コマンドを実行してバージョンを確認します。
$ lsb_release -d
Description: Ubuntu 16.04 LTS
$
デスクトップ版でのログイン時のバージョン表示(16.04LTS)。
これでアップグレードは終わりです。お疲れ様でした。
2016年1月5日火曜日
Mac OSX (El Captian)でbrew updateが動かなかった時に確認すべき対処法
年末の休暇を使ってやっとMacのOS更新をやったのですが、 Mac OS XをEl Captianにアップデートしてから、brew updateがうまく動きませんでした。 下記対処でbrew updateできたのでメモ。
ステップ1:PATHを確認。
しょっぱなからつまずき。なんでコマンドが無いんだよ〜
% brew update
zsh: command not found: brew
% echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin
brewコマンドへのPATHが通っていないみたいですね。私の場合は「/usr/local/bin」がなかったので、一時的に追加して様子を見ます。
% PATH=/usr/local/bin:${PATH}
% export PATH
% echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
% which brew
/usr/local/bin/brew
% brew --help
Example usage:
....省略....
うん、動いておる。
毎回PATHを設定するわけにも行かないので、次回以降のためにPATHの設定をしてしまいましょう。
~/.zshenvをエディタで開いて、
PATH=/usr/local/bin:${PATH}
または
path=(/usr/local/bin(N-/) $path)
とします。
この「(N-/)」の意味はつぎのサイトを参照。ディレクトリパスが存在しない時に空白に置換することで、無視させるテクニックです。複数のPCで.zshenvを共有する場合に便利なので、何も考えずにとにかくつけまくっておけば良いと思う。
(参考)http://qiita.com/mollifier/items/42ae46ff4140251290a7.
ステップ2:パーミッションを確認
ようやくbrewコマンドが実行できるのでためしてみると、エラーが出ますね。
% brew update
error: unable to unlink old '.gitignore' (Permission denied)
error: unable to create file .travis.yml (Permission denied)
error: unable to unlink old '.yardopts' (Permission denied)
error: unable to unlink old 'CODEOFCONDUCT.md' (Permission denied)
error: unable to unlink old 'CONTRIBUTING.md' (Permission denied)
error: unable to unlink old 'LICENSE.txt' (Permission denied)
error: unable to unlink old 'README.md' (Permission denied)
error: unable to unlink old 'SUPPORTERS.md' (Permission denied)
Checking out files: 100% (3823/3823), done.
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master
% brew update
Error: The /usr/local directory is not writable.
Even if this directory was writable when you installed Homebrew, other
software may change permissions on this directory. Some versions of the
"InstantOn" component of Airfoil or running Cocktail cleanup/optimizations
are known to do this.
You should probably change the ownership and permissions of /usr/local
back to your user account.
sudo chown -R $(whoami):admin /usr/local
パーミッションがrootになっているのが原因のようです。brewコマンドのエラーメッセージ通り、chownコマンドを実行してやります。
% sudo chown -R $(whoami):admin /usr/local
Password:
% ls -ld /usr/local
うん、パーミッション変わりました。
ステップ3:アップデート実行!
% brew doctor
% brew update
% brew upgrade
brew upgradeコマンドでは途中でmake bootstrapが走るため数十分くらいかかりましたが、無事成功です!
最後に
それにしてもbrewコマンドのエラーメッセージは優秀ですね。エラーとなる要因(機械的)を示すだけでなく、オペレータ(作業者)が読める形でのエラー説明があり、次に取るべきアクション・解決策をも提示してくれています。こんなエラーメッセージを設計できるなんて、すごいエンジニアだと思います。
2016年1月4日月曜日
尊敬できる人って、具体的にどんな人なの?
「尊敬できる人が好きです」
合コンに行くと、こんなことを言う女の子がいる。
でも、尊敬できる人ってなんだろう。でかい仕事をしていれば尊敬できる人なのだろうか?英語が喋れたら尊敬できる人なのだろうか?料理が上手なら?大金を動かしていたら?部下が多ければ?給料が高ければ?……。
そんなことを考えていた。
年末に読んだ本に松下幸之助の言葉が載っていた。
こんなエピソードだった。
#有名なエピソードだそうで、検索すれば原文や原典が詳しく出てくるかと思う。
❝
まだ松下電器が創業間もない頃、電球工場で、電球を磨くだけの仕事がありました。
従業員もつまらなそうに磨いていると、松下幸之助が声をかけてきます。
正直に「つまらないです。誰でもできる仕事です」と応えると、こう諭しました。
この電球はどこで光っているか知っているか? 君が電球を磨くことで、街頭に明かりがつく。駅から家に安心して帰れる。子供が本を読むことができる。 あなたは電球を磨いてるのではなくて、人の夢を磨いているんだ
❞
やっと気が付いた。
百億円のプロジェクトを回しているから尊敬できる?お茶を淹れるだけの仕事だから……?
そんなことじゃあない。そんな目先のことで、尊敬できるかどうかなんて決まりっこない。
尊敬できる人っていうのは目先のことだけを見るのではなくて、自分のことだけを考えるのではなくて。 その先にいる人のこと、誰かのために出来ることを考えているのだろうと。
あけましておめでとうございます。
そんな、尊敬できる人になるため、本年も邁進して参りますので、よろしくお願いします。
2015年5月27日水曜日
組込み系こそJenkinsでちょっと便利なビルド環境をつくろう
JenkinsってWeb系のひとだけが使って便利なやつだろー?組込みだから関係ないもんねー?なんて思っていませんか。
そんなことはありません。組込みだって活用は可能なんです。だって組込みは、
- クロスコンパイルが当たり前
- 開発環境(有料)のライセンスの都合で、ビルドPCをみんなで使いまわしている
……負荷状況に応じてビルドするマシンを選択してくれたらいいのに! - 開発環境の都合で、OSごとにビルドマシンを用意している
……マシンが多くて管理が面倒くさい! - 開発環境に新しくアプリをインストールするのは嫌だ
なんてこと、ありますよね。Jenkinsならこれを楽に解決できちゃうるんです。
Jenkinsの特徴
ざっくり言ってしまうと、Jenkinsはちょっと賢いcrontabです。 ちょっと賢い部分というのは、
- 処理を開始するトリガに指定した時刻、周期が設定できる
(…cronに似た書式で設定可能) - 処理を開始するトリガにgitやsubversionが更新されたタイミングを簡単に設定できる
(…git hookスクリプトを使用) - 手動でブラウザのUIから処理を開始することができる
- Master-Slave構成が容易に構築できて、分散ビルドもできちゃう
(…Slaveにはインストール不要!) - ビルドマシンがWindowsでも大丈夫
(…Javaが動けばOK) - 複数のマシンのうち、特定のマシンでビルドする設定も簡単(…※1)
- ビルド結果をブラウザで簡単に確認できる
- ビルドした成果物をブラウザで取得できる
- Slaveノード(ビルドマシン)にgitやsubversionがインストールされていなくても、git/subversionの連携が可能!
(…Jenkinsのプラグインを使えば)
というところです。
※1:Slaveノードに「ラベル」を設定でき、処理(ジョブ)を動作させるノードをラベルで指定可能です。 ラベルを使うことでWindowsでなくLinuxで処理をするとか、 特定のマシンを指定して処理をさせることも可能になります。
組込み用ビルドマシンをJenkinsで活用する
Jenkinsは、Master-Slave構成を取ることが出来ます。 MasterノードにはJenkinsをインストールする必要がありますが、Slaveノードにはインストールの必要がありません。 Slaveノードとして動作させるには、
- MasterノードからSlaveノードにSSHで接続ができる(NAT環境は不可)
- SlaveノードでJavaアプリケーション(Java Web Start)が実行できる。(NAT環境もOK)
のどちらかの条件さえ満たしていればよいのです。 Windowsマシンの場合は、Java Web Startを使えばOKです。特に設定は不必要で(※)Jenkinsのブラウザの設定画面から、「jlnp」とかかれたリンクをクリックするだけで起動できます。
(※:環境によってはNATのポート開放や、Firewall設定は必要です)
Jenkinsを使うのに必要なことって?
先に書いたように、「Jenkinsはちょっと賢いcrontab」です。 そのため、ビルドしたり、自動テストしたり、組込み基板に焼きこんだり、したいというならば、それを実行するコマンド/バッチファイルを作成する必要があります。 逆に言えば、コマンドを叩いてできることなら、なんでも連携できちゃいます。
まとめ
というわけで、組込み系でもJenkinsは活用可能です。どんどん活用しましょうよ!!お願いします、、、
インストール方法は他のサイトにお任せいたします…
2015年4月16日木曜日
Windows 10 のフォントレンダリングは文字が欠ける(何も改善されていない)
Windows 7, 8.1でプログラミングする場合、フォントをConsolasなど定番フォント(Inconsolata、Source Code Pro、DejaVu Sans Mono、Anonymous Pro、…)に変更することが一般的です。
しかし、これらのフォントは英数字のみ収録されているため、日本語のコメント文を表示することが出来ません。 日本語が全く表示されず空白になってしまったり、表示されても文字が潰れて読めなかったり、文字の比率がおかしくなってしまう事があります。
対処法には、大きく2つの方法がありました。
①FontLink設定する。
②Rictyのように、英字フォントに日本語フォントを合成する。
デメリットは、①の場合は、英数字以外はメイリオなどを使うようにレジストリを設定した場合、メイリオは横長なので等幅フォント風に幅を調整するパラメータ設定が難しいことです。 ②のデメリットは、windowsのフォント描画性能が悪いせいで「f」や日本語の文字の横棒が消えてしまう問題があることです。フォントサイズ20以上にすればまだ読めるのですが、 現実的に使用する10〜18ポイントでは使い物になりませんでした。 (そこでGDIPPやMacTypeのようなツールに人気がありました)。
Windows 10 (Technical Preview)ではどうか
試しにサクラエディタにてRictyの表示をしてみました。(画像はRicty Diminishedのフォントサイズ12ptです)。
しかし、残念ながらWindows7時代と同様に、文字の一部が欠けてしまいます。「語」の口の部分が几のように下が欠けています。また、英語部分も文字が歪んでいます。
これまでどおり、諦めるか、従来のツールを使うしかなさそうです。
Webで検索するとMacTypeの動作報告がいくつか見つかるため、Windows10でもMacType等のツールに頼るしかないです。
マイクロソフトは改善する予定はない
当然、フォント描画をなんとかしてくれ!という要望は世界中からされているのですが、却下されてしましました。(参照: Improve font rendering)
Improve font renderingAnyone who's used other operating systems knows Cleartype distorts fonts to a point where some look atrocious. In general, it makes fonts too thin and jagged which makes them harder to read. Projects like gdipp and MacType try to address this issue, however, they can't provide the best result.
「他のOSに比べてもWindowsのフォントはギザギザになるし汚いよ。gdippやMacTypeだけじゃ限界があるから、改善してほしいな」という意見に対して、回答は…
Admin (Admin, Microsoft Windows) responded · Mar 26, 2015
Thank you for the great feedback. IE, Windows modern shell and Office all use grayscale. ClearType is only used in a few places on the desktop shell, not in places where people read text. This is no longer an issue starting in Windows 8.
「IEもOfficeもグレースケールを使っていて、ClearTypeは限られた場所で使っているだけだ。Windows8の時点で既に問題は解決されているから、対処はしないよ」と。
つまり、Windows10では、フォントの問題は解決されない見込みです。
2015年4月3日金曜日
MacBook Retina+Windows10で解像度を16:10に変更する方法
Windows 10 Technical Previewが2014年10月から公開されています。
私はMac Book Pro (Retina)で無料の仮想化ソフト「Virtual Box」上にインストールして、Windows 10TPでの動作確認を実施しています。 ところが、Virtual Box上のWindows10 TPでは、標準で選択できる画面解像度は1600x1200、1280x1024、1152x864、1024x768と、画面解像度が4:3のものしか使用できません。
フルスクリーンで使用する場合はもちろんのこと、ウィンドウモードで使用する場合でも16:10や16:9で使用したいと考えるのが普通では無いでしょうか?そこで、Macbook+VirtualBox上のWindows10にて、画面解像度を自在に設定する方法を調べました。
仮想マシン上のWindowsで認識できる解像度の追加方法
Macのターミナルからコマンドを実行することで追加が可能です。
Terminalにて、VirtualBoxのインストールディレクトリに移動します。
cd /Applications/VirtualBox.app/Contents/MacOS
下記のコマンドを実行します。
VBoxManage setextradata "Windows 10 TP" CustomVideoMode1 1280x800x32
VBoxManage setextradata "Windows 10 TP" CustomVideoMode2 1440x900x32
ここでは画面解像度として1280x800と1440x900を追加しています。
「Windows 10 TP」の部分は、VirtualBoxの仮想マシンの設定名称に合わせて変更してください。「Oracle VM VirtualBox マネージャー」の画面にて表示されている名前を使用します。大文字と小文字が区別されることに注意してください。
CustomVideoMode のあとの数字は、追加する数に合わせて1,2,3,...と変更します。
最後の1280x800x32の部分で追加する解像度を指定します。横幅ドットx縦幅ドットx色数ビットの型式で指定します。
※ちなみに、このコマンドはホストOSがWindowsでも共通に使用できます。ディレクトリをC:\Program Files\...に読み替えてやってください。
どの解像度を追加すべきか
Appleの公式サイトに記載があるように、Macbookはアスペクト比が16:10で、iMacは16:9のようです。
https://support.apple.com/ja-jp/HT5266
(16:10) 2560x1600 - MacBook Pro (Retina, 13-inch, Late 2012 以降)
(16:10) 2880x1800 - MacBook Pro (Retina, Mid 2012) および MacBook Pro (Retina, 15-inch, Early 2013 以降)
(16:9) 5120x2880 - iMac (Retina 5K, 27-inch, Late 2014)
したがって、16:10または16:9の画面解像度を設定するのがお勧めです。
Macbook Pro Retinaの場合でも、フルスクリーンであれば16:10が便利ですが、ウィンドウモードで使用する場合にはDockの表示領域を考慮して16:9程度の画面解像度を追加しておくと便利です。
MacbookPro Retina(13in)は、ディスプレイの解像度は2560x1600と高いのですが、実際には擬似解像度として 1280x800ドットと同じ倍率で画面表示されます(標準設定の場合)。 そのため、縦幅800ドット以下の解像度を追加するのが便利です。
画面解像度はWikipediaにリストがありますので、そこから適当に選んできましょう。
http://ja.wikipedia.org/wiki/%E7%94%BB%E9%9D%A2%E8%A7%A3%E5%83%8F%E5%BA%A6
以上から、私のおすすめは 1280x800, 1280x720あたりです。



