もがき系プログラマの日常

もがき系エンジニアの勉強したこと、日常のこと、気になっている技術、備忘録などを紹介するブログです。

Ruby勉強その1(基礎の基礎)

はじめに

こんばんは。Go言語の勉強やりたいんですが、積本がやまほどあるのでそれを消化するのと、今後はRubyの案件もとっていけるようにRubyの勉強をしようと思っています。

ちなみにGoは別日でちゃんとやる予定です。本も買ってるしね。

とりあえず、phpしかメインで触ってなかった僕ですが、pythonはまぁまぁわかるようになったし、rubyへの言語ジャンプも、頑張れば可能かなと思っています。

チュートリアルやオンラインの学習サイトなど見ながら気になった点を忘れないように上げときます。

主にphpとの違いを列挙してみました。

やってみた

べき乗

phpでは pow() 関数を使って表現するけど、rubyは演算で可能みたい

puts 10 ** 5
# 100000

型変換

to_s とか to_i とかでやるみたい

puts "test => " + 10
# Traceback (most recent call last):
    1: from test01.rb:1:in `<main>'
test01.rb:1:in `+': no implicit conversion of Integer into String (TypeError)

puts "test => " + 10.to_s
# test => 10

if文

目新しい感じはなかったけど、elsifが面白かった。

elseifにしなかったのはなんでだろう。

message = "BBB"
if message == "AAA"
    puts "Yes"
elsif message == "BBB"
    puts "No"
else
    puts "???"
end
# No

unless

条件が正しくない場合に使うっぽい。

つまりif の否定式ってことだと思うけど、使い分けはどうやるんだろう?

rubyで動いているプロダクションコード見てみたい。

message = "AAA"
unless message == "BBB"
    puts "BBBではありません。"
end
# BBBではありません。

case

switchみたいな感じだと思うけど、switchより便利っぽい

score = 70
case score
    when 0..30
        puts "留年決定"
    when 31..60
        puts "追試決定"
    when 61..85
        puts "合格ライン"
    when 86..100
        puts "天才だ!"
end
# 合格ライン

times

数値の回数繰り返し処理を行う

forとの使い分けを知りたい

10.times{|i|
    puts i
}
# 結果
0
1
2
3
4
5
6
7
8
9

upto

数値から指定した数字まで繰り返し処理を行う。

これはtimesよりはforとのすみ分けができてそう。

10.upto(15){|i|
    puts i
}
# 結果
10
11
12
13
14
15

downto

uptoの逆

10.downto(5){|i|
    puts i
}
# 結果
10
9
8
7
6
5

redo

繰り返し処理をもう一度やり直す。

これが一番へぇとなった。

○○の処理の場合、繰り返すみたいな処理って結構あったりするから、これは地味に使えそう。

phpだとどうやってるかな・・・

同じ値で上書きしたりしてお茶を濁したりしてそう。。。

count = 0
10.times{
   count += 1
   if count == 5
       redo
   end

   puts count
}
# 結果
1
2
3
4
6
7
8
9
10
11

終わりに

phpとの違いがいろいろあっておもしろかった。

次も多分Ruby関係になりそう。

もしくは本読んだ書評。

まとまりないなこのブログ。

でもいいよね。備忘録だし。

sayonara sayonara

FEARLESS CHANGEを読んだ

はじめに

こんばんは。

FEARLESS CHANGE をよんでみました。

昔に買って、ずっと積本になってる本でした。。

今月・来月くらいまでは集中してGo言語の勉強をしようと思ってたんですが、先に積本消化しようと思い、重い腰を上げてやっと読めました。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

社内(チーム内)に新しいアイディアなり、ルールなり、サービスなりを広めて定着させるには、どのようにすればよいかという方法をパターン化して紹介されてます。

導入前に実践すべき方法や、導入中、導入後など現在の状況に応じて適用できるパターンが存在していて、知らず知らずのうちに実践していたというものもありますが、参考になるべきものばかりでした。

1〜48のテクニックの中で自分が、「お、なるほど」と思った、文章を抜粋して紹介したいと思います。

引用部分は各テクニックで僕が印象に残った文章というだけなので、引用部分がそのテクニックで伝えたいことではないです。

感想

1. エバンジェリスト

あなたの組織において、そのイノベーションがもつ可能性についてもっと学ぼう。しかし、あなた自身は専門家でないことを、常に認識しておこう。あなたが専門家の役割を担えると売り込んだり、できると思い込んではいけない。

人数が少ないスタートアップ企業だと、その導入したいアイディア(サービス)を本人しか知らないって状況はザラにあると思う。

なのである程度、自分が答えられるよう知識を蓄える必要がある。

ただ、自分以外に詳しい人が現れても、そこで悲観することはない。自分は「専門家」ではないから。

あたり前のことだけど、プライドが高い人とかは、ここに引っかかりそうな気もして、なるほどと思った。

2. 小さな成功

私たちはつい、成功を決定づけるドラマティックな「大きな勝利」イベントに、力を入れすぎてしまう。これは本当によくあることだ。最終的に求める目的地へ導いてくれる継続的な改善よりも、魔法の銀の弾丸に気が向いてしまうのだ。その結果ほとんどあらゆる仕事では、勝者として認識してもらえる機会なんて、ほんのわずかだ。

この小さな成功自体は、やる気を長持ちさせる方法として、よく言われてる手法だとおもうけど、仕事として置き換えたときに、ちょっと見え方が違った。

この改善のタスクはあんまり評価されないけど、実際に売上が大幅に上がったこのタスクは、すごく評価されて、その結果給与が上がったみたいなことってあると思う。

インパクト的に薄いタスクの評価も、きちんとしてもらえるほうが、こちらもありがたい。

↑は仕事の各タスクの話だけどw

アイディアを広めるために適用するとすると、例えばチームで持ち回りでブログ記事やQiita記事を書くってなった時とかに、はてぶ数とか、いいね数が例え少なくても、「いいね!」とかチーム内で言い合うことが大事って感じかな?

認めてもらえたことで次のアクションの起爆剤になると思う。

こういった「成功」を見逃すなよってことかな。

承認欲求的なところとも関わってきそう。

3. ステップバイステップ

チェンジエージェントが犯すもっともよくある失敗は、あまりに急いでたくさんのことをやろうとすることだ。彼らは、植物を上から見下して「成長しろ!もっと頑張れ!君たちにはできる!」と命令している庭師のようなものだ。しかし、どんな庭師でも、成長する意欲をもたせるために植物を説得するようなことはしない。そのかわり、大きな変化はゆっくりと始まり、時間をかけて着実に進化するということを理解している。

