「言語」を含む日記 RSS

はてなキーワード: 言語とは

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。


富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。


富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

http://anond.hatelabo.jp/20160528220748

画面操作時の動きとそこからデータの流れまでわかってる人だからもうほぼ書けると思うんだよね


基本的既存の流用か改変だし PG歴浅くてこの言語はじめてな自分がなんとかしてる状態から


確かに適切じゃない資料が残ってたらそれはそれで厄介だ

2016-05-28

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

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

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

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

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

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

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

2016-05-27

オバマ大統領の所感と脳の不思議

現職米国大統領による広島訪問という歴史的出来事テレビで見た。

ベルリンの壁崩壊と同じような歴史の節目になるんじゃないか、なってほしいという希望とともに少し緊張もしていた。

 

耳をテレビに集中させオバマの声を聞き漏らすまいとしていたらオバマ発言がそのままダイレクトに脳に入ってきた。

なんという俺の英語力の進歩。集中しているからなのかと思っていたら俺が聞いているのは同時通訳による日本語だった。

 

そしてそのままNHKの19時のニュース

アナウンサーの声がとぎれとぎれにしか理解できない。

どうなってしまったのだ。疲れているのか。

それとも何かしらの体の異変前兆かと思っていたら、副音声英語を聞いていた。

 

ポンコツ脳の勘違いだが、何かを考えるときには人は言語ではない「何か」で思考しているのかなと思った。

2016-05-26

女の書く文章って何であんイライラすんの?

文語体ではなくて、口語体の話ね。

なんつーのかな。軽く煽るというか、私は他の人より上の人間なんです!って感情を何とかオブラートに包んでるような…。

あー上手く言えねーわ。誰かこの感じ言語化してくれよ。

http://anond.hatelabo.jp/20160526124746

子供大人背中見て育つしか無いと思うので、四の五の言わずにこれからの世の中で自分たちがどう一生懸命に生きるかを見せるのがいいんじゃないですかね。しいて言えば、流通交通が発達して距離障害はどんどんと解決されていくでしょうから言葉障害解決する手段は身につけてさせておいたほうがいいかなとは思います。(言語を学ぶにせよ、そうしたテクノロジーのあ使い方を身につけるにせよ)

愚者の国

愚者の国に言語はない。

音節叫び声、述部のない主語主語のない述語、目的語のない主語と述語、主語も述語も目的語もない補語が繰り返される。

強調は声の大きさと単語の繰り返しの回数によって表現される。

すなわち声が大きく、繰り返しの回数が多いものほど強調度が高い。

しかし構文ではなく1単語叫び声の繰り返しでしかないので、なぜ、何を、どう強調したいのかはまったく不明である

ポエム

言語フレームワークを先に考えるんじゃなくて、実現したいコト/解決したいコトが先でそれをとことん突き詰めて考えるコトが大事

それがちょっとだけ良くなる程度のものだったら、そもそもそれはあまり問題では無いのかもしれないし、単純に当事者意識情熱がなくてただ普段と違うコトがしたいだけなのかもしれない。

例えば、車輪のようなもの一見するとちょっとだけ良くなる程度のもののように思えるけれど、突き詰めて考えるとちょっとだけ良くなる類のものではなくて、シンプルだけれどすごく応用範囲の広い要となるものだったりするよね。

その応用範囲までもよく考えたものを、最初の段階から応用範囲に至るまでを効率よく実現するために、何を選択するかをよく考えよう。

海外の有名な会社が作ってるようなもの簡単に作れるからとかあの会社も使ってるから、ありとあらゆる部品が揃ってるや既に知ってるものから効率が良いなんてものは、参考にはしても選択理由にするべきものであってはいけない。

そんなコトを理由にしたら、私は自分の頭で考える力も何かを生み出す能力も持ち合わせていません。なんて宣言してるようなものなんだよ。

問題が起きたらまた一から作り直せば良いなんてのは大抵失敗するし、そのコストが支払えない場合は継接ぎだらけで局所的な問題が頻発するものになるコトが多い。そして、最初に感じた効率の良さなんてものはいつの間にか消え去ってしまってる。

必要部品は何なのかをきちんと洗い出して、それらの部品を柔軟に組み合わせられて効率的に動かせるもの選択するコトなんだ。もしもそれらが存在しないなら、それらも含めて作り出すコトも視野に入れておこう。

こんなコトを言うとオレオレかよなんて声が聞こえてくるコトもあるけれど、初めからそうじゃないもの存在しないんだよ。誰かが作り出したか存在してるんだ。だからやると決めたらきちんとアピールしてディスカッションして継続的改善しよう。

そんな風に世の中に数多くいる、言語フレームワークアルゴリズムUIUXシステムアーキテクチャ設計開発研究をしている優秀な人たちの思考を真似てみよう。

流行り廃りに振り回されて後追いばかりに終始して、大きな声でその時々の借り物の言葉しか話せなくならないように。

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人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

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

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

http://anond.hatelabo.jp/20160525143657

俺も別にフェミニストじゃないから、詳しくない人間同士で話してもアレだけど

知らんが、主婦という生態自体が家父長制度やらの封建的環境で発生したものから、それを否定するためには主婦生き方それ自体否定しなきゃいけないって教義なのがフェミニストなんじゃねーの。

 おれの知ってるフェミニストはそこまで極端な主張する人はあんまいないかな。

 「主婦という生き方デフォルトになりがちな社会」のあり方は否定してるフェミニストが多いと思うけれど、

 自覚的主婦選択する人をディスったりする人はあんまりいないし、

 「主婦という生き方」のなかにどういった苦労があるかということをきちんと言語化しようというタイプ仕事をしてるフェミニストのほうが圧倒的に多数派だという印象を持ってけどな。そこでアンペイドワークがなんちゃらとか、そういう話が出てきてるのだと認識してる。

 まあ、フェミにもいろいろいるか主婦という存在のものをディスってるラディカル系の人もいるにはいるんだろうな。そういうフェミの人とはあんま近寄りたくないな。単にあたまわるくて話が通じなさそう

http://anond.hatelabo.jp/20160525033655

外国人英語共通言語だと思ってる節があるからね。

普通に失礼だと思う。

元増田よく我慢した。グッジョブ

2016-05-24

[]テッド・チャンあなたの人生の物語」その2

あなたの人生の物語

満を持しての表題作

異星人とコミュニケーションするために言語学者の女性がいろんなアプローチを試みる中で、ところどころに女性の娘へ話しかけるような描写が入る

一見何の関係もないように見えるのに、最後最後でその構成意味がわかったときめっちゃ感動して鳥肌たった

SFお話としてのオチがすごく綺麗につながってて、しかもそれが読みやすさにも寄与する構成になっているという、何重にも考え尽くされた構成

脱帽どころか頭蓋骨外して脳みそ取り出すレベルで恐れいった

どーゆーことかっつーと、娘へ語りかける描写言語解析アプローチフェーズ→の繰り返しなんだけど、言語解析のところはぶっちゃけ読んでて結構きついのよ

からないわけじゃないけど(ここもテッド・チャンのすごいところ。自己満じゃなくて、読者にわかレベルで丁寧に書いてくれる。この話にかぎらず)、

細かすぎて疲れるっつーか、ずっとこの調子で書かれるとちょっとうんざりするなあという感じ

それが娘への語りかけ(これも平易だけど細かいディテールに凝った、感情移入やす描写)がはさまることで、かなり緩和されてるのよ

そんでその構成も、ただの読みやすさのためだけじゃなくて、ちゃんと意味があるの

それが最後最後で明らかになるのよ

もうファーーーーーーーwwwwwwww

ッて感じとうっわまじかよ・・・って感じで思わず本を置いてしまった

SF作家じゃなくて言語学者が書いたのかとばかりに凝りに凝ったディテールの、異星人の言語解析描写は、ほんとやばい

子育てエッセイかな?というくらいの子育てフェーズやばい

全部やばい

いまんとこ面白さは、

あなたの人生の物語>=理解バビロンの塔>ゼロで割る

かな

マジすげえ

もっと早く読んどくんだった

星を継ぐものとか夏への扉なんかより、こっちを先に読むべきんだった

お話としての面白さ・エンタメ性がないとSF小説」と名乗る資格はないと思ってる自分が、まさに求めているものだった

自分が求めていたものテッド・チャンだったんだ

■React.js界隈の人に聞きたい

http://anond.hatelabo.jp/20160521163144


gitも無いような化石みたいなweb制作会社で働いてて

