Wonderful Iphone Icon Generator Online

http://www.iconj.com/iphone_style_icon_generator.php

Give your divs a simplistic nice shadow with css

I loved the middle box shadow in the shopify.com website, and therefore decided to dig it up. The CSS used for it is:

-moz-box-shadow: 0px 0px 15px rgba(0,0,0,0.1);

-webkit-box-shadow: 0px 0px 15px rgba(0,0,0,0.1);

box-shadow: 0px 0px 15px rgba(0,0,0,0.5);

At: http://www.shopify.com/faq

The 'Call Super' Antipattern

A common design problem that is usually solved using the 'Call Super' antipattern (also referred to as code-smell). Simply stated, the problem occurs when the subclass needs to share the implementation of the super classes over-ridable methods.

In such case, 'Call Super' anti-patten is usually used by calling the over-ridden methods from within the subclass's over-riding methods.

I'll show a 'Call Super' code sample, then show a much better and neater solution (proposed by Martin Fowler).

The Bad Solution (Using the 'Call Super' AntiPattern):

class Penguin {
public void intoduceYourSelf() {
        System.out.println("Hi, I'm classified as a penguin.");
    }
}

class EmperorPenguin Extended Penguin {
    public void introduceYourSelf() {
        super.introduceYourSelf();
        System.out.println("My real name is Emperor Penguin");
    }
}

A Better Solution
A much better solution is to have an abstract method in the super class for the extra actions the subclasses will perform. And thus, the subclass only needs to implement that abstract method:

class Penguin {
    public void introduceYourSelf() {
        System.out.println("Hi, I'm classified as a penguin.");
        talkAboutYourselfMore();
    }
 

    abstract public talkAboutYourselfMore();
}


class EmperorPenguin extends Penguin {
    public void talkAboutYourselfMore() {
        System.out.println("My real name is Emperor Penguin");
    }
}

Thats it. A neat alternative solution that I love to use.

Patterns Plus Anti-Patterns

In every engineering science lies the notion of good (design) patterns.

This comes out as a result of repeating good ideas and/or methodologies that work. Once being repeated in different places, a pattern is spotted in which it gets popular between the engineering community and can be safely reused, it even acts as guidelines to beginners.

"Another important concept - but not as popular - is the concept of anti-patterns."

Good Patterns and Antipatterns complete each other. Anti-Patterns are simply the bad patterns that have been spotted being practiced repeatedly and should be avoided.

Its important to note that patterns and anti-patterns do not apply only to software engineering, but rather can be applied to any science. You can even apply it in your own kitchen (strong assumption: you have a kitchen).

I'll discuss here some anti-patterns spotted in the managerial world that have been popular and should be avoided:

1. Fruitless Hoop: The manager who requires endless (often meaningless) data before making a decision.
2. Golden Child: When special responsibility, opportunity, recognition, or reward is given to a team member based on personal relationships or contrary to the person’s actual performance.
3. Leader Not Manager: Being a great leader doesn’t necessarily mean being a great manager.
4. Manager Not Leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability
5. Management Meeting Mania: The manager whose only function in the organization is to schedule useless meetings
6. All You Have is a Hammer: One-dimensional management where the same technique is used on all subordinates.

These will do for today. For more you can search google or checkout wikipedia. Keywords Anti-Patterns and Managerial. You can also check amazon.com for good books on the anti-patterns subject.

Stable Software

From a black box perspective, stable software boils up to the following:

1. Good usage of Version Control Systems. Branching revisions, branching features, tagging releasing, merging, detecting flaws from versions logs, histories, comments and generated diffs. After being able to use version control correctly, I'm starting to wonder how I ever by-passed such a requirement.

2. Good Bug Tracking. I'd rather call it 'good issue tracking', since its not always a bug, it could be a required future feature, a priority for the next release, a recommended third party code to use, a small research signifying or recommeding new code structures. Bottom line, being able to track the past, present and future of your software's needs.

3. Good Quality People. Not the ones that randomly click everywhere trying to spot a bug. No, I'm talking about Smart Quality People that can intelligently utilize (or even build) testing tools and automation scripts to consistently be able to test every build and every release in a convenient time without having to repeat the quality cycle all over again. In short, good quality people build good quality assembly lines that result in consistent high quality output for every minor or major release launched.

I Smell Rotten Code.

Here's my best self-awareness test for detecting areas of self-written rotten-code in my source code. The question you have to ask yourself after finishing a code module is the following:

Are you afraid of looking into the code you wrote for this module?
Are you having any discomfort when it comes to adding extra functionalities to your code?

If the answer to any of the above two questions is yes, then I believe you have a problem and your code needs 'refactoring' (another cool word for 'restructuring').

Build space ship 'One' before space ship 'Two'

Whenever you have an idea for a library, product, class or anything else, always remember to build space ship one first, stop collecting extrabonanzic features and ideal design methodologies to reach directly to your dream space ship, start with space ship 'one' always.

This means, if its a product, this would be the minimal set of features that will make it usable.

If its a library, this means exposing the minimal set of functions that are sufficient to achieve the main objective of the library.

If its a class, then allow the smallest simplest possible code that'll make it work.

Ofcourse, before you even think of starting to work on Spache Ship 'Two', remember to launch spache ship 'One', or else, you're skipping the advice.

In a product's sense, space ship one is usually your own design, thoughts and implementation. After launching space ship one, people will start giving you feedback on certain conveniences, improvements, enhancements which you should take into account in space ship two.

The important thing to remember is: "DONT TAKE MUCH FEEDBACK FROM PEOPLE ON SPACESHIP ONE, DONT ADD FEATURES PEOPLE WANT ON SPACESHIP ONE, JUST IMPLEMENT SPACE SHIP ONE AND LAUNCH IT."

Nothing more, nothing less, if you cant launch space ship one, dont even think of building a space ship.

Role Based Security

Just a quick summary from the last security post...

A resource is what you need to protect. It could be a document, html page, folder, part of the system, etc.
A subject is the user, him or her who acts on the resource.
An action is what the subject performs on a resource.
An Access List is a table describing what 'action'(s) can a subject perform on a resource.

Lets say we have an admin application, with four sections. User Management, Reporting, Backup & Restore. These can be 3 resources that we want to protect. Remember, a 'resource' is any thing you want to restrict access to.

The subjects are the 10 users. For simplicity, the actions can be Allow, Deny. (ofcourse, some actions could apply to certain resources only specially when you have finer permissions).

The access list could contain:
User A --> Allow --> User Management
User A --> Allow --> Backup & Restore
User A --> Allow --> Reporting
User C --> Allow --> Reporting
User C --> Allow --> Backup & Restore
User C --> Deny --> User Management
User D --> Allow --> Reporting
...
For 10 users, the table grows, for 100 users the Access List becomes so big... and so administratively consuming. The poor administrator will have to assign the action for every and each user on the system.

Here comes the concept of the "Role". A role is simple a middle entity between the subject's (ie. users) and the actions that would greatly simplify maintaing the access list. The access list in role-based security is called a Role Based Access Control List (abbr. RBACL).

We can now create three Roles; Reporter, Full User, and Guest. The Role Based Access List will now hold Role --> Action --> Resource instead of User --> Action --> Resource.
And another table will hold the User --> Role mapping.

See how simple the Access List becomes:
Full User --> Allow --> User Management
Full User --> Allow --> Reporting
Full User --> Allow --> Backup & Recovery
Reporter --> Allow --> Reporting
Reporter --> Deny --> User Management
Reported --> Deny --> Backup & Recovery
Guest --> Deny --> Backup & Recovery
Guest --> Deny --> Reporting
Guest --> Deny --> User Management

Thats it! Now all you have to do is to add a column in the users table
to specify a Role.

for example, User --> Roles will be:
User A --> Full User
User D --> Guest
User E --> Reporter
User F --> Guest

See how simple it becomes, every new user will only need to assign him or her one Role instead of re-defining all the actions he can perform.

Next post, I'll introduce you to extending your design, and some guidelines to stick to.

Guidelines on Designing a Better Security Model

I've collected some quick notes that will be helpful to guide you in designing a better security model. And to make it simpler, I'll explain it in a step by step example.

Assume you designed/implemented a multi-user application and would like to implement some sort of manageable security for the login accounts on the system. Read the following scenario:

1. Your system is comprised from a set of documents and pages.
2. You have multiple users on your system that can login.
3. The different users can perform different actions on the different documents and pages.

Till here we need to take a break and define some standard terminology used all over.

When it comes to security, the documents and pages are termed "resources", the different users are termed "subjects" and the different actions performed from those "subjects" on these "resources" are termed "actions".

4. I'd like now to collect a list of all the resources, actions and users on my application before I step into any design issues.

5. The resources I have are "Documents" and "Pages"

6. The actions I have are "Read", "Read/Write", "Upload", "Delete", "Edit" as an example. Note that certain "actions" can apply to certain "resources", while have no significance for other "resources", for eg. I can "Upload" a "Document", but I cant "Upload" a "Page". This is okay.

7. A list of users, this is usually stored somewhere in a database table or wherever, the important thing here is that those "subjects" are known.

After preparing a list of "resouces", "subjects" and "actions", I'll assume that no security is applied at all in the first place.

This means that any "subject" can perform any "action" on any "resource" whatsoever. In such a system, freedom fighters will enjoy it the most, while the rest will feel very insecure. Serving the rest will need some better security constraints on the different actions and resources in the system (sounds a bit political :\)

Here comes the concept of the "Access List".

The "Access List" simply defines which subjects can perform which actions on which resources?
Database wise, consider it a problem to figure out, simply it could be a table with a user id, resource id and action(s) for each row. Remember, its your design, I'm just giving guidelines here.

Ofcourse, when talking about the resource document or the resource page, we are indicating the resource type, thus its more of a resource type, and not a specific resource. Again, its your design, some might choose a very fine grained security model in which every single document has its own security, others will be comfortable with a certain action applied or denied for all documents.

An example "Access List" will simply say:

Subject "Basil" can "Delete" resource "Documents"
Subject "Basil" can "Read/Write" resource "Pages"
Subject "Whoever" can "Read Only" resource "Documents"
... (and so on)

The problem here is that if I have 100 users on my system, with 8 types of actions and three types of resources, then this "Access List" can grow indefinitely when describing the different permissions and will be hard to maintain by an administrator on the system.

Next post I'll show you how to tackle this problem.

ps. Comments, anybody, please, starting to feel lonely here.

In search for a good security model

I'm currently researching for some good way of implementing a security model for an administrative application. See, this is one of the areas where you really need a good design. And if not well thought of, then the code can easily get dirty and strangled in one month's time.

In small applications, we used to implement such in a very simple way by using database columns with true/false values or by using a access mask stored in a string.

However, such methodology proves very weak when its times to scale and fine tune your apps security demands. A security model is something that doesn't stay the same since it will be affected by any extra functionalities added to the application in future versions, therefore, as i already said, it is one of the areas that need deep thought and a good design.

If you're not acquainted to the terms: Policy, Subject, Resource, Role Based Access List, Authenticator, Authorizer... then HANDS OFF the security architecture document and delegate it to someone else. I know you have the brain power to do it, but without the correct knowledge, it wont be easy.