このたとえは、2の小さな成功とともに、なるほどと思った。

2の例えで言えば、いきなり社外に向けたカチッとした記事を書く前に、社内だけ共有されるQiitaTeamとかEsaとかで社内向けの記事を書くところから始めようぜ!って感じかな。

4. 予備調査

時にアイデアは組織で受け入れられるには、新しすぎたり、急進的すぎることがある。また、ベンダーや製品の好みなど、他の制約と衝突するかもしれない。強硬に進めることよりも、組織が変化を受け入れられるまで少しだけ待ってあげるほうがよいかもしれない。適切な効果が得られる時期まで、あなたのエネルギーをとっておくのだ。

4番目に来てるけど、このパターンが一番最初にやるべきことっぽい。

例えば新しい開発言語を導入するとき、当然だけど予備調査が必要になる。

でも、引用したとおり、開発メンバのスキルなども関係してくるから、よいと思って導入を急くよりも、今のチームにマッチするかなど、そのような調査が必要。

...当然か。

5. ふりかえりの時間

学習する組織を作るためには、プロジェクトについて議論する習慣を身につけなければならない。同様に、個人としても学習するため、私たちはふりかえるための時間を取らなければならない。リンカーン大統領はこう言っている。「我々は正しく行ったことより、正しく行えなかったことからより多く学ぶ」そして、そのための時間が確保できなければ、学ぶことはできない。

チームでのふりかえりというとKPTとかだけど、最近のKPTは「ふりかえりから学習する」というよりも、「ふりかえること」だけをやっている気がする。

いい気付きができた。せっかく振り返りの時間を設けてもらっているのだから、そこから学習することしなければ、あまり意味がない。

6. 協力を求める

常に完璧な信頼性と確実性を示すリーダーは、結果的に現実をやや歪曲する空間をつくりだす。一方で、自分の弱点を認めるリーダーには、人々は心を動かされ、驚くほど惜しみない手助けをしてくれる。

わかる。圧倒的なリーダーシップを持ってる人には、ある程度盲信してしまうっていうのはあると思う。

そのリーダーの方向性にチームが傾いちゃうので、そのリーダーがイノベーターだと、メンバーは疲弊しちゃいそう。

チームは一人で動くのではなく、みんなで動くもの。

7. ブラウンバック・ミーティング

午前中や午後よりも、昼どきのミーティグングの方が多くの人々の関心を引く一方で、ランチミーティングには参加したがらない人たちもいるだろう。彼らはランチタイムを休憩時間としてとらえているからだ。そんな人たちのために別のイベントをアレンジする必要があるだろう。

よくわかる。熱量的に同じ人であれば、たとえ休憩時間と捉えていても参加してくれるけど、そうではない人は参加したがらない。

自分がいるチームの場合は、昼よりも定時後酒飲みながら、ミーティングと言うスタンスではなく話し合いという感じが一番マッチしてそうだった。

これもステップバイステップでどんどん本格的なミーティングに移行できればなおいい。

8. コネクター

新しいアイディアがもつ価値を確信してもらえるよう、個人的な接触を試みるのだ。インフルエンサーたちが相手なら、説得はたやすいはずだ。たとえ説得が難しくても、時間を掛けるだけの価値はある。ひとたび彼らが興味をもてば、彼らの持つコネクションが、あなたが情報を広めるためにかけなくてはいけない努力を減らしてくれるからだ。

すごいわかる。

自分は社交性が低いから、自分がアイディアを広める場合はコネクターの存在が絶対必要。

身近にコネクターがいるのはとても心強い。

9. 何か食べながら

贅沢にする必要はない。たとえ食べ物がシンプルでも、このパターンにおける影響力は揺るぎない。食べ物は小さいミーティングにも影響力がある。二人の間であっても。

このあたり、飲み会とかただの宴会的なところとの差を明確にしておかないとだめだと思った。

そのために、酒はなしで、あくまで簡単な飲み物とお菓子くらいが一番いいとお思う。

10. 電子フォーラム

そのメディアを監視すれば、そこで得られるデータを変化にむけた活動の今後の動きに十分関心がある身近な支援者や経営層の支持者の説得に利用できる。

slackとかの特定チャンネルで情報を発信していくような感じだと思うけど、個人的には新入りの人たちにはハードル高い印象がある。 その点でWorkplaceは、書き込みの敷居が低いいいサービスだと思う。

11. アーリーアダプター

アーリーアダプターは、単なる改善よりも根本的な進捗について考えるビジョナリーだ。新しいというだけの理由でアイデアを歓迎する熱狂的なイノベーターとは違い、アーリーアダプターはそのアイデアの有効性をよく考え、アイデアをビジネス上のゴールに結びつけようと試みる。結果として、彼らはしばしば同僚からの尊敬を得て、よいオピニオンリーダーとなる。

イノベーターとアーリーアダプターの役割が違うのは理解できたが、自分の経験上、イノベーターのような動きをしている人は結果的にアーリーアダプターにもなっているような気がする。

自分は比較的スタートアップの企業で働いていたから、限られた予算・時間内で、なにがサービスにマッチするかというのを、探してきて試みるという、イノベーターとアーリーアダプターの2つの役割を担っている人ばかりだった。

そういう人達を見ていたので、自分もその立場になれるよう頑張っている。

12. 外部のお墨付き

成功の匂いに敏感な人たち向けに、可能ならば成功事例を含めてみよう。その出版物が対象者から信頼されていることを確認しよう。経営者は技術雑誌ではなく、ビジネス雑誌を読む傾向があるという例からも、対象者に注意することは重要である。

これはなるほどと思った。

当然だけど非エンジニアの人とはコンテキストが合わないのは当然。

こちらが伝える側の場合は、こっちが合わせてあげないと伝えたいものも伝わらない。

その上で、対象者が信頼をおいている外部資料などから成功事例を集める。

その資料には細かい技術の話はおそらくないけど、そのかわり、サービスにおいてどんなインパクトがあるということをストレートに書いてくれていると思うので、説得材料として効果が高い。なるほどー。

13. グループのアイデンティティ

変化への活動に名前を与えると、変化の存在と、なにを実現しようとしているのか、気付かせる助けとなる。人々がその名前を見聞きする機会が増えれば、彼らの関心が増して、より深く関わるようになる。

名前をつけるという当たり前の行為なので、全然意識したことなかったけど、グループ以外の人達には大事なものだと理解できた。

なるほど。

14. 達人を味方に

