もはや２年以上前の話ですが、PGEconsというところスマポでの導入事例を発表していました。 https://www.pgecons.org/2013/12/03/2742/ その際の資料はこちら PGECons発表資料 - PostgreSQL導入事例 from Misato Takahashi この時の発表はこちらの記事に大変よくまとめられておりまして。発表資料をよむよりこちらを参照していただいた方がいいかもw 内容は超ざっくりと、、、 位置情報使うならなんだかんだPostGISがいいよね HStoreやJSON型などNoSQL的な機能も豊富だよ 今はパフォーマンスも十分だし、運用も楽です というような内容です。 僕も１０年ぐらい前に7系を使って以来このサービスで久々にいじったのですが、当時のイメージは全くないですね、SQLも素直だし、今後も選択肢の１つに入れていいデータベースかなと思

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

以前 (2.6.31 まで?) は以下の挙動*1。 最初のペイロードを受信するまで SYN_RECV ステート クライアントの ACK (TCP ハンドシェイクの最後のパケット) を受信していたとしても、SYN-ACK を送り続ける 190 秒たったら、サーバ側は TCP 接続確立失敗と認識 クライアントは SYN-ACK を送ってるから接続できてるつもり TCP の仕様的にどうなの、って話はわかる。ただ、IP 層はパケットロスの可能性があるわけで、インターネットを使っていて、この挙動で問題があるとしたら、それはアプリケーションのバグだと思うけど。一方で、 LAN 上でパケットロスが (ほぼ) 起こらない前提で作ってたら困ることがあるのかなー。Ubuntu の BTS で話が出てるのは、そういうケース (特定のハードウェアロードバランサと TCP_DEFER_ACCEPT を使う Apac

HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション

SpoutCoreは、特定のプラグインを利用することなしにレスポンス性の高いデスクトップレベルのアプリケーションを構築できるJavaScriptライブラリ。特定のWebサーバーに依存することなく、さまざまな既存の環境で利用できる。HTML5の最新機能を利用することから、HTML5アプリケーションフレームワークと称している。 もともとは自社電子メール管理サービス「Mailroom」のために社内で開発・利用されていた技術で、米Appleが「MobileMe」で利用しているほか、Mozilla Foundationもプロジェクトで採用している。 SproutCore 1.0では、18ヶ月の開発期間を費やして2万行を書き直したという。6000回以上のユニットテストを行い、全体の安定性とAPIの一貫性を強化した。パフォーマンスも高く、複雑なアプリケーション構築にも利用できるレベルに達したと報告されて

米Googleは3月19日、Webアプリケーション向けのセキュリティ脆弱性スキャナ「Skipfish」を公開した。現在最新版となるバージョン1.1ベータのコードが公開されている。 Skipfishはクロスサイトスクリプティング、SQLインジェクションなど、Webアプリケーションで発生する可能性のあるセキュリティホールをスキャンして検出するツール。誤検知を抑えた高度なセキュリティチェックを導入、捉えにくいセキュリティホールを検出できるとしている。Cで実装されており、HTTPハンドリング向けに最適化することで速度を改善、LAN環境で毎秒2000件以上のHTTP要求を処理できるという。使い勝手が良い点も特徴としている。 検出できる問題としてはSQLインジェクションやシェルコマンドの実行、XML/XPathインジェンクション、フォーマット文字列のチェックミスや整数オーバーフローといった危険度の高い

GTK+ではDrawingAreaというGUI部品を用いることにより、その中に自由に描画を行うことができる。 GUI部品の描画はウィンドウのサイズ変更時や最小化後の最小化解除といった場面で描き直しがされるようになっているが、これもうまく処理されるようにできる。 ここではPyGTKでDrawingAreaを用いる上でのメモを扱う。 流れ DrawingAreaを用いたときの大まかな流れは決まっている。 gtk.DrawingAreaクラス(もしくはこれを継承したもの)のオブジェクトを作成し、他のGUI部品と同様にウィンドウに配置する size-allocate,realize(GDK使用時のみ),expose-eventのシグナルをハンドラに関連付ける GDK使用時にはrealizeシグナルのハンドラでgtk.gdk.GCオブジェクトを作成し、色などの属性を設定する expose-event

俺「新しいアプリだよ。さぁ、デプロイするからAppSlotを解放するんだ…!」 appengineたん「で、でぷろい…ですか…?こんなおっきなあぷり…は、入るかな…?」 俺「今日はScalaを使ったアプリケーションなんだよ」 appengineたん「Scalaなんて…そんな変態的なこと…で、できません ///」 俺「もう遅いよ。どうだ? どんどんアプリがアップロードされていくぞ!」 appengineたん「は、入りました…。こんなおっきなアプリケーション…あついです…」 俺「よしテストだ。どんどんリクエストをおくってやるからな」 appengineたん「そ、そんなにリクエストされたら…らめぇっ!!SpinUpしちゃうぅっ!!」 俺「まだまだいくぞ。おらっ!データストアにputしてやるっ!」 appengineたん「らめぇぇ!あっ、あふれちゃうっ!!データが…quotaからあふれちゃうよぉぉ

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

java-ja温泉2日目の夕食。 @yoshiori がpythonのワンライナの楽しさを得々と語っていた。 @yoshiori「Brainf*ck を Python-oneliner にコンパイルする Python-onelinerを書いたけど全ッ然反応がなかった。こんなに面白いのに！」 @yamashiro「だって分かりにくいもん」 西尾先生が通常ワンライナではtry-catchが使えないけど子プロセス立ち上げて例外を出力してパースすればエラー処理ができるとか(http://www.nishiohirokazu.org/blog/2006/08/python_12.html参照)そんな話で盛り上がる中、 @nagise「Javaでセミコロンなしでプログラムが書けるような気がしてきた」 Javaの場合、普通にセミコロン(;)でマルチステートメントにかけるのでただ1行にしようというなら改行