matobaの備忘録

育児しながら働くあるエンジニアの記録

2017-09-20の日記

今日のダイジェストを書きます。

仕事をした

滞りなく仕事をできたつもりです。

技術的な試行錯誤のできる仕事で、自分が手を動かしていて、実験データも自分が見ていて、どうやってやるかにも噛んでいて、、、という色々自分がメインで動けているので、気分はいい感じです。

欲を言うなら、もうちょいさくさく行きたいけど、サクサクいけてない原因が僕の説明力にありそうなので、精進したい。

インドカレーを食べに行った

初めてのお店。

ナン美味しい。

ナンがおかわり自由だった。

なんだってー？！

社内LT会に参加した

参加した。 同僚が蛇を飼ってるらしい。 可愛いらしい。 あと、古代魚を飼ってる人もいた。 マニアックだなあと思った。 ちなみにマニアックと言うのは褒めています。

あと、技術的な話もした。

terraformがいいよ。っていう話とcircle ci 2を使って見たよ。って話。

とりあえず、雰囲気として便利なことが伝わった。ただ、インフラのコード化の辺りのこと、よくわかってなくて、中身までは分からなかった。

とりあえずインフラをコード化するとインフラの管理が楽で良いわ〜と言う話があるのはわかって来たけど、自分でインフラのコードを書いたことがないのでよくわかってない。

とりあえず、雰囲気は理解したので、自分が書く機会をそのうち作っていきたい。

プロフェッショナルの流儀をみた

家帰ってきて、録画してたプロフェッショナルの流儀を見た。

だいぶ前の録画だけど、とりためている番組を見た。

オークションスペシャリストの話。 職種がマニアックすぎて、プロフェッショナルさよりもなぜその職にたどり着いたのか、どの道を辿ればそこに行くのかが気になって仕方がなかった。

久しぶりにDAWを開いて打ち込みをした

なんとなくDAWが触りたい気分なので触っていた。midiをぽちぽちしてた。

そう。midiキーボードが壊れていて困ってる。何が困るかって、midi音源の音色確認が時間かかる。

そう。音源がたくさんあるのもあって、音を触ってたら時間が過ぎていく。まあ好きなんだけど、音楽ができた方が嬉しい。

そう。さすがに音楽が全くできずに、迷ったまま時間が過ぎると疲れてしまう。

とりあえず音色は適当で進めると良いように思ってきてる。

なんかサウンドプロデューサー的な依頼が来た

久しぶりの友人から連絡があったと思ったら、ミニアルバム制作のサウンドプロデューサーやってほしいって話だった。

打ち込み、レコーディング、ミックス、マスタリング辺りを担当しそう。

楽しみではある。

なお、まだ聞いてないがギャラはでないと思う。とりあえずまあボチボチやろうと思ってる。

Soft Skillsを読んで気になった部分を書き出した話。

ライフハック 読書

f:id:mtb_beta:20170818223441j:plain

そういえば、こう言う本を読んでいました。

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

ソフトウェア開発者の人生マニュアル。らしいです。

ゆっくり読んでいても終わらない感じがあるので、今回は、自分のケツを叩く意味も込めて、ブログを書きながら本を読んでいきたいと思います。

まず、目次を読んで、僕が気になったことを書き出しました。

この一つ一つを、簡単に本を読みながら確認していきます。

プロであること

この本の中に、「プロであること」と言う章があります。プロって何だと思いますか？

この本には、プロとアマチュアの違いが書いてありました。 この話を読んで、僕はプロとしての行動をとることができているんだろうか、と改めて考えることになりました。

この中に、自分の習慣を見直そう、と言う話がありました。 僕には、どう言う習慣があるだろう。

僕は自分で思うのも残念なんですが、あんまり習慣がないように思っています。 いや、そんなことないかなあ。

どうだろう。

常に何かを考えているとか？何かに疑問を持っていて、それを、常にメモに書き留めている、とかは、いい習慣なのかもしれません。 その一方で、時間を管理するような習慣をもっと強化していきたいと思っています。

例えば、早く寝て、早く起きるとか。

習慣かあ。

うまくやりとげるまではできたふりをしよう

これも、本の中に、「うまくやり遂げるまではできたふりをしよう」と言う章があります。 そこを読んで思うことを書きます。 まず、補足すると、これは、嘘をつけと言う話をしているんではないです。 ここで話をしているのは、「やり遂げることができるように行動しなさい。」と言う話。

思考は現実化する、みたいな話ですかねえ。

そういえば、これに関連して思うことなんですが、僕は、他の人から見ると、自信満々にしているように見えるようです。

なぜ、そんなに自信満々なのか、と言う話をされることがあります。 なぜだろう。と言うかそもそも、自信満々にやってるつもりはないんですけどねえ。 でも、自信がない風に振舞っていたら、だんだん元気が無くなってくるので、自信が持てるまで、考えようとしているところはあります。

まあ、自信が持てるまで考えられているかは、怪しいところなのかもしれませんが。。。

学び方を学ぶ：独学の方法

これも、本の中の一つの章です。

ここでは、独学は、行動するのが大切だ。と言う話をしています。

本を読んでも、実際にそれを使って行動してみないと学んだとはいえない。と言う話です。

あと、学ぶことの目的は、知識ではなくて行動とする方が、効果的に学習することができる。と言う話もしています。

ふむふむ。なるほど。

あと、学んだ知識で遊ぶことで、労力をかけずに多くの情報を身につけることができると言う話も書いてます。

そうですねえ。遊びかあ。

この話を聞いて思ったことが、最近プログラミングは、仕事でアウトプットしたり、インプットしたりすることが多いのもあって、遊びやすくなってきたんですよね。

前までは、学んだことが消化しきれずに、どう言う風に使われるかわからないような感じでしたが、仕事でプログラムを書く中で、それぞれがどこでどう言う意味を持つのかわかってきました。

プログラミングとは別の話で、趣味の音楽に関連することで、もうちょっと独学を進めたいなあと言う気持ちがあります。そっちもなんとか音楽で遊べないかなあ。

マルチタスク、やっていいこと、悪いこと

世間的には、マルチタスクは減った方がいいと言う話があるものの、マルチタスクの方が効果的なタスクもあるだろう、と言うのが筆者の意見です。

あと、筆者が言っているのが、一般的なマルチタスクは、ただ単にシングルタスクを細かく切り替えているだけで、並列でタスクを実行しているわけではない。と言う話。ふむ。

で、筆者の言うマルチタスクと言うのはなに？と言うと、並行して実行できることで、例えば、ヘッドホンで音楽を聴きながら、タイピングをするとか、ジムでウェイトをしながらポッドキャストを聞くとか。そう言うやつらしい。

そういえば、前に、ジムで自転車をこぎながら、本を読んでいたことがあるけど、あれもマルチタスクかあ。 そうよね。集中力が入らない何かをやっている時に、頭が空いていたら、そこで何かをやるのもいいかもね。

ただ、個人的には、頭の中に色々思うことが浮かび続けるから、その色々浮かんでくるイメージを一つずつ処理していくのが、心地よい時間ではあるんだけど。

時間を浪費するメカニズム

この章で、話をしているのは

  1. テレビを見るのをやめろ
  2. ソーシャルメディアを見るのをやめろ

この２点。これについては、僕も概ね同意。

ただ、あんまり頭を使わなくていいテレビは、楽でいいだし、バラエティ番組も好きなのでそう言う時間があってもいいと思う。 あと、ソーシャルメディアも張り付いているのはどうかと思うけど、１日に１回とか２回にまとめれば、別にいいんじゃないかなと思う。

むしろ、それくらいは触れておかないと世の中から孤立していくような気がしてしまう。

ブレイクダウン：先延ばしを克服する方法

ここで話しされているのは、 先延ばしが起きるのは、問題を大きく捉えすぎてしまうこと。 だから、小さく分解しよう。と言う話。

大きく見すぎていると、その大きさに圧倒されてしまうから、まずは大きさを小さくしようよ。と言う話になる。

これは、僕がよく陥る罠なんだよなあ。 全体像を見ようとして、大きすぎて、辛い気持ちになる。

