全ての意志決定者は一度株で大損こくべき

プログラミングとは直接関係ないですが、営利組織の舵取りに不可欠な意思決定について。

さてさて自分は投資については全くの素人なのですが、その世界ではわりと有名なプロスペクト理論(元は行動経済学の概念だそう)というのがあります。簡単に言うと

・人間は目の前の利益が手に入らないというリスクの回避を優先し、損失を目の前にすると損失そのものを回避しようとする。

と言う事だそうです。つまり、自分自身の意思決定が人間のこのような性質に影響をうけていると言うことを客観視出来ない人は、「まだまだ上がる余地があるのに上昇中の株価が反転するのが怖くて早々に売却してしまう」「値下がり中の株の含み損が売却によって確定するのを躊躇し、いたずらに損失を拡大させてしまう」という利益を上げるといった観点では逆の不合理な行動をとってしまいます。

さて、これは投資に限った話ではなく企業で行われる意思決定においても非常に似たようなケースがあるのではないでしょうか。例えば

・商談中の顧客が明らかに無理な要求をしてきているのに、失注を恐れて強気に交渉したり、切ったりすると言うことができない。
・事業がずっと赤字を垂れ流しているのに、今まで行ってきた投資を考え撤退の決断ができない。

意思決定者がこれらの責任を全面的に取ってくれれば良いのですが、残念ながらここで生じた歪は現場に降りてくるんですよねー。何故なら責任転嫁以前に自分がこのような性質にモロに流されていると言うことを彼もしくは彼女自身が認識出来ていないので、自分に非があると全く思っていないから… その挙句の、激務、長時間労働、デスマーチと言うのはもう鉄板と言っても良いぐらいお決まりな流れな気がします。

そういうのを考えると、やはり一度個人的に株で大損こいて、その理由についてきちっと消化&対策出来ている人の方が良いマネージャーや良い経営者になる可能性が高いような…

(そんなん無理やろと言うツッコミは置いておいて)少なくとも自分はそういう人の下で働きたいですね。

C++ std::regex_token_iterator で文字列を split (token 分解)

完全に boost ::tokenizer 相当と言うわけでは無いですが、C++11 から追加された正規表現ライブラリに std::regex_token_iterator  と言うイテレータが含まれており、これを文字列の split に利用する事ができます。

std::regex_token_iterator (cppreference.com)

詳細については上記のリンクを見ていただくとして、std::regex_token_iterator の基本的な使い方は以下のようになります。

上記の例を見て頂ければ分かると思いますが、コンストラクタの第4引数に正規表現でキャプチャした文字列のうちどのインデックスのものをイテレーション対象にするかを指定します。インデックスには 0 と -1 を指定することが可能で、0 を指定した場合はマッチした文字列全体が、-1 を指定すると対象の文字列全体からマッチした部分を取り除いた断片がイテレーションの対象になります。

この「マッチした部分を取り除いた断片をイテレーションする」と言う機能を利用すると split 処理を書く事ができ、例えば

のようになります。

ただ処理速度的にはアレだと思いますので、速度が要求される場面では従来から行われている愚直な処理の方がマッチするのではないかと思います。

 

C++ で Worker Thread パターン

Worker Thread とは一般に生成、破棄コストの高いスレッドをプールして使い回すためのパターンで Thread Pool とも呼ばれます。 Worker Thread パターンは Producer-Consumter パターンに基づいており、キューで受け渡されるのがデータではなく実行可能な仕事を表現したオブジェクトである点が特徴です。

以下の例で Runnable は仕事の基底クラスであり、std::shared_ptr<Runnable> のキューをを介してプールされているスレッドに仕事を依頼します。 クライアントは Runnable のサブクラスを作成し、インスタンスをスレッドプールに add する事で自分でスレッドをハンドルする事無く非同期に仕事を実行させる事ができます。

実際に使用してみると以下のようになります。 以下の例では WorkA, WorkB という異なる2つの内容の Runnable サブクラスのインスタンスを add しています。 仕事は Runnable で抽象化されていますので WorkA、 WorkB 以外にも任意の仕事を実行させる事が可能です。

Runnable のような基底クラスではなく特定の仕事クラスのキューを持たせる事も可能ですが、より汎用的にするためにこのようにするケースが多いように思います。また C++11 からは std::function が利用できますので、std::function のキューにするとより C++ っぽいかもしれません。

std::function 版の使用例です。

C++ でマルチスレッドデザインパターン