達人には謙虚さをもって近づこう。あなたは彼らから学ぶために近づくのであって、イノベーションのニュアンスすべてを彼らに教えるわけではないのだ。彼らに新しいアイデアを叩きつけるのではなく、徐々にアイデアを提示できるようちょうど十分となるようにして、達人に意見を求めよう。

大きい会社ならばこういう達人っていると思うけど、小さい会社だと難しいよね。

でも例えばフリーランスとかで働いてくれる人たちとつながれば、小さい会社でもこういう場面は出てきそう。

その際の話し方で、ここでも言ってるけど謙虚な姿勢ってのがめっちゃ大事になると思っている。

この辺できてない人って多いと思う。今のチームにもいるけども。

謙虚さっていうのってチームワークの中でとても大事だと思う。

「あの人謙虚だよね」っていう印象は与えるとは思うけど、決して嫌な印象ではないはず。

15. 空間を演出する

このパターンは、人々が新しいアイデアに関する最新情報について目にしたり議論したりする場所をつくり出すものである。「その場所に」留まってもらい、考えていることを分かち合ってもらうのである。その場所を訪れた人は新しいアイデアを進める仲間に加わることに興味をもってくれる可能性がある。

目に見えている場所を用意するのが重要みたいだ。

結構Slackのチャンネルつくって適当に招待するみたいなので終わっちゃっているケースがある。

それだと確かにあんま長続きしないケースがあった。

16. イノベーター

しかしながら、あなたはイノベーターに長い間、頼ることはできないだろう。イノベーターは次から次へと新しいものに興味をもつので、違う方に興味が移ってしまうのである。さらには、イノベーターは新しいアイデアをすぐ受け入れてしまうので、他の人には疑念を抱かせることにもなる。したがって、一般的にはイノベータはよいオピニオンリーダーにはなれないのである。イノベーターからの協力は、短期の門番のようなものと考えよう。もしそれ以上の働きをしてくれたら、ラッキーだと思おう。

あんまり出会ったことないイノベーター。アーリーアダプターのところでも話したけど、自分が今まで出会った人は、イノベーターとアーリーアダプターを兼務している人たちが多かった。

人数が少ない会社あるあるなのかもしれないけど...w

本当はイノベーター思考だけど、限られたリソースで自分の興味のある新しいことを試すために、導入可能かどうかまで検討する必要があるから、結果アーリーアダプターもやっちゃっているって感じなのかな?

17. やってみる

多くの人が、やればできるはずなのに何もしようとしないのは、まだ知識が十分ではないと思い込んでいるからだ。しかし、新しいアイデアを実際に試してみるまでは、学びの機会は得られない。自分自身で研究しよう。経験不足はライバルたちの絶好の攻撃材料になるが、うまくいった経験があれば反論は難しくなる。さらに、新しいアイデアの限界がわかってくるにつれ、過信を避けることができ、アイデアを有効利用するためのより現実的なアプローチ方法が見えてくるだろう。

これはそのまんま。

最低限チームにハマるか、プロジェクトにハマるか的なところの予備調査は必要だけど、それがOKならば、実際まずやってみようってことだ。

一人でやってもいいし、もし協力者がいれば一緒にやってもいいし。

とにかく実践してみよう。

18. 感謝を伝える

仕事なんだからやって当然、と考えるのは簡単だ。だってお給料もらってるんだから!しかし、人が幸せを感じたり貢献できたと思えるのは、認められたり元気づけられたりしたときなのだ。協力してくれた人にお礼として提供できるものが何もなくても、感謝の気持ちを表すだけならコストもかからないうえに、相手にとっては大変意義深いものとなるのだ。

基本的なことだけど難しいことだと思う。

最近プログラムとかでなにかを教える状況が多いんだけど、なかなか伝わらなかったり、何回も同じミスしてる人をみてるうちに、例えばその人になにか簡単なバグ対応をやってもらったときも、感謝を伝えるって気持ちがでなくなる時がある。

でも最近は、育ってきた環境が違うから、みんなが俺とおんなじじゃない。

って考えるようになって、少しだけ頭と心が柔らかくなった(個人的にセロリ思考とよんでいる)

どんな状況でも謙虚さと感謝って大事。

19. 次のアクション

学んだことを実際に仕事に適用できるかどうかを考えると、参加者は疲弊し、圧倒され、不安に陥ることがある。イベントがうまくいけば、参加者の行動をさらに刺激できる。参加者たちが部屋を出て行くまでに、その興奮をうまく利用しよう。参加者たちが、望ましい未来の明確な見通しを得てやる気になっていたとしても、次に何をすべきかわからなければ、進歩はわずかしかないか、もしくはまったくない。

せっかく勉強とかやったとしても、単発で終わっちゃうと、もったいない。

継続は力なり。

宿題っていいシステムだと思う。

20. 個人的な接触

全員と話そうとして、あなた自身を疲弊させてはいけない。あなたは誰をも納得させられるだけの力も個性ももっていないと自覚するのだ。あなたの話を聞きたがらない人がいたら、橋渡し役を探そう。

個人的な接触は一番抜けてたなと思った。

結構自分のアイデアを広める際は、いきなりチームにMTGで伝えたりしちゃってた。

でもやっぱりメンバーそれぞれのやる気だったり、時間だったりがあるわけで、俺がどんだけやったほうがいいよ!っていっても、なかなか伝わらない。

やっぱり一人ひとりと話でどんな形ならみんなが参加できるかってのを話し合うべきだった。なるほど。

21. 便乗

組織に長い時間を経て受け入れられた既存の習慣があり、新しいアイデアを受け入れるために、それらが役に立つかもしれない。もし、あなたのアイデアを既存の慣習の追加機能(add-on)として提案できれば、まったく新規で既存と異なるアイデアを導入する場合に比べれば、一部のルールや手続きを迂回できるかもしれない。

面白い考え方だと思った。

イデアの種類によるけど、確かに既存の社内 or チームのルールにすでに混ぜることも可能なものもある。

自分が導入したいと考えているアイデアがこのパターンを使えるかどうか、最初に考えるのがいいなと思った。

22. 種をまく

人は無料のネタは手に取るものだが、ごく一部の人だけがそれらを読んだり新しいアイデアに興味を持ったりするものだ。しかし、その影響力というものを過小評価してはいけない。「種」はごくまれにしか興味をかきたてないものだが、それが主要人物、たとえばコネクターアーリーアダプター、あるいは達人を味方にといった、あなたの代弁者となるような人たちに届くかもしれないのだ。

目立つところに自分のアイデアの資料なり何なりを置いておこうってことらしい。

