Develpreneur: Become a Better Developer and Entrepreneur

We have run a weekly gathering for the last few years that is called our mentor and mastermind group.  This is a resource we rarely push.  However, it is an invaluable tool for anyone that wants a little help or a nudge to keep them moving forward in their career.  If nothing else, this is a great way to hear about the experiences of others in the industry. Changes to the Mentor Program The big non-change going into 2019 is that we will keep the program free.  Donations are always welcome, but there is no cost to attend.  We even have some swag for those that make a couple of meetings.  Each session will also continue to be recorded, and those recordings are available to everyone that signs up to attend.  You can watch or listen to these at your convenience. The significant changes this year are a switch to twice a month instead of weekly and the difference in duration.  We started to keep the meetings down to an hour and a half last Fall.  That has worked well and will continue.  The first thirty minutes will cover the mastermind tasks of pushing each other forward.  The last hour will be a mentor focused presentation and questions and answers session. This year will also see the addition of a Trello board to help members review how others are doing.  It is a little more accountability and a way to keep us close even while reducing the number of meetings. Keeping The Good We have found the goals and nuggets to be highly useful and informative.  Therefore, we will continue to keep these on the agenda.  They are not mandatory, but it is recommended to contribute as that seems to be as much benefit to you as it is the team.  The presentation from each meeting will continue to be edited for our Vimeo channel (https://vimeo.com/develpreneur).  Check this out regularly for the latest published sessions. If you want to learn more, you can read the page on the class at this link: Mentor-Mastermind Class

This episode covers the new book "The Source Code Of Happiness" that is our first Develpreneur published work.  It contains a lot of ideas that we have discussed in blog posts over the years.  On the other hand, it ties things together and has a few new stories and suggestions as well. The Source Code of Happiness Of course, the book implies that reading it will help you find happiness.  I will add a spoiler because you already know this.  The way to true contentment and happiness is to find a job you love that will always keep you challenged.  Guess what?  A technology career can be a perfect fit.  That is not the case for everyone.  However, those that like to follow this podcast and site are likely in the group that finds IT a perfect fit. More Than a How-To The book does not just provide a laundry list of tasks to do.  There are some stories of success, failure, and points in-between.  There are also recommendations on how to get those tasks done while balancing everything else that matters in your life.  The examples will give you some food for thought and also some tricks and tips to help you get the most out of your efforts to advance your career. Don't take my word for it.  Go ahead and check the book out yourself.  You can even read it for free on a Kindle.  https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R  

We wrap up the season with the observer pattern and a review of what we have learned.  This pattern is one that you probably have already encountered.  Instead of an observer, you probably have heard it called a listener. The Observer Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." Thus, the observer pattern is precisely what the name implies.  You assign an object to an observer, and when something changes in the observed object, the observer is notified.  The key to this is that it is a one-to-many relationship where an object may have zero or more observers.  The observed does not care about the observer; it just knows to keep that instance "informed" of changes. Applying The Pattern This pattern is another one that can end up producing two hierarchies.  The observer hierarchy will likely start from an interface and then can be extended.  We can add actions to the observer pattern or adjust the signatures.  An action or notification may send a value with the notification but does not need to do so. The observable object will also start from an interface.  It will likely stay shallow if it is extended at all.  However, you may have some different action/notification options or more than a simple register and de-register method for the observers.  There might also be security or authentication required as part of the observer process. Java, PHP, C#, etc. This pattern sticks to the core features of a language.  All you need to implement this is a base class (probably an interface) and support for inheritance.  That leaves you almost identical implementation approaches in whatever language you choose to use.

The visitor pattern is the last of the behavioral ones for us to review.  This is going to feel similar to some others that allow us to abstract functionality such as a command.  This one provides us with a way to group functionality and avoids duplication or even sprawl of our code. The Visitor Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Represent an operation to be perfomed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates." Simply put, this pattern allows us to abstract and group functions that we will be performed on a collection of objects.  It is almost like a compliment to an iterator.  Instead of giving us objects from a collection (as an iterator does), this one goes to each object in the group.  At each stop along the way, it performs an action or actions.  A simple example is a print method.  You can put a print method on every object and use an iterator to cycle through a collection so you can call that method.  On the other hand, you can define the print method on the visitor object and give it a collection of objects to traverse and execute the action. Applying The Pattern This pattern ends up producing two potential hierarchies.  One is to describe the node interface (the objects we will perform actions on).  The other is the visitor hierarchy.  A node can start as an interface with a way to progress to a next node.  Then the visitor can perform an action or more as well as varied actions. Java, PHP, C#, etc. This pattern sticks to the core features of a language.  All you need to implement this is a base class and inheritance.  Therefore, the only differences among languages are going to be minor syntax variations to note what needs to be implemented or overridden in the child classes.

In the last episode, we looked at abstracting algorithms.  Now we examine the template method pattern and how it allows us to abstract steps of an algorithm.  Thus, providing a template for implementation while leaving the freedom for subclasses to handle the details. The Template Method Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure." This is a rather simple pattern to understand.  We build a root or base class that lays out the steps of an algorithm.  Then we leave some (or all) of those steps to be implemented in subclasses.  Note that we will usually implement some of the steps in the base class to avoid duplication of code.  These steps performed in the base may also provide context and constraints for the subclasses to conform to. Applying The Pattern As noted above, most of the time this will start with a base class and some of the steps implemented.  However, that is not a requirement.  You could also start from an interface, but then it may make more sense to stay a little more flexible and use a strategy.  In any case, the concrete part of the implementation will be wrapped up in the subclasses.  This allows you to follow the same steps for the algorithm but do so in varying ways.  A typical application of this pattern is a text processing algorithm that "cleans" data as it goes and has very different work to do in cleaning a date, a street address, or a phone number.  However, this is a pattern that has such a broad number of uses you may easily see it turn up in almost any algorithm. Java, PHP, C#, etc. This pattern sticks to the core features of a language.  All you need to implement this is a base class and inheritance.  Therefore, the only differences among languages are going to be minor syntax variations to note what needs to be implemented or overridden in the child classes.

Our review of the behavioral design patterns moves on to look at the Strategy pattern.  This is one that you might not recognize from the name.  However, it is relatively common in use (or at least it should be). The Strategy Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it" Some people start to hear static when the word algorithm is used.  It seems too theoretical and does not apply to a practical approach.  Unfortunately, that is the core aspect of a strategy.  There is a process you are following, and you want to abstract that to make it easy to apply the exact method (algorithm) for the proper context.  The example from the book that is probably familiar to you is handling the line feed for a bunch of text.  You will use a different value for raw text, HTML, XML, RTF, etc.  Thus, a strategy for a line feed allows you to create a handful of solutions and then plug them as needed for a given type of content. Applying The Pattern When it comes to implementation, the strategy often starts with a root or base class.  That might even be an interface if there is no need for core functionality among the strategy classes.  Then each concrete strategy class will inherit from that base class.  This provides the interface to call or execute the strategy while allowing us a variable number of ways to implement it. Java, PHP, C#, etc. Although the implementation can get a little complex for this pattern, the syntax and language support is minimal.  An interface and inheritance are nice to have, but you can get away without an interface in a pinch.  Therefore, an example of this pattern that you can find will likely be easy to translate to any language you want for implementation.

We tackle the memento pattern in this episode.  If you ever wanted to store the state of an object, then this is the one for you.  You can think of this pattern as a way to take note of your instance and store it for later. The Memento Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Without violating encapsulating, capture and externalize an object's internal state so that the object can be restored to this state later." The trick to this intent is to avoid violating encapsulation.  The whole point of this pattern is to allow us to store and pass around the memento without having to keep track of the ways and places it is used.  Thus, proper encapsulation will enable us to keep the memento object self-contained outside of the knowledge it requires of the classes that use it.  Of course, that brings us to an essential part of this pattern.  It can sometimes be used to store the state and context of several types of objects.  Therefore, it does not have to be a one-to-one relationship.  Even the caretaker classes can be used to handle a large number of memento types when correctly designed. Applying The Pattern In most cases, you will want to start with an interface for the memento.  That will give you a signature that the caretaker object will use to handle the memento objects.  Then the memento itself is going to implement that interface.  You might even have a hierarchy of them to progressively store and transfer more details (properties) of the objects they work with.  Therefore, you will find access level restrictions along the lines of a friend or package level tend to work best. Java, PHP, C#, etc. This is one of the few patterns that can be implemented very differently depending on the language you are working with.  In particular, the languages that have a friend or helper concept built into them are going to have better-looking implementations.  This improvement is because implementing this pattern falls into that category of relationship.

In this episode, we look at the state pattern.  It is a design that uses object-oriented tactics to provide a class with very different functionality based on its current state.  I think you will find this to be one that is not often going to be evident in your first pass of a design. The State Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Allow an object to alter its behavior when its internal state changes. The object will appear to change its class." We have not had many cases of helpers or partner classes in the patterns we have explored so far.  This pattern uses a primary (context) and concrete class (state) to help you organize instance states under one umbrella.  The examples vary, but the most familiar one is likely a connection (network, database, etc.).  In these cases, the connection class has an internal class reference that varies by state.  Thus, the implementation behind a method call is passed through to the state class to provide the needed flexibility. Applying The Pattern The implementation of this pattern is not too complicated.  However, the access/encapsulation piece of the pattern is something you should think through.  You probably do not want to create a state that is entirely open, that would likely limit its usefulness.  The typical approach to a state is to start with an interface and then extend that to concrete implementation classes.  Those implementation classes are what is used to assign a state to an object.  Instead of the state being an integer or string code value, this pattern is where we assign an object as the state. Java, PHP, C#, etc. This pattern again works the same in almost any language.  All you need to do is create an interface and then inherit from it to implement the concrete classes.  This sort of approach is supported in all modern languages.  Thus, your challenge will be designing it properly rather than language support.

The number of conference solutions available out there can be overwhelming.  A large number of them are free or close enough that it can make deciding on a solution a difficult task.  Thus, we want to look at the well-known and well-supported solutions that fit our price range as well as the features we should look for in an application.  Even if you only need to use conference solutions a time or two a quarter, this list will help you find a platform that matches your needs. Amazon Chime Among the AWS services is a conference call solution called Chime.  This has a thirty-day free trial as well as a free option where all members pay call fees.  It is an excellent solution that provides desktop clients across a broad range of platforms.  We use this solution for our mentor sessions, and I have used it for consulting a large portion of the last few years. Free Conference Call As the name says, this is a free conference call solution and works well.  The desktop sharing tools and ability to give attendees a feel of this being a high-end solution are not what one would hope for.  However, the cost is hard to beat, and that makes this a perfect solution for an ad hoc call requirement. Goto Meeting This is arguably the best-known solution on the list.  Goto Meeting has been around for a long time and has developed some very high-quality tools for the desktop and web clients.  It is one of the more expensive solutions ($14/month or $29/mo to get record and transcripts).  However, it is a platform that will give your customers/callers a comfort level with the tool and your professional approach. Skype For Business Skype has been around for years and is a robust VOIP solution.  The "Skype For Business" product was created when Microsoft bought Skype and merged the legacy product with the Lync product.  The result is a pretty good and often used solution.  I have had a lot of headaches with this over the years, but they do seem to be getting fixes in regularly, and stability has improved.  At $2/per user per month, it is practically free and often bundled in with Office 365 subscriptions. Zoom The top conference solutions products often include Zoom in the list.  It is quick and easy to use along with some reasonable pricing (free or $15/mo to add recording).  The free option is another perfect one to use if you have to quickly set up a conference call and do not have a subscription with one of the other providers. Webex Much like Goto meeting, Webex has been around for a long time.  They have made good improvements over the years and created a solution you can trust.  I have not seen it used as much in recent years, but that may just be my experience and not a reflection of the tool itself.  It does the job and should be considered if you are going to step up above a free solution.  It runs $19 per month per user. join.me The name recognition of this product makes it another one you will likely run into for conference solutions.  The pricing and positioning make this a much better solution if you want high-quality communication and sharing for a small number of attendees to your calls.  It starts with $10 per month for up to 5 people on a call or you can step up to $20 to add recording and 50 participants per call. Uberconference I often run into this solution in situations similar to freeconferencecall.  It does provide for recording with a small number of users (free record and up to 10 attendees, $15/mo/user up to 100 attendees) and it scales up to a large number of attendees well.  It is a newer product, but I have no complaints in my experiences with it.

We spend this episode looking at the mediator pattern.  This is a pattern that provides a great deal of flexibility.  However, it is not used as often as it should be.  The implementation does not always lend itself to a mediator.  Instead, the design needs to be thought through enough to create one. The Mediator Pattern Defined As always, we will start with the "Gang of Four" intent to set the stage for our discussion. "Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." It may be most comfortable to think of the mediator as a pattern that creates a communication hub.  This approach allows you to have a group of objects that interact without them needing to know about everything they communicate with.  This can simplify your interfaces while making it easier to manage all of those interactions.  Instead of the code being spread through several objects, you can control the flow in a single class. Applying The Pattern In most cases, you will want to start with an interface for the mediator.  This provides the input signatures that classes can use to take advantage of it.  Then a concrete class should be created to implement that interface.  It will also provide the logic for the various interactions.  When a class is instantiated, it will register itself with the mediator.  Once registered, an instance will send information to the mediator or be transmitted data through that same mechanism. Java, PHP, C#, etc. This pattern again works the same in almost any language.  All you need to do is create an interface and then implement the same.  This sort of approach is supported in all modern languages.  Thus, your challenge will be designing it properly rather than language support.