  |
はてなキーワード: node.jsとは
ほいノ
高専行こうと思えば行けたんだけど、実家離れるの怖くて偏差値45の工業高校へ。
18歳までフリーター。
18歳〜21歳まで定時制に通った。
英語は個人的にそこそこ勉強したけど、数学なんかはⅠの後のAが半分も終わらなかったレベルのバカ校。
この時期は暇で、なぜかやる気に満ち溢れてたから、TOEIC700近くとか日商簿記2級とか色々資格を取った。
24歳でうつになって、30歳くらいまで日雇い・派遣↔無職を半々くらいでリピートしてた。
やってる仕事は大したことなかったけど、幸い仕事中にPCをめちゃくちゃ使うのでやりたい放題だった。
この時にプログラミングを始めた。
ここで年収どんどん上がった。
36歳でうつが再発して辞めて今に至る。
基本は、仕事で使えそうなもの・必要なものをその都度吸収していった感じ。
Webが中心ではあるけど、組み込みとかのハードが絡む分野以外は結果的に広く浅く手を出してる、つもり。
| Excel VBA | 1年 |
| VB.NET | 半年 |
| JavaScript（Node.js） | 4年 |
| HTML | 1年 |
| SQL | 4年 |
| GAS | 3年 |
| C# | 1年半 |
| TypeScript | 2年 |
| Java | 半年 |
| C++ | 半年 |
| ラダー、FB（三菱、シーメンス） | 1年 |
実務経験があるって胸張って言えるのはこれくらい。
大体習得順。
他には、Python、Julia、R、Fortran、Rust、Go、Dart、Shell、Deno、CSSなんかは少しずつかじってる。
最近はWebに関してはほとんどJS（TS）で済む感じになったので楽。
なんでPLCが最後やねんってツッコミは置いといて、Web系寄りでラダーも触ってるって人は観測範囲ではあんまりいないので、それが俺の数少ない強み。
RDBはPostgreSQL、SQL Server、MySQL、SQLiteの順で実務経験あり。
NoSQLはFirestoreが実務経験あり、実務なしだとNeo4jとか。
PaaSはGCP（Firebase）、AWSの順で実務経験あり。AzureはADとVM周りをちょっと触った程度。
Dockerはよく使うけどKubernetesとかまでは行ってない。
後は産業用の通信プロトコル的なやつを無駄に色々触ってる。Modbus TCPとかORiNとかCC-Linkとか。PLCもそうだけど、あの辺は日本とドイツとアメリカが未だに既得権益で幅利かせててまじで闇深い。その代わりそれをブレイクスルーできればめっちゃ稼げる分野だと思う。
閑話休題。
フリーターでどんな仕事してるか知らないけど、仕事で一日の半分が無くなっちゃうじゃん？
以下、俺の場合ね。
次長クラスの人が「この製造番号でクレームがあったんだけど、作業当時どんなことあったか覚えてない？」みたいなことをわざわざ現場まで何度も聞きに来るんだよ。
作業したのなんて半年前だったりするから一々覚えてないっすよ、って言ってるのに何度も聞きに来るから、イラッとして仕事用のPCで勝手にExcelで業務日報を付けるようにして、イントラのファイルサーバーに置いて「そういう時はこれ見て下さい。次長の貴重な時間が勿体ないです」って言ったのよ。
それだけでめちゃくちゃ喜ばれる。
で、今度はその次長が「この製造番号どれくらいの時間で作業終わった？」みたいなことを現場までわざわざ何度も聞きに来るから、俺はその時またイラッとして、Excelでストップウォッチもどき作って製造番号とか工程ごとに時間計測して記録して、やっぱりファイルサーバーに置いて「これ見て下さい」って言ったのよ。
それでまた、めちゃくちゃ喜ばれる。
最初はプライベートな時間も結構使ってやってたんだけど、そういう周りに喜ばれる効率化を繰り返してると、少しずつ業務時間内で自分のスキルアップに直結する時間を作れるようになる。
自分でこれ面倒くせーな、効率よくできねえかなって思ったら、じゃあどうやって？てのを考える。
ちなみにPCがなくても、たとえばメールアドレスさえあれば今の時代カイゼンはできる。
大きな会社に勤めてるとかだと使うのが難しいんだけど、IFTTTとかが良い例かな。
これはiPaaSっていうサービスの一種で、まあ言葉の意味は覚えなくて良いんだけど、要は「イベントAが発生したら別のイベントBを起こせ」っていうのを登録して、自動化できるWebサービス。
例えば、あなたが日雇いの会社にいて、毎日違う現場に働きに行くとする。
で、出勤前、現場到着時、勤務終了の時にLINEで毎日報告しなきゃいけないとする。
で、その報告を受けた事務方は、Googleスプレッドシートにその都度入力する。つまり、それだけの為の事務員が一人いる。
面倒くさいし、お金がかかる。
そこで、「特定のグループでLINEを受信したら（イベントA）、特定のGoogleスプレッドシートに情報を記録せよ（イベントB）」っていうのをIFTTTに登録すると、少なくとも事務員の入力の手間は省けるってえ寸法だ。
IFTTTはたくさんイベントを処理させたい場合は有料になっちゃうけど、個人で試すぶんにはクレカ登録しなきゃいいだけだから試してみるといいよ。
月1000円で学べる。コスパは圧倒的。
入門コース（学習に180時間と公称してる）がしっかり理解できていれば、Webで大抵のものは作れる。
ただし、大筋は問題ないんだけど、細かい部分で最新技術をキャッチアップできてない可能性があるので、そこは注意した方が良いかも。
https://www.nnn.ed.nico/pages/programming/
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。
そしたら、職歴書の作り方次第で中小企業の社内SEにはまず転職できる。
中小企業の社内SEは、ITリテラシーの低い社員が多い中で「Excelのセルの色が変わらなくなっちゃったんだけど！」とか「複合機が紙詰まりって言ってるけどその紙が見つからない！」とかクソイージーなクエストをこなすだけでおちんぎんが貰える、人によっては天国、人によっては地獄のような職業だ。
ごめん、流石に言い過ぎた。実情は色々と面倒くさい。DXとかバズワードを聞きかじったクソ重役から突然言い渡される重めのミッションとか。
けど安定なのは間違いない。
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。ここは社内SEと同じ。
生産技術ってのは、誤解を恐れずにすげえ簡単に言えば、カイゼンばっかりやってる人たちのことだ。
あんまり詳しくは言えないんだけど、俺が最後にやっていた仕事は言わば生産技術だった。
で、中小企業の生産技術は、Webに強い人材をかなり欲しがっている。有り体に言うとIoTとかね。
IoTは最近、セキュリティの強化がかなりクローズアップされていて、そのせいで二の足を踏んでる企業が多い。
そこに滑り込むのはアリだと思う。
よく「T型人材」って言われ方をするけど、どっちのスペシャリストの言うこともある程度分かる「橋渡し」的な人材になると途端に貴重になって需要が増すので、上昇志向があるなら「Web+何か」の組み合わせでお金稼ぐのが良いんじゃないかな。
ま、橋渡しって自然とプロマネとか任されがちで、裁量大きくて大変なんだけどね。
質問あればどうぞ。頑張って。
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
node.jsやってるけどjavascriptと同じように書いて動くのでどのあたりが難しいかもわからんし素のjavascriptと何が違うのかもわからんやで
https://d.potato4d.me/entry/20220405-nodejs/
が話題になっているけど、本来人類に必要なのはクロスプラットフォームな実行環境であってNodeじゃない。
TSが流行ったのはJSがクソだから。BabelしなきゃいけないのもJSにトランスパイルしなきゃいけないからであって、必要なのはJVMやCLRのような言語実行環境。
Reactが流行ったのはshadow domだけど、必要なのはDOMじゃなくてちゃんとした「アプリ」開発用のイベントモデルとレイアウトマネージャ含むGUI環境。
フロント界隈の流行廃りって本質的な改善ってよりもほかの良い技術をいかにブラウザ/Electron等JSエンジンという限られた環境に持ち込んで幸せになるかがメインに見えるので地獄に見える。
「アプリ」書くのになんでドキュメント記述用のHTMLに今ものっかってんだよと。
MavenやらGemsができて依存管理楽になったとか、RailsがでたときのようなCoC良いねとか開発の考え方を変えるフレームワーク、 rspec/Cucumberがでてテスト最高とか、c10kも怖くない非同期I/Oとか、好きな言語が使えるJVM/CLRそもサーバーならrustでもgoでも好きなものが動くとかとか本来の開発を楽にするという意味のブレークスルーってあんまりみられない気がしている。なんでフロント界隈の新技術ってあんまりわくわくしない。
逆にちゃんとしたクロスプラットフォーム実行環境がブラウザしかないということなんだけど、ブラウザなかなか進化しないし RIA は Apple 様が切り捨てるからなぁ。
ということですべてはブラウザが悪い。JavaScript 以外がちゃんと動くクロスプラットフォームのGUI環境が必要。でもプリインでモバイルでも動いてOSから独立して協調して作られていて、Webという既存の大量の資源にアクセスしやすいものは現時点で実質ブラウザ一択。つまりWASM に期待。次にHTMLであるべき文書はともかくSPAなんてもう「アプリ」なんだからHTML手書き文化もうやめてネイティブアプリ並みの GUI 作成環境も復権しよう。
するとクライアントでも好きな言語が使える。そして同じ言語がいいとサーバサイドで Node.js を使う必要もなくなりへっぽこプログラマが Node のイベントモデルを理解せずに使うこともなくなる。
そしてそれらができたときに Node というか JS/HTML の呪いから解放され人類に平和が訪れるのだ。君はその後も Node.js を使っても良いし使わなくてもいい。
契約してる1つのサーバで個人ブログとか昔ながらのBBSとかブラウザゲームとか種類が違うサービスをいくつも運営しているけど、サーバの運用方法が流石にレガシーすぎるからもうちょっとモダンな感じにしたいと思ってる。
でも中々抜け出せない。
まず前提としてAWS,GCP,Azureは高いから使えない、同スペックなら適当なVPSの方が圧倒的に安い。
最近流行りのコンテナ構成みたいなのもいくらDockerが昔のVMに比べるとリソース食わないと言っても例えば
「1つのサーバで10個のサービスを相乗りで運営しなければならない」みたいな場合に1サーバ内で何十コンテナ起動みたいなの運用すると流石に相当重くなっちゃうよなぁ。。。
あとnode.jsとかginみたいに1サービスごとに常駐プロセスが増える技術スタックも多分あんまりよくない、必要ポートを管理するのも大変
結局自然と行き着くのは格安VPS借りてLAMP構成作ってVirtualHostで相乗り設定して昔ながらの方法で運用する方法になっちゃう
php+apacheの構成ならアクセスの少ないサービスを何十個運用しようとアクセスがないならそれにリソース食われることがないんだよね、何気にLAMP環境の結構な強みだと思う
もっと良い方法見つけたいし、多分お金かければあるんだろうけど
月2000円以内くらいで多くのサービスを運用したいってなった場合に結局これ以外の選択肢ってなくない？
月1～2万円みたいな額はインフラエンジニア雇う費用に比べると全然安いんだろうけど、ポケットマネー基準だとそうもいかない
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
昨日見つけたいくつかのGitHubのリポジトリを面白く眺めてる
20代のフランス人だったり、40代のブラジル人だったり、色々である
ブラジル人は体力有り余ってるのか、
絵だとやりにくいなぁ、と思ったりする
みんなでブクブク浸かって楽しむみたいな世界は、
で、思ったのは、やはりプログラミングというのは、
過去のゲームがルールの発明だったこととかは古臭いものとなり、
コードも言葉と同じように無償で自然と発するものに近づいていく
ここで思うのは、スティーブ・ジョブズがこの世界をIBMの、
いわゆる、ソフトはハードのおまけ、の世界に戻したことであり、
ビル・ゲイツだったか、ソフトウェアは無償化していくという予言は当たっていたのだろう
それをマネタイズするには、ApacheでWebサービスを立ち上げるみたいな、
いわゆるGNUライセンスであれ、運用やサポートではお金が取れるが、
Node.jsを開発したら、開発者は当たり前だが一番Node.jsに精通しているわけで、
企業を顧客にNode.jsのサポートを有償ですることでマネタイズできる
ソフトウェアは無償化し、コードは会話のように無償で、ライブなものになり、
あー、そういう世相を予測して、
先に牛耳っておこうという点でMicrosoftによるGitHub買収は正しかったのである
ソフトウェアがなんでも無償に向かうのはMSとしても良くは思えない動きだったはずだが、
今はまったく反対方向にMSは向かっており、収益の基盤をAzureなどに移している
今すぐはありえないが、WindowsというOSも意味はなくなっていく
これはAppleやGoogleのような企業でも同じ考えのように思う
もちろん、そのレベルでのシェア争いや小競り合いが今すぐ消えてなくなるわけではないが、
長い目で見ればいつかはそうなっていくことは容易に予想できるわけで、
つまり、ソフトウェア産業というか、近年のバズワードでもあるテック産業というのは、
人生だって、みんな崖に向かって歩いたり、走ったりしてるだけである
その崖がどれだけ近いか遠いかとか、どれぐらいのスピードで崖に向かってるかとか、
それだけの違いであって、誰もがいつかは崖に到達して落ちる、つまり死ぬのである
しかし、そこには一発逆転や一人勝ちするチャンスも乏しくなり、
そういった金を求めるギラギラしたアブラギッシュは寧ろ嫌悪される存在となり、
しかし、そうやってった末に待っているのはコモディティ化であり、
ただの暇つぶしにさえなっていく
今は楽しい
でも、その楽しさの果てに死が待っている
なんか今頃になって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やった方がいいと思う
スキルというか"プログラミング"についての理解が足りてないだけだと。
適材適所。スキルレベルも含めて、そのとき一番"自分に"いい(楽とかスキルアップ)と思うものを選べばいいのでは？
なければ自分でやる。そもそも連携可能でなければ出てこないし、労力に見合わなければやらない。
Pythonからエクセルを動かすのは、試してみたが、VBAマクロの方が楽に感じる。操作を記録する機能はあるし、そこから不要部分削ったりすればよく、Pythonでエクセル動かそうとすると読みにくいし何やってるか結局わからない。
汎用型か、特化型か。Pythonで楽になるならVBAマクロはいらない。汎用性無双ならアセンブラか機械語でプログラミング言語は止まってる。
プログラマーの人はエクセルなどを嫌うけれど、matplotlibを細かい調整しようとすると調べて描画し直してを繰り返さないとならず、GUIでポチポチ調整する方が楽に感じてしまう。
エクセル含め便利なツールはがっつり使う。楽だから。エクセルで辛くなったら、GUI=>VBAマクロ=>自作ツール。GUIで楽なら無駄に自作ツールなんか作らない。楽になりたい時だけ
個人でGUIを作るとして、ボタンやプルダウンは簡単だけど、マウスを使ってインタラクティブになるとググってもすぐ出てこない。
Python使いじゃないのでなんともだけど、PythonオンリーならDjangoとか？
PythonはGUIが得意な印象がないので、自分ならJS(TS)+Pythonで。Python部分は必要最小限にして、Node.jsで呼び出しか、ReactでAPIコール。
@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年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
