はてなブックマーク

前回の「機械学習に本気で取り組むためにやった数学周り 前半戦結果」の記事から早くも半年近くが経過しました(覚えてくれている人いるだろうか…)。本当に時間が過ぎるのは早い。とりあえず2017年前半の締め括りの季節として良い時期になってきたので少々早いですが後半戦結果を書きました。後半戦では 色々な軌道修正・計画の調整を行ったため 前半戦に記載している流れになっていない部分がありますがご了承下さい。 ● 2017年1月 – 6月 後半戦結果 2017年1月後半 – 線形代数復習 昨年8月にやっていたのだけれど、幾何的な理解はできていたが理論的な理解が浅いままで割と苦労したので改めて時間を設けて固めることにした。 【勉強時間: 35時間】 2月 – 最適化数学 → これなら分かる最適化数学―基礎原理から計算手法まで ラグランジュの未定乗数法とか最適化問題の考え方の基本はこの本で習得した。未定乗数

機械学習等で最近国内でも徐々に人気の高まりつつあるPythonだが、雑多なタスクの自動化等しているうちに Pythonが結構しっくり来ている。 せっかくならWebアプリケーションもPythonでつくれるようになりたいなあということで Flask, Pyramid 等色々調べていたが、まずはDjangoでしょ という事で Djangoを始めた次第。 そんなDjangoだが、Vagrantによる導入時点で早速ハマった事があったので備忘録として残しておく。 環境は以下を使用しました。 ・Python 3.4.3 ・Django 1.7 ・Vagrant 1.7.4 ※ 前提として Python, Django, Vagrantは既にインストール済みであること。 プロジェクトをつくる $ django-admin.py startproject blog このコマンドを使用することによってカレント

先日無事入籍を終え、結婚式に向けてあれこれ準備が必要になるということで、友人の何人かがやっていたように家庭内でRedmineを導入した。「結婚式準備」プロジェクトを立ち上げて暫く運用していて 最近ようやく運用が落ち着いてきたため、今度は少し欲が出てきた。 現状、チケットが更新されるタイミング・何のチケットが更新されたか等タイムラインでしか把握できない状態になっているので、Slackを使って チケットが更新されたらリアルタイムに通知が飛ぶようにした。最近一部の界隈では家庭内でこういうツールを導入するのもよくある流れになってきたのかなあとは思う(ねーよ)ので、流行に便乗してみようといった所だ。導入・設定に苦戦するかなあと思ったら、元々Redmineが入っている状態から15分くらいで意外とサクッと導入できた。 これまで 家庭内でRedmineを導入したのはおよそ一ヶ月前のことだ。使い方としては、

最近個人的にアプリケーションのみならず ミドルのあたりを触る機会が増えて、サーバのパフォーマンスを意識するようになってきた。 とはいえそのあたりの負荷テストに対する認識等、割とざっくりとやってしまっていたので ここらで一度しっかり落とし込んでおこうと考え、色々調べてみた。 特に「秒間にさばけるリクエスト数って、何をもって秒間●リクエストって言えるのか」 とか、 「秒間リクエストを測る際に、ユーザごとの端末の違いは考えなくて良いの？例えば有線のPCと3Gのスマホだと全然速度違うから、サーバ-クライアント間のコネクションが続く時間も変わってきてしまうんじゃないの？」 とか色々考えていたけど、調べているうちに自分なりに何となくハッキリしてきたので 情報の整理がてら共有。 もしかしたら認識誤りで 間違った事を言っているかもしれないので、その場合はご指摘いただければ本当に嬉しいです。 「秒間リクエス

ご無沙汰です。 本当は「数千万件のデータが入ったテーブルでインデックスを構築したらパフォーマンスが劇的に改善された話」というタイトルで書こうと思ったのだけど、書いているうちに内部構造が気になり出したので上記のタイトルに変更。 まずはパフォーマンスが改善された話から SELECT A FROM hoge WHERE B = ~~~ ORDER BY C DESC; hogeは数千万件のデータが入ったテーブルで、その中から結果約4万件程のデータのうち A の部分をSELECT。条件としては、カラムBの値が~~~に合致するときで、更には Cという別のカラムで並び替えるというクエリになっている。 結果的に ALTER TABLE hoge ADD INDEX foo ( B, C, A ); というインデックスを張ることによって、それまで2分以上かかっていたselect文が 0.1秒～0.2秒まで

