コロナになってしまいGWはほとんど寝たきりでした😿 ようやく全快したのでまた今日から再開します！ 今回ははてなブログより 記事の中にある、郵便番号からの住所補完ですが どうやっているのか分からなかったので調べてみました。 Railsでは、gemを使ったり、csvデータを読み込んで表示させる選択肢がありそうです。 DBにcsvデータを読み込ませることができるなんて知りませんでした…！ 仕組み的には住所データから当てはまったデータをJSで表示させているようです。 EC
技術記事ではないですが、noteの記事で気になった機能がありました。 気になったのはこの機能です。 オフラインで！？ どう実装するのか全く想像つかなかったので、ざっくりですが調べてみました。 ↓↓↓↓ WEBアプリをオフライン対応にすることをPWAというそうです。 キャッシュとJavaSprictを使って実現してるんですね。なるほど〜。 VScodeもPWA化しているそうです。アプリの用途によってはとても便利になりますね。 また、rails ではPWA化するための
メルペイの記事より。 移行作業は慎重な検討やテストが必要だと再認識しました。 今回のパターンはお金が絡んでいるので尚更ですね。 驚いたのが2019年からスタートしたプロジェクトだそうで、それでもトラブルがあったそうです。 どこかのサイトでデータ移行プロジェクトの約4割は、予算や時間制限や準備不足が原因で失敗する書かれていたのを思い出しました。 準備では経験値が重要そうです。 また、2025年の崖問題もあるので、これからシステム、サーバー、データ移行はどんどん増えそうですね
Hatena Blogの記事より。 分からない用語が多かったので調べました！ 【標的型攻撃】 ランサムウエア 感染したPCをロックしたり、ファイルを暗号化したりすることによって使用不能にしたのち、元に戻すことと引き換えに「身代金」を要求する不正プログラム。身代金要求型不正プログラムとも呼ばれる。 https://www.trendmicro.com/ja_jp/security-intelligence/research-reports/threat-solutio
developIOの記事より。 今回のように不正アクセスのログが見つかったりなど、何か起こってから緊急で対策することは少なくなさそうですね。 WAF のアクセスログの保存についてや、Athenaで分析するパターンが多いことは知らなかったので、勉強になりました！
DevelopersIOの記事より。 思ってたよりも設置できている数が少なくてびっくりしました！ またお恥ずかしながら海底ケーブルというものを全然知らず、こんなものが海の中に？！世界中と繋がっている？！と驚きました。 以下の記事に（ちょい古めですが）、海底テーブルのメリデメや衛星との比較が書かれており分かりやすかったです。 大容量で送れることが衛星よりも優れている点だそうですが、コストはどうなのでしょうか？ 25年位の寿命かつ、災害や船や海洋生物によって修復が必要に
TeckRachoの記事より。 where.firstの場合、「 # ORDER BY "users"."id" ASC 」の処理も発生するためクエリ実行処理が重たくなるそうです。 Active RecordのようなORM（Obuject-Relational_Mapper）の場合、簡単にデータを取り出せるので裏側の処理は見えにくいですね。 あと、find_byとwhereの違いもよくわかっていなかったので調べてみました。 find_by ・返り値はレシーバーのオブ
Wantedlyのブログより。 今までリレーショナル型しか使ったことがなかったので、勉強になりました。起こり得る状況や条件によって実装する方法が変わりそうです。 また、まだ知らないデータベースの形もあるかもと思い調べてみました。 ネットワーク型知りませんでした。階層型と同じく柔軟な取り扱いが難しく、高度な知識が必要だそうです。 データベース、奥深い…！
DevelopersIOの記事より。 元々別だったのですね。先月からAWSは勉強し始めたので元の状態を知りませんでした。 毎日のようにAWSはニュースが出ているので要チェックですね。 （大半がまだ全然理解できないニュースですが涙） そろそろ次のAWSの資格試験勉強も始めようと思います！
アプリマーケティング研究所の記事より。 もともと、サービスが重くなったり落ちてしまうことがあったそうですが、ページ高速化やセール時の負荷対策（安定化）を行い、月300万以上の売上改善につながったそうです。 「あのサイト重いから、こっち使おう」って実際私も思いますし、改善されていたとしても印象が変わる可能性は少ないと思います。 なぜかというと、代用となるサービスがあればそちらをずっと使うので改善された事を知らないまま終わる可能性があるのと、”軽い”ということが当たり前とな
TechRachoより。 こんな議論があるんですね〜。会社によって粒度が違いそうですね。 コードレビューはECサイトをチームで開発した際にしましたが、表面上の確認だけで「動いてるならOK」の姿勢でした…。 セキュリティ品質・運用性の高いコードか確認すべきですね。 憧れの伊藤さんのレビューはとても参考になりました。 rails上達のためにされていることを記事に書かれていて、私も真似してみようと思います。 ①まず直感でコードを書く（この時点では汚くても良い。動きさえす
ANDPADのブログより。 「ロック」「デッドロック」というワードすら知らなかったので、勉強になりました。 ロックとは：https://wa3.i-3-i.info/word11314.html デットロックとは：https://wa3.i-3-i.info/word11317.html データベースの整合性を保ったり、ユーザ体験を損ねないためにも必要ですね。 また、RailsのActive Recordには、楽観的ロックと悲観的ロックがあります。 楽観的ロック：
GIGAZINEで見つけて気になったのでピックアップ。 これは怖いですね。URLを確認するしか対策が思いつかない…。 ただ、本当のOAuth認証であってもセキュリティに問題があるそうです。 IDトークンも発行できるOpenID Connectを今度から使ったほうが良さそうですね。
メルカリ・ソウゾウのブログより まず、クライアントからBFF経由で渡ってきた商品IDを元に、バックエンド（similarseach)で商品名を加工し、Word2Vec という自然言語処理を使って200個の数値の組み合わせ（＝200次元のベクトル）にしています。【下図①〜③】 そこから類似の商品IDを見つけ、類似の商品IDをBFF経由でクライアントに渡して表示している仕組みです。【下図③〜④】 今回は「Word2Vec」と「BFF」というワードを知らなかったので勉強になり
Wantedlyのブログより。 サービスの拡大や制度変更などに伴って、こういった問題はどんなサービスでも起こる可能性がありそうです。 機能や処理をモデルに集約し、パーツ化することで変更を最小化できます。 チーム開発でDB設計からこの開発方法を意識してしていこう…！
Speeeのブログより。 前職で架電業務をしている人は、電話機で１人ずつ電話をして話した内容をシステムに書き込んでました。 この記事を見て、架電業務はもっと効率化できたのか！と思いました。 Amazon Connectは電話をかけるだけではなく、会話の内容から該当チームへ通知を送ったり、会話の概要を自動的にまとめてくれるそうです。 さらにこちらの記事を見ると言語で、状況に応じた処理をカスタムできるのですね！ 引き出しの一つとして参考になりました。
