Posts

ことはじめ Linuxに関するいろいろなことをまとめてあるサイトを見つけたので、自分に有益な部分だけをまとめて行きたいと思う。 参考文献 これです 俺が思うLinux中級者向けのコマンド達 中級者というか、今の時点で俺が知らない、もしくは使いこなせていないコマンドって感じかな。 find ファイルを検索する。 find <検索パス>　-name <ファイル名> ファイル名の一部 的にやるのもだいぶいいと思うけど。 useradd 新規ユーザの作成 id ユーザの確認 stress dmesg lsmod ロード済みのカーネルモジュール一覧を表示する ちなみに、カーネルモジュールとは「カーネルの機能を拡張するためのバイナリファイルです。 例としては、ディスク・ネットワークカード等をLinuxカーネルで使用可能にするためのデバイスドライバなどがあります。 デバイスドライバは各ハードウェアベンダーから提供されることが多いです。 初期のUNIX系OSでは新しいハードウェアを使うにはカーネルの再構築が必要でしたが、 現在のLinuxカーネルは、必要ありません。 起動時に常駐カーネルがメモリにロードされ、必要に応じてロード・アンロードが出来るようになっています。 です。いつか自分でも自作してみたいきはだいぶしていますねー。 modprobe カーネルモジュールのロード、アンロードを行うコマンド 「カーネルモジュールとは、Linuxカーネルの機能の一部を、カーネル本体とは別にロード、アンロードできるように分離したサイズの小さいバイナリファイルです。多くの場合、ハードウェアにアクセスし、操作するためのドライバ部分がカーネルモジュールとなっています。 ドライバ自体をカーネルに組み込む古い方式では、ハードウェア構成を変更した場合に、カーネルの再構築が必要になります。現在では、ほとんどのドライバがモジュールとして提供されているため、ハードウェア構成変更後は、必要なカーネルモジュールをロードしてカーネルに組み込むだけで対応できるようになっています。 modprobeは、モジュールの依存関係を確認し、必要なモジュールがあれば同時に組み込むといった処理も行います。モジュールの組み込みには内部的に「insmod」コマンドを用いており、取り外しでは「rmmod」コマンドを使っています。 」 ってことですね。 FHS (Filesystem Hierarchy Standard)について /bin コマンドファイルが入っている。すべてのユーザが利用するコマンドが保存されているディレクトリ。lsとか、echoとか。 ここに入っているコマンド全部覚えておいて損はないと思いますけどね。 bash fusermount netcat su bunzip2 grep netstat sync busybox gunzip networkctl systemctl bzcat gzexe nisdomainname systemd bzcmp gzip ntfs-3g systemd-ask-password bzdiff hciconfig ntfs-3g.probe systemd-escape bzegrep hostname ntfscat systemd-hwdb bzexe ip ntfscluster systemd-inhibit bzfgrep journalctl ntfscmp systemd-machine-id-setup bzgrep kbd_mode ntfsfallocate systemd-notify bzip2 keyctl ntfsfix systemd-sysusers bzip2recover kill ntfsinfo systemd-tmpfiles bzless kmod ntfsls systemd-tty-ask-password-agent bzmore less ntfsmove tar cat lessecho ntfsrecover tempfile chgrp lessfile ntfssecaudit touch chmod lesskey ntfstruncate true chown lesspipe ntfsusermap udevadm chvt ln ntfswipe ulockmgr_server con2fbmap loadkeys openvt umount cp login pidof uname cpio loginctl ping uncompress dash lowntfs-3g ping4 unicode_start date ls ping6 vdir dd lsblk ps wdctl df lsmod pwd which dir mkdir rbash ypdomainname dmesg mknod readlink zcat dnsdomainname mktemp red zcmp domainname modeline2fb rm zdiff dumpkeys more rmdir zegrep echo mount rnano zfgrep ed mountpoint run-parts zforce egrep mt sed zgrep false mt-gnu setfont zless fbset mv setupcon zmore fgconsole nano sh znew fgrep nc sleep findmnt nc.openbsd ss fuser nc.traditional stty /lib 共有ライブラリを保存するディレクトリです。 共有ライブラリが何なのかわかる？ ...

オブジェクトストレージとは？ tiledbの使い方の基本 まず、知っておきたいのは、TileDBはmariadbやmysqlののようにサーバクライアント方式のデータベースではないということ。どちらかというと、sqliteやhdf5のように、ライブラリとして提供されているものだと思ってほしい。しかし、なんとデータの実態はリモートに置いておいて、httpでそのデータを取ってくるってこともできる。この時に、オブジェクトストレージってのが使われます。 で、c++とpythonの二つがあるけど、使いやすいし、今回はpythonでやろうと思う。環境構築はいたって簡単。condaとかで新しい環境を作って、 pip install tiledb をするだけです。 非常に簡単！で、ここからは使い方ですね。 import import tiledb 空間とスキーマを定義し、 # Don't forget to 'import numpy as np' dom = tiledb.Domain(tiledb.Dim(name="rows", domain=(1, 4), tile=4, dtype=np.int32), tiledb.Dim(name="cols", domain=(1, 4), tile=4, dtype=np.int32)) schema = tiledb.ArraySchema(domain=dom, sparse=False, attrs=[tiledb.Attr(name="a", dtype=np.int32)]) データベースの名前を定義 array_name = "quickstart_dense" tiledb.DenseArray.create(array_name, schema) 重要事項 上のarray_nameっていうので、データのディレクトリが指定されます。ただ、ここには、次のような形式でパスを指定することもできるし、 リモートにあるオブジェクトストレージにアクセスすることだって可能です。こんな感じです。 array_name = 'file:///home/usrname/my_array array_name = 's3://bucket-name/array-name' みたいな感じですね。ここで出てきたs3っていうのが、僕にとっては初耳の知識でした。結構web業界では使われてるみたいですね。 amason simple storege service (amazon s3)とは、オブジェクトストレージサービスです。 ブロックストレージというのがいつも使っているハードディスクとかssdとか、あの辺のやつね。 じゃあオブジェクトストレージとは何か？って話なんだけど、 まあ簡単に言うと、ファイルシステムが入っていななくて、データ単体をオブジェクトとして保存している、というかんじ。 Object storage systems typically do not have a traditional file system hierarchy within them. Instead, they store data as objects, each with its own unique identifier (often called a key) and associated metadata. These objects are typically organized in a flat namespace rather than a hierarchical directory structure. In a traditional file system, you have directories (folders) that contain files, and you navigate through the hierarchy to access your data. In contrast, object storage relies on a flat namespace where each object is stored independently and accessed by its unique key. This approach simplifies data management and makes it well-suited for storing large volumes of unstructured data, such as images, videos, documents, and backups. オブジェクトストレージはファイルシステムを持っていなくて、フラットなデータストレージ上にキーとそのデータを保管しているんだね。key-valueストアだね。その構造についてだけど、実際にハードディスクへの書き込みをするコンポーネントが合って、メタデータを管理するコンポーネントがあって、httpでのアクセスに対して処理をするコンポーネントがある。 ...

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単位を取得可能です。履修登録を忘れないようにお願いします。