ご無沙汰です。連載企画を書き進めると豪語しておきながら かなり経過してしまいました。連載企画の方は時間を見つけつつ少しずつ書き進めていければと思います、申し訳ございません。 さて、最近周囲の方にGitの解説をする機会が増えてきたため、今回はGitの基本コマンドに関連する説明をします。 対象読者 ・何らかの理由でGitを使う事になったが、コマンドが多くてよくわからない方。 ・コマンドごとの意味は何となく理解しているけど、イマイチピンと来ない方。 (※「そもそも何故Gitを使う必要があるのか」「バージョン管理とは何か」といった点については ノンプログラマ向けの連載企画として後日記載させていただければ幸いです) 解説するコマンド git init, git add, git commit, git status, git log, git branch, git checkout, git me

前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ

本に書いてある通りやっても何故かバリデーションが通らない。 何度やっても「Password Missing password」と怒られるばかり。 物は試しとGoogleで似たような人がいないか検索してみるが それらしいものは見当たらない。 試しにModelを全コピするが一向に改善しないため、どうやらtypoではないようだ。 ( 元々3.2系の本だから ちょいちょい仕様が変わってたりするんだよなあ…今回もその周りのにおいがプンプンする ) それでもって POST時にユーザから渡って来たログを出してみて、その値を確認してみた。 Parameters: {"utf8"=>"V", "authenticity_token"=>"c4yT/Bt6ypoDW5rl119tndpOZgLLAE4pv824XPZXRdM=", "user"=>{"name"=>"aef", "password"=>"[F

そろそろキャッシュの一つくらい導入した方が良いだろうということで、以前勉強会でお話させていただいた方にご紹介を受けた Varnish をいじってみることにした。3日間いじってみて、色々と感じる事があったので 今後Varnishを触られる方の為にも情報を残しておこうと思う。 Varnishとは? 「HTTPアクセラレータ」と言われている。Squidの数倍速いと言われている。 簡単に言えばHTTPサーバの前にリバースプロキシサーバとして待ち受けてくれて、メモリ上にキャッシュがあればキャッシュを基にレスポンスを返すし、無ければバックエンドのHTTPサーバから取ってくる。 Varnish関連で学んだこと(実際にVarnishをいじられている方向け) デフォルトだとポート番号は6081だけど、基本的に80番で待ち受けるように書き換えているケースが多い …ので、httpdのポート番号を変更したり

久々の更新。 土曜日は これまで何となく使っていたVagrantを本格的にいじっていたけど、知れば知る程便利だなあ。 Vagrantfileって Gruntfileみたいに何となくいじるのが面倒くさそうな印象があったんだけど、実は全くそんな事がなくて 寧ろちょろっとやれば誰でも簡単にいじれるようになるくらい学習コストが低かった(まだChefと絡めていないので Chefと連携させると若干話が変わってくるかもしれないけど)。 というわけで今回は Vagrantを使ってUbuntuサーバを2台立てて MySQLでレプリケーションを構成してみた話を。 今回に関してはどちらかというとVagrantよりMySQL寄りの話になります。 Vagrantに関しては boxの構造とかVagrantfileの事とか 色々と整理できたので 後日 初心者向けにvagrantの基本的な事柄についてまとめます。 Vag

覚えたてのマクロの練習がてらつくってみた。500バイト程度で実装。ファイル出力がなければ400バイトくらい？ (defmacro css (name elems) (with-open-file (*standard-output* (string-downcase name) :direction :output :if-exists :supersede) `(progn ,@(mapc (lambda (style) (let ((elem (car style)) (attrs (cadr style))) (format t "~a {~%" elem) (loop for i in attrs do (format t "~2T~a: ~a;~%" (string-downcase (car i)) (cadr i))) (format t "}~%~%"))) elems))

ようやくSICPが終わった。念願の夢の1つを叶えた。「ポインタを理解する」「コンパイラをつくる」とかから始まり 今年に入って 技術者として個人的にやりたかった事を3つ実現できた。良い調子。 サムネは記念にマッカーシー先生(再使用が許可された画像)。 完了までの期間 3.5ヵ月程度。平日は帰社後に2～3時間ほど、毎週土日はSICPに費やした。 学んだこと・できるようになったこと 1. より抽象的に物事の仕組みが考えられるようになった。 (「言語」という制約されたドメインを取っ払って純粋に実装について考えられるようになった) 2. 再帰のコードは悩まなくてもスンナリ頭に入るようになった。 3. Eval & Apply の陰陽によるプログラムの成り立ちを理解した。 4. 数学・コンピュータ科学に関する以下のことが人に説明できる程度には身についた。 - Newton法 - エラトステネスの篩 -

< ご注意 > ・難易度に関しては完全に個人の主観となります。 参考までに僕個人のスペックを記載しておくと、高校2年の数2Bまで終わってるくらいのレベル感です。アカデミックな数学はパッパラパーです。 ・また、各Exerciseの難易度に関しては そのExerciseの所まで勉強した時点でのスキルセット・理解度を想定した難易度を書くようにしています( つまり、既に後の章も勉強して記述に慣れた状態での難易度ではないので、前の章の★3つと後の章の★3つのレベル感が大きく異なります )。 第1章 難易度リスト 第2章 難易度リスト 第3章 難易度リスト 第4章 難易度リスト 第5章 難易度リスト 1.1 プログラムの要素 1.1.6 条件式と述語 1.1 ★ (これまでの部分ちゃんと読んでればしゅんころ) 1.2 ★★ (見た目程怖くない.括弧の組み合わせに慣れるには良い問題) 1.3 ★★ (こ

ようやくSICPの第1章が終わったので、これからSICPの勉強を始められる方に向けて, SICPの第1章に関する個人的なまとめをおくりたい。 SICPの第1章を学ぶ上で必要になるもの ・1ページ1ページしっかり理解しながら進む忍耐力。数ページ 飛ばし読みするだけで分からなくなるので注意( 特にExcerciseは 問題を理解する手助けになる上, 前のExcerciseで定義した手続きが後のExcerciseで何回も出て来たりするので, 1章に関しては全ての問題を飛ばさずにやることをオススメする. 実際、1章に関しては後述の高校数学の基本的な計算さえ理解していれば、「どうあがいても絶対にできない」というような絶望的な問題は存在しない )。「ん？ちょっと雲行きが怪しくなってきたな…」と感じ始めたら迷わず一度戻って勉強し直した方がよさげ。 ・高校数学。所々に複雑に見える数式があるけど, シグマ計

最近コンピュータサイエンスの独習に身を入れるようになって感じたのが、巷で溢れている「数学を学べば頭が良くなる」っていう論は、抽象を扱えるようになる・抽象を組み合わせて更なる抽象をつくり複雑系に立ち向かえるようになる上で、数学という学問が最適だからなんじゃないかなあということ。 ( 「仮説を立てる力」とか他にもいろいろな要素があるけれど、今回は「抽象」という話題にフォーカスして考えたい ) 「抽象」を理解する上で数学が最適だと思う理由 「抽象化されたモデルを扱うこと」や「抽象化されたモデルを組み合わせて新たな抽象をつくること」を学ぶ上で、特定のドメイン固有の問題によるノイズを極力減らし、問題の本質と向き合うことができるからだと思う。 例えば「オブジェクト指向」という概念について考えたい。僕たちはオブジェクト指向の概念に基づいて 抽象やその組み合わせによる抽象を構築する。ただし、「オブジェクト

「兼ねてから自分で電子工作してみたいなあと思いつつ、自分のような全くの初心者は一体どこから始めればいいんだろう…」 以前Raspberry Pi も買ったけど、自分で好きなものを自由に作ろうと思ったら回路図とか各パーツのはたらきとかちゃんと理解していないと駄目っぽい(実際 Raspberry Pi とか買ったはいいものの結局どう扱えば良いのかわからず持て余している人も少なからずいると思います。僕とか僕とか僕とか )。 ということで、周囲の人にも相談の上、まずは元々キットとして世の中に存在しているものをつくっていく中で ちょっとずつ全体観を掴んでいくのが一番よいかなと思いました。僕自身シンプルな物事を複雑に考えるのが大好きな人間なので、正直回路とか制御工学とか理論的な事いっぱい勉強したい人だけど、まず現物をいじってみない事にはイメージがつかずピンとこない(=効率が悪い)ので。 そんなわけで、

ここ1年、こういう内容の記事をよく見るようになった。 言っていることはもっともで、「ああ確かにそうだなあ」と共感する部分も多い。 今後技術が発達していく上で間違いなく単純作業は減っていくのは確実だろうし。 ただ2点自分が願うとしたら、彼らが語る「プログラマ」の定義を明確にして欲しいということと、彼らの論が必ずしも業界全体に当てはまることではないことを明確にして欲しいということです。 彼らが語る「プログラマ」の定義 何かしらのサービスを成功させている、もしくは成長の真っ只中にいる人がこういう事を語る場合、彼らの思い描く「機械に取って代わられるプログラマ」像は、いわゆる「与えられた仕事を淡々とこなすだけ」の人の事を指している場合が多い。 ちょっと考えればその人の語らんとしているプログラマ像はわかるとは思うけど、誤解する人もいると思うので、こうした定義は明確に書かれていたほうが親切だと思う。 余

比較的規模の大きいソースコードを見る際、何らかの目的を持った上でソースコードを読み始める。 目的の粒度は大なれ小なれ「コードのどこに着目するか」という疑問は必ず生じる。 パズルも完成形の絵柄を知らずに組み立てるのと 予め出来上がった後の形を知った上で組み立てるのとで 完成の時間が変わってくるように、ソースコードもその全体の形ができるだけ見えた方が良い。 とはいえ、数千行～数万行のコードを相手に 自分の手で一つ一つのクラスの役割や関連性を整理するのも得策ではないので、ここは一つ先人の知恵を活用した方が良さそう。 ということで、今回はソースコードリーディングのお供として活躍してくれるドキュメント自動生成ツール「Doxygen」と、構造体やクラス間の関係を図で出力してくれる「Graphviz」を紹介。 プログラミングの勉強中に何かの本のサンプルコードを読み解く上でも十二分に力を発揮してくれるので

プログラムを書いていて、次に何を学習するべきか と考えることが度々あった。 その度に 「プログラマ 成長」 「プログラマ ロールモデル」 「プログラマ 1年目 本」 なんておもむろにGoogleの検索フォームに入力して、 世の中で話題になっている人のロールモデルを参考にしようと色々見ては、その人が「小さな頃から親にハードを与えられていじって遊んでいて…」というように、幼少の頃からコンピュータに深い馴染みがあることを知って「ああ 自分のケースとは合わないな」なんて思ったり ウィザードと呼ばれている人達の論文を読んでは「もっとコンピュータに詳しくなろう」と思い立って、 Web系にも関わらず 何の脈絡も無く、突然 SICPや分厚いアルゴリズム本をかじり出しては途中で挫折したり、 ( 学習した事が現実的にどういった形で結びついているのかわからないから現実感が湧かない ) そんな事を繰り返していた。

久々の更新。しばらくRailsで趣味の開発に没頭しておりました。 というわけで 今回はRESTful Web APIs読書会(第三回)の参加報告を。 今回は主に「リソースの定義」と「HTTPリクエストの種類」と「安全性・べき等性」のお話。 ・リソースの定義 リソースというと結構個人的に定義が曖昧で、データベースのデータとかがメインになるのかなと思っていたけど、どうやらRESTにおいて URIで表現されるものは全てリソースになるらしい。 そしてリソースの状態は以下の二つによって表現されうるらしい。 ( 2013年12月1日改正、コメントより「リソースが（同じ状態で）複数の表現を持つ場合に、クライアントは望む表現をどのように指定するか、の選択肢である」といただきました。必ずしも二つではないということですね ) 1. Content negotiation( 「内容ネゴシエーション」とも。HTT

RESTful Web APIs 読書会 #2 に参加してきた。 RESTful Web API？ 要約すると以下のような感じ。 ・Webサービスだとハイパーリンクとかをたどって ユーザは目的達成できるけど、APIの場合って  多くの場合ドキュメントがWeb上に別個に公開されていて、URLだけ見てもわからない上に、ドキュメントを見ても個々の機能がどのように関連しているかがわかりにくいよね ・そもそも そういうWeb APIのあり方って 自己記述性の点でどうなの？(=RESTfulじゃないよね) ・自己記述的なものが含まれていて、最初のURLさえあれば使い方がわかるようなAPIが理想的だよね そこで RESTful Web APIの著者は Collection+JSON というフォーマットを推奨している。 Collection+JSONとは？ JSONが汎用的でプレーンテキストを扱うものだと