  |
はてなキーワード: メソッドとは
例: プログラミング言語の説明に「Method(メソッド)」という単語が出現した場合
IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。
PHPのプロジェクトはPHPの認定試験に受かってる奴しか使わないとか、MySQLの資格もってないとテーブル設計もやらせないしSQLも書かせないみたいな。
認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。
Javaの入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観だから、自分は実力あるとナチュラルに信じこんでるし。
VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールをJavaに持ち込んで「全メソッドでcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界。
ダメな技術者が、年をとってるってだけで評価されて上にたってダメな技術者を育成するって負のループに入り込んでるから、一定の客観的な基準で評価する仕組みをもちこんで負のループを断ち切るべき。
いわゆるExcel方眼紙でシステムの設計書を書いているのだが、これがどうにも上手くいかない。
問題は色々あるが、大きく分けて「必要な情報が見えにくい」「変化に追従するのが大変」に集約される。
そのメソッドを記述するのに必要な、他の設計書や仕様書を見つけにくい。
例えば、他の設計書(1ファイルで1クラス)に書かれているメソッド名や引数が合っていなくても、すぐに発見しづらい。
また、入出力情報が書かれたインターフェース仕様書を探しにくいなどなど。
そもそもどうユースケースを読んで、設計が必要なクラスを抽出するかもよくわからないし。
次に「変化に追従するのが大変」について。
上述の状態で設計書を書いた結果、製造するプログラマから「こんなんじゃ実装できない」と突っ返されて修正するパターンが多い。
更に要件定義レベルでの見落としによる手直しも、結構な頻度で起きる。
いずれもExcelファイル1個に留まらない、影響範囲の大きい修正になるケースが殆ど。
そんなことが相次いで発生した結果、修正対象の抽出・修正・確認作業で作業量が膨大化し、全く対応できない。
「1個ずつ解決していけばいずれ必ず終わる」を合言葉に、気合と努力と根性でやってきたけど、なんでこうも先が見えないのか意味がわからない。
今回の参院選ではいつも以上に左翼陣営から『意に添わぬ投票行動をする人々』に対する罵倒が多かった。
それに対してはてブ等では、
「なぜ左翼は味方になりうる人に罵声を浴びせるのか。そんなことをして味方が増えるわけないじゃないか。非合理的だ」という意見が散見されたが、
これはとても間違っていると言わざるを得ない。
あるいははてブらしくもない、一面的、非リベラル的なものの見方だと言ってしまってもいいだろう。
左翼陣営にとって、「仲間になりうる人に罵声を浴びせる」というのは仲間を増やすうえで非常に合理的、あるいは合教条的行動なのだ。
基本的に、左翼陣営が仲間を増やすときに用いるのはアブラハム宗教メソッドである。
２、それを足掛かりに暴力をもって物理的制圧を行うか、精神的マウントをとる。
３、教化を行う
このような手順になる。
思想の輸入の際にメソッドも合わせて輸入されたのか、それとも敗戦の記憶がバビロン虜囚の代わりになったのか定かではないが、
日本でも左翼陣営が仲間を増やそうとしたときに行われる行動はおおよそこれで説明がつく。
ここまで書けばお分かりいただけるかと思うが、彼らにとって仲間を増やすことと相手を貶めることは不可分である。
仲間を増やしたい『のに』相手を罵倒しているのではなく、仲間を増やしたい『から』相手を罵倒しているのだ。
メソッド的には何も間違っていない。本来ならばこの後に続く、相手を圧倒する物理的暴力や知的能力を持ち合わせていないだけなのだ。
これってまさに日本の美少女ばっかのアニメのメソッドをなぞっているのでは…？と思った。
そのうちヒーローはみんな女の子にしよう、ってことにさえなるのでは。
「政治的正しさ」に基づくなら女の子の活躍ばかり描いて、男の活躍には全く期待しないというふうになるわけなのか。
32歳。とだけ。瞑想はじめて二年目。といってもやりたいときにやるだけで、毎日はやってない。初心者の域を出ない。今までに軽くいくつかの瞑想方法を試した。そしてそのいくつかの瞑想方法を気分によって使い分けたりミックスさせてやっている。メインは金井メソッド。サブでマインドフルネスストレス低減法、Zmeditationというアプリでの誘導瞑想、某瞑想団体の誘導CDによる瞑想、など。
だらだらと適当にやっているが、割と楽しい。金井メソッドは別名源波動瞑想といって、本が何冊か出ている。割と説明が難しい。瞑想関連の本で一番面白かったのでこれがメイン。おすすめは「すべてを受け入れて自由になる」というやつ。金井…なんだっけか。本見に行くのがめんどくさい。
マインドフルネスストレス低減法は、こないだNHKスペシャルでもやってたけど、あらゆる種類の瞑想法から宗教性を排除し、共通項を取り出して作られた瞑想法。マサチューセッツなんとか大学(工科ではない)で研究・開発された、エビデンスベースドな瞑想法。といってもシンプルに、座って、目を閉じて、今ここを意識して、意識が飛んだら呼吸に意識戻して〜みたいな、簡単なやり方。エビデンスベースドな瞑想法、というより、瞑想に科学的根拠を与えた、と言った方が正確か。何がすごいって、瞑想すると恐怖を司る扁桃体とやらがリアルに小さくなり、そのかわり感情や記憶を司る海馬がこれまたリアルに大きくなるということだ。脳ミソが物理的に変化するという。実験は8週間だというからさらに驚き。瞑想欲が深まった。詳しくは、ジョン・カパッドジン「マインドフルネスを始めたいあなたへ」がおすすめ。ジョン・カパッドジンなのかジョン・カッパドジンなのかは、確かめるのがひどく面倒だ。
Zmeditationは、丁寧な日本語誘導付きの、お手軽簡単な未経験者にオススメの瞑想アプリ。5分、10分、15分、20分…と、五分刻みで瞑想時間が用意されていて、誘導も調整してある。シンプルでおしゃれなUI。呼吸に意識を向けさせる誘導がメイン。仏教では数息観というのだそうだ。仏教の瞑想の中で入門的な瞑想らしい。
瞑想団体のやつは、金もかかるしガッツリスピリチュアルなのでオススメしないので名前は出さない。ただ、実感として、これが最も手っ取り早く、かつ最も効果的なんだろうなと思っている。直感。
何を目指すかによって瞑想は幾多も用意されている。ストレスの低減なのか、パフォーマンス向上なのか、はたまた悟りへの道としてなのか。
そういえば悟りについて面白い本があった。魚川なんとか先生の「仏教思想のゼロポイント」という本。著者は東大で哲学を学び、同大学院で仏教を研究。その後ミャンマーに渡り五年、瞑想センターで修行した方。内容は、悟りって何？を研究者らしく論理的に解明していくというもの。
お疲れさまです。
まず全体的に、インデントがおかしいのと「}」が不足しています。
プログラム仕様書とはいえ「}」や「；」は書く必要がないため、もう少し日本語として通じる文章にしてください。
下記の
俺 ＝ 彼女いない歴 = 年齢；
「もし」ではなく、繰り返しを意味する「諦めない」でしょうか？
また「彼女＝フリー;」setupメソッドで「なんかモテそう」を代入していますが、フリーで上書きして問題ありませんか？ その場合「なんかモテそう」の代入処理は必要なのでしょうか？
変数彼女のフォーカスが不明のため、このクラス内だけでは考慮できません。
次に「俺頑張る＋＋」は、人間型の変数俺の頑張るプロパティをインクリメントするという意味でしょうか？
上記のループが回っているときに、このメソッドではない別のメソッドで、変数彼女と俺の友達の値が変更されるため、上記のループの中に条件式があるのでしょうか？
もし、そのためであれば、非同期処理を本当に使う必要があるのか、もう一度設計を見直してください。
そのためでないのなら、ループが始まるまえに、条件式を記載してください。
return 今夜も童貞;
voidなので、値を返すことはできません。
また、条件式の結果によっては、値を返さないケースがあります。
その場合は初期値を返すのか、エラーを投げるのか明記してください。
以上、指摘事項を受けて、修正箇所があれば修正を行い、レビュー結果ドキュメントに修正箇所を明記してください。
また、質問箇所については、レビュー結果ドキュメントに回答もセットで記載してください。
文章でわかりにくいところがありましたら、遠慮なく私のところまで聞きにきてください。
徹底的に利己的に追求していけ！
俺の発言の正味を解説したら「誤読するメソッドじゃないか！ｷｰッ！」って
意味わかんなすぎて怖いわ
お前の発言について述べてる時に言うならまだわかるが
お前はもしかすると誤読って言葉の意味すら正しく把握してないのカナ
先に誤読してるのはお前なんだがなｗ
「くやしいんでちゅね」としか思われないよん
「それの延長だよ」という文章を完全に見落としている
多分フィクションとは何かについて考えたこともないだろうな
具体的に反論できず
「見落としてる」みたいなボンヤリしたことだけ述べて勝利宣言ポーズ、とｗ
前のめりになって「どう自分が勝利してて相手が敗北してるか」を熱心に説明するもんだよ
具体的な反論を避けて抽象的な勝利宣言＆話を切り上げようとしてる時点で
みんなの目にもばればれでちゅよ、劣勢を悟って逃げたくなってるっていうのがな
まあどっちが優勢か判断する頭だけはあったっていうことが少し意外だ
普通なら１回で気付くことを５回ぐらいやり取りしたあとに、だが
まだまだ一部のエンジニアにとって、という話だよね。
少なくとも英語の読み書きができないと最新のテクノロジー情報をキャッチアップできないとか、stackoverflow読めなくて問題解決できないとか、オープンソースにコントリビュートできないとか、これはまさにその通りだよな。オレもオレなりに英語力の不足を痛感する機会は腐るほどある。
でも日本にいる80万人以上のITエンジニアのうち、そうした能力を必要とされないエンジニアがこの日本の大部分だ。
なぜならSIerみたいな受託開発・運営がソフトウェア業界の売上高6兆ぐらいのうち半分以上で、かつ彼らの大部分は日本語ドキュメントが充実してる枯れきった技術を使い続けるから。
枯れた技術で安定性を担保ってのはわかるが、公式のサポートが終わってるJava4~6,PHP5.0~5.3を使ってんだよ。保守じゃなくて新規案件だよ。COBOL,アセンブラみたいな化石言語を保守し続けるところもあるがあれはもっと別の世界から来たナニカって感じだな。そっちはよく知らん。
オレは新卒で入った受託ソフトハウスや大手SIerで計8年働いて、6年ぐらいはwebアプリのプログラマ・SEとして色んな現場みたが、オレも含め一緒に仕事する人は誰も英語なんて求められてなかった。英語読むより怪しいExcel仕様書なりソースコードのコメント読むなり顧客のメール読むなりして汲み取るのが大事だし、コーディングで困ったら日本語でググればまずヒットする問題ばかり。
コーディングで英語を使うと可読性が下がるから変数名・メソッド名・データベースのテーブルやカラム名もヘボン式ローマ字表記で書けってわけ。顧客マスタは「KOKYAKU_MASUTA」だし、担当者は「TANTOUSHA」と「TANTOSYA」で表記ゆれ、笑えるよな。
とにかく言いたかったのは、docker1.12だとかRails5だとか機械学習の新しいフレームワークだとかそういう話題でワイワイやってる層とはまったく別の層がいて、そいつらに英語は全く必要ないしこれから先の何年も求められずにやっていくだろうっていうこと。
悲しい愚痴、以上。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログに対するSIer側からの反応を見て危機感がないよなーと思った。
「ウォータフォールは一切メリットがないので止めておきなさい」っていう言葉のメリットって誰にとってのメリットかっていうのに齟齬がある感じ。
受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。
確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？
実際につくった後で「思ってたんと違う！」と言われても、「要件定義で合意した通りですよね？」と言える仕組みで自分たちがお金を貰えないリスクを抑えてるんでしょ？
だから顧客にとっての価値に言及せずにウォーターフォールにもメリットがあるって言うのはポジショントークじゃないですかね。
そりゃ「ウォーターフォールは一切メリットがない」なんてことはないですよね。SIerにとっては。
ウォーターフォールじゃないと契約できないとか日本の文化があるからアメリカのやり方はなじまないとか言ってて、じゃあその日本に馴染むやり方で価値のあるシステムが組めてるのかっていう。より価値のあるシステムを生み出そうとしてるのかっていう。
そうやって現状に甘えてるばかりで、より価値を生み出せるやり方をするプレイヤーが出現したらどうなるのか、みたいな危機感がないですよね。
知らんけど。
これについては、
という阿澄佳奈メソッドは新人女性声優において極めて有効だと思われる。
汎用系のエンジニアからRubyのエンジニアとして転職して1年。
コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。
その特徴はだいたいこの3つだ。
やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。
そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。
テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。
ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。
そもそも自分が行おうとしているソートが何ソートなのか知っているのか？計算回数を考慮した上での実装か？
便利なメソッドがたくさんあるのは知っている。
ただ、中身くらいは知っておこうよ。
新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。
「Githubで公開されてましたんで導入しました」じゃねーよ。
得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。
そんで都合の悪いところだけコードを読んでオーバーライドする。
影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの？
いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。
エンジニアもどき量産言語だね。どれか１つでも当てはまった奴は小学校からやり直せ。
追記
意見がたくさんもらえて喜ばしい。
文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。
「だいたい」とあるだろう。全てのだいたいだ。
＞フローチャート糞
精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。
＞カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける
あー、ここは誤タイピングだわ。
自動テストでカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。
単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
http://b.hatena.ne.jp/entry/qiita.com/tadsan/items/fb496e450fc27c8c4494
歴史的仮名遣へのヘイトスピーチが人気コメントの2位・3位。これはひどい。そして悲しい。
多分、著者のtadsanは一々コメントを返したりしないので、この場で勝手にツッコミを入れてみる。
bottomzlife なぜ意味不明な歴史的仮名遣いがまじってるんだ。気持ち悪いからやめてほしい。プログラマなら日本語のコーディングガイドラインも守れ
「まじって」なんかない。全文が単なる歴史的仮名遣でしかない。(これは逆に、「現代仮名遣い」との差が少ない証拠になってる)
あと「日本語のコーディングガイドライン」が「現代仮名遣い」を指すなら、そのガイドラインの方が意味不明でクソ。まだ歴史的仮名遣の方が論理的で、プログラマ的にも腑に落ちる。その辺は http://web.archive.org/web/20020612101011/http://hb9.seikyou.ne.jp/home/kyuri/nihongo/kana-hikaku.html でも見れば、小学生でも解る。
「歴史的仮名遣い風」ではなく、正真正銘の歴史的仮名遣。(字音仮名遣? 知らない子ですね…)
それでも信用しないのなら、個人の勝手だが、そんな差別をする奴は信用ならない。
snobbishinsomniac 「ヘッダ」「メソッド」ではなくて「ヘツダ」「メソツド」だろうし、「レガシー」「モジュール」じゃなくて「レガシイ」「モジユウル」ではないのかな。
外来語の長音記号とか大書き・小書きとかはどっちでもええんやで。
ちなみに「モジュール」は「module」でダ行だから「モヂュール」と書く人も居る。
慣れの問題。いや本当に。
時間を掛けてまで歴史的仮名遣の読み書きを習得する価値は、個人的にはある。似た感覚としては、全然論理的でないHTML3.2を捨てて4.01とか5.0に移行するのと同じ程度に有用。
http://anond.hatelabo.jp/20160613091056
つってまあ、そんだけ見てりゃピクサーとディズニーの新作追ってりゃいいと思うけれど。
とはいっても2010年代のアメリカのアニメスタジオは群雄割拠。これにストップモーションアニメ勢や日本やフランスの伝統的な2Dアニメ勢が絡んできて大乱闘スマッシュブラザーズだし、中国や韓国の新興スタジオも力を伸ばしつつあるわ。
もしかしたら、今が世界的にみて一番アニメが豊潤な時期なのかももしれない。
そんな混沌としたアニメ勢力図を一スタジオ一作品で把握できる、ステキなリストを元増田にプ・レ・ゼ・ン・トよ♥
1. ドリームワークス：『ヒックとドラゴン』（クリス・サンダース＆ディーン・デュボア監督、2010年）
『リロ・アンド・スティッチ』の監督（とスティッチの声）を務めながら、ドリームワークスに移籍したクリス・サンダース。名監督、会心の復活作よ。
人間不信のドラゴンとドラゴン使いの一族のおちこぼれ少年が育む純粋無垢な友情の物語に涙しないものはいないわ。
監督が変わった『２』もDVD/ブルーレイでリリース済み。評価は分かれてるけど、１を楽しめたら是非観てもらいたいわね。
ドリームワークスはディズニー/ピクサーの昔からのライバルよ。
創業者の一人であるカッツェンバーグ氏は元ディズニーの幹部。低迷していたディズニーに『トイ・ストーリー』以前のピクサーと手を結ばせた功労者だったけれど、ディズニーのお家騒動に巻き込まれて会社から追い出されちゃったの。
それだけにディズニーやピクサーに対する恨みは深くて、自分が退社する直前に挙がっていたピクサーの『バグズ・ライフ』の企画をパクって『アンツ』を作ってほぼ同時公開し、ラセターをブチ切れさせた逸話もあるわ。
ディズニーとの最大の違いはその量産ペース。たまにハズレもあるけれども、成功した作品はめざとくシリーズ化して貪欲に稼ぐわ。
『シュレック』、『カンフー・パンダ』、『マダガスカル』がそうね。元増田は『マダガスカル』がお肌に合わなかったみたいだけど、『シュレック』は『カンフー・パンダ』並に観といて損はないわ。『マダガスカル』は作品ごとに評価の波が激しいけれど、この二作のシリーズは一貫して高評価を受けていて安心して観られるわよ。
単発作品では、『ガーディアンズ 伝説の勇者たち』たちなんか玄人好みの作品ね。
2. ワーナー・ブラザーズ：『LEGOムービー』（クリストファー・ミラー＆フィル・ロード監督、2014年）
『シュガー・ラッシュ』以降の現代的なウェルメイド作劇に感動した元増田なら、『LEGOムービー』は外せないわ。
チャーミングなテクスチャの質感、とぼけたオフビートなキャラクター、意外に王道な感動ストーリー、アッと言わせる伏線やオマージュネタの数々……
クオリティだけでいえば近年の3Dアニメのなかでもトップクラスと言ってもいいわ。たかがLEGO、とあなどるなかれ。あなたの涙腺をしぼりとる大傑作よ。
WBは元々バックスバニーなどで知られるアニメ業界の最大手。テレビでは「カートゥーン・ネットワーク」を系列に抱えてるわね。けれども映画ではディズニーに遅れをとってきたわ。
散発的に『アイアン・ジャイアント』や『ルーニートゥーンズ：バック・イン・ザ・タイム』といった良作を自前で生み出してきたけれども、基本はポケモンや他社製作のアニメの配給が中心。ようやく自社制作で気合入れだしたのはそれこそ2014年の『LEGOムービー』からよ。
これからは豊富なキャラクターコンテンツを利用して『原始家族フリントストーン』や『宇宙家族ジェットソン』、『スクゥービードゥー』といった作品を映画化するみたい。
ちなみにワーナー傘下にはヴィレッジ・ロードショー・ピクチャーズっていうオーストラリアの映画製作会社があるんだけれど、
そこで『マッドマックス』のジョージ・ミラーにふわふわペンギンヒップホップダンスマッドマックスミュージカル映画『ハッピー・フィート』、
『ウォッチメン』や『300』のザック・スナイダーにふわふわフクロウガチ殺し合い300映画『ガフールの伝説』と、
ヤバい映画の監督に見た目かわいい内容ハーコーな動物3Dアニメをやらせててどれも最高よ！
3. ソニー・ピクチャーズ：『モンスター・ホテル』（ゲンディ・タルタコフスキー監督、2012年）
それまでディズニーの独占市場だったアニメ映画界に風穴を開けた90年代のピクサーと2000年代のドリワの活躍を見て大手映画会社はこう考えたわ。
「3Dアニメは儲かる！」。
ソニー・ピクチャーズ・アニメーションはそうやって便乗的に2006年ごろから作品を継続的に発表しつづけてきて、それなりに稼いではいるけれど、他と比べてあまり元気がないわね。特に日本だとほとんど知られてないんじゃないかしら？ アニメ映画界で重要なプレイヤーとは言いがたいわね。
ここは『レゴムービー』の監督のデビュー作である『くもりときどきミートボール』を挙げときたいところだけれど、『レゴムービー』を観たなら薦めなくても観るでしょう？
監督のタルタコフスキーはタルコフスキーのパクリみたいな名前だけど、アニメ業界ではレジェンド級のアニメーターよ。『デクスターズ・ラボ』や『サムライ・ジャック』を作った男、いえばすごさが伝わるかしら。
『モンスター・ホテル』は雇われ仕事で、お世辞にも脚本は最高の出来とは言えないけれど、彼が担当したキャラデザや動きはとても艶やか。特に主人公のドラキュラ娘のキュートさといったら！ 3Dアニメが実は2Dアニメと地続きだということがよくわかるわ。
4. イルミネーション・エンターテインメント（ユニバーサル）：『怪盗グルーの月泥棒』（ピエール・コフィン＆クリス・ルノー監督、2010年）
『怪盗グルー』シリーズの大ヒットで一躍アニメ業界を席巻したのがイルミネーション・スタジオね。
大手のユニバーサルが後ろ盾にいるだけあって、よく広告なんかでも観るんじゃないかしら。「バナナバナナ」と喋る、サスペンダーを来た黄色い丸っこい謎生物のキャラ、あれがイルミネーションが誇る人気マスコット「ミニオン」よ。そのミニオンたちのデビュー作がこの『怪盗グルーの月泥棒』。
偏狭な中年大泥棒がいきなり現れた三姉妹の世話に追われててんやわんやになる、といった筋は『モンスターズ・インク』を思わせるけれど、堅実なアニメーション表現とドギツいスラップスティックさでピクサーとの差別化が成功しているわ。
特にスピンオフである『ミニオンズ』はイルミネーションスタジオの「ヤバさ」が最もよく出ている作品なので、『怪盗グルーの月泥棒』『怪盗グルーのミニオン危機一髪』を観た上で是非ごらんになってほしいわね。
しかし、イルミネーションの本領が発揮されるのは今年からだと言ってもいいわ。
2016年に発表されるオリジナル新タイトル二作品――『ペット』と『Sing』（邦題未定）。このふたつを注視していきたいわね。
5. ブルースカイ・スタジオ（20世紀FOX）：『I LOVE スヌーピー THE PEANUTS MOVIE』(スティーブ・マルティーノ監督、2015年）
20世紀FOXは自前のスタジオもあるんだけど、まあせいぜい作ってるのはシンプソンズ映画くらいだし、3D作品は基本ブルースカイ作品と言っていいわね。
2000年代の仁義なきアニメ戦争の最初期に反応したスタジオのひとつで『アイス・エイジ』は観た人も多いんじゃないかしら？ あまり印象に残る作品はないし、批評家筋の評価は芳しいとは言いづらいけれど、ソニーなんかと比べると安定して高収益を叩き出してきたブランドね。
そういうわけであまり過大な期待を持たずに『スヌーピー』も観に行ったんだけれど、これが思わぬ収穫だったわ。
原作の感じそのまま活かそうとした2Dと3Dの中間めいた微妙な表現は賛否両論あるだろうけれど、88分でチャーリー・ブラウンの恋物語うまく落とし込んだ良作よ。
『スタンド・バイ・ミー ドラえもん』がやろうとして大失敗したことをうまくやるとこうなる、という感じで、見比べてみると作劇の勉強になるわよ。
6. ウォルト・ディズニー・アニメーション・スタジオ：『塔の上のラプンツェル』（バイロン・ハワード監督、2010年）
ディズニー映画は2008年の『ボルト』以前と以後で大分変わってくるわ。簡単にいえば、元増田が昔観たであろうオールドグッドな2Dディズニー映画が以前、元増田が大好きだっていうウェルメイドな作劇の3D作品が以降。このラインを意識すると効率良くディズニー映画を愉しめるわ。
もっとも元増田は08年以降のディズニー3Dアニメ映画をだいたいチェック済のようね。
でも『ラプンツェル』を見逃しているのはいただけないわね！
90年以降生まれの女子にとってはマイルストーンといってもいい、新しいディズニープリンセス物語の決定版よ！！
女子にモテたければ是非観るべきだし、女子になりたければ絶対観るべき、現代女子力のパワーソース（力の淵源）よ！
7. ピクサー・アニメーション・スタジオ：『インサイド・ヘッド』（ピート・ドクター監督、2015年）
シュガー・ラッシュ以降のピクサーを観た元増田なら当然鑑賞済みかしら？
現代アメリカアニメを支配するピクサーの作劇の極致ともいえるのがこの『インサイド・ヘッド』よ。
物語自体の面白さもさることながら、「私たちはいつ、どのように成長していくのか」についてここまで丁寧に描いたフィクションは稀有だと思うわ。
8. オン・アニメーション・スタディオズ（メソッド・アニメーション）：『リトル・プリンス 星の王子さま』（マーク・オズボーン監督、2015年）
フランスは日本とおなじく2Dアニメーション映画が主流だけど、日本にも白組があるように、フランスのなかにも3Dに情熱をそそぐスタジオがあるわ。
まだまだ知られるとはいえないスタジオだけど、『カンフー・パンダ』のマーク・オズボーンが監督した『リトル・プリンス』で一躍名を上げたわね。
アメリカの大手がかかわっているスタジオでは見られないようなヨーロッパ的な叙情が特徴よ。
今後はこういう小スタジオの3D作品もバンバン出てくるんじゃないかしら？
9. ライカ：『コララインとボタンの魔女』（ヘンリー・セリック監督、2009年）
ここからはちょっと趣向を変えて同じ立体アニメでもストップモーションアニメを紹介するわ。
元増田は『ナイトメア・ビフォア・クリスマス』という映画をご存知かしら？
ああいう人形を使ったアニメはストップモーション（コマ撮り）アニメと呼ばれてファンも多いわ。一番有名なのは『ウォレスとグルミット』かしらね。
『ナイトメア・ビフォア・クリスマス』はティム・バートンの監督作だと勘違いしている人も多いけれど、実は監督を担当したのはこのヘンリー・セリック。
彼が自分のスタジオである「ライカ」を立ち上げての第一作目が、この『コララインとボタンの魔女』なのよ。
ストップモーション特有の質感を保ちつつも3DCGと見まごうばかりのなめらかなアニメーションは、気が遠くなるような数の人形パーツによって実現したもの。
セリック独特のゴシックな美意識が溢れる画面は観ているだけでため息が出るわ。
この『コララインとボタンの魔女』の成功によって、ライカはイギリスのアードマン・アニメーションズと並ぶストップモーションのスタジオとして一躍地位を確立したわけ。
ライカはこれまで三作しか発表しておらず、日本に入っているのは『コラライン』含めて二作だけだけれど、二作目の『パラノーマン』もすばらしい出来なので是非見てね。
10. アードマン・アニメーションズ：『映画 ひつじのショーン 〜バック・トゥ・ザ・ホーム〜』（マーク・バードン＆リチャード・スターザック監督、2015年）
で、ストップモーションアニメの老舗であり、ストップモーションといえばアードマンと言われるほど有名なアードマン・アニメーションズ。
配給会社はそのときどきによって変わるけれど、一貫して温かみのあるゆるさと精緻な細部へのこだわりをふせもった上質なストップモーションアニメを世界に供給しつづけているわ。
もちろん、去年発表された『ひつじのショーン』も最高だったわね。
『ウォレスとグルミット』とおなじく、テレビシリーズの劇場映画化だけれど、TV版をみてなくとも十全に楽しめるわ。むしろ、テレビシリーズの入り口としてちょうどいいくらい。
アードマンの作品はそのルックを一目見れば即座にわかるので、公開されたらとりあえずチェックしときたいわね。
11. スターバーンズ・インダストリーズ：『アノマリサ』（チャーリー・カウフマン＆デューク・ジョンソン監督、2015年）
スターバーンズ・インダストリーズはテレビドラマで活躍するダン・ハーモンが立ち上げたストップモーションアニメ会社。
その第一作目に『マルコヴィッチの穴』などで知られる個性派脚本家チャーリー・カウフマンを監督に迎えて作ったのが、この『アノマリサ』。
アードマンにしろライカにしろ「子どもも大人も愉しめる」映画が信条のストップモーションだけれど、この『アノマリサ』は完全にオトナ向けよ。
カウフマン特有の奥行きある哲学的なストーリーもそうだけれども、一番子どもに見せちゃいけないのはセックスシーン。
なんと精巧に作られた人形同士（男女ともにくたびれた中年）がヤッてる姿をえんえん見せつけられるの！ クンニから挿入、絶頂、事後まで全部よ！
いわゆる2ちゃんねるネタであり「あそこに書かれていることなんて気にしなくていいと思うぞ」で終わってしまう話を、あえて書いてみる。
就学前の幼少時から始められる楽器の代表例は、なんといってもピアノとヴァイオリンだろう。
そんなだから、当然2ちゃんねるにもヴァイオリンのスレはあるのだが、ピアノと違ってこのスレはほぼ十年来、ギスギスした空気で現在に至っているのだ。
理由は、幼少時から始めた人=アーリー組と、高校・大学・社会人くらいから始めた人=レイト組の対立にある。
結果、本スレから分家した、レイト向けスレの1に貼られるテンプレからして、その上から目線ぶりが尋常ではない。
以下の論争はすでに終結しています。
●耳の腐ったレイトに良し悪しは解らんだろう。
●ヴァイオリンはピタゴラス音律で弾く。レイトは基本的にヴィブラートを掛けてはならない。
●幼少期から習っている人に大人から始めて追いつけるワケがない。言語と同じ。
●チューナーは、調弦では仕方がない、運弓で使える、音階練習には使えない。
(中略)
汚い音、狂った音程に対する嫌悪感が、上達のインセンティブで、
これはもう、明らかに「にわかを見下す熟練者」「アーリー組自身が囚われている生存者バイアス」が合わさった結果であり、こういう対立がないピアノ組が正直羨ましい。
自分も一応はアーリー組の末席という立ち位置だが、どう見てもアーリー組のスタンスの問題だと思うのだ。
以下、そんなアーリーの特徴を、ヴァイオリンの特性も絡めて書いてみる。
主にピアノと比較したヴァイオリンの特性をシニカルに書くと、こんな感じである。
ヴァイオリンをとても良く弾ける人間がひとたび音を出せば、それはもう堂々の主役として、当たり前のようにステージを支配する点において「楽器の女王」であることは間違いない。
しかし楽器のポテンシャルや柔軟性から言えば、「楽器の王様」はピアノだろう。
そんなヴァイオリンは、親の時間的金銭的負担が大きい時点で幼少時からの学習者がピアノほど多くないところに、演奏技法習得の難しさ(≒誰もが知っている名曲を弾けるまでに至るための要求水準の高さ)から、恐らく多くの脱落者を生んでいることが容易に想像できるシロモノである。
それこそ面倒どころか、個人的には世界一難しい楽器としてギネス認定すべきだと思うくらいで、ヴァイオリン弾きの生存者バイアスが強いと思う理由である。
全5曲のうち、重要なのは3番以降の3曲で、これはプロオケの入団試験にも頻出する曲であり、つまりヴァイオリンでクラシックをやるなら、3曲のうちのいずれかをプロ・アマ問わず習得していることが望ましい曲である。
というかメンデルスゾーンの協奏曲やバッハのシャコンヌやチゴイネルワイゼンみたいな名曲を弾こうと思ったら、モーツァルトをまともに弾けるのは大前提だし。
そんなこともあり、実際プロ目指す人は小学生でモーツァルトをやってしまう。
しかしアマチュアになると、幼少時から習っていてもここまで来る人は1割程度だと言われている。
そして、そんなごく一部の人=アーリー組が、大人になってもヴァイオリンを続けていると、こういうわけだ。
しかし、アーリーにそんな自覚は多分ないはずで、それどころか超頑張って俺はここまで来た的な自負があり、これがレイトとの軋轢の根本原因だろう。
つまり、幼少時から始めた人が超上手くなって続けるか、そうならずにヴァイオリンを習っていたことそのものを無かったことにするかという両極端な事情をどうにかしないと、今後もこの憂慮すべき事態は続くと思われる。
「オブジェクト指向は現実にある"もの"を元に設計します。だから人間にとってわかりやすい設計が自然にできるのです」
なるほどなるほど
「まずHTTPServletクラスを継承したクラスを作ります。doGetメソッドはHttpServletRequestクラスのインスタンスを引数にとります」
はあああああ？？？
今敏のやつ。
アイドルのストーカーってのは聞いてたけど、いつもの今敏で現実と妄想？夢？がごっちゃになるようなパターン。
つなぎとか演出はうまいし作画はすごいと思うけど、あまりにもワンパターンすぎて飽きる
そーゆー意味ではワンパターンとはちょっと違う東京ゴッドファーザーズは途中までは面白かったけどラスト微妙だったしなあ
ひたすら演出や作画、惑わされるような感覚に酔うのを楽しむ映画であって、物語やキャラがうすいんだよなー
それはそれですごいとか隙って言う人がいるのもわかるけど
妄想代理人はまだ見てない
結果的に予想が合っていることが多いとしても、それはあくまでも結果論
（略）
その通りだと思います。
本当もう、完全におっしゃる通りで、今から長文を書きますが、反論とか俺は間違ってないとかじゃなく、
前のトラバでも書いた通り、本当に反省しないといけない事項だと思っています。
僕の元の増田も、同じ事を書いているつもりで、
こう、議論が活発になっていって、ドンドン相手と意見をかわして行くと、
次第に「次に相手が何を言うのか？」を最初の一言二言ぐらいで、予想して、意見を言っちゃう事があるんですよね。
これは、本当によくないなあ、反省しないとなあ、って毎回なるんですけど、中々治らない。
この部分ですね。
相手の意見を遮ってまで、意見を言うのはよくない、と反省している。
なんだけど、次に
話を最後まで聞かないことはあるけど、その話の予想が間違ってた事が、ほっとんど無いんだよね。
と書いてあるから
増田さんは「てめえ、反省しろや！ あってるあってはないは関係ないだろ！」って思われたのかもしれませんね、確かに言葉の選び方がよくなかった。
ただ、さらに続いて
「あれ、あのとき先走って、相手の喋りを中断させなかったか？」って思い返して
ぶっちゃけ、仕事の成果物を作るため、という目的に関しては、別に反省するようなことじゃないんだけど、
一緒にやる人を不快にさせてまで、することでもない、と僕は思ってるので、これはちゃんと反省しないとなあ。
ヒートアップしすぎないよう、気をつけないとね。
と言った感じで、ちゃんと自分でも、それによって出来る成果物に差は出るわけじゃないけど、最終アウトプットを作るだけが仕事じゃないんだから、ちゃんと反省しないと駄目だよね。
と書いていたつもりです。
なので、この辺の文章が伝わらないのも、僕の文章がイマイチなので反省しないといけませんね。
もちろん、それが先走りになって間違いを言ってしまうこともあるんだけど、
僕としては「何故僕が間違えたのか？」も含めて、気づきになるので、間違いを恐れずにドンドン発言をしていきたいと思っている。
俺の部下でもこっちが何か質問するとその回答の先を話そうとしてくる
に通じてしまったのかなあ？ とも思いました。
ここでいう
それが先走り
っていうのは、
僕「いいですね、ロコモコバーガーっていう新商品が出たらしいですよ」
上司「うん？ それマクドだよね？ マクドじゃなくてロッテリアのつもりだったんだけど」
こういう先走りを言ってます。
つまり、相手の質問の先を予想したりとか、意見を遮ったりとかじゃなくて、
質問が足りずに、自分の中で補完して、答えを出しちゃうタイプの先走りですね。
間違いがないようにするには
僕「どこにしますか？ マクドならロコモコバーガーっていうのが出てるらしいですよ」
こんな感じの方が確かに良い会話にはなると思いますが、
俺の部下でもこっちが何か質問するとその回答の先を話そうとしてくる
元の、マクドナルドと決めつけるような回答は、この文章でいう「その回答の先」ではないと思っています。
そりゃまあ、先と言われれば先なのかも知れませんけど、
ある程度は阿吽の呼吸というか、今までの会話を踏まえて、進めるべきだと、僕は思っています。
この例で言うと
上司側には
「ハンバーグといえば、ロッテリアという共通見解が共有されていない」
であるとか
「昼ご飯の伝達はジャンルではなく、具体的な店名にした方が誤解を招かない」
当然僕側にも
ただ、こうやって会話をすることで
「片方がちょっと会議が長引いて、店内で待ち合わせ、となった際に、2人とも別々のマクドとロッテリアに行っている」という最悪の展開だけは、回避できるわけなので、
そこまで最低の選択肢だとも思っていません。
そりゃまあ、この例ならどうでもいいですが、実際の仕事だと、
僕「出来ますよ、A画面のa項目のOnClickにメソッドを仕込めば可能ですね」
僕「うーん、α機能があるB画面やC画面とはHTMLの構造が違うので、既存のメソッドを呼ぶだけでは無理ですね。
ただ、画面から取得する箇所が違うだけなので、改修自体は難しくないです」
上司「あーそうかB画面と同じ要領で出来るのか、でも関数自体は増やさないといけない？」
上司「それじゃあ、駄目だわ。HTMLの改修だけで済ませたかったんだよなあ」
こんな感じの流れですかね？
もちろん、この会話の流れでも、
僕には
という問題点があるし、
上司には
「メソッドの追加無しに、HTMLの改修で可能かを伝えていない」
という問題点があるわけですよね。
細かく見て行けば
「α機能をB画面やC画面と同様と決めつけている」とか
「既存のメソッドという言葉を、どの.jsファイルの既存かをすり合わせていない」とか
「既存のメソッド？ としか聞かれていないのに、改修の難度まで答えている」とか
そういう、先走りもあるわけですよね、これらは偶々合致していたから、問題なかっただけで。
（推敲してて思ったんですが、改修の難度まで答えるのは、もしかしたら不快に思われる方がいるかもしれませんね、すいません）
とまあ、長くなりましたが、全面的に増田さんの意見には賛成です。
