About one year ago we wanted to gain some experience in android app development and the whole associated workflow, consisting of:
- developing an Android app
- publishing and maintaining the app in the Play Store
- performing marketing and earning some money
So we decided to create a trial-balloon-project to get started. Despite the fact that our company normally creates serious business software, we gladly received the ok to do some more “funny stuff” like a game for this special case. We are working for a really cool company, do we?
In this short series of blog posts I want to share with you some of the key-insights we’ve gained (and problems we’ve encountered) since the first version of the app was released one year ago. Today I want to start from a technical perspective which must be a little “game specific”. But the later blog posts will focus on the Google Play Store as well as marketing and selling activities we’ve tried, which should make the whole story more interesting for a wider audience as just game developers. So keep on reading! Continue reading
Our business software REWOO Scope runs as a Java application and uses the Sun Java JDK under CentOS 7 (minimal package). To setup a linux system with a running Sun Java, you need a browser and working filetransfer – but why not use wget to download the missing file?
Simple question, difficult answer: Sun dissalowed direct downloads of java from their servers. You have to agree with the license conditions by browser.
It seems that a single cookie is all that is needed to bypass this. If you want to download jdk7u67 for 64-bit Linux using wget, you can use:
wget --no-cookies --no-check-certificate\
--header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie"\
But remember: each version of Java is located in a different folder. For other versions than 7u67 you have to use the respective URL.
In our product REWOO Scope we use a postgres database as underlying data storage. While postgres serves a good overall performance, some of our data structure are more graphish like data structures. A standard RDBS does not suit well here – even a recursive SQL query in postgres. Our current implementation needs over 2 1/2 minutes to collect over 70000 vertices of one particular sub graph. So we investigate some time to evaluate OrientDB, an awesome open source graph-document database.
One of our problem was to load our graph structure with over 1,3M vertices and almost 2,5M edges into OrientDB. The main problem was that the insert of vertices went well, but the insert the edges was a pain. Further we got
OConcurrentModificationException here or
OutOfMemoryError (perm space) errors there. After some implementation iteration we found a good way:
- Create indexes before inserting vertices or edges
- Insert the vertices with OIntentMassiveInsert()
- Insert the edges with disabled Level 1 cache
- Directed graph with 1,3M vertices and 2,5M edges
- Each vertex has 3 properties (1x String, 2x Long). Edges do not have properties.
- Test machine: i7 8×3,4GHz, 8GB RAM, SSD, Ubuntu 13.04, 64 Bit
- OrientDB 1.5.0, Java 1.7.0_09 with -Xmx6g
Now it needs about 100 seconds to read 1,3M vertices (0.07ms/vertex) and about 370 seconds to read about 2,5M edges (0.15ms/edge). The graph database needs about 450 MB disk space. BTW: the final graph traversal of 70000 vertices took about 4 seconds which is a very good result against our current implementation.
For dummy source code read the full blog entry.
I attended the SeaCon 2013 in Hamburg, Germany, a conference about software architecture, processes and management. It was a very delightful conference with lots of fresh talks, good food and awesome gimmicks. Here are my findings of these two days:
- Evaluate the needs of outsourcing well! In most cases it makes more sense to develop a mobile app or an e-commerce software on your own than by a 3rd party. Knowledge is power. If it is your team that gets into it then you are in control of it. Your team has a strong relationship to the project and you are able to change everything whenever it is required. If you outsource something, make sure that all the software sources and rights belong to you after the external project has finished. Otherwise you will have a kind of vendor lock and have to pay for subsequent changes (which might take ages to complete, too).
- It is very popular to develop software using agile methods like Scrum, Kanban or Scrum Ban. Today, every modern development is agile. However, the old waterfall software development architecture still applies to everything but the development itself: the management, budgeting and external agreements do not fit into the agile development framework — yet. There is a need to change that. The management should adapt agile methods for quicker decision cycles. The budgeting should be approved and reconsidered in shorter intervals than one year (AKA beyond budgeting in Germany) and contracts to 3rd parties should be more loosened.
- Similar to the previous topic but different: Large projects cannot be controlled but guided. It is impossible to accurately estimate all aspects of a larger project like its complete feature set, required time, and total costs. However with shorter control and decision cycles you can guide the project better than in one large phase. A decision cycle should not be longer than three months and decisions should be made by a heterogeneous group of specialists.
- It is more important to consider the business and investment value a specific task has for your company rather than asking the software development department about the required time to complete the job. If you know your business value well, you can use and organize your resources (man power, time, and money) in a better way.