あまり効果がないかもしれないけど、効果が得られた人がたまたま影響力のある人であれば、その効果は跳ね上がるってことだ。

これも同じで、とにかくやってみるってことだな。

23. 適切な時間

人はみな忙しい。しかし、比較的忙しくない時期もあるのだ。新しいアイデアに興奮していると、即座にみんなに話したがるものだ。しかし、現実に戻り、熱意を覚ますべきだ。よくないタイミングであなたの情報が飛び交うと、説得したい相手の人々を苛立たせて、あなたの目標への改宗者を失ってしまう危険性がある。

結構これも失敗しがち。聞いて聞いて状態になっちゃってすぐ話しかけちゃう。

でもそれってよくないよね。

相手も相手のペースがあるから。

自分の話をしたいならば、まずはタイミングを計らねば。

24. 定期的な連絡

人々がイノベーションを採用することを決めたとしても、その気が変わらない保証はない。人は常に自分の行った決定を補強できるような情報を求めている。常に新しい疑問を抱えている。もし答えを得られなければ、古いやり方に戻ってしまうかもしれない。

これも結構忘れてると思った。

一回チームでやろう!となったことは、常にみんな同じ水準のモチベーションだと錯覚してしまって、共有を怠ってしまっている。

これはぜひ改善したいなと思った。

25. 勉強会

勉強会における発見プロセスはすべてのタイプの学びに適しているわけではない。プログラム言語のような技術的なトピックは、学習者が問題に引っかかったときは熟練者の出席が必要かもしれない。さらにこのような探索的な手法が、すべての人に有効とは限らない。とくに、他人とのやりとりがあっても盛り上がらない人や貢献する人ではなく「スポンジ」である場合は役に立たないかもしれない。勉強会は学び方の一つにすぎない。組織における教えと学びの戦略全体の一部と考えるべきだ。

わかり味ある。

まさに例で挙げられているプログラム言語の勉強会ってよくあるけど、必ず効果的と思ったらだめだなと思った。

勉強会の参加自体にストレスを感じてる人もいるし、それはメンバーそれぞれ。

ここはやっぱり、個人的な接触で、どんな形の参加ならばストレスでないかなど、聞き出す必要がありそう。

26. テイラーメイド

人々の認識のフィルターを通り抜けるようなやり方で売り込めなければ、いかなる最高のアイデアでもインパクトを与えられない。そこでよくあるアドバイスは、「技術を売るな、仕事上の解決を売りなさい」だ。

テイラーメイドってなにと思って調べたら個別対応ってことらしい。

個人的接触で話す時に、その人達ごとに売り込み方を変えろってことかな?

ちなみにオーダーメイドと何が違うんだろうと思ったら、意味はおんなじで、オーダーメイドは和製英語らしい。

なるほど。

27. 著名人を招く

あなたのプレゼンテーションには忙しくて出られないという人でも、その分野におけるエキスパートから話を聴くためなら時間を割くかもしれない。信頼性のある講演者なら、人は講演者のいうことに感化されるものだ。

これってよくいう、何をいうかじゃなくて誰がいうかっていうことかな?

自分が言っても暖簾に腕押しな感じだけど、別の人が言うと効果テキメンっていうことってよくある。

これと一緒かな。ただ外部の人でかつ、著名人ってのが違うか。

なるほど。

28. 経営層の支持者

組織のあちこちから尊敬を受けている人物を探すこと。さもなければ、やっかいごとに巻き込まれてケチがつくことになりかねない。間違った種類の重役のサポートは、新しいアイデアが組織内で「ごり押し」されているといった印象を与える可能性がある。個人的な興味から新しいアイデアに乗ってくるような人物には注意すること。その役割が別の職務や組織に移ったら、その指導力も消えてしまうだろうから。

上層部を味方につければ勝ったも同然みたいなことを考えていた自分はこれを読んで、自分は考えが足りてなかったなと思った。

確かにここもやり方は注意しないといけない。失敗すると、確かにゴリ押しされているからやらざるを得ないみたいな印象を他の人に与えてしまう。

これは意識しよう。

29. 正式な推進担当者

新しいアイデアの成功はあなただけのものではないことをはっきり理解すること。多くの場合、成功への熱意の中にある正式な推進担当者は、他の人たちの役割を促進したり確保するよりも、自分で何でもやってしまいがちだ。みんなを巻き込む、協力を求めるを使いなさい。どれだけ他の人々の作業を促進したかで成功を図ろう。

おなじ熱量の人が近くにいれば、一緒にやろうっていうようになるけど、そうじゃない人たちの場合は、自分は一人でやっちゃっている。この辺も改善事項ってことだな。

みんなを巻き込むことをできてないってことだ。

30. アーリーマジョリティ

イノベーターとは違い、アーリーマジョリティは新しいアイデアゲートキーパーをの役割を担うにはアイデアの採用が遅すぎる。アーリーアダプターとは違い、彼らはフォロワーであり、通常、組織のオピニオンリーダーのポジションには立ってない。だが彼らは、早期採用者と比較的後になって採用する人々とのあいだのつなぎ目となってくれる。このつなぎ目は、アーリーアダプターとアーリーマジョリティの間のギャップもしくは「キャズム」を越える橋となる。新しいアイデアを主流にするためには、キャズムを超えなければならない。

この本の前半で書いていたけど、イノベーターとアーリーアダプターの人数を足しても全体でいうと超少数派なので、全体の3分の1の数に相当するアーリーマジョリティを仲間に入れることができて、やっと定着への一歩を踏み出せるといった感じだった。

個人的にアーリーマジョリティの立ち位置ってそれこそ経営層に多そうなイメージ。

ちがうかな?

ちなみにキャズムって何?と思って調べると溝、裂け目という意味だった。

31. 達人のレビュー

通常、経営層と開発者は近くにいる達人の判断を信じる。特に彼らが長期にわたって関わりをもっている場合はなおさらである。達人は最近の流行に通じているので、専門家や頼れる知識源とみなされることがある。この信頼の認識によって、彼は経営層を含む多くの聴衆に影響を与えることができる。

達人を味方にや、著名人を招くに近いのかな?

ここもやはり、何をいうかじゃなくて誰がいうかっていう感じだと思う。

32. 体験談の共有

このパターンは体験共有のためのイベントを作り出す。多くの人は成功例に刺激を受けるので、そのようなイベントによって新しいアイデアの魅力が高まることであろう。だが間違った人を選んでしまうと、あなたの目的を損なう危険がある。たとえば、ダラダラと喋り続ける発表者のせいで、他の人が話せなくなることがある。人気があり、尊敬されている人に話してもらおう。もし不適切な人がどうしても発表したいというのなら、より感じのいい発表者の発表と組み合わせておけば、その影響を緩和することができる。

