#sparts

[sickfires]

HEY YOU. YES YOU. here's some new slime beds for your weird aliens. we have a significant lack of new sprite assets, i will fix that. the imgur link below contains the full res and a 2x sized one, for better scaling with most panels. these are recolorable however you like, and can be used with or without credit.

===> GET IT HERE, FREE FOR WHATEVER! <===

[a-point-in-tumblspace]

This year, I finally achieved my goal of getting through Super Bowl Sunday without noticing.

[babyfoxcollectionthings]

[sparts-ti]

🤩Upgrade your SHOEI Motorcycle Helmet with SPARTS Titanium Alloy Screws and make your ride stand out! 🏍️💨

[twothangspopart]

One more vending event for the 2017 season! It's art under $100 by @southparkarts at the Seattle Design Center. Come on out this Saturday and see a pretty fantastic collection of local artists selling their art for cheap! #artunder100 #au100 #sparts #southparkarts #madeinseattle (at Seattle Design Center)

[strawberry-oat-milk-latte]

Mets game :3 #mets #gomets #citifield #nikonmets #baseball #sparts #love (at Citi Field)

[totinos]

COME AT ME, BRO.

[hackedu-blog1]

Sparts 101

I recently started working on a personal project with a good friend of mine, using a python library called Sparts. Developed by the folks at Facebook, Sparts makes it dead simple to write new services (ie. software that continuously runs, doing whatever you’ve programmed it to).

Sparts is built on top of two foundational concepts: 

A “task” is, as its name suggests, a task that you would like to happen.

A “service” is a perpetually running program (otherwise known as a “daemon”, in computing-speak) that performs the tasks you write and specify.

You generally will have one service that runs many tasks; these tasks can run continuously, at regular intervals, or just once depending on how you program their logic. 

As per its design goal of making the process of creating your services/tasks as simple as possible, Sparts is implemented with an abstraction model such that there is a main service class and a main task class that you as the developer will subclass from to make your service(s) and task(s). The parent classes are written such that once subclassed, all you have to do is “fill in the blanks” with the logic of your tasks and services by overriding specific methods of the parent (or superclass). These methods are pre-defined but typically contain no logic, as that is what you are supposed to implement in your specific instance of the task.

In this manner, the typical work flow is to create a new task class that inherits from the main task class, otherwise known as subclassing the main task class. Note that there are actually two main common ones, but we’ll get to that later after we talk about the work flow. Then, you define the logic of that task by overriding the “execute” function that was defined as an empty function in the parent task class. After defining your task(s), you will create a new service class that inherits from the main service class (called “VService”) and then define a class list variable inside of it called TASKS, with each of your tasks as the list items. Then, all you have to do is run your service and it will handle running your tasks correctly as you’ve specified. 

You fill in the blanks for the logic behind each of your tasks, add them to a service’s list of tasks, and boom- you’re off to the races.

A little more about the different Task classes that are available: the most commonly used Task classes are either “PeriodicTask” or “QueueTask”. As their names suggest, PeriodicTask is the class you want to subclass from if your task is to run at regular intervals, and a QueueTask is the class you want to subclass if your task is to perform a bunch of operations in a given order. From there, the work flow for using these Task classes is exactly the same as described above.