Cheedar Cheese Press now support Blender files

Article written by: mrbriandog123
September 2nd, 2013    Posted in Uncategorized

For our latest app, Mobile Model Viewer, our free online compression tool Cheddar Cheese Press now supports importing Blender files! Submit a ZIP containing a “.blend” file and the tool will export a COLLADA file for use with Mobile Model Viewer.


Comments Off

Keeping Planes in the Sky and Satellites in Orbit

Article written by: Michael Boldischar
April 5th, 2013    Posted in Developer Resources, Java, Uncategorized

The idea came to me the other day as I was assigning a value to a variable in Java. I asked myself, “What units are being used for this variable?” Every number you enter into a programming language has some type of units associated with it. Some units are simple: feet, pounds, inches, meters. Other units are more complex: newton seconds, miles per hour, feet per second squared.

Why are units so important? Units are important because they make important calculations correct. They are especially important when more than one person is using the same piece of data. If we didn’t know the units being used in our code, we would be lucky to find out sooner than later. Here are some examples of major disasters that occurred because of improper understanding of units: Unit Mixups.  One example from that page is the loss of the Mars Climate Orbiter.  It crashed because systems involved each assumed different units for an impulse bit which caused the unit to lose it’s course and disintegrate in the atmosphere of Mars.  Another example from the non-programming world is the Korean Air MD-11 crash.  In this example, no software was at fault, but the same problem occurred.  There was a misunderstanding about meters versus feet.  The flight crew thought they were supposed to fly to 1,500 feet instead of the instructed 1,500 meters.  They lost control and crashed.

How do programmers deal with units in object-oriented programming?  The first way they do it is through documenting variables.  For example:

int height = 300; // feet

The next way they handle units is by encapsulating the variables and exposing methods that convert between units as the value is returned. Also, they include constants that help convert between units. For example:

