Posts

なぜunixドメインソケットはipソケットよりも高速なのか？ っていう話や。まあ、ちょっと事情があってプロセス間通信をしたいんですわ。 でね、わざわざtcp/ipのレイヤーまでもっていかなくてもいいやない、ローカルホスト内の通信だったらね。だからunixドメインソケットを使おうと思っているんだけど。 じゃあ、なんでunixドメインソケットのほうが高速なのかって話だけど、その理由はもう単純で、tcp/ipまでいかないからやな。もう少し具体的に書こうか。 コンテキストスイッチが発生しない まあ、ネットワーク通信ってシステムコールだからコンテキストスイッチが発生するんだよね。 でもドメインソケットはネットワーク通信ではないから、コンテキストスイッチが発生しないって話や networkStackを通る必要がない コンテキストスイッチが発生する以外にネットワーク通信はいろいろとオーバヘッドが大きいです buffer間でのコピーが発生する UnixドメインソケットはsharedMemoryを使って通信する。 って感じや。 でもソケットって扱いめっちゃ面倒じゃないですか。どうやってやるんですか？ わかるー。マジでわかる。httpはsocketの上で作られているからね。扱いが簡単なんだよね。 あー、でも、ドメインソケットを使ってhttp通信をすればいいってことじゃね？いやそうやん！ そうしましょう。そのやり方を教えましょう。 kwi

c/c++のライブラリーとビルドについて ということで、c++でのヘッダーライブラリ関係を全部まとめます。 ソースコードをビルドするまでの流れ プリプロセス(preprocess) #include は、<> 内に指定したヘッダーファイルの中身をソースコード内に組み込むプリプロセッサ指令です。 つまり、定義が書かれていない入出力関係だけが書かれたヘッダーを読み込むことは、プロトタイプ宣言にだいぶ近いものがあると思います。 コンパイル (compile) 入出力関係を保ったまま、ソースコードを アセンブル (assemble) リンク (link) 制御のジャンプ先をここで決めるわけです。 ヘッダーとライブラリはセット 関数をオブジェクトファイルにして、ほかのソースコードから呼び出せるようにしたものをライブラリといいます。 ソースコードはライブラリの入出力を知るために、ヘッダーファイルを使います。だから絶対にセットなんです。 3rd partyのライブラリをどうやって使うか？ ライブラリの配布のされ方はいろいろあると思うが、大きく分けて二つに分けられると思う。 パッケージマネージャーを通してライブラリを配布 githubでソースが公開されているライブラリを配布 どちらも最終的に使うときには、ヘッダーをインクルードして、ライブラリをリンクするんですが、使えるようになるまでが違います。ってことです。 1. パッケージマネージャーを通してライブラリーを入手する方法 これは、aptとかでライブラリを入手するあれです。 例えば、boost libraryとかは、aptで次のようにインストールできるわけですね。 sudo apt install libboost-all-dev で、ソースコード上でプログラムを使いたいときは、例えば、 #include<boost/asio.hpp> でインクルードして、 さらに、ビルド時にライブラリーをリンクするのを忘れないでください。はい。 ただ、boostはどうやらheader-only-libraryということで、リンクする必要はなさそうですね。はい。大丈夫です。 2. githubでソースが公開されているライブラリ githubからソースコードを持ってきてください。 で、最近は大体cmakeがついていますね。cmakeでMakefileを作って、makeでビルドしてください。 最後に、make installでライブラリとヘッダーのデフォルトのサーチパスにヘッダーとライブラリをおいてくれます。ハイよろしく。

ことはじめ 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にします！それだけです！！ ただ、起動時のスクリプトでそれをやるとなんでかわからんけどうまく行かないんです。だから、下を見てください。 まとめ 起動時に一度ワイヤードキーボードでバッシュに入って設定を変更したあと、無限にワイヤレスが使えるようにすればいいです。ということで一回目の起動のときはどうしてもワイヤーが必要になります。