Dave's Notebook

Secrets to Your First Programming Job

This past week I was talking to a guy who is graduating from College and looking for a job. He asked me what most people ask at that point in their career. “Everyone wants experience, but how do you get experience if no one will give it to you?”

What is interesting is that for all the advances in the 30 years since I started my career, that question is still the main question every graduate asks.

Now, before I get started, I want to make sure we are clear. These tips may or may not work for you. They are what I would do, and in large part are what I did 30 years ago, just updated to be appropriate to the current technology. How well they work for you are going to depend on a lot of different factors, not least of which is how much effort you apply. They are also very much based on my culture here in the USA. If you are looking for a job in another country that is dissimilar culturally, you may want to ignore this advice completely. But, I’ll also say this. If what you are currently doing isn’t working, what do you have to lose?

![](/uploads/2017/05/2017-05-13.png)
Photo credit: [MDGovpics](//www.flickr.com/photos/mdgovpics/8157677890/) via [Visualhunt.com](//visualhunt.com/re/abeb67) / [ CC BY](//creativecommons.org/licenses/by/2.0/)

Read More

Using Real World NgRX

This week, I want to demonstrate some ways you might use NgRX in your own code.

Review

Last week we went into a lot of detail about how the NgRX system should be wired together. Here is all of that in picture form.

image

A component fires an event to either an effect or a reducer using an action. If an effect was called, it fires another action which is normally picked up by a reducer. The Reducer mutates the state which then gets placed in the store. “Magic happens here.” You don’t write any code to get it to the store other than that you create a reducer. Anything that is observing the table in the store that got changed will get notified via RxJS observables and the cycle is complete.

Note that the action you dispatch can be handled by either an Effect, a Reducer or both.

Basic CRUD

Most of the time, we think of NgRX as a way of handling CRUD operations. We need to see the current record so we fire off a LOAD action that uses an effect to retrieve the data from the database. Once the data comes back, we return an action that tells the reducer to put that new data into the store. Since our component is observing the store, it updates the screen with the new values.

If we need to add a record, we fire an ADD action. If we need to delete we fire a DELETE action. If we need to update, we fire an UPDATE action. Each of these are picked up by the Effect, which then fires an action that places new state information in the store via the Reducer.

Wait State

When most people think of how to use NgRX or any similar pattern, they immediately think of the CRUD pattern I mentioned above. But, we don’t have to start the Action chain from a component. For that matter, we don’t have to listen to our Store data from a component either.

One way I’ve implemented NgRX that solves a lot of common issues is that I’ve created a wait state component that shows when a count variable has been incremented and doesn’t show when the count is zero. Since Store is Injectable, I can increment and decrement the count from just about anywhere. Most often I increment it from an effect just before I make an AJAX call and decrement it in a finally() block of the Http observable. I have a start() action that increments the count and an end() action that decrements the count and ensures that I never go below zero. I can start off multiple asynchronous processes which will all increment the counter and decrement the counter appropriately. The wait state GUI displays until everything has finished.

This is OH! So much easier than how we’ve had to handle this problem with other design patterns. I’m not saying it couldn’t be done, or that it was even particularly hard. But this way is easier.

Error Handling

Another place where you might want to present information but trigger the display from just about anywhere is with error handling. In the code I work on, I have a modal popup component that displays whenever my error collection has something in it. Anytime I need to display an error, I add the error to the collection via an Action and it magically displays. The great thing about this mechanism is that regardless of how many errors I send to the collection, they all display until I close the window, which clears out the collection.

Page State

Most page state is handled by the fact that we’ve stored the data into a database. But there are times when we want to come back to a page we had been working on previously and we want it to display with the data that was on it at the time we left.

Or maybe you want to work on a series of pages prior to saving so that everything gets saved as a set.

No matter. You can use NgRX to store everything into the store and a separate action can trigger an effect that pushes that data to the database.

Or, as is the case in an application I’m working on, I’m using a form to search a database. When I come back, I want the same search fields and I want the search to reinitialized. In my particular case, I don’t have a search field. You change a field, a new search is automatically initiated. This case is just a little bit more complicated than what we’ve looked at so far.

image

In order to keep the state information available so that it is there when I come back to it, I need to store that information in the search table via the Search Reducer. So, every time something changes in the Search Form, I send off an action to the Search Reducer so that the change can be recorded.

Meanwhile, the Search Form also is listening to the Search Table so that when it comes back it can put the changes in the form, and it can send an action to the Search Results Reducer telling it to search for the information. When it gets the results, the Search Results Table picks them up and since the Search Results Component is listening to the Search Results Table, they display.

If I leave the page, the Search Form grabs the current search parameters from the Search Table and Fills the Form and sends the action to the Search Results Reducer and the page is back where we left it.

Conclusion

The point is, NgRX isn’t just about basic CRUD forms and because there are multiple ways you can mix and match the parts, even your basic CRUD implementation has a lot more flexibility than you might be used to.

Angular(2+) Model Driven Forms Are Superior

If you are programming in Angular and haven’t tried Model Driven Forms yet, I’m assuming that is because you’ve not taken the time to try to learn it. In this article, I am going to try to convince you that the Model Driven Form based approach is superior to Template Driven Forms and that the only people that are still using Template Driven Forms are people who either have not been enlightened or lazy.

![](/uploads/2017/04/image-4.png "Angular(2+) Model Driven Forms Are Superior")
Photo credit: [DarlingJack](//www.flickr.com/photos/aceofknaves/33346081006/) via [Visualhunt.com](//visualhunt.com/re/f8175d) / [ CC BY](//creativecommons.org/licenses/by/2.0/)

Read More

More Control with Angular Flex Layout

If you are using Angular(2+) and you are looking for an easy way to layout your components that gives you lots of flexibility and very few restrictions, you owe it to yourself to checkout Angular Flex Layout.  While it is still in Beta, the framework is quite usable.  I’ve been using it in one of my projects and I’ve been quite happy with the results.

![](/uploads/2017/04/image-2.png "More Control with Angular Flex Layout") Photo via [VisualHunt.com](//visualhunt.com/re/7d8037)

Read More

Unit Testing Angular(2+) with JSDOM

Unit Testing Angular(2+) with JSDOM can be problematic unless you know the secret handshake that allows ZoneJS and JSDOM to coexist.

The great thing about Angular is that you can write Unit Tests from the presentation layer all the way down to calls to the server.  But up until now, you either ran those tests in a browser, which doesn’t work well in a CI system, or you used PhantomJS, which tends to be REALLY slow!  But there is a better way, and hopefully, by the time this post goes live, the patches needed to use JSDOM will be available.  If not, I’ll show you the hack that I’ve found works and the pull request I’m hoping will go live.

![](/uploads/2017/04/image.png "Unit Testing Angular(2+) with JSDOM")
Photo credit: [Juanedc](//www.flickr.com/photos/juanedc/14896919066/) via [Visual Hunt](//visualhunt.com/re/cf947c) / [ CC BY](//creativecommons.org/licenses/by/2.0/)

Read More

Coasting, Curiosity, Diversification and Being Awesome

There are two twin evils that I see in the programming community. The first is the programmer who knows what he knows and has no desire to learn more. I call these, “coasters”. And then there are the programmers who are so curious that they try to learn every new thing that comes along, with no focus. The interesting thing is, both of these types of people end up at the same place. Out of work. The cure for both is the same.  Being Awesome.

![](/uploads/2017/03/image-3.png "Coasting, Curiosity, Diversification and Being Awesome")
Photo credit: [aaronHwarren](//www.flickr.com/photos/pedalfreak/3745777389/) via [Visual hunt](//visualhunt.com/re/1b14eb) / [ CC BY-ND](//creativecommons.org/licenses/by-nd/2.0/)

Read More

3 JavaScript Fallacies You Might Believe

You know, you think the whole world knows something is true until you hear someone people respect say something really dumb.  The three JavaScript fallacies I have here are actual statements I’ve heard over the last week during a discussion about Angular2 and Rect.  What makes these fallacies particularly interesting is that they sound plausible.  In fact, there are time when they are even true.  But in the larger context of a JavaScript application they are nearly always false.

So, here are 3 JavaScript Fallacies you may still believe that you may want to reevaluate.

![](/uploads/2017/03/image-2.png "3 JavaScript Fallacies You Might Believe")
Photo credit: [bark](//www.flickr.com/photos/barkbud/4341791754/) via [VisualHunt](//visualhunt.com/re/8dc251) / [ CC BY](//creativecommons.org/licenses/by/2.0/)

Read More

Confident Programmer Secrets, Revealed

To say there are secrets to being a confident programmer may seem a bit over the top. But, you would be surprised at what makes a programmer seem confident, how you can be more confident, why confidence is no real indicator of truth, and why you need to arm yourself against confidence.

![](/uploads/2017/03/image.png "Confident Programmer Secrets Revealed") Photo via [VisualHunt.com](//visualhunt.com/re/7edea7)

Read More

Accessing Private Fields in TypeScript

Have you ever needed to access a private field in TypeScript? The most common place you may find yourself needing to do this is while writing a unit test. But, I also found myself needing to do this while using a JavaScript library where the field wasn’t declared in the type file for the library I was using.

Now, suppose you could access those private fields effortlessly and easily. How valuable would that be to you?

![](/uploads/2017/02/image-3.png "Accessing Private Fields in TypeScript") Photo via [VisualHunt](//visualhunt.com/)

Read More

JavaScript Fatigue Makes Me Scream

Maybe JavaScript Fatigue makes you scream too. Are you annoyed with the constantly changing JavaScript environment? Do you wish things could just settle down for a bit? Have you decided that you won’t learn anything new because there will just be something new to learn tomorrow? Welcome to JavaScript Fatigue. But frankly, unlike many people who talk about JavaScript Fatigue, I see JavaScript Fatigue and the much broader subject of language fatigue as a symptom of a much larger problem that has less to do with JavaScript and more to do with human psychology and the state of the programming community at large. image

What is JavaScript Fatigue

JavaScript Fatigue is the belief that there are so many ways of assembling a JavaScript project that instead of just having to learn JavaScript, you have to learn several other related technologies.  It is in essence, more about decision overload than it is about JavaScript specifically. Think about the average JavaScript project that goes beyond the (now) old school “Augment my form with some jQuery.” Here are a sample of decisions that need to be made:

  • Should you use a JavaScript framework, or just write native JavaScript?
  • If you decide to use a framework, which one should you use?
  • What tool(s) will you use to bundle, minify, cache bust, and tree shake your code?
  • Should you bother lazy loading?
  • Will you use MVVM, MVC, Redux or something else as a basic architecture?
  • How do you plan on dealing with AJAX calls? Callback hell? Promises? RxJS? Something yet to be created?
  • What directory structure will you use?
  • What component libraries will you use?
  • How will you style your application?  Raw CSS? Bootstrap? Material Design?
  • What development environment will you use?
  • Oh and by the way, to use most of these tools you’ll need to learn node and may need to decide between NPM and YARN.

I recently heard that for a basic React application there are about 40 different decisions of this kind that need to be made.

Why JavaScript Fatigue Is Considered a Problem

If you are working on your own, or working in a small shop without any clear architectural direction, the choices can seem overwhelming. For that matter, if you are an architect, this is still a pretty long list of things that you need to learn well enough to evaluate. But the reason JavaScript fatigue is a problem is because it triggers emotions of fear, anger, and depression. It all starts with fear. You look at all the stuff that you “need to learn” and think, “I can’t possibly learn all of that. And even if I do, there will be something newer tomorrow that I’ll need to learn.” And so your fear turns to anger. I’m not talking rage kind of anger. Just that mild, “I’m not in control here and I’m feeling a bit uncomfortable” kind of anger. And this point, the next most logical thing most of us attempt to do is to try to get some sort of control over the situation. But in this case, the beast can’t be tamed.  So, we resign ourselves to the situation and decide that since we can’t control any of it, we’ll give it a name and in really extreme situations give up learning any of it. Yes, I’ve actually read comments and had conversations with people who have told me as much. “Too much new stuff to keep track of, I’ve just given up.” Hey, OK. Don’t complain to me when you can’t get a job though.

How to Fix JavaScript Fatigue

I used to think that the people who had given up like this had either lost their love of learning, or were so distracted by the bright and shiny that they had hit overload and couldn’t continue. I now see that the real problem is depression. A natural extension of anger. But, suppose there was a different way of looking a all of this JavaScript Fatigue stuff? Yes, there is a lot of stuff to learn. A lot of stuff you could learn. And you see, that’s the first step. There is a world of difference from NEEDing to learn all that is out there and having that all be things you could learn. I doubt you evaluated all the possible languages you could use prior to using the first language you used. Maybe it was chosen for you by your first job. Maybe it was the language you were most attracted to. In my case, I tried three different languages prior to my first job and when I started my first job, I wasn’t using any of them. Even today. How many languages are there? How many do you know? The point is, you don’t HAVE to know everything about anything. You really only need to know enough to get your work done. Sure, there will be something new and shiny. Take your time and evaluate if it is even worth looking at. Dip your toes in.  Does what you’ve seen so far make sense? Go further. Recently, YARN has become the “hot new thing.”  I tried it. It didn’t work in my current environment. At least for now, we are sticking with NPM. We’ll take another look when it matures a bit further. I love learning. But, I also realize I can only learn one thing at a time. I can’t be awesome at everything. So, I focus. Everything else I might need to know, I learn well enough to get the core thing done.

Conclusion

And so, the cure for JavaScript Fatigue lies not outside of us, but within. Fix your perspective.  Focus on what you need to know now. Learn bits at a time. Don’t worry about what is coming. There will always be new stuff. Not just with JavaScript but in the programming world in general. Even in the world at large. Don’t worry, be happy!