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

フツーって言うなぁ!

フツーなサラリーマンのフツーな嘆き.

ネットワークスペシャリストになれました

勉強

というわけで,3度目の正直というやつで合格できました.

情報セキュリティスペシャリスト(SC),データベーススペシャリスト(DB),ネットワークスペシャリスト(NW)試験の3資格に合格することは,自分の大学院生時代の目標でしたので,2年遅れでようやく達成できたことになります.

せっかくですので,合格までの経緯を軽くまとめておきたいと思います.

2014年秋試験

ウチのブログのアクセス解析を見てみると,こちら↓

lethe2211.hatenablog.com

の記事が一番閲覧されているようなのだが,この年のNW試験は午後2が4X点という特に残念でもない点数で落ちてしまっており,「ネットワークスペシャリスト試験を受けてきた(合格できたとは言っていない)」という状態が長く続いていた*1

2015年秋試験

また,去年も試験を受けてきたわけだが,この時期はちょうど仕事の忙しい時期と重なってしまって勉強時間が十分に取れなかったのと,午後2で完全に問題選択を誤り,5X点*2で落ちてしまった.

2016年秋試験

そこで,「今年は一念発起,気合い入れていこう!」となったかというと,そうでもなく…

2016年8月上旬

特にネットワークについて継続的に勉強していたわけではないが,「受かるまで受け続けよう」という謎のやる気はあったため,せっせと申し込む*3
この時期に海外出張があり,その準備等があったため,この時点では特に何もせず.

9月

謎の開発案件が降ってきて仕事が忙しい日が続いたが,ちょこちょこ午後試験の過去問を解きはじめる.
3回目ということで,過去問もある程度やり尽くしてしまっている感があり,どちらかというと解に至るまでのプロセスの確認と,解いていく上での疑問点の解決に注力した.

以下,使った問題集.

ネスぺの剣25 ~ネットワークスペシャリストの最も詳しい過去問解説 (情報処理技術者試験)

ネスぺの剣25 ~ネットワークスペシャリストの最も詳しい過去問解説 (情報処理技術者試験)

ネスペ 26 道 ?ネットワークスペシャリストの最も詳しい過去問解説 (情報処理技術者試験)

ネスペ 26 道 ?ネットワークスペシャリストの最も詳しい過去問解説 (情報処理技術者試験)

受験者の中でも評価の高いネスペシリーズ.
過去問(午後試験)1年分について非常に詳しい解説を施してある.
個人的に,「なぜその解答になるのか」だけでなく,「なぜその解答以外の解答にならないのか」についての反駁が行われている点がよいと思う.
反面,基礎技術についての解説書ではないので,その点は他の本などで追いついておく必要がある.

情報処理教科書 ネットワークスペシャリスト 2016年版

情報処理教科書 ネットワークスペシャリスト 2016年版

前年までの2年間で,そもそもネットワークについての基礎が足りていないと感じていたので新たに購入,したのだが…,どちらかというと過去問から見た視点での要素技術の解説に終止していた印象.
体系的に知識を得るための資料が欲しかったので,少し購入目的とズレてしまっていた感はあった.

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

これも名著として有名.
こちらは試験対策本ではなく,ネットワークの基礎技術についての解説本.
ユーザがブラウザからURLを叩いてHTMLが返ってくるまでを旅に例え,それぞれのレイヤで何が行われているのかを詳しく解説している.
分量はあるが,わかりやすさを気にかけているのか,非常にすいすいと読み進められた.
これを読んだからといってすぐに問題が解けるようになるわけではないが,体系的に勉強がしたいのであれば読むべきだし,副読本としての使い方も十分にアリだと思う.

以下,参考にさせていただいたサイト.

www.infraexpert.com

NWの試験範囲について,必要最小限な分量での解説が施されている.
ある程度ネットワークの知識がある人なら,ここを見てある程度知識をつけた上で過去問演習をすればなんとかなってしまうのではないかと思う.

10月

このあたりから,午前試験対策を始めた.
といっても,特に参考書等を買ったわけでもなく,過去問をやるだけ.
今年は午前1免除が失効していたため,午前1についても勉強する必要があったが,結局3〜4年分解いてイケそうなことを確認できたのでやめた.

試験当日

午前1

試験終了の時間を間違えて焦ったが問題自体は普通に解けた.

午前2

午前2は試験範囲が非常に狭く,過去問さえ覚えればほぼ同じ問題しか出ないのでいつも印象に残らない.

午後1

無線LANは勉強していなかったので問1,3を選択.
なんとなく近年はメール送信に関する出題が増えてきている気がした.
手応え的には7割程度.

午後2

昨年同様,問題選択に窮したが,直前にIPsecの勉強をしたのでえいやで問2を選択.
結果的にはこれが正解で,結構ヤマが当たった.
帰った後自己採点してみた結果的には6割5分ぐらい*4

結果

f:id:lethe2211:20161223133749p:plain

うひぃ,ギリギリ…

反省点

そもそもなぜ3年もかかってしまったのか.

  • 広範囲な知識の必要性
    そもそも,試験範囲がなかなかに広い. OSI参照モデルの7層全てとその周辺技術から出題があり,ネットワークが本職のエンジニアであっても,すべての内容についていくのは困難なのではないだろうか. 最初に過去問に当たったときに感じた,「どこがわからないのかわからない!」という感覚は,単純な暗記量の少なさによるものだったのではないだろうかと,今になって感じる.最悪正規化とERモデリングだけできればなんとかなってしまうDB試験,コクゴができれば短期間の勉強でも合格できるSC試験と比較しても,学習曲線が非常に緩勾配で,長期間の根気強い勉強が必要となる気がした. 午後試験を大きく分類すると,レイヤ3以下(スイッチ,配線に関する出題)と,レイヤ3以上(主にIP,DNS,HTTPなどの技術に関する出題)に分かれているので,どちらかにヤマを張って勉強するのはアリだと思う.

  • 新技術への対応
    上に関連するが,ネットワーク周りの技術は進歩が目覚ましく,NW試験でも様々な要素技術が出題されている. 情報処理技術者試験は,多くの人にとって初見の内容を扱う場合,既存の知識を応用して解けるように問題が設計されているのだが,そのあたりで知識の底の浅さが露呈してしまっていた. また,少し前の試験ではよく出題されていたIP電話の問題が減った代わりに情報セキュリティに絡めた出題が増えるなど,数年で出題傾向も変わっている. NW試験の過去問だけでなく,SC試験の過去問に手を出してみるのも有用かもしれない.

  • ネットワークについての知識・実務経験不足
    これは試験そのものというより自分の問題. 学生時代もWeb系の開発経験はあり,現職もアプリケーションエンジニアではあるが*5,ネットワークについて体系的に学ぶ機会がなかった. 学生時代のプログラミングというと,(実サービスとしての運用でもしない限り)「動けばおk」というものがほとんどであり,「Webのチュートリアル記事を見てそれをそのままコピペした」といったものがほとんどであった. また,現職でもネットワーク担当の仕事とアプリケーション担当の仕事は分業されており,「権限管理」の名のもとにネットワークを直接的に触る機会はほぼない*6. この手の勉強には実機を触るのがいちばんよいのだろうが,その機会に恵まれなかったのが一因だと思う. 最近であれば仮想環境上にネットワークを構築するのも以前より難しくなくなってきたらしいので,少しずつそういう学習も進めていければいいと感じた.


次は何を取りましょうかねぇ…*7

*1:地味に「ネットワークスペシャリスト」でググると上記記事が検索上位に出てきてものすごく恥ずかしかった

*2:適当に埋めた部分が多かったが,問題そのものが結構難しかったのか,採点は甘めに感じた.情報処理技術者試験では,合格率調整のための得点調整は結構なされる(と思われる)ので,問題が難しいと思ってもやはり諦めてはダメだと思う

*3:余談だが,早く申込みを行うと現住所に近い会場に行けるという噂があるので,申し込むならできるだけ早い方がいいかもしれない

*4:個人的にはイーサネットのMTUを勘違いしていたのがつらい

*5:現在の上司氏はアプリケーションエンジニア出身だが非常にネットワークに強く,その点でも頼られている.このような,「もう一つの強み」を持てることがエンジニアとしての市場価値の向上につながっていると感じる

*6:さわるコマンドと言えばせいぜいpingとdigとnetstatぐらい

*7:友人からも「資格マニア」と呼ばれるようになってきていますw

Web APIプラットフォームの設計をやってみた

設計

