コンピュータやソフトウェアのあれこれ@道民(&元道民)
Planet
Head First JavaScript読書会 03に参加しました
3月 13th
3月12日(月)に開催された、Head First JavaScript読書会 03に参加しました。
本日は第4章「意思決定」。
if, switch
今回のメインはif、switchといった条件分岐。
条件分岐だけで1章使うのは贅沢…というか、薄く多くといった感じになりますね。
同じ事が繰り返されているので頭に入りやすいです。
javascriptの場合、やっぱりbreakをつけるのが大変&ミスしやすいので、ifを使う事が多いなあ。
「セミコロンはブログラム”文”の終わりにつける」
という考え方はなかったので新しい発見でした。
あと、本に書いていた「ifを繰り返すと効率が悪いからswitchを使う」というのはどの部分の「効率」なのか疑問が残りました。
【ifによる分岐】
var str = "E"
if( str == "A") {
alert("えー");
else if( str == "B" ){
alert("びー");
else if( str == "C" ){
alert("しー");
else if( str == "D" ){
alert("でぃー");
else if( str == "E" ){
alert("いー");
}
【同じ事をswitch文で書く】
var str = "E"
switch( str ) {
case "A":
alert("えー");
break;
case "B":
alert("びー");
break;
case "C":
alert("しー");
break;
case "D":
alert("でぃー");
break;
case "E":
alert("いー");
break;
}
これって、「評価回数」は同じだと思うのだけど、違うのだろうか。
評価回数が同じで、それぞれの評価コストが違う(caseでの評価の方がコストがかからない)、というのであれば納得できるのだけど「(ifの場合)5つのテスト条件が全て評価されるから効率が悪い」と書かれていた所に疑問が残りました。
<< 4/25 追記 >>
後日、この記事を教えてもらいました。納得。
ブラウザによってはswitch文がかなり最適化されているのですね。
現在はブラウザ(のjavascriptエンジン)がかなり高性能になっていてここまでの差はないという話もでました。
演算子、コメント、スコープ
途中で出てきた大事な事としては「各種演算子」「コメントの書き方」「スコープ(グローバル変数/ローカル変数)」の3つ。
コメントについて、コメントは「コードの動きを説明するために」書く必要があると書いてあったけど、どちらかというと「どうしてそう書いたか」を残した方がよいよね、という話をしました。(達人プログラマでもでできた話)
スコープについては「グローバル変数は本当に必要なとき以外は使わない」という方針が大事だなと思いました。
変数のスコープが大きいとどこで何をやっているかわからない不安があるから、スコープは可能な限り小さくしていきたいですね。大風呂敷を広げないというか、責任を持てるコードにするために。
今回の発見
「ゲームブック」という言葉を初めて聞きました。
「ゲームブックの14は死亡フラグ」というのも初めて聞きました。
あと、後輩の子がMacBookProを購入していました。(すごく)羨ましかったです。
実践アジャイルテスト読書会 02に参加しました
3月 6th
3月6日(火)に開催された、実践アジャイルテスト読書会 02に参加しました。
お仕事で少し遅れての参加。(しばらくは少し遅れての参加になりそう)
本を購入し、さらっと読んできてきたので内容にはついていける事ができました。
あー、でもアイスブレイクに参加できていなかったのかー。残念。
2章「アジャイルテスターのための10の原則」
本日は、アジャイルテスターになるための原則、心構えについて。
これが全てできたら、どこででも通用するようなスーパーマンだろうな・・・という意見に納得しました。
しかし、この原則はアジャイル原則を元に考えられており、普段忘れがちな気持ちや心構えが言葉として書かれている所がとても良いなと思いました。
仕事の中に喜びを見出す
章の最後に書かれていたこの言葉は、うーん。響きましたね。
いつもそう思えているか、見出そうとしているか、喜びを感じているか。
その他、心に残った言葉の羅列
- テスターは全体像を持ち続けている
- 安全なフューチャを提供できる十分な期間
- アジャイルなチームになるために必要なもの「勇気」
- 失敗から学ぶ、他者の失敗は許す
- 最もシンプルな事をしなさい
- チーム全員が意識を高く持つ
- 変化に対応し、変更を受け入れる
※ 太字は特に良いなと思ったもの
「人間力」
この章を読んで、一番強く感じた事は、10の原則を達成していくためには、スキルはもちろん、何より「人間力」が必要である、ということでした。
- 積極的にコミュニケーションを取る
- 自らが会話に参加する事で潤滑油となる
- 周りとの調整をはかる橋渡し的存在となる
- 他者の失敗は許す、チーム全体の責任と捉える
- チームとしてお互いに尊敬して良い形を作る
- 他の人のミスを非難しない
どれも、人間としての力がなければ、どれだけスキルがあっても達成できない事だと思いました。
一緒に働く仲間を信頼する、尊敬するって、いつでもどこでも可能な事ではない。
ただ、そういう運の良い職場で働けるような時のために、人間力を上げていきたいなぁ。
テスターとしてというより、アジャイルなチームの心構えとしていろんな事を考えた回でした。
仕事終わりにかなり濃い内容で辛い部分もありますが(今日も後半途中死にかけてました)、次回も頑張りたいです。
第15回アジャイルサムライ読書会 @札幌道場 開催
3月 1st
第15回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は4名。初心に返る、気持ち引き締まる回でした。
今回の範囲で「グっときた」ところ
規律の徹底。
技術的卓越の追求。
チームがコードを所有する。
勉強会として
今までのページで学んできた事を思い出しながら、この場面では(ここまでで伝えられた事を考えると)何を伝えたいのだろう、とじっくり考えながらのぞむ事ができました。
それでも9.6で書かれていた「正式な受け入れテスト」が具体的にどのような段階でのどのような行為をさすのか、なかなかイメージがわきませんでした。
最終的なものが完成して、最後のリリースが終わって、チームで味わう充実感、完成によって得られるものについての章があったら読んでみたかったなと思いました。
技術的(エンジニアリングの)プラクティスの話が徐々に出てきて、やっと自分の実践や経験した事と絡めながら考えていけるようになってきたな、というのも感じました。
その分、技術者としての基礎体力など足りない部分を足りない!と自覚する部分も増えそうです。
今回の場合だと、「チームでコードを所有する」はとても素晴らしい事だな、素敵だな、と思っているのになかなか実践できていない(全てのソースコードに責任を持てていない)事だな、いかんな、と気がつきました。
ただ、これからどんどん、本に書かれている事が前半よりも身近に感じられてくるような気がします。
運営の立場で
今回、初参加の方がいらっしゃいました。
15回開催して、しばらくぶりの初参加の方でした。
こうして、継続しているとどんどん新しい出会いが生まれていくのだなーというのはとても嬉しかったです。
また、この読書会をJavaFestaの平鍋さんのセッションを通じて知ったと言う事を教えてもらいました。
改めて、いろいろな事はきっちりとつながっているんだなと感じました。
また、初めての方がいらっしゃった事で、初心にかえり、言葉の意味を噛み砕きながらしっかり読み進めていけたような気がします。
知っている、わかっているはずの単語でも、きちんと言葉にして説明する事で見えてくるものもあるな、と改めて感じました。
嬉しい発見がたくさんあった回でした。
ただ、運営の立場であるにもかかわらず、風邪をひいてしまいまして・・・。
ぎりぎりの体調でしたが色々ご迷惑をおかけしてしまい、すみませんでした。
(帰ってダウンしてしまった。今は完全復活しています。)
ディスカッションをまとめたwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120228
最後に、今回も場所を提供してくださった弊社に感謝。
来月も(再来月も)よろしくお願いします!
Head First JavaScript読書会 02に参加しました
3月 1st
2月27日(月)に開催された、Head First JavaScript読書会 02に参加しました。
予習だいじ
今回は前日に該当範囲を読んでから参加することが出来ました。
やっぱり1回読んでおくことは大事ですね。
随所に散りばめられたユーモアをサクっと流しつつ、内容について話し合うことが出来ました。
どんなユーモアが飛び出してくるか、の耐性をつけておくという意味でも事前予習は大切ですね
今回の発見
今回の範囲は、Webアプリを作ったことがあれば、1度は触れることのあるトピックばかりでした。
びっくりしたのは、eval(関数評価)の考え方が突然出てきたところでしょうか。
eval
Timer.setTimeout("alert('hello!!')", 2000); // 2秒後に"hello!!"とアラートを表示する
この”alert(‘hello!!’)”がなぜ「文字列」なのか。
「文字列」じゃないとどうなるのか。
ブラウザのコンソール上で実験しながら詳しく説明してもらいました。
> var bbb = function(){alert('hogehoge')};
undefined
> bbb
function (){alert('hogehoge')} // 文字列がでる
> bbb()
undefined // 実際にアラートが表示される
メモ:nodeを使ってプロンプト上で確認するときはConsole.logを使う
cookie
Cookie周りのソースは、複雑であることを加味してもサンプルソースがちょっとよくないなと思いました。
もう少し見やすくするためには ‘;’ という区切り文字列を、変数に割り当てるか、
‘;’ で結合するためのfunctionを作るか、もう少し可視性の高いコードにしたほうが良いと思いました。
実際に書いてみたら難しいのだけど。
【before】
var date = new Date(); date.setTime(date.getTime() + (30 * 24 * 60 * 60 * 1000) ); var expires = "; expires=" + date.toGMTString(); document.cookie = name + "=" + value + expires + "; path=/" ;
【after(冗長かも)】
var data = keyValue(name, value);
var date = new Date();
date.setTime(date.getTime() + (30 * 24 * 60 * 60 * 1000) );
var expires = keyValue("expires", date.toGMTString());
var path = keyValue("path", "/");
document.cookie = createCookie([data, expires, path]);
function keyValue(key, value){
return key + "=" + value;
}
function createCookie( params ) {
var val = "";
for(var i = 0; i < params.length; i++ ){
if(i != 0 ) val += ";";
val += params[i];
}
return val;
}
※ 書いていて、”=”もうっとうしい事に気がついた
まあ、ライブラリを使うのが確実だと思います。
次回も予習してちゃんとのぞみたいと思います。
4月に入ったらセクションのナビゲーターを担当したいなと思います。(決意)
Sapporo.elに参加した
2月 27th
Ruby Sapporo Night vol.14 に行ってきました
2月 25th
2月23日(木)に開催されたRuby Sapporo Night vol. 14 『Ruby札幌 × Sapporo.js』に行ってきました。
このイベントはRuby札幌がApple Store Sapporoで行っているイベントです。
Ruby札幌の方達の今やっている、気になっている技術のお話を聞けたり、他コミュニティとのコラボ企画で色々な分野のお話を聞く事ができます。
不定期開催、事前登録不要のイベントです。
開催はRuby札幌のサイトやAppleStoreのイベントカレンダーで知る事ができます。
リッチクライアントを中心とするセッションのリンク
前半は、Ruby札幌の島田さんによるセッション
「リッチクライアント時代のWebアプリケーションアーキテクチャパターンについて考える」
”MVC” をキーワードに、従来のMVCとは、そして現代のリッチクライアントに必要なMVCモデルの形についてとお話が発展していきました。
後半はSapporo.jsの佐藤竜之介さんのお話
「Testable JavaScript」
”テストしやすいJavascript” にするためにどのように設計をし、コードを書いていくのが良いか。
Testableにしていくために、MVCモデル(KATA)を考えていく事が大事になると言う話でした。
参加していてとても面白いなあと思った事は、全く違うアプローチから入っていっている両者のお話が、絶妙にリンクしていってたんですよね。
核となる部分に同じ思想があって、それにそれぞれの形で向かっている。
うまく言えないのだけど、すごく気持ちのよいイベントの流れがありました。
あと、お二人のスライドはどちらもお二人の話以外のたくさんの情報が詰まっている。
とってもためになる資料です。公開されている事に感謝です。
リッチクライアントのためのMVC
ちょうど数ヶ月前に「Javascriptのテスト、すごく難しい」と思う事があり、どういう形でテストしていくのがいいのかなーと考えていたので、りゅうのすけ氏のアプローチはとても興味深かったです。
テストツールやテスト用のライブラリの紹介も最後にあったのですが、それよりも「KATA」。
手を加える度に、進歩して行ける開発を!
デスクトップアプリケーションを作った時に学んだ考えも生かしつつ、「良い設計」について考える機会・・・もとい
「良い設計」を意識する気持ちを持つ事ができました。
Javascriptだから、時間ないから無理、と諦めないこと大事。
良い時間を過ごす事ができました。ありがとうございました!
実践アジャイルテスト読書会 01に参加しました
2月 23rd
2月20日(月)に開催された、実践アジャイルテスト読書会 01に参加しました。
今回から始まった読書会、どのようなものかというと(ATNDより)
- 「 実践アジャイルテスト 」をベースにテストに関して学ぶ
- 勉強会の中では書籍の読み合わせ(輪読)は行わない
- あらかじめ該当の章を読み進めて来ることが前提(書籍の購入は必須)
- 担当者が予習して文書(sphinx)にまとめておきそれを元に発表していく形式
大学時代のゼミを思い出します。
1回1回が結構ヘビーになりそうです。
(Head First JavaScript読書会もあるし、アジャイルサムライ読書会もあるし…)
ただ、第1回と第2回は概要についての話になると言う事で「書籍購入不要」。
本を購入せずにどのような勉強会か空気をつかもうと思い参加しました。
まぁ、書籍を持っていなかったの、私だけだったんですけどね…。
アジャイル開発の中でのテスターの重要性
今回の範囲は「1.アジャイルテストとは?」。
大きく分けて以下の3つについて話をしました。
- アジャイルについて
- アジャイルな現場のテスターの役割
- アジャイルなテストについて
アジャイルについて
アジャイル宣言なども読みながら、何に価値をおいているかを理解する。
- アジャイルの価値 “ごく短いリリースサイクルで、ビジネスの価値の小さな塊を提供すること”
- アジャイルの前提 “チームが個々の役割以上の事をする – 職能横断的”
- アジャイルで重要なことは “スピードではなく、高い品質を提供し続ける事”
他の読書会などでも考えていることなので、大きなずれはありませんでした。
スピードではなく高い品質のものを提供し続ける事が大事、と言う部分は絶対に忘れてはいけない。
アジャイルな現場のテスターの役割
チームが個々の役割以上の事をする中で、テスターとはどのような位置づけになるか。
- テスト以上の事をしなければいけない
- バグを見つける事を第一目的とするのではなく、「製品をよくする」為に改善点を探す事を一番大事にする
- テストの中で得られた情報を元に、よりよい方向に “テストを変化させる”
- テスターはお客さんとプログラマの橋渡しができる立場にいる
- テスターの仕事は、顧客がイテレーション毎に実現したいことは何かを顧客が言えるようにすること
ソースコードのテストはプログラマも行う事が多いですが、それによりテスターのやる事がなくなるわけではなく、もっとさらに高い次元のテストを行える事を喜ぶべき、と書いてありました。
プログラマーであっても、テストをする時はテスターの帽子をしっかり意識しないとな。
アジャイルサムライ読書会では開発者各自がどのようなポジションでどのような事をやるかまでは突っ込んでは書かれていない(心構えやチーム作りの話が多い)ので、具体的な「誰はどのような目的でどんな事をやる」というのを整理できたのがよかった。
顧客チームと開発チームの相互作用のベン図はとてもわかりやすかった。
しかし、「顧客がイテレーション毎に実現したいことは何かを顧客が言えるようにすること」って、難しいですね。とてもハードルが高い。
アジャイルなテストについて
アジャイルテストの4象限のうち、アジャイル開発のテスターが行う事は主に「ビジネスに面したテストや要求機能に対するテスト(右上寄り)」となる。
目的は上記テスターの心構えで書いた通り。そのためのテストタイプはたくさんある。
20の質問
今回はその中でも重要になる「探索的テスト」のアプローチを学ぶと言う事で「20の質問」ゲームをしました。
担当者@shuji_w6eさんが頭に思い浮かべたものを、他の人が「Yes/No」で答えられる質問をしながら何かを当てていく(絞り込んでいく)ゲーム。ゲーム?のようなもの。
2回やったのですが、面白かったです。
ちょっと長いですが質問を全部載せてみます。(取りこぼしがあるかも)
<1回目>
現実に存在するか Y
お店に売っているか たぶんN
食べられるか N
自ら動く事ができるか N
さわることができるか N - 触るものじゃない
日本で生まれたものか N
私たちが目にするものか われわれはY 普通の人はN
電気を通す事ができるか N
目に見えるか Y
生き物か N
かべにかかるものか Y かかる時もある
やわらかいものか わからない
光るか N
今日それとかかわったか N
におうか N
カラフルなものか Y カラフルな場合は結構ある
それは絵ですか N 近い
それはホワイトボードか N ホワイトボードに関連する事もある
いろいろなものがまとまっているものか Y
作る事はできるか Y
変化しないものか N 通常は変化する
自分で作った事はあるか Y
アジャイルに関係するか Y する場合もある
それは言語か N
それは工場にあるか Y よくある
それは何かを書くものか わからない
それは何かが書かれるものか Y
それは カンバンですか N 近いけど違う
一般的にあるか 一部の業種の会社にはよくある
一部の業種とは営業か N
一部の業種とは飲食業か N
それは貼る事ができるか Y
それはポスターか N
それがないと使っている人は不便か Y
それは工程表か Y
1回目が終わった時に
「得られた情報を共有しようとする気持ちが足りない、誰が当てるかのゲームではない、チームで当てるために得られた情報から絞り込むというアプローチを考えた方がよい」
と指摘されました。
それをうけてもう一回。
<2回目>
さわれるか Y
食べられるか N
目に見えるものか Y
重いものか 通常はY - 感覚的なものは忘れた方が良い
動くか N
売っているか Y
中に何かを入れるものか Y
どの家庭にもあるものか 通常はY ない家庭もある
独身の家庭にはありますか Y ある場合もない場合もある
それは台所にあるか Y ある場合もある
もつ/もたないは所得に関係するか N
子供がいるかどうかに関係するか N
それでインターネットをする事ができるか N
男性が使うものか N 男性だけのものではない
マンションにあるものか だいたいY
高齢の人が使うものか Y
寒冷地の家庭には必ずあるか Y
沖縄にあるか N 基本的にない ある場合もあるかも
火に関連するものか Y
赤いものか Y 赤い場合もある
冬に使う頻度が上がるものですか Y
それは暖房(ストーブ)ですか Y
「どのような家庭にあるか?」という観点で絞り込みをかけていっているのがわかると思います。
また、1回目に比べてゴールまでの質問数も少なくなりました。
このような感覚やアプローチする方法が「探索的テスト」では必要になるそうです。
なるほどなー。
20の質問ゲームはとても楽しかったです。
皆さんならどんな質問をしようと思いますか?
いろんな人とやってみるとアプローチの方向性が見えて面白いかもしれない。
1回目を終えて
本の内容として、とても高い所を目標にしているので、現実で実現しようと思うと困る所や足りない所がたくさん見えてきそうです。心が折れそうになることもあるようです。
また、本自体も厚く、読み進める事自体がかなり難しそう。
しかも予習必須…! とてもハードな読書会です。
でも、だからこそ、1人でやっても無理なので読書会で学んでいくのが良いのかな、と思いました。
(ということで、読書会中に書籍を購入しました
)
次回もがんばってついていきたいです。
第14回アジャイルサムライ読書会 @札幌道場 開催
2月 15th
第14回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は9名。いろんな方向の話をまとめるのは難しいなあーと感じた回でした。
今回の範囲で「グっときた」ところ
全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない
お客さんが隣に座っている
勉強会として
自宅に帰って本を読み返しつつまとめのwikiを書いていて、若干文脈が違うディスカッションがあったかもしれないなと感じました。
「必要な分だけ、必要なときに」分析すること
“そのイテレーションで必要なものだけを分析していたら全体像が見えなくならないかな?”という話題がでました。
ここでいう「分析」がどういうものを示すのかをきちんと考えておくべきだったなあ。
見知らぬ土地に連れて行かれて「君のフィールドはここだ!さあ武器と防具を選んで!」というイメージではなくて、
見知った自分の土地のうち「今回はあの区画を耕そう、そのためには何の準備が必要かな」そんなイメージ。
(あまりに抽象的すぎますが。)
本章Ⅲ部の計画の段階で下地ができていて、それをさらに落とし込むという段階での「分析」だと思うのだけど、この段階では全体像はどこまで共有できていて、どこまで準備できているんだろう。
決して「行き当たりばったり」でも「今までの経験とスキルでなんとかなる」ものでもないと思う。
実際の業務の場合、この段階での「分析、設計」ってどんな事をするのかな。そしてその段階で揃っている情報はどんなものなんだろう。仕様面だけじゃなくて、技術的・アーキテクチャの面はどこまで固まっているんだろう。
この本で文書は不要と言っているかどうか
“会話とちょっとした文章だけで伝わるから文書はそんなに必要ないというのは文書化できない事に対する言い訳じゃないのかな?”という話題がでました。
家に帰って気がついたのだけど、完全に議論の途中で自分が文中から読み落としてしまっていたところがありました。
この本で、同じ机を全員が囲めるような小さなチームに必要はないだろうと言われているのは「形式的な」文書、ですね。
文書そのものが全くなくて良いと言っているのではなく、2,3人のチームでは「基本設計書」「○○仕様書」みたいな形式的な文書を作る必要はないよね、というニュアンスなんじゃないかなと、読み返して感じました。
「形式的な」って原著だとどのような単語になっているのだろう。
重要な事は「全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない」事。
その方法として文書が必要なチームは必要な文書を作ればいいし、膝を突き合わせてじっくり話し合う事でイメージが共有でき、それでプロジェクトを進める事のできるチームは、話し合いの時の絵や図、カードのメモだけでプロジェクトがうまくすすんでいくんじゃないかなあという個人的な結論に今は至っています。
ペアプロの話
今日はペアプロやってどうだった?得たものは何か?という話ができなかったのでここに書いておきます。
何度かペアプロをして、自分が一番変わったなと思った事は「名前を付ける」事に対する意識です。
クラス名とかメソッド名、パッケージ名(Javaなので)、1人で作っている時はそれなりの名前を付けて終わっていたのだけど、ペアプロをしているときは「本当にこの名前でいいのか」考える時間が増えました。
(そういうペアに恵まれた事が多かったと言う事もあるのかな)
新しいクラスやメソッドを作る、ということはペアプロ中の大きなイベント事なので
「さてどうする」とじっくり話し合うきっかけになる時だったのですよね。
それからは1人でコードに向かう時にも「名前大事」を忘れないようにしています。
みんなはどういう風にペアプロしているのかな、どういう時に困るんだろう。
また今度聞かせてください!
運営の立場で
「適切な話題をきちんとテーブルに載せる」「話をぶった切らない、雑にまとめない」「きちんとした言葉を選んで伝わるように話をする」、とっても難しいなあ。
「この本が本当に伝えたいポイントはどこか」をもっとしっかり考えたいなと思いました。
どうやって進めるのが良いか、14回開催しながらまだまだ試行錯誤中です。
あと今回は時間配分をミスりました。
ちょっと長めの休憩時間を取ったのもあって、途中で終わってしまったセクションには進まなければ良かったかなーと思っています。
実際にどうやってペアプロをやっているか、困った事、ペアプロをやって良かったと思った事、変わった事とかみんなの話を聞く時間を持ちたかった X(
反省点が多い回です。
でも、今回も楽しく充実した時間を過ごせました。
バレンタインデーと言う事で、皆さんにコーヒーとチョコレートを差し入れしました ![]()
(写真を撮るのを忘れたのでありました。ご想像でお楽しみください)
ディスカッションをまとめたwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120214
最後に、場所を提供してくださっている弊社に感謝。
(今回はコーヒーもいただきましたありがとうございます)
また次回から頑張りたいです!
Head First JavaScript読書会 01に参加しました
2月 14th
2月13日に行われたHead First JavaScript読書会 01に参加しました。
この読書会は、Head First JavaScriptの決まった章を読んできて、追加説明を交えながらJavasciptを基礎から学んでいく勉強会です。
しょっぱなから今日の範囲(1章と2章)、流し読みで参加してしまいまして・・・苦労しました。
次回からはちゃんと読んでいきます。
知らなかった事いろいろ
へえ!そうなんだ!と思った事色々を箇条書きにしておきます。
外部ファイルとして定義したスクリプトファイルのキャッシュを適切に制御する
<script type="text/javascript" src="hogehoge.js?20120102"></script>
ファイル名の後ろに任意の文字列をつける事ができる。
内容を変更したタイミングで末尾の文字列を変えると別ファイルとして認識されるのでキャッシュクリアされる。
あと、scriptタグは外部ファイル定義するときも /> で閉じてはいけない。
prompt
使った事なかった・・・。
constで定数定義、遅延初期化はできない
const A; A = 10; alert(A); // undefined
こんな形で使う事ないけど、しらなかった。
constで定義した定数のスコープってどうなるんだろ。
+演算子のルール
前から評価、前から型を推測。
1 + 2 => 3 "1" + "2" => 12 1 + "2" => 12 1 + 2 + "4" => 34 "1" + 2 + 4 => 124 true + 3 => 4 false + 3 => 3 true + true + "3" => 23 true + "3" => "true3"
parseIntとisNaN
isNaNの方が数値の定義が厳しい。
isNaN("200aaa")
=> true
parseInt("200aaa")
=> 200
parseIntとN進数
0が先頭だと8進数、0xが先頭だと16進数に勝手に解釈される。
文字列から適切な進数に変換するためには第二引数を指定する。
parseInt("077")
=> 63
parseInt("077", 10)
=> 77
ルート、ノード、リーフ、エレメント
(この辺はもう頭が沸騰していてアレでした)
親がルート、末端がリーフ、それぞれがノード≒エレメント。
エレメントのidは重複しちゃだめ、絶対。
今日の発見、ここまで。
—–
学ぶ形式の勉強会、仕事終わりだとなかなかハードですね。
アジャイルサムライ読書会や達人プログラマ読書会とは違った部分の脳を使います。
終わり30分前くらいにはぐったりしていました(電池切れ)。
体力つけないと、と感じた勉強会でもありました。
次回、リベンジできるかな。