Yahoo!のインターン(サイエンス/大阪)に行ってきた
Yahoo!の黒帯インターンシップにてサイエンスコースの大阪オフィスに行ってきました.
サイエンス 〜黒帯インターンシップ〜
5日間のコースで(多分)人生初の大阪.
時間が経ってしまった上にあまりメモをとれていなかったので覚えていることを.
経緯と流れ
過去何回かCTFに参加していたため,インターンに応募の際に最初にオススメされたのは"セキュリティ 〜黒帯インターンシップ〜"でした.
確か"セキュリティ専門ではない企業が珍しく募集している"という流れだったはず.
その時に今年のYahoo!のインターンは細分化されたコース分けになっていることを初めて知りました.
今年はいくつかの企業にインターンに行きたいなぁと思っていたので,興味がある∧日程が被りにくいコース,という基準で選びました.
その結果サイエンスコースの大阪に応募することに.
エントリーシートだけでなく面接も必要だったため,新幹線の中で急いで卒論を外部向けの真面目なverに変更して発表練習をしていた記憶が.
内容
コースが細分化された結果なのかインターン生は3人のみ. 5日間のなかで,セットアップ,課題決め,黒帯による講義,そして最終日に成果発表を行いました.
インターン課題
短時間でいっぱいor難しいことをやるのは難しかったため,僕はpythonとHadoop(streaming)でゴニョゴニョする程度で終了です.
Hadoopは初めて触ったのですが,一筋縄ではいかないなというのが5日間を終えての感想です.
(Hadoop印象遷移)
「あ,なんだラクそう」->「え,なにこれバグわかんない」->「つらい」->「でもやっぱりすごい」
インターン中メンターの方と色々相談しながら作業を進めていき,方針や目標がサクサク決まったのでコーディング作業に集中できました.
最後に結果を分析する際には非常にお世話になりました.
黒帯の講義
サイエンス 〜黒帯インターンシップ〜に書いてなかったので行くまで知らなかったのですが,インターン中に自然言語の専門家と機械学習の専門家から講義を受ける時間が用意されていました.
Yahoo!には黒帯制度なるものがあるらしく……あれ,課題解決休暇? は知らなかった.
Yahoo! JAPAN - IR関連情報
研究室のOBの方が黒帯と聞いて驚きました.
発表
準備
発表前日にデバッグのためHadoopを回している間の待ち時間があったので,「大体こんな感じになるのかなー」と大体の構成を考えてました.
スライドの中身は当日の午前中から作り始めてメンターに見てもらい,更に一度練習をしてフィードバックを頂きました.
発表の準備時間は割りとタイトでしたが,スライド枚数を減らしてなんとかしました.
(その分かなり発表時間が余った.なんとかなってない)
結果
なんと,優秀賞を頂きました.
景品に自撮り棒とスマホ用レンズを頂きました.
発表を色々な方々に褒められて非常に嬉しかったです.
他の記事とのdiff
この記事を書くにあたって今までのインターンの記事を参考にしたんですが,オフィスによる違いなのか時間による変化なのか違いがあったのでdiffをとっておきます.
(といってもよくよく調べたらそんなに記事なかた……)
マシン
インターン生にはWindows機が渡されていましたが,オフィス全体を見渡すとWinとMacは大体半々くらいでした.
メンターの方に聞いたらMacだからと特別な申請はないらしく,最初に好きに選べるそうです.
エンジニアやデザイナーはMacを選ぶ傾向があるとか.
エディタ
あんまり話にあがりませんでした.
エディタは……まあ好きに選べばいいんじゃないかな.
あ,美少女はいなかったです.
まとめ
も っ と デ ー タ に さ わ り た い !
はてなブログに引っ越した
ブログを引っ越すのはこれで2度目になるか.
最初はBloggerで書き始めた.
その内Markdownで書きたくなり,どうしようか悩んだ結果
ドメインを購入してPericanとGithub.pageを使って公開することにした.
しかしPericanという部分がネックになり,
外出先や研究室で書けずなかなか更新ができなくなった.
また,Github.pagesをブログに使うのはもったいないという同期からの指摘もあった.
というわけで,sukerutulo.comはポートフォリオサイトにし,
ブログは sukerutulo.hatenablog.comにすることにする.
その内以前のブログの内容をこっちに持ってこようかと思う(フラグ)
持ってくるほどの内容でもないけれど.
ポートフォリオにするといったものの,コンテンツがない.
作らねば.
アルバイトについて
技術的なことが書けないのでふと思いついたことを書いてみる。
今まで自分が関わってきたアルバイトについて振り返ってみる。
どのバイトでもNDA(秘密保持契約)があるので、業務内容ではなく自分自身について書く。
某研究室のアルバイト
自然言語処理を研究する研究室でアルバイトの募集があった。学部2年の時だったから、3年前か。応募メールの日付を確認したところ2012年の9月末だった。当時の自分は情報系の学生ながらも何もできない状況だったと思う。
この研究室で学部3年の冬、2014年の1月くらいまでアルバイトをさせてもらっていた。ここでの経験がほぼ今の自分を形作っている。
課題を与えられて週1の進捗報告を交えつつ自学自習の形で作業を行っていた。PythonとC++、各種コマンドやgitを覚えた。(gitは今でも怪しい) とりあえず基本はemacsとコマンドラインでにらめっこ、わかんなかったらググる、という感覚になった。
テスト期間や帰省など途中で休みを交えつつ課題をこなしていった。結果は奮わないことがほとんどだったが、着実に力は身についていったように思う。作業自体は1人だったので色々と気楽な部分もあった。研究室の環境を使わせてもらっていたので、勝手がわからず色々と迷惑をかけてしまったこともあった。本当にサーバー周りでは何度嫌な汗をかいたかわからない。
学部4年になり研究室配属が決まったので一旦アルバイトをやめることにした。
現在しているアルバイト(今まで)
研究室の先輩が以前お世話になった方の元でデータ解析のアルバイトをしていると聞いた。前回のバイトの業務からデータを扱う仕事はとても気になっていた。ビッグデータとかデータサイエンティストとか流行りの単語もあったし、この手の経験をしておけば今後食いっぱぐれにくくなるだろうと、先輩に自分も加わりたいと願い出た。
こちらもメールの日付をみたところ2014年の9月頭だった。9月に職にありつくジンクスでもあるらしい。既にチームで走りだしていたようなので、作業のキャッチアップに時間がかかると思いきや、その月の下旬にはタスクをこなしていた。
前のバイトと違いこちらはチーム戦になった。用意してあった時系列データを2チームに分かれて解析した。チーム間で作業は独立していたが、時には同じ作業を各々こなして互いの手順の正しさを確認することもあった。
一緒にチームを組んだ前述の先輩がとんでもなく優秀なエンジニアだったので学ぶことが多く、色々と勉強させてもらった。傍から見てめんどくさそうな作業をホイホイ引き受けて「え、マジっすか」と思っていたらいつの間にかササッと仕上げている様子には感服するしかなかった。逆に「これならSQLに命令追加して叩くだけで大丈夫っすね」と言ったらすごいと褒められることもあった。ああ、やはり世によく見受けられる1人よりもチームがいいという言説は嘘じゃなかったんだなと本気で思った。
こちらも週1でミーティングがあり、その間の課題をこなしていく形だが、作業・解析の提案なども行わなければならない。単純にアルゴリズムを実行するコードを書くだけでなく、どのアルゴリズムを採用するかなども一緒に考える。仕事のレイヤーが1つ上がった感じ。
現在しているアルバイト(これから)
件の先輩が卒業してしまったので現状チームを組む相手がいなくなってしまった。
このままではチームに割り振られるタスクを1人でこなす必要がある。作業量よりも心理的な負担や、相談相手がいなくなったことが厳しい。そうでなくとも最悪でも卒業までに1人は後任を確保しなければならない。
だが、そううまい具合に人材が見つからない。仕方がないので質を問わず、ともかく手の空いている人を募集することにした。最悪コード周りは全て自分でやればいいから、ともかく相談相手が必要だ。
探してみたところ、二人ほどアテがついた。この二人に作業に加われるよう教育を施し、チームとしてマネジメントしていけばやっていけるようになるかもしれない。
そういった経緯で「教育って一体何したらいいんだよ」と頭を抱えながらgitとpythonを教えている。pythonで動的にSQLを作成し、SELECT結果をpython側であれそれできるようになってくれれば十分だが、そこまでが途方もなく遠く感じる。
(ただしまだアルバイト志望の二人に関してはあくまで"予定"。
もしダメだったとしてもgitとpythonの知識は二人の無駄にはならないだろう)
バイトを通して
プログラミングに関わるバイトはこれで4年目ということになる。
1-2年目:基礎の時間
プログラマとしての感覚、というか。SSHでサーバに入ってtopでリソースの空きを確認してからtmux上でプログラムを並列に回してデタッチして授業に出る、みたいなことを平然とできるようになった。
基礎練というか、ゲームとして成り立たせることができるようになったというか。
3年目:ステップアップの時間
単純なスキルを身につける、できないことを減らすというのとはまた違う経験ができた。1人では得られない経験というやつ。人と一緒に仕事をしたからか頭打ちに感じていた成長率に先を感じられるようになった。
コートに立てるようになったというか、チームメンバーとの連携を覚えたというか。
4年目:成果の時間(?)
今まで自分が得た経験を人に与え、適切な仕事の割り振る。これらを今までの作業と同時並行にこなすのかと思うとちょっと自信がない。けどコードを書かずにいれるわけもないし、何よりデータを解析するという一番面白い作業を手放す道理もない。 また1つレイヤーが上がりそうな気もする。チームギークとかアジャイルとかの本でも読むべきだろうか。
チームを回す役割、キャプテンにでもなった気分。トップではないので中間管理職。
おまけ
現状を把握するために文章化してみた。
書く前から薄々感じていたのだけどなんだかこれ社会人の経歴のような……
学んだことをいくつか
研究資料検索システムの進捗を出すために作業してて学んだことをいくつか
シェルスクリプトはスペースに容赦無い
下手するとpython以上にコード表記に厳しいんじゃないかっていうくらい。 スペースがあるかないかでよく怒られる。代入の=とかif文の[]とか。
やっぱりpythonのエンコード周りは闇だった
単純な文字列のUnicodeErrorによくあるstr型とunicode型の扱いくらいなら慣れてきた。 今回困ったのは名前が日本語のファイルをopen()しようとしたとき。 ああでもないこうでもないとやった挙句、結局それまでと同様にunicode()で直った。 実際の問題はファイル名ではなく、パスが絶対パスではなかったことだったようだ。なぜ文字化けしたのかは不明。
valueソートの辞書
keyではなくvalueで辞書をソートしたいというのはよくある。sort()にkey=lambda x:x[1]してやればよい。 今回jsonを使って辞書型をvalueの降順にdumps()したかった。 しかし上述のsort()のやり方はdict.items()をソートしているためソート後は辞書型にならない。 では辞書型に戻してやればいいのかというとそれも違う。ソートした順番通りに辞書型が作れない。 さてどうしよう、とググったところOrderedDict()を使えばいいとのこと。 ついでにdumps()で日本語を出力する方法(ensure_ascii)も覚えた。
from collections import OrderedDict
dict = {'赤':1, '青':32423, '黄色':0}
sorted_dict = OrderedDict(
sorted(dict.items(), key=lambda x: x[1], reverse=True))
print json.dumps(sorted_dict, ensure_ascii=False, indent=4)
githubについて
学生は大学のメールアドレスを登録すればgithubのプライベートリポジトリが使える。 このプログラム自体は公開しても全然構わないのだが、対象データが個人情報なのでうかつに公開したくない。 そういうわけでプライベートリポジトリを使って管理している。 折角なのでgithubに関する今まで使ったことのない機能もいっぱい使っていきたい。 コミット量がそこまで多くないのが少し問題だが、[successful git branching model]とかgithubを正しく使えるようになりたい。 とりあえずissuesを存分に利用してみる。branchもmasterとdevelopで切っているが、一人作業なので有り難みがない。 もっとfeatureとかreleaseとか使っていきたい。
進捗
とりあえず全pdf,pptxファイルの単語をベクトル化するところまではできた。tf-idfもすぐに計算できる。 これからどうやってクラスタリングをするのか、アイデア程度ならあるが実装レベルではまだわからない。
考えついた当初は「単語をベクトル化するくらいまではサラサラっと書けそうだし大変なのは検索エンジン化とクラスタリングの作業かな」などと思っていたのにここまで苦労してしまった。 自分で「簡単な作業」と思う仕事を1週間でさらっとこなせるようになりたい。 書き上げたコードを見て振り返っても、かかった時間の大半は調査時間に含まれる気がする。 自分が欲しいと思う技能全てが一気に進歩するわけないだろうし、一歩一歩やっていくしかなさそうだ。
デバッガに打ちのめされた
IDE最強
gdbに触れたことはあるものの、積極的に使っていくほどではなかった。
どうせ自分が書くプログラム程度ならprintデバッグで十分だろう、と。
最近ICPCに向けて研究室でもプロコンが盛んになってきている。
ついさっきまでゼミの課題であるTopCoderの問題に取り組んでいた。
最初は単純にどう書いたらいいかわからずウンウンやっていた。
自前で書いたやり方がどうも違う気がして仕方なく蟻本を開いた。
アルゴリズムの書き方はわかったけど、どうにもおかしい。エラーがとれない。
それも何か奇妙な値のとり方をしている。どこか実装をミスったか。
奇声をあげながらTypoを探していると同期がやってきた。
彼には既に「その問題はintじゃあふれるよ」とのアドバイスを受けていた。
変なエラーが治らない、一部だけ通って一部だけ通らない、と助けを求めると、
「longにしたのか、桁あふれしてるんじゃないか」という。
いや、さっきの助言通りlong long intにした、そんなことはないはず。
そう言うと彼は「変数の中身は確認した? デバッグにVisualStudio便利よ」という。
いや、研究室用PCはMacだし。一応VirtualBoxに入って入るけど(DreamSparkという学生の特権)。
しぶしぶXcodeを使ってみることにした。使い慣れないIDEにものすごく苦労した。
「buildできない。runのボタンがない」「なにそれ(画面を見る)俺の知ってるXcodeと違う」
「ググってもよくわからない(情弱)」「プロジェクト作った?」「え、なにそれ?」「作れ」
想像以上に間抜けを晒してしまった。
でもライブラリやら何やらの依存があるきちんとしたソフト開発ならともかく、
一回問題を通すためだけに書き捨てるプロコン用のコードにもいちいちプロジェクトを作るのは
なんだか無駄が多いような気がしてならない。あまり好きになれない。
プロジェクトなしに生のソースをそのままコンパイルして実行したいのだけど。
あ、ちなみにエラーは桁溢れでした。
まさかlong long intが溢れるとは思ってもいなかった。
結局何から何まで彼の言う通りだった。
脱Emacs? まさか
そんなことがあって、「Emacsでコード書くのやめたほうがいいのかな」と少しへこんだ。
だが、ぐぐるとEmacsとgdbの連携はなかなか悪くないらしい。
周りの人は皆GUIが好きだと言うが、僕はCUIが好きなのでこっちのほうを覚ることにしよう。
とりあえず、まずはprintデバッグからの脱出、というところか。
研究資料検索システム
近況報告
研究室に入ってからかなり経った。学ぶことばかりだ。
しかし今年の目標として掲げたアウトプットがおろそかになってしまった。
新しく特殊なキーボードを注文した話とか、そのファームウェアを書き換えた話とかネタはある。
とりあえず今やりたいと思ってることを文章として残しておこうと思う。
研究資料検索システム
現在研究室にある資料、先輩方の残した論文やスライドはきちんと管理されている。
しかし現状の管理では「どこに誰が書いたものがある」がわかる程度で、その中身についてはファイルを開けてみないとわからない。
研究室が持つ資料数年分ともなればその量も結構なものとなる。
長く所属している人ならばどんな内容の資料があるかある程度想像つくだろうけれど、そうじゃない人は必要な情報を探し当てるのに遠回りをしてしまうかもしれない。
というか僕が先輩や先生に「こういうことについて調べたいけど、それについて調べた先輩っていますか?」とかいちいち聞くのが申し訳ないだけだったりする。
と、いうわけで研究室の資料をなんとかして内容から検索しやすいようにできないかと考えている。
計画
- 研究に関連する主な資料は論文(tex, pdf)とスライド(ppt, pptx)
- 各データの内容を対象にして検索をしたい
- 含まれる文字列を抽出していろいろあれこれすればできそう(?)
- texはテキストファイルと同じで直に扱える
- pdfからの抽出はツールもライブラリもあるだろうし困らなさそう
- スライドの2種類が鬼門かと思ったがpythonにライブラリがあるようだ(参考URL)
- これらから抽出した文字列の中から名詞を抜き取り、ファイルの場所とひもづける
- ファイルが含む名詞と場所とで索引構造を作り検索できるようにする
できたらいいなと思ってること
参考URL
pythonでオフィス快適化計画 - SlideShare 覚書ブログ: pythonで PowerPointを操作する。
win32.comとかpython-pptが使えるらしい。もっときちんと調べてコードを書きたい。
Pelicanになれる作業
苦労したこと
ともかく疲れた。もうPelican触りたくない。
Pelicanは公式ドキュメントがあるから設定には困らないはずなんだけど、それ以前の問題といったところ。
というか間違えて大事な部分にまで手をいれてしまったせいで一回はブログが投稿できなくなった。
仕方ないので諦めてPelican-quickstartをもう一度やり直した。こんなこと二度としたくない。
この記事を書くのだって二度目だ。一個前の投稿など何回書いたか、という気分。(あくまで気分)
Pelicanに移してまだ2回目の投稿だというのにもう当分したくない。
Pelicanについてわかったこと
- make serveは連続してできない
- pythonでエラーが出てもエラーログは役に立たない
- モジュールとか例外の名前を読んだところで到底解決できない
- 前後の自分の行動から察せよ
- かなり柔軟、というか細かく指定ができそう
やること
- 過去ブログのインポートができるかどうか調べる
- ブログのカスタマイズ
- markdownになれる
- 記事を書く