  |
はてなキーワード: vueとは
増田やTogetter、NHKに寡占されているはてなブックマークだが、めったにブクマされないサイトからホットエントリ入りしてくるウェブページはとても面白いコンテンツなんじゃなかろうかと思って調べてみた。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 2882 | 【アメリカで話題】ただ座るだけ！股関節がみるみる柔らかくなる「90/90ストレッチ」 ｜ ヨガジャーナルオンライン | yogajournal.jp |
| 1526 | 共感格差 | shioshio3.hatenablog.com |
| 1440 | きゃりーぱみゅぱみゅの 「大人なLADYになるわよコラム」第35回〜『マネーの虎化してるわよ』〜 | hanako.tokyo |
| 1109 | 米津玄師氏の担当の方から連絡がありました。｜つんく♂ | note.tsunku.net |
| 1002 | ちょうどいいWebデザインギャラリー | choooodoii.com |
| 939 | 記念日、赤ちゃん連れ等には向いていません - 星野リゾート リゾナーレ熱海の口コミ - トリップアドバイザー | www.tripadvisor.jp |
| 887 | 【股関節がガチガチに硬い人向け】可動域を無理なく広げる！"揺らすだけ"股関節ストレッチ ｜ ヨガジャーナルオンライン | yogajournal.jp |
| 795 | おいでよ 広告の沼 ｜ 昭和の雑誌広告を中心に | www.citymilk.net |
| 670 | スプラトゥーンの特許 - naoya2kの日記 | naoya2k.hatenablog.com |
| 659 | ネイティブが使うビジネス英語：株式会社日立システムズ | www.hitachi-systems.com |
| 615 | 株式会社リクルート エンジニアコース新人研修の内容を公開します！（2022年度版） | blog.recruit.co.jp |
| 598 | 「1年かけたマンガが、らくがきに負けた」上を見るよりも自分の評価を見る ／カレー沢薫の創作相談 | www.pixivision.net |
| 578 | 書評『つみたて投資の終わり方』取り崩し方考察 - FIRE: 投資でセミリタイアする九条日記 | www.kuzyofire.com |
| 578 | 有志と #ソフトウェアテスト読書マップ を作りました！ - ソフトウェアの品質を学びまくる2.0 | www.kzsuzuki.com |
| 570 | 世紀の謎「カーリングはなぜ曲がるか」を精密観測で解明 ｜ 立教大学 | www.rikkyo.ac.jp |
| 558 | AMD × 藤井聡太 ｜ 「神の一手」の裏側に。 ｜ AMD | fujiisota.amd-heroes.jp |
| 535 | ウェブ制作で React(Next) や Vue(Nuxt)、jQuery が最近どれぐらい使われているのか調べてみた - feb19 | feb19.jp |
| 481 | しみけんの妻・はあちゅうさんに訴えられましたが勝ちました - ゲスで怠惰なブログ | gesugesumi.hatenablog.com |
| 465 | 【海外アニメ】恐怖！ディズニープラスクソダサロゴ展覧会！【カートゥーン】 - コウタロー速報 | kotarodayo1126.hatenablog.com |
| 463 | 22/9/17 小二で全国模試一位を取った男の半生 - LWのサイゼリヤ | saize-lw.hatenablog.com |
| 461 | 「部分的」動員がロシア社会に及ぼす影響 | rusbureau.net |
| 450 | 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ ｜ コーソルDatabaseエンジニアのBlog | cosol.jp |
| 433 | 外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog | product.10x.co.jp |
| 425 | “統一教会”と性教育（前編） | www.knb.ne.jp |
| 400 | 「水着でも男女混浴不可？」の東京都の条例についてあれこれ調べたら面白いことになってきた。 - ヨッピーのブログ | yoppymodel.hatenablog.com |
| 398 | 元・電通マンが地方公務員に転身。湘南から岡山に移住して5年でいまだ感じる4つの葛藤 ｜ OCEANS オーシャンズ｜男の日常を楽しくする情報発信局 | oceans.tokyo.jp |
| 397 | Fit Boxing北斗の拳（フィットボクシング北斗の拳）｜ Nintendo Switch | fitboxing.net |
| 397 | 【睡眠改善の手順】睡眠時間を正して、質を高める | kaimin-times.com |
| 393 | VSCodeをメインのエディタにして半年たったので入れてある拡張機能を紹介します - 壁に飾られた絵画を見ようとしてその絵に近寄ってはいけない | blog.ayako-m.work |
| 393 | キリン、電気の力で塩味・旨味を増す「エレキソルト」。対応カトラリーを2023年発売へ | gourmet.watch.impress.co.jp |
React.jsを使うと、Node.jsの学習って無駄になるんでしょうか？
例えば、何か新しい機能を追加したい、となったらNodeのライブラリじゃなくて、reactのライブラリを使いますよね？ もしくは普通にJSで書くとか（？）
無駄にはなりません。
まず、「Node.js、Deno」はサーバー･サイドJavaScript、「React」はクライアント･サイドJavaScript(つまりブラウザ側)なので、役割分担が違います。
ただし日本のプロの世界では「Node.js、Deno」はイマイチ人気は無いので、プロを目指すなら無駄になるでしょう。
そうですが、Next.jsは人気は無いので、Reactを強く推奨します。
Google Trendsは、あくまでもキーワードの人気度であり、本体の人気度ではありませんが、人々の関心度と考えて良いでしょう。
https://trends.google.co.jp/trends/explore?date=2013-06-01%202022-06-01&q=jQuery,React,Vue,Angular
Vue.jsはhtmlのような一度記述するとファイルを更新するまで記載内容を変えられないようなファイル（静的ファイルと言います）をユーザーがボタンなどの操作を行うことで、Google Chromeなどに表示された後でも、htmlの内容を随時更新させるような仕組みを提供してくれるツールです。
HTMLは構造体と呼ばれる設計図ですが、Vue.jsというのはJavascript（ジャバスクリプトと呼びます。Java（ジャバ）ではありません。メロンとメロンパンくらい意味が違います。）とよばれるスクリプト型のプログラム言語をより書きやすく、かつ使いやすくした新世代のJavascriptの一種です。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
スペックはアラサーのIT系人材。Web系はだいたい一通り触れてきてフロントエンドもバックエンドもある程度できるけどインフラは最低限くらいにしかできない程度に苦手。言語はPerlとJavaScriptから始まってPHP、Ruby、Python、Go、TypeScriptあたりは言語レファレンスを見なくてもある程度は書ける。非WebだとC++とかも一応書けるには書ける。フレームワークで言うとRailsとかDjangoみたいな全部込み込みのものからFlaskとかpeeweeとか選定して作るみたいなレベルまで色々経験してきたし、フロントエンドもnodeとio.jsが喧嘩してた頃からAngularとかBackboneを経由してReactやVueなんかに触れてきた。某転職サイトでは得意な言語は一通り偏差値65-70で某ポートフォリオサイトの技術力スコアは3.6くらい。運良く趣味やらバイトやらでWeb系をやってきたから外向きに見せられる実績もある程度あるしエンジニア人材マーケット内でもそこそこ需要があるといった感じ。ずば抜けた才能があるわけではないけどどんな現場でもそれなりにスキルを発揮できる器用貧乏タイプだと思う。
そんなこんなで博士に至るまでIT系のスキルを活かしつつだいぶウェット寄りの分野でプログラミングを駆使して色々なことに取り組んでた。民間のエンジニア人材としては平々凡々でも周りがプログラミングできない連中だらけのアカデミアの世界では神扱いされてちやほやされた。そんでもてはやされて勘違いして工学じゃなくて科学の博士課程に進んだのが間違いの始まりだった。
身バレするのが嫌だから詳細は伏せるけど、まあパワハラアカハラなんて日常茶飯だった。指導教員はまともに指導なんてしないし周りの教員たちも工学的なことばっかやってるのを見て好き勝手言ってきた。正直進む道を間違えたのは自業自得だけど、そのくせ「せっかく進学したのにやめちゃうの？」みたいなこと言って引き留めてくるからタチが悪かった。今からして思えばプログラミングができるレアな便利人材を手放したくなかったんだろうなって感じがする。
そんなこんなで博士の終わりが迫ってくる頃にはアカデミアに対してこれでもかというくらい嫌気が差していたけど、それでもやりたいことがあるから一応就活はアカデミア系と民間系で両方やってた。どちらもオファーが来たけど結論から言うとお話にならないくらい民間の方が条件が良かった。
まず給料は民間が1.5倍以上、アカデミアの技術職との比較だと2倍以上の開きがある。しかもこれは「民間の一番下」と「アカデミアの一番上」を比較した数字でそれぞれ逆をとったら正直目も当てられない。その上福利厚生もさまざまな手当も民間の方が条件がいい。給与の伸び代も民間の方がいいし就労条件も民間の方がいい。そもそもアカデミアでフルリモート可なんて存在しないんだから勝てるわけがないんだけど。その上で民間は原則として終身雇用に対してアカデミアは任期付きのポストばかり。就活を始める前からわかってたけどいざ現実として待遇の違いを突きつけられるともはや笑うことしかできなかった。
「それでもアカデミアは自分の研究ができるんだからいいじゃないか」と言う意見を目にするけど、結局はPIとして独立するまでは他の先生のラボで雇われになる。その間にうまくやらなきゃ一生そのまま下請け仕事をし続けることになる。そしてたとえ独立できたとして、選択と集中の名の下に文科省にとって都合のいい研究テーマを立案しなければまともに研究費を取ることすらできない。大口の予算を取ろうと思ったらいかにビッグマウスで役人を丸め込んでそれっぽいことをやれるかで全てが決まる。
自分が外れ値であることは否定しない。プログラミングが楽しくてWeb系の技術が好きで、可処分時間を使って夢中になって勉強したり色んなものを作って遊んだらして過ごしてきたからこそ今がある。でも正直少しでもプログラミングができるならアカデミアに残るより民間に就職した方が待遇もワークライフバランスもいい。きちんとリサーチすればカルチャーだってすごくいい会社はたくさんある。
それを承知の上でアカデミアに残る人は正直すごいと思う。自分がその立場にいることを想像したら気が狂いそうになる。もし似た立場で迷ってる人がいたら心から伝えたい。アカデミアやめて本当によかった。
機能を盛り過ぎてるのはVueの方で、Reactには最小限の機能しかないよ
最小限の機能しかないのでライブラリを選定するなり自分で実装するなりする必要のあることが多く、機能モリモリall in oneを求めるVueのユーザー層には確かに向いてない
ぶっちゃけわかる。
開発から遠のいた(Excel資料整理係になってる)のでreactはハロワしかやってないけどもわかる。
vueのほうが非エンジニア層に受けがいい気もするし、そもそもそこまでspa的に作りたいか?と思ってしまう
めちゃめちゃstoreがわからなくて、そこそこ書きやすいCRUDアプリみたいな書き方で良くない?とかになった覚えがある。
vueはガチガチしてないものを作るのにいいし書きやすい。reactはなまじっか機能を盛り過ぎてるのが無理。
やれと言われたらやりますが……。
何年か前に、Vue.jsとReact.js比較して、Vue.jsを使うことに決めたんだけど、
最近の風潮として、React.js一強になりつつあるから、またReact.jsのことをちょっと調べ始めた。
正直、React.jsって何がいいんだかさっぱりわからない。
JavaScriptの中にHTMLタグが記述されるJSXって、ものすごく筋が悪いように思う。
大昔、Servletの中でちまちまHTMLタグ出力してた時代に戻ったみたい。
後、これってどういうワークフローで開発してくの？
TSはおろかJSすらできる人が少ない現場だとReactなんて使えないのよ
もっと言うと、VueわかりませんjQuery使いますってことすら普通にあるし
Reactも面倒なことはめちゃくちゃ多いしそこまで素晴らしいとは思わないけど
因果関係が逆
Reactを持ち上げるためにVueをくさしてるんじゃなくてゴミ糞であるVueが採用される可能性を下げるために仕方なくReactを持ち上げている
「Reactは最もシンプルなライブラリ、〇〇とかクソでしょ」とか、うるせええええええええ
シンプルなんていう自己満足はどうでもいいんだよおおおおおおおおおおお
こっちは好きでイージーでフレンドリーなFWを使っとんねん！！！！！！！！！！！！！
わざわざ他フレームワークの記事にまで出しゃばって来んじゃねえええええよおおおおおおおおおおおおお
そんなにシンプルなんが好きだったらBrainfuckでも使ってろや！！！！！！！！！！！！！
「〇〇は魔法だから嫌なんだよなぁ」ってプログラミング言語なんて多かれ少なかれ全部魔法やろがい！！！！！！！！！！
魔法が嫌ならマシン語で書かんかい！！！！！！！！！！！！！！！！！！！！！
そんで useEffect は魔法と違うんかい！！！！！！！！違うんかい！！！！！！！！！！！！どっちなんだい！！！！！！！！！！！！！！
「海外ではReactが流行ってるから」お前が働いてるの日本やんけシリコンバレー行ってから言えやああああああああああああああ
「企業主導で開発が活発だから」それは認めるけどもおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお
「何でVueは二重括弧なの？笑」それは流石に難癖だろうがあああああああああああああああああああああああああああああああ
最初に見たReactを親だと思ってるだけとちゃうんかああああああああああああああああああああああああああああああああああああ
比較するだけなら良いけど、他を叩くことで自分を持ち上げるっていう排外主義者みたいなダサい真似は流石にやめとけえええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええ
（JSXは別に気持ち悪いとは思わなかった。classNameとhtmlFor以外は）
------------------------------------------------------------------
使いたいデータは data に書けばいいし、使いたい関数は methods に書けばいい。
非常に単純明快だ。
------------------------------------------------------------------
React は、JS をある程度理解していないと使うことすらままならない。
さらに React の設計思想を深く理解していないと、うまく使いこなすことはできず render 地獄が生まれてしまう。
「俺たちの設計思想が理解できない奴は使わなくていいよ。初心者のためにわかりやすくなんか絶対しないよ」と言うメッセージを、駆け出しの私は確かに受け取った（実際そう思ってるんじゃないかな）。
------------------------------------------------------------------
React 推しのエンジニアのほとんどは、発表当初すでに JS に強かった人が多い。
そして Vue すら理解できないエンジニアが世間にはゴロゴロいることも知らない層だと思う。
だから無批判に React を礼賛できる。そりゃ自分や周りが振る分には切れ味最高なわけだからね。
その剣を持ち上げることすらできなかったり、持ち上げられてもうまく振れない人々がいるなんて、思いもしないのだろう。
------------------------------------------------------------------
しかし強いエンジニアに影響された何もわかってない駆け出しが「React 最高〜〜 Vue はクソ」みたく嘯いているのを聞くと「本当にわかってて言ってる？」と思わざるを得ない。
Vue の Options API すら理解できない人々に、useEffect が使えるわけないからだ。
React 信者たちは「俺達が簡単に覚えられたんだからお前らもできるだろ」的な知的マッチョ思想で、不特定多数の駆け出しにReactを勧めるのを今すぐやめるべきだ。
------------------------------------------------------------------
もちろん強いとわかってる後輩には勧めていいけどね。
日本のエンジニアの給与の下限は、Reactを習得する対価としては低すぎるのです。
------------------------------------------------------------------
