「DB」を含む日記 RSS

はてなキーワード: DBとは

2018-12-18

(PHP) phpMyAdminのセキュリティー

アドバイスどうもありがとうございます

https://anond.hatelabo.jp/20181218231219

本番サーバには入れないでね

phpMyAdminセキュリティーって、過去の事例を見ると、あまり高くないようですね?

この手の管理ツールセキュリティ侵害を受けた場合ダメージが大きいので、インターネットからアクセスできないようにしておくのが基本です。特にphpMyAdmin過去に致命的な脆弱性が何度も発見されており、インターネットさらして利用するには向いていません。任意コード実行可能脆弱性の事例もあり、DB以外にもリスクがあります

 

内部ネットワークからしかアクセス出来ないようにしておきましょう。レンタルサーバのようなインターネット孤立したサーバであっても、VPNの経路を作りそちらからしかアクセス出来ないようにしておくようにした方がよいでしょう。

 

IPアドレスによる制限は次善策です。アクセス元のIPアドレスが固定されており他人と共有していないならそれなりに安全になります

 

URLによる隠蔽は外部から攻撃可能な既知の脆弱性スキャンするようなカジュアルアタック避け程度にはなりますが、URLは何かと漏洩するものですので、一般セキュリティ手法と見なされていません。

 

アクセス制限をした場合でも、認証は必ず設定する必要があります。例えばCSRFのような攻撃にはアクセス制限無意味です。

 

phpMyAdmin認証HTTP認証のどちらを使う方がよいかは使ったことがないのでわかりませんが、HTTP認証場合BASICではなくダイジェスト認証にしてください。BASIC認証は(ほぼ)生で認証情報が流れますので使ってはいけません。(ブラウザで人が操作する場合以外にはBASIC認証を使わざるを得ない場合もあります

対応

  1. phpMyAdminローカルの開発サーバーで使う。
  2. 本番サーバーのMySQLメンテナンスときだけ、Adminer.php等を使う。(使用前にコピーして、使用後は削除する) もしくはMySQLコマンド操作する。

こんなかんじでしょうか?

Mackerel時系列DBスキーム論文が出るというのに、はてなグラフには移動平均すらつかない

まあ、Mackerelを使えということなのかもしれない。

みんな、はてなグラフは何を記録するのに使っているのだろう。

自分典型的なところで貯金残高や体重を打ち込んでいた。

しかしいずれにせよ知りたいのは日々のちらちらノイズスムージングした後の傾向である

はてなグラフアイデアとしてはなかなか面白かったのに移動平均程度の簡単な集計機能すらつかなかったのはなぜだろうか。

あいい、最近ニジエという18禁ヘテロ男性専用画像SNS?っぽいものを知った。

ネタのような機能である射精管理という機能がある。しかしこれもスムージング機能はもちろん備えておらずさらにニジエ内での回数しかグラフにしてくれない。

様々な非対称を捨象して考えるならば目的は違えど月経周期管理予測ルナルナが使えるのかもしれない。

実際ググってみたら2(5)chに「ルナルナ射精管理しているという」スレを立てたやつがネタ扱いされていた。

しかしだ、ザイムだって出費のスムージングなんてしてくれないし、破産予測みたいなこともしてくれない(結構危ない橋を渡っている)。

時系列は世の中にあふれているのに周期までたどり着いているウェブアプリがそうそうないのである

Mackerel業務以外で触ってないので知らないけど、インプットトリガーとして例えばGoogle Spreadsheet とかはてなグラフは使えるのだろうか。

しかしまあ気軽に打ち込めて簡単スムージングや周期推定を持ったグラフアプリというのが存在しないのはなんでなんだろうか。

VPS借りて自分向けに作れという話かもしれないが。

DB検索結果の行に"line"って付けるセンス

2018-12-17

噛ませ犬キャラたちの個人的ベストバウト

噛ませ犬キャラたちがいとおしい。

バトルの最後でいいところを持っていく、フィニッシュを決める、そんなキャラたちも大変魅力的でカッコいいとは思うのですが、それを上回って私の心を強く惹き付けるのは、下手したらバトルの途中で脱落していく噛ませ犬キャラたちです。

とは言え、ただ弱いだけじゃ噛ませ犬にもならない。噛ませ犬になるためには、そこそこの実力を兼ね備えている必要があるのです。

それなりに強くて、かつぶっ飛んだ強さでもない。その中途半端さが魅力的なバトルシーンを作るのでは?と言うのは私の持論です。

とにかく、噛ませ犬キャラたちのバトルは魅力的なんだ!!

そんな衝動が沸き上がり、文に認めたくなったので筆(キーボード)を取った次第です。お暇な方はお付き合いいただければ幸いです。

あと、私が勝手に噛ませ犬認定したキャラたちが数名出てきますが、異論はもちろん認めますあくまで私個人意見ですので、異論反論はいつでも受け付けますが、「わかる~~!!」という同意意見ももちろん受け付けます。わかってくれる人がいてくれると嬉しい。

噛ませ犬キャラなんて星の数ほどいますが、とりあえず天下の週刊少年ジャンプから有名どころを数名お呼びして語りたいと思います

ロック・リー vs. 我愛羅NARUTO

これ。

リー君ほど見事な噛ませ犬、いる?

いやまあNARUTOそもそもキャラも多くて、その分噛ませ犬も多いんですけどカカシ先生とか。

一応、ロック・リーというキャラについて簡単にご紹介しておきますと、一言で言えば熱血努力バカです。あと体術がすごい。

リー君は主人公ナルトたちの1つか2つ上の学年?の先輩忍者で、中忍試験の際に、ナルトたちと初顔合わせします。

色々な事情がありまして(その辺りはどうぞNARUTO本編をお読みください)、リー君は突如、ナルトチームメイトでもありライバルでもあるサスケ喧嘩を売ります

この時のサスケと言えば、ナルトたちの学年の中ではトップの成績、実力も才能も申し分なく、主人公ナルトの目指すべき、倒すべき目標でした。つまり強い。

そんなサスケを、さして歳も変わらないリー君が手玉に取ったのです。

あのサスケが手も足もでない。インパクトは充分でした。ロック・リー、こいつはつえぇぞ。

そんな、我々読者にリー君の実力を印象づけてから迎えた、vs.我愛羅戦。

我愛羅もすでに相当な実力者として描かれていました。というか強い通り越してヤバいヤツ扱いでした。実際ヤバかった。

そんなヤバいヤツ相手に、どうするリーくん!

と思いきや、なんと中盤まではリーくん優勢で勝負が進みます

我愛羅の砂の鉄壁防御を、スピード主体体術で追い詰めるという、体術を極めたリーくんにしかできない攻略でした。我愛羅の頬に傷をつけたあの踵落とし最高。めっちゃカッコいい。

そして確かに我愛羅をあと一歩のところまで追い詰めたのです。

しか相手は尾獣持ち。そのタフさに加え、体に多大なる負担をかける攻撃をしてしまったがゆえにリー君に生じてしまった隙をつかれ、リー君は四肢を砕かれ敗北してしまうのです。

我愛羅の強さと残忍さを印象付けさせられ、リー君は途中退場と相成りました。

尾獣ってなんだよチートだろ。ずるいやん。

その後も色々エピソードがあるので是非本編を読んで頂きたいのですが、ともかくリーくんは、相当の実力者として描写されながらもラスボスには勝てずに敗北を期したのでした。てかあの当時の木ノ葉の下忍の中じゃ最強なのでは…?

でもこのバトルは熱かった。リーくんが我愛羅を追い詰めた展開には拳を握った。文句なしベストバウトでしょう。

でも負けてしまう。噛ませ犬だからね、しょうがいね

余談ですが、このロック・リーvs.我愛羅戦は、アニメ版の出来も大変に素晴らしいので是非見ていただきたい。アニメスタッフに愛される男ロック・リー


クリリン vs. マジュニアドラゴンボール

国民作品と言っていいでしょう、ドラゴンボールからこのバトル。

てかこのバトル覚えてる人いる?

ドラゴンボールなんてベストバウトいくつあんだよってレベルでいい勝負だらけなのですが、ここはあえてこの勝負を語りたい。

まあまずクリリンマジュニアについて簡単にご紹介。いや紹介いるか?あ、ちなみにマジュニアピッコロです。まだイキってたころのピッコロ

クリリンはいわずもがな、主人公悟空チビハゲ親友ですね。髪は剃ってただけらしいんで後期にはフッサフサに生えてますが。一説によると地球人最強とも言われる男です。幼少期から悟空と共に修業し、実力が悟空を上回ったことはないものの、トリッキーな戦法や素早さを活かした機動力等を持ち味に、人造人間編くらいまでは前線で戦ってました。地球人なのにようやる。

映画の出演率も結構高かったと思いますクリリンの「なんでオレだけこうなるの…」はもはや悟飯危機に駆けつけるピッコロさんと並んでお約束

そしてマジュニアことピッコロさん。今でこそ仲間面してますが、そもそもピッコロさんは最初敵でした。今回語りたいのは、この敵だった頃のピッコロさんとのバトルです。

ピッコロさんは、先代が一度悟空に敗北しています(この辺りの展開についてはいいかDBを読め)。その雪辱を晴らすべく、というか世界征服するのに明らかに障害になるであろう悟空大衆面前で八つ裂きにすべく、律儀に天下一武道会エントリーしてきたのでした。ピッコロ、という名前は世に知れ渡っているから、マジュニア(魔Jr.)として。その気遣いかわいい

天下一武道会なんで、試合形式でバトルが進みます。第何回戦か忘れましたが、得体の知れないマジュニアと当たったのが、修行を通して若干背と実力の伸びたクリリンでした。

ぶっちゃけ悟空たちも読者も、こんなん負け試合だろとは思っていたと思いますだってクリリンが噛ませ犬だから悟空なんか「死ぬんじゃねえぞ」的なことを言ってた気がします。負けは確定かよ。もっと別の応援の仕方あんだろ。

そして始まる試合。もちろんマジュニアが優勢ではありましたが、クリリン、粘る、粘る。これほんと、私の文章じゃ全く表わせないんで漫画を読んで欲しいんですけど(あと今手元にコミックがなくて細かいところを確認できない)、いい勝負をするんです。確か14,15巻くらいの話だったと思います

マジュニアが、「少し驚かせてやるか」とか言って、伸びーるアームを披露するのもこの試合が初めてです。てかそれまでデコピンくらいしか披露してなかったからね。クリリンもどちらかと言えばスピードと手数で勝負する系のキャラなので、攻めて攻めて、最後とっておきとして、かめはめ波を食らわせてやれるチャンスまで生み出しました。

結果としてそれは避けられ、「クリリン後ろだーっ!」というお手本のような台詞悟空が吐いたとおり、背後に回ったマジュニアによってクリリンは上空から地面に叩きつけられました。ダウン。そして審判によるカウント

マジュニアはこの時点で「勢い余ってうっかり殺してしまった」的なことを宣っていますマジュニア的にも、手加減する余裕がなかったこと、そして殺す勢いの攻撃を繰り出されていることがわかる台詞です。まじ?クリリンまた死んだの?もうドラゴンボールでも生き返れねえんだぞどうしてくれる!!

しかし、カウントの途中でなんと立ち上がるクリリン!!マジュニアもめちゃくちゃびっくりしてますしかダメージは大きく、クリリンは降参宣言をし試合としては敗北してしまいました。

いやこれめっっっちゃくちゃ大健闘でしょ。最後クリリンの、へにゃっとした笑みからの「まいった」も最高。ある意味カッコいい。この試合以降、マジュニアことピッコロさんも、何かとクリリンの実力は認めている素振りを見せます悟空以外の人間をザコだと思っていたピッコロにひと泡吹かせた瞬間でした。

熱くない!!!???この試合

ドラゴンボールにおけるバトルの中では地味な方だと思いますが、個人的にはこれをクリリンベストバウトに挙げたい。異論は認める。

ちなみにドラゴンボールキャラが多いんで噛ませ犬はたくさんいますが(ベジータとか大人トランクスとか)、ドラゴンボールの噛ませ犬は全体的に退場早すぎると思う。かなC。



サンジ vs. クリーク海賊団(ワンピース

 ド ン !

というわけでもはや国民作品と言っていいでしょうワンピースからはこれ。結構初期のバトルです。

ワンピもめちゃくちゃキャラが多いから噛ませ犬だらけなんだけど、その中でもサンジは一貫して噛ませ犬な気がする。最高。

まあ紹介するまでも無いと思いますが一応サンジについて説明しておくと、主人公ルフィ船長の麦わらの一味における戦うコックさんですね。コックだから手は料理をするためのもの、というポリシーのもと、戦闘は全て足技のみで行う蹴り技主体キャラです。ごく稀に包丁で戦うけど。

特殊能力キャラだらけのワンピにおいて、未だ身一つで戦うキャラであるところはもっと評価されていいと思う。去年と今年あたりで連載20年を迎えてようやくサンジフルネームが明らかになるなど、何かと話題の渦中にあったキャラでしたが最近ようやく落ち着いてきたかな。

一方、敵側のクリーク海賊団は、サンジ初登場エピソードの時に出てきた海賊団。首領クリークルフィ相手したとして、サンジ相手したのは鉄壁パールさんとかいう防御特化キャラと、鬼人のギンとかいトラファルガー・ロー前身みたいな目つきの悪い隈キャラ。二連戦になりましたがここはまとめて一つのベストバウトとして見ようかなと。

パールさんは正直ぽっと出キャラですが、ギンは戦闘に入る前に1エピソードあります。腹減って死にそうだった時にサンジ海鮮ピラフ?を作って食わせてやった、つまり命を救ってやったと言う展開があります。つまりギンにとってサンジさんは命の恩人。その辺りも込みでこのバトル好き。「クソうめェだろ」は名言

第一回戦はサンジ vs.パールさん。サンジの働いていたレストランを襲ってきたクリーク海賊団を追い払おうとして、サンジが初めて戦闘を読者に見せます

今まで一度も傷付けられたことのないらしいパールさん相手に、優勢なサンジ鉄壁パール鉄壁を崩して2回くらい鼻血吹かせます。素早い動きで懐に潜り込み、的確に相手を蹴り飛ばす!てか、サンジスピードと手数勝負キャラだよな。そう言う戦闘スタイルキャラが好きなだけかもしれんと言う気が若干してきた。

このまま楽勝かと思われたところで、ギンがサンジの恩人(ジジイ)を人質にとります抵抗の出来なくなったサンジパールさんにボッコボコ。いやずるいやんけそれ。そしてこの辺りですでに漂ってくる噛ませ犬臭。

まあでもそのあと色々あって(この辺りは本編読んで)、パールさんはギンにトドメを刺され、選手交代サンジ vs.ギンになります

いやサンジさんすでに満身創痍やん。ギンもそこそこ弱ってるけど。命の恩人に向かって「あんたはおれが殺る」みたいなこと言うギンのヤンデレみがすげえわ。

んで、今度はサンジさん普通にボコボコにされますボコボコにはされるけど、ここの戦闘がな~良いんですわ…!!パールさんとの戦闘もそうなんだけど、足技キャラというのが前面に出てて、多彩な足技を駆使してくるのと、一つ一つの流れるような動きが丁寧に描写されてんな~って思う。最近ワンピ大技ドーン!!って感じの戦闘が多いから…それでもいいんだけど別に…

サンジ戦闘に関しては、初期アニメOPとかでやってた逆立ちからの回転蹴りとか踵落としとかそう言う感じの技の方が好きなので、なおさらこの vs. クリーク海賊団の時のバトルが良いなと思ってしまう。特に、ギンに一撃かますときの拘束から抜け出してからの蹴り落としまでの一連の流れがめっっっっちゃ好きカッコいい。

ぶっちゃけサンジはギンには負けるんですが、まあ、命だけは助けてもらうと言うか、その辺はもう漫画読んで。

そんなわけで、サンジの足技が丁寧に描写されているのと、二連戦の間に挟まるゼフとサンジ師弟愛というか親子愛的なものが素晴らしいので、個人的にはこれをサンジベストバウト推したい。次点でvs.ボンちゃん

なんで最近サンジライダーキックみたいな蹴りしかしなくなってしもたん…?あの逆立ちしてぐるぐる回るキックめちゃくちゃ好きだったのに。


●思いついたら書く

2018-12-14

anond:20181214115201 anond:20181214115509

フォーマットがあればデータとして蓄積出来る

上に報告する時にも口頭ではなく

データで発案と施策の結果が語れるわけで

誰に不利益がでるのかって感じだが

追記メールで送れExcelで送れとか基地外じみたことはやめようね。ちゃんと蓄積出来るDBを考えよう

2018-12-13

精神と時の部屋に住みたい

住みたくないよ。めっちゃ過酷らしいし。なんでDB世界の人たちはみんなこぞって入りたがるのか。

2018-12-12

anond:20181212190058

MySQL無料やぞ

もしくはWEB DB を入れる

access 買うよりはたぶん安い

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

平成最後だしポンコツSE転職事情さら

平成最後だし、なんかい不況が来るかもわからない状況な気もするし、

今のうちに年収上げておきたいなんて考えている人もいるのかなと思い、

本当に普通な感じで埋もれているエンジニア転職した時の話をしようと思う。

現在私は同業界大手企業で働いている。転職結果としては年収も大きく上がったし、

職場環境も申し分ないので成功したと思っている。

 

スペック転職時)

 年齢:39歳

 

 <前職>

 中堅の独立系SI企業WEBSierもやってるような感じ)社員600名程度

 に所属していた。勤続は7年目

 

 <技術力>

 技術力はほんとに並の下程度。

 JavaとかPHPとかやっていて、PHPがメインだったかな。主にWEBサービスを作ったり、社内WEBシステム作ったりしてた。

 プログラミングの基礎はあるし、SQLやその他DB知識もそれなりにある。サーバー知識あんまりないし、

 Linuxコマンドは正直ちょっと苦手だし、AWSとか触ってないし、なんならApacheだってそんなに詳しくない。

 ググっていつも解決する。フルスタックエンジニア?なんだそれ?こちサーバーサイドエンジニアだ、文句あんのか?

 

 新しい技術言語は基礎があるので飲み込みは早い方だと思う。なので対応力はある方だ。Rubyでもpythonでもコード見れば読めるし、

 大抵のことは理解できると思う。でも業務では使ってない。JQureyもまぁ普通に使えるけどJSコードとかたぶん汚いと思う。

 

 色々と新しい技術をググって記事見たりして「わかった気になるタイプ」だと思う。36歳くらいでやっと「デザインパターン

 知らないとやばいんだ。勉強しないと!と焦って本だけ一応読んで「わかった気」になった。

 

 ここまで読めばわかると思うけどエンジニアとしてはだいぶ「ポンコツ」だ。

 でも仕事のためにやってるエンジニアとか結構こういう人が大半な気もするんだよね。

 立ち位置は開発リードとか設計とか上流も少しやってた。年齢のせいもあると思うけど、

 まぁうまく立ち回って仕事してた感じだと思う。コミュ力はそれなりにある方だと思う。

 もうエンジニアとかお前が名乗るなよとか言われそうだな。。。すまん。

  

転職活動の経緯

転職理由

 このまま、今のポジション仕事を続けてたら永遠に新しいこととか他の言語を使って業務をすることができそうになかったから。

 嘘だ、人間関係だ。ほとほと同僚、後輩、パートナーに愛想が尽きたからだ。それと上司やその上の部長にもだ。

 客先で顧客と一緒に仕事をしてたが顧客側の人はほんとにまともで良い人ばっかりだった。転職する時にそれだけ、ちょっと寂しくなったな。

 ポンコツながらプロジェクトでは納期を守り何とかやり抜いてきたが、全く評価されない現実もあり、それも嫌だった。あと、給料安い。

 表向きはいろんな理由があるだろうけど、転職する人の理由はきっとこれが現実だと思う。

 

概要

 転職を決意

 ↓

 とりあえずビズリーチよさそうねとか何も吟味せず登録

 ↓

 エン転職にも登録(以前使ったから)

 ↓

 DODAリクルート系は良い思い出が一切ないので登録してない。

 ↓

 ギークリーというところからビズリーチ経由で勧誘

 ↓

 一応そこの担当面談してギークリー利用

 ↓

 ビズリーチギークリーとエン転職転職活動

 ↓

 ビズリーチ経由でA社で外資強めの転職エージェントに会う。

 ↓

 ビズリーチ経由でB社で金融ITに強めの転職エージェントに会う

 ↓

 最終的にA社で3社応募して、2社内定をもらい転職した。

<詳細と雑感>

 転職しよう!と思ってからとりあず動けーーー!って感じで動いた感じです。

 総応募数は覚えてないけど30~50社くらいだったと思う。書類で超落ちる。年齢のせいも大きい。

 エン転職スカウト全然ダメだった。めぼしい企業がなかったし、年齢のせいか知らんけど、

 タクシーちゃんとかトラック運転とかそういうのも来てた。

 ギークリーから応募したのが一番多いと思うけど、とにかく手あたり次第に紹介してくる。

 よさそうな企業もあったけど、面接まで行ったのは4社程度ですべてお祈りだった。

 2次や最終までは行くが、いまいち紹介された企業自分志望動機を合わせる作業がどうにも苦手でうまく行かなかった。

 ギークリーはほんとに求人が多いから、たくさん見て選びたい人には向いてると思うけど、自分には向いてなかったな。

 他にもビズリーチ経由で4社くらい直接カジュアル面談があったけど、有名なY社とか、運輸系のY社のシステム会社とか、

 印刷系のD社の子会社とか、どれも最初カジュアル面談で、それ以後連絡なかったなぁ。

 カジュアルと言いながらガチ面接なこともあったな。

 

 そんな感じで行き詰って2か月。心機一転また別のところ!というのと、

 自分でもう一度ポンコツなりに職務経歴書を頑張ってブラッシュアップし、面接対策もして、改めてA社とB社とつながった。

 B社からの紹介はとても面白い会社だったし、一次面接もかなり好感触だったのだが、なぜかその後に論文筆記があり、

 書いて出したら、落ちた。どうやら思想が合わなかったらしい。

 A社から紹介されたのが、医療系のWEBサービスの会社と誰もが知ってる大手企業

 どうやら大手企業とは結構つながりのあるエージェント会社だったみたい。

 自分大手に行けるか半信半疑だったが、面接対策結構しっかりしてくれて助かった。

 同じ質問面接でされたので、うまく答えることができたと思うし、職務経歴書も一緒に見てくれた。

 そして、2か月でこの医療系の会社大手から内定を頂いた。転職活動は実質4か月くらい。

 どちらも良い会社だったので、本当に迷ったが、大手の方にした。

 断るのもエージェントがやってくれるのでこれも結構気持ちが楽だった。

 

<振り返って思うこと>

 ポンコツなりにアピールできるポイントがあれば、それをしっかりアピールするような職務経歴書を作ったり、

 私の場合は3回目の転職だったので、今までの経歴をきちんとよどみなくアピールできるような練習有効だった。

 転職活動初期は全然対策してないこともあって、やっぱり落ちたのかなと思う。

 だんだんエンジンがかかって、面接にも慣れていき、最終的に大物ゲットできた感じだ。

 そして、面接ではやっぱり自分はできる奴だ!ということをちゃんアピールした方がいいと思った。

 謙遜かいらないし、こういう職務なんですができますか?と言われても、普通に全然問題ないです。くらいに言ってもいいと思う。

 

 ハイスペックエンジニアかいやいや十分すごいですわ的なエンジニアは、自分活動して、普通に交渉もして、

 自分がより有利な環境を手に入れることができると思うけど、私のようなポンコツ普通にエージェント使って、

 普通に応募して、面接対策しっかりして、志望動機ちゃんと頑張ってたくさん考えて、ちゃんと喋る練習して、それで行けば結構いけると思う。

 落ちるのはやっぱり職務経歴書がまだちゃんと練れてないのと、面接練習や、志望動機が甘いんだと思う。そこを頑張れば良い環境転職できると思う。

 

 おススメのエージェントとかは特にいかな。自分に合ったもの自分転職活動しながら、見つけるのが良いと思う。

 1つ言うならエージェントを1つに絞らないことかな。忙しくなるけど、いろんな所と付き合って、自分に合うところを見つければいいと思う。

 そういう意味ではビズリーチは大小さまざまなエージェント会社があり、そこから連絡がバシバシ来るので登録しておくとよいかもしれないです。

 

<まとめ>

こんな感じだ。読み返すとあんまり参考にならないかもしれない。。。

