Teem Geekを読んで

チーム

チームは個人の生産性や幸福に直接影響する ソフトウェア開発はチームスポーツ

  • 素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのはリスクの高い大きな賭け
  • 検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神
  • バス係数(「プロジェクトメンバーが何人バスに轢かれたらそのプロジェクトが破たんするか」という数値)を高める

邪魔されない時間があったとしても間違ったことをしていたら時間のムダ →できるだけ同じ空間で作業をする

邪魔されないまとまった時間が必要=クリエイターの時間

A:「break point, tenshotanaka」
tenshotanaka:「ACK」

HRT

  • 謙虚(Humility) 自分は絶対に正しいわけではない。常に自分を改善していく必要がある。

  • 尊敬(Respect) 相手を一人の人間として扱い、その能力や功績を高く評価しよう

  • 信頼(Trust) 自分以外の人は有能であり正しいことをすると信じよう。

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるもの
 https://gyazo.com/6dcfdf3c96b5b5b619c5b5933633b9cc

チームでの振る舞い

  • ほんのすこしの手間が大きな見返りにつながる。組織を使う必要があることを認識し、組織を自分の仕事に使うことを学べば、組織を自分の要求に合わせられるようになる。

  • 何かを成し遂げるための関係を構築する

  • 批判の配分と対応
    • 批判するべきなのは、オブジェクトではなく、振る舞い。
    • 相手に対する疑問ではなく、自分の疑問として謙虚に聞く
「このメソッドの制御フローは完全に間違ってますよ。みんなが使ってる標準的なxzxyyコードパターンを使うべきです。」

→「この部分の制御フローがよくわからないのですが、xzxyyコードパターンを使えば読みやすくなるでしょうか?」
  • 学習のための時間をのこす チームのなかで局所最適化してしまうと学ぶのをやめてしまうこと。 → コンフォートゾーンの外側に自分を置く

  • 影響を受けやすくする 影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。

文化

  • チームの文化の基礎を作るのは、チームや会社に最初からいるメンバーたち。
  • チームの文化の定義、維持、制御に責任を持つのは、かならずしもリーダーではなく、チームメンバー。

  • 強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的。

  • 強固な文化を構築すると「自己選択的」になる

  • 優秀なエンジニアは他の優秀なエンジニアと働きたいと思っている。

  • 優秀なエンジニアは優秀なチームリーダーを求める
  • チームがエゴを持つのは大丈夫だけど、個人がエゴをもつのは良くない
  • 意思決定をする際の衝突を解消するプロセスそのものではなく、衝突を解消するプロセスを持っていること、それを守っていることが重要
  • 前向きな批判をしてくれる友達や同僚を見つけたら、貴重な存在なので、手放さないようにしておきたい

  • 成功する文化のコミュニケーションパターン

同期的コミュニケーション(ミーティング) < 非同期(チャット)
できるだけ多くの人が、プロジェクトの文書からすべての情報を取得できることが重要
  • ハイレベルの同期 集中するにはやらないことを決めること

効率的なミーティング

  • dailyは15分なら問題ない。
  • 新しいものを設計するのであれば、ミーティングに5人以上参加させてはいけない

1.絶対に必要な人だけを呼ぶ 2.アジェンダを作ってミーティング開始前に配布する 3.ミーティングのゴールを達成したら時間前でも終了する 4.ミーティングを順調にすすめる 5.ミーティングの開始時間を強制的に中断される時間(お昼休みや就業時間)の前に設定する

  • FaceToFace を過小評価してはいけない。

leader

  • エンジニアは代替可能な労働者ではなく、数ヶ月間かけて新しいチームに追いつく。
  • リーダーの役割として最も重要なのは、執事や召使のように、チームに奉仕すること
  • 友人関係とチームをリードすることを混同してはいけない。

  • リーダーの仕事は、チームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきこと

  • ミスをしたときに謝るということ、失敗したときに謝罪できるリーダーは尊敬される

  • エンジニアが相談をもちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決をするのを手伝ってほしいから。問題を整理したり調査したりすることで彼が自分で問題解決できるように支援する

  • リーダーは、障害を取り除くための答えを知る必要はない、取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。

  • チームに安心感を与えればリスクを取れるようにできる。

  • 言えないようなことや知らないことがあれば、そのように伝える。→ 答えがわからないことを聞かれたときは答えがわからないと言う。

  • 褒め言葉のサンドイッチは、本当に伝えたいメッセージを聞いてくれないので避ける。

  • フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかが重要

  • 時間を作ってチームの幸せを計測する

  • 1対1のMTGのあとに「何か必要なものはある?」と質問する
  • オフィスのそとに生活がないと考えてはいけない(家庭が大変な時期に余裕を与えておくと納期が迫ったときに長時間労働をしてくれたりするもの。)
  • チームメンバーのキャリアを追い求める(有能なリーダーになりたければ、そのメンバーの暗黙的な目標を明確にして、どうすれば実現できるか考えるべき。)
  • リーダーになって間もないころ(自分でやったほうが早くても、できるだけチームに仕事を任せる)
  • チームをリードした後(自分で手を汚す。チームの尊敬を集めることができるし、仕事のペースが上がるから。特に誰もやらないような仕事を担当する。)
  • 自分自身を置き換えようとする
  • 事を荒立てるときを知る
  • できるだけ多くの情報をチームに共有すべきだが、チームに関係ない組織の話でわずらわせる必要もない。
  • チームのいいところをフィードバックする
  • 優秀なリーダーは取り返しがつくかどうかの判断に優れている。

有害な人の対処

  • やりたくないことを明確にする。
  • 排除するのはあくまで振る舞いであり、特定の個人ではない。
  • 完璧主義を回避する
  • 返信した方がいい相手とそうでない相手を区別する
  • 有害な人の放つ辛辣な言葉の中にも有用な知恵が埋もれている
  • 長期的に考える

    • 短期的にはチームの注意や集中を無駄にしても長期的にはプロジェクトにメリットがあるだろうか?
    • その衝突は有益な方法で解決できるだろうか? 上記の答えがノーの場合はできるだけ早くその振る舞いを中止する必要がある。
  • HRTをベースにした強い文化はかけがえのないもの。

  • 技術的に貢献できる人は確実に交換可能。短期的なメリットのために文化を妥協する必要はない。

  • 多くは、誤解や見当違いが原因。

立ち回り

  • 誰かを説得するときは、あらかじめ賛同してくれる人を探しておいて、対象となる相手との会話の中でアイデアについて触れてもらう(提案や要求を出してもらう)と成功率が上がる。

  • 攻撃的な仕事(ユーザーに見えるもの)と防御的な仕事(プロダクトを長期的に健全にするためのもの)があり、防御的な仕事で政治的な信頼性を獲得することはできない。→ 技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3~1/2をかけない。

  • 自分の仕事に関係がなくても、他の人の仕事を手伝うようにすれば、いづれ誰かが喜んで手伝ってくれるようになる。

  • 親切の経済で少しだけ信頼を稼ぐことができる。

忙しい人にお願いする方法

3つの箇条書きと行動要請のテクニック

問題について説明する(最大)3つの箇条書きと、一つ(一つだけ)の行動妖精がふくまれる
箇条書きは短い文章にする(改行なしで1行にまとめること)
行動要請もできるだけ短くすること

良いプロダクト

  • エンジニアは客観的に高品質で効果的なものが売れると思っている → 多くの人間は論理と感情を同じだけ使い、マーケティングの人間は感情操作に精通している。ソフトウェアに対する感情的な知覚に配慮しなければならない。一分後にどのように感じるか。

  • マーケティングの人には必要以上に保守的な見積もりを伝える。Googleはプロダクトの機能を事前に予告しない

  • 簡潔でよく考えられたユーザーインターフェース

  • プロダクトの最初の体験が超重要

  • ソフトウェアを技術系と非技術系の両方の人に使ってもらい、最初の1~2分を観察する。

  • アプリケーション速度(科学的に言えばレイテンシー)の重要性

  • 成功しているソフトウェアというのは、問題を限定してそれをうまく解決したもの。あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題をうまく解決している。

  • コードを書く側の都合ではなく、ユーザーに集中しよう。

  • 複雑なことであっても、簡単なことをしているように感じられるようにするべき。

