Continuous Learning

I began a new learning journey a few months ago when I set out to create a little app to solve a problem for me. I decided to do this in the most vanilla way possible with JavaScript, HTML, CSS and at the time an undetermined testing tool. I knew I was going to use TDD & BDD as my design approach. Why did I make these decisions? I don’t know. It seemed like a good idea at the time… I eventually decided, and with the help of some cohorts, began to use Cypress with Cucumber.

Things Learned & Still Learning…

JavaScript

Frameworks. If you have read any of my previous posts, I am not a fan of frameworks. That is usually directed towards so called “agile frameworks” like Scrum or SAFe. I think of the frameworks to JavaScript in a similar way but not including the dysfunction of the process frameworks related to agile. I think if I started to learn JavaScript via a framework first rather than vanilla JavaScript, I would have the same understanding of the language as those that learn Scrum or SAFe and think they understand agility.

Browser dependencies. I have noticed some odd occurrences depending on the browser in which my application runs. Some of this undoubtedly is my inexperience, but some apparently is how browsers treat the events in the application. I am not really sure at this point if it is my lack of skill or a true limitation between JavaScript and browsers for some of the issues I see. The learning and research will continue on this one. I am pretty sure this learning path will take me towards writing JavaScript server-side with node.js. I will have to circle back on this in a future post…

Varying variables. The flexibility to change the meaning of a variable throughout it’s usage in the application I find to be interesting. I don’t see it as good or bad, just that it is flexible. My concern could be that by doing this we could easily couple too much functionality into a single function. Thereby creating something that is both difficult to understand by looking at the code and to test. But given that I am new to this, maybe I am just stupid.

Single-threaded. I quite like this honestly. But I am a simpleton. I enjoy the fact that JavaScript will only run through one line of code at a time.

Objecty Functions or Functiony Objects. JavaScript functions can have their own methods, properties or added features. You can assign functions to variables or array elements. I think I even passed one function through another function. Inception Based Programming… Or maybe I was hallucinating… It’s been a rough month…

Cypress W/ Cucumber

Configuration. I am forever thankful to my cohorts and in this case specifically @alfredoig for helping me figure out how to install and configure Cypress with Cucumber. It was not as straight forward as I was initially led to believe when looking into this on my own. Tip that seems obvious but needs to be said; Be sure you are in the correct directory ;).

Browser Testing vs Headless. When running Cypress tests headless, the errors are usually very clear and help you to figure out what direction you need to go. However, take a moment to run the same tests in the browser and watch what happens. I have noticed on numerous occasions that a test will fail running headless but pass and work quite nicely in any one of the browsers Cypress offers.

False Failing. Tests will fail during creating other tests and functionality that aren’t actually failing. Let me explain.

• New functionality to add to the application.
• Create ‘Given’.
• Run test.
• See ‘Given’ test fail but also another random test fail…
• Curiosity and learning begins…

To attempt figuring out if this was a false failure, first thing was to check tests in the browser. When the tests also failed in the browser, I then took the error to google and the Cypress community in an effort to figure out how my lowly ‘Given’ was breaking a whole other functionality and test. After not being able to figure it out, I decided to return to safety and remove the ‘Given’ of the new test and see what happened. Everything passed. So now what? Put the ‘Given’ back in. Same failing results… Hmmm… Next experiment, finish the test and functionality. When that was done, all tests passed again. I was able to eventually find that others experience this error at random. More learning and research to come…

Things I do

Story Mapping. I started this idea of an app with a story map. I took the steps that I usually take to get something done and created a sticky note for each one. Then I sequenced them from left to right. After that, I began to go a little deeper into each step as to what I would do, or what had to happen to complete the step. Then I took an honest look at it and decided what I ‘thought’ would make a usable tool to solve my problem. Nothing pretty. No bells and whistles as you might say. Just the functionality I was looking for to solve my problem. Then I drew my horizontal line across the map. For anyone who hasn’t used a story map before, the things I ‘think’ I need to make this work go above the line, everything else goes below the line. Then I started creating stuff. If you have read my stuff before you may be able to guess what happened next. I said… ‘Now That I’ve Seen It…’

