Code That Reads Like A Novel

I’ve run across this more and more, recently – developers who want code to read like a novel.  In other words, they want an entire application’s logic to be in one script – maybe a couple more, if the app is really complex.  And we’re not talking concatenated files, here (I’m all for those); the design should result in one script. 

I think this is so problematic. Multiple contributors to a document typically makes it harder to read.  Each dev has his or her own style, and when you start to mix them, it just becomes weird and hard to follow.  When I first started running into code like this, I adjusted my style to fit what I saw.  I thought it was a good idea.  Ten months down the road, however, when there was more work to do, I was lost.  I couldn’t remember what I was trying to do, or even why.  It didn’t save time, or make the app more maintainable.  The added (unnecessary) frustration didn’t help, either.

Changing working code often introduces new bugs.  How many times have you made a quick fix, just to later find out that you created another problem?  Happens all the time.  In small, decoupled scripts, that’s practically impossible to do.  If it turns out that something is wrong with your code, you can be sure the error is in the document that you created/altered.  No need to go searching through 1500 lines of code to figure out the issue.

Forget about replacing libraries, or even large portions of functionality.  That’s a guaranteed re-write.  Search and replace won’t save you when you when there are 150 versions of the function name you’re trying to update/replace.  In writing an elaborate to-do app, for example, you’re inevitably going to use some variation of the word “task” at least 100 times.  Sometimes it’ll be in comments.  Sometimes it’ll be part of variable names.  You may even find it in include-file names. 

Lastly, (I know I’m getting a bit long-winded here), unless you’re given a complete build, most tickets are for bug or feature requests.  In either case, you don't need to know how the entire app functions to solve the problem.  You just need to know where to implement your solution.  I almost always create new scripts, once I’ve reached this point.  When I realize I’ve misunderstood the requirements, I just go directly to that doc, and make changes. 

Ultimately, these long scripts make code more brittle.  I’m probably preaching to the choir, for the most part.  It seems most of us prefer to have our code broken down into modules/components that are then assembled in a main script (router, App.js, etc.).  Still, there are quite a few who disagree.  I’m just supporting my position.

As always, let me know what you think. 

Addressing The Problems With Object-Oriented Programming

YouTutbe is not my primary resource for learning new technology or paradigms.  I'm a Pluralsight-Lynda guy.  I still like to listen to presentations and lectures, though -  just to see what people are talking about in the real world.  There are a lot of conferences and interesting presentations posted on YouTube.

I'm an OO guy... still (I probably just lost all the functional devs, but I guess I'll be converting soon with React, we'll see...), but I do recognize the tricky issues inherent to object-oriented designs.  I was hoping this video might shed some light on what other devs do when they face similar problems.  I was in agreement with the early parts, but somewhere around that 30-minute mark, things started to change.  Then came the solutions, and that's where he completely lost me...  I think the solutions are worse than the problems.

My biggest issue with Will Brian's solutions, hands-down, is implementing long methods.  I don't even know where to begin.  They are hard to read - heaping loads of conditionals, variables, and state on you.  Accidentally breaking code because of semantic mistakes is a regular problem (unmatched curly braces, anyone?).  In Javascript, nested and inline functions lead to memory leaks.  It's impossible to reuse code that's bundled-up in another function.    It's just bad stuff.  I prefer the S.L.A.P. (single level of abstraction principle) approach, which basically boils down to new functions for every indentation.  I started doing this a few months ago, and it has saved tons of time in understanding flow, logic, and documentation (if you use good names).  I'll never go back to long methods.

Then there's the recommendation to use comments to explain what's happening in the long functions - another head-scratcher.  What's more common than an outdated comment?  I've learned to distrust them.  Instead, I follow the code.  Comments are useful when they explain why you've done something, but not to document what you've done.  Good function and variable names are better.

I'm also not sure what the problem is with "hopping" around code.  If functions are short, and scripts cohesive, you shouldn't be "hopping" far - especially if you copy-and-find.  Sublime even has a nice shortcut for specifically finding functions (control+R) - a very nice feature, indeed.  Hopping from script-to-script is painful, but as far as I can tell, it's just the price of decoupling.  I'm open to suggestions that eliminate tons of script files, but not if it means coupling.  There are always changes and rewrites; coupling makes them a nightmare.

But my intention here is not to antagonize Brian, or to try and poke holes in his coding philosophy.  Instead, I was inspired to speak my opinion on the ideas he raised.  It's a great reminder of the different types of devs we work with, and how we're all passionate about our ideas of good code.  "Object-Oriented Programming Is Bad" has nearly a half-million views, and it's only roughly a year and half old.  There are thousands of likes and dislikes - not bad numbers for a design pattern video.  Check out the comments - a lot of activity there, as well - all indicators that he has touched on very real issues.

Anyway, just sharing a few thoughts.  Let me know what you think about the video.

Twitter, Amazon, and Pornhub Work Together

This short video, from the Vlog Brothers, does a pretty good job explaining the issue at hand.  It's a little dated, but the issues are essentially the same.

Disappointing.  I had so many notes... so many things to say... I'm so pissed... but now I'm out of time (at least I hope so).  It's supposed to go down tomorrow: we stand up against net neutrality.  Quite a few big, online players (think Twitter, Amazon, Netflix, Github, Atlassian...) are orchestrating an effort to stop the FCC from ending net neutrality.

For those of you who don't know,  net neutrality is pretty much the idea that that the internet should remain as is - with no "governing" body controlling access to content.  This is a big issue, right now, and there seems to be some confusion.  I've run across a few videos and articles from people who think net neutrality is the exact opposite, and should be fought.  If you know anyone in those circles, please make sure they know the facts.  We need to be on the same page.

The internet has leveled the playing field, and given everyone access to an endless stream of information, and means of self-expression.  In short, the government wants in on that.  Don't be fooled by claims of faster and cheaper internet service.  It's just a carrot.  Once we cede control to the FCC, we'll be at the mercy of its policies.  And do you trust it to "fairly" regulate use?  Do you think "undesirable" content will NOT be marginalized, if not completely banned?  I think we will lose our voice.  We'll go right back to pay-to-play, and "being served" preferred content.

Consider the argument that it doesn't make sense for companies and customers to foot the bill needed to support a few sites.  If porn sites, for example, use 30% of the bandwidth in the country, why should all of us support that infrastructure, if we don't watch?  Make the porn companies pay.  Makes sense right?  But what if I told you Netflix was the actual culprit behind 30% bandwidth usage?  Would that make a difference?  Who gets to make that decision, and why?  The point is, we already have a system that works for everybody. Regulation moves away from that.

I think this is an issue on which a very divided country can still agree.  Let net neutrality stand.  Our internet access is too important.

TechCrunch has a great article, if you're interested in learning more.

Using AWS Command Line Interface

For those of you who don't know, I’m a big fan of the command line and automation.  Obviously, implementing scripts incurs development costs, but once they are complete, the time savings are invaluable.  I was recently browsing Pluralsight when I came across “Mastering AWS Command Line.”  I was already preparing to download files from a bucket for a current project, so the timing was perfect.  Outside of a few small tasks, I’ve only used the AWS browser console.  I figured this was an opportunity to improve my productivity and learn something interesting.  It’s only two hours, so you won’t be a “master” after watching, but it is a good primer for working with the CLI.  AWS documentation is pretty good, so that’s all you really need, anyway. 

As we continue to move towards cloud infrastructure, AWS becomes a critical resource.  It's my new go-to for static assets.  Being able to quickly navigate, copy, and move files between directories/buckets makes life so much easier.  Some operations aren’t even possible with the console – downloading an entire bucket, for example.  If you’re not already using the CLI, it’s only a matter of time before it happens.  You may find this course a nice warm-up.

The CLI also enables automation, through scripting – which turns out to be a big deal.  Amazon bases its pricing on resource use.  With S3, that’s not a big problem; you’re essentially using the same amount of data no matter what.  Automating tasks isn’t going to save money.  That’s not true with all services, though.  With EC2 instances, for example, service management becomes necessary.  The most cost-effective methods require some form of automated monitoring, and starting/stopping services.  I remember a conference speaker telling us about receiving a $10,000+ bill from Amazon because multiple devs left EC2 instances running all month.

Anyway, I try not to let these articles get too long; I just want to share a few thoughts.  If you decide to check out the course, let me know what you think.

Martin Fowler Breaks Down Event Driven Architecture

A few weeks ago, I wrote an article on this year's GOTO Conference videos. I recommended checking out a few presentations. Following my own advice, I ran across this gem from Martin Fowler.  If you're new to design patterns, or interested in event-driven architecture, take a look. He does a great job of breaking down a pretty broad concept.

It's like "service-oriented architecture."  This concept gets thrown-around a lot, but what does it really mean?  Microservices is technically service-oriented, but it's very different from building a monolithic, single-server API.  The concept of event-driven architecture suffers from the same ambiguity.  So is my app "event-driven" because I rely heavily on DOM events, or is it a problem that I sometimes call an object's method directly, rather than triggering an event?

Fowler doesn't attempt to answer these questions directly, or create a concrete definition.  Instead, he distills the concept down to four main paradigms: event notification, event-carried state transfer, event sourcing, and CQRS (Command Query Responsibility Segregation).  For the details, you can check out the video; he does a much better job explaining than I ever could.  It's a 50-minute presentation, so he only touches the surface, but it's sufficient.

I walked away with the ability to communicate my architecture choices more clearly.  When using Backbone, for example, I'm creating an event-driven app, but only in the sense that it's dependent on event notification.  I'm not using event sourcing for state management, or CQRS for IO.  This means better documentation, less confusion with other developers, and better questions.

Remote Work... Denied.

I recently tweeted an article regarding Microsoft's curtailing of remote work - a terrible decision.  Employment trends should move the exact opposite direction.

This is especially true in web development (Microsoft targeted software developers).  I could go on for days... We typically work alone; pushing and pulling code requires open source tools, which can be downloaded to practically any computer; development files are typically small, so slow/shaky connections are fine; working from home minimizes meetings and distractions, which are nightmares for focused developers.  It should be a no-brainer - better for everyone.

Even the planet - I'm a tree-hugger, so that matters to me.  We reduce gas consumption and emissions, buy less clothes, eat out less - there are plenty of examples, I'm sure.  The point is that we need to be moving towards "green" solutions.

I try to keep these posts relatively short, but bear with me a moment.  I'd like to reference a book I read this weekend - The 4-Hour Workweek, by Tim Ferriss. It's considered a must-read by a few people I follow and respect.  If you're reading this, I assume you care.  Ferriss spends quite a bit of time imploring employees to seek remote-work arrangements - even quitting, if the boss won't budge.

I hope Microsoft and others reconsider this move away from remote work.

If you're interested in my thoughts on The 4-Hour Workweek; it lives up to the hype.  Tim definitely includes more stories and "resources" than I deem necessary, but he articulates his arguments well, and a lot of what he says aligns with my personal philosophies.  If you're into refining your priorities and living an "effective" life, it's worth reading.  I even finished the book quicker, by following his speed reading tips.

Check Out GOTO Chicago 2017

Interested in a good, "free" developers conference? GOTO Chicago has posted videos from this year's conference.  I'm a big fan of conferences.  I think they are a great way to stay abreast of emerging technologies and trends.

I attended GOTO last year, and had a great time - nice venue, great speakers, great content - worth the time.  I even met a cool developer there (shout out to Bill Brown at ColorfulSoftware.com - great guy).  I hoped to make it again, this year, but things just didn't work out, so I'm glad to see the presentations online.

It's interesting to think about the future of conferences.  Presenters and patrons want presentations posted online, but that pretty much defeats the purpose of attending.  I know... I know... the networking - I'll get there.  Lets just assume people quit attending.  Revenue drops (ads, vendors, registration fees, etc.) - making it difficult to afford spacious venues and "flash."  This, in turn, makes attending even less desirable.  Makes me wonder...

As for the networking - it's way less effective than social media, or local meetups.  For the time, effort, and energy you invest, I argue it's more useful to stay active on a popular social platform (Twitter, for example), and to maintain a blog.  Meetups are more frequent, and attendees are typically there for networking, as well.  They're more to-the-point, in my opinion.

97 Things Every Programmer Should Know

I recently finished 97 Things Every Programmer Should Know.  It's a little dated, but principles stand the test of time, right?  I think so.  I gave it a shot.  

It's a little long (200+ pages for essentially anectdotes), and I'm not quite sure how the authors' intended for readers to consume the book.  The chapters are too long for a daily psalm-like reading, but too short for any real analysis or depth.  In the end, it felt like a collection of short stories.  

Some concepts were really useful.  The "Coding With Reason" chapter, for example, was great - short, but loaded with reminders that helped me immediately.  "If you need a nested section, make it a function," for example - brilliant.  I forced myself to apply this principle for a few days, even when it seemed ridiculous, and I actually found my code was simpler, and fixing bugs, or changing functionality was a breeze.  

The "Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly" chapter came at the perfect time.  I was working on a project where there was conflict over the application's behavior under certain conditions.  We found that simply removing features (buttons), was actually a better solution than developing execution paths.  

I'll assume an exhaustive report, of every harvested jewel from this dusty classic, is unnecessary.  Overall, I give it a 7 (out of 10 whatever's...).  There were quite a few "confirmations" and interesting concepts that left me pondering, which is the book's biggest strength.  It's not a place for answers to technical questions.

I've made it a personal goal to read at least a book a month, so hopefully these posts will come more often.  Feel free to leave a recommendation.

Destroying Jobs Is A Good Thing

I just read an article, in the Seattle Times, about harvesting apples with robots.  In short, Washington is experiencing a shortage of farm-workers to harvest its fruit orchards.  Consequently, companies are racing to get contracts and sell machines.

Okay... so what?  Just another example of how technology is destroying jobs, and making it impossible to survive in this economy.  That's the narrative we consistently hear.  I mean, it's even directly in the article:

"The eventual loss of jobs for humans will be huge, said Erik Nicholson of Seattle, an official with the United Farm Workers union."

That's not good for innovation and progress.

This is where I think we, as IT professionals, have to frame the story.  We're not taking jobs.  We're changing the work people do.  I look at examples like this as one step closer to feeding everyone.  The purpose of technology is to improve lives, efficiency, and productivity.  If we can solve a problem, like world hunger, using robots, then shouldn't we do it?  The point of work isn't to be busy; it's to achieve something meaningful for humanity - to solve a problem.  If our food supply isn't an issue, which I think is a pretty good reality, then let us feed everyone, and focus on another problem - like scarce drinking water.  There aren't many things we need to survive, by the way - food, water, shelter, clothing, and protection.

The two gaping holes in my position seem to be: 1 - people "have to have jobs;" 2 - the argument that "my grandfather grew apples, my dad grew apples, and damnit, I should be able to make a living growing apples."  I'm not quite sure what to do about those types of concerns.  I think jobs should solve a problem, and as we solve those problems, we address new ones.  Don't support that neighborhood video store, when Netflix is better.

React or Aurelia?

After finally feeling pretty comfortable with Backbone, I've decided to move away from it. I recently attended a developer's meetup where we looked at Aurelia.IO. I like what I saw.  Further, technology is all about embracing the new.  Moving on to the popular new tool is just pretty much part of the IT spirit.  I was being resistant and holding on to what I knew most - terrible mindset for a dev.

So I was really impressed with Aurelia, but I know React is the popular kid, so I'm at a crossroads - which to choose.  At this point, the learning curve really doesn't matter; I've accepted it as part of the profession.  I'm more concerned about market value.  Aurelia could turn out to be the new cool kid, but maybe not.  That's a big concern for me.  I'd prefer to learn and build experience with an in-demand technology.  Right now I use Slim (long story) as a backend PHP framework, and it drives me crazy because everyone wants a Laravel developer - meaning my market value would be higher if I had built the same experience, just with a different framework.

If you're wondering why Angular isn't on this list, it's because I feel like it's the new Backbone/jQuery.  It's been around for a while, a lot of people/organizations use it, but I think devs will start moving on soon.  That's just my opinion.  I could be wrong, but you've got to make your own decisions in life.  Still, if you disagree, I would love to hear your thoughts.  I'm not stubborn.

So which should I choose?  Let me know what you think.

Why Write?

Unless you're a writer at heart, blogging is a pain.  It's not likely you're going to get rich, it can be hard to come up with content, and no one wants another "job" - at least I don't.  Yet, I'm back at this for the third time.  Why?

I do this to share and network.  I find it invaluable as a developer.  We have so much going on - tools and processes constantly change (Javascript... need I say more?), this is a really competitive industry, and most projects tend to be pretty demanding.  It's just really hard keeping up with everything.

"Social networking" (blogging, tweeting, Facebook posts, etc.), can help curate some of the information coming at us.  For example, a gentleman just reached out to me, this morning, about a CMS  platform his team is building.  I'm not in the market for a CMS, and I'm not even really a big fan of them, but he read one of my previous articles, and thought I might find it interesting.

It's not for me at the moment, but "my readers" are likely devs, with similar interests.  Some of you may be in the market for a CMS, and so I shall share this gentleman's product with you - Composr CMS.  Keep in mind that I've never used it, and only intend to try it the next time I need a CMS.  I'm not confirming that it's great, or terrible; it's just a platform that I've been recently discovered.  Let me know what you think, if you decide to give it a try.  Maybe it's a good alternative for all of you disgruntled Drupal users.  What a mess, right now...

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.

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.  

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.