「マシン」を含む日記 RSS

はてなキーワード: マシンとは

2016-08-17

靖国神社でのコスプレを見て、コミケコスプレを思い浮かべた

終戦記念日高校時代の唯一のブサイクな友人と靖国神社に行った。

決して2人とも靖国神社が好きだとかそういうわけではない。

ただ午後のVRマシン体験会に参加するための前座のようなものだった。

靖国神社旧日本軍コスプレをしている人間を見たときコミックマーケットコスプレが脳裏に浮かんだ。

日本軍の格好をしている人間は、容姿がいい女だったらコスプレでもして静かに楽しく生きていけたのではないかと思い続けていた。

愛国心だとかそんなの無く、独裁が始まってもセックス笑顔で生きていける存在が一番勝ちだ。

自分だって見てくれがいい女なら、高校時代は楽しくて友人もたくさんいてVRも靖国神社も興味なんか持たない。

カス大学になんか行かないで、日吉の近くのホテルセックスでもしていたとすら思う。

持病の薬の副作用で顔が赤く腫れ上がり、血やら膿やらが吹き出て今でもひどいニキビ跡がべったりとくっつき醜い容姿だ。

とりあえず、去年と違い今年の終戦記念日靖国は予想外に静かだと感じた。

昨年と違い平日だということが関係しているのだろうか。

また、マイクメガフォンと言ったものが目立たなかった。

個人的にうるさいのを期待していたが、拍子抜けした。

仮想現実(VR)が自分を醜い容姿から解放してくれると思ったが、そんなことは微塵もなかった。

靖国神社コスプレをしている人間や、ウェブでロクでもないことを言っているネトウヨとか言われる人たちも解放されなそうだ。

所詮はただのモニター付きゴーグルだった。

貯金が割とたまったが、美容整形にでも期待したほうがいいということを実感させられた一日であった。

自分の酷いくせ毛や持病の治療薬の副作用でついた深いニキビ跡や赤み、大きな顔やらをどうにかしたい。

効果があるかもわからないし、できるかもわからない。

一生醜い容姿なら死んだほうがマシな気がしてならない。

容姿がよくなりたい。

2016-08-16

VRセックスなんかより、風俗美容整形に期待したほうがマシ

最近はVRとアダルトとの融合やらを期待する人間がいる。

しかし、本当にそれが魅力あるものなのかと考えると怪しい。

現状のVRと言うものに、美男美女が楽しんで行うセックスと同等のもの提供することはできない。

正直、コンシューマー向けのVRマシン2種類の体験会に行ったがゴーグル付きディスプレイしかないと感じた。

センサーがついたディスプレイしかない。

自分はVRというものに当初期待していた。

容姿が醜い自分が、獲得できなかった体験ができると。

そんなことはなかった。

ただ、持病の治療薬でできた酷く醜いニキビ跡がべったりとくっついた肌が蒸れただけだ。

体験会の案内の若い女が化け物を扱うような態度だっただけだ。

もし、自分が見てくれがいい女ならVRなんか期待しないで、コミケやらで露出の高いコスプレでもして静かに楽しんでいる。

正直、VRというディスプレイ付きゴーグルというもの自分にとって大したことはない。

そして、大したものではないしインフラになり得る要素も思いつかないので大した需要は見込めないと感じている。

貯金が割とたまったが、美容整形にでも期待したほうがいいのかもしれない。

自分の酷いくせ毛や持病の治療薬の副作用でついた深いニキビ跡、大きな顔やらどうにかしたい。

容姿がよくなりたい。

効果があるか分からない美容整形を調べ始め、どうにもならないのかと泣き出すだけである

2016-08-07

ディープラーニングAV女優類似画像検索サイトをつくった

Babelink

http://www.babelink.net/

作った動機は、そっくりNAVIをつくった人と似ていて技術勉強のためと今ある類似検索サイトへの不満からです。

そっくりNAVI - 気になる子顔写真で、似てるAV検索できるサイトを作った

http://anond.hatelabo.jp/20160719033025#tb

... 素人からも探せるのは素晴らしいと思います

ディープラーニング最近流行りの技術で、一般的物体認識では人間匹敵するか

もしくは超えるぐらい画像認識の精度がいい手法です。

今回は自分が持っている画像有名人に似ているAV女優を探すという

極めて実用的な問題にその手法を試したいと思い、サイトをつくってみました。

使った主要なライブラリを紹介しておきます

■使ったライブラリなど

python (プログラミング言語)

PostgreSQL (データベース)

・flask (Web構築)

opencv (画像認識)

・dlib (顔検出)

chainer (ディープラーニング)

・FlexSlider (画像スライダー)

・Awesomplete (入力補完)

ぼくは一応エンジニアのはしくれですが、pythonとか仕事でちゃんと使ったことなレベルです。

それでも3~4ヶ月程度である程度のサイトはつくれるので、みなさんも是非つくってみてください。

課題

ディープラーニングでは非常に多くの画像機械学習させる必要があるのですが、

現状では学習のための画像がまだまだ足りていないので、あまりいい精度はでていません。

あとはディープラーニングで精度を高めるには、ハイスペックGPUマシン必要になるのですが、

そんなもの持っていないので精度をこれ以上あげるのは難しかったです。

そんなかんじで、まだまだ改良の余地はたくさんあるので、楽しみにしていてください。

■参考にしたサイト

完全に一致

http://anond.hatelabo.jp/20101203150748

京大画像処理を学んだ僕が本気でエロWEBサービス作ったった

http://anond.hatelabo.jp/20130122180847

UIは一応Netflixを参考にしてます


画像収集サーバー容量の問題もあり、していないので画像検索を気軽に試してみてください。

Babelink

http://www.babelink.net/

VRは大したことがない。

大学夏休み、どうにもならないジェンダーバトルやらの煽り合いを繰り返しているウェブに飽き飽きしている。

働く気概能力もない。

ウェブ風俗嬢の客の悪口や、それを持て囃す輩を見ても仕方がないからPSVRの体験会に行ってきた。

自分はVRというのは次世代の何かであり、ジェンダーソバトルやらとは違うフィールドへ己を連れて行くものだと期待していた。

銀座には見てくれの良い女がいた。

自分がどんなに見てくれが悪く酷い思いをしてきたかというのがこみ上げてきて苦しかったが俯いて歩いた。

そして、ソニービルでPSVRを装着した。

まず、解像度が低い。

そして、暑い中を歩いてきたがために汗だくだったのでグラスが曇る。

VRというもの所詮は画面が付いたゴーグルしかないと感じた。

案内の女の自分への態度が、汚物を扱うようだった気がしなくないというのが一番現実だった。

PSVRを購入する権利があったが、見送ることにした。

その後、やることもなくアキバに行ったらヨドバシでも予約を受け付けているようだった。

持病の治療薬でついた酷く深いニキビ跡だらけの皮膚はドロドロである

本屋に入ると、なんちゃらアートオンラインやらが平積みされている。

そんなラノベに登場するVRマシンレベルなら流行るだろうし楽しいだろう。

しかし、現状のVRというのは3Dプリンターのようなものに成り果てる気がしてならない。

ようは大したことがないということだ。

薄々皆はVR(仮想現実)が大したことがないと気づいているのか、現実ゲームに近づけるというAR的な傾向もあるらしい。

そんな風に、現実で見てくれの良い人間がどこまでも特権を得る。

VRなんか買わずに持っている金で効果があるのかないのか、持病でできるかも分からない整形でもしようか考えている。

容姿がよくなりたい。

2016-08-05

ゴジラと刺し違えたのは誰か(ネタバレ)

自分今日見てきてので、一つ書く。



シン・ゴジラカタルシスは散々言われ尽くされてる事だが、ゴジラブレス攻撃第一波に尽きる。

主人公側(政府側)のステートマシン図を書きたくなるような目まぐるしい報告と対応も凄かったが、

その凄さは恐らく「敵が無能だと強さ引き立たない」という理由演出されたものであり、

あくまフォーカスの中心はゴジラ攻撃にある。




観終わった後も「あの攻撃だけでももう一回見たい」という気持ちが強く、

多分DVDダウンロード権を買うことになるだろう。

で、あの攻撃の何が凄かったのか数時間考え続けて、一応の結論自分の中で出たので、書き留めておく。




まずあのブレスが設定上どういう位置づけかという点だが、あの攻撃は、波動砲ガミラス視点)だったのだ。

発射に至るまでの溜めの長さといい、ゴジラ自身制御しきれない巨大なリスクを伴った手のつけられない破壊力といい、

存在感として波動砲位置づけと見た。

庵野つながりで巨神兵ブレスと見ても良いのだが、巨神兵との違いは、巨神兵が最終的に大海嘯に押し切られて自滅するのに対し、

ゴジラ攻撃は押し切られない事。

とにかく撃ったら終わる無敵兵器位置づけなので、巨神兵よりは波動砲に近い。

(とはいえ、後述するように最後は「ガス欠」が敗因なので、そこは巨神兵と同じと言える)




で、ブレス攻撃第一波に物語上の位置づけについてだが、

見てる人は皆同じことを思っただろうが、今回のゴジラブレスを吐くまで攻撃らしい攻撃を全くしないのである

町の中をのたくってあっちこっちを押しつぶしたのと、煙の中から橋をちゃぶ台返しした事以外は、実に忍耐強いというか、攻撃をしない。

神心会のデンジャラスライオン加藤清澄パンチされまくっても欠伸してる夜叉Jrのように、まるで何もしない。

ゴジラ攻撃するのは「有効攻撃」をされた時だけなのである




これは別にゴジラが「攻撃しなければ無害であり、本当は戦いたくないのだ」などという甘っちょろい事を意味してるわけではない。

第一形態から第四形態に至るまでずっとそうだが、

ゴジラは移動するだけでも甚大な被害を発生させる存在であり、「放置しておくと増大するリスク」そのものなのだ

いるだけでも迷惑だが、取り除くために行動するなら痛みとリスクを伴う癌細胞。それが今回のゴジラだ。

から有効攻撃を食らうまではゴジラ攻撃しなかったのだ。

今回の映画政府側は何度となく「民間人被害が出るけど攻撃するか」を問われるが、

ゴジラ最初からブレス撃ちまくりながら侵攻してきていたら、その葛藤は描けなかっただろう。




で、テーマ上の都合は上記のとおりとして、

ゴジラの都合に立ってなぜ攻撃しなかったのかを考えると、ブレスの「奥の手」としての悲哀が見えてくる。

ゴジラの負けが決まったのがいつかという点を考えると、それはあのブレス攻撃が終わってゴジラ活動停止した時だろう。

あの攻撃で「ガス欠」という決定的な弱点を晒ししまった事で、

主人公側はゴジラ血液凝固剤を投与するための道筋が見えてしまった。




確かに「止め」を刺したのは血液凝固剤を飲ませた事で、その点はショボく見えるのだが、

重要なのはそれより前に無人機による波状攻撃によって放射能を撃たされて、意図的に再度ガス欠にさせられてしまった事で、

あの状態になったらもう血液凝固剤でも口の中に爆弾でもバンカーバスター釣瓶撃ちでもなんでもできるわけで、

止めの手段問題ではない。

ガス欠がバレた時点でゴジラの勝ち目はなくなっていたのだ。

その意味で、勝負が決したのはゴジラが奥の手であるブレスを使わせれた第一波が全てだった。

