Gmailを簡易HTML表示にしたらものすごく快適になりました。
とにかく余計なことをしない。
クリックしたとおりに動いてくれます。
そもそもGmailの最大の売りは検索機能と迷惑メールフィルタであり、それらは先進的な表示でなくても何の問題もなく使えるものなのです。
やっぱりWebアプリというのはネイティブアプリと比べて制約が多くて、ネイティブアプリの真似事をしようとするとトリッキーな実装に頼らざるを得なくなって、使い勝手が悪くなってしまいがちなのです。
そうなると結局、原点に返ってWebページとして動くのが最もシンプルで使いやすいということになるのです。
昨日のヤブクロンに続き、ミノマダムの絵を描きました。
こっちは特に戦いっぷりとかそういうのはなく、ただ描きました。
まあ、攻撃はいい感じでした。
PDWで新しいポケモンが出るようになってレベルの低いポケモンを育てる機会がまた増えてきました。
そんな中、とてもすばらしい戦いっぷりを見せてくれた野性のヤブクロンに出会ったので、オレと名付けて新しい仲間に迎え入れました。
その愛らしい姿をここにスケッチしておきます。
アンパンマンDBバージョン3開発中。
Smartyのインストールに手間取っています。
公式のサンプルが古いPHP用だったりクラスのオートロードがうちで設定しているものと衝突したり、簡単そうに見えてなかなかうまくいかないものです。
タイトルジェネレータをTwitter対応にしました。
いつの間にかTwitterに投稿するためのURLが変更されていたので最新のものを使っておきました。
アンパンマンDBバージョン3の現在できている画面をアップしました。
ただし、フロントエンド側はまだ何も作っていないので本当に何にもないただの真っ白な画面が出てきます。
たぶん今後は随時進捗状況をアップしていきます。
Svg2Xaml、ストローク対応版公開しました。
実際に変化しているファイルは2つだけで、ほかのファイルについてはオリジナル版をそのまま使っています。
あと、付属しているテキストはライブラリそのものではないのでLGPLの適用外だと思われます。
TGWSAdminを修正しました。
RSSをアンパンマンDBの最新っぽい情報群に取り込むプログラムが、Twitter連携のときと同じように特定の状況下で働かないことがあったのです。
LGPLのことはよくわからないのですが、元のライブラリと微妙に違う名前をつけて、元著作権者を表記して、LGPLを継承すれば大きな問題はなさそうな気がします。
とにかくやってみなければ始まらないので、まずは自分の思うようにsvg2xamlのバグ修正版を公開したいと思います。
ポケモンホワイトでドーブルが仲間になりました。
ドーブルはスケッチでどんな技でも自分のものにしてしまうので、技の構成がいろいろと楽しそうです。
とりあえず、ぼうぎょ・とくぼうがいい感じなのでゆうわく(PDWで覚えていた)とコットンガードで耐久方面に育ててみようと思います。
でもうちのエルフーンはコットンガード覚えてないんだよなぁ…。
svg2xamlどうしましょう。
自分で使うために治したんだから自分で使うのは当然として、成果物の公開とかもしたいのですが、LGPLのライブラリの派生版の公開なんてしたことがないからこのあたりの流儀やら何やらがわからんのです。
それを言うなら私自身が1から作った作品も流儀を知らないといえば知らないのですが、自分のものなら公開方法が変でも特に迷惑がかかるようなことはないのです。
アンパンマンDBのアンケート、全部終了したわけではありませんがおおよその集計結果が出てきました。
モバイル版にはそれなりの要望がある模様。現在EZwebではメモリ不足で表示しきれない問題があります。また、検索にも問題が発生しています。リニューアル時にモバイル版のデザインを同時に作るという形でよさそうです。
キャラクターグッズについては買いたい人もそうでない人もそれなりにいるようです。後述するように歌詞掲載・検索できるようにするにはそれなりに金がかかるので多少がめつく行かなくてはならなくなるかもしれません。作業は割と簡単そうなので空き時間にちょこちょこっとやってみようかと思います。
歌詞掲載についてはさほど需要はないみたいです。コメント中にもあったのですが、単に歌詞を表示するだけなら外部サイトを駆使すれば特にお金を掛けることなく可能です。ただ、表示用に掲載するだけでなく、検索にも使えるようにしたいという思いが少しあります。アンパンマンDBの強みのひとつは充実した検索性だと思うのです。その検索性を強化するためなら…と考えをめぐらせています。
svg2xaml、私がわかる範囲では直りました。
見つかった問題点は昨日のものから3つ増えて以下の5つ。
1.ストロークの接続点の種類が反映されない。
2.ストロークの端点同士が勝手に結ばれる。
3.色が変。
4.ストロークの太さに変換が適用されていない。
5.XY軸に平行な直線が描画されない。
1は昨日解決しました。
2は、GeometoryをPathGeometoryに変換するためにPathGeometry.CreateFromGeometryでなくGeometry.Combineを使っていたのが原因でした。
素直な方法ではなく奇っ怪な手段を用いているのを見ると、メソッドの意味を考えずに使ってしまったように見えます。
3は、普通のARGBで途中まで計算していたのに途中からその数値でScRGBを計算してしまったために起きた問題でした。
どんなことが起きているのかというと、描画される色が実際より明るくなってしまいます。
おそらくこれも、メソッドの引数と戻り値の方だけを見て意味を考えずに使ってしまったのでしょう。
4のストロークの太さについては、もう、そのままです。
そもそもこのライブラリがストロークにまともに対応する気がなかったようなので、まあ当然これも対応していなかったというわけです。
変換行列の行列式から拡大率を計算して太さに反映させました。
5は、パスの面積が0ならば表示しないという実装になっていました。
ストロークがなくフィルのみならば面積0=何も塗らないという意味でこの実装が正しかったのですが、線は面積が0でも表示されます。
というわけで、線がなくて面積が0ならば表示しないというロジックに変更しました。
昨日に引き続きばいきんまんの絵で改善の様子を残しておきます。
group_concatの件、結論から言うと、ダメでした。
共用サーバーゆえ、下手にバージョンアップすると互換性が失われてみんなのプログラムが動かなくなるかもしれないとのこと。
残念ですが、仕方ないので頑張って自分で実装してみます。
SQLiteには自分で関数を追加することができるらしいのです。
パフォーマンスはガクッと落ちるだろうから使うのは最小限にしなければいけないとは思いますが、うまく使えばかなりの威力を発揮しそうです。
svg2xamlで線がうまく表示されないバグ、頑張って原因を調査しました。
問題点は2つ、ストロークの接続点のスタイルが適用されない、ストロークの端点が認識されない。
問題点1は解決しました。
ストロークの接続点のスタイルを、読み込むだけは読み込んでおいて、出力時に反映していないのが原因でした。
改善の様子をアップしておきます。
もう一方の問題も、大体の原因には目星がついています。
なんとか明日には直したいところですね。
うちのSQLiteではgroup_concatが使えないようです。
group_concatというのは、複数の値を任意の区切り文字でつなげてくれるという便利な関数です。
もしこれが使えればアンパンマンDBの次期バージョンでカテゴリや登場キャラの一括取得に役立つと思ったのですが…。
バージョンアップすれば使えるはずなので、ダメ元でサーバー管理者に掛け合ってみます。
なんとか頑張ってアンパンマンDBのコラムを更新しました。
アンパンマンDBは今後バージョンアップを予定しているのでそのバージョンアップにあわせてコラムの管理画面もちゃんと作ろうと思います。
現状ではコラムだけほかのコンテンツを合わないつくりになっているのでここも統一したいのです。
アンパンマンDBのコラム、1年以上更新がありませんが、ネタがないわけじゃないんです。
ただ、管理画面ができていないので、更新には手動でSQL文を打って手動でRSSを発行しなければいけないのでほかのコンテンツの更新と比べてかなり大変なのです。
管理画面を作れば済むという話ですが、それはそれで面倒ですし…。
ちょっとニンテンドー3DSを触ってきました。
なんというかまあ、普通に立体的になっていましたね。
一言で表現するなら、「普通」です。
そこにあるものが普通にそこにあるように見える、そんな「普通」です。
目を見張るほどとんでもないものが見えるとか、とんでもなくドドーンと飛び出してくるというわけではありませんでした。
ただ、試遊台にあったものはすべて3Dボリュームが最大にされていて、単なる二重像になっていたのでどれを見るときも調整が必要でした。
やっぱりとんでもなくドドーンと飛び出してくるのを期待して無茶な3Dボリュームにしてしまうのでしょうかね。
アンパンマンDBバージョン3のデータベース構成考え中。
SQLiteにすると正規表現検索が使いにくくなるのでなるべく正規表現に頼らずとも検索できるようなデータ構造にしたいのです。
また、カテゴリも、親子関係がうまく表せておらず、親の親とか子の子とかのカテゴリがうまく処理できないでいたので、その点の改善も考えています。
正規表現を使っていたのは、複数の要素をひとつのテキスト内に詰め込んでいたのを分解するのと、ひらがなとカタカナなどの同一視でした。
このあたりは、素直に複数の行および列を使うとか、見せるデータとは別に検索用のデータを用意するとかで対応できそうです。
カテゴリに関しては、包含関係をきれいに表せるモデルを使えばなんとかなりそうです。
大阪に行ってきました。
駅ビルが新しくなっていましたね。
外側を通って上ってみたのですが、とても楽しかったです。
つい乗りたくなるエスカレーターとでも言うのでしょうか。
帰りは中を通ったのですが、中は別に普通でしたね。
というわけで、駅ビルを一往復してきたという話でした。
ふにゃさん、これ以上開発する予定のなくなった1.xx系の作りかけの最新版をアップしました。
最新版といえども作りかけなので明らかにうまく動かない部分が多々あります。
ちなみに、WPFで作る予定の2.0.0は、比較的安定しているバージョンの最新版である1.13のソースコードをベースに作り直します。
TGWSAdminのRSS-Twitter連携機能が、RSSを更新するタイミングによってうまく動かないことがあったのを修正しました。
簡単に言うと、最新のRSSを以前ツイートしたものと同じかより古いと誤認識してしまうのが原因でした。
TGWSAdminもWindows7的にしていきたいですね。
svg2xaml、閉じたパスならきれいに変換してくれるのですが、開いたパスだと端点を直線で結んでしまうバグがあるようです。
逆に言うとそれ以外は割りと良好なので、そこさえ自力で直せれば実際に組み込むこともできそうではあるのですが。
あと、先月26日に言っていた「Linux系の何か」として、Ubuntuを入れてみることにしました。
別にWindowsから乗り換えるわけではなくテスト環境として欲しいだけなのでインストールしやすそうなWubiを使ってみることにしました。
ええ、OSはパソコンの基本ソフトなのでカテゴリはPCソフトですよ。
WPF/Silverlightでのベクターグラフィックについて調べています。
日本語のサイトだとWPFを使えば線を引けます丸を書けます線を引けます四角を書けますばっかりで役に立たないことこの上ないのですが、海外のサイトに目を向けるとわりといい情報が見つかったりします。
探していたらsvg2xamlなんてものが見つかったのでまずは試してみようと思います。
WPFはベクターグラフィックを扱うのも得意だとか、ハードウェアアクセラレーションで高速に描画できるとか、そういったことを聞いたので、WindowsFormsではなくWOFで開発するというのもありかと思いました。
WPFで開発していると、ブラウザ上で動くというSilverlightにもほとんどコードの修正なしで移行できるという話ですし、充分なパフォーマンスが得られるのであればかなり良い選択かもしれません。
ふにゃさんのグラフィックについて。
いつまでも320x240の画面サイズでもないだろうということで、ウインドウサイズに合わせてゲーム画面を大きく描画するというのを考えました。
しかし、320x240の画面をそのまま拡大しては画像が荒くなってしまいます。
そこで考えたのが2つの方法。
1つは、SVGなどのベクターグラフィックを利用する方法。
これならば解像度を気にせず画面サイズに合わせて自由にきれいに拡大縮小できます。
単純なふにゃの造形とも相性抜群です。
しかし、SVGを読み込み表示するノウハウを私はまったく持っていませんし、それらしきライブラリの導入に成功したこともありません。
つまり、かなり難しそう、ということです。
もう1つは、あらかじめ大き目のビットマップを用意しておいて、実行時に縮小するという方法。
縮小アルゴリズムにもよりますが、小さい画像を拡大するよりはきれいに表示できますし、実装も比較的簡単です。
問題は、ファイルサイズおよびメモリ使用量が大きさに比例して増大するということ。
まあ、最近のパソコンなら大きな画像でもまったく平気かもしれませんが。
結論から言うと、ダメでした。
NeoMuplを32bitでコンパイルしなおしても、DirectMusicは使えませんでした。
やっぱりDirectMusicそのものがなくなっているようですね。
FNチェンジャーを.NETで書き直してみました。
VB6は新しい環境にインストールしていないし、ランタイムも将来ない環境が増えていくんだろうなと思ったもので。
あと、TableLayoutPanelを使って、ウィンドウサイズに入力フォームの大きさを追随させるようにしました。
それからエラー処理とかログ表示なども。
もしかしたらNeoMuplは32bitでリビルドしたらDirectMusicも使えるようになるんじゃないかと思い、早速プロジェクトを開いていろいろしてみたのですが、どうにもこうにもあれやこれやとトラブルが多く…。
それはそうと、今度のアンパンマンの映画に出てくるココリンを描いてみました。
実際のココリンはもっとにこやかな顔です。
ふにゃさん開発中。
まだ地味なインターフェース作りです。
アニメーションは再生状態がそれぞれ変化するけどアニメーションの元データ自体は変わらない、そのあたりもうまく表現したいものです。
GChat最新版公開しました。
バージョン1.00ではタグ使用可能でしたが、今回のバージョン1.01では使用不可能になりました。
ただ、このままでは不便なので今後何らかの形でタグを使えるようにするかもしれません。
また、それとは別に機能追加を考えています。
そのひとつは、入力エリアサイズ変更機能。
近頃ワイド画面が普及してきた一方、携帯端末でパソコン用のサイトを見る機会も増えてきたので、なるべくならこの両極端に対応させたいのです。
おそらく、数種類から選択できるだけでも充分に効果を発揮すると思います。
えーっとですね。
うちで実際に稼動しているほうのGChatはXSS脆弱性修正できました。
で、それを配布用にも反映していざアップしようと思ったら、直前に行った念のためのテストで問題が出てきました。
簡単にいうと、ちっとも解決していませんでした。
自サイト用のものと配布用のもので微妙に異なる部分があるのでそこら辺りで問題が起こっているのだと思われます。
ふにゃさんの開発中。
描画系のインターフェースを構築しています。
アニメーションを静止画と同じように扱いたい、描画先によって適切な描画モードが選ばれるようにしたい、などと考えているとなかなか難しいです。
ポケモンホワイトで、テラキオンを捕まえました。
あまりにも見つからないのでブラックにしかいないのかと思いましたが、なんとか見つけることができました。
GChatにクロスサイトスクリプティングの脆弱性が見つかりました。
簡単に言うと、誰でもチャット内に危険なコードを埋め込めるということです。
もちろんその具体的な方法は述べませんが、早急に問題を修正しようと思います。
ふにゃさんのgitリポジトリ作りました。
githubで公開しています。
https://github.com/mifumi323/funya3
浮き沈みランチャーが64bit環境でも問題なく動くことを確認しました。
一方NeoMuplは、DirectMusicが使えませんでした。それ以外は32bit版とまったく同じです。…時々エラーで落ちるところまで含めて。
