法務ネット　Ｑ＆Ａ

朝は美魔女がいなかった。“””

我が家のグレンケアンが2個になりました。嫁さんが加賀梅酒にハマっているのですが、これで飲むのが美味しいみたい。食後に夫婦でグラス傾けて次男の教育であーでもない、こーでもないと語ってます。“””

出勤前に犬走りの雑草ひき。一夏放っておいたので大漁。“””

今から午後一の法廷に出るために新幹線です。今回はちゃんと乗る前におにぎり買いました。1個108円なので妥当。“””

Unityを始めました。独特の流儀が多いのですが、普段組み込みばかりやっていると新鮮ですね。オブジェクトのキューが組み込み型にあるという時点で感動しています。さてプログラムを作成していて、あるメソッドで値を代入したクラスのローカル変数が、他のメソッドから参照できない、というか見れるけれども初期値になっていて代入の結果が反映されていないという問題が発生しました。何じゃそりゃと悩んでいたのですが、原因は極基本的な所にありました。バグの解析の最中にその変数をStaticにすると他のメソッドからも参照できたのですが、「ローカル変数なんだからstaticにしようがしまいが関係無いはずでしょ」とうんうん悩んでました。ただこれも分かってみると納得。作業としては、Unityでユーティリティアプリを作ろうとしていて、画面の描画されるオブジェクトとは関係無く一定のロジックを回したいので、HierarchyにEmpty Objectを作り、そこにC#スクリプト(Main.cs)をアタッチしてロジックを作っていました。このスクリプト（クラス）のあるメソッドでローカル変数を設定したら、Main.csの同じクラス内のローカル変数から見られないという状態になっていたのです。原因は、GUIに設定したボタンへのスクリプトのアタッチでした。UIのボタンが押されたときに簡単に処理できるように、そのボタンにもMain.csをアタッチしていました。こうするとボタンのクリックイベントからMain.csのメソッドを呼べるので簡単だろうという判断からです。が、これが間違いの始まりでした。オブジェクトにアタッチされたクラスは、それぞれのアタッチ先のオブジェクト毎にインスタンス化されるので、Empty Objectとボタンにそれぞれアタッチされたスクリプトで、別のインスタンスが生成されていることが分かりました。まだGameObjectの仕組みをあまり理解できていないのですが、概ねそんなところだと理解しています。試しに新しいプロジェクトで以下のスクリプトをEmptyとボタン２個にそれぞれアタッチしたところ、それぞれのインスタンス他それぞれStart()を実行し、自分のアタッチ先のGameObject名を出力しました。staticな変数が２個目のインスタンスでは初期化されないことも確認でき、２個目のインスタンスのstart()ではその前のインスタンスで設定された内容が表示されます。インスタンスが３つあるのでUpdateも別々に回っていて、それぞれがDebug.logを実行しています。publicにしたプロパティはインスペクター上でそれぞれ違う値を設定でき、その値が動作に反映されました。

using UnityEngine;using System.Collections;public class Main : MonoBehaviour {"

	

僕の本（ホームページ？）をみたＭさんという方から以下の質問をいただきました。初心者の方で同様の疑問を抱く方がいらっしゃるかも知れないと思いましたので、回答を公開しておきたいと思います。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝始めまして。お世話になります。 電子回路初心者です。東京コスモスのＴＷＥ-Lite　Dipの出力（4mA以下？)をフォトカプラでON/OFFしたく、TLP521-4を購入したのですが、データシートではIFが50ｍAとなっております。管理者様の回路図を見ると3.3Vで680Ω＝約5ｍAになると思いますが、このTLP521は最低、何ｍAから確実な動作が出来るのでしょうか？私がデータシートの素人読み込みで50ｍA必要と思い込んでいたのでしょうか？仮に、5ｍAでもOKなら2～3ｍAでもいけますか？宜しくお願いいたします。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝Ｍさん、こんにちは。正直なところアナログ回路はあまり得意では無いのですが、わかる範囲で回答をさせていただきます。ご質問の件については、基準と視点を変えることが必要だと思います。ＴＬＰ５２１の「５０ｍＡ」という数字は、「絶対定格」に記載されている電流だと思います。絶対定格は、素子の動作条件ではなく、その素子の使用条件として、「絶対に超えてはいけない条件」を意味します。この条件を超えてしまったときには、その素子が壊れるかも知れないし、もしかすると発火して家を焼くかも知れない、そうなってもメーカーとしては知らないよ、責任持てません、という意味で「絶対」なのです。５０ｍＡちょうどであれば、いちおう絶対定格の範囲内ではあります。ただ、電源電圧が変動したり、電流制限抵抗の値が温度で変動したり、内部のＬＥＤのＶＦのばらつきなどにより、いつこの絶対定格を超えてしまうかわかりません。ですので、設計をするときには、不確定要因の変更を見込んだ上で、「絶対」に「絶対定格」を超えない電圧や電流を設定します。次にＬＥＤに何ｍＡ流したらよいのかということですが、これは「Ｍさんで無いとわからない」というのが結論になります。というのも、フォトカプラのＬＥＤに何ｍＡ流したらいいかは、フォトカプラのトランジスタに何ｍＡ流したいかで決まるからです。フォトカプラを使うということは、トランジスタでスイッチングしたい回路がその先にあるのだと思います。それはどういった回路でしょうか。通常のＬＥＤであれば数ｍＡでしょう。デジタル系でプルアップ抵抗につなげるだけなら１ｍＡいかでしょうね。フォトカプラのトランジスタ側は、フォトトランジスタであるとはいえ、振る舞いはトランジスタなので、ベース電流の代わりである、受光量に応じて、コレクタからエミッタに流れる電流が変わります。つまり流したい電流に応じて、ＬＥＤの発光量を変えるということです。ＴＬＰ５２１のデータシートの後ろの方を見てもらうと、縦軸がコレクタ電流、横軸が入力電流になっているグラフがあると思います。性能の悪いサンプルＢで考えるとして、コレクタ電流に１０ｍＡ流したいのであれば、入力電流として１０ｍＡぐらいが必要なのがわかります。コレクタ電流として１ｍＡぐらいが欲しいのであれば、入力電流としては３ｍＡぐらいあれば十分でしょうね。ちなみにですが、このデータシートからすると、ＴＬＰ５２１のコレクタ電流は、絶対定格も考えると、３０ｍＡぐらいが限界という感じがします。だんだんカーブが緩やかになって、入力電流を増やしてもコレクタ電流を増やせなくなってますね。ですので、もし、もっとコレクタ電流を流したいという状況なのであれば、後ろに更にトランジスタをつなげるとか、最初からダーリントン出力のフォトカプラを使うといった工夫が必要になるでしょう。そうすれば発光側への入力電流も減らせますから、ＴＷＥの負担も小さくなります。

MSDNのTCP非同期サーバーのサンプルコードをUnity上で動かそうと移植していたら、Unity自体が固まって強制終了せざるを得なくなるという現象が発生。ロジックを追っていくとまずwhileの無限ループがあると固まることが判明。開発環境上でPlayするときはアプリは別スレッドで動かしてくれたらいいのにと思うのですが。何か理由があるんでしょうかね。でwhileを抜いて実行してみてもやっぱり固まる。今度はManualResetEventでWaitOneしているときに固まることが判明。もちろんSetされたら復活するのですが、その間停止するのはアプリとして問題ですから使わない方がいいですね。今回のコードではManualResetEvent自体が不要そうなので丸ごと消しましたが、どうしても必要な場合はスレッドを作った方が良さそうです。

public static ManualResetEvent allDone = new ManualResetEvent(false);// Set the event to nonsignaled state.allDone.Reset();// Wait until a connection is made before continuing.allDone.WaitOne();// Signal the main thread to continue.allDone.Set();

“””

仰々しいタイトルですが、要は同期+スレッドと非同期のどちらがいいのかという話しです。「C#でTCPサーバーの実装を作ったよ」というレポートはかなり多くて、www.codeproject.comなんかで検索すると１０件近く出てきます。日本語の情報もいくつかあり、チュートリアル的な情報では、まずは同期式で勉強してから非同期でという流れが多いですね。Unityを始めてまず「オンラインゲームのしくみ」を読んだのですが、この本の場合は非同期で作るのは大変だから同期でつくろうよというスタンス。この本のライブラリを使ってコーディングを始めたのですが、このライブラリが複数接続に対応しておらず、結局作り直しになりました。で、色々と見て回ったところ同期ベースか非同期ベースかというところで大きく分かれているので、自分はどちらでいこうかと迷い、メリット・デメリットを検討してみました。で、同期の方のメリットは、結局、スレッドプログラミングになれている場合には、プログラムの構造がわかりやすい、つまり書きやすいというところに尽きるようで、他のメリットは見あたりませんでした。僕の場合、マルチスレッドは使ったことが無いのであまりメリットは感じられず、スレッドがメモリを食う、オーバーヘッドが大きいというデメリットの方が大きく感じました。サンプルコードを見ていると、非同期式でもそれほど複雑なプログラムにはならなさそうなので、非同期で実験してみることにしました。で、MSDNのサンプルコードを使ってUnity上でTCPサーバーを非同期で実行するためのサンプルがこちら。いわゆるチャットサーバーですね。いくつかはまりポイントがまたありましたが、概ねスムーズに書けました。ncコマンドで複数の端末から接続すると、それぞれに固有番号を振った上で、ある端末のメッセージが全端末に送信されます。接続切断はまだ未実装です。ちょっと困ったなと思うのはどうにもコードが肥大する感じで見にくいです。クラス化しようかと思ったのですが、コールバックはビジネスロジック側で実装しないと意味が無くて、サイズを取っているのがコールバックなので、クラスにしてもあまり意味が無い感じがしました。デリゲートで作れるとは思うのですが、このあたりはまだ慣れていないので余力があれば書こうと思います。

// There could be Copyright (c) of Microsoft and Yasuo Kawachi// If there is， this code is licensed under Microsoft Limited Public License// https://msdn.microsoft.com/en-US/cc300389 See ""Exhibit B""// I belive there is no copyright due to non creativityusing UnityEngine;using System.Collections;using System;using System.Net;using System.Net.Sockets;using System.Text;using System.Threading;using System.Collections.Generic;public class Main : MonoBehaviour {"

このサイトのメールフォームはContact Form 7を使用しています。導入した直後からスパムが送られてきたのでReally Simple CAPTCHAを組み合わせて使っていました。が、ここ数日このキャプチャを乗り越えてくるスパムが続発。体裁が同じなので同じボットだと思います。某調査によればアルファベットのキャプチャはOCRを使って「人間よりも高い精度」で読み取り可能らしいので、仕方ないですね。で、こちらのサイトさんの手順を参考にして、認証をキャプチャからクイズに変更しました。アホらしい質問ですが、これに答えられるボットはそうそういないでしょうから、しばらくはこれで耐えられるのではないかと思います。”””

CH340/CH341を使用したUSB-シリアルチップを使用したかったので、公式サイトから、CH341SER_MAC.ZIPをダウンロードしてきました。各所で配布されているようですが、公式からでないとなんか不安ですね。セキュリティ許可が必要というのはマニュアルにも書いてあるのですが（中国語のＰＤＦ）、Yosemiteだとこちらにあるように、ターミナルからsudo nvram boot-args=””kext-dev-mode=1″”の実行が必要でした。再起動も必須のようです。”””