New Year’s Resolutions for Developers

By | Development, Enterprise Mobility

I am not big on New Year’s resolutions, mainly because if you need to change something, don’t wait till the new year, just make the change. While I was driving home from vacation, stuck in traffic, I started wondering what the development teams I work with can do differently in the coming year.  Thinking about what we should focus our energies on,  I came up with some “resolutions” for the new year. As with any resolution or goal, not all are needed to be completed or followed, but as a developer, if you can accomplish any of these, you will improve your development skills and also help teach the developers that follow you.

Read More

Take aways from a Friday Code Review

By | Development, Enterprise Mobility

Do you do code reviews? If so, why? What do you benefit from your code reviews?

Most companies do code reviews to prevent future program errors, but in my opinion a major benefit of code reviews is to ensure the code is maintainable, that others can read and follow the code.

If you have not read the book Clean Code by Bob Martin, I highly recommend it, as it will give you techniques for writing maintainable code.

code reveiwCode Review Fridays

Here at BlueFletch we have a standing weekly code review meeting.  The engineers meet as a group and review some portion of code from a current project.  This meeting does not replace individual project code reviews, but is meant to benefit everyone in the company not working on the project.

Some of the benefits are:

1. See what others in the company are working on
2. Get insight into different technologies
3. Get help with a tricky piece of code
4. Ideas on doing a project differently

During our code reviews we look for the following items:

1. Readability — is the code easy to read / follow
2. Maintainability — can our customers easily maintain it
3. Usability — are the classes easy to use, are they overly complicated?
4. Does the code make sense?

Additional items we look for can be found here

A Recent Review

On a recent Friday we reviewed a couple of Android projects we inherited from other companies. As per our practice, we reviewed the code from the aspect of clean code and best practices, discussing how we would make the code maintainable and easier to read.

During the review four major issues jumped out:

1. Pyramid of doom
2. Project organization
3. Code Reuse
4. Hardcode Strings

code reviewPyramid of doom (or Callback Hell)

Every engineer has run into this, regardless of the language or platform, you have a function that has many, many levels of indention. This could a HUGE if statement with many conditions or a series of callbacks within callbacks. The deeper the code, the harder it is to follow and maintain.

Example:


if ( conditionA) {
    if ( conditionB ) {
        if ( conditionC ) {
            block of code doing something 1
         } else {
            if ( conditionD ) {
                block of code doing something 2
            } else {
                block of code doing something 3
            }
        }
    } else {
       if ( conditionE ) {
            block of code doing something 4
       } else {
            block of code doing something 5
       }
    }
}

 

Tip: If you find yourself coding such a monstrosity, STOP! Refactor the code. Start with the inner code and place the code into separate methods. Yes, you end up with more methods, but the code will be more readable, and with smaller methods you get code that is easier to write unit tests.

A possible rewrite (one of many ways, but easier to write unit tests):

..
 if ( conditionA) {
    methodConditionA()
 }
..

methodConditionA() {
   if ( conditionB ) {
       methodCondtionB()
   } else {
       methodCondtionE()
   }
}
methodCondtionB() {
    if ( conditionC ) {
       methodHandlerProcssingLogic1 ()
    } else {
       methodCondtionD()
    }
}
methodCondtionD() {
    if ( conditionD ) {
        methodHandlerProcssingLogic2()
    } else {
        methodHandlerProcssingLogic3()
    }
}
methodCondtionE() {
    if ( conditionE ) {
        methodHandlerProcssingLogic4()
    } else {
        methodHandlerProcssingLogic5()
    }
}
methodHandlerProcssingLogic1() {
    block of code doing something 1
}
methodHandlerProcssingLogic2() {
    block of code doing something 2
}
methodHandlerProcssingLogic3() {
    block of code doing something 3
}
methodHandleProcssingLogic4() {
    block of code doing something 4
}
methodHandlerProcssingLogic5() {
    block of code doing something 5
}


 

Project organization

Within one of the projects we reviewed, there were 67 fragments, all within one package. For non-Java programmers, imagine 67 code files within one folder, with the files having similar names.

There were 11 fragments referring to devices; 4 related to signing in; various fragments for product registration, and 2 About fragments.

How are these 67 fragments related? Which ones need to be looked at when enhancing a feature of the application? Where do we start?

Tip: How you organize your code can help those that follow. If you make it easier to identify features and/or the process flow, then those that follow will be able to understand your project.

If the engineer building the project had separated the fragments out by features or relating the code in some manner, then working with the project would be easier.

Some suggestions for organization include placing all the “User” related (sign in, forgot password, account creation) into one package.   Place settings related fragments into another package.  Place device related fragments into another package.

Get the idea? Organize the project by context.

Code Reuse

Within one of the projects we reviewed the code utilized simple REST API calls to gather data. A simple pattern of URL creation with HttpUrlConnection classes and code to handle the result.

After some research we noticed the same endpoint was used in multiple places. Then we found the same exact code pattern, almost line for line, in 15 other places.  The code had been copied from place to place, with minor changes to suit the need.

And there was a bug within the code that required a major change within each piece of code. Yuck!

Another project we reviewed had a common error message display, but the display code was copied into each Activity (25 code files). Imagine if they decided to change the look/feel of the error display, 25 code files would have to be updated and tested. Dooh!

Yes, as software developers we need to get things done fast, but the consequences of copying code from one part of the project to another will cause you headaches down the road. As no code is perfect, at some point it will need to be fixed or enhanced, how many places do you want to make changes?

Tip: if you find yourself copying a block of code from one part of the project to another, almost line for line, then build a reusable code object, either a new method, a new base class, something common. This will reduce the amount of code to maintain, and if a bug does arise, you have one location to fix it.

Hardcode Strings

Imagine opening a code file for the main activity of a project and having to scroll through 1,300 lines of hardcoded string literals? Yes, we had to do that during our code review.

We as engineers get lazy, we need to add a new UI label or a new error message, instead of doing it correctly we put the text directly in code. It never fails, later the project needs to be localized and now you have to pull all the strings out to a string resource file. How time consuming! How much time does it take to add the initial string to the resource file, less than a minute?

Tip: Take the time up front, do it right, and for the sanity of the engineer that follows you into the code base, do not hard code 1,300 lines of string literals into the main activity.

Conclusion

As software developers/engineers, we should take pride in our code. We should build our code to be readable, maintainable, and testable. Doing code reviews either as a group or individually will help you and others to learn and improve code.

And please: organize your code, write reusable modules, do not hard code strings, and break down your large unruly code blocks into smaller methods.

Specifying your Android Host URL using Gradle

By | Development, Enterprise Mobility

Using Gradle has many cool features, the one that I really like is the ability to change configurations based on build type (release or debug).

Background

One of the headaches of building Internet enabled applications is pointing your application to a different API service based on the stage of development. For instance, for a QA build of a product I have had the need to point an application to a QA API Instance, or during initial development of APIs, to a development server. There are many ways to accomplish this, from reading a configuration file loaded on the device or changing a string resource to a new host. But I have started using my Gradle configurations to point my Android applications to different API host servers.

Gradle

Common Configuration Switching

A common method for switching host configurations is a complicate if statements:

if (BuildConfig.Debug) {
… use host A
} else {
… use host B
}

Of course, using this approach has many downsides, one of which is ugly “if” statements scattered through out your code. And when you have multiple flavors of the product with different debug versus release host API’s, it can get really ugly.

Another method is to use string resources that are loaded per flavor of build. A debug resource string file could contain Host A URL, which Staging flavor could contain Host B URL. This keeps the complicated if statements to a simple string load. But now your URL’s are in different files, and maintaining the multiple files always leads to ‘which is getting loaded’, ‘what is the current host’, etc.

This is where Gradle configurations can help clean up the code, and to me the main benefit is there is one source of truth of the host configuration settings.

Read More

The Magic of Splunk: How to ignore incoming data

By | Data & Security, Enterprise Mobility

Splunk is a very robust tool for digging into data. You can customize it to search a variety of data formats, and using the results you can accomplish many tasks, from producing pie chart reports to generating email alerts.

During a recent project I had the task of building a reporting dashboard reflecting server status. As I did not want to impact the production Splunk system, I spun up a test instance on a QA box.

