まずはHTML から。その後はCSS、JavaScript、Linux、GitHub、Ruby、HTTP、Nginx、データベース、Ruby on Rails、ポートフォリオ制作、就職活動、の順番で進める予定です。
エンジニアとしての就職を目指すことにしました。
https://www.youtube.com/watch?v=boKMk36ugkw

よくわからないけど、

まだ若い（20歳？）んだし色々やって頑張ってほしい。

そして動画で嘆いてほしい。

コメント欄も応援しているようで、破滅に向かわせているような人もいるけど、諦めるな！！

Permalink | 記事への反応(2) | 16:57

2025-03-21

■新卒 銀行3ヶ月退職→未経験 エンジニアを目指す「みるる」君を応援！

https://www.youtube.com/@Miruru72

Youtubeのおすすめに流れてきた。

大げさな言葉と酒と自称鬱で「人生終わったわ」が口癖のイキる大学生時代の友達を思い出す。

正直みるる君のことをバカにする気持ちはあるが、嫌いではない。

等身大の自分が動画に表れていていいね。

チャンネル登録者数も1250人と伸びていて期待大。

銀行を辞めて、エンジニアを目指すらしい。

まずはHTML から。その後はCSS、JavaScript、Linux、GitHub、Ruby、HTTP、Nginx、データベース、Ruby on Rails、ポートフォリオ制作、就職活動、の順番で進める予定です。
エンジニアとしての就職を目指すことにしました。
https://www.youtube.com/watch?v=boKMk36ugkw

よくわからないけど、

まだ若い（20歳？）んだし色々やって頑張ってほしい。

そして動画で嘆いてほしい。

コメント欄も応援しているようで、破滅に向かわせているような人もいるけど、諦めるな！！

Permalink | 記事への反応(2) | 23:22

2025-03-16

■フロントエンド 不要論

「フロントエンド不要論」は、最近の開発現場やサーバーレス、クラウド技術の進化に関わっている人たちの間でリアルに実感されている問題です。

✅ 最新の開発現場で「フロントエンド不要論」が出てくる理由

🚩 1. フロントエンドが複雑すぎる（技術負債が増大）

• React, Vue, Angular などのフレームワークがどんどん複雑化

• SPA（シングルページアプリ）のメンテナンスが大変

• フロントエンドとバックエンドの分離が、**「本当に効率的か？」**という疑問が生じている

• 「最終的にHTMLを描画するだけなら、サーバーでやればよくない？」

🚩 2. フロントエンドのセキュリティリスクが高すぎる

• API キー、アクセストークンの露出問題が深刻

• フロントエンドから直接APIを叩く構成では、「APIを守る」ことが難しい

• XSS, CSRF, CORSといった脆弱性に対処し続けるコストが無駄

• 「フロントエンドで認証情報を持たせないほうが安全」

🚩 3. サーバーレス・クラウド技術が進化し、APIの負担を減らす方向に

• AWS Lambda, API Gateway, Cognitoなどのサーバーレス技術が進化

• フロントエンドがAPIを叩くより、サーバー側で直接処理する方が効率的

• バックエンドがフロントの役割を代替できる環境が整った

✅ 実際にフロントエンドを捨てた企業の事例

1. GitHub（Hotwire, Turboを採用）

• 以前はReactを使用 → ReactをやめてHTML ベースに戻した

• サーバーサイドでレンダリングし、最小限のJSだけ利用

• 「HTMLはサーバーで生成すれば十分」と結論付けた

2. Basecamp（Turbo + Rails）

• React, Vue, Angularを全廃

• Turboを使って、サーバーから直接HTMLを更新

• JavaScriptなしで動的なページを実現

3. Laravel（Livewire）

• JSなしで動的UIを作るフレームワーク

• フロントエンドの負担をゼロにする方向に進化

• 「JSが不要なら、開発効率が上がる」

4. Shopify（GraphQLでデータを直接取得）

• フロントエンドを完全分離する構成から、「バックエンドがHTMLを返せばいい」というシンプルな構成へ移行

• APIの負担を減らすことで、開発効率とセキュリティを向上

✅ サーバーレス時代の最適解：「フロントエンド不要アーキテクチャ」

「フロントエンドを捨てて、サーバーがすべての処理を担う」方向に移行するのが最適解になりつつある。

📌 最適なアーキテクチャ

ブラウザ → サーバー（PHP, Node.js, Go） → API Gateway（Cognito認証）

• フロントエンドはHTML/CSSのみ

• サーバーがAPI GatewayとCognitoを仲介

• API キーやアクセストークンはサーバーで管理

• サーバーがデータを取得し、HTMLとして返す

📌 具体的な実装例（PHP + Cognito + API Gateway）

require 'vendor/autoload.p hp';

use Aws\CognitoIdentityProvider\CognitoIdentityProviderClient;

