From the category archives:

Development

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.

 

Tagged as: , ,

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.

Tagged as: , ,

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!

Tagged as: , , ,

What Drupal and Salesforce have taught me about coding

by Pearlbear on June 30, 2010

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: , , ,

{ 1 comment }

Why use contributed Salesforce modules for Drupal?

by Pearlbear on March 24, 2010

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: , , ,

The easier it looks, the more expensive it will be (or, how to avoid clusterfrack projects)

by Pearlbear on March 23, 2010

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: , , ,

{ 3 comments }

Specify Story, not details

by Pearlbear on August 19, 2009

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: , ,

{ 4 comments }

Be like a three year-old

by Pearlbear on May 3, 2009

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: ,

{ 1 comment }

Drupal Themeing, and other projects

by Pearlbear on November 13, 2008

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.

{ 2 comments }

Cake vs. Symfony

by Pearlbear on November 6, 2008

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.)

{ 10 comments }

← Previous Entries