中の人の徒然草349

おはピヨ♪休日を満喫しているインドリです♪
今日はコミュニケーション力について書きます。
私はよくIT業界ではコミュニケーション力を強調する人が多くて疑問に感じておりました。
コミュニケーション力は情報処理技術以前の問題であり、社会人として持っていて当たり前の能力なので、別に敢えて言うべき事ではないと考えていたのです。
しかし、ここ最近は強調しなければならない程、酷くコミュニケーション力がない人もこの業界にいる事に気付きました。
私はフリーのエンジニアなので自営業者であり、交渉相手は企業です。
ですから、日頃会話するのは重役の人ばかりでした。
まれに、ワンマン社長過ぎてどうにもならない人もいましたが、それは例外だと考えておりました。
また、一緒に仕事をする開発メンバーにそれ程酷い人はいませんでした・・・
今まで感じた事は、プログラマに設計や分析の事を言っても分かってもらえない程度の事でした。
ですが、居るんですよね・・・
私用でネットを使い始めてから、コミュニケーション力がないというものがどれほど凄いものか体験しました。
まず会話にならない。そして、会話にならないのでどうしようもない。
常日頃、仕様書・設計書といった書類をどう読んでいるのか気になります。
文章を読めないのであれば、仕様書はもちろんのこと、メンバー間で会話出来ないから、仕事を正常に行っているとは考えられないです。
きっと、周りの人がフォローしてくれているのでしょう。
それに、専門書を読んでいるとは思えない。
きっと、本も読まないのでしょう・・・
・・・・・・・・・・・・
もしかしたらIT業界の人ではないのかもしれませんね。
その可能性はあるものの、もしかしたらIT業界に於いてコミュニケーション力が強く提唱されるのは、その手の人が結構いるのかもしれませんね。
今までの私の印象は、技術者は専門用語を多用する傾向があるから、他の業種の人から誤解されるというものでした。
しかし、他の業種の人も専門用語を多用していますので、やはり多いのかもしれませんね・・・

コミュニケーション力は大事です。
文章の場合は前提を読みとりましょう。
どの文章も前提を全て列挙するなんて事はしません。
読み手の理解力も必要となります。
お客様は神様だならぬ、読み手は神様だと主張するコミュニケーション力がない人もいますが、コミュニケーションは双方があって成り立つものですから、必要最低限のマナーを守りつつ、相手の事を理解しようと努力しながら行いましょう。
しかしながら、コミュニケーション力といっても、技術者が求められているレベルは高が知れています。
心がけ次第で誰でも出来るレベルのものしか要求されません。
私は口下手で不器用すが、クライアントから余り注意された事がありません。
口下手な私程度でもいいのです。
そのぐらいレベルなのですからさっさと身につけて、IT業界内でコミュニケーション力の欠如が叫ばれないようにしましょう。

中の人の徒然草348

おはぴよ♪ゴールデンウイークが楽しみなインドリです♪
今日は何を書こうかな・・・
そうそう、技術者は理系だと不可思議な分類をされますが、国語力は大事ですよね。
私はずっと、文系／理系という区分が不思議で仕方がありませんでした。
世の中は2つの学問しか存在しないでしょうか？
勿論そうではありませんよね。あえて言うのならば、情報処理技術者は情報処理系なのです。
そもそも、人間を二分法で分ける自体が間違っています。
情報処理技術者だからといって国語力は必要です。
※国語力が必要でない職業なんてあるのだろうか・・・
あと、これは学問ではないけど、誰しも全員社会人としてもモラルは必要ですね。
インターネットだから何でもしていいと考える人も見受けられますが、インターネットは公共の場であり、当然モラルが必要とされます。
ですから、人として恥ずかしい行為は当然してはなりませんし、そういった判断力がなければ、技術者以前の問題だと思います。
そして、恥ずかしい事や間違ったことをしたら謝罪するべきです。
何でも騒げば通ると思うのは大間違いで、余計に恥をかくだけです。
謝罪出来ないのであれば、せめて黙るべきです。
そうしないと、インターネットは記録が残りますので、恥の上塗りとなります。
大勢で騒げば済むと考えている人がいるようですが、過ちは消せません。
間違いを犯したら如何に早く謝罪するのかが大事です。
それが出来ないのであれば、もうこれ以上過ちを犯さないのが妥当な行動だと言えるでしょう。
一番の正解は、初めから人として恥ずかしい行為はしないという事です。
全ての事柄は自分に返ってきます。
人を極度を非難すれば、自分も非難されます。
人に迷惑をかけたら、自分も人生がいまくいかなくなります。
人をストーキングしたら、自分の言動も見られます。
・・・・・・・・・
賢明なる皆様は余計な事をせずに、普通に社会人としていきましょう。
特に自営業者には絡むのはよしておいた方がいいですね。
自営業者は弁護士の知り合いぐらいいるものです。
インターネット中毒の人は現実感が薄れる傾向があるようですが、日本が法治国家であることを忘れない方がよいかと思います。
そもそも、その様な事をしている暇があったら自分を鍛えましょう。
そして、良心的な言動を心がけておけば、インターネットはもちろん事、住みやすい世の中になっていきます。
そうすれば、自分も幸せになります。
人にストレスをぶつけると余計に人生が悪いものになります。
普通にちょっと親切に生きる。
全員がそうすれば、住みよい世界になります。

中の人の徒然草347

こんにちは。春らしくない気候が続き、ちょっと憂鬱なインドリです♪
私は晴天が好きです。天気が良いと、気分まで良くなります♪
だから昔は、雨だとちょっと気分が沈みがちでした。
でも、ある時友人は雨が好きだといいました。
その話しを聞いて、意外と雨も良いものだと感じるようになりました。
そういえば、私が好きな曲もショパンの雨だれです。
耳を良くすませば、雨は素敵なハーモニーを奏でるのかもしれない。
それに、農家の人にとっては恵みの雨かもしれないしね♪
天気に限らず、何事にもそういったことがありますよね。
物事を多面的に捉えられると、自分の世界が一気に広がります。
何事に対しても、狭い視野で偏見的に見ず、広い視野で多角的に見ると良い事があると思います。
私は常にこれを心がけて、広く学習をしております。
こうすると、仕事でも色々いい事があります。
皆様も是非、広い視野と多角的なものの見方をするよう心がけてください。
人生楽しくなりますよ♪

中の人の徒然草346

おはピヨ♪今日も情報処理技術を啄ばんでいるインドリです♪
昨日は関数型言語の強力さについて思いを馳せていました。
その力の源は、やはりプロセスとデータを同様に扱える事かな？
改めて考えてみれば、データもプロセスもバイナリ。
同様に扱えない事はない。プロセスもデータも情報なのですから・・・
ただ、Lispが流行らない理由もそこにあったと思います。
何故ならば、人間は区別を好むからです。
人間の知的活動は、物事を区分することから始まります。
ですから、プロセスとデータを一緒に扱うとなると、抵抗感があったり、考えにくいと感じるのも無理もない話です。
ですが、昨今は関数型言語の特徴を取り入れる命令型言語が大半であり、本当の意味での普及状態に入ったのだと思います。
これからは、言語のパラダイムを考える事自体が無駄になってくるでしょう。
その時、特徴が残るのはどの言語なのか、プログラミング言語とは何なのか・・・非常に興味深い課題です。
プログラミング言語が完全にマルチパラダイムになった時、違いは文字列のフォーマットでしかないような気がします。
さらに、そのフォーマットが自由に変換出来れば、なんの言語で開発しても違いはありません。
.NETやJavaなどの仮想マシンを使用する環境は既にその兆候がありますが、プログラミング言語が進化する事により、それが全言語に拡大する可能性があります。
そうなってくると、最適化能力と開発環境で違いをつけるしかありません。
それは、嬉しくもあり、寂しさもあり、複雑な気分です。
今後自分のプログラミング言語を設計＆実装しますので、その辺を今後も考えていきたいです。

中の人の徒然草345

