We have a small handful of web sites (mostly WordPress, but with one custom Node.js+Express app) that we’re looking to hire someone to provide ongoing maintenance for, including bug fixes, new features, dependency updates, etc.
This would be part time (ideally about 10 hours a week) and remote, working whatever hours you prefer. We’d like to start by dividing your time in half between WordPress and Node, but we may shift that balance as time goes on.
This is something we have an ongoing need for, so if you’re a freelancer, this is an easy way to add some stability to your schedule for potentially years.
About the sites you’d be working on
- On the WordPress side, we version the themes and all essential plugins in Git, and deploy them via Git push to WP Engine’s servers. We have automated tests in place for a lot of the essential sales functionality, so that you can deploy to a staging environment, test it, then deploy to production once all the tests pass. Our sales site runs on WooCommerce, with a small handful of custom plugins to deal with weird stuff specific to our business.
- Our Node app (the Scenery Gateway) is a glorified CRUD frontend for users to upload scenery for the flight simulator. We have a reasonable amount of documentation on the organization of this app and its integration tests—see the README for more info.
A qualified candidate will have:
- Outstanding judgement and ability to self-direct. We won’t be looking over your shoulder constantly, so we’ll expect you to be able to prioritize issues, manage your time, and make responsible decisions on the future of these projects.
- Experience working remotely.
- Excellent written communication skills in English.
- Long-term availability for roughly 10 hours a week.
What to expect from us
We won’t be doing any sort of grueling interviews for this position—we expect to hire based solely on seeing your past experience, plus maybe a Slack chat or two.
We do our best to cultivate long-term relationships with contractors—we want you to love working with us. With that in mind, we will:
- Pay you competitively.
- Pay you on time, every time.
- Respect you as a professional.
How to apply
If this is sounds like a good fit for you, please shoot me an email with the following (my email is my first name at X-Plane.com):
- One or more references we could contact about past freelancing work you’ve done (doesn’t have to be web related)—we’re basically looking to have a third party confirm that you have good judgement, good communication skills, etc.
Fair warning: I expect to get an absolute flood of emails here, so I won’t be able to respond to every one. I’m planning to make a hiring decision two weeks from today (on May 13th), so if you’re interested, please let me know ASAP. 🙂
I’m headed to the annual Game Developers’ Conference in San Francisco next week.
If any folks from the flight sim community are going to be there as well, I’d love to meet up and talk shop—hit me up on Twitter (@TylerAYoung), or send me an email (my email is my first name at X-Plane.com).
EDIT: See the recording of the Q&A session here on YouTube!
We’ve been posting about this on social media for a bit, but realized we hadn’t talked about it here.
Today at 11 am Eastern (16:00 UTC; click here for time zone math) we’ll be doing another live Q&A on our YouTube channel. We’ll be taking questions in the YouTube comments, but if you can’t make it live, we’ll try to answer a few questions from the comments on this post.
In case you missed the first, second, and third (part 1 & part 2) rounds of this, this is a streaming broadcast featuring:
- Austin Meyer, owner & creator of X-Plane
- Ben Supnik, desktop product manager
- Chris Serio, mobile product manager
- Alex Unruh, art director
- …and a handful of other special X-Plane friends.
Over the weekend, I published a Python package called
xplane_airports. This serves two major use cases:
- Parsing the airport data (
apt.dat) files used by X-Plane, and asking questions like “does <some airport> support <some feature>?”
- Nicely wrapping the X-Plane Scenery Gateway’s API to get information about the airports available there. This includes the ability to download scenery packs and manipulate them just like you would an
apt.dat on disk.
If you’re doing any sort of automated analysis or manipulation of X-Plane airports, this should be a huge help.
It’s available via
$ pip install xplane_airports
And there’s a ton of documentation in the project’s README on GitHub.
Bug reports, feature requests, & pull requests are all welcome. 🙂
As you may have seen on our social media, we have new joystick features coming in the next major update. There are two major features here:
- Custom response curves
- Special (semantic) ranges for certain axis types
The first may be of general interest, while the second is almost exclusively useful to hardware makers and custom cockpit builders.
Custom response curves
For as long as I can remember, X-Plane has had a “control response” setting, which makes your controls respond non-linearly. More of your joystick’s range is mapped to the center of the your pitch/roll/yaw axis’s center, and less of the range is devoted to the extremes. This gives you fine-grained controls in the region where the controls are typically used, at the expense of more coarse controls at the limits.
In X-Plane 11, these settings live in the Control Sensitivity window (launched from the bottom of the Settings > Joystick screen), and they will continue to be there in the 11.30 update.
The problem with the existing control response setting, though, is that it applies to all joystick hardware you might plug in. You get just three values—pitch, roll, and yaw—that apply to every axis of that type, no matter the device. Moreover, if you have a different type of axis whose input you want to curve (e.g., throttle, tiller, etc.), you’re simply out of luck.
So, in 11.30, we’re adding support for setting custom curves on any axis type. When applied to a pitch, roll, or yaw axis, this will override the global control response curve; applied to other axis types, it will support new functionality not previously available.
These curves are incredibly powerful. They can do things like:
- Manually configure a null zone
- Create a smooth curve (a straightforward replacement for the old “control response” setting)
- Create really complex curves, with loads of control points, and your choice of interpolation method (linear, or one of two methods of smoothing)
But the fun doesn’t stop there!
New semantic ranges
There’s a new component to the curve editor that bears calling out explicitly.
When you’re editing a response curve for certain axis types (throttle, prop, or mixture), you’ll have the option of also configuring the ranges for certain axis-specific behaviors:
- Beta & reverse ranges for throttles
- Feather range for prop controls
- Cutoff range for mixture controls
X-Plane has always set these ranges automatically based on the aircraft model you were flying. For the first time, though, you can configure it yourself to match your hardware.
These are aimed primarily at hardware builders who have physical detents on their controls—you can make X-Plane’s idle point exactly match your throttle’s physical detent, for instance. This makes it possible to build really nice throttle-prop-mixture quadrants that play nicely with X-Plane.
If you’re a commercial hardware maker, and you’d like X-Plane to correctly configure your hardware by default for your users, you can set up both the axis & button assignments and the semantic axis ranges from the settings UI, then click the “Create Default Configuration File” button. Send the file it creates to me (my email is my first name at X-Plane.com) and I’ll get it shipping in the next release.
We’re looking to add a junior UI developer to the team in the near future.
About the position
We need a junior developer to come do user interface work for us. As you may know, the Plane Maker and Airfoil Maker user interfaces did not get the same overhaul that X-Plane itself did for version 11, and we’d like to change that. That’s a major undertaking, and you, dear applicant, could be responsible for it in its entirety.
Beyond that, X-Plane itself has a “long tail” of UI improvements that we’d like to see. You could be the one to move these improvements from “The Glorious Future™” schedule into reality.
Our UI is built on a custom widget-based framework that is only now starting to reach maturity. So, while a lot of your work will involve putting together existing pieces, there will definitely be problems you can only solve by writing completely new UI components. Read More
I’ve gotten a handful of emails from third-party devs recently asking the question:
I have a bunch of XPWidget-based windows. When will I be able to use them with fancy new features like UI scaling, pop-out support, VR support, etc.?
Happily, the answer is: now!
I really buried the lede on this one, but back in X-Plane 11.20, as part of adding plugin support for VR windows, we added a new “mode” for XPWidget-based plugins. It all starts with a call to opt-in to the “modern” window APIs like this:
From this point forward, all widget windows you create will be backed by a modern XPLM window, and can therefore be used with all the new XPLMDisplay APIs. All you have to do from there is call XPGetWidgetUnderlyingWindow() get the XPLMWindowID of your window to pass to those APIs.
Edit: the X-Plane live session is actually on the 14th – today, Tuesday.
At the request of our European friends, the next round of X-Plane live Q&A will take place on August
15th—excuse me, 15 August! August 14—at 20:00 UTC (translate that to your time zone). Previous Q&A sessions have been scheduled at times that were convenient primarily for Americans, but why should they get to have all the fun?!
In case you missed the first and second rounds of this, this is a streaming broadcast (via YouTube) featuring:
- Austin Meyer, owner & creator of X-Plane
- Ben Supnik, desktop product manager
- Chris Serio, mobile product manager
- Alex Unruh, art director
- …and anyone else we happen to drum up. 🙂
Dear Europeans, the fate of the livestream is in your hands! 😀
The CEF post generated a lot of controversy, and rather than replying directly in the comments (and doing a bunch of copy & paste), I thought I’d collect my responses to the major objections here.
Objection: Nobody wants to browse the web in X-Plane!
Yes and no. I agree that, unless you’re in VR, a full-fledged web browser is totally useless. Nobody wants to be browsing cat pictures while flying. But CEF is really not designed to power a traditional web browser.
Consider this list of a bunch of other applications that nobody wants a web browser in:
- Adobe Acrobat
- The Steam client
- The Atom text editor
- The GitHub desktop client
What do all those applications have in common? They’re built on CEF, or the closely related Electron project.
My point is this: the primary use case for CEF is not to build a full-fledged browser—it’s to support things like HTML5 user interfaces, which massively lower the bar for creating nice, easy-to-use plugins. It could also support things like displaying PDF charts or other electronic flight bag features—things that are theoretically possible without a webview, but which have such a high barrier to entry that nobody wants to tackle them.
We are always looking for ways to both
- get more people involved in creating X-Plane add-ons, and
- give existing plugin developers better tools so that they can create things they couldn’t have before.
Doing so makes the X-Plane community stronger, and supports the creation of add-ons that might otherwise not have existed.
Objection: This is a waste of time. What you should be working on is [some other feature].
As I mentioned previously, CEF is being used in X-Plane right now to enable in-app upgrades. This is obviously the most boring non-feature we could ever ship, and I understand why power users (people who might have bought X-Plane 11 on day 1!) are irritated.
The reality is: some features we ship for end-users*, and some we ship to “pay the bills.” Paying the bills is boring, but important: having X-Plane be financially successful ensures that we can continue improving the sim (ahem, in ways that end users actually care about!) for decades to come. In this particular case, we have reason to believe the current purchasing process is convoluted enough that it’s losing us sales. In-app upgrades will increase sales by some (small) percentage, so even though it’s not a direct improvement to the sim for existing users, it’s funding future development.
One more thing worth mentioning on the topic of “I wish you’d do x instead” is that we have a handful of full-time developers now, with people specializing in very different areas, so we tend to have a lot of features in progress at any one time. It’s certainly not the case that, say, Sidney stopped working on improving performance while I was off integrating CEF. 🙂
Objection: I don’t want X-Plane plugins using webviews!
The reason we’re having this discussion is that plugin developers are already using CEF—and they’re doing so in ways that are incompatible with other developers’ implementations.
It’s certainly an option for us to bury our heads in the sand and ignore this—we could force users to choose between, say, installing a Flight Factor plane and installing a fancy new web-based plugin (or using future X-Plane core features). Ultimately, though, this hurts both the end users who would have otherwise chosen “all of the above,” and it hurts the add-on makers who lose sales because users were forced to choose.
We can’t stop add-on makers from using webviews, but we can make sure that doing so doesn’t lead to a compatibility nightmare for end users.
Objection: CEF represents a massive security hole!
This is absolutely a concern for us. Webviews in X-Plane present two major attack surfaces:
- The possibility of running untrusted code (e.g., a nefarious site exploits a browser vulnerability to execute harmful code on your machine)
- The possibility of sending data somewhere you didn’t want it to go (e.g., a nefarious site masquerades as your bank’s web site, and sends your login info to bad guys)
We’re still in the “exploration” phase here, trying to understand plugin developers’ needs, but there are a lot of ways we could mitigate these threats. A few possibilities, listed from most extreme to least:
- Don’t allow remote connections at all; plugin-created webviews could only load local assets (HTML, JS, etc.) that were bundled with the plugin
- Require plugins to provide a whitelist of URLs that are deemed safe to send & receive data from
- Allow user preferences to control the above policies (or even disable webviews entirely)
Objection: CEF will slow the sim down. This is bloatware!
That’s for measurement to decide! In our tests, having CEF displaying static pages while flying didn’t slow down the sim by any amount we could measure. And since CEF doesn’t run on the main X-Plane thread, the OS can schedule CPU-intensive things like page loads around X-Plane’s work. There is definitely some memory overhead involved (a few hundred megabytes), but considering the existing footprint of X-Plane, it’s not a crazy amount.
And, like everything in X-Plane, if you want to tune it to get the last drop of performance, you’d be free to avoid using features & add-ons that depend on webviews.
Objection: Don’t use CEF—You should use WebKit, Gecko, Servo, etc. instead.
I did a lot of research and test implementations (on Windows, I went so far as to use Trident, the underlying engine to Internet Explorer!), and the only webview framework I found that meets X-Plane’s requirements was CEF.
* Aside: What does 11.20 include for end-users? A few highlights from the release notes:
- VR support
- New Sydney, Australia landmarks
- A new Aerolite 103 model
- An overhauled Columbia 400
- 1,315 airports with new 3-D scenery
Plugin developers, Beta 5 includes a few new VR-specific APIs in the XPLMDisplay header.
The complete list of VR-specific APIs is now:
I’ve updated the VR sample plugin to take advantage of all the new stuff here, minus the widget API—really, once you enable native widget windows, your widget window becomes “just another XPLM window” as far as the display APIs are concerned.