Using PHP to Add Content to Plain Text

In my last blog message, I described how I use a converter to HTML-ize plain text. This is useful for taking URLs like and producing a link. Now that I convert each text file before display, I can add content.

One thing I add to my web pages, is ads. Some people pay me for specific ads. On other pages, I put in filler from Google Ads.

I based my converter on functions from, particularly "txt2html". At the end of that function, when the HTML is almost ready, I can append to it. Or, since I want the ads up front, I pre-pend.

/* Ad from  Get your own ad from there, 
 * unless you want me to get paid for it! 
 * When you have the ad, they'll tell you what HTML to put in your site.
 * Cut and paste their text into the string below.
 * Put only double quotes inside the string, single quotes to define it. */ 
$html = '<' . 'table align=right> <' . 'tr> 
<' . 'td> <' . 'script type="text/javascript"><' . '!--
google_ad_client = "pub-4220969454236754";
/* 300x250, created 10/17/09 */
google_ad_slot = "6246428593";
google_ad_width = 300;
google_ad_height = 250;
<' . '/script>
<' . 'script type="text/javascript"
<' . '/script>
<' . '/td> 
<' . '/tr> <' . '/table>' . $html;
return $html;

About the Author: 

Scott Eiler has for decades worked in all aspects of software engineering, in public and private sectors, in many different industries, on projects most people know by name, as employee, vendor, and now consultant. He also maintains his own diverse web site, including much commentary. Scott knows, engineering is more than just hacking out code.

Posted in: 

Agile Project Management - Engaging Your Customer!

The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’. It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.

Agile PM - Engaging Your CustomerBut it has a simple solution. The customer should stay engaged during the entire project. They should be available for trade-off discussions and for demo’s. They should provide ongoing feedback on interim deliverables. They should even understand the teams’ capabilities and implementation challenges. In a word, they should become a “partner” to the team and not simply a “stakeholder”. They need to have continuous skin in the game if the project heads south and they need to be a part of trade-off and scope adjustment decisions.

The agile methods have several ceremonies or tactics that are intended to draw the customer into the team; to foster their inclusion and to gain their insights. In this post I want to review and emphasize the importance of these practices and the need for overall customer engagement.

Backlog Grooming

You all know that a prioritized backlog of work items (features, tasks, key functional and non-functional requirements) is what drives the agile ‘machine’. The list is dynamic in nature with items being added, removed and changed nearly continuously during the lifetime of an agile project.

Many represent the central nature of the backlog as a pyramid or iceberg. It follows then that at the ‘tip’, the highest priority items are found. They are also defined at the clearest and finest level of granularity. In other words, these items are ‘ready’ for execution. The team has sized them and broken them down. They have talked about them several times as they’ve done this.

This activity is typically called ‘grooming’ the backlog. It’s where the team repeatedly revisits the backlog, refining it from multiple perspectives and getting elements ready for execution. The Scrum Product Backlog is not only a list of features, but it’s effectively a work breakdown structure for all of the work necessary to complete a product or project release.

By involving your customers and stakeholders in backlog grooming and making it transparent, you’re engaging them at a base level of requirement management and planning. Both are areas where your transparency can and should pay-off in increased interaction and feedback on the backlog—pre execution.

It also results in a better understanding on the part of the stakeholders on the level of complexity and difficulty that the team is encountering. I probably hear pushback 3-5 times in every grooming session around how easy they thought a feature would be to complete. Why, we almost do it now, so it can’t take more than an hour or so to extend the feature…right?

Then the team, usually patiently, tries to explain why the design is more complex and how the estimate for the story is extended by the “real world” they deal with every day. Or why a single day implementation might need three days of testing because of data security concerns. So having the customer involved in grooming and planning (next) can really help them understand why things take as long as they do, while also drawing them into powerful trade-off discussions.

Sprint Planning

Rarely does an approach to software development include customers and stakeholders in planning the project. At least not in the nitty-gritty details of the effort. But in Scrums’ Sprint Planning ceremony the customer is welcome to attend as the team considers the work and plans their execution.

The meeting has a two-phased approach. Phase one is focused towards the Product Owner sharing the sprints’ focus with the team. They review the body of stories targeted for this sprint and answer any late-binding questions the team may have about them. Quite often, the questions vary from specific behaviors to how the team might design and implement the feature set for the sprint.

