Reducing Turnaround Time

As more enterprises are migrating to off-the-shelf tools, there is increasing pressure to reduce the turnaround time on custom development.  One way to do this is to use boiler plate.  The next level is to use a boilerplate generator. This basically removes a lot of repeat effort and converts that process into a configuration process rather than a coding exercise.

While the flexibility you might desire is going to be lacking, the time saved is well worth the effort to get setup to do so.  Over the past month, I've been working with two separate technologies to accomplish a certain degree of kick-starting the coding effort.

Spring Roo is a project that has been around for a while an is stable at version 2.0.0.RELEASE.  From a script file, you can procedurally generate a Spring Framework application.  Optionally employing JPA in the configuration script will also populate a target data source table structure with any models you define.  For the price of setting up and understanding Spring Roo, you get a standards based API and data structure rather quickly.  All you have to do is provision the empty data source if not specifying an in-memory RDBMS.

Spring Roo will also create the MVC and service layers for THYMELEAF if you want to have it spit out a UI for you.  The resulting UI is far from complete but can be used to validate the API and then you are free to custom develop the remaining UI tweaks or revisions you desire.

For my needs, though, I would rather use Angular, so for this I have been looking at Angular Schematics.  Schematics is a standalone tool that you can use to create a file tree of code that can be merged into a target tree.  This lets you build components and features as schematics and then push them into an existing Angular CLI project. 

Now, Schematics takes a bit more understanding to come to grips with, but once you understand what it is doing, and how you can take advantage of that, the power it unlocks is fairly impressive. 

As icing on this two layer cake, my latest effort has been to write a front-end script that takes a short config model definition file and a few input parameters and then generate the Roo script as well as automate the execution of the Angular CLI and Schematics calls.  With a carefully designed set of schematics, this provides everything you need to make a complex object repository, API and UI with maybe 30 minutes of specification work.  In the past, doing this all long hand, it would probably take me 2 weeks to a few months depending on what was requested. 

The take away is that now I can focus on the customizations that add value for the customer once the spun-up boilerplate API and UI are ready for them to review.   The nice thing about this approach, from a long term maintenance perspective, is that I can always refine or extend the code generating tool set so it's easy to provide forward compatibility with future features and tool sets.  Careful use of source code management means I can also maintain a version history and recreate past work quickly if and when needed.

Linux Fun on Android

It's 2ferWon day! I'm catching up on things I've been stashing away to blog about.

I recently got the python bug due to a request at my main client site. This led me to idly wonder if I could run python on my Android phone. Turns out you can do so, and more.

Thanks to an amazingly cool App, UserLAnd, you can in fact run Linux and hence a bunch of cool tools, including easily working with python, on your very own smart phone or Android tablet.

Once you install UserLAnd, you can pick a shell distribution: Arch, Kali, Debian, Ubuntu and a few others. I chose Debian due to my familiarity with it from past years trying out various linux distros. You set it up by creating a user and password and a VNC password.

Once signed into a user session, you can sudo whatever you like. In my case, I started off by installing python3 and python-pip as well as a host of other libraries Jermaine to the request I had from my client.

If you're a geek like me with an Android device and you're looking to kill a little time, I encourage you to check it out!

Ramping Up with Android

Yes, you may have detected a common thread.  It has been long in the works but my shift away from legacy systems as my bread and butter to cutting edge (or more recent) technology has been a gradual 6 year shift for me.  I've gotten to the point where old-school mastery is no longer something to be grasped on a technology level, but on a practicum and theory level, and in that realm I've gotten to where I am comfortable enough to pickup new technologies as I have need.

Recently, that need turned towards Android.

If you're just starting out with Android Development, I can't recommend highly enough a starter series from Tek Eye. (https://tekeye.uk/android/examples/index) It's now 4-5 years old, and most of the projects will need gradle and build tool updates, but it provides a good, digestible starting point if you are new to Android. (As I have worked through these tutorials and started building my own apps, it is worth noting that Android Studio 3 brings many welcome features, like responsive layouts, that you'll also want to come to grips with).

This offers a basic series of tutorials for Android development. While the downloadable sample code is a little behind the current Android Studio version, it is terse and lesson specific and worth reviewing and running on your own. For use with Android Studio 3.3, the following changes will be needed in your build.gradle files.

But before you make these changes, let the IDE find and fix problems. If asked to upgrade, click OK. If any errors with suggested solutions are displayed in the console, try those suggestions first, like 'try again'.

If asked to recreate the wrapper using the latest supported Gradle version, click OK.




On build.gradle (Module: app), remove the line "buildToolsVersion" altogether.

Change the compileSdkVersion to 26 (or latest)

Change minSdkVersion to 14 (recommended by the console when you first sync the file)

Change targetSdkVersion to 26 (or latest)

Change instances of 'compile' to 'implementation' in the dependencies section.

Change the dependency for com.android.support:appcompat-v7+ to the version of the SDK you are using, eg 'com.android.support:appcompat-v7:26.0.1'


In the build.gradle (Project: myproject) file, add google() before jcenter() wherever you see the reference to the jcenter() repository.

Upgrade your dependency for com.android.tools.build:
classpath 'com.android.tools.build:gradle:3.3.0'

From there, I recommend starting at the beginning of the list of lessons. Download the sample code, unzip it and open the project in Android Studio. Then walk through the written lecture and have a play running the code on your device on an emulator (downloaded through Android Studio).

Time spent on a lesson will depend on you. Downloading and setting up Android will eat some bandwidth and take some time. Generally, Android Studio is very user friendly, but if you get some errors in the console that prevent you from building and running an app, just copy and paste the text into your favorite search engine. There is a lot of help available on sites like Stack Overflow.

After you've worked through the lessons, keep the unzipped code handy. You'll have some familiarity with it and should easily remember where certain examples can be found. Going forward, it can serve as a library of snippets to help you out with your own apps.

Coming Up to Speed with Angular 6/7

Over the course of the past few months, I've been making a study of current JavaScript UI frameworks. Angular presently holds the lead as the best fit for my primary client's enterprise environment, so I've been working through a few things to make this a manageable, extensible, quickly deployed solution for a wider swath of development needs. This is a brief discussion of the high-points of that journey. While I'm mostly only taking advantage of Angular 6 functionality, I've been using the Angular 7 CLI to make sure I've got the latest dependencies in the applications I am building right from the start.

POC

The first thing I like to do after nailing down the tool chain for any new technology I am learning is to create a Proof-of-concept implementation. In this case, we had a simple 3 page survey tool that was used once a year for an internal campaign. For the new year, they wanted to add a leader board with bar charts and add email notifications.

Translating the current work from .jsp based web pages to a modular design took a lot of effort, but less time than I thought it would. The first big surgical decision was to separate the UI and the back end web application that provided the APIs driving the user experience. This decision played well into the next section of this article when it came time to break things out into libraries.

The form this separation took, within my Maven project, was that of a multi-module project. Maven is a dependency management and build tool that makes combining external dependencies with your own code a pretty straight-forward, declarative affair. By extension, then, making your own modules should follow roughly the same approach. It does, to an extent, but what you inherit is the responsibility for creating the packaging for your own sub-modules -- a task usually transparent to you when you consume externally provided dependencies.

So in this case, I had separate Maven build files for the API, the UI, and a Web module which simply provided the Web Archive (.war) file packaging at the end of the build. With this arrangement, a web developer can maintain the UI and a back-end engineer can maintain the Spring API separately without excessive concerns for one another's activities.

The POC was a success, and it also created the opportunity to begin identifying and isolating our own unique Angular components as reusable libraries.

MAKING COMPONENTS

Abstraction, if you're not familiar with the term, is the practice (art / science) of breaking a system down into representational components that serve a single purpose in a generic enough fashion as to be useful in many different scenarios. Selecting a function to extract from my POC for this treatment was not my biggest challenge. Getting the process nailed down, from an Angular world view, was what required the most work.

Angular provides external library components to you through NPM. NPM is the Node Package Manager and is by default pointed to a global internet library of Node Modules. If you want to publish your own modules to NPM, you have to sign up for an account. For an enterprise environment, this may not be the best approach. In some cases, components you develop are going to be useless outside of the environment you are working in. In others, they may represent portions of intellectual property that can not be shared. So I had the challenge of working out how to do this without the NPM repository.

The first step was to create a library project. There are several guides available online for this. What this process taught me was the need to carefully decouple my angular components. While Angular makes it super easy to add components to a project with the Angular CLI, you want to be careful what you do with them after that step in terms of how they are connected to parent components. While it is possible, for example, to make components out of form elements, turning one of those elements into a standalone library means you won't necessarily have the parent context while developing and testing that library. Creating them in a way that they have a minimum of interaction with the parent component, then, predisposes them to future extraction into standalone libraries.

The next thing was figuring out how to both put the library under source control and provide a path to being able to package and install it into another future application. This involved three steps.

First, only the "lib" folder in the library component is checked in. Checking in the surrounding test harness is not required.

Second, creating an on-board packaging script for the library allows future users to build it into a .tgz locally after they clone the repository.

Third, using an NPM feature to install from a local file path, the .tgz can be installed as though it comes from the global NPM repository.

This seems like a lot of work, but the important thing here is that it keeps the source code for the library open for extension and modification within the enterprise. I want future developers to be able to fork this library to make their own components or branch the code and possibly submit pull requests when they fix bugs. By keeping the library in a raw, source code format, we get the best features of using packaged libraries and reusable code combined.

NEXT STEPS

Going forward, I have a couple of targets I want to hit with my Angular learning. I have a request to expand the libraries that are documented and tested - essentially create a loose standard for us to follow within the enterprise, so expanding my knowledge of existing external components is going to be a major theme in the coming months. Secondly, I have been delving into Android development on the side. Angular, through Native Script, promises to expedite the process of developing tools that can work on multiple platforms, including Android, so I'll be looking at that.

RESOURCES
Here are some of the resources I've found thus far that have been useful to this pursuit:

Making custom libraries
https://angular.io/guide/creating-libraries

https://medium.com/@tomsu/how-to-build-a-library-for-angular-apps-4f9b38b0ed11

More in-depth example for making libraries
https://blog.angularindepth.com/creating-a-library-in-angular-6-87799552e7e5

https://blog.angularindepth.com/creating-a-library-in-angular-6-part-2-6e2bc1e14121

JavaScript Frameworks and Your Business

Being a small business owner who does a lot of subcontracting on long term contracts, I have both the freedom and professional need to stay on top of new technology trends.  Sometimes this need becomes very pressing, like when I know or suspect a contracting gig may be ending, and at other times work makes such a huge mental demand that I don't have time to keep up where I would like to.

JavaScript frameworks are one of those areas where I wish I could have kept up better over the last 4 or 5 years.  My focus instead had been on systems integration and J2EE.  UI, while a sometimes important part of what I was doing, was in most of those cases a secondary concern, and while I was joyed to adopt Bootstrap and W3.css, they are really about decorating the UI, not frameworks. 

JavaScript Frameworks: Basic History

The idea of frameworks goes way back.  I don't know the precise origin but started getting involved with them when prototype.js, scriptaculous and ext.js were in their infancy, even contributing to a few bug fixes on prototype and ext through my connections with developers on those.  Early frameworks focused on reducing the amount of code you wrote.  Forks of ext.js included complete makeovers for some UI's generated by things like IBM Lotus Domino (notorious for its broken and ham-fisted HTML rendering). 

These two ideas, reducing coding effort by creating simplified and powerful boilerplate code, and redrawing the UI through DOM manipulation for better User eXperience (UX) continued to evolve over time, giving rise to things like ember.js, knockout.js and others.  All the while, the focus was moving away from just scripting the UI and towards more abstract concepts and solid design patterns.  Knockout.js, for example, introduced binding that worked in a way that made keeping the UI view and its underlying model in sync much much easier.

Modern Frameworks

Present day, 2019, Angular and React have become the dominant frameworks.  They build on a legacy of prior art while also reinventing and reconsidering the design challenges web application developers have faced over time.  Maintaining the state of an application from one screen or panel to another, handling server side requests for data, ensuring cross-browser or even cross-platform compatibility and deciding how to divide up logic and UI are just a few such considerations. 

Angular, created by Google leverages another open source tool, Typescript.  React, created by Facebook is a less opinionated framework that nonetheless offers a lot of benefits.  Sitepoint published a very good article that I recommend to anyone trying to choose between the two.  Importantly, it offers a conclusion I very much agree with as it meshes solidly with my view: don't choose one.  I believe, as others do, that there is a right tool for each job, and that it is often not the tool you have used the most or most recently.  Fresh analysis of the needs and environment of a project should be undertaken each time you embark on a new effort.

The Probable Future

Presently, both React and Angular offer CLI's to expedite and standardize the bootstrapping of a new project.  (I rather like the very structured approach Angular takes).  Code generation is just enough to get you started.  After that, you have some learning to do.  But, the everyday tasks we perform as application developers are largely the same.  The details are what make the biggest difference in each implementation, but we often enough repeat work done by others.  Mixins (in the case of React) and continued contributions to libraries and add-ons for both frameworks follows the same general trend of software development in other technologies, that being one of continued modularization,  code generation, standardization and ever more complete and competent frameworks. 

A merging of platforms is also underway where projects like React Native and Native Script provide the ability to take these primarily web browser focused frameworks and create native applications for both Android and iOS devices.  The number of different skill sets needed to create something with a broad audience is declining as time goes on.  However, the tools and platforms we build these solutions upon continue to improve and evolve through natural growth and innovation.  So too, the frameworks and tools we employ to make more utility out of less time and fewer people will evolve and change in step or just behind these platforms.  However, the core challenges of providing value to customers will remain, and that means good business requirements analysis will be an in-demand skill for some time to come. 

It also means that some skills will have more longevity in the market than others, though the details of how they are implemented will continue to change.  UI design continues to change subtly as customers move from the desktop and tablets to smaller presentation form factors on mobile devices.  Application development, though, is rapidly changing.  So much so that within the span of of 3- 6 months, a projects base code might need to be reevaluated from a dependency perspective as changes and updates to the ever increasing number of external dependencies projects have continues at a very brisk pace.  What was the best way to do something last year is out of date and clumsy now.  Core design principles remain important, however.  Even as we see a near constant flow of changes in tooling and libraries we may take from the open source community and commercial markets, understanding what reliable and maintainable designs looks like, and how to avoid common pitfalls remain foundational skills that do not age out.

All Things Considered

The challenge for a modern provider of software design and development solutions, then, is to balance time learning and updating skills with providing lasting value and value-added services to customers.  My primary concern for any client is always that the time they pay me for results in cost savings or profits.  We should be striving to optimize systems so that less time is wasted, efficiency of systems improves, friction of transactions decreases, and the investment in IT as a whole has a clear and measurable impact on the bottom line. 

These opportunities only arise as often as businesses have the presence of mind to ask key questions, just like any software developer should ask: are we making the best use of our resources? Are we duplicating work? Are we spending disproportionate capital on a problem(addressing a 1% problem with more than 1% of our resources, for example)? How can we improve?  What can we do better, faster or cheaper?  How do we continue to improve quality and reduce our future cost of ownership?

And that's the sort of conversation I like to have with managers and business owners.  If you haven't had a conversation like that lately, drop us a line at: datatribe at gmail dot com. 

Frameworks, then, should be viewed as value added investments.  Adopting them has an initial cost in terms of developer ramp up, but the benefits to quality and speed of development in the future are quite clear from a technical standpoint.  It's the sort of investment that is on the same level as adopting a source code control solution and giving consideration to continuous integration or continuous development solutions. 

If you're a big enough business to have a dedicated IT department, these will be familiar concepts, or ought be, and are worth careful consideration.  If you area small business, what you need to know is the value delivered when a solution provider mentions the use of a framework such as Angular or React comes in the form of quicker initial results with faster future updates.  You should expect turnaround times to improve greatly over older ways of creating custom solutions.  This means your overall or initial cost will likely be lower in terms of man hours, allowing more capital to be diverted to other needs or folded back in to making better tools for your employees and customers.