体験談の共有会って確かにやってないかも。

○○やろうぜ!よしやろう!ってなって、ルール化できても結局そのまま野放しになってしまってることがある。

こういう地道なのって大事なんだな。

次やるときはこれもやってみよう。

簡単な振り返りを共有するだけでもいいんだし。

33. みんなを巻き込む

あなたが多くのことをやりすぎることによって、失敗に向かってしまうことがあるのだ。新しいアイデアをあなた自身に関することと捉えられてしまうことがあるので、他者の考えがあなたの人格や歴史によって色付けされてしまうのである。どうすればイノベーションがもっともうまくいくか議論する人は、あなたの意見に従おうとするだろう。まるで「正しい道」を学ぶ学生のように。

なるほど。

自分は結構人見知りで、自分である程度まで頑張って、そのあと信用できる人に話を持っていく癖があるけど、ある程度っていうのがどのレベルかで、参加してくれる人たちの指針となってしまうっていうのは問題だと思った。

それが100%成功の道と誤認されてしまう危険性があるってことか。

気をつけないとだめだ。

34. ちょうど十分

新しいアイデアを紹介するためにプレゼンテーションを行う場合、より高度なコンセプトに関する追加情報を1〜2枚のスライドにまとめよう。日常会話の中で、周囲の人たちが新しいアイデアを快く扱えるような情報を提供し、まだまだ学ぶことがあると伝えよう。周囲の人がそれぞれ、新しいアイデアに興味をもって自ら調べたくなるような情報を与えよう。 管理部門の上層部を相手にプレゼンテーションをする際は、まず最初に結論を示すこと。総括的な展望を描いて見せ、質問されたら詳細について説明しよう。損失よりも収益を強調すること。誇張することなく、リスクを無視せず、新しいアイデアの導入によってよい結果が導かれることを主張するのだ。

経営層とそれ以外でプレゼン方法を切り分ける必要があるのか。

まぁ確かに、考え方が違う人達だから当然か。

35. 身近な支援者

間違ったスポンサーを巻き込んでしまうと、あなたは焦点と方向性を見失ってしまうかもしれない。新たなマネジメントを招き入れることは、同時に、あなたの考える方向性とは別の方向に押し出されてしまうリスクも伴う。あなたのアイデアを盗み、自分の実績にしてしまう独善的なマネージャーもいるかもしれない。マネージャーが熱心すぎると、新しいアイデアが強制されているような悪い印象を与えるかもしれない。あなたの真面目な思いを傷つけるのではなく、支援してくれる人望の厚いスポンサーを探そう。

マネージャーを味方にしようって話。

印象に残ったのは、上記の注意文。

明らかに危ない雰囲気の人っていうのは、わかるけど、あまり話したことない人の場合、一回ぶつけてみちゃうような気がする。

そして蓋開けると、上記のような結果になってしまうと。

そういう結果にならないよう、選別と言ったら聞こえが悪いけど、日々のコミュニケーションがとても大事だと思った。

36. 場所重要

仕事の現場ではない外部の施設を利用するには、必然的にコストがかさむ。それでも外部の施設を利用しようとするならば、きちんとやらなければならない。

1日かけてやるようなものは、職場でやらずに、別の場所で割り込みが入らないようにやろうっていうことのようだ。

よくあるプログラミング合宿とかは、まさにこのパターンに当てはまってるんだろう。

37. メンター

メンターとチームメンバーが一緒にトレーニングし、経験を共有するという効果がある。チームメンバーが新しいアイデアについて効果的にコミュニケーションが取れるようにするだけでなく、チームビルディングの練習にもなるのだ。

新卒の子について教えた経験って何回かあるけど、教ぼえてもらうという事に注力してて、自分の教えるスキルを伸ばすなんていうのは考えたこともなかった。

教える立場も一緒に成長しなければ。

せっかくそういった立場にさせてもらったのだから。

38. 謁見

チーム、個人あるいは管理者によって有意義なものとなるよう招待者を利用しよう。それにはプレゼンテーションする時間帯の前後、日中や夜間のあまりの時間や食事の時間を使うのだ。

著名人を招くパターンで外部の方を招待した際に合わせ技で使用できるパターンって感じだと思う。

この方の発言力を利用させてもらい、経営層の支持者を獲得するということのようだ。

まず最初の段階で結構ハードル高そうだけど、、、

39. 相談できる同志

コミュニティというものは、同じ目的をもった人が集い、一緒くたになって話し始めた時に動き出すものだ。このコミュニティは、落ち込んでいるときの後押しや、有用な議論や、戦略の情報源を提供してくれる。

しかし、気をつけないと、集いが泣き言をいうだけの劣化したものになってしまう。これでは、人をネガティブ思考に溺れさせるだけでなく、彼らに対して申し訳ない気持ちになってしまうだろう。誰かの不満が妥当なものであっても、人が引き起こした問題への解決策に焦点を当てよう。一度負担から開放される機会を得ると、人は前進するための大いなる知性を使えるようになるのだ。

結構バッドパターンに当てはまっちゃうことってありそう。 愚痴をいうだけの会みたいな。

もう一歩踏み込んで、それの解決策ってなんだろうね。っていうのを話し合うようにしないとな。

40. 成功の匂い

あなたの取組みがなんらかの目に見える結果を残した時、あなたと話したがる人がぞろぞろと現れるだろう。その機会を活かして教育に力を入れよう。

自分が考えているアイデアは社内全体に対しての話ではなく、あくまでエンジニア内での話だけども、それでも複数チームに分かれているような場合、片一方のチームに新シアイデアを導入して、上手く行っているような雰囲気があると、もう片方にも導入しやすくなるし、むしろもう片方が進んで導入を検討してくれると思う。

これが成功の匂いっていうやつだと思う。

結果を出さないとだけども。

41. 勢いの持続

変化への取組みをしているあいだは、自分自身を奮い立たせ続けなければならない。「静止している物体は、外部から力を加えられるまで静止状態のままである」というニュートンの第三法則は必ずしも真実ではない。新しいアイデアを使い続けなければならない。止めてしまってはいけない。一旦勢いを失ってしまうと、再び勢いを取り戻すことはとても難しい。

これはめっちゃわかる。

あれやってみようこれやってみようといろいろ提案して実際始まったけど、みんなで進めないといけないものなのに、集まりが悪かったり、そもそも仕事が忙しくて開催できなかったりというのが続いて、結局なくなってしまったイベントなども社内であったりした。

でもそれは、集まりが悪い人達が悪いわけではなく(一部悪いかもしれないが・・・)、その興奮をみんなに持たせ続けるために、自分が動かないと駄目だった。

また新たに始めるのは確かに大変だけど、形を変えて始めてみたいと思う。

42. トーク

私達の脳が記憶できる量には限りがあり、今日の情報は明日の情報ですぐに置き換えられてしまう。人には思い出させるものが必要なのだ。特定の話題に関連付けられた物体は人の記憶を刺激する。今は他のことに気持ちが移っていても、そのアイデアのことを思い起こさせる手がかりになるし、ずっと時間が立ってしまった後でも有効だ。

例としてあげられているのは、マグネットとかボタンとかだそうだ。

ステッカーとかもそうなのかな?

重要なのは暗黙的なリマインダーの役割になればいいということなので、そのトークンがなにであるかはこだわらないか。

43. 橋渡し役

最後までぐずぐずしているのろまたちはたいていの場合、同僚の殆どもしくは全員が賛同して初めて、イノベーションを受け入れるものだ。プレッシャーに負けてそうしただけだとしてもだ。だから、いずれ彼らが折れるのだとしたら、のろまたちにプレッシャーをかけようと骨を折るよりもただ待っているだけのほうが無駄がなくてよいだろう。

懐疑派との説得の橋渡し役を選ぼうという話で出た↑の文。

全員を気持ちよく説得するというのは考えなくていいということw

44. 懐疑派代表

懐疑派代表がくれる情報を活用しよう。

あなたが考えていなかったことに気づけたなら、感謝を伝える。あなたが深刻な間違いを起こす前に修正するチャンスかも知れない。しかし、懐疑派代表が提案する極端な案に乗ってはいけない。ある程度の反対なら問題ないが、あからさまに敵対している強硬な人は避けよう。

反対意見を持つ人を、反対意見をもたせたまま、こちら側に取り組むイメージかな?

すごく面白いアプローチだと思った。

45. 根回し

あなたが会話した人たちがこの先なにか見返りを求めてくる危険はある。また、ミーティング前の個別の対話は、裏取引のように捉えられることもありえる。あなたはできる限り公明正大でありたいと思っていることだろう。全くの自分勝手な理由でこのパターンを使うと、火傷するだろう。そのコミュニティにとって最良の道を考える時、このパターンはもっとも力を発揮する。

個人的な接触と違いがわからなかったんだけど、決議の前に実行するところが違うのか。

ただ、引用したところであるとおり、使い方は気をつけないと行けないパターンだと思う。

46. 恐れは無用

抵抗勢力が全くいない状況を想像すると、ぞっとする。あなた一人で常に100%の正しさを保証しなければならない。これはおそろしいことではないだろうか。完璧な人などいない。抵抗勢力にアイデアを評価してもらう必要がある。だから反対意見に対する最初のステップは、それに感謝することである。幸運なことに、このやり方はあらゆる状況で有効だ。したがって、抵抗勢力の存在を感じたときは、密かに悩むのではなく、まず表に出してみよう。

この文章を見てなんの反対意見もない状況がおそろしいと感じた。

反対意見に対して感謝することっていうのは、すごく難しいけど、自分一人がこのアイデアを考えいるわけではないという、安心できる状況を作ってくれたということに関して、確かに感謝すべきだ。

47. お試し期間

実際に目で見て、触れることによって確信してもらう方が、言葉や理論で理解してもらおうとするよりも効果的だ。アイデアが確立された手法の一部としての説得力をもつまでのしばらくの間は、「受け入れ不可」のアイデアを一時的に「受け入れ可能」にもっていくために、「試験目的」という便利なラベルを使おう。

これは確かによく使う手だ。

「とりあえず1ヶ月間ミニマムで運用してみませんか?」

みたいなことってすごく言いやすい。

本当にチームにマッチしたアイデアだったら一ヶ月間やれば、良さは伝わる。

最小構成でお試しでやるっていうのはすごくいい手だと思う。

終わりに

長かった。

この本を読むために1週間ブログ書けなかったです。。。

いろいろと参考になる物が多かったです。

実は今お仕事を頂いている会社で、自分がやりたいと言って、社内勉強会開催や社内記事を書くことなどを今のチームで導入したりしたのですが、他のメンバーから不満があがり、結局やらなくなってしまいました。

これは本人たちのやる気の問題というのもあるかもしれませんが、これを読んで、そもそも自分の導入方法・進め方に問題があった可能性があるなと思いました。

この本をもう一度読んで、再度導入できるようにしていきたいと思いました。

再導入がうまくいけば、またブログにまとめようかなと思います。

次も積本消化します。

終わり。

CakePHP3のfindではバッククォートが使われない対応

Cakephpネタ。

レガシーなシステムとかだと、MySQL予約語とかがカラム名に設定されてたりする(レガシー関係ないか・・・)

実際自分が携わっている案件でも、

CREATE TABLE `customer_profile_options` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `customer_id` int(10) unsigned NOT NULL COMMENT,
  `key` varchar(128) NOT NULL COMMENT '項目名',
  `value` text NOT NULL COMMENT '値',
  `created` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  CONSTRAINT `customer_profile_options_ibfk_1` FOREIGN KEY (`customer_id`) REFERENCES `customers` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

みたいなイメージの縦持ちテーブルがあって、keyはMySQL予約語として使われている。

QueryBuilderとかでSQL組み立ててinsertとかすると

INSERT INTO customer_enquete_options (id, enquete_master_id, key, value, created) VALUES (?, ?, ?, ?, ?);

みたいな感じで、SQLが組み立てられる。

CakePHP2系までは各カラムにバッククォートが適用されて上記のinsert文は問題なく発行できた。

ただ、CakePHP3では上記のようにデフォルトでバッククォートがつかないようなので、SQL syntaxエラーが発生していた。

うーんうーん。とCakeのDatabaseDriverあたりのクラスを見てみると Cake\Database\Driver.phpで以下のような文を発見。

<?php

..
        $this->_config = $config;
        if (!empty($config['quoteIdentifiers'])) {
            $this->enableAutoQuoting();
        }

それっぽい。

公式で確認するとたしかにあった。

quoteIdentifiers あなたがテーブルやカラム名予約語特殊文字を使用している場合は true に設定します。 この設定を有効にすると、SQL を生成する際に クエリービルダー によって引用符で囲まれたクエリーが生成されます。 これはクエリーを実行する前に横断的に処理を行う必要があるため、パフォーマンスを 低下させることに注意してください。