お久しぶりです… また4ヶ月放置してしまいました.

現在関わっているプロジェクトで,Tech LeadとしてイチからWeb APIプラットフォームを1本書く,ということをやっています. 初めての経験だったので,いろいろ回り道もありましたが,なんとか軌道に乗りそうなところまでは持っていけたかと思います.

メモとして,やったことと今考えていることを残しておこうと思います.参考になれば幸いです.

業務要求

あまり詳しいことは書きませんが,現在開発中のAPIは,いわゆる決済業務系Web APIとして,主に社内のサービスから使われることを想定しており,かつそこそこの量の秒間リクエストが来ることが想定されます. 最終的には,現在稼働中のAPIを置き換える形で,開発したAPIプラットフォームを使うことを目的としています.

議論の結果,今回の業務要求として,

  • 最低5年程度は現役で使い続けられること
  • 知識の乏しい開発者が短い時間でAPI開発を始められること
  • 運用が比較的スムーズにできること
  • トラフィックをスムーズにさばけること
  • 障害に強く,復旧も早いこと
  • 他サービスからの利用が容易であること(API利用者が容易に開発を進められること)
  • セキュリティ対策ができていること

といったことなどが挙げられました.

ちょうど,エンプラ系のガチガチのシステムと,スタートアップなどの「とりあえず動けばなんでもいい」ようなシステムのちょうど中間,ぐらいのイメージでしょうか.

アーキテクチャの検討

業務要求を受け,これを具体的な設計に落とし込んでいくことを行いました. いろいろ悩んで議論したのですが,最終的にはこんな感じになりました.

  • URL設計においては最近流行りの(?)RESTfulアーキテクチャを採用する
    • 既存APIではRPCを採用していたが,似た挙動をするAPIが乱立する,そのAPIが参照系なのか更新系なのかがわかりにくい,といった問題があった
    • RESTfulを採用した結果,URLが宣言的になり,リクエストを見るだけである程度何をするAPIなのかが明確になるというメリットがあった.反面,URLのパス設計が難しくなったのと,ログを設計する際に,どのパスがどのAPIに対応しているのか何らかの形で保持しておく必要がでてきた
  • URLについては,主流のWeb APIにならってバージョニングを行う
    • 度重なる業務要求の変更に対応するため
  • リクエスト,レスポンスの形式にはXMLJSONを用いる
  • WebフレームワークにはSpring Bootを用いる
    • 実績,ノウハウ面からJVM言語(というかJava)を開発言語として使うことは最初から決まっていた
    • 自分としては,将来Scalaを使用することを見据えてPlay Frameworkを使いたかったが,Playにはまだ枯れていない部分があることと,これまでの実績があったことからSpringを選ぶこととなった
  • 将来のマイクロサービス化を見据え,(パッケージ構成も含め,)サービスはできるだけ疎結合に保つ
    • 現状はまだ開発の1stフェーズであるというところと,マイクロサービスアーキテクチャがどこまで流行るかが未知数ということから,一度ひとつのデプロイ可能jarで作成し,いつでもサービス分割が可能な形を保つこととした
  • キャッシュにはRedisを用い,キャッシュ層はサービスとして分離する
    • インメモリKVSならなんでもよかった
    • Redisを使用したのは,実績があるのと,ドキュメント類が充実していたため
  • DBは変更の対象外とする
  • Docker+Kubernetes+JenkinsのCI/CD環境を用いて,開発者はコードをGitリポジトリにpushするだけでデプロイまでが自動で行われるようにする
    • アプリ側としては,開発環境に依存する設定項目をできるだけ減らし,(DB接続情報などを除き)環境間での差分を最大限減らすことを目標とした
  • ログに関しては,Elasticsearch+Fluentd+Kibanaでの集約,解析を可能にする
  • Junitによる自動ユニットテスト,Cucumberによる自動end2endテスト,SonarQubeによるコードカバレッジ測定など,テストとそれに関連する機能についてはできるだけ自動化を行う

全体的に,「Web系にしてはオーソドックスだなぁ」という構成にはなっているかと思います. 人の出入りが激しく,自分もいついなくなるかわからないので,とにかく「わかりやすさ」を重視したつもりです*1. そういった制約の中でも,Dockerをベースとした運用環境など,「イケてるしこれからもしばらくは使われそうなもの」については,積極的に導入するようにしています.

今後検討したいところ

  • 不正利用の検知,将来のデータ分析に向け,独自のクライアント認証システムを導入する
    • OAuth2など,一般に使われる認証,認可アルゴリズムの適用も考えていたが,今後,社外からAPIをコールされるようになる可能性がかなり低く,多くの場合クライアントにとってこういった作業は手間となるため,見送ることとなった
  • ドキュメントの構成管理
    • 既存のAPIは,ドキュメントをPowerPointなどで作成しており,ドキュメントが散逸する,仕様変更の反映がなされないなど,構成管理に大きな問題があった
    • できれば,ドキュメントはソースコード中のJavadoc等と同期させるようにし,開発者の責任で適宜更新させるようにしたい
    • もっとできれば,ドキュメントとAPIのテストページをまとめてしまいたい*2
  • Dockerコンテナベースでのローカル開発環境の構築
    • 「俺の環境では動く(動かない)」をゼロにしたい
    • まだ検討中
  • 障害対応の方法
    • まだノウハウが足りない
  • 開発フローの構築
    • 開発チケット起票からリリースまでをどう進めるのがよいか
    • ブランチ戦略,ChatOpsなど
  • 他プロジェクトメンバへの教育
    • 特に,Spring自体への理解を深めることと,網羅的なテストケースの作成方法を理解することが必要
    • 最低限,どの開発者も,サービスロジックとコントローラ,そのそれぞれのテストを自力で書けるレベルまでには持っていきたい

こんなところでしょうか. やってみて思うのは,実際に業務で開発されるAPIには大きな制約が課されるということです. 特に,今回のAPIは想定ユーザが多く,いちから基盤を作り直すということだったので,5年後,あるいは10年後を見据えた形での開発が必要でした*3

機会があれば,もう少し実装寄りの部分の解説をしたいと思います.

ではでは.


以下,参考にした本.

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

*1:現状,開発者のレベルもマチマチなので,「保守され続ける」ことを考えると,こういった構成になるのもやむを得ないかと思います

*2:REST APIでは,Swaggerなどのツールで実現できるようだ

*3:チャレンジングではありましたが

最近読んだ本を晒しとく

書評

お久しぶりです.
4ヶ月近く放置してしまいました…

とりあえずリハビリとして,読んだ本の感想とかを適当に並べてお茶を濁しておきたいと思います.

「Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)」

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

業務で既存のAPIを設計からリニューアルすることになったが,その過程での先輩とのディスカッションで,

先輩「どうせなら今時のイケイケなRESTful APIにしたいよね」
ぼく「あーRESTfulですね.はいはいあのRESTfulか…」

こんな感じで会話を終えた後,すぐにAmazonを検索して,名著との評価のあった本書を読むことに決めた.

タイトルだけからだと非常につかみにくいが*1,本書は,

  • 最初にWebの歴史について触れた上で,
  • HTTPの仕様とURI,HTML,JSONなどの関連技術について説明し,
  • 現時点でのWebサービス設計のベストプラクティスとされるRESTについての説明と実際の設計手法につなげる

形で論を進めている.

基本的な計算機科学とWebの知識を持っている人がWebサービスを作っていくにあたって,どのようにリクエスト/レスポンスのインタフェースを設計していけばいいのか迷った時に本書は適していると思う. また,具体的なソフトウェア(Webフレームワークなど)の実装には(歴史の説明は除いて)全く言及しておらず,非常に普遍的な視点から知識を得ることができると思った.

Junit実践入門 ~体系的に学ぶユニットテストの技法~」

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

これも,同じ案件でJunitをがっつり書く機会ができたので,ベストな方法論が知りたくて買った.

今まで「なんとなく」ユニットテストを書く機会はあったが,どのような観点でテストケースを作成すればよいのか,作成した各テストケースをどのようにクラスタリングすればよいのかについては,自分の中でまとまったものがなかった.

本書は,「なぜユニットテストを書くのか」といった基本のところから,テスト技法の紹介,4フェーズテスト(事前準備 -> テストクラス実行 -> 結果の検証 -> 事後処理)についての説明と来て,実際にJunitの機能の説明に移る.
ここまででも,今までなんとなくテストを書いていた自分には学びがあった.

