AcrobatのOCRエラー（その後） - Mugicha2004の日記
スキャンした雑誌PDFファイルは300〜600ページ程度。Acrobatで一気にOCRするとエラーで スキャンした雑誌PDFファイルは300〜600ページ程度。Acrobatで一気にOCRすると「Paper Capture 認識サービスのエラーにより、ページを処理できません」エラーでアウト。 そこで、ページ分割にチャレンジ。5ページ単位、10ページ単位、1ページ単位など、さまざまなサイズに分割。それらをOCRさせることに。 以下、まとめです。 分割したPDFファイル、2,000〜3,000個をまとめてAcrobatOCRすると、やっぱりエラーは発生する。 発生するけど、エラーでAcrobatが落ちる前までのPDFファイルは、OCR化に成功している。 エラーが発生したPDFファイルは、エラー発生のページ以降がOCRナシではなく、全ページがOCRされる状態に。 エラー発生のページは、そのページ
「オタク婚活」サイトが急増 オタク同士なら理解し合える
オタクな男女を結びつける「婚活サイト」が増えている。一般の婚活の現場では敬遠されることも少なくない。それならば、初めから理解し合うことができ、結婚後もオタクライフを楽しめる相手を見つけた方がいい、というわけらしい。 オタクの婚活サイトを検索してみると、「ヲタ恋」「アエルラ」「オタ恋」「オタこん！」「I`ｍ single」など、たくさん見つかる。ほとんどが最近オープンしたばかりだ。 アニメ「らき☆すた」の鷲宮「オタ婚」がきっかけ 結婚相談所「ファーストコンタクト」がオタクな男女を対象としたサイト「ヲタ恋」をオープンしたのは2011年5月31日。同社は歴史のある相談所なのだが、オタクの出会いの場を提供するきっかけとなったのが2010年11月に埼玉県鷲宮で開かれたイベント「オタ婚」の成功だったという。 鷲宮はアニメ「らき☆すた」の舞台として知られ、オタクが大挙するようになっていた。オタクの出会い
簡単におっさん画像を入手する方法 - hitode909の日記
部長とか専務とか，おっさんがやってそうな役職でイメージ検索すると，おっさんの画像がたくさんヒットする． 校長だとこんな感じ．いろいろ試したけど，校長と名誉会長がいい感じだった． google:image:部長 google:image:課長 google:image:係長 google:image:専務 google:image:校長 google:image:会長 google:image:取締役 google:image:名誉会長 google:image:料理長 よかったですね． 追記 代表取締役も良いそうです． "代表取締役"で検索するとより効率的に探せる。 URL 2011-06-20 12:00:56 via web google:image:代表取締役 追記2 釣果もいいです よりシチュエーションに特化したいいおっさん検索のキーワードないかな URL 2011-06-20 1
Tokyo.vclでVarnishCache3の新機能とVUPの仕方を話してきました – cat /dev/random > /dev/null &
hmskさん主催の第一回のTokyo.vclでVarnishの話をしてきました。 5分～15分の長さでと言われたのでのんびりいっぱい喋れる！ ・・・と思ったら詰め込みすぎて結構早口で聞き取りにくかったかもしれません。 申し訳ないです。 内容はVarnishCache3.0の新機能と2.1/2.0系からVUPするときの変更点についてです。 UST（５分あたりから喋ってます） あといくつか資料で補足したい点がありましたので・・・ 別にESI使わなくてもgzip対応の恩恵は受けられるよ！ おもいっきりESIでgzipサポートとは書いていますが別にESIに限ったことではないのでESIを使わなくてもgzipは使えます。 スライド中には一行でしか書いてないのですが、 今まではVarnishではgzipの処理ができなかったので１つのオブジェクトに対してgzip・圧縮されてないコンテンツを持つ場合 両方を
私がクックパッドの画像配信野郎です - 昼メシ物語
一年ほど前にヤフーを退職した私ですが、その後なにをやっているかというと、クックパッドに入社して画像配信をしています。私が入社する前から動いていた画像配信の仕組みは設計が古くてなにかと困っていたので、より良いシステムを開発してリプレースというのをやっています。前職ではなかなかこういう基盤システムを一人でイチから作って運用までするという体験はできなかったので、でかい仕事をできるチャンスに恵まれて大変充実した毎日です。 入社当初はサービス開発の担当だったんですが、開発に必要な基盤システムを作り始めたらどんどんエンジニアリングのレイヤーが下がってきて、気づけばインフラチームに所属していました。 まあそんな話はさておき、この画像配信関連の成果をいくつかの勉強会で発表したので、その資料を紹介します。 サイバーエージェントxクックパッド合同勉強会（amepad） 弊社オフィスで開催された、サイバーエージ
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.memetodo.co.cc/2011/06/javascript.html