ツールは解決策ではない | POSTD
最近、『The Atlantic』に掲載された非常に重苦しい 記事 「The Coming Software Apocalypse」（きたるソフトウェア大惨事）を読み終えました。同記事は最初のうちは、人に傷害を与えたり、人の命を奪ったりした恐ろしいソフトウェアバグについて述べており、いい内容です。しかし、途中から急に残念な展開になっているのです。 同記事の著者はソフトウェア業界の多くの思想的リーダーにインタビューをしましたが、 Light Table 、 モデル駆動工学 、 TLA+ といった新しい技術を生み出したリーダーだけを選んでいます。 私はこうしたツールに何ら反対しているわけではありません。Light Tableプロジェクトに資金提供さえしました。優れたソフトウェアツールは優れたソフトウェアを書きやすくすると思います。しかし、ツールは「大惨事」に対する解決策ではありません。 著者は
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
ディープラーニングの限界 | POSTD
(注：2017/04/08、いただいたフィードバックを元に翻訳を修正いたしました。 @liaoyuanw ) この記事は、私の著書 『Deep Learning with Python（Pythonを使ったディープラーニング）』 （Manning Publications刊)の第9章2部を編集したものです。現状のディープラーニングの限界とその将来に関する2つのシリーズ記事の一部です。 既にディープラーニングに深く親しんでいる人を対象にしています（例：著書の1章から8章を読んだ人）。読者に相当の予備知識があるものと想定して書かれたものです。 ディープラーニング： 幾何学的観察 ディープラーニングに関して何より驚かされるのは、そのシンプルさです。10年前は、機械認識の問題において、勾配降下法で訓練したシンプルなパラメトリックモデルを使い、これほど見事な結果に到達するなど誰も想像しませんでした。
サーバレスはより安く、より複雑だ | POSTD
先週の (Emit) カンファレンスでは、卓越した講演の数々、興味の尽きないパネルディスカッションが行われ、サーバレスコミュニティの優秀な仲間たちに出会って貴重な意見交換をする機会がたくさんありました。 そこでは誰もが一様に、コストこそがサーバレス適用の推進の鍵だとみなしていました。オンデマンド実行と生来の弾力性は、稼働率を最適化しつつ、稼動時間と信頼性もさらに高い状態に保ちます。従量課金制はコストを直接的に定量化できるものに変えました。場合によっては 桁外れの 節約 になる可能性があります。パネルディスカッションで、Gartnerのアナリストの Anne Thomas は、企業クライアントは”コスト”が有利という理由からサーバレスに興味を持つ、と話しました。 しかし、クローズドなシステムにフリーランチはありません。メリットを得るには何かを犠牲にしなければならないのです。テクノロジーにおい
JOSE（JavaScriptオブジェクトへの署名と暗号化）は、絶対に避けるべき悪い標準規格である | POSTD
注： 本稿は元はJSON Web Tokens（JWT）について書いたものですが、JWTはJavascript Object Signing and Encryption（JOSE）のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption（JOSE）を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption（JWE）、JSON Web Signatures（JWS）のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能
プログラマとしてのキャリアを脅かす反復運動過多損傷の痛みをどう解消したか | POSTD
タイピング時に痛みを感じつつ、プログラマとして働き続けるのは非常に辛いことでしょう。音声認識という代替手段はあっても、やはりタイピングとは勝手が違います。新しい仕事を始めてすぐに手首と腕の痛みがぶり返した時、私は恐怖感すら覚えました。 私は過去に2度、こうした状況に陥ったことがあります。その時は痛みが消えるまで結局何年もの間、プログラミングなしの生活を余儀なくされました。そのため、またプログラマとしてのキャリアが脅かされるのでは、と不安に感じていました。 そんなある日、仕事場へと自転車をこいでいる最中に、私は何が起きているのかに気付いたのです。そして自らの理論を検証する手段を思い付き、それを実行に移すと、痛みは消え去りました。同じ対策を何年か前にも講じていれば、きっと痛みは解消していたはずです。しかし実際は、プログラミングができたはずの数年間を、嫌々プロダクト・マネジャとして働いて過ごして
Linuxシステムコール徹底ガイド | POSTD
要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法（例あり）、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは？ 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ（MSR） アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3
R vs Python：データ解析を比較 | POSTD
主観的な観点からPythonとRの比較した記事は山ほどあります。それらに私たちの意見を追加する形でこの記事を書きますが、今回はこの2つの言語をより客観的な目線で見ていきたいと思います。PythonとRを比較をしていき、同じ結果を引き出すためにはそれぞれどんなコードが必要なのかを提示していきます。こうすることで、推測ではなく、それぞれの言語の強みと弱みの両者をしっかりと理解できます。 Dataquest では、PythonとRの両方の言語のレッスンを行っていますが、データサイエンスのツールキットの中では両者ともそれぞれに適所があります。 この記事では、NBA選手の2013/2014年シーズンの活躍を分析したデータセットを解析していきます。ファイルは ここ からダウンロードしてください。解析はまずPythonとRのコードを示してから、その後に2つの異なるアプローチを解説し議論していきます。つま
開発者がビッグデータ分析にPythonを使う時によくやる間違い | POSTD
システムの構築、新しい技術の習得、PythonやDevOpsなどに情熱を注ぐソフトウェア開発者です。現在はチューリッヒを拠点とするビッグデータのスタートアップで働いており、データ分析およびデータ管理ソリューションのためのPythonの技術を磨いています。 1 はじめに Python は開発時間を短縮できるという点で一般的に評価の高い言語です。しかし、Pythonを使って効率よくデータ分析をするには、思わぬ落とし穴があります。動的かつオープンソースのシステムであるという特徴は、初めは開発を容易にしてくれますが、大規模システムの破綻の原因になり得ます。ライブラリが複雑で実行時間が遅く、データの完全性を考慮した設計になっていないので、開発時間の短縮どころか、すぐに時間を使い果たしてしまう可能性があるのです。 この記事ではPythonやビッグデータで作業をする時に、最も時間を無駄にしがちな事柄につ
Optimizelyを使ってクビになりかけたワケ ~統計学が苦手なマーケターへの薦め~ | POSTD
（訳者注: 検定手法について、この記事には一部内容が古い部分があります。Optimizelyは現在、両側検定を採用し、独自開発したより精度の高い統計手法(Stats Engine)でテスト結果を表示しています。Stats Engineに関する記事: 日本語 ・ 英語 ） 私たちがSumAllでA/Bテストを一斉にスタートさせて6ヶ月が経ち、あまりよくない結末を迎えました。それは勝算があるとした結果のほとんどが新規ユーザーの獲得改善にはつながらなかったことです。それどころか、私たちは失敗したのです。そして私の一番の責任はユーザー獲得の増加であるということを考えると、本当に最悪の状況でした。私にとっても、私のキャリアにとっても、そしてSumAllにとっても。 過去に A/BテストとWebサイト･パーソナライゼーションの会社 に勤めていた経験から（はっきり言うとMonetateはOptimize
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