機能説明の後は,テストダブル(いわゆるスタブ,モック),カバレッジについての説明から,TDDやBDDの説明が進む.
この辺については,抽象的な説明が続き,巻末の実例集を見ても,あまり実感がわかなかった.

全体的に見て,Junitの解説書としては十分な出来だと思う.
これに加えて,Mockitoの解説記事をいくつか読めば,現在のJunitを用いたシステムテストについてはほぼおさえられるのではないだろうか.

「どんどん話すための瞬間英作文トレーニング」

どんどん話すための瞬間英作文トレーニング (CD BOOK)

どんどん話すための瞬間英作文トレーニング (CD BOOK)

相変わらず英会話力に不安を抱えているのだが,最近特に気になるのが,「英語での発話(返答を含む)開始までにかかる時間」.

もともとコミュニケーションには不安があり,日本語でも「あの,えーとですね…」からしか会話を始められない私だが,英語での会話だと,それにさらに2-5秒の「言いたいことを英語に変換する時間」が追加される.
こうなると,複数人の会話に入っていけないのはもちろん,一対一の会話ですら,相手に話し続けられてしまってコミュニケーションにならない.
この時間を短縮したいと思ったのが本書を買った動機.

本書に記載してある例文と対訳は,どれも中学英語で見たことのあるものばかり.
しかし,いざこれを「3秒で訳して発音しろ」と言われると,なかなか表現が出てこない.
また,「それっぽい」表現が出てきたとしても,"Does"になるべきところが"Do"になってしまっていたり,"more smarter"なる謎英語がでてきたり,自分の中に正しい英語を落とし込めているとは言いがたい.
「まず,中学英語レベルの表現を問題なく(素早く)引き出せるようになってから,英文法書にあるような例文を練習すると良い」というようなことが本書のまえがきに書いてあり,「なるほどな」と思った.

とりあえず2周ぐらいしてみたが,まだまだ英語ペラペラは遠いと感じる.

*1:本書をちゃんと題するなら,「HTTPとRESTアーキテクチャ」が正しいように感じる

声優ハッカソンに行ってきた

雑記

2/27,28に楽天株式会社主催で行われた,「声優ハッカソン」に行ってきました.

rakutenwebservice.doorkeeper.jp

apps.rakuten.co.jp

このハッカソンの売りは,「声優さんの声を自分たちの作ったアプリに使える」ということ.

自分もアプリを開発したことは何度かあるのですが,一素人が「声優さんに声を当ててもらえる」という機会に恵まれることはなかなかなく,声素材を集められずにアイデアを断念する,といったこともそれなりにあったように思います.

このハッカソンなら,声優さんにあんなことこんなことを言ってもらうことができる!

「これは参加するしかないだろう」ということで,妄想膨らむ大学の同期と参加を決めました*1

作ったもの

声優ハッカソン20160227 チーム16(Blind Busters!!)中間発表スライド / レテ さん - ニコナレ

自分たちのチームが作ったのは,「ブラインドバスターズ!」という,「声優さん演じる妖精ちゃんの指示を聞きながら見えない敵を倒していく」アクションゲーム.

最初に議論を進めていくうちに,スイカ割りに着想を得て,「声優さんに指示を出してもらって,その気持ちいい声を聞きながら楽しめるアクションゲームがあれば面白いのではないか」という話になりました.

例えば,前から敵(プレイヤーには見えない幽霊)が襲ってくると「右によけて!」って指示してくれる感じ.

ハッカソン前から,デザイン面,ゲーム性の議論など,少しづつ準備をすすめ,本番に望みました.

感想

「声のプロである声優さんに時間をいただいて,こちらの欲しい音声を収録してもらえる」というのは,開発者冥利に尽きるものがありました.

正直,声が入っているか否かで,アプリとしての完成度が5倍は違いました.

また,ハッカソンそのものとはあまり関係なくてアレですが,声優さんの生声録音の現場に立ち会わせてもらうことができたのが本当にいい経験でした.

収録直前に出した原稿にもかかわらず,こちらが指示したキャラ設定をちゃんと考えて,ほぼ一発撮りでセリフを撮り終えてしまう声優さんの凄さに感動しました*2

残念だったのは,プレゼン中,PCからの音声の出力ができずに,アプリのデモができなかったこと.

こんなケアレスミスでせっかくの機会をフイにしたのは初めてで,正直クソがつくほど悔しかったです.

後で再チャレンジの機会をいただきましたが,「事前の接続チェックは大事」という,プレゼンの基本を痛感させられました*3


僕のレベルの低い質問にも嫌な顔せず答えてくれたチームのみなさん,このような素晴らしい機会を与えて下さった主催の方々,そして,音声を収録していただいた菅沼千紗さんをはじめとする,今回ご協力いただいた声優のみなさま,本当にありがとうございました!

*1:決して声優さんと写真を撮りたかったとかそういうのではないです

*2:その後,余った時間で仕事についても少しだけお話させてもらいました.噂には聞いていましたが,声優,厳しい職業なんですね…

*3:受賞を逃したことよりも,やったことを出しきれなかった不完全燃焼感が自分の中であまりにも許せなかったので,再チャレンジタイムに真っ先に手を挙げました.その瞬間,たしかに「自分にもまだこんな情熱が残ってるんだ」と感じ,それに関してだけは自分を褒めてやりたい気分です.

いろいろ新調した

雑記

働き始めて初めて「ボーナス」なるものをいただいたので,前から欲しいと思っていたものをちょいちょい買っています. 体組成計とか,カジュアルコートとか,キーボードとか*1

Majestouch MINILA US67キー 茶軸 FFKB67M/EB

Majestouch MINILA US67キー 茶軸 FFKB67M/EB

組成計については,とりあえず己の身体の今の状況を知るようにするだけでも,健康的に生きようと思えるかな,と思って買いました. 「定期的に体重測るだけでも痩せる」って言いますし.

キーボードについては,今までは,Windows機向けに3k特価品のワイヤレスキーボードを使っていました. 別にそれに不満があったわけではなかったんですけど,ちょっとサイズが大きかったのでコンパクトなものが欲しかったというのと,仕事で使ってるMBAのUSキーボードとできるだけ配列を揃えてストレスを減らしたいな,というのがあって,買い換えることを決めました*2

あとは,タブレット端末を買ってみたいのと,髭剃りを新調したいのですが,なかなかいい感じのものが見つからず,保留しています. こういうのって,悩む時間も結構楽しいんで別にいいんですけど!

*1:小市民なので10万以上する買い物とか旅行はなかなか実行できないレテです.お金も貯めたいですし

*2:あと,皆が使ってる高級キーボードってそんなにいいモノなのかというのを確かめてみたいという気持ちも

昨年のまとめと今年の抱負

雑記

あけましておめでとうございます(遅

最近,目標を持ち続けて暮らすというのは非常に難しいことなんだと痛感しております. 年のはじめぐらいは何か新しいことを始めようという気になりたいですね.

去年のやつ↓ lethe2211.hatenablog.com

去年のまとめ

1月

修論に向けて実験していた. 自分の実験は被験者を使うタイプのものであるため,やり直しが効かないので少しつらかった.

Code Thanks Festivalの入賞祝いに焼肉会に連れて行ってもらった. 東京の焼肉はレベル高いと思った.

2月

修論提出と発表. 最後の2週間程度は研究室に数日泊まりこんでは風呂に入りに帰る生活だった(実験の結果は出ていたので,字数を埋める&英語に直すという作業を続けるだけ). 発表会ではボコボコにされたが,最終的には高評価をつけていただいた.

3月

研究室の連中+αと,イタリアに卒業旅行に行った. ヴェネツィアフィレンツェ,ローマという鉄板ルート. 期間が1週間だったので,他の国にも行きたいという話があったが,1つの国の都市をまわるというのも楽しかった.

4月

東京に引っ越し,今の会社に入社した. 全体研修は面倒な課題が多く,総合職の人たちとの人間関係にも馴染めなかったが,開発研修に入ってからは,自分が好きな開発ができて結構楽しかったと思う. 「もっと英語勉強しないといけないな」と痛感した.

5月

引き続き研修. 同期とも少し仲良くなって,飲みとかリアル脱出ゲームとか行ってた.

6月

第2希望の部署に配属された. 希望の部署ではなかったが,大規模トランザクションを扱う部署で,今はそこそこ気に入っている.

7月

特筆すべきこと無し.

8月

オフィスが引っ越しになって,徒歩通勤になった.

9月

特筆すべきこと無し.

10月

Pycon JP 2015に行った. さすがにPythonのカンファレンス,データ解析系の講演が多く,ツールや方法論など,ためになった.

11月

友達と1泊2日でGoのハッカソンをした. 私の友達は技術力の高い連中ばかりで,全員初修の言語であったにもかかわらずある種の劣等感を感じつつも励みになった.

大学の学園祭を見に京都に戻った. バイト先の人達と久しぶりに喋れてよかった. 住んでいた時は「住みにくい」とか京都を散々ディスってたけど,また行きたくなった.

12月

学会発表でオーストラリアに行った. 質疑応答に全く答えられなかったことは本当に残念だったが,いい経験になったと思う.

今年の抱負

今年の抱負は「正直に生きる」にしたいです.

これは,他人にも,自分にも嘘をつかないということです. 他人になんとなく(悪意なく)ついた嘘が人を想像以上に苦しめてしまったり,自分への嘘・ごまかしで生きることが苦しくなってしまったり. 失望されても嫌なやつになってもいいから,正直に自分の気持ちを表現することが,人間関係構築の第一歩なのかな,と最近強く感じるのでした.

国際学会AIRS2015に参加してきた

研究 雑記

気がつけば前に記事書いてから3ヶ月経ってました…
文章を書く習慣をつける目的でブログを続けてきましたが,一度途切れるとやる気が無くなってしまうの,本当に良くないですね.

本題.
修論の内容をまとめた論文が国際会議に通ったので,有給取って参加してきました.

今回参加したのは,AIRS2015という会議.
"IR"という文字が示す通り,情報検索系の研究が中心の国際会議で,オーストラリアのブリスベンで開催されました.

AIRS2015

以下に参加記を記しますが,会議メモというよりは,ほぼ旅行記だと思ってもらえれば.

  • 1日目(移動日)

幸いにも,成田<->ブリスベンは今年の8月から直行便が出ているらしく,そちらで向かうこととなった.

f:id:lethe2211:20151206155743j:plain

  • 2日目(会議初日)

会議当日5時*1ブリスベン国際空港着というなかなかのきついスケジュール.
とりあえずホテルに荷物を預け,会場のクイーンズランド工科大学に向かった.

f:id:lethe2211:20151206155929j:plain f:id:lethe2211:20151206155947j:plain

f:id:lethe2211:20151206160001j:plain ↑会場

現地は夏だと聞いていたので,半袖のTシャツも持って行ったが,25度ぐらいのちょうどいい気温.*2

f:id:lethe2211:20151206160042j:plain

会場付近でしばらく時間を潰していると,会議がスタート.

最初のキーノートセッションは,量子力学の考え方を,情報検索における適合性の考え方に導入しようという試みについての講演.
正直,よくわからなかった…

この日の昼に自分の発表があった.
内容は,検索エンジン結果ページ(SERP)の改善について.

f:id:lethe2211:20151206160029j:plain

発表自体はトチらずに終わらせたが,英語での質疑応答があまりにもできず,質問者に日本語で話させるという,国際学会ではありえない失態を犯してしまった.

↑つらい

その後のポスターセッションでは,大きなスクリーンに圧倒されながらも,お酒を飲みながら,つたない英語でポスターやデモの話を聞いていた.

f:id:lethe2211:20151206160219j:plain

f:id:lethe2211:20151206160232j:plain f:id:lethe2211:20151206160241j:plain

  • 3日目(会議2日目)

この日最初のセッションに,2つ目のキーノートがあった.
検索における正解集合(テストコレクション)をどのように作っていくか,という話.
現在の情報検索の研究は,従来の「適合」「非適合」といった単純なものではなく,検索者の様々な要求に対応する必要があり,それに応じて,テストコレクションの方も,評価者の専門性を考慮したり,ユーザのごとの視点の違いを取り入れる必要がある,とのことだった.
こちらは,内容的にも自分たちの分野と近く,比較的聞きやすかった.

あとは,自分の発表が終わったこともあり,のんびりと発表を聞きつつ,後輩とお昼休みに外に出て,大学の近くを流れるブリスベン川を眺めていたりした.

f:id:lethe2211:20151206160508j:plain f:id:lethe2211:20151206160521j:plain

会場の大学で見つけた面白いもの.
ポスターセッションでも使われた大きなモニタに,重力や元素への理解を深めるための(?)タッチパネルを使ったゲームや,果ては,全く関係ないブロック崩しができたりする.
どこに金をかけてるんだろう大学というよりまるで科学館のアトラクションのような展示だった.

f:id:lethe2211:20151206162044j:plain f:id:lethe2211:20151206162055j:plain f:id:lethe2211:20151206162109j:plain

この日のセッション終了後には,バンケットという形で,ブリスベン川を遊覧するディナークルーズがあった.

f:id:lethe2211:20151206160550j:plain f:id:lethe2211:20151206160615j:plain f:id:lethe2211:20151206160623j:plain f:id:lethe2211:20151206160636j:plain f:id:lethe2211:20151206160646j:plain

  • 4日目(会議最終日)

この日もセッションを聞きつつ,ちょこっと抜け出してコアラ見に行った.

行ってきたのは,ブリスベン郊外にある,Lone Pine Koala Sanctuaryという動物園.

Lone Pine

f:id:lethe2211:20151206161038j:plain

日本では珍しい動物のコアラだが,この動物園はコアラの保護区になっているらしく,そこら中コアラだらけで,もはやありがたみが薄くなるレベル.

f:id:lethe2211:20151206160845j:plain

また,コアラを抱いて一緒に写真を撮ることができる場所があり,もふもふのコアラを抱いたまま引きつった笑顔で写真に撮られていた.

コアラかわいい.けど結構重い.*3

他にも,カンガルーに直接触れられる場所があったり,カモノハシ見れたり,カラフルな鳥に餌をやるイベントがあったり…
ブリスベンに来る機会があれば絶対に行くべきスポットだと思う.

f:id:lethe2211:20151206160919j:plain f:id:lethe2211:20151206160941j:plain f:id:lethe2211:20151206160953j:plain f:id:lethe2211:20151206161004j:plain f:id:lethe2211:20151206161012j:plain f:id:lethe2211:20151206161019j:plain f:id:lethe2211:20151206161028j:plain

ブリスベンの町並み.
観光地って感じはしないけど,キレイで普通に良い街だと思う.

f:id:lethe2211:20151206165811j:plain f:id:lethe2211:20151206165815j:plain

市街に戻ってきた後は,tukka restaurantという,地球の歩き方に載ってたレストランで夕食.
メニューにはカンガルーの肉やエミューの肉なんかもあって,せっかくだし食べようと思ったけど,直前で日和ってアヒルを食べてしまった.
これ,たぶん後で「食べとけばよかった」って後悔するやつだな…

f:id:lethe2211:20151206161142j:plain

その後は,Queen Street Mallという,ブリスベンの中心街をブラブラしたり,カジノに行ったりしていた.
後輩氏はスロットで掛け金を2倍にしている中,わずか3分で10$を擦り,自分にギャンブルは向いていないと再び痛感.

f:id:lethe2211:20151206161219j:plain ↑カジノ

それまでは,会場とホテルを往復するだけだったが,この日は結構観光できて楽しかった.

  • 5日目(移動日)

帰りの飛行機は朝早く出発だったので,出発後特に何かすることもできず空港まで直行.

おみやげにワインとお菓子を買って,飛行機に乗った.
飛行機内で見た,「ミッション・インポッシブル」の新作と,「夜は短し歩けよ乙女」*4が面白かった.

f:id:lethe2211:20151206161309j:plain

夜は短し歩けよ乙女 (角川文庫)

夜は短し歩けよ乙女 (角川文庫)


こんな感じです.

国際会議への出席は2回目ですが,口頭発表したのは初めてだったので,質疑応答がつらかったですね.
もっと英会話うまくなりたいです.

学会について. 採択率はfull paperで32%(29/92)と,そこまで高くない会議です.
発表者がポスター・デモ発表含めて40人程度と,あまり規模が大きくなく,すべてシングルセッションで聞くことができるため,「発表をする/聞く場」としてよくできているな,という印象でした.
著者同士のコミュニケーションもわりと活発だったので,初めて行く国際会議としては結構いいところだと思います.

こういう学会に出るたびに,自分も何か研究続けたくなりますね…

*1:時差があるので日本的には早朝4時

*2:結果的に半袖は不要だった

*3:オーストラリアの中でも,地域によりルールが異なるらしく,コアラを抱けるのは実質この動物園だけらしい

*4:行く前に買った