「順次」を含む日記 RSS

はてなキーワード: 順次とは

2019-01-13

シス男性は同性の裸に興味を持つことが禁止されてるにすぎない

https://anond.hatelabo.jp/20190112203947

シス男性そもそも同性の裸に興味を持たないのがマナー、という空気が作られているだけで別にゲイ排除していないわけではない。

あとシス男性ゲイフォビアは結構強烈だぞ、と思うけれどそれはちょっとサンプルが自分だけなのでもう少し一般化できそうなら今度書く。

顕著な例がトイレかと思うので、トイレの話から

最近どんどん公共トイレが清潔になり、明るくなってきたんだけど、何故か小便器の間の敷居がなくなってきている傾向も出てきた。

パッと見た雰囲気は確かに良くなったが、これはそれだけ「隣の男のちんこが見える」状態になってるってのと同じなんだわな。

例えば大阪メトロは全駅のトイレをきれいにしようっつって全駅に順次おいてる小便器これやぞ(下記リンク画像右上)

http://www.com-et.com/jp/file/fetch/130458/

便器に傾斜がつきまくってるので、小学生がよくやっていた「体を押し付けちんこを隠す」ことすらできない構造になっているのはちんこ見せればええやん、という潔ささえ感じる。

もちろん体を押し付けるのが不衛生極まりないことや、多くのおじさまが小便を床にこぼすからこういう形状に進化してきたのだろうから、仕方ないのかもしれないけれど、カバン掛けじゃなくて一蘭の味集中カウンターみたいに可動式の敷居入れてほしかったやつ。

この「隣のちんこ丸見え問題」に対して世の一般男性がどうやって対策しているかというと、「お互いのちんこに無関心を決め込む」という暗黙の了解を作っているだけなんだよ。

例えば「他の小便器が空いているのに自分の隣に来た友人」に対して「なんだよ隣に来るなよホモかよ」と冗談交じりに言っていた奴は周囲に結構いたのでは?

まり男性男子トイレに入るときに「俺はホモじゃないか他人ちんこには興味ないよ」ってアピールしながらトイレに入るのが常識でありマナーになってる。

このマナーが強烈な支配力を持つせいで、特に思春期の頃は小便器で極端にちんこを隠そうとする奴が出てくるとそれはそれで「ホモかよ」って言われ出すんだよな。

「お互いちんこに興味ないから隠す必要なんてないよね」っていう形にマナー解釈して、極端に隠すやつはむしろ周囲のちんこに興味津々だというレッテル貼られるわけ。

もちろん実際は思春期特有自分の体が他人と違うのでは、という不安から「いや、見たくないんだけどね?目に入るんだよね」ってスタンス他人ちんこチェックしたいっていう思いもあるだろうけど。

とまぁ、なんにせよ、こういう経験を経て、男性は「周囲の男性の裸に興味を持たないもの」というジェンダーロールが作られていくわけ。

から銭湯ゲイがいてもそれは「気にならない」でも「受け入れてる」わけでもなくて、「気にしないのがマナー」になってるクソ事例なんだわ。気にするやつはホモ(お仲間)扱いされるから

この空気に対する言及無しに「銭湯ではゲイを受け入れている」という流れに持ってくのはちょっと無理筋だわ。

ちなみに、トイレの話の補足をしておくと、男性の側から「そんなマナー要らんからシステムで解決してほしい」って声は上がってきていて。すべての男子トイレを個室にして小便器をなくそう、という動きは少しずつ出てきている。

https://www.huffingtonpost.jp/2017/11/10/otoko_a_23272964/?ec_carp=7686460202638501780

和式トイレをなくす運動と同じで、一部の小学校から始まってるとは聞いている。

この流れが進めば最終的にトイレは男女共用になっていくだろうし、そういう世界になってくれれば自分は嬉しい。

2019-01-11

再審請求事件判決の続き

全体としては「作らせれば早く出られる」という被疑者射幸心につけこんで捜査官が作成した虚偽の供述調書である可能性が高く、調書自体証拠として信用できず、証拠価値がない。

ク この点について、検察官は、警察検察での取り調べでは、書面作成はどうでもいいことであって、現在警察署、検察庁では、日本語も解さな犯行当時の申立人のようなニートのし反社会的行動抽象しつつ、取り調べで日本語能力を鍛えさせることを目途として行われているから、裁判官は、この趣旨を没却しないために、本件調書を採用すべきと主張するが、取調べの制度はそのような趣旨で設けられたものではない上に、調書に抽象されている反社会行動についても、その実質が脅迫に見えるだけの単なる国家への悪口であり、刑法222条が処罰対象としている程度のものとはとうてい言えないのであるから、そのような調書には価値がなく、裁判所採用すべきではない。

ケ 検察官は、申立人が公判期日に法廷反省の弁を述べているし、これをさせた趣旨も、申立人を法廷で辱めるところにあって、そこがポイントなのであるから裁判官は、これを没却すべきではないなどと主張するが、公判での反省は、裁判官被告人が犯した罪につき、真に反省をしているかどうかを観察し、反省が深まっているとき執行猶予を与え、単に形式的反省をしているだけで実質においては執行猶予を狙うために裁判官の前でのみうたっている虚偽の反省である場合には執行猶予を与えない、という、被告人刑務所に行くか行かないか裁判官の全人格で決めるというところにその趣旨があるのであって、検察官の言っていることは滅茶苦茶であり採用できない。そして、本件に関して言えば、当時置かれていた申立人の心境からすれば、単に刑務所に行くのは恐ろしいと考えたために、全力で反省しているかのような文言手紙に書いて裁判官の前で必死に述べただけに決まっているのであって、その狙いは刑務所行きを避けることにあり、毫も犯行を認める趣旨ではない。これに対して当時の裁判官は、申立人が刑務所行きたくないという必死意思があるし、法廷で涙涙の反省をしているから、情けを感じて執行猶予にしたにすぎず、確定判決文章も、極めて形式定型的な文章であって判決をした裁判官が本件に関し根ほり葉ほり検討しようとした姿勢は伺われず、確定判決自体も無内容なものである

コ そうすると、申立人が公判反省の弁を述べたからといって、犯行を認めたということにはならない。したがって、以上を総合すると、本件に関しては犯罪証拠がない。

サ この点について、平成30年(た)第2号再審請求事件を書いた任介辰哉裁判官は、申立人は、本件が犯罪の事案でもないし故意も認められないと主張するが、独自立場からの主張で裏付け証拠がないとか、他に適法な主張立証がないか再審理由に当たらないと判断しているが、同事件に供した申立書を形式的に見て、無罪であるとは思ったが、即時抗告特別抗告もあるし、再審何度でもできる上に、裁判官としても、本件につき詳細に審理する気がないか、仮にあっても、本件具体的事情を知りたくない、見たくないか無視をした上で、証拠が挙がってないなどと適当なことを言ってつっぱねたか、ないしは、裁判所自体にもはや明治時代の神もなければ昭和正義もないし、職務形式的に行っているから、申立書だけでは足りない、仮に善意があるとしても、もっと書いてからしろ、といった卑劣趣旨形式的判断をしたものと解されるが、裁判所は、再審申立者がどんな人であろうが、どのようなことを言おうが、いかなる文章を書こうが、裁判官

主張を聞いて無罪だと思ったら無罪にしなければいけないだけのことであって、どういう形の書面を書いたかとか、どの分量の書面を書いたか問題ではない。そもそも現在日本人再審請求者が、分量のある書面を当然に書けるという事実もないし、また、直截に判断して無罪と分かるのに一々長々とした書面を提出させるのは、時間無駄資源無駄裁判所としても、職務障害になるというべきである

シ そして、ア~コ記載の陳述をみれば、概要、本件には、生々しい脅迫故意もないし、そもそも脅迫自体を行っていないことも、裁判官において十分察知できる。したがってア~コ以上の陳述ないし証拠をいちいちそろえる必要はないし、裁判官はア~コの事情を読めば本件が無罪であることは判断できるから、これ以上、長々と文章を書く必要はない。

ス よって、ア~コ記載事情から、本件は懲役2年に値する脅迫行為などとは毫も認められないから、再審を開始すべきである

4 当裁判所判断

 そこで検討するに、3で申立人が述べる諸事情総合考慮し、一件記録を再度検討すると、結局、本件書き込みは、俗にいうところの強がり記載であり、名前として挙げられた具体的な被害者らに対し、現実具体的にその生命身体財産に対して危害を加える旨を告知し、被害者らに対して高度の恐怖感を与える意図を伴った、懲役刑に値する程度の高度に卑劣で悪質な脅迫行為とは認められず、捜査員による調書も、申立人が刑事施設を早く出たいという射幸心に付け込み、警察官、検察官が自ら作文し、署名押印をさせたものに過ぎないと推認され、法廷での反省も、犯行を認める趣旨ではなく、刑務所行きを回避するための便法であることも容易に推認されるから刑事手続きとして全くその体をなしておらず、警察検察による捜査自体が極めていかがわしいのであって、本件につき、申立人が犯罪をした証拠がないに帰し、3記載のア~コの事情から犯罪をしたと認定するには合理的な疑いの余地が発生せざるをえない。

 検察官は、2記載のとおりるる主張するが、刑事司法形式的しか仕事をしないというのは検察官の身勝手判断であって、容認できないし、仮に検察官がいうところの実質的理由についても、本件がいわゆる国家に対する批判エスカレートした最終的な結果として、名前を挙げた者らに対して脅迫をするに至ったものであるという見解も、的外れであり、申立人主張の2のア~コの事情および一件記録を再度検討すると、はてなダイアリー記載文言も、2ちゃんねる記載文言も、当時の情勢を考慮してもなお、被害者らに対し卑劣執拗な犯意を持つ脅迫行為などとはとうてい言えないし、現在時点で検討しても、文言周辺の批判文章や、2ちゃんねるでは、書き込み者を犯罪者に仕立て上げようとする多くの者の書き込みが目立つばかりで、書き込みのものからは何らの畏怖感も感じられないし、仮に被害者である女性大学教員や元最高裁判事が本件書き込みから恐怖を覚えたにしても、いずれの女性被害者高齢であって、当時20代前半であった申立人とは社会感覚も相当にずれていることを考慮すると、書き込み者がした形式的書き込み社会内に紛れてあたか書き込み内容を実行されるのではないかと誤信したり、または、2ちゃんねるで、このような文言を書き込む者を犯罪者に仕立て上げようとする者の多くの書き込みあいまって、右誤信を強めたもの推認されるのであって、仮に女性被害者らが畏怖感を覚え被害にあったにせよ、書き込み者本人は、そのつもりのない強がりを書いただけで、これが2ちゃんねらーによる仕立て上げもあいまって被害者らにとって脅迫と感じられたものであって、むしろ脅迫をしたのは他の多くの2ちゃんねらーの感があるし、書き込み自身は、懲役刑に処するに値するような、真に執拗かつ悪質でリアリティのある脅迫行為をせんと企図し、敢行したとまでは、とうてい認められない。申立人には、その性格人生経緯、被害者との関係においても、書き込み当時、生々しい脅迫をする動機がないし、仮に本件の動機を察するとすれば、悪口強がりの域を出るものではなく、いずれにせよ、刑法処罰しようとしている脅迫としては、採るに足る醜悪故意危険性を一切欠く形式文言にすぎず、これが犯罪になるとすれば誤判により多くの罪のない者が人権を奪われる事態になるばかりか、かかる形式文言を書く者のみを検挙し、社会内でより巧妙な手口で生々しい脅迫行為をしている者を見逃しているとすれば、刑事司法の怠慢と犯罪と言わねばならない。

 仮に捜査員が本件に関して、わずかでも脅迫故意を認めたとしても、本件から感じられる犯意は、まったくないか、あったにしても極めて微々たるものであって、書き込み当時の書き込みの生成の勢いとか、そういったもの推認してもなお、書き込み者は生々しい脅迫ではなく、2ちゃんねる呪詛を書き連ねていただけで、その生成的な実質において脅迫を働いたとまでは言えない(仮にも東大法学部卒業している人間であって、しか逮捕されて刑事施設に入りたいと思っていたような人間でもないから、安易逮捕されるような真の犯罪行為に出るとは思われないし、当時の引っ込み思案な申立人に警察と戦う度胸も認められないし、そもそも逮捕自体を恐れる人間だったとみられるため、捕まる可能性のある実質的脅迫行為を堂々とするとは考えられないし、これを考慮すると、本件書き込みの実質は、犯罪の域にまで達しているものではなく、本人にも捕まらない程度に意思を調節する考えはあったと思われる。逮捕を恐れている以上、逮捕される可能性あることを安易にするとは思われない)。通常であればインターネットありがちな不平不満の書き込みで、立件に値するようなものでないし、かかる微罪もしくは犯罪でもない行為を一々立件していては、社会は回らない。また、微罪と判断たにしてもこれをことさら公判まで実施して懲役2年の刑にしているのは、国家刑罰権の濫用も甚だしく、許されない。そうすると、本件については、捜査員が危険犯とみたため逮捕したというより、申立人が2ちゃんねらーなどから刺激を受けて瞬時的に怒張し本件書き込みをしたのを利用して殊更申立人をみせしめにして苛めるために捜査されたとみられ、実質的理由はないと考えられる。本件に関しては、あたかネット上の立小便のごときもので通例不問にされている程度の極めて微々たる反法行為をことさら重大犯罪に仕立て上げているところに本質があると思われる。したがって、警察検察ら、捜査員がした捜査は、全体として極めて信用性がないし、誠実に捜査取調べをしたとも評価できないし、特に2ちゃんねらー日本人故意に刺激し、怒張させて、特定形式文言を書くと犯罪者に仕立て上げていることも鑑みると、本件に関しては、陰謀的なものが看取され、なおさら本件を一々脅迫罪に問擬した確定判決は、実質がないと認められる。本来刑事司法は、社会内に存する真の危険犯であり、刑務所に入れて矯正教育実施するに値するだけの、悪の道にひた走る種類の人間逮捕し、訴追し、刑を言い渡すをもってその任とし、少なくとも本件のように、被告人の具体的事情に鑑みて自然危険犯でもないし、陰謀的なものによって犯罪者に仕立て上げられた者を処罰する趣旨運営されているものではない。したがって、仮に本件、はてなダイアリー2ちゃんねるでの書き込み形態のものが、全体として、反国家的で、国家批判し、その中で国家関係者に対する脅迫行為と見えるようなものがあったにせよ、善良な捜査員であれば、書き込み者は真正凶悪犯ではないと推知し、逮捕には至らないはずであるところ、本件捜査に関して言えば、捜査員はそのようなことを考えた形跡も伺われず、むしろ刑務所に入れる必要のないような人をあえて逮捕するという暴走行為に及んだだけと認められる。これを考えても、なおさら本件につき、刑事手続きに乗せる必要はなかったのであって、窮極するところ、2008年時点でのインターネットの情勢も踏まえ、本件書き込みは、脅迫形態をとる不平不満の域を超えるものではなく、百歩譲って、わずかでも脅迫故意があったにしても、捜査機関としては、社会によくある程度の違法性の微小な反法行為とみて、信号無視、野原での立小便同様、不問に付し、一々大げさに捜査すべきものではなかったのであって、本件は、その実態において、本来は訴追されるに至るような行為ですらなく、大仰に裁判が開かれるに値するまでもない、インターネットの不平不満にすぎない。インターネットのこのようなことを「書いただけで」、ことさら高度な違法性を伴う書き込みでもないようなことにつき、いちいち逮捕されていたら、国民は、犯罪趣旨ではないのに、犯罪形式をとっただけで逮捕されるのでは何も書けなくなるし、憲法21条で保障されている表現の自由が委縮し、重大な弊害を来すと考えられる。

 以上を考慮すると、本件に関しては、捜査機関が、殊更、刑務所に入れて矯正教育実施しなければいかんともしがたいような危険犯を見出し、厳正に処罰すべく捜査を敢行したとは認められないし、2ちゃんねらーなどインターネット書き込み者に刺激されて怒張し、瞬間的に本件のような書き込みをしたにすぎない、本来善良な市民逮捕するという暴走行為をしたと認められるのであって、書き込み自体も、申立人が3のアで主張するとおり、脅迫実体を有していないし、仮にわずかでも何らかの犯意があったにしても、本来捜査機関が大仰に動くに値するほどの重大事案ではない。この点について確定判決は、本件は折りから厚労省事務次官殺害事件が発生しており、それに連続するものであって被害者に与えた恐怖感は多大であって悪質云々と論評するも、確定判決自体が無機質な文章であってしか簡単な短文であり、全体としてナンセンスまりないもので、抽象検討をしたにとどまるものであり、一つの刑事判決として趣味もないし読むに値するようなものでない。

 以上を総合考慮すると、本件に関し、捜査機関が乗りだし、刑事手続きに乗せた上、最終的に懲役2年の刑を言い渡した上、その後執行猶予中に再犯をした場合現実刑務所収容されて強制労働をさせる結果につなげるほど、本件の被告人が重大事案を犯したなどとはとうてい言えないところであって、捜査及び判決自体も全体として刑事手続きとしては全く意味をなしていない形式的かつ悪質でナンセンスまりないものであり、およそ全体として適正な刑事手続き実施されたという価値を具有しない、支離滅裂無意味ものであり、はてなダイアリーおよび2ちゃんねるでの書き込み自体も、本人の性格書き込み当時の社会実態関係、本人がはてな日記2ちゃんねるで遊んでいただけで、凶器も準備しておらず被害者の自宅場所も知らない上で「自宅において順次殺害する」と書いたのも、単に被害者に対する嫌悪の情極まって語勢の強まるところ「自宅において」という文言が付加されたにとどまり確定判決が言うところの厚労省事務次官殺人事件犯人のように、実際に凶器を準備し被害者の自宅を調査して実行行為に及んだ性格の者とは大きく違い、被告人被害者らの自宅に行き実行行為に及べるような人物ではないのであって、その実態関係において脅迫として処罰しなければならない危険性が全くないか、仮にあったにしても極めて微小であり、また、2ちゃんねる書き込みこのエントリーをはてなブックマークに追加ツイートシェア

平成31年(た)第1号再審請求事件 東京地方裁判所

主    文

本件につき再審を開始する。

理    由

1 事案の概要

 本件は、平成20年11月に、インターネットはてなダイアリー等で「文科省局長である金森越哉等を順次自宅で殺害する」云々と書き込んだ件で、申立人が脅迫罪逮捕され、平成21年3月26日に、懲役2年、執行猶予3年の判決を言い渡されたが、本件確定判決については、申立人が述べる諸般の事情から刑訴法435条6号にいう無罪を言い渡すべき新証拠があるので、再審を開始すべきとして、再審請求をしているものである

2 検察官意見

ア 検察官意見聴取したところ、本件は、社会通念上、インターネット電子掲示板掲示された立派な脅迫文言であって、この程度の形式を有する文言記載した以上、被害者が恐怖感を感じるであろうことは犯人は容易に推測がつくものであり、被告人も、取調べで犯行を認めて、公判廷でも反省しており、有罪判決が出る外形的事実は十分に整っている。被害者被害供述をしている調書も整っており、しかも、文言形式から受ける印象は極めて過激で、被害者も、この書き込みにより、著しい恐怖感を覚えたと供述しており、懲役2年を言い渡すに値すると信じられるだけの諸般の外形的なものが揃っている。他面、申立人がいうところの事情は、司法機関には理解できないことであって、捨象すべきである。生々しい刑事司法を展開していた昭和時代であればともかくとしても、平成20年時点での我が国の完成した社会通念からすれば、これだけの形式的なものが揃っている本件に関しては、これを覆すのは困難であり、右形式的な書類等を全て覆すに足りるだけの形式的な証拠を、申立人は何ら提出していない。したがって、形式的に動いている現在刑事司法においては、形式的な書類等は鉄壁犯罪証拠であって、これを虚偽とすることは困難であり、本件再審請求は通らず、棄却さるべきものである

イ 仮に、本件書き込み形式的なもので、実態上は犯罪構成しないとしても、被告人ブログに書き込んだ文章や、2ちゃんねるでの書き込みは、実質において、極めて反国家的であって、文科省教育刑事司法が腐れていると言うなど、関係機関侮辱しているところ甚だしい。したがって、申立人は、脅迫行為を行ったわけではないが、国家に対する諸般の反抗的文章を書き、国家敵対したとして、これを刑事司法私刑に処する意味で、本件を脅迫罪として作り上げ、懲役2年に処しても、平成20年当時の実質法には違反しない。それに、本件に関しては、執行猶予があることが最初から決まっており、申立人は反省形式を整えれば刑務所にいくという致命的なことは免れえたのであるから、今回の刑事処分が、形式的な行為に対して刑罰を下すという残酷行為であるというのは当たらない。

ウ 仮に本件について実質的理由があるとすると、検察においては、本件ブログ記載書き込みは、従前より申立人がブログ2ちゃんねるに書いてきた反国家的な文章投稿による怒りが頂点に達した結果、記載に及んだものであり、その量も膨大であって、脅迫行為として採用するに足りると判断するから実質的な面を見ても、本件を脅迫行為としても何ら問題はないし、懲役2年の刑も相当である

エ 何よりも、現在刑事司法犯罪行為があったかどうかについて、外形的事実からしか判断しないという姿勢は一貫しており、申立人は、本件刑事手続きにおいて揃えられた形式的な証拠を全て覆すだけの形式的な証拠を用意できていないし、現在日本刑事司法実質的正義はないから、仮に申立人が本件再審請求で、実はこうだった、ということを陳述したとしても、裁判所検察は、実質はどうでもよく、形式しか見ないから、本件再審請求が通ることはありえない。

オ よって、本件につき無罪を言い渡す新証拠はないから、本件再審請求棄却すべきである

3 申立人の意見の要旨

申立人が、本件行為脅迫罪に当たらないとする事情は、以下のとおりである

ア そもそも刑法222条が罰するとしている脅迫行為とは、その当時の社会実態被害者心理状態加害者意図狙いなどを総合考慮して、実質的被害者生命財産が損なわれるのではないかという著しい恐怖感を与えるような行為であって、この行為が行われたと認定するためには、犯人にそのような生々しい意図があるということと、犯人がした行為が、被害者をして生命財産が損なわれるのではないかという著しい困惑感を覚えさせる必要がある。この程度に至らない行為は、単なる形式的なもの些末なものであって、いちいち刑法処罰し、まして懲役刑など選択する必要性もないのであって、また、脅迫行為は、必ずしも、日時や場所記載の上、氏名をあげて殺害するといった文言によらずとも、例えば、それ相当の具体的関係を持つ者が、すれ違いざまに何かを呟くなど危害を加える旨の言動をしてそれによって被害者が恐怖を覚えても成立するし、一般には意味が分かりにくいような文字ないし絵、暗号でも、加害者被害者住宅や部屋に、被害者危害を加えられると察知してしまうようなもの差し入れ場合にも成立するし、要するに、脅迫罪の成立は、形式文言記載したこと要件なのではなく、文言記載した場合には、その文言記載したこと加害者に真に生々しい犯意があって、しかも、その文言を閲読した被害者が真に生々しい恐怖感を覚えなければ、実生活上は意味のないものであって一々脅迫罪の成立を見ないし、外形的なものがなくても、当事者間だけで通じるような言動暗号の表示、一定空気を醸成すること等、諸般の無形的な行動があってそれが実質的個人生命財産身体安全を脅かす場合は、特に整った外形が無くても脅迫行為に当たることは言うまでもない。

イ これを本件についてみると、結論から言えば、ブログにおける書き込み自体からは、通常人感覚からして、特に何の恐怖感も感じない。関係証拠などを総合すると、「殺害する」云々の周辺には、大量の記事が書かれてあって、平成20年当時にこのようなブログ文章を書くような者が持論を展開しているようにしかみえないし、「殺害する」云々は、脅迫をする趣旨ではなく、強がっているか、もしくは、面白いからたまたま書いてみただけのようにしか見えず、金森越哉という者に対して、生々しい恐怖感を与えようという意思が感じられない。また、2ちゃんねるに書きなぐっているところの脅迫文言も、便所の落書きスレッドを盛り上げるためのジョークしか見えず、とうてい真剣脅迫行為には見えないし、スレッドを全体としてみると、むしろこのような文言を書き込んだのをいいことに、2ちゃんねらーがこのような形式文言を書いた者を脅迫犯に仕立て上げようとしているようにしかみえない。このようなことをしている2ちゃんねらーは、国家関係者とみられ、この点を見ても、刑事司法形式的に動こうとしているという悪意が執拗に感じ取られ、検察官がいうところの、形式的に脅迫の外形があるから処罰に値するという見解は、極めて悪質である

ウ そもそも平成20年11月時点で、申立人が本件文言を書いたのは、小学校時代学校いじめられていたことを思い出し、その真犯人文科省である抽象的に思念して、文科省HPアクセスして、幹部として氏名が列記されていたページを開いてその氏名をコピーアンドペーストして貼り付けただけか、金森越哉については、具体的な当人を申立人が知っていたわけではなく、たまたまHP局長名が金森氏だったので、文科省というところにいるその名前の者がボスであると思料して、ブログでその名前を出したまでのことで、申立人は金森氏が勤務する霞ヶ関に、当時一度も立ち寄ったり、用事で近づいた形跡もないこと、「自宅で順次殺害する」などと言っただけで、申立人は金森氏その他の自宅場所など知りもせず、殺害に用いる凶器なども何ら準備しておらず、結局は、ブログ文科省等を抽象的に批判するだけで、その中でたまたま気が強くなって、このような文言を書いて恰好をつけてみたにとどまるものであり、申立人は平成20年当時、ひきこもりニートであって交友関係も何もなく、パソコンで自堕落に遊んでいた若者にすぎず、金森氏等本人などとは面会すらしたこともなく、書き込みである文京区本駒込の自宅と、金森氏等が勤務する霞ヶ関までかなりの距離があること、申立人は、結局書いただけであって、これにより被害者が生々しい恐怖感情を覚えるであろうとは思いもしなかったこと、申立人はそもそも東大合格するような大人しくて真面目な人間であり、しか東大法学部の先輩である金森氏に対して、一般世間で行われているような卑劣で生々しい脅迫行為をする性格動機も具備していなかったことを考えると、本件書き込みは、人をして自己生命財産身体が害されるのではないかという生々しい恐怖感を与えるような具体的行為とは認められない。

エ この点について、検察官は、本件は、2008年11月までの過去幾多に渡るブログ2ちゃんねるでの、国家に対する不平不満、批判などがエスカレートし、その怒りが極まった結果としての書き込みであり、その本気度が高いなどといった実質的理由を主張する反面で、起訴した理由形式的なものであり、申立人が刑事処分を受けるべきは、実質的理由もあるが、申立人が調書に署名押印し、公判犯行を認め反省しているといった外形的事実鉄壁のものであって、こちらの理由により本件再審請求は通らないなどという、支離滅裂な主張をしている。

オ これについて検討するに、検察が言う形式理由については、刑法趣旨が、虚構犯罪に対して刑罰を与え場合により刑務所労役をさせるところにあるものでないことは明らかであるから、全く理由がない。また、検察が主張する実質的理由についてであるが、本件は、国家文科省に対する批判文章がかねてより蓄積し、その憎悪クライマックスに達した結果、遂に国家幹部に対して脅迫行為に及ぶに到達したものである、などというが、検察の都合のいい誤信であり、実態に合っていない。

カ 本件の一件記録にある犯罪証拠であるが、これを一瞥しても形式的なものであって何ら生々しい恐怖感を覚えるものではないし、書き込み当時の社会情勢を考えると、なお、本件のような書き込み被害者が真に恐怖を覚えたとは考えられないし、被害供述は虚偽の可能性もある。仮に恐怖を覚えたとしても、平成20年時点での社会情勢を考えて、いまどきこのような形で人を脅迫する者はいいから、書き込み者においては単に形式的にした書き込み社会の中に紛れ込んでこれを閲読した者の内面において恐怖が発生しただけであって、書き込みをした者本人の内心には、かような形式書き込みで、名前の具体の者に対して一般社会実施されているような卑劣で生々しく狡猾な意思をもってその生命身体財産に害を加えんとし、法で処罰するに値するだけの高度に悪質な故意があったとは、本件書き込み者の人生の経緯や性格書き込み当時に置かれていた社会立場被害者との関係総合考慮しても、とうてい認められない。そもそも、申立人は社会的交友がないニートであって、名前を挙げた者と現実具体的な交渉関係を持たないような人間であるばかりか、性格としても男性的なところがほとんどなく女々しい者であって逮捕されるまでには他人と喋ることもできないような引っ込み思案の性格であって、さらに交友関係は一切ないどころか、暴力団関係者とも付き合いがあるわけではなく、まして殺害に用いる凶器など購入もしていないし、当時の状況に鑑みて、名前を挙げた者の自宅を把握しているわけがないのであるから、本件書き込みを実行に移す意思など毫もなかったと考えられ、結局において本件は、社会にありがちの文言で本人が強がりを見せただけの言葉社会内に紛れ、被害者被害を受けると誤信したか、あるいは誤信もせず、ウソであると分かった上で虚偽の被害供述をした可能性が極めて高い。仮に、名前をあげられた東大大学教授女性の者や、女性最高裁判事が恐怖を覚えたと誤信したことは分からないではないが、少なくとも文科省で長年人生経験し、あるいは精神が屈強で本件文言ときに恐怖を覚えるとは思われない東大男性教授等が恐怖を覚えたとはにわかに措信し難いのである。また、一般世間では、より巧妙な手口で、人を脅迫する者が増えていることは、現在実質的社会通念であって、むしろこのような文言を書くことで脅迫する者は、絶滅しているほか、2ちゃんねる電子掲示板ではなく、便所の落書きであることは、一件記録2ちゃんねる書き込みを総覧すれば容易に看取しうるところであって、これを電子掲示板などと見るのは、抽象的観察に過ぎるものがあって是認できない。以上を総合すると、検察官が主張するような、実質的理由、すなわち、本件が、被害者に対し、生々しい恐怖感を与える、生々しい脅迫故意を伴う行為であるから、2年間の懲役に送り込むに値するほどの凶悪行為だ、などという意見は、全くの絵空事であって、無内容にも程があり刑事処分の体をなしていない。検察官は、これが失当であることをあえて知りながら、本件再審請求が通らないのは、一件記録形式的印象から受ける証拠を覆すだけの、テクニカル技術的な証拠を、申立人が何ら提出していないから、再審は通らないという卑劣な主張に力点があるので、以下これについて検討する。

キ 検察官は、警察官調書で犯行を認めて反省し、サインをしており、検面調書でも同様の供述をしてサインして、調書の外形が出来上がっている上に、公判でも、裁判官に対し、反省の弁を述べているのであるから、申立人が犯行を認めたのは間違いなく、右のように書面や反省の弁を揃えた以上は、現在刑事司法では、判断は覆らないのであって、いくら申し開きをしても無駄である、などと考えているが、平成20年警察体制は申立人のような2ちゃんねるで遊んでいた者に対しては形式的で暴力的な態度で取り調べをしており、申立人の主張は一切採用せず、警察検察官は、取調べにおいて、「犯行を認める文章捜査官に作成させること」「サインをすること」の2点をさせれば、「執行猶予は間違いない」もしくは「少なくとも何度も取調べに呼ばれることなく、早く釈放される」などといって被疑者射幸心につけこみ、捜査官が勝手に作文して作っているだけであるのが実態であって、この観点から一件記録の調書をみると、なるほどいかにも捜査官が適当作成した定型文章であって、当時、引っ込み思案で大人しく、日本語もまともにしゃべられない申立人が実際に言ったことをそのまま書いたとは思われないものであって、全く具体性がなく、こんなもの被疑者真意からそのまま供述したと見る方が、不自然である。従って、仮に署名押印のある、犯行を認めたかのような調書であったとしても、全体としては「作らせれば早く出られる

2018-12-09

犯罪をして捕まった場合

 犯罪をして、もし逮捕までこぎつけられると、二段階のいじめがある

(1)初犯

 ア 留置場で丸裸にされ囚人服に着替え

 イ 留置場弁当はそこらへんの脂ぎった仕出し弁当くそまずい

 ウ 留置場ではすることがなく死ぬほど暇で発狂する(先日、某留置場発狂死したやつがいた)

 エ 定期的に取調室に出され、取調官から暴力的取り調べあり、犯行を認めないと何回も呼び出すぞと脅して苦痛を与え

   自分意見は調書に簡単に書いてもらえない、取り調べに逆らうには、ヤクザもんくらいの不屈の精神がいる

   その辺のやつなら呼び出しが嫌すぎたり、調書にサインすると裁判上どうなるかが分からなくて、さっさと出たくて

   犯行を認める文章を書かせてしまサインもしてしま

 オ 押送といい、警察での調べが一段落すると、バンでお迎えが来て、お前含め留置にいるやつ数名が手錠つけられバン

   に揺られて千代田区霞が関にある東京地方検察庁につれていかれる、朝8時出発、9時到着、一日200名ほどの

   被疑者が同行室という部屋の牢屋に入れられ、順次検察官に呼ばれる

   昼食は、食パン3枚とジャムが渡される、それとお湯。便所牢屋内にあり、他のやつの目を気にしつつ、クソ小便

   をすることになる

 カ 検事室では、警察と一緒。閻魔のような奴に、怒鳴られ、犯行を認めるよう脅される。否認すると、連日呼び出し、

   朝9時から17時まで牢屋監禁になるので、嫌すぎて否認を続けるバカはいないし、否認できるのは、よほどの

   知能犯ヤクザのように精神の強いやつだけ

 キ 否認しても、犯行を認めても、ほとんど起訴起訴になると、葛飾区小菅東京拘置所移送される、刑務官から

   チンポの皮を剥け、など、いじめあり、建物はきれいだが、飯は豚のエサ

 ク 裁判所に連れて行かれ、審理が始まる、否認を貫くと、実刑で、もっと恐ろしいことになるが、拘置所必死に考えて

   真人間になり、法廷で、真摯反省しているようなオーラを出すのに成功すると、執行猶予で釈放

 正義とかはない。手続きの体で、以上のような罰ゲームがある、相当きつい、実刑場合は、次に書く

2018-12-04

増田プログラマー養成講座 その23 SQLを巡る物語

前回は、データベース設計について学びました。

今回は、その他のデータベース話題について見てみましょう。

 

 

リレーショナル・データベース理論

問合型言語SQLは、「関係代数」という計算モデルを基に作られたプログラミング言語

一度「関係代数」について学んでおくと、RDBの使い方について、理解が深まる。

↑このスライド作者さんは他にもDB関係資料作成されてるので見ておくといいかも?

 

 

SQL以外の問合型言語

SQL以外にも「SPARQL」、「TMQL」(Topic Maps Query Language)等、いろいろな問合型言語がある。

実際に使う機会は少ないかもしれないが、「問い合わせ」で処理するという発想は参考になるかも?

 

Datalog

Datalogは「Prolog」(論理言語)を源流にもつ宣言的なデータベース問合せ言語。DatalogはSQLと同等の表現力を持つ。

Datalogは様々なプログラミング言語で利用できる。

 

トピックマップ

トピックマップ」は、本の索引もっと機能にしたような仕組みで、RDBとは違う形でデータを蓄積/検索できる。

 

 

RDB以外のデータベース

SQLを使わないデータベースもある。

 

NoSQL

NoSQL一般に "Not only SQL" と解釈される)とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である

関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合操作を利用しないこと(場合によっては単にそのような機能が欠落しているだけ)、水平スケーラビティが確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。

学術的な世界では、この種のデータベースのことを構造ストレージ (structured storage) と呼ぶことが多い。

 

NoSQLデータベースは、関係データベースのような汎用性は欠くものの、その制約された条件下ではRDBMSより高いパフォーマンスを持つ。

そのためビッグデータソリューションでしばしば活用される。

NoSQLデータベース管理システム有用な場面は、関係モデル必要としないデータを扱う時や、大量のデータを扱う時である

 

有名な実装として、GoogleBigTableアマゾンAmazon DynamoDBなどがある。オープンソース実装も数多く存在し、例えばMongoDBRedisApache HBase、HyperTable, Apache Cassandraなどがある。

 

 

SQLRDBに慣れたら、NoSQLも調べてみよう!

 

 

その他、データベース関係話題

DB運用管理で学んでおきたい話題を列挙してみよう。

 

 

SQL開発物語

問合型言語学習最後に、SQLを巡る物語も見てみよう。(SQL学習ドラマチックで楽しいものにしたいねw)

 

 

RDB活用すれば、大量のデータを処理して、多くの仕事効率化できる。(金持ちへの扉が開かれる。)

暇があったら、SQL物語登場人物も見ておこう。

 

エドガーフランク・コッド(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言語を開発した。

 

ラリーエリソンSEQUEL 完成前に発表された論文に基づいて Oracle を完成させ、先に発売している。

IBMは、SQL/DS を発売した。

幹部技術音痴だと、部下の名案も却下してしまうんですね?

 

ローレンス・ジョセフ・エリソン(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日取締役会に出席する時間が充分に取れないことを理由アップル取締役を辞任した。

この人、キャラクター的にはあまりきじゃないけど、行動力はすごいね

コッド博士論文を見て自分RDBを作っちゃった!

Oracleバージョンを「2」から始めて、改良されているように見せかける。~ちょっと詐欺っぽいけど、商売うまい?w

 

 

 

SQLデータベース活用して、素敵なアプリWebサービスを開発してください。

では、これでいったん、増田プログラマー養成講座を終了します。

御清聴いただき、どうもありがとうございました。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラム=データ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミングの練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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 増田プログラマー養成講座 コンテンツ一覧

2018-12-02

外国人技能実習生制度なんか、奴隷制度だから、止めちまえ!

実習生恋愛妊娠禁止 施設側「生産能力が落ちる」:朝日新聞デジタル

https://www.asahi.com/articles/ASLCZ7220LCZUTIL05X.html

これ、外国人向けにそうさせられるということは、当然、権力のない日本人労働者(とくに派遣)に対しても、同じ対応しているということだからな。

日本人外国人かで多少、奴隷の度合いが違うだけで、実質、このような奴隷扱うする会社は、日本人奴隷扱いしている。

人間ロボット代わりに、ロボット以下に扱う企業を全部潰してしまえ! そういう会社は、全部潰れろ!

 

なにも、外国人技能実習生じゃなくても、日本人派遣労働者奴隷度合いが少し緩いだけだ。

大衆向けに使っている、いわゆる”派遣”は奴隷である。それは「派遣」ではない。

悲しいけど、大衆向けに使っている、いわゆる”派遣”は奴隷

なので、何人(なんびと)も”派遣”に手を出してはいけない。

本来の「派遣」は、専門的な何かを持っている人対象であり、そのような人らは、最低限でも年間1,000万円以上の報酬手取り)がある。

何が言いたいかというと、”派遣”の仕事で、手取りで年間1,000万円を切る案件は、「派遣」ではない。

 

まさに、明治時代女工哀史で語られていることは、いまの日本人奴隷派遣)哀史そのものと思えるし、さら人間を買い叩いたバージョン外国人技能実習生奴隷哀史そのものになりつつある。

まっ、千葉県船場市の街なかにいても、これを肌で感じるんだから、全国津々浦々、こんな感じだと思う。

 

この「フリーター漂流ときからすでに10年以上経っているけれども、いまはこのときよりもさらにひどいことになっている。

この”派遣”、奴隷労働を法改正順次経て、法的に認める方向になっている。

フリーター漂流 https://www.nicovideo.jp/watch/sm26120858 via ニコニコ動画

2018-11-20

はてなアイデア

わ!本当にありやがったwww

てかサービス終了してるしwww

 

はてなアイデアとは http://d.hatena.ne.jp/keyword/%A4%CF%A4%C6%A4%CA%A5%A2%A5%A4%A5%C7%A5%A2

はてなのサービスの1つ。

はてなへの要望不具合報告を募集・処理する仮想市場サービスだった。

アイデアに対してポイント株式見立て仮想的に「売り」「買い」する。

1000株に達することを「上場」と呼び、上場したアイデアは、はてな運営によって検討され、「見送り」「他の方法」「実装」など順次処理された。

2012年から運営側は「上場」したアイデアに対して処理を事実上放置するようになった。

2013年7月31日サービスを終了した。

 

はてなはもう面白いサービスを作るフェーズじゃないのかもね?

競合他社がいなければ新参でもチャンスあり!?

2018-11-19

増田プログラマー養成講座 その22 データベース設計 概念物理

前回は、DB設計の(1)要件定義を学びました。

今回は、DB設計の(2)概念設計、(3)論理設計、(4)物理設計を見てみましょう。

 

DB設計の流れ

  1. 要件定義
  2. 概念設計
  3. 論理設計
  4. 物理設計

 

DB設計の教材

データベース解説本やWeb記事を調べてみた。

  1. 本「スッキリわかるSQL入門」 第12章 テーブル設計 https://book.impress.co.jp/books/1111101167
  2. Web記事「できるエンジニアになるためのちょい上DB術」 https://www.edifist.co.jp/lecture/dbdesign/

 

スッキリわかるSQL入門」のDB設計説明コンパクトにまとまっていて、分かりやすいと思いました。(是非一度読んでみてください。)

 

 

 

概念設計論理設計物理設計概要

スッキリわかるSQL入門」第12章の説明(p.374)を参考にしてみよう。(詳しくは本を読んでみてください。)

 

概念設計

管理すべき情報はどのようなものなのかを整理します。

データベースシステムに関することは考えず、要件に登場する情報だけをザックリと把握します。

たとえば、家計簿データベースであれば、扱うべき情報として「利用者情報」や「入出金情報」などがあることを明確にします。

また、情報間で関連がある場合、どのような関係があるかも併せて整理します。

 

論理設計

概念設計で明らかになった各情報について、RDBを使う前提で構造を整理し詳しく具体化していきます

論理設計では「どのようなテーブルを作り、それぞれのテーブルにどのような列を作るか」まで明らかにすれば十分です。

型や制約など、付随的な部分については考えません。

 

物理設計

特定DBMS製品(たとえばMySQL)を使う前提に立ち、論理設計で明らかになった各テーブルについて、その内容を詳しく具体化していきます

すべてのテーブルのすべての列について、型、インデックス、制約、デフォルト値など、テーブル作成必要なすべての要素を確定させます

この物理設計に基づいて、CREATE TABLE文などを含む一連のDDL文を作成し、最終的にデータベース内にテーブル作成することができます

 

本書の「図12-4 データベース構築のおおまかな流れ」も参考にして欲しい。

入力 お客様要件(全国の倉庫商品があって、その在庫管理したいんだけど~)

 

 

●処理 DB設計作業

 ・概念設計:(商品)(在庫)(倉庫) …ER図を作成

 ・論理設計:[商品][在庫][倉庫]    …正規化

 ・物理設計:[SHOHIN][ZAIKO][SOUKO]  …使うDB仕様に合わせてテーブル定義表を作成

 

 

●出力 DDL

 ・CREATE TABLE

 ・CREATE VIEW

 ・CREATE INDEX

 

 

 

(2) 概念設計

 

ER図とは?

ER図とは、「Entity-relationship Diagram」(実体関連図)の省略形だ。

 

ER図の用語

コンピューター用語英語ばっかりだから日本語にして欲しいよねw

 

ER図の書き方
  1. エンティティ―」は四角い箱で書く。
  2. 箱の中にエンティティ―の詳細な中身=「アトリビュート」を書く。
  3. 箱と箱を「リレーション」の線でつなぐ。
  4. 線の両端に「カーディナリティー」「オプショナリティー」の記号を書く。

 

ER図で使う記号は、「IE記法」や「IDEF1X記法」など、いろいろな規格がある。

情報処理技術者試験のデータベーススペシャリストの問題では、「UML」という図の記法も使われる。

 

 

 

(3) 論理設計

 

正規化とは?

正規化 Normalization」とは、データの形を「正規形」(Normal form)に変えること。

ざっくり言うと、テーブル(表)を分割して、データの重複や不整合を解消する作業だ。

 

テーブルの形を変えていくステップには、第1~第5まで5段階ある。

  1. 第1正規
  2. 第2正規
  3. 第3正規
  4. 第4正規
  5. 第5正規

それぞれの変形方法について理解しておこう。

実務では第3正規形まで正規化できればとりあえずOK

 

第3.5正規形(ボイス-コッド正規形)

第3正規形をより厳密にした「ボイス-コッド正規形」という形もある。

第3と第4の間なので「第3.5正規形」とも呼ばれている。

(ボイス-コッド形もカウントに入れたら、第1~第5、+第3.5で計6段階になる。)

 

非正規

正規化を進めると、SQLJOIN」の利用が増えてくる。JOINを多用する処理は遅い=DBの性能低下につながる。

第3正規形まで分割しても、実際に使ってみて遅い場合は、第2正規形や第1正規形に戻して使うこともある。これを「非正規化」とか「正規化を崩す」などという。

 

RDBでは処理速度が遅くなる場合、代わりに「NoSQL」を使う場合もある。

 

 

 

(4) 物理設計

 

時間がない場合、先にGUIDB管理ツールでデータベース作成してしまい、その後でテーブル定義表を作成することもある。

 

DB設計に慣れてきたら上記の各段階はすっ飛ばして、いきなりデータベースを作れるようになるだろう。

 

ここまで、SQLの使い方やデータベース設計について学びました。

次回は、その他のSQLに関連する話も見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-11-16

anond:20181116085135

ものによるが早いと一カ月くらいで増産できるし妊婦子供予測できるだろう。

まあ男性が一斉に押し寄せなければ大丈夫

子供いないと予防接種が珍しいだろうが行政から順次お知らせくるだけだから住民票は忘れずに移してあと大人しく待っとけ

2018-11-15

anond:20181115091014

順次もどってきてくれるかもしれないじゃん~。

2018-11-13

サービス終了のご案内

2019年3月をもって、「おこづかいQUICPay」のサービスを終了いたします。

これに伴う各種サービスも、順次、終了となります

詳細は下をご覧ください。

2018年11月15日(木)終了】

新規申込(MyJCB・入会申込書)の受付

2019年3月31日(日)】

おこづかいQUICPayサービス終了

https://www.jcb.co.jp/ordercard/add/quicpay/apply-cardmembers/children/index.html

5年でサービス終了

利用者が少なかったんやろなぁ

2018-11-11

増田プログラマー養成講座 その21 データベース設計 (1)要件定義

前回まで、データベースを使ったWebアプリ作成して、SQLの使い方を学びました。

今回からデータベース設計について学んでみよう。

 

参考書

これらの参考書ガッツリ読めば、データベース設計のやり方は分かる。

 

リレーショナル・データベースは昔からある枯れた(=安定した)技術なので、鉄板ノウハウが蓄積されている。

先人の知恵に沿って使うなら、データベース設計で悩む余地は少ない。=攻略は意外と簡単

 

データベーススペシャリスト教科書

経済産業省認定情報処理技術者試験で「データベーススペシャリスト」という資格もある。

 

データベースエンジニア」という肩書きを名乗れば、ただのプログラマーよりも高給取りになれる。勉強した後、自分知識棚卸してみるつもりで資格を取ってみるのもいいだろう。

データベーススペシャリスト試験教科書には、浅く広くDB知識網羅されているので、1度眺めてみたらいいかも。

 

 

 

データベース設計の流れ

データベース設計(database design)は、ソフトウェア開発工程においてデータベースの詳細なデータモデルを作る工程である

 

  1. 要件定義:「CRUD表」の作成
  2. 概念設計:「概念モデル」の作成 → ER図(実体参照モデル)の作成
  3. 論理設計:「論理モデル」の作成 → テーブル定義表の作成
  4. 物理設計:「物理モデル」の作成 → 論理モデルを実際にデータベース上で作成インデックス作成など

(分類方法にもよるけど)データベース設計は、このようなステップを経る。それでは順番に見ていこう。

 

 

 

1.1 永続化するデータを決定する

いわゆる「要件定義」だ。

実際にシステムを使うことになるユーザーヒアリング調査して、データベース内に永続化(格納)すべきデータを決定する。

 

CRUD表とは?

データCRUD操作(Create 追加、Read 参照、Update 更新Delete 削除)が、いつ、どこで発生するか?をまとめた表のこと。

 

データベース 設計 CRUD表」等のキーワードGoogle画像検索してみよう。どんな表か分かる。

↑このページの「図2 標準的CRUD図(例)」みたいな表を作って確認すれば、扱うデータの過不足がなくなる。

 

複雑なシステムだと、完全なCRUD表を作るのは面倒だよねw

だが安心して欲しい!

押さえておくべきポイントはあるので、そこだけ手抜きをしなければ、大失敗は避けられるだろう。

 

マスタートランザクションの違い

実は、後でテーブルを作るときに、データ更新頻度によって2種類に分類できるんだ。

 

 

トランザクションデータの扱いは、気を付けないとデータベースの性能低下に直結する。

どっちのタイプデータなのか?要件定義の段階から見分ける癖を付けておこう。

 

要件定義練習

試しに、Amazonのような通販サイトなら、どんなデータを扱うことになるのか?想像してみよう。

仕入先、在庫数、受発注配送会社顧客情報商品カテゴリー、商品スペック、などいろいろあるだろう。

いつどこでCRUDが発生するか?どれがマスターデータで、どれがトランザクションデータだろうか?

 

 

 

(ここまでの説明URLを8個も貼ってしまったので、続きは次回にしよう。)

次回は「概念設計」以降のステップを見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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:20181024214737 増田プログラマー養成講座 コンテンツ一覧

はてブって意味不明コメントが人気1位になり過ぎで怖い

khwarizmi こういうのを見るに,高度成長期日本の成長というのは今のアメリカみたいにアジア周辺国の才能を吸い取って成し遂げられていたものなのだなあと思う。平成になって減速したのは当然なんだろう。 社会 経済 10 clicks

2018/11/11 リンク Add Stargabilljakuonnowa_sdy0kangirenmillipedeyarimokuIridiumenemyoffreedomsizukanayorugrdgsBenjaminWyattakiramazbulletko_kanagawasenbuuregicat

http://b.hatena.ne.jp/entry/s/gendai.ismedia.jp/articles/-/58365


なんで日清の百福さんの1例からここまで言えるのか。

高度成長期アジア周辺国から吸い取られた才能」って具体的に何?

安藤百福さん自体は立派な人だけど、なんで彼がこんな滅茶苦茶な日本disに使われるのかわからない。


アメリカみたいに」って、世界一移民国家と比べますか?

高度成長期日本にいたのは百福さんみたいな居残り台湾人

朝鮮戦争とき祖国捨てて順次逃げてきた南北コリアン人ぐらいですよ。

高度成長は日本人の頑張りではなくて、そのアジア人達の才能が原動力だったと?

どういう根拠

割合的にもわずかな(そしていいたくないけど無職ヤクザもんも多かった)人達の才能が日本の成長を成し遂げたと?

日本人なんかは貢献してないんだと?


意味不明すぎるしぶっちゃけ日本人に対する感情的な難癖ヘイトに思えるんだけど

「そうじゃなくてちゃん合理的説明出来る事実なんだ」って反論あるの?


しかもその理屈なら日本に在住する外国人は増える一方なんだから

平成になって減速するのは当然」っていうのは自分理論的にもおかしくない?

どれぐらいまともに思考した上で書いてるのこれ?


☆つけてる人達でもいいけど合理的説明が出来るなら是非書いてほしい。

絶対誰も説明出来ずにだんまりでしょ。

日本ヘイト出来て嬉しい!事実性なんて知ったことか!」ってノリで☆つけただけだから

2018-11-10

増田プログラマー養成講座 その20 SQLデータの削除

前回は、SQLデータ更新をやりました。

今回は、SQLデータの削除をやりましょう。

 

メッセージの削除

基本は、同じなので前回やった更新処理をちょっと変えれば削除もすぐできます

 

投稿されたメッセージを削除する機能を、Webページに付けてみよう。

 

削除ページにジャンプするリンク

前々回作ったメッセージの一覧の中に、削除ページにジャンプするリンクも入れておいた。

<td><a href="welcome/delete/<?php echo $item['id']; ?>">削除</a></td>

という1行が削除ページにジャンプするためのリンクになる。

ブラウザーHTMLソースを見ると、ここが以下のようなHTMLに書き換わってる。

<td><a href="welcome/delete/2">削除</a></td>

これは「メッセージID番号が2のメッセージ」を削除対象にして、削除ページにジャンプする。

 

Controllerの改造

ユーザーが「http://localhost/waf/welcome/delete/2」というURLで、削除ページにアクセスしたら、コントローラーで「2」を受け取って使いたい。

CodeIgniterでは、URL文字列を解析して、使うことができる。

以下のようにコントローラーを改造してみよう。

 

// 削除画面

public function delete($id = '')

{

 echo "ID=".$id;

 $this->load->view('chat_delete');

}

 

Controllerの改造の解説

delete()メソッド引数で、URL中の「2」の部分を受け取れる。

これは前回の編集ページ(更新の処理)と同じ。

「$id = $this->uri->segment(3);」でも受け取れる。

 

Viewの改造

削除ページでは、確認する質問を入れてみよう。

ユーザーに「本当に削除しますか?」みたいな注意喚起をしておきたい。

 

ファイルの内容を以下のように編集する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

  <base href="<?php echo base_url(); ?>">

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>削除</h2>

  <p>以下のメッセージを削除しますか?</p>

  <form action="welcome/delete" method="post" accept-charset="utf-8">

   <?php if (isset($talk)): ?>

   <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>

 

Viewの改造の解説

<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番号を仕込んでおく。

 

Controllerの改造

ファイルの内容を以下のように編集する。

// 削除画面

public function delete($id = '')

{

 $id = $id ? $id : $this->input->post('id');

 $action = $this->input->post('action');

 if ($action == 'delete') {

  $this->chat_model->delete_message($id);

 }

 $data['talk'] = $this->chat_model->read_message_by_id($id);

 $this->load->view('chat_delete', $data);

}

 

Controllerの改造の解説

やってることは、前回のデータ更新場合とほぼ同じ。

$this->chat_model->delete_message($id);

で、モデルに用意したデータ削除用メソッドを呼び出しているだけ。

次は、モデルdelete_message()メソッドを用意しよう。

 

Modelの改造

ファイルの内容を以下のように編集する。

// 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();

}

 

Modelの改造の解説

SQLの「DELETE」を使えば、指定したレコード(1件分のデータ)を削除できる。

DELETE FROM talk WHERE id = ?」で、talkテーブルmessageid指定して削除している。

 

データを削除した後の挙動は、メッセージID番号がなくなるので、削除ページに表示できるメッセージデータがなくなる。

(例)id=2のデータを削除したら、SQLで「SELECT * FROM talk WHERE id = 2」を取得しても、空のデータデータがない状態

その場合は、

<p>※該当するメッセージがありません。(または削除済です。)</p>

と表示させてる。

 

まとめ

以上で、SQLの「DELETE」を使ったデータの削除ができた。

長々と説明したが、今回の大事な点は、SQLの「DELETE」の使い方だ。

 

以上で、MVCフレームワークを使ったOOPの使い方とSQLの使い方を見てきた。

SQLSQLだけで説明したほうが良かったね!MVCフレームワーク説明SQL説明が混在すると要点が分かりづらくなる?)

ちょっと失敗だったかも。m(__)m)

 

次回は、データベースの設計について学んでみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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:20181024214737 増田プログラマー養成講座 コンテンツ一覧

増田プログラマー養成講座 その19 SQLデータ更新

前回は、Webアプリの骨組み(スケルトン)に、SQLデータの追加と取得をやりました。

今回は、SQLデータ更新をやりましょう。

 

メッセージ更新

 

編集ページにジャンプするリンク

前回作ったメッセージ一覧に、[編集]のリンクも入れておいた。

<td><a href="welcome/update/<?php echo $item['id']; ?>">編集</a></td>

という1行の部分。

[編集]をクリックすると、編集用ページにジャンプする。

ブラウザーHTMLソースを見ると、以下のようなHTMLになってるはず。

<td><a href="welcome/update/2">編集</a></td>

これは「メッセージID番号が2」を対象にして、編集ページにジャンプすることを意味する。

 

Controllerの改造

編集用ページのコントローラーを作ろう。

「http://localhost/waf/welcome/update/2」というURL編集ページにアクセスしたら、メッセージID番号の「2」を受け取れるようにしたい。

URL文字列を処理して「2」を取り出せるようにしよう。

 

// 更新画面

public function update($id = '')

{

 echo "ID=".$id;

 $this->load->view('chat_update');

}

 

CodeIgniterでは、URLから文字列を取り出す方法がいくつか用意されている。

  1. 「update($id = '')」のようにメソッド引数「$id」を用意すれば、「2」の部分を取り出せる。
  2. 引数を使う以外の方法も用意されていて、「$id = $this->uri->segment(3);」のように書けば、「2」の部分を取り出せる。

// 更新画面

public function update()

{

 $id = $this->uri->segment(3);

 echo "<hr> ID=".$id;

 $this->load->view('chat_update');

}

 

Controllerの改造の解説

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()メソッドで順番を指定すれば取得できる。

 

Modelの改造

データベースでメッセージID指定して、メッセージを取り出す機能を用意しよう。

 

ファイルに以下のメソッドを追加する。

// Read by 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();

}

 

Modelの改造の解説

SQLの「WHERE」句で、絞り込む条件を指定できる。

 

SELECT * FROM talk WHERE id = ?

「WHERE id = 2」とすれば、メッセージID番号が2のメッセージデータが「talkテーブルから取り出せる。

もし該当するデータがなければ、返されるデータは空になる。(データが返ってこない。)

 

CodeIgniterの「row_array()」は、1件分のデータ配列の形にして返すメソッドだ。

 

Viewの改造

ファイルの内容を以下のように編集する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

  <base href="<?php echo base_url(); ?>">

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>編集</h2>

  <p>メッセージを変更して「更新する」ボタンを押してください。</p>

  <form action="welcome/update" method="post" accept-charset="utf-8">

   <label>メッセージ</label>

   <?php if (isset($talk)): ?>

   <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>

 

Viewの改造の解説

データベースから取り出した1件分のメッセージを表示する部分を追加した。

<input type="text" name="message" value="<?php echo $talk['message']; ?>">

の「<?php echo $talk['message']; ?>」という部分だ。

これで変更したいメッセージの本文を表示できる。

 

あと、編集したメッセージWebサーバーに送信できるように、Formタグ送信ボタン(「更新する」の部分)も追加した。

このときメッセージID番号も送信できるように、

<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">

という1行も仕込んである

 

Controllerの改造

ファイルの内容を以下のように編集する。

// 更新画面

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);

}

 

Controllerの改造の解説

メッセージID番号を指定して、データベースから取り出し、Viewに渡すデータを用意している。

$data['talk'] = $this->chat_model->read_message_by_id($id);

 

ユーザーメッセージ編集をして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()メソッドを用意しよう。

 

Modelの改造

ファイルの内容を以下のように編集する。

// 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();

}

 

Modelの改造の解説

SQLの「UPDATE」を使えば、指定したレコード(1件分のデータ)を更新できる。

「UPDATE talk SET message = ? WHERE id = ?」で、talkテーブルmessageid指定して更新している。

 

CodeIgniterの「affected_rows()」メソッドは、更新した行数を返す。=成功なら1行、失敗なら0行となる。

 

補足

コントローラーの「$id = $id ? $id : $this->input->post('id');」という行は、$idの受け取り方が2パターンあるので、それに対応している。

編集ページの表示で、1回目の表示と、2回目以降の表示で、$idの受け渡し方が変わっている。

  • 1回目:URLに埋め込まれID番号をupdate($id = '')の引数$idで受け取っている。($this->uri->segment(3)で受け取るのと同じ)
  • 2回目以降:Formタグで送られてきた$idを$this->input->post('id')で受け取っている。

URLに埋め込む方法上記の1回目のような方法)は、ユーザー勝手に値をいじれるので、基本的には使わない方が良い。

 

まとめ

以上で、SQLの「UPDATE」を使った、データ更新ができた。

長々と説明したが、今回の大事な点は、SQLの「UPDATE」の使い方だ。

CodeIgniterの使い方や、Webサイトの作り方(FormタグなどのHTML知識)は、オマケ程度に見ておいて欲しい。

 

次回は、データを削除するSQLDELETE」の使い方を見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-11-08

anond:20181108174005

amazonでは剥き出し流木などのアマゾン倉庫を経由できない商材は扱っていない(はず)

amazon倉庫では例外なくアマゾンロボが自動的商品棚を動かしている

まではいいとして、その先に人間がまだいる理由

アマゾンがその部門をまだ自動化できていない」だけで「アマゾン自動化できない」とかそういう話ではない。

単に機械リソースが足りてないとかそういう糞低レベルな話であって、これもヘタしたら2,3年のうちに順次アマゾン人間排除されてアマゾンの地で暮らすようになって結果ライダーへと変貌を遂げる可能だってある。

今は正にその「梱包人間」を挙って機械化するシーケンス上にあり、中国での倉庫業界では割とフル自動化を達成しているケースもあるって事だろうよ。

逆に言うと、amazonの規模が倉庫完全自動化になったらもう既にその辺の話は終わってるよw

2018-11-04

増田プログラマー養成講座 その17 Webアプリの骨組み

前回は、Webアプリの完成見本を先に見てみました。

今回は、Webアプリを作る途中の過程を見て、作る雰囲気を一緒に味わってみましょう。

 

フレームワーク使用ルール=「設定より規約」=手抜きをする仕組み

最近フレームワークは、「設定より規約」(CoC、convention over configuration)という発想で作られている。

フレームワーク規約使用ルール)に従うと、プログラマー作業量が減って、楽ができる。

 

設定より規約(convention over configuration)とは、開発者の決定すべきことを減少させ、単純にするが柔軟性は失わせないというソフトウェア設計パラダイム

使用しているツール実装した規約開発者の望む動作と一致していれば、設定ファイルを書く必要もない。実装規約と望みの動作が違っている場合必要動作を設定しなければならない。

 

最近フレームワークは「設定より規約アプローチ採用しているものが多い。

例えば、Ruby on Rails、Kohana、Grails、GrokZend FrameworkCakePHPSymfony などがある。

 

CodeIgniter使用ルール

CodeIgniter使用ルールは、マニュアルチュートリアル確認できる。

↑このページの「アプリケーションフローチャート」を見てみよう。

 

  1. 一番左の「index.php」が、Webアプリ入口になっている。(エントリーポイントフロントコントローラーパターン等ともいう)
  2. から2番目の上段「Routing」で、URLに応じて、仕事の振り分け先を決定する。(ディスパッチ、マッピングルーティング等ともいう)
  3. から4番目の「Application Controller」で、具体的な処理の指示を出す。
    1. Application Controllerは、「Model」に必要データを用意させる。
    2. Application Controllerは、「View」に表示用の画面を作らせる。
    3. Application Controllerが、index.phpに表示用の画面を渡す。
  4. 表示用の画面(最終的な処理の結果)を受け取った「index.php」は、ユーザーブラウザー)に画面を渡す。

 

 


 

それでは、CodeIgniterプログラマーが用意する部分のM(Model)とV(View)とC(Application Controller)を、骨組みから作ってみよう。

事前準備として、前々回と前回のWebアプリ完成見本を用意するところまでやっておこう。

 

スケルトンとは?

スケルトン(skeleton, 骨格)とは動物人間の骨格。

コンピュータプログラムコードの骨格部分。プログラムコード作成では、初期段階でスケルトン作成し、その後で詳細部分を肉付けしていく。

 

 

 

Application Controllerの骨組み

まずは、MVCのCの骨組みを作ろう。

Controllerは、ユーザーからリクエストを受け付けて、ModelViewに指示を出す監督です。

 

上記フォルダの中に「Welcome.php」というファイルを作る。(デフォルトであるはずなので、それを使ってOK

 

CodeIgniterルールで、Application Controllerを置く場所は「application/controllers」というフォルダになっている。

CodeIgniterルールで、一番最初に呼び出されるApplication Controllerは「Welcome.php」というファイルになっている。

→これは「C:\xampp\htdocs\waf\application\config\routes.php」という設定ファイルで決められている。

$route['default_controller'] = 'welcome'; // 別の名前にすれば変えられる。

 

「Welcome.php」の中身を以下にように変更する。

<?php

defined('BASEPATH') or exit('No direct script access allowed');

 

class Welcome extends CI_Controller

{

 // 初期画面

 public function index()

 {

  echo "Here is index()";

 }

 // 更新画面

 public function update()

 {

  echo "Here is update()";

 }

 // 削除画面

 public function delete()

 {

  echo "Here is delete()";

 }

}

これがチャットApplication Controllerとして動作する最小限の内容=骨格だ。

 

継承

class Welcome extends CI_Controller

という行に注目してみよう。

CodeIgniterで用意されてる「CI_Controller」クラス継承して、プログラマーが「Welcome」クラスを作ってる。

継承によって、フレームワークが用意してる様々な機能をWelcomeクラス内で使えるようになる。

 

URLリクエスト)とControllerの対応マッピング)のルール

「Welcome」クラスの中に、「index()」「update()」「delete()」という3つのメソッドを用意した。

CodeIgniterURLは、Action Controllerのクラス名やメソッド名とひもづけられている。

今回作るWebアプリだと、

「http://localhost/waf/クラス名/メソッド名」

という対応関係になっている。

(例)

http://localhost/waf/        →Welcomeクラスindex()メソッドが呼び出される。

http://localhost/waf/welcome/index  →Welcomeクラスindex()メソッドが呼び出される。

http://localhost/waf/welcome/update →Welcomeクラスのupdate()メソッドが呼び出される。

http://localhost/waf/welcome/delete →Welcomeクラスdelete()メソッドが呼び出される。

 

 

 

Viewの骨組み

次にMVCのVの骨組みを作ろう。

ビューは、表示する画面の部分です。HTMLWebページの構造を書きます

 

 

welcome_index.php編集

以下の内容にして保存する。

<?php defined('BASEPATH') OR exit('No direct script access allowed'); ?>

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

  <base href="<?php echo base_url(); ?>">

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>新規投稿</h2>

 </body>

</html>

 

chat_update.php編集

以下の内容にして保存する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

  <base href="<?php echo base_url(); ?>">

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>編集</h2>

 </body>

</html>

 

chat_delete.php編集

以下の内容にして保存する。

<?php defined('BASEPATH') or exit('No direct script access allowed');?>

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

  <base href="<?php echo base_url(); ?>">

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>削除</h2>

 </body>

</html>

 

Viewファイルの追加に合わせて、Controllerも一部変更します。

 

Welcome.php編集

<?php

defined('BASEPATH') or exit('No direct script access allowed');

 

class Welcome extends CI_Controller

{

 public function __construct()

 {

  parent::__construct();

  $this->load->helper('url');

 }

 

 // 初期画面

 public function index()

 {

  $this->load->view('welcome_index');

 }

 

 // 更新画面

 public function update()

 {

  $this->load->view('chat_update');

 }

 

 // 削除画面

 public function delete()

 {

  $this->load->view('chat_delete');

 }

}

 

(変更点の説明

コンストラクターの追加

コンストラクター「__construct()」は、クラスからインスタンスが作られるとき自動的に実行されるメソッドだ。コンストラクターは、初期化最初にやっておくべき下準備を書いておく。

$this->load->helper('url');

CodeIgniterには、リンクの表示を補助する「URLヘルパー」という機能が用意されている。

上記のように書くとURLヘルパーを呼び出して、使えるようになる。

Viewファイルの以下の行でURLヘルパーを使っている。=「base_url()」という関数URLヘルパーの1つ。

<base href="<?php echo base_url(); ?>">

 

ビュー読み込みメソッドの追加

$this->load->view('welcome_index');

というメソッドによって、Viewファイルの「welcome_index.php」を呼び出し、画面を出力します。

 

これでMVCのCとVの骨組みができた。

今の段階でWebブラウザーで各ページを表示させると、各Viewファイルの中身が表示される。

 

 

 

Modelの骨組み

次にMVCのMの骨組みを作ろう。

モデルは、具体的な処理内容(ロジック)を書いて、データを読み書きする部分です。

データベースを操作するSQL文もモデルに書きます

 

上記フォルダの中に「Chat_model.php」というファイルを作り、以下の内容にして保存する。

<?php

defined('BASEPATH') or exit('No direct script access allowed');

 

class Chat_model extends CI_Model

{

 public function __construct()

 {

  parent::__construct();

  $this->load->database();

 }

}

 

CodeIgniterで用意されてる「CI_Modelクラス継承して、プログラマーが「Chat_modelクラスを作ってる。

「Chat_modelクラスコンストラクターには、以下のように書いている。

$this->load->database();

これは、データベースを使用する準備だ。

 

Modelの追加に合わせて、さらにControllerも一部変更します。

 

Welcome.php編集

<?php

defined('BASEPATH') or exit('No direct script access allowed');

 

class Welcome extends CI_Controller

{

 public function __construct()

 {

  parent::__construct();

  $this->load->model('chat_model');

  $this->load->helper('url');

 }

 

 // 初期画面

 public function index()

 {

  $this->load->view('welcome_index');

 }

 

 // 更新画面

 public function update()

 {

  $this->load->view('chat_update');

 }

 

 // 削除画面

 public function delete()

 {

  $this->load->view('chat_delete');

 }

}

 

コンストラクター

$this->load->model('chat_model');

と書いて、「Chat_model」というモデルを読み込むようにした。

これで、モデルに用意するいろんな機能コントローラーで使えるようになる。

 

 

 

以上で、MVCの骨組み(スケルトン)だけを作成するプロセスを見ていきました。

まだ中身はスカスカで、何も機能がついてませんね。

次回は、データベースのCRUD操作を行なって、チャットメッセージを追加/取得/変更/削除する機能実装してみましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-11-01

増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本」の続きです。

 

index.php編集

Webサーバーの時間設定がズレていると、メッセージ作成したときに、作成日時もズレてしまます

(=12時に投稿したメッセージが、3時に投稿したことになってしまう、等。)

時間がズレてた場合は、Webサーバーの時刻を一時的に変更する処理を追加しておきましょう。

 

index.phpファイルの先頭に以下の内容を追加します。

上記フォルダの中の「index.phpファイルを開いて、先頭付近(2行目辺り)に以下の内容を追加します。

<?php

date_default_timezone_set('Asia/Tokyo'); // 2行目あたりに追加

 

動作確認

以上で、簡易チャットWebアプリが設置できました。

ブラウザーアクセスして、動作確認してみましょう。

 

 

以上で、データベースを利用したWebアプリが用意できました。

コピー作成しただけでは、プログラム意味が分からないと思うので、次回以降プログラムの部分を解説してみます

次回は、

を見ていきましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 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:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-31

重要フィーチャーフォン向け楽天Edyアプリ新規ダウンロード・初期設定(新規発行)の終了のご案内

フィーチャーフォン向け楽天Edyアプリ新規ダウンロードおよび初期設定(新規発行)を2018年10月31日より順次終了とさせていただきます

対象機種、新規ダウンロードおよび初期設定(新規発行)の停止予定日等の詳細は下記をご確認ください。

https://edy.rakuten.co.jp/info/2018/0801_maintenance/

新規ダウンロードおよび初期設定(新規発行)の停止予定日>

NTTドコモ2018年10月31日予定

KDDIau) :2018年10月31日予定(初期設定(新規発行)の停止。※新規ダウンロードは既に終了しております。)

SoftBank2019年1月31日予定

※既にご利用中のお客様は、引き続き楽天Edyサービスをご利用可能です。

あと30分!

増田プログラマー養成講座 その14 Webアプリの試作品作成

前回は、SQL文法を学びました。

今回は、データベースを使ったWebアプリ制作を通じて、SQLの使い方を確認してみましょう。

 

Webアプリとは?

WebブラウザーGoogle Chromeなど)で動作するアプリのこと。

ウェブアプリケーションWeb application)は、インターネット(もしくはイントラネット)などのネットワークを介して使用するアプリケーションソフトウェアである

多くの場合、これらのアプリケーションは、Webブラウザ上で動作するプログラミング言語(たとえばJavaScript)によるプログラムWebサーバ側のプログラム協調することによって動作し、ユーザはそれをWebブラウザ上で使用する。

 

準備

Windowsパソコンを使ってたら、「XAMPP」を使ってすぐにWebアプリを試作できる。

以前の講座(その6、その9)を参考にして、XAMPPCodeIgniterを用意しておこう。

 

Webアプリ制作の流れ

最近アプリの作り方は、「デザインスプリント」と呼ばれる方法流行ってます。本やネット情報がたくさんあるので調べてみよう。

 

ざっくりと、以下のような流れです。

  1. アイデア企画)を出す。
  2. アイデアを基に、ペーパープロトタイプ(紙の試作品)を作る。=アナログの試作品ノートなどにアプリの完成予想図、画面などを描く。
  3. ペーパープロトタイプを基に、動くモック(ハリボテ)を作る。=デジタルの試作品
  4. モック画面を基に、実際のプログラム作成して、アプリを完成させる。
  5. 完成したアプリを改良していく。

それでは順番にやってみよう。

 

アイデア

以前にデータベース練習をしたとき、「後で簡単チャット(おしゃべり)ができるWebアプリ作ってみたいと思う。」と言ったので、今回のアイデアは「チャットを作る」にしよう。

 

ペーパープロトタイプ

チャット必要な画面は3つある。

  1. トップページの画面(新規投稿投稿一覧がある)
  2. 投稿更新する画面
  3. 投稿を削除する画面

ノートなどに描いて画面をデザインしてみよう。

 

モック

Webページを作るには、HTMLCSS知識必要だ。HTMLCSSを使ったことがなければ、本やネット情報勉強してみよう。

今回はCSSを使わずに、HTMLだけでシンプルWebページを作ってみよう。(練習から余計なもの無駄を省きたい。)

 

Webページ制作ツール

ブラウザーテキストエディター(またはIDE)が必要です。

特にこだわりがなければ、Microsoftの「Visual Studio Code」という無料IDE統合開発環境)を使ってみよう。

インストール方法や使い方、メニュー日本語化のやり方は、検索して調べてみよう。

 

フォルダを作る。

デスクトップに「mock」というフォルダを作る。

 

ファイルを作る。

「mock」フォルダの中に

  1. index.html」 (トップページの画面)
  2. 「edit.html」 (投稿更新する画面)
  3. delete.html」(投稿を削除する画面)

という3つのファイルを作る。

テキストエディターで保存するとき文字コードを「UTF-8」にしておく。

 

ファイルの中身を編集する。

index.htmlファイルエディターやIDEで開き、以下のような内容に編集して保存します。(コピペする場合、行頭の字下げ(インデント)の全角スペースを半角スペースに置換して下さい。)

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>新規投稿</h2>

  <form>

   <label>メッセージ</label>

   <input type="text" name="message">

   <button>投稿する</button>

  </form>

  <h2>投稿一覧</h2>

  <table border="1" cellpadding="5" cellspacing="0" bordercolor="#CCCCFF">

   <tr>

    <th>No.</th>

    <th>投稿日時</th>

    <th>メッセージ</th>

    <th>編集</th>

    <th>削除</th>

   </tr>

   <tr>

    <td>3</td>

    <td>2018-10-20 12:34:56</td>

    <td>Webアプリを作ってみる!</td>

    <td><a href="edit.html">編集</a></td>

    <td><a href="delete.html">削除</a></td>

   </tr>

   <tr>

    <td>2</td>

    <td>2018-09-10 22:33:44</td>

    <td>今日からプログラミングを勉強します。</td>

    <td>編集</td>

    <td>削除</td>

   </tr>

   <tr>

    <td>1</td>

    <td>2018-08-01 11:22:33</td>

    <td>こんにちは!</td>

    <td>編集</td>

    <td>削除</td>

   </tr>

  </table>

 </body>

</html>

 

「edit.htmlファイルエディターやIDEで開き、以下のような内容に編集して保存します。(コピペする場合、行頭の字下げ(インデント)の全角スペースを半角スペースに置換して下さい。)

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>編集</h2>

  <p>メッセージを変更して「更新する」ボタンを押してください。</p>

  <form>

   <label>メッセージ</label>

   <input type="text" name="message" value="Webアプリを作ってみる!">

   <button>更新する</button>

  </form>

  <p><a href="index.html">戻る</a></p>

 </body>

</html>

 

delete.htmlファイルエディターやIDEで開き、以下のような内容に編集して保存します。(コピペする場合、行頭の字下げ(インデント)の全角スペースを半角スペースに置換して下さい。)

<!DOCTYPE html>

<html>

 <head>

  <meta charset="utf-8">

  <title>増田チャット</title>

 </head>

 <body>

  <h1>増田チャット</h1>

  <h2>削除</h2>

  <p>以下のメッセージを削除しますか?</p>

  <form>

   <p style="background-color:lightpink">Webアプリを作ってみる!</p>

   <button>削除する</button>

  </form>

  <p><a href="index.html">戻る</a></p>

 </body>

</html>

 

以上でモックWebページ(HTMLファイル)ができました。

Webブラウザーで「index.html」を開いてください。「編集」や「削除」、「戻る」をクリックして、チャットの画面を確認してください。

 

モックを作ってからWebサイトを作る方法

実務では「仕様書」という書類を大量に作る場合もありますが、時間と労力の無駄になっている場合が多々あります。(紙の仕様書はあまり使われる機会がない)

紙の仕様書アナログ)の代わりに、モック仕様書デジタル)として使うと、その後の段階がスムーズになります

どうしても紙でなければ困る場合以外は、モックをそのまま仕様書として使ってみましょう。

 

プロトタイプ作成ツール

モック(動くハリボテ)を作るための便利なツールがいろいろあります

 

 

 

ちょっと長くなったので、モックを基に機能実装プログラミング)するのは次回にしましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミングの練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成 ←★今ここ★

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-28

増田プログラマー養成講座 その13 SQL文法

前回は、データベース参考書を見た。

今回は、DBで使うプログラム言語SQL」の文法を見てみよう。

 

リレーショナル・データベース(Relational Database、RDB)とは?

WikipediaRDB説明を見てみよう。

関係データベース(relational database)は関係モデルにもとづいて設計、開発されるデータベースである

関係データベース管理するデータベース管理システム (DBMS) を関係データベース管理システム (RDBMS) と呼ぶ。

Oracle Database、Microsoft SQL Server、MySQLPostgreSQLDB2、FileMakerH2 Database などがRDBMSである

 

関係モデルIBMエドガー・F・コッドによって考案された現在もっとも広く用いられているデータモデルである

データベース利用者は、クエリ(問い掛け)をデータベースに与え、データ検索したり、変更することができる。

 

データは表に似た構造管理されるが、関係と呼ぶ概念モデル化される。

関係は組(タプル、表における行に相当する)、属性アトリビュート、表における列に相当する)、定義域(ドメイン)、候補キー(主キー)、外部キーなどによって構成される。

SQLなどに代表されるデータベース言語(問い合わせ言語)を用いて、関係に対して制限・射影・結合・和・差・交わりなどの関係代数演算(集合演算を含む)ないし関係論理演算を行うことで結果を取り出す。

関係複数持つことも可能で、互いを関連させることも可能である

要するに、

 

SQLとは?

WikipediaSQL説明も見てみよう。

SQLエスキューエル)は、関係データベース管理システム (RDBMS) において、データ操作定義を行うためのデータベース言語(問い合わせ言語)、ドメイン固有言語である

エドガー・F・コッドによって考案された関係データベース関係モデルにおける演算体系である関係代数関係論理関係計算)にある程度基づいている。

 

SQLは、シークェルと読まれることもある。

これは、SQLの元となったデータベース言語が、IBMが開発したRDBMSの実験実装であるSystem Rの操作言語SEQUEL (Structured English Query Language)」であったことが由来である

SEQUEL (Structured English Query Language)」を略して「SQL」と呼んだらしい。

 

  1. 質問する、尋ねる
  2. 問い合わせ[クエリー]を行う

英語クエリーは、質問する、問い合わせる、という意味なんだね。

 

SQL3分

SQL説明するとき、3つのグループに分類される。

 

↑このページをよく読んでくれ。理解できたらSQL説明は終わりだ!!!

 

 

 

…というと、説明することがなくなるので、ちょっとまとめておこう。

このページの「表1●SQLDDLDML,DCLの三つに大別できる。このうちプログラマが最も多く使うのはDMLだ」という図を見てみよう。

 

という3種類に分けてる。順番に見てみよう。

 

DDL(Data Definition Language:データ定義言語

データベーステーブル、ビュー、インデックスユーザーなどを作成/変更/削除するときに使うSQL

これでデータベースを使う準備ができる。

  • 「CREATE」…作成する。
  • ALTER」…変更する。
  • DROP」…削除する。

 

DML(Data Manipulation Language:データ操作言語

データ操作するときに使う。いわゆる「CRUD」のことで、SQLのうち、このDMLを覚えれば、とりあえずRDBは使えるようになる。

CRUD(クラッド)とは、ほとんど全てのコンピュータソフトウェアが持つ永続性の4つの基本機能イニシャルを並べた用語

その4つとは、Create(生成)、Read(読み取り)、Update(更新)、Delete(削除)である

ユーザインタフェースが備えるべき機能情報の参照/検索/更新)を指す用語としても使われる。

 

この中で一番活躍するのは、「SELECTコマンド命令文)だろう。

SELECTは、いろんな条件を付けてデータを絞り込む/加工することができて、便利なんだ。(Excelなどの表計算ソフトよりも高機能

 

JOIN(結合)

RDBは「リレーショナル」(関係)という冠言葉が付いてることからも分かるように、関係がある表と表をくっつけて、データを加工できる。

表と表をくっつける操作のことを「結合」という。

SQLでは「JOIN」というコマンドを使って表と表を結合できる。

↑このページにある丸と丸が重なった図を見てくれ。この図は「ベン図」といって包含関係を示す図だ。図を描いて塗りつぶせば、欲しい部分が分かりやすくなるだろう。

 

結合の種類

表と表のつなげ方には、何通りかパターンがあるよ。

  • 結合は、「内部結合」(INNNER JOIN)と「外部結合」(OUTER JOIN)の2種類に分類できる。
  • 外部結合はさらに、「左結合」(LEFT JOIN)と「右結合」(RIGHT JOIN)と「完全結合」(FULL JOIN)の3種類に分類できる。

 

内部結合は単純だ。外部結合はちょっとややこしい。

外部結合は「LEFT JOIN」の形がよく使われると思うので、まず最初にLEFT JOINの仕組みを理解すれば大丈夫だろう。

(LEFTの仕組みを基準にして、RIGHTやFULLとの相違点を意識すれば、表のつなぎ方を間違えにくい?)

 

DCL(DataControl Language:データ制御言語

トランザクション」は、データ更新に失敗したとき、元に戻せる機能だ。(安全装置

  • 「COMMIT」…更新処理の確定
  • 「ROLLBACK」…更新処理の破棄

 

言葉だけだと意味が分かりづらいと思う。

Google画像検索で「トランザクション」を検索して、分かりやすそうな図解を探してみよう。

↑このページの「図1 処理失敗による不整合の発生」を見てみよう。

 

銀行で口座間の送金を考えてみる。Aさんの口座からBさんの口座へ50万円送金したい。

  1. Aさんの口座から50万円減らす。
  2. Bさんの口座に50万円追加する。

この2つの処理が両方とも成功しないと、送金は失敗だ。(Aさんは送金できてないのに貯金が減ったら怒る。Bさんは送金されてないのに貯金が増えてラッキー!)

AとBの両方が成功したら更新処理を確定する。AとBのどちらか、または両方が失敗したら更新処理は破棄してなかったことにする。(やり直し!)

これがトランザクションだ。

 

クレーム対応難易度

ちょっと話がそれるけど、トラブルの重大さ=クレーム対応難易度について考えてみよう。

  1. 人身事故 …人命にかかわる事故は取り返しがつかない。文句も一番キツイ絶対ミスがあってはならない分野のシステム開発はなるべく避けよう。
  2. 金銭絡み …(命の次に)お金大事という人は多い。人は金の話になるとシビア文句も強烈だ。決済など金銭絡みのシステムでは、RDBトランザクションを使おう。
  3. 上記以外 …その他のクレームは、それほどハードではない。匿名掲示板とか、どうでもいいゴミ情報投稿されるシステムなら、トランザクションは使わなくてもOKだろうw

 

DB管理ツール

ここまで、SQLRDB操作する方法について話した。

RDBは、SQLコマンド操作するだけでなく、DB管理ツールを使って操作することもできる。

DB管理ツールについても知っておこう。

 

この講座では「phpMyAdmin」というDB管理ツールで「MySQL」を操作した。

他にも、Google検索で「DB 管理 ツール GUI」などで探してみよう。商用だけでなく無料でも便利なソフトがたくさんあるね。

 

など。

 

SQLパズルだ!

SQLを駆使すると、欲しいデータをホイホイ取り出せる。

SQLコマンドを組み立てる作業パズルのような要素もあるので、遊びだと思ってSQLに取り組んでみて欲しい。

SQL パズル」でGoogle検索すると、いろんなテクニックが紹介されているので、時間があったらチャレンジしてみよう!

 

SQLの話は、それだけで1冊の本になるぐらい広範だ。今回は、SQL概要説明するだけになってしまった。

SQLの詳細については、前回紹介したSQL参考書などを読んでみてね。

 

まとめ

 

次回は、データベースを使ってWebアプリを作ってみよう!

データベースって便利だな~~~!!!」と実感して欲しい。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマ養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマ養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマ養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマ養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマ養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマ養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマ養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマ養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマ養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマ養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマ養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマ養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマ養成講座 その13 SQL文法 ←★今ここ★

anond:20181031014212 増田プログラマ養成講座 その14 Webアプリの試作品作成

anond:20181024214737 増田プログラマ養成講座 コンテンツ一覧

2018-10-26

増田プログラマー養成講座 その12 データベース参考書

前回は、MySQLphpMyAdminを使って、リレーショナル・データベースRDB)を少し触ってみた。

今回は、RDBの使い方や仕組みについて理解を深めるための資料を探してみよう。

 

本は、買う価値のある本と、買わなくてもいい本の2種類があるね。

  • 買う価値のある本:何度も読み返す本。
  • 買う価値のない本:1度読んだら終わりの本。(図書館で借りる。図書館にない場合は買う。読み終えたら古本屋などに売却)

どちらの本かは自分判断で決めよう。(1度で理解できない本は、何度も読み返すことになるだろう。)

 

初めてRDBを使う人のためのガイダンス

本書は,新人エンジニアデータベース全般について勉強したいとき最初に読む本です。

データベースに関する知識を広く浅く網羅的に紹介してた。

最初に読めば、DB全体を俯瞰する地図を手に入れたようなもの。その後の見通しが良くなる。

 

入門書(初級レベル

本書はMySQLをはじめて触る方を対象として,開発環境の準備からSQL基本的な書き方,PHPによるWebシステム開発まで,図解でわかりやす解説します。

MySQL入門書カラフルな図解が分かりやすい。

まずは、データ操作の基本「CRUD」(Create=追加、Read=取得、Update=更新Delete=削除)を理解しよう。

CRUDが分かれば、DBを使ったWebアプリを作れる。→ここがIT土方の最低レベルだぜ!

 

豊富な図解とていねいな解説により、やさしく・楽しくデータベースSQL学習できる入門書です。

本書は、データベース操作する問合型言語SQL」の文法練習できる。

SQLが読める&書けるようになれば、RDBを使ったプログラミングで苦労しなくなる。

 

 

 

上記2冊の入門書程度の知識を身に付ければ、RDBに関しては初心者から脱却できるはずだ。

RDBを使うプログラムを作るなら、まずはこの程度の知識クリアしておけば、十分だろう。


次の段階では、既存DBを使うだけでなく、「ゼロからDB設計、構築してくれ」と頼まれるようになるはずだ。

時間があったら、DB設計スキルを身に付けておこう。

(以下の話は、今の段階では無視してもOKRDBにある程度慣れたら読んでみて!)

 

 

 

ミックさんのDB

データベースの本はいろいろあるけど、「ミック」という人が書いた本はRDBの要点がまとまってるので、なるべく早い段階で一通り目を通しておくことをお勧めする。(ミックさんの本は買って何度も読み返してる。)

 

DOAデータ中心アプローチ

RDB設計方法はいろいろあるが、古典的手法として「DOA」(データ中心アプローチ)がある。

なぜこの古臭いDOAが、今でも重要なのだろうか?

DOAと、他の「OOAObject Oriented Approach:オブジェクト指向アプローチ)」「POA(Process Oriented Approach:プロセス中心アプローチ)」を比較した図を見てみよう。

OOAは、言い方を変えれば、

[ユーザー] ←→ [プログラム] ←→ [DB]

という流れになっている。

まりユーザーから見ると、間にある[プログラム]は、[DB]を包んでいる「ラッパー」でしかない。

=[DB]のデータ構造スキーマ)さえシッカリしていれば、間にある[プログラム]は取り替えてもあまり困らない。

 

RDBを使うシステムなら、DB設計プログラム設計よりも重要になる。

(後で[プログラム]を変更するよりも[DB]を変更する方が影響は大きい)

から今日でもDOAは十分に役立つ手法だと思って理解して欲しい。

 

DOAは、ざっくりと3ステップでやる。

  1. 分析会社業務などを分析して、データCRUDが発生してる所を列挙する。
  2. 論理設計データ間の関係分析して、「ER図」を作る。
  3. 物理設計ER図を基にして、DB設計する。

慣れたらER図を書かなくても、頭の中で思い浮かべるだけでもテーブルを作れるようになる。

 

最初DOAを知っておけば、今後他の設計方法を使うときでも、比較検討基準として使えるので、損はないはずだ。

それでは、DB設計の本を見てみよう。

 

DB設計(中級レベル

初級者が押さえておくべきDB設計の基礎知識ポイント正規化非正規化のケーススタディテーブル設計のやってはいけないバッドノウハウ、注意すべきグレーノウハウなどを丁寧に解説します。

DB設計入門書。著者はミックさん。

DOA正規化階層構造木構造)のデータの扱い方など、DB設計の基本を網羅的に説明している。

 

現場で使えるアイデアが満載 デキるDBエンジニアになろう!

私が設計スキルを付けるために実際に行ってきた「身の回りのものを題材にERDを書く」という方法サンプルを今回は8種類書き下ろさせていただきました。

手前味噌ではありますが、本書をお読みいただき実践していただくことで「実務で具体的に手が動く」というレベルに達していただけると考えています

DB設計入門書

DOAの考え方、ER図の書き方などが説明されている。

 

RDB理論上級レベル

RDBSQLは「関係代数」という数学が、その基礎を支える理論になっている。

関係代数」などを解説

RDBを改造したり、自作したくなったら、RDB原理を知っておきたい。

この手のコンピューターサイエンスの本って、難しくてつまらない本が多いけど、この本は図解が多くて、珍しく分かりやすい本だったw

 

ネット

本の情報は、出版された瞬間から陳腐化が進む。

最新の情報は、ネット確認することができる。

 

公式サイトオンラインマニュアル

自分が使うデータベースマニュアルは最も基本的な1次情報になるので、不明点があったらまず確認するようにしたい。

など、公式サイトオンラインマニュアルをチェックしておこう。

 

ミックさんの解説記事

ミックさんは、ネットでもDB技術論の記事を公開されており、参考になるかも?

(↑無料Webサーバー「Yahooジオシティーズ」は2019年3月閉鎖予定なので、読むなら今のうち?)

 

階層構造になっているデータカテゴリー情報など)をRDBに保存するとき、主なやり方が3通り紹介されてた。(上記の本でも紹介されてる)

  1. SQLで木と階層構造データを扱う(1)――入れ子集合モデル
  2. SQLで木と階層構造データを扱う(2)――経路列挙モデル
  3. SQLで木と階層構造データを扱う(3)――入れ子区間モデル

自分は(2)の「経路列挙モデル」が分かりやすくて、いつも使ってる。

 

…という具合に、ネット上の公開記事にも参考になる情報がたくさんあるよ。

(ここまでの説明URLを9個張ってしまったので、もうこれ以上URLを張れない。><

他にもGoogle検索などで役立つ記事を探してみよう!(唐突な締めw)

 

NoSQL

データストア(データを保存する道具)は、RDB以外にもいろいろある。→「NoSQL」とか呼ばれている。(自分検索してみてw)

RedisHadoop、ElasticSearch、OpenStack…いろいろな道具が発明されてるね。

RDB以外のデータストアを使うときでも、RDBと相違点を比較しながら学べば、取っ掛かりが持てて、理解スムーズになるだろう。

RDBは、知っておいて損はない。使いまくって、体得しよう!

 

まとめ

RDBSQLパズルみたいなものから、楽しんで学んで欲しい。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書 ←★今ここ★

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん