STRONGblog

5 Tips to Accelerate Adoption of Rational Developer for System z

2016-07-11T15:34:00.004-04:00

Reasoning

We've been involved in several large scale deployments of Rational Developer for System z. The product is an incredible piece of software that can drastically improve software development productivity. It also will drastically change your development organization's culture (usually for the better). However to have the best culture change, you need to be prepared to implement the product correctly. We've seen it implemented poorly, and have cleaned up after the product was improperly installed or the students were insufficiently instructed. If you follow these five tips, you'll have about a 97% chance of a successful adoption.

1) Automate Deployment of the client to the Desktop

Rational Developer for System z is a large, complex tool. Most mainframe organizations (banks, insurance companies, financial institutions, governments, etc) often need to restrict what software is installed on the developer's workstation. Fortunately, this can all be automated and scripted. Further, it can be combined with other IBM tools (such as IBM DataStudio), as well as the current fix packs in one single package using the Packaging Utility. Once packaged, it can be installed using scripted methods and automated using tools such as Microsoft SMS, or IBM Endpoint Manager (now BigFix).

Even before you begin the packaging, you'll need to spend time to understand all the tools that the developers currently interact will, or will need to interact with after it is deployed. This may include any of the following:

Code validation (JCL check)

3rd party debuggers (i.e. Compuware tools)

Source Code Management (i.e. CA Endeavor, SCLM, ChangeMan, Panvalet, Team Concert)

Problem determination tools

File Manager or VSAM related tools

Java/JZOS

CICS Explorer

Data Studio

Take a survey by your development teams. Do NOT assume you know all the answers; we've seen career sysprogs surprised by the results.

2) Provide Just-In-Time Training

Training is absolutely critical for success. An ISPF developer will be hard pressed to adopt RDz without it (and there is ZERO evidence that any ISFP developer actually has adopted it without training).

As such, you need the right training, at the right time. The right training is a minimum of 2 days in person classroom training, adjusted and or customized for your environment. Yes, you need to budget for this. If you are budgeting for RDz and not budgeting for training, I recommend you not purchase the product. In fact, please don't buy it if that is the case. Your team will fail to use it, you'll waste money, and everyone will have a bad taste in their mouth afterwards.

So now that you've read that, and you've included some budget room for training, you need to schedule it for the right time, and find the right RDz partner who knows the product well. That is typically the week you expect your ISPF developers to begin actually using the product. You can do a week before, but never earlier than that. That means you need to have the product installed, configured (on both the host and the client) and ready to go on day 1 of training. It needs to be integrated with all the critical systems including SCM out of the gate (see #1 above). An alternative to classroom training is on-demand Computer Based Training. Our organization is currently developing this exact course with videos, interactive quizzing, and lab exercises. CBT based curricula would allow a student to revisit the course several times.

Training should also be multivariate as your personnel will learn at different rates. Provide classroom training to everyone at the start, but then provide additional training for laggards, and for new hires (those people hired after the original training finished). Provide interactive lunch-and-learns hosted by your RDz business partner, or your team champions (see #3 below).

3) Cultivate Mentors

To cultivate a product mentor in your organization, you'll need to train them ahead of the rest of their team. Typically, this person would be involved in the initial pilot or sales demo process and have prior experience with Eclipse. These are the people who will eventually conduct lunch-and-learns post implementation, interact with the IBM support team, and attend conferences such as COMMON or IBM InterConnect or Edge. To cultivate, you need to ensure these folks schedule time in their calendars to interact with the product, read up with its integrations and go through advanced tutorials and product literature. Budget for their attendance at conferences. Provide them a Wiki or Connections site to host so they can interact with other students and share their knowledge. Most of all, make them feel appreciated and reward them for positive efforts.

4) Uninstall the terminal emulators on the desktop

This is an effective motivator as exemplified by Cortez in 1520 when he sunk his ships to avoid mutiny by his men. As a result, his men were well motivated. To access it, just right click on your host lapr in the Remote Systems Explorer view. Yes, you read that correctly! You may not know this, but RDz includes a terminal emulator as part of the product. Its baked into the IDE and provides all the core functionality of the IBM PCOMM emulator (note that it does not include FTP or macro functionality). Click on Host Connection Emulator and it will bring up the emulator as shown below.

This GUARANTEES that the developer will have to use RDz just to get to their precious emulator. By the time they get in and are connected, they'll just as likely go into the other RDz views rather than have to log into the emulator and navigate to their ISPF panels.

5) Adjust the Developer's Expectations

One of the most common excuses I hear is that "we have to deal with production issues fast, so I don't have time to use it", or "my boss expects this to be done now, and won't wait". This is of course a bogus excuse. RDz makes the job of the COBOL development more productive, but it does have an initial learning curve. Once past that learning curve the productivity accelerates. So how do we combat this issue? First, we need to coordinate executive sponsorship from the C-level down through middle managers. The middle managers are critical on this. They need to set the expectations to their teams that using RDz to solve critical issues is paramount to just "going with the devil that you know". Thus, the developer should have the expectations, that they are not just the fixing the problem like putting on a bandaid, but applying proper medicine such that the problem never manifests itself again. Ensuring that the middle managers expect them to use their new DevOps tools is a key part of its successful adoption. We're not just using a tool for the sake of technology, we're using technology to vastly improve our business outcomes and our productivity.

Easy way to manage a developer's prioritized daily backlog

2016-06-06T13:39:00.002-04:00

The central tenant of any good Agile methodology is a prioritized daily task list. Even if you are not a developer, you'll see this concept in business, such as in the Franklin-Covey time management series, or David Allen's GTD. Its all about breaking up large tasks into achievable chunks, and timeboxing your work in progress so that you show gradual, measurable progress.

If your team is beginning to adopt Scrum, SAFe, or other Agile discipline, you'll like the features that IBM's RTC provides to enable a smooth transition. It is a Collaborative Lifecycle Management solution that enables developers, managers, and stakeholder to work collaboratively, providing faster delivery, more accurate delivery, and higher quality software.

The Rational Team Concert Eclipse client has a very convenient view call the "My Work" view, which presents as a prioritized daily backlog. This pulls from the team's central sprint backlog, allowing the developer the ability to see everything he or she has on their plate for the day, the week, and the following week. It also shows any future work in the sprint, as well as future sprints' work, as well as unplanned work in the release backlog.

This short video introduces the view, and shows how to link tasks or defects to source code change sets for traceability.
The backlog itself can be managed by a program or project manager, or Scrum master in the web client during a team's weekly or bi-weekly backlog grooming session. Note here how the developer can further colorize the backlog so as to group similarly affected items (such as those with similar tags). This further enhances the developer's productivity.

For the rest of the team, when the developer makes changes to the work item (such as marking it complete), the whole team can see the change immediately. This helps to avoid the issue with having a project manager going around and tap on everyone's shoulder to get an update. It also means that the stakeholders and executives can get a clear view of the current status at anytime of the day, without waiting on a status report. This is important for distributed teams that do not come into the office, or are located in different states (or countries). This is much better than just putting up a webcam on the whiteboard that you use to manage the backlog.

