タグ

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

  • DRYと不当な抽象化によるコストについて | POSTD

    記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、

    DRYと不当な抽象化によるコストについて | POSTD
    syuu256
    syuu256 2016/11/01
  • 『茹でたニンジン』 : ソフトウェア開発の失敗と技術について | POSTD

    子供の頃、私はニンジンが嫌いでした。においや感がイヤだったのです。しかし実家を出て、自炊をするようになってからニンジンが好きになってきました。ニンジンそのものが変わったわけでもないですし、私の味覚が変わったわけでもありません。違いは調理法です。私の母や彼女と同年代の多くの英国人は、料理が得意ではなく、特に野菜の料理はイマイチでした。母はニンジンを20分以上茹でていたのです。適切な方法でニンジンを調理すれば、全く違った味になるということを私は学びました。 ここは調理のことを話すサイトではなく、ソフトウェア開発のことを話すサイトです。しかし、技術やツールはおいしくないニンジンと同じだなと思うことがよくあります。それは、「その技術が適切に用いられなかったことが当の問題であるにも関わらず、技術自体が良くないものとして非難される」という点においてです。 いつか例を挙げてみましょう。私の複数の友人

    『茹でたニンジン』 : ソフトウェア開発の失敗と技術について | POSTD
    syuu256
    syuu256 2016/10/27
    Fowler
  • CSSになり損ねた言語たち | POSTD

    TeXMicrosoft Word、あるいはその他の汎用的なテキスト処理環境では簡単に実現できるような見た目に自分の文書を似せようと頑張る(文字どおり)無数の人たちに対して、 “悪いけど、うまくいかないよ” と繰り返し言い続けるのは、実際のところ、この1年間、私にとっては継続的な楽しみだった。- Marc Andreessen 1994年 Tim Berners-LeeによってHTMLが発表された1991年には、ページのスタイルを設定する方法はありませんでした。HTMLタグがどのように処理されるかはブラウザ次第で、多くの場合、ユーザの恣意的な入力が大きく影響しました。そうした事情から、ページがどのようなスタイルで処理されるかを”提案”するような標準的な方法を求める声が上がるようになりました。 しかし、CSSが導入されるのは5年先で、完全に実用化されるには10年の歳月を待たねばなりません。

    CSSになり損ねた言語たち | POSTD
    syuu256
    syuu256 2016/10/25
  • 『DOOM』(2016)-グラフィックス研究 – 前編 | POSTD

    去る1993年、『 DOOM 』がゲームデザインやゲームメカニクスに根的な変化をもたらしました。これは世界的な現象となり、 John Carmack や John Romero など、開発に関わった象徴的な存在の名声を広げました。 それから23年が経った現在、 id Software は Zenimax の傘下に入り、当初の創設者は会社から全員去りました。しかし、かつてid Softwareに属していたチームは最高のゲームを作り、変わらずに優秀であることを示しました。 この『 DOOM 』は非の打ちどころのないシリーズ最新作となりました。使用されている id Tech 6 engine については、元Crytekの社員だった Tiago Sousa がJohn Carmackから引き継いだ部署のレンダラプログラマを率いて取り組んでいます。 歴史的には、id Softwareはエンジンをオ

    『DOOM』(2016)-グラフィックス研究 – 前編 | POSTD
    syuu256
    syuu256 2016/10/17
  • そのJavaScriptの関数は本当に純粋関数? | POSTD

    (2016/12/11、いただいたフィードバックをもとに翻訳を修正いたしました。) JavaScriptにおいて”純粋関数”とはどういう意味でしょうか? 一般的なプログラムの用語では、純粋性というのは”参照透過性”として知られています。カッコよく言うと、「 式や関数の呼び出しをその結果と置き換えたとしても、プログラムの振る舞いが決して変わらない 」こと、また別の言い方をするなら、「 同じ入力値を渡すたび、決まって同じ出力値が得られる 」ということです。 これなら直感的に理解できそうに聞こえますし、 x => x * 10 などの関数は純粋に見えます。これに数字の 3 を引数として渡したら必ず、出力値として 30 が得られますからね。では、ある関数が純粋で別の関数が純粋でないと、どうしたら分かるのでしょう? コードを読むだけで十分でしょうか? 一般的にどう思われているかを見てみましょう。昨日

    そのJavaScriptの関数は本当に純粋関数? | POSTD
    syuu256
    syuu256 2016/10/14
  • WebSocket大合戦:Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD

    Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。

    WebSocket大合戦:Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD
    syuu256
    syuu256 2016/10/12
  • 機械学習に挑んだ一年間 – 機械学習について一から学び、仕事に活用するまでの道のり | POSTD

    この記事は、去年私が書いた「Machine Learning in a Week(機械学習に挑んだ一週間)」という記事の続編です。その記事では、私が5日間集中的に機械学習を学び、のめり込んでいった経緯について説明しています。 機械学習に挑んだ一週間 一般の人にとって機械学習の分野に足を踏み入れるのは、無謀なことに思えるでしょう。medium.com 私は順調なスタートを切った後も、時間を見つけて勉強を続け、およそ一年後には、仕事機械学習を活用した初プロジェクトを立ち上げることができました。そのプロジェクトでは、さまざまなタイプの機械学習や自然言語処理(NLP)の技術を駆使して、 Xeneta の 潜在顧客の特定 を行っています。 趣味でやっていたことが仕事になって、とても嬉しかったです。 同時に、仕事として機械学習を利用するのは博士号を持つ限られた人だけだ、という思い込みも払拭されました

    機械学習に挑んだ一年間 – 機械学習について一から学び、仕事に活用するまでの道のり | POSTD
    syuu256
    syuu256 2016/10/11
  • FlyWeb―Mozillaによる、完全Web型のクロスデバイス・インタラクションの実験プロジェクト | POSTD

    FlyWebは、Mozillaプラットフォーム部門内で人知れずプロトタイプを作ってきた実験的なプロジェクトです。昨年末にサブプロジェクトとしてスタートし、以来、小人数の特別チームがそのコンセプトの”バージョン0″の完成を目指してきました。過去6か月にわたり実現に向けてあれこれと手を入れ、特にこの開発のアイディアに興味を持ちそうなWeb開発者やハードウェアハッカー向けには、気楽に話せるくらいのところまでにこぎ着けました。 根的に、目指しているのは1つのゴールです。それは、物理的に近くにいる人間やデバイスがアプリケーションとコンテンツそれぞれをスムーズに動かしやすくすることです。そのためには、”ローカルエリアWebサーバ”を立てる人やそのローカルエリアWebサーバを見つけて接続するブラウザを持つ人にとって、完全にシンプルなものにしようと思っています。このアーキテクチャの上に築かれるものは、ユ

    FlyWeb―Mozillaによる、完全Web型のクロスデバイス・インタラクションの実験プロジェクト | POSTD
    syuu256
    syuu256 2016/10/06
  • ゲームをプレイするアルゴリズムを選択するためのアルゴリズム | POSTD

    この記事は当初、私たちの論文を紹介する簡単な投稿のつもりだったのですが、最終的に膨れ上がってしまいました。結果として、十分な内容が詰まったものになったと思います。 ビデオゲームは、人工知能アルゴリズムをテストする最良の方法ではないでしょうか。 少なくとも私は以前に、このことについて(ある程度の分量で)持論を展開しました。 ビデオゲームでは可能で、例えばロボットにおける問題などでは不可能なものの1つとして、同じアルゴリズムをたくさんのゲームで素早く簡単にテストできるということが挙げられます。ちなみにそのことは、 他のゲームベースのAIテストベッドに対して一定の優位性 を持つ The General Video Game AI Competition (GVG-AI)の指針となる原則の1つでもあります。 GVG-AIフレームワークに実装された数種類のゲーム。 現時点では、実質的にすべての種類の

    ゲームをプレイするアルゴリズムを選択するためのアルゴリズム | POSTD
    syuu256
    syuu256 2016/09/26
  • 私たちがAmazon Web ServicesからGoogle Cloud Platformに乗り換えた理由 | POSTD

    https://flic.kr/p/os8Taq 要約:AWSは素晴らしいが、Googleはその グーゴル 倍素晴らしい。 AWS re:Invent (参加料は1,600ドル)に参加したり、チーフ・エバンジェリストの Jeff Barr をフォローしたりすれば、あなたはたちまち、Amazon Web Servicesのとりこになるでしょう。 毎年何百もの新機能が登場しており、べ放題・融通が利く・運用担当者不要の、オンデマンドサービスのビュッフェのようです。まあ、実際にべてみるまでは、の話ですが…。 Amazonは素晴らしいです。しかし、Google Cloudは「開発者によって、開発者のために構築された」ものであり、それが一目で分かるのです。 移行した理由 App Engine GAE はきちんと機能し、オートスケーリング機能も持ち、ロードバランサや無料のmemcacheも備えていま

    私たちがAmazon Web ServicesからGoogle Cloud Platformに乗り換えた理由 | POSTD
    syuu256
    syuu256 2016/09/09
  • NoSQLデータベース:調査と決定のガイダンス(その1) | POSTD

    (訳注:2016/10/1、頂きましたフィードバックを元に記事を修正いたしました。) 先月、ハンブルク大学の同僚たちと一緒に SummerSOC 2016 でNoSQLの状況についての講演をしました。メンバーは、 Felix Gessert 、 Wolfram Wingerath 、 Steffen Friedrich 、 Norbert Ritter でした。今回はその講演の要点を記事にまとめました。 Baqend を設立して集めた、私たちのNoSQLの濃厚な知識が皆さんに伝われば幸いです。 要約 現在、データはかつてない規模で生み出され、消費されています。増え続けるデータ量とリクエスト負荷に対応するために、「NoSQL」データベースシステムという用語で包括されるスケーラブルなデータマネジメントの新しい方法が産み出されてきました。しかし、数多く存在するシステムは、不均一で多様性があるので

    NoSQLデータベース:調査と決定のガイダンス(その1) | POSTD
    syuu256
    syuu256 2016/09/06
  • GoogleのQUICプロトコル:TCPからUDPへWebを移行する | POSTD

    QUIC(Quick UDP Internet Connections)プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 (冗談で) TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ (ネットワークパケットの往復) が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 (出典: UDPを介

    GoogleのQUICプロトコル:TCPからUDPへWebを移行する | POSTD
    syuu256
    syuu256 2016/08/27
  • 動的配列について – JavaのLinkedListとArrayListを分析・比較する | POSTD

    私はSkienaの『Algorithm Design Manual』 (訳注:『アルゴリズム設計マニュアル』 上巻 ・ 下巻 ) を読んでいました。ところでこのは素晴らしいで、連結リストと配列についてこんな比較をしていました(chapter 3.1.3)。 連結リストが静的配列に勝る相対的な長所には以下のものがあります。: • メモリが当にいっぱいにならない限り、連結構造にオーバーフローが生じない。 • 連続的な(配列)リストに比べて、挿入と削除が単純である。 • 大きなレコードを扱う場合、要素自体を動かすよりもポインタを動かすほうが容易かつ高速である。 一方で、配列の相対的な長所には以下のものがあります。 • 連結構造には、ポインタのフィールドを格納するための余計な領域が必要となる。 • 連結リストでは、要素に対する効率的なランダムアクセスができない。 • 配列は、ランダムなポイン

    動的配列について – JavaのLinkedListとArrayListを分析・比較する | POSTD
    syuu256
    syuu256 2016/08/24
  • マイクロサービスの終焉 | POSTD

    これは未来からの投稿です。現在、信頼のおけるスケーラブルなプロダクションシステムの構築は、言ってみれば、その他のソフトウェアを書くのと同じくらい容易になっています。未来にはどのような風景が広がっているのか、お伝えしましょう。 2016年当時は、誰も彼もが「マイクロサービス」を取り上げていました。例えば、1996年に「情報スーパーハイウェイ構想」の記事ばかりが出回った頃に似ています。「情報スーパーハイウェイ構想」というフレーズがやがて消滅し、人々はインターネットの構築に戻っていったのと同様に、サービスが、スケーラブルなソフトウェアシステム構築の標準になるにつれ、マイクロサービスの「マイクロ」の部分もまた、削り落とされて行きました。私たちが使ってきた(そして捨て去った)名称であるにもかかわらず、どちらの用語も、当時のテクノロジーに対する考え方とその使い方に起こった転換を示しています。サービスベ

    マイクロサービスの終焉 | POSTD
    syuu256
    syuu256 2016/08/24
  • あなたはCSSプロパティ”display”をどのぐらい知っているだろうか? | POSTD

    CSSプロパティの1つである display は、CSSレイアウトに用いるプロパティの中でも極めて重要なものです。よく使われているのは、 block や inline 、 none あたりでしょう。 table や inline-block も、今ではかなり一般的になってきたと言えます。一方、 flex は新たに登場したものです。きっとユーザに気に入られるでしょう。これはレイアウト用に特別に作られたdisplayプロパティです。さらには、この先、 grid がまもなく私たちの秘密兵器となるでしょう(現在、盛んに取り組まれています)。これもまた、レイアウトに特化したプロパティです。 記事は、当初予定していたよりもずっと長くなりました。ご希望に応じて、自由にサブセクションに飛んでお読みいただければと思います。もし、お時間を割いて全体を読んでいただけるのでしたら、大変嬉しく思います???? 目

    あなたはCSSプロパティ”display”をどのぐらい知っているだろうか? | POSTD
    syuu256
    syuu256 2016/08/06
  • Linuxシステムコール徹底ガイド | POSTD

    要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法(例あり)、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは? 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ(MSR) アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3

    Linuxシステムコール徹底ガイド | POSTD
    syuu256
    syuu256 2016/07/29
  • 私がscriptタグについて知っていること全て : 知られていない属性や実行順序など | POSTD

    <script src="//typekit.com/fj3j1j2.js"></script> <!-- This second script won’t execute until typekit has executed, or timed out --> <script src="//my.site/script.js"></script> ローカルスクリプトとリモートスクリプトを組み合わせても同様に操作することができます。 機能的には、Webページの前の部分で重いスクリプトのロードがあると、サイトの表示が明らかに遅くなることを意味します。さらに、ページの最後の方で表示されるスクリプトは、それまでに存在するされたスクリプトの動作に依存することを意味します。 先行する全てのscriptタグがロードされ実行されるまで、ページ上の要素は表示されません。つまり、パフォーマンスへの悪影響を覚

    私がscriptタグについて知っていること全て : 知られていない属性や実行順序など | POSTD
    syuu256
    syuu256 2016/07/23
  • オーディオアプリ開発でありがちな4つの間違い | POSTD

    ここで論じているのは、オーディオアプリの開発者が陥りがちな 4つの間違い 、 より良く開発する方法 、 問題個所の発見方法 です。主に開発者向けの内容ですが、開発者以外の方にも知っておいてもらいたいと思います。ここでは、開発者向けの診断ツールである Realtime Watchdog を紹介し、 人気のあるオーディオライブラリの調査結果 を提示します。 オーディオアプリの開発はとてつもなく楽しいです。やりがいを感じるし、創造力を発揮できる範囲が大きく広がり、ひとたび開発が終われば、 誰かがクリエイティブなツールとして使ってくれるのです! こんな分野は多くないし、この領域で働けるなんて非常に幸運だと自分でも思っています。 しかし、仕事でオーディオアプリを扱う時には深く考えなければならない部分もあります。オーディオアプリの開発者としてユーザに対する責任があるのです。大前提として、ユーザを公共の

    オーディオアプリ開発でありがちな4つの間違い | POSTD
    syuu256
    syuu256 2016/07/20
  • AsyncとAwait : コールバック地獄を避けるための最新のやり方、そしてその未来 | POSTD

    (2016/7/7、いただいたフィードバックを元に記事を修正いたしました。) JavaScript、特にNode.jsといえば、 コールバック地獄 がよく連想されます ^(1) 。たくさんの非同期I/Oを扱うコードを書いたことがある方には、おそらく以下のようなパターンはおなじみでしょう。 export default function getLikes () { getUsers((err, users) => { if (err) return fn(err); filterUsersWithFriends((err, usersWithFriends) => { if (err) return fn(err); getUsersLikes(usersWithFriends, (err, likes) => { if (err) return fn (err); fn(null, lik

    AsyncとAwait : コールバック地獄を避けるための最新のやり方、そしてその未来 | POSTD
    syuu256
    syuu256 2016/07/06
  • 私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD

    1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由

    私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
    syuu256
    syuu256 2016/06/03