January 2022 on vAMSYS - Development Update

[Lukas Jankauskas]

Hello everyone! 

I apologise in advance - this may be dense, poorly spaced and in questionable grammar - living up to vAMSYS Standard 🙂

You must know the phrase - it can be done quickly, cheaply or well - pick 2. For almost 8 years, ever since I took vAMSYS, the code was written quickly and cheaply - I was under immense pressure to add features and functionality really quickly - back then vAMSYS replaced a somewhat fully featured airline management system for a shell of it. As I mentioned in the past - foundations I took over were strong - in fact, there are functions which remain unchanged 8 years later and were carried over verbatim from vAMSYS 0.5 to 1, 1.5, 2 and 3.

As you know - I am not a web developer - this is not something I do at my job or had previous training or experience with- circumstances led me to learn the tools and gain the skills needed to keep vAMSYS and vRYR going. However - over the last 8 years I have picked up quite a bit - more importantly - the gained knowledge it's what has been helping me go over the code, make improvements and eradicate code deficit where it was not too time consuming, not to mention the value I was able to create at my real job thanks to everything I learned with vAMSYS. 

PHP world does not stop - nor does Laravel and all the amazing tools you can pair it with - since I restarted work on V4ifying vAMSYS, I got to grips and became familiar with tools which have been a game changer - Laragon for local development environment, Filament for the tables and forms you see in Orwell and VDS, Livewire which ties it all together and Tailwind which makes it all look a bit more pleasing than plain HTML. 

I am fully aware the V4 project started last year and we are behind your and my expectations of delivery. However, with the latest progress in Orwell and VDS, as well as more reading up and just having more time to think about it - I have found myself to be in a position to crystalize the path to end of V4 - this is what brings us here today. In this forum post I hope to give you the final plan of development and how I will go about achieving it.

Orwell

It all started with Orwell and it was my first foray into Livewire - a nifty tool for someone who is not in love with javascript to make more user friendly interfaces. Coupled with Filament, these two turbocharged the progress and, I hope, gave you the Orwell pages and tables you find likeable and usable. 

As of now, there are 6 Orwell pages pending v4ification- PIREP Review, Forum Management, Score Management, PIREP Comment Presets, PIREP Point Presets and Pilot Invite Management. 

Score management is basically a copy of AutoReject Scorers; Comment and Point preset pages, once done will be a copy or announcement management and Pilot Invite is basically a form - these are all low hanging fruit which, as I mentioned in previous updates, will pluck as and when fill-time is needed between more significant work (i.e. I have 60 minutes - can I do something significant - if not, copy over and edit one of the pages above and have them ready).

The only big thing left is PIREP review page. It's a big and very important page - it's the page you visit most often. That is the reason why it is being left for last - to give me time to better learn the tools I am using and improve my technique, so when the time comes - I can do it not quickly and cheaply, but quick and well. 

That PIREP Review page, in my mind, is so significant, I opted to delay working on - I opted to learn more from experience, pick up best practices before I tackled it and instead jump onto grossly overlooked VDS, which by now is in dire need of attention.

VDS

VAs using vAMSYS have grown so large and big that VDS, in some cases, is simply not able to cope anymore. There are VAs whose VDS is chronically inaccessible and gives a server timeout error as it takes too long to query and process the data for display.

As of the last weekend you have access to VDS Beta - which is a total misnomer - it's VDS early access, where features are made available as they are developed and tested, hence why you are limited to 4 pages - Aircraft, Aircraft Type, Airport and Airport Groups.

By my count - in terms of development, I need to do Stands and Advanced Cargo System in management category and - the holy grail - route management. As I mentioned in the previous update posts, vAMSYS is doing away with pairs - they will become the thing of the past.

This change ought to cure the remaining nuisances a lot of our VA Partners have - system generated reposition and transfer flights - you will be in a position to set up scheduled (regular) flights, multi-leg routes as well as create custom repositioning flights from and to airports you want, instead of global setting which does it for you with blank routes. Not to mention, you will have the option to designate routes as 'jumpable' giving you the granular control as of yet unseen on vAMSYS. 

This overhaul is significant - as it will require complete rework of the logic for displaying flights to book, dispatch process and data shared with Pegasus - all of this, I believe, is mostly within our reach without changing a single bit of Phoenix UI code - which is important.

Phoenix

With your help and your suggestions in Bugzilla, I hope I am working on the best vAMSYS yet, but there is one major obstacle - Phoenix. I hope that after the next few paragraphs you will be able to appreciate the logic behind my madness and understand why I went about things in incremental fashion instead of a big version rollover.

For almost all intents and purposes (except absolute emergency for small changes) - Phoenix UI is not editable - that's all the maps, forms, filters, pages etc - anything to do with user interface - I cannot change. What I can do - is tweak the logic behind the scenes - this is what will allow me to retire pairs in VDS without a rebuild of Phoenix. 

Why can I not make any changes on Phoenix - simple - most of the critical functionality of Phoenix was written in Vue. Due to lack of updates over the years it fell into disrepair significant enough where it would no longer compile under updated versions of Vue and NPM. We did it quick and cheap. I then, more recently, consciously or not took, the decision widely known as 'screw it' - the tools I started using for Orwell and subsequently VDS - now make it unpractical to make Phoenix editable. And by unpractical I mean it needs a full rewrite to make it work again - something I had in my plans for 2 years now. 

Phoenix has been and remains, for all intents and purposes frozen in state. 

Unlike Orwell and VDS, it would be a very poor idea to try and incrementally update Phoenix page by page - it would break too much, not to mention wreak absolute havoc to your pilots understanding of how to use the system, not to mention potential bugs which can be introduced or your CSS changes which would become invalid overnight. As I mentioned in the new year post - there are just too many pilots to risk this sort of incremental development in live environment used by thousands. There needs to be a better plan. 

Plan for vAMSYS

I have been broadcasting in vAMSYS updates and our Discord conversations that our path is Orwell -> VDS -> Phoenix. I said there will not be vAMSYS v4 - we are on continuous improvement mode; I said there will be no downtime and we will tick along as we did for the last year.

I said all that prematurely.

I am fully aware that just the sentence above I basically said I lied - and I kind of did - but the information I gave out at the time was based on current thinking and current plans. Again - there is a reason to my madness - allow me to explain.

You will have noticed that no new features have been added to vAMSYS since I started v4ification with Orwell - it was impossible since I cannot edit Phoenix without rewriting it. But I cannot rewrite it as I am still learning good practices whilst redoing Orwell. Then there's all these changes I want to make with VDS - some of which will work with current Phoenix, a lot which will not. Think about it for a while and you end up in circular holding pattern with no exit.

The situation where the v4ification of Orwell and VDS - in incremental fashion, page by page- drip by drip has worked well - up till now - it gave me the way to learn and it did not break anything. I alluded before that incremental changes will not translate Phoenix and it will have to be an overnight change (with beta period), but I now realise I was rather naive. See - the incremental Orwell and VDS changes come with back-end code rewrites and improvements. I have changed swaths of logic but I have to fight myself against Phoenix limitations. Limitations I am now starting to grow very tired of, which led me to make the changes to my plan for vAMSYS.

I will still mostly follow the plan laid out before - that is Orwell -> VDS -> Phoenix with a caveat - once all the Orwell and VDS pages (with Pair retirement) are done, the current codebase will be put to pasture and I will start anew. Again, sounds drastic - but there is absolute sense to my madness in walking back what I said previously ( no v4) , which was walking back what I am saying now (yes v4). Confusing, I know!

The more I think about it, the less I can find a viable, reasonable and efficient path to take the Orwell, VDS and rebuild Phoenix whilst adding new features. There is a number of features I slated for implementation in the new vAMSYS - some of which have bits of code logic written already - but the more I work and wrestle with the current code, the more it exhausts and entraps me like quicksand. 

Hence the final plan -  rewrite-ish vAMSYS. It will not be a clean-slate design (other than Phoenix) - Orwell and VDS code will be transitioned very quickly almost in their entirety - after another review, refactor and improvement. That's the beauty of learning new coding tools and techniques - the very first new pages of Orwell are already due for a rewrite - they were my testbeds for learning and I have since learned how to make it better.

So - just to recap, simplify and expand a little:

Plan is - finish VDS (sans pairs), finish remaining pages in Orwell. You - VA Owners and Staff have a fully usable Orwell and updated VDS to use.

Then I will open a new document and basically copy over the good bits (Orwell and VDS) with no bad bits (Phoenix). Once the good bits are in place, start reworking Phoenix. All these new bits will no be worked on in production environment of vamsys.io - they will be hidden till there is something to show you and your pilots (aka VDS Beta) - I allows me to make all the mistakes and break things as I add stuff without adversely affecting anyone.

End result - we will come out with brand new Phoenix, updated Orwell and VDS. Oh, and since database won't change - there will be no downtime for that - it will be, as promised, overnight change once done 🙂 

Timeline and Servers

I am 80% confident that none of the vAMSYS plans outlined above will require any downtime. I also don't have the exact timeline - but I bet you can sense I am very close to being done with Orwell and VDS. There is one thing - our servers.

The current lease for our two amazing 48 core 96 thread AMD EPYC servers ends 27 April 2023. Whilst I do not have a concrete plan as to what the future holds for them (we can renew), I am exploring other options and once there is a decision I will be sure to let you know. If we do opt for a change, there will be downtime needed to transfer the data over.

-------

Hope you stuck with me for the full length of this - if there's anything I can clarify - do let me know! 

[Nicholas Knott]

I hope that you  can help me. Firstly you have done an amazing job with vAMSYS. I am having trouble importing a saved aircraft from simbreif to create aircraft fleet. When i try to add the link copied from simbrief i just get an error code. The code has no reasoning as to why the error occurs. 

Also just an idea for vAMSYS, maybe have a quick select option to add a new aircraft fleet to ALL airports saved in VDS.

I look forward to your responce, keep up the good work. Nick

[Lukas Jankauskas]

@Nicholas Knottthank you for your message - please join or Discord for community support or send off your question to our helpdesk.