  |
はてなキーワード: dbとは
主要な目的は編集ではなく分析だね。一般ユーザにうかつにアクセスさせたくないDBだけど、そのうちの一部のデータを見せてプロジェクト企画とか評価とかで使わせるのは有用なケースでは最近割とホットだよ。DX(笑)の文脈だけど
DB直じゃなくてPowerBIのセマンティックモデルとしてAzureADと紐付いた認証認可付きでデータ公開してExcelからPowerQueryとかで接続するのが今時じゃないかな。
DBみたいに一度死んでる作品を死霊術で生き返らせてるならともかく、現行作品を「遺産」っていうの日本語的におかしいでしょ。
それに日曜にやってるから今の子供たちはアニメみてたり、親がワンピ世代とかだったりで友達だれかの家にあったりで、結構読んでるぞ。
原則関数とピボットテーブルのみで完結させ、マクロは使わない。ってのが良いと思う。
DBからデータぶっこ抜いたり(今のご時世は出来ないと思うが)、外部ファイルを読み込むとかしないで、ブック内のデータを処理するだけならマクロいらんやろ。
数十万以上のデータ件数になるとさすがにきついけど、そうでもなければ関数駆使すればだいたいいける。
てか、Excelはお絵かきソフトであって、表計算として使うんならGoogle Spreadsheetの方が絶対に良いわ。
今まで設計2名、製造10名みたいな体制だったが、AIを使えば設計の2名で製造まで終わらせられるようになり、製造専用の10人はお払い箱。
っていう構図でAIがプログラマーの仕事を奪うってのはありそうだな。ただ、設計とか要件定義出来る人間の仕事はまだ安泰だと思う。
具体性のあるプロンプトだとちゃんと要望に応じたプログラム作ってくれるけど、ぼんやりとしたプロンプトだと大した回答返ってこないからな。
学生のころ、IT土方がどうとかで業界がだいぶまずい場所だと文系の大学生の自分は思い、とても興味のある分野だったけどやめた。
それから5年がたち、今の職業を続けていてもと感じて、ずっと抱えていた興味に素直になろうと思い半年独学し、SES系の会社に転職した。
DBすらよくわかっていない状態だったけど、めちゃくちゃ楽しくて毎日充実しているし、3年たったけどまだ楽しい。
会社で学んだことを活かして個人開発したらまたそれで収入が増えてスキルが上がり、それを会社で活かせば褒めてもらえてより難しい課題に挑め、また更にスキルアップしてより難しい個人開発に挑める。
だからこそ新卒の時入社で来て居たらなぁと思うし、最近では自分と同じようにもっと早く業界に入っていればという中途の人にも出会った。
そういう意見もあるかもしれないけど、ネット上での世論が世の中に影響を与えるようになってる昨今、何かを腐す文化は当人からすればわからないけど、それを読んだ人間のうち誰かの人生を変えてしまってる自覚を持ったほうがいいのではと思った。
枕の下から轟音が聞こえて目が覚めて眠れなくなり家中を探したらこの機械の音だと気付いた。測定すると常に62dB程の音がこの機械から出ている。60デシベルは洗濯機やテレビで感じる音とだいたい同じ大きさ。
Je me suis réveillé et je n'arrivais pas à dormir parce que j'entendais un grondement venant de sous mon oreiller, alors j'ai cherché dans toute la maison et je me suis rendu compte que c'était le bruit de cette machine. Les mesures montrent que cette machine émet toujours un son d'environ 62 dB, 60 décibels correspondant à peu près à l'intensité sonore d'une machine à laver ou d'un téléviseur.
スシロー皿ぺろ投稿・バイトテロ投稿と類似する投稿をして自爆しただけだぞ
増田がどうしてもスシロー皿ぺろ投稿・バイトテロ投稿を擁護したいなら、
『これって退学させるほど追い込まないといけないことか？』じゃないですかね
脚本家なら『失職させるほど追い込まないといけないことか？』かしらね
ちなみに後に脚本家が謝罪(映画｢ドラゴンボール・エボリューション｣の脚本家がファンに謝罪 https://www.gizmodo.jp/2016/05/writer-of-dragonball-evolution-apologizes.html)している
(2009年 DRAGONBALL EVOLUTION 公開時のコメント。興業収入4,500万ドル)
「脚本やキャラクター造りは原作者としては『え?』って感じはありますが、監督さんや俳優の皆さん、スタッフなど、現場は超優秀な人達ばかりです。ボクやファンの皆さんは別次元の『新ドラゴンボール』として鑑賞するのが正解かもしれません。もしかしたら現場のパワーで大傑作になっているかもしれませんよ! おおいに期待しています!!」
(2013年 『ドラゴンボールZ 神と神』の大ヒットの後のコメント。なお、脚本鳥山明の『ドラゴンボール超スーパーヒーロー』 の興行収入は1億250万ドル)
「脚本があまりにも世界観や特徴をとらえておらず、ありきたりで面白いとは思えない内容だった。注意や変更案を提示しても、製作側は妙な自信があるようであまり聞き入れてもらえず、出来上がったのも案の定な出来のドラゴンボールとは言えないような映画だった」
スシロー皿ぺろ投稿・バイトテロ投稿を擁護したいのではなくて、『作者は金もらってたじゃん、それがたとえ端金だろうが』だったら、
約45年前
この時8〜15歳だった人は
今53〜60歳
約38年前
この時5〜14歳だった人は
今43〜52歳
約29年前
この時9〜16歳だった人は
今38〜45歳
公開は2001年
約23年前
この時8〜15歳だった人は
今31〜38歳
約19年前
今29〜39歳
約13年前
この時12〜18歳だった人は
今25〜31歳
公開は2014年
約10年前
この時5〜15歳だった人は
今15〜25歳
約8年前〜
なおすずめの戸締まり（2022）時点では14〜22歳だが、この人たちは2011年時点で3〜11歳
約5年前
この時8〜16歳だった人は、今13〜21歳
ガンダム 50代
千と千尋 30代
アナ雪 15〜25
新海誠 14〜26
鬼滅 13〜21
特定のインデックスを管理する技術者（Aさん）がいるとしよう。
このインデックスがサイト全体の検索で使われるため、CTRを気にするなら最も重要なパーツだ。
ここで私が検索アルゴリズムを改善するための特徴量をインデックスのフィールドに挿入したいというとする。
しかし特徴量を管理するのが私であるのに対し、インデックスを管理するのがAさんであるので、どうやってこの受け渡しをするのかという問題が生じる。
私がインデックスのマッピングルールを書き換えるわけにはいかないのである。
そこでバッチ計算してそれぞれのアイテムIDに対する特徴量をDBやプレーンテキストに保存しておくようにする。
すると
という流れが生まれる。
Aさんは保存データを参照してインデックスに挿入すれば足りるようになる。
基本、各自が各部から依頼を受けて勝手に仕事をするスタイルになっていて
俺の信頼がイチミリもないから、誰も俺に仕事を依頼してこないので仕事がない。
本来だったら、部として仕事を受けてそれをメンバーに振り分けていくんだと思うんだけど
部長が中途でIT未経験のハゲだから誰が何やってるか全く把握できてないので、
しゃーないのでペーパレス化するだけやってDB化もせずにほっぽり出してるデータを
シコシコDB化する仕事を誰に頼まれてもないのに勝手にやってる、増田やりながら。
phpの場合、＜?php 処理 という具合に書くが、この中身にはhtmlやjavascriptも包含することができてしまう
MVCフレームワークを使わないにしろ、基本的にビューとバックエンド処理は分割しておくべき。
さらにDB処理、ビジネスロジック、プログラム処理と言ったものがあるが、
DB処理はdbhandler専用のモジュールに分けておき、さらにそのモジュールを処理するテーブルごとに分けておいた方が良い（MVCではモデルと言う）
特にビジネスロジックとプログラム処理の区別だが、「商品名にアダルト商品と思わしき文字列があった場合は登録を拒否する」という例外は「ビジネスの例外」であるのに対し、「商品名の文字列がDBで用意されたvarcharの可変文字範囲を超えた」という例外は「技術の例外」であるということを明確に区別するようにコードを書く。
「おすすめ機能」のような凝ったアルゴリズムが必要な場合はそれ専用のクラスへ分離しておくこと。
