「クライアント」を含む日記 RSS

はてなキーワード: クライアントとは

2016-06-25

Instagram広告

ナイキとかUNIQLOとかメルカリかいうやつの広告がちょいちょい挿入されるのはまぁいいかと思っていた。

でもなメチャコミ(はてなだったら許容できる)だけは無理だわ…。伊勢丹Tポイントカード導入したくらいの嫌さ。せめて元のイメージに合うクライアントにしてほしい。それが難しいならイメージにそぐう広告を作ってほしい。電車の中で見たいのに見るのが憚れる感じ。tumblrotsuneさんをフォローしていた頃を思い出した

2016-06-24

無能の人

私の言葉をさえぎって注意してくる人がすごく多い。



私「クライアントが◯◯と言ったので…」

A「それは■■って答えなきゃだめだよ」

私「ええ、■■って答えましたよ」



いつもこれ。

ちゃんと対応してるのに、無能の人あつかい

いろんな人にこれされる。

何がいけないんだろうか。



私が「できない人」っていう前提が相手の中にあるからかな。

地味にしんどいわ。

2016-06-21

未練

https://twitter.com/miraihack/status/745059267535765504

ストーキングにならずに静かに待つ。

忍耐力が試されるけれど、これも自分の試練だろう。

ヒロイズム自己陶酔したりはしないが、まだ人を信じることは出来た。



https://twitter.com/miraihack/status/745068110076510209

ちなみにいま周期的に生理前でして、以前私の交友関係について

PMSの苦しさを男はしょせん理解しきれないだろうと思う - 接客業はつらいよ!のように書かれたことがありまして、

生理前が落ち着くと状況も少し変わってくると信じている自分がいます



https://twitter.com/miraihack/status/745095191313276928

いま病院で待合中。私の友人や知人の約10人くらいほぼ全員に、

私は断捨離されたのでこれ以上深追いしたり待ったりするのを諦めて別な女性仕事に没頭した方が良いと勧められましたw

帰宅してから少し寝て頭を冷やして考えるようにします⊂二二二( ^ω^)二⊃



https://twitter.com/miraihack/status/745102212133621760

でも今の時期に私を断捨離して良いんだろうか。

ピルを飲んでいたしお互いにできちゃった結婚に流れ込むのがいい」という話になっていたので特に何もアレだったのだけど、

飲み忘れは無くて生理前になったのかな。

妊娠したら喜んで責任をとるつもりでいたけどその点が心配。もちろんその時は認知する。



https://twitter.com/miraihack/status/745104430018617344

何の連絡もないから連絡が来たら考えるか。

「お互いの安心のためにお互いに検査を受けよう」という話もまだ実現されていないけれど…。

3か月あったので何かの病気であっても既にという状態

「その時はうつされても良い」と言われていたけど、私の検査を待たなくて良いのだろうか。



https://twitter.com/miraihack/status/745135575112421376

実は今日相馬実家一時帰宅する日だった。

「来月から交際している女性と一緒に東京暮らします」という話を持ち帰る予定だったけど、

蜃気楼のように消えてしまったのと昨日までの疲れがあったので、土曜日に延期させてもらった。



https://twitter.com/miraihack/status/745143023252561920

ごめんなさい、誘惑に負けて元彼女電話してしまいましたw 

「お留守番サービス接続します」だったので、

留守電「色々迷惑掛けてゴメンね。生理の方ちゃんと来ているかな?来ていなかったら連絡ください」

伝言を入れてしまった寝る直前のお昼。



https://twitter.com/miraihack/status/745154505302409216

ます。いつも寝元には彼女から「今からそっちに向かうねー!」

電話が掛かってくるかもしれないとスマホを横に置いて寝ています

そういう時に起こしてくれるのはクライアントおっさんだったりしますがw

2016-06-20

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

この記事を読んだ。

http://anond.hatelabo.jp/20160619185731


COBOLエンジニア、現Rubyエンジニアとして増田記事がどうしても許せなかったので反応してみる。

この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。

