00:06
はい、8月22日ですね。月曜です。15日は昨日もありました。ちょっと遅くなりましたね。
今日の東京はちょっと曇りだそうですね。ただ雨降らないで欲しいなと思います。
いや、朝は洗濯機を回してます。はい、おはようございます。めめめのkeeth、河原です。
ちょっと本日も朝活を始めていきたいと思います。
えーと、今日は前回、前座会に引き続き、えーと、なんだっけ。
テクニカルライティングフォーデベロッパーズですね。記事の、まあ、読んでいこうかなと思います。
で、昨日ってなんだっけ。プルリクエストの書き方みたいなところまで入ったような記憶がありますね。
で、えー、じゃあそこまで終わったのかな。
で、一周の話まで入って、レポーティングバグですね。の話まで入って、
で、続いてコミュニケーティングウィズクライアントかな。クライアントのコミュニケーションの話に入るところで、
確か中途半端からやっぱり切ろうとして、切った記憶がありますね。はい。
なので今日はその続きからです。で、おそらく今日で読み切ると思うんで、そのまま続きで別の記事を読もうと思っていて、
えーと、いろいろまだ探したんですけど、まあ海外の記事って、あの特にテクニカルな記事だとソースコードだらけになってくるので、
なかなか難しかったんですけど、面白そうな1つ見つけたので、読みたいと思います。
えーと、Five JavaScript Concepts to Make You an Excellent Frontend Developerですね。
まああの、書いてある通りですけどね。あの、ま、優れたフロントエンドのデベロッパーに、
あなたがなりたいのは、なめるために、えーと、5つのJavaScriptのコンセプトみたいなところですね。
をまとめた記事があるので、これは結構読み物系だったので、読んでいこうかなと思います。
では、えー、早速ですけど、今日の、えー、範囲ですね、コミュニケーティングウィズクライアントの方からちょっと入っていこうかなと思います。
ほい、えーと、だいちさんと、てらんさんと、えーと、えんどひずみさんですね。
はい、おはようございます。ご参加いただきありがとうございます。
今日もだらだらとタイトルにある記事を読んでいこうかなと思ってます。
ほい、じゃあ、えーと、前者の方ですね。
テクニカルライティングフォーデベロッパーズの方で読んでいきたいと思います。
えー、クライアント、コミュニケーティングウィズクライアントですね。
クライアントとのコミュニケーションですけど、
えー、あなたは1人でフリーランスとして働いているかもしれませんし、
あるいは、小規模なチームのリード開発者かもしれません。
どちらの場合でも、あなたはプロジェクトでクライアントとやり取りをする責任を負っているとします。
さて、プログラマーはコミュニケーション下手というイメージがありますと。
技術的な専門用語を多用し、何ができて何ができないかを相手に伝え、
自分のやり方に疑問を投げかけられると身構えることもありますと。
はい、そうですね。これよくありますね。
疑問を投げかけられると、まあ否定されているじゃないですけど、
自分の考えのことについてストップをかけられるような勝手な印象を受けるというのは結構現場では多くありますけど、
まあそんなことはなくて、単純にクライアントは質問しているだけだったりしますけどね。
はい、まあそういうふうに感じることもあるでしょうと。
で、えーと、深掘っていきます。
Ask the right questionですね。適切な質問をしましょうと。
03:03
まず、あなたとクライアントが同じ考えを持っていることを確認することから始めましょう。
いわゆる認識ですね。共通認識を持っていますか?というところから始めましょうと。
で、ターゲット層は?とか、サイトの目標は何か?とか、
もしくはその最も近い競合他者というのはどこなんですか?とか、
その競合他者は何をやっていますか?とか、
まあそんなへんですね。一回確認しましょう。
で、特にクライアントの意見や決定に同意できない場合ですね、
質問をすることは前向きな姿勢を示す良い方法になります。
質問することで、あなたが自分の立場を守って相手を攻撃するのではなく、
相手が自分の主張を裏付けるように仕向けることができるんですと。
たとえ性能利コストが追加コストがかかってもそれでいいんですか?とか、
という問いがありますが、
その部品を移動させることで我々の目的をより良く達成することができるでしょうか?とか、
いろんなクエスチョンがどんどん続きますね。
はい。
えー、また打ち上げ後のメンテナンスは誰が行うのですか?
打ち上げ後というかリリース後のメンテナンスは誰が行うのですか?とか、
えー、はい。
例えばその2色のコントラストがWCAGの基準をクリアしているかどうか、
まっすぐに分かりますか?とか、
いろんな問いがありますけども、
こういう質問というのは敵よりも、実は好奇心を促進し、
より無邪気な方になりますよという風に言っているので、
質問をどんどんしていってくださいという感じですね。
まあでもタイトルにありますけども、
これはライトクエスチョンなので、
なるべく適切な質問をしましょうということですね。
別にお客さんとかクライアントは別に攻撃したいわけではないですし、
こちらとしても自分の身を守りたいための質問をするというわけでもなかったりします。
まあそういう時の質問もありますけど、
基本的にはライトな質問をすることで、
好奇心を促進に支えることができるよという風にこの方はおっしゃってますね。
これは僕も結構経験としてはあるかもしれないです。
割と質問をバンバン投げてくれるということは、
僕らするとプロジェクトにかなり前向きというか、
熱意を持って取り組んでくれているなという風な印象を与えることもできるので、
割と質問をガンガン投げるのは全然いいと思いますし、
メンバーの方から質問を投げるというのがかなり僕はいいと思います。
もちろんリーダーは質問をするんですけど、
メンバーの人からの質問、本当にボトムアップ的な印象を与えることができるので、
割といいなと思います。
続いて、セル・ユア・セルフですね。
自分自身を売り込むというタイトルですね。
見込み客に売り込みをする場合、
自分を雇うように説得する必要があります。
なぜそのクライアントはあなたを選ぶべきなんでしょうか。
次のことを明示することが結構重要ですよ。
すいませんね、また今朝もうちの家では救急車と消防車が走り倒していますね。
雑音が入って申し訳ないです。
通り過ぎてか、まあいいか、喋れますね。
聞こえにくかったら申し訳ないです。
なぜあなたを選ぶべきかというところを明示する必要があります。
例えば、あなたが誰でありますか。
あなたの仕事内容はどうですか。
なぜこの仕事に適しているのですか。
06:01
これまでに手がけた仕事の関連性のあるリンクはありますか。
この辺を示していきましょう。
これはどちらかというと、自分自身を売り込むというので、
企業間というよりもフリーランスの方の面が強いかなと思いますね。
自分自身を売り込むというところです。
仕事を獲得して契約書を作成する必要がある場合、
法律要項の束ほど威圧的なコンテンツはないということを忘れないでください。
デザインプロジェクト用に書かれたものですが、
コントラクトキラーというのは、
より親しみやすい文章を書くための良いきっかけになるでしょう。
コントラクトキラーという、今回別の記事のリンクも貼ってありますので、
今日もまたこの読んだ記事をツイートするので、
この記事内のリンクからもらってください。
これはこれで気になりますね。
コントラクトキラーというタイトルが、
そもそもキラーワード感がすごいので。
戻ります。
細部へのこだわりというのが、
同じプロジェクトを勝ち取ろうとする他のディベロッパーとの差になるかもしれません。
私の経験では、クライアントというのは、
技術的に最も有能で経験豊富な開発者よりも、
やっぱり一緒に仕事をして楽しいと思える開発者を簡単に雇うものです。
何だかんだ人なんだよなというところがあると思います。
もちろん、
人によっては、
いや全然経験豊富で能力が高いという人を採用するということがあると思いますし、
一般的にはそっちの方が高いと思いますけど、
とはいえやっぱり、
同じ技術レベルの中で比較をするとなったときに、
仕事をして楽しいと思えるという人を選ぶ。
それは当然だと思うので、
そういうところも加味して、
自分の売り方というのも考えていくのもいいかもしれないですね。
これも一つのセルフブランディングな印象はありますけど、
セルフブランディングというと認知度的なイメージはありますけど、
そういう好印象を与えるという一つのブランディングを作るのもいいと思います。
今のがコミュニケーションウィズクライアントでした。
続いて、ライティングマイクロコピーですね。
入っていきたいと思います。
マイクロコピーの書き方ですね。
じゃあいきましょう。
マイクロコピーとはユーザーフレンドリーなUIメッセージですね。
エラーメッセージなどを書く技術になります。
開発者の皆さんは発売まで後回しになってしまい、
エラーメッセージを書かなければならなかったことがあるのでしょうか。
ないでしょうか。
ああ、そうですね。
結局エラー系のメッセージを後回しに後回しにして、
直前にガッとやるみたいなこともたまにやりますけど、
最近はやらないですかね。
むしろテストをちゃんと書いたりする習慣があるチームだと、
異常系を書くのが当たり前ですね。
正常系なんて本当に一話にしか書かないことが多かったりするので、
エラーメッセージは最初に決めておくというのは結構やると思うんですけど、
プロジェクトによっては後回しになりがちだというのもよくありますよね。
はい。戻ります。
そのためか、例えばこんなエラーを見かけることもありますと。
09:00
エラー Unexpected Input Code 693とか書いてありますけど、
こんなエラーメッセージもたまに見受けられますと。
エラーというのはもちろんユーザーにとっては最も避けたいものです。
でも実際に起きてしまうこともあるし、
起きてしまうことはどうしようもありませんしということですね。
ここでマイクロコピーのスキルを向上させるためのヒントをいくつか紹介しますと。
さっきのエラーメッセージは正直言って意味がわからないというか、
予期しない入力がありましたというふうに書いているけど、
全然ユーザーフレンドリーではないという感じですね。
はい。
ではそのマイクロコピー、特にエラーメッセージ系の意味かな。
を書いていきたいと思います。
一つ目ですね。アボイドテクニカルジャーゴンです。
専門用語を避けましょうということですね。
プログラマーの100%知っている一方で、
ほとんどの人はサーバーが何であるかを知りません。
それはそうだよね。
そのためエラーメッセージにAPIやタイムアウトの実行などの
一般的ではない用語というのが書かれていることは珍しくもありません。
僕らからすると当たり前だけど、
一般ユーザーからするとなんじゃそれっていうのは確かにもちろんあります。
技術系のクライアントやユーザーを相手にしているのでなければ、
ユーザーの多くはコンピュータサイエンスのコースを受講しておらず、
インターネットの仕組みやあるものがなぜ動作していないのかを
知らない可能性がもちろん高いです。
だからエラーになるのです。
僕らがエラーと思っていないものをユーザーからすると
知らない挙動なのでエラーですよと言ってくる時もありますね。
ですから良いエラーメッセージはなぜうまくいかなかったのかを
説明すべきではありません。
なぜならそのような説明には怖い専門用語が必要になるからかもしれないです。
だからなるべくそういうエラーメッセージには専門用語を
使わないようにすることが大切ですと言っていますね。
続きまして、
Never blame the userですね。
ユーザーのせいにしないと。
これはちょっと強い言葉というか反省ですね。
僕もなんだかんだ案件を燃えたりすると
これどう考えても俺らじゃないだろって
言いたくなる時も正直あるので
これはしっかり読んでいきたいと思います。
ユーザーのせいにしない。
こんなことを想像してみてください。
あなたのプラットフォームにログインしようとしています。
ブラウザを立ち上げウェブサイトにアクセスし
自分の情報を入力します。
そうするとこう言われましたと。
あなたの電子メールとパスワードは確かにありません。
Your email slash password is incorrect.
isなのかこれは。まあいいや。
このメッセージが敵対的であると考えるのはちょっと大げさですけども
意識のうちに私をバカにしているんですと。
マイクロコピーではユーザーを非難することは
決して良いことではないと言っています。
誰だ。
マリー・チャインプっていう方。
ログインから引用したこの例のように
あまり試断されないメッセージに変えてみてくださいと。
そのメッセージの例がこんな感じです。
申し訳ありません。
そのメールとパスワードの組み合わせは正しくありません。
アカウントの復帰をお願いします。
みたいなメッセージになっていますね。
こんなメッセージだとどうでしょうかというところでした。
確かによく考えたら
12:00
your email or password is incorrectっていうのは
バカにしてるつもりはないんでしょうけど
そう捉えられる可能性は全然ありますよね。
要はお前間違ってるぞっていうことを言っていると。
言ってることは分かるし
何が間違ってるかっていうのも適切に表現されてるんですけど
言葉が強すぎますよね。短いので。
なのでそういう配慮をしたメッセージをしていくのもいいと思います。
なるほど。
これはなかなか
僕らは多分ITに慣れしすぎて
ウェブのアプリを使ったり開発してるから
当たり前になりすぎてるけど
一般の人たちはそうではないっていうのは
やっぱりちゃんと認識しなきゃいけないってことですね。
このデータは今何が来てるか分からないですけど
僕が数年前に聞いた話で
とあるデザイナーさんがユーザーインタビューしたときに
ウェブサイトの僕らだと
左上にだいたいロゴが置いてあるじゃないですか。
ロゴが置いてあるときにそこをクリックできることを
僕らは知ってるじゃないですか。
なおかつクリックすると何が起きるかっていうのを
だいたいイメージできるじゃないですか。
いわゆるホーム画面スラッシュに戻るってことですね。
っていうのがだいたい僕らの中では想像できるし
だいたいクリックしたらそうなるんですけど
一般ユーザーはあそこがクリックできるっていうのを
まだ知らない人が半数らしいです。
日本だけですけど
のしのが取ったデータの中では日本だけだったんですけど
知らない人が多いらしくて
クリックできたとしても
何が起きるのかを想像できないので
ちょっとクリックしたくないですみたいに
言ってる人もいるんですよね。
人によってはマウスをホバーしたときに
画面の左下にURLが出ることも
実は認識しない人もいたりするので
結構僕らの思っていることって
当たり前って他の人に当たり前じゃないことって
割とケースとしてあり得るんですよね。
なのでこのNever Blame the Userっていうのは
結構大事だし
おメッセージも結構気を付けたほうがいいな
っていうふうに僕は思いました。
という余談でした。
はい、戻ります。
続いていきましょう。
Don't Overwhelm the Userですね。
ユーザーを圧倒しないですね。
これはちょっと圧迫感のあるメッセージだと思いますけど
いきましょう。
マイクロコピーにユーモアを取り入れるのは
良いアイデアです。
ユーモアは気分は軽くし
最悪のエラーによって起こされる
ネガティブな感情を抑制する
簡単な方法にもなります。
しかし完璧に使いこなせなければ
ユーザーを見下し侮辱しているように
見えてしまう可能性もあるので
結構大きなリスクにもなりますよ。
また今回も一つ例が載っていますので
これもまたちょっと
例そのものは
記事のリンクをおいてください。
一言だけそのメッセージだけ引用されてますね。
その引用メッセージですけど
無理にユーモアを作ろうとすると
全くないことよりも悪くなることがあります。
もし自信がなければ真顔で言いましょう
っていうのを強調していますという感じでした。
本当に使えるっていうときに使いましょうですね。
結構難しいというか
リスクがあるので
慣れないうちはやらなくていい気はしますけど
ちょっとユーモアを挟めるのであれば
挟んでもいいと思います。
ただ作っているシステムとか
アプリケーションにもよりますけどねこれは。
じゃあ続いていきましょう。
今のが
Lighting Micro Pでした。
15:02
続いてLighting Accessible Markupですね。
マークアップなので
HTML的なお話が続くんだろうなというところですね。
実際そうなんですけど。
じゃあいきまーす。
アクセシブルなマークアップの書き方です。
アクセシビリティとテクニカルライティングの関係については
記事全体を費やして説明することも一応可能にはなりますが
今回はちょっと割愛します。
Microsoftや
MailChimp
などのコンテンツスタイルガイドには
アクセシビリティがよく含まれています。
先ほど言ったMicrosoftと
MailChimpっていうのかな。
読み方わかんないですけど。
これは2つのサイトの
アクセシビリティのドキュメントのリンクも
また貼ってあるので見てみてください。
アクセシビリティは海外では当たり前に求められるので
日本がまだまだ認識されていないだけであって
しっかりそれをガイドラインとして書いて公開しているってのは
結構素晴らしいし
逆に読んでおくといいかもしれないですね。
今後対応しなきゃいけなくなった時に
この辺を見るとなるほどねってなると思うので。
続きますね。
あなたは開発者であり
おそらくアクセシビリティについて
すでに多くのことをご存知でしょう。
すみません。あんまり把握しないです。
またアクセシビリティをワークフローの中学に据えている
勤勉な開発者の一人であるかもしれません。
メンバーは一応いますけどね、そういう人は。
それでもアクセシビリティへの配慮が後回しにされがちなのは
驚くべきことです。
全ての能力を受け入れるアクセシブルなオンライン体験を
実現することがいかに重要であるかは
もう誰もが知っているはずですと。
ここはそうですよね。
知っているんだけどなぜかアクセシビリティって
日本だけじゃなくて海外でも後回しにされがちだ
というところですね。
ですから他人のコピーライティングを自分のコードに実装したり
他の開発者のために文章を書いたり
あるいは自分でUIコピーを書いたりしている場合は
基本的なアクセシビリティのベストプラクティスを
意識してください。
例えば次のようなことですと。
可能な限りセマンティックタグを使用すると。
例えばNavタグとかHeaderタグとかArticleタグなど
セマンティックなタグを使ってくださいと。
セマンティックなタグについてはまたリンクを貼っていますので
そこを見て参照してくださいと。
他にも論理的な見出し構造に従いましょうと。
例えばH1が複数あるとかも意味分からないので
そういうことはやめましょうとか。
そんな感じですね。
あとは画像にオールドテキストを追加しましょう
ということですね。
オールドテキストについては実はアクセシビリティの観点では
必ず書かなきゃいけないというわけではなかったりします。
例えばタイトルがあって文言があって
途中に画像があるみたいな表現ってよくあると思うんですけど
サブタイトル的なところに十分説明があって
そのサブタイトルをほとんどオールドの画像に
そのまま載せるんだとしたら
ぶっちゃけると意味がないんですよね。
すでに情報としては与えられていたりするので
必ずしもオールドを書くのがベストだという意味ではない
というのが最近のアクセシビリティの見解というか
業界的に全体としてのそういう認識らしいですね。
本当に機械学そのコードを読むときに
18:05
必要なのかどうかっていうのは機械には判断できないので
その受け取り手の人が本当に必要かっていうのを
ちゃんと観点に入れて
オールド属性を書かないかっていうのを
決めた方がいいよってことでした。
すでに情報を与えられているものを
もう一回オールド属性に入れて
重複して読ませるのは
学級って意味ないよねって話なので
もしくはオールド属性があまりにも抽象的で
シンプルじゃなくて単純な文言ですね
だったりすると結局あやふやな情報を与えたりとか
逆に誤解を招くような情報になってしまうので
そういう場合も逆に画像のオールド属性を書かない方が
いいみたいなような見解だったりしますね
というのが最近のアクセシビリティらしいです。
なのでオールド属性を追加することは構わないんですけど
必ず書かなきゃいけないというわけではないよ
っていうのは結構認識しといた方がいいかもしれないですね
はい、戻ります。あとは何だったっけ
インラインのセマンティックに注意しましょうとか
インラインのセマンティックですね
それについてのまた別記事を張ってますので見てみてください
今回のセクションめちゃめちゃリンクだらけですね
で、アンディベルって方がいらっしゃるんですけど
アンディベルはコンテンツをよりアクセシブルにするために
できる比較的小さなことをいくつか提案していて
それらをチェックする価値もありますと
ジョン…誰だ、ジョン読めないな
ジョンレファーさんかな
セマンティックなHTML要素を使用する際に
可能な編集上のトリックをいくつか紹介しますと
この辺は他の人のいろんな記事があって
その辺が参考になるのでこれを見てくださいってことでした
ライティングアクセシブルマークアップでした
ここは今回はこの方はあまり言及しないよってことでした
本当に記事のリンクがたくさん散りばめられてるので
今回の記事の文章の中からリンクをたどってください
最後はコンクルージョンですね
やっと結論にきましたね
最後終わりにですけども
以上テクニカルライティングだと開発がどのように結びついているかを示す
6つの方法点を紹介しました
例やアドバイスはロケットサイエンスではないかもしれないですけど
他の開発者の共同作業だったり自分の仕事をメンテナンスだったり
ピンチの時に自分のコピーを書かなきゃならない
プロジェクトの企画書の下書きなど色んな場面でお役に立てたら幸いです
結論から言うと文章力を磨き
文章にちょっとした工夫をすることで実はより良い開発者になれるのです
当たり前っちゃ当たり前なんだけど
それができないので今回ここで6つに切り分けて
いろいろ書いてみましたってことでした
以上でテクニカルライティングforデベロッパーズですね
という記事は終わりたいと思います
ではこの6個の方法というのを改めて読んでいきましょうかね
1,2,3,4,5,6この辺だと思うんだけど
What is good grammarと
Writing code commentsと
Writing pull requestsと
Reporting bugsと
21:02
Communicating with clientsと
Writing accessible markupですね
というところに注目をしてみてください
以上長くなりましたけど
残り時間ちょっとありますので
もう一つの記事ですね
今日中にこれも読み終わらない気がするので明日に続くと思うんですけど
5 JavaScript concepts to make you an excellent frontend developer
の記事を読んでいきたいと思います
5つのJavaScriptのコンセプトですね
あなたを素晴らしいフロンテンドデベロッパーにするための
5つのJavaScriptのコンセプトという記事ですね
を読んでいこうかなと思います
では行きましょう
ちょっと翻訳に時間がかかってますね
タイトルを変更したことを
あーだこうだと見つける友人は多いでしょうかと
確かにタイトルは変更されていますが
共有されたコンテンツは前のコンテンツの後に引き続き共有されています
4回目のシェアの後友人が
自信でタイトルを変えて新セミを出すことはできないかと送ってきました
このような相手とのやりとりを経て
試しにやってみようと思うようになりました
さて新しいタイトルもみんな気に入っているといいんですが
新しくシェアされたコンテンツがより多くの友人と議論できるようになるのがいいなと思っています
なのでこれか
この記事のメインタイトルの下にパート5って書いてあって
これ何の意味かなと思ったんですけど
一応読むとパート5ですね
これらの概念を知ることで優れたフロントエンドの開発者になることができます
っていうサブタイトルですけど
このパート5っていうのはこの4回の
試行錯誤で5回目のリリースってことですね
はいなるほどでした
では早速一個一個いっていきましょうか
長いな
早速コンセプト一つ目ですね
一つ目ですけどまず継承についてです
まず継承について語っていきましょう
いくつかの継承の方法について
その特徴も含めて以下に説明します
いくつかに分けてっていうのが
合計6個に分かれてその継承についての方法
特徴を語っています
一つ目ですねプロトタイプチェーン継承ですね
オブジェクトをオーバーライドするってことです
これには2つのデメリットがあるよっておっしゃってますね
一つ目はオブジェクトのインスタンスが継承された
すべてのプロパティとメソッドを共有しますと
2つ目はパラメーターを渡すことができないよってことなので
この辺がデメリットだっていう風に言ってます
なるほどですね僕あんまこれデメリットだと思わないなっていうのと
そもそも最近のフロントエンド開発で
プロトタイプを意識することって
ほとんど皆さんないと思いますね
フレームワークはその辺やっぱりアップしてくださっているし
あとはやっぱりクラス構文の
シンタックスシュガーですけどクラス構文がJavaScriptにあるので
24:00
あんまりプロトタイプっていう風に明示的に書くことって
ないような気はしますねっていうのがあるので
一応そうですねプロトタイプチェーンっていうのも継承がありますよってことでした
まあまあまあまあですただあんま使わなくてもいい気はしますね
最近のフレームワークの機能が十分すぎるので
一応昔の歴史的な背景でいくと
まあ確かにこれは意識した方がいいなと思いましたけど
2つ目ですねコンストラクター継承です
サブクラスのコンストラクターの内部でスーパータイプのコンストラクターを呼び出すと
アプライメソッドとコールメソッドを使うみたいなのがありますね
このアプライメソッドとコールメソッドも最近は使わなくなりましたし
ほとんど見なくなりましたねっていうのはありますね
もちろんテクニカルなこととかちょっと複雑なことをするときに
JSのアプライとコールとか使ったりしなくはないですけど
ほぼ使わないかなってことですね
ただ知っとって損はないので
未だにフロントエンドの駆け出しの方とかには
ちょっと利用としては難しいし理解するのは難しいんですけど
少なくとも引き出しとして教えることはありますね
これらですけどこれらのデメリットっていうのは
また2つあって関数の再利用性が高くないと
全てのインスタンスが再インスタンス化されたコンストラクターであり
共有属性というのが存在しないと
2つ目にインスタンス上の属性しか継承できないので
プロトタイプ上のメソッドは不可視であると
この2つ目の方が結構大きいですね
1つ目はまあまあよくある話なんですけど
そうですねインスタンス上の属性しか継承できなくて
プロトタイプ上のメソッドはやっぱり不可視だっていうところですね
なのでここは結構たどっていかなきゃいけなかったりする
一応エディターで割と追ってはくれるんですけど
奥の奥まで追ってくれないしないのでこの辺は結構大変ですよね
また継承してるんですけど継承先も多分オブジェクトで
オブジェクトってJavaScriptの全てのオブジェクトって
紛らわしいんですけどオブジェクトオブジェクトを全部継承してるんですよね
言ってしまうとなので大元のオブジェクトのメソッドなのか
それとも途中継承されたやつのメソッドなのかって
ちょっと分からなかったりするので
この辺も結構難しかったりはしますよね
なのであんまコンストラクター継承は僕もよろしくないな気はしますね
続いて複合継承ですね
プロトタイプチェーンプラスコンストラクターですね
親のコールだったりしますけどとか
ニューペアレントで上記の決定は一応回避されますけど
っていう風に書いてるんですね
これもメリットデメリットが両方書かれてますね
パラメーター渡すことができて
親クラスの参照属性と共有されることがない
というのが一応メリットだと言ってます
複合継承ですね
デメリットは親クラスの機能を継承する場合
親クラスのコンストラクターが呼び出されるため
子クラスのプロトタイプに不要な親クラスに属性が付いて
メモリの無駄が生じるっていうのは確かにありますので
それはそうですねっていう
デメリットは確かにデカいですね
メモリの無駄が生じるのは本当に大きいので
だから複合継承もあんまり僕もしたくはないですね
そもそも継承自体しないっていうのは置いといてる感じですけど
続いて4つ目ですね
27:01
4つ目はプロトタイプ継承
もう一回来たの
1つ目は何だったの
プロトタイプチェーンの継承とプロトタイプの継承か
明示的に分けたんですね
プロトタイプ継承ですけど
オブジェクト関数ですね
っていうのは渡されたオブジェクトのシャローコピーを行いますと
はいはいはいはい
シャローコピーっていうのがまた悩ましいですよね
この辺参照と
何だっけ
何本も出てこない
物理的な参照などかそれともポインタ的な参照などがあるじゃないですか
っていうのがあったりするので
やっぱりシャローコピーをするとこの辺が落とし穴ですよね
シャローコピーを行うってのは結構バグの温床になったりもするので
あんましない方がいいなって気はします
続いて
パラセティックインヘリタンス
こういう名前があったんですね
日本語にすると規制的継承っていうらしいですけど
初めて聞きましたね
コンストラクターで属性を継承して
プロタイプ連鎖のハイブリッド形式で
メソッドを継承すると
はーなるほどね
ただまあ継承するときに
ハイブリッドとか
どっちどっちみたいな話があるので
するならガツンと継承した方が
人としては分かりやすかったりするし
やっぱ認知レベルが低いので
そっちの方がいいと思うんですけど
はいでラスト
規制的合成という風に
言ってますね
そんなもんあったんですね
コンストラクター一度だけ呼び出せるものだと
規制的継承と合成的継承の長所を
併せ持ちます
型に基づく継承を実現する最も有効な方法であります
親クラスのプロトタイプを
子クラスに割り当てて
コンストラクターを子クラスとすることで
無駄な親属性の問題解決し
親指出しプラスオブジェクトと
クリエイトとなります
あーはいはい
オブジェクトとクリエイトを内部的に呼び出すと
ほぼ同じになると
まぁじゃあそっち使えば
良くないかもありますが
以上とりあえず継承についての
6項ですね特徴とか
っていうところを書いてましたけど
基本的にデメリットを書くことが多かった
印象なのと
僕はなんとなくこれはあんまもう継承しなくて
良くないかっていうような
結論になりましたねこれは皆さんがどう感じるか
ちょっと分からないですけど
以上一つ目のコンセプトまず継承について
ってところでした
このままガッと読んでいきたいんですけど
もちろん時間がちょっと
超えてしまったので今日の朝活は
一旦こちらで終了して
また次回ですね明日も続きですね
残り4つのコンセプトを読んでいこうかなと思います
先にタイトルだけ
頭出しして終わろうかなと思います
二つ目のタイトル
コンセプトですね
let's have a brief understanding
of this keyword
thisのキーワードっていうところを
理解することが重要ですよ
ここは本当その通りだと思います
JavaScriptの
難しさの
トップに上がると言ってもいいと思います
thisですねいわゆるコンテキスト
っていうところが難しいんだと思います
三つ目です三つ目は
how much do you know about type judgment
型の話ですね
最近はタイプスクリプトがあるのでっていう話が
30:00
多分出てくるんじゃないかと思いますが
出てこないっぽいですね
なので一応
JavaScriptの型についての話です
四つ目ですけど
let's understand the conversion of the following types together
です
以下のような型の
一緒に使うときの
お話をしてますね
その辺で理解しましょうと
基本的にはコンバートする系ですね
convert to boolean convert to numbers
convert to string
っていうようなケースを理解しておくことがいいよと
そうですねJavaScriptは
何とかありますよねnot a numberみたいな形も
あったりするし
0って普通に0と
数字として書くんじゃなくて0って
フォルシーな値みたいな判断されたりとか
その辺の話が出てくるっぽいですね
ラスト五つ目のコンセプトは
comparison operator
how much do we know
オペレーター周りのところの話
皆さんどれくらい知ってますかっていうので締められる感じでした
はい
明日はその辺を深掘っていきたいと思いますので
また興味ある方はゆるっと参加していただければと思います
一応明日ももう一回
このコンセプト一応さらっと
おさらいすると思います
明日の俺が忘れてなければすると思います
というところで長くなりましたけど
朝活は以上にしたいかなと思います
本日もたくさんの方ご参加いただきありがとうございました
また今日から月曜日ですね
一週間始まりますけど
結構休み明けの方も
ツイッタータイムライン見てたら多そうなので
頭なんとか起こしていただいて
今日からまた一週間頑張っていただければなと思います
では終了します
お疲れ様です
