ラプラスと並ぶ激レアポケモンだったカビゴンだけど、最近のアップデートであちこちに出現するようになったっぽい。

カビゴンの放流が始まったか。

今までは10km卵で引くしかなくて、家人が10km卵からカビゴンを2体孵化していて、その引きの強さにびっくりしていた(10km卵のget率に加えてカビゴンやラプラスなどレアと言われるポケモンをさらっと引いている)

ところがP-GO SEARCHというサイトを眺めてみたら19日あたりからやたらカビゴンを見かけるようになった。街道沿いや住宅街といったところでポコポコ湧いている。

5時間ほどのあいだ、足は車の範囲で、カビゴンが9体も出現している(ここにはギリギリ写ってないものも入れて)

はっきりとした規則性はないけど、国道や県道を周回している印象。

そろそろこのへんに出るかな、と思ってたところ、徒歩圏内に狙いどおりカビゴンが出現。あっさり野生のカビゴン、というか野良カビゴンを捕獲することができた。

攻略サイトでカビゴンのレア度が見直しされてたのも、最近の出現率からすると当然か。

ただまあ、野良のカビゴンは「ポケモンを調べてもらう」と個体値的には期待できないし、それでもまだ他のポケモンと比べると出現率は低いだろうから強化のための飴が足りない。

…て、ここんとこポケモンGoネタが続いてるなあ。イイ歳こいて、こんなんで大丈夫なのか。

いや、メタボ対策とボケ防止のためのウォーキングネタだと思えばきっと大丈夫。ここ三ヶ月ほどで300キロ以上は歩いてるから、これでいいのだ。

卵カビゴンが欲しいので、頑張ってまだまだたくさん歩こう。おう!

[2016/09/27 01:05:09]

うひゃ。江戸川の向こう、千葉県市川市は同じような範囲内でカビゴンが12体も。こりゃカビゴン放流は確定だな。

Firefox41がようやく縦書きに対応したのでこれからは遠慮なく縦書きを使える、すばらしい、というネタの続き。

WEBブラウザでの縦書き表示のあるべき姿について。いや、横書きでいいというひとにとっては意味のないネタ。

縦書きの場合、テキストをそのままブロック要素に流し込むとスクロールとなる。

これはありえない。

・文字が切れるのをコントロールできない。

・ページは縦にスクロールして見てるのに、なんでここだけ横スクロール。

ということで、前回も書いたように、縦書きでは段組でレイアウトされるのが正しい。

(※どうやら今日時点、Firefoxは縦中横が効かないので「!?」がひっくり返っているけど、ChromeやSafari、IEは問題なし)

で、これがちょっと面倒くさい。

１段落に入る字数と行数によって、どこで次の段落に移動するのかを確認する必要がある。これはやっぱ面倒くさい。

スクリーンショットでいうと「家屋が」で段落が終了して、次の段落が「かしぐ」から始まるというのを判断して段落を分けなきゃいけない。

なもんで、字数行数改行をチェックして文字数を数えて段落単位でテキストを分割するスクリプトを書いた。

[10/02 11:22:44]追記

CSS3のmulti columnを使えばそのまま文字通り段組が実現できる。N字xN行ではなくて、画面幅やテキスト量で柔軟に表示してくれるので、webは本来このCSS3のマルチカラムを使うべき。

版面というかN字xN行のレイアウト表示で見せたい場合にこのスクリプトの出番(css3の完全リフローとは少し違って、N字xN行の箱に入る分のテキストの塊を作るイメージ)

ルビや縦中横に関しては、テキストにHTMLでタグづけされてれば生かす。

でも、わたしは素人のヘタレなので制約はあって。文字数を数えるために。

縦中横の指定のない半角の数字と、半角のアルファベットや記号類は全角に変換。

また、なんちゃって禁則でバグくさいところがある。

https://t2aki.doncha.net/tmp/dangumi-sample.pl

(例によってここは直リンクできないのでこちらからどうぞ)

