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.

Download the latest release.

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?

Check out the source on GitHub.

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.

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 mail. A 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 mail package.

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.