Andy Crouch - Code, Technology & Obfuscation ...

Ngrok

Photo: Unsplash - Nicole Y-C

I love a great simple utility and this week I found one that is genuinely useful, ngrok.

ngrok provides a simple way to forward your localhost server content through any NAT or a firewall. This means that you can fire up a demo of your latest website and share a URL with your client or boss and have them view it. I found it while developing a chatbot for Slack. What I loved about the site was that I was signed up and using the app in less than 4 minutes!

(For clarity I have no association or involvement in ngrok.)

First up head over to ngrok.com and sign up for a free account. Once you are in they have a simple UI that guides you through a 4 step process to download the app and get going.

I installed the app via my package manager. Step 1 & 2 provides details for Mac and Windows users and Linux users that are not lucky enough to have a package in their repositories. Once you have downloaded and installed the app you can move to step 3.

In step 3, you need to provide your account token which they provide a shell snippet to copy and paste into a terminal. Step 4 is run the command with some examples of how to serve different content. Serving your localhost webserver (on port 80) is as easy as

$ ngrok http 80

This results in a server running in the terminal which provides the temporary URL’s to reach your localhost.

They even provide a web based interface you can track and monitor requests. This is accessible at http://localhost:4040.

So simple and useful.

What simple but killer apps do you use to make life easy? Let me know via twitter or email.

Thoughts On Monoliths

Photo: Unsplash - Michael Schaffler

There was an interesting post on Microservices vs Monoliths this past week. You can read it here. This made me think a lot about why and what should drive your architectural choices.

Microservices have gained a lot of attention since 2013. The architectural approach composes complex applications by combining individual applications. The smaller applications (services) communicate via standard protocols such as http. They are stateless. These applications generally only relate to backend and data services. Early pioneers are listed as Netflix and Amazon.

Monolithic applications describe a typical n tier application. These bundle the state management, user interface and data access into a logical single application. The list of monolithic applications is endless and it is a very established approach.

There has been a lot written about Microservices. A lot of “we benefited in this way by migrating to Microservices” articles. A lot of new projects writing about going with services. These articles can sometimes be light on reasoning and wider business context. Every company and every project is unique. While reading about other projects is useful and educational, not taking the wider context into account could lead to bad decisions being made.

There are many questions that need to be answered when designing an application and it’s architecture. First, what are the problems you need to solve? What kind of project are you working on? What are the business goals? Are you starting out on a new project, taking over an MVP or refactoring a large, existing codebase? What is your budget? What are the available resources and what is the skill set? Are you going to have to use a particular stack or language? These are all standard inputs to your architectural decisions.

I have only ever concluded that a microservice approach would be beneficial once. In all other circumstances, I have to start or continue with a monolith. Why in that one instance did I feel that a service-based approach would be wise? The reasons included:

  • The existing code base comprised less than five main features. Each feature had a clear boundary and could be thought of as a distinct application.
  • The company goals were to replicate the features across global markets. Each market would have a different implementation caused by regulatory and supplier requirements.
  • The codebase would move to a CI/CD process to simplify the deployment process and improve testing. Each service would want to be independently deployable.
  • The longer-term plan for the company was to build a marketplace platform. This would provide common functionality on which any reverse auction-style marketplace could be built.
  • The plan to evolve the development team included having significant resources split into core and autonomous feature teams.

This was for a company that was past the initial cycle of build and testing features. They were 3 years in and already had a good market fit. They secured investment to drive forward and evolve into a technology-focused business. Unfortunately, they opted to invest in offline resources rather than the technical team and the project was doomed for failure. Anyway, my point is that there was a clear set of requirements and goals on that project that meant that a service-based approach seemed like a sensible option.

If you are starting a new project then you absolutely do not want to go with services. You will not understand your customer’s or the business well enough to design your services right first time. You almost certainly will not have the time to integrate test them and because of that your deployment and monitoring will be horrific to start with. These last two points are pretty key on the whole. Once you break your code down to lots (hundreds) of services then you need to not only test them but observe them in your environments. Instead of keeping one application online you have to manage to keep a lot of interrelated applications online. It’s not beyond impossible but it’s not quite as Develop friendly as everyone tells you.

If you are starting a project and need a web app and a mobile app then it is fine to have a single API app running them. You can structure that API as you might your services and you should absolutely be following clean code styles. This will mean that when you come to split the logic out into services (when your company has raised £10m and has a million users) that it is an easy task. Following that approach will make your project easier to develop anyway.

If you are looking to refactor an application that has become an unmanageable ball of bad code then Microservices is absolutely not the right approach for your team to consider. You should first review how you have ended up with such a bad codebase. If you do not fix the root issues then you will replicate them across multiple services. You need to refactor your codebase based on clean code principles and instil best practices and code reviews on your team.

This has turned into a bit of a brain dump. I started out really wanting to agree with the article I mention. I hope this has come across. Its OK to design your codebase as fits your skills, budget and company goals. Architect solutions to your problems and not those of much bigger, wealthier competitors. It’s always good to see what others are doing but building your project right and fast is what will make your company a success.

I’d love to hear your thoughts on the Monolith vs Services debate so please contact me via twitter or email.

Debugging Rust

Photo: Unsplash - David Boca

Lately, I have been reading up and learning the Rust programming language. This was caused by me taking on some JavaScript backend projects and thinking “there has to be a better way”. Don’t go hating on me yet JavaScript developers, wait for the post on my JavaScript thoughts. Stay tuned.

Rust has been around for over ten years and is a multi-paradigm language developed at Mozilla. Its primary focus is memory safety and concurrency and syntax that should be familiar to anyone that has worked with the C family of languages. I have read the odd thing about Rust over the years but what made me take notice was finding techempower.com and learning about the Actix Web framework based on Rust. So I have been making an effort to learn more about the language and development workflow. I have a long way to go but have enjoyed getting familiar with Rust. I may even write a short series on it late in the year.

One of the first things that I do when learning a new language is set up a development environment and work out how to debug code. I use either Vim or VS Code and for Rust VS Code was ideal given I am time poor at the moment.

To get Rust setup I:

  • Followed the excellent instructions found at the Rust install page. This gives a good overview of rustup which is an equivalent to nvm or pyenv.

  • Installed the Rust(Rls) extension for VS Code. I did try the Rust Analyzer extension but there is a bug at present which means that the Vim keybindings no longer work.

  • Install the CodeLLDB extension which provides a native debugger.

  • Open your user settings and under the LLDB settings set the “Lldb: Executable” setting to rust-lldb.

  • With a Rust project open, hit F5 and VS Code will tell you it has found a Cargo.toml file in the workspace and then ask if you would like it to create a launch config. Say yes and set your breakpoints.

At this stage, you have a working development environment which will allow you to start learning more about Rust.

If you have recommended links on developing Rust then please share them with me via twitter or email.

Some Thoughts On Culture

Photo: Unsplash - Austin Distel

Culture is a key element in any business. It is a subject that has been increasingly written about and studied and for good reason as 82% of responses to a 2016 Global Survey felt culture can provide a competitive advantage. They also reported that they did not fully understand culture and they found it hard to cultivate, manage and measure.

It is a topic I have pondered for a long time. Having built remote teams for many years, getting the team culture right took effort. Every team in every organisation has its own skill set which differentiates them from others. This means that one team’s culture can differ from that to another team in the same company. That is fine but all teams and employees should be governed and led by the top-level company culture.

Company culture has to be developed from early in its existence. The culture should be set directly by the founder(s) and this means it can be a result of previous roles and the experiences they have had. I find it interesting that some of the best company culture’s I have read about or worked in are at companies that have founders that are straight out of education. I have also seen cultures develop that are parallel to the founder’s previous company culture. They don’t know how to develop an individual culture for their business and just repeat what they know. This I find strange as these founders have usually started a company to break away and change a way of working or to disrupt an industry.

Like a lot of things when you start a company you need to learn about culture and how to create one. It’s no different to learning about accounting, sales and marketing or customer management. You should be asking people in your network and read up on the subject. There are a lot of articles online and they all offer similar advice for getting building your culture. Define your mission, and the values your company will be governed by. These are key. You will want to apply the values as you start to work with clients and especially when you start to hire. You need to track and nurture your culture. It is not a document you write when you found the business and file. You need to make time to review it and monitor how effective it is. You also need to be prepared to evolve it as your company grows. If you can afford to then get a coach to help you. Learn from people that have been there and done it. Be humble. Something I have noticed is how easy it is to track culture just by talking to employees and taking time to listen. If you find you need to work on your culture because you feel it is not working or people are feeding back that they are not happy then look at the root causes and adapt. Going out and buying a monitoring app or employee survey tool is not fixing the issue. Although, these tools do have their uses.

It’s strange how you can get a feel about a company from the way the employees talk and carry out their work. A good friend of mine, who does not work in tech, was pulled up by his manager recently. He was told that while he was doing his job really well he was making the rest of the team look bad. They were not completing all their tasks and customer were complaining about them and the service they were giving. The manager told my friend that he didn’t want to replace the rest of the team and that they were probably doing the best that they could. As you can imagine this didn’t make my friend feel very good at all. It also went against the published values of the company (it’s a gym). This is one of many examples where although a company has a set of values, they are not enforced and are meaningless to both employees and customers.

All this thinking about culture was prompted by me buying Ben Horowitz’s new book “What You Do Is Who You Are”. I haven’t even started it yet but the title stands on its own for employees, founders and companies. I will come back and write more on this once I have read the book. I’d love to hear about your thoughts on culture and the company cultures you have experienced. Please contact me via twitter or email.

Automate The Small Stuff

Photo: Unsplash - Franck V

Sometimes as part of your regular development process, you have tasks that you repeat a lot. Or you have long commands or groups of commands to run that need a lot of repeated typing. When working with teams I’m often surprised when they do not live by the mantra of “do it once manually, do it twice, automate it”.

Modern development environments need the use and knowledge of the command line (cli). This means it is easy to automate every repeatable task imaginable. When should you automate a task? When:

  • You do it more than twice.
  • You do it infrequently.
  • It requires multiple steps.
  • When it is easy to get wrong and where the result is not easily reverted.

As an example, I am currently working on a project that is using a lot of uuid’s. For testing and seeding purposes I am generating and pasting a lot of these. So I created the following call:

echo $(cat /proc/sys/kernel/random/uuid) | xclip -selection clipboard

This command generates a uuid and adds it to the clipboard. This means I can flick between my terminal and code and create and paste in a new uuid with only a couple of keystrokes. It means I do not have to use a browser-based generator or my mouse or anything else that takes me out of my flow.

(As an aside there are a variety of packages on Linux that will generate a uuid such as uuidgen. The above approach requires no extra packages. Instead, it uses the kernel’s random number generator.)

For short snippets such as the above, I create functions that I can call in my shell. Often in projects, there is a possibility to automate a project-specific task. In these instances, I always create a shell script. The script is checked in with the project so other team members can utilise them. I find it can be helpful to use action names with these scripts such as “hydrate-database”. I wouldn’t use a technology-specific term so that the implementation doesn’t matter. As an example, on my project, I have created create-migration.sh and create-seed.sh. Although I have Knex installed globally, there is currently a bug which means that I have to use the project-specific version to generate files. So now I call:

$ ./create-migration.sh file_name

Instead of

$ ./node-modules/knex/.bin/knex migrate:make file_name

It may seem trivial but as your project grows it makes things easier. It also means that you don’t have to think too hard about tasks or perform repeated tasks that slow you down or break your concentration.

I’d love to hear about the ways in which you automate the small stuff so please contact me via twitter or email.