だから、この本では分解しましょう。と言う話になっている。

その話を聞いて僕は、じゃあどうやって分解するの？って思う。

それは、本の中で、タスクを小さい連続的な部品に分解していこう。と言う話につながる。

なるほど、それができたら苦労しないんだけどな。。。と思ったりもしたが、 もう少し、小さい連続的な部品に分解して見ようと思う。

まとめ

とりあえず、今日はここまで。 本を読みつつ、ブログに自分の考えていることを書いていくのは、思った以上に時間がかかった。

この記事を書くのに１時間の時間を使った。 もうちょっとコンパクトに書きたかったと思う。

本で書かれていることをそのまま書いてしまうのは、おかしいと思うので、自分なりの言葉に置き換えたり、自分なりの解釈を加えて、ブログに書いていくわけだけど、それが、なかなか言葉にならなかった。

今後はもうちょっとスムーズにブログを書いていきたい。

githubの使い方を学んだ時の話。

読書 ソフトウェア開発 Git/GitHub

最近、githubをどうやって使ったらいいんだろう？と言う人に会いました。

気持ちはわかります。僕も４ヶ月ほど前まで、githubでPRを送ったことがありませんでした。

PR送るの怖いなああ。と思っていました。今ではそんなことはありません。PRも普通に送れるようになりました。

と言うわけで、僕が、githubでPRを送る抵抗がなくなるまでに勉強したことを書いておこうと思います。

前提を話します。 僕は、もともとSVNを使ったことがありました。 SVNを使って、チームで開発をしていました。 あと、趣味で、Mercurialを使ったこともありました。 ただ、gitは使ったことがない。と言う状況でした。

と言うわけで、スタートです。

まず、僕はこの本を読みました。

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール Web制作者のための教科書シリーズ

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール Web制作者のための教科書シリーズ

この本は、デザイナーの人がgithubを使うために必要な情報が書いてあります。

デザイナーの人にとってわかりやすい本とするために、あまりコマンドは書いていなかったように思います。確か、基本的にGUIベースで話が進んだ記憶があります。

この本を使って、githubがどう言うものなのかを雰囲気掴みました。

そのあとに、次の本を読みました。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

  • 作者:大塚 弘記
  • 発売日: 2014/03/20
  • メディア: 単行本（ソフトカバー）

Githubで実際にPRを送ったり、PRをマージしたりできます。 実際にやってみることで、自分が何をやろうとしているのかわかるので、すごくためになりました。

次に、以下の本を読みます。

Pro Git 日本語版電子書籍公開サイト

いや、正確には、全て読んでいません。必要になった時に、読んでいます。

簡単になりますが、僕がgithubでPRが送れるようになるまでにやったことを紹介しました。

今から思うのは、とりあえず自分のgithubアカウントにリポジトリを作って、ローカルにcloneして、そこで色々試してみると、いいんじゃないかな。と言うところです。

いきなり動いているプロジェクトのリポジトリにPRを送るのがきついなら、自分のアカウントで一人しか使っていないリポジトリにPRすれば、誰も痛い目を見なくて済むのでね。

僕も、初めての操作があれば、基本的に、そうやっています。

PyConJP 2017に行って来ました。（全体まとめ）

技術イベント参加 Python

PyConJP 2017に行って来ました。 たくさんツイートしたのでだいぶ貼り付けた。適当な事ばっかり言ってるのが目につくな。。。

初日

基調講演の話

基調講演の話だけ、昨日書きました。

blog.mtb-production.info

変数アノテーションの話

最初の方、話についていけなかった。でも、よくわからんという話をボソボソとTwitterでつぶやいていたらなんでこんな話になっているのかを教えてもらえて最終的にはついていけた。

speakerdeck.com

Apache SparkとかPySparkの話

SparkとかPySparkを使ったことないけど気になっていた。Sparkを使う、というのがどういう話なのかを知れてよかった。とりあえず、pandasとscikit-learnとdaskを使う or PySparkを使う、みたいな選択になりそうなイメージ。