私は前の会社全然評価されなかったが、今の大手に移ったら、普通に評価が上がって、給料もしっかり上がった。

環境次第で人の評価って全然変わるし、所詮評価する側のフィルターをかけた評価なんてやっぱり気にしなくていいんだと思った。

実際前職の部長退職の旨と転職先の話をした時に「子会社ですか?」とか言われたし、「いえ、本体です。」と答えたら「マジで?」という顔をしてた。

部長フィルターでは自分評価はそんな感じだったんだなと実感した。

ももちろん良いフィルターをかけて評価してもらっていると思うけど、自分にとってどっちが良いかは明白だし

その良いフィルターが本当になるようにもっと努力したいと思う。

 

今の市況ならほんとに転職すれば年収上がるくらいの状況だし、勤続3~5年以上で、

自分の現状に不満があるなら、いっちょやってみるのも良いかもしれません。

誰かの参考になれば幸いです。

2018-12-02

anond:20181202215246

PCスペックあげる必要性を感じないので許可できません

Excel撲滅してWEB DBなどを活用しよう

メモリ増設くらいなら許すぞ

[]2018年12月1日土曜日増田

時間記事文字数文字数平均文字数中央値
008211388138.961
01425381128.166.5
02235939258.243
03101196119.632.5
044834208.553
05183252180.747.5
0626154659.535
07314015129.555
08344065119.648
09111989889.235
1055397372.236
111581307782.832
1210013733137.339.5
1310213091128.334
1410210322101.238
1511812154103.044
161131042192.228
1710013097131.033.5
1810920193185.345
191151060592.245
201141117498.045
2111112554113.151
2296833786.841.5
231151012888.135
1日1889210373111.441

頻出名詞 ()内の数字単語が含まれ記事

人(205), 自分(153), 今(99), 話(89), 日本(75), 増田(74), 女(60), 問題(57), 仕事(57), 必要(57), 人間(57), 男(56), 前(56), 金(54), 意味(52), 関係(52), 好き(52), 頭(50), 結婚(48), 感じ(48), 気(47), あと(42), 相手(42), 会社(42), 場合(38), 他(37), 社会(35), 勉強(35), 普通(35), 子供(33), 全部(33), 理解(32), 言葉(32), ー(31), 理由(31), 企業(31), 今日(31), 環境(30), 無理(30), ネット(30), レベル(30), しない(29), 女性(29), 別(28), 他人(28), おっさん(28), 手(28), 気持ち(27), 存在(27), じゃなくて(26), 時代(26), 時間(26), 当たり前(26), 子(26), 男性(26), 最近(26), セックス(25), 大企業(25), バカ(25), 最初(24), キモ(24), 結局(24), 生活(24), 目(24), 英語(24), 日本人(24), しよう(23), 人たち(23), 人生(23), オタク(23), NTT(23), 派遣(23), では(22), まとも(22), 一人(22), 社員(22), 馬鹿(21), 国(21), 意見(21), 昔(21), 世の中(20), 正直(20), 簡単(20), 結果(20), 全員(20), 世界(20), 友達(20), いない(20), 映画(19), 大学(19), 嫌(19), 内容(19), 能力(19), 誰か(19), 東京(19), 退職(19), 職場(19), 家(19), 親(19), ダメ(19)

頻出固有名詞 ()内の数字単語が含まれ記事

日本(75), 増田(74), じゃなくて(26), 大企業(25), キモ(24), NTT(23), いない(20), 東京(19), 同性婚(18), なんだろう(17), アメリカ(17), 元増田(15), 中国(14), スマホ(14), わからん(14), ワイ(13), 価値観(13), マジで(13), 2018年(12), 普通に(10), Google(10), にも(10), フェミ(10), 嫌韓(9), 富裕層(9), ブコメ(9), IT(9), 韓国(9), 腐女子(9), GAFA(9), シュレック(9), 飲み会(9), 個人的(9), 異性婚(8), アプリ(8), 日本企業(8), はてなー(8), 可能性(8), なのか(7), 20代(7), 一日(7), ブログ(7), 氷河期世代(7), s(7), 社会的(7), トラバ(7), LGBT(7), 自分たち(7), はてブ(7), Twitter(7), hatena(7), 悪いこと(7), 何度(7), detail(6), DV(6), NHK(6), …。(6), 夫婦(6), 何回(6), 交通事故(6), Webサービス(6), インド人(6), 最終的(6), 娘(6), SNS(6), 兄弟姉妹(6), ???(6), 1人(6), twitter(6), ツイッター(6), 上の(6), 基本的(6), いいね(6), HIV(6), 欧米(6), 数年(6), 外国人(6), 働き方改革(6), 主義者(6), togetter(5), -1(5), コピペ(5), マンスプレイニング(5), 社会人(5), キモい(5), いいじゃない(5), 人間関係(5), 自民党(5), パワハラ(5), E(5), 経済的利益(5), 10年(5), 婚活(5), 毒親(5), 5%(5), 私たち(5), note(5), かな(5), -3(5), ロスジェネ(5), 金(5), かもしれん(5), 明治維新(5), Web(5), 商標法(5), 外資系(5), どんだけ(5), 人手不足(5), 共産党(5), ポリコレ(5)

本日の注目単語 ()内の数字単語が含まれ記事

シュレック(9), 異性婚(8), 商標法(5), ローグライク(3), コミッション(3), カモフラージュ(4), 妾(4), 経済的利益(5), GoPro(3), 11月30日(3), 出家(6), 同性婚(18), 外資(15), NTT(23), 日本企業(8), 大企業(25), 矯正(6), 派遣(23), ピル(6), 🐈(8), 正規(7), 富裕層(9), 輸入(8), 出世(14), ヤンキー(8), 年下(7), 通販(6), 退職(19), 正社員(14), 作れる(11), 地球(9), 社員(22), エントリ(9), 社内(9), 人材(8)

頻出トラックバック先(簡易)

■続きです→大企業の男に相手にされない(女にも) /20181201155849(28), ■大企業の男に相手にされない(女にも) /20181130212224(27), ■いつまで日本企業で消耗してるの? /20181201024136(20), ■言語を「その場に応じたことを言うゲーム」だと思っている人がいる /20181130112105(12), ■嫁の靴が93足あった /20181201183605(10), ■【急募デカチンになる方法 /20181201052902(9), ■富裕層への暴動って何したらいいの? /20181130075711(7), ■詭弁のガイドライン2018年版) /20181201124705(7), ■ /20181201103408(6), ■友達結婚 /20181201012357(5), ■投下する場所が間違ってるのは理解している /20181201180220(5), ■お金が貯まらない /20181201174317(5), ■ねこってなんであんな寝るん? /20181201105026(5), ■東京スーパーにロクな物がない件 /20181201165947(5), ■有能でなくても稼げる社会はムリ /20181201110911(5), ■半年くらい前にOmiaiで「ここで知り合った人と付き合うことになったのでごめんなさい」とやり取りが途切れた人 /20181201193302(5), ■ナンパについてった話 /20181201075226(5), ■妻「ビール250円てすごくない?」夫「まぁそういう戦略なんでしょ?薄利多売的な」 すまん、これの何がいけないんや??? /20181201091906(5), ■ /20181201150322(5), ■じゃあ訊くけど、40代氷河期世代って具体的にどう救えばいいわけ? /20181201113001(5), ■「私それ嫌い!」わざわざ言いに来るブクマカ達 /20181201080919(5), ■DBをUPDATEする時にWHERE句忘れたら全行UPDATEされるのって怖くない? /20181201151918(5), ■anond20181201125854 /20181201135149(5)

増田合計ブックマーク数 ()内の数字は1日の増減

5839047(3325)

2018-12-01

anond:20181201151918

本番環境DBはいじったことないな

電話受けるのはサポセンだろうし一開発者が気にする必要あるか?

DBをUPDATEする時にWHERE句忘れたら全行UPDATEされるのって怖くない?

マジでみんなどうしてんの?

本番環境DB触らないほうがいいのは知ってるけど、やむを得ないときあるじゃん

テスト環境で試してからやるけどさ、たまたまWHERE区コピペし忘れたら終わりじゃん。

これ間違ったら電話殺到すんのかなって考えながらUPDATEすんのマジで地獄

2018-11-29

https://anond.hatelabo.jp/20181129093636

木の増田じゃないけど

問題外 見つけ次第殺せ(そもそも起こすなという話ではある)

データ改竄
クラック

できるのは分かってるからマジでやめろ

超高速連打

データベースに負荷がかかる

一応サーバー側で防いではいるけどDB周りの実装ミスが死に直結する

高橋名人でもそんなことしねーぞ

なるべくやめろ

ゲーム自動化

100%黒だと言い切る保証が難しい(リアル24時間動くアホがたまにいる)、超速連打してなかったらまあ許すよって感じ

複垢

これも同じくリアル妹との差分が難しいので100%黒だと言いづらい。

昔のソシャゲカードバシーン)ってトレードあったけど、自動化するとゲーム通貨(スタ●リ的な)を無限に稼げるゲーム設計だったので

トレード廃止 or Myスタ●リ的な方向にシフトしたのはこの2個が主原因。1人1000アカウントかいるし業者とか1アカウントに集約してるし

問題外のやつはサーバー側で止めるべき案件なんだけど、それ以外の2個はよくある画像認証とかあの手のやつ以外で止める方法が(たぶん)ない

なんでそもそも仕様レベルで「24時間殴り続けることのメリットを薄くする」ってするべきだとは思うんだけど、

そうすると1回あたりのプレイ時間が減る => 遊ばないゲームになる => アクティブ落ちる、って判断になってマルチ実装してる系のゲームだと結構致命的

2018-11-25

anond:20181125172551

ツイ援DBで、素人評価たかそうな女の子探して事情話して、2回デート援して3回目ご飯ホテル行けば、きっと今からでも得るもの多いぜ。

2018-11-20

DBを「デービー」っていうのは日立に限らず業界標準じゃないか

HTTPを「エイチテーテーピー」っていうのは日立だけ

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

anond:20181119175520

DBだとチェックポイントまで物理ファイルの書き換えはしないからまあ時間かかるんじゃない

そんなのよりベンチマークソフトで書き換えの耐久テストをした実例ならいくらでもあるよ

2018-11-18

anond:20181118200837

まずオーラ測定器を製造販売している業者に連絡してオーラ登録(有料)を行います

その際、自分の出したいオーラカスタマイズできるので、大きさ、色、形、効果音とかは事前に考えておくと良いでしょう。

登録が終わり、クレジットカードまたはコンビニ決済が完了するとオーラ測定器のDB更新されます

その時点でその業者オーラ測定器で登録者のオーラを測定すれば登録した通りのオーラが出ていることを確認できるようになります

2018-11-16

anond:20181116203459

魚拓魚拓

株式会社アイビスというとこに入社して、3年いました。

そこで、あまり自分給与が低いことが最近認識しました。

手取りで18万ぐらいです。仕事としては、オブジェクト指向言語でかつSQLを使って、DB操作して、機能をつくる感じですが、

Yahooニュースに乗るようなシステムをつくっていましたが、18万円。

現在転職して、手取り33万円です。やっていることはほぼ変わらないです。

社長は開発のことしかしていなく、経営についてあまり興味がないようです。

いかに、エンジニアを安い値段で買い叩いているか気づきました。

さらに、ボーナスについては一年目は支給されません。翌年から支給されても一か月分ですが、減点式で0.8以下になります。150人以上いる組織ですが、みな多くの人が暗黙の了解で仕方なくいる感じです。

新人は15万いくかいかないかです。社員のことをかんがえていないような感じです。

社長会社の仕組みを変えずにただ自社開発だけをしていて自社開発のユーザーTwitterでやりとりをしているだけです。

機能改善サービスを開始したらプレスリリースとしてTwitterを使えばいいと思いますが、毎日ユーザーとやりとりしているので、経営すべきことを放置しているようにしかみえないです。

上場も考えているそうですが、そうしたらいい人を呼び集めて他の人を必然的に外すように考えているそうです。そんな人についていけないと思い退職しました。

また、営業の方もただ数字を上げればいいと単価の高い案件アサインして、すぐに退職する人があとをたちません。

エンジニアを安く買い叩く会社

株式会社アイビスというとこに入社して、3年いました。

そこで、あまり自分給与が低いことが最近認識しました。

手取りで18万ぐらいです。仕事としては、オブジェクト指向言語でかつSQLを使って、DB操作して、機能をつくる感じですが、

Yahooニュースに乗るようなシステムをつくっていましたが、18万円。

現在転職して、手取り33万円です。やっていることはほぼ変わらないです。

社長は開発のことしかしていなく、経営についてあまり興味がないようです。

いかに、エンジニアを安い値段で買い叩いているか気づきました。

さらに、ボーナスについては一年目は支給されません。翌年から支給されても一か月分ですが、減点式で0.8以下になります。150人以上いる組織ですが、みな多くの人が暗黙の了解で仕方なくいる感じです。

新人は15万いくかいかないかです。社員のことをかんがえていないような感じです。

社長会社の仕組みを変えずにただ自社開発だけをしていて自社開発のユーザーTwitterでやりとりをしているだけです。

機能改善サービスを開始したらプレスリリースとしてTwitterを使えばいいと思いますが、毎日ユーザーとやりとりしているので、経営すべきことを放置しているようにしかみえないです。

上場も考えているそうですが、そうしたらいい人を呼び集めて他の人を必然的に外すように考えているそうです。そんな人についていけないと思い退職しました。

また、営業の方もただ数字を上げればいいと単価の高い案件アサインして、すぐに退職する人があとをたちません。

2018-11-15

ドラゴンボール試写会

ここぞとばかりに「試写会はこういうモノ」とか言う映画好きが居るから映画イベント業界が先細るんだろ

大多数の人間抽選に当たってるのに当日席が無いとか想像出来ないし、ハガキの隅に書いてあっても読まないんだよ。残るのは当日行ったら満員で入れなくて雑に扱われ、SNS愚痴ったら映画通が「試写会は開場前に行くのが基本、開演前とか甘え」なんてマウント取ってきて映画が嫌いになる記憶だけ

数字読みも出来なく、来た人に「早く来なかったから席遠かったね。次は早く来よう」とか「早く来なかったから、今日は見れなかった。でもグッズ貰ったから次は早く来よう」みたいな学習させることもなく、ただ「書いてあるんで」で済ませるイベンターは駄目でしょ

でも、例え客をゴミ扱いしてもドッカンカード死ぬほどファンの居るDBだった問題ないんだろうな。昨日のでDB嫌いになった子供100人居ても、今日には新しく好きになる子供が300人は居るだろうし

2018-11-12

anond:20181112112442

間違いなくjavascriptの隆盛はGoogleが導いてる

学問としていまいちだったDB分野でweb検索イノベーション起こしたのと同じくらいjavascriptでもイノベーション起こしてる

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

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん