Friday, July 28, 2017

Friday Challenge #4: Hack Troy's time for another Friday Challenge! This one is for a bit of a hacker for a day. Hack Troy Hunt's site. Don't worry it's legal, he invites you to do so. You see, Troy is a world-class security guru and set up the site to accompany his PluralSight training video - Hack Yourself First. You can learn a lot from him in this free course, so why not check it out!

And while your at it, pop over to OWASP and see what the top 10 web security vulnerabilities are. Spoiler Alert!!! The top 3 haven't changed in the last 4 years. Jeez guys...aren't we getting it yet!?!?

Friday, July 21, 2017

Friday Challenge #3: HTML 3-ways

Ahhh...web frameworks. What do they do for us? A lot! But do we really need them? Let's find out with this Friday Challenge.

This challenge has 3 parts (tip: try not to get too fancy and get bogged down on any one part).

Part 1: Build a web page with HTML and JS only (use some CSS if you like pretty things). The trick for this one is to use base JS only, no JQuery or anything like that. Do all DOM manipulation using JS only.

Part 2: Build the same thing (or refactor existing) using a templating tool such as Handlebars or for additional challenge build your own rudimentary templating tool.

Part 3: Build the same using a full-on framework such as Angular, React, Ember, Elm or whatever flavor of the day your feeling.

Build whatever you are comfortable with - a hello world if you wish. But if you really want to realize the value of the challenge - try something that interacts with an API that returns data (and handle the possible failure of the API call or no data response).

We do depend on frameworks for a lot. And yeah it's not always necessary to do so, but if you decide you'll have a go at not using one you may end up rolling your own. Depends on what you're going for...either way it's good to know what life is like on either side.

Friday, July 14, 2017

Friday Challenge #2: Make Your Own Mocks

Mocking frameworks are all the rage in unit testing - they can help you build out Mocks, Fakes and other types of Test Doubles. We don't strictly need them to create those doubles, but they sure do help! If you haven't guessed yet, this challenge is all about test doubles! (Classicists need not apply! JK, this is for you too 😁).

Two parts:

  1. Use a Mocking Framework and a Unit Testing Framework to create a fake data reader, pass that into a business logic unit and use it to fetch some fake data.
  2. Create your own fake and pass it into the same business logic unit and use that to fetch some data...can you implement the fake so that it can be set up with different fake values for different tests? Maybe start with the stub - static data returned from the test double (in that case it'll be a a stub).

Suggest using Mentor which has Mentees...and get the Mentees that have scheduled sessions. For an extra challenge, instead use two test doubles - the data reader and a notifier - use the notifier to "send" reminders to all mentees without scheduled sessions. You won't actually send the notifications, but need to verify that "remind" happened.

Thursday, July 13, 2017

Managing Complexity in Today's World






Back to the topic of deciding on a platform...


But whom should decide what the right tools are?





Wednesday, July 12, 2017

Video Series is a Go!

Good day! I've been thinking of doing videos as a companion to this blog for some time now (at least a year), and finally got that going! You can find the first video here or below. It has some tips and tricks on using Visual Studio more efficiently. Enjoy and subscribe!

Friday, July 7, 2017

Friday Challenge #1: Data Access

Today, I'm going to do a whole different kind of post - a Friday Challenge! Here's how it works: I'll post a challenge, you take up the challenge (usually by writing some code) and post the results or a link to the resulting repository in the comments. Discussions ensue. We share information. I'll put one up every Friday if there's interest. It's fun and engaging, what can go wrong? With that, here we go:

First Friday Challenge.

Your Quest is to write data access code using 3 different "patterns". I'll try to be a language agnostic as possible, the one requirement is to use a SQL based database.


In software there are many ways to perform the same functional operation, some are better than others when it comes to change, re-use, and readability.


You have a `users` table with the following columns: id IDENTITY/AUTOINCREMENT INT, name VARCHAR(255). You have the user's id and need to lookup the name of the user.


Given the following users:

|1|Marquart Flitshema|
|2|Loriens Blakens|
|3|Ashima Kithra|

When I look up a user with the id 1,
Then I should get the name "Marquart Flitshema".

When I look up a user with the id 3,
Then I should get the name "Ashima Kithra".


Pattern 1: Everything in 1 class/method/function (this is actually an anti-pattern).

Pattern 2: Pass the SQL and some mapping class/method/function into a different construct (class/method/function) to handle execution. Could be a base class (abstract or not), could be a prototype, any other construct will do so long as it is distinct from the construct that handles the SQL string and the mapping.

Pattern 3: Pass an entire construct into a different construct which handles the execution (by passing the database connection into the first construct).

Each pattern should be consumed similar to the following depending on language:

Pattern 1:

DataBase.getUserName 1.

 Pattern 2:

  Users.GetName 1


  Users.Get 1
(getName (dbQuery getUser 1))

consider the advantages and disadvantages of both approaches.

Pattern 3:

Db.Query UsersQueries.NameQuery 1



again consider advantages and disadvantages

Those are just examples in various language formats or pseudo-language formats. I tried to be inclusive, though I'm not as well versed in some languages (for a bit of language fun look up DerpCode). Feel free to use due dilligence such as null checking, exception handling whatever else you would like, but try not to muddle up the point too much with all that for now...don't let it get you off track is what I mean.

The code doesn't need to work completely, but if consumed by other code it should work (hint: you could use Unit Tests to drive the code and mock out the database but there should be some sort of `connect`, `open`, `close` and whatever else your SQL DB of choice normally has in the mock).

So that's it, the first Friday Challenge...go forth on your quest! If you need any tips, explainations, etc...feel free to put those in a comment and I (or anyone else who feels enlightened to do so) will do our best to get back to you as soon as we can. You should create a repo in GitHub, Bitbucket, JsBin, *Bin, someother online platform or whatever you do then share your work in the comments. Please don't link to file downloads, dropbox, etc...those aren't really for sharing code the way your should be sharing it for this.

Wednesday, July 5, 2017

What is Dependency Injection and Why Does it Matter?

While DI may be ubiquitous among most developers, it recently occurred to me that there are entire batches of newly minted grads entering the industry who, by and large, would not be familiar with the concept. Don't worry, you aren't the only ones! Although this topic has been bludgeoned to death by bloggers, I somehow feel the need to bubble it up here as well - sorry, it's a fun topic for me and I strongly feel that it's necessary to understand the principle. So if you are reading this and thinking - here we go again! Just give it a glance. But if you're like "what's this cool thing about?" or maybe still foggy on the principle read on and see if this doesn't clear things up.

I like to think about Dependency Injection/Inversion (DI) like this: A consumer should not be responsible for producing a resource that it consumes, the execution context should do that.

For a concrete example, consider the need to check whether or not a user is currently enrolled for mentoring. I'm going to be abstract in terms of implementation in order to make things a bit more language and platform agnostic (aside from the example being a web UI)...

We have some web site for managing mentor opportunities. Users who are mentors can navigate to the mentor page if they are mentors. If not a mentor, they cannot go to that page. Also, if they are not a mentor, we want to see if they have enough XP to serve as a mentor - if they do, encourage them to sign up for mentoring.

There are a few scenarios at play here so let's iterate those with specific examples:


| user   | XP    | is mentor |
| Tyler | 564   | yes           |
| Julie  | 8274 | no            |
| Jeff   |  128   | no            |

Scenario: User is a mentor.

Given user "Tyler" is logged in
When the navigation is shown
Then the user should see the mentors link.

Given user "Tyler" is logged in

When "Tyler" goes to the Mentors page
Then the Mentors page should be shown.

Scenario: User is not a mentor and is not qualified to mentor.

Given user "Jeff " is logged in
When the navigation is shown
Then the user should not see the mentors link.

Given user "Jeff " is logged in

When"Jeff " goes to the Mentors page
Then the user should be redirected to the home page.

Scenario: User is not a mentor and is qualified to mentor.

Given user "Julie" is logged in
When the navigation is shown
Then the user should see the mentors link, but it should be disabled.

Given user "Julie" is logged in

When"Julie" goes to the Mentors page
Then the user should be redirected to sign up for mentoring.

Given user "Julie" is logged in
When messages are displayed
And the user has not accepted the offer to become a mentor
Then an invite to become a mentor should be included in the messages.

Scenario: User becomes a mentor.

Given user "Julie" is logged in
When the navigation is shown
Then the user should see the mentors link.

Given user "Julie" is logged in

When "Julie" goes to the Mentors page
Then the Mentors page should be shown.

That's a lot of description, but it's worth noting the various scenarios in this example. But now back to focusing on the DI part...

So we have a module (note: I'm using "module" to express a class or function or whatever the unit is called in whatever language you use) for each component of the website -  the navigation bar, the mentor page, the mentor signup page. Those modules each need information about the user - is the user a mentor and can they become a mentor. Let's make a User module - one that can be passed into each web module and which can answer those questions. . Let's see how that would look:

        isMentor() : boolean
        isQualifiedForMentor() : boolean
        becomeMentor() : boolean

        getLinks(user) : links



The User module would be passed to the web modules by the request context (usually in the web framework) - the same thing that initializes the given web module.

So, something in the web request process will authenticate the user, load the user data, and pass the user details to the web page module as a User module. That User will be used to answer questions for each module that depends on it.

Notice what we are not going to do here - we are NOT going to call the database from within authorizeUser(), getLinks(), or signup()...those are details those modules simply should not care about! What they care about is whether or not the user is a mentor or is qualified to be one. Even the Signup page doesn't care about HOW to sign up the user, it just needs to direct something else to do the actual signup.

A level deeper...

The User itself could have some dependencies. Let's say the User needs to send a message to some signup processor - perhaps to a message queue so that the signup processor can pick off the queue and process at it's own pace (so the user won't have to wait for processing to complete).

Let's say at first, it handles the signup right there in the web process. Now let's say the site scales massively and running the signup process within the web processes impacts all users of the site due to the additional load on the web servers - we would want to offload that process. When we use DI, we can change the way the User handles the signup without changing the consumer (the User module).

    internals/private members/curried functions:
    public function:
        becomeMentor() : boolean
             calls _mentorSignup -> signup(user_id) or signupForMentoring(user_id)

Whatever happens when a user signs up is passed into the user module by the module that constructs the entire web request handling process (or whatever consumes the User for that matter).

The MentorSignup dependency (the one User is depending on) can either handle the signup itself OR pass off the signup to some other process that runs asynchronously so that the current process can continue execution without delay. It can be changed without touching the User module or any module that consumes User (theoretically).

A goal in good system design is to produce product that can be changed at a minimal cost - because software is soft (malleable, changeable).

In the case of changing the MentorSignup module, it's an ideal situation to be able to change the implementation without changing the consumers. However, there is one problem - if the MentorSignup module is consumed in a way that the web modules need to be recompiled or the MentorSignup module would need to be replaced in those modules in some other way, then we haven't achieved the ultimate goal. We are coupled architecturally.

Instead, we could have some communication between the web process and the signup process using a common interchange protocol such as HTTP and a mechanism to tell the signup process that a specific user would like to sign up to become a mentor. That's getting in a bit deeper than DI so I'll back off a little...

So here's what we have now: web modules, a User, a MentorSignup module, and something to build it all up and pass those dependencies in (MentorSignup into User, User into web modules).

We can do some interesting things with that - we can create some fake User code that gives us pre-defined answers so that we can build and test the web modules without depending on all the details of how a User is signed up, how user data is stored and retrieved, etc. We've decoupled the web modules from the dependency on the user data.

How else could we do it? Let's say we started out with the user data in a db and coded everything into the web modules directly:

        lookupUserLinks ... open a db connection, run query, map results, close connection, use results

        authorizeUser(user) ... open db connection, run query, map results, close connection, use results

        signup(user) ... open db connection, excute email...send email...close db connection...close different db connection....execute another command...close different db connection...etc

For one thing, we have a lot more room for errors...then duplicating errors. Another, our web modules would be difficult to understand - what does all this db code have to do with redirecting a user??? Ok you let's pull that out an put it into a User module, call up the user module to run the code...

        lookupUserLinks ... create User module...use User module to query (get user)...use results

        authorizeUser(user) ... create User module...use User module to query (get user)...use results

        signup(user) ... create User module...use User module to query...use results...create Email module...use Email module to create and send email

At least the "goo" is centralized and has some re-usability - we no longer have a copy and paste scenario. But now we're still coupled to the specific User module that the functions know about directly! So we can't change those without changing the web modules - we can't do cool things like swap the User module on the fly or in test scenarios!

Now we get into programming to abstractions...we've already abstracted the details somewhat, but we've got this wicked coupling to only one specific implementation. So let's level that up and program to an abstraction...

For the purpose of building the web module, we don't care about the details of how to get the user, we don't even care that the user was got at all! What we really care about is that we have something to tell us certain things about the user and something that will sign the user up for mentoring. That's the abstraction we care about. We'll get into the details of implementation later in the development process - regardless of what those are, this thing should still work as described above in those Scenarios.

An important note on abstractions - they can leak! While we may only care logically that the user is a mentor, we also care that finding out does not take ages...if it did, that would be a leak in the abstraction! We really want to find out almost immediately when that block of consuming code runs - therefore we may want to load up all the user data BEFORE the web page is shown to the user. And of course we know this needs to be done quickly as well so we'll have to consider that in the implementation of the User module.

Now that we've gotten this far and (hopefullly) you can see how DI and many other fundamentals (programming to abstractions) are important to producing good software, let's take a look at one of the primary benefits of having done so...testing.

Now that we've designed the system in a way that depends on abstractions whose implementations are injected, we can swap out the implementation. For each of the defined scenarios described waaay above in this post, we can create a User that gives the pre-defined responses and exercise the code without depending on complicated - one-time only, db interactive - test setups.

We can have a setup for the first Scenario similar to:

MentorUser : User
    isMentor(): true

NonMentorNotQualifiedUser : User
    isMentor(): false
    isQualifiedForMentor() : false

NonMentorQualifiedUser : User
    isMentor(): false
    isQualifiedForMentor() : true
    becomeMentor(): true

Well, there you have a whole set of subtypes all based on the User with only isMentor()! Of course each has its own's own domain...we could further break those down to become specific dependencies of each web module, but that'll be enough detail for now...

think about the DI principle and other scenarios where you may want to swap some dependency based on context...connected to internet v not connected, testing v production, logging per environment, exception handling per environment, multi-tennant apps...just to name a few.

If you've now come to understand the DI principle then you've gained some valuable XP! Next you'll probably want to exercise the idea...look for something soon that'll help with that (hint:subscribe now to see what happens on Friday)!