ということで、config/app.phpのDatasources項目にある quoteIdentifierstrue にすると、正常にバッククォートが適用されていた。

公式の文で注意されていたパフォーマンスを低下させるっていうのがどの程度のものなのかビクビクするけど、ビクビクするくらいならばテーブル設計やり直したほうが良さそう。。。

とにかく、設計より設定って感じだった。

人に期待しないという言葉の意味を個人的に考えてみた。

こんばんは。

今日あるツイートが自分のタイムラインに流れてきたので、気になってしまった。

内容は

人に期待しないということ。

なにがそこまで気になったか自分の中でもよくわからなかったので、ちょっと考えてみた。

そもそも期待という言葉の意味を辞書で調べると、こういうことのようだ。

dictionary.goo.ne.jp

あることが実現するだろうと望みをかけて待ち受けること。

当てにして心待ちにすること。

人に期待する = 人(他人)があることを実現するだろうと望みをかけて待ち受けること。

人に期待しないはその逆。

つまり他人が何かを実現することはないと思っている。もしくは、実現する・しないすら考えない。

ということだと思う。






僕がこのツイートを見たときはじめに思ったのは、そういう考え方もあるのかと思ったのと同時に

「それならば一人でやればいいのに」

ということだった。

期待していない人たちと仕事する意味ってあるの?誰も期待していないなら1人仕事すればいいのに。という感想だった。

まぁ実際はそういうわけにはいかず、やはりチームを組んで作業をしていくのだと思うけど、チームメンバーが期待されてないということを知ると、どうおもうんだろうかと感じた。

例えば僕とかは、期待されていないのかと思うと、なぜ期待されていないのかという原因を探って自分自身で改善できるように努力をすると思う。

ただ、それが自分に原因がなく、その人の思想的に人に期待しないということがわかると、どれだけ頑張っても期待されないのかと思ってしまい、モチベーションを下げてしまいそうだなと思った。

それは、僕の、モチベーションの芯の部分に

「あの人の期待に応えられるように頑張ろう」

というものがあるからだ。 なので、そもそも僕に期待をしていないとわかってしまうと、僕はモチベーションを保てないだろうなと思った。

これは、「人に期待しない」という意味を言葉通り受け取った場合の、僕の結末予想だ。

メンタル弱くてごめんなさい。




でも、人に期待しないという思想を持っている人も、そうは言ってるけども本当はそんなことはないんじゃないか思っている。

例えば人を採用するとき

「この人はこういう技術を持っているから、プロダクトのこの領域に力を貸してくれそうだ」

「この人のリーダーシップは、チームを円滑に効率よくまわしてくれそうだ」

など、採用したい人になにかしらの「期待」して採用しているはずだ。

「期待してないけど、採用しよう」

なんてことにはならないと思う。

例えばタスクをふるときも

「この人がこの機能を以前に作っているから、この機能追加タスクも効率よく作業を進めてくれそうだ」

「この人にはもっとこの技術をつけてもらいたいから、このタスクを任せてみよう」

など、何かしら期待しているはずだ。

「特に誰にも期待してないから、重いタスク順にランダムに振り分けよう」

とはならないと思う

つまり、人に期待しないという人も必ずどこかしらで、人に期待しているはずだと思う。

「人に期待しない」という強い言葉が目立っているだけで、本当に言いたいことはもっと別のことではないのかと思った。

掘りすすめると自分が何に気になったのかがわかった気がした。

自分はその、人に期待しないという強い言葉に嫌悪感を抱いたんだとおもう。

僕もあえて強い言葉を使うと、捉え方によっては、

人に期待しない = 人を信用しない

と変換できてしまうからだ。

信用していないチームと一緒に仕事はしたくないだろうし、メンバーとしても、信用してくれない人と一緒に仕事はしたくないとおもう。

こういった負の考えが、頭をよぎって、人に期待しないと言う言葉が気になってしまったんだとおもう。

本当はもっと別のことを言いたいんだろうなという、裏の意味を考えずに、その強い言葉だけが気になったのだろう。

ただ、自分は読解力も語彙力も皆無なので、本当は何を言いたいのだろうかと読み解き考えるのは無理だった。

なので、ここからはあくまで自分の予想で考えてみる。



人に期待しないということで得られる効果で、ぱっと思い浮かぶのだと、はじめから期待をしていないから、がっかりする事や、イライラする事が少ないという感じだと思う。

確かに、期待をしていないのだから、どんな結果になろうががっかりもイライラもないということなのだと思う。

でもそれってチームにとって健全なのだろうか。

僕的には(青い考えかもしれないが)チームがプロダクトの成功のために一丸になることってすごく大事なことだと思う。

チームメンバー全員が全員ともメンバー同士で期待を持ちあい、下回りそうな場合はお互いにフォローして、上回りそうな場合は称賛しあうみたいことが、重要なのではと思っている。

期待を持ち合うことでがっかりすることやイライラすることを少なくすることもできるのではないのかと思う。




.......なにがいいたいかよくわからなくなってきたのでそろそろやめておこう。。。

僕が言いたいのは人に期待しないという手法を批判しているわけではなく、そういう考え方もあるのかと理解しつつ、自分ならばこうだなという考え方をまとめてみただけということだ。

以上。おやすみなさい。

Vueやってみてる1

はじめに

こんばんは。

この記事からだいぶ間が空きましたけど、vueまたやり始めます。

なかなかモチベーションが上向きにならないんですが、頑張ってブログ書くというモチベーションだけは続いているので、気合ですよね気合。

codeprepにvueのブックがあったので、思い出しがてらやってみました。

やってみた

v-show(表示・非表示)

v-if でもおんなじことやれるけど、こういうのもあるみたい。

 <div id="app">
     <p v-show="is_show">表示だよ!</p>
 </div>
 
 <script type="text/javascript">
    var app = new Vue({
        el: "#app",
        data: {
            is_show: 1
        }
    });
</script>

f:id:kojirooooocks:20180814015848g:plain

v-if vs v-show

v-if = falseの場合は、描画されなくて、v-showの場合はcssのプロパティを変更するだけみたい。

使う場所がかなり違いそうだな。

算出プロパティ

以下のような、なんらか処理が必要を噛まして、その結果を表示したい場合に使える技みたい。

<div id="app">
    <p>{{ deliveryAnswer }}</p>

    <select name="delivery_date_list" v-model="delivery_date_list">
        <option value="">選択してください</option>
        <option value="1">2018-08-10</option>
        <option value="2">2018-08-11</option>
        <option value="3">2018-08-12</option>
        <option value="4">2018-08-13</option>
        <option value="5">2018-08-14</option>
        <option value="6">2018-08-15</option>
        <option value="7">2018-08-16</option>
    </select>
</div>

<script type="text/javascript">
    var app = new Vue({
        el: "#app",
        data: {
            delivery_date_list: "",
        },
        computed: {
            deliveryAnswer: function() {
                if (this.delivery_date_list === '') {
                    return ;
                }

                let result = "配送可能";
                if (parseInt(this.delivery_date_list) >= 4) {
                    result = "配送できません";
                }

                return result;
            }
        }
    });
</script>

f:id:kojirooooocks:20180814015951g:plain

普通に関数使って

deliveryAnswer() って感じで呼び出すのと何が違うのかな?と思ってたら、公式に書いてた。

算出プロパティ vs メソッド

算出プロパティはキャッシュされるようだ。

ちゃんとした違いがあった。

ウォッチャー

そのまんま、データの変更の監視を行ってくれる。

<script type="text/javascript">
    var app = new Vue({
        el: "#app",
        data: {
            deliveryAnswer: '',
            delivery_date_list: "",
        },
        watch: {
            delivery_date_list: function (new_value, old_value) {
                let result = "配送可能";
                if (parseInt(this.delivery_date_list) >= 4) {
                    result = "配送できません";
                }

                this.deliveryAnswer = result;
            }
        }
    });
</script>

f:id:kojirooooocks:20180814020030g:plain

使い方的には以下、

ウォッチャ

非同期やコストの高い処理を実行したいときに最も便利

だそう。

ウォッチャーは非同期通信を行う際のイベントを検知するもので、算出プロパティは、ロジックをhtml内に入り込ませないようにするための機能って覚えとく(キャッシュもあるしね)

フィルター

渡された値を別の値に変換する機能。

<div id="app">
    <p>{{ message | label }}</p>
    <input type="text" v-model="message">
</div>

<script type="text/javascript">
    var app = new Vue({
        el: "#app",
        data: {
            message: ""
        },
        filters: {
            label: function(value) {
                if (value === '') {
                    return value;
                }

                return "あなたの名前: " + value;
            }
        }
    });
</script>

f:id:kojirooooocks:20180814020119g:plain

なんか例で作ったやつがイケてない。。。

でも正直使い勝手が難しいところ。

良い使い方教えてください。

終わりに

終わり。

最初の方にやったやつ完全に忘れてるから、四苦八苦だっけど、やってるうちに思い出しました。

次も続いてvueやってみますー。

Sassやってみた

はじめに

こんばんはー。

低空飛行のモチベーションが続いてる僕です。

比較的頭使わず、かつ、あまり触ったことないやつを勉強中です。

今回はSassやってみました。

自分はフロントエンドの知識はすごく薄いし、CSSもあんま得意じゃないのでSassとかもあんまり興味なかったんですが、食わず嫌いというか触らないのに興味ないというのも失礼なので、一旦触ってみようと思ってやってみました。

まぁ自分みたいなSass初学者が説明しても大した説明できないんで、Sassとはなにかっていうのは割愛します。

今回勉強して面白いなーと思ったところをかいてきます。

覚えるために。

面白かった

アンパサンド

親のセレクタを参照できるってことみたい

example.scss

a {
  &:hover {
    cursor: pointer;
  }
}

example.css

a:hover {
  cursor: pointer; }

でもそもそもネストで書けるから、以下の書き方もできる。

example.scss

a {
  :hover {
    cursor: pointer;
  }
}

example.css

a :hover {
  cursor: pointer; }

使い分けの違いが今のところ思いつかないけど、もっと大掛かりなスタイルを記述する際に差が出てくるのかな?

if文

変数使えるってのは知ってたから多分できるんだろうと思ってたけど、やっぱりできてしかもめちゃ簡単だった。

example.scss

$width: 500;
$background_color: 'red';

@if $width >= 500 {
    $background_color: 'blue';
}

body {
  background-color: $background_color;
}

example.css

body {
  background-color: "blue"; }

mixin

メソッド的に定義できて、@include で簡単に使いまわせる。

example.scss

@mixin image-style($border-color: #ddd) {
  border: 1px solid $border-color;
  border-radius: 5px;
  padding: 5px;
}

.list-image {
  width: 150px;
  @include image-style();
}

.detail-image {
  width: 500px;
  @include image-style(#000);
}

example.css

.list-image {
  width: 150px;
  border: 1px solid #ddd;
  border-radius: 5px;
  padding: 5px; }

.detail-image {
  width: 500px;
  border: 1px solid #000;
  border-radius: 5px;
  padding: 5px; }

extend

スタイルの継承ってのが面白かった。

example.scss

.submit-text-style {
  font-weight: bold;
  font-size:   16px;
}

.user-register-button {
  @extend .submit-text-style;
  color: green;
}

.purchase-button {
  @extend .submit-text-style;
  color: red;
}

example.css

.submit-text-style, .user-register-button, .purchase-button {
  font-weight: bold;
  font-size: 16px; }

.user-register-button {
  color: green; }

.purchase-button {
  color: red; }

でもmixinでも同じことできるから、使い分けが結構難しそう。

終わりに

プログラムチックに触れるのはいいなーと思いました。

こんな感じで書けるならば食わず嫌いはやめてCSS勉強してみたいと思いました。

ただ、自分はデザインセンスがないんで、知り合いのデザイナさんに教わりながらもうちょいSassつまみ食いしてみようと思います。

勉強しはじめた。

こんばんは。

先週やる気云々話してて、今週何もしないのは流石にまずいので、仕事も適度に終わらして勉強しようと思います。

まだ全然全盛期のモチベーションに到達してないので、ウォーミングアップ的になにか簡単なものをやっていきたいなと思います。

それを続けて積み重ねていって、モチベーションを上げていこうかなと。

今目下の課題は持続力なのでね。

で、何を勉強しようかと思ってたんですが、以前やってたCODEPREPやProgate,Udemyなどのオンラインの学習をやろうかなと思います。

初心者向けが多いので、比較的自分的には必要ないものが多めですが、多言語の習得の入りにはちょうどいいし、今のモチベーションにもちょうどいいかなと。

このあたりを続けてモチベーションを高めたらまた、本買って勉強し始めようと思います。

頑張って持続させて今年のはじめのやる気を取り戻すぞ!!