Sazbean

Software Development Management

Main navigation

You are here: Home / Archives for Tech

Tech

/

Does your business website need buzz?

What do RoR, APIs, Interactive Media, Mashups, and Product Communities all have in common? Well other than they all make up the bottom row of this year’s Buzzword Bingo card, all five are technologies that you aren’t using but should be.

Here’s a truism – Really good websites create buzz about your product or service. To create that excitement, you have to find a compelling feature, function or attribute that causes a positive reaction. When Macromedia’s Flash first came out, people were unimpressed. So it was a web animation tool for advertisers to make monkeys move really fast back and forth in a banner ad, big deal. It only became a big deal when really talented designers began making sites that generated attention. That attention separated the really good sites from the no talent hack imitators, solidifying their product and/or service in the minds of their viewers. The same can be said for each of the technologies in that list. Used properly and in moderation (as with most things in life) you can create some truly impressive results. Those results, in collaboration with smart marketing, will never fail to deliver the all important buzz.

In what looks to be a longish series of posts, I hope to convince you that one or more of the above can help your business website stand out.

  • Ruby on Rails (RoR) thinks it can, and does
  • Application Programming Interfaces (API’s) and why they aren’t just for geeks
  • Interactive Media talks back
  • Mashups = Your chocolate in my Peanut Butter
  • You can make a community about anything these days (Product Communities)

/

Web 2.0 Expo – Yahoo, Google change Web, kinda

The wave of tech information is starting to drag me under. So many great web solutions to problems that businesses have. As the last day of the conference, I’m starting to reach critical mass.

Yesterday I watched two internet titans decide to embrace open, user friendly web platforms for us mortals. This could be exciting for our business web developer community.

In their keynote, Yahoo! announced a Herculean task to re-wire every part of their platform to open up access to outside applications. Starting with the recent announcement of Search Monkey, Yahoo! is making bold moves to bring web developers into their house and offer them warm cookies and fresh milk. Their idea is to make their web properties sticky, keeping people on Yahoo’s network though stealth because the interconnections made though 3rd party web apps will drive them back in. Thats not as sneaky as it sounds, many many web application platforms work in the same way (Facebook is natorious for its locked-in platform for web applications). The appeal to web app developers like me is the potential for huge, fire hose style traffic curves coupled with some of Yahoo’s cooler properties like Flickr, Mail, Search and Finance. This won’t happen overnight, but if Yahoo can keep its focus though all the distractions, then they have a real chance at stealing the hearts and minds of some influential developers. Those developers may just change the web.

Later that same day, Google took the mic in the big hall to discuss Google Apps Engine. The company line here is that Google wants to “help the internet scale” by opening up access to its massively scaled data hosting platform. That’s a cute little sound bite, but I personally suspect it has more to do with the decision to monetize spare computing power, a decision Amazon had years ago Google’s offering goes a bit further than Amazon, building out every aspect of the stack to allow web sites and web apps to use Google to host up their online ideas. Once you get past the initial ‘I can have my little web site running on Google’ daydream fantasy, you see that there are some severe limitations as of today. Apps need to be written in Python, which may be a hurdle for some. They need to interact with Big Table, Google’s unique persistence layer. Big Table is not a relational database, so you really need to rethink how you interact with your data. Outbound web interactions are limited to 1MB transfers per connection and http calls only for outside web services. The service is free today for beta but expect that to change in the future. These limitations aside, you cannot deny that when Google sets a path for the future, it draws a considerable crowd of followers (some may say sheep) If Google can make this app engine viable, they may have once again changed the web as well.

Technorati Tags: , , ,

/

Web 2.0 Expo – Designing APIs (part deux) – Stamen

Stamen is the classic “position player” of the web app industry. They do really great work but are rarely singled out for it. Stamen’s job is to make other companies better. They’re mostly known for those really cool flash data mashups available at Digg Labs

Michal Migurski discussed some of the things they learned from Digg when designing the Labs API. Here are some highlights

  • Do dates as UNIX timestamp – There is a deep religious philosophy surrounding this kernel of wisdom, but at its center timestamps are just best practice. If you aren’t a unix acolyte, UNIX timestamps are seconds since Jan 1st 1970 (called epoch in some circles). This arbitrarily decided date format is the universal solvent that cleans up all date messes. Trust us, just use it.
  • Stick to core formats like XML & JSON. He also mentioned Serialized PHP and Javascript callbacks which are gaining in popularity
  • Unit tests are the single best way to coordinate design and development – One of the stories he told about working with the Digg community was that as designers they had a hard time syncing with the programmers at Digg. Unit Tests were the best way to make sure that what Stamen was designing would work on what Digg was writing in their API. If you don’t know what Unit Tests are, start with the wiki page on it
  • Expect your database to change – APIs that need to talk to the database (and really, what API doesn’t) will need to be updated as often as the database changes. DB changes can happen quickly at a client company like Digg who is thinking up new features in the wild. That can make for a tough, moving target to hit.
  • If you defer a feature at launch it’ll take forever to get to it – This is more of a truism than any great pearl of wisdom, at least to an experienced developer. Once code “ships” you rarely ever have the luxury to revisit missing pieces. The logic goes that if it wasn’t important enough to hold up the launch, then its likely not important enough to hold up the next launch either. At Digg the missing part is the Writable API I believe, though it was hard to hear near the end of the session

Technorati Tags: , , , , ,