KutterGroup LLC Blog

Coming Full Circle

jim — Thu, 02 Sep 2010 01:26:16 +0000

I was forwarded something interesting from a client. It was a service that we had discussed rolling out on our own. Interestingly, it also was developed and marketed by a firm not unlike my own - a small website and custom programming shop. I went to their site, and noticed they were touting their own CMS platform.

"Ah," I thought, "there but for the grace of god go I."

There was a point in time where I felt I needed to have my own CMS platform to be taken seriously. In fact, we founded KutterGroup with a custom platform we developed for The Paramount Center for the Arts, and ever since, we developed a custom CMS for each client from the ground up.

As anyone who as ever done so can tell you, it gets old fast. For every site there's about 90% of a CMS that's redundant. Users need to login and perform certain tasks depending on who they are, pages have titles, urls, one or more paragraphs of text, etc... Developing an engine to store, manage and display that over and over again isn't terribly difficult, but is quite redundant. Furthermore, each client had their own project, which, let's be honest, after launch, wasn't heavily modified unless the need arose. Over time, we came to the realization that we should have our own platform where this work can be centralized, and if each client was using the same platform, fixes and enhancements built for one could be enjoyed by the rest.

So we went about doing just that. It was pretty neat if I do say so myself. It was written in C# to run on .NET (more on that later), everything could be managed via a web interface, new content types could be defined, fields could be added to those types, and instances of those types could be created. It was centrally managed - it ran on our hosting environment and pushed out "compiled" sites via FTP (this was because we wanted to be able to push content to any website). It also had a mechanism for managing multiple sites under the same client. Perhaps the coolest feature of all, it was scriptable using IronPython - so collections of content instances could be searched, sorted and displayed via simple scripts.

And, it was a colossal waste of time and effort.

For everything it did, it didn't do dynamic things all that well - forms and dynamic pages needed to be handled outside the system. It was difficult to learn (it made perfect sense to me, but I wrote it), and it turns out, it was rather fragile.

The idea was to have it run on a shared host with a company then called Mosso (now RackspaceCloud). However, due to increased focus on security, Mosso changed their .NET hosting environment to "Medium Trust." Embedding IronPython meant I needed more than that. As a result my fabulous CMS could no longer run on our shared hosting environment. As we found out, many .NET hosts were Medium Trust or lower. We didn't want to invest in the infrastructure to run this on servers we maintained (a dedicated or even virtual windows server was cost prohibitive, especially since we only had a handful of sites that used it).

Long story short, we had something that we spent 6 months developing, that we couldn't use.

Around this time, we started to get a lot of questions from new and existing clients about the viability of Drupal as a platform. Up to that point, my attitude on Open Source CMS projects was that they gave you several kitchen sinks worth of stuff, and that really all you needed was a simple spigot, so you spent most of your time ripping out pieces you didn't need, and in the process, likely broke most of the product.

We had experience with Mambo (now Joomla) and WordPress, and we weren't terribly impressed. Simply, we felt it was easier to build required functionality from the ground up, than tear down unnecessary functionality from the top. However, despite all this, we decided to give Drupal a proper go.

Drupal, as a website platform, is, simply put - perfect. Well, not perfect, but it comes pretty close. It makes sense, that since 90% of the sites we developed had similar requirements, then in turn, 90% of the world's sites would have similar requirements. Drupal has been around for a while, and is quite popular, so there are a lot of other developers who have built functionality to cover that 90% quite well. Drupal is a big box of legos. Want to add a signup form for MailChimp? Here's a brick. Want to make a page that will show only certain types with certain criteria? Here's a different brick. Instead of trying to put everything possible into the CMS core itself, Drupal is modular, allowing us to find just about anything to meet a requirement. However, the real beauty is that if we need to do something that we can't find a brick for, we can use the incredibly powerful hook system to either make something that exists do what we want, or flat out make our own brick.

The module system is well thought out, and is a joy to develop for. We only need to spend our time working on integrating modules and building any remaining custom functionality, so our clients get much more bang for their buck. We're also able to turn sites around much faster, increasing our bang for the buck. We see it as a win-win.

It's fitting then, that we've come full circle.

Our very first project we did as KutterGroup was the custom CMS for The Paramount Center for the Arts, and it set the stage for subsequent sites. Now, with quite a few Drupal sites under our belt, we have the pleasure of announcing a revamped website for the Paramount, built, of course, in Drupal.

KutterGroup.com 2.0 (beta)

jim — Fri, 30 Jul 2010 01:14:03 +0000

We have just launched a new version of our website.

Code named "Honey Badger," we have revamped just about every section of the site. We've merged the Sandbox and Blog, we've introduced a search capability. We are using Google Fonts with reckless abandon, and, perhaps most importantly, we've rewritten large sections of site copy.

Apparently, the old copy was written by a bureaucrat (grade 26). We apologize, the bureaucrat has sent back to the DMV, and we've found actual humans to describe us and what we do.

Please feel free to poke around, and of course, let us know what you think!

Iconic Mistake

aisha — Wed, 23 Jun 2010 11:29:02 +0000

We've all seen those cute, artistic renderings of the social media icons. They are everywhere - some for free and some you have to pay for, and unfortunately the social media outlets don't like them - according to their brand and marketing guidelines.

After recently working on a site for a client, we worked diligently to find icons, albeit icons that are Facebook, Twitter and LinkedIn approved, and in that quick bit of research and reading the associated guidelines a bit more in detail, such as the Facebook "f" logo, you discover that they are all pretty strict on how to use their logos on your site. This may seem harmless, but for an organization, eroding their brand and image is not something they condone, nor should they.

So what's the verdict? If you value your company's brand and image, be sure to show the same respect and care when using social media icons on your site as well. Take a few extra minutes and see how they want you to use their icons and make sure the icons are from the source, not from the icon designer looking for a link back to their work.

Wiki's For Everyone!

aisha — Sun, 06 Jun 2010 14:04:15 +0000

We recently deployed an internal Wiki for organizing our business operations and project details using the MoinMoin Wiki Engine. This decision is one I had only wished we made when we first started KutterGroup. Outside of its extreme simplicity in use (and fast learning curve, even for those technically challenged), the ability to organize internal thoughts and new business ideas has been fantastic.

No more disparate Word, Pages, Google docs or the worst, emails, for internal documentation - everything can easily go into the Wiki. Then being able to recall information is a breeze via the search as well as easily customizable navigation. In addition, the fact that this is a web-based solution, when traveling we can document ideas or meeting notes in our iPad and we can revisit them when we get back to the offices.

For an organization of any size, an internal Wiki is highly recommended and something that I now want to deploy for managing my household!

Flirtations with IDEs editors and why I'm boring after all...

jim — Tue, 12 Jan 2010 15:12:51 +0000

I've been using Coda since 1.0 and having worked as a web developer for the past decade, I really like how polished it all feels. It just feels like an IDE "light" which I really love. It doesn't take 40 minutes to load, I don't have to download a dozen plug-ins to make it useful, and it's simple to setup and operate.

However after experimenting with some other web-oriented editors/IDEs out there, I found some things I'd like the fine folks at Panic to implement. Sort the code navigator

For the love of god, please sort the code navigator. While I can appreciate mirroring the order as it appears in the file, when working with other people's code, this is unbearable. I know what I'm looking for, please make it easier to find it!

Flag Files as Unpublishable

This comes up quite often - you have a settings.php or config.php or whatever, and it has a DB connection string, or an email address for form submissions or a file path or whatever. Almost always, you have different settings for a local development server vs the settings on the destination server. If you do a lot of work locally, and you (foolishly) publish the entire folder, you've just blown away your app's production settings...

To get around this (I know, I know - version control) it would be nice to flag a file as unpublishable. If the flag is set, skip it when uploading the whole folder. Either that or a regex so we can skip version control folders or other project metadata too. Simple, effective.

Speaking of publishing...

Multiple Publish Destinations

This was from Aptana and an incredibly powerful and useful feature. Imagine the following scenario, you work with a staging site, and a live site. It's nice to be able to publish a file or set of files to a selectable location. Currently, we use Coda to work on the local server and the staging server, then Transmit to publish to the live site. The downside to this approach becomes apparent in the following scenario:

You make a change locally, then publish the change to the staging site for review. You make a few more changes. Eventually, you've done a bit of work, and now you need to publish to the live site. Good luck remembering everything you changed. Ideally, Coda could track changes and where a given local file was sent, so when you look at another publish destination, you can see that it needs to be updated there too.

