Farms and Fields: Bringing Industry to Nullsec

One of the common whines I hear in industry circles is "Industry is nigh impossible in null sec".  Between lack of slots in sov-space (player owned and controlled) and the impossibility of logistics to and from POS, heavy industry is basically absent from nullsec.

Without industrial investment, there are no soft-targets to hit.  Without "farms and fields", there is nothing for smaller gangs to "burn".  And though I agree with the sentiment of enriching gameplay through more targets, I fear for the viability of industry across EVE.

I fear the changes because the first trumpet of 0.0 space is "risk v reward".  That everything should be inherently better only on the measure of risk.  That call is always paired with "nerf high sec", which would destroy (I think) a valuable balance between builders and destroyers.

The Way It Is

Currently, the modus operandi is buy in Jita, and ship to the warzone.  I don't think this is a terrible way to go, but secondary hubs are drying up and Jita is becoming more and more monolithic, which I think IS unhealthy.  

There is also a significant issue of investment when it comes to dropping a factory.  On the surface, there could be a cost/benefit analysis between dropping POS in LS/0.0 without the need for standings.  Unfortunately, there is no added benefit, so the entry cost of high security (standings) is just so much better than providing a target you will eventually lose.  This incentivizes high-sec heavy-industry corps.

Instead the benefits are in shipping.  It would currently make much more sense to sponsor a near-by high-sec industry corp that could ship to a null hub than try and support the infrastructure inside null space where it can be interrupted.  I personally think this is the place where improvements can be enacted  making it easier to make a factory mobile, allowing for a rear-operating base, rather than "farms and fields".  But if the CSM is going to push for "farms and fields" then we should look at what that would mean.

Supply Chain

This is the obvious bottleneck in sov-space industry.  Even if slot/POS issues were solved by tweaking some DB numbers, the supply chain problem would remain.  Currently, to haul the materials needed for production, compression is required.  Compound that with the trouble of reprocessing and then delivering to a POS.  This all adds up to "frack it, I'll buy it in Jita and haul the finished product".  Some proposed solutions:

Super-Veld

Currently, mining rates on all ores are nearly flat on a per-hour rate.  Also, thanks to the hellfire toward bots, the per-hour rates are pretty lucrative for miners.  Since rates are flat, why risk a mining fleet in PVP space when you can harvest vanilla ores in safe space?  If you're going to need to ship compressed materials anyway, why not just skip the mining op all together and reduce the steps?

Since the hauling volume bottleneck is in low-end minerals (tritanium, pyerite, mexallon), the first suggestion in solving the supply chain bottleneck is to make super-yield low-end rocks that can take advantage of tools such as rorquals.  This would allow for harvesting materials in much higher yields locally, incentivizing manufacturing locally to then monetize out those hauls.  This would remove a leg of the supply chain into null.

Personally, I think this is a very good idea, since I personally believe the low-end prices are way too high at the moment, and it is causing the price of things to be distorted.  There would need to be some finesse as to how people could invest in their space to get this super-veld, but I think there are a lot of opportunities in this department to ease up several bottlenecks.

Refinery Issues

Both in WH and null sec, there's a big problem of "Water water everywhere, but not a drop to drink".  The issue lies in refinery availability.  Any way you go, there will be a yield hit, and if you're stuck hauling large volumes around from op->outpost then still hauling heavy loads from outpost->POS, then we haven't eliminated a supply chain leg.  

I think the issue can be solved with a heavy revamp to mobile refineries.  Increase their holds to 100k-500k, increase the yield to 75-90% flat (no skill improvement).  Even make the refinery types restricted to ores and make cycle time proportional to load.  By giving a mobile refinery where ore can be refined near the factory, a supply chain is significantly improved.  This also puts fully functional factories in the crosshairs of enemies, allowing for raiding targets.

Castle Walls

The problem with industry is it is diametrically opposed to PVP.  Without significant security, it's far too easy to burn down a lot of hard work.  It's like saying we should build a tank factory in Afghanistan because we need tanks there... when instead we can put that factory somewhere secure and ship in the tanks.  