こういうの見ると毎回気になるんだが

React.jsとか使うような案件ってどんな感じでくるの?

っていうかどういう言語とか案件をメインで取り扱ってる会社が受けてるの?

近い業界のはずなのに全然知らないもんなんだなあ

2016-05-23

http://anond.hatelabo.jp/20160523174650

思考言語化できる能力がなくても

相手理解できないを繰り返していれば傷1つ付けられないから君は無敵だね。

ヨハネスブルク天使たちを読んだ。建築紛争と落下するロボット。全編通して退廃的な寂寥感が味わえたのでなんだか寂しい読後感を得られた。

人間って何なんだろう。誰しもがふと考えて、その時々で納得できる答えを見つける問を、再び抱かせるような作品だった。紛争が大きな共通項として紡がれているから、どうして人は争うのだろうとかも考えさせるんだけど、ある程度その答えが作中で描かれているか人間に対する哀れみにも似た感情を抱いてしまう。歴史は繰り返すって言うけれど、改めて無情な現実を突きつけられたような気がして呆然としちゃった。

また表題作でもあるヨハネスブルク天使たちにおいて、起動しただけのDX9に意思と呼んでいいのかわからない思考回路が生まれていることが引っかかった。この一遍以外純粋なDX9の思考は明確に表現されていないんだけど、人格を上書きされた個体とか、プログラムを上書きされた個体果たしてどうなったのか、思考存在していたのかとか彼女たちに対する生存権みたいなものを考えると、ますます人間のどうしようもなさが強調されているように感じた。

建築とか紛争については解説でも触れられていたから脇においておくけれど、度々記述されていた言語に対する思想も興味深かった。言語に関する項目は紛争にも関わる事柄ではあるんだけど、もしバベルの塔が倒壊していなかったらもう少し現状とは違う現在存在し得たんだろうと思う。

最後一遍だけ紛争から離れた日本舞台にしてたから(二編目もアメリカ舞台だけど9・11を題材にしていたから毛色が似通っていた)雰囲気が他と少し違ってたけど、この作品には最後希望が見える気がした。あんなの希望じゃなくて暇を持て余した挙句に見つけたささやかな娯楽の延長でしかないのかもしれないけど、あの光景想像すると人間の善性を信じてみたくなる。もちろんそんなのはまやかしかもしれなくて、事態を一方からしか見ていない独善的な捉え方ではあるんだけど、やっぱり生きていくのだから先は少しでも明るいほうがいいと思う。

なんかよくわかんない感想になってしまった。個人的には前作のほうがバラエティーに富んでいたし、しんみりする話ばかりじゃなかったから好みに合っていた。静な気持ちにさせてくれる一冊だったと思う。

関数言語界隈は悪い意味で頭おかしい人が多いんじゃないか

この前本屋でIQ145女子高生がなんたらって本見かけて頭がクラクラした

2016-05-22

http://anond.hatelabo.jp/20160521234423

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

わざわざ一緒くたにベタ書きする設計が悪いだけの話でしょう。それともJSで書くものはすべてロジックで、表示用コードは別言語でなくてはいけない、とでも思っているのでしょうか。ビジュアルデザインはほぼCSS規定されるだろうし、それを用いる構造HTMLベタ書きなのかJSで作るのか、という話にすぎない。

活発なメンテがそんなに重要なのかな?ということです。

"Software Rot"という用語を知らないでしょうか。インターネット上の環境が進んでいるなかで、進歩が止まれば使えないと同義でしょう。世の中には脆弱性のあるJVMマイナージャージョン固定でユーザーに使わせた大企業もあるけど、そちら側の人ならしかたないですが。もうReactがどうのこうのというレベルじゃないですよ。

http://anond.hatelabo.jp/20160521163144

coffeescriptは廃れたから使われなくなったんじゃなくて、言語仕様に吸収されて役目を終えたんじゃないの?

欲しい機能を先行実装して、それが仕様に吸収されて基本仕様需要が満たされた役目を終えるってむしろ素晴らしいことじゃん。


てか、jQueryを使って出た不満を解決するために出てきたのがReactであって、同じ不満を抱えてた人が多いから今の状況があるんでしょ。

jQueryだけでいい、Reactなど不用」ってのも「React最高!jQuery滅ぶべし」ってのも、どっちも共感できない。


一番わからないのは「Web界隈は流行り廃りが激しすぎて糞」とかい意味不明Dis

jQueryで得たDOM操作はReact触るときにも役に立つし、Web Componentsは仕様に組み込まれる方向で動いてるんだから

Reactが廃れるとしたら、それはcoffeescriptと同様にその役目を終えただけで、廃れたから使われなくなるわけじゃないと思うんだが。

全く別の技術が林立してるんならその批判もわかるけど、既存技術問題点解決する技術確立否定したら進歩なんか無くなっちまうよ。

利便性が上がって手間が減るスピードが速い事のどこが悪い事なの?マジで意味わかんねぇ。

学習コストこれ以上払うの嫌でござる」って素直に言えばいいのに、何でかっこつけようとするのかね。

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

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

http://anond.hatelabo.jp/20160521163144

まずReactの特徴は、「状態データから変換してビューを生成する」スタイル統一されることにある。

これはjQueryをはじめとするDOM操作モデルでの、「初期状態ビューの作成」と「(イベントに伴う)状態変化からの部分ビュー変更」で構成するスタイルから脱却され、たとえば部分処理の積み重ねから想定外状態が生まれることを防ぐ。

SPAは、クライアントが自立した1プログラムとして状態管理する。サーバUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバサーバサイドページ生成のスタイルを、サーバブラウザでやるようにシフトさせたものともみなせるだろう。

そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。

すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーものとしては残り続けるだろうが。

Reactのモデル関数型プログラミングモデルのものであって、そういう観点ではすでに何年も続いたものであり、React自体は消えたとしてもその手法は長く続くことになる。

岡部健劇場

おう、今度はC言語純粋関数型言語だ、と言い始めたぞ

それも凄いが、今頃そんな事を言い出して、お前がQiitaで書いてきたことは何だったんだよ(笑)

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

React.js界隈の人に聞きたい

**誰かみんなの主張のまとめを作ってくれないですか?** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)

最近JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。

論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ!ってことなんだと思います。(virtual DOMがメインだ!という話もあったけど、じゃあ何でReactなの?というのは聞きたいかな。メジャーから?)

ただちょっと個人的違和感が拭えないので聞きたいです。

ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ(SPAではなかったような気がする)を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。

そもそも世の中にそんなにSPAがあるのか

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。

世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。

JSXを使うことに抵抗ないんですか?

トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います

こういう例、JS以外にもいろいろあって、例えばboostAndroidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ記法を使いましょう、ってことですよね。

でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます(そこまでは違わないかw)。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ!!」っていうのはかなり危ういように見えます

そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通言語から変えるようなソフトウェア流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)

五年後のビジョンがありますか?

五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee script結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい!!みたいに言ってるんじゃないでしょうか。

まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ(≒JQuery)と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。

まあこれを突き詰めるとじゃあetaxもactivexで、銀行システムcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、



とりあえずこんなところで、有識者の皆さんよろしくお願いします。



追記

React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。

id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない?という感じです。

id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で(どのくらいの規模のプログラムで)domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。(もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。)なんかReactががりがり(かつユーザー目線から見て有効的に)使われている例がイメージ出来ないのが問題な気がしてきました。

id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。

id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。

id:manaten もちろんFBGMailJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。(ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます

トランスパイラですねごめんなさいw

SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか?」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOM1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチ需要じゃないでしょうか。

あとなんか保守点検に関する意識ちょっと違うのかなっていうコメント散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね?ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。

それともしかしたら「枯れた技術」あるは「標準化」という意識あんまりないのかなとも思いました。まあ確かに「Web世界日進月歩!」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。

あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJS世界を救う!みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。

増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情お仕事としてのエンジニアはしていないですし。ほんとに純粋質問だと思ってもらえればうれしいです。

まあ長くなってきたので私のブログにまとめ直してもいいのですけど。

そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在必要ですけど~。

http://anond.hatelabo.jp/20160302090242

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

nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題Ocaml関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。


もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。


http://anond.hatelabo.jp/20160520153948

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、


もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。


もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

2016-05-20

http://anond.hatelabo.jp/20160520061937

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

nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題Ocaml関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。


もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。


http://anond.hatelabo.jp/20160520153948

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、


もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。


もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。