A couple of days ago I was sent a link to Robert Cringely’s latest treatise: The second coming of Java – and to say I disagreed was a bit of an understatement. To me, it represents a fundamental flaw in his perception of developers, and more importantly the economics of software development.
The key to Cringely’s argument comes down to this:
When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true.
What he’s missing here is the real reason people use frameworks like Rails; it’s not about it being Ruby, or being the latest cool thing – it’s about developer productivity. That’s it, and that’s all there is to it – Rails allows a developer to do more in less time. That’s one of the key reasons so many Java web developers jumped ship (though I can think of a few others), and what pushed Microsoft to invest so heavily in their MVC framework.
I could fully rehash the argument, but in what I consider to be one of Jeff Atwood’s best articles, Hardware is Cheap, Programmers are Expensive, he covers a key point to my argument – developer time is vastly more expensive than hardware. Atwood’s take on the issue is clear:
Clearly, hardware is cheap, and programmers are expensive. Whenever you’re provided an opportunity to leverage that imbalance, it would be incredibly foolish not to.
When there’s a choice between developer productivity, and spending money on hardware – the conclusion should be the same. It’s much cheaper to throw more hardware at a slower framework than it is to invest more developer time in a faster framework. For any non-trivial application, throwing more front-end servers at it will always be cheaper than slowing the development process down with a non-productivity-centric toolkit.
It’s simple economics; server hardware is getting faster and cheaper, developer time is only getting more expensive.
I was recently given the task of ensuring that a Silverlight+RIA application that could contain private information was secure for deployment to a public web site. So I started searching for automated pen-testing tools that could work against Microsoft’s Binary SOAP protocol (msbin1, a.k.a “application/soap+msbin1“) and found only disappointment. For various reasons, it’s significantly more complex to pen-test a application using msbin1 than traditional SOAP + WSDL.
To properly test the services, I had to make a compromise: temporarily modify the application to expose a SOAP endpoint. While this changes the state of the application and thus reduces the validity of the tests, it does provide a reasonable way of testing the web services to ensure that they are behaving as intended.
The recently released SoapUI Pro 4 adds new security testing tools that makes this a viable (and attractive option). To get this working, there are a few small changes that need to be made to the solution:
First, you’ll need to add a reference to “Microsoft.ServiceModel.DomainServices.Hosting.EndPoints” which is part of the RIA Services Toolkit; this allows you to expose different End Points for the service such as SOAP and OData.
Next, you’ll want to add the following configSections entry to your Web.config:
<configuration>
<configSections>
<sectionGroup name="system.serviceModel">
<section name="domainServices"
type="System.ServiceModel.DomainServices.Hosting.DomainServicesSection,
System.ServiceModel.DomainServices.Hosting,
Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</sectionGroup>
</configSections>
...
Finally, to expose the SOAP end point:
<configuration>
...
<system.serviceModel>
...
<domainServices>
<endpoints>
<add name="Soap"
type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
Microsoft.ServiceModel.DomainServices.Hosting,
Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</endpoints>
</domainServices>
...
Finally, just follow the instructions for SoapUI to setup your tests, and you can feel (just a little) more confident in your application. Passing with flying colors obviously doesn’t mean your application is bulletproof, but it helps to confirm that web service code is solid.
Now, while this does provide some insight into your application and should help find common issues, it’s not a replacement for a professional assessment by a qualified auditor. If you are handling credit cards or other highly targeted information, please consult a security specialist before a public deployment.
This morning, the latest version of my favorite forum software, bbPress, was released. While this is a beta and not a final release, it’s still a major event for the project: this release is in the form of a WordPress plugin, instead of a stand-alone application as it’s been in the past. In December 2009 I wrote about this decision – and at the time I was rather disappointed with the change in direction; but now my views have changed. I’m also excited to see that Matt and his company, Automattic have decided to invest the time and money needed to make this happen; there for a while it looked like bbPress really was dying.
Thanks to services like StackExchange and its numerous clones, it seems the days of standalone forums are numbered; when combined with the increasing strength of WordPress as a full-blown CMS, this move actually makes a lot of sense.
I’m excited both as a user and developer – this opens many new doors from both perspectives, and will certainly increase adoption of the software, as integration with the current version is a bit tricky.
Congratulations to the entire team on this release; it really is a major milestone for the project!
On my fresh Ubuntu 11.04 box running Ruby 1.9.2 instead of the standard Ruby 1.8, I ran into some undocumented errors while installing the mysql2 gem. Here’s what I was seeing:
$ gem install mysql2
Building native extensions. This could take a while...
ERROR: Error installing mysql2:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.9.1 extconf.rb
<internal:lib/rubygems/custom_require>:29:in `require':
no such file to load -- mkmf (LoadError)
from <internal:lib/rubygems/custom_require>:29:in `require'
from extconf.rb:2:in `<main>'
Gem files will remain installed in
/usr/lib/ruby/gems/1.9.1/gems/mysql2-0.3.2 for inspection.
Results logged to
/usr/lib/ruby/gems/1.9.1/gems/mysql2-0.3.2/ext/mysql2/gem_make.out
This obviously isn’t all that helpful, nor did I find anything all that useful on Google – thankfully the issue is easy to solve. All that’s needed is to ensure that the following packages are installed:
sudo apt-get install libmysqlclient-dev libmysql-ruby1.9 ruby1.9.1-dev
Then you can try installing the gem, it should work, hopefully
For those outside of the IT field, developers are looked at as miracle workers – through us, business leaders think anything is possible (and they often see no reason why we can’t work our latest miracle by the next morning). In reality though, we do work miracles; we save companies vast amounts of money every year through increased worker efficiency and automation, we enable new lines of business that wouldn’t be possible otherwise, and reduce energy costs because we keep the office lights turned off. Well, that’s more or less how they see us.
But for all of the wonders we are responsible for, there is one thing we can’t do (no matter what amazing powers some executives think we have to make them look better or earn them more bonuses):
You can’t fix stupid.
I’ve often described development as being a professional problem solver, and we are often tasked with rather challenging problems to solve. Sometimes the problems are purely technical – making something new possible that previously was impracticable or even impossible, sometimes it’s all about efficiency, other times it’s about image and controlling how people see a company. When the problem is the user though, you know you’re in for a rough day.
I was recently given such a task – the users weren’t listening to their supervisors and they wanted the software to force these users to do whatever it was that management told them they should be doing. I was given less than a week to find ways to make people that don’t want to work, work.
Basically, users fall into three simple categories:
- Power Users – these users understand software, and require little, if any instruction – more than anything, you give these users a tool and stay out of their way.
- Average Users – odds are, your mother or father falls into this category. They understand enough to get by, and with a little instruction they should have no trouble.
- Idiots* – odds are, you work with one of these users. You lead them by they hand, and show them exactly what to do – just in time for the boss to walk by and praise them for doing a good job (and 10 minutes later you find them playing in traffic, somehow defying Darwin in the process).
For users of the last category, there’s just not much you can do.
I always do my due diligence while building software; doing all I can to make it simple to use, flexible, and forgiving of user error. I always use extensive data validation, carefully worded instructions and dialogs, and do my best to follow the various best-practice guides for UI and UX; yet for all this effort and design – I can’t write software that thinks for people or makes judgement calls based on business rules that only they know (probably because they make it up as they go).
No matter how helpful or intelligent an application is, or how idiot-proof you think you’ve made it, reality is that you simply can’t fix stupid – you can’t take an incompetent person that refuses to think for themselves and turn them to into a great, productive asset. After years in this industry (which has made me just a little cynical [in the way that Sol only seems little when compared to Betelgeuse]), I’ve come to understand something rather disturbing: idiots keep getting better.
Somewhere, right now, idiots are working to build even better idiots – and that’s a really scary thought.
We can make a user more efficient by automating tasks, providing better information, or helping to manage their workload – what we can’t do is make them smarter, make them think through their actions, or force them to do what their managers tell them. Yet we are, at least on occasion, asked to fix this problem.
Despite our best efforts as professionals and passionate developers; if a user won’t think – we just can’t fix it.
* – I define an idiot about the same way I do someone that’s lazy; they have no medical issues or legitimate handicap. They just don’t want to think or work (probably both). Those that are handicap or have learning or medical issues are a very different story and not the target of this article; I donated time and services to charities that served the disabled for a number of years, I highly recommend that all developers do it – it’s a very rewarding experience to see your work make somebody’s life better and it teaches you quite a bit about how people interact with technology.
While building a new website for a small ISV, I was asked to integrate a forum – should be simple I thought, I’ll just use WordPress as a CMS and bbPress. Simple? Not quite.
To make things easier, I used Platform Pro by Pagelines (a great platform IMHO) and so used their “deep integration” instructions (while they are intended for Platform Pro users, the steps are virtually identical for all other setups). While the setup went quite smoothly, it wasn’t until it came time to test user registrations that the issue came up: when a new user tried to register they would receive an error stating that “email is required,” even if they had entered a valid email address. This effectively made it impossible for users to register, and thus made the forum useless.
After a bit of research, it looks like there is a conflict between newer versions of WordPress (3.0+) and bbPress 1.0.2 (I’m not sure if older versions have the same issue, but I would assume so). The fix for this is actually quite simple: install a plugin. The plugin itself is quite simple – containing only around a half-dozen executable lines of code, and works around the issue with a simple hack.
Unfortunately, the plugin description is rather vague and required a fair bit of research to identify as the fix, and the official documentation makes no reference to the issue or that this plugin can be used as a workaround.
Overall, a simple workaround but a major issue if you don’t notice that it’s broke (as is quite easy to do).
