I chose Electron to create an invoicing app for my partner because I wanted to store customer data locally so that I didn’t have to worry about doing authentication to protect the data when trying to access it over the internet.
Initially, I used Tauri because I’m keen to become more proficient with the Rust programming language. With Tauri, I could easily use my current favoured frontend technology Svelte (more specifically using SvelteKit) as they provide simple setup instructions for using the two together.
I recently worked with the internationalisation library i18next to add multiple language support to an app. In the process, I found myself needing to convert data between two different formats:
JSON key-value pairs used by i18next to match keys to their respective translations. Spreadsheet data with matching translations to their english counterparts (essentially CSV). Example JSON data:
{ "foo": "Translated Foo", "bar": { "baz": "Translated Baz" } } Corresponding example CSV data:
Finding my passion for software engineering late (in this case meaning a few years after college) meant that my first real taste of a programming language was with JavaScript. I went through a career transition like many others with a bootcamp, which focused on teaching us skills that could be immediately applied to real jobs, i.e. JavaScript (also React, but it really is just part of JavaScript). However, I wasn’t satisfied with what I was learning; I wanted more; I wanted to learn what goes on in the layers below that have been abstracted away from us.
The first thing I learnt from this project has nothing to do with software. It’s that asking the right questions can make a huge difference to how I feel and how I approach the problem at hand. I eventually landed on figuring out how to call C code from Rust as the first problem to solve.
Asking better questions Having no experience creating command-line applications, I was at a loss for where to start.
I want to build a terminal application for myself to solve a use case that I have. (I’m also using this use-case as an excuse for me to learn and write more Rust!) However, instead of just building it, I want to try something new. Going with my theme for 2024, I want to try writing about my process of building the app as well. More creating, so I’ll code AND write!
At the end of 2023, I left the company that first kickstarted my journey as a software engineer due to my disagreements with the company’s culture.
I learnt plenty from my first stint, picking up skills and technologies far beyond what my bootcamp and personal learnings had taught. Docker, microservices, Expo, and React Native were some of the additional technologies that I picked up within the first month just to be able to make useful contributions to my team.
More less; less more.
That is my theme for 2024. For the past few years in my life, I have been focusing on more of everything. More learning; more reading; more coding; more working; more consuming; more creating; more knowledge gathering.
This is in large part due to my current position in life. I recently switched careers to be a software engineer, and while I love it, I also realised how far behind I was compared to my peers, especially those who have been developing software since they were young.
Introduction Setting up a debugger was not easy or straightforward for me. Nothing works out of the box as compared to common IDEs, such as VS Code, so there was plenty of learning needed to get me to my current point. I wrote this piece in hopes that it might help someone else understand a little bit more about debuggers through trying to set one up for their own Neovim configurations too.
I came across this saying from ThePrimeagen, that as a software engineer, we should not ask for permission to do things. Instead, when we see a potential solution to a problem, create prototypes to show others the solution. Then, if things don’t work out, ask for forgiveness. This is in contrast to asking for permission to work on a potential solution before actually getting down to creating anything.
The reason given is that it is difficult for others to fully understand your ideas from an explanation with only text.
I’ve recently become a software engineer after a career switch from marketing. In my short time so far, I’ve come to realise the importance of writing regularly.
Clear communication is an essential part of any work, but even more so in software development. We interact with computers that understand code, not the communication that we’re used to with other fellow humans. The nature of code makes it such that we need to be highly specific with our instructions for the computers.