indilog

都内でLMSとか作ってます✨

Heroku PostgreでStagingのデータをReview Appsにimportする方法

herokuのreview appsを使っていて、review appsでstagingにあるデータをそのまま使ってデータがある状態で検証を行いたいと思い、とりあえずインポートする方法を探してみたところ、以下の方法でできた💡

手順

  1. Stagingのherokuの管理画面からOverview⇨Heroku Postgres f:id:indigo-lain:20180628095239p:plain

  2. Durabilityタブ内のBackupからDownload f:id:indigo-lain:20180628095308p:plain

  3. DownloadしてきたファイルをDropbox等外からアクセスできる場所にアップロードする

  4. Review AppsのHeroku PostgresからImport先のDBの名称を確認 f:id:indigo-lain:20180628095333p:plain

  5. 以下コマンドを実行する ここ 参照

heroku pg:backups:restore <"DropboxにあげたファイルのURL"> <Import先のDB名> <appの指定など>

peco+historyで便利なhistory

設定

brew install peco でpecoをインストール

~/.zshrc で以下を追記

function peco-select-history() {
  BUFFER=$(\history -n -r 1 | peco --query "$LBUFFER")
  CURSOR=$#BUFFER
  zle clear-screen
}
zle -N peco-select-history
bindkey '^r' peco-select-history

使い方

Ctrl+r でpecoを使ってインクリメンタルに history から検索、実行ができて便利 ✨

みんなのGo言語 Day3

今日もつらつらと読んだことをメモ的に書いていく📝

Goを始める

学習方法

プロジェクトを始める時に気をつけること

  • リポジトリ名は小文字にする
  • リポジトリディレクトリ構造は $GOPATH/src/{レポジトリのドメイン}/{レポジトリのパス} の形にする
    • 例えば、githubなどにホストする場合は github.com/indigolain/myprojなどにする
    • 配置は $GOPATH/src 以下にする
  • ディレクトリ名はパッケージ名と同一にする
  • testdataやアンダースコアで始まるディレクトリはgoのパッケージとして見なされない
  • サブパッケージはサブディレクトリを切って作る
    • 基本的にはあまりサブパッケージを作ることはない、ロガーのパッケージなどはあり得る
      • 他のプロジェクトから使えるような形を維持できるようにすることを考える
    • コンポーネントはtypeを定義して、typeごとにファイルを分けるのが良い
  • サブパッケージはインポートする際に絶対パスで指定する
    • go getなどで取ってくる時に絶対パスである必要がある

外部パッケージの依存管理について

  • goにはvendoringという依存管理の機能がついている
    • プロジェクト配下に vendor/ 以下にパッケージを配置すれば、GOROOTや$GOPATHよりもそちらを優先して読み込むようになっている
  • これに加えてglideを入れると、bundlerのGemfileやGemfile.lockなどと同じようなglide.ymlとglide.lockというファイルが生成され、これをコミットしておくことによって同じバージョンの外部パッケージが、他の環境でもインストールできるようになる github.com
    • また、テストなどであるパス以下のディレクトリを対象にしている際に ./... などとするが、vendoringを使用している場合、vendor以下のディレクトリに対してもテストが行うことになってしまうが、 go test $(glide novendor) などとすると、それを無視してテストを実行できる

Makefileをタスクランナーとして使う

  • rubyのrakeのように、makeを使うことで、初期のsetupやその他のテストをここに定義しておく
  • 複雑なタスクになってくる場合は、 _tools/ などにシェルスクリプトを配置して、呼び出すようにする

みんなのGo言語 Day2

エディタと開発環境

今回はgoで開発する際に使われるlint系のツールやエディタでよく使われているツールの紹介だった👀

vetとgolint

vetはエラーの可能性がある箇所を指摘してくれるツール

vet - The Go Programming Language

golintはスタイルなどを指摘してくれるツールみたい

golint - GoDoc

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を省けるやつっぽい?
  • goreを終了させる時は control+d
  • 他にもここら辺を入れておく

github.com pretty print良い。作者k0kubunさんだ 👀❗️


github.com

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とは BlockElementModifier の頭文字を取ったもので、構成する要素をそのどれかに当てはめて命名していく方法。

それぞれの要素

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などを使うことによってオブジェクト指向的に実装ができていてわかりやすい 😀
    • というかsass/scssなどのcssメタ言語を使わないといちいち各クラスに書かなきゃいけないので成り立たなそう 💭
    • 逆に上の方のクラスを書くときにはどのくらいがデザイン的には良い抽象化なのかを考える必要がありそう
  • 基本的にクラスはネストさせない形で書いてあげる形になる 👍
    • 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