In C# there are two methods for casting:

1. (T) works with both value and reference types. It casts the object to T, and throws an InvalidCastException if the cast isn’t valid.
   e.g -; Foo obj = (Foo) bar;
2. as (T) works only with reference types. It returns the object casted to T if it succeeds, and null if the cast isn’t valid.
   e.g -;

Foo obj = bar as Foo;  
if(obj == null)
{  
  // the cast did not succeed so proceed accordingly  
}  

The question therefore is which one should be used where?

Using (T) means that you fully expect the cast to succeed. If it doesn’t succeed then there is an error in the code that needs looking at.

Using as (T) on the other hand means that you do not fully expect the cast to succeed in every case. It is considered normal behaviour if the cast did not succeed and this would be taken care of through a null check afterwards.

The only mistake is when you use as (T) but do not follow it up with a null check. The developer fully expects the cast to succeed so doesn’t write the null check. However later down the line when something goes wrong, no exception is thrown on the invalid cast, no null check is performed, and you have yourself a bug that is hard to track down. It is best to always use the regular cast (T) unless you intend to check yourself for the invalid cast via as (T) and a null check afterwards.

So apparently there is a new bit of malware going around now which is particularly nasty. It encrypts all of the data on your drive and mapped network drives with an RSA 256 bit AES key. Once encrypted there is obviously no way to decrypt it again. The only way to get the files back is from an off site backup (because if the backup drive is local it also gets encrypted) or to pay them their ransom which would of course decrypt your files (not). The fact that this also attacks networked drives is particularly annoying and I bet this would catch a lot of people out if they were to get infected.

Source and More Info

When using the Git version control system with Git Bash it can often become annoying when you have to manually type in the full absolute paths to particular files in your project. For example when trying to add changes to the staging area or checking out a file, in a large project typing out the full file path can be very tedious:

git add src/uk/co/ryanharrison/snippetmanager/SnippetManager.java

or

git checkout src/uk/co/ryanharrison/snippetmanager/Snippet.java

The problem is especially bad when working on Java projects as the folder structure follows the package names which can often get rather long.

Handily there is an alternative when using Git Bash to all this typing - the ‘*’ or ‘2-asterisk globstar; which searches recursively down your file structure for a file matching the given name.

The above commands can then be replaced with:

git add **/SnippetManager.java

which will add any file called SnippetManager.java Bash finds below the current working directory to the staging area. The same works with all other commands:

git checkout **/Snippet.java

Apparently for this to work in Bash you first have to activate globstar using this command:

shopt -s globstar

however the Git Bash in Windows does not seem to support this. The functionality seems to still work though, at least when using it within Git commands.

I’ve written and Android app that can be used to view stocks and shares information from a wide variety of different businesses. The user maintains their own stocks portfolio so they only see the latest figures and information for the tickers that they are interested in - be it technology businesses such as Google or Microsoft, or perhaps just the popular financial indicator such as the FTSE or Dow Jones. The portfolio can be added to or removed from at the users convenience.

The full source code for this app is available on my GitHub account.

Also download the .apk file to install it on your own devices (Froyo and above).

Rather than presenting the information in a big long table, this app aims to give you the basic information about each ticker in a more graphical way. I’ve used colour coded tiles instead of a table which displays red for a ticker that has gone down in price in the current day of trading, or green if it has risen. Other pieces of the most important information is also present in each of the tiles. This includes the market the stock trades in, the current price, the price change, the price change percentage and the market capitalisation value.

Here is the main app display which shows the ticker tiles for each of the stocks currently in the users’ portfolio. As more stocks are added, tiles are added to the bottom. The figures themselves can be updated by tapping the icon in the top rightmost corner. In a way this almost replicates ‘live tiles’ in Windows 8.

As I said before the tickers that are monitored on this screen can easily be added to through the use of the ‘+’ icon in the top right hand corner. This brings up the ‘Add ticker’ screen that allows you to search for a given company. In this example I search for ‘Google’ which brings up a list of possible stocks to add to the monitored portfolio. Here I choose the main Google ticker ‘GOOG’. It immediately gets added as another tile on the main screen with the most recent price information. To remove a ticker from the portfolio, hold your finger on the appropriate tile and select ‘ok’ in the confirmation menu that appears. The tile will be immediately removed from the main screen and the figures for the stock will no longer be downloaded unless the ticker is added again through the ‘Add Ticker’ view.

To view more detailed information and figures about a particular ticker in your portfolio, simply tap the appropriate tile that contains the relevant ticker. This brings up a new screen containing further financial figures about the stock along with a news feed with items relating to the stock. The news feed is updated constantly with the tickers to present the newest articles. Tapping a news article opens up the article in your web browser. For example here is the display for Yahoo Inc which was accessed by simply touching the Yahoo tile on the main display. As you can see the news feed is presented at the bottom and more detailed figures are at the top including the Day Highs and Low, Years High and Low and Volume figures.