からあのブレスシーンは凄かったのだ。




ということで表題ゴジラと刺し違えたのは総理大臣

総理ゴジラブレスで死んだが、ブレスを撃たせたことでゴジラの死も決まった。

神羅カンパニーミッドガルキャノンvsダイヤウェポン戦と同じで、あのブレスシーンは、総理以下内閣首脳とゴジラが刺し違えたシーンだったと考える。



あの総理大臣は2つ印象的なシーンがあり、一つはゴジラ第3形態の時に巻き添えになる民間人を見過ごせず、攻撃中止を決断したシーン。

もう一つは米軍によるゴジラへの攻撃東京の空が赤く染まっているのを見ていたシーン。

特に前者の方は、直後のゴジラのしばしの停止とも相まって、日本政府の弱みを敵の眼前に晒したシーンであり、総理のその後の敗北を強く暗示する物だった。

ゴジラ鎌倉に再上陸した後東京に向かい登場人物が「なんでこっちに来るんだよ」と嘆くシーンがあるが、

その理由は、あそこで攻撃を止めたことが一因なのだろう。

要は、民間人を救おうとしたことで勝機を逸したと同時に「人がいる場所なら攻撃されない」と舐められたわけである

その事が、熱核攻撃というリスクの拡大再生産と、最終決戦での主人公民間人に巻き添えが出ようが何だろうが攻撃する決断につながったのであり、

またゴジラ東京駅活動停止した理由も、人の多そうなビルの近くが一番攻撃されにくいという判断によるものかもしれない。




攻撃するべき時に攻撃できなかったことで、リスク東京消滅の寸前まで大きくしてしまった総理

一方で、ゴジラの死因となった総理でもある。

決断力あり過ぎに描かれていると非難も多い日本政府だが、それは彼らが死んだ時に「その後」の日本政府人材欠乏ぶりを際だたせるためのものだろう。

実際、農林大臣総理就任した時の頼りにならない感は強烈だった。

だが同時に、あそこで死ぬ総理は、ゴジラと刺し違える総理なので、無能に描かれるわけが無かったのだ。

なぜ良作程度のシン・ゴジラが傑作と騒がれるのか。

ネタバレ含む

 

 

(ここから飛ばしてOK)

 

庵野秀明総監督として制作されたシン・ゴジラの評判が高く、一部では傑作として騒がれている。

しかし、パニック映画としては、途中で被害を受ける一般人の姿が殆どなくなり、怖さの演出がなくなっていき、完全体となったゴジラには恐怖感をあおる演出はなく、強さはあっても怖さはない。

序盤の深海魚的ないびつさも、慣れない人には恐怖かもしれないが、基本的には間抜けな顔をしている。

怪獣映画としても、ゴジラにさほどの強さとしての演出が残念である。硬く大きい、それは原始的で分かりやすい強さではあるが、特別な強さを感じない。

放射火炎は一見強そうだが、よくよく見てるとバーナーであり、色々な建物破壊するが、あのゴジラならしっぽをぶつけるだけで問題ない。全身からバーナーを出すのも、防御のためで強いというよりは防衛反応の強い生き残ることに特化した存在だ。

それも凍結作戦の推移を見るに、無人機での波状攻撃で防御バーナーを無効化してからバンカーバスターによる攻撃破壊できそうに見える。(もちろん細胞再生機能が強く、解決はしないと劇中で描かれているが、それでも強さを感じない一因となる。)

最終的に転がされて、口から凝固剤流し込まされて活動停止とか見せられては「ああゴジラ強かったな」と言う思いが薄まってしまう。

メインとなっている会議シーンはどうだろうか、今回の会議シーンは日本行政手続きこそを大事にすることを皮肉的に描いている。

現場から連絡が数珠つなぎに上がって、総理命令数珠つなぎに下されていくなどは、寿限無のような落語的愉快さをもっているとは思う。

無駄な溜がないことも好まれている。

しかしながら、会議の展開に緩急がなく急ばかりでメリハリが弱い、最初からクライマックスな展開のためいわばすべて緊急場面の会話で、緊張状況の雰囲気に慣れてラストシーンへの緊迫感ですら冗長になってしまう。

また、終盤の会議問題発覚→提案解決の流れが簡単すぎて、その問題を描く必要があったのかと言うシーンが続くのも緊迫感が薄れる原因の一つだ。

解析のためのマシンパワーが足りない!→世界応援を依頼→日本を信じるわOK!→解決

薬剤制作に1日足りない→フランスに働きかけを→解決

世界的な協調演出したいのかもしれないが、無意味だったのではないか

世界的な展開と言う関連でいえば、今回の映画日本ゴジラと銘打たれているが、基本関東vsゴジラであり、もっと言えば霞が関vsゴジラであって、後自衛隊ぐらいでそれ以外は一切戦っていない。(薬剤作成に協力した企業ぐらいか。)

日本の他の地域描写はないため、東京近県以外にはあまり身につまされない。

今回のゴジラと言うのは、原発事故津波地震メタファーであることが映画からすぐにわかるが、つまるところ東日本大震災なのであり、あの震災体験した東京人達には身近な恐怖として心底感じるものがあるかもしれない。

しかし、西の地からすれば、(それが人間としてどうこうはおいておいて)やはり他人事のように関係のない話にみえてくる。

このように、面白みがない映画ではないが、絶賛するほどに良くできた映画でもない、良作と言う程度と感じられる。

 

 

(ここまで飛ばしてOK)

 

シンゴジラを傑作とすると感想を見ていると、「ようやく邦画として世界と戦える映画ができた」みたいなものが出てくる。

それも比べているのは、特に今の邦画である

米国で週間興行収入1位を記録した呪怨はどこ行った?)

邦画と比べた時シンゴジラは確かに面白い部類に入るだろう。

 

ここらへんの事情は、結構割合で、「字幕が読めない」「吹き替えが下手でいや」「顔の区別がつかない」などの理由で”邦画以外を見れない層”が結構いて、

この邦画しか見れないような手合いが、今までの、つまらなくつまらなく作られた日本人オンリードラマ邦画を、これしか見れないからとずっと我慢して見続けてきた結果、シンゴジラを見て「これは凄い傑作だ」と感じるのだろう。

また、普段映画館に行かず家のテレビ映画を見ていたような層が、庵野秀明+ゴジラと言うことで見に行って、大画面+大音響にいつも以上に心が動かされたのかもしれない。

この辺り、シンゴジラを絶賛している人たちが「つまらないとか○○な証拠ww」とか言って、シンゴジラ批判する人物の、人間性の否定が始めているところから

初めてジャンルに触れた時に感動してファンになった人が、普通批判程度にも噛みついているのと良く似ていることや、特定ジャンル新規ファンが来た時のアンチとの口喧嘩とよく似ていることから

映画ゴジラでで良いものを見るという経験に乏しい多くの人が見て感動したのではないかと感じられる。

 

ただ、多くの人を映画館に足を運ばせる誘因力があり、それを、ただ足を運ばせるだけではなく、ちゃんと満足させた。それは重要出来事だ。

その意味で、シンゴジラは確かに傑作であり、多くの人を映画へと興味を持たせ希望を持たせたという意味で、日本映画界の一つの希望だろう。

2016-08-01

Pokémon GOSNS必死シェアしているおっさんを見ると腹が立つんだが

お前ら今までポケモンやったことあるのかと言いたいよね。

しろたかゲーム」とバカにしてきたんだろ?

「USのApple Storeから落としてみましたがまだポケモンいません^^;」

じゃねーよ!!!

すっげー痛いんだよおっさん!!!



そもそもポケモンの何を知ってるんだよ!!!






ヒトカゲ選んでニビジムで顔真っ青になったことあるのかよ!

フラッシュ存在知らなくてイワヤマトンネルフラッシュなしでプレイしたことあるのかよ!

シオンタウンの音楽が怖いから通るとき自転車に乗る気持ちがわかるのかよ!

カビゴンがなかなかどいてくれなくて笛を使うなんて発想なくて詰んだ経験あるのかよ!

初めて通信ケーブル通信をしたあの高揚感を味わったことあるのかよ!

ダウジングマシンでほぼ全ての通路ダウジングしたことあるのかよ!

捕まえる為に必死に削ったのに最後急所にあたって絶望したことあるのかよ!

サファリパークカイロスでなくてタマタマばっか出てきて辛かったことがあるのかよ!

げんきのかたまりがもったいなくて使わないままゲームが終わったことがあるのかよ!

マスターボールを間違えてトレーナーポケモンに使ってしまったことあるのかよ!



マジでいてーわおっさんども。

いか明日ゼニガメゲットしました^^;」とか投稿すんじゃねえぞ!!!



赤と緑からやり直せ。

しろからやれ。

2016-07-29

Windows10駆け込みアップデート

やっぱり必要な気がしたり、せっかくだからWindows10ライセンスも確保しとくか…みたいな気持ちが今更ながら沸いてきて、3台ほどやった。一番油断していた自作マシンアップデート不可で、途中でロールバックに入ってしまって驚いた。Windows7に戻ってからは、とくに問題が出ていないので、無事もとに戻ったんだろう。

どうして、もう少し余裕を見て対応出来ないんだろう?

2016-07-21

ポケモンGOなのか頻繁に立ち止まり端末みてて、歩きスマホしない人なのかなーと思ったらダウジングマシン使ってたやつがいたらオレです。

2016-07-20

Pokémon GOSNS必死シェアしているおっさんを見ると腹が立つんだが

お前ら今までポケモンやったことあるのかと言いたいよね。

しろたかゲーム」とバカにしてきたんだろ?

「USのApple Storeから落としてみましたがまだポケモンいません^^;」

じゃねーよ!!!

すっげー痛いんだよおっさん!!!



そもそもポケモンの何を知ってるんだよ!!!






ヒトカゲ選んでニビジムで顔真っ青になったことあるのかよ!

フラッシュ存在知らなくてイワヤマトンネルフラッシュなしでプレイしたことあるのかよ!

シオンタウンの音楽が怖いから通るとき自転車に乗る気持ちがわかるのかよ!

カビゴンがなかなかどいてくれなくて笛を使うなんて発想なくて詰んだ経験あるのかよ!

初めて通信ケーブル通信をしたあの高揚感を味わったことあるのかよ!

ダウジングマシンでほぼ全ての通路ダウジングしたことあるのかよ!

捕まえる為に必死に削ったのに最後急所にあたって絶望したことあるのかよ!

サファリパークカイロスでなくてタマタマばっか出てきて辛かったことがあるのかよ!

げんきのかたまりがもったいなくて使わないままゲームが終わったことがあるのかよ!

マスターボールを間違えてトレーナーポケモンに使ってしまったことあるのかよ!



マジでいてーわおっさんども。

いか明日ゼニガメゲットしました^^;」とか投稿すんじゃねえぞ!!!



赤と緑からやり直せ。

しろからやれ。

2016-07-06

コンピュータ言語言語ごとの特徴を俺が教えてやる(異論は認める

コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある(特徴のない言語は廃れていく)。

まり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。

なお、取り上げるのはある程度広く使われている言語に限りたいと思う。

TL;DR

言語 概要
C言語 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグやす
C++ マニアック言語、高速、習得大変
Java サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる
C# 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語
Perl 広く使われていたが今は若干時代遅れのスプリクト言語。汚い
Python Perlにかわって主流になりつつあるスクリプト言語。綺麗
PHP Web開発にフォーカスされたスクリプト言語一世を風靡した。
Ruby とても綺麗なスクリプト言語
JavaScript ブラウザで実行出来る唯一の言語言語自体はいまいちだが、ブラウザ事情需要あり
Go サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語

詳細

C言語

メモリに直接アクセスして書き換えるといったコンピュータ機械語に近い言語構文を持つため、高速な処理が可能言語

コンパイラ歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語

一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディング効率が良くなく、多種多様バグを生みやすい側面も持つ。

ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。

C++

C言語オブジェクト指向を導入した言語C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。

C言語の速度を維持したままオブジェクト指向テンプレートなどの効率的記述可能にしようとした意気は真っ当だったのだが、

当時最先端だった色々な技術思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。

C++理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。

速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。

Java

サーバサイドで安全コードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。

当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリ解放忘れというバグを生まず、

サーバサイドなどで何千時間動作するソフトウェアに適した言語として受け入れられた。

必然的エンタープライズ用途で利用されることが多く、各種ツールなども豊富人海戦術がしやす言語という側面も出てきた。

一方でブラウザHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。

ガラケーアプリや(ちょっと違うが)Androidなど、クライアントサイドでも使われることがある。

プログラミング言語最初Javaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。

C#

クライアントサイドで安全コードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。

元々はWindowsクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。

マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。

Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。

自作ゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。

Perl

ほぼ全てのLinuxディストリビューションに含まれており、ツールや様々な用途で使われていた。

上に紹介したC、C++JavaC#のようなコンパイル言語とは違い、(少し語弊はあるが)1行ずつ実行してエラーがあれば止まるスクリプト言語である

ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である

20年近く前にWebCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。

しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存コードもどんどん別の言語に置き換えられていることが多い。

日本大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。

Python

後発のスプリクト言語。こちらもほぼ全てのLinuxディストリビューションに含まれており、それゆえに広く使われている。

インデントまで言語仕様規定することで、誰が書いても読みやすコードになるように考えられている言語である

Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。

ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。

最近だとマシンラーニング系のライブラリPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。

最初に覚える言語としては良い選択肢だろう。

PHP

Web開発に特化したスクリプト言語CGIの代わりに使われ始め、一世を風靡した。

以前CGIWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。

またphp.net豊富ドキュメントスニペットのおかげもあり、開発初期の効率が大変に良い言語である

残念なことに、言語API設計がいけていない点が多く、一部の人から蛇蝎の如く嫌われている。

今でも根強い人気があり、海外でも小規模プロジェクト最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。

Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。

なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。

Ruby

綺麗なスクリプト言語日本発で世界的に普及している数少ないIT技術の一つ。

言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWebフレームワークの登場で、Webアプリでの採用例も一気に増えている。

基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである

スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語

サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。

一方で、なぜかRuby採用するWeb側のフレームワーク(具体的にはprototype.jsCoffeeScriptはいつもクソなので、そちらは深入りしないのが吉。

JavaScript

ブラウザで動くスプリクト言語ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語

言語としてはプロトタイプベースオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。

言語仕様イマイチで、大変バグを生みやす言語であり、また関数スタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが

ブラウザで動く言語現在これしかないので、大きなシェアを持っている。

一部の物好きがサーバサイドでこの言語を使おうと(主にnode.jsで)四苦八苦している(とはいえ、1つの言語Webサーバが完結するのは大きなメリットだ)。

ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。

まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。

Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である

最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsサーバサイドもできるしで、意外とオススメだったりする。

GO

C、C++Javaと同じでコンパイル言語サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語

その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。

それ以外の目的ではあまりこの言語採用するメリットはないが、ニッチ用途ピンポイントで抑えており、これから広く利用されることも期待される。

コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである

まとめ

繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。

ここに挙げた言語は何らかの特徴があり、何らかの用途必要なので生き残っている。

その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。

2016-07-05

空白の10年間を取り戻している

以前に3D酔いを克服した増田を書いた。



3D酔いが克服できた



その後steamサマーセール過去の名作を1000円以下で買い漁った。

もう続編が何本も出てるようなやつだ。

今その1作目から順に遊んでいるが、自分たか3D酔いのためにこれほどまでに人生の損をしていたのかと嘆きたいくらいの気分で一杯だ。

3D酔い対策のために肩を左右に揺すりならが遊んでいるが、それもまた臨場感があってよい。

それでもまだ30分も遊ぶと胸焼けに近いものがなくはないが、それを差し引いても楽しい

恐らく自分3D酔いに弱いことを認めたくないために海外FPSを頑なに否定し続けていたのだろう。

それが克服できた今にしてみれば、なんとも滑稽なアンチ思考しか思えないくらいに下らない。

今までゲームといえばコントローラーアーケードスティックしか使ったことがなかったが、キーボードマウス操作する感覚が新鮮で、しかマウスでの方向転換は直感的でコントローラーより何倍も操作がし易い。

コントローラーでの操作に比べて、突然羽が生えてしまたかのように自由に動ける。

この感覚だけでも正直言って病みつきになりかねないくら楽しい

core2quad以降のCPUを積んでいるデスクトップマシンなら2万円以下のグラボで新作以外大半の名作は遊べるからPS4とか手が出なくて悩んでるなら超オススメ

もうsteamサマーセールは終わってしまったが、大体日替わりで色々なゲームセールをしているので、とりあえずアカウントだけ作っておいてたまに覗いてみるといいよ。

まらない意地と選り好みでどれだけ損をしてしまったのか。

今日から必死で取り返す!

2016-07-02

初めて日焼けマシンを使った

最近通い始めたジム日焼けマシンが置いてある。

それをちょっと試しに使ってみた。


自分は自他ともに認める色白。

彼女には「人間になったもやし」と言われてしまった。

色白に対し少々コンプレックスを抱えていたので、

から日焼けマシンに興味があった。


500円で10分、1000円で20分で、

今回は時間があったか20分を選択

機械の外にあるコイン入れに500円玉を2枚入れて筒形の日焼け装置の中に入りスタート

青白い光に身体中が包み込まれた。

何だか日常感覚を味わいちょっと気分が高まる

日焼けということで少々熱いのかと思っていたが全くそんなことはなかった。

バンバンと風が送られてくるので涼しく、むしろこれできちんと日焼けできるのかと思ったほどだ。

こうして最初のうちは初めての日焼けマシン体験を楽しめたものの、20分間機械の中で突っ立っているだけなので当然飽きてくる。

本当にやることがないので、大半はただ眼をつぶって時間をつぶしていただけだった。


20分が経過しようやくマシンの外に出た。自分の身体を確認すると少し黒くなっている。

なんだが嬉しくなった。

この調子で繰り返していけば人並みの肌色に近づくのかなと妄想?を膨らませ、

今度ジムに来たときもまた身体を焼こうと決めた。




・・・・・・

以上は午前中のことなんだけど、

今すっげ~~~~~身体が痛い。

日焼けマシンなんてもう使うか!

2016-06-21

http://anond.hatelabo.jp/20160621144135

Zbrushで作った億ポリゴンモデルとかをリアルタイムで動かせるマシンは流石にないだろ…スキンメッシュ計算だけでとんでもない時間が掛かるんちゃうか。

音楽家はもうちょっと大人になるべき

http://b.hatena.ne.jp/entry/togetter.com/li/989697

このネタ、定期的にやってくるね。見るたびにほんとクソだなって思う、こういうこと平気で言うアーティストって。

結局、世の中の事象を表面的にしか捉えられない極めて残念な頭脳の持ち主だってのが露見するからこういうのはできるだけ見たくない。

CCCDレーベルゲートCD(以下CCCD統一)は、別に必要が無いのに突然作られたわけじゃない。ビジネスとしてそれが必要だと判断されたから作られた。それが成功か失敗かに関わらず、産業を護るための1つの手法として作られた。

当時、音楽世界を猛烈な勢いで襲ってきたのは、「印刷技術陳腐化」と、「それに伴う経済圏破壊」だ。

音楽が、中世パトロン音楽家が養われていた時代から先に進めたのは「印刷」の技術のおかげだ。楽譜印刷し、アナログレコード印刷し、そしてCD印刷することで音楽お金に変えることに成功した。1つのマスターを大量に印刷し複製すること、その「印刷」が特別技術であったからこそ、そこに金銭的な価値が生まれ音楽を金に変えることに成功した。

マネタイズが上手くいった場合恩恵などいまさら語ることではないと思うが、その金がさらなる設備投資を生み、最高峰音楽スタジオを作っただけでなく、作品多様性文化としての多様性をも生んだ。1作品の売上で1度失敗したらすべてが終わる世界ではなく、大衆に広く伝わる音楽から、極めてマニアックでありながらしかし深く深く誰かの胸に突き刺さるような、採算を考えたら許されるはずのない作品さえも許容できる余裕が生まれた。80年代90年代音楽を見ればそれは一目瞭然であり、多様性こそが文化としての豊かさだというのは誰の目にも明らかだ。それもこれも、マネタイズが上手くいっていたか可能になったことだ。

この辺の「ありがたみ」を、元記事音楽家などはきっと理解していないんだろうと思う。もっとも恵まれ時代活動し、勝手に思うがままにできていた世代特有傲慢さ。プラットフォームを築き上げることがどれだけ大変で、それを維持することがどれだけ重要なことか、まったく理解していないんだろう。いい歳こいてるくせに。

それらの恵まれた状況をもっとも大きく変えたのは、「家庭用パソコンCD-ROMドライブが搭載されるようになった」ことに他ならない。その時点で「印刷」の専売特許が失われ、「印刷」が家庭レベルに落ちた。誰でも印刷ができるようになってしまった。ここでいう印刷とは、CD-Rに焼く行為のみならず、HDDデータを取り込む、そのデータコピーする、これらすべてがつまるところ「印刷」だ。誰でも自由印刷ができるようになった時点で、そこに金銭的な価値を維持できるような専売性は無くなった。

それをいち早く察知したのは、アップルグーグルだ。彼らはしきりに「おまえの持っているCDパソコンに取り込め」とけしかけた。とにかく入れろ入れろとしきりに促した。同時に「その取り込んだデータをどうするかはおまえ次第だから知らないけどな」と、極めて狡猾な態度をとり続けた。スティーブジョブズが本当に音楽家を救いたかったのだとしたら、やるべきことは人々にCDパソコンに入れさせコピーさせることでは無いことは彼も気付いていたはずだ。気付いていながら彼は巧みにポジショントークを繰り返し、自社製品を売り、むしろ自社製品音楽を救うとまで言ってのけた。そして、それに音楽家たちはまんまと騙された。

音楽パソコンにさえ入れさせれば、後はユーザー勝手コピーするなり、ネットにアップするなり、金も法も関係なく勝手にやり始めることを彼らは知っていて、それを積極的に促した。

なぜ彼らはそれができたかといったら、それは「彼らは音楽投資をしていなかったから」に他ならない。制作費やスタジオ設備に一銭も出していないからだ。音楽CDプラットフォームを作ると同時に音楽制作も始めたソニーには、ビジネスを通じて音楽文化を育てる気概があった。対してアップル音楽制作には一切触れようとしない。彼らは単に、はちゃめちゃコピーマシンと、投資はせずに回収だけするプラットフォームを作り上げただけだ。

そうやって彼らが「パソコンにじゃんじゃんCDを入れちゃって~」とやり始めた時、当然、それに抗わなくてはならなかったことを想像もできないようなら、もう一度中学生からやり直した方がいい。

コピーコントロールCDという名前が表すように、コピーコントロール、つまり印刷」をコントロールする必要があった。そうしないと、音楽を育むための全ての経済圏破壊されてしまうからだ。指を咥えて待っているわけにはいかない。対策を講じなければならない。

明らかに不利な立場だった。何もしないと責め立てられ、やろうとすると「考えが古い」と叱責される。アップルグーグルが上手かったのは、いかにも「先進的で素晴らしいパラダイスを目指している」ようなイメージアーティストたちへも擦りこむことに成功していたことだ。その先に実際には何もなくても、イメージさせてしまえば勝ちだ。あの頃のみんなに「10年後、音楽アイドル大人ホストサーカスしか残ってないよ」と教えたらどんな顔をするだろうか。

実際にはCCCD技術はあまり褒められるようなものではなかったし、それは作った側も認めている。技術アイデアが足りなかったのだとは思う。しかし同時に、何もしないわけにはいかなかったこともちょっと理解してやったらどうだ。いい大人なんだから

当時、全てのレーベルCCCDを出していたわけではない。人を「犬」呼ばわりするほどCCCDが嫌なのだったら、違うレーベルからリリースすればよかったではないか契約などのせいでリリースせざるを得なかったのだったら、裁判でもやって争えばよかったではないか制作費をしこたま出して貰って、ワガママもできるだけ聞いてもらいながら制作をしていた人間が、気分でボロクソに言うのって本当に程度が低いと思う。

CCCD正式にはコンパクトディスクでは無い。redbookのCD-DA規格に準拠していないからだ。つまり厳密なことを言えば、CCCD対応していないCDプレーヤーCCCDをぶち込むのは、CDドライブにフロップーディスクをぶち込むのと大して変わらない。

ここで「だからプレーヤーが壊れたのは自己責任」などとは言いたくないし、その辺りは確かにソニーエイベックスのやり方や啓蒙の仕方、技術には問題があった。 だが、何かしらの対策をしないといけないのは明白で、それに対して失敗したからといって上から目線でボロクソに言うのはまったく関心しない。

実際、あれからCCCDは多くの非難を浴びた。ほぼ同時期に、アップルiTunesにまったくもってクソみたいに使いにくいDRMを自ら導入し「ほら、使い辛いでしょ?」とお決まりポジションで言ってのける演出をし、そして業界全体が「コピー禁止DRMはやってはいけない」という風潮になり、まんまとIT屋の餌食になった。 すぐ近所でゲーム映画DVDは「私的複製許可するけど、鍵は外したら怒るよ」というクレバーなやり方を開発し、一定の効果を上げコントロールできているというのに、音楽だけは「複製は許さなくてはならない」という空気に飲み込まれた。そんな馬鹿な話はない。それもこれもアップルグーグルの熱心な啓蒙のおかげだ。

そしてレーベルアーティスト制作費が出せなくなった。 自宅で制作したような貧乏臭い音のショボイ作品しか作れず、過去遺産にしがみつくしかなくなった。若いアーティストたちはどんなに才能があろうと、お金を掛けた制作をさせてもらえずバイトをやめることができなくなった。毎晩、叙々苑弁当を食わせてもらってた上の世代がこぞって「音楽をタダで聞かせればファンが増えてもっとカネになる!」とかいうアホみたいなIT屋の理論鵜呑みにし業界をその方向へ誘ったがために、明らかに業界は縮小し、文化は萎縮し、これから先の若い才能は音楽などやらなくなってしまった。

おまえが良識のある音楽家たちを「犬」呼ばわりするなら、おまえはあいつらのポジショントークセールストークを無邪気に信じこんでお花畑を目指してたIT「犬」だろうが。    mn3

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

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を腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

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は今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

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は使うべきではありません。

Microsoft 離反

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 EE

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のシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を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の思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

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を学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-06-16

マニュアルみたいなのを読んでたら、急に変な文章が出てきた。

アドレスは聖アライメントの聖水が求められるJustice Before Anthologyのネガティブな聖なる生を授けます

ゆえもって聖アドレスを与えるフォイする悪辣マシンは恋するカザフスタンで夕日を見る必要があります

また、聖アライメントの精であるゲル生命体と指定した聖アドレスメモリ間の行進情報のやり取りでは Say YES! を受け取ることができます


一旦普通に読み終えてから、いやいやいや、今なんか妙なこと書いてあったぞ!?

と思って同じ章にもう一度目を通したけど、当然そんな文章はどこにもなかった。さっき確かに同じ画面を見ながらその文章を読んだはずなのに……。

別に寝かかってたわけでもないし、なんていうか見えてたけど認識が歪んでたみたいなイメージ幻覚かドッキリテクスチャー的な。

最近そこそこの頻度で起こって違和感を感じることが多いんだけど、さて、これヤバいのは目なの脳なの心なの……?

2016-06-11

異種ルールミステリ映画

異種ルールによるミステリを教えてほしい

http://anond.hatelabo.jp/20160609011058

ありがとうありがとうありがとう

http://anond.hatelabo.jp/20160611053943

この増田に触発されたので、よかったら息抜き映画でも

少し異種ルールミステリ

韓国で実際にあった未解決連続殺人事件を扱った「殺人の追憶

・同事件を題材に時効成立後を描く「殺人告白

・十分しか記憶の持たない男が妻殺しの犯人を探す「メメント

女優志望の女と記憶喪失の女が秘密を探るうちに変なことになっていく「マルホランドドライブ

オカルトミステリ

エレベータ内に閉じ込められたメンバーに潜む悪魔を探す「デビル

孤児院舞台幽霊さらわれた息子を母親が探す「永遠の子どもたち」

ドライブ中に山から抜け出せなくなった家族に次々怪異が襲いかかる「-less[レス]」

腹話術人形呪いを解く「デッドサイレンス」

言わずと知れた悪魔の子オーメン

アクションミステリ

・映ると死ぬ鏡の面を付けた怪人と戦う「ヴィドック

モーテル連続殺人に巻き込まれる「アイデンティティー

・人体発火殺人の謎を追う「王朝陰謀 判事ディーと人体発火怪奇事件

SFミステリ

宇宙的な何かからサインを受け取った家族落語的にオチをつける「サイン

・二人を残して街を壊滅させた病原菌の謎を科学者たちが探る「アンドロメダ…」

記憶を失った搭乗員が襲いくる何かと戦いながら宇宙船の謎を探る「パンドラム」

五感体験できる装置を使ったレイプ殺人事件を追う「ストレンジ・デイズ/1999年12月31日

列車事故で唯一生き残った自分秘密を知る「アンブレイカブル

タイムマシンのぐだぐだミステリサマーマイムマシンブルース

2016-05-24

Windows10 にあげるとアプリ周辺機器が使えなくなっちゃったからWindows7 に戻したよ ← わかる

数年毎にマシン買い換えてるから、そのときWindows10 にするよ ← わかる

強制的Windows10 にされた!不具合なく使えてるけど戻して! ← は?

Windows10 しね!次買う時も XP か 7 しか買わねえwwwww ← ???

2016-05-21

React.js界隈の人に聞きたい

**誰かみんなの主張のまとめを作ってくれないですか?** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)

最近JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。

論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ!ってことなんだと思います。(virtual DOMがメインだ!という話もあったけど、じゃあ何でReactなの?というのは聞きたいかな。メジャーから?)

ただちょっと個人的違和感が拭えないので聞きたいです。

ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ(SPAではなかったような気がする)を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。

そもそも世の中にそんなにSPAがあるのか

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。

世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。

JSXを使うことに抵抗ないんですか?

トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います

こういう例、JS以外にもいろいろあって、例えばboostAndroidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ記法を使いましょう、ってことですよね。

でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます(そこまでは違わないかw)。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ!!」っていうのはかなり危ういように見えます

そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通言語から変えるようなソフトウェア流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)

