Initial commit (a clone of the jsmachines project as of v1.15.3)

blog/2014/03/30/README.md

@@ -0,0 +1,50 @@
+Running on Azure
+---
+Publishing a Node-based site to [Azure](http://azure.com) was painless, thanks to their friendly web portal and
+GitHub integration.  Getting a fully operational site, however, took a bit more time.
+
+Unfortunately, because Azure's underlying server technology is Windows-based (IIS), some of the same Windows/Unix
+portability problems that have plagued us for decades still plague us today: **carriage returns** and **backslashes**.
+
+Even though all PCjs text files in my project contain only linefeeds, IIS would serve them up with CR/LF
+instead.  I first noticed this on the client side, when an XML file retrieved via *XMLHttpRequest()* came back
+full of CR/LFs, and later on the server side, when *fs.readFile()* returned a Markdown file filled with CR/LFs.
+
+I wondered if the CR/LF transformation had happened when Azure pulled all my files from GitHub, because
+while I can understand some whitespace inconsistencies across web servers, I would never expect file system calls
+on the server to modify file contents.
+
+I finally confirmed that the files were indeed modified on the server, by using Azure's FTP browser.  For example,
+[minimal.xml](/configs/pc/keyboards/minimal.xml) is currently 622 bytes locally, but on the Azure server, the
+reported size is 632 bytes -- one extra CR for each of the file's 10 lines.  After a little more digging, I
+[learned something new](http://git-scm.com/book/ch7-1.html#Formatting-and-Whitespace) about **Git**: it has a
+setting called `core.autocrlf` which, for me on OS X, defaults to `input` (meaning "convert CR/LF to LF on commit
+but do NOT convert LF back to CR/LF on check-out").  But Azure apparently sets this to `true`, causing all LFs to be
+converted to CR/LF.
+
+Regarding slashes, even when path components contained only slashes, *path.join()* would return paths with
+backslashes.  And unfortunately, this behavior varies from Node module to module.  For example, I use the NPM
+[glob](https://www.npmjs.org/package/glob) module, and even when the input path to *glob()* contains backslashes,
+its output paths do not.
+
+In the process of fixing those portability issues, I also had some trouble getting Azure logging to work as
+documented.  Setting `loggingEnabled: true` in **/IISNode.yml** would generate logs in **/site/wwwroot/iisnode/**,
+but the logs were numerous and poorly organized.
+
+And the Azure command-line tool that was *supposed* to enable real-time log-streaming to the console:
+
+	azure site log tail pcjs
+	
+would happily report:
+
+	Welcome, you are now connected to log-streaming service
+	
+but it would NEVER display anything but deployment information.  Instead, I had to browse the log files using Azure's
+"FTP DIAGNOSTIC LOGS" link on the web portal -- which presents the logs as one big, ugly, fragmented mess:
+ 
+![Azure Logs](iisnode_logs.png)
+
+Sigh. But at least the site is up and fully operational now.
+
+*[@jeffpar](http://twitter.com/jeffpar)*  
+*March 30, 2014*

blog/2014/03/31/README.md

@@ -0,0 +1,41 @@
+Browser Compatibility Woes
+---
+While JavaScript has been doing a good job of delivering on the old "write once, run everywhere" promise that its
+[unrelated namesake](http://www.java.com) coined, the "hook once, deliver everywhere" promise seems less fulfilled.
+
+Not that anyone ever made such a promise.
+
+Specifically, I'm talking about DOM events.  Take the HTML5 <canvas> element, for example.  If I give 
+it a `contenteditable="true"` attribute, it will play nicely with my JavaScript app in a Mobile Safari browser,
+by popping up the device's soft keyboard in response to the canvas element receiving focus (ie, when you tap on it).
+
+The Silk browser on a Kindle Fire, however, is another story -- it acts like it has no idea what `contenteditable`
+means.  Even if I display an actual <input> text field alongside the <canvas>, and attach all the same
+input event handlers to the text field instead of the canvas, the Kindle Fire's soft keyboard will pop up, but my
+input event handlers still won't fire.
+
+I've done what testing I can with the Android SDK and the "Android Virtual Device Manager", and in general, support
+looks fine -- you click/tap on the PC's screen, the soft keyboard pops up, and typing works.  So I guess Silk is just
+an outlier.  I'm not sure what I'll do about it yet (or even what I can do).
+
+![PCjs in AVD](avd_tablet.png)
+
+---
+
+Here's another issue I've yet to resolve.
+
+When Apple released iOS 7.0, PCjs went from being a rock-solid web application on
+2nd/3rd/4th-generation iPads to a very flaky web application.  It's still rock-solid on 5th-generation iPads
+(the iPad Air and iPad Mini w/Retina Display), and so I suspect a bug in Apple's JavaScript engine that's specific
+to their older A5 processor.
+
+It may be possible to work around the bug, but I haven't yet isolated exactly what code
+sequence(s) are failing.  For now, this is the most serious unresolved PCjs bug I'm aware of.
+
+---
+
+If you're having a problem (or trouble with a device) that I've not already mentioned, [let me know](mailto:Jeff@pcjs.org).
+Thanks.
+
+*[@jeffpar](http://twitter.com/jeffpar)*  
+*March 31, 2014*