「JavaScript」を含む日記 RSS

はてなキーワード: JavaScriptとは

2016-09-17

起業しない理由

古参ネット使いとして苦言を申すよー。

私はWEBデザイナー12年目。

紙もできる。ポスター、チラシ、雑誌のページ。

WEBコーディングは当たり前。エディタmiで直打ち。

CMSは3つ扱った。

drupal

Wordpress

movabletype

周りは独立していった人も一定数いた。

だが私は会社員を望んだ。

その理由を下記に述べる。

1.サラリー

私は恵まれたと思うくらいの会社所属している。

有給年間20日。夏休み5日。毎年年休はほぼ使い倒す。

夏休みも、5日フルにとり9連休にしている。

給料女性平均よりちょい上。

2.面倒くさい顧客シャットダウン

周りに恵まれているのである

営業さんや上司が間に入り、アホなことを言う奴らを丸く収めている。

アカ20校目とかない。

3.営業苦痛

起業したとして、いまの年収を考えると4倍の収入が得られなくてはならない計算だ。

無理。

そんなスキルあったら別の事で生かしてブイブイいわせてるわ。

4.私も青かった

くせーくせー青くせー。

高校進学校に行き、日教組と反発し。映画が撮りたくて専門学校に行く為に一年バイトして学費を貯めた。

行った専門学校はクソで。

しょーもない日雇い派遣で末端を見た。

瓶にヒビが入ってないかひたすら検品をする8時間

フォトショイラレが使えるだけで日の目を見ることができた。

5.脱線したな

まあ、あれだ。ブロガープログラミング知識はいらないぞ。

それhtmlとかcssでいけるぞ。

もしくはJavaScriptとかjquery

あとPHP

ハローワールドーとか書いてよし!とか思ったらウェルカム

ブログプログラミング始めました、とかかいたらアウト。

2016-08-23

グラフィックデザイナー専門の俺が何でプログラミングしないといけな

上司命令グラフィック制作チームからプログラマーのチームに配属された

グラフィックデザイナーとして就職したのに何でプログラミングしないといけないの?

Rubyとか知らねえよ

俺はフォトショイラレしか使ったことねえんだよカス

Windows PC用意したからそれ使って」

Windowsあんまり使ったことないし・・・まあ仕事なら覚えますけど・・・

「このチームではエディタVimEmacsしか使えないから。どっちか選んで。」

出来れば長年愛用してきたmiが使いたいんですけど・・・やっぱりMacがいいな・・・

「ここ、午後までに修正してプルリクしてね」

「ここ壊れてるらしいから午後までに潰して」

