  |
はてなキーワード: オブジェクトとは
メーカー系SIer（仮にF社とする）のプロジェクトのもとで単体テスト工程に参画しているんだけど、非常につらいものがある。
この状況でテストする身にもなってくれよ...。
もう疲れた。
・男性に頼らない自立した自立した女性、活発に動く女性はヒーローのアニメーション
・サポートする男性キャラクターはありません、男性の影はありません
・女の子が格闘して格好いいと思ってほしい（ドラゴンボール、ワンピース、ナルト、セブンデッドリースポーツオブジェクトなど）。
・聖闘士星矢と北斗の拳のようなものと世界のために戦うことが望ましい
・男性の視点が含まれているので、戦いの間に技術的な名前で話すことまたは精神の叫び声を得ることは不可能です。 例えば、キラキラの文庫は良くありません。
・愛の要素はありません。 愛至上主義がなくても
・かなり治療法のような女の子にとっては「女性のため」ではないのでそうではありません。 大人のための高いターゲットと商品のための数字はそこにあります男性のファンによって見るアニメ
・主なターゲットレイヤは男性ではありません。 「女性を楽しむことができる男性のための」アニメーションはよくありません。
・男性の作家、男性の作家など男性の視点が入力されていない "女性を考える女性のための女性の主人公"はよくありません。 男性による女性主人公思想は名誉ある男性ヒーローだろうから、そうしないでください。
・・たとえば、Ke！ 女は部長、シリーズ作曲、キャラクターデザイン、作画部長、主役に任命され、ストーリーボードストーリーには女もいるが原作者は男性、主視聴者も男性
・萌え絵はダメです。 "萌え"の基準は、空の境界、約束のネバーランド、ウィザードの妻、バイオレットエバーガーデン、キノの旅、リトルウィッチアカデミアはOKです。 まどか、ひだまりスケッチ、ラブライブ！ NGです
・セクシーなスタイルは、Bayonettaのように見えます、キラーキルは大丈夫です
・「少女戦」のようなタイトルが悪くなるのは良くありません。 中身だからダメ
・集団的なイメージプレイは女性の主題ではないので、それは良くありません。 PSYCHO - PASSは良くありません。 明らかに女性の英雄が優れています。
・魔法少女は趣味ではないので、しないでください（CCサクラ、セーラームーンなど）
・それは深夜のバンド放送ではない、それは大衆を受け取った主要な作品であるべきです
・それは見ているように感じるには長すぎるので2つ以上のコースを持つには長すぎるように思われるのでショートはより良いです
・理想はバイオハザードクレア、RDGレッドデータガール、スピリットガーディアン、チハヤフル、攻殻機動隊、パトレイバー
該当する場合、マンガ、小説、ゲームは問題ありません。 Animation博士の増田氏がしばらく出てきているとしたら？
（その他の注意事項）
・Originは「ドラマには女性のヒーローがたくさんいるがアニメには数少ない」と言っていて問題があるようで、実写のコンテンツは除外
・「現在配給されているアニメには女性主人公がほとんどいない」というのは問題なので、古すぎるのはよくありません
・「さて、あなたがそれを作ろうとするなら」は「そのような作品はほとんどないので、それは問題となるコメントです、それであなたは自分でそれを議論することができるだけであるようにすることができます」
（付記２）
@矛盾と質問内の理想的な作業が最初に条件から外れていることを確認してください、@ quzi23してください。 この人の発言から条件を抽出して要約したところです。
そもそもITゼネコン主導の大規模開発は悪評まみれで、天国案件なんて数えるほどしかないと言われる。
なので誰がやってもしんどいと思うが、特に自分には全く合わなかった。
自分のプログラミングは、動かす前に「これで行けるだろう」と確信しながら、動かしてみて抜けや漏れが発覚するタイプなので、コードの品質は多分悪い部類に入るだろう。
つーか、仕事なんて楽に済ませたいから、コードなんて可能な限り書きたくないというのが一番にある、かなり独善的な人間だ。
一方で大規模SIのプログラマなんて、基本的にライン工か調整役以外お呼びでない。
そしてコミュ障でもある自分は必然的に、もらった設計書の長ーいフローをひたすらコードに翻訳するという、まさにライン工として身を粉にして働くしかなかった。
それこそif文の後のelseが何ページも先になろうが、ループが何重にネストしようが一切気にせず、可能な限り設計に沿うようコードを書き続けた。
元々コードを書かずに済ませたい自分には、正直目が眩みそうな作業だったが仕方ない。
しかし上述のように元来不注意な人間なので、品質は恐らくメンバーの中では最低レベルの代物を量産する結果となった。
コーディングもスケジュール的に余裕なかったが、テストに至っては必死にというか、死に物狂いで頑張らないと遅れてしまうくらい、作業量が半端なかった。
ちょっと込み入ったメソッドになると、それだけでテストケースが20とか30とか相当な数になるので、ケースの抽出から始まって、最終的にレポートにまとめてカバレッジと一緒に提出するまで、地獄のような作業の連続になった。
最終的には体調不良を理由に「すんませんクビにしてください」と言って現場を抜け、その責任を取って僻地に飛ばされ今に至る。
そんなことはどうでもいいのだが、それ以来、テスト自動化ツールに対しては、理屈抜きに憎しみしか沸かないようになった。
フレームワークの便利さを推す記事とか、むやみに持ち上げるヤツは一切信用できなくなったし、オブジェクト志向をやたら崇高で革命的なもののように吹聴するやつはもっと信用できなくなった。
問合型言語のSQLは、「関係代数」という計算モデルを基に作られたプログラミング言語。
一度「関係代数」について学んでおくと、RDBの使い方について、理解が深まる。
↑このスライド作者さんは他にもDB関係の資料を作成されてるので見ておくといいかも？
SQL以外にも「SPARQL」、「TMQL」（Topic Maps Query Language）等、いろいろな問合型言語がある。
実際に使う機会は少ないかもしれないが、「問い合わせ」で処理するという発想は参考になるかも？
Datalogは「Prolog」（論理型言語）を源流にもつ宣言的なデータベース問合せ言語。DatalogはSQLと同等の表現力を持つ。
Datalogは様々なプログラミング言語で利用できる。
「トピックマップ」は、本の索引をもっと高機能にしたような仕組みで、RDBとは違う形でデータを蓄積／検索できる。
NoSQL（一般に "Not only SQL" と解釈される）とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。
関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合操作を利用しないこと（場合によっては単にそのような機能が欠落しているだけ）、水平スケーラビリティが確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。
学術的な世界では、この種のデータベースのことを構造型ストレージ (structured storage) と呼ぶことが多い。
NoSQL系データベースは、関係データベースのような汎用性は欠くものの、その制約された条件下ではRDBMSより高いパフォーマンスを持つ。
NoSQL系データベース管理システムが有用な場面は、関係モデルを必要としないデータを扱う時や、大量のデータを扱う時である。
有名な実装として、GoogleのBigTable、アマゾンのAmazon DynamoDBなどがある。オープンソースの実装も数多く存在し、例えばMongoDB、Redis、Apache HBase、HyperTable, Apache Cassandraなどがある。
問合型言語の学習の最後に、SQLを巡る物語も見てみよう。（SQLの学習をドラマチックで楽しいものにしたいねｗ）
RDBを活用すれば、大量のデータを処理して、多くの仕事を効率化できる。（金持ちへの扉が開かれる。）
エドガー・フランク・コッド（Edgar Frank "Ted" Codd, 1923年8月23日 - 2003年4月18日）は、イングランド生まれの計算機科学者
。関係データベースの理論的基盤であるデータベース管理の関係モデルを発明した。
1960年代から1970年代、コッドはデータ配置に関する理論を構築し、1970年 "A Relational Model of Data for Large Shared Data Banks" （大規模共有データバンクのデータ関係モデル）という論文を発表した（IBM内ではその1年前に公表している）。
しかし、IBMはライバルがそれを実装し始めるまで彼の提案を実行に移そうとせず、コッドは失望した。
当初、IBMはIMS/DBの収益を守るため、関係モデルを実装することを拒んだ。
コッドはIBMの顧客に自身のモデルを実装した場合の可能性を提示し、顧客からIBMに圧力をかけさせた。
そこでIBMは関係モデルの実装を開発する System R プロジェクトを Future Systems プロジェクトに含める形で立ち上げたが、その開発チームとコッドは分離され、しかもコッドの理論に精通した者はチーム内にいなかった。
結果として彼らはコッドの Alpha 言語を使わずにリレーショナルでないSEQUEL言語を開発した。
ローレンス・ジョセフ・エリソン（Lawrence Joseph Ellison、1944年8月17日 - ）は、データベースソフトをはじめとする大手ビジネスソフトウェア企業オラクル・コーポレーションの共同設立者であり、元CEO、会長、CTOである。
2014年現在の総資産は500億ドルで、世界で5番目の富豪である。
ニューヨーク出身。アシュケナジム・ユダヤ人の母親のフローレンス・スペルマン(Florence Spellman)は出産当時未婚の19歳で、生後9ヶ月のラリーをシカゴに住む叔母リリアン・エリソンとその夫である義理の叔父ルイス・エリソンに養子として引き取ってもらった。ラリーは実の母の名も知らず育ったが、48歳の時に初めて対面した。
高校時代は秀才だが、無愛想な生徒だった。イリノイ大学アーバナ・シャンペーン校に二年生まで通っていたが、リリアンの死後まもなく退学。カリフォルニア州北部で夏を過ごした後、シカゴ大学で学ぶために実家に戻ったものの三ヶ月でまたも退学し、カリフォルニアへ移住。この頃、コンピュータに触れ始めている。
1970年代、エリソンはアンペックスで働いた。彼の関わったプロジェクトのひとつにCIA向けデータベース開発があり、彼はそれに「オラクル (Oracle)」と名づけた。
エリソンはエドガー・F・コッドのリレーショナルデータベースシステムに関する論文 A Relational Model of Data for Large Shared Data Banks に触発され、1977年、自己資金1400ドルでオラクルを設立した。
彼はIBMのSystem Rデータベースがコッドの理論に基づいたものであると聞き、Oracleもこれと互換性のある製品にしたかったのだが、IBMはエラーコードを秘密にすることによって互換製品が出てくるのを防いでいた。
オラクルの最初の製品はOracle 2であり、Oracle 1は存在しない。このリリース番号は、それ以前のバージョンのバグが全て解決されていることを暗示しようとして付けられた。
1997年8月、ラリー・エリソンは親友のスティーブ・ジョブズがアップルに戻った後、同社の取締役に就任した。2002年9月20日、取締役会に出席する時間が充分に取れないことを理由にアップルの取締役を辞任した。
この人、キャラクター的にはあまり好きじゃないけど、行動力はすごいね！
Oracleのバージョンを「2」から始めて、改良されているように見せかける。～ちょっと詐欺っぽいけど、商売もうまい？ｗ
SQLやデータベースを活用して、素敵なアプリやWebサービスを開発してください。
では、これでいったん、増田式プログラマー養成講座を終了します。
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 データベース設計 概念→物理
anond:20181204142213 増田式プログラマー養成講座 その23 SQLを巡る物語 ←★今ここ★
：
anond:20181024214737 増田式プログラマー養成講座 コンテンツ一覧
昔のアニメを見返してて思ったけどやっぱりアニメはアナログだね
と言っても理由はよく言われるようなセルの質感がとか作画力がなんて話ではなく
レンズなんだよね
例え元がセルに描かれた絵でも本物のレンズを通して撮影されたものというだけでやっぱり空気感が違う
セルの手前にある数センチの空気層だけはまごうことなき実写だから
思えば3Dアニメがオブジェクトを表示するのがやっとだった頃から
今ではレンズや空気のシミュレーションが出来てきてリアルになった一方で
純度100％の精彩なイラストを表示するかに苦心してきてしまったような気がする
むしろこっちこそが今のアニメファンの求めるものなのかも知れないし
どうしようもないのかも知れないな
残念だ
今回は俺も一応モチベーションがあったのに、ここにきてそれが減少していくのを感じる。
これは、アレだ。
どうする。
今から弟を迎えに行けば間に合うか。
いや、いま向かっている途中ですれ違ったらどうする。
もう今回の小旅行を断ったほうがいいだろうか。
ああ、くそ。
寝起きの頭じゃあ考えがまとまらない。
「ごめん、にい……兄貴。遅くなった」
頭がグズりだしてきたとき、弟がやっと来てくれた。
それで失ったモチベーションが元通りになるほど俺は調子のいい人間ではないが、ひとまず安心といったところか。
「弟よお、荷物もないのに何をそんな時間をかけることがあるんだ」
「い……いやあ、寝癖が大暴れしてさあ」
「寝癖って。お前そういうの気にするタイプじゃないだろう」
「そ、そうかな……」
しかし、このときの俺は寝起きで判断力が鈍っていて、そのことを深く考えていなかったんだ。
「じゃあ集まったところで、別次元での行動についておさらいするよ」
ガイドが注意事項を説明し始めるが、内容はほとんど当然のことばかりだ。
別次元に悪影響を与えないために目立つようなことはしないだとか、その次元の住人に迷惑をかけないようにだとか。
ところどころ小難しい横文字を並べている以外は、修学旅行の学生しおりレベルのことしか言っていない。
「……というわけで、キミたちが注意すべきなのはそんなところかな。ちゃんと心がけてね」
「は～い」
だからといって、本当に修学旅行中の生徒みたいな気のない返事をしてしまう弟も大概だが。
言ってからそのことに気づいたようで、気まずそうにモジモジしている。
こいつ、まだ寝ぼけているようだな。
「……ほら、キミも返事！」
なんだかこのあたりのやり取り、本当に修学旅行みたいなノリだな。
「じゃあ、今から“穴”を開けるよ。そこを通って別の次元を移動するんだ」
いわゆるワームホール的なやつか。
気取った横文字並べられるのも癪だが、“穴”っていう表現は風情がねえなあ。
「開いたらすぐに入るように。長く開けておくと次元警察が煩いから、すぐに閉めないといけない」
放り投げられたオブジェは空中で静止し、1秒と経たない内に“穴”を作り出した。
穴の先に見える景色は淀んでいて見えにくいが、自分たちが今いる世界とは明らかに違うと感じさせる。
「さあ、ボクについてきて！ 早く入って！」
未だモジモジしている弟の手を引いて、俺はその空間に勢いよく入った。
今回は、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 データベース設計 概念→物理 ←★今ここ★
：
「一緒に別の次元に行ってみよう！ そうすればキミも、ボクの言っていることを信じるはずだ」
『別の次元』
「別の次元ってのはアレか。パラレルワールド、平行世界的なヤツか？」
今までにない俺の好反応に、ガイドもたじろいでいた。
「んー……まあ広義的には」
「そうか……やっと分かってきたようだな。そういうのでいいんだよ」
「どういうの？」
俺が知っている限り、こいつが今までやってきたことは尽く期待外れだった。
人の家の庭を焼き払う謎のオブジェクト。
生身の俺に妨害されただけで、何もできなくなる程度の機能しかないダサいスーツ。
色々なものを無理やり詰め込んで何がやりたいか分からない、使い勝手の悪そうな多機能端末。
将来生まれてくる子供の人生をシミュレーションできる装置だの、罪と罰を測ることができるメーターだの。
こいつにとっては未来の科学力を証明しているつもりなのだろうが、いずれも胡散臭いか感性がズレている。
もっと普遍的なイメージに応えるようなものなら良いのに、どれも頭でっかちだったからコメントに困っていた。
シンプルに空を自由に飛べるだとか、玩具の兵隊だとか、世界旅行に行けるようなものとかでいいのに。
いつもヒネたことばかりやってくるから、凄いかどうかイマイチ分からないし、興味も湧いてこない。
だが今回、やっとマトモなものが出てきてくれたようだ。
「じゃあ、その別次元について、話を聞こうか」
今でこそ落ち着いてはいるが、ここにきてその頃の気持ちが再燃していく。
そして出発当日、早朝。
別次元に与える影響を最小限にするため、身に着けるものや、持ち物は最低限だ。
それでも俺がOKしたのは、もちろんパラレルワールドというものに惹かれたのもあるが、“とある条件”を飲んでもらったからだ。
「後は弟くんが来るのを待つだけだね」
俺は同行者、つまり弟も共に連れて行くことを条件にした。
見知った身内でもいれば、多少はマシになるだろう。
……だが、弟が来るのが遅い。
後から来ると言っていたが、まさか二度寝しているんじゃないだろうな。
「色々とこっちにも事情があるんだよ。好き勝手に次元を跨ぐと厳罰になるから、あんまり融通利かすわけにはいかないんだ」
「じゃあ、このままだとお前と二人で旅行ってか？」
「まあ、元から二人で行く予定だったんだし同じことでしょ」
勘弁してくれ。
こいつと長時間一緒とか、補正をかけてもロクな思い出にならないぞ。
