#えむけーろぐ

北海道産

内定者イベント

就職先の内定者イベントに行ってきた。

春から一緒に働く2人の同期と顔合わせしたり、会社や事業部についての説明や戦略の説明、どういうことを期待されているかを聞いたり、相互理解セッション、今後取り組みたいことの検討と共有などなど。

とても楽しかった。普段とはまた違う人達と接するのは良い刺激になる。自分があまり気にしない事について深く考えていたり、同じ考えるでも自分とはモノの見方が違ったり。そんなわけで、普段とは違う部分の頭を使ったので、結構疲れた。

あと今日は、どちらかというとあまり喋れない日だった気がする。「今日静かだね?」と何度も言われた。静かでいたというつもりは無いのだけど、熱が入ると話のバトンを持ちっぱなしになってしまう悪いクセがあるという事を指摘されたのが忘れられなくて、その反動であまり喋らなくなったというのはあるかもしれない。たくさん喋れる時もあるので、その辺の発動条件はよくわかっていない。

まぁ何はともあれ、楽しい1日だった。来年の4月からいよいよ社会人なるんだなぁという気持ち。今後も楽しくやっていきたい。

実はこの記事はmktakuyaアドベントカレンダー2018 7日目の記事でした。明日の担当は僕のことが大好きな @rasyosu くんです。

ミスドの店内BGM情報を返すWeb APIを作った

RailsによるWeb API開発、SwaggerによるAPIドキュメンテーション作成の練習として、ミスタードーナツの店内BGM情報を返すAPIを作った。

Misdo BGM API

ミスドの店内BGM

ミスタードーナツの店内で流れているBGMは、USENなんかの音楽番組を流しているのではなく、独自に選曲しているようだ。

月ごとのプレイリストの内容は、以下のWebページから確認することが出来る。

店内BGM情報|ショップ情報|ミスタードーナツ

1時間毎に組まれたプレイリストには、それぞれテーマがある。例えば10時、14時、18時からの時間帯には、「ALL-TIME HITS(1)」という様々な時代のヒット曲のプレイリストが流れていたり、11時、15時、19時には「Now Hit Parade」というタイトルで最新ヒット曲が流れている。

f:id:mktakuyax:20181204130718j:plain

ドーナツを食べながら無限コーヒーを楽しむだけで、懐かしの洋楽から最新ヒット曲まで様々な曲に触れる事ができるのだ。

Web APIにしてみた

ここ最近はバイトや部活等でずっとWeb APIを開発していて、練習用の趣味アプリとしても何かWeb APIや、それと通信するモバイルアプリケーションを作ってみたいなと思っていた。

題材は何が良いかなぁとミスドでドーナツを食べながら思いついたのが、このミスドBGM APIを開発することだ。

仕様

仕様は以下のURLで公開している。

https://misdo-bgm.apps.m6a.jp/v1/docs/

エンドポイント

https://misdo-bgm.apps.m6a.jp/v1

Playlists API

  • GET /playlists - 今月のプレイリスト一覧
  • GET /playlists/1 - プレイリストの詳細
  • GET /playlists/now - 現在放送中のプレイリスト

Songs API

  • GET /songs/now - 現在放送中の曲

現状だとまだまだレスポンスの情報が少なかったり、nullに対する意識が低かったりするけど、今後改善していく。

APIを作っただけで終わりではなく、クライアント側でもっとおもしろい事を出来そうなので試してみているところ。

技術

スクレイピング

BGM情報はPDFで配信されている。PDFは6ページあり、1ページがそのまま1つのプレイリストに対応している。

PDFの解析にはRuby製の pdf-reader というGemを利用している。このGemにPDFを食わせたあとに、テキストを抽出すると一定のルールに従って曲情報が出てくるので、あとは文字列操作を頑張るだけだ。

pdf-reader gemでググると上司の書いた記事が上位に出てきて吹いた。

qiita.com

API開発

APIの開発には、RailsとGrape、Grape::Entityを使用した。仕事で使ってる技術を趣味アプリでも使おうマインド。

RailsとGrape、Grape::EntityによるAPI開発の詳しい手順は先日Qiitaに書いたので自分も何か作ってみようという人は参照してほしい。

qiita.com

Misdo BGM APIでは、上記の記事で行った手順に加えて、APIドキュメントの生成のためgrape-swaggergrape-swagger-entityを利用している。これについても後々Qiitaに書いておきたい。

運用

デプロイ先としてConoHa VPS上に、ConoHa公式のDookuアプリケーションイメージを展開して利用している。

Dokkuとは、自分のサーバ上にHeroku的なモノを作ることが出来るOSSだ。業務として人からお金をもらってマジメに作るアプリケーションならHerokuやAWSを使うけど、趣味レベルなら十分戦える。

詳しくは、さっき書いたアドベントカレンダーの記事をどうぞ。

qiita.com

おわりに

そこそこの量のデータがあり、また止まっても別に困らないけど自分でも欲しいなと思える練習用の題材として、なかなか良いテーマだったと思う。

また、このAPIを作るにあたって、スクレイピングと著作権についても調べてみた。

it-bengosi.com

上の記事を読んだ感じだと、以下の項目を満たす限りは大丈夫そうだ。(法律に関する知識のない自分の解釈なので正確性は保証できず。)

  • 利用規約への同意を経た会員登録・ログイン等をせずに見られるコンテンツで、クローラに対する制限(robots.txtとか)が無いこと。
  • 情報の複製が情報解析目的であること。
  • 取得した情報をそのまま配信するのではなく、自分で分析して再構成したものを提供していること。

今後も楽しく便利な趣味アプリを作っていきたい。

運が悪すぎる問題

通学は高専専用の通学バスを利用したり車を運転していったりするし、バイトはリモートなので家や学校でやってるしで、公共交通機関を利用する機会は月に1回や2回あれば良いくらいだ。そして、これは「気の所為」とか「たまたま」で片付けられる話ではあると思うのだけど、僕が公共交通機関を利用するととにかく災害や悪天候による乱れに巻き込まれる。

f:id:mktakuyax:20181205214329p:plain

これは9月の台風のときの写真

まずは今年の3月に旭川で行われた複雑系マイクロシンポジウム。前日に移動を始めたのだけど、その日がちょうど大雪で大変な事になった。JRの特急券を払い戻して高速バスに1時間くらい並び、なんとかしてたどり着いたけど、二度と冬に遠出はしたくないなと思った。

mk-nikki.hatenablog.jp

さらに、9月の電気学会。1日目の9月5日は、ちょうど台風21号で道内が大変なことになっていた。幸い僕は午後からの学生ポスターセッションに出る予定で、その時間までには間に合う感じで電車が復旧してくれたけど、帰りも何故か電車が死んでいて、2時間くらい都市間バスで立ちっぱなしだった。冬じゃないし遠出でも無いのになんでこんな目に遭わなきゃいけないんだ、と思った。そして、次の日に大地震が来た。

mainichi.jp

で、今回の内定者イベントだ。金曜日の午後からの日程なので、午前中の飛行機で行けば十分間に合う予定だったのだけど……このとおり。早めに教えてくれたので木曜夜の便に振替したけれど、行けたはいいが帰れない、なんてことにもなりかねない。 

f:id:mktakuyax:20181205213355p:plain

本当に運が悪すぎる。そういや先日のうみさま飲みの時もすごい事になっていた気がするな。今年に入ってから、公共交通機関を利用したタイミングはほとんどこういうのにぶち当たってるかもしれない。冗談抜きで。別に怒ってもしかたがないので怒ってるわけでも、ましてや鉄道会社や運行会社に怒ってるわけでもなく、ただただ愚痴を書き連ねてアドベントカレンダーのネタにしようというだけなのだけど、どうしてこうも運が悪いのか。

とりあえず、こんな事を言っていても仕方がないし、内定者イベントはめちゃくちゃ楽しみなので、行けない・帰れないなんてことにならないことを祈りつつ、やっていこうと思います。

慣れについて

さっき久々に父に会って*1、彼が使っているiPhone 7 Plusのアレコレをしていたのだけど、iPhone Xの画面に慣れた目で見ると「え、iPhone X対応してないのこのアプリ」みたいな気持ちになってしまった。

初めてiPhone Xを触った時は、「え、なにこれ、気持ち悪い。」という印象だったのに、慣れというのはこわいものだ。

振り返ってみると、Twitterのふぁぼがいいねになったのも、iPhoneからイヤホンジャックが消えたのも、MacBook Air 2013からMacBook Pro 2016にしたらキーボードがパタパタになって変なバーがついたのも、全部慣れて(諦めて?)受け入れてしまっている。変わった時は、「なんだこれ!前のヤツ返せ!」って思っていたのに、今となっては、逆に古い方をもううまく使えないレベルになっている。

こんな感じの話は、rebuild.fmのEP185でnaanさんが語っていたなぁと思い出すなどした火曜日の夜であった。

http://rebuild.fm/185/#t=00:14:59

*1:複雑な事情とかではなく、単に最近道内外のいろいろなところで仕事をしている。時によって群馬だったり仙台だったり埼玉だったり砂川だったりするのでいちいち覚えていない。

