Calling all devs: View our old source code

Since 2002 we’ve developed custom software for LB, whether that’s for the site itself, to customise third-party forum software we used to run, support migration efforts as we moved from code-base to code-base over the years or various other utilities and web-services for our different projects.

We’re now running LB on an open-source discussion platform so there’s no huge amount of development for us to do, which is great as we became more and more resource constrained as the years went on, because… life. We’re still coding, still working on things such as a new galleries site and what-not.

Over the years we must have written hundreds of thousands of lines of code (perhaps more) and created untold number of graphics and HTML designs. Rather than let it all die a death hidden away from everyone I thought it would be nice to put it out there for posterity.

With that in mind, you can find all the source-code for our historic projects on GitHub now:

We’ve got on there, source code for:

  • The original LB website (V5)
  • The forum-only LB website (V6)
  • MotoProfessional (our photography sale website)
  • Stolen Vehicle Database (SVD)
  • Email Loader (helped automate editorial publishing to LB)
  • MotoFeed (a project we didn’t finish)
  • VehicleDatabaseWebService (VDWS - used by SVD)
  • Other utilities
3 Likes

V5 was my favourite of the LB websites. I regret moving away from this. We should have just modernised it.

well here’s a question: I believe in the single page site I feel it’s the optimum solution (at times unattainable potentially so an ideal case). Looking at V5 there does appear to be lots of static loaded tabs - how would you modernise? It’s looking like a major rewrite either way, a dashboard with news, gallery etc widgets?

1 Like

The value of the V5 code-base is it’s very mature Content Management System in the middle-tier, the application that acts as API and data abstraction layer. Without considering whether it would be viable, i.e. a desirable service or even if migrating to a different product like DNN, Umbraco etc would be a better course of action, as a mental exercise, if we were to consider modernising it then I would consider the obvious goals to be:

  • Give it a first-class mobile experience
  • Give the photo galleries a slick, ultra-high definition experience
  • Make the editorial compliment video components
  • Trim off the other outdated aspects, i.e. directory

So I’d probably approach it like this:

  • Create a new Web-API for the CMS (application tier), say .NET Core Web API
  • Move file storage from local files to cloud storage
  • Create the front-end app that consumes the API from your favourite poison
  • Configure the front and back-end to use OpenID Connect to authenticate users against our IDP
  • Consider either containerising the app or using a managed platform like Azure Web Apps

So many good front-end options nowadays, i.e.

  • An SPA architecture
  • An MVC architecture
  • A Web-Assembly architecture, aka WASM (server or client side), i.e. Blazor

I’m leaving out the huge amount of complexity in the front-end here. It’s a minefield. So many options, so many ways to think you can save time by using open-source components and so many ways to find you need to develop something bespoke or try and customise the hell out of that open-source component only to bin it because it doesn’t work (been there more times than I’d like).

Regarding the WASM architecture - I’m starting out on building a new web-app atm for the galleries using Blazor (server-side mode).

1 Like

Interesting reading, I’ve got some blind spots here I’ll get googling

The mobile experience was the weak point.

As for the directory I’d keep it because people still ask questions “I’m in se of London where can I get an MOT”. A community driven directory would be great.

2 Likes