private int height = 300; // feet
private static final float METERS_PER_FOOT = 0.3048;
public int getHeightInFeet() {
   return height;
pubic float getHeightInMeters() {
   return height * METERS_PER_FOOT;

Both of those techniques for communicating units have worked well. But, in mission critical applications, an engineer may want more assurances. This brings us to a wild and crazy idea. Variables have had three parts to them for all these years. First, the variable has a name. Second, it has a value. Third, (added recently) it has a type. Values are stored in “primitive” types (e.g. float, int, short, char, etc…). So, a variable with a value of 5 could really mean anything. What if we gave variables a fourth component? What if they had a component for units? Whoa, you say! I don’t want more boiler plate code! Then, you probably aren’t writing code that will be used for life support on the International Space Station. Because if I was writing code for those brave astronauts, I’d want all the checks I could put in my code.

Here’s an example of how it works. I haven’t perfected a syntax, so I’m using annotations as an example:

private int height = 300

Now you ask, “Why would I want to program in my units?” This is the most important question! Because the compiler can perform a type of static analysis on the code to find problems where you are assigning values in the wrong units to a variable. This sounds trivial, but it’s very profound. Here’s an example with a units error in it:

private int height = 300
private int speed = 300
public float calculateMetersPerSecond() {
   return height / speed;  // this is returning the wrong units, i hope the compiler catches this

When the developer tries to compile the code above, it should generate an error saying that the function is trying to return meters per second, but the variables are identified as feet per second. It shouldn’t even compile, let alone take down a satellite!

This seems pretty amazing to me! I wish there was a nicer syntax for describing the units. I’m sure someone will think of one. Identifying units each time a variable is used would provide an extra layer of protection against engineering disasters. I think this idea could save lives. What do you think?


We have released our first app – Mobile Model Viewer!

Article written by: mrbriandog123
January 18th, 2013    Posted in Uncategorized

The new Mobile Model Viewer Android application has been released on Google Play. This exciting application can parse 3D COLLADA models and display them on a mobile device. Here are some screen shots:


The Main Menu




A Wheel of Cheese

Click here to check it out on Google Play

Take a look at the User Manual for it here:

Comments Off

Android Ant Proposal

Article written by: Michael Boldischar
March 17th, 2012    Posted in Android, Apache Ant, Java

We just finished submitting a proposal to the adt-dev Google Group. Here is a link to the new proposal. The goal of the proposal is to get a set of standard Ant tasks developed for Android.

We would appreciate some feedback on this proposal. Let us know if you would like to help or have ideas.

No Comments

Mocking Frameworks Considered Harmful

Article written by: Michael Boldischar
December 1st, 2011    Posted in Developer Resources, Java, Uncategorized

I’ve been on several projects where developers use Java mocking frameworks.  The most popular of these frameworks is called Mockito.  I’m pretty open to giving new technology the benefit of the doubt.  I used it for several months and found reasons to consider mocking frameworks harmful.  I constantly get asked why I don’t use them by other developers.  I always say that one day I’ll write a blog article on the subject.  Here it is.

Here are the reasons I consider mocking frameworks harmful:
1. When you need to use mock objects , you are saying that you are unable to use standard unit testing on your code.
2. The tests you develop with mocking frameworks are tightly coupled to the internals of the code.
3. The code you test with mocking frameworks is hard to refactor.


1. When you need to use mock objects, you are saying that you are unable to use standard unit testing on your code.

I’ve seen systems where testing using mock objects was the only option.  This is usually a sign there is a major design problem in the system.  The most common cause is too much coupling in the code base.  This can mean too much coupling in the domain layer or between layers (e.g. domain and infrastructure).  Or, classes have references to “god” objects (i.e. objects that have too much responsibility).


The most important part of Object Oriented Programming is build a solid domain model; it should be independent of other layers.  See Eric Evans diagram for a good example of domain-driven-design architecture.  This domain model needs to limit the number of points where it interacts with infrastructure services.  I’m going to use the example of a database infrastructure service.  The domain model should have an interface database through some type of “repository” object or facade.  A common use case for mocking is to test classes that interface with a database.  This becomes a major obstacle in systems where JDBC objects are sprinkled around in the domain layer.  These objects need to be bundled in a cohesive class or package to reduce the coupling between the domain layer and infrastructure layers.  The repository objects that communicate with the database need to be interfaces. This allows you to change database technologies later in the project because all the JDBC code is in one area.  When these repository interfaces are trivial, you can even do things like create in-memory concrete instances of repositories for testing.


You might say, “Okay that’s great, now my database calls are all in the same class.  But I still need to unit test them!”  Here’s the deal my young apprentice.  Testing interactions between larger systems/components is not unit testing.  It’s called integration testing.  That’s why it’s important to have a suite of integration tests to exercise all the major functions of your system.  Your integration tests should be run regularly during development.  Consider using a Linux cron job with automatic email reporting.  When you have a hammer, every problem looks like a nail.  Remember that you have a toolbox.  One of my favorite tricks in integration testing is using Python scripts to call interfaces and aggregate results.

2. The tests you develop with mocking frameworks are tightly coupled to the internals of the code.

The first point wasn’t enough to convince you that mocking frameworks are considered bad practice, eh?  So you went to work the next day and create the class called “SuperAwesomeHelperUtility”.  Yes, it’s more or less a god class that knows everything about sandwiches, email systems, and databases.  But you don’t care because your mocking framework will help you test this utility.  Please don’t attempt this type of coding at home or work.

Here is one of your unit tests:

public void testMakeTurkeySandwichEmailTomAndStoreSandwichData() {
   Connection mockConnection = mock(Connection.class);
   EmailServer mockEmailServer = mock(EmailServer.class);
   SandwichMaker mockSandwichMaker = mock(SandwichMaker.class);
   SuperAwesomeHelperUtility utility = new SuperAwesomeHelperUtility(mockConnection, emailServer, sandwichMaker);
   utility.makeSandwichEmailFriendAndStoreSandwichDataInDatabase("", "turkey", "turkeydb");
   verify(mockConnection).executeUpdate("insert into sandwich values (\"turkey\")");

First, the test above isn’t a complete unit test.  It’s just an example of the types of calls that cause tight coupling between code and unit tests.  In the example above, the internal calls in the method “makeSandwichEmailFriendAndStoreSandwichDataInDatabase” have been exposed by the mock objects passed in the constructor of the “utility” instance.  The concept of encapsulation is being broken by verifying the calls to external components are made.


Again, this is an example of bad design.  But this is the trap that mock framework users fall into.  It becomes their crutch when implementations are hard to unit test.  Soon the practice becomes common in a group because it somewhat solves the problem.  This type of viral malpractice needs to be identified early and stopped.


3. The code you test with mocking frameworks is hard to refactor.

Have you ever tried refactoring code that has all the calls to other components mock tested?  It’s impossible.  Especially when there are thousands of verify calls to other components in a unit test class.  That doesn’t sound very agile, does it?  You might have to throw away the entire unit test and start over if you decided to refactor the “Connection”, “EmailServer”, or “SandwichMaker” classes or method signatures found in item 2 above.

Everyone knows how important unit testing is during development.  The point of unit testing is to test the functionality of one unit of code.  That usually means testing at the method level.  In my experience, good code can be easily tested at the unit level because it doesn’t depend on lots of other services for testing.  Here’s another example.  Say you want a function that tests adding two numbers together:

// adds two numbers together and returns the result
public int add(int x, int y) {

That’s as simple as it gets in programming.  And that’s the whole idea!  You want to write simple methods in Object Oriented Programming.  You also want to reduce dependencies between classes.  Your class for adding two numbers together should not have a dependency on the “SuperAwesomeHelperUtility”.  If it does and you need to mock it for testing, you’re doing something wrong.

No Comments

Microtransaction Library Uploaded

Article written by: Michael Boldischar
October 1st, 2011    Posted in Android, Apache Ant, Java, microtransaction, Unified Modeling Language

I finally finished enough of the microtransaction library I mentioned during our last podcast and posted it on our site. I made the license open source so you can use it in your own projects. I wrote some documentation on how to use it. Also, I marked it as beta since it hasn’t been fully tested and integrated into a real application yet. This project has a lot of potential. It greatly simplifies the life of developers who want to use in-app billing.

Here is a link to the new library:

No Comments

Disgruntled Rats Podcast for September 11, 2011

Article written by: Michael Boldischar
September 11th, 2011    Posted in Android, Apache Ant, Gamers, Graphics Engine, Java, OpenGL ES 2.0, Podcasts

Download Podcast

Download the Podcast for September 11, 2011

Show Notes


Michael Boldischar

Sean Godinez

Brian Morgan

Computer Graphics

Cloth Simulation Algorithms

WebGL Raytracing Water Simulation


Google Buys Motorola Mobility

Amazon Kindle Rumors

Android Steals 20% of iPad Tablet Market


Tactile Feedback from Disney

Battlefield 3: Focusing on Innovation

Minecraft and Steam

Discussion Topic: Using content delivery services. Good idea for new games? Build or buy?


George Clooney Suggests Matt Damon For Presidency


Microtransactions/In App Billing in Android


We are accepting short audio questions to play during one of our recorded episodes. If you would like your question played on our show, email an audio clip to

You can find show notes on our website:

Friend us on Facebook for your chance to win a Disgruntled Rats t-shirt

If we made a mistake or you have news to share, or want a product reviewed, email us at

No Comments

Game Development in Android

Article written by: Michael Boldischar
August 9th, 2011    Posted in Android, Apache Ant, Developer Resources, Graphics Engine, Java, OpenGL ES 2.0, Ubuntu

Thanks to everyone who attended our session on game development in Android yesterday.  Sean, Brian and I all had a great time and enjoyed the questions and interactive discussions.  If you have any other questions for us, send us an email at

Here is a copy of the presentation we gave.  Also, the Java User Group website should be posting a recording of our event sometime in the future.

Download PDF presentation

Happy coding!

No Comments

New Android Examples Added

Article written by: Michael Boldischar
August 8th, 2011    Posted in Android, Apache Ant, Developer Resources, Graphics Engine, Java, XML

In preparation for the Twin Cities Java User Group Presentation on August 9th, 2011, the Disgruntled Rats have added new Android example projects to their website. Check out the following link for more information:

We will continue adding examples and content to our website that is useful to developers as time permits.

Cheers and happy coding!

No Comments

The Quick and Dirty to OpenGL ES 2.0 on Android

Article written by: sean.godinez
August 1st, 2011    Posted in Android, Gamers, Graphics Engine, OpenGL ES 2.0

This is a short article for those familiar with OpenGL's programmable pipeline and are
interested in using the OpengGL ES 2.0 API for Android development.

To use the OpenGL ES API in an Android environment you have to setup a GLSurfaceView
object, override the GLSurfaceView.Renderer, and attach the renderer to the surfaceview.
Additionally, you could extend GLSurfaceView to capture touchscreen events by overriding
onTrackballEvent() and onTouchEvent().
Step 1) Check that OpenGL ES 2.0 is supported and attach your renderer.
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
public class MyOpenGLApp extends Activity {
    private GLSurfaceView mGLSurfaceView;
    protected void onCreate(Bundle savedInstanceState) 
        mGLSurfaceView = new GLSurfaceView(this);
        ActivityManager am = 
            (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
        ConfigurationInfo info = am.getDeviceConfigurationInfo();
        if(info.reqGlEsVersion >= 0x20000) {
                mGLSurfaceView.setRenderer(new MyOpenGLAppRenderer(this));
        } else {
                //Buy a new phone
    protected void onResume() {
        //Do additional stuff to unpause your game/app
    protected void onPause() {
        //Do additional stuff to pause your game/app
Step 2) Setup your OpenGL Renderer
    a. Override onSurfaceCreated
    b. Override onDrawFrame
    c. Override onSurfaceChanged
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;
import android.content.Context;
import android.opengl.GLSurfaceView;
import android.opengl.GLES20;
public class MyOpenGLAppRenderer implements GLSurfaceView.Renderer
    public MyOpenGLAppRenderer(Context context) {}
    public void onSurfaceCreated(GL10 glUnused, EGLConfig config) {
        //Initialization -> Steps 3, 4, and 5
    public void onDrawFrame(GL10 glUnused) {
        //Update the graphics, bind resources, and render -> Steps 6 and 7
    public void onSurfaceChanged(GL10 glUnused, int width, int height) {
        //Adjust your camera/rendering parameters or just look funny
Step 3) Initialize your shader program
    a. Create, load, and compile the vertex and fragment shaders
        i.   glCreateShader(shader_type) // => GL_VERTEX_SHADER / GL_FRAGMENT_SHADER
        ii.  glShaderSource(shader_reference, shader_source_code);
        iii. glCompileShader(shader_reference);
    b. Create the shader program and attach the vertex and fragment shaders
        i.   glCreateProgram();
        ii.  glAttachShader(program_reference, vertex_shader_reference);
        iii. glAttachShader(program_reference, fragment_shader_reference);
    c. Link the program and check for errors
        i.   glLinkProgram(program_reference);
        ii.  glGetProgramiv(program_reference, GL_LINK_STATUS, results, 0);

Step 4) Request the locations of specific variables within the shader program
    a. Uniform Locations
        i.   glGetUniformLocation(program_reference, "uniform_name_goes_here");
    b. Attribute Locations (can also be mapped during vertex buffer binding)
        i.   glGetAttribLocation(program_reference, "attribute_name_goes_here")

Step 5) Create and Load Vertex Buffer Objects (it’s a little different if you are not using VBOs)
    a. Create Vertex and Index Buffers
        glGenBuffers(number_of_desired_buffers, returned_buffer_IDs, 0)
    b. Bind Vertex Buffer
        glBindBuffer(GL_ARRAY_BUFFER, vertex_buffer_id)    
    c. Load Vertex data into buffer
        glBufferData(GL_ARRAY_BUFFER, size_in_bytes, vertex_data, GL_STATIC_DRAW);
    d. Bind Index Buffer
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, index_buffer_id)
    e. Load Index data into buffer
        glBufferData(GL_ELEMENT_ARRAY_BUFFER, size_in_bytes, index_data, GL_STATIC_DRAW);

Step 6) Rendering Preparation
    a. Use the program shader
        i.   glUseProgram(program_reference)
    b. Map each Vertex Attribute to an index (ex: position attribute below)
        i.   glEnableVertexAttribArray(VERTEX_POS_INDEX)
        ii.  glVertexAttribPointer(VERTEX_POS_INDEX, VERTEX_POS_SIZE, GL_FLOAT, false, 
            VERTEX_SIZE_IN_BYTES, offset_in_vertex_structure)
    c. Bind each Attribute Index to its respective attribute location in the Vertex Shader
        i.   glBindAttribLocation(program_reference, VERTEX_POS_INDEX, “a_position”)
    d. Send uniform data like the model-view projection matrix to the GPU
        i.   glUniformMatrix4fv(mvp_location, 1, false, mvpMatrix.getAsFloatBuffer());

Step 7) Render
    a. glDrawElements(GL_TRIANGLES, numIndices, GL_UNSIGNED_SHORT, offset)

Step 8) The quick and dirty clean up calls for you neat freaks out there
    a. glDeleteBuffers(number_of_buffers, buffer_IDs)
    b. glDeleteShader(shader_reference)
    c. glDeleteProgram(program_reference)


Step 1 sets up your activity class, queries EGL (the ‘glue’ between OpenGL and the OS window) for OpenGL ES 2.0 compatability and attaches your renderer.
Step 2 sets up your renderer class allowing you to handle initialization, rendering frames, and handling surface size changes.

Step 3 gets your shaders down to the GPU as binary instructions. 

Step 4 gets the ‘addresses’ of variables in your shader program so that you can push data into them from the client side. 

Step 5 builds your vertex buffer objects on the GPU. These VBOs hold data such as vertex positions, normals, colors, and texture coordinates. 

Step 6 maps the data in your vertex structures to attribute variables in your vertex shader, and also pushes data (like the model-view matrix) down to your shader’s uniform variables. 

Step 7 renders the attribute arrays we mapped out using glVertexAttribPointer in Step 6. 

Finally, Step 8 does some clean up.

For more detailed information in audio form check out some of our podcast spotlights.  I go through the OpenGL ES 2.0 pipeline in our March 20th, 2011 podcast and take a deep dive into bump mapping, parallax mapping, and relief mapping in our July 10th, 2011 podcast.

If you are looking for a good book on this topic you can’t go wrong with the OpenGL ES 2.0 Programming Guide by Aaftab Munshi, Dan Ginsburg, and Dave Shreiner.  The book’s code examples are in C, but it’s a fairly straight forward mapping to Android’s GLES20 class.  There are also some Android examples on the book’s website. They can be pulled down via svn from here:

Feel free to post any questions or comments.

No Comments