2014年4月26日土曜日

Windows 8.1のGoogle Chromeで文字がぼやける

高解像度のWindows 8.1のGoogle Chromeで文字がぼやける現象の対処法。


  1. コントロールパネル→デスクトップのカスタマイズ→テキストやその他の項目の大きさの変更 画面で、「すべてのディスプレイで同じ拡大率を使用する」にチェックを入れてサインインしなおす
  2. タスクバーのChromeアイコンを右クリック→Google Chromeという文字の上で右クリック→プロパティ→互換性タブ→高DPI設定では画面スケーリングを無効にするにチェック
  3. Google Chromeを開いてURL欄に chrome://flags/#high-dpi-support と入力し、HiDPI サポート Windowsを有効にする
これで文字もメニューバー等も大きくなり、かつぼやけてない状態で読めるのではないでしょうか。

2013年10月18日金曜日

Windows 8.1 のフォントなどのサイズを Windows 8 と同じ大きさに戻す方法

昨日の日本時間20時にWindows 8.1が公開されました。
さっそくWindows 8からアップデートしてみたのですが、画面上のすべてが大きい…。
設定をいじってもいくつかのアプリケーション上でフォントがぼやけるなどの問題に少し苦しんだので、私の環境での解決方法を共有しておきます。


1. デスクトップの何もないところを右クリックし、出てきたメニューから「画面の解像度」をクリック


2. 「ディスプレイ表示の変更」が出てくるので、下の方にある「テキストやその他の項目の大きさの変更」をクリック

3. 「すべてのディスプレイで同じ拡大率を使用する」にチェックを入れる

4. 文字サイズを「中-125%」に設定し、適用をクリック

この後サインアウトしなおすと、私の環境ではWindows 8のときと同じサイズで文字が表示されるようになりました。
参考までに。。

2013年5月10日金曜日

さくらのVPSにUbuntu 12.04 を入れた

ちょっとは最近の技術に興味を示そうということで、色々弄れるサーバーが欲しかったのでさくらのVPSを借りました。
サーバーの知識はあまりない素人なので、何をやったか忘れないようにメモ。。

OSのインストール

さくらさんが丁寧にマニュアルを用意してくれているので、それを参考にしました。以下、SSHにてサーバーに接続して作業を行います。

Emacs を入れる

何はともあれemacs入れないと作業がはかどらないよね☆

$ sudo apt-get install emacs23

Firewallの設定

こちらのブログを参考にして設定を行いました。Firewallを有効にし、sshでログインできるように設定。サーバーなので、80番ポートも解法。

$ sudo ufw enable
$ sudo ufw default DENY
$ sudo ufw allow ssh
$ sudo ufw allow 80/tcp

公開鍵の設定


~/.ssh/authorized_keys に使用したい公開鍵を設置し、パーミッションを適切に設定します。

~$ mkdir .ssh
~$ chmod 700 .ssh
~$ emacs .ssh/authorized_keys  (<- ここで公開鍵をコピペ)

sshd_configの編集


rootでのログイン、パスワード認証でのssh接続を無効にしたいので/etc/ssh/sshd_configの以下の箇所を変更します。

PermitRootLogin yes --> PermitRootLogin no
PasswordAuthentication yes --> PaswordAUthentication no

ついでにX11フォワーディングも無効にしておきます。

X11Forwarding yes --> X11Forwarding no

そして再起動して設定を反映させます。

$ sudo service ssh restart


SSHクライアントから公開鍵でログインできること、パスワード認証ではログインできないこと等を確認し、設定完了です。

その他必要そうなものを入れる


$ sudo apt-get install mysql-server
$ sudo apt-get install apache2


2013年1月20日日曜日

Tera Term上でemacsを開いたときに、Ctrl + @ を使用したい

Tera Termでサーバー上のemacsを起動して作業をする必要があったのですが、数行プログラムを書いて、Ctrl + @でマークセットができないことがわかりました。
Ctrl + SpaceはIMEのon/offに割り当てているので、なんとしてもctrl+@でマークをセットしたい…。
調べたところ、Tera Termをインストールしたフォルダのkeyborad.cnfに下記を追加するだけでOKでした。



[User keys]
User1=1050,0,$00

1050となっている数字はctrl + @を押した時の(私の環境下での)キーコードです。使用する際は、Tera Termをインストールしたフォルダにあるkeycode.exeを使用してctrl + @のキーコードを調べて、置き換えてください。

$00というのはCtrl + @のアスキーコードです。

これで無事にemacsで開発できます。

2012年11月9日金曜日

DeNA一次面接のグループディスカッション受けてきました

夏は某社のインターンに参加していたため、ブログを書くことができませんでしたが、気づけばもう就活本番の時期です。