汎用系の現場でもRuby現場でも優秀な人はたくさんいたし。


今では信じられないほどの経験を当時(といっても2年前)はしていた。

改めて今、RubyというかRailsを始めてよかったなーと思う。

そこで僕が経験した糞だった現場をご紹介したい。

(もちろん業界特有ということもあると思うが)


インデントは定規で計る

いやー、これが一番ひどかったな。

まず静的デバッグ(机上デバッグ)といってコンペアファイルソースコードコンパイルログをそれぞれ紙出しして提出用(クライアント)、リーダー上司用の3部印刷する。

全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。

1セットあたり印刷に15分くらいかかったかな。


そしてインデントレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。

媒体のインデントをどうチェックするかって?

定規で計るんだよ。半角スペースが5ミリだったっけな。

それで5ミリずれてたら指摘するんだよ。目がつかれたよね。

っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。



ログを紙出ししてマーカー塗る専属社員がいた

これもびっくりだよね。

専属社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。

ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。

大卒の、しかも僕より先輩の社員たちだったな。

そんな人達サービス残業しているのを見て悲しくなったよね。


ネットは使えない。リファレンスは紙媒体(常に貸出中)

これはクライアント金融特有なんだと思う。

ネットは使えない。現場に入る時も持ち物チェックとかあるしな。

リファレンスは紙媒体だったよ。

でもセキュリティ観点からマスターの1冊のみ。

常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。



まだまだあるんだけど、これだけでもひどい現場だったなーって思う。

そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。

最後の方レビュー適当なって品質下がってバグ生んでたし。

Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。

それでも、やっぱりRubyのほうが未来があるよ。

この先もっともっとブラックボックスフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。

認めたくない気持ちはわかるけど、時代エンジニアも合わせていかなくちゃいけないんじゃないかな。

Photoshopファイルを納品したらレイヤーのいくつかにクライアント悪口があって指摘されて

あれ俺いつこんなの書いてしまってたんだろう・・・っていうオカルト話は意外と多い

2016-06-19

ソシャゲの片隅で

ソシャゲの片隅で。ホントウソかの判断貴方におまかせ(笑)

ソシャゲ宣伝にとてもお金がかかる

 目立とうとおもうと、ソシャゲ大作の開発費と同レベルお金が飛んでいく。ゲームの出来が良ければ宣伝に金かけるだけの価値があるが、良くなければ只の悪夢。でも、宣伝しなかったらどんなに良いゲームでも人の目に触れず、開発費用回収すら困難になる。

ソシャゲは金払う人はほんの一部

  そもそも金払ってくれる人はそのゲームDLしてくれたユーザの数%。ただ、この人たちの異常な金の払いっぷりで、全運用費用運用スタッフ宣伝費、インフラ代金、開発費用借金全部を余裕で返済できるだけのお金が集まる。このあたりがほんとに異常。こみ隊長がいうようなガチャ規制入ったら、ほぼ全員(トップセールス10常連ですら)思うように金稼げなくなって一気にソシャゲ業界終わる。

宣伝リリース完璧でも...

 宣伝タイミングが事前実施リリース実施でとにかく金ぶち込みまくって理想的にやれたとして、初動1週間の1日あたりのプレイユーザ数を上回ることが出来るゲームはきわめてまれ(正直居ないかもと思わざるを得ないレベル。)スマホの上位5位ぐらいのトップレベルセールス常連らの1日あたりのユーザ数は、まあ業界的に今後二度と起きないと思った方がいいレベル奇跡

大作レベル資金を渡しても、資金にみあったクオリティソシャゲをちゃんと作れる会社まれ

 とても多くのデベロッパが十分な資金時間を渡しても、正直詐欺といわれても仕方がないレベル成果物しか出せない。なので、大作のソシャゲ開発はとてもリスクが高い。リスク要因考えるだけでも、サーバ技術ダメクライアントアプリ技術ダメ音楽・サウンド・挿入アニメダメグラフィックダメPM/ディレクションダメ会社ダメ(笑)等など、ダメになる要因洗うだけでも、沢山ある。まあ当たり前の話、自分で全部ちゃんと出来るなら、その会社自力ソシャゲ出して只のデベロッパからはすでに脱却してるはずだから当然といえば当然。胴元というのは、いつの時代でも、有利で儲かる立場なんで、誰でも胴元になりたいよね?

