Archive

Posts Tagged ‘Software Development’

Dependency Checker

February 2, 2015 Leave a comment

Dependency Graph

Have you ever had software work on your machine and not work on a different machine? Missing dependencies is a common cause of software that works in one environment and not in another. Modern software is most often a tapestry of libraries and frameworks that must be present on a machine to function properly. Even the simple “Hello World” programs that are used so frequently to introduce programming languages require additional libraries to run outside of a development environment.

Windows Environments: Dependency Walker

Dependency Walker (depends.exe) is a tool that has been around for many generations of Microsoft windows. This tool is your basic tool for diagnosing Windows dependency problems in the field.

Unix Like Environments: ldd

ldd is a shell tool used to list dynamic dependencies (shared object files). This is your basic tool for diagnosing dependency problems in unix like environments.

Resolving Dependency Errors

Why is the dependency required?

Sometimes project templates for ISEs can incorporate common dependencies that you may not need for your specific application. Always determine why a dependency is needed. You should be able to account for every library and framework your application requires. This knowledge may also extend to the dependencies of your dependencies and so forth. While this process of tracing dependencies can be tedious, it can teach you a lot about the frameworks you use and the operating systems you distribute on. In simple terms, don’t carry any more dependencies than necessary. Each dependency is a potential vector for bugs and vulnerabilities.

Is your application built correctly?

Some operating systems (i.e. Windows) distinguish between debug and release libraries. There will often be restrictions on distributing debug libraries. Debug libraries are often associate with the developer’s machine only. The QT framework on windows is a perfect example of this. Applications linked for debug link to QT libraries  with ‘d’ prefix (qt5cored, qt5guid, qt5networkd, etc.) This is case where something working on a developer machine and not on another machine is expected behavior.

Can static linking help your problem?

Some languages, such as C++, allow dependencies to be completely pulled into an executable at compile time. This means that the operating system does not need to resolve the dependency at run time because everything is already in the executable. The downside of static linking is that executable sizes increase and dependency updates require an entirely new application to be published. This had helped me in the past to incorporate Boost program options into an application. Static linking is not only language dependent, but also conditional on your licensing situation. Static linking to certain GPL works can cause the linking application to become a derivative of the GPL work and force the linking application to comply with the GPL terms. Consult appropriate legal and technical council for more information on this advanced topic.

Can you detect when the dependency is not met?

One common approach to dependency resolution is to check that prerequisites are met before allowing the application to be used. Visual Studio is a prime example of this approach. Visual Studio requires a number of companion technologies to be installed before the application can be installed. This does not prevent future problems because a user can uninstall still remove a prerequisite at a later time but it does set a nice baseline for what the publisher expected the system state to be.

Would setting minimum system requirements help?

Sometimes large sets of dependent files are distributed as a single update. An example of this would be service packs for Microsoft operating systems or names versions on Mac OSX (Yosemite, Snow Leopard, Mountain Lion, etc.) Requiring a specific update set can be an easy way to ensure dependencies are met. For example, when a minimum version of the .NET frame work is required.

Are you future proof?

Libraries change. Sometimes the way your software is written can cause unnecessary coupling between your application and the specific version of a library. My work supporting applications on Ubuntu has highlighted this idea. At some point in the life the software specific library versions get referenced. When transitions occur between 10.04 ->12.04, 12.04 -> 13.04 and 12.04->14.04 the default distribution for a library is based lined at a newer version. The older version are simply not present in the canonical package repositories. Sometimes members of the community post back borts for commonly used libraries but there is no guarantee this will be the case.

How Should the dependency be resolved?

Should you distribute the dynamic library or shared object file with your application? Should you rely on a different installer or updater to put the files there? How you answer these questions depends on the technology being used. Software is generally licensed, not sold. Software licensing dictates the terms that the software can be used and distributed. License restrictions may forbid the component from being installed by a third party. Others may all distribution as long as attribution is made. Some operating systems forbid or discourage the distribution of key system components. For example, it would be inappropriate to distribute a component that is normally updated through Windows Update. In some instances it may be appropriate to rely on a different installer to add and remove a component. The OpenSSL libraries are a good example of this. Every piece of software on the planet has bugs, including mission critical security software. Once you take ownership of distributing a library you are also on the hook for distributing all future security updates. If you don’t do this your software can either be disabled by system administrators or used as an attack vector against flawed software.

Advertisements

Source Control

February 2, 2015 Leave a comment
Uncle Rico tried to buy a time machine online

Uncle Rico tried to buy a time machine online

Do you ever wish you had a time machine? Maybe you would like to see ancient history first hand or re-live an important decision in your life? While we can’t travel through time and space, we can achieve a close second in our technical work using source control. Source control is kind of like a time machine for your plain text files.

