開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
Socket.IO のサーバは v0.7 からスタンドアローンでも立てられるようになりましたが、 Express のサーバ上に Socket.IO のサーバを同居させる構成は多いと思います。 しかし Socket.IO は Express が HTTP で確立したセッションとは別のコネクションを確立するため、 例えば、 Socket.IO で接続したユーザが Express で認証したユーザかどうか等が判別できません。 そこで、 Socket.IO で接続を確立時に Express のセッション用の Cookie を取得して、接続を識別できるようにし、 さらに Socket.IO でのやり取りが長くなっても、その間にセッションデータが切れることが無いように、更新する必要が有ります。 Socket.IOv0.7 を用いてこれを実現する方法が、こちらで紹介されていたので、試してみました。 So
Webframeworks LLC - Open Souce Projects Dramatically improve your Ajax application performance with JSOC - the JavaScript Object Cache framework. AjaxのレスポンスをキャッシュするJavaScriptライブラリ「JSOC」。 次はJSOCを使ってXMLHTTPRequestの結果をキャッシュするサンプルスクリプト。 var xhttp = new xhttp(); // use your XMLHTTPRequest library of choice! function setCache(n,v){ var respCode = jsoc.set(n, v); alert('Data containing ' + n + ' was fetc
昨日、livedoor テクノロジーセミナーに参加してきたので、そのメモと感想を。 アジェンダ セッション1: 「はてなの開発/運用体制について」 / はてな 伊藤直也氏 セッション2: 「livedoor Readerについて」 / ライブドア ma.la氏 セッション3: ディスカッション / はてな 伊藤直也氏、ライブドア 池邉氏 セッション4: 質疑応答 メモ 自分の意見は文字色を変えてます。 セッション1: 「はてなの開発/運用体制について」 / はてな 伊藤直也氏 id:naoya:20061214:1166063145 に発表資料。 はてブのサーバー構成について 特性に合わせて3つのセグメントに分けているのが、非常に特徴的だと思った。 通常リクエスト用 bot用 → リクエストが非常に多いがレスポンス速度はそんなに重要じゃない イメージやカウンタなど → Webサーバーに負荷
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 そろそろRaspberry Piセットの日経BPムックが皆さんの所に届いていることでしょう。 僕も何台かRaspberry Piは持っていて、以前mod_mrubyをRaspberry Piで動かしてLチカしたりしていたのですが、今回はmod_mrubyとRaspberry Piを4台使ってでクラスターを組んで見ました。 まずはラック作りから まずは、Raspberry Piのラックを作りました。Raspberry Piのラックやケースをググると色々と出てくるのですが、なんとなく今回はそこら辺にあるものを使ってラックを作ってみました。Raspberry Piラックは以下の様になります。 上から見ると、以下のような感じです。適当にニトリのキッチ
実際のサービス運用時はないと思いますが、debugしているときやトラブルの調査をしているときにmemcachedのキー一覧を閲覧したいときはありますよね。 そんな時は、telnetを使って下記のコマンドを打つことでKey一覧を取得することができます。 $ telnet localhost 11211 stats items STAT items:1:number 6 STAT items:1:age 20505 STAT items:1:evicted 0 STAT items:1:evicted_time 0 STAT items:1:outofmemory 0 STAT items:1:tailrepairs 0 stats cachedump 1 100 ITEM foo [9 b; 1264464651 s] ITEM bar [9 b; 1264464649 s]ざっとこんな感じ
Redis は基本的にシングルスレッド、イベントドリブンモデルなので、時間のかかるLua スクリプトを実行したらどうなるかというのは想像に難くないのですが確認してみました。 Redis は 2.6.14 です。 redis-cli eval 'while true do print("hello") end' 0な感じのを実行します。 実行中に、別クライアントから GET, INFO, PING すると全てブロックされて結果が返ってきません。 redis.conf で lua-time-limit 5000 と設定している場合は、5秒後に redis-server のログに [18068] 22 Jul 13:51:23.798 # Lua slow script detected: still in execution after 5000 milliseconds. You can t
テストコード書いてますか？ HIROKIです。 murahashiに続いて、テストファーストを導入してみての振り返りをします。 まず、どうやってチームにテストファーストのスタイルを持ち込んだのか。 1．テストが重要だという共通認識を持つ。 前のプロジェクトではテストコードは、ほとんどありませんでした。 その中で、開発になれていない人や新たに人が投入され、 極少数ですが、デグレーションが起きました。 その経験を元にテストが重要だという共通認識を持つことができました。 2．プロジェクト開始時からテストファーストに踏み切る気持ちが必要 テストコードを書かなければコミットさせない。ぐらいの気持ちが必要です。 実際に何度も、本格的な実装が始まる前から口にしていました。 「うちのチームはテストを書かなければコミットを許さない。」と。 3．でも、テストコード書いたことないよ？ テストコードを書いたことの
皆様におかれましては、WEB+DB PRESSの最新号のRedis特集は既にご覧頂いたかと存じます。 弊社では1年ほど前から広告配信に関する様々な部分でRedisを使っています。まだ2.4系なので、2.6の新機能とか新鮮でした。 本番環境でRedisを運用する上で、強く訴えたい注意点は「RDBが壊れることがある」ということです。 「RDBがあるからインスタンスが落ちても平気だぜ」とか思ってると、RDBが壊れてリストア失敗→データ消失ということになりかねません。ファイルにdumpされるからと安心していると痛い目に遭うかも知れません。 （2013/02/27追記）今のところ壊れたのはハード障害が怪しい場面のみです。「RDB壊れるとかRedis使えねー」とかそういう話ではまったくありません。誤解無きよう。壊れる時はRedisじゃなくても壊れます。自分のユースケースではTokyo Cabinet/
Redis-Commander
What is Redis Commander? Redis-Commander is a node.js web application used to view, edit, and manage a Redis Database Download .zip Download .tar.gz View on GitHub Features
どうも初めまして2012年度入社の社内ニート予備軍editnukiです。 普段は引きこもって WebSocketで監視もリアルタイムに を書いた社内ニートさんの下でコミュニティサービスのインフラをやっております。 運用面以外ではrpmパッケージ作ったりしています。 さて、本題ですがコミュニティサービスでもredisを利用したいという声が最近多くなりいくつかのサービスではredisを導入しているのですがマスターとなるredisが死ぬと更新系が一切できなくなるため、マスターが死んだ時はアプリの向き先をスレーブに変更しなければなりません。 今までのredisの構成としては下図の様な構成でした。 redisの2.6系がリリースされた時に「sentinel」というフェイルオーバーの機能が追加されました。 詳細は公式ドキュメントをご参照ください。 フェイルオーバーしたとしてもアプリ側にマスターが切り替
Redis による分散ロック¶ 異なるプロセス同士が、相互に排他的な方法で共有リソースに対して操作を実行する、という環境において、分散ロックは非常に役に立ちます。 Redis を使った DLM (Distributed Lock Manager) の実装については、多くのライブラリやブログポストがあります。しかし、ライブラリごとに異なるアプローチがとられており、またその多くは、より複雑なデザインと比較するとシンプルで、そのぶん保証される内容が低いアプローチとなっています。 このページは、Redis 上で分散ロックを実装するにあたり、標準的なアルゴリズムを提供することを目指すものです。私たちはここで Redlock と呼ぶアルゴリズムを提供します。これは DLM 実装の一種で、よく見かけるような、ひとつのインスタンスを使うアプローチよりも安全である、と私たちは考えています。コミュニティがこの
国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。 Kyoto Tycoonなら: memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる（memcachedプロトコルを喋るクライアントコードはそのままでよい） Tokyo Tyrantと違ってexpireもOK memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK 非同期レプリケーションもできる ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台の
net.core.somaxconnについて調べてみた - 祈れ、そして働け ～ Ora et labora
概要 ↓ memcachedのtcp_backlogのデフォルト値は1024で、stats settingsにも1024と表示されているのですが、 stats settings ... STAT tcp_backlog 1024 ... END↓ net.core.somaxconnがデフォルト値のままだと128に切り詰められてしまい、 # cat /proc/sys/net/core/somaxconn 128負荷が高いサーバーでは接続要求を取りこぼしてしまうことがあるそうです。 このnet.core.somaxconn、MemcacheやMySQLなど、高負荷時に多くの接続要求を受け付けるサーバーではチューニングが必要なカーネルパラメータのようです。いったいどういう値なのか、調べてみました。 net.core.somaxconnとは TCPソケットはlisten()関数の第二引数 ba
AWS、Redisをフォークした「Valkey」を、同社サービスのElastiCacheとMemoryDBで採用すると明らかに
AWS、Redisをフォークした「Valkey」を、同社サービスのElastiCacheとMemoryDBで採用すると明らかに Amazon Web Servicesは、同社のマネージドサービスとして提供しているAmazon ElasticCacheとAmazon MemoryDBで、インメモリデータストアのRedisをフォークした「Valkey」を採用すると、同社のブログに投稿した記事「Why AWS Supports Valkey」で明らかにしました。 Why #AWS Supports #Valkey. https://t.co/PMXv0Zv8B4 — Werner Vogels (@Werner) April 5, 2024 Valkeyの採用について、上記のブログで次のように記されています。 AWS is committed to supporting open source
ある PHP 案件の振り返り | Carpe Diem
2015 年、僕がメインで担当したとある PHP 案件の振り返りを行ってみようと思います。おもに技術面から、設計前に想定したこと、実際に導入してうまくいったこと・いかなかったことを振り返ってみたいと思います。 技術的な環境は、次のとおりです。 インフラ環境: オンプレミス（だいだい６台くらい、このときのためにほぼハードウェアを新規に調達しました） OS: CentOS 7.0 言語: PHP 5.6 フレームワーク: FluelPHP 1.7.x データベース: Postgresql 9.3 ミドルウェア ロードバランサー冗長化: Keepalived（新規） ウェブサーバ: Apache から Nginx に変更、PHP は FPM キャッシュ: Redis（新規） 検索: Elasticsearch（新規） ログ: Fluentd（新規） 監視: Nagios & Cacti & Mu
memcachedを安全に運用するポイント 2010年8月10日のスラッシュドット・ジャパンにて「Memcached に潜むセキュリティホール」としてmemcachedの脆弱性に関する記事が上げられました。記事の内容をまとめると以下の2点となります。 bit.ly や Globworld、Gowalla といったサイトではインターネットから memcached へのアクセスが可能であった アクセスしたmemcached上にユーザーのログイン ID / パスワードが格納されており参照可能だった http://slashdot.jp/security/article.pl?sid=10/08/10/0052240 ここには2つの問題があったと考えます。1つ目はmemcachedをインターネットから接続可能な状態で設置してしまったこと、もう1つはキャッシュ上に置かれている必要はなさそうなパスワー
PHPのクラスに備わっているstaticはJava(Servlet)のそれとは違いHTTPのリクエストが完了すると破棄されてしまいます。 そのためstaticフィールドを使ったシングルトンの実装を行ったとしてもリクエストがある度にインスタンスが生成され独立したプロセスから同一のインスタンスにアクセスすることは不可能です。 そこで今回memcachedを利用しPHPの各プロセスから同一のインスタンスを参照できるようにしてみたいと思います。 といってもシリアライズさせているので厳密には別のインスタンスになりますが…。 ちなみにmemcachedとはオブジェクトをメモリにキャッシュさせるPHPとは独立したサーバプログラムです。 利用できる言語はPHPだけに限らずPerl、Ruby、Java、Pythonなどにも対応しています。 インストールは./configure && make &
LINE Engineer Insights vol.1 「LINE BOT 育ての親に聞く、LINEの誕生と成長」 : LINE Engineering Blog
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEで働くエンジニアに色々と話を聞いていく新コーナー「LINE Engineer Insights」をスタートいたします。インタビュアーにはLINEで働くエンジニア @tokuhirom を迎え、エンジニア同士でざっくばらんにお話を伺っていきます。LINEのエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。 今回は、開発1センター LINE開発室 B Partチーム所属の熊井に、コミュニケーションアプリ「LINE」の誕生時のことや現在担当されているLINE BOTのバックエンドの話などを聞いてきました。 B Part のBはBOTのB？ ―― tokuhirom 今日は宜しくお願いします。熊井さんとはB
How HipChat Stores and Indexes Billions of Messages Using ElasticSearch and Redis - High Scalability -
« Sponsored Post: Netflix, Logentries, Host Color, Booking, Apple, ScaleOut, MongoDB, BlueStripe, AiScaler, Aerospike, LogicMonitor, AppDynamics, ManageEngine, Site24x7 | Main | Stuff The Internet Says On Scalability For January 3rd, 2014 » This article is from an interview with Zuhaib Siddique, a production engineer at HipChat, makers of group chat and IM for teams. HipChat started in an unusual
先日開催された memcached Night in Tokyo #1 というのに参加してきた。 http://groups.google.com/group/memcached-ja/web/memcached-night-in-tokyo-1 夕方6時開催という昨今の勉強会としては早めの開始時刻なので、あたふたと会社を出た。場所は原宿である。おされな場所である。浮足立つ。ということはどうでも良くて会場であるmixiに初めていったのだが綺麗なオフィスであった。 memcachedというのは、データベースに対する分散メモリキャッシュ技術みたいなもので昨今のWebではよく利用されている。国内ではmixiでの事例がよく知られている。 http://ja.wikipedia.org/wiki/Memcached この話を初めて聞いたとき、うーん随分乱暴な話だな、RDBMSでやるべき仕事だろ、そー
今回は、1.4になってアップデートされた新機能を中心に紹介します。 memcachedとは？ memcachedとは、主にデータベースへの負荷を下げ、かつWebアプリケーションのスケーラビリティをコストパフォーマンス良く向上させる高性能な分散キャッシュサーバです。memcachedの基本や概要に関しては、以前ミクシィ運用グループの長野と執筆した「memcachedを知り尽くす」をご覧ください。 memcached 1.4の特徴 1.4、5つの特徴 memcached 1.4の大きなニュースの1つはバイナリプロトコルの正式導入です。また、他にも色々と嬉しい機能や改修が施されています。詳しくは1.4のリリースノートに記述されていますが、要約すると以下の5点が上げられます。 バイナリプロトコルの正式導入 パフォーマンス向上 統計システムの強化 報告されたバグの修正 テストの強化 入手先 memc
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
こんにちは、hachi8833です。 今回は棚卸しとして、弊社CTOのbabaさんによるRails勉強会スライドから引用して記事にします。 勉強会自体はRails 3.x時代のものなので既出が多くなっていますが、棚卸しも兼ねて今のうちに記事にいたしました。 非同期処理 言うまでもなく、リクエストからレスポンスまでの時間が長くなるほどユーザー・エクスペリエンスの質が低下します。これを改善するためにさまざまな工夫が必要になるわけですが、その中の一つとして、時間のかかる処理をバックグラウンドで実施しておくというのがあります。 cron 最も素朴な方法はやはりunix標準のcronを使って定時に出力データを準備することでしょう。この場合、起動用スクリプト(rakeなど)やジョブ管理は自分で作成する必要があります。 delayed_job delayed_job gemを使用すると、ジョブをActi
最近のWebシステム開発ではキャッシュを使うケースが増えつつある。各種Webアプリケーション向けフレームワークでもキャッシュをデフォルトでサポートしているものも多く、その筆頭に挙げられるのがmemcachedだ。 top風にmemcachedのステータスが確認できる memcachedは軽量で、あると便利だと思える機能が殆ど実装されていない。ステータスを監視するような機能もないが、そこは独自に開発されたmemcache-topを使えば解決する。 今回紹介するオープンソース・ソフトウェアはmemcache-top、memcachedのステータスを表示するコマンドラインスクリプトだ。 memcache-topはPerlで作られたスクリプトで、既に立ち上がっているmemcachedサーバを一覧し、そのステータスを表示してくれる。デフォルトで3秒ごとにリフレッシュされるようになっており、topコマ
アメーバ事業本部コミュニティ事業部の大﨑 (@hiroosak)です。 24LOGというサービスの開発を担当しています。 サイバーエージェントでは、コミュニティサービスが多数存在しているのですが、 実は、その中のいくつかのサービスでRailsが使われています。 ですが、社内・社外問わずあまり知られていないようです。 なので、今回は、Railsを使ったプロジェクトでは どのように開発が行われているかを簡単に紹介したいと思います。 基本構成 構成図の概要は上の図の通りです。 (監視サーバなどは上の図から省いています) 静的なファイルは、社内の共通ストレージに置き、検索については 社内のラボチームで用意したシステムと連携しています。 なのでプロジェクトのチームでは、主に app, db, cache, queue を見ています。 ちなみに、rubyのバージョンは主に2.0, railsは3.2で
expressやsocket.ioのテストはこんな感じで書いてます、というお話 - アルパカDiary Pro
最近仕事ではNode.jsしか書いてないtoritoriです。 お仕事でもexpressやsocket.ioを使っているのですが WebアプリケーションのテストについてWeb上にあまり書かれていないような気がします。 特にソケット接続した後のメッセージ送信/受信の部分です。 今までのようなHTTPの単純なリクエスト/レスポンスとは手法が異なりますしどうしたものかと。 そこで「自分はこんな感じでテストしてますよー」という記事を書いてみます。 裏を返せば「もっといい方法あるよ！」というのを聞きたいのです＞＜ サンプルについて socket.ioのexample を使います。 ただし、サンプルではログイン時に遷移しない方式なので もう少し実用的な動作に近づかせるため あえてログインURLから遷移するようにし、 セッションもRedisを使うようにしてexpressとsocket.ioでセッションを
Where should you run your workload? It depends...Choosing the right infrastructure options to run your application is critical, both for the success of your application and for the team that is managing and developing it. This post breaks down some of the most important factors that you need to consider when deciding where you should run your stuff! What are these services?Compute Engine - Virtual
ついに発売されたスト4のコンシューマ機版をやりたくてしょうがないけど筐体を買ってもらえないので、駅前のゲーム屋のディスプレー前で垂涎するばかりのmikioです。今回は連載の最終回で、各種スクリプト言語を使ってお手軽にテーブルデータベースを操作する方法について説明します。 TokyoCabinet::TDB まずは、TCのPerlバインディングとRubyバインディングの最新版を入手してください。それぞれテーブルデータベースを扱うための TokyoCabinet::TDB というクラスが加わっています。以下のようなIDLによるガイドラインに準拠したインターフェイスが提供されますので、使い方は言語にかかわらず同じようになるはずです。 module TokyoCabinet { interface TDB { boolean open(in string path, in long omode);
ISUCONに行ってきました。社内での事前βテストに参加して問題を知っていたので出場はせず。社内β参加を持ちかけられたときは、正直「めんどくせーなｗ」が素直な感想だったんですが、実際にやってみるとスコアがリアルタイムにわかる＆ちょっとずつ自分のスコアが上がっていくってのは楽しくて、わりと本気でチューニングしてしまいました。 さて、本戦でも14時頃からお遊び用としてサーバー一式が解放されたので、大人げも無くそこで112500req/minをたたき出して参加者のやる気を削いだ（・・と懇親会で言われました。色々すいません！）構成について。 reverse proxy nginx(1.0.5) ngx_http_memcached + ngx_http_ssi_filter + ngx_http_scgi + ngx_http_upstream_keepalive(3rd party plugin
gumiStudy#2 で memcached の運用について喋ってきた - blog.nomadscafe.jp
例の件以来、memcachedについて書いたり話したりする機会が多く頂いています。次はShibuya.pm で再び監視について発表する予定です。また、今回の発表でも紹介したリソースモニタリングツール cloudforecast はYAPC::Asiaで詳しく説明します。Shibuya.pmは参加のキャンセル待ちがかなり多い状態ですが、YAPC::Asiaはまだまだチケット絶賛発売中です。ぜひいらしてくださいませー。 \n\n例の件以来、memcachedについて書いたり話したりする機会が多く頂いています。次は[Shibuya.pm](http://shibuya.pm.org/) で再び監視について発表する予定です。また、今回の発表でも紹介したリソースモニタリングツール cloudforecast はYAPC::Asiaで詳しく説明します。Shibuya.pmは参加のキャンセル待ちがかなり
11/3に開催された #isucon2 に、隣の席の @pandax381 と一緒に、チーム双龍として参加してきました。 結果は惨敗だったのですが、そのレポートを書く前に、 #isucon2 で使う予定だった秘密兵器 recaro について紹介します。 recaro とは recaro はカーネル空間で動く httpd + memcached サーバーです。 httpd サーバーは @pandax381 が作成した tkhttpd で、 memcached は kmemcached というプロジェクトが 未完成のまま放置されていたのを見つけて、私がデバッグ＆高性能化したものです。 (KLab/kmemcached) 通常のnginx+memcachedだと ネットワーク <- TCP/IP ]-> nginx <-[ TCP/IP ]-> Memcached ([] はシステムコール) と
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Kazuho@Cybozu Labs: Mycached: memcached protocol support for MySQL
It is a well-known fact that the bottlenecks of MySQL does not exist in its storage engines, but rather in the core, for example, its parser and execution planner. Last weekend I started to wonder how fast MySQL could be if those bottlenecks were skipped. Not being able to stop my curiousity, I started adding memcached proctol support to MySQL as a UDF. And that is Mycached. From what I unders
私が山田浩之さんと共著させていただいた「検索エンジン自作入門」は、検索エンジンについて実際のプログラムを参照しながら解説を行った書籍です。 そのプログラムは、言語はC言語、データベースはSQLite、データソースはWikipediaを用いています。 読者の方が、自らの得意なプログラミング言語、データベースやデータソースを用いて実際に検索エンジンを書いてくださっているようです。うれしいので、それらを紹介させていただきます！ PHP id:masayuki5160さんこと、たなかしさんによる、PHPでつくる全文検索エンジン PHPはWebエンジニアにとって身近なプログラミング言語です。データソースもTwitterを用いていて、Webエンジニアにとって親しみやすい実装になっています。 Python id:nwpct1さんこと、めじろさんによる、Pythonでつくる検索エンジン(Webクローラ,
はじめに 突然ですが、みなさんはWindowsやWindows Serverに対してどのような印象をお持ちでしょうか？ Linuxと比べて良い点や悪い点はあるのはなんとなくわかるものの、総合的に、Windowsに対してあまり良いイメージを持たれない方も多いのではないでしょうか。 私たちの会社では、GREE向けにリアルタイムギルドバトル[1]と呼ばれるジャンルのソーシャルゲームをAWS＋Windows環境を使って提供しています。Web 業界全体を通しても珍しい、AWSかつWindowsという組み合わせの大規模Webアプリケーションをどのように提供し、継続的に運用しているのか、実際のところはどうなのか、といった点を今回は紹介したいと思います。 グラニが提供するソーシャルゲームの規模 実際に弊社で提供している「神獄のヴァルハラゲート」の規模感は次のようなものになります。 リアルタイムギルドバトル
OpenStreetMapで地図タイルサーバーを構築する OpenStreetMapはオープンソースの地理情報データを作成する事を目的としたプロジェクトで、 世界中の有志が地図を改善するために日々変更を加えています。 地図データはPlanet OSMで最新データが公開されていますが、 全データを導入するためにはハイスペックのサーバーと大容量のメモリが必要で、 参照するデータをSQLサーバーに入れるために最低でも数日間を要するため、 ベンチマーク情報が公開されているくらいです。 またダウンロードするデータ量も30GB近くあるため現実的ではありません。 そこで国別にデータが提供されている以下サイトよりデータを導入する事を推奨します。 http://download.geofabrik.de/asia.html 他の提供サイトについては以下URLを参照ください。 http://wiki.open
あのmiyagawaさんがjoinし、PerlをサポートするようになったPaaSとして大注目のdotcloudのinvite codeをいただいたので、早速遊んでみました。 http://now.kentarok.org/ ソース: https://github.com/kentaro/now.kentarok.org まあ普通の一行掲示板みたいなものなので特になにもいうことはないのですが、一応メモ。Perlでdotcloudの導入の一般的な話については、以下のエントリを参照ください。 dotCloud でPSGI Hello World - D-6 [相変わらず根無し] 前提 言語: Perl フレームワーク: Dancer ストレージ: Redis(PerlバインディングはRedis) Dancerのconfig use Dancer ':syntax'; config->{foo}{
ついったーさんやってますか? ついったーさんのバックエンドは、実はscalaで書かれているってご存じですか? 急成長するついったーさんのバックエンドを支えるなんてすごいですねscala! ついったーさんとscalaのお話は、こちらを参考に。 Twitter on Scala で、Kestrelというメッセージキューが、ついったーさんのバックエンドの一部で利用*1されています。 robey/kestrel · GitHub このKestrelはオープンソースで誰でも利用することができます。 ちょっと試してみましょう。 Kestrelの特徴 READMEに書いてあるものをものっそいてきとうに意訳します。 Kestrel is: fast It runs on the JVM so it can take advantage of the hard work people have put in
こんにちは、@f_subal です。 pixivFACTORY というサービスで普段はフロントエンドをやっています。 今回は Rails のサービスに Headless CMS の Contentful を導入し、ワークフローを改善した話をします。 ランディングページ、あるいはマスターデータの詳細について pixivFACTORY はグッズおよび同人誌がブラウザ上で簡単に作れるサービスです。 取り扱っているグッズは 60 種類以上あり、各グッズごとに仕様が大きく異なります。 グッズにはそれぞれ、仕様や出来上がりの写真を載せたページ（以下、product 詳細とも呼びます）が存在します。 要するに、以下の状況を想定してください。 運営が管理する静的なドメインモデル（ここでいう「作れるグッズの仕様」）が存在する モデルの各内容について説明するページが存在する 各ページの内容は DB の内容から
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Socket.IO と Express でセッションの共有 - Block Rockin’ Codes
AjaxのレスポンスをキャッシュするJavaScriptライブラリ「JSOC」:phpspot開発日誌
Hatena::Diary::take-m - livedoor テクノロジーセミナー
mod_mrubyを使ってRaspberry Piを4台でWebサーバクラスタを組んでみた
memcachedでキー一覧を取得したい時に - UNIX的なアレ
RedisのLuaで時間のかかる処理をするとどうなるか？ - （ひ）メモ
ウノウラボ Unoh Labs: アジャイルな開発をチームでやってみた(2010年版) - その2
redisのバックアップは慎重に | Nekoya press
『redisをsentinelとAliasIPを利用して冗長化』
Redis による分散ロック — Redis Documentation (Japanese Translation)
memcached(プロトコル)のデータレプリケーション - （ひ）メモ
第2回 memcachedのセキュリティと脆弱性 | gihyo.jp
memcachedを使ったPHPのシングルトン実装 - 徒然なるままにBlog
ユメのチカラ: memcached Night in Tokyo #1
第1回 memcached 1.4、基本の基本 | gihyo.jp
Rails勉強会まとめ -- 非同期処理/RSpecなど｜TechRacho by BPS株式会社
memcachedのステータスをtop風に·memcache-top MOONGIFT
『サイバーエージェントでRailsを使っているコミュニティサービスのお話』
elixir-phoenix-on-google-app-engine
DBMによるテーブルデータベース その五 - mixi engineer blog
isuconお遊びチーム（事前社内β組）の設定あれこれ - hideden.hatenablog.com
Isucon用Webサーバーrecaro : DSAS開発者の部屋
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
【作ってみた】書籍「検索エンジン自作入門」を読んで検索エンジン作ってみたリスト
第1回 C#へのこだわりは、より良いサービスへのこだわり | gihyo.jp
OpenStreetMapで地図タイルサーバーを構築する
dotcloudで遊んでみた - Kentaro Kuribayashi's blog
twitterでも利用されているメッセージキュー Kestrelを試す - ( ꒪⌓꒪) ゆるよろ日記
Rails + Contentful で LP のコーディングをゼロにする - pixiv inside