オレが考える最強のDBA(Database Administrator)

投稿日: 2016/10/13 作成者: masuda

のだめ開発を考える中で、SEとPGと…DBAと書こうとして躊躇してしまったのだが、DBAについて書いておこう。

数日前に、プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに を買って読んでいるのだが、20年前位だったか年配のコンサルタントの人に「データベースを扱う人ってのは、プログラマなんでしょうか？それともシステムエンジニアなんでしょうか？それとも SIer？」というのを尋ねたことがある。そのときに、DBA（Database Administrator）という分野の人をいることを知った。当時、会社で Oracle の設定をしていたり、SQL Server のチューニングをしていたので、テーブル設計をするとか、テーブルに効率よくアクセスするとか、を「誰が責任をもって担当するのか？」を知りたかった頃である。実務的には「プロジェクト内でデータベースに詳しい人」が担当する訳なんだけど、大規模プロジェクトになると大手 SIer（元請けという意味で）のSEが設定していたりする。それが SE なのか DBA なのかは、今もってわからないけど、じゃあ、テーブル設計は誰が責任を持つのか？というのは「DBA」という答えだったのだが、その「DBAの人は何処にいるのか？」という答えは得られなかった。つーか、はぐらかされてしまったんだよね。

そう、今思うと、そう意味での DBA なんて当時、何処にもいなかったのだよ。

「そういう意味での」ってのは、

  1. Oracle や SQL Server などのデータベース設定ができる
  2. Oracle や SQL Server などのデータベースのチューニングができる。
  3. データのテーブル設計（論理設計、正規化）が適切にできる。
  4. テーブル等の物理配置が適切にできる。
  5. テーブルにアクセスするための、効率のよい SQL が書ける。
  6. テーブルにアクセスするための、ストアドプロシージャなどが適切に書ける。

ってことになる。このストアドプロシージャを使うのが、プログラマだったりするからだ。

当時、大手 SIer の SE な人がやっていたのは、サーバーのセッティングとデータベース等のインストールで（内部的には DBA という分掌だったかもしれないが）、1と2の分野を担っていた。だから、3以降は、誰がやるのか決まっていなかったんだよね。元請け/下請けの関係の場合は、設計書として「テーブル設計」があるから元請けが作成することが多いのだが、果たして、5や6のように「効率よく」アクセスできるかどうかは抜け落ちてしまって、場合によっては、正規化ができていないテーブル構造がでてきたりする。だが、下請けにとって、その「まずい」テーブル設計を修正する手段を持たされていないので、その「まずい」設計のままモノ（コード）を作らざるを得ないパターンに陥る。

近年になって Web システムがこなれてきたので、データベースの設定や設計に関しても小規模に行うようになったから（ Oracle のインストールは、昔はひと苦労だったのだ）、このあたりの分け方が随分マシになったのだが、それでもデータベースのテーブル設計が「？」なものは多い。まあ、そりゃ、データベースのプロじゃないから仕方がないよね、と思っていたものの、じゃあ「本物のDBA」は何処にいるんだ？って話になる。そう、俺＝プログラマの視点から見たときに、先の1～6までを担ってくれる DBA はいるのだろうか？ いや、そもそも、1～6までは DBA の担当なのだろうか？という疑問がでてくる。

この本の邦題は「プロうグラマのための～」になっているが、原題は「Joe Celkos SQL for Smarties, Fourth Edition: Advanced SQL Programming」になっている。for Smarties というのは「賢いやつ」とか「知ったかぶりの」という意味もあるので（ “for Smarties” で検索すると定番のタイトルらしいので、皮肉なのか？）まあ、プログラマに限らない。

DBA はストアドプロシージャを書くのか？

データベースに効率的にアクセスするならば、ストアドプロシージャを書くのは「DBA」であるべきだ。なぜならば、プログラマよりも DBA のほうがテーブル構造を熟知しているし、下手なプログラマやなんちゃってSEがあれこれやるよりも、きちんとテーブル構造を知っている人がコードを書いたほうがいい。これは、昔からよく見ている。だが、その DBA が何処にいるのかという判然としない。理想的なのは、開発プロジェクト内に DBA が1名以上いて、その人が先に書いた1～6までの作業を請け負ってしまうのが望ましい。

しかし、ストアドプロシージャ自体にビジネスロジックを書いたり、テーブル自体が200個位あるような規模のプロジェクトになると、1名では足りなくなって複数名必要になる。しかも、業務ロジック（Web APIも含むだろう）をプログラム側から呼び出すようになると、きちんと設計すると、プログラマの半分ぐらいは DBA が必要となる規模になってしまう。これは何か変だ。DBA が何処にいるかわからないのに、そんな数の DBA を集めるのは不可能だから、DBA の仕事を減らすために（現実的な規模におさめるために）、1と2ぐらいの仕事だけを DBA に割り当てる。そうなると、非DBAな人（SEやPG）がテーブル設計をして、テーブルアクセスも非DBAがやるという、素人臭いデータアクセスの設計／実装になってしまう。これも変だ。

じゃあ、DBA が足りないのだから、もっと作ればいいじゃないかと思うだろうが、そうそうデータベースに精通している人がいるわけでもなく、まあ、そんなことをやるよりも、LINQ でアクセスするとか、コードファーストで作ってしまおう、という発想になってしまうのも無理ないことだ。実際、そういうパターンになる場合も多いだろうし、小規模な WEB システムであればそれで十分な場合も多い。しかし、それが「理想的」なのかといいえばそうではない。では、DBA の理想は何処にあるのだろうか？

DBA の必要条件

人数が少ない（居るのか居ないのかわからないけど）理想的な DBA が少数であると仮定して、その制約条件を考えてみよう。例えば、20名のプロジェクトで1名の DBA だけを想定する。均等に仕事を割り振ると、プロジェクトの5%の仕事が DBA に割り振られることになる。そのほかの仕事は、SE, PG, PM, PL などに割り振られる。そうすると、

DBA が最低限しなければいけない仕事に絞ると、

  • データベースのチューニングが可能である。
  • 正しいデータベースアクセスの解答を導き出せる。

を持っていれば十分な気がする。近年 Oracle や MySQL, SQL Server などのデータベースの設定自体はそれほど難しくはない。場合によっては、標準的な設定でも十分可動できたりする。

しかし、利用するメモリや、テンポラリディスクの物理配置、ログの切り捨てやバックアップ計画などの標準的なものから、環境にあわせた「チューニング」は必要だ。チューニング≒高速化は DBA にとっては必須条件ではないだろうが、システムの予防策を組む場合には必須となる知識だろう。逆に言えば、標準を超える閾値が何処なのかを知っておくだけでも十分だ。データベースアクセスの頻度など閾値を超えなければ、標準的な初期設定だけで十分だったりするし、最近はそれぞれのパターンが用意されている。

2つめの「正しいデータベースアクセス」は、「テーブル構造を作成する」よりも優先するのではないか、と思っている。業務フローなどからテーブル構造を作っていくのは結構大変な作業になる。生産現場などで使う200以上のテーブルを、5%の作業量しか持たない DBA に全て積んでしまうのは作業量的に無理がある。となれば、おおまかなテーブル構造や、アクセスの仕方は SE, PG が作ってしまい、それが「正しいデータベースアクセス」になっているかどうかを、チェックする係になってはどうだろうか？ゲートキーパー的な役割だ。

プログラムからのアクセスは、「ストアドプロシージャ」、「SQL文」、「LINQ」などの様々な手段があるから、それを統一するか場合によって選択するかはプロジェクトによって異なる。SE が作るテーブル構造も、アクセスしやすいようになっているか、最適なのかは分からない。ある程度の正規化ができていればそれで充分であろう。最適を求めるのではなく、工学的な準最適化を求めるのであれば、それほど細かく正規化する必要もない。また、データにあわせて非正規化する必要もない。そんな中で、統括的な意味あいで DBA という存在が、ひととおりの整合性をチェックし、経験上（そう豊富な実務経験は必要だろう）落とし穴になりそうな部分を潰しておき、後々に陥らないように予防しておくのだ。

これだと、少数の DBA でもなんとかできるかもしれない。そう先の2の要件とプラスアルファがあるだけだ。

で、何処に DBA はいるのか？

つらつらと「プログラマのための～」を読んでいて、DBA について考えなおしたのだが、そうなると著者は、まあ DBA としても、他に誰が DBA として適当なのだろう？という疑問がでてきる。いわゆる、資格としての DBA じゃなくて、実務的なプロの DBA だ。中国地方にひとりいるような気もするし、関東では出会ったことがないような気もするし、もっと閾値を下げてしまえば、プログラマを20名集めて、ひとり DB に詳しい人がいれば、その人をプロジェクト内の DBA とするのが現実的な解じゃないかなと思ったり。

カテゴリー: 開発 | オレが考える最強のDBA(Database Administrator) はコメントを受け付けていません

[のだめ開発] 指揮者 Conductor の役割とは(2)

投稿日: 2016/10/12 作成者: masuda

とある会社で、社内研修をすることにしました(技術顧問も兼ねています）。もとが保守の会社なので、そこにプログラミング要素を付け加えるというパターンで研修内容を組み立てています。なので、プログラミング研修よりも、もっと直近的に使える「社内ツール」を自作できる、程度まで引き上げます。最終的には、製品の内製ぐらいまでですかね。

あまり、言わないようにしているのですが、SE（システムエンジニア）とPG（プログラマ）のためのスキルは別ものです。両方持っているに越したことはないのですが、それぞれが「プロフェッショナル」として仕事をする以上、どちらかの技術に精通している（ゆえに、片方の技術があまり精通しなくてよい）というスタイルになります。仕事上は「分掌」という言い方もしますが、住み分けというか得意分野というところですよね。プロ／仕事なのだから、普通の人よりも十数倍早く出来上がるというのは意外と重要な要素です。その差分が、「支払ってもらう金額」なのですから。

オーケストラというチームビルディング方法

以前、[のだめ開発] 指揮者 conductor の役割とは | Moonmile Solutions Blog を考えていたときは、「カンタービレ」のほうを考えていたのですが、今回は「オーケストレーション」のほうに重きを置きます。詳細は「のだめカンタービレ」を読んでもらうことにして、ソフトウェア開発の視点からオーケストラを見たときの類似点は、専門家の集団ということです。これは、アジャイル開発でもウォーターフォール開発で同じように使えるチームビルディングの方法です。逆に言えば、専門家ではない人を集めてチームビルディングする方法もあります。以前、Microsoft が提唱していた「ソフトウェアファクトリー」とか、Intelが採用している標準的なスキルによるチームビルディングです。これは、どちらが良いとか悪いとかいうのはないので、適材適所でチームの作り方を選びます。勿論、チームに入っているのは「人」なので、その人に向かないチームもあることを忘れないでください。そういう時は、浅田彰の「逃走論」を読んで、清くチーム／会社から去ることをお勧めします。これは、デマルコ著「ピープルウェア」やヨードン著「デスマーチ」でも言われていることですので忘れずに。

さて、今回の研修のように、

  • 中途入社が対象
  • システムエンジニア、プログラマが混在

というスタイルでチームを組む場合は、いわゆる LLC/LLP（合同会社／合資会社）に近い形態でチームを組みます。LLCとLLPは会社法的には異なるものなのですが、ここでは「各自のスキルを持ち寄る」というところに注目します。

ちなみに、新人／自発的に動けない人／モチベーションが低い人、を混ぜるとこの方式は取れません。これは、新人等を否定してるわけではなくて、そういう場合には別なチーム作りがあるということです。例えば、命に係わるようなことは「軍隊式」じゃないとうまくいかない場合もありますからね。そこは、心理学や社会学も含めてベターな方法を選びます。

LLC の場合、それぞれが専門家≒独立できる程度のスキルを持つ人達を集めて、ひとつの会社を作ります。最大のメリットは、営業口を一本化できることと、他の専門家のスキルを自分のスキルとして借りることができる、ということです。いわゆる横のつながりですよね。「引き合わせ」というスタイルです。これは、人材派遣会社と被派遣の関係とは異なります。相互にスキルを渡し合うので、対等な関係になります。LLC の場合、弁護士や医者などの独立した専門家で組むことが多いのですが、実は同じスキルじゃないほうが効率的にチームが組めます。同じスキルの場合は、自分の溢れた仕事や遠地などの都合のあわない仕事に対して、他のチームメンバに振ることになるのですが、異なるスキルの場合は、各専門家に仕事を割り振るというスタイルになります。ちょうど、建築/土建における施工のような感じで、左官、電気工事、内装などの専門家がそれぞれの仕事を受け持つという感じですね。ゼネコンスタイルになると、一次請けという上下関係が発生してしまいますが、もっとフラットな関係になります。

このフラットな関係が「オーケストラ」のスタイルになります。ひとつのオーケストラにおいて、楽器は別々ですが、上下関係があるわけではありません（ヴァイオリンのように第1、第2や、コンサートマスターという役割もありますが、それはチーム内のチームという関係です）。また、楽器の奏者が交換可能というわけではありません。奏者はそれぞれソロでも弾ける実力を持ち、さらにオーケストラとして集まるというチームビルディングの方法です。

ちょうど、システムエンジニア、プログラマ、テスター、データベースアドミニストレータなどが集まってチームを組むところと似ています。大抵の大手のプロジェクトでは、SIer を中心にして系列会社／下請けに割り振るという「ゼネコン」方式を取りますが、独立系の保守会社やソフトウェア会社であれば、オーケストレーションの手法を使えます。

そんなわけで、

  • 色々な専門家を集める
  • 専門家は対等な関係を維持する

を使ったチームを「オーケストレーションによるチーム作り」と呼ぶことにします。

既存のチームビルディングとしてはアジャイル開発スクラムが、オーケストラに近いのですが、専門家の範囲が狭いのと「スクラムマスター」という制度ができてしまったので避けておきます。かつ、スクラムマスター等の「管理／交渉／調節役」と「指揮者（コンダクター）」の役割がかなり異なります。

指揮者 Conductor の役割

のだめカンタービレには、指揮者が何人か出てきますが4巻ぐらいまでの、千秋とシュトレーゼマンの指揮のスタイルを見れば、まずは十分です（もちろん、その先にも色々参考にできるメタファーもあるので、それはおいおいに）。

千秋が、自分の音を表現するために、強烈な主導権をもって指揮をします。それぞれがうまくない学生オケの場合は、奏者のスキルが低いので、そういう教鞭的なスタイルも重要です。これは新人を含めたウォーターフォール形式によいでしょう。しかし、ある程度、おのおのの奏者のスキルが上がっていくと、指揮者の役割は変わってきます。

シュトレーゼマン曰く「楽しい音楽の時間デス」に尽きるのですが、厳しいスキルアップの後には「楽しく」スキルを披露することが重要です。ソフトウェア会社において、スキルを披露するということは、現場でのハードウェアのセッティングであったり、徹夜でのトラブル対処であったり、長期／短期に関わらずソフトウェア開発であったります。いわゆる、顧客に何を「披露」するのかが、重要になってきます。

奏者それぞれのスキルが十分であるならば、複数の奏者がスキルを合わせられるように、出番をそれぞれ調節していくのが指揮者の役目です。勿論、単なる「進行」役（プロンプタ）ではないので、指揮者の目指すところに指揮（誘導）をします。

このあたりが、スクラムマスターとは異なるところで、主にスクラムマスターが強弁であることが重要になる（顧客の対処への交渉力が必須）のに対して、指揮者（コンダクター）は強弁である必要はありません。少しもじるならば「雄弁」ある必要ありますよね。イメージを膨らませて、聴衆（顧客）や奏者（メンバ）に自分のイメージを伝える必要があります。この指揮の仕方は、のだめカンタービレにも出てきてパリ編の指揮のコンテストにも出てきます。

そんな訳で、指揮者（Conductor）と専門家（Professional）の組み合わせが「オーケストレーションによるチームビルディング」の基本になります。

でもって、具体的な話は研修にて。でもって、興味があれば相談してください。研修に加えるか、別途時間を作るか考えます。

補足…「響け！ユーフォマニア」もブラスバンドでチームビルディングの好例なんだけど、あの場合はスキルの低い奏者を集めて指揮者／指導者が引っ張る形（物語的には高校生の成長もあるし）なので、ちょっと違うかな。原作4巻はお勧め。

カテゴリー: のだめ開発プロセス | [のだめ開発] 指揮者 Conductor の役割とは(2) はコメントを受け付けていません

Android SDK をアップデートしたら Hyper-V のエミュレータに接続できなくなったとき

投稿日: 2016/10/07 作成者: masuda

久し振りに、Xamarin.Android を作って、ツールを作ろうと思ったのですが、何故か

error: could not install *smartsocket* listener: cannot bind to 127.0.0.1:5037: …

のようなエラーがでて、Visual Studio から Hyper-V の Android エミュレータに接続できなくなってしまいました。Android の axml を編集するために、Android SDK をアップデートしたのですが、どうやらタイミング的に Xamarin.Android 内の Android SDK と相性が悪い模様。正確には adb がうまく起動できないようです。

こんな風に、エミュレータにアップロードする時に固まってしまいます。

image

 

エミュレータへは adb を使って接続しているのですが、どうも adb devices を実行しても空で返って来ます。多分、AppData/Local のほうで使っていれば分離できているのだけど、/Program Files を示しているときは競合しているのかも。

image

C:/Program Files (x86)/Android/android-sdk/platform-tools に adb.exe があります。

image

多分、connect がうまくいっていないので、手動で接続してあげると、繋げるようになります。

Hyper-V のエミュレータで >> ボタンをクリックして「Network」のタブを開くと、エミュレータが使っている IP アドレスが分かります。

image

これを使って

adb connect 172.16.0.20

で起動させておくと、Visual Studio から Hyper-V のエミュレータへのデプロイができるようになります。

image

多分、Program Files 配下にあるから、パーミッション絡みで起動できなくなっているような気がするんだけど、どうなんだろう。コマンドが間違っているような気も。

おまけ

Visual Studio の新しいバージョンを Hyper-V 内で試しているんだけど、そこで Xamarin を動かして Android に接続するときに困っていたのですが、どうやら adb connect で繋げれば、Hyper-V 内の Visual Studio から別の Hyper-V で動いている Android エミュレータに接続できますね。これは結構便利。

カテゴリー: Xamarin, トラブルシューティング | Android SDK をアップデートしたら Hyper-V のエミュレータに接続できなくなったとき はコメントを受け付けていません

MVVM+MVCパターンを発注視点で分割する

投稿日: 2016/10/06 作成者: masuda

MVVM+MVCパターンを大規模システムにスケールする | Moonmile Solutions Blog で書いた「大規模プロジェクトを発注視点で分割する」の項目をもう少し掘り込んで、思考実験してみましょう。

何故、発注視点を先にやるのか？

もし、ソフトウェア開発が車の購入のように、買ったその日から使えるとすれば（既存のシステムや、クラウド上にあるシステムに沿うならば、「即日」も可能ですよね）、開発している途中の都合は問題ではありません。機能的な価値よりも、機会損失を加味して早期導入によるメリットのほうが大きいパターンを考えてみます。実際には、開発期間が0日であったとしても、実際に使う期日はもっと先にあって、しばらく使わないという塩漬けな状態があったりするのですが、できることなら、すべてを0日で揃えるのが一番価値の高いものでしょう。

そう考えると、ソフトウェア開発における要件定義のまとめからソフトウェアの開発期間、品質の向上、機能の豊富さなどが、すべてマイナス要因となり、減点法で考えることができるようになります。学校においては「減点法」は良くないのですが、リリースが即日であって開発期間が0日であることが「最高」であると考えると、開発期間が増えるたびにマイナスになっていくという単純増加のグラフが簡単に作れるのです。

image

リリースまでの日数が0日でれば、先行利益の価値は最高になります。開発期間が0日以上であれば、その分、先行利益の金額は下がるというわけです。

発注からみれば、すべての機能が揃っているならば、即日使えたほうがいいですよね。既存の製品を売る場合はこのパターンになるでしょう。

開発期間により機能が増えると考えると

リリースまでの日数が0日の場合は、開発期間がなしということなので、何もモノがない場合は、モノがない状態で納品することになります。開発期間が数日、数週間、数か月と増えていくたびに、なんらかの機能が追加され製品を使ったことによる収入が増えると考えられます。これは、間接部門が使う情報管理システムかもしれないし、会計システムかもしれないし、顧客管理のシステムかもしれません。何の機能もない場合は、何も効率化できないけど、数週間なり数か月のソフトウェア期間を設けることによって、何らかのモノができるという考え方です。

image

開発期間を0日を基準にしたとき、右上がりのグラフが「先行利益」になり、右下がりのグラフが「機能による利益」になります。リリース日より、数日前から機能による利益は発生し、開発期間が長くなれば、機能による利益はアップします。ただし、開発期間を数十年にしたら、どこまでも伸び続けるかというとそうでもなく、ある程度の限界が必要なのですが、ここで注目したいのは「適切な開発期間」なので、長期すぎる開発期間の話は省きます。

図を見て分かる通り、二つの線には交点があります。2つの利益を加算したときに、最高になる地点がこの交点になります。2つのグラフが直接の場合には、加算しても同じ値になるのだけど、そこは曲線になると考えてください。

つまり、交差する時期にリリース日を設定すると、先行利益＋機能による利益が最高になるというわけです。実際には、リリース後にも機能が追加されるので、機能による利益は少しずつ増加していきます。

ソフトウェア開発には最適なリリース日がある

この考察をまとめると、車のように即日買ったときに全ての価値が得られるのではなく、

  • なんらかの開発期間を要する
  • 開発期間により、製品自体の機能価値があがる

という条件のもとでは、リリース日は0日ではない、ということがわかります。また、すべての機能が盛り込まれた状態の最終的な出荷よりも、ある程度の機能が盛り込まれた状態でリリースさるほうが先行利益が加算されて、トータルの利益が大きいことがわかります。つまり、ここが「発注側の視点」によるリリース日の設定になります。

先行リリース、逐次リリースなどアジャイルやウォーターフォールを含めて、いくつかのリリース方法がありますが、発注側からすれば、リリースまでに極端に短期である必要もないし、すべての機能が揃うまでリリースを待つ必要もありません。リリースされたものを利用して、具体的に先行利益が得られる状態でのみ、リリース日の意味があります。

カテゴリー: 設計 | MVVM+MVCパターンを発注視点で分割する はコメントを受け付けていません

[ソフトウェア開発者の道具箱] 金の鍵

投稿日: 2016/10/04 作成者: masuda

ソフトウェア開発者の道具箱 | Moonmile Solutions Blog シリーズの第3弾めは、情報発信の話。

研究開発でもプログラミングでもそうなんだけど、実際にモノを作っている時間と、モノを作ろうと設計としている時間がある。モノを作っているときは、集中している時間を多くして、出掛ける時間を減らしたり人と会う時間を減らしたりする。じゃないと「モノを作る」時間を捻出できない。逆に、モノを作るための設計とか計画をしているときは、適度に情報を取り入れたり出したりしないとうまく発想が回らない。情報を取り入れるところはすぐに分かると思うけど、「情報を出す」というところに手が回らないくてやめてしまう人が多いのだが、実は違う。情報を効率よく取り入れるためには、情報を出すという自分なりの整理が必要になる。

  1. 雑多な未知な情報を取り入れる。
  2. 自分の中の既知な情報と組み合わせたり比較したりする。
  3. 取り入れた情報に対して「本質」を外していないか、客観視するために情報を出す。

というサイクルが必要になる。よく、Twitter で書いた途端に誤字をみつけるとか、人と話した途端に理解が進むとか、コンピューターの横に熊のぬいぐるみを置いて話しかける、というアレです。

でもって、何らかの情報を出し入れしている間にだんだん固まってきて、ひとつに集約するためにモノ（プログラムコード）を形作っていくわけだけど、物理的なモノづくりと違って、プログラミングコードなんてのは作ったり消えたりするサイクルが非常に早いので、作る時間と考える時間を結構なタイミングでスライスさせても問題がない…ように見えるのだが、それでも交互に来ることには違いない。

「金の鍵」ってのは、情報を発信するときに内側から開けるための鍵です。外からの情報をシャットアウトするために鍵が必要なのは直ぐに分かると思うけど、内側から出るときに何故鍵が必要なのか？そう、先の設計時の思考で書いたように、情報の流入と流出のバランスと保ために、内側のほうにも鍵を付けておいて「常に外側に繋がっているという状態ではない」という状態を保つのに必要だということだ。「平田弘史のお父さん物語」に詳しく書いてあるのだが、呼吸と同じ。「吸」だけ続けても何も吸収できないので、「呼」があって循環させないといけない。これは仏教の呼吸法にもあるんだが、循環とか輪廻とかそういうところに根差している「思想」になる。だから、科学的に「本当に知識の吸収ばかりすると効率が悪いのか？」という証明は別として、温故知新な経験的なところから、情報の入力と出力のバランスを取れ、というのセオリーということになる。こんな風に、ブログとかで出力すると自分にとっても客観視ができやすくなるので、それなりの効用はある。

内部から外側にでるときに「鍵」を使うということは、情報発信をするときに、なんらかの形で情報を整理するということでもある。つまり、取り入れた情報をそのまま垂れ流すのではなくて、何がしかの理解をしたうえで流す／伝えるということですね。そうなると、安易なリツイートやまとめサイトの云々がアレなのが分かると思う。ひと呼吸おくということが、ちょうど「鍵」の役目をすることになって、それが「思慮深さ」を生むことなる。思慮深さは会話のテクニックでもあるのだけど、即答しないでひと呼吸置くとか、相手が息を吐ききった後に話かけるとか、そういうタイミングの話でもありますね。武術においても、相手が呼吸を吐いたときに当てるのが一番ダメージが大きいので、それを見る。同時に、呼吸をさとらせないという技もあれば、偽の呼吸を相手に伝えて惑わすという手法もある。これは武術に限らず、会議とか競合会社のアレとかにも使える。

そういうタイミングが鍵になる。

ちなみに、逆引き大全のほうは、1対多の情報発信の話になっているので、こっちはISO9000絡みの、「外に漏れるとまずい情報≒メンバ全体が知らなくても良い情報」あたりの鍵の話になってる。

カテゴリー: ソフトウェア開発者の道具箱 | [ソフトウェア開発者の道具箱] 金の鍵 はコメントを受け付けていません

怒鳴り声が聞こえる教室/職場について

投稿日: 2016/10/03 作成者: masuda

実は「とと姉ちゃん」をちらちら見ていて思ったんだが、Twitter には流れてこないし、それほど気にする人はいないのかなと思った。しかし、Twitterで拡散されたツイート「先生の怒る声が辛くてドキドキして苦しくなっちゃう子供が実際にいること」: 『それでも彼と未来をさがして』HSC母のblog が流れてきたので、エールを送っておこう。

学校の先生とか職場とかで「怒鳴る先生／上司」がいるときに、別の人が怒られていて自分には関係ないはずなのに胃が痛くなる。先に書かれているブログの内容のように「メンタルが弱い」と言われることがあって苦々しく思うのだが、実は感受性が弱い（凡庸）だから他人が怒鳴られているのに気にせず（あるいは、胃が痛くなるほど同化せず）、感受性が強いからこそ（相手への共感性が高いほど）自分が怒鳴られているように感じて、精神的に病んでしまうことがある。…というのは、なかなか理解されない。

HSC/HSP（Highly sensitive person）というのを初めて聞いたので、自閉症／アスペルガー／注意欠陥／多動症／サヴァン症候群との違いが、いまいち掴めていないかもしれないが、ハイリー・センシティブ・パーソン – Wikipedia を見る限り「生得的な特性」とあるので、遺伝系の話になりますよね。社交性が問われる内向的な性格とか、協調性のような社会的な適応性のような後天的なもの（例えば、オオカミに育てられた子供のように、社会的な活動を一切していないのであれば、社会的な活動に沿う行動はできないのだ。逆に、後天的に学ぶことが可能ってことになる）とは違って、生まれつき持っているもので変化しないものだ。勿論、生れつき持っているもの＝気質だからといって、将来的に（大人になったときに）、それがマイナスに働くかプラスに働くかは別の話になる。さらっと HSC の話をいくつかみていくと、子供の頃のマイナス面を強調されているものが多いのだが、プラス面を強調することも可能だ。

怒鳴り声に鈍感になる

HSC な子の割合が 15～20% ってことになっているので、30人学級だと6人ぐらいいることになるよね。これだと「症候群」というよりも、単にグループとか分類の範疇になると思う。そうそう、民主主義的に多数決で投票を取ると少数派になるパターン。でも、徒党が組めるぐらいの人数がある。最近語られることの多いマイノリティ（≒少数派）はもっと数が少ない。5%以下ぐらいじゃないかな。30人学級で1人いるかいないかという確率になる。こうなると、学級内で「友達」を作ることが難しいので、意図的に保護しないとうまくいかない。

でもって、人口の8割が「怒鳴ってもok」という雰囲気の中にいると、教室なり職場なりで「怒鳴る」ことが日常的に行われていることを、単なる現象として捉えること（ああ、かわいそうだなと思う程度で、自分に降りかからないようにするとか、他山の石として参考にするとか、そういう意味で）ができるのだが、残りの2割は自分が怒られているように恐怖として感じる。8割の多数の人は「怒鳴り声」の多い職場／教室では、自分だけが怒られたときに「怒られた」というストレスを感じるわけだが、2割の人は「怒鳴り声」を聞くたびに、自分が怒鳴られているのと同等のストレスを感じるので、まあ、常に怒られているような教室／職場になるわけだ。そりゃ、それがストレスになって登校拒否になったり、職場に行くのが嫌になったりする。いわゆる、ブラックな職場というものがあるけど、それはまた別な話。一般的に「怒鳴り声」が少ないと思われる職場であっても、怒鳴り声のたびにストレスを感じれば、ブラックな職場ぐらいのストレスをその人は感じているのだ。

じゃあ、これの場合はどうするのか？というと、

  • 職場を教室を変える。
  • 「怒鳴り声」に鈍感になる。

実は、「とと姉ちゃん」の怒鳴り声を聴くたびに、私は嫌な感じがするので内容はともかくとして、怒鳴り声を許容している職場というのが嫌なんだが（それが朝ドラで放映されているのも嫌なんだが）、そういう場合は、テレビを消せばよい。あるいは、音を小さくするという手段をとる。簡単だ。見なければ自分に関係ないからストレスを感じなくなる。

テレビドラマの場合は「見ない」という手段が取れるが、実際の教室や職場だとこれはできない。教師は、怒鳴ることによって「叱る」ことの手段を行使しているのかもしれないし、8割の子供や親にとって（かつ教師も含む）「怒鳴る」ことがそれほどストレスに感じないのだから、まあ、直接、怒鳴ることはなくても、他の子を怒鳴ることもあるだろう。そもそも、怒鳴ってくださいという体育会系の親もいる（今だといないのかな？）もいるわけで、なかなか一方の主張を通すだけでは難しい。逆の立場になれば、いたずらっ子を怒鳴って懲らしめるというのは、サザエさんも一般に行われているし、社会的に認知されているものと考えられるでしょう？それは、日本的なものなのか、戸塚ヨットスクールみたいに限定されているものなのかは不明だが（だって、赤毛のアンにだって鞭で打たれるシーンはあるし、洋画のほうが「口論」というシーンは多い）、社会的な通念は別として、感受性の高い子（「過敏な子」と言い方ほうがいいと思う）にとって、その「過敏」さは他の人に理解されにくいところがある。ただし、この HSC の原因が「気質」にあるならば、両親のどちらかがその遺伝的形質を持っているということなので、片親が理解できればいいのですよ。つまり、父親の遺伝であれば、母親には理解しがたい現象かもしれないし、逆に母親の形質であれば父親には理解しがたい。遺伝だからね。

となると、社会的に取れる手段として「鈍感になる」というのがある。自閉症の例で、目に入る光が多く感じられるので、色の濃いサングラスをかける（ある色彩だけ遮蔽するとか自閉症専用のサングラスがある）という方法がある。これだけでも十分過ごしやすくなるそうだ。同じように「怒鳴り声」が多い環境の場合は、怒鳴り声に対して鈍感になるように、自分の側で防衛する方法を取る。

  • 怒鳴り声が聞こえたら、教室や職場を一時的に出る。
  • 別なことに集中する。あえて、楽しい絵を見るとか、漫画を読むとか。
  • 端的に耳をふさぐ。耳栓をする。

一般的な8割の人からみれば、他の人が「怒鳴られている」のだから、もうちょっと気を使ったらいいんじゃないかという不審な目で見られがちなんだが、いや、自分が怒鳴られているように感じるのだから防衛するしかないのだ。8割の人の鈍感さの対応の仕方では難しいので、別な対策をとるという方法になる。

私の場合、だいたいこれでマシになります。会議中でも誰かが怒鳴りだしたら、空気を読まずにトイレに出ることにしている。

ポジティブに HSC/HSP をとらえる

アスペルガー症候群と若干混ざってくるが、常に防衛側に回る必要はない。所詮「症候群」という全体主義的なカテゴリ分けの意味しかないので、個人として生活するならば、アクティブなものとして捉えることもできる。

アスペルガー症候群にも重いやつと軽いやつがあるので、いろいろなんだけど、他人に迎合しない利点（感情を理解する仕組みは一般の人とは違う）を利用して、多人数に迎合しない仕事とか発見が可能になる。HSP の場合は、世の中の2割がそうならば、職業の2割は HSP のほうが得な職業だということだ。社会的適合としてね。

ひとりで研究をするという意味で、医者とか芸術家とか漫画家とかプログラマとかがあげられているけど（IT業界の場合は、群衆なプログラマと個なプログラマがあるので、もちろん後者のほうね）、とある現象に「過敏」という癖を利用すると、品質管理とか文書チェック関係の細かい仕事を正しくやるという仕事にも向いている。宇宙飛行士もその範疇だと思うんだけど、協調性（相手を早い時期に許すという緩めな性格）と強烈な自我（競争率が高いからね）を両立しないといけないので、もうちょっと待ったほうがいいかな。「死」に対する危険を人より多く感じるので、工事現場とか建設現場とか工場のライン作業には向かない。安全第一の場合、注意喚起として大声を出す事が推奨されているけど、それがマイナスに働く。「間違い」に関して多少寛容でないと、間違いを犯さないように注意深く進み過ぎて動けなくなってしまうという特徴がある。そういう意味で、私のプログラマ生活は TDD とワンセットだったりする。

研究員には向いているはずなんだが、日本の大学だともうちょっと違う要素が多くなっているみたいで、そこは教授をうまく選ばないといけない。というか、いっそ海外に出ちゃったほうがいい。海外に出ると、そももそも自分がマイノリティ（日本人＝少数民族）なので、マイノリティな中でマイノリティなことをやるのが馬鹿馬鹿しくなる、という利点がある。

うちの娘も小学校最後の運動会が終わって、来年から中学生。親の保護ができるのは、小学生までなので（という風に決めている）、あとは自分の世界を模索しないといけない。そういう場合に親ができるのは「環境」を用意しておくだけ。あと、この手の理論武装≒武器をあらかじめ揃えておく。不利だからと言って（根本的には）誰も助けてくれないし、誰の助けも根本的な助けにはならない。信じられるのは自分だけなのだから、うまく環境（自分のまわり）を制御するのがコツ。

本を読んだので補足

エイレン・Ｎ・アローン著「ひといちばい敏感な子」を取り寄せて、読み終わったので追記をしておこう。HSC が Child で、HSP が Person なので実質違いはない。この本は、HSC の子供を持つ親向けに書かれているので、HSC かな？と思う場合は、「ささいなことにもすぐに動揺してしまうあなたへ」を読めということになっているが、自分の子供の頃は、注意欠陥も多動症も緘黙な子もごっちゃにまとまって「ひとつの普通のクラス」だったので、昔のことを思い出しながら小学生の章を読み下せばよい。

私は日本では「HSC がグループになじめなくて～」と書いたが、この本では179頁に「和を重んじる日本などでは、見方が違う」という項目があって、アメリカ国内の強い自己主張に負けてしまう HSC の子は、日本のような自己否定の少ない国のほうがなじみやすいのではないか、という書き方がされている。どうやら、アメリカでも日本でも HSC な子にとっては住みにくいらしい。

この本には HSC/HSP の「怒鳴りに対する恐怖」っぽいものは書かれていないのだけど、子供を叱るときに頭ごなしに叱るのではなくて、言い聞かせるほうが通じやすい、という書き方がされている。全体的に診療心理学の分野なので、自己主張よりも「現実の世の中にどのようになじむのか」という視点での提案が多い。まあ、芸術家などに HSC な人が多い（アスペルガーが多い）などと書かれているが、実際に統計をとるならば、無作為に芸術家を選び出して HSC な人の割合と、一般抽出の割合とを比較しなければいけないので、あまりあてにならない。が、良い目標にはなるだろう。HSC/HCP であることが、マイナスの要素として働くだけでなく、プラスの要素としても働くわけだ。これは障碍（障害）としてではなく、とある性格（特徴）として捉えることができることを示している。勿論、パラリンピックを観ればわかる通り、片足が義足でも一般のひとよりも遠くに幅跳びができるように、明確な障害（健常者ではない足）が人として全体的にはマイナスに働かない例もあるけれど、なにかと子供のうちはマイナスになりそうなところは避けておきたいのが人情だ。しかし、そういう明らかなマイナス要素としてではなく、伸ばすべき特徴（あるいは、本人の希望を叶えるための原材料）となる可能性あるならば、使わない手はないだろう。HCPの割合が15～20%という割合をどうとらえるかにもよるし、それは本に示されている通り「5人に1人」という高い割合なので、自閉症などと違って高い確率で存在することなる。そこを、進化論的に捉えて、潜伏した劣性遺伝子として捉えるかどうかは、今後の研究次第なんだけどどうなんでしょう。あとがきを見るとセロトニンと差次感受性に関係するので、普通に躁鬱病に関係するような気もするけど。このあたりは、自閉も多動もアスペルガーも根本は一緒だと思っている。症例が違うだけで。

 

カテゴリー: 雑談 | 怒鳴り声が聞こえる教室/職場について はコメントを受け付けていません

.NET Standard とは何か？

投稿日: 2016/09/30 作成者: masuda

.NET Core が 1.0 になってリリースされて、ASP.NET Core MVC が Linux 上で動くようになったと思ったら、今度は .NET Standard ってのが出てきて、え？いきなり、.NET Standard 2.0 ってのは何ですか？ってな感じな人は多いと思いますが（私もそうでして）、ひとまず、.NET Standard とは何なのかを探っていきます。

Introducing .NET Standard | .NET Blog
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

もともと、.NET Core って、Windows に依存する API を切り離してしまって、Linux やら Mac やら動く環境を作るのが目的じゃなかったんですか？と思っていたわけですが、図を見るとちょっと違うようです。

dotnet-today

たぶん、Xamarinを買収した影響（Mono自体を取り込んでしまった影響）が大きいと思うのですが、Linux 上で、何らかの .NET なプログラムを動かそうと思うと、.NET Core なプログラムと mono なプログラムは競合します。上の図では、Xamarin が、iOS/Android に「のみ」依存しているような書き方ですが、実際は Linux 上で動かしているものもあるわけで、Raspberry Pi 上で C# を動かしてツールを作ったり、F# を動かせたりするのはそれです。実運用的に apache と .NET の組み合わせが妥当かどかは別として（LAMPで組むとか、Javaのほうが楽だろうし）、mono を使えば、結構な .net なツールを Linux 上で動かせます。クラスライブラリ自体も大体のところは本家（？）の .NET Framework を網羅しています。まあ、そのあたりが Unity + Mono という組み合わせなわけですが、それとは別なスタイルで .NET Core な環境を Microsoft は独自に始めたわけです。

で、結果的に Xamarin 社と業務提携から買収に至ったわけで、そうなると、上の「Mono Class Library」なところが「Core Library」に置き換わるのかな？と想像するわけじゃないですか。Microsoft 社内としては、Mono と .NET Core のメンテナンスを分散して注力するよりも、.NET Core に統一してしまったほうがよい（Mono の差分な資産はどうするのか？は別として）と思っていたわけです。

が、

dotnet-tomorrow

蓋を開けてみれば、base library の場所が、ごっそり「.NET Standard」に切り替わるって話なんですよね。ええ。.NET Core は 2.0 になることなく、vNext（でいいのか？）という統一された形で、.NET Standard になるわけですね。

すっきりするのはすっきりするんでいいですが、いわゆる OS 依存な低レイヤな部分は、.NET Standard としてどう扱うのか？特にSystem.IO系のセキュリティ絡みは .NET Standard としてどう扱うのか（あるいは扱わないのか）が不明なのですが、ひとまず、ひとつにまとめたい模様です。

PCL Hell が解決するのか？

PCL(Portable Class Library)を作るときに、動作するプラットフォームを選ぶわけですが「そんな未来なことはわかりません」。要は、誰が考えたか知らないのですが、.NET Framework で「Client Profile」っていう Web 系抜きのパッケージを考えたのが間違っていたわけです。

image

and

image

肥大化するアセンブリと、OneClick なインストール環境（だったかな）を利用できるようにするために、Web 系のアセンブリをケチったわけですが、その系譜が、Xamarin.iOS/Android を含める PCL 作りのところまで引き擦られていきます。あのプロファイルの番号は、順列組み合わせになっていて、Silverlight とか、Windows 8.0 とか Windows Phone とか過去の遺物を引きずり回します。まあ、最終的に Proifle7 か Proile78 か Profile259 なマジックナンバーに落ち着くわけですが（苦笑）。

ちなみに、ここの Hell な原因は、アセンブリ名やクラスの厳密性を優先させているのが問題であって、Linux の *.so のように（というか C言語呼び出しのごとく）「名前はどうでもいいから、スタックさえ合っていれば、呼び出せるよ」でもいいわけで、実際 Linux 内で *.so を呼ぶのは非常に簡単ですし、シンボリックも使えて便利です。まあ、その分、競合は発生しそうなんですが、Windows の各種ライブラリみたいに頻繁に更新しない、というのがミソですね。

あと、F# のタイププロバイダーで、ビルドするときの DLL と、出力する DLLと、Xamarin 内で動作する DLL が競合してしまって、Xamarin.Android/iOS 内ではタイププロバイダーを使えないとか、F# のライブラリを参照している C# のライブラリを参照する F# のプロジェクトを作るときにはコツがいるとか、変なことになっているのは、ぜんぶ PCL 絡みの変なことになっているせいです。ええ、F# のライブラリな変な番号も体系も PCL のせいです。F# が流行らないのも PCL のせいだし、ポストが赤いのも PCL のせい。

そんなわけで .NET Standard 1.x が過渡期である

ことが判明して、.NET Core そのものをあれこれと攻めていっても、これも過渡期（2.0がなくて吸収合併するんだったら、まあ VSCode でビルドの仕方ぐらいを覚えるのでよいのでは？）なので、構造的には .NET クラスライブラリの焼き直しの時期なんでしょう。Microsoft 内部の人にはそうなんだけど、外部からすれば、そこで停滞しているわけにはいかない（ .NET 以外の分野が主だったりするわけなので）となれば、そこは「最新情報」の獲得にあくせくするのではなくて、

  • 従来型の WPF アプリを極める（内部的に UWP は .NET Standard で統一されるので、UWP でできることが限りなく WPF に近くなる）。
  • スマートフォンは、Xamarin.Forms を拡張してしまうか、Xamarin.iOS/Android で独自に進化させる（特に、Xamarin.Andrid のほう）。
  • Linux で ASP.NET するときは .NET Core を使う

という感じですかね。個人的には。

他にも VR とか Unity とか機械学習で Python とか Alljoyn とか ROS とか、諸々な要因があるわけで、 .NET Standard がそのあたりと「どのくらい組み合わられるか？」が肝になってきます。

もうちょっと真面目な解説はこちらへ

.NET Standard Library
https://docs.com/iwanaga-nobuyuk/3514/net-standard-library

.NET Core とマルチプラットフォーム
http://www.slideshare.net/shozon/net-core-66620714

マイクロソフト、.NETの分裂を未然に防ぐための標準仕様「.NET Standard」を策定 － Publickey
http://www.publickey1.jp/blog/16/netnet_standard.html

カテゴリー: 開発 | 1件のコメント

[ソフトウェア開発者の道具箱] 同情プログラミングをやめる

投稿日: 2016/09/28 作成者: masuda

道具箱シリーズの第2弾は「同情プログラミング」の話です。

プロジェクト運営（プロジェクト「管理」ではなく）の視点から言えば、プロジェクトやチームがうまく動く方法は「うまくいかない部分」を切り去っていくことです。「切り去っていく」ということは、冷徹な感じがするような気がしますが、人を切り去るのではありません（チーム崩壊を招く「マイナス生産者」に対しては、切り捨ての手法をとりますが）、その人が何かをやるときに、うまくいかなくてマイナスになってしまう部分を切り落として捨て去ります。人なのだから、何かの間違いもするし、勘違いもするし、運が悪いときもあるし、体調が悪かったときもあるし、状況によりうまくいかない場合もあるでしょう。だから、トータルで考えるわけですが、チームとして（それは人として「成長」なのかもしれません）今よりもうまくいくためには、今、ダメである部分を少しずつ切り取っていくのが着実な方法なのです。なので、何らか状況でうまくいかなかったとき（能力が低かったというのも含めて）は、再び同じ状況に陥ったときには回避できるようにしておきます。完全に同じ状況というのはないのですが、今後も似たようなことはおきますよね。ISO9000の「是正処置」という考え方ですが、これを流用します。勿論、なんでも是正処置が必要なわけでなく、レアな場合（今後は1度も起こらないようなこと）は是正する必要はありません。苦くて忘れたい経験は、忘れ去ってしまうのがベターです。

さて、プログラミングにおいて、プログラムコードを書くということは、それなりの時間をかけて、それなりのかの人の努力の結果が示されているわけです。なにがしかに時間は、会社の給与のうちかもしれないし、自主的に家に帰って考えた結果かもしれないし、どこかの講習でお金を払って覚えた技かもしれません。1,2日のコードであれば、捨て去る勇気もあるのですが、1週間も掛かって苦労して作りあげたコードを、人情的に捨てるに忍びないですよね。ちょっとぐらいまずくても、何らかのいいところを拾うとか、かの人の心情を害さないような手段を取りたいものですよね。

ですが、残念。それらは捨て去ってしまうほうがベターなのです。

プログラムコードが、アジャイル開発的に動くものを達成するのであれば（場合によっては、「動かない飾りのコード」というものもありますから）、動かないまずいコードは、そのままゴミでしかありませんし。何の価値もありません。そこに「同情」をしてしまうと、先行き負債を抱えてしまうのは明らかなことです。いや、コード自体の負債以前に、かの人の成長機会を失ってしまうのです。

ベストな方法、かの人に書き直して貰う事です。仕事として。

うまくいかない原因は、まずい設計かもしれないし、時間がなかったのかもしれないし、予想よりも時間が掛かったかもしれない、能力が足りなかったのかもしれない、いろいろな原因があります。でも、2度めにコードを書くときは、設計の見直しや、時間をしっかりとったり、計画を立て直したり、かの人の能力だけでなく他の人の助けを求めたりすることが可能であり、それは「経験」として生きてきます。それを、本人に伝えずにこっそり直してしまったり、直すべきところを指摘して勝手にピンポイントで直してしまったりというような、かの人の「成長機会」を奪うような方法は、結果的にチームやプロジェクトにとって損失でしかありません。そう、いわゆるかの人の生産性が変わらないままになってしまうのですから。

この「同情プログラミング」をやめるのは、かの人にシビアすぎるような感じがするでしょうし、無意味につらくあたるような気がしますよね。いいえ。「同情プログラミング」をやめるためには、

  • 失敗を前提として、コーディング期間の計画を立てる
  • やり直しの時間を確保する
  • 失敗しても問題が少ないところを新人に配置する

というプロジェクト運営/計画が必要です。それがなければ、単なる無法地帯で、プロジェクトの成否は偶然によって左右されているだけですよね。

カテゴリー: ソフトウェア開発者の道具箱 | [ソフトウェア開発者の道具箱] 同情プログラミングをやめる はコメントを受け付けていません

PLEN2 で始めるロボット制御の基本…の補足

投稿日: 2016/09/26 作成者: masuda

Plen2で始めるロボット制御の基本（スライド）

[slideshare id=66364049&doc=plen2-160924053144]

NETラボ勉強会 20160924 – YouTube

二足歩行ロボットのチート…じゃなくて、参考用に購入した PLEN2 を題材にした発表です。あれこれ、模索した結果を話しているので、本格的なところは ROBO-ONE などを参照して貰うとして、ソフトウェア開発のサイドから見ると、ハードウェアな二足歩行ロボットはこう見える＆こうアプローチできるという感じで話をしています。

PLEN2 を購入して、あれこれ弄って分かったことなのですが、

  • サーボモーターの初期化が結構大変
    → 結構、誤差がでるので、誤差は誤差で許容しないといけない。
  • 歩くといっても、モーション作りと、自律制御と、人によるコントロールが混在している
    → どれを目指すかによって、制御プログラムにいろいろ違いがでる
  • ソフト屋さんのアプローチできるところは多い。
    → クラウドでセンサーデータを集めるだけじゃなくて、モーションを作るアプリとか、通信制御の部分とか、協調動作を映像化するとか、今後ソフト屋さんのできることは多い。

VR など仮想空間ということで、ソフトウェアだけで完結できるものが流行りだったりするのですが、自分としてはハードウェアにアプローチできる部分でソフトウェア開発の手法を使う方向でやっています。なので、重力の話だとか物理誤差だとかモーメントとか必須になりますよね。

7月からずっと、ASP.NET MVCの本を書いていたのですが、やっとこさ一区切りついてきています。10月以降は、再びハードウェアなもの（Windows IoT Core も含めて）に戻る予定。真面目に Raspberry Pi/Rasbian に戻って、Python も。

コントローラー制御の参考に

有線 USB の XBOX コントローラは、Windows IoT Core でも繋がるので、お手軽です。無線のほうは、まだ試していない。

カテゴリー: PLEN2 | PLEN2 で始めるロボット制御の基本…の補足 はコメントを受け付けていません

アリスは無限にプラダから猫を取り出す（F#編）

投稿日: 2016/09/22 作成者: masuda

アリスは無限にプラダから猫を取り出す | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/8179

これをF#版に直してみる。
実は、GetCatsメソッドを末尾呼び出しにして、F#のほうは無限に猫を取り出せる…という風にやろうと思ったのだが、この方式だと lst に詰め込むときにスタックオーバーフローになってしまう。
最初は head::tail 方式で書いていたのだが、なんか面倒になって（ツリー構造だから）、外部で list を持っているのが問題かも。

type IObject() = do ()
type Cat(name) = 
    inherit IObject()
    member val Name:string = name with get, set

type Bag() =
    inherit IObject()
    member val Items:IObject list = [] with get, set
    member x.Add(items) =
        for it in items do
            x.Items <- it :: x.Items
        x
    // 猫だけ取り出す
    member x.GetCats() =
        let rec cats (bag:Bag) =
            let mutable lst = []
            for it in bag.Items do
                if it.GetType() = typeof<Cat> then
                    lst <- it :: lst
                else
                    let bag = it :?> Bag
                    lst <- lst @ cats bag
            lst
        cats x 

// main
// 入れ子のバッグ
let prada = 
    Bag().Add(
        [Cat(&quot;mike&quot;);
         Bag().Add( 
            [Cat(&quot;hop&quot;);
             Cat(&quot;stop&quot;);
             Cat(&quot;jump&quot;)]);
         Cat(&quot;kuro&quot;);
         Cat(&quot;shiro&quot;)] )
// 猫のみ取り出す
for it in prada.GetCats() do
    let cat = it :?> Cat
    printfn &quot;cat: %s &quot; cat.Name 

// 無限バッグを作る
let mutable infbag = Bag().Add([Cat(&quot;Cheshire&quot;)])
infbag.Add([infbag]) |> ignore
// 無限に取り出す...ことはできない
for it in infbag.GetCats() do
    let cat = it :?> Cat
    printfn &quot;cat: %s &quot; cat.Name
カテゴリー: F# | アリスは無限にプラダから猫を取り出す（F#編） はコメントを受け付けていません