Posts tagged as:

web

Tools I use: Personal Web Presence

by Pearlbear on May 6, 2011

I’ve had a web presence of some sort since way back when most personal URLs looked something like: http://somecollege.edu/~username. In 2002 or so, I ditched HTML for a series of CMS systems for my personal stuff. I started out using the CMS I wrote in Perl, called XINA. (Those were the days.)  Anyway, that was then, and this is now. Here’s what I use.

Software:

  • WordPress – you already know it and love it. I use it for this blog, only. I used to have two blogs on WP – this blog and my personal blog, but I moved my personal (and author blog) to Drupal, to integrate it with other stuff I had online.
  • Drupal – I use Drupal for my personal blog and also other purposes, like the website for my intentional community. My main personal site will be migrated to Drupal 7 soonish. My main sci-fi author site is already on Drupal.
  • Dokuwiki – my woefully neglected and out of date technology wiki is on Dokuwiki. Dokuwiki is a very cool tool. It’s a wiki, but everything is stored in files instead of a database. It makes it quicker, and also much more easily migratable. The annoying part is that it is one more wiki markup to learn (I wish SOMEONE would finally agree to make a wiki markup standard!!)
  • In the relatively rare case where I need to use HTML/CSS for web pages (there are a few legacy sites I maintain for friends) I use Bluefish (on Ubuntu.)

What I like most about WordPress is that I don’t really have to do any work to use it, or tweak it. I love how easy it is to use.

I love Drupal for its flexibility – and for my personal stuff, it’s really great to be able to mix and match stuff (like I actually have two different blogs on that site, but it’s really only one blog… Drupal is ace at that sort of thing.) I keep debating about whether or not to migrate this blog to Drupal. Stay tuned.

Hosting:

All of my personal stuff is on Dreamhost. I say this with some hesitation. I have hosted with Dreamhost since 2007. They are worker-owned, pretty green, and their newsletters are quite humorous. They give free accounts to nonprofits. Their service has improved over the years, but they ultimately aren’t all that reliable. They have downtimes (a really bad one recently,) Drupal often barfs on Dreamhost during admin tasks, and you can’t run Rails apps reliably at all. I’m going to spend the spring and summer migrating all of my domains (there are plenty!) to a VPS on Linode (this will be my chance to play with IPv6, too. I already use Linode as a development server.)

My Tools: Development

by Pearlbear on April 25, 2011

Since I am a web developer, the core of my development workflow is, for sure, a browser. But not just one browser, or any browser. Several. Chrome has become my everyday browser, although Firefox is making its way back into my heart, now that Firefox 4 is so lean and zippy. But I am very often in both. I use Opera on occasion, and, of course, I use IE only when I absolutely have to (and it generally means rebooting into Windows, which I do less and less these days.)

My other core tool is a console window. In Linux, I use the generic version. For Windows, I use SecureCRT, which is well worth the $ since putty is not up to the task (I know, it’s open source, which is great. But it just doesn’t cut it if you need to use it pretty much all day every day with multiple servers.) My text editor of choice is Emacs. Yes. Emacs.

For Windows, I love Notepad++, a sweet open source text editor.

I like Eclipse as an IDE, its awesome. I think it’s better than the proprietary Komodo, but that’s just me, I’m sure people beg to differ.

Other core tools are git for version control and github for code sharing. I haven’t found a GUI git client I like, so I just use the command line. IRC and Pastebin rock my world for getting help in troubleshooting problems, and IRC is great just for chilling with other developers.

 

Open Source vs. Proprietary: Web Server Software

by Pearlbear on April 25, 2011

By Web Server Software, I mean the software used to serve websites/pages. This includes databases, operating systems and other software that is involved in that process.

On the proprietary side, there are two options. Proprietary Unix, and Microsoft Windows, and associated Microsoft Software. The current version of MS Server in use is Server 2008. Microsoft has web server software called IIS, and it’s database server product is MS SQL server, which people use for far more than just serving web site data. The primary web development framework used in this environment is .NET.

Proprietary UNIX has dwindled greatly in popularity with the increasing popularity of Linux. On top of proprietary UNIX, people will generally run associated open source server software for web, database and development frameworks.

On the open source side, Linux is by far the most popular, with BSD in second place. Both Linux and BSD come in several flavors (or distributions.) Apache is by far the most popular web server software. MySQL and PostgreSQL are the open source database systems most in use for web servers, with PostgreSQL being a pretty distant second to MySQL. Other database systems (such as NoSQL variants) are increasing in popularity, but are pretty far down from MySQL as well.