名言

  • 「人間は断続的なバグの大きなかたまり」
  • 「自分は自分の書いたコードではない」
  • 「できるだけ約束は小さくして、届けるものは大きくしたほうがいい。それでノーと言う機会が増えるとしても、できないことを約束しない。頻繁に締め切りを守らなかったり、機能を落としたりしていると、会社の人は信頼してくれなくなる。」
  • 「ダウンロードではなく、利用されなければならない。」
  • 「エンジニアの文化は「事実」に満ちあふれている。」
  • 「ソフトウェア以外のことに注意と集中を浪費しない。」

Reference from

www.amazon.co.jp

DOM構造を作ったりするときに王道を見つける方法について思ったことがあるので書く

なんかhtmlとかって実際同じビューを作ろうとおもえば、例えばheaderとかfooter作る上だといくらでも書ける。でも使うタグもたくさんあるし、こういうレイアウトのときはどうしたほうがいいか。そういうのは、w3cのdocsを読むか、googleseo周りの部分を見ればなんとかなる。結局RTFM。でも具体的な事例とかはそういうとこには必ずしも書いてないから、海外の王道サービスを見る。google docsとか、AirBnBとか。そういうとこ見ればわりかし、王道っぽいDOMになってる気がする。だから困ったら、公式ドキュメント&有名所、技術力高い世界的なサービスを参照する。

MCSS

MCSS(Multilayer CSS) OOCSSとBEM

  • BEMでいうところのBlockとそのElementとModifierはまとめて同じ場所に記述されるべき。
  • 可能な限りクラス名を略称にする

1.Foundation

SMACSSでいうところのBase

2.Base

SMACSSでいうところのModule

下層のレイヤーからの上書きを禁止することによって、レイヤーの混同とそれによる複雑化、破綻のリスクを抑える

3.Project

Baseレイヤーコンポーネントよりも具体的なページを構成する要素。登録フォーム、ログインエリアのブロック、コメントリストのような要素

4.Cosmetic

下層のレイヤーコンポーネントには含まれないような、ちょっとしたスタイルが含まれる。リンクカラー、少数のプロパティで構成されるCSSクラス(.font-sizeXL .margin-tL)、グローバルなModifier

  • Cosmeticレイヤー自身も含め、例外のコンテキストレイヤー以外のレイヤーから上書きできない。

Context 特定のブラウザやデバイス向け、またはログイン中の時にメディアクエリによる特定条件化にある場合などに、例外的なスタイルを用意するためのレイヤー

https://gyazo.com/4badd505e41a2fa68043fd785c7a8bd6

Reference from

http://operatino.github.io/MCSS/

Difference between mixins, extend and %placeholder

Mixins

A mixin lets you make groups of CSS declarations that you want to reuse throughout your site.
@mixin message($color) {
  border: 1px solid #ccc;
  padding: 10px;
  color: $color;
}

