Jump to content

George Peppard

Members
  • Posts

    110
  • Joined

  • Last visited

  • Days Won

    26

Other groups

vEXS Moderators vAMSYS VA Staff

George Peppard last won the day on September 25 2022

George Peppard had the most liked content!

Reputation

46 Excellent

Personal Information

  • vAMSYS Staff
    (Infrastructure and Platform Delivery Manager)

Recent Profile Visitors

22229 profile views
  1. When browsing your VA's member list, or leaderboards, you may come across some members with a badge. This badge exists to help you identify genuine vAMSYS staff accounts, and provide some explanation about why you cannot perform certain actions to these accounts. Who are ? The vAMSYS team is made up of several sub-teams that perform different roles across the platform. The badge is shown on the profiles of members of the team who have superuser access to the platform. Currently, this access is given to the vAMSYS platform development team, and the vAMSYS Community Support team. Accounts bearing this badge may have a normal pilot ID, or they may have a strange-looking ID such as "RYR-George". No matter the pilot ID, only people with the badge are vAMSYS platform superusers. The vAMSYS team members act independent of any VA, and we never make decisions on behalf of your VA management team. We don't reinstate pilot accounts, maintain the VA in any way, or review PIREPs. What is a superuser? vAMSYS superusers have access to every page of every VA, and this extends to VDS (the route management area) and Orwell (the VA back office and management area). They also have access to Aeolus, which is the vAMSYS platform-wide administration panel, and contains details on airlines and users. When a superuser logs into a VA, the things they can see and do (pretty much) model that of the VA owner. Some data needs an even higher level of permission to view or edit. If this is the case, then the data can only be seen or edited by a database admin (referred to in some places as a platform administrator, or a platform manager). Not all DB admins are , yet some are platform administrators. There are currently only two members of the vAMSYS team with DB admin access. They can be contacted via the support desk if necessary. vAMSYS team members only access your VA's data where there is a need to do so. They will never share the data with anyone outside the vAMSYS staff team. If vAMSYS team members choose to fly for your VA, they will fly as normal pilots do, will be subject to normal scoring and PIREP approval/rejection rules, and will not manually override decisions made by the automated system. If you would rather a team member did not fly for your VA, you can either contact them directly (e.g. via Discord or email), or you can raise a ticket with vAMSYS Customer Services. Who are these strange accounts in my new VA? Superusers are added to your VA when it is created so that they can automatically see and log in to the VA, for example to provide support or investigate a bug report. Superusers added to your VA will have the badge automatically too. It is not possible to remove a superuser from your VA - this is similar to how it is not possible to remove staff from a VA without removing their staff permissions first. Can I become a superuser? Superuser privileges are only granted if a member of the team's role requires them. We recruit members for these roles directly, so it is not possible to apply for these roles.
  2. Hi all, You may have noticed (especially if you are staff) that there have been some trials ongoing recently to determine how best to support our VAs (and to a lesser yet still important extent, their pilots). We are pleased to announce that we have completed our trials and have provisioned the required systems to make the necessary changes, which are detailed in this announcement. Support VA owners and staff may have noticed the trial of a live support chat in Orwell. This was received very well, with the members that used it reporting a high level of satisfaction with it. Unfortunately, after careful deliberation, it has been decided that such approach duplicates existing Discord functionality (which is free) and does not add anything of value (like ticket management) for the cost such chat service provides. Hence we regret to inform that we will not be pursuing live chat support options on vAMSYS at this time. We will continue to evaluate this method of support going into the future, and if possible, we will consider bringing it back. Our review into support systems has, however, led us to reevaluate our current platform. For around a year, we have been using Zendesk to provide ticket-based support to VA staff and some pilots. This platform, whilst looking nice, has given us plenty of headaches in keeping staff and owners synced. In addition, the cost of the platform compared to the benefit over competing solutions has led us to the conclusion that this service no longer economically makes sense. For example, the most popular request from users was the ability to be able to see and respond to their tickets via a web interface. Were we to offer this, our subscription fees to Zendesk would increase by over £60 a month. Therefore, we have installed a brand new helpdesk system (based on osTicket, an open source helpdesk platform) which is now available at https://support.vamsys.io. We have also redirected the hello@vamsys.co.uk email address to open tickets on this new platform. We hope you enjoy using it (as much as it is possible to enjoy a helpdesk system), and we invite you to raise requests either by email or by the new help centre going forward. We have also taken this opportunity to move certain requests away from vAMSYS Customer Services. See the sections below for more information on changes to bug tracking, reporting bugs, and suggesting features. Please remember that vAMSYS is not resourced to provide, and does not provide first line technical support to VA pilots. If you're a VA, please do not send pilots to us for basic queries, we cannot help. If you're a pilot, please contact your VA first for support. Bug tracking and reports vAMSYS has (for as long as I cam remember at least!) used various forms of internal bug and feature tracking software in order to keep track of what needs to be changed about or added to the platform. For (mainly) licensing reasons, we have never been able to open these trackers to users, which meant that our customers did not have visibility on the actual state of their issues after they were reported to vAMSYS Customer Services. This was a key point of frustration for many of our customers, who, not being updated about the status of their bug reports, could not feed this back to users. We have therefore taken the opportunity to install a new bug tracking software which allows any user to register and report bugs directly to vAMSYS. The platform is based on the open-source bug tracker Bugzilla, which is used by several large software projects (including those by the Mozilla Foundation, including the Firefox web browser and Thunderbird mail client). Don't be fooled by the somewhat dated UI - Bugzilla is extremely powerful software, and whilst there may be a slight learning curve, we anticipate that overall the system will provide a much closer connection between users and the developer that is working on their bug report. Key benefits of this new system include: All users will have visibility of all bugs that are being worked on or are under investigation, meaning they do not need to spend time reporting them only for them to be closed as duplicates. Users can add comments to bug reports, for example if they would like to elaborate with additional information. Users can "follow" a bug (i.e. add themselves to the CC list) so that they receive updates when the issue is progressed. The main benefit - users can raise bug reports themselves, immediately, without having to go via vAMSYS Customer Services. This means that hypothetically, any user can raise a bug report, not just VA staff. We have a guide on reporting bugs on the new system, which you should read fully before you use the new system. Please note when registering that your email address can be shown in full to other users, so if you would rather your email address remained private, you should use a different one! Ideas and feature suggestions When we originally implemented vAMSYS Ideas a couple of years ago, many things were different. We had much less customers than we do now, and most customers were on a first-name basis with each other. vAMSYS Ideas was implemented as a place for discussions on features that used to take place in our Discord server to go, and also handled tracking "upvotes" so that popularity of a certain feature could be gauged. However, several VAs have since become disconcerted with this system. The concept of upvotes, whilst useful for gauging popularity, does not usually reflect the number of VAs that want certain functionality (VAs would often have several of their staff upvote a certain idea), and VA owners and staff felt demoralised by the concept of having to "canvas" for upvotes for their ideas. Ideas (which were originally envisioned to be detailed suggestions for a feature) were often submitted with only one or two sentences, meaning the development team did not have the required information to implement the request, leading to further "back and forth" between the users and development team. The ability for any user to request functionality, whilst originally billed as a positive, led to no real distinction between requests submitted by a paying customer and requests submitted by some end users. End users often did not search for duplicates; much of our administrative time for feature requests was spent clearing up the system and merging duplicate suggestions together. It is clear that the current system is no longer fit for purpose, and that drastic change is needed. Note that when we talk about a "poor suggestion", we mean one that does not contain the required detail or one that is inherently flawed, not one that the development team disagrees with. We have therefore designed a new system based on the following principles: Every feature request must be sponsored by a VA. This is the VA that crafts the suggestion, and the primary beneficiary of the feature if it is implemented. All requests must be submitted by VA staff. Users that would like to request something for inclusion should do so by contacting their VA; VAs act as a filter for poor or duplicate suggestions from end users so they do not pollute the system. Feature requests should be detailed, and contain all the information required. Features that contain all the required information, or suggestions for implementation details, often progress much quicker than those that are poorly formed. This too acts as a filter for poor suggestions; it is often not possible to extract the required detail from a poorly formed suggestion, so if the person submitting the request cannot do this, then neither can we. We will spend more time reviewing and managing requests, as it improves the overall quality of the suggestion list. We will act as a further guard for poor suggestions entering the system, with the view that any suggestion that makes it through review could be implemented. Requests that can never (or will never) be implemented will not be left in the system. We will inform VAs if suggestions are unrealistic or will not be implemented, providing a reason, so that VAs that submit suggestions are not left in the dark as to whether we intend to implement functionality. Feature requests should encourage debate and discussion, with people supporting the request often adding further elaboration to it. We will not track popularity of requests by arbitrary vote counters. VAs that support a request can add comments to it, elaborating further and continuing to develop the suggestion right through to implementation. Feature requests will be evaluated based on merit to our customers. Any feature request that passes review and has healthy discussion, and is fully developed, should be implemented. We provide no timeframes for implementation, but we do not want feature requests to "rot". If we have the time, we will implement a well-formed and highly-requested suggestion. The Bugzilla platform used for bug reporting and tracking can also track enhancements. We have decided to (ab)use this functionality for tracking feature requests, as the overall structure of the platform will (we believe) encourage a more healthy debate on feature requests, encouraging VAs to submit fully fleshed out suggestions, or express their interest in existing suggestions by adding useful and constructive comments to them. Our article on reporting bugs also contains details on requesting features. If you currently have ideas on the vAMSYS Ideas platform, we invite you to enter the ideas into Bugzilla. We are offering you this chance because we currently do not store a sponsoring VA in Ideas, yet we would like to capture this information if possible. After a couple of weeks, we will go through the ideas list and copy across any that have not already been moved but we consider to be either highly-requested or important requests. You do not need to migrate your ideas yourself if you do not want to, but doing so allows the suggestion to be correctly attributed to you and your VA, and you will receive the relevant emails. To conclude We hope that these changes improve our support and feature request system for everyone, and that they continue to support our ever-growing platform into 2022 and beyond. If you have any questions or comments, then please feel free to either leave a comment below, or contact vAMSYS Customer Services. George
  3. This post is now superseded by -------- We try and keep the bugs in the platform to a minimum, but the extensiveness of it and the wide variety of use cases means it is almost inevitable that at some point you will experience a bug. This article describes how to report bugs accurately and correctly so that we can fix them as soon as possible. What is Bugzilla? Bugzilla is our installation of the upstream software of the same name. We now use it to track unconfirmed and confirmed bugs through from when they are reported all the way to resolution. We previously used YouTrack and Jira to handle this. We plan to soon migrate idea tracking to Bugzilla in some form, although how this will be done remains to be seen. vAMSYS developers have full access to Bugzilla - that is, they can do everything. vAMSYS community support staff have an elevated level of access to Bugzilla that allows them to edit all bugs, regardless of who reported them. All other users can view and comment on all bugs, can submit new bugs, but cannot edit bugs that do not belong to them. The anatomy of a bug Bugs in Bugzilla have the following information associated with them: the product is the root level project that the bug is associated with; for most bugs this will be "vAMSYS" the component is the part of the product that the bug is associated with the version is the version in which the bug is exhibited - as we do not track versions for most products, this will usually be "rolling" the status can be one of UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED and VERIFIED; some statuses have more information associated with them (for example, an issue can be RESOLVED FIXED or also RESOLVED WONTFIX); for non-staff users, this will be set to UNCONFIRMED until it is reviewed by staff the severity is a measure of how "important" a bug is; it's important to think in terms of overall importance and not just how important a certain bug is to you (an exception to this rule is the severity "enhancement" is used to represent new features or ideas) the hardware and OS can be used to capture information about the platform you are seeing a bug on the assignee is the person who is held accountable for the resolution of this bug - by default this will be the vAMSYS developer who has overall accountability for the component you selected, but the assignee of an issue is often changed later to the developer who is working on the bug the CC field allows you to specify any other users who are key stakeholders in the bug the orig. est field allows you to specify an original estimate in hours for how long the issue will take to resolve the deadline specifies the date by which the bug should be resolved the URL can be filled to include a URL to link the bug to the summary and description allow you to describe the bug; the summary field should contain a brief summary of the issue and the description field can be used to elaborate further you may add an attachment to a bug depends on, blocks and see also allow related bugs to be specified the priority of an issue is populated after the issue is filed, and represents how high priority the issue is to be resolved Not all fields must be filled (in fact only a product, component, version and summary are actually required). You may not have permission in your role to edit some (or most) of these fields - do not worry, fields you cannot edit will be populated by the staff member that carries out the triage for your issue (that is, checks over the issue and confirms it, as well as assigning it a priority and severity). Submitting a good bug report The most bugs can get the most timely attention if users adhere to good practice when submitting bugs. Bugzilla already has a fairly comprehensive set of guidelines on reporting bugs, which we encourage all reporters to read. In general, reporting bugs generally follows down to some principles: Be precise - remember we don't see what you can see, so we need to have precise information in order to find the bug in the first place! Be clear - explain the bug so it can be reproduced One bug per report No bug is too trivial - small bugs may hide big bugs Clearly separate fact from speculation and some preliminaries: Check before you report the bug that you can reproduce it - it may have been fixed Search to see if the bug has already been reported! If you've reproduced the bug and can't find it on Bugzilla already, then this is how you can go about reporting a new issue. Choose Enter a new bug. Select the product in which the bug is located (for most bugs, this is "vAMSYS"). You may be automatically sent past this step. Select the Component the bug relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General") Enter a summary, describing the bug in 60 characters or less. A good summary should quickly and uniquely describe a bug report. It should explain the problem, not the solution. Enter the details of the problem report in the description field, including A more detailed reinstatement of the summary. Steps to reproduce the bug including the URL of the page the bug occurs on. Actual results (what the application did when you performed the steps) Expected results (what the application should have done if the bug was not present) Any other useful information - for example - if it only applies to one VA - note which one. Double check your bug report for any errors or omissions then press Commit. Your bug is now in the database, and (provided you are not a Bugzilla moderator) is awaiting triage in the UNCONFIRMED state. You will receive emails when the status of the bug changes. You can always leave comments on a bug if you wish for additional information to be noted, or edit the bug. Submitting an idea or feature request vAMSYS VA owners (or their staff) are able to request the addition of new functionality to the platform. Previously this was accomplished via a dedicated "ideas" platform, however in order to consolidate information on changes to the platform we have moved this process also to Bugzilla. Feature requests are created as bugs, but must be created with the "enhancement" severity. Please note that if you do not hold a VA staff position, or are not a VA owner, then your feature request will be automatically dismissed. You should contact your VA staff and ask them to consider raising the request on your behalf. VA staff should note that when raising a request on behalf of their VA, it is considered the VAs opinion that the requested feature should be added. If a VA does not agree with the request put forward by a user, they are within their rights (and we recommend that they do) to politely decline. If this is the case, no Bugzilla entry needs to be created. Feature requests require a VA sponsor to be considered. When requesting functionality we suggest you follow these tips: Be clear and concise, but include the required details. Tell us why this change would benefit your VA. If you have any ideas about how the feature would work, then please include them! Even if our implementation is slightly different, this is helpful for us. Most importantly, make sure your VA owner is aware of the fact you are raising this request! It is their VA that will be sponsoring the change, and they probably won't be happy if their name is attributed to something they had no idea about! To request new functionality is included in the platform, follow these instructions: Search for the feature request on Bugzilla! If it has already been created, you may wish to add a comment expressing your support. See Supporting a feature request for more information. Choose Enter a new bug. Select the product in which the feature will be located (for most requests, this is "vAMSYS"). You may be automatically sent past this step. Select the Component the feature relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General"; if your feature request would add a new component, then please select the component that would "contain" this new one if possible) Enter a summary, describing the request in 60 characters or less. A good summary should quickly and uniquely describe the requested feature, and should not include any suggestions for implementation. It should describe what you would like to be achieved, not how to get there. Enter the details of the suggestion in the description field, including A more detailed reinstatement of the summary. What group of people within your VA this change would benefit, and why. Roughly what proportion of your VAs users (or staff, if this is a request for staff-only functionality) the change would benefit. Any background relating to the change request. For example, did you previously have this functionality on another platform? Any additional information you think would be pertinent. Enter the Feature request sponsor VA's three letter pilot ID prefix (for example, if you are VAM0002, the prefix is VAM). Please only enter the prefix of a VA in which you are staff. If you do not see this field, then you have not selected enhancement as the severity. Go back and select this now, then complete this field. Double check your suggestion for any errors or omissions then press Commit. Supporting a feature request Previously, it was possible to vote for an idea to express support. The intention of this was good, but often manifested in a VA getting their entire staff team to vote for their idea, artificially inflating the popularity of a given idea. This led many VA owners and staff to feel that this "canvassing" was necessary to get an idea through to implementation, which left many owners with negative opinions of the system. This also presented issues for vAMSYS developers - we had no idea how the feature would impact a certain VA, or what VAs it would impact. To try and curb these issues, and mainly to try and encourage a healthy debate around the inclusion of new functionality, we have removed the previous "voting" system, instead allowing members to comment on a feature request on Bugzilla to express their support. There is no direct relationship between "votes" (or in this case comments) and implementation, and instead the entire request (including comments) will be reviewed holistically in order to gauge popularity. Therefore, if this functionality will benefit your VA, we invite you to leave a comment on the feature request on Bugzilla explaining why your VA would also like the feature implemented. This need not be any longer than a couple of sentences, but you may wish to (and of course, you are welcome to) elaborate further, for example if you have further suggestions or requirements for the implementation.
  4. Hiya, We are not aware of any problems with the website - you will need to contact your VA and get them to escalate this up through the appropriate channels. VAs do not pay vAMSYS for first line pilot support, so we are unable to assist directly. All the best George
  5. For action: vAMSYS system migration (this announcement is targeted at VA staff - if you're a pilot, please wait for an announcement from your VA) Unless you've been living under a rock for the last few months (or are one of our newer customers - in which case, welcome!) you will have heard of the large infrastructure upgrades that are currently being worked on across the entire platform to deliver a more stable experience for all our users. Most parts of this migration can be done silently, without affecting users - this is the approach we have so far taken and will continue to take, slowly migrating groups of users onto the new systems until all users are accessing the "new" hosts, at which point the "old" host, Atlas, can be switched off one last time and retired. However, there are a couple of parts of the maintenance in which we will be required to prevent users from accessing the platform - these are the parts of the maintenance related to the database, where we need the state of our data to remain constant for a long period of time, without any changes, to ensure no data is lost, duplicated or corrupted. The vAMSYS platform will be UNAVAILABLE on WEDNESDAY 23RD FEBRUARY from 1600 UTC until 2300 UTC. This includes the `vamsys.io` website, Pegasus, the vAMSYS Community Forums and associated services. You will NOT be able to book flights, file PIREPs or access the platform IN ANY WAY. Flights in progress may continue to track BUT WILL NOT REPORT BACK TO THE CENTRAL SERVER. YOU SHOULD NOT START FLYING IF YOU WILL NOT FILE YOUR PIREP BEFORE THE MAINTENANCE PERIOD BEGINS. Action required NOW: - We recommend each VA delegates overall responsibility for communication to pilots for this outage to one person. This person should claim this communication and see it through to resolution. - Cascade this communication to the rest of your VA staff and begin to formulate some publicity to communicate this to pilots in good time before the outage. - Begin to determine whether pilots will be able to manually claim for lost hours and points during the outage (we recommend using our PIREP claim system), and devise a strategy for processing claims. Action required IN GOOD TIME before maintenance, ideally BY MID-DAY ON TUESDAY: - Cascade publicity to pilots via various channels to inform them of the impending outage. vAMSYS staff will add a global announcement banner, **VAs do not need to add alerts or notices unless they wish to add additional information**. Important Information - It is our experience (and that of several of our VAs) that many pilots will either not see the various forms of publicity provided, or ignore it, and will therefore request support from your VA. We would recommend implementing some method to prevent users from requesting support with vAMSYS (we recommend if you have a platform support channel in your Discord server that it is locked - there is no way to have issues with the platform when the platform is not available to pilots). - We do not, and will not for this outage, provide first line support to pilots. Pilots that contact vAMSYS Customer Services to report the outage will only delay support for VA owners, and will receive a (to them) dissatisfactory response referring them back to your VA. - Please do not contact vAMSYS Customer Services, via the helpdesk or Discord, to report this outage. Doing so will only delay completion - we are a small team (the team that can deal with infrastructure problems is even smaller), and time spent responding to erroneous outage reports is time spent *not* carrying out the planned maintenance. We apologise for any inconvenience this may cause.
  6. I'm a bit late(!) but I believe this has now been done? George
  7. January 2022 on vAMSYS Welcome to the first of our regular monthly (or thereabouts) updates where we will be describing what has been going on, what we've changed, and what we plan on doing in the coming weeks. This month's update is particularly exiting for us (although probably not for you, the reader!) because we are in the process of taking delivery of two brand new machines which we're migrating the platform onto over the next few months. We've also made some changes to the platform itself - some visible to all our users, some only to our VA staff and owners, and some that aren't visible at all! Grab a cup of tea and some biscuits - let's get into it. Platform Changes As promised in our end of year update, we've made several internal changes to the platform over the last few weeks. Most of these are in the name of improving stability, but some are to make preparations for future changes and upgrades. Some highlights include: Changes how we dispatch scheduled and ad-hoc tasks across the platform to improve stability, especially as the number of VAs increases. Changed some details relating to how we generate and cache (remember) statistics data to improve consistency across the platform. Better support for Chinese characters in some places such as events. Added a more prominent note in case there is an issue with a VA's vAMSYS subscription. Removed two factor authentication for the time being - we'll replace it with a much better system in the future when we re-visit that area of the platform. Various typo fixes and language improvements. CSS changes to make the navigation menu float over the map/exporter/importer selectors. Improvements to our back-end central admin panel, to have a better overview of subscriptions. Improvements to the PIREP claim system to make use of new statistics generator. Applications for VAs on vAMSYS will now automatically reject applications which are duplicates of current customers. Several extensive code consolidation changes. VDS area edits will now correctly hide/unhide and "hub"/"un-hub" an area. Enabling or disabling manual PIREPs in Orwell now functions prototypically. Added 12,339 stands to our stand database. Improvements on how equipment, transponder and PBN codes are sent to SimBrief. Fixed the auto-reject meant to detect in-air refuelling so that it actually detects in-air refuelling. Fixed an issue where in some cases, removal of a stand group was incorrectly propagated across the system (or was not propagated at all). If you are a member of multiple VAs, you may also notice that we have implemented a new select page. This page takes greater advantage of the screen space available to us to display more VAs, and is an example of the look and feel we are going for with our new user interface elements. Over the coming days, weeks and (hopefully not) months, we will start reworking Orwell (our management panel for VA staff) to use this new design and technology. We hope you like it, and we're happy to hear any feedback either directly by email, via our Discord server, or in the comments below this post. Upcoming Changes With the upcoming infrastructure change, we do not want to make any radical code changes which will introduce instability. We will continue to refactor and optimise our code; time permitting, we have our eyes set on a new feature - finally, we hope to start rolling out design changes and related code modifications to Orwell. Scheduling, importers and tasks As part of our changes to task dispatching, we made comprehensive changes to our so-called "hierachy" of tasks. Every minute, hundreds (or thousands) of tasks are queued for the automated processing system to run. The system must decide where to route this job, pull in all the data required (in some cases from hundreds of different locations), execute the job itself and handle monitoring and recording of the result, as well as working out whether there are any follow-up jobs required. Tasks run from really minor things like moving single pilots to their destination when they file a PIREP to more major things like generating flight lists, leaderboards, and parsing and scoring any and every PIREP filed on the platform. If you do something and feedback is not instant, it's likely your actions have triggered one (or in many cases, several) automated jobs which the system then needs to prioritise and execute on top of the hundreds more already scheduled for processing by the system or other users. It is for this reason that we sometimes have to sacrifice performance of one area of the platform in order to make another run faster. In the most recent case, we de-prioritised import and export jobs so that tasks which require more "real-time" feedback (like moving a pilot) can be executed sooner. We never designed imports and exports to be fast or instant - it so happened that in the original implementation this was the case, but this was beginning to take it's toll on other areas of the platform. After we made these changes, some users contacted us to inform us that these tasks were taking a now abnormal amount of time to complete. In response to feedback, we re-prioritised import and export jobs again and we now feel that the current priority strikes a suitable middle ground between speed and reliability of other areas of the platform. File Management We continue to review the many areas of the platform, and are always looking for opportunities to replace or upgrade functionality with a more relevant and intuitive system. The File Manager in Orwell (for VA staff) was implemented quite some time ago, and has seen little to no changes since original implementation. With better ways of accomplishing the same thing now available, we will be retiring the File Manager in Orwell in the coming months. What you should do with files currently in the system depends on what the files are, and what they are for. If the file is a custom stylesheet, we will make provision for you to upload the file directly to the relevant settings page and you will be able to upload the file there instead. If the file is an image for Pages, then we will make provision for you to upload the file directly to Page Management - you will need to upload the file there instead. If the file is a VA resource, then you should use the vAMSYS Community Forums' downloads feature, which is free to all non-trial VAs. Setup is instant and automated, and you can be up and running in minutes. If you have large files, or more complex requirements, then vAMSYS Customer Services will be happy to discuss any custom arrangements for your VA - please get in touch. We are providing advance notice so you can begin to prepare for this change and incorporate these changes into your VA's ways of working. We're happy to answer any questions either directly by email, or in the comments below. Infrastructure It wouldn't be a post from me without mentioning infrastructure (besides - apparently now it's my thing?!). This week, we took delivery of one of our two new dedicated servers. Each server boasts an AMD EPYC processor with 48 cores and 96 threads of processing power, 256 GiB of RAM, and 2 TB of high-speed NVMe SSD storage. Hopefully, we'll take delivery of the other ordered server next week We have now taken delivery of our second server(!), so we will begin to work towards a timeline for migration. Please keep an eye on the usual channels for announcements of downtime so that you can cascade this to your VA, in good time, ahead of any planned maintenance. Conclusion Thanks for reading this month's update! I'm interested to hear what you think about the format, style and relevance of content - please let me know in the comments below this post. Until next month! George (on behalf of the vAMSYS platform team)
  8. On v4, continuous updates and infrastructure Continuing on from our recent end of year update, vAMSYS is pleased to provide this further announcement outlining our plans for the new vAMSYS version and the infrastructure changes which will be taking place over the next few months. Updates and semantic versioning Long term members of the platform will know that, for many years, we have been rolling updates into "versions". Versions 1 and 2 were legacy versions of the platform, version 3 is what you are using now and version 4 is what we have been working on. Each version is currently subdivided into further minor releases (for example version 3.8) and then subdivided further into patch releases (3.8.1, for example). This semantic system, whilst allowing the development team to mark changes against milestones, does not, in our use case, make sense. Often, changes are released before the version is bumped and the changelog published. This essentially defeats the point of a semantic versioning system at all. Starting with the next release, we will begin to move away from this system, and instead towards a continuous "release when ready" cycle. This means that as soon as functionality is ready for end users, it will become accessible. Users will no longer need to wait for the corresponding release to be published before they can use features they have been waiting for (which in some cases, have been waiting several weeks for their official release date). You will no longer see version numbers on the platform, for example in the footer. We will provide a method of determining the release you are currently viewing, but this is mainly for internal use, and should not need to be monitored by end users. Instead of changelogs, we will publish a monthly(-ish) update on what we are working on and what has changed since the last update. This also allows us to cover other topics where required (if you have suggestions for what to include in this "newsletter"-type update, please get in touch), and we hope that you will find the first update around the end of January 2022 to be an informative and interesting read. vAMSYS version 4 Now that the preamble for this section has been covered, we can say (with context) that there will be no v4 release. The reason for this is simple - there are no more numbered releases. As discussed in our end of year update, it has become clear that over the last few months the time available to the team to work on the new version is not as high as was originally hoped. It is for this reason that a stark change of tactic is required. We will no longer be "starting from scratch" with v4. Instead, we will take the existing v3 codebase, and begin to make several fundamental updates to it in order to stabilise and prepare the platform for easier addition of functionality. Our starting point will be PHP and Laravel upgrades, followed by code consolidation and implementation of some code we wrote for our internal development version of the former v4. Instead of vAMSYS v4, the version you use currently will be heavily updated. Instead of vAMSYS v3, you will just be using vAMSYS. Feature requests and suggestions We outlined that we would like to eventually move away from the vAMSYS Ideas system for feature requests. This is because internally, we do not consider upvotes as much as the ideas platform makes them out to be - so to continue to use a platform which places so much emphasis on upvotes is, in our opinion, counterintuitive. We are unsure as to what we will be replacing vAMSYS Ideas with at this stage (it will likely be something integrated into the systems we already use internally to track bug reports and confirmed feature additions), so for now, please continue to raise requests via the existing Ideas system. We will be sure to capture all requests in Ideas when moving to a new system to ensure that nothing is lost. If you have any meta-suggestions (suggestions for the suggestions system) then please contact George Peppard via Discord or email (george@vamsys.co.uk). Infrastructure and downtime vAMSYS is investing around £1600 over the next few months in new enterprise-level hardware and software to ensure the platform continues to operate with stability for many years to come. We are currently in early discussion with our server hosting provider to ascertain exactly when this upgrade will be possible (there are some billing complications, as well as some lead time for the hardware to be provisioned in a datacenter), and we will aim to keep downtime to as low a level as possible (this too depends on what can be worked out with the service provider). We are very excited about this and will be sure to provide you with more information regarding our new infrastructure solutions in the future. However, the key takeaway is this: in or before Q2 2022, there will be an unprecedented server and service overhaul, which will result in downtime. Please continue to monitor the vAMSYS Discord server for publicity so that you can inform your pilots, in good time, ahead of any planned outages which will affect them. Conclusion Thank you very much for reading this update. We hope you have found it's content to be useful and we are happy to answer any questions or comments you have either via the vAMSYS Discord server or the comments below. The vAMSYS team would like to congratulate Anna, one of our developers, on graduating with a BSc in Computer Science.
  9. 2021 on vAMSYS ~ In memory of Graeme Wright, a long-term member of the platform, a well-respected virtual pilot, VA staff member and so much more ~ "Another tumultuous year here. I could not blame anyone, hey - this was me - tad too optimistic last year when I wrote the end of year message. I think we all thought along the same lines - we will vaccinate, we will adjust and life will come back to normal. It did - for a few months in the UK at least. If the lockdowns did anything - together with the re-release of Microsoft Flight Simulator - they have driven a lot of new users to Virtual Airlines. Based on numbers alone, we did better than ever before. This has been a particular high for us all - let's get real - not every day we get an influx of new people joining our very niche hobby. We are trying to do our best in helping our new members in finding their feet when they go the perilous road of staring a Virtual Airline and we want to thank you for pitching in Discord in helping out. vAMSYS in 2021 had to take a second violin for me a lot of the time, hence I could not be prouder to hand off the bulk of the end of year message you can see below to the people you interact with the most - the better half of Team vAMSYS. " - Lukas, vAMSYS LTD "It's over already?", we hear you say - so do we. I am not sure how I would describe the year 2021 - least of all in a concise format - but circumstances notwithstanding, it's been the biggest year yet for the platform - for which we mainly have you, the user, to thank. So brew a cup of tea (George recommends this one, Lukas would rather you opted for this instead) or grab your favourite beverage, have a seat, and let's discuss what 2021 has meant for the Virtual Airline Management System. Let's go back to 2020 We ended 2020 on a high - we finished v3, then migrated everyone over to v3; Anna developed Pegasus, then we moved to using Pegasus exclusively; we started the year with 10 VAs, ended with 30+ - last December we were high on lockdown induced accomplishment fever - we were bright eyed, thinking we can do anything and thus - on the wrong side of Dunning-Kruger curve when we set out our goals for 2021. Don't get us wrong - 2020 has been the best year for us... up until 2021 - we did a lot. With your help - we achieved a lot and hit new milestones in our history, but were a few things we could not do - and it's time to fess up. We ended our 2020 message on our DIscord with the following: Osprey is dead. Osprey was a project to allow VAs to implement their own frontend to the platform, interacting with vAMSYS via a RESTful API. The beauty of our platform, we believe, is that anyone can use it - even if they do not have the technical expertese that was previously required to run a VA (using self hosted software). Due to what we consider to be very little interest in this feature (leading to the feature likely not being used by many if not all VAs) and reprioritisation of projects in preparation for the v4 release, we have decided that Osprey will not be implemented. Discord Bot - towards the end of 2020 we were very happy to be approached by Aidas. He offered his hand and time in developing a universal vAMSYS discord bot for every VA using our services. We were thrilled with the idea - it has often been a requested addition to the vAMSYS repertoire of tricks. Due to the number of ongoing projects this feature is currently somewhat suspended. We know it's something that many of our customers would value, and we will aim to implement Discord integration in a future release. Pegasus Scorers have been delayed due to the continued support of legacy smartCARS integration. It is likely that due to the required changes to the platform that would need to be implemented in order to fully take advantage of the new Pegasus functionality (and the fact that a new version of Pegasus will shortly be in development, which will change how the software works anyway), major new scorers will be deferred until they can be implemented in v4. We will continue to enhance our existing scoring lineup, and where scorers are required to be implemented, will implement less "ground breaking" options in the current version, to be revisited at a later date. v4 - the elephant in the room, which we will touch more on towards the end of this post. Whilst we never made any dates official - we had some internal milestones to hit which we thought were reasonable when we posted the 2020 end of year message. As the phrase goes, "The devil smiles when we make plans. He laughs when we get too busy." Due to less-than-expected development time between the team, we have realigned our internal milestones to more accurately reflect the pressures of a development team consisting of time-limited members. We continue to work towards a release, which we now expect to be some time in 2022. We understand that some of this news is likely disappointing to readers, however we would rather offer more transparency (if at the expense of shattering some expectations). Statistics Our yearly holiday post wouldn't be complete without some mind-boggling statistics we share with you every year, so here we go. In 2021... 9700 of you joined vAMSYS for the first time, bringing the total number of users to just over 37,000 26,543 new VA memberships were created, which is around 2.7 per user more than 80 of our current VAs were created in 2021 - and long may they continue you filed over 195,000 PIREPs, which is around 15 per active user in those PIREPs, you flew for over 1.18 million hours, which is enough time to travel to Mars and back... 91 times, in a rocket (or in George's terms, enough time to make around 890,000 trips from end to end on the Central Line) you also used up just over 1.35 million metric tonnes of fuel - let's hope that electric planes "take flight" soon...? our most frequent pilot filed just over 800 PIREPs representing just over two months of continuous flying - the development team are really impressed, and we will be in touch! All of these statistics represent the reason why we continue to put hours of our free time into vAMSYS, why we are prepared to be woken up at (literally and forcibly, thanks to our alerting systems) every and any hour of the day to fix platform issues and why it's still worth it - because our platform provides a place for people to unwind and do something they enjoy for hours on end (in some cases, hundreds) - and any developer that tells you that's not humbling either isn't telling you the truth, or is not a very good developer. What has changed? Not only did we have some incredible statistics to show off, we're also going to talk about some of the biggest and best changes to vAMSYS this year (in mostly chronological order). We implemented the Network Connectivity Service, which allowed us to produce our first of many VATSIM- and IVAO-based PIREP scorers. We implemented proper management of pilot sharing agreements. We added the advanced fleet and stand override system. We completely replaced our pilot search system with one that's much quicker and more user friendly. We added Forum Management in Orwell, allowing staff to (finally) manage forums with autonomy. We rewrote alert management and maintenance from scratch, which to George's great dismay, made it better than notices. We added the Advanced Cargo System which allowed people to specify exactly what virtual oddities they are transporting around the world. Where does your money go? I am not a huge fan of prividing these numbers, and fear it detracts from our (my) purpose. vAMSYS (and it's very few partner VAs) do not exist to make thousands of pounds. vAMSYS Is a passion project - that's how the team and I came to work on it. We spent time with VAs, started some, managed them - we are all very much a part of the community we aim to support. However, we think it is only right that as paying customers, you see where your membership fees are spent. Here you go. - Lukas vAMSYS is a private limited company in England and Wales with one shareholder (Lukas). All payments are handled by Stripe, an industry standard payment processor. Their policies and compliance documentation are linked on the billing pages in Orwell. As a private limited company, we are required to submit our accounts to regulatory organisations in the UK. They have an address on them - please do not show up unannounced. If you want to meet with Lukas, please just ask him - he will be more than happy to arrange such a meetup. We file accounts every year, however as a small company, we don't need to have them audited by a third party, nor do they need to be particularly detailed. You can gleam from our filing in August 2021 covering 1st March 2020 to 28 Feb 2021 that vAMSYS LTD is not bankrolling the team or our customers - we do not hire Rolls Royce Phantoms and private Embraer jets for trips to our City of London offices. We reinvest almost all of the vAMSYS service fees (sometimes more) we collect from you to provide the services you and your pilots have come to enjoy. Monies (per year), as of 20th December 2022 has been allocated roughly as follows: ~£80 for various domains we use £164 for the alerting systems letting us know day and night if vAMSYS has issues (Opsgenie and New Relic) £760 for ticketing and support systems you use to get in touch (Zendesk) £462 for accounting and mandatory legal fees £655 for code storage, deployment and server management £8,520 for bare metal server costs Were we to hire (assuming it was affordable) the entirity of Team vAMSYS as salaried employees at £30,000 per year, our total cost would increase by another £168,160. Hence all our time, effort and software we use is wholly unpaid. In fact, vAMSYS owes nearly £11,000 in director loans to cover previously incurred expenses. We do have other expenses and overheads which we did not account for here, but these are our recurring costs which your monthly fees pay for. vAMSYS has not paid any dividend nor it will for many years to come. If you think you know how we can do a better job, then please do get in touch! What is going to change? 2022 will see the biggest migration of vAMSYS onto new hardware to date, and we're really excited to show off the results (well - actually, we hope you don't notice anything apart from maybe things getting quicker). Some key things are: Circa £1500 investment in the first few months in new enterprise-level software and hardware, with ongoing renewal and support costs after that. Moving off our current model where everything shares resources onto an enterprise-level virtualization platform. New networking equipment linking servers together, allowing us to sync databases between clones multiple times every second with no latency or impact to the user. 96 cores, 192 threads, 512 GB of RAM and over 4 TB disk space of brand new dedicated infrastructure, linked together at 6 Gbps, and to you at 1 Gbps (if you would like us to do some sort of technical blog, please get in touch). Oh, and apparently there's this thing called "v4" that people have been asking about... not sure about that one though. 😉 We will also invest time into less "physical" - yet still as important - changes, as follows: Increased transparency, telling people what we are working on and why. Moving slowly away from only taking ideas from the vAMSYS Ideas platform, which will allow us to be more flexible and respond more rapidly to change. Moving away from "hard versioning" and towards continuous releases. The retirement of "changelogs" - we will instead publish a regular newsletter comprising of what has been worked on since the last publication, and what is being worked on at the time of publication. We hope these changes will help us engage better with our customers, and we would be delighted to hear any suggestions you have in order to help us do this even better. Please contact George if you would like to make a suggestion. We will obviously need to plan some extensive maintenance for the infrastructure move. If you are a VA owner, please continue to monitor the vAMSYS Discord server for publicity so that you can cascade this to your staff and pilots in good time ahead of any downtime. Closing remarks Whether you filed one PIREP, a hundred or a thousand, you (and your VA staff counterparts) make vAMSYS what it is today. I wouldn't go so far to describe us as "essential" over the last few years, nor are we "key workers" on vAMSYS (although coincidentally, some of the team are in the "real world", as well as some VA staff!), but VAs provide a place for people to go and spend a few hours with like minded individuals, free from judgement, and do something they enjoy - and I think the importance of this to many people over the last year and beyond cannot be understated. The whole team is eternally humbled by the contributions of our many users to the platform - and we hope that you, like us, look forward to what 2022 has to bring. - Anna, Chris, Steve, George and Lukas - collectively, Team vAMSYS
  10. This evening we completed an upgrade to the vAMSYS Community Forums which was the last in a series of planned outages which allows us to deliver changes to how we provide release notes (changelogs) and our knowledgebase. Forum version upgrade Probably the least significant change of the evening, we have upgraded the software powering the forums to the latest version offered by the third party provider. There should be no material change in functionality as it's just a patch release. Changelog migration Currently, our changelogs are stored in one long forum post which becomes more and more painful to maintain as we release more functionality, and is not very user friendly (as the newest releases are at the very end of the thread). We have therefore taken the opportunity to use the functionality originally designed to support the knowledgebase to also provide a better platform for our changelogs - which we have now renamed to Release Notes. The Release Notes should be much easier to browse for end users (the latest releases are shown at the top of the page) and is also much easier for Team vAMSYS to maintain - a win win for all of us! If you currently have alerts set up for when we post new comments to the old changelogs thread, you'll need to follow the release notes using the link at the top of the release notes page. The old forum post will no longer be updated. Knowledgebase migration The most significant change we have delivered is the migration (and quite significant enhancement) of the vAMSYS knowledgebase from the old Atlassian Confluence platform, which is now out-of-support and in growing need of replacement. We are pleased to announce that the most of the vAMSYS knowledgebase from the old platform (and many more new articles describing Orwell features!) are now available to browse by clicking Knowledgebase in the menu at the top. We will continue adding articles covering functionality we have not touched upon yet. The new knowledgebase is a living project and will be continuously updated to remain the number one source for information vAMSYS v3 and upcoming v4 functions. Over the coming weeks we will remove references to the old knowledgebase from the platform and supporting resources and direct members still using the old knowledgebase to the new one on this platform, in preparation for the eventual discontinuation and subsequent removal of the old knowledgebase entirely. Only VA staff and owners can view the knowledgebase - if you have any comments on the content of an article please feel free to leave it a review and let us know how you think we could improve (or what you liked). --- Thank you for bearing with us during these planned outages and we hope you like the improvements we have made to the service we offer. If you have any queries, please follow your normal support routes (escalate to your VA if you are a pilot, or if you are VA staff please contact vAMSYS Customer Services). Many thanks for your support, George and all of Team vAMSYS
  11. We accept the following payment methods: Visa Mastercard American Express Discover (including Diners Club) China UnionPay JCB Cartes Bancaires Interac We do not accept PayPal.
  12. What payment methods are accepted by vAMSYS? Do you accept PayPal?
  13. vAMSYS 3.8.0 introduces no radical new features - instead, this release cycle, we have given a bit of TLC to some old functionality that could be improved (or in some cases, didn't work properly). The biggest change in this release is that we have completely rewritten Alert Management in Orwell - from the ground up. This change brings it in line with other modern components of the vAMSYS system - it's now a Vue component, which in simple terms means it is much easier to navigate and use, and removes the need for lengthy page refreshes when information is modified. We have also removed support for raw HTML input in Alert Management. This is part of our "Secure-By-Design" project - part of which will, over the next few months, completely remove support for raw HTML inputs across the entire platform. If you are a VA owner, please see upcoming publicity in the vAMSYS Discord server regarding this change. We've also added support for the force airline parameter which allows you to link to your VA specific pages without having to add disclaimers about which VA pilots must have selected. As with all our releases, vAMSYS 3.8.0 also contains several bugfixes, performance improvements, cosmetic improvements and various quality of life improvements for existing functionality. There's much more to see - including some more features, so as always, for information on the entire list of things included in this update please see the detailed changelog here: Please continue to report bugs via the usual channels. If you are a VA pilot, please escalate bugs via your VA. If you are VA staff, please report any issues to vAMSYS Customer Services. vAMSYS would like to thank @Stephan Oschmann, @Jan Podlipský and @Kian for reporting bugs that were fixed in this release, or suggesting new ideas that were implemented. Thanks for flying vAMSYS!
×
×
  • Create New...