C

まずは簡単に props.errors で降りてきた文字列を表示するだけの componentを作る。 import * as React from "react"; interface Props {     errors: string } interface State { } export default class Error extends React.Component<Props, State> {     constructor(props: Props) {         super(props);     }     public render() {         return <h3>{this.props.errors}</h3>;     } } 上を題材にJestの初歩を勉強する。以下、Jestに動かしてもらう Unit Test を作る。Unit Test 自体も TypeScript で書いてみることにする。以下、error.test.tsx: import * as React from "react"; import Errors from "../components/error"; import * as ReactTestRenderer from 'react-test-renderer'; test('test error component', () => {     const errorMessage = "hello world!"     const rendered = ReactTestRenderer.create(         <Errors errors={errorMessage} />     );     const ren...

こちらは実に簡単で、VS Codeがうまいこと処理してくれる。 左のツールバーから Debug （虫アイコン）をクリック。 上部のギア・アイコン(Open launch.json) をクリック。 初期値をセットしてくれているが、これと別に以下を追加： { "type" : "node" , "request" : "launch" , "name" : "Jest Tests" , "program" : "${workspaceRoot} \\ node_modules \\ jest \\ bin \\ jest.js" , "args" : [ "--runInBand" ], "internalConsoleOptions" : "openOnSessionStart" , "outFiles" : [ "${workspaceRoot}/dist/**/*" ] } 上をセーブし、上部のドロップダウンから "Jest Test" を選択。 左上のDEBUG をクリックして開始。 これだけ。きちんとdebugger; のところでブレークしてくれる。CLIでの苦闘が嘘のようであるが、人生無駄なものは無し、と日記には書いておこう。 なお、Break時からContinueする際のショートカットにはF8ではなく、F5がアサインされている。これを変更したい場合は、MenuのFileから　Preferences | Keyboard Shortcuts で Continue を検索するかスクロールしてロケートし、左のエディットアイコンをクリック、F8を押してからリターンキー。

React が大分わかってきた（ような気がする）ので、Unit Test に進んでみる。またまた忍び難き道を忍ばねばならなかった。以下、備忘録。この世界も jasmine だとかなんだとか、あまりに選択肢が多く目が回るが、とりあえず Jest を勉強してみようと判断。 [Jest のインストール] 以下の要領でいたって簡単。      https://facebook.github.io/jest/docs/en/getting-started.html#content CLI のどこからでも jest と叩きたいので、グローバルにもインストールした。     npm install -g jest [初期動作確認] 上のサイトの要領に従って sum のテストを実施。すんなり動作した。さほどの感激は無し。 --- ここからが実務となり、厚い壁がはだかっているのは既にわかっている。C#でも Unit Test を書くのは、普通にコードを書くのと同じぐらい大変な作業だが、プログラマのライフセーバーとも言えるので、堪えどころ。 まず、私の書く Unit Test自体にバグが発生することが分かっている。これを詳細にデバッグできないと全くお話にならない。まずはここらから検証。 [Unit Test のデバッグ] 暫し調べると、やはり本家のここにたどり着いた：      https://facebook.github.io/jest/docs/en/troubleshooting.html#content 要は、Node上で Jest.js が走り、そこから私の書いた sum.test.js が走るわけだが、Node が web server を立ててくれ、そこに Chrome からアクセスし、Chromeの F12 で Just 向けに書いた Unit Test スクリプトをデバッグ可能、というわけだ。Nodeは偉い。早速 CLI にて：    node --inspect -brk node_modules/.bin/jest --runInBand やはり、さっぱり動作しない（涙）。結論から申すと、４つの問題が上の短い一行に...

React には色々と感心・得心させられ、実に面白い。日本のReactを取り扱ったサイト群では、哲学という単語を使っているところもあるが、むしろ、道（どう）、というのが相応しいかと思う。武士道とか柔道の道（どう）。私がまず最初に感心したのは、Document道である。実にプレインな英語だけで、どうやってこれほど技術屋の心を擽ることができるものか。 https://reactjs.org/docs/hello-world.html この分かりやすさが、英語ネイティブではない各国のプログラマたちをも惹きつけている要因の一つではないかと思う。それが理由なのか、驚くことに日本語の翻訳サイトが存在しないのですな。 さて、以下は無論翻訳を狙ったものでは無く、上 Hellow World サイトにて、私なりに感じた重要点やReact道の備忘録。 [Component and Props] 呼ぶ側のコンポーネントから流れてくる props は、リード・オンリー。編集してはいけない。propsは、親コンポーネントから子、孫、ひ孫・・・へ、変数や関数を上から下にむかって一方向で流し込む。“top-down” または “unidirectional” data flow と呼ばれる React道のひとつ。 [State and Lifecycle] state は特殊なローカル変数であり、他のコンポーネント視点では、本コンポーネントが stateful なのか stateless なのかは全く興味の外、これもReact道のひとつ。 this.state={abc: "def"} のように直接セットできるのは constructor 内のみで許され、それ以外はダメ。必ず this.setState({comment: 'Hello'}); this.state は非同期処理されるので setState()しても即座には変化しない。変化した後に処理が必要な場合は、callback を指定できる。 // ダメな例 this . setState ( { counter : this . state . counter + this . props . increment , } ) ; // ...

Chrome F12でデバッグ中に、しばしば map （高）レベルのソース表示と、生JSレベルの実態がずれる事がある。これを解決せしめるには、F12画面で単に ALT+R キーを押せばよい。map ファイル自体は、既にきちんとロードされているので、HTTP reqestは発生しない。殆どバグだと思うし、pull が出ているようだが、現時点 (Nov/17) では未解決。以下参照： https://github.com/webpack/webpack/issues/2478

Entity Framework にて POCO で書いている場合、Json シリアライズはあまりにも簡単であり、POCOの威力を見ることになるが、DevExpress XPO の XPBaseObject は、そのままではSerialise できない。とはいえ、これを実現するには、さほどの手間はかからない。POCOに比べると、コードが少々汚れることはやむを得ず。 XPOのシリアライズ（その逆）には以下の処理を施さねばならない。 Deserialize、すなわちXPBaseObject の生成の際に、Session を渡したい場合（多くの場合そうであろう）、引数付きの constructor に Session (UnitOfWork) を渡さねばならない。ちなみに、この処理を実施しないと、XpoDefault.Session が使用される。 他クラスの object をReferenceしている property の処理。 XPOCollection の処理。 まずは、上の処理で作成した作品達を使う側の例：         [TestMethod()]         public void SerialiseWf()         {             TestHelper.ConnectToDataSource("UK Test");             ManagedUnitOfWork uow = TestHelper.uow; // 単なるUnitOfWork と読んでください             Enquiry en = uow.GetObjectByKey<Enquiry>(6915);             var settings = new JsonSerializerSettings()     ...

Azure で動作するアプリやAPI の開発者であれば、当然 Azure 上にそれら resources を deploy し、動作試験・負荷試験をすることになる。Microsoft は、こうしたケースに便宜を図ってくれており、Virtual Machine や App Service 等々を４割程安い金額で使用できる。 この便宜を利用するのは簡単で、Pay-As-You-Go Dev/Test という種別の subscription を作成し 、その配下に各リソースを普通に配置するが、size の選択の際に表示される料金が、Pay-As-You-Go よりも安価であることがわかる。 また、VM上でMS系のソフトウェア(SQL等々）を無料で使用することができる。 Hybrid Benefit  と同じ料金、と言い換えてもよい。 本 subscription を作成できる条件は、利用者が Visual Studio Team Server のアカウントを保持していることだが、無料サービス（５名以下）アカウントも対象である。また、使用目的が開発・テストに限定、とされている。

この歳（五十半ば）になって初めてMACを勉強することなったのは自身驚き。仕事場のスペースが限られており、Windows環境とMAC環境、それぞれのスクリーンとキーボードを別個に置くスペースは無い。Windows環境が主であることには変わりないので、MACはRemoteで操作したい。macOSにはVNCが標準装備されているが、どうも好きになれない。実際に使ってみたが、やはりもたつき感。ということで、RDPで MAC を操作できないかと思い標題となった。 macOSは無論 RDP はサポートしていないので、3rd party を探すが、これが意外とプロダクトが少ない。MACから RDP で Windows を操作するクライアントは、Microsoftが無料提供しているし、他にも山ほどプロダクトが存在するが、漸くたどり着いたのが NuoRDS 。 なんだかそっけないWebサイトだが、Free Trialがあるので早速インストール。すんなり動作した。やはりVNCよりも何かと画面の動きがスムースで良い感じ。ここまでは順調に進んだが、問題はキーのマッピングであり、ここから本題となる。 macOS自体に Comand と CTRL キーを入れ替える機能があり、また 3rd party のkey mapper も充実している( Karabiner 等 )。これらは全て物理的に接続されているキーボードではうまく動作してくれるが、リモート操作の場合、設定したマッピングは全く効いてくれないことが判明。しかも悪いことに、私の愛用するキーボードには Windows key が存在しない。古い重いでかい、IBM の化石のようなキーボードなのである。 かなり調べたつもりだが、どうにも解決できないので、様々なケースをスタディーされているであろう NuoRDSのサポートに泣きついてみた。なんと３０分後にビシッとした回答を頂戴し、これにて解決に至った、ありがたや。これは全てMAC側の設定で解決できる問題なのであった。System Preference から Keyboard を選択。Modifier Keys... は何十回も設定してみたが前述のとおりリモートアクセスの際には効かない。ここではなくて、 Shortcuts タブをクリック 左の一覧で App Shortcut をク...