「ライブラリ」を含む日記 RSS

はてなキーワード: ライブラリとは

2016-08-12

amazon unlimited 使いづらい

コンテンツ管理から本の利用を停止したいのに、iPhoneからだとアカウント管理のページを開いても出てこない。

やっとたどり着いて、本を削除しようにも、オーナーライブラリ使用中だからできません。と出て、じゃあどうやってオーナーライブラリの利用を停止するのか調べでるけどまだ分からない。

すごく使いづらくて利用やめたくなってきてる。

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/

2016-07-31

webサイト作成したいだけなのに何でファイルを沢山作らないといけないのか

webpackの設定ファイル

gulpの設定ファイル

sass設定ファイル

ライブラリを使うとどんどんファイルが増えていく

設定に関する仕様策定して統一できないものかね

設定ファイルを1つにまとめられたら良いんだけどね

↓こんな感じで1ファイルカテゴリ毎に設定したほうがディレクトリがきれい

[webpack]

[gulp]

[composer]

[phpmd]

2016-07-28

http://anond.hatelabo.jp/20160728113532

バージョン確認は当たり前と言うけど、逆にマイナーバージョンまで一致してることなんてほぼないわけじゃん。どの程度違ってても動くのかなんてわからいから、確認した所であまり意味はない。

またライブラリよりも依存する環境の設定(バージョンではなく)で動かないケースが経験上多いからそこまでは記事から確認できなくてお手上げなんだよな。

解決策としては公式を読み込むしか結局ないんだけど野良エンジニアブログが役に立ってた時代より開発に時間がかかるようになったのは確か。

http://anond.hatelabo.jp/20160727175406

ライブラリバージョンが一致しているかどうか確認するのは当たり前のことだよ。

つーかNodeでもライブラリドキュメント読めば互換性があるかどうかはきちんと書いてある。

Javaは安定してるっていうけど、この前Android開発でJDKバージョンアップした時にjarsignerのデフォルト引数が変わっていてひどい目にあったかJavaでも同じ。

アピールできるスキルが無くて辛い

これまで10年近くプログラマやって来たんだが、コアになるスキルを身に付けずにここまでやってきたことに後悔を感じている。というのも転職活動をしていて、経歴はそこそこあるので書類は落ちたこと無いんだが、リーダークラスの人との面接で、経歴を交えつつ自己アピールすると全然ダメだ。というかそれがダメだとどうしようも無いんだが。



動画処理とか音声処理、データベースネットワークまわりのアプリを点々とやってきた。とはいっても、それらを実現するための、コアなライブラリ別に有って、外部から色々なたたき方をして、アプリケーションにすることをやってきた。



動画だったらコーデックとか、データベースだったらチューニングとか、そういったものに詳しいと思われてしまうようなんだが、そこらへんはライブラリ任せだったので、そこにコアなスキルがあるわけではない。コア技術をくっつけてアプリにするような、接着剤みたいなコードをずっと書いてきてしまった。ただ○○って言語使ってバリバリ書いてました、じゃ全然ダメだ。



今まで漫然と過ごし過ぎていた。もっと深堀したスキルを身につければ良かったな。もし似たような境遇の人が居たら、どうやってアピールするか教えてほしい。

2016-07-22

https://twitter.com/yuku_t/status/753177071468224512

それできるVimプラグイン作ってるよ

scipyとnumpyを自力挫折せずに導入できる人しか使えないし出来ない人のサポートしたくないしVim 8.0に合わせるから今は公開する予定はないよ

http://anond.hatelabo.jp/20160107202352

プラグイン自体はだいたい完成してて今は辞書を膨らませている

Vim界隈でPython機械学習に詳しい人なら作れるよ

いくつかPythonライブラリを覚える必要があるけど君達もPython覚えてチャレンジしてみなよ

良いエンジニアの条件ってさ・・・

以下の記事を読んでの考察

https://nanapi.com/ja/122917



上記内の記事でもそうだし、

散々いろんな優秀な方々が言ってることだから

