Android Development Project #1 – Game Tube

Game Tube is a new Android App for Android 2.2+ and Adobe AIR 2.5+

Game Tube 1.0

Game Tube 1.0 will allow people to view certain selected Gaming Sessions for entertainment purposes only.

New Gaming Sessions will be added on a regular basis.

Game Tube 2.0

Game Tube 2.0 will allow users to “upload” their gaming videos via You Tube as a way to share their Brag Clips with other users of Game Tube 2.0.   People will have the option of installing a Desktop Version of Game Tube 2.0 to their Windows/Mac/Linux Desktop to Administer their Game Tube Brag Clips;  there may be some support in the Android version for this also.

Game Tube 3.0

Game Tube 3.0 will allow users to build their own Social Networks of friends and others they wish to share their videos with.  There may be a FaceBook App that interfaces with Game Tube 3.0 to allow users to share their Brag Clips via FaceBook.  Support for Twitter and other Social Networks may be added depending on user support and user requests.

Stay Tuned for the ride !

Check back here for additional details whenever they become available.

Riddle me this… ?!?

How can a language with half the speed give 200% better performance ?!?


#1 – Java is supposed to run way faster than Python.

#2 – Java servlets are single threaded due to complexity of threading model.

#3 – Python can more easily deal with real OS threads. (No link required because this is Axiomatic.)

Fact #2

Whenever Java programmers talk about Java, in hushed low voices, in relation to performance problems they are having with Java – not that anyone wants to talk about any perceived performance issues where Java is being used… they have to acknowledge the undeniable fact that Java is simply single-threaded.

Java is only single-threaded because the code required to make Java multi-threaded is so god-awful complex that nobody would want to have to deal with it AND the requirement to write thread-safe code.  Actually thread-safe code has gone the way of the dodo bird in Corporate America.  Why ?  Because your typical programmer (I hate to use the term “Software Engineer” here because most programmers are no more an “engineer” than milk is carbonated, which as we all know milk is not at-all carbonated unless you can find fizzy milk and as we all know when you walk through your local grocery store you ain’t gonna see much carbonated milk and hence there are very few real software engineers in Corporate America contrary to popular belief and all self-delusions aside…).

Thread-safe code is about as fun to write as Drano is to drink, for most Java programmers (aka. code slingers).  Let’s face it, most Java coders hate to solve real problems when they can have so much more fun writing Java code.  Why spend all that time working-out how to make your code thread-safe when there is very little reason to do so since each Servlet instance runs in its own thread anyway ?!?

Fact #3

Anyone who has spent enough time with Python to learn how it works knows Python handles thread as easy as 1..2..3.. which means Python wants to be multi-threaded.

Python has that really cool Global Interpreter Lock which to the casual uninformed coder seems like a really bad idea until you figure-out it really does help you write thread-safe code without so much as having to even think about whether or not your code is in-fact truly thread-safe.  Each thread gets to execute a certain number of instructions before the next thread gets control and so on until all threads have had their turn.  The GIL ensures there is never more than exactly 1 thread being executed at the same time.  In essence the GIL makes multi-threaded code pretty much automatically thread-safe while allowing software engineers to engineer their software using multiple threads.

Stackless Python !

Stackless Python makes micro-threading easy and is in-fact easier to code than Python OS threads.

Stackless Python is at the heart and core of one very popular and powerful MMORPG known as Eve Online.

Why has nobody ever coded an MMORPG using Java?

Java-based MMORPG…  Okay maybe there are some Java-based MMORPG Engines out there; supported by a ton of C++ code rather than pure Java code.  But… Why are there no Java-based MMORPG games I want to play ?  None are as popular as Eve Online !  Eve Online is the ONLY MMORPG game that features a single unsharded Game Universe !  (Eve Online appears at the top of that search, doesn’t it ?!?)

Why do skilled Java coders not push their Java servers to the hilt ?

So who even knows what the “hilt” is where Java is concerned anyway ?

Typical Java coders who spend their time in J2EE-ville are far less concerned about pushing the performance envelope than in just writing some pretty easy to understand Java code… so because very few Enterprise-level Java coders know what the “hilt” is none of them would know how to push it to the “hilt”.  Also pushing it to the “hilt” would require some pretty insane coding and who wants to have to do that anyway ?!?

Python makes it easy to push it to the “hilt” !

Let’s face it, when you have as rich a set of data types to use when writing your code you can very easily find yourself pushing your code to the “hilt” and beyond.

