Beyond Coding

It’s gone! :)

Ladies and gentlemen, please allow me to present this new website: beyondcoding.com, with my fellow developer friend Scott Gruer! Together we are working hard towards a better blog as well as some interesting projects.

Scott and I have been working together for more than 2 years now. We share very similar goals and mindsets, we believe our collaboration will not only do ourselves a favour, but ultimately also to produce even more values to the web design and development community.

If you are a regular visitor or subscriber of thislab.com, you’d notice that I haven’t been posting much lately. Rest assured, this new website will pack a lot more content, from coding to beyond coding. :)

If you haven’t already noticed, all the page links as well as RSS feeds are now redirected to this new domain name, but just in case, please update your bookmark!

Oh by the way, a brand new identity and theme are in the works and they will be published in the coming few weeks.

“Our interests are in the future, because we’re going to spend the rest of our lives there.”

Related posts

• No related posts.

When you’re starting your own web development business or just starting out freelancing, there’s a tendency to take on any and every job that comes your way. After all, there’s not much to show in your personal portfolio so you could do with beefing that up even if it means slaving away for not much $$.

As soon as you’ve got your portfolio to a reasonable size and you have built up your experience and professionalism, do yourself a favour and charge clients the appropriate rate for the professional web development services you provide.

There’s no quicker way to get bitter about your work than to give someone a cheap quote and then realise the work you took on is going to take 3 times as long as you expected, while you should also find out about the monthly payslips on your job to get the required documents for this.

Some reasons why you might have given a cheap quote include:

• Underestimating how long it will take you to do something. More often than not a task, no matter how simple, will take you longer than you think. The good old rule of “work out how many hours it will take, then double that” rings true. Personally I quote on a project basis so if I quote 8 hours and the job takes me longer, I wear the extra hours and write that time off as a learning experience.
• Sympathy. When a client mentions they don’t have a large budget, or they’re a small business, or a new business, or a family business or whatever, it’s only natural to want to give them the best rate possible. That works ok when the job goes smoothly, but if the sympathy plea of a client causes you to under-quote and things go south, you won’t be a happy camper and everyone will suffer.
• You don’t feel experienced enough. Sure, you may only be 20 and still at uni, but that’s no reason to under-quote if you’re delivering a professional service. At the end of the day, if you provide the same service or end product (web site) as an agency, why should you be working at half the rate?
• Competing with your client’s nephew. Everybody knows someone who thinks they can create a site just like Facebook or eBay for $200, whether it be their nephew or their aunts-husbands-neighbours-grandparents-dog. Then there’s always the people who can’t understand why they have to pay so much for a site that uses an Open Source (in their mind, “free”) CMS, despite the fact you had to write a custom module to fit their needs or spent 10 hours designing and xHTMLing their template.

By all means, give clients the best deal you can – just make sure you don’t sell yourself short, learn more about handling a business by reading this post about the hiring process in startups. If you sell yourself short all you’ll do is make life harder for yourself and you’ll devalue the entire web development market.

Related posts

• (1)

People might think that IE6 is really slowing down the advancement of web design and development, which is true. What some people don’t realise is that IE7 is just about as evil as IE6, as web is evolving rapidly and making a new website is not difficult at all.

Today we have noticed a nasty bug that only happens in IE7. We built a website and it is being framesetted by other websites. In IE7, sessions and cookies do not work at all for this website (which has a different domain to the parent website).

After lots of research and debugging, we’ve finally identified this bug: IE7 incorrectly sets privacy settings for the website that is contained with a frameset and is not part of the main (parent) website. All sessions and cookies are therefore blocked.

Fortunately, there is a fix:

header('P3P: CP="ALL ADM DEV PSAi COM OUR OTRo STP IND ONL"');

The above line will ‘magically’ fix this IE7 bug.

I wish the IE family was bought out by other vendors, or alternatively, died peacefully.

On a side note, let’s wait and see what Google has to offer with Google Chrome.

Related posts

• (1)
• (0)
• (19)

First of all, not all parts of the Zend Framework enforce the class naming convention, at least not upon calling ‘em. For example, view helpers are called directly by the ‘chopped’ class name:

// actual class name:
class Path_To_The_CustomViewHelper {}

// calling it in the view:
$this->CustomViewhelper();

Also, models are both named, and called by their class names without any paths (but yes we have to include them in the include paths).

You would think that in most cases calling the classes by their full names (with paths) should work, right?

Wrong.

Related posts

• (52)
• (52)
• (1)
• (7)
• (3)

Two weeks ago I started working with Zend Framework at work. I chose to use Zend Framework for one primary reason: Zend. Even though I have plenty of experience with CodeIgniter and Kohana, I simply could not take any risks using them for a rather large project at a company I had just joined.

My experience so far is mixed. Probably because I am so used to the way CodeIgniter and Kohana do things, Zend Framework just appears utterly complicated and difficult to work with (at the beginning).

Related posts

• (52)
• (52)
• (1)
• (7)
• (3)

Yeah I am a lame PHP guy who hasn’t gotten too deeply into Ruby yet. ;)

In PHP I often use variable methods, for example:

$foo = new Foo();

$funcname = 'dynamic_method';
$foo->$funcname();
// Same as calling $foo->dynamic_method();

$varname = 'dynamic_accessor';
$foo->$varname = 'some value';
// Same as calling $foo->dynamic_accessor = 'some value';

Now, because Ruby does not prefix $ in front of variables, it is impossible to use variable methods the way we do in PHP.

I am sure for Ruby gurus it’s pretty obvious but for me, I just spent more than 30 minutes searching for an alternative other than evil eval, and I finally found one.

We use the PHP call_user_func and call_user_func_array equivalent in Ruby: send or __send__.

Luckily accessors in Ruby are methods, so we are able to use the send method for both methods and accessors.

For example we can set a variable accessor like this:

foo = Foo.new

funcname = 'dynamic_method'
foo.send "#{funcname}"
# same as calling foo.dynamic_method

varname = 'dynamic_accessor'
foo.send "#{varname}=", 'some value'
# same as calling foo.dynamic_accessor = 'some value'

I wish in future versions of Ruby, we can somehow assign accessor values the way we do in PHP. :)

Related posts

• No related posts.