POSTDをGatsby.jsベースに変更しました | POSTD
POSTDの運用がリクルートからニジボックスに移管される際に、デザインのリニューアルと同時にコードベースをGatsby.jsに変更しました。 本記事では、運用移管に至るまでの過程を踏まえつつ、現在のPOSTDの構成を紹介します。 移管前のPOSTD 前述の通り、POSTDは株式会社リクルートのインキュベーション部門Media Technology Lab.（現新規事業開発部）で運用されていました。 最後に公開した記事は、2019年3月28日の「PHPはもうダメだ、PHP万歳！」となっています。 もともとはWordPressによる運用が行われていましたが、運用体制の関係で静的HTMLをFirebaseで公開する形式になっていました。 ニジボックスへの引き継ぎに伴い、記事の翻訳を始めとしたサイト運用を再開することになり、改めてCMSの形式に変換する必要が出てきます。 Gatsby.jsを選ぶ
プログラマの採用面接で聞かれる、データ構造とアルゴリズムに関する50以上の質問 | POSTD
情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。
ブラウザのキャッシュをクリアする | POSTD
最も一般的で最も簡単にフロントエンドのパフォーマンスを向上できる方法は、ブラウザにアセットをキャッシュすることです。しかし、いずれかの時点で開発者は長いキャッシュ寿命を持つアセットを誤ってリリースしてしまう場合があります。正す方法があるのです。キルスイッチの導入方法を教えましょう。 私のようにWeb開発をしている方であれば、誰もが一度は質の悪いフロントエンドアセットをリリースしてしまったことがあるのではないでしょうか。そのせいで30年というキャッシュ寿命を与えてしまうことになってしまいます。凶報です。ユーザが手動でキャッシュをクリアしない限り、残ってしまいます。果たしてそうでしょうか。 最近、 Steve Souders と朝食を一緒にしたのですが、相手がSteveということもあり、会話は3時間も続き、終わった時には頭が痛くなっていました。Steveに課題として考えさせられたのが、キャッシ
分散型システム徹底入門 – Part 3. | POSTD
BitTorrent BitTorrentは、Web上でtorrentを使って大容量ファイルを転送する際に広く使われているプロトコルです。その主な目的はメインサーバを経由することなく、ネットワーク内のさまざまなピア間でのファイル転送を容易にすることです。 BitTorrentクライアントを使うと、世界中の複数のコンピュータに接続してファイルをダウンロードします。.torrentファイルを開くと、コーディネーターのような役割を果たすマシン、いわゆる トラッカ に接続されます。トラッカはピアを見つけ出し、欲しいファイルを持っているネットワーク内のノードを示してくれます。 *注釈： トラッカ ・オンラインのノードをトラッキングする ・ノードが何のファイルを提供しているかを認識する Seeder：シーダ Leeche： リーチャ 破線：ファイル転送 実線：メタデータ転送* ネットワークのサンプル
GitトラブルをGetしてしまったら：バージョン管理のお話 | POSTD
非常におかしい題名を笑ってくださってありがとうございます。しかし、おかしくないことがありますが、何か分かりますか。git repoにコミットをプッシュした時で、これを GitHubデスクトップ で見ることができます。 Googleを使ってこれが何を意味するか調べてください。 もちろん、 いけている人 が Git Tower を使い、 本当に いけている人は コマンドライン のみを使っていることを知っています。我々は本当にいけているので、ここではコマンドラインを使って問題を解決します。実は他に選択肢がないのです。この記事で、git専門のコマンドライン知識が全くないのにも関わらず、コマンドラインを使い、全く プログラムの書き手に非がない のに、突然git repoが壊れてしまう問題を解決する冒険に誘います。少なくとも自分に非がないのに突然壊れてしまった時のパニックの度合いを見ていただけるかと思
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
「フロントエンド開発者」の終焉 | POSTD
元記事の著者より：この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます（答えは相手によって変わることもあります）。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLやCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPやMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです（これに関しては、後に詳しく説明します）。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな
Linuxシステムコール徹底ガイド | POSTD
要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法（例あり）、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは？ 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ（MSR） アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3
DockerでのNodeアプリ構築で学んだこと | POSTD
以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から本番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない（悪いやり方です）。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する（これには秘訣があります）。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と本番環境で Do
Makefileを自己文書化する | POSTD
私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ
POSTD Podcast #1 POSTDの作り方 | POSTD
About Kazuyuki Suzuki(@kechol), Kei Sawada(@remore), Satomi Yako(@yako_yaco)の3人がPOSTD, HackerNews, 翻訳, The Changelog, Podcastの運用などについて話しました。 Show Notes and Links POSTD Media Technology Lab. HackerNews翻訳してみた Saying Good Bye To Python The Changelog github.com/thechangelog/ping github.com/postdcc 雑な発想を活かすチーム作り Rebuild AWS Podcast | Listen & Learn About AWS VentureBeat’s What to Think Podcast wada.fm
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