And this is where I like a story map but also see quite the amount of misuse with story maps. My map with what I ‘thought‘ was needed to make a usable tool changed. Yes, it can, does, will and should change. For me the horizontal slice across your map is not supposed to be treated as a locked in plan of what you will definitely deliver. Maybe you will eventually create all of those things for all of those steps in that map. Or perhaps, and for me preferably, while you create the things in the map and begin to use them, you will take an honest look at your map. Ask some questions.

• Is what we have on the map still what we need?
• Should something in the map be dropped for something else?
• Did we realize something in the time we were creating that last thing that we missed?
• Are we actually done?

There are a bunch of questions you could ask that would help you steer the thing you are creating. But not if you don’t stop to ask and answer them.

If you are interested in learning more about story mapping, event storming and domain driven design, here is a list of stuff that I have found helpful.

• User Story Mapping by Jeff Patton
• Passionate Produce Leadership Course by Jeff Patton
• Event Storming by Alberto Brandolini
• Domain Driven Design Distilled by Vaughn Vernon

Practice, Practice, Practice… I learn by doing things, repeatedly in most cases. With JavaScript it has been no different. When I first learn something new, I try to use it again and again in various scenarios to see what the outcomes are. I experiment with this new thing to see what I can do with it. I am practicing. And much like my meathead football brain works, as you practice something, it becomes second nature.

K.I.S.S. Method. This is not a new thing for me as I grew up with this from my father. And this is not really a JavaScript thing as much as a working and learning thing. If you are not familiar with the K.I.S.S. Method it goes like this: Keep.It.Simple.Stupid. Do not try to tackle some large piece of functionality all at once. Narrow things down. Keep things small. Your brain will thank you.

Get Going. We can research things all day and google to our hearts desires. But just like with learning anything else, JavaScript is best learned by doing it. Get started creating something. Even if you have never written a line of code before and need to google or stack overflow a solution. That is fine. But once you have the solution in your IDE, and see it working, dissect it. Step through what it is doing line by line. Remember how JavaScript is single-threaded?! This is where that is also a benefit. Now obviously you don’t want to build an entire app this way, but we are talking about getting some working software in front of you to get going on your learning journey.

TDD & BDD. My preferred design approach to creating software is TDD. I enjoy the flow, the smallness, the dopamine hits of rapid feedback, continuous integration and overall learning. Since I decided to use Cypress with Cucumber, I have interjected BDD into this design approach. Things I’ve noticed since taking this approach:

• I enjoy creating the tests with Gherkin G/W/T. The plain language of it gives my brain a break from code. The trade-off is there is an extra step of writing the Gherkin then creating the step definitions of the test. Making sure that text matches is another bit of pain. But the benefit of coming back to the test later and having it easily understandable to anyone whether they create software or not is nice.
• Writing tests backwards from the ‘Then’ (expected outcome) has allowed me to focus on the outcome. When I have a hard time having the test make sense, taking this approach allows me to feel that and what I am trying to do is not very well understood and probably far to big and complex.
• Naming makes a big difference. Using BDD has let me think more clearly about people that don’t know code reading my code. With this in mind I have found the value of explicit names. Abbreviations are pain. Unclear strings of text that don’t actually let me know what this code does, ex: “runJob”, are pain.
• Using the language of the domain. Directly related to explicit naming is naming with the domain language. If you use a different term than the business domain to describe the same thing, this causes pain. Same if you use the same term as the business domain but it has a different meaning. Pain. Pain by way of confusion.

Recommendations

Try to find a group of people that have the same interest in what you are doing. In this situation, it is learning JavaScript taking a TDD/BDD design approach with Cypress and Cucumber. It also helps if the thing you are creating with this software is something that peaks the interest of others. When you find this group of people, try to set up time to work on creating the bits and pieces of the application together. In other words, mob program. The learning is shared, the ability to pull from one another is such a better experience than the searching google or stack overflow on your own.

Closing… For Now…

My learning journey with JavaScript and Cypress with Cucumber will continue. And there will be future posts about it. With this initial post, I hope I was able to share that more than learning these tools is the act of learning itself. Find something that interests you and take some time to learn about it. Whether you end up using that thing or not, you will learn something that is beneficial to you. And the experience is worth it.