7 posts tagged “programming”

    In the midst of programming there will come a time where a certain skill will be incredibly useful to know to solve either a quick problem or a large dawning task. With this are 7 very important skills that every programmer should either learn or already have. Here they are:

1. Regular Expressions (Regex)

In the realm of searching, text-parsing and iteration it is all too common for programmers to put together their own form of searching through unstructured data. (By all means, don't fall into this path) It's good that you can figure out how to parse unstructured to slightly uniform data, but there is an easier path. Learn Regular Expressions and your life will be a billion times easier (relatively speaking). Although regular expressions seem ridiculously ambiguous, they provide an important tool in your coding career. Learn it!

• (Here's a powertoy to help: RegWizard)

2. Structured Query Language (SQL)

Information, the very reason technology even exists, will always be as important as the people who are making the technology to use it. It is not only important to understand how to properly model information, but how to query it. Luckily, there is a standard query language that you can use to search for that information of yours. SQL provides the means for connecting information models with the all important people in information technology. Learn it!

• (Here's w3school's website to help: SQL Tutorial)

3 & 4. Extensible Markup Language (XML) and XML Schema Documents (XSD)

Before this technology there was what I like to call: chaos. It was chaotic because the greatest uniform structured format was the dot-slash format. Data was just everywhere. Luckily, the industry finally adopted the XML standard which we all love and use today. XML is a tag < > based format where all data is structured using a tree-node and attribute like structure. With XML you can turn this:

John Doe
11-18-1987
Software Developer

into this:

<?xml version="1.0" encoding="UTF-8"?>
<Person FirstName="John" LastName="Doe">
    <Birthdate>11-18-1987</Birthdate>
    <JobTitle>Software Developer</JobTitle>
</Person>

Giving back the meaning and well-deserved value in information. Not only that, but I and the rest of the developer audience can understand what it is your model is talking about. On top of XML is a schema that we can create for validation. This is called an XML Schema Document (XSD). XSD's are very useful for creating standards for your XML documents and it is definitely a standard that you should learn!

• (Thank you w3schools: XSD Tutorials)
  

5. XML Path Language (XPath)

On top of the extensible tree is another key language in searching through XML-based documents. XPath provides programmers the ability to quickly sort through XML selecting, replacing and rearranging any trees, nodes and data. XPath is not nearly as complex as regular expressions and it looks as if you are searching for a folder on your hard drive. If it's easy, then why not learn it!

• (w3school's website provides an awesome tutorial set: XPath Tutorials)
  

6 & 7. Hypertext Markup Language (HTML) and Cascading Stylesheets (CSS)

We've come a long way since HTML, the foundation laid down by HTML and CSS has allowed millions of users to create their own websites. The web is a funny place. It can also be an ugly place if you're not careful to understand the proper uses of web markup tools like HTML and CSS. With HTML it's important to note that it is used to give usage with a visual understanding of XML based data. Whether the data involves an address to media or a texbox, the markup allows browsers to output that meaning visually to all the users. A common mistake with HTML is to use it in styles. While HTML does include a way for adding style to your webpage, it limits your ability to change those styles in an instant. That's why it's important to not only learn HTML properly but also learn CSS.

• (w3schools and standards: HTML and CSS)
  

    There are of course other skills that do not involve much technical standards such as: understanding object-oriented programming and having problem solving skills. Most of these with and soft-skills are typically acquired over time with more and more experience in the computer science industry. Ask questions, think outside the box, research other ways, draw a picture, showcase your work, but most of all have fun with it: your brain will thank you for it :)

Alright, this time I'm going to get right to the gut of quality assurance and talk about the ideal kind of testing environment when it comes to software, big or small.

Firstly, what kind of project are you planning on building? Is it a website? A desktop application? A mobile phone application? Realistically, it can be any project so long as you follow these 12 guidelines.

1. Do you have source control?
       It's always good to have source control and especially for the type of test driven environment you're looking for it will be even better for running all of those tests.
2. Can you build your solution in 1 Step
       Most of us are using Visual Studio to build our projects but nevertheless you should be able to build your solution in 1 step whether it be building it for debug or compile and/or including deployment. It's a pretty common scenario where you want to deploy your solution immediately when you're done.
3. Do you perform daily builds?
       If you're working on a project that goes day in and day out of work you should ensure that you at least build once a day or at night to follow up tests and issues in the program.
4. Do you have a bug database?
       Bug databases are used for instant tracking of all of your bugs, whether automatically reported by the system or typed in by a user or developer on the team. It's very good to have one of these if you're working in a larger team. But even in a small team (like yourself) it can be pretty handy to organize everything into a simple database of bugs. Makes it easier to clean things off.
5. Do you fix bugs before writing new code?
       This one is tough if you're not working directly off test driven code. What test-driven code means is that for every feature or series of implementations you have written tests to ensure that all logic and implementations are valid or work according to a standard. Think of test-driven development as writing the model that you want your project to become and the code that you are writing to be tested against are the drafts to the sculpture.
6. Do you have an up-to-date schedule?
       What are you working on? What needs to be done? Who's working on what? Try not to think of schedules as some mundane constraint who's only use to keep the manager out of your hair. Schedules are incredibly valuable tools for time management. They teach you to manage your time wisely and keep you from working day in and day out on a silly problem that may mean nothing in the long run. In our industry we are too often thinking about the how and the what-if scenarios of software development but we rarely take a step back and ask whether or not we should do something rather than if it's possible.
7. Do you a specification?
       If you're working on something that other people are going to be either working on or integrating with, please please please for the sake of all time and humanity, write healthy comments and anything else that will help people understand how to work with said system. Tutorials, samples, anything that relates to your system is really helpful for others to use their time just as wisely and timely.
8. Does your team have quiet working environments?
       I know, you're thinking, "Wait a minute. What does quiet working environments have to do with software quality assurance." Well believe it or not, but a quiet working environment is basically a large white board to the mind of a developer and a tester. It ensures that not only can someone hear their own thoughts, but as a team it makes it easier to discuss and collaborate without disturbance.
9. Do you own or use the best tools money can buy?
       Better tools, newer technologies anything that can aid you and speed up your time in development or your goals is far more useful than ever, especially to your users who are so eager to see what you've come up with.
10. Do you have a group of people or person who's sole purpose is to write tests?
        This is more so for larger groups, in small groups you will be the tester and as a developer it's best practice to get in the habit of testing your own code before hand.
11. When you have new people on the project, do you have them write code before joining the team?
        Usually it's a great idea to have the person you're interviewing actually write code related to what you're working with or what you plan to have them working with. Sometimes it doesn't really have to be a test of knowledge but to allow the person to get a feel for the code that he/she will be working with and it allows you to adapt to whatever practices or standards he/she may already go by.
12. Do you perform hallway usability testing?
        Hallway usability tests are done by simply taking your laptop out into the hallway and showing what you've made. It's a great way to get suggestions and get other people excited about your creations. It's a great motivator if the people you test give back constructive criticism. And if you've followed the above guidelines this step should be no problem because you'll never run into a situation of a useless feature or a bug. You can explain it with confidence and passion!

What do I use for my test-driven quality assurance setup?

1. Subversion Web: I try to always have a subversion setup that I can access via the web. These are useful for the fact that most of them have wikis for documentation and logs that come from subversion. It makes it especially easier for deployment since I can just create a release from the website.
   I've been using: unfuddle lately. I think it's great!

Once upon a time there was a man, this man was no ordinary man, he was a thinker; a social thinker. Free and abroad there are no limits to where his mind can go. Each project he came upon was a work of art; focusing in the beauty of social networking and constructing the perfect anatomy to which the interaction and workings should comprise of it. However, one problem arises in his approach, he is no manager; his timing is usually off; and the communication with others lacks with his ability to define a fine path for the goals he sets out. Because of this anomaly in design, each project turns into a recursive space of chaos; dwindling down into the black hole of development.

Each time we start developing our own projects there are some that simply dwell on the idea that others will use it, that "it" will become the greatest thing since sliced bread; all will use it and all will adore. Then you begin to think of what it will do: features and ideas simply thrash their way into that roller coasting storm within your brain. Alright then, where do I start. hmm... let's write something down, like a scope outline or a set of goals. So all those ideas you suddenly thought of turn its way to pen and paper (or notepad if you prefer).

Congratulations you have successfully broken rule number 1 in your intent to finish a great project.

Rule #1:
    Firstly, a project, like any work, is a series of steps starting by it's growth pattern.
    Projects grow into beauty, much like artwork. Where you start is up to you, it's simply a matter of starting it that most people tend to forget.

Alright, so you decide let's take a look at those ideas and put together something of a prototype. Hmm, which feature do I start working on? Well, let's see what's available on the internet, I'm sure someone has something that I can take a look at. So you go off, look at a few.. well hundred samples and you find out that there's definitely something missing in all of these samples. An underlying concept or resource that suddenly because apparent and you begin creating to fix this problem.

Rule #2:
    Research and development is a perfect way to figure out a role in either user design or project dynamics. The problem is that it is too often done well over the time that it's needed for. In addition, while you tune yourself in on each project there is a tendency to fall into a thought-process that causes you to stray from the original goals. This, recursive syndrome, is often found in the minds of programmers and developers.
    "Wanting to build a tool to help you write tool rather than just building the original program."

It's really a habit of perfectionists; because as you build each component you want to make it better, more secure and more extensible, more aesthetically pleasing.

Spending 12 minutes on a button because you don't like it's color or agonizing over a single-pixel error is apart of that perfectionist habit. Break it before it takes a hold of your original intentions.

Introducing the next feature, or next set of ideas it is easy for one to break rule #2 over and over again; and before you know it it's 3 weeks later and not a whole lot is done. Getting passed those 2 rules is easy if you've already set a standard for the project and what to complete.

Standards and requirements don't have to extensive, they're there for guidelines; to keep you in check so you don't endlessly break rule #1 or #2. And generally they're supposed to be small, incremental in design, that's usually why it's supposed to be written in almost the 1st day.

Nevertheless, there's a place where you may not even need several documents of requirements, loads of design papers and prototypes. This place is attributed to the sole creator, designer, architect... etc. Quoting Ze Frank, "every time I have an idea, I try to create it as fast and as soon as possible. otherwise I'll get addicted to brain crack." When it comes right down to it, let a project grow into it's amazing beauty, create as soon and as fast as possible; if nothing comes to mind for it's next selection of growth, then go back and strengthen those genes of the project. You'll find out that the creativity will come a lot quicker when you're constantly getting to show what you've already made.

- This post was really directed at myself since last quarter I had just been putting out brainstorms and visions, but I hope it helps anyone else who's gotten stuck somewhere.

In my previous post I discussed some of the common testing basics when developing a product. In this post I will be going over equivalence classes; that is, identifying characteristics within a feature and classifying them based on a given set of conditions.

An Equivalence class is a set of data that has equivalent characteristics. When you decide on a feature in a program, you must first gather what is important based on the domain knowledge. Equivalence classes can be combined into sets with each value in a class (yes/no answer). However, we can have a value in multiple classes. Let's take the following example, what equivalence classes can you come up with from the data?

        3, 099, 127, 003, 128, +05, -3, -128, 0A1\

• Positive/Negative
  
• Leading Zeros/Non-Leading Zeros
• Leading Sign/No Leading Sign
• Single Digit/Non Single Digit
• Single-digit parsed value (ignore sign and leading zeros)/Not single digit value
• Numbers that can be stored in a signed byte/Not
• Decimal Number/Not a Number

There are however boundaries to each of these classes. With even a minor modification it will be removed from the class. Or contrary to this, identifying values adjoining the boundary where a minor modification will put it on the boundary. In most cases we may have more than one boundary that we are dealing with in an equivalence class. Take the example of a rectangle.

In a rectangle, there are the four edges, the corners, and all the area inside. Similar to test scenarios, prime candidates for testing a point would be on the edge or the corners. With a rectangle we may have the equivalence classes: Left-Boundary, Right-Boundary, Top-Boundary, Bottom-Boundary, Top-Left-Corner... etc.

We can see that there are far more useful scenarios for testing these boundaries than testing the middle of the range. This is simply because we are more likely to run into defects and bugs while testing the boundaries of equivalence classes than the middle. Now let's try this with an exercise (a common test scenario by Myers in 1969).

• Triangle problem
• Program to identify triangles given three numbers
• Scalene, Equilateral, Isosceles, Invalid
• Exercise:
• Identify input classes for individual values (ensure that each value is valid before moving on in the steps)
• Identify equivalence classes and sets of equivalence classes for 3-valued sets of individual numbers that fit
  
• Use representative values to identify power tests sufficient to test all of your equivalence classes.
• Ensure that you cover the boundary, borderline, and mid-range of each value of each equivalence class.

The above enumeration TriangleType will give us the possible equivalence classes. We obviously know the four types Isosceles, Scalene, Equilateral and Invalid. But there is also the different types of Scalene and Isosceles. Take care to include these in your equivalence classes.After we have specified all the different types of equivalence classes we can now construct our Triangle structure.

    public struct Triangle

    {

        private TriangleType myType;

        private double myLongestSide;

        private double myLeg1;

        private double myLeg2;

        private const double Tolerance = 1E-09;

        .........

I have taken care to add the TriangleType and the different sides. When you construct a Triangle you will want to have the three sides of course set. I also have set a Tolerance level which I will discuss later in the initialization part.

      public Triangle(double side1, double side2, double side3)

        {

            myType = TriangleType.Invalid;

            myLongestSide = myLeg1 = myLeg2 = 0;

            if (side1 > 0 && side2 > 0 && side3 > 0)

            {

                if (side1 < side2)

                {

                    if (side2 < side3)

                    {

                        Initialize(side3, side1, side2);

                    }

                    else

                    {

                        Initialize(side2, side1, side3);

                    }

                }

                else if (side1 < side3)

                {

                    Initialize(side3, side1, side2);

                }

                else

                {

                    Initialize(side1, side2, side3);

                }

            }

        }

When we actually create the triangle we need to analyze different equivalence classes based on characteristics that we measure. The common approach will be to determine what values or characteristics define a given equivalence class and even still what other cases will default a case.

I'll make the note that our Initialize method is taking in the following parameters:

private void Initialize(double longestSide, double leg1, double leg2)

The first parameter is the longest side on the triangle, with the other two legs passed in after.

If we look at the first condition: if (side1 > 0 && side2 > 0 && side3 > 0)
We will notice that it the condition is true, then the equivalence class is Invalid. Otherwise we'll move on the other conditions.

In the next condition: if (side1 < side2) there's one of two scenarios that we can look at for initializing (if it is true).

• side1 is smaller than side2
• Is side2 smaller than side3?
• Side2 is the largest side
• Initialize(side2, side3, side1)
• Side3 is the largest side
• Initialize(side3, side2, side1)

After this we can look at:

• Is side1 smaller than side3?
• Initialize(side3, side1, side2)
• Otherwise
  
• Initialize(side1, side2, side3)

Basically we've run into all possible scenarios of values for the different sides. We can classify each of these cases into equivalence classes. Each condition is in fact a characteristic that defines what equivalence class the triangle falls into. Now let's take a look at the Initialize method.

    if (((leg1 + leg2) - longestSide) > Tolerance)

    {

        TriangleType type = TriangleType.Scalene;

        myLongestSide = longestSide;

        double scaledLeg1 = leg1 / longestSide;

        double scaledLeg2 = leg2 / longestSide;

        if (Math.Abs(scaledLeg1 - scaledLeg2) < Tolerance)

        {

            leg1 = leg2;

            scaledLeg1 = scaledLeg2;

            type = TriangleType.Isosceles;

            if (Math.Abs(1d - scaledLeg1) < Tolerance)

            {

                type = TriangleType.Equilateral;

            }

            else if (Math.Abs(scaledLeg1 * scaledLeg1 - .5d) < Tolerance)

            {

                type = TriangleType.RightIsosceles;

            }

        }

        else if (Math.Abs(1d - scaledLeg1) < Tolerance || Math.Abs(1d - scaledLeg2) < Tolerance)

        {

            // Note: no need to check for RightIsosceles if the longest side is one of

            // the sides with equal length

            type = TriangleType.Isosceles;

        }

        else if (Math.Abs((scaledLeg1 * scaledLeg1 + scaledLeg2 * scaledLeg2) - 1d) < Tolerance)

        {

            type = TriangleType.RightScalene;

        }

        myType = type;

        myLeg1 = leg1;

        myLeg2 = leg2;

    }

In our first condition we use the old is it a triangle formula. Side A + Side B - Longest Side  Greater Than 0 or at least the tolerance in this case. If it is then we can start with a Scalene type.

Scalene:

Isosceles:

Equilateral:

As we can see from the different triangles this is what we're testing for. So essentially, scalene: unequal sides, this is why by default the type is Scalene. After the following condition, (if the sides subtracted is close to zero), then we know that all sides either equal or this is possibly an Isosceles. I use the scaled leg to ensure that decimal points are taken into consideration instead of whole numbers.

double scaledLeg1 = leg1 / longestSide;

double scaledLeg2 = leg2 / longestSide;

if (Math.Abs(scaledLeg1 - scaledLeg2) < Tolerance)

We can determine if the triangle is an equilateral if the 1d - scaledLeg1 is less than our Tolerance level. Otherwise, if the scaledLeg1 squared - .5d is less than our Tolerance level then it's a Right Isosceles triangle.

  if (Math.Abs(1d - scaledLeg1) < Tolerance)

  {

      type = TriangleType.Equilateral;

  }

  else if (Math.Abs(scaledLeg1 * scaledLeg1 - .5d) < Tolerance)

  {

      type = TriangleType.RightIsosceles;

  }

We know that it's an Isosceles if two sides equal each other so the next condition handles as opposed to the first condition.

else if (Math.Abs(1d - scaledLeg1) < Tolerance || Math.Abs(1d - scaledLeg2) < Tolerance)

Other than this, if all three sides are not equal, then it's a Scalene triangle, handled by the next condition.

else if (Math.Abs((scaledLeg1 * scaledLeg1 + scaledLeg2 * scaledLeg2) - 1d) < Tolerance)

To sum this all up we will simply test a few cases, I won't go into detail about utilizing our testing principles since this tutorial is for learning the concept of equivalence classes but you get the idea. However, I hope this has helped you understand some of the basics to identifying characteristics into classes. In the next post I'll discuss how to properly identify features.

If you want to learn all the mathematics behind the idea of Equivalence Classes, and how that got started, you can check out the Wikipedia entry here.

There has been some discussion over how much .NET developers actually use in their first few years of development. I'd like to post a few keywords that are rarely seen for the majority of us. Feel free to comment on any others to contribute to this post.

UPDATE: Thanks to Matthew, I've added the default keyword.

stackalloc
    stackalloc allocates memory dynamically from the stack. Its very fast and the memory is reclaimed after the enclosing function exits. But it, of course, has some limitations. It only works with blittable types. It's good for arrays that will never be anything more than a few hundred kilobytes. By default, the maximum stack size is one megabyte. In practive, function call depth is very very small, unless you do something like a recursive function scanning a deep tree. Offsetting the risk that a stackalloc can generate the StackOverflowException is the infrequency of multiple dynamic stack allocations in use at the same time.

    Even for moderately large arrays, stack-based allocation can be preferable to heap allocations, especially if these allocations are very frequent or very temporary. The worst type of allocation for the garbage collector are large arrays, especially temporary ones. Large objects (over 85K) are placed separately in the large heap and are only release during a full garbage collection. (In other words, the more frequent Gen 0 or Gen 1 partial collections do not release large memory allocations). Large objects are never compacted, resulting in potential fragmentation and wasted memory.

yield
    yield is a common term used when referring to Iterators. The keyword can only be used in the context of an Iterator actually. Furthermore, the definition of an iterator holds the usage of yeild. Here are some definitions via MSDN.t

• An iterator is a section of code that returns an ordered sequence of values.
• An iterator can be used as the body of a method, an operator, or a get accessor.
• The interator code uses the yield return statement to return each element in turn.
• Using iterators, it is no longer necessary to implement the interfaces System.Collections.IEnumerable and System.Collections.IEnumerator when creating a collection class that supports foreach. The compiler does this work for you.
• The return type of an iterator must be System.Collections.IEnumerable, System.Collections.IEnumerator or one of the generic iterator interfaces.
  

  Yeild

volatile
    The volatile keyword indicates that a field might be modified by multiple concurrently executing threads. Fields that are declared volatile are not subject to compiler optimizations that assume access by a single thread. This ensures that the most up-to-date value is present in the field at all times.

    The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock Statement (C# Reference) statement to serialize access. See How to: Create and Terminate Threads (C# Programming Guide) for an example of volatile in a multi-threaded scenario.

default
    Generally seen in generic code, the default keyword can be used to obtain the default value to a parameterized type (such as T) when you don't know some of the following:

• Is the type: Value-Type or Reference Type.
• If it is a value-type, is it numeric or a struct.

The easiest way to get the initialized value is by calling the default keyword. This will avoid any code that may initialize a generic type to null or a numeric value. We can add a little more polish to our generic types and utilize the type constraints feature of C# 2.0.

Type Constraints
    Aside from the usual keywords, there are also other concepts that may be uncommonly used. One really neat trick to generics in C# .NET 2.0 is type constraints. This is where you can take a generic type like T, and apply constraints such as the types polymorphisms and inheritance factors. We can take a simple type T, and actually require that it implements a given interface or inherits from a particular class. Even still, we can require that it has a default constructor created.

In this case I am writing type constraints on the generic type Products to implement the IBuilder interface and contain a default constructor (indicated by the new() constraint). This can be handy when dealing with generic types and you can ensure that not just any type is being used for a particular class.

Recently I've been running into a few interesting bugs that occur when painting in GDI+. I wrote this tutorial to help those who have run into issues with drawing gradients, double buffering, and form border style issues.

The first issue I shall address is painting in the right place.

Commonly, when creating windows forms to draw special backgrounds such as gradients and static text or pictures, developers will override the OnPaint method. Generally you'll want to paint according to logic in the OnPaint method, and backgrounds in the OnPaintBackground. Let's start by creating a gradient background.

Override OnPaintBackground and take a look at the GraphicsPath class

We can see that it uses the namespace System.Drawing.Drawing2D. We will use this namespace for drawing other surfaces. After instantiating your GraphicsPath object.You will notice the many methods we can add call to draw.

To get a smoother drawing mode, set the graphics object SmoothingMode to a specific property such as AntiAlias this can turn a tacky title into a something really smooth.