slowjet

is a part of a carburetor

bundle installのjsonでエラーになる

El CapitanからHigh Sierraにアップデートしたら特定のRubyのバージョンでエラーがでるようになって

$ bundle install --without production --path vendor/bundle

~~ 中略 ~~

Fetching json 1.7.5
Installing json 1.7.5 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

~~ 中略 ~~

An error occurred while installing json (1.7.5), and Bundler cannot
continue.
Make sure that `gem install json -v '1.7.5'` succeeds before bundling.

エラーには

$ gem install json -v '1.7.5'

しろって書いてあるけど、これやると解決するどころか余計ひどくなる。 Rackupでopensslがどーのみたいなエラーが出るようになったりした。。

$ bundle update json

後にもう一度

$ bundle install --without production --path vendor/bundle

で解決した。

参考

stackoverflow.com

地雷になる仕様

十分な吟味が必要

前もって、どれくらいのヤバさを秘めているのかを知っていれば、仕様策定時に一歩引いて考えられる

  • 履歴
  • ユーザーがトークンを持っていない
  • (トークンなしでの)データの先勝ち
  • HTMLなどの生のデータを保存

こういうことをしてると危険

全ての仕様は全てのメンバーと共有するものです

  • 仕様を全員が把握しないまま決めてしまった
  • 機能追加、仕様変更時のコードの上塗り
  • 仕様を限定的なものと考えること(こういう仕様だからこれは出来ないと決めつけること。仕様は変わるものと割り切って、クローズドなコーディングをしない)

複数人で開発するときに揃えたほうがいいところ: 機能の実装方法を揃える

例えば、ドラッグアンドドロップを実装するとして、一人はjQueryプラグインを使って実装して、もう一人はHTML5のDrag & Drop APIを使って実装してしまわないように、その時にいる人たちで話して統一する。後から入った人には、その旨が分かるようにメモでもWikiでも仕様書でもいいので残しておく。

GitHubのPull Requstの運用について

GitHubを使っている案件で、何か新しい機能を実装したとき、バグを修正したときはPull Requestを出しているんだけど、これの運用メモ。

  • 作業中は[WIP](Work In Progress)をタイトルの接頭辞にする
  • 作業が完了したら[WIP]を削除する
  • 完了したら誰かに@で確認をお願いする
  • 関連する動作の確認手順を洗い出して、その操作や動作が当たり前のことだとしても、コメントに明記する

重要なのは、最後の2つで、誰かに確認してもらうところ。特に確認手順を書くというところで、確認をお願いした相手がどういう操作で動作するのが正しいかを伝えるのはもちろん、自分で気づいていない項目がないかに気づけたりする。

大量にDOM操作(追加削除変更)をしていて、そのDOMのイベントを監視している場合は確実にイベントの監視を解除する

キの字だけど、最近イベントの監視を解除し忘れていたのが原因で、メモリリークを起こしてブラウザをクラッシュさせるという事案があったので。

View.render = function() {
  this.$someElem = $('<div class="someView"></div>');
  this.$someElem.on('click', function() {
     ...
  });
  this.@$el.append(this.$someElem);
};
View.destroy = function() {
  this.@$someElem.remove();
  // ノードを削除するときにイベントを削除していない
};

こういうのを連続的に大量に行ったりしていると、メモリリークを起こすので、ノードを削除するときは必ずイベントの監視を解除する。

View.destroy = function() {
  this.@$someElem.off().remove();
  // ノードを削除するときにイベントを削除するようにした
};

追記

jQueryのremove()はoff()も一緒にやってるから、問題はここではなかったようです。

GitHubとかによくあるEmoji(iPhoneぽいやつ)のライセンスは誰のもの?

まあAppleですよね。 だから、あのEmoji画像が含まれたリポジトリがMITになってたりするんだけど、ライセンスをよく見ると、Emoji画像はAppleに帰属するとか書いてあったりする。

つまり、基本的には使っちゃいけないんですよ。

米国内でも絵文字はあるが著作権やライセンス等の縛りがあり、オープンソースなOSに添付できるようなものはなかったようだ。現在はAppleが訴訟しないという希望的な観測の元でAppleが作った絵文字が使用されていることが多い模様。

ちょっと笑ってしまった。希望的観測てw僕も希望的観測でパズドラ風アイコンジェネレーターを作ったから、なんか気持ち分かるwジェネレーターは公式広報のムラコがこっちのオリジナルフレームを使ったりして、暗黙の了解的なところがあります(?)。プロデューサーに聞こう聞こうと思って、なかなか聞けてない…

話が脱線しましたが、PhantomOpenEmojiというオープンソースプロジェクトがKickstarterで募集されてたようで、GitHubリポジトリがあります。

これはオープンソースだそうで、誰でも使いたいときに使えるみたいですねー。とは言え、ライセンスは

This project is licensed under a combination of the SIL Open Font License, MIT License and the CC 3.0 License [CC-By with attribution requirement waived]. In short you can use everything in this repository however you want. Please see the LICENSE.md file for finer details.

でプロジェクトのLICENSE.mdを見てください。

複数人で開発するときに揃えたほうがいいところ: イベントの命名規則

イベントドリブンな持ち回しだと、よくあるイベント名を使いがち。例えば、クリックされたっていうのから、コントローラーとかへ渡す場合

// view
_onClick: function(ev) {
  this.someController.trigger('click', @);
}

// controller
_eventify: function() {
  this.listenTo(someView, 'click', function() {
    // hogefugapiyo
  }
}

みたいなの。例えば後から違う人がViewのコードを見て、clickだけで検索すると、、clickって他でもよく使ってるから検索結果に出てくるよね…イベント名は固有で分かりやすい命名規則にしておくと、メンテナンスがしやすそう。

// view
_onClick: function(ev) {
  this.someController.trigger('clickSomeView', @);
}

// controller
_eventify: function() {
  this.listenTo(someView, 'clickSomeView', function() {
    // hogefugapiyo
  }
}

イベント名にコロン使うとかドット使うみたいな話はまたどこかで。