Once phase one is finished and the team fully understands the work, they then dive-in and begin to break down each of the stories into work tasks. Keep in mind that these are ALL tasks associated with the work—for example: development, testing, design, inspections & reviews, documentation, etc. Every bit of work required to deliver the story to completion is identified by the team and the effort associated (hours) are estimated.

So you might ask, how does this help the customer engage? It allows them a view into the planning & execution dynamics of the team in order to deliver on their requests. They gain a glimpse into the level of difficulty associated with each feature—where are the hard ones, fraught with risk. And conversely, where are the easier ones.

They gain insight into the strategy the team will be using to deliver the features. Who will be working on which features and why? How is the team planning on handling dependencies and overall feature testing? How are they planning on handling risks? And if the team is operating as part of a larger group, how are they interacting with other teams on dependencies, integration, and collaboration?

In a word, the plans are totally transparent and open for discussion and adjustment. The team simply wants to deliver on its commitments, so constructive ideas are welcome—especially the empathy that stakeholders should realize by becoming part of the teams’ planning.

You see—software is rarely as simple or easy as most bystanders believe.

Daily Stand-up

All of the agile methods have the notion of a daily team meeting for sharing progress, challenges and making real-time adjustments to the teams’ committed goals. In Scrum this is known as the Daily Scrum and it’s where a customer can gain real-time insight into the “inner workings” of their agile team(s).

Agile Daily Stand Up

I remember a team implementing some features in an eCommerce application. To her credit, their VP of European Operations would attend the meetings whenever possible as they were developing the interfaces to Amazon UK. She would listen intently to the discussions, but wouldn’t interrupt the team with questions as she was a compliant ‘chicken’ in the stand-up meeting.

However, after the more difficult conversations in some of their daily scrums, she would pull me aside and ask me questions regarding what she had ‘heard’ in the stand-up. Were they in trouble? How could she help? And, could they adjust some of their scope commitments in order to assist the team? Were very typical questions she asked. In some cases, her concerns were unfounded. In others, they were absolutely right on.

The stand-up was her window into the teams’ work dynamics that she had never had before. No longer was she relying on written or e-mail status reports that were interpretations of progress. No! Now she received unfiltered, raw data from the team themselves.
She encountered the highs and lows. She clearly saw the teams’ challenges and, more importantly, how they approached resolving them.

She didn’t need a report to tell her where the risks were. Instead, she viscerally understood them by interacting with the team. She also saw the opportunities present themselves where she could assist the team in making adjustments while still achieving their & her overall goals.

It was incredibly powerful and frightening at the same time. It enticed, no encouraged, no demanded her to engage as an ‘owner’ with the team.

Sprint Review or Demo

One of the core agile manifesto points is “working software over jabbering about working software”, and I paraphrased a bit here. You see an incredible emphasis in agile teams, and I think it appropriate, to discuss most of your designs, requirements, and product commentary while looking at working software. There’s literally nothing else like it.

In Scrum, there is a Sprint Review or demo ceremony at the end of each sprint or iteration. In the demo, the team is responsible for showing off their working software that was focused towards their established sprint goal(s).

This ceremony is a “big deal” in Scrum teams. At iContact for example, we have sprint reviews for our teams every three weeks. We have them in our largest conference room. We literally invite the entire company (yes, we’re relatively small) to the event. Usually over half of our C-level team is in attendance and the room is typically standing room only.

Each team takes its turn to demonstrate their efforts for the past sprint. Team members all get a shot at speaking to their efforts. The audience is engaged. Asking questions and providing immediate feedback on the functions and features demonstrated.

Often the feedback extends beyond the demo. Folks will follow the team back to their seating areas and provide additional feedback and/or ask to see a particular feature again. I often see our CEO whispering his reactions to our product managers during and after the demo as he guides the vision he’s personally looking for in our product.

But beyond feedback for our teams, it shares information with our sales, customer support, and account managers. They become familiar with what’s being developed in real-time and can communicate those “coming attractions” directly to our customers.

Wrapping Up

One of the keys to engaging the customer is showing them you’re listening to their feedback. That it matters to you and you’ll take relatively immediate action on it. This loop of (Listen To Feedback – Develop/Change Software – Demonstrate – Listen Again) is a wonderful device for agile teams to assure they’re on the right track.

It also draws in their customers. It engages them in the process because they feel more like a partner in the teams’ efforts. Now not all customers will embrace this behavior. Traditional customers will be taken aback and you’ll hear excuses—mostly that they don’t have the time for it. You’ll need to be patient and, over time, draw them into your efforts. Working software that demonstrates solutions to their most challenging problems can be…well intoxicating.

Agile project managers maintain their teams’ focus on the heartbeat of delivering value and work hard to PULL the customer into the fray. Why? Because it’s their software, they need to care, and you need their feedback. So just do it!

Don't forget to leave your comments below.

Related Articles:

Agile Project Management—No Upfront Estimates!

Agile Project Management—Controlled Chaos

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at

Posted in: 

SQL 101 - Summarizing Data (Part 1)

When beginning to learn SQL, it won't be long until you have to answer questions that require you to summarize the data. It's one of the primary reasons SQL is used. You store many records detailing events, then you can summarize that data and report it back to users, so they don't have to summarize it by hand.

I'm going to show you the 5 most common ways you'll be asked to summarize data: COUNT, SUM, MAX, MIN,and AVG (Average). There are several more that SQL understands, and once you learn to define your own functions, there will be an infinite number of ways to summarize that data. I just want you to gain an understanding of the basics, so you can go on to all those other methods.


There are three variations to this function

COUNT(ALL expression)
COUNT(DISTINCT expression)

The first method is the most common. You'll use it when you want to count how many rows are in a table. If we ran the following query against our products table we've referred to throughout the SQL 101 lessons, we get 4, since we only defined four records.

COUNT(*) AS [count]
FROM products

We would get the same result from the following query.

COUNT(ALL productName) AS [count]
FROM products


If there were duplicates in the products table, and we only wanted a count of unique values, then the following version would let us count only the unique values in the table.

COUNT(DISTINCT productName) AS [count]
FROM products


Since there are no duplicates in our example table, we still get four.


Like COUNT, the sum function accepts ALL or DISTINCT as a modifier, but by default, it will sum all. Sum is the first function that really interprets the data. A COUNT is simple, a SUM actually does a little work for you. Warning, make sure the column your summing is a numeric type. The sum function will try to convert the column into a numeric type, and if it finds even one value that cannot be converted, you will get an error. You may also want to consider using the ISNULL function with this, since adding NULL to something is still NULL.

SUM(price) AS [Total Price]
FROM products

Total Price

MAX, MIN, and AVG (average)

SQL is can be a great way to store lots of detail records. Whenever you have data, someone will eventually ask you to do some statistical analysis on that data. MAX, MIN, and average are the most common statistical numbers asked for.

MAX(price) AS [max]
, MIN(price) AS [min]
, AVG(price) AS [average]
FROM products

max min average
---- --- -------
1.25 .25 .8725


Summarizing data will be a big part of your life as a SQL developer. These functions will serve as your first steps into learning more and more powerful ways to summarize data. If you have any questions, please, feel free to send them in! I'm here to help you learn as much as you can about SQL.

Other Recommended Articles:

SQL - The Advanced LIKE Clauses

SQL 101 - The WHERE clause

About the Author: 

Look no further for expertise in: Business Analysis to gather the business requirements for the database; Database Architecting to design the logical design of the database; Database Development to actually build the objects needed by the business logic; finally, Database Administration to keep the database running in top form, and making sure there is a disaster recovery plan. Connect with Shannon Lowder.

Posted in: 

Agile Project Management—Driving Value or Where’s the Beef?

There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Often she was disappointed in her quest and shouts “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

Agile PM - Where's the Beef?I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—then sort of throwing the software “over the wall” for feedback.

Quite often they are under the gun to deliver a smorgasbord of features. Almost as if no one knows what the customer needs, so they shotgun scatter solutions hoping to hit their needs. Fingers crossed. While this may be somewhat successful, it also results in delivering low value features that dilute the focus of the team and increase product development costs.

Wouldn’t it be wonderful if we could focus entirely on “The Beef” in application development? Spending most of our energy focused on delivering high-value and high-need solutions to our customers. Cutting through the clutter of disappointment and ambiguity and simply working on what matters most?

While it sounds like a fairy tale, the agile methods aspire to just this purpose. But it’s not easy to achieve and the effective Agile Project Manager plays a wonderful role in this quest. In this post, I want to share some ideas on how to focus the team towards value delivery.

A Prioritized Backlog!

One of the first mechanisms that drive value is the Product Backlog—the simple prioritized list that drives what agile teams are building. Every team should be laser focused on prioritizing their backlogs in 1..n order. There can’t be three or four priority one features—there can be only one; then two, three, and so on.

Trust me; your customers and stakeholders will want to play infinite games with priority. I’ve seen cases where they have groupings in a spreadsheet that are prioritized and then sub-features broken out within each of them. They’ll insist that they can’t decompose the value out any further as they try to overload priority. This (1a, 1b,..1z) approach allows them to escape true prioritization and selection, also indicating their innate inability to make hard choices regarding what’s truly most important. Don’t let them do that!

An effective product backlog is always in linear and priority order. The team will always deliver the highest priority features first. They will work on them first, finish them first, ensuring the customer is engaged as appropriate.

And since the customer is the final arbiter of priority, they shouldn’t really complain about this approach. It’s just that we’ve historically allowed them to give us large lists of features without making this distinction—so they’ve gotten a bit lazy.

When encouraged (forced) to prioritize, I’ve never seen a stakeholder who couldn’t do it.

Customer-Driven Value

Prioritization can also be driven by perceived value—change that to should be driven. One technique used by many agile teams is the notion of Value Poker. It’s a variation of the popular Planning Poker technique that is used for User Story size estimation. But instead of determining size of stories in story points, we use Value Points as the determinant.

In this case you use a deck of cards labeled from 1-10, one being the lowest value and ten the highest. For each User Story or Theme of stories you ask a group of various customers and stakeholders to ‘vote’ on their view to value of the Story. You take a round-robin approach discussing the ‘why’ behind the highest and lowest values—letting the team express their views towards value nuance.

Once the discussion is over, you re-vote and re-discuss until you narrow the value as much as possible. Sometimes you gain agreement across the team. Sometimes you simply get a range.

You might even compartmentalize values from the different perspectives of the team. For example, the quality and testing folks’ might value a particular story as a five, while the business folks’ value it as a three and development or technology folks’ as a one. All of their valuations provide important data as to how you cross-functionally value the feature.

This logic might be applied to multiple stakeholders as well. For example, the North American stakeholders might value a feature at six, while the EMEA stakeholders think it only a three. In all of these cases, discussing VALUE as a distinct attribute helps the team in prioritizing and in deciding how much fit & finish to apply to individual features.

A Variation

 A truly effective variation on the Value Poker technique is to give every voting or contributing partner a ‘pool’ of funding to spend as part of their voting. So not only are they voting on a value, but they have to invest a portion of a fixed pool of dollars on the feature as well.

Quite often monopoly money or a similar fun equivalent is used for this purpose.  Let’s say everyone gets $5,000 to spend on their features as we play priority poker. In one particular case, a business stakeholder votes a nine for a feature.

In order to emphasize the importance, they put up $1,500 on the feature or about 30% of their available funds. In fact, they only spend their pool against a total of seven features. While they continue to prioritize subsequent features, they’ve clearly communicated their views towards value. In fact, that $1,500 feature ends up being the #1 priority with a total value pool of $12,000 across the entire voting team OR 25% of the available pool.

So here’s an interesting question. If you’re implementing this feature, what does #1 Priority convey vs. #1 Priority AND 25% of the value pool? From my perspective, there’s a large difference. This feature is a much more significant portion of the value and requires particular care in execution. I hope you see the difference.

Minimal Marketable Feature (MMF)

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be valuated by the customer. Earlier I spoke in terms of a theme of stories. This is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic level, it simplifies your prioritization. It also has more meaning from the customers’ perspective.

A variation on this theme (pun intended) is the Minimal Marketable Feature or MMF. This concept originates in the Kanban and Lean spaces. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF is larger than a theme. It could be equivalent to a user story epic and require several sprints to complete. However, once complete, the team will usually physically deliver the MMF to the customer—for example, pushing it into the production environment.

Tracking Value

