えびスタ!#1 の発表資料です
![NewsPicks を支える技術と怖い話](https://cdn-ak-scissors.b.st-hatena.com/image/square/219fb3d3e2e4a75b1845678a169fdf8cf7a6b85c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fea4cc40068f40132fd470a025a0ea166%2Fslide_0.jpg%3F4283160)
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
経営者たるもの、先ず第一に経営戦略の要諦をまとめなければなりません。 戦略的視点がない経営は場当たり的になり、それでは到底、事業の長期的な発展を望むことはできません。 それでも新米の経営者は、戦略をたてることが苦手です。 多くの場合、戦略と計画の区別もついていません。 今日は軽視されがちな経営戦略の立案法についてプログラマーの視点から見ていきましょう。 まず、経営をしようというときに最も重要なのは、ビジネスモデルです。ビジネスモデルは、変化の早いITの世界では3〜5年で一周すると言われています。IT企業の経営者ならば、常にビジネスモデルを変化させつつ、次の3年、次の5年に備えなくてはなりません。 ビジネスモデルとは、平たく言えば「どのように人様のお役に立ち、どのように価値を認めていただくか」ということ。短く言えば価値創造です。 なんらかの価値ある商品なりサービスなりを考案し、対価をいた
Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用 急速に人気が急上昇するWebサービスでは、どのようにスケールするアーキテクチャを構築し運用していくのかはサービスの成否を分けるほど重要です。Pinterestのように急成長してきたサービスのソフトウェア構成やリソース構成はどうなっているのでしょうか、Web上でいくつか情報が公開されているのでまとめてみました。 Pythonで開発し、Amazonクラウドで運用 1年ほど前なので少し古い情報ではあるのですが、Q&AサイトのQuoraにPinterestのco-founder Paul Sciarra氏が書き込んだソフトウェア構成の説明があります。 PinterestはPythonで開発されており、MemcachedやNginxなど高速なレスポンスに配慮した構成になっている様子がうかがえま
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね(しんぱいそうなめでみている) http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、1台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
インターネットのコンテンツ 最近インターネットを見ていて、本当に素晴らしいと思った記事が一つあります。 技術はコンテンツに対し中立でいられるのか?〜CD1枚74分とサビ頭ポップソングにその真髄を見る〜 この記事を簡単に説明すると、「技術の制約によって、コンテンツも影響を受ける」というような話しです。 その中に、an・anの記事がもしもインターネットメディアで公開するとすると、タイトルは以下のようになる、というような例がありました。 例えば、かつてなら『an・an』のような女性誌において、「夏の恋」に破れ、打ちひしがれた女性向けに秋を迎えて、「さあ元気になろう!」というような特集が掲載されるとするならば、そのタイトル見出しは 「一夏の花火よ、サヨウナラ!深まる秋に心を磨く」 というようなものになるのかもしれません。しかし、Web上でPVを稼ぐように見出しを付けると 「夏の失恋から回復するため
http://www.yamdas.org/column/technique/hatenablog.html なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた(ソフトウェア企業)が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か? プログラムをスクラッチから書き直すことに決めることだ。 まぁ、そんなわけないんだけどね。 「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試
プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
増井君と二人でPhotoShareというサービスを立ち上げてもう15ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ(JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく(上の図で、CSS,
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
元マイクロソフトのプログラマで書籍「Joel on Software」などでも知られる著名なプログラマであるジョエル・スポルスキー氏が立ち上げた、プログラマ向けのQ&Aサイト「Stack Overflow」。 月間1600万ページビュー、300万ユニークビジターのこのWebサイトがどのような構成になっているのか、Webサイト「High Scalability」の記事「Stack Overflow Architecture」に分かりやすいまとめが掲載されていました。 最大の特徴はスケールアップ型 Stack Overflowの特徴は2つあります。1つはスケールアップ型のアーキテクチャだということです。現代のマルチコア、大容量メモリ、パラレルプログラミング技術においては、スケールアップ型のアーキテクチャも重要な選択肢だと記事では説明しています。 その説明の通りStack Overflowでは、
前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは2つあります。 (1)言語やフレームワークの選択自由度が上がる 現在運
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く