  |
はてなキーワード: javaとは
もっとも、Adobeは、Flashをブラウザ上からクロスプラットフォームのアプリ作成環境にまで成長させるつもりっぽいので、長い目でみてもFlashは形を変えつつ生き残るんじゃないかと思ってる。
でもそれ node.js っぽい気もしてきた。
なぜ両方使うという選択肢がない。真の技術者はウェブ標準だろうがFlashだろうがネイティブだろうが、その場その場でユーザーの体験を最善にし、クライアントの要求を最高に満たすベストの技術を使う。JavaScriptかFlashかなんて動きさえすればユーザーには関係ないんだから。実際、HTML5スゲＥＥＥＥＥ！！！ってページにFlashタグのブクマが間違ってつけられたりしてるよ？（笑） ウェブ標準の崇高さなんてパンピーにはわからんのです。
そもそも分からないんだけど、HTML5が「投資」するほどたいしたもの？ 誰もが基礎教養として身につけているはずの、これまでのHTML＋CSS＋JavaScriptの延長線上の技術でしょ。今まで普通にやってきたウェブ開発者ならすぐにキャッチアップできるはずだよ。
どうせHTML5の実装の普及には当分かかるし、その時点のブラウザ環境で使用可能なものをゆっくりまったりと導入していけばいいだけ。その意味ではいわゆる遅延評価学習で十分。あわてることはないです。どうせ皆使うことになるんだから。
一応言っておくと、いいものだと思いますよ、HTML5は。現段階で頑張って凝ったものを動かしておられるイノベーターの方々もたいしたものだと思います。敬意を。マリオやらグラディウスやらは著作権的にどーなのかと突っ込みたいが。
それはシナリオのひとつですよね。Googleの甲斐性次第では十分にあり得る。それと、ジョブズが翻意するというシナリオもありますよ。今までに散々あったことですが。どこかでそれをネタにしている記事があったと思いますが。
もしEdgeを見てそう思ったのなら、Flash CSを使って制作したことがありますか？ Edgeを実際に使ってみましたか？ と問いたい。
他にも、最低でも、
これらにきちんと答えられない人間にHTML5 vs Flashなど語る資格はないです。そもそも対立させる時点でわかってないなー ┐(´д｀)┌ って感じなのだけど。
あとFlashへの投資が無駄になると思ってるようですが、俺はFlashは投資判断「Buy」継続だと見てますよ。たとえこのままiOSで動かずともね。AIRもあるし、ブラウザのプラグインとしてのFlashだけ見ていると考えを誤るよ。ブラウザのほうにしても、GPUアクセラレーションつきの3Dが真っ先に使用可能になるのはFlash。プレイヤーの普及が速いから、WebGLと異なり、今後1～2年内に実案件で使用可能になるでしょう。そういった面ではなおカッティングエッジな技術だよ。
まあ、プラットフォームや言語の選択は投機だから、どの銘柄が買いか売りかで紛糾するのはわかる。ただ、それなら分散投資だとか、インデックス投資という考え方もあるのでね。HTML5に惚れ込んで一点買いなんて若いエンジニアがいたら、それはもう相当危なっかしいなと、視野も相当狭くなるだろうなと危惧するよ。
というか、JavaだろうがC++だろうがObjective-CだろうがLLだろうがアセンブリ言語だろうが関数型言語だろうが、一度全部触ってみなよ。いいから。HTML5で手一杯なんてのでは話にならんですよ。
今、海外IT系企業に所属しているのだけど、日本の求人情報のいい加減さにはうんざりする。あれで人を集めたいと良く思うな。部下というより、子分が欲しい感ありあり。結構有名な人でもそういうことをするんだよな。「一緒に未来を目指せる人」とか一行もいらない。
海外じゃ、あれは通用しない。元々スキルも出生もバラバラな人を雇う前提なので、事前の要望を明確にしておかないと、採用活動自体が無駄になるから。LinkeInとかが、スキルと経験をきちんと書けるよう設計してあるのも、そのため。日本の求人ではグローバルは目指せない。
以下に、(自分視点だけど)望ましい例をあげる。
人によっては「箸の上げ下げ」と思うみたいだけど、海外の求人はこれをやっている。なんでこれを求めるかというと、創業者や社長というのは、制度設計者だから。自分の掲げた目標(「求人情報を扱うSNS構築」とか「ARを利用したソーシャルゲーム」とか)を実現する為に人を雇う訳で、これが書けないうちに人を雇うのは、目標とそれに準じた制度設計が出来ていないと看做されても仕方ない。海外で成功している事業者は、目標設定が明確。Googleにしたって「世界中の情報を整理する」というミッションはあるけど、実際のプロダクトがあるから説得力を持つし、人を集めて使う事も出来る。
とくかく、目標に準じた制度があり、その制度を動かす為の求人がある。それがわかってないで人を集めると、気のあう人か、そうでない人かでかなり成果が違ってしまう。そうすると、ミスマッチが起きるので、双方に不幸が訪れる。要するに「書かなくてもわかるだろ」を意地でもはっきりさせるということ。コンサルなら得意なことなんだけど、それ以外の人は結構できない。
もちろん、求人は解雇制度を関係があるので、一概にこれが日本で適切とは言えないかもしれない。でも、不幸を避ける為の事前の策は多い方が良い。
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
多分、==と=の話をしているんだと思う。
比較に使うはずのif文の中でも代入できるのはバグの元だよねーって話。ちなみにjavaでもCでもif文の中に代入は存在できるので、そういった意味でどっちも優れてない。
Javaの場合、エラーにならないのはbooleanを代入した場合だけ。つまり、condというboolean変数があったとして、
if (cond == true) {}
if (cond == false) {}
のような書き方をしたときだけが代入にしてしまうミスが発生するわけ。
でもそんな書き方はありえない。condがbooleanの場合の通常の判定文は
if (cond) {}
if (!cond) {}
のように書く。だからJavaでifの条件式に代入を書いてしまってミスることはまずない。Cと比べて一緒というのは明らかにJavaをわかっていないと思う。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
CIツールを使って、常にcheckstyleでも走らせておけばいいんじゃないかな。今時、そんなのは人間様が労働力を割かなきゃいけないお仕事じゃないよ。
残りの「不注意やミス」をなんとかしたいなら、それこそ「高機能な」言語を使うべきだよ。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
横だけど、これ何の話してるんだろ？
つまり、「生産性の高い言語」は、人間の不注意やミスを言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。
これを無邪気に言い放つ人とは一緒に仕事したくないわ、とだけ言っておきますよ。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
そこに意識的にならないと、そもそも議論の出発点にすら立ってない。
Javaの場合、ユーザのフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
つまり、「生産性の高い言語」は、人間の不注意やミスを言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
Cで開発してるチームなら絶対に持っている、自前のライブラリ群や
それらが十分に品質が高く、容易に利用できるものならいいんじゃないかな。
Javaの場合、ユーザのフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。
「素性の良い言語」に求められる性質は色々あるけど、一つは、モジュール同士を疎結合に保つための機能が備わっていることが挙げられる。つまり、「理解していない人」がエンバグしても、その影響範囲を最小限に留められるということ。これが、機能追加やデバッグ時にどれだけありがたい性質であるかは、多くのプログラマに同意してもらえると思う。
大規模なコードになるほど、一人の開発者から見てブラックボックスになる部分が増えるのは避けられないこ。Javaの言語機能を適切に使えば、手に負えないバグを埋め込むことを回避しやすくなる。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
あなたは、その解決を「生産性が高い言語」だけでしか話していないけれどね。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
Cで開発してるチームなら絶対に持っている、自前のライブラリ群や
それだけでメッセでイベントが開催できるほどの開発ツール群はすべて無視して、
関係ない。
生産性が高いと言われてる言語で行われた、ゴミみたいなプロジェクトは沢山ある。
生産性の高さが生かせると言うのは、設計からしてきちんと考えられていると言うことで、そういうチームが開発するなら言語は関係ない。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
まさかだけど、「Cで１からすべて書く」ことと「Javaの開発済みコード群を使う」ことを比較してたりとか、
「Cで行うテキストエディタとコマンドラインコンパイラのみの開発」と「Javaで行う高機能開発環境での開発」を比較してたりとか
本題とはあまり関係がないけど、そういうことも開発生産性の高さに貢献しているのも事実。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
関係ない。
生産性が高いと言われてる言語で行われた、ゴミみたいなプロジェクトは沢山ある。
生産性の高さが生かせると言うのは、設計からしてきちんと考えられていると言うことで、そういうチームが開発するなら言語は関係ない。
まさかだけど、「Cで１からすべて書く」ことと「Javaの開発済みコード群を使う」ことを比較してたりとか、
「Cで行うテキストエディタとコマンドラインコンパイラのみの開発」と「Javaで行う高機能開発環境での開発」を比較してたりとか
Cで管理できるチームならJavaでも管理できる、の間違い。逆は真ではない。
プロダクトに関わる人数が増えれば増えるほど、言語自体の素性の良し悪しが生産性に大きく響いてくる。
横だが、アホくさい。
というか、C言語で書かれてメンテ不能に陥ったガラケーが、Javaで書かれたAndroidに駆逐されている点について、誰も指摘していないのが不思議。
Javaで管理できるチーム、もしくは個人なら、Cでも管理できる。
あとな、ガラケーの開発がCって、それどこの開発をさしてんの？
C言語にこだわるのは良くない。けど、パフォーマンスを上げ、他社のプロダクトに勝つタメにはCは必須。ネットワーク、描画系はjavaの何倍も処理速度が変わるのを忘れてはならない。
既に本人から突っ込み（「Javaの方が早くなるケースは多い」）が入ってるけど、たとえ多少遅くなったり、それを補うために値段の高いチップを積まなくてはならなくなったとしても、プロダクトの開発生産性が上がることで、総合的には製品力の強化に繋がる場合だってあるわけでだな。
というか、C言語で書かれてメンテ不能に陥ったガラケーが、Javaで書かれたAndroidに駆逐されている点について、誰も指摘していないのが不思議。
カーネルコミッターでも、処理系実装者でも無さそうな人達が、「Cは滅びず！」と叫んでいる不思議な光景。
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5545216280/c
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5603961294/c
Linuxカーネル（せめてPOSIX互換品)を手前が思う言語にさっさと移植すれ。さすればCを滅ぼせん。（ちなみに高機能アセンブラの最適解がCとは俺も思っちゃいない。）
最後のＣの牙城、Linux（ＵＮＩＸ）をＪａｖａなり何なりベターな言語にさくっと移植してくれ。それともgoogleビッグブラザー様がクラウドでＵＮＩX鯖を駆逐してくれるのを祈ってればいいのか？
JavaもC#も，それにPerlもRubyもPythonも，実行環境自体はCで書かれている件。コンピューターが「シリコンを基材としたチューリングマシン」であるかぎり，アセンブラとCは滅びない。
まぁ、タイトルの「レガシープログラマ」とは私の事なんですけどね。
if( foo == TRUE ){
という判定文をよく見かける（fooはいろんなオブジェクトだと思ってほしい）。
個人的には、この書き方、嫌いなんだよね。
if( foo ){
か
if( foo != FALSE ){
と書いて欲しいわけよ。とにかく「TRUEか？」という判定にはして欲しくないわけです。
で、なんでこう書くの？と外注や若い連中に聞いたら、「TUREは1ですから」と必ず答える（断言する）。
あ、あれ？？？自分は「TRUEはFALSEでは無い。確定しているのはFALSE=0という事だけ」だとずっと思っていたんですわ。
古いC言語風に書けばこんな感じ。
#define FALSE 0 #define TRUE (!FALSE)
確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。
新しいC++や規格ではBOOL型というのがきちんと定義されたと思うけど、製品寿命が20年とかいう私の職場では、DOSやC(K＆R)、アセンブラは現役だし、プラットフォームもなにもWindowsに限らない。組み込みマイコンも使う（うちのところはVxWOKSだが）し、UNIXやLINUXも使う。
もちろん、マネージドC++（.netFramework)やC#、JAVA、Parlも私は使うし。でも、どのプラットフォームでどの言語になっても「TRUEか？」という判定文は使ってこなかった。
で、試しに、VC2008のincludeフォルダをgrepしてみたら、
#define TRUE 1
あ、ほんとに「1」だ。
typedef bool int
なんて見かけるから、やろうと思えば「5」でも何でも数字が入ってしまうわけですよ。そこで「== TRUE」なんてやられたら、絶対に成立しないわけで。バグの温床になるんじゃないかなー、と思ってかたくなに前述の姿勢を持っていたわけです。
今（最近の）言語はきちんと「BOOL」型（またはboolという名のクラス）を定義されていて、コンパイルエラーになるか、自動的に補正してもらえるのかもしれないけど、ちょっと気持ち悪い。
最近、ちょくちょく外注や若い連中と意見や話が合わず、「ああ、俺ってレガシープログラマなんだな」と思う事が多くなった今日この頃。ネットワークに平気でリトルエンディアンのデータを流すとか、勘弁して欲しい。LANアナライザでデータが見にくくてしょうが無い。