JRDV.sp

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

開発

過去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倍の差が出ますね。

解決策

続きを読む

競馬新聞作ってる

サンプルです。
この形で出てくる事は無いと思う。

→ 作成過程

JRBの白黒の横版のPDF新聞、これが種類が多くて整理が必要。
一時期の勢いにまかせて乱立させて、以降10年ほど?そのままです。
僕がJRDBに入る前のものですね。
流石に…入っているデータも古いし、新規にJRDBに入ってから使う方も少ないかなと。
古くからJRDBをご利用頂いている方が、ずっと使い続けているのでしょう。

WindowsXPと同じて、何か手を加えるにはあまりにリリースしてからの時間が経ってしまいました。
個人的には、全部1から作り直してしまう方が長期的にはベターな方向。
ですがJRDBはそんなドラスティックな事が出来る会社でも無いです。
未だに最初期のHTML版の馬柱が毎週更新されているように、1回出したら無くせない方針。
故に、1つ新規のコンテンツを出す度に、トータルの作成時間がどんどん掛かるようになっていきます。

位置取りシートや「外厩」シート、データビューワにTarget用のデータパック。
これらはJRDB本体とは切り離して作成しているので、まだ新規の物が出せていますが、JRDB本体で新しい物は、ここ数年以上出せておりませんね。
と言う事で、リソースを確保するためにも古い新聞の種類を減らしたい。
似たような新聞をまとめると、例えばこんな形になるかな。

t1

「新パドック新聞」との比較で、A4にプリントしてみました。
実際に印刷して使うのであれば、現状の物だと小さすぎて厳しいです。
情報が少なくなる分、文字のサイズは今よりも大きくなりますね。
サンプルは14頭立て以下のレースでのものなので、15頭以上のバージョンは形が多少かわります。

でも・・・。
そもそも、予定では僕は作成しましせん。
新聞作成のための周辺ツールの作成までが僕の仕事範囲。
パーツの組み合わせだけで、誰でも(は、言い過ぎかも)新聞を作れるシステムを作成予定です。
コンセプトやデザインは別のスタッフが担当します。
上のサンプルも、こうやったら新聞が作れますよ、という説明のための物。
さて、どんな新聞を作ってくれるのでしょうね。


F12のススメ

もしブラウザでGoogleのChromeを使っているのであれば。
(いや、IEでもFire Foxでも同じなのですけれども)
たまには「F12」を押して見るのも良いかも知らん。

例えばよく見るレーシングポストさん。
各馬の成績画面がコレ。

t1

ここでF12キーを押すと、開発者ツール画面が開きます。
これで中身のHTMLが見られる。
ソースと言われるものですね。

上部にはjavascriptが埋め込まれており、「window.PRELOADED_STATE =」以下にはJSON形式で見えない部分のデータが入っております。
そこだけを抜き出してみると、このような構造。

t2

profile
entries
quotes
seasons

4項目ほど入っております。
・・・ん?
Quotesに関してはメンバー登録しないと見られない項目なはず。
ですが、ソースの中に埋め込まれてしまっております。
騎手・調教師のレース後のコメントがその内容。
現状では丸見えですが大丈夫かな?
もしかすると、このページはまだ開発途中なのかも知れません。

そして以下の部分

t3

この箇所にはReact が使われてます。
春の時点では確か違ったはず。
ちなみに、ReactはWordPressがライブラリの使用を止める方向に動きました。
Facebookの特許条項のリスクを嫌い、WordPressがReactライブラリの利用を止めることを発表

個人や中規模程度の企業であれば、多分あまり気にする必要は無いとは思いますが、嫌な材料である事は確かですね。

地方競馬サイト
単行本
外厩ブラックボックス馬券術

Target用ファイル
「外厩」データ
(無料分)
「外厩」印データ
Target用厩舎ランクCSVファイル
(JRDB会員専用)
Target用ファイル
ビューワ 5/19・20
土曜日
日曜日
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

没関係啊(*`ω´)



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



おいなりさん

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

  • ライブドアブログ