  |
はてなキーワード: モデルとは
お金持ちが通う、お坊ちゃん大学に行ってスマートな遊び方を覚える。
結婚するには、良い学歴と、勤め先、教養、まともな親せきが必要。（本当のお嬢様なら）
本当に天然の美しい人で立ち居振る舞いも良い、育ちの良さなども総合して考えているのか。
＞d-matchon社長は当然のこと、周りで囃し立ててる連中も頭おかしい…
＞nekong87半グレ犯罪者のクズ達はもちろんだけど、一緒に騒いでるバカ女（モデル？）もヤバいだろ。
＞crexistドン引き。。現行犯逮捕でしょ、これ。。そして、3.2.1キャー、とか言ってる女の声がムカつく。場の空気があったとしても最悪2度目は止めろよと思う。
Vtuberは中身のyoutuberと違い炎上しない(し辛い)みたいな利点を黎明期に言っていた連中もいたが、事務所とのトラブルでいざこざ起こした人たちやモデル盗作魔王に人見クリスレイプ事件とか全くそんなことなかったな。
むしろ企業、モデル、中身と3つに別れてる以上どこから火が付くか分からないうえに、既にレッドオーシャン化した市場で乗り手っ取り早く利益を上げたい企業に何でもいいから仕事が欲しい底辺声優が集まればトラブルも起こるわな。Vtuberの中身なんて声優としてのキャリアの足しにもなんにもならないのに。
「優しい世界」ってなんだったんだろうなぁ。優しさどころか厳しさしか感じないわ。犯罪者に優しい世界って意味なら理解もできるけど。
今回は、DB設計の(2)概念設計、(3)論理設計、(4)物理設計を見てみましょう。
「スッキリわかるSQL入門」のDB設計の説明がコンパクトにまとまっていて、分かりやすいと思いました。（是非一度読んでみてください。）
「スッキリわかるSQL入門」第12章の説明（p.374）を参考にしてみよう。（詳しくは本を読んでみてください。）
概念設計
データベースやシステムに関することは考えず、要件に登場する情報だけをザックリと把握します。
論理設計
概念設計で明らかになった各情報について、RDBを使う前提で構造を整理し詳しく具体化していきます。
論理設計では「どのようなテーブルを作り、それぞれのテーブルにどのような列を作るか」まで明らかにすれば十分です。
型や制約など、付随的な部分については考えません。
物理設計
特定のDBMS製品（たとえばMySQL）を使う前提に立ち、論理設計で明らかになった各テーブルについて、その内容を詳しく具体化していきます。
すべてのテーブルのすべての列について、型、インデックス、制約、デフォルト値など、テーブル作成に必要なすべての要素を確定させます。
この物理設計に基づいて、CREATE TABLE文などを含む一連のDDL文を作成し、最終的にデータベース内にテーブルを作成することができます。
本書の「図12-4 データベース構築のおおまかな流れ」も参考にして欲しい。
●入力 お客様の要件（全国の倉庫に商品があって、その在庫を管理したいんだけど～）
↓
・物理設計：[SHOHIN][ZAIKO][SOUKO] …使うDBの仕様に合わせてテーブル定義表を作成
↓
●出力 DDL文
・CREATE TABLE ～
・CREATE VIEW ～
・CREATE INDEX ～
ER図とは、「Entity-relationship Diagram」（実体関連図）の省略形だ。
コンピューターの用語は英語ばっかりだから、日本語にして欲しいよねｗ
ER図で使う記号は、「IE記法」や「IDEF1X記法」など、いろいろな規格がある。
情報処理技術者試験のデータベーススペシャリストの問題では、「UML」という図の記法も使われる。
「正規化 Normalization」とは、データの形を「正規形」（Normal form）に変えること。
ざっくり言うと、テーブル（表）を分割して、データの重複や不整合を解消する作業だ。
テーブルの形を変えていくステップには、第1～第5まで5段階ある。
第3正規形をより厳密にした「ボイス-コッド正規形」という形もある。
第3と第4の間なので「第3.5正規形」とも呼ばれている。
（ボイス-コッド形もカウントに入れたら、第1～第5、＋第3.5で計6段階になる。）
正規化を進めると、SQL「JOIN」の利用が増えてくる。JOINを多用する処理は遅い＝DBの性能低下につながる。
第3正規形まで分割しても、実際に使ってみて遅い場合は、第2正規形や第1正規形に戻して使うこともある。これを「非正規化」とか「正規化を崩す」などという。
RDBでは処理速度が遅くなる場合、代わりに「NoSQL」を使う場合もある。
時間がない場合、先にGUIのDB管理ツールでデータベースを作成してしまい、その後でテーブル定義表を作成することもある。
DB設計に慣れてきたら上記の各段階はすっ飛ばして、いきなりデータベースを作れるようになるだろう。
ここまで、SQLの使い方やデータベースの設計について学びました。
次回は、その他のSQLに関連する話も見てみよう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
anond:20181101230220 増田式プログラマー養成講座 その16 Webアプリの完成見本（続き）
anond:20181104161900 増田式プログラマー養成講座 その17 Webアプリの骨組み
anond:20181104233013 増田式プログラマー養成講座 その18 SQLでデータの追加と取得
anond:20181110120715 増田式プログラマー養成講座 その19 SQLでデータの更新
anond:20181110182445 増田式プログラマー養成講座 その20 SQLでデータの削除
anond:20181111205255 増田式プログラマー養成講座 その21 データベース設計 (1)要件定義
anond:20181119224031 増田式プログラマー養成講座 その22 データベース設計 概念→物理 ←★今ここ★
：
と思う
俺に支給されているのは2017年モデルのMacBook Pro 13インチ, メモリ16GB, SSD 512GBだ
せめてメモリは倍ほしいし（その場合MBP13インチでは無理なので、MBP15インチでもいいしiMacやiMac Proでもいい）ディスプレイは4Kのを2枚ほしい
という内容の記事をQiitaに書いても「増田で書け」と言われるのがオチなので増田で書く。初増田に書く内容がこんなのとは…。
元々Qiitaは「Yahoo!知恵袋」ぐらいのものでしかないと思っており、はてブに上がっても内容チラ見してスルーする事が多かったが、ここ最近になって「ゴミ記事ばかりだ」「低評価ボタンをつけろ」しまいにゃ「ゴミ記事を選別する機械学習モデルを作る」なんていう見事なブクマ稼ぎ記事がホッテントリに上がっていたりして頭を抱えそうになった。
そういうあからさまなブクマ稼ぎ記事こそ「ゴミ記事」と批判すべきなのではないかと。機械学習で排除しても残るのは「普遍的な記事」のみとなり、さらに見る価値もなくなる。
（今はもう寂れてしまい言及する人も少なくなったが）Qiitaも所詮は「便所の落書き」レベルと変わりなく、5chと大差がない。そもそも匿名（ハンドルネーム）で書かれる記事に文句をつける方がおかしいのである。
もしこの騒動が昔の2chで起こったら「100年ROMれ」と言われNGIDにブチ込まれるのがオチである。荒らしに反応する方もまた荒らしなのである。
同じようなもので「食べログ評価問題」というのがあった。その時は「食べログの評価を信用する方がおかしい」という意見が大半だった。これには自分も深く同意する。
匿名での寄稿記事など信用性の面で評価するべきではないし、検索結果が汚染されるとかもう笑止千万というところである。
Googleには古くから「マイナス検索」というのがある。特定のキーワードやドメインが含まれたサイトを除外して検索結果を返してくれる機能だ。
これは専ブラでいう「NGキーワード」であり「NGID」機能と同じである。見たくないものを自らの選択で除外できるのである。
ドメイン単位で結果を返してほしいなら「検索キーワード site:example.com」で絞り込める。逆に「このドメインからの結果は返してほしくない」場合は頭に「-（ハイフン）」をつけるだけで除外できる。
例えば「nginx」の事を調べているが「Qiita」からの結果を返してほしくない場合は「nginx -site:qiita.com」とすれば、Qiitaにある記事が全て除外される。この除外条件は複数指定できる。
今流行っている「Python」などでは「Qiita」もそうだが、調べたい内容がない（侍ナントカみたいな）記事までヒットする事がある。そういう場合もこの除外条件を複数つけることで丸ごと排除できる。
特にプログラミング言語系の場合は「teratail」のような「技術系に特化したYahoo!知恵袋」みたいなサイトまである。内容は言うまでもなくお察しレベルなので「Python -site:qiita.com -site:teratail.com」みたいにして排除してしまう。
Qiitaのゴミ記事問題について「SEOに強すぎて検索結果から排除できない。SEO汚染を排除できないGoogleもクズ！」と言う意見も聞かれた。笑止千万である。
先ほどにも書いた通り、Googleでは「マイナス検索」があり自ら取捨選択できるようになっている。そもそもキーワードだけ散りばめて広告費を稼ごうとするアフィリエイトサイト（ワードサラダなど）について言うのであれば一理ある。
しかし、Qiitaについては俗にいう「スパムサイト」の定義に当てはまらないのでこのような批判は論外である。Googleはお前のおかんではない。言うならばセルフレジ導入店舗にて「店員が商品精算を行わない不誠実な店だ」と嘆く老害のようなものである。
「Qiitaに低評価機能をつければゴミ記事が一掃できる！」と息巻いていた人もいた。はたから見れば「バカジャネーノ」と言いたくなる。
成功例として「Stack Overflow（本家）」の名前を上げている人が多数いたが、Stack Overflowにも「ググれカス」と言いたくなるレベルの質問が投稿されている事には誰も言及しない。
低評価を行って記事自体を排除したところで検索結果として消される訳ではなく、もちろんGoogleでも引っかかる。そもそも「ググれカス」という文化は日本が最初であり、最近では海外でも「ググれカス」という文化が流行ってきている。
そういう文化圏がなかった頃の話を成功例として持ち出されても日本では上手くいかない。逆に投稿者が萎縮してしまう事で利用者低下に拍車がかかり、サービス維持が困難になるだろう。
低評価機能がある事で利用者減に繋がった実例がある。かの「pixiv」である。「pixiv」の評価システムが少し前に五つ星から「スキ！」に変わったのは「ねとらぼ」などで取り上げられたので知っている方も多いであろう。
五つ星システムでは悪意のあるユーザーが集団で「星一つ」をつけて投稿者の筆を折らせる行為が目立った。その対策がされた後、今度は逆に「満点（星五つ）」を集団でつけ投稿者を舞い上がらせて（5chなどで晒し）影であざ笑うという悪質な行為が目立った。
絵師というのは他人の評価が気になり、エゴサをしないという選択肢を取りにくい。pixivの作品URLでググって5ch内のスレで晒されてボロクソに叩かれているのを発見した時どう思うだろうか。自分なら間違いなく筆を折る。
そうして「投稿者」が減っていき「閲覧のみ」だけのユーザーが増えていく。当然、雑多の中にある魅力的な作品も投稿されなくなっていくので言うまでもなく「閲覧のみ」のユーザーも減っていく。魅力的な作品もなく課金なんてしてもらえない。
日本の文化圏は「加点方式」ではなく「減点方式」なのは言うまでもない。もしQiitaに低評価、もとい投票システムが実装されたとすればpixivの二の舞になるのは目に見えている。Qiitaが潰れても問題ない？だったら侍ナントカみたいなサイトで検索結果が汚されるのは別に問題ないというのか。
もう一度言うが、この情報過多の時代「口をあんぐり開けてエサをもらえる」なんて考えてはいけない。有益な情報が欲しければ対価を払って手に入れろ。技術はタダではない。
対価を払うにしても頭を使って事前に調べないとQiitaよりゴミな情報を掴まされる危険性すらある。もう何度も言う必要はないからこれ以上言及しない。
どうしても対価を払いたくないのであればQiitaでも何でもいいから「雑多な情報から掘り出し物を見つける」感覚で調べろ。そういう事もできないのであれば100年ROMれではなく直ちにインターネット回線を解約しろ。
任天堂のスマブラＳＰＥＣＩＡＬで新・鬼ヶ島のキャラを出すべき理由
２．唯一のＡＤＶキャラ
４．男の子、女の子、お供の二匹と一羽で、技が考えやすい。例えばおはなで復帰、りんごで威嚇など。
６．音楽は静かな曲、激しい曲、勇ましい曲など一通りのジャンルが揃っている。
８．原作のゲームは細かいバージョン違いを含めると結構多く、実績がある。
１．キャラクター名はどうするか。例えば「ひかりとどんべとお供達」「ひかり一味」
３．キャラクター音声はどうするか。
というわけで、ＤＬＣによる「参戦」に期待している。
ハワード・フィリップス・ラヴクラフトに端を発する小説を中心とした架空神話
一神教文化を背景としたおぞましさを表現している傾向が強く、多神教文化圏では理解しにくい部分もある
日本の創作にもよく引用され、クトゥルフ神話を題材とした作品がアニメ化されたりもしている
リチャード・ストールマンに端を発するGNU宣言の後に誕生
フリーソフトウェア運動支持者は狂信的なものもおり、時にその思想から内外で対立することを宗教戦争として揶揄したことからGNU教というジョークが成立
リチャード・ストールマン本人も聖イグヌチウスと名乗りコスプレを披露したこともある
北米の公教育において進化論と共にインテリジェント・デザイン説(知性ある何かによって生命や宇宙の精妙なシステムが設計されたとする説)の立場も教えなければならないとする議案に対して、反発する意味を込めて成立した
このインテリジェント・デザイン説の立場とは事実上キリスト教徒の立場であり、信教の自由があり為政者が特定の宗教を贔屓するのは良くないとする学生たちがキリスト教のパロディ宗教としてスパモン教を作った
スパモン教徒は「平等のため、スパゲッティ・モンスターが人類を作ったという説も学校教育で教えるべきだ」と主張した
後にオランダにおいて宗教団体として受理され、(神前式のノリの)パスタ婚式も行われた
日本の女性声優の釘宮理恵のファンによるサークル的性質を持つ創作宗教
ヤマグチノボルのライトノベルであるゼロの使い魔に登場するルイズ・フランソワーズ・ル・ブラン・ド・ラ・ヴァリエールをアニメ版ゼロの使い魔で釘宮理恵が演じたことにより釘宮理恵のファンが爆発的に増えたことを由来とする
釘宮理恵の演技に虜となった者を釘宮病と揶揄し、釘宮病罹患者はほぼツンデレ神釘宮教信者と見做される
海外の日本アニメファンにもKugimiya DiseaseもしくはKugimiya Byouで通じる
(追記)
東京都八王子市日吉町に所在する寺院了法寺の住職がオタクカルチャーファンだったことにより、了法寺へ萌え看板を設置したことにより注目を浴び、イラストレーターとろ美デザインのとろ弁天が作成された
そんな単純な話じゃないんだよ、別にツイフェミだって無趣味なわけじゃないんだから
男が憎くて、だから男女の恋愛や規範みたいなものも憎たらしくて、ただマイノリティであるという理由だけでBL（や百合）に走ってる連中
（もちろん全員がそうというわけじゃないし、当の腐女子に言わせると若年層はあまりそういうの考えずにカジュアルに楽しんでるらしいが）
そういう輩なんだから、いくらよそ様の趣味を性的消費とか言って殴ろうが、自分の趣味だけは理屈こねてその性的消費とやらに含まないに決まってるんだよ
それか「ゴールデンカムイはカウンターだから素晴らしい」とかわけのわからないことを言いだす
だから「娯楽vs統制」というモデルでとらえること自体が正確じゃなくて、はっきり言うなら単に娯楽と別の娯楽の争いでしかない
私の中で、『やがて君になる』の主人公小糸侑は、『十二国記』の泰麒と重なる。
いつか大切な気持ちを知るときが来るのだと、侑や泰麒の周囲の人びとは言い聞かせる。泰麒の場合は女官たちが直接に。侑の場合は、少女漫画やラブソングといったメディア、友人たちとの恋バナを通じて。あなたにもいつかその気持ちは訪れるのだと。
けれど、周囲の人びとが提示するのはあくまで1つのモデルに過ぎず、色々な形でその「気持ち」は訪れるのだと、侑も泰麒もわからない。その気持ちは誰にも同じようなかたちで訪れるのだと誤解している。
だから、侑も泰麒も自分の気持ちに気づかない。泰麒は自分の感じた王気を怯えているのだと誤認する。自分の「ほんとうの気持ち」から出た行動を嘘だと間違える。侑は、自分の心臓が高鳴っているのに、高鳴っているのは燈子のそれだと決めつける。どちらも、周囲が教えてくれるモデルとは違った形だから。
自分のことを思い返してもわかる。好きになる気持ちの形は、いつだって漫画みたいにくっきり訪れてくれるとは限らない。ふとした瞬間、これまで周囲の話やメディアから思い描いていたのとは違う形で、その思いは訪れる。そしてそれに気づいたときには、もうこらえようもなく大きなものになっている。
アズマリムにまつわる騒動をあのツイートがあった日からずっと追っかけてたんだけど、「転生」っていう言葉を「中の人を入れ替える」っていう意味で使ってるサイトがあって違和感があった。
例えばKAI-YOUとWikipediaの記事では完全にそういう意味合いになっていてどういうことだよと思った。
･転生、つまりバーチャルYouTuberの中の人（魂）を入れ替えられようとしている
バーチャルYouTuberとそのファンの間において転生とは魂、つまりバーチャルYouTuberの演者を入れ替えることを指す[22]。
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%BA%E3%83%9E%E3%83%AA%E3%83%A0
そうじゃねえだろ。転生っていうのは、中の人が変わるんじゃなくてガワ（キャラ）が変わるってことだろ？
例えば、ニコニコで活動していた「福山○治」がバーチャルYouTuberの「ふくやマスター」になったりするのを転生っていうわけで。転生組ってそういうことだろ。
2017年11月に友人が「作ったよ」とLive2Dモデルを急に送ってきたことをきっかけにLive2Dを使用した配信を開始。その後、2018年3月より改名をし、「バーチャルシンガー」ふくやマスターとして、バーチャルYouTuberへ転生。
https://dic.nicovideo.jp/a/%E3%81%B5%E3%81%8F%E3%82%84%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC
これはあくまでも俺の邪推でしかないけど、今回の件の「転生」っていうのは、アズリムの中の人は変えずにガワと性格を変えて、別キャラとして例の学園に転入させようとしたってことなんじゃねえの？
アズリムの話からだけじゃ詳しい実情はわからんけど、少なくとも今までの転生という言葉の使われ方を踏まえると「中の人を変える」って意味にはならんだろ。
配送の仕事が遅くまで続いた日は近所のコンビニで唐揚げ弁当とチューハイを買って胃に流し込んでから寝る。ケイタはずっとそうやって暮らしてきた。今日もそうやってベッドに体を沈めよう、そう思って帰った部屋には万能家事ロボット「キョウコ」がいた。
※ ※ ※
「始めましてケイタさん。万能家事AIロボのキョウコです」そう話しかけられてケイタは思い出した。先週スマホのSNSで見かけたロボットのモニターに応募したのだった。広告など普段は見逃すのに、ロボットの薄い緑色の瞳と淡い栗色の髪に惹かれてしまった。そして目の前に少女の姿で現れたそれは生き生きと動いていてとてもロボットとは思えない。
「ケイタさん、お食事は買ってきたんですか？」ロボットに話しかけられて、ケイタは「あ、はい、いつもこれなんです…」と曖昧に返事した。そういえば部屋に帰って誰かと話すなんて慣れてない。いくらロボットとはいえ誰かが見てる前でいつものようにスマホ片手に食事するのも変だ。なんだか落ち着かない気分で黙々とご飯を食べる。自分にはロボットとの生活は向いてないんだろうか。
「あの、お風呂入るんですけど」食事後ケイタはロボットに言った。「はい、お背中流しましょうか？」ロボットは躊躇なく、にこやかに答えた。笑顔が眩しい。「いや、あの、やっぱりいくらロボットでも女の子がいる前で着替えるの恥ずかしくて、どうしようかなって思ってて…」ワンルームの部屋には隠れて着替えする場所はない。女の子のロボットに来てもらったはいいが生活をどうするかなんて全く考えていなかったのだ。
「はい、失礼しました。では本日はこれでお休みさせていただきますね。」少女は答えると、部屋の隅の3Dプリンターの場所まで移動した。この前のボーナスで買った最新モデルで、小さな冷蔵庫くらいの大きさの物ならネットからデータを読み込んで数分のうちに組み立てる高性能モデルだ。「明日は朝からお伺いします。朝食はお作りしますか？」
お願いします、とケイタが答えると、少女はおやすみなさい、と一言そえて3Dプリンターの樹脂ボックスの中に立った。カタカタという静かな音と共に少女は樹脂ユニットに還元されていった。そうだな、あれはやっぱりロボットだったんだ。ケイタは妙に納得して、シャワールームへと歩いた。明日はトーストがいいかな。ケイタはパンの袋を棚の奥から前に出した。
※ ※ ※
「ケータ最近元気そうじゃねえか」運転席の西田先輩にそう話しかけられて、少女が来てからの自分の変化に気づいた。「彼女でもできたか？」
「いやぁ、先月あたり家事ロボットが家に来てですね。生活リズムが整ったからですかね」
「へえ、よく聞くやつ。あれやっぱ便利なのか？」
「便利っていうか、生活に潤いが出ますよ。家に帰ると誰かがいるって思うと」
「ハッ！こりゃ当分結婚できねえな」
西田先輩に言われたくはないですね。と、軽口を言い返したもののケイタの心に引っかかるものはあった。家にいる少女はやっぱりロボットだ。いつまでも頼っていたら彼女も結婚も遠くなるばかりだ。今の自分は、まるで家電に名前をつけて愛情を注いでいる哀れな独身男性じゃないか。仕事を終えて少し肌寒くなった空を見上げながら、ケイタは考え込んでしまった。
「おかえりなさい。今日はケイタさんの好きな麻婆豆腐ですよ」家に帰るとロボットがいつもどおり夕飯を作ってくれていた。いつも今日あったことを話しながら楽しく食事をしている時間だが、今日からケイタは一人の生活に戻ることにした。スマホを片手に黙々と食事を取る。ロボットはいつもと違う雰囲気を察して、今日なにか嫌なことがあったのか、食事が気に入らなかったのか、など話しかけてくれたが、ケイタが何も喋らないところを見てやがて黙り込んでしまった。
「すいません、明日からあまり喋らないようにしますね」ロボットはポツリと言った。「ああ、そっちの方が楽だね」ケイタはスマホから目を離さず答えた。「必要なことだけ話してくれればいいから
「はい、わかりました。今日は後片付けだけしたらお休みさせていただきますね」ロボットはそう返事したあと、一言付け加えた。「あと、明日はモニターの最終日です。延長して契約いただけるようでしたら、アンケートに延長の回答していただけますか？」
モニターの期限は1ヵ月だったことをケイタは思い出した。これでもう終わりにしよう。ケイタは延長しないことをロボットに伝えた。ロボットがどんな返事をしたのかは覚えていない。ケイタはまるで味のしない麻婆豆腐を掻き込み、シャワー室に行った。
※ ※ ※
次の日は朝から小雨だった、体が芯から冷え込む。いつものトーストを平らげて出勤しようとすると、ロボットが声をかけてきた。「今日で最後ですね。利用延長はしないことをセンターに申請しました。でも、」ロボットが続いて語りかける。「もし気が変わったら、今日の夜11時までに、直接私に伝えてください。スマホからは申請できなくても、私なら申請できます。」
「ありがとう、でも延長はしないよ」ロボットにそう伝えて、ドアをあけた。ロボットは少し寂しそうに頷くと「了解です。今までありがとうございました。ケイタさんと1ヵ月過ごせて楽しかったです。」
そう答えた。
雨は昼を過ぎると本降りになってきた。道路が少しずつ混み始め、配送作業も思うように進まない。運転席の西田先輩も少し苛ついているようだった。「これじゃ寝る頃には日付変わっちまうじゃねえかよ。ケータには世話してくれる彼女がいるからいいけどよ」
「まじかよ。寂しくなるよな。1ヵ月も一緒にいたんだろ？」
いやロボットですから。そう答えたものの、今までの1ヵ月、家に帰れば少女がいる生活にすっかり馴染んでいたことにケイタは気がついた。このまま少女を喪って、本当によかったんだろうか？
「ロボットっつっても一緒に過ごしてりゃ家族みたいなもんだろ。俺の愛車みてえなもんだ。モニターったってせめて期間延長とかさせてもらえりゃいいのになあ」
その権利はつい昨日自分で捨てたのだった。いや、まだ間に合う。今日の夜11時までに、家に帰って少女に告げるのだ。もう少し君と過ごしたい。
日が暮れて雨は一層強くなってきた。荷物はまだ残っている。道路は渋滞し、赤いテールランプが蛇のように列をなしている。家に11時までに帰れるだろうか？ケイタは少しずつ焦ってきた。最後の荷物を届け終わったとき、時計は10時を過ぎていた。事務所のパソコンに日報を書き込むと、ケイタは矢のように事務所を飛び出した。今から電車に乗れば11時5分前に駅につく。そこから走れば間に合う・・・
しかし家まであと一駅のところで電車は突然停止した。先行車両の遅延が原因らしい。どうにか間に合ってくれ。スマホを握りしめたケイタの祈りも虚しく、電車の中で時刻は11時を過ぎていった。
※ ※ ※
ケイタはのろのろと暗い部屋を開けた。もう扉の向こうにキョウコはいない。ようやっと電気をつけ、すっかり濡れた服を脱衣所に放り込んだ。「キョウコ・・・」ケイタは思わず一人呟いていた。「もう少し、君と暮らしたかった・・・」
「おかえりなさい。お背中流しましょうか」聞き覚えのある声が部屋の奥から聞こえてきた。まさか。もうキョウコはいないのに。そう思って振り返ると、そこには見覚えのあるキョウコの姿があった。
「キョウコ！11時になったらいなくなるんじゃなかったのか？」ケイタは驚きの声をあげた。「よかった、まだ間に合うんだ。延長したい、いや、ずっと一緒に暮らしたいんだ。いいかい？」
「もちろんです。ありがとうございます！」キョウコは晴れた空のような笑顔で答えた。「だって、まだ9時過ぎですから。間に合ってくれてよかったです。」そう、部屋の時計は21:21を指していた。ケイタはすっかり忘れていた。去年からのあの法律のことを。
前回まで、データベースを使ったWebアプリを作成して、SQLの使い方を学びました。
これらの参考書をガッツリ読めば、データベース設計のやり方は分かる。
リレーショナル・データベースは昔からある枯れた（＝安定した）技術なので、鉄板のノウハウが蓄積されている。
先人の知恵に沿って使うなら、データベース設計で悩む余地は少ない。＝攻略は意外と簡単。
経済産業省認定の情報処理技術者試験で「データベース・スペシャリスト」という資格もある。
「データベースエンジニア」という肩書きを名乗れば、ただのプログラマーよりも高給取りになれる。勉強した後、自分の知識を棚卸してみるつもりで資格を取ってみるのもいいだろう。
データベース・スペシャリスト試験の教科書には、浅く広くDBの知識が網羅されているので、１度眺めてみたらいいかも。
データベース設計（database design）は、ソフトウェア開発工程においてデータベースの詳細なデータモデルを作る工程である。
（分類方法にもよるけど）データベース設計は、このようなステップを経る。それでは順番に見ていこう。
実際にシステムを使うことになるユーザーにヒアリング調査して、データベース内に永続化（格納）すべきデータを決定する。
データのCRUD操作（Create 追加、Read 参照、Update 更新、Delete 削除）が、いつ、どこで発生するか？をまとめた表のこと。
「データベース 設計 CRUD表」等のキーワードでGoogle画像検索してみよう。どんな表か分かる。
↑このページの「図2 標準的なCRUD図（例）」みたいな表を作って確認すれば、扱うデータの過不足がなくなる。
だが安心して欲しい！
押さえておくべきポイントはあるので、そこだけ手抜きをしなければ、大失敗は避けられるだろう。
実は、後でテーブルを作るときに、データの更新頻度によって2種類に分類できるんだ。
トランザクションデータの扱いは、気を付けないとデータベースの性能低下に直結する。
どっちのタイプのデータなのか？要件定義の段階から見分ける癖を付けておこう。
試しに、Amazonのような通販サイトなら、どんなデータを扱うことになるのか？想像してみよう。
…仕入先、在庫数、受発注、配送会社、顧客情報、商品カテゴリー、商品スペック、などいろいろあるだろう。
いつどこでCRUDが発生するか？どれがマスターデータで、どれがトランザクションデータだろうか？
（ここまでの説明でURLを8個も貼ってしまったので、続きは次回にしよう。）
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
anond:20181101230220 増田式プログラマー養成講座 その16 Webアプリの完成見本（続き）
anond:20181104161900 増田式プログラマー養成講座 その17 Webアプリの骨組み
anond:20181104233013 増田式プログラマー養成講座 その18 SQLでデータの追加と取得
anond:20181110120715 増田式プログラマー養成講座 その19 SQLでデータの更新
anond:20181110182445 増田式プログラマー養成講座 その20 SQLでデータの削除
anond:20181111205255 増田式プログラマー養成講座 その21 データベース設計 (1)要件定義 ←★今ここ★
anond:20181119224031 増田式プログラマー養成講座 その22 データベース設計 概念→物理
：
https://anond.hatelabo.jp/20181110151336を読んで書きたくなったので
彼女どころか女友達すらおらず異性と手をつないだ事も二人きりでどこかへ行ったこともない完全な童貞です
転職を期に出来た空き時間で一念発起してアプリを2ヶ月ほど使ってみたので淡々と結果だけ書いていきます
32歳男
170前半
2つのアプリを使い800人ほどとマッチング、100人程度とメッセージのやりとりをし最終的に15人と会いました
二人で考えてドリア専門店へ、初めて女性と二人で食事に行ったので会う前からめちゃくちゃ緊張、会ってからもキョドりまくる
相手がトイレに行ってる間に会計を済ませる、店を出たところで相手があーしまったーみたいなノリで「会計どうしましょう？」と言ってきたので
震える声で「ままま、また次はお願い、し、します！」と何回もイメトレした脳内イケボで伝えた所「そうですね🎵」と言われその後、音信不通
－5000円
俺が決めてエスニック料理店へ、店に着いてそうそう「私カービィに似てるってよく言われるんです！」と軽くジャブをもらう
仰る通りまんまるな見た目だったが、それが功を奏したのかとても話しやすく前回よりも会話が弾んだ
トイレ中に会計を済ませる、会計について相手が触れることは一切なくそのまま帰宅、こちらから連絡することもなく終了
－4000円
雰囲気の良いイタリアンレストランへ、待ち合わせ場所が分かりにくくて会うのに時間がかかり店の予約時間に遅れる
単純に医者という仕事に興味があったので前半は質問攻めにしてしまう、後半は逆に相手からの質問攻め
トイレ中に会計を済ませる、店を出たところで会計どうしたんですか？と聞かれ払ったことを伝えるとなぜか笑われる、その後少しだけやり取りするもフェードアウト
－10000円
ネットで見つけた半個室のダイニングバーへ、これまで以上に写真とまったく違う相手が来たため「ついに着たか」となんとなく感動する
アニメ大好きなオタクだったため多少話が合うもよくよく話してみると腐女子だった、なぜかBLクイズを出題される
奢ろうと思ったがタイミングを逃し割り勘に、その後また会いたいとメッセージを貰うも良い友達になれそうとの注釈付きだったので答えに窮しのらりくらりしている内にフェードアウト
－2000円
前回使った半個室のダイニングバーへ、雨が降っていたため傘を買いに待ち合わせ場所を離れてしまい5分遅刻
遅刻こそしたもののお店も2度目だったり色々慣れてきたため調子にのる、ギャグでもかまそうかと思ったら相手から「実は難病なんです」と逆にかまされる
ほとんど真面目な話しかしなかった事もあり流れで割り勘に、そもそも遠方住みのため会う機会もなく「病気良くなるといいね」と掛け値なしの本音を伝えてフェードアウト
－2000円
半個室のダイニングバーへ、プロフィール写真と一切遜色ない美人が来てキョドる
意外にもアニメ好きだと言うのでアニメの話をしてるといきなり元カレとアニメを見た話をされて更にキョドる、ついでにキャバクラで働いていたけどコミュ障なんですと謎の身の上話をされ「俺もコミュ障だよ」とカミングアウトしてしまう
絶対に次はないと思ったので割り勘に、意外にも相手からメッセージが来るもなんと返したら良いか考えてる間にフェードアウト
－2000円
半個室のダイニングバーへ、お店についてから未成年だったと思い出す
男向けのアニメが好きだったため今までで一番話が盛り上がる、実は男の人と食事に行くのは初めてだと言われ「マッチングアプリなんか使わないで大学で良い人探したほうが良いよ」といらぬことを言ってしまう
割り勘にしましょうと言われたが全額出す、アプリはやめると約束してフェードアウト
－3000円
看護師25歳
半個室のダイニングバーへ、いきなり彼氏持ちですと申し訳なさそうに謝られる
終始彼氏が如何にクズかを聞かされる、別れたら？と月並みなことを言ってみるも借金を返してくれるまでは別れられないと言われる
割り勘で良いよねと伝えその通りに、彼氏と別れられるといいねと送りフェードアウト
－2000円
半個室のダイニングバーへ、お店につくやいなや「お酒めっちゃ飲むんですけど割り勘でいいですか？」と聞かれる
これなら飲み放題にしとけば良かったなと後悔しながら割り勘に、また食事に行こうと約束するも予定が合わずフェードアウト
－4000円
半個室のダイニングバーへ、出会い頭にいきなり「車持ってないんですか？」と聞かれる
年収や職業、結婚観や恋愛遍歴について質問攻めにされ、はじめてうんざりする
絶対に奢りたくなかったので割り勘に、相手からメッセージが来るもそれとなく断ってフェードアウト
－2000円
半個室のダイニングバーへ、お店に入る前になぜか服の裾を持たれ困惑する
もはや毎度の事だったのでいつも通り割り勘に、また食事にと言って別れるも相手からメッセージが来ないためこちらも送らずフェードアウト
－2000円
半個室のダイニングバーへ、事前に知っていたが相手は整形手術を受けた帰り
念願の二重を手に入れたためか異様にテンションが高かった
大学生だったので奢る、整形に偏見はなかったが遠方住みだったためお互いそれとなくフェードアウト
－3000円
半個室のダイニングバーへ、「ここ来たことある」と言われはじめての展開だったためキョドる
席についた途端「何人と並行してるんですか？」と言われ更にキョドる、「私も並行してるんで気にしないでください」と正直さをアピールされる
相手の提案もあり割り勘に、「ビビっとこなかったらフェードアウトしてください」と言われたからではないがなんとなくフェードアウト
－2000円
半個室のダイニングバーへ、化粧品を抱えていたため「もしかしてマルチビジネスの誘いか？」と思ってビビる
メイクしてみますか？と言われ少ししてみたりと思いのほか盛り上がる
割り勘で良い？と聞いてその通りに、また会おうとメッセージもしていたが会うことなくフェードアウト
－2000円
半個室のダイニングバーへ、待ち合わせ場所につくと同時に電話を掛けてきたためキョドる
もはや行きつけレベルになった店だったが、その経験が役にたたないくらい先手先手で色々決められてキョドる
相手から割り勘を提案される、次の約束を日付と共に具体的に立て実際会うことに、その後もやりとり継続中
－2000円
やればやるほど要求レベルがあがっていく、もっと良い人と出会えるかもと思いだらだら続けてしまった
彼女を作ることではなくよりスペックの高い女の子と約束を取り付けることが目的化していた
そこまでするのであれば、どうせなら次の段階の誘いをしてみてもよかったが断られるのが怖くて出来なかった
残り15人ほど会う約束をしていたが良いタイミングだったので全員にキャンセルのメッセージを送った
後悔はないし、やってよかったと思う
もしも今の人と付き合えたら大事にしたい
ただしこの先の進め方が分からないので教習本がほしい
マッチングの内訳ですが
とりあえずどんな相手だろうとイイねするチャンスがあればイイねする→800人とマッチング→うち半分に最初のメッセージを送る
→更に半分の200人からメッセージが返ってくる→但し1、2通で終わるパターンがまた半分あるので最終的にやりとりしたのは100人
って感じです
800人もマッチングするわけないって意見についてですがアプリを2つ使っていたので一つのアプリで400人です
最初の週にこちらから出来る限りのイイねを送りまくって100程度イイねがつくと、あとは女性の方からイイねがどんどん来ました
プロフィール写真は人生で初めて行った川遊びのリア充っぽい写真をメインにあと数枚、プロフィールの文章も女性ウケ狙って盛ってました
ナルシストっぽくなるので書きませんでしたが容姿はよく褒められます、客観的な指標だと兄弟がイケメンの触れ込みでモデルをやってました
使ってみて分かりましたが最終的に女性の見た目と年齢しか見なくなってました
基本は、同じなので前回やった更新処理をちょっと変えれば削除もすぐできます。
投稿されたメッセージを削除する機能を、Webページに付けてみよう。
前々回作ったメッセージの一覧の中に、削除ページにジャンプするリンクも入れておいた。
<td><a href="welcome/delete/<?php echo $item['id']; ?>">削除</a></td>
ブラウザーでHTMLソースを見ると、ここが以下のようなHTMLに書き換わってる。
これは「メッセージID番号が2のメッセージ」を削除対象にして、削除ページにジャンプする。
ユーザーが「http://localhost/waf/welcome/delete/2」というURLで、削除ページにアクセスしたら、コントローラーで「2」を受け取って使いたい。
CodeIgniterでは、URLの文字列を解析して、使うことができる。
以下のようにコントローラーを改造してみよう。
// 削除画面
public function delete($id = '')
{
$this->load->view('chat_delete');
}
delete()メソッドの引数で、URL中の「2」の部分を受け取れる。
「$id = $this->uri->segment(3);」でも受け取れる。
ユーザーに「本当に削除しますか？」みたいな注意喚起をしておきたい。
<?php defined('BASEPATH') or exit('No direct script access allowed');?>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<base href="<?php echo base_url(); ?>">
</head>
<body>
<form action="welcome/delete" method="post" accept-charset="utf-8">
<p style="background-color:lightpink"><?php echo $talk['message']; ?></p>
<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">
<input type="hidden" name="action" value="delete">
<?php else: ?>
<p>※該当するメッセージがありません。（または削除済です。）</p>
<?php endif;?>
<button>削除する</button>
</form>
<p><a href="welcome/index">戻る</a></p>
</body>
</html>
<p style="background-color:lightpink"><?php echo $talk['message']; ?></p>
削除するメッセージを色付きで強調して、ユーザーに確認してもらう。
<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">
コントローラーに削除対象のメッセージID番号を送るため、inputタグの「type="hidden"」でメッセージID番号を仕込んでおく。
// 削除画面
public function delete($id = '')
{
$id = $id ? $id : $this->input->post('id');
$action = $this->input->post('action');
$this->chat_model->delete_message($id);
}
$data['talk'] = $this->chat_model->read_message_by_id($id);
$this->load->view('chat_delete', $data);
}
で、モデルに用意したデータ削除用メソッドを呼び出しているだけ。
次は、モデルでdelete_message()メソッドを用意しよう。
// Delete
public function delete_message($id = 0)
{
$sql = "DELETE FROM talk WHERE id = ?";
$param = array($id);
$this->db->query($sql, $param);
return $this->db->affected_rows();
}
SQLの「DELETE」を使えば、指定したレコード（１件分のデータ）を削除できる。
「DELETE FROM talk WHERE id = ?」で、talkテーブルのmessageをidを指定して削除している。
データを削除した後の挙動は、メッセージID番号がなくなるので、削除ページに表示できるメッセージデータがなくなる。
（例）id=2のデータを削除したら、SQLで「SELECT * FROM talk WHERE id = 2」を取得しても、空のデータ＝データがない状態。
その場合は、
<p>※該当するメッセージがありません。（または削除済です。）</p>
と表示させてる。
以上で、SQLの「DELETE」を使ったデータの削除ができた。
長々と説明したが、今回の大事な点は、SQLの「DELETE」の使い方だ。
以上で、MVCフレームワークを使ったOOPの使い方とSQLの使い方を見てきた。
（SQLはSQLだけで説明したほうが良かったね！MVCフレームワークの説明とSQLの説明が混在すると要点が分かりづらくなる？）
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
anond:20181101230220 増田式プログラマー養成講座 その16 Webアプリの完成見本（続き）
anond:20181104161900 増田式プログラマー養成講座 その17 Webアプリの骨組み
anond:20181104233013 増田式プログラマー養成講座 その18 SQLでデータの追加と取得
anond:20181110120715 増田式プログラマー養成講座 その19 SQLでデータの更新
anond:20181110182445 増田式プログラマー養成講座 その20 SQLでデータの削除 ←★今ここ★
anond:20181111205255 増田式プログラマー養成講座 その21 データベース設計 (1)要件定義
：
ヴィクトリアズ・シークレットにデブのモデルを入れないのは体型差別だってわりとマジで批判されてんだって（笑）社長が公式回答しなきゃいけないレベルでデブのモデルがヴィクシーのショーに出る社会的意義（笑）が高まってるんだって（笑）
信じられないよパトラッシュ……アイドルグループにブスがいないのは差別だとしてブスを入れるよう要求、くらい意味がわからないよ……
ヴィクシーは死んだ。死んだんだよ。
直感的には、ソースコードを変更してゲームのバイナリを作り直したら、メモリ配置が全体的に変わって、元のバイナリとまともに差分がとれない気がする。
複数のDLCのうち、買ったもののみを選択的に適用しないといけない。
3Dモデル・画像などのアセットはどう埋め込んでいるんだろう。
PCゲームのインストールディレクトリを見ると、アセット用の巨大なファイルが数個のみある。
前回は、Webアプリの骨組み（スケルトン）に、SQLでデータの追加と取得をやりました。
前回作ったメッセージ一覧に、[編集]のリンクも入れておいた。
<td><a href="welcome/update/<?php echo $item['id']; ?>">編集</a></td>
という１行の部分。
ブラウザーでHTMLソースを見ると、以下のようなHTMLになってるはず。
これは「メッセージID番号が2」を対象にして、編集ページにジャンプすることを意味する。
「http://localhost/waf/welcome/update/2」というURLで編集ページにアクセスしたら、メッセージID番号の「2」を受け取れるようにしたい。
// 更新画面
public function update($id = '')
{
$this->load->view('chat_update');
}
CodeIgniterでは、URLから文字列を取り出す方法がいくつか用意されている。
// 更新画面
public function update()
{
$this->load->view('chat_update');
}
CodeIgniterで、URLの文字列から、特定部分の文字列を取り出す方法を見ておこう。
例えば、「http://localhost/waf/welcome/update/aaa/bbb/ccc」というURLにアクセスしたとき、CodeIgniterではURL中の「aaa」「bbb」「ccc」という部分は、以下のようにして取り出せる。
$seg1 = $this->uri->segment(1); // → 1番目のURL文字列：「welcome」＝コントローラーのクラス名
$seg2 = $this->uri->segment(2); // → 2番目のURL文字列：「update」＝クラスの中のメソッド名
$seg3 = $this->uri->segment(3); // → 3番目のURL文字列：「aaa」の部分
$seg4 = $this->uri->segment(4); // → 4番目のURL文字列：「bbb」の部分
$seg5 = $this->uri->segment(5); // → 5番目のURL文字列：「ccc」の部分
：
URLを「/」で区切って、base_url（http://localhost/waf/）の次から順番に、1番目のURL文字列、2番目のURL文字列、3番目のURL文字列、…とsegment()メソッドで順番を指定すれば取得できる。
データベースでメッセージIDを指定して、メッセージを取り出す機能を用意しよう。
public function read_message_by_id($id = 0)
{
$sql = "SELECT * FROM talk WHERE id = ?";
$param = array($id);
$query = $this->db->query($sql, $param);
return $query->row_array();
}
「WHERE id = 2」とすれば、メッセージID番号が2のメッセージのデータが「talk」テーブルから取り出せる。
もし該当するデータがなければ、返されるデータは空になる。（データが返ってこない。）
CodeIgniterの「row_array()」は、１件分のデータを配列の形にして返すメソッドだ。
<?php defined('BASEPATH') or exit('No direct script access allowed');?>
<!DOCTYPE html>
<html>
<head>
<base href="<?php echo base_url(); ?>">
</head>
<body>
<p>メッセージを変更して「更新する」ボタンを押してください。</p>
<form action="welcome/update" method="post" accept-charset="utf-8">
<label>メッセージ</label>
<input type="text" name="message" value="<?php echo $talk['message']; ?>">
<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">
<input type="hidden" name="action" value="update">
<?php else: ?>
<p>※該当するメッセージがありません。</p>
<?php endif;?>
<button>更新する</button>
</form>
<p><a href="welcome/index">戻る</a></p>
</body>
</html>
データベースから取り出した１件分のメッセージを表示する部分を追加した。
<input type="text" name="message" value="<?php echo $talk['message']; ?>">
の「<?php echo $talk['message']; ?>」という部分だ。
これで変更したいメッセージの本文を表示できる。
あと、編集したメッセージをWebサーバーに送信できるように、Formタグや送信ボタン（「更新する」の部分）も追加した。
<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">
という１行も仕込んである。
// 更新画面
public function update($id = '')
{
$id = $id ? $id : $this->input->post('id'); // id -> segment or post
$action = $this->input->post('action');
if ($action == 'update') {
$message = $this->input->post('message');
$this->chat_model->update_message($id, $message);
}
$data['talk'] = $this->chat_model->read_message_by_id($id);
$this->load->view('chat_update', $data);
}
メッセージID番号を指定して、データベースから取り出し、Viewに渡すデータを用意している。
ユーザーがメッセージの編集をしてWebサーバーに送信したら、データを更新する指示を出す部分も追加した。
$action = $this->input->post('action');
if ($action == 'update') {
$message = $this->input->post('message');
$this->chat_model->update_message($id, $message);
}
モデルにupdate_message()メソッドを用意して、$idと$messageを渡せば、該当データを更新するようにしたい。
次は、モデルでupdate_message()メソッドを用意しよう。
// Update
public function update_message($id = 0, $message = '')
{
$sql = "UPDATE talk SET message = ? WHERE id = ?";
$param = array($message, $id);
$this->db->query($sql, $param);
return $this->db->affected_rows();
}
SQLの「UPDATE」を使えば、指定したレコード（１件分のデータ）を更新できる。
「UPDATE talk SET message = ? WHERE id = ?」で、talkテーブルのmessageをidを指定して更新している。
CodeIgniterの「affected_rows()」メソッドは、更新した行数を返す。＝成功なら1行、失敗なら0行となる。
コントローラーの「$id = $id ? $id : $this->input->post('id');」という行は、$idの受け取り方が2パターンあるので、それに対応している。
＝編集ページの表示で、1回目の表示と、2回目以降の表示で、$idの受け渡し方が変わっている。
URLに埋め込む方法（上記の1回目のような方法）は、ユーザーが勝手に値をいじれるので、基本的には使わない方が良い。
以上で、SQLの「UPDATE」を使った、データの更新ができた。
長々と説明したが、今回の大事な点は、SQLの「UPDATE」の使い方だ。
CodeIgniterの使い方や、Webサイトの作り方（FormタグなどのHTMLの知識）は、オマケ程度に見ておいて欲しい。
次回は、データを削除するSQL「DELETE」の使い方を見てみよう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
anond:20181101230220 増田式プログラマー養成講座 その16 Webアプリの完成見本（続き）
anond:20181104161900 増田式プログラマー養成講座 その17 Webアプリの骨組み
anond:20181104233013 増田式プログラマー養成講座 その18 SQLでデータの追加と取得
anond:20181110120715 増田式プログラマー養成講座 その19 SQLでデータの更新 ←★今ここ★
anond:20181110182445 増田式プログラマー養成講座 その20 SQLでデータの削除
：
最近のファッションモデル界隈は混沌としている。長らく、細身の健常者の白人ばかりを起用してきた事を意識の高い人たちに責められ、どこもかしこも多様性とやらを打ち出し始めたのだ。具体的には、多くのショーでアジア人や皮膚病や太ったモデルが出てくるようになった。一見いい話のように思えるかもしれないが、実情は全くそうではない。この結果何が起こったかというと、冒頭に書いた「混沌」だ。
例えば、どのようなショーでもアジア人を起用しなくては叱られるので、アジア人モデルには向いていないショーにも駆り出されるようになった。先日行われたヴィクトリアズ・シークレットのショーが典型例で、下着をみせるためにある程度体にしっかりとしたボリュームがないといけないから平坦な体格のアジア人には不向きなのだが、ポリコレのために起用され、ショーのお茶を濁している。
まるでお弁当に申し訳程度に添えられたパセリのようだと思う。好きだから入れるパセリではなく、緑の食べ物もちゃんと入ってますよ！というアピールのために添えられ、見向きもされず食べられることもなく捨てられるパセリ。
モデルというのは美しさを競うオリンピックアスリートである。オリンピック100m走の決勝にアジア人や障碍者がいないのはポリコレ違反だとしてそれらをねじ込むようなことがあってはならないのだ。細くて健常者の白人がより美しいというなら、そういう人ばかりになるのは仕方がないことなのだ。何なんだポリコレって。何なんだ多様性って……おかげで世界から美しい光景が消えようとしている。
説明するのだるい感じになってきたな…あのね、ロボットの問題は「ガッシリ物を掴めるモーター」とかじゃないんだよ。人間は見たまま物体をひょいと掴むってことができるじゃん。で、落としたらキャッチとかできるじゃん。で、その動きを一回記録すれば大電力を注ぎ込んでロボットに同じ動きをさせることはできる。横増田が言ってる「プログラムした動きを繰り返すだけ」は昭和の頃から自動車では普通にやってるし、無しでは現代社会は回らなくなってはいるのよ。
だけど、その動きを自動生成することができない。
つーのは、生物は生まれてから10年や50年で機械学習してものを掴んだり操作したりする動きを覚えるわけじゃなくて、小鳥から人間まで共通に持ってる脳のハードウェア処理エンジンをチューニングして使ってる。鹿の子供は生まれてから10分で立ち上がって親についていくというくらい、ほぼ遺伝子に書き込まれて完成済みの専用計算ブロックがある。そしてその構成は完全には解明されていないどころか、まだ具体的にどういう小部分があって同相互接続されているのかさっぱり分からず、工業の分野の数学的モデルで解決しよう(古典・現代制御)とか解明された他の手法を転用してなんとか真似できないか(ディープラーニング™など)と試行錯誤している状態。
このハードウェア処理エンジンは動物に基本的に備わっているから、ハード的に人間の動きをほぼ再現できるロボットを見ると、形には自然と機能が伴うと思ってチャチャッとソフトを開発すれば何でも掴めて人間を置き換えられると思っちゃう。
違うんだよ。この完全に理性とか思考とかいった人類が人類である価値を全く含まない部分が、最低賃金以上の金を支払う価値が全く無い単純極まる肉体労働タスクこそが、種としての人類の最後の砦といっても過言ではないんだ。
