Skip to content

Latest commit

 

History

History
59 lines (47 loc) · 3.44 KB

Vik_comments_to_editor.adoc

File metadata and controls

59 lines (47 loc) · 3.44 KB

My notes:

chapter 5

  • p. 203 not following what reviewer mean. Code generation is automatic process.

  • p. 214 command line tools like Grunt, bower and yo make development process IDE agnostic.

Chapter 7

  • p. 313 V: we’re giving an explanation through example.

  • p. 315 banderson: Here’s an example: V:

  • p. 316 banderson: Also mention Universal Module Definition here, briefly. - V: mentioned in dedicated section. Also I would prefer to keep sections as is (without additional word Option X)

  • p. 321 banderson: We need a new paragraph. V: new paragraph to explain in code explanation? I didn’t catch that.

  • p. 322 V: distinction b/w CJS and AMD provided later in this section

  • p. 325 V: I agree with code comments. We need to use === in most cases

  • p. 326 V: converted sidebar to subsection

  • p. 329 V: there is no need to add summary in between of chapter. Summary of chapter contains required overview.

    • No. because we develop web application, we’re going to use AMD approach only.

    • extensive overview follows later in this section.

    • yes, it’s a good place for this note.

  • p. 332 V: we have same text at the beginning of this section

  • p. 333 V: OR we can have it as subsection

  • p. 334 V: no we don’t need sudo if we installed node via homebrew. Also, there is no sudo on windows.

  • p. 338 V: AMD is a standard. There is no such thing as AMD modules for RequireJS

  • p. 346 V: I don’t understand the questions?

from Chapters 10-12.pdf document

  • p. 347 example of require.js plugins provided in a prev section with code example usage. I don’t understand the issue.

Chapter 8

  • p. 358 V: Mentioned slide deck demonstrates how to use PhantomJS for performance testing.

  • p. 359 We have given explanation of test in unit test section

  • p. 364-365 I don’t think that we need to contrast TDD and BDD. BDD is just a way to embellish test code for readability and cleanness. I’m not quite understand remark about «headless browser test»

  • p. 367 bug in callouts decoration. asciidoc.conf compat config should fix that.

  • p. 370 code is there

  • p. 372 explanation followed in callouts

  • p. 374 this concept introduced now

  • p. 380 grunt watch task described in tools chapter

  • p. 386 in spirit of tdd spec goes first. Code goes after.

from Chapters 10-12.pdf document

  • p. 359 inconsistency addressed in a favor of JSHint.

  • p. 396 I don’t understand what editor meant here.

Chapter 9

  • p. 403 these tree subsections describe existing architectural styles achieving or emulating same aim - bidirectional communications. On the contrary, websocket is a absolutely new protocol that uses http to bootstrap communication.

  • p. 404 explanation follows

  • p. 407 SSE does only server-push. But it’s only one way street.

  • p. 408 We don’t need to provide any "advanced introduction to IDL". We provide link to wikipedia. IDL not essential to WebSocket. It’s just one of the ways to describe APIs.

  • p. 411 Explanation of TCP is out of the scope of this book. In order for readers to understand this section, we can recommend O’reillys book about TCP, HTTP, HTTPs. Magic string is exact (as mentioned).

  • p. 412 I’ll stick to my formulation

  • p. 418 Yes, csv and psv are still very common formats in enterprises these days

  • p. 420 JSON was extensively covered in ch2. DOn’t want to repeat it here.

  • p. 422 ???

  • p. 439 Chrome Developer Tools are availabe on for …​ Chrome. Wireshark allows to debug networking in browsers which development tools lack of debugging tools for websocket.