RPGしか正直金にならないか

 今の所、RPGは、ユーザらがゲーム中でソコソコわかりやす継続的に何か作業がやれる上に、ゲーム運用側も作業量収入バランスやすいから。なので、結局ソシャゲ業界RPGばかりになる。なお、ユーザのやれることいっきに増やそうとして、いわゆるMOオープンワールド系のゲームにしちゃうのは、相当にゲーム設計運用ノウハウがないと無理。オープンワールド系は運用ノウハウが無いと、ユーザがすぐに何していいかからなくなるので、結局ビジネス面で詰む。

マルチユーザの対戦なんて

 ソシャゲ運用から見ると、マルチユーザの対戦の機能なんて、正直、肉料理についてくる前菜サラダぐらいの価値しかない。無いとソシャゲの見栄えが寂しい一方で、開発は技術的に難易度無駄に高い上に、1日に遊ぶ全ユーザの2〜3割ぐらいしか遊んでくれない。しかゲームのメインにしようものなら速攻ユーザが逃げる。この場合悲惨で、残ったユーザガチ勢ばかりになって益々初心者入ってこなくなるわ、結局ガチ勢もいつも同じ面子ばかりと対戦になり正直飽きて継続しないわで、たちまちゲームビジネスが詰む。実際ユーザの遊び方を計測しても、正直実はみんなシングルプレイで十分なんだろ?と思う行動ばかりのご様子。正直頭痛い。ただ、ある程度のマルチユーザの対戦機能があると、新規ユーザ獲得に役立つ(プレイヤー友達誘う正当な口実になる)気がするのと、高課金者らが継続的に金を突っ込む為の理由の1つにできるかもしれず。また、対戦を口実に運営施策が入れやす場合があり、結果、ゲームの盛り上げ感を出しやすいかもね。ゲーム運用からは、費用対効果の面では、無いと寂しいが、頑張ってみてもいいとこ無しという機能

1年程度で十分な利益を出せる状況にならなかったら閉じるしかない

 ちゃんと宣伝しているのにいまいち売れないまま1年もたっちゃうと、どう宣伝しようが、何しようが、ユーザほとんど反応しなくなる。同時に、ソシャゲ流行りも変わるので、結局詰む。こうなったら借金精算して、次行こ、次!

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

http://anond.hatelabo.jp/20160614230825

は?なんでわざわざクライアント用のlinuxOSの名前理由なんて調べなきゃなんないんですか?

そもそも何が言いたいのかよく分からない。

もっとはっきり書いてくれる?何が言いたいのか分からない

何をどう調べてないの?

コミュニケーションってそういうもんでしょ?

2016-06-12

http://anond.hatelabo.jp/20160612112533

・隣の「まとめ役」より偉い人がいれば、その人をターゲット

 (最終的に、まとめ役の上席に伝わるように、その前の順番(社内の序列人間関係)を間違えずに)共感を積み重ねる、根回しを積み上げる。

 で、異動なりなんなりをお願いする

・被パワハラさんのお友達になってやる

自分が、別の場所パワハラ声が聞こえない部署など)に異動を申し出る

会社をやめる



ぐらいかな。

音声の証拠を集めたところで使う場所がなきゃ意味がない。

それに、録音するのなら、被パワハラさんへの同意も得るべきなので、単なる正義自己満足しかないと思う

クライアントを、社内のみっともない事情に巻きこむのは、みっともないからやめた方がいい。マジで

へたしたら会社の信用度にかかわる。



残念だけど、増田には、今のところはまだ、この問題解決する能力はないのかも。

諦めるか、逃げるか、踏ん張って社内政治をやって解決させるか。お好きな道をどうぞ。

