First post at Opensource.com!

Very happy to announce that my first post at Opensource.com was just published!

https://opensource.com/open-organization/19/10/gaining-influence-open-community

This is the first installment of a 2-part series!

Midsummer Thoughts on the Fun of Coding, Obvious Secrets, and Whether Plumbers Plumb on Vacation

A recent documentary shown on american television (https://www.golf-films.com/hogan) told the story of the life of Ben Hogan, the greatest golfer of the 1950’s. Hogan is a fascinating person, not only for his success as a professional athlete, but his overcoming personal tragedy. His father committed suicide when he was a child. Years later, as an adult, when he reached the pinnacle of his sport, he was nearly killed in a head-on collision between the car he was driving and a bus. After multiple surgeries and months of recovery, he was once again able to become the top athlete in the world for his sport. He became so proficient, in fact, that he was rumored to have found “the secret.” 

Every athlete searches for the secret to better performance, but in reality, “the secret” usually comes down to a combination of talent, hard work, and perseverance. In Hogan’s case, it was definitely a combination of the second and third of these factors. To a great degree, he invented modern practice where repetition in practice was the key to success performance under pressure. It has been an obsession lasting decades to try to discover Hogan’s secret. The answer may have been obvious. If he had a true secret, it was hard work coupled with the fact that he actually enjoyed practice. It was never work or drudgery to him. For him, practice was actually fun.

But, what does this have to do with software engineering? Fast forward to this week. 

We had taken the family to the beach for a week of vacation. After returning from a day at the beach, everyone in the family was relaxing their own way. My wife poured herself a glass of white wine and became engrossed in FaceBook.Grandma tuned the TV to the Golf Channel and complained about the beach traffic to anyone who would listen.The kids tortured each other over a game of ping-pong And me? I put my feet up and was unwinding by downloading an open source project that I had just discovered on github. Later on, my daughter remarked to me, in her usual subtle manner, “Geesh dad, you’re always on the computer. Don’t you ever want a break? Do you think that plumbers do plumbing when they are on  vacation?” She does have a point. For a lot of people after working a full day, the last thing that they want to do is to look at or work on anything job related in the evening, especially when they are on  vacation. I tend to doubt that very many plumbers do a lot of plumbing when they are on vacation. 

But, software engineers are different.

What is is about software and software engineering that makes us always wanting more? One reason may be that rapid changes in technology are interesting and frequently exciting. Another reason might be that given the rapid rate of change it’s important for your career to stay current with the latest  developments. 

These are all valid reasons, but I think that the "secret" for us, just as it was for Hogan and his practicing, is obvious, that we actually enjoy reading and writing code. 

In other words, for us, it’s fun!

Part of the fun comes from the nature of software itself. When you're working with physical media such as with steel, or concrete, or beach sand, the limitations of what you can do are based on physical limitations of that media and the physical environment. In contrast, with software, you can face limitations of memory or CPU speed or environment, but you are primarily only limited by your imagination. This is what makes software engineering so rewarding, and so much fun. You are basically building virtual structures out of ideas. And, unlike physical media, you can easily tear down, redesign, and rebuild structures in software. 

Wishing everyone a fun end of the summer!

Divided by (the lack of) a Common Language?

”Why are you bothering with tests that don’t work?”

I remember the incident distinctly, even though it took place several years ago at a company that no longer exists, while my team was building and testing a long forgotten product. I was reviewing a software test plan with a development team colleague as I wanted his input on the risks associated with a new feature. I described the functional tests that wanted to build for the feature, and then mentioned that we would in parallel be updating the product’s non-functional tests (such as performance and security tests) to take into account the new operation of the new feature. He looked confused and asked me,”Why are you bothering with tests that don’t work?” His question caught me off guard and when I asked him to explain, he said, “You’re talking about tests that won’t function. Why are you wasting time on those tests? They’re broken, right?”

At that point, I thought of George Bernard Shaw’s famous quote about the British and Americans being two peoples divided by a common language. In this case, however, the problem was two groups of people being divided by the lack of a common language. That being, the language of software testing.

Historically, Development and QE teams have been kept separate. The separation was based on the belief that the only way to have effective and unbiased testing of a product was through having an independent testing team. One of the rationales for this separation is that testing always includes an element of “creative destruction” and that is difficult for people to act in a destructive manner toward their own work.

In an agile development model, this artificial separation is done away with. The walls that divided development and test engineers are torn away broken and they work together as members of the same team, where the quality of the product created is owned by every member of the team. The transition to this model from a traditional waterfall development model can, however, be difficult. The problem is that people without a QE/test background will be asked to build and run tests when they may lack hands in experience in test development beyond building unit tests. The “test guys” (that is, the QE/test engineers) can help by providing guidance and coaching, but but that coaching can difficult because people new to testing will not have a frame of reference to build upon.

A Shared Language - And Two “Good Reads” for Anyone Building Software Tests

When you work in a technical field it’s easy to become totally absorbed in the technology and forget the importance of human communication and community. What makes a community? Shared values, shared goals, shared experiences, shared literature, and a shared language for software testing.

It’s winter here in Boston, which makes it a great time to sit down by the fire, or at least a video of a fire, and do some reading. There are a couple of resources that anyone new to testing should read:

The year 2019, marks the 40th anniversary of the original release of Glenford Myers’ book, The Art of Software Testing. It’s still my favorite software testing book. In this little book, Myers provides a practical, and very readable description of methodologies for software test design. Equivalence partitioning, boundary value analysis, it’s all there in The Art of Software Testing.

In its syllabus and glossary, just updated in 2018, the International Software Testing Qualifications Board (ISTQB, https://www.istqb.org) provides a detailed and systematic definition of software testing. Founded in 2002, the ISTQB has established standards and certifications for software testers. In their glossary and syllabus, the ISTQB painstakingly describes how to design, organize, execute, and report on the results of software testing.

Building effective software tests are not just for “the test guys” anymore. In an agile model, we all own and contribute to and execute tests to improve product quality. Doing some basic research by reading The Art of Software Testing and the ISTQB syllabus and glossary would make for a very useful New Years resolution for anyone wanting to learn learn the language of software testing and to create better tests. Happy 2019!

Management tip - When the Pizza is Free, Answer the Phone

It all began with free pizza.


Public Domain, https://commons.wikimedia.org/w/index.php?curid=79505

Many jobs ago, when I was working for a company that coincidentally no longer exists, there was a monthly event that no one looked forward to; the monthly managers’ meeting.

My fellow managers were, as individuals, extremely pleasant and competent people, but when they got together, group paralysis seemed to set in as they became collectively incapable, or even afraid, of taking independent action.

I remember one meeting especially well as it taught me a valuable management and leadership lesson. It all involved free pizza. In an effort to improve both morale and attendance, it was decided that the monthly meetings would be scheduled during everyone’s lunch hour, and that a free pizza lunch would be provided.

The meeting started promptly at noon, and soon settled into a familiar pattern of discussing, delaying, denying, and deferring actions to be taken.

And then, the telephone in the conference room rang.

The conversation stopped. Everyone stared at the telephone as it continued to ring. What could this mean? Why would someone place a telephone call into a conference room? Were we being watched? The phone continued to ring. Everyone stared at the phone, trying to will the ringing to stop.

After a few rings, I answered the phone. “It’s the front desk. The pizza is here.” Instantly, the tension was broken. Everyone started to breathe again.

But, after a few seconds, everyone froze again. Glances of uncertainty were exchanged. Everyone in the room shared the same thought, “What should we do now?” After a few more seconds of deafening silence, I stood up and addressed the team, as they sat frozen in their chairs and said, “I’ll go downstairs and get the pizza.”

OK, I may be exaggerating for dramatic effect, but I really did see this happen. It’s easy to dismiss this silly little story as a silly little story, but I think that there’s more to it. Individuals, small groups, and large institutions often create their own inertia. It’s the responsibility of team leaders and managers to recognize when forward progress is stalled and change the team’s inertia by removing obstacles. This may require shifting resources from one task to another, or it may require adjusting the relative priorities of task assignments, or it may require simply answering the phone and picking up free pizzas.

The JBoss apiman Crash Course Guide is published!

Just published a brief and easy to follow "crash course" guide to JBoss apiman. Hoping that this will help lots more people get started with API Management with JBoss apiman...

http://www.apiman.io/latest/crash-course.html

Introduction to User Roles in apiman

(Reposted to: http://www.apiman.io/blog/apiman/introduction/overview/users/roles/2016/03/28/users_roles.html )

In this post, we’ll examine apiman user roles. In the apiman data model, all data elements exist in the context of the organization. The same holds true for user memberships as users can be members of multiple organizations. Permissions in apiman are role based. The actions that a user is able to perform are dependent on the roles to which the user is assigned when a user is added as a member of an organization.

Let’s start by looking at the roles that are preconfigured in apiman.

Understanding OOTB apiman user roles

In apiman, each role defines a set of permissions granted by that role. When a user is made a member of an organization, that user must be assigned to a role. A role definition consists of a name and description, and, most importantly, a set of permissions that govern the user’s ability to view, edit, and administer the organization itself, as well as the organization’s plans, APIs, and applications.

Roles are managed in the Roles section of the apiman System Administration form in the Management UI.

Apiman is preconfigured with the following roles:

• Organization Owner
• API Developer
• Client App Developer

These role names are self-explanatory. For example, a user assigned the Application Developer role is able to manage the organization’s applications but is blocked from managing its APIs or plans.

The full set of permissions provided in apiman by these preconfigured roles are:

Preconfigured apiman Role	Who Should be Assigned this Role	Permissions Granted to this Role
Client App Developer	Users responsible for creating and managing client apps.	Client App View Client App Edit Client App Admin
Organization Owner	Automatically granted to the user who creates an Organization.	All permissions: Client App View Client App Edit Client App Admin Plan View Plan Edit Plan Admin API View API Edit API Admin Organization View Organization Edit Organization Admin
API Developer	Users responsible for creating and managing APIs.	Plan View Plan Edit Plan Admin API View API Edit API Admin

Organization owners can assign roles to users through the “Manage Members” form in the apiman Management UI. Each user must be assigned at least one role, but users can also be assigned multiple roles.

We’ll walk through an example of assigning a role to a user in a moment.

While apiman admin users can also modify the permissions as defined for these preconfigured roles, it can be easier to create new custom roles. We will also walk through an example of creating a new user role later in this post.

Assigning/Revoking Roles for Organization Users

It’s worth repeating that all data elements in apiman exist in the context of an organization.  As a result, it is important to understand that users can only manage these elements if they have the appropriate role for the organization in which the elements exist.  Therefore, a user must be granted membership in an organization.

It’s not possible for users to assign themselves roles. Roles must be assigned to a user by an organization owner. Assigning a role to a user is a straightforward task for an organization owner.

First, the organization must search for the user:

And then, the organization owner can select a role from the existing set of roles:

Revoking a role for a user is just as easy. The organization owner simply has to search for the user, and then deselect a role for the user.

The same approach for assigning/revoking a role for a user is followed for the standard roles that are preconfigured in apiman, and for custom roles that you create.

Creating a New User Role/Defining the Role Permissions

In addition to providing a set of preconfigured roles, apiman also provides a means for apiman admin users to create new roles where you can define a custom set of permissions for each role. Custom roles give you the ability to exercise fine-grained control over the set of permissions granted to users.

Let’s look at an example of a custom role.

Imagine a situation where you have API developer users and application developer users. These sets of users can rely on apiman’s preconfigured roles. Let’s also imagine that you have a third set of user. You want these users to have read access to APIs and applications so that they can participate in a review/approval process. However, you do not want to give these users write access. For example, suppose you have to find a job for a certain relative of yours. He may be a thoroughly competent person, but you’d feel better if he didn’t have write access to anything valuable. A read-only role for your brother in law would look something like this:

Once the “brother-in-law” role is created, you can assign it to other users in the same manner as any other role:

In Conclusion

A consistent pattern in apiman is a rich set of features provided OOTB, and a method for you to expand on these features by creating customizations. User roles enable you to assign users permissions based on the tasks that they perform. Apiman is preconfigured with a rich set of roles OOTB, and also enables you to create new, custom roles to handle additional types of users (even your brother-in-law).

Reposted to DZone!

It never gets old...

https://dzone.com/articles/apiman-12-improvements-to-plugin-management