Wednesday, January 17, 2018

New Tools for the Toolbelt

If you’ve never heard of Chris Hawkes, check him out. I listen pretty regularly. Like a lot of guys you find on YouTube, most of his content is geared towards new developers. He still manages to slide in a few advanced topics, though. Be warned: if you’re sensitive to profane language, he may not be for you. He can sometimes be vulgar. It doesn’t bother me, though; I find it funny.

Anyway, I was listening to "Is CoffeeScript Dead In 2018?," and he made a good point - the gist of which was to be strategic about where you invest your learning time. In other words, don’t feel pressured to learn the newest technologies, as soon as they come out. Sometimes it’s better to just wait. He uses CoffeeScript as an example. Apparently it’s dead.

I’m relatively new to development (3.5 professional years, at this point), and haven’t worked on any CoffeeScript projects. As a result, I don’t know much about it. I am preparing to adopt TypeScript in a coming project, however, which is a similar technology. For those unfamiliar, TypeScript basically adds data types to JavaScript. After watching Chris’ video, however, I started having concerns. TypeScript requires a dedicated maintenance team. What if that team dissolves? What if Microsoft goes proprietary? What if a better implementation of data types is already in the works for a coming release of JS? Crazier things have happened…

I shared the video with a colleague of mine - a guy I trust and respect - who is in the TypeScript-is-fine camp. He allayed a few of my concerns, but he’s still a relatively young guy. He hasn’t had time to see an industry evolve. I have. I’m now a developer because of “industrial evolution.” Forgive me if I lack faith. At the end of the day though, I agree with him: TypeScript likely has a bright future. I should probably move forward with it. But Chris’ words of caution have not fallen on deaf ears. I get the point: adopt new technologies cautiously.

What do you think? I’m sure you’ve noticed how fast technologies are changing. I mean, who was talking about React, five years ago? Now you can’t get job unless you know it… Are you a slow-adopter, or think it’s vital that developers stay up-to-date with the latest and greatest? Drop a line.

Thursday, January 11, 2018

Where have I been?

Doctors playing my game.  
It has been a while since my last post. Some of you may be wondering what’s up with that. Well I’ll tell you: I’ve been working - working hard. My company recently had a big event, and it was all-hands-on-deck. We were at it full-throttle, for a few months. I managed to squeak out a few articles, in the beginning, but then the workload became too much. One of my applications was in the show. I had to focus. Everything went very well, though! Doctors from all over the world played my game; I even saw them taking pictures beside the screen. I’m still elated!

Since then, unit testing has consumed much of my time. I currently have a few projects on my plate, and they all need tests. I know, I know… I should have written them first. Well, I’m new to this, and deadlines are real. Writing had to take a backseat, while I learned the Jasmine framework, and how to properly implement consistent, fast, accurate tests. That’s definitely more than a month-long process; I still have plenty to learn, but I’m making progress. And I like the results. The first unit tests I ever wrote were on the backend (PHPUnit), and weren’t really good. I learned a lot, though, and much of it transfers to what I’m doing with Jasmine. I find the confidence from testing, and ability to skip the browser (I use Karma to run tests), are worth the extra effort. I plan to make this a permanent change in my workflow. Maybe I’ll elaborate further later, but for now, I just wanted to give you an update on what I’ve been doing.

I plan to continue writing; I find it helps me better understand development. Furthermore, I write for developers and dev teams. My hope is that these posts eventually lead to fruitful discussions that help me become a better developer. Lets see what happens...

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.