Monday, August 27th, 2007
A question I've been asked many times over the years and Pete was again asked recently is why we don't place a "Site Designed by" tag in the footer of our sites. The simple answer is we're not looking for free advertising when we've been paid to provide a service. Look at any magazine ad, billboard or brochure and nine times out of ten you will not find credit to the designer, producer, printer, etc (one exception would be when creative and/or printing has been donated). A Web site should be no different.
Sure, the temptation is there, between the referring link and the advertising, but still somehow not worth it. At the end of the day, a happy client will provide better advertising than any link in the footer of a site. The biggest compliment we receive is when one client refers us to another business and the best part is it's a result of them wanting to advertise our services, rather than taking it upon ourselves to use their platform to advertise ourselves.
Posted in Who We Are | Add a Comment »
Monday, August 27th, 2007
From eWeek:
Monster.com Shuts Down Rogue Server
Last week, researchers at SecureWorks found a server containing data from 46,000 people that was stolen by hackers running ads on job hunting sites and injecting those ads with a Trojan.
When a user views or clicks on one of the malicious ads, their PC is infected and all the information that enters into their browser—such as financial information entered before it reaches SSL protected sites—is captured and sent off to servers used by the hackers, SecureWorks officials said.
Just some food for thought. Thanks RB for pointing this out...
Posted in Security | Add a Comment »
Thursday, August 23rd, 2007
I ran across an interesting article in last month's Wired titled Mr. Know-It-All: Is it OK to ban someone from posting comments on my blog?
From the article:
A personal blog is pretty much an autocracy, so you're technically free to ban whoever rubs you the wrong way. But going all Joe Stalin on your commenters — even the ones who annoy you with their nit-picking or wacko views — doesn't jibe with the Internet's spirit of openness. The best blogs are supposed to be a conversation. And anyway, if you're going to publish what you write, accept the fact that the responses are going to be neither 100 percent positive nor 100 percent civil. Journalists have known this since the invention of the letter to the editor.
The article goes onto say:
And if a racist, abusive, or otherwise abhorrent guest is putting a damper on your shindig, you're well within your rights to kick the hooligan to the curb.
A blog is supposedly a conversation, right? By censoring your comments its the equivalent of standing in a room, expecting everyone to hang on every word you say, only to plug your ears and scream "I'M NOT LISTENING!" when someone has a response. 
You open up a forum for people to give their opinion, and when they do, you slam the door in their face if you don't like what they have to say. People will ask themselves "why did my comment get censored?" when they really should be asking "who is this person to even censor my comment...?"
Don't get me wrong, I'm all for removing spam comments, and banning abusive, racist, repeat offenders. But I think a warning should be enacted first or some sort of "3 strikes and you're out" - not turning on "Moderation" and clicking "Reject" to the first person that rubs you the wrong way.
Over time, I would imagine that readership would decline. The amount of comments received in a month, or a week or a day takes a dive. Not because the amount of comments being rejected increases, but because people stop bothering attempting to leave comments. It's a one-sided conversation - if you can even call it that - where the only comments that get approved are in line with the author's views or idea of what a comment should be.
If you're willing to write pieces that draw and attract some sort of response, either positive or negative, but not willing to share those responses - then maybe blogging isn't for you.
Posted in Rants, Social Media | Add a Comment »
Thursday, August 16th, 2007
Since I've started web development, I've come across many ways to handle data access and business logic. Some of these have been good, many were bad, and some had potential but not for that particular project. I've decided I would bring up some of the better designs I've come across and discuss the benefits and problems I've experienced with each, and hopefully come up with a decent idea of when each should be used.
Ad Hoc
The basic premise of this is simple; put data access code and business logic anywhere that needs it. If you have a web page that allows the user to add, edit, and delete users, then put the code to access and handle adding, editing, and deleting users directly in the [server side] code of that page. The biggest benefit of this setup is flexibility. Since the code of every page has its own set of data handling procedures, you don't have to worry about how the changes to one part is going to affect the entire project. This also allows you to just get the data you need at the time, which can increase performance. However, with this, you'll often end up with the same code scattered across most of your files. This makes even minor changes a nightmare.
Benefits
flexibility, performance
Problems
code bloat, increased maintenance time/costs
When to Use
This should really only be used in a couple of situations, small read-only sites and working models. Small read-only sites are ones that don't really have any business logic to them. They basically spit out the same data no matter who the user is and what they do. Working models are the projects where you need to get a solution out there, but you don't yet know the problem set well enough to create a well designed system. So, to move forward, you create a working model of the final project until you have identified enough of the problem set to replace it with a viable solution. Choose wisely though, plans often change and you may end up having to maintain that working model longer than you planned.
Datasets And Business Objects
While these methods can become two very different things, I've grouped them together because they usually tend to end in the same result. The basic premise behind these is having one set of objects that handle accessing the data and another for managing that data after its been retrieved. This method can make front end coding very quick and easy as you can now call simple well defined functions like:
$customer = Customer::GetCustomer($id);
$orders = $customer->getOrders();
While this often works out very well for most of the front end development, making changes to handle any unforeseen business requirements (yes, these do change, often) can be like adding a bathroom to a finished house. Major changes like this will often need to start in the database and weave their way through the data and business layers. A lot of time for what the boss probably thinks is a minor change.
I've also run into an issue with performance using this method. Unless I've spent way too much time breaking down the business classes into the smallest data chunks I could think of, the program is almost always having to retrieve way more data than it actually needs. For instance, if there is a page that only needs to print out all the customer names who purchased Uncle John's Bathroom Reader, then either the "Person Name" would have to be handled as a separate business object from the rest of the customer class or the software is having to wastefully retrieve each customer's address, phone number, etc.
Benefits
easier front end development, lower coupling between database logic and application logic, easier minor business logic changes
Problems
wasted data transfer, major changes can be expensive, performance
When to Use
Most projects will work best with this design. Its compartmentalized logic means that most changes will be relatively simple. The compartmentalized logic also means the developers only need to know about one section of the project at a time, which works well for multi-developer projects where people may come and go. If performance is a major concern, consider spending a great deal of time in pre-development design.
Logic First
This is the latest one I've discovered, and so far, its gone well. The basic idea is to move all the business logic to the database itself. Not only will this lower the number of trips to the database to retrieve intermediate logic data, but it also makes sure that any other applications that use the same data have the same rules applied. Through the use of stored procedures, transactions, and views a single query can now verify the customer's credentials, input the order, and output the receipt info, all while being able to undo the entire thing in case of an error. With the business logic now contained within the database, data access can be setup in data managing classes, ad hoc, or both, leaving a lot of flexibility. This method is still relatively new to me, so I haven't found many problems yet other than the fact that from experience, most developers don't know enough about T-SQL to write all the needed business logic.
Benefits
flexible data transfer, easier front end development, localized business logic, performance
Problems
readability by most developers, debugging sql is much more difficult than other code, simple logic is more complex
When to Use
Since writing T-SQL can be much more difficult and wordy to write, I would leave this to medium to larger projects. With a lot web projects moving towards AJAX integration, I prefer this to the conventional dataset design, as this allows less calls back and forth between the code and database, giving a much more responsive user experience.
Posted in Programming | 4 Comments »
Monday, August 6th, 2007
It looks like September is a good month for blogs and developers in and around Orlando, Florida. Registration opened up today for BarCamp Orlando so Sean and I hopped on that (Pete and Mike are still clearing their calendars), but then it prompted me to also register for another "un-conference" coming up in September, BlogOrlando.
More on Barcamp
BarCampOrlando is a bi-yearly event to bring together people from different technical backgrounds to share and learn from each other. There will be people who know Java, .NET, Ruby, PHP, and other technologies coming together for a free all day event.
It's a day of developers sharing with other developers. There is no specific format for the day, but you are asked/expected to talk about something relevant and of interest to you. We'll definitely be contributing to the conversation and now starts the challenge of exactly what it is we'd like to talk about.
More on BlogOrlando
BlogOrlando is now in its second year and according to their site
We hope to bring together a good cross-section of folks to discuss blogging, podcasting, public relations, social media, citizen's journalism and other related topics
Josh has put together a nice list of session leaders which has us excited for a solid day of blogs.
So will we see you there? The price can't be beat on either event (they're free)!
Posted in Development, Social Media | Add a Comment »
Thursday, August 2nd, 2007
At lunch today with my wife she told me an interesting story about helping a potential client with online banking (she works for a bank). While in this meeting, my wife was explaining the benefits of online banking (the person was not using it) and when the client wanted to see what it was all about, she offered to help them sign up for online banking with their current bank. As my wife watched them walk through the setup process it came time to set up the username and password. As is normal with many sites now there were password requirements. At least six characters in length, one number and one special character. The person then says...
Special Character? What's that?
With nothing in the process to explain "special characters" it takes a fairly simple concept and creates a definite chance for frustration.
Posted in Usability | Add a Comment »
andrew:
hey mike -- thanks for the reply, let me clarify what i mean.... I know that PHP fu...
nick:
Hi Jeff, Thanks for the heads up on the link. It's all fixed now and you should...
Jeff:
I would love to try your plugin, but the download link appears to be dead again. Ca...
mike:
@Denise: 1. The image is selected randomly each time the code is run. So normally ...
andrew:
hey -- great plugin and would like to use on several different pages, not just the ...