A semi-official blog dedicated to the Mojolicious web framework
Over the course of this advent calendar, we have discussed the Wishlist example application several times. We used it to motivate discussions about templates, models, installable apps, and testing. In this post I want to use it somewhat differently. I would like to motivate you, the reader, into action in a few different ways.
Perl is well-known for its one-liners: short programs written as part of the command line invocation of the interpreter. Certainly every programmer or sysadmin has the need, from time to time, to do a quick one-off task programmatically. Such tasks can be done with a full script, to be sure, but once you get the hang of writing them, one-liners can save the time and hassle of actually doing so.
These tasks may include removing unwanted lines from files, collecting data from logs, or even a quick proof-of-concept of something that would become a script later. They can read lines in files, even multiple files, can operate on files in-place, can read from STDIN as a pipe. But while one-liners have been tools of the trade for these activities, certainly no such thing would be practical for web tasks, right?
But of course, on day 5 and day 6 of this series that we saw that we can build command line tools with your app. We have even seen how to use the eval command to run a one-liner against your app. So could we take this further?
Could we do remote data fetching and manipulation as a one-liner? Could we build an entire web application as a one-liner? Would I be asking if the answer was no?
The OpenAPI Specification (formerly named Swagger) is an API description format for REST APIs. An API specification written using the the rules set by the Open API Initiative can be used to describe:
This post look into how to write an API specification and how to use it together with Mojolicious::Plugin::OpenAPI and OpenAPI::Client.
What do you do when you want to split up a stream of data in real-time while giving the user instructions?
This is just what I wanted to do to aid in reverse-engineering the USB protocol of Virtual Reality devices known as Head Mounted Displays (HMD), for the OpenHMD project.
HMDs are used to create virtual reality environments. When worn, two slightly different images are drawn to each side of the screen, with each side visible to only one eye. This imitates binocular vision and creates an image with a feeling of depth. By tracking the rotation of the unit, the user can then look around this environment.
The recent resurgence of Virtual Reality devices can be attributed to the Rift DK1, released by Oculus in March 2013.
By logging the packets generated during each movement, we can compare the content of each log to identify which bytes are related to which action. Such movements include roll (tilting head side-to-side), pitch (looking up and down) and yaw (turning left/right). Though position isn't tracked, we also look for sway (left-right translation), surge (back and forth) and heave (up and down) information as this is used in combination with the other values for accurate tracking of rotation.
Mojo is an amazing toolkit for web development, as shown in previous calendar entries, but using components of it can also solve problems in other non-web spaces like these. Why use Mojo for this? Because it makes it easy.
Back on Day 9 we discussed testing and especially Test::Mojo. Today I want to just briefly talk about some practical things that can come up when testing real world applications. Once again the discussion will be motivated by the Wishlist application that we've been developing these past few days.