TAMINIF’s blog

大阪在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

RedashのDatasourcesにMySQLがなかった場合の対処法

はじめに

RedashのDatasourcesにMySQLが出てこなかったので、その調査と解決策です。

TL;DR

PythonのMySQL用ライブラリ（MySQL-Python）をAPサーバにインストールする

何が起きているか

Redashでは、Datasourceごとにクライアントライブラリが存在するかをチェックし、存在しないDatasourceは新規作成時に表示されません。

Redashの環境構築を行う際、docker-compose.ymlを使用してDocker上で全て完結する場合は全てのクライアントライブラリをインストールするpipコマンドが実行されるようDockerfileに記載されています。（requirements_all_ds.txt）
ただ、こちらの記事にある開発者向けの環境構築手順では、Datasourceをインストールする手順が省略されているため、いくつかのDatasourceは表示されません。

何もしなくてもいくつかのDatasourcesが使用できる理由

環境構築で必要なライブラリだからだと思われる。
例えば、Postgresqlはライブラリがimportできるかのチェックすら行なっていない。これはおそらくPostgresqlをRedash自身が使用するため、ライブラリは確実にインストールするためだと思われる。
他にも、MongoDBやAmazon Athenaは、Redashのユニットテストで使用しているため初期から表示されている。

MacにMySQL-Pythonをインストールする

pipでインストールするだけでは動きませんでした。

pip install MySQL-python

また、全てのDatasourceをインストールしようとしても失敗しました。

pip install -r requirements_all_ds.txt

インストール失敗時に表示されたエラーメッセージを読み、こちらの記事を参考にしました。 stackoverflow.com

まとめ

Docker Composeで構築した場合と自分で構築した場合で表示されるDatasourcesが違ったり、いくつかのDatasourcesは最初から利用できることから
最初はとても戸惑ったけど、中を読めばわかる内容だった。
ドキュメントではLinuxでの環境構築が書かれており、Macで環境構築しようとすると少し手間が必要になる。
他に同じような内容で困っている人がいればこの記事が参考になると幸いです。

わからなくても読む。いずれ理解することを目指す

導入

最近、設計について解説されている本や設計パターンの本をいくつか読んでいる。
そんな中、このツイートとこの話題を取り上げているブログをいくつか読んで、自分は今読んでいる設計の話が本当に理解できているんだろうかと不安になった。

私自身、本を読んだだけで理解できたとはまったくもって言えないし、理解するのにまだ時間がかかると思っているけど
そんな状態でも読むことに意味があるんだと信じたいのでブログでまとめる。
読む対象は本だけではないです。ブログとかのインプットするもの全般です。

まずは用語だけでも目に入れておく

今回のケースは、本を読むことである程度理解できる人ではなく、
なんとなく、主張はわかるけど実際にどうやれば良いのかわからないという人がテーマになる。
私もそういうタイプの人間で、すぐ理解できなかったり、その場では理解できるまで読み込むようなことをしないタイプだけど、それはそれで良いと思っていて
まずは用語を目に入れて、どこかのシーンで「見たことある」というようにしておくことを心がけている。
そうすることで、他の記事を見かけた時に少しずつ前提知識がついていって理解が進むようになると思う。

自分が携わるシステムに触れる時に読む

業務でもプライベートでも、どこかでシステムに関わる機会はあるはずで
そのシステムが自分一人だけで作っているものでない場合、最初に作った人や大きな部分を構築した人の思想というのは絶対に入っているので
それを読んで、システムの理解だけでなく背景や思想まで読み取るような習慣をつけると、思いがけず過去にみた事ある設計パターンの理解に繋がることがあると思っている。

実体験してわかることもある

プログラミングを始めた頃、「オブジェクト指向」や「MVC」について、何を言っているか全くわからなかった。
設計図を作るから何？再利用できるなら関数で良いんじゃないの？って考えてたけど、ちょっと経験を積んで、有名なフレームワークのソースコードを読んでみると
ああこれがMVCか、なるほどこうすることで綺麗なコードになるんだと理解できるようになっていた。
なので、いきなり全てを理解できることはなくて、実際に使用されているシステムのコードを読むだとかその中で開発するという経験はあると理解が進みやすいと思います。
そういう意味では、一つのサービスだけではどうしても触れる領域というのは限られてくるので、小さいアプリを作ってみるとかOSSに参画してみるとかで機会を増やす方が良いと思います。

まとめ

