Introducing the MOTKI CLI
I've been playing EVE again lately-- started a corp, it's getting really serious. So naturally, I decided to build an online presence for my corporation and tooling to help me optimize my carebear experience.
What started out as a web application has now become a pretty neat technical experiment on building a mid-sized project with Go. I used protobuf to create a client/server layer with code being shared between. I was able to leverage the client side of things to create a command line tool that interacts with a remote motkid installation.
Ner..I mean, neat!
The goal for the application was to create a set of customized tools tailored to meet my needs. Especially, I wanted something that could tell me what I was missing to produce a certain item.
This first pre-release of the MOTKI command-line interface includes a production chain feature that allows a user to set up arbitrary production chains, including the ability to either buy or manufacture the required materials. It pulls down average market prices for the products to produce a basic cost analysis.
For example, here's the output for a Guardian:
Guardian Domain # Material Name Cost/ea Qty Req Cost/unit 1 Tritanium 5.78 550,265 3,180,531.82 2 Pyerite 6.01 110,053 661,418.56 3 Mexallon 76.29 31,746 2,421,902.37 4 Isogen 52.35 8,254 432,096.89 5 Nocxium 386.97 1,375 532,083.75 6 Zydrine 1,108.45 741 821,361.41 7 Megacyte 1,320.42 128 169,013.77 8 Construction Blocks 12,501.06 71 887,575.23 9 Morphite 10,805.95 86 929,311.72 10 Fusion Thruster M 43,626.36 71 3,097,471.50 11 Radar Sensor Cluster M 29,516.26 250 7,379,065.73 12 Nanoelectrical Microprocess M 60,705.62 1,714 104,049,431.69 13 Tungsten Carbide Armor Plat M 11,342.42 2,143 24,306,798.33 14 Antimatter Reactor Unit M 148,411.69 22 3,265,057.08 15 Tesseract Capacitor Unit M 59,157.90 714 42,238,737.15 16 Linear Shield Emitter M 43,560.71 143 6,229,181.63 Per unit Revenue 215,500,816.00 5% ME Cost 200,601,038.61 Profit 14,899,777.39 Margin % 6.91 * 'M' indicates the component will be produced in-house.
Additionally, it looks at corporation inventory for blueprint copies of the necessary items.
Here's the inventory for the above Guardian:
Materials Inventory Missing Blueprints 11532 Fusion Thruster Available Blueprints Best/Worst Total Name Type ID ME% TE% Runs Guardian 11987 3/ 3 2/ 2 6 Radar Sensor Cluster 11537 10/10 20/20 11000 Nanoelectrical Microprocessor 11539 10/10 20/20 9000 Tungsten Carbide Armor Plate 11543 10/10 20/20 32000 Antimatter Reactor Unit 11549 10/10 20/20 9000 Tesseract Capacitor Unit 11554 10/10 20/20 13000 Linear Shield Emitter 11557 10/10 20/20 3000
Pretty cool, huh?
You'll probably also want to create an account on the Moritake Industries website and link your character to enable the production chain functionality in the CLI.
Decoupling Yourself From Dependencies
I've been working on a project for my EVE Online corporation building a web application with tools to help optimize industry game play. I decided to use Go for this project, for no reason in particular. This post is mainly targeting Go codebases, but the general idea is should be familiar and is interesting to consider, regardless. That is:
For an example, imagine your application needs to send email messages. You could easily use the
net/smtp package from the standard library throughout your project. But this would introduce a tight coupling with the un-customizable standard library; you wouldn't have a place to add or extend the functionality.
Instead, create a package in your project that acts as an adapter between the library and your project. This allows you to explicitly section off where and how you use that library's API — you only implement what you need, and you can customize that to fit your application. This package defines the API in which the rest of your application uses the functionality you're wrapping.
In our example above, you might imagine a
Sender type in the package
Sender is initialized with parameters for the SMTP connection and then provides an interface suitable for the rest of your application. It additionally provides padding should the library ever have a backwards-compatibility break — you'd only have to fix the break in the
I'd mention one other reason: in the unlikely event that you need to fully replace the library you're wrapping, then this pattern might be very beneficial.
But consider the drawbacks
Overly granular packages are somewhat frowned upon in Go as they can make a project needlessly complicated. If the component in question is used all over the application, then the benefits for having a wrapper increase. It would be rather pointless, however, if that component were only used in one other place. A digression for another time.
The adapter pattern, so what?
Yep, that's all this is. But it doesn't require classical interfaces or objects or inheritance at all. I just think it's interesting that the same patterns can be useful in many different contexts.
Anyway, so long.
- September 2017
- Introducing the MOTKI CLI
- July 2017
- Decoupling Yourself From Dependencies
- May 2017
- Model Rocketry Update
- April 2017
- Dynamic DNS with homedns
- March 2017
- The Story I Heard
- February 2017
- New squIRCy2 Website
- Ad-Hoc Polymorphism in Scala
- July 2016
- Packing Data Into Byte Arrays
- SeeedStudio 2.8" TFT Screen with Adafruit's ILI9341 library
- January 2015
- A Nice, Material Face-lift