What do the various link types in Rational Team Concert mean?

2016-06-02T16:50:00.000-04:00

In an RTC work item, on the links tab, you'll notice several types of links you can create. When getting started with RTC, its difficult to know what link type to create. If the project area you are using is a LifeCycle project linked to an RQM and DNG project, you'll find even more link types that may make your head spin.

Basic Work Item Links For Just RTC

Let's get started with the basics. These links are used only in RTC, and do not link into the other CLM tools like DNG for requirements management or RQM for test management.

The first is the Add Related link.
This is the general purpose links two work items. This linkage type has no real context. It does not tell you why the two are linked. Is there a dependency between the two? Is one blocking another? Parent/child? Nope - no context. This is the link type you get when you mention a work item in a comment or description area of another work item.

Next is the Add Related Artifacts link.

This one allows you to link to external content, such as Wiki's, sharepoint content, Connections content, deployed URL's and such. This should ONLY be used for external content, not for URL links to other work items.

The one link you might rarely, if ever, use is the the SVN Revisions link.

This is for subversion code revisions. However, your organization may have most likely converted source from subversion (SVN), to RTC. If they have not, they should as RTC source code management is far superior than SVN.

Directional Links in RTC

You'll notice that many of the links appear in what looks like pairs. This is for a reason. These links are directional. Do you remember diagramming sentences in high school? Finally, here is where you get to use that knowledge! These linkage types provide context as to why the two are linked. For example, take the linkage pair Blocks / Depends on. These are reciprocal.

If you specify that Task 1 blocks Task 2, then on Task 2, we should see the link as "Depends On". Looking at this in the following diagram helps us to understand how to read the two in a sentence:

Directional relationship between RTC work item links

In this case, task 1 "blocks" us from working on or making progress on task 2. For example, let's say task 1 is to Install WebSphere Liberty on Staging Server. Task 2 is Configure Java EE security on the Staging Server. Obviously, we cannot edit the security configuration on the Liberty server if it has not been installed. This particular linkage type is what the built in work item query "Blocked Work Items" looks for. A project manager or Scrum master can see this view and will be able to better help the team prioritize work and remove obstacles to productivity.

If you understand this pairing of link types, then the rest become a bit more obvious.

The Resolves/Resolved By is commonly used on defects, where if you fix one defect, it effectively resolves another defect. This one is rarely used on anything but Defect work items.

The Duplicated By / Duplicate Of pair, indicate that one task or defect is an exact duplicate of another. This type of link is common when two different people have entered the same defect (perhaps worded slightly different). In this scenario, simply choose one as the duplicate. When one defect is marked as resolved, RTC will mark the duplicate resolved as well.

Lastly, we have the parent/child link types. These are special in that a work item can only have one parent (did you know work items were asexual?). A work item, however, can have multiple children. Child work items, in turn can have children, and so on. These also have special behavior properties in RTC, such that the RTC Project Administration (or JazzAdmin), can restrict the parent work item from being closed until all the children have also been closed. This is typically a good practice to have, especially for Stories with multiple tasks. A Story should not be closed until all the children have been completed.

Planning Links

The next group of links that are specific to RTC, are those that affect project planning. This means that work items with these link types will affect project plans and reports.

Let's start with the Affects Plan Item link type. This is typically used on a defect, to indicate that if affects a story or epic. Stories and Epics are plan items, whereas tasks and defects are execution items. A plan item is the when part of a requirement, as in "when is the requirement going to be implemented". The execution items are the "how do we implement the requirement". Plan items are measured in story points, whereas execution items are measured in hours. This link type is the reciprocal link type as Affected By Defect link type. This really should only be put on a story or epic to indicate that it is affected by a defect, and on the linked defect, it would have the Affects Plan Item link.

Next is the Contributes To and Tracks link types. This are linkages between cross-project plans, and allows you to have a work item track another Plan item in another plan or project area. The Contributes To allows you to indicate that a given work item (such as a task), contributes effort to another Plan item. That plan item may be in the current project, or in another project. For example, if you have two project areas, for two very different software projects, and there is a task to install infrastructure that both projects will be running on, we can say that the task "Contributes To" the stories in both project areas. This will allow the work item to show up in project plans in both project areas.

Formal Training for RTC

If you've been slogging around trying to learn RTC on your own, we recommend that you get some formal instruction on the product by a knowledgeable vendor who actually works with the product in the field.

Find out about RTC Training

Stop manual deployment or scripting deployments to WebSphere App Server - there is a better way

2016-05-16T15:37:00.001-04:00

Manual deployments suck

Lets face it, we've all had the "deployment weekend" nightmare. You plan for a half day of deployment, but it ends up turning into a day and half of wasted time because you've either missed something, deployed the wrong version, set the wrong environment parameter, or a late defect showed up that QA did not catch in the past week.Then you go home Sunday afternoon wiped out, and have to answer to your significant other (or your kids), why you were not at the event last night, or why you had to miss the kids game, etc. Manual deployments are error prone, weak, and frankly are a thief to your personal time.

Jython scripts work but are fragile

Hand scripting deployments to WebSphere application server using Jython (or JACL) can be time consuming, and are commonly fragile. As the application changes, so do the scripts that are used to deploy them. Then, if the developer who wrote them leaves the company (and you DO need a developer to maintain them), then how long do you think it will take to get a replacement up to speed? That is a skill that is hard to recruit.

Automate Deployment to WebSphere

While you may shake your head at purchasing a commercial product to do this, ask yourself this: "How much does it cost us in labor to do manual deployments?", or "How much does it cost us in lost revenue if we screw up a manual deployment?" There is a tool we have been working with and have been deploying at our customers. Its IBM Urbancode. Its simple to use and understand, thus there's no long ramp up time required to learn it. This means you can distribute the responsibility to kick of the builds across all the members of your team, and they won't have to sacrifice a weekend to run it. We love this because it allows your development and operations group to:

Reduce the amount of manual labor, resource wait-time, and rework by eliminating errors and providing self-service environments
Increase frequency of software delivery through automated, repeatable deployment processes across development, test and production
Deliver higher quality application releases with increased compliance through end-to-end transparency, auditability and reduced time to feedback

Oh, and while this post is in the context of Java/WebSphere, it also works on z/OS to deploy COBOL apps, Windows for .NET apps, Linux for LAMP apps and more. It also works with AWS, Softlayer, and more.

IBM Urbancode for WebSphere Application Server from Strongback Consulting

Easy peasy cross project linking and traceability in IBM CLM (RTC, DOORs, and RQM)

2016-04-22T14:58:00.001-04:00

For years, you've probably heard about "traceability", that mysterious shangri-la that are read about in case studies. Well, obtaining traceability is not rocket science in IBM's CLM tools. This video below shows you how to set it up at an atomic level, meaning, between specific artifacts between the three CLM applications. In a nutshell, you need to think of traceability as WHO, WHAT, WHEN, and HOW.

WHAT = Requirement in DOORs NG

A requirement defines what we are going to develop. It is the definition, the description of the software feature that gets implemented. This is most commonly done using User Stories (sometimes use cases). While DOORs NG has several other artifact types, the User Story Elaboration is the glue we want to adhere to.

WHEN/WHO = Story work item in RTC

If you have the full CLM stack, you'll likely be putting the full requirement text in the DOORs artifact. If you only have RTC, then follow our previous advice on Writing User Stories within IBM Rational Team Concert. In the case of full CLM, however, the Story merely represents when the requirement gets implemented, and who is responsible for completing it. The details of the Story work item in RTC are linked to the User Story Elaboration in DOORs. We will leave to your team's discretion to copy the details into the body of the story work item, however, we do encourage you to copy the acceptance criteria into the acceptance area, if you have not already captured it.

HOW = Test case in RQM

Finally, the HOW is the test case that confirms how (or if) the story implemented the requirement. The test case depends upon good acceptance criteria. If provided, the test case and scripts can be written in short order.

BONUS: WHERE = deployment via UrbanCode

So, as a final bonus, you may be thinking "but you forgot the where part". While Urbancode is not part of the official package, it certainly should be part of the solution. This defines where the code gets deployed. If you are unfamiliar with it, Urbancode is a deployment automation tool, that can handle deployment to multiple environments. It can reduce your deployment time by as much as 95% by automating all the manual tasks required to push a product into an environment.

IBM CLM Linking And Traceability from Kenny Smith on Vimeo.

In a future video, I'll demonstrate a scenario where we can link at a higher level using Requirements Collections, Sprint Plans, and Test Plans. This level of linking helps to visualize gaps in a test strategy, ensure accountability on the implementation of requirements, and identify stories that are affected by defects.

Configuring Release Numbers in Rational Team Concert

2016-04-15T17:23:00.000-04:00

The defect work item in Team Concert has a attribute labeled "Found In". This field is not populated by default, and often causes confusion for new users. The intention for this field is to tell the development which release the defect was found in. Thus it's important to understand, that RTC will certainly not know what your release numbering is when you install it. This has to be configured by the RTC project admin or release engineer. This video shows how to configure the release numbers in the project settings of Team Concert. If you have not configured a release nomenclature, it is best to do so before configuring this section. Also, if you are using IBM Urbancode, you will want to use the release names as they are deployed from Urbancode.

Release Numbering from Kenny Smith on Vimeo.
For more information on RTC, see our Collaborative Lifecycle Management solutions, and DevOps solutions over on our website.

Strongback Website Update: new Devops solutions

2016-04-07T14:58:00.003-04:00

We have finally updated our website to address the services we've actually been doing over the past few years. For so long, we've neglected the content on the website, frankly, because we were too busy. Now, after a couple of weeks of intensive work, we finally have content that reflects what we really do and what want to do. Yes, we still do Enterprise Modernization, including advanced deployment and customization of HATS applications and adoption strategies for RDz and RDi. However, we've expanded our whole DevOps approach to include service offerings such as:

We also have some rather new offerings that are purely services oriented. We now offer extended WebSphere Application Server 6.1 support for customers who cannot migrate to later editions due to third party software limitations. We also now offer remote DevOps Software Management for customers that cannot justify hiring a full time resource just to manage their RTC, RQM, DNG, or Urbancode servers.

There are other goodies in there as well that you may or may not notice. Of course, we spent some time on better URL navigation, analytics, and SEO. But it should be much easier to find out exactly what solutions we offer.

In the coming weeks/months, we'll also be adding new pages to the Industries area, as well as more case studies. In the meantime. Go ahead. Take a peek and let us know what you think!

InterConnect 2016: Tips for Developing and Testing IBM HATS Applications

2016-03-28T11:29:00.000-04:00

This is from our presentation at the InterConnect 2016 conference in Las Vegas, February 2016.
IBM Rational Host Access Transformation Services (HATS) can dynamically transform your terminal-based applications into rich web pages. It is highly customizable and built on Java EE technology. We discussed some lessons learned from a very (very) complex HATS engagement. We also discussed proper development strategies, and how to distribute workload across team members. We'll introduce a novel approach to unit testing advanced customizations using JUnit, and will also talk about how to address functional testing.

Tips for Developing and Testing IBM HATS Applications from Strongback Consulting

If you would like the source code examples used in this presentation, please contact us.

Creating and Sharing Work Item Queries in Rational Team Concert

2016-03-15T14:37:00.000-04:00

Rational Team Concert uses work items as the "glue" to bind various artifacts together. It links source code change sets to tasks, tasks to user stories, defects to test plans, stories to requirements.

Work item queries allow you to easily create repeatable searches into the RTC system for just about any work item type and attribute that you can imagine. Queries, once created, can then be shared with colleagues, other teams, or the entire project.

This video demonstration shows you the following:

Where to find work item queries
How to create and save a query
Sharing queries with individuals or teams
Work with query conditions
Full text queries
Querying on traceability links
Change column orders and column sorting

Rational Team Concert: Managing Work Item Queries from Kenny Smith on Vimeo.

If your organization is just evaluating team concert and would like to learn more, or understand what it will take to implement RTC successfully in your DevOps organization, then please contact us.

Additional helpful links on work items and queries:

Work Item Tracking in RTC

IBM InfoCenter: Creating work item queries

Quick Query Syntax for the My Work View in Quick Planner (v6)

Advanced User's Guide to Querying Work Items in Rational Team Concert

Video: Creating and using personal dashboards in IBM Team Concert

2016-03-14T12:07:00.001-04:00

This video was requested by a customer to show their employees how to create a personal dashboard from a project area. These videos are in the public domain by intention, and thus our ability to share it with you. In this situation, we created a custom dashboard template in the project area's configuration. Widgets were placed in a 3 column layout, and the widgets settings are automatically created using mementos (which are predefined settings for the widget). This allows us to have a single, consistent dashboard that provides a common instrumentation for everyone to understand. We can place widgets that are backed by our team's work item queries, specific to this project.

Creating a Personal Dashboard in Rational Team Concert from Kenny Smith on Vimeo.

Writing User Stories within IBM Rational Team Concert

2016-03-11T09:33:00.000-05:00

First Rule: Write Good User Stories

If you are just getting started with writing user stories, I highly recommend Mike Cohn's book User Stories Applied: For Agile Software Development. Perhaps you're coming from a background of writing large use cases. Perhaps you're fresh out of school and not familiar with requirements management.

If you're already familiar with user stories and want to take requirements management to the next level, check out Dean Leffingwell's book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)

INVEST in the content of the user story

