Sunday, July 5, 2015

100 Billion: June Income and Balance Sheet, and Reflections at the Mid-Year Point

June was back in the green and would have been better save for a completely random gank.  So goes life in EVE.  I also eliminated at least one item out of our tech II production chain.  I don't have a systematic way of doing that yet, but significant work on EveKit is nearing a close so I should be able to divert efforts to building those types of tools.  Finally, as we're six months into the year, now is a good time to reflect back on how the 100 billion experiment is going so far.

June By The Numbers

Here's where we were at the end of May:

and here's where we stand after June:

The balance sheet is up about ISK 1B although equity is still down due to the drag from PLEX cost.  About half of the increase came from income from tech II sales, and the other half came from asset appreciation.  PLEX prices are still on the rise.  So we're still waiting for the predicted bottom cycle of PLEX pricing which usually occurs late in the summer.  There was a PLEX sale this last month which would normally cause prices to drop, but that didn't happen.  Also, many EVE bloggers have been talking about the recent low active logons count.  That would favor higher PLEX prices instead of lower (not enough liquidity on the buy side).

Here's the top 20 assets from end of May:

and here's the top 20 at the end of June:

There are three main things to note from the asset list for June:

  1. Toxic metal prices continue to be volatile, at least on a month to month basis.  I have no idea what's going on there.
  2. Ship skins have now made their appearance in the top 20 with the Dominix skin being very popular.  It's a limited issue skin and likely something to be re-issued for major EVE events (think: EVE Vegas or FanFest).  That suggests we should consider dumping it soon.
  3. The special issue clothing is still on the list but, unlike ship skins, are particular to FanFest 2015.  That suggests they won't be re-released any time soon (perhaps ever again), so I think we're a hold for now.

On the income side, we were nicely into the green although as usual not near enough to cover PLEX cost.  Here's where we stood for May:

and here's where we are at the end of June:

We had the strong sales we expect for being well into the regular production cycle of our tech II items.  We should have been about ISK 200M higher but for a random gank which you can see in the transaction list.  We sold our kill rights for the gank, and they were used.  That's the ISK 2 we made :)  Here are the top 20 transactions for May:

and for June:

The company Crane (blockade runner) was randomly ganked on the way to a pickup all in high sec space.  We got podded as well.  There was no cargo loss as we were empty at the time, but as blockade runners can't be scanned, our gankers had no way to know they wasted their time (and ships).  So this was mostly an annoyance that cost us about ISK 200M in replacement costs.

The other item of note is that I've decided to drop Adaptive Nano Plating out of tech II production.  The market for this item is flooded at the moment and the price has dropped out of the bottom.  I'll leave a sell order on the market to get through current stock, but I'll be excluding this item from the tech II blueprint copy list until prices improve.  As I mentioned above, I don't have great tools for doing this systematically yet, but I expect to have time to work on that soon.

That's it for the 100 Billion corp financial update, now let's reflect on the year so far.

Reflections at Mid Year

We're half way through the year and it's probably fair to say that we're just treading water with the 100 billion experiment so far.  From an equity perspective, we're actually losing money.  But let's gather all the numbers so far, then draw conclusions:

I've colored coded the months to show where we had positive income versus negative income.  This leaves out the change in asset valuation, which is also a potential source of income.  But the main take away is that we're almost dead even with where we were at the start of the year.  That's a lot of work for no real gain.  In fact, we're actually losing money if you throw in the cost of PLEX (not shown in table).

I'm dedicated to this experiment for at least a year.  So despite the lack of any real progress, I'm staying positive.  Which means it's time to look forward and think about what needs to change to show real progress.  Here's what I've got so far in no particular order:
  • The Market?  Being in the finance industry, I feel like I'm missing a huge opportunity here to do some station trading and make some income that way.  I haven't gone down this road yet because I want to do it systematically and don't yet have the tools to get that done.  That will definitely be a focus for the second half of the year.
  • Drop the losers already.  The call to remove Adaptive Nano Plating from production was a gut call based on prices I'm seeing and my rough accounting of production cost.  This needs to be done more systematically for all the production we're engaging in.  Two updates ago I presented a simple spreadsheet analyzing drone production.  I need to do the same thing for all tech II production to see where we're just not making the grade.  I suspect I'm missing a few more items I need to cut based on cost.
  • Blitz more missions.  This is more time consuming than other endeavors but it's a money maker both in terms of cash (usually at least ISM 100M a month) as well as loot and salvage (particularly on missions which return officer insignia).  The real cost in missions is time, which of course doesn't show up on the balance sheet at all.
  • Is Tech I Profitable?  This should come from better market analysis, but it would seem to reason that given the amount of PVP, there should be a decent market for Tech I ships.  Of course, the market may be heavily flooded here.

Getting a handle on losing tech II production is probably the highest priority, followed by more regular mission running.  There are regular stories of players making billions from dedicated mission running.  I doubt I can put that much time into it, but I can probably do more than I'm doing now.

In other news, the EveKit Wayback Machine is about to become reality which will free up some time as well.  I'm really excited about that change as it will make it much easier to analyze how the 100 billion corp is burning through assets used for production.

That's the update for this month.  See you after the Aegis update!

Saturday, July 4, 2015

The EveKit Wayback Machine

We've posted in a few places that we're changing EveKit to implement something called the "Wayback Machine".  That work is finally happening on the Beta site starting tonight.  This post is a more detailed description of what these changes are and how they work.  This post assumes you know what EveKit is, why you might use it, etc.  If you're unfamiliar, you can visit the front page which has a decent summary of the main features.

What is the Wayback Machine?

Simply put, in Wayback Machine mode, EveKit will now retain a history of all changes to any XML API data we're downloading for you.  Previously, the only data which really had a history were things like industry jobs, market orders and the wallet.  Now, every time some piece of data changes we'll version it and save the old version for later reference.  We're also changing the API so that you can view the data at any time in the past.

The main reason we implemented this mode is to get better tracking of account assets over time.  When you're trying to manage a modest sized EVE corporation, it's useful to track how fast you're burning through key resources needed for production.  Likewise, there are several other interesting use cases.  For example, you can view corporation member tracking information over time to track movements, recruitment, etc.  If the feature catches on, I'm sure several more clever people in the community will come up with their own interesting use cases.

How It Works (Technical Details)

The main change to support versioned data is to assign every object a "lifeline".  A lifeline is a series of time stamps which indicate intervals at which an object was live in the system.  To simplify the implementation, we make copies of objects as they change, so a single logical object is actually represented as a sequence of physical objects reflecting the logical object's state as it changed over time.  We implement lifelines by assigning two values to each object in the sequence:

  • lifeStart: the time stamp (inclusive) at which the object first became live; and
  • lifeEnd: the time stamp (exclusive) at which the object was deleted or replaced.