プロカメラマンレタッチ写真現像と加工について

http://b.hatena.ne.jp/entry/s/medium.com/mediumjp/2b0da4969e65

ここのブコメを見て危機感を覚えたのでちょっと書く。

だいたいはここらへんのコメント

id:koiz アメリカでは、光を思いっきり入れたクリエイティブが求められることが多い(特に西海岸だし、スイムウェアは)。自分センスで左の方がいい!この写真家はクソ!ってなる人がrawデータを貰いたがるタイプなのだと予想

id:Memeo このレタッチ写真屋が勝手にやったんじゃなくて用途デザイン案に従って仕上げたもんなんじゃない?/ カレー作って今からルー入れようって時に「もうそれでいいから食わせろ」と言われても困るだろう。

で言い表されてると思ったんだけど、スターを集めてるブコメでは誤解が解けてないようなので。

まず、カメラマン仕事理解していないひとが多い。カメラマン写真家と違って、クライアント要求にあった写真を撮るのが仕事なんだよね。「フレアがわざとらしい」とか「レタッチ前の写真のほうが好き」と言っている人は、カメラマンじゃなくてクライアントセンス文句をつけている。

次に、本文でも親切に「レタッチを前提として撮っている」と書いてあるように、レタッチは下手な写真ごまかす手段としてではなく、クライアントの望む理想的写真を作り出す手段として使っている。「RAW現像を前提としてあえて暗めに撮っておき、現像時に明るくすることで暗部の階調を残す」というようなテクニック常套手段。なのでレタッチ前の写真が下手という指摘は外れているし、そういう誤解があるからこそ元データを納品したくないんだよ。

記事カメラマン立場からRAWデータを渡せない理由説明し、それでもクライアント不利益が少ないことを説明して理解を求める内容。「RAWデータは作りかけのもの自分名前で世に出したくはない」「そのことでクライアント不利益が生じないようきっちりと仕事をしているので、理解してほしい」「しかカメラマン側も事前に契約を詰めるなどの取り組みは必要」という流れ。その流れを踏まえてブコメを読むと、とんちんかんブコメがかなり多いことがわかる。

いわゆる写真の加工に対して、アレルギーを持った人が多いんだろうなと再認識させられた。身の回りにある写真ほとんどが加工済みだし、iPhoneで撮った写真でさえ元から強烈な補正がかかってる。ここまで写真が身近になった今だからこそ、写真現像レタッチについてカメラマンからも発信していかなければならないと思った。


以下コメントへの突っ込み

id:toksato 結局なんでレタッチ前の写真を渡さないのかよくわからなかった。

本文中に"レタッチが終わるまでは、自信を持って「自分作品です」とクレジットを付ける気にはなりません。"って書いてある。

ただ、元記事は「レタッチデータを渡したくない理由」「レタッチデータを渡す必要が無い理由」「同業カメラマンへの提言」がまぜこぜに書かれていて、主旨が読み取りづらいとは思う。

id:Akamemori お前それフィルムカメラでも同じ事言えんの?

ブコメで多数指摘されてるけど、銀塩時代も加工の技術はあった。現像プリントの段階で、色味やコントラストシャープネス、粒状性は変えられるし、覆い焼き部分的な明るさを変えることもできる。デジタルで幅が広がったのは確かだけど。

id:atoh 契約時にきちんと詰めろってだけの話だった。

id:aromabird 契約次第としか中間制作物も納品義務のある契約なら納めるし、無ければしない。別料金。ただそれだけ。

本文で"撮影の前には、契約が成立しています。""これは、プロカメラマンである以上、事前にしっかりと内容を詰める責任があります。"ときっちり書いてある。このコメントに星が集まってるのが理解不能なんだけど、みんな本文最後まで読んでないの?

id:nasuhiko レタッチっていうかほぼRAW現像の話だろこれ。翻訳者がわかってないのか、それらも含めて原文がレタッチって言ってるのか。プロでさえ1枚のベストショットの背後に何十何百という失敗ショットがあるのは同意

