DEV Community: Joseph Jung

How my greenfield projects fall into muddy messes…

Joseph Jung — Thu, 05 Apr 2018 05:16:41 +0000

When I started off as a developer, I remember the lead architect lamenting the fact that he hadn’t been on a“greenfield” project in a while - as he was scrolling through 30,000 lines of CSS code in one file…

7 years later, I ask myself the question, “Have I learned how to keep a greenfield project ‘green’?”

In the software world, the term “greenfield” refers to a brand new project, a lush undisturbed land, clean and un-trampled. In this place, a coder can lay down new laws, foundation, and ideals. He hopes people will come and view its beauty, maintainability, and scalability for years to come. Unfortunately, in one or two years time, reality comes crashing in with a vengeance. The project is no longer a “green field”, but rather a muddy mess.

So what causes this? Here’s my opinion from my experience:

Narrow deadlines provide easy excuses to compromise on code quality.
Tests fall behind because they’re hard to write and there’s not enough time.
Team leads are too embarrassed or not skilled enough for code reviews.
Scope creep messes up the most well-laid abstractions.

So how do you combat “muddy mess” syndrome? Ideally, you handle it BEFORE the technical debt accrues, but that hardly ever realistically happens. First of all, accept the fact that you WILL have to let go of some of your rules. Regardless, enumerate the most important ones (like testing) and hold fast to them. Communicate those principles. Don’t be afraid to say “that code is not very good”. Do these things, and next thing you know, you’ll be promoted to engineering lead, and you can slowly melt into middle management.

This is original content from snaptest.io, made because I needed to get tests made quickly and easily for many “muddy mess” projects.

Getting your head around Chrome headless

Joseph Jung — Thu, 17 Aug 2017 19:09:42 +0000

A slew of new automation “stuff has just arrived due to Chrome’s new headless feature in v59. As creator of snaptest.io, it’s my job to stay up-to-date with them.

So here’s what you need toÂ know:

A headless browser means you don’t see it open when you start it, it’s all in memoryâ€Š–â€Šand it also implies user actions are automated.
Uses of automation:

QA tests
Scraping
Pre-rendering single-page apps.

Uses of headless:

Less resource intensive.
Great for build-systems running tests before a deploy.
Can run in many more server environments, like Lambda.

Is this the first headless automated browser? No, phantomJS has been the goto browser like this, but the main contributor almost immediately stepped down when he heard about Chrome’s new headless featureÂ . Turns out its hard to maintain an ENTIRE browser.

So what’s actually new in ChromeÂ v59?

running the executable like this: chromeâ€Š–â€Šheadlessâ€Š–â€Šdisable-gpuâ€Š–â€Šremote-debugging-port=9222 which opens it without a visible window.
then sending commands to the above port… closest to the metal node library is this oneÂ .
the above commands give you ability to do almost anything a user would do… so you can scrape data or make tests.

The community is responding

The community has decided that we need a pretty wrapper around this “low level stuff, and have started making these:

Chromeless (a combination of the words “Chrome and “Headless and maybe even “Serverless”).
Puppeteer (Googles very own “lightweight wrapper”)
Simple-headless-chrome (another wrapper) Probably many more to come!

Conclusion:

What’s the state of each of these frameworks? Let’s find out in a couple months once they’ve grown up a bit. Comparing and contrasting right now would be a practice in futility.

Be thankful for your github repo graveyard

Joseph Jung — Fri, 21 Apr 2017 22:27:28 +0000

I have a good feeling that I’m not alone when I see a desolate graveyard of repositories when signing in to Github. Here’s a list of some casualties in my account with post-mortems:

jDrawerâ€Š–â€Ša jQuery drawer plugin. Died quickly after getting hit by a “no one cared” bus…
KodeKarateâ€Š–â€Šcollaborative code/test writing… though having a hip name, it suffered from a “too over-complicated” attack.
Hail-the-kingâ€Š–â€ŠA javascript clone of Travian… Had a bad case of “too ambitious” and died young.
A web pack starter kitâ€Š–â€ŠHad a good run with … 5 users? Still limping along but about to croak.
lwrnc(stands for Lawrence) rendererâ€Š–â€ŠA node template renderer– suffocated after finding out renderers were much more complicated originally thought. This list goes on and on…

It may be tempting to look back on these projects and regret the “lack of motivation”, but is that really what happened?
I think project graveyards are actually good things, and should be viewed so. Why’s that? It shows that:

You are ambitious.
You at least know when to quit.
You’ve probably learned that you should think things through BEFORE you start.

It’s inevitable that you will fall out of love with your project, after which the value it provides to others will be what keeps you motivated.
Think about itâ€Š–â€Šmost of these dead projects probably would’ve taken way too much timeâ€Š–â€Šit’s not easy to bring a project to the public… bug fixes, complaints, feature requests, potential hosting costs… a whole host of headaches.

I think I’ve made a tool that provides value for peopleâ€Š–â€ŠA chrome extension called snaptest that emulates Selenium in the browser so you can actually easily debug your QA tests. I find value with it at work, and other people email me saying that it helps them a lot. Even though it may not be the most interesting subject matter in the world, it provides value to others, which gives me the “good feels”.

So keep looking for ways to add value, and be thankful for your github graveyard.

The guilt of not testing everything

Joseph Jung — Thu, 13 Apr 2017 15:46:06 +0000

My CTO: “We’re really impressed with your testing solution, you’ve gone above and beyond!”

(Immediate feeling of guilt washes over me)

This happened a couple months ago after my CTO heard about a testing solution I put together for our web applications. My solution was to auto-generate the QA Selenium code instead of manually coding it by recording/configuring the tests. (Shameless plug: it’s available for free over at snaptest.io . This tool has dramatically increased coverage - but why did I still feel guilty about accepting this compliment?

It’s because I unreasonably assume testing should be exhaustive.

Exhaustive testing: refers to running a test on every possible combination of actions/data.

The guilt comes when I say things like: “I’ve tested the new feature”, or “the tests are passing”. In the back of my mind, I know there are hundreds of thousands of combinations I didn’t test for.

We must give ourselves a break and remember that exhaustive testing is usually not possible. One must reconcile the cost/reward balance sheet of testing… Especially when you start thinking about negative tests.

Negative tests/Destructive tests/error path testingâ€Š–â€Šrefers to checking how gracefully a system handles errors or unexpected situations. This is when exhaustive testing gets exhausting… Don’t expect to get them all.

Here are my recommendations for handling negative test cases:

Pick off the easy negative tests like form validation.
Defer negative tests that will take a lot of work to create and maintain. Such as 1 slow network connections on mobile applications. It may be more economical just to manually test those occasionally.
Spend time making negative tests on the most commonly experienced errors. Ask yourselves, which errors are users most likely to see? Cover those ones.
Don’t worry if you don’t cover every state of the app. Just remember, any test is helpful!