↑ここでテキストや字詰め行数を入力すると、縦書き段組表示用に分割されたテキスト(縦書き用のスタイルシート付き)のHTMLが手に入ります。

テキトーにテキストを放り込んで試してみてください(わたしはこれで表示の調整をしてました)

縦(字詰め)、横(行数)を確認して縦書きサンプルとして、ブログなどにコピペしてご利用いただければ。

『創作文芸見本誌会場HappyReading』に登録した立ち読み用のテキストなど、ご自分のサイト、ブログで縦書き表示して読者さんに希求できると思います。

(※HTMLが編集登録できるブログ限定でしょうか)

小説は縦で読んでもらおうず！

[更新]2026-02-01 09:16:01

小説同人誌は売れない。まず手に取ってもらうことから、というのはよく言われること。

商業誌の場合は、新刊やフェアとして一斉に全国の書店に並ぶ・書店内にポスターやpopがある。「あ、これのことか」「さっきも見かけた」「へー、こんなのか」という共時性・共有力みたいなものが、本を手に取る大きなきっかけ。これを小説同人に求めるのは無理。せいぜい、ネット、自分のサイトやSNS、WEBサービスで告知するぐらい。それも当然ながら「現物が目の前にある」強さにはかなわない。

また、商業誌の場合は、版元のブランドもモノをいう「ここが出してるなら大丈夫」、雑誌で書評家という立ち位置の人間のオススメ「このひとの言ってたの面白かったなあ」という信用が、本を手に取るきっかけとなる。同人誌は、同じ趣味志向の人が、同じ立ち位置でやっているという意識がある。そこにブランド・権威を持ち込むのはそぐわない。オススメ系コンテンツも慎重に考えないといけないところだ。

ということで、妙案など浮かぶわけもなく（小説内容の充実・レベルアップは当然として）地味で地道に。

その１

・出られるイベントはすべて出る

・出るイベントには新刊を用意する

・次回出るイベントを自スペースで告知する

・自スペースのディスプレイはころころ変えず統一感を出す

・サイト持ちならそちらの告知もして、その２に繋げる

その２

・アマゾンや自家通販、ダウンロード販売等、イベント以外で入手する方法を用意する

・自サイトやSNS、WEBサービスでイベント参加情報を出していく

その３

・アンソロ参加などで名前の出る場所を増やす、ひとも巻き込む

・イベント内で企画を立てる・企画に乗る

具体的なディスプレイ、POPなどはともかく、やることはこんな感じかな。今さら言われなくても、んなこた100年も前からやっとるわ！というサークルもいるとは思うけど、やることもやらず目先の結果だけで、売れないと愚痴が目についたりするので、上目線の記事を仕立て上げてみた。

親戚のおっさんのようなまとめになるけど「継続は力なり」

[09/26 17:58:51] 追記

まずはサークル、著者の認知度をあげて（WEBに出回る胡散臭い用語でいうと）セルフブランディングに繋げるのが大切、ってことだなぁ。

↓わざとらしく宣伝も入れておくのが大人の流儀。今、審査に出してるiPhone電子書籍の目次

・小説同人誌Select 公開中

・iTunes Store はこちら→ http://itunes.apple.com/jp/app/id546230414?mt=8

ついこないだ、ちらっと書いたtwitterにメールで発言するスクリプトを。

ぐーぐる様詣でをすれば、すぐに出てくるネタで新鮮味もないんだけど、メールを受け取るところからの解説記事が少なかったんで、自分メモ。

前提としてメールサーバーはqmail。

HOMEにtwitter用のドットファイルを用意する。たとえば .qmail-mytwitter。中身はパイプでスクリプトに渡しているだけの1行。たとえばこんな感じ

| twitter.pl

送られてきたメールは、このtwitter.plが処理する。

twitterに投稿するにはユーザー名とパスワードが必要なので、データベースでもcsvファイルでもいいから、なにかに記録・登録しておく。このとき一緒に、投稿に使うケータイのメールアドレスも記録・登録する。

送られてきたメールをかまわずtwitterに投稿するわけにはいかない。まずは誰から送られてきたメールなのかを判定する必要がある。

my ( $emailaddr ) = $ENV{’RPLINE’} =~ /\<([^\>]+)\>/；

qmailの環境変数 RPLINE は return path （ほぼ送信元のメールアドレスのこと）が入るので、これを使う、てのがキモ。こいつを見て、登録されているメールアドレスなら、そのユーザー名とパスワードを使って、twitterに投稿する。登録されていないメールアドレスだったら、なにもしない。

送り先のメールアドレスがバレても、returnpathのチェックが入る。returnpathを偽装されても登録されているメールアドレスでチェックをする。エラーの場合は何も返さず沈黙する。

てことで、なりすましや何かの踏み台に使われることも、ない、ハズ。セキュリティ的に問題になりそうなのはパスワードを平文で保存しているところ。でも、twitterそのものが認証はBasic認証だし、jsonpでAPIを使ってるひとのソースをみるとJavascriptにユーザー名とパスワードを書くことになっているのが目につく（＝パスワード丸見え）

てことで、ここは目をつぶってtwitterだけにしか使わないパスワードにする・定期的にパスワードを変えることでカバーしよう。DBにしろcsvにしろ、ウチのポンコツサーバーから持ち出される、なんてことはほぼ考えられないし。

後は、誰が書いても、どんな環境でも、ほぼ同じスクリプト。

↓こんなでメールを解析して

sub parse_mail{
  my $self = shift；
  my $mparse = new MIME::Parser；
  $mparse->output_to_core(1)；
  my $entity = $mparse->parse( \*STDIN )；
  return {
    charset=>$entity->head->mime_attr(’Content-Type.charset’)，
    body=>$entity->bodyhandle->as_string
    }；
}

メール本文と文字コードを取り出して

↓こんなでtwitterにPOSTする

sub post2twitter{
  my $self   = shift；
  my $twt    = shift；
  my $message = shift；
  return -1 if length($message) > 140；
  return -1 if ! $twt；
  my $uri = $self->{twitter} . $self->{update}；
  my $req = HTTP::Request->new( POST=>$uri )；
  $req->authorization_basic( $twt->{user}， $twt->{pass} )；
  $req->content( "status=" . $self->html_encode($message) )；
  my $ua = LWP::UserAgent->new( agent => $self->{ua}， keepalive => 4 )；
  my $res = $ua->request( $req )；
  my $stat = $res->status_line；
  return $res->is_success ? 0 : $stat；
}

メッセージが140文字以上だったらなにもしない。

ケータイのメールアドレスから取り出したユーザー名とパスワードを$twtに渡すのでそれを使ってtwitterのBasic認証をする。

メッセージ本体はhtmlエンコードをする。

POSTで投稿する。

というだけの手抜きなシロモノ。

twitterみたいな気楽な巨大チャットにはモバイルは最適、だと思う。ケータイで使えるモバツイッターや、iPhoneなどのスマートフォン向けのアプリが充実してるのも当然。わたしの場合はauで、パケットのコースのこともあるので、メールで投稿できたほうがいいかな、と。

ケータイで見るのをどうしようか検討中。とりあえず、ezwebで見るようにスクリプトを書いたんだけど、なんかビミョー。それなら、空メールを送ったら返信で最新のつぶやき20個とかメールで返してもらうのも、あり、かなと。こっち側はまだ試行錯誤、だ。

節操なくねえちゃんと寝ちゃうし、料理はいちいち解説つきだし、ケンカは負けない腕っぷしだし、しゃべると必ず無駄口叩いてるし、改めて読むとロクでもないんだけど、相変わらず快哉なタフガイで、ニヤニヤしてしまうじゃないか、ちくしょう。

「わかったわ。でも、わたしたちのことを笑わないで。わたしたちは、あくまで真剣だし、絶対に正しいんだから」

「そう、おれの知ってる連中はみんなそうだ」