Friday, December 2, 2016

Angular 2 Tour of Heroes with Spring Boot Rest Service

Blogworthy.  So I finally have a topic that actually matches the description of my blog.  A web app with a back end using groovy and java.  I have been working through a few tutorials to get myself up to speed on Angular 2.  I first reviewed Scott Davis's getting ready for angular video tutorial on Safari Book Online.  Scott does a great job presenting and I really like his energy in the video, but his focus was on staying in the strictly ECMAScript world and I was interested in learning the Angular2 Typescript approach, so I was left wanting more.

Angular and Spring.  I had done the Tour of Heroes tutorial just prior to the GA release for Angular 2, but didn't complete it and I wanted to walk through it again.  This time I completed it and for extra bonus points, I built a spring boot back end to support it.  The results are on Github: tour of heroes and hero-service.  As always Promises and now Observables were a bit of a mental challenge for me.  I also tripped up on the need to set up CORS so my angular app on port 3000 could talk to rest on port 8080.

Saturday, September 3, 2016

Windows 10 and Visual Studio 2015

Background.  In my day job I have moved to a point in my career where I don't do full time development, but help guide the organization and individuals in making technology choices.  One of our developers has over the past year or so developed a new .NET based version of a product that was originally developed in VB 6.0 and java.  VB was originally used for the UI while java was used for our service based code.  As we were/are primarily a java shop and our company perceived that introducing .NET at that point and time was unpalatable to the IT shops that supported our users, these choices made some sense.  Fast forward about 10 years and we see the .NET runtime as pervasive on the desktop and java in that space is somewhat frowned upon from the IT organizations that we deal with.  This is not reflection on java itself which I continue to think has a strong leadership position as an enterprise language/technology platform.  It is more a reflection on the poor perception (warranted or not) that the IT organization hold on supporting the JVM on the client desktops.

.NET Curious. As the developer of this .NET application was walking me through his work, I kept noticing how far Visual Studio has come in terms of providing the developer with the right tools at the right time for solid enterprise level development.  I decided to look into Visual Studio and C# in particular to get a feel for the tool set and environment.  I use Windows 7 on my work machine, but have a Macbook Pro for my home machine.  As the MacBook Pro is the machine that I do most of my research on, I decided to build a VM to host a new Windows 10 / Visual Studio development environment.

VM Building.  Knowing that I would probably want to keep this VM around and might live in it a while, I wanted it to be a good size disk space wise.  I also didn't want to give up precious SSD hard drive space on my mac.  So I bought a 256Gig USB 3.0 thumb drive from Costco dedicated to this VM.  I first put Windows 10 Pro on it, then did the Visual Studio Enterprise install.  I picked a pretty full installation as I want to try out all of the data tools, web tools, and maybe other languages (Python, F#).  The installation took a few hours and I was a little concerned that my multiple reboots always seemed to come up with the hard drive pegged at 100%.  Not sure exactly why this was but my guess is that Windows Cortana and search services started out by indexing everything on the drive and just beat up the hard drive stats.  Once I started working regularly in the VM the hard drive thrash abated and I don't see nearly the number of lengthy pauses as I did upon the initial installations.

JavaFX and WPF.  Part of the reason for my curiosity in researching .NET tools, is that I really wanted to see how rapidly I could develop web enabled applications for the desktop in Visual Studio.  My interest in this area started out with me looking at JavaFX for the same thing in the Java arena.  I really liked the notion of declarative UI with backing MVC code pattern that JavaFX uses.  When I mentioned to colleagues that I was playing with JavaFX, I got a lot of raised eyebrows.  The .NET app that our developer had written used WinForms, but I let the developer know at the start of that project this it was his choice as to whether we use WinForms or WPF.  His familiarity with WinForms was his reason for going that route, but knowing that WPF had a similar approach to JavaFX got me thinking out looking into the .NET tools for developing desktop WPF apps.  For my java development I have used Intellij IDEA since its very early days.  The current version incorporates the JavaFX  Scene Builder for screen building with controls palettes and properties.  It works OK.  I had to restart Scene Builder quite often and it seems to lose its notion of where you were when it lost and gained focus, but overall it was a pretty good experience.  My goal with Visual Studio was to compare the experience within the Microsoft tool suite and WPF to see how it stands up to IDEA/Scenebuilder.

Visual Studio First Impressions.  I am starting out my exploration of Visual Studio by working through a trusted standby reference: Andrew Troelson and Philip Japikse's C# 6.0 and the .NET 4.6 Framework, 7th Edition.  I am relearning C#, which I never really used in production apps myself.  I find myself skimming large sections that really draw out topics that a new comer to the language would want to dive into.   I found a key bindings reference to become familiar with Visual Studio editing functions, but really miss some of the Intellij Idea editing functions that don't seem a counter part in Visual Studio.  I really enjoying being in the Microsoft-everything at your fingertips world.  The MSDN / library docs are great.  One feature that is new to me since the last time I used Visual Studion is the behavior of spinning up a local GIT repo for every new project/solution I create.   I like to pop up my play / learning projects into my Github account and it looks like this will be easy with Visual Studio.  This is a feature that Intellij Idea has long had but I didn't expect Visual Studio to embrace Git/Github at the same level.  I was pleasantly surprised.

Long Lead Time.  It will probably take some time before I am comfortable in Visual Studio writing C# code but so far I am enjoying completing the samples in the Troelson book.  Debugging is fun and easy.  I notice that a performance monitor pops up as I'm running my app and this looks interesting.  I really want to get my arms around the SQL Server data tools as well.  Maybe even introduce Postresql into the mix.  I have a small Department-Employee data table set that I like to use as a play data project that I want to introduce into a learning project.  Lots of learning to do.  I'll continue to blog on this as I go or until my interest moves into another direction!

Saturday, May 14, 2016

Added hiphello to Github, SMTP testing

Hiphello.  Adding a quick note to say that I uploaded my Hello World version of JHipster, hiphello to Github.  Points of interest of the /jdl directory off the route that contains my jhipster-uml jdl model to kick start the app's entity model.  I also have an example of loading 1 row into each of my entities in the /src/main/resources/config/liquibase directory.

Docker.  By the way, a nice way to test this without having to stand up postgres (my db for the app) is to use docker.  If you have docker installed you simply type in the following commands:

./gradlew bootRepackage -Pprod buildDocker

docker-compose -f src/main/docker/app.yml up

Mail.  Another handy tool to test the mail capabilities is FakeSMTP. I ignored mail in my learning app until I needed to change a password.  I realized a quick way to to get this done was to have the change password email send out to drive the user (me) back in with the change password token.  FakeSMPT has a nice GUI to show incoming mail and display it or just watch an incoming mail directory that you specify.  Displaying the email for the GUI invokes your OS handler for files with a ".eml" extension.  In my case it kicked off MS Office's Outlook application which I haven't used for years and was hooked to my gmail account.  It then tried to pull ALL of my gmail mail.  Not good, be forewarned, know what .eml handling will do.  On another note, their is a docker file for FakeSMTP which by default fires up the server mode.  I wouldn't mind seeing FakeSMTP included in the jhipster generator and if I have an opportunity to figure out how to incorporate at a level that makes sense for the jhipster community, I may do the fork/pull request thing.

FakeSMTP Alternatives. @Fotozik on twitter alerted me to Maildev, a javascript/npm package that does essentially the same thing as FakeSMTP but uses a web page to show output emails.  Works nice with HTML email that JHipster kicks out. The Maildev code is at Github.  Installation:
npm install -g maildev
For unit testing the subethasmtp project has a subproject call Wiser.  Wiser allows you to start and test incoming smtp email in a unit test.

Thursday, May 12, 2016

Multi-tenancy

Multi-tenancy and Security.  In reviewing the needs of the learning app I am developing with JHipster, I stumbled on a somewhat large-ish disconnect in terms of security.  JHipster integrates Spring Secirity which offers role based authorization (authz) and a variety of social sign on options.  Its pretty complete right out of the box (that JHipster generates). This is all good, but my app is being built as a multi-tenant app.  When a user logs in, I not only need to make sure they have the right roles, but I also have to determine their association with a "tenant".

Multi-tenancy Model.  For my application I have chose a multi-tenancy model where the application and database are shared by ALL tenants.  It will be up to the code to ensure that I don't co-mingle a particular tenant's data.  In my example from prior articles, I used an Employee - Department set of entities to discuss relationships.  Imagine now that I need to restrict users of my learning app to a single company.  The Company entity is now the driving entity as to what makes up a tenant.  All other non-system entities that are part of the app (Employee, Department) have to relate to the Company such that when a user logs in, they only see the data for their company.  Found a cool tool to do diagramming:



In reviewing how JHipster manages authorizations, I found that the code generated will lock down the back end access at the Rest api level by adding authorization checks at the Rest url level within the SecurityConfiguration class.  I really like this approach.  It frees the remainder of the app from checking roles at each step.  I will still likely include spring security annotations @Pre and @Post Authorize in my high level service methods on my custom services where appropriate.  I went ahead and set ALL the generated Rest apis to ROLE_ADMIN to lock them down.  I really want to dig into the Spring Security expression based access control.  It looks to have some pretty compelling features that might come in handy when locking down data for multi-tenancy.

Data vs. Role Security.  In addition to the Role based auths however, I still have to ensure that my Rest api does not allow data from one tenant (Company) be seen by the user associated with another tenant.   I went ahead and implemented my own version of UserDetails by extending User and populated it in my custom UserDetailsService.  I included the notion of the Tenant in my UserDetails class such that when a user logs in and Spring calls the UserDetailsService, I load the user's default tenant (company) from the database into the UserDetails class.  For now I will rely on passing the UserDetails via parameters to the Service and Repository layers to restrict data for a given user.  I may refactor to use a ThreadLocal but there are many documented disadvantages to this.

JHipster and Groovy.  As I begin to lay in new code, I wanted to start using Groovy.  My plan is to leave the generated Java code AS Java (rather than convert to Groovy), but  any new classes will be Groovy.  One very minor snag is that the Groovy compiler wants all sources, Java and Groovy to be in src/main/groovy.  Added these two lines to the Gradle build to fix:

sourceSets.main.java.srcDirs = []
sourceSets.main.groovy.srcDirs += ["src/main/java"]
Put these lines in, wrote some simple Groovy classes and simple Spock tests, and the compile works fine, both from Gradle and from Intellij Idea.

Wednesday, April 27, 2016

JHipster JDL Notes

JDL.  JDL stands for JHipster Domain Language and is a shorthand notation for describing entities and relationships for the jhipster-uml to consume when generating the domain portion of you JHipster code.  My current JHipster learning project quickly evolved to using this format after a few painful sessions with the question and answer approach of the yoeman jhipster:entity sub generator.  The jdl format is pretty concise and allows you to quickly specify the attributes you need to define entities: properties, types, constraints and relationships.

First Issue Encountered.  Once I had my entities defined in JDL and had the generator working to the point where I had working CRUD for all my entities, I started playing with the functionality.   The first thing I noticed was that all of the entities that had relationships to others (let's say children entities) would always represent the child as the Primary Key ID value of the object.  To illustrate I'll use the example of an Employee - Department relationship where an department has many employees.  When listing the employee, JHipster would show all of the attributes of the employee (name, position, years employed) and then show the numeric id (Primary Key) of the department.  Not a very good user experience.  Of course what I wanted was the department name, both in the listings of the employee and as a drop down selection when editing a single employee.  

First Issue Solved. It makes sense that JHipster used the department id as the data showing the relationship.  After all, I did not tell it WHICH piece of data in the department object would be meaningful (and unique) to the user.  Thankfully the the JDL has a nice facility to not only indicate the relationship between entities, but also indicate the field which would be meaningful to the user, and thus be used to represent the relationship on the parent object when used in the UI. My original relationship section of my JDL looked like this:

relationship ManyToOne {
    Employee {worksInDept} to Department
}
This defines that there are many employees in a department and that the employee entity will contain a property named worksInDept that will be the child department object.  When the relationship is defined like this, JHipster simply defaults to using the department id in representing department in any employee UI areas.  In order to tell JHipster that the property on the department object to be used, I had to make the following change:

relationship ManyToOne {
    Employee {worksInDept(deptName)} to Department
}

Note the add of the deptName property.  Not sure what this construct is actually called in JDL.  It shows up in one of their examples but is not documented in the relationship declaration definition:

relationship (OneToMany | ManyToOne | OneToOne | ManyToMany) {
  <from entity>[{<relationship name>}] to <to entity>[{<relationship name>}]
}

Second Issue Encountered. So the addition of the unnamed attribute in JDL seemed to have solved my first issue. The generated code included additional references in the EmployeeDTO to the new deptName property called worksInDeptDeptName and appeared to use it through to the angular display of employees (lists, edit, etc). However when I ran the app, the mapper did not map the new field on the DTO. It left it null. The EmployeeMapper clearly had a mapping annotation to pull the from the related worksInDept object and put it in worksInDeptDeptName, but it wasn't doing it at run time.

Second Issue Solved. My first thought was that the mapping library was broken. My second thought was that there is no way that wouldn't get fixed before I see it in release. I then started looking at the MapStruct lib and learned that it does its mapping magic by generating code for the mappers at compile time. I happened to be running my code in Intellij from its Spring Boot run configuration and I pretty quickly guessed that it was bypassing the code generation that the Gradle build was doing. I ran the Gradle build and the mappers worked. No more nulls and I get the user friendly department name throughout the Employee UI facilities.

Next Up.  One of my big frustrations with code generation approaches is how to add code and not break the upgrade path.  When a new JHipster version comes out, I have a laborious set of tasks to restore my custom adds (homepage, ssl, etc) after re-running the code generation.  I'll start to think about how to deal with this and write up my findings as I arrive at them.

Tuesday, April 26, 2016

JHipster Notes

JHipster.  I have always been a big fan of using framework / code generators to kick start apps where you just want to get something done but don't want to spend a lot of time laying in infrastructure and UI. In the past I have always used Grails for this purpose to pretty good effect. I have lots of utility apps that do a specific thing that, well, look a lot like a Grails app. This really allows me to quickly dive into the thing I wanted to get done. I was recently introduced to another project, JHipster, that uses code generation rather than a framework approach to kick start an application. Whereas Grails provides an application framework with a rich plugin architecture, JHipster takes the approach of generating your app from a BUNCH of best of breed technologies that would be needed in an enterprise web app.

What is it? At its core it pulls together Spring Boot on the back end and AngularJS on the front to create a modern looking application using tried and true enterprise architecture choices throughout. I won't include the laundry list of technologies within the generated app, but the highlights for me are the AngularJS/Bootstrap generated front end, Spring Boot using Spring Security and JPA with Spring Data JPA.

Javascript. I have been working on a largish sized AngularJS application at my full time job and have come to appreciate the size of Javascript/NodeJS ecosystem involved in standing up modern JS applications. JHipster takes full advantage of that ecosystem by generating a front end application that is in line with what a front end developer would expect. JHipster uses Yoeman, a fairly well known javascript code generator, to generate the application. Javascript dependencies are managed by Bower and you get a choice of Gulp/Grunt as your front end build tools. On my Macbook Pro I tend to have node versioning issues when using a lot of these tools, so I have installed NVM (Node Version Manager) to keep node under control.

Build. On the java side, you have a choice of build tools, Gradle or Maven, for the overall build.
 As this is a Spring Boot app, the java build tool is the main method for rendering the entire application, but it defers to the javascript build where it needs to.  The generator has you make this choice up front and I picked Gradle and Gulp for my build tooling.

Docker.  As of late I have also been playing with Docker to learn about quickly spinning up deploy environments.  JHipster generates a Docker directory in the src directory to provide the container set to deploy your app into.  In my case JHipster generated docker config for a java container and a postgresql container.  There was a bit of mystery for my around the postgresql container until I dug into it.  How did it know the db name, user name, password?  Where were all the commands necessary to create these things?  It turns out that the image that JHipster uses for Postgresql container, documents that you can just pass the user name as an environment variable on startup and it will use that to create the user, db, and password for you.  In my case the user name is simply my application name.

More to come.  I plan on using this blog to document the issues I come across as I take my JHipster generated app into a real working application that actually does more than CRUD. Topics I want to address in future blogs are Liquibase, SSL, JHipster Domain Language.

Thursday, April 21, 2016

TJUG Code Kata

Bob Damato and Shane Boucvalt of Valpak in St. Pete hosted the Tampa Java User Group (TJUG) Meetup tonight at Valpak's Manufacturing Center.  Tonight's meetup was run as a Code Kata, which is basically where a facilitator hands out a problem statement / requirement that can be solved/coded/tested within the space of a meeting in a safe environment where like minded developers can collaborate to solve the assigned issue.   The purpose behind the Kata is to give the developers a chance to practice their craft in that safe environment.  The problems are usually a generic puzzle style problems that require some thought goes into the solution and the unit testing scenarios.

Tonight's problem was called the Monty Hall problem.  From wikipedia:

Suppose you're on a game show, and you're given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what's behind the doors, opens another door, say No. 3, which has a goat. He then says to you, "Do you want to pick door No. 2?" Is it to your advantage to switch your choice?

We were asked to run 2 - scenarios of 1000 runs each where the winning door and your guess are selected at random.  In  scenario 1, you stick with your first choice.  In scenario 2, you pick the remaining door.  The code is to determine which scenario has the advantage.  You could write in the language of your choice but given that this is the TJUG, java was kind of expected.  I choose Groovy because I like it and its close enough to Java that the others could read my code if I was explain it.  I wrote my tests in Spock and was happy that I could quickly spin up an app with a Gradle build and Spock tests within Intellij Idea.

It was a last minute decision on my part to attend as I was cutting it close to leave work at 5:30 pm in Tampa to get to St. Pete for the 6:30 meetup.  Because you so rarely get to do any coding in these type of user group meetings, I really wanted to attend this one.  It had a somewhat small turnout, but was interesting none the less.  It took me about an hour to get a working application that yielded the results.  My test were more about exercising my solution rather than checking the solution's validity.   Bob, Shane and other Valpak employee's who had previously done this Kata, shared their solutions and showed how to break testing down to 4 simple scenarios that validated the outcomes.  I was happy to have the opportunity to share my solution at the lectern with this small crowd.  I'm not always comfortable speaking in large group settings, so I was glad to have a chance to do this in this environment.

It was a really fun exercise and I look forward to sharing the Kata experience back at the office. Thanks to Bob and Shane, as well as Valpak for hosting this meetup. I am including both my code and tests for the Kata below.  More refactoring could be done but I wanted to post exactly what I ended up with in the allotted time:


KataMain.groovy

 package com.bpcs.kata  
 /**  
  * Main Kata for TJUG  
  *  
  * Created by wpfeiffe on 4/21/16.  
  */  
 class KataMain  
 {  
   public static void main(String[] args)  
   {  
     KataMain kataMain = new KataMain()  
     int winner = kataMain.runScenario()  
   }  
   int runScenario()  
   {  
     int winner = -1  
     Integer firstStrategyResult = this.getFirstStrategyResult()  
     Integer secondStrategyResult = this.getSecondStrategyResult()  
     println "The first strategy wins $firstStrategyResult times out of 1000"  
     println "The second strategy wins $secondStrategyResult times out of 1000"  
     if (secondStrategyResult > firstStrategyResult)  
     {  
       winner = 2  
     }  
     else if (firstStrategyResult > secondStrategyResult)  
     {  
       winner = 1  
     }  
     println "The winning strategy is $winner"  
     return winner  
   }  
   Integer getFirstStrategyResult()  
   {  
     Integer result = 0  
     List<Integer> doors = createItems()  
     List<Integer> guesses = createItems()  
     doors.eachWithIndex{ int door, int i ->  
       // if they picked correctly  
       if (door == guesses[i])  
       {  
         result++  
       }  
     }  
     return result  
   }  
   Integer getSecondStrategyResult()  
   {  
     Integer result = 0  
     List<Integer> doors = createItems()  
     List<Integer> guesses = createItems()  
     doors.eachWithIndex{ int door, int i ->  
       // if they did NOT pick correctly  
       if (door != guesses[i])  
       {  
         result++  
 //        Integer nextPick = pickRandomDoor(2)  
 //        if (guesses[i] == 1)  
 //        {  
 //          nextPick++  
 //        }  
 //        else if (guesses[i] == 2)  
 //        {  
 //          if (nextPick == 2)  
 //          {  
 //            nextPick++  
 //          }  
 //        }  
 //        else  
 //        {}  
 //        if (door == nextPick)  
 //        {  
 //          result++  
 //        }  
       }  
       // else they change and result is 0  
     }  
     return result  
   }  
   List<Integer> createItems()  
   {  
     List<Integer> items = []  
     (1..1000).each {  
       items << pickRandomDoor(3)  
     }  
     return items  
   }  
   Integer pickRandomDoor(int max)  
   {  
     Random rand = new Random()  
     rand.nextInt(max) + 1  
   }  
 }  

KataMainSpec.groovy

 package com.bpcs.kata  
 import spock.lang.*  
 /**  
  * Spock tests for TJUG Kata  
  *  
  * Created by wpfeiffe on 4/21/16.  
  */  
 class KataMainSpec extends Specification  
 {  
   def "Test Create Items"() {  
     setup:  
       KataMain kataMain = new KataMain()  
     when:  
       List<Integer> items = kataMain.createItems()  
     then:  
       items != null && items.size() == 1000  
   }  
   def "Test Random Door"()  
   {  
     setup:  
     KataMain kataMain = new KataMain()  
     when:  
     Integer door = kataMain.pickRandomDoor(3)  
     then:  
     door > 0 && door < 4  
   }  
   def "Test First Strategy"(){  
     setup:  
     KataMain kataMain = new KataMain()  
     when:  
     Integer successCount = kataMain.getFirstStrategyResult()  
     println "First result = $successCount"  
     then:  
     successCount >= 0 && successCount <= 1000  
   }  
   def "Test Second Strategy"(){  
     setup:  
     KataMain kataMain = new KataMain()  
     when:  
     Integer successCount = kataMain.getSecondStrategyResult()  
     println "Second result = $successCount"  
     then:  
     successCount >= 0 && successCount <= 1000  
   }  
   def "Test All"() {  
     setup:  
     KataMain kataMain = new KataMain()  
     when:  
     Integer winner = kataMain.runScenario()  
     then:  
     winner >= 1 && winner <= 2  
   }  
 }  

build.gradle

 group 'com.bpcs.kata'  
 version '1.0-SNAPSHOT'  
 apply plugin: 'groovy'  
 apply plugin: 'java'  
 sourceCompatibility = 1.8  
 repositories {  
   mavenCentral()  
 }  
 dependencies {  
   compile 'org.codehaus.groovy:groovy-all:2.4.4'  
   testCompile group: 'junit', name: 'junit', version: '4.12'  
   testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'  
 }