こんにちは。休日を満喫しているインドリです♪
昨日、久し振りにHaskellプログラミングしてみました。
やはり、純粋関数型言語は独特ですね。
あまり関数型言語でプログラミングしないものだから、プログラミングしにくいのですが、この言語は非常に興味深いです。時間に余裕が出来たらモナドの実装を詳しく調べたいです。
他にも、Clojure、Oz、Scala、F#、Elang、Rubyあたりをもっと堪能したいです。
普段の仕事では命令型言語ばかり扱っているので、こういった言語を扱うのはよいストレス解消になります。
それで仕事にこれらの言語を使えないかを考えてみたところ、ライブラリ次第だと思い至りました。
仕事となると、納期がありますので、生産性が大事です。
そして、生産性を上げる要因を考えたところ、先ず第一にライブラリが大事だなと考えたわけです。
開発環境については、最悪の場合テキストエディタとバージョン管理ソフトだけいでも何とかなるけど、ライブラリがなければ非常に苦しいです。特にGUI系のライブラリがないと辛い。
その点を考えると、これらの言語は仕事に使うのは十分に可能だと思います。
理想的には継続的インテグレーションを実現するツール類が必要となりますが、そういったツールもどんどん作られていくでしょう。関数型言語や論理型言語を使わない理由は、どうも慣習的な部分が多そうです。
私の思想は「使えるものは何でも使う」だから、使えるものがあるならば何故使わないのか不思議でなりません。
Scala・Clojure・F#はGUIも別に問題がありませんし、プロジェクトの特性に応じて使えばいいと思います。
私は前から不思議だと感じていたのは、日本のIT業界が保守を言い訳にして、使う言語や開発ツールなどを制限するところです。製造者の都合により、お客様にその都合を押しつけていいのでしょうか？
これはあくまでも私個人の考えですが、プロならば使えるものは何でも学習して、よりよい製品をより短期間で提供するべきだと思います。
こういうことを言ったら教育コストが・・・という言い訳をする人が出てきそうですが、基本的に実践を通じて学ぶべきものです。お受験じゃないのだから、何時までも机上で学習する必要はありません。短期間でサクッと要点を掴み、後は実践で鍛えるべきものだと思いますので、教育コスト論に疑問が生じます。
教育コストを理由に挙げる人は、画一的に学校のように学習させることを考えているという印象があります。
そんな余計な事をせずに、技術者同士で技術交流する時間を会社が与えればいいと思います。
変化が早いIT業界に於いて、鍛練するというのは当たり前の事であり、そういった事を考慮していない会社が多い事実は不思議でなりません。情報処理技術は変化が早いから常に学習させないと、ちゃんとしたシステムを開発できません。
情報処理技術を提供する会社は、情報処理技術の特色を考慮するべきなのです。
そういった環境が整っていない会社が多い要因は、多分この産業は日が浅いからでしょうね。
色々な技術が出てくるのは嬉しい事ですが、そういった経営面の研究も進んでほしいなと私は思えてなりません。

書籍をつつく139ー並行コンピューティング技法。2冊目以降に読むべき良書。

お久しぶり♪最近レビューを書いていなかったピヨ。ごめんね。
今回は並列処理に関する書籍を紹介するピヨ♪



この本は何らかの並列処理入門書を読んだ後に読むべき良書ピヨ♪
これからその辺を囀るから先ずは目次を見てね。


【目次】

The Art of Concurrency和訳書籍への推薦文
訳者まえがき
まえがき

1章 速くしたい人、手を挙げて!
1.1 さまざまな疑問
1.2 スレッド化の4つのステップ
1.3 並列アルゴリズムの背景
1.4 共有メモリプログラミングと分散メモリプログラミング
1.5 並行プログラミングへのアプローチ

2章 並行か非並行か? それが問題だ
2.1 並行アルゴリズム設計モデル
2.2 並列化不可能?

3章 正当性の検証と性能測定
3.1 並列アルゴリズムの検証
3.2 例題:クリティカルセクション問題
3.3 性能指標(現状把握)
3.4 並列性に対応するハードウェアの進化

4章 マルチスレッドアプリケーション設計の8つのルール
4.1 ルール1:真に独立した処理を特定する
4.2 ルール2:並行性はより上位で実装する
4.3 ルール3:コア数増加に備えスケーラビリティ対応を早期に計画する
4.4 ルール4:スレッドセーフなライブラリを使用する
4.5 ルール5:適切なスレッドモデルを採用する
4.6 ルール6:実行順序を前提としない
4.7 ルール7:ローカル変数を使用する、できなければロックで保護する
4.8 ルール8:並行性向上のためのアルゴリズム変更を恐れない
4.9 まとめ

5章 スレッドライブラリ
5.1 抽象化ライブラリ
5.2 明示的スレッドライブラリ
5.3 その他のスレッドライブラリ
5.4 特定分野のライブラリ

6章 並列和とプリフィクススキャン
6.1 並列和
6.2 プリフィクススキャン
6.3 セレクション
6.4 章のまとめとして

7章 MapReduce
7.1 並行map処理
7.2 並行reduce処理
7.3 MapReduceの応用
7.4 MapReduceの一般的並行性

8章 ソート
8.1 バブルソート
8.2 奇偶転置ソート
8.3 シェルソート
8.4 クィックソート
8.5 基数ソート

9章 サーチ
9.1 未ソートデータ
9.2 バイナリサーチ

10章 グラフアルゴリズム
10.1 深さ優先探索
10.2 全頂点対最短経路
10.3 最小スパニングツリー

11章 スレッド対応ツール
11.1 デバッガ
11.2 性能解析ツール
11.3 その他のツール
11.4 前へ進め、そして打ち勝て

用語解説
Photo Credits
索引

