  |
はてなキーワード: Jsonとは
第5回 Rollup のWASM buildを利用できるようにする
第4回の続き。
エラーの指示通り？に次のコマンドでrollup/wasm-nodeのなるものをインストールしたハズだが状況が変わらない。
npm i @rollup/wasm-node
切り分けのために、使われないハズの「node_modules/rollup」を削除してみる。
rm -r node_modules/rollup/
もう一回、チュートリアルの指示通りにコマンドを打つとエラーの様子が変わった。
npm run dev Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'rollup' imported from ****
つまり、インストールしたrollup/wasm-nodeは無視されてるらしい。なんでだ。
色々しらべてpackage.jsonを弄る必要があると気付く。参考にしたやつ。Thanks silvenon
以下の文言を追加
"overrides": {
"rollup": "npm:@rollup/wasm-node"
}
その後、再度「npm run dev」を実行。エラーの代わり、いくつか処理がされた後「・・・・・Killed」と出る。
もう嫌だ。飽きた。
が、ダメもとでブラウザでアクセスするとLaravel Breezeの画面がブラウザで開けるようになっていた。
第２回 Larabelチュートリアルを参考にログインするだけのWebアプリケーション(?)を作る
composer create-project laravel/laravel example-app_20240131
続いて、Composerを使用してLaravel Breezeをインストール
composer require laravel/breeze --dev
php artisan breeze:install
いろいろ聞かれる。わからん。とりあえずBlade/Yes/PHPUnitを選択。
すると「・・・・installed successfully.」と表示されたので何かが成功したっぽい。
続いて
php artisan migrate
するとエラー。
Illuminate\Database\QueryException SQLSTATE[HY000] [2002] Connection refused
そもそもデータベースの準備を何もしてなかったので、エラーが出るのは当たり前だった。
サンプル用にデータベースを作成し、それに合わせて.envファイルを修正する。
再度、
php artisan migrate
すると「DONE」と表示。成功したっぽい
チュートリアルに従い、「ウェブブラウザでアプリケーションの/loginか/register URLへアクセス」。
すると、Laravelが出してるっぽいエラー
Illuminate \ Foundation \ ViteManifestNotFoundException PHP 8.1.27 10.43.0 Vite manifest not found at: /******/example-app_20240131/public/build/manifest.json Run npm run dev in your terminal and refresh the page.
npmとやらが「not found」だったので手順を飛ばしたのがやはりダメだった。
さくらインターネットでnpmを使うにはnode.jsをインストールしてnpmをコンパイルする必要がある？
次回があれば「さくらインターネットのスタンダードプランの環境にnpmをインストールする」である。
早くHello Worldとか書きたい。
そのアプローチは非常に効果的ですね。メイン関数内での処理をシンプルに保つことで、コードの可読性と保守性が向上します。以下にその考え方を反映したサンプルコードを示します。
import json # ビジネスロジックの関数 def business_logic(data): # ビジネスロジックの詳細 pass # 設定情報のロード def load_config(config_file): with open(config_file, 'r') as f: config = json.load(f) return config def main(): # 設定情報のロード config = load_config('config.json') # ビジネスロジックの実行 business_logic(config) if __name__ == "__main__": main()
このコードでは、メイン関数は設定情報をロードし、その情報を元にビジネスロジックを実行するだけです。技術的な詳細は関数内にカプセル化されており、メイン関数はそれらの関数を呼び出すだけです。これにより、コードは自然言語を読むような形で読むことができ、技術的詳細は隠蔽されます。また、各関数の担当者も明確になります。このような設計は、大規模なプロジェクトやチームでの開発に特に有効です。
import json import urllib.request # True にするとユーザー名を隠す hide_user = False # 以下を書き換える。sys.argv 使ってもいいんだけど url1 = "https://www.cygames.co.jp/news/id-23172/" url2 = "https://mtg60.com/archives/palworlddoujinsi.html" def get_bookmarks(url: str): req = urllib.request.Request(f"https://b.hatena.ne.jp/entry/json/{url}") with urllib.request.urlopen(req) as res: dict = json.loads(res.read()) user_comments = {} for bookmark in dict["bookmarks"]: if bookmark["comment"]: user_comments[bookmark["user"]] = bookmark["comment"] return user_comments b1 = get_bookmarks(url1) b2 = get_bookmarks(url2) common = set(b1.keys()).intersection(b2.keys()) print(f"[1] {url1}") print(f"[2] {url2}") print() for user in sorted(common): if hide_user: print(user[0] + "*" * (len(user) - 1)) else: print(user) print(f"[1] {b1[user]}") print(f"[2] {b2[user]}") print()
phpの場合、＜?php 処理 という具合に書くが、この中身にはhtmlやjavascriptも包含することができてしまう
MVCフレームワークを使わないにしろ、基本的にビューとバックエンド処理は分割しておくべき。
さらにDB処理、ビジネスロジック、プログラム処理と言ったものがあるが、
DB処理はdbhandler専用のモジュールに分けておき、さらにそのモジュールを処理するテーブルごとに分けておいた方が良い（MVCではモデルと言う）
特にビジネスロジックとプログラム処理の区別だが、「商品名にアダルト商品と思わしき文字列があった場合は登録を拒否する」という例外は「ビジネスの例外」であるのに対し、「商品名の文字列がDBで用意されたvarcharの可変文字範囲を超えた」という例外は「技術の例外」であるということを明確に区別するようにコードを書く。
「おすすめ機能」のような凝ったアルゴリズムが必要な場合はそれ専用のクラスへ分離しておくこと。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
いやぁ、長かったですね。Python が業界デファクトスタンダードになり、シェル言語やシステム記述言語となる可能性が潰えて久しくなるまでが。具体的にいうと Ansible のようなクラウドの構築はTerraformになったし、Linuxのブートには systemd が後継となったいま、Python は Ruby と同じく「Perl のような何か」に落ちてしまった。唯一無二の人工知能の為の言語としても、高度化した人工知能の開発で新規参入者にとってはハードルが高く、API を操作するぐらいだったら JavaScript で JSON をコネコネする API を操作するほうが賢い時代となってしまったのだ。よって Python を新規で採用する絶対的なメリットは消えてしまった。これで「Pythonを使えます」という奴に見下される必要はなくなったのだ。これで、ここ数年間も続いた「Pythonを使えるのを凄いと勘違いしている間抜け、または人工知能の開発で Python は必須なのとかぬかす馬鹿、それに Python を使えば他言語を学ぶ必要はないというキチガイ」を排除できるようになった。だって、Python は数多の言語のようにチューリング完全を満たした言語の一つになったのたから。これを普遍的と言わずになんていうのだろうか。
この時期になるとずっと気象庁の気温ランキングを眺めて「今日も暑いなー」って見てるんだが
https://www.data.jma.go.jp/obd/stats/data/mdrr/rank_daily/data00.html
このページの「観測値」が昔からずっとバグっててめっちゃ気になってる
「35.9 ]」っていう感じで、「]」が入ってる
もうバグの原因はほぼほぼ目に見えてて、ここはJSONで「 [ 34.0, 34.5, 35.0, 35.9 ]」っていう値が入ってて
それをJSON.parseするんじゃなくてsplit()とか使ってしかもlength-1とかで最新値を取ってる
なので後ろの括弧がそのまま入ってしまってる
こんなのめちゃくちゃわかりやすいバグだし、多分気象庁側も把握してるんだろうけど
多分発注しないとダメとかテストが必要だとかでずっと放置されてる
めっちゃ気になるのにずーーーーーっとこのままなのが凄くダサい
世間一般的に読みにくいコードというと、コメントついてないとか
名前が狂ってるというのは、
JSONParserとか言いながらJSONが関係していないクラスとか、
getUserみたいなメソッド名なのに引数としてuserを渡すとかそういうやつ。
JSONParserクラスの名前を付けた奴は、中のコードからすると、
どうもネストした連想配列のことをJSONだと思っていたらしい。
ネストした連想配列から個別の値を取得するのがJSONParserだった。
文字列を受け取って、ネストした連想配列を返すparserメソッドが
あるクラスであればJSONParserという名前で合っている。
getUserはuserIdフィールドだけ値を設定したUserインスタンスを
書いた奴は、データベースから値を取得するのをgetだと思っていたのだろう。
コンテナータブに依存するから依存する拡張機能が有効ならコンテナータブが強制有効になるのはわかる
でも依存する全部の拡張機能を止めたらコンテナータブが無効になるってわけわからん
んで再度有効化したら設定がデフォルトに戻って手動追加したコンテナーも消えてるの本気で意味わからん
どうして強制上書きするんですか？？？？？？？？？？設定にリセットボタンでもつけとけ
あれやこれやのログイン情報全部消えたんですが？？？？？？？？？？？？？？？？？？？？？？？？？？？？
しょうがないから思い出してコンテナー追加したけどこれ並び替えも出来ないのな
前と順番変わっててすこぶる気持ち悪い
Multi-Account Containersの拡張を使ってたらこいつを無効にしたら設定リセットになるのは百歩譲って…いや一時無効にしただけでjsonファイルをデフォルト化って意味不明だけど億歩譲って我慢するわ
でもお前、標準機能だろ？お前を使うかどうかはabout:configで俺が決めさせてくれよ
せめてどこかに注意書き書いとけよ
書いてた？俺が悪かったその場所教えてくれ。光速でブクマするわ。さっさと出せよ。
もしかして俺の勘違いで別の操作が影響してる？？？？謝罪するから原因を教えてくれよ通知もないから妄想で怒るしかねーんだよこっちは
もうマジで意味不明だわ最近Android版でtampermonkey復活したからちょっと株上がったと思ったらこれだよ。多分何年も放置されてる仕様だろこれマジこんなうっかり地雷しこまれると体験損なうんだが
設定消えるなら警告のひとつでもだしてくれ
あとついでにグチるとCookieの許可設定を変更できるようにしてくれ
なんで一度消して同じURLを再登録しないと変更できないんだよ
リソース少ないにしても一体何に費やしてるのかまったくわからんわ
ブコメでも指摘されてるけども。
ある時を境にスターの集計先になるURLが切り替わっているので、すべてのスター数を知るためには2回APIを投げる必要がありそうだ。
たぶんはてブがHTTPS化された2019年5月あたりが境目だろう
https://bookmark.hatenastaff.com/entry/2019/05/28/141208
自分のはてなIDと昔使ってたIDで試した限りではこうなっているはず。
①ttps://s.hatena.ne.jp/blog.json?uri=http://b.hatena.ne.jp/はてなID/
②ttps://s.hatena.ne.jp/blog.json?uri=https://b.hatena.ne.jp/はてなID/
| 2019年5月以降に作ったアカウント | ②の結果しか返らない。①を投げると403エラー |
| 2019年5月以前で消えたアカウント | ①の結果しか返らない。②を投げると403エラー |
| それ以外（2019年以前から今まで現役） | ①と②の結果を合算する |
