katsuyukikun’s diary

とある天パーエンジニアのblog

データベース入門②

もうすぐGWに突入にします。。。

 

結婚式の余興動画も作り終えたのでまた書いていきたいと思います。

 

まああとせっかくGWでまとまった時間取れるのでサイトの速度改善やら新しい技術入れたり何やらをやりたいのでね。。

 

とりあえずデータベース入門はとっとと読み終えて他のことしたいなと思ったので急ピッチで進めてます笑。

 

さて、久しぶりのデータベース入門です。

前回から読み進めましたが、8章くらいまでは論理値の説明と正規化の必要性とどうやったら正しくDB設計できるのかという説明でした。ここに関して個人的には「知っている人多いし、軽く流し読みする程度でいいかな」という感想です。それくらいで理解できる内容だと思います。

 

 

ってことで8章〜9章くらいからの内容に触れていきます。その内容とは以下です。

 

select文の使い方

まずはSQLの基本ですね、select文です。こいつは何をするやつなのか・・データ取得できる唯一の存在です!

書き方はこんな感じ、説明するまでもないですね。

SELECT カラムのリスト 
FROM テーブルのリスト 
WHERE 検索条件

 

これにいろいろ条件を付け加えることができます。集計結果を出したいなら

SELECT count(カラムのリスト) 
FROM テーブルのリスト 
WHERE 検索条件

 

重複省いた集計結果なら

SELECT count(distinct カラムのリスト) 
FROM テーブルのリスト 
WHERE 検索条件

 

集計結果に制限をつけたい時は

SELECT department, COUNT(*) 
FROM students
GROUP BY department 
HAVING COUNT(*) <= 30

とcountで取得したものに<=30といったような制限をかけることで取得することができます。今回だと30以下という制限をかけました

 

ここで人数少ない順にしたいときはサブクエリ使っても良いのですが、せっかくなのでorder byを使ってみます

SELECT department, COUNT(*) 
FROM students
GROUP BY department 
HAVING COUNT(*) <= 30 
ORDER BY COUNT(*) ASC

 

ちなみにこれ順番大事です笑。group byしてからhavingしてorder byしないとエラリますので気をつけましょ。上から順に読んでいくので今回だと「グループに分けて、それぞれを集計した結果を制限して最後、集計結果順に並べてみる」になります。イメージはつきやすいかなと思います。

 

 

サブクエリの説明もあったのですが、結局それはこれらの組み合わせでしかないので割愛しました!

 

今回はここまでとします。

 

軽〜い内容でした笑。 

 

 

データベース入門もあとは

・インデックスの説明

・リファクタの仕方

・実際にアプリケーションを扱うとき

トランザクションについて

この4つで本は終わりにしようかなと思います。

そのあとにrailsのときのjoinとinner_joinの違いの説明を軽くやってDB周りは一旦終えようかなと思います。(アンチパターンもやるかもですが)

 

 

GW前までには終わりそうですね、、よかった。

 

終わり。 

何をするにも目的が大事

最近全然更新していません!

 

それはなぜか、、、題目のとおり大学の友人の結婚式の余興に出るべく準備をしているからです笑。

 

婚約をした友人とは両親ぐるみでよくしてもらっていたので余興に出ないわけにはいかず。

 

結婚式を行うと言われたときから「余興に出る!」と言っていたものの余興に出るメンバーの中でそういうものを作った経験のある人はいないという状態でした。

 

それでも集まったメンバーに「一生に一度しかないものだし最高の余興にしようぜ」と言うとそれにみんな乗ってくれている。

 

良い仲間だ・・・・・

 

 

余興はぼくたち含めて3組出るらしい。

 

ぼくたちだからこそ、伝えることができることがあるし表現できることがある。

 

そんなことを軸に「どういう状態だったら最高の余興だったと言えるのか」ということからなにをしようかと余興を考えられている。

 

 

余興といえど「なにを伝えたいのか、どういう状態になったら最高といえるのか、僕たちの最終のゴールはなんなのか、そもそも余興みる人はどんなひとなんだろうか」など目的をしっかり決めてその場をリアルにイメージして考えに落とし、作業をしていく。。。

 

