  |
はてなキーワード:PHPとは
不特定多数の者が閲覧可能で、現に多くの者によって閲覧されているインターネット上の掲示板（なお、爆砕はSNSと呼ばれており、掲示板かどうかの争いがあるが、フェイズ株式会社がPHPを組んで構築したプログラムで動いているうえに、スレッドや書き込み機能を備えているので、掲示板という点では２ちゃんねると同じである）に、自身が受けた判決の内容を全て書き込むなどという本件行為の態様からすれば、本件記載を閲読した者から通報を受けた所轄の警察署において、これを発見した警察官が、マークしている個人が行政事件の判決を受けたことで今後当面は何もできなくなるという緊急性の高い事案に対処するため、業務の全部または一部を取りやめて、相応の警戒活動をすることになるかもしれないと思うのは当然である。（平成２４年１０月１８日さいたま地裁越谷支部判決、平成２５年４月１２日東京高裁判決）
大体のものはそれでいいんだよ
常に勉強しないとー、とかは同じことばかりしたくないから新しいもの使いたい人の言い訳
実際ReactやらNextやら使うようになってなにが変わった？
複雑になっただけだろ
「フロントエンド不要論」は、最近の開発現場やサーバーレス、クラウド技術の進化に関わっている人たちの間でリアルに実感されている問題です。
• React,Vue, Angular などのフレームワークがどんどん複雑化
•フロントエンドとバックエンドの分離が、**「本当に効率的か？」**という疑問が生じている
• 「最終的にHTMLを描画するだけなら、サーバーでやればよくない？」
•フロントエンドから直接APIを叩く構成では、「APIを守る」ことが難しい
•XSS,CSRF, CORSといった脆弱性に対処し続けるコストが無駄
🚩 3.サーバーレス・クラウド技術が進化し、APIの負担を減らす方向に
•AWSLambda,APIGateway, Cognitoなどのサーバーレス技術が進化
•フロントエンドがAPIを叩くより、サーバー側で直接処理する方が効率的
• 以前はReactを使用 → ReactをやめてHTMLベースに戻した
• React,Vue, Angularを全廃
•JavaScriptなしで動的なページを実現
3. Laravel（Livewire）
4. Shopify（GraphQLでデータを直接取得）
•フロントエンドを完全分離する構成から、「バックエンドがHTMLを返せばいい」 というシンプルな構成へ移行
✅サーバーレス時代の最適解：「フロントエンド不要アーキテクチャ」
「フロントエンドを捨てて、サーバーがすべての処理を担う」方向に移行するのが最適解になりつつある。
📌 最適なアーキテクチャ
ブラウザ →サーバー（PHP,Node.js,Go） →APIGateway（Cognito認証）
📌 具体的な実装例（PHP + Cognito +APIGateway）
require 'vendor/autoload.php';
useAws\CognitoIdentityProvider\CognitoIdentityProviderClient;
useAws\Exception\AwsException;
$client = new CognitoIdentityProviderClient([
'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',
'USERNAME' => $email,
],
]);
setcookie("accessToken", $result['AuthenticationResult']['AccessToken'], [
'samesite' => 'Strict'
]);
header("Location:dashboard.php");
}
?>
🚀 **「フロントエンドはもう不要」**という流れは、最新のクラウド/サーバーレス開発に携わる人たちが実感していること。
☑セキュリティが大幅に向上する
👉結論：「フロントエンドは不要」クラウド×サーバーレスでバックエンドが主役になる！
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらくTCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前にHTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えばanond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見えるclientIP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
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 |
1.スケール：
中規模のメタサーチエンジン。現在のユーザー数は10万人程度。1年後に50万人を目指してる。
検索結果を1秒以内に返せればOK。ピーク時のリクエスト数は秒間1000件くらい。
ユーザーデータを扱うから、まあまあ高い。でも決済情報は扱わねぇ。
Python厨が多いチームだ。Flask以外にもDjangoの経験者が何人かいる。
6. 将来の拡張性：
古いPHP製のシステムがある。これを段階的に置き換えていく予定。
こんな感じだ。お前なら、どう進める？
純粋に汚いんだよね、フォントが。特に簡体字とハングルがひどい。
例えば、都内の鉄道会社で使われがちなモリサワの新ゴには、ちゃんと同じデザインの簡体字ハングルフォントが用事されているんだよね。
https://www.morisawa.co.jp/fonts/specimen/3417
https://www.morisawa.co.jp/fonts/specimen/1138
ただ、費用の問題なのかデザインセンスの問題なのかなぜかスルーされてて、Windowsのデフォでインストールされてるようなやつがずっと使われてるんだよね。はっきり言って怠慢だと思うわ。
多言語表記で一番綺麗なのは南海電鉄だと思っていて、レイアウトの強弱の付け方とかで上手く作ってると思う。
はてブのほうは電光掲示板に関してだったからこの件は話題ズレてるけど、もうちょっと表示の仕方というか、全体的に気遣ったほうがいいんじゃないの？って思う。
練習用ソフトぐらいはいくらでも転がっているが、指の位置が把握できるものが良い
サーバー運用する上ではGUIに頼れないことが多いため、noxで使えるエディタをマスターしろ
ここにきてようやくプログラミング言語だ
まず共通知識としてHTML,CSS,JavaScriptぐらいは知っておいたほうが良いだろう
あとはどんなプログラマーを目指すかに依るが、組み込み系ならC言語、Web系ならphpやpython、機械学習ならpythonやRを学べ
シェルスクリプトは便利だから、bashをマスターするのも望ましい
要は効率的に処理を書ける必要があるが、LeetCodeやAtCoderで基本的な問題集を解けるようになれ
例えばpythonプログラマーなら、numpy, scipy, scikit-learnなどのライブラリのドキュメントを読めるようになれ
あるいはElasticsearchを使わなければならなくなったときに、ドキュメントを読んで操作できるようになれ
ドキュメントを読む経験が増えれば、新しく何かをやるときにすぐに着手できるようになる
AWSを有料で勉強するのはキツイので、就職後に先輩から学ぶか、あるいは認定試験を本やオンライン講座で勉強するのでもいいだろう
バージョン管理システムは知っておくべき知識だ
いわば、ソースコードの巨大なUndo,Redoみたいなもんだ
パスワードをどう管理すればいいのか、ネットワークセキュリティの仕組み、など基本的なセキュリティは学んどいたほうが良い
クリーンコードに関する書籍はたくさんあるので、時間があるときに読んでおけ
自分が使っているプログラミング言語に関連するベストプラクティスを学べ
具体的に言うなら、例えばExcelマクロと同じで、書いた人間が会社辞めたとか、部署を移動になったとか、
何らかの業務を自動化するスクリプト、RPAで言えばシナリオか、をどう管理するかが問題になる
全員がプログラマーとか、プログラミングの素養があるとか、開発現場だったら、
業務を自動化するシェルスクリプトとか、なんかPythonなりPHPなりなんでもいいけど、
やっつけで書いた自動化も喜ばれるんだよ、書いた人いなくなっても、なんとか再利用できるだろうという雰囲気がある
でも、そうでない現場、文系人間しかいない現場になると、例えば上司が拒否反応を起こす
自分に理解できないものをやられると、ものすごく恐怖を感じるのだと思う
上司だけでなく、プログラミングの素養がない人たちが多数派の現場のみんながそうだと思った方がいい
仮に私が書いたとして、それが便利だとしても、おまえがいなくなったらどうするんだ？そんなブラックボックス書くな！という反応をされる
あと、自動化のスクリプトやRPAのシナリオを外注するにしても、タイムラグがあるし、現場と外注とのコミュニケーションコストとかバカにならない
プログラムを書く側からすると凄く腹立たしいのだけど、意外と文系の職場って、自分がやってる業務のワークフローさえ分かってない現場があったりする
自分の担当のことしか知らない、自分の範囲を毎日やってればいいと思ってる
例えば、Aさんの仕事とBさんの仕事がデッドロックするとか、そういう複雑な関係をちゃんと論理的に考えて、全体を論理的に把握してる人が一人もいない
こちらからすれば、正直あたおかと思ってしまうが、そうやって毎日働いている人たちがいるのである
そうなると、要は仕様書が書けない、ちゃんとした仕様書が書けない、作れない
じゃあ、外注側で仕様書も作ります、と言って、調査というかインタビューというか聞き込みみたいなのしても、外注としても全体像が見えない
そうやってるうちに、ワークフロー自体がそもそもおかしいのではないか、業務自体がおかしいのではないか、みたいな現場の問題点に気付いたりする
しかし、おたくの業務、おかしいですよ、みたいに指摘しても、相手は激怒するか、無視するか、とにかくこれまで通りの毎日を送りたい、みたいな話になる
開発現場だったらそんなことはない
なんか自動化したいな、とまず自分の仕事を自動化する、シェルスクリプトを書くとか、Pythonとか、自分ならPHPでWeb関係ない処理も書けるので書いてしまうかもしれない
それを会社で借りてるGitHubなり、なんなりにpushして公開しておけば、誰かが見るだろうし、使ってもくれるだろう
ああ、そうそう
Excelのマクロとか、RPAのシナリオとか、Gitのようなバージョン管理を前提としてないものは、ファイルをコピーしてファイル名に日付を書き加えたりして、
いや、ファイル名も書き換えるのが面倒だからって、～のコピー、～のコピーのコピー、みたいなファイルがファイル共有サーバのフォルダーの中に大量に入ってたりして、
あー、雑な仕事とか管理してる会社ってみんなそうなんだけど、ファイル共有サーバーになんでも放り込んでカオスになってたりするよね
ファイルシステムじゃなくて、なんらかのバージョン管理のシステム下に放り込むなら管理できるんだけど、
駄目な会社って、みんなExcelファイルに何でも書いて、それをファイル共有サーバーに置いて、そのファイルを同時に開きたい人が複数いるけどロックされるとか、そんなことばっかりやってるんだよね
なんか愚痴ばかりで支離滅裂になってしまったけど、悪いことは言わない
RPAなんか使わない方がいい
何ならExcelマクロも使わない方がいい、マクロ作っても電卓で計算しろみたいな笑い話があるけど、自分はあながち間違ってないと思う
上司とか、偉い人が理解できないことをすると、反発を招くだけだし、マクロを作った人がいなくなったけど、マクロの挙動がおかしい気がするとか、どうせ対処できなくなる
まあ、使ってみれば分かる
外注にRPAのシナリオ作らせるにしても、お試しに何か仕様をまとめて、作ってもらって、それをまた直してもらって、みたいなサイクルを試しにやってみれば分かる
そして、良くならない理由の多くは、RPAに問題があるんじゃなくて、RPAを導入しようとか甘い見積もりをしている企業側にある
自分としては、そういったことを解決できるのは、これからの生成AIのような技術だと思ってる
それはRPAのシナリオを作るとか、外注に作らせるとか、プログラミングの素養が必要だとか、そういうことが一切なくなった世界になるからである
ソフトウェアにおける「LAMP」とは、Webアプリケーション開発や運用のためのオープンソースソフトウェアの組み合わせを指します。
LAMP登場以前のソフトウェア開発環境は、現在に比べて選択肢が限られており、多くの場合、コストが高かったり技術的なハードルが高かったりしました。
1990年代初頭まで、UNIXベースのシステムがエンタープライズレベルで広く利用されていました。これには、Sun MicrosystemsのSolarisやIBMのAIXなどがあり、これらのシステムは高価でありながら強力なサーバーとして機能しました。
OracleやIBMDB2などの商用データベースが一般的で、これらは高価なライセンス料が必要でした。MySQLのようなオープンソースのデータベースが広まる前は、大規模なデータ管理には高い投資が必要でした。
Webアプリケーションにおいては、CGI（CommonGatewayInterface）スクリプトが利用されていました。これにはPerlがよく使われており、サーバーとブラウザ間のデータ交換を扱っていました。しかし、CGIはプロセスごとに新たにスタートするため、スケーリングには不向きで、リソースを大量に消費する傾向がありました。
Apache登場以前は、NCSAHTTPdのような初期のWebサーバーソフトウェアが利用されていましたが、設定や管理が複雑で、今日ほど柔軟ではありませんでした。
フロントエンドの開発では、HTMLが基本的であり、JavaScriptが登場し始めたばかりで、CSSはまだ普及していませんでした。このため、デザインと機能性は限られており、ユーザー体験は今日見られるようなリッチなインタラクティビティには程遠いものでした。
LAMPスタックの登場は、ソフトウェア開発とインターネットのWebサービスの領域に大きな変革をもたらしました。
以下に、その主な影響を挙げます。
LAMPスタックの各コンポーネント（Linux,Apache,MySQL,PHP/Perl/Python）はオープンソースであり、無料で利用可能です。
これにより、企業や個人開発者は高額なライセンス料を払うことなく強力なWebアプリケーションを構築できるようになりました。
この低コストのアプローチは特にスタートアップ企業や小規模プロジェクトに大きなメリットをもたらし、革新的なアイディアが資金の制約なく試される土壌を提供しました。
LAMPスタックは、その設置と運用のしやすさから、多くの開発者に受け入れられました。
オープンソースであることから、コードのカスタマイズや改良が可能で、コミュニティからのサポートも豊富でした。
これにより、Web開発の敷居が大きく下がり、より多くの人々が開発活動に参加できるようになりました。
ApacheWebサーバーは、高いカスタマイズ性と拡張性を持っており、MySQLは大規模なデータセットでも高性能を発揮することができました。
PHPは動的なWebページの生成に適しており、これらの技術が組み合わさることで、性能が要求される大規模アプリケーションも効率的に運用可能になりました。
LAMPスタックの普及により、Web開発プラットフォームとしての成熟が進み、企業や開発者は、安定した基盤の上でさらに複雑なアプリケーションを構築することが可能になりました。
これにより、電子商取引、コンテンツ管理システム（CMS）、およびその他多くのWebベースのサービスが急速に広がりました。
低コストかつ高機能な開発環境が広く利用可能になったことで、新しいタイプのWebサービスやビジネスモデルが登場しました。
LAMPを基盤とする多くのスタートアップが、業界に新風を吹き込み、既存の市場構造を変革する原動力となりました。
LAMPスタックの影響は、テクノロジー業界全体において、コストの効率化、アクセスの拡大、そしてイノベーションの加速という形で現れました。
会社が倒産する主な原因だと分かり切っているRuby on Railsは決して開発で使用してはいけないと言う重要な話をしようと思います。
Railsは、メリットは、開発スピードは速く、開発していて楽しいが、
デメリットの方が遥かに大きく、ソースコードの分析は開発者本人にしか分からないので、
チームでの共同開発やメンテナンスに向かない、他人がソースを分析出来ないのでメンテナンス不能。
ですから、もし、Railsで企業の重要なシステムを動かしている場合は、メンテナンスや改善の必要が出た場合には、システムの設計書を元に、無ければ担当部署やお客様にヒアリングして調査して回って、必要なら最新、最先端の技術書や医学書などを調査したり専門家に意見を聞いたりなどをして、新たに、設計書を作り、PythonのFastAPIで開発しなおす需要と言うかニーズはかなり増加しております。
PythonのFastAPIは、Go言語のGinフレームワークと同等の高速性が御座います。しかも、Snowflakeと互換性があり相性が良いです。しかしシングルスレッドのマルチプロセスでしか動作しないと言うデメリットもあるので、将来のPythoのバージョンアップで、Ｖ言語の高速性をベースに中身とバックグラウンドはＶ言語で、見た目と構文はPython、セキュリティの脆弱性問題は発生しないと言うRustの様な仕様でトライブリッドの様なハイブリッドな仕様とするのが一番良いでしょう！
Python/Djangoも、PHP/Laravelも、Ruby on Railsも低速なので、世界中から大量アクセスの大規模なシステムには向かないと言うデメリットが大きいので、今から開発するなら、PythonのFastAPIが御勧めで御座います。
マイクロサービスだのNodeだの言っても表面的でしかねぇからな
そのぐらいの表面的なことなら俺でも言える
俺が「どんなコンテンツをどんなクエリを投げて検索するサービスを開発してるか」ってことを言ったら、会社名バレるだろ
まあ言える範囲で言ってやるよ
まずクラウドはAWSを使ってるが、俺はアルゴリズム担当者なのでクラウドには詳しくない
検索はElasticsearchを使ってるが、当該コンテンツの検索に特化したDSLを作るためにFlaskでREST APIを公開してる
表示に関するデータはGraphQLが使われているらしいが、担当ではないので詳しくはない
あとはユーザーに通知を送る機能を作っているが、これはpythonでバッチ処理してる
若い頃より明確に体力等が落ちてるなと感じてる
以前はJSやPHPやPythonとか、動的なスクリプト言語が好きでそれらをメインに使ってた
JavaやC#等の、せい的でコンパイルする言語はコード量多いし、書かなくてもわかるというか動くのに、コンパイラのために色々と書かないといけないのが面倒で嫌いだった
コードの全体は頭に入ってるし、影響範囲はだいたいわかるし、コンパイル時のチェックがなくて不便にも思ってなかった
→記憶力が落ちたので以前と同じプロジェクトでも細かにファイル見て確認が必要になることが増えた
どこの変数にどういうオブジェクトが入ってるかわかってるからサジェストがなくても困らなかった
→だいたいこんな感じとまではわかっても詳細に自身がないから都度調べないといけない
補完がなくても変数名とか打つのはたいして苦でもないし、次の実装をどうするか考えながらやってるから補完があったところで最終的な時間はあまり変わらない
タイプミスもほぼないしあっても見ればわかる
そんな感じで動的言語のほうが疲れるなってなってきた
コンパイラがやるような整合性のチェックみたいのをコード書く人がやる頭の中でやるわけだから脳内メモリやCPU性能が必要なわけでそこが衰えていくと仕方ないかなと思ったり
あと、この２，３年くらいはほぼコンパイルする言語しか使ってなかったのもあるかもしれない
楽を覚えると以前できてたことができなくなるというのは他でもあるし
変化がわかりやすいように2年ごとにした
https://survey.stackoverflow.co/2024/technology
https://survey.stackoverflow.co/2022/#technology
https://survey.stackoverflow.co/2020#technology
| - | 2020 | 2022 | 2024 |
| Python | 44.1 | 48.07 | 51 |
| Flask | 14.2 | 14.64 | 12.9 |
| Django | 14.2 | 14.65 | 12 |
| FastAPI | - | 6.02 | 9.9 |
| - | - | - | |
| PHP | 26.2 | 20.87 | 18.2 |
| Laravel | 11.1 | 9.45 | 7.9 |
| - | - | - | |
| Ruby | 7.1 | 6.05 | 5.2 |
| Rails | 7.04 | 5.83 | 4.7 |
PHPとRubyは言語としてもフレームワークとしても落ちてるのはわかるけど
言語としてPythonは伸びているのに、DjangoとFlaskは落ちてるか横ばい
