JRDV.sp

JRDBからJRDVがスピンオフして、しかもいいとこ取りのブログ。

開発

ハイブリッド競馬新聞 印一覧を作りました

トップ画面
t2

「印一覧」をクリック。
現在は最新分のみです。
バックナンバー、成績を入れてのレース後更新は今後の予定。
画面はこのように。

t1

上部に書いてある通りのデータです。
新聞と違うのは「前半・後半」を印にして6頭まで出力した事くらい。

目的は?

このビューは純粋に印だけに絞りました。
騎手も厩舎も斤量も無し。
これで1から予想をする、という為の物ではありません。
「眺めるための」データ。
なのでこれ単体での使用も想定しておりません。
右手にはハイブリッド競馬新聞、もしくは専門紙やスポーツ新聞で馬柱があるものを。
左手にはスマホ等でこの画面。
基本は2つで1つだと思う。

競馬新聞という体裁だけでは見落としてしまう馬も、この印だけの画面では何かしら引っ掛かってくれる。
その効果は大きいはず。

そもそも、考え始める前にザッと12R分一気に頭に入れらる事も大きいです。
印がバラバラなレースで変な馬を狙うのが好きな方も、逆に、印がまとまっているレースが好きな方も、短時間でレース自体をみつけられます。
スマホの縦スクロール機能は、相当に偉大ですね。
これはホイールスピンのマウス+PCでも感覚的に負ける部分。
このスクロールの為だけに作ったと言っても良いくらいです。
画面の上部タップで一気に先頭まで戻れるって、当たり前に使っていますが…考えた人は天才すぎですよね。

前日予想の段階では、ただただサブの要素としてお使い下さい。
そして当日。

個人的には3連複の3列目の馬を拾うに使っています。
あるいは、考えた上で消した馬の復活用。
騎手やら成績やらで消した馬でも、印だけ見ると「んー、来ちゃいそう」ってなる事は多いはず。
で、実際に来る事も多々アリ。

もう少し積極的に使うなら、中位人気辺りの印が厚い馬の評価をこれで上げる。
馬単で2着付けの馬券の時に、これで1着馬が抜ける事は少なくなります。
来たら結構跳ねるしね。

あまり考えずに拾う。
その為に使うデータという面も考えて作りました。

とりあえず「眺めて」みて下さいな。

HTMLテーブルのソート

たまには競馬から少し遠い記事でも。
僕が使っている方法です。
例えば、さっき実装したコレですね。
Twitterに途中のアップしていたので、その続きをやっておきました。

吉村智洋騎手成績

規模が小さく、コードも短い簡単なのであれば、こんな方法もありますよ。という紹介。
ざっとGoogleで検索するとライブラリ使った方法も多くありますが、そこまででも無い普通のやつです。
ガチでコードを説明はここ向きでは無いし、雰囲気だけでも…。
使うのは普通のjQueryと、あれば便利なjQuery.tmpl.jsだけで充分。
今はtmpl.jsの次期ライブラリもありますが、僕はテンプレート側では何もしないので問題無し。

JSONからのデータを加工

主に表示するとき用のカスタマイズですね。

t1

これには$.extendを使用。
上記だと$.extend(d,{})の箇所です。
日付8桁から、18-6/1のようにやってたりします。
これをテンプレート側で行う方法もあるのだけれども、全部jsファイル内ですべきと僕は思う。
基のデータ+拡張分を1つのオブジェクトとして用意する。

DOMを作って、その生の参照を得る

続きを読む

過去3走以内通過順

あたまファンタジックからの逆輸入

引き続き、とりあえず出しておきます。
昨日の分だと地方成績とか余計な物が混じっていたので、今回は3走以内でJRAオンリーのデータ。

芝はコース替わり、ダートは前有利な馬場とい傾向もあって、左から2列目、特に入っている頭数がすくない左端の馬の好走が目立ちました。
明日もそれっぽいレースはぽつぽつありますね。

4月1日

R逃げ3・4角3位内4角8位内4角9以降×逃げ×3・4角6位内
中山1R 1800②⑫⑦⑫
中山2R 1200⑬⑭②④⑥⑨⑩⑯
中山3R 1600④⑥⑫
中山4R 2880①②①⑪③④⑤⑥⑪
中山5R 1800①⑨⑮③⑩②⑥
中山6R 1600①⑨⑩②④⑮④⑤⑦⑧⑫⑯①②⑥⑩⑬⑭⑮
中山7R 1800⑦⑬②⑨①⑤⑧⑪⑬
中山8R 2000⑤⑨⑫⑬②⑤⑥⑦⑧⑨⑩⑪
中山9R 2500②④⑨①②④⑦⑩⑪③⑧⑨⑩⑪⑬
中山10R 1800①②④⑦⑨①⑤⑥⑧
中山11R 1200⑤⑦⑩⑫①④⑦⑩⑦⑨⑫④⑪⑭
中山12R 1200②③⑥⑦④⑫⑮①⑨⑫②⑤⑦②④⑤
阪神1R 1800②⑤③④
阪神2R 1400⑤⑯②⑦②④⑧
阪神3R 2000①④⑥⑨⑭
阪神4R 1600③⑥⑨⑪⑫⑤⑰
阪神5R 1200②④⑤⑨⑬⑤⑦⑨⑫⑮⑦⑨②⑪⑭⑮④⑥⑩⑬⑭⑮
阪神6R 1800④⑫④⑤⑥⑫③⑤②⑨⑩⑪
阪神7R 1200⑤⑯①⑥⑨⑭③⑤⑦
阪神8R 1200③④⑮②⑤⑩⑭①⑤⑯②③⑧⑭⑮
阪神9R 2000⑥⑧①④①⑧
阪神10R 2400③④⑨①②④⑤⑥⑦⑪②③④⑥
阪神11R 2000⑩⑫①⑨⑪⑭⑮①②④⑧⑮⑯⑤⑥⑦③⑫⑭
阪神12R 1400②④⑥⑪①③④⑦⑨⑪⑫⑭⑮⑥⑧⑤⑫⑬

あたまファンタジックからの逆輸入

あたまファンタジック
で発行している地方競馬用のマキシマム競馬新聞。
その上部にある「過去3走以内通過順」。
新聞の見方

これをJRAでやってみました。
区切りの条件は少し変えており、地方競馬は3走以内+「5着」以内だったのが「3着」以内と幅を狭めております。
右端の2列は「×」が付いているように、4着以降からの馬。

もちろん、地方ほどにはJRAは単純ではありません。
これだけで全てが上手く行くなんて美味しい話でも無し。
だけれども、あたまの整理には使えるし、最終的に迷った際の決め手にもなるかとは思う。
もっと条件別に細かく設定したら良さそうな感はありますが、しばらくはこれで様子を見ながら進めて行こうかなと。

もし自分で物事を考える事が出来る方であれば、プロトタイプのコレではありますが使ってみて下さい。
全部解説・説明つきじゃないと考えられないという方は、数ヶ月ほどお待ちを。
何か探します。

3月31日

R逃げ3・4角3位内4角8位内4角9以降×逃げ×3・4角6位内
中山1R 1200①⑤⑨①⑪⑫⑯
中山2R 1800⑫⑭③⑩⑪⑮
中山3R 1200①⑨①②⑦⑬⑤⑥⑬⑯
中山4R 1800④⑬②③⑩
中山5R 2000⑤⑪⑯⑧⑱
中山6R 1200③⑤⑥⑨⑪⑫⑬⑭④⑫⑯①②⑧⑩⑬⑭⑥⑮
中山7R 1800
中山8R 1200⑪⑭⑧⑨⑫⑬⑭⑯①②⑥⑦⑭④⑥⑦⑩⑯
中山9R 2200②⑤⑨①④⑤⑩①③④⑥⑦⑧⑨⑩⑪②⑤
中山10R 1200①⑧①③④⑦①⑧②⑥⑦⑫
中山11R 1600②⑥⑧⑬⑭①②④⑦⑨⑪①⑦⑨⑫⑮②⑧⑬⑭⑯③④⑤⑥⑩⑭
中山12R 2400③④⑨⑪⑬③⑦⑨⑫⑬①⑤⑦⑨⑩
阪神1R 1800④⑥⑧⑨
阪神2R 1200⑩⑭
阪神3R 1800④⑧⑫⑭
阪神4R 2000⑧⑨⑭
阪神5R 1800②⑦⑨②③④⑥①④⑩⑪⑫
阪神6R 2000①③①⑩⑪
阪神7R 1200⑤⑩⑥⑦②④⑥⑫⑮
阪神8R 3140①②④⑧⑨④⑥⑨②③⑤⑦⑧
阪神9R 2400①⑤⑧①③⑧②③④③④⑥
阪神10R 1400②⑧⑩⑨⑪①⑥⑧②④⑤⑥⑩
阪神11R 1400③⑥⑩⑧⑨⑮⑤⑧⑨⑭③⑮①⑥
阪神12R 1800⑤⑩⑫①②④⑤⑦⑧⑨⑭⑯⑩⑮③⑫

大阪杯

R逃げ3・4角3位内4角8位内4角9以降×逃げ×3・4角6位内
阪神11R 2000⑩⑫①⑨⑪⑭⑮①②④⑧⑮⑯⑤⑥⑦③⑫⑭

先週分は以下に。
続きを読む

デメリットが読めん

今回新たにAzure上にSQLserverを立てました。
これまでいくつか作ってきたのですが、全て僕個人が使う範囲での物。
しかしながら今度のは僕以外の人が使用するので、色々とややこしくなったのでメモを。

普段SQLserverを扱う時には、便利なManagement Studioを使っています。
データを入れる時には自分のプログラム経由。
つまり殆ど直でのやりとり。

が、今回はフロントエンドがAccess。
リンクテーブル経由での運用になります。
そうなると、文字コード関連で悩むはめになるんですよ。

データベース作成時に何も指定しなければデフォルトの文字コードは「SQL_Latin1_General_CP1_CI_AS」になるはず。
Accessにてリンクテーブルをアチコチ繋ぎまくっていると文字化けの温床になる可能性大。
現状ODBC経由でSQLserver、その他データベース、他のAccessとカオスな構造になっており、なるべくならトラブルは減らしておきたい。
しかもこの文字コードだと日本語を扱う時にはNプレフィックスを使う必要もあって手間だったりします。

このように。

t2

もしNがついていないと、Where文にはヒットしません。
他の人が使う事を考えると出来るだけこれは避けたいなと。
なので初めてこの文字コードを使う事にしてみた。
Japanese_Bushu_Kakusu_100_CI_AS
Collation and Unicode Support

これであればNプレフィックスは不要になる。

t5

(ちなみに、1つめは佐賀競馬場のレースで、下段のはJRAのレース)

Accessでもインサート他で文字化けも起こらない。
でもね。
「補助文字 (_SC) を含む照合順序を使用しているデータベースでは、 SQL Server レプリケーションを有効にすることはできません。」
という注意書きもあります。
あるのだけれどもAzureでレプリケーションを設定したら、出来てしまいました。
・・・よく分からん。
2017以降では解決されたとかでしょうか。

他にもtext型等の制約はチョイチョイあります。
それでもまだこの文字コードの方がメリットが大きい。
どんな落とし穴があるのか?もっとテストしないと見えてこないのかも。
6時間ほどアレコレとテストをしてみて今のところ問題ナシです。
このまま進めてしいいのか迷うなあ。

データを移行して料金の節約になるかな

まあ、やってみよう。
何を?って話ですよね。

現在は、騎手・厩舎・「外厩」の詳細データはAzureのWEBサービスから取得しております。
サービスを立ち上げて、そこにディレクトリを作成して、ファイルを置いている状態。
そもそも、ここにファイルを置く事自体が緊急措置でした。
一時期、このブログ自体にすら接続出来なかった事があった、あの時にとりあえずの移行先として置いていた場所。
でもね、ここからファイルを配信すると無駄にコストが掛かるんよ。

t4

7,083円の殆どがそのデータの転送量。
しかもいまだに自腹だったりします。
ちなみに、下の2つはSQLserverの料金。

地方競馬の新聞をBlobストレージで管理してみたら意外と安かったので、ただのファイル配信は全てここで良さそうです。

t3

今回は途中からの使用で配信数は少ないものの、1つのファイルは0.8Mバイトほど。
各種データ一覧で扱うファイルは凄く小さいファイルなので、やはり料金的は安くなるんじゃなかろうか?と。

ライブドアブログのFile Manager API

File Manager API について

を使ってみようかと。
会社ではwindowsなので、お試しするならPowerShellですよね。
便利なInvoke-RestMethodもあるし。

最初にファイルのリストを取得してみた。
ちょっとC#っぽくやるとこうかな。

(Invoke-RestMethod -Uri "https://livedoor.blogcms.jp/blog/*****/file_manager/list"`
  -Headers @{"X-LDBlog-Token"="*****"} -Body @{"dir_id"="112770"} -Method Post`
 ).lists.Where({$PSItem.name.Contains("gk")}).ForEach({$PSItem.name})

これで指定したフォルダにある「gk」を含むファイルを表示してくれます。
なるほど。
では次にアップロードを。

$body = @{dir_id = "112770";filename = "aaa.txt"; upload_data="aaa.txt"}
Invoke-RestMethod  -Uri "https://livedoor.blogcms.jp/blog/*****/file_manager/upload"`
 -Headers @{"X-LDBlog-Token"="*****"}`
 -Body $body -Method Post 

「{@{msg=アップロードするファイルが指定されていません。}} fail 」
というエラーメッセージ。
PowerShellでの書き方が間違っているのかな?と、これでも出来ますよと書いてあった「Postman」で試して見ても同じエラーが返ってきちゃう。

誰かFile Manager API使って上手く行っている方いませんかね?

頭数と馬番で枠番を出す

と、わざわざ計算して枠番を出す機会も普通は無いと思います。
1番手っ取り早いのは対応表をデータベースに入れておく、でしょうか。
JRAだと17頭以上になった時には1つの枠に3頭のような特殊パターンがありますね。
こんなのは7・8枠の2パターンだけなので例外的に処理してしまってもOKかなと。
ネット上では数列やら数式なんかも既にあります。

今回必要になったのは、香港の新聞で使ってみようと思ったから。
馬番とゲート番号が違うので、ゲート番号に日本と同じような枠の色を入れたらもっと直感的かな?と思ってん。

香港だと最大14頭。
上記のような特殊パターンもありません。
なので実装は簡単。
チラッと検索してみると、VBAやらで実装されている方法が上位に来ますね。
MOD(余り計算)が入ってたりするけれども、今回は必要ナシです。
C#で書くとこんな。

t2

続きを読む

Visual StudioでAzureのSQL Serverが開けない時

自分用のメモです。
このブログの99.9%の方には全く関係無いです。
解決はしてません。でも別の方法でも特に問題無しでした。

Visual Studio上からAzureのSQL Serverに接続する時は、普通だとSQL Serverオブジェクトエクスプローラーからクリックして開いてきますよね。

t1

僕はいくつかAzure上にSQL Serverのインスタンスがありまして、例えば上の例だと「NAR」はデータベース名が表示されているように普通に接続出来ております。
でも「HKJC」の方は赤線の箇所に本来表示されるべきDB名が表れず。

ちゃんと調べた訳では無いのだけれども、多分、原因はコレ。

t2

DBの照合順序がこれだけ「Japanease_CI_AS」に変更されていました。
記憶に無いけど…デフォルトとは違いますね。
標準では「SQL_Latin1_General_CP1_CI_AS」となっているはず。

んー、Visual Studioが2015だからダメなのかな?と、せっかくなので2017を入れてみたものの…結果は変わらず。
以前は普通に繋げていたはずなのに謎です。
回避策としては、通常のDB接続と同じく「サーバーエクスプローラー」を使います。
ここで設定を入力すると。

t3

デキター。
さて、これで後はテンプレートにデータを流し込んでいくだけ。

t4

イラストレーター2018は2017に比べて約2倍ほど遅い

少し前にアップデートがあったillustrator2018。
うっかりアップデートしてしまった方は、ご愁傷様です。
僕も2台のPCの内(1アカウント2台までインストール・使用可能)1つを2018にしました。
もちろん使い方にもよりますが、僕の作業では2つのバージョンの処理速度は約2倍の差が出てしまいました。

t2

t1

1ファイルA3サイズで約3M程。
JavaScriptでJsonファイルを読み込み新聞作成という作業内容。
それを一度PDFのプリンタドライバを通した物が園田競馬場用の新聞となります。
コチラ

1つめのファイル作成完了後から最後のファイルまで、タイムスタンプでの比較ですと2018は7分、2017だと3分となっております。
2018が今後のアップデートで以前の処理速度に戻るのか?もっと遅くなるのかは分かりません。
そもそもAdobeの製品自体が、CPUとメモリの使い方が非常に悪い。
なので多分、改善はされないでしょうね。
ちなみに、2017よりももっと速いのはCS5。
普通にはもう手に入らないのだけれども、競馬新聞を作成するには最適なバージョンです。
2017よりも約8倍ほど速いので、単純に2018との比較だと16倍の差が出ますね。

解決策

続きを読む
地方競馬サイト
単行本
「枠順」と「位置取り」で勝ち馬を見抜く!


外厩ブラックボックス馬券術

Target用ファイル
「外厩」データ
(無料分)
「外厩」印データ
Target用厩舎ランクCSVファイル
(JRDB会員専用)
Target用ファイル
ビューワ 11/17・18
土曜日
日曜日
PV: 位置取りビューワ
DV: DV3
mini: JRDV-mini

過去分
2017年 2016年 2015年
記事検索
中の人
当ブログでの「僕」または、一人称は全て飯村公一@JRDBシステム班です。
JRDVを含めWEBアプリ系の開発担当者。
僕直通のメアドです。
iimura.sp半角アットマークgmail.com
半角アットマークを「@」に変えて入力して下さい。

Twitter:@jrdvsp
FaceBook:飯村 公一

こちらでもコンタクトできます。
Live レース結果
最新コメント
サイトへのリンク
【JRDV.SP】のサイトはリンクフリーです。
リンクしていただける場合は、以下のバナーをご利用ください。
コメント欄にでもご連絡頂ければ、このブログでも紹介させて頂きます。


http://blog.jrdvsp.com/



競馬リンク
必要な物はここで全部揃います


JRDBブログの1st


僕の席のとなりにいる人


新感覚


1回にご馳走になる食事
≒僕の1ヶ月分の食費


競馬情報ポータルサイト。


SMARTKEIBA


ストライド競馬新聞




競馬ビッグデータ




相互リンク

逆転競馬

大阪梅田競馬BAR
『そのままっ!!』



チョットだけ競馬を。

The Lion Sleeps Tonight

没関係啊(*`ω´)



大きい馬券好きの競馬予想



おいなりさん

「競馬」と「料理」と「愛犬」と

  • ライブドアブログ