コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

BEMとMindBEMdingの命名規則の違い

Tips CSS

BEMを元にした考え方がMindBEMdingなんですが、地味に命名規則(というかModifireの使い方)が違うのでメモ

比較元

BEM

Quick start / Methodology / BEM

MindBEMding

MindBEMding – getting your head ’round BEM syntax – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts

違う部分

Modifireが違う

BEM

The modifier name is separated from the block or element name by a single underscore (_).

とあるので、Modifierの区切りは単一のアンダースコア、_ で区切り

.block-name_modifier-name {...} /* Block + Modifier */
.block-name__element-name_modifier-name {...} /* Block + Element + Modifier */

MindBEMding

-- で区切り

.block-name--modifier-name {...} /* Block + Modifier */
.block-name__element-name--modifier-name {...} /* Block + Element + Modifier */

参考リンク

バックグラウンドで動かしているdockerコンテナを確認して止める

Tips Docker

手順を忘れるのでメモ

環境

$ docker -v
Docker version 18.03.1-ce, build 9ee9f40

やり方

1.消したいもののIDを確認する

$ docker ps

そうすると動いているもの一覧が出てくる

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                      NAMES
e0598e6d418c        example_web         "prehook 'dockerize …"   23 minutes ago      Up 23 minutes       0.0.0.0:3333->3333/tcp   example_web_1
37ca6557ed89        mysql:5.7           "docker-entrypoint.s…"   23 minutes ago      Up 23 minutes       3306/tcp                   example_db_1

2.消したいもののIDでstop

$ docker stop {{止めたいCONTAINER ID}}

$ docker stop e0598e6d418c
e0598e6d418c

参考サイト

docker でよく使用したコマンドの覚え書き - Qiita

anyenvのrbenvで最新のrubyを使えるようにする

Ruby Tips

rbenvって入れてから後のrubyのバージョンに関してはrbenvをアップデートしないといけないので、そのやり方

やり方

rbenvを最新にする

$ cd ~/.anyenv/envs/rbenv
$ git pull origin master

ruby-buildもアップデートする

$ cd ./plugins/ruby-build/
$ git pull origin master

参考サイト

Ruby以外の言語を学んで来た人が、初めてRailsでrspecを書く前におさえておくと幸せになれるかもしれない話。

Ruby 雑記

『view以外はrspecでテスト書かないとマージさせません』となって初めてrspecをかかざるをえない状況（仮）の人がいたら教えてあげたいエッセンス的な雑記

抑えておいてほしい知識

  • 文法
  • 大まかなグループの使い分け
  • 純然たるrspecの機能とそうでないものの見分け

文法

一番ベストはEveryday Rails - RSpecによるRailsテスト入門を読んでもらうのが体系的にもRailsのお作法的にも嬉しい。

そうでなければはJunichi Itoさんのrspecシリーズ記事を読んでもらうのがベスト

大まかなグループの使い分け

文法に近い部分になるんですけど、describe とか it の使い分けの部分、特に実行時の制約がないから普通に適当に書いてもかけてしまう。お手本のコードがあまりポリシーがなかったりすると新しく参加した人はさらに混乱するので基礎的な使い方は理解したい。

ここらへんはEveryday Railsを読んでれば理解できる部分ではあるが、読んでない場合に最低限抑える場合は下記記事などがおすすめ

純然たるrspecの機能とそうでないものの見分け

これはどういうことかと言うと『factory bot』の記述や『rails_helper.rb』などに書かれたプロジェクトごとの独自拡張のこと。

例を出すと

let(:user) { create(:user,:email_user,age:24) }

などは create があまりにも自然に出てくるのでFactoryBot.create であるというのも知らずにrspecの標準機能であると 自分は最初勘違いしたし、他にもそうやって勘違いしている人を数名見た

そのためfactory botを利用している場合は使い方をさらっと見ておくといいし、helperクラスの記述は見ておくと良いし、教える側に立った際は一言添えておくと良いかもしれない。

参考としては以下のようなページがある（どれも旧称のFactoryGirl名義）

進んでもらうときの考え方

『サヨナラBetter Specs!? 雑で気楽なRSpecのススメ - Qiita』にも書かれているのですが、ちゃんと書こうとすればするほど、便利記述を使い始めるのでマッピングがよくわからなくなってきます。

なので

  • 最初はわかりやすいようなSimpleな記述で書いている
  • matchaは expect().to eq() のようなイコールとするものを基本として、あんまり便利なものを使おうとは考えずに書いてみる
  • 日本語が母国語のエンジニアしかいなければdescribeやcontextなどの部分に無理に英語は使わない。テストは理解しやすいほうに倒したほうがよい

というように愚直に平易な書き方で書いて、自身がスキルアップして冗長さを感じてきたら自分なりのやり方で洗練できればいいのかなと思っています。

Rubyで二次元以上の配列もしくはハッシュの値を取るとき、要素数などが不明確な場合、digを使うとスムーズに取れる

Ruby Tips

知ってそうで知らないシリーズメモ

環境

$ ruby -v
ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin17]

例

2次元以上のHashから値を取ろうとした場合、1つ目のキー指定時に対象のものがないと2つ目以降が取れない。

# サンプル配列
hash = {a: {b: "val"}}
#=> {:a=>{:b=>"val"}}

# 1個目の値が存在するものなら問題なくとれる
hash[:a][:b]
#=> "val"

# 1個目の値がないと nil に対して処理をするのでエラー
hash[:x][:b]
#NoMethodError: undefined method `[]' for nil:NilClass
#  from (irb):5
#  from /usr/bin/irb:11:in `<main>'

こういう場合にdigを使うと存在しない場合はnilを結果に返してくれる

hash.dig(:a,:b)
#=> "val"

hash.dig(:x,:b)
#=> nil

配列にも使える

ary = [[10,20],[30,40]]
#=> [[10, 20], [30, 40]]

ary.dig(0,0)
#=> 10

# ありえない引数を指定する
ary[10][0]
#NoMethodError: undefined method `[]' for nil:NilClass
#  from (irb):11
#  from /usr/bin/irb:11:in `<main>'

ary.dig(10,0)
#=> nil

関連リンク

月末でまったく時間がなかったので1回休み

日記

あまり使いたくなかったけど月末の送迎的な催しで一回休み。

おまけ

渋谷で催し物が開催されることになったので件のイベントの余波を知りたくてググったら、渋谷はライブカメラが設置されているのでいつでもようすを覗くことができる

【LIVE CAMERA】渋谷スクランブル交差点 ライブ映像 Shibuya scramble crossing

『Microservices Meetup vol.9 (FiNC App & Frontend)』に行ってきたよメモ

行ってきたメモ

Railsでマイクロサービス的なことをやり始めざるを得ない状況になりつつあるので、知見収集として Microservices Meetup vol.9 (FiNC App & Frontend) - connpass に行ってきたメモ

各発表の感想

マイクロサービスとクライアント：理想と現実の狭間で

感想

  • ウェルカムトークといいながらも、内容濃いめにFiNC社がやってきたことをざらっと紹介。
  • キャンペーンに応じてアプリのビルドが異なるものにどう対応していたのだろうと思ったけどなるほどという舵切り
  • あと普通に画面の情報がゴリゴリ必要なチュートリアルの部分をAPIで持つってどういう概念なんだろうって思った。

関連リンク

クライアントサイドから考えるマイクロサービス

感想

  • 開発者やチームにおいてコンテキストがずれないようなチーム運用の事例
  • 結構腐敗防止層とかエリック・エヴァンスのDDD用語が出てきてハイコンテキストな話だった、けどわかっている自分としては事例集みたいでめっちゃ興味深く聞けた
  • 作るものの対象は同じだし、iOS/Androidも複数人でやってると往々にズレがちなので「同意形成」が必要ってのはWebでもあんまり変わらいないなーという
  • 後半マイクロアプリみたいな話もあり、InstantAppとかの世界が出てくるのかなという気持ちに

関連リンク

マイクロサービスとクライアントとコンテキスト境界

感想

  • iOS文脈で話されるけど有用な情報を発信されているtakasekさんの話（どうでもいいけど背景が明るい色のスライド始めてみたかも）
  • こちらもDDD文脈が強いのでワードがわからないとちんぷんかんぷんになりやすい話だったが、コンテキスト境界は文字通りの意味なのでまだ理解しやすかったかも
  • ネイティブアプリ側の責務をただただ表示させるものとするなれば境界づけは簡単だけれども「分散コンピューティングの原則」が出てくるとなるほどな…という気分になった。（ここらへんはインゲームとアウトゲームの観点で考えるとよいのかも）

関連リンク

実践、BFF ~ BFFはFiNCのアプリで何を解決したのか

感想

  • BFFの役割を明確に表してくれている資料、いままでちょっとAPIGatewayと混同しているところがあったので整理された。
  • ネイティブアプリはサーバー対サーバーと違って通信環境の影響をモロに受けるので、リクエスト回数を減らすことが肝要ってのはなかなかリソース指向論になると置いてきぼりになりがちだなって思った
  • 話の中で出てきた「BFFはあくまでも参照系で、更新系はBFFに盛り込まないと決めている」というあたりがフロントエンドのための機構という納得感を醸成していた
  • サーバサイドKotlinでBFFはある種C#大統一論に似たものを感じた。

関連リンク

お礼ポイント投票機能をSPAに移植してMicro Frontendsを実践した話

スライドは見つけたら貼ります

感想

  • React + WebCompornentsでいろいろ試行錯誤した話の事例。
  • WebCompornentsやりたい…！って思ったけど前提として仕入れて布教する知識のレベルが高い、高すぎる！と思った
  • たぶんあまり踏み抜いている人が少ない話なので事例としてはすごく参考になるというか、いつか来るであろう世界のための予備知識にはなった
  • しばらくはiframe世界観がマターな正解なのかな…って感じ。

関連リンク

(飛び込みLT)

感想

  • 分散トレーシング失敗事例！って感じです。
  • やりたいけどやれないし、知見もない部分なのでありがたいし、Istio！みたいなところにできませんでしたの代替案は知見になった

関連リンク

全体を通しての感想

  • 現在Web,過去アプリをやっていたマンとしてはとても参考になる話の連続だった。
  • 懇親会で話していたんですがFiNC社のエリック・エヴァンスのドメイン駆動設計用語習得率ヤバいって気持ちがあった、普通に話しててバンバン用語が出てくるので頭の辞書ひっくり返すのに必死になってた
  • 立ち話セッションであった「共有的な部分をもっていくアプローチ」としてクロスプラットフォーム（ReactNative,KotlinNative,Flatter）の話になっていたけど、「両OSを同じコードで出したい」から「モバイル体験でずれないドメイン処理を共通化したい」ってモチベーションが異なっているのでここらへんの視点は斬新だったし、むしろクロスプラットフォームの利用は後者の視点で取り組まれるべきだなと思った
  • 全体的にコンテキスト境界とか集約をどうもってくるかって話は重要だなって感じ。先行してマイクロサービス化すると間違って切っちゃったときに結構大変という話はみなさん語られていたので、ちゃんとビジネスロジック分析がなされたあとにやるべきという感じ。

他のかたの感想記事