June 7, 2011

LBHToolkit: Using the PHP5 vCard Generator

Kevin Hallmark @ 9:30 pm —

I was having a lot of trouble finding a suitable vCard generator for one of my personal projects last year, so I whipped up this little class to let you quickly generate a vCard in an object oriented way.

The example below can help you use the class. It’s actually really easy. Just instantiate the class, set properties to it with standard object notation, and then call “Generator::create()”. A list of all the fields can be found in LBHToolkit/vCard/Generator.php

LBHToolkit vCard Example

<?php
// Include the class
require("library/LBHToolkit/vCard/Generator.php");

$vcard = new LBHToolkit_vCard_Generator();

// Name, requires a little knowledge of vCard.
$vcard->formatted_name = "Kevin Hallmark";
$vard->name = 'Hallmark,Kevin';

//Company nae
$vcard->company = "Little Black Hat";

// Assign an address
$vcard->work_address = "123 Fake St";
$vcard->work_city = 'Orlando';
$vcard->work_state = 'FL';
$vcard->work_zip = "12345";

$vcard->work_phone = '555-555-5555';

$vcard->note = "Kevin is a nice guy.";

 

echo $vcard->create();

March 30, 2011

Software design is about iteration, not perfection

Kevin Hallmark @ 1:07 pm —

Over the years, I’ve learned some fundamental things about software development. Writing perfect code with a perfect design is a fools errand. Perfection used to paralyze me. These are some principles I use to help me make coding decisions.

1. Don’t rewrite your application. Ever.

This explains it better than I ever could.

2. DRY – Don’t repeat yourself

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

While it can apply to data sources as well, I am applying this to  code itself. Every single line of code you write is a potential bug. You should strive to write the least amount of code possible so you can depend on “known working” code.

If I need to get a record from the database, I can either write the select/execute call every single place I need it. This works for one off calls, but if I need to get that more than once or twice, a function is a better choice. I won’t have to worry about making a mistake each time I write the code. This is a contrived, but relevant, example.

3. YAGNI – You Ain’t Gonna Need It

“Always implement things when you actually need them, never when you just foresee that you need them.”

Simply put, if you don’t need it today or tomorrow (soon), don’t write for it. Maybe put a little underlying support code in, but don’t implement it until you have to. It takes time to add code, debug it and document it, time that might be better spent on more pressing features. If you add the feature too early, you need to support that bloat. If you need to refactor, you are refactoring more code. You have to make sure it doesn’t break.

After all that effort, you might even find that you don’t need the feature (ever), or you need something slightly different. The way you implemented it might be mutually exclusive with what you actually need. Adding it before it is needed might actually make you unable to implement a feature you need, or may lead to an incomplete implementation.

A good example is scaling. Why would you write software to scale your servers when you aren’t even using the power of one? Why write some awesome abstraction when it’s not going to be used by anything?

4. Three simple steps:

  1. Make it work
  2. Make it fast
  3. Make it pretty

I used to worry about the perfect application. I wanted everything to be the creme de la creme design. Unfortunately, I found that I never actually wrote the application. I got stuck in the design and never built out all the features I needed.

In a time crunch, you need the code to work. It doesn’t matter if it’s fast or pretty, if it doesn’t work it’s worthless. Usually, I can make it fast enough with iteration one, but as a system grows you’ll need to make things faster. As each pain point in speed becomes apparent, whack it out. Eventually, you’ll discover where you need to optimize. Finally, making it pretty by identifying code duplication and eliminating it where needed.

These principles have helped me write better software. I hope they help you too.

December 10, 2010

PHP is falling apart (or Why we need ‘finally’)

Kevin Hallmark @ 11:58 am —

PHP is crumbling.

PHP 6 was delayed for years and now sits abandoned as they restart the effort. In the meantime, a bunch of features are being backported to PHP5.x branches. Each new 5.x release has more features from what would have been PHP 6. PHP is stagnating.

The PHP core team has fallen apart. There is no leadership. There is no guidance. There is no logic. There is just a cobbled together release of miscellaneous features that are somebody’s baby.

For example, ‘goto’.

‘Goto’ should not be implemented in any modern language, period. It’s not needed. Yet, PHP chose to implement this in version 5.3! The reasons for adding this were dubious at best, showing a lack of language design skills. You can read all about my opinion on goto here: http://www.littleblackhat.com/blog/2009/11/php-5-3-and-goto/

I recently found this little gem on the php website: http://bugs.php.net/bug.php?id=32100 (thanks @lesmothian).

The best (and only) comment we get about why there is no ‘finally’ block is “We’ve had long discussions and came to the only conclusion that we don’t need that, for more search the mailing list archieves(sic).” Of course, that conversation can’t be found in the list archives. Does that matter? Of course not.

Finally is part of many modern programming languages: Java, Javascript, C#, Ruby, Python, Objective C, Perl, VB.net… the list goes on. Many of these languages and their designers abhor ‘goto’ and praise ‘finally’.

The use cases for finally assure proper memory management and resource deallocation. Without it, the chance for a mistake in control structure flow increases significantly. Additionally, unless I reraise the exception, it short circuits my app wide exception handling code. Reraising deletes runtime information about the source of the error.

Finally results in cleaner more reliable code. It should be implemented in PHP.

This essay only touches on the idiotic decisions of the PHP team. First ‘goto’, now ‘finally’. Suffice to say, I am getting less and less attached to PHP by the day. I hope that one day the php team gets some leadership again.

November 23, 2010

My first 4 months with Ruby

Kevin Hallmark @ 10:37 am —

I first began exploring Ruby on Rails in 2007 at the urging of Tim Rosenblatt. He and I went out to a meeting of the Orlando Java Users Group to see a presentation about this new framework called Rails in a language called Ruby. At the time, I was very interested. However, after I got my position at Bonnier, I wasn’t able to spend the time fully learning RoR. That changed when I switched jobs to Orange Lake.

I’ve been coding in Ruby using Rails for the past four months for Orange Lake Resorts. I wanted to share some of my experiences developing Ruby software in hopes of enlightening people who are unaware of some of the aspects of Ruby on Rails I like best.
» read more

August 16, 2010

Some lessons about Ruby Plugins

Kevin Hallmark @ 11:25 am —

So I have been having trouble getting plugins working with my Ruby app. I followed the directions here: http://peepcode.com/products/rails-2-plugin-patterns and it was working pretty well.

However, I came across two “gotcha’s” that gave me a little trouble.

  1. You have to include init.rb
    This fact was not readily apparent to me, I thought ruby would just take care of it. In my case, I had to add the init.rb into the app. This is probably obvious to you Ruby veterans, but not me as a n00b.
  2. You have to include your plugin’s file into init.rb
    Again, this seems like a no brainer. It’s not. You have to add each file you want your plugin to us to some file included by init.rb.

Obligatory plug for the peepcode above. If you’re just learning about plugins and Ruby, that peepcode is worth every penny

May 12, 2010

Google launched a new design, and I hate it

khallmark @ 10:15 am —

Update 2:

Apparently, you can get the old interface back with a little hack.

http://www.gtricks.com/google-tricks/how-to-get-old-google-interface-or-layout-back/

Update:

You can complain here: http://www.google.com/quality_form

For uniformity, let’s complain using the same options. Select the option from my screenshot below.

Dear Google,

The new left navigation is horrible. Don’t get me wrong, I like the functionality the left rail exposes. I like being able to easily filter my results by content type, date, etc… but I don’t want those features in a left rail.

Simply put, the left rail undermines what originally made Google great: simplicity. Google has always been visually simple, allowing me to easily scan search results. The new left rail is just a distraction. It takes some of the most valuable screen real estate and fills it with something that is not always needed.

The most important information on the page is my search results, not the sorting, filtering, or ordering therein. When I use Google, I want to access search results 100% of the time. The algorithm is so good, most of the time I don’t even need to refine my results because the answer is right there. I want to filter my results significantly less often.

The search filtering might be better suited to a right rail: there when I need it, ignorable when I don’t.

The new left rail also removes an important visual cue from the page: the browser left edge. My brain naturally tracks to the left edge of the browser window, much like reading a book. Now, instead of shiny clean search results, I get the left bar. While there is still a line for visually tracking the edge of search results, its soft coloring doesn’t give you a strong visual cue for the left edge of the content area; the contrast between the browser edge and the page is still a stronger cue. I end up scanning to the left edge of the browser, bringing my attention back to this evil left rail.

I understand that you want to advance your search engine, exposing more features to your customers. I’m all for it. However, those changes should not come at the expense of a tried and true product. You should let long-term customers retain their current configuration, if they desire. Give users the new look by default, but let account holders turn it off.

Remember “New Coke”? Instead of replacing their tried and true product, they could have released it alongside their flagship product. Don’t repeat the mistakes of your predecessors!

Please don’t make me hack it away.

Thanks,

Kevin

March 11, 2010

Recent Downtime

Kevin Hallmark @ 11:34 pm —

Sorry for the recent downtime! Should be back up and good to go. Cool

February 21, 2010

The IKEA Experience

khallmark @ 12:01 am —

I needed a dresser. The one I’ve had since I was a child is falling apart, and it’s just not big enough for both myself and my wife. It was time for a new one. After evaluating all the choice online, I ended up going with Ikea. Instead of ordering it online, I decided we’d trek out to the Ikea store instead. I wanted to have the Ikea Experience.

Suffice to say, it’s an interesting experience.
» read more

February 13, 2010

The new Little Black Hat

Kevin Hallmark @ 9:41 pm —

Welcome to the new Little Black Hat site. Over the next few months, I’m going to be adding some great new features to the site. First, I’m planning to add a project gallery to the site. This will let you see what I have been up to. I’ve also got a few projects to open source, so those should be coming soon as well. For visitors looking for information about my services, there will be something for you too. Overall, I expect things to happen here much more regularly. I love coding sites from scratch, but WordPress helps me in this time crunch world. No need to reinvent the wheel. :-)

January 28, 2010

Remote Debugging PHP on Mac OS X using xdebug and MacGDBp

khallmark @ 4:38 pm —

A debugger is one of the most powerful development tools available. However, with PHP, debugging a site can be tricky. A lot of times, the host you need to debug is remote. Xdebug, the PHP debugger, solves this problem with their remote debugging feature.

Unfortunately, getting remote debugging with xdebug setup on Mac OS X can be a little tricky. This tutorial will help you setup your environment for easy remote debugging using Xdebug and MacGDBp.


» read more