今の所、前者は、試行錯誤しやすい。後者はスケールしやすい。みたいな理解。そして、今の所、pandasとpyspark間のデータフォーマットの変換は結構重いらしい。（Apache Arrowに期待が集まる）

speakerdeck.com

Djangoフレームワークのユーザーモデルとか認証の話

ブースを見ていて、途中からの参加になった。 途中からの参加すぎて、話についていけなかったので、スライドを確認したい。

www.slideshare.net

len()関数がオブジェクトの長さを手に入れる仕組み

PyConJP2017っぽいスライドマスターが印象的でした。 なるほどお。と思う話ばかりで、Pythonについて勉強させてもらいました。

www.slideshare.net

自然言語処理 とかディープラーニングの話

アカデミックな論文発表っぽいなあと思っていた。 アカデミックな領域から出てから思うのが、アカデミックな論文発表って、何かをやるときに、なんでそれをやっているのか、という話がすごい長いなあと思う。

僕は、どっちかというと、どうやってそれをやったのか、とか技術的な話を知りたい。モチベーションの方は、まあ論文読んだり飲み会で話をしたらいいのかなと思っている部分がある。もうちょっと中の話が聞きたかったなあという印象。論文を読もうかなあ。

www.slideshare.net

djangoのパーミッション管理の話

djangoのパーミッション管理の話。 アプリケーションとかサービスを作る話を聞いていると、どこもパーミッション管理の話である程度悩むように思うので、為になる話でした。

www.slideshare.net

セキュリティと機械学習の話

徹底的に自動化しようとしているところが、すごい印象に残った。 途中で、検査値を自動生成する話があって、GAでそれらしい検査値を作った後に、それを元にして、GANで大量の検査値を生成していて、なるほどと思った。

www.slideshare.net

二日目

keynoteの堀越さんのpandasのOSSコミッターとしての話

pandasとかOSSにコントリビューションすることの話が印象的だった。 今までOSSってどうやって動いているんだろう、と思っていたところがあったけど、その気持ちがだいぶ薄れた。何かできることがあれば、やっていきたい気持ちはある。

Pythonで実現する4コマ漫画の分析の話

自分が好きなツールを自分で開発している話。楽しそうだった。僕も自分が欲しいものを自分で作っていきたいと改めて思った。

slideship.com

SQLAlchemyの話

SQLAlchemyの話。ORMって、よく聞くけど、具体的になんなの？って思ってたけど、あーあれがORMかあと思ったりしながら聞いてた。途中で話についていけなくなったので、スライドを見返したい。

ジョブフェアでグローバルに働くために英語をやろう、という話

グローバルに働きたい人って減ってるのか、Pythonの人がグローバルに働きたいと思っていないのかわからないけど、少ないなあと思った所存。僕は、やりたいことをやる為に結果的にグローバルになるのはいいと思うんだけど、海外で働きたいという欲はないかなあという気持ち。

補足すると、ドキュメントはGoogle翻訳するんじゃなくて自分で読むほうがいいように思っている。ただ、自分の訳が不安だったり、英語の文章が、頭にスッと入ってこないので、とりあえずGoogle翻訳にどんな雰囲気の話を確かめてから、具体的に英文を読んでいたりする。でも、ドキュメントの場合、結局コードがあるので、文章としては、雰囲気わかればだいたい事足りているところがある。

ドメイン駆動設計の話

とりあえず、ドメイン駆動設計は、変化に強くなる代わりにスピード感がなくなるということを理解することができた。

www.slideshare.net

機械学習におけるデータの再現性の話

会社で仕事としてデータ分析をしていくときに悩ましい話だなあと思った。これから色々僕も検討していきたいと思っている。

speakerdeck.com

ディープニューラルネット確率的プログラミングライブラリEdward

難しかった。とりあえずなんかすごそう。と思ったので、スライドを見て、知らない技術単語について調べるところから始めたい。

www.slideshare.net

後「ベイズ統計モデリング: R,JAGS, Stanによるチュートリアル」がいいという話を聞いた。

Pythonの並列処理とか並行処理の話。

なんとなく知っているような知らないような話をきちんと整理してもらえてありがたかった。標準ライブラリを知ることができて勉強になりました。

