みんなのGo言語 Day3
今日もつらつらと読んだことをメモ的に書いていく📝
Goを始める
学習方法
- A Tour of Go を一通りやってみる
- ドキュメント を読む
プロジェクトを始める時に気をつけること
- リポジトリ名は小文字にする
- リポジトリのディレクトリ構造は
$GOPATH/src/{レポジトリのドメイン}/{レポジトリのパス}
の形にする - ディレクトリ名はパッケージ名と同一にする
- ディレクトリ単位でパッケージとなるため
- testdataやアンダースコアで始まるディレクトリはgoのパッケージとして見なされない
- サブパッケージはサブディレクトリを切って作る
- 基本的にはあまりサブパッケージを作ることはない、ロガーのパッケージなどはあり得る
- 他のプロジェクトから使えるような形を維持できるようにすることを考える
- コンポーネントはtypeを定義して、typeごとにファイルを分けるのが良い
- 基本的にはあまりサブパッケージを作ることはない、ロガーのパッケージなどはあり得る
- サブパッケージはインポートする際に絶対パスで指定する
- go getなどで取ってくる時に絶対パスである必要がある
外部パッケージの依存管理について
- goにはvendoringという依存管理の機能がついている
- プロジェクト配下に
vendor/
以下にパッケージを配置すれば、GOROOTや$GOPATHよりもそちらを優先して読み込むようになっている
- プロジェクト配下に
- これに加えてglideを入れると、bundlerのGemfileやGemfile.lockなどと同じようなglide.ymlとglide.lockというファイルが生成され、これをコミットしておくことによって同じバージョンの外部パッケージが、他の環境でもインストールできるようになる github.com
Makefileをタスクランナーとして使う
みんなのGo言語 Day2
エディタと開発環境
今回はgoで開発する際に使われるlint系のツールやエディタでよく使われているツールの紹介だった👀
vetとgolint
vetはエラーの可能性がある箇所を指摘してくれるツール
vet - The Go Programming Language
golintはスタイルなどを指摘してくれるツールみたい
overcommitとかと組み合わせると捗りそう
もちろんCIなどに設定しても良いけど、gitのコマンドをフックして色々やってくれるovercommitみたいなものを使えばもっと捗りそうだと思った💡
PreCommitのタイミングで走らせればコミットされる前にチェックができて良さげ。 github.com
vetとgolintに対応してるみたいだった https://github.com/brigade/overcommit#precommit
みんなのGo言語 Day1
1.1 開発環境の設定
Goのインストール
- 前やった時にここら辺のインストールは終わってた
$GOPATHの設定
- ここの設定も前やった時に実施済みだった
- でもよくあるGOPATHの設定場所とかが載ってるの地味に嬉しいと思う。正しいものとかはないかもだけど、ベストプラクティスがあるんじゃないかとちょっと不安になるしね ☺️
go getを試してみる
- go getで$GOPATH配下に外部パッケージをインストールできるって丁寧な説明があるの嬉しい☺️
GoのREPLであるgoreを使う
gore -autoimport
でgoreを起動してみる- autoimportオプションは
- formats and adjusts imports automaticallyとある👀
- fmtをimportせずに使えてるということは多分importを省けるやつっぽい?
- autoimportオプションは
- goreを終了させる時は
control+d
- 他にもここら辺を入れておく
github.com pretty print良い。作者k0kubunさんだ 👀❗️
godoc.org ドキュメンテーションツール✨
こちらの補完ツールはvimを使っているため、代わりにvim-plug経由でvim-goを入れてみる github.com github.com
$GOPATH管理のためにghqを導入する
pecoで簡単にリポジトリ間の移動を行う
- 出たpeco👀❗️
- このツールはだいぶライフチェンジングなやつや
- historyと組み合わせて自分が実行していたコメンドを検索して取ってくるやつとか定義してて、結構便利☺️
- pecoってgoで書かれてたのか💡
Go製ツールのインストールについて
- 確かにpecoとかがgoで書かれているのであればgo getすれば良いけど、安定板とかを探してダウンロードしてくる必要がある
- なのでものによっては他のパッケージ管理ツールにダウンロードを任せるのが良い!全部go getで良いじゃんと思ったけどなるほどそういう違いが出てくるのか💡
- でもhomebrewとかのパッケージ管理ツールでは取り扱われていないツールなどは取ってくることができないので、github releaseから取得できるようにするためのツールを作っているらしい✨ github.com
みんなのGo言語 Day0
RailsとReactをただひたすら書き続けるのに疲れ、刺激を求め何か新しいものにチャレンジしたく、 A Tour of Go を一度さらっとやってみた後に表紙のGopherに惹かれこちらの本を買ってみた📕
スローペースな感じになりそうだけど、とりあえず記録のためにそれぞれのセクションで思ったこととかを書いていけたら良いなと思ってる💭 とりあえず今回ははじめにを読んで気持ちを高める💪
はじめに
メモリ管理やコンパイル速度など、前にC++をやっていた時に色々考えなきゃいけなかったものから解放されつつ、パフォーマンスが良かったり、かっちり型を指定できたりというところがすごく楽しみなところ。 別に動的型付けが嫌だというわけではないし、むしろ一度C++からrubyにいって動的型付けすげーって感動したんだけど、やっぱりあのかっちりした感じも良いよね☺️
あとスタイルについて矯正してくれるの良いよな、と思った。もちろんlinterとかを入れてチェックすれば良いは良いんだけど、色んなlinterがあったり、好みによって設定ファイルを書き換えたりする必要があったりで、戦争になったりする時とかもあるもんね。
コマンドラインツールの開発も楽しみ☺️どんなものが紹介されるんだろうか💭
BEMの書き方についてちょっとだけ勉強
BEMとは
BEMとは
Block
、Element
、Modifier
の頭文字を取ったもので、構成する要素をそのどれかに当てはめて命名していく方法。
それぞれの要素
Block
- 構成のルートとなる要素
- 継承元のクラス
Element
- Blockに所属する子要素
- 単体だと存在できない
- Blockの派生クラス
Modifier
- 元となるBlockまたはElementから変化した状態を表す要素
- クラスに所属するメソッドやアトリビュート/プロパティ
書き方
結構色々と書き方があるっぽい?以下は割と共通っぽい?
Block__Element--Modifier
みたいな形で、
- Elementの前には __
(アンダースコア2つ)
- Modifierの前には --
(ハイフンが2つ)
がそれぞれつく
また、複数単語から成り立つそれぞれの要素は -
(ハイフン1つ)を用いて単語を繋げる
他にも、
下記みたいな形で Modifier
は key_valueのように書く形になるなど
.item-nav__item--state_active
例
<div class="block"> <div class="block__element"></div> <div class="block__element--modifier"></div> </div> <div class="block--modifier"> <div class="block--modifier__element"></div> </div>
.block { width: 100px; } .block__element { width: 20px; margin-left: 10px; color: blue; } .block__element--modifier { @extend .block__element; color: red; } .block--modifier { @extend .block; margin-top: 20px; } .block--modifier__element { @extend .block__element; background-color: green; }
この例を見て思ったことは
- 確かにextendなどを使うことによってオブジェクト指向的に実装ができていてわかりやすい 😀
- 基本的にクラスはネストさせない形で書いてあげる形になる 👍
bootstrap
とかと相性悪かったりするかも?(bootstrapはネスティングとかをしている形式で、ネストが深い方がスタイルが優先されるはずなので 💭 )
- 要素毎にスタイルを定義する形になるので、要素ごとにファイルを分けてあげた方が良さそう 👀
- 共通のものは共通のものでまとめる形で
- やっぱ一つのクラス名が長すぎになる可能性が・・ 😅
その他
Roleなどを考える場合は、どちらかというとそれが Modifier
になる?
タブ的なものだったら以下のような形かな 👀
.nav .nav__tabs .nav__tabs--role_teacher
参考
http://blog.ruedap.com/2013/10/29/block-element-modifier https://qiita.com/mrd-takahashi/items/07dc3b4bad027daa2884
プログラミングと自分
高校の時から夢見てた職業としてのプログラマに半年前になり、ふと自分はどのようにして学生時代PCやプログラミングと関わってきたのかを振り返ってみたくなったので軽く書いてみる。
PCとの出会い-小学校低学年
自分が生まれて初めてPCを触ったのは小学生低学年の時だった。 もうほぼほぼ憶えていないが、家にはデスクトップPCがあって、そのPCでブラックジャックを遊ぶのがすごく楽しかった気がする。
異国でコンピュータに触れる-小学校中・高学年
親の仕事の関係で、渡米することになった。 転校先の現地校では、こんな感じのIMacがずらーっと並んでいて、かっこいいなと思い、パソコンを使う授業がすごく楽しみだった。
この時はまだプログラミングをすることはなく、ひたすらブラインドタッチの練習や、オフィス系のソフトの操作などをやっていたような気がする。 友達と遊ぶにしてもPCゲームがメインだったので、親に自分のPCを買い与えられるまで、ひたすら家族のPCを一日中占拠していたのが懐かしい。 この時はダイヤルアップ接続だった気がする、やはり懐かしい。
日本に戻ってきて-中学生
中学生の頃もひたすらPCゲームをやっていた覚えがある。ダメ人間感がすごい。
夏休みはひたすら起きたらゲームを始め、飲み食いをほぼせずに一日が終わるまでひたすらオンラインゲームをしていた。
この時に技術の授業で初めてHTMLというものに触れた。交通系ICカードを紹介するサイトを作っていたのだが、リンクを貼ったり、画像を貼ったりと、自分の手で綺麗にサイトが出来上がっていくのを見てとても興奮した覚えがある。
プログラミング始め-高校生
ゲーム漬けだった中学生だったが、受験はアメリカ住まいで培った英語力でごり押し、なんとか無事志望校に受かることができた。
高校生になってからも相変わらずゲームが多かった気がする。頻度は少なくなっていたが、オンラインゲームは相変わらず継続していたし、PSPとかも出てきた影響もあり、時間があれば高校に集まってはみんなでワイワイとゲームをしていたことが多かった。
そんな中、ちょうど高校の選択授業でプログラミングの授業を2つ軽い気持ちでとることにした。中学生時代に味わったあの感覚をもう一度味わいたかったのだ。
しかしとった授業はC++とJAVAの入門。HTMLからこの2つの言語にいきなり入っていったので、初めて見るそれぞれの言語の書き方や考え方に少し戸惑った。
C++の授業はプログラミング大会か何かの問題をひたすら解く形式、Javaは指定の教科書を買ってくるように指示され、それを輪読して説明するというなかなかハードモードな授業だった。
特にJavaの夏休みの宿題は、Javaで「物理シミュレータ」を作って来いというとても範囲が広くて何を作れば良いのかわからない課題で、悪戦苦闘しながらブロック崩しを作ろうとして途中で挫折した覚えがある。でもその時は本当にその悪戦苦闘が楽しくて、いつの間にか徹夜もしてたし、うまくいかないところを絶対うまくいかせてやろうという気持ちに溢れていてがむしゃらにコードを書いては消してを繰り返していた。
ちょっと寄り道-大学生
大学生に入ってからは、サークルの活動で少しマイコンを触る機会があり、Cを少しやったり、研究室でC++やPythonを使っていたりした。 バイトでは初めてサーバの設定や、web系のプログラミングを始めるなど、徐々に職業:プログラマとしての土台が見え始めてきたところなんじゃないかなと思う。
特にサーバの設定はとても印象的で、少し高校時代の思い出が蘇るようなものだった。サーバの設定をするためのマニュアルを渡され、それを頼りにいろいろと設定を入れていくのだが、エラーなどがバンバン出てきて全然思うようにいかない。ひたすらネットで調べて色々と試してみて、最後には設定もちゃんと入り、動くようになってくれて、それはそれで達成感があったのは間違いないと思う。
こんな感じでメモっぽいものを書いてみたが、とても薄いものになってしまった気がする・・・。 もっと面白おかしく書くスキルを手に入れないとな、と思うのであった。
itamaeでsidekiqが使えるようにredisをremiからインストールする
問題
railsでActionCableを使ってアプリを作っていて、ActiveJobを処理させるためにsidekiqを導入しようとしたら、 epel
だとredisのバージョンが足りなかった。
github.com
# recipes/redis.rb package "redis" do options "--enablerepo=epel" action :install end service "redis" do action %i(enable start) end
解決
remi
から取ってくるようにするために、レシピを以下のように変更。
# recipes/redis.rb package "epel-release" do action :install end package "http://rpms.famillecollet.com/enterprise/remi-release-#{node[:platform_version][0]}.rpm" do not_if "rpm -q remi-release" end package "redis" do options "--enablerepo=remi" action :install end service "redis" do action %i(enable start) end
これでうまくsidekiqが起動、処理してくれるようになった🔪🔪🔪