Archive for the 'Web Strategy' Category

26
Mar

Caxy Founder Michael LaVista to speak at PMG Innovation Summit

Caxy founder Michael LaVista will be speaking at the PMG Innovation Summit on April 21st, 2009.  Wondering what interactivism is? Are you an interactivist? There’s a site about it just for you. What will Michael be talking about, anyway? Gald you asked:

This is Michael LaVista, your Technology Squad Leader, and I have some good news: interactive marketing isn’t that complicated. It’s true! Web technology isn’t as wild as it once was—you could say that the universe has at last settled into a system of interconnected tools and parts.

By that, I mean that marketers shouldn’t let apprehension about technology prevent them from big plans. So much more is possible and affordable now than it ever has been, and it’s all just waiting to be tapped.

My section of the day will focus on teaching you how web tools like data base management and e-commerce can be integrated into your system in the most headache-free, cost-effective manners, and you’ll also learn the basics about website hosting.

pmg_interactivism1

29
Dec

Open Season for Open Source

A recession is no time to pay through the nose for software. So in these tough economic times, with proprietary software vendors increasing the licensing fees and locking in their customers, open source is king.

The idea behind open source is simple: find a relevant solution that already exists, use that as a starting point and customize from there. After all, most of what you’re looking for (e-commerce, CRM, content management, social networking, blogging) has already been done. Thousands. Of. Times.

But the strength of open source is also a challenge—in an infinite sea of alternatives, how do you find what you’re looking for?

That’s where an open source guru like Caxy comes in. We’ve vetted hundreds of options, learning firsthand which ones work and which don’t. So when a client comes to us with just about any request—the latest content management interface, for example, or a more flexible e-commerce system—we instantly pull up the top 1% of open source material and go from there.

Here’s an example. One of our University clients needed websites for each of its four locations, but only budgeted for two. So we found the open source software that best matched what they needed (with features like photo galleries, updatable calendar and contact forms) and developed one site for them. When they signed off on that, we took that same system—sans licensing fees—and duplicated it to create the other three sites. We could have done 30 more sites, with barely a change in the cost of implementing the software.

But back to the economy. The last time things took a downturn (2001-02), Linux established itself as a widely-accepted enterprise operating system, and vendors who got on board early reaped the benefits. This time around there’s a bigger focus on databases and higher-level software apps, but the principle is the same: don’t start from scratch. Depending on the scope of your project, a head start can mean real savings. Sure, saving $10k on a million dollar job isn’t a big deal, but saving $10k on a $50k is a real dent.

So if you’re on a project that’s not a brand new, earth-shattering, clouds-parting genesis of a concept, find yourself an open source specialist whose budget goes to customizing, not software. We happen to know a good place to start.

Caxy is a custom development shop specializing in open source technology, notably interactive PHP and Flash. Founded in 1999 on the mean streets of Chicago, our master coding ninjas are currently conquering CodeIgniter, Drupal, Wordpress, ExpressionEngine, SugarCRM, jQuery, prototype & more.

Rackspace is proud to name Caxy VIP Partner of the Month for December.

29
May

Managing Legacy Code While Remaining Somewhat Sane

I think every coder and every company that’s been around long enough arrives at a situation where for whatever reason, old code needs to be re-used. But not in a ‘Hey, I’ll grab this function from the site’ way but in a ‘Hey, we need to redo the frontend for this site without redesigning the code base’ way. But seemingly without fail, this code was created three versions of coding language ago using barely logical, much less programmatically sound, methods. As a coder, how do you avoid pulling out all your hair in an instance like this?

There could be a number of reasons for doing this. One, there may not be enough budget to redesign the code. The idea is that by not spending the time necessary to document and and then reprogram the code base, time is saved because the code, in theory, already works. Two, if no one really knows how the code works and a deadline is approaching, it may be hard to justify spending lead time on the process necessary to document code that seems to work. However, I might argue that when making a decision like this, one should consider the support time that might be required to ensure that everything is working properly once the site goes live, the time cost of combining two or more disparate types of code which may not want to ‘play nice’ with each other, and other similar factors.

Ultimately, whether or not to re-use or reappropriate legacy code depends on the budget, time constraints, and other business factors. If the person who designed the code is available, then this process is made easier; if not, the person who picks up the project has to make some tough decisions. If the decision is made to use legacy code, a developer’s best plan is to:

1) Be organized. Keep notes on everything and refer to those notes frequently. The code may be unorganized, but that doesn’t mean you have to be.

2) Have a plan and follow it throughout your development. If you have a certain way of formatting code, make sure you do it everywhere. Come up with way to address general problems you will encounter. If a function doesn’t work, are you going to rewrite it from scratch? Are you going to attempt to fix the code in-place? Whatever you decide, apply the same thing everywhere.

3) Be patient. Dealing with legacy code can be frustrating and slow. Take it one page / function at a time. Speed is always important, but never at the expense of good code.

4) Keep perspective. Yes, you will encounter crazy, illogical ways of doing things. You will not believe that someone could think this way. However, the point is not to let that distract you from the goal of creating good code. Create a ‘Wall of Fail’ like we have where we poke fun at these things.

So if you are presented with legacy code that needs to be reappropriated, try to follow these steps. If you do, hopefully at the end of the project you will be able to don a smoking jacket, and not a straitjacket.