アラフォーがお金持ちになるためプログラマ目指すブログ

お金も根性も学歴もないアラフォーまきのがエンジニア…じゃない、プログラマになってお金持ち目指すよ!

侍エンジニア塾 22回目の授業

どうも、アラフォーまきのです。


今日は、先々週の金曜日お休みしたので、その分の授業をお願いしていました。


今日は時間制限があったので、やったことは少ないんだけれども、
何はともあれ記録しておきましょう。

今日までにやっておいたこと


Herokuへデプロイしたアプリが、開発環境の時と同じように動くように微調整をしてました。





とはいえ、自分で直せたのは1つくらい。





直せたって言っても、前回の授業でメンターさんに教わりながらやった時と同じエラーだったからできただけで、
正直自力で解決したとはいえない。





他にも大きな山が2つあって、1つはいいところまでバグを追い詰められたけれど、
解決方法がわからず1日潰しちゃったので、翌日メンターさんにSlackでご指導いただきながら、
やっと解決まで行ったという。




もう一つは残念ながら解決できず、今日の授業で教わって解決までこぎつけました。





実は先日、ゲスエンジニアのとださんがYouTubeにあげてた動画で

「自分でなんとかできそうなヤツ感が重要」

って話をみたんですよ。





これ以来、なんとか自分でエラー潰して解決したい!という欲が湧いたんですけど…。




簡単にはいかないってのが私の実際;





とださんすごい。
だって独学だったっていってましたよ。
すごいな。私ももっとがんばらなきゃ。




本日の授業

1:山くずし

さて、そういうわけでまず大きな山2つめを崩すことから入りました。




結論を先にいうと「Turbolinks」の仕業だった…。






まって。






Turbolinksってなに?





Turbolinksを全く知らなかったまきの。




メンターさんに色々教わったところ、
turbolinksさんは自ドメインのリンクの中身を先読みして、
クリックされたときにサクサク表示できるように準備しておいてくれるのだそう。





これは、画面遷移するWEBサイトの画面描画をサクサクにするために作られたものらしい。





でも、最近はシングルページのwebサービスが増えてるそうで。





シングルページのwebサービスだと、ページ遷移はせず、
部分的にデーターを更新するから、
その関係でうまくいかなくなるパターンが結構あるらしい。





私の場合、ajaxを使って画面遷移せずに一部分の表示だけ更新する部分があった。




そして、Rails4からturbolinksさんが正式採用されていたから、
なんもしなくても最初からRailsに入ってる。





というわけで、

「なんかうまく動かない」
「変な動作してる」

という状況が発生していたのでした。





今Herokuにデプロイされているんですけど、
もちろんその前に一通りローカルで動作を確認したんですよ?




そのときはこういう怪しい動作はなかったと思うんですが、実際にもう一度ローカルで動かしたら、
見事に同じ箇所で同じヘンテコ動作が。



悔しいw




あと、これ雛形データだから、
この後本番用のちゃんとしたコードを書くんです。





そのときは、rails newするときに

–skip-turbolinks

のオプションをつけて、はなからturbolinksさんにはご退席願うことに決定。





昨今シングルページアプリが主流になりつつあり、
おそらくturbolinksさんがいると困ることしか起こらないだろう…という。





turbolinksさんは、画面遷移するようなWEBページでは非常に活躍する優れものさんで、
当初はかなり効果があって評価されたんだとか。




でも、もうすでに時代に合わなくなりつつあるらしい。
こういう技術面での時間の流れって、本当に早いんだなあ…とおもった。







2:画像が消える問題



私のアプリには、ちょっとした画像がアップロードできるという機能があります。




Herokuへあげる前に、当然一通りローカルで動くことを確認した上でHerokuへあげたんです。





で、最初はなんともなかったのに、
あとで見たらアップロードした画像壊れてて見えなくなってた。





これは今日の授業中に発見したものなんですけど、メンターさんはすぐに理由がわかったみたいです。




今Herokuはフリープランにしてます。




Herokuは、フリープランの場合、
一定時間アクセスがなければセッションを切り離して、
他のユーザに使わせてあげようとする。




クラウド上の仮想サーバーだから、サーバーを落としたとき、
データーを削除して綺麗にした状態にしちゃう。




で、画像保存のためにactive storageを使ってるんですが、
そのactive storageで指定されてる画像の保存先のデーターを消されちゃうらしい。





容赦ねぇです。





だから画像が壊れちゃった状態になっちゃう。
こりゃ致し方ない。




ということで、画像についてはAWSのS3を使うことになりました。



ただ今日は2時間コースで時間が足りないので、次回やることになりました。
(最近常に3時間半〜コースだから、足りない気がしちゃうw)





3:削除



私のアプリ、モデルが7つあって、それぞれ結構紐付けが発生してます。





下手に削除すると


「おい、紐付けしてあったあいつのデーターがないぞ!」


「まて、うちも紐付けしていたあのデーターがなくなってる!」



とエラー祭り必至。





これだけモデルが多くて紐付けもあちこち繋がってるとなると、
削除もちょっと考えてやらないとならないわけですよね。




実際にデーターを消しちゃうのを物理削除というそうですが、
これだけ繋がりがあると物理削除はちょっと危なそう。





ということで、その対義語?に当たる「論理削除」戦法にて対応することにしました。




deviseがはいっているので、ユーザーの削除はdevise先生にお任せしておくことに。
(というか触りたくない…w)





なので、ユーザーが削除されたら、
「user_idを外部キーとして紐付けしているデーター」のみなさんは、
公開設定をoffにするとか、非表示にすることに。





これはもちろん、製品となるものであれば、
きちんとデーターを削除できるようにした方がいいんだと思うんです。





特に、タイムリーな話題ではこの間あった「宅ふぁいる便」の情報漏洩。





ユーザーのあらゆるデーターが盗られ、
中でも「パスワードが平文のまま(暗号化してない)」という古いシステムのままだったから、
パスワードまで盗られちゃったってのが話題ですね。




この話題、メンターさんが教えてくれて知ったので調べたんですが、
宅ふぁいる便は退会処理後のユーザーのデーターを残していたそうで、
宅ふぁいる便をやめたユーザーの情報までも抜かれちゃったんですよね。




そういうことを考えれば

「退会したユーザーの個人情報を適切に処分する」

という対応も重要なんだなあと。





なので、宅ふぁいる便ほど個人のリアルな情報はいただかないアプリですが、
いずれはちゃんと消せるようにしたいです。





あと、「ユーザーが消えたら関連するものが丸っと消える」の話しかしてないですが、
記事や投稿だけが削除された場合のことも考えないといけない。



削除はなかなか一筋縄ではいかなそうだ。




次回までの課題

1:ユーザーが削除された時の関連データーの削除の実装


2:動作がおかしいところの修正


3:テスト(人力)



をやります。




テスト(人力)は、まだアプリ全体の動作チェックが十分じゃないので、
実際に動かしてちゃんと動作するか、
変なところがないか確認しようというものです。




人力で。





本来テストコードを書くと思うんですが、
まあ、あれだ、こまけーこたぁーいいんだよ。




ということで、次は金曜日。
どこまで進められるだろう。


がんばれーうおー!