From the category archives:

Consulting

Social Media ennui

by Pearlbear on May 17, 2011

I have a confession to make. I have social media ennui. I’m tired of reading and hearing about about social media and nonprofits, and I’m annoyed that social media is taking up so much of the air space in the #nptech world.

As you know, I’m a bit of a technology curmudgeon, but I’m far from a luddite – I’m an early adopter, for the most part. I’m a fairly active user of Facebook, LinkedIn, Twitter, and some other social networking sites, and have been for years now. I certainly have followed and friended lots of organizations on these networks (particularly on Twitter, but also some more personally relevant to me on Facebook.) The apps I use most on my phone include the Facebook app for Android and Tweetdeck.

I spend some amount of my Drupal and WordPress development time, both for my clients and for myself, in setting up one or two-way integrations between websites and social media sites. I understand how the varied APIs work, and have to keep on top of whether I should be using a “like” or a “share” button for Facebook. I’ve been using social media to actively promote my new science fiction books.

In other words, I don’t avoid social media, I use it a lot, and I actively facilitate my clients use of social media integration with their web presence. (And I use hashtags in blog entries!)

But I’m still bored silly. Case in point: A new report out from IBM on Social CRM. It’s geared toward a for-profit audience, but it certainly has some reasonably useful lessons for nonprofits, and it has been a topic of conversation in the #nptech world today. But there isn’t anything in this report I haven’t read a dozen times already. It doesn’t help organizations bridge the huge data and workflow gap present between their traditional CRM/Donation management systems and their social media interactions. And if I hear the buzz phrase “game changer” one more time, I’m going to puke. It’s hype designed to sell things. And hype designed to sell things isn’t necessarily going to help make the world a better place.

No one should take this post personally. I’m very glad that most of my #socialmedia #nptech colleagues talk a lot about ROI of social media, and really try and figure out what works, and what doesn’t. But we’ve had, what 3 or 4 years solid of nonprofits using this stuff. Can it be demoted now?

So what do I want us to talk more about? How about lowering the costs of software by using open source and collaboratively developing software? How about data standards to help us share information more easily? How about finishing the work we did on getting the expensive CRM vendors to really open up their APIs so that organizations can better integrate their systems? Maybe talking how to deal with neglected nonprofit verticals like client management? Helping accidental techies get the training they need so that they can do more work in-house? Nonprofits who need tech help partnering with local organizations who provide training to the unemployed and ex-offender? The list goes on and on.

 

{ 4 comments }

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.

 

Tools I use: basic workflow

by Pearlbear on April 12, 2011

I was perusing Social Source Commons (something I don’t do nearly often enough,) and catching up on the SSC blog, and I thought it might be worth sharing with this audience what tools I use for basic consulting workflow. I’ll do another few posts for other areas, like development, system maintenance, personal web presence, and writing.

(If you want to look at my Social Source Commons toolbox, it’s here. It’s not so up to date, and it’s a list more of tools I have used, and some I still use.)

The center of my workflow, like for most consultants, is email. I’ve used a variety of email clients of one sort or another over time, and I have recently just decided to ditch them, and use gmail exclusively. I have definitely noticed that I’ve been migrating a lot of functionality of things that I do to web-based apps of one type or another, and this is one example of that. I use Canned Responses to provide HTML signatures when needed, and also forward all of my mail to gmail, then send out mail as other identities. (I’ve learned how to circumvent that annoying thing of “Sent on behalf of” in gmail – use the SMTP of the email alias you’re using.)

What’s also very close to the center is my project management tool, Redmine. (I’m actually now using a very recent fork of Redmine, called Chiliproject.)  I’ve waxed on about this tool ever since I’ve found it, and I would love to challenge a loyal Basecamp user to a point-by-point comparison of the two tools. I think it knocks Basecamp right out of the water. It’s core is a very powerful and flexible ticket tracker, but it includes all of the important project management features you want and need, milestones, time tracking, wikis, file repository, even discussion boards, and it connects with version control repositories. It works for multiple projects. And, it’s open source, and isn’t even that hard to get set up and running.

