「Scala」を含む日記 RSS

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

2017-09-16

株式会社はてな株主構成から見るはてな実態

今戯れに時価総額と持ち株比率から換算した資産表作った

近藤 淳也 66.33% 4482581400円 ○

(株)はてな 6.59% 445352200円

毛利 裕二 5.98% 404128400円

梅田 望夫 4.30% 290594000円

栗栖 義臣(社長) 2.61% 176383800円 ○

大西 康裕 1.97% 133132600円 ○

伊藤 直也 1.79% 120968200円 ○

田中 慎樹 1.41% 95287800円

田中 慎司 1.30% 87854000円 ○

小林 直樹 1.15% 77717000円

お金の額面はともかくの話なんだけど、

○をつけたのは、はてなコードを書いたことがあると"思われる人"。「名前 プログラミング」で検索して有意な結果が出た人に○つけた。各株主の詳細知りたい人は適当にググって

で、さら


はてな年収は524万円が平均年収です。(有価証券報告書調べ)

http://heikinnenshu.jp/joho/hatena.html

あると好ましい知識経験

スクリプト言語(主に Perl/PHP/Python/Ruby/JavaScript)によるアプリケーションライブラリ開発の経験

ScalaGoにおけるアプリケーションライブラリ開発の経験

iPhoneアプリ、もしくはAndroidアプリの開発経験

UNIX系OSRDBMS特に LinuxMySQL)についての基礎知識

オブジェクト指向プログラミングの基礎知識

コンピュータサイエンスアルゴリズムデータ構造分散技術自然言語処理技術機械学習データマイニング型理論)に関する基礎知識

ネットワーク技術HTTPDNSTCP/IPなど)についての基礎知識

大学卒/275,000円〜

http://hatenacorp.jp/recruit/fresh/application-engineer-entry

って、エンジニア待遇悪すぎじゃない?

この毛利 裕二という人の持ち株の資産新卒給料(計算だるかったか計算からボーナス抜いたけど、手取り分で考えたらボーナス分くらいは消えるだろう)で稼ぐとしたら122年かかるし、梅田 望夫という人は88年かかる。本当にこの人たちにはそれほどの価値(上にあげた新卒に求めるやたらと高いスペック)分の価値があるのか?いや、価値があると思ったから株をあてがったんだろうけど...

まぁなんていうか...、はてなのエンジニアのみなさんお疲れ様です...業務がんばってください

完全に外様の俺から言えるのは"エンジニアに"もっと給料たくさん払った方がいいんじゃないかということだけです

2017-08-12

Scala敷居が高いと言われたり、いまいち流行らない理由

Scalaコミュニティ有名人が、憧れの存在って感じじゃないからかな

やたらアカデミックだったり細かいことにうるさいが、野望があったりとか、クールソフトウェアを作ってたりとか、そういうのがない。

ハッカーっぽくない。

2017-08-09

10年後も戦えるプログラミング言語

Java

ScalaとかKotlinかいろいろ言ってる奴いるが10年後にはどうせJavaが勝ってる。

ラムダ式とか取り入れてJavaも着実に進化しているからね。

Javaはnull安全じゃない!とかほざく奴はもちろん@CheckForNullアノテーション使ってから言ってるよな…?

フレームワーク流行り廃りがあるから微妙だが、勉強するならSpringにしておけ。それだけでいい。

JavaScript

Webブラウザに標準搭載のJavaScriptが無くなることもまずありえない。

あとやるならjQueryね。AngularJSとかすぐ廃れるから

学習コストが高いものって結局広まらいからさ…素直に現実を認めよう。

シェルスクリプト

AnsibleやFabric使ってるやつがいるがどうせ10年後にはブームが去り技術負債となっている。

シェルスクリプト代用できるのだからシェルスクリプトでやっておけ。

SQL

これだけ広まったRDBが今後使われなくなることはまず考えられない。

ORMは流行り廃りがあるが、SQLが無くなることはまずありえないのだからSQLをやっておけ。

2017-07-10

Webアプリを作るときにどの言語/WAFで書くべきか

使ったことあるモノもないモノもごちゃまぜにして経験雰囲気で書いてる。

PHP

Laravelは結構好き。DSL過ぎず、それなりにフルスタック生産性もいい。

何よりLaravel本体ソースコードが読みやすいのがいい。

まともな日本語情報が少ないのは弱点だけど、気になったところは本体コードを読めばすぐに分かる。

最大の欠点PHPってことだ。他のLL言語に比べてPHP自体生産性は低い。セキュリティ面の不安も大きい。それに安心して後を任せられるようなPHPerは一握りしかいない。

Perl

Mojolicious結構好き。これもDSL過ぎず分かりやすい。CPAN豊富ライブラリ群もある。

Perlは可読性が悪いなんて言うけど、ちゃんとしたライブラリ普通に読みやすいよ。

最大の欠点Perlってことだ。長期的に開発者を集めることを考えたら茨の道だろ?

Python

今でこそ機械学習Pythonが人気になっているけど、Web系はまだまだマイナーだ。

Djangoプロジェクト/アプリケーションという構成単位の考え方が好きじゃない。理論的な利点は分かるけど、現実問題それが必要になるケースが浮かばん。

Django以外でフルスタックのWAFが出てくればいいんだけど。Tornadoはフルスタックじゃないのでちょっと違う。

Python3で安心して開発できるならアリだと思うけど今はどうなの?使いたいライブラリが3系に対応していないとかで躓きたくないよ。

あと単純に速度が遅いよね。いや書き方を気をつければマシにはなるんだけど、書き方を気をつけなければいけない時点でつらい。

Ruby

Railsは便利だ。周辺ライブラリの充実度もすごい。情報玉石混交だけどまともな情報もたくさんある。

ただあまりにもDSL過ぎる。Railsプログラミングではなく、一つの巨大なDSLだ。

Railsプログラマの何割が、少しでもいいかRails本体ソースコードを読んだことがあるのか。めっちゃ読みにくいんだけど。Rubyは可読性が高いなんて嘘だろう。Perlと一緒でちゃんとしたコードは読みやすいけどそれはプログラマ依存する話で、言語自体に可読性の高さはない。言語思想の通り書くのは楽しいよ。でも読むのがつらい。

Rails自体DSLみたいなもんなのに、RSpecやらRakeやら周辺ツールDSL意識高すぎる。

問題があった時にググらずにコード読んで解決できるRailsエンジニアはどれだけいるのか。情報量が多いからググれば解決すると答えるやつは、底辺PHPerと大差ないからな。

あとバージョンアップ追従するのが面倒過ぎる。でも放置したら負債になるし。意識高くRailsで開発したやつの大半はバージョンアップやらの保守に入る頃にはもうそプロジェクトはいないんだろ?だからそのつらさを知らないんだろ?

散々罵ったけど、このDSLを覚えれば生産性が高いのは事実だ。だから結局ついていく確率が高い。モテ男なんだよ結局こいつは。

Java

SIerさんに敬礼

Scala

Playが王道だけど最新バージョンになるほど情報が少ない。このあたりがRailsと違う。公式(英語)とか本体コードを読める人じゃないとつらい。

そもそもJava、というかJVM周りの知識がないと本番運用はつらいだろう。LL言語運用経験しかない人は特につらい。LL言語でいうhot deployみたいなことがしたい時のやりかた分かってる?

コンパイルの遅さに耐えて開発し、運用時のGC問題を乗り越え、黒魔術を味方につけてライブラリコードリーディングが出来るならいいんじゃないか

動作は早いし、言語のものは強力だ。

Scalaを好むプログラマ関数型やらDDDやら意識高い人が多い。別にScala自体にそれらは必須ではないけど、そこら辺を意識しないならJava8でいいんじゃないかとも思う。

Node.js

非同期処理で開発することの難しさに耐えられるの?

