Site updates: improved activity feeds

We’ve just improved the activity feeds on the site. Activity feeds are a great way for members to discover other members and new features on site and have become and important part of Sparkle*Shelf.

One of the great things about Drupal is how active the community is. We installed an earlier version of the Activity Module last summer and it was a nice addition to the site. It was fairly crude to begin with, but did the job of letting people know what was going on around the site.

Recently, we noticed that the developers on the project have been quite busy adding new features and fixing bugs, and we decided to upgrade to the latest (and still in development) version of the module. Some of the features we’re most pleased with are

• Privacy: users can now opt out of having their activity appearing in the activity feed
• One-click delete: admins and activity authors can now delete activity items (no more need to delete things in the database!)
• Themeable display: we’re able to add nice icons and change the look and feel of both activity blocks and the activity page (see http://sparkleshelf.com/activity)
• Much improved admin interface – it is now far easier to manage the messages that are displayed in the feed.

Here’s how it looks now:

Activity on Sparkle*Shelf

There are still some glitches, like the built in feature to avoid duplicate actions (if you update a post three times in a row, for instance), but overall we’re extremely happy and grateful for the work done by the Activity project team.

Weathering the economy-is-in-the-dumps storm

It was not too long ago when the pages of Techcrunch were full of articles about the latest Web 2.0 company to receive massive venture funding. These days there are more stories about lay-offs than product launches, ominous signs for those of us trying to get a business off the ground, and there are no signs that things are going to get dramatically better in the near future.

By some luck and some planning, we have not had to change our plans much to adjust to the new environment. Here are some tips we’d like to share:

1. Start small, stay lean. Sparkle*Shelf was built and launched by two principals and a handful of freelance writers. Since launch, we have added freelance writers and a part-time online editor. Marie remains the primary developer, designer and manager of the site, and the only full-time team member.

2. Fund yourself. Early on we thought the only way we could get the business going was if we received some form of external funding. A business adviser recommended that we do as much ourselves as possible (“consider your time the investment”), and we ended up being able to do nearly everything. This meant that at the time we couldn’t spend $50,000 on web servers, hire a marketing firm or throw extravagant launch parties. Now it means our monthly expenses are with our means and we don’t have to worry about nervous investors disappearing.

3. Don’t rent an office. These days, a good internet connection and laptop are all you need to do the day to day work involved in running a web company. There are many many better ways to spend that $500, $1000 or $3000 a month. Extra points for ditching your land-line.

4. Take advantage of cheap server technologies. Instead of buying servers, take advantage of services like Amazon’s web services, Virtual Private Servers like Slicehost, or Google’s App Engine. They are incredibly cheap to get started with and can grow with you.

5. Use Google Apps for your email. The free option is just fine unless you need to be sending/receiving huge numbers of emails. You can even wire it to your servers for system generated emails, meaning you don’t have to worry about managing an email server (and all of the headaches that go along with that).

6. Focus on improving the product and building up your core audience. If you have a lean, sustainable model, shelve those plans for being the next Google and take this time to really work on your product. When the economy picks back up, you will have a much better offering waiting for the world.

5 Things I Wish I Knew When Setting Up a Drupal Site

I’ve been working with Drupal every single day, all day long for the past one year.   I even have bizarre dreams about Drupal, it’s taken over my brain!  Over the past year I have learned a LOT about the ins and outs of creating a Drupal site, comparing and trying out modules, and theming every single module, block view, and panel that we’ve created.

Most of these things I learned after hours or days of trial and error. So I’d like to share 5 Things I Wish I knew from the start.  Hopefully this will help you save time if you are starting to learn Drupal.

At the end of this post I’ll also include a short list of other helpful tips. Luckily we’ve always been able to find answer to our Drupal problems somewhere on the internet (thanks to all you active Drupal developers & contributors posting your solutions!).  Note these all apply to version 5x.   Ok here goes, in no particular order.

1. THEMING:  MAKE A ZEN SUB-THEME
If you are creating your own design/theme, in my opinion there is only one way to go… ZEN.  Create a Zen Sub-theme. This will save you hours of time, and give you a very lightweight easy to manage theme.  Zen is a bare bones total CSS theme that is cross-browser & platform compatible. Of course you’ll want to check your theme across browsers when you are done, but Zen give you a fantastic starting point with a skeleton that is easy to work with.  Trust me, if you have the design ready you can get your basic theme up and running in hours… as opposed to days. Make a custom zen sub-theme.

2. THINK ABOUT YOUR CONTENT FRAMEWORK FROM THE START
We are using the Pathauto module to automatically create the path for our pages and content types.  Basically this module lets you say “for content type ABC” create a page url that reads “/ABC/PAGE-TITLE”. So all content of the same types are grouped into similar paths and directories. This is extremely helpful if you want to use PHP to show blocks on specific pages or paths.  We didn’t create these paths until after the first month, so still today we have hundreds of nodes with “old” paths that don’t follow this structure.  So my point? Before you start making pages and nodes, sketch out your content types, and a desired path for each one. Set it up BEFORE you make content. Pathauto changes are not backward-compatible.

UPDATE: per comment below looks like you can install additional modules to help this issue. haven’t tried it yet, but planning to soon!

3. SPECIFIC PAGES & NODES CAN BE EASILY CUSTOMIZED
This one is good to know from the start, and easy to implement. Basically you can create a customized different page template or node template based on the URL path. This is so helpful and valuable for so many reasons.  It might not be the most efficient method but for us it’s very effective and an easy fix for a lot of things.  Bookmark and read this page on drupal.org for detailed info.

4. PLAN FOR SEO FROM THE START
There are a few simple things you can do to really help your SEO. We’ve had really good results with Google using the following modules in conjunction with a handful of other little things.  We’ll do a more in-depth post on Drupal SEO soon, but for now here are some helpful modules for SEO:

• Meta Tags module: Automatically creates meta tags based your node content
• Pathauto module:  This makes the URL the same as your page title, excellent for SEO
• Page Title module: This make the page title in your browser the same as your actual page title (like the title tag in html)

5.  DO YOUR HOMEWORK ON YOUR HOST
After thorough research on Drupal hosting options, we came to the conclusion that VPS is the best option, and so far it’s been working extremely well for us!  Read Andy’s post on selecting a host for a deeper look at hosting options.

If you must use shared hosting for your Drupal site, there are two things you’ll want to be sure they allow:

1. Allow you to change your PHP Memory Limit settings. Some hosts do not let you control this, or they have a limit.  Drupal really needs a minimum of 32mb, depending on which modules you are running.
2. Be sure you have direct access to your databases (via phpMyAdmin or similar tool). This is important for many reasons, and will save you a lot of hassle.

MORE HELPFUL TIPS…

As mentioned in the beginning, I’d also like to point out some fixes for annoying issues I’ve run into working with our Drupal site.

• PROFILE AVATARS & BROWSER CACHE: We’ve run into an annoying issue where a user uploads a new profile photo, but the old one shows up due to browser caching. There is a handy little module called Unique Avatar which addresses this by creating a unique filename, very helpful.
• DRUPAL MODULES & THEME DIRECTORY: For newbies, a very basic but very important item to know, is to install ALL non-core modules and theme in /sites/all/themes or /sites/all/modules NOT in the root directory.
• CONTENT TYPE SETTINGS:  I’ve noticed that if you change your content type settings after nodes have been created, the settings are NOT retroactive. I repeat NOT RETROACTIVE!  This seems affect the “Comments” and “Published” settings most. And I have to say I don’t think it’s all the time, seems sporadic, but more often than not I get stuck troubleshooting this, when it’s a simple answer.  So for example let’s say you have a content type that had comments disabled.  You created some nodes, then decide later on to enable comments.  All those existing nodes will NOT have their comment settings changed, you have to manually change this.  This could be a mess if you have hundreds of nodes, and then decide to enable comments.  Again this supports content planning, be sure you have thought through how your want your content types to work from the start.  And my disclaimer again, it seems to be sporadic, but plan for worst case so you don’t have a mess on your hands.
• SETTING UP PROFILE PAGES:  If you are creating a community site with user profiles, you need to use the Advanced Profile module. We are using it with nodeprofile and it has worked really well. BE SURE TO READ ALL THE DOCUMENTATION and setup info.
• GET RID OF THE EDIT TAB ON PROFILE PAGES:  This was annoying me for the longest time. If you are using Advanced Profile you’ll notice an extra “Edit” tab on the profile page that lists content types to add.  Obviously this is not desired for a member profile page.  We got rid of this by going to “/admin/settings/advanced-profile” and clicking “Reset to defaults”.  Scary to click this button, but it totally worked, that stupid extra EDIT tab was gone!
• PERFORMANCE SETTINGS: Be sure you take advantage of the core Performance settings. This helps our site performance drastically.  When we’re not working on the site we always have “Caching mode” set to “normal”, and “Aggregate CSS files” enabled.
  NOTE:  Remember that these are ON, so if you are uploading new css styles and they aren’t showing up, it’s because performance is on. I can’t tell you how many times I have forgotten this fact and driven myself insane!
• NEWSLETTER SUBSCRIBE:  There are many options out there, but we ended up using a combination of a 3rd party service – Campaign Monitor – with the Campaign Monitor Drupal module.  It adds a little checkbox on forms & registration page so users can opt-in to your newsletter. I highly recommend this solution it’s clean and Campaign Monitor provides excellent reporting and email marketing management.

Ok that’s it for now.  Stay tuned for more helpful tips on Drupal sites and theming.  There will likely be a part 2 coming soon.  Happy theming!

Good reading about the down-turn

Love him or hate him, Jason Calacanis has some great observations about running a startup. Recently he sent out an email about what to do in this time of economic craziness. Join his email list here: https://my.binhost.com/lists/listinfo/jason. You can read an overview of it here. There’s also a link to the full text.

There was also an interesting panel that included Jason – see below for a recording of it, or read the summary here.

The long and short of it, this is actually an opportunity for companies that are lean and mean, and don’t have to worry about investors looking for returns or threatening to pull our their funding. Here in Seattle, the impact is startling – almost every startup I know of has already had layoffs or will have them soon and those looking for funding are having a very hard time.

Keeping tabs on the dream: website monitoring

After we launched the initial version of Sparkle*Shelf, I became fairly obsessed with knowing what was going on with the site. We wanted to know the typical stuff about which pages were most popular, where people were entering and exiting the site, etc. On a more practical level, we also needed to know when things went wrong.

Fairly early on, we received a lot of traffic due to a writeup, and after one spike the site went down. We were working on the site, and noticed the problem within a minute, and after a simple restart of the web server, it was back up and running. But what if it had happened in the middle of the night? The thought of a multi-hour outage was not pleasant.

A former colleague pointed me to alertra.com. Alertra has a bunch of different services that all basically check to make sure your site is running by sending a request to your web server from various locations around the world. We chose an option that checked the site every five minutes, and would send a notification by phone, email and text message if there was a problem. A pretty good deal at $11.95 a month.

That was a great start, but after a couple of calls in the middle of the night that required a web server restart, I started wondering if there was a way I could automate the process (while doing some real head scratching about how to correct the underlying problem). After some digging, I found a nice little program called monit. Unlike Alertra, you install monit on your server. Because of this, it can monitor many more aspects of your server’s health, and (more importantly) it can automatically take action if it finds something wrong.

An added bonus of monit is that its web interface works great on your favorite web enabled handheld device (such as an iPhone). There were a couple of cases where I needed to restart the servers and was far away from the nearest computer, and was able to thanks to monit.

Even with monit and Alertra in place, a particular problem emerged that caused the site to be unavailable. To help make Drupal perform better, we had installed a PHP accelerator called eAccelerator. A bug in eAccelerator on occassion causes Drupal to serve up a blank page (in Drupal circles, this is the infamous “white screen of death”) – which neither monit nor Alertra recognize as a problem. Luckily, the Drupal community had a solution that was easy enough to deploy and addressed the problem well enough for the time being.

I now feel very confident that I will know within a minute if Sparkle*Shelf is down. Further, until a new wrinkle emerges, the site should be able to fix itself within 2-3 minutes. This is in many way patchwork covering up underlying problems that will need to be addressed eventually, but when your running a company with two people, sometimes patchwork fits just fine.

Looking for a home and a host

After deciding to build the site ourselves, we had to decide where the site would live. While we had both worked with web servers before, neither of us had been responsible for setting up a site’s infrastructure.

As I mentioned in the last post, we have built Sparkle*Shelf on Drupal, which is a fairly resource intensive web application–especially once you start adding all of the fun features that we liked so much. Those $4.95 a month shared host plans are great for your baby’s blog, but don’t do well with database intensive sites with lots of visitors.

On the other end of the spectrum, a dedicated server that we maintained seemed (a) very expensive and (b) a lot of work. Do I really want to be driving to some datacenter to replace a failed harddrive at 3 AM?

As I dug into the options more, a happy medium emerged: VPS, or Virtual Private Servers. A VPS looks and acts like a complete server, but is actually only a “virtual” server that uses a portion of the underlying systems resources. This has a few advantages:

1. It’s much cheaper than a dedicated server
2. It’s easy to setup, rebuild and backup
3. There’s no need to worry about the physical security or the reliability of the hardware

We chose Slicehost. There are a lot of good VPS options out there, I’m sure, but we couldn’t be happier. The tools for setting up your VPS, or “slice” are amazing, making installation of well known operating systems a matter of a few clicks and a five minute wait. Rebuilding from backups is equally easy.

We setup two servers to start: the first was our test/development server and the second was our production server. This allowed us to take a copy of the most recent live version of the site, put it on the test server and do development and experimentation there.

Having a whole server to ourselves, and no CPanel (as those of you familiar with shared hosting options know) means one of us had to learn the ins and outs of installing and running Apache (web server), MySQL (database), PHP and the other required tools. Since Marie was busy designing and coding the site, that person would be me.

The basics of this are not hard at all. Basically, you need to get comfortable working within those archaic looking terminal screens and typing in obscure commands. Luckily, Slicehost had a ton of helpful tutorials like this that walked me through the process. I thought I was pretty cool for getting everything up an running within a day, and the site (or early version of it we had ready) was in fact functioning. However, I know I’m still a complete novice at making the site run well. Tuning Apache and MySQL is a black art as far as I’m concerned, and I’m thankful every day when I wake up and the site is still running. I have learned a lot in this whole process.

Taking the next step to a multi-server configuration that is more reliable, where there are multiple web servers and a dedicated database server (or two) is something that scares the bejesus out of me. I won’t mind too much, though, because it will mean we have lots more traffic than we do today. And if that’s true, it might be time to hire someone who knows what he or she is doing.

The point I really want to make is that more and more tools are services are available for building “real” sites. They are cheap to get started with (we’re talking $20/month) and heavy-duty enough to grow with you if your business takes off. The world of “Cloud Computing” is really taking off, and beyond Slicehost, there is an amazing assortment of services from the likes of Amazon, Google and others for building scalable Web applications. What are you waiting for?

Shoe Strings

I have been meaning to blog about some of the behind the scenes aspects of Sparkle*Shelf since it launched in May, but am just now getting around to it. While the delay is in part due to a lack of time, I honestly was also a bit hesitant to reveal how much of a shoe string we’ve been running things on. Now, in these days of economic crises and startup layoffs, I figure some people might be interested our version of bootstrapping.

The Beginning: Out-sourcing vs. In-sourcing
Last December my wife Marie and I were brainstorming about possible side projects, and she came up with the idea of a beauty and fashion related social network. It seemed like it had real potential, and we spent the next couple of months refining the concept. We put together the type of documentation we were used to producing for the web proejects we had done for both startups and larger companies, namely a detailed functional spec and a clickable html prototype. By the end, we had more or less mapped out much of what you see today on sparkleshelf.com.

Next came the question of how we were going to approach making this vision a reality. Based on our experience working for both startups and well established companies, we figured the next step was to find some form of investors. Poking around the web, I found plenty of articles that talked about bootstrapping your way through the first year. Some of these articles even included spreadsheets with all of the expenses of running a business, and concluded for $250,000 you could just about squeak by. Yikes.

Not knowing where to start, we approached some successful entrepreneurs we knew. One friend of Marie’s gave us some great advice that was both brutal and inspiring. He said, (1) no one will invest in you given your levels of experience, regardless of how good an idea it is, and (2) your best shot at success you have is to get something out there in whatever way you can and see what people think. Our investor would be our sweat, so to speak.

So we embarked on a journey to get the site built ourselves. Neither of us is a hardcore developer, so we assumed our only shot (unless we could find a developer partner) would be to have it built by offshore developers for cheap. In this time we found out about the crazy worlds of scriptlance, elance, odesk and all the others. We put together a detailed RFP bundle that included the spec and prototype and placed our requests for bid. (you can actuall see the project on scriptlance still, despite our request to have it removed: http://www.scriptlance.com/projects/1199004600.shtml)

The responses were a bit shocking – some claimed to be able to do the whole thing in a couple of weeks for $400, and some said it could be done for no less than $75,000. It did not seem highly likely that any of them would deliver exactly what we were looking for, however, so we scaled back the $10,000 of saving we were going to put into the project and selected one of the companies that had bid $1,200. We figured the worst that could happen was that ww would be delivered a highly flawed version of the site and we would have to find someone locally to help us bang it into shape.

At this time, we had also made an important decision about the platform we would build on. We had selected Drupal, though neither of us had much experience with it. To get used to working with it we decided to try to throw together a scaled-down version of the site ourselves. It would give us some exposure to the oddities of the system and experience building out the server infrastructure we had planned for it (more on this later).

This turned out to be one of the best decisions we could have made, but it was hard going at first. Drupal is a strange beast that requires you to adopt its own quirky logic. Marie has been a Web designer for over ten years. She is a rock-star when it comes to XHTML and CSS, and can work her way around PHP code, but was still banging her head against the Drupal wall for a week or two until things started clicking. It took me longer. Eventually things started to come together and we began completing features that remarkably like those we had planned back in December.

Meanwhile, the Indian vendor, which had started out OK, started to flounder. They got about 1/2 through the site and suddely stopped communicating. After a couple of weeks, they delivered the code they had done, charged us for half of the project and disappeared.

We were thrilled. We were starting to like our simplified version of the site better than theirs, any way, and were all to happy to learn what we could from the work they had done and move on. For $600 we had learned that maybe just maybe we could rely on ourselves much more than we had anticipated.

–Andy