仕事と通ずるものを感じている今日この頃。

 

 

もうしばらく続きそうですがそれが終わったらまた技術的なことをアウトプットしていこうと思いまーす!

 

 

以上、最近の状況でした!

 

 

 

 

終わり。

 

 

 

 

reactをまだマスターしていなかった件

「え?こんな書き方あるのか、知らなかったわ〜」と思ったのでメモる笑

 

まあまずはこれですな・・・

 


 

ループ処理

配列のループ処理!意識していなかったわけではないんですけどね、、反省。。

 

forEach

連想配列(object)だと使えないんですけどね、ただ指定のarrayを回すときに使う


[1, 2, 3].forEach( (element, index, array) => {
  console.log(index + ":" + element);
});

 

indexとarrayは省略可能ですー!

 

map

新しい配列を作成したいときに使う感じですな


const elementSquareArray = [1, 2, 3].map( (element, index, array) => {
  return element * element;
});

 こちらもindexとarrayは省略可能でっす!returnで返してあげましょ!

 

filter

条件にあうものだけを抽出したいときに使います


const evenNumberArray = [1, 2, 3].filter( (element, index, array) => {
  return (element % 2 === 0);
});

 

reduce

処理をして1つの値を取得。
previousValueは前の値というより、それまでの結果と考えるとわかりやすいかもです


const total = [1,2,3].reduce( (previousValue, currentValue, index, array) => {
  return previousValue+currentValue; 
}); 
### total=6になる

 

every、some 

これ使ったことないですけど・・・

everyは条件を全ての値が満たすか、someは条件を満たすものがあるかの判定。
結果はbooleanで返ってくるらしいです 


const everyEvenFlag = [2, 4, 6].every( (element, index, array) => {
  return (element % 2 === 0);
});

 


const someEvenFlag = [1, 2, 3].some( (element, index, array) => {
  return (element % 2 === 0);
});

 


 

render

なにを返すのか問題ですね、返す型はそろえましょ!

 

はい、すみません。僕は適当にやってました・・・

 

 

何も描画したくないときにnullまたはfalseを返すことでそれを実現することができます。実際には裏で<noscript>タグを描画します。 なんでそういうときは

return <noscript/>

とするとよいかもですね

 


 

JSXのif文

jsx内のrender部分でif文書くとき即時間数を使って書くことが多いと思いますが、いかんせん括弧が多くて見にくくなってしまいます。


{(() => {
  if (this.props.count >= 3) {
  return  (componentとかviewを返す);
  }
})()}

 

 

こんなときに使える書き方があります、それがrenderのときの理論です。falseやnullのときはなにも表示されないのでそれを使うと以下になります。


{(this.props.count >= 3) && (
  return (
    componentとかviewを返す
  )
)}

 

 

見やすい!!

 

わかると思いますが、最初のif文でtrueのときの処理しか使えません。なので最初からif~elseで分けるものに対しては即時間数で書くしかありません。

 

 

 

 

 

 

 

 

 

react使って3ヶ月くらいですが、まだまだ知らないことがありそうなので詰めていきたいものです。

 

 

終わり。

 

railsとrubyの相性

rubyrailsのバージョンを上げることになったが、一つ疑問に思いました。

 

適当にどっちも手間なくあげれるとこまで上げれば良いのかな・・・??

 

ビルド時にどのくらい速度に差があるのか気になったので調べてみました。

 

 

準備

ruby 2.2.0、2.3.0、2.4.0をrbenvでインストールしておく

 

 

コード

RUBY=("2.2.0" "2.3.0" "2.4.0") 
for ruby in ${RUBY[@]}; do
  export PATH=$RBENV_ROOT/shims:$PATH
  rbenv global $ruby >/dev/null 2>&1

  RAILS_VER=("4.0.13" "4.2.8") 
  for rails_ver in ${RAILS_VER[@]}; do
    gem install rails -v $rails_ver >/dev/null 2>&1
    if test $rails_ver = '4.0.13' ; then
      gem uninstall rails -v "4.2.8" >/dev/null 2>&1
      gem uninstall railties -v "4.2.8" >/dev/null 2>&1
    else 
      gem uninstall rails -v "4.0.13" >/dev/null 2>&1
      gem uninstall railties -v "4.0.13" >/dev/null 2>&1 
    fi
    rbenv rehash
    ruby -v
    rails -v
    rails new rails_${rails_ver}_speedtest -d mysql >/dev/null 2>&1
    echo "gem 'spring'" >> ./rails_${rails_ver}_speedtest/Gemfile
    cd ./rails_${rails_ver}_speedtest
    bundle install --path vendor/bundle >/dev/null 2>&1
    bundle exec spring rails g scaffold blog title:string description:string >/dev/null 2>&1

    echo spring
    for i in {1..10};do
      bundle exec time spring rake routes | grep real
    done 2> routes.txt
    awk -f ../ave.awk routes.txt
    cd ..
    rm -rf ./rails_${rails_ver}_speedtest
  done
done

結果

f:id:katsuyukikun:20170328193006p:plain


何度もやってもこのくらいに落ち着くのでやはりビルドに差があると言ってもいいのではないでしょうか。。。ちょっと今回はしょりすぎてrake routeでやったのがセンスなかったですね笑

あと追加でrails5もやったっていうのがruby2.2.0を使っているところからバレバレですねw

 

まとめ

rubyrailsのバージョンの相性はありそう。

ただ今回rake routeでやってしまったので差があまり明確にならず。

またバージョンのどこに差があるのかというところまで調べていない。

DBの本を読み終わった後、ここについてもう一度追加調査していたいと思います。

 

 

終わり。

実装工数の見積もりの精度を高めるために

最近、長期間にわたる実装が多く、そのときに工数を見積もるの結構大変だったなと思ったのでそのときの振り返りも兼ねて書きます。

 

そもそも実装段階〜リリースするまでにやらなくはならないことは以下だと思います。

f:id:katsuyukikun:20170325112040p:plain

雑ですね・・笑。。。。まあ、いいか。

 

 

まずこのことは押さえておかないといけないなと思いました。

え?と思った方もいると思いますが、結構認識ずれます。

特にシステムに関与していない他のチーム、例えばセールスチームに共有するときなどはどこまでのフローのことを話しているのかというのをまず共有すべきだなと思います。

 

 

一旦定義を確定しておこうかなと思います。

個人的には

・見積もり・・・全タスクとその工数を洗い出すこと → 全体感、規模感を算出

・スケジュール・・・そのタスクにかかる時間を算出する

というイメージです。

 

 

ここから個人的に良かったなと思った進め方についてです。

 

  • 見えていない部分はおいといて見えている部分でまずタスク分解する

 

やることは主に2つ。

・作るべきものをタスクに分解する

・次にタスクの工数を算出する

 

これができれば良いのですが、全然先が見えなかったりするものもあります。

そのときはこれをざっくりやります。今見えている部分だけでもよいのでやるイメージです。

例えば、Aという機能を実装するときに「Aを完了するには全体としてやることはa、b、cがあるんだけど、bに関してよくわからない部分が多くそれもa次第なんだよなー」となったときはとりあえずaだけは細かくタスク分解していきます。b、cに関してはざっくり今考えられることとしてこれくらいありますくらいでよいかなと思います。そして肌感で工数をふればよいかな程度です。

 

  • 中間地点もしくは期間で区切って再度、見積もり直す期間をつくる

 

そして実際に行動に移していくのですがここでポイントがあります。それは見積もりをもう一度見直すタイミングを作ることです。

例であげたとおりb、cに関してざっくりとしか見積もってないので必然的にやることにはなるのですがそのタイミングはaのタスクを消化している途中です。一旦手を止めてでもやるべきだと思っています。

重要なのは「見えているor見える可能性があるならそこまで考えて、タスク分解してから手を動かしましょう」ということです。

 

仕事である以上、何をどのくらいの期間でやろうと思っているのかというのはすべてのチームへ説明する責任はあるのでそういった意味を含めてもやらないといけません!

 

  • ターニングポイントを意識する

 

あとは最後にスケジュールを作成するときに、スケジュールがどのくらい幅ができそうなのかとその幅のターニングポイントとなる場所を算出しておきましょ。 スケジュールの幅というのは最短期間と最長期間との差のことです。そしてそのターニングポイントとはある意味でボトルネックといってもよいかもしれません。タスク分解すると「これらをこの期日までに最低やってないと間に合わなくない?ってことは今週はここまでがmustだよね、ってことはこれが延びた時点で見直したほうがよさそうなよね」という”これが”の部分です。

 

 

 

 

 

  • 個人的感想

個人的にはこうやってやることでやるたびに精度を高められるし、共有も楽だしおそらく聞いている人たちも状況が伝わりやすいのではと思っています。

実際のリリースまで持っていくので一番難しいのはスピードと質のバランスを取ることです。良いものを最短で出せれば良いのですが、毎回そういうわけにもいかないときがあります。そういうときはどう判断するのかは結構難しいところではありますが、そういった議論が発生することを踏まえて見積もりできると良いですね。

 

 

終わり。

 

 

 

データーベース入門①

さて、宣言通り技術についてアウトプットしていこうかなと思います。

 

題材は「DBについて」です!

Webアプリケーションをずっと作ってきたのでアプリケーション周りは結構強いのですが、DB周りについてはまだまだ穴があるので今回はそこについて「理論から学ぶデーターベース実践入門」を読んで抑えていきたい思います。

 

 

まずは第一回ということでそもそものところから書いていこうと思います。

 

  • データベースとは

ここからやらなくてもいいんじゃない?と思いますが、一応やっておきます笑。

wikipediaさんに聞いてみると

データベース(英: database, DB)とは、検索や蓄積が容易にできるよう整理された情報の集まり。 通常はコンピュータによって実現されたものを指すが、紙の住所録などをデータベースと呼ぶ場合もある。 狭義には、データベース管理システム (Database Management System, DBMS) またはそれが扱う対象のことをいう。

 

つまり特定のテーマに沿ったデータを集めて効率的に管理し、使いやすくしたものと考えてもらって良いと思います。ちなみにもう少し調べてみたら実は・・・・

データベースという名称は米軍からきているらしいです。第二次大戦後の米軍が、そこにアクセスすればすべての情報が得られるように、点在していた膨大な量の資料をひとつの基地に集約して効率化を図ったらしいです。この際にデータベースという言葉が誕生したと言われているらしい・・

 

そしてそんなデータベースですが種類があります!大きく分けると以下4つに分けることができます。

 

「階層型」「ネットワーク型」「関係型」「NoSQL」

 

一つずつ説明していってもよいのですが、ちょっとそれをしちゃうと肝心の話まで届かないで終わってしまう気がするので割愛します笑

参考リンクを貼っておきますので興味のある方はこちらをどうぞ!!

 

ざっくり説明が書いてあります↓

programming-study.com

 

図がわかりやすいかもです↓

www.techscore.com

 

NoSQLについての説明あります↓

www.sejuku.net

 

 

 

業務ではSQLを使用しているのでRDBについて書いていきますー 

( ´ ▽ ` )ノ あっ「関係型」のことです。

 

 

 

SQLとは、リレーショナルデータベース(以下RDB)に対して問い合わせを行うための言語のことです。そしてSQL はリレーショナルモデルをベース設計されておりリレーショナルモデルに沿った演算が得意です。なのでSQLを理解するにはRDBについて理解しなければならないということになります。逆にいうとRDBを理解しないとSQLについて理解できたとは言えずそれは単になんとなく書けるというレベルでしかありません。

 

  • リレーショナルモデル

現実世界のデータを「リレーション」と呼ばれる概念を用いて表現するデータモデルのこと。ここで注意したいのがあくまでも、リレーショナルモデルが表すデータモデルは 設計という意味ではなく、データをどのように表現するか、という概念の話だということ。「○○という概念を使ってデータを表現してください」という決まりごとがデータモデルであり、リレーショナルモデルはその中の一つにすぎないということになります!

 

  • リレーションとは

最もよくある間違いとしてあげられていたのが、「テ ーブル同士の関係」というものです。概念にすぎないという説明をしたと思うので理解されていると思いますが、テーブル同士の関係を(ER 図などを使って)デザインするのはリレーショナルモデルではありません。SQLにおいてリレーションに相当するものは、テーブルです!

言葉だとだとわけわからないと思うのでずを載せておきます。

                        f:id:katsuyukikun:20170325022254p:plain

説明書きとしては以下でした。

リレーショナルモデルにおけるリレーションの定義のようなもので すリレーションは見出(Heading)本体(Body)のペアで構成されます。 見出しは、0でないn  属性(Attribute)集合ですこの属性、名前とデー タのペアになっています。本体、属性値集合である組、あるいは英 語うとタプル(tuple)集合です

 

タプルに含まれる属性値は、名称とデータ型が見出しで指定されたものと、それぞれ一致していなければなりません。

見出しで定義されていない属性が存在したり、逆に見出しに含まれる属性がタプルに存在していない場合は、ルール違反です。

つまりリレーションとはタプ ルの集合であり、タプルはすべて同じ n 個の属性値の集合という同じデー タ構造を持っています。図 1.1 は、リレーションをイメージ化したもの。

 

 

 

 

今回はここまでにしておこうかな・・・ここまで理解するとわかりますが、結局集合体でしかありません。だからもっと理解を深めるにはその集合体の話を知っておく必要があります。なので次はそこから始めれればなと思います。

 

終わり。

 

 

目標の立て方

気がつくと全く技術のこと書いていないので次回から技術の話をする!とまず最初に宣言しておきまする!

 

 

で、今日はTedで「死の直前に人がとる行動は3パターンに分かれる」というなんとも面白そうなテーマがあったのでそのことについて少し思ったことを書きます。

www.youtube.com

 

  • 3パターンの行動とは
  1. 宗教や文化的背景に関係なく、許しを請う
  2. 記憶への願望
  3. 魂に触れる

 

どれもドラマとかで結構見かけるシーンだなと思いますが、順に説明していきます。

・許しを請うというのは「自分の時間を自分勝手に使わずに、子どもたちや孫たちともったたくさんの時間を過ごせばよかった」というような後悔を含んだ感情のことを指します。

・記憶への願望というのは、「私を覚えていてくれる?」「「私を忘れないで」と人の心のなか、頭の中で永遠でありたいという感情のことを指します。

・魂に触れるというのは、自分の人生に意味があったのだと思いたい感情のことを指します。自分の人生を意味のないことのために無駄に費やしはしなかったということでこれは許しを請うに似て非なる感情です。

 

 

 

 

 

個人的にこういう視点からも物事を考えられると異なるものの見方ができて良いなと思いました。前回「大きな目標を持とう」と書きましたが、みんながみんな初めからそのような考えかたができるとは思いません。そもそも僕も持てないタイプだったので・・

 

僕はどちらかというと「ボトムを決める」という考え方が先行していました。「いついつまでにこれができなかったらクソだな」「〜年目でこういう扱いだったらへぼいな、かっこ悪いな」という感じです。そこからその要素を逆転させ「こういう人にならないためには何をするべきなのか」と考え、それを目標にしてました。

 

まあ何が言いたいのかというと、人は「ポジティブに未来を描いてそれを為すために行動する」と「ネガティブに未来を描いてそれにならないために行動する」の2パターンの目標の立て方のアプローチがあるのではないかということです。目標を決めることは何をおいても大事なことなのでもしまだ持ててない人、よく分からないという人は「最低ラインを決めてそれを逆転させて目標にする」というアプローチをしてみてはいかがでしょうか。

 

最後に「好きはものの上手なれ」ということわざがあるようにどうしても「興味がある、楽しい」と思って行動している人には勝てないのでだんだんポジティブな目標設定ができるようになると良いですね。

 

終わり。