
シルバーウィークにバイト先の開発合宿に参加して,WeDictionaryというウェブサービスを作りました. Greasemonkeyを入れると,登録された単語がハイライトされて,その場で説明を読めます(リンク先にデモがあります). http://wedictionary.appspot.com こう便利 例えば,「DNBK」という言葉に,「ドン引きすること」と説明を書いておくと,どこでもその説明が出るようになるので,以後,DNBKの意味について困る人が減ります. 一緒にやった人 合宿中,id:mechairoiさんが暇そうにしていたので,手伝ってもらいました. id:mechairoiさんには,RubyもPythonも知らないのに,RamazeからGAEに移植していただいたりと,大変感謝しています.
非モテSNS内で、mixiのecooのような、 twitterのよーなものを、google app engineを使って開発してみた。 使った言語はAjax + Flash + gae(python+mysql+memcached)。 そんで、手抜き&googleを過信しすぎて リクエストの度にSQLをたたくような↓みたいな処理をかいてたら、(言語はpython) def get : sql = 'SELECT * FROM hoge LIMIT 50'; dbObj = db.GqlQuery(sql); ..ディスク<帯域<CPUの順に制限が...の記事どおりの現象が発生。1日50万リクエストくらいでCPUオーバー。w 規模としてはだいたい、約1日10万〜30万pv程度で、 会員数は20000人でopenPNEで動いてるサービス。 そんで、仕様をみなおして memcacached 化し
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね(しんぱいそうなめでみている) http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、1台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
If you need to see a list of the reboots of your system with date and time stamps then on a Linux with systemd you can use (as non-root) the command: journalctl --list-boots This could be useful if you are trying to track when a power outage occurred. An alternative is: /bin/sudo grep "^-" /var/log/boot.log ^ This only shows the boot start date/times while the journalctl command shows a "LAST ENTR
Etherpad is a highly customizable open source online editor providing collaborative editing in really real-time. Collaborating in really real-timeNo more sending your stuff back and forth via email, just set up a pad, share the link and start collaborating!Etherpad allows you to edit documents collaboratively in real-time, much like a live multi-player editor that runs in your browser. Write artic
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く