iOSで使うブラウザをChromeからSafariにした

今までiOSデバイスでは、macOSと同様にChromeを使っていたのだけど、Chromeをやめて標準のSafariを使うことにした。

理由はいろいろあるが、一番の理由はChromeから記事をShare Extensionを用いてシェアする時に、リンクしか渡してくれない事だ。

Webブラウザで今見ている記事をTwitterにシェアしたいとしよう。Safariだとこうなる。

f:id:mktakuyax:20181130134956j:image

一方Chromeだとこうなってしまう。

f:id:mktakuyax:20181130135014j:image

OGPタグ等のデータが適切に設定されているWebサイトなら、URLを貼っただけでTwitterがいい感じに解釈してリンクを使ってくれるが、そうでないWebサイトだと、単なるURLのみシェアする事になって、わかりにくい。

f:id:mktakuyax:20181202183137j:image

他にも、これはGoogleではなくiOSの問題だが、Safariならワンタップで開けるものをChromeだとわざわざ長押しして開かなきゃいけなかったり、Safari以外ではまだPWAが使えなかったりとか、いろいろある。なんだかんだ言って、デフォルトが最強なのだ。

Safariに乗り換えて3日くらい経つけど、今の所不便していないので、このままいっちゃおうと思う。なお、MacではふつうにChromeをデフォルトブラウザにしている。

mktakuyaアドベントカレンダーをやります

憧れの自分アドベントカレンダーを、今年はやってみようかなと思っています。

adventar.org

今日は苫小牧高専アドベントカレンダーの記事を書いてたら力尽きたので、明日から本気出します。

基本的には自分一人で書いていこうと思っていますが、すでに何人か登録してもらっているように、なにか書きたい事があればぜひ書いていただければと思います。

目指せ完走!

#本当にひどい実験 実施報告書

※この記事は苫小牧高専アドベントカレンダー2018 1日目の記事です。

f:id:mktakuyax:20181001122518j:plain

ロットネストアイランドの海。記事とは全く関係ない。

はじめに

今回は、情報科学・工学系第3学年で行われた #本当にひどい実験 の実施報告を書いていく。思ったより長くなったので、興味がない人は最後の「#本当にひどい実験 クソツイグランプリ2018」だけ読んでもらえればと思う。

#本当にひどい実験 とは

#本当にひどい実験 とは、Twitterのハッシュタグである。苫小牧高専 創造工学科 情報科学・工学系3年の情報科学・工学実験Ⅱにおいて、後期6週分の日程で行われた「セキュリティ」というテーマの実験のハッシュタグとして使用された。

twitter.com

最初は僕やツイ廃の3年生達が悪ノリでハッシュタグをつけてツイートしていただけなのだが、2週目には実験を行っていた教室(a.k.a.ダンス部部室)のホワイトボードに「#本当にひどい実験」と書かれていたので、公式(?)なのかもしれない。*1

優秀な学生はこちらの意図に気づき、ハッシュタグを用いて実験や教材に関するフィードバックを書き込んでくれていた。頂いた意見をもとに来年度以降、同じ研究室の後輩である専攻科1年のてっぴーくんや未来の土居研の学生がなんとかしてくれるはずだ。

実験の目的と内容

今回の実験の目的は、IoTセキュリティに関する基礎知識を習得することである。そんな感じのことを実験指導書に書いた気がする。

実験では、僕の専攻科特別研究のテーマ「IoTセキュリティに関する教材の研究開発」のもと開発している、「IoTセキュリティに関する教材」を使用した。この教材は、IoTカーと実験指導書、スライドや補助用の資料から構成される。

IoTカーとは、Raspberry Piを搭載したラジコンカー的なモノである。このIoTカーには、操作用のWebアプリケーションが搭載されている。前進・後退、右左折といったラジコンカーとしての基本機能から、IoTカー搭載のWebカメラを利用した写真撮影機能、撮影した画像の管理機能(ユーザ名・パスワードによる認証付き)といった機能を持つ。

ちなみに僕が開発したのはIoTカーに搭載されているソフトウェアや指導書等の教材であって、ハードウェアそのものは某社から買ったものだ。某社の人曰く、「オモチャを作って各高専に配ったらmkくんの卒研になっていた。」とのこと。

f:id:mktakuyax:20171126220738j:plain

IoTカーの外観。前後左右に走行可能な筐体に、Raspberry Piとモータドライバ回路等が搭載されている。