Another important tool, which I use in my personal life as well as consulting life, is Evernote. Evernote rocks my world. The web interface is great, as is the desktop application (which I use cross-platform – the Windows version works great with WINE). I also access Evernote on my Android phone. It’s a great tool. I use it for to do lists, stuff like blogging calendars, and also the Chrome Evernote extension allows for clipping of whole web pages, which I love (there is a Firefox extension as well.)

A tool I’ve recently come to adore is Passpack. It is an awesome web-based password management tool for teams. I love the collaboration features. For sharing files, as well as providing solid file backup, I use Dropbox (it even works on Linux!)

And, like all consultants, workflow involves documents and spreadsheets, and for that I mostly use LibreOffice, although sometimes using Google Docs makes sense for collaboration. I use Google Reader for RSS feeds, and TweetDeck, or, more recently, HootSuite for Twitter (I really like the tabbed interface of HootSuite. It makes looking at the variety of lists I have a lot easier.)

 

Web Application Frameworks

by Pearlbear on April 6, 2011

If I got a dollar for every time I heard something like: “we’re trying to choose between Ruby on Rails and Drupal for our new website” or “our developer convinced us to do our new website in Ruby on Rails and we can’t update it,” I wouldn’t be rich, but I’d have some money for a very nice meal at an expensive restaurant.

I know a lot of pretty serious geeks read this blog, but I also know some folks who aren’t do too, and I figured it was time to do a quick outline of web application frameworks, and how they differ from things like a CMS.

A web server, in the physical sense of the phrase, is a box sitting in a data center (or under someone’s desk) with a unique IP address, that answers queries from the internet and serves up data, depending on the request. In the software sense of the phrase, it is the actual piece of software (most often Apache, but sometimes something different.) That software runs in the background, and and listens to requests, then serves up the data.  That data is in some form of HTML, CSS and Javascript, because that is what browsers understand. However, how that HTML, CSS and JS is generated varies depending on the system underneath.

In the old days (when I was starting with web programming, back in the early-mid-90s) it was all HTML flat files (and not even much in the way of CSS or JS at the time.) And dynamic elements were less common (you remember those days.) Now, a minority of web servers actually serve HTML files – they serve HTML, CSS and Javascript dynamically generated by software, like, in the case of this page you are reading now, WordPress.

WordPress, Drupal, and Joomla are CMS systems that are written in PHP. PHP is one of many programming languages. Plone, for instance is written in Python. This isn’t really the place to describe what programming languages are, or how they work, but Wikipedia (as always) as a nice entry, worth a read. CMS systems are full-featured – they require no programming to install or configure or get going, or to create a usable interface. They may require some to customize in particular kinds of ways, but I’d say most nonprofit websites don’t need to do that. Most Drupal developers, for instance, don’t spend a whole lot of their time in code unless they work on contributed modules (or contribute patches and such to core.)

A web application framework is one that does require programming to provide the basics of a user interface. The cool thing about frameworks for developers is that it provides a great leg up, and a way to use the model-view-controller design pattern really easily – it’s a powerful way to do development. The advantage of a framework is that it allows you to do great custom apps a lot easier and quicker than before (many web 2.0 apps are written using these frameworks). The disadvantage to a framework is that it does take significant programming to get user interfaces (especially on the admin side) working well. So to use them to build a CMS (or a CRM, for that matter) is probably not a great idea, given the plethora of already-cooked options in the world. People who are working with frameworks are spending much of their time dealing with code.

Popular web application frameworks include Ruby on Rails (using the Ruby programming language,) CakePHP (using PHP), and django (using Python.) Ruby on Rails is arguably the most popular MVC web framework at the moment, but there are a lot of folks using the others. The PHP frameworks (which include Cake, as well as Symfony and Zend) are pretty popular because of the plethora of PHP programmers out there. All of these frameworks get more sophisticated every year, and they are interesting to watch.

Alternatives to MySQL

by Pearlbear on March 14, 2011

For those of us that depend on MySQL everyday, the buyout of Sun (which had bought MySQL) by Oracle did not bode well. A decidedly biased survey by the folks behind PostgreSQL suggests that many people worry about the health of MySQL in Oracle’s hands. I’ve mentioned this before, and I do think the conventional wisdom is that open source software (which includes OpenOffice.org, MySQL and Java) will not flourish at Oracle. It makes sense – Oracle has never had a culture of fostering open source software, and it seems unlikely to obtain one.

So what does someone do who builds their houses right on top of the LAMP stack (M standing for MySQL)?

For most folks, especially if they build on shared hosting infrastructures, this just isn’t an issue. They depend upon their hosting providers, for whom it may or may not be an issue – but they won’t have to think about it. For those folks in a position to choose which database software to use, (for example, you use VPS systems like Amazon, Slicehost, Linode, etc.,) then I think there are two pretty good options:

  • Go with MariaDB, which is basically a drop-in replacement for MySQL (and conveniently starts with an “M”.)
  • Switch to PostgreSQL.

MariaDB is a branch of MySQL that came about because of the uncertainty relating to Oracle’s ownership of MySQL. From the website:

In most respects MariaDB will work exactly as MySQL: all commands, interfaces, libraries and APIs that exist in MySQL also exist in MariaDB. There is no need to convert databases to switch to MariaDB. MariaDB is a true drop in replacement of MySQL! Additionally, MariaDB has a lot of nice new featuresthat you can take advantage of.

The problem is that the major Linux distributions (Ubuntu, Debian, RedHat) don’t yet have MariaDB in their repositories, so it will be a while before MariaDB is an easy apt-get or yum away from installation (there are some independent repositories and builds.)

PostgreSQL is a different beast entirely. It’s been an also-ran in the open source database race, and I was, for many years, quite faithful to it. It’s a very solid database, and it was ACID compliant before MySQL was. It’s major weakness (and why the LAMP stack is called that and not the LAPP stack) was that it was a fair bit slower than MySQL. But  that weakness has long been taken care of, but the damage was already done.

Many open source web database systems can use PostgreSQL instead of MySQL at this point. But PostgreSQL doesn’t have the same large user base, and doesn’t have many of the same web-based and desktop tools that MySQL does. There are differences in the SQL commands and such, and the command-line interface looks different. There is also a big difference in how Auto-numbered fields get handled, but that’s not really an issue that folks who don’t dive into deep database and code need to deal with.

So which to go with? It probably makes sense to wait a bit, first for MariaDB to make it into mainstream repositories, etc., and also to see what the fate of MySQL is. And checking out PostgreSQL is always a good option, it’s a very good database system, and the likely flight from MySQL might do the project some good.

{ 3 comments }

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 }

How to deal with technology change

by Pearlbear on February 18, 2011

I saw a call for a ColdFusion developer on an email list I’m on, and I couldn’t help but think about technology choice and change, particularly in the website world, and how nonprofits deal with technology change (or, don’t deal with it.) ColdFusion has been around for 15 years (more than a century in Internet time), and although it has improved and developed, technologically, it has been surpassed by its successors (including PHP, Java, Python, RubyonRails, and even .NET.) But this article isn’t about CF, it’s about technology change.

Technology is a rapidly moving beast. And the pressure to move forward, fast, is right there, always. It’s part of our culture, from the advertisements to the neatest, newest, coolest phones, to the new TV you should have. And then there are those of us in the Nonprofit technology community who are constantly on the bleeding edge of the next thing, whether it be hardware, software, or web services, are constantly talking about it, and how it’s going to make it easier/better/faster to change the world. Although I often get snarky about this, I am aware that I am guilty of this, too.

Most nonprofits are not run by geeks. Most nonprofit leaders think of technology as something in between a useful tool to be leveraged, and a necessary evil. They are resistant to rapid changes in their technology, as well they should be. And, they depend on geeks to help them get things done.

I have a story about nonprofits with a website they can’t leverage for their mission. Although complete fiction, this story will feel quite familiar. And I know I’ve been a guilty party in a real story at some point in my career.

A small nonprofit has a small staff who know a lot about their mission, but nothing about how to create a website. A friend of one of the board members is a web developer. They hire that web developer to put a new site together. The developer waxes poetic about the capabilities of this platform, called AmazingWebCreator. They imagine the developer knows what they are talking about. The developer builds the website, then goes away. The organization is happy for a while, they have a website with pages they can easily edit using a web form, which is more than they had before. Then in months, or years, they want to add some new pages, or a new section to their site, and a widget on the side. But they realize they don’t know how to do that. They call the developer, who is busy now using AmazingWebCreator on some huge project, or has moved on to SuperDuperWebCreator, and doesn’t have time for them. They have to bring in another developer, who knows AmazingWebCreator, which may cost them time and $.

Of course, the critical factor here is what is “AmazingWebCreator”? If it is a relatively new CMS (like WordPress, Drupal, Joomla and others) they may not need to bring in a new developer – they may just be able to get a book, or buy a video to teach them how to use the web interface to create new regions and widgets. If “AmazingWebCreator” is a platform like RubyonRails, Django,  .NET, Java, or ColdFusion, they are most likely going to have to hire someone to do that work for them, and depending on the platform, those developers may be either few and far between (ColdFusion) or in high demand, and therefore relatively expensive (RubyonRails, Java.) Worst, of course, is if AmazingWebCreator is a proprietary, custom CMS that the developer wrote themselves in 2002, and no longer supports.

How is an organization supposed to know how to make an informed choice about a website platform? I have a few suggestions:

1) Assumptions: First, assume the person/people who develop your site might not be around in a year or so. And assume there are things you can’t conceive of now that you’ll want to do in a year. Don’t assume the platform that your buddy chose for their organization’s site is the right one for you. Don’t assume that the most popular platform is necessarily the right one, either.

2) Feature set: Garden variety website, or  very specialized functionality? (By “garden variety” I don’t mean brochureware. I mean average, normal features of most nonprofit organizations. These include such things as donation buttons/pages, membership lists, blogs, etc.)

3) Platform choice: Look at a number of things – if it’s open source – how many developers are there? How many people use it? How easy is it to find developers? Will most new functionality be able to be added via web interface, or will it require back-end coding? Is it a custom CMS, written, maintained and supported by a single shop? (NEVER, EVER, EVER CHOOSE THESE. Here’s why. Luckily, they are an endangered species.) If it is proprietary, or software-as-a-service, are the extra features really worth the cost? Are there many consultants and developers who can assist you with this platform?

4) Lifecycle: Is it early in the life of the platform, at it’s peak, or late (or very, very late)? Bleeding edge might hurt, aged platform might crumble underneath the weight.

There are lots of folks (I do this on occasion on this blog, and Idealware is a great resource) that can provide you with information about specific platforms, and comparisons between them. Read, read, read, and ask many questions before you decide.

{ 2 comments }

Salesforce.com and Ruby on Rails

by Pearlbear on December 17, 2010

Programming languages and I have issues. By now, I’ve learned quite a number of them (I think 9 by last count), but for some reason, I seem to choose my work on them just at the top of the curve, or as they are going down. I have yet to manage to pick one early. I learned C at the height of its popularity, just as C++ was beginning to rise. I learned Fortran when it was almost dead, mostly for fun. I learned Pascal toward the tail end of its reign. In the late 90s, I chose to write a CMS in Perl instead of PHP. Dumb idea.

I’ve been moderately interested in Ruby and Rails for years now, although I haven’t yet spent very much time getting my hands really into coding Ruby. As pretty much all of you in the Salesforce.com world know, Salesforce.com agreed to buy Heroku for a pretty big chunk of change. I’d played with Heroku a little a while back, and I thought it rocked.

What is Heroku? Heroku is cloud Ruby on Rails. Build a Rails app, and deploy it on Heroku. It’s pretty sweet. So why would Salseforce.com buy it?

On one level, it makes über sense to me. As someone who has managed to learn some Apex, which is, frankly, somewhat of a monster of a programming language, it’s pretty clear that it’s not super easy to build complex apps using it. It’s like Java in heavy chains. A well-joined RoR & Salesforce.com platform, all in the cloud, would simply rock. (In case you are wondering, there already is a Ruby toolkit for the Salesforce API, although it looks like it only works on Rails 2.3, not 3.)

One another level, it’s fascinating. The culture of the Ruby and Rails world, the open source, community-driven, gift economy meritocracy, is very different than the Salesforce.com world – proprietary, business oriented, certifications-focused world. Of course, these are stereotypes – there are plenty of business-oriented Rails folks, and plenty of open-source oriented Salesforce folks, but the worlds really are culturally very different.

I’ll have a post soon where I talk in detail about why I think open source has both won and lost the open source vs. proprietary war, but this particular intercultural marriage will be interesting to watch. And the great thing is that our company has had such a marriage for a couple of years now, and it works.

Anyway, I’m dusting off my Ruby books, and diving in. Fun times!

I’ve been spending a fair bit of time in the last couple of years learning to code in a new way. It reminds me of a transition I made in coding from having written stand-alone applications for varied computers, to writing code for the web. When I was in college, grad school and early in my academic career (this dates me – from the early 80s to early 90s), I spent a lot of time writing stand-alone applications, mostly in Pascal and C. The shift from that kind of code, to writing for the web was a lesson in protocols, constraints, and different ways of troubleshooting.

The transition from writing free-form web applications, to writing modules for Drupal, or APEX customizations for Salesforce, is another set of lessons in protocols and constraints. First, it’s not enough to understand the syntax and form of the language (this is especially true for APEX – and beware the required test coverage!) One has to understand how the surrounding application works – what APIs or methods one can use, and how. And unlike long standing languages, there aren’t lots of detailed cookbooks and that sort of thing lying around – a lot of it is learning from other folks, as well as just learning by trial and error.

And, in my small forays into learning frameworks like CakePHP, Ruby On Rails, and others, it seems like these days, coding for the web is many lessons in constraints – which is a good thing, I think. Even though it feels like beating my head against a wall, it’s nice to know that I won’t “dump core” and break Salesforce (although I for sure have broken Drupal on occasion!)

{ 1 comment }

Lobo’s comment on my post yesterday prompted me to complete this blog entry that I’ve been ruminating on for a while. I wrote a blog entry a while back on the state of Drupal/Salesforce integration. What I didn’t say is that a number of shops that have done Drupal/SF integration for production sites chose not to use the contributed modules – they built (or are building) their own custom Salesforce/Drupal integration modules.

A few months ago, in preparation for a couple of projects, and a big push into this area for our company, I was faced with a strategic choice – go it alone, and build our own integration module for client projects,  or plunge into using and working with the contributed salesforce modules. Truth is, it wasn’t really a choice for me – I’ve got using and contributing back to open source projects in my DNA somehow. Although we certainly could have chosen, like others, to go our own way, we have committed ourselves to using, and contributing to the modules on drupal.org.

What we lose:

  • Complete control over development process and direction
  • Not having to fix other people’s bugs in order for stuff to work

What we gain:

  • Not having to reinvent a number of wheels
  • An easier upgrade path
  • Build on the work of others
  • Collaborate and learn

The work done so far on the modules is really solid – and it’s getting better. There is a great new maintainer, and increasing activity and contributions. There are also a number of other module integrations (like Ubercart, Webform, and FeedAPI) that are moving forward. Integrations with Views and Actions are also moving being considered (it’s instructive to look at the issues queue). This is stuff that would be hard to match, and makes building integrations for different kinds of sites easier.

So beyond just my own personal preference, I think that there is much benefit, both for our clients, and for us as a company, in hitching our wagon to theses contributed modules instead of going it alone.