プログラマの雑談部屋 ★260
■ このスレッドは過去ログ倉庫に格納されています
鳥山明は天津飯と餃子を一緒に食べるのが好きだったのかな? ドラゴンボール知らないと菜葉に餃子が組み付いて死なないで天津飯さんって意味不明よな >>742 普通に人数分のアカウント作るよ もしくはLDAP セキュリティー的に共通アカウントなんてあり得ない おまえ働いたことないだろ? 客先常駐にあるある 顧客「依頼されたものと違うアウトプットが出ている(ウソ)」 →これ、レビューやgitなどIT知識がない営業職の人間が騙されるパターン 現場で曖昧な指示を出していたから確認を取ったらキレる悪質な顧客がよくこういうクレームを出すから気を付けろ >>764 お前さそういうはぐらかすやり方してると一生そうなるぞ 共有するアカウントって書いてあるだろ いい加減にしろよ マジで おれの知る限り顧客は正しい だいたい顧客の提示がクソすぎてSEが勝手に変えてる 助けてやってるのに 顧客から矛盾する依頼をされたとき、分身の術使わないと顧客からクレーム来るぞ 俺はその術しらない 相手の瑕疵をごまかして直させる技があるのか? 新型(と言うか再販で仕様変更)ランクル70良さそう この業界に入って顧客からのクレームの半分は虚偽だけど、営業が騙されてはメールをこちらに送ってくることが多くて気になった とりあえず、虚偽の内容も途中でアップデートされた指示だと解釈して粛々とやるか 営業がアホしかいない事に気づいて受託開発の仕事を辞めたよ こっちが努力してもどうにもならない >>700 ,703 そうなんだよな 同人ゲーム作ったとしてそれを広める手段がなくていっつも頓挫しちゃうな インディーズゲーム配信プラットフォーム無いんですか? ならビジネスチャンスですね >>728 脳トレとして走っとるんでこんなもんでええんや 勿論記録が伸びればより楽しく走れるやろうけども >>780 任天堂もMSもsteamもインディーゲーム取り扱っとるで これどうなん? エンジニア転職のFindy(ファインディ)| GitHubからスキル偏差値を算出 https://findy-code.io/ 客先常駐してる人ってどんだけ無能なの? まともなプログラマーならいくらでも仕事選べるのに 客先常駐断れないほど無能なの? まともなプログラマーは5chで人を煽ったりしない そもそも5chなんか見ない 研修会資料に メモリマネジメントの事調べてくれ言われたんだが なに調べりゃいいやら・・・ >>792 垢要るから蓄積されそうで自主規制してる >>791 研修会程度だとメモリが壊れています以外に書きようがなさそう メモリ周りなんて突き詰めると膨大な資料になるよ というかプログラマの範疇ではない いや、ヒープメモリの管理の話じゃね? マネージドの昨今なら、c#で言うusingの話とかさw >>799 あ? テメー何様だ? こんな場所でしか威張れない引き篭もりか? 2人ともおちつけ おれたちそんなに凄いプログラマではないはずだ 謙虚にいこうぜ AIばかり使ってると一人では組めない身体になりそうでこわい Excelで仕様書書いてくださいって言ったら書いてくれる? そろそろおれらのやってることも伝統芸能になりそうだな >>807 エクセルでと言うならエクセル使うけど 何の仕様書を書くのかを聞くまでは「書く」とは言わない >>806 それでいいんじゃない? いつの時代も作る側よりも、作る側を操る人の方が優位になってるし 画面に入力された受注情報をDBに登録する処理を書いてください その中にDB設計と画面設計もつけてください 業務用システムなので排他制御、ログ出力なども考慮してください ChatGPTがやってくれました 【データベースの設計】 受注情報を管理するためのデータベースを設計します。以下のようなテーブルを作成します。 【テーブル1:Orders】 OrderID (int, primary key):受注ID CustomerID (int):顧客ID OrderDate (datetime):受注日時 TotalAmount (decimal):受注合計金額 Status (int):受注ステータス(1: 新規, 2: 処理中, 3: 出荷済み) 【テーブル2:OrderDetails】 OrderDetailID (int, primary key):受注明細ID OrderID (int):受注ID ProductID (int):商品ID Quantity (int):数量 UnitPrice (decimal):単価 >>819 続き 【画面設計】 受注情報を入力する画面を以下のように設計します。 【画面1:Order Entry】 受注情報を入力する画面です。 ▼入力項目 顧客名:顧客名を入力するテキストボックス 商品名:商品名を入力するテキストボックス 数量:数量を入力するテキストボックス 単価:単価を入力するテキストボックス ▼ボタン 受注登録:入力された情報をデータベースに登録するボタン 【受注情報をデータベースに登録する処理】 以下は、入力された受注情報をデータベースに登録する処理の例です。 顧客情報の取得 1-1. 入力された顧客名をもとに、顧客情報をデータベースから取得する。 1-2. 取得した顧客情報から顧客IDを取得する。 商品情報の取得 2-1. 入力された商品名をもとに、商品情報をデータベースから取得する。 2-2. 取得した商品情報から商品IDと単価を取得する。 受注情報の登録 3-1. Ordersテーブルに、顧客ID、受注日時、受注合計金額、受注ステータスを登録する。 3-2. 登録した受注情報から受注IDを取得する。 受注明細情報の登録 4-1. OrderDetailsテーブルに、受注ID、商品ID、数量、単価を登録する。 以上が、受注情報をデータベースに登録する処理の例です。 ぼちぼちってところかな よく本にあるサンプルみたいな感じ OrderIDがサブテーブルの主キーでないなど玄人感ある TotalAmountをorderに持たせる理由を説明してみて >>823 TotalAmountをOrdersテーブルに持たせる理由は、受注の合計金額をすばやく取得するためです。 OrdersテーブルにTotalAmountを持たせることにより、受注情報を一括で取得した際に合計金額を計算する必要がなくなります。また、受注情報が増えていくにつれて、合計金額を計算するための処理が重くなることを防ぐことができます。 さらに、TotalAmountをOrdersテーブルに持たせることで、受注ステータスが変更された際に合計金額を再計算する必要がなくなります。例えば、出荷済みの受注をキャンセルした場合など、受注ステータスが変更された際に、再度合計金額を計算して更新する必要がある場合がありますが、TotalAmountを持たせておくことで、このような処理を簡略化することができます。 以上のように、TotalAmountをOrdersテーブルに持たせることで、受注の合計金額を効率的に管理することができます。 >>825 ハハハ...なんやねんこれ完璧すぎワロタ 逆に考えるんだ! 無能がめちゃくちゃ優秀になれるってことだ TotalAmountみたいなデータを嫌うプログラマがいるよな 二言目には冗長だ!とか言う奴 後々TotalAmountがないと困ることが多いので本当に迷惑 ちなみにこのコード書いてって言ったら全部書いてくれた 本当にやばい 俺らの仕事は無くならないって言ってるやつマジで自惚れすぎだぞ 危機感持ってやった方が良い AIに任せたいなら任せたらいい 責任取れるならだけど どうせ取れない Googleがエロ画像検索を規制したように これもそのうち暗に規制されてしょぼい機能しか提供しなくなるんじゃないか そういう懸念 >>832 平方根を数式で表すと、以下のようになります。 √x ここで、xは平方根を求める数値です。例えば、xが16の場合、平方根は以下のようになります。 √16 = 4 また、xが任意の正の数である場合、以下のように計算することができます。 xの平方根 = x^(1/2) 例えば、25の平方根を求める場合、以下のようになります。 25^(1/2) = 5 また、xが負の数である場合、以下のように複素数として計算することができます。 xの平方根 = √(-x) * i ここで、iは虚数単位です。例えば、-16の平方根を求める場合、以下のようになります。 √(-16) = 4i なお、Javaでは、Mathクラスのsqrtメソッドを使用することで平方根を求めることができます。 具体的には、Math.sqrt(x)のようにして、数値xの平方根を求めることができます。 2の平方根聞いたら細かい数は数えられないらしくめちゃくちゃだったと 試しでchatgptを実際の仕事で使ってみれば判るが取って代わられる事はないよ chatgptが出したプログラムを精査して修正して、さらに設計や仕様やデータと連動させていく作業が残ってる 実際の業務でもプログラミングそのものよりも周辺と摺り合わせの方が多いからね むしろその事に気づかされる 2の平方根を求めると、約1.41421356となります。 Javaで2の平方根を求める場合、以下のようにMathクラスのsqrtメソッドを使用します。 double result = Math.sqrt(2.0); System.out.println(result); // 結果: 1.4142135623730951 この例では、Math.sqrtメソッドに2.0を渡すことで、2の平方根を求めています。 結果は1.4142135623730951となります。 なお、結果はdouble型で返されるため、必要に応じて数値フォーマットを行うことができます。 また、sqrtメソッドは正の値に対してのみ定義されているため、負の値を引数に渡すとNaN(Not a Number)を返します。 >>825 TotalAmountの再計算を忘れずに確実に行うための仕組みを考えてください プログラマーの仕事なくなったらAIの出力結果を精査する仕事になるんけ >>846 精査するにはプログラムを書くスキルがないと出来ないので、形は変われど仕事はなくならない 久々に生jkと絡んだがあんまりそそられんな やっぱ俺はロリコンではないのだ >>845 TotalAmountを再計算するために、以下の2つの方法があります。 1.受注情報の更新時に、関連する受注明細情報から合計金額を再計算する。 2.受注情報の更新時に、関連する受注明細情報から合計金額を再計算するのではなく、トリガーを使用して自動的に再計算する。 方法1の場合、TotalAmountの値を更新するたびに、関連する受注明細情報から合計金額を再計算する必要があります。 この場合、TotalAmountを更新するたびに再計算を行うため、処理が重くなることが懸念されます。 一方、方法2の場合、TotalAmountの値が更新されるたびに、自動的に関連する受注明細情報から合計金額を再計算することができます。 トリガーを使用することで、データベースに変更が加えられた際に自動的に処理を実行することができます。 具体的には、以下のようなトリガーを使用することができます。 CREATE TRIGGER update_order_total_amount AFTER INSERT ON OrderDetails FOR EACH ROW BEGIN UPDATE Orders SET TotalAmount = ( SELECT SUM(Quantity * UnitPrice) FROM OrderDetails WHERE OrderID = NEW.OrderID ) WHERE OrderID = NEW.OrderID; END; このトリガーでは、OrderDetailsテーブルに新しいレコードが挿入された際に、関連するOrdersテーブルのTotalAmountを自動的に再計算しています。 具体的には、OrderDetailsテーブルの新しいレコードによって影響を受けるOrdersテーブルのレコードのTotalAmountを、 関連するOrderDetailsテーブルのQuantityとUnitPriceから計算して更新しています。 このようにトリガーを使用することで、TotalAmountの再計算を忘れずに確実に行うことができます。 ただし、トリガーを使用する場合は、トリガーの動作によってパフォーマンスに影響を与える可能性があるため、適切な設定が必要となります。 また、トリガーによって自動的に処理が行われるため、処理の正確性を確認する必要があります。 >>849 トリガーを採用した場合、TotalAmountを更新するのはトリガーからのみに限定する仕組みを考えてください。 最近気になる技術はって聞かれたら chatgptともう一個ぐらい言うなら何がいい? アクセス過多には対応してないから自分で考えてね 全銀ネットのプログラマーより愛を込めて >>851 トリガーからのみTotalAmountを更新する仕組みを実装するためには、以下のような手順が考えられます。 1.OrdersテーブルのTotalAmountカラムにトリガーで更新を行う。 2.OrdersテーブルのTotalAmountカラムの更新に対して、Ordersテーブルにアクセスする権限を持つユーザーにのみ許可を与える。 具体的には、以下のようなSQLコードで実装できます。 -- Ordersテーブルに対するトリガー CREATE TRIGGER update_order_total_amount AFTER INSERT ON OrderDetails FOR EACH ROW BEGIN UPDATE Orders SET TotalAmount = ( SELECT SUM(Quantity * UnitPrice) FROM OrderDetails WHERE OrderID = NEW.OrderID ) WHERE OrderID = NEW.OrderID; END; -- Ordersテーブルにアクセスするユーザーに権限を付与する GRANT UPDATE(TotalAmount) ON Orders TO myuser; この例では、トリガーを使用してOrderDetailsテーブルに新しいレコードが挿入された際に、 関連するOrdersテーブルのTotalAmountを自動的に再計算するトリガーを設定しています。 また、Ordersテーブルにアクセスする権限を持つmyuserというユーザーに対して、 OrdersテーブルのTotalAmountカラムの更新に対してUPDATE権限を付与しています。 このようにすることで、OrdersテーブルのTotalAmountカラムは、トリガーからのみ更新され、 Ordersテーブルにアクセスする権限を持つユーザー以外からは更新することができなくなります。 ただし、必要に応じて、他のカラムに対しても同様の権限制限を設ける必要があります。 また、この例ではMySQLを使用していますが、データベースによっては、権限制限の設定方法が異なる場合があります。 これだと付随してOrdersのUPDATEにトランザクションをかける必要があるけど言及されてないね しかし理想のモデルっていうのは重要だからスジはいいぞ >>857 その条件教えたらまた改善してくれるよ これが恐ろしいところ 相談しながら設計できる 「入試帰りの電車の中で、私を囲んだ3人のサラリーマン男性。号泣している姿を周りから隠すように立ち...」(東京都・20代女性)(全文表示)|Jタウンネット https://j-town.net/2023/02/25343534.html?p=all ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる