Quick update…

Hello everyone; wanted to check in real quick and keep everyone update. Still on vacation and loving it. However; I did see the uptick in visits and wanted to thank everyone for signing up to the subscribers list! I am very happy you find my content helpful, if not even intriguing. I’ll be back soon with more tech related content.

Thanks again!

Yii2 and bower/asset: jquery.inputmask AfterAction report…

So last week Im working along and I run composer install … to get a new framework installation to while trying to track down a bug. The install fails. I am all like ‘what did you say to me!?’ bower-asset/jquery.inputmask package was not being found. I look through the composer.json of the framework and sure enough it is required. A frontend client asset is required to install a framework. While some would say ‘thats a terrible idea’ in this case it makes sense. The framework is a full MVS stack, not just a middleware, or just a ORM, or just a client rendering engine.

Anyways, after looking in Packagist and following the link to Github the repo itself was basically empty. Apparently GirtHub repo alias’s have a life span limit. This limit had expired and thus caused the package URI to no longer resolve correctly. So I submitted a couple tickets on the respective projects and went home.

Not sure how long it took exactly but when I returned to work the next morning not only GitHub restored the alias but the framework group was going to updated the dependency list to point to the (newer) repository in the next point release. While this does not seem like a big thing to some; I felt happy I was able to find, isolate, and identify an issue that effected a number of people; and did so very quickly. Then provided a solution. #problem-solver


Related Links:

Packagist: jquery-inputmask
Yii2 GitHub ticket

ComposerCat (beta)

(Preface: I am a full supporter of CLI tools, UI tools are nice but should not be depended on for day-to-day workflow).

Came across this interesting UI tool from NomadPHP‘s weekly mailer. ComposerCat. It visually displays the contents of Composers composer.json and installed packaged. It’s in beta but looks to do everything it says on the tin. Check it out.

The Importance of Interpersonal Communication (re-posting)

(This is a re-post from my blog post for Sourcetoad back in March ’17.)

As we tend to spend 30% of our lives in close proximity to other human beings it is important that we attempt to keep not just our professional skills sharp but also the skill of communication. To be able to articulate what we mean to say clearly and holistically is a cornerstone of good teamwork. Without good communication no team can succeed.

When speaking with fellow team members many factors come into play. One the speaking sides word choice, tone of speech, body language, and even facial expression can influence the receiver’s perception of what is being stated. Let’s take the example phrase ‘I am doing great today.’ Without context the phrase is simply a statement; say this phrase a frown and it becomes a sarcastic statement. Say the same phrase slow tired voice and it could easily be considered irony. While these two examples are extremes they help to prove the point that it is not always what is being stated but how it is being stated.

Expounding on the `how` a given statement is positioned; let us imagine every day we arrive at our place of employment, every day you ask the same peer ‘how is your day going’, and every day that peer answered with ‘as good as it can’. While the statement itself is not very clear the tone of voice, the energy used to state the phrase, and the body language of the peer are all context clues as to the true meaning of the phrase.

As we get familiar with our peers we can gain insight into the person, mannerisms, typical behaviors, and average attitude. Thus when communication with our peers gaining insight into the meaning behind the phrase. However, this path of contextual knowledge and interpretation can take a large amount of both time and effort.

In my opinion needing to gain intimate knowledge of an individual’s particulars is, in general, a waste of effort. I am not saying do not get to know your peers, the opposite in fact. But when it comes to explaining abstract ideas, concepts outside of areas of expertise or even humor, being precise and clear about the stated subject matter eliminates misunderstandings. I like to belong I am not the only one who has made a statement only to be misinterpreted and it causing issues down the road. Being clear prevents repeated effort and the need to start over on whatever the given subject or discussion is.

In the end it is important to remember that when we communicate with the people we spend upwards of ⅓ of our daily lives with we need to try our best to be clear, precise, and as well mannered as possible.

Going in circles…

…ever try to write something when your brain is not firing on all 8? I recently had all of my wisdom teeth pulled during the same visit to the Dentist. During the recovery I tried to bang out some code Needless to say if you can/are not able to focus and concentrate; very little progress is made…

Days tip: Do not get overly dedicated to a task if you head is not in it game.

Shameless Self Promotion: Presenting during Tampa Bay PHP’s May meetup!

Using Codeception for Acceptance testing

Tuesday, May 30, 2017, 6:30 PM

Sourcetoad’s new location
2901 W Busch Blvd #1018 Tampa, FL

9 Members Went

David Eddy will present “Using Codeception for Acceptance testing: the crash course.”

Check out this Meetup →


Update: Video is up on youtube at https://youtu.be/QXSP0bEpF4Y .

Always plan on something going wrong…

Anyone who has sat through the process managing a project know, whole heartedly as a fact, no matter how much something is planned and scheduled something else will always go wrong. Believing this as fact one should never, ever, plan a time line or effort estimation based around everything working as planned. Planned and working are so far removed from each other the relationship is vague at best. No matter how many times we build the same CRUD application or data pipeline, or CI/CD process; always leave yourself some buffer time to correct unforeseen issues.

As a general guideline the less I know about a requested change the higher my effort estimation; almost geometrically. As an example:

  • 80 hours to write a single data object CRUD UI
  • 40 hours to write a single data object CRUD UI  with defined fields & validation
  • 20 hours to write a single data object CRUD UI  with defined fields, validation, and user story documentation
  • 8 hours to write a single data object CRUD UI  with defined fields, validation, user story documentation, and visual mock ups of the expected UX

Now at some point I hit a floor where effectiveness just simply keep up with the continued reduction in effort. But at that low of an effort estimate we are basically wizards doing magic as far as non code people are concerned.

Some people will  responded with ‘but estimates that high scare away clients’; This is very true and factual. However, my response is this: do you really want to work with a client who has not clear answer or concepts of what the results of the effort should be? Think `moving goal posts` but not having a goal post to begin with.

TL;DR: Always buffer your estimates, even if you know everything that needs to be done.