Apr 29 2019
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.

Stephen Adams 0 Comments
Mar 4 2019
Shared Module vs Module Per Component
Photo by Kaleidico on Unsplash

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.

Stephen Adams 0 Comments
Feb 27 2019
Using iA Writer for blog content
Photo by rawpixel on Unsplash

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.

Stephen Adams 0 Comments
Feb 23 2019
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.

Stephen Adams 0 Comments
Feb 19 2019
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

Stephen Adams 0 Comments
Jan 11 2019
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.

  1. Iteration – the first attempt doesn’t have to be perfect, you can always iterate on the implementation
  2. 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
  3. 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.

Stephen Adams 0 Comments
Jan 5 2019
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.

Stephen Adams 0 Comments
Oct 24 2018
What companies want from an Ionic developer

I’ve recently started a new Ionic project, where we are already using Ionic v4. Through chatting with the team, I’ve realised that being an Ionic developer is a specialist role and by working as a developer in such a specialist role there is more to it than being able to code.

When a company decides that they are going to be developing their new mobile project in Ionic, they are making an investment in a technology that is not yet the norm for building mobile apps. They have spent the time to look into alternative ways for creating their app, they need to be sure that the road they are going down will mean that the app being built can fulfil all the business needs that they have for the app.

With native app development, the path has been proven. There are tons of examples of business apps developed in Swift or Java that show whatever the company’s needs are a native app can be built to meet those needs. But as we know as a hybrid developer, there are a few drawbacks from building native apps. There is cost, there is timescales and availability of development skills. All things to think about when deciding what to use to get their app built.

So when a business has decided that they want their app built using Ionic as the ‘Ionic developer’ who is working on the project you are seen as the expert. Not only should you be able to develop an app with Ionic, but you need to be able to guide the business through the process of having building a hybrid app.

The sort of advice you will need to help the business with could include, how will the app perform in relation to other apps they may have seen? You may have to convince the business that the app is fast, or appears fast to the user. How will you add features that show the app is fast? You’ll have to suggest ways like having loaders when data is being retrieved, showing update messages when a form is being submitted. Do you know how to partially load data into the view, so the user sees something as soon as data has been received.
You have to also show them how an Ionic app will be deployed. What are the various options? Are they going through the App Store or are they looking to use the Ionic Pro tools, do you know what the Pro Tools do? If they are using them you’ll have to help with the deployment stage.

Security is an important part of any business app, so you’ll have to know about the different approaches there are to securing an Ionic app. You’ll have to be able to advise on what Cordova plugins could be used to store data securely. You may also need to what other options they could use to secure an app. Is biometrics an option, could they use the native finger print reader within the app? How would you suggest API tokens are stored and passed with every API call?

If the business has an existing design style, how will that work within a mobile app? Does it work across all platforms and still look and feel as a native app should for the user? You will have to give the business advice on how the app will look in order to work for the user, without trying to tell a professional designer, who knows more than you do, how to design.

There are a lot of questions that a business will have when going through the process of having an Ionic app developed. As the Ionic developer you need to be able to guide the business through this process. It’s not just a case of just sitting behind a monitor with you headphones on writing Ionic code, you need to actively work with the business in all aspects of building the app.

But there is more we can do as Ionic developers. We can write blog posts on how we solved these types of questions. There are many brilliant blog posts on how to create an app with Ionic, but there aren’t many about how an Ionic developer has used the framework and the tools Ionic provides to solve a business need.

I’d like to see more blog posts on how security was built into an app, how data is stored securely in the app. What methods someone used to shows that the app is performing really fast, how was this monitored? What ways was the UI setup to show to the user the app was performing well for them?

There are many examples of posts about the setting up and building of an app and this will continue now we have Ionic 4 coming out with its support for multiple frameworks. I’m in the process of writing a book about Angular and Ionic, where I go through the basics of creating an Ionic app. This is all great for new developers coming to Ionic, the more we have the better.
But I think we also now need to show how we as Ionic developers are using what the framework provides to show businesses and enterprise level companies how Ionic can be a viable option for their next business application.

As Ionic developers we need to be this guide for businesses as well as developers. With Ionic 4 coming soon its time we stop telling each other how great Ionic is and now start telling businesses how great an option Ionic is for their next app.

Stephen Adams 0 Comments
Sep 6 2018
Upgrading Your Approach to Angular from AngularJS

When upgrading an AngularJS app to Angular, there are a couple of routes you can take. There’s ngUpgrade, which is the official migration path set out in the Angular docs. There is also ngMigration, a fantastic tool that reviews your existing AngularJS codebase and lists the actions you need to take in order to migrate to Angular. Both ways show you what to do with your codebase in order to get from AngularJS to Angular, but the trickiest part is for developers new to Angular, who may have been working on one large AngularJS application for the last few years and have had no exposure to Angular. Is for them to understand the new approach Angular is taking.

In AngularJS you had scope, controllers, directives and services/factories. In v1.6 components were brought in (though they are really just directives with controllers built on). Now in Angular, you have components, modules, providers, pipes, classes, interfaces (though both features of TypeScript). You have type safety on top of all this.

So for the legacy AngularJS developer, there is a whole mindset shift that needs to happen besides just upgrading the codebase.

They need to know what effect having everything as a component has on the structure of an application. What is the relationship between parent/child components, how is data transferred between parent/child components? How does the module system need to be used? A legacy developer may just add all their components to the single module, creating one large monolithic module. Instead of taking advantage of the module system to break down the application by having feature modules. They need to know about the by feature approach to the folder structure of an application. They need to know about where the common features will go, is there a core folder that contains all the components/providers that aren’t part of a feature?

Another area that legacy AngularJS developers can slip up on is using TypeScript and embracing the type system. It could be far to easy to just set everything with a type of any and not using the benefits that the type system gives you. Like better tooling, picking up spelling errors before running the app, more efficient code that the TypeScript compiler can optimise to make the application run faster.

The advice I’d give if upgrading to Angular

  • Read the ngUpgrade guide
  • Read the Angular style guide in order to understand the approach to writing an Angular app
  • Understand the module system, how to use it to divide up your app
  • Understand the relationship between parent/child components
  • Learn at least the basics of TypeScript and creating Types

You can’t go from AngularJS to Angular and expect to use the same approach you had. Angular is so different from AngularJS, that it is not just a case of changing a few JavaScript files to TypeScript. It’s a complete shift in approach to not only writing Angular but developing front-end applications altogether.

Stephen Adams 0 Comments
Sep 3 2018
This week in Angular
Photo by Mr Cup / Fabien Barral on Unsplash

Here is a list of news stories I’ve found interesting from around the world for the Angular platform.

Apps That Work Natively on the Web and Mobile

From the Angular official blog, we have a post about NativeScript and how you can now, thanks to Schematics in the Angular Cli, share code between desktop and mobile apps.

One codebase for both desktop and mobile, something that is very powerful. Max Lynch from the Ionic team did Tweet at the time that Ionic has been allowing developers to share code between desktop and mobile for a long time.

2 New Tools to help with AngularJS to Angular Migrations

Another story from the official Angular Blog, on two tools that will help to make upgrading from AngularJS to Angular. One tool is a CLI tool called ngMigration. This tool will analyse your application and gives a list of recommended changes you need to make in order to prepare for migration to Angular. This is extremely clever and gives anyone a great starting point when you want to migrate to Angular. 

The second tool, is a forum where tips and tricks can be shared on how to migrate to Angular, and a place to ask for help during a migration.

Nrwl Nx 6.3: Faster Testing with Jest

The Nrwl team has just released a new update to NX, now at version 6.3. This release now has support for Jest, the test runner from Facebook. Now with this latest release Jest can be used as the test runner instead of Karma. According to their blog post, the main reason for using Jest over Karma is performance. Jest is fast, but not only that Jest has better reporting, uses Node so no need to link to the browser and Jest has excellent Mocking.

I’ve not used NX as yet, but I can see there is a really need for large scale Angular applications to have fast running tests. With this new release of NX, Nrwl are building an excellent tool for enterprise Angular teams.

RxJs Observables versus Subject

Continuing his brilliant articles on RxJs, Cory Ryan compares the different types of Observables that RxJs provides. Cory has written a number of great articles on RxJs, as well as articles on Tree Shaking in Angular, classes in TypeScript. His blog is a great resource for any Angular developer.

Angular Patterns 3: flexible and scaleable design of complex page

In this article, Adriano di Lauro goes through a set of patterns he has developed over his time developing Angular applications. There are many articles about how to use the latest features of a framework, or how to use a certain library. So it’s good to read, for a change, an article about how someone approaches a problem within Angular. Adriano also has articles on how he organises modules and what considerations to have when writing reusable components.

There is a lot happening within the Angular eco-system, but these posts I found really interesting.

Stephen Adams 0 Comments