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](https://test-track.io) and [Crash Catch](https://crashcatch.com) 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](https://crashcatch.com) 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](/api/images/109)

Below is an example of a crash report from Crash Catch

![image.png](/api/images/111)

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](/api/images/113)

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](https://udemy.com) 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

Devso in 2022 and what 2023 has in store

Me and Devso in 2022

Providing support to customers and users is one of the most, if not the most important aspect for something to be a success.

Providing support has the potential to make or break a company. If a customer has an issue and support is handled well, they’ll likely trust you and continue further business, however, if the provided support is poor, its likely that the customer won’t do business again, especially if they are a new customer and that was their first interaction.

Therefore, having been involved with support for the best part of a decade as part of my full time job, I strive to provide the best support for customers and users of Devso products and services, and with this, I’m making some significant changes to what we currently provide on our support portal.

Devso Rebrand
-------------

One of the reasons for the new support portal is due to the rebrand that was done this year from Boardies IT Solutions (you can find more info on our [blog post](__GHOST_URL__/boardies-it-solutions-becoming-devso-in-2022/)).

This new support portal however, is going to be more than just a reskin of the original to make it Devso, it instead is going to be a complete rewrite, with improved features, management and ease of use.

What's Changing
---------------

The existing support portal, which is still currently at [https://support.boardiesitsolutions.com](https://support.boardiesitsolutions.com), is to be honest, a bit sub par and some of the fields don’t make sense to the end user to fill in for certain products and services.

Let’s say you are raising an issue for [Crash Catch](https://crashcatch.com). For those that don’t know, [Crash Catch](https://crashcatch.com) is my simple and affordable, cross platform crash and error monitoring service, supporting platforms such as, ReactJS, PHP and Flutter to name a few.

When you want to raise a support ticket for Crash Catch, by going to [https://support.boardiesitsolutions.com/support](https://support.boardiesitsolutions.com/support) you are presented with the following form:

![Current Support Portal - Raising New Support Ticket](/api/images/87)

Current Support Portal - Raising New Ticket

Now to some degree, this form makes no sense for Crash Catch, there is one platform (the web app) and one version (what’s currently installed and available to users) so when you select the Software dropdown to be crash catch, you still have to select the platform and version, although there’s only one option available on each, the platform is “Web Service” and the version is “Current Version”.

This is probably somewhat confusing so this is the first area that I’m improving.

The new support portal will look something like below (bear in mind this is still early on in the development so this is very likely to change before it gets released)

![New Support Portal - Raising New Ticket](/api/images/88)

New Support Portal - Raising New Ticket

When the page loads you just get one field, the service/app selection that you want to raise a support ticket against.

In this example, Crash Catch has been selected and the rest of the form is loaded, however, in this case, the platform and the version don’t get shown, as the support portal backend knows these fields can only be a specific issue, the API tells the frontend that it doesn’t need to display them, allowing the user to concentrate and just fill in what’s relevant, the support portal handles the rest.

You’ll also notice, that the ticket raise form is a bit more dynamic, when you select the service, it shows on the right hand side the service logo, a bit of information regarding the ticket and a link to the documentation site, not to push you away from contacting us, but just a piece of information in case what you are looking for is in the docs.

Portal Registration
-------------------

You might have noticed in the screenshots above, that the new version has a login and register button. This is to streamline the ability to raise support tickets, issues or feature requests and allow you to view and manage past things that have been raised.

![Support Portal Registration](/api/images/89)

Support Portal Registration

On the current support portal, there is no account required to raise anything on the support portal, and this will remain the same on the new portal, however, you can register for an account.

The support tickets remain private between yourself and Devso (raised issues and feature requests are public and available to anyone visiting the support portal).

If you raise a support ticket as a guest you won’t have access to update the ticket or further communicate on the ticket via the portal. Instead, the support portal will notify you via email about any updates to a ticket and you can reply to the email in order to update the ticket.

If however, you register for an account, any time you raise a support ticket, issue or feature request, you do not need to enter your contact information each time, plus you’ll be able to see a history of all of the support tickets you’ve raised, as well as update the support ticket and send us messages (you can still reply to the email notifications as a guest user can) and see a history of how the ticket has been progressed.

Issues & Feature Requests
-------------------------

At the moment there’s not a huge amount to say about the issue tracker and feature requests at the moment. The support portal is very early in the development so this part has been started yet, but the basis is these two areas are public. Therefore, the issue tracker and feature requests are available publicly on the support portal, anyone will be able to view them and comment them. This will work as a type of road map and priority list of what I should focus on on the development of projects and services for Devso.

As mentioned above, I believe support is one of the most important aspects of providing a web app, service or API and we want to get your feedback on what you would like to see on the support portal and I’ll continue to write blog posts on the progress of the development.

Current Support
---------------

At the moment the support portal will stay on [https://support.boardiesitsolutions.com](https://support.boardiesitsolutions.com) and emails to [support@boardiesitsolutions.com](mailto:support@boardiesitsolutions.com) are still working. Emails will be automatically forwarded to [support@devso.io](mailto:support@devso.io) and that’s where replies will be sent from.

However, email notifications from the support portal will continue to be sent from [auto-reply@boardiesitsolutions.com](mailto:auto-reply@boardiesitsolutions.com)

Once the support portal development has completed, the [support@boardiesitsolutions.com](mailto:support@boardiesitsolutions.com).

Service Status
--------------

The service status pages at [https://status.boardiesitsolutions.com](https://status.boardiesitsolutions.com) are in the same situation as the support portal. Once the support portal has been redeveloped, the service status pages will also get redeveloped and rebranded for Devso at which point the domain will be moved under the [devso.io](http://devso.io) domain, and the [auto-reply@boardiesitsolutions.com](mailto:auto-reply@boardiesitsolutions.com) will be official shutdown in replace of [auto-reply@devso.io](mailto:auto-reply@devso.io).

Nearer the time of development, we will have more information on the next steps of the service status.

I appreciate your patience while we go through this transition period and I’m doing my best to ensure that it goes smoothly.

Improvements to Support Portal

I've had Boardies IT Solutions ([https://boardiesitsolutions.com](https://boardiesitsolutions.com)) since the beginning of 2010. I got this when I was at University and used it to host multiple projects and news about future projects and this is going to continue, however the name Boardies IT Solutions will be no more, instead I am introducing the name **Devso**.

![Devso New Logo](/api/images/82)

So why the name change? While I was at university, Boardies IT Solutions was more of a portfolio site for finding a job and showcasing what I've worked on, although this is still going to be primarily the case (not the job hunting side so much), but I am trying to actually sell services and push the name more openly than I was previously - hence you may have noticed the blogs have been more frequent as well as the Twitter account and doing the whole build in public which seems to have become more popular and being open about what I'm working on, what issues I've had along the way and what's gone well, but recently while doing this I've found Boardies IT Solutions to not be the right name for a number of reasons.

First of all, Boardies IT Solutions is a bit of a mouthful, most company and/or product name are rather short snappy names, and it was so long that Twitter handles and Facebook pages didn't fit, that's why the their both call "Board IT Solution" instead of "Boardies IT Solutions". Also, being called IT Solutions made it sound like I was providing IT systems such as computers and network solutions which isn't the case.

I haven't got an exact date but Boardies IT Solutions will slowly be phased out over the course of the next few months while I rework the website. Initially, [boardieisitsolutions.com](http://boardieisitsolutions.com) will likely just redirect to [devso.io](http://devso.io) the new domain until I get that reworked, along with a new and hopefully improved version of our support portal. Speaking of which, if there's anything you don't like or would like to see on our support portal, then please let me know and I'll see if I can implement it.

Facebook and Twitter pages will hopefully be switched soon, just in case someone tries to take the account after seeing this and everything else will transition into the new year depending on how long it takes me to rework them.

So in case there's any concerns, what I do isn't going to change, my focus is still to continue developing mobile apps, web apps, APIs and software to help my users and fellow developers. [Crash Catch](https://crashcatch.com) is currently still my focus though but I do have some other projects in the pipeline to hopefully start in the not too distant future (can't keep all your eggs in one basket after all ? ).

I am always looking for the next project id and trying to keep on top of the latest technologies where appropriate (easier said than done though) and I can't wait to see what the future holds for Devso and I hope you are just as excited to see what's next.

Thanks

Chris

Devso Blog

Tagged

devso

Me and Devso in 2022

Improvements to Support Portal

Boardies IT Solutions Becoming Devso in 2022