code master

Thursday, August 17, 2017

There is no redeeming point to this blog post, so if you're greatly offended by the title, move on please and make America great again by respecting people's freedoms.

Yes, React.js is for Dumb People, literally!

Think of the selling points:
- Reliable for being supported by a major company: Facebook
- High performance
- Everything (content, style, behavior) is mixed into the same file, making it simpler to understand
- Components

Any web developer worth his salt knows how to put a small JavaScript component using nothing but pure JavaScript + a library like jQuery, and it's FAST ENOUGH for 90% of the businesses out there as well as super reliable, especially when covered by Jasmine tests or the like, and finally with so little code pumped out, is super maintainable too.

Before I revisit React.js's selling points, notice who its main adopting audience is: Super inexperienced developers worried about not understanding JavaScript and thus need a guarantee of reliability, performance, and a dumbproof way for understanding content, style, and behavior!

In fact, I'd say React.js's success mainly comes from the rise of programming to a degree that everyone and their mother got hired at software development companies, even without degrees or sufficient training.

"- Reliable for being supported by a major company: Facebook"

Yes, an inexperienced developer who wants to lie to a customer to give them confidence in his skills will want to heavily sit on a technology backed by a major company like Facebook.

Naturally, an experienced smart developer can piece together code relying on good open-source libraries by judging them from experience and good software engineering skills. Such a smart developer has already delivered software to thousands if not millions of customers and as such has no worry about requiring an open-source library to have the backing of a large company like Facebook.

"- High performance"

An inexperienced dumb developer doesn't even realize that most business apps don't need much performance since they don't have a highly updating user-interface, so they waste their time over-engineering their solution by using React.js under the guise of simplicity when an experienced developer already wrote many fast-enough simpler components without React.js and maintained them better.

"- Everything (content, style, behavior) is mixed into the same file, making it simpler to understand"

Hahaha. This is like saying I don't know how to ride a bike (maintain content, style and behavior separately), so let's add a third wheel and pretend to be riding a bike. 'Nuff Said!

"- Components"

I already touched on that under the performance section, but let's just say this is the "EXCITING" part of React.js for many new comers who've never wrote a component on their own before due to having very little formal training in software engineering or even Agile software development methods like eXtreme Programming.

Yes, people have been writing components for decades. Yes, GOOD developers do that only. Yes, it takes experience to write good components. Check out TinyMCE as a good example among many JS libraries that are componentized.

Let's use a bit of intelligence and agility in writing our JavaScript code, shall we!

Saturday, July 29, 2017

Rails generators are a form of meta-programming in Ruby. They're basically programs that write programs. To be more specific, in my open-source project Ultra Light Wizard (also a pattern presented at RailsConf 2014), the Rails generator ultra_light_wizard:scaffoldgenerates models, controllers, views, routes, helpers and a migration automatically when the user wants to build a wizard.

How does one test-drive such a Rails generator though?

I started by writing a standard RSpec test and then quickly realized that if I were to test-drive what each file generated contains, I'd be opening a can of worms and getting lost in so much unimportant detail.

Then, I had an idea. Why not create a full-fledged Rails app as a fixture and place it under the "spec/fixtures" directory?

Next, how about I configure the app exactly as needed to run the generate command from a test, but then during the test, I leave it untouched and copy it on every test-run to avoid messing up the reference version?

Well, to explain, you end up with an RSpec test that looks like this:

Now, comes the tricky part. How do you test by invoking the generator on the project copy?

Well, I took the easy way out and simply dropped down to the shell from Ruby as follows:

In other words, by invoking "rake" from the Rails project copy, I started another RSpec test suite run from within my main test suite. Totally meta, eh!?

Now, here comes the meat of the work, in the form of feature specs written for the Rails project copy. To explain, the tests shown below are written from the user's point of view for the effect of running the generator in a real Rails app (the top part consists of helpers [e.g. fill_in_project_fields] and the bottom part has the test cases as "scenarios" [e.g. scenario 'can start wizard']):

And with that... problem solved. Here is an example test run:

Notice how the inside RSpec test-run (from the reference Rails project copy) reported 5 examples, and then the outer RSpec test-run reported 1 example (the one that spawned the rest).

Pros to this approach are success in covering end-result of generation, and decoupling tests from detailed work of generator.

Cons are obviously increased complexity, albeit that is balanced with decreased complexity of writing the inner integration specs and freedom of implementation.

How have you handled Rails generator testing in the past? Care to discuss pros and cons?

Wednesday, July 26, 2017

I have recently explored the idea of self-installing apps while implementing the new Glimmer executable.

What do I mean by a self-installing app?

An application that requires external dependencies, potentially written in multiple languages/technologies, and can handle self-installing them upon first-run via a simple seed command.

Think of it like a seed of a bean plant, which you'd plant (download), water (execute), and then voila, a full-grown app sprouts up, grabbing extra components off the Internet as needed.

To translate this into my example above, Glimmer, has a non-ruby dependency, SWT.jar (Java Archive), which must be setup properly for Glimmer to work. As a self-installing app however, it detects whether SWT.jar is available or not on the first run, and automatically downloads and installs it if unavailable, or otherwise uses it and runs without a hitch. That works on Mac, Windows, and Linux with both x86 and x86-64 CPU architectures.

Self-installing apps are nothing new, but I am documenting my first venture into it in JRuby (albeit I've collaborated with a developer in the past who wrote such an installer for an application I built at a past company I worked for)

I shall explore the idea of having self-installing apps auto-update themselves as well in the future. Stay tuned for a blog post about the subject if I do implement.

Would it be a good idea if all software was self-installing and self-aware? Please share your thoughts in comments.

Set condition for when to run as specified by an index, array, or range.

Default value is nil meaning always

Value as an Integer index (1-based) specifies at which run to print once

Value as an Array of indices specifies at which runs to print multiple times

Value as a range specifies at which runs to print multiple times, indefinitely if it ends with ..-1 or ...-1

Can be set globally via PutsDebuggerer.run_at or piecemeal via pd object, run_at: run_at_value

Global usage should be good enough for most cases. When there is a need to track a single expression among several, you may add the option piecemeal, but it expects the same exact object passed to pd for counting.