Forem: Ed

The Unarchitecture

Ed — Thu, 18 Feb 2021 13:22:51 +0000

A team of developers have been given a new greenfield project to deliver. The powers that be told them they have full control over the technical direction of the project. The team was excited to move on from their legacy project, it was a great opportunity for them to apply the lessons from the old onto the new. They were going to do things properly this time.

Building a Barn With a Golden Hammer

One of the developers closely follows the Uber Engineering Blog and there she read Uber uses Golang to hit stellar RPS (requests per second) numbers. She proposed that the team writes this project in Golang so they can leverage that same performance.

The second developer suggested they use React for the frontend and build an SPA (single page application), because that's what everyone's doing these days and it's the de facto standard.

The last developer found great success with serverless microservices at his previous company. He recommended they leverage the near infinite scalability of the serverless platform for their new project.

At face value, the plan seemed solid - Golang on the backend, a React SPA on the frontend and it's all going to be served by a serverless microservice infrastructure. It was going to be performant, infinitely scalable and decoupled.

Executing the plan proved more difficult than they anticipated. It turns out they forgot to take a few things into account.

The team didn't have any real experience with Golang as they were all primarily PHP developers. Building a React SPA was proving to be a time sink as they now had an additional problem of communicating with APIs. By the time they had 12 microservices, the complexity of their system was causing more issues than it was solving. To add insult to injury, they were only asked to build a very basic inventory management system for internal use.

Somewhere in the excitement and the prospect of doing it like the big companies the team forgot where they were, what worked for them and what they were building. What they thought they had was a solid architectural foundation to build upon, but what they ended up with was an unarchitecture.

What Exactly is Unarchitecture?

I actually borrowed the idea for the word from this blog and think it encompasses what I'm trying to convey here. To me, unarchitecture is ill-fitting software architecture, which is often born of best intentions.

If good software architecture makes a codebase easy and enjoyable to work with, then unarchitecture is the antithesis of that. An unarchitected codebase is a source of endless friction and misery for developers, it makes new features tiresome to develop and fixing bugs a soul-crushing exercise.

Where and How Does it Happen?

The story in the introduction has a series of questionable decisions that led to unarchitecting the codebase, but in reality all it takes is just one decision to create a pocket of friction in any codebase. For example, you could just over-engineer the CI pipeline and make nobody on your team want to touch it with a 10 foot pole.

I've found that unarchitecture often comes from a good place. We often tend to apply what we already know as working without really weighing up the pros and cons (everything has cons) of the approaches within our current context. What worked for a company with a team of 20 might not necessarily work for a team of 3. This applies across the board to software packages, languages, libraries, frameworks and patterns.

I like to think it's akin to wearing your parents shoes when you're 7. You've seen your parents walk in them and you really want to be like the grown ups, but once you try them on you can barely walk in them, much less run.

Preventing Unarchitecture

I think there are a few ways we can try and prevent ourselves from unarchitecting our applications:

We should aim to try and keep things as simple as possible for as long as possible. Introduce complexity only when we really need it.
Put our ego aside and question whether the pattern or technology we're applying is right for us, within our current context. Some questions that I like to ask myself are:
- Will my team realistically be able to maintain this? Do we have the skills required currently, can we learn or grow the team to accommodate for what we're trying to achieve?
- Can it stifle future growth? If we're going for simplicity, will it be hard to evolve if we need to?
- If our decision turns out being a mistake, how hard will it be to take a step back and go on a different path?
- Is this something that will bring us value? How? Maybe our efforts are better focused elsewhere?
I'm a big believer in Conway's Law and think we should take into account the structure of the organisation when we're architecting our applications. Our architecture should either complement the structure or drive change in the direction that we want to go.

Closing Note

In a world where microservices, serverless, Leviathan-esque container orchestration tools and decoupled frontends are all the rage, it's easy to lose sight of where we are and what we're trying to achieve and give in to hype driven development instead.

I think, in general, we should just strive to approach software architecture with more pragmatism and not give in to dogma. After all, there's no such thing as a panacea.

Notes on Promises and Useful Snippets (ft. async and await)

Ed — Sun, 03 Jan 2021 19:06:00 +0000

Quite a few people in my circle are either in development or looking to get into it as a career. The majority of them are learning JavaScript and the questions that I get asked most often relate to promises in some way.