The time at which a given object is live is therefore represented by the interval [lifeStart, lifeEnd).  The latest live version of an object will have lifeEnd set to +infinity.

There are two ways in which a (logical) object can change, each of which modifies its lifeline:
  • Delete: if an object is deleted, then we "end of life" the last object in the sequence, which means we set lifeEnd to the delete time;
  • Update: if an object is updated, then we "end of life" the last object in the sequence and create a new object with lifeStart set to the update time, and lifeEnd set to +infinity. 
We've changed the EveKit API (see below) to make it possible to query the version of a logical object at any given time.  If the query time is t, then this query is just a scan through the object sequence for an object with lifeStart <= t and t < lifeEnd.

Versioning everything raises some efficiency concerns so we've made two main changes to try to keep things performing well:
  1. Queries are optimized for returning the latest live data.  We're assuming the vast majority of API calls will be for current live data, so we've optimized our queries to work best for that case.
  2. We've internally refactored data which changes frequently. For example, most of a Character Sheet is relatively static except for things like "balance".  So we version balance data separately from the rest of the character sheet. This change minimizes the amount of data we have to copy when versioning.

What Happens to Meta Data? 

EveKit allows user defined meta data to be assigned to any object we sync through the XML API.  Meta data is just a set of key/value pairs made up of bounded length strings.  We've chosen to not version meta data, which means the following:
  • Meta data is associated individually with the physical objects which make up the lifeline of a logical object.  That is, meta data is a non-versioned property of each physical object;
  • Meta data may be copied forward depending on how the lifeline changes.  Specifically:
    • If an object is updated, then the meta data for the old object is copied and becomes the meta data for the new object.  This copy is completely independent of the meta data for the old object.
    • If an object is deleted, then later re-added, then the new object will have empty meta data (meta data is not copied from the last live version of the object).
  • Meta data changes independently for all physical objects in the lifeline for a given logical object.  This means you can modify the meta data for a given object without affecting the meta data for any other object currently in the same lifeline. 

API Changes

There are two basic changes to the EveKit client APIs:

  1. Every API call for synced data now includes an optional "at" parameter.  If you specify this parameter, it should contain the time stamp (in milliseconds UTC since the epoch) at which you want to view your data.
  2. Every API result now includes two new fields:
    • lifeStart: the time stamp (in milliseconds UTC since the epoch) at which the returned data became live, or 0 if this data was live when the site was switched over (see below).
    • lifeEnd: the time stamp (in milliseconds UTC since the epoch) at which the returned data was deleted or replaced by a more recent version, or -1 if this data represents the latest live version.
If you omit the "at" parameter, then EveKit will return the latest live version of the requested data.  An API call will either return valid data, or throw an error code if no data was live at the specified time.

For API calls which return a single data item (e.g. a single asset), lifeStart and lifeEnd are a direct view of the current life line for the given object.  For API calls which return multiple data items (e.g. a list of all assets), lifeStart and lifeEnd are bounds:
  • lifeStart = max(lifeStart) for all items returned by the call
  • lifeEnd = min(lifeEnd) for all items returned by the call
The individual items within a returned list may have different individual life lines, but the result is guaranteed to be live in the bound represented by lifeStart and lifeEnd.

A Special Note About Meta Data

As described in the technical details above, EveKit meta data is not actually versioned.  So there are no API changes for meta data and there is no "at" parameter required for meta data calls.  The lifeStart and lifeEnd values in a meta data response can be safely ignored.

How the Roll Out Will Work

The roll out is a multi-step process all occurring during down time:

  1. The data sync scheduler is disabled.  No new API data will be synchronized during downtime.  You can continue to make API calls against EveKit, but the results will be unpredictable.
  2. All current sync data is backed up.
  3. All current sync data is converted to Wayback Machine mode.  Each current data time will be assigned a lifeStart of 0 and a lifeEnd of +infinity.
  4. After a few basic tests, the data sync scheduler will be re-enabled and down time will end.
All current data is therefore considered live at the time of conversion.  The conversion time also places a natural lower bound on the "at" parameter: a query before the time of conversion will always return all the data which was live at conversion time.  As new data is downloaded from the XML API, current data will be versioned as described above.

Final Thoughts

We're very excited about this change, but we're also a bit nervous about any change that touches everyone's data.  So we'll be watching the Beta site pretty carefully over the next week before we decide to make the change to the main site.  We'll continue to post updates to the forums, this blog and the EveKit main site as we get closer to releasing on the main site.

Wednesday, June 10, 2015

100 Billion: May Income and Balance Sheet, and Coming Soon: the EveKit wayback machine!

May brought a big hit to the balance sheet due to the release of a new set of Genolution Core Augmentation CA-3 and CA-4 implants.  These were released as an EVE Online anniversary gift and the market for these implants dropped like a stone.  I chose to view this as glass half full (more below), but for now we took it on the chin in the balance sheet.  The other big change this month is that we got out of the "running a starbase" business.  As I said last month, this really isn't necessary any more with the industry changes a few months ago.  So I disassembled my starbase and started selling off the parts.  I'll finish up this month's post with some exciting news on the development front: I've finally started work on the EveKit Waybaack Machine!

May By The Numbers

Here's where we were at the end of April:

and here's where we stand after May:

The impact of the new implant release is pretty obvious, we took a ISK 5B swing down in overall value of the company.  Ouch.  In hindsight, it's obvious we should have dumped these implants before they crashed.  However, I'm expecting we'll have another shot at that, depending on how long it takes for value to rise again.  The market is flooded at the moment, but the normal PvP attrition should start to wear down the supply.  It's a longer term play, but to catch that wave I put a buy order in for these implants just after the supply bumped up and picked up five each at ISK 80M a pop.  Not a great price, but I wasn't sure how these were going to move and wanted to make sure I got my position in.  If they rise to even half of what they were before it's still a great move.  The big risk around this play is that this implant release becomes an annual event.  If that happens, then I'm sunk.  On the plus side, I didn't bet the farm here.  I'm only risking about ISK 800M.  If these implants reach ISK 1.5B again (about half what they were before the new release), then we'll make about ISK 15B on the transaction, or a gain of just less than 1900% !

Cash and assets were more or less flat excluding the implant pricing change.  PLEX prices continue to rise fairly steadily.  Most sources report that PLEX prices are cyclic with a drop in late summer.  That's getting close, we'll see.  The uptick in PLEX doesn't suggest a great investment here.  There's money to be made, for sure, but not much relative to the cash outlay.  Now on to the asset valuation.

Here's the top 20 assets from end of April:

and here's the top 20 at the end of May:

And there it is, the Genolution Cores fell right into the bottom of the list.  The rest of the list is more or less unchanged except for the surprise appearance of an Orca at ISK 600M.  This is actually a mistake.  The company Orca happened to be temporarily out of the company when the April balance sheet was computed due to some account maintenance.  It's back in for May.  Toxic metals are up once again.  I may consider putting a sell order in at the higher price if I need cash (so far, this hasn't been necessary).

On the income side, we were negative for the month mostly due to taking a position in Genolution implants.  We also kicked off another round of invention for tech II production, which means spending on data cores.  Here's where we stood for April:

and here's where we are at the end of May:

We had fairly healthy sales, but as you'll see in a moment, our investment ate up all the gains.  Here are the top 20 transactions for April:

and for May:

We bought a total of 10 Genolution implants for a hit of around ISK 800M.  Taking this investment out, we still would have been negative for the month (just barely) due to data core purchases.  There were also several purchases of raw materials for tech II production as we burned through the last of our tech II blueprint copies.

On the income side, you'll notice the usual mix of tech II items as well as some pieces of the starbase we sold off.  The bottom part of the transaction list is made up of mission loot sales.

That's it for the 100 Billion corp financial update, now let's talk about the EveKit Wayback Machine!.

EveKit Wayback Machine

I talked about this at Fanfest 2015 as potential future work and now I've finally got around to starting development.  It's going to take most of the summer to get this done.  More on the status below.

The EveKit Wayback Machine is a change to EveKit to retain history for ALL synchronized data, not just data which already has history (like wallet data).  What this means is that each time your character sheet changes (for example), we'll keep a copy of the previous version and store a copy of the new version.  We'll also change the APIs so that you can request a view of your data at a particular point in time, both from the usual web APIs, as well as from the bulk snapshot API.

Ok, so we're keeping a lot more data now.  What's the point of that?  We have a few ideas (some a bit silly):

  • You'll be able to measure your account activity over time (i.e. time series over login stats);
  • You'll be able to view how your assets are changing over time.  This gives you a way to measure consumption rates for things like ammunition and production inputs;
  • In general, you'll be able to compute rates for just about anything; how many industry jobs per unit of time; how many market orders placed per unit of time; etc.
  • For corporations, you'll be able to view member tracking over time which means you can do things like plot the location of members over time.

These are just a few ideas.

The development schedule looks something like this:
  1. Data model modification (DONE)
  2. Data model unit and integration tests (IN PROGRESS)
  3. API modifications
  4. Site QA and integration tests
  5. Data model migration tools creation
  6. EveKit Beta deployment and migration
  7. EveKit GA deployment

Developing tools to migrate from the current data model to the new data model look to be the most challenging part so far.  I'll provide an update in next months 100 Billion Corp. updating our progress.  That's it for this month!

Tuesday, May 5, 2015

100 Billion: April Income and Balance Sheet, identifying our tech II income sources

April was almost a carbon copy of March: we made about the same amount of money (net) although time in the game suffered due to a mix of real life obligations and the time we spent rolling out the new contributed applications feature.  After the numbers, I'll list out our main tech II income sources and do a quick calculation on tech II drones as a way to describe the margins we're seeing.

As I'm writing this, a significant announcement was made regarding EVE Online's twelfth birthday.  The TL;DR is that every active account is receiving a Genolution Core Augmentation CA-3 and CA-4.  If you've been paying attention to this blog, you'll know that our existing stock of these items represent a significant part of our asset value.  The introduction of more of these will cause prices to drop so we expect to see a big hit in the value of the corporation.  At the same time, this is a great buying opportunity.  It's very likely some players will decide to dump these items for some quick ISK.  I'm on my way to put in some buy orders now.

April By The Numbers

Here's where we were at the end of March:

and here's where we stand after April:

We see a healthy bump in cash (so yeah, we failed to make much of an investment this month...again), but really the big boost here is due to increase in asset value.  The asset value increase actually exceeded the drag on PLEX to fund the accounts, so staff equity jumped almost two billion over the course of the month.  Asset valuation is a fickle thing, we'll have to see how stable this increase is.  It may be a sign to sell, so let's look at the top asset valuation for April.

Here's the top 20 assets from end of March:

and here's the top 20 at the end of April:

And...Genolution Core's are up in value again.  That pretty much explains the big boost in equity (but see the note in the intro!).  There are also two new notable entries: the "t-shirts" which were given out to FanFest attendees.  Combined, these almost pay for one of the two PLEXs we need to fund the corporation every month.  I looked at some of the market data here and while CA-1's and CA-2's move pretty frequently, the CA-3 and CA-4 almost never sell.  I'll have to think a bit as to whether it's worth valuing these a different way.

I've started watching the Prosper show to get some ideas about potential investments.  Prosper usually covers trends in PLEX, minerals, moon materials, and some ships.  I don't feel like I have good enough tools yet to really try a large investment here.  Stay tuned for some upcoming ideas.

The income statement for the month shows continued stable income from tech II production (but still lacking any real analysis on where the best margins are).  Here's where we stood at the end of March:

and here's where we are at the end of April:

The income side was significantly better than last month, but we also accrued higher expenses.  The main culprit there (as you'll see below), was POS fuel.  We'll need this soon as we're fairly close to running out of blueprint copies for tech II production.  So we'll need to go through a round of invention to refresh our stock.  We've been doing invention in our POS for convenience (it's much closer than the nearest station supporting invention), but cost-wise that may not be such a great idea anymore.  Yet more analysis we need to do...  You'll also note we had even less time for mission running.  When we go back into a round of invention we'll need to pickup mission running to keep up reasonable income.

Here were the top 20 transactions by value for March:

and for April:

As we said above, we continue to drive fairly steady income from tech II sales.  Tech II drones continue to be an easy sale and this month we dumped stock in tech II rail guns.  0.01 ISK botters were mostly a nuisance this last month.  It's still on my list to document some strategies for dealing with these idiots.

On the debit side, we had to refill on Caldari fuel for our POS.  See below for some quick calculations on how running our own POS affects our profitability.  Prior to Crius or so, it was a no-brainer to run your own POS for any serious production.  Now, I'm not so sure.  The rest of the debit side of the month was spent on raw supplies for tech II production.

The one thing I didn't do in April which I said I might do is dump more Toxic Metals.  Before I do that, I want to work out a better strategy.  There's no hurry to dump this PI material at the moment as we don't need the cash.  What I'm trying to work out is whether I can efficiently produce enough of this to bring in significant income (think: several hundred million ISK).  Currently, I'm netting about 50000 units per month (net of using this material for production).  At current prices, I'll need about 6 times this amount just to make ISK 100M.  That's a major scale up.

That's it for the 100 Billion corp financial update, now let's talk about our tech II production choices and dive a little deeper on tech II drones.

Tech II Production Choices and Profitability

Successful industrialists in EVE know that PvP drives most production.  In high sec, where the 100 Billion Corp make a living, PvP is dominated by duels, mission fits, ganking and some fringe piracy (e.g. pirates popping into high sec briefly to pick up supplies).  Except for newbies or comedy fits, tech II or better is the fit of choice.  As a result, there's a very active market in the production and sale of tech II items related to PvP.  Some markets are busier than others, but most regions have room for producers selling lots in the small hundreds or less.

The 100 Billion Corp is currently active in the following Tech II modules (in no particular order):
  • Adaptive Nano Plating II
  • Small Armor Repairer II
  • Small Capacitor Booster II
  • Hammerhead II
  • Hobgoblin II
  • 1 MN Afterburner II
  • Damage Control II
  • 150mm Railgun II
  • Light Ion Blaster II
  • Light Neutron Blaster II
  • Warp Scrambler II
This list was very unscientifically constructed from a scan several months ago based on volume over a six month period.  In other words, I picked some tech II PvP materials which had fairly stable prices and which had no trouble moving in the market.  This means, barring over-production or serious competition in the market, I should have no trouble moving this stock.  Of course, all of that depends on being able to produce my stock efficiently enough that there is margin left over.

Let's take a deeper dive into the production of Hobgoblin II's, which are a regular source of profit for the 100 Billion Corp.  Excluding the lucky few that somehow got themselves tech II blueprint originals, production of all tech II items goes something like this:
  1. Make a copy of a tech I blueprint original.
  2. Use invention to produce tech II blueprint copies from tech I blueprint copies.
  3. Produce, mine or buy tech II production materials.
  4. Produce your tech II item.
Given this process, the first major decision is which components will be purchased on the market, versus built from raw materials, or mined (including Planetary Interaction).  This is where a spreadsheet comes in handy.  I started building a spreadsheet for this by hand, but then decided I could do a lot better by automating the breakdown of a component into all constituent parts, including the production processes for each part.  This would give us a chance to analyze buy vs. build at all stages.  So in the interest of getting this post out in a timely fashion, I'm going to summarize the big choices and main results, and post my sheet in a follow up blog entry.

The first two parts of tech II production require making a tech I blueprint copy (BPC), then attempting to convert that copy to a tech II blueprint copy.  Producing a tech I BPC only requires the blueprint original and a place to run the job.  This is "free" in your POS, otherwise you have to pay the cost of installing the job at an NPC station.  Of course, running in a POS is not really free as you have to pay for fuel.  More on that later.  When producing copies, it's important to produce copies with the maximum number of runs.  If you don't, then you won't max out the number of runs in your tech II invented copies.

Converting your tech I BPC to a tech II BPC is done by "invention" which requires one or more input materials and a roll of the dice: not all invention attempts succeed.  In the case of a Hobgoblin II BPC, the invention process consumes:
  • one Datacore - Electronic Engineering; and 
  • one Datacore - Graviton Physics.  
You can either buy these materials, or get them for free (other than time) from research agents.  Going the research agent route is slow because the production rate is very slow.  Therefore, I simply buy these data cores and occasionally harvest from my research agents to top off my stock.

The probability of an invention job succeeding depends on numerous factors which are nicely summarized on the wiki here.  You can find invention success calculators on the same page.  A successful invention run on a tech I BPC with max runs will produce a tech II BPC with 10 runs.  If the probability of success is X, then on average we'd expect to yield X * 10 Hobgoblin IIs out of each invention attempt  If the total cost of the data cores for one invention run is D, then invention cost of each Hobgoblin II is D / (X * 10).  This is the base cost of a Hobgoblin II before we include all the other materials needed to produce the final product.

Once we have the tech II BPC, the materials required to produce a Hobgoblin II are as follows:
  • 1 Morphite
  • 1 R.A.M. - Robotics
  • 1 Particle Accelerator Unit
  • 1 Hobgoblin I
  • 1 Guidance Systems
  • 1 Robotics

For the 100 Billion Corp, we've chosen to build everything except for Morphite, which we buy on the market.  We build Hobgoblin I's and R.A.M. components from minerals we recycle from mission running.  Although we build Particle Accelerator Units, we buy the raw materials (which are moon materials) from the market.  Guidance Systems and Robotics we build through Planetary Interaction (PI).  In summary, our expenses for production amount to the invention cost (see above), the price of Morphite, and the price of the raw materials for producing Particle Accelerator Units.

At time of writing, our expenses per Hobgoblin II are about ISK 75000.  This gives us a margin of about ISK 200000 depending on the market.  A more interesting question is whether we'd make more by selling the raw materials or production products which go into making a Hobgoblin II.  A quick spot check shows this is not the case mainly because there is still a hefty margin if we simply bought all the main components.  In particular, including the cost of invention, we'd still have a margin of at least ISK 50000 if we simply bought the six components above and sold the result.  Yes, Hobgoblin II's are good business.

What about the cost of running a POS we alluded to above?  Prior to the Crius expansion, it was almost mandatory to run copying and invention jobs in your own POS as there were typically very long waits for these slots in NPC stations.  After Crius, the limit on slots disappeared.  Instead, jobs will have variable cost depending on how active a station is.  There's also the inconvenience of having to move jobs to a station with the appropriate facilities.

For the 100 Billion Corp, we run a small Caldari POS which burns 10 fuel blocks an hour or about 7200 blocks/month.  At time of writing, a Caldari fuel block cost ISK 15929.  So the monthly cost of this POS is about ISK 114M.  That's a pretty serious drag on operations, about 7% of our total profit for a recent month.  It's about time to generate another round of blueprint copies and invention, so it may be a good time to experiment with running these jobs elsewhere and letting our POS shut down.  Stay tuned.

Friday, April 17, 2015

New client libraries, PHP client bindings, contributed applications and other significant improvements released to the beta site

A few days ago we released a substantial update to our beta site.  Many improvements have been made to the back end to make things more efficient, and a few creature comforts have been added to the front end as well.  We'll likely reflect these changes to the main site sometime this week.

I'll cover the minor changes at the end of the blog.  There are three big changes that I need to describe in more detail.  Without further ado:

Client Libraries Now Class Based

What this means is that the various client bindings we offer are now encapsulated in classes rather than exposed as top level functions which required all arguments to be passed on every call.  We made this change to make it easier to manage credentials and also in support of the new "contributed applications" functionality described below.  There is one exception: we didn't change the Java client library.  We'll do that eventually, be we left it for last because no one is really using that library at the moment.

Each client library now provides four classes:
  • CapsuleerAPI: this class exposes all methods used to access capsuleer data from a synchronized account.
  • CorporationAPI: this class exposes all methods used to access corporation data from a synchronized account.
  • ReferenceAPI: this class exposes methods for retrieving EVE server reference information (e.g. the current skill tree).
  • SDEAPI: this is actually two classes, one for each of the two latest EVE Online releases.  These classes expose methods for retrieving Static Data Export (SDE) information.
To use the new API, you first instantiate one of these classes and pass EveKit API key information into the constructor.  You can then call the methods of the class without having to present your EveKit API key on every call.  The SDE API also allows you to specify the name of the release you'd like.  If you don't specify a release, then you'll get the API for the latest release.  If you're release agnostic, then upgrading your code just got easier: just never pass a release string into the SDE API constructor and you'll always use the latest release.

NOTE: this change does not actually change the underlying REST calls.  Instead, this change repackages how the various client bindings are exposed.  If you're making direct REST calls, you won't be affected by this change.  Likewise, if you've downloaded an older version of the client, then that client will continue to work until you need a feature only present in a newer release.

Let's look at a few examples in Google App Script (essentially, Javascript without requiring callbacks) to see how your code will change.  Before the change, getting your corporation assets might look like this:

var apikey = 1234;
var apihash =  'FA8EB656E23C0AE73796F9D17E7A0290B2BA3952BF89C3B1E4A35FDE480E6E06';
var assetResponse = commGetAssets(apikey, apihash);

In the new code, there is one extra step:

var apikey = 1234;
var apihash =  'FA8EB656E23C0AE73796F9D17E7A0290B2BA3952BF89C3B1E4A35FDE480E6E06';
var corpAPI = new CorporationAPI(apikey, apihash);
var assetResponse = corpAPI.getAssets();

However, once you've created the CorporationAPI instance, you don't need to worry about API credentials any more unless someone changes the credentials on the EVE Online support page.  The same pattern works for the SDE API.  Before the change (retrieving list of agent types here):

var sdekey = 1234;
var sdehash =  'FA8EB656E23C0AE73796F9D17E7A0290B2BA3952BF89C3B1E4A35FDE480E6E06';
var agentTypesResponse = scylla_agtGetAllAgentType(sdekey, sdehash);

In the new code, you now instantiate an appropriate SDE class and make the call on that:

var sdekey = 1234;
var sdehash =  'FA8EB656E23C0AE73796F9D17E7A0290B2BA3952BF89C3B1E4A35FDE480E6E06';
var sdeAPI = new SDEAPI(sdekey, sdehash, 'scylla');
var agentTypesResponse = sdeAPI.agtGetAllAgentType();

If you leave the release name off of the call to "new SDEAPI" then you'll get the latest release.  Regardless, this normalizes the calls across versions so most of your code won't have to change when a new SDE comes out.

PHP Client API released

To accompany the change in how we present the client API, we've also released PHP client bindings.  You can download the code straight from the GitHub site or if you're using composer you can pull the package from packagist using the package name "dark-planet-labs/evekit-php".  The GitHub page contains complete instructions for how to integrate the code.

The PHP bindings are used in the same manner as the other bindings.  For example, the two code snippets above look as follows with the PHP bindings:

// See the GitHub site for details on how to ensure the bindings are in your path
use EveKit\EveKit;
// EveKit API key and hashcode.
$apikey = 1234;
$apihash = 'FA8EB656E23C0AE73796F9D17E7A0290B2BA3952BF89C3B1E4A35FDE480E6E06';
// Create an appropriate API instance
$api = EveKit::getCorporationAPI($apikey, $apihash);
// Retrieve and echo asset tree
echo $api->getAssets();
// Now let's pull something from the SDE
$sdekey = 5678;
$sdehash = 'FA8EB656E23C0AE73796F9D17E7A0290B2BA3952BF89C3B1E4A35FDE480E6E06';
// If we omit the last argument in this next call, then we'll get the API for the
// most recent release.
$sde = EveKit::getSDEAPI($sdekey, $sdehash, 'scylla');
// Retrieve and echo the list of agent types
echo $sde->getAllAgentTypes();
PHP calls return instances of EveKit\API\Response or EveKit\API\ResponseList as appropriate.  The structure of these objects follows the structure of similar objects in the other client bindings (e.g. Javascript).  One difference is that the PHP bindings throw exceptions on errors (like the Java bindings) as opposed to returning an error type (like the Javascript or GAS bindings).  Data types for API calls are defined in the EveKit\Types package.

Contributed Applications and the AppBridge

It's long been the goal to make EveKit a platform for others to develop their own third party apps.  The new "contributed application" feature is an attempt to further this goal.  A contributed application is just a third party website that you register with EveKit.  An EveKit user can then choose to "instantiate" a contributed application, in which case EveKit makes it possible for the contribute application to access EveKit data on behalf of the instantiating user.  The goal here is to simplify and standardize the way one builds applications designed to work with EveKit.

The details of this feature were described in a previous post, but here it is again with more careful explanation.  There are two logical parties involved in any contributed application: the application contributor, and the application user.  The application contributor is responsible for creating the contributed application, which consists of the following:
  • A unique name and description;
  • A URL pointing to the application web site;
  • An indication of whether the application should launch in a new page (this is needed for certain websites which don't allow authentication from a frame); 
  • A public or private designation; and,
  • One or more key-value pairs which represent the initial state of the app (these are strings).
Contributed applications are associated with the EveKit screen name you authenticated as at the time the application was contributed.  If you choose to make a contributed application public, then it can be searched and used by any other EveKit user.

An application user can choose to instantiate a contributed application.  An application instance has the following features:
  • A unique name;
  • An indication as to whether the application is allowed to use the user's SDE key; and,
  • A list of capsuleer or corporation access keys that should be made available to the instantiated application.
An instantiated application will appear in the "Apps" menu when the instantiating user is logged into EveKit.  When a user selects an instantiated application, a new frame or tab is opened using the URL of the contributed application.  The query string of this URL will contain two special parameters "evekitkey" and "evekithash" which represent a key-value pair the application can use to access the private key-value store of the application (including any API keys that have been shared with this application).  Through this mechanism, the contributed application can then access the exposed data of the application user.

The new EveKit client libraries include an "AppBridge" class which simplifies implementing contributed application websites.  This class is instantiated with the values of "evekitkey" and "evekithash", and provides convenience methods for interacting with the private key-value store of the instantiated application (including retrieving API keys).  Here's a snippet of code showing how the AppBridge class can be used in a PHP based contributed application:

// Pull in the EveKit client bindings
use EveKit\EveKit; 
// Extract evekitkey and evekithash from the URL
parse_str($_SERVER['QUERY_STRING'], $qstring);
$ekey = $qstring['evekitkey'];
$ehash = $qstring['evekithash'];
// Create the AppBridge.
$bridge = EveKit::getAppBridge($ekey, $ehash);
// Contributed applications may have a limited set of configuration data.
// You can read a configuration value as follows:
$val = $bridge->getConfig("somekey");
// You can save a configuration value like this:
$bridge->setConfig("somekey", "somevalue");
// For this example, let's assume the user assigned the SDE key and a corp
// key to this application.  You can get all the appropriate Corporation APIs
// like this:
$corpAPIs = $bridge->getCorporationAPIs();
// You can then make an API call as in the example above, e.g.
// (in this example, there is only one corp key)
$assets = $corpAPIs[0]->getAssets();
// The SDE API is equally easy to use, e.g.
$agentTypes = $bridge->getSDEAPI()->getAllAgentTypes();
// If you want a particular SDE release, you can also use this form:
$agentTypes = $bridge->getSDEAPI('scylla')->getAllAgentTypes();

The AppBridge provides raw access to the underlying API keys if needed, but in most cases you should only need to use the API convenience functions provided by this class.

Fine Print

And now some fine print around the contributed application feature:
  • Application names (both contributed and instantiated) must be alphanumeric (including underscore) and at least two characters in length;
  • Contributed application names must be unique among all applications contributed by the same user.  Likewise, instantiated application names must be unique among all applications instantiated by the same user;
  • The URL for a third party app must be less than 1000 character in length.  You're free to embed a query string but avoid the reserved strings "evekitkey" and "evekithash" which are used by EveKit to pass credentials to the instantiated application;
  • You can change most features of a contributed application at any time after it is submitted (if you were the original contributor);
  • Users "capture" a snapshot of your contributed application when they choose to use it.  This means that you can't break existing users if you decide to modify or remove a contributed application after one or more users have decided to use it.  You'll need to use other means to communicate with existing users of your application (e.g. if you need to make upgrades);
  • The private key-value store for an instantiated application has the following limits:
    • Keys must be alphanumeric (including underscore and period), must be at least one character long, and no longer than 300 characters;
    • Values must be strings no longer than 2048 characters;
    • Keys may not start with the reserved prefix 'evekit_';
    • The initial key-value store for an application may not have more than 200 key-value entries; and
    • An instantiated application may not have more than 300 key-value entries.  Note that any API keys assigned to the instantiated application consume one entry per key.

Other Improvements

There are a few other quality of life changes on the beta site.  For example, accounts are now clearly marked with red text when their XML API key has expired.  Likewise, the account synchronization history view uses a new color scheme to make it clear when certain data was not sync'd because the XML API key doesn't allow access.

Friday, April 3, 2015

100 Billion: March Income and Balance Sheet, shrinking to two accounts, and (finally) a description of what the 100 Billion Corp actually does!

March has come and gone and the 100 Billion Corporation actually made some money, but not enough to overcome the PLEX load we're charging ourselves.  It turns out we can't fill up three full EVE accounts with activity yet, so we're shrinking to two accounts to reduce the PLEX load.  More on that below.  I went to FanFest, saw some Icelandic nature, and gave a talk about development on Google App Engine.  Check out the link if you're interested, and the numerous FanFest recaps others have posted.  We finish off this entry with a description of what the six characters which make up the 100 Billion Corp actually do to make ISK.

March By The Numbers

Let's take a look at the balance sheet first.  Remember that a balance sheet is a record of a company's assets and liabilities at a given point in time.  Here's what things looked like at the end of February:

and here's where we stand after March:

This is pretty much flat month to month except that staff equity decreased by ISK 2 billion as we continue to struggle overcoming the PLEX tax.  There's one new liability here labelled "Historical".  This is how we're recording the fact that we had three PLEX'd accounts for the first three months of the company, and the sum here is exactly the cost of buying three PLEX for one account at the beginning of the first three months of the year.  For now, we'll just keep two accounts for the corporation, to the tune of about ISK 1.5 billion per month.  So that's what we need to bring in to stay even.  Staff equity wise, we would have done better if we'd never paid for that third account.  Due to company income and asset appreciation, we would have been flat across the board.  As it stands, however, our investors lost another ISK 2 billion this month.

FanFest and other real life duties kept me from finishing some of the tools I had planned to make some of this tracking easier.  However, I am planning a significant EveKit release in about two weeks (mid-cycle for EVE Online releases) which will have some changes I need to support these tools.  I'll be posting a blog entry in a few days describing the changes.

Let's now look at the asset valuation for March.  Here's the top 20 from the end of February:

and here's the top 20 at the end of March:

It's worth mentioning at this point that I had to switch asset valuation sources early in March.  Previously, I had used EVE Marketdata to retrieve asset prices in The Forge.  However, the site had a major several day outage during which I decided to switch to EVE Central.  There are some clear differences in prices which are cause for concern.  A significant "to do" is to switch to the new CREST market endpoint instead, but I haven't got around to that yet.

The most notable differences month to month are the massive increase in value of the Genolution Core Augmentation CA-3, and the complete disappearance of the Genolution Core Augmentation CA-4.  The former moved up about 20%, and the latter didn't even make the top 20.  The price of the CA-4 at the end of the month was ISK 39 million.  That's likely an anomaly due to someone making a very foolish sale of a high value item.  Since the balance sheet is a snapshot in time, it's bound to be affected by anomalies like this.  It's also notable that Toxic Metals continue to rise significantly.  We actually dumped some of our stock in March to generate some cash flow, we may do more of the same this month to lock in some profit.

Overall, the message from this balance sheet is basically the same as for the last few months:

  • We're carrying too much of a cash balance.  A goal for April is to invest at least ISK 1 billion in a long term play of some sort.  It's probably too early to buy PLEX.  Toxic metals is an interesting play, however.  Also, there was a change announced on the O7 show last night in which major materials changes were discussed.  I still need to digest, but this is another possible play although one in which many others will participate.
  • We did better this month, but we're still not making enough to keep the company afloat.

Let's move on to the income statement.  Here's where we stood at the end of February:

and here's where we are at the end of March:

What changed?
  • We're in the green from an income point of view.  With this income, we essentially paid for one of the three PLEX we were carrying into the month.
  • The vast majority of our income was from selling produced goods on the market.  More on that below.
  • We had less time for mission running this month, so that part of our income suffered a bit.
  • PI taxes were again a significant part of our expenses, which is not surprising given how much we rely on PI for our production business.
Let's look at the top 20 transactions by value.  For February:

and for March:

For March, we diversified a bit in what we sell and ended up making most of our income from tech II drones.  Our stock in Small Armor Repairer II is lower, hence less money from those sales.  Competition also picked up around the Small Armor Repairer II for reasons I don't yet understand.  When this happens, the 0.01 ISK botters show up and it takes significantly longer to sell my stock (remember: I promised not to use any bots, not only is it not legal, it's not cool for my experiment).  Tech II drones are extremely reliable income, they sell very quickly in the hub I sell them in.  Random mission loot rounded out the bottom of the list as usual.

The debit side of the ledger is dominated by pre-production items.  That is, raw materials for items used in tech II production.  The one exception was Electronic Engineering data cores, which are used for tech II blueprint invention.  Overall, the margins here were very nice although you can't see the mineral or other material costs that went into the tech II production. I'll need to post a separate spreadsheet to show that.

You'll note on the income side that I dumped some of my Toxic Metals stock this month.  The price trend around Toxic Metals suggest I should do some more of that again to lock in some profit.  We have more than enough stock for our current needs, I can easily dump half the stock and not miss it.

That's it for the 100 Billion corp financial update, now let's talk about what the company actually does.

The Business of the 100 Billion Corp

The 100 Billion Corp is (now) composed of six characters, all dedicated solely to the corporation.  The company generates income from the following activities:
  • Mission Running: Two of the characters are used in a multi-box setup to blitz level 4 missions.  Typically, one character runs the mission (in a Tengu), while the other follows up behind to collect salvage.  A small set of tougher missions require both characters to run, then we bookmark and collect the salvage later.
  • Tech II Production: The main income source of the company at the moment is tech II production of the following items: Adaptive Nano Plating II, Small Armor Repairer II, Small Capacitor Booster II, Hammerhead II, Hobgoblin II, Damage Control II, 150mm Railgun II, Light Ion Blaster II, Light Neutron Blaster II, 1MN Afterburner II, Warp Scrambler II.  I generated this list from a not very scientific scan of items which are often used for PvP fits and which have reasonable volume.
  • Planetary Interaction (PI): We use PI mainly to produce materials needed for tech II production.  We currently produce: Construction Blocks, Mechanical Parts, Miniature Electronics, Rocket Fuel, Superconductors, Transmitters, Guidance Systems, and Robotics.  Any other materials we produce by buying raw materials and running production jobs.  The list here was chosen largely to support tech II production, although the company made its first billion almost solely on the back of selling robotics on the market.
  • Market: we sell the vast majority of our tech II production on the market, as well as any "valuable" mission loot or rewards (e.g. implants given as mission rewards).  We occasionally dump some of our mineral stock as well.
  • Investments: we have a small collection of items we're holding as investments, usually awards or gifts from CCP in the past which we aren't using (e.g. certain implants).  We haven't sold any of these yet to generate cash.
Most of the six characters in the corporation are multi-taskers (meaning: they trained skills for multiple roles), but generally the characters get used as follows:
  • Character 1 (C1): mission running, mining, PI, invention, production, market
  • Character 2 (C2): mission running, mining, PI, production
  • Character 3 (C3): PI, market, production
  • Character 4 (C4): mining, PI
  • Character 5 (C5): PI
  • Character 6 (C6): PI
One thing I almost never do is mine!  I still do this occasionally, but usually as a background task while I'm doing something else (like hacking on EveKit).  Instead of mining, we salvage or re-process a fair amount of mission loot.  A typical session of mission running goes as follows:
  1. Run one or more missions with the primary character, use the secondary character to follow the primary and loot/salvage.
  2. For all mission loot:
    1. Salvage items which can be used in production are saved;
    2. Ammo we use is saved (mostly missiles);
    3. Drones we use for production are saved (e.g. Hammerheads or Hobgoblins);
    4. Items which can not be re-processed are either saved (if they are worth at least ISK 400000), or are immediately discarded or sold;
    5. Items which can be re-processed but which are worth at least ISK 400000 are saved to be sold on the market;
    6. Everything else is reprocessed into minerals and used for production.

We use the EVE client estimated value of an item when deciding what to do with mission loot.  This is the value shown in the client when hovering over an item in your inventory.  It's not perfect, but it's a reasonable estimate for quickly sifting through mission loot.  The ISK 400000 threshold is also a bit arbitrary.  It's my estimate of large enough value to justify carrying an item to a market hub for sale.

Generally speaking, we sell all production or loot items at a hub using limit orders (a sell order with a specific price).  We occasionally sell with market orders instead (meaning, an order which immediately sells at the current best bid price) when the spread (the difference between the best bid order and best ask order) is very small.  This most often happens with mission loot, where the volume is so low it's simply not worth the time to periodically reset the order to deal with competition.

The activities above consume a fair amount of my time.  A typical week looks like this:
  • Daily: log in at least once to reset competitive market orders, complete any finished production jobs, and start new production jobs.  This takes about 30 minutes a day.
  • Twice a week: reset PI jobs.  We typically run four day resource extractions, with transport of some resources to drive PI production jobs.  I've honed this down to a fairly tight procedure which I can get done in 30 minutes if there are no distractions.
  • Weekends: usually at least one mission running session lasting two hours or so.  I have to sacrifice this for vacations, family time, etc.
  • Every other month or so: invention of tech II blueprints.  I normally produce 200 run blueprint copies (or whatever the maximum is for a given blueprint original), then gather enough data cores so that I can run large batch invention jobs.  A typical invention run takes around two weeks to complete and generates enough stock to allow production for a month or two.
It's very easy to get into a rut with the above schedule, so I tend to use the mission running time to experiment or try some new things, like look for possible new production targets.  Very rarely, I'll mine instead of mission run, and use this time to hack on EveKit, write blogs, catch up on EVE news, etc.

Hacking on EveKit and keeping up with EVE news is another major time sink, but I'll leave that for another entry.

That's all for this month's income report.  Expect another entry in a few days describing the upcoming EveKit release.

Saturday, February 28, 2015

100 Billion: February Income and Balance Sheet, and Upcoming Features in EveKit

February is almost in the books and the 100 Billion Corporation is still negative for income, and yet the balance sheet is better.  What gives?  Also, yours truly suffers two stupid ship losses and pays for it.  Interesting factoid: insurance payments don't show up in your wallet, they just magically get added to your balance.  So you won't see these payouts in the income statement this month.  Finally, I talk a little bit about some changes coming in EveKit.

February By The Numbers

Let's take a look at the balance sheet first.  Remember that a balance sheet is a record of a company's assets and liabilities at a given point in time.  Here's what things looked like in January:

and here's where we stand after February:

Overall, the 100 Billion corporation increased in value by about ISK 1.1 billion, but actual equity in the company decreased by about ISK 1.5 billion.  This is because the increase in company value is not keeping up with PLEX cost.  We've had to pay for 6 PLEX so far (two months worth of business for three accounts).  Remember that I'm trying to simulate a company where I have to pay for the PLEX for the employees of the company (I'm not actually buying PLEX to keep the company afloat).  At this rate, we're 70 months away in absolute terms from hitting 100 billion, and we'll never hit it if PLEX cost is counted.  So...we better get cracking on a better solution!  I didn't get around to modifying the balance sheet to single out fixed assets, versus investments, versus inventory.  Instead, I spent time working on changes to EveKit to make these kinds of changes easier.  Hopefully I'll have this ready for the next report.

Most of the increase this month came from equipment value which grew from ISK 16.4 billion in January to ISK 18.6 billion in February.  Let's take a look at our top asset values to see where the increase occurred.  Here's the top 20 from the end of January:

and here's the top 20 at the end of February:

Some assets moved up due to general appreciation (e.g. ships and implants).  The big winner was Toxic metals which increased in value by 25% (and our inventory increased as well).  Caldari Navy Admiral insignia also had a nice move up of about 13%.  Keep in mind that these are point in time snapshots, not trends, so I'm not getting too excited yet, but I WILL keep my eye on toxic metals.

What else does this balance sheet tell us?

  • We're carrying ISK 1 billion less in cash.  We'll see more detail about this below, but a good chunk of that cash was spent replacing ships.  The rest was spent buying data cores to support invention.  So while we're putting some of our large cash balance to work, most of it is still sitting idle.  We need to start looking for a good investment.
  • Toxic metals look a bit like a cash cow.  They cost little to produce (via Planetary Interaction) and seem to be going up in value.  It may be time to cash some of the inventory out in case we're at a local peak in value.
  • We'll be bankrupt in two years unless we stop counting PLEX costs or find a way to drive up company value.

Let's move on to the income statement.  Here's where we stood at the end of January:

and here's where we are at the end of February:

What changed?
  • We're still in the red in terms of cash flow.  That's not always a bad thing if you're buying materials for production, or burning money for investments.  Unfortunately, it IS mostly bad spending for February.
  • We sold about the same as last month as indicated by the "Market Transaction" row on the income side.  However, we bought more stuff as indicated by the "Market Escrow" row on the expense side.
  • Corporation account withdrawals have been removed from the sheet since they always balance out (because we include employee wallet when determining income).
  • We ran significantly more missions than last month, and our bounty prizes doubled.  Agent mission rewards tripled compared to the previous month.
  • All told, we had ISK 150 million more income this month.  Not a big increase but it's a start.
  • Planetary export tax doubled and planetary import tax tripled.  This isn't due to an increase in tax rate, it's because three more characters moved to participating in PI.  More about that in a follow up post.
  • We got fined for contraband because I wasn't paying attention while looting after a mission.  Sigh.

So much for the high level numbers.  Let's look at the top 20 transactions by value.  For January:

and for February:

The top income source was once again Small Armor Repairer II with higher volume than last time.  Drones also brought in decent income.  A small amount of money was made off of mission loot, for example 100MN micro warp drives.

The debit side of the ledger shows the pain of a few bad decisions, but also some future investment:

  • I lost the Tengu I bought in January by not getting out fast enough in a level 4 mission I didn't have a very good fit for.  Insurance paid back ISK 100 million, but the loss still hurt and I decided to buy another in February.  It will take another month or two of mission running to pay that off.
  • I lost a Crane during some low-sec trading experimentation where I ended up getting ganked.  This ship was NOT insured, so the default insurance paid out ISK 13 million.  I was insta-locked so I'm not sure if I could have gotten out of this one with a cloak activated.  Historically, the align speed of my Crane was fast enough that this wasn't a problem.  I'd owned this ship for a least a year, maybe longer, without any similar incident.
  • We spent quite a bit on data cores and production materials this month.  The changes a few releases ago to production mean that tech II blueprint copies end up being much more numerous.  In other words, it takes me a lot longer to finish building all the tech II blueprints I end up with after research.  This all means that data core purchases won't be as frequent, maybe every two to three months.  I'm able to fill some data core needs through research, but the rate of core generation is fairly low going that route.

Lot's of good takeaways from this month:

  • Stop losing ships!  This is costly unless I start losing much cheaper ships.  There's really no excuse for losing a ship in a level 4 mission.  I can't do much about ganking other than to minimize my exposure and think about using a better fit ship.
  • I should maybe dump some of the toxic metals after checking price trends.  The jump this month suggests a peak, might as well cash in a bit.
  • I'll need to run the numbers on tech II production.  I'm not sure I'm making great margins on everything I'm producing.

That's it for the 100 Billion corp, now some discussion about what's going on in EveKit.

Upcoming Changes to EveKit

One of my goals is to create all the tools I need to manage the 100 Billion corp using EveKit.  EveKit already has all the data and SDE, but so far I've been using Google Sheets to run the balance sheet and income statement.  Google Sheets doesn't actually add much here other than to provide a table based display.  That is, I'm not really using spreadsheet functions in any significant way.  Most of the hard work for the monthly reports is in the Google App Script supporting the sheet.

The upcoming release of EveKit is intended to make it much easier to integrate third party applications with EveKit.  The long term goal of EveKit is to be an EVE third party tool platform.  There's still lots of work to do here, but to make things a little easier, we'll be rolling out the concept of an EveKit Contributed App.

An EveKit Contributed App is just a third party web page that users can register with EveKit and either use themselves or share publicly with other EveKit users.  An EveKit user can instantiate a contributed app at which point EveKit storage is set aside for use by the app on behalf of the registering user.  This allows contributed applications to customize their behavior based on the user.  The per-app storage can also be used to provide access to EveKit data access keys.

The whole process works as follows:
  1. First, a user creates a contributed app.  A contributed app consists of:
    1. A name and description of the app.
    2. The URL of the web page which serves the app.
    3. The EveKit screen name of the user contributing the app.
    4. An indication of whether the app is public (public apps can be found and used by any EveKit user).
    5. One or more key-value pairs which can be used to initialize the app the first time it is created for a user.
  2. Second, another user (or the same user) decides to use a contributed app.  Contributed apps are searchable via EveKit on the name of the app.  When a user decides to use an app:
    1. The user names their instance of the app.
    2. The user specifies whether the app has access to their SDE access key.
    3. The user can choose one or more corporation or capsuleer access keys to make available to the app.
  3. Finally, when a user launches an app:
    1. A frame or new tab is opened using the URL specified in the contributed app.
    2. A "key" and "hash" query parameter are passed in the URL which gives the contributed app access to the state for this instance of the app.
    3. The contributed app instance can access the state of the app to retrieve any initial state specified when the contributed app was defined, as well as any keys the owning user has decided to make available to this app.
    4. The contributed app instance is free to change or set new key-value pairs to maintain state on the app instance.
It sounds confusing but it's actually pretty simple.  I'm hoping to release this feature around 2015-03-07 along with a demonstration video.