このIoTカーには、プログラムの不具合や設計ミス、設定の不備などが原因となって発生したセキュリティ上の欠陥、つまり脆弱性が埋め込まれている。これらの脆弱性を発見・修正することによって、攻撃者の立場からIoTセキュリティについて学ぶことができるというのが、この教材のアピールポイントだ。今回の実験は、その初運用も兼ねていた。実験の担当教員はshigyo先生で、僕はTAとして実験のお手伝いをしつつ、教材の評価を行っていた。

実施結果

今年度の実験は、10月11日(木)から11月15日(木)まで、毎週木曜日午後に以下のような日程で行われた。2週間を1つの区切りとして、3つの小テーマに分け、実験レポートも、2週間に1通の提出とした。なお、実験は2人1組で行った。

1〜2週 Raspberry Piのセットアップと動作確認、PythonによるIoTカーの制御

最初の2週間では、Raspberry Piそのもののセットアップと動作確認を行った。作業内容としては以下の通りだ。

  • 配布したmicroSDカードへのOSイメージの書込み
  • SSH接続の設定
  • 基本的なUNIXコマンドの確認
  • PythonによるIoTカーの制御(モータの制御、カメラの制御など)

OSイメージのダウンロードがめちゃくちゃ遅くて大変だった。教室に設置された1つのルータで20台以上のPCを捌くんだから、そりゃそうだ。また、SDカードへの書込みも、展開前のzipファイルをそのまま書き込む人がいたりした。

また、PythonによるIoTカーの制御も、班によって達成度にかなり差があった。

3〜4週 PythonによるWebプログラミング、操作用アプリケーションの設置と設定、動作確認

次の2週間では、Webで動作するIoTカー制御プログラムを買いたり、操作用Webアプリケーションのセットアップと動作確認を行った。

  • Apacheのインストール
  • サンプル用HTMLの作成と確認
  • 1〜2週目で書いたIoTカーの制御プログラムをWebアプリとして移植する作業
  • Webアプリケーションの設置、動作確認

こちらは、1〜2週目で感覚を掴んでくれたのか、躓く学生は少なかったように感じた。ただし、GPIOやカメラを扱うためのRPi特有の設定や、ドキュメントルートに配置するファイルのパーミッションとか、UNIXの扱い方的なところでハテナマークを浮かべる学生がいたのもまた事実だ。

5〜6週 脆弱性の発見と修正

最後の2週間では、脆弱性の発見と修正を行った。最後の2週間にして、やっとセキュリティっぽい話が始まった。

  • セキュリティに関する簡単な講義
  • Webアプリケーションに埋め込まれた脆弱性の発見
  • IoTカーそのものの脆弱性の発見
  • 脆弱性の原因の調査と修正方法の提案
  • 可能であれば、脆弱性の修正

まず最初に、セキュリティに関する簡単な講義を行った。スライド資料は僕が用意し、講義はshigyo先生がしてくれた。スライドには、これまで扱った要素技術とIoTカーそのものについての説明に加えて、これまでに起きたセキュリティに関する有名な事件とその原因、対処方法についての説明、課題のヒントの説明を行った。

課題は、IoTカーに埋め込まれた脆弱性を発見し、原因の調査と修正方法の提案を行うというものだった。前述したスライドを配布し、課題の文章にもキーワードを散りばめておいたので、だいたい自力で発見をしてくれていたようであったし、そうでない学生も段階を追ってヒントを与えていくとなんとか答えを見つけてくれているようだった。

所感

IoTセキュリティといいつつも……

IoTセキュリティに関する教材といいつつも、埋め込まれた脆弱性はWeb寄りなものが多かった。ハードウェア的な脆弱性もあるにはあるのだが、正直言って物足りなかったと思う。実験後に実施したアンケートにも、「IoTカーである必要がよくわからない」と書いていたが、全くそのとおりだ。

せっかく自動車の形をしているのだから、自動車に関するセキュリティの事例をもっと研究して、教材にもその要素を盛り込むべきだった。RPi 3にはBluetoothモジュールが載っているので、そのあたりを使ってみても良いのかもしれない。まぁ、ハードウェアの要素を入れると実験の難易度はだいぶ跳ね上がると思うけど、そこはどうにでもなる。

学生にとってはじめての事が多すぎる

今回対象となった3年生が持っている授業や実験で得た知識は、せいぜいUNIXコマンドの基礎とC言語の基礎くらいだ。一方、今回の実験で扱ったような要素技術を列挙してみると、こんな感じだ。

  • Linuxサーバの構築
  • ApacheによるWebサーバの構築
  • HTMLによる簡単なWebページの作成
  • Pythonによるプログラミング
  • PythonによるGPIOやWebカメラの制御
  • リレーショナルデータベースとSQL
  • Webアプリケーションにありがちな脆弱性