use Aws\Exception\AwsException;

$client = new CognitoIdentityProviderClient([

'region' => 'us-east-1',

'version' => 'latest',

'credentials' => [

'key' => getenv('AWS_ACCESS_KEY_ID'),

'secret' => getenv('AWS_SECRET_ACCESS_KEY'),

]);

$email = $_POST['email'];

$password = $_POST['password'];

try {

$result = $client->initiateAuth([

'AuthFlow' => 'USER_PASSWORD_AUTH',

'ClientId' => 'XXXXXXXXXX',

'AuthParameters' => [

'USERNAME' => $email,

'PASSWORD' => $password,

]);

setcookie("accessToken", $result['AuthenticationResult']['AccessToken'], [

'httponly' => true,

'secure' => true,

'samesite' => 'Strict'

]);

header("Location: dashboard.php");

} catch (AwsException $e) {

echo "ログイン失敗";

}

• API キーをクライアントに公開しない

• アクセストークンをサーバーが管理

• フロントエンドは何も持たない（XSS耐性あり）

✅ まとめ：「フロントエンド不要」が最新の開発トレンド

🚀 **「フロントエンドはもう不要」**という流れは、最新のクラウド/サーバーレス開発に携わる人たちが実感していること。

☑ API キーの管理が楽になる

☑ セキュリティが大幅に向上する

☑ フロントエンド開発の負担がなくなる

☑ パフォーマンスが爆速になる

👉 結論：「フロントエンドは不要」クラウド×サーバーレスでバックエンドが主役になる！

この方向性に完全に共感しますし、今後の開発では**「フロントエンドなしで済むか？」**を常に考えるべきですね！

Permalink | 記事への反応(3) | 14:13

2025-03-12

■求人 ボックスの求人 件数の変化

求人ボックス

https://xn--pckua2a7gp15o89zb.com/

技術	1月3日	3月12日
rails	22,891	27,570
node.js	12,829	16,178
Django	13,348	17,054
Flask	1,589	1,907
FastAPI	1,210	1,509
Laravel	26,879	32,624
spring	16,380	23,965
spring boot	5,110	7,002
React	49,465	65,273
Next.js	7,382	10,288
Vue	34,322	45,354

言語	1月3日	3月12日
Ruby	61,479	94,975
Python	98,527	179,183
PHP	92,129	142,628
JAVA	124,840	232,585
Javascript	99,212	237,094
Typescript	65,828	91,348
Rust	3,807	21,921
Go	48,000	183,352

Permalink | 記事への反応(0) | 18:56

2025-03-10

■LLMで50個くらいのjavascriptのvarをconst,letに置き換えさせたら

1Mトークン以上かかったわ

Permalink | 記事への反応(0) | 10:01

2025-03-07

■anond:20250307111030

私デザイナーだけどVue.jsとか、Javascript書けるならできるよー！ってエンジニアさんに言われたけどむずかったわ！！！

でもすごい頑張ってちょっとだけ書いたらウケてた。

出来合いのをちょっと変えるくらいならできる！ちょっとくらいならな…

Permalink | 記事への反応(1) | 11:17

■

プロンプトどうでもいい論を唱える奴がマジで理解できないんだよな

誰かが用意した物をコピペしてくるか、バイアスに従ったスタンダード出力しか必要としてないなら確かに考える事はほぼないのは分かる

ていうかそもそも「プロンプト」なんてCLI コマンドと一緒、と言い切るにはランダム性があるんで意味は共通だとしか言えないが

「ディレクトリ内のファイル一覧が欲しい」のか「サブディレクトリ一覧が欲しい」のかでコマンドが変わるように

結局ユーザーの望む出力を促すためのもんでしかないんだから「必要な出力を引き出すための手段」くらいの認識でいいってのに

プロンプトエンジニアリングという言葉をやたら大袈裟に考えてる傾向にあるんだよな、忌避してる奴は

簡単な例で行くと「テトリス作って」「Javascriptでテトリス作って」「C#でテトリス作って」全部得られるもんは違うわけだ

んでもって更に要件があるなら、それは指示に組み込まないとAIに伝わりようがない

「これ調べて」「これ調べて箇条書きで整理して」「調べて解説しつつブラックジョークを言って」これも全部成果が違うだろ

AIによっては日本語や特定の和製英語、独自の業界用語が理解できないものすらあるよな

じゃけん適切に指示を出しましょうねと

そういうもんでしかないものがどうでもいいも不要になるもあるかと

推論モデルであっても、勝手にCoT始めるからといって要件無しじゃAIの獲得した一般常識に従って動くだけだぞ

どこまで言ってもそれが仕様だ

西野カナのトリセツを見習え

まぁメモリーに色々埋め込んでおけば、言葉少なでも期待通り動いてくれるかもしれんが

その実態はつまり事前入力してるだけのプロンプトや

メモリーが充実してる二人の間にはもう言葉はいらないってか？　やかましいわ

Permalink | 記事への反応(1) | 06:47

2025-03-06

■ブクマ エントリーページを開くブックマークレット

ちょっと長いけど、拡張機能より便利かなと。

javascript:(()=&gt;{const%20loc=document.querySelector('link[rel="canonical"]')||location;const%20urlStr=(loc.href.startsWith('about:reader'))?decodeURIComponent(loc.href.slice(17)):loc.href;const%20url=new%20URL(urlStr);let%20s=url.search;s=(s.startsWith('?page=')||s.startsWith('?P='))?"":s;const%20w=window.open('https://b.hatena.ne.jp/entry?url='+encodeURIComponent(url.origin+url.pathname+s));w.document.close();})();

canonical 指定があればそちらのURLのエントリーを参照する
page=かP=のクエリを無視して元URLのエントリーを参照する
Firefoxのリーダーページ（about:reader）からでも元URLのエントリーを参照する

Permalink | 記事への反応(0) | 08:48

2025-03-04

■AJAX。Google Maps の開発した、史上初の非同期コンテンツ 更新 技術。

「…先輩、これは一体どういうことですか…？これはただの非同期通信です。

「あれが AJAX (エイジャックス) だよ。Google Maps、このサイトの技術は革新的すぎたんだ。20年前にこのサイトが公開されてから、世界中のIT エンジニアたちがAJAXをこぞって研究、解析した。

わずか数年でAJAXはWEB制作の技術体系に組み込まれ、新しいAPIによる強力なフレームワークが開発された。

最終的にはJavascript 本家のAPIにも取り込まれ、AJAXは革新的技術ではなくなった。今では単なる『非同期通信』と呼ばれているよ。20年はWEB 業界にとって相当長い時間らしい。

Permalink | 記事への反応(0) | 16:11

■anond:20250304084013

必要なコードはたったこれだけやから

(function(){
  if(!window.getSelection || !window.getSelection().containsNode) return;
  Array.from(document.links).forEach(link => {
    if(window.getSelection().containsNode(link, true) === false) return;
    if(link.href.startsWith('mailto:')) return;
    if(link.href.startsWith('javascript:')) return;
    window.open(link.href);
  });
})();

ワイはこれをShortkeys拡張を使って [O] キーに割り当ててるやで

Permalink | 記事への反応(1) | 12:19

2025-03-02

■

こいつの俺がそうだから全員そうだみたいな思考どうにかならんの？

リプでもいるけど大雑把に分けるとJavaScriptやPythonなどのスクリプト系をメインにしてるいわゆるWeb エンジニアがろくに中身を知らないだけでは

気持ちは分かります。

とても分かるんですが「自分で中身を理解していない構造化もしていないプログラムなんて発展の余地ない」は単なる我々の願望でしかないと思うのです。

プログラマーは巨人の肩の上に乗っているだけであり、ライブラリやハードウェアの技術を「すべて」理解できていません。 https://t.co/rozACcWuX4— いぐぞー ✈️ 旅するプログラマー (@igz0) March 1, 2025

Permalink | 記事への反応(2) | 20:51

2025-02-28

■anond:20250228045849

今の時代ならJavaScriptとかPythonでいいのでは…😟

Permalink | 記事への反応(0) | 05:00

2025-02-20

■3大間違えると恥ずかしい勘違い

「JavaとJavaScriptは全くの別物だよ」

「SixTONESはシックストーンズじゃなくてストーンズって言うんだよ」

あともう1つは？？

Permalink | 記事への反応(1) | 20:57

■

2025-02-19

■anond:20250219013915

やり方は色々あると思うんだよな

一回押したら押せないようにするとか、ユニーク IDをhiddenに隠すとかさ

って、AIに聞いたほうが早いか

AI ちゃん

SNSでボタンの連打による連投を防ぐための修正方法として、以下のバリエーションが挙げられます。

ボタンの無効化: 送信ボタンをクリックしたら、jQueryなどのJavaScriptを用いてボタンを無効化する。これにより、ユーザーが連続してボタンを押すことを防ぎ、多重送信を回避できる。ただし、ボタンを押した後に何らかのチェックを行うようなシステムの場合、再送信ができなくなる可能性があるため注意が必要。
同一内容の投稿制限: X（Twitter）では、全く同じ内容の投稿を複数回行うことができない仕様になっている。同じ内容の投稿をしようとするとエラーメッセージが表示されるため、テキストの一部分を変更して再度投稿する必要がある。
アクション数の制限: 一定時間内に実行できるアクションの回数に制限を設けている場合がある。
ユニーク IDをhiddenに隠す: 多重送信を防ぐ方法として、サーバー側で処理を識別するために、ユニーク IDをhiddenフィールドに含めることが考えられる。