Tuesday, December 18, 2012

Thoughts on JavaScript Development

Subject: Thoughts on JavaScript Development

  • note: originally emailed 12/18/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...




Sent by XXX:
I am trying to put together an argument to use pure JavaScript. I wanted to get some of your thoughts on large scale application JavaScript. Like how feasible you think it is to use JavaScript for large scale applications and where the code base can become large. Also some ideas on how to combat the fact that JavaScript is not a structured language and sometimes makes maintainability of a code base and testing and such a nightmare.


I would have to ask, what is the application trying to do?

One of the mantras of “unix” utilities is, small programs that does one thing really really well.  But you can put a bunch of them together to make really powerful and extremely flexible set of tools.  Putting them together leverages each of the specialized utilities (concentrated in what they do) to make a bigger (and more useful) end product results.

Wait… here it is: http://en.wikipedia.org/wiki/Unix_philosophy
  • To this, I would liken it to the *.lib concept in programming (instead of end user executables)

You will have some people argue against that for ‘large scale application’ – but I contend that it is [usable].

As for code bases becoming large:
  • Just like any other programming languages, a good set of APIs and documentation would carry it a long way.
  • Again, think of it as if you were releasing an XYZ.lib object, it is only useful if it's easy to pick up and run with it.
  • However, in JS, it’s even easier for people to just try:
    • By just including an 'example' demo with the "library" --  this will make developers that much closer to using it.
    • [Downloading and running it] is a lot easier than "lemme see how I’m supposed to be using this…"
  • Large code base can be managed by modularizing the components to specific tasks
    • This is by far my #1 requirement and the way I do things.
    • Think of this as, if I find a better replacement, I can drag and drop it in.
    • Lately [work related], it’s the need for an [alternative] mode – using a plug-in style provides the mechanism for this.
      • So in [ABC], for example, the core logic of controlling the boxes and displaying the visuals are all the same.
      • The network messages, on the other hand, are different.  So these were split off from the core base code.  Again maintaining the separation of logic by putting them in their own "modular" file/component.
      • [XYZ] does this too.  Right now we have basic [xyz1] and [xyz2] (it isn’t separated yet) but think of it as how you have [awesome featurez currently]. All of the core functionality are split out.  This can also be done in JS.
        • I hope to split out [xyz2] and make (maybe) [xyz3 soon] to further show the modularity concept.

As for its non structured language:
  • Just like any other programming languages, unit testing is invaluable.
  • Javascript is just as easy to unit test and can be done along with normal development.
    • I would contend that it is even easier to write test cases for it in JS.
    • I can add a “debug” [file] version that is normally not picked up on release -- but when included, [it] will augment the features, capabilities, flow, etc. without interrupting or polluting the base code.
      • I have done a GIANT code clean up to show this concept a bit more clearly.
      • The PHP code was cleaned out of any ‘core logic’ – this was pushed in the base game JS code
      • Any “add-ons” are dynamically included (see AlertBox, DebugPrint, [abc], etc as examples).
        • None of them have any required code called from the base game
        • Just including the JS file will automatically generate and append the required code in the browser
    • Again, following the “example” demo method, you see it running live, can take any of the code you may find useful or leave it alone, very flexible.
  • I would also argue that it’s actually easier to maintain (and read and follow the flow) of scripting languages than the giant plumbing [code in] structured languages.  Which goes into my next topic: framework.
    • But first, don’t get me wrong, I totally understand the need for strong typed languages and I have programmed with them a lot in the past.
    • But, I [find] there are a lot of times when I need to write quick and small utilities, [and] I prefer to write them with as little lines of code as possible.
    • The benefits of extreme-rapid-development with very-fast-iteration times has far outweighed the usability of strict and terse programming.

HTML(5) + CSS(3) + JS *is* a framework [out of the box].  A lot of work has been done by a bunch of hard core nerds that created quite simply an extremely robust yet flexible/tailor-able renderer that can be your basic e-reader, live auction viewer, balance your financials, connected/online universe, and a whole heap of other possibilities.
  • I would also mention that there isn’t that much more (system) code that needs to be written to provide features already supported by the browser itself. Let me re-phrase that.  There’s no need to re-write (i.e. re-invent) the core features already available in the modern browser.

Finally, the sheer volume of documentation, books, online resources and examples out there makes it very easy to find solutions to questions, problems and wonderment when everyone is speaking down to the nuts and bolts – pure JS.  Otherwise, you will be hard pressed to find the same answers, suggestions and recommendations if it was written anything else for the browser.

Hope this helps

Wednesday, December 12, 2012

jenkins and puppet

Subject: jenkins and puppet

  • note: originally emailed 12/12/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...



Ok, here’s what I got from trying to figure out what Jenkins and Puppet is.



Starting with Puppet, from Puppet Labs:

At first, I thought they are something like building you own distro with a configurable ‘manifest’ (it kinda is).  But upon reading part 2 of their 'learning puppet' docs it finally became clear what puppet does (go figure that it was on the last page of their collection of docs:).

It basically describes the "agent" doing a pull-request from the "master" for work" – this is nothing more than:
  • Poll the server to find out what-to-do…

In a nutshell, this is a way to deploy a node (either natively or VM) like any other linux distro, but does have some interesting ways to configure/interface with cloud providers (like netflix’s asgard), see the node’s status, configurations (like openNMS/nagios) as well as updating/patching them (like rsync).

Again, the feature is the ability to run unit testing with the agent and master configuration.



Jenkins is a continuous integration server.  Basically, a 'build server' – which I believe is a must have for any projects that uses compilers.  Not quite so much for web based content though [using Jenkins, that is...].
  • However, the stuff that you plow into Jenkins is the same stuff I plow into a script file.
  • Put this together with a cronjob (or whatever periodic scheduler you like) and you have Jenkins.
    • which can have more [added tasks], customizations and logic plowed in there
    • and generate a results page


It doesn’t seem that Jenkins will run and do unit testing on the build’s executable.
  • But, this is where Puppet comes in.