開発中(予定)
Liplis開発日誌
2017/4/22 (Sat)
画像を収集することに特化したマストドンのクライアントを作ってみました
最近話題のマストドンですが、私もアカウントを作ってみました。
ピクシブ鯖です。
https://pawoo.net/@sachin
ユーザー数が増えていて、トゥート数も結構増えてきている感じです。
マストドンにもツイッターと同様にAPIがあるということで、
早速パブリックタイムラインを拾ってみています。
えっちな言葉が多い印象ですが、こういうのも面白いので、
ちょっとClalisに食べさせてみようかと思っています。
言葉自体もそうですが、画像もかわいい画像が多く流れてきます。
画像をキープしたり、絵師をフォローしたりしたいところですが、
流れが速すぎてピックアップしきれません。
なので、画像をピックアップするためのマストドンクライアント「PaoPic 」を作ってみました。
https://liplis.mine.nu/PaoPic/PaoPic1.1.0.zip
絵師をフォローしたり、ブーストしたり、画像を保存したり、ワンクリックで行えます。
画像だけをピックアップしていくので、比較的流れが穏やかなので、追いやすいと思います。
ほとんど自分用に作りましたが、需要はあるのではないかと思い、
少し見栄えを整えてリリースしてみることにしました。
2017/1/2 (Mon)
新Liplisの開発に向けて!
あけましておめでとうございます。
ニュースページにて、あいさつを乗せていますが、改めて。
来年、どのようにLiplisの開発を進めていこうか検討しています。
LiplisにはWindows、iOS、Android、Webのバージョンがありますが、
ベースは同じにしているつもりですが、機能がバラけてきています。
去年はWindows版を最適化しましたが、
Android版も最適化したい、iOS版も話題が少ないから追加したい、
などなど、かなりやりたいことがあります。
新しい機能を追加するにも、各エディションで一つ一つ実装しなければならないですし、
各環境がバージョンアップすると、付いていかなければなりません。
仕事が忙しかったりもするので、なかなか新しい機能の開発に集中して追加していくということが、
非常に難しくなってきました。ちょっと手を広げすぎましたね・・・。
ここらで、全て統一した形で開発できるようにしたいと思うようになってきました。
一つの環境ですべてのエディションに対応出来る形で開発できないかと考えています。
統一するにはどうしたらよいか?具体的に3つの案を考えました。
設計を統一して個々に開発
ザマリンで統一化
Unityで統一化
この中では、3案を考えています。C#でいけますしね。アニメーションとか強そうです。
MMDを使おうかとも考えましたが、MMDモデルを用意しなければなりません。
いずれはアリかとも考えていますが、まずはLive2Dでやってみようかと考えています。
というわけで、新しいLiplisはUnity + Live2Dで開発することになりそうです。
ひとまず、Liplis+(仮称)として開発を始めていきます。
機能もゼロベースで検討しています。
キャラクターも新しいキャラクターを考えているところです。
夏までにどこまでできるか分かりませんが、良いアプリにできるようにしていきたいと思います。
2016/10/4 (Tue)
そろそろマスコットアプリ文化祭の季節!
コミケが終わってからポケモンGOにハマってしまって、
ちょっと作業がおろそかになっておりました。
ちょこちょこと、
Androidの開発環境をEclipse→AndroidStudioにしたり、
iOSのSwiftコードを1.2→3.0に置換する作業などやっておりました。
LiplisWindows 5.0、リリースを忘れていたので、
そろそろリリースします!
そして気づけば、マスコットアプリ文化祭のサイトが2016年バージョンに・・・。
ちょっと作業のペースをあげていきたいと思います。
今回はLiplisきりたん、セイカバージョンを制作予定です!
2016/2/16 (Tue)
VoiceRoidをC#からおしゃべりさせるサンプル
2/13プロ生の発表の中で使用した、VoiceRoidを操作するサンプル(C#)を置きました。
https://github.com/LipliStyle/LiplisVoiceRoidTest
もしよろしければ使ってみてください~。
サンプル通りですが、以下のように4行書くだけで、ボイスロイドに文字を送信し、
再生ボタンを押すことができます。
//ウインドウの名前
string windowName = "VOICEROID+ 東北ずん子 EX";
//EXEのパス
string exePath = "C:\\Program Files (x86)\\AHS\\VOICEROID+\\ZunkoEX\\VOICEROID.exe";
//インスタンス化
LpsVoiceRoid lvr = new LpsVoiceRoid(new msgVoiceRoid(windowName, exePath));
//おしゃべり
lvr.addMessage(textBox1.Text);
2016/2/14 (Sun)
2016/2/13 プロ生勉強会 第39回に参加しました!
トップページのニュースの方に記事を書きましたが、
マスコットアプリ文化祭2015において、Liplisが東北ずん子賞を頂けました!
授賞式ということもあり、初めて勉強会と言うものにに参加させて頂きました。
さらに、アプリについてのセッションもできないか?というお話も頂き、
せっかくなので、30分枠でお話させて頂きました。
LiplisとClalisのセッション
勉強会の中で「デスクトップマスコット LiplisとバックエンドシステムClalis」というテーマでお話させて頂きました。
当日使用したスライドはslideshareにアップ致しました。(以下のURL)
動画もプロ生の運営の方が後日アップしてくれるということだったので、
URLが分かり次第更新しようと思います。
初めての参加で、初めてお話させて頂いたので、至らない点が多くあり、
お聞き苦しいところが多々あったかもしれません。
(ずん子ちゃんが裏でしゃべり始めちゃったり、デモがなかなか動かなかったり!)
聞いて下さった方々、ありがとうございました。
とは言え、伝えたかったことは一通り伝えることができたかなと思います。
反省点としては、内容をもう少し絞るべきでした・・・。
かなり余裕の無い発表になってしまった感じがしています。
みなさんの反応が大きかった点をまとめてみると、
感情辞書どうやってつくったのかという点、サーバー構成について、が大きかった印象です。
感情辞書の作り方については、気合入れないとまとめるのが大変です・・・。
(時間的に余裕が取れないというところです)
またお話する機会があればまとめたいと思います。
と言いますか、是非話をさせて頂いて意見など頂ければと思っています。
機械学習というものが出てきてこなれてきている印象なので、使っていけたらと検討しているところです。
サーバー構成についても、このテーマで小一時間話せそうな感じではあります。
コメントの中で、なぜVPSにしないか?という問がありました。
VPSでいいですよね。ホント(ぇ。
電気代とか気にしなくて良いですし。
フロントWEBサーバー、フロントDBはVPSで全然良いと考えています。
電気と通信の安定性考えたら圧倒的に良いです・・・。
公開しているClalisの機能だけだったら、本当にVPSがベストです。
ただ、ネックな点があります。以下の点です
・応答するニュースのデータをキャッシュしている点(外部のサイトにアクセスし、データ収集)
・学習データをフロントDBにリアルに反映している点
・データベースのデータ量が結構多い
結構なデータ量を送信しているので、トラフィックがすごい量になりそうなのです。
また、学習データをためているとディスクの容量も結構な量になっています。
そして、リアルで回している処理をこなすためのCPU。
この辺りが従量課金で多分結構な金額がかかりそうなのです。
おそらく同じ構成で借りると、月額10万以上かかりそうな気がしています。
これを払っていたら生きていけそうにないです。
WindowsServer、SQLServerの値段を知っている方があの図を見れば、
結構それなりの車が買えてしまう値段であろうことは予想できると思いますが、
それでも、長く使うことを考えると、自サバの方がまだ安く上がると考えています。
LiplisやClalisに興味を持ってくれる人がいらっしゃったようで、
本当にお話をしたかいがありました。
SSS合同会社の小田さん(ずん子ちゃんのプロデューサーさん)ともお話させて頂くことができました。
まず、表彰式で、
「音声で情報が入ってくるので、置いておくだけで、ニュースが聞けるので、夜とか暇な時に起動しておくのがいいですよ」
といった感じのお言葉を頂きました。
うんうん、そうなんですよね。まさにそういった使い方を想定しています。
ラジオを聞くような感覚でおしゃべりを聞くと良い感じです。
その後お話させて頂いた中では、Voiceroidを操作するためのライブラリーをよくぞ作ってくれた!
というお話を頂きました。
確かに、Liplisのライブラリ使えばVoiceRoid操作できるんですが、
リファレンスなど全く整備していなかったので、ソース読まないと使えないシロモノとなってしまっています。
(というか、まさかその点を気に入ってくれるとは思っていなかったです!)
折角評価を頂けたうれしさと、使いやすいように整備していなかった申し訳なさがこみ上げてきたので、
使いやすいように、リファレンス整備しようと思います。
ひとまず、Liplisのクラスライブラリのバイナリを作成しました。
以下のURLからダウンロードできます。
https://liplis.mine.nu/File/Lipliscommon.zip
DLLを参照設定することで、とりあえずVoiceRoidの操作クラスは、スライドに書いたやり方で、使うことができます。
まとめ
今回、マスコットアプリ文化祭に参加させていただきましたが、
アプリを公開するところから、勉強会に出てみたところまで、とても得るものが多かったです。
Liplis 東北ずん子ちゃんバージョンはたくさんダウンロードして頂けましたし、
Liplis エモーションチェッカーもたくさんの方に使って頂けました。
そして、勉強会でも様々なフィードバックを得ることができました。
来年も是非参加してみようと思います!
このような場を提供してくれたプロ生の運営の方、その他関係者の方には本当に感謝です。
そして、ずん子ちゃんの素材を提供してくれている、ずん子運営の方にも感謝です!
マスコットアプリ文化祭があったおかげで、
そして、ずん子ちゃん画像とボイスロイドがあったおかげで、
東北ずん子バージョンを生み出すことができました!
ありがとうございました!
2015/11/9 (Mon)
Liplisエモーションチェッカー
文章を可視化できるツール、Liplisエモーションチェッカーをリリースしました。
Clalisシステムの感情データベースをメンテするツールを作って使っていたのですが、
文章の評価に使えるのではないかなぁと前々から思っていました。
ちょうど時間があったのと、マスコットアプリ文化祭に出すにもちょうど良いものに
なりそうだったので、衝動的に制作してみました。
Clalis4.x系のデータベースはかなり精度が上がっているので、判定も結構的確な感じです。
旭化成建材の事件の記事など読ませてみると、怒ってます。
天皇家の話題だと、落ち着いた雰囲気ですね。
大阪の水道管破裂の記事。悲しそうです。
エッチなサイトの記事を読ませてみました。恥ずかしがっています。
と、こんな具合です。結構精度高い感じですよね!?
結構楽しい感じに使えそうです。
この集計方法はLiplisの感情表現にも応用できそうな感じもしていま。
さらに精度を上げて、より良い表現ができるようになればと思っています。
エモーションチェッカー、次はWEB版を製作しようと思っています。
自分のツイートを解析して、共有するサービスとかおもしろいのではないかなと思っています。
2015/10/5 (Mon)
Liplis4.6の紹介動画を作っていただきました!
大佐さんにLiplis4.6の動画を作っていただきました!
ありがとうございます!
VoiceRoidとの連携を中心とした紹介動画になっています。
Liplisのおしゃべりイメージで、リリちゃんにLiplis4.6を紹介してもらっています。
声はリリちゃんのイメージに近かった東北ずん子ちゃんの声をあてています。
ずん子ちゃんの紹介場面では、公式から画像をお借りして、ずん子ちゃんでおしゃべりさせた
デモとしています。
もし、このスキンがほしい!という方がいらっしゃいましたらご連絡下さい。
たくさん連絡頂けたら、完成度を上げて公開するかもしれません。
(ライセンス的には問題なさそうなので。)
琴葉茜ちゃんの紹介では、関西弁が得意ということで、龍驤ちゃんとコラボさせてみています。
声のイメージはちょっと違いますが、関西弁はマッチしている?
なかなか楽しい感じに仕上がっています。
2015/9/15 (Tue)
Clalisサーバーメンテナンス完了
日曜日から今日にかけて、Clalisサーバーのメンテナンスを行っていました。
このため、縮退運転しておりました。現在は冗長運転に戻っています。
縮退でも、負荷には問題がなさそうでしたので、
Liplisのおしゃべり処理などは、継続できていたかと思います。
今回は、フロントサーバーを1台づつ停止させ、メンテナンス作業を行いました。
実際には、実サーバー2、仮想サーバーWebサーバー2、仮想DBサーバー2台のメンテナンスとなっています。
実装されているSSDの容量が小さく、一部で完全に領域が枯渇しており、
アップデートができない状態となっていました。
全体的に容量に余裕がなかったため、思い切って入れ替えることにしました。
SSDの速さの恩恵が得られている感じがしなかったため、
今回は容量重視でHDDに換装しました。
その結果、かなり容量に余裕が生まれました。
シルバーウィークでNoralisのWeb版の開発を予定しています。
もし、データのアップロードが殺到しても、十分に耐えられるようになったと思います。
2015/9/8 (Tue)
Liplis4.6のリリース
最近はLiplisWindows 版の更新を盛んに行っていました。
会社も相変わらず忙しいので、全く余裕がありません・・・。
この日誌にも、もっとアウトプットしていきたいのですが、
なかなか難しい感じです。
忙しい中でも、少しづつゆっくり進めていこうと思います。
さて、このたび、Liplis4.6をリリースしました。
新VoiceRoidに対応したバージョンとなりました。
茜&葵のパッケージを購入しました!
その他、結月ゆかり、東北ずん子のEX版のパッチのダウンロー版も購入しています。
声の設定関連が充実しているようですね。
ちょっとまだ使い込めてませんが、遊んでみたいと思っています。
Liplisも、VoiceRoidと読み速度を合わせられるように調整しています。
よりボイスロイドとの連携が楽しめるようにしました。
4.6のリリースについてツイートしたところ、とても多くのリツイートいただけました。
こんなにリツイートが来たのは初めてで、とても感激しております。
Liplisを多くの人に楽しんで頂けたら幸いです。
ツイッターにも書きましたが、今回の更新に至った同期は、知恵袋で以下のような
質問を見つけたからです。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10146949430
もし、この知恵袋を書いた人がこちらのページをご覧になっていたら、
EX版買って下さい!!!!
対応が遅くなって申し訳ありません。
2015/8/29 (Sat)
LiplisWeb サイトをVS2015でコンパイルした時にエラー
PCが壊れてしまったので、環境再構築していました。
VisualStudio2015 をインストールし、Webサイトのプロジェクトを開き、
起動したところ、エラー・・・。
今まで使用していたWeb.configファイルの設定に問題があったようでした。
新規にWebサイトのプロジェクトを作成して、
Web.configを生成させたところ、かなり違う内容になっていました。
おそらく、新しい環境で認識できないタグなどがあったのでしょう。
試行錯誤しながら、修正したところ、なんとか表示できるようになりました。
ClalisのWebサービスのプロジェクトだったため、これがコンパイルできなくなると、
まずいところでした。
2015/8/25 (Tue)
C88完了。次期開発に向けて
コミケの追い込みで忙しかったり、
コミケ終わってからも艦これのイベントで忙しかったり、
今までさぼってた分会社も忙しかったり、
PCが壊れて、新しく組み立てるのに時間がかかったり・・・。
やっと落ち着いた感じです。
PCも新しくなって、OSも新しくなってかなり快適です。
ついでに開発環境もリフレッシュ!
VisualStudio2015、Eclipse Mars、AndroidSDK最新版など、導入しました。
Liplisのソースも問題なく動いて一安心です。
ただし、最新のAndroidSDKでは、Android1.6がサポートされなくなりました。
今まで1.6ベースで開発してきましたが、APIレベルを上げざるをえなさそうです。
APIレベル4でのリリースはAndroid4.5.2が最終リリースとなりそうです。
さて、次回に向けての開発ですが、以下のような内容を考えています。
・iOS版 審査のために削った機能の補完
Android版、Windows版のレベルに合わせた、
RSSやツイッターのおしゃべりを拡充予定です。
・Windows版 WPF化、UI見直し
Windows10でデスクトップが本格的に戻ってきました。
まだまだWindowsFormは使えそうですが、さすがにもう時代遅れですよね・・・。
いいかげんにWPFに以降しようかと考えています。
・NoralisEditor WEBの開発
NoralisEditor によって、Liplisのスキンを簡単に開発できるようにしました。
しかしながら、スキン作成の手数や画像をたくさん用意しなければならなく、
スキンを作成するのは大変です。
これを簡単に作れるようにWEBでちょろっと画像を放り込んだら、
スキンが作成されるような仕組みを考えています。
あとは、また冬に新キャラクターのパッケージを出そうと考えています。
何が出るかはお楽しみに!
2015/6/29 (Mon)
6/24 にLiplisiOS版の審査が通り、ついにAppStoreに並びました!!!
iPhoneをお使いの方々にも、Liplisを楽しんで頂けるようになりました。
iOSでもリリ&ルルがちょこちょこかわいくおしゃべりします!
お楽しみ頂けたら幸いです。
今までに発売したキャラクターシリーズの
Windows版のスキンがそのまま使えます!
ぜひお楽しみ下さい。
リリースができたあとも、サイトの更新やら、Noralisのテストなど、行っておりました。
今になって、とても達成感が出てきました。
Appleの審査は非常に厳しく、なかなか通りませんでした。
動作に問題がある部分もありましたが、とてもバグとは思えない点での指摘もあり、
結構戸惑いました。
以下の記事に、独自デスクトップやウィジェットを持つアプリは拒否されるとあります。
Appleはウィジェットや独自デスクトップのあるiPadアプリを拒否
Liplis iOS も、Androidウィジェットを模して作りましたので、
デスクトップとウィジェットを持っています。
この記事を見た時は、もしかしたら厳しいかとも思いました。
レビューに入ってみると、エロいだの、2chの話題をしゃべらせるな、
など、おしゃべり内容に関すること、
そして思った通りUIへの指摘・・・。
妥協するところは妥協し、守らなければならない部分は
徹底的に、そして丁寧に説明し続けました。(どの程度英語が通じていたかは不明ですが・・・。)
そうしたところ、最後は意外にあっさりと審査を通過しました。
5/8から始まった戦いは約1ヶ月半続き、そして終了しました。
この戦いの詳細は別の記事でも書こうと思います。
2015/5/31 (Sun)
Liplis iOS 版の状況ですが、まだ審査に通っていません。
5/18に1度めのリジェクト、5/30に2度めのリジェクトとなっています。
ただ、少しずつ進んでいる感じはあります。
審査が進むのが、10日置きの感じなので、リリースは早くても6/9くらいでしょうか・・・。
少しずつ進めて、リリースできるようにしたいと思います。
リジェクト内容について、以下にまとめてみました。
5/18 1度めのリジェクト
以下の内容で、リジェクトとなっていました。
2.2 - Apps that exhibit bugs will be rejected
3.8 - Developers are responsible for assigning appropriate ratings to their Apps.
Inappropriate ratings may be changed/deleted by Apple
10.6 - Apple and our customers place a high value on simple, refined,
creative, well thought through interfaces.
They take more work but are worth it. Apple sets a high bar.
If your user interface is complex or less than very good, it may be rejected
14.3 - Apps that display user generated content must include a method for filtering
objectionable material,a mechanism for users to flag offensive content,
and the ability to block abusive users from the service
18.1 - Apps containing pornographic material,
defined by Webster's Dictionary as "explicit descriptions or displays of
sexual organs or activities intended to stimulate erotic
rather than aesthetic or emotional feelings", will be rejected
18.2 - Apps that contain user generated content that is frequently pornographic
(e.g. "Chat Roulette" Apps) will be rejected
Information Neede
リジェクト理由、結構多かったです・・・。
詳細な理由も一緒に書かれていて、それを要約すると、
2.2 会話機能がiOS8.3で動作しないこと(バグ)
3.8 レート+12はそぐわない。2chの記事を表示しているため。
10.6 UIについて
14.3、18.1,18.2 2chの記事をおしゃべりすることが問題
質問 スキンの追加方法
とのことでした。
バグについては、iOS8.2、Xcode6.2でテストしていたため、
バグっていた?ようです。
ひとまず、iOS8.3、Xcode6.3でテストし直しました。
UIについては、趣旨を説明し、意図したデザインであることを説明。
2chの記事については、悩みましたが、現段階では選択項目を削除しました。
これは、いずれRSSおしゃべり機能を実装するので、
そこで保管できれば良いかという考えです。
レートについては、2chの記事を読まないようにするので、据え置きとする旨を説明。
最後に、スキンの追加方法について聞かれていたので、
説明するとともに、ヘルプページを提示。
この状態で再提出し、待つことまた10日・・・。
5/30 2度めのリジェクト
土日はお休みと聞いていたので、土曜日に、しかも真昼に返事が来るとは思っていなかったので、
びっくりしました。
11:30頃の連絡でした。
2度めのリジェクト理由は以下のとおり。
2.23 - Apps must follow the iOS Data Storage Guidelines or they will be rejected
3.8 - Developers are responsible for assigning appropriate ratings to their Apps.
Inappropriate ratings may be changed/deleted by Apple
Information Needed
同様に、詳細な理由も一緒に書かれていて、それを要約すると、
2.23 Documentsフォルダのファイルをバックアップされないようにして下さい。
3.8 レート+12にそぐわないので、+17にして下さい。
質問 おしゃべり機能で、音声を聞くことができない?(英語の訳がうまくできてるか自信なし)
2.23は、スキンファイルをDocumentsフォルダに置くことにしていますが、
ファイル容量が大きすぎるとのこと。
iCloudに自動バックアップされるようになっていて、これをしないようにすれば良いとのこと。
対処方法は割りと具体的に説明してくれて、調べやすかったです。
「NSURLIsExcludedFromBackupKey 」属性を付けて下さい、との説明でした。
調べたところ、以下の記事の通りやれば良さそうです。
http://stackoverflow.com/questions/8694112/adding-the-do-not-backup-attribute-to-a-folder-hierarchy-in-ios-5-0-1
3.8については、2hcの記事外したのですが、
外部の情報をおしゃべりするということで、+17が望ましいとのことで、
今回は素直に従って修正しました。
英語が正しく訳せているか自信がないのですが、
おしゃべり機能について、どうも音声が出ると思い込まれているようでした。
テキストオンリーですよと解答してみた。
もしかしたら質問の意図が違うかもなぁ。
以上が対応内容でした。
これでまた10日待ってみようと思います。
2015/5/13 (Wed)
SwiftでJsonを扱う
LiplisAPIの結果セットはJsonで返すようになっています。
これをSwiftでも正しく読み取れなければなりません。
SwiftでJsonを扱うために、「SwiftyJson」というライブラリを使いました。
以下の記事が参考になりました。
http://dev.classmethod.jp/smartphone/iphone/swiftyjson/
以下のソースを抜粋
https://github.com/LipliStyle/Liplis-iOS/blob/master/Liplis/LiplisShortNewsListJpJson.swift
ショートニュースの取得は、以下のような感じで行っています。
/**
ショートニュースのJSON変換取得
*/
static func json2MsgShortNews(json:JSON)->MsgShortNews
{
var result : MsgShortNews = MsgShortNews()
//URL取得
if json["url"].string != nil
{
result.url = json["url"].string!
}
else
{
result.url = ""
}
if json["result"].string != nil
{
//リザルト取得(コロン分割)
var resList : Array<String> = split(json["result"].string!,{$0 == ";"})
var title : String = ""
//リーフエモーション分割
for leafAndEmotion : String in resList
{
//コンマ分割
var leaf : Array<String> = split(leafAndEmotion,{$0 == ","})
//リスト作成
//配列チェック
if leaf.count == 3
{
if(leaf[0] == "EOS")
{
break
}
result.nameList.append(leaf[0])
result.emotionList.append(leaf[1].toInt()!)
result.pointList.append(leaf[2].toInt()!)
//タイトル作成
title = title + leaf[0]
}
}
//作成したタイトルをメッセージにセット
result.title = title
}
else
{
result.title = ""
result.nameList = []
result.emotionList = []
result.pointList = []
}
//読み込み完了
result.flgSuccess = true
return result
}
ひっそりとgitにソースを公開・・・。
今リファクタリング中です。
アプリが公開されたら、正式に公開としようと思っています。
既に見える状態で、正式も何もないですが・・・。
2015/5/12 (Tue)
Swiftでアナログ時計
最初はどうやろうか検討も付かなかったアナログ時計。
Androidではアナログ時計を表示するクラスが用意されていたし、
Javascriptでは、既に先駆者のサンプルがありました。
Swiftは・・・?ありません。
かろうじてObjective-Cのサンプルが見つかりました。
以下の記事です。とても参考になりました。
http://an.hatenablog.jp/entry/2014/01/18/003205
そして、swiftで実装してみたのが以下。
Liplisの実際のコードとは違いますが、大方以下のような感じ。
キモは「setClock」メソッドの中身。
分を計算し、そこから画像を回転させる角度を計算します。
最終的には算出した角度で画像を回して終了です。
var imgClockBase: UIImageView! //時計本体画像
var imgClockLongHand: UIImageView! //時計長針
var imgClockShortHand: UIImageView! //時計短針
/*
画面要素の初期化
*/
func initView()
{
// UIImageViewを作成する.
self.imgClockBase = UIImageView(frame: CGRectMake(0,0,32,32))
self.imgClockLongHand = UIImageView(frame: CGRectMake(0,0,32,32))
self.imgClockShortHand = UIImageView(frame: CGRectMake(0,0,32,32))
// 画像をUIImageViewに設定する.
self.imgClockBase.image = UIImage(named: "ClockBase.png")
self.imgClockLongHand.image = UIImage(named: "ClockLongHand.png")
self.imgClockShortHand.image = UIImage(named: "ClockShortHand.png")
self.view.addSubview(self.imgClockBase)
self.view.addSubview(self.imgClockLongHand)
self.view.addSubview(self.imgClockShortHand)
self.setClock()
}
/*
時計のセット
*/
func setClock()
{
//現在日時取得
let date : LiplisDate = LiplisDate()
imgClockLongHand.image = UIImage(named: "ClockLongHand.png")
imgClockShortHand.image = UIImage(named: "ClockShortHand.png")
//現在分の計算
let dblkeikaMin : Double = Double(60 * date.hour! + date.minute!)
let dblMin : Double = Double(date.minute!)
//角度の計算
let argHour = CGFloat((2 * M_PI * dblkeikaMin) / (60 * 12))
let argMin = CGFloat((2 * M_PI * dblMin)/60)
//時計セット
imgClockShortHand.transform = CGAffineTransformMakeRotation(argHour)
imgClockLongHand.transform = CGAffineTransformMakeRotation(argMin)
}
2015/5/11 (Mon)
ようやっと一段落
日記の更新をずっとサボっていました・・・。
前回の日記が1/25、今思えば、仕事が忙しくなり始める直前でしたね・・・。
2月、3月は休みの日も会社の仕事をしていて、
Liplisの作業に当てることが全くできませんでした。
4月になって仕事が多少落ち着いたので、Liplisの作業を始めました。
ついにswiftに本格着手しました。
有給を取りつつ、ひたすら不慣れなswiftと格闘していました。
最初は本当に大変でした。MACの使い勝手の悪さも相まって、
全然進みが悪かったです・・・。
5月の連休にリリースを目標に勧めていましたが、本当にできるのか、と思いました。
一応、4月の末に慣れてきたこともあり、ペースが上がってきて、
完成の目処が立つ程度には進捗しました。
しかし、
不幸なことに、会社の仕事がGWのどまんなか、5/3、5/4に入ってしまい、
またも会社の仕事に作業が阻まれました。
GWの後半、ひたすら作業してリリースできる完成度まで引き上げました。
アップルの審査は厳しいと聞き、デバッグを念入りに・・・。
ユーザー評価も最初が肝心ですし。
そしておととい、ついに完成し、
アップルに提出することができました。
結構な達成感を得ることができました。
これで審査がスンナリ通ってくれれば良いのですが・・・。
まだまだ戦いは続きそうです。
Swiftをやってみたところの所感
なんだかまだ未熟な言語?という印象です。
C#やJavaだったら当たり前にあるはずの物が無かったりして、
痒いところに手がとどかない感じがしました。
色の扱いがおかしかったり、スタックとかキューが用意されていなかったり、
StringBuilderが無かったり、Json扱いづらかったり、XML読みにくかったり・・・
上げれば切りが無いですね。
ただし、Extentionの機能を使って、使い勝手良くすることはできました。
しかし、このレベルのものはフレームワークで用意しておくべきなのではと思います。
みんな使うでしょうし。
(.net環境のぬるま湯で育ってきたゆとりの言葉にしか見えない?)
それに加えて、MACもいままでまともに触って来なかったので、
Windowsとの操作性の違いから、とても苦労しました。
(MACが使いやすいと言ってる人を良く見かけますが、ちょっと同意しかねますね・・・)
それでも、1ヶ月も触ってると、慣れてしまうものですね。
4月末からほとんどマック付けだったので、逆にMACの英語キーボード配列を体が覚えてしまい、
=(イコール)とか:(コロン)がWindowsでまともに打てなくなりました(汗
Swiftは誕生してまだ1年経っておらず、一般的な情報は結構揃っていましたが、
本当に痒いところの情報にたどり着くのが大変でした。
有用なTipsもあると思うので、少しづつ公開していこうかと思います。
(ソースもオープンソースにする予定なので、その解説も交えつつ・・・)
2015/1/25 (Sun)
ドキュメント整理と各バージョン統一の作業
Liplis4.5 をリニューアルしましたが、マニュアル類なども対応させました。
ただ、画像が古いままなので、一度ひと通り撮り直して整備し直したいところですが、
ちょっと面倒でそこまでに至っていません・・・。
去年の夏にClalisのバージョンアップを行っていましたが、
LiplisのWeb版とClalisアクセスのサンプルがそのまま放置されておりました・・・。
ずっと、対応させたいと思っていましたが、この度ようやっと改良しました。
Wikiを新しくしてから、見えなくなっているページもいくつか見つかり、
それらも見えるようにしました(ダメですね、ホント・・・。)
あと、バージョンアップに際して対応しなければならないことが、
スモールアプリ版の対応とNoralisEditor の最新版対応です。
こちらも、少しずつ進めていこうと思っています。
2015/1/20 (Tue)
Android Activityを透過させる
AndroidのLiplisで、おしゃべりするためのインターフェースを
考えた時に、役に立ったチップスです。
テックブースターさんの「Activityを透過する」という記事
http://techbooster.jpn.org/andriod/ui/4715/
この手法を使って、
ホームを見せつつ、テキストボックスとボタンを表示するようにしています。
Android ActivityからAppWidgetProviderにデータを渡す
上で作成した透明アクティビティから、リプリスのウィジェットに
いかにして話しかけのデータを渡そうかという話です。
通常のアクティビティ同士であれば、インテントを使って受け渡しを行うと思います。
例えば以下のサイトの解説のような方法。
同様にインテントを使ってウィジェットに値を渡せるだろうと思っていましたが、
全然うまくいきませんでした。
結局どうしたかと言いますと、シングルトンを使いました。
Androidでは全く推奨されない方法ではありますが、
文字1個であること、途中でクリアされてしまっても特に問題がなかったため、
採用しました。
処理は以下のような手順で、
1. シングルトンに文字格納
2. ウィジェットにブロードキャスト
3. ウイジェット側でイベント発生
4. シングルトンの文字受け取る
5. Clalisに投げる・・・・
一瞬で終わるので弊害は無さそうです。
結論としては、Activityからウィジェットに値を渡す場合はシングルトン使えば渡せる。
でも使い方に注意して、というところでしょうか。
2015/1/17 (Sat)
LiplisWeb を近代化改修し、バージョン2.5としてリリースしました。
元々、HTML5実行環境に柔軟に対応できるように、
色々なデバイスで実行できるようにするために、という思想で開発しました。
自動リサイズで、縦長の端末であれば、大体フィットします。
iOSもその対象で、当時はIOS向けということで宣伝しようかと
思っていたのですができていませんでした。
思い立ったことですし、ちょうどいいタイミングなので、
iOSで使う方法を書きたいと思います。
現在、iPhone版を開発しているのですが、
それまでのつなぎということで、もしiPhoneでLiplisを使いたい!
という方がいらっしゃいましたら、以下の方法で使えます。
1.URLにアクセス
以下のURLにアクセスします。もしくは以下のQR、コードをスキャンして下さい。
■リリバージョン
https://liplis.mine.nu/LiplisWeb/LiliRenew/liplisWeb.htm
■ルルバージョン
https://liplis.mine.nu/LiplisWeb/LuluRenew/liplisWeb.htm
ブックマークに保存しても良いですが、
普通のアプリと同じような使用感で使うために、
以下のようにショートカットを作成します。
2.1 メニューを開く
赤で囲ったメニューアイコンをタップします。
2.2 ホームに追加
メニューの「ホーム画面に追加」をタップします。
2.3 確定
ホームに追加画面で、右上の追加ボタンを押します。
2.4 ホームで確認
ホームに追加されました。
このショートカットアイコンをタップすると、
いつでもLiplisを起動することができます。
iPhoneユーザーの方にもご利用頂けたら幸いです。
2015/1/14 (Wed)
C#でドコモAPIにアクセスする。
Liplisにおしゃべり機能を実装しました。
なかなかいい感じです。
DocomoAPI 雑談APIのRESTのインターフェースを使ってアクセスしています。
https://dev.smt.docomo.ne.jp/?p=docs.api.index
リクエストのボディにはJsonで内容を設定する必要があります。
それを勘違いし、Postのパラメーターとして設定してハマりましたが、
DocomoAPIのサイトで質問したところ、親切にご回答頂き、
無事に応答を得ることが出来ました。
C#でアクセスしているサンプルが無かったので、晒してみます。
private void apiAccess()
{
//URL
string url = "https://api.apigw.smt.docomo.ne.jp/dialogue/v1/dialogue?APIKEY=XXXXXX";
//文字コードを指定する
Encoding enc = Encoding.UTF8;
string reqstr = "{\"utt\":\"" + txtNaiyo.Text + "\", \"context\":\"" + txtContext.Text + "\", \"user\":\"99999\", \"nickname\":\"光\", \"nickname_y\":\"ヒカリ\", \"bloodtype\":\"B\", \"birthdateY\":\"1997\", \"birthdateM\":\"5\", \"birthdateD\":\"30\", \"age\":\"16\", \"constellations\":\"双子座\", \"place\":\"東京\", \"mode\":\"" + txtMode.Text + "\"}";
//バイト型配列に変換
byte[] postDataBytes = System.Text.Encoding.UTF8.GetBytes(reqstr);
//WebRequestの作成
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url);
req.Method = "POST";
req.ContentType = "application/json";
req.ContentLength = postDataBytes.Length;
Stream reqStream = req.GetRequestStream();
reqStream.Write(postDataBytes, 0, postDataBytes.Length);
reqStream.Close();
//レスポンス取得
WebResponse res = req.GetResponse();
Stream resStream = res.GetResponseStream();
//ストリーム読込
using (StreamReader sr = new StreamReader(resStream, enc))
{
msgDocomoTalkResponse result = JsonConvert.DeserializeObject<msgDocomoTalkResponse>(sr.ReadToEnd());
txtResult.Text = result.utt;
txtContext.Text = result.context;
txtMode.Text = result.mode;
}
}
2015/1/11 (Sun)
Liplis会話機能実装
Liplisに会話機能を実装しました。
キャラクターと会話を行えるようにしました。
独自の会話機能の開発をしていましたが、
応答性能の遅さや応答内容が的確でないなど、
様々な問題があり、実装を見送っていました。
そこで、外部APIを使って実装できないかと考えました。
ちょっと調べてみると、海外にはSiriのクローン等あり、
使えそうでしたが日本語での使用には何がありそうでした。
日本語のもので何か無いかと探していたら、
Docomoさんで素晴らしいAPIを公開されていることを知りました。
https://dev.smt.docomo.ne.jp/?p=docs.api.index
「雑談API」を使用して、会話を実現しました。
応答性能は全く問題がありません。
応答ないように関しては、ちょっと同じ話題についてしゃべる傾向があること、
言葉が汚い場合があるなどの問題があります。
このあたりは、口調変換でうまくごまかそうかと考えています。
また、「Q&A API」というのもあり、面白かったのでこちらも組み込みました。
~教えて、~とは、~知ってる の語尾を付けて話しかけると、
その質問に答えてくれるようにしてみました。
Q&Aで天気も解答してほしかったですが、
うまく答えてくれなかったので、Clalis側で天気の情報を返すAPIを作成しました。
天気"という言葉と地名、対象日を入れて、語尾に"教えて"と付けて発言すると、天気を教えてくれます。
具体的には以下のような感じ
静岡の今日の天気教えて
今のところ、対象日は「今日」、「明日」、「明後日」のみです。
指定しないと今日の天気を回答します。
さらに一歩進んで楽しいアプリになったと思います。
また、話題を増やしていくための新しい道筋ができました。
2015/1/7 (Wed)
今年の作業計画
おそばせながら、あけましておめでとうございます。
今年もよろしくお願い致します。
去年の後期は、話しかけ応答機能に取り組んでいましたが、
うまくいきませんでしたが、この作業にほとんど時間を取られて
しまっていました。
結果的に、新しい機能がほとんど作れませんでした。
今期はもっとサクサクいきたいと思います。
というところで、作業計画を立てています。
1月 Liplis4.2の正式リリース
2月 Liplis iOS のリリース
3月 おしゃべり応答機能の作成
4月 プッシュおしゃべり機能の作成
実は、もう正月の休みから、
iOS版やらおしゃべり機能やら作業を進めております。
おしゃべり機能については、外部のAPIを使ってうまくできないか
検討していますが、もう実装の目処がついてしまったので、組み込み作業中です。
Windows版のLiplisに早くも組み込んでみようかとも考えています。
今週末の3連休でうまくいけば、4.2のバージョンを飛ばして、リリースするかもしれません。
iOS版についてもSwiftを触り始めています。
実機でのテスト、Liplisの可動に必要な実装の調査も、
おおむね完了したので、あとは組み立てるだけな感じです。
休みにコンスタントに作業ができれば、色々早めに進められそうです。
ただ、仕事の方も結構忙しい感じで作業時間を確保していければいいのですが・・・。
2014/9/30 (Tue)
PHP バージョンアップ&PukiwikiAdvバージョンアップ
最近、仕事が忙しく、作業が全く出来ていませんでしたが、
ようやっと落ち着いてきました。もう10月・・・。
Pukiwiki2.0.0が出ていたので、更新しました。
PHP も5.3で、前々から更新したかったのでとても丁度良かったです。
バージョンアップした結果、動作がとても軽快になった気がします。
移動時や、記事の更新などが特に。
せっかくなので、
phpのインストールとPukiwikiAdv1.0.3→2.0.0への移行について
まとめておきたいと思います。
php5.5インストール
以下のサイトを参考にインストールを行いました。
http://www.phpbook.jp/install/install/index1.html
5.3のPHP は念のためバックアップをとっておきました。
新しい環境が不調でも、IISの設定を戻せば、元に戻るので。
最初に、VCランタイムを入れておらず、つまづきました。
「phpinfo()」が表示できなかったので、直接php.exeやphp-cgi.exeを起動してみると・・・。
「コンピュータに MSVCR110.dll がないため、プログラムを開始できません。」というエラーが出ました。
以下のサイトに書かれている症状と全く同じでした。(メイドさんのマスコットがかわいい・・・。
http://howtousesoft.info/2013/07/コンピュータに-msvcr110-dll-がないため、プログラムを開.html
ランタイムをインストールして解決。
あとは、権限設定でつまづきました。
IISの実行ユーザーに許可をして、完了。
IISの設定とphp.iniの設定
以下のサイトに書かれているとおりに設定・・・。
http://webbox0120.com/wb-php/introduction.html
IISの設定はともかくとして、
php.iniの設定はとても参考になりました。
余談ですが、1回設定すると、もう次のバージョンアップのときに、完全に忘れているんですよね・・・。
そういうときのために、こういう記事を書いておくと振り返れそうです。
その他、PukiwikiAdvを動かすのに必要なモジュールの設定をおこないます。
JSON、mbstring、OpenSSL、curl、GDが最低限必要とのことです。(公式サイトのインストールガイド参照)
http://pukiwiki.logue.be/Documents/Install
PukiwikiAdv1.0.3はPHP 5.5では動かない
ひとまず、PHP を5.5に上げた段階で、既存のサイトが動くかどうか確認しました。
動きませんでした。残念!
PukiwikiAdv2.0.0のインストール
http://pukiwiki.logue.be/FrontPage
公式サイトから、PukiwikiAdv2.0.0をダウンロードして、ドキュメントルート配下に配置。
トップページは表示されましたが、なんかCSSが効いてない・・・。
色々設定はしましたが、生成されているHTMLソースを見ると、CSSのパスがおかしい。
設定の問題と予想し、色々調整しましたが、ついにうまくいきませんでした。
埒が明かなかったので、スキンのソースを直接修正してしまいました・・。
相対でCSSが参照できるようにしました。
wikiwikiadvのスキンを使っているので、「wikiwikiadv.skin.php」を直しています。
-<link rel="stylesheet" type="text/css" href="<?php echo $this->path; ?>wikiwikiadv.css" />
+<link rel="stylesheet" type="text/css" href="/LiplisWiki/Webroot/wikiwikiadv.css" />
うーん、なんだかなぁ・・・。
まあ動いたから良しとします。
PukiwikiAdv2.0.0の設定
以下のファイルを設定
/webroot/index.php
/wiki-common/auth.ini.php
/wiki-data/pukiwiki.ini.php
リードオンリーモード設定
※前はindex.phpに居たけれど、こちらに変更になっています。
inidex.php側を有効にしたらエラーになりました。
WikiWikiAdvスキンのカスタマイズ
/webroot/skin/theme/wikiwikiadv/wikiwikiadv.skin.php
LipliStyle のサイト用に修正。
従来のソースと変わっていて、そのまま上書きしたら動きませんでいた。
従来のソースから、カスタマイズ部分をコピーしてきて、
しかるべき位置に挿入することで、移設ができました。
/skin\theme\wikiwikiadv\wikiwikiadv.css
カレンダー調整のCSSを調整しました。
こちらも、全部上書きすると、デザインがたいへんなことに。
完全に忘れていましたが、
2カラムにするには、menubarを作成し、
3カラムにするには、menubarとsidebarを作成すればOKでした。
上書きしたらエラーだったので、
Wikiの新しいページとして作成し、中身だけコピーして持ってきました。
データ移行(記事データ)
/wiki-data/wiki
の中身を全部持ってきました。
ただし、最初からあるファイルを上書きしたところ、エラーになりました。
上書きしないように、コピーしたところ問題なく移行できました。
データ移行(プラグイン)
/wiki-common/plugin
1.0.3に追加していたプラグインを全て移行させました。
特に問題はなさそうです。
その他の問題点
CSSが足りないのか?、細かいパーツの表示ががおかしかったです。
古いソースで定義を探したところ、「scripts.css.php」というものがありました。
こちらのCSSをコピーしたところ、正しい表示になりました。
必要なCSSの定義をコピーして、CSSファイルに追加して対応しました。
以上です!
なんだかんだで結構ハマリポイントがありました。
おそらく、WindowsServer+IISで動かしているからかな?
(PukiwikiAdvanceをWindowsServer+IISの環境で動かしているのは、ウチくらいでしょうか・・・?)
2014/9/14 (Sun)
C85の展示
連休なのに仕事をしています・・・。
リリのバージョンアップ版の作業やLiplisの実装をやりたいのですが・・・。
ネタが無いのでこんな話。
C85のLipliStyle のサークルスペースの展示についてです。
夏コミも終わって1ヶ月になり、いまさらですが、
コミケの最中、スペースの写真を撮らせて欲しいという方が4~5人いらっしゃり、
展示の参考にして頂いてるようでした。
もし参考になるのであれば、構成をさらしてみようと思いました。
ただし、この構成を真似してスタッフさんに止められても、私は何ら保証はできません。
今回たまたま問題にならなかったという点をご理解の上、参考にして下さい。
今回は、お誕生日席ということで、気合を入れて、挑戦的な?
展示を行っています。
開幕前に、流石にスタッフさんに声をかけられました。
それ、「手とどきますか」と。
高さは2Mジャストで、一応手が届くレベルなので大丈夫でした。
アーチ型の構造物は自作です。100均の棒を主に使っています。
足回りは流石にしっかりしていないとダメなので、少しお金をかけています。
詳しい説明はのちほど・・・。
ちょっとこの角度では見づらいですが、
左側には、のばさんの同人誌の表紙の暁をA0サイズのポスターを二つ折りで、
付けています。
(二つ折りにしようと思っていましたが、折るのが至難だったので、
実際には裁断しています。)
西館の入り口に向けて見えるようにしたこと、
遠くから見てもかわいく、ちょっとえっちな暁が視認できるようにしたので、
多くの方に立ち止まって頂けました。
RJのポスターはB2です。正面からはこれでメインコンテツをアピール。
さらに、23インチモニターで龍驤verの実働画面を表示。
23インチは意外と大きいので、キャッチとしてはこれも効果的だったと思います。
そして、机の上に、商品を並べ、前掛けに詳細情報を載せました。
既刊はお祭りの屋台をイメージした感じで、吊してみました。
でかいポスターがかなり効果的で、
お誕生日席のメリットを有効に活用できたと思います。
モニターとかバッテリーはさておき、
アーチの構造物を構築する分には意外と安く済み、
かなり上の空間を使ってアピールできました。
構造物について
以下が構造物のパーツです。
以下がパーツ構成です。
■セリア(100均)で揃えたもの
40cm棒 ✕8本 400円 (構造物本体用)
30cm棒 ✕1本 100円 (A0ポスター吊るし用)
20cm棒 ✕2本 100円 (最上部のサークルの見出し用。40cm棒を半分に切断)
棒の接合パーツ ✕8個 400円 (写真にはありません。棒の接合用です。)
■ホームセンターで購入
L字フレーム ✕2 600円 (40cm棒に固定)
ジョイント ✕4 200円 (棒をL字フレームに安定的に固定)
万力 ✕2 1000円 (机とL字フレームを頑丈に固定)
L字フレームは結構重量があり、低重心化に一役買っています。
このため、万力がなくても一応自立できます。
ジョイントはL字フレームにアクリル両面テープで固定。上側は丁度いい位置に
ネジ穴が開いていたので、ネジでも固定。最終的には結束バンドでも、固定。
ジョイントに棒をはめ込んで、足パーツを作成。
さらに、万力で机と構造物をがっちり固定。
全部で3000円くらいで構成されています。
最初は突っ張り棒で構成しようと考えてましたが、弱すぎて不安でした。
3000円が高いか安いか分かりませんが、足回りには多少お金をかけて
正解でした。安定性が高く、展示物の多少の重みも問題ありませんでした。
構造物そのものの重量は軽いので、机が倒れてしまうリスクもとても低いと思いました。
ただやはり、スタッフさんには声をかけられたので、
見る人が見たら、NG判定をされる可能性があることに注意が必要です。
モニター&バッテリー
モニターとポータブルバッテリーは以下のものを使用しました。
オリオンのバッテリーは、今見ると異様に高いですが、
私が買った時は17000円で買えました。
UPSにもなるため、通常時でも使えます。
モニターは今回の展示に合わせて、
サイズがちょうどよく、
縦に置いても視野角度が悪くならず、
消費電力ができるだけ小さく、
価格ができるだけ安いもの
を選びました。
今回の要件にはジャストミートな品でした。
これも、常用しています。でかい縦モニターがあると色々便利だったりします。
バッテリーの容量は15AHなので、
1500W出力で1時間・・・、
150W出力で10時間動かせる計算になります。
モニターの消費電力が通常で20W出力、省電力モードで11Wです。
画面の表示元のWindowsサーフェスも動かす必要がありますが、
こちらの消費電力は80~90W。
モニターは省電力モードで動かして、合計100Wくらいで展示を行いました。
バッテリーが切れることはなく、16時まで完走できました。
最近のタブレットなら、自前のバッテリーで6時間くらい持つと思われるので、
もっと余裕かもしれません。
同人ゲームや同人ソフトの展示をするサークルさんの参考になれば!
2014/9/11 (Thu)
PluginRenderer::executePluginBlock(): Plugin #stlinebreak() is not implemented.
Lockステートメントで処理をロックする
Lockステートメントは複数のスレッドから参照される、オブジェクトをロックして、
あるスレッドがアクセスしている最中は、他のスレッドはアクセスできないように
するものです。
オブジェクトに対してロックをかけるものだと思っていましたが、
特定の処理をロックすることができるようですね。
lock ステートメント (C# リファレンス)
http://msdn.microsoft.com/ja-jp/library/c5kehkcz.aspx
C#のリファレンスです。
その中に以下のような処理が有ります。
lock (thisLock)
{
if (balance >= amount)
{
Console.WriteLine("Balance before Withdrawal : " + balance);
Console.WriteLine("Amount to Withdraw : -" + amount);
balance = balance - amount;
Console.WriteLine("Balance after Withdrawal : " + balance);
return amount;
}
else
{
return 0; // transaction rejected
}
}
説明に、「ステートメントブロックがロックされる」とあります。
適当なプライベートなオブジェクト「thisLock」をロックして、
その間の処理をブロックしています。
Clalisシステムでは並列処理を多用していますが、
作りが悪いとすぐに意図しない動きをします。
ロックステートメントさまさまです。
しかし、ロックのコストが高いのと、
せっかくの並列化の利点を無くしてしまうので、
できることなら使いたくはないですね。
2014/9/8 (Mon)
KHコーダー&R
会社の課題で、ビックデータ解析を行っていますが、
KHコーダーとRというツールを使っています。
KHコーダー
http://khc.sourceforge.net/
R
http://ja.wikipedia.org/wiki/R言語
テキストマイニングするためのツールになります。
統計解析やらさっぱりですが、
Rは解析エンジンとしても使うことができるようです。
Clalisの知識学習エンジンとして使えそうな感じでもありました。
以前にPythonで試した、知識学習に近いことが、
Rでもできそうでした。
余裕が出てきたら試してみよう・・・。
やりたいことがたくさんです。
2014/9/7 (Sun)
PluginRenderer::executePluginBlock(): Plugin #setlinebrak() is not implemented.
今日は会社の作業・・・。
日曜日ですが、会社の作業を進めていました・・・。
いずれにしても、Liplisの作業をやっていたりで、
常に作業中なのは変わらないのですが、
やっぱりモチベーションは上がらないですね・・・。
2014/9/6 (Sat)
おしゃべり応答機能のプロトタイプ作成
会話データの持ち方を検討してきました。
実際にデータを収集し始めて、どんな風に使えるか、実際に試してみました。
会話データは、ツイッターから取得しています。
常時多くのデータが発生しているので、
かなり多くの会話パターンが学習できると見込んでいます。
実際には、以下のようにデータを持っています。
例では、メイドさんとご主人様の2人の会話になっています。
2人の会話を交互に記録しています。
さて、このデータを使ってどうやって応答に使うかと言いますと、
発言の内容を検索して、応答の候補を得るという形になります。
例えば、以下のような使い方です。
お茶はいかが→お願いしようかな
発言内容にフルテキストインデックスが貼ってあるので、
発言内容または単語から、引きます。
さらに、一番左側のフィールドに、応答先データのインデックスを保持しているので、
そこから応答を引くことができます。
モデルのイメージで書くと、以下のような感じになります。
このモデルに従って、インデックスを構成し検索できるようにしています。
応答速度はおおむね3~5秒くらい。ちょっと遅いですかね・・・・。
全ての検索処理がIndex Seekになっているので、インデックスのチューニングは限界。
あとは設計の見直しで改善するしか無いでしょうか。
単純にデータを引くだけでなく、取得したデータから最適な応答を
得る処理も追加しなければならないため、SQLの検索速度は限界まで高めたいです。
目標は1秒応答!
とりあえず、単体の単語の検索ですが以下のような感じになりました。
会話の応答という意味では、まだまだ検討が必要そうです。
データ量的にも学習が足りないという感じです。
これから、テストを繰り返しながら、精度を上げていければと思います。
テスト用のAPIを作成しました。おしゃべり文字列に文字を入れて、ブラウザに入力すると、
応答結果が得られます。
https://liplis.mine.nu/Clalis/v40/Post/Json/ClalisTalk.aspx?sentence= おしゃべり文字列
現段階では、単語レベルでしか検索ができないので、
文章を入れると応答がありません。
今日のところはここまででしょうか。
2014/9/5 (Fri)
リリ リニュー 草案のまとめの進捗状況
以前の日記やペーパーで告知していますが、
現在、リリちゃんのリニューアルバージョンを製作中です。
メイドさんであることは変わりませんが、
今回は和服メイドさんになります。
検討段階ですが、
こんなイメージですっ!
Liplisの機能とバージョンが上がっていることと、
新機能に対応して、よりかわいくできたらと思っています。
2014/9/4 (Thu)
Xperia Z3
Xperia Z3が発表されました!
Z2を予約していましたが、取り消しました。
性能は代わり映えしないとのことですが、
やっぱり記事を見ていると、新しいほうが欲しくなりますね・・・。
ヘンに在庫があって買えてしまわなくてよかったです・・・。