development

Recently, I read Codifying devops practices, a blog post written by Patrick Debois. This is food for thought. I spent some time trying to identify the patterns I recognize in daily practice. I may continue to update this as I learn more opportunities and categories. Approached with a build-measure-learn philosophy, patterns are less about the "how" and more about opportunities to improve and grow. These opportunities may be considered best practice, but are circumstantial based on your organization, your project, or other factors. I personally advocate addressing the most glaring problems

BackgroundI recently changed companies and am going through the process of onboarding. One of the big draws to the new company was an emphasis on people and culture. The whole balance between a for-profit business and a focus on employee needs, in my experience, can be in conflict. I have been learning more about how these goals are achieved. In some onboarding documentation, there has been a reference to "The Agile Manifesto". A swift Google search, let me to this page. The core values are defined as follows:Individuals and interactions over processes and toolsWorking software over

I recently had a difficult situation in which I could not debug a hanging Simpletest in Drupal 8. Before continuing on, add the dblog module as a dependency to the Simpletest you are writing and rerun it. Your test may be hanging because it cannot write to the error log. If it continues to hang, read on. Hanging test with no outputWhen a test hangs, there are no signs of life. It leverages Drupal's Batch API. The screen just sits on a progress bar of death. This process continues to run indefinitely and then causes performance issues. When running the test, it will never leave the batch screen

I personally believe cut-and-paste coding can be one of the sloppiest and least reliable ways of developing a product. Consider the source. After teaching Comp Sci for several years, I can confidently claim that this is the worst type of coding. Most of the cut-and-paste code comes from the web. Someone goes onto Stack Overflow, slaps in variables and values to meet their use case, and commits their change. Consider the source! You have no idea who posted the code, the merit of the code, or if it follows best practice. There is often a ton of metadata missing as well, e.g. the supported major

I was recently asked about what separates my company from others I have worked in the past. What immediately came to mind was the relationship with my team, the work we do, and the sheer talent. Those elements alone still make me get up in the morning. But, over a cold beer, something else struck with me. My company has no routine and I love it. Let me Google that for youYes, this may set you back initially. Routine typically has to do with schedules or habits. But, what I am referring to is very much about our culture. We're a newer company that is still applying polish to our offerings

Estimations suck. Seriously. To do estimations properly, it requires significant analysis and a sound grip on the full project scope. It's hard. There are always unknown complexities that creep up. Estimations set expectations and impose risk when complexity is not identified. Covering RiskThere are a couple approaches people use to balance estimates with risk. The fixed percentage model just adds a near arbitrary percent on top of a given estimate for known complexity. While this is fine, it doesn't excuse a lack of effort to try to determine what the estimates should be. Another is

Companies are very bottom line focused. Even after a high level scope of work is determined, the most appealing bids often are on the lower end. Even if some form of a deliverable can be achieved in a given number of hours, it often does not yield the correct one. Smarter bids allocate more time for damage control, error correction, and proper testing. For low bids, especially really low ones, one has to wonder what part of the product suffers. Most places I have worked have emphasized ethics and client success over the written contract. And, honestly, this tenet is part of my moral fiber. I

If you're doing Drupal development, having a local sandbox is a necessity. Why? No one should be making untested changes on a production or staging server. And, a development server should be free of initial development errors where the developer should execute a small set of engineering tests before deployment. Plus, it can be time consuming to regularly deploy code developed locally onto a development server. To summarize: a local sandbox is absolutely best practice. I hope to summarize how to quickly get up to speed without having to rehash the lessons I have learned. DisclaimerThis blog

Rands' recent blog post Busy is an Addiction struck a chord with me. It's made me rethink many aspects of my day-to-day routine. Work Smarter, Not Harder It's so easy to say, I'm busy. In reality, I should be working smarter, not harder. Busy is as much of a state of mind, as it is the items on your plate. It's a routine, a lifestyle, and a shitty excuse. If you fall into the busy pattern, I personally believe it's easier to make mistakes. Your pace is more frantic, your getting pulled in thirty different directions, and you really don't have the time needed to pay attention to what your doing

In a previous job, I had a boss that I really admired. He's near the end of his career and his experience had made him wise. He was humble, but would chime in as needed. One of my favorites was his ability to bust out short one-liners that would hit the nail on the head. Around the water cooler, we regularly discussed open source. Here are some highlights: Free like a puppy This one always made me chuckle. But, it's true in so many ways. I look at the open source community. At times, people's evaluations of open source tools are skin deep. "Ah, they are free!". This typically follows two