Why Angular Developers Love NgRx

If you saw any of the recent talks from ngConf, you will probably have seen one on NgRx, it was a huge topic at the conference this year, but why are  Angular developers all talking about NgRx?

If you run a team of Angular developers they probably have already mentioned that they are looking to use NgRx in a project sometime soon, why? Well because NgRx solves one large problem, state management. What is state management, well it is a way of managing the state of an application between screens For example if you have a six-step process that needs to add to the application your team is building. In order to pass the information enter in step 1 to step 6, state management gives the developer a way of storing all the information added throughout each step, so it is accessible throughout the entire processes.

Before state management libraries like NgRx, developers use to have different approaches to store the state of the application, from storing all the information in local storage in the browser to cookies and even writing back to a temporary table in a database. With each project, there was probably another way of managing the state of the application.

This means when your developers are working on a project there wasn’t a common approach to the state management problem, but now thankfully due to libraries like NgRx, there is.

Another great feature of libraries like NgRx is the dev tools that come with the library. These ‘dev tools’ are features written into the library that take advantage of the wonderful features of a modern browser, by tapping into the tools the browser gives. Tools that allow the developer to really look into what is happening in the application as it runs. NgRx comes with a feature called store devtools this gives the developers the ability to add or amend the state of the application to see how the app handles different states. This is something that was usually done in the QA stage because it was easier to set up in QA. Now a developer can change the state through their browser to see how the app behaves. The better a developer can test how the app behaves at development time, the fewer bugs, the less time an app spend going through the QA process.

So to recap, Angular developers are loving NgRx at the moment, for two main reasons. One it gives them a standardised way to solve the problem of state management within an application, and two it helps provide fantastic tooling for developers to really look into how the application is working.

But NgRx isn’t the only state management library available, there is also NGXS which is another state management library for Angular. This one takes the approach to be more class-based, thanks to classes in TypeScript, than NgRx, which is more function based. Both tackle the same problem of state management, but NGXS has taken what people have learnt from using NgRx and implemented an approach that uses the great features of TypeScript.

If your team are looking at NgRx it is worth adding to your project, it will help your team with providing a common approach to one of the trickiest parts of building a modern web application.

The rise of hybrid and a question by a Mac developer

Recently the great Mac app developer Brent Simmons posted on Twitter “Sometimes it looks like there are people *rooting* for the demise of native Mac apps. Why?”   This started a long thread from various other Mac/iOS developers, all giving their opinion on why this is. Some said it was because of the UIKit which is used to layout Mac apps and how slow it is compared to using web technology others said it was a skills issue. Easier to find JS/Web developers than Mac developers.

What stood out to me about this question, is not the answers, I really don’t know if the APIs used in Mac development is slower than web development or not, what I found interesting is that one of the leading Mac developers was asking why more people are interested in using web technology than native to build Mac/iOS apps.

This is the first time I’ve seen from the other side (hybrid vs native) it’s interesting to see that now native developers are seeing this rise in hybrid apps, or apps built using web technology as a concern. It shows that the growth of developing apps using HTML/CSS/JS is getting more prevalent and Mac app developers are starting to notice this new trend growing.

Does this mean that hybrid app development has won this ‘war’ on native vs hybrid, well no, because there probably isn’t a war between the two sides? It just means now there is another viable option to native development, which a lot of developers are now taking advantage of. Whether it’s because of the latest performance gains in web technology is making building apps with web tech a good option or there are more web developers moving over into app development as well as web development, who knows. One this is that now apps can be developed either the native way or the web way is a good thing. It’ll lead to more opportunities for developers, and better apps for users.

Slack doesn’t replace a forum

Or how Mike Harington from the Ionic team deserves an award.

The more and more that Slack gets popular, the more it is being used as a way of a team who runs a product to communicate with the users of their framework. While initially, a Slack channel is a great way to speak to the team behind the framework, it can soon become unmanageable and just a lot of noise.
The old fashion forum is still the best way for users to get the help they need.

For example, I’ve been on the Ionic Worldwide slack channel for a few years now. Originally it was just a UK based slack channel, but soon it was opened up to the rest of the world. More and more channels within the group started to open. Channels to ask technical questions, ionic questions, channels for different countries. It soon became a massive community.

I was in the slack group today and I was going through the ‘Technical Questions’ channel. In here people can ask questions about apps or the deploying of apps using the new features of Ionic Pro. In here you’ll usually find Mike Harington from the Ionic team. He’s so helpful, always trying to give help and advice to people who post questions.

