My Life and Code

The first time I really listened to Led Zeppelin was in my junior year of high school, when my friend John gave me a copy of Led Zeppelin IV  for Christmas. It was one of those rare, consistent albums that I could listen to from start to finish without wanting to skip a track. Not too long after that I picked up Houses of the Holy  and was surprised to find that I liked that  album even more . Sometime after that , I picked up Led Zeppelin II , which I didn't like as much as the other two albums I already had. After high school, I picked up the boxed set . This was my first exposure to a lot of the tracks from the albums I didn't own. One of the things about the boxed set that I heard people say they didn't like was that the tracks were out of chronological order, and it can be kind of confusing as to which song came from which album. A few years later I picked up the second boxed set which included all of the remaining studio tracks not on the first boxed set (pretty cool

  If you don’t know how something works, how can you fix it when it doesn’t  work? This is why I’m not entirely behind something like GitHub Copilot. It’s already easy for developers to copy and paste code they find on the internet and implement it without understanding how it works. Here’s a ridiculous, real-world example. In 1979, “Star Trek: The Motion Picture” was released. It had amazing special effects but awful pacing. It’s a slow movie, to put it lightly. Yet it’s been re-released twice in the past 20 years with additional special effects work…and not much done to improve its pace. The special effects were never the problem, but that’s what they’ve “fixed”, twice. This is a movie which includes a 10 minute long sequence with no dialog, just the characters flying through a cloud and looking at a viewscreen. They might as well have put the word “Intermission” on the screen during this sequence so the audience would know they could get up, use the bathroom, and not miss anything i

One of my favorite bands is Queen . Probably more than any band, the music of Queen takes me back to certain moments of my life, as if part of the soundtrack to it. Along with Iron Maiden , they were a perennial during a period of my life. Just recently, I started listening to them again after many years without. I became a fan after their career with the original lineup had ended, and over the course of some time collected their albums. I didn't get them all in the order they were released (far from it), and could easily pick up an album from a different stage in their career which was much different in style from whatever my previous purchase was. Below is my ranking of their studio albums, from least favorite to favorite. This is just my opinion , and not an attempt to say "this album is better than that  one" -- it's only personal preference. 15. Flash Gordon Released 12/8/1980 This album is ranked last on my list simply because it's the one I listen to least.

For formatting dates in HTML, Angular provides DatePipe , but what if you need to format a date within a component, service, or other non-HTML code? For this, Angular provides the formatDate()  function. I was unaware of this function until one of the developers I work with submitted a pull request where he used it. I've often seen developers inject DatePipe  into their components when they need to format dates, but formatDate()  is the better option for that. Here's an example: public formattedDate : string = formatDate ( Date . now (), "MM/dd/yyyy" , 'en-US' ); You can read it about it at the official docs here .

In most cases, when you subscribe to an Observable , you should also unsubscribe  from it. In Angular, there are a few exceptions (for example, Observables returned by HttpClient ), but usually unsubscribing is the way to go. But how would you write a unit test to make sure this happens? One way is by using a  Subject . A Subject is a kind of Observable. It includes an observed  property which is a boolean and indicates whether or not it is being subscribed to. Prior to this, there was an observers  property which provided a count of observers, but this has been deprecated. In the test below, the component being tested contains code to ensure that JobListenerService.jobCompleted  Observable is being unsubscribed to when the component's ngOnDestroy()  method is called. The mock of the service returns a Subject  (a type of Observable), and we use that Subject to verify that it's being observed before the component is destroyed, but no longer being observed after  the component is

When it comes to application architecture, my approach is holistic: it's not just about the application design, but the things around  the application -- for example, unit tests and linting -- that can help produce a solid application.  Here are some of my thoughts for creating successful Angular applications, though many of these apply to other sorts of applications as well. The goal is to design something in such a way that it's easy to maintain, easy to enhance, avoids pitfalls, and most importantly, works as intended . Here we go! 1. Use those spec files Angular was designed from the start with unit testing in mind. But a lot of Angular developers I've spoken to don't use the spec files the CLI creates for us. Having good code coverage is important, and it's worth taking the time to write those unit tests. For more information on how unit testing has helped me write better software, check out  this post. 2. Organize code into judicious feature modules with lazy-