山本ゆうごブログ

山本ゆうごの仕事メモ

目的別プログラミング言語

プログラマー初心者が疑問に思う「どのプログラミング言語をやればいいの?」という質問。プログラミング言語の文法などはそんなに違いがないのでどうやって選んだらいいかが分かりづらい。言語仕様意外で決める要素があってそれに引っ張られるころが多いということがあまり知られてない。

動作環境で決まる

  • Excelを自動化したければ、Excel上で動くVBA
  • ブラウザ上で動かしたれば、JavaScript
  • メーンフレーム上で動かしたければ、COBOL
  • LambdaやFirebaseのようなサーバーレスアーキテクチャなら、JavaScript(Node.js)
  • Unityで開発したければC#
  • Windows上の.netフレームワーク上で動かしたければ、C#
  • iOS上で開発したければ、Objective-CかSwift
  • Apacheモジュールとして動いてほしければ、PHP
  • 大規模なマシンの性能をフルに使いたかったらJava

動作する環境で決まるということが多い。

利用できるライブラリ・フレームワークの差で決まる

  • scikit-learn という統計・機械学習ライブラリを使いたかったら、Python
  • numpy などの行列計算を簡易にしたければ、Python
  • RailsなどのWeb+DB系のライブラリを使いたければ、Ruby
  • 標準モジュールだけでWeb開発をしたければPHP
  • スマホ向けの3Dエンジンのライブラリをつかいたければ、Unity(C#)

利用できるライブラリ、フレームワーク(雛形みたいなもの)というのは、言語仕様そのものではなく、そのプログラミング言語をより便利にするために、プログラマー達が「育てた」とも言える。プログラミング言語そのものは、用途を絞ることはあまりないが、ライブラリやフレームワークは特定の用途にフォーカスした形で育成される。PythonもRubyも同じことはできるだろうが、機械学習用のライブラリの充実と、Webサイト向けのライブラリの差は歴然としている。

当然のことながら、RailsというRubyで作られたフレームワークも所詮はひな形なので、別のプログラミング言語でもできる。PHPはもともと言語仕様からWeb開発向きではあったが、Railsほどの雛形にはなってないので、PHPにもフレームワークで開発すれば「Apacheプロセスの中で動くから軽くて開発生産性も高い」という美味しいとこ取りをするケースもある。

swiftでも頑張れば、スマホ向けのアプリは作れるが、大半のスマホゲームメーカーはUnityを使って開発をしている。ゲーム向けのライブラリが充実しているからである。反対に生活ツールではUnityはあまり使われない。

Progateは素晴らしい。だが他にもやることがある。

こちらのエントリ読んで思うところを書いています。

「progateをどれだけやったら仕事ができるの?」に採用について考えてる側から答えたい – fukaminmin – Medium

自社でもエンジニア採用をしているのですが、Progateやプログラミングスクールを経て、プログラマーになろうとしている人は多くいます。

プログラマーになろうとしている人の背中を押してあげるという点では、これらの初心者向けのサービスは本当に素晴らしい。ところがいくつか困ったケースができはじめています。

Progeteのみを永遠と続けていて、エディタを触ったことがない

自社の採用は「未経験OK」とはしているのですが、プログラミング勉強中の人にはFizzBuzz(のような超シンプルなソース)はその場で書いてもらっています。メールで出題をして、結果をメールで返信してもらいます。

  • Progeteでしか書いてないので、エディタは持ってないのですがいいですか?
  • Progateの問題にないコードは書いたことがないので、実行せずに書いたまま出します

あとは、Progateの中でしか実行してないので、ターミナルそのものを触ってないという人もいます。カレントディレクトリの概念がないとか。

ターミナル、コマンドプロンプト、CLI、シェル いろいろいい方はありますが、「黒い画面」で「ファイルをいっぱい繋げていく」というのが、プログラミングの基本です。プログラミング「言語」に引っ張られすぎて、まるで語学習得のようになってないでしょうか。

Progateは料理教室みたいなもの

料理教室はこの世に必要なものですが、料理教室で「しか」料理をしてないというのはよくない。料理教室だと以下の訓練ができません。

  • 食材を買ってくる訓練
  • 食材を貯蔵する訓練
  • 調味料をそろえる訓練
  • 献立を考える訓練
  • 味見をして、レシピを改善していく訓練
  • 同じレシピを繰り返し安定して作る訓練

単に料理本をみて、そこから食材を買いに行くというだけでも十分カバーできることはあります。

そんなわけでProgeteの外で頑張らなくちゃいけないこと

Progateは初心者にプログラミング言語を網羅的に教えてくれるのだけれど、それだけだと足りない。

タッチタイピングの練習をしよう(まさかのここから)

今はスマホネイティブの人も多いので、PCで高速チャットをする機会がない。だからタッチタイピングができないまま、Progateをやりつづけていたり、合宿系のプログラミングスクールに行ったりする。タイピングスピードが遅いというしんどさだけではなく、画面をみながらタイピングができないということは、Googleの第二キーワードもエディタのコードアシスト機能も使えないということ。キーボード見ちゃダメ。絶対。TwitterもPCでやりましょう。Twitterはキーボードのみでほとんどの操作ができます。

新規のファイルからソースを書こう

ファイル名をつけるところからスタート。Proagateみたいに予めファイルが用意されていて、そこを修正するだけなので、ほとんどエラーがでない。実際にはタイピングしているとたくさんのスペルミスがある。requireで指定しているファイル名と、実際のファイル名が違うことなんてベテランでもしょっちゅうある。私はよく「俺たちはファイル製造マシーンだ」といい切ってる。新しいファイルを適切なディレクトリに作るという訓練をたくさんしよう。

読む能力を身に着けよう

どのプログラミング言語も、本屋にいけばテキストがある。テキストだからそれそのものは面白くもなんともない。だけどいずれは、テキストだけで勉強しなくちゃいけなくなるときは来る。プログラミングの楽しさって、「できあがったプログラムが便利だった」というところなので、正直勉強は苦しくても別にいい。そして殆どのドキュメントには公式ドキュメントがある。公式ドキュメントは最初はとっつきにくいだろうけど、読めるようになろう。

読解力というのは人それぞれかなりの差がある。「読むと頭に入らないが質問のキャッチボールでは頭に入る」という人もいる。だけどプログラミングというのは、どこまで行っても読み書きの世界。読み書きの得意な先輩方が作られた業界だから、覆しようがない。適切に質問をする能力が身についているのなら、人間相手ではなく、Googleに聞けばほとんどの答えが載っている。

ググり方を身に着けよう

タッチタイピングができるようになったら、Googleで検索して適切なサイトか適切な情報を引っ張り出す訓練です。Progateは中のテキストが充実しているので、困ったときにスライドにジャンプできます。しかし実際のプログラミングではそのスライドを探し出すところからやらなくてはなりません。適切なワードでググりましょう。ググったら上から順に「これは欲しい情報なのかどうか?」「まともな人が書いてそうか?」などの重み付けをしながら参照します。公式ドキュメントやstackoverflow(英語版)の評価の高い解答などは大事ですね。

エラーメッセージの「ちょうどいい部分」をググるというのも大事です。

環境構築が大変なら環境構築が楽な言語から手を付けよう

Webプログラミングといえば、Railsという相場観があるかもしれないが、残念ながらWindowsだとrbenvの段階で辛い。Railsまでいかなくても、単体のRubyなら十分手元で勉強はできる。またWebで公開して他人に触ってもらいながら学習を進めるのも効果的。そうなると、フォルダコピーだけで本番反映が可能なPHPの方が学習からフィードバックまでのサイクルは早い。ロリポップのようなレンタルサーバーでもすぐ動かせる。

仕事でエクセルをよく使うのなら、エクセルVBAから始めたって構わない。繰り返しや分岐などは全く変わらない。VBAのエディタはIDEとしても完成度が高い。本当にプログラミング初心者ならVBAから初めて、Web系言語にシフトしても全然遠回りじゃない。

手元に自分のサンプルソースをたくさん作ろう

どんなリファレンスよりも、自分で書いたコードが一番あとで参照しやすい。だからできるだけ自分の手元においておこう。絶対あとで見る。Progateを一通りやったら、全く同じ課題を、自分の手元のPC上で書いて、手元のPC上で実行するというのもいい。絶対別の苦労がでてくる。だけどその苦労は仕事でエンジニアになった時には乗り越えなくちゃいけない苦労。

手元でたくさんのサンプルファイルを置くのは、「うまいこと動いているバージョン」「動かないバージョン」と複数バージョンを置いて比較をしながら学んでいくことができます。プログラミングの最初は、「Hello World」と出力するだけのプログラムですが、「いろんな文字列を日付としてパースするサンプル」のようなサンプルソースはベテランになってからも手元でちょこっと作ります。小さくても「手元で動いたプログラム」がリファレンスとしては最高です。

自分ひとりが便利なものから始めよう

プログラミング初心者が作りたいものというと、Railsで作った何かしらのコミュニティサイトを上げる人が多いです。ところがコミュニティサイトはプログラミングだけではなく、Webサーバーのセットアップや管理から、掲示板が荒れした時(もしくは誰も来ない時)のコミュニティ運営まで幅広いスキルが必要になる。PDCAサイクルが一周する時間が長すぎます。

手始めにおすすめなのは、自分がよく見るサイトのスクレイピングツール。定期的にWebサイトを巡回して、欲しい情報があれば、そのサマリーを自分あてにメールで送ったりするツール。このレベルなら、Rubyでクラスなんて作らなくてもできちゃう。継承だオーバーライドだインスタンス変数だとか知らなくても、誰かの生活を便利にすることはできる。自分でやり始めて「あれ、修正すると既存機能が壊れやすいなぁ」とか「部分的なテストがしにくいなぁ」みたいな課題感を持ってから、クラスを覚えたって構わない。まずはプログラミングによって人が幸せになるのだというところは実感したほうがいい。

その点では、エクセルVBAは職場の人が即幸せになる可能性があるので、入り口としては馬鹿にできない。

環境構築もいずれはチャレンジしよう

「環境構築だけがクリアできない課題」という言い訳はあるものの、「エラーメッセージが出る→ググる→ちょっと直してみる→前回と比較してみる」というステップはエンジニアの仕事そのものです。「適切な情報源から適切な文書を取り出して読む訓練」ができれば、環境構築もできます。

オススメのプログラミング学習方法

こちらの記事に感化されて書いてみる。

www.vivi-life.com

「個人差」がかならずあるだろうとは思っているし、「成長過程」に関しては「自分」をサンプルとしている以上は、どうしてもサンプルが少なすぎる。私個人の話と、実際にたくさんのプログラマー向けの研修をしていたときの肌感覚を元に書きたい。

一つ一つ解きほぐしたい。

「一番最初の苦痛から逃げ出さなければよかった」 → 苦痛な時点でしんどくないか

私が一番最初に作ったプログラムは「アクティブなウィンドウに下矢印キーを一秒おきにSendKeyするツール」だった。理由は自分が欲しかったから。ご飯食べながら長い文章を読みたい。コードそのものは10行程度でいいが、勉強にはそこそこの時間がかかった。でも達成感ありまくりだった。自分でも長いこと使っていた。

プログラミングとは料理のようなものなので、自分が食べて美味しいかどうかで上達したかどうかが分かる。試食なしにただひたすらレシピを丸暗記するだけなら、料理はとても苦痛だろう。

その点では、会員制Webサイトというのは、たくさんの人に使ってもらうもの。料理で言えば「レストランを経営してみましょう」に近い。まずは自分一人が使って、楽しい/便利 なものを作るのが入り口としては正しい。

「周りがコードをかけて当たり前の環境に行けばよかった」 → でもその人達も一人でやってること多い

先輩も結構独学でやりきっている。聞けば分かるかもしれないが、先輩方は聞かずに答えにたどり着いていることが多い。もちろん聞けば早いが、聞ける環境にないからといって、あまりハンデだと思わないでいい。うちの研修でも、基本は自分でググる力をつけることを主眼に置いている。「調べ方が分からない」のであれば、調べた方を聞いた方がいいとは思う。

「周りに質問に答えてくれる人をそばにおく」 → なくても構わない

逆に聞かないと進めないとなると、なぜ一人で進めれないかを考えたほうが良い。イマドキは掲示板で聞けるし、ちょっと検索してみると似た質問を投げている人もいる。質問を文章にする能力があれば、検索はできるはず。検索ができないとなると適切な質問もできないと思う。

「プログラミングの勉強の要は、読書によることも多い」 → 月間20万円も買わなくても良い

月間20万というと、2000円の本が100冊なので、読めないのではないか。勉強の順番をつけて順に買っていけばいいと思う。私が初心者の頃に買ったのは、CとPerlの言語の教科書あとSQLの教科書。それ以降に覚えた言語はWebのリファレンスのみで分かるようになった。

「アウトプットをどんどんすればよかった」 → これは絶対にそう

アウトプットはひたすら繰り返す方がいい。だからアウトプットの単位が「会員サービス」だと大ぶりがすぎる。「ちょっと便利なコマンドラインツール」くらいを連発するのがいい。

「コードリーディングをもっとすればよかった 」 → 目的がないと読めない

漠然と読んでも仕方ない。コードリーディングのキモは、「自分がやりたいことのパクリ元を探す」ということだと思う。やりたいことが強くないと読む気も起きないのではないか。

「最初から大きな理想を描き続けない」 → 絶対にそう

今日一日で完成するものを作るというのが理想。下ごしらえはしていいけど、今夜食べるまかない飯も必要。

「最初のプログラミング言語でRubyを選択してよかった」 → Rubyなの?Railsなの?

プログラミング初心者がパニクってるのが、自分がやってるのがRubyなのかRailsなのかが混乱しているというところ。セットでやろうとするからしんどい。

学生さんでサクッとWebサービスを公開しているのをみると、PHPで無料のレンタルサーバーで公開している。覚えることが圧倒的に少ないので公開は楽。ゴリゴリに自分でHTMLを書かなくちゃいけないけど、HTTPとHTMLの理解という点では理解しやすい。そして何よりも安いサーバで公開できる。ことWebプログラミングという観点では、PHPから入る方が理解が早いと思う。

逆にRailsのみで入った人で、scaffoldだけでtodoリストを作って「何が起きているかが分からない」という初心者もいる。FizzBuzzが書けないレベルでWebサイトが作れてしまっているので、「逆にどこから勉強していいのか」という話になる。PHPでフレームワーク無しで書いてみることで、フレームワークの中でやってくれていることが肌でわかると思う。

本当のプログラミング初心者には、以下の順に覚えてもらっている。

  • rubyのコマンドラインのプログラムを大量につくる
  • SQLを単体で覚える
  • フォームからDBにエントリーする仕組みをSinatraで作る(自力で全部書く)

業務で会員向けのサイトを実装するときにはRailsを使うけど、裏で何をしているかは自分で理解しないといけないのでトレーニングの段階では浅めのフレームワークで勉強する方がいい。

オススメの書籍

一つか2つプログラミング言語の本を前から順に習えば、あとはネットの情報でなんとかなるのではないかと思っている。

ネットの情報の中でも単なるトラブルシューティングではなく、ネット上の公式ドキュメントにあたるということ。rubyならrubyリファレンスマニュアル。phpならphp.net。公式ドキュメントって、イラストがないのでそっけないのだけれど、書いてることは正しい。公式ドキュメントが読みづらいなら、公式ドキュメントを読む力を身に着けた方がいい。

検索にもこつがある。

  • サジェストされる第二キーワードもよく見ながら検索しようね
  • 英語でググることで、より多くの検索結果にヒットする
  • site: 演算子で公式ドキュメントの中だけを検索できる

など。特に英語での検索は大事。たまーに「パイソン ループ」というカタカナで検索している初心者がいるが、英語の方がいい。

Linuxコマンドなどは、書籍がどうというよりも、man とか --help で、ドキュメントをみた方が手っ取り早い。ググる必要さえない。英語だけどそのままカタカナとして読めばいい。本を買う事自体はダメではないが、manから逃げる姿勢はほんと良くない。

「コンピューターはグローバルで便利なもの」なんだから、プログラマーが勉強する際にもコンピューターをフルに使いこなせた方がいい。

あとエラーメッセージも初心者が軽視しているポイント。画面に出た文字をちゃんと読むということは超大事。

プログラミングの勉強はどの道を進んでも結局重要 → その通り

ここに、結構大事なことを書いている。

大学の実験結果を解析する時、Excelでちょこっとマクロを組んだり、データをRubyに流し込んで解析をするみたいなこともできるようになります。

逆に、ここからスタートするのが健全なのではないかと思う。Excelをたくさん使ってる人のためにExcelVBAを書いてあげる。そして業務効率があがることでプログラムが発揮した価値を確認する。まさに職業プログラミング。個人向けWebサービスを作るだけが仕事じゃない。

最後に「Webサイト以外のプログラムの用途」が出てきたが、プログラムってのは人間の見えないところで働くケースも多い。Webサイトの形で動いているプログラムはほんの一部。プログラムを学ぶこととWebサイトを作ることはイコールではないし、それ以前にプログラムが社会に与える影響はWebサイトでのみ発揮されるものでもない。ラズベリーパイで自分の家の家電を自動化するというのでも十分プログラミングだし、価値も発揮されやすい。

調整さんの正しい使いかた

簡単みんなのスケジュール調整ツール「調整さん」を作った|blog|たたみラボ

調整さん リリースから10年以上も経つが、そもそもツールだけでは解決しないことが多々ある。 元々はメール文面で、日程調整をしていたのをビジュアル化したいというニーズから作ったものなので全ての課題を解決してくれるわけではない。

調整さん以前に時間調整ってどうするのかということを記したい。

例えば、会社の飲み会の調整。

二週間前後くらいあとの日程で

直近だと急すぎる。先すぎるともっとだいじな予定が入るかも知れない。なので、二週間前後くらいがちょうどいい。

自分の予定はまずはブロック

たまに見かけるのが、自分があとで日程候補に△とか書いちゃうケース。日程候補は自分が行ける日だけにしましょう。

会の重要性を伝える

行っても行かなくてもいいのか、必ず来て欲しいのかって重みは大事。既に予定が入っていてもそれを押しのけるべきかどうかも受けての判断ポイントになる。

調整さんで日程候補を出す前にキーマンの予定をブロック

ありがちなミスが、キーマンが調整さんに最後に予定をいれて、全滅というケース。まずは偉い人の予定を先に確保する。その確保された選択肢を、調整さんに候補として登録する。そして招待する際に「○○さんのブロック済みの候補です」とアナウンスしておけば、下々のものは「ならそっちに寄せるか」と判断しやすい。

日程候補を多くしすぎない

二週間くらいのレンジで飲み会日程候補がやってきたとしても、全てに◯とは書きづらい。「現時点での空き」を伝えるのではなく「日程調整が終わるまでのブロック」を差し出すことになる。二週間全部空いていたとしても、ユーザは「ブロックを差し出す数件」のみ◯にしちゃうので、結果的に日程が合わない。

選択肢は「できるだけブロックして欲しい数件(常識的には最大5件程度)」を提示するのがいい。

入力をお願いする

全員が入力されない場合もある。優先度が低い人は「ではこの日程に決まったのでできれば参加してください」と伝えるし、優先度が高い人(そして往々にして忙しい人)に対しては、直接会ってでも入力を促す。もしくは会ってその場で彼のスケジュールをブロックしながら候補を埋める。会えない人には電話をする。一対一のコミュニケーションでお願いする。

まとめ:時間調整は結構な意思決定を促している

調整さんというお手軽ツールを作っていながらもやっぱり幹事は気を使うべきだとは思ってる。偉い人も偉くない人も時間は平等に24時間。その時間を何らかの予定のブロックとして「差し出す」のは結構な投資/消費の意思決定をしている。その二時間で仕事をする以上のものが得られるのか、その二時間で一本の映画を見る以上の楽しみがあるのか。「どうか私に貴方の二時間を下さい。後悔はさせません」という気合でコミュニケーションをとるべき。

RDBにバイナリファイルを置くメリット

RDBにはBLOB型があって、そこにはバイナリファイルを置くこともできる。

あんまり有り難みがないかもしれないだけれど、個人的には結構よく使ってる。

以下、いいところだけをピックアップする

複数マシンから寄ってたかって使いたいとき

処理マシンのローカルにファイルを置くと共有できない。NFSみたいなものを使えばいいのだけれどそういうの作るのが面倒。開発環境と本番環境で揃えるのも面倒だ。

削除がしやすい

大量のファイルをローカルストレージに置いちゃうと、rm -rf だけですごい時間がかかっちゃう。黙ったままなので進捗も分からない。これが、RDBに置いたら、trancate 一発で削除できる。そもそもローカルストレージでファイルが多いと、lsだけでもビタット止まっちゃう。

ステータス管理しやすい

RDBなので、BLOB型の隣には、status(int) みたいな適当なフィールドを作っておいて、この画像サムネイル作ったっけ?みたいなステータス管理がしやすい。キューもかねたストレージとして扱える。

集計しやすい

select DATE_FORMAT(updated_at,'%Y/%m/%d %H') as ymdh, count(updated_at) as cnt  from テーブル名  group by ymdh;

こんな感じで、一時間おきのファイルの更新ペーストとかが分かる。

メモリに載せやすい

MySQLにはクエリキャッシュの機能がある。イマドキはいっぱい詰めるので、極端なはなしDBの中身が全部乗っけることもできる。クエリキャッシュは元データが変わるとキャッシュも破棄されるので、プログラマが意識する必要がない。どれくらいキャッシュにヒットしたかもSQL一発で分かる。ディスクのIOよりも、ネットワーク越しのメモリアクセスの方が管理しやすいってこともある。

SequelProならバイナリファイルもそのままみれる

SequelProというMySQLクライアントがめちゃくちゃよくできていて、バイナリファイルはプレビューができちゃう。jpgだけじゃなくてPDFまでプレビューしてくれる。めちゃくちゃ高速に検索できるファイルサーバとして使える。

そもそも、S3でいいのでは?

それはそもそう。容量あたりの単価も安い。ただ、ステータス管理とかしたくなると、S3のメタデータだけだとやや不便。そこは別途キューとかRDBでステータス管理したくなる。惜しい。「今日更新されたファイル一覧が欲しい」って検索条件がぱっと思いつかない。

僕はいつもこんな感じでざくっとデータをみている

CSVがドーンとあったとする。その際にどうやってデータを見るかってのは、なんとなくの手順がある。その手順を示しておく。

wc -l でみる

まずは行数をみる。10万行とか超えちゃうとExcelでは重すぎてみれない。

less コマンドでみる

そして中を確認する。lessコマンドでみれるのはutf8縛りなので、SJISの場合は別のエディタなどで開く。 中身が何かを確認する。 先頭にBOMがついているかどうかや、LF改行なのか、CRLF改行なのかくらいはここで分かる。 大きなファイルも早く開けるのがlessコマンド。先頭行と最終行はチェックする。

Excelでみる

文字コードを変換する

nkf -s utf8.csv > sjis.sv

で、SJISに変換する。UNICODEのままでExcelで開きたかったら、以下のコマンドでBOMをつける。

cat <(printf "\xEF\xBB\xBF") 元ファイル > BOMつきファイル

Excelで開く

数値の前ゼロが取れちゃうから、普通はCSVをダブルクリックしちゃだめなんだけど、参照専用と割り切って、ダブルクリックして開いちゃう。

フィルタをかける

フィルタをかけて、▼をクリックする、そうするとどういうデータがあるかが分かる。空白の存在などもここで分かる。ゴミデータが入ってないかが分かる。

ピボットテーブルを作る

ピボットテーブルを作ることで、データの分布が分かる。特に日付のフィールドがあれば、ピボットテーブルを日付でグループ化して、年単位や月単位の分布をみて、傾向をつかむ。

mysqlの場合

CSV単体が見づらい場合はmysqlなどのRDBでみる。

ひたすら並びかえる

データの異常値がないかどうかは、ひたすら並びかえて確認する。sequel proやphpmyadmin などのツールであれば、sqlを書くこと無く並び替えが用意なので、そこでみる。

ひたすらグループ化する

select DATE_FORMAT(updated_at,'%Y/%m/%d %H') as ymdh, count(updated_at) as cnt  from テーブル名 
group by ymdh;

こんな感じで、時間単位の更新時間を並べて見て、どういう処理ペースで動いているかを確認したりする。

そのままメールに出力結果を貼り付けたい時などは、FORMAT関数でカンマ区切りにしたり、LPAD関数で左空白詰めをして右揃えにしたりする。

BiqQueryの場合

MySQLだけだと、数百万件を超えるデータは扱いにくい。並び替えやグループ化をするデータはインデックスを貼ればいいのだが、インデックスをはるにもマシンパワーが余分にとられる。そこまでくれば、インデックスに気を使わなくてもいい、BigQueryをつかうのがいい。

ただ、CSVを参照可能にするにもそこそこの手間がかかる。

CSVはUTF8

UTF8のダブルクォート区切り。フィールド内ダブルクォートはダブルクォート二重でエスケープ。

CSVをgz形式にする

BiqQueryに入れるレベルのCSVファイルは、GBを超えるくらいなので、アップロードに時間をかけなくてもいいように、giz圧縮をする。

gzip -c data.csv > data.csv.gz

Google Cloud Strageにアップする

gsutil cp data.csv.gz gs://bucket/data.csv.gz

この段階で、Googleの認証が必要。gsutilもインストールしてる前提。認証は、gsutil auth で認証をする。

この際に、GoogleCloudStrageのプロジェクトIDが必要。GoogleCloudStrageのプロジェクトIDとBigQueryのプロジェクトIDは同じ方が権限的に楽。

bq コマンドでロードする

bq load --source_format=CSV  --skip_leading_rows=1 --project_id=XXX aaa.gz   gs://zzzz/aaa.gz \
id:integer,\
name:string

各カラム名とその型を、スキーマとして引数にしていしている。シェルとしては一行だけど、見づらいのでバックスラッシュで改行を入れている。

bq コマンドを最初につかうときにもGoogleの認証は聞かれる。 AWSみたいなアプリケーションキーを環境変数に入れておくというような手法でない。accountを切り替えるのは面倒。

BiqQueryで集計して、レポートにする

ひたすらグループ化のSQLをたたく。集計の結果は、SpreaSheetに出力できるので、ポンポン出力する。適当なファイル名で出力されるので、出力されるたびに、スプレッドシートのファイル名を変えたほうがいい。

スプレッドシートに出せば、グラフにポンポン変換できるので、グラフ化して、スライドの資料にポンポン貼っていけばいい。スプレッドシートには、SPARKLINEという関数があって、セルの中にちょっとしたグラフをかける。Excelでいうデータバーみたいなことができるので手軽。

f:id:yugo_yamamoto:20171015103510p:plain

ポンチ絵のナゾ

ポンチ絵は大事で嫌い

ポンチ絵は嫌われている。

Bubbles don't crash! という言葉がある。Bubbles というのは、ドキュメント上に書かれた図形のことで、ドキュメントをいくら頑張って描いても、その間違いって気づき用がないということ。だからエンジニアの間では、ソースコードの方が重視される。それがシステムを表しているし、間違っていたらエラーがでる。

しかしながら、ソースコードを見せてもそれが何なのかはわからないし。プログラムの外のこと(ユーザーとか銀行とかとの関係)は分からない。

そのシステムの社会的な位置付けを示したいときには、どうしてもポンチ絵が必要になる。大事なのは「システムの外」ということ。

規格としてのポンチ絵 UML

UMLという規格はあるのだが、ポンチ絵にはあまり役に立たない。基本は「自社のシステム」を作るためのものであって、他者との座組を示すものではないから。

ポンチ絵の定義

ラフイメージという位置付け。ハードウェア業界の人達は、製品の完成イメージ図や設計図のラフイメージをポンチ絵と言うし、企業ごとの提携を示すにもポンチ絵という呼び方をする。

ここでは、相関図をポンチ絵を呼ぶことにする。

ビジネスマンでなくてもポンチ絵は大事

例えばオリラジ中田のブログ。 http://lineblog.me/atshikonakata/ https://obs.line-scdn.net/0hWjYbkdvnCEVkGybdC6R3Ei5GDiodeBJNDmMffxFNAmsRdx9FDGEXZgNCDi8XdB9JCDgXPzVoADECLxRDXA9AUUJSLAlKQj1bDgpHKidHCCUKdAZHRH1CK0MbVHZIKkYTUC9PI0QZE3ROKRwaUChO

めちゃくちゃポンチ絵を使ってる。

ポンチ絵のわかりづらさ

学問がない

文学でもない。経済でもない。自然科学でもない。一番近いのは語学ではあるが、ジャンルとして存在していない。だから習うことができない。

ルールがない

ルール化されたのがUMLではあるが、一般的ではない。

ハンディキャップ仮説としてのポンチ絵の存在

本当にコミュニケーションを円滑に刷るために作られたのかさえ怪しい。「頑張って図がいっぱい入ったパワポ資料を作りました」ってスタイルは存在する。

というとで色々サンプルをみながらポンチ絵の存在をみてみよう

日経新聞はこれ http://www.nikkei.com/paper/article/?b=20170502&ng=DGKKZO15973950S7A500C1MM8000 http://www.nikkei.com/paper/image-article/?R_FLG=0&ad=DSKKZO1596443001052017MM8000&ng=DGKKZO15973950S7A500C1MM8000&z=20170502

日経新聞なので、登場人物やら組織やらの間を矢印で繋いで、お金の流れを表すということが多い。

http://www.nikkei.com/paper/article/?b=20170502&ng=DGKKZO15970070R00C17A5TI1000 http://www.nikkei.com/paper/image-article/?R_FLG=0&ad=DSKKZO1597009001052017TI1000&ng=DGKKZO15970070R00C17A5TI1000&z=20170502

この図の場合はもやは矢印が何かさえ言い表してはない。ただ、登場人物は明らかで、なんらかの取引のルールとが矢印で表されているということだけは分かる。

ポンチ絵で抑えるべき箇所

  • 登場人物を箱で書く
  • データ・モノ・お金の流れを矢印で書く

登場人物(組織)を発注などの情報を矢印で結ぶ。「誰が」→「誰に」という風にイベントのトリガーを元にする。 複数の登場人物がいる場合には、直接コミュニケーションをとっているのが誰かというだけでも分かりやすい。

アマゾンの例では、発注の流れではなく、在庫の流れを示してると思われる。普段は出版社はAmazonと直接取り引きをしていないが、日販に在庫がない場合には直接取引をしていることを示している。

形にはこだわりすぎない

日経のAmazonの例をみてみる。出版社はビルだし、日販は本の束だし、AmazonAmazonと書いているだけだ。じゃぁそれが分かりにくいかっていうとそうでもない。Amazonも何らかのイラストつけてあげなよとは思うけど、そこをモタモタするくらいなら、単なる長方形でいい。

社内用途ではロゴが分かりやすい

ロゴって勝手に使っちゃいけないから社外向けのドキュメントには書きづらい。日経もそうだと思う。一方でビジネス用途では本当にその会社を示すためにロゴを使いたいときもあるので、そういうときにはロゴを使った方が視認性が高い。