  |
はてなキーワード: テンプレートとは
コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある（特徴のない言語は廃れていく）。
あまり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。
なお、取り上げるのはある程度広く使われている言語に限りたいと思う。
| 言語名 | 概要 |
|---|---|
| C言語 | 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグ出やすい |
| C++ | マニアック言語、高速、習得大変 |
| Java | サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる |
| C# | 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語 |
| Perl | 広く使われていたが今は若干時代遅れのスプリクト言語。汚い |
| Python | Perlにかわって主流になりつつあるスクリプト言語。綺麗 |
| PHP | Web開発にフォーカスされたスクリプト言語。一世を風靡した。 |
| Ruby | とても綺麗なスクリプト言語 |
| JavaScript | ブラウザで実行出来る唯一の言語。言語自体はいまいちだが、ブラウザの事情で需要あり |
| Go | サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語 |
メモリに直接アクセスして書き換えるといったコンピュータの機械語に近い言語構文を持つため、高速な処理が可能な言語。
コンパイラの歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語。
一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディングの効率が良くなく、多種多様のバグを生みやすい側面も持つ。
ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。
C言語にオブジェクト指向を導入した言語。C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。
C言語の速度を維持したままオブジェクト指向やテンプレートなどの効率的な記述を可能にしようとした意気は真っ当だったのだが、
当時最先端だった色々な技術や思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。
「C++を理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。
速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。
サーバサイドで安全にコードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。
当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリの解放忘れというバグを生まず、
サーバサイドなどで何千時間と動作するソフトウェアに適した言語として受け入れられた。
必然的にエンタープライズ用途で利用されることが多く、各種ツールなども豊富。人海戦術がしやすい言語という側面も出てきた。
一方でブラウザにHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。
ガラケーのアプリや（ちょっと違うが）Androidなど、クライアントサイドでも使われることがある。
プログラミング言語で最初にJavaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。
クライアントサイドで安全にコードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。
元々はWindowsのクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。
マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。
Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。
自作のゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。
ほぼ全てのLinux系ディストリビューションに含まれており、ツールや様々な用途で使われていた。
上に紹介したC、C++、Java、C#のようなコンパイル言語とは違い、（少し語弊はあるが）1行ずつ実行してエラーがあれば止まるスクリプト言語である。
ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインのコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である。
20年近く前にWebでCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。
しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存のコードもどんどん別の言語に置き換えられていることが多い。
日本の大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。
後発のスプリクト言語。こちらもほぼ全てのLinux系ディストリビューションに含まれており、それゆえに広く使われている。
インデントまで言語仕様で規定することで、誰が書いても読みやすいコードになるように考えられている言語である。
Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。
ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。
最近だとマシンラーニング系のライブラリでPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。
Web開発に特化したスクリプト言語。CGIの代わりに使われ始め、一世を風靡した。
以前CGIでWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。
またphp.netの豊富なドキュメント＆スニペットのおかげもあり、開発初期の効率が大変に良い言語である。
残念なことに、言語やAPIの設計がいけていない点が多く、一部の人からは蛇蝎の如く嫌われている。
今でも根強い人気があり、海外でも小規模プロジェクトの最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。
Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。
なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。
綺麗なスクリプト言語。日本発で世界的に普及している数少ないIT技術の一つ。
言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWeb用フレームワークの登場で、Webアプリでの採用例も一気に増えている。
基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである。
スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語。
サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。
一方で、なぜかRubyが採用するWeb側のフレームワーク（具体的にはprototype.jsやCoffeeScript）はいつもクソなので、そちらは深入りしないのが吉。
ブラウザで動くスプリクト言語。ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語。
言語としてはプロトタイプベースのオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。
言語仕様がイマイチで、大変バグを生みやすい言語であり、また関数のスタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが
ブラウザで動く言語が現在これしかないので、大きなシェアを持っている。
一部の物好きがサーバサイドでこの言語を使おうと（主にnode.jsで）四苦八苦している（とはいえ、1つの言語でWebとサーバが完結するのは大きなメリットだ）。
ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。
まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。
Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である。
最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsでサーバサイドもできるしで、意外とオススメだったりする。
C、C++やJavaと同じでコンパイル言語。サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語。
その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。
それ以外の目的ではあまりこの言語を採用するメリットはないが、ニッチな用途をピンポイントで抑えており、これから広く利用されることも期待される。
コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである。
繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。
ここに挙げた言語は何らかの特徴があり、何らかの用途で必要なので生き残っている。
その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。
恋は白いブランコ
白いは余計な情報ですよね？
こういうの詩的っていうんですか？
って、ううきまさみが愚痴ってたけど、
レイバーを空飛ばすのも、十分詩的だと思うけどなあ。
あ、あれ？ 犬だ！ 犬がいるぞ！
そばに七味を山ほど入れるぞ！ キモい！
サヨナラ
って言うぞ！ キモい！
映画館でゴティックメードがぶつかり合う、鉄と鉄がぶつかり合う音を収録するために二年間かけたアニメ監督ばんどまんがいるぞ！
おわかれだヨ
達者でな
お前といられて
すんげえ幸せだったぜ
繁代……
って言うぞ！ キモい！
あ、あれ？ ここに10万人の宮崎勤がいます！ って言ってないことを証明した漫画家がいるぞ！
この人のことは本当に好きなので揶揄いません。
それじゃあ、みんなも、80年代、90年代のアニメや漫画の関係者をこのテンプレートで弄ってね！
長谷川裕一がハゲに「お赤飯がまだの女性にそういうことするのはよくないですよ」って説教されたエピソードとかを盛り込むのがコツだよ！！！！！
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー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を学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
高校の頃に某作品の二次創作と出会い、すっかり腐り落ちてから早15年。
私の場合は腐ってからの年月は、ほぼ同人活動の年月とイコールになる。
15年間オン・オフともに同人活動を続けていると、いろんな人と知り合う機会があった。
いい人もいれば(こちらが大半だけども)記憶から消し去りたいくらい嫌な人もいた。
で、学んだ。
同人活動やってて、過去ジャンルのことを悪く言う人は十中八九、当人が難あり物件だということを。
15年間の間に知り合って別れた人に、この手のタイプが４人いた。
悪く言う内容はテンプレートでもあるのかってくらい同じで、
「いじめにあった」
「嫌がらせを受けた」
「スペースで罵倒された」
という、「えっ、そんな酷いことする人ばかりがいるジャンルなんてあるの？」と驚くような内容。
大して親しくないのに、むしろ知り合ったばかりなのに、いきなり「実は私ね～」と自分から語り始めたり
でも、その４人は皆、それそれ金銭トラブルだの真っ黒なパクリだのと
要するに後ろ暗いところがあるから、予防線の意味で過去ジャンルのことを悪く言うんだろうなと思う。
しかしネット社会の今、証拠ありの悪行はネット上に残るので、予防線張っても無駄だと思うんだけども。
・同人活動歴そこそこ長そうなのに、過去ジャンルの友達が全くいない人
・聞いてもないのに過去ジャンルの悪口をべらべら喋りはじめる人
(・上二つがそろってる場合、ジャンル移動時にPN変えてる人)
結局の所手書きが無難で高学歴や資格持ちはPCが無難って事でいいんだろ？
俺は文系院卒だから手書きなんだけど、字は綺麗な方だし希望職種が事務系だから良いよな。
逆にどうしたらPCか手書きかで分かれなくて済むか教えてくれ。
俺は好きで手書きだからパソコンで作成する意義が分からないんだ。
勿論職歴書(自己紹介文)はパソコンなんで両立してやってるって意味じゃパソコンも使ってる。
履歴書だけ手書きっていうのも今となってはなんだか不思議な感覚だと思ってる。
どうなんだろう。
手書きは今でも主流なんだろうか。
今の学生はスマホが主流だからパソコンも使えない人もいるらしい。
ましてや手書きで卒論なんてもう書いてる人探すのが困難だろうから
履歴書ももしかしたらJIS規格の手書き履歴書じゃなくてパソコンのテンプレート探して
それにスマホ打ちしてるのかもしれないな。
難しい。
フィードバックのない生産活動など、ただの消費で徒労と同じだ。
宝くじは徒労を、射幸性によって麻酔させることで消費に向かせる。あれは麻薬の類だ。
わらえないのが、優れた詐欺組織のオフィスとうまく回っている普通のオフィスは良く似ていて、
その日の仕事で得た課題点と成果を分析し、翌日以降の業務を改善していくシステムができているという事だ。
大きな企業や安定した大人数で動く業務は、ノルマさえこなせば仕事が回るから
問題点は改善されず、放置され、惰性のまま進み何か大きな不祥事やトラブルが起こるまで続いていく。
彼女は幼いころから金持ちからお金を騙し取る事を社会正義だと教わり、
飢えは不当に不労所得を持つ金持ちが悪いと教わり続けた。学校にも満足に通えず、新聞配達で糊口を凌ぐ日々。
義務教育を終えると、ふとしたきっかけでオレオレ詐欺のオフィスに就職することになった。
中卒で未成年の労働者を雇ってくれる場所なんて、限られた場所しかなかった。
オレオレ詐欺のオフィスは、トイレの壁に社長自身で考えた標語や過去の偉人や社長の座右の銘が貼り付けられてて、
どこにでもあるテンプレートのようなぎらついたベンチャーのオフィスだったそうだ。
ねずみ小僧を教科書に、彼女は上司の言われたとおりにオレオレ詐欺をこなしていく。
あの頃はオレオレ詐欺が出始めのころでオレオレバブルというべき入れ食い状態だったのだ。
給料は出来高制で、詐欺の金額の何パーセントかが彼女のフトコロに入った。
ある程度組織化されたところだと、ノルマ制で固定給+インセンティブみたいな会社もあったらしい。
アイディアを練った詐欺の成功による報酬という甘露が、彼女の思想を容（かたち）作り。
詐欺の失敗による飢えという鞭が、富裕層への憎しみとなり彼女の考えを堅めていく。
失敗が先か、成功が後か。成功が先か失敗が後か、どちらが最初だったかなんてわからない程に
成功と失敗を繰り返し、彼女はオレオレ詐欺の構成員になっていった。
一般的なコールセンター同様に離職率も高く、今ほど専業化されておらず、
騙す老人や親に田舎においてきた家族を思い出し辞めるような善良な小市民も少なくなかった。
しかし、彼女は愛するべき家族はいなかったからして、騙す相手にかける情など生まれはしなかった。
基本詐欺師なんてのは、みすぼらしい自分をエリートに飾りたい人間がやるか、
頭が回るやつだが、学歴や前科の都合で正規の頭脳労働ができなくてやるものだと相場が決まっている。
二人で一つのツーストロークサイクルする行為にふけりつつ私はそんな相手の人生のことを考えた。
性行為というのが相手を思いやる快楽行為であるのであれば、私は相手から教えてもらった記憶を再構成して
考えてやることにしている。それは虚実混じてて、あるいは誇張があるかもしれない。
思い出とは苦しさでゆがむし、辛い経験や誇らしい経験だけが強調されていく。
そういうものから最小二乗法のようにその中に隠された法則性というか事実を想像するのが好きなのだ。
彼女は元詐欺師だというから、すべてがウソかもしれない。そもそも元詐欺師という話すらウソかもしれない。
そうなると元の話すら信用できない。もしかすると彼女は作家なのかもしれない。彼女のほんとうは何一つわからない。
つかみかかれば折れそうな細い鎖骨。手に収まる触りやすい胸、白い肌、整った目鼻、狐みたいに切れ長で意志の強そうな目。
人の顔は無表情でないと本当に醜い。整った顔立ちの彼女ですらこんな顔になるのかと、新しい発見が出来る。
美人のAV女優だって行為のときの顔はみんな似たような顔をしているようなものだ。
潔癖な親友は人が恋人にだけ見せるあのゆがんだ顔が許せないくらい嫌いなのだという。
人形のように美しい顔は人形のようにあるべきだという。彼はマグロが大好きだった。
相手になったつもりで考えれば考えるほど、自分がわからなくなってきた。それでも体は熱く、心臓は激しく脈打っている。
快楽が強く顔がゆがむくらい痛い。寒い日に肌が突っ張って古傷が痛むのに似ている。
彼女は何を考えているのだろうか。
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
ユーザー体験がどうかはまあ意見が別れるでしょうからおいておくとして、ずっと楽に開発というのがよくわからないです。普通になんでもいいですけど、ウェブ側のフレームワークでちゃんとしたものを使っていれば別になんでもないことだと思うんですが、具体的にどういう状況を考えられていますか？
プログラムはユーザーサイドだけでは完結しなくて、入力チェックとかいろいろは絶対にやらないといけないですよね。ということで同じロジックを複数書く場面が出てくることが多いと思います。そういう手間も含めたうえで開発が楽になるというのはちょっとよくわからないです。
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？
ちょっとここ書き方分かりづらかったかもですが、「ES6で書く以上はES6を使えばいいじゃん」「変な独自拡張を入れてまでJSを使い続ける理由がわからん」という２つの疑問を同時に書いたつもりです。
将来長持ちする気がしています。
PHPやJSP,ASPが通ってきた道に見えてなりません（まあASPはまだ現役ですか。）。
正直その他のアプリケーション(サーバーサイドや、例えばAndroid/iOS開発)でこのような書き方はまずしないので、なぜわざわざ同一ファイルに書きたがるのかがわかりません。（ロードのコストを嫌がっているとかですかね？）
テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
ええと、テンプレートストリングではなくて、mustacheみたいに十分枯れているテンプレートエンジンでもいいですが、必要かどうかは別として確かに機能の豊富さはどうかはちょっとわかりません。
速度に関しては、実際みんな早いと言っていますがこの手の速度神話はJSにかぎらず昔からちゃんと前提と状況を考えなくてはいけなくて、（例えばJavaは重い！とか関数呼び出しはオーバーヘッド！とか仮想関数は使うな！とか）例えばさっとぐぐるとこんなものが出てきました。
http://www.stefankrause.net/wp/?p=283
まあよくわかりませんが、結局あんまいじらないのが一番良いという当たり障りない結論になってしまいませんか？（あと原理的に生のDOMを操作するのよりも早くなりようがない気がするんですがどうなんですかね？？）
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
ごめんなさい、Reactまわりのエコシステム全体も含めた時を意味したかったです。leftpad騒動とかもあったように、なんかまだちょっと不安がある感じがします。偏見でしょうかね。。
React.js界隈の人に聞きたい
http://anond.hatelabo.jp/20160521163144
最近某所で、React使うとjQueryは不要だ的なタイトルの記事を書いちゃた気がするので一応反応しときます。長文ごめんね。
えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQueryは不要」「jQueryは要らないこともある」と長く書いた方が正確です（本文ではちゃんとReactが万能ではない説明をしてる）。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。
そもそも世の中にそんなにSPAがあるのか
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAだから使いづらい」という主張はよく分かりません。GitHubやTwitterサイトがSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは（Reactではないけど）SPAで、ブラウザでMarkdownをレンダリングしています（ http://webpack.github.io/docs/ )。サーバサイドで動くスクリプトもタスクもゼロ。個人的にはこういう使い方で十分嬉しいです。
何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります。自分中の閾値としてはJSコードが数百行超えるならもうReact使う。
JSXを使うことに抵抗ないんですか？
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？ 正直その主張を聞いたのは初めてです。歴史的にJSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。
「JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装が一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしています。JSXは「関数呼び出しのシンタックスシュガーをJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います。仮想DOMの思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています。
とはいえ所詮JSXはシンタックスシュガーなので、使いたくないなら使わず、本来の関数スタイルで仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。
それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルのコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々と成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。
Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています（個人の感想です）。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2～3年待てばよいと思います。
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
元増田です。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
手間がかかりません？さらにもともとほぼサーバー側だけで済んでいたものを分けることでCSRFやSQLiなどの変なバグを仕込む可能性だってありますよね。これに見合うメリットが見えないのですがいかがでしょうか。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。シンタックスハイライトとかインデントも効かないじゃないですか。そういう点ではAngularJSが一番気持ちいいですが。。
まあそれはそれとして、なるほど、JSXは別にどうでもいい、というのはわかりました。まぁそれならわからんでもないです。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
ここわかんないですね。活発なメンテがそんなに重要なのかな？ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか？
http://anond.hatelabo.jp/20160521163144
内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。
jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査兼下地作りの段階だけど
正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。
でもjQueryを捨て去れるかというとそれも無理だと思ってる。
その辺のことを適当に書いてみる。
社内サポート的なことやってて、サポートのテンプレート対応を省力化するために
Webでツール作って人が対応するコストを減らすために使ってる。
jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。
最大にして一番の理由がこれ。
そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMツリーを脳内でくみ上げるのに疲れた。
500行もいかないようなショボいコードでも脳内DOMツリーと格闘するのしんどい。
DOMツリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの？
そんなスーパーハカー揃いなの？信じられないんだけど。
オリジナルのbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど
React-Bootstrapはマジで楽だし、スッと理解できる。マジ最高。
Bootstrapってこっちを本筋にすべきじゃね？と割とマジで思ってる。
まだ触って3日も経ってないけど。
これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど
一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。
ベースのHTMLにはベースのdiv一個載せとくだけで後は全部js。
レイアウトを大元のコンポーネントでReact-Bootstrapで組んで、あとは各コンポーネントを
個別に作っていけばいい。
HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは
少なくとも俺にとっては一番楽。
やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。
だからjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから
管理が楽。
極力なくす方向で行くつもりだけど、今はまだ両方使ってる。
あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。
気持ち悪くて仕方ない。いまだに大嫌い。
どんなに気持ち悪くても、結果が伴う以上使う。
5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。
今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。
それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。
将来まだこの仕事やってて、もっと有用なツールがあればそっち使う。
俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、
自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。
まずReactの特徴は、「状態データから変換してビューを生成する」スタイルに統一されることにある。
これはjQueryをはじめとするDOM操作モデルでの、「初期状態ビューの作成」と「(イベントに伴う)状態変化からの部分ビュー変更」で構成するスタイルから脱却され、たとえば部分処理の積み重ねから想定外の状態が生まれることを防ぐ。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
Reactのモデルは関数型プログラミングのモデルそのものであって、そういう観点ではすでに何年も続いたものであり、React自体は消えたとしてもその手法は長く続くことになる。
**誰かみんなの主張のまとめを作ってくれないですか？** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)
最近、JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。
論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ！ってことなんだと思います。(virtual DOMがメインだ！という話もあったけど、じゃあ何でReactなの？というのは聞きたいかな。メジャーだから？)
ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ（SPAではなかったような気がする）を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。
世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね！」っていうことなんだと思います。
こういう例、JS以外にもいろいろあって、例えばboost、Androidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ・記法を使いましょう、ってことですよね。
でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます（そこまでは違わないかｗ）。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ！！」っていうのはかなり危ういように見えます。
そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonやRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通の言語から変えるようなソフトウェアが流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。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 もちろんFBやGMailをJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。（ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます）
SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか？」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOMを1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチな需要じゃないでしょうか。
あとなんか保守点検に関する意識がちょっと違うのかなっていうコメントが散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね？ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらにもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。
それともしかしたら「枯れた技術」あるは「標準化」という意識があんまりないのかなとも思いました。まあ確かに「Webの世界は日進月歩！」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。
あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJSが世界を救う！みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。
増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情でお仕事としてのエンジニアはしていないですし。ほんとに純粋な質問だと思ってもらえればうれしいです。
まあ長くなってきたので私のブログにまとめ直してもいいのですけど。
そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLでモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在は必要ですけど～。
自分語りをします。特に何かを伝えたい、というわけではありません。得になることも益もありません。 こういう腐女子もいるんだ、という理解をしてくれたらいいなあ、と思いながら書きました。
私は元々母親が腐女子で、同性愛の含む(もしくはそれに似たものを感じ取れる)コンテンツを小学校の頃から読んでいました。 念のため言いますけれどこれは母親が私に強制したわけではありません。手の取れる位置にそれがあって、漫画で絵が綺麗だったから読んだだけです。今でもたまに読み返します。紫堂恭子はとてもいいぞ。
BLや腐女子、と言ったワードを知覚したのは小学校６年かそこらだと思います。 でもその時は「わたしは腐女子ではなく、ただの漫画オタクだ」と思っていました。 パタリロ好きな人間全員腐女子か？という問いかけに対する答えと似たようなものです。 BLが好きというわけではなく、あくまでその作品が好きだったから読んでいた、それだけです。
中学にあがり、深夜アニメなるものを見始め、そのうちとあるジャンルにどハマりしました。 web漫画で、好きな声優がデフォルメされたイケメンの声をやっていて、面白いギャグで、好きなキャラクターができた。 pixivで調べるうちに、その主人公二人のBLが目に入った。 そしてちょうど同じタイミングでTwitterをはじめ、そのジャンルの人をフォローするうちに、そっちの世界に入りました。
わたしの本命ｃｐはその二人にはならず、サブキャラ二人を推していました。 しかし周りはどんどん主人公二人に群がっていきました。
作者がTwitterでその学パロやコスプレを「関係ない奴、非公式」と言いつつもアップしました。 腐女子はそれに便乗したものを描きました。 いつの間にかpixiv百科にそのキャラの派生のページが作られ、設定なんてひとつもないのにいつの間にかそのキャラの設定が浸透していきました。わたしも最初は「面白いぜヤッフー」と思っていました。
ふと、眺めて見ると、それは異常でした。
その時に、そのジャンルに対する熱意というものが失われていったように思います。
わたしはそのままジャンルを離れました。 そして、この時にきっとわたしの地雷は作られていきました。
そのあり方は賛否両論かもしれませんが、イベントに参加しているわけでも、同人紙を買っているわけでもないし誰にも迷惑かけてないからほっといてほしい、というのが本音です。
わたしはジャンルにハマると１日中サーチをかけ続け、思ったことを語りまくります。 この期間はおよそ1ヶ月ほど。その間は他のジャンルの話はあんまりしなくなります。 語り尽して話すことがなくなると、他のジャンルの話や最新話の話やとにかくいろんなことを話します。 次にどハマりするものが出てくるまで。
話すことがなくなったから話さないだけであって、けっしてそのジャンルが嫌いになったというわけではありませんと思います。最初の件を除くならば。
わたしは弱小お絵描き人間(ブクマ貰えるとしても多くても10人、とかほんとにそういうレベルです)なので、「イナゴだよろずだ」などといちゃもん(になるんですかね？)や嫌味を言われたことはないのですが、そう思われても仕方ないな、という気持ちではあります。
さっきちょろっとだけ触れた、地雷の話をします。 これ滅茶苦茶賛否両論というか否定が多そうなので先に言いますけれど、わたしが嫌いなだけであってその考え方や在り方を否定しているというわけではないので悪しからず。
わたしは、友愛や家族愛や主従愛を恋愛に置き換えられるのが果てしまく嫌いです。腐女子の癖に何言ってんだ、と思う人もいると思うのですが。
とある結構昔にハマったジャンルでは、孤児の主人公とその主人公を拾ったお金待ちのお嬢様がいました。 その二人は後々、女神とそのお付きの戦士になるのですが、まあこの二人のCPが地雷でした。 しかし、その二人が一緒にいることが嫌いというわけではないのです。
この二人は人としての主従関係と、神と人間という主従関係の二つの関係が複雑に絡んでいる二人でした。 その二人の、前世からの因縁を、恋愛、と言われたくなかった。 それはあまりにも雑すぎる、と思った。それだけです。
最近のでぃずにーの映画(わたしは見てません)もそういう「この二人は恋愛じゃないから云々」みたいな話をTwitterで見かけましたが、あれと言ってることは同じです。 原作の複雑な関係を、二次創作のテンプレートに当てはめるのはあまりにも原作に対して失礼ではないのか、それは本当に原作の二次創作と言ってもいいのか。
これはNLを例に取りましたが、BLでも同じです。 公式で最高の友情をやっている二人や、美しい兄弟愛を見せる二人が同じようなセリフを言って、同じようなシチュエーションで、同じようにエロをする。 それはわたしの求めるBLではないな、と思うと自然とメジャージャンル全般が地雷になりました。
お前どんだけ地雷あるんだよ、と言われそうですがそれでも結構ちゃんとやっていけてるし、Twitterとかに流れないようにここで語っているので許してください。
わざと隙間を作る作品もありますが、大体のものは「他人が介入する隙間のない人間関係」を物語で提示しています。
そこに、都合のいい女(もしくは男)を介入させる。 それがわたしには無理だった、という話です。
原作ですでにお相手のいるキャラクターだとなおさら不倫とか寝取られみたいに感じてしまって見ることができません。夢を見るつもりで夢を見たことはないんですけど。
最近、ソシャゲをよくするようになりました。 その時に性格の提示されていない主人公が受けに回るのがあまりにもダメで、しかも何故かそれが流行りに流行っていて(そのゲームはむしろ男向けなのに)、公式では「相棒」みたいだったキャラと主人公がTwitterやpixivではカップルのようにいちゃこらしている。 世界の危機なのに。
わたしの心はとても狭いです。 こんな風に王様の耳はロバの耳って叫ぶようにどこかで主張しないとイライラが収まらないほどに。
別に「わたしが不快だからどうにかして！」っていう話ではありません。 好きな人は好きなようにすればいいし、嫌いな人は嫌いなままでありつづける。 それでいいと思います。 つーか好き嫌いの押し付けほんとよくない。 そういう人間とは手を切るべき。
最初に言ったように、「世界のどこかには貴女の好きなものを食べられない人間もいるし、貴女が必要ないからと捨てているものを大事に抱えている人もいる」ということをわかってほしい、わからなくてもいいけど認識はしといてほしい。
追記として、最近、軽い男性恐怖ができたのですが、その後BL読んでたらエロ展開が見れなかった。 R展開のもの全てがおぞましく見えました。時が過ぎれば過ぎていくほど地雷が増えていく自分がこわい。いやまじで。 ホモ見れなくなったらどうするんだよ。
という話を友人にしたところ、「RのないBLなんてBLって呼べなくない？」みたいなことを言われたのでもう彼女とBLの話もソシャゲの話もしない。
解釈違いは相容れない、そう思った五月の昼下がり。
2000年代で見ておいた方が良い神アニメ、良作アニメを３００本程まとめて感想と紹介をする
こういうアフィ丸出しのブログに文句つけても、アクセスが増加してそのブロガーが喜ぶだけだから意味が無い。むしろ、くだらないゴミみたいなコンテンツを作るのに加担しているとさえ言える。いや、「アカギは麻雀わかんなくても楽しめます！」なんて言われた日には、そりゃ文句を付けたくなるのはわかるんだけど、彼らアフィリエイターにとって得でしかない。くだらない記事に文句ブクマつける行為は、意外にも彼らにとってのみ得である。
ブクマをつけて、ホットエントリー載って、（良エントリーと）勘違いしたライトユーザーがまたブクマをつける。ホッテントリーに載ってしまえば、アフィリエイターは記事の新たな戦略を見つけてしまい、「◯◯選！」「見ておくべき映画◯◯！」「◯◯はこれだけ見とけばオッケー」のようなコスパ再重視ゴミエントリーが量産されてきたのと同じように、また違ったテンプレートが出来上がることは想像に難くない。それとは別に互助会ブックマークユーザーズによって、不自然に伸びてしまうエントリーもあるから一概には言えないが、どちらにせよ、ブクマユーザーがくだらないコンテンツづくりに加担している現状は否めないのではないだろうか。
自分も文句ブコメをつけていたが、ある日、これは意味のない行為、むしろ相手に得でしかない行為だと分かってしまった時から、文句ブクマはしなくなった。嫌儲思想というより、くだらないコンテンツに加担、共犯しているのが嫌になった。「くだらないコンテンツを生むな」とブクマで批判しておきながら、一方ではそのブクマによってアクセスを増加させてしまい、味をしめたアフィリエイターはその類型記事を作ってしまう。結果的に、ブクマユーザーはくだらないコンテンツを生み出す片棒になってしまっている。
そう思った。以上です。
太陽の石を読んだ。オーリエラントの魔術師シリーズは、魔術師と魔法に特化した重厚なファンタジーだから読み応えがある。世界観にどっぷり浸かると面白いと思う。
ただ、個人的に今作は前二作に比べて盛り上がりに欠けた気がした。謎を解いたり、強大な敵の罠に嵌ったりすることがなかったからかもしれない。歌うクジラでも思ったけど、ロードムービー的な物語はあんまり好みじゃないのかもしれない。失敗や成功を糧に登場人物が変化するわけじゃなく、終始道なりに展開するからなのかな。あんまり起伏が感じられなくて残念だった。でも、朽ちた砦で冬ごもりする部分は面白かった。
イザーカト兄弟は揃いもそろって人間味あふれる問題児ばかりで、それが理由で悲惨な兄弟喧嘩に発展したのかと考えると悲しくなった。もちろん魔術師だから性根のところがねじ曲がってはいたんだけど。暴君とかしてしまうナハティの変遷なんて、テンプレートといえばテンプレートなんだけど、どこかで違う道に進めたんじゃないかな。力が強すぎたりプライドが高すぎたりするのってほんと不幸だと思った。
帯にも解説にもあるけど、最終決戦へ向けての段階から、予想を裏切るが決して嫌いを裏切らないエンディングが待っていたので、ちょっぴり切なかったけど満足できた。
この地域の人々がこれからどんな歴史を育み、後世の社会を形成していくのか。シリーズ第四弾が出たら追い続けたいなって思いました。
教えてあげれば？
ちなみにaspのテンプレートがそのまま出てるだけで、sqlではない。
気が付いたら何してたかもわからないくらい何の価値もなくただただ落ち込んだ気分で月曜日を迎えていたんです。
何の話かって、はてな界のニュー・オーダーのせいでブルー・マンデーだったっていう話なんですよ。
つまらぬものを切っても切れなかったんですよ。むしろ自分がつまらぬものになってしまったんですよ。わかってくださいよ。
わたくし、べつに村民とかそういう者ではございませんが、でもこのはてなっていう会社のサービスが大好きで気に入ってただ淡々と使っていたんです。
それでですね、先週ほら、また盛り上がってたじゃないですか……例の。あまりわたくしのようなニワカが口にするのは恐ろしい恐ろしいなのでその名には触れませんが。
いや、ここ1年半くらいなんだか居心地が悪いなーとはずっと思っていたのですけども、最近特定層の人たちの記事が大量にホッテントリに上がってくるじゃないですか。
それがわたくし個人としては正直うざくて気持ち悪くて気持ち悪くて気持ち悪くて仕方なかったんですけども、でもサービスをどう使うかはある程度自由ですし、運営の視点で見てもこの先生きのこるためにはある程度アメーバ化していくのもやむなしじゃないかとも思うわけなので、一、フアンとしてはひっそりと身を引くくらいしかできないのかしら、とも思っていたのですよ。
ところがですね、最近この層の方々から発射された流れ弾が外の別のSNSでも着弾することとかも出てきまして、こりゃもうたまんないなと感じまして。
そんなときでした。Androidのアプリでもユーザ非表示設定ができるようになったって言うじゃないですか。
今まで、宗教上の理由によりユーザ非表示って使ったことが無かったんですよ。それに、本当はユーザ非表示じゃなくてNGサイト登録のほうがありがたいのですけれども、これははてな社のビッジネースのことを考えたら望み薄いのかもと思いまして、何もしないよりは、とポチポチ非表示を登録し始めてみたんですよ。ワナビーなブコメや明らかなスパムが目に入らないだけでも精神衛生上よろしいかと思いまして。ええ、GOJOいアカウントを思いつく限り片っ端から。
そうしたらですね、もうこれはまさにGOJOの奇妙な冒険が始まってしまったわけなんですよ。
最初はね、20人くらい登録すれば良いのだと簡単に考えていたんです。
それで、金曜日の深夜に上がっていたGOJOい記事から順に見ていきまして、非表示に登録していったんです。
そうしたらですね、これが結構手間暇が掛かるものなのですね。そして人間くだらないもので、だんだん躍起にやってしまうんですね。あれよあれよと気がついたら、もう朝方。この瞬間、自分はスタンド使いどころか波紋でやられてしまう吸血鬼程度に成り下がってしまっているわけですね。ミイラ取りがミイラってやつですね。
疲れたし、目は痛いし予定は潰れるしで昼まで寝て起きて、だるくて外出もできずスプラトゥーンしてたら夜になってしまってですね。
そして止せばいいのに、夜またも奇妙な冒険に出てしまったんですね。ユーザ非表示をいくらやったって弓と矢にはなり得ないんですけどね。
わたくし、甘く見ていたんですよ。敵は20人じゃなかった。確認して、実際にコメントを見て、場合によってはわざわざアフィ記事踏んで確認して非表示へ……
なんということだ。この街はもう自分には住めない街になってしまったのかもしれない。頭の中でバイオハザードをプレイしている光景が浮かんでは消えるわけですよ。まさに、ゾンビ取りがゾンビっていうわけですね。
一日体も動かさずスタンドバトル（クソゲー）とスプラトゥーンしかやっていませんので真夜中に目が覚めてしまい、またこの絶望的なポチポチ登録を始めてしまい、気がついたら日曜日の昼。ループ2周目が始まって、だるくて外出もできずスプラトゥーンしてたら夜になってしまってですね。
この時点でもう、わたくしは敗北してるわけです、この世界から。
なんということでしょう。今朝方未明、また夜中に目が覚めてしまい、眠れなくてまたスマホを開いて青いアイコンをタップ。もう病気ですね。もういい休め！って自分の中でもざわざわしてるわけなんですけど、止まらないんですよ。
そう、もうこれやっててもきりが無い感じなんですよね。こうなってくると、もはや自分のほうがマイノリティでメンヘルになってしまっている気がしてくるのですね（いや実際そうなんですけども）。見ていくと確かに、例のGOJOい一団は数十人なのですが、そこにブログでお小遣い稼ぎをしたいアフィいフォロワーがすでにその何倍かついて絡んでいるんですよね。そこに、キャンピングカー大学生経由の若者の一団とかも絡み合ってきていて、もう読み解いていくだけで深淵の泥沼に嵌ってしまうんですよね。
しかも、読みたくないものをわざわざ徹底的に読み込んで調べて学習しているわけじゃないですか。わたくしは馬鹿なんですか。そうですね。
もう、精神はズタボロですよ。心にダメージを負い、睡眠不足になり、情緒不安定になりスプラトゥーンは負けまくってB+まで落ちてしまったじゃないですか。
馬鹿ですね。あるいは病気だったのかもしれませんね。頭を冷やして、もう辞めよう、と思いましたね。
というわけでもう今さらではありますが、おかげでブコメ欄はだいぶスッキリしました。相変わらず興味の無いホッテントリはたくさんぷかぷかと漂っていますが、そういうエントリはお気に入りのアイコンがひとつも付かず、コメント欄も大概謎の空欄になったので、判別しやくなって多少は快適であります。
こういうことを書いているとよく、「古参が『昔は良かった』とボヤいてるだけ」などとアフィい方が仲間内でやり取りしているのが見たくもないのに目に付いては、「違う、そうじゃない」と心の中でツッコミを入れていたのです。そうじゃないんですよ、少なくともわたくしの中では。わたくしはただ、ソーシャル・ブックマークサービスを個人用ブックマック＋情報収集＆シェアツールとして楽しく利用させていただいていただけなのです。そのことを『昔は良かったとぼやく老害』と言われてしまってはもう敵わないなあと思うわけなのですが、逆にこの方々こそこれはこれでやっぱり新・ムラ社会なのかもしれませんね。
ちなみにですけど、最近よくホッテントリに上がる新しめのブログが十把一絡げにイカンとか言ってるわけじゃないですよ。個人の趣味もありますが、公平に見て中にはこの人はやいのやいの言われてもセーフだろうと思うブログもちらほらあります。自分の体験や自分の好きなものを自分の言葉で日記にしたためている感じがするブログは好きなんですよ。
同世代ブログ間の交流とかはあるかもしれませんが、そういうブログは記事の作りもアフィい一団とは一線を画して実際面白い記事もあり、よく読んでたりします。
やっぱりこりゃキツイなあと感じるのは、特定の一団とそのフォロワーなんですよね、今のところは、ですが。キャズム超えなんていう言葉もありますし、かつて有吉が「ブレイクするっていうのは～」なんて毒舌を吐いていたことも思い出すのですが、特定の一団がマジョリティになったとき、ここも腐海、もしくはアメーバに沈むのでしょう。それが良いことなのかどうか、一、ユーザにはよくわかりませんが、「スパムで無い限りは」ブログは自由です。はてな社にとっては好ましいことなのかもしれませんし、「スパムで無い限りは」どうこう言っても個人ユーザの利用方法を責められるものではないことは理解しております。ただただ、一、フアンとしては、「衆愚化してつまらなくなって廃れていく」というインターネッツのテンプレートをなぞることが無いことを願い応援しております。
というわけで、自分のこの週末を振り返って一行にまとめますと、タイトルのとおりであります。
皮肉なことに、この話題と主要プレーヤーについてめちゃくちゃ詳しくなってしまいました。虚しい。
もう自分が疲れてるな、視野狭窄になっているなと感じることができたので、わたくしはそっとここを去って運動と瞑想をして過ごすことにします。
※ところで書いてて思ったのですけれども、id:xevra先生のような濃ゆいユーザがこの村を見限って去った時こそ、実はいよいよ終わりがやってくるのかもしれませんね。5,6年くらい前まではこの人はbotなのだろうか、非表示にしたほうが良いのだろうかと考えては思い留まって今に至るわけなのですが、今まで生き残ってみると、年々人間味が出てくるし優しいことも言っちゃったりするし、GOJOい人達からも人気みたいですし、実は彼こそがもっともフラットで平等なユーザーなのではないかという気がしてきました。わたくしが知らずのうちに村の毒に冒されているせいかもしれませんが。
というわけで、じゃあ磯野、また明日な。
そういえば、先月は番茶でアニメを殆ど見てないことを思い出しておそ松さんの続きを見始めたら、ローション会だった。
１クール目のおそ松さんは好きだったんだけど、２クール目は女子向けに突き抜けすぎて、ちょい食あたりやなぁ〜。
１６話って女性の業の深さが見えて、「逆恋愛工学」みたいになってて、一周回ってホラーにしか見えないんだが…。
ここで言う逆とは「恋愛工学めいた【利己的な遺伝子】的発想を女性側が自分達が干からびてでも受け入れる」という意味での逆。恋愛工学…つまり、正位置では振りかざしてたことをね
２クール目のおそまつさんは見ないほうが良かったのかな…特に１６話は最初っから最後まで媚び媚びすぎて、しんどい…。
なんだろう…こうじゃないんだよ。
どっちかというと、少年マンガとかロボットアニメの１シーンからヤオイ的なものを拾っていくのが好きな感覚を「腐」として認識するわけで
少女マンガはあの独特のテンプレのシュールさを楽しむ、バカエロ系AVとか、テンプレート的なライトノベルの女版文化だと思ってみてました。ごめんなさいｗ（たまにすげーいいのはあるけど、典型的な奴は本当にシュールっす）
妹にハルヒとかおおふりのキャラソンをかたっぱしから聞かされた時のことをおそ松さんのエンディングの入りで、思い出す。
地獄の１６話終わったと思ったら、１７話は十四松まつりかよ…マラソンで見ようと思ったら、タフネスが要求されるなぁ〜。これ。
１６話でなんか、最近の嫌なことを色々思い出して、思考がこじれたから寝るけど
恋愛カテゴリに手を出して、女性向けアニメ見るとなんか精神の平穏を保ちながら見るのがすげーしんどい。
ゲスな女の恋バナと、部分的に一致していくのを見ると「あーオタクでも女の子はやっぱりそっちノリなのか？」みたいな気持ちになる（実際そうなのかはサンプル不足で謎だから気持ちの問題）
自分の語彙力不足と経験不足で、ゲスな恋愛論を言う人間と、女性向けのオタク的な色恋ものをきっちりと切り離せない。
これが、男性向けだと「ねーよ」とか「うぶすぎてかわいい」ってのが全部仮想的であると同時に安心するんだけど…。そして、ないと思っても意外と初な女性っているからねぇ…うん
前に、とれいC（@sakenomitracy ）さんから「他の記事はいいのに、青二才さんの恋愛論だけはなんか違う」って言われたのは本当に的を射てると思う。
というのも、恋愛論をかじってから、人間の見え方が変わっちゃって、不信感とアウェー感で押しつぶされかけてるのよね…うん。
正直言って、恋愛のコツは２つしかない。「足るを知ること」と「自分がモテたいタイプの人のいるところに行く」ことの２つ。
で、恋愛論の多くは「ミスマッチを他人のせいではなく、大半は自分の鏡でしかない」と気づいてないだけ。
結局のところ、なんで恋愛論が存在するかというと、結論よりも共感を大事する女と、そこにうまく頷くとヤれること・モテることを知ってる男が「男ってホント馬鹿ね」「あいつがモテないのはキモいからっしょ」といいあうという地獄。
リア充版駄サイクル
頭の悪いやつのために補足しておくけど、ヘイトでもミソジニーでもないです。
