Off Topic

Firefox 3 ignores cache control http headers - security risk for online apps!

Tim Huffam — Fri, 26 Sep 2008 03:17:40 GMT

If a user, using Firefox 3, signs out of a web site and does not close the browser, anyone else using that browser subsequently can view the content of pages loaded by the previous user (eg in an internet cafe, or any place where workstations are shared eg universities) - exposing private/confidential data.

This only affects HTTP post requests (not gets) and only Firefox version 3 - earlier versions (1.5, 2 etc), and IE, are not affected.

The main points are:

This is definately a bug: a violation of RFC 2616, section 14.9 that states "The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain".
Some companies who deem this a significant hole in their security have chosen to block requests from Firefox 3 (eg they deem it their responsibility to secure their customers private and confidential data to the best of their ability).
This bug has been registered with the Mozilla dev team, but currently (as of 26 Sept 2008) has a status of unconfirmed.

Task Oriented Programming

Tim Huffam — Mon, 08 Sep 2008 12:10:06 GMT

For some time I've been wondering if there's a better way to program business logic. Years ago I used to write COBOL, then moved onto a 4GL, bla bla bla... and today I find myself well entrenched in OO with Microsoft's .Net. Development times don't seem to be much better these days - and the complexity of things seems to have mushroomed.

We went from barely-a-3GL to 4GL back to 3GL plus an explosion of things you need to consider. We started with procedural code then moved to OO and seem to have got stuck there. But somehow I think we need to revise our use of OO. Business logic is predominantly procedural code - even if written in OO; it starts, follows a process, performing stuff until finished eg Customer.UpdateCreditLimit()

OO is really good for modelling things - as per the classic OO examples of a bicycle or car. And thus they model business things quite well too - like an Invoice or a Customer.

However, I've found that the more object oriented the code gets - the less productive, maintainable and flexible it becomes. Not saying leave OO - far from it - it's brilliant. It's just that we need to learn when to say 'when'. The use of patterns has helped a huge amount - but these can also caused similar problems - when being applied where they aren't really needed - resulting in overly complex software (read: inflexible and unmaintainable and unproductive). It's a fine line - and it's not easy to get the balance.