For those that do not know, Splunk allows you to use the software for free, as long as the amount of data being indexed (flowing in) is less than 500 MB per day. See the downloads page here for more information.

Perfect, I had my own environment. I built my reports, dashboards, alerts, etc., with no impact on the production systems.

 enteprise mobile app development, enterprise mobility solutions

The Situation

Due to unforeseen circumstances, I needed to keep this development instance running longer than expected. As I didn’t want to chance hitting the 500 MB limit I decided to block anyone from “accidentally” placing data into it.

Splunk does provide a mechanism for blocking incoming data, but the documentation is not straightforward in explaining how to achieve this, think: This thing reads like stereo instructions” (youtube).

The solution is not truly blocking data, but ignoring incoming data.

The Steps

Ignoring the incoming data is a two-step process. First you need to tell Splunk which data your interested in, and then you need to tell Splunk what to do with the data.

To accomplish step one, which data, I updated the props.conf file. Within this file I added a ‘stanza’ (or rule) identifying the source of the data. Once this was accomplished, I had to tell Splunk what to do with the data. Using the keyword ‘transform’ within the matching stanza, I could accomplish this.

Here is what my props.conf looked like. The first stanza defined my data, and if a match occurred the data would be transformed by ‘setparsing’. The second stanza matches any other data and transforms it by ‘setdevnull’.