Also, it is possible to run Apache, most varieties of open source databases and web frameworks on Windows, and that is not uncommon.

It’s hard to know what the market share of server operating systems are, because there are different ways to measure it. You can measure how many units are sold. By that measure, Windows is first at about 49-67%, Linux is second at 16-23%, and proprietary UNIX is third at 7-22%. That underestimates things like self-installed OS systems (standard with Linux), as well as VPS systems. If you measure by surveying publicly accessible websites, you get Linux first at 41%-74%, Windows second at 20-42% and proprietary UNIX third at 2-5%. This underestimates servers inside enterprises. (source: wikipedia)

From my perspective, the underestimation of self-installed and VPS systems by the first measure far outweighs the underestimation of enterprise servers, because plenty of organizations and enterprises also install Linux behind the firewall. It would make sense to me that the true number is much closer to the estimation by publicly accessible websites, rather than the unit sales estimation. So on the OS side, Linux does look like it wins.

Apache is far and away the most popular web server software. It is way ahead of IIS. The most recent data from Netcraft shows that Apache has 63% of web servers, compared to 19% for IIS. Also, Apache is showing a clear upward trend, and IIS a clear downward trend.

 

{ 1 comment }

The Good, the Bad and the Ugly RFPs

by Pearlbear on March 3, 2011

In my time working on web development for nonprofit organizations, I’ve seen more RFPs than I can even begin to count. I’ve even written a few. And, especially since I’ve primarily been someone in the role of having to respond to an RFP, I’ve gotten pretty good at spotting RFPs that I feel don’t serve either the organization, or the developers well. Here is, in my estimation, the good, bad, and ugly in the realm of RFPs.

I’ll start with the bad. A mistake I see very often in RFPs is an imbalance in what is articulated in the RFP, and the kind of work that is required to pull off what’s needed. Let me give an example: An RFP for a new website has 2 pages describing in detail needs provided by any modern CMS (web based WYSIWYG editing, drop down menus, new pages easily added, contact forms, etc.) and then a phrase dropped in like “integration with our CRM,” or “event management system,” without any detail as to what these things really mean (like, what is the CRM and what kind of integration is needed, etc.) This invites a world of hurt, as you can imagine. Kind of like the sound made when the Man from Mars starts eating guitars in the Blondie song.

Then there is the ugly. The mistake that organizations most often make is that they have a five- or six-figure imagination, and a four-figure budget.

So what’s the good? What makes a good RFP?

  • Do your homework: know what kinds of software options available to build the kind of system you want, and know what their capabilities are, and how much it generally costs to implement those basic capabilities. Learn about how hard customization of those platforms are (some are much easier than others.)
  • Understand that integration of most any two different systems is going to be four times as hard as you think, cost at least three times as much, and will do 1/2 of what you expect or want.
  • Hire a strategic consultant who really understands technology and the technological details of what you are looking for to help you figure out whether or not you can afford what you really want, and how best to articulate those needs in an RFP. Even an hour or two of their time will save you money and headaches. Someone who is a developer or who has been one in the past is a good bet.
  • Read this slide deck by Gunner of Aspiration!!

{ 2 comments }

Any consulting shop that does significant amounts of implementation and development (as we do) needs a project management and ticketing tool. Basecamp seems to be a standard that many people have reached for. We were using Intervals for a while, which is really a fabulous tool if you do a lot of hourly consulting. We also have been using Google spreadsheets for some elements of project management.

All tools have their strengths and weaknesses. And, in addition, the best tool does nothing without good human project management skills using it. As a shop that practices Agile development (we use an adaptation of scrum methodology that seems to work for a shop that does multiple projects with small teams,) finding a good tool that facilitates instead of hobbles Agile was critical for us.

We found, and have chosen to use Redmine for our project management/ticketing system. You can think of it as a multi-project version of Trac, which is a fabulous ticketing/wiki system that we were initially going to go with. Redmine has the elements of Trac that we liked, with the added ability to track multiple projects. Like Basecamp, Redmine has document storage and messaging systems. It doesn’t have milestones per se, but it does allow you to see tasks in calendar and Gantt views, which is very helpful. Unlike Basecamp, you can add custom fields to tickets, users and other features. Having spent many hours in Basecamp, I actually like Redmine much better. It does even do time tracking, which we won’t use, but is nice to know is there. And the wiki is nice. Basecamp’s Writeboards seem so much more like an add on than integrated.

