vgo使うとき二段階認証を有効にしたgithubアカウントでプライベートリポジトリのパッケージを利用する
~/.gitconfig に次の内容を記述する $ cat ~/.gitconfig [url "git@github.com:"] insteadOf = https://github.com/ GIT_TERMINAL_PROMPT=1 をつけて go get する $ go get プライベートリポジトリのパッケージ
~/.gitconfig に次の内容を記述する $ cat ~/.gitconfig [url "git@github.com:"] insteadOf = https://github.com/ GIT_TERMINAL_PROMPT=1 をつけて go get する $ go get プライベートリポジトリのパッケージ
GoのプロジェクトをDockerで動かすことがあると思う. 知らんけど. まぁきっとあるんだろう. ちなみに私は何度かある. 私がよく使うDockerfileの設定を書いておく. Dockerのimageをbuildするときに気を使うことが一つだけある. それはimageのサイズを小さくすることである. 何も考えずにGoのプロジェクトをbuildすると多分こんな具合だろう. FROM golang:latest WORKDIR /go/src/hogehoge.com/who/bar COPY . . RUN set -e \ && go build -o /bin/bar main.go WORKDIR / RUN set -e \ && rm -rf /go/src CMD ["bar"] 流石にここまで雑に書くことはなかなか無いだろうが, 一応ビルドして掃除までしている. だが小さくするには不十分である. まずGoのDocker imageがそれなりに大きい. 2018-12-12のlatestの段階で774MBある. $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE golang latest df6ac9d1bf64 3 weeks ago 774MB Goはシングルバイナリのビルド物を生成する. なので実行時にコンパイラは必要ない. GoのbaseになってるDocker imageはDebianである. なのでGoのdocker imageでバイナリを生成してDebianのimageにうつしてやればいいじゃんてなるだろう. Debianのlatestのimageは101MBである. 小さいように見えるがまだダイエットが可能である. alpine Linuxというもっと小さいDocker imageが用意されている....
12/7 (金) に長野県がやっているときどきナガノの制度を利用して長野県へ行ってきた. 長野県にはよく行く(今年20回くらい?)のだがときどきナガノを利用するのを忘れて普通に行ってしまうミスをしてしまう. 今回は忘れずに利用することができた. 行った場所は八ヶ岳とかの拠点で有名な茅野(今年5回目くらい)で茅野駅直結のワークラボ八ヶ岳を利用した. ここのコワーキングスペースのいいところは駅から近いのと御飯食べれるところが近い, 広いしwi-fi安定してるし人が少なくて静かだということである. とりあえず良い. 多分また利用する機会があるので良さはその時に書くとして, そこで何を作っていたかと言うとmessage queueを実装していた. queue worker式のシステムを構築するとき全体の処理速度を制限したい時がある. そのときworker側で制限するのは大変である. worker側でやるとするとworker同士が通信して誰かが全体の速度計算してみんなにこれ以上通信しないでねって教える必要がある. それは大変そうだし作りたくない. なのでqueueのほうで制限することにした. 作ったものはvalveMQというもので, 裏側がmysqlになっていてアプリケーション側はスケールすることができる. まだ試験的な実装なので設定項目とかは作り込んではいない. そういえばこれだけは言っておきたい. 八ヶ岳Octetのソフトクリームは絶対食べるべき.
だいぶ書くのが遅くなってしまったが先週の土曜日, つまるところ11/17にヤマノススメでおなじみの三つ峠に登ってきた. 今年の三ツ峠は二回目である. 前回は天気が悪く山頂から何も見えなかったが今回はいい感じに晴れてくれた. コースは登りは三つ峠駅から登り, 下山は河口湖方面へ下った. ヤマノススメの聖地ということもあり三つ峠駅でヤマノススメでお馴染みのキャラクターたちが出迎えてくれた. ヤマノススメではひなたがあおいに富士山をサプライズで見せる計画で登ってたけど三つ峠の駅のホームから富士山見えるし登山道からもいたるところから見えるし『これは隠し通すの無理だわwww』ってなった. これは股のぞきからの富士山である. 結構気温も寒く紅葉はすでに終わったものと思っていたがいい感じに紅葉していた. ヤマノススメであおいちゃんが登ってるとき闇落ちしていたが, 三つ峠の駅の方から三つ峠に登ると結構急登が続く. あおいちゃんは運動苦手な子設定だが実際運動苦手な子が登るとたしかに辛いと思う. 八十八大師のあたりまで行くと急登がほぼ終わるので行く人は頑張ってください. ちなみに日向ぼっこしてるみたいで可愛い. 山頂からは富士山が見えるのはもちろんのこと, 南アルプス, 八ヶ岳などが一望できた. せっかくめっちゃよく見えたのに南アルプス, 八ヶ岳方面の写真を取り忘れた… ちなみに富士山は近いだけあってめちゃくちゃでかい. 写真は山頂からじゃないけど. ヤマノススメでも言及されていたが三つ峠の屏風岩はクライミングの方で有名である. 自分はまだ技術がないので登れないがいずれは屏風岩も挑戦したい.
これは結構前に作ったネタなんだけども, 何らかのアプリケーションをつくったとき設定をjsonだったりyamlで管理することがある. そのとき秘密情報は隠したいみたいな案件があったとする. 設定ファイルをまるごと暗号化してもいいが, jsonとかだとkeyは暗号化せずvalueだけ暗号化しておいたほうが管理上都合がいい時がある. というわけでcryptexというものを作った. cryptexはmap型のvalue部分のみを暗号化するパッケージである. cryptex自体がサポートする暗号化の手法はrsa暗号とAWSのKMSを利用した暗号である. type Encryptor interface を満たす実装をするとほかの暗号方式にも対応が可能であるように実装してある. 暗号化したり暗号化された情報を復号する機能の他にコマンドラインツールを実装したときに使えるように less で内容を確認する機能や任意のエディタを立ち上げ(デフォルトはnano)て編集する機能を提供している. 編集したりlessで確認するときはユーザーに暗号化と復号を意識しなくてもできるようにしている. 質問やバグ報告はissueから受け付けます. 英語でも日本語でも良い.
この間の土日(11/10-11)にかけて剣山から三嶺にかけてを縦走してきた. 立冬を迎えたこともありそれなりに寒かった. とはいえ天気は最高の秋晴れでお盆のとき剣山登ったときと違い最高の景色を見ることができた. クリックで拡大 剣山-白髪避難小屋の道は距離は長いがあまり高低差が少なくあるきやすかった. とはいえ丸石避難小屋と白髪避難小屋の間に一部道が分かりづらい場所は存在したり補助ロープのある場所があるので注意がひつようである. またほとんどが低いクマ笹なので開放的で景色も良い. ただし風邪が強いともろに影響を受けることに為るので注意が必要である. 白髪避難小屋に関しては見た目本当に何もない小屋である. 実際トイレもなにもない. クリックで拡大 自分が到着したときすでに2張りのテントが立っていた. 小屋に到着したとき16時ごろであったがすでに結構寒かった. ちゃんと冬用の装備をしていてよかったと思う. 特に日没後は一気に寒くなった. 日の入りを楽しむかと思って外に出たら凍えるかと思った. 日の入り頃の白髪避難小屋付近の様子 ちなみに宿泊場所なので携帯の電波状況を書いておくとKDDI, docomo, Softbankは小屋の中では使えない. KDDI, docomoは小屋の外なら使えた. 20時頃星をみに外に出た. めっちゃ寒かったがすごくきれいだった.(語彙力がない) 三脚持ってこなかったので上にしか向けれなかったのが悲しい. 次は持ってこよう. クリックで拡大 1日目は21時に就寝した. そとは霜柱ができるくらい寒かったが小屋の中は終始10度くらいで快適であった. 二日目は3:30頃に起床した. 三嶺の山頂で日の出を見るためである. 寝袋だったりマットなどの片付けを終え4:00に出発した. とりあえず寒かった. 月も出てなく暗かったが踏み跡はわかりやすかった. この日の日の出は6:30頃だった. 三嶺の山頂付近は最後の方が鎖場である. 300mくらいで150mくらい標高を上げた. 結構辛かった. 6:00くらいだった間に合わないかと思った. 間に合ってよかった. クリックで拡大...
電話番号の判定をやりたくてつくり始めた. 一応ルールがあるらしい. 細かい解説はqiitaに存在していたので割愛する. とりあえず作り始めたやつはこれ(tel-num-parser). 使い方 参考実装です. 電話番号であるかどうかと種別が取得できます. package main import ( "fmt" tnp "github.com/ieee0824/go-tel-num-parser-jp" ) var telList = map[string]string{ "東京都庁": "03-5321-1111", "東京都庁2": "03(5321)1111", "東京都庁3": "0353211111", "国土交通省": "03-5253-4150", } func main() { for k, v := range telList { fmt.Print(k + ": ") fmt.Println(tnp.IsTelNumber(v)) } }
ガソリン製品を利用する時期ですね. 冬将軍と戦うためにはやっぱりガソリンですよ. そもそも冬とか関係なくガソリンを燃料にした製品よくない? これは内燃機関の話ではなく, 光源としてだったりとか熱源としての話なんだけど. 白金懐炉とかいいよね. ガソリンランタンとかいいよね. ガソリンシングルバーナーとかいいよね. なにがいいかって燃料がガソリンってだけでなんか強そうだしかっこよくない? ちなみに自分が使ってるシングルバーナーは新富士バーナーの ストームブレイカー SOD-372 とコールマンの スポーツスターII です. はじめに購入したのはコールマンの方ですが重たいのと大きいのと消火に時間かかるのと時々機嫌が悪いときがあるので新富士バーナーのストームブレイカーを山に持っていっている. 癖の強いコールマンのバーナーも嫌いではないのでゆっくり時間が取れるキャンプとかには持っていく. ストームブレイカーもスポーツスターIIもどちらもプレヒートせずに点火して使える(安定するまで待つ必要はある)らくでいいなと思っている. あと少々寒くても使える. -10度くらいでも問題なく使えた. それより寒いところでは試してないがガソリンの引火点は確か-40度あたりだったはずなので冬のオイミャコンとか行かなければ大丈夫(オイミャコンは-71度記録したらしい.さすがロシア格が違う.)だと思う. 近頃のランタンは安全面だったり重量面だったり扱いやすさの点で光源にLEDを利用したものが多い. そんな中ランタンにもガスやガソリンを利用したものが存在している. ガスやガソリン式のものはLEDのものに比べて巨大なものが多い. ガスランタンは一部小型のものも存在する. 例えばプリムスの IP-2245A-S やゆるキャン△のなでしこが使っている ルミエールランタン などである. それに比べてガソリンランタンは例外なくでかい. ガソリンランタンだとコールマンのものが結構有名だと思うがシングルマントル式の 286A740J とか有名だが, 本体重量1.4kgあり高さが30cmほどある. まぁキャンプ用途なので大きさは問題ないが山でテント泊するときには持っていけないよねってなる. 想定されない用途なので仕方ないが. とはいえ大きくてつよそうなコールマンのガソリンランタンすきなんですけどね. 明るいしバッテリ式と違って温度にあまり影響されないし良い. でもやっぱりガソリンランタンも小さくて気軽に持ち運びできるのがほしい. 新富士バーナーさんお願いしますよ. ストームブレイカーみたいに気軽に扱えてとテント泊登山のときでも気軽に持っていけるガソリンランタン開発してください. 可能なら燃料缶もストームブレイカーとかMUKAストーブとかのと互換性があると嬉しいです.
golangでSQSのqueueの一覧を取得しようとしたときこんなふうに書くことができる. package main import ( "fmt" "github.com/aws/aws-sdk-go/aws" "github.com/aws/aws-sdk-go/aws/session" "github.com/aws/aws-sdk-go/service/sqs" ) func main() { c := &aws.Config{ Region: aws.String("ap-northeast-1"), } svc := sqs.New(session.Must(session.NewSession(c))) list, err := svc.ListQueues(&sqs.ListQueuesInput{}) if err != nil { panic(err) } fmt.Println(list.String()) } このように書いた場合 github.com/aws/aws-sdk-go/aws/credentials とか github.com/aws/aws-sdk-go/aws/stscredes とかを利用していない. つまり利用されるawsのアクセス権限の元になる情報は ~/.aws 以下に設定された情報だったり ECSの場合はtaskRoleARNに設定された情報となる. 私が上記の実装をした上でdocker containerをビルドして実行したときハマったことを書こうと思う. ECSは標準出力の内容をcloud watch logsに出力することができる. 上記の実装を実行したと気次のようなエラーが出力された. For verbose messaging see aws.Config.CredentialsChainVerboseErrors panic: NoCredentialProviders: no valid providers in chain. Deprecated. はじめはtask roleにsqsのアクセス権限を忘れたことによって発生していた問題かと思ったが違った. ECS上でコンテナを動かしたとき特に何もしない場合はtask roleで設定した情報を元に権限が設定される. 実際のところ裏側ではAWS SDK側で 169.254.170.2 にアクセスしてメタ情報からクレデンシャル情報を引っ張ってくる....
フォーマットが決まっていない文字列から日付を推測するgolangのpackageを作った. fdateという. fdate の f は ふわっと(fuwatto) の f である. フォーマットが決まっていない文字列というか半角数字の羅列から日付として成り立つように組み立てるというのが正しいが. 日付として成り立つ区間の年度を1945~今の年にしてはあるが fdate.MIN_YEAR() と fdate.MAX_YEAR() を上書きすると定義を書き換える事ができる. 使用例は次のような感じである. package main import ( "encoding/json" "fmt" "log" "github.com/ieee0824/fdate" ) func main() { strs := []string{ "2018/10/21", "2018-10-20", "197211", "19720101", "19800824", "1980824", "200011", "200021232", "2010年1月1日", } for _, v := range strs { d, err := fdate.PickPossibleDate(v) if err != nil { log.Println(err) } bin, _ := json.MarshalIndent(d, "", " ") fmt.Print(v, " = ") fmt....