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.

Monday, May 29, 2017

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.

Saturday, May 20, 2017

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.

Thursday, May 11, 2017

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.

Sunday, April 30, 2017

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.