  |
はてなキーワード: typescriptとは
学歴がよくなくて、就職が困難だったので中小 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系の技術が好きで、可処分時間を使って夢中になって勉強したり色んなものを作って遊んだらして過ごしてきたからこそ今がある。でも正直少しでもプログラミングができるならアカデミアに残るより民間に就職した方が待遇もワークライフバランスもいい。きちんとリサーチすればカルチャーだってすごくいい会社はたくさんある。
それを承知の上でアカデミアに残る人は正直すごいと思う。自分がその立場にいることを想像したら気が狂いそうになる。もし似た立場で迷ってる人がいたら心から伝えたい。アカデミアやめて本当によかった。
TypeScriptが使われてるプロジェクトだったから仕方なく使った
面倒な型を書いてる分、色々楽になることを期待してたが思ってたのと違った
JavaScriptだとある場所の値がなにかわからない
コードを追うのも大変だからbreakpointの設置かdeubugger文を置いてたりして、値とスタックトレースを見てみる
TypeScriptだと静的だからクラス名がわかってすぐにどういう値になるかわかると思ってた
だが実際には型は具体的なクラス名じゃなくてインターフェース（もしくはtype）
それだけだと◯◯ってプロパティがあるという情報はわかっても具体的な値まではわからない
最低限◯◯があるだけで書いてないけど実は✕✕もある可能性はある
実装を見るにはそのインターフェースを実装するクラスを探すしか無い
ある程度大きいプロジェクトなら多数見つかるし、呼び出し場所を見てコードを追わないと実際にどれなのかはわからない
結局breakpointかdeubggerを使ってどんな値なのか見てる
それってJavaScriptと一緒
全然楽にならない
あとは補完がちょっと便利になるくらいだけど、JavaScriptだって静的解析をある程度やってくれるし補完はそこまで便利になった感を感じられてない
TypeScriptって静的型付け言語やってるとなんてことはないのばっかりだけど
動的型付けばっかやってた人には馴染みがなさすぎるのでは？
JavaScript → モダンフレームワーク→ Typescript
の学習ってかなりキツそう。特に初心者からのロードマップがイメージできない。
Javaメインの開発やってた人より。
TypeScriptなんて、JavaScriptで書いておいて拡張子だけ ts に変えればいいだけじゃないの。
そりゃ、TypeScriptの全機能を使うのは無理かもしれんけどさ。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1397787.html
https://2022.pycon.de/program/SBCNDY/
Ruby on BrowserとかPython 3.11 in the Web Browserとか
そういうの求めてないんだよなあ
こいつらよりTypeScriptの方が100万倍優れてるから
https://www.publickey1.jp/blog/22/javascripttypes_as_commentsjavascripttc39.html
Javascriptが登場したころはVBでさえ、型宣言は省略せずにしっかりしようって言われてたのに、その後Perl、Javascript、Ruby、PHP、Pythonなど、動的型の言語が広まってしまう。
その後に一部で関数型の言語が流行ったり、Rust、Go、TypeScript等が影響力をもって、JS,Ruby,Ｐｙｔｈｏｎでも型チェックのしくみを取り入れようという動きがでてくる。
・機械工学は大学で学んだ。機械系４力学のさわりだけなら大体やったがもう忘れている。
・切削加工はけがき、フライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ３Dプリンタでなんでも作れるらしいが、３Dプリンタは触ったことがない。
・CADは大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。
・シミュレータはANSYSをマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。
・電気工学はだいぶ勉強不足。簡単な回路図はチップの製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメ。ArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。
・化学系は全くの無知。大学受験で知識は止まっている。物性物理的なところも無知。
・数値計算はPythonやMatlabでちょっとできる程度。ライブラリを使った行列計算や簡単なニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分や常微分方程式を調べて思い出せばできる程度。測度論とか特殊な積分とかいわゆる大学数学的な道具が必要になる解析はできない。
・競技プログラミングはちょっとかじったがやめてしまった。むずかしすぎた。
・機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定１級落ちた。
・バックエンドはSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaはJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった＆謎のSegmentation Faultで苦手意識を残したまま。Go？Rust？なにそれおいしそうだね。
・クラウドはAWSをマニュアル通りに使っている程度。１から設計なんてできない。なのでAWSのソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。
・ネットワーク系とかセキュリティ系は全く勉強不足。応用情報をギリギリ合格できる程度の知識しかない。わかるようにはなりたい。
・フロントエンドはFlutterを勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離がありすぎてよくわからない。javascriptはjQuery一強時代にちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript？なにそれおいしそうだね。
・ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。
全部中途半端だな、、、
結局まともに扱おうとするとtype hint書くことになるし、マジで動的である利点が無い
動的型付けの言語にも利点はあるという主張は（自分は同意しかねるけど）理解しているが、今のPythonの用途で動的であるメリットが皆無
機械学習やっててPyTorchとかTensorFlowとか既存のライブラリがPythonだから仕方なくPython触ってるけどマジでさっさと淘汰されてほしい
それかJavaScriptにおけるTypeScriptみたいなのがPythonにもほしい