What's that? I should be using version control like subversion to manage this instead? Oh yeah, that bring me to my next point.

Deeper Subversion Integration

If you do use subversion to track changes, and you work with systems that use plugins (drupal, wordpress, etc..) it would be nice to let Coda see that I'm using subversion for a particular directory (not necessarily the whole project). As it stands, I currently don't use Coda's built-in subversion support (which is very nice btw), and instead use either the command line, or a third party app such as Versions. This goes against the "one window development" mantra that Coda was created to enable.

So that's really it, a handful of things I'd like to see from Coda that I liked from my flirtations with other coding tools. I liked Aptana, but in the end, it didn't feel right. I've tried eclipse at various times in the past, and never quite got into it. Everything felt like it was bolted on, and the workspace approach was counter intuitive. I'd have one workspace, and various projects. I didn't see the benefit of having a locally hosted PHP project asking me if I wanted to start the current script as a Python app. Finally somebody told me to try one workspace per client, and configure the launch and debug settings specific to the client's project (or suite of projects). Still, the whole thing felt wonky to me.

Same with TextMate. It's a great editor. Good implementation, tons of features, but it felt like I was using Xemacs again. It's 2010, we're on Macs. Make it sexy. Do a cutesy animation or something. I'll tell you the one thing that drove me nuts about TextMate - block editing. Coda makes it easy and intuitive to enter block edit mode. Once you're in it, it's apparent where the block is, and it's forgiving. You can navigate about within the block. TextMate doesn't do that. It's an arcane key combination to enter block mode, then once you're in it, there's no feedback. You just type and that's it. Granted that's one example, but the whole thing felt that way. The Xemacs reference stands - it could probably be configured to wash my car for me, but you're going to have to pour through the manuals for a week to figure out how to do it. Same with TextMate. It's crazy powerful, but sometimes I just want to edit a file.

That's why I'm sticking with Coda for now. Thanks guys. Keep up the good work.

What are your thoughts? Think I'm dead wrong? Think I should be using VIM and be happy it's not ed? Tell me!

UPDATE

After speaking with some friends, I just wanted to add something that I forgot to mention.

These were just my experiences in trying new things. As a professional in this space, my job demands I look at new things to stay relevant (and that's half the fun too). The primary thing to remember though is something I learned a long time ago: "It's not the tools, it's the talent." If you have enough of the latter, you can make do with the most basic of the former.

Ruby script to compute and post summaries to Basecamp

jim — Sat, 09 Jan 2010 14:46:23 +0000

It's no secret that we use basecamp a lot and love it.

About a year ago, some of our clients wanted to be able to log in somewhere and see a status of how many hours they had left on their retainer, or how much their bill would be at the end of the month. So I came up with a quick and dirty script that does the following:

logs into basecamp
iterates through each client
looks for a configuration message in a pre-defined category (stored as YAML)
does it's calculations based on the configuration
posts the results back to basecamp under another pre-defined category

Here's a sample configuration message for a basic maintenance client:

Hours: 2
Run Dates: 10, 20

This tells the script that the client purchased 2 hours of support each month, and that the script should post status updates on the 10th and on the 20th of each month.

Here's a more complex example:

Limit: 1000
Developer A: 75
Developer B: 45
Run Dates: 10, 20

This tells the script that the client has a dollar limit of $1,000 a month, and the two developers assigned to it bill out at $75 and $45 per hour. It's also set to post results on the 10th and 20th of each month.

Again, not rocket science, but allowed us to provide clients with an automated status update so they could keep a handle on costs.

I'm posting it here to share as something neat, but please bear in mind that it comes with no warranty of any kind. It worked well enough for us, ymmv.

Let us know what you think!

Attachment	Size
main.rb	3.16 KB

International URLs

aisha — Tue, 03 Nov 2009 12:19:08 +0000

On November 16th, ICANN (Internet Corporation for Assigned Names and Numbers) will begin accepting applications for internationalized domain names. This marks one of the biggest changes to the internet as we know it and comes with great opportunities as well as potential new threats.

For opportunities, just think about the doorway being opened by allowing domain names to be registered in it’s native language. The current requirement that domain names be registered using Latin characters poses a gap in reaching those individuals that only know their native language. Opportunities for registering and reaching out to entire communities who only know their native language is tremendous and can now be done. Ever wish you had registered key domain names to sell your product and or service to a highly specific Hasidic, Asian or Islamic community? Now is your chance. Just keep in mind that a vast majority of existing internetians (i.e those who peruse the internet) operating systems will not support these characters, however, that may just prove to be an advantage for those with an entrepreneurial spirit.

For threats, one only has to look in their spam folder to know that phishing scams will likely increase by a significant magnitude. Say you have a bank account with a large, Asian bank – it’s a fair bet that someone would look to get similar domains of that bank in its native script to use for nefarious deeds and it would become increasingly difficult for the average non-native person to identify that it is a scam.

So, while we may be near running out of web addresses (although this will be fixed before it becomes a real problem), be sure to examine if your business model warrants a discussion on registering and targeting a niche market and doing so in its native tongue.

Makes you wonder, what would the domain name of the man formerly known as Prince look like with this newfound freedom of expression?

White House Website Built in Drupal

jim — Thu, 29 Oct 2009 11:06:20 +0000

When you’ve been building web systems for as long as we have, it is nice to see and know when you’ve made the right decision.

We recently relaunched our website using Drupal (in addition to launching several other sites in Drupal as well) and that decision came as a result of research into this 8 years young, open source platform. Drupal has allowed for us to harness the efforts of the open source development community and quickly build complex websites in a very short amount of time, while preserving, enhancing and expanding the list of features and functionality contained within. Turns out, this month the White House also relaunched its website using guess what? Drupal. This past weekend MSNBC reported the launch of the new whitehouse.gov website using Drupal as the platform of choice.

It has been said that using open source has inherent risks associated since no one person or organization owns the code, however, when properly implemented, even a website that requires the highest level of security has managed to use open source to its full potential. Plus, the simple fact that the code is available to the public means that there are just as many folks, if not more, working to secure it as those who are looking to crack it. We have known for quite some time that open-source has plenty of advantages (having built and maintained systems in Zope, dabbled with Mambo – which is now known as Joomla, built a plethora of custom systems using the ubiquitous LAMP stack to even embedding Python into our own custom CMS platform) and it is refreshing to see that our decisions match those of other respected thought leaders and is making headway into mainstream web development.

Free Website Builder, Accounting Software & More

aisha — Tue, 27 Oct 2009 13:00:00 +0000

So I heard on the radio the other day, an advertisement for a "Free Website Builder, Accounting Software & More for small businesses!" All for a low price of $5 per month, you even get to choose from over 2,000 website design templates. Sounds great and, in my opinion, a little too good to be true.

I decided to take a look at the site to see what it was all about and despite my skepticism, it was more than I thought it would be. They offer various up-sale items such as a shopping cart, accepting credit cards online, payroll and of course, an accounting software service, all at an additional cost. Not bad for the budget minded business. The offer is quite compelling and I am sure that we will miss out on some potential new business, BUT…

One thing we’ve come to appreciate over the years is how valuable your (and our) time really is. We have been providing website maintenance as a service for some time now because, while every website we build for a client is done so in a manner that allows for them to easily maintain it on their own, most of them frankly don’t have the time to do so. Take a few minutes to assess how much your time is worth – see if it really makes sense for you to spend it on your site, or would it be better spent doing what you do best.

SEO and Web Maintenance

jim — Sat, 17 Oct 2009 13:55:32 +0000

We get asked about SEO (search engine optimization) a lot, and our response is almost always "If you do your site right, you won't have to worry about it." Since that response is pretty much the antithesis of what every SEO vendor on the planet says, we get a lot of skeptical looks in response.

We may even lose business over it.

But, sometimes, we're actually right.

According to Google's own blog:

While it's true that linking is a significant factor in Google's ranking algorithms, it's just one of many. I know we say it a lot, but having something that people want to look at or use—unique, engaging content, or useful tools and services—is also a huge factor. Other factors can include how a site is structured, whether the words of a user's query appear in the title, how close the words are on the page, and so on. The point is, if you happen to see some low quality sites linking to you, it's important to keep in mind that linking is just one aspect among many of how Google judges your site. If you have a well-structured and regularly maintained site with original, high-quality content, those are the sorts of things that users will see and appreciate.

Loosely translated, if you build the site properly, maintain it (update the content) regularly, and have unique stuff to talk about, Google will find YOU, usually without a whole lot of effort.

Keep that in mind next time you talk to a SEO "expert."