It’s a Ruby on Rails application, and that was actually kind of fun to finally get to install and play with RoR a tiny bit. And it’s great that it’s free and open source. Although that wasn’t an absolute requirement for us, it is most definitely a plus, given so much of our work is implementing open source web tools. And it’s nice to save a few bucks per month.

{ 7 comments }

Avoiding Trainwrecks

by Pearlbear on June 3, 2009

I spent a big chunk of my day dealing with a project that is, in no uncertain terms, a trainwreck. The client has sunk a ton of money into a product which is in, its current (first phase supposedly finished) state, unusable (client and vendor shall remain unnamed.) My role in the project has been strategic and as a liason, not technical, which to some extent gives me a bit of a distanced view.

Web development trainwrecks are, sadly, far from isolated cases – they happen all the time, even when all of the parties have good intentions. And as someone who is building a business around doing this sort of work, it is of keen interest to me as to why some projects end up in the state that this project is in, and I want to make sure to avoid these kinds of situations. So how do we avoid trainwrecks? Some trainwrecks we can see coming miles away, but yet we are in complete denial about them. Some trainwrecks are like sudden derailments – it’s not at all clear where it comes from. But I think all trainwreck projects have the seed of the wreck somewhere in the history of the project.

The hallmarks of this particular trainwreck were so clear, that in retrospect, they scream out at me:

  • Lack of transparency about development process
  • Lack of transparency about cost implications of increased scope
  • Waterfall development process (well, the vendor said they practiced Agile, but in practice, it’s been waterfall)

As a practitioner of the Agile development process (we use a somewhat modified form of Scrum, in particular,) I’m beginning to really see the value of this kind of process. It makes visible all sorts of things that are often hidden. It seems like the Agile methodology helps in a number of ways:

  • Once educated, clients have a window into the development process. They know what small chunks of development are going to happen in a given time interval, and they know what they will get at the end of that time interval
  • Things are developed in priority order
  • Clients can critique things early
  • New functionality becomes a part of the “product backlog” and it is easier to have clarity about what is and is not within scope

Of course, it is theoretically possible to be completely transparent in a traditional waterfall methodology, and completely opaque using Agile, but I do think that the Agile methodology makes it way more difficult to be opaque. But it also takes some work and education of clients unfamiliar with the methodology (as well as making mistakes along the way on our part as developers.)

And I’ve been able to watch this process work well, not only with our own projects, but also with a project I was a strategic lead on. I was pretty skeptical a year or so ago, but now I’m sold. And since transparency has always been something of real importance to me, a development process that encourages transparency is a good thing.

Integration of CMS and CRM – Preamble

by Pearlbear on January 26, 2009

As I talked about in my last post, there are a variety of strategies one can use to move data between your CMS and your CRM. I’m going to choose a few examples to look at in some depth. Some of these are examples I’ve been working with clients on, or I’ve played with, some are just examples I know about, but are prominent, useful examples to talk about. I’ll talk a bit about mechanics, and talk about strengths and weaknesses, and under what situations you might want to look at it. I’ll cover:

  • CiviCRM/Drupal (with Joomla notes)
  • Plone/Salesforce.com
  • Using varied webforms (like DemocracyInAction, Blackbaud, Network for Good, etc.)
  • Drupal/Salesforce.com
  • Joomla/Salesforce.com

You’ll notice that only Drupal, Joomla and Plone are represented among CMS. That’s mostly because that’s what I know, and there is a critical enough mass for all three of them that some integration work has been done in a systemic way (the exception to this is Drupal/Salesforce – it’s only half-way systematic.)  I  haven’t included any all-in-one systems (like Kintera), mostly because I don’t think they are a good idea – you might get a halfway decent CRM, but you’ll for sure get a crappy CMS, and there is no good reason for that. Another note: I’ll talk about this in detail later, but Salesforce also includes the new Salesforce.com app, Common Ground, by Convio. From what I can tell (I’m learning a lot more fairly quickly) integrating Common Ground with a CMS should be pretty much the same process as integrating Salesforce.com.

First up, CiviCRM/Drupal. I’m choosing this first because it is a pretty interesting example, and also is an example of what I would call easy and tight integration.

{ 3 comments }