.success { 
  @include message(#333); 
  border-color: green;
}

.error {
  @include message(#333);
  border-color: red;
}
.success {
  border: 1px solid #ccc;
  padding: 10px;
  color: #333;
  border-color: green;
}

.error {
  border: 1px solid #ccc;
  padding: 10px;
  color: #333;  
  border-color: red;
}

Extend/Inheritance

Using @extend lets you share a set of CSS properties from one selector to another. It helps keep your Sass very DRY.
.message {
  border: 1px solid #ccc;
  padding: 10px;
  color: #333;
}

.success {
  @extend .message;
  border-color: green;
}

.error {
  @extend .message;
  border-color: red;
}
.message, .success, .error, .warning {
  border: 1px solid #cccccc;
  padding: 10px;
  color: #333;
}

.success {
  border-color: green;
}

.error {
  border-color: red;
}

%placeholder

Placeholder selectors have the additional property that they will not show up in the generated CSS, only the selectors that extend them will be included in the output.
%message {
  border: 1px solid #ccc;
  padding: 10px;
  color: #333;
}

.success {
  @extend %message;
  border-color: green;
}

.error {
  @extend %message;
  border-color: red;
}
.success, .error{
  border: 1px solid #cccccc;
  padding: 10px;
  color: #333;
}

.success {
  border-color: green;
}

.error {
  border-color: red;
}

Difference between mixins, extend and %placeholder

  • difference between mixins and extend
# mixin
+.success {
+  border: 1px solid #ccc;
+  padding: 10px;
+  color: #333;
+  border-color: green;
+}

+.error {
+  border: 1px solid #ccc;
+  padding: 10px;
+  color: #333;  
+  border-color: red;
+}

# extend
-.message, .success, .error{
-  border: 1px solid #cccccc;
-  padding: 10px;
-  color: #333;
-}

-.success {
-  border-color: green;
-}
  • difference between A and B
# extend .message
+ .message, .success, .error, .warning { 
# extend %message
- .success, .error{ 

Limitations

Since @extend works by adding a selector to another selector without duplicating any of the properties it's actually impossible to join selectors in different @media blocks.
%icon {
  transition: background-color ease .2s;
  margin: 0 .5em;
}

@media screen {
  .error-icon {
    @extend %icon;
  }
  
  .info-icon {
    @extend %icon;
  }
}
You may not @extend an outer selector from within @media.
You may only @extend selectors within the same directive.
From "@extend %icon" on line 8 of icons.scss
@media screen {
  %icon {
    transition: background-color ease .2s;
    margin: 0 .5em;
  }
}

.error-icon {
  @extend %icon;
}

.info-icon {
  @extend %icon;
}
@media screen {
  .error-icon, .info-icon {
    transition: background-color ease .2s;
    margin: 0 .5em;
  }
}
@extend doesn't work between rules in different @media blocks.

Conclusion

  • コンパイル後のcssでより簡潔(冗長ではない)になるのが、mixinより、extend
  • CSSには書き出されない別のセレクタから継承(@extend)されるためだけの専用セレクタが%placeholdar

Reference from

http://sass-lang.com/guide https://sass-guidelin.es/#extend https://sass-guidelin.es/#mixins https://www.sitepoint.com/sass-mixin-placeholder/ http://thesassway.com/intermediate/understanding-placeholder-selectors

!important

6.4.2 !important rules

CSS attempts to create a balance of power between author and user style sheets. By default, rules in an author's style sheet override those in a user's style sheet (see cascade rule 3).

cssはauthorとuserでバランスを取ろうとする。 デフォだとauthor > user になる。

However, for balance, an "!important" declaration (the delimiter token "!" and keyword "important" follow the declaration) takes precedence over a normal declaration. Both author and user style sheets may contain "!important" declarations, and user "!important" rules override author "!important" rules. This CSS feature improves accessibility of documents by giving users with special requirements (large fonts, color combinations, etc.) control over presentation.

user, author 両方 !importantだった場合 author < user

Declaring a shorthand property (e.g., 'background') to be "!important" is equivalent to declaring all of its sub-properties to be "!important".

backgroundとかにimportantとか使うとその子の要素にも影響する

The first rule in the user's style sheet in the following example contains an "!important" declaration, which overrides the corresponding declaration in the author's style sheet. The second declaration will also win due to being marked "!important". However, the third rule in the user's style sheet is not "!important" and will therefore lose to the second rule in the author's style sheet (which happens to set style on a shorthand property). Also, the third author rule will lose to the second author rule since the second rule is "!important". This shows that "!important" declarations have a function also within author style sheets.
/* From the user's style sheet */
p { text-indent: 1em ! important }
p { font-style: italic ! important }
p { font-size: 18pt }

/* From the author's style sheet */
p { text-indent: 1.5em !important }
p { font: normal 12pt sans-serif !important }
p { font-size: 24pt }

参照したドキュメントは、CSS 2.1のものだった。 https://www.w3.org/TR/CSS2/cascade.html

こっちはCSS3の最新のドキュメント https://www.w3.org/TR/css3-roadmap/

だから!importantは非推奨

SMACSS

命名規則

.alert {
- .alert.success {
+ .alert-success {
- .alert.warning {
+ .alert-warning {
- .alert.error {
+ .alert-error {
…
.warning { // 汚染されてしまう

ベースとなるコンポーネント名を名前空間として継承した命名にすること - クラス名の重複によるスタイルの強豪と汚染のリスクを減らせる - クラス名を見て、どのコンポーネントの拡張かがわかる - セレクタの詳細度を減らせる