While I won't cover the book here in this blog, I will emphasise a few key points that are important to understand when working with RTC. In it you will learn about the INVEST mnemonic, which is an acronym to describe the quality of the user story.

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N	Negotiable	User stories, up until they are part of an iteration, can always be changed and rewritten.
V	Valuable	A user story must deliver value to the end user.
E	Estimable	You must always be able to estimate the size of a user story.
S	Small	User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T	Testable	The user story or its related description must provide the necessary information to make test development possible.

RTC itself is merely a tool. The content of the tool is only as good as what the analyst puts into the tool. Garbage in - garbage out. If you learn anything from this blog, learn the INVEST mnemonic and stick to it.

Here is an example of what a simple user story would look like. A story has 3 C's: the card, the conversation, and the criteria. At the top of the index cards is the name of the story. On the front of the card is the conversation with the stakeholders, elaborating on this need.

Taking this approach, here is what this user story would look like in the RTC story:

As you can see from above, the the entire content of the front of the card is placed in the Description field. We've put the "what" of the card in the Summary line for brevity (this makes it easier to find in work item queries). But what about the back of the index card (i.e. the criteria)?

Acceptance criteria

This is likely the most neglected step in writing a user story. The back of the index card is where we should be putting acceptance criteria. This has the format of the card shown here to our right. This establishes conditions for when a person interacts and performs a series of operations, what should be expected out of the system.

We can take the acceptance criteria content and put it on the RTC user story like this:

Acceptance criteria makes it much easier to create test cases. Whether you manage your test cases in spreadsheets, in HP ALM, or (our preference) Rational Quality Manager, having the analyst and stakeholders document what their criteria for acceptance is, makes writing the test case much more efficient. While it is easy to write test cases that test conditions that the stakeholders may never think of, if you don't test for the conditions they require, you'll never deliver a product that satisfies the target audience.

Additional References for User Stories

These links below are to help you with the content of your use cases. Again, the 'bible' of user story authoring is Mike Cohn's book listed above. All the information below follow from its cannon.

Agile Requirements Decomposition from Rick Austin

Slicing and dicing your user stories from Jenny Wong

Other useful resources:

http://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing-user-stories

http://www.softed.com/Resources/Docs/A%20rough%20guide%20to%20elaborating%20stories%20on%20agile%20projects.pdf

http://kingsinsight.com/2010/12/03/elaborating-user-stories-by-using-acceptance-tests/

Lessons in how NOT to implement IBM DevOps tools (Antipatterns)

2016-02-25T18:31:00.000-05:00

This week we presented at the IBM InterConnect conference in Vegas. This was information compiled from multiple customer engagements over the past few years.

Patterns and Antipatterns for Adopting IBM DevOps Ttools from Strongback Consulting

If you are looking to implement the IBM platform as your Application Lifecycle Management platform of choice, and need help or direction, please contact us. We'll help you get it deployed right, the first time.

What does it mean to "Shift Left"?

2016-02-22T20:49:00.001-05:00

If you are at IBM InterConnect, you'll frequently hear the phrase "shift left". Its meaning may go over your head at first, but here is what it means.

First, take this chart:

Everyone has heard this before, but the latter in the development cycle a defect is caught, the more expensive it is to fix. In the chart above, as you move from left to right, the cost goes up. Thus, when we say "shift left", we mean, reducing the cost of development and maintenance of software by invoking testing earlier in the development cycle.

How do we do shift left?

The farthest left we can push is to Unit testing. Unit testing is the process of a developer creating a code to test other code. It is developer driven, but is something that can be automated as part of the build cycle. There are numerous open source and commercial unit testing solutions out there, including JUnit, cppUnit, xmlUnit, nUnit, and zUnit. Oh... you don't know what zUnit is? Well, that is a xUnit type framework for unit testing COBOL and PL/I on the z/OS (mainframe). Yes. I you read that correct. Mainframe unit tests. Watch the video conducted by our friend Jon Sayles for more information:

Unit testing is an amazing, misunderstood and grossly undervalued type of testing. It BY FAR is the most valuable testing that you can do. It will actually accelerate development, not retard it, which may be contrary to your initial thought.

However, unit testing may not cover every possible scenario. It certainly may not catch security, or performance testing needs, nor will it solve the overall 'black box', or user acceptance testing (UAT) need. This is where commercial tools such as Rational Test Workbench, and Rational Test Virtualization Server come into play. Test Workbench can test the UI from the browser perspective and run through various scenarios with multiple data points. Service virtualization creates stubs of the dependent systems (such as MQ, or the DB2 instance) such that you can call the the system under test, without invoking the dependent systems. The stubbing features work on all systems (including mainframe) and can stub entire subsystems (MQ, DB2, CICS, etc). This lets you you truly test the software you are developing in isolation.

The next pillar to shift left is automation. Automating this into your DevOps continuous deployment pipeline such that these tests are conducted before any manual tests are conducted means spending le$$ money on regression testing, and thus catching the defects earlier in the cycle. This is shifting left.

If this sounds of interest to you, let us set up a demo or consultation and show you how it can benefit your organization.

Our sessions at IBM InterConnect 2016

2016-02-19T10:49:00.001-05:00

For those of you going to IBM InterConnect next week, we will be presenting the following sessions.

Session Schedule

Number	Title	Where	When
2365A	Patterns and Antipatterns for Adopting IBM DevOps Tools	Mandalay Bay SOUTH - Surf Ballroom A	Wed, 24-Feb 08:30 AM - 09:30 AM
2381A	Tips for Developing and Testing IBM Host Access Transformation Services Applications	Mandalay Bay SOUTH - Surf Ballroom A	Mon, 22-Feb 10:30 AM - 11:30 AM
2496A	The Skills Dilemma: A Panel Discussion with Peers and IBM Experts	Mandalay Bay SOUTH - Lagoon L	Tue, 23-Feb 10:00 AM - 11:00 AM

What are these sessions about?

Patterns and Antipatterns for Adopting IBM DevOps Tools

In this, we discuss our experience implementing various DevOps tools including Rational Team Concert, DOORs Next Generation, RDz, RDi, and other editors, as well as concepts regarding Agile adoption. We'll cover what you should do, as well as examples of what not to do.

Tips for Developing and Testing IBM Host Access Transformation Services Applications

This is geared towards the audience with a general familiarity with IBM HATS. We'll go over the general flow of designing different types of HATS apps from the simple to the complex. We'll also cover testing strategies and introduce a Unit Testing framework we wrote to test custom HATS Java code in isolation from the host system. This unit test framework saves a HUGE amount of wasted time from regression errors and helps to promote and ensure quality deep in the system. We also cover some gotchas on performance testing.

The Skills Dilemma: A Panel Discussion with Peers and IBM Experts

Here, we're on a panel with others members of the IBM community (business partners and IBM'ers) discussing how to get over the skills hurdle, how outsourcing is not a panacea, and how your organization can better prepare for the business challenges ahead.

We look forward to seeing you next week!!

Anti-pattern: Using the IBM Rational Jazz Tools in Place of a Help Desk Suite