コラム目次
2分で分かる並行プログラミング入門
観点別設計スコアカード
デッドロックを発生させる4つの条件
プリフィクススキャンを用いた配列のパッキング
総当たり方式でルービックキューブ問題は解けるか

どう？この書籍の良さがわかったかな？この書籍は並行処理／並行処理について広範囲の知識を提供している本ピヨ。目次からもそれが読み取れるピヨ。勿論ボクはその点を期待して読んだピヨ。そして、実際に読んで期待通りの本だと分かったピヨ♪
この手の本は、大概特定の技術に関するプログラミングだけを解説しているものが多かったけど、この本は設計まで踏み込んで書いているピヨ。おまけに、並列アルゴリズムの考え方も書いてあるピヨ。ボクにとってはその辺が非常に気にいったピヨ♪
この本のレベルは、並列処理初心者からちょっと上ピヨ。ボクはその辺が気にいったんだけど、初心者レベルを期待していた人には残念な事かもしれないピヨ。ボクが思うに、並列処理入門者用の本を先ず読んで、ちょっと慣れてからこの本を読むと良いピヨ。
褒めてばっかりではレビューとは言えないから、ちゃんとこの本の弱点も書くピヨ。この本の弱点は話題が広い分ディープさが足りない点ピヨ。正直言って、ボクはもっと濃いのが欲しかったピヨ。ページ数と話題の広さから考えて仕方がないことだと思うけど、次の版で情報量を増やすか、別冊でテーマを絞って濃い本を書いてほしいな。20年以上も並行処理／並列処理に携わっている偉大なるClay Breshears 氏ならば絶対に可能だから、濃い続編を期待しているピヨ。
その弱点はあるものの、2冊目以降に必ず読むべき良書ピヨ♪要点が簡潔に述べられているし、書くべきことはちゃんと書かれているピヨ。著者の凄さが随所から伝わってくるピヨ。既にマルチコア時代になっているから、システム開発をする人は絶対に読むべき本だと言えると思う。
この本を読んでマルチコア時代を生き抜こう！


【追加情報】
違う本を知りたい人は書籍レビュー目次と書籍レビューを見ると良いピヨ♪

中の人の徒然草344

おはようございます。今日も元気なインドリです♪
今日は何を書こうかな・・・
最近これと言って書く事がないんだよな・・・
そうだ！たまには、情報処理技術以外の事も書こうかな♪
ということで・・・
最近気候がおかしいですよね。
いきなり寒くなったかと思えば、次の日には暑くなったり・・・
気候の変動が激しいと体調を崩しますし、気分的にもいいものではないですよね。
私はこのまま異常気象が進めば、日本から四季がなくなるのではないかと不安です。
やはり四季がある方がいいですよね。
四季は美しいし楽しいです。
四季を楽しむ事が出来なくなると、人生の楽しみが減りそうです。
日本の良さは色々あると思いますが、やはり四季は外せない。
四季の風景にはそれぞれ美しさがあります。
でも、既に季節の特徴が弱くなっているという気がします。
例えば冬には、私が幼いころには雪が積もったりしたのですが、今では殆ど降らない。
あの冬景色が楽しめないのは非常に残念です。
このまま異常気象が進むと、孫の代になる頃は「雪って何？」とか言われそうです。
さらには、季節が減って二季とかになっているかも・・・
そんなのやだな。
願わくば異常気象がなくなりますように・・・

中の人の徒然草343

おはピヨ♪マルチパラダイムなインドリです！
今日も朝起きてから、ぼーと並列処理について思いを巡らせていました。
そこで考えたのが、並列処理は今までの常識を変えるという事です。
例えば、メソッドの引数を多くするよりも、プロパティ等を使用して引数を少なくし、メソッド呼び出しのパフォーマンスを向上させる事が提唱されていました。
※スタックされるデータ量が減るからパフォーマンスが向上するという事。
でもそれは逐次処理だから通用する事です。
並列処理になると、そんな事をしたら同期処理が増えますし、並列度が低下しますので、パフォーマンスが逆に低下します。
そういった事が多々あります。それを難しいと感じる人も多いでしょう。
しかしながら、グローバル変数を極力使用しないとか、従来からも言われている共通点もあります。
だから、あんまり気にしなくても思います。
OSやデータベースについて考えていると、それらの事はおのずと分かる事ですし、我々の政界は並列的なので、実のところその方が自然な考え方です。
リラックスしたら自然と分かります。
素直になればいいのです。情報処理技術は変化が早いので、素直さが一番大事なのかもしれません。
とにかく、ラブ＆パッションです！
呼吸をするように自然と情報処理技術について考えていれば、自然とレベルアップします。
例えば、歩道でセマフォについて思いをはせましょう。職場でのトラブルからデッドロックを感じましょう。
そうした姿勢が苦痛なく技術力をアップさせます。
常に情報処理技術について考えていれば、素質なんて関係ありません。
情報処理技術は特別な才能を必要としません。
気楽に情報処理技術を楽しもう♪

中の人の徒然草342

こんにちは。副作用を避けたいインドリです♪
突然ですが、私はよく情報処理技術の壮大さを考えます。
現実は並列処理で動いており、その同期手法における不備で様々な問題が生じていますよね。
これ一般的に言うと、コミュニケーショントラブルだとか、連絡ミスと言われているものです。
さらにえば、人間のトラブルの多くは、情報処理におけるバグの様な気がします。
完璧に互いの情報が通信できて、おまけにそれが徹底的に最適化されていると、トラブルはずいぶん減るでしょう。
残るのは感情の問題です。
でもそれも人間から発生する情報の一種であり、処理できるような気もします。
ですから、情報処理技術者の役割はもっと広く、非常に重要なものです。
でも現実は、情報処理技術の大切さがあんまり認識されていないんですよね・・・
戦争も経済も科学も政治も交流も・・・全てが情報が大切です。
人間の歴史は、数字・文字・言語・電話・手紙など様々な方法で情報処理がなされており、情報処理の技法により発展してきました。
つまりは、人間が力を合わせていくためには、情報処理が必要である事を意味しているのでしょう。
如何にして人間同士が情報を通信し、種全体で反映していくか・・・
そういった大きなテーマを、人類は考える必要があると私はよく考えます。
それとともに、人類が今まで育んでいた技術や知識はもちろんのこと、大自然の理に情報処理技術をより発展させる宝が沢山埋まっている事を感じます。
実際に私は、月を見て発明を思いついた事があります。
自然を感じる事により、アイデアが生まれます。
この業界の人は、室内で居る事が多いと思います。
そして、日本の組織はそういった見た目の真面目さを求める傾向があります。
しかし、そんな事をしてもいい発想は生まれません。
形式的に真面目な感じを醸し出しても生産性は上がりません。
我々は生産をするために仕事をしているのです。
表面だけを取り繕うよりも、より柔軟に、より効率的に、生産する環境作りをする必要があると私は思います。
我々はビジネスをしているのであって、学生ではありません。生産してなんぼです。
努力している雰囲気を醸し出す事に力を注がず、生産をする事に力を注ぐべきです。
そういった事を皆が考えれば、不景気なんて怖くないのにな・・・
世間は不景気ばかりを連呼していますが、原点に帰れば景気も上向きになると私は思えてなりません。
以上。取り留めもなく考えた事を綴ってみました♪

中の人の徒然草341

こんばんは。寒さに弱いインドリです。
いやー、最近寒いですよね。こんなに寒くなるとは思わなかった。
寒いので、ちょっと厚着をして生活しています。あー冬眠したい・・・

それは、さておき、並列処理と関数型言語を学習していると、従来の逐次処理が難しい事をしていたと感じます。
というのも、副作用をもたらす処理ばかりだからです。
特にI/O関係なんて、副作用ありまくり！
だから、並列処理ではI/Oが鬼門になるんですよね。
かといって、副作用を全て避けるのは難しいですよね。
でもそれは、私の未熟さもあるでしょう。
これからは、如何に副作用を避けるのかを学ぶ必要があります。
きっと数年もたてば、副作用を避けるのは当たり前の事になり、副作用を伴う処理の方がマイナーになるのに違いない。
副作用がない方がテストもやりやすいし、いいことずくめだもんな。

話題はまた変わりますが、コンパイラを並列処理で実装する場合、シンボルテーブルが問題になります。
シンボルテーブルを上手く扱う方法はないものだろうか？
先ず思いつく手段としては、fork/joinの方向性かな？
ミニテーブルを処理ごとに作って、後で結合するとか・・・
うーん、でもこれ、直ぐに結合するとパフォーマンスが劣化するから、結合処理自体を削減したいな。
そうなると、コンパイラ全体で使用する情報を整理整頓して、処理もちょっと工夫しないと駄目だよね。
やっぱり、直列アルゴリズムでは駄目で、並列アルゴリズムを考えださないと・・・
もっと、研究の必要がありますね。

それにしても、ガベージコレクションのアルゴリズムと実装がまだ入手できないorz



げぇ、今見たらAmazonで入手できるみたいだ・・・
Amazonで手に入らないから違う所で注文しちゃいました♪・・・（泣き）
急がばまわれですな。早く読みたい！でも2冊買うのもあれだし我慢するしかない。
早くガーベッジコレクト堪能したいな！