When inside the detailed information view for a particular stock, you can also view various charts for the stock which illustrate the price changes over a certain timeframe. Access this by tapping the ‘View Chart’ button. By default a 3 month chart will be shown however you can change the charts timespan by selecting an option from the top of the page. Here is an example showing the 1 month chart for Yahoo -

Each view in the app is fully compatible with a wide range of screen resolutions in both portrait and landscape. For example when flipped to landscape, the detailed information view for a stock is changed to present the information in a more user friendly manner -

All data in the app is downloaded from the API’s by Yahoo! Finance (free for personal use). The app is also compatible with devices running Android Froyo (version 8) and above. I may do further posts on the internal infrastructure of the app which relies heavily on parsing retrieved XML and JSON data.

Get the full source code from my GitHub account.

Download the .apk file to install the app on your own devices (Froyo and above).

Cut out all the sugar from pretty much any unit testing framework and you have yourself the situation where the users have marked their test classes to signify that they contain test methods and have marked the test methods themselves to tell the framework to actually run them.

So really on the base level (cutting out assertions and such) you need to somehow figure out which methods in which classes should be run by your tester. In managed languages this becomes a lot simpler through the use of reflection. We can simply ‘reflect’ on each of the classes/methods and decide if they should be run or not.

Here is some short C# code that demonstrates this idea through attributes and reflection. Classes which contain test methods are marked with the TestClass attribute and the test methods themselves which will be run later on are marked with the TestMethod attribute. The code uses LINQ to first get all the types in the currently executing assembly which include the TestClass attribute. Then all the methods are found in each of those classes which are marked with the TestMethod attribute. Finally each of those test methods are invoked using a new instance of the test class itself. The code is all commented so it should all be self-explanatory.

This simple idea can then be added onto in a load of different ways. For example some methods are expected to throw certain exceptions. The TestMethod attribute could therefore be modified to allow that exception through. The unit tester itself could then be adapted to catch that exception and still pass.

  
using System;  
using System.Collections.Generic;  
using System.Linq;  
using System.Reflection;

namespace UnitTester  
{  
    // Attribute to mark that a class contains tests that should be run  
    [AttributeUsage(AttributeTargets.Class)]  
    internal class TestClassAttribute : Attribute  
    {  
    }

    // Attribute to mark that a method is a test and so should be run  
    [AttributeUsage(AttributeTargets.Method)]  
    internal class TestMethodAttribute : Attribute  
    {  
    }

    // Class does not have TestClassAttribute so will ignored  
    internal class TestSuiteOne  
    {  
        // Method has TestMethod attribute but resides in a class without TestClass so will be ignored  
        [TestMethod]  
        public void DoTestOne()  
        {  
            Console.WriteLine("Doing test one in TestSuiteOne");  
        }  
    }

    // Class does have TestClassAttribute so will not be ignored  
    [TestClass]  
    internal class TestSuiteTwo  
    {  
        // Helper method does not have TestMethod attribute so will be ignored by the tester  
        // However will be run once indirectly through DoTestOne()  
        private void Helper()  
        {  
            Console.WriteLine("Helping to run the tests in TestSuiteTwo");  
        }

        // Method has TestMethod attribute so will be run by the tester  
        [TestMethod]  
        public void DoTestOne()  
        {  
            Console.WriteLine("Doing test one in TestSuiteTwo");  
            Helper();  
        }

        // Method has TestMethod attribute so will be run by the tester  
        [TestMethod]  
        public void DoTestTwo()  
        {  
            Console.WriteLine("Doing test two in TestSuiteTwo");  
        }  
    }

    internal class Program  
    {  
        public static void Main()  
        {  
            // Get access to all the types in the executing assembly  
            Assembly assembly = Assembly.GetExecutingAssembly();

            // Get all the types whose custom attributes includes TestClassAttribute  
            IEnumerable<Type> testClasses =  
            assembly.GetTypes().Where(t => t.GetCustomAttributes(false).Any(a => a is TestClassAttribute));

            foreach (Type testClass in testClasses)  
            {  
                Console.WriteLine("Running tests in TestClass: " + testClass.Name);

                // Get all the methods from the testclass whose custom attributes includes TestMethodAttribute  
                IEnumerable<MethodInfo> testMethods =  
                testClass.GetMethods().Where(m => m.GetCustomAttributes(false).Any(a => a is TestMethodAttribute));

                // Create an instance of the test class so we can run the test methods from it  
                object testClassInstance = Activator.CreateInstance(testClass);  
                foreach (MethodInfo testMethod in testMethods)  
                {  
                    // Run each of the test methods using the instance of the testclass  
                    testMethod.Invoke(testClassInstance, null);  
                }  
            }  
        }  
    }  
}