海外の"retouch"は現像も含めた写真の加工全体を指す。"no retouching"なら、撮影後いっさい手を加えていない写真のこと。

id:kazoo_oo 追記でぐだぐだと契約だなんだ言い訳してるけど、前段ではそのrawファイル自分より優れた現像者に出会可能性を潰すことの理由説明できてないよね。 </bockquote>

これは文章の読み取り方の問題自分よりも優れた現像者に出会可能性は潰しきれないが、カメラマン側の能力で相当小さくしている。カメラマンの被る不利益との天秤で、原則RAWデータを渡すことはできない。ただし信頼関係契約次第で対応することはできるというのが本文の論。

IT業界クライアントが「あとで使うから作ったソースコードや旧バージョン全部ちょうだい」って言ったら普通に断られると思うんだけど、それと同じ話。

id:jassmaz jpegだけ送られてきたらキレるわ。rawファイルもいらない。psd + pngを送るのが常識では?

psd+png常識というのには同意。その上で、クライアントが求めるものはまちまちなので、契約をしっかり詰めておきましょうというのが本文の内容。

id:oscdis765 これ右がレタッチ後なんだよね?左のが良いのが沢山あるんだけど

id:mfigure 上手けりゃ、原版渡せとは言われないでしょ。加工後の方が上手いといえない写真が多いんだけど、よく言うわ。

id:kantei3 思いあがっている。あと、左の方が良い写真が多いので、都合のよい例すら選べない低能なんだな、と。

id:paradisemaker いやー、商売が成立してるんならいいけど、元々のカメラの腕が良くないし、レタッチもそれほど上手くない。デジタル時代カメラマンって感じだなぁ。

この手のコメントが多いのが本当に悲惨使用イメージが頭にあるクライアントカメラマンと話しながら詰めた結果、右みたいなタイプ写真希望にあったというだけ。あなたたちがどっちがいいと思おうがまったく関係ない。仕事で右みたいな写真が好まれがちだからこそ、private workもそういう味付けにしてポートフォリオとして公開しているんだろう。

デジタル時代カメラマン」ってのがよくわからない。フイルム時代、大多数の人が見ていた写真は加工の入ったプリントと、よくて現像済みのネガぐらいで、RAWデータに相当する未現像ネガは見られなかったはずなんだけども。

id:zheyang う~ん、今でも撮影時に設定を絞り込んで、レタッチを最小限にしてる人もいるんじゃないか?/作例のレタッチフレア)がわざとらしくてCGくさい。この人の写真家としての腕がちょっと怪しい。

写真家カメラマンは違う。「写真道」でも極めるならともかく、クライアント希望に適う写真を納品するという立場において、レタッチ忌避する理由はどこにもない。最高の成果物を納品するためには、「撮影時に設定を絞り込んでレタッチを最小限にする」より「撮影時に設定を絞り込んだうえでレタッチで仕上げる」のほうが良いというだけ。フレアがわざとらしいとか、クライアントに言うべき。

id:xevra くだらんこだわりだ。写真家カメラマンは違う、カメラマンならとっとと出せ。単に現像スキルに自信がないってだけなんじゃないの? 面倒臭い奴に発注するのはやめたい。

5000枚の未選別データを欲しいならそうするけど、それには相互信頼関係必要だし、契約段階から要求しておいてほしいという話。

id:aceraceae いらないとこ白飛びさせるの好きな人なんだなってことがわかった。

この人の好みもあるかもしれないが、クライアント希望にもあっているからこそそれで納品されたんよ。あと向こうの雑誌広告ちょっと見ればわかるけど、こういう派手でやり過ぎっぽい写真はかなり好まれてる。

2016-06-10

http://anond.hatelabo.jp/20160610084553

2011年ガラケーのピークで

それからは高機能スマホシンプルガラケーという住み分けがなされるようになったために

新機種が出ても従来ほどの機能はないようになった

Wi-Fiテザリングクライアント対応PCサイト表示ができなきゃ話にならないとおもいスマホに変えたのが2年前

2016-06-07

業界小話(コンサル編)

業界小話系に乗っかってみよう

訪問契約率20%のブラック企業の真っ黒な営業手法を書いてみる

http://anond.hatelabo.jp/20160526110823

・なぜ家電量販店で凄まじく値引ける(ことがある)のか教えてやる

http://anond.hatelabo.jp/20160412234807 

リフォーム業者営業が仕組みや値段について書くよ

http://anond.hatelabo.jp/20160531150129

MとかBとかの外資系有名ファームでないけどわりかし有名なファーム経営コンサルタント

30代のマネージャー営業プロジェクト推進の両方をやっている。

コンサルとは

コンサルタント資格不要で名乗ろうと思えば誰でも名乗れます

なので様々な仕事コンサルタント存在しています

他のコンサルは知りませんが、経営コンサルタント簡単に言うとアドバイス業です。

学術情報であったり、他社事例であったり、自社ノウハウなどクライアントが知らないことを教えることが基本です。

ただし、知識をそのまま教えるだけではダメで、クライアントの状況を斟酌しながらカスタマイズしていくことが生きていくポイントです。

営業のやり方

弊社は基本、問い合わせとセミナーから営業活動が主流です。

問い合わせを増やすために、書籍記事執筆、講演などで会社名前自分の顔を売って問い合わせを狙います

また、自発的セミナーをやって見込み顧客を作っていき、手法説明業界情報などを餌に訪問して提案につなげます

成功率としては問い合わせの方が良いのですが、こっち思い通りには行かないので自発的営業します。

何度か訪問させてもらって意見交換して提案という運びになります

設備などに比べて効果がわかりにくいので提案・交渉の回数は多くなりがちです。

プロジェクトお金

見積基本的に人工です。活動を為すために必要人員と単価表で見積もります

社内で以下のような単価表があります(例はフェイクです)

クラス 単価
アシスタント 200,000
シニア 400,000
マネージャー 600,000

日数はクライアントへの訪問日程だけでなく作業日程を含めるルールですが、最近競争力が落ちてきたせいか作業日程分を取れない場合が多いです。

クライアントへの訪問日程は提案書に明記せずに総額で交渉します。

外資系に比べれば安めですが、コンサルを使ったことの無い企業では結構値段に驚かれます

交渉としては、値下げの幅にも寄りますが単純な単価の減額や日数減は行わず対象範囲を狭め結果として訪問日数を減らす方向にします。

プロジェクトの話

受注したら晴れてキックオフです。

アシスタントも引き連れてキックオフして、メンバーと具体的に進めて行き、適宜Pjtオーナーに報告しながら勧めていき、最後に報告会を行うのが一般的です。

進め方はテーマクライアントによって大きく異なり、先生となる指導型、プロジェクトメンバーとなり一緒に進めるを分担型、クライアントの手足となって作業をする請負型などバリエーションが有ります

弊社は割とタスク分担で進めて行くパターンが多いです。指導型は楽なのですがクライアント能力によって活動が進まなくなるリスクが高いので近年は少なくなりました。

請負型はクライアント次第な部分もありますが、好かれていません。

コンサル説明でも書いたようにあくまアドバイス業ですので、活動の結果にはコミットしません。

我々のアドバイスイマイチ場合もあるにありますが、成果が出ないときお客様活動量が圧倒的に少ない場合が多いです。

結構コンサル入れれば安心。後はコンサルがやると思っている方が一定数いらっしゃいますが、成否はむしろPjtメンバーにかかっていると思い直してもらいたいです。

アウトプットが定まりにくい内容のため、炎上リスク結構ありますので上手に着地させることも結構重要な力量です。

コンサルお金

弊社では固定給年俸に分かれます

若いうちは固定で、ある職位以上に上がると年俸制シフトします。

固定給でも成果や評価賞与金額にバラツキが出ますが、事業会社と同様で倍半分の世界にはなかなかなりません。

年俸制になると、売上比例なので売上が立てば立つだけ給与が増えます

年俸制は30台の前半から適用され、平均値としては1200-1500程度です。

弊社はトップファームに比べると一段階給与が安くその不満が社内には結構あります

客観的に周りのファームに比べると業務時間が短かったりするので、時給計算は悪くないと私は感じています

比較対象にもよりますが、やはり30代で1000万が比較的容易に出るので悪い給与では無いと思っています

終わりに

コンサルって全然違う世界に見えるようで、普通営業さんやシステム屋さんと同じようなことをやっている世界です。

ただし、投資も少ないし、少数精鋭なので給与が高いということです。

ご参考になれば幸いです。

2016-06-05

TSUTAYA DISCASメールの古い仕様を直さな

TSUTAYA DISCAS(以下、Tカス)のメールヘッダのDate項目の仕様が古いため、

Tカスから来るメールの日付がWebメーラで正しく表示されない。

ちなみにWebメールは、さくらレンタルサーバさくらメールボックス

原因は、RFC5322の4.3章「Obsolete Date and Time」。

これが新しいもの対応していない。

Tカスには前に問題を報告済み。

しか問題が起こってない、と言うことで対応しないとのこと。

こんなに頭と対応が悪いとは思ってもみなかった。

さくらメールボックスは動作が軽いので使っているが、クライアント側でなんとか対応できないか考えているがいい案が浮かばない。

クソッ!

2016-06-04

一番のつっこみどころは

黎明期からツイッターをやっている」のにクライアント一時的に #ntv #kinroとかの実況タグミュートすることすら知らないことじゃないだろうか。

http://anond.hatelabo.jp/20160604102901

一番のつっこみどころは

黎明期からツイッターをやっている」のにクライアント一時的に #ntv #kinroとかの実況タグミュートすることすら知らないことじゃないだろうか。

2016-06-03

スマホ初心者通信チェックアプリを入れる

先月いきなり7GBオーバー、1GB追加購入したことを反省

今月は計画的に使うぞと通信チェックのアプリを入れた

帰り道、駅からとろとろ歩きながらゲームしたり、ちょっとツイッター見たり

と、3MB増えた

え?どこで何が3MB??

スーパーで買い物しつつ、自宅まで歩きながらあれこれ

と、また3MB増えた

え?いつどこで何が3MB??

だって3MBって言ったらあれだよ?フロッピー3枚だよ?

会社で使うドキュメントも2MBとかまあ重い部類よ?

メールクライアントによっては添付制限されるサイズよ?ってそれは弊社の脆弱メールサーバーぐらいなのかしらんけど

とにかく何MBとかが一瞬で消費されてしまスマホ及び回線

なんかすげーな、ちょっと感動

http://anond.hatelabo.jp/20160602235920

そもそもツイッターでふぁぼ(いいねなんて無ぇ!星にもどせや!!)とかRT数気にするのって

ここ数年の話

ふぁぼってメモ代わりに使ってる人が多かったはずなんだけどイイネ化アホらしい

みんな非公式クライアント使ってたんだから反応なんて見なかった(見なくていいか排除してた)

ほんと、自分常識押し付けるのってやめてほしいよね。とくにツイッター二次創作活動してる人たち

2016-05-31

仕事が断れない

仕事を断るのが苦手だ。



私はデザインとかイベント映像企画屋をやっているのだが、

独立して10年、おかげ様で順調に引き合いをいただいている。



独立してすぐは「どんな仕事も断らない」をモットーにがむしゃらに働いてきた。

その甲斐もあり、若い有能なスタッフも雇うよになり、なんとかやっていけている。



ところが、メディア露出することが増えてくるにつけ、

いろいろな相談・引き合いが増えてくるようになった。

どうも、昔お世話になったクライアントが、

増田さんとこだったら安くて高品質だよ」と宣伝してくれているようだ。

昔ならありがたかったが、今では迷惑である



こんなのはザラである



確かに昔はすべて受けてきたけど、それは自分一人だけでやってきたから。

でも、今はそうはいかないし、小さい仕事お金の無い仕事を受ける余裕はない。



はいえ、昔お世話になった人の顔をつぶすようで断るに断れないのが性格で、

スタッフにふるのも申し訳なく、自分作業をしていたりする。

なんとか、うまい断り方は無いものか。

2016-05-30

http://anond.hatelabo.jp/20160529174143

医者にかぎらず学校卒業してすぐの社会人のうち、ある程度はこういう人がいそう

それにしても患者クライアント)の感謝が嬉しいと思えないというのは、ちょっと感情不全っぽいものを感じるなあ

人との関わりが増えるうちに変わるものだとは思うけど

2016-05-28

彼女が欲しい。

クライアント先で、とある新作映画チケットを2枚貰った。これが普通の男なら、“お誘い”をかける女性の一人や二人を思い浮かべることだろう。僕もチケットを「ありがとうございます」と言いつつ受け取りながら、誰とこの映画を観に行こうか頭の中で考えていた。

まりにも思い浮かばず、思考を諦めた。諦めたというより、逃げたという表現が正しいかもしれない。そりゃあ、この数年女性デートなんてことをしていないので、当たり前といえば当たり前かもしれない。とはいえ、誰か一人くらいはいるだろう。そう思いもう一度改めて考えてみたが、やはり一人も浮かばなかった。

中学生でも出来る「映画に誘う」というデート方法しかも、「チケット貰ったんだけどさぁ、余らせちゃうの勿体無いから……一緒に行かない?」という、“誘える理由”も僕にはある。過去自分がもしこの状況だったら、あの娘を誘っただろうな。そんな思いを巡らせながら、いつものようにインスタグラムを惰性でチェックしていると、3年前に恋人だった女性写真を見つけた。紫色の髪の毛、ボロボロTシャツ、派手なメイク。僕の恋人だった頃の面影はそこにはなかったが、すぐに「あの娘だ」と理解した。

家に帰って、自分の姿を鏡で見てみた。少し髪が薄くなったかもしれないが、ほとんど変わっていないだろう自分がそこに写っていた。僕は、瞬時に理解した。今日までの僕は、新しいことも昔のことも、どちらも考えないように、そして逃げていたんだ、と。

ちょっと新しい道を歩いてみようかな。3年前から、1歩進んでみよう」と、前向きに生きられる気がした。まぁでも、とりあえず溜まっている仕事を片付けてからかな。

そんなことを思った、初夏の金曜日の夜。

2016-05-25

http://anond.hatelabo.jp/20160525144615

買ったゲームを動かすのに必須というので嫌々入れたクッソ重いゴミクライアント

クリアしてから数年放置してたら巨大マーケットになってました

2016-05-22

http://anond.hatelabo.jp/20160522003506

http://anond.hatelabo.jp/20160522003506

ども。

この辺りの一連の発言特に後二者)を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAWeb APIといったフロントエンド世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます

ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データ配信DB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリレベルに追いつき、同じやり方ができるようになった、というだけの話です。

とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。

具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドリアルタイム集計が登場する勤務予定表的なものを、1人でjQuerySPAで作った際、数百行のHTMLと数千行のJSスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代ベスト」として自信を持って残せますJSX局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません(私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います)。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。

「変な独自拡張を入れてまでJSを使い続ける理由わからん」についても、まるでJS生来嫌われ者で、クライアント側でもPythonRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね? たぶんES6は人々から積極的に愛されています。現状、クライアント側にPython進出するのではなく、逆にデスクトップモバイルサーバ側にどんどんJavaScript進出する流れが起きています

速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね(mustache使うよりは速いよね)ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通JS技術者普通に触れる程度の成熟はしています(枯れたとまでは言いませんが)。

http://anond.hatelabo.jp/20160521163144

SPAにしたことで画面表示のコードは全部クライアント側に持って来れるようになったかサーバ担当の俺は楽になったw

2016-05-21

http://anond.hatelabo.jp/20160521190026

元増田です。

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のほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーものとしては残り続けるだろうが。

ここわかんないですね。活発なメンテがそんなに重要なのかな?ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか?