Posts

oauthの大枠について、いい感じに理解したので、覚えているうちにアウトプットしておく まあ、経験的にもわかると思うけど、新しくemailを登録してそこに確認メールを送って、認証する、っていうやつ、あれやっぱり面倒くさくて、CVR下げるのよね。ってことで、やっぱりgoogleとかLINEとかを使った認証のほうが圧倒的に楽なわけですわ。ポチってしまうわけですわ。これ、自分のアプリに組み込むことで圧倒的にユーザを確保できると思うんですよね。ってことで、 仕組み 大事なのは、どのフェーズにおいても、URLそのものに重要な情報を乗っけてやり取りしてるってこと。 まず、ユーザがログインページでgoogleによる認証をクリックしたとするよね。これはゲットリクエストなわけですわ。このgetリクエストに対して、サーバはユーザをgoogleの認証サーバにリダイレクトするわけです。 で、リダイレクトのurlの中にこのサイトの情報が乗ってるんですよね、サイトのIDってやつです。 このIDは事前にgoogleのdeveloperサイトでもらえます。google側はこのIDでどのサイトかを判別しているんですね。更にこのサイトでコールバックのURL (ユーザがgoogle側にこのアプリに情報を送ることを承認するボタンを押したあとにリダイレクトされるURL) も登録しておきます。 で、ユーザが承認すると、コールバックのURLにユーザの情報にアクセスするためのトークンを乗っけてこっちにリダイレクトされるわけですわ。 で、そのトークンを使って、ユーザの情報にアクセスできるようになるわけです。 ただ、自分でメール認証の仕組みを作るのも重要だとは思っている。 これの作り方、そんなにむずくないよね。 まず、ユーザにメールアドレスを入力してください。ってお願いするわけです。 で、入力されたメールアドレスに、このサイトのurlと/auth/mail/{random} みたいなのを入れておくわけですわ。randomっていうのが、そのメールアドレスと一時的に紐付けられているランダムな値です。で、ユーザが/auth/mail/{random}にアクセスしてきたら、まあ、実際にそのメールアドレスがあったんやなってわかるわけですわ。まあなんでもいいよ、mail2uuid := map[string]stringとかで管理しているやつと for k,v := range m { if v == uuid { // そのイーメールアドレスを認証する、って感じです。 // このときにcookieを入れておくといいですね。ええ。 // cookieとemailを紐付けるのを忘れないように。 // useridとパスワードを入力するページにリダイレクトします。 // って感じです。はい。 } } これ、有効期間決めておいたほうがいいですね。数分とかそんな感じで。 ちなみに、golangからemailを送信する一番いい方法なんだけど、 やっぱり、リレーするのがいいみたいです。ええ。 chatGPTに出してもらったコードがこちらですね。 package main import ( "net/smtp" "log" ) func main() { // Sender and recipient email addresses. from := "your_email@gmail.com" to := "recipient@example.com" // SMTP server configuration. smtpServer := "smtp.gmail.com" smtpPort := "587" smtpUsername := "your_email@gmail.com" smtpPassword := "your_email_password" // Compose the email message. subject := "Hello, Golang Email!" body := "This is a test email sent from a Golang application." // Define the SMTP server's authentication information. auth := smtp.PlainAuth("", smtpUsername, smtpPassword, smtpServer) // Create the email message. msg := "Subject: " + subject + "\r\n" + "To: " + to + "\r\n" + "From: " + from + "\r\n\r\n" + body // Send the email. err := smtp.SendMail(smtpServer+":"+smtpPort, auth, from, []string{to}, []byte(msg)) if err != nil { log.Fatal(err) } log.Println("Email sent successfully!") } 決済の方法についてもいくつかあると思うので、まとめておきたい。 まずは、どの決済を組み込むかなんだけど、まあ普通に paypayとpaypalとまああとはクレジットカードでいいかね。 そうね、ユーザにポイントを付与する感じにするか。 1シミュレーション100ポイントとかにしてとかにして、って感じかね。 実際に購入画面に進むためには500ポイントとかにして。1000ポイント買うと、200ポイントおまけでついてくる、とかにしてね。 ...

サムアルトマンのブログでかなり好きだったポスト The Strength of Being Misunderstood A founder recently asked me how to stop caring what other people think. I didn’t have an answer, and after reflecting on it more, I think it's the wrong question. Almost everyone cares what someone thinks (though caring what everyone thinks is definitely a mistake), and it's probably important. Caring too much makes you a sheep. But you need to be at least a little in tune with others to do something useful for them. It seems like there are two degrees of freedom: you can choose the people whose opinions you care about (and on what subjects), and you can choose the timescale you care about them on. Most people figure out the former [1] but the latter doesn’t seem to get much attention. The most impressive people I know care a lot about what people think, even people whose opinions they really shouldn’t value (a surprising numbers of them do something like keeping a folder of screenshots of tweets from haters). But what makes them unusual is that they generally care about other people’s opinions on a very long time horizon—as long as the history books get it right, they take some pride in letting the newspapers get it wrong. You should trade being short-term low-status for being long-term high-status, which most people seem unwilling to do. A common way this happens is by eventually being right about an important but deeply non-consensus bet. But there are lots of other ways–the key observation is that as long as you are right, being misunderstood by most people is a strength not a weakness. You and a small group of rebels get the space to solve an important problem that might otherwise not get solved.

learn_k8s_2! はい、前回がk8sクラスタの構築部分でした。ここからは実際に運用をどうするか？ってところに焦点を当てていきたいと思います。 前回の冒頭の記事はいい感じだったので、ここにも書いておきたいと思います。 ことはじめ k8sという技術が注目を浴びている。web業界での近年の大きな変化としてはアプリケーションアーキテクチャの変化が挙げられる。従来は、アプリケーションを構成するソフトはモノリシック(一枚板)であった。つまり、アプリケーションは、一つのソースコードで1プロセスで動いているような感じだった。しかし、このモノリシックなアーキテクチャではソースコードが複雑で、変更が加えにくい等の問題があった。チームで開発する際も、メンバーみんなが同じソースコードをつかってビルドをする必要がある等、いろいろと面倒なことが多かったと思う。そこで、近年はアプリ開発にはマイクロサービスアーキテクチャが採用されている。マイクロサービスアーキテクチャは、小さなコンポーネントの集合が全体として一つのアプリケーションを構成しているようなアーキテクチャである。 自分も意図せずして、開発してきたアプリはマイクロアーキテクチャにしていたが、こちらの方が各コンポーネントの役割をきちんと明確化して進められるので、開発を分担できるのと、変更を加えるとき、役割がコンポーネントに分かれているので、各コンポーネントの中身だけを変えればよく、管理が簡単になると思われる。つまり、APIだけそろえておけば、後は中身はなんだっていいということだ。 これによって、アジャイル開発が非常に簡単になると思われる。 そして、このコンポーネントをひとつひとつをコンテナ化するってのも近年の大きな流れだ。コンテナ化することで、そのコンテナはCPUのアーキテクチャさえそろっていればどんなマシン上でも動くようになるからだ。そして、コンテナ化されたコンポーネント（マイクロサービス）をうまく協調させるのが コンテナオーケストレーションツールってはなしだ。 コンポーネントを協調させる、と書いたが、具体的には(k8sの機能は非常に多いので、俺が理解できる、かつ、大事そうなものだけをピックアップする)、 コンテナのスケジューリング スケーリング/オートスケーリング 障害時のセルフヒーリング ロードバランシング ワークロードの管理 とかがある。 k8sの基本的なコンポーネント 参考動画 基本用語説明 dbと連携させたjsアプリを題材に、k8sのコンポーネントを説明していくよ！ cluster k8sのリソースを管理する集合体のこと node 物理マシン、もしくは仮想マシンのこと。つまり、ホストのこと。 ノードには、master nodeと普通のnodeがある。 master nodeはkubernetesを管理するため、次の管理コンポーネントを持つ kube apiserver:kubernetesのAPIを公開する。kubectlからの操作を受け付ける役割。kubeletからもアクセスを受けるし、他にもいろいろなクライアントがある。これがclusterへのgatewayになる。ユーザは必ずkube apiserverを通してクラスターとやり取りをするということだね。 etcd:分散kvs。クラスタのバッキングストアとして使用される。ログとかが記録されている。etcdは分散kvs、ということはetcdを何個か立てることが可能、ということでして、そうするとetcd間で内容の一貫性を保たないといけないわけですね。ということは？お？層です。分散合意アルゴリズムのraftが使われているわけですね。最高です。 kube scheduler:コンテナを配置する最適なnodeを選択する。ここも研究の対象になりえるところではある。 kube controller manager: リソースを制御する k8sでソフトで実現される概念的なコンポーネント (下で紹介するが、これをリソースと呼ぶ。) Nodeはコンテナ化されたアプリケーションを実際に実行するホスト pod コンテナの集合体。PodはNodeの中で動作し、一つ以上のコンテナを持つ。 K8sにデプロイするときは、Pod単位で行う。(実際はdeployという単位でコンテナをデプロイするんです) pod一つでなにか機能を果たす、とかそういう感じでpodにまとめるのだと思われる。 そうだね、1 application per Podというのが基本らしい。 k8sはvirtual networkを提供。各Podはこの仮想ネットワーク上でIPアドレスを持っている。 そして、これが結構大事な概念だんだが、Podは結構簡単に死ぬ。そして、Podが死んだら、新しいPodがデプロイされるのだが、その時にIPアドレスが変わってしまうというのが不便らしい。その時に使うのがServiceらしい。 Container Dockerコンテナのこと ReplicaSet 同一仕様のPodを複数生成する仕組み。 ReplicaSetを複数持っておくことで、一つのReplicaSetが死んでも他のReplicaSetに 処理を移すことでシステムが死んでいる時間をなくす。 後は、ロードバランスもできる。 データベースは基本的にk8sクラスタの外で管理する。というのも、ステートを考えるのが面倒くさいかららしいです。 Service Serviceは、Podにアクセスするための経路を定義。 PodのIPアドレスを固定できる。 外部への公開ポイントもここで設定する。 Deployment ReplicaSetの上位リソースで、ReplicaSetを管理する。 つまり、 DeploymentがReplicaSetを管理し、ReplicaSetがPodを管理する。 ingress クラスタ外部からのエンドポイント？ ConfigMap Podsの設定ファイル ...

いい本である あのね、アプリとか、ネットワークとか、サーバとか、そのへんがある程度詳しくなってから改めて読むと、めちゃめちゃ整理されていて、めっちゃためになる。 最初にかんたんに全体像を説明しておくか。ネットワークの。 アプリがある。アプリは、システムコールを使ってデータの送信をosに依頼する。例えば、HTTPもアプリだよね。アプリケーションプロトコル。 で、アプリから依頼されたosの中で一番最初にデータを受け取るのがTCP(UDP)。こいつは、一番最初の通信経路の確立、データの分割、再送信、などを担う。TCPヘッダーには色々入っています。で、分割されたデータをパケットっていうんですね。 HTTPのヘッダーとか、ボディーとかも、TCPから見るとバイトの羅列でしかないってことはめっちゃ大事なポイント。 で、TCPは更にIPに送信を依頼する、というわけですね。 IPで意外なのは、IPはIPヘッダーをつけるだけでなく、MACヘッダーもつける、ということです。ここは大事。マックもつくんです。送信相手の見つけ方なんだけど、まずは送信先のIPを見つけるんだよね。そのときにはルーティングテーブルを見るんですね。linuxだと、 route コマンドで見られます。で、どこに送信すればいいかがわかると。 でね、イーサネットの中では、IPは通用しないんだよね。(IPとイーサを一緒にしないのはなぜか？というのは考えラバわかります。考えてください。)それは、IPという概念がないから。だから、IPと一対一に紐付いたMACを調べないと行けないんだよね。そのときに使うのがARPプロトコルだね。address resolution protocolだね。これは、ブロードキャストアドレスに対して出されるプロトコル。だから、みんな受け取るんだよね。 アプリケーション層 TCP/IP層 TCPの仕事 ipの仕事 イーサネット層 おもろかったのが、イーサネットの間は全部同じデータが流れている、というところ。これかなりおもろかった。イーサネットケーブルでつながっているノード同士は、大きな部屋に入っている人のようなもので、誰かが大声で叫んだら、それをみんなが聞けるのとおんなじだ。って話。これはおもろいね。だからイーサネットケーブルっていつもあんなにピカピカ光ってるんだよね。りかい？？ んで、そこで宛先を判別するためにMACアドレスが使われている、ってはなし。 ただね、スイッチングハブは、MACアドレスを見てその相手に向かっているイーサネットケーブルにしか流さないから、章電力なわけ。りかい？ ハブ、スイッチ、ルータ アクセス回線、プロバイダ サーバ側

まえがき Go言語はhttpサーバに使われることがおおいー＞これは、現代のシステムがマイクロアーキテクチャに依存していることを示している。一つ一つのコンポーネントは単純な入出力に対応しているだけである。そのため、シンプルなgo言語が好まれるのだろう。 さらに、goの人気を上げているのが、並行処理の扱いやすさにある。 一般的な言語では、スレッドを立てて、スレッド間でなにか、スレッドセーフなコンテナを準備してやり取りをしないといけなかった。 しかし、goでは、goroutineとchannelを使って、スレッド間通信のようなものがかんたんにできるのがかなりいい。 以上の２つの要因によって、goではデータの流れがだいぶ見やすくなっていると思う。川上から川下へ流れていくがごとく、データの流れがとにかくつかみやすい。 goで特徴的なもう一つの機能は、インターフェースだろう。 これについては、後ほど説明する。 第一章 環境構築 https://go.dev/dl/から最新版をダウロード。tarで解凍。/usr/local/いかにgo/をおいて、そこにパスを通す。 echo 'export PATH=$PATH:/usr/local/go/bin' >> $HOME/.profile source .profile ここで疑問なのだが、どうやら、go/はホームディレクトリいかにもおいておかないとだめみたいなんだ。 というのも、ダウンロードしたモジュールやパッケージはホームディレクトリ以下のgo/に置かれるかららしい。 まあ、よくわからんよね。じゃあ、/usr/local/いかにおいたgoは何だったんだとね。 実行 go run hello.goでも実行できるし、 go buildで、コンパイルもできる。go自体はコンパイル言語。go runは直接実行しているように見えるが、内部的にはgo buildで一回ビルドしている。 ちなみに、go buildで出力される実行ファイルは.go前の部分。だから、hello.goをコンパイルすると、helloという実行ファイルが生成される。これを変えたい場合は、-oで実行ファイル名を変更することもできる。 モジュール まあ、c++やcの分割コンパイルみたいなことができるって話で、モジュールを作ってみましょう、ということ。 mkdir hello-world cd hello-world go mod init hello-world これで新たにgo.modというファイルが出来上がる。 go install goはgo installコマンドでgoのバイナリをインストールできる便利なコマンドである。 ためしに、heyという、httpサーバのロードテストを行えるツールをインストールしてみましょう。 go install github.com/rakyll/hey@latest デフォルトではホームの下の~/go/binにインストールされます。なので、ここにもパスを通す必要がありますね。 が、変えたかったら、$GOPATHを変えましょうって話ですね。まあ、変えることはあまりおすすめしませんが。 で、goで作ったファイルはこんな感じでかんたんに公開できるわけですね。 goのコードのフォーマット 無意味な宗教戦争を産まないために、かなりフォーマットに制限があるという話。こういうのは結構好き。例えば、 main(){ } と main () { } みたいな。goでは後者はコンパイルエラーになる。 開発ツールにgo fmtやgoimportsというものがあり、これはプログラマーが書いたソースをきれいにしてくれるフォーマッターである。 他にもstaticcheckという名のりんたーがある。 これは、まあ、コードを解析してくれるツールです。きれいなコードを生み出してくれるということで、ありがたい。 第二章 変数の定義について色々教えてくれています。これは実際に書いていくなかで勉強していくほうがいいのではないかと思っているのです。 ただ、変数の命名規則は結構勉強になった。 go言語ではスネークケースはあまり使わないと。これは俺が好んで使うやつだね。 comp_calcみたいな感じ。でもこれはあまり使われないらしい。で、キャメルケースのほうがいいって話。うん。たしかにそっちのほうが主流な気もしてきたな。 あと、goでいいなって思ったのは、定義した変数を全部使わないとコンパイルエラーが出るところ。これでいらない変数を全部排除できるって話です。 三章 配列、スライス 配列は、 ...

問題 bluetoothのキーボード、やっぱ留守ごく便利なんです。紐がないとそれだけで机がきれいになるし、やっぱり机がきれいだとやる気もでる。ただね、ubuntuがどうやらbluetoothキーボードと相性が悪い。一度ペアリングして接続したあと、アイドル状態が長く続くと接続が切れて、その後またコネクトしようとしても一生disconnectとconnectを行ったり来たりする。これを解消する方法があるって話だ。 参考文献 このサイト 解決方法 まず、usbドングルがアイドル時に自動的に切れるのを防ぐ必要がある。で、まずはどのusbドングルが対処のusbドングルなのかを調べる必要がある。で調べるためにpowertopというアプリをインストールしますね。 で、ドングルを特定して、そのあと autosuspendをoffにします！それだけです！！ ただ、起動時のスクリプトでそれをやるとなんでかわからんけどうまく行かないんです。だから、下を見てください。 まとめ 起動時に一度ワイヤードキーボードでバッシュに入って設定を変更したあと、無限にワイヤレスが使えるようにすればいいです。ということで一回目の起動のときはどうしてもワイヤーが必要になります。

個人的基本 ローカルで新しいブランチ作成 git branch <new branch> ブランチ一覧を見る git branch ブランチ移動 git checkout <branch name> ローカルのブランチ削除 git branch -d <branch name> ローカルのブランチをリモートブランチにpush git push origin <branch name> originは省略できませんねー。お願いします。これでgithubに新しくブランチができます。 ちなみに、originはブランチ名ではなく、リポジトリ名です。つまり、githubのリポジトリをoriginで指定しています。 ファイルの差分を確認 git diff <filename> 作業していると、どのような変更を加えたか忘れてしまうこと多いと思うんですけど、これがあると、最後のコミットからどのような変更が加えられたのかが 一瞬でわかります。 個人的中級 ##　リポジトリの特定のブランチをクローン git clone -b <branch_name> <repository_url> issue branchをmainにマージ まずmain branchに移動。その後、merge git checkout main git merge issue コンフリクトが起こったらその個所を直してコミット！！ 個人的上級 プルリクの送り方 前提として、何かしらのossを開発しているものとしましょう。まず、プルリクエストっていう概念は、gitではなく、github上のものなので、ローカルではできませんね。じゃあどうやるか？それを今から説明していくぜ。 まず、github上でforkします。forkしたものをローカルにcloneします。cloneしたものに変更を加えます。そして、githubにプッシュします。で、github上でフォークされたリポジトリから、コピー元となったリポジトリ (これをベースブランチと呼ぶらしいです)にプルリクエストを送るわけですね。 変更メッセージを指定して、レビュアーを指定して、Create pull requestをクリックすればプルリクエストの作成が完了するんですね。そうすると、プル陸タブにプル陸が表示されるようになるんだよね。 れびゅあーに指定できるのは、リポジトリのコラボれーた　（共同編集者）　となっているアカウント。 ちなみに、企業でいわれているコードレビューっていうのはこのプルリクエストを送る作業のことなんだと思います。 だから、去年のインターンの面接で「コードレビューをしてもらったことはありますか？」って聞かれたときにはい、あります、先生に見てもらってここをこうした方がいいとか、そういうアドバイスをもらいました、って言った俺は、意味が分かっていなかったわけですね。 mergeには3種類ある create a merge commit ：もっとも一般的 squash and merge rebase and merge : ブランチを一直線にする 特定のブランチorタグをcloneする git clone リポジトリ名 -b ブランチorタグ名 いちばんやさしいgit&Githubの教本を読んで新しく学んだこと forkはgithub上でリポジトリをコピーすること。 ...

修了要件について 共通基礎科目4単位以上、専門科目16単位以上、習得した単位数が合計で30以上、が修了の要件。 共通基盤科目は4単位取りました。情報法律制度論、人文情報科学概論の二つで。 専門科目は 計算機構論、知能集積システム学、アルゴリズム論、高信頼システム、離散数学、IFT,情報基礎科学ゼミナール、ビッグデータスキルアップ演習、データ化学トレーニングキャンプ1,2、以上、18単位をここまで取っています。この時点で専門16単位もクリアしています。 修論も専門科目に含まれていて残り9単位が降ってくるので、 共通基礎科目4 + 専門科目18 + 修論9(専門科目) = 31単位で修論。 保険で「サイバー攻撃とその対策実践入門」を最後に取りたいとおもいます。こちらは夏休みに実施される集中講義で1単位を取得可能です。履修登録を忘れないようにお願いします。

Squidについて Squidはプロキシやリバースプロキシの機能を提供するソフトウェアです。 プロキシを置く理由 主に、サービスの利用者向けのソフトウェアですね。 リバースプロキシを置く理由 リバースプロキシサーバーをバックエンドサーバーの前段に置く理由は、主に以下の５つです。 キャッシュサーバーとして利用 レスポンスを圧縮 (レスポンスの転送を高速化) SSL ターミネーション (暗号化や復号化の処理をリバースプロキシにオフロード) セキュリティの向上 (リバースプロキシでフィルタリング、バックエンドサーバーを隠蔽) 拡張性 (クライアントはリバースプロキシと通信するので、バックエンドサーバーを変更可能) こっちは主に、サービスの提供者側向けのソフトですね。 僕がやりたいこと 全部の通信が、Torみたいに、複数のサーバを介して行われる感じにしたいんですよね。んで、最終目的地はデータベースです。ユーてこれって、openvpnとかでじっそうできるのかな？いやできないか。 ネットワークの通信、頑張って自分で作れたりするのかな。いけそうな気もするな。

やりたいこと webアプリケーションを家のサーバで動かすとなるとセキュリティーの観点からして怖いじゃないですか。やっぱり自宅のipさらしたくないじゃないですか。 だからAWSなどのVPSを借りてそのうえでアプリを動かすんだと思います。 ただね、VPSでは二次記憶で使えるデータ量が決まっているんですね。しかもそのデータ量が結構限られています。例えば僕が契約しているサーバは二次記憶の容量が30GBです。つまり、大規模なデータベースを展開するには、大幅な課金が必要になるわけです。しかもさ、データベースを移植するのって結構面倒だからさ、一回構築したやつを長く使いたいんです。だからね、データベースだけは自宅においておき、アプリケーションが自宅のDBにデータをとりにきたり、おきに来たりすればいいのでは？と今思っているわけです。DBクライアントがデータを取ってくる時の通信量も考えるとどっちが安いかはまだわからないんですけどね。 じゃあ、自宅のルータをポート開放して、ポートフォワードすればいいんじゃねーの？って思うよね。でもね、データベース用のポートを開放しておくのもなんか怖いんですよ。ブルートフォースとか受けて、破られることもあるわけじゃないですか。ということで、vpnを介して自宅のネットワークにアクセスできるようにしておけばいいのではないか？というのが僕の考えです。 vpnクライアントのインストール sudo apt update sudo apt install openvpn vpnクライアント、設定ファイルのインポート config.ovpnをサーバに配置 sudo openvpn --config /path/to/my/ovpn/file パスワードを入力してトンネル完了 openvpnを介して自宅のmysqlサーバに接続 mysql -u ray -h 192.168.3.10 -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 473 Server version: 8.0.33-0ubuntu0.20.04.2 (Ubuntu) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> いけてしまっている…これはマジで感動！！ネットワークはやはり面白い。仕組みとかはもっと勉強しないといけませんが。 いやー－－、実際これはすごいです。マジですごいですわ！！感動ですわ。 ...