【GoogleCloud】Professional Data Engineerの資格勉強ログ vol1
なぜやるか
データエンジニアとしてキャリアを積んでいきたいと考えています。普段業務でGoogle Cloudを使っていることもあり、Google Cloudが発行しているProfessional Data Engineerの認定資格を取得するのも良いなと思い立ち、勉強のログを残します。
こちらですね。
試験で問われる能力は大体この辺りだそう。
- データ処理システムの設計
- データの取り込みと処理
- データの保存
- 分析用データの準備と使用
- データ ワークロードの管理と自動化
試験時間は2時間で、税抜$200。
高いですねえ。
記事を見ていると、このような方も見つけました。
この方はエンジニア経験はないそうですが、エンジニアとの会話の解像度を上げるためであったり、データ基盤のベストプラクティスを答えられるように勉強したらしいです。素晴らしい。
Anyway
隙間時間にのそのそと勉強をするので、早速初めていきます。
学習のまとめというより、やったことと書簡的なログにしようかと思っています。
やったこと
12/3
- BigQueryで利用するSQLの復習
- 同じスキーマを持つデータの連結方法
- UNION：重複レコードを含めない
- UNION ALL：重複レコードも含まれる
- テーブルワイルドカード
- 同じスキーマを持つデータの連結方法
unionのソース
12/10
- BQにおけるスキャンバイト数について
- LIMITをつけても読み込まれるデータ量は一定なので料金が安くなったりすることはない
- 例えばWHERE句で日付を絞った結果0件と出力されても、スキャンするすべてのデータ量を読み込む料金が発生する。
- なので、やるのであればpartitionテーブルを作成するのがいい。
- パーティション分割に利用できるのは、DATEとTIMESTAMPの2種類
12/18
- JOIN(結合方法)について
- cross join
- 1 つ目のデータセットの各行と 2 つ目のデータセットの各行が結合され、すべての組み合わせが出力されます。
- 内部結合
- 結果テーブルにレコードを表示するには、両方のテーブルにキー値が存在する必要があります。両方のテーブルでキー値が一致している場合のみ、レコードが結合された状態で表示されます。
- 左結合
- 左側のテーブルの各行が結果に表示されます。一致するレコードが右側のテーブルにあるかどうかは問いません。
- 右結合
- 左結合の逆です。右側のテーブルの各行が結果に表示されます。一致するレコードが左側のテーブルにあるかどうかは問いません。
- cross join
- あとはagg_stringとかagg_arrayが便利という話
【Frontend Developer Roadmap】HTTPとその周りの技術を見るぜ
今日勉強する内容
こんにちは！最近急に寒いですね。朝かぐ空気の匂いが冷たくて、頭が叩き起こされる感覚で毎日目を覚ましてます。
さて、本日も本日とて、Internetの勉強をします。2つ目のトピック、What is HTTPの深掘りですね。
前回記事はこちら。
2つ目のトピックリンクをクリックしたら、こんな感じで紹介がありました。
大体要約すると、HTTPは、ブラウザとサーバー間の通信を定義するステートレスなプロトコルで、リクエストとレスポンスで動作すること。HTTPSやHTTP/2などの進化形があり、セキュリティやパフォーマンスの向上に寄与している。みたいなことが書かれています。
Freeでこれ読んだら？って記事が4つもあって、それぞれのメモを残すのは大変なので、3,4個目の、
- How HTTPS Works
- HTTP/3 is Now a Standard: Why Use it and Hot to Get Started
を読んでいこうと思います。
How HTTPS Works
なんか変な猫みたいなのがお迎えしてくれます、なんだこれ笑
やけにコミカライズだなと思ったら漫画でした。
なぜHTTPSは必要なのか
Compugterとか、Browserbirdとかいるのおもろい笑
翻訳もあって、結構スピーディーに読めるので、直接読むのがいいと思います！最初はなぜHTTPSのSが大事なのかという話、プライバシー、完全性、認証が、実生活においても大事だよね？みたいな話でした。非IT圏の人からみてもわかりやすそう。
鍵
2つ目のページでは鍵についてです。
これを実装するために暗号化技術が必要であり、ここでは2つの暗号アルゴリズムを説明しています。そう、最も有名と言っても過言ではない、共通鍵暗号アルゴと公開鍵暗号アルゴ。
書いてある通り、使う鍵は1つ。
メッセージの暗号化に1つの鍵を利用し、その1つの鍵を持っている人であれば誰でも複合できるというもの。問題は想像に容易いですね。共通かぎは共有するのが難しいというもの。
次は公開鍵暗号アルゴについてです。
共通鍵との違いはカギが2つあること。1つが公開鍵でもう一つが秘密鍵ですね。考え方を整理すると、暗号化には公開鍵を、そして復号ににペアとなる秘密鍵が必要になります。暗号化に必要な公開鍵は、送信先が発行しているものを利用します。そうすることで、2つの鍵を持っている人だけがメッセージを開けることができる仕組みなんですよね。賢いですよねぇ。
相手が公開している鍵で鍵をかけることで、そのついとなる秘密鍵を持っている相手だけが解錠できる仕組み。これを物理的で実現するのは難しいですが、情報を使って暗号化しようとすると簡単にできますな。
読んでて思ったけど、このサイトのFooterかわいい。笑
次はハンドシェイクです。これも大事。
ハンドシェイク
ハンドシェイクは握手のことですね。要は、接続するサーバー同士が安全かどうかを互いに同意するという目的でハンドシェイクが必要になります。
個人的に、ここの漫画は抽象化されすぎてわかりにくかったのでハンドシェイクだけ別サイトから引用します。
SSL（Secure Sockets Layer）は、HTTPのために開発された本来のセキュリティプロトコルです。SSLは少し前にTLS（Transport Layer Security）にとって代わられ、SSLハンドシェイクは現在ではTLSハンドシェイクと呼ばれています（「SSL」という名称も依然広く使用されていますが）。
ほーん。SSL→TSLの時代の流れがあったと。
TLSハンドシェイクは、ユーザーがHTTPSでWebサイトに来て、ブラウザーがそのサイトのオリジンサーバー（配信元サーバー）に問い合わせ始めた時に行われます。TLSハンドシェイクは、その他の何らかの通信でHTTPSが使われる時（API呼び出し、DNS over HTTPSクエリなど）にも起こります。
Client HelloとかServer Helloって言ってたのもちゃんと説明されている。
ハンドシェイクの流れを文章で引用するとこちらです。
1. 「Client Hello」メッセージ：クライアントがサーバーに「Hello」というメッセージを送信することによってハンドシェイクを開始します。このメッセージには、クライアントがサポートするTLSのバージョン、対応する暗号スイート、「クライアントランダム」というランダムなバイト文字列が含まれています。
2. 「Server Hello」メッセージ：Client Helloメッセージへの返答として、サーバーがメッセージを送ります。このメッセージには、サーバーのSSL証明書、選んだ暗号スイート、サーバーが生成した別のバイト文字列「サーバーランダム」が含まれています。
3. 認証：クライアントはサーバーのSSL証明書を発行元の認証局に確認します。これにより、サーバーが自称する本人に間違いなく、クライアントはそのドメインの実際の所有者とやりとりしていることが確認されます。
4. プレマスタシークレット：クライアントは、「プレマスタシークレット」と呼ばれるもう1つのランダムなバイト文字列を送信します。プレマスタシークレットはパブリック鍵で暗号化されており、復号化は秘密鍵を使うサーバーしか行えません。（クライアントはサーバーのSSL証明書からパブリック鍵（公開鍵）を入手します。）
5. 使用される秘密鍵：サーバーはプレマスタシークレットを解読します。
6. セッション鍵の生成：クライアントとサーバーは共にクライアントランダムとサーバーランダム、プレマスターシークレットからセッション鍵を生成します。双方とも同じ結果になるはずです。
7. クライアントの準備完了：クライアントは、セッション鍵で暗号化された「finished（完了）」のメッセージを送信します。
8. サーバーの準備完了：サーバーは、セッション鍵で暗号化された「finished（完了）」のメッセージを送信します。
9. セキュアな対称暗号化の実現：ハンドシェイクが完了し、セッション鍵を使用して通信が続行されます。
HTTPS、SSL、TLSの違い
Sは保護されたって意味ですよね。これはわかる。
HTTPが、ブラウザとウェブサーバーが通信し、情報を交換するのに使われるプロトコルであって、それがSSL/TLSで暗号化されているとHTTPSと呼ばれるらしい。
じゃあSSL/TLSで暗号化されるとは？なぜ一緒にされる？
SSL：Secure Socket Layer
TSL：Transport Layer Security
SSLプロトコルは、Netscape社が開発したけど、セキュリティ問題だらけでプロトコルの管理をIETFに委ねたらしい。んで、20世紀の終わりにTLS 1.0をIETFがリリース。
この辺は流れがそうなんだくらいの理解で止めておきます。
ここがわかれば良いっぽい。そしてSSLは90年代半ばには廃止されていると。
認証局の話も、漫画として面白かった。って感じでした。詳しい仕組みを知るには別の記事を参照するほうが良さそうですが。
とっかかりとしては分かりやすい漫画でした！
【Frontend Developer Roadmap】インターネット周りの知識を整理するぜ
はじめに
Frontend Developer Roadmapの初回キャッチアップ記事です。目標はフロントエンドの技術者になるというより、フロントの開発者と技術的な話をできるようになる、ですので、メインは仕組みや説明可能な部分を増やすというものです。
前回記事でも書いた通り、Frontend Developer Roadmapより、最初から丁寧にロードマップに乗って知識を整理していこうと思います。
最初はここからですね、インターネットからなんですね。結局JavaScriptの勉強をしようにも、ブラウザの勉強をしようにも、インターネットの知識から入る本が多いような気がします。
これですこれです。このロードマップの便利なのが、これらに関連するリンクが貼ってあるんですよ。これがすごい。
Internetの回では、
- How does the internet work
- What is HTTP
- What is Domain Name
- What is hosting
- DNS and how it works
- Browsers and how they work
ですね。文句言わず全部目を通してみたいと思います。
How does the internet work
今読んでるサイトが用意したページっぽいですね。インターネットとは何かみたいなふわっとした質問に、インターンネットを作ったうちの一人である"Vint Cerf"が解説する動画が貼られています。
中身は、世間のインターネットに対する漠然としたイメージと、その歴史みたいなところでした。
なぜインターネットが漠然としているのか。それはインターネットを管理する人もいなければ、その実体もないからであると動画内では解説されています。そしてそれでいいのだと。
ただ、わかりやすく1台と1台のコンピュータを繋ぐ構成を考えてみると、2つのコンピュータを繋ぐ何かが必要です。糸電話ではそれがヒモになるわけですが、コンピュータを繋ぐのはワイヤー、またはWi-fiです。
ここでいうワイヤーは、イーサネットケーブルや、ワイヤレス信号のWi-fiを含みます。情報はバイナリー形式で配送されますね。うむ。わかる。
でもこの動画普通に面白かったのおすすめ。
0/1を送信して受信するわかりやすい仕組みとか面白かったです。
さて、情報を運ぶためのパイプラインはわかりました。あと必要なのは住所ですよね。どの情報をどこに運ぶのか。それを解決するのがIPアドレスとDNSです。
これはbrief introduction to IP, DNSってやつですが、ここにもfather of the internetのVIntが登場しています。
DNSに関してはまた別で説明がありそうなので割愛します。
InternetのReliabilityに関しては、Spotifyのソフトウェアエンジニアの人が説明しています。すごいですねえ優秀。っぽそう。
インターネットの情報は一気には送れないのでパケットと呼ばれる最小単位で送受信されます。パケットはインターネット上のどこを通るかは事前に決まらず、なので1つの画像であってもさまざまな経路を通る可能性があります。
この、どこを通るのかという部分をコントロールするのがReliabilityです。わかりやすい。
次にHTTP
HTTP is the standard protocol by which webpages are transferred over the Internet. The video below is a brief introduction to HTTP and how web browsers load websites for you.
インターネット上で使える、情報送信のプロトコルですねって話。
大体こんな感じでした！Internetパートをまとめます。
まとめ
この記事では、インターネットの仕組みについて、その構造、ケーブルやWi-Fiを介したデータ転送、IPアドレスやDNSを介した通信などについて解説しました。
また、パケットを使った情報のルーティング、暗号化を使った安全な通信、サイバーセキュリティといった重要な概念についても、勉強先の記事では解説しています。紹介したYoutubeでは、HTTP、HTML、暗号などのプロトコルについて解説し、インターネットの機能を包括的に紹介しています。
リモートのコミットメッセージの修正をしようとしたらそんなに綺麗にならなかった話
経緯
みなさんgitは普段使っていますか？
僕はゆーてそんなにありません。ならしたら1週間に10~30commitくらい。
そんな中で、業務中、prodのコードベースに対してこんな感じでコミットメッセージを書いています。
add: 機能1
add: TAG1
update: 既存の命名規則
fix: TAG1のタイポ修正
add: TAG2
delete: dead code
こんな感じで、新規追加やUpdateをメインにcommitしていき、typoや修正漏れなどのcommitをfixで切っています。そんな中、仮に、上から4つ目のfixをupdateにした方が、プルリク全体の収まりがいいなと感じたのでrebase→amend→pushを試してみようとしました。
ちなみにこれらのコミットはリモートにpush済みです。
起こったこと
記事としてはこのあたりを参考にしました。
まぁ大体予測つくと思いますが、remoteのプルリクにはforce-pushの文字がつき、今までコミットIDは変更され、コミット時間も変更され、そこまで綺麗にならなかったなという印象でした。
git rebase -i HEAD~n
git commit --amend -m "update hoge"
git rebase --continue
git push -f origin feature/branch
これでやりたいこと自体はできました。コミットメッセージは無事updateになったので、メッセージの切り方は綺麗になったのですが、、、
特定のコミットに対してメッセージを打ち、その後また新しいコミットを積んでいたのでコード修正の流れが不自然になったのです。
こんな感じ。
普段rebaseしたり、--amendを使ったりしないので楽しかったですがremoteにpushした後のcommitログを修正するときは気をつけようねという話でした。
フロントエンドのキャッチアップを永遠に保留していたので向き合います
最初に
タイトルの通りです。データ分析のインターンでエンジニアとして始めてお給料をもらい、そこからアプリケーションの開発やデータ基盤を中心に経験を積んできました。
今ではデータエンジニアとして、検索ログ基盤の開発と運用を行っていますが、ログの文脈で言うとフロントエンドの基本的な知識があるに越したことはないよな。と感じる日が多いような気がしています。
過去に全くフロントを触ったことがない、と言うわけではなく。
むしろフロントのみのアプリケーションを会社でリリースまで持っていったこともあるのですが。個人的な感覚としてはなんか動いてるからOK。
みたいな部分が多いものでした。
その他ハッカソンなり、個人開発なりで、フロントを触る機会はあれど、なんか動いてるからOK！みたいなノリを3、4年続けてきました。
エンジニアとして、せめてそれくらいは知ってようよ。くらいの知識をキャッチアップして、それを人に説明できるくらいの定着を目指したいなと思いこの記事を書きます。
今年も残すところ残り2ヶ月となりましたが、、、
エンジニアとして成長できたのかと言われたら不安です。。。
学生の時にあった、どこから来るのかよくわからない自信が今となっては眩しいなと、またあの全能感に浸りたいと思いながら勉強しようと思います。
何やるか
そう。問題は何をやるか。
現状のスタート位置を整理します。
- html, css, jsそれぞれ書ける
- HTMLがプログラミング言語ではない、と言うネタで笑える
- レスポンシブデザインちょっとわかる
- Vueのコードは見慣れている（書けるとは言ってない）
- Reactのコードもコピペしながら動くものが作れる
- ビルドツールがたくさんあるのはわかるが、種類や何をしているかは整理ができていない
- 状態管理、正直よくわからない
- ブラウザレンダリングの仕組み、よくわからない
思いつくものを書き殴ってみました。
目指すゴールとしては、実装を読んだ時に技術者としての意図がわかる、またその意図から派生した会話ができるようになる。状態になりたいなという気持ちです。
フロントエンドのエンジニアになるわけではないのでこれは参考程度ですが、途方もないですね。
っていうか、、、
書きながらこの記事を見つけて、そして斜め読みしていましたがこれでよくない？
順にやっていったらフレームワークまでたどり着くし、しばらくは読み物や動画教材もあるので、これに従って、経過報告をしていこうと思います！有名なやつにあやかれば、そこそこの平均は取れるでしょう！
と言うことで、次回から進捗とメモ的な記事を残しつつ勉強していこうと思います。