Pythonをとりまく並行/非同期の話

サーバーレスの日本語形態素解析の話

日本語形態素解析に興味があった。ノーマライズとかサニタイズとかしていて、なるほどなるほど。って思った。あと、合名詞も結構印象的だった。

まとめ

PyConJP 2017は、Output& Followがテーマだった。

僕は、PyConJP2017で何かを発表することはなかったけど、ひたすらツイートで、思うことをアウトプットした。すると、たくさんの人にツイートした疑問をフォローしてもらえた。そして、僕は、このブログで、自分自身のアウトプットをさらにフォローしていきたいと思っています。

今後、やりたいこと。

せっかくなので、僕のツイートを振り返りながら、自分が今後やりたいと思うことについて書き出しておこうと思います。

  • wheelの仕組みを学びたい
  • 変数アノテーションを使ってみたい
  • unmarshalerが何か分からなかったので、使ってみたい
  • pysparkを気が向いたら使ってみたい
  • apache arrowが気になるので、調べておきたい
  • GANとかCNNとかもう、よく分からないやつが結構あるので、色々調べなおしたい
  • 著作権に関する議論をもうちょっと調べてみたい
  • 自然言語処理のDeep learningは気になっている
  • 各種スライドを見直して、よく分からないところを洗い出したい
  • SQLAlchemyを使ってみたい
  • ヘキサゴンアーキテクチャとかCQRSとかドメイン駆動設計をもう少し知っておきたい
  • 組織的なデータ分析というのは、もう少し深掘りして考えていきたいと思う所存。
  • 自然言語処理をもっとやりたいなあと思った

おまけ：togetter

togetter.com

PyConJP 2017　初日の基調講演

Python 技術イベント参加

PyConJP 2017にいって来ました。

ざっくり

PyConJP 2017の初日、楽しかったです。 たくさん知らないことが知れたのと、面白そうな話をたくさん知れたので勉強したいなあ、という気持ちになりました。

ここからは僕のツイートを貼り付けつつ、話を思い出しながら書いていきます。

基調講演の話

初日は、anacondaを開発するーーのーー、ーーー氏の基調講演から始まりました。 英語での発表なのですが、PyConJPの基調講演は同時通訳が付いていて、レシーバーから日本語を聞くことができます。

後日談的には、同時通訳のレシーバーは、はじめから席に置いてあって、数に限りがあったらしいですね。僕はなかったので、スライドを見ながら雰囲気で楽しみました。

内容に関する情報ツイートを貼り付けつつ、補足も書きます。

英語はあんまり聞き取れないけど、スライドから読み取るには、データ分析を行うプログラミング言語として、Pythonがいろんな分野の人に使われていて、そのいろんな分野が話をする共通言語として、Pythonが利用されている。という話をしていた。

あと、データ分析をするためのライブラリやフレームワーク、システムはたくさんあるけど、データのフォーマットが違ってその変換に時間がかかるが問題になってるらしい。

そして、その変換の橋渡しのためにApache Arrowの開発が進んでいる。という話もあがっていた。

あと、質疑応答周りでPyPIとかの話が出てたみたいだけど、僕は英語を聞き取れなかったのでよくわからない。ただ、白熱していた様子だった。

Twitterに参考資料が流れてきたので、僕は読んで勉強してた。

コンピュータに詳しくない人がPythonでデータ分析をするための環境を簡単に整えるための１つの方法としてAnacondaが作られた。そして、Anacondaはこれまで、Pythonコミュニティが議論してきたパッケージ管理の仕組みに従ってない。という話のようですね。

wheelとかまだよくわかっていない部分があるので、これから勉強していきたいなあ。

さて、、、少し長くなって来たので、ひとまず、ここで切り上げます。

githubに趣味で作ったもののソースをあげた話

個人開発 Python

唐突な話ですが、以前からOSSを作ってみたいと思っていたので、作ってみました。

と、いっても大したものを作った話ではなくて、 ちょうど趣味でプログラムを書いている時に作ったソースをgithubにあげてみただけです。

github.com