ベストプラクティスがなく、移り変わり激しいJS界隈に流されてオレオレで書いたコード保守する自信があるならいいんじゃない。俺はない。

Go

API単体ならともかく、画面も担う普通Webアプリを書くような言語じゃない。少なくとも今は。

正確に言うと書けないことはないけど、Webアプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットほとんどない。

ClojureとかElixirとか

運用実績ノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない

結論

完璧選択などない。

2017-05-31

ここで質問するのもなんだが。。。

jQuery最近知った。純正jsより便利だ。

じゃあjQueryを使わない理由ってなんだ?

【追記】

最近はReactでjQueryすら要らなくなるのか。

HTMLPHP+js+CSSで初めて勉強したころは、なんて不便なんだもっと便利にできるだろ

と思ってたけど想像以上に早い進歩だ。

web界隈はどこまで進化が進むんだろう。

きっとフレームワークで一つの言語で完結するようになると思う。

PHPとかHTMLとか死語になる日も近い

サーバーサイドフロントサイドはRubu,Python,Scala,の一機能しかなくなる未来が見える。

2017-05-25

Scalaが怖い理由

コミュニティレベルが高いとか、モヒカンが〜とかじゃなくて、なんか一瞬でScalaコミュニティのえらい人に捕捉される、監視されてるみたいな雰囲気だろ。

2017-05-24

http://anond.hatelabo.jp/20170524131734

使ったことないから知らんけど、KotlinScalaJavaの親戚だから仕方ないんじゃない。

C++をCと比べて説明するようなもの

LispJavaと比べて説明する奴はおらんだろうよ。

2017-05-19

コップ本 と scalaKotlinSwift と私

コップ本 を購入して数年経つが、未だに半分くらいしか読み終わっていない。

その半分もきちんと理解しているかどうか怪しい。 自分の頭の悪さに憂鬱になる。

一方、「 Kotlinスタートブック」 と 「Swift実践入門」 は理解しながら大体読み終える事ができた。

まず分厚さがコップ本とはまるで違う。内容も分かりやすい。

「その言語代表する入門となる1冊目」は大事だと思う。 おかげで KotlinSwift が大好きになった。

しかしこの2冊を、自分の中では比較的楽に読み終える事が出来たのは

その前に scala関数型の考え方に馴染みを作れたおかげだと思っている。

ありがとう scala。 でも scala はもう読みたくない。辛い。

Swift に関してはビギナーズ向けの勉強会が活発で初心者でも敷居が低い。

一方、scala は人が怖い。

もし今、自分scala案件に飛ばされたら、レベルの高い人たちの中でついて行ける自信が無い。

これからサーバサイドで Spring + Kotlin流行って案件が増えて、 scala の方は廃れていってくれたら嬉しい

2017-05-06

しかプログラミング一つにしても業界によって必要スキルは異なるわけだし、

Web系ならScala,JS,Ruby,ミドルウェアならC++,Java,システムならJava,分析ならPython,Ruby…)

会社必要になる知識漏れなく教えるなんてことは無理だと思う。

2017-04-22

http://anond.hatelabo.jp/20170422015216

言いたい事は判るけど言語スキーとしてはどれも書いててそれなりに面白さはあると思う。

判ってくると楽しい、みたいなやつ。

まぁ仰る通り保守性・可読性には一切寄与しないし「俺つえー」的な自尊心満たすだけかも知れないけどw

あと言語の多機能さとか演算子オーバーロードモンキーパッチ批判するなら Scala も入れといて欲しいかな。

あれも関数型ってだけでなんかありがたがられてる感あるけどそういう意味じゃなかなか酷い言語

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2016-11-20

エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase

http://futoase.hatenablog.com/entry/2016/11/19/155427

例示されている暴力はだいたい頭の悪い暴力なので反論できます

CGIには今の時代PHPを利用するのに、なぜ未だにPerlを使っているのか。処理速度も遅く、表現も難解だ。

