  |
はてなキーワード: TypeScriptとは
TypeScriptのスペシャリストでない俺が見ても型定義は本当に局所的でAnyばっかりだわstrictFunctionTypesがfalseだわts-ignoreばっかだわでTypeScriptの型チェックをまともに使ってなかった。
言語仕様のうちメインの機能を使ってない時点でバリバリ使っているという印象ではなかったしただトランスパイルのオーバーヘッド増やしてるだけのようにしか感じなかったのでとても不誠実だなって思った。
「私たちはTypeScriptを使って堅牢な設計を構築してまーす」みたいな文言があったら警戒しておくに越したことはないなって感じ。
なんか今頃になってPythonの学習コンテンツが充実してきてるけど
Pythonってもう旬を過ぎたと思うんだよな
tensorflowとかsklearnとか使うためにPythonは凄く有用だったしこぞって使ってた
まぁそれでもPandasはクソだったけど他に選択肢もなかった
あと、AIみたいにサービス化とかUIを気にしなくて良いようなワンショットのプログラミングには向いてた
型付けとかしなくていいし、少しぐらいメモリリークしてても気にしないし、UIはtensorboardとかグラフをpngで吐き出せば良かった
何よりターミナルから打ち込んだら実行してくれたりMarkdownのファイルの中に書いたら実行してくれたりそれはまぁ便利だった
ところがAIがコモディティ化して頭打ちも見え始めてきた段階でそろそろビジネス化しないといけないけど
そうなるとPythonみたいなやんちゃな言語をプロダクトレベルまで実装出来る人が少ないことに気づき始めた
UI作るの面倒だし、型チェックとかもやってくれないから想定してないバグが出たり
Pythonを凄いやってた人も「プロダクトレベルとなるとちょっと」っていう人が増えてきた
かといってJavaには戻りたくないってなってTypeScriptが流行り始めた
そもそも最終のUIはWebだし、jQueryから始まったReact/Vue/Angularあたりはどれを使っても簡単にUIを作れる
おまけに枯れたNode.jsでサーバレスに実行できる環境まであるからTypeScriptが流行りまくってるんだと思う
Web系の弱いところはスマホアプリで、WPAあるけどイマイチ流行ってないしAppleが乗り気じゃ無いのがなんとも
なのでflutterあたりが人気出てくるかなぁ、とは思うけどWeb系ほど選択肢が無いから合わない時にとことん合わないと思う
ここから数年はPython人気が落ちてきて、TypeScriptが伸びて、Dartがじわじわ伸びてくるんじゃないかなぁ
初学者はPython、とか言うけど関係なくTypeScriptやった方がいいと思う
数行書き換えるたびに走る激重コンパイルのせいだかVSコードのせいだか、お前がTypeScriptで開発したせいでPCがスワップ領域にアクセスしまくってまともに動かないんじゃ！死ね！
お前は意識高いから16GのフラグシップiMac貸与されてるのかも知らんがよ。こっちはMacMini8Gで作業させられてんだわ
お前がゴミみたいな言語選んだせいでゴミみたいなエコシステムと自称軽快なエディター(糞重)を使わざるを得ないせいで、いっかいTypeScriptを触る作業が出るたびに他のアプリも全部ひっくるめてろくに動かんのだわ。
なんでVSコード上でファイル名を検索する方法をググるのに10分もかかるんだよ。ほっさかぁ〜爆笑じゃ〜
8Gマシンでここまで重くなるわけねーだろ。馬鹿じゃねえのかああん？？？？なめてんのかnpm。なんじゃこれ。お前ら本当にこんな腐ったエコシステムがいいのか？頭イカれてんじゃねーの？
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
いまもjQueryをWebアプリケーションの大事なライブラリとして使っている会社は少なくないと思う。
jQueryを会社で使っていると何が問題なのかを語っていこう。独断と偏見によるものなので、jQueryを使っていても問題ない会社も当然ある。たとえばペライチのサイトを作る会社とか小規模サイトなんかでは全く問題ない。
採用困難で売り手市場になっている時代、そして「jQueryを触らなければならない環境 vs モダンフロントエンド環境」という選択肢がある中で、あえてjQueryを選ぶフロントエンドエンジニアは少ない。
また、新人はもはやjQueryを学ぶことはない。彼らはES6以降のJavaScript / TypeScriptを書く。よしんばjQueryを学ぶことになった新人がいたとしても、それはただその新人が可哀想なだけで、現役なわけではない。ラガード（遅滞者）の仲間入りをさせているだけだ。新人でもキャリアをデザインできる新人は「jQueryはオワコン」という情報には触れているので、よほど就活で失敗しない限りはjQueryのところにたどり着かなくなっている。
そもそもバックエンドエンジニアでもモダンフロントエンドを書くような環境が増えてきた中で、2世代も前のjQueryだけでアーキテクチャに関する一考もないコードをメンテしなければいけないので、「jQuery」という言葉だけでフロントエンドエンジニアでなくとも入社を避けがちだ。（jQueryでアーキテクチャがしっかりしている可能性は低い。アーキテクチャがしっかりしているならばjQueryに依存しておらず、jQueryに依存していないのであれば簡単にjQueryから脱却できるはずで、簡単にjQueryから脱却できるならもう脱却しているはずだからだ）
メインストリームの部分はほとんどリプレイスが終わっているというでもなく、すべて現役でjQueryなのであれば尚更問題で、誰もメンテしたがらないコードの出来上がりだ。「弊社はCOBOLで書いてます！」とにこやかに言うようなものだ。
（ただし、さすがにjQueryだけでフロントをやっているという会社の求人をほとんど見かけることはない。無意識のスクリーニングで落としているのかもしれない）
jQueryを使っている会社には、フロントエンドエンジニアは一人もいないと言いきってもいいかもしれない。もしくは、今まさにjQueryをやめようとしているか、たまたま入ってきたフロントエンドエンジニアが今まさに辞めようと迷っているかのどれかだ。
「jQueryを使っていました」というエンジニアは、他社からはフロントエンドスキルが0とみなされる。つまり、フロントエンドエンジニアではないという意味だ。jQueryは、jQueryを使っている会社に対してしか武器にならないのだ（逆はできる）
jQueryを書ける人口自体は増えているだろうが、労働市場からは撤退し始めている。昔jQueryを書いていた人材の人数が上限で、そこから新たに学ぶ人の絶対数が減っているため、全体としては減っている。
私もjQueryは以前業務で書いていたが、もう数年書いていない。特にメリットを感じないからだ。遊びで、生のJavaScriptを書くことはある。
jQueryで入社するのは、昔からjQueryを使っている高齢のエンジニアか、なぜかjQueryを学ぶことになってしまった新人である可能性がある。
そのため、需要と供給に応じて、昔いたようなスキルレベルの人を今の市場で見つけようとすると費用がかかってしまう。jQuery書けますという人材が高年齢化しているのだ。そして世継ぎはいない。
リプレイスはハッキリ言って難しい。モダンなフロントエンドを学習するだけでは足りなくて、それを使いこなせた上でしかもjQueryを使用したカオスイベントコードも読めて、そしてアーキテクチャを考えてリプレイスしなければいけない。
時代が下るにつれて、そうしたハイスキル人材はより高価値になっていき、レア度も単価も高くなる。今そういう人を雇うという判断をしない会社が、どうして今後もっとハイスキルの人を雇えようか。
jQueryを使ったサービスがしっかり利益を出している点もリプレイスを難しくしている。全廃もできない。かと言ってコストに見合わなければリプレイスという経営判断も難しい。経営が困難な状態ならより厳しい。
何も理由がなくjQueryを使い続けたいという奇特な人は多くないはずだ。何か理由があってそうなっているわけだ。カッコよく言うと『ナッシュ均衡』という状態だろう。今会社にいる人材もいわゆる『jQuery人材』が多いため、そこを打破するのはとても困難な道だろう。
jQueryから抜け出すには、すでにいる人材がなんとかしてリプレイスするか、外から連れてきて改革するしかない。しかし大抵の場合、既存の従業員にとってはそんな大変なことをするよりも転職したほうが楽な道だ。（もちろん、「jQueryしかなかったサービスをモダンフロントエンドにした」というのが実績としてある人材はかなり魅力的な人材で引くてあまたなことだろう。その意味ではピンチをチャンスに変えるときの『チャンス』ではある）
ReactやVue.jsに変えたいと思ったとして「じゃあお前それですぐに利益出せんのかよ？」と詰められたら、その論争をクリアしてまで変えるのはほとんど無理に近い。通常、リプレイスそれ自体は価値を生み出さない。リプレイス後に運用コストが低下したり、人材獲得がしやすくなるために利益が出るのだ。リプレイスとは長期の投資であるため、短期的には必ず損失になる。経営が困難な状態でリプレイスしようとするのは、生活困窮世帯にリボ払いをやめさせるぐらい難しい。そのため、まず自分が身銭を切ってリプレイスするしかない。そしてリターンがあるかもわからない身銭は切りにくい。そして同僚は容易に『抵抗勢力』になる。
jQueryを今も使っているということは、裏を返せば「これまでリプレイスをしてこなかった」「リプレイスしようとしたが無理だった」という実績にもなる。
jQueryを使っている会社は、昔からあるコードをもとに書いているため、今もES6以前の文法で書いている可能性がある。そうしてどんどんと情報が少なく、古く、現代で通用しにくいものになっていく。
bundlerを使っていない可能性が高いし、もしかするとCI/CDも無いかもしれない。そうすると、モダンなインフラエンジニア（もしくはモダンなインフラ知識のあるエンジニア）がいないかもしれない。SREという概念がないかもしれない。
世間一般から見ると会社の中が古いのだが、古い会社にいると「自分が古い」とはなかなか思えないものだ。太っちょの集まりの中にいたら「自分はそんなに太ってない」と思うのと同じことだ。
すべては憶測なので、実際は違うかもしれない。
さんざんdisってきたが、そもそもjQueryは何も悪くないし、大変優れたライブラリだ。ちょっとしたプロトタイプを作るときには良いものであるかもしれない。しかも今もjQuery自体はメンテされている。そのため、状態管理さえうまくできていればjQueryだろうがなんだろうが問題ない。
問題は、jQueryというライブラリを使ってきた時代からアーキテクチャが前進していない点にある。何年もずっとその状態だということだ。そこを今日に至るまで誰1人として変えられなかったということだ。特に経営陣は何の問題視もしていない可能性が極めて高い。そうした社内のしがらみが反映された結晶体、それが『使用技術: jQuery』という言葉になっているのだと思う。また、ヤバさは、jQueryのバージョンに反比例する。
jQueryを使っているアプリケーションには、jQueryが担保していなかったアーキテクチャ部分に問題があることが多い。また、どこから呼ばれているか誰もわからない複雑なイベント、SPAもクソもないページ遷移ごとのリロード、誰もどこもテストできず、HTMLにベタ書きで書かれたJavaScriptコード、その場しのぎでデタラメに書かれた関数、無視される変数のスコープ、サポートが終わったライブラリ、ドキュメントを見つけるのすら困難なよくわからないライブラリ、高齢者しか知らない伝説の機能・伝説のハック、などもある。これらはモダンフロントエンドではほとんど発生しないものだ。
そのため、一定の基準として「jQueryを使っているかどうか」で、フロントエンドエンジニアとしてのやりがいがあるかどうかを判別できる。
そうして、フロントエンドエンジニアというのはもうjQueryに見向きもしていない。書けるけど書きたくない。パラレルワールドのようなものだ。
そういうようなことを「使用技術: jQuery」という文言から感じ取ってしまうのだ。
（そしてこれは、実際の仕事の中身が違うかどうかは関係ない。jQueryとは、そういうふうなブランドと化しているのだ）
jQueryを使っている会社からしたら「そんなことはわかっている」という部分で、「じゃあどうすればいいのか？」という部分が気になるところだと思う。
そこで、後編では「どうやってjQueryを全廃すればいいのか？」「実際にどのように全廃したのかの事例」について、だいたい来週ぐらいに書くつもりだ。
お楽しみに！
「TypeScriptを勉強する」が対策として上がってるならちょっとは理解できると思うが、
難しい文章を理解するために有効な手段のひとつはリファクタリングだ。
こんな感じ。
主張(a) 「その文章を読む価値があるのか」という想いの度合いが薄ければ、それに応じて文章は難しくなる。 (a)は文章にだけ言えることではない。 コンテンツを理解することは、モチベーションが高ければ容易になる。 「その難しいことをやるだけの価値があるのか」 「自分の人生の一部という、他にも選択肢がある中での、かけがえのない時間と交換するだけの価値があるのか」 という部分がモチベーションの高さに結びつく。 # 次のパラグラフは複数の主張が混濁しているようで、主張を明確にできていないように思える ＞ モチベは時間に応じて減衰していくので実際には習慣をつけるという能力も必要だが、 ＞ 点火点であるトリガーではモチベは有能な起爆剤になる。習慣化や自分のスケジュールに組み込まれることによって、 ＞ 必要なモチベの量はだんだん減っていくこともあり、 ＞ モチベだけがすべてではないが、基本は「価値あるぞ」と思えるかどうかだと思う。 コンテンツを理解すること自体は難しくない。 難しいのは、「それを突破する価値がある」と考えられる（＝モチベーションが高い）状態を作り上げることである。 モチベーションが高い状態を作り上げることに寄与する要素 ・自分には突破できるという信念（自信） ・それを裏付けする成功体験 ・たとえ無駄になったとしても人生において問題ないという経済状態 ・あなたならできると言ってくれる身近な人 上記の要素を揃えることは、難しい。 上記の要素を揃えるためにどうすればいいかは、ここまで読み進めてこられたみなさんならもうおわかりだろう。 # ここまで読み進めても「どうすればいいか」についての記述は無く、 # これは存在しない主張を、さも存在するように見せるレトリックに見える。
すべてにとって共通して言えることは、「なぜ難しく感じるのか」という点と、「どう突破するのか」という点だ。
この2点に集約される。
難しい文章を読むのは、誰にとっても難しい。
もちろん、ある人にとっては難しい文章が、別のある人にとっては簡単だというのはよくある。ただそれは、前提知識の違いや読み方の違い、たまたまその人の感性が筆者の感性にフィットしている場合や、筆者に対してどのぐらい信頼感を抱いているかにもよる。もしそこに差がなければ、同じ難しさになるはずだ。
つまり、もし自分と似通った能力を持っている人がその難しい文章を読めば、必ず難しいと感じるはずだ。
思考実験として、自分という人間をコピーしたあと、その文章の読解に必要な能力だけはそのままにして、さまざまな性格・さまざまな外見・さまざまな人生経験・さまざまな年齢に変えたとしよう。そういう人も同じようにその文章は難しいと感じるはずだ。
わかりやすい例を挙げるならば、タイからやってきたレンさんという存在を仮定しよう。レンさんは、日本語を猛勉強して、自分の日本語運用能力と遜色ない能力を身に着けているとする。なので、レンさんは自分が難しいと感じる文章を同じように難しいと感じる。ここで、レンさんは外国語を相当なレベルまで引き上げることができたのでバカではない。つまり自分がバカだから文章が難しいわけではない、ということだ。
つまりそれは、自分がバカだから難しい/読めないのではなくて、自分の現在の能力だと単に難しいというだけであり、「単に差があるだけだ」と認識する必要がある。その「差」とは「上下」ではなく、どのぐらい「違うか」というものだ。たとえばファッションに興味がない人が、ファッションの専門誌を読まないといけなくなったとき、ほとんどの言葉は未知語ばかりで難しい。ただ、そのファッションの言葉を知らなくても誰も自分はバカだとは感じないだろう。それと同じで、難しい文章を読むための知識が不足している可能性があることだけを認識するだけで、難しい文章を読みやすくなっていく。
アーガイルやAラインシルエットという言葉を知っていても「ふーん」と思われるのに対して、ロピタルの定理やはさみうちの原理を知っていると「賢そう」と思われるのは、文化やブランディングや前提知識の差によるものであって、バカとか頭いいとかそういう問題ではない。文化圏によっては真逆の扱いを受けることもあるだろう。
それに対して一切の興味がないとその文章を読むことは難しい。
「知らなくてよい」「自分には不要」と思っていることを知ろうとするのは難しい。「嫌いな食べ物を食え」と言うのに近い。そもそもそれが自分にとってどれぐらい有意義なのか知らなければ読む進めることさえ困難となる。
興味関心の度合いは、難しい文章の難しさをどのぐらいまで我慢して読み進められるかという突破力に密接に関連してくる。興味が薄いと「こんなものに時間を費やす必要があるのか」と思ってしまうからだ。結論、興味とは「どのぐらい理解したいか」なので、興味が薄ければそれ相応の「理解したさ」になる。そして、それぐらいの「理解したさ」では頭打ちになる場所が来たときに、終わってしまうことがわかる。
知るのに費やせる労力が100で、知るのに必要な労力が101ならば、知ることはできないという単純な理屈である。そもそも「どのぐらいそれに投資できるのか？」という興味レベルが重要になってくる。こうしたエネルギーをどう人工的に生成できるかは知らないが、自分を誤魔化してあたかもパッションがあるかのように振る舞うことはできる。
未知語や未知の概念や、自分にとって慣れ親しんでいない言葉（理解語彙ではあるが使用語彙ではない言葉）が文章中に出てきたとき、それを知らないことや習熟していないことは問題ない。また、それを知らないことで読めなくなることも問題ない。
大事なことは、そのときに、どの言葉がわからないせいで文章が理解できなくなっているかを知ることだ。その未知語は、実は他の箇所で説明されていることもあるだろうし、本当に初出の言葉かもしれないし、筆者オリジナルの言葉かもしれない。ともかく「この言葉を知らないから正確に読めていない」と考える。そうすることで「この言葉が全体の理解を妨げているのだ」ということがわかる。
実はその言葉はそのあと説明されるかもしれないので、いったん「こういう意味なのではないか」と推測して読むことも必要かもしれない。ともかく、文章が難しいのではなく、言葉が難しいだけなら、言葉を知ればいいという話になる。
文章によっては、循環参照になっている言葉もある。循環参照というのは、たとえば「AとはBである」という説明をしているのに、あとから「BとはAである」という説明がされて、結局何の説明にもなっていないような関係のことを言う。そういう循環参照された言葉は「筆者には自明だから説明するまでもないこと」または「筆者も実はよくわかってないこと」のどちらかに分類されるのではないかと思う。こうした言葉は、別の場所で自分で理解せざるを得ない。
また、知らないことだけでなく知っている言葉でも、その理解度次第ではとてつもなく難しく感じる文章に進化する。
たとえば、完全に説明できる言葉の理解度を100%・未知語の理解度を0%として、理解があやふやな言葉の理解度を50%としたとする。そうすると、あやふやな言葉が10個入った文章の理解度は、50%の10乗で、0.09%まで低下する。理解度が90%の語でも、20個あるだけで12%まで低下する。この数値は、掛け算で雑な計算をしただけなので、実際のところは実験なりなんなりしないとわからないが、ともかく、あやふやな理解の言葉ばかりが並んでいる文章を読み解くのが困難だということそれ自体には納得していただけるものと思う。
自分では100%理解していると思っている言葉でも、実際には98%程度だということもある。むしろ、100%理解している言葉などないと思ったほうがいいかもしれない。相手の人生とこちらの人生が違う以上、全く同じ意味で使われている言葉などないものだ。未知語うんぬんにとらわれず、どの語が理解を妨げているか検出できれば、あとは調べるだけになる。
事細かく書かれた描写を読み解くのはとても難しい。１つ１つの文も異様に長くなるため、本来は平易な概念でも、ひとつの考慮漏れも逃さないようにするために緻密に書かれ、そのせいで難しくなることがある。
厳密にするのは必要なことも多いが、概要を示さないでいきなり厳密な論理展開を始める文章も多い。そうした文章は、読者に対して概要提示を忘れていたり、概要提示が雑だったりすることがある。
そうしたとき「これはとても難しいことを言っているけど、もし単純に捉えるとするとどうなのだ」ということを考えると、急激にわかりやすくなることがある。
未知語うんぬんの項でもそうだったが、「わかっている側」からは「わからない側」が何を知らないのか一切つかめないこともあるため、「わかっている側が想像する知らないであろうこと」と「実際自分が知らないこと」に大幅な差があることがある。その差には、どのような手段でもいいから、自分で気づく必要がある。
例示・図示などで、二重に説明されていない文章もまた難しい。まず、文単体では理解しがたいものや、直観に反する文があったとき、それが筆者の思った通りのことなのか、筆者が誤って書いたものなのか、自分が間違った理解をしているのか、全然わからないものがある。文だけで全く疑問に思わず次に進められれば問題ないが、ひとたび疑問に思うと袋小路に入ってしまう。そうしたときに「例示・図示されていないからわからない」と気づくことが必要になる。
興味関心の部分に通じるものでもあるが、信頼していない筆者の文章というのは読めないものだ。「本当にコイツが言ってることは正しいのか？」と思うと、すべての文に対して正しいかどうかの考察を入れることになる。
ほとんどの人は、反ワクチン・天動説・電波洗脳陰謀・宗教団体関連の文章は読むに値しないと考えていると思う。これに関する是非は置いておいて、これらの書物になんら信頼を感じてない人にとって、これらの書物を読むことは大変困難になる。すべてを検証しなければいけないからだ。そういう人よりも、全幅の信頼を置いて読み進める人のほうがスッと「理解」していくことだろう。
基本的に、普通の人達にとってこうした書物をたくさん読むのは苦痛でしかないはずだ。たくさん読めば「ミイラ取りがミイラになる」ような状態になりかねないし、それを読んでいることで他者から嫌な目を向けられることを避けたいはずだ。興味も信頼も一切ないのに、そうした文章を大量に読むのは難しい。
「その文章を読む価値があるのか」という想いの度合いが薄ければ、それに応じて文章は難しくなってしまう。
TypeScriptとは、プログラミング言語の１つだ。これを学習することで論理的思考力が養われ、読解力が上がり、難しい文章を読むこともたやすくなる。実際に私もそうだ。
実はこれは文章にだけ言えることではない。共通して言えることは「その難しいことをやるだけの価値があるのか」「自分の人生の一部という、他にも選択肢がある中での、かけがえのない時間と交換するだけの価値があるのか」というモチベの部分にある。モチベは時間に応じて減衰していくので実際には習慣をつけるという能力も必要だが、点火点であるトリガーではモチベは有能な起爆剤になる。習慣化や自分のスケジュールに組み込まれることによって、必要なモチベの量はだんだん減っていくこともあり、モチベだけがすべてではないが、基本は「価値あるぞ」と思えるかどうかだと思う。
本質的には、難しいことそれ自体は難しくない。難しいものにぶち当たったときに「それを突破する価値がある」と考えられるような自分の状態を作り上げることが必要なのだと思う。
これが難しい。自分には突破できるという信念（自信）や、それを裏付けする成功体験や、たとえ無駄になったとしても人生において問題ないという経済状態、あなたならできるのだと根拠はなくとも言ってくれる身近な人なども必要になってくる。これが難しいのだが、しかしそうした環境を手に入れるためにどうすればいいかは、ここまで読み進めてこられたみなさんならもうおわかりだろう。
TypeScriptのことを調べているんだけど、メインストリートであるESがリリースする前の機能をTypeScriptがすでに取り込んでいているらしくてめんどくさーってなってる。
TypeScriptがトランスパイルするって書いているけどbabelも必要なんだよな？よくわからん。javascriptといううんこの上に建築物を構築していくと足場が悪いのでかなりだるい。
年収270万の元増田です。2013年のフロントエンド界隈にいた（jQuery と Adobe Flash）のですけど、今って本当に700万近くまでもらえるのですか？例えば、React や Vue を TypeScript でかけたりするとどれぐらいもらえるのでしょうか。
自分は 2013年ぐらいに Java で Android と iPhone にて Objective-C で、jQuery でブラウザのフロントエンド部を書いていたら、強制的に Spring Framework で SQL バリバリのバックエンドを書くように指示されて、しかも AWS EC2 の上でプロダクション用の構成をつくったりしてたのですけど、２社目の社長に「職歴が浅いから、月給25万円ね」と言われて、絶望した記憶があります。
＝＝＝＝＝
東大卒のヨーロッパでエンジニアやっている人から解説しよう。（ちなみに医学部は防衛医大に補欠合格していた）
エンジニアになるより医者やっていたほうが（国内で頑張る分には）絶対いいと思う
ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。
おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。
エンジニアも厨ニ病でマウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、
表面的な知識を羅列しているところがあったので突っ込んでいく。
ー＞そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて
できる領域が狭いので給与が低い、またおそらくDCL、DML、DDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。
＝＞全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。
現場に放り込まれても１０年ぐらいかかる。というより、フロントからバックから低レイヤから、モバイルまでやることはもはや現実的ではない。
＝＞QUICとかマイナーなプロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語４文字を羅列するのは厨ニ病すぎます。
=>自分はcloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう
本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」
＝＞こんなにあれこれ、やっている時間はないでしょう。趣味のサイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな？どういう利用シーンかというと膨大なログの収集等で使うのだが（ただのNoSQLではない）、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます？ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisもちゃんと使えてる？pub/subとか分かってないと思う（普通に理解する必要があんまない）
それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味にマウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。
ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる
＝＞MyISAM をInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。
＝＞ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的な数字にしてたらばれなかったのにね。
Next でSSRまで踏み込むと結構、フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな？
＝＝＝＝＝
ー＞アメリカの事情は知らないはずなので知らないことは書かないようにしましょう。
ー＞ヨーロッパでは白人様はHRとかマーケやってます。移民にたよってます。ロシア、ウクライナ、インド、パキスタンなど
なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上
（年収270万で）プログラマーを引退して、医学部にきた俺が真面目に考えてやろう。
真面目に読んでいて、ちょっと気になる箇所がある。たとえば PostgreSQL を postgre とか書くヤツは現場では嫌われるぞ。少なくとも postgres と書いてくれ。お里が知れるぞ。
消えていくエンジニアの特徴だけど、叱責されたり馬鹿にされるのが嫌で VCS にコミットしないヤツ、または貪欲にコードレビューをされるのが嫌がるやつは、成長しない。
この業界は数年前には『デジタル土方』と揶揄される業界でした。ちなみに、アメリカでも「テック系はハードだから避ける」という雰囲気でした。つまり何をいいたいのかというと、ソフトウェアの開発者っていうのは「泥臭い領域」なんだよ。エリートとは程遠い場所にあるというね。
いやぁ、是非とも楽天で働くべきだよ。どうせ野村総合研究所とか NTT DATA なんて無理だと思うから。
うん、ココはまずい。基本的にフロントエンドなんて給料が安いのよ。だって、誰にやらせてもデータベースにクソなDCLを飛ばせないから。逆に、データベースを触れることができるプログラマーはリスクと責任が大きいから、給料が高いのだよ。B4 になってもそれが理解できていないようだと、この先くらいよ。
君はソフトウェア・エンジニアになりたいのだろ？世の中は分業で成り立っているのだから、全部やろうとするやつはアホだよ。
インターン生はお客さんなの。君のスキルが通用したのはすごいと思うけど、同じ感覚で仕事はできないから注意しときなよ。
なに言ってるの？そんなことは言い訳にならんよ。プログラマーになりたいのだろ？勉強をしろよ。
逆にいうと、あなたがインターンとして週３で20万円貰えていたのは、参入障壁が少ないからでしょ？強強エンジニアが生き残っているのは、それだけすごいということだよ。
いやぁ、違うと思うよ。その問題が「難しい」なら切り分けて、上に「ココが自分の能力では解決できないです」と持っていくだけなんだからさ。CS じゃないのだったら、仕事をするまで「扱わないまま」なんだよ？しかも、土日に勉強する気もないとなったらいつするのさ？
諦めなよ。ソフトウェアというものが「変化できることに価値がある」ものだから。変化する業界はストレスフルだけど、立身出世する可能性が高いでしょ？安寧なばしょではないの。
いやー、CSでない博士課程に行って、雇ってくれる企業があるかね？無いと思うけどな。
この時点で、君はコピペしかやってきてないことが理解できる。おそらく QUIC か MQTT あたりだろ？逆にいえば、それが実装できたら他社と差のつけられるプロダクトだったはずだ。つまり会社の利益の源泉であった部分をみすみす実装できないようでは、そこらへんの専門卒以下だぞ。
ムカつくというか、虫酸が走る書き方だ。箇条書きにすると、
プログラミングに年齢はないから。自分は９歳ではじめたけどね。
あー、俺も天才が高校のときにいて、マーチの情報工学と旧帝の院の学費を会社持ちという驚異的なやつがいたよ。今もブログ見てると、Android と iPhone のアプリを書いているみたいで、元気そう。
それを上手にコントロールできるプログラマは世界中にもほとんどいねぇ。むしろ、月20万でやるもんならギルドから苦情が来るぞ。オレもアビームの人に給料を答えたら、「こんなヤクザな会社はやめろ」と耳うちされたよ。
人より良い経験をしたいという願望はあるのは素晴らしいと思うよ。しかしながら、君が到達したノウハウは他人にもできることだからね。ワン・オブ・ゼムになりたくないなら、努力し続けることだな。勉強をするのをやめたら、数年で中卒に負ける世界だからな。覚悟しとけよ。
P.S. 医学部に来たのは家庭の都合だよ。それに、自己顕示しないと「場末のコーダー」で読んでもくれないだろ？年収については、自分も低いと思うよ。なぜ低かったかというと、都内私立大学多浪中退の自分にはベンチャーの皮を被った助成金搾取がメインの反社会的勢力のフロント（ベンチャー）企業ぐらいしか相手にしてくれなかったからだよ。そこの会社は外国帰りの MDMA をキメて、未成年の子女に手を出しては警察沙汰スレスレのことをしているキチガイが社長をやっていて、人工知能を作ろうと学生インターンを酷使している会社だったのだけど、「サイバーエージェントに紹介する」という嘘にひっかかって、特定派遣事業の免許がないのに客先常駐させられ、土曜は帰社日、日曜は社長の Python の勉強会に参加させられる、というブラック会社にいてピンはね率（60%）となると、まともに考えることもできず働くアリになってしまってたからだよ。
P.S. ② 年収については、初日から派遣先の会社に引き抜きのオファーをもらって、２ヶ月後に新しい会社に移動したけど、300万だったので CodeIQ というサイトで転職をする準備をしていたよ。たしか、DMM とかサイバーエージェントの面接にいこうとしてたような記憶。その後で家庭の都合で、医学部に来たけど。
P.S. ③ 医学部医学科の６年生だよー。みんなが嫌いな私立医学部だけどね。ちなみに、俺もこの大学が嫌いだ。
P.S. ④「GraphQLをわざわざ書くのは理解できるけどな。」そうだとすると、REST や SOAP も書かないとまずくない？書くのだったら「Rails と Next のデータ受け渡しにGraphQLを使った経験が」という感じだと良いと思うけど。
P.S. ⑤「野村総研とデータを挙げるあたりSI寄りの仕事してたのかな。 」ちゃうねん。オレっちは多浪したからさ、そこのエントリーシートをかけなかったのよね。まぁまぁ大学が名門でさぁ、OB が誘ってくれるけど、年齢で弾かれて辛かったねん。
P.S. ⑥「ダウト。学費をどうやって稼いだんや 」えぇ、親の金です。だから家庭の都合でと書いてるじゃろ。
P.S. ⑦「本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」たしかにおかしいよな。Kubernetes や Terraform を弄って、CI は GitHub Actions、CD には AWS CodeDeploy を使って、ブログは Jekyll で静的サイトジェネレータを使いつつ、自前のサービスを立ち上げるために Rails, Next, React, PostgreSQL, Redis, Kafka, Elasticsearch, S3 の勉強をしつつ、スマホ環境のために Kotlin と Swift を触れているなんて変だよな。そういえば、Docker が来るまでは Vagrant で環境をつくっていたのも忘れてたよ。あと Rust を今年に学ぶ言語にするなんて、受験生にあるまじき行為だよな。うん。
P.S. ⑧ 年収については、基本給が 22万で、残業が200時間超えたらプラスだった気がする。あと、反社ベンチャーは「ポートフォリオの作成にまる一ヶ月間で拘束された、しかも無給で」という時点でヤバいのだけど、その会社にコミットしたのは「サイバーエージェントに紹介する」ということだけであって、同時期に DMM も面接に行けそうだったのよね。馬鹿なことをした。
P.S. ⑨「特にフロントエンドを見下す感じとか」オレ自身はフロントエンド出なんだよ。何を隠そう、Adobe Flash のゲームをつくっていたから。それでもって言うよ、バックエンドが一番大切だと。
P.S. ⑪「5～10年前に人売りに捕まった話とするなら、年収270万も現実味を帯びる。」特定派遣は消えてくれてよかったよ。俺のところは特定派遣すら未登録だったけど。
P.S. ⑫「いい医者になるのだよ 」うん、頑張る。「オッサン」「社会不適合者」「あるき方がキモい」「プログラミングwww」「同じ班になりたくない」「親も頭が悪い」「生きてて恥ずかしくないの？」とか言われてるけど、頑張る！
P.S. ⑬ 「フロントエンド別に給与低くないよ。」えっ、そうなの？WebDesigning を読む限りだと、400万もいかないイメージだけど。
P.S「医学部6年でまだプログラムに興味あるの不思議。」好きなんだよ、言わせるな///
P.S. 「フルタイムじゃないのでしょ？」いいえ、東京都内でフルタイム（ひどいときで、朝7から夜24）でしたよ。入った会社が「法律よりも、派遣先の評価」という会社だったからね。
P.S. サイバーエージェントさん、ときどき御社の社名を使って「弊社に恩を売ると、サイバーエージェントに紹介する」というベンチャーが跋扈しているので、どうにかしてください。わたくし、１ヶ月間もその嘘で jQuery と Django を回収させられた挙げ句、月給 2000円だったのですけど。本当に千円札２枚だったのですけど。ついでに、Android（Java） と iPhone（Objective-C）と jQuery を使ったフロントエンドシステムに、バックエンドに Rails + Postgresql のシステムで、AWS を介したサービスを作らされたのも「サイバーエージェントに紹介する」と言われたからなんですけど。いったい、何なんですか？お前ん所は、コンプライアンスどうなってんじゃ。
P.S. 「好きそうだし医学部卒業してシレッとgoogle行ったれ 」無理っすよ。オレのスキルじゃ。
P.S. 「病院は」親がクリニックを持っていたけど、潰したよ。クリニックは人に患者がついていて、アルバイトを充てがっても患者さんが不幸になっていくのをみちゃったからね。自分は責任を持って患者さんを見たいから、バイトなんて使わないよ。
P.S. 自分はコードを書きたいタイプだったから、SIer みたいな UML とか書いて下請けにコードさせるみたいなのは絶対に嫌だったのよね。だから SIer にはならなかったよ。やっぱり、現実にある計算機が解決できる問題を、より直接的に触れて解決したいと思っているから。仕事がハードでも全く問題なし。
P.S. FPGA すごいよね。ザイリンクスとアルテラが Intel と AMD に買収されて、すごいと思ったよ。2010年頃だっけ？、CPU の限界を FPGA で突破しようという話があったけど。手を出そうと思ったけど、高性能なチップが 100万ぐらいして挫折した記憶があるよ。
P.S. 「東海大の医学部・学士」は自分は大学を卒業してないから無理でした。あと、それ以上の詮索はやめてくれ...
P.S. 「MySQLそんなに嫌いなのか。」そんなこと書いたつもりはないが、あれ？確かに MySQL は PostgreSQL より嫌いたけど、それは Oracle が親元だったり、Unicode の扱いがファッキンだったり、ストレージエンジンが切り替わるときにカオスな目にあったけどさ、MySQL は好きだよ。お世話になったし。
P.S. 給料については契約後に言われたのよ。というか、もともとは「サイバーエージェントに紹介」するという理由で、ポートフォリオの作成や Django の改修を手伝ったつもりで、入社とかする気は全く無かったのよ。それが、いきなり他所の会社に面接を受けさせられて「君は明日からXXで働くから、履歴書を書いてね」と言われて、抗議したら「俺に恥ずかしい思いをさせるのか！業界に入れなくするぞ！」と大声でシャウトされて、気がついたらあっちが用意した履歴書に拇印してしまったのよね。有料職業紹介と派遣登録をしてない会社だったから、そんなかとはできないはずなんだけどね。ホームページには「年収550万」と書いてあったけど、実際はまったく違ったのだけどね。
P.S.「うーん、いらないかな。IT土方としての仕事しかないと思う。」だよな。おとなしく医者になるよ。ありがとう。
P.S. Elasticsearch は全文検索機能がほしいからやってるよ。Redis はインメモリなセッションストアとして使いたいのよ。Kafka はさ、twitter のファボをじっそうしたいけど、RDB の書き込み速度が上がらないから利用したいの。TensorFlow は全く理解できてないよ。それは、指摘されたとおり。
逆に聞くけど、以下の知識があったらどれぐらいもらえるわけ？東京23区で。
俺が初めて「DV」って言われたときに何をイメージしたかわかるか？
「Digital Video」やぞ！もしくは「Digital Visual Interface」だ！！！
DVに男が引っ付いて「DV男」って表現を見たときの俺の宇宙猫はどれくらい大きかったかわかるか！？
「TS」！お前てぃーえすぅぅぅぅぅうううう！！！コラお前マジでホントいい加減にしろよ！！！
TS言われると日本人なら先ず「TSマーク」思い付いちゃうだろ！情報技術者なら「TypeScript」だ！！！もしくは「Transport Stream(MPEG-2 TS)」
TSで男女の話題からめられて「ママチャリ？」みたいに最初マジで思ったんだぞ！直ぐに「あっ何か違う・・・」って気付いたけど！！！
良いか？アルファベット2文字略語は2028パターンしかねぇんだよ！アルファベット3文字略語は17,576パターンだ！！！
※ 再ポストを許してくれ。どうしても、聞く人がいないのだ。
当方は、元プログラマー。今となっては、家庭の都合で引退した身。嫌なことがあって、久しぶりにプログラミングを勉強したら楽しくて仕方ない。
たとえば、Ruby on Rails, Next with React on TypeScript とか最高にイカしていると思ったし、Kubernetes や Terraform で AWS, GCP を触れば IaC に感銘したし、Kafka や Elasticsearch といった NoSQL が RDB が進歩した上で共闘している様は夢のようだ。PHP や Java も元気にしていて、おじさん嬉しいよ。（最近の流行りだから Docker も触ったが、Vagrant なんかを触れた身からすると、正当な進化だよね。）ただ Python が人気なのは理解できないし、そんでもって C は苦手なままだけどな。あと、CSS と HTML のナレッジのアップデートについていけないのは歳のせいだろう。
閑話休題。それでタイトルの質問なんだけど、今のモバイルアプリの開発手法について知りたいのだ。もちろん React Native といったものがあるのは知っているが、この手のものは好きになれないのよね。どうしても無理から生じる齟齬が気になっちゃうし、もっと言えば「プログラミングを介して、設計思想に触れたい」からね。
まず、iOS の話題から。今は iOS は SwiftUI だけで書けば良いのかしら？昔は Objective-C と Storyboard を使っていたけど、新規のプロジェクトだと無視してもよいのよね？いや、だめだったら追加で勉強するだけだから良いのよ。その、加減がわからなくてね。自分としては Swift言語が好きで、SwiftUI は StoryBoard よりマシだと思うから、そこは問題ないのよね。10年前より、絶対に良くなったと思うし。あと SwiftUI と Swift言語の example 集とか、CocoaPods のまとめサイトなんかを教えてほしいな。公式だけじゃ物足りない。
次に Android なんだけど、現行なのは Kotlin言語 + Android Studio の UI ビルダーを強制なんでしょ？昔は Java言語 + XML の MVC という感じで、当時としては iOS よりまともなイメージだったけど、最近ふれたら蕁麻疹が出そうだった。なんというか、ちょっと体が受け付けない感じがする。だから、Android は昔の開発手法で良いのかを教えてほしい。あと、iOS と同様に example を大量に載せたページをお願いします。
こんな感じかな。追加で知っておくべきことがあれば、嬉しい。たとえば、PWA とか。自分としてはモバイルのプログラミングが理解できたら、ブロックチェーンや人工知能を除くと、ここ10年のナレッジはキャッチアップできたつもりなので満足なんだよね。あと気力があれば、作成物を増田に晒すかもしれないです。
ごちゃごちゃしたモデルがほいほい操作できて、Formもちょちょいと書ける。
テストもモリモリ書ける。
想像していたよりずっと良い。
気持ちがいい。
私ハマっちゃうかも。
でもFormでちょっと動的なことをしたいな、ってだけで、CoffeeScriptと格闘する羽目になってとても苦しい。
CoffeeScript辛いから全部サーバに処理させたいけど、そうなると、簡単な動的操作でも画面更新と履歴積み積みになってそれはそれで酷い。
というかCoffeeScriptむちゃくちゃ見辛い。地獄。なんだよこのインデント。
辛い。
病みそう。
RailsはAPIだけやってろって言う人の気持ちがよくわかった。
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
