個人アプリ開発日記 #1

先日から個人アプリを開発し始めました。

 

今回の開発環境

■言語

html(haml),CSS(Sass),Ruby( 2.5.1)

フレームワーク

Rails 5.2.3

■DB

MySQL

■本番環境

AWS EC2

こんな感じで作成しています。

 

前回開発した開発は

Rails 5.0.7.2での開発だったのでそこが少し違うと言う状態

 

今回のアプロは私自身以前から作りたいアプリで

しっかりとリリースして

みなさんに使ってもらい、生きたアプリにしたいと思っています。

 

ですので

現場に入ってもこのアプリをしっかりと作り込んだり

いろんな人が使うようになった時にインフラ周りの知識が必要になってくるので

今後ではあるが、勉強が必要だなと思う。

 

まずは動くものを作成し、

実際に使ってもらっていいものにしたいと思う。

 

ビジョンはこんな感じではあるが。

 

技術面においては

今回絶対に入れたいのは

 

「テストコード」

 

以前に作成した共同開発のアプリは

時間が足らずテストコードを実装することができなかった。

 

世間ではスマホ決済戦国時代なって

様々な企業が一斉に参入しているが

セキュリティー面を不安視するの声もよく聞く。

 

「まずは動くもの!」というのは

大事だともうが

 

大前提で安全なものというのは当たり前ですので

しっかりといろんな方が使ってくれることを意識して

開発を進めて行こうと思います。

 

 

 

 

【名古屋Ruby会議に参加しての感想】

こんにちは、

始めめましてMasaです。

 

先日名古屋Ruby会議というイベントに参加してきました

このイベントは割と有名なのかな?

 

よくわからないですが

名古屋で勉強会自体が少ないので

知って速攻参加申し込みをしました

(東京の人たちが羨ましい・・・)

f:id:masataka_sugita:20190610212511p:plain

名古屋Ruby会議

会場の人数は約100名

歌舞伎とかをする会場で不思議な雰囲気でした。

f:id:masataka_sugita:20190610212644j:plain

会場雰囲気

年配の方々が多いイメージを受けて

「偉大な先輩方がいっぱいおられる!!」

 

とテンション上がりました笑

 

感想

 

いろんな方の話を聞いて

もう本当に何がなんだかわからなくて

「これってRubyなの?」

と目が点になってしました。

 

話を聞きながらひたすら

ググりまくりながらなんとかついて行こうとしましたが

今の僕には到底追いつけるわけもなく

 

「(チーン・・・) 」

 

ruby勉強し始めて2ヶ月満たない時期には早すぎたのかもしれませんね^^;;

(今まで勉強してきたことほとんど出てこなかった・・)

 

早く東京に出て自分にあった勉強会に参加して

ステップアップしたいですね。。

 

いつかこういうガチ?のイベントの話を納得して

一緒に楽しめるようになりたいですね。

 

もっと頑張ります。

 

本日の学習時間10時間

 

最後まで読んで頂きありがとうございした。

 

PAY.JP導入。単体テスト勉強。

こんにちは、

初めましてMasaです。

 

今日はクレジット決済を実現するにあたり

PAY.JPを導入しました。

 

導入の仕方は初めはわけわからなかったですが

公式リファレンス、Qittaを読み解いて

少しずつ点が出来上がり

点が繋がりようやく線になり一気に進みました。

 

公式リファレンスを読むのは本当に大事だなと思いました

というのも

Qiitaに書いてあることは簡潔に書いてあって

わかりやすいのですが

他の記事と書いてあることが違ったり

細かいところまでは書いてないので

 

何かあったら公式見るのは大事だなと思いました。

 

と言いつつ

いつもQiitaに助けられてるのも確かですけど。^^;

 

Qiitaにわかりやすい記事をあげてくださってる先輩方には頭があがりません。。

 

テストコード

 

PAY.JPど導入して今はテストコード学んでいます。

 

スクールの弱点として

テストコードについてあまり深くカリキュラムが作られていないという現状で

僕を含めてチームメンバー全員テストコードを書くことができません。

 

実際の現場では確実にテストは求められるらしいので

進捗から少し外れてしまいますが

しっかりとテストコードかけるようにし、

メンバーにアウトプットをして行こうと思います。

(いつも助けてもらってるので・・・^^;)

 

噂ではテストコード書くの楽しいと聞いたことがあるので

楽しさ見つけれるまでやってみます。

 

本日の学習時間12時間

 

最後まで読んでいただきありがとうございました。

 

リアルタイムで閃いた。笑 PAY.JP導入準備。チームメンバーのコード改善。【サプライズ神回】

こんにちは、

初めましてMasaです。

 

今回記事を書いてる途中でアイデアを閃いて

貴重な修正する過程を残せたので

楽しんでいただけるかなと思います。

最後まで読んでいただけたら幸いです^^/

 

今日はクレジットカード決済を実現させるために

PAY.JPの導入に取り掛かりました。

 

まずはマークアップから

■本家

f:id:masataka_sugita:20190603200606p:plain

本家view

 ■今回作成したもの↓

f:id:masataka_sugita:20190603200716p:plain

今回作成したview

いい感じでできたんじゃないかなと思いっています。

 

楽しかった点

・今回自分なりに楽しかったなと思うところは

selectのプルダウンメニューの改善です。

 

チームのメンバーの一人が以前作成してくれた

 

selectのプルダウンメニューは

f:id:masataka_sugita:20190603201214p:plain

改善前のselectのコード

上記のコードで「おお〜」って思いましたが

実際に表示される桁数が01から表示されていないという問題がありました。

おそらく期待している挙動としては

[01.02.03.04.05.06.07.08.09.10.11.12]

だと思うのですが

表示される表示は

[1.2.3.4.5.6.7.8.9.10.11.12]

このように桁数が省略されていました。

 

別にこのままでの問題ないかなーと思いましたが

ちょうど僕が実現したかった処理が

f:id:masataka_sugita:20190603201744p:plain

狙いの処理

↑こちらのコード。

記事:https://qiita.com/takachan_coding/items/f7e70794b9ca03b559dd

 

本家も01からカウントされててせっかくなら動的な動きも完コピしたいな。。

ということで

 

修正を加えてみたコードがこちらになります。↓

f:id:masataka_sugita:20190603202221p:plain

修正後のコード

桁数の0埋めは初めてのことで困惑しましたが

何とか実現させることができました。

 

ですが・・・

 

画像下の

%select{name: "year", class: "select--item"}
= (19..29).each do |year|
- full_year = "20" + year.to_s
%option{value: full_year}
= year

 こちらのコードに関して今だにモヤモヤしているのは

べた書きで

19..29と書いてしまっていることです。

 

というのも

2020年になったらどうするの?問題です。

 

明らかに時間の変化に弱いコードになってしまっていますね・・・^^;

 

調べて

f:id:masataka_sugita:20190603202953p:plain

ここまで辿りつきましたが

その先にどうしたらいいのか・・・

というところでいきず増しました。

 

その時に頭の中でぐるぐるした考えとして

・年を取得する処理を コントローラに書こうか

・モデルに書こうか

・そういえばモデルとビューの関係性ってどんな関係だっけ?

・モデルで定義した変数ってviewで使えるっけ?

 

あ、今書いてて思いついたことが一つ出たのでやって見ます。

コントローラーで処理の返り値として

現在の年を取得して10を加えてたものを配列として吐き出させて

@arrayとしてインスタンス変数にしてそれをviewでeachで回してみます

 

やって見ます!!

できました笑

(まじでやってました笑)

 

今書いたコードはこちら!

 

■コントローラー

f:id:masataka_sugita:20190603210628p:plain

newアクション部分

■view

f:id:masataka_sugita:20190603210721p:plain

viewに@インスタンス変数array

感動。。

 

まさか記事で振り返りしてる時に

思いつくとは^^;

(記事書いててよかった)

 

今回のコードで2099年までは何とか耐えれそうです笑

 

補修性、変化に強いコードを書くというのは

最近自分の中で大切にしていることなので今回それを実現できてよかったです。

 

本日の勉強時間11時間。

 

長くなってしまいましたが、

最後まで読んでいただきありがとうございました。

 

今回お世話になった記事一覧:

http://cameong.hatenablog.com/entry/20120806/1344271504

https://qiita.com/takachan_coding/items/f7e70794b9ca03b559dd

https://www.javadrive.jp/ruby/date_class/index3.html

カテゴリ機能への仮説全否定。クレジット決済の導入

んにちは、

初めまして、Masaです。

 

ゴリゴリ開発できるエンジニアになるベク

今日もコツコツやっております。

 

先日からずっと戦ってきたカテゴリ機能のことについてです。

 

f:id:masataka_sugita:20190529211317p:plain

f:id:masataka_sugita:20190602203539p:plain




中身がこんな感じで

同じ繰り返しで、DBから引っ張ってきた要素分eachで回すのだろう

とざっくりとした自分の中で仮説を立てました。

 

その仮説を元に実装に入りました

実装することで仮説の解像度が高まり仮説のボロが出てきた。。

 

初めの仮説ではeach文の中にeach文を入れて回そうと考えていました。

 

f:id:masataka_sugita:20190602204551p:plain

f:id:masataka_sugita:20190602204608p:plain

こんな感じでeachの挙動を確認し、

いざ取り掛かろうとしたところ、

回せないことに気がつきました。

 

中身の、子。孫。が何度も回ってしまうと気づきました。

 

調べても直書きする方法しか出てこず

この時点で仮説が破綻しました。

 

おそらくhoverした際に

そのカテゴリの下層カテゴリを引っ張って来なければならない。

裏で紐ずけて表にだす。こんなような処理が正しいのかなと・・・

 

しかし。

 

具体的な実装方法が浮かばず、

チーム開発の進捗に影響が出ると判断し、

チーム開発での必須機能を作りあげた後に

取り掛かろうと思います。

 

今作っている機能は

クレジットカード決済の導入です。

 

PAY.JPというもので導入できるらしいが

https://pay.jp/docs/cardtoken

個人情報を扱う機能なので慎重に行いつつ

外部の機能を使わせていただく分

自分の知らない分野で処理が行われるので

何か不具合が行なっても対処できるようにしていきます。

 

コツコツ頑張ります。

 

本日の学習時間12時間。

 

最後まで読んでいただきあるがとうございました。

カテゴリ投下完了!gemの取り扱いには注意が必要!初Qiita執筆!

こんにちは、

初めましてMasaです。

 

やっとカテゴリテーブルにデータを投下することができました。

f:id:masataka_sugita:20190601204112p:plain

カテゴリテーブル

親カテゴリ、子カテゴリ、孫カテゴリしっかりと関連が取れていて

いい感じに出来上がりました。

 

gem万歳!

ancestry万歳!

 

と思っていましたが

 

親要素が取り出せない。。

github(https://github.com/stefankroes/ancestry)見る限り便利そうないろんなメソッドがあって

親要素を取り出せそうな雰囲気だあったので

ancestryの少ない情報量を片っ端から見て試して見たが取れるメソッドがなかった。。

 

テーブル見たら親カテが何かわかるし

idで番号を指定してやれば簡単に取れる。

 

が、

 

それでは変化に弱いものになってしまう。

・もし親カテゴリは増えたら?

・もし親カテゴリが減ったら?

 

という変化に対応させるには

idで持ってくるのではなく、

「親カテゴリ!」

として引っ張るメソッドを見つけなければ!!

そうしなければチームのメンバー全員の機能が満たせれなくなるかもと

いう危機感(gemを導入した責任)で奮闘、悩みまくってました。

 

メンバーに相談したら解決方法が見つかった。

 

親カテゴリのancestryカラムはNULLとなっているのでそれを利用したらいいのでは?

 

やってみた。

f:id:masataka_sugita:20190601210608p:plain

⬆︎ダメだった

 

f:id:masataka_sugita:20190601210644p:plain

⬆︎これもダメだった

 

f:id:masataka_sugita:20190601210815p:plain

⬆︎取れた!!

 

今までの知識で全然いけた・・・泣

gemのメソッドにとらわれすぎは良くないですね^^;

 

そしてこれにきづかせてくれたメンバーに感謝です。。

 

と、ここまででやっっとカテゴリ機能の下準備が終わったので

チームメンバーにカテゴリテーブルを使ってもらいつつ

 

明日はこの取得した親のレコードたちを使って子カテ、孫カテを引っ張って

viewに反映させてカテゴリ機能を実現させていきたいと思います。

 

本日の作業時間12.5時間

・qiita記事執筆

・カテゴリデータの投下

・ancestryについての理解

・フロントへの考察

・Web業界調べ

書いた記事

https://qiita.com/Masataka_Sugi/items/2a9d5de1ba119c1f6da2

最後まで読んでいただきありがとうございました!

 

チーム開発6日目 カテゴリデータ投下地獄 ~メソッド組む難しさ~ / gem 「ancestry」導入

こんにちは、

初めましてMasaです。

 

チーム開発6日目

カテゴリデータの投下

 

昨日に引き続き本日も

カテゴリ機能の、下準備。

 

というのもカテゴリは製作者側が提供しなければならないので

seed.rbにデータを書き込んで入れなければならない。

 

数百あるカテゴリを

階層構造で紐づけて書かなければなカテゴリとしての機能を持たない

そこで色々調べて

テーブルの構造に

経路列挙モデルというのを採用してみた

ancestryというgemが便利で

この記事と

https://qiita.com/NAKANO_Akihito/items/d42a6ceae40933af2352

この記事を

https://qiita.com/Sotq_17/items/120256209993fb05ebac

参考に導入してみた。

githubはこちら

https://github.com/stefankroes/ancestry

 

うまいこと使えて

f:id:masataka_sugita:20190530213340p:plain

このように投下できた

f:id:masataka_sugita:20190530213533p:plain

このコードで

f:id:masataka_sugita:20190530213627p:plain

これが再現できて

「いい感じ!もしかしてこれが保守性か?メンテナンスのしやすさか!?」

と思っのもつかの間・・・

 

子カテゴリどうするんや・・・汗

子カテゴリをテーブルに投下するに必要な要素として

f:id:masataka_sugita:20190530214547p:plain

・親投下した際の変数(上で言うlady)

・投下物(上で言うトップスとか)

 

これが親カテ×子カテ分ある

さすがにベタガキは非効率だなと思い

 

メソッドを組んでみたが

これが難しい。。。

引数に色々持って来なければならなくて

each文で回すにも限界があった

 

無理くりメソッド組んで引数私まくって条件分岐しまくればなんとかして

できるかもしれなかったが

とてもじゃないが解読できたもんではない・・

他の人からみて絶対に解読できない

明日になったら自分でも解読できないのではないか

 

そもそも

子カテでそれなら孫カテはどうなるんだ・・・

と思い無理にメソッドを組むのはやめて

めんどくさいがメソッドより見やすいベタガキを選んだ。

 

悔しかった。

結局負けてしまったが

自分でメソッドを考えて

デバッグして色々思考錯誤する過程は本当に楽しいかった

本家であるメルカリは絶対にいい感じのメソッドを組んで

追加でカテゴリが増えても大丈夫なようになっているはずと思うので

 

今回のこのカテゴリの初期データ投入は頭の片隅に置いていいて

これからスキルアップしていつかリベンジする。

 

本日の学習時間10時間。

明日は予定があるので作業できるかわからないが

隙間時間に業界のこと会社のことなどを調べ

 

就活の準備をしていこうと思ういます

 

最後まで読んでいただきありがとうございました!