Python makes the job of writing very efficient code as easy as possible without losing your ability to handle complex coding problems.

Java, as a language, is not about coding complex problems easily.  Java is all about readability and making code easy to understand.  Java coders don’t even think in terms of writing efficient complex code – they are all about just making the code work about as simplistically as possible.  Java does not make data manipulations fast, efficient and powerful the way Python does, IMHO.

Obviously I would rather code Python than Java !

But like everything, there is a reason for this… Nuff said !

Charting Stress Test for Flash and the Google Cloud

This is a story about LitePoint.Com and how they need to hire someone who can resolve their terribly messed-up Flash Builder 4 Code that cannot perform real-time charting of only 5000 data points.

Once upon a time a skilled software engineer went on an interview with the aforementioned company who said they wanted to hire someone who has worked with Charting Apps that chart a bunch of data points, in this case some 5000 every 250 ms.  The skilled programmer told them he could do the work.  They asked what past coding projects could they view as proof of the skill our rugged Hero said he had.  All went well for the first part of the interview until… The two guys who had created their problems had their chance to interview our rugged Hero.  Neither of those guys had any experience to speak of with Flash or Flex (Flash Builder 4 is really Flex).

One of these guys was a C++ programmer and neither knew anything about Object Finalization, as if knowing how to cause objects to be garbage collection is all that big of a deal – which it is not, of course.  Let’s forget the fact that one need not be the least bit concerned about either object finalization nor garbage collection when performing real-time charting of 5000 data points every 250 ms – because none of that is the least bit required.

Let’s also forget the fact that one need not create a bunch of objects to get 5000 data points charted every 250 ms; unless someone tried to build their own charting display objects and they had no clue what they were doing.

Let’s also forget the fact that not only can Flash Builder 4 produce Apps that can chart 5000 data points every 250 ms one can also easily optimize this system to handle far more than just 5000 data points every 250 ms.

Let’s also forget the fact that our two llama C++ guys who caused their own problems were trying to convince their bosses that Flash Player cannot handle charting 5000 data points every 250 ms, as-if the only way to get this done would be to code it in C++.

Let’s also forget the fact that if one really wanted to one could shove C++ code into a Flash App to get the performance up, if one had to do so.  It’s called Alchemy, not that those two Llama’s had any clue about this aspect of Flash anyway.

So now that we have chosen to ignore all the facts we can focus on the solution which by the by only required 12 hours time to build but then this is how a skilled programmer handles such trivial tasks as charting 5000 data points every 250 ms.  This is worth 12 hours because this is a non-issue for Flash Builder 4.

See also: Charting Demo – go ahead and download it.  The published version handles 5000 data points every 250 ms with ease.  The simplest of optimizations could easily boost performance to 20,000 data points every 250 ms with ease.  Additional optimizations would result in 50,000 or more data points charted every 250 ms, also with ease.  Just in case Flash Player might prove too slow one could always achieve this goal using any number of techniques capable of displaying 30 charting updates per second by using some optimization techniques any suitably skilled programmer should be able to manage with ease.

Anyway, Charting Demo took 12 hours to build – time-permitting some additional features may be added such as a slick Dashboard with gauges and dials to show the performance.  It would also be nice to boost the performance as high as possible just to prove this can be done with Flash.

Moral of the story is… if you need to hire someone to fix your problems you might as well hire the guy who says he can get the work done… who knows he might even get it done right away and save you some money OR you can just live with your problems and keep on interviewing until you find Mr. Perfect who may or may not be able to get the job done.  Either way, this is nothing but a trivial problem for those who are suitably skilled – the rest cause the problems without knowing how to fix them.

BTW – The skilled programmer who wanted to fix these problems for that wayward company has also NEVER created a problem he could not fix – hey, I am talking about myself anyway in the 3rd person – this is a story so deal with the literary stuff however you wish… those who create problems they cannot fix should also not piss those off who can fix whatever problems anyone may care to create.

It should be noted Charting Demo was created with a couple Frameworks (Flex and the Google App Engine) that don’t exist anywhere else; Flash Builder 4 for the client and Python/Django 1.1 for the server.  Reusable code make Application Development a breeze – 12 hours is pretty quick for any development effort and this one has some pretty cool features – all those features are 100% reusable.  No reason to spend time reinventing the wheel – unless you are in Corporate America and cannot figure-out how to make your code reusable.

%d bloggers like this: