Sunday, July 23, 2017

Glimmer Ruby Desktop Library Version

Come and grab Glimmer Ruby Desktop Library Version over here:

Ships with girb (Glimmer IRB), providing a Ruby playground for trying out Glimmer app ideas.

Happy Glimmering!

Saturday, July 22, 2017

Glimmer Ruby Desktop Library Version

The Glimmer Ruby Desktop Library Version was just released.

Key Features:
- Glimmer now uses a Ruby Logger in debug mode to provide helpful debugging information
- Glimmer has a smart new Ruby shell script for executing applications
- ***DRUMROLL*** As part of the smart new Ruby shell script, Glimmer now downloads swt.jar automatically for the user platform whether Mac, Windows, or Linux, and whether it's an x86 or x86-64 CPU architecture.

Below are new sections added to Glimmer's README:

More details can be found at the project page README over here:

Happy Glimmering!

Friday, July 21, 2017

Glimmer Ruby Desktop Library Version

Glimmer - The Original One and Only - is alive and well. A new version has just been released supporting Ruby 2.3.0 (jruby- and SWT 4.7.0, with improved glimmer executable and instructions.

Get it here.

Example code:

Tuesday, July 18, 2017

On Software Engineering with Elm

This blog post explores Elm following software engineering methods. So, get ready for some hardcore engineering talk as opposed to pure software development geeking out.

My entry into as a software engineer in late 2011 coincided with an explosion of JavaScript frameworks, each claiming to be the end all be all that would solve all your JavaScript troubles. We happened to adopt Backbone.js at Groupon, and I, as a software engineer, sadly saw extreme over-engineering of the front-end with Backbone.js going through multiple components just to submit a simple form.

Sadly, nowadays the situation is worse as I have recently worked on a React-heavy app and was surprised by how much code I had to maintain just to submit a simple React form. It had many levels of indirections and too much componentization, definitely swinging the balance in the wrong direction.

In short, I am pretty skeptical when encountering new JavaScript technologies that push developers too far from writing basic JavaScript. For example, I still think jQuery is sufficient for most JavaScript needs on its own or augmented by underscore.js (or something similar). I also think CoffeeScript is close enough to JavaScript to make the jump tiny and worth it.

What is Elm in any case?

Elm: a typed functional programming language that compiles to JavaScript

Features as per their website:
- Compiles to and interops with JavaScript
- No runtime exceptions, friendly hints at compile time instead due to strong static type checking with type inference
- Great performance (fastest compared to Angular, React, and Ember)
- Enforced Semantic Versioning

Now that we had an introduction to what Elm is, let's continue our conversation on software engineering with Elm by studying it from a software architect's point of view.

1. What are the functional requirements or use-cases regarding front-end development with JavaScript?

During my career in business application web development, these are all the use-cases I've encountered as per my memory:
- Highlight or flash an element upon data entry or making a mistake
- Open or close a drawer containing information
- Expand or shrink a text area containing an article
- Animate data graphs like piecharts
- Light boxes and dialogs to give user information or gather input
- Scripting of video and audio
- Parallax, that is ability to scroll page into via with the trackpad or mouse like going through a pop-up book
- Linking user actions to partial views on the screen (think of browsing emails in affecting the master email view)

2. What are the non-functional requirements that affect technology decisions on the front-end?

- Productivity: how productive can good developers be at pumping out features that are satisfactory for the customer?
- Maintainability: how easily and quickly can good developers maintain existing code when adding/modifying features and fixing bugs?
- Stability: does the technology facilitate avoiding bugs and enable writing reliable front-end applications?
- Performance: having just enough response time for the user (no delay longer than 2 seconds, with the average being half a second or less)?
- Security: is data protected when submitted over the wire to the server?
- Usability: how user-friendly and effective user-interfaces can be.

That should be enough to get us moving, albeit there might be non-functional requirements like Legal Adherability (e.g. HIPAA Compliance), Accessibility, and Localization/Internationalization, but let's stick with the ones above for now.

3. Discuss Specific Technologies

A. Vanilla JavaScript

So, if I were to rate vanilla JavaScript on the points mentioned above for developing front-ends, here is how it goes:
- Productivity: 7 (JS has improved quite a bit with newer versions, but I still find utility libraries like jQuery and underscore.js more powerful than plain JavaScript)
- Maintainability: 2 (It's JavaScript man! What did you expect?!!!)
- Stability: 2 (Ditto as Maintainability)
- Performance: 9 (for the use cases mentioned above, JavaScript is more than fast enough. I've even seen it run 3D animations quickly enough)
- Security: 8 (decent support in browsers for blocking cross scripting attacks and hiding passwords seems to shield us well enough for today)
- Usability: 5 (it's hard to implement interactive and visual front-ends with vanilla JavaScript)

B. JavaScript DOM/Utility Library (jQueryjQuery UI, underscore.js, and other similar small libraries)
- Productivity: 9
- Maintainability: 4 (jQuery and _ require terser code, thus less code to maintain, still it's JavaScript man.)
- Stability: 4 (less code means less chance for error, still it's JavaScript man.)
- Performance: 8 (still fast enough for the use cases mentioned above, nothing to complain about)
- Security: 9 (jQuery works hard at protecting you when performing Ajax calls via good APIs)
- Usability: 7 (jQuery and _ certainly help in building more usable user interfaces)

C. JavaScript Framework
- Productivity: 8 (productivity takes a dip due to increased complexity, even if the framework was React, one of the simpler frameworks)
- Maintainability: ranges from 2 to 7 depending on the framework and use-case (for most use-cases it takes a dip due to increased complexity)
- Stability: ranges from 2 to 5 depending on the framework and use-case (takes a dip to complexity or improves a bit for highly interactive UIs)
- Performance: ranges from 5 to 10 (badly written framework JS code, which is way more common than you think, yields worse performance, even with React. Otherwise, performance only improves from a framework with well-written code addressing a highly updating UI problem like stock ticking or live news updates)
- Security: 7 (takes a hit in badly written over-complex framework code)
- Usability: 9 (this might be where frameworks shine, as they enable building very intricate user interfaces when needed)

D. JavaScript Interop Language (CoffeeScriptElm, Clojurescript, etc...) (judged independently of B and C, albeit it is additive to them)
- Productivity: ranges from 5 with Elm and Typescript, to 7 with Clojurescript, and 9 with CoffeeScript (haha, this was not researched... just a gut feeling. To explain, Clojurescript maintenance will counter balance its productivity benefits. It's hard to find developers committed to it on top of JavaScript. CoffeeScript is on the other hand close enough to JavaScript not to require much extra commitment. Elm and Typescript defeat the point of JavaScript and bring productivity down with their complexity. Few people will do very well with them I admit, but just few. Not something everyone is interested to invest in and struggle through finding hires for. )
- Maintainability: ranges from 1 to 7 (Ditto as Productivity)
- Stability: ranges from 1 to 7 (Ditto as Productivity)
- Performance: ranges from 9 to 10 (using these languages might improve performance due to taking care of optimizing JS for you)
- Security: ranges from 8 in dynamically typed languages to 9 with statically typed ones (types can improve security since they limit vectors of attack)
- Usability: ranges from 3 to 9 (Ditto as Productivity)

4. Summary

I am not so excited for Elm, Clojurescript, TypeScript or any language that moves too far from basic JavaScript because:
- I want to find hires who are good enough in JavaScript first let alone some esoteric language
- I want to do as little JavaScript as possible and keep web apps focused on serving customers without confusing them with overly flashy features
- I want to avoid over-engineering with something as powerful as Elm that acts like a nuclear device shooting a fly
- I want to avoid pre-mature optimizations. Most of the time, jQuery runs fast enough, and in rare cases, I could optimize a bit and succeed without something like Elm or even React.

Monday, July 10, 2017

Learning Clojure Is a Sunk Cost

Here is a message I wrote to an old colleague of mine after spending time learning Clojure from the "Functional Programming for the Object Oriented Programmer" book, and then beginning to read "The Joy of Clojure".

I might have made a few typos. Please don't judge!

Message body begins here.


Yesterday, I bought the Joy of Clojure eBook/liveBook edition at Manning. After reading through the first few chapters, here is my opinion as summarized the upcoming 3 paragraphs. I shall blog and tweet my opinions too very soon.

“One example of incidental complexity is the tendency of modern object-oriented languages to require that every piece of runnable code be packaged in layers of class definitions, inheritance, and type declarations.”

This is not the programming language consumer concern. It is the programming language creator concern. To a consumer, you would not have to know about the many layers of Object inheritance and can avoid inheritance except where it offers value. This is not a problem except to the inexperienced developer, which would have a problem with LISP too and any other language. Last but not least, type declarations are not needed in Python, Ruby, nor Smalltalk. I think the author was only talking about one OO language, Java, and it's the old Java as the new Java 8 has optional typing now. That point is very weak and does not hold up as a valid use case for Clojure. One more note, Clojure programmers would still have those classes in LISP too, albeit in a different form; as structures or maps, and separate functions. Does that remind you of anything? Sure, C and structured programming. In fact, they are less readable than Object Oriented abstractions in a clean language like Ruby or Smalltalk and introduce the very problem of maintainability that Object Oriented Programming solved long ago. Also, Python, Ruby, and Smalltalk all allow functional style of programming and expressibility while retaining Object Oriented Programming paradigms. There is not selling point here. I'd recommend mastering Ruby or Python instead.

“Clojure cuts through all this by championing the pure function, which takes a few arguments and produces a return value based solely on those arguments. ”

Object Oriented Programming languages already support writing functions, such as Ruby, Python, and Smalltalk among many other examples. Even Java now supports that with Java 8 Lambda Expression even if it did not support in the past. This renders this argument moot with regards to "simplicity" even when taking Clojure's unique Purity support into account. Still, "simplicity" is not enough to ensure having readable and maintainable code, and thus Object Orientation was came about to narrow down the difference between the way we "think" and the way "code", taking advantage of the fact that computers are more than fast enough to spend cycles on supporting such abstractions while still serving users on time.

“An enormous amount of Clojure is built from such functions, and most applications can be, too, which means there’s less to think about when you’re trying to solve the problem at hand.”

As mentioned before, Object Oriented Languages already permit writing such functions (Ruby, Python, Smalltalk). But suppose there is less, in an Enterprise production application, there would still be a lot to reason about all at once, breaking the 7±2 rule of how much a developer can hold in their head to stay productive in problem solving. So, the way to surmount that is to rely on an abstraction mechanism that shields one from details, as no amount of simplicity in a health comparison machine learning algorithm for example would render the algorithm simple, even in Clojure. Developers would still have to deal with complexity, and abstraction hides it better. Furthermore, "Functions" only represent verbs, which is not how we naturally think of the world. Data may represent objects, but keeping both separated creates the very problem that spawned Object Oriented Programming in the first place as mentioned before. Yes, sounds like this is a problem of lack of understanding of Object Oriented Programming in the wild due to being in academia (I am talking about Rich Hickey, I don't care how hard he worked if he's doing the wrong kind of work.. that's biblical, you do your work for God and he guides you on the right path for building things for the real world. I doubt his work was for God, I feel it was for his own personal gratification).

I am sorry I am not sold anymore, and feel I wasted my time learning Clojure, and would have better spent my time learning LISP or Haskell instead for educational purposes only, and then apply its learning in Ruby or Java 8. The price I paid for the book is "Sunk Cost" as per Microeconomics theory, so I'd get more value of that money by forgetting Clojure, not wasting more of my time on top of that money.

In the meantime, I'm buying Programming in Scala next by Martin Oderskey. By the way, of course I know Martin Oderskey. He was famous for adding Generics to Java 5, one of my favorite features at the time. I have very high regard and respect for him. He talked for years about adding Scala-like features to Java, and that didn't materialize till 10 years later in Java 8. I am sure I will get value by learning Scala as that would make me a stronger Java 8 developer since it adds most of its features. I look forward to that reading sometime later today.

As a recap about my opinions of Clojure, I think Rich Hickey was hiding under his brilliance in academia from delivering real customer value in teams of programmers with practical experience, so he does not understand Software "Engineering" concerns very well, and spins factually inaccurate information to motivate people to use a LISP in a production setting instead, without mastering languages like Python, Ruby, or Smalltalk first. May the Lord Jesus Christ deal with him fairly for the benefit of humanity. Just to be clear, I come from Academia as well, so I highly respect University Professors and their works so long as it serves the Lord Jesus Christ and humanity practically instead of wasting people's times and masking Academics' fear of working practically in the real world. The Rubber (Academic Theory) must hit the Road (Real World) before it offers real value to people.

To repay the favor of recommended books, may I recommend to you reading "Java 8 Lambdas" by O'Reilley ( It was a very quick and practical read for me when I worked at Grass Valley a couple of years ago. I'm sure it would go down as easily as a marshmallow for an experienced Scala developer since most of the concepts come from it anyways.


Monday, March 06, 2017

puts_debuggerer v0.5.0 adds caller, formatter, and more goodies

puts_debuggerer v0.5.0

Yes, many of us avoid debuggers like the plague and clamp on to our puts statements like an umbrella in a stormy day. Why not make it official and have puts debugging become its own perfectly legitimate thing?!!
And thus, puts_debuggerer was born. A guilt-free puts debugger Ruby gem FTW!
In other words, puts_debuggerer is a Ruby library for improved puts debugging, automatically displaying bonus useful information such as source line number and source code.
Partially inspired (only partially ;) by this blog post: (Credit to Tenderlove.)
Below are some of its options.


Options enable more data to be displayed with puts_debuggerer, such as the caller backtrace, header, and footer. They also allow customization of output format.


(default = :p)
Print engine to use in object printout (e.g. pappp). It is represented by the print engine's global method name as a symbol (e.g. :ap for awesome_print). Defaults to Ruby's built-in p method identified by the symbol :p. If it finds awesome_print loaded, it defaults to ap as :ap instead.
# File Name: /Users/User/example.rb
require 'awesome_print'
PutsDebuggerer.print_engine = :ap
array = [1, [2, 3]]
pd array
Prints out:
[PD] /Users/User/example.rb:5
   > pd array
  => [
    [0] 1,
    [1] [
        [0] 2,
        [1] 3


(default = "[PD]")
Announcer (e.g. [PD]) to announce every print out with (default: "[PD]")
PutsDebuggerer.announcer = "*** PD ***\n  "
pd (x=1)
Prints out:
*** PD ***
   > pd x=1
  => "1"


(default = PutsDebuggerer::FORMATTER_DEFAULT)
Formatter used in every print out Passed a data argument with the following keys:
  • :announcer (string)
  • :caller (array)
  • :file (string)
  • :footer (string)
  • :header (string)
  • :line_number (string)
  • :pd_expression (string)
  • :object (object)
  • :object_printer (proc)
NOTE: data for :object_printer is not a string, yet a proc that must be called to output value. It is a proc as it automatically handles usage of print_engine and encapsulates its details. In any case, data for :object is available should one want to avoid altogether.
PutsDebuggerer.formatter = -> (data) {
  puts "-<#{data[:announcer]}>-"
  puts "HEADER: #{data[:header]}"
  puts "FILE: #{data[:file]}"
  puts "LINE: #{data[:line_number]}"
  puts "EXPRESSION: #{data[:pd_expression]}"
  print "PRINT OUT: "
  puts "CALLER: #{data[:caller].to_a.first}"
  puts "FOOTER: #{data[:footer]}"
pd (x=1)
Prints out:
FILE: /Users/User/example.rb
HEADER: ********************************************************************************
CALLER: #/Users/User/master_examples.rb:83:in `block (3 levels) in '
FOOTER: ********************************************************************************


(default = nil)
Caller backtrace included at the end of every print out Passed an argument of true/false, nil, or depth as an integer.
  • true and -1 means include full caller backtrace
  • false and nil means do not include caller backtrace
  • depth (0-based) means include limited caller backtrace depth
# File Name: /Users/User/sample_app/lib/sample.rb
PutsDebuggerer.caller = 3
pd (x=1)
Prints out:
[PD] /Users/User/sample_app/lib/sample.rb:3
    > pd x=1
   => "1"
     /Users/User/sample_app/lib/master_samples.rb:368:in \`block (3 levels) in <top (required)>\'
     /Users/User/.rvm/rubies/ruby-2.4.0/lib/ruby/2.4.0/irb/workspace.rb:87:in \`eval\'
     /Users/User/.rvm/rubies/ruby-2.4.0/lib/ruby/2.4.0/irb/workspace.rb:87:in \`evaluate\'
     /Users/User/.rvm/rubies/ruby-2.4.0/lib/ruby/2.4.0/irb/context.rb:381:in \`evaluate\'

Options can be set as a global configuration or piecemeal per puts statement.

Global configuration is done via PutsDebuggerer module attribute writers. On the other hand, piecemeal options can be passed to the pd global method as the second argument.

# File Name: /Users/User/project/piecemeal.rb
data = [1, [2, 3]]
pd data, header: '>'*80, footer: '<'*80, announcer: "   -<[PD]>-\n  "
Prints out:
   > pd data
  => [1, [2, 3]]

Become a puts_debuggerer!

Sunday, March 05, 2017

puts_debuggerer v0.3.0 (header/footer + multi-line)

What's New in puts_debuggerer v0.3.0 ?

Simply invoke global pd method anywhere you'd like to see line number and source code with output. If the argument is a pure string, the print out is simplified by not showing duplicate source.
Quickly locate printed lines using Find feature (e.g. CTRL+F) by looking for:
  • [PD]
  • file:line_number
  • ruby expression.
This gives you the added benefit of easily removing your pd statements later on from the code.
Happy puts_debuggerering!
Example Code:
# /Users/User/finance_calculator_app/pd_test.rb # line 1
bug = 'beattle'                                 # line 2
pd "Show me the source of the bug: #{bug}"      # line 3
pd 'What line number am I?'                     # line 4
Example Printout:
[PD] /Users/User/finance_calculator_app/pd_test.rb:3
   > ("Show me the source of the bug: #{bug}").inspect
  => "Show me the source of the bug: beattle"
[PD] /Users/User/finance_calculator_app/pd_test.rb:4 "What line number am I?"


Header to include at the top of every print out.
  • Default value is nil
  • Value true enables header as '*'*80
  • Value falsenil, or empty string disables header
  • Any other string value gets set as a custom header
PutsDebuggerer.header = true
pd (x=1)
Prints out:
[PD] /Users/User/example.rb:2
   > (x=1).inspect
  => "1"


Footer to include at the bottom of every print out.
  • Default value is nil
  • Value true enables footer as '*'*80
  • Value falsenil, or empty string disables footer
  • Any other string value gets set as a custom footer
PutsDebuggerer.footer = true
pd (x=1)
Prints out
[PD] /Users/User/example.rb:2
   > (x=1).inspect
  => "1"

Become a puts_debuggerer!