読者です 読者をやめる 読者になる 読者になる

大学プロジェクトメンバーに残す「今後やってほしいこと」

2年の頃からアルバイトとして大学でいろいろなWebシステムの開発を行っていましたが、卒業が近づくにつれ終わりが近づきつつあります。

自分は居なくなりますが、後輩は(おそらく)今後も各種システムの開発を引き継ぐことになると思います。

せっかくなので、自分がやろうと思ってできなかったことや、絶対にやっておいたほうが良いと思ったことなどをまとめてみました。

といっても私が思ったことでしかないので、特に従わなければだめとか、従ってないと悲しいとか、そういうことは全くないです。

というか、あの現場にいるよりもっと成長できる現場に行けるのであればやめてしまっても全く問題ないとすら思っています。

デザインパターンの習得

共同でコーディングを行う上で、デザインパターンの習得は非常に重要だと考えています。

というのも、デザインパターンは知っている人たちからすれば「共通の設計方針」になるからです。

例えばこのシステムにおけるモデルはActiveRecordパターンを使う、などというだけで、設計方針を 明確に伝えることができるようになります。

メンバー全員が共通の認識を持つことで、チグハグな実装になる可能性を排除することができます。

例えば、アレにおけるmakeUserメソッドはFactoryパターンです。採用理由はコンストラクタで例外を投げないようにするためです。

関数型言語(の考え方)の習得

関数型言語といえば数学的というイメージがあり、圏論、ラムダ計算、(Haskellの)モナドなど、難しいイメージがあるのではないかと思います。

私もそうですが、今後この仕事でご飯を食べていくためにもしっかり圏論から学ばなければならないなと薄々感づいています。

ただ、別にそこまで理解しなくとも関数型言語のエッセンスを理解することは従来通りの手続き型OOPをする上でも十分に活用できると思っています。

というのも、最近は何気なく書いているSQLJavaScriptには既に関数型のエッセンスが散りばめられているからです。

高階関数、イミュータブル(不変)性のメリットなどについて調べることで、データの加工処理においてよりスマートなコードが書けるようになると思います。

例えば、アレのUI生成ではJavaScriptのmapメソッドを用いていますが、あれも関数型の考え方に近いものがあると思っています。

環境の改善

ただただ仕事としてやるだけじゃなく、コードを書く上で効率的な手法やモダン(近頃流行っている)な手法について自ら調べ試してみることで 例えそれがうまくいかなくとも良い経験になると考えています。

個人的にCI(継続的インテグレーション)とかしっかりしたユニットテストやりたかった。

普段何気なく使っているGitLabですが、せっかく多機能なシステムなのに殆どの機能を活用できていません。

また、いちいちテストサーバにデプロイする作業も無駄です。Hookなどの機能を活用してテストサーバに自動的にデプロイされる環境を作ったほうが良いでしょう。

例えば、アレは比較的大規模なシステムなのにもかかわらず、ユニットテストがしっかりと組まれておらずテストの自動化ができていません。テストが自動化できないことでデグレード(改善したつもりがバグになる)が発生する危険性が増し、「触らぬ神に祟りなし」状態となってコードのリファクタリングもしにくい状況です。

スケジュールとメンバー次第ですが、テストドリブン(機能実装より先にテストコードを書く)な開発を行っても良いと考えています。

「書いたら書きっぱなし」をやめる

環境の改善と重複しますが、一度書いたコードは問題が起きるまでいじらない、という考え方はやめたほうが良いと考えています。

といっても状況によるのですが、コーディング規約を無視してとりあえず動くようなコードを書いて、それを「問題がないから」と放置するのはその後の保守を考えると絶対にやめたほうが良いでしょう。

自分の書いたコードは他の開発メンバーが読む、ということを常に意識してコードを書くよう心がけ、例え荒削りなコードを書いたとしても後々しっかりリファクタリングすることで、その後の開発が随分楽になるのではないかと思います、

ちなみに就活をしていた時の経験として、コードを書くときに面接官の方はそういったところをかなり注目して見ています。

仕事においては複数人での開発が当たり前になるので、他人が読むことを考慮したコードを書くことはとても重要です。何せ自分たちは頭キレキレでバリバリなコードを書く理系大学生ではないのですから、そういう部分でアドバンテージを発揮するしかないように思います。

例えば、アレについて私は問題ない部分や変数の初期化方法など本当にどうでもいい部分を結構変更したりしていましたが、コードの統一性を図り後々メンテナンスする時に楽になればいいな、と考えていたためです。(とはいえテストがしっかり組まれていないのでかなり危険な橋を渡っていたことは否定できない)

検索スキルをつける

何か問題にぶち当たったらとにかく検索しましょう。自分がぶち当たった壁は99%くらいの確率で他の誰かも経験しています。

あと、英語で検索してみるのも良いかもしれません。どうせこの分野での英語なんて大して難しい言葉は使われていませんし、最悪Web翻訳をかけて読むことだってできます。

例えば、55円事件のアレでは英語で検索したことで本番環境での不具合の原因がSAMBAのバグであることを特定することができました。

最後に

グダグダと書いてきましたが、とにかく興味を持つことを忘れないのが大事だと思います。好奇心を大切にしてください。 自分からいろいろな情報を集めて試してみるのは良いことです。少なくとも、学生なら少しくらい失敗しても大丈夫です。

あと、偉そうなこと言ってますが、私は仲間とともにもっともっといろいろ磨いていきたいなと考えているだけの本当に大したことのない人間です。あんまり当てにしないほうが良いと思いますし、もっと立派な人はいます。

っていうか、大体の場合において、こういうことをグダグダ言っている人は無能です。本当に有能な人は黙々と自分の道を進んでいます。そういう人から学べる環境に行きたいなと常々思います。

XperiaのOSSアーカイブ読み 2017/01/20

いつも通り適当にRSSTwitterに流れてくるサイトを巡回してたら,気になる記事を見つけた。

androplus.org

未発表のスマートフォンの画像がリークするのはいつも通りすぎて特に言うことはないのだけれど,気になったのはこの部分

また、Sonyのデータベースから、現在開発中のプラットフォーム名も判明しました。 一つは「BlancBright」、もう一つは「Yoshino」です。

Sony Mobileのスマートフォンには基本的に開発コードネームとプラットフォーム名がつけられている(例えば,Xperia Zなら開発コードネームYugaでプラットフォームがLagan(Qualcomm APQ8064 + Qualcomm MDM9215M)のだけれど,新しいプラットフォーム名が判明しているそう。

どうせいつも通りQualcommのSoCだろうし,最新のXperiaオープンソースアーカイブ見てみたら何か書いてるかも,と久々にXperia X Performance / XZの39.2.A.0.386をダウンロードして探してみた。

すると,ごく僅かに,断片的にだけれどもMakefile中にYoshinoに関する記載があった。

# vendor/semc/external/fips/kscl/Android.mk Line 16 ~ 26

ifneq ($(filter N 7.0, $(PLATFORM_VERSION)),)
  ifeq ($(strip $(SOMC_PLATFORM)),tone)
    TARGET_KERNEL_SOURCE := kernel/msm-3.18
  else ifeq ($(strip $(SOMC_PLATFORM)),yoshino)
    TARGET_KERNEL_SOURCE := kernel/msm-4.4
  else
    TARGET_KERNEL_SOURCE := kernel
  endif
else
  TARGET_KERNEL_SOURCE := kernel
endif

どうやら変数SOMC_PLATFORMyoshinoならカーネルソースとしてkernel/msm-4.4を使用するそう。

ここで出て来る特殊な用語(?)としては

  • SOMC : SOny Mobile Communications,昔はSEMC(Sony Ericsson Mobile Communications)だった。
  • msm : MSM(Mobile Station Modem,要はQualcomm Snapdragonのこと。
  • msm-3.18, msm-4.4 : msmにおけるターゲットLinuxカーネルバージョン。ここにあります。

ただし,39.2.A.0.386にはkernel/msm-4.4が含まれない為,わかったのはこれだけだった。

わかったこととしては

  • YoshinoプラットフォームはQualcommチップセットである。
  • Yoshinoプラットフォームはmsm-4.4ベースである。
  • YoshinoプラットフォームはLinux Kernel 4.4ベースになる。

ということくらい。

BlancBrightの名前は見つからなかった。たぶんMediaTekチップセットなんじゃないかと思う。そういやMediaTek Helio P20採用の機種の情報が漏れてましたね。

あと,Qualcommチップセットに元素名のコードネームをつけてるみたい。ちょっと適当にソースを眺めてみた感じだとこんな感じかな...間違ってるかもしれない。

  • msmcopper => MSM8974 (Snapdragon 800)
  • msmgold => MSM8917 (Snapdragon 425)
  • msmtitanium => MSM8953 (Snapdragon 625)
  • msmferrum => MSM8909 (Snapdragon 210)
  • msmplutonium => MSM8994 (Snapdragon 810)
  • msmtellurium => MSM8952 (Snapdragon 617)
  • msmthorium => MSM8937 (Snapdragon 430)
  • msmzinc => APQ8084 (Snapdragon 805)
  • msmcobalt => MSM8998 (Snapdragon 835)

夜フクロウを改造したら起動の度にログインを求められるようになった話

の、対策方法をQiitaに書きました。

qiita.com

夜フクロウがMacのdGPUを叩き起こす問題とユーザー側での対応方法

電池がモリモリ減るよ

前述の通り、初めてdGPU(ディスクリートGPU)つきのMacを買った。

今まではiGPUしかなかったから何も考える必要はなかったのだけれど、dGPU搭載ということで 必要のない時にはiGPUを使用することで電力消費を抑えることを考える必要が出てきた。

特に何も考えず数時間使っていたのだけれども、明らかに電池の消費が早すぎる。

で、現在使用しているグラフィックスの種類を表示するアプリであるgfxCardStatusを入れてみた。

GitHub - steveschow/gfxCardStatus: This is a fork of gfxCardStatus, this fork will handle integrated-only mode a little better

(正確にはフォーク版だけど)

すると、やっぱりというか、案の定というか、バッテリ駆動時だろうとなんだろうと常にdGPUが使われてることがわかった。

原因

gfxCardStatusには何が原因でiGPUに切り替えられないのかを表示してくれる便利な機能がある。 というわけで何が原因か調べてみると、どうやらNight Owlというアプリが原因でdGPUが叩き起こされているらしい。

Night Owl => 夜フクロウ

Night Owlはその名の通り夜フクロウのことで、非常に使いやすいTwitterクライアント。ほんとに使いやすい。Windowsにもこういうのほしいなと切実に思う。

sites.google.com

が、これが原因で常にdGPUが叩き起こされている。どうやらTwitterをするためにはクアッドコアCPUだけではなくディスクリートグラフィックスも必要らしい。TwitterのためにXeonのPCを組む人の気持ちが... わかるわけがない。

原因を探ってみると、どうやら夜フクロウ側でGPUの自動切り替えに対応している旨の宣言をしていないのが原因のようだった。

無理やり改造して対応させる

対応してないならさせればいい。

Mac App Storeから落とした場合はそれ関係の情報が付加されるので、うまくいじれない可能性やアップデートで崩壊する可能性を考慮して公式サイトで配布されているバージョンを落としてきて改造した。

夜フクロウオープンソースじゃない。けれどもWindowsと同じようにマニフェストファイルは自由に書き換えられる。

しかもMacのアプリケーションは.appというディレクトリ名を持つ単純なディレクトリなので、以下のようにして簡単にマニフェストファイルにアクセスできる。

$ cd Night\ Owl.app/
$ open Contents/Info.plist

で、GPU自動切り替えに対応していると嘘をつくために、マニフェストファイル(Info.plist)を以下のように書き換えた。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>BuildMachineOSBuild</key>
    <string>15G31</string>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>NSSupportsAutomaticGraphicsSwitching</key>
    <true/>
〜以下省略〜

あとは起動するだけ。成功した。

その他

本当に宣言するだけでなんの問題もなく使えてしまっているので、公式に対応していただければ...

Mac買った

1年以上前から次のMacBook Proが出たら買うと決めていたのだけれども、まさか1年以上も待つ羽目になるとは思わなかった。

とりあえず買ったので予備録代わりにやったことをメモ

構成

今思えばストレージケチりすぎたと思うけど、今更どうしようもない。 13-inch, Late 2016, Two-Thunderbolt 3 PortsプロプライエタリSSDとはいえ交換可能だったから完全に油断していた。

やったこと

AppStoreでソフト導入

mas-cliとか使えよと思われるかもしれないけど、そんなにAppStoreのアプリ入れることがないし...

  • BetterSnapTool (ウィンドウスナップ, 後述するBTTのライセンス通すのにも使う)
  • 夜フクロウ (Twitterクライアント)

BetterSnapTool

BetterSnapTool

  • Andreas Hegenberg
  • 仕事効率化
  • ¥360

Homebrewの導入

そもそも開発を楽にするためにMacを買ったのでこれをやらないと何も始まらない。

brew.sh

各種Formulaの導入

必要なものをすべて入れていく

  • PHP 7.0 (いつもクソ言語と言われているかわいそうな子)
  • Composer (PHP Package Manager)
  • Composer Completion (Composerの補完)

開発用のmacにはまだいろいろ入れてるはずだけどもうカオスなので一切忘れて新たに環境を作ろうと思う。 絶対足りないけど、必要になったらその都度入れていく。

ComposerでLaravel Valetの導入

github.com

LaravelというPHPフレームワークでの開発を補助してくれるすごいやつ

とりあえず入れてパスを通してインストール

$ composer global require laravel/valet
$ cd ~
$ sudo echo 'export PATH=$PATH:$HOME/.composer/vendor/bin' >> .bash_profile
$ source ~/.bash_profile
$ valet install

あとは開発用ディレクトリに移動して

$ valet park

でおわり

Homebrew Caskの導入

https://caskroom.github.iocaskroom.github.io

Homebrew Cask(HomebrewでMac用アプリケーションを管理できるようにしてくれる便利なやつ)を入れる。 とは言えコマンドを叩くだけ

$ brew cask

おわり

Homebrew Caskでいろいろ入れる

$ brew cask install bettertouchtool
$ brew cask install google-japanese-ime
$ brew cask install google-chrome
$ brew cask install firefox
$ brew cask install intellij-idea
$ brew cask install phpstorm
$ brew cask install iterm2
$ brew cask install skype

BetterTouchToolの設定

起動して、アクセシビリティ権限与えて、BetterSnapToolでライセンス認証通して完了。

マルチタッチトラックパッドが使えるmacを使うのは初めてなので、とりあえず3本指クリックで中央クリックだけ設定した。 タブとか閉じられて便利。

システムの設定

キーリピート発動までの時間が長すぎるので短くした。 その他、三本指でのドラッグを有効に。なんか動かないとか言われてるけど、自分の環境だと今のところ問題ない感じ。

その他

Parallels Desktop入れたり、Dockのいらないアイコン削除したり、Microsoft Office入れたり... とくにメモする必要もなさそうなこと。

使ってみて思ったこと

  • マルチタッチトラックパッドは便利。
  • 感圧トラックパッドは極稀に思ったように反応しない。これは感圧トラックパッドなMac全部に共通してるので仕方ない気もする。
  • キーボードは全然悪くない (5576-A01, 5576-C01, ALPS Bigfoot, Apple Extended Keyboardとか名機と呼ばれるキーボードをいろいろ使ってきたけど、普通に良いと思う)
  • スピーカーの音は良い (けど、そんなに役に立つだろうか)
  • TouchBarは特に問題なくて逆にびっくりした (物理ボタンではないけど違和感なくEscも押せる)
  • TouchBarの有機ELの焼付きが怖い (だから有機ELスマホやゲーム機も苦手, 精神衛生上よろしくない)

はてなブログに思ったこと

  • 昔使ってあまりの使いづらさに絶対使うかって思ってたんだけど、すごく便利になっててびっくりした。Markdownも使えるし。