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
I’ve been getting to know Amazon S3 lately, and there are some great things about it. I think it is one of the long list of unpredicted successes that resulted from the near-ubiquitousness of open source software on the server side. We’ve been using it for “offsite” backup for drupal sites for a while now. We have a script going which runs by cron daily to do the backups.
There are a number of ways to do this. We started using S3fs as a way to mount an S3 bucket in the filesystem, then just copy the files to S3. One of the scripts we’ve use is here. (We also use rsync.) However, S3fs isn’t very actively supported or in development. So we’re thinking of moving to use S3cmd, which works really well, and is still under active development.
Tagged as:
amazon,
aws,
backup,
drupal,
s3
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
I’ve been doing a bit of playing around with Drupal 7 in my copious spare time (not a whole lot of that!) I’ve also been keeping track, a bit of how the development process is going, and what things will look like. One thing to say – it feels like as big an improvement as Drupal 6 was to Drupal 5.
Of course, mostly, Drupal is only as good as it’s contributed modules (that’s a bit more of a stretch, now, because many of the key contributed modules, like CCK, are now in core Drupal.) So when folks like us, who build sites that depend on Drupal 7 can start using it is a bit up in the air, although there is a movement to get many modules ready for Drupal 7 at it’s release. But some may well not make it. We’re guessing that we’ll start building production sites in Drupal 7 starting in late summer, early fall, depending on requirements.
A note: the standard process for deprecation of old Drupal versions is that when a new version of core comes out, the one two versions back stops being officially supported. So Drupal 5 will no longer get security updates and the like. Already, many module developers have stopped supporting versions of their modules that work on Drupal 5. (The salesforce module maintainers recently made that decision, as have others.) So certainly a site running Drupal 5 won’t stop working, but it will become vulnerable without security updates to core or modules, and it will get increasingly difficult to maintain and add features to. So it might be a good idea to budget the time and money to upgrade as soon as possible if you are on Drupal 5. If you are on Drupal 6, you’ve got a while yet, but Drupal 7 certainly has some great advantages, particularly in user experience, to look at.
Tagged as:
CMS,
drupal,
opensource
Although it’s not often used in nonprofit settings, the Drupal module (or, more correctly, a large suite of modules) called “Ubercart” is a pretty amazing tool if you need to create a shopping cart system. We’ve implemented it for organizations that want to sell fees for events, sell items, and take donations. It doesn’t have many of the strengths of CiviCRM, but it has a lot of useful features if you want to sell things, or combine selling things with taking donations, memberships and selling event tickets.
A while back, I’d heard of the Ubercore initiative – a group of developers working to bring Ubercart to Drupal 7 (there was quite a delay between the release of Drupal 6 and the availability of Ubercart for Drupal 6.) That initiative is now called “Drupal Commerce. (other site here.)” It is basically meant to be a rewrite of Ubercart for Drupal 7. It looks to be something to watch. Gregory Heller of CivicActions wrote an interesting conceptual piece on the integration of Drupal Commerce and CiviCRM that’s worth a read. (By the way, there is a module done by DharmaTech that integrates CiviCRM and the current Ubercart.)
Tagged as:
civicrm,
CMS,
drupal,
drupal7,
ubercart
It’s taken me a while to write this blog post, mostly because I have been working hard at various things (like building a business and building new websites.) This is the last installment in my CRM/CMS integration series, that started almost a year ago (wow!) And I’m skipping Joomla/Salesforce Integration because there isn’t any publicly available documentation or code about the integration that PICnet did with Joomla and Salesforce, called J!Salesforce. [update: see Ryan's comment below.]
So what is the state of Drupal/Salesforce Integration? It’s not as mature as the Plone/Salesforce integration, for sure, but it is coming along nicely. There are several contributed modules:
- salesforce – main module, with API, node, and user integration possibilities. This module provides the basic salesforce API connection (via SOAP), and includes field mapping, and basic import/export
- sf_webform – Makes integration with webforms in Drupal fairly easy. Web-to-lead is quite nice and flexible with this module.
- uc_salesforce – Provides integration with ubercart orders
- parser-salesforce – Integration with FeedAPI – pulling data from salesforce into drupal nodes via FeedAPI (I hope to start maintaining this module)
- sf_import – Import Salesforce objects into Drupal nodes (will be folded into the main salesforce module)
All of these modules are in alpha or beta, although I know for a fact that some of them (or versions of them) are working in production sites. There are a fair number of bugs that need to be fixed before there is a stable release. There are a bunch of outstanding issues that need a lot of work (like caching, for instance). There are two other modules that are related, but don’t use the main salesforce api module – one for ubercart, and one for web-to-lead (called salesforcewebform). That module has a stable release, but only provides the ability to integrate between Webforms and leads, not other objects.
Right now, the salesforce module allows for integration of contact, lead and campaign objects only. so that’s another big area that could use some work.
There is a good screencast done by one of the folks (Jeff Miccolis from Development Seed) who has worked a lot on this project.
I’d say that in a year, we’ll have a good solid module release, providing lots of features for integration between Drupal and Salesforce.com.
Tagged as:
CMS,
CRM,
drupal,
integration,
nptech,
salesforce
Now that the Idealware CMS report is out, I get to have my say about it. Here’s the first post, there might be more to come.
The thing that is prompting this post is the little storm about the security metric that we used to try and get a handle on the security of the 4 different systems we reviewed. More on that in a bit.
You might think that comparing four different open source packages that, in essence, do pretty the same thing (in a broad sense) would be a cakc walk. In fact, nothing could be farther from the truth. The developers of each project have completely different sets of assumptions about what the right way to do things is, and completely different philosophies and ethos when it comes to building interfaces and functionality. Making apples-to-apples comparisons of these systems was one of the most difficult analytical tasks I’ve taken on in a while (and, actually much of the heavy lifting of designing the analysis was done by Laura Quinn), and until you attempt such a thing, please be somewhat tempered in your complaints about it.
Now the security issue. One of the 12 different aspects we are comparing is “Scalability and security”. The report isn’t about security, it’s a very, very broad comparison of the systems, with security as a very small component. That’s just the context. Two (yes, just two) questions out of many relate to security. First, a simple metric relating to security reports, and second, what processes are in place in the communities to deal with security. This wasn’t designed to be an in-dept, complex analysis of security. If it had been, we would have done a lot more work on how to measure security. On the Four Kitchens blog, they say, “While both reports above seem to identify Drupal (and Joomla! and WordPress, to be fair) as having notably bad [emphasis mine] security, they’re also both based on one superficial metric: self-reported vulnerabilities.” Now I can’t speak about the IBM report (I haven’t even read it yet), but our report says no such thing. Drupal gets a “Solid” on Scalability and security. Solid, which is only one step below Excellent. And you know why it got a “Solid”? Because, indeed, it does have more reported security vulnerabilities than Plone (as do Joomla and WordPress.)
David Geilhufe, who also takes issue with the security metric, has some good points. Yes, sheer numbers of vulnerabilities are not anywhere near the best metric of whether or not a system is secure or not. As a quick comparative look between a small number of open source systems, it’s hard to argue that it contributes no information. Four Kitchens seems to suggest that part of the reason for more vulnerabilities in Drupal compared to Plone is that it’s more popular. But, if you’ve been an observer to the Linux/Windows FUD wars, you’ll remember that Microsoft has that exact same argument about why there are more security vulnerabilities in Windows as compared to Linux. And the Linux folks say, in response, “It’s not popularity, it’s design.” I’m sure that Four Kitchens, and most open source software developers agree with that perspective. In reviewing Plone, and talking with people who develop for Plone, I was convinced that the reason that Plone had fewer reported vulnerabilities was not just because it was less popular – it’s because it (and Python and Zope) was more secure by design.
I am completely happy with Drupal’s security (otherwise, it wouldn’t have gotten a “Solid.”) I think the Drupal community takes security extremely seriously, and if they didn’t, I wouldn’t have chosen it as a platform for development. I also think that the Joomla and WordPress communities take security seriously. In our estimation, they were all really good. But Plone was just that much better.
Tagged as:
CMS,
drupal,
idealware,
plone,
security
I have some exciting news. For the last few months, I have been working on a new collaboration called OpenIssue, which is a growing, diverse, self-reflective and constantly-learning team. We are focused on delivering quality web technology solutions to nonprofit organizations and social enterprises.
As you know, I have built a long-time expertise in open source software and web applications, particularly Content Management Systems (CMS) and online database systems, including CRM. Thomas Groden, my new business partner, has expertise in Software-as-a-Service Constituent Relationship Management Systems (CRM), as well as much more broad expertise in technology infrastructure.
All technology implementors have to choose their tools (unless they run a very large shop) and we have decided to focus on implementation of both Salesforce.com and CiviCRM as CRMs, and Drupal as a CMS. We are keenly interested in building on our expertise to integrate these open platforms in really rich ways, to allow organizations to create great online applications.
I’m excited to be a part of a team – I’ve been a soloist for a while, and it’s nice to build collaborations, and work together with people with shared ideals on larger projects than I’d be able to take on alone. And I’m really excited by the set of technologies we’re working on, and the kinds of applications we’ll be building with these technologies.
And you can follow us on twitter.
Tagged as:
civcrm,
CMS,
Consulting,
convio commonground,
CRM,
drupal,
nptech,
salesforce
It’s been a few days since I got back from Drupalcon, and I’ve had time to let all of the things that happened settle in. It was a great time, and I’m really happy I went.
We had a fabulous (and quite large) nptech/progressive exchange/community organizing BoF. There was a show-and-tell session for nonprofit websites (which I didn’t make it to). I went to some interesting sessions on Ubercart, Organic Groups, and a BoF on Drupal in churches (where I wondered about the theological spectrum, and guessed was populated mostly by evangelicals.) I met lots of great people, and saw old and new friends.
I think, also, I’ve completely drunk the Drupal koolaid. I’m psyched to be working with Drupal more intensely (I’ve got 4 Drupal projects going at the present moment.) There’s lots of new things to learn, and challenges to face, but I’m excited about digging in a lot deeper. I’m sure I’ll have more to say as time goes on. And I’m looking for good excuses to go to Paris for Drupalcon Paris!
There were lots of great talks, and the videos are up!
Tagged as:
CMS,
drupal,
drupalcon,
nptech,
opensource
At the end of day one, I figured I’d give a little report on how DrupalconDC is going for me. I’m having a good time, and learning a lot.
I went to three pretty intro talks (two of them were a bit too intro for me, but I got a few good tips) and one advanced panel.
- Themers Toolkit- I’ve only done a few themes, and modified a few, but I guess that was enough for this panel to be too beginner for me. But I did learn a few tricks I didn’t know, so it was useful. It was a good talk.
- Totally Rocking Your Development Environment – also covered mostly stuff I knew, but I did learn a few tips (and also learned a little from my next door neighbor. It was a great talk by an incredibly enthusiastic speaker. I can’t believe though, that she suggested using Makefiles for Drupal!
- Organic Groups – since I haven’t personally implemented OG, I didn’t know a lot about the innards, and how it really works. It was a great introduction, and I’m totally sold on it. He gave some sweet examples of it’s use (like teamsugar.com) which is amazing, and made me totally rethink using Elgg.
- Advanced Theming Techniques - A nice talk given by two folks from CivicActions, once of whom I’d worked with jointly on a client project. I learned a fair bit, and now have some good techniques to think about using as I start doing more serious theming (although, truthfully, I’d like to eventually be able to hand that off to folks who have a better visual sense than I.)
Dries‘ keynote was fun, and it was great to hear a bit about the history, and also the ideas about where Drupal is going. One thing he said in particular stood out: “Start thinking of the internet as one big machine.” The idea is that as barriers to the movement of data come down, doing things that were never possible before become a lot more possible. And there is some really cool stuff coming in the future like OAuth, Job Queues, RDFa output, XMPP, and Activity logs. Really neat.
I missed a couple of talks I’d wish I could have made, like the Drupal SEO talk, and Install Profiles. I was glad to see that there are a significant number of women here, and a number of women presenters, too.
I hung out with Drupalchix for lunch, and met new folks, saw some colleagues, and generally have been having a good time. I’m very much looking forward to tomorrow.
Tagged as:
CMS,
drupal,
drupalcon,
nptech,
opensource