A major break through in this area is LINQ. This has meant we have less clutter in our apps catering for ORM (brilliant). This has resulted in code very similar to the old 4GL days (essentially 4GLs were just SQL based code anyway) - where all you care/code about is the business logic - caring not a jot about how or where a Customer or Order got created - and in this age of SOA - that becomes more important (as a Customer could come from many different sources - local RDBMS, company ERP, external CRM etc). I guess you could say LINQ allows you to focus your code to be more domain specific (not saying it's a DSL).

I have been playing with workflows for donkeys of years and found that although the individual workflow systems themselves can range from very simple to incredibly complex - the individual tasks they perform need not be. This had lead me to start thinking about applying this principle to code design at a reasonably low level.... what if we developed tasks as objects. Each task has just one job (I've heard some people say this is how objects 'should' be coded anyway). It has properties that can be get/set. Keeping things dead simple, eg:

public class AdderTask
{
    public int Addend1 { get; set; }
    public int Addend2 { get; set; }
    public int Result { get; set; }
    public AdderTask(int addend1, int addend2)
    {
        Addend1 = addend1;
        Addend2 = addend2;
    }
    public AdderTask Execute()
    {
        Result = Addend1 + Addend2;
        return this;
    }
}

To run this you'd simply do this:

int result = new AdderTask(1, 2).Execute().Result;

Exposing the task's properties means you can build up get and set statements - and because the Execute method returns the task object itself you can easily use it in a single line as if it was a method on it's own - or retrieve it's property values after the Execute (these tasks would easily be adapted to work within a workflow system).

This style lends itself to expanding; rather like building blocks, you can build large workflows out of these task oriented blocks. The workflows themselves coded just like these tasks - whereby all the business logic resides within the Execute() method.

Adding LINQ to the mix takes this to the next level - allowing you to build software that is simple to develop and understand.

I've been building a sizable system using this technique and I'm finding that I'm converting code developed using standard OO practices over to this methodology as it makes code more easily reused - but most importantly: easier to read and maintain.

In summary:

All input and output parameters should be implemented as properties (getter and setter accessors).
Provide a constructor that accepts all required parameters. A default constructor (with no parameters) is optional (I've found I never need these - but if you were to use these tasks in a workflow system they may need this).
Provide an Execute() method that takes no parameters and returns the object instance eg return this;
The object should clean up after itself.

Other notes:

Originally I created a similar type of class for workflows - but I found that these ended up being no different in concept to tasks. Likewise I've found that some tasks needed to call other tasks - so I've ended up just implementing everything as tasks. On reflection this is actually quite valid - because, as I found when building large orchestrations using Biztalk, workflows become atomic tasks themselves when used within the context of a large orchestration (which may run many workflows and external tasks) - and the orchestration, from a highlevel could also be considered an atomic task.
I've found using System.Transactions.TransactionScope great for scoping transactions around many tasks when creating a macro task that runs many sub tasks.

Suggestions/comments very welcome - I'd like others to expand or comment on this.

Tim

Agile Manifesto - addendum 0.1

Tim Huffam — Wed, 23 Jul 2008 01:58:02 GMT

Fresh chocolate chip cookies and fresh coffee over garden variety cookies and instant coffee

That is, while there is value in the items on the right, we value items on the left more.

The unspoken rule is that non-team members attending team meetings must come bearing the fore mentioned items

Microsoft Word - cursor placed at top of page.

Tim Huffam — Tue, 15 Apr 2008 21:12:23 GMT

When creating a new document and in Print Layout, Word sometimes places the cursor right at the top of the page - not catering for the top margin.

I'm not sure why - can only presume this is a bug.

The workaround, to make it display the cursor where it should be (below the margin) seems to be to view the Header then hide the header:

Select menu item 'View' - 'Header and Footer' (this shows the header)
Do the same thing to hide it (Select menu item 'View' - 'Header and Footer').

That's it - the cursor should now be placed where it should be - so you can start typing text and see it in the correct position on the page.

HTH

Tim

Turning off custom menus/always show full menus in Microsoft Office applications (Word, Excel, Outlook, etc)

Tim Huffam — Tue, 29 Jan 2008 13:43:44 GMT

To turn off the annoying customised menus in Microsoft Office products (Word, Excel, Outlook etc) do the following:

1. Start up an Office application eg Word.

2. Select menu item 'Tools' - 'Customize...'.

3. On the 'Options' tab, check (put a tick in) the 'Always show full menus' check-box, then click on the 'Close' button.

That's it

How to make a transparent background/selection on an image using GIMP

Tim Huffam — Sun, 19 Mar 2006 21:49:00 GMT

Open your image.
Select the area you want to make transparent.
1. Select the appropriate selection tool from the Tool window or the Tools - Selection Tools menu on the Layer window. I usually use the magic wand/fuzzy select (Select contiguous region) tool or the Select regions by color tool.
2. Click in the region you want selected. Use shift-click to add more regions/colors.
  Tip: It's easier if you zoom in (View - Zoom menu) to see finer details of exactly what you're selecting.
In the Layer window (the one showing your image), select Layer - Transparency - Add Alpha Channel. If this is blanked out then it's already done. This makes sure your image can store transparency data.
Select Edit - Clear. This makes the selection transparent.
Save the file.
Note: If you save it as a PNG file, be sure to select the 'Save colour values from transparent pixels' option in the Save as PNG dialog box.

And that's it.

NOTE: IE does not support showing PNG transparencies (alpha channels) natively. There are a few work arounds for this (theres loads to be found on google) - here's MS's solution. However, personally, I find the simplest approach is to save the image as a GIF (which all major browers support transparencies for).

When saving your image as a GIF from within Gimp, it will prompt you to export it - you can select either Indexed or Greyscale - however, on the next screen (Save as GIF) be sure to check the 'Interlace' option.

HTH

Tim

Arse Bandit Alert!

Tim Huffam — Wed, 09 Nov 2005 21:17:00 GMT

LMAO when stumbling across an RSS aggregator called RSS Bandit.

Actually, it's very good... and the app aint bad either ;-)

Google helps push Firefox

Tim Huffam — Wed, 09 Nov 2005 21:13:00 GMT

Now this is interesting.