では今あるシステム全部PHPリプレイスするとして、○人月工数必要ですがそのような予算はありません。

Go言語のもの表現力が低い。そんなものを利用するならJavaScalaで書くべきだ。ライブラリ豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。

ところでどうしてWindowsPCを開いてExcel文書作ってるのか教えてください。

Serverlessそのものサーバがなくなるわけではない。自身チューニングなど細かなリソース管理ができないPaaSを使って自身サービスの命運を預けるなんて馬鹿げている。

理屈の上ではオンプレミスIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。

みんな忙しいから結局何もやってないじゃないですか

iOSアプリのものプラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなもの技術をかけてどうするのか。

Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんものはチンケなものだ。そもそもUnityインフラエンジニアが覚えて意味があるのか。

流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか?

でも安心してください。すべてはUnity解決してくれます。そう、Unityならね。




とは言っても結局は私も暴力をふるう側の人間

例示された人たちに暴力ふるいたい。

windowsmacフロントエンドインフラ組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ!誰もお前がカバーしてない部分をサポートなんぞしねえからな!

ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ)

iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmaciphone買え(ios開発は何もかもmacxcode大前提

フロントエンドプログラマgo → goだけ使われても微妙。当然DBとの連携もあるんだよな?ん?(サーバサイドスクリプトDB連携のためにあるようなもの

サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから!(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも)

NintendoUnityインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityエディタ上で動くくらいを目標にすべきだ。

2016-10-14

GoScalaっておいしいの?

なんかいけてる感じ!

2016-09-22

低学歴Webプログラマーは何のプログラミング言語を覚えればいいの?

Node.jsってクソなんでしょ?

socket.ioとか使い物にならないらしいじゃん。

npmでインストールアンインストールできるだけの知識さえあればいいんでしょ。

じゃあNode.js覚える必要ないよね。

つうかNode.js使うならVert.xのほうがいいし。



golangを使えばいいの?

でもさほとんどの企業golang必要

5ページほどの静的サイトを作るのにgolang使ってる人もいるそうだけどPHPじゃダメなの?

コストかけてまでgolang使うメリットてあるの?

経営者から見たらエンジニア自己満足なだけで無駄に金払ってるようなものじゃない?

Webサイト運用している企業ってどんくらいあるのよ?

本当にgolang使わないとダメなの?

は?scala

結局、大企業なんて基本的にAラン大卒ネット界で知名度のある限られた人しか入社できないんだからgolangscalaも覚えるだけ無駄なんだよ。

個人利用以外で使い道がないから。

結局利用できる人が多いPHPWebサイトを作ればいいよね。

CLIツールだったらgolangpythonでいいでしょ。

javaとかcでCLIツール作るやつとか池沼でしょ。

人生限られた時間しかないんだから最善の選択をしていきたいよね。

2016-09-04

http://anond.hatelabo.jp/20160902031012

同じく情報系の大学に通ってる自分が同じようなことかもしれないけど書いてみる。

確かにIT系の本で難しい本は本当に難しいよね。プログラミング言語の一つで最近イケてるScalaなんかはコップ本という滅茶苦茶分厚くて難しい本があるし。

幼い頃からプログラミングしてたりしないとあんな本到底読めないよ。すぐには理解できないに決まってる。

ただ、プログラミングを少しずつでも学んでるにつれて読み返してみると段々分かるようになってこれが成長というものだなと思ってる。

あと、「情報系の大学に通ってるなら良いよね」とかよく大人に言われるけど大学に行ったところで自分の作りたいものを作れるようになれないよな。

でも身の回りでデキる人がいたりすればその人に聞いたりして作れるように近づくかもしれない。

残念ながら自分大学にはそういう人はいなさそうだ。もう少し世間で良いと評価されている大学に行けばデキる人にいつも会えるのかもしれない。

http://anond.hatelabo.jp/20160903140451

おじさんが滅茶苦茶いい記事を書いてくれてた。ただ、おじさんは現実を分かっていない。

出来ない人はインターンになんていけないよ。ちゃんと自分プログラミングしてモノを試行錯誤しながら作った人は評価されてインターンに行けるんだ。

自分試行錯誤しながらプログラミングして自分の作りたいものを作ってるよ。

どんなに出来るものはしょぼくてもいいからとにかくチャレンジし続ければいいことあると思ってる。

2016-09-03

Scalaにすっからー”

ぷぷ


Scalaにすっからー”との一致はありません。

マジかよ

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-04-09

Javadisられまくってるけど

というかOracledisられてると言った方が正しいのかもしれないけど、Scalaとかは今後どうなるんでしょうね

オワコンなんですかね

2016-03-24

サーバスペックが低くても負荷の高いサイト運用したい

何を作りたいかというとマルチプレイヤーブラウザゲームが作りたいんだよね。

phpsymfonyを使ってみたけど重い。

俺の開発用のceleron 1コアのメモリ1GB環境では重すぎる。

isoファイルを10000個同時にダウンロードしてるぐらい重すぎる。

ページの読込みがなかなか完了しない。

こんなクソ重いフレームワークはそれなりのサーバスペックがないとパフォーマンスに影響が出すぎるので除外したい。

phpフレームワーク一般に言えるんだけどプロジェクト毎にプロジェクトルートなかにフレームワークのコアファイルを置くのがなんか嫌だ。

railsdjangoのように分離させてほしい。

nodejsシングルスレッドなので負荷の高いサイトで使うのは厳しそう。

pythonでもgolangでもwebsocketは使えるのでnodejsにこだわる必要もないしvert.xを使う選択肢もある。

日本ではvert.xの話題あんまり盛り上がってないよね。どこかの企業さんが実践で使いましたって記事を書いたら会社の知名度が上がると思う。

scala,golang,elixirこの3つの選択肢でいいのかな。

でも負荷の高いブラウザゲームやってる会社ってrailsとかphpだよね。

railsphpでも問題ないのかな。

redisをうまく活用しとけばあんまりそれ以外でボトルネックとなるようなことって無いのかな。

艦これやってるdmmとかは何使ってるんだろうね。

スクエニさんのオンラインドラクエもどうやってるんだろうね。

あと海外ブラウザゲームってほとんどがaws使ってるのでaws使えばいいのかな。

でも怖いよね高額料金を請求されたらさ。

金儲けの為にサイトを作らないとawsは使ってられない気がする。

初めのスタートダッシュは定額制のレンタルサーバクラウドでいいか。

http://anond.hatelabo.jp/20160324100118

すまん、良く分かってなかった。

apt-get とかでscala入れたら普通にpythonなんかと同じ感覚で動くからそういうもんだと思ってた。

scala起動したらJDKなんたらってでてるの確認したよ。scala自体Javaで動いておるんやね。

こりゃまた失敬。勉強になったわ。

http://anond.hatelabo.jp/20160324095716

Java関係があるScalaってのはPlayFrameworkなんかの特定フレームワークの話

わかってる人が書いた文章とは思えない。

Scalaフレームワーク関係なく、バイトコードコンパイルされてJVM上で動くでしょ?

っていうかPHPシェルスクリプト大好きないつもの老害おじさんでしょ?

http://anond.hatelabo.jp/20160221104655

Scalaは単体でScalaであり、Java関係があるScalaってのはPlayFrameworkなんかの特定フレームワークの話だけどな。

ってか逆に単体でScalaを利用するメリットがほぼ無いってのは重要だと思うぞ。

訂正。scalaJVM上で動作するので、javaライブラリを使えるのはメリット

scala自体javaより大分シンプルコードを書けるので、それもメリット

存外便利かもしれんが、慣れないとそこはよく分からんかもしれん。

ワイはちょいと触っただけやった。

http://anond.hatelabo.jp/20160324095052

Scala「なんだかんだ言っておまいらもワイの仲間やと思うで。別に言語としての人気はなくても死んだりはしてへんで!」

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん