日々精進

aikoと旅行とプログラミング

builderscon tokyo 2019に参加してきた #builderscon

先日開催された,builderscon tokyo 2019へ参加してきた.

builderscon.io

buildersconは

buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。buildersconではトークに関して技術的な制約はありません、特定のプログラミング言語や技術スタックによるくくりも設けません。

(引用:https://builderscon.io

と書かれているように,特定の言語やフレームワーク等に縛られないテックカンファレンスです.縛りがないので,開催する二日間で様々なジャンルの話を聞くことができ,まさに「知らなかった,を聞く」というテーマにピッタリのカンファレンスとなっている.

以下,参加して気になったセッションの内容と簡単な感想を述べたいと思う.

ランチセッション「キーボードは好きですか?」

speakerdeck.com

自作キーボード,最近よく聞くようになりましたね.秋葉原には遊舎工房というお店もできたぐらい.

yushakobo.jp

今回は,我々が普段使っているキーボードから自作のコアな話まで50分間たっぷり聞くことができた.日本語でこれだけまとまっている資料が他にあるだろうか. ちょうど最近USキーボードに移行しようとしており,新しいキーボードをめちゃくちゃ迷ってるタイミングでの発表だったので,非常にタイムリーだった. 正直キーボードのスイッチがあんなに深いものだとは思っておらず…軸の名前(赤軸とか)は聞いたことあったけども,こんなに種類や特性があるんだなという学びを得た.

で,発表していたのが以前インターンしていたときに隣の席だった id:foostan だった.というのも,このセッションはfreeeがスポンサードしており,freeeで自作キーボードといえばfoostanなのである.

muttan1203.hatenablog.com

↓の記事が面白いのでぜひ

developers.freee.co.jp

コンパイラをつくってみよう

speakerdeck.com

DQNEOさんの発表.なんと,ライブコーディングで簡単なコンパイラを作成するというもの.

  • Go言語を使う
  • 加減算を行い,評価した値でexitする
  • アセンブリを標準出力に吐き出すことで実現

というものだった.この発表はすごく良くて,1ステップずつ出来上がる過程をみることができるし,機能が追加される毎に会場では拍手が起こり,ワイワイしながら発表が進んでいった. 途中実行がエラー担った際は,客席から間違った部分の指摘が飛んできており,実質ボディビルの掛け声だった.エラーが起こっている行数を教えていた人,人間コンパイラだった.

DQNEOさんが学んだ教材は,有名なruiさんの8ccらしい.

github.com

今だとchibiccというものがよさげかも

github.com

コンパイラ作成は長い道のりになりがちで,モチベーションをどう保つのかという質問もあった.確かに難しすぎると途中で心が折れてしまいそうである.その点,chibiccは

この本では、コンパイラの説明の難易度が急に上がりすぎないように、様々なトピックを本書全体を通じて次第に掘り下げていくという形で説明することにしました。その理由は次のとおりです。

と書いてあるように,これまでのものよりはとっつきやすいのかもしれない.

www.sigbus.info

非同期処理の歴史から見たコンピューティングの進化

speakerdeck.com

ついつい避けがちな非同期処理の話題.正直自分も正しく答えられるかというと,自身がまったくない. 今回は,歴史的経緯も踏まえつつ,どのように非同期処理が進化してきたかという内容だった.最初の方に出てきたRunnableによる非同期,昔Androidアプリを 書いたときに使っていたなあなどと思いだして懐かしくなっていた.

もちろん文法レベルでどうやって書けば非同期処理が実現できるかがわかるのも大事であるが,それ以上にどのようにしてソフトウェアが動作しているかを意識しなければ ならないと感じた.最近書いているものは正直そのあたりを意識して書けていない(本当は意識しないといけないのだけども)ところもあり反省点である.すごい情報量の資料 なので,もう一度読み返したい.

Optimizing Ruby with JIT - 最速の言語を目指して

speakerdeck.com

Ruby 2.6.0から導入されたJIT(Just In Time)コンパイラ.この発表では,JITコンパイラによる高速化をどのようなアプローチで進めていったのかといったことを聞くことができた. 正直,RubyJITコンパイラが入りますよと言われたときはそこまで関心がなかったのだが,今回この発表を聞くとその見方も大きく変わってくる. 様々なアプローチをコードの例を提示しながらステップバイステップで最適化されていく様子は見ていてとてもワクワクした.

今回の資料ではないが,こんなものもある

speakerdeck.com

レガシーサーバーを現代の技術で再構築する

speakerdeck.com

社内で使用されてきた機能モリモリのレガシーなLinuxサーバを,現代の技術を使って再構築していく話.fujiwaraさんはISUCONの方で何度も 見ている人で,実際の発表を見るのは初めてだった.

Redmine, SVN, Git, IRC, Gyazoなどのサービスが1台のLinuxサーバに構築されており,そのシステムは4年周期ぐらいで手が加えられて行ったそう. 今回がちょうどその周期になっており,実際に一つ一つ改善していった点が紹介されていた.

ついついやらなければいけないことから考えがちであるが,まずは「やらないこと」というのを明確に定義したあとにやっていくことを決めて 行ったのが印象的だった.ついついいろいろなことに手を付けがちなものだが,原状を正しく把握してやることを整理できる力というのはかなり 大切であるように感じた.

それにしてもサーバが1台しか存在しなくて,それが結構な頻度で使われておりあまり落としたくないという状況下の移行は大変そう…というお気持ちに. いかにうまく移行するかがエンジニアが頑張るポイントで,更にコスト計算等も考えられるようになりたいねと思った.

入門サービスメッシュ

speakerdeck.com

マイクロサービスやその周辺の技術に疎い自分ですら最近良く見かけるサービスメッシュというワード.サービスメッシュのサの字もわからないので,これを機に 入門しようということで聴講.小さなアプリケーション同士が連携し合うことでサービスを提供するマイクロサービスアーキテクチャを採用した際に生まれる

  • Service Discovery
  • Fault Isolation
  • Observability
  • Authentication
  • Access Control

あたりの処理をいい感じにやってくれるソフトウェアぐらいは掴むことができた.そしてそれを実現するために,EnvoyであったりIstioが存在しておりどのように使用 されているのかも雰囲気を感じることができた.しかし,周辺知識が不足しすぎていたので,途中からだんだんわからなくなって来ており勉強不足を痛感した.

そもそもサービスメッシュの話をする前に,マイクロサービスだと何が辛いねんみたいなところがしっかりわかっていなかったところがある.でも今回自分で調べて 見たりして少しずつつかめてきたのでよしとしたい.

まとめ

テックカンファレンスはなにか特定の言語やフレームワークに限定されたものは多く開催されているが、Buildersconでは普段自分が聞かないような分野やコミュニティの 人の発表を聞くことができて、非常に充実した二日間であった。

特にDQNEOさんのセッションが印象に残っていて、あそこまで会場に一体感のある発表というのは初めてだった。すごいスピードでコンパイラが出来上がっていく過程というものを 体験することができたし、機能が追加されていく面白さみたいなものを感じることができた。

楽しかったと同時に、自分が何も知らないということを痛感した。「知らなかった、を聞く」なのである意味狙い通りとも言えるが、この先エンジニアとしてやっていく と考えると、もう少し色々考えて動かなければならないなとも感じた。でも楽しいと思えたからいいでしょう。来年から社会人、がんばっていきたいですね。

なお,本イベントに参加するにあたって,Classi株式会社のスカラシップに採用していただき,移動費と宿泊費を負担していただいた.

classi-scholarship.connpass.com

Classiは、教育におけるICT活用の重要性と今後の一層の高まりを見据え、 ベネッセとソフトバンクの強みを生かして、学校教育、家庭学習の両方の領域で、 最新のテクノロジーも活用しながら、未来を生きる子供たちに よりよい学びを提供できるよう新たな教材・サービスの開発に取り組んでまいります。

https://classi.jp/corporate/より引用)

とあるように,新しい教育の姿をテクノロジーとの掛け算で追求している.教育系×テクノロジーという組み合わせにピンときたかたは, 直接アポイントをとってみたり逆求人等を利用することでより詳しい話が聞けるだろう.今後も学生向けのスカラシップは実施していくとの ことだったので,要チェック.

スカラシップ制度,地方に住んでいて金銭的にも都心に出るのが辛い学生にとっては本当にありがたい制度である.buildersconは去年から行きたいと思っていた イベントだったので,今回その夢を実現させることができてよかった.重ねてお礼申し上げます.

PyCon Kyushu 2019 Okinawa 参加記

f:id:bath_poo:20190522231337j:plain

5/18(土)に開催されたPyCon Kyushu in Okinawa 2019に参加してきた。 kyushu.pycon.jp Pythonめちゃくちゃ書く人かというとそうではないが、最近身近にPythonの機運が高まりつつあったり、Python2あたりで止まっている自分の知識のアップデートも兼ねて参加することに。 普段福井にいる学生が沖縄まで行くのは辛いのでは?という話だが、ありがたいことに遠方支援という制度があり、そのおかげで参加することができた。ありがとうございます。

以下聞いたもののメモです。

Python Webフレームワーク比較

Python超初心者の私は、聞いたことがあったフレームワークDjango, Flask, Zopeぐらいなものだった。この3つも含めて全部で9個のフレームワークを比較するというセッション。Webフレームワークに求められる機能は非常に多岐にわたり、フレームワークによってその実装度合いもまちまちである。求められる要件に応じて、適切にフレームワークを選択する必要がある。

もちろん求めている機能が実装されていることは非常に大事だが、そのフレームワークを使っていく上で、それに関する知識やノウハウといったものがどの程度蓄積されているか、周囲の知識レベルなども非常に大切な要素であると感じた。

Pythonにおける並列処理プログラミング

slideship.com Pythonで並列/並行プログラミングをする話。毎度並列と並行がごっちゃになる人間なので、セッションが始まる前にちょっと復習した記憶。 Python(正確にはCPython)にはGlobal Interpreter Lock(GIL)の制限があるため、複数のスレッドを生成しても実際に実行できるスレッドは1つに限られている。

Pythonでの開発を効率的に進めるためのツール設定

Pythonを使った開発を便利にするためのツールの紹介。ここで聞いたツールたちを後々の発表で聞くこともあった。手元の環境(例えばエディタであったりjediなどのコード補完)もそうだが、linterやformatterなどを使うことでチームでのPython開発をより良いものにしようという強い意志を感じた。「クオリティは人力であげるものではなく、機会に頼っていこう」というところに強く共感した。

ところで、import文をソートするという概念に初めて出会った。importを入れ替えて動かなくなった場合、そこに依存関係が発生しているからどうにかしたほうが良いというお話のようだった。

試行錯誤のための Docker 活用術

Dockerについての最低限の知識を持った状態で聞いていたので、流石に最初の方はわかる、となっていた。DockerはJavaという強い言葉をきいた。

データアナリスト側としては、

  • 様々な方法(ツール)を簡単に試行できること
  • 環境の再現が容易であること

のような環境があるととても嬉しくて、そういう要件にコンテナがとっても良いよというお話。環境の再現性やポータビリティといったものに関してはDockerを始めとするコンテナは非常に有用である。今nvidia-dockerとかあるんだなー、という気持ちになった。MLOpsに対する興味が湧いてきた。

開発環境の垣根を超えるLanguage Server Protocol入門

最近聞くことが増えたLanguage Server Protocolのお話。エディタとかの補完を実現するために使われているとかとか。エディタとLanguage Server間をJSON-RPCで通信することでその機能を実現しているとのこと。Pythonはもちろん、他にも70種類ほどの言語で実装されているらしい。

LSPってマイクロソフトが関わってたのをここで初めて知った。 microsoft.github.io

Pythonと型ヒントとその使い方

Type Hintsは関数の戻り値の型や引数の型といったものに対して型注釈(アノテーション?)することができる機能である。あくまでアノテーションであって、型の検査等はされない。主に静的解析用途と考えたほうが良さそう。適切な補完を出すためにも書いておくと良いし、この話はPythonでの開発を効率的に進めるためのツール設定でmypy話をしていたときにも出てきていた。ただ開発者陣は「あくまでPythonは動的型付け言語であり、Type Hintsは必須の機能にする気はない」とのこと。

Type Hints登場時から歴史をたどって(PEPをみながら)進んでいってとてもわかりやすかった。

まとめ

Pythonに関する勉強会やコミュニティといったものに初めて触れましたが、1日楽しくまた大変勉強になる知見をたくさん得ることができました。Pythonといえば今Machine Learningの分野で多く使われておりそちらよりの発表が多いのかと思いきや、Web寄りの内容も多く楽しむことができました。今後Pythonを使用する際に参考にさせていただきたいと思います。スタッフの皆さん、参加者のみなさんお疲れ様でした!

余談

PyConも楽しみましたが、人生初の沖縄も少し楽しむことができました。海綺麗すぎませんかね? f:id:bath_poo:20190522230951j:plain 三枚肉そばも f:id:bath_poo:20190522231056j:plain

MSPJマイグレーションコンペティション2019 winter 参加記 #mspj

f:id:bath_poo:20190120225016j:plain

2019年になってから一発目のイベント、MSPJマイグレーションコンテスト2019に参加してきた。

マイグレーションコンペティションとは

そもそもマイグレーションコンペティションって何?という方のほうが多い気がする。

mspj.jp

日本MSP協会(MSPJ: Managed Service Provider's Association Japan)が開催しているコンペティションで、すごく簡単に言ってしまうとシステムをマイグレーションする(移行する)コンテストなのである。タイトルそのままなので説明になっていない気もするが…。

このコンペティションにはある特徴があって、参加するにあたって「開催当日に30歳以下であること」が必須の条件とされていることである。募集ページの言葉を引用させていただくと、

日本MSP協会コンペティショングループは、運用技術を競うコンペティションを開催し、 次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目指します。

ということで、比較的若いエンジニアがターゲットとなっていることが挙げられる。私もまだ比較的若いので(?)参加してみようということに。

このコンペティションの面白いところとして、システムマイグレーションだけではなく顧客とのやり取りや報告書の作成等も含まれるところである。完全に移行し、かつ顧客とスムーズにやり取りする力、資料作成まで見込んだスケジューリング感なども求められるコンペティションになっている。

前日まで

お題については事前に公表されており、

connpass.com

非常にざっくりとではあるもののどのようなシステムを移行する必要があるのかを感じ取ることはできる。お題は

お題:いま動いている文書システムを新しい環境に移行して欲しい

とのこと。システムに関しては、

  • Amazon Web Servicesで動いていそう
  • バージョンが古めのCentOS
  • ミドルウェアApachePythonGitが含まれていること
  • 移行先がMicrosoft Azure

程度の状況はわかっている。バージョン古めのCentOSはどうせCentOS6.xだろうなーとか、 AzureやったことないしVM立てるぐらいはやっておかないとなーと思っていたら、イベントの1週間前ぐらいからひどい風邪を引いてしまいずっと倒れていた。つまり、コンペ当日まで何もできていなかったのである。こういうのは付け焼き刃の知識では良くないので、もっと計画的に前から作戦を練ろうという気持ちになった(来年への課題です)

当日

今回(も?)会場は品川にある日本マイクロソフトだった。品川駅を降りて港南口からでて右折までは成功したものの、その後さまよい続けて結果10分ほどロスをするはめになった。ビル沿いに並んでるのかと思いきや、少しマイクロソフトのビルだけ入り口が奥にあったので気づかずにスルー(伝われ)

f:id:bath_poo:20190120224934j:plain
いい景色

10:00から開会式と聞いていたが、前に書いた通り迷子になっていたので到着が9:50ぐらいになった。すでに会場にはそれなりに人がいて、皆様結構到着が早めなのね…などと思っていた。知り合いがひとり来るのは知っていたがまだ来ていなかったようなのでコミュ障地蔵になって椅子に座っていた。

開会式

開会式が始まる。みんな静か。めっちゃ静か。自分も静かだったので申し訳ない。もうちょっと反応したほうが絶対いいよねって思いました、自分も含め。でもみんなお金が欲しいことだけはすごくわかりました(自分もそう)

今回のお題が発表される。Gitで管理してる文書サイトをAWSからAzureに移行しましょう!というお話だった。また、文書のビルドにはJenkinsを使っているとのことだった。このときJenkinsを使ったことがない、というかCIツールを使ったことがない私は(これやばいんじゃない…?)という気持ちでいっぱいだった。他にも顧客からの要望が来ていて、

  • 今の環境を新しい環境に完全移行して欲しいです。
  • 実施した内容と結果については報告が欲しいです。
  • システムを止めるときは利用者に告知が必要なので連絡が欲しいです。
  • 昔から使っている古い環境なので、バージョンアップして欲しいです。
  • できれば利用者に影響を出さないように切り替えたいです。
  • できればサーバに関する資料があるとありがたいです。
  • できればバックアップを取れるようにしたいです
  • できれば今後は利用者が増えるのでシステムを冗長化したいです。
  • できれば引継ぎするために必要な情報がまとまっていると嬉しいです。
  • 体制変更で、システムが分かる人がいなくなってしまいました。
  • いいタイミングなのでリフレッシュしたいなと思っています。
  • 商売は続いているので、できるだけ利用者さんに影響が少ないと嬉しいです。
  • 本当はいろいろとナウっぽいこともしていい感じにしていきたいんですよ。

と大変盛りだくさん。完全に移行ができた上で、この要件を満たせると+ALPHAの加点となるようだった。

そして最後にチーム分け。今回は実務経験年数が4年以上とそれ未満で分け、4年以上の人たちが各チームに一人以上はいるようにチーム分けが行われた。このコンテスト、参加者がほぼ社会人なので、実務経験が0年の私はとにかくチームメンバーの足を引っ張らないかどうかが心配で胃に穴が開きそうだった。1列に並んで、前から1〜9の番号を読み上げていきまた1〜9まで読み上げるという小学生ぶりのチーム分けを行い、Team5(Tさん(社会人), Oさん(社会人), 私(学生))ということになった。いよいよ10:30から開始である。

コンペティション最中のお話

10:30〜11:30

ここからはTさんのまとめた資料をもとに書いていく。資料をちゃんと書いていると、コンテスト後の参加記が書きやすくなります(そういう用途ではない)

まずは、顧客の要求を「やらなければいけないこと(MUST)」と「やるべきこと(SHOULD)」に分けるところから始まる。上に載せたもののうち、

  • 今の環境を新しい環境に完全移行して欲しいです。
  • 実施した内容と結果については報告が欲しいです。
  • システムを止めるときは利用者に告知が必要なので連絡が欲しいです。
  • 昔から使っている古い環境なので、バージョンアップして欲しいです。

については必ず実施しなければいけない。これが完了した上で、残りの項目を達成できるように行うべきであるという認識を一致させた。これについてはTさんがGoogleSpreadsheetにすべてまとめてくれており、最後までこれを見失わずに進むことができたと思う。

やらなければいけないことがわかった上で、それぞれのスキルや経験等をもとに役割分担を行った。リーダーのTさんは、顧客に提出する資料を書きつつ残りチームの舵取り役、Oさんは移行先環境(Azure)のセットアップ、残る私は現在の環境について調査を行うことになった。

調査をしていくと、

  • 今回は配信しているものに関しては静的コンテンツしかない
    • PHPMySQL等は存在しない
  • OSはCentOS6.9
  • WebサーバはApache
  • GitPythonは予告どおり
  • Apache, Gitリポジトリ, Jenkinsなどがすべて1台のインスタンスで稼働している
  • コンテンツはmkdocsを使ってビルドされている

ことがわかった。これらを調べているうちに、横でOさんがVMを立て終えていて(社会人のお二人手際良すぎでは…)と思うなどしていた。

また、副次的にわかったこととして、

  • Jenkinsのログを見ていると、大量のWARNINGがでている
  • Jenkinsで走っているジョブの動作
    • /var/lib/jenkins/mkdocs/docsへ移動
    • git pullで変更をとってくる
    • /var/lib/jenkins/mkdocs/へ移動
    • mkdocs build
    • ビルドされた/var/lib/jenkins/mkdocs/site//var/www/html/rsync

ということがわかった。どうもmkdocs buildするときに、Markdownファイル内に含まれる外字を表す画像を格納したディレクトリ(以下、外字ディレクトリ)が存在しないのでは?という警告だった。しかしページ自体は普通に表示されているので、とりあえず問題ないとして次に進んだ。

まだ午前中&チームを組んですぐだったので、めっちゃビクビクしながら話しかけていた。

11:30〜12:30

ここまでの状況を一度お互いに報告し、このあとの方向性を決めた。Tさんは現在やっている作業を継続、Oさんはバックアップの設定、私はデータの移行を行うことになった。

旧環境から新環境へは以下のファイルを移行させる必要があった。

  • コンテンツのリポジトリ
  • httpd.confやmkstyle.ymlといったコンフィグファイル
  • Jenkinsの設定ファイル

基本的にインスタンス関連のオペレーションは私とOさんがやっていたので、Oさんと相談しつつ「とりあえず全部rsyncを使って全部コピーしよう」という方針で決まった。Jenkinsの移行は、/var/lib/jenkinsをまるごとコピーした。1[GB]ぐらいあった。

このあたりで、リポジトリの奇妙な点に気づく。先程Jenkinsのログで大量のワーニングが出ていた事に気づいていたが、その原因が「.mdが参照している外字ディレクトリがリポジトリに含まれていないため」であることがわかった。その外字ディレクトリはどこにあるかというと、Apacheのドキュメントルート/var/www/htmlに置かれていた。つまり、人力で旧環境から新環境へ外字ディレクトリをコピーしない限り、いくら新環境でビルドしても外字がNot Foundになってしまうという罠があった。

画像ファイルが含まれていないことにこの段階で気づいたので, /var/www/htmlに関しても新環境にそのまま移行した. ここでこれに気づいていたのはラッキーだったと思う。

12:30〜13:30

ごはんもぐもぐ。ここになってやっとお互いの話を落ち着いてできるようになる。やはりランチ会っていいですね。出身の話をしたりとか、普段どんなことをしているのか、どんな会社なのかいろいろ聞きつつ楽しい時間を過ごすことができた。

13:30〜14:30

とりあえず移行が終わったはずなので、新環境でページが見れるかを確認した。午前の段階で、旧環境の/var/www/htmlの中身をコピーしてあるので, 正しく設定されていれば見れるはずである。結果、正しく表示されていた。このとりあえず動くというのはメンタル的にも大事であると今まで嫌というほど学んできたので、新環境で動いた瞬間を見たときは正直ホッとした。

この段階で,

  • とりあえずVMは稼働している
  • 22, 80ポートの疎通ができる
  • Apacheも動いている
  • 表示も正しそう(画像の欠損がないか、など)

は確認できていた。そして次取り組んだのはJenkinsの設定。まずコンソールを見ようと思って<host>:8080に何もでなかったので,

$ systemctl status jenkins
● jenkins.service - LSB: Jenkins Automation Server
   Loaded: loaded (/etc/rc.d/init.d/jenkins; bad; vendor preset: disabled)
   Active: failed (Result: exit-code) since 土 2019-01-19 02:26:14 UTC; 1h 37min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 864 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=1/FAILURE)

エーン。journalctlでみた結果、Javaが入ってないというだけだった。ログを見て速攻Oさんが気づき爆速でjdkインストールをしてくれた。今回思ったんだけど、私の曖昧な詰まり報告をきいて爆速で課題解決してくれるOさんがめちゃくちゃ頼もしかった。

そんな感じでJenkinsが復活した。旧環境から環境をまるごとコピーしたので、前の環境と同じようにログインし、もともとあったジョブを走らせたらコケてしまった。どうもjenkinsユーザーがssh失敗してるようだった。これは、

$ su -s /bin/bash jenkins
$ ssh admin@localhost

という感じでknown_hostsに突っ込むことで解決した(ビルド実行ユーザーはadminだったのでこんな感じになった)。この日初めて問題解決をし、多少役に立てたかな、という気持ちになった。

次は、mkdocs buildがコケるようになった。どうも使っているテーマ(見た目)がインストールされていないらしい。これまたOさんが爆速でpip installを決めてくれたおかげでビルドも通るようになった🎉

14:30〜15:30

JenkinsのログにBUILD: SUCCESSとでていた私たちは大喜びしていたが、冷静になってみるとその上にエラーが表示されている事に気づいた。どうもメール送信に失敗したらしい…

その後もう一度ジョブを走らせると、そのエラーが表示されなくなった。何だこれは…?と思ったが、とりあえず一度でもメール送信失敗したことは事実なので調査を行うことに。そこでOさんとTさんが「たしかAzureって25番ポートで他のメールアドレスに直接メール送信できなかった気がする」という話が出る。どうもAWSは25番、つまりSMTPサーバへの通信ができるが, GCPAzureはできないとのことだった。これOP25B(Outbound Port 25 Blocking)って言うんですね。だから前の環境ではこれで動いていたのか…となる。

これの解決策としてパッと思いつくのはSendGridを使うことなので、そちらの方針に切り替える。顧客に事情説明とSendGridを使う旨を伝え、移行作業に取り掛かった。またこちらもOさんが爆速でSendGridの環境を整えてくださり、私はJenkinsのConfig画面にユーザーとキーとSMTPサーバのアドレスを書くだけになった。

設定したものの何故かうまくいかない。結果としてはポートが25のままだった。他のポートに変更したら無事にメールが届いたため、メールの設定も無事に終了した🎉

同時に冗長化どうする?というお話にもなった。

15:30〜16:30

冗長化をどうしようかという議論が前の時間から続いていた。可用性セットとか可用性ゾーン、LBWAFとか?という話をしていたが結果どれも断念。LBの下に何台かインスタンスをぶら下げたとき、どうやってコンテンツ類を同期しようかという話になって、残りの時間を考えたときにこの変更は難しいということになって断念した。

また、CDNを入れてサーバの負荷低減や冗長化というところまでやったが、Jenkinsも同一サーバにいるためこちらも断念ということに。

これに加えて、セキュリティ的な対策も考えた。まず、DDoS等の不正アクセスを検知するためにAzure Monitorをつかってモニタリングを行った。5分間の平均CPU使用率が80%を超えるようなときにアラートが飛ぶようになった。この設定はOさんがやってくれていた。

あとこれが対策になるかはわからないものの、Apacheの基本的な設定を行った。どんなものかわからなかったので、とりあえず二人に相談し、「いいんじゃない?やってみよう。」とのことだったので進める。割とよくあるバージョンを隠そうねとかそんなやつなので、

  • ServerTokens ProductOnlyを追記し, レスポンスヘッダーに含まれるApacheのバージョンを非表示に変更
  • ServerSignature Offを追記し, エラー(NotFound)時にシステムの詳細が書かれたフッターを表示しないように変更
  • のOptionsからIndexesを削除し, <URL>にアクセスした際にファイル一覧を表示しないように変更

という感じをやった。これも一応報告書にも載せてもらえた。

このあたりで、顧客に対してDNSの切り替え要請を行った。

  • 16:30頃に切り替えて欲しい 
  • ページがダウンする可能性があるので、ユーザーへの通知を行って欲しい

の2点をお願いした。主にこのあたりのやり取りはTさん中心にOさんも行ってくれて本当に本当に助けられた。特にTさんは、VMいじってる二人がやっていることも気にかけつつ、必要と思われるコミュニケーションはどんどんとっていてありがたかった。

16:30〜17:00

いよいよDNSが切り替わる。見たところ正常に動作してるっぽい。とりあえず移行はできたことが確認された。

そして残りは納品資料の作成。と言ってもこの段階で9割ぐらいはできていて、あとは手直しやtypoの修正というぐらいだった。Tさん有能過ぎでは。

そして1分前ぐらいに提出して終了。こう見るとギリギリだったけど、やっている側としてはそんなに焦ってやってはいなかったので良かったかな。3人共やりきったという感じでした。

懇親会

今回懇親会画像全然撮ってない。大量のアルコールがDeployされましたが、私は病み上がりなので緑茶を無限に決めていた。オードブルとかもでてきていい感じ。懇親会2hあって結構長いなーって思っていたら、その裏でジャッジが行われていたらしい。通りで運営チームの人を見かけないわけである。

一番最初に話しかけてくださった方が、いきなり私のTwitterの話し始めたの本当に面白かった(嫌ではない)。共通のフォロワーが何人かいたからね、しょうがないね。その流れで、その社から来ている方々ともいろいろお話させていただいた。今度ご飯食べいこうねというお話もした。

29人中27人が社会人の方だったので、自分より年上だったりする方がおおかったりした。就活中なんすよ〜〜(ヘラヘラ)というムーブもした。自分も興味があったりする会社の人もいたりしたのでその方ともお話をした。

コミュ力トークスキルが低いので、懇親会は難しい。当日で一番難しかった。

結果発表

いよいよドキドキの結果発表。なぜならば、このイベントは入賞者に賞金が贈られるのである。今回から大幅に増額&受賞者が増えたということでみんなワクワクしていた。具体的に書くと1位が60万, 2位が30万, 3位が10万である。

3位から順に発表された。3位はなんと該当者なし。会場が???となる。まあもしかしたら同率2位とかそういうね、と思う。そして2位。2位もいない。更に???????となる。つまり今回移設成功していたのが1チームしかなかったのである。

この自体にレギュレーションが変更される。なんと1位が100万円全部もっていくことになった。会場がざわざわする。まさか100万円になるとは誰も思っていなかったんだろうね。

そしていよいよ1位の発表である。1位はなんと

f:id:bath_poo:20190120225107j:plain
まさかの
でした。というわけで優勝しました🎉

やはり移行が完全にうまくいっていたところはTeam5だけだったらしい。自分は「多分入っていても3位ぐらいでは」と思っていたので、3位が該当なしの時点ですでにあきらめムードだった。そんな中名前を呼ばれたので、最初は脳が混乱していた。

隣のTeam6は惜しくて移行まで行っていたけど、外字ディレクトリの移行にミスっていたため駄目だったらしい。結構シビアだなあと思うなどした。

感想

MUSTとSHOULDの話

今回は、資料もあまりないシステムが与えられてそれを別のパブリッククラウドに移し替えるというものだった。それに加えて、顧客からの要求もきており、そちらもできる限り実現して欲しいというものだった。

最初にも書いたが、やらなければいけないMUSTなことと、やってほしいSHOULDなことをしっかりと見極め、それをブレずに実践することの大切さを感じた。今回の課題に関しては、旧環境が新環境で完全に再現されている必要があった。これはMUSTな条件である。ナウいシステム構成にするのもいいが、それよりもまず満たすべきところをしっかりと満たせたのが我々の良かったところだと思う。チームメンバーの3人とも、同じ方向を向いて取り組めていたところも大変よかったと思う。

チームでうまいことやるのって難しい

f:id:bath_poo:20190120230531p:plain 今回は時間も結構限られていた。6h30mぐらいの中で、求められていることを確実にこなして資料まで作り上げなければならない。意外と時間があるようでなかったりするので、そのあたりのスケジュール感が適切でないと最後移行失敗ということになってしまいそうだなと思った。

自分はそのあたりが正直全然わからなくて、完全にTさんとOさんに任せっきりという感じだった。次出るときがあったら意見できるぐらいにはなりたいですね。

まとめ

10:30〜17:00という非常に短い時間で移行を行うのは、自分が想像していた以上に難しいものでした。しかし、それによって得られた学びも大きかったように感じられます。実務経験0の私には、得られるものが非常に大きなイベントでした。

あとははじめてのJenkins, はじめてのAzureって感じで。慣れないながらも試行錯誤できたかな、と。まだまだ精進が必要ですね。

まだ全然U30なので、来年以降も積極的に参加していきたいと思います。チームメンバーのお二方、運営のみなさん、そして参加されたみなさん、ありがとうございました。

2018年を振り返る

2018年も終わりですね

何でもかんでも「平成最後の」ってつければいいというものでもないですよ。2018年、前半のスカスカ具合に対して後半のイベントつまり具合が半端ない年だった。前半全然かくことないもんね。

1月

  • 1/1といえばaikoさんのnew year CMですね!!!!

  • 今年は福井県で初詣をする

    • 毛谷黒龍神社に行った
  • 当たり前ですが外は雪&雪
  • なにか例年と違う…そう降雪量がおかしい
  • 温泉に行く予定が延期になるレベルでドカ雪が降る
  • もりもり寿しは神
    f:id:bath_poo:20181223224504j:plain
    最高のエクスペリエンス

2月

  • 今年は卒論を書かないといけないというのに、雪がひどすぎる
    f:id:bath_poo:20181223225745j:plain
    雪がひどすぎるんじゃあ
  • 交通網が麻痺し、8号線が足止め状態となる

www.asahi.com

  • 同じ研究室のやつも、学校までたどり着けない状態になる
  • スーパーから物が消える
  • 道路も雪で埋まってしまう
  • 無事に卒論発表&提出を終える
  • ピクシブインターンシップをする

3月

  • クックパッドの1dayイベントに参加
  • 研究室紹介があったりとか
  • LLP20の開催が決定し一人で喜んでいる

4月

  • 研究室に後輩が入ってくるぐらいしか書くことがないぞ

5月

  • GWにかるめりに会ったきがする
  • 研究室の扉にDashボタンを付けて呼び出すボタンをつくる
  • 妻籠宿へいく
    f:id:bath_poo:20181223230034j:plain
    すごくいい感じ
  • 食中毒(カンピロバクター)になる
  • 名古屋でImageFluxのイベントに参加

6月

  • このあたりからサマーインターンとかの面接やらテストが始まる
  • 人生初の逆求人イベントへの参加
  • aikoが渋谷をジャック
    f:id:bath_poo:20181223230110j:plain
    道玄坂aiko
    • そこらじゅうaikoで最高だった
    • 道玄坂でストローがね
  • 6月ぐらいから渋谷にいく頻度が上がる
  • ギークフェスタに行った

7月

  • 人生初freee
    f:id:bath_poo:20181223230219j:plain
    しゃれおつ
  • LLP20 浜松公演に参加
  • そのライブの前に盲腸になる
    • ライブの2h前ぐらいまで点滴を打っていた
  • 結局翌週手術する。人生初手術
  • 逆求人参加(2回目)
  • LLP20 京都公演参加
  • SHISHAMO NO 夏MATSURIに行くために東京へ向かうも台風で中止\(^o^)/
    • 関東まで行って友達と飲むだけになってしまった

8月

  • ISUCON勢で温泉行って合宿
    f:id:bath_poo:20181223230746j:plain
    お部屋がきれい
  • 夏を感じる
    f:id:bath_poo:20181223230804j:plain
  • 日本酒がうまい
    f:id:bath_poo:20181223230822j:plain
    推しの酒造(松浦酒造)です
  • ダッカソン参加
  • かるめりと「デザインあ展」に行った
    f:id:bath_poo:20181223230252j:plain
    ア…ドモ…
    • 子供に混じって回転するかるめり

9月

muttan1203.hatenablog.com

  • git challenge参加

muttan1203.hatenablog.com

  • アドテクコンペ参加
  • これが生まれた
  • ISUCON

    f:id:bath_poo:20181223230319j:plain
    さわやか

  • 研究室合宿的なもの

    f:id:bath_poo:20181223230359j:plain
    メェェ

  • Google Cloud Nextに行く

    f:id:bath_poo:20181223230704j:plain
    会場がでかい

  • くまの会合が初開催

    f:id:bath_poo:20181223232556j:plain
    牛タンシチュー、美味しいに決まっている

10月

  • AbemaTV Developer Conference参加
  • 人生初はぴおしゃをする
  • LLP20 滋賀公演
    f:id:bath_poo:20181223230603j:plain
    外観が好き
  • 久しぶりに京都を観光するも人が多すぎてキレた
    f:id:bath_poo:20181223230620j:plain
    渡月橋で写真をとると高確率でカップルが映り込む
  • 新卒採用が本格化する

11月

  • LLP20 大阪公演
    f:id:bath_poo:20181223230544j:plain
    例の階段
  • 夜行バスは俺には無理だと悟る
  • 面談or面接の嵐
  • また逆求人に出る
  • Bug Shooting Challengeに参加

muttan1203.hatenablog.com

  • AWS Loftに行く実績を解除
  • 今年もまた恵比寿でぼっちイルミネーションをする
    f:id:bath_poo:20181223230524j:plain
    すごくきれい

12月

muttan1203.hatenablog.com

所感

大雪本当に許さんからな

今年は雪が降った。いや、毎年雪は降っているのだけど今年は異常だった。上にも書いたけど、久しぶりに豪雪という感じだった。かつて56豪雪というのがあったのだけど、それ以来だろうか。おかげで道路は全然通れないし、車はスタックしてしまうし、ものが届かないからスーパーから商品が消えるし。そういえばガソリンスタンドも大変なことになってました。

www.asahi.com

 時期が時期だったので、卒論シーズンだった。卒論を書かなければ行けないと言うよりも、豪雪で学校にすら行けなくて練習とかもできないという感じで悲惨だった。実際、自分の研究室の友人は家から数時間かけて徒歩で学校まで来ていた。ちょうど大学のテストだったのだけど、1週間延期となった。卒論もそうだけど、食べるものも確保しないといけないしで気持ちも大変だったなと言うかんじ。もういやですね、あの量の雪は。見たくない。

www.pref.fukui.lg.jp

aikoさんのライブ行きすぎじゃない?

 と親に言われた。そんなに行ってなくない?4回だよ4回って思ったけど、冷静になるとそれなりに行っている気がしてきた。本当は夏のSHISHAMO@等々力競技場というのがあったけど、台風で吹っ飛んでしまった。前日明らかにできねえだろ…って思ってたら、主催者がまさかの決行発言をしたのでとりあえず当日東京に行ったところ中止という連絡が。今更これについてはとやかく言わないけども、ちょっと残念な思い出になってしまった。原宿でクッキーを食べて帰りました。

 で、本題のaikoさんなんですが、今年20周年イヤーということですごい公演数だし本人も気合入ってましたね。前回のツアーでは骨折しながらもずっと続けてたaikoさん、今回は特に何もなくずっと続くかと思いきや神戸公演で喉の調子が悪くなり振替公演をする事態に。聞いたところセットリストは全部やりきったらしい、プロ根性凄まじい…。終わったあと、声が出なくなったことよりもaikoさんの気持ちの方を心配する書き込みが多く見受けられて非常に温かい気持ちになりました。主催者側の対応も非常に早くて、こういうところが好きなところなのかもなあと思ったり。とにかくその後振替公演もちゃんとやれて無事に完走ということになりました。

 今回は参加レポートとか書いてない(書く元気がなかった)のだけど、いろいろとあったなと。まず浜松公演は盲腸の診断を受けたが強行でライブに参加。連番してくれた人ははじめまして(会うの初めてだし、aikoのライブも初めて)だったのだけど、まさか盲腸引きずった野郎が来るとも思わなかったでしょう、これは申し訳なかったな。結局そのあと手術しました。次の京都公演も、退院して2週間とかだったのでわりと病み上がりという感じだった。LLP20前半戦はずっと体調がよくなかったな、と。アンケートに「元気ですか?」みたいな欄があったけど、そこが今までで一番埋まったライブになりました(嬉しくない)

 後半戦は特に何もなく、純粋に楽しむことができた。初公演の滋賀にいったのだけど、びわ湖ホールいいですね。すごくよく見えました。めちゃくちゃでかいわけでもないし、横の席だったのだけど、1列目で前を遮るものなく楽しむことができました。例の琵琶湖に向かってカブトムシを歌う謎企画の話もありましたね(笑)フェスティバルホールについては文句なしという感じで、お客さんもさすが大阪という感じで楽しめました。個人的にやりたかった551のコールアンドレスポンスができたので大満足ですね。

 そういえば、今年は渋谷の街をaikoがジャックするなんてこともあった。そこらじゅうでaikoを見かけた。大型ビジョンで湿った夏の始まり

のCMが流れてたり。上にも貼ったようにいろんなところにaikoがいた。シアワセかよ。あとは各種CDショップでも結構推されていてすごく嬉しかった。

f:id:bath_poo:20181223231153j:plain
タワレコ
f:id:bath_poo:20181223231205j:plain
タワレコの入り口
f:id:bath_poo:20181223231230j:plain
これはTSUTAYAの店内かな。Sexy Zoneの圧を感じる
 来年はアリーナツアーも控えているので楽しみですね。私も大阪公演両日行けることになったので、思いっきり楽しみたいと思います。もう来月なんですけどね。

インターンシップに行った

 自分がB2とかB3の頃って、別にインターンシップ行かなくてもいいかなって思っていた。特に就職したい方向性がはっきりと定まっているわけでもなかったので。でもぼちぼち決まってきた中で、2月に運良くインターンシップに行くことができた。ありがとうピクシブさん。あ、pixivのpは小文字ですからね。

 ピクシブで過ごした1週間は本当に刺激的だった。大学にいるときでは考えられないぐらい技術の話をすることができるし、社員さんはもちろん同世代ですごく頑張っているand技術力の高い人達に会うことができた。ビクビクしながら成果発表とかやったなあという感じ。ピクシブで一緒だった人とは未だに結構遊んだりする。かるめり率が高い。

デザイン「あ」展がいちばんおもしろかったな。

 その後も、ちょこちょこインターンシップとかイベントとかに参加する機会があった。例えばコロプラとか、freeeとか。ほかはsanozi.comをみてくれ。どこもわりと気になっていたところだったし、そういうところに行くことができたのは幸運だったと思う。もちろん面談を重ねていけばいろいろわかるけども、働いてみたりするともっと分かるような気がしている。個人的な感想だけども。

逆求人にいった

 逆求人な、聞いたことはあるという感じでぜんぜん興味はなかったのだけど、インターンシップに行ったあとにいろいろ企業知りたいなあという気持ちになって参加した。逆求人やってる会社はいくつかあると思うのだけど、4回行って全部違う会社が主催するものに行った。なので4社分経験したことになる。それぞれ違っていて、特に交通費的なところと参加企業の違いはあるなあと感じた。交通費は出るほうがいいですよね、特に地方だと。自分も地方なので、多くでてくれるところのほうが助かったりしていた。企業に関しては、メガベンチャーとか大企業が多いところもあれば、小さめのベンチャーがいたところもあって様々だなと。あとこれだけ行くと、どんどん企業がかぶってくるのでたくさん行くものではないなと思った。

 自分は逆求人というものがいいとか悪いとかいう議論には全く興味が無いのでパス。1日で結構な会社とのつながりを作ることができる場だと考えればいいんじゃないかと思っている。少なくとも自分はそう思っているタイプ。そこでつながりを作って、その後やり取りするかとかは自分次第だと思っている派なので、そういう機会だと割り切って参加していた。逆求人の好きじゃないところは、単純に疲れるということぐらいかな。ほかは企業だけじゃなくて、学生同士でも繋がりとか作っておくと後々便利かもしれませんね。

 こういうところで色々繋がりができたりして、今の就活にもそれなりに役立っているような気がしている。結構大きいなと思うのは、面接というか自己分析と言うか、その練習にもなっていたんじゃないかと今になって思っている。今まさに20卒の採用面接とかをしてもらっている立場なのだけど、採用面接で喋る内容は今まで色んな会社の人事の方とかと話した内容がベースになっているので。志望動機とかいろいろ考えるのも大事だけど、実際に話をしてみて気づくこととか指摘されることもあるので、人と話す(聞いてもらう)ことがいかに大切かというのを感じた。逆求人系のサイトに登録すると誰か担当者がつくはずなので、その方に相談するのもありじゃないだろうか。  

まとめ

2018年、振り返ってみるとそれなりに濃かった。たくさんの出会いがあった。今までで一番ぐらいかもしれない。いろいろ遊んでくれたりご飯行ってくれた方々、来年も何卒。
結構体調とか崩したりもしたので、2019年は健康に生きたい。あとお寿司いっぱい食べたい。来年もどうぞよろしくお願いいたします。

freee Winter Internship 2018 エンジニアコース 参加記

IMG_7867.JPG (2.7 MB)

freee Winter Internship 2018とは

2018/12/10〜2018/12/14で開催された、freee株式会社(以下freee)の冬インターンシップに参加してきた。公式ページから引用すると、

freeeの向き合っている顧客の”現場”を知ること、freeeの開発やデザインの”現場”を知ることを通じて、 freeeがマーケットに対してどのような価値を提供しているのかを体感していただける内容となっています。 また、メンターとしてサポートする現場社員や役員陣からの徹底的なフィードバックとメンタリングを通じて、 freeeのメンバーがどのような思いや価値観をもって日々の業務に取り組んでいるかを体感していただきたいと思います。

とのことで、実際にfreeeのチームにジョインして、課題解決や新機能の追加等を体験するインターンシップになっている。地方勢にも優しいインターンシップになっていて、

  • 期間中の宿泊場所(前泊、後泊も)の提供
  • 交通費の提供(※ただし、通勤にかかる費用は個人負担)
  • !!日当15,000円!!

という高待遇だった。その前に、freeeが何をやっている会社なのかを説明する。

freee株式会社とは

freeeは「スモールビジネスを世界の主役に」というミッションを掲げている企業だ。そのへんはこの記事が詳しいかもしれない。

developers.freee.co.jp

いわゆる中小企業と言われている人のバックオフィス業務を効率化するためのソフトウェア群を開発している会社である。例えば会計フリーや人事労務フリー、開業届を5分で作成可能な会社設立フリーなどがある。なかなか学生だと馴染みのない分野だったりするかもしれない。話を聞いてるうちに、いかにバックオフィスに時間を取られているかを知ることができたし、それをテクノロジーで解決できて本来やりたいことに集中できるようにするのがフリーの役目なのだと感じた。

選考フロー

一般的なフローになっていて,

  1. エントリー
  2. エントリーシート記入+コーディングテスト
  3. 面接
  4. 合格

と言った感じだった. エントリーシートの内容も、一般的なもの。面接のときにコーディングテストで書いたコードについての話とかもした気がする。面接官の方は非常にフランクにお話してくださって、楽しく面接することができた。その後合格メールが来て無事に決まったという感じだった。所属チームはSREだった。

インターンシップ中の出来事

いつもだと毎日ちゃんと毎日箇条書きでもメモを取っているのだけど、今回はつけるのをすっかり忘れていたので思い出しながら断片的に書く。つまり日によってはめちゃくちゃ内容が薄くなってしまうけど勘弁してほしい。

1日目

  • 前泊だったので、朝はすごくゆっくり出社する
  • 初日の意気込みです
  • 基本は10:00〜19:00で仕事になります

  • 初日なので、オリエンテーション的なことからやる

  • 自己紹介フェイズ。自分からスタートした
  • 社内のSNSにげんこつハンバーグの画像をテロする
  • マシンのセットアップ、各種ツールのセットアップをやる
  • 全体のミーティングで挨拶 -「 freee完全に理解して帰ります」などという

  • メンター陣とランチ IMG_7869.JPG (1.3 MB)

    • 塚田農場の弁当はだいたいうまいということをココ最近感じている
  • 午後は横路さん(CTO)や泉さんの話を聞く

    www.pr-table.com

    • freeeのミッションであったり, 開発についてのお話
  • その後メンター陣と合流してそれぞれのチームに配属
  • 課題の概要を聞きながら情報を整理する
  • 今回のゴールや、やらなければ行けないタスクの洗い出し、疑問点の解消などを主に行って1日目は終了
  • 隣の席の方が自作キーボード大好き id:foostan だった

developers.freee.co.jp

2日目

  • 1日目で割と疲れたもののそれなりに寝れたので体は元気だった
  • 自席に風船がついた
  • 昨日の続きをする
    • 取り組むタスクの手順書のようなものを書く
  • ランチで寿司🍣 IMG_7875.JPG (1.8 MB)
  • PayPay使えるらしくびっくりする
  • 久しぶりにリアル九岡さんに会う

developers.freee.co.jp

  • SREチームのミーティングにも参加
  • 手順書のレビューを受ける

3日目

  • 確か環境構築バトルをしていて、なかなかできないなあと思いきや朝解決した
  • びっくりするぐらい何も覚えていない…

4日目

  • けど, 今回の課題の終わりがだんだん見えてくる
  • 課題の成果発表について考える
    • 構成とかなんとか
  • 夜はチームで焼肉だった IMG_7899.JPG (2.3 MB)
  • 映えるなあ IMG_7895.JPG (1.6 MB, orientation fixed)
  • 肉を一度に頼んでしまったので、机の上が大変なことになっていた
    • 僕「リクエストがスパイクしてますね!!!」
    • みんな「机スケールアウトしないと…」
    • エンジニアとご飯行くと楽しいですね
  • 就活の話とか、会社の話とかいろいろできて非常に有意義であった

5日目

  • 人生初リモートランチ(?)をする
    • with 九岡さん
  • IT健保はいいぞというお話をする
    • 鮨一新だけじゃない
  • 頑張ってスライドを作る
  • 時間が5minぐらいと言われているのに, 明らかに終わらない量のスライドを書いてしまい焦る
  • 突っ込むデータを取るのが発表ギリギリになり、あれだけ時間があったのに結局5分前ぐらいまで書いていた
  • 成果発表会開始
  • 他のみんな結構いい感じで発表していて心配になる
  • 自分の発表も大きな失敗はなく終わった感
    • しかし質問にうまく答えられなかったのは残念
  • アンケートとか書きつつ、チームの皆さんにお別れの挨拶をするなどした
    • 5日間あっという間だったし、居心地が良かったので寂しかった
  • 懇親会が始まる
  • Beer IMG_7905.JPG (953.7 kB, orientation fixed)
  • お酒をよこに並べてスケールアウト、縦に積んでスケールアップっていいながらキャッキャしてた
  • ちなみにこれはコンテナデプロイでいうところのサイドカーパターン想定です IMG_7906.JPG (1.5 MB, orientation fixed)
  • 社会人歴的にベテランの社員さんや、新卒で入った社員さんと色んな話をする
  • 時期が時期なので、就活の話もする
  • 人生こういうこともある
  • そういえば以前別のインターンシップで会いましたよね?が発生した
    • 最初わからなかったのはごめんなさいという感じ
    • 話を聞いたら結構かぶっていたが、こういうのはこの業界あるあるなのかもしれない
  • Kinesushiの話をした
  • ついたあだ名は攻めるSRE

感想

あっという間の1週間

 インターンシップって、春とか夏つまり大学生の長期休暇がある時期には比較的多く行われていると思う。今回のインターンシップも、普通に授業期間であることを考慮して1週間となったようだった。確かに自分もいくらfreeeが気になっているとはいえ2週間と言われていしまうと行けなかったかもしれない…なんとも絶妙な期間だったと思う。

 しかし1週間というのは本当にあっという間で、実質4日みたいなところがあるのでいかに段取り良く課題に取り組めるかというのが大切だった。はじめて取り組む部分であったりとか、現在稼働しているシステムのアーキテクチャについてなど質問はたくさんあったが、そのあたりもメンターの方やチームメンバーが嫌な顔せずに答えてくださったおかげで順調に課題を進めることができたと思う。感謝の気持ちでいっぱいである。

freeeの開発文化

jobs.freee.co.jp

このあたりを見ると結構詳しく書いてあると思う。結構良いなと思ったのは理想ドリブンという考え方。自分は理想ドリブンとは逆を行く思想で、自分の手札から実現可能なことを考えがち。とりあえず理想を表に出す、共有することで生まれることも多いよなと思った。あとは社内のSNSでもいろんなことが共有されていて、非常にオープンな印象を受けた。新機能のリリースとかもバンバン告知されていて、それに対して多くの人がリアクションしている文化も良いと思った。そしてなにより、仕事だって楽しくやろうという雰囲気が感じられた。

note.mu

チームとかにもよると思うけど、こういう人もいるということで。

働いてみて感じたこと

5日間しかいなかったけれど、全くストレスなく過ごすことができた。例えばポジション、役職、年齢等を気にせずに対等に話をできる文化であったり、いつ聞いても返事が帰ってくるあたり大変心強かった。他にも実際にfreee内で開発する際のフローを体験できたことも良かったと思う。すごい苦手なレビューもなんとか無事に終わった。ちゃんとどういう理由で良いのか/悪いのかを指摘してくれるのはありがたいし、自分がやるときも相手が嫌に思わないレビューを心がけないといけないなと感じた。

c5meru.hatenablog.jp

あとは、開発のスピードが早いなあと社内Slackを見て思うなどしていた。 あとは横路さんが言っていた、3年でCTOになれという話もあったなあ。そのくらい頑張らないといけないってことですね。

社内の様子

もうすぐクリスマスなんでね、どこもかしこもクリスマス仕様でした。 IMG_7867.JPG (2.7 MB) ウェルカムボードもおしゃれですな IMG_7908.JPG (1.9 MB, orientation fixed) 毎朝コーヒーを得ていた(フリーコーヒーです) IMG_7900.JPG (1.8 MB) 一瞬ファミレスかと IMG_7903.JPG (1.5 MB, orientation fixed) Asobiba(アソビバ)というスペースで、全体の打ち合わせとかイベントとかはここで行われる。成果発表会もここだった。 IMG_7902.JPG (1.6 MB) 卓球台もあります(最終日に遊んでました) IMG_7911.JPG (1.8 MB) 今回他社に比べると全然撮っていないですね。櫛井さんの記事がわかりやすいです。

blog.kushii.net

とにかく充実した1週間でした。メンターさんを始め色んな方々におせわになりました。ありがとうございました!

Bug Shooting Challenge #1 参加記 #mixi_BSC

IMG_7722.JPG (1.7 MB)

今回, 株式会社ミクシィさん(以下ミクシィ)開催のBugShootingChallengeに参加してきた。記念すべき第一回大会の参加となる。

BugShootingChallengeとは

名前のとおりではあるのだけど, Bugを潰そうぜ!というコンテストで, 真面目なものを引用すると,

 BSCはもともとCREグループが新卒エンジニア向けに行なっていた不具合調査研修をベースとしています。不具合調査研修については下記の記事にその様子が掲載されておりますので興味を持たれましたらぜひご一読ください。BSCではイベントを楽しんでもらうための工夫として、バグを仕込んだゲームサーバを用意いたしました。イベント当日は2人1組となって、このゲームサーバのログから不具合の原因を特定し、ソースコードの修正まで行なっていただきます。(引用元:https://medium.com/mixi-developers/intro-bsc-40ee02fc675d

らしい. あまりにも名前の通りなのだけど, バグを直して優勝しようということである.

参加記

午前

  • 起床チャレンジに成功する
  • すごい余裕を持って渋谷に着く
  • 渋谷開発し過ぎでは?
  • ミクシィまでは徒歩10min位かかるので余裕を持ってきたほうが良さそう
  • Registrationに成功する
  • ハッシュタグが #mixi_BSC なんだけど, 俺しかつぶやいてない
  • ホスピタリティが最高(無限に飲み物が得られる) f:id:bath_poo:20181117222756j:plain
  • 座学が始まる
  • 不具合調査の必要性
  • CREの話
  • 「心の準備はいいですか?」って聞かれるも, 全然良くなかった
  • まさかのストーリーが存在
    • 上司が冷たすぎる
  • 技術説明がはじまる
    • RubyやらRailsやらDockerやらをつかいます
      • Matzと写真を取る社員さん
      • Rubyのおはなし
        • Rubyは頑張ってください」というアナウンスと共に, 20分で始めるRubyへのリンクが貼られていた
      • Gitの説明
        • 人の気持ちを学んできたLinux Torvalsのお話
        • git challengeの紹介
      • Docker
        • VMとコンテナの違いみたいな
        • Docker Install Battleが始まる
        • 違うランタイムのあれが動くんだなあ
    • SQLのお話
      • SQL on Hadoop with Apache Hive
      • データってどんどん増える(ログとか、スナップショットとか)
      • そこでHadoopですよ
      • 分散処理基盤ですね?
      • 低コストでスケールアウト可能
      • ファイルベースなので生ログも行けるぞ
      • HiveはHiveQLっていう言語でいい感じに分散処理を書ける(SQL like)
      • Amazon EMR(S3のデータに対してEC2インスタンスクラスタで分散処理が可能)
      • Hadoop + EMRのハンズオンが始まる(!!)
      • 全然やったことないけどSQLっぽい感じでかける
  • ランチだ!!!
  • 隣の人のキーボードで遊ぶ IMG_7726.JPG (1.9 MB)
    • ちょっと欲しくなった

午後

  • いよいよ開始
  • ディスプレイ配布される
  • とりあえずslコマンドを使う
  • チームメイトのデスクトップが無限にきれい
  • docker-compose upチャレンジ
  • ローカルでGrafana動いていたせいでポートが競合して😇
  • なんとか環境ができあがる

    1問目

  • 頭が取れた
    • 何もできませんでした
  • 思ったより時間がなかったので, 回答を満足にかけなかった

2問目

  • ログとにらめっこをする
  • 違和感を感じる
    • 結果これが正解だった
  • これも時間が足りずまともにレポートを書けなかった

3問目

  • 実際にありそうなバグ(システムの穴)だった
  • コードをひたすら追っかける
  • 明らかにおかしい箇所があったので治す
    • 修正方法としては正解だった
  • どういう理由でそのバグが悪用されているかを調べる
  • ありがとうRubyMine
  • やはり時間が足りずまともにレポートを書けなかった

解説パート

  • git challengeのように全部が終わってからまとめて解説ではなくて, 1問目が終わったあとに解説, 2と3問目が終わったあとに解説という感じだった
  • それぞれ特性が違う問題で, 非常にやりごたえのある問題だった
  • 2, 3問目に関しては狙いをつけていたところが正解でちょっと嬉しかった
  • 完全にチームメイトのおかげという感じだった
  • 問題を解いたあとの僕

懇親会

  • はい料理が最高 IMG_7728.JPG (1.9 MB)
  • サーモン IMG_7729.JPG (1.7 MB)
  • 一番手前のやつは、友達も俺もよくわからん…って言いながら食べてた IMG_7730.JPG (1.6 MB)
  • 普段の256倍ぐらい人とコミュニケーションを取る
  • 久しぶりにあった社員さんとかとお話をする
    • データ分析基盤の話をした
  • みんな大体就活のお話をしている
    • 大学にはそんな人はいないので, 就活シーズンなんだなあとぼけーっと思う
  • DBに関するLTのようなものが始まる
  • 最後はソファーのとこにあつまって記念撮影(ISUni suwatte shashinwo toru CONtest)

感想

今回がはじめての開催となったBug Shooting Challenge. 結論から言えば非常に面白かった. 実際の現場でも起こりうる内容で, それの調査を行い修正だけではなくその根拠となるものの提示まで含めて採点対象だったので, より実務に即したコンテストだったように思う.

問題の配布や回答はGitHubを通して行われた. 特に回答は, その問題に対しての修正をPull Requestで提出することで採点(人力)されるという仕組みだった. PullRequestではこのバグが何故起こったのかを詳細に説明する必要がある. MVPになったチームのPull Requestを見たが, 非常に丁寧かつわかりやすい説明がなされていて流石だなと思うなどした.

今回はRailsを使ったアプリケーションだったので, もちろんRailsについての知識はたくさんあるに越したことはない. 更に言うと, 大規模なプリケーションを作成・運用していく上で必要な知識も得ることができる大変よいコンテストだった.

今回のように, ユーザーからの問い合わせを受けて調査する業務というのは日常的に行われていると思う. コンテストが終わってから社員の方に聞いてみたが, 実際の現場では長いものでは数日かかるようなものもあるという. 今回はコンテストだったのでそこまで重たいものはなかったが, 実際は粘り強く調べていく力も必要なのだと思った. また, コンテストはコンテストで程よい難易度に調整する必要があるので, 社員の方の準備には本当に感謝という気持ちです.

というわけで, 今後もきっとこのコンテストは続いていくと思うので, 是非多くの人に参加してもらいたいと強く思った(ミクシィさんはgit challengeとかTDD challengeとかいろいろおもしろいイベントをやっているので, 他のイベントも是非チェックしてみてください)

Jupyter Notebookのテーマを変えたらアウトプットの左端が表示されない

いろいろあってJupyter Notebookを使ってデータ分析を行うことになった. こういうのは形から入りたいので, データ分析を行う前に好みの見た目に変えることから始めた. Terminalも見た目変えるところから始まっていて, この先も多分見た目をいじるところから始めると思う.

jupyter-themesを入れる

Jupyter Notebookのテーマを変える方法に, dunovank/jupyter-themesというものがある.

github.com

これを使うことで, みんなだいすきなmonokaisolarizedなどを入れることができる. もちろんデフォルトの真っ白Notebookが嫌いというわけではないけど眩しいので, 慣れ親しんだ暗めのテーマに変えようと思った. インストール自体は簡単で,

$ pip install jupyterthemes

とすれば簡単に導入される.

テーマを変える

jupyter-themesを導入できたので, 実際にテーマを変える. インストールされているテーマは

$ jt -l

とすることで確認することができる. 手元では, 以下のテーマが入っていることが確認された.

$ jt -l
Available Themes:
   chesterish
   grade3
   gruvboxd
   gruvboxl
   monokai
   oceans16
   onedork
   solarizedd
   solarizedl

今回はonedorkというデザインに変更した.

$ jt -t onedork -N -T

基本, jt -t <theme>でテーマを変えることができる. オプションとして, 行番号を表示する-Nツールバーを表示する-Tをつけた.

Jupyter Notebookの起動

テーマを変えたので, 任意のディレクトリでJupyter Notebookを起動する.

$ jupyter notebook

するとブラウザ上でいつもの画面が開くので, 自分の作業するノートブックを選択する.

あれ…左端が…

起動するとテーマが暗めのになっててハッピーですね. onedorkかっこいいです.

しかし… f:id:bath_poo:20181012101922p:plain outputの一部が表示されていない…左端が切れている… f:id:bath_poo:20181012101929p:plain

無理やり治す

Chromeのインスペクタで要素を見ていたら, f:id:bath_poo:20181012102006p:plain と言った感じでオーバーレイされてるように見えたので, アウトプットそのものが表示されている領域に強制的にmargin-leftをつけちゃえばとりあえず出るかなと考えた. そこで, 使用している.jupyter/custom/custom.cssというファイルをいじって治すことにした. 具体的には, 1664行あたりに行ってmarign-left: 9exとかを足します.

div.output_subarea.output_text.output_stream.output_stdout,
div.output_subarea.output_text {
 font-family: monospace, monospace;
 font-size: 8.5pt !important;
 line-height: 150% !important;
 background-color: #373e4b;
 color: #b1bed6;
 border-top-right-radius: 0px;
 border-top-left-radius: 0px;
 margin-left: 9ex;
}

すると f:id:bath_poo:20181012102027p:plain なんか表示されましたね. これでいいのか…?良い解決策あったら教えてください.

余談

Jupyter Notebookのこと昨日までジュピターノートブックだと思ってました. ジュパイターなのね.