props.conf
[code]]czoyMDI6XCINCiMgTXkgRGF0YSAtLSByZWd1bGFyIGV4cHJlc3Npb24gdG8gbWF0Y2ggbXkgZGF0YQ0KW3NvdXJjZTo6LlxcL215ZGF0e1smKiZdfWEvZm9vL2JhcipdDQpUUkFOU0ZPUk1TLXNldCA9IHNldHBhcnNpbmcNCiMgRXZlcnl0aGluZyBFbHNlIC0tIHRoZSBzb3VyY2UgaXN7WyYqJl19IGEgY2F0Y2ggYWxsDQpbc291cmNlOjouKl0NClRSQU5TRk9STVMtc2V0ID0gc2V0ZGV2bnVsbA0KXCI7e1smKiZdfQ==[[/code]

Now for the second step of ignoring the data. This is done within the transforms.conf file. Here you can tell Splunk how to manipulate (or transform) any data. By default, Splunk will index data, but in my case, you can tell it to ignore the data. To ignore data, you must send the data to /dev/null, which Splunk calls ‘nullQueue’.

Here is what my transforms.conf file looked like:

transforms.conf
[code]]czoxNzY6XCINCiMgU2V0IFBhcnNpbmcsIEluZGV4IHRoZSBkYXRhDQpbc2V0cGFyc2luZ10NClJFR0VYID0gLg0KREVTVF9LRVkgPSB7WyYqJl19cXVldWUNCkZPUk1BVCA9IGluZGV4UXVldWUNCiMgU2V0IERldiBOdWxsDQpbc2V0ZGV2bnVsbF0NClJFR0VYID0gLg0KREVTVF9LRXtbJiomXX1ZID0gcXVldWUNCkZPUk1BVCA9IG51bGxRdWV1ZQ0KXCI7e1smKiZdfQ==[[/code]

Notice the DEST_KEY, this tells Splunk we want to deal with data going into the ‘queue’, data that is to be processed/indexed. Then the FORMAT keyword, we set to either ‘indexQueue’ (send it to the indexer) or ‘nullQueue’ (ignore it).

I tested this by sending in the access log from a web server, and that data was not indexed, WOOT! But my data was not indexed either, OOPS!. What did I do wrong?

The way Splunk works is it processes incoming data against the props.conf file linearly, one stanza at a time. The last stanza “matched” wins. So the last stanza to match was of course “Everything Else”, therefore all data was sent to /dev/null.

The easy fix would be to move my stanza to the end, but that is too easy. Looking through the documentation for props.conf, Splunk has the concept of ‘Priority’, which allows you to prioritize the data matches. I updated my stanza to contain priority=100 for my data.

props.conf
[code]]czoyMzU6XCINCiNNeSBEYXRhIC0tIHJlZ3VsYXIgZXhwcmVzc2lvbiB0byBtYXRjaCBteSBkYXRhDQpbc291cmNlOjouXFwvbXlkYXRhe1smKiZdfS9mb28vYmFyKl0NClRSQU5TRk9STVMtc2V0ID0gc2V0cGFyc2luZw0KPHN0cm9uZz48ZW0+cHJpb3JpdHk9MTAwPC9lbT48L3N0cm97WyYqJl19bmc+DQojRXZlcnl0aGluZyAtLSB0aGUgc291cmNlIGlzIGEgY2F0Y2ggYWxsDQpbc291cmNlOjouKl0NClRSQU5TRk9STVMtc2V0IHtbJiomXX09IHNldGRldm51bGwNClwiO3tbJiomXX0=[[/code]

Still, my data was getting dropped. The reason, the default priority is 100, so Splunk was matching the rule “Everything” and it’s priority was equal to “My Data”. By adding priority to all the stanza’s, I got the desired result.

props.conf
[code]]czoyNDc6XCINCiNNeSBEYXRhIC0tIHJlZ3VsYXIgZXhwcmVzc2lvbiB0byBtYXRjaCBteSBkYXRhDQpbc291cmNlOjouXFwvbXlkYXRhe1smKiZdfS9mb28vYmFyKl0NClRSQU5TRk9STVMtc2V0ID0gc2V0cGFyc2luZw0KcHJpb3JpdHk9MTAwDQojRXZlcnl0aGluZyAtLSB0aGUgc297WyYqJl19dXJjZSBpcyBhIGNhdGNoIGFsbA0KW3NvdXJjZTo6LipdDQpUUkFOU0ZPUk1TLXNldCA9IHNldGRldm51bGwNCjxzdHJvbmc+PGVtPntbJiomXX1wcmlvcml0eT0xPC9lbT48L3N0cm9uZz4NClwiO3tbJiomXX0=[[/code]

Great! Splunk is now indexing my data, and ignoring everything else. I just had to properly prioritize the stanzas.


Conclusion

If your running into data issues with your Splunk instance, one solution you can use is to ignore some of the incoming data. Remember, after you identify the data, properly prioritize it, then transform it.

Happy Splunking.

 


Establishing Procedures for Using Git

By | Ideas For Your Business

If you’re moving from another source control management (SCM) system to Git, you will need to develop some operating procedures and make sure everyone on the team buys into those procedures.

Why?  Git is a different type of SCM tool and its concepts are somewhat different than most SCMs.  Git’s concept of “origin” repository with the use of “local” repository takes getting used to over a traditional SCM’s concept of the main repository.  And Git promotes using the Master / Branch relationship differently than most SCMs.

Example: In Subversion the main code tree is in Trunk.  I’ve seen companies do all their work within Trunk.  Multiple developers submitting changes to Trunk, and when release time comes, a freeze on check-ins is enforced.  Once the release is built and tagged, only then are developers permitted to continue working. What a waste of time!

Some companies will not do the tag, but copy release Trunk over to a branch. To see what is in production you have to locate the correct branch.

Other companies will work strictly out of branches. They create a branch off what they believe is the most recent release code base (trunk or a branch) and at some point “might” merge release work back into Trunk.

With Git, the direction is that all releases are out of Master (aka: Trunk). Branches are where the work happens. Branches get merged back into the Master for release builds. And Master is tagged for those release builds.

Keeping release code within Master and separating out current work into Branches helps to make logical breaks in features and dependencies. And you will not block your developers from checking in code.

With that in mind, here is a short list to get you started with your team’s Git procedures: Read More

Enterprise Applications: Going from the Green Screen to Android in 8 weeks

By | Development, Enterprise Mobility

Are you heavily invested in Big Iron? Do you want to move to mobile but don’t know how? Don’t let Big Iron shackle you to the past. You can move to mobile and it is easier than you think.

There are many short cuts to making the move; such as running emulators/virtual machines on your device, or installing special tools that translate the green screen CICS applications within mobile devices.

But why not leverage your mainframe to do what it is good at, pushing data around!

Read More