2019 – Page 2 – Stephen Adams

Show Some Love for the Angular CLI

I’ve recently listened to the latest episode of Adventures in Angular, a great podcast. In this episode they were discussing the merits of the Angular CLI, what it does for us as Angular developers, how much is saves a company on time and money.

The Angular CLI makes writing Angular applications so fast and easy. Before the CLI we had to handle all the build steps ourselves, using tools like Grunt than Gulp. Both fantastic build tools, but having to fight our way through JSON config files was not easy, especially if you wanted to create the ideal setup for your project. It would take days of tweaking the config settings working on the ideal build process.
Then you had to share this build setup with your other team members, and if one thing was different on their system, then the build would fail for them, it was a nightmare.
Thankfully the CLI has taken all that away from us, now there is one universal way of building and running an Angular application locally, which works the same for all members of a team.

Another great benefit of having a CLI is that we no longer have to worry about what build system a project is using. Whether it’s Grunt, Gulp, Bazel or Rollup, this is all handled behind the scenes by the CLI. So as new build systems are coming out, the CLI team can add them to the CLI and we as Angular developers can either accept the new build system the team have added to the CLI or make some changes to our angular.json file and choose the build system we want for our projects.

I think one of the greatest benefits of the CLI is how easy it makes running Unit Tests. Before Angular, in AngularJS, setting up Karma and Jasmine was a painful experience. Again, tackling JSON files, making sure all the paths were correct, spending hours searching for answers to errors when we finally tried running the tests. Reading blog posts where someone showed us a few ‘simple’ steps to making it all work first time, and finding that after following these ‘simple’ steps Karma still didn’t work for us, then trying to figure out where we went wrong. Setting up Unit Tests was a painful and long process, but now with the CLI it’s all handled for us. All we do is run a simple command, and boom all our Tests are run.

The Adventures in Angular episode really did show how much time and effort the CLI now saves us, not only as developers, but the costs it saves companies. No longer do companies have to pay developers for setting up their local build systems, now an Angular developer can be up and running in no time.

If, as an Angular developer, you’ve gotten use to having the CLI around, take a minute to think about all the benefits it brings us. The CLI is really an amazing tool, it really helps separate Angular from the other front-end frameworks out there.

Shared Module vs Module Per Component

Recently I saw Julien Renaux posted on Twitter that whenever they work on an Angular application, there were a few things they always did in their approach to how they built the application. One of these things they did was write one module per component, this drew a response from another developer asking why they didn’t use a SharedModule instead.

So this got me thinking why would you use a module per component instead of a shared module?

Before we look at the benefits of the module per component approach, it’s worth looking at the other approaches we can take in our Angular application.

First, there is the Featured module approach, this is where we are developing a feature of our application, say user management. So we create a UserManagement module that has all the functionality associated with user management, all the components and services for that feature. This is a pretty standard approach, which we start with when getting started with Angular.

Another approach is creating a SharedModule. In this shared module we may have components or services that are going to, well, shared in several features. For example, we may have an authentication service, which checks if a user is authenticated or not. We may need this functionality throughout an application, so placing this service in a SharedModule that is included into all the sections we need makes sense.

The problem with the share module approach is that over time and in a large application this module could grow out of control. Especially if you have multiple developers working on an application, and they don’t know where to add a new service or component they are creating, which is clearly not part of a feature module. The temptation is to add it to this global shared module, which over time gets bigger and bigger. I’ve seen this happen with .Net projects. They have a shared library that became a dumping ground for services where the developer wasn’t too sure where the best place to add their new service was.

There is also another approach, the module per component approach. This is where for each component, we create a module for each component in our application. At first that sounds like a big overhead having to create this module every time we create a new component, but it does have two great benefits. One, it helps with tree-shaking. If our application is not using the component, then it’s not loaded. This reduces the load the browser needs to make, increasing the speed our application loads.

The second advantage this brings is when importing a module, we know exactly what is in that component specific module. Unlike the shared module approach where they are other components and services which are part of this shared module. The single component module approach means we know that the single component is part of the module we’re importing. It keeps our imports clean.

This approach has been used to great effect by the Angular Material team, who changed from the feature module approach to the component per module approach. Now when using Angular Material we only import the module for the components we are using. Keeping the size of the Angular Material library we add to our applications down to a minimum.

So what is the best approach? Well, with all things it depends on your circumstance and the type of application you are building. For large enterprise application, where you are building a set of Angular applications across an organisation. There maybe a need for a limited shared module that has some functionality that is needed for each application. If you have a design system for your applications that give each app the same UI then the module per component approach is extremely useful. Just as it is in Angular Material.

As Angular continues to grow and being used in more and more large enterprise applications, the best practices for how to manage and make best use modules will continue to mature. So it is still something that needs to be researched into and as Angular developers we need to document the pros and cons of these different approaches so other developers can learn from what we’ve found when they come to deciding what their approach to modules is going to be.

Using iA Writer for blog content

I bought a licence for iA Writer ages ago, but never really used it that much at first. I was looking for a writing application as I was planning to start writing a eBook.
So I looked around at the various options, there was Ulysses, Bear Notes, Evernote and iA Writer.

I knew I wanted a Markdown writer because Markdown is becoming a universal way of writing content on the web now. Not only is it used for things like GitHub, but now blog posts can be written in it, and even eBooks can be written using Markdown.

So this excluded the idea of using Evernote for a writing application. It is a great note taking application, ideal for keeping notes, ideas and plans together and the search in Evernote is amazing, but the writing and formatting within Evernote is not as good as it could be, hopefully it is something they add soon.

I did have a look at Ulysses for a bit, I downloaded the demo version and explored using it. Some of the features I really liked, like the word count target and the focussed UI when you are writing are both great features. I did find having to buy a monthly licence a problem because I was already paying for a yearly subscription to Evernote, getting another subscription on top of Evernote just for a writing application? I just couldn’t justify the cost to myself.

Then I looked at Bear Notes as I thought it would be both a replacement for Evernote and a writing application. It seemed great on paper, I could create notes as I did in Evernote, I could write quickly and easily using the Markdown features Bear supports, it seemed ideal. But after a while I found that it was becoming a mess, well the way I was using it. With out the structure of Notebooks, and Stacks that Evernote gave you I soon had things all over the place and I found that I missed the powerful search that Evernote provides.

In between going from Evernote to Bear and back again, I had a look at iA Writer, it was cheaper to buy than Ulysses. There was a one-off payment, no monthly subscription so if I bought it and didn’t use it much there was just the one payment instead of having a subscription for a service I didn’t use.
It had versions for Mac, iPad and iPhone all synced through iCloud. All my content was stored in my iCloud account, which I liked and the UI was well thought out.
So I paid for a subscription licence and installed it, then used it a couple of times and then left it. I suppose I got caught up in the online hype of Bear, so went onto trying that out.

After going back to Evernote I remember that I had iA Writer installed so I fired it up and found that solved a lot of the issues I had. Again it had the Markdown support, I can export to WordPress directly so I can write blog posts in iA Writer. I can tag things and use folders, so I can use it for more than blog posts, I can write the long form in it (I’m currently writing my Angular book using it) I can export in different formats if I want. The syncing between devices is really good. As soon as I stop writing on one device I can carry on using another device to continue on the same file. It works really well on iPhone, iPad and Mac. It is really good.
I can export directly into WordPress and/or Medium if I wanted to, I can export to PDF and Word formats as well, which makes my blogging workflow a lot smoother.

Having all your content stored on your iCloud account is a nice feature, so if for any reason iA Writer stops, I have all my content for any books or blog posts I’ve written stored as Markdown files in my iCloud account.

So in the world of writing application I think iA Writer is a hidden gem, it might not be getting the praise of Bear Notes or the large number of users as Evernote, it still a very good alternative.

Weeknotes #2

This week has been manly working on getting a first internal release of the client project. So as part of the internal team I’ve been working on a lot of small CSS changes to the Ionic application, giving it that extra polish to make it look as close to the original designs as possible.

What Went Well

The internal app is getting close to being released to real users, even though internal users it’s going to be good to get the app on devices and used by non-developers hands.

Book writing is still going, half way through and it’s clear that writing a book is a slog after a while. Being at the halfway point must be the toughest part. But it has been a great learning experience getting into the depths of Angular.

I also emailed Pete Bacon Darwin, who is a member of the Angular core team, after I heard an interview with him on the My Angular Story podcast. In the podcast he mentioned how working on open source has really helped him and opened a lot of doors in this career for him. So I thought I’d email him to say how I enjoyed the interview and if he had any advice on getting started with open source. And amazingly he emailed me back and said that there are so many ways to get involved, working on projects, writing documentation, answering others questions on Stack Overflow.

So after finishing the book I’ll be working on getting into a few open source projects.

What didn’t go well

Not much really, has been a good, but quiet week. I need to start working on using social media more in order to start promoting myself and business getting ready for my next project.

The business management of my freelance business needs to be something I need to focus on a bit more. Instead of going for one contract to the next, I want to build a lifestyle business instead of having a Limited company for contracting purposes.

As part of this I have been trying to be better organised with both work and personal life. So trying to work on that, but not there yet.

Things I’ve Read

I have read many articles this week, but I have been watching a few YouTube videos. One series in particular is the [Overpass](https://www.youtube.com/user/OverpassApps) Apps channel. Where the owner of Overpass Apps makes a daily video about running a mobile app development business.

Weeknotes #1

I’ve seen a few web developers starting to write up a weekly blog post on what they have been up to throughout the week. As I was enjoying reading these types of posts I thought I’d start writing a weekly update on what’s going on at CGCSoftware.

What Went Well

Work

Still working on a new Ionic 4 application, which hasn’t been released yet, but is getting close to a beta release. The Ionic v4 is really good, we’ve been using it since the beta release and had no issues with it.

Book Writing

Also still working on writing a book on Angular. Writing a book is a big task, and for my first book you really don’t realise how much work there is to creating a book, but it is a great way to dig deep into a subject.
I’m halfway through the first draft of the book, aiming for releasing it soon.

What didn’t go well

Freelance business growth

With working full-time on the Ionic application and writing the Angular book, there hasn’t been anytime to focus on running CGCSoftware.
As a freelancer I need to keep promoting my work in order for getting the next project after this Ionic project ends. This is a constant task you have for running a business.

Following GTD

I’m trying to follow the GTD methodology for both work and personal tasks. I do keep slipping in doing my weekly reviews, which I didn’t do last week.

Articles I’ve Read

Turning Design into Angular Components

Recently I had to take a design and create the Angular components for this design, while working through this problem it made me think about the thought process of how as Angular developers we turn designs into working applications.

When I first looked at the design, it’s a very simple layout of a page, which has a simple form, and a few controls at the bottom of the page. The first thing I thought of was how I would divide up the sections of the page into separate components. I’d create one component for the main page, one for the form, one for the controls at the bottom of the form, then off I went creating components using the CLI.

What I really should have done is looked at the page as a whole, how it works within the application and asked myself some questions before diving into building components.

The types of questions to ask before include:

What is the purpose of the page, what does it do?
What are the inputs and outputs of the page?
How will the possible components of the page pass data to other components?
Is there already a component I can reuse for this design?
What is the teams conventions on how pages should be built? Do they have a preferred way that components should share data?
Is this design actually finalised? If it changes is my approach flexible enough to cope, so if the design does change is there a large amount of work to change the page?

These questions are important, because we need to plan how we are going to build out the pages/views of the applications we build.

There can be times when we as developers are given a design to implement and it at first glance looks so complex that we are not sure where to start, but I think there are a few points we should remember in order to get started.

Iteration – the first attempt doesn’t have to be perfect, you can always iterate on the implementation
Feedback from others – getting feedback from others is important to get their perspective, but you still have to use you original ideas as starting point
There is no perfect way – there are many different ways to create a layout from a design, there are best practices (for efficiency and performance) but trying to hit that perfect approach first time is impossible

Angular is great, it gives us so much out of the box, but it is too easy to just start throwing out components using the Angular CLI, that this few minutes planning of how to turn a design into a set of components can be missed, which may lead to problems later.

2018 Review

Writing a yearly review is not something I normally do, but after speaking to some other independent developers, it seems like it is a good idea, just for yourself to see what you’ve accomplished throughout the year.

What went well in 2018

Well, had another year of solid work, with no long-term breaks between contracts.
I worked on 3 major projects, one Angular project and two Ionic mobile apps.
I actually had my best year financially, bringing in the most I have since I started working for myself, which is very satisfying.

I’ve also managed to work remotely for over half the year, which was one of the goals I had for 2018. I do enjoy working remotely, mainly because I don’t like commuting into London every day, the trains in the UK are rubbish. Unfortunately, I do think I’ll have to go back to London for my next contract, as they will probably want me to work onsite in their offices.

One of my other goals for 2018 was to get work directly, which I managed to do. I found my latest contract through a connection on Twitter, who knew someone looking for an Ionic developer. I contacted them and we arranged a telephone interview and that was that. It turned into a really fun 3-month contract, which is soon to end, but it’s great to see that getting work directly does work.

One of the other ideas I’ve had for 2018 was to start writing a book. I was thinking of ideas and planning to go down the self-publish route, using something like LeanPub, but through a couple of blog post I’ve written on Angular and Ionic I was contacted by Packt Publishing to write a book for them. I started this in October and still have plenty to do. This is one of my main goals for 2019 to get this book completed.

Throughout 2018 I’ve worked with in some great teams, learnt a lot for them all. Each new team I work with I learn new things, new ways of working, new approaches to how people develop.

A lot of these yearly reviews mention how many books they’ve read or how healthy they have been for 2018, but for me, these are just ongoing things. It’s interesting to see some of the books that people have been reading, but I’m not that concerned about how many I may or may not have read.

What didn’t go so well in 2018

I definitely got too caught up in spending too much on content marketing. In 2018 it seemed everyone was releasing a new course or a new book, which is great. I do believe that content marketing is a great way to promote yourself and the work you do. It is something that I plan to do more of myself in 2019, but I did find that I bought a few too many freelancing books or online courses. Many of them I still haven’t read or watched. So I’m planning on not doing that so much, instead just taking what I’ve learnt from the ones I have read or bought and applying that to my business.

I have also found that I did fall back into just contracting instead of running my own business a few times. What I mean by this is, I have been working on a few projects as a development resource, where I get paid to work daily, 9-5 as an extra developer on a project. This is fine, it can pay well and has kept me working for the last few years. But my aim is to change how I work so I can get work directly as a consultant instead of a development resource. Instead, clients will come to me because I can solve a problem they have. This will take time to set up, as I need to be able to show potential clients what problems I can solve for them, prove that I can do this and also have the business skills in place to win these new types of clients. This is a goal of mine for 2019.

So all in all 2018 was a good year for me and my business. Writing out these yearly reviews do help you take stock of what you have achieved, now I need to start planning out my goals for 2019.