ちょっとしたきっかけで毎月一定額を寄付してる。
寄付先は World Food Programという団体。
理由は、
学校で給食が出るようになると、親にとっては子供を学校に行かせる大きなモチベーションになる
という話を聞いて「なるほど〜」と思ったから。
この世界をよくするためには教育が重要だと思いますので。
WFP には本家団体と日本の代理店的な団体がある。
日本の代理団体の方に寄付すれば税制上の優遇措置がうけられる。 一方、寄付額の 1/4 くらいは日本での活動費として使われるため、実際には寄付額の 3/4 しか寄付先には渡らない。
それを元に日本で活動することで日本企業からの大口の寄付を呼び込めたりするわけだから、意味のある費用だとは思う。 でも、自分の寄付がなるべく直接活動に使われた方が嬉しいなぁ、と思って本家に寄付してみてる。
たしか寄付額の 93% がそのまま活動に使われる、と書いてあった。
月数千円からできるので、ぜひあなたも寄付してみてはいかがでしょうか。
ちょっと必要があって Tensorflow.js を勉強している。
Tensorflow のようなボリュームのある新しいフレームワークを目の前にすると、わくわくする気持ちがある反面、「自分には理解できるのだろうか」という不安にかられる。
その不安を前にどうするか。
少し前までは、一度に大きなことを理解しようとしてうまくいかないことが多かった。結果として「とりあえず動くものを作る」という方法で不安を解消しようとする。でも、この方法では不安は解消されない。なぜなら、結局のところ対象を理解していないから。
最近は「小さく理解する」ことでこの問題が劇的に改善した。
必ず、シンプルで悩まずとも理解できるようなコードから始める。そうすると「自分でも理解できるんだ」という小さな自信が芽生え、安心感が得られる。難しい問題に出会ったとしても蓄積した自信と安心感によって、挫けることが少なくなる。挫けることが少なくなると、理解できる可能性がずいぶんと高まる。
「小さく理解する」というツールはここ最近の自分にとって欠かせないものになった。
Tensorflow.js は、このページから始めるのが「小さく理解する」のにちょうどよかった。
https://js.tensorflow.org/tutorials/core-concepts.html
// 2x3 Tensor const shape = [2, 3]; // 2 rows, 3 columns const a = tf.tensor([1.0, 2.0, 3.0, 10.0, 20.0, 30.0], shape); a.print(); // print Tensor values // Output: [[1 , 2 , 3 ], // [10, 20, 30]]
これなら僕にも理解できるからね。
Coursera: Deep Learning Specialization の Course 4: Convolutional Neural Networks を修了しました。
内容としては次の通り。
こうやって書いてみると四週間でなかなか頑張ったじゃないか、という感じ。 かといって毎週毎週量が多くて大変、ということはなく、楽しく勉強できたなーって思った。
ただ、今回のコースは今までと違って「さわりだけ押さえておく」って感じで、実務で使いたければもう少し勉強しないとだめかなーって印象。 でも、その「もう少し勉強するための下地」は身についた感じがあって、あとは必要に応じて教科書とか論文を読めばなんとかなりそう。
次は最後のコースで RNN。いろいろの都合で6末開始になりそうだなぁ。
Coursera: Deep Learning Specialization の Course3: Structuring Machine Learning Projects を修了しました。本当は1ヶ月くらい前に終わってたけど…。
内容としては次の通り。
今回のコースはかなり実践的な内容で「AI プロジェクトはこうやって進めましょう」というような話がメイン。こういう実践的な内容はこの講義でしか受けられないんじゃないかなーと思った。
単一の Metrics を設定するとチームパフォーマンスが高まる、プロジェクトは iterative だからからシンプルなモデルをまずは実装しましょうとか、最初に Error Analysis をしましょう、とか。AI プロジェクトに限らないといえばその通りだけど。
Deep Learning はハイパーパラメータが特に多い中で、どのハイパーパラメータがどの Metrics を改善・悪化させるかを意識するのはとても重要。この講義ではそれを昔のテレビのチューニングノブに例えていた。複数のノブを同時に操作してしまうと、何が起きているか分からなくなってしまうので、どのノブがどんな影響を持っているか正しく把握して、それぞれ個別に操作していきましょう、という話だった。
12 Factor App シリーズ。2個目は依存関係の管理について。
Dependencies: The Twelve-Factor App
12 Factor app は決してライブラリに暗黙的に依存しません。
プログラミング言語にはライブラリを管理するためのパッケージマネージャが存在します。
システムワイド (site-package) にもインストールできますし、app を含む特定のディレクトリだけにインストールすることも可能です (vendoring or bundling) が、決して site-package にインストールするようなことがあってはいけません。
OS 側のツールにも暗黙的に依存してはいけません。
たとえば暗黙的な ImageMagick や curl の存在には依存してはいけません。 すべてのシステムに存在することや適切なバージョンが存在することを保証できないからです。
もし、ツールが必要であれば明示的に依存関係を書かなければなりません。
すべての依存関係は依存関係宣言を使って明示的に宣言されます。 また、app の実行時には依存関係分離ツールを使って依存関係がシステムに漏れ出さないようにしなければなりません。
これは開発環境にもプロダクション環境にも適用されます。
Ruby では依存関係宣言のために Gemfile を利用し、依存関係分離のために bundle exec を利用します。
Python では依存関係宣言のために Pip を利用し、依存関係分離のために Virtualenv を利用します。
たとえ C 言語であっても依存関係宣言に Autoconf を利用し、依存関係分離のために静的リンクを利用できます。
たとえツールが何であろうと、依存関係宣言と依存関係分離はは常に一緒に行う必要があります。
macOS High Sierra の更新に失敗してしまい、次のようなメッセージがでて OS が起動できなくなった。
macOS could not be installed on your computer
再起動しても同じエラーで起動できない。 これはまずい。。。
まず「起動できない」という状況を打破したい。 次の記事を参考にして通常起動できるようにした。
http://sublimelife.hatenablog.com/entry/2017/12/15/103447
ただ、この方法は単に更新をスキップしているだけなので、このままだと最新の High Sierra にいつまでも更新できない。。。
最新の状態にならないのは困るなぁと思い少し調べると、
Apple のサイトから手動で dmg を落としてきて更新するとうまくいくよ
という報告を発見。
今回は High Sierra 10.13.4 への更新に失敗していたので、次のサイトから 10.13.4 の Combo Update dmg をダウンロードして更新したらうまくいきました。
https://support.apple.com/kb/DL1959?locale=ja_JP
きっと、この方法ではうまくいかないケースもあるのだろうけど、同じような事態に遭遇している人たちの一部にでも役に立てば…。
12 Factor App シリーズ。最初はコードの管理について。
Codebase: The Twelve-Factor App
12 Factor App は常に Version Control System で変更をトラックしています。 このリビジョンのデータベースは Code Repository と呼ばれ、単に Repo と呼ばれることもあります。
Codebase は一つの Repo に相当し、Codebase と app は１対１の関係を持ちます。
もし、複数の Codebase を持つのであればそれはもはや一つの app ではありません。 それはなんらかの分散システムとなります。
ただし、分散システムを構成する一つ一つのコンポーネントは app として扱うことができ、それら一つ一つは 12 Factor App に適合することができます。
複数の app が同じソースコードを共有していることは 12 Factor App 違反です。 その場合、共通のコードをライブラリとして切り出し、依存関係を管理するようにするべきです。
一つの Codebase が一つの app である一方、一つの Codebase に対して複数の deploy は可能です。 この場合、deploy は app が動作する一つのインスタンスだと考えます。
deploy には production や staging 環境などが考えられます。また、ローカル環境での開発も deploy の一つだと考えることができます。
Codebase は app と１対１てあるため、すべての deploy において Codebase は同一である必要があります。しかし、それらで違うリビジョンがデプロイされることはありえるでしょう。
(c) The King's Museum
