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!)
Tagged as:
apex,
code,
drupal,
salesforce
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.
Tagged as:
CMS,
drupal,
opensource,
salesforce
As most of you know, I’m a very long time veteran of web application building. I’ve been involved in web application development basically since they started – when a cgi-bin folder with some perl scripts to process simple forms was the norm. Until just a few years ago, there was very little sophistication about the user experience in web applications – what mattered most was functionality. and to make sure there weren’t too many errors when users did unexpected things.
I’ve considered myself pretty successful at both helping clients navigate the tough waters of web development projects, as well as accomplishing web projects for them. Recently, though, I had two projects that ended up, for wont of a better term, clusterfracks. And I’ve spent a lot of time lately trying to figure out what lessons I need to learn from those projects – what can I take away from them so I don’t make the same mistakes again. They were both custom web applications, both projects that I was a strategic, rather than engineering, partner on. Both projects were attempting to accomplish pretty sophisticated database functionality (such as case management). Functionality I knew how to get done, because I’d accomplished it before – so I had a very good feeling for what kind of code it would take to accomplish the task (and, ergo cost and time.) But what I hadn’t taken into consideration is how slick, AJAXy, easy to navigate, and easy to understand user interfaces people have gotten used to in the last few years. And, frankly, have come to expect. And how unwilling people are to sacrifice that for raw functionality.
I did a lot of self-examination: where did I go wrong? What could I have done differently? Was it the client? The developers? Me? I realized a fairly simple truth. It was all three. In reality, I should have looked at the budgets of those projects, and looked at the clients straight in the eye and said, “double, or triple the budget at least, or don’t do the project.” And walked away if they insisted. The vendors should have bid triple what they did, and had more user interface expertise on board. The clients should not have expected to get slick 2009 functionality for a mid 5-figure budget.
The easier a user interface is to use, the more money and time it took to create. It’s that simple. What most nonprofit decision makers don’t completely realize is that the interfaces they work in every day when they shop, or tweet and facebook, or use other online tools, are the product of millions and millions of dollars of venture capital, or, in some cases, hundreds of thousands of person hours of work in open source projects (or some combination of both.) Ground-up custom applications, even when written in great frameworks like Ruby on Rails or CakePHP, which save all sorts of development time, just are not going to have the user experience people are getting more and more used to without very serious investment of time and expertise. In addition, most small development shops don’t have the user interface expertise on hand to accomplish that task, even with a hefty budget.
So the lessons:
1) If you are embarking on a custom development project (such as a case management, for example) exhaust every possible option of using and customizing/modifying existing tools (Salesforce, CiviCRM, SugarCRM, other open source tools) before you begin to consider custom development from scratch.
2) If you have a budget of less than $100,000, go back, and stay, at step 1. I know this is high, but I’m serious. Obviously, simpler projects won’t need a budget of this sort. But simpler projects generally don’t need custom databases.
3) If you’ve got the cash to spend, and have exhausted all other options, when choosing a vendor, make sure the vendor you choose has UE expertise on hand. Look at other custom database work they’ve done. Dig in. Make sure it has the ease of user experience that you are expecting.
4) Remember the mantra: the easier it is to use, the more expensive it is to build.
Tagged as:
Consulting,
Development,
opensource,
user experience
I’ve been a fan of user stories for several years now. User stories are a way to describe a set of functionalities of an application in a way that is focused on results – it’s easy to connect to mission. An example from an events management application:
The organization should be able to create several different kinds of events, and determine for each kind of event which detailed information will be taken. Those events can be displayed in a list or calendar format. Users can register for events, and pay using a credit card.
There are many ways to describe this story – it certainly can be a lot more detailed, but what’s clear is the result of this functionality. And, of course, user stories are great for agile development process.
Developers would determine how much this function would cost (based on our knowledge of the tools we use, and the time it takes using those tools to generate this sort of functionality), and clients would know exactly what they are getting from a functionality standpoint. When this functionality is complete, everyone is happy. The developers get reasonable compensation for a job well done, and the clients get the mission-based functionality they asked for.
And it would avoid a situation which I have become recently far too familiar with – vendors who underbid projects, and then feel the need to resort not to the intent of the contract, but the letter. Everyone knows it is utterly impossible to specify every detail in the letter of a contract – sometimes letter of the contract, unfortunately, details things like fields and queries, not functionality. The letter of a contract will be, almost by definition unless based on functionality, an inadequate representation of the final result needed. In this case, no one really wins. The clients either don’t get the functionality they expected, or they pay extra for it, and they leave the project with a bad taste in their mouth about the vendors, which will only come around to hurt the vendors later.
Tagged as:
Consulting,
Development,
nptech
I don’t have kids, but I do know how young kids ask questions. They are innocent, and free of assumptions, and keep asking “why?” In the end, the poor adults either get tired of the questions, or realize that there are assumptions they’ve been making for all this time that might actually be worth questioning.
Human processes mold around software. We see this all the time. A CRM gives you these 5 canned reports, and you get used to making do with what’s there. A legacy client database requires a certain order of data entry, and your intake forms have been produced to copy that order. Your email software has particular limitations, and you find behavioral workarounds.
What’s also true in the realm of customized software, is that software is molded around people. You put in your RFP that a package spit out data in X,Y and Z ways because your ED is used to data in that form (maybe because a package they had at their previous organization had those canned reports.) You have a requirement that data be entered into the system in one particular way, probably because that’s the way you’ve always done it. Sometimes, you feel the need to replicate a process that the person 3 administrative assistants ago put in place that was molded around their particular limitations, just because that’s what you know.
When you are undergoing the process of creating or implementing a new system of any sort, whether it be a CMS for a website, a CRM, some internal system, it is a really good exercise to be like a 3 year-old, and keep asking “why?” Why do we need this feature? Why will this report be important? Why should the software work this way? Once you peel the layers down to the bottom, you’ll either have “we don’t know” or “because we believe it will help us meet our mission in this specific way.” Then you know what you should take, and what you can leave behind.
Tagged as:
nptech,
Software
I’m learning Drupal bit by bit – one of the first tasks was to learn how to make a new theme. It’s one of those things which is actually fairly straightforward-seeming … until you hit a snag. And then it’s opaque.
One thing I learned is that it is incredibly sensitive to typos. One space accidentally inserted between the “<?” and the “php” led to a completely blank page. Ah well. I’m certainly learning what mistakes can lead to what kinds of issues, which is good. Eventually that becomes second nature.
But, in any event, by the end of an hour or so of hacking, I’d turned a template that I found online at Open Web Design into a Drupal template. I felt accomplished! I’m going to do a few more, and see how sophisticated with it I can get.
One thing I ran into (and haven’t been able to solve yet) is that it’s not easy to have navigation that requires more than just the standard <ul><li> tags. Adding <span> tags, for instance (which makes possible some more interesting looking navigation buttons) seems, at least at first, far from trivial.
I’m making a list of little(ish) projects that I want to do – sort of like problems I think I want to know how to solve.
- Drupal and google docs single sign on. There is already a SSO Module for Drupal 5.x, and someone submitted a patch for it, but it’s still up for review. I’d also have to cough up $50/year to get a google account that has the SSO API, but it might be worth it.
- Drupal sidebar connecting with the NPR API – perhaps to provide a targeted news stream?
- Doing a google map mashup of data in Drupal
- Working with getting flickr photostreams to show in Drupal
I’m still looking for a good project to try out in Cake. Unfortunately, the module Drake, which is meant to be a bridge allowing you to run Cake applications within Drupal, seems moribund. There is only a development snapshot for the 5.x branch, and no one seems to be picking it up for 6.x. Sigh. There is, for sure, another whole blog entry about Drupal modules.
In my new explorations of PHP web application development, it seemed a good idea to get a look at both CakePHP and Symfony. Both of them seem to be PHP’s answer to Ruby on Rails.
The approaches are similar and different to each other. I set up both on my laptop, and tried out some really simple app development. In Cake, the database build is separate from the application building (you do it yourself), whereas in Symfony, you use Symfony to build the database with schema files written in YAML. Then, you build forms and such using the schema as a foundation.
They both use the MVC pattern, and both use object oriented PHP, which is great. I got a lot further with Cake in one evening of playing with both than I did with Symfony. At this point, I really prefer Cake – it feels like it jives with my own coding sensibilities better. I also don’t like the overhead of learning YAML. I can imagine, though, that the Symfony approach can be powerful.
Looking at Ohloh, Cake is more popular than Symfony (on Ohloh, who knows about in general), but Symfony has a lot more developers (81 vs 17). They both have good documentation and active communities.
For now, unless something strange happens, I’ll settle on Cake – although I’ll not be spending too much time on it, since I’m working hard to grok Drupal. But perhaps a cool project will manifest, and I can use it.
Update: I learned that Yahoo and delicious have a huge investment in Symfony (which, I guess, might be why they have so many more developers.)
I think that if I had to pick only one thing that would help people understand the character of Drupal, it would be the WYSIWYG editor that comes standard with an out-of-the-box Drupal installation. That would be NONE. There is no standard WYSIWYG editor that comes with Drupal. You have to figure out how to find one, and install and configure it yourself.
So if you want to start adding content to your new site, and you need a little formatting, or a picture, etc., well, unless you know a bit of HTML, you are S.O.L.
On the other hand, this is actually, from my perspective, a really good thing (can you tell I’m becoming a Drupalista?) There are several to choose from, and they differ both in difficulty to get installed and working, as well as features. Want something barebones? There’s one for you. Want something with all of the bells and whistles? There’s one for you, too.
There is a great review of five of the major ones.
I’ve been getting to know a few of them (and, yes, they can be a pain to install, and they depend, generally, on other libraries that you have to install as well.) I don’t have a favorite yet, but I’m thinking I don’t need to have one – just to know which ones are well-maintained, and what the differences are in feature set. Then I can choose the one that makes the most sense.
I’ve been working with Drupal a fair bit over the last few weeks, with the ultimate goal to basically be able to really work with it to create sites. I converted my (very simple) consulting site to Drupal, without any bells and whistles. I’m working now on a site that needs some bells and whistles, like translated pages and a WYSIWYG editor (ah, the WYSIWYG editor thing in Drupal is going to get its own blog entry, I’m sure).
My next step is to try and create a simple theme (so I understand how theming works,) and write a module (so I understand how modules work.) There are still lots of things that are mysteries to me, but perhaps I’ll learn more at Bay Area Drupal camp this weekend.
I’ve also been digging a lot into the new(ish) social network software Elgg, and beginning to develop a members-only site with it for a client. In my estimation, it’s amazingly promising, as a platform for interesting private sites. And, since it has OpenID (which seems to have bugs, though), OpenDD, and OpenSocial, it’s not such a bad idea for public sites either (although I’d still not suggest that nonprofits spend the time to do this.) Maybe someone will use it to create the Facebook killer (I kind of doubt it, but I can hope, can’t I?)
As well, I’m still honing my WordPress skills, mostly in the realm of dealing with themes and moving the darn things around and upgrading from ancient versions. I’ve done some theme hacking, but haven’t yet written a plugin (I can’t think of one to write that hasn’t been written yet.)
And, on top of all of that, I’m re-writing in PHP some core functions of a web-database/CMS framework I wrote in Perl a gazillion years ago (and still is in use for an application called EASE.) That’s been fun. What’s also fun in retrospect is that the framework (the erstwhile Xina) was written basically using the MVC architectural pattern before I knew it existed!
It feels like I’m beginning to focus on a core set of tools and technologies (PHP, Drupal, WP, Elgg,) and that in a few months, I’ll be up to speaking PHP fluently, like I spoke Perl a while back. And I’m looking forward to getting to work on the kinds of projects that I’ve been watching as a spectator in the last year.