Subscribed unsubscribe Subscribe Subscribe

SE Can't Code

A Tokyo based Software Engineer. Not System Engineer :(

次世代データ解析IDE, JupyterLabをインストール.

データ解析でよく利用されるJupyterNotebookでは、後継であるJupyterLabというIDEの開発が進んでいる。今回はそのJupyterLabのインストールと良さ気な機能を少し書こうと思う。

JupyterNotebookとは

JupyterNotebookはブラウザ上でPythonプログラミングが簡単に出来るツールであり、主にデータ解析の業務で利用されている。iPythonの旨味であるインタラクティブな処理の実行を行い、matplotlibのinline表示をすれば、plot結果をブラウザに埋め込まれた形で確認することが出来るので、非常にスピード感のあるコーディングが可能になる。ちょっとした検証コードや書捨てのコードを書く際には威力を発揮するツールだろう。特徴を簡単に羅列すると下記になる。

  • インタラクティブにコードを実行できる
  • Plotをinlineに埋め込められるため、可視化に優れている
  • Python2系、3系、また仮想環境への切り替えが簡単
  • Pythonだけでなく、RやScalaといった多言語との連携にも対応している
  • セルモードを切り替えるだけでmarkdownとコードを共存させることができる
  • プレゼンテーションモードにすれば、スライドが自動生成される

などなど、パッと思いつくだけでもこれだけの特徴が挙げられる。特に2系、3系のカーネル切り替えやmarkdownが書ける、といったところは仕事で非常にお世話になっていてありがたい。プレゼンテーションモードを使って研修教材を作ったりしたこともある。もうこれがないと基本的に仕事にならない、と言っても過言ではない。他のデータ解析の現場も同じなんじゃないかと思う。


後継のJupyterLabとは

そんなJupyterNotebookの次世代版が"JupyterLab"である。現在、絶賛開発中のIDEであるが、JupyterNotebookをさらに使いやすくしたUI改善が多く実装されている。特徴として下記が挙げられる。

  • JupyterNotebookはブラウザ上のIDEである
  • Building BlockなJupyterNotebookに比べて、柔軟性のあるUIを実現
  • npm/webpackをベースとしたJSで開発されているため、プラグイン開発が簡単になった
  • 各種Inspector機能がついた

主にUIの開発が進んだ印象である。より詳しくは、Scipyカンファレンスの動画を見ると良い。

www.youtube.com


JupyterLabのインストール

JupyerLabはJupyterNotebook4.2.0以上である必要があるので、バージョンがそれ以下の場合は事前にupgradeを行う。JupyterLab自体はpipを使えば一発でインストールされる。

$ pip install jupyterlab
$ jupyter serverextension enable —sys-prefix  
$ jupyterlab

データ解析者御用達のAnacondaの場合はcondaを叩く。

$ conda  install -c condaforge jupyterlab

インストールが完了すると、ローカル環境のブラウザ上でJupyterLabが立ち上がる。

f:id:fixxman:20161126145617p:plain


JupyterLabで出来ること

JupyterNotebookとの一番の進歩はブラウザの一画面内での画面分割が可能になったことだろう。JupyterNotebook上でいくつかのノートブックを開いて作業をする場合、ブラウザのタブ毎を行き来しながら作業をせざるを得なかったが、JupyterLabではマウスで画面内のタブをクリックして移動させるだけで、簡単に画面を分割することが可能になる。たとえば以下のように、Console画面を開きながら、iPythonのインタラクティブな実行環境でコードを実行しながら、ターミナル画面までも操作することができる。

f:id:fixxman:20161126150241p:plain

また、見てわかると思うが、サイドバーとしてディレクトリも操作できるようになっており、従来のIDEに近づいた設計となっているのがわかる。(これはかなり嬉しい)


さらに個人的に良いなと思ったところとしては、csvファイルを画面にクリック&ドロップしてあげるだけで、綺麗なTable形式でcsvの中身を表示してくれる機能がある。わざわざPandasのread_csvを叩いてheadで表示して中身を確認する、なんて手間が不要になるところは、小さい話だが個人的には嬉しい。

f:id:fixxman:20161126150807p:plain



このようにUIに大きく変更が加えられているJupyterLabであるが、スピード感を持ってデータとにらめっこして解析・検証を行うデータ解析者にとっては割と嬉しいIDEとなるんじゃないだろうか。個人的には単純にオシャレなので会社で使ってやろうとニヤニヤしているだけなのだが、ファイル操作やIDE内のタブの使い勝手といった面は普通に嬉しいな、と思う。あと凄く個人的な願いなのだが、iPythonLab上で書いたコードをpyファイルにnbconvertした時の出力がもう少し人の手が入らないように正規化されて出てきてくれるととても嬉しい。ここらへんって実はもう改善されていたりするんだろうか。

Remove all ads

2ヶ月計画、英語, Done.

今月から2ヶ月の勉強計画がスタートしているわけだが、その中の一つである英語部分が終了した。

やったことは、Forestを2周と英単語を3周、あとはちまちまとiKnowをひたすらやってた。元々英文法はすっかり忘れてて苦手意識があったが、Forestを2周したことでもう問題ないレベルまで上げられたと思う。普段から僕の喋る英語は文法めちゃくちゃだったわけだが、これで少しはマシになるんじゃないだろうか。英単語は単語帳にあるものは丸暗記したが、すぐに忘れそう。まぁ元々、英文はノリで読む人間なので、まぁいっかと思ってたりする。(いや良くないけど)

あるエンジニアの記事で、「英語は短期間で狂うほどやれ」ということが書かれていたが、たしかに短期間集中は割と身になった気がする。少なくとも、英文法はもう勉強しなくていい。ただ、仕事で毎日英語を話していた日々から一転、英語を話す機会が一気になくなったので、ちょっとSpeakingが頭から消えつつあるのが辛い。これが今のところの悩みか。

とにかくやろうとしていたことの一つは無事に終わった。英語はこんなもんでストップさせて、あとは普段からやってる海外のPodcastを聞くのと、iKnowをやるぐらいに留めておくとする。まぁなんか、去年は一切喋れなかった英語レベルと比べれば、割と伸び代あったんじゃないか。元が低すぎたって話だけども。

Remove all ads

SICP2章、データによる抽象の構築 - 抽象の壁.

SICP2章の途中だが、一度、"抽象の壁"までをまとめようと思う。

1章は手続きの抽象の話だったが、2章からはデータ構造の抽象の話。2章の導入部分から使われている例として、有理数を一個の思考単位とするためのデータの糊付けの仕組みを学ぶ。これは単純な数値データでは立ち向かえない複雑な問題を解くための手助けとなる。計算機は複雑な問題を解くためにモデルを生成するが、モデルを作るためにデータを抽象化(すなはち"抽象の壁"を構築)することで、複雑な問題に対応する。要するにプログラム設計を行う際に、思考レベルを高めることが可能になる。

データ抽象

手続きと同様、基本的なデータオブジェクトを用いて抽象化することを Data Abstraction(データ抽象)と呼ぶ。このデータ抽象はselectors(選択子)とconstructor(構成子)という2つのインターフェースによって構築される。データ抽象を用いて合成データオブジェクトを作ることで、データオブジェクトをどう表現するかに関するプログラムの部分を、データオブジェクトをどう使うかに関するプログラムから隔離することができる。このように抽象化を行い、レイヤーを分けることで、下記のような恩恵を受けることができる。

  • ある場所での変更を局所的なレイヤの変更に封じ込めることができる
  • 実装方法を自由に入れ替えることができる


このデータ抽象の説明には有理数の例を出すといい。有理数を用いた計算を行うためにデータの抽象化を行うことで、必要な思考だけに留めることができる。
最も基本的なデータ構造として、2つの引数を部分として含む、consという対(pair)の合成構造がある。また、その部分の値はそれぞれcarcdrによって取り出すことができる。簡単に表現すると、consに引数となる値2つを渡すと、2つの値が対の組み合わせとなって返され、その対の組み合わせの一つ目の値を取り出す際はcarを、それ以外の値を取り出す際はcdrを用いる。

(define x (cons 1 2))

(car x) -> 1
(cdr x) -> 2

このデータ構造を最も低レイヤとして、抽象化を行う。まずは有理数を表現する。有理数を2つの整数、分子と分母の対で表現するために、構成子make-ratと選択子numer,denomを定義する。

(define (make-rat n d) (cons n d))

(define (numer x) (car x))

(define (denum x) (cdr x))

有理数の表現ができたら、有理数を用いた基本的な演算を行う抽象化を定義する。簡単に有理数の加算、減算、乗算、除算をmake-rat, numer, denomで表現する。このレイヤはcons, car, cdrを意識する必要はない。既に分母と分子を糊付けしてあるため、有理数が表現されている前提で演算を行うことができる。

(define (add-rat x y)
  (make-rat (+ (* (numer x) (denom y)
               (* (numer y) (denom x)))
            (* (denom x) (denom y))))

(define (sub-rat x y)
  (make-rat (- (* (numer x) (denom y)
               (* (numer y) (denom x)))
            (* (denom x) (denom y))))

(define (mul-rat x y)
  (make-rat (* (numer x) (numer y))
            (* (denom x) (numer y))))

(define (div-rat x y)
  (make-rat (* (numer x) (denom y))
            (* (denom x) (numer y))))

(define (equal-rat? x y)
  (= (* (numer x) (denom y))
     (* (numer y) (denom x))))


こんな具合で有理数の演算を行いたい時は、上記のadd-rat, sub-rat, mul-rat, div-rat, equal-rat?を用いてプログラムを実装するだけで良くなる。データ抽象の基本的な考え方はSICPに記載されている内容がしっくりくる。

一般にデータ抽象の基盤となる考えは、データオブジェクトのそれぞれの型に対し、それを使ってその型のデータオブジェクトの全ての操作が表せるような基本の演算の組を見出し、これらの演算だけを使ってデータを操作することである。


あとは表現の依存性を少数のインターフェース手続きに制限すると、すごくプログラム設計に役に立つ。プログラミングをしているとこれらは基本動作に過ぎないが、あまり意識せずに利用しているリストのデータ構造とかもこうした低レイヤーから意識して実装してみるととても面白いし、学びがある。抽象化によって多くの実装レイヤはブラックボックス化されているが、それらを知らずに高い思考レベルだけでプログラムを考えるのはよくないんじゃないかとSICPなり、低レイヤの勉強をしているとよく思う。インフラエンジニアがAWSといったクラウドからスタートしたり、WebエンジニアがRailsといったフレームワークからスタートすることがよくないと言われていることと同じ話で、こうした抽象化の壁の向こうを覗いてみることは、何を理解するにしても大事なことだと実感する。というか本当に技術の面白いところはこういうところだと思う。


しかし2章は進むのが凄まじく遅い。問題が非常に多くて負荷が強いが難儀だ。ここらへんを勉強していると、やっぱし大学でちゃんとコンピュータサイエンスを勉強したかったなぁ、と思う。文系エンジニアがよく思うやつだけど、そんなこと言っても時間は戻ってこないので、社会人はなんとか時間を捻出しましょうと。そんな話。

Remove all ads

アジャイルサムライ.

単純な好奇心として最適な開発スタイルに対する興味がある。DevOpsやらアジャイル、それらの中にあるツール類やら、自分達の開発はもっと良く出来るんじゃないかとよく考える。そのためのインプットとして本を読んだり技術を触ったりしているのだが、最近、アジャイルサムライという本を読んだ。この本は有名なアジャイルの本なので感想ならWebのいたるところにあるんだけど、個人的にはWFとアジャイルの共存ってどうすれば実現するんだろう、という観点で読み進めた。学びはあった。実践出来るかさて置いて。

SoRとSoE

ここ数日前からSoRとSoEという考え方が普及し始めて、SoRの主流であるWFとSoEの主流であるアジャイルの共存について考えるようになった。

というのも、一ヶ月前くらいに会社の同期から「アジャイルについて聞きたいことがある」と言われて話した内容が、まさにSoRとSoEの考え方だったからだ。SoRとは、System of Recordの略で、ミッションクリティカルな記録のためのシステム、つまり基幹システムのようなものを指す。SIerがWFを駆使して強みにしている分野だ。一方でSoEは、System of Engagementの略で、ユーザとの関係性を構築する、ユーザに近い部分のシステムを指す。ここはWeb側がアジャイル開発で強みにしている分野だろう。

その同期が相談してきた内容としては、ボタンを一つ追加するだけで、数ヶ月という時間がかかるのをアジャイル開発でスピード感を持って開発したい、ということだった。よくある話だろう。そんな話をすると自然とユーザに近いシステムからアジャイル化だね、という流れになる。冷静に考えると当たり前なのだが、口で言うのは易し。実際にWFでガッチガチに開発していた一部分をどうやって、アジャイル化するのか、というのは難題だ。

MicroService

昨今のユーザ企業での内製化の流れはSoEの部分にメスを入れるというものが多いと思う。要は全部のシステムを自分達で巻き取って内製化するのではなく、SoRの部分はベンダーに任せたままで、SoEの部分を切り離して自分達でアジャイル開発する、という流れ。これはどうしても進んでいくと思う。

冷静に考えて、ボタンを一つ追加するのに数ヶ月とかやっていられない。個人的には3ヶ月サイクルのシステムしか経験してないので、それ以上かかるシステム、特に年単位のシステムは想像も出来ないが、SoRの部分はやりたいことによってはしょうがないのだろうな、となんとなく思う。

で、この切り離しの部分をどのように実現しているのかが凄く気になっている。始めてこの話を聞いた時にパッと浮かんだのはMicroServiceだった。コンウェイの法則に従って、SoR部隊とSoE部隊に組織構造からメスを入れて、全ての機能をAPIを通じてやり取りをさせる。要は疎結合アーキテクチャを設計しないと二つの手法(WFとアジャイル)の共存なんて出来ないんじゃないかという考え方。一般的に既に動いているシステムをMicroService化させていくやり方がよく推奨されているので、SoRなシステムをMicroService化&SoE分離させていくのが腑に落ちる。

勿論、SoRとSoEの仲を取り持つマネージャが必要になるし、それら二つの組織が乗る共通のインフラも必要になる。加えて、アルゴリズム検証チームなんて組織があるとより面白いプロダクト開発が可能になるんじゃないかとも思った。アルゴリズム検証チームはデータマイニング機械学習のモデルを検証するチームであり、プロダクトに組み込むアルゴリズムを開発する。なんだか良さげなチームに見えないか。

隣の芝と自分とこの芝

ここまで書いて気付いたこととしては、これは自分の中の理想だな、ということだ。ずっと不満に思っていたこととしては、SoRに全振りのチームばかりの会社への物足りなさ、同僚エンジニアに対する技術力の無さだった。それはSIの特徴とも言えるもので、社外に目を向けるようになってからWebの世界、つまりSoEの世界がより一層青い芝に見えるようになっていった。

そしてデータマイニングチームにアサインされてから、アイデアだけで勝負することに対して課題感を持つようにもなった。ここに書いたことは、それぞれの分野の専門家が一つのプロダクトを作ろうとしている形だ。きっとこの世界観が自分の求めるもので、そこに入って何かを作りたいから技術を磨いているんだと思う。

まぁしかし自分はまだ偏った開発経験しかない。データマイニングチーム的なところにいるので、SoRなチームからはもう割と離れてしまったが、SoEアジャイル開発は依然として経験出来ていない。情報集めをしていると、たとえば、設定用フラグのフレームワーク、reputation 評価を備えたチェリーピックツール、HashiCorpのツールを使ったデプロイ、サービスディスカバリー... こうした具体的な実装への興味は尽きない。まだまだこの分野は自分にとって隣の青い芝でしかない。だから早め早めにいろんなところを経験したいという想いがある。一つのところにずっといることは一番の遠回りだと思う。

この頃こうしたことをゴニョゴニョと考え過ぎていて、時間の使い方を間違えている気がする。というかレイヤ違いが過ぎるのか。これ考えるのはCTOの仕事だからな。最近上司にこれをやってくれと頼まれたりして、「いやこれってCTOの仕事なんで、僕じゃないでしょ」と言ったら、「実績作ったら年収グンと上がって転職し放題だよ。やろうよ。」みたいな上司あらぬ発言を受けたけど、いずれやれたら楽しいなとも思う。まぁこれは先の話だ。今はいろいろ力量不足。

Remove all ads

機械学習エンジニアとは.

最近ずっと頭を悩ませていることに自分のポジションの話がある。今の自分は立ち位置がかなりうやむやになっていて、機械学習という技術トレンドの大波に乗ってはいるものの、これをキャリアにするとなんなのだろうと悩みに種になっている。ここ最近は機械学習を扱うエンジニアでもいろいろと区分けがあるようだが、どうもその区分けがピンと来ていない。

たとえば、Researcher, Analyst, ML Engineer, Consultant といった区分けが挙げられるだろうか。なんとなく得意分野の伸びで分かれそうなのがわかる。Researcherなら研究寄り、Analystは統計や数学に強みを持った解析寄り、ML Engineerはプログラミング寄り、Consultantはビジネス寄り、とかだと思う。基本的に4つとも網羅していないといけないスキルは共通していて、数学、機械学習、統計、プログラミング、と大きく分けるとこんなもんだろうが、その中でどこを尖らせるか、であったり、スキルの使い方であったりで分かれそう。

その場合自分はやっぱりプログラミング寄りなので、ML Engineer、つまり機械学習エンジニアになるのだろうが、こいつの活躍場所がいまいちピンと来ていない。転職市場を見てみても、機械学習エンジニアはかなり需要が高まっているが、Analyst(イメージとしてデータサイエンティスト)がいれば万事解決じゃんと思って見てしまう。おそらく機械学習エンジニアはプロダクトへの機械学習アルゴリズムの実装をメインとしているのだろうが、実装だけならそんなに難易度は高くないんじゃないかと。

一番難しいところって、データを見て、自分で前処理して、数学や統計学を駆使して特徴量をいい感じに抽出し、機械学習のモデルに当てはめて、評価してうんぬん、みたいなところだと思うが、機械学習エンジニアの担当領域がそこまで根を張っているのか?と疑問符が付く。そしてこの一連のデータマイニングのプロセスを踏むのがAnalystで、機械学習エンジニアは決まったモデルをただ実装するだけなら、そこまで大した仕事ではないんじゃないのか?というのが自分の中のモヤモヤの正体である。

まぁでも理解出来ないモデルをプロダクトへ実装するなんて許されないから、そういう意味で機械学習の知識があるプログラマーが必要なのかもしれない。それは確かに自分の仕事の中でもあった気がする。実際にプロダクトに実装するプログラマー機械学習のモデルの説明をした時、ホワイトボードに数式を書いて説明したりしたが、「なんとなくやりたいことはわかったが、数式はわからん。」みたいなことを言われ、そのためプログラムの品質を担保出来ない、と言い切られたことがあった。そこをわかるプログラマーが欲しい、とそういうことなのか。

うだうだと自分の中のモヤモヤを書いたが、理想はAnalyst分野もある程度出来てかつ、プロダクトへの実装も出来る機械学習エンジニアだよなぁと思う。自分はデータサイエンティストか、というと違う気がするので、数学と統計学を伸ばしつつ、実装寄りの人間を目指すのだろう。むしろプロダクトを作る方がただ解析するより楽しいのでそれがいい。そしてこの分野でいくとしたら、機械学習が乗る分散処理系も技術として持ってないといけないんじゃないか、とか今後の技術の習得計画が凄く悩ましいものになっている。

もういろいろゴチャゴチャ考えるのはやめて、面白そうな技術を遮二無二に習得していく、という今まで通りに方向に倒すのもありだが、26歳を目前にした今、それってこれからも通じるのか、とかを変に考えてしまっている。いい感じのロールモデルが近くにいればいいんだが、周りはすげぇ出来るデータサイエンティストばかりなので、自分の方向性とはちょっと違うな、とか思ったりする。とにかく、数学と統計学をガンバレ、ということでこの場は締めておくとしよう。

Remove all ads