I thought it would be a good idea to write up a brief overview of promises, explaining what they are (on a high level) and go through some snippets that I find myself using in my day to day.

While I did try to make this post as beginner friendly as possible, I assume that you, the reader, will have at least a basic understanding of JavaScript. If you don't, I highly recommend the CodeCademy Introduction to JavaScript.

What Exactly is a Promise?

In simple terms, it's just a way for us to execute a bit of code and provide the result of that code at some point in the future.

Imagine having a function that can execute in the background, while the rest of your application keeps happily chugging along, reacting to any button clicks, updating the DOM and etc. Once that function finishes executing (the Promise resolves), we resume the execution path that requires the result of that function.

The most common use case for promises is making API calls. You'd instruct your application to send a request to an API and do something with the result once your application receives a response. While that's happening in the background, or asynchronously, you can still keep using the application.

However, it's not just API calls that promises are useful for. In a broader sense, we use promises whenever we don't want to sit around waiting for IO - reading from or writing to disk, network requests or even intensive CPU tasks are some of the other use cases for promises.

It might be a bit difficult to imagine still, but bare with. The examples should help conceptualize the idea of a promise a bit better.

Here are the two main ways to use Promises - the standard API and the more novel async and await:

// We return a promise object that can either resolve (success) or reject (failure)
function promised() {
  return new Promise(function(resolve, reject) {
    return resolve('yay!');
  });
}

// We call our promised() function and then follow it up with a .then()
// The function inside .then() will execute 
// immediately after the promise resolves.
// The result of your promise will be passed in 
// as a parameter of our callback function.
promised().then(function(promiseResult) {
  console.log(promiseResult);
});

// Should print out 'yay!'

// Because we want to use await at the top level
// we have to wrap our code in a self-executing async function.
// This "hack" has a story of its own, I'll include it
// in Further Reading, but will not go over it here in much detail.
(async () => {
  // async here just says that whatever this function returns 
  // should be wrapped in a promise.
  // adding the sync keyword to our function also allows us to 
  // use await within the context of that function.
  async function promised() {
    return 'yay!';
  }

  console.log(await promised());

  // Should print out 'yay!'
})();

Disregarding the self-executing async wrapper, the code using async and await looks much neater and, in most cases, is going to be preferred. However, we still need to know and understand the previous method since there are times when it's useful.

Useful Snippets

In this section I'll cover some snippets that I use in my day to day that I think might be useful to others as well. They range from quite basic to more advanced. I highly recommend playing around with each snippet, to get more of an understanding of each of their intricacies.

Promise Chaining

This is a bit of a basic one, but possibly the most important. One of the great things about promises is that they can be chained together. Meaning, we can force sequential execution.

Lets say we want to fetch a fake person from one API and then use another API to guess our fake persons age by their name - a completely logical thing to do. Here's what it'd look like:

function fetchFakeUser() {
  // fetch() will return a promise.
  return fetch('https://randomuser.me/api/');
}

function fetchAge(name) {
  return fetch('https://api.agify.io/?name='+name);
}

fetchFakeUser()
.then((fakeUserResponse) => {
  // Get the JSON data from the response. Returns a Promise.
  return fakeUserResponse.json();
})
// As soon as the Promise returned by json() resolves
// we'll continue executing the .then() chain.
// Note that the result returned by the previous .then()
// will be passed in as a parameter to our next .then() call
.then((fakeUserData) => {
  // Return the name of our fake user down the Promise chain.
  return fakeUserData.results[0].name.first;
})
.then((name) => {
  console.log('Name: '+name);
  return fetchAge(name);
})
// We'll wait for the Promise returned by fetchAge to resolve,
// then continue executing the chain.
.then((fetchAgeResponse) => {
  return fetchAgeResponse.json();
})
.then((data) => {
  console.log('Age: '+data.age);
});

We can keep chaining the .then() functions indefinitely, as long as we want to maintain that sequential control.

One particular benefit of this is that it keeps our code relatively clean. Try and imagine doing something like this with nested callbacks, that'd be absolute hell!

We can also convert the above to use the async and await notation. If we did, it would look like this:

(async () => {
  // The functions below don't need to be prefixed
  // with async, because fetch() already returns a Promise,
  // so we don't need to do any "wrapping" ourselves.

  function fetchFakeUser() {
    // fetch() will return a promise.
    return fetch('https://randomuser.me/api/');
  }

  function fetchAge(name) {
    return fetch('https://api.agify.io/?name='+name);
  }

  // We'll use await to wait until the Promise 
  // returned by our function resolves.
  const fakeUserResponse = await fetchFakeUser();
  // Will only resume execution after the above Promise resolves.
  const fakeUserData = await fakeUserResponse.json();
  const name = fakeUserData.results[0].name.first;
  console.log('Name: '+name);

  const fetchAgeResponse = await fetchAge(name);
  const fetchAgeData = await fetchAgeResponse.json();
  console.log('Age: '+data.age);
})();

The above is more or less a direct translation of our implementation using .then() chains. One thing to note though is that everything below an await will be executed only after that function completes. So if we're awaiting for an API request, anything that comes after will be executed only after the request completes. This is particularly important to remember if you're using await and want to execute multiple promises at the same time (or in parallel). We'll get to this in another snippet.

Error Handling

One thing we've not touched on just yet has been error handling. As with anything, we want to be able to catch any errors that our promises throw and gracefully handle them. With promises, there are a few different ways we can approach this.

Using .then() and .catch()

It's fairly straightforward when we're using .then() - we'll use .catch().

const alwaysError = new Promise((resolve, reject) => {
  throw new Error('Oops!');
  resolve('Success!');
});

alwaysError
  // The function passed into .catch()
  // will receive the error as its parameter.
  // We can also return something from the .catch()
  // and continue our promise chain further.
  .catch((error) => {
    // console.log(error.message);

    return 'Failed!';
  })
  .then((userMessage) => {
    // If we would not have thrown an error,
    // our message would be 'Success'
    // as the catch() function is never triggered.
    // You can try this by commenting out
    // the "throw new Error" above.
    console.log(userMessage);
  });

If an error is thrown anywhere up the promise chain, .catch() will intercept it and it will immediately skip to executing the function that was passed into it. Once .catch() finishes executing, the rest of the promise chain can continue with the value returned in the event of failure. Easy peasy, right?

Using try and catch

Using async and await we'll want to use try and catch for our error handling. The only thing I'd like to draw your attention to here is that we have also extracted the error handling to a separate function:

(async () => {
  const alwaysError = async () => {
    // Comment the error out
    // to see the success flow.
    throw new Error('Oops!');
    return 'Success!';
  };

  const getMessage = async () => {
    try {
      return await alwaysError();
    } catch (error) {
      // Any error that is thrown by our promise
      // or if we manually call the reject method
      // will trigger this catch block.
      return 'Failure!';
    }
  };

  const message = await getMessage();

  console.log(message);
  // Should print out "Failure!"
})();

By doing the above, we nicely encapsulate our logic of "getting a message" along with any error handling.

Using await and .catch()

Sometimes extracting your error handling into a separate function might feel like overkill. Maybe you just want to quickly catch, recover and continue execution without any extra overhead. Using the try/catch approach we run into a few issues:

(async () => {
  const alwaysError = async () => {
    // Feel free to comment this error out
    // to see how it'd work without.
    throw new Error('Oops!');
    return 'Success!';
  };

  try {
    const message = await alwaysError();
    console.log(message);
  } catch (error) {
    // Handle our error here.
    const message = error.message;
    console.log(message);
  }

  // But if we want to use anything
  // outside our try/catch block,
  // it will not be available.
  console.log(message);

  // Message in this context will be "undefined"
  // and you will likely get an error.
})();

The main problem with this example is that nothing is available outside our try/catch block. There are ways to solve this, but none of them are elegant:

Declare message using let message just before our try/catch block, making it available outside the block scope. This, however, leaves us with a dangling, reassignable variable, so is not ideal.
Just stick all our code in the try/catch blocks. But this will increase nesting and very likely also lead to code duplication.

A cool and quick way to handle the above problem that I have found is to use a mix of await and .catch() :

(async () => {
  const alwaysError = async () => {
    // Comment the error out
    // to see the success flow.
    throw new Error('Oops!');
    return 'Success!';
  };

  const message = await alwaysError().catch((error) => { return 'Failure!'; });

  console.log(message);
  // Should print out "Failure!"
})();

The above works because .catch() and alwaysError both return a Promise and in this scenario await will wait for whichever Promise was returned last to resolve. This gives us a very elegant way to recover from an error that was thrown by our function and continue execution as if nothing happened.