2015-10-20T10:52:00.001-04:00

A common anti-pattern for the Jazz tools (RTC, RQM, and DNG) is using them in place of a true help desk application. Help desk apps are designed to handle the recording of calls to the desk, categorizing the problems, and assisting the call agent with remediating those problems. In some cases a help desk system can offer self-service functions to the end user, alleviating the load on the help desk.

The Jazz tools are designed to manage software application development lifecycle, collaboratively. As such they have specific functions, and subsequent licensing that should not be exposed directly to the end user (these licenses are not cheap). Rather, a role of the help desk should be separating help desk calls from true software defects. With a help desk system, an organization wants to capture the nature of EVERY call. Using RTC to capture the contents of every call is ludicrous (and expensive). It is like using a screwdriver, when you need a hammer. RTC makes for a mediocre (at best) help desk.

Help desk items tend to have multiple different types of calls:

User error (RTFM)
Inquiry ("How do I do this? Where are the manuals? When is training?")
Facilities management questions ("The accounting department's A/C is not working")
Occasional wrong number
Defect in COTS (which requires remediation by the vendor of the product)
Defect in actual software that is written by the organization, and needs to be remediated
Request for enhancement (which can be further categorized)

As you can see, all but the last two categories are not relevant to any of the Jazz tools. As such, the Jazz tools should not be used as a first line of defense for help desk. However, for these two last issues, there is an opportunity for collaboration, whereby the data entered into the help desk can go right into RTC as a defect, or task and save on data entry errors, while capturing linkage between the RTC defect and the help desk ticket.

The key here is having a help desk system that is capable of doing just that. That is where the IBM Control Desk comes into play. Control Desk is a suite of components including one that integrates with the Jazz tools via OSLC. The Service Request Management feature provides full help desk management functions, including routing of tickets to appropriate queues.

Here is an overview of Control Desk's Service Management features:

The Tivioli Service Request Management is a piece of Control Desk that allows integration with the Jazz tools. This video belows describes how, in the process of a help desk call, the CCR can route a ticket into RTC as a software defect. By using the OSLC interface, the CCR creates a defect in RTC, via Control Desk. The work item is linked to the ticket and vice versa. This is very helpful for the software developer, as he/she can navigate bidirectionally to understand the nature of the problem, and the collaboration that has taken place previously (without having to wade through hundreds of email chains).

The cost of Control Desk makes this a highly competitive solution, and considering its features, a more complete solution than using RTC as a help desk. While you can customize RTC to act like a help desk, it will never provide sufficient features for the audience. When one considers the licensing cost, it especially makes sense.

If your organization has another help desk system, it is possible to integrate the two via the OSLC bridge API, which we have worked with in several prior engagements. However, it is important to understand that one must use the right tool for the right job, not customize a tool designed for a different job, when a cheaper, and more appropriate tool is already available.

For more information on RTC customization and help desk integration, contact us, and we'll be happy to work with your needs.

How to Install IBM DevOps tools with IBM Packaging Utility and Installation Manager

2015-08-31T13:50:00.001-04:00

IBM has an extensive catalog of desktop products, especially for application and database development. Some of those tools offer features and functions that can only be realized when combined with another product. In such cases, the products need to be installed into the same Eclipse package. This presentation shows you how to combine, deploy, and update these packages in a centralized manner.

Creating installations-with-packaging-utility from Strongback Consulting

For more information on Tivoli Endpoint Manager, or if you need help deploying your IBM Rational DevOps tools, contact us.

Unpacking IBM Software from Passport Advantage the easy way

2015-08-17T13:49:00.001-04:00

Some of the IBM software can include multiple multi-gigabyte files, all of which are required for installation. IBM Rational Application Developer is good example. Using the normal windows unzip functionality can make for a bit of a tangled mess of a download directory if you're not careful. I've been working with this software for over a decade and have a pretty simple way to make it go much easier.

First, make sure you have Java installed. Open a command line and type java -version. If you get a proper version report, you should be good to go. Otherwise, install a Java JRE, and ensure you have also installed the browser plugin to make the next step go easier.

Log into Passport Advantage and locate the software you've purchased. If you can, when downloading, use the Download Director option to make sure all the software is delivered into the same directory, and downloaded as fast as possible. Download Director uses a Java task to open multiple HTTP ports back to IBM to download multiple streams simultaneously. This can mean the difference between downloading at 200Kbps vs. 1200 Kbps.

Once the download has completed, open a command line and navigate to your DownloadDirector directory on your hard drive. Assuming you are using Windows, enter this command:

dir /b > unpack.bat

This will print the contents of the directory (mostly zip files) without any other attributes. Now, open the batch file in Notepad or Notepad2. Here is an example where I downloaded the RAD 9.5 beta.

Prepend jar -xvf in front of each file name. This calls the java jar command, which is much like a linux/unix tar command. In fact it uses nearly identical parameters (xvf).
x = extract
v = verbose (not really needed, but makes you feel like its actually doing something as the content whizzes by)
f = force

This will then extract the contents of the zip files into the correct directory structure. You can then run the installer or launchpad.exe to install the software. In the case of the RAD 9.5, the installer is located in the RAD_SETUP directory:

Once extracted, you can then delete the zips. However, I often archive the zips to a separate drive for further reference if needed. I never archive the extracted files - too much to navigate through and too fat to store.

Using JUnit to unit test IBM Rational HATS applications

2015-07-21T13:51:00.001-04:00

Why unit testing?

Any developer worth their salt, uses unit tests to validate that their code satisfies the task or tasks the code is supposed to do. Unit testing encourages modular development. Junit for Java was one the first and certainly the most well known. Other frameworks for other languages have popped up all over the industry for other languages (nUnit for .NET, cppUnit for C++, etc). I won't lecture on the benefits, but will refer you to other sites for proof:
Why not just use a debugger?
Why not just use System.out.println()?
Why use JUnit for testing?

Why it's difficult to unit test HATS

Not all HATS applications require complex testing. Many (and I mean MANY) HATS applications just use some simple customizations and one of the existing out of the box templates. Very few use anything more complex than a custom page template, and rarely ever use any custom Java code. This is quite normal. IF this is your scenario, and you have no custom Java code, then skip down to the bottom of the article.

However, some shops might need more customization than what is available out of the box. This is where some unit testing may be needed.

HATS relies on a runtime (Telnet connection) back to a host system. With JUnit, you really do not want to have to run a test that only tests a single class while having the whole system running and connected to the host. This is similar to issues with unit testing EJB 2.x, where you could really only test in a live environment and it required a secondary framework such as Cactus to get the results out of the live environment.

This can be overcome by using what's called mocking and stubbing. By that, I mean mocking the runtime connection and stubbing the API's results. Mockito and Powermock are excellent tools for mocking, and can be used with HATS to mock the runtime. However, there is a major hurdle in using this, it is because when running a JUnit test that uses the mocking framework, you'll run into a NoClassFoundException issue, where the mocking framework cannot stub a return result because it cannot find the class to stub. Fear not, however, as we've found the solution. Keep reading.

