読者です 読者をやめる 読者になる 読者になる

impedance(インピーダンス) 全てに抗え!!

この世の全てに歯向かい、抵抗することでしか存在を見いだせない愚直な漢のオルタナティブ? ブログ

将棋に負けるとなぜこんなにも悔しいのか。

将棋愛好家なら誰しも経験していることだが、将棋に負けるのはホントに悔しい。

 

「負けた」という事実をすんなり受け入れらず、あれこれ言ってその場をのたまいたくなるし、

それでもその事実を中和、転嫁することが出来ず、胸が張り裂けそうになる。

 

特に悪手、緩手を咎められたり、相手の指し手を見落とした時やるせなさといったら。

己のふがいなさにすごく落ち込むし、それと当時に、むらむらと怒りが込み上げてくる。

腹いせに誰かをぶん殴りそうになる。(やらないけど…)

 

もう、将棋盤も見たくないと思うほど嫌いになる。(それでもまたやるのだが...)

 

なぜ、こんなにも悔しいのか。

 

将棋はお互いが1手ずつ交互が差し手を進めていくゲーム。

自分の出番になったら、当然だが、自分で自由に指し手を決められる。

「制限時間内に指す」という制約はあるものの、それ以外は誰にも邪魔されない。

 

ただ、それゆえに、指した手は紛れもなく自分自身で選んだ手である。

 

もし、指した手が敗着となった場合、当然ながらその原因は誰でもなく、(自分自身が決めた)「その指し手」に帰結する。

また、それが制限時間に追われて考えきれずに指した手であっても、

(自分自身が決めた)「指し手」であることに替わりはない。後で何を言おうとそれは言い訳でしかない。

完全に自己責任。「自分自身が負けにした。」という事実からは逃れられない。

 

そこに気が狂いそうになるほどに湧き上がる悔しさの根源が眠っていると思っている。

 

誰のせいでもなく「自分自身が負けにした。」という残酷な結果を、ただただ受け入れるしかない。

そこには、誰かに直接言われたわけでもないが、「自分自身が不当であった」というサジェスチョンが発生し、

そこにたっぷり含まれているある種の軽蔑的なメッセージが、いやおうなし神経を逆なでする。

 

話しは変わって、ここ最近、将棋界でいろいろ問題を指摘されているが、

将棋自体は奥深いマインドゲームだとともに、日本が世界に誇る文化でもあると思っている。

 

「界・道・盟の精神」(もはや死語か)とまでは求めないが、品位を落とすことはしないでほしいととみに思う。

C++ 二次元配列の動的生成について

掲題の件、以下のステートメントが紹介されているサイトをよく見かける。

--------------------------------------------------------------------

// 動的生成(smax * slen)

char **s = new char*[smax]

for(int i = 0;i < slen;i++)  s[i] = new char[slen];

 

// 上記ステートメントで動的に生成したメモリ領域の開放 

for(int i = 0;i < smax;i++)  delete s[i];

delete s[i];

--------------------------------------------------------------------

 

しかし、上記ステートメントだと、配列sは厳密には「2次元配列」((smax * slen)個分)としてではなく、

「ポインタの配列」((1次元配列(slen個分)の先頭要素のポインタ)の配列)として作成される。

 

【根拠】

以下のソースでコンパイル時にエラー「no matching function for call to 【関数名】」となる。

--------------------------------------------------------------------

const int smax = 3;

const int slen = 7;

 

void print(char x[slen], int n)

{

cout << x[n] << endl;

}

 

void strcopy(char dst[slen], char src[slen], int i)

{

/* srcの文字列をdstにコピーする */

]

 

int main()

{

char[slen] = { ‘First’,’Second’,’Third’ };

 

// 配列を動的生成

char **s = new char*[smax]

for(int i = 0;i < slen;i++)  s[i] = new char[slen];

 

// 配列に値をコピーする

for(i = 0;i < max;i++)  strcopy(s, p, i)

 

// 配列の中身を画面表示 

for(i = 0;i < smax; i++)  print(s, i);

 

// 動的に生成したメモリ領域の開放 

for(int i = 0;i < smax;i++)  delete s[i];

delete s[i];

 

return 0;

}

--------------------------------------------------------------------

 

2次元配列を仮引数としている関数strcopy()に、動的に生成した配列sが受け渡しが行えないというエラー。

  ※ 尚、同じ2次元配列pについては、コンパイルでエラーとなっていない。

 

配列sは2次元配列として作成したつもりだったのだが

「2次元配列として受け渡しが行えない。」となると、

論理上、配列sは「2次元配列として作成されていない」ように思う。

 

以下のように動的生成すればOK

--------------------------------------------------------------------

// 要素がslen個分ある配列を、smax個分動的生成。(smax * slen)

char (*s)[slen]= new char[smax][slen]

 

// メモリの開放

delete s;

--------------------------------------------------------------------

 

以下のソースでコンパイルしたところ、正常終了した。

--------------------------------------------------------------------

const int smax = 3;

const int slen = 7;

 

void print(char x[slen], int n)

{

cout << x[n] << endl;

}

 

void strcopy(char dst[slen], char src[slen], int i)

{

// srcの文字列をdstにコピーする 

]

 

int main()

{

char[slen] = { ‘First’,’Second’,’Third’ };

 

// 配列を動的生成

char (*s)[slen]= new char[smax][slen];

 

// 配列に値をコピーする

for(i = 0;i < smax; i++)  strcopy(s, p, i);

 

// 配列の中身を画面表示

for(i = 0;i < smax; i++)  print(s, i);

 

// 動的に生成したメモリ領域の開放 

delete s;

 

return 0;

}

--------------------------------------------------------------------

 

<動作環境>

MacOS 10.2.3、Xcode 8.2.1

Darwin 16.4.0、gcc 9.2.1

 

以上。

 

walkman

出先等で音楽聞くのにiPod(第四世代)使っていたのだが、

10年以上も使っており、電池切れが早まってきており、パフォーマンスに物足りなさを感じていた。

また、iTunesに保管している音楽データが結構増えてきており、今現在、全ての音楽データをiPodに転送出来なくなった。

 

そろそろ、新しいポータブル音楽プレーヤーが欲しいと思っていた今日この頃。

 

Macユーザということで、買い替えるのならiPod Touchとなるのだが、

既にiPhoneを持っており、iPod Touchって「iPhoneの廉価版」というくらいに機能スゲーカブっているのよね。

同じもの2つ持つの嫌だ。

 

また、既に使っているiPhoneに音楽データ入れて使うのも、、

もし音楽プレーヤーは電源が切れていたも、「あっ、電源切れた。」と思うだけなんだけど、

iPhoneは会社や現場との業務連絡手段で使っているため、電源が切れているのは痛くて、そのへんがすこし違う。

iPhoneに音楽プレーヤーのややがさつな取り扱いを持ち込みたくないため、音楽プレーヤーは別に所持したい。

 

あれこれ考えましたが、SONYwalkman(NW-A30)を選びました。

 

f:id:SHAKARIKI:20170211180437p:image

 

ただ、幾つか気につく点が…

 

まず、iTunes内の操作でのwalkmanへの音楽データ転送ができないのね。

  ※ iTuneswalkmanバイアスが識別出来ないようである。

 

WindowsだとiTunesの替わりにMedia Goという専用ソフトがあり、

それで音楽データをライブラリに管理したり、walkmanに自動転送する機能が具備されているのだが、

そのMedia GoMacに対応してない。

  ※ まぁ、対応してたとしても、Macユーザなら、音楽データの管理はiTunes使いたい。

 

じゃどう音楽データを転送するのかというと、

データを転送する機能だけ具備したContent Transferというツールがあって

ただただ、ドラックドロップで手動で転送してくれっていう…。

 

原始的ですね。(嫌いではないのだがね。)

 

一応Content Transferにも自動転送機能はあり、「おっ」と思ったのだが、

音楽データを外部HDに保管しており、そのフォルダを指定して転送しようとすると以下のメッセージ。

 

f:id:SHAKARIKI:20170211175303p:plain

 

外部HDを認識してくれないみたい。冷たいねぇ。

 

結局、手動で音楽データを転送しました。(3253曲 約20GB)

2、3時間かかったよ。

 

Macをメインで使っているのであれば、iPodシリーズをチョイスするのが無難だったかもしれない。

結構お金払ったし、痛いが、少し教訓にはなったか。

 

追伸 : 今年もよろしく…

校正と校閲

ある日、とあるジャズバーでマスターや常連客とたわいのない話をしていた中で、「校閲」についての話になった。

  ※ そういや、今、テレビで校閲をテーマにしたドラマやっているらしいが…。

 

さてその「校閲」についてだが、それとは別に「校正」というのもあって、「校正」と「校閲」とでは意味が違うとのこと。

 

・校正

   出版物の誤植や体裁上の不備を正す。

     出来上がった原稿の1字1句を確認。誤字や脱字、表記のブレ等文字の誤りを修正。

 

・校閲

   原稿に記載されている内容が、事実に則ってるいるものかをを確認、訂正する。

      原稿に記載しているメッセージに対し、文献等を元に信頼できる情報を探し、徹底的に事実確認を検証するらしい。

 

この「校正と校閲」の作業。聞いた分には地味にキツそうだ。(キーキー言いそう。)

この大変さは広く一般になかなか認知されていないが、この「校正と校閲」を行うことで、出来上がりの出版物の品質が格段に違うとのこと。

 

俺、てっきり「校正と校閲」って同じこと言ってんのかと思っていたよ。アハハ。

 