I agree we should incentivize thriving headquarters for alliances, but the volumes alliances require are not worth putting on the line.  Unless we can build fortresses, there is nowhere to put factories.  Unless valuable BPO's can be secured, no one will risk the factory.

POSibilities

With current POS mechanics, the choice is between factory and security.  If you want to have a tower that has any defensibility, you can only half-load it with industrial capabilities.  I don't think this mechanic is directly bad, but without significant fuel savings the cost/slot and logistical hurtles of providing enough manufacturing throughput (as well as technical organization to make several towers work together).  Furthermore, the hassle of management would require returns that are significantly better than "just buy it" to really justify the risk.

As for proposals, I'd start with a PG->CPU conversion module, nullsec only.  This would allow a tower to be hardened and expanded to allow a secure base of operations.  This could be abused to make dickstars even more dickstar-y, but I think a balance could be reached to incentivize the intended behavior (higher stacking penalties on shield hardeners?).  I would also like to see a method to disable/slow production through enemy gang activity, but that's probably asking too much in the game mechanics department.

Risk vs REWARD

The main point still stands: why build in null when I can ship instead?  Without incredibly significant bonuses to build speed, material requirements, and ore yields, why would anyone take the risk.  Also, with the requirements for industry being so diametrically opposed to PVP, why would any organization tolerate the shift in paradigms.  Already PVP organizations have near-zero tollerances for missing CTAs due to "carebear excuses", and without sticking to a production schedule, I don't see how any organization can hope to have enough materials to justify the investment.

There is a significant oil-and-water world collision when it comes to PVP and industry.  The types of people who will put up with the industry grind are not the type of people who can be counted on for frontline PVP.  A lot of orgs will not find the losses acceptable when they appear on enemy kill mails.  Efficiencies will drop as carebear activities are attacked.  Space honour and image will be challenged as blocs require carebear corps for support.  

Also, my proposed changes still don't address the T2 supply chain, which would still be unsustainable in null.  The moon supply chain is designed to avoid monopolies.  Also, invention would require hauling of either invented bpcs or large groups of datacores into null, since there are no supplies coming from that space.

It's because of these two meta issues, image and real-return, that bringing significant industry to null is not a trivial matter to fix.  Without very significant overhauls to industry mechanics (most not for the better), there will be no change in the status quo.  Unless balances can be struck between killers and builders, where both can exist in the same space, then there will be no progress away from Jita. 

The Joys and Pains of Stockpiling

A topic I abhor, but a common point of contention among heavy industrialists.  It has always been a major point of contention among my teammates about what is the best way to stockpile.  From the utilitarian to the economic, there is a range of reasons to stockpile.  Unfortunately, it's something that can quickly get out of hand and cause issues both expected and unexpected.

A disclaimer: I am an engineer, not an accountant.  I feel confident speaking on the top-level economics of the topic, but am not reliable on the hard-core finance tools (heges, futures, derivatives, etc).  I am not publishing this as a guide, but instead discussing my opinions on applying the topics to your own EVE experiences... Use with caution, regard with a grain of salt.

Real Life Analogs

Stockpiling, or hedging, allows for insuring against future price spikes.  Airline fuel is the common example: if I expect prices to be higher in the fall, I will hedge against that price and find a way to lock in a lower price in advance of that spike.  

Since EVE lacks the nuances of modern financial products, hedging is done by stockpiling.  Whether that is hoarding products for price spikes, or just keeping a backlog of raw materials to quickly react to price sways in manufactured product.  

In EVE, I don't dare, for one second, to claim I know how to read the commodity markets.  In the traditional sense of hedges to "insulate against price spikes" I am a miserable failure.  Instead, let's look at the different ways we can stockpile to make the industrial process less painful.

Before Stockpiling

The cost of stockpiling is ISK.  ISK that can't be used for other processes, ISK that isn't being turned into more ISK, ISK that can be stolen/lost/depreciate.  It's very easy to have a project that has more value in stockpiled goods than actual net products.  This is the reason I treat stockpiling so gingerly.

Since the goals should be to simplify the industrial process (hauling, building), and try to make more ISK, pick your stockpile carefully.  Having large stores of commodities like Tritanium might make heavy production more agile.  Holding back product for the swings of market ups-and-downs might mean more ISK/unit.  Having a store of built T2 components might better utilize build times.  Just remember, that's ISK not in the wallet.  Also, the further refined the product is, the harder it is to cash-out the stockpile if something goes wrong.

Raw Material Stockpiles

Personally, I am a big advocate of stockpiling low-end minerals, and high-volume PI materials.  I should hold on to more moon components and T1, but I find those products are either light enough to transport easily or have such a small price differential, they aren't worth holding on to.

A practice I am trying to get better at is becoming smarter at stockpiling things that are essentially free (blue print copies), or take very little liquid ISK to hold on to (datacores/decryptors).  Stockpiling these intermediates serves to make the T2 manufacturing process much more agile.  Even T2 BPCs are pretty cheap to hold on to.  Also, they may be a theft risk because of : shiny: but would be such a pain to monetize, I can't imagine someone having the patience required.

Product Stockpiles

Since I am so bad at extrapolating trends, and tend to try and keep all my ISK working at all times, I don't like stockpiling finished product.  But, for the supply-oriented manufacturer, holding the same margin as the expected profit is like holding free goods.  This can be useful to portion off 10-30% of products for going straight into corp use.  

My problem with corp-use product stockpiles was two fold.  On the one hand, managing getting product into the hands of members is a pain.  On the other hand, keeping a diverse enough stockpile is a massive headache.  Why do we have one gun but not another?  Why can't I have the whole ship comped?  Trying to balance both an ISK-generating manufacturing house AND a direct PVP supplier is a lot of headache.

Cash Stockpiles

Cash is king.  Unlike the other stockpiles, cash can be turned directly into product instantly.  Whether that's ship equipment for the corp, or materials for manufacturing.  Though some will argue it's not the most efficient to just sell-order 100% of your materials, or buy-order 100% of your products, there's nothing like having piles of cash to just get it done.

Personally, this is the means I like to stockpile.  Unfortunately, as I mentioned earlier, I have a personal bad habit to invest stockpiles too readily and end up over leveraged.  Also, cash is really easy to move and steal. So be careful how you hold cash.

Security and Stockpiles

As countless corp thefts have highlighted, a stockpile is a target just like any PVP engagement.  Any pile of goods can be stolen by anyone.  Some thoughts to keep in mind:

• Difficulty of monetization: Good stockpiles are hard turn into cash
• Enormous piles of trit are heavy to transport
• T2 BPCs take a lot of time and/or material to manufacture
• Intermediaries might not have a player market (T1, RAM)
• Security of materials: Corp tools are your friends
• Secure hangers by need of access
• Utilize POS lab use/take rules to protect materials
• Alt stashing cash
• Remember: nothing is 100% secure once you involve human interaction
• Utility of stockpile
• Don't be afraid to reduce stocks if inputs > utilization
• No reason stockpiles can't be fluid.  Change to suit needs

Engineer Engineer

Pardon me a moment of off-topic.  I promise, development blogging will resume soon(tm).  I have a couple entries still in draft as I finish them.  Hopefully I can finish them this weekend.

I would like to highlight a trend I find disturbing in the technical jobs sector.  The haphazard slapping of "engineer" on any title to make the job sound more impressive.  Being a formally trained, and practicing electrical engineer, from a family of engineers, I take the title seriously.  Unfortunately, since STEM education has fallen out of favor until very recently, I don't believe most of the general public has the vaguest idea what an engineer actually does.

Hint: It has nothing to do with driving trains.

About The Author

I currently work as a Test Engineer in Probe (Wafer Sort) at a memory fabrication house.  My current project is developing the first ever production-volume phase change memory (PCM) part.  Furthermore, my job is tied to part reliability as we beef up the process for higher volume.  This means I spend my day designing tests and experiments to properly stress the part, and deliver the data for fab to improve the process.