Introducing Mocking and Stubbing with Mockito

This presentation (courtesy of Richard Paul), covers Mockito pretty well. Mockito also has EXCELLENT JavaDoc detailing the ins and outs of using the framework (it is such excellent JavaDoc, I use it as an example of how a developer should be creating Javadoc for his/her custom code).

Mocking in Java with Mockito from Richard Paul

Mockito is excellent at creating concrete mock objects. One of the first things you may want to mock, is a specific host screen. This is detailed below. Mockito cannot, however, mock static classes. Those must be handled by PowerMock. Keep in mind, that there are several HATS API objects that are static, and you will have to use PowerMock to mock those items (such as the ECLPS class).

Mocking i or z Screens

When we were creating this framework, we came across a neat little constructor in the HATS API, that allows you to create a HostScreen object from an XML file. If you pass in an XML Document object to the constructor new HostScreen(), you will get an object you can then interact with. The HATS Screen Captures are XML files, but you must read them in, and get them into a org.w3c.dom.Document object. This little snippet above will do that for you.

protected HostScreen buildHostScreen(String fileName)

throws UnsupportedEncodingException, ParserConfigurationException, IOException , SAXException {

//Courtesy of Strongback Consulting - www.strongback.us

URL url=this.getClass().getResource(fileName);

String file= URLDecoder.decode(url.getFile(), "UTF-8");

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

DocumentBuilder builder = factory.newDocumentBuilder();

Document screencapture = builder.parse(file);

HostScreen hostscreen = new HostScreen(screencapture);

return hostscreen;

}

Overcoming a key HATS impediments (missing code)

So, if you've attempted to mock and stub, you will eventually run into a NoClassFoundException on com.ibm.eNetwork.HOD. You can try and look in the HATS runtime jar files (any of them), but you will not find it.

On a recent project, we were working with one of the HATS product architects and asked about this particular dilemma. As it turned out, the reference to this object is never used, and thus not ever included in the hatsruntime.jar, nor any included HATS jar files. It is a class that is part of the Host on Demand API, and only parts of that API are actually included in the HATS toolkit - only those that are actually used. By simply creating an empty class, we were finally able to get this mock to work!

Just create a new package, and a new class in the package as follows:

package com.ibm.eNetwork.HOD;

public class ScreenHistory {
//this is never used, but required to complete
//a mock object
}

Now, you should be able to build your mock object.

What to test

If you have a Java class that does not use any HATS API (such as a convenience class, a POJO, or utility class), then you likely do not need to mock it. However, there are several types of HATS objects that require mocking. These include:

Business logic - use the snippet of code above to help you create the HostScreen object
Custom Widgets
Custom Components
Custom Screen Recognition (yes, this is a real thing you can create to handle custom screen recognition if all the other options leave you dry)
Macro Custom Actions (yep, another thing you can create custom)

In general, not only can you mock these items, but you should mock the objects above. Testing them in a mock framework will prove highly fruitful. You can debug the code in isolation, without being connected to a mainframe or AS/400. You do need to gather screen captures first. This is beneficial also, because in some conditions, you might have to have different test data everytime you go to a specific screen. Mocking, allows you to use the same screen capture for multiple tests. Also, you can run through multiple scenarios in a single unit test. Just grab screen capture for each scenario.

Guidelines

Here are a few general guidelines to to help you with this process:

- "Pull up" common code into a super class, so all subclasses can reuse the same code (keep it D.R.Y.)
- It may not seem like it at first, but unit testing is FASTER than debugging in a live environment.
- Debugging JUnit code is even faster.
- Be sure to account for multiple scenarios.
- Make it part of your continuous integration plan - have Team Concert, or Jenkins run a build on every checkin of code.

Other types of testing to be concerned with

Unit testing only goes so far. It is not a replacement for full system testing, or security testing. Keep these testing types in mind also:

- Functional testing - RFT, and Selenium. RFT has the benefit of being able to run function tests against a telnet application (5250 or 3270). Reuse the same data in HATS
- Performance Testing
- Policy and compliance testing (ADA, screen readers, etc)
- Security testing (white box, and black box)

Strongback Presentations at IBM InterConnect 2015

2015-02-21T10:05:00.002-05:00

Strongback will be hosting two presentations this year. These are in the DevOps tracks, and in the Mandalay Bay side of the conference.

DAX-5162 : C-ing is Believing: Being Smart about C/C++ Development on AIX and Linux

Session Type : Meet the Experts
Date/Time : Tuesday Feb 24, 12 -12:50 PM (Pacific Time)
Venue : Mandalay Bay Expo Hall
Room : Dev Ops & CE Engagement Center

Abstract:
Finding talent for C/C++ development for UNIX systems can be a challenge. However, it does not have to be so difficult. Using Rational Developer, you can have more junior developers or cross-skilled developers do the kind of slick development that punches above their weight class. See how the productivity features of the editors far exceed what vi can do. See how static code analysis can reduce your defect cycle time to streamline code maintenance and improve the performance of your applications.

DAX-3966 : Green Screens? Verde Screens? Internationalize and Modernize Your Green Screens with Rational HATS

Session Type : Breakout Session
Date/Time : Thursday, 26-Feb, 10:30 AM-11:30 AM (Pacific Time)
Venue : Mandalay Bay
Room : Islander Ballroom H

Abstract:
Rational HATS is a solution to dynamically transform 3270 or 5250 green screens into rich web applications. It is a highly extensible product written in Java EE. We will show you how to extend the product to translate field labels on the fly into multiple languages. We'll also discuss the product's support for different character sets.

Making IBM Rational HATS A Strategic Investment

2014-10-17T10:30:00.001-04:00

Here is another presentation we did a the IBM Innovate conference in June 2014. Using HATS to create web services from 5250 or 3270 terminal applications is a common use case for HATS. You can also consume services either in the interface (i.e. RESTful or JSON), or through HATS macros or Business Logic (i.e. custom HATS Java code). HATS can also connect to relational databases using Business Logic. With the IBM i, you can also integrate with PCML (Program Call Markup Language) interfaced IBM i apps.

Making Rational HATS a Strategic Investment from Strongback Consulting

If you are interested in additional HATS related links and content, check out our Delicious.com links: https://delicious.com/strongback/hats. You can also find related content using the labels on the right hand side of this blog.

If you need assistance with your current HATS environment we can help there as well. Contact us!

13 steps you need to take to improve your web site performance

2014-10-15T09:48:00.000-04:00

Consolidate your CSS

There is no reason to have more than 3 stylesheets in your application (with a few notable exceptions). In most cases, 1 will suffice. If you have a CSS for every page, you are doing it very very wrong. CSS should be reused across multiple pages. If the page is supposed to have the same theme as another, just different content, then why have a different CSS? Refactor your CSS so that it applies across your website. This not only makes it less to download, but makes it more manageable in the long term.

What many neophyte web designers do not realize, is that every single Javascript, CSS file, and image file represents a separate HTTP call. A web page has to make multiple trips to a website, and does so serially. That means the more files from the same site, the more calls it has to make, and each call adds latency to the web page.

Consolidate your JavaScript

First, read the second paragraph above.
Second, look to see how you can reuse some Javascript functions. You might also delight in using a Javascript framework such as JQuery, or Dojo, which will make your Javascript writing more efficient, and allow you to reuse code that has already been written and perfected by someone else.

Use a CDN to host your JavaScript frameworks

Remember my comment about pulling down multiple files in serial? Well, its only serial if its from the same web site. If from another website, it can do so in parallel. If you are using a Javascript framework, you can pull it from a content delivery network (CDN) such as Google's Hosted Library. This also means less HTTP traffic on your network, and therefor less work on your servers. Keep in mind however, that this may not work well if your target audience is behind a firewall. Some firewall might prohibit access to these sites. In such situations, you could host a CDN behind your firewall, and even host your own customized Javascript libraries (or CSS libraries).

Minify your static files

The YUI Compressor is a great utility to compress static text files such as CSS, and Javascript. It can be run on a command line. This removes redundant whitespace from these files, and optionally redundant semicolons. This can save as much as 70% in file size transfer. Now, your first objection might be "but I can't read minified Javascript when I'm debugging!".

Well... duh! Don't minify it in your IDE, and certainly don't check in minified code to your SCM. Rather, make this part of your build automation, and minify it right before you package your WAR file. Add the following ANT lines into an ANT target (replace the variables accordingly). Then it gets minified on build, but yet is fully readable in your source editors and source code management systems.

<path id="yui.classpath">

<pathelement location="${yuicompressor.jar}"/>

<pathelement location="${yuicompressor-ant-task.jar}"/>

</path>

<yui-compressor warn="false" munge="true" jsSuffix=".js" cssSuffix=".css" preserveAllSemiColons="false" fromDir="${path.web}/common/js" toDir="${basedir}/js">

<include name="*.js"/>

</yui-compressor>

If you use CDN delivered Javascript frameworks, make sure you at least use the minified version in production.

Shrink your JSP's by moving styles into your style sheets

This is likely self descriptive, but the smaller your JSP, the less load on your application server. Move this into your CSS file. Same logic applies to Javascript functions in your JSP's. Move those functions into your JS files. Its easier to cache static content, than JSP's, thus taking further load off the application server. Also, only use an <img> tag if the image is part of the content. If its there for decoration, use a background-image attribute for a stylesheet.

Combine smaller images into a single sprite

Some web sites that have lots of small images that represent controls, or navigational elements. Many are less than 10px in width or height. These can be combined into a single sheet, and referenced as sprites in a stylesheet using the following syntax:

#home {
    width: 46px;
    height: 44px;
    background: url(img_navsprites.gif) 0 0;
}

This can dramatically cut down on the number of HTTP calls and subsequently cut down on the total page load time.

Shrink your images

High resolution images are important, when they are part of the content. If they are merely decoration, such as in the case of stock images for a business web site, lose the resolution, and save some bandwidth. That image of people in business suits poised over a conference table does not need to be high definition 1920px wide. Such images can be as large as 2MB. When they load in a browser, they will typically buffer (i.e. slowly render from top to bottom). Worse, if they are as images, or in imported stylesheets, the whole site will wait until the entire image is loaded. This adds the most unneeded latency. In some cases, you might only need a portion of the image, but just dropped the entire stock image in the directory for convenience. In this situation, crop the image to only the dimensions you actually use.

Replace images with CSS

I have a huge pet peeve with creating images of words because you want to use a font that is only available in Photoshop, or because you want some effect on the text. HTML5 and CSS3 allow you to use @font-face to load the font from a stylesheet on demand. The new standards also allow you to apply effects such as skew and text shadow Also, an image is not indexable, nor is it searchable by web crawlers, thus reducing your potential SEO. Remove the images, and put in simple text, decorated with CSS3 text effects.

Always, always, ALWAYS use an HTTP Server - never your application server transport chain

No matter the Java application server you use, it will not be as efficient at HTTP transfer as a true HTTP server. Period. The WebSphere Application Server's HTTP transport chain is not an HTTP server. It serves up content as HTTP, but this is a raw I/O channel. Rather, it is easy to setup the IBM HTTP Server (or Apache Web Server) to front end the traffic. It offers the benefits of URL Rewriting, caching, and load balancing to back end clusters. Even with Tomcat, you should use the mod_jk module (i.e. the AJP connector) to front end with Apache. I even recommend using an HTTP server in front of web services servers. This allows the web server to proxy information into one of possibly many servers in a WebSphere cell (if you use WAS), without having to call a specific port for a specific JVM member. This means that you can move applications around to different application servers to best meet the resource demands, without affecting the web services consumer.

Add a caching proxy for static content

When it comes to caching, the closer to the browser, the better. A caching proxy can cache images, style sheets, javascript files, and more for longer periods of time than a browser, and can intelligently cache it for multiple clients and applications. For example, if you have 50 applications in your environment and 20 of them use the same 10 images, and the same 5 Javascript libraries, then running traffic through an caching proxy means you save that much more traffic on your application server.

Move validation logic to the browser

Form validation is now highly mature in Javascript frameworks, and while you shouldn't necessarily remove the validation from existing Java code, you are well served to add client side validation. This means less round-trips back to the server.

Use WebSphere Dynacache or eXtreme Scale for dynamic caching

If you have data that cannot be cached, and must be calculated either on a session or application level, the WebSphere dynacache and eXtreme Scale are excellent tools to improve application response time. Both can be used to cache user session data, application context data, and more. Dynacache is included with all versions of WebSphere Application Server, but eXtreme Scale is bundled only with Network Deployment version. They do require some custom API calls to implement, and they do tie you to a specific application server. However, if you're going to need something this caliber, you're likely going to need the most scalable app server out there... which is WebSphere App Server.

Scan and analyze your Java based web app

We could certainly go into great detail on application maintenance, but we can summarize all these steps in one category: static code analysis. If you are running Rational Application Developer (RAD), you have one of the most powerful static code analysis tools on the market. This best kept secret of RAD is extremely good at finding common anti-patterns.

541+ provided rules
Integrated results view with click-to-source navigation
Explanations, examples, and quick fixes
Supports customer rule creation based on rule templates
Extensive context sensitive help
Produces HTML/PDF reports with violations and violation metrics
Supports configuration of rule sets for use in different scopes and environments
Run interactively or invoke from command line
Integrate with automated builds

A single run with this tool can identify defects and performance bottlenecks before they occur.

Fighting spam and hackers with FIRE(walls): How to reduce contact form SPAM.

2014-09-02T09:54:00.002-04:00

We've been having a hell of a time with Salesforce contact form spam as of late. Its been littered with junk about cheap Air Jordans, Louis Vitton bags, and other assorted hijack links. In the course of a week, we could have as many as 300 new "leads", all of which were spam, and that was after instituting form validation on all the contact fields.

So, the next step was to find out where this spam was coming from. By adding a hidden field to the form, and tying it to the lead source, we were able to capture the IP address of every submitter. Well, most of the submitters were coming from this little village in Fuzhou China. You can find the location of such IP addresses from http://addgadgets.com/ipaddress/index.php.

If you use JSP in your site, here is the code to capture the IP for your Salesforce Web2Lead form:

<%
String ipaddress = request.getRemoteAddr();
%>
<input id="lead_source" name="lead_source" type="hidden" value="<%=ipaddress%>">

So, the next step was to block the IP. This can be done via IPTables in linux. As these addresses were found in predictable blocks, we decided to block more than just the IP addresses listed. Instead we blocked entire countries. Yep. If you are reading this, then you are likely not blocked from our web site.

This website had an excellent shell script that handles all you need to block any specific country.

Iterates through the countries you specify
Gets the IP address blocks assigned to that country.
Adds the block range to IPTables
Recycles your IPTables to ensure a clean, fresh instance.

This script can be run via chron job (perhaps monthly) so the list always stays current. We chose a block of 15 countries based on the fact they were the most frequent countries for spam and hack attacks. These are also 15 countries we have no intention of doing business in.

References:

The top 9 spamming countries.

Leading countries of origin for unsolicited spam emails as of 1st quarter 2014, by share of worldwide spam volume

Linux Iptables Just Block By Country

IBM Innovate 2014: How to become a Rational Developer for IBM i Power User

2014-06-11T14:13:00.000-04:00

Moving from SEU/PDM to Rational Developer for i?

This month we presented at the annual IBM Innovate Conference in Orlando several topics on the various IBM Rational tools. Rational Developer for i (RDi) is the IDE of choice for editing, verifying, analyzing, and managing RPG, COBOL, and C/C++ on the IBM i (i.e the AS/400). If you come from a SEU/PDM development environment and are looking to move to a more robust IDE, or if you wish to use the new RPG language features, you need to read through this to learn how to adopt the product. In this presentation we cover the new features of RDi 9.1, including the new debugger and code coverage tooling. We also demonstrated editing features of the LPEX editor, such as find/replace with regular expressions. We covered the screen and report designers as well.

How to become a Rational Developer for IBM i Power User from Strongback Consulting

The Caffeinated Mainframer: Using Java on IBM z/OS to build enterprise Java apps

2014-05-23T13:50:00.004-04:00

At last year's IBM Innovate Conference (formerly the Rational Software Developer's Conference), we presented this deck about using Java on the z/OS mainframe. Since that time there have been a couple of major releases of the IBM Rational Developer for Enterprise product and at this year's conference there will be extensive coverage of version 9.1 of the Rational IDE's. These new versions were just announced and went live for general availability this week.

If you will be developing on Java on z/OS and need to access MVS datasets, be sure to read through the presentation below, and it is a good primer on the platform.

The caffeinated mainframer from Strongback Consulting

If you develop Java on the mainframe, check out our link collections on Delicious:
https://delicious.com/strongback/jzos
https://delicious.com/strongback/rdz
https://delicious.com/strongback/java

CFO's: Do you bear criminal negligence in not updating your developer workstations?

2014-02-12T16:49:00.000-05:00

Why is your company dragging its feet to update the corporate desktops or laptops? If you are a CFO, or CIO, you are not getting the most out of your application developers, software engineers, and systems administrators. In fact, you're paying your staff to watch progress bars. You are also more likely to lose the really good employees because of it. You are wasting money. And if you are a CFO, you are guilty of neglect, shirking your fiduciary responsibility to your shareholders, owners, and/or board of directors.

The first thing to know about provisioning hardware is that it is sheer idiocy to give developers the same laptops/desktops you give your sales/marketing folks. It is the failure to give them enough power to do their jobs. It is the CFO's fiduciary responsibility to seek maximum productivity out of their developers.

Allow me to explain further, The cost of a well provisioned desktop, including dual monitors, can be under $2,000 (actually under $1500 with a good volume purchasing discount). Compare this to the total cost of ownership including IT service maintenance and software licenses which can be up to $9,900 per year according to a study done by Gartner. As you can see, the cost of equipment, when compared over a 3 year depreciation cycle is only fraction of the total cost of ownership.

Other costs to consider, is the average turnover cost. In the United States the average annual corporate turnover rate is 13%. That is across all industries. In specific job categories (such as call centers), the rate is slightly higher. A company will spend up to 20% of a person's salary on hiring fees just to get them in the door. This means that, for a software engineer, the amount of time the employee stays with you will be short lived. This is all the more reason to maximize the productivity of the software engineer while he or she is on staff at your organization!

This is what your developers should have, and why.

1) A quad core processor CPU

Developers do much more than just read email. They will typically have 5-20 applications open at a time. Each of those applications requires at least one CPU processor core to run. The more applications you have running, the more competition for those processors. A quad core Intel i7 has four cores, and with hyperthreading technology, and run a total of 8 processor threads (2 threads per core). This is four times the number of threads that the older dual core processors offered. This means less progress bars. It means more lines of code from your developers.

2) 64bit OS, Windows 7/8, or MAC OSX (or Linux Desktop)

If you are on Windows XP, your company is at risk from technology, security, and financial factors. Your competitors are eating your lunch. Microsoft no longer offers support for Windows XP. No software vendor is writing new applications for the platform. It is a DEAD platform. Your IT strategy should be leading you in a way the becomes near operating system neutral. Email clients now exist for all three platforms listed above, as well as office suites. Everything else should be, or is likely to be running in a modern web browser.

3) External, larger monitor

Your developers likely are working in multiple applications. They need multiple apps open at the same time, and in some cases, need to reference data in one app to code into another. There are several studies that show productivity increases with a second monitor.

These recommendations above are by no means complete, but are certainly the highest priority items most software engineers would need. Other nice-to-haves include a solid state drive, more memory (16GB), faster ports (Thunderbolt, USB3.0, eSata, DisplayPort, etc). Get the real needs from your team.

As a consultant, I've seen more than my share of developer desktops that were underpowered, and as a result, the developer was downright discouraged, and cynical about the importance they served the organization. It is very frustrating to have a company purchase new development tools (and spend thousands per desktop in doing so), and put it on crappy hardware. Often times it will perform so poorly that the software will go unused. Then the consultant gets blamed for selling shelfware.

So... stop reading, and go get a pulse on your developers. See if they have what they need. If you see them "waiting" for progress bars, on tiny little monitors, then its time for a visit from your hardware vendor.

Disclaimer: Strongback Consulting does NOT sell hardware (software, yes). We recommend developing a positive relationship with a quality vendor who can tailor a solution to your company, and your developer's needs, and there are plenty of vendors willing to do just that. Good luck!