ある意味、一つの勉強法の話かもしれないなと思いつつ、思ったことを書いた。 今回は設計の話で思ったことだけど、これって設計に関わらず全ての事象で言えることだよなーと思ったので、タイトルに設計というワードは入れなかった。
事前にちょっとずつ入れようという話ではあるんですが、別の考え方も持っていて、これってYAGNIの原則とは離れた考え方だよなと思った。
なのでそこは、完全に理解するのは必要になるまで不要ということで結論としたい。

「ファクトフルネス」読んで最後まで感動した

FACTFULNESS(ファクトフルネス)　10の思い込みを乗り越え、データを基に世界を正しく見る習慣
読んだ。最初のきっかけはTwitterだったかブログだったか忘れてしまったけど、最初は「ビル・ゲイツがアメリカの大学を卒業した学生のうち、希望者全員にこの本をプレゼントしたほど」という触れ込みに興味を持った程度だった。ただ、読み終わった今は読んで良かったと思っている。とても良い本だった。
最初から書いてしまうんだけど、「終わりに」の文章まで最高だった。この本を書いたハンス・ロスリングという方が、本を書き始めて約半年で余命宣告をされて、それからこの本を書くことだけために余生を費やしたこと、それでも最後は完成させる前にこの世を去ったこと、救急車で運ばれた時も原稿を手にしていたこと、この本を妻と子供が最後まで完成させたことが2ページ程度に書かれていたのだが、偉大な人がまさに人生をかけて書いた本ということがすごく伝わった。素晴らしい内容だった本が、より感銘を受け感動した。もしあなたがこの本に興味があるのなら、必ずこの本は読んだ方が良いとお勧めできる本である。

「ドラマチックすぎる世界の見方」は正しくない

あなたは、世界は悪くなっていると考えているだろうか？戦争・暴力・災害は減ることはなく、貧富の差は広がっていると考えていないだろうか？
少なくとも紛争は減っているし、災害発生時の支援や救助は年々整備されている。だからその見方は正しくない。だけど、人間はそういう見方をする生き物だ。
「ドラマチックすぎる世界の見方」を変えるのは難しいが、ドラマチックな本能は抑えるべきだ。

ファクトフルネスと事実の見方

どうやって「ドラマチックすぎる世界の見方」を抑えるか、それは、世界を事実で見るようにすることだ。
先ほどの紛争や災害発生時の被害者は、年毎のデータを見ればわかることだ。データを見れば、「ドラマチックすぎる世界の見方」をすることはなくなる。
この本は、ファクトフルネスの方法を習慣化するための手助けをしてくれる。

10の本能と、それを抑える方法

この本では、「ドラマチックすぎる世界の見方」をしてしまう10の本能について紹介されている。

  • 分断本能
  • ネガティヴ本能
  • 直線本能
  • 恐怖本能
  • 過大視本能
  • パターン化本能
  • 宿命本能
  • 単純化本能
  • 犯人捜し本能
  • 焦り本能

どれも世界の見方を曇らせるもので、どういうものかとなぜそうなってしまうのか、その回避方法が説明されている。それをここで全部書いてしまうとただの本を写すだけになってしまうし、ちゃんと文章で理解してもらえる内容を私に書く力はない。
この本を読んでその通りだなと思ったことはいっぱいあって、一例を出すと、どんなに勉強をしている人でも一度手に入れた知識をアップデートすることは少ないと思う。この本はそれについても言及されていて、過去の知識を元に考えてしまうことがあると思う。それが不変なものなら問題ないが、世界情勢が不変なことはありえない。
世界は常に変わっている。だから、今の知識をデータで見て、アップデートすることが必要だ（宿命本能）

まとめ

10の本能はひとつひとつ読み応えがある内容なので、ぜひ買って読んでいただきたい。
この本を読んだ後、世界に希望が持てるようになるとのことだったが、確かに読む前と読んだ後で世界の見方が変わった気がする。
自分もクイズの正答率はチンパンジーより悪かったし、事実を見れていなかったので反省している。
ファクトフルネスの10のルールは写真に撮っておいたので、なんども見返しながら実践していきたい。

SkyWayのiOSライブラリ知見二つ/peer.destroyとSKWMediaStream

はじめに

本日ハマったので備忘録を二点残しておきたいと思います。
iOSアプリでSkyWayを使ったアプリを実装する場合に、peerオブジェクトを必ず明示的に破棄するようにしましょう
そして、SKWMediaStreamの操作をするときはメインスレッドで実行しましょう

TL;DR

画面遷移などで一度接続したpeerを破棄する場合は、peer.destroy()しないと次回接続時のSKWNavigator.initialize(peer)を実行した時にエラーが発生しないまま動作がストップする。
SKWMediaStream.addVideoRendererするときはもちろん、SKWMediaStream.closeするときもメインスレッドで実行しないと接続が切れるまでUIがストップする。しかも、止まるのを待たないまま動かし続けるとフリーズする
(completionhandlerのような接続断後に実行できる関数はない)