良いエンジニアになるのに一番大事なことって


技術が単純に好きなこと」


なのだろう。。。多分。



そこでふと思ったんだけど

この技術が「好き」という想いには

レベル存在しているのではなかろうか。


自分はまだ駆け出しのPGだが、

以下は自分想像した

アプリケーションエンジニアの「好き」レベルである




Level1】:

ネット本屋で新しい技術を目にすると、ざっと確認してしまう習慣がある。

ありがちな言動:「ふむふむ(ほむほむ)」



Level2】:

Level1に加え、自宅でWebサーバを公開したり、アプリ作成している。

またこのレベルからデザインUI/UXDBセキュリティインフラ技術など、興味関心が多分野へ渡りコミットし始める。

ありがちな言動:「今日アクセスが10増えたぞい。ぐふっ」



Level3】:

Level2に加え、休日はしっかりと時間を確保し、技術習得や、OSSへのコミットを楽しんでいる。

ありがちな言動:「今日×コミット×コンプ♪」



Level4】:

Level3に加え、技術面白すぎて、いろんなアイデアが一日中頭の中に浮かび、

気づいたら毎日手を動かして何らかの実装をしている。

ありがちな言動:「フォオオオオオオオオー」



Level5】:

Level4に加え、FWライブラリソース読破し、茶々を入れることに喜びを覚える。

また実際にコミットも行えるLevelに到達。

ありがちな言動:「これはアカン。。」



Level6】:

Level5に加え、言語設計にまで手を伸ばし始める。

現在第2のMatzになるため、世間から隠れたところで日々ハッピーエンジニアリングに勤しむ。

ありがちな言動:「俺が最高の言語、作っちゃる!!!





↑これあってる?

2016-07-10

memo

書籍より

Web + DB vol.92

データ分析の基本アーキテクチャ
フレームワーク比較評価

10年戦えるデータ分析入門

SQL中心アーキテクチャの3つの
SQL中心アーキテクチャの3つの条件
tips
  • DWH層を標準ライブラリのように考えて構築するとよい.
    • 「購入の可能性があるユーザ一覧を表すビュー」をDWH層に持たせるなど.

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

Javaしかwebアプリ作ったことなかった俺がphp入門したんだけど

すげー楽でワロタ

つーかなんだよ、JSPって

なんだよ、ストラッツって

大体デプロイするのになんでwarの中に参照ライブラリ入れてくれないんだよ

なんでクラスファイル漏れることがあるんだよ

xml地獄ってなんだよ。

今は2016年だぞ。未来なんだぞ。いつまでもくだらねー仕事やらせんなや。もうJava案件やりたくねーんだよタコ。バーカバー

2016-06-30

http://anond.hatelabo.jp/20160630180305

ナマJSも書けない人間ライブラリを使いこなすなんて無理だから

勉強サイトではしっかり生JSを学ぶべき。



だけど、本番開発ではセキュリティ周りを気にして一から自分でナマJS書くのは危険まりないので

再利用できるライブラリは使った方が良い。

http://anond.hatelabo.jp/20160630013810

ドットインストールやら各種お勉強サイトだとナマでjs書いてるけど、実際に開発するときはそうするな!ライブラリをつかえ!ってこと?

2016-06-29

http://anond.hatelabo.jp/20160629160535

配列操作やらが楽だからだな。>phpが便利

例えばSQL文を生成する際に以下のINの所にカン区切りデータを入れる際、

SELECT * FROM ITEM WHERE ITEM IN (...)

このIN文に入れるデータテキストデータなんかで格納されてて、適宜読み出して使う場合普通にコードを書くとクソ面倒くさい。「行ごとにカンマは足していくが、末尾のカンマは取り除く」みたいなどうでもいい処理を書く羽目になって、それだけで10行近くコードが膨れる。

しかし、phpならば$IN=implode($list,",") とかでいい。

こういうような糞処理を関数一発で何とかしてくれるのがphpには沢山ある。

jsonなんかのパースも、特にライブラリ読み込んだりしないでもjson_encode()json_decode()なんかでいい。

とかく普通にやると面倒くさい処理の殆どデフォで揃ってるのがPHPだ。

PHPやった後にPythonやると、あれもこれも機能が不足してたりして結構辛かったぞ。

2016-06-26

いまさらRubyはない

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

Rubyオワコン

Rubyいたことないけど

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

PHPPerlJavaJavaScriptやってる連中の言語Ruby

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

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

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

だいたいそんなイメージ

2016-06-21

デプロイ時にいつの間にかライブラリバージョンが上がってしまって死ぬとか、どんだけ管理杜撰なんだよwwwww

2016-06-19

全てのRubyエンジニアはだいたい糞である

汎用系のエンジニアからRubyエンジニアとして転職して1年。

コボラー(笑)なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。

その特徴はだいたいこの3つだ。

1.テストを甘く見ている

やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。

そもそもブラックボックステストホワイトボックステストを分かっていない奴が多すぎ。

テストコードカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。

そもそもテストケース表を若いうちに書く習慣が無いからだ。

ドキュメント揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまRubyエンジニアは糞である


2.パフォーマンスを考えない

Rubyエンジニアパフォーマンスを考えない。

どのメソッドがどれくらいの負荷なのか意識せず実装を行う。

便利だから、ただそれだけの理由なのである

そもそも自分が行おうとしているソートが何ソートなのか知っているのか?計算回数を考慮した上での実装か?

便利なメソッドがたくさんあるのは知っている。

ただ、中身くらいは知っておこうよ。

eachで回してばかりだから複雑なループ対応もできない。

新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。


3.外部ライブラリに対する絶対的根拠の無い信頼

Gemに対する絶対的な信頼感、あれなんなの?

Githubで公開されてましたんで導入しました」じゃねーよ。

結局他のGemバッティングしているじゃねーか。

得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。

そんで都合の悪いところだけコードを読んでオーバーライドする。

影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの?





いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。

インデント合わなくてコンパイルエラーとかないしな。

でもあまりにもRubyエンジニア糞すぎだろ。

エンジニアもどき量産言語だね。どれか1つでも当てはまった奴は小学校からやり直せ。

日本の将来が心配だわ。




追記


意見がたくさんもらえて喜ばしい。

文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。

それで納品するのはプロとしておかしい。



主語が大きい

「だいたい」とあるだろう。全てのだいたいだ。



フローチャート

ロジックを整理するツールとしては優秀。

精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。



カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける

あー、ここは誤タイピングだわ。

自動テストカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。

単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。

もちろん慣れて頭に入ってくれば勘所がわかるんだが、そんな属人的ものよりもケース表書くのが無難だろう。

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

iPhoneからiTunesで買った曲をAndroidで聞きたい!

なんか、Androidで聞いた方が音がいいような気がする、

iPhoneから曲が買えて便利だけど、

買った曲がAndroidでも聴けたり、反映されてライブラリ勝手にこっちにもダウンロードされたりとか

そんなことできないのかな?

なんか、そこら辺の曲の取り回しの仕方がめんどくさい。

Bluetoothで曲をAndroid転送できんのかい

Android版のiTunesってないんかい

2016-06-07

言語言語っていうけど

言語のものに力はなくて、

生産性に大きく関わってくるのは結局開発環境ライブラリフレームワーク

2016-06-06

プログラマにとって最も屈辱的な瞬間

小飼弾ライブラリを使っている時

2016-05-28

Rubyかい気持ち悪い言語をよいしょするな

コードの中がendの山で見るだけで頭がくらくらする

unlessってなんだよこんなんいらねえよ

無駄言語構造を増やしてんじゃねえよ

言語構造は極力シンプルであるべきなんだよ

必要ものライブラリ実装するべきなんだよ

いい加減国産からと持ち上げてよいしょしてんじゃねえよ

2016-05-27

自慢気にDeep Learning使ってるやつは大体クソ

色んなライブラリが出てるからDeep Learningを使うこと自体全然難しくない。

おかげで暇人Deep Learningをちょっと試してみたみたいな記事がよくホッテントリに上がってくる。ブクマをつけてるやつらは大抵、自分で試してみる気力とか能力のない残念な人たち。

ところが、記事の内容を見てみるとマジで単に使ってみてるだけなんだよな。なんでDeep Learningを使わなきゃいけないのかさえ考えてない思考停止ほとんどの場合は、昔からある3層のニューラルネットとかSVMで十分な性能が出る問題になんとなくDeep Learningを当てはめているだけ。

あのな、Deep Learningみたいに膨大なパラメータを持ってる学習モデル簡単過学習を起こすから素人が下手に扱うとむしろ精度が落ちるもんだ。そこそこ難しいタスクに対して上手く学習するには、とんでもない量の訓練データ必要になる。しかも、Deep Learningは手動で設定する必要があるハイパーパラメータの数も膨大で、学習率とかノード数、正則化パラメータみたいなやつらを地道に調整しなけりゃいけない。はっきり言ってめちゃくちゃ泥臭い作業だ。

なんでGoogleとかがDeep Learningで成功しているか、少しでも考えたことあるか?あいつらは過学習なんて関係なくなるほど、無茶苦茶たくさんのデータを手元に溜め込んでるんだ。しかも、ハイパーパラメータ設定の勘所を掴んでる職人みたいな技術者を金の力でどんどん集めている。

Deep Learningは理論的な下支えがほとんどなくて、勘と経験則で成り立ってる世界だ。数年前の定説簡単にひっくり返ることが多いし、正直なところあれは研究と呼べるものではないと思う。「なぜかは知らんがやってみたらうまくいった」みたいな事実が羅列されてるだけ。思いついた手法が上手くいくかが運任せという意味では、ガチャを引いてるのとだいたい同じ。無課金勢がいくら知恵を絞っても廃課金勢には勝てない世界

というわけで、お前らがぽっと出のアイディアDeep Learning使ったところでゴミみたいなアプリが出来るだけだからやめとけ。

そんな時間があったら、ちゃんとした機械学習の本読んどけ。PRMLとか。

数学が難しい?じゃあ、線型代数確率論勉強をやり直せ。そいつらは機械学習が廃れても役に立つからさ。

2016-05-25

http://anond.hatelabo.jp/20160525213232

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

第一に、それは、ストリームFRPの値の定義)の問題であって、ユニットテストすれば良い。もしくは単にFRPログを取れば良い。

グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリ特にそうだけど、基本的ミュータブルな値同士が関数リアクティブ連携されて常に整合性を保っているのだからグローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという(テスト自体困難な)問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。

使用する関数問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数問題と一緒というのはまったく違う。

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

いや、それがそもそもの発端であるブログの経緯には書かれている。説明されている方式GUIアプリまで書けるのか?と疑念が呈されたことがきっかけ。

岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

原理的に可能かという議論ではなく、実用的な範疇か?という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRP状態渡しは同じ複雑さだという主張も崩されている。そこが重要

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

段階を踏んだ上で、非FRPHaskellのIOモナドコードを誰かが書いたらいんじゃない?当面、最初OCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたか制限されたんでしょ。実際には、OCaml関数型では冗長しか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、

書き込みをみれば、君以外の書き込みもすべて、その一派ではない、とでも言いたそうだ。

2016-05-24

http://anond.hatelabo.jp/20160524151555

FRPライブラリサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか?

拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話

すでに出たサンプルからFRPの効力がまざまざと見せつけられている。

FRPの効力を否定なんて誰もしてない(よね)

「これが正しい関数型でお前らの状態渡しは間違ってる」みたいに言うから荒れる

間違っている電波

個人的電波だと思うのはこういう匿名書き込みを住井だ駱駝だ言い出すところ

いやだから、定数なんだから書き換わらないんだよ、FRPストリームconst 定数なんだから

ストリームから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラム欠点をそのまま持ってるじゃん