ITとdesign エンジニアのブログ by エンジ庭

IT業界のトレンドなどIT分野について学んだ事を書いていきます。プログラミング技術などについて現在Qiitaメインに書いてますので、そちらを参照ください。  https://qiita.com/kota_sho

夏からエンジニア

2019-08-09

 

今夏新たな職場に転職します。

 

半年前に前職を退職し、プログラミングスクールで学習〜転職活動を経て新しい仕事を始めます。

今回は職種も変わりまた一からのスタートですが、毎日自己投資して成長していきます。

引き続きブログも書いていきます。

具体的な職務内容は書けませんが、学んだ技術についてアウトプットをしていきます。

 

ちなみに、今はデータベースやSQLなど自習中です。

また改めて、ブログにまとめます。

個人アプリまとめ

2019-07-17

 

勉強も兼ねて家計簿アプリを作りました。

細かい部分で修正が必要ですがここで一旦、個人アプリ開発に取り組んでみた感想をまとめます。

 

①よかったこと

②難しかったこと

③改善できるところ・反省点

 

概要:

アプリ内容:家計簿アプリ

使用言語・フレームワークRuby on Rails

 

①よかったこと

考える力、想像する力を鍛えられた

今回は、課題を与えられてないので何のアプリを作るのかというところから自分一人で考えました。そしてアプリに必要な機能は何か(必須なもの、応用的なもの)、それらを実装するために必要な処理の流れを考え全体の設計をしました。また、家計簿アプリは分析ツールであるため、データが非常に重要です。そのためDB設計にもかなり神経を使いました。チーム開発も勉強になりましたが、一連の処理を自分一人で考えたことは非常に鍛えられました。3ヶ月間スクールで課題に追われながら、何とかやりきったのが精一杯でしたが、個人のアプリを開発することで、いい復習にもなりましたし、少しずつ勉強したことが繋がってきています。

 

 

②難しかったこと

よかった点で、自分で考えれたということを書きましたが、同時にそれは難しいことでもありました。「自分の考えたアプリを作る」ということは自由度が高い分、何から手をつければいいかわかりませんでした。もちろん設計〜開発という流れはありますが、細かな部分をどう進めれば良いか分かりませんでした、またスクールの課題で開発したクローンサイトのように見本がないので、機能の抜け漏れもあり、手戻りも結構ありました。ゲームで例えるとオープンワールドみたいな感じですかね。自由だけど何していいか分かんないみたいな

 

また、「設計」にどれだけこだわるかという点。

自分は元々、完璧主義なところがあるので、スクールに通うにあたってそこは意識して捨てるようにしました。多分まだ残ってますが。今回の個人アプリも設計を固めてから開発始めたいという想いはありましたが、完璧主義すぎていつまでも開発が始まらないという懸念がありましたので、今回は実験的に、大まかに作って仮で開発をスタートさせてみることにしました。だいたい1週間掛けました(毎日ずっと考えてたわけではありませんが)。案の定抜け漏れ、矛盾などわんさか出てきます。

経験を積んで、設計〜開発の流れもスムーズにできるようにしていくのが1つの目標です。

 

 

③改善できるところ・反省点

バリデーション:

「月ごとカテゴリー毎に金額を計算し、合計金額を表示する」という機能をつけました。この時、データベースに値が入っていない時、ページを表示しようとしてもエラーになりますので、値が入っていない(nil)の時は、¥0を返すように設定しています。

それ以外にまだ設定していないところがいくつかあります。

・「予算設定」では何回も同じ年・月に金額を設定できてしまうので、2回目はできないようにする→「すでに設定されています」の表示や、編集ページに飛ばすなどの対策が必要。

・収入、支出入力ページで値が入力されなかった時のバリデーション。

 

データの取り方、加工のしかた:

上述の月ごとにカテゴリー毎に金額を計算し、合計金額を表示するという機能について、そのコードは修正の余地ありです。

検索結果は以下のように表示されます。

 

f:id:Arts91:20190708214210p:plain

 

そしてコードは、

def show
 
@search_year = params[:year]
@search_month = params[:month]
detail_year = @search_year
detail_month = @search_month

# 以下問題ありコード。修正を検討する
# 長すぎる
# カテゴリーIDを1つずつ取ってきているため、もしユーザーが独自にカテゴリーを追加できる機能をつける場合、対応できない
 
