When you are building a tool, how do you measure the success of your efforts? There are data driven approaches around adoption, like number of times your tool has been downloaded or installed. Similarly, success could be defined as how effectively you solved the problem.
As a bit of background, my main objective is to integrate Drupal coding standards into PHPStorm.
Drupal 8 has been widely praised for improving the developer experience (DX).
I'm a big fan of Field Collections. It provides a high level of flexibility in setting up an auxiliary (and potentially shared) data structure that can associate with another entity. As such, it's a highly customizable way to do relational data in Drupal.
I recently made a pass through historic downtown Altoona and I noticed how many buildings appeared to be empty. It actually occurred to me that my definition of infrastructure has shifted radically from the conventional infrastructure companies have adopted.
I thought I'd play around with creating this feature in Drupal 8. Here's the step-by-step run down. This is assumed your logged in with an administrative user.
I'm not one to really dig my heels into politics. I find it divisive and I recently had a clear example as to why.
Site updates in Drupal are one of the most critical, proactive things needed to eliminate vulnerabilities on your site.
I long struggled with how to effectively do local development in Drupal. Few would argue the merits of doing local development over working directly on a production system. While the problem seems straightforward, nothing seemed to work quite right.
The annual winter meetings have passed. A lot of GMs have been aggressive in spending or prioritizing their team's urgent needs. As usual, the Pirates were not big spenders nor would I consider them aggressive. This fits into their typical patient and cost-effective operations.
The Agile framework is all the rage. It aims to solve limitations introduced by waterfall. The framework is driven by value and priority, not fixed scope and heavy upfront planning.
Recently, I read Codifying devops practices, a blog post written by Patrick Debois.
Hands down, a huge pet peeve of mine is a lack of reliability.
I recently had a difficult situation in which I could not debug a hanging Simpletest in Drupal 8.
This morning I read this article. It's a short phrase that stood out: simple beauty of life.
This evening, my daughter and I were playing doctor. I laid on the floor and she gave me a checkup. She looked at my ears. "Better". She checked my heartbeat. She nodded her head. And, lastly, she checked my temperature.
I'll try to stay focused on the picks in the first two rounds, as it's very difficult for a novice like me to be an expert after that.
There are two philosophies the Steelers never deviate from. They certainly will not this year:
Generally speaking, I try to be very laid back. I do get stressed out (and continue to try to work on that). However, there is one major pet peeve of mine that I believe is worth sharing. Being present.
No one is irreplaceable, and that is a fact. Teams often find ways to overcome the loss of staff, even creatively. Some losses hurt more than others. One key factor is institutional knowledge.
I personally believe cut-and-paste coding can be one of the sloppiest and least reliable ways of developing a product. Consider the source.
DRM is a sticky issue. I found this out the hard way recently when my Keurig machine died.
I am a big fan of learning moments. In business, some learning moments come at a cost. Some mistakes are easier to forgive than others. I still believe in exercising as much patience as possible to allow people to learn.
Drupal is definitely a framework enterprises can leverage. I think few would argue this. But, the term open source freaks out a lot of people. What it boils down to is how to best leverage this framework. This means that we as a community need to adopt best practices in how Drupal is used.
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.
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.
Recently, it hit me that there are actually benefits to having a short term memory. I don't think this is broadly applicable. In fact, I think there are more instances in which you do not want to have a short term memory. Allow me to explain...
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.
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.
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.
Nodes are the unquestioned most robust data structure within Drupal. It has widely adopted integration, e.g. Views, Features, Context, Rules, etc that make the Node a popular Drupal entity for countless use cases.
Projects are risky. Specifications are nearly impossible to define on most projects due to technical or communication gaps. This is the age old challenge many people fight.
Bad projects are toxic.
While most staff within a company focus on the bottom line, the bottom line is no guarantee of project success. It's impossible to look in your crystal ball and make this call before a project begins. Hindsight is 20/20, right?
At the heart of Agile is flexibility. This is designed into sprints that are intended to account for changes rolled into subsequent sprints.
Push aside the user stories, contracts, and legalities. When push comes to shove, the developer delivers the goods. In my mind, there is huge risk to a project with the role of a developer.
Peter Nixey describes good developers as both technology proficient and hard working in his blog post. His concept of "simplicity" is worth noting.
The Migrate module is, hands down, the defacto way to migrate content in Drupal. The only knock against it, is the learning curve. All good things come to those who take the time and learn it.
As organizations evolve, traditional metrics and philosophies are being thrown out the window to further organizations. Such factors include efficacy, employee satisfaction/ownership, innovation, etc.
Personally, I love bagels. The pinnacle of all bagels is the toasted everything bagel with plain cream cheese.
I reserve the right to update this over time, but let this serve as the Bergstein Metrics of Bagelology.
1. Seeding Amount
This is a topic I have grown all too familiar with, as this is my thesis topic for my master's degree. I thought I'd share some basics to set the stage in this area of work.
Standing in a Boston hotel room, I went to put my room key in my sport coat pocket and found something that gave me pause. It was a sign.
The Coder module (http://drupal.org/project/coder) is well known for assisting developers in producing code up to snuff with the community defined standards. Such standards have been integral in helping the community grow in a consistent manner.
Much focus has been paid to Matt Niskanen or Simon Depres finding new towns. This is the most likely scenario, as Niskanen's youth and recent good play has surely garnered focus. His trade may be more likely, as Depres came to camp over weight.
Drupal is a complex and robust system. Due to all of the processing required to bootstrap Drupal, enabled modules, enabled themes, and page-specific rendering, one can imagine performance becomes a major concern.
My previous post outlined my exploration in text editors. But, there are several other tools that revolutionized my ability to do my job.
To innovate, you often have to risk getting out of your comfort zone. The last several years, I have had varied needs which have required me to evaluate new text editors that offer more robust functionality.
What happens when there are a lack of open problems? On the surface, it seems to make it more difficult to have impactful contributions. I just think it requires you to think outside of the box.
Scale and performance are major issues for high traffic websites. The design of the Drupal system poses many challenges to building a distributed system that can support load balancing.
Apple's release of new iPhones and iOS7 has been criticized for what analysts claim is a lack of innovation. Such things have been prevalent for years in Operating Systems, productivity software, tablets/mobile phones, etc.
We've all had to deal with difficult people at work. It doesn't get easier when the difficult people are those you serve.
You've heard it all before. "The old programmer did this and it's crap" or "This person used this tool and it's no good". It's the age old grudge match between the old and the new. And, it doesn't help anyone move forward.
I recently read this article: http://bryanbraun.com/2013/09/21/please-stop-stewing-and-start-blogging-about-drupal
If you spent hours solving a problem, what is the likelihood you will remember exactly what you did the next time it comes around? Don't solve the same problem twice. Find a way to automate routine tasks so you can focus on other challenges. What are some strategies used?
Well... here goes nothing. I've always wanted a way to share the things I've learned.
Good programmers learn from their mistakes. The best programmers then share the love.
I welcome your thoughts and encourage you to engage in conversation through comments. Thanks for visiting.