Personally, I really like this approach and would even prefer it to try/catch in most cases, due to how clean and simple it is.

Parallel Execution

When talking about promise chaining using await, we briefly touched on parallel execution. Going back to our example of getting a fake person from an API, lets pimp it out a bit. Lets try and guess the age, country and gender of the name that we get.

A common solution to a problem like that would be something along the lines of:

(async () => {
  // We're prefixing the function with async
  // because we're going to be using await inside it.
  async function fetchFakeName() {
    const response = await fetch('https://randomuser.me/api/');
    const data = await response.json();

    return data.results[0].name.first;
  }

  async function fetchAge(name) {
    const response = await fetch('https://api.agify.io/?name=' + name);
    const data = await response.json();

    return data.age;
  }

  async function fetchCountry(name) {
    const response = await fetch('https://api.nationalize.io/?name=' + name);
    const data = await response.json();

    return data.country[0].country_id;
  }

  async function fetchGender(name) {
    const response = await fetch('https://api.genderize.io/?name=' + name);
    const data = await response.json();

    return data.gender;
  }

  const name = await fetchFakeName();
  const age = await fetchAge(name);
  const country = await fetchCountry(name);
  const gender = await fetchGender(name);

  console.log(name, age, country, gender);
})();

In this example, we'd wait until each API call was done. This happens because each await will stop executing anything below it until the promise resolves. A good way around this is to use the Promise.all() function:

(async () => {
  // We're prefixing the function with async
  // because we're going to be using await inside it.
  async function fetchFakeName() {
    const response = await fetch('https://randomuser.me/api/');
    const data = await response.json();

    return data.results[0].name.first;
  }

  async function fetchAge(name) {
    const response = await fetch('https://api.agify.io/?name=' + name);
    const data = await response.json();

    return data.age;
  }

  async function fetchCountry(name) {
    const response = await fetch('https://api.nationalize.io/?name=' + name);
    const data = await response.json();

    return data.country[0].country_id;
  }

  async function fetchGender(name) {
    const response = await fetch('https://api.genderize.io/?name=' + name);
    const data = await response.json();

    return data.gender;
  }

  // We fetch a fake name first.
  const name = await fetchFakeName();

  // Promise.all() will execute all the promises
  // that we pass to it at the same time
  // and it will return a Promise,
  // resolving with all the values of our functions.
  const [age, country, gender] = await Promise.all([
    fetchAge(name),
    fetchCountry(name),
    fetchGender(name)
  ]);

  console.log(name, age, country, gender);
})();

Promise.all() will take our functions, all of which return promises, and it will await until all of them have resolved. One thing to note that's rather important is that if one of the promises throws or rejects, Promise.all() will immediately reject as well.

Not really parallel, but as parallel as you can get on a single thread.

Racing

Promise.race() is a bit of a weird one. It's very similar to Promise.all() where it takes an array of promises in and it returns a single promise back. But unlike Promise.all() it will not wait until all the promises you give it will resolve. Instead, Promise.race() will resolve or reject as soon as soon as the first promise given rejects or resolves.

The two primary use cases for it that I've found are for loading indicators and performance checks.

In terms of a performance check, you can fire off requests to multiple endpoints, and you'll resolve with the response from the one that completes first. Fairly straightforward.

Loading indicators is where it gets slightly more interesting. Lets say you're making an API call that you know can take up anywhere from 10ms to 5s and in case of it taking too long, you want to provide the visitor some visual feedback so that they don't navigate away. Here's a basic example of what that would look like:

(async () => {
  async function fetchFakeName() {
    const response = await fetch('https://randomuser.me/api/');
    const data = await response.json();

    // Wait 5 seconds before returning the response of our API call.
    // This will help us simulate a slow network.
    return new Promise((resolve) => {
      setTimeout(() => resolve(data.results[0].name.first), 5000);
    });
  }

  function showLoading() {
    // Wait 0.5 seconds before letting the user know
    // the request is taking longer than usual.
    return new Promise((resolve, reject) => {
      setTimeout(() => reject('This is taking a while. Please wait!'), 500);
    });
  }

  await Promise.race([
    fetchFakeName().then((name) => console.log(`Name: ${name}`)),
    showLoading()
  ]).catch((message) => console.log(message));

  // Should print out
  // This is taking a while. Please wait!
  // Name: [name]
})();

One thing to keep in mind is that the other promises will not cancel and will still complete in the background.

Sequential Execution

While promises are great for executing various tasks asynchronously, sometimes we want to make sure that we are executing certain actions in a sequence. Due to the nature of promises, this can prove quite difficult, but combining promises with Array.reduce() we can solve this issue:

(async () => {
  // The number of processors 
  // that we have in our pipeline
  // can be completely dynamic,
  // as long as they accept a string and return a string.
  const processors = [
    async (name) => name.toUpperCase(), // Convert to uppercase
    async (name) => 'Name: ' + name // Prefix with Name
  ];

  // We are utilising Array.reduce here
  // and reduce our array of promises to a single promise.
  const processName = (initialName) => processors.reduce(
    // Our reduce callback is going to take the result
    // of the previous (or initial) promise, 
    // wait for it to be processed and
    // pass its result into the next promise.
    // processName will return the very last promise from the array.
    async (processed, processor) => processor(await processed),
    Promise.resolve(initialName)
  );

  const processedName = await processName('Ed');

  // Should print out Name: ED
  console.log(processedName);
})();

I have personally found this extremely useful when trying to build data processing pipelines in JavaScript. Or in other words - in cases where you have a piece of data (a JSON object, for example) and you want to pass that JSON object through a series of asynchronous processors.

Closing Notes

I hope people find this compilation useful. I highly recommend you read some of the material linked in Further Reading & References, especially if you are new and find promises hard to grasp still.

If you have any questions or would like to discuss or provide feedback - feel free to shout at me on Twitter @SkepticalHippoh.

Mozilla layoffs 🦊, COVID19 tech industry 🦠 and a bit on side projects 👷‍♀️ - Synk #4

Ed — Sun, 16 Aug 2020 10:54:29 +0000

It's been a very interesting couple of weeks in the world of development. From a restructuring of Mozilla to noteworthy career tips, we've got you covered!

Remember, if you enjoy the content, you can subscribe over at synk.sh.

📰 The News

Mozilla restructure leads to 250 employees being laid off

As part of a company restructure, apparently triggered by the current coronavirus situation, Mozilla has decided to reshift focus only to specific products, leading them to lay off various dev favourites including the MDN team (whose birthday we just celebrated in the last issue) and the DevTools team. A truly sad day for those affected by the restructuring, as well as those who heavily rely on Firefox for development.

💬DISCUSS: REDDIT | HACKERNEWS | TWITTER

Here is how the tech sector is dealing with the impact of COVID-19

The impact of coronavirus has been felt by many across the tech industry, and the data seems to confirm that. Though there is some issue with this data, such as the fact that it mostly focuses on the US and does not offer a breakdown of various seniority levels, it's fair to say that many industries, including tech, will be struggling for a while.

💬DISCUSS: REDDIT

20GB of NDA Intel blueprints have been leaked

If you've been waiting for Intel documentation for years, then you're finally in luck, as 20GB of Intel blueprints have now been leaked! In all seriousness though, this leak may could bring on a new wave of Intel exploits we've seen in the past few years (Spectre and Meltdown). Also noteworthy is that the leaker's account has already been suspended from Twitter.

💬DISCUSS: REDDIT | HACKERNEWS

🔭 Code Discovery

A tool to automatically update your dependencies and keep things secure

Renovate is a very nifty, highly customizable tool that can automate pull requests whenever your dependencies need updating. Think of it like a supercharged version of Github's own dependabot.

A different, faster way of parsing JSON

JSON is everywhere, and parsing it isn't always as fast as one might wish. Simdjson aims to change that, and it's already used by companies such as Microsoft, Shopify, and Yandex for that exact reason. Check out the Bindings and Ports of the README to find out how you can use it in your own application.

🎓 Career Development

Always ask questions in your interviews!

Many people fixate so much on answering questions during interviews that they tend to forget they are a two-way street. Both parties have to find each other appealing, so here are some questions you may wish to ask; a reverse interview!

CS is not for everyone, and that is absolutely fine

Working in CS can be absolutely exhausting, as tiresome as any other job. Whether you're burning yourself out or just not enjoying the job at all, it's okay to think about changing a career. After all, your wellbeing is more important than the job you're doing.

Only coding at work is okay

Anecdotally, a lot of us have probably experienced the pressure of feeling like we constantly have to be coding. But the truth is, it's absolutely fine to only code at work. Will you be the top programmer at your company? Perhaps not, but are the sacrifices you have to make to get there worth it? That's for you to decide, and no one else.

💬DISCUSS: REDDIT

🤔 Miscellaneous

How Adam Wathan turned Tailwind CSS into a multi-million dollar business

Adam Wathan, the creator of the fantastic Tailwind CSS framework, has shared some insight into his journey of turning Tailwind from a side project to a succesful business. If there is one key takeaway here, it's this: keep building things. Just because one product you made wasn't succesful doesn't mean the next one (or the 100th!) will not be either.

💬DISCUSS: REDDIT | HACKERNEWS | TWITTER

NodeJS best practice, from the source

Want to see what a proper NodeJS project looks like? Then check out the official repository and spend some time perusing its wonders. Maybe you'll notice some cool things, such as the fact that 64.9% of the code is written in TypeScript. A sign of things to come?

Arctic Code Vault, GitHub ReadMes and Svelte - Synk #3

Ed — Sat, 01 Aug 2020 20:50:55 +0000

📰 The News

Your code may have been stored in an arctic vault!

The year is 3020. Humanity is on the brink of extinction. The elders have decided to look into the past for answers. The mysterious GitHub Artic Code Vault is finally opened. The first film is unraveled in great anticipation, and the first message arrives: “Hello World!”

💬 DISCUSS: REDDIT

Svelte now supports TypeScript

Svelte, an up-and-coming front-end framework contender, has just announced support for TypeScript. While Svelte hasn’t seen as much adoption as Vue or React, this is definitely a step forward.

💬 DISCUSS: REDDIT

Happy 15th birthday to MDN Web Docs!

A fantastic resource for all web developers, MDN Web Docs has just celebrated its 15th birthday. Celebrate by reading something you haven’t seen before!

💬 DISCUSS: REDDIT

🔭 Code Discovery

Draw images on your GitHub contribution graph

Reddit user /u/me-at-work has created a very nifty tool that uses custom git commit dates to draw images on your GitHub contribution graph. Check it out and tweet us your creations!

Spice up your readmes with auto-generated stats

Thinking up good information to include in your readme can be quite daunting. With this tool, you can include some relevant, fun, and informative stats with little effort.

Cannot remember how to do X with Python? Look here

I absolutely love a good cheatsheet and often use various ones (hello Markdown, my old friend). If you often find yourself in a similar situation with Python, here’s a goood bookmark to have.

🎓 Career Development

Is Agile good for everything? A discussion

Love it or hate it, the Agile methodology is extremely common in dev workspaces. Prompted by an article by Ron Jeffries, one of the original co-signatories of the Agile Manifesto, read up on a good discussion about the pros and cons of Agile, as well as what it means for developers vs managers (good and bad).

💬 DISCUSS: REDDIT

Your code passing QA has nothing to do with being a good developer

Whether you’ve been in the industry for 6 months or 6 years, your code will likely fail QA. Does that make you a bad developer? Certainly not! Join this discussion and see how many developers struggle with the same things.

🤔 Miscellaneous

Microsoft releases NodeJS tutorials

There are not a ton of great resources on the web to learn NodeJS so it’s great to see a selection of curated, well-made tutorials by none other than Microsoft.

💬 DISCUSS: REDDIT

Struggling with Webpack? Read this

Webpack is a lot of things, but easy to understand is not one of them. This “gentle introduction” aims to change that a little bit and is definitely worth a read, even if you’ve just wondered what it’s all about. In case you’re looking for something that is perhaps easier to understand and simpler to start with, check out Parcel and Rollup.

💬 DISCUSS: REDDIT

Enjoy the content?

Subscribe to Synk. Web development news, cool code and career advice delivered to your inbox, every two weeks.

Synk #2 - 🏦 Barclays, 🐘 PHP and ⛓ Safe Links.

Ed — Sat, 25 Jul 2020 14:09:21 +0000

Hey! 👋 I posted a while back about launching a newsletter for developers. I'm over the moon to finally be able to share our newsletter with everyone in the DEV community. This is our second issue, which we feel is a major improvement over our very first one. Let us know what you think!

If you enjoy the content and want more of it, make sure to subscribe over at Synk for a biweekly delivery straight to your inbox!

📰 The News

🏦 Barclays used Wayback Machine as CDN

An inquisitive Twitter user (@immunda) found that Barclays had been using the Internet Archive's Wayback Machine as a CDN for some of its JS assets. Not sure how that one got through QA!

💬 Discuss: Reddit

Microsoft will drop official support of PHP on Windows

Though it's likely that someone in the community will pick it up, Microsoft will no longer officially support PHP on Windows. Will this affect you?

💬 Discuss: Twitter

🔭 Code Discovery

Check out a real-world app in different languages!

When you want to learn a new language, you'll often follow a tutorial that'll lead to the creation of a to-do app, or something similar. But what abou real world apps? In this GitHub project, you'll be able to see a "Medium.com clone" and what it looks like in all kinds of different languages. Neat!

💬Discuss: Twitter

Get inspired with these app ideas

Learning is already hard, and trying to think of ways to apply your learning can often be even harder. Instead of doing everything yourself, why don't you check out these ideas for apps to inspire you? Who knows, you may even make something successful with one of them!

💬 Discuss: Twitter

🎓 Career Development

A tale of two dads(or what to do when saying something silly in the workplace)

Whether you've called your manager dad like this Reddit user, or accidentally sent a message on Slack asking everyone to give you a sex (sec), the most important thing to remember is everyone makes mistakes!

"Why did this take so long, you only added two lines of code!"

Regardless of what we may think, a lot of people outside the industry seem to think that the more lines of code you write, the more you are actually contributing to the product/project/company/happiness-of-manager. Here are some things you can say when someone asks why those 2 lines of code took an equal number of days to write.

🤔 Miscellaneous

Some portfolio advice by a veteran

Twitter user and industry veteran Dan Spratling recently took it upon himself to shell out some advice regarding dev portfolios. Read on and you might find something useful for your own site.

How to structure Express apps

Kent C. Dodds, JS teacher and Twitter afficionado, shows us how he structures his own Express apps. This is a very useful guide for both those of us just starting our Express journey, and those who may wish to check out a different opinion.

Careful when using the target="_blank" attribute

Something that happens very often in web development is that we tend to forget how important the basics are, especially when it comes to security. In this case, let's remember how important it is to use the target="_blank" attribute safely.

💬 Discuss: Reddit

Want to help us improve? Give us a shout @synk_sh

Launched Synk - A newsletter for web developers!

Ed — Sun, 28 Jun 2020 16:02:16 +0000

Hey everyone! We're two web devs (junior and lead) who have been working on this for the past few months and we're really excited to finally show it all off!

We started Synk because we want to give back to the community and also learn ourselves. Here's where we're hoping Synk can provide value to web developers:

Take the anxiety out of trying to keep up to date with the latest news in our ever-evolving industry.
Expose developers to a wider range of technologies that would allow them to become more well rounded and at the very least hold a conversation with someone using different tech.
Help junior developers broaden their horizons and sound smarter during interviews 🤓

Our first issue is due to come out in a few weeks time and we'd be really happy to hear any feedback from anyone and everyone 🙏

If you have any questions, be it Synk or generic web dev, do not hesitate to reach out!

We are also on ProductHunt and IndieHackers!

Forem: Ed

The Unarchitecture

Building a Barn With a Golden Hammer

What Exactly is Unarchitecture?

Where and How Does it Happen?

Preventing Unarchitecture

Closing Note

Notes on Promises and Useful Snippets (ft. async and await)

What Exactly is a Promise?

Useful Snippets

Promise Chaining

Error Handling

Using .then() and .catch()

Using try and catch

Using await and .catch()

Parallel Execution

Racing

Sequential Execution

Closing Notes

Further Reading & References:

Mozilla layoffs 🦊, COVID19 tech industry 🦠 and a bit on side projects 👷‍♀️ - Synk #4

📰 The News

🔭 Code Discovery

🎓 Career Development

🤔 Miscellaneous

Arctic Code Vault, GitHub ReadMes and Svelte - Synk #3

📰 The News

🔭 Code Discovery

🎓 Career Development

🤔 Miscellaneous

Enjoy the content?

Synk #2 - 🏦 Barclays, 🐘 PHP and ⛓ Safe Links.

📰 The News

🔭 Code Discovery

🎓 Career Development

🤔 Miscellaneous

Launched Synk - A newsletter for web developers!