Category Archives: languages

Open-Source Gone Bad

I stand by (and blog on) open-source languages. They’re customizable yet robust and come with an extensive library of public documentation. More often than not, a quick Google search can help you get through that epic wall you’ve been bashing for hours. Feeling innovative? You can always see the “what if” attempts made by other programmers across the web. This open collaboration is key to pushing the envelop and finding new means of development. Sounds so lovely, right? Well, I’m feeling obligated to note the downside due to the nuances battled in a recent project.

Here’s the thing with open source — You’re making yourself wide open to dealing with inconsistencies and, even worse, blatantly incorrect code. Logic, though primarily 0/1 or TRUE/FALSE, can easily conform to a programmer’s style. There may be one right answer, but many ways of getting there. That said, you may have immediate access to great code and ideas, but you’re likely to spend some time getting that programmer’s style to conform to your own within your projects. Oh, and the whole “this isn’t even right” portion of this example.

I downloaded a new installation of CakePHP and found some great Bootstrap/ACL plugins and helpers to get the site to be super responsive and equally secure. Yet, I kept hitting walls with some of my forms; they would not validate properly despite using the same code as in other, working projects. Let the debugging begin.

Hours later, I realize the issue derives from the improperly formatted parameters in an example created by the plugin developer. ::sigh:: So much time assuming it’s a database or structural issue. Nope! Just a simple inclusion that hoses the entire functionality. Moments like that are a key reminder that open source has its fair share of nuances and disadvantages. Be sure to always weigh the pros and cons of a priced solution, as time can quickly cost more than an upfront payment.

Mid-project realization: double-check all browser validation capabilities before destroying the validation in your project. More browsers are intervening with front-end validation (HTML5) so be sure to add the “novalidate” parameter to your forms to maintain your own error message:

<form method="post" action="/foo" novalidate>

Otherwise, you will see a generic alert with browser-oriented colors and text. Still debating if I appreciate this feature or not. Front-end validation = good. Browser-controlled styling and text = not so hot. Baby steps.

Happy coding!