One of the wonderful additions to your tool-set as an Agile Project Manager is burning down (or up) the value of stories, themes, or MMFs. You’ll want to setup a burndown chart in a well visited location that burns down team delivered value. As with all burndown charts you’ll want to keep everyone’s eyes on progress and interacting with the team over progress and flow.

You’ll want to calculate total value for a release or project. Then setup your burndown on an iteration-by-iteration basis.

If you’re getting healthy agile behavior within your team, you’ll see value being delivered in a front-loaded fashion. You should also see healthy done-ness and quality attributes as these high-value features are delivered. In fact, I usually expect teams to factor in value as part of their overall quality and testing strategies.

Wrapping Up

Agile Project Managers don’t just care about by-rote execution of tasks or stories. No! Instead they focus their teams on a multi-faceted and nuanced view towards customer, value-driven execution.

Not only are they hoping to deliver value first, but they’re also hoping that by doing so, the customer may achieve a “good enough” view towards incrementally delivered product increments and allow the team to stop the project earlier than planned.

Stopping after delivering the features and functionality that truly matters the most to them. Sort of gaining their value and then moving onto their next highest value-driven project. It’s this sort of value-trimming that can truly make an agile team stand-out from their traditional counterparts and move so much faster.


Related Articles:

Agile Project Management—No Upfront Estimates!

Agile Project Management—Controlled Chaos

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at

Posted in: 

Another year older, and a new one just begun…

I spend a lot of time around the Holidays with my family.  It’s my time to recharge the proverbial batteries, reconnect with my kids, and just stop to take a breath.  Sometimes we travel, sometimes we just hang around the house.  No matter where we end up, though, we spend a lot of time in the kitchen, at The Movies, and just doing family stuff.  By the time the holidays are over, I’m ready to change focus once again, and gear up for another productive year of Careerism.

And during this period, I try to reflect on what’s transpired in the last year for me, both good and bad, personal and professional.  I think about my life growing up in Fort Lauderdale, the times I had a child, and compare my experiences to those of my children.   I make every effort possible not to repeat the mistakes my parents made with me – rather, I try to invent brand new mistakes that will linger with my children the rest of their lives, as all loving mothers and fathers inevitably do.

Also, if you’ve been reading my blog posts for awhile, you know I have a fondness for John Lennon’s music and just his general view of the World.  He released one of my favorite Christmas songs in 1971.  The first line hits me with the same force it did when I first noticed it as a young teen:

“So this is Christmas, and what have you done?  Another year older, and a new one just begun…”

Another year older, and a new one just begun…Now, I’m fairly certain I heard this song hundreds of times when I was a little boy, but I was 13 years old, the words actually sunk in.  This wasn’t your typical ‘ho ho ho, Merry Christmas’ type of song, it was a challenge.  What have you done?  What have you actually accomplished with your time on this Earth of ours.  Forget about the celebratory implications of your religion.  Fill in the blank for the holiday if you like, make it any milestone you want.  The second part of the sentence remains a question, if not the question, for all of us.  What have you done? 

Now, when you’re 13 years old, you think you know everything.  You’ve got your entire life planned out and everything is going to go your way.  No thought of failure or loss or disappointment, and precious little thought of those faceless people in the World who have far less than we do.  However, as an adult with a son who also happens to be 13, my perspective is quite different than it was all those years ago (another great song title, this one by George Harrison). 

The way I see it, you have a choice in this World.  Are you going to try to improve yourself, and as an extension of that, our society, OR, are you going to simply watch your life roll by?  Are you going to get better, or will you just settle for getting older?  Do you want to be Keith Richards, who hasn’t contributed anything of note since 1981 (co-writing ‘Waiting On A Friend’), playing the same tired guitar licks for even longer?  Or, do you want to become a virtuoso (insert your favorite guitarist here, mine being Jeff Beck), who gets better with time, aging like a fine vintage, and taking up the challenge to improve every day?

The choice is yours, and it truly is up to you.  Remember this, though:  the World isn’t going to magically improve itself.  

About the Author: 

Willard Woodrow, Senior Project Manager and BI Champion at Genuine Parts, has 15+ years of information technology experience in the utilities, retail, recruiting, telecom, and insurance verticals. His professional expertise includes business consulting, system implementation, project management, application operations, and client relationship management. Follow Willard on Twittter @willardwoodrow.

Posted in: