Saturday, August 26, 2017

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. 

Saturday, August 12, 2017

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.

Tuesday, July 11, 2017

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.

Thursday, July 6, 2017

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.

Sunday, June 4, 2017

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.