ML Study Jams Vol.4 完了したから軽く感想
ML Study Jams Vol.4
とりあえず対象のハンズオンを8つクリアした。
↓は対象外のも含む。
4つでマグカップがもらえるが、8つ以上だと、過去のグッズ(Tシャツとバッグ)ももらえるのだ。
感想
以下はどっちかというとqwiklabsの感想になる。
有用か?
基本的には、文章読みながら理解して、ソースコードコピペしながら進めていくので、学ぶ姿勢がなければただの作業になる。 ただし、一部は与えられた課題にたいして過去のハンズオンを参考に自分で考える必要があるものもある。 学ぶ姿勢があれば有用だとは感じる。ただの作業にしても、4,5回同じことしてたら流石に覚えそうな気もする。
致命的な不具合
qwiklabsについては、ちょいちょいエラーが気になった。 今回は8つクリアしたが、実際途中で諦めたのも2つあった。 なぜかエラーで進めないなどがあるのだが、まあ無料だから仕方ないとして、 Dataprepのコースはやつは結構やばい↓
個人的にやっておきたいもの
AutoMLでさくっと学習はやってみたい。業務で作ってるモデルよりこちらのほうがよければもうこれでいいんじゃね? って思ってしまう。ベンチマークとしてさくっと使いたい。
【GCP】Cloud DataprepのTransformerはデータ分析向けに心地良すぎた
Qwiqlabsの下記講義でgcpのサービスであるCloud Dataprepの使い方を学んだのだが、 その中にあるTransofrmerと言うのがすごく良かった。
次世代版エクセルというか、これをjupyterと組み合わせてインタラクティブにできたら最高だなあと思う。
デーブルデータをロードすると、各カラムに統計やtypeが表示される。
これだけでデータ分析コンペはかなり嬉しいんじゃないか、pandas-profilingみたいなもんだ。
ヒストグラムはただの画像ではなく、グラフとして機能している。
カーソルを合わせると、対象binの数値が表示さるのだ。すげえ。
カラムのヘッダから簡易的なフィルタリングも可能。
対話型のGUIでぽちぽち条件を設定すると、自動的にクエリに変換される。
こう言うの本当に嬉い。直感的に操作した後で微調整や繰り返しはコードでっていうことができる。 wangle言語というDSL(なのかな?)を用いれば、このようなクエリをコードで表現することも可能だ。
さらにそれらをデータ処理フローとして登録できる。他のテーブルデータとの結合も簡単。
ネットをクソ適当に探したけど、まだそんなに知られてないのか日本語の文献が全然出てこない。 見つけた資料としてはcourseraの動画があったので、見て欲しい。
Qwiklabsが今なら無料
【LeetCode】Best Time to Buy and Sell Stock 解法
LeetCode - Best Time to Buy and Sell Stock
自分的な解法はfinalである。 v1は5800ms、finalは120ms。 v1はスライス多様しすぎなへっぽこコード。 finalはsolutionに書かれていたものを理解したもの。
ループを時系列に例えて、その際の最小値と最大利益を順次計算している。
ちなみにmaxProfitはsolution内の書き込みだが、よく理解していない。
class Solution: def maxProfit(self, prices: List[int]) -> int: if len(prices) <= 1: return 0 d = [prices[i]-prices[i-1] for i in range(1,len(prices))] g = [0]*len(d) g[0] = d[0] for i in range(1,len(d)): g[i] = max(d[i], g[i-1] + d[i]) return max(0,max(g)) def final(self, prices): minprice = 9999999999 # sys.maxsize maxprofit = 0 for price in prices: if price < minprice: minprice = price elif price - minprice > maxprofit: maxprofit = price - minprice return maxprofit def v1(self, prices): max_ = 0 for i in range(0,len(prices)-1): v = prices[i] p = max(prices[i+1:]) - v #max_ = max([max_, p]) max_ = max_ if max_ > p else p return max_
【LeetCode】Two Sumの解法
LeetCode - Two Sum
解法。自分の場合は最初はv1(ブルートフォース)。 その次にv2(ハッシュ)、これで速度が100倍になった。 で、コメントをみてv3,finalです。
finalの場合、target - nums[i]をifの中で 計算しているようにしているが、ifがTrueになる確率の方が低いから、 変数への代入のコストが少なくてすむのだろう。 ちなみに enumerateを使おうが使わまいが、速度差はなかった。
あとは、towSum関数に直接コードかかないと30msくらい遅くなるが、 これは備忘録として見やすいようにしているだけ。
class Solution: def twoSum(self, nums: List[int], target: int) -> List[int]: return self.final(nums, target) def v1(self, nums, target): for i, n1 in enumerate(nums): for j, n2 in enumerate(nums[i+1:]): if n1 + n2 == target: return [i, i+1+j] return None def v2(self, nums, target): map_ = {} for i,v in enumerate(nums): map_[v] = i for i, v in enumerate(nums): complement = target - v if (complement in map_) and (map_[complement] != i): return [i, map_[complement]] return None def v3(self, nums, target): map_ = {} for i, v in enumerate(nums): complement = target - v if complement in map_: return [i, map_[complement]] map_[v] = i return None def final(self, nums, target): map_ = {} for i in range(len(nums)): if target - nums[i] in map_: return (map_[target - nums[i]], i) map_[nums[i]] = i return None
【書評】Docker 書評というにはあまりにも失礼なくらいわからない
- 作者:Adrian Mouat
- 発売日: 2016/08/17
- メディア: 単行本(ソフトカバー)
業務でDockerを使うようになってきたので、ちゃんと体系的に知って起きたと思って手にとってみたが、まあむずい。
Ⅰ部 背景と基本
これこれ!こういうことをちゃんと体系的に知りたかったんだよねえ!!
Ⅱ部 Dockerのあるソフトウェアライフサイクル
お、おう。そうだな、こういうハイテクな使い方があるんだ、ふむふむ。
Ⅲ部 ツールとテクニック
・・・。
という具合である。
まあ今使うと言っても、リソースをスケールアウトしたいとか、いろんなコンテナを起動して連携したいとかいう場面はないのだ。 ただ実験環境をクリーンにして、受け渡しやコード管理を楽にしたいという理由でDockerを使っているから、とりあえずI部の内容をちゃんと把握しておけば合格だと思っている。
この書籍の出版は2016年であって、もう4年くらい経ってるわけだから、ここで紹介されている内容だってだいぶ陳腐化されている可能性はある。 書籍でのdocker バージョンは1.9(19じゃない)だし、オーケストレーションでswarmなんて使わないでしょ?しらんけど。 なのであまり変わらないであろう「背景と基本」を抑えておけば、、、あとは必要な時に学習するのがよいのではなかろうか、と自分に言い聞かせる。
まあ3,600円するけど自分にとってその価値があるかというと、微妙ではある。というか、「お前にはまだ早い」と言わんばかりの内容であった。
個人的付箋
コンテナのポートを自動割り当て
-Pという引数を使うとDockerにホスト上の空いているポートを自動的にフォワードさせることができる。
$ ID=$(docker run -d -P nginx) $ docker port $ID 80 0.0.0.0:32771 $ curl localhost:32771 <!DOCTYPE html> <html> …
コンテナ間でのデータの共有
コンテナ間でのデータの共有はdocker runで--volumes-from CONTAINERという引数をつかうことで実現できる。
$ docker run -it -h NEWCONTAINER --volumes-from container-test debian /bin/bash
これを使って複数コンテナ間でデータの共有をするためだけに作られた最小限なデータコンテナを用意するテクニックがある。
開発環境と実行環境の切替
cmd.shというファイルを作成する。
#/bin/bash set -e if [ "$ENV" = 'DEV' ]; then exec python "development.py" else exec python "product.py" fi
Dockerfileに
CMD["/cmd.sh"]
を追記して
$ docker run -e "ENV=DEV" -p 5000:5000 test-container
【書評】みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト
これはやばそうな本が出たぞ。というワクワク感で買ったものの、 amazonの評価を見るとそうでもない感じだった。
同じようなレビューが複数存在していて、なんか著者はみずほ銀行に忖度しているのかと思ってしまったが、 とりあえず読んでみることにした。
結果的にはレビューの通り、罵詈雑言が飛び交うものでもなく、現場の荒れ果てた状況が語られるわけでもなく、どちらかというと、すごいシステムを作り上げたという評価に近いものであった。
本は3部構成になっており、 1部が最近完成したMINORIというシステムについて、2部は東日本大震災直後のシステム障害について、3部は統合後の最初のシステム障害についてである。
2部、3部についてはいろいろ問題があって起こるべくして起きたと語っているものの、1部のMINORIについては、35万人月、4000億以上のコストをかけたすごいプロジェクトを成し遂げたんだ。という内容になっており、拍子抜けだった。
技術者であれば、人が増えることで一人あたりのパフォーマンスは下がることは経験的にわかるはずで、これだけの人数が携わっているならそれはもう想像しただけで恐ろしいと思うのだが、なぜかその苦難というのがあまり語られていない。過去の失敗から学び、大きな問題なく完成させたぞ、みうほは銀行の中でもリードしているのだ。みたいな。
まあ実態は違うんだろうけど、それでもまあここに語られていることが全てならば、予想していたよりもよいものができているんじゃない?と思ってしまう。
- ブラックボックスの排除
- 経営陣のIT軽視、IT理解不足の解消
- IT理解不足の場合は、ソフトウェアが障害の原因なのにハードウェアベンダーの責任を問うなど見当違いが発生する。
- SOAを採用
- APIゲートウェイの採用
- AS IS(現状のまま)の要件定義を完全排除
- Xuppterを使って、「あるべき業務フロー」をゼロベースで検討
- 超高速開発ツールを採用し、属人化を排除
- Fintechとの連携を想定し、コア部分は自前、それ以外はオープンAPIを利用
まあ、言うは易く行うは難しだと思うので、MINORIが完成したことはすごいとは思うし、障害が発生しないで星いと思うばかりである。