以前の記事でインターンの際の一次面接を書かせていただきましたが、今回はそのリベンジ?ということで新卒採用の一次面接を受けてきました。

インターンの選考を受けている人は、以前通ったステップに関しては免除されるようです。
僕の場合はWebテストを通って一次面接で落ちたので、今回も一次面接から。
知り合いの話を聞いていると、二次で落ちた人は二次から、三次で落ちた人は三次からスタートのようです。

で、面接の内容ですが、インターンの時とまったく一緒。
以前の記事とかぶりますが、一応詳しい流れを書いておきます。

オフィスに到着すると、空いている椅子で待っているように指示されます。
他の就活生としゃべりながら待っていると、社員さんが来て奥の部屋に通してもらえます。
そこでは、履歴書の間違い・変更点の修正と、アンケートの記入を行いました。インターンの時はこの場所でビデオを流された気がするのですが、今回はそういうのはなかったですね。

集まったのは15人弱。4~5人で構成されるグループを作り、面接の部屋に移動するまでの間、グループの人と話て仲良くなる時間があります。
ちなみに、服装は全員スーツでした。

しばらくして、小さな会議室に移動し、面接スタートです。
流れは本当にインターンの時と同じで、
  1. 自己紹介(名前、大学、学生時代頑張ったこと)
  2. ディスカッション1
  3. ディスカッション2
  4. 自己PR(テーマ:今まで経験した中で一番の困難)
  5. 質問タイム
という流れでした。自己紹介、自己PRはそれぞれ30秒ずつと言われた気がしますが、他の人を見ていると守っている人が少なかったです。

ディスカッションについて補足します。
1つ目のディスカッションは、「直前の発言を否定し、かつ新しい案を出す」というディスカッション。テーマは「○○の売上を1年間で1.5倍にするには?」というものでした。
○○に入る店の名前(飲食店が多い?)は、その場で就活生に聞いて決めるパターンが多いようです。(前回も今回もそうでした)
また、「1年間」や「1.5倍」という数字は多少変動があるようですが、全然違うテーマが出たという話は聞いたことがありません。(が、今後はどうかは知りません)
だらだら書きすぎたので、ルールをまとめると、
  • テーマは「○○(飲食店)の売り上げを1年間で1.5倍にするための手段は?」
  • 発言は挙手制
  • 発言の際は、直前の発言者の意見を否定し、なおかつ新しい案を提示しないといけない
という感じになります。

これが10~15分程度続いたでしょうか…。その後、ディスカッション2に移ります。
このディスカッションも以前の記事に書いたものとまったく同じで、「私は最近映画を見に行っていない」、「私はビールを飲むことができない」など、面接官に関する情報が与えられるので、この理由を推測するというもの。ただし、3回だけYes/No型の質問を面接官に投げることができ、持ち時間は10分。
10分間ののち、グループで結論を出した後は、答え合わせ。
その後、それぞれの人に別々の質問が飛んできました。もう一度ディスカッションをやり直せるとしたら、今と同じ方法で議論を進めますか?などです。

この後、2つ目のディスカッションに関する小さなフィードバックがありました。

いわゆる「自己分析」なことを毛嫌いしてまったく行わなかったので、自己紹介や自己PRですら話すネタがなくてあたふたしてたので、たぶん落ちました。ディスカッションでも切れのある意見が言えたとも思わないですし…。
他の人を見ていると、自己紹介になった瞬間に暗記していた文章を読んでいるかのようにスイッチが切り替わった人などもいました。そこまですることはないと思いますが、ある程度しゃべれるネタを考えておくことは必要なんでしょうね。

結果については良ければ書きます。良ければ。

2012年7月24日火曜日

LaTeXで表と本文の間のマージンのサイズを指定したい

figureやtableを [h] を使って、ソースに記入したそのままの場所に挿入した場合は \intextsep にて設定されている。
\begin{document}の前あたりに、下の行を追加すれば調整できるようになりました。

\setlength{\intextsep}{30pt}

2012年7月14日土曜日

Reading Text on a Smart Phone: Scrolling vs. Paging: Toward Designing Effective Electronic Manuals [Fukaya et al., 2011]

Reading Text on a Smart Phone: Scrolling vs. Paging: Toward Designing Effective Electronic Manuals [Fukaya et al., 2011] を読みました。
International Conference on User Science and Engineering (i-USEr) っていうカンファレンスの論文らしいんですが、このカンファレンスは聞いた事無いです。
2011年で第2回目という、新しい学会のようですね。

PCのモニタではスクロールレイアウト vs. ページレイアウトのどっちがいいの?という研究が数多くなされていますが、スマホを対象にした研究はまだそれほどなされていないので、そこにフォーカスした論文です。

1. Introduction

  • スクロールレイアウト/ページレイアウトに関する既存研究はPCのモニタに関するものが多いが、スマートフォンでテキストを読む場合はどうなのか
  • レシピやマニュアルなどの手続き的なテキストにはスクロールとページのどちらが適しているのか?
    • 手続き的な文書はWeb上ではありふれていて、スマホのようなデバイス上でより読まれるようになるだろう
  • 研究の目的は、スマホ上でのスクロールやページレイアウトがテキストの理解力、パフォーマンス、メンタルロードワークにどのように影響を与えるかを調査すること
  • 2つのタスクを用意
    • 記憶力タスク
    • 操作タスク
2. Experiment
  • 被験者
    • 12人の日本人(男性8人女性4人で、平均年齢35.3歳)
    • 5人はスマートフォンをほとんど使ったことがないが、7人は使い慣れている
  • 装置
    • タッチパネル式デバイスとしてiPod Touch 4Gを使用
    • テキストの表示には、スクロール式とページ式の場合にそれぞれDocument Reader と Perfect Reader Mini というアプリを使用)
    • 操作タスクでは19インチのモニタも同時に使用(後述)
  • Materials
    • 2つのタイプのテキストを使用
      • 物語
      • 手続き的なテキスト
    • 物語は1500字程度のものを4種類用意
    • 手続き的なテキストは6ステップからなるものを5つ用意
    • どちらのタイプのテキストも、スクロール式のものとページ式のものを両方用意した
  • 記憶力タスク
    • 物語を読んでもらった後に、10個の穴埋め式の設問に回答してもらう。
    • テキストの位置が記憶力に影響するかどうかを見るために、半分の設問はテキストの端(最初と最後の3行)の部分に関する設問にした
  • 操作タスク
    • iPodでマニュアルを読んでもらいながら、仮想コンソールをPCで操作してもらう
    • 操作ミスがあったら、正しく操作できるまでやり直し
  • ワークロードの評価
    • スクロール式、ページ式の双方で操作タスクを終えたあとに、NASA-TLXを用いてワークロードを評価した
  • 実験手順
    • 実験を行う前に、5分間スクロールやページめくりの練習
    • 仮想コンソールの操作の練習も7分間行う
    • ページめくりは横方向に指をスライドさせるが、スクロールは縦方向に指をスライドさせて行う
    • 記憶力タスク --> 操作タスク の順で行う
    • スクロール式とページ式を両方つかてもらうが、どちらを先に使うかは被験者を半々に分けてバイアスがかかるのを避けた
    • 操作タスク終了後、NASA-TLXを使ってワークロードを評価
3. Results
  • 一番好まれた操作方法は、物語・手続き的テキストの双方でスクロールであった
  • 記憶力タスクの結果
    • 回答の平均スコアは、ページレイアウトで読んだ場合のほうがわずかに高かった(統計的有意差あり)
    • 回答のある位置(テキストの端か中央部分か)に関してはスクロールの場合は統計的有意差はなかったが、ページの場合は有意差があった(中心部のほうがスコアが高い)
  • 操作タスクの結果
    • 仮想コンソールの操作に要した時間に有意差はなかった
    • スクロールを好む人と、ページを好む人を別々に考える
      • スクロールを好む人は、スクロールで読んでいる場合のほうがページで読んでいる場合よりも操作時間が有意に短くなっていた
      • 一方ページを好む人の場合は、ページで読んでいる場合のほうが操作時間は少し短くなっているものの、統計的に有意な差はなかった
    • 操作ミスの回数に有意差はなかった
  • メンタルワークロード
    • Mental workloadに関してはスクロールの方がかなり少なかった
    • Temporal workload, performance, effort, frustrationについてもスクロールのほうが低いスコアだった
    • Physical workloadに関してはほとんど差がなかった
4. Discussion
  • 物語に関しては理解力はページレイアウトで読んでいる場合のほうが高い
    • PCモニタの場合と同じ結果
  • 手続き的なテキストに関しては、操作ミスの回数や操作時間に差はなかったものの、スクロールを好む人だけに注目すると、スクロールレイアウトの場合に短い時間で操作を終えていた
  • メンタルワークロードは、全体的にスクロールの方が低い
  • PCモニタの場合だけでなくスマートフォンにおいても、ページレイアウトのほうが読解には向いているのではないか
  • スマホユーザにとっては、手続き的なテキストに関してはスクロールの方が効率良く読めるのではないか
5. Conclusion
  • 教科書などの記憶力を要するテキストの場合は、ページレイアウトを使ったほうが良い
  • マニュアル、レシピ、how-to本などはスクロールレイアウトのほうが、スマホに慣れ親しんでいるユーザにとっては効率良く読める