[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

2016年2月23日のブックマーク (7件)

  • goでスクレイピングするのにgoquery + bluemonday が最強な件 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    goでスクレイピングするのにgoquery + bluemonday が最強な件 - Qiita
  • 塩締め、昆布締め、漬けなど、魚をおいしくする一工夫 - はてなニュース

    魚を料理するとき、調味料などでちょっと一手間加えると、うま味を出したり、感を良くしたりすることができます。塩締めや昆布締め、漬けなど、魚をもっとおいしくする方法を集めました。 ■ 熟成したうま味が楽しめる「塩締め」 ▽ 熟成させた刺身が美味い。〜「塩締め」の作り方〜 - 鯖と烏賊 ブログ「鯖と烏賊」のid:sabatoikaさんは、お気に入りだという「塩締め」の作り方を紹介しています。魚の切り身に塩を振って冷蔵庫で寝かせておくと、水気が抜けて味が濃くなるとのこと。3~7日経ったあたりがべごろだそうです。傷まないよう、作業中は衛生面に気を付けましょう。 ■ 料亭の味「昆布締め」を家庭でも ▽ 鯛の昆布締めのレシピ/作り方:白ごはん.com 料亭や寿司店などで出される機会の多い「昆布締め」。白ごはん.comでは、真ダイを使った昆布締めの作り方が見られます。塩を振った昆布で真ダイの刺身をはさ

    塩締め、昆布締め、漬けなど、魚をおいしくする一工夫 - はてなニュース
    y_uuki
    y_uuki 2016/02/23
  • MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage

    毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー?温暖化ってやつ?日の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気

    y_uuki
    y_uuki 2016/02/23
  • Fluentdのin_forwardに流れているレコードをtcpdumpで見る - ryotarai's blog

    番環境で動いているFluentdのin_forwardに何が流れているのかを知りたい、けど設定を触りたくない…みたいな場合に流れているタグやレコードを見る方法です。特にFluentdに限った話ではないですが、備忘録として書いておきます。 1. tcpdumpでキャプチャ 調べたいサーバ上で、tcpdumpを使ってパケットキャプチャを取ります。in_forwardのポート番号などを指定してキャプチャします。 $ sudo tcpdump -i eth0 -w fluentd.pcap port 24224 and tcp 2. tcptraceでTCPストリームのデータだけ吐き出す tcptraceは-eオプションを渡すと、TCPストリームごとのデータをファイルに吐いてくれるのでこれを利用します。なお、tcptraceはHomebrewやaptで入ると思います。 $ tcptrace -e

    Fluentdのin_forwardに流れているレコードをtcpdumpで見る - ryotarai's blog
    y_uuki
    y_uuki 2016/02/23
    現場じゃん
  • 分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo

    昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication のをベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌

    分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo
  • ヤフー社内でやってるMySQLチューニングセミナー大公開

    3. Yahoo! JAPANのRDB環境 • 11g RAC Enterprise Edition • 約200DB • サーバ 200台, Exadata もあるよ • MySQL 5.1 (RR,Mixed) Percona 5.5 (RR,Mixed) Percona 5.6 (RC,RBR,GTID) • 約500DB • サーバ 300台 Oracle Database MySQL Percona

    ヤフー社内でやってるMySQLチューニングセミナー大公開
  • 分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo

    前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか?」「データフローは

    分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo