Me and Devso in 2022

Chris Board

Jan 07, 202310 min read
devso

It doesn’t seem that long ago, but its that time of year where its time to write a blog post detailing how its gone for myself and Devso in 2022 and what you can export, or at least what I hope will happen in 2023.

Devso Blog

While looking at this blog to remind myself what happened this year I realised I haven’t been writing as many posts as I should have done. That’s something I want to improve in 2023 and write more blog posts showing the development journey for Test Track and Crash Catch along with decisions and future plans for these projects and other projects.

I also want to improve the functionality of the blog by allowing users to be able to register their emails so when I post a new blog it sends you a notification of a new post making it easier to keep track of any updates I have.

Devso Rebranding

Early on in 2022, brought the introduction of Devso, a rebrand from the original name, Boardies IT Solutions. One of the reasons I chose to rename was, one, Boardies IT Solutions, was a bit of a mouthful, but also, it didn’t give the impression of what I am actually doing, it sounded more like I was an IT solutions provider where I go on site and install a computer system of some sort rather than developing software or websites.

Crash Catch Gets New Subscription and Overhauled User Interface

Also early on in the new year was a new release to Crash Catch which provided a new Pro+ subscription allowing 1 million crash and error reports a month, as well as an overhauled and (hopefully) improved user interface to make it simpler and cleaner to view and manage your crash and error reports.

The Future of Crash Catch

This is a difficult one as I am undecided what to do with Crash Catch in 2023. I am torn whether I continue with it and carry on with what I planned to do, which includes adding more libraries, such as for NextJS, Laravel, C# etc and creating a dedicated mobile app to name a couple or shutting down the service.

So why am I considering shutting down, its been going for around a year and its had 11 users signup, only 1 of which was a paying customer and they only lasted 6 months. I know the reason however, it wasn’t a fault with Crash Catch, they were on a pro plan which had 100,000 crash and error reports per a month, and they would send 100,000 crash reports within one and a half days, so further crashes don’t reported as they are over quota for their subscription. They used to email every month asking why they weren’t seeing crashes and explain they were over the crash report quota and they could upgrade to the pro+ but they ended up just stopped paying for their account.

The other users that signed up, would sign up, create a new flutter project and then successfully initialise the library and then do nothing else and their trial ended, and no feedback was ever provided - I did try contacting each one but never heard back.

So with the lack of users, and the lack of feedback I am not really sure, one if there is any interest in Crash Catch or what direction to take it.

I recently switched one of my projects from using Crash Catch to use Sentry instead and I found Sentry to be so cluttered with unhelpful info (why do I care about the users ip address for example) so I am still undecided with Crash Catch.

Below is an example of a crash report from Sentry.

image.png

Below is an example of a crash report from Crash Catch

image.png

The other issue is around the ReactJS crash reports. In case you didn’t know, ReactJS when built for production is minified and therefore crash reports by default aren’t really that helpful. To get around that is a source map which provides information as to how the code was minified and the source map is uploaded to crash services such as Sentry or Crash Catch use the source map to decode the minified crash stack to a human readable form of the stack trace showing you exactly in your code where it crashed.

At the moment, to do that, I am using a third party NodeJS library, that is no longer maintained, which although is working is not ideal but so far have been unable to find how the source map decoding actually works, so I’m torn whether I keep Crash Catch and try and find how the decoding it works, or reverse engineer the library I am using to reimplement it directly within the Crash Catch engine. The reason for that, is the Crash Catch engine is C# .Net Core application, and due to the third party library being Javascript, I have a separate NodeJS application which the .Net Engine sends a request to decode the stack. Although this happens pretty quickly, its a point of failure and some amount of latency, for the engine to send the request to the NodeJS app and get a response instead of the engine being able to do everything itself directly.

Do you have any suggestions or ideas on what I should do, let me know in the comments below or send me a DM on Twitter (https://twitter.com/chrisboard_).

Learning New Technologies

As part of my full time job, we recently started using Vue and Laravel. Although I never really liked Vue myself so not using that for personal projects, I did start using Laravel as instantly fell in love with its simplicity and how it keeps a project well structured and organised. The database management ORM (Eloquent) was the first experience I had with ORMs and it was great and massively simplified and reduced the time it took to develop and perform database operations over writing pure SQL and not needing to worry so much about SQL injection as that is all handled by the ORM.

I fairly quickly transitioned existing projects such as Devso support portal and service status to use Laravel for the backend API, as well as Crash Catch, all of which previously was written in vanilla PHP. All new projects also use Laravel for the backend API with a React frontend.

Another thing I learnt a bit more and want to get more involved in is NextJS. This blog is written in NextJS and was the first project I did properly. I previously tried NextJS but never got on with it (I did a post about it on Indiehackers.com which can be found here (https://www.indiehackers.com/post/my-recent-experience-with-nextjs-nextauth-on-a-new-project-37ca6a4309).

However, I assumed I must have been missing something as more a less everything I see on Twitter and Indiehackers is showing how good NextJs is.

My main problems I had with it was compared to Laravel it wasn’t as simple and convenient to create pages and routes etc. Laravel has a bunch of commands that automatically create the file and scaffold the bear minimum you need such as the class definition, the imports etc. NextJS doesn’t have that, (as far as I am aware at least) so you have to remember or copy/paste from an existing file the required imports and function definition and parameters required which slows the development slightly.

I was also using PrismaJS for the database ORM and although this worked well, I was constantly having issue with my IDE (PHPStorm) not detecting changes within the prisma schema. I thought this was a bad quirk of how Prisma work but have recently realised its actually a fault in PHPStorm not detecting the changes - this issue doesn’t happen in VSCode - although I am not a fan of VSCode.

However I gave it another try and this blog is actually developed using NextJS and PrismaJS with TailwindCSS for the styling.

I plan to do another and larger project in NextJS as a trial and see if NextJS ever becomes my default stack for newer projects moving forward. I want to re-write the service status pages at status.devso.io as a trial. I’m not particularly happy with those pages at the moment, although functionally works but I think I could do a much better job with the user interface as I think my UI skills have improved over the course over the last year.

New Project - Test Track

In October of 2022 I released a new project to help developer and QA (Quality Assurance) testers called Test Track.

Although I got roasted slightly by a couple of comments on Reddit (that’s Reddit for you) making out that I didn’t know what I was talking about suggesting people don’t use spreadsheets to manage test plans I I standby the project as I know its done. Having over 10+ years working in a small software software company dealing with other SMB customers the test plans we, and our customers put together and share around are all done in spreadsheets that easily get bloated, hard to follow and quickly become clunky, and usually get out of sync as its passed around via email to different people, other people within a team (usually within the customers teams) aren’t looking at the latest version and you end up with several different versions of the same test plan.

I also used to use a spreadsheet myself to manage my own test plans for my own side projects, that why I built Test Track.

The idea is you create different projects, and within a project you create 1 or more test plans. A test plan can cover the entire project or split into different modules, such as frontend, backend, billing etc and each test step can be provided with detailed instructions and images to explain clearly to the testers what needs to be done and what is expected to happen. Then each test plan, you can trigger a test run where you can provide the state of each test step, and provide detailed description of went wrong so the developers have a clear and concise view of what the issue so they can fix it quickly as possible and make it available for retest.

image.png

I have a new version coming early on in 2023 which has significant user interface improvements based on some feedback and experience of using it myself that it was hard to navigate in some areas so hopefully made it simpler to navigate between projects, test plans and test runs.

What 2023 Has In Store

I have plans to continue with Test Track and continue to evolve it and try and get some more users. I also plan on doing a marketing course to hopefully do a better job at marketing Test Track and any other projects I might work on in the future.

I actually have marketing course I bought on Udemy for a while but not had time to go through it but hopefully that won’t continue in to the new year.

Also as I mentioned above, I plan on doing a better job at writing posts for this blog as I have done very posts in 2022 and want to improve the blog further by allowing you to receive notifications of new posts.

I also plan on hopefully growing my Twitter audience (https://twitter.com/chrisboard_) and provide more updates of the development progress and hopefully that will tie nicely into doing more blog posts as well.

I hope everyone has a happy and successful 2023 and look forward to seeing what the year brings.

Chris Board

Test Track

Are you a developer or involved in Quality Assurance Testing or User Acceptance Testing, you might be interested in Test Track

A simple and affordable test planning and management solution.