五年後のビジョンがありますか?

五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee script結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい!!みたいに言ってるんじゃないでしょうか。

まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ(≒JQuery)と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。

まあこれを突き詰めるとじゃあetaxもactivexで、銀行システムcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、



とりあえずこんなところで、有識者の皆さんよろしくお願いします。



追記

React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。

id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない?という感じです。

id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で(どのくらいの規模のプログラムで)domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。(もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。)なんかReactががりがり(かつユーザー目線から見て有効的に)使われている例がイメージ出来ないのが問題な気がしてきました。

id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。

id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。

id:manaten もちろんFBGMailJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。(ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます

トランスパイラですねごめんなさいw

SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか?」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOM1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチ需要じゃないでしょうか。

あとなんか保守点検に関する意識ちょっと違うのかなっていうコメント散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね?ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。

それともしかしたら「枯れた技術」あるは「標準化」という意識あんまりないのかなとも思いました。まあ確かに「Web世界日進月歩!」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。

あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJS世界を救う!みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。

増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情お仕事としてのエンジニアはしていないですし。ほんとに純粋質問だと思ってもらえればうれしいです。

まあ長くなってきたので私のブログにまとめ直してもいいのですけど。

そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在必要ですけど~。

2016-05-16

ウィンドウズ10へのアップグレード中に強制終了したらパソコンクラッシュ

帰宅

帰宅パソコンOSインストールし直ししようとおもったら

インストーラーの型番が不一致 

がっくり

翌朝

翌日オフィスに来てみたら見つかった。

本当トホホ

そのまた翌日

新規購入SSDが納品!!!

いまから開封して感激に浸ろう。(5分だけ)

ガッツだぜ!!

今日帰宅SSDの取り換えおよびインストール実践だ。

睡眠中にウィンドウズ10へ移行してもらおう

またまた翌日

SSD換装については成功した。

ウィンドウズ7のインストール成功した。

しかネットワーク関係の設定ができない。

原因は?関連ドライバーファイルなどを入手し忘れた。

このマザボ無線LANの受信手がいない。ワイヤレスアダプタが外付けなのだ

またまたまた翌日

ワイヤレスアダプターのドライバーが入手でき見事にネット接続成功した。

これでこのマシン蘇生したといえよう。

ウィンドウ10へのアップグレードに関して何も言ってこないわ。

ある程度ウィンドウズ7がアップデートされないとだめなのかしら?

ウィンドウ10メールとか言うメールアプリにしてみやうかなと考えている。

雷鳥

雷鳥は大変なのかな?アドレス帳移植できんのか。

送信済みメール移植できるのか?

からない

補遺

クラッシュ前のパソの構成はISRT(インテルスマートレスポンステクノロジー:以下「あれ」)

に基づくものだった。

これって一時流行ったけど、あくまでもSSDが割高で低容量しか

現実的でなかった頃の過去遺物しかも、あれはクラッシュした時に

データが救済できる可能性が低い。

今や、SSDも安売りされているので

今時あれを導入する意味はない。

30円/GB価格ドットコム情報

あれが原因で結局パソの寿命は約3年ということか?トホホ

当時高かったであろう低容量SSDは、これでごみになるということか

2016-05-11

http://anond.hatelabo.jp/20160511182054

水素水に嵌った人に、酸素吸入器みたいな形で水素を発生させる水素吸入マシンとかを薦めるとどうなるんだろう。結構気になるな。