But going through the questions being asked and how people are using the channel I do feel sorry for Mike. He’s trying to help and he keeps getting people mentioning him directly with their questions, or screenshots of errors posted by people who expect an immediate answer from Mike (I’m sure that helping on the slack is his full-time job).

It’s this demand for an immediate answer is what is wrong with Slack as a way of support. Some developers hit issues, then take a screenshot of the error message and throw it on Slack and then demand an answer almost straight away. They need to spend a bit of time understanding the problem, what is the error message actually saying? Could stepping away from the computer screen for a few minutes help you see the cause of the problem?

A forum allows the developer to write a clear description of the problem (well hopefully) which sometimes by writing out a description of the problem actually helps clear up what the problem is. It also allows others to get involved, Slack is more of a conversational thing than a forum.

While Slack is great for teams working on the same project to communicate, I don’t think it should be used as a way for a community to get support for their own projects.

So do Mike Harington a favour, when you have an issue with your Ionic app, go to the forums, search to see if others have had the same problem and then write a clear explanation of the issue. Then sit back and wait for the fantastic Ionic community to help.

Contracting – Keeping your skills sharp

Being a contracting web developer, you need to keep on top of your skillset, they are what you use to keep employed. So ‘practising’ your skillset is part of the job, which you need to do regularly in order to keep these skills sharp.

But what does this mean to have your skills up to speed? Well, the web industry is so fast, it changes so quickly. New frameworks keep being released, new build tools are appearing all the time. GitHub has revolutionised the way people develop for the web, how they work together and how companies now work.

So if you want to make a decent career as a web developer it is important that one, you know about what is happening in the industry, what new technologies are being used, which ones are sticking around (remember Flex?) and two, you are proficient in your chosen skill set. What you say you know about you know about. The number of times I’ve seen highly paid contractors on a project who don’t really know what it takes to be a solid web application is frightening.

But how do you go about keeping your skills sharp? Well, there are a number of ways, first, if you’re a front-end developer, you can use your own website as a testbed for new ways of building sites. There is nothing wrong with rebuilding your own site over and over. Making it a case study for how you used this new tech. You can also make ‘fake’ example site, make a site for a fictional shop or business. Use sites like CodePen to create examples of how you would use a new technology or way of creating something in HTML/CSS.

If your thing is application development, things are a little trickier. You can’t build a full web application for yourself (unless you want to make a business form it) and host it somewhere as an example app. But thanks to the wonderful Github web app developers now have a place where we can send potential clients or recruiters to somewhere where they can view the quality of the code you write as a web app developer. This has made such a big difference to the web industry.

Of course, there is the whole Open Source movement that has sprung up over the last few years. This is a fantastic thing for new web developers. When I started there was nothing like GitHub, all we did was build small websites and send a list of URLs to recruiters as examples of work. Now developers are finding work through more direct routes, by people finding their open source work.

As a contracting web developer GitHub and open source give you a place where you can put your example web apps for others to look at when they want to check that you have the level of skills they require.

But along with all these new opportunities to show they work you can do and ways that you can practice your skills, there is still a need for focus.

With all the new technologies coming out there is fear of missing out that contracting web developers can get. When your livelihood is so closely tied to the skillset you have when a new technology is release or starts to get popular. There is a fear that this new tech will become more popular than the one you currently specialise in. For example, I work with Angular, which has been around now for a few years (if you include AngularJS). But now React is looking a very popular choice for front-end development. Does this mean as a contractor I should stop using Angular and move to using React? Well not necessarily, while React looks great, Angular for me is still a valid choice. Maybe not all the modern startups are using Angular, but more enterprise companies are. As long as there are support and development of the framework from Google I think it is still worth specialising in the one approach to web app development.

So as a contractor how can we both keep our skills up to date and at the same time make sure we know a technology well enough to be a good level contractor, who is going to build good software for their clients? Well, I think that by taking this focussed approach is the answer. There has been a lot of talk about having a niche as a freelancer. It’s spoken about in many freelancing books and podcasts. As contractors, I think we can also benefit from niching down into a certain skillset. If you can demonstrate that you know your chosen skillset well (though example works on GitHub or contributing to open source projects). You can keep your skill set sharp and relevant, but don’t forget to keep an eye on the industry because it can change fast. All it takes is a letter from a famous leader of a tech company and your chosen technology is killed off (remember Flex? I loved Flex)

Photo by Luca Bravo on Unsplash
Why Types? For JavaScript developers

I’ve been rewatching the Ultimate Angular TypeScript fundamentals course over the last few days. And it’s made me think about types, what benefit they bring.  Before I was a JavaScript developer I did a few years as a .Net developer, using C#. So the concept of types wasn’t completely new to me when I started working with Angular and TypeScript. I was used to the idea of interfaces, and classes. I’d actually spent many years learning OOP, first with ColdFusion and then with C#.

When going through the TypeScript course and with the work I’ve been doing with TypeScript, I was thinking of how I would explain to a JavaScript developer, someone who’s mainly been using jQuery why using Types and in particular TypeScript is a good thing.

As I see it there are two great reasons for Types, first by using types within your code, you are in a way ‘describing’ your code. For example, if you are creating a function that takes in two properties. Normally in JS you’d just past them in, all you’d know is their name, you don’t know ‘what’ they represent. Now with typescript, you can create object/types that describe what is being passed in. No more of this duck typing, where you are just throwing properties around not too sure what they actually are. So the first reason I think types are great is they give you this descriptive nature within your code. When you read TypeScript you know what the types of the properties being passed into a function are.

So as well as this descriptive nature that types give you, the other reason I think Types are such a great thing for JS developers is, by describing your code and creating types you can write code that the JavaScript engine can use to make extremely fast and optimised code. Code that can ‘tell’ the JavaScript engine what things (properties etc) are. The more information you can give the JS engine the better it’ll run.

Now, this isn’t just something I believe, it’s based on a talk I watched on how JavaScript engines actually work. There is a talk by Franziska Hinkelmann at JSConf, where she explains how the V8 JavaScript engine works. In this talk, Franziska shows that by using types to tell the JS engine all about your code the JS engine will run faster, be more optimised. But don’t take my word for it watch Franziska fantastic talk

Photo by Artem Sapegin on Unsplash
Attention: Angular Cli Stories

 

The Angular CLI is awesome, using it now makes working Angular a real joy. If you go back to version 1, without the CLI, it’s so hard to get back into the grove of not using it.
What I love about a CLI is how it has been designed to help you as a developer gets on doing your job. Unlike some other technologies, like .Net or Java the Angular Cli helps the developer without getting in your way.
We all know that the CLI helps you create components, services, pipes, modules and other classes we use in Angular. But one of the lesser known features of the CLI is the Stories that are in the GitHub repo. The great thing about these Stories is, they are small reminders for common things you may need to do when working with Angular, but you usually forget the specifics. So instead of trailing through Stack Overflow for an hour looking how to set up Angular Flex with CLI, you have the stories to help.
These stories are written by the Angular CLI team (though I think they can be added to by anyone who puts in a PR), showing you how you can do more with the CLI. For example how you add 3rd party libraries to your project or how to set you CSS processor of choice so every component you create is using that CSS processor.
There is also another story on how to add Bootstrap to a Cli built project. In the work, I do I use Bootstrap a lot for the UI of the web applications I’m developing. So this story is a real help. I can set up any new projects, add Bootstrap, and use Sass. All with a few changes to the .angular-cli.json file.
I think these angular stories are great. For me, they have proved to be a real help when I need a quick reminder of how to do something with the CLI.
The Angular 2018 Developer Survey

Recently Stephen Fluin announced a developer survey for Angular. It’s a pretty short survey, but worth taking part in.

The main question that the survey is asking is what order of importance do developers see these things

  • Tooling
  • Documentation
  • Ease of Updates
  • New Features
  • Initial Load Performance
  • Runtime Performance

I personally think that the initial load and runtime performance are the top two most important features of Angular. The reason for this is clients who want someone to develop an app for them, all they are concerned with is that the application starts quickly and runs fast, which Angular does, but I think the Angular team should focus on getting the load performance of Angular as fast as it can be.

Another question that the survey asks is ‘How else should we improve Angular for you?’. For this, I put that I think the Angular team should focus on showing developers best practices. Now we know the basics Angular now we need to know how to build really good quality, fast applications.

One thing that did come out of AngularConnect this year, was that the Angular team are now focusing on this skill gap. With more talks on advanced concepts of Angular, like pre-rendering, PWAs and performance gains. It’s going to be interesting to see what else the team do over the next few months. Hopefully the feedback on this survey will be published along with what the Angular team plan to do based on the results of the survey.

Why Contracting?
I was asked the other day ‘why I was a contractor’. For me contracting is perfect in many ways. It gives me a good income, as the main earner of a family, this is really important. I also get to work with a variety of clients including football clubs, startups and councils.
I started contracting in 2012, so next year will be my 6th year. This is my longest job to date and I can’t see myself going back to permanent employment (unless Nrwl.io come calling).
Getting started as a contractor is relatively easy. All you need is a Limited Company (though you could be a Sole Trader, a Ltd company is better). An accountant or some type of online accounting software and a job.
Well, this sounds simple, but it’s not.
When I started getting my Limited company involved completing an online form, making a small payment and that was it.
One of the things I did need to consider was a company name. You need something that matches with the services you’re providing, with some flexibility in case you try something new. You don’t want to be called WideWeb Solutions if after a year or two you just make iOS apps.
I wanted something that covered me for web development, but I have always been interested in mobile development. So I went for something that had the word software (either web or mobile) plus the initials of my wife and children. That’s how I came up with CGCSoftware.
So I had my company name and limited company setup, next getting some work.
The reason that I started contracting, I was working for a startup in London as a Flash developer (good times). It was all going well then the company decided to move to America, and get a new development manager. So we had this new manager and half the team went to America, but still, the work was ok.
But soon the new development manager started letting people go, and get in new people that he wanted. Well, eventually it came to my time to go for a quick chat at lunchtime.
So that was the end of that, can’t say I was too bothered as I wasn’t getting on too well with the new members of staff. It did remind me that I don’t want to work for someone ever again. (If you work for yourself, it’s hard to fire yourself).
This is why I started contracting. I wanted to be in charge of my career, and have that flexibility of working on different projects with the technologies I wanted.
AngularConnect a review

Recently I went to AngularConnect, this was my third time and probably my last (well for a while). The main problem with the conference this year was it just seemed like it was going through the motions. It seemed that there was nothing new and exciting in this years conference, maybe I’ve been to too many, maybe I was expecting more from the conference.

Last years conference was great. The new version of Angular was almost released, there was loads of great talks about the new and exciting version of Angular. This year we had version 5, with service workers and server side rendering. Both great features but not the biggest features ever.

I also found that some of the most interesting talks, one about NgRx and strategies in Server Side Rendering in Angular, both great talks, but they were only given 25 mins. These were just not long enough. I wanted to learn how to write better Angular apps, learn from the industry leaders on how to create great Angular apps.

Unfortunately I felt that I didn’t learn enough from the investment I made in going to the conference. These great developers come over, but weren’t given enough time to go into depth about Angular. There were some other talks that didn’t need to be there, they just seemed like fillers.

AngularConnect does offer a lot of other things, yoga sessions, meditation sessions, both great things, but I’ve never taken advantage of them. (I can go yoga classes outside of the conference). They also have office hours, what ever they are, and panels. But I’m not interested in those.

For me a conference should have talks from the best developers, great food and a place to sit down, eat and discuss the topics discussed in the conference.

Maybe I’ve been to too many AngularConnect in a row. A break from it might be in order. Next year I’ll watch the talks when they are online.

There’s a JS lib for that

Recently I was creating an app using Angular Material all was going well until I tried to use Flexbox to layout the app.

The app was a demo Employee Manager app, that lists all the employees on the right side of the screen and the edit form on the left side.

I wanted to make the app fully responsive. So I decided to look into using Flexbox. I’ve used Flexbox in an existing app once before, and from what I saw I was really impressed. So I decided that I’d try to implement a Flexbox layout from scratch.

It was all going along well when I tried to implement a layout change so when the app was displayed on mobile/tablet. The list of employees was on top of the edit form. But as this was new to me I thought I’d do some research using Google to see if anyone had written about how they implemented Material and Flexbox.

So in Google, I typed ‘Angular Material Flexbox’ (not Google, you never type Google into Google. As we all know it will destroy the internet if you do that). The results I got for my ‘Angular Material Flexbox’ search was really interesting.

Instead of seeing some articles on how you can use Flexbox within a Material app, instead, it was full of links to GitHub each with a library that you can add to your project that’ll give you Flexbox support along with Angular Material.

Now I’m a fan of GitHub and what it has done for modern web development. But now it seems if you are trying to implement a feature or trying to solve a problem within a project, there are just JS libraries that you can ‘just add’ to your project that’ll fix your problem.

There are no longer articles where people show how they have solved a problem, it’s all pull request, get this library and add it to your project and a few lines of code and the problem is solved.

What happened to articles showing you how you can use what the web provides to solve the problem.