Posts tagged as:

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

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 }

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.

Tagged as: , , ,