GWにやることメモ
GWにやることをリストアップしていこうと思います。
それについて記事書いていこうかな。
1 railsのバージョンをupdateするときの進め方と実際の作業の仕方(5/3)
2 android入門(5/4)
3 docker入門(5/5)
4 Go入門(5/6)
5 速度改善(5/7)
6 機械学習入門(5/???)
6 IoT入門(5/???)
7 AWS CodeStar触ってみる(5/???)
8 AWS Athenar触ってみる(5/???)
あれ???5日間しかないのに8項目ある、、、
あと別途、技術だけではなく事業的なことも考えていくために本読んだりしたいな。
とりあえずGWは予定は一切何も入れなかったので、技術的なことでやりたいことやっていこうかなと思います笑
皆さんもGW入る前に計画立てて、日々有意義なものにしていきたいですね!
終わり。
データベース入門②
もうすぐ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の相性
rubyとrailsのバージョンを上げることになったが、一つ疑問に思いました。
適当にどっちも手間なくあげれるとこまで上げれば良いのかな・・・??
ビルド時にどのくらい速度に差があるのか気になったので調べてみました。
準備
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
結果
何度もやってもこのくらいに落ち着くのでやはりビルドに差があると言ってもいいのではないでしょうか。。。ちょっと今回はしょりすぎてrake routeでやったのがセンスなかったですね笑
あと追加でrails5もやったっていうのがruby2.2.0を使っているところからバレバレですねw
まとめ
ただ今回rake routeでやってしまったので差があまり明確にならず。
またバージョンのどこに差があるのかというところまで調べていない。
DBの本を読み終わった後、ここについてもう一度追加調査していたいと思います。
終わり。
実装工数の見積もりの精度を高めるために
最近、長期間にわたる実装が多く、そのときに工数を見積もるの結構大変だったなと思ったのでそのときの振り返りも兼ねて書きます。
そもそも実装段階〜リリースするまでにやらなくはならないことは以下だと思います。
雑ですね・・笑。。。。まあ、いいか。
まずこのことは押さえておかないといけないなと思いました。
え?と思った方もいると思いますが、結構認識ずれます。
特にシステムに関与していない他のチーム、例えばセールスチームに共有するときなどはどこまでのフローのことを話しているのかというのをまず共有すべきだなと思います。
一旦定義を確定しておこうかなと思います。
個人的には
・見積もり・・・全タスクとその工数を洗い出すこと → 全体感、規模感を算出
・スケジュール・・・そのタスクにかかる時間を算出する
というイメージです。
ここから個人的に良かったなと思った進め方についてです。
- 見えていない部分はおいといて見えている部分でまずタスク分解する
やることは主に2つ。
・作るべきものをタスクに分解する
・次にタスクの工数を算出する
これができれば良いのですが、全然先が見えなかったりするものもあります。
そのときはこれをざっくりやります。今見えている部分だけでもよいのでやるイメージです。
例えば、Aという機能を実装するときに「Aを完了するには全体としてやることはa、b、cがあるんだけど、bに関してよくわからない部分が多くそれもa次第なんだよなー」となったときはとりあえずaだけは細かくタスク分解していきます。b、cに関してはざっくり今考えられることとしてこれくらいありますくらいでよいかなと思います。そして肌感で工数をふればよいかな程度です。
- 中間地点もしくは期間で区切って再度、見積もり直す期間をつくる
そして実際に行動に移していくのですがここでポイントがあります。それは見積もりをもう一度見直すタイミングを作ることです。
例であげたとおりb、cに関してざっくりとしか見積もってないので必然的にやることにはなるのですがそのタイミングはaのタスクを消化している途中です。一旦手を止めてでもやるべきだと思っています。
重要なのは「見えているor見える可能性があるならそこまで考えて、タスク分解してから手を動かしましょう」ということです。
仕事である以上、何をどのくらいの期間でやろうと思っているのかというのはすべてのチームへ説明する責任はあるのでそういった意味を含めてもやらないといけません!
- ターニングポイントを意識する
あとは最後にスケジュールを作成するときに、スケジュールがどのくらい幅ができそうなのかとその幅のターニングポイントとなる場所を算出しておきましょ。 スケジュールの幅というのは最短期間と最長期間との差のことです。そしてそのターニングポイントとはある意味でボトルネックといってもよいかもしれません。タスク分解すると「これらをこの期日までに最低やってないと間に合わなくない?ってことは今週はここまでがmustだよね、ってことはこれが延びた時点で見直したほうがよさそうなよね」という”これが”の部分です。
- 個人的感想
個人的にはこうやってやることでやるたびに精度を高められるし、共有も楽だしおそらく聞いている人たちも状況が伝わりやすいのではと思っています。
実際のリリースまで持っていくので一番難しいのはスピードと質のバランスを取ることです。良いものを最短で出せれば良いのですが、毎回そういうわけにもいかないときがあります。そういうときはどう判断するのかは結構難しいところではありますが、そういった議論が発生することを踏まえて見積もりできると良いですね。
終わり。
アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?
- 作者: Mike Cohn
- 出版社/メーカー: マイナビ出版
- 発売日: 2009/01/29
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
データーベース入門①
さて、宣言通り技術についてアウトプットしていこうかなと思います。
題材は「DBについて」です!
Webアプリケーションをずっと作ってきたのでアプリケーション周りは結構強いのですが、DB周りについてはまだまだ穴があるので今回はそこについて「理論から学ぶデーターベース実践入門」を読んで抑えていきたい思います。
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)
- 作者: 奥野幹也
- 出版社/メーカー: 技術評論社
- 発売日: 2015/03/10
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (18件) を見る
まずは第一回ということでそもそものところから書いていこうと思います。
- データベースとは
ここからやらなくてもいいんじゃない?と思いますが、一応やっておきます笑。
wikipediaさんに聞いてみると
データベース(英: database, DB)とは、検索や蓄積が容易にできるよう整理された情報の集まり。 通常はコンピュータによって実現されたものを指すが、紙の住所録などをデータベースと呼ぶ場合もある。 狭義には、データベース管理システム (Database Management System, DBMS) またはそれが扱う対象のことをいう。
つまり特定のテーマに沿ったデータを集めて効率的に管理し、使いやすくしたものと考えてもらって良いと思います。ちなみにもう少し調べてみたら実は・・・・
データベースという名称は米軍からきているらしいです。第二次大戦後の米軍が、そこにアクセスすればすべての情報が得られるように、点在していた膨大な量の資料をひとつの基地に集約して効率化を図ったらしいです。この際にデータベースという言葉が誕生したと言われているらしい・・
そしてそんなデータベースですが種類があります!大きく分けると以下4つに分けることができます。
「階層型」「ネットワーク型」「関係型」「NoSQL」
一つずつ説明していってもよいのですが、ちょっとそれをしちゃうと肝心の話まで届かないで終わってしまう気がするので割愛します笑
参考リンクを貼っておきますので興味のある方はこちらをどうぞ!!
ざっくり説明が書いてあります↓
図がわかりやすいかもです↓
NoSQLについての説明あります↓
業務ではSQLを使用しているのでRDBについて書いていきますー
( ´ ▽ ` )ノ あっ「関係型」のことです。
- SQLとは
SQLとは、リレーショナルデータベース(以下RDB)に対して問い合わせを行うための言語のことです。そしてSQL はリレーショナルモデルをベース設計されておりリレーショナルモデルに沿った演算が得意です。なのでSQLを理解するにはRDBについて理解しなければならないということになります。逆にいうとRDBを理解しないとSQLについて理解できたとは言えずそれは単になんとなく書けるというレベルでしかありません。
- リレーショナルモデル
現実世界のデータを「リレーション」と呼ばれる概念を用いて表現するデータモデルのこと。ここで注意したいのがあくまでも、リレーショナルモデルが表すデータモデルは 設計という意味ではなく、データをどのように表現するか、という概念の話だということ。「○○という概念を使ってデータを表現してください」という決まりごとがデータモデルであり、リレーショナルモデルはその中の一つにすぎないということになります!
- リレーションとは
最もよくある間違いとしてあげられていたのが、「テ ーブル同士の関係」というものです。概念にすぎないという説明をしたと思うので理解されていると思いますが、テーブル同士の関係を(ER 図などを使って)デザインするのはリレーショナルモデルではありません。SQLにおいてリレーションに相当するものは、テーブルです!
言葉だとだとわけわからないと思うのでずを載せておきます。
説明書きとしては以下でした。
リレーショナルモデルにおけるリレーションの定義は次のようなもので す。リレーションは見出し(Heading)と本体(Body)のペアで構成されます。 見出しは、0でないn 個 の属性(Attribute)の集合です。この属性は、名前とデー タ型のペアになっています。本体は、属性値の集合である組、あるいは英 語で言うとタプル(tuple)の集合です。
タプルに含まれる属性値は、名称とデータ型が見出しで指定されたものと、それぞれ一致していなければなりません。
見出しで定義されていない属性が存在したり、逆に見出しに含まれる属性がタプルに存在していない場合は、ルール違反です。
つまりリレーションとはタプ ルの集合であり、タプルはすべて同じ n 個の属性値の集合という同じデー タ構造を持っています。図 1.1 は、リレーションをイメージ化したもの。
今回はここまでにしておこうかな・・・ここまで理解するとわかりますが、結局集合体でしかありません。だからもっと理解を深めるにはその集合体の話を知っておく必要があります。なので次はそこから始めれればなと思います。
終わり。