Kikuchy's Second Memory

つくる楽しさをもっと伝えたい。プログラムを書いていて、わからなかったこと・気付いた事を書き留めています。

GPD WinにXubuntuを入れてコーディングする

以前
GPD Winで通勤中にコーディングしたいという記事を書いたのですが、
やっぱりWindows (bash on Ubuntu on Windows)での運用は辛かったのでLinuxに乗り換えることにしました。



何が辛かったのか


satさんが性能比較をしてくださっているとおり、ファイル入出力が遅いのが一番つらいです。

qiita.com


コンソールでvimを使ってスクリプトを書いて…というのがメインだったのですが、
ファイルを開くのも10秒くらい待たされ、保存でも数十秒待たされ、
という感じだったので流石に我慢できなくなって乗り換えを決意しました。

どのLinuxディストリビューションを使おうか

GDP Winは非力なUMPCです。
でもサクサク動いて欲しい。

開発のために色々とプログラムを動かすため、OSなど常駐プログラムがたくさんメモリを食ったりするのは許せません。

そこで、ウィンドウマネージャにXfceを使えばまあ軽量だろう、という安直な考えで、まずはXubuntuを導入することにしました。

じつはその前にManjaro Linuxという、Arch Linuxベースのディストリを導入しようとしたのですが、どうしてもWifiが繋がらずにあきらめてしまいました。
またLinuxの知識がついたり、Debian系で満足できなくなったら、いつかArch系にも挑戦してみたいと思います。
GentooはCPUが非力なのでちょっと…

XubuntuをGPD Winに入れる障壁


GPD Winはそこそこ特殊な端末で、普通にXubuntuを入れようと思っても期待通りに動いてくれません。

  • 画面が横になってしまう
  • Wifiがつながらない
  • 電源ボタンを押しても反応しない

など、いくつかの不具合がコミュニティに報告されています。

その不具合報告をベースに有志の方々がカスタムディストリを作る方法を公開してくださっているので、それを参考にXubuntuをカスタムしました。


カスタム方法はこちらのページを参考にさせていただきました。

[GPD Pocket]GPDPocket向けにUbuntu系ディストリビューションをリビルドできるツール – BOOLEE STREET.net

上記はGPD Pocket向けですが、GPD Winも使用しているWifiモジュールが同じものだったりするので、問題なく使用できています。


当方、母艦はMacなので、まずはXubuntuをインストールした仮想マシンを用意します。
今回はVirtual Boxで作成。

作成した仮想マシン内でrespinしていきます。

$ sudo apt install -y git wget genisoimage bc squashfs-tools xorriso libssl-devel dpkg-dev
$ git clone https://github.com/stockmind/gpd-pocket-ubuntu-respin.git
$ cd gpd-pocket-ubuntu-respin
$ wget (どこか近いところからXubuntu17.04のisoを落としてくる)
$ ./build.sh xubuntu-17.04-desktop-amd64.iso 

仮想マシンだったのもあって時間はかかりました。確か3時間くらい。

あとは適当な方法で出来上がったISOファイルをUSBメモリに焼けば準備完了。

焼きあがったUSBメモリをGPD Winに挿して、Boot MenuをいじってUSBから起動、指示に従ってインストールするだけ!!

今回はWindowsを残さず、全部フォーマットしてLinux向けにパーティショニングをやり直しました。

これで完成。
後はDPIやマウスカーソル速度などを調整して出来上がりです!


出来上がりはこちら。
実機で動いている様子を撮りたかったので画面は見づらいですが、ご勘弁を!

f:id:kikuchy:20171003235513j:plain


IntelliJも動きます。
時々補完の表示が遅いかなと感じる程度で、Kotlinのプログラムもバッチリ書いて動かせます。
問題だったvimもストレスなく動作します。
zshも問題ない速度で補完してくれるので、普段使いにも支障ありません。
これで通勤中もコードを書ける!

さて、何を書こうかな。

感情処理のはなし

エンジニアは情報処理が得意だったりしますが、人間として生きていると感情処理もしていかないといけません。

 

 

 

昔から他人にネガティブな感情を向けるのが苦手です。

 

そりゃ、そんな感情を他人に向けないに越したことはないのでしょうが、それを差し置いても苦手です。

どうしても怒らないといけない時があるかも知れません。

そんなときも怒れる気がしないのです。

たぶん、ははは仕方ないよ、と言うのが精一杯だと思うのです。

 

自分の中だけで感情が暴れていて外にエネルギーが出ていかないので、なんとなく自分が磨り減っているのでは、という感覚はあります。

しかしそれを避けたいという気持ち以上に、他人にネガティブな気持ちを向けた結果、自分にネガティブな感情を突きつけ返されるのが怖いのです。

 

要は意気地無しということなのですが。

 

多分、感情をぶつけ合って、その末に仲直りするのがベストなのでしょう。

ところが仲を直す方法がわかりません。

 

きょうだい喧嘩などは昔よくしましたが、お互いその感情が一過性のものであることはわかっていたので、何をせずとも仲は良くなっていました。

きょうだいほどよく理解できていない人に対しても、それを求めて良いのでしょうか。

 

もしくは感情のぶつけ合いの末に決裂することもあるかも知れません。

そうなるなら、それまでの相手だったと割り切ってしまうのが良いのかも知れませんが、それによって自分の立場が悪くなるようだと、それはそれで別の恐ろしさがあります。

 

自分の中で暴れ続けるエネルギーをどうしたら良いのか、

この意気地無しをどう正せばいいのか、

今抱えているこの感情をどう処理したら良いのか、

未だにわかっていません。

GPD Winで通勤中にコーディングしたい

GPD Winが安くなっていたので衝動的に買ってしまいました。

この端末は元々ゲーム用ですが、何と言ってもボタン式キーボードがついているのが魅力。
日本の通勤電車の中でも使用できる、学生/サラリーマンの味方です。
パンタグラフ式キーボードは、立っているときに両手で使用できないので却下)

普段は家でも会社でもMacを使っていて、コードを書く場合もVimスクリプトを書くか、IntelliJJavaを書くか、という使い方をしています。
GPD WinにはWindows 10 Homeが入っているので、とりあえずBash on Ubuntu on Windowsで運用して遊んで見ることにしました。
気に食わなかったら適当にLinuxのディストリを見繕って入れるつもり。

Windowsで快適に過ごす環境を整える

Zeal

Macでは言語やライブラリのマニュアルを引くのにDashを使っています。

Windowsでも使える同じようなZealというものがあるようなので、これを使ってドキュメントを引くことにします。

Zeal - Offline Documentation Browser

フォント

SourceCode Pro for Powerlineを入れます。
Vimでlightlineを使っているので、対応したフォントを使えるのは嬉しい。

github.com

ランチャーは検討中

MacではAlfredを使っていてDashもそこから引けるようにしているので、できれば同じようなことをしたいところ。
アプリケーションランチャーとしてはスタートメニューだけで事足りるのですが、Zealを引くことのできるランチャーが果たしてあるのかはまだわかりません。


Linux環境を整える

Creators Updateを入れる

Creators UpdateからUbuntuが16.04になったらしいので、新しいものは良い、の精神で放り込みます。

放り込んだらば、WifiSSIDを認識しても接続ができない、という状態に陥ったので、Wifi Patchをあてます。

www65.atwiki.jp


あとは Bash on Ubuntu on Windows をインストールして、bashをぺちぺち叩いていきます。

git, gcc, zsh

何がなくともgitもgccもないと何もできません。
clangではないのは、この世にはgccじゃないとビルドできないものがまだまだたくさんあるから…

zshの保管機能が優秀すぎてそれなしでは生きていけない体になってしまったのでzshも入れます。

$ sudo apt install git build-essential zsh

vim

aptにはまだvim 8が来ていないので、有志が作ってくれたppaを使います。
tipsonubuntu.com

普通に install vim するとluaだとかが有効にならずneocompleteが使えないので、gnome全部込みのやつを放り込みます。

$ sudo apt install vim-gnome

dotfile

私は個人用のdotfileをgithubで管理しているので、gitもvimも入ったところでおもむろに放り込みます。

github.com


そしてvimを起動したらプラグイン類をインストール。

:call dein#install()

もしかしたら先にX Server入れておかないと、githubのユーザー名とか聞かれたときに動かなくなるかも?
githubのユーザーIDとかを聞かれて、プロンプトに入力できずタイムアウトで死んだ)

anyenvとphpenv

今書きたいプログラムはPHPなので、phpenvを入れておきます。
phpのビルドにはなんだかんだたくさんパッケージが必要なので、この際全部放り込んでおきます。

インストールはこちらを参考にしました。
qiita.com

PHP7.1.6ではbisonは最新でも問題なかったです。
あと、このままではビルドが通らなかったので、いくつかパッケージを足しました。

$sudo apt install libssl-dev libmcrypt-dev libreadline-dev libxslt1-dev libxml2-dev libbz2-dev libcurl4-openssl-dev libpng-dev libjpeg-dev libmcrypt-dev libsqlite-dev libtidy-dev libltdl-dev make autoconf automake re2c lemon libsasl2-dev pkg-config bison

Windows環境とLinux環境を上手く両立させる

WSL Terminal

流石に標準のcmd.exeではフォントとか選択肢が狭すぎるしコピペもままならないのがつらすぎるので、WindowsSSHしたりmingw使ったりしてたときに使ってたminttyを使いたいところ。

あと、Explorerで開いているディレクトリをbashでも開きたいときが多分出てくるので、そこも対策したい。
カレントディレクトリからbashを起動できるようにしてくれるWSL Terminalなるものがあるということなので、とりあえずこれを使ってみることにしました。

github.com


etc/wsl-terminal.conf にシェルを指定できる項目があるので、bashからzshに書き換えておきました。

X Server

gvimを使いたくなることもある気がするので、VcXsrvを入れてスタートアップで起動するようにしておきます。
あとはprofileの方にもDISPLAY環境変数を設定しておきます。
sourceforge.net

export DISPLAY=localhost:0.0

今のままだとgvimのメニューなど日本語部分が文字化けするので、Windowsで使えるフォントを放り込んでフォントキャッシュを再作成します。
こちらを参考に行いました。
d.hatena.ne.jp


これで無事にgvimも使えるようになりました。
WindowsデスクトップにUbuntuのウィンドウが出てるってなんだか新鮮。

現在の感想

CPUがAtomなので、非力さは否めない感じ。
コンパイルとかとても時間がかかるので、もしできることなら別のマシンでクロスコンパイルしたものを持って来たい気分になる。

キーボードは全体的に端末の左側寄りに配置されているので、右手はいつも突っ張った感じになる。
ホームポジションにポッチがあるのでタイピングはそこそこしやすい。
WindowsではAlt + F4をよく使うけれども、Function類はFn + 数字キーでの入力なので、とても入力できない。せめてAltとFnが隣同士になっていてくれれば良いのだけれど…

ジョイパッドはそこそこよい操作感。
細かいマウス操作は慣れが必要。
スクロールは上下しかできないので、左右にもできたらもっと嬉しかった。

画面がタッチパネルなのは嬉しい。
ブラウザで前のページに戻るときや、いちいちマウスカーソルを移動させるには遠かったりするときに、指で操作しちゃうと便利。
というか日々スマホを使っていると「手持ち端末の画面は触るもの」という意識になっているので自然と触ってしまうので、触れるのは嬉しい。

しばらくはこのまま運用してみたいと思います。
飽きたら…どのLinuxディストリを試そうかなぁ。

一つ、父を超えた

とてもとても技術とか関係のない話ですし、とてもしみったれた小さな話ですが、個人的に感慨深かったので忘れないように。



Google I/O 17で、KotlinがAndroidの公式開発言語になったという発表がありました。

www.publickey1.jp




早くから(それこそ1.0が出る前から)この言語は主流になると思ってプロダクトに取り入れる活動などをしていたので、実際に主流になったというのは感慨深いものがあります。


さて、感慨深いと同時に、「父を超えた」ことができたと思いました。

      • -


私の個人的な考えでは、「子供は親を超えるもの」だと思っていますし、子供はそれを目指すべきだと思っています。
老いては子に従え」と言いますが、親を導くためにはそれなりの子供になっていないと、と思っているわけです。

私の父は技術者(と言ってもメカの設計が専門で、情報系のエンジニアではありませんでした)で、家電好きでもありました。
父はもう15年ほど前に他界しましたが、それまでの間、最新の家電や電子機器をいくつも(母親が許す範囲で)家に導入していたものです。

中にはいくつかの規格が覇権を争っている最中に購入したものもあります。
特に私の記憶に残っているのはこの2つです。

  • VHSとBetaが争っていたとき -> Betaのビデオデッキを購入
  • MOとCD-RWUSBメモリが争っていたとき -> MOドライブを購入

ことごとく「スペックは良いが派遣を握れなかった」ものを選んでいました。
技術者としてスペックが良いものを選ぶのは自然な思考だと思いますが、どうにもその先行きまでは見通せていなかったようでした。


父を超えた、と思うのは、覇権を争うものの中から覇権を取るものを選べたこと。

私が会社で開発していたプロダクトにKotlinを導入しようとしていたとき、Alt-Java言語としては他にも

などの候補がありました。
特にScalaは当時はKotlinより知名度が断然高く、case classなどボイラープレートを省略する文法、便利なライブラリ、強力な型システム、サーバーサイドでの利用実績が魅力的でした。

Alt-Java言語を使いたかったのは、Javaの冗長さを疎んでのことでした。


それでも「導入してしまえばこの先数年は使い続けることになる(そしてAndroid開発での主流にならなければ負債にしかならない)」という視点は大事です。
Kotlinは、Javaとは大きく変わらないけれどもとても便利になっている文法と型システムを持っていたのが「この言語は使われるようになる」と考えた決め手でした。

導入から1年近くたち、結局KotlinはAndroid開発言語の公式言語にのし上がりました。

父は技術のその先を見通せなかった(かもしれない)が、私は(少なくとも今回は)見通すことが出来た。
果てしなく小さな一歩でしたが、父を超えられたと思いました。
少なくとも父よりは大衆に認められるものを見極める力があるぞと。


まだまだ超えられない父の壁はたくさんありますが、これからも精進していきたい所存です。
これからも空の上から見守っていてくれたら、嬉しいです。

読みやすいコードとワーキングメモリ

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

3年ばかり前に『リーダブルコード』という本を図書館で借りて読んだ(ので詳細な内容を忘れてしまった)のですが、
こういった本が出版されるほどに、エンジニアは読みやすいコードを求めているのだと感じます。

コードの品質については様々な要素があります。その中に、可読性というものも入るでしょう。

可読性の高さは、コードの理解を容易にします。
コードの理解が容易であれば、変更も加えやすく、拡張もしやすくなる可能性があります。

その可読性も、いくつかの要素から成り立っているようです。

  • トークン単位 ... 命名は妥当か。値やメソッド名、クラス名から挙動などの想像がつくか。
  • 式単位 ... プリミティブな命令の単位。どのような命令なのか、見てわかるか。
  • 制御文、スコープ、メソッド単位 ... この文やスコープの意味するところは何なのかを、想像できるか。
  • クラス、モジュール、ファイル単位 ... 理解しようという気になるか。


これらすべての根底には、読者にかかる認知的負荷を低くできるかどうか、という問題が横たわっています。
認知的負荷というのは、一時記憶(ワーキングメモリ)の圧迫と言い換えられるでしょう。
要は、覚えておけるかどうか、です。

人間の一時記憶は 7±2 個のことがら(チャンク)しか貯蔵できないと言われています(マジカルナンバー・セブン)。
コードを書いている本人ならともかく、読む人はたくさんのことがらを記憶できません。

しかし、記憶できることがら(チャンク)は、意味のある一かたまりであれば、ある程度記憶がしやすくなるのです。

例えば数字列。

097153754865

これを覚えろ、と言われてもなかなか難しいかもしれません。
数字一つひとつを記憶しようとしても、12個あるわけですから、7±2 を明らかに逸脱しています。

では、こちらは?

0971 - 5375 - 4865

まだ覚えやすいですね。
例えばこれが紙に書かれた電話番号だったとして、番号を打ち込むのが少しは楽になりそうです。
一つの塊は4桁ですから、塊ごとに記憶するのは容易。
その塊も3つですから、数字を一つずつ覚えこもうとするよりかははるかに楽になります。

コードについても同じことが言えます。
なるべく、単純化・抽象化した塊で捉えることで理解が楽になるわけです。

// 昔メンテナンスしていたプロダクトでこんな感じのコードを見たことがあります
boolean ret;
if (isSucceeded(results)) {
    if (results.targets.size() > 0) {
        ret = true;
    } else {
        ret = false;
    }
} else {
    ret = false;
}
return ret;



// 変数が減れば、頭に入れておくべきことが減ります。
// 行数や制御構文が減れば、「このまとまりが何をしているのか」を少ない労力で考えられます。
return isSucceeded(results) && (results.targets.size() > 0);

ある特定の操作をメソッドに抽出する、というのも有効な手段です。

// ナイーブに実装すると
int index = -1;
for (int i = 0; i < elements.size(); i++) {
    Element e = elements.get(i);
    if (e.id != target.id && e.name.equals(target.name)) {
        index = i;
        break;
    }
}




// 特定の操作をメソッドに置き換える -> 抽象化する ということです
int index = indexOf(elements, () -> e.id != target.id && e.name.equals(target.name));
/* (ラムダ式部は、以下の省略形です)
new Predicate<Element> {
    boolean test(Element e) {
        return e.id != target.id && e.name.equals(target.name);
    }
}
*/

// 最終的な行数は増えますが、こちらのメソッドの実装は頭に入れなくても良いでしょう
// 「特定の条件を満たす要素が格納されているインデックスを探し出す」という役割だけを覚えておけばいいのですから
public boolean <T>  indexOf(List<T> list, Predicate<T> predicate) {
    for (int i = 0; i < elements.size(); i++) {
        T t = list.get(i);
        if (predicate.test(t)) {
            return i;
        }
    return -1;
}


単純なことを複雑に実現することは楽なのです。
なぜなら「実現する」という最低限がすでにできているのに、「単純化する」という+αに頭を使わなくて済むから。
書いた行数が増えれば、なんだか仕事した感じにもなりますし。

単純なことを単純に実現する
できないことではないのですが、疲れるタスクです。
書いた行数が成果とされるような(Web系でそんな職場は存在しないと信じたいですが)ところだと、マイナスに働くかも。
ですが、書いた自分がやっておけば、今後のこされたコードに触る人全員の労力を削減できます。
また、それだけ考えることができる人だと周囲も認識してくれますし、それが自信をつけることにも繋がるでしょう。

読む人に苦労をかけないコードを残していきたいものですね。