いい話聞けたな。

 

ところで、このような「地味にキツイ」作業。程度の違いこそあれ、どの現場にもあるとは思う。

俺の配属先の現場にも幾つか思い当たるものがあるが、言いたいことがある。

 

それは、「この「地味にキツイ」作業の存在に向き合わない奴があまりに多すぎる。」ということ。

特に一部の勘違いリーダ各位については、この手の作業をアサインする人間を恣意的に選んで、頭ごなしに丸投げするしな。

 

以上。

 

追伸:

このあとそのジャズバーにライブ観にいってきまぁす。

その人来てるといいなぁ。

直電

配属先プロジェクトでは、客先からの問い合わせは等については、

契約上の都合および、作業の管理上の都合により、プロジェクトを統括している会社側で対応する取り決めとしており、

担当レベルとの直接のやりとりはなるべくは避ける取り決めとしている。

 

しかし、現実には、その統括している会社側で対応しきれなかったりすることもあり、

担当レベルでも客先からの電話での問い合わせ(以下「直電」という。)を受け、対応するケースも多々発生している。

このことについて、個人的には問題ないものと認識している。

 

ただ、その直電の回数が頻繁で、やりとりに時間がかかったり、また、新たな作業を依頼されることもある。

それが、客先からの依頼ということもあり、本来プロジェクトに必要なものかに関わらず、必然的に優先度が高いのものとなる。

また、客先側の都合で発生するため、作業タスクとしてピックアップおよびマネジメントがとてもしにくい。

 

すなわち、プロジェクトを進めるにあたって、事前にプランニングされていない作業が最優先で次々割り込まれる格好となる。

そうなるとその客先からの各種対応を優先的に作業することを強いられてしまい、本来の担当作業に対する稼働捻出が難しくなる。

 

このように「客先からの直電」については、プロジェクト進捗の妨げとなる要因に大化けする可能性を秘めている。(少しオーバーかもしれんけど、こんくらい言っておこう。)

 

そのようなこともあり、担当レベルは客先からの直電には、なるべく避ける取り決めとしている。

 

 

 

ある日、客先からの電話問い合わせが無条件でこちらに転送されることが少々多く感じたので、

上司にお話ししたら、こんな回答。

 

「一度電話受けているのであれば、直電ではないんしゃないの?」

 

はぁ?。バカにしてんのか?。

 

電話とってそのままこっちにパスすんのって、実質、直電と同意義だろうがよ。

 

その上司は、所属グループのマネジメントを行っているが、

客先からの直電が、上司が懸念している稼働超過の原因の1つになっているのに、それを問題視していないようだ。

 

すなわち、その上司の業務(マネジメント)はポーズだけということ。

以前からそのきらいはあったが、少し失望している。

 

以上。

「あそぶ! ゲーム展」行ってきました。

「あそぶ! ゲーム展」行ってきました。

http://www.skipcity.jp/vm/game/

 

ゲームセンターCXでも特集やってて、気になっていた。

 

中に入ると、各種デジタルゲームが展示されており、

オシロスコープをモニタにしてプレイする「テニス・フォー・ツー」や、

デジタルゲーム元祖といわれている「コンピュータースペース」から、

平安京エイリアン」、「ドンキーコング」等、バラエティに富んている。

 

ゲームもプレイ可能で、無料で何回でもプレイできる。

  ※ ただし、マナー上、ゲームのプレイを占有するのはご法度。

      ゲームオーバーになったら、他の人に人にゆずってください。

 

スペースインベーダのブース。テーブル筐体のやつ懐かしい。

昔、上級生がやってんのを見てて、すごく羨ましかった記憶がある。

で、スペースインベーダー久々にプレイしてたけど、感覚鈍ってんのね。すぐにゲームオーバ。

名古屋撃ち披露できず…。

 

子供よりウキウキしちゃってたよ。間違いなく。

 

もちろん、ゲーム機が展示されているだけではなく、

デジタルゲームの歴史についてや、技術的にどのような進化を遂げているのかもきちんと解説している。

 

この展覧会。シリーズで3回行われるとのことで、今回は初回のステージ1。

次のステージに何が展示されるのかとても楽しみだ。

 

追伸 : 今年もよろしく。

マンガン電池の行方

最近、マンガン電池見なくなったよなぁ。ととみに思う。

 

テレビのリモコンの電源が切れたので近くのコンビニで補充しようとしたら、

アルカリ電池ばかりでマンガン電池は売っていなかった。

 

確かにアルカリ電池の方がマンガン電池に比べ、パワーがあって、かつ、長時間の放電に向いているんだけど、

テレビのリモコンってそんなに長時間電気を使うわけではないので、マンガン電池がピッタリなんだよね。

 

価格もアルカリ電池よりもリーズナブルだし、まだ需要はあると思っているんだけどね。