所属思考からの解放

よくあることだが,「●●(会社や学校名)の△△です」という紹介がよくある.

名刺にも自らの所属を書き,自らのラベル付けを行っていく.

個人的なことではあるが,プライベートなイベントに関しては

自分の所属(特に会社名や学校名)は書かないようにしている.

なぜかというと所属が全く関係ない(別にお金を払ってもらっているわけでもない)状態で

わざわざ自らが好まないラベルを付けることが嫌いなためである.

第一,このラベル付けは自由を制限させる一つの要因になっているのではないかと考えている.

周りのひとは所属は重要かつ普遍的であると考えているようだ.

確かに,別会社の重役に会うときにはそのラベルを利用することは

重要なことであることは間違いない.

(そもそもそのラベルがなければ会ってくれないこともざらだ.)

しかし,私はラベルは普遍的である必要は全くないと思う.

それは,職業選択の自由という観点ではなく,自らが自発的に参加している物事に対してまで

不必要なラベルを張り付ける必要はないという観点からだ.

ラベルは剥がせない(普遍的な)ものではない.

自ら自由に剥がし,貼り付けられるものという認識.

物理的なノマドは馬鹿の一つ覚えのように言われているが,

精神的なノマドに対しての意識を高めることが

今後の仕事の方式(1人1人がそれぞれ技術,ノウハウを持ち,それらをそれぞれに合った企業や活動に対して活用していくという所属意識から解放された仕事の方式)を実行するうえで,重要なのではないだろうか.

祝500

めでたいのかよくわからないが500回見られているということを記念して.

多分,このブログが結構見られた時って

SQL World,VSハッカソン,鹿駆動会でのレポートの計3回しかないんじゃないかなと思います.

記事ごとのアクセス閲覧をグラフ化できないのかなとも思いますが,

そこらへんははてなさんが開発してくれることを祈るばかりです.

というより私はWeb系言語の経験がなさ過ぎて自分から作るとか言えない.

多分,アクセス履歴引っ張ってこれればなんとかなりそうかなとも思う.

Perlとかで引っ張って来れないかしら……

物事は表裏一体

物事を多くの面で表裏一体であることを意識的には理解していても,

如何せん肝心な時ではそのことを忘れていることが多い.

予定表には書いていたのにできていないであったり,

物事の結果のみにとらわれてそこまでの過程を理解していないということであったりと

正直,目も当てられない(自分のことだが)

物事が表裏一体であることを理解することが実は今の政治,ビジネスにはできていないのではないか

と感じることは多い.

このアクションを起こせばどのような影響を起こすのか?あるいはどのような影響を起こしたいのか?

利益とはなんだ?その一方で失われるものはなんだ?

理想は何だ?そしてその一方で理想実現において存在する義務は何だ?

現在の自らの強みはなんだ?そしてその一方に存在する弱みはなんだ?

全体を見れているか?そしてそれと同時に細部も見れているのか?

自己分析という言葉に押し込むことは非常に嫌なのだが,

社会自体が冷静な自己分析,そして物事に対して表裏一体であるという認識を

持つことが精神的な部分の課題の1つなのではないだろうか.

馬鹿のように公開する社会

Twitter,Facebook様々なSNSがブームとなり消えていく.

そこでよく聞くのが「本来話すべきではないことまで公開してしまう」という事例だ.

大学生がカンニングペーパーの作成を,飲酒運転を,新社会人が余計なことを話してしまったがために

悪事が表に出たり,バッシングの嵐を受けることになった.

それをSNSの管理側に対して文句をいうことはできない.

彼らは「良識の範囲内で」ツールを使うという前提があるのだから.

(腹の底ではどう思っているのかはわからないが表向きはこの前提を暗黙の了解として提示していると思う.)

自己責任という前提ですべて行う必要があることを私たちは意識的に,論理的に理解する必要があると思う.

SNS,ひいてはITの力によって何を得ただろうか.

ユーザ側のメリットとしては2つある.

多くの人とつながることで行動をすることができるようになったという点

そしてもう1つは今までの経験や作業を短縮できるようになったという点.

前者がSNSの,後者がビジネス向けのITの利点だろう.

逆にデメリットは何があるだろうか.

私としては「利用者が馬鹿になった」ということを挙げたい.

決して,利用している人全員が馬鹿だと言っているわけではない.

(その理論なら私は大馬鹿者だろう.実際,その理論がなくても事実として大馬鹿者だという認識はあるが.)

それは便利になったが故のモラルや考えることに対しての意識低下が主な原因だと考える.

そしてそのモラルの低下を臆面もなく世に出す.

その世に出すところでSNSがツールとして出てくる.

SNSはその部分において罪があると考える人が多いのはそのためだ.



私の持論としてITは最終的に人を駄目にするという可能性が高いと思っている.(正しくはITに限らず,どんなものでも突き詰めれば人を駄目にできるという考え.)

その考えを他の人に(不注意にも)話したことがある.

Facebookとかって態々顔を出して名前出して重要な個人情報を何の危機感もなく出させるようにする.人間をある種駄目にするツールだと思う」

その言葉に,その人は激昂し,反論してきた.

Facebookで昔の知人・知らない人とつながることができた」

Facebookで様々な情報を得ることができるようになった.」

こんな素晴らしいツールをけなすなんて信じられないとのこと.

なるほど.確かにそれはいいことなのかもしれない.

しかし,Facebookを通じないと本当にそれらはできないのか?

昔の知人であれば仲良かったらその時に連絡先等を聞いておけばいいではないか.ブログのアドレスを教えるでもいいだろう.

その時にコミュニケーションのツールがなかったとはあまり考えられない.

(その時にまだITが大きく普及していないならまだしも.郵便等でもコミュニケーションは可能だったはずだ.)

知らない人に関してはつながることで何を得たのか?とも思った.つながるだけであれば近くのコミュニティセンターでも行けば

つながりは作ることができるだろう.

(実際,私も地元のコミュニティセンターには足しげく通っている.如何せんつながりはご老人が多いのだが.)

様々な情報を知ることができたと言っているが,果たしてそれは本当に今までのツールでなしえなかったことなのか?

単に自分が出不精,情報収集の力がないことを言っているだけではないのか?

元々,Facebookに関していうとあれはインターネット上での個人の証明が他のSNSには見られなかった要素だ.

インターネットで人脈づくりも結構だが,その裏でしっかりとオフラインで会う.

言葉を交わすということがなければSNSも意味がないのでは……と考えてしまう.

ビジネス向けのITの功罪に関してはまた別の記事で書きたいと思う.

以上,屁理屈をこねるコミュニケーション能力がない大馬鹿者の支離滅裂な記事でした.

人間の安定性

私は数学の研究(まがい)をしているが,

その中で安定性という言葉がある.

まぁ簡単に言うと,ある点に収束していくものが安定

と考えてもらえればいいです.

(漸近安定とか大域的安定性とかいろいろあるけど数学的なとこは調べれば出てくると思う.多分.)

数学とかだとある程度決まった方法で安定性を判定するわけですけど.

人間における安定性とは何か?と思ってしまうときがある.

大体分けると人間を構成するものは物質的,社会的,精神的の3つに分かれる.

物質的安定性というと肉体的に健康であるかということ,

社会的安定性というと周囲とのコミュニケーションを問題なくとれ,違法なことを行っていないということ,

精神的安定性は物質的安定性と同じように精神的に健康であるかということになる.

さて,この安定性は定量的に判断が可能だろうか?

物質的安定性は血糖値であったり,体重等で見ることができるだろう.

問題は社会的安定性と精神的安定性.ここは確かめようとするとヒトの感性が入ってくるため

定量的な判断が難しい.

仮に,社会的,精神的に不安定な状態を定義しても安定な状態がどうなのかということは明確化できない.

結局.人間は不明確な安定の概念を持っているがゆえに,今の状態を曖昧な理想と比べて不安定と称することしか

できないのかもしれない.

鹿駆動勉強会に参加しました!その3

14人目の方は最強のオブジェクトとは?がテーマ.

bitの限界.

数値をオブジェクトとして扱うとメモリの制限以外表現し放題

学術のシミュレーションとかにも最適

カプセル化→隠蔽化

再利用性

疎結合なオブジェクトの利点→組み合わせがやりやすい.

しゃべる電卓

ポリモルフィズム多態性

継承

北斗の拳

SwingをWicketに変更させてWebでもオブジェクト指向


15人目の方Hadoopと浅草フレームワークがテーマ


HadoopとはOSSの分散処理ミドルウェア

中核はHDFSとMapReduce

浅草フレームワーク→バッチ処理をデータフローの視点に沿って設計をして

その設計をそのままおとしこめるJavaのDSLに

浅草フレームワークOSS!残念ながら途中終了


16人目の方はユニットテストについて

小さな単位でテストをすることが大事


17人目の方は

TDD Pre Camp 大阪4/30 6/2,3 TDDBC大阪の告知からスタート

最近の勉強会事情がテーマ

話す側の方が入る情報が多く,フィードバックももらえる

良いことはわかるが自分なんかが……ということに関しては

昨今の事情により緩和されてる.

発表する機会をどうやって作るか??

ノリも重要だが,その辺のLTに飛び込んでみる.テーマを大きく外してなければ失敗しても5分だし大丈夫

自分で主催する.



18人目の方は

公募でテーマを決定する.

テスト駆動F#がテーマに.


19人目の方は

カバレッジツール「Hippo」について

カバレジツールを作ってみた


20人目の方は

勉強会の作り方をテーマに.

鹿駆動勉強会がどのように生まれたのかという経緯を話してもらえました.



以上,20名の方のプレゼンでした.

なんというか,メモの内容がかなりひどい気がしますが,なんとなくでとらえてくれたらうれしいです.もっと的確に細かく書いてくれる人や発表資料をアップロードしてくれる方もいると思いますのでそこら辺を参照していただければよろしいかと.

感想としては,やっぱり5分で何かを伝えるということは難しいなぁということと周りの人のレベルが技術的にもプレゼンのレベル的にもすごく高いなぁと2つを感じました.

そして,今回の企画はすごく面白いと思いました.なんというかこのまま続いてもらって日本風TEDになっていってほしいなとも思いました.いかんせん,今は技術寄りの
内容ですから,今後,技術者じゃなくとも楽しめるライトニングトークイベントになればより面白くなるかなとも思いました.

もし,次回以降があればスピーカーとして出てみたいなと強く思いました.

最後になりましたが,

20名のスピーカーの皆様,そして会場をお貸しいただいた奈良県新公会堂の方々,そしてこのイベントを企画した素晴らしきスタッフの方々に最大の感謝を.

鹿駆動勉強会に参加しました!その2

鹿駆動会の続き.

こっからほぼ走り書きのようになっている.頭の処理速度が追い付いていない証拠です.

2番手の方はJavaFXJavascriptをテストするというテーマ.

JavaFXにはWebkitを搭載したWebViewがある.

だからJavascriptのテストをJavaでできるようになるかも!

余裕なかったのでなんもやってません!

ではいけないので最近やっていたことは

Swingのレガシーコードの回収やっていた

groovyで書いてたりしているらしいです.

残念ながら途中終了.


3番手の方はStarting JavaFXというテーマでした.

TwitterクライアントをJavaFXで作ってみたが具体的テーマ.

アンカーペインにポチポチと乗っけるわけですが,面倒くさいのでScene Builderで作るわけですね.

Twitter4jで作るが,非同期処理に注意すべきで.

重い処理は別スレッドで行うのがベータ.

別スレッドからビューを触るとデータ不整合が起こるからJavaFX Application Threadに

画面更新を任せる.

ListCellとList Factoryが使えるというところで残念ながら終了.


4番手の方のテーマはJavaと並行と私

スレッドセーフから話がスタート.

同時に動いた時に不整合が起きないように

synchronizedブロックで同期させるという方法がある(動くのは1人のみ)

volatile修飾子を使うことで回避もできる.

Concurrency Utilitiesを利用する.

ということで終了.



5番手の方のテーマはシステムアーキテクトをもっと目指してほしいという思いから,

システムアーキテクトになる前に覚えておきたい技術とか色々である.

Sierのなかで3年でPMに勝手に動かす会社がよろしくない.(生産原価が合わないだのどうのこうの)

そしてわざわざリスクのある方法をとってしまうのが

開発の技術リーダーがシステムアーキテクト



6番手の方は新米エンジニアが1年目を振り返るというテーマでした.

実体験で一番学びの多かった事例を紹介.

ソースコードレビューについてですが,先輩にコードを晒す恐ろしい儀式なわけですが,

経験知の塊と考える.ここから後輩は学んでいく.ソースコードをすることで,

後輩の不安を取り除いてあげると同時に学びの機会を与えることができる.

工数かけることが面倒という話があるが,鷹の爪のセリフから1琴出して終了



7番手の方,bash07Cの宣伝からスタート.

今に生きる奈良時代の技と術がテーマ.

技術の系譜と伝統的デバイスについて.

技術の系譜,これを見ていくと納得いくしどんどん楽になるし,進化が、見て取れるようになる.

伝統的デバイス,机上デバッグについて話を進めていく.

紙出し重要や机上デバッグ大事ということでなく,

ソースコードの読み解き技法がわかったことがよかった.BDD,仕様化テストなど.

JOJOから結果だけを見ていると近道していると真実を見落とす.

ソースコードをちゃんと読む,書くという真実を得られることができるようになった.

様々な物事の奥底にあるものを考えていき,戦い続けることが大事.



8番手の方は5分でわかるInvoke Dynamic

Javaがどうやって動いているか,Invokeの基本,

Javaはコンパイルすると中間ファイルを生成し,それをJVMで動かすという形.

ちょっと画面が見づらかったのが残念.



9番目の方はInnovationの話.

iPhone,Facebook,TwitterというInnovation

俺たちは世界を変えられるか

イノベーションを起こすための3つのソウ

継続的,破壊的イノベーションの2種類

どちらも行動が大事.

空想,構想,実装の3つ.

あったらいいな

どうやって実現するか

実現のための行動

リーンスタートアップやPDCAサイクルと類似しているというコメント

3つのソウを支えることは「なんかいいよねは禁止」

思考停止は禁止.



10番目の方は,MongoDBとか全文検索とか

MongoDBと相性のよいelasticsearch Java製の全文検索



11人目の方は,Nodeについてのお話.

Node.jsの話

Node学園祭の宣伝

Javascriptの限界突破

WebRTC,WebSocketを利用したデモ.

Javascriptもここまで来た!



12人目の方はSQL Worldでもお世話になりましたおださん

テーマとしてはJavascriptのテンプレートエンジンについて.

jQuery Templates→非推奨



13人目の方はPHPフレームワークKohanaについて

PHP用のWebアプリケーションフレームワーク

特徴:軽量,高速,ライブラリーフリー,HMVC,オブジェクト指向の利点を生かしやすい

すぐに使える!設定はほとんど不要.PHP5.3があればすぐ使える.

バージョンアップのハードルが高い

ドキュメント,コミュニティが小さいのが欠点

日本Kohanaユーザー会

5/12 大阪にて PHPカンファレンス関西2012 Ust中継もあり!