ニューラルネットワークの動物園 : ニューラルネットワーク・アーキテクチャのチートシート(後編) | POSTD
前編はこちら： ニューラルネットワークの動物園 : ニューラルネットワーク・アーキテクチャのチートシート(前編) 逆畳み込みネットワーク(DN) は、インバース・グラフィックス・ネットワーク（IGN）とも呼ばれていますが、畳み込みネットワークを逆転させたものになります。例えばネットワークに”猫”という言葉を入力すれば、生成した猫らしき画像と本物の猫の写真を比較しながら猫の画像を作成するよう訓練するようなイメージです。普通のCNNと同様にDNNをFFNNに組み合わせることができますが、新しい略語が見つかる時に線が描かれるところが特色です。深層逆畳み込みニューラルネットワークとでも呼べそうですが、FFNNの前後にDNNをつなげると、新しい名前をつけるにふさわしい別のアーキテクチャのネットワークができると主張できます。実際にはほとんどのアプリケーションにおいて、ネットワークにテキストに似たものが
Lispのアイデア | POSTD
Lispと聞くと、冷蔵庫のような大きいサイズのコンピュータや、大文字のアルファベット文字列や括弧の並びといったような過去の時代のことが頭に浮かびます。そう、非常に多くの括弧。何故、オブジェクト指向プログラミングの作成者たちは、そんなにもLispの アイデア に魅了されるのでしょうか。そしてまた、アイデアとされるプログラミング言語というものは、どうやったら説明できるでしょうか。こうしたことを教えてくれなかったコンピュータ科学の教育を責めるべきでしょうか。 Lispは、John McCarthyが書いた Recursive Functions of Symbolic Expressions and Their Interpretation by Machines, Part I という論文によって、初めて世界に登場しました。その中で、McCarthyはプログラミングに新しい多くのアイデアを導入
仮想DOMの内部の動き | POSTD
PreactでVDOMがどのように機能するかを示すフローチャート 仮想DOM（VDOMあるいはVNode）は魅力的です✨ しかし複雑で、理解が難しいものでもあります???? React や Preact 、その他同様のJSのライブラリでは、これをコアで使っています。残念ながら私は、これを詳細かつ分かりやすく説明している優れた記事や資料を見つけられませんでした。ですから、自分で書こうと思い立ったのです。 備考：これは非常に長い記事です。内容をシンプルに表すために画像を山ほど挿入しましたが、それゆえにさらに長い記事になってしまいました。 私は Preact のコードとVDOMを使いました。容量が小さくて済み、将来、簡単に見なおすことができるからです。しかし、概念のほとんどはReactにも共通していると思います。 皆さんがこれを読んだ後、仮想DOMをよく理解できるようになり、できればReactや
現実世界のマイクロサービス：サービスに陰りが見え始め、いよいよ本気になるとき | POSTD
マイクロサービスを用いれば、エンジニアリングチームは迅速にプロダクトを拡大することができます……もちろん、彼らが分散システム運用の複雑さのせいで泥沼にはまっていなければの話です。本記事では、マイクロサービスの運用に関わる非常に厳しい問題―例えば大規模なサービスのステージングやカナリアデプロイなどの問題―が、RPC層に ルーティング の考え方を導入することにより、どう解決できるのかを説明します。 私は、Twitterでインフラのエンジニアを務めていた時代（2010年から2015年まで）を振り返ってみました。すると、当時はそういった言葉がなかったというだけで、私たちは「マイクロサービスを使っていた」のだということが分かります（当時は、今思えば分かりにくい言葉、 SOA ＜サービス指向アーキテクチャ＞と呼んでいました）。 バズワードはさておき、当時も、現在私たちがマイクロサービスを使おうとする動
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS! ：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
2015年の最優先事項は関数型プログラミング！ | POSTD
—もはやOOP（オブジェクト指向プログラミング）は”クラウドモンスター”から私たちを守りきれない おそらくあなたは、”Clojure”、”Scala”、”Erlang”といった言葉や、”Javaにラムダ式が導入された”という話を聞いたことがあるでしょう。そしてそれらの言葉が”関数型プログラミング”と関連があるのをご存じかもしれません。プログラミングコミュニティに参加していれば、おそらく既にこのテーマが議題に上がっているでしょう。 Googleで”関数型プログラミング”を検索しても、目新しいものは何も見つかりません。言語の中で2番目に古い言語は、関数型プログラミングを利用しています。1950年代に登場した、Lispという言語です。では一体なぜ人々は、今になって関数型プログラミングに沸き立っているのでしょうか？ およそ60年も経っているのに？ 初期の頃、コンピュータは実に遅かった 信じられない
Q. （関数型）リアクティブプログラミングとは何ですか？ | POSTD
Wikipediaで リアクティブプログラミング (reactive programming)を調べてみました。また、 関数型リアクティブプログラミング (functional reactive programming, FRP)についても少し説明があったので確認してみましたが、どちらも説明が大雑把です。 実際のところ関数型リアクティブプログラミングとはどういう意味なのでしょうか？リアクティブプログラミングは（非リアクティブプログラミングと比べて）何で構成されているのですか？私は命令型のオブジェクト指向言語を使っているので、そのパラダイムに関連させて説明して頂けると大変有難いです。 asked by JtR Answer(s) FRPの感触をまず試してみたいのであれば、 1998年に発表された古典のFran tutorialに目を通してみると良いでしょう。 これは動画で説明されています。
なぜDockerとCoreOSの決裂は予測できたか | POSTD
「私が滑っていく先はパックが向かう所であり、パックがあった所ではない」－Wayne Gretzky CoreOSとDockerの間で 最近 、 騒動 がありました。DockerはCoreOSのクラスタ管理の領域に入り込むために構築している製品の範囲を広げています。それにより、CoreOSがDockerと競合する独自のコンテナランタイム Rocket を発表したのです。そういった動きは、Clayton Christensenの『 Law of Conservation of Modularity 』を読んでいれば十分に予測できるものでした。 我々がコモディティ化に関する研究から洞察したのは、コモディティ化がバリューチェーンのどこかで進んでいる時はいつも、脱コモディティ化という逆のプロセスがバリューチェーンの別のどこかで進んでいるということです。（中略）この2つのプロセスが相互関係にあるという
USトップ大学でも関数型プログラミングが余り教えられていない現実 | POSTD
数カ月前、私たちは一部の言語が他の言語に比べて受け入れられやすい理由を調べた SocioPLT リサーチプログラムについて 投稿 しました。その 調査 の一環として、2000年から2010年の期間内にSourceForgeのプロジェクトで使用された言語を調べて頻度別にランク分けしたのですが、この結果で興味深かったのは、上位20の言語の中に関数型言語が1つもなかったということです。 教育機関のプログラミング言語研究者は関数型言語を好む傾向にあるため、この事実を残念なことと思うでしょう。しかしながら、このような事態に陥った原因の一部は、私たち学術研究者自身にあるのかもしれません。関数型言語が“現実の世界”で受け入れられるためには、大学などの機関がそれを教えなければならないからです。この投稿を通じて、そうした教育プログラムを持つ大学がほとんどないことが分かるでしょう。プログラミングの教育課程にお
Go言語がダメな理由 | POSTD
私はGo言語が気に入っていますし、多くの場面で使用します。現にこのブログもGoで書いています。Goは便利な言語ですが、優れた言語とは言えません。つまり、悪くはないけれど、十分ではないということです。 満足できない言語を使用する際は注意が必要です。注意を怠ると、その言語を次の20年間使い続ける羽目になるかもしれないからです。 私のGoに対する主な不満を本文にまとめました。既に何度も指摘されていることも含まれていますが、中にはこれまでほとんど話題になっていない指摘もあります。 これから列挙する全ての課題には既に解決策があることを示すため、私が優良な言語と考えるRustやHaskellと比較して説明します。 汎用プログラミング 課題 誰でもさまざまな事柄に幅広く対応できるコードを記述したいと考えます。例えば数のリストの合計を求めるために定義した関数が、小数、整数、またその他の合計を求められるもの
科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD
今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度（少なくともほとんどの場合）私は反省し、それまでにも増して退屈なくら
ある中級プログラマの告白 | POSTD
私は中級レベルのプログラマです。 基本を理解するのは得意です。過去の失敗をきちんと分析できるくらい経験を重ねていますし、もっと知るべきことは山ほどあることも分かっています。 特筆すべきは、自分で身につけるべきことを知ったうえで、それを吸収しようと積極的かつ精力的に取り組んでいる点でしょう。 プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。 でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。 自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
