読者です 読者をやめる 読者になる 読者になる

reizist's blog

ウェブ

RDSでslow logが出力されない件

mysql AWS

結論

log_output = TABLE になっているから。 log_output = FILE にすればファイル出力される。

詳細

aws parameter groupsで指定するmysql parametersの log_output = TABLE 状態になっていることを確認した。 この場合、ログはファイルにではなくTABLE mysql.slow_log に格納される。

mysql> select * from mysql.slow_log order by start_time desc limit 10;
+---------------------+-----------+------------+-----------+-----------+---------------+-------+----------------+-----------+-----------+--------------------------------------------------------------+-----------+
| start_time          | user_host | query_time | lock_time | rows_sent | rows_examined | db    | last_insert_id | insert_id | server_id | sql_text                                                     | thread_id |
+---------------------+-----------+------------+-----------+-----------+---------------+-------+----------------+-----------+-----------+--------------------------------------------------------------+-----------+
| 2017-03-22 10:43:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |             1 | hogehoge |              0 |         0 | 794362535 | throttle:        755 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:42:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |           178 | hogehoge |              0 |         0 | 794362535 | throttle:        757 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:41:54 | [] @  []  | 00:00:00   | 00:00:00  |         0 |             0 | hoge |              0 |         0 | 794362535 | throttle:        759 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:40:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |           178 | hoge |              0 |         0 | 794362535 | throttle:        768 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:39:54 | [] @  []  | 00:00:00   | 00:00:00  |        24 |            24 | hoge |              0 |         0 | 794362535 | throttle:        757 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:38:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |           178 | hoge |              0 |         0 | 794362535 | throttle:        762 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:37:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |           178 | hoge |              0 |         0 | 794362535 | throttle:        771 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:36:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |             1 | hoge |              0 |         0 | 794362535 | throttle:        758 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:35:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |           178 | hoge |              0 |         0 | 794362535 | throttle:        757 'index not used' warning(s) suppressed. |     96738 |
| 2017-03-22 10:34:54 | [] @  []  | 00:00:00   | 00:00:00  |         1 |             1 | hoge |              0 |         0 | 794362535 | throttle:        755 'index not used' warning(s) suppressed. |     96738 |
+---------------------+-----------+------------+-----------+-----------+---------------+-------+----------------+-----------+-----------+--------------------------------------------------------------+-----------+
10 rows in set (0.01 sec)

尚上記の throttle: ..... index not used .... がうざい場合、

log_throttle_queries_not_using_indexes , log_queries_not_using_indexes のパラメータを変更する。

ちゃんとテーブルに格納されていることがわかる。 log_outputFILE に変更することでファイル出力されるようになる。

補足

  • RDSの場合(通常のmysqlと違い) log_output に複数のパラメータを指定できず、代わりに log_output = FILE の場合ファイルとテーブルに出力されるようになっている。なおデフォルトはTABLE。

参考:

HyperDrive: Thunderbolt 3 USB-C Hub for 2016 MacBook Proレビュー

家電 ガジェット

www.kickstarter.com

kickstarter経由で購入したMacBook Pro 2016用のusb-cハブ、 HyperDrive: Thunderbolt 3 USB-C Hub for 2016 MacBook Pro のレビューです。

仕様

f:id:reizist:20170320234525j:plain

外観

イカしてます。macbookとマッチする高級感があり、値段相応です。

レザー生地の入れ物もついているので持ち運びも問題なさそう。

f:id:reizist:20170321000328j:plain

実用性

推奨どおりの装着だと接触が悪く、しっかりハマっていない感じがする。自分のmacが悪いのかHyperDriveが悪いのかは謎。しかし推奨方法で使えないのでがっかりした。

とはいえ逆だと「カチッ」という音と共にしっかりハマっており通常通り動作している印象がある。 接触が問題ない状態だとすればかなり便利で、各種アダプタがない状態であたふたしないで済みそうなのでmust buy感がある。appleが作って欲しい。

個人的にはmicro-SDをmacbookに挿したいことが多く、この場合2つのアダプタを介すなどしており全く2017年にもなってなんて不便な生活なんだと思わなくもなかった。

所感

minimumで$69, shipping含めて $79したので高い。高いゆえに品質を期待していたので、残念に思う部分もある。

とかでもいいのかもしれない。

HatenaBlogScraper公開してました

1週間くらい前に深夜のテンションで作ったgem HatenaBlogScraper(HBS)を公開してました。

GitHub - reizist/hatena_blog_scraper

まぁ何をするものかというとhatena blogの記事をスクレイピングしますよってだけのgemです。

[1] pry(main)> require 'hatena_blog_scraper'
=> true

[4] pry(main)> c = HBS::Client.new(url: "http://reizist.hatenablog.com")
=> #<HatenaBlogScraper::Client:0x007fe6cc0e2788 @host="reizist.hatenablog.com", @url="http://reizist.hatenablog.com">
[5] pry(main)> c.list_articles
=> [#<HatenaBlogScraper::Article:0x007fe6cc18ab68
  @html=
   "<div class=\"entry-content\">\n  \n    <p>1週間前くらい前に深夜のテンションで作ったgem HatenaBlogScraper(HBS)を公開してました。</p>\n\n<p><a href=\"https://github.com/reizist/hatena_blog_scraper\">GitHub - reizist/hatena_blog_scraper</a></p>\n\n<p>まぁ何をするものかというとhatena blogの記事を<a class=\"keyword\" href=\"http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%EC%A5%A4%A5%D4%A5%F3%A5%B0\">スクレイピング</a>しますよってだけのgemです。</p>\n\n<p>それをhatena blogに書いちゃっていてどうなのと思わなくもないので<a class=\"keyword\" href=\"http://d.hatena.ne.jp/keyword/rubygems\">rubygems</a>に公開していないのと、個人ブログでひっそりと。</p>\n\n<p>何か問題があればご指摘いただけますと幸いです。</p>\n\n  \n</div>",
  @markdown=
   "1週間前くらい前に深夜のテンションで作ったgem HatenaBlogScraper(HBS)を公開してました。\n\n[GitHub - reizist/hatena\\_blog\\_scraper](https://github.com/reizist/hatena_blog_scraper)\n\nまぁ何をするものかというとhatena blogの記事を[スクレイピング](http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%EC%A5%A4%A5%D4%A5%F3%A5%B0)しますよってだけのgemです。\n\nそれをhatena blogに書いちゃっていてどうなのと思わなくもないので[rubygems](http://d.hatena.ne.jp/keyword/rubygems)に公開していないのと、個人ブログでひっそりと。\n\n何か問題があればご指摘いただけますと幸いです。\n\n",
  @text=
   "\n  \n    1週間前くらい前に深夜のテンションで作ったgem HatenaBlogScraper(HBS)を公開してました。\n\nGitHub - reizist/hatena_blog_scraper\n\nまぁ何をするものかというとhatena blogの記事をスクレイピングしますよってだけのgemです。\n\nそれをhatena blogに書いちゃっていてどうなのと思わなくもないのでrubygemsに公開していないのと、個人ブログでひっそりと。\n\n何か問題があればご指摘いただけますと幸いです。\n\n  \n",
  @title="HatenaBlogScraper公開してました",
  @url="http://reizist.hatenablog.com/entry/2017/03/17/010417">]

それをhatena blogに書いちゃっていてどうなのと思わなくもないのでrubygemsに公開していないのと、個人ブログでひっそりと。

何か問題があればご指摘いただけますと幸いです。

web+db vol97のMySQL運用最前線を読んだ

mysql 開発

前職でソシャゲ開発/運用をしていた関係でちょろちょろ触る程度のなんちゃってDBA/インフラーなのでそこまで深い知識は持っていないけど、 最低限時代についていく必要はあるので読んだ。 なんか間違ってること僕が書いてたら教えてください。

目次

について書かれている。

MySQLの現在

今現在の最新である5.7に至るまでのMySQL史が紹介されている。 次期リリースの「MySQL 8.0」はしばらくでなさそうだし、5.6はリリースされてだいぶ経っている。 5.7に移行したほうがいいよね、という熱感を高める文章が記載されている。

innoDB徹底活用

  • innodbの解説(デフォルトで有効なストレージエンジンだし他のストレージエンジンにする必要ないとか)
  • mysqlのパラメータの中でも最も重要な innodb_buffer_pool_size がオンラインで変更可能になったよ
  • ファイルフォーマット/行フォーマットの変更
  • 日本語の全文検索が可能になったよ

あたりが言及されている。

innodb_buffer_pool_size の動的変更、 バッファプールを増やす場合 全てのアクセスが禁止されるのでパフォーマンス劣化が懸念され、 バッファプールを減らす場合 チャンク単位のページ開放でロックを取得する場合他のトランザクションに影響する等でパフォーマンス劣化が懸念される

あたりが気をつける点としてあって、短期的なパフォーマンス劣化で中長期のパフォーマンスを向上させるものだという認識。 オフラインで対応する場合mysqlプロセスを停止させる必要があるが、その場合buffer_pool_sizeが大きければ大きいほどflushに時間がかかるのでダウンタイムが伸びる可能性があって、 どうしてもダウンタイム作れないものにはアクセス少ない時間帯にオンラインコマンド叩いとく感じになると思う。

とはいえauroraなどマネージド・サービスならデフォルトでインスタンスの ¾ のメモリ量になるよう設定されているようで足らなければインスタンス変更で対応しそうだし、 自前でmysql管理するレベルのチームなら最初に innodb_buffer_pool_size を適切に設定しておくだろうし、 よっぽどリリース時から想定されていないアクセスが来たみたいな状況じゃないと使わなそう?(素人意見)

フォーマットのデフォルトが変更されたあたりは多分メリットしかなくて、

  • デフォルトがAnteropeからBarracudaになった件は、普通のアプリケーションエンジニアが意識するのって絵文字対応などのときだと思っていて、これにより各々の my.cnfinnodb_file_format = Barracuda を書く必要がなくなった
    • 関連して innodb_large_prefix も5.7デフォルトで1になっており絵文字対応がデフォルトで対応されている?
  • デフォルト行フォーマット innodb_default_row_formatdynamic になった件は、ちょっとまだ肌感としてはよくわかってなくて、 圧縮される(のでストレージ負荷が下がる)代わりにCPU負荷が上がるCompact( or Compressed)を採用するか否かの話になると思うんだけど、CPU負荷というのがどれくらいのものなのかわからないのと、もはや近頃はストレージ価格というのはどんどん下がっているのでリスク犯すなら思考停止して dynamic でいいじゃん、と思ってるんだけどどうなんでしょう

日本語の全文検索に関しては結構読み飛ばした(mysql内で形態素解析等するケースが思いつかなかった)

柔軟で安全なレプリケーション

この章がもう結構衝撃的で、正直前職では master_log_file , master_log_pos めっちゃ駆使してたし、 set global sql_slave_skip_counter=1 も手動で叩いていたので GTIDとクラッシュセーフスレーブすげーーという感想になった。

マルチソースレプリケーションに関しては、チャンネル単位で複数スレッドに並列化してスレイブを構築するほどスレイブ遅延が発生する状況を知らないので読み込んでみたけどあまり直近で使う未来は見えなかった。 むしろ

ただしチャンネルはお互いに独立しているため、チャ ンネル間の整合性は保証されません。すなわち、チャン ネル❶のマスタが更新されたあとにチャンネル❷のマス タが更新されたとしても、スレーブ上ではどちらが先に 更新されるか保証することはできない

