ビジュアルプログラミングの先へ

巷ではビジュアルプログラミングが話題になっている。すごくいいと思う。

Web方面は非常にがんばっているなぁ。

双方向という言葉でハッとしたが、昔C言語で30日OS開発したことや他の言語でGUIを開発して行くうちに双方向でプログラミングしたいと思うようになったのを思い出した。

という一方向だけでは足りなくて、UIを変更するならばUIの方からも変更を行いたいとずっと思っていた。 色とか変更するのはUIから右クリックして変更したい。 UIだけではなくロジックも書き換えたい。 それも動いているソフトウェア上で書き換えたい。 SmallTalkでは上記が可能だった。よしやるか!と思って2ヶ月。停滞中。頑張りたい。 ちなみに基礎を勉強するならこれがおすすめ。相当前の書籍だけど内容は色褪せない。公開ありがとうございます。 swikis.ddo.jp そういえばIoT機器を操作したいんだけど組み込み機器用Smalltalkはないのかな?SmallTalk環境から遠隔でIoT機器を書き換えたい。SmallTalk言語で。

あと、ソフトウェアの動作中に書き換えて変更することを hot swapping と言うらしい。 日本語Wikipediaには活線挿抜の情報しかなかった。
Hot swapping - Wikipedia

Only a few programming languages support hot swapping natively, including Pike, Lisp, Erlang, Smalltalk, Visual Basic 6 (Not VB.net), Java and most recently Elm and Elixir. Microsoft Visual Studio supports a kind of hot swapping called Edit and Continue, which is supported by C#, VB.NET and C/C++ when running under a debugger.

つまり以下の言語はhot swapping あり

他の言語もっと頑張れ。 全体的なニーズはないのかもしれんが、個人的に非常に欲しい。Visual StudioC/C++でどうやっているんだ。デバッグ時だけじゃなく標準化してくれ。

ユーザーが動作を双方向で書き換えられるようになってほしい。動作させながら自分専用にバージョンアップしたい。 IoTなどの組み込み機器に接続して再プログラミングしたい。 UIの方から書き換えるのはビジュアルプログラミングとはちょっと違うかもしれないけど、その先はそうであって欲しい。


話は変わるが、私は普段ソフトウェア開発で様々な開発をしている。がなぜかときどき工場へ行って自動化の様子を見る機会がある。今では当たり前の光景だが初めて見たときに非常に驚いたことが、PLC(プログラマブルロジックコントローラー)によるラダー言語が圧倒的に自動化の中心にいることだった。

ラダー・ロジック - Wikipedia

工場のどんなロジックを変えるにもPLCのラダー屋さんにお願いする必要があって色々変更してもらうのだけれど、端からみるとものすごく変更が面倒くさい。まずラダー言語自体が面倒くさい。ロジックが全て並列に動いてるから混乱する。脳内メモリ足りなくなるわ。(ラダーの人ごめんなさい。でもこれ触れるなんてすごい。小並感) また、データを保存するメモリ番地を決めてラダーを書き換えて実際に動かす→悪かったらもう一度やり直し。という爆弾処理のような変更とデバッグをしている。ラダーが特殊すぎてバグ取りに時間もかかる。テスト駆動開発なんてできない。 なぜこの大昔から使われているラダー言語が未だに幅を利かせているのかと思っていたけど、以下のメリットがものすごかった。

  1. PCとPLCをつなげて同期するだけで内部メモリの情報変化をリアルタイム可視化可能
  2. ラダー表示画面上でも、リアルタイムにロジック動作が見える
  3. プログラムを動かしたまま、内容を書き換えるRUN中書き込み対応 (hot swapping)
  4. PLCリンク/CCLink(IE) の規格により通信による他機器との連携が非常に楽
  5. タッチパネルと連携し、GUI追加とメモリとの紐付けも非常に簡単(なように見えた)
  6. 安定性や信頼性がバツグン。何年放置してても不可解な現象がない

可視化は正義。ラダー言語はビジュアルプログラミングの一つの到達点だと思う。 また、最後の安定性に関しては、2020年現在でもWindowsLinuxは不明な現象が発生し再起動の必要があるため、末端としてしか扱われていない。中心は常にPLC。 そもそも組み込みLinuxなのに起動に失敗するときもあったのには驚いた。 過酷かつ失敗の許されない環境では、PLC+ラダー言語に勝るものはないのかもしれない。 他の言語でできないのかと考えたこともあるけど、知れば知るほど そりゃ替えられないわ と思い知らされた。


今後、プログラミングが進化していくならば、このラダー言語レベルの情報可視化と変更の簡易化が必要だと思う。ビジュアルプログラミング+αが必須だと思う。
近い将来、VRやARで直接内部情報をプログラミングする時が来るはず。というか来て欲しい。みんなで作ろう。 組み込みやIoT、VR/AR/MRをやるならば、機器につながったら簡単に内部を閲覧変更できるようにしたい。 GDB では足りない。既存の言語環境もまだまだ足りない。SmallTalkはあとちょっと足りない。新しい開発環境が必要なんだと思う。

まとめとして、ビジュアルプログラミングの先はこんなプログラミング開発環境が欲しい

  • ソースコードとUIからの双方向プログラミング
  • ソフトウェアの hot swapping 対応
  • 状態のリアルタイム可視化
  • オブジェクトや他機器との通信簡易化
  • デバッグ容易性

歯科の虫歯予防教室

開発と全く関係ないけど歯医者で素敵な講義をしてくれたので忘備録として

予防に大事なことは以下の3つ

  1. はみがき
  2. フッ素
  3. 食事

___________________________

はみがき

CMなどでは毛先はギザギザになっている歯ブラシがあるがあれはダメ。普通の平らでちゃんと列になっているのが一番良い。
歯科はああいう歯ブラシを推薦していない。普通のが一番。一番奥を磨くために少々形状が異なるものがあるが、あれは他のところが磨けない。
(これ以前にも実は歯磨き講習があった。歯ブラシ端の1列を歯と歯茎の間にいれて、歯1本ずつふんわり5秒ほど前後に動かす。こすらないことがコツ?毛先が歯茎をこすらないよう、当てて揺らす感じと教わった。)
歯ブラシは1本100円ほど。これを1カ月に一回交換。

歯磨き粉は、LIONのCheck upがよい?

ライオン チェックアップ スタンダード 120g【医薬部外品】

ライオン チェックアップ スタンダード 120g【医薬部外品】

市販のものはミントの香りを強くし、かつ泡が出るものが売れるが本来はそうじゃなくてもよい。これは歯科用でフッ素の量が書いてある。
磨きおわって歯磨き粉をゆすぐときは少ない水でOK。ミントの香りが完全になくなるくらいまでゆすいだらフッ素がなくなる。
気持ち歯磨き粉の泡が半分くらいになる程度。20ml?50ml? どちらか忘れたがそのくらいの水でゆすぐ。後は残す

電動歯磨きもあるが、これはきちんと歯の磨き方がわかっている人が前後することを楽にするために使うもの。
2000-3000円のものは逆効果なので無駄。買うなら1万円のもの。フィリップスの2万円以上のものはやっぱり良い。

フッ素

歯磨きの予防にフッ素大事。LIONのCheck upのジェルを使いましょう。

ライオン チェックアップジェル ミント 60g

ライオン チェックアップジェル ミント 60g

日本は虫歯予防後進国。アメリカ・カナダ・その他(わすれた)などは水道水にフッ素が入っている。
日本も一時期、宝塚でフッ素入りの水道水を試験導入したが、あそこは六甲の水?でもともとフッ素濃度が高い。それなのにフッ素を追加したために病気(名称わからんかった)になって訴えられた。そこから全く導入が進んでいない。
アメリカなどで導入が進んでいるのは、推測だが医療費が高すぎるから。平気で10万20万飛んでいく。水道水にフッ素を入れだして歯科の医療費が劇的に下がったとか。

日本は自分でフッ素を利用した予防をすることが大事。フッ素は再石灰化を促す。

食事

唾液は弱酸性。通常は口内も同じく弱酸性。しかし食事開始3分ぐらいで口の中は酸性になり、この時に歯が溶ける(脱灰)。しかし、食事が終わるとたくさん唾液が出て弱酸性に戻る。この戻った時に唾液中のカルシウムやリンなどが歯を戻している(再石灰化)。
上記のため、延々と間食をすると口内が常に酸性になるためどんどん歯が溶けていく。会社などで30年間ずっとそのような生活の人は虫歯だらけ。子供も虫歯だらけの子がいた。その親は哺乳瓶にジュースをいれて飲ませていた。静かになって手も煩わせず、親にとってはものすごい楽だが、歯科にとっては最悪。常に口の中が酸性となって、乳歯の前歯が根元からなかった。
間食は、お茶、コーヒーならブラック。紅茶なら砂糖を入れないままが良い。スポーツドリンクは糖分が多すぎる。ノンシュガーをうたっているいるものもあるが、コンマ何%以下はノンシュガーと表示してよいなどがあり、実際は糖分が存在するため気を付けること。
キシリトールガムは良い。安くなるボトルで買うとよい。

なるべく再石灰化の時間が長くなるように生活すること。
この食事の部分は、全く注意していない人が多い。

___________________________

なるべく、早期検診に来てほしい。地方自治体によって値段は変動するが一回3000円ほど。歯のエステくらいの感覚で!
痛くなってからくるよりも楽。年2,3回来てほしい。高いと感じるかもしれないが、治療の値段より安い。
実は治療をしたくない、できるだけ予防に力を入れたい。

入れ歯になると費用は一個25万円。上下で50万。食べたものの味もわからなくなるらしい。
インプラントになると一本30万。全部で500万かかる人もいる。
それよりかは予防に力を入れたほうが将来何百万か浮く。

現在、QOL (Quality Of Life) に力を入れている。80歳で歯がない人よりも、歯がある人の方が若く見える。歯がなくなると骨が細くなり顎が小さくなってほうれい線が目立つ。痴呆症もすすむという研究もあるようだ。

これから予防をがんばりましょう。


というような話をしてくれた。
この後、歯磨き粉とフッ素ジェルと歯ブラシの購入を勧められた。ものすごく欲しくなったがここで買うと今後衝動買いがひどくなりそうなのでとりあえずお断りしたw なんちゃら商法みたいだったw(医者だから全く問題ない正しい商売なんだろうが・・・)

言っていることは理に適って信用できると感じたので、これからもここに通おうと思う。

手回し昇降式スタンディングデスク(SKARSTA)を購入

PCを触るのに座ったままだと健康に悪い気がしたので
IKEAの手回しで高さを上下できるスタンディングデスクを購入

www.ikea.com

約2万円なり
一回り大きいものだと2.7万円ほど。

電動式だと、日本のIKEAでは売ってない・・・
日本で発売しているメーカーの電動式だと15万-30万円。さすがにそこまで出せないなぁと考えていたら、なんと手回し式が売ってた。

どうせ、健康のために立つんだし、手回し式でちょっとした運動も兼ねるんだったらこっちでいいや、ということで購入。

電動じゃなくても非常に快適。

PCを触るために部屋に行って、わざわざ座らなくてはいけないことからも解放。
固定式ではないので、自分に合った高さを微妙に上下できるのもGOOD
いい買い物をしたと思う。

C#で大量データを高速表示するChartライブラリ

MSChartでは描画速度が遅すぎる...
5000データで違和感が出始め、10000でバグクラスの遅延となる。

今まではMSChartの設定(FastLine等)で高速化しようとしていたが、
ようやく高速な描画速度のライブラリを探そう!ということに思い至ったので、記述

以下、全部有料。
無料なものは探したけど見つけることが出来なかったorz

Windows Formの場合のライブラリ候補

  • Lightning Chart
  • Measurement Studio

WPF の場合

  • SciChart
  • Visiblox

説明

描画速度がMSChartと違いどれも圧倒的に早かった。
Windows Formの場合、Lightning Chartは描画速度にバラつき発生。Measurement Studioのほうが高速かつ安定?
15万データの折れ線グラフ描画速度。

  • Lightning Chart : 30 ~ 300 [ms]
  • Measurement Studio : 20 ~ 40 [ms]

WPFはどっちでもOK。
WPF Charting Performance Comparisons (the Battle Continues)

追記
MSChart の描画速度 : 300 ~ 10,000 [ms]
断然に遅いのが難点...

大量のデータをMSChartを使用して表示するときの描画時間が遅い

C#のFormアプリケーションで5000ほどのデータをChartで描画すると重い時と重くない時があったので忘備録として記述

AddXY()を利用して面グラフと折れ線グラフの2種類のデータを描画していた。
5000のデータを描画するとものすごい遅い。開発用のPCだと実は軽かったが、テスト用のウルトラモバイルPC等で描画すると10分ぐらい描画が止まる。
UIスレッドのReflesh()自体に相当負荷がかかるみたいで使いものにならない。
また、マウスオーバーで出現するツールチップを入れているとものすごく重い。

原因

原因は面グラフとツールチップ。2つが組み合わさる場合の面グラフの描画がものすごく重い。折れ線グラフの7倍ほどだった。
以下秒数

面グラフ

1.2 sec

折れ線グラフ

0.17 sec

ツールチップがない場合

面グラフ

0.0220167 sec

折れ線グラフ

0.1098249 sec


これは、同時描画数に関係ない。5000個データが有る内、10を描画しても重くなる。
(もちろん同時描画数が多くなればなるほど重くもなる。)

ということで解決策は

  • 面グラフを描画するかしないかの選択UIを作成する。
  • 面グラフを諦める
  • 他にスライドバーを設置し、描画範囲を指定する。

となると思う。


追記

      • -

処理時間はバージョンによって変動する場合があるので正確な時間計測が何よりも大事。
C#での時間計測のオススメ記述法は以下のサイトを参考。
これ以上のものに今は出会ってない。

C# デバッグ時の処理時間測定ロジックを簡潔に書く | Try&Error テクニカルブログ

Formのフォントを変更するとFormのサイズも変更される問題

FormプロパティのAutoScaleModeがデフォルトでFontであるため、[MS UI Gothic]から[Meiryo UI]等にFontを変更するとForm全体のサイズが大きくなる

f:id:sechs:20140723135738p:plain

f:id:sechs:20140723135739p:plain

図のサイズが圧縮表示されているorz

よって以下の順番が望ましい

  1. Formを選択
  2. プロパティより AutoScaleMode を Noneに変更
  3. Fontを変更
  4. プロパティの AutoScaleMode をFontへ戻す

Excelで名前の定義をしてその部分のみ塗りつぶす方法

世の中にはExcelで名前を定義した後、その範囲をひと目でわかるようにしたいという人もいるはず。

条件付き書式を使用し、簡単に実行できた。

条件付き書式の数式

=TRUE

条件に一致するときのセルの書式

(背景色の指定など、セルの書式を自由に変更)

適用先

=(定義された名前)

これだけ。


以下、詳しい手順(例:Excel 2007)

1. "数式"タブで名前の定義

  • A1:A10の範囲を"範囲1"という名前にする

2. "ホーム"タブ - スタイル - 条件付き書式 - ルールの管理 を選択

3. 新規ルール - 数式を使用して、"書式設定するセルを決定"を選択し、入力

  • "次の数式を満たす場合に値を書式設定" の欄に以下を入力

    =TRUE

  • "書式" ボタン - 塗りつぶしタブ より背景色を赤に設定

4. ルール一覧画面で、適用先を設定

=範囲1

適用先が自動的に"=$A$1:$A:$10"と変更されるが、これは挿入や、削除を行うと自動変更されたので心配なし。