Terrarium

いわゆる掃き溜めの ありふれた有象無象

研究生活を支えるちょっとお高いガジェットたち(+すべった話)

この記事はeeic (東京大学工学部電気電子・電子情報工学科) Advent Calendar 2017 その2の20日目の記事として書かれたものです。

qiita.com

昨日は @CeleuC さんの研究バイトの記事でした.いいですね,私も研究でお金が欲しいです. 明日は @yunoLv3 のVRの記事みたいですね.彼は存在がVRって感じの人なのでどんな記事を書いてくれるか非常に楽しみです.

はじめに

EEIC2016でB4をやっているtellusiumです. 自分の趣味の一つとしてガジェット(デバイス?)集めみたいなものがあり,それらを研究生活にどう使っているかとそのレビューについて書いていきたいと思います. B3のころはバイト侍をしていて,結構お金に余裕もあり色々なガジェットを買っていました.おかげでほぼ使い切ってしまいましたが…

それでは,趣味の話であり研究の話でもあり,すなわちプログラミングの話と言えなくもない話の始まりです. (元々「趣味の話か研究の話かプログラミングの話かすべらない話」と書いていたので無理矢理)

起床

まずは朝ですね. 心地よい一日の始まりのためにも,朝は非常に重要です. そこで睡眠から起床に使えるガジェットのレビューです.

Fitbit Charge 2

起床用のガジェットとしては,Fitbitを使っていたことがあります.私が使っていたのは「Fitbit Charge 2」でした.

www.fitbit.com

価格は確か2万円ちょっとだったような.

機能

普段の生活とエクササイズ,睡眠に関わる様々な機能がついています. 詳細はHPに任せます. 特に私が使いたかったのは次の機能でした.

  • 睡眠のアクティビティをトラックしてくれる機能
  • バイブレーションによるアラーム機能

感想

使ってみた感想ですが,もちろん人によって変わるとは思うのですが,「あまり使っている意味を感じない」でした. 特に次の点です.

  • よく眠れている時と眠れていない時での差が一目ではわからない(し,わかるためにはデータとにらめっこする必要がある)
  • 毎回トラック結果を見るためにアプリを開かなくてはいけない

特にアプリを開かなくてはいけないのは自分の理想の使い方とは乖離していたので少し残念という感想です.

自分はFitbitをEvernoteやGooglePhotosのような「放置して貯めておく」系のサービスとして期待していました. 使っていれば自動的に1週間に1回睡眠のアドバイスがされる的な(そのうちそうなるかもしれない,技術的には可能なはず) しかし使ってみると,これは「積極的に使う必要のある」サービスだったように思います.

ということで最近はFitbitをつけることをやめてしまいました. ただ最近睡眠で少し悩んでいるので,寝るときだけつけてみることも検討しています.

通学

私は電車で結構な時間を通学するため,電車の中でどう過ごすかが1日のQOLを大きく左右します. そこで電車の中で使っているデバイスを3つほど紹介します.

iPad mini, iPad Pro 10.5

電車の中で論文を読むには,大画面デバイスが欠かせません. 昔はiPad miniを使っていましたが,途中でiPad Pro 10.5に買い換えました. 電車で立ちながらだとちょっと重いのですが,座っている分には快適に論文が読めます.

機能

多分みんな知ってるので割愛.

論文を読むのは昔はGoodReaderを使っていました.

GoodReader - PDF Reader, Annotator and File Managerを App Store で

DropboxGoogleドライブとの連携ができ,非常に重宝していました. しかし秋くらいにiPad Pro 10.5を買った際にこれらにログインしようとしたところ,Googleはそもそもログインできず(アプリ内ブラウザでのログインが利用できなくなった?)Dropboxは日本語ファイルがあると同期エラーが発生するという状況で,使い物にならなくなってしまいました(対応してくれー)

と悩んでいるときにちょうどiOS11のアップデートがきて,デフォルトでファイラーが使えるようになってからはこちらを使っています. (でもGoodReaderの方が使いやすい…)

感想

iPad miniiPad Pro 10.5の違いを感じたのは次のような点でした.

  • iPad miniで論文を読もうとすると少し小さく感じる
  • 一方iPad Pro 10.5はかなり快適
  • しかしiPad Pro 10.5は電車で立って読む際にはかなり重い

iPad Pro 10.5にしてからは,GoodReaderでもデフォルトのファイラーでも結構快適に論文が読めます. Kindleでコミックを読むのも大画面で快適. 画面が大きい分Macをラボに置きっぱにしていても家で快適にブラウジングは楽しめます.

とこれまで良い点を述べてきたのですが,ApplePencilと合わせて11万円(セルラー付きモデル)の価値があるかと言われると正直なんとも言えないです. まだ投資した額を回収できていない気しかしないので,最近は新しい使い方を模索中です. 例えばこんなものに挑戦しようとしてます.

iPhone X

はい出ました.某りんご企業への強い信仰心を持っておりかつ多額の寄付を行った信者のみが手にすることができるデバイスiPhone Xです(冗談です)

電車内で座れないとき,論文を読むのに欲しいのが大きい画面のスマートフォンです. 昔はiPhone5sを使っていましたが,最近iPhoneXに買い換えました(当日に予約しました)

機能

全てはここに記されています.

感想

言いたいことはたくさんあるので別記事にした方が良さそうなのですが,まあ満足度は高いです. 一応論文を読むという趣旨でこの記事を書いているので,それに基づくと

  • 画面が大きいので,2段組なら縦向きのままでも1段ずつ表示すれば十分読める
  • 画面が縦に長いので,1段組なら横向きにすると結構読める

画面がスマートフォン最大級なため,結構ちゃんと読めます. もちろんiPadに比べると小さいなという感想は否めませんが,電車で立っている場合に使うことを考えれば十分です. (まあ最近は実装中心で論文はほとんど読まないのですが…)

Amps AirSONY WF-1000X

電車で音楽を聴く人は多いと思います.自分も論文を読む気力がない時(ほとんどそうなんて言えない)は,音楽を聴いています. その時に使いやすいのが,左右分離型ワイヤレスイヤホンです. コードがないため,電車内でもたつくことなく装着できますし,タッチノイズもなく,電車を乗り換えている時でも快適に音楽を聴くことができます. 昔はAmps Airを使っていましたが,今はSONYのWF-1000Xを愛用しています.

http://solrepublic.jp/product/amps-air

www.sony.jp

機能

どちらもBluetooth左右分離型のワイヤレスイヤホンです. WF-1000Xの方はなんとノイズキャンセリングもついています.

それぞれの特徴を比較すると次のようになります.

  • Amps Air
    • WF-1000Xに比べ安い(13000円ほど)
    • 本体の電池持ちが良い(1.5h の往復すなわち3hでも余裕で持つ)
    • ケースにモバイルバッテリーがついているので本体の充電が切れた時も充電できる回数が多い
    • 音質はまあまあ
    • 遮音性は高い
    • 音がでかい(iPhoneの音量制限機能を使わないとでかすぎる,1でもでかいためGooglePlayMusicとかでは使えない)
  • SONY WF-1000X
    • 高い(25000円ほど)
    • 本体の電池持ちはそんなにない(1.5h使うと赤になる)
    • ケースに入れれば充電できるがケース自体の容量がそんなにない(2回くらいしか充電できない)
    • その分軽い
    • 音質はかなり良い(さすがSONY
    • ノイズキャンセリング機能付き
    • 音が控えめ

感想

正直に買ってよかったと思える買い物でした. 一度分離型ワイヤレスを使うと普通のイヤホンの取り回しが面倒になります.

上にも書きましたが(Bluetoothイヤホン全般は)音がでかいです. 1にしてもでかい. 音量調整が効くiPhone純正Musicアプリならそれを下げると少しましになるのですが,そこがなかなか使いづらい. 純正でないGooglePlayMusicなどを使おうとするとでかすぎて聴けないレベルでした.

私はWF-1000Xの発売の際にAmpsAirから買い換えたのですが,高い分こちらの使い心地は最高です. 音が控えめなので,音量制限を使わずとも快適に音楽が聴けます. 特にノイズキャンセリングは最高で,iPhoneで音楽を聴いていてもノイズキャンセリングを使うことができます.

お金に余裕がある方にはぜひお勧めしたい1品です.

(AmpsAirは胸ポケットに入れたまま洗濯してしまい買い換える羽目になったというエピソードが…)

研究室

最後は研究を進める拠点となる場所,研究室. いかに集中して作業に取り組めるかが鍵となります. しかしここは人が集まる場所,会話は時間的にも空間的にも偏在し,いつスマブラが始まるかわかりません. (個人的にはスマブラが勃発したほうが楽しげで好きですが) そんな時にも,ノイズキャンセリング. 私はSONYのMDR-1000Xを使っています.

MDR-1000X

www.sony.jp

WF-1000Xの登場に合わせて新しいモデルが出ています.

www.sony.jp

特徴

  • 高い(35000円ほど)
  • 音質が良い(自分が持っている中では最高)(高いからそれはそうという感じ)
  • ノイキャンをONにして音楽を流せば近くでスマブラしていても全く聞こえないレベル
  • ワイヤレスなので取り回しが楽

感想

この記事の中でもお勧めNo.1です. ノイズキャンセリングはとても優秀で,音楽や環境音などを流していれば周りの会話が気にならなくなります. 右側の耳にあたる部分にタッチセンサが入っており,ジェスチャで音量や音楽のスキップや戻る操作ができます(便利でもありちょっと不便でもある) 使い続けても疲れは感じません.

同じような商品にBOSEのQuietComfort35があるのですがデザインが好きなのでこちらを選びました. QuietComfortは使ったことがないので比較はできません.ごめんなさい.

www.bose.co.jp

Macbook Pro

みんな大好きMacbookProです. Macはラボ内でのデファクトスタンダードと言っても過言ではない. まあこれについては言うことは何もないのですが,Macを使うメリットは次の点だと思っています.

  • 画面が綺麗
  • フォントが綺麗
  • shellが使える
  • Adobe系のソフトが使える

最近Macbook系の値段がどんどん上がっており,TouchBarと言うよく分からないものがついてしまったり,ちょっと行く先が不安でもありますが…

まとめ

研究お役立ちガジェットのレビューはいかがだったでしょうか. 書いてみるとただのSONY製品とApple製品推しの記事でしたね.

将来技術者というか生産者になる以上,今最先端の製品やサービスがどうなっているかを知るのもとても重要だと思っています. と考えると,このような最新ガジェットを買うのもただの消費ではなく投資とみることができるかもしれません.

以上です.最後までお読みいただきありがとうございました.

すべった話

最近IT業界のブラックな噂,聞きますよね. 私も去年ちょまどさんをフォローしたあたりからIT業界って大変なんだなぁと感じた記憶があります. ところでそういうツイートってこんな風な書き方してますよね?

SIer出身の人と…

SIerに挨拶しにいったら…

SIerからWeb系に転職したのだが…

こういうツイートをみて私は思いました.

「スラーってどんなひどい会社なのかと」

Twitterのフォントって大文字のI(アイ)にセリフがないので小文字のl(エル)と見分けがつかないんですよね. 以上.謎の大企業Sler(スラー)に対して反感を持った私でした.

はい,これで「趣味の話か研究の話かプログラミングの話かすべらない話」がコンプリートできました. どうでもいいですね.最後までお読みいただきありがとうございました.

実験でQiita記事のタグ情報を可視化した話

この記事はeeic (東京大学工学部電気電子・電子情報工学科) Advent Calendar 2017 その2の12日目の記事として書かれたものです。

qiita.com

枠が空いていたので元々アドベントカレンダーの記事にしようとしていたものをこちらに書くことにしました.

はじめに

EEIC2016でB4をやっているtellusiumです. 私は今年の秋に大学の実験の方でTAをやっていました. 情報可視化実験というものです.

2017infovislab:start [Koji Yatani's Course Webpage]

去年私自身もその実験を受講しており,せっかく作ったのと後輩の参考になればと思いこの記事を書くことにしました.

どんな作品が製作されたかは,まとめ動画をみていただければ分かるかもしれません.ちなみに2016年度の方は私が製作しました(BGMが激しいのはこの動画にインセンティブを受けたからという裏話

www.youtube.com

www.youtube.com

製作物について

なんとなく私はQiitaの記事を使って何か可視化できたら面白そうということで,@natsuki-1994を誘ってチームを組みました. (この実験は基本的には2人のチームで行われます)

紆余曲折を経て完成したのが,QIitaのタグ同士の関係を可視化したものです.

これは私のGithub(下のリンク)で現在公開しています.

https://ta21cos.github.io/qiqiqi/src/zero.html

使っている記事情報が去年までのため,新しい情報は含まれていませんのでご注意ください. (後述のWikipedia情報と人気Contributor情報は動的に取ってきているので実は最新です)

説明

プログラマのための技術共有サービス「Qiita」の各記事には投稿者が タグを付与することができますが,「盛り上がっている技術分野の可視化」「技術同士の関連性の可視化」 ができるのではないかと思い、このシステムを作りました.

可視化にはForce Layoutを使っています.タグ同士の関係を表すにはこれが最もふさわしいと考えました.

ノード1つ1つがタグを表していいて,大きさはタグのついている記事数を表しています. タグは1万種類ほどあるため,ある程度の記事数があるタグのみを表示しています. また,各ノードは分野(これは自分たちの方で勝手に分類した)ごとに色分けしています.

リンクは特に結びつきの強い分野のノード同士を繋ぐようにしました(そうでないととても見辛かったので…) しかしこのままでは離れ小島なタグが大量発生したので,最も関連性の高いノード一つとは必ず繋がるようにしています. また年を変えることができ,ノードの大きさは左下に表示されている年までの記事の積算数に対応しています.

タグ上にマウスオーバーすると,WikipediaAPIを用いてタグ名で検索した時に出てくる情報の最初の一文を表示しています. なので物によっては全く関係のない文章が表示されることがあります… (AWSとか見ると面白いかも)

各ノードをクリックすると,各タグの人気ContributorTOP3とそれぞれのContributorの人気記事一つが表示されるモーダルウィンドウが表示されます. またContributorや記事はQiitaへのリンクになっており,ページに飛ぶこともできます.

使っている言語など

この実験では可視化ライブラリとしてD3.jsを使います. なのでこのシステムもページ自体はD3.jsを使って作成しました. データ処理などは後述しますがPythonを用いています.

データ収集・データ処理

この時は(今もですが)あまりDBに詳しくなかったため,記事の重複を避けるため面倒な手順を踏んでいます. QiitaのAPIを用いて,

  • tagの一覧を取って来る(get_tags.py
  • 各tagを引数にして記事を10000件ずつ取得(get_article_by_tags.py
  • 各記事について,そのユーザーを取得(get_users_by_article.py
  • 各ユーザーについて,記事を全て取得(get_article_from_users.py

した結果の最後のデータを記事データとして用いています. もっといい方法があるはず(primary keyを使うとか)

この後でタグ同士の共起関係を計算したものをjsonとしてあらかじめ用意し,これを用いて可視化を行なっています. 共起関係の計算は年ごとに行い,年ごとにjsonファイルを作成しています. (calc_cooccurance.pyあたりに書いてあると思います)

想定される利用方法

この実験では可視化して面白いだけでなく,ターゲットはどんなでどんな風に使われるのか,また可視化することでどんな知見が得られるかまでしっかりと考えることが求められています.

このシステムは,ある技術分野に関して興味を持っており,詳しくその分野を知ってみたいと思ったビギナーをターゲットとして製作しました. 特定の分野の人気Contributorを表示することで,その人の記事を辿ることで効率よく良質な記事にたどり着け,最短でその分野をキャッチアップできます. なぜなら,特定のタグの人気記事よりも,人気なContributorが投稿した記事の方が良質な記事が多いと考えたからです. それゆえにモーダルウィンドウに表示されるのも人気記事ではなく人気Contributorの記事となっています.

2012年,Qiitaの登場した年を見てみると,記事数も少なく,注目されるタグ数も少ないことがわかります. (と書きましたがAPIで取りきれていない可能性も否定できないのであくまでも可能性ということで)

2013年をみるとタグの種類が増加し,Qiitaがプログラマ界隈で徐々に使われてきている様子がわかります. またスマートフォン関連で見てみるとiOSタグしかなく,Androidがまだ注目されていないこともわかります.

2014年にはタグ数・記事数共に大幅に増えていることがわかります. Androidも急激に増加しiOSと変わらない大きさに,またPythonも大きく増加しており機械学習などで一気に注目を浴びたことが伺えます. またAppleが「Swift」を発表した年でもあり,Swiftタグが登場していることもわかります.

2016年はあの「AlphaGo」が世間を騒がせた年ですが,ここにきて「AlphaGo」の基礎技術である「強化学習」タグやGoogle機械学習フレームワークである「Tensorflow」タグが出現しています. またIoTタグやRaspberryPiタグも登場しており,IoTというワードが注目され始めたこともわかります.

まとめ

これまで書いたことは実験で提出したレポートを参考に書かれています.

ここまで読んだ方はお分かりかもしれませんが,この実験は多くのことを学生に求めていることがわかります. ここでは最終成果物について書きましたが,これ以外にも先生から情報可視化についての講義や実際に例となるシステムを作るHands-on Tutorialもあり,内容は盛りだくさんです. ちなみにこの実験は10日実験(週3日)なので,3週間から1ヶ月程度でここまでのことをやります.

確かにとても大変ですが,非常に密度の高い実験で,私はとても楽しく感じました(2日くらい徹夜した気がします)

EEICには他にもCPUを自分で作るとか,OSSを自分で改良してみるとか,色々な楽しい(つらい)実験がたくさんあります. この記事を見て,一人でも多くの方がEEICに興味を持っていただけると嬉しいです. (最後なんてまとめればわからないのでとりあえずEEICを宣伝していくスタイル)

シェルスクリプトを使ってGitHubの特定のOrganizationの持つリポジトリを全てCloneしたい

表題の通りです.あるOrganizationのリポジトリを全部バックアップする必要があったため,それをシェルスクリプトでやってみようという話です.

TL;DR

curl -u [USERNAME] -s https://api.github.com/orgs/[ORGANIZATION]/repos | grep "ssh_url" | sed -e 's/\".*\".*\"\(.*\)\".*/\1/' | xargs -L1 git clone

調査

シェルスクリプトはあまり触れたことがなかったので,やり方を調べる必要がありました.以下は自分向けのメモとして冗長に上記コマンドにたどり着くまでの経緯を書きます.

1. Organizationの全リポジトリの取得方法

やりたいことを英単語でつらつら書いて検索すると似たような事例が出てきました.

Clone all repos from a GitHub organization · GitHub

どうやらcurlを使って特定のAPIにアクセスすれば取得できそうです.このページではRubyを使って書いていますが今回はシェルスクリプトのみでやりたいので,前半のみ参考にします.

2. リポジトリのURLの取得

curlAPIにアクセスするとOrganizationの持つリポジトリの情報が色々取得できますが,ここからCloneのためのURLを抽出する必要があります.ざっと中身を見ていくとssh_urlを使えばCloneできそうです.というわけでgrep "ssh_url"を使って特定の行のみ取り出せました.

次はこの行からURLの部分のみを抽出したいのですが,そのためにはsedを使えば良さげです.マッチさせたい部分を括弧でくくるとできるらしいので,2つ目のダブルクォーテーションに囲まれた文字列を取り出します.すなわち"[文字列]"[文字列]"([取り出したい文字列])"[文字列]ということです.すごく適当ですが…マッチした部分はその順番を用いて\1で取り出せるので,sed -e s/[正規表現]/\1/と書くことによってURLのみを取り出すことができました.

(ちなみに括弧もエスケープする必要があること,\1の後にもバックスラッシュが必要であるというところで一瞬つまずきました…)

stackoverflow.com

stackoverflow.com

3. clone

これまでで取得したURLについて,それぞれgit cloneを走らせます.そのためにはxargsを使えそうですので,使い方を調べるとxargs git cloneでできると思ったのですが,too many argumentsと怒られました.入力に使う行数を指定する必要があったようです(当たり前だ…)xargs -L1 git cloneで実行できました.

まとめ

記事執筆も含めこれまでおおよそ40分くらい.書き終わった後でほぼ同じStackOverflowのページを見つけました…

stackoverflow.com

PythonでSwift-likeなstructを使いたいので検討(してみたがダメだった)

Pythonはいろいろなことを簡単に書けるのでよく使っています. ところが『実践Swift』を読んでみたところ,その型のある世界に憧れるようになってしまいました… (大学で型についていろいろ勉強したのもある)

www.amazon.co.jp

今回はSwift-like(と言い切ってしまっていいのか不安が残りますが)な構造体を使いたい場合にどんな実装をすれば良いのかについての検討です.

Swiftでは変数(や関数)をまとめた型としてenumstructclassprotocolなどがあります. 『実践Swift』では,structは変数のまとまりを値型として扱いたい場合に用いると書かれています.

一番簡単な例が座標情報などですね. Pythonでクラスを用いて実装すると次のようになります.

class Point():
    def __init__(self, x, y):
        self.x = x
        self.y = y

p = Point(10, 20)
print(p.x) # 10
print(p.y) # 20

一見これで良さそうに見えるのですが,インスタンス同士の代入を行なった場合クラスでは参照がコピーされます. すなわち片方の座標の値を変更するともう片方も変更されてしまいます. これは座標というただの値を表現する手法として適切ではありません.

以下がその例です.

# (上の続き)
q = p

q.x = 30

print(q.x) # 30
print(p.x) # 30

Swiftのstructを用いると,この座標を参照ではなく値そのものがコピーされるため,以上のような問題は発生しません. (そもそもC言語でも同じです) ちなみに上のコードでq = pの部分をq = copy.deepcopy(p)とするとうまくいきます(import copyが必要)が,できればq = pでコピーできてほしいものです.

すなわちPythonで値型で構造的に記述したいというのが今回の目的です.

ということをTwitterに呟いたら,enum.Enumを使うという啓示をいただきました.

早速調べると…おお…これは使えそうだ(早とちり)ということで書いてみました. 実装には次のサイトを参考にさせていただきました.

py3.hateblo.jp

import enum

class EnumTest(int, enum.Enum):
    # 継承元最初のintはvalueメソッドにおける加算にて型を決める必要があるため書く
    _x: int = 10
    _y: int = 15

    # getter を試した
    @property
    def x(self):
        return self._x
        # return self._x.value()
        # とすればうまくいくが全てのpropertyでこれをやるのは非効率
        # いい方法がないものか…?

    @classmethod
    def value(self) -> int:
        return self._x + self._y

# getterを利用(うまくいかない)
print(EnumTest.x)
# 要素を参照(名前が出てくる)
print(EnumTest._x)
# 要素の値を知る方法(ちょっとめんどい)
print(EnumTest._x.value())
# メソッドを利用(これはうまくいく)
print(EnumTest.value())

# 上から
# <property object at 0x1050a6b38>
# EnumTest._x
# 25
# 25

やりたかったようにEnumTest.xで簡単に値が取得できればよかったのですがちょっと追加の実装がいるのであまり綺麗じゃないですね.

上の実装では致命的な欠陥がいくつかあります.

  • 値の変更ができない
  • Constructorがない(座標データごとにclassを宣言する必要がある)

これではSwift-likeなstructとは離れ過ぎていますね. さらなる検討を重ねるか諦めるか…

ちなみにnamedtupleを使うとpoint.xという形で値が取得できるようですが,こちらも値を変更できないという問題があるそうです.

うーん…そもそも値型の構造体を使うよりもっとPython-likeな手法があるのかもしれないなぁ…

というわけで検討してみたがダメだったという記録です.

(追記) namedtupleが値の変更を行えないと書きましたが関数型っぽく書くなら値の変更は必要ないですね… さらにnamedtupleにメソッドを追加した例もあるのでこちらを使った方が便利そうです. まあいずれにせよスッキリとは書けないみたいだ…

Python で namedtuple を使ってバリューオブジェクトを作る | CUBE SUGAR STORAGE