正直、これだけの要素技術を初めて扱うものとして6週間の実験に詰め込むのは無理があると思う。課題やレポートでは、これらについて理解していなくても、「さらっとでも触れて、こういうものがあるんだと知ってくれれば良いよ〜」くらいの難易度にしたつもりではある(実際、コードを書くような課題はほとんどサンプルコードのコピペで済んでしまう)が、それでもこんなに新しい事が次々と出てこられては、戸惑う学生も多かっただろう。

この実験は授業や実験でコードを書く経験を積み、RDBやHTML等の要素技術についてもサラッと習った4年生や5年生になってからやったほうがいろいろ楽しめて良いかなとも思う。とはいえ、まぁなにか新しい事をするとなったらやっぱり学科再編後の人達向けになるだろうし、4年生からはコースが分かれてしまうので、タイミングとしては3年後期のこのタイミングしか無かったのではないかと予想している。(もちろん、カリキュラムを決める権限は僕にはないので憶測でしかない。)

とりあえず一通り体験してもらえたし、何よりみんなでワイワイやるのは楽しい

セキュリティに関する実験とはいえ、セキュリティ以前にまず普通にモノを作ったり、環境を作ったりした事が無い人たちがほとんどだろうから、この実験の前半はそういう経験を積んでもらうことに重点をおいた。

これまでの授業だと、教員や技術職員さんが用意してくれた環境の上で課題のプログラムだけ書くという体験しかしてこなかったはずなので、ゼロから体験してもらおうという意図だ。たぶんわかってる人は勝手に進んでいったし、わからない人は、実験書に書いてあるコマンドをよくわからないまま書き写して、それっぽい結果が返ってきたら次へ進むという感じだったと思う。

今回扱った要素技術については、これから進級して授業や実験で扱ったり、資格試験の勉強で体系的に学ぶことが出来ると思う。また、今回の実験をきっかけにRPi買うなりVPS借りるなりして趣味や自学として触れることもあるだろう。その時に、今回手を動かしてそれぞれの技術に触れたという経験が生きてくると良いなと思っている。

肝心のセキュリティに関しては、「こうするとこうなる」とか、「こういう脆弱性がある」くらいは体験してもらえたと思うので、今回ですべてを理解していなかったとしても、今後なにか自分で作る時に思い出すきっかけになれば良いんじゃないかなと思っている。

そして何より、3年生の皆さんと一緒に実験するのがとても楽しかった。僕が気づきもしなかったような事に気づいてフィードバックをくれたり、実験の進行を助けてくれたりして、とても助かった。3年生の皆さんは学科再編後の第1期生ということで、こういう事には慣れているというか、もう飽き飽きしているかもしれない。しかし、今後もこういう事は続いていくと思うので、引き続き活躍(?)してほしい。

今後

第1回目の運用は終了したので、僕はこれからこの結果を卒業論文にまとめるつもりだ。また、皆さんから頂いたフィードバックを元に、てっぴーくんが来年度以降の実施に向けて教材の改善を行ってくれるはずだ。

そのへんの話は、おととい公開した樽前FM EP17でてっぴーくんとお話させて頂いたので、そちらも合わせてどうぞ。

tarumaefm.com

#本当にひどい実験 クソツイグランプリ2018

もう長い文章をダラダラと書くのは疲れたので、 #本当にひどい実験 というハッシュタグ付きのツイートの中でも、特に僕がおもしろいと思ったものを3つ紹介して、この記事を終わりたいと思う。

おわりに

以上で、#本当にひどい実験 実施報告書は終了とする。

この教材の開発について電気学会の全国大会で発表したところ、優秀ポスター賞をもらうことができた*2。さらに、この実験の実施報告(マジメなやつ)を書いた論文の査読が通れば、査読付き論文デビューだ。これから研究者としてのキャリアを進んでいくつもりは特に無いのだけれど、それでも「専攻科2年間、ただ遊んでただけでは無いんだぞ!」と言える程度には業績を残すことが出来たっぽいので、それはそれで満足かなと思う。

担当教員のshigyo先生、その他アドバイスをしてくださった情報工学科の先生方、そして何よりも、実験を受けつつフィードバックをくれた情報系3年の皆さん、本当にありがとうございました。

明日は #本当にひどい実験 の本当の首謀者である @shigyo先生の担当です。

*1: "本当にひどい○○" の元ネタはたにったさんとない子さんがやっていた飲み会のハッシュタグ #本当にひどい飲み会 である。

*2:優秀ポスター賞 受賞者 | 電気学会 電子・情報・システム部門