A simple form of source control could work like the following:

  1. Do some work in an electronic document
  2. Save the file off with with a unique name at a given point
  3. Repeat steps 1 and 2 until the work is complete

This model works well for a small project with a single author. But this approach becomes problematic when different circumstances emerge such as

  • Multiple authors are contributing work
  • Two or more parallel works need to be merged into one work
  • There are lots of files that need to be tracked
  • Additional meta data is needed such as author, time and change notes

When one or more of these conditions emerge it becomes appropriate to utilize source control software. As is true with many universal problems in the software industry, the problem of tracking revisions has been solved with many different tools over time. As a frame of reference I have directly or indirectly dealt with seven different source control systems over the course of 14 years. A thorough comparison of source control systems can be found here: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software As with other articles in this series we will focus more on the factors to determine the right tool and less on any one solution.

Factors to Consider When Picking a Source Control Tool

What file types are being stored?

Most often source control systems focus on the task of versioning plain text (i.e. code and code like artifacts). They frequently do this using a difference concept where the changes from one version the next are captured. This also means that while some solutions are great at tracking plain text changes, they can also be terrible at tracking “binary” files such as images and office documents. If you are working with binary files, source control systems might not be a good choice

What is your environment?

One of the reasons why there are so many source control solutions is because there are so many ways to make software. Your environment might include one or more operating systems, official and unofficial IDEs of the team, and graphical vs. terminal workflows. For example, if you are using a Visual Studio based work flow in a Windows environment, Team Foundation Server may be a natural fit because it is seamlessly integrated with specific versions of Visual Studio. On the other hand if you have have a mix of Windows, Mac and Linux hackers you might want to consider a Git solution paired with visual clients like gitk.

What are your resources?

Some of the popular source control solutions have a price tag associated with them. Even “free” software can have a cost when paired with cloud services with a prime example being private repositories on GitHub. Different solutions may also require varying levels of infrastructure. Do you have a person who knows how to setup a server securely or setup a database? This infrastructure also needs maintenance over time to ensure availability, performance, and security.

What does the team prefer?

Developer productivity is an essential element in delivering a quality product. Productivity and morale will suffer a developer has to learn a complicated system or constantly fight a tool chain. Developers and other content creators should have a major say in the tools they are required to use. It is true that most developers like learning new things, but introducing too many new tools or technologies cripples a teams ability to craft new solutions. Keep the number of completely new tools and technology to one or two if you want to have any hope of making your schedule projections.

Common Workflows to Master

Regardless of which tool is selected as the right answer, team members will need to master a few common work scenarios. These skills are essential and should not be schlepped off to peers. Address avoidance of these tasks immediately because they could be:

  • An indicator that more hands on training is required
  • An indicator that the wrong source control solution was selected
  • An indicator that corrective action and coaching is needed at an individual level

Universal Source Control Tasks

  • Add a file or files to source control
  • Remove a file or files from source control
  • Obtain the newest version of a file or files
  • Obtain a specific version of a file or files
  • View revision history for a file or files
  • Fork or branch from a given version
  • Join or merge two versions
  • Roll back to a specific version
  • Create a new version and share it with others
  • View the changes between two versions
  • Mark or otherwise annotate specific versions

Lab[3] = Make Some Noise

November 19, 2013 9 comments

Note: If you tried this lab on or before 8/29/2013, there was an error in the original code. Please download the code again.

Objective

  • Run the Jaalaga starting code on a device
  • Pick different sounds
  • Update the credits screen if you use different sounds

What You Will Need

Lab Version

  • Version 0.3

Prerequisite

In Lab[0] we setup a development environment. Our development environment at this point includes several software tools, the AndEngine source code and our Android or Kindle Device. Among the code was a project with a wide variety of AndEngine examples. You should have reached a point where you ran these examples on your device. If you did not reach this point you should get Lab[0] working before tackling this lab because it requires a working AndEngine setup.

Introduction

In this lab we take what we accomplished in lab[2] and add some excitement with some sounds. Audio is an important element to a game because it can is another way to convey to the player what is going on in the game world. Tense music and sound effects can add an extra level of challenge to any game. In the interest of keeping these labs shorts, we will focus our audio efforts on replacing existing sounds.

Steps

Run the Starting Code for Lab 3

First you will need to get the starting code from Git Hub at the link described above. Add this project to your working setup from Lab[0]. Note, if you changed the graphics in the previous labs, you can update just the “src” folder and the “assets/sounds” folder.  Compile and run the code. You should now hear sounds when a missile is fired or when a missile collides with an enemy. If you are happy with the sounds, you are done!

Update the Sounds

The source code for this lab and future labs will be marked with comments that have TODO at the beginning. This lab has x such comments

Original Sounds

The player missile fire sound is a creative commons attribution sound. Therefore the sound shows up in the credits. Here is the original sound: http://www.freesound.org/people/bubaproducer/sounds/151022/ This file is saved as playerFire.mp3 and is stored in /assets/sound/

The collision sound is another creative commons attribution sound. It is also listed on the credits scene. The original sound can be found here: http://www.freesound.org/people/Robinhood76/sounds/187647/  This file is saved as enemyExplosion.mp3 and is stored in /assets/sound/

Replace Sounds

If you want to use different sounds, replace the mp3 files mentioned above to a file with a different sound. Make sure they are fairly short because the audio pool is a small, finite size. If you load a sound that is too big to fit into memory, AndEngine will simply not play the sound.

Update the Credits

See the new file JaalagaCredits.java for code that displays the credits screen. When using sound from FreeSound.org, or any source, you should comply with the license terms. Attribute means give the author credit. Non-commercial means you can’t use the sound if you intend to publish an app for profit. Honoring license terms is the right thing to do as a content creator. If you can’t or don’t want to comply with the license terms, simply don’t use the work.

Lab[2] = Make it Collide

November 12, 2013 Leave a comment

Objective

  • Run the Jaalaga starting code on a device
  • Detect collisions between missiles and enemies
  • Establish good values for the ship’s speed and missile speed with the expanded game loop
  • Pick better sprites for the enemy ships

What You Will Need

Lab Version

  • Version 0.5

Prerequisite

In Lab[0] we setup a development environment. Our development environment at this point includes several software tools, the AndEngine source code and our Android or Kindle Device. Among the code was a project with a wide variety of AndEngine examples. You should have reached a point where you ran these examples on your device. If you did not reach this point you should get Lab[0] working before tackling this lab because it requires a working AndEngine setup.

Introduction

In this lab we move beyond what we learned in Lab[1]. A new red button has been added that causes ‘missiles’ to fire from the player’s ship to the newly added enemies. Some basic collision detection has already been added to the code restricting the ships movement to the camera bounds. What is missing right now is the collision detection between the player’s missiles and the enemy ships.

The image below displays the type of thing you should see when first running the code for this lab.

Screenshot_2013-11-11-00-00-08

Steps

Run the Starting Code for Lab 2

First you will need to get the starting code from Git Hub at the link described above. Add this project to your working setup from Lab[0]. Note, if you changed the ship sprite by finishing the last lab, you can update just the “src” folder and the “AndroidManifest.xml” file.  Compile and run the code and you should see something like the screen above.

Examine TODO Items

The source code for this lab and future labs will be marked with comments that have TODO at the beginning. This lab has six such comments

lab_2_todo

Collision Detection for Missiles and Enemy Ships

First, as be sure that you have tried to shoot a ship. What happens? A less than interesting  event happens as the graphic for the missile travels right over the enemy sprite. For this part of the lab will actually try to write some code. Step by step instructions will be given, so don’t panic.

The general algorithm, or approach to solving a problem, we will implement is as follows:

For each missile, iterate over every enemy ship and determine if a collision has occurred. When a collision has occurred, remove both the missile and enemy from the screen.

The procedure above is represented in the flow chart below. Note that this flow also includes hiding rockets that have left the screen. The code you need to add to accomplish this flow is provided below.

lab_2_procedure

lab_2_code

You should add the code above to your project and run the game to see that missile impacts now cause the enemy ships to disappear. Some notes on the code above:

  • A “for loop” is a way to do things in a repeated fashion. It is of the form “for( initial value; condition; end of loop action)”. The normal practice is for loops to count upwards, but this loop is a specific scenario where we may need to remove items and we don’t want to lose our place.
    1. We set the variable j to the last item in the enemies list
    2. We check to see if j is greater than or equal to zero. In other words we check to see that if we have more enemies.
    3. If we still have an enemy, we we execute all instructions in the loop, else we exit
    4. At the end of the loop we reduce the value of j so we can access the next enemy
    5. Return to step 2
  • The recycle call in theory should return the object used for the missile to the pool to be reused. This is because making too many objects can slow down your program as “garbage” builds up and must be cleaned up. That is the theory, but in reality there is a bug in the RocketPool right now that means that the recycling/reuse is not happening. Expect this to be fixed in the next lab.
  • You effectively “remove” something from the screen by hiding it and turning off updates.

Change Ship and Missile Speed

At this point, you may be saying, “I already did that in lab 1!” The need to repeat the exercise is three fold.

  1. The code changed in a fairly dramatic fashion. We could have had a lesson on using a difference tool, but I figured you did not have the time or interest.
  2. The game loop has now grown and the old values may no longer work well.
  3. Repetition strengthens neural pathways

Change Sprites

Something as simple as MS Paint can be used to change graphics. You can also use more advanced image editing software like GIMP (http://www.gimp.org/)

  • /assets/gfx/button01.png (Width: 512 px, Height: 64 px)
    • Normal and pressed graphic
  • /assets/gfx/menu/logo.png (Width: 240 px, Height: 240 px)
  • /assets/gfx/game/ship.png (Width: 64 px, Height 64 px)
  • /assets/gfx/game/enemy1.png (Width: 32px, Height: 32px)
  • /assets/gfx/game/enemy2.png (Width: 32px, Height: 32px)
  • /assets/gfx/game/enemy3.png (Width: 32px, Height: 32px)
  • /assets/gfx/game/playerRocket.png (Width: 5px, Height: 15px)

Lab[1] = Make it Move

November 1, 2013 Leave a comment

11/8 Update: Significant rework since last revision

Objective

  • Run the Jaalaga starting code on a device
  • Restrict the ships movement to only left and right movement
  • Find a ship speed that that is good for the game
  • Replace the ship sprite with a better graphic

What You Will Need

Lab Version

  • Version 0.5

Prerequisite

In Lab[0] we setup a development environment. Our development environment at this point includes several software tools, the AndEngine source code and our Android or Kindle Device. Among the code was a project with a wide variety of AndEngine examples. You should have reached a point where you ran these examples on your device. If you did not reach this point you should get Lab[0] working before tackling this lab because it requires a working AndEngine setup.

Introduction

In this lab we will start to build our game. As we discussed in class, we will be building a game that is similar to the arcade classic Galaga. We can’t use the same name so we will just call our game “Jaalaga”. In Jaalaga you will be piloting a space ship and trying to eliminate the hostile aliens. You ship is fixed to the bottom row of the screen. Your ship can move left and right and can fire two shots at any time. Enemies move in formation and periodically break formation to dive at your ship. All ships are destroyed when they are hit by a missile or collide with another ship. In this lab we will focus of the movement of just the player’s ship.

The images below display the two screens we will see:

Screenshot_2013-11-08-02-26-11    Screenshot_2013-11-08-02-25-50

Steps

Run the Starting Code for the Game

First you will need to get the starting code from Git Hub at the link described above. Add this project to your working setup from Lab[0].  Compile and run the code and you should see the screens above.

Examine TODO Items

The source code for this lab and future labs will be marked with comments that have TODO at the beginning. This lab has three such comments

lab_1_todo

  • JaalagaResourceManager.java (Line 208)
  • ManagedGameScene.java (Line 122)
  • ManagedGameScene.java (Line 56)

After reading the comments, make changes to the code based on each TODO item. You may have to look up help on AndEngine functions to change the right thing. Feel free to make a guess and verify if your assumptions were correct. When you have completed the three TODO items you have completed Lab[1].

Lab[0] = Display Something

October 25, 2013 Leave a comment

Objective

  • Run the AndEngine Examples

What You Will Need

  • A computer with an internet connection
  • Free Android Software (Explained Below)
  • An Android device or Kindle HD device

Lab Version

  • Version 0.7

Introduction

AndEngine is a set of libraries or code blocks that make creating 2D games easier. It was created by an engineer named Nicolas Gramlich at Zynga and is used by many developers as the base of games and applications. In this lab we will do the setup required to compile and run the AndEngine examples.

Video Tutorial

The following video was created by someone else, but it does a good job of explaining the process of moving from no setup to running the AndEngine examples. What follows the video is a text explanation of what the video covers along with some specific notes to make the process smoother.

Install Software

  • Latest Java JDK
  • Latest Android Developer Tools Bundle (Includes Eclipse and the Android SDK)

Steps

  • Configure Eclipse to make it easier for debugging
    • Show progress bar
    • Show line numbers
    • Show log viewer
  • Download files from Git Hub user RealMayo
    • Repositories Link: https://github.com/RealMayo?tab=repositories
    • Download zip file for each repository
    • Unzip all files
    • My notes to make your life easier
      • The default zip file name has “-<branch name>” appended to the end where <branch name> is something like GLES2 or master, remove this
      • Sometimes when Windows unzips things it adds an extra folder level, you don’t want this. A picture of the type of thing you do want in the end is shown in the picture below.
      • Fix all of the names and the hierarchy before importing to save yourself some pain
      • Here is what the project folders should look like
        • andengine-projects
      • He is what it typically looks like inside each folder
        • typical-project-folder
  • Import all projects into Eclipse
  • Download all Android environments API level 8 and above (This is going to take a while)
  • Fix project build problems
    • If you read the note above you will have far fewer problems than in the video. You read it, right?
  • Build the project
  • Run on the Examples project on a device

Kindle Details

The video is not Kindle specific. Here are some extra resources to help you if you are working with a Kindle Fire device.