無題
とりあえず、SQLiteの端数処理のページ、整数も扱ってみることにします。
他にも正の数に限った簡易版とかもやってみたいですが、とりあえずこれからは少しずつネタを小出しにしていこうかと。
プログラミング関係の話題。プログラミングコーナーを更新したとか、プログラミングの内容に踏み込んだ話とか。
とりあえず、SQLiteの端数処理のページ、整数も扱ってみることにします。
他にも正の数に限った簡易版とかもやってみたいですが、とりあえずこれからは少しずつネタを小出しにしていこうかと。
というわけで、小数の整数への丸めだけですが、書いてみました。
しかし、それだけとはいえ、負の数の扱いや、.5をどちらに丸めるかなど、色々と充実した記事になりました。
とはいえ、ものによっては常用に堪え難いほどクエリが長くなったり、実数型を前提にしているなど、あまり使い勝手の良いものとは言えない印象があります。
よく使われる0以上の範囲に限って正しく動くシンプルなクエリや、整数をより大きな位の整数に丸める方法など、まだまだ話を広げようと思えば広げられそうです。
先日のアンパンマンDB3の機能実現のため、数の切り上げをやろうとしたのですが、SQLiteには四捨五入の関数しか用意されていないため、クエリを工夫して切り上げを実現していました。
切り捨て・切り上げがないのは実に不便ですが、逆に言えば、こういうところが私の工夫の見せ所ということにもなります。
プログラミングコーナーに結構充実した記事が書けそうなのです。
プログラミングコーナーで公開していた「FilesizeFormat」クラスをダウンロードコーナーで改めて公開しました。
プログラミングのサンプルというよりは、そのままプロジェクトに組み込んで使うほうが便利なものだったので。
これまでずっとsmartyではバージョン2の記法で書いてきたのですが、実はうちで使っているのはバージョン3だったのでもっと書きやすい気泡があったのでした。
foreachとかずっと{foreach from=$array item=value}なんてことやってましたよ。
バージョン3では{foreach $array as $value}というPHPに近い表記も可能なのです。
とりあえず見つけ次第新しい表記に直していこうと思います。
プログラミングコーナーの当たり判定補助クラスにミスがあったので修正しました。
報告してくださったtetさんに感謝します。
アンパンマンDBは、登録するデータの重複を一部省略してデータサイズを削減したり、リンク機能無しのリスト表示など。
自動リンクを入れると結構骨が折れるのですが、それさえなければただの単純なサブクエリなのです。
アンパンマンDB3のデータベース管理クラスを検索機能のクラスと編集機能のクラスに分割しました。
現状のアンパンマンDB2のように何でもかんでも1箇所に集約しすぎてソースがごちゃごちゃしてきたのと、ユーザー側のページでも呼び出していないだけで編集機能そのものは動く状態で存在していたのが理由としてあります。
編集機能は結構大きいので、ユーザー側のページでは絶対使わない編集機能を読み込むのも無駄な話だし、もし万が一間違えて編集機能を呼び出すコードなんて書いてしまったら大変です。実際紛らわしい内容のメソッドもありますし。
あと、SearchPhraseParserを微妙に更新しました。
本体の動作が変わらないほど本当に微妙な変更ですが。
ただ、オプション項目を追加する程度のことはできたかなーって気がします。
アンパンマンDB3のトップページを作成中。
50音順もバージョン2よりパワーアップさせています。
あと、プログラミングのページも更新しました。
最近必要があって作ったBOM検索のプログラムです。
カービィWii、本当の100%クリアしました。
本編は、ですが…。
あとは夢の対決のあの人と戦うことになるあのモードが……
アンパンマンDB3のカテゴリは元々の入れ子集合モデルのままで行くことにしました。
書き換えの手間やデータ量の点で経路列挙モデルが不利というのももちろんですが、入れ子集合モデルには入れ子の表現に遣う値がそのまま並び順にもなっているという利点があったのでこちらを選びました。
プログラミングのページ更新しました。
ファイルサイズを文字列に変換するFormatProviderです。
サンプル的なものなので色々抜けていますが、もうちょっと調整すればちゃんとしたものとしていろんな面で使えるようになりそうです。
文字列の左側共通部分を取り出すプログラムを以前作ったので、今日は右側を作ってみました。
まあ、割と簡単な内容でした。
あと、カービィWii、あっち方面もクリアしました。
ふわふわふにゃの開発はGitの練習も兼ねてやっていこうと思っています。
Gitはブランチ(開発の分岐)を作ったり統合したりするのが得意なので、メインブランチと新機能ブランチとバグフィックスブランチに分けて開発いくこともできそうです。
そうすれば、新機能が未完成なせいでバグフィックス版が公開できないなんて悲劇も防げそうです。
すなわち、バグフィックスのアップデートは頻繁に行いつつ、裏ではじっくりと新機能の開発もしていけるわけです。
今はまだGitの使い方がよくわかっていないので、失敗してもダメージの少ないこのふわふわふにゃでGitの練習もしていこうと思います。
enchant.jsを使ってJavaScriptでふわふわふにゃを作ろうかと思っています。
JavaScriptは以前と比べると劇的に速くなったとはいえ、まだまだ本格的なゲームを動かせるほどではなさそうなので、こういったミニゲーム類から攻めていこうかと。
マウス新しいの買いました。
クリックが効かなくなるのは嫌なので今回は耐久性重視で選びました。
中央ボタンのクリック感がいまひとつなほかは割といい感じです。
AmazonAWS、うまくいきました。
ただの検索ですが、ちゃんと認証も通って結果が返ってきました。
あとはこれをどう組み込むかといったところですね。
8月に言っていたレーダーチャート、アップしました。
サンプルはアキヤメのプログラムをちょっといじって作りました。
個人的な話ですが、Gitの改行の扱いちょっと変更しました。
CRLFを自動変換しているとGithub上にはVisualStudioでそのまま読めないVisualStudioのプロジェクトが存在することになってまずいので、改行コードをそのまま維持するようにしました。
そうすると今度はUNIX系のOSで動かすCGI系統で困りますが、いまどきちょっと気の利いたソフトなら改行コードが違っても読み込んでくれるし、こちら側で編集段階からLFで改行していてもいいわけです。
AmazonAWSの認証について調査中。
一応何かライブラリを使えば簡単にできないこともなさそうなのですが、認証周りのことを一度よく理解しておいたほうがよさそうな気がしたので自分で実装してみることにしました。
アンパンマンDBの商品情報の更新の一助にしようと考えています。
SPDYなんて技術が開発中らしいですね。
HTTPを高速化するとかなんとか。
Googleが開発中のようです。
ブラウザの開発元でありサーバーの提供元でありネットワークに情報を流すことで利益を上げている企業だからこそ、ブラウザとサーバーの両方の対応が必要でネットワークの通信に大きく関わるようなことに着手できるんでしょうね。
おそらくPHPとかでプログラムを組んでいる私のようなものには直接的には絡んでこない事象でしょうが。
AmazonのProduct Advertising APIを調べているけどいまだによくわかりません。
署名が必要だとかなんだとか。
とにかくまずサンプルが動かないです。
group_concatをあっさり実装したので、プログラミングコーナーにあっさりと書いておきました。
昨日書いたコードに対して、バージョンチェックを入れています。
AmazonのProduct Advertising APIに登録してみたけど、いまいちよくわからんです。
XMLで何か作ってリクエストすれば何か返ってくるらしいですが、それ以前のところでわからなくなっています。
以前言っていたgroup_concatの件、あっさり実装できました。
ローカルサーバーと公開用サーバーでSQLiteのバージョンが違っていますがそのあたりも含めてさらっと書けました。
コンマ以外で区切れませんが、自分用なので気にしないことにしましょう。
参考までに、ソースです。
$step_func = create_function('&$context, $rownumber, $string', 'if (isset($string)) { if (isset($context)) $context .= \',\'; $context .= $string; } return $context;');
$finalize_func = create_function('&$context, $rownumber', 'return $context;');
$this->db->sqliteCreateAggregate('group_concat', $step_func, $finalize_func);
レーダーチャートのプログラム、汎用的な部分とTGWS独自の部分に切り分けています。
こうすればメンテナンスもしやすいし、汎用的な部分だけ配布するということもできるわけです。