タグ

ブックマーク / postd.cc (13)

  • 勾配降下法の最適化アルゴリズムを概観する | POSTD

    (編注:2020/10/01、2016/07/29、いただいたフィードバックをもとに記事を修正いたしました。) 目次: さまざまな勾配降下法 バッチ勾配降下法 確率的勾配降下法 ミニバッチ勾配降下法 課題 勾配降下法を最適化するアルゴリズム Momentum(慣性) Nesterovの加速勾配降下法 Adagrad Adadelta RMSprop Adam アルゴリズムの可視化 どのオプティマイザを選ぶべき? SGDの並列化と分散化 Hogwild! Downpour SGD SGDのための遅延耐性アルゴリズム TensorFlow Elastic Averaging SGD 最適化されたSGDに対する更なる戦略 シャッフル学習とカリキュラム学習 バッチ正規化 早期終了 勾配ノイズ 結論 参考文献 勾配降下法は、最適化のための最も知られたアルゴリズムの1つです。これまではニューラルネット

    勾配降下法の最適化アルゴリズムを概観する | POSTD
    bouzu_ao
    bouzu_ao 2017/07/30
  • ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD

    最小限の設定のTDD手法を使い、「何をテストすべきか?」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出

    ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
    bouzu_ao
    bouzu_ao 2016/06/18
  • 2015年の最優先事項は関数型プログラミング! | POSTD

    —もはやOOP(オブジェクト指向プログラミング)は”クラウドモンスター”から私たちを守りきれない おそらくあなたは、”Clojure”、”Scala”、”Erlang”といった言葉や、”Javaにラムダ式が導入された”という話を聞いたことがあるでしょう。そしてそれらの言葉が”関数型プログラミング”と関連があるのをご存じかもしれません。プログラミングコミュニティに参加していれば、おそらく既にこのテーマが議題に上がっているでしょう。 Googleで”関数型プログラミング”を検索しても、目新しいものは何も見つかりません。言語の中で2番目に古い言語は、関数型プログラミングを利用しています。1950年代に登場した、Lispという言語です。では一体なぜ人々は、今になって関数型プログラミングに沸き立っているのでしょうか? およそ60年も経っているのに? 初期の頃、コンピュータは実に遅かった 信じられない

    2015年の最優先事項は関数型プログラミング! | POSTD
  • APIデザインにおける七つの大厄介 | POSTD

    (編注:2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか(私がしたことを見てください)。 リスティクル(箇条書き形式の記事) を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」

    APIデザインにおける七つの大厄介 | POSTD
  • 依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD

    記事はRubyについて書かれたものではありますが、PythonJavaScriptJavaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 番環境で読み込まれるテスト用Gem 数百メガバイトもRAMをRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ

    依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD
  • Angular 2で作った最初のアプリの事後分析 : 使ってわかったAngular 2の長所と短所 | POSTD

    最近、Angular 2を使ってWebアプリ作成の手伝いをする機会がありました。このフレームワークの複雑さに戸惑いもありましたが、Angular 2は間違いなくすばらしいものです。この事後分析では私がAngular 2のフレームワークを使った時に感じたいい面と悪い面の両方を掘り下げていくことにします。 Angular 2 Angularは携帯電話やデスクトップのWebアプリケーションを作成するための開発プラットホーム。 https://angular.io/ Angular 2+リアクティブプログラミング=❤ 私はすでに、Angular 1アプリケーション ではRxJSをかなり使っていました。特に、サービス間のメッセージ・バスを行うアプリを作成する時です。Angular 2はObservableを非常によくサポートしているので、アプリ全体にリアクティブプログラミングを取り入れることができ、

    Angular 2で作った最初のアプリの事後分析 : 使ってわかったAngular 2の長所と短所 | POSTD
  • Go言語の並行性を映像化する | POSTD

    Goというプログラミング言語の強みの1つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす

    Go言語の並行性を映像化する | POSTD
    bouzu_ao
    bouzu_ao 2016/03/16
  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
    bouzu_ao
    bouzu_ao 2016/02/22
  • AWSで避けるべき5つの間違い | POSTD

    今年からAWSAmazon Web Services)クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈:(左から)DNS、CDN、静

    AWSで避けるべき5つの間違い | POSTD
    bouzu_ao
    bouzu_ao 2016/01/28
  • データサイエンスのワークフロー ― データ分析を効率に行うために | POSTD

    データを扱うときに、きちんと定められたワークフローがあると助かります。具体的には、「ストーリーを伝える」(データの可視化/ジャーナリズム)ことだけを目的として分析を行いたいのか、それとも一定のタスク(データマイニング)をモデリングするためにデータに依存するシステムを構築することが目的なのか、プロセスが重要です。前もって方法論を定めておくことによって、チームの足並みが揃い、次に何をすべきか考え出そうとして無駄な時間を費やさなくて済みます。それによって早く結果が得られ、資料の公表も早くなります。 これを念頭に、Ashley Madisonの漏洩データ分析に関する 前回の記事 に続いて、私たちが現在使用しているワークフローをご紹介します。このワークフローは、データ漏洩(Ashleyのケースなど)を分析するためだけでなく、社内のデータの分析にも使用されます。ただし、重要な点として、このワークフロー

    データサイエンスのワークフロー ― データ分析を効率に行うために | POSTD
    bouzu_ao
    bouzu_ao 2015/10/15
    フロー大事。
  • リレーショナルデータベースの仕組み (1/3) | POSTD

    リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQLJavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを

    リレーショナルデータベースの仕組み (1/3) | POSTD
  • JavaScriptのデバッグのコツと技 | POSTD

    以前の記事で、 Webアプリケーションのデバッグの仕組み について触れました。今回は実践的なJavaScriptのデバッグについて掘り下げていきたいと思います。 ブラウザデベロッパツール 私の個人的なお気に入りはChromeデベロッパツールです。SafariやFirefoxはChromeほどの高水準に達していません。しかし、徐々に改善されてきています。FirefoxにはFirebugと改良されたFirefoxデベロッパツールが組み合わされた機能が備わっています。もし、Firefoxチームがビルトインされているデベロッパツールの改良の中で素晴らしい仕事をし続けたとしたら、Firebugはいつか、すたれるかもしれません。 個人的な好みにかかわらず、ターゲットとするあらゆるブラウザで、全てのコードのテストやデバッグができるようにすべきです。”あらゆるブラウザ”には、かの有名なInternet E

    JavaScriptのデバッグのコツと技 | POSTD
    bouzu_ao
    bouzu_ao 2015/09/05
  • システムコールを経由する生のLinuxスレッド | POSTD

    Linuxのスレッドは、洗練された美しい設計です。スレッドは仮想アドレス空間とファイルディスクリプタテーブルを共有するプロセスに過ぎません。プロセスによって生成されたスレッドは、メイン”スレッドの”親プロセスに追加された子プロセスです。これらは同じプロセス管理のシステムコールを通して処理されるので、スレッドに関するシステムコールのセットを分ける必要性を取り除きます。これはファイルディスクリプタと同様に洗練された方法です。 一般的に、UNIX系のシステムではfork()を使ってプロセスを生成します。新しいプロセスは、オリジナルのコピーとして独自のアドレス空間とファイルディスクリプタテーブルを取得します。(Linuxではコピーオンライトを使用して、この部分を効率的に処理します。)しかし、これは非常に高度なスレッドの生成方法なので、Linuxでは別の clone() システムコールを使用します。

    システムコールを経由する生のLinuxスレッド | POSTD
    bouzu_ao
    bouzu_ao 2015/07/12
  • 1