経緯

どちらも、以前動いていたものが動かなくなって報告をもらってから調査を行なったもの。
ソースコードは一切変更していなったので、なぜ突然動かなくなったのかはわからない。
おそらく以前から動かなくなっていたと思われるが、リリース当初は問題なく動いていたため、いつからかは不明。

peer.destroy()

ビデオ画面に入室 <-> 退室を繰り返した時に2回目のSKWNavigator.initialize(peer)を実行したタイミングでエラーも出ず、次の処理にも進まない事象が発生した。
SkyWayのSwiftライブラリは中のソースコードを読むことが出来ず、ステップ実行でどこで止まっているかもわからないためいくつかのサンプルコードを読んで実行して問題ないことを確認した上で、ビデオ終了時にpeer.destroy()せずにpeerにnilを格納して破棄しているだけであることを発見、解決した。

SKWMediaStream

こちらもビデオ画面に入室 <-> 退室を繰り返した時に、2回目の退室後に入室前画面に戻りはするも、画面がフリーズする事象が発生した。
こっちはどこで処理がストップしているか不明だが、前画面には戻っていて処理は全て完了していたので、こちらもサンプルコードを探して
公式のサンプルではDispatchQueue.main.asyncでremoveVideoRendererを実行していたため、こちらを参考に修正することができた。

まとめ

SkyWayのiOSライブラリは情報が少なく、原因を調査するのが難しいので
こういうブログでWebに知見を残していきたい。

精神が疲弊しているので本を読んで勉強する

年末から年明けにかけてここ二ヶ月くらい、公私ともに忙しい日々を過ごしていている。それ自体はありがたいことなのだが、仕事が終わって帰ってくるなりほとんど何もできていない。休日もいろんなところに出かけていて、まともに時間が取れないこともあって、最近はほぼアウトプットできないでいる。
ハードワークというわけじゃなくて、精神的に負荷がかかっているのも影響があると思っているのだが、パソコンを開いてもあまりモチベーションが上がらないまま時間が過ぎてしまう。
何もできないとやっぱり焦りはあって、今はできるだけ頑張れることを頑張るようにしていて、その一環で本を多く読むようにしている。でもインプットするからにはアウトプットもした方が効率が良いし、この二ヶ月で読んだ本について良かった本をアウトプットする。

禅マインド ビギナーズ・マインド (サンガ新書)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか という本で、リーダーシップパターンの中に「禅マスターになる」という章がある。リーダーはどのような状況でも禅の心を持って平静を保ち、知識に沿った判断をするというものである。これとは別に、仕事の上でついつい感情的になってしまう傾向があり、自分を俯瞰する技術を身に付けたいと思ってどうすれば良いか考えたときに、禅を学ぶことを決めてこの本を読んでみた。

このツイートはわりと本音を書いていて、読んだ結果は全然わからなかったというのが正直な感想である。
ただ、禅とはそういうものらしい。本を一冊を読むだけではわからないとは思っていたけれど、禅は学び続けるのでちょっとずつ学びたい。

おとなの教養 私たちはどこから来て、どこへ行くのか? (NHK出版新書)

面談で教養つけた方が良いんじゃない？と指摘をもらって、Amazonで「リーダー 教養」で検索して良さそうなのをいくつか見繕って買った本のひとつ。前にも池上さんの本は読んだことがあったんだけど、この人の本は読みやすくてすぐ読めるのが良い。
歴史や宗教が人を形成していったことがわかりやすく説明されていて、教養がなかった私にも、すでにある人も再認識するという意味で良い本だと思う。

自分は教養をちゃんと理解できているか怪しいけど、これから多くの人と関わる上である程度多くの人が持っている普遍的な情報を持たないといけないと思っていて、こちらも時間をかけて学んでいきたいと考えている。

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

世界中の人と仕事をする際に、その国のコミュニケーションの方法、仕事の付き合い、評価の伝え方などそれぞれで違った文化を持っていることを知り、その国に合わせることで仕事をスムーズに進めるという本で、とても参考になった。
日本で働くだけであれば国に合わせるようなことはそうそうないことだが、自分の職場にも海外で育った人が働いて、その前提を持って話をすることはひとつのテクニックだと思うので、実践できればと考えている。

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

コードもあまり書けていないのだが、この機会に基礎的な本を読もうと思ってこの本を読んだ。
「3年目までに身に付けたい100の原則」とあるように、プログラミングする上で知っておくと綺麗なコードになると思う参考になる本だった。
自分はもう9年目なのですでに遅いかもしれないが、どれだけ時間がたっていてもちゃんと学ぶべき内容だったし、読んで良かったと思う。
「コンウェイの法則」など、この業界で何年か働かないとスッと入ってこないような内容もあって、読み直すのもオススメしたい。

リーダーが育つ55の智慧

ニトリに行った時にこの本が積んであるのを見たのと、記事などでこの人の特集を読んだことがあって
気になっていたので、この機会に読んでみた。
上のツイートの通り面白かったし、人には向き不向きがあっていろんな舞台でチャレンジさせてあげるとか、
常に改善を行うなど、実践してみたいと思う内容だった。

今読んでいる本

FACTFULNESS（ファクトフルネス）10の思い込みを乗り越え、データを基に世界を正しく見る習慣

まだ第1章を読んだだけだが、面白そうで楽しみにしている。
私も事実を見ずに印象だけで思い込んでいたので、この本を読んでちゃんと物を見れるようになろうと思う。

まとめ

なんとなくだけど、海外の本で翻訳されたものと日本の本ではボリュームが違うのはなんでだろうと思った。
ちなみに弊社は本を全て会社で購入してもらえるので自分で買った本はない。 いずれまとまったアウトプットはしたいが、そのためにもちょっとずつ勉強できたらと思う。

Node.js Advent Calendar 2018に参加しました

今年もQiitaのAdvent Calendarに参加しました。今年はNode.jsで記事を書きました。 QiitaのAdvent Calendarなので毎年Qiitaに書いてるのですが、こちらのブログにもリンクを貼っておきます。

Qiitaの記事

qiita.com

良いpuppeteerライフを！

github.com

「別にやっても良いですよ」という人たち

これは自戒の意味も込めて書く。何かやる必要がある時のスタンスの話。

「別にやっても良いですよ」という人たち

チームで何かやる必要があるときに、タイトルのことを言う人を観測範囲で結構見かける。たまに自分も言う。
やってもやらなくても良い時に言う傾向が高いと思うが、あまり良くないと思うのでその理由を書く。

タスクを任せづらい

正直なところ、消極的な人にタスクを任せるのはめんどくさい。
善意での発言かもしれないが、任せるのであれば「やりたいです！」や「やりましょう」と言ってくれる人に任せたい。
これは感情的な話なのかもしれないけど、そういうスタンスでやってくれる人の方が良い結果を出す傾向があると思っていて、
それが誤りでないとわかるまでは、この感覚は信じたいと思う。

自分ができないならまずやらないという姿勢を見せる

そのタスクが技術的・時間的にできないのであれば、チーム内でその姿勢をちゃんと見せた方が良い。
他のチームメンバーの判断を迷わせることになる。
消極的な姿勢はチームに悪い効果だと思う。

やらなくても良いタスクなら最初からやらない

チーム内でタスクの提案が誰かからあった時、それがやる必要があるかどうかをまず判断すべきだけど、
やる必要がないタスクであれば、最初からやらないという決定をすれば良い。
そうなってないなら、やる必要があるタスクだということになる。

やる必要があるなら

結局誰かはやるのだし、面白いタスクでもつまらないタスクでもやった方が良いと思う。その理由も書く。

面白いタスクなら

今までできなかった経験かもしれないし、やってると楽しいタスクかもしれない。
そのタスクをやることで成長できるなら、やらない選択肢はない。

つまらないタスクなら

自分がそのタスクをやることで、他のチームメンバーがより大きなコミットを出せるならそれはチームの功績になる。
特にあなたがマネージャーなら、他のメンバーの障害になりそうなタスクを積極的にやる方が良い。これはTeam Geekにも同様のことが書かれている。
(サーバントリーダー)
ただし、自分の優先度と比較して、それより大事なタスクがあるならちゃんとそっちを先にやろう。これだけは忘れてはいけない。

自分ができないかもしれない時は

技術的に難しい場合は、チームにそれを伝えた上でやるようにしたい。でもチャレンジするのは良いことだと思うので良い機会だと思ってやろうとする方が良いと思う
時間的に難しい場合は、タスクの優先度をちゃんと判断して決めよう。
いずれにしても、積極的にできないことをチームに伝えよう。

まとめ

チームで働く上で、チームに良い結果をコミットしていくことは重要だと考えていて、
そのためには積極的にチームに参加していくようにしたい。
言いたいことを十分に伝えられてないかもしれないけど、いずれにしてもタイトルのスタンスはやらないようにする。