DEV Community: Michael Simmonds

Shortening import paths (path aliases) in vite-react-ts with NX mono-repos.

Michael Simmonds — Fri, 15 Nov 2024 12:01:54 +0000

The aliases (shortened paths) need to be set in both the root tsconfig.base.json and vite.config.ts files.

vite.config.ts will be used at compile time to tell the vite compiler where your files are located. Its critical that both are set up correctly.
tsconfig is required so typescript knows where the file can be found for intellisense and automatic imports.

The way tsconfig.json files extend one another can cause confusion when setting up path aliases in monorepo projects. Therefore its critical we add out aliases to the tsconfig.base.json file in the root of the mono-repo, not in the tsconfig.json file found in individual apps.

The "extends" property of a tsconfig.json file is poorly named. The properties of the file being extended (often tsconfig.base.json) are overridden not extended.

To add custom path aliases the following pattern can be used.

1. Add the path alias to the tsconfig.base.json file in the root of the monorepo.

{
  "compilerOptions": {
    "paths": {   
      "@<project-name>/<import-alias>": [
        "apps/<app-name>/<path-to-dir>"
      ]
    }
  }
}

@<project-name>/<import-alias> is the shortened, readable import path you will use in your files. eg: import {FileName} from '@<project-name>/<import-alias>'
apps/<app-name>/<path-to-dir> is the directory that you wish to alias (relative to the tsconfig.base.json file location)

the @ symbol is not required, but it is the standard pattern to prepend the aliases when using nx.

2. Add a path alias to the vite.config.ts file inside the app(s) you will be using the alias.

import * as path from 'node:path';
export default defineConfig({
    resolve: {
      alias: {
        '@<project-name>/<import-alias>': `${path.resolve(__dirname, './<path-to-dir>')}`
      },
    }
});

@<project-name>/<import-alias> is the same alias as used in the tsconfig file and should match exactly.
<path-to-dir> is the directory which you wish to alias. NB: this is relative to the location of the vite.config.ts file so the path will be different from the one used in tsconfig.base.json. usually ./src/path/to/directory.

This setup should allow you to user shortened aliases, which act as absolute imports in your Vite-React Typescript projects.

Goodbye import {filename} from '../../../../relative/import/that/breaks/all/the/time'

Basic Mastering in Ableton

Michael Simmonds — Sun, 28 Jan 2024 20:30:26 +0000

Notes on the tips provided in this video:
https://www.youtube.com/watch?v=qrroYDVdPUc&ab_channel=AbletonTipsbyPML

Check you have headroom on the master track ~5db is ok
Add a limiter to the master track with lookahead to 6ms and the ceiling to -1.0db. Puch the gain until you can ear audible distortion. At that point, wind the gain back by 1db.
Then add 'ulene loudness meter' after the compressor. If you can't turn the gain on your limiter up and get to around 10Lufs without distortion, then you need to go back to your track and mix it better as one of the sounds is smashing the limiter and needs fixing.
Add an eq8 to the master track before the limiter. turn off the visualiser on it. We'll come back to this later.
Next we check the mono and mid/side mixes separately. Set 2 utility plugins on the master track, one with the mono button pressed, one with the mid/side knob turned up to 100%. Now we can listen to both individually and hear what might need to happen in the eq we just added.
Start with the mid/side. Listen to it and see if its muddy (it often is due to stereo effects bleeding into each other. If it is muddy: turn off the mid/side utility first then set the eq8 to mid/side mode and set a low cut. move the low-cut freq up and down until the track looses its warmth, then pull it back a little bit. Then listen out for elements in the mix that are too forward, or causing mud and use a band-cut to remove them. Eq it up, small changes, this is mastering, not creative.
Add a glue compressor after the eq and before the limiter. Set the eq on the glue compressor to the fundamental of the kick (use a spectrograph to find it) Set the q quite tight ~3. Set attack a bit slow ~10 and the release fast to about 0.10. Pull the threshold down until the kick sits in the mix better and feels cleaner. N0 makeup gain.
Add another eq after the compressor and use this as makeup gain. add gain to it based on how much you lost in the compressor (see the meter) then add a little light eqing as necessary. We now have a clean sound and can boost it.
Finally add another compressor at the end of the chain after the one we previously added. Set the set the old one back to 0db ceiling and the new limiter ceiling to -1db with 1.5ms lookahead. Push the gain until you hear audible distortion and then pul it back by 1db as we did before.

You should be able to et to -8db LUFS with this. if you cant you may need to think about your mix again.

Long-list of questions to ask in interviews.

Michael Simmonds — Tue, 26 Sep 2023 08:22:58 +0000

This is a ever-growing collection of possible interview questions that may or may not be relevant for any particular interview.

Its intended as a kitchen-sink reference for use during interview preparation so pick out the ones you want based on the role and what you could not discover about the company before hand.

This is for my own use: You are more than welcome to reference it too - but there may be some parts that are less relevant to you and your roles.

Engineering approach

What types of engineering problems are you facing these days?
What is your team’s biggest current challenge?
What do you see as the engineering team’s role in the company?
What does a typical day in the life of an engineer look like?
How does the handoff between frontend and backend engineers work?
What testing frameworks do you use, what is the policy for testing and how do you mitigate the risk of developers cutting corners on testing when under time-pressure.
Whats your tech stack?
How is the interaction between developers and product managers?

Product / Project management

How do product, design and engineering collaborate to take an project from idea to deployment?
How much of a say do engineers have into the design/ux of products?
Is this a product-focused company or a service-based business?
How do you review your product roadmap?
What software do you use (this shows a lot about a company so its great if yo have experienced a few). How long have they been using it and is it used in all cases?
How much of the work is green-fields vs legacy application and how are developers assigned to each? Do the old-guard get all the new projects?
Do you have a standard release cycle? (shorter cycles more testing)
How do you deal with tech dept? Is time set aside for tech dept?
What do you do when things go wrong? For larger issues do you have retrospectives?

Role progression & Performance

If I were to get this position, how would my performance be measured? How often are roles reviewed, and what is the mechanism (Personal Development meetings?)
If I exceeded the expectations for this role in 6 months, where would you see me going from there?
What qualities will I need to have to be successful in this position?
How would you describe a 10x employee if one existed?
Would my compensation be tied to performance or mostly title and responsibilities?
Why are you hiring and what do you hope to achieve by hiring for this position?

Professional/Career development

How do you ensure the success of new employees through your onboarding process?
What are the learning / career development opportunities available to your employees?
Are there opportunities to switch roles internally inside the company down the road? Or do you tend to hire externally?
Where have previous successful employees in this position progressed to?

Work culture / Team

Everyone likes to talk about work/life balance - what is your take on it?
Have you ever seen your CEO or other leaders admit when they were wrong, own it, and make changes?
What are the company’s top 3-5 values for their employees?
Would you consider your company to be “remote first / friendly”? What does that look like?
How would you describe the work environment here—is the work typically more collaborative or more independent?
How many meetings do developers have? Do developers interact directly with clients and stakeholders, or do they need to go through a PM?
Why do you like working here?
What is the teams biggest challenge?

Product market fit / unique value proposition

What makes you better than all your competitors?
What problem are you solving that no one else is? (eg. your unique value proposition)
Where do you see the company growing towards in two to three years?
What can you tell me about your new products or plans for growth?
Who is one of your biggest competitors in the field and what is something they do better than you?

Financial health of the company

What is your net revenue retention rate?
What is the company’s burn rate / runway – eg. how long they can operate without running out of cash?
How much money has your company raised?
When do you expect the company to be profitable if they aren’t already?

Credits:

Claeb Mallas: https://levelupsoftwareengineering.substack.com/p/35-questions-to-ask-while-interviewing

Time, quality, cost triangle when the client can't choose.

Michael Simmonds — Thu, 02 Mar 2023 09:26:33 +0000

The time/quality/cost triangle is well know as a good way to decide where flexibility is in a project.

In short, the client decides on one of these if is the most important to the business and the other 2 are given more flexibility as specifications and timelines wander.

Sometime clients refuse to pick one, and say for example: they need time and cost, but will allow for lower quality. this is not enough room for manoeuvre on a project as complex as a web application.

Therefore:
Only quality is flexible:
The app produced is agreed to be rebuilt properly after a pre-determined time limit (1 or 2 years probably).

This time limit could be discussed at the time, but deciding this up front allows the client to manage costs, rather than devs coming back after 1 year and telling them that they need a rebuild - because the app has become unmaintainable (and this was predictable a year ago!)

Be wary of people thinking/pretending this is the same as Agile! It is absolutely not.

Only Time is flexible:
The app to be produced does not have a fixed deadline, and the client expects longer response times, and does not decide on a launch date until after the app is completed.

When both quality and time are constrained the company ned the flexibility of allowing devs to move to other projects and deprioritise the one with the flexible time-scale. Having any kind of launch date planned before the app is completed and signed off is a fools errand as it will almost always be missed (and this was predictable at the start of the project!)

Only Cost is flexible:
The price is not determined before time and the client pays whatever costs are generated whilst trying to rush a high quality app out of the door, even if estimates are inaccurate.
Cost estimates for features cannot be enforced, as more developers will need to be drafted in to finish the app in time. Cost-flexible clients would receive the developer hours from projects whose time is flexible to allow cost saving for the time-flexible projects and time-saving on the cost flexible projects. Csots on these projects can spiral and its imperative that the client is planning for this. Its not fair to wait until the crunch of a project and say that you have run out of budget. The client needs time to gather budget (and this was predictable at the start of the project!)

Setting up an Angular project with Angular cli, GitHub cli and deployment to GH Pages

Michael Simmonds — Wed, 15 Feb 2023 13:57:34 +0000

This guide uses Angular cli, git cli, GitHub Pages and a package called angular-cli-ghpages

Prerequisites:

Angular cli (this example uses Angular 13)
Github cli ( this example uses v2.4)

In your workspace spin up a new angular app with:

ng new <app-name>

This will prompt you to create a new project, set up a local git repo and make an initial commit for you.

To create a new repo on GitHub with the command:
gh repo create

Select 'Push an existing local repository to Github` and follow the interactive prompts.
The repo will need to be public unless you have GitHub Pro.
When offered, set up a remote,
This will create a github repo for your project and set up the remotes so you can push to it easily.

Now we add the angular-cli-ghpages package. Note the use of ng add, not npm i.
ng add angular-cli-ghpages

Add a script to package.json to simplify deploy.

Open package.json.
In the scripts object add a new line: "deploy": "ng deploy --base-href=/<your-repo-name>/"

Commit your changes to the main branch
git add .
git commit -m "added angular-cli-ghpages"
git push origin main

Create a new branch called gh-pages (this can be customised, but you will need to select a different branch in the github settings page mentioned below)
git branch gh-pages
git checkout gh-pages
git push origin gh-pages

Set up GitHub Pages in the browser (just need to check this - it should be setup in the correct way by default)

Find the repo you just created on GitHub.com
Setting > Pages
In Source select deploy from branch (automatic)
Under branch select gh-pages and /root (automatic)

Finally - its time to deploy the base application
git checkout main
npm run deploy

NB: The deploy script will build your application and overwrite the contents of the gh-pages branch with the compiled build. There is rarely any need to have the gh-pages branch checked out locally, so I suggest you delete it.

If all is well - your application should be deployed to http://<gh-username>.github.io/<repo-name>

Consistent architecture is the cornerstone of confident testing.

Michael Simmonds — Mon, 09 Jan 2023 15:20:49 +0000

This post is about the importance of good architecture in the path to creating testable applications. Well architected applications allow a team to work quickly and confidently whilst focussing on the task in hand, rather than worrying that their changes may break existing features.
A consistent approach to UI architecture and creating features is required before you are able to get the most value, and confidence out of the tests you write.

Quality takes time iterations.

Although consistency is important, it is not necessary to have the perfect UI architecture that will last forever straight away - so long as it is considered and documented, a feedback process of working and improvement can begin. Its important that any decisions have buy-in from the whole team - therefore be sure to keep everybody as involved in the process as possible - as they will be the ones giving you feedback to improve further down the line.

The importance of framework and tooling agnostic architecture

Anyone who has worked in the industry for any length of time will be aware that the fashionable frameworks and tooling of the time change rapidly. There are use-cases where certain tooling is critical to the success of an application. These cases will be picked up during the specification stage and the temptation to add tooling should always be tempered with the question: "Can this problem be solved with a better architecture rather than tie us into a tool".

Architectural design thinking

At the core of good design is creating something that works well without much thought. Don't make me think by Steve Krug and The design of everyday things shows these principles in the realm of visual and product design, but the principles are universal.

Separation of concerns

Separation of concerns is critical in designing good software as it is universally applicable and forces you to really think about what you are doing, where and why.
Thinking should be done about the problems involved, but not about the framework itself.
Split the problem into primary concerns
Presentation concerns, Business concerns and Data concerns

Architecture as a cornerstone

In the context of stone masonry cornerstones are the most highly engineered part of a structure. They only make us a small amount of the physical size, however they are completed by the most skilled masons. Strong cornerstones allow the other people working on the structure to build the walls between them more quickly and creatively - without risking the structural integrity of the building.
In the context of development Cornerstone architecture sets the context for the stability of the system. Once these cornerstones have been put in place, the system can be consistent. Having these constraints in place actually improves creativity as you can go any way you like - so and remain confident that the wider product will not be effected.

The pit of success

An honourable mention goes to an article called Falling into the Pit of Success by Jeff Atwood. It is very relevant here as once a team has a strong architecture that they can all work within, they will fall into the pit of success and be able to work more quickly and more confidently in their roles. This breeds a feeling of confidence, self-reliance and developer-happiness which in turn will lead to a better ed product.

Although this is not a practical guide by any means, I hope that the information has inspired you to create more consistent architectural cornerstones that allow your team more flexibility and creativity as they work.
As always I appreciate feedback and this article is a never-ending work in progress, so feel free to start a discussion and we can all learn from one another.

How I approach testing in Angular and React.

Michael Simmonds — Sun, 08 Jan 2023 19:09:24 +0000

Testing is not fun, does not add value to the end user and should be avoided..

However:

Manual testing sucks more than writing automated tests.
Writing tests for code you did not write is awful.
Working on code that has no tests requires a full understanding of every use-case which is a costly overhead and can lead to unanticipated bugs.

What type of tests are useful in the front end?

There is some ambiguity in the terms used for testing, so your team may use different definitions, however I find the definitions below are sufficient.

End to end. Runs commands using a browser and a real API connection. They are to test user stories and covers a lot of different components and their interaction together. A single e2e test can save a lot of functional and unit testing so should be preferred. I like Cypress.
Functional testing. Used to test components using a virtual dom without a browser. API calls and other external dependencies should be mocked. Here we are testing the functionality of a component or group of components, not the implementation. I like Kent C Dodds testing-library.
Unit testing. Tests the implementation of a component or function. Only complex business logic or utility functions are worth testing. Functional and e2e tests more accurately mock the users experience and should be preferred. Other types of test offer much better bang-for-your-buck so let's not spend time testing the implementation of every minutiae.

What should be tested?

Critical user paths such as login and store checkouts. (using e2e testing)
Things that the PM or Client always monkey test (to save them time). discussing this with the also highlights critical application areas that may not be obvious to the developer. This is a great way to convince managers to allow you time to test the application, as they will be saving time themselves! (using e2e and functional testing)
Things that suck to test in the ui. For example things that render based on slow api calls. It's faster to write the tests than monkey test during development. (Functional testing)
Reusable components or libraries that are used across projects. Thorough testing here adds significant value as one test covers many projects. These are treated as dependances and should not be re-tested in the project that consumes them . (Functional and unit testing)
Complex or critical business logic. For example break a complex sorting function into its own file and cover with tests. This conveniently documents the sorting function and means any changes to the spec can be implemented with more confidence. (Unit testing)

Finally:

Is there any point if the client or PM will manually test anyway?
Yes, let them test. If your tests are good they should not find anything unexpected. If they do find something then this will highlight issues at either the specification phase, or your tests where not accounting for all of the requirements.
These feedback loops are central to good software development.

Thanks for reading - I try to keep these posts as terse as possible but if you have any questions or think that something is just plain wrong. Please comment below so we can learn from one another.

Omnisharp not working in vscode - fix

Michael Simmonds — Thu, 15 Sep 2022 15:33:17 +0000

My intellisense for vscode suddenly bailed out on me:

Before we start mucking about too much let's try some standard things to get it back up and running:

Reset the OmniSharp server - Command palette - OmniSharp: Restart OmniSharp.
Check that OmniSharp is looking at the right project - Command palette - OmniSharp: Select Project.

If neither of these work - follow on for another option:

Microsoft released a new version of the C# extension (v1.25) for vscode that breaks for older projects (the one I'm using is 2.1 :\ ). The tools required for it to work are no longer included in the extension - so you need to download them yourself.

In vscode go to settings (I used workspace settings) and search for "Omnisharp - use modern net" set this to off.
Mac: Download and install Mono that includes the build tools (Visual Studio Channel). Windows: Download and install Visual Studio MSBuild Tools or a full Visual Studio version.

Restart vscode. I had restart the OnmiSharp server (see above) even after a restart of vscode itself.

If this helps a single person I'll be happy - I lost hours to this!

Questions to ask when approached by a recruiter

Michael Simmonds — Tue, 22 Mar 2022 16:19:05 +0000

They promise the world - and before the ink is dry on the contract the cracks start to become apparent. You don't fit the company culture, all your colleagues wear suits whilst working from home and your CEO is a psychopath...

How can you improve your chances of getting a job you really love?

Mindset:

A recruiter's job is to recruit and they have little technical knowledge (and will often get it wrong [sometimes it feels deliberate])
Companies are desperate for hires and will bend the truth to get you onboard
Remember you're bending the truth too. It's important to be mindful that everyone in the room is trying to present the best version of themselves... and that's OK.

Questions that work:
Spend time writing out the questions that matter to you, from your experience in your professional life. I like to think of this kind of task as an improvable process - good quality questions will illicit good quality responses. Create a process improvement loop by taking careful note of the responses you receive to each question and then refine your questions based on the response by rewording, replacing or keeping each question.

Have a practice. Just try turning on 'open to work' on LinkedIn for a couple of days - it's likely you will be inundated with requests from recruiters for all sorts of roles. Use these eager-beavers to hone your questions.

So to put my card on the table, here are the first set of questions I will be responding to recruiters with:

What are the remote working arrangements at the company, and when did the company start remote working?
How big is the company? What is the turnover and how many employees does it have?
What is the time-frame for filling the vacancy and when would they like me to start work?
Is there a standard tech stack across the company or does it differ per project?
How is the company structured? As independently functioning teams or as a single structure with different departments (eg client management dept, operations dept etc)

I'll update with the responses I get, and how I use them to improve my questions.

Organising scss in Angular

Michael Simmonds — Tue, 15 Feb 2022 16:51:05 +0000

Styling in Angular can be a bit intimidating at the start. Hopefully this will shed a bit of high-level light on the situation.

There are 3 main places to stick your styles in Angular:

Component styles - Style encapsulated to the component.
Global styles - Styles in the global scope.
Dependency styles - mixins & variables that other stylesheets depend on

Component styles
These are the easiest to talk about so let's keep it brief. Angular uses the excellent Shadow DOM technique to allow us to encapsulate (protect from outside interference) the styles of our components.
Advantages:

This is the mechanism that allows us to create truly reusable components that we can reuse within the same app or in a different project.
This also makes styling much easier to read and reason about. As our component is only effected by the styles in the (nice and short) stylesheet and the very minimal global styles we may have.
It improves separation of concerns. The responsibility of styling a component should be with the component itself, as opposed to the wider app.

NB: Component style encapsulation only works within the component tree. Therefore global styles will still effect all components.

Global Styles:
These are the 'normal' way css works. All of the styles are bundled together from the styles.scss file in the project root and added into the head of index.html. You can find the global styles in the compiled output - its usually the last tag in the head tag and looks something like this:

<link rel="stylesheet" href="styles.081464a278750c3f7d11.css">

Global styles do effect all elements inside the app - so it is prudent to be sure anything you add there is truly global, and that a component intended for reuse won't rely on these to be able to render correctly.
I recommend to only have these files (or similar) globally available:

@import "./app/scss/reset"; <- reset browser styles
@import "./app/scss/typography"; <- add font-imports
@import "./app/scss/base"; <- add basic styles (like fonts)

The order of the imports in styles.scss is important.

Dependency styles:
Dependency styles are those that are references all over the app, in different feature modules and often in base.scss. These are most likely to be variables and mixins to keep the app consistent.
The reason that the variables and mixins are not in the global scope is that Angular will compile different style bundles for different lazy-loaded modules or chunks individually. Therefore if a module depends on scss $variables that are in the global scope, then the modules are not truly reusable. This is a bit of a point-of-contention as it could be argued that there is still a dependancy on the variables.scss file, however the variables should be considered similar to an API Interface as most components will rely on the --primary-brand-color regardless of which project they are in.
Dependancy style imports can be quite annoying as they can get very long, and need updating every time you move the component in the filetree:

@import "../../scss/vars/variables";

To fix this, an argument can be added to angular.json to let the compiler know where the stylesheets are. This is: stylePreprocessorOptions.includePaths and accepts an array of directories.
I choose to store all of my dependancy styles in a folder called "importable" as shown below:
json "projects": { "app-name": { ... "architect": { "build": { "builder": "@angular-devkit/build-angular:browser", "options": { ... "styles": ["src/styles.scss"], "scripts": [], "stylePreprocessorOptions": { "includePaths": ["src/app/scss/importable"] } },

NB: It is preferable for the scss stylesheets to go into a folder in the root of the project, rather than inside the /assets folder. The assets folder is generally reserved for public files, which doesn't really apply to your stylesheets!

As always - Thanks for reading - if you have any comments or corrections please give me a shout.