経緯

  • 過去のブログ記事を、はてなブログ（非公開）にインポートして、整理していた。
  • カテゴリがぐちゃぐちゃすぎるので整理して から公開したい。
  • 最初は手作業で整理しようとしたが、記事の数が多くて嫌になってきた。（約５００記事）
  • プログラムで整理しようと思い、はてなブログからエクスポートした。
  • はてなブログからエクスポートしたら、MovableTypeのエクスポートフォーマットだった。
  • Pythonで編集したかったけど、MovableTypeのライブラリで気に入った感じの見つからなかった。
  • MovableTypeのexportフォーマットを確認したら、簡単そうなので自分でパースすることにした。
  • ついでだし、githubにソースを公開しておこう。と思った。

思ったこと

  • MovableTypeのエクスポートフォーマットは、今の所簡単にパースできていて、ハマりどころはない。
  • とりあえず、githubにソースをあげるのは、なんとなく気分的に楽しい感じがする。
  • せっかくgithubを使っているので、一人でブランチを切って、PR出して、一人でマージする、をしてみたけど、やったことが整理しやすい
  • issueを使うと、もう少し整理しやすくなりそうな気がするので、もうちょっと適当にissueとか発行して使ってみたい。
  • githubはissueとPRの番号が、通し番号になっていることに気づいた。どういう運用を想定しているのかいまいちわからない。

vimの環境周りがなんか汚くて、困っている話

Vim

最近思っている悩みを話します。

みなさん、MacPCでの開発環境ってどうやって作っていますか？

複数のマシンがあるときに、どうやって開発環境を揃えたらいいのがわからず困っているところがあります。

いや、厳密には開発環境はある程度揃っているのですが、開発環境が汚くて困っています。

とりあえず、状況を説明します。

これまで、僕が使ってきたMacは、４台あります。

  • 個人用マシン１（2010年〜2014年）
  • 研究用マシン（2012年〜2014年）
  • 個人用マシン２（2014年〜現在）
  • 仕事用マシン（2017年〜現在）

僕が開発するプログラムの大部分は、Pythonです。 それぞれにPythonの開発環境を整えてきました。 よく考えてみると最近は、Pythonの開発環境そのものには、あんまり困っていません。

個人用マシン１を使ってた時は、よく困りました。 そもそもパッケージ管理とかよくわからなくて、適当にパッケージを入れまくりました。 その結果、マシン環境がカオスになりました。

研究用マシンを使い始めた頃には、「適当にPythonパッケージをインストールすると困る。」ということがわかってきていたので、 個人用マシン１でいい感じにインストールできたライブラリだけをインストールしていました。

その後、個人用マシン２を買ってからは、パッケージ管理というものがあるのもある程度わかり、virtualenvやpyenvを使いだしました。 Pythonのパッケージは、pipでインストールするようになりました。

最近は、基本的に、Python3のvenvを利用して環境を作り、pipでライブラリをインストールしています。 そうするとあんまり、Python周りの開発環境は汚くならないようになりました。

じゃあ最近は何を困ってるの？というと、vim周りのプラグインですね。

僕はPythonの開発環境に、vimを使っています。 なんで、vimを使ってるの？というと、vimを使ってる人がコーディングしているのを見て、 「vimってコーディングはええええええ！！！カッケーーー！！！！」ってなって、僕もそれやりたいと思ったからです。

で、最近、vimを開発環境をもっと整えたいと思いながら、色々模索しています。 そして、NeoBundleというvimのプラグイン管理のライブラリ？を使っています。

ただ、この仕組みがあんまりよくわかっていないのか、ちょっと個人用マシン２の環境がおかしくなっています。 ちょいちょいプラグインのインストールエラーが出たり、動きがなんかおかしいような気がしたりします。

研究用マシンを作った時と同じく、仕事用マシンをインストールする時は、 結構慎重にインストールするので、環境は汚くなっていないのですが、個人用マシンが・・・・ね。

ってわけで、vimの環境をいい感じにしたいんだけど、どこからやり直せばいいんだろうと思っています。 vimの環境をクリーンにして、vimrcだけ持ってきたい気持ちです。

どうやったらいいんだろう。 vimを一旦アンインストールすればいいのかなあ。