Friday, January 30, 2015

100 Billion: Balance Sheet and Income Statement

At the end of my last post I mentioned that the next step in the 100 Billion project was to produce a balance sheet and income statement.  I've created these sheets for the 100 Billion corporation (not its real name).  In this entry, I'll discuss what we'll use these sheets for and what we know so far about the effort to hit 100 billion ISK.  At the end of the post, I'll describe how I built these sheets and provide links if you want to use them for your own purposes.

Balance and Income for the 100 Billion Corporation


A balance sheet is a snapshot of a company's financial condition, usually on a specific date.  A traditional balance sheet has three sections:
  1. Assets, usually listed in order of liquidity (that is, how easy it is to convert the asset to cash)
  2. Liabilities (debt or things we owe other people)
  3. Ownership equity, which is almost always assets minus liabilities.  This is the net worth of the company.
Because of the relationship between assets, liabilities and equity, a traditional balance sheet will presents assets on the left side of the sheet, and liabilities and equity on the right, with the two sides balancing.  I've created a traditional balance sheet for the 100 Billion corporation.

An income statement shows a company's revenues and expenses for a given time period.  Typically, revenue and expenses are summarized according to one or more categories.  When done well, an income statement shows exactly how a company makes its money by showing which activities produce the most revenue, and which activities are the most expensive to pursue.  It goes without saying that when revenue exceeds expenses, the company makes money.

With those preliminaries out of the way, let's take a look at the current balance sheet and income statement for the 100 Billion corporation.  Note that for accounting purposes, I'm declaring 2015-01-01 as the official start date of the project.  So all accounting records will be referenced to that date.

Balance Sheet



As I mentioned in the previous post, the 100 Billion corporation is starting off with assets and cash from when it was the 10 Billion corporation.  So the company already has a healthy cash balance of around ISK 11 Billion.  Since all the members of the corporation are solely dedicated to its activities, we're also including the cash balances of those characters.  This puts the cash assets for the corporation at around ISK 12 Billion.

The next section in "Assets" lists equipment which is literally the EVE assets of the corporation and all its members.  Once again, we're combining the assets of the corporation and its members.  This is because a substantial part of the value of the company is the ships the company has purchased for use by its members.  The value of equipment here is simply the EVE Market Data price (in Jita) of the asset on the day the report is generated.  Equipment value is substantially higher than I expected, indicating that more than half the gross value of the company is stored in equipment.  That's actually a good thing, but more on that in a bit.

On the liabilities side of the sheet, the main liability is the PLEX cost of maintaining all the accounts used for the corporation.  We compute this cost by computing the current PLEX cost in JITA at the start of each month and multiplying by the number of accounts.  The company is less than a month old, so we've only had to (virtually) buy three PLEXs so far.

The last part of the liabilities section is owner equity which is just assets minus PLEX cost.  This is the net value of the company.  Our goal is to get this value to 100 billion ISK.

What does the balance sheet tell us so far?  Some observations:
  • We have a healthy cash balance, but probably too much.  There's no reliable way to generate interest on cash balances in EVE so this money isn't working for us.  We need to figure out our monthly operating costs so that we can reduce this balance down to just enough to let us conduct business.
  • We have a lot of value in corporation equipment, but it's not clear how much of this is liquid (things we plan to sell as part of the business) and how much of this is fixed assets or investments (things we'll never sell or things we'll sell as an investment later on).  It's probably worth breaking this down into liquid, fixed and investment assets.
  • It looks like we're already a quarter of the way to our goal, but the reality is that PLEX costs are going to eat us alive if we can't find a way to generate significant income.  Each account will have to generate ISK 800 million per month just to break even.
A lot of the net value of the company is in equipment, so let's take a look at the top 20 contributors to asset value:


Interestingly enough, the first ISK 6.5 billion in asset value is from gifts and promotions.  I'd forgotten I even had these. There are a few other promotional items further down the list as well.  These all look like investments to me and should be categorized and tracked as such.  The next two big items are ships assigned to staff.  In a traditional balance sheet, these would be called fixed assets.  That is, things which will be used for a long time by the company and likely not converted to cash unless the survival of the company depends on it.  The remaining items would likely be classified as "inventory".  That is, things we plan to sell as part of business operations.  For next time, we'll use EveKit to categorize these assets for better tracking.

Income Statement


Let's turn now to the income statement.  We're close enough to the end of January that I think it's safe to call this our income statement for the first month of the company:


The left side of the table shows all income for the corporation and any staff as pulled from the journal log for the current month.  The right side shows all expenses for staff and the corporation.  The summary at the top shows the net income, which is just total income minus total expenses.

What does the income statement tell us about the company so far?
  • First off, we lost money this month.  We operated at a deficit of ISK 900 million.  Ouch.
  • Cash transfers solely within the corporation appear on both sides of the sheet.  Everything balances out, but we should remove these transactions in the future to get a clearer picture of company operations.
  • The company currently makes most of its money selling stuff in the market.  Almost ISK 1 billion was made this way.
  • The next biggest income source was mission running, at about ISK 100 million.
  • The largest expense in the company is buying things from the market.  That certainly warrants some investigation!
  • Planetary export and import taxes are another big expense.
The punch line is the company lost money this month because we either bought too much or bought some expensive things from the market.  Let's take a look at the top 20 transactions on both the income and expense side:


On the income side, we made most of our money selling various tech II ship equipment (and apparently a spare Tengu propulsion unit we had lying around).  On the expense side, we decided to buy a Tengu for mission running and this took a nice bite out of our profit for the month.  Ignoring the Tengu purchase, most of the expenses were used to support invention and production of tech II space equipment.  And now the bad news: taking the Tengu out of the picture, we still would have lost money for the month (although substantially less).  That's not good.

We'll need to break out the spreadsheets to get a handle on what's profitable and what's not.  We'll leave that for next time.

Takeaways and Conclusion


The 100 Billion corp is off and running and we have a few basic tools to get a handle on operations and income.  Here's what we need to do before next month's balance and income statement:
  • We'll reclassify assets as either investments, fixed assets or inventory.  We'll also add some tools to start tracking investment value over time.  As investments appreciate (or depreciate) we can add these values to the income statement. 
  • For the tech II items we're selling in the market, we'll need to start tracking production costs against market value so that we can estimate what is profitable (and what isn't) and what our margins will be.
That's it for this month.

Appendix: How It's Made


All tools created for the 100 Billion project will be stored in this Google Drive folder.

The balance sheet and income statement I used for this entry come from a Google Docs Spreadsheet which pulls data from EveKit and EVE Market Data.  I've shared the spreadsheet here (there are usage instructions on the spreadsheet).  You'll need three things to make this spreadsheet work:
  1. An EVE Market Data character name.
  2. Your SDE key from EveKit which you can find here.
  3. One or more EveKit sync account keys.  You can create these keys from the account list here (select "Access Keys" for the appropriate accounts on the right).
All of this information is entered on the "Accounts" sheet in the workbook. This spreadsheet will work for any combination of corporate and character accounts as long as the provided access keys can access assets, the wallet journal, and wallet transactions.  When you have everything configured, select either "Update Balance Sheet" or "Update Income Statement" from the "100 Billion" dropdown menu.  

The sheets included in the workbook are as follows:
  • Balance Sheet - balance sheet for configured accounts computed as of the current date.
  • Income Statement - income statement for the date range specified at the top of the sheet.
  • Transaction Summary - sorted transaction summary for the income statement.
  • Asset Values - sorted asset valuation using current prices from EVE Market Data.
  • PLEX prices - average PLEX price at the start of each month.
  • Accounts - EveKit access key configuration.

Most of the hard work is done in a Google Application Script which you can view by selecting Tools ➞ Script editor...

Sunday, January 18, 2015

The 100 Billion Project

I play EVE solo.  My play style is high-sec care bear: mostly industry with a bit of mission running every now and then.  This wasn't always the case.  I was in a small corp once, but time zones and the demands of the real world didn't allow much time to participate.  I'd probably be a useful industry player to one or more corps, but it's never really worked out that way.  The craziest I get is to use one of my alts for faction warfare every now and then.  It's been this way for about five years now.

Many players would ask why I continue to play.  In a game where much of the content relies on banding together with other players, what's left for the solo player beyond PVP or photo tourism (neither of which I do...yet)?  For me, the answer is the solo business enterprise.  That is, the challenge of building a large and profitable business all by myself.  When you go solo, you can't rely on corp mates to help you mine, or produce products for the market.  You'll have to do those things yourself.  And if you resort to mining for the rest of your life, you'll be old and grey before your business ever gets anywhere.  If you want your business to be a serious contender, you'll have to do things a little differently.

I enjoy this type of play because it highlights my favorite features of EVE as well as my favorite past times.  Everyone knows that EVE has complex game mechanics, hence the nickname "spreadsheets in space".  Any serious space tycoon, especially a solo tycoon, will need to use many out of game tools to get ahead.  As it happens, I'm a developer by trade and I enjoy personal coding projects.  There is no shortage of such projects for the serious EVE player, especially the solo space tycoon.  What's more, CCP actively embraces the third party developer community, providing data and APIs to support out of game tools.

In the end, it's the drive of the solo space tycoon that keeps me going.  Can I, through a combination of wit and hard work, and probably lots of coding, build my own space empire?  I guess that depends on the goal...

The 100 Billion Project


My goal is to accumulate 100 Billion ISK as a solo EVE player.  This is really a proxy for building a successful EVE empire, I just don't know what that empire will look like yet, so I use the net worth as the goal instead.  This is my third such goal.  The other two were: accumulate 1 Billion ISK solo (pretty easy), and accumulate 10 Billion ISK solo (a little harder but achievable over a period of months with regular, but not obsessive, play).  I'm starting this project on the heels of the 10 Billion ISK project, so I already have a little over 10 Billion ISK and a few accounts with well trained characters.  I also have the small corporation I used to achieve these goals.  The only members of this corporation are characters from my own accounts.

Obviously, I could get there pretty quickly by dumping real money into PLEXs and cashing out.  That would be silly and expensive.  Here are the ground rules for what I mean by "going it alone":
  • ONE HUMAN: I can open as many accounts as I want, but I'm the only one allowed to play them.  I can't ask friends or other humans to play for me.  If I can manage to train my cats to play for me, then that's fair game.
  • NO BOTS: Duh.  As a developer, I'd love the challenge of writing a market bot, but all of this is against CCP rules.  Note to self: ask CCP if they've ever thought of opening a server where bots were allowed.
  • ACCOUNTS = LIABILITIES: To balance the books, and keep myself honest, I'll deduct the cost of each of my accounts monthly from my net worth using the current best offer price for PLEX.  I may pay for accounts with real money or PLEX, but this will always show up as a PLEX liability in the books.  Also, I won't open any trial accounts for this project.
  • INCORPORATION: I'll create my own corporation for the purpose of project tracking.  I don't have to enroll all participating accounts in the corporation, but this is where I'll track all assets (cash or otherwise).  I won't join any external corporation (other than NPC) with any of my accounts which aren't a member of the project corporation.  However, I can sell services to other corporations.  The project corporation won't accept applications from any other accounts except my own.
  • ACCEPTABLE SOURCES OF INCOME: I'll build my wealth in one or more of the following ways:
    • PVE or PVP income such as bounties, theft, mission rewards, loot, mining, etc.  I'm not excluded from joining fleets with other players, e.g. for incursion running.
    • Market income through speculation, selling of manufactured goods, etc.
    • In-game payment for services I provide, such as website income, etc.
  • NON-ACCEPTABLE SOURCES OF INCOME: I won't take income from any of these sources.  If I get such income, I'll either return it or otherwise remove it from the books.
    • Donations or gifts from other players.
    • PLEX purchased with real money for any purpose other than to pay for game time.
    • Scams.  I won't make money this way, but this doesn't exclude things like stealing cans or loot from mission runners.  I'm not against scams, I just don't have the skills or interest to make money that way.  More's the pity some might say.
I think it's safe to say that other solo players have already achieved this goal.  I don't know how they did it, but I'll be scouring the web to look for clues and ideas for how I should go about it myself.  I'm already aware of a few famous stories as to how this has been done.  I'll report on the interesting ones as I find them and as they become relevant to my own project.

Tracking Progress and Reporting


I'll start out with reporting progress on a regular basis (at least monthly) in two forms:
  • Balance Sheet: I'll provide a balance sheet which shows the distribution of assets and liabilities.  The assets are just the cash and assets of the project corporation and all its members.  The main liabilities will be PLEX to pay for any accounts, and corporation equity.
  • Income Statement: I'll provide an income statement for each reporting period.  The income statement only covers cash flow.  Any increase in net worth due to acquired assets will show up in the balance sheet instead (but any cash used to acquire assets will be deducted in the income statement).
While cash flow is relatively straightforward to track, valuing assets is a tricky process.  The next blog post for this project will discuss the initial approach for valuing assets.  I'll likely refine this over time if there are huge discrepancies in actual versus reported value.

What's Next?


Since I'm on the hook to produce a balance sheet and income statement on a regular basis, the first thing I plan on doing is writing tools to automate those reports.  The next project blog post will discuss those tools and provide more details about the starting point of the project (e.g. the initial balance sheet).

Wednesday, January 14, 2015

Static Data Export as a Giant Google Sheet!

I've loaded the entire EVE Static Data Export (SDE) into a single Google Sheet.  I've publicly shared the sheet for Proteus here, and Rhea here.  You can use these links in your own sheets, or you can make your own copy of each sheet.  I've documented how I built these sheets towards the bottom of this post.

Why, you may ask, would one want to do this?  The main reason is to perform SDE cross references when you don't have convenient access to a database.  For example, suppose you want to look up type info for assets.  If you only need one particular table (e.g. invTypes), then it's probably easiest to import that one table.  In the more general case, however, you may need to cross reference multiple tables (e.g. industry planning).  This is where a single sheet with everything in it comes in handy.  If you don't like reading, you can stop now and watch this video instead, where I show how to make a cross reference from one Google sheet to another (the sheet used in the demo is available here).  Otherwise, read on to see how it works.

You can build sheet to sheet cross references in Google Sheets using a combination of IMPORTRANGE and the surprisingly awesome QUERY function.  A formula containing IMPORTRANGE simply copies a range of cells from another sheet, where the source sheet is specified by a special URL.  When used by itself, IMPORTRANGE stores the copied cells into the local sheet.  What the QUERY function brings into the mix is the ability to use a SQL like query to only pull in the bits you care about.  That is, if you wrap IMPORTRANGE with QUERY, you'll only copy the parts of the imported range that match your query.

Here's an example.  Suppose you have a sheet that looks like this:

A
B
1
TypeID
Type Name
219551

Then we can fill in the "Type Name" column with the following formula:
=QUERY( IMPORTRANGE(TABLEREF, "invTypes!A1:C65000"), "select Col3 where Col1 = " & A2 & " limit 1", FALSE)
where "TABLEREF" is a URL referring to the SDE Google Sheet.  The IMPORTRANGE function pulls in the given range from a sheet named "invTypes" (this is a sheet in the workbook of TABLEREF).  The QUERY statement selects the third column of the imported range when the first column matches our type ID.  We're using a very simple query here, but the QUERY function allows many more SQL-like abstractions (like "avg"), you can read all about it here.  One thing the documentation doesn't make explicit is that column names from an imported sheet are always "Col1", "Col2", ..., etc., regardless of how they're actually named in the source sheet.  If you're using QUERY within the same sheet, then you use the regular columns names for the sheet you're querying.

It's important to get the TABLEREF correct, otherwise the import won't work, and it's non-obvious how to get the correct URL here.  The short version is: if you're using a link that has the form: https://drive.google.com/...  then you're doing it wrong.  The URL you want will look something like: https://docs.google.com/spreadsheets/d/...  (this is the form shared at the top of this post).  The easiest way to find this link is to actually open the sheet in Drive.  The correct URL is the link in your browser address bar when you're looking at the actual page.  To make it easier to figure out the correct URL, each of the sheets I exported above installs a menu option which shows the proper URL.  You can access this function by loading the SDE Sheet, then selecting "SDE Tools" → "Get Import URL".

Still confused?  Take a look at this video for a demo using an SDE sheet.

How It's Made


It's a multi-step process to construct the whole sheet, but the process always starts from the SDE export that Steve Ronuken provides here.  Among the many formats provided, Steve provides each table as an excel file.  The TL;DR is that I import all of these individual files as sheets in a giant Google Sheets workbook.  There are a few intermediate steps along the way to deal with various sizing limits.  Here's the process (this is on a Windows machine since I need Excel and VisualBasic for one of the steps):

  1. First, download all the excel files.  I use a simple bash oneliner running in cygwin:

    for i in `curl -s https://www.fuzzwork.co.uk/dump/proteus-1.0-109795/ | egrep -o '[a-zA-Z]+\.xls\.bz2' | sort -u` ; do curl -o ${i} https://www.fuzzwork.co.uk/dump/proteus-1.0-109975/${i} ; done

    The important bit is the path for the release you want to build (in this case, Proteus).  When this step completes, you'll have bzip'd copies of every excel file.  Run "bzip2 -d *.bz2" to uncompress everything.
  2. Ideally, I'd now compile all the sheets together into a giant Excel workbook and import into Google Sheets.  But that doesn't work because the resulting Excel file is too big for Google Sheets.  So instead, I have to do things in three batches (two might work, I didn't try).  Each batch consists of building a consolidated Excel workbook, and proceeds as follows:
    1. Divide the downloaded Excel files into three batches.  Here's how I divided things:
      batch 1 : agtAgents through dgmTypeEffects
      batch 2 : eveIcons through invTypes
      batch 3: mapConstellationJumps through warCombatZoneSystems
    2. Assemble the files in each batch into a consolidated Excel file.  You can do this following the guidance here.  My version of their Visual Basic script looks as follows:

      Sub simpleXlsMerger()
      Dim bookList As Workbook
      Dim mergeObj As Object, dirObj As Object, filesObj As Object, everyObj As Object
      Dim worksheetName As String
      Application.ScreenUpdating = False
      Set mergeObj = CreateObject("Scripting.FileSystemObject")

      'change folder path of excel files here
      Set dirObj = mergeObj.Getfolder("C:\<path to your excel files>\<current batch directory>")
      Set filesObj = dirObj.Files
      For Each everyObj In filesObj
      Set bookList = Workbooks.Open(everyObj)
      worksheetName = mergeObj.GetBaseName(everyObj)
      'sheet names are limited to 31 characters in length
      worksheetName = Left(worksheetName, 31)

      'copy the range to a new worksheet
      Range("A1:AG" & Range("A65536").End(xlUp).Row).Copy
      Set ws = ThisWorkbook.Sheets.Add(, ThisWorkbook.Sheets(ThisWorkbook.Sheets.Count))
      ws.Name = worksheetName
      ws.Activate

      'Do not change the following column. It's not the same column as above
      Range("A65536").End(xlUp).Offset(0, 0).PasteSpecial
      Application.CutCopyMode = False
      bookList.Close
      Next
      End Sub

      One important bit is that sheet names have a size limit in Excel, but some of the SDE files exceed this limit.  This happens for two of the RAM tables which I fix later.

      When each batch has been created, I remove the one empty sheet that was created for each batch, and save out the merged Excel file.  When you're done, you'll have three large Excel files.
  3. Create a new Google Sheets file.  Import each of the batch Excel files you created above as follows:
    1. Select File → Import and use Upload to pull in the next batch file.  Use the "insert new sheets" option when it asks how you want to import the file.
    2. You'll have one empty sheet in addition to all the sheets you imported.  Delete it if you're a purist.
    3. You'll have two shortened sheet names: ramAssemblyLineTypeDetailPerCategory and ramAssemblyLineTypeDetailPerGroup.  Rename those if you're a purist.
  4. (Optional): if you want to add the Google App Script (GAS) that provides the IMPORTRANGE URL, or the cell count then:
    1. Select Tools → Script Editor... on your sheet.  This pulls up the GAS editor.
    2. Replace the default script with the following:

      function onOpen() {
        SpreadsheetApp.getUi().createMenu('SDE Tools')
        .addItem('Get Import URL', 'getImportURL')
        .addItem('Count cells...', 'countCells')
        .addToUi();
      };

      function getImportURL() {
        var url = SpreadsheetApp.getActiveSpreadsheet().getUrl();
        showInfo("IMPORTRANGE URL: " + url);
      }

      function countCells() {
        var sheets = SpreadsheetApp.getActiveSpreadsheet().getSheets();
        var cellCount = 0;
        for (var i = 0; i < sheets.length; i++) {
          cellCount += sheets[i].getLastRow() * sheets[i].getLastColumn();
        }
        showInfo("Total cell count: " + cellCount);
      }

      function showInfo(msg) {
        var ui = SpreadsheetApp.getUi();
        ui.alert(msg);
      }

      Save with Ctrl-S.  You'll either have run the "onOpen" method at least once, or reload your sheet to get the menu to appear.
    3.  
That's it!  You're done!  You'll have to make the file shareable if you want to allow others to use it.





Saturday, January 3, 2015

IMPORTXML for Google Sheets in EVE

Lots of recent posts on EVE Forums and the EVE-Central Google Group about seemingly recent problems with the IMPORTXML function on Google Sheets, specifically with import calls to the EVE-Central market data APIs.  As discussed in this thread, the problem seems to be mostly with the old version of Google Sheets which is gradually being replaced with a newer version of Google Sheets.  Google is supposed to auto-convert all existing sheets to the new version over the next year.  If you're having problems, there's a good chance you're using an old sheet.  There are at least two ways to fix this:

  1. Convert an old sheet to a new sheet (more on that below); or
  2. Don't use IMPORTXML, instead create a Google App Script for your sheet.

Here's how to upgrade from an old sheet to a new sheet:

  1. Figure out if you're using the old or new Google Sheets.  Your using the new Google Sheets if there is a small green checkbox in the lower right corner of your sheet: 
  2. If you're using an old sheet, you can manually convert to a new sheet.  Currently, the only way to do this is to create a new sheet and copy.  This page gives instructions for how to do that.
  3. There are a few feature differences between the old version of sheets and the new which you can read about towards the bottom of this page.  Some things they don't mention explicitly, for example (and this bit me already): named ranges now require the sheet as well as the range name.  You used to be able to define a range like "Foo = sheet1!A1:A20" and refer to that range on any other sheet as just "Foo".  Now you have to refer to it as "sheet1!Foo" which is kind of a pain (or...maybe there's some workaround I haven't found yet).
My own preference is to write Google App Script for these types of things.  Steve Ronuken has a long post here about replacing IMPORTXML with script instead.

Thursday, January 1, 2015

In Development - We Need Your Input!

Happy New Year!

We've had a productive busman's holiday here at EveKit working on a number of new features for the site.  There are three main features we're working on, and I'm excited about all of them, but honestly I'm not sure which features (if any) are the most relevant/interesting for third party tools developers or players of EVE Online.  That's where you come in.  Take a look at our feature descriptions below and let us know what you think at our survey.

Feature 1 - Third Party Developer Freelance Site

Our extensive market research (read: we lurked on the forums a bit) has shown that many players are interested in third party tools which either don't exist yet, or would require significant modifications to existing tools.  These players are more than willing to pay ISK to get these tools made (because they can't develop themselves, they don't have the time, etc).  Conversely, there are many talented third party developers out there willing to help, and more than happy to take ISK in payment.

Outside of EVE Online, there are numerous freelance sites which match freelancers to customers looking for developer help.  Here at EveKit, we've started working on a part of the site which attempts to do the same thing for third party tool developers.  In our case, you'll pay with ISK instead of paying real money.  This part of the site works as follows:
  • Anyone can sign into EveKit and identify themselves as a developer, at which point we start keeping a history of their job activity including things like winning bids and happy customers.  Over time, this is how you'll know a given developer is reliable.
  • Anyone can sign into EveKit and post a project and call for bids.  A project consists of:
    • A description.
    • Implementation requirements (e.g. programming language, DB choice, etc).
    • Maximum price the poster is willing to pay (in ISK of course).
    • Any schedule or time requirements for the project (e.g. finish in four weeks).
  • We also keep a history of project posters: do they pay on time?  were they pleasant to work with?  Over time, this is how developers will know which customers are reliable.
  • You won't need to sign into EveKit to view projects up for bid.  But you WILL need to sign in if you want to post a project, or bid as a developer.
  • EveKit is just the matchmaker here.  YOU DON'T HAVE TO USE EVEKIT AS PART OF YOUR TOOL IMPLEMENTATION.  We'd love it if you used EveKit account synchronization as part of your implementation, but it's not required.
We haven't settled on a payment model yet but here are some ideas we're kicking around:
  • Developers and posters can either make their own arrangements or use a standard agreement (e.g. 20% up front, balance on delivery).  EveKit will offer a service to help developers confirm that posters have made payments.
  • EveKit will charge a small fee to post a job, e.g. 50M ISK.  The actual price will depend on the volume.  If many posts are made, the fee can go down substantially.
We've started the design of this feature, but we're still a month or so away from being ready to roll it out (if we focus on this feature).

Feature 2 - EVE Wayback Machine!

If you've used EveKit before, you know that we use your API credentials to maintain a snapshot of your account information in the cloud which we make accessible through the EveKit web service APIs.  Account features which have an obvious history, like wallet transactions, are retained forever.  So you can look at your entire wallet history if you want, starting from the first day you added your account to EveKit.  Account features which don't have any obvious history, like your character sheet, are only maintained in their latest up to date state.  In other words, we can't tell you what your skill point balance was a month ago.  We can only tell you what it is now.

The EVE Wayback Machine feature idea is simply to start maintaining history across ALL the state EveKit maintains.  This means that every bit of mutable account state (e.g. your character sheet, your list of contacts, your assets, etc.) would now have a history.  Moreover, the EveKit APIs would change so that you could view the state of your account at any point in time.  This will increase the amount of data we have to store in EveKit, but not as much as you might think.  Currently, wallet entries (journal or transactions) dominate our storage requirements, and this is history we already keep.

More details about this feature:
  • All EveKit web service APIs would change to include an optional "as of" timestamp field.  You would use the "as of" field to view data at a particular point in history.
  • The daily snapshots we generate in CSV format will only cover the latest data.  We'd provide a separate on demand API for requesting a CSV snapshot from a particular point in time.
  • EveKit access keys (these are required to access your data through the web service APIs) would be unchanged.  These keys already have a "limit" field which specifies the earliest date at which account history can be viewed.  Previously, we used this feature to limit access to older wallet entries.  Now we'll use this feature to limit access to any historical state.
We've started on a prototype implementation of this feature.  We're about three weeks away from a beta if we focus our efforts here.

Feature 3 - EveKit Server Side Code and Applications

Maybe you'd like to make your own third party tool (as opposed to paying someone, see the first feature), but you're not too crazy about sorting through the various API libraries, setting up your own website, etc.  Or maybe you can do a little bit of coding, but not enough to piece together an application that meets your needs.  If so, then this last feature is designed for you.  If you use EveKit, then your account data (and the Static Data Export as well) is already online and available through straightforward APIs.  All that's missing is a simple tool to put the pieces together.

To meet this need, we've built a prototype "App Developer" in EveKit which will allow players to build simple applications in-browser running against their sync'd data and the latest Static Data Export (SDE).  The tool provides a visual programming language (based on Blockly) so that most players will be able to build applications without needing to write code.  Here's what an example "program" looks like:
Sample EveKit Server Side "App"

Some of the details in plan for this feature:
  • Applications can run server side (on the EveKit servers), in the browser, or both.  Applications running on the EveKit servers will have some limits on size and run-time (TBD).
  • Server side applications can be headless.  They'll run on a schedule even if you're not actively signed into the site.
  • You can make an application "public" in the code repository sense, which means that other users can make a copy for their own use.
  • We're considering ways to allow multiple users to "share" a single copy of an application, but don't have a design finalized yet.
  • You can search and copy public applications if you don't want to start from scratch.
This feature is the furthest along of any of our features.  We already have basic server side application development and execution working.  It's likely we'll be ready to release this feature in February if we focus our efforts here.