  |
はてなキーワード: リファレンスとは
平岡さんが先月末で辞めた。その少し前に打ち明けられて理由を聞いたら「興味がなくなった」と短い答えを貰った。２年間働いた結果がそれだったのだけれど、辞意を伝えるといろいろ止められたが、給料をあげれば残ると言ったらあっさり引いたそうだ。
平岡さんはすごい人だった。一緒に働いた２年間、僕はすごいと思い続けた。プレゼンテーションサーバ、ロジックサーバ、データベース、経路のアライアンンスとすべてのチューニングが行え、Beanだってばんばん修正していた。ドキュメントをばんばんつくって公開していた。マネージャが聞きかじってきた新情報はすでに実装までこなし、たまーに営業が持ってくるドラフト段階のキャリア案件の実装だって仕様書とリファレンス、サンプルから作り上げていた。「絵と音がつくれないからなー、これくらいはしないとね」と笑った顔を思い出す。僕がしらないところでまだまだすごかったのだろうと想像できるくらいすごい人だった。
まずマネージャが「平岡ならこれくらいできたぞ」と怒っているのをよく見かける。営業から「平岡さんなら次の日の午前中にはもらえたんですが……」と上司にいいよる。公開サーバのチューニングだってインフラ部門担当者が２人がかりで今週今日までかかってまだ解決していない。平岡さんならもっとはやく解決できたんじゃないかな、と思っている。言わないけど。
平岡さんが入社したころはみんながすごいとおもっていたんだろう。そのうちみんなが平岡さんに「慣れて」しまう。そして平岡さんを想定して計画を考えるようになってしまったのだろう。あれほどすごい人を「最低限：平岡」という基準にしてしまったのだ。結局、烏合の衆が残った。たばになっても平岡さんには届かない。
計画を左右するほどのすごい人を、どれくらいの給料で使っていたのだろう。でも平岡さんが辞めた理由は給料の問題ではなく「興味がなくなった」のだという。本当に技術が好きな人は給料で満足を判断しないのだ、とよく見かける言葉の意味がよくわかった。
会社は平岡さんを満足させ続けなければならなかっただ。いや、満足できないくらいあたらしいものを提供し続けなければならなかったのだ。かわりに給料を出すならまだしも、その更改を願ったらあっさり彼を手放してしまった。どれほど釣り合わない値段で平岡さんを使っていたのか想像しているのだろうか。
平岡さんのように「都合のいい人」と同意の関係が構築できれば、それは幸せなのかもしれない。だけれど、もし、居る理由がなくなったらあっさり興味のある場所へと移動してしまうのだろう。無邪気に。そして平岡さんなきあとも、会社は続く。都合のよさはもうない。あれほどの計画を左右する人を手放してしまってもまだ、平岡さんを基準として考えることになれてしまった自分を理解もせずに。
批判もあるかと思いますが、できればすべて受け入れてくださると、僕と僕みたいに困ってる人が嬉しいと思います。
気が向いたらでかまわない。参考に聞かせて欲しい。
6つ要望が書いてあったが、例えばその6つを満たす技術ブログや技術解説記事(雑誌含む)を聞いてみたい。次の情報があると助かる。
http://anond.hatelabo.jp/20140502221658
★読破したのは、薬師院はるみ「名古屋市の１区１館がたどった道」という本だが、
というのは、名古屋や横浜、大阪のような政令市では「１つの区に１～２館」というのが実情だが、東京２３区では
「区内で７館とか１０館」というのが、ごく当たり前の状況になっている。
政令市だと「図書館から半径１キロ圏内の人口より、半径１キロ圏外の人口の方が多い」、
つまり「図書館が徒歩圏外にしか存在しないエリアの住民の方が多い」のだが、
東京２３区では「図書館から半径１キロ圏内の人口の方が、半径１キロ圏外の人口より多い、
それだけ図書館網が区内をくまなくカバーしている」状況である。
東京２３区の図書館環境に慣れてしまった身には、政令市の図書館状況というのは「まことにお寒い状況」に見えてしまうし、
おそらく図書館利用率も、徒歩で図書館アクセスできる２３区と、そうでない政令市では、全然違っていると思う。
ましてや、図書館が整備されてない通常の市、或は郡部とでは、利用率は月とスッポンだろう。
多分、２３区住まいの方が、読書欲が多く、かつ経済的にも余裕があって、
本来なら「小説家にとって、お客様を多数抱えているハズの商圏」なんだが、
そういうエリアでくまなく図書館ネットワークが構築されちゃっているから、小説家の怒りも相当なんだろう。
★あと、「住民１人当たりの図書館館数１位は富山県だ、だから富山が進んでいる」という言説があったが、
これには違和感がある。
利用者にとっては、人口当たりの館数なんていう数値はあまり意味がなく、
「徒歩圏内に図書館があるかどうか？」それが大きいと思う。
クルマを運転できる大人なら徒歩圏云々はあまり関係ないが、クルマを自力で運転できない小中学生にとっては、
「徒歩圏内に図書館があるか否か？」は、「図書館を気軽に利用するようになるか、否か？」の分水嶺になってしまう。
その意味では「徒歩圏内に図書館サービスが行き届いている２３区が、圧倒的に進んでいる」と思う。
「なぜ東京２３区は、ここまで図書館王国になったのか？歴史的背景は何か？」
★図書館のプロって、この「徒歩アクセスできるかどうか？」の観点をあまり重視してないような気がする。
図書館関係者って、「図書館が果たすリファレンスの役割」とか、とかく大上段に構えがち。
でも、図書館利用者の９割は、そういうことを気にせずに、「タダで本を読める、読書欲を満たせる」という単純な理由で
利用していて、図書館関係者の高尚な想いと、ズレてる気がする。
利用者目線だと「徒歩圏内にサテライト館が欲しい、貸出冊数・期間を拡大してほしい、開館時間を延長してほしい」
この辺の意識のずれは、何とかならないか？
★そもそもレファレンス機能・アーカイブ機能は、国会図書館と都道府県の中央図書館が主に担えばいい話であって、
市区町村図書館、それもサテライト館は、とにかく利便性向上につとめればいいのでは、とも思う。
本を読む、という場合、
２．なんとなく、読書欲を満たしたい
という２つがあって、１．の場合はレファレンス機能・アーカイブ機能が重要になる。
また、蔵書数は多ければ多い方がいい。
でも２．の場合は、他館からの取り寄せ機能さえしっかりさせておけば、
蔵書数にはこだわることはない。リファレンス機能もあまりいらない。
それより利便性が命になる。
一理ある。何故コピペD論が有り得るのか甚だ疑問。修論・博論は何度もボス（教授）なりメンター（助教とか）に修正されまくって、最初に自分で書いた原型は留めない、というのはある意味研究者に共通のネタでもある。程度の違いはあるにせよ。
仮に論文本体内でのコピペや嘘っぱちリファレンスリストを許容したとする。しかしデータの使い回しは有り得ない。例えばPCR画像使い回しなんて完全に黒。余談だが、修論提出締切に間に合わなくて先輩のリファレンスリストをコピペして審査員に提出する"裏技"というのは聞いたことがある。しかし当然減点対象になりうるし正本では直すのが普通。
三年前のデータと？そんなん有り得るか。理論科学と違って実験の面倒なことは再現性をとるためとか綺麗なデータをとるために何度も同じ実験を繰り返さなきゃいけないこと。投稿論文への掲載に値するデータを取るのにいくつもパイロット実験があったりする。で、そうゆう膨大な下積みデータってフォルダやファイル名に日付を入れて管理する。細かな作法は人それぞれだけど、日付の他に、実験の名前とか、株の名前、対象遺伝子・タンパクの名前もデータ管理に使う情報。どうやって数年前のデータと取り違えるのか理解し難い。
http://anond.hatelabo.jp/20140317015734
わからんでもないが。実験詰め込み過ぎてノート書くの一週間放置とかデータ整理二週間さぼるとか。でも最低限どの条件で実験したとかはメモ書きしておく（そうじゃなきゃ後で困るのは自分）。しかしそれ以前に、自分のデータ、しかもうまくいったデータって覚えてないもんか？というのが本質的に疑問。まして顕微鏡写真なんか、DNAの泳動写真に比べたら憶えやすいのは。視野内の細胞の配置とかで。顕微鏡に関しては確かに膨大な数の写真を撮るけれど、「これ！」というデータはそのあと研究室内での発表とか学会発表で繰り返し見ることになるから、自分どころか教授が憶えてたりするぐらい。
コピペや泳動写真の切り貼りがいけないことだとは知らなかった、は理研ユニットリーダーとしては有り得ない発言だと思うが、これまでの研究教育環境が悪かったことも否めなくはない。しかし既に書いた通り一つのデータを「異なる実験」と言って使い回すのは単なる嘘偽り。研究教育以前の人としての問題。二月中旬だか下旬頃に「いま必至に追試・再現性の確認を行っている」と発表されていた気がするが、そもそもきちんと実験されていないもの・存在しないかもしれない現象に再現性もくそもあるかい。いったい真実は何なんだ、おぼちゃんよ。
http://anond.hatelabo.jp/20131008141912
全く困らない。慣れる。
適切な単語の選択のセンスはプログラミング経験でいくらでも身に付くので、
辞書があれば困らない。
エラーメッセージで検索するとよくStack Overflowなどが引っ掛かるが
ある程度長い場合は機械翻訳に突っ込むこともあるが意味が取れなかったことはない。
質問をしたことは無いが、コードとエラーメッセージを簡単にまとめればなんとかなると思っている。
あまり気の利いたことは書けない。
Issueを要約したタイトルぐらいなら書ける。
内容をすべて英語で書こうとすると日本語の時の数倍の時間が掛かることになるため、できれば書きたくない。
少なくともスマートフォンでは。
昨年Googleが買収したMotorola Mobility(以下Motorola)のDroid UltraファミリーのSoCであるMotorola X8には、Googleの野望が透けて見える。
Motorola X8の詳細は http://juggly.cn/archives/91084.html でも見てもらうとして、一言で言うなら
X8 ≒ 2013年のミッドレンジSoC(MSM8960T=2コアCPU+4コアGPU+LTEモデム)
+ 各種センサ制御用プロセッサ(富士通のヒューマンセントリックエンジン相当？)
な、8コア()のSoCである。後ろ2つがMotorola設計。
このニュース見てすぐ
と思ったが、よくよく考えると顧客のIPと組み合せてカスタムSoCを作るってのはQualcommのビジネスモデルじゃない。
Qualcommの戦略は、リファレンス的存在のLTEモデムを武器にSnapdragonを大量販売することだ。
Motorola = Googleは何らかの対価（単に金を積んだか、あるいは虎の子のIPをQualcommにも使う許可を与えたか）を払ってX8を作ったことになる。
これは今のMotorolaのシェアからすると途方もない投資だ。
そして、この投資で得られるものは「SWと(SoCというローレベルからの)HWの協調設計」、つまりAppleの設計手法だ。
などのDroid Ultraファミリーの新機能はSWでも実現可能だが、待機時の消費電力が莫大になってしまう。
HWに手を入れて初めて、実現できた機能と言える。
GoogleによるMotorola買収後、新規開発された初のスマートフォンと噂されるMoto Xでも、このX8が使われる。
GoogleはMotorolaを飼い殺しにする気なんてない。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
一部で話題になってるこれだけど、投稿件数100越えてる割には、他のネット論争と比べて比較的コメントが読みやすい。これについては、投稿してくる人も d:id:perlcodesample も余計なノイズや一言を入れずに投稿してくれているからだと思う。見習いたい。
にもかかわらず、ここを読まないでトラバ突っ込みを入れてくる奴は馬鹿ばっかりだから話は全然収束しないし。トラバ投げる奴は、ただ自分が気持ち良いエントリを書きました、って話しかしてない。
d:id:perlcodesample は「perlだとスカラーも各種リファレンスも全部 my $var って書くだけで受けることができる！ 楽！」って話しかしてない。（そこから派生する色んな"利点"については「お前がそう思うんならそうなんだろう、お前ん中ではな」レベルの主観だらけなので"インデントをスペースにするかタブにするか論争"のように対話しても万人に納得のいく結論は出ない）
そう言う話に「そんなことをしてると(あらかじめコンパイル時にチェックが入らないから)後から大変なことになるぞ！」ってツッコミが入り、それに対して「後から大変ってどういうことですか？ どうせ全部テストするんですから(コンパイルを行った時点である)最初から大変なのも、(プログラムをテスト実行した)後から大変なのも、大変度合いの総和は大して変わらないでしょう？」というあたりで止まっている。
この d:id:perlcodesample の主張は、(本人にとっては)暗黙の以下の前提がある。
この前提のどれかに無理があることを直感的に示さない限り、この対話は終わらない。
あけおめ！今年は巳年。へび。へびと言えばPython。そう今年は全てのwebエンジニアがPythonを勉強する最高の環境が整った年なのです。
必要です！必要だと思います。もはやPythonはwebエンジニアにとって必修言語となりつつあると思います。Linuxの多くの箇所でシステム言語として用いられ、可読性の高さから多くの技術系書籍のサンプルコードとして用いられ、科学技術系分野におけるエコシステムの充実っぷりはますます磨きがかかっており、様々なライブラリがどんどん出てくる現状を「Pythonわからないから自分には関係無い」と遠巻きに眺めるのはもったいないです。
あなたが既に他の言語に慣れ親しんでいるなら、特にRubyなどに精通していれば「1週間」で基本的な読み書きは出来るようになるでしょう。そのくらいPythonは敷居の低い言語です。またweb上のチュートリアルドキュメントが大変に充実していますので(もちろん和訳済み！)費用0円で勉強開始できるお手軽言語でもあります。
これは大変に悩ましい問題で、自信を持ってお薦めできるバージョンが無いのが残念な現状です。2系と3系は特に文字コード周りを中心に言語体系にそれなりの差があり、日本語を扱うエンジニアにとっては悩ましい問題です。結論としては「どちらも読み書きできる」ようにした上で「3系で書く」ですかね。2と3の違いを理解しておかないと必ずどこかで躓きます。特にweb上の情報はまだほとんどが2系ですが、ぱっと見て2と3のどちらのバージョンで書かれた情報なのかを判断できないと多くのweb上の情報を利用できずにもったいないです。
先述しましたが和訳済みのチュートリアルが充実しているのがPythonの特徴でもありますので、まずは目を通す事をお勧めします。
ぜひ超充実したドキュメント群を覗いてみてください。「チュートリアル」を読めばだいたいの言語仕様がつかめるはずです。「ライブラリリファレンス」はあなたの最高の辞書となるでしょう。
その上で、やっぱり書籍で勉強したいということでしたら以下の本がお薦めです。
・プログラミング自体が初めての人向け
・他言語を既に知っている人向け
みんなのPython 第3版(柴田 淳) ・・・2版と3版で大きく内容が異なります 2版はPython2系、3版はPython3系を中心に解説
・進んだトピックを扱う中級者以上向け
pythonはインデントの存在があるので無機能エディタで大規模なコードを書くのは案外骨が折れます。贅沢系IDEの代表格はPyCharm(有料$99)でMac,Windows,Linuxの3プラットフォームに対応しており、一つのアカウントでいくつものマシンにインストールできます(同時に使う事はできない)。30日間の無料トライアルもありますしトライアル期間が過ぎても一回あたり(たしか)5分ぐらいなら継続して使えます。無料IDEだとEclipseプラグイン、Netbeansあたりでしょうか。Netbeansは公式開発は既に終了しておりあまり安定していません。
大規模な開発ならDjangoが第一候補。歴史が長いフルスタックなフレームワークですがまだ正式版がpython3系に対応していない。最近勢いがあるPyramidは3系に対応済み。各webフレームワークについては各開発者同士が「筋が悪い」「Pythonとしておかしい」「トレンドから3年は遅れてる」などとガチンコで思いの丈をぶつけ合っている以下の記事も参考にしてください。http://www.atmarkit.co.jp/news/201209/24/pycon.html
とりあえず最低でもDjangoとPyramidは両方使ってみてから自分にあった方を選択するといいと思います。
・Numpy/Scipy
科学技術系の人が好んでpythonを使う理由の一つがNumpy。数値行列計算を内部でCを使って計算するために非常に高速。インターフェイスは書きやすいpythonだけども実行速度はCネイティブ並みというとてもありがたいライブラリです。現在のPythonの盛り上がりに間違いなく大きく影響しているライブラリ。
・nltk
言語処理で使われるライブラリ。英語がベースとなってますが工夫すれば日本語でも全然使えます。参考文献 http://nltk.googlecode.com/svn/trunk/doc/book-jp/ch12.html
・multiprocessing
並列処理ライブラリ。CPUのマルチコアを全て使い切って無駄無く高速に処理を行いたい時に重宝します。個人的に大好きなライブラリ。頑張ればちょっとした分散並列システムも作れます。このライブラリのお陰で自宅にある10台*(擬似)8コアでお手軽python並列処理クラスタを30分ぐらいで作る事ができました。
OECDの勧告にあるかどうかと、それが正しいかどうかは別物。権威ある団体が声明を発表したから正しいというのはやめてくれ。その勧告本文へのリファレンスつけてくれ。
ちなみに、原文が同じ物を見ているかどうかしらんけど、それって、子どもがいない場合のジェンダーギャップが２０％で、いる場合のジェンダーギャップが６０％となっていて。
女性の性差というより、子どもの有無による差分なんだが・・・日本の場合、仕事より育児に傾ける傾向があるからで、企業動向がかならずしも、差別的だとはいえんだろ。 子どもがいない場合のジェンダーギャップが２０％なんだから。
で、どこの国でも、子あり、なしのギャップは子ありの方が２０％ぐらい高い傾向にあるだろうに。それと比べると、１０％～２０％ぐらいしか、国別の差がないようにみえて、６０％うんらた、ってのは、他のデーターを削って、ショッキングに見せるように加工したんじゃない？とかすら思えてくるんだが
RSS 経由で竹内マリコという人の書いた『ここは退屈迎えに来て』という本について知った。現状では紙の本でしか出版されていないようで、まだ読んではいない (彼女の本を読んだことも (多分) まだない)。
既に本を手にとって読んだ人の感想などを読んでいると、地元 (東京などの大都市ではない地方都市などか?) に通うヤンキーの同級生とはそりが合わず、かと言ってクラスに溶け込めている訳でもない自分が「東京に行けばどうにかなる」という思いで結局東京に来て、たまに帰省してみるとヤンキーやクラスの中心にいた人間はオッサン (オバサン) になっていて… という内容らしい。
私はクラスに溶け込めなかった側の人間だった。小学生の頃はどちらかと言えばいじめられていた方だと思うし、気の利いたことを言うクラスメイトを見ながら「私もああいう話し方ができたらなぁ」と思う人間だった。高校は工業高校だったのが私には良かったのだろうと思う。そこではプログラミングのできる人間やコンピューターに強い人間というのが一目置かれていて、中学までのヒエラルキーとは少し違っていた (ありきたりな表現かも知れないが、私の居場所が少し大きくなったということなのだろう)。中学までは全然勉強できずに工業高校に行ったのが私には吉と出たように思う。
その後色々あって今では日本国外で暮らしはじめて数年になる。地元にいたときには「退屈」という気持ちはあまりなかったと思う。そもそも「ここは退屈だ」と思えるほど私の世界は広くなかった。実際に運良く外に出ることができて、その実感を得ることができたのだろう。件の本に登場する人物は雑誌などの情報によりその人の世界が広がるということなのだろうと (感想や対談内容からは) 理解できる。一方私は雑誌よりも本やマニュアルを読んでいたりしていた (結構高かった Delphi のリファレンス ブックも全然活用できなかったなぁ… DirectX が… とか言ったら年が分かるか ;-)。
私が地元から離れた最大の原因は「成り行き」と「運」だと自分では考えている。外を見る機会が無かったら、何も知らずにあのまま地元に残っていたのかも知れない。Facebook で中学生や小学生の同級生がアップロードした写真を見るが、もしかしたらそのとなりに私もいることになっていたのかも知れない (いや、友達はそこまで多くなかったから、それはないかも)。
既に起こったことに対して「もしもあの時」などと考え、延々と議論するのはあまり賢い時間の使い方と思えないが、それでもたまに「もしも地元に残っていたら、今の私とどちらが満ち足りた (つまり足るを知っている) 状態だっただろうか?」と考えることがある。同年代の人と比べると比較的経験はした方だと思うのだけれど、それが足るを知ることと関連しているとは必ずしも思えない。しかし人間年をとれば知識も蓄積されるので、私のような人間でも後になって外 (現実的には日本国内だと東京一択になってしまうのだろうか) に憧れてしまうのかも知れない。
Carpe diem.
ポインタ、参照（リファレンス）、束縛（バインディング）、それぞれ似てるけど同様に語ると混乱の元ではないかと。
ポインタはメモリアドレスに型情報をくっつけたもの。加減算できる点が特徴で、それはメモリアドレスの概念由来だろう。
変数というメモリ上の記憶域を指すフィジカルに近い概念で、配列の運用（*p++で回すとか）、引数の参照渡し（コピー抑止、複数戻り値の実現）、メモリそのものの管理（malloc）あたりで、基本手作業による最適化のための仕組みという側面が近いと思う。
perlだと、変数はやっぱり記憶域ではあるけれど概念として一段抽象化されていて、メモリという連続した領域じゃなく独立した領域の集合となっているから、リファレンスの加減算はなし。
また、配列も単なるメモリの並びからより抽象化してリストもできたから、配列運用や複数戻り値もリストがあるのでリファレンスに頼ることはなくなる。
ただ、オブジェクトの概念があって、オブジェクトをオブジェクトとして入れる変数は用意せずリファレンスとすることで、文法上の変数の型を増やさない、コピー時のコンストラクタの問題を回避するなどのほか、オブジェクトの概念を援用して無名関数や無名変数、ファイルハンドルなども変数＝引数として扱えるようにした。
で、pythonはもう一段推し進めて、今までの数値や文字、配列もオブジェクトとみなし、変数はすべてオブジェクトを指し示すもので、記憶域は変数としてあるのではなくオブジェクトとしてあり、変数にリファレンスという特別なものがあるのではなくなり、変数は記憶域をもっていて値が代入されるものではなく、既にあるオブジェクトに変数名という名前（ラベル）を付けて束縛する行為とされる。
見方を変えると変数はすべてにおいてリファレンスで、代入とは値そのものの代入でなく値へのリファレンスの代入で、引数も参照渡しであるが、引数に代入したところでリファレンスが変わるだけで元の値が変わるわけではなく、しかし他の演算などでは自動的にデリファレンスされており、単純な数値や文字列など、自身を変更する機構を持たない（できない）ものにとっては実質的に今までとの違いはないに等しい。隠ぺいといえば隠ぺいか。
java, javascript, rubyもおおむねこの考え方でよかったと思う。
ただ、phpは若干両者が混じったところがあって微妙なところがある。
参考
まあ、「ポインタなんて必要なの？」とか思う層には「アセンブラなんてなんの役に立つの？」とか思いそうだけれど。
しかし、ポインタであーだこーだ言ってるけど、配列とか文字列とかはどうなん？
全部つながってるので行ったり来たりしながらやってくしかない気がするけど。
まあポインタは、その後リファレンスになって、さらにバインディングと、どんどん抽象化するんだけれども。
つか、どうなのかな。
アセンブラみたいにハードべったりな具体的なほうと、OOとか抽象化されたほうと、どっちがやりやすいのかな。
例によって、かなり長めの文章を書くつもりでいたのだが、どうしても途中から筆が進まなくなってしまった。よって方針を変更し、ちょっと短めの文を書いてみたいと思う。…と思っていたが、最終的に書き上がった文章はそれなりに長いものとなった。覚悟して読んでいただきたい。
まずはじめに断っておくが、私は武雄市在住のれっきとした武雄市民であり、もちろん住民税等も武雄市に納めている。よって今回の問題については一市民として堂々と意見を物申すことが出来る資格があると考えている。
なぜそんな回りくどいことをここで書くのかといえば、ネット上での一部で、「武雄市民以外の人間が武雄市のことにごちゃごちゃ口をだすな」的な発言が多用されているためである(誰がどういったかは言った言わないの話になるので、各自検索していただきたい)。よって私がここで発言することには、武雄市民でないからなどという屁理屈は一切言わせないぞ、と一応宣言しておくこととする。
これで拒否されるなら、来年度から住民税をふるさと納税制度を利用し合法的に武雄市以外の他都市に支払う覚悟であるので、念のため申し添えておく。
さて、全国ニュースにも取り上げられるようになった武雄市図書館・歴史資料館(エポカル武雄)のカルチュア・コンビニエンス・クラブ(以下CCC)への業務委託の件である。
5月4日の記者会見以来、その内容をめぐって「健全な」論戦が繰り広げられている(と少なくとも私は思っている。そう思ってない方もいるようだが…)。
気の変わらないうちに先に書いておくが、今回の件で私は武雄市長には一つだけ感謝していることがある。それはなぜか。
ふだん私もエポカル武雄は利用している。今年も既に数回は本をかりている。勉強にも行っている。何しろ近くにあるので便利なのだ。ただ行けるのは土日くらいのものだが。
で、だ。私はこれまで生きてきた中で、図書館は「あって当たり前のもの」だと思っていた。武雄市も「市」だが、以前いた土地も「市」だ。法律で「市」には図書館を設置すること、となっているので、図書館があるのが当たり前の環境だったわけだ。これがもし「町」や「村」だったら、図書館がなかったかもしれない(もちろん図書館が設置されている素晴らしい「町」「村」もちゃんとあります。念のため)。
そんな環境で過ごしてきたせいか、図書館はあって当たり前、無料で本が読めて借りることもできる、快適な環境で静かに勉強ができる、くらいのイメージであった。
よもやその裏側で、司書さんを始めとするスタッフがいかに苦労をされていたのか、選書だったりリファレンスだったり、もちろん貸し出し返却や蔵書整理、はては郷土資料の収集保存など、様々な業務を行なって下さっていたことを、今の今まで恥ずかしながら知らなかったし、考えたこともなかった。また、「図書館の自由に関する宣言」の存在も知らなかったであろうし、その歴史的な背景について知り考えることもなかっただろう。
おそらく、今回の件がなかったら、もしかしたら死ぬまで図書館の裏側については知ることもなく考えることもなかったかもしれない。
そう考えると、今回の件で、改めて図書館に関わるすべての方に感謝すべきだと気づくことができたし、図書館が無料で使えることのありがたさ、私たち市民の「知る権利」や「読書の自由(貸出履歴の秘密保持)」があることの大切さに気づくことができた。この点では武雄市長には感謝以外の何物でもない。改めてこの場でお礼を申し上げる。
忘れないうちに、この件についての私の考えを簡単に述べておこう。文句もたくさんあるが、それは後になってくるに連れて出てくるだろう。
まず、指定管理者制度そのものの導入については、絶対反対とは言わない。というのも、それこそ最近エポカル武雄で借りてきた本の中に、「私たち、図書館やってます」という本がある。興味のある方はぜひ読んでいただきたいのだが、これにはとあるNPO法人が図書館の委託運営を行なっている事例が事細かに載っている。彼らは市民の視点から、市民に必要な図書館のあり方を常に考え運営しており、市民の行政参加という面からも評価できるものである。ただ、最近佐賀市で指定管理者で運営していた図書館の分館が、直営に戻されるという事例も起きており、どういった形が望ましいのかはよほど慎重に考える必要があるのではないかと思われる。
開館時間の延長についても、概ねは賛成である。私もしがないサラリーマンである以上、図書館に行くことのできる日は決まっている。夜7時でも普通に仕事をしていることも少なくないので、開館時間が延長できたら夜家に帰る前に寄るなど、自由度は格段に向上する。
ただ、便利になる反面、運営費が上がることは覚悟しておかなければならないと思う。市長は1割減という発表をされていたが、本当にそれは可能なのか。民間に委託するから安くする、という簡単な理論ではあるまい。事務の人間を減らせばいいというものでもあるまい。図書館は貸出返却の業務だけではない。TSUTAYAのアルバイト店員のような感覚で務まると思ったら大間違いだ。そこはよく精査する必要がある。
それと、蔵書の整理や虫対策の燻蒸など(市長は書籍には燻蒸しないと思っているようだが、武雄の場合は書籍にも燻蒸を行なっている。過去にホームページに掲載した履歴がある)、どうしても休館日が必要な可能性が出てくるのだが、それはどうするつもりなのか。まぁ蔵書を並べるくらいなら、書店のように利用者のじゃまにならないように随時行うことで、ある程度の作業量をこなすことはできるかもしれない。また、ある村では自動機を利用して無人で24時間貸出を行なっているところもあるので、それも導入の参考にはなるかもしれない(さすがに防犯上すべての本ではないと思うが)。
20万冊の本をすべて開架にするとのことだが、それはそれで結構な話だが、物理的にどうなのか？という疑問は残る。私も通っているのでよくわかっているつもりだが、記者会見のスライドで出ていたパースはどう見ても壁の部分にも本がズラリと並べられていた。となれば、かなりの部分を改修する必要が出るだろう。果たしてその費用はどこから出てくるのか。委託費用の削減分と簡単に言うが、前項の理由で本当に削減できるのかは正直怪しいと思う。せめて議会にはきちんと積算根拠が提出されることを望む。でなければ納得はできない。
また、現在の開架部分もよほど高い本棚にし、かつ本棚の間隔を狭めないことにはまずそれだけの冊数の収納は難しいだろう。ブックオフのように背伸びしても届かないくらいの高さになってしまうのか。利用者の利便性としては後退しそうな気もする。また逆に貸出不可のため大事にしまっておくためにわざと閉架にしておく資料だってあるだろう。そういったものの区別はきちんと付けるべきである。
次にカフェダイニングの件だ。
図書館でたしかに喉が渇くこともあるだろう。今の図書館は、入って左側にカフェコーナーと称した空間があり、水を飲んだりジュースを飲んだりすることができるようになっている。あれではダメなのか。そんなにスタバがほしいのか。よくわからない。
第一、市議会1日目での演説を聞いていて私は愕然とした。図書館が教育施設というのなら給食はどうなるのか、というあの発言だ。何を言っているのだ。学校は確かに教育施設だ。しかし、そこでは子供たちにきちんと教育をする。給食の時間は皆一斉に机の上を片付けて給食の準備をし、盛りつけて皆同時に食事をする。その時に、おしゃべりこそすれ誰が本を取り出して読み始めるというのだ。普通そういうシチュエーションならば、先生が「食べているときは行儀が悪いから本を読まないように」と注意するだろう。もちろん家でも同じようなことがあれば「行儀が悪い」と怒られるだろう。それと図書館でコーヒーを飲みながら本を読むのと一緒にしてどうする。それは躾の問題とは言わない。TPOをわきまえろといっているだけだ。
飲み物を飲むなとは言わない。例えばペットボトルのように蓋が閉められるものであれば持ち込み可、ただしこぼして汚したら弁償、とするだけでも市民の利便性は上がるし、こぼしても自分のせいとあきらめも付くだろう。実際にその方式をとっている図書館もあるようだが、調べてみるとよいだろう。
あとは文具を売ったり雑誌を売ったりするということだったが。
まぁ最近は、例えば水族館などの観光施設で、来館記念にと施設のオリジナルグッズを製作販売しているところも確かにある。ゆえに、そういったノリでの文具販売という形なら無くはないかもしれない。エポカル武雄もオリジナルのマークがあったはずだ。そのマークが入った筆記具など、オリジナルの物を売ってみるのはありかもしれない。
ただ、それ以外のもの、特に雑誌あたりを売り始めるとなるとちょっと話は変わってくる。文具にしろ雑誌にしろ、既に市内にある商店ともろに競合する話になってくるからだ。これは図書館での説明会に言った方から聞いた話だが、とある書店の方が雑誌販売について尋ねたところ、既存の書店は競争してもらいたい、という旨の話が出たという。
ちょっと待て。競合ということは、つまりTSUTAYAと競争しろということか。かたや巨人、かたや零細となってはどこにフェアな競争条件があるというのか。もっと言わせてもらえば、首長というものはそもそもその自治体の経済的発展のために力を注ぐのもひとつの重要な仕事であろう。そりゃ工業団地を作り企業を誘致することで雇用も生まれ市には税収が入ってくるかもしれん。だがそれだけではなく、雇用された人が市内に住み、消費行動を起こすことで地域の経済が回っていくのではないか。では地元の商店はどうか。ゆめタウンなど大型店舗が増え、自家用車で買い物に行く人が特に若い人を中心に増えた。そうすると旧来の商店街からは客足が遠のき、もはや青息吐息となってしまっている。そんな中でさらに巨人を首長自ら引っ張ってきて、競争をせよというその信念が理解できない。むしろ地元の書店や文具店等にスペースを有償で貸し出し、ここで商売をして儲けてぜひ市に税金をたくさん納めてくれ、というのが地元自治体のあり方ではないのか。何か根本的なところから間違っていると言わざるをえない。
…だんだん疲れてきた。ここから文章崩れます。中の人も崩れてます。ごめんなさい。
まず、映画・音楽の充実でTSUTAYAレンタルをする、と。それでその内容は既存の武雄店と被らないような品揃えにする、という話だったように思う。
…で？
もう隣接地に別にTSUTAYAを作ったらいいじゃないか。なんで図書館内でやるの？図書館同様無償で貸し出すならともかくとして、有償で貸し出すのだったら単なるTSUTAYAだよね？
むしろ近くにあるレンタル屋(SQUARE)がどう思っているか聞きたいよ。多分本屋さんと同じ事を言い出すと思うけど。
iPadでもWebは見られるよね？今の図書館でもWebで蔵書検索はできるよね？私は結構利用しているのだけど。まぁメリルというちょっと危ないシステムではあるから(岡崎図書館事件でぐぐってくれ)、変えられるなら変えたほうがいいけど、それ以上に何がご不満なの？むしろMy図書館の青空文庫化をどうにかして欲しいのだが。
これもエポカル武雄にあった、増田社長の本「代官山オトナTSUTAYA計画」と「情報楽園会社」両方を借りて読んでみた。が、特に武雄に持ってきて嬉しそうな話は何もなし。むしろ確かにカンブリア宮殿でも見たほうがよっぽどマシかもしれん。ただね、テレビを見ただけで簡単に全国で同じ物が実現できると思ったら、大間違いだと思うだけど。代官山はむしろTSUTAYAでは採算度外視と番組内でも明言しているわけで、そんないくら掛かるかわからないようなシロモノを丈夫に作って、コスト削減ができるとはとても思えないのだが。コストとコンセプトが見合うという根拠を示してもらう必要がある。
極めつけはTカードだ。
ポイントを付けるためには日時を記録しておく必要が有る(あとで訂正する必要があるかもしれないからね)。貸出日時が全く同じ、ということはまずありえないから(カウンター2台での確率を考えてみればすぐわかる)、その時点で名前が直接わからなくても、特定の人間を判別することは容易だということだ。
もう高木浩光先生はじめ、ネットのセキュリティ関係者のみならず、少々データベースが分かる人は総ツッコミしているわけだが、これはもう誰かセキュリティに詳しい人が進言してもらうしかないんじゃないかな。市議会でもそこまで詳しそうな人はいないと思うし。
一つだけ書いておくと、今のコンピュータを舐めるな、と。というか人間を甘く見るな、ということだ。たとえシステムが別々に分かれていても、それを管理する人間が同じであれば、簡単に両方のシステムから共通する情報を抜き出すことはわけないということだ。データさえどうにかしてシステムから取り出せれば、名寄せくらいなら多分私でもできるぞ。世の中には便利なソフトがあるからね。
Tカードの規約を知らない人は(カードを作ったけど、あの小さい字なんか読んだことないというそこのアナタだ)、ぜひ一度読み返してもらいたい。ネットにはちゃんと大きな字で書いてある。何故か色は薄いけど。そこには、ポイントプログラム参加企業で個人に関する様々な情報を共通利用できる旨のことがちゃんと書いてある。個人情報は法律上は住所とか名前とかだが、個人に関するセンシティブな情報だってたくさんある。家族のこと、買い物の履歴(例えばファミマで何を買ったとかガストで何を食べたとかエネオスで石油を入れたとか蔦屋で何のビデオをレンタルしたとか…いろいろだ)など、人によってはそんなの他人に知られたくない、といった情報もひとまとめになっているのがこのTカードと呼ばれるシステムだ。ビデオを借りたらポイントが付いて便利じゃんとか簡単に思っているかもしれないが、つまりわれわれは個人情報をポイントと引換に売り渡しているようなものだと思ったらいい。
それと図書館に何の関係が？と思うだろう。図書館は歴史的に個人の貸出履歴は秘密にしておきますよ、という宣言をしている(図書館の自由に関する宣言でググってほしい)。今のような平和な世の中ならそうでもないが、以前図書館の貸出履歴がお上の思想調査の材料として使われたという苦い経験があったのだ。それでその反省を踏まえてこの宣言ができ、図書館員は(たとえ民間委託であろうが)この考えを守る、ということで一致している。しかし、CCCがいくら情報を使いませんよーといっても、物理的に別々のシステムから一致する情報を探し出せる条件がそろっているのなら、コソッとされても我々利用者にはわからない。それをしません、とどうやって担保するのか。そこが今だ不明なところだ。
ちなみに、図書館でポイント、というのも実は既に別の図書館で事例がある。図書館独自のポイントではあるが、利用者を増やすというインセンティブだけの目的であれば、それでも十分客寄せの用は果たすだろう。
というわけで、ひと通り書いてみたが、時間がもしとれたら改めて順序立てて書いてみたいと思う。
まぁ、今回の一件については、1ヶ月以上の時間が過ぎたこともあり、twitterなどの議論に参加していても、徐々に話が散漫になってきているような気もしなくもない。それは主に以下の様な理由がある。
(1) この期に及んでもなお、話の全体像はともかく詳細が全く見えてこない。
市長は「議会で説明する」の一点張りで(それはそれでわからなくはないが)、そうかと思えば市民団体からの要望でと、当日になって急に説明会を行ったり、5月4日からの記者会見で話した内容と、後にブログに記載した内容に一貫性がなかったり、市民に対してきちんとした情報は全くといって良いほど出ていない。その割には市民からの反応が云々とブログに書くなど、何が本当なのかさっぱりわからない。
市からの公式な発表といえば、あの不便な顔本(Facebook、ね)にほんの数行書いているのみで、あとはCCCのりリースを見るしかない。と思っていたらさらにその抜粋が今月号の市報に1段だけ掲載されていたという…。なんじゃそりゃ。
市民の多くは、新聞やテレビなどの報道を見て初めて知った人も少なくないだろう。なにせ、ITに詳しい人だけが市民なのではないのだから、ネットが見られないとほとんど情報を知りえないという人も少なくはなかろう。そもそも、図書館が存在する理由の一つとしては、経済的な理由で書籍の購入が困難な市民でも、知る権利を保証するためという一面がある。とすれば、図書館の話はそういったITと縁遠い人にもきちんと説明責任を負う必要があるのではないか。
CCCと組むとこんな良いことがありますよ、というのは記者会見でもニュースリリースでも述べられており、基本的にその論調でしか正式な話は伝わってこない。
対して、ネットや一部報道などでは、CCCと組むことでこんなことも考えられるのではないか、と専門家(図書館協会やセキュリティ専門家など)の視点も交えて指摘をしているにもかかわらず、やれ荒唐無稽だの、対案を出せだのと明後日の方向でしか返答が帰ってこない。
指摘する方は、「今発表されている計画のままだと、こんなリスクがあり、そのままにしておくとこんな結果になりますがどうですか？」と指摘しているにすぎない。普通対案を考えるのはむしろ指摘されたほうだろう。「そういう問題点なら、これこれこういう方法を取ることで回避できると思います」といった返答をするのが常識だろう。それを蹴散らした挙句暴言まで吐くとは何事か。嘘だと思うならネット上で検索してみるがよい。
…さすがに疲れてきた。まだ書きたいことは山のようにあるのだが、今日のところはそろそろやめることにする。
とにかく今は議会が全て、という話なので、我々としては一般質問の内容をよく精査した上で、地区の議員諸氏を説得していくよりほかないかとは思う。議員諸氏が闇雲に条例案に賛成すること無く、上記に挙げたような問題点を今一度理解していただき、よりよい武雄市図書館を作るために全力を尽くしていただきたいと切に願うものである。
と言った汎用コンピュータの大元の技術が全部日本製じゃないんだから
そこそこ面白かったりしたが、ソフトウェアはパッとしなかった。
長大な設計書、応答性がよろしくなかった。
ハードウェアのことはプログラムに関わる部分しかわからないが。
情報系の奴らの話を聞いていると工学・理学の人らが血反吐吐く思いで学問しているのがバカバカしくなってくるな。
話は変わるが、一言目はソーシャルというのを批判しているようだけれど
SI業界は設計だけしかしない実装能力もない指揮を取る会社はただ協力会社に投げるだけだし、
実際の実装する協力会社は強烈なコストカットと短納期要求でグズグズじゃないのか。
最後に
これから情報系に行こうとしている人たち、IT業界に行こうとしている人たち、
いやまいったなあ。増田に本気で「知的エリートが蝟集する」なんて思ってないよ。ただの枕詞。そういうのわかんねえかな。
Clinical effectiveness of photodynamic therapy in the treatment of periodontitis (http://www.ncbi.nlm.nih.gov/pubmed/19554711)
periodontitisって歯周病のことな。光線を当てて歯石を除去する方法と従来の方法でどっちが歯周病に効くか調べてる。ここからリファレンスを手繰ればお前の読みたい論文も簡単に見つかるから、大岡山にでも行けば大体読めるんじゃねえの。いや、こういう分野は弱いかな。大岡山になくてもCiNiiで探せばみつかるだろう。
つまり、お前の言う
そういう研究がそもそもないんだ。
は間違い。
これだけ書くのに、専門外でもあり知的弱者であるおれは(一応言っておくが本気ではなくイヤミで言っている)10分かかったが、おれ以上の知性の持ち主であるお前(一応言っておくが本気ではなく以下略)なら2秒でこの程度調べられるだろう。
どうして調べないの？どうして調べないで思い込みを断定しちゃうの？それこそ知性の感じられない行為じゃないの？
それから医療についてだが、医療は本来自然にそった行為ではない。だってそうでしょう自然にそってたら死んじゃうから医療行為を施すんだよ。
投薬や手術に頼らずに、人間が本来持つ免疫機能を大切にするというのが現代医学のトレンドなのを知らずに投稿するのはよしたほうがいいよ。