等のコメントを読んで腰が引けたというかあまり使いたくない印象を持ってしまった。

設定における留意点と分析機能の利用

この章も「フムフム」と言って読んだ。SQLモードの変更やログのスタンプ形式の変更は読んで把握しておいてよかったなと思った。 とはいえ個人的にはDBは常にUTCでもいいんじゃないかとも思っているので(実際に前職はそういう運用をしていた)、頭にindexを作るに留める。

所感

どんどん最新機能出てきてそれを最前線で追っている方々、すげえみたいな小学生のような感想。 今までローカルのmysql5.6だったけど、手元の開発が落ち着いたタイミングで brew install mysql で5.7にあげよう。(今は brew install mysql56

サーバーエンジニアで少しでもDB(mysql)触る人は是非読みましょう

WEB+DB PRESS Vol.97

WEB+DB PRESS Vol.97

(pdfはgihyoから買える)

参考

www.slideshare.net

www.slideshare.net

nippondanji.blogspot.jp

yakst.com

yakst.com

Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠

MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.7 InnoDB 圧縮テーブル

4Kディスプレイ買った

家電 ガジェット

philipsの43インチ/4Kディスプレイ  BDM4350UC/11 を65000円くらいで買った。

買ったのはこれ

自分の部屋に作業環境を構築している最中で、机と椅子を買ったのでようやくサブディスプレイを買うに至った。

24インチとか、オフィスで普通に使っているようなものにしようかとも思った(2万あればソコソコの買えるし)けど、 机と椅子をけちったのでディスプレイくらいいいか、という甘えた考えで4Kディスプレイに手を出した。

当然24インチとか27インチあたりで妥協する選択肢もあったんだけど、

まず解像度。

27インチで4Kディスプレイ写すと文字小さすぎて読めないというレビューが多く。

さらに価格。27インチ帯で4K、まだまだ価格が高くて、

あたりも5-6万してしまう。24インチの4Kでない通常サイズのディスプレイ1枚というのは味気ないし、それなら6万5000円払って43インチ買っちゃおうぜっていう気持ちがあり勢いで買った。

40インチ以上の4Kディスプレイというと選択肢が多いわけではない。

他の選択肢としては

とか

、もしくは40インチ以上のTVをPCモニタに使うとTVも見れるしやすいという判断で

などかな、と考えていたが、

IPS液晶であること、RGBW(いわゆる偽/なんちゃって4K)でないこと、値段などを考慮して最終的にはphilipsのものにした。

今のところ不自由なく使えていて、でかい is 最高!といったところで幸福感が高い。

macbookpro 2016 lateユーザーの人の場合ケーブルには気をつけなくてはいけなくて、

apple純正のusb-c <-> displayport ケーブルでは画面を表示することができない。

この辺の罠に関しては

itstrike.biz

あたりで詳しく解説されているがケーブル単体の購入(変換器ではなく)の場合殆ど選択肢はなくて、

しか無いと思われる。

前者のほうが人気があったようだが、昨年のmacbookpro 2016特需で値段が2倍に跳ね上がり(昨年は2000円程度だった)、かつ送料もかかり、届くまで時間がかかるという点で敬遠し 自分は後者を購入した(displayportの場合1mしかないので注意)。

(ケーブルに4000円程度払うのすごい癪なんだけどHDMIだと30Hzのみ対応っぽく最高のパフォーマンス(4K/60Hz)のために仕方なく買った。)

届いた瞬間はでかすぎてびびった、

でもすぐ慣れた。 参考までに、自分が使っている机のサイズは奥行きx横は60x140で、本当はもっと奥行きあると嬉しいなーという感じ。

少し前まで10万-15万してた4Kディスプレイが、6万円で手に入る時代が来たのでどんどんハードルが下がってきている。

6万で最もQOLを上げるのにコスパの良い買い物だと思うので、特にプログラマーの皆さんは今すぐ買いましょう。

NAS環境整えた

ガジェット 家電

結構前なんだけど備忘録として。

NAS環境を整えた。

NASとは

NAS(Network Attached Storage)。ネットワーク上にストレージがあってネット経由でアクセスできる。

入れ物は選択肢が多々あったんだけど、コスパとエコシステム(Synlogyが出している専用のOSとかアプリとか)で選んだ。

  • NASに関してはド素人
  • 最悪消えても死なないけどそれなりに堅牢にデータ守って欲しい
  • 運用とかに力かけたくない。脳が停止しててもとりあえず動く

という温度感だったので、

  • RAID1(二本のHDDに同内容を書き込んでおいて一個HDDが死んでも復旧できるようにする)程度の冗長化にとどめた
  • 自分でconsoleからガツガツ拡張しないでできる拡張(ビューワアプリをインストールしてiPhoneから直にHDD上のpdf見れるようにするとか)
  • ある程度ディレクトリのアクセス権限を設定する

程度のことしかしてない。

また中身(HDD)に関しては、HD red を選択。 各色の特徴は

akiba-pc.watch.impress.co.jp

などが参考になる。

補足としては、容量単価では3TBが最もコスパが良い。 自分的には人生で集めた全てのファイルを足しても2TBで事足りるので2TB x2 を購入した。

Synlogyのweb UIが(ド素人には)親切で、webから一通りの操作ができる(もちろんOSはlinuxなのでconsoleであれやこれもできる)。

f:id:reizist:20170302032350p:plain

アプリも多々転がっていて、脳死していてもある程度できることの幅がある。

f:id:reizist:20170302032338p:plain

所感

とにかく導入コストが低く、RAIDも10分程度で組めたし何一つ苦労することなく運用できているので、エントリーとしては非常におすすめできる。

お金が余っていてNAS持っていないみなさんは買いましょう

小林銅蟲先生のブログでマルコフ連鎖

ruby

こんにちは。

漫画「めしにしましょう」が好きすぎて、

著者である小林銅蟲先生のブログ

negineesan.hatenablog.com

を漁り読む日々を過ごしています。

小林銅蟲先生っぽい」文章が面白くて文体を真似るファンが続出しているのを観測しており、人気の高さが伺えます。 まだ読んでいない人はめちゃくちゃおもしろいので今すぐ読みましょう。

さて、今日は朝7時に目覚めてしまったので、何を思ったかマルコフ連鎖で「小林銅蟲先生っぽい」文章を自動生成してみることにしました。 ※ブログ掲載にあたって小林銅蟲先生に許可を頂きました。

マルコフ連鎖とは

wikipedia を見てもさっぱりでした。

概要だけ把握する場合、

マルコフ連鎖を説明してみる。 | 分析のおはなし。

が参考になりました。 今回は要するに 「既存の文章を適当につぎはぎして自動で文章作る」のが目的です。

余談ですが、しゅうまい君もマルコフ連鎖で作られているようです。

準備

まず手始めにマルコフ連鎖に必要なデータを取得します。 パルスクレイピングして全てのブログ記事をtxtに落とし込みました。 (すべての記事からマルコフ連鎖するとそこそこ実行時間がかかったので最終的には取得記事を絞ってます)

これらの記事を1つのファイルに結合し、これを基データとしました。

また、マルコフ連鎖のために形態素解析を行います。これにはMeCabを使用しました。 rubyから使用する場合、 Nattoが便利です。

(macの場合)

brew install mecab mecab-ipadic
gem install natto
require 'natto'
 
text = '使用後はとても爽やか。'
 
mecab = Natto::MeCab.new('-Owakati')
p mecab.parse(text)
# => "使用 後 は とても 爽やか 。 \n"

以上が実行できれば環境はokです。 あとは以下のアルゴリズムに従って文章を作成します。

  1. 形態素解析を行い基データを単語に分割する
  2. 文章を複数語で構成されるprefix(接頭語句)と1語のsuffix(接尾語)に分割しテーブルを生成
  3. テーブルからprefixを選択し、prefixの後ろにつなげるsuffixをランダムに選択

結果

実行結果を並べてみます。

こんにちは。今回のイブニングのめしは新年一発目なので、なんかテフロン加工鍋的なものを食うことにしています。その他各種臓器も、消化器は開いて汚れを洗ってから茹でて、、冷水でも骨は確かにウッてなる。でもうまいのでOK。工夫を考えていきます。成敗ウーウオーウーオウッオいやーびっくりしすぎて、それどこでアンコウ鍋をやってみたところ、全然うまかった。ていうか生活が苦しい時代よりも明らかに良いものを使うと平和っぽく作ることがわかります。前回あとなんかマツコがマ文脈牡蠣ですはいだるかったのかと勉強になり、これ全体がコラーゲンじゃないのって感じで陳列があり、それは焼いたパンに乗せたらいい感じの肉があり、それについての補足を簡単にしているのか知らんけどいきなり茹でてみたく、さらに漫画も描けるから経費パワーも使えるという、デメリットが一切ない企画です。解体を丁寧にやると木っ端の骨が出てきます実際松茸と霜降り肉は1人200gを超えるとしにます翌日もだるまちゃん先生家では本命のあれを茹でましょうモリモリいきますはいまず肝臓を確保血管を割いて血を抜こうとしてくれろという取引がございます。白子はググったら高級っぽくて、アンコウらしいヒラヒラが映えますすっきりいわゆるちょうちん的な箇所は引っ張れば普通にクリアできるヒレに皮が残りがちだけどヒレから皮取ったら食うとこないだろ説もあるのでよーく茹でてますねおもむろに白子が出ていますエラには酢が到達して煮てもいいんだけど削ることに2500円を出すか?というとこういうことがわかってきます実際松茸と霜降り肉は合うと思う、別にテフロンじゃなくてゼスターグレーターでパルミジャーノを削っている状態でも骨は確かにウッてなる。でもうまいのでOK。工夫を考えていますねおもむろに白子が出ないので丸呑みした胃を裏返してよく洗いますなんだかんだで皮膚が破損する湯通ししたねびっくりしすぎて、こんなふざけたものでは甘すぎるので醤油を足して二番だしをとります。肉ですそれ以外です味変ガンガン混ぜることで大阪のイベントの帰りに高島屋今半で肉をかまぼこにしてからよく噛んで食ってうまいしなんなら吊るし切りもやっています結構でかい切ると中は超魔界村の4面みたいになって1.5kg買ったけど食ったらいけました。食感だけでここまで嗜好性がいまいちよくわからないものを洗い流していて、こんなふざけたものではこのように死ぬ思いをしています。幸いシーズン最後の出荷分をゲットできて、何のために口の中で水分がガンガン出るので水はなるべく少なめにところで肝はうまかった記憶がありとてもおいしい。その他各種臓器も、消化器は開いて汚れを洗っていましたねびっくりした胃を、そろそろ、、とにかくできました。10分だかガッツリ茹でるのでノロウイルスはしにますスーパー計量タイム配合は忘れたので速攻で帰りました。その足でマテガイ採集に向かったということです。文脈ですが、それはそれとして参戦します。エラです。金曜の朝8時に市場へ着くと観光目的の人間はいきなり死ぬ」について主に考えてみたらこれもまた別件で、小骨の激しい部位の肉がありますとれたまだ頬肉がガッツリシカトされたので、合理的なものがどろどろと溶けていきます。のでこれは大洗で揚がってかつ内臓が出ないので丸呑みしたね。
こんにちは。イブニングで2話掲載がよくあり(よくあるのです)、今回もなのかなこれ謎腸に黄色いクリームみたいなのですがショップ情報には酢が到達しています皮湯通し後の世界です身の迫力を楽しみたいのでグッと大ぶりにカット炊いていきますハサミの方が便利だったハローいろんなのがはっきりしました。ていうか生活が苦しい時代も忘れて、しかしアシに入る日がそこから7日くらいあったので、折角だから大洗に行くことになりました。口の中で世界になります。店もここ以外やってみたく、さらに漫画も描けるから経費パワーも使えるという、デメリットが一切ない企画です。一応ニンニクやショウガもおろせるらしい。つうことで煮えました。アンコウはうまいです。ポタージュっぽくもありかなこれ謎腸に黄色いクリームみたいなのがあります。その他各種臓器も、消化器は開いてくるところでウツボは小骨がいろいろ邪悪で、厚削り節と鴨のガラが冷凍庫にあったのでめしです1kg1万円ぐらいで存在しやがって、アンコウの初心者にわりと取り付く島がなくなったのでめしです1kgパワーモリモリ割くはい肉よくわかんないのでここでラクができますが10kg級になるのでフードプロセッサで粉砕します。一体どうすれば、、冷水でも骨は確かにウッてなる。でもうまいのでOK。工夫を考えてみましょうゆでた肝は固まりませんでしたが種類でいろいろあるんでしょう。胆嚢なのがいますはいはい人ん家を色んな角度から撮りますフムッ超時空バトル四の五の言わずぶちこみます以下、意味不明ですたぶん脾臓、味がとにかくきれいでうまいでは肉を外し終わったヒレを取りましょうモリモリいきます。やりました。実用的に硬質チーズや柑橘類を削りたい人間がどれくらいいるか」「人間はいきなり死ぬ」について主に考えています。これは固さとしては片はんぺんくらいで結構柔らかいのだから大洗に行くことに2500円を出すか?そんなことは特に気にして煮ます中華粥のニュアンスにするため、20分だか20分だか20分とかでぼちぼちじゃね?みたいになってほしい。年末最高。そんで年末の話です。よろしくお願いします。詳しくは各自読んでもらうとして、、冷水でも骨は確かにウッてなる。でもうまいのでOK。工夫を考えていき、お前こんなふざけたものが世界に存在しやがって、そういえばクセもなくうまかった記憶があり、これも仕事ですね。
こんにちは。ブログ的に崩壊します。血管ぜんぶ引っこ抜いて細かく切って針ごと収容する)、調理環境に持ち込んだ時点ではまだ生きてたので昆布を足して二番だしをとります。とてもぬめっている酢まんべんなく塗りたくるこの状態のアンコウはうまい。よかったですね。
色々なことをしなければ平気だと思って元気付けのために今日もめしを食ってよいものだろう」との差異はよくあり(一部地域で「人体を食べることにつきましてはこれで14リットルだったので、買う際に「この袋はたべられませんでした。ていうか卵は高いやつだと取り回しが微妙なったのでそれに直交させればよいという知見があり、醤油、オイスターソース、(酢)、片栗粉、で餡をぶっかけました。これは何が起こっている塩とごま油と塩でざっくり洗って濾してニンニンク、ショウガに漬けて放置します。これは急いでた牛です。600gくらいでしたが、昔の偉い人の歴史や思想的なものを選びました。よかったですね。
色々なことが予想された臓器があり、同じ肉ではないでしょう。ジャガイモを茹でます。うま界さてこの当時、ぶっちゃけあんまり変わらなかったことになり、タタキが鬼のようなこと、うまいです。同様にする人はやっていくことで告知が出ますね。
色々なことが出来ず、糊を食ってうまい。よかったですね。

所感

本家の面白さには至らず力不足を感じましたが、とはいえそこそこおもしろい文章が生成できて満足です。

今回は完全ランダムでしたが、マルコフテーブルを作成する際文節の出現頻度のスコアリングするなどすることでもっと「っぽい」文章が作れるかもしれません。

よかったですね。