いつも応援してくださる皆様へ
いつも温かく見守ってくださる皆様、並びに関係者の皆様へ ご報告させていただきます。
この度、私、もやしきんぐは先日大学を卒業し、本日より某IT企業に就職いたします。 突然のご報告になりましたが、私自信特に変わることなく、オタク業を続けてまいります。
まだまだ未熟ではございますが、オタクとして、人間としてこれからも成長していきたく思っておりますので、どうか温かく見守っていただけると幸いです。
今後とも、オタク「もやしきんぐ」をよろしくお願いいたします。
令和2年4月1日 もやしきんぐ
なうぷれTunesV2 1.5リリースのお知らせ
お久しぶりです。約一年ぶりの更新になります。
アップデートについて
本バージョンで大幅な変更を加えた為、以前のバージョンへの上書きインストールは出来ません。
必ず別ディレクトリへのインストール(展開)をお願いします。
また、設定ファイルの互換性も失われている為、引き継ぐことが出来ません。
※ 各再生ソフトにインストールしているプラグインについては、更新の必要はありません。
リリースノート
ディスプレイごとに異なるスケーリング倍率が使われていても正しく描画するようになりました
※Windows10 1607(Creators Update)以降のみの対応
以前はシステムのスケーリング倍率でのみスケーリングされていましたが、 Per-Monitor (V2) DPI Awareness対応を入れ、スケーリング倍率が違うディスプレイにウィンドウを移動してもボケずに正しく描画されるようなりました。
.NET Core 3.0への移行をしました
.NET Core 3.0にWPFサポートが入った為、.NET Framework 4.7から.NET Core 3.0への移行作業を行いました。
C# 8.0対応に伴い大幅なコードの書き換えを行い、バグの元になりそうなコードのリファクタリングをしました。
.NET Core 3.0への移行作業に伴い、acrylic_darkテーマが正常に作動しなくなった為(正確に言うと依存ライブラリが正しく動作しなくなったため)、削除しました。
タスクバーのアイコンから簡単に再生中の曲を確認出来るようになりました
再生中の曲のアルバムアートと曲名・アルバム名・アーティスト名が簡単に確認出来るようになりました。
Windows7のサポート打ち切り
Windows7への対応は打ち切らせていただきました。来年にはマイクロソフト社によるサポートも終了するため、OSの更新をお願いします。
ダウンロード
インストールについて
.NET Core 3.0への移行に伴い、完全版とポータブル版の2つのバージョンを配布しています。
.NET Coreって何ですか？って方は普通に完全版を使ってください。
以前より大幅にファイルの数が増えていますが、今までと同じくNowPlayingV2.exeが本体です。
.NET Core 3.0のランタイムがPCに導入済みの方はポータブル版をお使い頂けます。
以下のサイトにて配布されている、.NET Core Runtimeと.NET Core Desktop Runtimeが導入済みであれば使用可能です。
あとがき(全然関係無い話なので読まなくても大丈夫です)
1.4から1.5までの間におおよそ1年ほどブランクが出来てしまい申し訳ないです。
そろそろ更新しないとマズイなって思ったので.NET Core 3.0移行をして、今後.NET 5がリリースされた際にスムーズに移行が出来るように準備をしました。
汚かったコードも少しずつリファクタリングを加え、手入れがしやすいようにしています。
時間に少し余裕が出来たので頂いた要望の機能などの実装をやっていきたいと思います。
(以下なうぷれTunesには関係ない話です)
週末に名古屋に行ってきました。最高でした。
改めましてTHE IDOLM@STER CINDERELLA GIRLS 7thLIVE TOUR Special 3chord♪ 『Funky Dancing!』
— アイドルマスター コロムビア公式 (@imas_columbia) 2019年11月10日
へご来場頂いたプロデューサーの皆様、遠くから応援してくださった皆様、ありがとうございました‼️
早いもので7thLIVE TOURも残すところ大阪公演のみとなりましたが、引き続き宜しくお願い致します🌟 pic.twitter.com/mar3SaHzB5
😭無限に感情になってる😭
アンドロメダぁ......... Last Kiss良すぎてもうね........
THE IDOLM@STER CINDERELLA GIRLS 7thLIVE TOUR Special 3chord♪Funky Dancing！2日間本当にありがとうございました！💓
— 原田 彩楓 (@sayaka_harada_) 2019年11月12日
DJ KOOさんと！！最KOO🤤✨
これからも美優さんとプロデューサーさんと一緒に、カラフルな未来を歩んでいけると信じています。
これからも美優さんらしい色で🌈 pic.twitter.com/NVvcomfu5D
😇😇😇😇😇😇😇😇😇😇
WSLとDrvFsとinotifyのMOVE_SELFの挙動の話
WSLの上で動かしているwebpack(watchしている状態)を使っていたら少し不思議な挙動に遭遇したのでメモ。
起こった現象
- DrvFS上のファイルをwebpackで監視して、変更があったらビルドするようにした
- Windows側のプロセスであるPhpStormからファイルを変更した
- WSL側から見ると全くファイルが更新されていないように見える
もうちょっと詳しく調べてみる
inotify-toolsのinotifywaitを使用するとどんな通知が飛んでくるか確認できるので、PhpStormでファイルを編集しながらどんなイベントが起こるか確認してみた。
$ inotifywait -m penlight-item.vue Setting up watches. Watches established. penlight-item.vue MOVE_SELF penlight-item.vue MODIFY penlight-item.vue ATTRIB
注目したいのはMOVE_SELFである。これは監視対象のファイルが移動されたことを意味する。
また、監視中にWSL側から対象のファイルをcatしてみてもgit diffしてみても全くファイルが更新されていないように見え、inotifywaitを終了させると終了した瞬間にファイルが更新されることも分かった。
inodeも確認してみる
ls -iでファイルのinodeが確認できるので確認してみる。
$ ls -i 70368744177769493 character-item.vue* 6473924466916263 main-view.vue* 1970324839556962 penlight-list-view.vue* 13510798882202666 character-list-view.vue* 32088147347008203 penlight-item.vue*
変更前のinodeは34902897112164784 penlight-item.vue*だったので、ファイルが移動され別のファイルがリネームされて今あるファイルになったことが分かる。
WSL特有の挙動
ファイルのinotifyイベントを監視中にWindows側から対象ファイルを移動(リネーム)し、別に作ったファイルを元のファイルの名前に変更すると、WSL側からは移動する前の段階でのファイルの中身が残ったような状態になる。
監視を終了させると、更新後のファイルの中身が見えるようになり、inodeも変化する。
IDEA系のIDEでの対処法
このままだとまともにwebpackが使えないので、何とかしたい。
safe writeを使用するオプションをオフにすることでこの現象が起こるのを回避できる。
自分にとって最初で最後のWake Up, Girls!のライブに参加してきた話
ライブからちょうど一週間ですが、どうしても書きたかったので書きました。クソみたいな文章ですが、読んでいただけると幸いです。
まえがき
- SSA公演が初めてのWUG現場でした
- 普段はアイドルマスターミリオンライブ！のPをしている者です
- 楽曲はSpotifyで聴けるものを前の週から聞き込みました
- アニメはちらっとしか観てなかったので、
うんめーにゃーぐらいしかネタが分かりません - 語彙力ありません
曲が良い
良い、良すぎる。
タチアガレ！とかは前から知ってましたが、One In A Billionが良すぎる...(他にもめっちゃ好きな曲は沢山ありますが全部紹介していると長くなって読みづらいと思いますので...)
現地で回収出来て良かったです。元のWake Up, May'n!のバージョンは配信がありませんがWUGちゃん単独の物でしたらありますので是非一度聴いてみてください。
あと、あと、もう1曲だけ紹介させてください。Beyond the Bottomは本当に良すぎるので一度で良いから、いや何回も聴いてくれ!!!
Final公演参加のきっかけ
Wake Up, Girls!が解散するという事実は知ってはいましたが、SSA公演の存在を知ったのは2月下旬頃でした。
最後の最後だけ参加しちゃって大丈夫なのだろうか... と 行かないと一生後悔しそう という気持ちが交差しながら、友人(こちらもWUG現場初)にチケあるし行こうぜと言ったところ一緒に行くことになりました。
ちなみにこの記事を書いたきっかけは、参加前に読んだとあるブログに『あなたの「申し訳ない」を「このために来た」と交換していただけると嬉しいです。』と、書いてあったことです。
きっかけをくれてありがとうという言葉しかありません。
普段このブログは書いたプログラムの話とかの技術系の話しかしていませんが、今回が初めてのライブレポートです。
せめて、「伝説の瞬間を見た」事だけでも記録に残して、楽曲などに触れてもらうきっかけになれば良いかなと思ったので。
いざ、現地へ
当日仕事があったので、退勤後ダッシュで会場まで向かいました。
会場に着いたのは開演30分前... 急いで会場に入り、席を確認しました。(席はステージ右側、200LVでした)
コールは少ししか予習出来なかったですが、SHIFTのコールが最高に楽しかったです。
そして、Polaris、満点の星空ってこれのことだったのか... 見られて本当に良かったです。
全体を通して思ったのが、ダンスが凄い... よくあれだけ歌いながら踊れるなと素直に凄いと思いました。
細かい各楽曲のレポート、ちゃんと書けなくて申し訳ないです。
色々書きたいことがありましたが、ここは文章が上手いワグナーの方々の記事を見てもらったほうが良いと思うので長くは書きません。
どれだけすごかったかはTwitterで#WUG_SSAで検索すれば分かると思います。
トリプルアンコール、すげえよ.... 今日がWUG現場初めての自分含め、皆で「Wake Up, Girls！」と叫んだ。
段々と大きくなる会場全体に響き渡る声に、感動した。
終演後、泣きながら帰る人も居れば「もう沢山泣いたし、第二章の始まりだから笑顔でスタートしたい」と話しながら帰る人.... 色んな人が居ました。
めっちゃ良かったわ...とか言いながら駅で友人と別れ、電車の中でTwitterを立ち上げるとトレンドに入る#WUG_SSAというハッシュタグを見つけました。 読みながらめっちゃWUGちゃんたち愛されてたんだなと思いました。
何もかもが凄すぎて、もうWUGのライブを二度と生で観ることが出来ないのかと、正直後悔しました。
第二章のはじまり
「来て良かった。 本当に....。 最高のライブをありがとうございました。」
これしかもう言うことがありません。
翌日、 田中美海さんが書いたブログを読みましたが、「星ってなくなる瞬間が一番輝いていて美しいんだって」という言葉に喪失感だけ残った僕の心では何と表現したら良いのか分からない気持ちがこれだということに気づきました。
壊れかけの望遠鏡では最後の最後まで見つけることが出来なかった... 手遅れだけどもう遅い...
どんなに惜しんでも、もうWUGとしての彼女たちを自分の目で見られないと思うと、悔しくてたまりませんでした。
でも、一番輝いている瞬間を見られて、本当に良かったです。
ProLiant ML350p Gen8のファンの回転数制御の謎
ProLiant ML350p Gen8が安かったので買ってみたけれど、めっちゃうるさくてとても寝室には置けない... ということで出来るだけファンの回転数を落とすために色々試してみました。
ファンがうるさい
クッッッソうるさいです。全部のファンを100%で回転させるとダイソンの掃除機と張り合えるレベルでうるさいです。
内部構成(ファンの回転数制御に関係あるもののみ抜粋)
- PCIe gen3 x4スロット: PLEXTOR M8Pe 512GB
- CPU: Intel(R) Xeon(R) CPU E5-2620 ×2基
- Smart Array: Smart Array P420i Controller(ドライブケージには何も刺していない状態)
- BIOS: P72 05/21/2018
- iLO: 2.61 Jul 27 2018
- RBSU上の冷却設定: Optimal Cooling
- Power Regulator Settings: Dynamic Power Savings Mode
※CPU 2基搭載の場合、ファン4つ搭載が必須。でなければBIOSに起こられてブートしない。
ファンの挙動の謎
hpのエンタープライズ向けのサーバを持っている方はご存知かと思いますが、POSTが通るとファンの回転数は内部温度に合わせてそこそこ低くなります。
なるはずですが、コイツは全ファンが32%から下がりません。普通にうるさいです。
iLOから見てみると、4基あるファンが全て32%で稼働していることが分かります。
| Fan | Status | Speed |
|---|---|---|
| Fan1 | ✔OK | 32% |
| Fan2 | ✔OK | 32% |
| Fan3 | ✔OK | 32% |
| Fan4 | ✔OK | 32% |
ここで少し調べてみると、フォーラムにこんな情報がありました。
ぶっ壊れてるHDDでも何でも良いからドライブケージに何か刺してみるとファンの回転数が下がるよ ...とのこと。
HDDを付けてみる
サーバに付いてきたEG0300FBDBRというhpのSAS接続のHDDを刺してみます。Smart Arrayの方では何も設定しなくても大丈夫です。
iLOから見たファンの回転数は以下のような感じです。
| Fan | Status | Speed |
|---|---|---|
| Fan1 | ✔OK | 27% |
| Fan2 | ✔OK | 27% |
| Fan3 | ✔OK | 6% |
| Fan4 | ✔OK | 6% |
かなり静かになりました。(それでもそこそこうるさいですが)
うるささのレベルとしては押入れか何かに閉じ込めておけば気にならないってレベルです。
HDDを付けた状態でPCIeスロットに何も刺さない状態してみる。
PCIe gen3 x4スロットに挿していたPLEXTOR M8Pe 512GBを取り外してみます。
iLOから見たファンの状態は...
| Fan | Status | Speed |
|---|---|---|
| Fan1 | ✔OK | 6% |
| Fan2 | ✔OK | 6% |
| Fan3 | ✔OK | 6% |
| Fan4 | ✔OK | 6% |
めちゃくちゃ静かになりました。無音とまでは行きませんが全然気にならないレベルで静かです。
結論
- HDDが何も刺さっていないとケージ内の温度が取得できず全ファンをとりあえず32%で回すらしい
- 社外品のPCIeカードが刺さっていると(その温度が取得出来ないため)カードが刺さっている方のファンが27%で回る
C#でもDangerしたかったので、出来るようにした話
TL;DR
- KotlinとかJSとかJavaの主要なLinterが吐き出すレポートファイルを食えるDangerプラグインはいろいろある
- だけど、C#はねえ！
- 仕方ないので作った github.com
- ついでにDanger本体のAppVeyor(Windows環境が使えるCIサービス)対応化をした github.com
これがしたい
やり方
LinterをCI環境に導入する
C#のコードを読めるLinterはいろいろありますが、VSの拡張だったりでコマンドを叩いてレポートファイルを吐き出させるという用途には使いづらいものが多かったので、今回はJetBrains社が提供しているReSharper Command Line Toolsを使用しました。
ReShaper自体は有償ですが、Command Line Toolsは無償ですのでこいつをうまくCI環境に入れてあげれば良いのです。
と言っても、自分のレポジトリにReSharper CLTのバイナリを入れるのはライセンス的にもNGですし、気持ち悪いのでここは上手く工夫しましょう。
if(![System.IO.Directory]::Exists((pwd).Path + "\ReSharperCLT2018.2.3")){ Invoke-WebRequest -Uri https://download.jetbrains.com/resharper/ReSharperUltimate.2018.2.3/JetBrains.ReSharper.CommandLineTools.2018.2.3.zip -OutFile JetBrains.ReSharper.CommandLineTools.2018.2.3.zip Expand-Archive JetBrains.ReSharper.CommandLineTools.2018.2.3.zip -DestinationPath ReSharperCLT2018.2.3/ }
CIの設定で、インストールスクリプトに上記PowerShellのスクリプトを入れてあげましょう。
それで、あとはReSharperCLT2018.2.3をキャッシュするように指定してあげるといい感じに初回だけダウンロードと展開が走るようになり、次回以降はキャッシュから展開されるようになります。
Dangerを入れる
まずはGemFileを用意しましょう。
source "https://rubygems.org" gem 'danger' gem 'danger-resharper_inspectcode'
次にDangerfileを用意します。
# Ignore inline messages which lay outside a diff's range of PR github.dismiss_out_of_range_messages # PR if github.pr_title.include? "[WIP]" || github.pr_labels.include?("WIP") warn("PR is classed as Work in Progress") end # Warn when there is a big PR warn("a large PR") if git.lines_of_code > 500 # Warn when PR has no assignees warn("A pull request must have some assignees") if github.pr_json["assignee"].nil? resharper_inspectcode.base_path = Dir.pwd resharper_inspectcode.report "report.xml"
ReSharper CLTが吐き出したreport.xmlを食わせる設定です。
ビルド or テストが走ったらReSharper CLTとDangerを走らせるように設定する
./ReSharperCLT2018.2.3/InspectCode.exe -o="report.xml" ./YOUR_PROJECT.sln bundle exec danger
CIの設定で上記PowerShellスクリプトがビルド後に走るように設定すればおｋです。
AppVeyorでの設定例
NowPlayingV2/appveyor.yml at develop · tumugin/NowPlayingV2 · GitHub
長ったらしい説明よりも使用例を見てもらった方が早いと思うので...
ちなみに、AppVeyorのデフォルトのRubyはちょっと古いので、PATHを書き換えてあげたほうが良いと思います。
IntelliJ IDEAでAndroidプロジェクトを開いたらRを認識しなくなった時の対処法
俺のRを返してよ！！！！！
何故かRを認識しなくなってしまった.... 俺のRを返してくれ...
そしてなぜかビルドはちゃんと通り、エミュレータ上でアプリもちゃんと動く。謎だ...
直し方
build/以下のそれっぽいやつを見つけて、Mark directory as>Generated Sources Rootに指定する。
するときれいさっぱりエラーが消える。が、これは一時しのぎのしかならない(Gradle Syncをかけると元に戻ってしまう)ので、Android gradle Pluginの設定を疑った方が良いだろう。
今回はalpha版を使ってたので、stableに戻したところ問題なくRを認識しました。
Android Studioの場合は
Android StudioではMark directory as>Generated Sources Rootが出来ないので、一回ビルドを通してAndroid Studioを再起動したところエラーが消えました。(原因不明)
なうぷれTunesV2 1.4をリリースしました
お久しぶりです。なうぷれTunesV2 1.4をリリースしました。
アップデート内容
「今すぐツイート」を実行した際に、アルバムアートが無いファイルだとエラーになることがあったバグを修正
バグのご報告ありがとうございました。
ちなみに、自動ツイート機能でも同様のバグが発生していたので修正しました。
「前回のツイートから一定時間経過していない場合はツイートしない」の設定において秒単位での時間指定を可能にした
今までは分単位での指定になっていましたが、分単位の指定に加え秒単位での指定が可能になりました。
これにより、0分30秒のように1分未満の設定も可能になります。
Mastodon連携において、公開範囲を指定可能にした
投稿先がMastodonの場合、トゥートの公開範囲が選べるようになりました。
また、自動投稿に関しては設定画面からデフォルトの公開範囲を選べるようにしました。
その他アップデート内容(今のところあまり動作には関係ありません)
- Mac版の開発開始に伴い、共通部分の切り離しをしました
- エラーメッセージがちゃんと出ていなかった部分があったので修正しました
- 依存ライブラリを更新しました
ダウンロード
あとがき
インターンなどでいろいろと忙しく、なかなかアップデートが出来ず申し訳ありません。
就職活動が終わり次第、色々とアップデートしたいと考えているのでよろしくお願いします。
ちなみに、次回のアップデートでは以下の変更を加える予定です。
- Discord対応
- 現状対応していない楽曲タグの対応化
Windows10+Android Studio+NDKでNinjaが無いと怒られる件について
NDKでC++製のライブラリをアプリに組み込もうとビルドをかけたところなんかcmakeがコケる模様。
発生する謎エラー
CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
回避策
PATHが通っている場所にninja.exeを配置したところ解決。
Android SDKのインストールディレクトリ内にcmakeというフォルダがあり、その中にninja.exeが入っているようだがこいつは認識しない模様。(じゃあ何のために入れてんだよって話だが、恐らくバグなのだろう)
cmakeを走らせる前にPATHを弄れば解決しそうな気もするが、あまりSDKに付いてきたビルドスクリプトを改変したいとは思わないので今回はいつか直ってくれると良いなと祈りながらこの回避策を当てた。
pixivの夏インターンに参加してきた話
8月22日〜8月28日にピクシブ株式会社で行われたpixiv SUMMER BOOTCAMP 2018に参加してきました。
pixiv SUMMER BOOTCAMP 2018とは
簡単に言うとpixivで夏に行われるインターンのことです。(ちなみに春インターンもあるそうですよ)
2018/10/5追記: ピクシブ公式ブログに今回の夏インターンの話が掲載されました
選考とか参加する流れとか
(今回の)インターンの選考フローは
- 書類選考 もしくは github選考
- 面接 + コーディング面接
という感じになっていました。ちなみに自分はgithub選考を選んだので、自分のgithubアカウントの中身が書類選考の代わりになるという感じでした。
ちなみにコーディング面接の問題の内容ですが、あんまりよく覚えてませんが(すいません)Rubyで書いたのを覚えています。
ホワイトボードに書くタイプのテストは初めてだったのでめちゃくちゃ緊張しましたが、面接担当の方に「こんなAPIありましたっけ？」みたいな質問を投げても大丈夫なので安心して参加して大丈夫だと思います。
参加のきっかけですが、Twitterで仲良くさせて頂いてる方がpixivのインターンの経験者が多かったので自分も行ってみようかなあということで応募してみたという感じでした。(あとは毎日使わせてもらってるサービスというのが大きかったですね)
インターンでやったこと
ざっくりと説明するとpixivコミックのAndroidアプリの方を触らせてもらいました。
インターンの課題内容については配属先チームによって様々ですが、自分は 画面遷移アニメーションの改善と実装 でした。
Start an activity using an animation | Android Developers
Android Developersに分かりやすい解説が載っていますが、具体的に言うとこのようなアニメーションをpixivコミックのアプリ内に取り込もうといった感じです。
1日目(水曜日)
インターンの流れの説明を受けて、自己紹介して、社員の皆さんとお昼ご飯を食べて、支給されたiMac 4K(既にある程度セットアップ済みでしたが)に開発環境を作ったりして、残った時間で少しpixivコミックのアプリの方のコードを読ませてもらい、お試しの課題として細かいissueを直したfixを🎉初コミット🎉させてもらいました。
2日目(木曜日)
実装できそうなアニメーションを探して、試しに色んなActivityに組み込んでみたり.... と試行錯誤していたら一日が終わってました。
実はコードレビューを受けて指摘点を直してコミットしたり...というのは人生初の体験だったので新鮮でしたね！(綺麗なコードを書くことを心がけよう！)
3日目(金曜日)
順調に進むと思いきや、バグにぶち当たる。
解決策はいくつか思いついたので、試してみましたがあまりうまく行かず... 困ったなあということで色んな人に相談してアドバイスをもらってりしてました。
ちなみにハマったバグですが、一部分が画面の外にあるなど見えてないアイテムを選択するとアニメーションさせるShared Elementに指定したビューがシステムのUIの上に描画されてしまう... というものでした。
↑こんな感じに(画像はGoogleが配ってるサンプルアプリをバグらせたものなので実物とは違います)
ちょっと分かりづらいですが、一瞬被って表示されるのが分かると思います。
探してみると色々対処法はあるようですが、アニメーションが崩れたり、ナビゲーションバー、アクションバー等も一緒に強引にShared Elementに入れることでアニメーションさせるなどあまり根本的な解決になっていない(遷移先にも共有するビューがあることが大前提なので広告やボトムナビゲーションバーなどには使えない)ものが多かったので別の方法で対策しました。
簡単に言うと、ビューが完全に見えている(ビューの一部が他のビューの下に隠れていない)かどうか判定してから、Shared Elementに入れるか、またアニメーションさせるかの処理を入れて解決しました。
public boolean isViewFullyShown(View view){ Rect rect = new Rect(); view.getGlobalVisibleRect(rect); return view.getHeight() == rect.height() && view.getWidth() == rect.width(); }
こんな感じに...(KotlinならViewクラスに拡張メソッドを生やすといい感じになると思います)
4日目(月曜日)
バグを直してコミット！翌日は成果発表ということでいい感じのところまで実装を進めて一日が終わりました。
5日目(火曜日)
インターン生全員で期間中に出した成果を発表しました。
退勤後、社員さん達とインターン生の皆と打ち上げに行き、全日程終了！という感じです。
その他諸々、まとめとか
ちゃんと最新のAndroid開発のアレコレにキャッチアップしていた
出来たばかりのアプリじゃないのにちゃんと最新のアレコレが取り入れられてる！すごい！！とコードを読ませてもらった時に思いました。(小学生みたいな感想ですが、あまりレガシーを引きずってなくてすごいと思いました)
そこ感動するところ？と思われてしまうかもしれませんが、プルリクを送ると自動的にコミットしたコードに対してLintが走り、コーディングルールに反している部分に自動的に指摘をするコメントが入るようになっていて「これは早速家に帰ったら自分のレポジトリでもやらなきゃ」と思いました。
帰宅後、TravisCIで回しているスクリプトを少し弄って、自動でチェックを行うようにしました。また一つ勉強になりましたね.... 感謝感謝。
Kotlinはいいぞ
開発ではKotlinを使用しましたが、C#にもこの機能ほしいな...なんて思いながらコードを書いてました。良い言語です。(C#も良い言語ですよ)
普段はC#で開発しているので復習がてらインターン前に1週間程Kotlin漬けの日々を送ってみましたが、実際に稼働しているコードを見ると自分が知らない書き方があったりで勉強になりました。
ミリオンライブ！のPが多かった(?)、そして鑑賞会をした
(あまりインターンに関係ない話ですが) 今回のインターン、一緒に参加したインターン生に自分含めて3人ほどミリオンPが居て正直に言ってびっくりでした。(自己紹介用に作ったスライド見てたらおおお！！！ってなりました)
メンターさんもミリオンのPでした。なんとっ！！でしたね。お誘いがあったので金曜日は退勤後に社内でミリオン4thの円盤鑑賞会をしました。やっぱりいつ見てもミリオンの円盤は神なんやなあって....
打ち上げでは布教させて頂きました。
美味しいご飯を奢っていただきました
ごちそうさまでした。(写真撮り忘れました)
インターンの報酬により、pixivプレミアムが実質無料になった
インターンの報酬は5万円でしたが、pixivプレミアムの月額料金は(2018年9月現在)540円/月なので約92ヶ月分の会員費が無料になったということになります。(なりませんが今後もありがたく使わせてもらいます)
pixivのpは小文字のpということに気づいた
今までずっと大文字のPだと思ってました... すいません。
「ひとりで開発してるんじゃない」という事の大切さ
チームで複数人で開発していると、いろいろな知見が得られます.... これ、結構大きいです。
ひとりで開発していると、(余程人に見れ貰えるプロジェクトにならない限り)基本的には誰にも指摘されないのでなかなか辛いものがあります。自分で気づくまでおかしいコードはおかしいままですし、もっと良い実装方法があったとしてもなかなか気づけないです。
人にレビューしてもらうといろいろな 新発見 があって勉強になりますし、一緒に開発することでモチベも上がりますね。(正直に言うとレビューは楽しいことばかりではありませんが、それでもやる価値はあると思います)
(コードを否定されてる気分になるので)レビューを食わず嫌いしてた人間ですが、受けてみて印象が変わったというのが大きかったです。
以上、お疲れ様でした！
