 
|
はてなキーワード: 開発者とは
日本ではバンゲリングベイはクソゲー、もしくは早すぎた名作といった評価のされ方をする。
海外ではこのゲームのマップエディタにのめりこんだ開発者、ウィルライト氏が後にシムシティを生み出したことでルーツとして知られている。
バンゲリングベイは一見すると攻撃ヘリで工場を破壊するだけのアクションゲームだが、防衛目標であると同時に補給地点である空母の存在、タンカーやオイルタンクを攻撃することで敵の内政を妨害して兵器配備を遅らせるなどの戦術性が存在した。
だがこの考え方はオリジナルから存在していて（建物がシナジーを起こすという考え方が後のシムシティとなった）、滑らかなゲーム画面やレーダーの存在などにより、FC版よりはるかに高い完成度で実現されていた。ハドソンの功績ではない。
ハドソンがやったこととは、ラジコンにのめりこんだ結果、慣性のキツい酷い操作性にしてしまい不興の原因を作ったことだけ。
バンゲリングベイは、もともとバンゲリング帝国三部作と呼ばれるシリーズの作品であり、1作目となるロードランナーが国内で大ヒットしていた。
そのため続編であるバンゲリングベイも大ヒットが見込まれ、そこで「2Pマイクに向かってハドソンと叫ぶ」という裏技を仕込むことで売名を図った。
オリジナルであるコモドール64版の売れ行きは2万程度で、80万本近く売り上げたハドソンのFC版には遠く及ばない。
アメリカ軍のアパッチを操作して架空帝国の生産拠点を壊滅させる、というゲーム内容に「縦横合計100画面」という無意味な自慢を吹聴して多くの子供を失望させることになるが、商売人としてのハドソンは一流だった。
今日プロジェクトの打ち上げがあったのだが、とあるサプライズ……三ヶ月前に寿退社した先輩との再会に思わず涙ぐんでしまい、ひどくばつが悪い思いをしている。今も顔の火照りが抜けてくれない。アルコールは抜けたのに。彼女はかつてSQLの魔女と呼ばれていた。
今から遡ること一年前、私は辞令を貰い、二年目にして事業部ごと変わるという波乱をようやく乗り切って、業務系のSEの仕事内容、特にWebのアプリレイヤーについてOJT形式で学んでいた。そこで先生にあたる方として付いたのが、ちょうど手待ちだった先輩である。初めてお会いした時の先輩に対し、私は正直ちょっと物足りなく感じていた。
初日に行ったPCのセッティングでは、これやってと先輩から資料を渡されたのだが、外部にネットが繋がらない。先輩に相談して弄ってもらったのだけど繋がらず、今日は社内ネットで我慢して、と言われてから二日後、資料が古かったことが判明。
与えられた課題を終えるごとに、コードを提出するのだが、見たよ〜出来てると思う、頑張ったね〜と言われた後で、そのプロジェクトを下敷きに発展課題に足を進めたら、でっかいバグがあったり。
万事その調子で、今やってる課題放り出して、プロジェクトオイラーの問題でも解いてた方がよっぽど楽しいなぁと若干サボりたいと思い始めた頃、炎上プロジェクトへ先輩と二人テスターとして出向するよう、上司から命じられた。炎上プロジェクトのリーダーから手待ち要員いない？と声がお上に届き、降りて来た結果先輩と自分がいたわけだ。
前の事業部ではずっと同じ客先にいたわけで、頭では分かっていても鼻先三寸で飛ばされることには不安がつきまとった。
「これから行く先はどうなんでしょうね？」
先輩へ問うと、
「基盤にいたんでしょ。メインフレームが扱えるなら大丈夫だよ〜」
豆腐すらぷるぷる震えそうな声が返ってきた。
この時の私は、まだ事業部を転属して間もなかったし、プライドばかり高くて奢ってたように思う。事業部を変える→入社して以来の経験値がまた0に、と失うことに対する不満ばかりで、それが拗れて数少ない基盤系経験アプリ開発者、そんな肩書きばかりを強調する変人に成り果てていた。自己紹介で、どうも、基盤から参りましたと、そこだけは大きい声が、今思い出したけどマジで恥ずかしい。
だから、だろう。このゆるふわな先輩とドナドナされることに密かに感じていた屈辱には、出向いた先で押された駄目テスターという烙印によって罰があたることになった。
その理由は、私がSQLを全く使えなかったことにある。テスターとして行うことになったのは表示画面の統合テストで、UIの検索結果とデータベースに直接SQLを打ち込んで得たレスポンスを目で確認していく作業だった。UIは、境界値さえ気をつけて、仕様通りに実施すれば何とかなる。しかし、SQLで再現が出来ない。この仕様はどうやったらコマンドに落とし込めるんだよ。頭を抱える中で思い出したことがあった。
教育過程でJavaサーブレットを学んだが、その一つにJDBCも勿論習った。そこで私は何をしたか？mysqlに繋げればそれでいいやと、エグゼキュートで実行する際に渡す魔法の文字列……つまりSQLの中身は、すべてコピペで済ませていたのだ。社内教育資料を内部作成するにあたり参考にしたと思われるネットから……構文チェック効かないし、ここは手を抜いてもいいだろう、これが要領の良さというものさ……アホーアホー私のアホー。
三日目の午後二時、進捗を確認しに来たPMにすべてを告白すると、ちょっと来てとPMが連れ出したのがあの先輩の席だった。
「申し訳ないけど今やってるテストは止めて、これから定時いっぱい最低限テストが出来るように彼にSQLを教えてやってくれ。」
良いのですか？と顔をあげるとPMは何を勘違いしたのか、やにわに私の肩を叩くと、
「彼女はSQLの魔女と呼ばれている。半日でお前も即戦力だよ。」
と去っていった。顔を先輩へ戻すと、あのPMさんは嘘つきだから信じないほうがいいよといつものふわふわした声でにっこり。
宜しくお願いします。ノートパソコンを横に私は型通りの挨拶。四時間後、私は傲慢さを、尻の毛まで抜かれることになる。
私はSQLの深さを知った。SQLのQとは何だ？Queryであります、サー!!今も時々夢問答を繰り返す。そう、全ては問い合わせ次第なのだ。今思えば、あの時やったことはT2テストを使ったSQL文の作成と添削、しかもSELECTによる条件抽出のみだったが、そこに全てが詰まっていた。
DISTINCTとORDER BYの共存で詰まってわけがわからなくなったコードは、もっとシンプルにいけるよと副問い合わせに書き換えられて。ネストとワイルドカードを多用してスパゲティになったコードを、先輩はLEFT JOINとWHEREとORで全てをすませた。
なんということでしょう。マニキュアが塗ってある長い爪からは想像もつかない早さで直されていく構文に脳内で途中から匠の曲が流れ始めたのを覚えている。本当に、なんということでしょう。先輩はSQLの魔女だった。
翌日、先輩の教えはしっかり自分に身に付いていた。すらすら書けるSQL、サクサク進むT2テスト。条件設定に悩んで、エクセルに吐き出してからリストとコピペで逐一加工してた時間が馬鹿みたいだった。先輩のところへ、帰りしなに昨日のお礼と作業進捗に激震が走ったことを伝えると別にお礼なんていいよーといつものふわふわした顔で微笑んでくれた。
それから先、配属先が決まるまでの条件付きでテスターとして入っていたはずだったが、T2試験が終わり、T3試験が始まってもなぜか私はそのプロジェクトにいたままだった。DB担当者として。もともと基盤だったわけだし、バッチファイル処理でスクリプトがそこそこ書けたというのもあるけど、SQLが書けたというのはすごく大きい。昼休み、いつのまにか私はプロジェクトオイラーの問題に代わって、名著「SQLパズル」を解くのを日課としていた。
先輩は仲良くなる暇もなく、その後すぐにプロジェクトを移り、メーリングリストで寿退社を知った。炎上したプロジェクトは、なぜか横展開を経て今に至り、私は相変わらずここにいる。だが、あの時SQLの魔女がかけた呪いは今もしっかり私に根付いている。
あ、まず前提として、
貴女がWindows Phone大好き男を夢中にさせることが、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
とはいえ、Windows Phone大好き男たちは玉石混交ながら、
ＩＴ系の超かしこい男なども多く、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、Windows Phone大好き男に「どの端末が好き？」と訊ねられたとき、
あとはモダンUI、そして（MVPになるほどではないけれど）Microsoftが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
これこそまさに必殺の答えです。
そこでWindows Phone大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「TextTextRevolution!」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるWindows Phone好きの男の
落とし方をお伝えしましょう。
「わたしは、NokiaのLumiaが好き。
Lumia 920のカメラは低照度でもよく撮れるの、Lumia 925も予約したし、
曲面ガラスの720や半透明カバーがきれいな620も、大好き♪」
もしも貴女がそう答えたならば、
その瞬間、Windows Phone大好き男の目はきらりと輝き、
かれの貴女への恋心は、
２０％増量になるでしょう。
位置情報アプリやNokia Musicなどの独自サービスもあって、
Nokiaマップは日本で使いものにならないものの、そこがまた
ちょっぴり日本がスルーされがちなSymbianやMeeGoみたいなふんいきをかもしだしていて。
しかもNokiaがWindows Phone 8でリリースした端末は、
NFCやテザリング、MicroSDといったWindows Phone 8の新機能を、
ほどよく搭載していて、なおかつ、
唯一、Windows Phoneを主力のスマホOSとした功績もあって。
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
アプリソムリエ似の綺麗系ＯＬと、玉もあれば石も混じっている、そんなWindows Phone大好き男たちが、
この世界で唯一（いいえ、HTCやHUAWEIと並んで唯三）機種変更しうるメーカーです。
●
では、参考までに、危険な回答を挙げておきましょう。
Windows Phone大好き男に「どの端末が好き？」と訊ねられたとき、
「富士通のWindows 7ケータイ、F-07Cが好き♪ 週３回は、OSを再インストールするの。」
その瞬間、Windows Phone大好き男の貴女への恋心は消えます、
しかし、「パソコンが手のひらサイズに！」とかなんとか無意味な自慢を吹聴し、
Windows Phoneについての謬見を撒き散らした罪がありますから、Windows Phone大好き男にとっては天敵なんです。
また、もしも貴女が「Samsungが大好き♪ あたしOmnia MやATIV Odysseyも持ってるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、Samsungは、２０１０年のWP7発表時点ではリーダー格だったものの、
しかしNokiaが参入したころから、いやはやなんともなメーカーに転落し、
またもしもたとえあなたがLGが大好きで、
「わたし、LGのE906が好き、ボタンのデザインもいいけど、
最高に好きなのはカバーを外してもブルーの筐体♪ 付属のヘッドフォンもブルーで統一されているの。」
と、答えたとしたらどうでしょう？
たしかにLGのE906は、ジルサンダーのデザインが chick であるのみならず、
しかし、貴女の答えを聞いて、Windows Phone大好き男はきっとおもうでしょう、
（なんだよ、お高くとまった女だな、カネかかりそう）って。
貴女が、Windows Phoneが大好きで、名機の名を挙げるにしても、
たとえば、HTCのWindows Phone 8Sならば安心でしょう、
なぜならば、HTC 8Sは、ふつうのＯＬにもマニアにもともに愛されるめずらしい端末で、
貴女がその名前を挙げても必ずしも、あなたがWPおた宣言をしているとは受け取られないでしょう。
しかし、たとえば、富士通東芝と同じく1機種のみで終わったAcerにせよ、
出荷延期を繰り返しつつもキーボード付き縦型スライド端末を出したDELLにせよ、
最低8GBというシャシー制限を無視した4GBモデルで一世を風靡したZTEにせよ、
あっさりカメラボタンのないWP端末を出してXperiaにナメられる原因を作ったALCATELにせよ、
開発者向けE600では有名なのになぜか一般向け端末を作る気配がないASUSにせよ、
そういうメーカーの端末をいきなり挙げるのは、ちょっぴり微妙。
ましてや貴女が、「HTCのHD2が大好き♪ わたし、もうほとんどのOS、入れちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、HD2は、WP8やWindows RT、Android、Ubuntu、Firefox OSなどほとんどのOSが移植されているHTCの超絶名機ゆえ、
あなたがそう答えた瞬間、Windows Phone大好き男がいきなり超笑顔になって、
しかし、逆に、（なんだよ、この女、Windows Mobileおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもWindows Phone大好き男がWindows Mobile大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「xdaで配布されてるHD2のROMが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女をWindows Phone教育する余地がまったく残されていません、
したがって貴女のその答えは、
Windows Phone大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目には男たちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、男は男で繊細で、傷つきやすく、女に夢を持っています、
貴女の答え方ひとつで、男の貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、NokiaのLumiaが好き。
Lumia 920のカメラは低照度でもよく撮れるの、Lumia 925も予約したし、
曲面ガラスの720や半透明カバーがきれいな620も、大好き♪」
そして、その瞬間、Windows Phone大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが行ってみたいお店は、
フィンランドのNokiaストア、素敵なお店って噂を聞いたから。
あなたのお暇なときがあったら、わたしをヘルシンキへ連れてって♪」
これでもう完璧です。
そうなったらこっちのもの、
"Smoked by Windows Phone"の賞品としてもらったTシャツを着てゆきましょう。
その日から、Windows Phone大好き男は貴女の虜になるでしょう。
今GoogleI/O見ててエンジニアの隠しきれないオタク感がなんとなくやばい。
っでなんとなく思ったのだけど、
そんな代物になったんじゃない？
ほんとの素人って方も少なくて、
いらっしゃらなかったんだよ、きっと。
Androidの開発でGoogleのチュートリアルは時々見るが、
さっき紹介してたGCMとか、あらかた使い方覚えてAPI表みたら
確かにプラスα要素多くて丁寧そうに見えるんだけど
それ理解できるようになったらチュートリアル本編はいらないって
まぁ大体そんな感じ。
なんかその辺が全くの初心者に対していきなり知ってることすべて説明しようとして
説明できることと技術があることは別やねんと
同じく小学生時代にベーマガ見てMSXでプログラム組んでたおっさんプログラマですが共感するところがあったのでブクマ代わりに。
俺の場合はその後ゲームはやるのも作るのもさっぱり飽きて、バンド組んでミュージシャン目指したりしたが食えなくて大手ゲームメーカーに就職した。
でもゲーム作るのは大変な割に儲からなくて、続けても旨みがないので退職。今は家で受託のWebアプリとかスマホアプリとか作ってる。
でも未だにゲーム開発の依頼とか相談とか多いんだよね。でも少人数で作れるものなんてたかが知れてて製品レベルにはできないから断ってる。一度ガラケーのソーシャルゲームならいけるかな？と思って請けたけど依頼元が仕様を作りきれなくて頓挫した。ゲームの複雑性の高さをなめてはいけない。
開発者から見てゲームほど終わりの見えない難しい案件はない。丸パクリを除いて、何を作れば良いのか本当に見えない。つらい思いをして完成させてもクソゲー。ゲームの仕事はやりたくない。
有りといえば有りなんだが、出る杭は打たれるという以前に
APIサービスやRSSというのは、競合他社がそれを利用していることを明示しないで、競合サービスをするときに使っていいのか？
というのは、倫理問題としてあるのでは？
NTTとしてはAndroidに対してGoogleが締め付けてくる。という見解を出したけど、言い方を変えれば
Googleの収益部分は全部NTTがやります。 AndroidでGoogleは儲けないで下さい。ってNTTは言うわけだろ？
お互い言い分はあるにしろ、常識的に考えて、Androidが無料なら、広告や課金はGoogleがやる。ってのは、常識的範疇だろ。じゃなければ、Androidの原資はどこから出てくるんだ。
という話とまったくおなじで、はてなブにしろ、TwitterにしろFacebookにしろ そのサービスと競合するサービスを、そのサービスAPIとして使うのは倫理的に問題が有る。
ということを、事前に考えず、公開されているし、規約にも書いてないんだから、何をやってもいい。という話にはならんだろ。社会常識的に。
黒とはいわんが、事前協議ではてブと連携するならともかく、倫理問題考えずにヤッた挙句、成功すればいいんだ、若気の至りとばかりに、はてなが買収って
なんか、なっとくいかないし。
原発の問題も含めて、東大の倫理価値観はどうなってるんだ？と思うことが 昨今多すぎる。
頭いいんだから、倫理問題が有ることは事前にわかるし、キャッシュフローも事前にわかるんだからAPI公開してるサービスのキャッシュフローに反するサービスを作るなら考えなきゃいけないってことは 事前にわかるだろ。頭いいんだから。
私は2018年、つまり貴方達の生きる時代の5年後からタイムスリップしてきた将棋オタクの増田です。
2018年のコンピュータ将棋界はどうなっているか、そして人間が指す将棋の世界はどう変わったのかを一足先に体験した身として書いておきたい。
2013年頃の最強ソフトの一角GPS将棋は東大のクラスタを使ってCPUを並列にしていたけど、2018年ではCPUを計算用途に使うソフトはだいぶ少なくなって、今ではGPUを使う事が当たり前になっている。これによって計算できる量は飛躍的に伸びて、2018年の最強ソフトはGPS将棋の330倍の量を計算できるようになったんだ。
東大チームのGPS将棋に触発されて全国の大学が将棋ソフトの開発に乗り出し、今や個人の開発者はほとんど日の目を浴びなくなっちゃった。大学が持つ計算リソースを贅沢に使えるチームに個人開発者が勝てるわけがないのは当然だ。東大は開発からは手を引いてしまったので、今は東工大、東京理科大、中央大学が3強だ。関東の理系に強い大学がたくさん参戦して学生を集める宣伝としてもコンピュータ将棋が使われるようになっている。箱根駅伝みたいな感じ。
Googleが世界コンピュータ将棋選手権に出場した2016年の事も書いておかなきゃね。その前年にそれまで個人が細々とやってきたあの3.1415.....の円周率桁数計算に進出してギネス記録を40000倍も更新して世界中から大人げない奴と白い目で見られたあの黒船Googleが何と将棋に興味を持っちゃったんだ。Googleが保有するクラスタのうち50000台を使っての勝負。「勝てるわけがない」「もし欧米企業に負ければ日本文化の敗北だ」ってマスコミは大いにかき立てたんだけど結果はなんと地元日本の代表、将棋に特化した100台ほどのGPUクラスタの勝利だったんだ。CPUという汎用計算リソースだけでは特化クラスタに勝てなくなってしまったという情報工学的にも大変興味深い一戦だった。
その翌年2017年にはアジア代表として中国人民解放軍が参戦して来てこれまた大いに盛り上がった。人民解放軍はなんと一般庶民のコンピュータとスマホを全て総動員、27億台のクラスタで勝負を挑んできたんだ。これにはたまげたね。「今後こそ勝てるわけがない」「もし負ければ技術立国日本の敗北だ」ってマスコミは大いにかき立てたんだけど、劣勢を跳ね返して終盤に奇跡の逆転勝ちを収めたのは何と日本代表だったんだ。終盤に日本が取られても取られても「6四 歩」を打ちまくったのが天安門事件(1989.6.4 一般民衆の蜂起)を連想させて共産党謹製のプログラムが一部クラッシュしたのが勝因とされている。心を持たないはずのプログラムなのに、結局は書いた人の何らかの思想がそこに反映されちゃうっていう情報工学的に興味深い一戦だったね。
プロも奨励会(プロの育成機関)の子らも、これだけ強くなったコンピュータ将棋を教師とはしていない。いまだに人から学んでいる。なぜなら、確かにコンピュータは強いけれど、その「理由」を説明できないからだ。
トッププロのような未知の領域に挑まなければいけない人にとってはコンピュータの指す異次元の手から少しは学ぶ事が可能だ。でも、特に奨励会の子らは一手ごとにその理由を解釈しながら強くなる段階だ。だからコンピュータ相手にいくら指しても上達しないし、棋符を見ても何も学べない。どんな世界でも、理由を解釈しなければ人は成長しないっていう良い例なんじゃないかと僕は思っている。
これはコンピュータが人間よりも遥かに強くなってしまった将棋の世界から我々が学んだ最も大きな教訓なのかもしれない。コンピュータには物事の理由を説明できない。彼らがやっているのはただの計算なんだ。何の理解も解釈もしていない。ただ計算しているだけなんだ。2018年のソフトの主流手法はDeepLearningと呼ばれる人の脳のニューロンを模倣した機械学習なんだけど、これはもう中で何をやってるのか作ったエンジニアですらもわからないブラックボックスだ。何をやってるのかわからないけど、強い。強いのは間違いないし誰も勝てない。でも彼(ソフト)は教師にはなれない。そこから何も生まれない。ただ彼自身が強いだけ。それだけなんだ。それにいったい全体、何の意味があるのだ？優秀な人間は優秀な人間を生み出す。そうやって人類は繁栄してきた。他の生き物だってそうだ。でも機械はそれ自体から何も次に繋げないんだ。
ああ、そろそろ帰らなきゃ2018年に。言いたい事は全て書いたよ。とにかく何が言いたいかって、やっぱり将棋は最高だってことなんだ。ハッシーのお陰で今は渋谷の女子高生の間でも将棋が大ブームだから、僕みたいなオタクな風貌での将棋が強ければチョベリグな思いができるってわけさ☆まだルールぐらいしか覚えてないって言う人は今からでも遅く無いよ。
jkondoがツイッターでGunosyのはてブ依存まとめを晒しあげていた。
それがバズを加速させて、大炎上になった。
近藤さんに呆れたとかほざいてる関係者もいたけれど、そうじゃないと思う。
あの仏のjkondoが、ブチ切れたんだ。
俺はそう思った。
Gunosyの記事を数本読み返してみたけれど、こいつらにははてなへのリスペクトがない。
はてなAPIを使わせていただいてありがとうございます、Special Thanks Hatenaとでもフッターに書かなければならないくらいなのに、
はてなを言外にバカにし、そのくせフリーライドしまくっている。
ライフハッカーに出ていた開発者インタビューでの「日銭を稼ぐためにエンジンなんか作ってる場合じゃない」発言。
この辺なんか、完全にはてなとjkondoを煽りに行ったとしか思えない。今思えば。
そりゃjkondoもブチ切れて当然だ。
最初は違ったようだ。Mashup Awardに出場し、はてなのAPIを使っていることも普通に明らかにしていたようだ。
それがいつの間にか「独自のアルゴリズムでクールにあなた好みの情報を提供します」となり、
Gunosyなんか吹けば飛ぶだろう、あれに力入れれば。
がんばれよ、もっとがんばれよ。
私の母は去年、夫を亡くしひとりぼっちの状態が続いている。
父親が亡くなってすぐは、父親を慕ってくれてた方々が遊びにきてくれたり、諸々の手続きが沢山あったり、それなりに忙しかったんだと思う。
ただ、ここ最近は塞ぎがちというか、たぶんやる事がなくて辛い毎日なんだと思う。
もちろん父親が亡くなった事により、会社も亡くなった。
そんな母親は、なんとかもう一度働こうと働き口をしていたが、世間的には高齢と呼ばれる部類に分類される母親に働き口なんかない。
父親なくなった瞬間、きっと母はすべての日常を失ったんだろうと思う。
言葉には出さないけど、明らかに辛そうな母親の顔が頭に焼き付いたまま離れない。
もう40年近くずっと毎日そばにいる状態で、それが会社でも家でもずーっと一緒で、そうやって積み上げてきた全てが亡くなるなんて、僕には想像できないし、本当に辛い事なんだろうと思う。
時々は孫が遊びにきたり、誰かが遊びにくるから一時的に元気になるけど、やっぱ帰ってしまうと辛いのだろうと思う。
「この状態はよくない。」
どうしたら良いかと真剣に考えていましたが、答えなんか出なかった。
ただ、何かの番組でみたのか、母親はiPadを欲しがりました。
そして、先月に1ヶ月早い母の日のプレゼントとして、プレゼントしてみました。
どうせ、すぐ飽きてしまうだろうと思ってプレゼントしてみたんだけど、予想外に母親は使いこなしているようです。
先ほどFaceTime使って連絡が来るぐらい嬉しいようです。
多分母親にとってiPadというのは未知の概念であり、未知の世界なんだと思う。
ケータイすらろくに使えなかった母親が、iPadを使っている。
Facebookで意外と昔の友達や知り合いを見つけたり、解らない事があったらSafariで検索したり、i文庫HDで青空文庫を読んだり、FaceTimeで連絡してきたり、Huluで映画堪能したり...etc
Facebookだって、i文庫HDだってHuluだって僕にとっては当たり前でツールであって、そこにイノベーションを感じない。
でも母親は違う、母親にとってiPadに入ってるアプリはものすごくイノベーションなのだ。
これを機に、母親の失われた日常が新しい日常に変化してくれることを切に願うし、それが出来るのだと信じてる。
その一言をレビューに書かれるような開発者になりたいと思った。
誰かのくだらない評価より、母親のような人の人生を変えられるアプリを作りたいと思った。だからこれから僕は今以上に全力で仕事をしようと思う。
とりあえず、ゴールデンウィーク後半。
明日実家に帰ったら、母親に「大切な事に気づかせてくれてありがとう」って声に出して伝えてみようと思う。
あくまでも一例でしか無いけど、資本家が強かったのは、工場とか何億円もする機械とかが必要で生産手段を資本によって独占できたから。という事だけど。
今の時代は、生産手段その物が陳腐化して非常に安くなった。とくにIT系では生産手段つまりSDKは０円が基本。
つまり、『産手段を資本によって独占できない』という状況だから、通常の概念の資本が意味を成さない。
逆に、『生産手段を資本によって独占できない』状況だから、マーク・ザッカーバーグやスティーブ・ジョブズのような特異な個人が、
過去の『生産手段を資本によって独占』していた産業をひっくり返してしまう。
大量の資本を有していても、開発者がいなければ何も出来ない。そういう時代に、資本論の訂正は必要ないんだろうか？
http://www.itmedia.co.jp/news/articles/1304/02/news033.html
知らなかったけどクックパッドもはてなと同じようなことやっちゃってたんだな。
抜擢された「UXの専門家」はおそらく張り切って自分の専門の仕事をし、ある程度は自信満々に製品を送り出したのだろう。レビューに並んだ酷評の嵐を見て何を思っただろうか。
結局ユーザーはシンプルさを求めていて「モダンなインターフェース」なんて要らないのだろうなと、このスクリーンショット一つ見ても思う。カッコ良くするために使い勝手を一段階落とす。これはやはり愚かな行為なんじゃないかと。
「ここを目立たせて、ユーザーを課金に誘導したい」等ビジネス上の理由があるかもしれないが、ユーザーには知った事じゃないし当然叩かれるだろう。はてなの場合はそんなのではなく、ただの迷走だろうが。
「批判が殺到しても利用者は増えている」「レビューは感情的な意見の集積と割り切る冷静さが必要」と言い逃れをし方針転換しないのははてなも同じか。ここで開発者が意地を張るのは正解か？せっかく開発したものが認められないのは辛いだろうが、失敗を認めて捨てる勇気も必要なのではないか。
http://bonnoh.jugem.jp/?eid=1228574
を読んだ。スクエニの社員でもなかった人間が良くもこれだけ断定できる。
偏見による分析とは酷いものだ。ろくなゲームが作れないタイプの似非プランナだろう。それはまぁいい。
俺は最近まで開発部門に所属しているプログラマだった。今はプーだがｗ
社長とは何回か酒の席やらで話したことがある。これは特別なことではなく、ある程度社歴のある人間はほぼ皆、社長に接したことがあるはず。
新卒なんかは和田塾と称して何度もあってる訳で、和田さんは社員を愛していたし、力のある開発者を優遇しすぎてさえいた。
…ただ面接の場面からも、スクエニがおかしくなってたことを痛感した。
ゲームを作る…ということを、スクエニは徹底的に馬鹿にしていたのだ。
面接官であったであろう幹部とその後ろに控えていた和田ら経営陣にとって、ゲーム開発はただのコストであり、開発者は会社の金を奪う泥棒にしか過ぎない。
和田さんほど自社のゲームを遊んで愛している社長を他に知らない。
彼は開発者ではないから技術などはないし浅い知識しかないが、それでもネットワークゲームの技術書を読んだり、ゲーム開発に参画したりしてきた。
そこにかかるコストの圧縮と効率は重視していたけど、ゲーム開発をコストとは考えていないし、開発者への敬意と信頼がありすぎるくらいの人。
もしも馬鹿にしてると感じたなら、それは目の前のあんたが余程の馬鹿に見えたのだろう。不合格だったのは当然だ。ご愁傷様。
ゲーム開発をコストとして考えていたのは、むしろ別の派閥で、今回の人事によって開発部門の縮小が加速する可能性が高いかもしれない。
和田さんは開発部門を守ろう、国内の開発力を落とすまい、とし続けてきた。
そのことは、何度失敗しても”健全な赤字”のRD部門を立ち上げ続けていることを示すだけで十分だろう。
俺が辞める段階で６０人以上の研究者が居たんだから、日本のゲーム業界最大の研究部隊を持っているのは今でもスクエニだと断定できる
和田さんの失敗・欠点は、むしろ開発者を愛して大事にして、信頼しすぎてきたこと。
切るべき時に大物や大型PJを切るに切れなかった優しさが、あれほど正確な分析と判断が出来ていたのに、会社を傾ける結果に繋がってしまった。
信じるべきではない人間を過剰に信頼しすぎてきたがために、社内の人間関係を複雑にして、PJ経営を難しくしてしまった。
もっと和田さんが冷酷な人間で、ゲームが嫌いで、オタクなんかクソだと思ってくれていたら、社員ならそう思うはずだろう。
和田さんの器の中で、多くの人間が甘えた仕事をし続けてきたんだが、もうそれは出来ない。
信頼を裏切り続けてきて、まともなゲームを出せなかったスクエニの開発者の地獄はこれから始まる。
俺が無能かどうかはどうでもいいが、多少なりとも和田さんに感謝しているのなら、匿名でdisるようなことはやめたほうがいいぞ。
俺の文書でもないものを俺と断定するあたり、思い込みが強そうなので元記事に書く
Disでも擁護でもない。感慨にふけったるだけ。
どちらかと言えば、スクエニの和田社長の取り巻きDisにはなるかもしれないな
和田さんは個人として見れば凄いよ。戦国IXAなんかも彼の功績の一つだったし、語られてた経営戦略や分析は振り返っても妥当だった。
それを実行に移せなかったのは、和田さんの甘さ故か周囲が弛んでたからかって話
スクエニには話に聞く柳井さんとか、三木谷さんあたりが社長としては向いてるんだ
君が悔しい思いをしたのなら、それは元社員としても忸怩たる思いだ。申し訳ない
俺としてももっと面白いものをもっと沢山作りたかったが、それは出来なかった。
色んな事実を上げたいが、それは許されることではないし語らない。
和田さんに対して社員の誰もが公開質問状を出せる時があった時、俺も経営方針に対する不満を送ったことがある。
それに対してもちゃんと返信をくれたことがあった。
次の社長がそこまで社員に歩み寄ろうとして、一緒にいいものを作ろうとするかは分からない。
損になると分かっていて研究開発をするかも分からないし、金の無駄だと数年かかってるプロジェクトをあっさり潰すかもしれない。
スクエニ再建に向けて多くのプロジェクトを畳んで行って、外注中心の開発にするのが、あるいは正解かもしれない。
しかし、その時には皆が望むスクエニには、本当にもう戻れないかもしれませんね。
んじゃ、ま、俺はこれで。皆さん、多くの反応をありがとう。
http://d.hatena.ne.jp/nowokay/20130322#1363969460
以下の記述のまとめ：
お前の言っているソフトウェア工学は今のソフトウェア工学じゃねえよ．
端的に言うとそんだけ．
で，本題．
まず，書いてる内容が古すぎて救いがたい．iPS細胞の研究がノーベル賞取った現状で，「実験材料に受精卵を使う万能細胞の研究なんて許されませんよ！」と主張されても，その何だ，困る，とかそういうの．
1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。
で，何？2000年以降ソフトウェア工学が何も進んでないと主張したいの？
って最初に書いてあんのに，そこから崩れて何も出てきてないって主張はどっから出てきたの？自分が知らないことが分かってるのにドヤ顔で提言とか大丈夫か？
しかし、結局統一設計手法は完成せず、UMLだけが残りました。実際に使われているのはその一部です。CORBAも普及せず、WebプロトコルにあわせてSOAPが出てきたものの、結局単純なRESTが定着しました。XMLはいまは毛嫌いされています。大成功したはずのオブジェクト指向も、Webアプリではうまく適用できませんでした。
だから何だ．提案されても使いにくかったり，状況自体が変化したら無用になるに決まってる．まさか「ソフトウェア工学分野で提案された手法はどれだけ開発環境が変わっても生き延びていなければならない」とかいう寝言じみた主張でもしたいのか？言語に流行廃りがあるように，手法にも流行廃りはあるに決まってるだろ．
あとSOAPとXMLに関しては，その衰退過程自体がよくある話すぎて話にならん．一番最初に厳格な重量級の様式が定められて，それをベースに運用レベルを考慮した軽量級の様式が定義されて駆動するってのはよくある話．言い換えると，学術から出てきた理論的に正しい手法が，産業界で必要なところだけつまみ食いされる形で運用されるとか，サンプルは死ぬほどそこらじゅうに転がってねえか？
ああ，CORBAはまあ，うん，そのなんだ．アレはフォローできない．
実際のところ，UMLが残っただけで十分じゃねえの？最初に提案された時の理念さえブレてなければ，つまみ食いしたモノがはやってても提案者的には本望だろ．
今はCMMIだ．CMMは2000年にCMMIに統合されてる．今更XPの本出してくるところといい，真面目に2000年より前で知識止まってんだな．
はぁ？動的型付言語が普及したらなんでソフトウェア工学と離れんのよ？静的型付言語で使えて，動的型付で使えなくなる研究分野なんぞ，完全にソースコードに寄り添った研究だけじゃねえか．
「この手法はC言語を対象としている」って書いてある研究は他の全ての言語には一切適用できないと主張してんのと一緒だ．はじめてのCあたりからやり直せ．
ここで、やはりCMMの失敗がソフトウェア工学にとっての痛手だったように見えます。
もちろん、プロセスを規定することが難しいということは当時からも言われていました。それであるから、CMMはプロセスそのものを規定するのではなく、プロセスの規定方法を規定するというメタプロセスになっていたのです。
そして、すべての組織で同じプロセスを採用することはできないということから、５段階のレベルを設けました。また、プロセスは変化し続けなければいけないということから、CMM成熟度レベル５では「最適化している」という成熟度になっていました。
これはなかなかいいかもしれないということで、期待は大きかったと思います。
でも、とにかく運用が大変だとか、CMM成熟度レベル5でも品質がいいわけじゃないとか、そういう話がきこえてくるようになりました。
まず失敗を定義しろ．で，失敗したってんなら，CMMIで未だに新たな認定がなされてる（http://cmmiinstitute.com/assets/presentations/2012SepCMMI.pdf）理由を説明しろ．
で，運用が大変？当たり前だ．品質確保すんのに運用が楽とかあり得んだろ．従業員に好きにやらせてもアウトプットが高品質ならそもそもCMMIなんぞ必要無い．順序が逆だ．「CMM成熟度レベル5でも品質がいいわけじゃない」ってのも当然だ．アレは組織の成熟度を評価する指標であって，中で働く人間の能力を評価してるわけじゃない．というか流動すんのに評価なんぞできねえけど．
そもそも，CMMIレベル5ってのはおおむね高品質なものが出てくるだけで，人間が関わっている以上ある程度のばらつきは存在する．つーかさー，CMMIレベル5なら必ず高品質のモノが出てくるとか思ってんの？まさかまだ銀の弾丸の存在を信じてんの？「ISO9001に準拠してればリコールなんて発生しない！」と思い込むくらい残念すぎねえか，その思考回路．
ああ，「CMMI」じゃなくて本気で「CMM」の話をしてるんなら申し訳ない．もう無いんだから，CMMの話を最近全く聞かないのは当然で，勘違いしても仕方ない．悪いもしくは古いのはアンタの頭だ．
もともとソフトウェア工学に対しては「がっこーで現場しらない人が研究してる手法なんて使えない」のような声があったのですが、XPやアジャイルによって「現場から生まれた手法のほうが使えるよねー」というのが決定的になりました。
前半は正しい．ソフトウェア工学の最初期からずっとその手の意見はあって，未だに言われてる．が，後半は話にならん．
真面目に聞くんだけど，アジャイルソフトウェア開発宣言に名前が入ってる17人のうち，何人知ってる？何人が開発寄りで，何人が研究寄りか分かる？まさかKent Beck1人を見て「アジャイルは現場から！」とか寝言垂れて無いよな？そもそもKent Beckはコンピュータサイエンスで博士号持ってるし，開発寄りと主張していいのかどうかすら微妙なんだけど．
あとアジャイルも突発的に出てきたわけじゃなくて，プロトタイピングとかあの辺（とそれ以前）からの流れがあると思うんだけどなあ．
ソフトウェア工学が何を失敗しているかというと、その学問自体の認知度が低すぎることです。
ソフトウェア工学がどのような問題を扱う学問かが知られていない。どのような問題を扱う学問か知られていないので、その問題に直面している人がソフトウェア工学の成果を積極的には利用できない。
問題に直面してる人がソフトウェア工学の成果を積極的に利用できないうんぬんについては，最近の国際会議でもその辺を扱った研究が出てきてたりする．ICSE2012のDistingished paperのうちの1本がそんなん．Eclipseの検索ツール使わずに，テキストエディタにコピペしてCtrl+F使ってる人の話とか出てきてた覚えが．
ただ，ソフトウェア工学の認知度なんぞどうでもいいと思うんだけどなあ，別に．そっから出てきたモノが使われさえしてりゃあ．ソフトウェア工学研究の成果が，それと分からずに使われてるんならそれ以上に望むべきモノは無いだろうに．「これがソフトウェア工学様の研究成果でござーい」と大上段に振りかぶって，「ありがたや」の言葉と共に使われることを望んでる研究者なんぞいねえだろ．
就職活動で「半年でプログラムは覚えれるし専門は必要ない」のようなことを言われるという話があります。たしかにアルゴリズムなど実装技術の研究をしていた人をSIの開発現場で生かすのは難しいと思います。でも、ソフトウェア工学の専門知識は、半年で覚えれるものではないし、SIでの開発現場に必要になるはずです。
うん，そうですね．だがそれを学術側を知ろうともしてない人間が言うな．
ソフトウェア開発がある限り、ソフトウェア工学は必要なので、XP・アジャイルを織り込んで再構築して、認知度を高めていってほしいなーと思います。再構築とかは他力本願になってしまうけど。
ソフトウェア工学を再構築しよう，という動きとしては http://semat.org/ あたりがあるのでそっち参照．
あとさー，そもそも論として，ソフトウェア工学の研究内容を「現場」と「学術」に2分することが不可能だって分かってる？工学ってそういうもんだろ？その2分は「工学」と「理学」というレベルでは可能なのであって，既に工学にカテゴライズされてるソフトウェア工学を分けるのは不可能だ．それくらいは語の定義レベルの話なんで，分かっててくれ，頼む．
まあ暇ならトップ会議であるところのICSEのプログラム（https://files.ifi.uzh.ch/icseweb/fileadmin/downloads/ICSE2012_conference_program.pdf）でも眺めてみて，ソフトウェア工学の定義について悩んでみるのもいいかと思います．
実際のところトピックは割と流動的．最近はOSS周りが流行．gitのおかげで開発者の行動とか取りやすくなってる関係もあって．
つまりさー，なんでか知らんけど，この人の頭ん中では「ソフトウェア工学は静的型付言語を利用したウォーターフォール型開発でしか使えない」てことになってんだよな．
はてなブックマークの「コメントを一覧表示するページ」のデザインが変わりました。そして案の定というかなんというか、いつもの通り不平不満がユーザの反応の大多数を占めました。個人的にはそんなにデザインが気に入らないなら Stylish でも使えばいいじゃんと思ったりもするのですが、まあそれは別の話です。デザインの変更というものについてちょっと思うところがあったので書いてみることにします。
デザインを変更するということの目的の大部分を占めるのは、「見やすく」するということでしょう。
ですが、一言に「見やすく」と言っても、ここでは「何を」見やすくするのかが明示されていません。このあたりにユーザと開発者の意識のズレがあるように感じました。
ユーザはツールの「使い方」のプロと言えます(妙な言い方ですが)。ユーザはそこそこ長い時間をかけてツールの使い方を知り、自分にあった活用の仕方を学びます。
その一方で、開発者はツールのプロです。生みの親です。ツールを進化させようと日々画策しています。そのうちに、あるときまでは重要でないとされていた情報が、じつはある見地からすると重要である、ということが判明したりします。そうしてデザインはその情報が目立つよう変更されます。新しい見地を知っている開発者にとってはきわめて自然なデザインがここに立ち上がるわけです。
とはいえそんなことユーザとしては知ったこっちゃありません。デザイン変更のアナウンスで「新しい見地」なんてものが提供されることはなかなかありません。少なくとも僕はそういう事例を知りません。ですからユーザは、それまで自分が親しんでいた情報が、なにやらよくわからない些末であったはずの情報に押しつぶされていると感じることになります。時間をかけて知った使い方がその新しいデザインにおいてはそれほど重視されていないわけですから、当然と言えば当然です。
デザインは、単なる見た目だけの問題としてではなく、開発者がその意図を提示する一つの仕方としても捉えられるべきであるように思います。
追記: 続き書いた ⇒ http://d.hatena.ne.jp/foobarhoge/20130326/1364309317
-----------------------------------------------------------
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 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"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
最初はrom専だったのですが、徐々にブクマでつぶやいていったら、なんか★とかいろいろもらえるようになって、楽しくてついああだこうだとブクマにはまっていった者です。
初めてお気に入りに登録してもらえたときはもうもんのすごく嬉しいものでした。
右上のフキダシで①とか出てるわけですよ。
おっ、どのブコメにスターいただけたのかなー、とかって思ったら、
とかっていってくれてるわけですよ。
このわたしに。このワタクシめに、お気に入りに登録していただけた、と。
もう嬉しくてその人のブコメにはちょっとでも気の利いたことが書いてあったらベシベシスターをつけたものですよ。しばらくして、うわっ、ちょっとこういうのってキモいストーカーみたいに思われたらどうしよう、って思ってすぐに自重しましたけれど。でも少しほとぼりがさめた後にすきあらばスターをベシベシつけてましたけれど。
はてブが1000を超えた頃には、お陰様で二桁のお気に入りに登録していただけました。本当に、本当にありがとう。なんか慣れ合いみたいに思われるのが嫌で平生を装ってふふーんて顔してましたけど、心のなかではスズメが小躍りするくらい嬉しかったんです。お気に入りに登録してくれた人、本当に、本当にありがとう。
あ、二桁って言いましたけど、要は10ってことです。10進法バンザイ。
そうして自分もお礼にお気に入りに追加しましたし、自分と考えの合う人を次々とお気に入りに登録してみました。するとどうでしょう、自分のお気に入りを確認すると、お気に入りにした人たちのブコメが次から次へと表示されるじゃありませんか。
自分がお気に入りにした人たちのブコメですから、当然興味深い話が次々と出てきます。面白い記事もサジェストされます。職場での昼休みが俄然楽しくなりました。はてなブックマークってなんて楽しいんだ、って思いました。
反対に、はてブを利用している中で、ウンザリするようなこともありました。
一番イヤだったのは、とにかく人の悪口ばっかり言う人。
でもこれは、”非表示に追加”することで全く目につかなくなりました。
具体的にID出すのも良くないかもしれませんが、どうせ匿名なので、
はっきりこの際文句言わせてもらいます。
特にこの二人のタグ見ると絶望的な気分になります。悪口ばっかり。
最初は何を言っているんだろうと思ったけれど、
ああ、そういう人なんだな、と思い、
非表示に追加しました。
その後も、非表示に追加を精力的に追加しました。主にネトウヨやはてサな人たち。
お気に入りと非表示に追加だけで、そうとう望みのものが手に入ると思いますよ。