DEV Community: Chris Gregori

10 tips for new Elixir developers

Chris Gregori — Tue, 12 Jul 2022 10:43:19 +0000

Elixirs popularity has exploded in the last year - and for good reason!

Stack Overflows 2022 Developer Survey lists Phoenix as the most most loved Web framework and Elixir is now the sixth highest paid language 👀 - it might be time to have a look if you haven't already.

What is Elixir?

It's a dynamic, functional programming language with an emphasis on fault tolerance, scalability, and developer experience. It's gorgeous.

I'm fortunate enough to write Elixir daily (when I'm not in meetings) as part of my job as the core tech stack and have done so for over 3 years. As such I've encountered some of the gotchas you're likely to experience if you're new to the language and amassed a bank of helpful tips to ensure you're really getting the most out of the language.

1. Get used to pattern matching

In Elixir, the = operator is actually the match operator. You can use it to assign variables just as you might expect but its hidden power comes from its ability to destructure complex data types.

A quick example from the official language guide:

iex> {a, b, c} = {:hello, "world", 42}
{:hello, "world", 42}
iex> a
:hello
iex> b
"world"

Now this is all well and good but some of the real fun comes from pattern matching on function heads to:

Replace pesky if statements

defp greet(%{first_name: first_name} = user), do: "Greetings, #{first_name}!"
defp greet(_), do: "Greetings, stranger!"

Handle different outcomes in your code declaritively

defp split_traffic(%{age: users_age}) when is_even(users_age), do: # redirect to path A
defp split_traffic(%{age: users_age}) when is_odd(users_age), do: # redirect to path B

2. Append to a list the correct way

Lists in Elixir are effectively linked lists - they are internally represented in pairs containing the head and the tail of a list.

Meaning both of these approaches are valid:

list = [1 | [2 | [3 | []]]]
# [1, 2, 3]
list = [1,2,3]
# [1, 2, 3]

Because of their linked list nature, prepending to a list is always faster (as it's constant time vs having to internally traverse each list til the end and append - linear time).

You can add to them by concatenating lists together using Kernal.++/2 or you can use | to do the same thing faster.

Have a look at the example below (which is using the erlang timer module to time the function call).

iex(19)> :timer.tc(fn -> [1,2,3 | 4] end)
{6, [1, 2, 3 | 4]}
iex(20)> :timer.tc(fn -> [1,2,3 | 4] end)
{6, [1, 2, 3 | 4]}
iex(21)> :timer.tc(fn -> [1,2,3 | 4] end)
{6, [1, 2, 3 | 4]}
iex(22)> :timer.tc(fn -> [1,2,3] ++ [4] end)
{13, [1, 2, 3, 4]}
iex(23)> :timer.tc(fn -> [1,2,3] ++ [4] end)
{14, [1, 2, 3, 4]}
iex(24)> :timer.tc(fn -> [1,2,3] ++ [4] end)
{12, [1, 2, 3, 4]}

3. Finding N slowest tests in mix application

You'll be writing tests in your Elixir code (right? 🙏🏼), and once your application grows to a large size you may find your tests take a long time to execute (not too long, Elixir's pretty speedy).

You can narrow the culprits down with the following:
mix test --slowest N # prints timing information for the N slowest tests

4. Read the docs (especially Enum)

This might be an obvious one to many of you but you'd be surprised how often people don't RTFM. I actually discovered that last tip by reading the official docs 🤯 - Elixir's documentation and standard libraries are stellar.

I can guarentee that you'll be using the Enum, Map, List, and Kernal modules often - get used to reading their documentation.

You'll find examples like:

Enum.chunk_while/2 for chunking lists when certain conditions are met
Enum.into/2 for converting enumerables into collectables (lists into maps)
Map.put_new_lazy/3 for putting the result of a function into a key if it's not already there

Any time you think there's a more functional way to do something - there probably is, get reading, chances are the standard librarys got you.

This leads me on to my next point quite nicely...

5. Embrace Doctests

It's impossible to talk about how good Elixirs documentation is without talking about the magic of doctests. I've spoken about these before in my Elixirs Hidden Potions post (which you should also read) but I have to re-iterate just how powerful this can be.

Doctests let you annotate your functions with example usage (including expected output) and have them run as part of your test suite.

Yes, they're as amazing as they sounds.

Taken from the official getting started guide:

defmodule KVServer.Command do
  @doc ~S"""
  Parses the given `line` into a command.

  ## Examples

      iex> KVServer.Command.parse("CREATE shopping\r\n")
      {:ok, {:create, "shopping"}}

  """
  def parse(_line) do
    :not_implemented
  end
end

# Running the tests...

1) test doc at KVServer.Command.parse/1 (1) (KVServer.CommandTest)
     test/kv_server/command_test.exs:3
     Doctest failed
     code: KVServer.Command.parse "CREATE shopping\r\n" === {:ok, {:create, "shopping"}}
     lhs:  :not_implemented
     stacktrace:
       lib/kv_server/command.ex:7: KVServer.Command (module)

6. Atoms are not garbage collected

Be careful about converting user supplied parameters and converting them into atoms. Atoms are meant to be used as named constants - do not take parameters from your users and convert them into atoms.

Atoms are not garbage collected.

The reason for this is because Atoms are represented as integers internally - when Beam (the Erlang VM) sees an atom for the first time, it inserts it into the atom table.

Don't worry - when your code is littered with :ok atoms from tuples they're all referencing the same atom (the one referenced from your atom table).

If you really, for some reason, need to convert user generated data into atoms - reach for String.to_existing_atom/1.

Fun fact: the default maximum number of atoms is 1048576.

7. Embrace the small, but mighty community

Elixir isn't the biggest language (yet 😏) but it has one of the most helpful communities I've ever stumbled across.

Slack

I'm consistently being assisted by the creators of platforms, libraries, the language itself all on the Elixir Slack channel. Get involved and do your part answering questions you can help with as they pop up.

Twitter

Some people hate Twitter - I maintain that it's a treasure trove of great information if you're willing to curate your feed and block out the noise.

Some of my favourite Elixir twitter accounts to follow include:

If I've left you out send me a message on Twitter and I'll add you to the list!

8. Add labels to your IO.inspect/2 calls

Really you should be using Pry for debugging your applications (see more in my other article here), but sometimes you just need a quick and dirty way to print out and that's where IO.inspect comes in.

The thing is you may get lost in the sea of terminal print out when you're trying to debug lots of data that looks very similar.

Consider the following pseudo-code:

customer_orders
|> Enum.map(&validate_purchases/1)
|> IO.inspect()
|> Enum.map(&exclude_late_orders/1)
|> IO.inspect()
|> Enum.map(&email_customers/1)

If your customer_orders represented a complicated schema with lots of nested data (and many of them) you'd struggle to decipher which are which in your printed logs after transformation - a simple option being passed to our IO.inspect/2 calls makes this inspection a hell of a lot more legible:

customer_orders
|> Enum.map(&validate_purchases/1)
|> IO.inspect(label: "Validated purchases")
|> Enum.map(&exclude_late_orders/1)
|> IO.inspect(label: "On-time orders")
|> Enum.map(&email_customers/1)

9. Try and keep your functions small and composable

This is a tip that applies to most software disciplines also.

When I first stumbled across functional programming, one thing that took some getting used to was creating lots of little functions. I used to write a lot of React - and thus a fair amount of boilerplate - which meant that I was used to large render functions.

In Elixir, and all functional programming, try and create lots of small function calls to describe your code. There are plenty of benefits:

It's more declarative so it's easier to read and reason about
It's easier to refactor later on down the line
It's easier to test
It helps enforces the DRY principle
If you structure your code nicely you'll find that you'll re-use plenty of functions often which inadvertently leads to better code structure. Better code structure also leads less circular dependency referencing which leads to faster compile times (but this is a topic for another blog post - let me know if you'd like to hear more!)

10. Learn about Macros but be cautious

Macros are powerful - with great power comes great ~responsibility~ chance of doing something invisible and horrendous to your codebase. Even the official language docs tell you to use them responsibly.

You can use macros to extend module behaviour by adding functionality through wrappers - think along the lines of always logging when you call a function without having to declare it - or dynamically generating routes in your Phoenix application to warn a developer when they've not accounted for something they should've like localisation.

It's good to be aware of Macros and what they can do for you - but seriously, triple check yourself every time you think about adding one. If you want a custom guard clause for your function heads pattern matching, look at defguard and defguardp instead.

There we have it.

10 tips to help you embark upon your Elixir journey. It's an incredible language, give it a chance and you'll slowly realise why I've been hooked for the past 3 years.

Subscribe to my Substack for similar content and follow me on Twitter for more Elixir (and general programming) tips.

5 scary Git commands you'll eventually have use for

Chris Gregori — Fri, 08 Jul 2022 10:43:49 +0000

Version control is magical.

I strongly believe everyone should learn how to use it - not just developers. How many times did you complete homework back at school and create arrays of filenames to denote just how final that piece of work was?

Today, in modern web development, Git is an absolute pre-requisite. But it's still shocking to see just how many experienced developers are just scratching the surface of what Git can do for you.

In this blog post I hope to unearth at least one useful Git command you perhaps haven't come across or would even think to use.

git rebase

Git rabasing is boils down to moving or combining a sequence of commits into a new base commit. It essentially appears like you've created your branch from a different commit base - extremely useful if you've been working on a branch for a while, you've diverged off of the main branch for a while and you run into conflicts when you try and merge back in.

It works something like this:

git checkout main # change to main branch
git pull origin main 
git checkout - # go back to last branch (feature branch)
git rebase main
# fix conflicts
git add .
git rebase --continue # until all changes are in

You can also use --interactive mode for rebasing which will let you manually select which commits you want to ignore throughout - helpful if you've made a commit purely to add some debugging and forgotten before committing.

Now, some of you might be thinking you can just git pull origin main in your branch and resolve the merge conflicts in an even easier fashion. While they are both similar there's one massive difference that you want to keep in mind here:

git pull will create a new commit that combines the two branches together
git rebase will move the commits of one branch on top of the other

You can also use git pull --rebase to pull using rebase which can be great and save you a lot of time. However

git rebase will essentially keep your git history clean.

Why is this important?

It means you can safely and effectively use our next arcane power: git bisect.

git bisect

git bisect uses binary search to find a commit that introduced some new unwanted functionality (read: bug).

It kind of works like this:

Imagine you're digging for the commit that broke a feature that we knew was working in commit 0cd429f02 (or a tagged commit), and somewhere along the way we broke something and a test is failing.

We can use git bisect to narrow down the commits and help us identify the culprit like so:

git bisect start
git bisect bad
git bisect good 0cd429f02

Note: You can use git bisect reset to jump out of this.

Once you've specified a good and a bad commit, bisect will find a commit in the middle of that range, check it out and give you some information regarding how many possible steps are left to split through.

Now that you're in your checked out commit you should run your tests and assuming it works, you can inform bisect of that by typing git bisect good, or tell bisect that that particular version is failing with git bisect bad.

Repeat the above steps and eventually you'll run out of revisions to test - bisect will then spit out the description of the first bad commit with a nice little summary - and there's your buggy commit. ✨

git stash

Stashing is used to take your uncommitted changes (including staged) and temporarily "stash" them away for later.

Extremely useful when you're not quite ready to commit a change, but need to move to another branch for some reason - maybe there's a bug you need to investigate.

You can stash your content like this:

git status

Changes not staged for commit:
    modified:   README.md
    modified:   mix.exs
    modified:   test/inspyre_web/live/story_live_test.exs

no changes added to commit (use "git add" and/or "git commit -a")

git stash

git status

On branch main
Your branch is up to date with 'origin/main'.

Like magic your changes are seemingly gone.. or are they?

If you run git stash list you'll see a log of previously stashed events alongside the branch you were operating on and the last commit in that log.

Running git stash apply will take the last stashed set of changes and apply them to your current branch but will not remove them from your stash list. If you know you won't need them this one time stash you'll want to use git stash pop to apply the changes and pop them out of your stash list.

git reset --soft HEAD^N

Have you ever accidentally thought you changed branch but really you were still in the last feature you were working on?

Have you committed multiple times?

Whoops. It's cool - we can fix that.

Use git reset --soft HEAD^N where N is the number of commits you want to un-commit to bring them back to you. From here you can stash or move to another branch and commit them there.

Be careful not to type --hard though. That'll trash unsaved changes for good.

git reflog

Gits secret weapon / time capsule.

git reflog will give you a list of every single thing you've done in git across every single branch.

If you've accidentally ended up in a state you weren't expecting to be in, deleted things, merged things accidentally or can't figure out what's happened, reach for git reflog (at least before you trash everything and re-clone your repo).

git branch -M (BONUS)

This one is simple but effective - and one I know several devs resort to deleting and recreating a branch to solve! 🤯

Renaming a branch!

Simply type git branch -M <new_branch_name> to set your new branch name for the branch your currently in.

That's all folks.

Hopefully that was useful for some - subscribe to my Substack for similar content and follow me on Twitter for more git (and general programming) tips.

Why do developers experience so much imposter syndrome?

Chris Gregori — Thu, 30 Jun 2022 09:33:27 +0000

The persistent inability to believe that one's success is deserved or has been legitimately achieved as a result of one's own efforts or skills. - Oxford Dictionary

Essentially a psychological occurrence in which someone (in the case of this article, a developer) doubts their skills, talents or accomplishments despite clear external evidence suggesting otherwise.

Almost every developer - irrespective of education or experience - has felt it at some stage of their career - and if they say they haven't, I don't believe them.

Why is it so prevalent in software?

It's due to the very soul of the tech industry - a symptom of the open, free sharing, nature of the job. With so many different tech stacks, languages, paradigms, layers of logic and knowledge, it's literally impossible for a developer to know absolutely everything.

You will come across someone that knows more about a topic than you do.

Is it a language feature that'll set you off? A design pattern? Knowing how to host and distribute software? AI? Blockchain? Web3? SEO? Accessibility? Web design? Performance? Systems design? UX?

We expose ourselves to as much as we can to make ourselves better in our roles - hell, the job itself is about constant learning to solve problems. Our job is about learning things. If a new ticket emerges tomorrow on your board and you don't know how to solve it, you're supposed to go and figure out how to do it. That's the job.

The modern web developer browses the internet daily for assistance, news and updates about their job - this culminates in more exposure to more things we don't know, and that can be a scary, scary thing for someone unsure of themselves in a professional capacity. Read something on Twitter? An article on Hackernews or Medium? Did someone just announce a new library on Reddit about something you feel like you should know about?

Chances are, that can be the trigger for that anxiety and ultimately make you feel like an imposter, and that's before even considering how quickly things change around here.

The rate that this industry moves is absolutely staggering. There is always going to be more to learn and it'll come at you at a pace that most humans can't keep up with. My team built a state-of-the-art marketing website with all the bells and whistles one could hope for around a year ago using some of the most bleeding edge, production ready tech available. Today, spending six hours on Twitter and Hackernews will tell you that your tech stack is archaic and that you should be building everything in Deno and Fresh.

So, what is the cure?

Honestly, it never really goes away. Sorry, but that's the truth.

At the time of writing this, I'll have been working as a professional Software Engineer for over 9 years.

I have worked with engineers to create software that has won accolades, won hackathons against a plethora of talented engineers, been promoted several times across multiple organisations and now lead a team due to my supposed knowledge. But it doesn't matter - every now and then (read: weekly) I'll see something online or talk to someone and feel like I'm a fraud. It happens. I know this is the case for other engineers I've spoken to as well, but even if there's no cure, there is medicine to relieve the symptoms.

Embrace the opportunity

Re-frame your mindset. If you come across a person or an experience that triggers that feeling of not knowing, take the bull by the horns; ask questions, admit that you don't know something and take it as an opportunity to learn and get better. It's better to be humble and admit you don't know something if it presents a chance to fix it.

Do you find that there's an insurmountable number of things that you need to learn? Prioritise. Write them all down, score them according to their importance, or how much they interest you or perhaps which topic would be most relevant.

Life is about learning - embrace the opportunity to learn something today that you didn't know yesterday.

Embrace what that desire to learn really means

If not knowing something is upsetting you, it's likely that it's because you care and you want to improve. If you have the capacity and desire to be honest about what you know and don't, are able to learn new skills, tech stacks and paradigms then that's as much of a definition of the job as there'll ever be.

Recognise that and recognise that it's a better situation to be in than thinking you know everything. You don't. No one does.

Rationalise the facts

Start listing the facts.

Out of the following scenarios, which is more likely?

That you scammed your way through all of your credentials, tricked every experienced interviewer you met and bamboozled a company into paying you a good salary to do a job you're not equipped to do

You know how to do your job, you've proved that through a series of rigorous tests which are researched and designed by "the professional developers" to weed out candidates, and met the criteria of a company willing to pay someone an agreed upon wage to do a job they believe you can do

Be really honest with yourself here.

Encourage your peers and promote collaboration

Software development is a team sport - almost every single product worth its merit - be that a website, an open source library you use, the circuit powering the device you're reading this on - has been built by a team of people with different skills all working together.

Encourage teamwork
Recognise failure as an opportunity to learn and celebrate wins together
Pair program
Mob program
Write the code together
Write the systems design document in a group
Collaborate
Teach each other
Tackle open source issues
Inspire and challenge each other.

You'll be a better developer for it and you'll learn so much more.

Ultimately, just remember that there will always be a higher bar to compare yourself against - the breadth of possible topics of expertise in this industry makes people feel like they're not up to scratch if they come across something they don't know and that's completely natural.

Jimi Hendrix couldn't play the guitar until he could.

Everyone is a beginner until they're not.

Be okay with the fact that you might come across something you know nothing about, but take solace in the fact that you have the capacity to; you've proven that before.

Embracing your own platform for blogging

Chris Gregori — Tue, 28 Jun 2022 09:00:22 +0000

👋🏼

My name's Chris Gregori - I'm a full stack software engineer specialising in Elixir and React, currently leading a team at Multiverse - the UK's first EdTech unicorn! (Yes, we're hiring, reach out if you're interested in changing education for the better).

This is my new personal site - it's been coming for a while, I initially created it as a Next.js project about a year ago and life (and design fatigue and side project-itis) got in the way until about a week ago when I had a spurt of inspiration. So I scraped 90% of the repository (aside from some static data I had written which was still relevant), upgraded Next to v12.0 and hooked everything up to a new Sanity.io project.

Why Next.js?

Next is a React.js framework. According to the latest Stack Overflow survey it's getting fairly popular - I'm a huge fan personally. It comes out the box with hybrid client, server, and static rendering, route pre-fetching, an image component that does all the hardwork for you, TypeScript support and more out of the box.

With static rendering, it means I can pre-fetch all my content at compile time and render it in the lightest way possible to my readers, so it's as fast as can be. Oh, and I'm hosting it on Vercels edge network (for free!) for world wide distribution.

Personally I think it's the nicest way to get a React project going these days - I'll mention that while I used to specialise in front-end tech, I've been less involved in it recently so feel free to correct me! Remix was also a consideration but I stuck to the devil I knew this time around.

Why / What is Sanity?

Sanity is a CMS (content management system) that puts developers first. If you've ever used or integrated with one before you'll likely find that the structure of the content you have to integrate with is strict and uncomfortable and the flexibility is usually limited. Another issue is it's usually all defined in some external service with no source control or ability to enforce rules and validations as and when you need them.

Sanity does away with that by letting you define all of your objects (think chunks of content) and documents (defined groups of content) in JSON which you control and manage the code for. This means you can create usable pieces, import them into your version of the Sanity editor (Sanity Studio) and deploy it!

It's nuts - in the new world:

All of your schema can live in source control
It can be as granular as you like with validation, rules and documentation you surface to your users
You can create and use community made, open source plugins in your editor
You can self host it
It's free

I had used Sanity in the last year when we built the Multiverse marketing site (which we won a Webby award for!) from scratch using it with React and Next.js - the development experience was ridiculously nice so I wanted to encorporate some of that into my blogging and personal site.

My previous personal sites had always been more of a manual affair. I had to do something around the realms of:

Clone or update the repo depending on where I was accessing it from
Re-teach myself how I'd stored the data
Write some JS or HTML
Commit the code
Push the code to source control
Re-deploy it manually or FTP it (yes, that's right)

Now with Next.js, Vercel hosting and Sanity, it looks more like this:

Access my authorised, hosted Sanity Studio (for free)
Change whatever I like in Markdown or alter dedicated fields (with validation!)
Hit publish

I've setup webhooks so that everytime I publish from Sanity I trigger a new deployment in Vercel which statically generates all of my content, styling and markup at compile time and hosts it on Vercels edge network globally which means my platform is as performant as can be. Sanity and Next.js also take care of rendering images beautifully with webp, and blured placeholders.

Why not blog on a dedicated platform?

I used to love Medium - it's awesome for a bunch of reasons. The design is beautiful, it's given writers a way to grow an audience without having to do the leg work of a self-hosted blog, it's promoted content is normally quite good, the list goes on.

But over the last few years I'd found myself becoming less and less enamoured with the platform. The introduction of the partner program seems to have bred a culture of writers creating un-original content with spammy titles just to get clicks, it's been YouTube-ified, and that's a real shame.

There's also the controversy that arose when FreeCodeCamp stole everyones content without consent. Yikes.

I've also found that I sometimes wanted more powerful editing features.

Seriously Medium, it's 2022, why do I still have to host code snippets in gists and embed them?

That said, I still like the platform and I'll be cross-posting there too for increased exposure thanks to the power of cannonical URLs.

What's new and funky?

MDX

This is one of my favourite bits - I'm using MDX for my blog posts which means I can write my content in markdown in Sanity and include JSX in the content itself which gets parsed and rendered out to the user.

Sparkly content omitted because it's not the original post.

Since I can render React components (that my code knows about beforehand) I can do some pretty powerful stuff.

Code editor omitted because it's not the original post.

Code Snippets with Prism

I've also added code snippets as you'd expect from any decent developer blog. This snippet is how I determine if I should add a sparkly "New" tag next to my blog post listings on the homepage.

const NewTag = ({createdAt}) => {
  const oneWeekAgo = dayjs().subtract(1, 'week')
  const publishedDate = dayjs(createdAt)
  const isNew = publishedDate.isAfter(oneWeekAgo, 'week')

  return isNew && <Sparkles><Tag>New</Tag></Sparkles>
}

Lottie

If you scroll to the end of the original blog post (hopefully after reading all of this delightful content), you'll see a lottie animation fire off. How cool.

The keen-eyed amongst you reading on desktop might have also noticed a progress indicator in the top left of the screen signaling how far you are through the post itself. This, and the lottie trigger are tracked using a useEffect hook alongside some magic from framer-motion.

  const { scrollYProgress } = useViewportScroll();

  const yRange = useTransform(scrollYProgress, [0, 0.9], [0, 1]);
  const pathLength = useSpring(yRange, { stiffness: 400, damping: 90 });
  const lottieRef = useRef();

  useEffect(() => yRange.onChange((v) => {
    if (v >= 1) {
      setTimeout(() => lottieRef.current.play(), 500);
    }
  }), [yRange]);

Cool, what's going to be on here?

I'm going to be blogging a lot more this year I hope and on a vast range of topics, including:

Elixir, Phoenix and LiveView
Front-end technologies like React, Svelte and Vue
CSS tips
New language deep dives
Architecture and macro-design
My opinions on the technical landscape
Coding tutorials and code snippets
Lots, lots more

I also do a fair bit of photography if that interests you.

How do I keep up?

Lots of ways.

Follow me on Twitter
Follow me on Instagram if you're interested in my photography
Follow me on Medium
Sign up to my SubStack using the subscription box below to get my articles straight into your inbox

I'm always down for a chat so feel free to reach out!

What's new in Node?

Chris Gregori — Thu, 30 May 2019 14:00:34 +0000

I used to solely write Node, React and JavaScript but in the last 1.5y I've been focussed on React-Native, Elm and Elixir.

I wanna spruce up and get back into it but I fear I may be slightly behind the ecosystem.

Any massive new libraries, features, patterns, do's/don'ts I should be aware of if I were to start looking for Node jobs anytime soon?

TIL — Git supports a global exclude file

Chris Gregori — Sun, 07 Apr 2019 10:59:08 +0000

TIL — Git supports a global exclude file

A tiny tip that might help a lot of you

I don’t really know why I didn’t think this was a thing until today but I was having some issues with elixir_ls (a VSCode plugin for Elixir development) plaguing my git repository up and my projects .gitignore file was seemingly ignoring the generated files.

There also seem to be some Github issues talking about the same thing so I wasn’t alone in my folly.

Solution

Your git installation can have a global .gitignore file! I’ve been programming for 5 years and had no idea — I’m not really sure why I didn’t consider it in the past.

To add a global .gitignore file:

git config --global core.excludesfile ~/.gitignore

To edit a global .gitignore file:

sudo vim ~/.gitignore (or an editor of your choice)

Here are the contents of mine — I took the liberty of adding some other common files I want to ignore in there too:

.DS\_Store
node\_modules/
.elixir\_ls/

Optional extra

Some of you might do this then find that your .gitignore hasn’t taken effect — the following commands will fix this:

git add [uncommitted changes you want to keep] && git commit
git rm -r --cached .
git add .
git commit -m "fixed untracked files"

Hope this helped! It cleared up my VScode woes.

Enjoyed my ramblings? Follow me on twitter to hear more of my development tales or keep up with my side projects on my personal site. 💻

“Why should I leave?”

Chris Gregori — Tue, 05 Mar 2019 17:22:24 +0000

An open insight into what it’s like to leave a comfy Software Engineering job and venture into the unknown.

There’s a TL;DR… at the bottom.

Photo by Andrew DesLauriers on Unsplash

Over the last 3 years I’ve worked at 3 different companies; in this post I’m going to outline the real benefits and losses I’ve experienced by moving away from one of the best jobs I’ve ever had.

This is a personal account of my time and experience at these companies and it should in no way muddy your opinion of the companies themselves or the people that work there, this is just a recollection of my experience.

My Engineering Timeline

Thomson Reuters : 2012 (Not covered / University industry placement)

Net-A-Porter Graduate Scheme : 2014–2018

SkyScanner : 2018–2019

WhiteHat GB : 2019-Present

Net-A-Porter

Background

I joined NET-A-Porter (will be subsequently referred to as YNAP ) in 2014 as a graduate. Over the course of 4 fantastic years I established myself as a Software Engineer thanks to the tutelage of the incredible people and mentors I had there, and due to the different paradigms, logic/business problems, and experiences I was lucky enough to be exposed to there.

I loved my job, genuinely. I would wake up and look forward to going in — something I know many people aren’t fortunate enough to experience in their careers — but the reasons for my adoration for my workplace started to dwindle and I had my career prospects to think about. The issue is that I had grown to adore the people and the comfort, and I was genuinely scared that I wouldn’t survive at other jobs for a variety of reasons:

I don’t have the skills for another job (imposter syndrome at it’s finest)
I wouldn’t manage to form meaningful bonds with other colleagues like I had done at this one
Other jobs would expect far more from me, NAP was quite comfy
“I’d miss the people too much”
What if the technology isn’t as cutting edge? NAP was happy to test out bleeding edge if it made sense
I really don’t have the skills for another job (again)

The company was a great kick off point for my career; I managed to hop different stacks and teams as a graduate (Java, Scala, Node, React, Vue, Swift, Perl, Ruby), and eventually settled into a Node/React role in one of the most important teams in the company. I was able to make a real impact over the next few years working on plenty of large scale projects.

Aside from the great technical challenges I was faced with I also managed to experience what it’s like to work at a company that really does have a great culture; colleagues were actually friends with each other, after/during/before work social gatherings were the norm; everyone was great, I loved the people there. This is largely due to the heavy emphasis that was put on during the hiring stages to ensure that the people joining valued the same things as the company.

Fun fact: did you know that statistically, the companies with the worst working cultures are the ones that brag about it as a selling point? It’s because employees start with very high expectations of what to expect, most of which are never met

Hints of danger

The good times lasted for some years until things started to change shape. After some large scale business and technical direction changes, my day to day work wasn’t as profound as I once found it to be — I won’t go into specifics here but I stopped being interested in the type of work that was coming my way and the type of work I foresaw the company (and subsequently myself) doing. People started to see this shift and began leaving, this shouldn’t be shocking to anyone and it can’t always be attributed to company issues, some people just want a change of scenery after a few years.

Alongside all of this I had been tinkering around in exciting, different languages and stacks in my own time and found myself really wanting to work in a more backend focussed role, specifically I fell for Golang— slight issue here is that a lot of my professional experience at this point wasn’t geared towards a backend role without a significant dip in salary; I had some but I lacked database experience and other traditional tricks of the trade. Call it greed but I wanted to become a different type of engineer without slashing my income dramatically.

Moving on

So I started looking for another job in September 2017. Luckily YNAP put me in a good position CV wise thanks to some of the incredible work some of my colleagues were becoming known for in the tech world and I received an influx of interview offers from plenty of different companies; this is my imposter syndrome talking too, in actuality I had done some good work, won some hackdays, created some fairly successful side projects, was pretty well trained and had been told I was a good developer. I turned down a few offers when I realised they weren’t offering what I wanted (or thought I wanted?) tech/product wise. I was also scared, I kept making excuses for the companies that were offering me roles or interviews and kept putting it off for a few months.

In April 2018, I finally summoned the courage to leave after a few melting points at work and landed a job as a Full-Stack Developer at SkyScanner which seemed to fit the bill.

It didn’t in the end, but that’s okay.

SkyScanner

I joined and immediately began working in a small, autonomous team that was focussed on re-creating a part of the mobile applications in React-Native. The team was highly motivated, had some good knowledge of the domains and stack we’d be working on and the project seemed quite cool.

So how was I doing?

New technology requirement ✅
Substantial salary bump ✅
Good team ✅
Backend work? ❌

Pretty good right? Kind of.

https://medium.com/media/cff7d4a5b868c807c4740d95e5466903/href

You see what SkyScanner offered me the position they weren’t clear about what tech stack I’d be doing and stressed that I’d be put into an appropriate team that matched my skillset upon accepting. I let them know that I really did not want to work on Java simply because I hated working with it and that I didn’t want to be stuck in front-end again; they seemed on board and their other tech stacks seemed appropriate.

Initial thoughts

When I first got there, the team (newly formed from new hires without strict JS backgrounds) was finishing off an MVP of a React Native prototype they had built to see if the stack stood up to the project requirements. It made sense, required less engineers for a multi-platform native application, the project didn’t require any niche platform functionality that RN couldn’t provide and we could still make it look good. After a few months of learning React-Native (very small learning curve if you’ve done React on web) and creating the new version of the app it turned out that the team needed a backend system to proxy and aggregate the calls we were making for our app.

Cool, finally I can work on some backend stuff, and get the experience I so desperately desired.

Well the team wanted to build it in Java due to their backgrounds. Much to my dismay, it made sense, it fit the purpose and Java had a strong backing from the company so tools and help were readily available. Okay fair enough, I could get on board despite me trying to get stacks like Golang or Elixir or <Insert CVDD tech stack here> in the picture.

Excited to finally get going on some backend work, I found out that the company had a “Developer Enablement” team. Their job was to create scripts and tooling around developer experience and cookie cutter builds. It was extremely useful and very productive to have a secure, logging-ready, CI/CD, AWS dev/prod and terraformed application ready simply by running a CLI command.

As productive as that was I was disappointed that I couldn’t learn anything about the process of setting any of that up because it had already been done for me at the push of a button, no ops knowledge or Java skills to pick up there at all. In my opinion a large amount of knowledge comes from setting up systems from scratch, you learn how things are coupled, where things live and how things interact.

The actual work there was to do on the Java side wasn’t exactly what I wanted either — I wanted to work on distributed systems, build microservices working at scale, optimising DB queries, analysing streams of data etc. The app was simple and proxied requests to a few internal systems and told the app how to behave — nothing I hadn’t already done before in other stacks. Ignoring this the team was composed of engineers from a variety of backgrounds and guess what, Software Engineers are opinionated, if some of them only wants to work in Java they’ll probably only pick up the Java tickets, so guess who was charged with doing most of the React work alongside developers that wanted to write JavaScript like enterprise Java?

You guessed it.

https://medium.com/media/408db45ebdb83f608e78dd68af3fcf17/href

Alright so I wasn’t happy with the tech, what about the product I was building itself? Well after 6 or so months we released a version of the application we planned out after we pivoted a few times due to some decisions from the higher ups. The app wasn’t bad and we were releasing updates frequently in an agile fashion — but I was still stuck in a position of working on React Native (read: React), all the while I felt like my skills were dwindling in other areas — I was no longer configuring webpack (a blessing really), I wasn’t doing any web performance tweaking, I wasn’t doing any Node or backend work and I’d lost my opportunity to touch AWS. Mobile was also a far more restrictive and annoying platform to release to in my opinion. Overall, I felt like I was stagnating as a developer.

Along with this issues I had also realised that many of the other developers on my team weren’t really that engaged — whilst that shouldn’t effect me, it’s hard to get invested in a team and a product when your colleagues are pointing out (very valid) flaws day-in-day-out.

So what did this job give me?

Confidence and clarity (and a pay raise).

The React Native skills were nice and I still use them to create small apps on the side in my own time. But the most valuable thing I took from this position is the knowledge that changing jobs doesn’t have to be scary. I made it through with more clarity and some tangible CV skills, and a bump in pay.

Was it perfect? No, but it was a learning experience.

Did I make intense meaningful connections to people? Not really, I made friends, some of whom I still keep in touch with, but I shouldn’t have ever expected that I’d form the same bonds with the people that I began my career with over 4 years in every work place. It would’ve been a great bonus but it wasn’t necessary — I still keep in touch with the people that matter and friends come from all avenues of life.

I only left after 10 months but that was my decision because I had realised what I wanted from a job and what I didn’t. I needed a role that would at least let me explore backend development and work with databases. I needed something different to keep my interest. I needed a product that I actually cared about building.

After a month or so of looking for new work (and a brief idea of contracting) I found a lovely start-up that’s looking to really help people and empower a new generation of world leaders in WhiteHat.

WhiteHat

As of writing this I’ve only been at WhiteHat for 1.5 months, it’s a challenging environment and I’m having to learn faster and more effectively due to the startup nature, and due to the fact that the entire tech stack is built in Elixir, Elm and PostgresDB, and aside from what I’ve gathered from ES6 and Redux, I’ve never done any functional programming.

But I’m learning, I’m meeting people, I’m seeing engineering life through the eyes of a small company that’s rapidly growing and expanding it’s territory and I’m excited. The future is bright for this little ~50 person start-up and I think we can do great things.

Aside from being pumped to get into a whole new tech stack and get some experience doing backend work, I’m actually optimistic about what we can achieve and what we’re doing, it’s a mission that isn’t just selling expensive things to people that can afford it, and it turns out that’s important to me.

Take aways

Moving jobs is scary. Especially if you’ve been there for a while and resonate with the people and the memories you’ve had there. But if you’re finding yourself no longer challenged, no longer interested, no longer learning or no longer caring about the work that you’re doing then maybe it’s time to look elsewhere.

It doesn’t have to be as scary as you think.

Other companies are also doing incredible things. Just because your current company does some things in a great way doesn’t mean others don’t and it doesn’t mean you’d be missing out elsewhere.

SkyScanner had an incredible devops setup which really blew me away. It also had some immensely talented people working in lots of different, varied teams and it was trying to establish an objectively good working culture — even if I had some issues with it.

Net-A-Porter had an immensely sharp eye for detail in it’s front-end technical teams and were headed up by some fantastic product, tech and delivery leads. My old teams admiration and drive to get testing, performance and user experience nailed was immense and it helped mould me into the developer I am today. It was also home to some of the most incredible people I know.

But you learn things by moving and it helps you get over the fear. I’m not scared of looking for new opportunities as I once was because I now know that whilst the grass isn’t always greener, it’ll still give you learning experiences and teach you things about the industry and yourself that you didn’t know.

Your turn

If you know exactly what you want to be working on, what excites you and you’ve gathered or are working on the skills needed for it then you’re half way there.

Software Engineers are lucky — the market is currently fantastic and innovations in tech are bringing about new opportunities every day. Just make sure that when you’re looking for them you really question what’s important to you.

In interviews, ask about the culture, ask them about what sort of work you’re really going to be doing and see if you can talk to the developers that already work there. Get an insight into how they release, how they build things, what’s in the roadmap, how they get feedback on their product, how they A/B test, how they test in general, really dig deep.

Also remember that when you’re being interviewed, you’re also interviewing them. Don’t sell yourself short and recognise that this company wants you otherwise they wouldn’t bother taking the time to find out.

They have needs but so do you.

TL;DR

By moving jobs you release yourself of the fear that other jobs won’t be as good or that you won’t make as many friends or have as good of a time. You might not, but each time you move you’ll expose yourself to new ways of thinking, new tech stacks, different work cultures and a bump in salary because let’s be honest, people care about money because money is important. Move and you’ll get more than staying (generally).

Be picky about where you wanna go and know what it is you want out of the job. Is it the product, the tech, the money? Know what you want, learn the skills and don’t get attached to a place because you are good enough to work elsewhere, even if you don’t believe you are.

https://medium.com/media/3036ebf1372b812578b622f81b6c5de0/href

Enjoyed my ramblings? Follow me on twitter to hear more of my development tales or keep up with my side projects on my personal site. 💻

My new approach to finding a gap in the app market

Chris Gregori — Sun, 13 Jan 2019 19:13:22 +0000

A different take on making a side project profitable in this saturated app world.

Photo by rawpixel on Unsplash

A problem a lot of developers I know have is thinking about what they can apply their newfound superpowers to: launching a side business or creating apps to make millions (the most common in my experience), developing embedded systems to automate your home, web apps to help manage your at-work pingpong tournaments and more.

A major issue with the first one is that the market, between both Android and iOS, has over 4 million apps for your potential customers to download — how are your customers supposed discover your new vegan recipe app amongst the clones of Flappy Birds, Bejewelled rip offs and Instagram-story-optimisers?

Secondly, what makes your idea original enough for people to download it?

My take is that it doesn’t need to be.

The app store is plagued by thousands of games, and apps that barely work that’ve been made to fill a gap in the market that was relevant at the time. Years ago someone uploaded the first 3-minute ab workout routine generator because one didn’t exist. That person likely made a small fortune from their app and might be thinking about how lucky they were to be the first to do so. App ideas are now seldom original — yes with the emergence of powerful and exciting new toolkits and technologies like machine learning and AR we will see new innovations in the app space, and some people really can think of incredible, innovative ideas, but maybe you can’t and you’re kicking yourself about the fact that everything with a public and free to use API has already been done.

So what are you to do? Reinvent the wheel.

My Take

I created Seagull Trainer , a £2, fully-fledged, Kegel training app built to be a little bit fairer to the people looking for apps to help reinforce their pelvic floor muscles. A friend of mine told me he started using a free kegel training app on Android and showed me how the app worked — he was able to get 3 sessions in (which included 2 manoeuvres) before he was told he had to buy the remaining 97 sessions via in-app-purchases for £8 in total. He bought the sessions! I thought this was ridiculous so I decided to make a better looking, gamified version with more features, a well researched routine and answer questions commonly found in the Kegel world by browsing forums and research sites.

Would making the app free be a more fair thing to do? Yes but my time is also valuable to me and £2 is less than the price of most peoples morning coffees. Also ads suck.

The app is currently bringing in more money (almost definitely far less than whatever figure you’re imagining) than any of my free + ads apps are. Yes with an obscene amount of volume these freemium apps can make a good amount of money but they’re also usually in the realm of apps that have already been done to death or require an obscene amount of effort to beat the competition — why not go for the tried and tested salesmen approach of undercutting the competition with a better product?

This also helps get around your first issue (app discovery); hundreds of app ideas have been farmed into this ‘just about works and costs money’ niche and due to the sheer number of users on these app stores, people are biting. If people are searching for these things anyway, put the best option in their eyes and they just might give it a go given enough polish, screenshots, honesty and positive reviews.

By following this approach, we purge the app store of poorly implemented, money-grabbing apps that appear free then charge obscene amounts for basic functionality — it may also help you get that elusive side hustle started. Consider a solution that improves upon badly implemented, freemium, good ideas next time you’re racking your brain for a side project to work on, especially if you see something niche. And who knows, maybe one day people will finally be okay with spending less than the price of a coffee for a tool that could revolutionise multiple aspects of their life.

Win, win.

Photo by rawpixel on Unsplash

Wanna give Seagull Trainer a spin? Here’s a link:

Seagull Trainer iOS Store

Enjoyed my ramblings? Follow me on twitter to hear more of my development tales or keep up with my side projects on my personal site. 💻

How my silly app turned into something potentially useful

Chris Gregori — Sun, 12 Aug 2018 10:31:01 +0000

Turns out that logging users poops on a map in real time can actually be something that helps everyone.

Dan Edwards — Unsplash

Backstory

Around year ago I began looking into React Native; as a web developer the idea of creating native applications without having to master multiple ecosystems and stacks was incredible. I personally love apps — I know some people prefer web experiences or PWAs to save their devices storage space or don’t want to download something for a one off use but I just find apps tend to have better UI and UX — good enough that I’m happy to download them.

I don’t want to start a web vs native war here — they’re both great and some web apps are definitely better than their native counterparts; in my experience however, apps are usually more refined.

Anyway I wanted some sort of project to build that wasn’t just a todo list or a notes app; I wanted something a bit more technically challenging so I could test if React Native could actually be utilised by a company or for a real world application. I was also beginning a job at SkyScanner as a React Native engineer so I wanted some hands on experience before starting the job.

Implementation

Introducing Logger: The Poop Tracker!

Logger is an idea stemming from a pun that I won’t explain; the short and sweet of it is that it’s a real-time, GPS tracking, logging application utilising Facebook oAuth and Google Maps. It’s powered by Firebase (which is incredible and free to a point) and it’s completely free.

A summary is it’s app with a real-time feed logging every users public logs. Each log has a star rating associated (because why not) and each user has a profile page they can use to see their average stars, their day/night ratio and where they use it.

The actual implementation isn’t anything magical — it logs to Firebase and makes use of Expos fantastic library of features such as a MapView and Facebook oAuth to authenticate, store and show logs on a map.

Launch

Logger was built as a joke — it was something my friend started making then he gave up, so I thought why don’t I use this as the base of my React Native training. It took me around 4 months of on and off starting and stopping — mostly due to some libraries not playing nicely (mainly React Navigation) and because it’s hard to stay motivated on a project that’s so silly and has no use.

The thing is though, Logger does have a use — multiple actually. After I released it I realised that it was actually being used from various spots around the world: USA, parts of Asia, Europe; I didn’t even spend any money or real effort promoting it — word of mouth, humour and the magic of the App Store had taken it into users hands.

That’s when I realised the crowd sourced information could actually be used for something…

Toilets

Everybody poops. There’s even a book about it.

On the second day of Loggers release to the App Store I added a feature by adding a new map tab, adding a toggle on the log function, and utilising the platform that I had built: “ Public Toilet? ”.

By adding a way for users to mark if their log was in a public place I was able to map this data and allow all users to see a map of local public toilets available for use. The issue is the information is all crowd sourced — meaning if people don’t use the app, there won’t be toilet information to share — it all begins and ends with the user.

The mechanisms were all in place, people were already using the app as a joke, but now they had an actual reason to use it. If someone wants to know where the nearest public toilet is or wants to add to the database — they’ve got Logger for that.

I had used Expo to build and publish my application binary which enabled my favourite part of React Native development — publishing my binary to a CDN. That’s right I didn’t need to release a new app version and go through Apples review process again. Upon hitting Publish my new version was live in seconds — just like a website!

Next Steps

Whether I continue developing Logger is based on how many people actually use it — if people find it useful I will continue to support and maintain it. Otherwise this was a fun little experiment to see if I could use my React skills to build a mobile application — and I could!

React Native is beautiful. It provides a web developer the basis to create and innovate on an entirely different (and at times very scary) native platform without having to immerse themselves in the lands of Swift and Android. If you’ve ever built anything in React before and are confident with how it all fits together — I encourage you to try it, it’s really not that bad.

That’s not to say I’ve cast native development to the wind — on the contrary React Native still has some short comings; it’s not as nice to animate with as native Swift, it doesn’t always play nicely with some libraries and it produces a fairly large app size if you’re using Expo.

I’m actually planning on learning Swift (properly this time) to make my second Swift iOS app now that the language is out of infancy. I think I’ll try and make something a little less gross and a little more useful.

Download Logger today!

If you’d like to help Logger and spread the public toilet news, please download the app and report back your findings!

Download for free today by clicking here.

Perhaps Logger has some other uses I haven’t thought of, let me know in the comments if you can think of anything!

Enjoyed my ramblings? Follow me on twitter to hear more of my development tales or keep up with my side projects on my personal site. 💻

HTTP Status Codes you probably haven’t heard of

Chris Gregori — Wed, 04 Apr 2018 17:53:45 +0000

And might not often see in the wild.

A colleague of mine stumbled upon a HTTP status code that the team wasn’t sure of: 207. When I took a look I stumbled across a few others I hadn’t really been made aware of throughout my 4 year developer career.

Lets go through some interesting codes…

207: Multi-Status

A status code sent to represent information about multiple resources where appropriate.

Imagine you have an aggregation layer that might make calls against multiple APIs to collate & process the data and return a JSON payload. If one of the calls succeeds and several others fail what’s the API to do?

It’s not a 4xx, the resource was found; it’s not a 300, there’s no redirect; it’s not a 5xx, the aggregation server didn’t fail to handle something and explode so it’s technically a 200 in the eyes of the app server.

207 is clever; if implemented properly it’ll give you an XML payload with a description of the information about the success or failure of the layered calls — each element must contain a href to identify the resource. It’s up to the consumer to handle what happens next.

411: Length Required

When a server refuses to accept the request without a explicitly defined Content-Length.

Simple and makes sense but not the most common code you might see.

451: Unavailable for Legal Reasons

A status code sent to deny access to a resource as a consequence of a legal demand.

A 451 response body should include an explanation of the legal demand, the party making it, the applicable legislation or regulation and what classes of person and resource it applies to.

Interestingly a 451 doesn’t necessarily mean that the resource being requested exists — if the legal reasoning behind denying it were removed, the resource might still not be there.

Pretty cool.

418: I’m a Teapot

Yeah you read that right. This client error responds to indicate that the server refuses to brew coffee because it is a teapot.

Relax, It’s an April fools joke from 1998.

Read more about it on the official Request for Comments.

506: Variant Also Negotiates

506 can be used to state that the server has an internal configuration error in which the chosen resource is configured to engage in a transparent content call itself, thus it’s not a proper end point in the negotiation process.

Experimental.

508: Loop Detected

Occurs when a server has encountered an infinite loop while processing a request — this is sent to indicate that the operation has failed.

I personally haven’t seen this often as I find that when people detect infinite loops in their code they fix them or they’re uncaught leading to a timeout.

There you have it, sort of interesting right?

Enjoyed my ramblings? Follow me on twitter to hear more of my development tales or keep up with my side projects on my personal site. 💻

The highs and lows of using Lerna to manage your JavaScript projects

Chris Gregori — Tue, 03 Oct 2017 14:30:17 +0000

Overview, pain points, highlights and tips

Lerna is a tool for managing large scale JavaScript projects with multiple packages.

Anyone that’s worked with huge projects that are made up of granular components or dependencies knows that it becomes a hassle to make updates to your work after a while. In the world of 2017 JavaScript we’re importing packages all over the place and Lerna is helping us manage them for our big projects at Yoox NET-A-PORTER.

Who’s using Lerna?

BabelJS
create-react-app
react-router
Jest
And many, many more

What it really does & why it’s great

Lets start with an example.

Imagine you have a React application with a Button component — this button component needs to use a Text component (granular but just humour me for the examples sake):

// inside the super-button NPM package + repo

import SuperText from 'super-text'

const SuperButton = props =\> (
 \<button\>
 \<SuperText value="Click me!" /\>
 \</button\>
)

export default SuperButton

// inside the super-text NPM package + repo

const SuperText = props =\> (
 \<span\>
 {props.value}
 \</span\>
)

export default SuperText

Each of these components live in their own repos and are their own NPM packages — they need to be maintained, versioned, and worked on by 20+ developers.

Lets say we have a consuming application of both of these components — if we wanted to update both of these components as part of a feature then we would have to make the changes to each, update tests, update the versions, commit the changes, get them code reviewed, publish the packages, update the consuming application and use them — phew.

But wait! You just realised your changes are slightly different to the requirements and/or it doesn’t work as expected — lets pretend these components are far more complicated or might involve complex styling etc. You’d have to redo that entire process again — if your team is busy maybe they won’t get around to code reviewing it, maybe you’ll be blocked for the next 2 hours and have to resort to reading Medium articles until they’ve unblocked you!

Lerna to the rescue! Lerna lets you construct your application into a very large repository of packages and apps (can all be renamed and configured); these apps are the consumers and the packages are the granular dependencies (SuperButton & SuperText above). When you’ve made all the changes required, you execute a command:

$ lerna run bootstrap

What this will do is go through all of your applications (in our self-named apps folder)and symlink each apps dependencies to any local version found inside the packages by using the respective packages name (and version!) in package.json. Any that aren’t found in packages will simply be installed from npm the same way you would anyway.

This is huge — it allows massive refactoring, updating and feature enrichment without the developer process headache. Make changes to your dependencies, bootstrap, check and implement them in your consumer apps and you’re done! Save the pull request until everything is ready.

Why it can be annoying & how to mitigate the pain

Sounds great right? We initially though so then we ran into some headaches porting our large app over — we’ve mostly solved all of them:

If you have a lot of dependencies in each application, bootstrapping can take a very long time. 2017 web development usually means you have 500+ dependencies of all manner of packages running your application — whether it’s for a build step, transpilation, bundling, a reusable component or simply something to left-pad your strings. Mitigate this by moving all of your shared dependencies between apps & packages to a root package.json file and specify the --hoist flag in your bootstrap command. It’ll still take a while but it’ll greatly reduce the time taken.
Tests take a long time to run and lose syntax highlighting. The $ lerna run test command goes through each package and runs the test script declared in package.json — the issue here is it will spawn a test runner for every single instance it finds — in our case we had ~60 which ate our laptops up. It also meant that our syntax highlighting (passing/failing/warnings etc) were being omitted due to the test runs being spawn in seperate shell process. Solve this by running your test runner from the root level with a config file there to specify which directory to find tests in — we use jest and the config file makes this all pretty easy. Our tests went from ~2m to run to ~15s and we got our colour coding back!
Ways of working with one gigantic repo. We’re still solving this incrementally and will depend on your project, team structure and requirements — if you’re building a large shared platform of reusable, atomic components you sometimes ask yourselves ‘who owns this?’, often the answer is everyone should but things don’t always work out that way and is a talk for another blog post.

We’re still getting used to Lerna, it’s been a rocky path of frustration but ultimately it’s worked out for the best. It was great for our project and it might just be great for yours.

Want to learn more about Lerna?

Check out the official site or check out the github page

Enjoyed my ramblings? Follow me on twitter to hear more of my development tales or keep up with my side projects on my personal site. 💻

DEV Community: Chris Gregori

10 tips for new Elixir developers

What is Elixir?

1. Get used to pattern matching

2. Append to a list the correct way

3. Finding N slowest tests in mix application

4. Read the docs (especially Enum)

5. Embrace Doctests

6. Atoms are not garbage collected

7. Embrace the small, but mighty community

Slack

Twitter

8. Add labels to your IO.inspect/2 calls

9. Try and keep your functions small and composable

10. Learn about Macros but be cautious

5 scary Git commands you'll eventually have use for

git rebase

git bisect

git stash

git reset --soft HEAD^N

git reflog

git branch -M (BONUS)

Why do developers experience so much imposter syndrome?

Why is it so prevalent in software?

So, what is the cure?

Embrace the opportunity

Embrace what that desire to learn really means

Rationalise the facts

Encourage your peers and promote collaboration

Embracing your own platform for blogging

👋🏼

Why Next.js?

Why / What is Sanity?

Why not blog on a dedicated platform?

What's new and funky?

MDX

Code Snippets with Prism

Lottie

Cool, what's going to be on here?

How do I keep up?

What's new in Node?

TIL — Git supports a global exclude file

TIL — Git supports a global exclude file

A tiny tip that might help a lot of you

Solution

To add a global **.gitignore file:**

To edit a global .gitignore file:

Optional extra

“Why should I leave?”

My Engineering Timeline

Net-A-Porter

Background

Hints of danger

Moving on

SkyScanner

Initial thoughts

So what did this job give me?

WhiteHat

Take aways

Your turn

TL;DR

My new approach to finding a gap in the app market

A different take on making a side project profitable in this saturated app world.

My Take

Wanna give Seagull Trainer a spin? Here’s a link:

How my silly app turned into something potentially useful

Turns out that logging users poops on a map in real time can actually be something that helps everyone.

Backstory

Implementation

Launch

Toilets

Next Steps

Download Logger today!

HTTP Status Codes you probably haven’t heard of

And might not often see in the wild.

207: Multi-Status

411: Length Required

451: Unavailable for Legal Reasons

418: I’m a Teapot

506: Variant Also Negotiates

To add a global .gitignore file: