PHPはもうダメだ、PHP万歳！ | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) GutenbergとWordPressに関する騒動は、PHPの終焉につながる最新記事です。深呼吸をしてください、みなさん。トロールは無視し、Mark TwainとFidel CastroとPHPとの共通点を見ていきましょう。そして、もっと重要なのは、スタートアップやスモールビジネスにとって、PHPが今でも合理的な選択である理由です。 PHPはいつから廃れ始めたのか “PHPはもうダメだ”といったブログの投稿が、登場し始めたのは2011年のようです（これより古いものを見つけたら、お知らせください）。Mediumや、mushroomsのように突然出現したcoding bootcampsを探し回れば、その唯一の共通点は、みんながPHPを嫌っているか、あるいは単に無視しているかです。どうやら、法外な値段のコー
The 2019 DevOps RoadMap | POSTD
DevOpsエンジニアになるためのイラストガイド（関連コースへのリンク付き） DevOpsは今とてもホットなテーマです。多くの友人、同僚、上級開発者である知人がDevOpsのエンジニアとなり自分のいる組織の中で第一人者になろうと一生懸命になっています。 私は DevOps の恩恵を心から認めています。DevOpsはソフトウェア開発とデプロイの改善に直結しているからです。しかし私の限られた経験から言っても、DevOpsのエンジニアになるのは 簡単ではありません。 非常に多くのツールと事例があり、適切な学び方を選ぶのがとても難しいのです。 Javaのブロガー としてよく質問を受けます。例えば、 DevOpsのエンジニアになるにはどうすれば？ どのツールを学べば？ どんな事例を参考にすれば？ DevOpsエンジニアにはMavenとJenkinsがマストですか？ DockerやKubernetes
ソフトウェア設計が重要である理由 | POSTD
新しいプロジェクト始まると、開発者はいきなりプログラミングに飛びつく傾向があります。それもいいでしょう。結局、それが仕事なのですから。でも、時には飛びつく前にブレーキをかけて、ソフトウェア設計から手を付けるのもいい考えかもしれません。 “ホワイトボードを使う長袖のホワイトシャツの男性”（出典： Trent Erwin ／ Unsplash ) ソフトウェア設計にはいろいろな方法があります。UMLなどのモデリング言語のソフトウェアを利用することもできるし、 テキストを書いて 画像を使うこともでき、あるいはホワイトボードに描くこともできます。ここで大切なのは、ソフトウェアの開発中に設計を保存して再考できることです。設計は多少なりとも改善していかなければなりません。ですから、いつも最初からホワイトボードに描きたいというわけではないのならばデジタルデータで、設計を行うのも良さそうです。データの保存
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD
バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高
13年分の未熟なゲームのコード | POSTD
1人きりの金曜日の夜、何らかのインスピレーションを求めていた私は、以前のプログラミングのいくつかを再現することに決めました。 昔のハードドライブがゆっくりと回転し、栄光の日のソースコードが表示されます。 しかし、蓋を開けてみると、全く期待していたものではありませんでした。”ここまでひどかったのか。なぜ誰も言ってくれなかったのだろう。なぜ自分はこんなにひどかったのだろう。 1つの関数内に、これほど多くのgoto文をよく入れられたものだ。 “ 私はすぐに自分の試みを諦めました。そして一も二もなく、コードの削除とハードディスクの完全消去を考え出しました。 以下は、過去の自分を見ることで得た教訓や断片、警告などをまとめたものです。過去の過ちをそのまま公開するためにも、名前などは変更していません。 2004年 私は13歳でした。このプロジェクトは Red Moon という、野性的で野心的なサードパー
機械が私たちの偏見を継承する仕組み | POSTD
機械は言語の処理を学習する際、人が書いた文章のサンプルから性別や人種的な偏見を継承します。 トルコ語では、”彼（he）”、”彼女（she）”、”それ（it）”を表すための代名詞が、”o”の1つしかありません。”o”の代名詞が含まれるトルコ語の文章をGoogle翻訳で英語に翻訳する場合、翻訳アルゴリズムは英語のどの代名詞が”o”に相当するのかを推測することになります（性別が不明な場合、大抵は”彼”）。そして、アルゴリズムは ジェンダーバイアス（性差に基づく偏見） を反映しながら、”彼は医者です”、”彼女は看護師です”、”彼は勤勉です”、”彼女は怠け者です”のような形で文章を翻訳するのです。言語処理の学習に際して、多くのアルゴリズムは人が書いたニュース記事やWikipediaなどの文章を参考にしており、こうした言語モデルから単語間の関連付けを行っています。しかしそうすることで、例えば” 「彼」
コードレビューのレビューはマネージャーの仕事 | POSTD
経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。 多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。 > エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。 品質管理以上の役割 従来、コードレビューのプロセスは品質管理のツールと見なされ
Makefileを自己文書化する | POSTD
私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ
なぜPythonはこんなにも遅いのか？ | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) Pythonは高い人気を誇り、DevOps、データサイエンス、Web開発、セキュリティの分野で使われています。 しかし、速度に関しては高い評価が全くありません。 JavaとC、C++、C#、Pythonの速度を比べるには、どうしたらいいのでしょう？ 答えは、実行するアプリケーションのタイプに大きく左右されます。完璧なベンチマークはありませんが、[手始めに比べる手段](https://algs4.cs.princeton.edu/faq/)としてはThe Computer Language Benchmarks Gameが適しています。 私は10年ほどthe Computer Language Benchmarks Gameを参照していますが、Java、C#、Go、JavaScript、C++などの他言
TCPを（少しは）理解しておくべきその理由 | POSTD
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
分岐予測の簡単な歴史 - Part 1 | POSTD
※これは、 RC（The Recurse Center：プログラマ教育施設） によって組織された講演シリーズである”localhost”を始動するために、Two Sigma（ツーシグマ）での2017年8月22日の分岐予測に関する講演の原稿を仮に書き起こしたものです。 コードで分岐を使われている方は、どれくらいいらっしゃいますか？ ifステートメントやパターンマッチングを使われているという方、よろしければ手を挙げてください。 ほとんどの聴衆が手を挙げる 次の質問に関しては手を挙げてもらうつもりはありませんが、もしそうお願いした場合、恐らく手を挙げる人の数は少なくなるのではないでしょうか。その質問とは、「分岐を実行する際、CPUが何をして、そのパフォーマンスは何を意味しているのかを十分に理解しているか」、そして「分岐予測に関する最新の論文を理解できるか」というものです。 この講演の目的は、CP
Node.jsのClusterをセットアップして、処理を並列化・高速化する | POSTD
Node.jsが多数のイベントの非同期な処理に長けていることはよく知られていますが、それが単一のスレッドで行われていることを多くの人は知りません。Node.jsは実際にはマルチスレッドではないので、リクエストは全て単一スレッドのイベントループで処理されているだけなのです。 そこで、Node.jsクラスタを使って、クワッドコアプロセッサの能力を最大限に引き出しましょう。コードの複数のインスタンスで起動し、さらに多くのリクエストを処理します。少し難しく思えるかも知れませんが、Node.js v0.8で導入された cluster モジュールを使えば、実はとても簡単です。 もちろん、これは、作業を別々のプロセスに分割することのできるアプリならどんなアプリにでも役立ちますが、webサイトのような多くのIOリクエストを処理するアプリには特に重要です。 残念ながら、並行処理は複雑なので、サーバ上でのアプ
分散型システム徹底入門 – Part 2. | POSTD
Cassandra 先ほど触れたCassandraは分散型のNoSQLデータベースで、CAP定理のAとP（可用性と分断耐性）の特性を基準に最終的な一貫性が確保されています。ただ、このように言ってしまうと少し誤解を招くかもしれません。というのも、実際のところCassandraの設定は非常に柔軟性が高く、可用性を犠牲にして強い一貫性を提供することもできるからです。ですが、そうした使用ケースは一般的ではありません。 Cassandraでは、 コンシステントハッシュ法 を使って、渡そうとするデータをクラスタのどのノードが管理するのかを決めています。そしてその際は、データを複製するノード数を示す レプリケーションファクタ を設定します。 注釈： レプリケーションファクタ＝3 挿入（キー、値） Cassandraのノード（コーディネータ） Cassandraのノード ハッシュ（キー）＝2 ノード#2
webpackとRollup：似て非なるもの | POSTD
先日、Facebookは 膨大なプルリクエスト をReactにマージして、既存のビルドシステムを Rollup ベースのシステムに移行しました。 その結果 、 何人もの人々 から「なぜwebpackではなくRollupを選んだのか」という質問が寄せられました。 これは、もっともな疑問でしょう。 webpack は、近年JavaScriptコミュニティで最も評価されているツールの1つです。毎月のダウンロード数は何百万件にもおよび、何万個ものウェブサイトやアプリケーションに使用されています。巨大なエコシステムがあり、コントリビュータも多くいます。さらにオープンソースプロジェクトとしては珍しく、 かなりの寄付金 が集まっています。 それに比べるとRollupは小規模です。しかしReact以外にも、Vue、Ember、Preact、D3、Three.js、Momentなど、数々の有名なライブラリに
HHVMの今後 | POSTD
2017年1月、PHPはPHP5のアクティブサポート終了を 正式に発表 しました。 私たちHHVMチームはPHPがPHP7で打ち出している方向を歓迎しており、この言語とランタイムを今日の位置に推し進める役割を担ったことを光栄に思っています。PHPコミュニティがPHP5に別れを告げようとしている今、HHVMチームも同じ決断を下しました。 HHVMの次のLTSリリースである3.24は、 2018年1月 にテスト公開され、その後1年間サポートされます。また、3.24は PHP5をサポートする最後のHHVMリリース となります。これは、2018年末にPHP5のセキュリティサポートも終了するPHP自体のタイムラインと同調するものです。HHVMチームはPHP5固有の特殊な挙動に対する全てのサポートを即座に中止するわけではありませんが、それらは3.24のテスト公開後はいつでも中止となる可能性があり、ex
Pythonや機械学習、そして言語の競争について – 極めて主観的な見地から | POSTD
(訳注：2016/1/5、いただいた翻訳フィードバックを元に記事を修正いたしました。) よくある主観的で痛烈な意見を題名に付けたクリックベイト（クリック誘導）記事だろうと思われた方、そのとおりです。以前指導してくれた教授から教わったある洞察/処世術は、些細でありながら私の人生を変えるマントラとなったのですが、私がこの記事を書いたのはそれによるものです。「同じタスクを3回以上繰り返す必要があるなら、スクリプトを書いて自動化せよ」 そろそろ、このブログはなんだろうと思い始めているのではないでしょうか。半年振りに記事を書いたのですから。ツイッターで書いた Musings on social network platforms（ソーシャル・ネットワークプラットフォームについてじっくり考える） はさておき、この半年の間書き物をしていないというのはうそです。正確には、400ページの 本 を書きました。
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
カオステストでHTTP/2の問題を見つけ出す | POSTD
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
15年目のVim | POSTD
(注：2017/04/19、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) Vim使用について述べた先の投稿（ 1 、 2 ）は好評だったこともあり、そろそろ更新が必要になりました。Vim 8には非常に要望の多かった機能がたくさん追加され、 VimAwesome のような新しいコミュニティサイトができたことでプラグイン探しと評価が容易になりました。最近では私もVimで仕事をする機会がとみに増え、 ピーク効率 に向け自分のワークフローの設定に時間を費やしたりもしています。ですから、この記事は私の現在の状況を写し取ったものです。 大まかには次の内容です。 ファイル特定にはfzfとfzf.vim *ファイル検索にはack.vimと ag Vim + tmuxが勝利への鍵 ALEは新Syntastic。理由はその非同期性 …などなど多数。ぜひ
ディープラーニングの限界 | POSTD
(注：2017/04/08、いただいたフィードバックを元に翻訳を修正いたしました。 @liaoyuanw ) この記事は、私の著書 『Deep Learning with Python（Pythonを使ったディープラーニング）』 （Manning Publications刊)の第9章2部を編集したものです。現状のディープラーニングの限界とその将来に関する2つのシリーズ記事の一部です。 既にディープラーニングに深く親しんでいる人を対象にしています（例：著書の1章から8章を読んだ人）。読者に相当の予備知識があるものと想定して書かれたものです。 ディープラーニング： 幾何学的観察 ディープラーニングに関して何より驚かされるのは、そのシンプルさです。10年前は、機械認識の問題において、勾配降下法で訓練したシンプルなパラメトリックモデルを使い、これほど見事な結果に到達するなど誰も想像しませんでした。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
