KyoroText で使用されている技術 その7

[課題] SurfaceViewでEditorを作る。


このページにアクセスする人を増やすため、
特定のAndroid APIをネタに記事を書くことにしました。

kyorohiroが良く知っているけど、ググッても得られない情報がありました。
SurfaceView上にEditorを実現する方法です。

これを読めば、OpenGlで書かれたEditor!!なんかも簡単に作れるようになるかも知れまもせん。

[構成]

 KyoroTextから、IME関連のエッセンスを抜き取って単体アプリ化しました。
これをサンプルとして、APIの解説をします。「KyoroSampleSurfaceViewEditor」といいます。5-6回に分割してAPIを解説する予定です。

これによりにより、以下のような効能があります。
- InputConnection の使い方が理解できます。
- InputMethodServiceを理解して、android用のソフトウェアキーボードを作成できるようになります。
- また、上記の機能のテストを作成したりする際に必要な知識が手に入ります。
※ 一部だけですが..。


[サンプルコード]
https://github.com/kyorohiro/KyoroSamples
の、KyoroSampleSurfaceViewEditorです。

ソースをコピーした後で、「Eclipse->File->Import->Existing Projects into WorlSpace」
よりプロジェクトをインポートしてご利用ください。


[次回]
今回は内容の紹介だけです。
次回から、APIの解説します。

KyoroText で使用されている技術 その6

この記事を読む人はカナリ少ないです。
今読んでいる「あなた」、もしかすると「あなた」だけかもしれません。 
.. そんな、「あなた」だけがための今回の課題は、「ヒープに収まらないテキストを編集したい」です!! 


[課題]ヒープに収まらないテキストを編集したい 


KyoroTextはでっかいデータをノータイムで表示できる事を実現したアプリです。 
なので、KyoroTextで編集するデータはヒープに収まらないデータとなります。 

ヒープに収まらないデータの一部を変更/編集したい場合、どうすればよいでしょうか？ 
KyoroTextでとった方法を解説します。 



[作戦] 
パパパッと思いついた作戦は、以下の２つです。 
  -a 変更したところだけ記録する。 
  -b 内部ストレージを、ヒープであるかのように使用する。適当にキャッシュして、ストレスなく扱えるように調整する。 

「-a」を実現するLogicは直ぐに思いついたのですが、「-b」を、実現するLogicは直ぐに思いつきませんでした。また、応答速度の最悪値が、良く無い場合には、うまく同期させる機能が必要になるかもしれません。 
とりあえず、簡単に実現できそうな、「-a」を実装することにしました。 


[変更点だけ記録する方法] 

  KyoroTextで採用したデータ構造はかなり単純です。 
  以下のような情報を持ったデータをListに記録しているだけです。 
   -「Ｎ行目にデーターを追加した」 
   -「Ｎ行目のデーターを削除した」 

  「テスト」と「UNDO/REDOの実装」が簡単になるように、「追加」「削除」の2つだけにしました。これだけで、編集前と変種後の差分を全て表現できます。例えば、「特定の行のテキストを置換する場合」には、以下のような感じで表せます。 
   1. 置換する行を削除する。 
   2. 置換した後のテキストを、削除した行に追加する。 


これならば、簡単に実現できそうですね!! 


具体的には、以下のような感じになりました。　改善の余地はかなりある。
https://github.com/kyorohiro/KyoroHelloAndroid/tree/master/KyoroCommon/src/info/kyorohiro/helloworld/display/widget/editview/differ


https://github.com/kyorohiro/KyoroHelloAndroid/tree/master/TestForKyoroCommon/src/info/kyorohiro/helloworld/display/widget/editview/differ


[次回のネタ]

  このブログに来る人は、特定のキーワード(APIとかフレームワーク名だとか)をGoogleした人がほとんどみたいです。より多くの人の目にとまるように、特定のキーワードが使って何か書く予定です。
  - SurfaceView上で、InputConnactionを使った簡単なサンプル
  - Robotiumを使った簡単なサンプル
  - JavaのC#への変換ついて、特定のツールの使い方
  - ..
  - .

KyoroText で使用されている技術 その5

[課題] 文字コードを自動認識させる。 


KyoroTexでは、テキストデータを表示/編集するためのツールです。 このテキストデータの扱いの難しところとして、「どの言語」なのか、「どのPFで書かれた」ものか、「どのようなツール」で書かれたデータなのかによって、データ構成が異なります。
例えば、「EUCJP」というルールに従うと、「あ」は 0xA4A2 で表せますが、「SJIS」というルールだと、0x82A0 であらわせます。 


テキストデーターを適切に読み込むには、どのようなルールで書かれたテキストデータなのかを、前もって知っている必要があります。 

しかし、テキストデータには、どのルールで書かれたものなのかが記載されていません。
KyoroTextで、どのようにしてこのルールを判定しているのかを説明します。 


[判定方法] 


  結論から書くと、jcharsetというライブラリを使用しています。「使っていますよ!」 だけだと物足りないので、文字コード(ルール)の判定する仕組みについて、さわりだけ説明します。 

文字コードの判定方法として、以下のような方法が考えられます。 
- a. テキストデータが、特定の文字コードのルールに沿ったものか確認する。 
- b. テキストデータに、含まれるバイトデータの出現率から、適当な文字コードを推測する。 
- c. テキストデータの、テキストの並びの出現率から、適当な文字コードを推測する。 
と行ったものです。 

例えば、日本語だと、改行のまえに、「。」があったり、英語表記と比較して、半角のスペースが少なかったりする。 ISO2022系の文字コードだと、文字の切り替えにESCが使用されると行った特徴を上手く利用して判定するのです。 


KyoroTextでは、自前でこれらの判定モジュールを作成することはあきらめました。　 

KyoroTextで使用しているのは、Mozillaで使用されているchardatのJava版です。 


[参考] 
jchardatのPSMについて解説できたらなと考えていたのですが、PSM(Parallel State Machine)の部分が上手く理解できなかったので、あきらめました。 

もっとjchardatを知りたい方は、以下のページなどを参照してみてください。 

- http://www-archive.mozilla.org/projects/intl/UniversalCharsetDetection.html 
- http://jchardet.sourceforge.net/ 


[次回]
KyoroTextはでっかいデータをノータイムで表示できる事を実現したアプリです。
なので、KyoroTextで編集するデータはヒープに収まらないデータとなります。

メモリーに収まらないデータの一部を編集したい場合、どうすればよいでしょうか？
次回はKyoroTextで実現した解決方法について紹介します。

KyoroText で使用されている技術 その4

[課題] ひとつの画面に複数のテキストを表示したい。 

androidやiPhoneは、WindowsやMacとは異なり、ディスプレイを一つのアプリが専有してしまいます。そのため、テキストを比較したい時には、交互に表示したりしなくてはなりません。WindowsやMACに慣れた方にとって、スマートフォンに対して不満を持つ点ではないでしょうか。 
この問題を解決するために、画面を分割する機能を追加して、同時に複数のテキストを表示できるようにしました。


同時にディスプレイに表示できるのは、本当に一つのアプリだけなのでしょうか。そんな事はないだろうと考えているあなた、その考えは正しいです。残念ながら、使用したことがないので解説できませんが、「Overlay Window android」で、Googleして見てください。実現方法がわかると思います。 



[画面分割] 
画面を分割する方法として、2つ頭に浮かびました。 
  - eclipse的な方法 
  - emacs的な方法 

KyoroTextでは、emacs的な方法を採用しました。いつも、xyzzyというエディタを使用しているせいで、emacs的な方法に愛着があったのが一番の理由です。 
また、実現方法も直に思いついたので、深く検討せずに実装してしまいました。まだまだ洗練されたものでは有りませんが、簡単に構造を紹介します。 


[構造] 
KyoroTextの画面分割には、二分木を使用しています。文章で説明するのは難しいので、直接データーを構造を記述することにします。この方が直感的に理解できると思います。


1. 起動時は以下のようなリスト構造となっています。
[テキストA] 


2. 画面分割にはすると以下のような感じになります。 
[[テキストA, テキストB]] 

- --- A
 |
  --- B

3. さらに、フォーカスがテキストBにある状態で画面分割した場合は、以下のようになります。
[[テキストA, [テキストB,テキストC]]]
- --- A
 |
  --- --- B
     |
      --- C


とても単純ですね!! 簡単に実現できそうです。
後は、この構造に合わせて、UI操作を作れば良いのです。



[登場したクラス]
 Screen#separateScreen(Screen target)



[たぶん次回のネタ]

前回はRobotiumがオヌヌメですよっと宣伝しました。
RobotiumがSeleniumライクに動作させるためにどのような事をしているのか？
で、KyoroText用のテストフレームワークにどのように取り込もうとしているのか？
について、解説します。

KyoroText で使用されている技術 その3

[課題] 自動テストにどのフレームワークを使用しよう? 

作成したプログラムを検証するのに、UnitTestを書くのはもちろんのことです。しかし、加えて、ユーザー操作を必要とするシナリオも自動化したくなるかも知れません。そんな時はどうすれば良いでしょうか? Unitテストでユーザー操作のシナリオも実行できるのでしょうか? 
ユーザー操作が必要なテストは、テスターを雇ってテストを実施してもらうのはどうでしょうか? 個人で趣味で作っているような, アプリでは無理そうですね。でも、一定の品質があることを確認してからリリースしたい。そう思いませんか 

KyoroTextで採用しようとしている方法を紹介します。 


[選択できるカード] 
  そんな時は、自動人形に実施してもらえばよいのです。 今時の携帯端末は、ユーザー操作もUnitテストでかけるのです。 
  - InstrumentationTestCase 
  - Robotium 
  - NativeDriver 
  - MonkeyRunner 
などあります。 

  今回は、「InstrumentationTestCase」「Robotium」「NativeDriver」について、簡単な解説を行った後で、KyoroTextで採用した方法を紹介します。 


[Instrumentation] 
  Androidでは、ユーザー操作をプログラムで書くためのクラスが提供されています。「Robotium」「NativeDriver」もこのクラスを使用しています。 
例えば、 
  - 上下キーを押す。 
  - 画面をタップする。 
といったことができます。 


[Robotium] 
  Selenimという、ホームページをテストするためにツールを参考にしてつるられたテストツールです。Android sdk で 提供されている AndroidInstrumentationTestCaseを使用してテストシナリオをかきます。 
基本は、Android Sdkで提供されている機能を、簡単にラッピングして使い勝手を良くした。のと、SeleniumライクなApiを実現するために、ひと工夫したApiが提供されています。 

[NativeDriver] 
  Seleniumの正当な派生物でありGoogleが提供しているテストツールです。androidだけでなくiOSなどもテストターゲットにはいっています。Selenimとコンパチな開発環境を提供しており。Ruby javascriptなどのJava以外の言語でテストが書けます。 
NativeDriverは、自前のサーバーをandroid上で動作させています。Rubyやjavascriptで書かれたシナリオから送られてくるテキストデーターを逐一解釈してInstrumentationを通してandroidアプリ操作します。 

[NativeDriver と　Robotiumの違い] 
   -　Robotiumは、Seleniumっぽい何かだが、NativeDriverはSeleniumそのもの。 
   -  Robotiumは同一プロセス上で動作しているので、直接テスト対象のアプリのクラスにアクセスできるが、NativeDriverはSeleniumでサポートしている範囲の事のみ、アプリのクラスに直接アクセスできない。 
   -  Robotiumのコードはシンプルで量が少ないが、NaiveDrivermはSelenium化のためのコードが、多くを占めていて、コード量が多い。 




[KyoroText選択] 
KyoroTextでは、Robotiumのコードから使用したいエッセンスを取り出して。自前のテストフレームワークに追加していく方法をとっています。 
NativeDriverが、Seleniumの正当な拡張であり、なおかつ、Android OS を提供しているGoogleから出ているテストフレームワークであることを考えると。 ※ WEBアプリやIOSでも使用できる優れもの!!! 
Robotiumの存在が弱くかじる方がほとんどではないでしょうか。RobotiumにGoogleみたいなモンスター企業がバックにないぞ。大丈夫か?と考えるのが正常な人の判断です。 


私がNativeDriverを選択肢なかったのは、「NativeDriverはSeleniumの正当な派生物であるがために、融通がきかない。」という理由からです。また、Robotiumの方がコードがシンプルで量も少なく、簡単に理解できます。 


でも今後の互換性は大丈夫か、「きちんと最新の環境にすぐに対応してくれるのか?」と不安を覚えるかも知れません。「Google様がなんとかしてくれるはずだ!!」という考え方もあるでしょう。 
または、私のように、「最悪自分で何とかできなきゃダメなんだ」と考えるのもありです。 
どちらも、イケてる判断です。 

※よく、他のブログなどでは、非公開APIを使っているRobotiumの互換性は将来的には不安だ!と情報が流れていたりしますが、NativeDriverも、非公開APIを使用していますよ!! 

Google様がサポートし続けるなんて保証はありません。ならば自分が即座に対応できものを使用しようと考えました。 
ならば、シンプルで、融通がきくRobotiumがだんぜん良さそうです。 

たぶん次回のネタ

 KyoroTextは、画面を無限分割する事ができます。とても便利です。
 どのように実現したのか？分割方法としてどんな候補があったのか？
 紹介します。

KyoroText で使用されている技術 その2

続き....

大きなサイズのファイルをヒープに読み込むのは、時間がかかります。この問題に対処した結果、一部だけ読み込めば良いと考えるに至りました。


[KyoroTextの場合]


KyoroTextに適用した方法を紹介します。
※改善すべき点は多々ありますが、当時だした結論を紹介します。



[問題の整理]

結論だけ紹介するには、少し複雑で説明が難しいです。まずは、何を実現したいのか整理させてください。実現したい事はとても単純でした。
   A) ファイルからテキストを読み込んで、それを、画面に表示したい。
と、いった感じです。
   ※今回は、「ファイルに詠み込む部分」がかなり重たい処理なためひと工夫必要なわけですね。


 もう少し具体的に表現してみましょう。 例えば、「画面を表示担当」と、「ファイルからデータを読み込み担当」を別々に考えるとより理解しやすくなります。

[1] 表示担当は、ファイル担当から表示するデータをもらう。
   |  表示担当　|  -----データーください!!---->　|ファイル担当|

[2] ファイル担当は、データを返す。
   |  表示担当  |　<--------ホラよっと---------  |ファイル担当|

かなり、簡単になりました!!


[KyoroTextの解決方法]

KyoroText採用した方法として、「ホラよっと返すデーター」を直ぐに表示側に渡せない場合には、「Loading....」と、テキストを返すようにしました。これで、どんなに時間がかかっても表示するデーターに困ることがなくなります。

あとは、「ホラよっと、返すデーター」が、なるたけ、ファイルから読み込んだデーターになるように調整すれば良いだけになります。
※指定された行周辺のデーターを、キャッシュしておけば、スムーズに表示できそうですね!!


[登場したクラス]
登場したクラスとメソッドは以下
// 画面にテキストを表示する
Viewer# drawMultiLineText()
    
// 指定された行のデーターを返す。キャッシュがなければ、「Loading....」と、テキストを返す
FileReader#getLine(int index)



[その3のネタ]

では、どのようにして、テキストデーターをキャッシュすると、良い感じになるでしょうか。
いくつかアプローチ方法が考えられます。次回、別の課題として紹介する予定です。
- 知識面の話では、「文字コードごとの可能な戦略について」説明します。
- 話のネタとしては、「KyoroText以外のアプリが採用している方法」「KyoroTextが採用している方法の欠点」について説明します。

つづく..

KyoroText で使用されている技術 その1の次

続き...

[共有メモリから取得]
 Dalvikは、アプリごとに使用しているJavaヒープをカウントしており、一定量以上のヒープを取得できないようになっています。しかし、Nativeヒープにはその制限は適用されていません。
 そこで、Androidで大きめのヒープが必要な場合は、Nativeヒープを取得することが考えられます。
 一つは、native側で mallocしてあげる。一つは、android.os.MemoryFileを使用すると良いです。

[KyoroTextの対処]
 ここまで、説明しておいて何ですが、KyoroTextでは、Nativeヒープを使用する方法は取りませんでした。Javaヒープだけで、済ませていまいます。

その2に続きます。

KyoroText で使用されている技術 その1

 数十回に渡って、KyoroText で使用されている技術について、紹介していきたいと思います。
※ androidとj2seで、自作Editorを作成する方法を紹介します。
    以下ような内容を含んでいます。
      - androidにて、InputConnectionより確定文字、未確定文字、キーイベントを取得する方法
      - j2seにて、未確定文字、確定文字を取得する方法。
  


[はじめに]
  私は今「Kyoro Text」というアプリを作成しています。その際に、「試行錯誤したこと」や、「得たノウハウ」をまとめていきたいと考えています。
  当初、Text Editorという、文字の表示と編集するだけのアプリに、悪戦苦闘するとは、考えていませんでした。
  皆さんも、たかだかEditor程度と思いでしょう。 たかだかEditorと言う認識で正しいのかも知れません。 間違いなのかもしれません。この判断をくだすための材料を提供したいと思います。


[進め方] 
  この文章を読んで頂いている皆様は、多分、androidやJ2SEでEditorを作るのに必要なAPIだとか、その使い方だとかを知りたくてこの文章を読んでいるのではないでしょうか？
残念ながら, あなたのご期待に沿う事は出来ないかも知れません。
  モチロン、apiの使い方にもついて、触れる事は多々あると思います。しかし、apiの使い方をメインに説明しようとは考えてません。
  Editorを作成するにあたり、どのような課題があって、それをどのように克服したのかを説明します。
  残念ながら、優れた対処方法はほとんどありませんが、試行錯誤の結果を物語として楽しんでいただけたらと思います。


[課題一覧]
  - Androidで、PC等で編集したテキストを表示するには、ヒープが足りない。
  - ..
  - ..
  - ..



[課題] Androidで、PC等で編集したテキストを表示するには、ヒープが足りない。

  KyoroTextが対象としていた端末はLowSepcなものが有り。 使用可能なJavaヒープが少ないため、Javaヒープ上にデータをすべて読み込んでから表示する事が困難でした。

  また、Fileから、データを読み込む速度も重要な要素です。 Fileからデータを読み込む速度は高機能を歌っている端末だからといって早いわけではなく。古い型のものの方が早かったりしました。
このため、 最新の端末なのにタカダカ数千キロバイト程度のテキストを読み込むのにカナリ待たされたりする事があるわけです。

  これらの状況をふまえて、ユーザーにストレスを与えないように、即座に画面に表示して上げるようにする必要がありました


[androidのメモリ]

  本当に使えるメモリはそんなに少ないのか?という疑問から解決していきましょう。
 端末には、数メガのヒープを確保してもありあまる程のようりょうがあります。
  これを特別な方法で取得できないのでしょうか?
  結論から言うとデキます。なので、この特殊な方法を使用するという手もあります。

簡単に紹介しましょう。
  - malloc
  - MemoryFile
  - ByteBuffer.alllocateDirect

続く..　中途半端なところで、ごめんなさい!!


[PS]

来年初頭に、KyoroTextの安定版をだす予定です。
そこで、「KyoroTextを紹介するページをつらないとなぁ～」と考えました。
機能の紹介だけだと、平凡な感じがしました。
そこで、KyoroTextを作成するにあたり悪戦苦闘した事を、記事にすることにしまた。

この記事が第一回目となります。
たぶん何度も書き直します。

ショート問題解決 IMEなんかに処理を渡したくない。CTLが押されたら自前で処理したい

KyoroText (自作 Android Editor)ネタです。
来年まとめる予定ですが、こまめに、Android IMEについて情報だししていきます。

* IMEなんかに処理を渡したくない。CTLが押されたら自前で処理したい
 ※ EmacsライクなEditorにしたい場合、IMEがジャマですよね!!

そんな時は、dispatchKeyEventPreIme() で trueを 返すとよい。

ショート問題解決 eclipseでndkアプリをデバック

たぷん、うまくいっていない。メモだけ
※ android-ndk-r8c windows7 
 *  Breakしたところでとまらない
 * ヘッダーとか、いったんEclipseを終了しないと反映されない？

「ショート問題解決　eclipseでndkアプリをデバック」時は、以下をする。

1. Preferences > Android > NDK でパスを設定
2. Android Tools -> Add Native Support
3. AndroidManifest.xmlのDebuggable をtrue
3. 「ndk-build NDK_DEBUG=1」でビルド
4. Debug As--> Native Android Application


[PS]
 そんなにガンバンなくても、Eclipse上で作業が簡潔できるようになった？のかな..。
 良い感じだ。

ショート問題解決 Androidアプリをビルドしている時、「Conversion to Dalvik format failed with error」

ショート問題解決　Androidアプリをビルドしている時、「Conversion to Dalvik format failed with error」と出力されてビルドに失敗する。

そんな時は、
*  「ライブラリとアプリ」のターゲットバージョンをあわせる。
*  eclise -clean とかしてみる。

ショート問題解決 Androidで「node.js」を使ってみたいな

ショート問題解決　Androidで「node.js」を使ってみたいな
と思ったら。

以下のサイトをのぞいてみよう!!

https://github.com/paddybyers/anode/wiki

※ ROOT化不要です!!
※ ちょっと説明不測ですね..。 KyoroPocketNodeJSとして、単体アプリとして、パッケージしたものをGithubにアップする予定です。注意点だとかは、その機会に説明する予定です。

ショート問題解決 「Cannot load library」が表示される

Androidアプリをビルド中に、「Cannot load library」が表示された。
以下のようなエラーがでました。

java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1306]:    37 cannot locate '__gnu_thumb1_case_uqi'...

そんな時は、Application.mkに以下を追加する。

APP_ABI          := armeabi armeabi-v7a

KyoroTextViewerでのISO 2022の扱いについて

KyoroTextViewerが下記機能に対応するにあたり、解決すべき問題を記録しておく。
- ISO 2022への対応
- アラビア語へり対応
※ todo アラビア語は、ここでは書かない。別に書く

[はじめに]

ISO 2022は、文字集合(バイトコードに応じて表示する文字)を入れ替えて表示するため、先頭から順に読み込んでいかなくてはなりません。
※具体的には、以下のような感じで、文字集合を変更するESCが挿入されます。

「こんにちはISO_2022_JP」の場合
<ESC 日本語> こんにちは <ESC ASCII> ISO_2022_JP

 KyoroTextViewerでは、ギガバイトのデータも軽快に表示できることを、目標としているため、
 毎回先頭からテキストを読み込むといったことはなるたけ避けたいと考えています。


[問題/解決]
例えば「改行無しに、数万文字が続くような場合」、毎回先頭から読み込むのと、
画面に表示するまでに時間がかかってしまいます。

そこで、毎回先頭から読み込むのではなく、前もって記録していた文字集合を渡すように
してあげることにしました。

[詳細]

具体的には、(designate) と(invoke) を記録しておく必要があります。
以降、ISO 2022について説明します。

文字集合を切り替えるのに、2つの方法を使用します。
* 文字集合を符号表(C0 GL C1 GR)に指定する(designate) 
*  文字集合をバッフア(G0,G1,G2,G3)にi指定する(invoke) する。その後符号表(C0 GL C1 GR)にわたす。
例)

1. <G0に文字集合を設定する>
2. <GLに対応する文字を変える>

[実現方法]

○ シングルシフトは記録しない。

 - ロッキングシフト

   命令で上書きされるまで、

 - シングルシフト

   1文字だけ

○*->UTF8への変換はJavaのAPIをそのまま利用する。なので、指定されている文字集合の変更だけを記録しておけばよい。

○指定されている文字集合の記録について、汎用的に作るのは断念する。

サポートしたいCharsetのdesignate/invokeを記録するようにする。

※ ISO2022ベースかどうかの判定は、自前でする必要があるため、

    もともと、自分が対応しようとしたものしか対応できない。

[サポート]

  ISO-2022-JP

    #designate:

   G0 

       <ESC ( B>, <ESC ( J>, <ESC $ @>, <ESC $ B>

     <ESC $ ( D>, <ESC $ A>, <ESC $ ( C>

     <ESC $ ( O>, <ESC $ ( P>

     <ESC $ ( Q>, 

   G2

    <ESC . A><ESC . F>

  #invoke

   G2

   <ESC N>;single

 ISO-2022-KR

    #designate:

      G1 

     <ESC $ ) C>

  #invoke

   G0

     <SI>

   G1

     <SO>

ISO-2022-CN

    #designate:

      G1

     <ESC $ ) A>,<ESC $ ) G>,<ESC $ ) E>

   G2

     <ESC $ * H>

   G3

     <ESC $ + I>,<ESC $ + J>,<ESC $ + K>,<ESC $ + L>,<ESC $ + M>

  #invoke

   G0

     <SI>

   G1

     <SO>

   G2

     <ESC N>; single

   G3

     <ESC O>; single

[参照]

http://ja.wikipedia.org/wiki/ISO/IEC_2022

[資料]

符号表
  制御文字(C0)
  印字文字(GL)
  制御文字(C1)

  印字文字(GR)


仮想バッフア
  G0 G1 G2 G3

命令
#designate
 CZD   : C0
 C1D   : C1

 GZD4 : G0
 G1D4 : G1

 G2D4 : G2
 G3D4 : G3

 G1D6 : G1

 G2D6 : G2
 G3D6 : G3
 GZDM4  : G0
 G1DM4  : G1

 G2DM4  : G2
 G3DM4  : G3
 G1DM6  : G1

 G2DM6  : G2
 G3DM6  : G3

 DOCS   : 

 IRR       : 

#invoke
 SI      : GOをGLへ 7bit符号
 LS0   : G0をGLへ  8bit符号
 SO    : G1をGLへ 7bit符号
 LS1   : G1をGLへ  8bit符号
 LS2   : G2をGLへ
 LS3   : G3をGLへ

 LS1R : G1をGRへ  8bit符号
 LS2R : G2をGRへ  8bit符号
 LS3R : G3をGRへ  8bit符号
 SS2   : G2をGL/GRへ 1文字限り
 SS3   : G3をGL/GRへ 1文字限り
 ACS   : アナウンス機能

コーヒー味のフライドポテト

コーヒー味のフライドポテトとは..

言語/論理化できないことがほとんどです。
-1 言語化してようしている、その変換処理を言語化する
-2 言語化してようしている、その変換元を、変換せずに言語化する
-3 ふと思いたる発想について、その発想にいたるゆえんを言語化する

1)2)3)を何かしらの方法で、表現した、表現しようとしたならば、「コーヒー味のフライドポテト」とラベルをつけることにしています。

焼きトマト

焼きトマトとは..

理解を深めるためには、手を動かしてみるのが一番のようです。
 1.  プログラムのリファレンスをReadして、仕様を調べるより、リファレンスの通り動くか試してみる。
 2.  本を読んで知識を吸収するより、本に書いてあることを実践みる。
 3.  ふと頭に浮かんだ アイデアについて考えるより、実際に実現してみる。

1)2)3)について、実現したこと、実現しようとしていることについて、
書いたならば、「焼きトマト」とラベルをつけることにしています。

戦うヨーグルト

戦うヨーグルトとは..

今を可視化することについて、色々考えています。
 1. リアルタイムに情報を集めて都度表示する。
 2. リアルタイムに情報を集めて都度解析する。
 3. なるたけ、中央サーバーを中継しないで、個々アプリで情報を共有する。


5年前、5年後の世界について、私は 1) 2) 3) を満たすような自動機械が、一般的になっていると思っていました。
しかし、あれから5年たった2012年は、そんな風にはなっていないようです。


1)2)3)を実現した世界、実現する方法について、思いをはせしたことを、
書いたならば、「戦うヨーグルト」とラベルをつけることにしています。

はじめての Blogger

こんにちは Blogger !!