  |
はてなキーワード: Jsとは
どうも、覚えてる人がいてくれると嬉しいけど何年か前にプログラミング完全に理解した程度でプログラミングの覚え方を語ってしまったおばさんです。
あの後おばさんはプログラミングの仕事をすることになって、今はプログラミング完全に理解したを超えて、プログラミングなにもわからない未満くらいのおばさんになりました。
おばさんは今、PHPとRubyとJSを書いて暮らしています。
おばさんはプログラミングを仕事にできて、本当に良かったと思っています。
良かったこととして、やっぱりプロダクトとして動いてるシステムをいろいろみれたりとかの技術面の話もたくさんあるけど、そういうのは他の人のアウトプットにお任せして、おばさんの人生で良かったことについて話そうかなと思います。
おばさんの人生について軽く紹介した方がこの後の話が分かりやすくていいんだろうけど、いろいろあるので省略します。行間から察して。
おばさんはプログラマになれて、ようやく自分に自信がついたと思っています。
仕事ってやっぱり自分のアイデンティティに強く影響するんだと思います。少なくとも私は仕事以外だけを人生として楽しむことはできないタイプです。そんな人間だからこそ、仕事がうまくいかないことで自己評価が低かった。
でもプログラミングの仕事は、できるできないの評価が完全に他人任せにならないで、できたかできなかったかが自分でもある程度評価できるので、そういう意味で自分を支える自信を作りやすい仕事だなと思います。
それに今までの上司とかの評価もいいみたいなので、人からの評価という点においてもそれなりに自信になりつつあります。
おばさんの人生でよかったこと縛りで話すとこれだけしかネタがないけど、おばさんにとって大切なことなので書いておこうかなぁと。
【追記】
昔書いた記事ってのはこれです。
https://anond.hatelabo.jp/20190404034812
でも、おめでとうと言ってもらえて嬉しいです。ありがとうございます。
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（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
Vue.js ってよく初心者向けだとか React より簡単だとか言われてるけど、ちょっと設計をミスると簡単に破綻する欠陥ライブラリという印象をどうしても拭えないんだよな。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。
CDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。
これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタイムに更新していくことができる。 next.js + vercel などはこのあたりをフロントエンドから CDN まで一気通貫に提供することでリアルタイム風にコンテンツを更新できるように見せかけているが、 Fastly なら本当になにもかもリアルタイムで出来ることが保証されるので、難しいことを考えなくてもよい。
CDN の設定の反映の遅さというのは Cloudfront とか使っていれば感じることだと思うが、 Fastly なら 5 秒ぐらいで反映される。設定を変更しながらいろいろ検証しているときにこれが地味に嬉しい。
ただし上記の特性の代償と言えるのかもしれないが(そうではないのかもしれないけど)、 Fastly は「デカめの配信拠点を比較的少数配置する」という構成になっているため、ディザスタリカバリなどの面では不安がある(今回の障害はマジで全部落ちたのでこれとは関係ない問題だろう)。
Web 設定画面からいじれる設定項目が多く、にもかかわらずユーザーに優しく使いやすい。例えばリクエストヘッダーを Fastly 側で書き換えてもらう機能があるのだが、それとは別に Host ヘッダーのオーバーライドの設定は(えてしてよく使うので)別の画面に切り出されていたりする。
大抵のユーザーは Web からの設定画面でできることで満足すると思うが、高度な制御をしたい場合、 Varnish の設定ファイルのスニペットをアップロードしたり、あるいは設定全体を書いてアップロードする、といったことができる。例えば JWT のデコードを VCL でやってしまって、同じ URI にたいして認証済みユーザーとそうじゃない人でキャッシュのだしわけなんてことが Fastly 上でできるようになる。
ただし VCL でいろいろな制御を実現しようと思うと、 VCL の表現力の低さにより地獄を見ることになるので、得られるベネフィットと相談しながらこのあたりはやっていくことになる。
良い言語だと思うが、不満がある。
という愚痴がある。他人の書いたものを読む分には良い言語だと思うよ。
型ヒントはコンパイル時のエラーにならないじゃん。だったら、いらなくね？タプルは複数の値を返すときに使うのね。Go みたいだね。または Ruby の Struct みたいな。
あれ嫌いな人おるのか。俺も好きじゃないが。純粋に Haskell と同じ文法だったら良かったのにね。
アレはキモいね。素直に ?! で良いと思う。というか、Python は英語圏の人も納得はできないだろ、っていう文法が多くないか？
というのは同意する。ただ、書くときにそうは思わない。例えば、with 構文は Ruby の方がブロックを抜けたらクローズするという方針のが良いと思う。
当方、機械学習や深層学習に乗り遅れた（自称）フルスタックエンジニアである。プログラム言語は Java, PHP, Python, Ruby, C, Swift, Kotlin, JS, Rust 何でも好きだ。HTML/CSS や SQL も大好きだ。ところが、計算機科学という領域で次に何が来るかわからないので、増田の集合知に教えてもらいたい。最近のワードは、以下の感じ。
この手の分散型データベースは好きになれない。遅いし。それに、反社会的勢力が暗躍する領域は嫌い。
どうせ、ICT やユビキタスとかと一緒で経産省のオママゴトになるのは見えているので、反吐が出る。
計算機の演算機能が未だに不足しているので、汎用 AI なんて無理なのがわかっているはずだが、何故に人の出入りが激しい。統計的機械学習といったアルゴリズムとして利用する分には、現実的だと思うが。
良いと思うが、既存の RDB なんかで十分という気持ちがしないわけではない。
デザイン領域以外は、既存のプログラマ延長でしょう？デザインはちょっとやる気ない。
デザイナーに頑張ってもらいたい。というか、デザイナーはここは責任持ってくれ。仕事なくなるぞ。
いつもお世話になってます。
世の中の問題に全て答えがあると思っている大馬鹿者の集まり。悪趣味。
いきなりセキュリティとかテストとか運用系に行くやつの末路は暗いと思っている。プログラマが後々コンバートするので十分だろ。
俺は好きやけどね。
が見つかって俺が騒然。
TypeScript はバージョン 4.3 で、「オーバーライド」を明示する機能が付いた。
class Base { foo() { } } class Deriv extends Base { override foo() { } }
これは、TypeScript の大きなアキレス腱となる。
例えば、こう
class Base { foo() { } } class Deriv extends Base { foo(): Base { } }
コロンの後ろに基底クラス名を指定し、これでオーバーライドを明示する記法としたらどうだろう？
TS としては「foo() は Base を返すメソッド」に見えるのに……
見た目は同じなのに TS と JS で意味が異なるとなれば、TS はもう「JS のスーパーセット」と名乗れなくなるだろうし
コードを読まされるプログラマにとっても大きな負担となり、TS に身勝手な機能を取り付けていった Microsoft は
似た事は「private」で起こっていた。
TS はプライベートメンバを「private」で表したのに対し、ECMA は「#」記号で表すことにした。
しかしこれは残念ながら TS の都合とバッティングするものではなく、TS はすぐに ECMA に追随してしまった。
TS と MS を Web から追いやるには、ECMA がちょっと工夫をするだけでよい。
ECMA の動きに大いに期待したい。
徹底的に単純化、抽象化することで、馬鹿でも分かるようにしてメンテナンス性を上げるとか、（もちろんドキュメントはちゃんと書け
技術者の本懐だと思うんだけど、無暗に複雑化したい、見栄えを良くしたいという考え方がまったく理解できない
そもそも、お役所関係の仕事ってフリーランスでもみんな避けたい案件で、
一度作ったら保守とか改善をしたがらないし、それはお金の決め方が民間と違うからそうなるわけで、
逆に、余ったから道路工事みたいに予算消化に協力してよみたいになって寧ろバグやセキュリティーホールを埋め込んだりとか、
予算がないならないで公務員に勝手にいじられて無茶苦茶にされたりとか、
Google Mapsなんかも公的なサイトとか企業とかはGoogleにお金払わないと使えないわけだけど、
それも決められた予算内でだったり、稟議の遅さとか、普通のお客とは大きく異なるわけで、
あと、なんか政府も含めて、DXだのカッコイイ表現をしたがったり、ナウでヤングな開発スタイルやるぜ！みたいなノリだったり、
そういうの止めた方が絶対にいいと思う
そんなの当たり前じゃん、馬鹿なんじゃないの？と思われるぐらい単純化、抽象化するのが論理的思考の基本中の基本であって、
そこまで落とし込んでもいないのに、余計なことをするもんではないと思う
手書きのHTMLが温かみがあるｗみたいに馬鹿にする輩がいるが、
元の文章はMarkdownなりはてな記法なりで書いて、静的HTMLに変換して、基本的なCSSで充分見栄えも良くなる
というか、マイナンバーカードを申請しても返信がずっと来ないので、さっきまで国のマイナンバーカードのページを眺めていたのだけど、
「文言が下手」「文章が冗長」「同じことを繰り返し書いてないか？」「FAQが読みづらいレベル」
という感じで、これ住んでる県とか市のWebもそうなんだけど、もっと端的にズバッて書けるんじゃないの？
デジタル庁の採用ページも必要ないエフェクトとかアホかと思ったが、文言も駄目、やりなおしレベルだと思う
思うけど、なんかポエム書く人の方が出世したりする世の中だったりするのでウンザリする
要は、その上のオッサンや老人を感動させなければいけないみたいな圧力に従った方が出世したりするわけだけど、
まあ、ティム・バーナーズ＝リーとかだったら最近はどういう意見を言うのか、JavaScriptアリアリでしょと言うのか、
単純なテキストを相互に通信するのが基本だから、みたいに言うのか興味はあるけど
いずれにせよ、公的案件を普通の案件と同じに考えると痛い目に遭うし、
デジタル庁ではそういうのはやめて、モダーンでナウでヤングにバカウケな開発スタイルでやるぜ！
とか正反対に全力疾走されても不安になるんで、そういうのはやめてくださいとしか思えない
個人的には、こういうことを言うとまた馬鹿にする輩が出てくるんだろうけど、
jQueryみたいなのちょっと添えるぐらいで、それでもJavaScript切っても動作するように書けるわけだし、
とにかく、最新最近のやり方じゃないとか馬鹿にされても、余計なことをしない、
そうすることで仕事量を減らす、
基本的にJavaScriptがなければ成立しないようなページを国が必要にするようには思えない、
フォームで充分なわけで、寧ろレガシー寄りで5年10年、下手すると20年安定することを考えるべき
一方ロシアは鉛筆を、Intelではなく並列処理させたZ80を使った、
みたいにローテクでも確実に長期に動作させることを考えるべきだと思う
JavaScriptのフレームワークの流行り廃れが変わる度に無駄な税金を使われてたまるか、
という気もする
…
なんかトラブルになったときNuxt.jsのソース読まないと困ることってないの？
Lodashだったか何だったか、ちょっと失念してしまったのだけど、
動作がおかしかったのでソース読んで、時間をかけて間違いを発見して、
報告とかプルリクしようと思ったらタイミングの差で修正されてたこととか思い出すんだけど、
中国は国家公務員としてサイバー攻撃を含むハッカーが高給で雇われているわけで、
隅から隅までLinuxなり、敵国から盗んだ技術なり、戦場で墜落したドローンとか戦闘機を拾ってきたり、ワリャーグとかそうだし、
徹底してリエンジニアリングさせると思う、自分にはそういう優れた技術力はないけど
もちろん、そうやってリエンジニアリングした組み込みOSなり、
そういった知見から独自のリアルタイムOSを開発するなりして、
それをミサイルなり戦闘機のアビオニクスなりに応用していくわけだ
（というか、最近の組み込みOS界隈とか中国も含めて熱いように思ってる
だから、最近のAWSとかを中心にした開発だと当てはまらないけど、
例えばApacheとかNGINXとかだったら、本来はそのソースもくまなく読むべきだと思う
使用しているユーザーが多いから、エコシステムが機能しているから、セキュリティーも安全だろう、
みたいな発想は国のシステムや軍需産業では相応しくないように思う
まあ、だからといってミッションクリティカルなシステムにしろとかまでは思わないが、
w3mで読めるように作ってもバチは当たらないというか、
最近のネタで言うなら、シンエヴァがちょっと盛り上がってたわけだけど、
庵野さんが、オネアミスは足し算、エヴァは引き算で作った、みたいに言ってた気がするけど、
この徹底した引き算って凄い大事な考え方だと思うんだよなあ
もちろん、テレビ版のエヴァは徹底的に引き算してもあの様になってしまったわけだけどｗ
徹底した足し算から、徹底した引き算に移行した、というのは凄く良い意味で理系的発想だと思う
（でも噂から想像されるシンエヴァは徹底した引き算でもなさそうなので家で観るつもりだけど
あと、神エクセルとか誕生するのも、結局は庵野さんとかの言う徹底した引き算、