(´・ω・`)はあ??なんなのこの会社

はあ?????????????????????????????????????????????

マジクソだろこの会社

CとかVC++とかRubyとかPHPとかJAVAScriptとか採用情報にいろいろ書いてあるけどそんなの1つも出来ねえよカス

プログラマーを雇えばいいだろ

そもそもプログラマーにも同じ事させてみろや

プログラマーグラフィック作らせてみろって

何でグラフィックデザイナーの俺にプログラミング即戦力を期待してるの?

俺はグラフィックがやりたいの!

ああそうか、これは事実上リストラ候補ノミネートされたパティーンなのか

ゆとりからってなめやがって

かかってこいよ東京都○○区のブラック企業の○○○○○の○○○さんwwwwww

2016-08-18

年収を上げたいなら、webを出ている場合ではない。

なんかイラッとしたので反論したい。

ちなみに年収主題かもしれないが、

言っていることも矛盾が気になった。

あと、自分匿名感情的な指摘なので、支離滅裂していることは最初に謝っておきます

やはり、web世界にいるだけじゃダメですね

どの会社web仕事はしていても、お客さんはweb世界だけではないので、

言うほど閉鎖的なものではない。

スタートアップとかは、web × 他業種だったりして、

他業種について、本業の方と同レベルで詳しくなることもあるんじゃないかと。



できる人とそうでない人の違いはどこにあるかというと、仕事の幅なんだそうです。

別にweb関係ない。どの業界でもそうだろ。



技術の幅が狭いエンジニア、例えば「JavaScriptしかできません」のような専業エンジニアがいる。これは東京に多いんだよ。

逆に、大阪には、仕事の幅が広いエンジニアがいる。大阪場合、「なんでもやれる」と言えないと仕事がとれないから、結果、フルスタックエンジニア生まれる。

なんとなく言いたいことは分かる。だが、

一方、大阪エンジニア自己評価が低く、基礎的な技術をしっかり学んでいるそうです。PHPからRubyといったように言語浮気をしようとしないんだとか。

おいおい他言語浮気はしないけど、一言語だけではダメとかどっちなんだよ。

何でもできるんですか、それとも知ってることだけですか?

フロントとバックの違いは浮気にならないとでも言いたいのでしょうか。

でも、言語としてはjsphpの2言語となるので1言語以外をやるなら、それは浮気ととれるでしょう。

結局、言葉遊びで「言語浮気」って使いたいだけだろ。浮気定義からやり直せ。

加えて、東京大阪の違いは分かった。だが、東京ディスる必要はない。

他人から聞いてきた話を引用するなら、不快になると分かる箇所くらいオブラートにつつめ。

今はweb仕事が多くなったけど、インターネットがない時代にはもっと他にもエンジニア仕事があったわけ。

別にだってweb以外はあるだろうに。なんなら、エンジニア不足って言われているんだよ?? あと、IoTでググって。

あと、web世界だと35歳になったプログラマーが悩むなんてことがよくある。これは、35歳定年説を信じてのことなんだけど、気にする必要はない。そんなの実際はないから。

おそらくですが、「35歳定年説」をそのまんま鵜呑みにしてるのは、webで働いてない人がほとんどかと。

web系の人は、ずっとプログラマーでいく意識が強い。生き残るために新しい言語を求めてしまうけど、そうじゃなく、仕様書を書いたり、情報処理勉強をしたりして基礎的なことを学ぶ方が賢いよ。

プログラマーバカにし過ぎ、基礎をやってるやってないは個人差。プログラマという職業関係ない。

ギャルIQが低いといっているのと何も変わらない。

実際は勉強のできるギャルはいくらでもいる。

から、稼ぎたいなら銀行システムを作ったほうがいい。ペースもゆっくりだし。銀行システムは作るのに数年単位かかるしね。

数年かかるのはいいが、終わらないのは困る。「みずほ銀行 システム開発」でぐぐれ。


特にweb世界はまだ単価が低く、紙の方がギャラが高いというのが現状。なので、割のいい仕事をしたいなら、やはりwebを出ないといけないんですよね。

また、手を動かす仕事から離れる話でも、最近思うところがあるんです。先日、界隈の人と話した時に「目立ってる人より、影に隠れている人の方が稼げてる」なんて話を聞いたんですよね。

これって、ライター世界にも当てはまっていて、注目を浴びているライターよりも、その人に仕事を振る人、編集をする人の方が効率的に稼げてるなんてことがあるんですよ。

単価の話関係ないじゃん!!

用は、管理職系の方が給料高いんですよって言いたいんでしょ。

ついでに具体的な年収記載してから言ってください。

仕事を振る人の方が効率的に稼げていることもあるでしょう。

あ、もしかして、この文章アウトソーシングですか?(煽り

なので、この記事を読んで、その重要性に気づいたエンジニアデザイナーライターなどの専門職の方は、ぜひ将来のキャリアについて考えてみてください。

その重要性ってなに?

フルスタックになること? 情報処理資格をとること? 管理職を目指すってこと?

それとも、Webをでること?

締めで使う「その」という指示語の範囲が広すぎる。記事の内容をまとめた後に使ってください。

それと、年収をあげるのは、別にプログラマのままでもできるんじゃない?

基礎を勉強して、フルスタックになって、

プレイングテクニカルディレクターとかになれば、

そこそこ給料はよくなりそうだが??(そんな職種があるかは知らんが)

金額会社次第でしょ。



提供:らふらく(@TwinTKchan))

お前が聞いてきたはなしじゃねえのかよーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー。

社長から聞いてきたーというくだりもそうだけど、

89世代意識高い「系」だったら、平成生まれ視点での言葉を言ってほしいわ。


この増田を読んで、煽り重要性に気づいたブロガー意味のある煽りについて考えてみてください。


「聞いた話をうまく活用しているサイトはやっぱアソコだよな」

エロサイトか。

2016-07-21

http://anond.hatelabo.jp/20160721084054

なかなか面白いので、次はJavaScriptエンジニア版でやって欲しい。Reactとか

2016-07-19

おカタい文章の中に出てくる独特な言い回しが興味深くて面白い

法律とか契約書みたいなおカタい文章を読んでいると,

「A、B、Cについては、○○の場合においてこれを実施することができる。」

みたいな言い回しをよく見かけるけれど, 日常のやりとりではまず出てこないような独特な言い回しだよなーと大変興味深い. (「これ」という言葉の使い方とか)

おそらく, この手の文章はできるだけ解釈が一意に定まる (読み方によって解釈がブレない) 表現必要なので, そのための工夫としてこういう形になったんだろうな~.

解釈が一意に定まる」ことの重要性はプログラミング言語でも同様で, 処理系実装する場合にもポイントになってくるわけだけど, そういえばこの表現ってプログラミングにおける foreach 文だよなとふと思った.

「A、B、Cについては」という語句言及している各項目を、「これ」という変数バインドしている感じ. Javascript 的に書くと

[A, B, C].forEach(これ => { if (○○の場合) 「これ」を実施; });

こういう風に解釈すると, この手の文章を読んでいてなるほどなーと思える.

http://anond.hatelabo.jp/20160719113551

javascript:(function(){document.body.innerHTML=document.body.innerHTML.replace(/!/g,'♥');})()

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-01

http://anond.hatelabo.jp/20160701123135

WEBプログラマー

RailsPHPが使えてWebサイト管理機能を作れる人が欲しい



フロントエンドエンジニア

HTMLJavaScriptが使えてカッコいいスマホ対応サイトデザインできる人が欲しい



ITエンジニア

仕事は決まってないけどとにかく人が欲しい

2016-06-30

2016 年 6 月版初心者向け JavaScript セキュリティ

JavaScriptUI を構築していると XSS がうんたらかんたらみたいな能書きをきちんと理解してきちんとやっていくのが一番よいというのはそうなのですが、 2016 年にもなってそんなことの学習時間がしがし使うのもおかしい気がする。おかしい気がしないというそこのあなたCPUFlash ストレージから自作して現代風のシステム全部作っといてください。

というわけで初心者は以下の原則を守ればいいと思う

JSjQuery作業しない

PHP だけでなにかを作る人間はもうたぶんいないですし、 JavaScript での UI 構築ももうそういうものだと思っていいのではないでしょうか。 React か Angular かなんか使っとけばいいと思います。 React おすすめ。これらの現代っぽいフレームワークを使っている限り XSS のような初歩的なミスはほぼ起きません。 React の場合危険機能には Dangerously Set innerHTML というヤバそうな名前がついていて便利です。

同一ドメイン内に決済とかあるサイトに関してはもちろん上の原則はあてはまりません。それは初心者が触るべきものではない。

2016-06-29

何がしたいのか

何がしたいのか。

なんでもやりたい。何にでも挑戦していきたい。webに関わること全てに。グラフィックデザイン映像プログラミングアプリ。けど、一つずつ潰していこう。

まずは何をする?

webデザインプログラミングを覚えよう。

htmlcssjavascript。これらの基礎や拡張言語から

目標を立てる。小さな目標で良い。ミニマムに達成を積み重ねていく。自分には成功体験が少ない。

褒めてもらうのを一度考えない。あわよくば、で良い。小さな目標を成し得たら、自分が褒めてあげる。それで良い。

他人意識しない。意識しない、というのは、他人と比べない。自分他人比較しない。比較無意味自分を追い詰めるだけ。

ただし、目標となる人物像を立てるのは良い。憧れの人を持ち続ける。尊敬する人は何人もいても良いけど、真似する人は1人くらいに絞ったほうが良い。

いままでは運で乗り切ってきたことを認識する。偶然、たまたまここまでやってこれた。

自分能力を一度、ゼロ戻す。

運に頼るべきではない。実力がついて初めて運もついてくる。

ただし、自信は捨てない。根拠のない自信を持て。何事も自信から始まる。

大丈夫、君はまだやれる。

ここでこれを公開することが、スタート前の最後承認欲求

2016-06-26

いまさらRubyはない

Pypyだかなんだかが何をするライブラリか知らない程度の門外漢だけどRubyやるくらいならPythonやる

Rubyオワコン

Rubyいたことないけど

本屋プログラミングコーナーのぞいてもIQ2桁の言語Rubyで3桁ならPythonという感じ

PHPPerlJavaJavaScriptやってる連中の言語Ruby

HaskellGoC++をやっている上級国民言語Python

あるいは、ホテル間接照明に照らされた女の子おっぱいを揉む人の言語Python

スーパータイムセールで買った半額弁当ワンルーム蛍光灯の寂しい部屋で孤独に糞に変え、自分弁当を糞に変えるパイプにすぎないという現実に直面してもとくに抗うでなく、人間なんてそんなもんだと納得し乳輪から毛が何本か生えてる自分の胸を揉む人の言語Ruby

だいたいそんなイメージ

2016-06-17

各界隈の頑固おじさん

PHP 徳丸
C++ 江添亮
JavaScript mizchi
Vim h_east
Google Yoshifumi YAMAGUCHI
アメリカ トランプ
北朝鮮 人造人間19号みたいな人
近所 3丁目のげんこつ八兵衛さん


昨日、駅でマナーの悪いDQNを注意してたおじさんがかっこよかった。

今の時代は人に嫌われるのが怖くて叱れない人が多いんだよねぇ。

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

Amazonの短いリンクを作るブックマークレット

物品購入とかの資料を作るときコピペできるように。

https://www.amazon.co.jp/dp/B00R3MZXKK/ref=gbps_img_s-5_3469_8e987573?smid=AN1VRQENFRJN5&pf_rd_p=326353469&pf_rd_s=slot-5&pf_rd_t=701&pf_rd_i=gb_main&pf_rd_m=AN1VRQENFRJN5&pf_rd_r=XWAC0XVYK23NCN3F4VN7

これを

こうする

https://www.amazon.co.jp/dp/B00R3MZXKK


javascript:(function(){prompt('Amazon ASIN Link', 'https://www.amazon.co.jp/dp/' + document.getElementById('ASIN').value);})();


製品名はこれ

javascript:(function(){prompt('Amazon Product Title', document.getElementById('productTitle').innerText);})();

2016-06-01

Impress Watchリニューアルはクソ

Impress Watchがサイトリニューアルしたらしい。が、スマートフォン・タブレットを主体にしたせいなのか、PCから見るとかなり見づらい。なぜ見づらいのか。

  • 画像と文字が大きくなりすぎて1画面に表示できる記事が大幅に減った。縦長ディスプレイ前提?
  • 左カラムにあった記事一覧が右側に移動、その上数が減っている
  • 特別記事、コラム記事が区別しづらく見える
  • 上部のヘッダーが大きすぎる。~Watchとかはともかく、出版本別に増やすのどうなの?
  • 上部のヘッダーのうち、スクロールしてもついてくるカテゴリ一覧が邪魔。右上に「カテゴリ」「検索」アイコンがあるんだからそれで十分だろ
  • JavaScript無効化すると画像が表示されない
  • 既読リンクの色が変わらない

横長モニターを使ってるPCでは読みづらい。特にヘッダー部と1画面に表示できる記事が大幅に減ったのはクソ。

記事の高い一覧性という特徴をつぶしてまでリニューアルする必要があったのか?その特徴に気づいていない担当者がやっちゃったんだろう。誰だよこんなデザインでGoサイン出したやつ。

読み手のこと考えてんのか?

2016-05-31

JavaJavascriptの違いの例え

メロンとメロンパンぐらい違う

うどんときしめんぐらい違う

のどちらがいいだろう?

2016-05-25

http://anond.hatelabo.jp/20160521234423

というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。

MVCモデルというのは、オブジェクト指向の発想。

DOMというのは、そもそもDocumentObjectModelでオブジェクト指向

JQueryはそのVを関数型的に扱おうとした拡張

Reactは、これらすべてを一旦ご破産にした。

MVCのVだ、と公式サイト説明されているが、これは半ば皮肉であって、本当はVは存在しない。Cももちろん存在しない。M、モデルロジックしか存在しない。モデル一元論、それがReact。

VであるDOM消滅し、JavaScriptの `x` や `a` などその他の変数と同列のファーストクラス仮想DOMとしてしか存在していない。

まり仮想Vは、M(モデル)内で関数型の文脈自由自在演算できるわけ。

コード最後マウントしておけば、仮想Vは自動的に、実VのDOMとして描画される。

M=ロジックの外に、あらかじめわざわざ決め打ちしたVを用意するよりも、M=ロジックに一元化するほうが賢い。それがReactであり、JSX

http://anond.hatelabo.jp/20160521163144

ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。

最近炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。

http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html

Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JSJSX)上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブJSX上の仮想DOMからDOMリアルタイムマッピングされ描写される。

JQueryも、実DOM関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能

coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。

React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。

2016-05-24

http://anond.hatelabo.jp/20160523164755

一応、要求通りに新しい課題OCamlコード書く

http://okaml.blogspot.jp/2016/05/done2.html#more

 ↓

kenokabe氏に、

OCaml関数状態渡し : 74行

JavaScript+React+TimeEngineのFRP : 29行

kenokabe氏のFRPじゃ半分以下のコード実装できたと、トドメをさされて終了

http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html

結果、kenokabe氏の圧勝かな、おもしろかったです!

2016-05-23

JavaScriptが嫌いで使いたくないたった1つの理由

Visual Studioデバッグが出来ないから。

http://anond.hatelabo.jp/20160520093920

仮にCが純粋関数型言語で、岡部FRPのx.t=x.t+1;も関数型なんだったら、C言語のx=x+1;も関数型だよね。

岡部氏の本でさんざん「x=x+1;は論理破綻」って批判してたのは何だったんだろう。

というか普通のCやJavaScript関数型なんだったら、岡部関数型の存在意義は……

2016-05-22

javascriptjqueryの知識もなくて、テンプレそのまま使ってる人がいる。

コードみたらぐちゃぐちゃだしJSなんて似たような内容のやつ5~6個読み込んでたり。

エラーが出たら私が直すようにしてる。

でもデザインがすごく良い。画像の使い方、文字の配置。

いつもそれを見て、凹む。うらやましい。私にはできない。

どれだけHTMLCSSJSの知識があったって、こんなの作れない。センスがない。

デザインの基礎を学ぶことはできても、応用はできない。

うらやましい、悔しい。私もあんものを作りたい。