Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

So I started playing Skyrim last night and I have to say: What a Treat!

Permalink | Leave a comment  »

Permalink | Leave a comment  »

I posted the following on our NewMediaLabs website and thought I would share here too...

Software projects are  packed chock-full of Risk. It's important to acknowledge the risks and to mitigate them. How you address the risks depends on which type of "project process" you are following. The two types of project processes that I have experienced are Agile-type and Waterfall-type projects. In this post I list some of the common ways to mitigate well-known risks for both these project types.

When given a choice we prefer to adopt an Agile approach. We believe that following an Agile approach leads to a far superior final product. We also believe that Agile is much less risky. So this post is unashamedly biased in favor of Agile.

First, a brief description of the two types of projects:

Waterfall-type project: 

A waterfall project typically has a set deadline for set functionality.  Many businesses like this type of project because it seems predictable and makes it easy to get a budget approved for the project.

Process: Plan, Build, Test, Done.

Problems:

• Trying to predict accurately while software development is very unpredictable.
• User Requirements Specifications are usually insufficient and open to interpretation, which leads to errors.

• Scope Creep is time-consuming to manage and often "sneaks" in due to unclear specifications. This puts pressure on the development team to deliver more functionality in the same amount of time.

Agile-type project:

An agile project is typically seen as a recurring monthly expense instead of a big capital expense. Features are delivered frequently  (typically every two weeks) and the project carries on for as long as it is delivering useful functionality.

Process: Plan, Build, Test, *Repeat Repeat Repeat

Problems:

• Unable to promise specific features at a specific deadline far in the future.

• Difficult to work with businesses with a "waterfall" mindset (most big old businesses).
• Difficult to get project approval when hard-and-fast promises can't be made.

Advantages:

• Deliver what's useful, not "what the spec said".

• Deliver useful features early.

• Detect problems early.

• Embraces change.

Why Projects Fail

Projects can be considered failures for many reasons. The most common reasons that I have observed are:

1. Budget Overruns and Late Delivery - these two usually go hand-in-hand.

1. Incorrect Functionality delivered - the client expected one thing and the programmers built something else.

1. Technical Problems - for example: the system is too slow to use, or it doesn't integrate with another critical system in the software ecosystem.

Below is a list of ways to combat these three problems in either a Waterfall or Agile project.

Problem 1: Budget Overrun/ Late Delivery

Waterfall:

• Add extra time to mitigate risk. For example: estimate 13 hours for a 10 hour task. Not optimal. Expensive.

• Track progress against milestones to ensure the project is progressing on schedule. (The problem with milestones is that they can give a false sense of security. When you think something is "Done" it might not really be. "It's done! (except for the styling, or integration with external system X)")

• Work overtime if needed to catch-up.

Agile:

• Frequent delivery means most important features get delivered early.
• If less important features are late it is not such a big deal. The system is constantly improving and maturing.

Problem 2: Technical Problems

Waterfall:

• Do lots of prototyping in the first stage of the project to try and spot technical challenges.

• If caught late it may be too late to do anything about it. Major losses.

Agile:

• Will be picked up early due to continuous early delivery. Project can then go a different direction, or cancel project if absolutely necessary (at least it will be early).

Problem 3: Wrong Functionality (incorrect assumptions)

Waterfall:

• Write very detailed user requirements specification. (The problem with User Requirements is that they give a false sense of security. Now matter how explicitly they are written, they are still open to individual interpretation and interpretation may not be what the author intended.)

• If caught late it may be too late to do anything about it. Major losses.

Agile:

• Agile embraces change. Frequent delivery ensures that the correct functionality is delivered and any "mistakes" are detected early. The client is continually evaluating the system and can change direction as required.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

For my personal project I would like to show a message to the user if the user is using an old browser. This is mainly because I don't want to spend time testing all the old browsers. I'd rather just tell the user that the site works better on certain browsers and give him the links to download the browser of his choice.

(PS: I know this is bad practice. I'm being lazy here...)

Thankfully JQuery makes this ridiculously easy. Here is the code (adapted from Think2Loud)...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<div class="works-best-on hidden">
    This web application works best on a modern browser like <a href="https://www.google.com/chrome">Chrome</a>, <a href="http://www.mozilla.org/en-US/firefox/new/">Firefox 4+</a> or <a href="http://www.microsoft.com/ie9">Internet Explorer 8+</a>
</div>

<script type="text/javascript">

    $(function () {
        if (badBrowser()) {
            $(".works-best-on").show("normal");
        }

        function badBrowser() {
            if ($.browser.msie && parseInt($.browser.version) <= 7) { return true; }
            if ($.browser.mozilla && parseInt($.browser.version) <= 3) { return true; }
            return false;
        }
    });
    
</script>

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Initially I was feeling discouraged about these bloody apples. But in the end I'm very happy with how the painting turned out. This is my first still-life painting and painted from life instead of a photo. Fun :)

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

• In "Remote Configuration" I specified that clients all need to use "Network Level Authentication".
• I only allowed Remote Desktop Connections for a single account (meaning only one account can be compromised)
• In "Local Security Policy" I specified that the account should be locked for a few minutes on 3 failed logon attempts.
• I made the password much longer and more complex.

Permalink | Leave a comment  »

I'm about to write some HTML-to-PDF conversion code for a website that I am working on. It sounds like everyone uses the iTextSharp library. 

I had to laugh when I loaded the iTextSharp.com website and only got the following response.

<html>
        <head>
        <title></title>
        </head>
        <body>
        </body>
        </html>

Thanks for the info! At least the "nothing" is formatted properly.

Permalink | Leave a comment  »

Apparently the hacker group "Anonymous" will be taking down facebook on 5 November. 

Thought I'd post what my friend, Danie, has to say on the subject:

 Anonymous uses distributed  denial of service attacks as their main weapon. Also its gives a measure of control so that if a target is selected to be effective it would need to be supported by the greater majority of Anonymous. As there in lies the strength and appeal of the group. Everyone has a voice and everyone has a free will to either take part in an attack or not. There is no one person acting as the leader of this group as its a hive mind. Thus its impossible to fight and almost impossible to stop even harder to prosecute all of them.

Given the average age of Anonymous i would say that the facebook attack will not hold big appeal to the majority. Thus rendering the DDos attack ineffective. Yes Anonymous does have splinter groups that does not use these kinds of attacks as they are the "none script kiddie" hackers that does the intrusions into the target network infrastructures. But the notification of the attack came from Anonymous and not one of these splinter groups like Lulsec. If it did facebook might have some trouble.

PS they do refer to "Antisec" in one of their statements. As that is the elite group of Anonymous. If they get involved it might be game over for facebook on that day. 

PPS.... Anonymous always gives notice about their attacks in advance as transparency gives the "target" time to appeal to Anonymous itself why this attack should not happen. Even other Anon's can plea a case for the target.

PPPS... FB is running a massive number of servers all over the World currently. To shut FB down you will need to target not just a single server. But multiple servers in multiple countries in multiple time zones. This will require 24 hour attacks synchronized with peak traffic times of FB. Just take an example. South Africa has its own FB cache server locally were all feeds are loaded onto locally then there are multiple main servers hosted in the USA in different states and Data centers also running on ipv6 that makes DoS attacks very hard to pull off. Its a massive task with their normal DDoS attack.

Food for thought. Let's see if anything happens on 5 Nov. I'm not holding my breath.

Permalink | Leave a comment  »

Deadlines in the programming world are tricky. They are a necessary evil unfortunately, so one needs to learn how to deal with them.

I think it's important to deliver in time and make your deadlines, but I also think it's near impossible(!). The biggest problem is that estimates are so unreliable. The only way to get a perfectly reliable estimate on how long a bit of programming is going to take is to go and physically write the code - only then will you comprehend all the "devil in the details". But then the "estimate" is no longer an estimate (it's like saying Africa is a 1:1 scale map of Africa).

Another problem is that requirements are often misunderstood and change frequently. So even if you did estimate 100% accurately, you probably estimated the wrong thing. Crap.

To cope with deadlines,  you have four options:

1. More accurate estimates means you're more likely to take on just enough work and not too much. You'll never get to the 100% accuracy mark, but doing more in-depth planning and design does help get you closer to it.
2. Sacrifice code quality - i.e. no unit testing, copy-paste code etc. This may help in the short-term but will probably come back to bite you (especially when requirements change and you have to change your code). So I never recommend this option.
3. Work more hours - either cut down on distractions and interruptions so you can work more hours during the normal working day (this is good), or work overtime after-hours (this is bad).
4. Cut features - release something, even if it doesn't have all the features required initially.

Personally I try to cut features. Where possible I try to be more productive during the day, but there's only so much you can do. I try to never work overtime. And I try to never sacrifice quality.

Permalink | Leave a comment  »