Sunday, March 26, 2017

Pretty Good, Quick Read

I’ve decided to shorten these posts tremendously lol. I realize: one - no one wants to read all of that, two, it takes way too long to hit a “word count,” and three, I don’t have that much to say. So with that, on to the point...

 I just finished Code Simplicity by Max Kanat-Alexander - good read. It’s only 84 pages, so it’s something you can finish in a day, and it does a really good job of covering the basics of solid app design - not necessarily the mechanics (languages, tools, etc. - not even SOLID principles), but more so what to look for in your system.

 I wouldn’t say it’s something for someone completely new to the field. You won’t have the experience to really understand what he’s saying. On the surface, his concepts may seem simplistic, but if you relate to the experience, it holds a totally different meaning. For example, I recently went through an example of a problem mentioned in the book. Without going into details, I intuitively knew something was wrong with the assignment, but I couldn't articulate my concerns, at that time.  I had a real “I knew it!” moment when I got to that part of the book. It felt great. As a relatively new developer, knowing that it's "not me" helps.

Given the length of the book (it’s really a quick read), I even recommend it for seasoned developers. Experience doesn’t necessarily translate to great design. A really skilled developer can quickly create an aesthetically beautiful, bug-free, body of code that is not maintainable, or open to change. Even if you’ve moved on to a lead role, with less development, realizing some of the challenges your team faces at the start of a project, can help manage expectation.

Sunday, March 12, 2017

No More Drupal For Me

Let me start by saying this article refers to Drupal 7.  I have no experience with 8.  I’ve read that it may address some of the concerns I outline below, but I haven’t investigated.  By the end of this article, I hope you understand why.  

I’m not new to Drupal.  Over the past 4 or 5 years, I’ve consistently found myself involved in a project using it, and I’ve done a bit - from custom module and template development, to aliasing drush commands.  I even went to the first DrupalCon Conference in Chicago.  I know not to hack the core, how to update, what a distribution is, and much of what I think most devs would consider the basics.  I’m far from an expert, but I know enough to get a project off the ground.

My main problem with Drupal has nothing to do with how it's built, maintained, or even how it performs (in terms of actual backend execution).  My main problem is that it doesn’t support single page app architecture, which I will refer to as service oriented architecture, from this point forward.  I’m a big fan of single page apps.  They’re faster for the user, easier to maintain, decoupled from the backend, and reusable.  I probably don’t need to spend much time touting the benefits of SOA.  Unless you’re a die-hard full stack developer, you’re probably with me.  

Drupal uses reusable templates (themes) for the UI, which could lead one to think “SOA,” but it’s completely different.  The front and backends are not separate; they are fused.  Each “page” requires a full trip to the server, and subsequent bootstrapping.  This is where performance and user experience crash.  It also opens the door to unnecessary errors (network failure, failed resource loading, etc.), and the inability to scale your app.  Drupal is a “backend” framework, just one ill-suited to service a decoupled front end.  It’s designed to generate renderable html, not manipulate headers, or return JSON.

This is where Drupal 8 supposedly comes into play.  I say “supposedly” because I’ve only read these things (headless Drupal and all of that), but for argument’s sake, let us assume it true: Drupal 8 is designed to service frontend applications.  Drupal 7 definitely is not.  Given its roots, and need to support porting from 7 to 8, I have a hard time seeing how completely different use-cases are easily implemented in a framework.  If this were done truly well, I’m sure there would be more of a buzz in the developer community.  

There’s also a serious learning curve.  Eight is completely different than 7, according to Dries Buytaert, the creator of Drupal, and I just don’t have time for that.  I might be more inclined to experiment if it were just a bunch of new functions, modules, or whatever.  Instead, it sounds like I need to invest time into learning an essentially new framework.  I already use a micro-framework (Slim), and the only new one I’m interested in learning is Laravel.  Consequently, I’ve decided to move away from Drupal.  

Sunday, March 5, 2017

Warming Up To Backbone.JS

I’m pretty new to Backbone.  I started using it in early 2016.  My first “large” app was really complex and hard to develop.  I made so many mistakes - using jQuery instead of methods, callbacks instead of events, business logic in the router - plenty of issues.  It was… unpleasant… but worth the pain: what I learned in event-based architecture and “object-oriented” JS was invaluable.  I’m currently working on my fourth app, and I feel like my code is much more flexible and solid.

A big turning-point for me was realizing that it’s just Underscore for objects.  This revelation has made all the difference.  Knowing that it’s possible to build a Backbone-like app without actually using the library, has helped me appreciate the work that it does.  It has also changed the way I think about solving problems.  Instead of focusing on the steps needed to update a UI (methods), for example, now I think about how I could single-out a dynamic element, and create an object and template for it.

I even see the point of making all dynamic elements views.  With just a little more work, you gain way more flexibility.  Handlers are much easier to use and organize, you can incorporate a model and its syncing methods (should you decide to start capturing data on that element) - the options seem endless. You could achieve these same ends with a vanilla JS object, but why do that when adding just a few more lines of code, adds tons of functionality to that same object?  It's an even more compelling case if you're already using Underscore. Snippets have been helpful here, by the way.  Again, more work up-front, but worth it in the long-run.

Of course I’ve found my share of issues.  The biggest one being the need for a build system, or some sort of dependency manager (RequireJS, SystemJS, etc.).  I’m over it now, but I really disliked this, at first; I felt like it just added more complexity to the app - making something like understanding a .gulpfile an added dev requirement.  That’s not cool.  It makes it harder for a new dev to learn.  After the build system is in place though, it’s painless.

I’ve read the articles and know a large portion of Backbone users love its flexibility.  I’m not in that camp, however; I’d prefer more rules around its use.  I designed my first app terribly.  Honestly, I still don’t know if I’ve found an “optimum” structure, but I just keep moving forward.  It would help guys like me to have a “right” way.

I still have a ton to learn with Backbone.  It’s fairly old, at this point, and taking a back seat to Angular and React, but I still find it very useful.  Plus, it’s used in plenty of legacy apps.  At some point, I plan to move on to more "in-demand" frameworks and libraries, but Backbone has been a good start.  My code is much more modular, with tighter cohesion and looser coupling.