#収入計算
@income_detail_saraly = Income.group("YEAR(date)").group("MONTH(date)")
.where(income_categories_id: 1, user_id: current_user.id).sum(:amount)
@income_detail_saraly[[@search_year.to_i, @search_month.to_i]]
@income_detail_saraly_view = @income_detail_saraly[[@search_year.to_i,
@search_month.to_i]]
 

まず@income_detail_saralyに入っているのはデータベースの収入テーブルの給与カラムの合計金額。ここでは月ごとにハッシュ形式で取得できてますので、ページで年、月を選択すると、その対象となる期間の合計金額を表示させるという流れです。

問題はカテゴリーを一つずつ取ってきているということ。

影響1:

1カテゴリーのデータを取得するのに数行書いていますので、複数のカテゴリーについて書くとコードが非常に長くなり、見ずらくなる。いわゆるファットコード。

影響2:

1つずつコードを書いてカテゴリーのデータを取得しているということは、仮に将来、

「ユーザーが自分で好きにカテゴリーを作り追加できる」という機能を追加したいと思った時に対応できない。柔軟性に欠けます。

 

DB設計:

データベース設計もまだまだです。

例えば、家計簿アプリなので、いろんなところで日付を扱いますが、カラムの型がバラバラで、日付をもとにデータを検索する際に、いちいち日付を認識できるようにコードを書く手間が掛かりました。

@income_detail_saraly = Income.group("YEAR(date)").group("MONTH(date)")
.where(income_categories_id: 1, user_id: current_user.id).sum(:amount)
 

group.("YEAR(date)").group("MONTH(date)")と書かないと、日付がうまく認識されず検索がうまくいきません。

あとは、収入用のカテゴリーと紐付けるcategory_idカラムを作り忘れ、途中で追加しました。途中でも追加、編集はできるとは言え、最初の段階でがっちり固められるようになりたいです。

 

gitの扱い

スクール似通っていた時から、gitの作業はGUIgithub desktop)を使っていました。バージョンが古く、新しくしたかったのですがなぜか上手くいかずそのまま使いました。新しいバージョンになれるように、今からでも使いたいです。また、GUIだけでなくコマンドでも作業がスムーズにできるよう慣れていきたいです。

 

以上

情報収集

2019-07-06

 

現在転職活動中です。

転職活動にあたり技術力に加え、IT業界の情報収集にも力を入れ始めました。

日経コンピューター(雑誌)

②NewsPicks

②IT JAPAN 2019

 

IT業界の潮流を把握すべく新聞やニュースサイト、雑誌を日々眺めています。

雑誌については、ネットで調べる限りエンジニアが読むべきものとして「日経コンピューターは外せない」ということだったので、6月から読み始めることにしました。

日経コンピューターは隔週の発売なので新刊はまだ2冊しか読んでいません。

なので

 

 

 

 

 

過去半年分のバックナンバーをまとめて購入しました

f:id:Arts91:20190706210843j:plain

毎日ひたすら読んでいます。多いわ笑

 

平成発売分のもありますので「そんな記事古いぜ」と言われるかもしれませんが、

業界の流れを勉強することが目的なので、古いニュース記事も目を通します。

歴史を勉強することも大事かと(IT業界ではついこのあいだのことも古い歴史になるんでしょうか)。

 

雑誌の内容は、ニュース記事がいくつか、特集(注目の企業や話題の技術などが取り上げられています)、コラムなど。僕はニュース記事と特集には目を通し、それ以外に気になるものがあれば読みます。

視点としては「IT企業の情報」というよりか、「ITのこういう技術やシステムが様々な業界や企業、生活にこのように影響を与えている」という見方で書かれているので、身近に感じながら読めます。

最近はIT業界のみならず、最近は様々な業界がデジタル戦略に力を入れていますし、まだ5冊しか読んでませんが、「企業のDX(デジタルトランスフォーメーション)戦略」などのキーワードが多く見受けられます。(なぜXなんでしょうか?)

 

 

 

次に、

NewsPicks

有名なニュースまとめサイト(アプリ)ですが、これは、iphoneだと小さいし、パソコンも微妙なのでipadで見てます。ちょうどいいです。

いろんなサイトから引っ張ってきてるんですね。

僕は「ダイヤモンド・オンライン」とか「東洋経済オンライン」とか「日経ビジネスオンライン」とか個別に今まで見てたので、それらから記事がピックアップされているので便利です。

プレミアム会員にはなっていないので、見れない記事はコメント欄見てます。全部見れませんが、それで大体の記事の内容が推測できます笑

 

最後に、

IT JAPAN 2019が7月10日(水)〜12日(金)の3日間、品川のプリンスホテルで開催されます。日経コンピューターを読んでいたら広告があったので3日通し券をとりあえず購入しました。

様々な企業の重役の方や大学の方が講演して頂けるそうです。

テーマは「DXで挑む新時代」なので、最近の日経コンピューターで特集されている内容がメインになりそうです。

 

ちなみに一番の楽しみは、

レスリング選手の吉田沙保里さんのスペシャトークです。

 

いや、IT関係ねえー!!!笑

予算と現状のリアルタイム表示

2019-06-24

 

家計簿アプリを開発中です。

せっかくなので、搭載した機能とコードについてたまに紹介していきます。

 

機能:

・月ごとに収入予算と支出予算を設定することができる

・トップページで当月の収入予算と支出予算が表示される。

・今月のその時点での収入額、支出額が表示される。

・収入(支出)予算に対する、その時点での収入(支出)額との差が表示される

・実際の収入額ー実際の支出額で収支状況が分かる。

 

予算の設定:

設定ページでで年・月を選択し、収入予算額、支出予算額を入力するとDBのbudgetsテーブルにデータが送られます。

コントローラ:

 def new
 budget = Budget.new
 end

 def create
 @budget = Budget.create(year: budget_params[:year],month: budget_params[:month],
 income_amount: budget_params[:income_amount],
 spending_amount: budget_params[:spending_amount], user_id: current_user.id)
 end

 private
 def budget_params
 params.permit(:year, :month, :income_amount, :spending_amount)
 end

 end

 

トップページで当月の収入予算と支出予算を表示:

 def index
 @name = current_user.name
 # 今月は何月か
 time = Time.now
 this_month = time.month
 this_year = time.year
 
 # 設定した予算の今月
 @income_budget = Budget.find_by(year: this_year, month: this_month).income_amount
 @spending_budget = Budget.find_by(year: this_year, month: this_month).spending_amount
 

まず、今が何年の何月かリアルタイムで認識される必要があります。

現在、this_yearには今年("2019")が、this_monthには今月("6")が入るようになっています。それを使いbudgetsテーブルから「年」は今年「月」は今月の「(設定した)収入予算額」を条件に検索して取得します。支出予算も同様です。

取得した値をビューファイルに」渡して表示させます。

 

今月のその時点での収入額、支出額を表示:

# 今月の現在の収支状況
 
@current_income = Income.group("YEAR(date)").group("MONTH(date)").sum(:amount)
@current_income[[this_year,this_month]]
@current_income_view = @current_income[[this_year,this_month]]
 
@current_spending = Spending.group("YEAR(date)").group("MONTH(date)").sum(:amount)
@current_spending[[this_year,this_month]]
@current_spending_view = @current_spending[[this_year,this_month]]
 
end

コードが長くなってしまいました。

まず、カラムの型が予算テーブルと異なっているので検索の仕方を変えました。(DB設計は反省です)。

incomeテーブルで検索条件を「年」を今年「月」を今月とし、その対象のレコードのincome_amount(収入金額)の合計金額を取得します。この時点では{2019,6 => 300000)という形で取得できていますので、そのまま@current_spending2019,6とすれば300000が取れます。しかし、毎月リアルタイムで値を取りたいので@current_spendingthis_year,this_monthに置き換えています。こうすれば7月に入れば、自動的に7月のものをデータベースから探してきます。

ポイントは、日付を検索する際はcreated_atではなく専用で作ったdateから探してきます。なぜなら、検索対象は「入力を行った日」ではなく「入力欄に入力された日付(中身)」だからです。(カレンダーから選べるようになっています)。

例えば、6月1日に思い出して5月31日の分を入力することも考えられるため、その際齟齬が生じないよう、DB設計と検索条件を考えました。

 

・収入(支出)予算に対する、その時点での収入(支出)額との差

・実際の収入額ー実際の支出額で収支状況が表示される。

ビューファイル:

 .side-contents
 .side-contents_budget
 .side-contents_budget_income
  今月の収入予算
  = @income_budget.to_s(:delimited)
.current_income
現在の状況
= @current_income_view.to_s(:delimited)
.income_difference
差額
= (@income_budget-@current_income_view) * -1
-# 収入予算より実績が上回っていたら計算式ではマイナスだが、会計上はプラスなので*-1して反転
 
.side-conyents_budget_spending
今月の支出予算
= @spending_budget.to_s(:delimited)
.current_spending
現在の状況
= @current_spending_view.to_s(:delimited)
.spending_difference
差額
= @spending_budget-@current_spending_view
.total
収支
= @current_income_view - @current_spending_view
円(今月の収入額-今月の支出額状況)
 


 
デザインはまだ仮置きなのでhamlは簡易的ですが、ここではただ四則演算で差額を計算しています。収入予算に対する、実際の収入額は予算を超えていれば計算上マイナスになるますが会計上はプラスなので*(-1)してプラスとマイナスを反転させています。
(まあ反対に実際額から予算を引いても同じことですが...)

家計簿アプリ!!

2019-06-23

 

プログラミングスクールのカリキュラムを修了し、就職活動も徐々に始めていますが、同時に勉強も兼ねて個人的にアプリを開発中です。

今回は家計簿アプリに挑戦です。

アプリ:家計簿アプリ

 

なぜ家計簿か:

・金融に興味があったから。

・プログラミング開発の流れを理解するのに丁度良いかなとなんとなく思ったから。

 

目的:カリキュラムが一通り終わったので、復習を兼ねプログラミング開発の流れをより理解するため。早めに完成させたいですが、優先度としては、理解をしながら、新しいことも勉強しながら、調べる力を身につけながらやってみることに重きを置いています。遠回りしてんなと思う時もありますが、きっと将来に役立つ・・・はず!

 

主な機能:

・新規登録、ログインができる

・収入・支出を日別、カテゴリー別に入力し保存

・月毎に予算を設定できる

・トップページには、当月の収入予算と支出予算、及びその日時点での収入と支出額が自動で表示されその差額が分かる。

・年と月を選択するとカテゴリー毎の金額と全体における割合、そして月の合計額が分かる。

応用として上記以外にも便利な機能を付けてみたいですが、まず基本的な機能の完成を目指しています。

 

今回の個人アプリは想像以上に身になっています。

理由:

・自分でどのようなアプリを作るかというところから構想する。

・アプリに必要な機能、処理の流れ、設計など一連を自分で考える。

・カリキュラムにない部分を自分で調べるため、調べる力がつく。

・考えても、調べても試行錯誤しても分からない時は、某WEBサイトで質問してみる。

その際、全く知らない、アプリの背景も分からない方々に質問するので、どのようにしたら質問の意図が分かりやすく伝わるか一旦自分自身でまとめる。

など

まとめると「自分の頭で考える」というのが一番です。

 

難しさ:

(進め方)

アプリを開発する上では、アプリの機能、構成、処理の流れ、またDB設計を事前に固める必要はあると思いますが、自分はもともと完璧主義者なので、作業を始めるまで時間が掛かりそうでした。いつまでたっても始められないと思い、一旦仮で設計を固めましたが、案の定進めていくにつれ「やっぱり、あーしたほうがいい」とか「あれが必要だから急遽追加、あれは不要」などスムーズとは言えない状況です。ただ、カリキュラムに沿って進めるのではなく、自分の頭で考えるのは、今まで学んだ知識、考え方を整理し、総動員する必要があるのでかなり充実しています。実践に近ずけるためTrelloも作って用意しましたが、最近は全然見てないです笑 いつの間にか無視です。

 

(実装)

家計簿アプリはSNSアプリなどと違い「分析」をすることが機能の主な役割なので、結構ややこしいです。ほとんどの機能ではデータを加工し扱います。

月毎、日毎、カテゴリーごとの収支、前月比、設定した予算に対しての実際の収支とその差、各カテゴリーの全体の中での割合などなど。当然機能ごとに必要なデータの抽出条件は変わってきますので、その都度、条件を組み合わせながらDBからデータを取得する必要があります。なので、SQLやActive Recordなんかはかなり調べたりしながら進めています。予想以上に入り組んでいるなというのが実感です。ナメてました。

例えば、今月の現時点での収入状況をDBから取得する際、

「今月が何月かをリアルタイムで認識させる」

「dateカラムの年ー月ー日から年と月のみを抽出し検索条件とする」

「検索にマッチするレコードのincome_amount(収入金額)カラムの金額を全て足し合わせる」

 

今の所うまく取得できてません。

 
 def index
 @name = current_user.name
 # 今月は何月か
 time = Time.now
 this_month = time.month
 this_year = time.year
 
 # 設定した予算の今月分
 @income_budget = Budget.find_by(year: this_year,month: this_month).income_amount
 @spending_budget = Budget.find_by(year: this_year,month: this_month).spending_amount
 
 # 今月の現在の収支状況
 @current_income = Income.group("YEAR(date)").group("MONTH(date)")
 .select(date: this_month).sum(:amount)
 @current_spending = Spending.group("YEAR(date)").group("MONTH(date)")
 .select(date: this_month).sum(:amount)  

 # binding.pry
 end
 
 
 
結果

[1] pry(#<BooksController>)> @current_income

=> {[20195]=>150000, [20196]=>1165000}

6月の合計取れてんじゃんと思ったら、5月もきてました。呼んでねーんだよ5月。御呼びでないんすよ。

 

引き続き頑張ります。

SQL

2019-06-06

 

今回はSQLについて書いていきます。

SQLとはStructured Query Languageの略で、リレーショナルデータベース管理システムと対話をするための言語です。

つまり、データベースに対し、〇〇というデータを追加してほしい、〇〇のデータについて検索したいという要求を出します。この要求をクエリ(問い合わせ)と言います。

 

では、リレーショナルデータベースとは何なのか。

データベースにはいくつかの種類があります。

階層型、ネットワーク型、リレーショナル型などです。

リレーショナルデータベースでは、データを表形式で管理します。そしていくつかの表(テーブル)同士を関連づけて管理することができます。

例えば、以下はある学校についてのデータベースですが、生徒テーブルは、生徒は全員どこかしらのクラスに所属していると見て取れます。教師テーブルには各教師がどのクラスを担当しているかわかります。つまり、2つのテーブルを関連づければ,

各生徒の担任が誰であるのかが分かります。

 

生徒

ID

名前

所属クラス

1

山田

A

2

佐藤

C

3

鈴木

D

4

加藤

B

 

教師

ID

クラス

担任クラス

1

A

小川

2

B

大野

3

C

石川

 

SQLに話を戻しますが、SQLはこれらデータに対し、様々な指示、要求を出すことができる言語です。

例えば、以下のようなものです。

 

〜基本〜

・データの取得

 

f:id:Arts91:20190606233358p:plain

・データの追加

f:id:Arts91:20190606233419p:plain

・データの更新

f:id:Arts91:20190606233427p:plain

・データの削除

f:id:Arts91:20190606233436p:plain

〜検索〜

・AND

f:id:Arts91:20190606233445p:plain

・OR

f:id:Arts91:20190606233456p:plain

 

算子 意味
= 左右の値が等しい
+ 左辺は右辺より小さい
< 左辺は右辺より大きい
> 左辺は右辺の値以下
<= 左辺は右辺の値以下
>= 左辺は右辺の値以上
<> 左右の値が等

f:id:Arts91:20190606233934p:plain

・NULL判定

f:id:Arts91:20190606233946p:plain

・LIKE分

f:id:Arts91:20190606234006p:plain

パンくずリスト

2019-06-03

 

最終課題メルカリのクローンサイトで実装したパンくずリストについて紹介します。

 

パンくずはページの階層が深くなった際に、今どこのページにいるのか視覚的にわかりやすくします。

 

下記実際に実装したページですが、メルカリのマイページに入り、その中のプロフィール画面にいることが視覚的にわかります。

 

f:id:Arts91:20190603104802p:plain

 

実装の流れ

①gretelというgemをインストール

(gemfileに追記し、bundle install)

 

②gretelの設定ファイル config/breadcrumbs.rbを作成

(bundle exec rails g enerate gretel:install)

 

③config/breadcrumbs.rbに各ビューページに表示させたいパンくずを設定

 

f:id:Arts91:20190603105723p:plain

メルカリ>マイページ>プロフィールを例に説明します。

まず「マイページ」について、

・crumb :show doでどのビューファイルに対し設定するのか書きます。「マイページ」はusers/show.html.hamlなのでshowです。

・link" "ではページに表示させたいパンくずの表示名を書きます。

・〜_pathでパスつまりルーティングの経路を書きます。「マイページ」はroot(トップページ)から入るので root_pathになります。

・parent : 〜 は親ページ(1つ前のページ)なので同じくrootです。

 

同じように

プロフィールはedit.html.hamlに設定し、表示は「プロフィール」(全ての経路を書く必要はありません。そのページの呼び名のみでOK)にします。パスはusers/editなのでusers_path, 親はshowなのでparent: showです。

 

④各ビューファイルに設定する。

下記はプロフィールページのファイルです。

f:id:Arts91:20190603111307p:plain