C++ の char, signed char, unsigned char は違う型 ?

結果から言うと char, signed char, unsigned char はそれぞれ違う種類の型です。試しに以下のコードを実行してみると結果は上から true, false, false  になります。

なぜこんな事になるかと言うと、元も子もないですが、そう規格で決まっているからです。 試しに C++14 の Working Draft を見てみますと。

3.9.1 Fundamental types

Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementationdefined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types, collectively called narrow character types.

C++14 のドラフトを引用しましたが、これに関しては以前と変わっていません。

「char型が符号付きか符号無しかは処理系依存」というのは組み込み系では比較的よく知られていると思いますが (開発環境によってはどちらにするかIDE上でユーザーに設定させるものある)、 「型の種類が全く別」というのは案外認識されていないかも(?) 型を細かく分けてオーバーロードしている時とか、メタメタしたコードを書いてる時とかに意図した結果にならずにハマるかもしれませんのでメモ …

Majestouch 日本語108キー・無刻印キーキャップが発売!

キーキャップを自分で塗装して真っ黒にするか… それとも元々無刻印ラインアップのある104 配列か HHKB に乗り換えて後戻りの出来ない道に進むべきか… どうしようか悩みに悩んで、色んな誘惑に耐え、こいつの登場をどれだけ待った事か!!

Majestouch 交換用キーキャップセット 日本語108キー・無刻印

早速3セットほど予約しました。

FILCO

換装しました。

AutoHotKey を使ったなんちゃって Vi のすすめ

「タイピングが遅いデキるプログラマ」と言うのを少なくとも自分は見たことがありません。

「なんて美しい設計なんだ…」「この選択肢は以外ありえない!」というようなコードを一発で書くことが出来る天才中の天才であればいざ知らず、凡人にはやはりコードを書いて試行錯誤しながら設計をつめて行くという作業が必要不可欠です。そういった視点で考えると「いかにストレス無く快適に素早くタイピング出来るか」と言うのは良いコードを書く上ですごく重要なのではないでしょうか。

ところでタイピングする上でのストレスといえば

(1) キーボードの打鍵感の悪さ
(2) ホームポジションを崩しての移動

が結構大きな割合を占めているのではないかと個人的に思っています。

「あなたはプログラミング以外何もしなくて大丈夫です。環境もご希望のものをどうぞご自由に」と言った恵まれた職場にお勤めの方は 「HHKB」+ 「お気に入りのエディタ」で全て解決!何も思い悩む事はないのでしょうが、そうで無い場合は大人の事情 (ノーマルなキーボードも頻繁にタイプしないといけないとか、プログラマ御用達エディタ以外にも色々と使わないといけないとか、私物の周辺機器を会社の PC に接続するの禁止とか、2万円以上するキーボードを会社の経費で買いたいって!?正気か?とか… ) が絡んできて実に悩ましいところです。

でも実は (2) に関しては AutoHotKey と言うツールを使えば実質的に解決する事が出来ます。

具体的にどうするかと言いますと、殆ど無用なスペース左側の「無変換」キーとホームポジションからアクセス可能な適当なキーを組み合わせて、頻繁に使用するにも関わらずホームポジションから遠くに配置されてしまっているキーをエミュレートするのです。

跡地になってしまっていますが、元ネタはこちら  (AutoHotKey を流行らせるページ)

ちなみに、自分の場合は vi のコマンドを参考に以下のようなスクリプトを作ってカーソル移動系のキーをエミュレートしています。

vk1Dsc07B & i::Send {Home}
vk1Dsc07B & o::Send {End}
vk1Dsc07B & h::Send {Left}
vk1Dsc07B & j::Send {Down}
vk1Dsc07B & k::Send {Up}
vk1Dsc07B & l::Send {Right}

これでキーボードの打鍵感さえ我慢すれば、 どんな環境でも、どんなソフトウェアを使っての作業でも ホームポジションを崩す事無く快適にタイピングする事が可能です。(ちなみに無変換キーは左手の親指で押してます)

加えて AutoHotKey の大変便利なところが 「作成したスクリプトを付属のツールで exe 化して本体のインストールされていない PC 上でも実行する事ができる」と言う点で、USB メモリーやパブリックなネットワーク上に exe 化したスクリプトを置いておけば普段のタイピング環境をそのまま簡単に持ち出す事ができます。

null

ちなみに、情報システム部が許可したソフトウェア以外インストール禁止の会社の場合はもうぐうの音もでません…