Hello! This is a hiring project for our Framework Specialist position. If you apply, we'll ask you to do this project so we can assess your ability to write and create content around your specialty framework.
Here's Fly.io's not-so-secret evil plan. We make it easy to run full-stack apps --- any app, in any framework --- close to your users. We're a simple and powerful way to run any application, with modern dev UX, advanced Postgres deployments with replication, and app scaling knobs that don't require you to learn Terraform to use. But we're especially shiny for frameworks that benefit from geographic distribution, like Phoenix LiveView, Laravel's Livewire and Rails's Hotwire. We want those kinds of frameworks to succeed, because the better they do, the more valuable we are.
We want Fly.io to be the best place on the Internet to run apps for your framework. If you're enthusiastic about your framework and helping other people, we need your help.
You can read more about the job posting here. This is the project for applying.
We would like you to create a "recipe" blog post that a developer could read and follow to add a specific feature to their own project. Here is the recipe we'd like you to create.
Add a self-serve diagnostic tool to a simple server-rendered page. The tool measures the network ping time between the browser and the server rendering the page.
Feature description:
- User checks a checkbox, clicks a button or takes some other action to start displaying the ping time.
- Once activated, the ping runs once a second.
- The ping time is displayed in milliseconds.
- The ping measures the full network transfer time between the browser and the server.
Dynamic server-rendered pages let developers create snappy applications without needing to use front-ends like React or Vue. When the server is dynamically rendering the page, then the total network response time becomes important. It directly impacts the user's experience! Longer network transfer times mean a less responsive application.
At Fly.io, we're all about moving the servers closer to the users! When servers are geographically closer to users, it greatly reduces the network latency, improves the user experience, and makes frameworks that use dynamic server-side rendering even more valuable! This project is about helping to measure and visually display the ping time between the browser and server.
We are looking for a well written recipe article that highlights and uses your specialty framework. Yes, this feature could be built using jQuery and a regular standard server-rendered page, but one of the benefits of using a dynamic server-side framework is that developers don't need to write a lot of custom Javascript. And the javascript they do need can be done using the framework. We'd like to see your framework used on the server and in the browser.
A quick explanation of a network PING and what it means.
The PING is initiated from the client. It measures the roundtrip network time to get from the client, to the server, and back to the client. Ping times will be higher when the distance traveled is greater or the server is less responsive because of load.
The idea with a ping is this:
- Client initiates the process by sending an "echo" request. You can think of it as simply "just reply back that you got my request".
- Server responds that the request was received.
- Client knows the local time of the first sent request and the local time of when the server response was received. Client computes the difference and this is the "ping time".
- Ping time is displayed.
Either side can initiate the ping process. The time measurement just needs to be taken on the side that started it.
Submissions should include a written "recipe" blog post that explains the problem being solved and shows the solution for how to do it. The goal with the recipe is to help a developers figure out how to add something like this to their own project. These articles should following a specific "recipe" format. More details are included on the recipe format and what that means in RECIPE.md and the recipe style guide here.
We expect this to take some time to complete. If you're experienced, you can expect it to take about 2-3 hours.
It is structured this way to help us evaluate applicants but also for you to determine if this type of work interests you.
When you are ready to share your article with us, please submit it as a PR on the Github repo you are invited to and please let us know it's ready!
See the recipe style guide for specific recipe format guidance and more detail on what we're looking for.
In short, here are some of the things we care about:
- Writing engages and interests the reader.
- It follows the recipe style guide
- Good technical quality.
- Simple and clear language.
- Easy to follow.
- The quality of English writing and that it feels natural.
- Don't include a full project. It won't be considered. This means no need to write tests either.
- Don't build more into the sample app than a single, simple page. It doesn't need to do anything extra.
- Don't bother adding any CSS or styles. Submissions are not graded on how they look. The focus is on the writing.
- Don't stress over turning in your submission quickly. The amount of time spent on your submission doesn't factor into the evaluations. You can take some time to think about things before you even start.
- Don't write a lot. There is no target word count, but we value efficient, short and to the point writing for recipes.
- Don't make this better than it needs to be. If you're like us, pride pushes you to make things better than they need to be. Don't do that here.
- Don't cover every edge case you can think of. Keep it simple and instructive.