Though in practice, my job is not that impressive, I maintain my credentials.  I have a BSEE from Colorado State University, and have passed the Fundamentals of Engineering exam as the first step toward earning my PE.  I hold membership in IEEE and several of their societies, namely Networking (ComSoc), and Power & Energy Society.  

The Trend

I have seen many job postings, and have friends in many technical positions, where the term "engineer" has been attached.  From programmers to technicians, the trend seems to be an inflation in title and/or a deflation in responsibilities.  

Floor technicians called "solutions engineers".  Over-the-phone tech support called "Technical Support Engineers".  Website designers called "Network Engineers".  

This trend is infuriating when trying to get a handle of what companies actually do.  When your company touts significant technological or industrial advancements: ground-breaking new tech, innovation, revolutionary new service... I then expect when I see open "engineering" positions, that the company requires the kind of broad-base, profit-minded, data-oriented skill set an engineer brings... Or at least be willing to pay the premium that comes with that skill set.

If someone called themselves "doctor" without credentials, they would be ridiculed.  If someone represented themselves as a "lawyer" without accreditation, they could ruin their client's life and be held liable.  If a "plumber" or "electrician" misrepresents themselves, they could cause havoc... yet "engineers" can be anyone from a car mechanic to sales person?  Seems a little broken.

What Does "Engineer" Mean?

Engineering has become synonymous with technical expertise, but the title is so much broader than that.  Engineering comes with a host of other responsibilities and liabilities.

Design

Engineers design the systems, tools, and infrastructure we use every day: every system and part in a car, the bridges and highways we drive on, the city planning for sewage and flooding, the internet this blog is posted on.  Every day you touch thousands, of systems that engineers designed.  These systems are considered critical for the lifestyle we enjoy, our livelihoods, or even our lives.

Analytics

No system gets better without data and analytics.  Though most breakthroughs come from the laboratory and scientists, real world optimizations are made by engineers.  Timing traffic lights to decease pollutants, designing more efficient computer networks to serve data faster.  Without a feedback path of design->analytics->optimization, no system would be robust enough to survive the ever changing challenges of the real world.  Engineers provide the expertise to gather, analyze, and apply this data to continue improvements and innovations.

Ethics and Liability

This is most important to me, when defining the title "engineer".  When a bridge collapses, everyone from the welder to the designer will be investigated.  If there is a fault in the design, and an engineer signed the drawing, he can be held liable, even face jail time.  And beyond life-and-death consequences, engineers have incredible power to cost companies outrageous sums.

A dark joke in engineering circles:

What's the difference between a doctor and an engineer?
When a doctor screws up, only one person dies

Business Sense

It is the duty of engineers to take the experimental from R&D and turn it into products for the public.  Scientists can study in schools and labs all day, but until a plan is developed to monetize the technology, it does very few people any good.  It is the duty of engineers to analyze the elements of production and bring the theoretical into reality.  Also, it is the duty of engineers to remind their clients that nothing is free, and technically every feature can be bought... but the price can be unfeasible.  

My favorite professor, Dr George Collins liked to note

Scientists research and develop new technologies, and businessmen make money.  But engineers bridge the space between to turn ideas and technology into sellable products.

Who Should be an Engineer?

I am the first to state that formal education should not be the only path to success, and engineering is similar.  Many fields and positions might have elements of engineering.  Many people might work their way off the production floor and into design.  Instead, I believe that if the position embodies the spectrum of work outlined above, then they are an engineer.  

A certain element of education cannot be overlooked.  Without the broad-base interdisciplinary education that every classically trained engineer receives, it is hard to supplement the body of knowledge that engineers are called to have.  But the motivation to go find out and learn should not be seen as monopolized by education or institution.

I don't mind calling programmers engineers, or inventors engineers.  Many embody the hallmarks above.  But  without the liability or risk to really break things, it's hard to justify the title "engineer".  Without impact, without risk, the title engineer is only embelishment.

The Price Tag of Engineering

All of this expertise comes at a price.  Engineering enjoys one of the last bastions of "old style" business; where employers are actively invested in gathering specific individuals and doing whatever it takes to get them and keep them.  This investment in human capital does mean there is a real life price tag on engineering positions.  Not only in salary, but also in incentives and talent acquisition.  

Any position's pay should reflect the value added.  Engineers, being an all-in-one package with both a host of skills and the commitment to bare the load of responsibility, should be adding significant value.  In my company, several times a year individuals in my division save millions of dollars per quarter on their process improvements.  Money that would have been spent otherwise on inefficiencies.

I want to call upon companies to analyze their titles and really think about whether that "engineer" is really deserved.  Under this scrutiny, I am not sure if I could keep my engineer title for the real work I do, but this is still a legitimate question.  If you wouldn't ship a candidate in on the company's dime, if they will not add several-times-over the value spent on them, then I am not sure if the position really needs an engineer.  

TL;DR

The part I really want to drive home again is the ETHICAL responsibility that comes along with engineering. The price of failure is what measures engineers.  Landing a $2B lander on Mars.  Keeping power on at a data center automatically.  Designing and maintaining bridges and subways.  These are the topics that cost serious cash, puts lives on the line, and require more than average-Joe to design, maintain, and improve.  

Sorry for the rant, we will return to your regularly scheduled spaceships talk soon(tm).  

Everything You Never Wanted to Know: Google Spreadsheets

Spreadsheets and Spaceships; the classic rebuttal to EVE online's title.  This guide is a pre-post for another upcoming series reviewing existing tools.  This is to pair with the writeup for EVE-Central.  These two articles were written in parallel, so there will be a decent amount of overlap.

Most of the lessons covered in this guide are Google-specific commands.  Some will work in excel, but several functions will be Google-only.  We will once again be skipping the laser-focused specifics and remedial topics, focusing instead on those that may have a spreadsheet (or dozen) and wants to improve their existing tools.  Also, we will cover a few best-practices for design so as not to get bogged down with the slew of new features.  There will be a set of example spreadsheets to illustrate concepts.

Resources are at the end of the article.  After the break to save some screen space.

Introduction

Google Drive provides a suite of easily-shared common office tools.  Documents, presentations, forms, spreadsheets, everything a budding small business would need to thrive, and none of the cost of MS Office.  Also, being cloud-hosted comes with some additional benefits.  The cloud allows for incredibly easy access of live web data, without having to write clunky excel scripts.  Also, being able to share these documents means that you and your corp can control access to tools.  This guide is purely for the Spreadsheets toolset.

Basic Functions 

I write this because there was a suite of basic functions I did not know about when I switched into Google Spreadsheets.  Feel free to skip ahead if these get filed in the "duh" category.

Anchor reference ($)

This delimiter allows you to use the drag-copy function while anchoring specific references so they will not drag.  For instance, building 4 condors.  By making the first reference (mineral*$qty), you can then drag-copy across the other minerals (rows) to complete the reference in 1/8th the time.

Technically, the $ freezes whatever its next to:

• $A1: Will freeze COL to A
• Drag-copy COLs: reference will remain A1
• Drag-copy ROWs: ROW will update, but COL will remain A
• A$1: will freeze ROW to 1
• Drag-copy COLs: COL will update, but ROW will remain 1
• Drag-copy ROWs: reference will remain A1

&, JOIN(), REGEXEXTRACT()

Being code minded, I often want to programatically update string cells. Manually filling every cell with their real names, and then having to do it over again for the T2 variant sucks. Also, different groups might need to be added/stripped in more elaborate methods, hence what these string manipulators are for. Using these tools, you can add a lot of quick functionality for only a small amount of work.

• &: allows you to join strings (and references) together.  Think java string printing "hello "+x+" world"
• Great for joining small things together 
• A1=Target Painter I, A2=A1&"I"-->Target Painter II
• Great for adding cell references into string commands
• "api.eveonline.com/api/CharacterList?vcode="&vcode&"&apikey="&apikey
• Join(): works like most scripting join().  Delimiter, string_array
• Convert to csv string
• Join item id's for importXML()
• Use like an iterated &
• RegExExtract()
• Allows for regular expression parsing
• Regular Expression cheat sheet

Array Functions

• Transpose: swap rows/columns.  
• Example: make a list a header
• Sumproduct(): Multiplies each element by corresponding element then sums the outcome
• Example: cost of materials

ImportXML()

ImportXML is the single most useful function for EVE tools.  ImportXML allows you to automatically load nearly-live EVE market data.  Using the numerical typeID for items you want to track (like minerals, products, ships, etc), you can query the APIs of sites like EVE-central.  Also, you can filter out specific data using an xpath query.

Some resources for the uninitiated:

• Sample Spreadsheet
• typeID lookup
• EVE-Central API resource

Some notes to keep in mind:

• Tends to update on-the-hour
• Can force update by changing URL (add/remove "http://" from address)
• DB is most likely to fail request on-the-hour due to cron traffic
• Cannot script cron (as far as I know)
• Join() is your friend
• Join maxes out at 100 entries
• Google's complexity limit is 50 importXML calls.  For very-large sheets, be smart about queries
• Use join (or combine join's)
• Query more data per request:
• Ill-advised xpath: "//sell/min"
• Better xpath: "//sell" or no xpath
• More data per call means less calls for the same data
• xpath "|" does not work like you think it does.  Will concatenate on the END of the first query, not beside the first query #WorkingAsIntended
• Each importXML call will make the spreadsheet slower
• See best-practices notes for how to cope with these limitations

WARNING: Do not try to queryXML() EVE API data.  Whoever set up those XML's was a turd and did not make them xpath compatible.  It can be done, but you need to write an app-script to parse the data, existing functions will not do it.

QUERY()

Query is a tougher tool to use, but incredibly powerful for simplifying a lot of the manual work of updating spreadsheets.  Query allows a nearly-complete SQL-like interface for parsing data.  This becomes EXTREMELY useful for some more eloquent features or further staving off the need for custom code.  I am by no means a SQL pro, but a few simple cases can add a lot of power to your spreadsheet.

Uses:

• Quickly reference price data with a simple command
• Query('Price data'!A:X, "SELECT B where A='"&cell reference&"'",False)
• Group useful data:
• Automatically grab highest and lowest data without needed complex IF()'s
• List collections of data on a sortable variable
• Sort all the frigates out of a list of ships
• Group suitable products between a certain cost

Notes:

• When referencing strings (item names), make sure to include single quotes around value
• ='string' and close SQL query with a double quote
• Not fully formed, only need SELECT and sort criteria, no FROM
• Finicky just like SQL, some frustration will ensue
• Be careful about overrunning boundaries   CONTINUE() will stomp over cells and give precedence to whatever it is continuing

Best Practices

-Or- How I learned to stop worrying about complexity and trust importRange()

Import functionality takes a lot of processing power and will slow down your sheet significantly.  Pile on Query() and a lot of sumproduct() calls, and your sheet will not process.  Instead, make your more complicated tools modular and use importRange() to recycle common functionality.  

Personally, I use importRange() on my personal priceDB.  Also, importRange() is great for bringing in any other data you might care about.  Also, it allows you to protect the sensitive sheets (APIs, work you don't want to share) and import the useful data.  Protection isn't foolproof, it's a security-through-obscurity solution.  Technically, only authors with access to the source material can import into their controlled sheets... but this doesn't give feedback to the source owner as to who is remotely accessing the data.

The biggest lesson I can share is modularity.  Have one sheet for prices, one sheet for t1 building, and so on. Hosting ALL THE THINGS on one sheet will only make a crawling behemoth.  Also, have some patience with importRange().  If the range is dependent on something slower, it may take a minute or two to get the right values and propagate them through the sheet.

Being smart about sharing

Google gives 3 levels of access control, additionally with read/write access for each.  Though the obvious level is to switch the entire sheet on or off, there are some middle ranges that might be useful.

• Hidden sheets
• As long as sheets are protected, they cannot be viewed when hidden
• Collaborators still have access to hidden sheets
• Make a second public sheet
• Hide 100% of the secret sauce in another sheet
• Make a public shell that only shows final data

Personally, I wish "public" could force a sign on anyway, but only invited collaborators will show as non-anonymous.  

A note about Drive-Mobile

Because I am a non-stop nerd, I just want to share that Drive-Mobile is a great place to VIEW these complex sheets... but a terrible place to EDIT them.  Edit with EXTREME caution.  Functions cannot be written in mobile, and some dependent references may not populate as intended.

Resources

• Google Doc function help
• SQL for dummies
• XML for dummies
• Example Spreadsheet

A Wise Man

One of my terrible habits is a constant use of quirky sayings.  Today's entry is dedicated to the saying:

"A smart man learns from his own mistakes.  A wise man learns from the mistakes of others"

Today's blog is dedicated to the developer of Aura, the leader of Aideron Robotics, Marcel Devereux.

About Marcel

Marcel is an extraordinarily gifted contributor to the EVE development community.  Aura is the defacto Android app for all things EVE.  His personal corp site is one that all organizations should strive for. A suite of powerful tools that enable an enormous amount of feedback to his corp members and leadership.

After working with Marcel, I found that he was extremely charismatic and bull headed.  This is not to deride his behavior, but strong men are imposing and strong wills often clash.  I partnered with him at the start of 2012 to push my industry operation from middling to larger scale, and on that front we succeeded greatly.  We managed to generate the program I had always dreamed of, reaching sales figures upwards of 50B/mo.  

Also, in this time, Marcel taught me an enormous amount to bring my own game into the big leagues.  With his extensive knowledge of Google's wide assortment of tools, I was able to upgrade my capabilities and jump into brand new possibilities.

Also, I took away a series of lessons:

1. Don't Develop Alone

This first point is the most difficult in any creative project.  The project is your baby, no one can nurture it like you.  This may be the way to start, but it becomes a massive burden.  The more people that rely on your product, the more they demand of you.  If you're not careful, all of your time is sunk into a side project, and there's no time left to explode spaceships.

This was a major point of friction when working with Marcel.  I was not skilled enough to help take some of the load, and my demands were complicated and hard to implement.  This was one of the major reasons our project closed down; too much demand on one person.

2. Keep It Simple, Keep it Clean

I think it's extraordinarily important to go peruse Aideron Robotics website.  It is the foundation that the entire corp is built around.  The major reason it's so successful?  It's exactly what you need, and not overbearing.  The forums are light-weight (and mobile friendly), the application tools are easy to read.

Design has been a critical component to Aura and Aideron Robotics website.  It is a component that I have trouble replicating.  Many of my own tools get close, but end up failing to wall-of-text.  Time will need to be spent in the foundation focused on the front-face of Prosper.  Also, being an electrical engineer, my code tends to be utilitarian, not efficient... so focus will need to be paid to avoiding code pitfalls.

3. Be Honest, Be Open

One of the temptations that arose from being tied to Aura was to add restrictions to protect Aideron.  Farming APIs, barring war targets from the app, unscrupulous data farming for profit.  Marcel made a point to directly state that ANY use of Aura for covert personal gain would mean the complete death of the app and its place as a primary resource for players.  He is completely open about the behavior and operation of the app, while still retaining control over the development.

4. Be accessible

The reason Aideron Robotics was my favorite corp to be in was connectivity.  The forums were active, we chatted both in-game and out constantly, it was very easy to chat business or pleasure with anyone in the corp.  Also, with the extensive Google integration, there was a connectivity that fostered further connectivity thanks to the various tools that all interconnect between G+, Google docs, and IM.

5. It's a hobby, not a job

The first rule of any EVE venture should be for the pursuit of fun.  As soon as the GAME stops being fun, there is no reason to continue.  It's easy to get caught up in commitments to others, to think "they are depending on me", but there is no reason to be in this kind of project if it's not fun.