On Word II

Our last kitty Gizmo passed in 2011 and we (my wife Judy and I) never thought we'd have another cat.  

Then via a stroke of luck, our neighbors found a kitten in the bush by their front porch.  As they were packed and ready to leave town, they needed someone to take care of the cat, find it's owner, find it a home, or whatever.  We had a few feral cats in the neighborhood, so we assumed it may be a feral kitten and prepared a bed in our garage figuring to feed and care for the kitten until it decided to leave.

That was 10 years ago, and sadly the kitten left us on Tuesday April 6th, 2022.  

While sad from his passing, we are very happy to have been lucky enough to have been in the right place at the right time 10 years earlier. 

 There are two things that are sticking with me at the moment.  

The first is to take more pictures.  When someone passes, your memory of them begins to fade that very day.  To some degree I feel like that's some of the grief that we feel, we don't want them to slip from our memory, but life marches on and it is inevitable.  Pictures help preserve the memory and trigger the positive memories.  They are invaluable.  My mother was a photographer and when she passed last December, we spent days, weeks going thru photo albums and disks full of pictures of friends, family and experiences.  It is an awesome reminder of an incredible person and life.  Those memories captured in perpetuity are a great present from my wonderful mother to our family.

The second thing on my mind is to be brave enough to love.  Sure it hurts when someone passes, but the love experienced is far greater than the pain of it's removal.  We learn throughout our lives to avoid things that cause us pain, touching a hot stove, skinning our knees, checking the street both ways before we cross, be careful of strangers, etc.  It may be natural then to avoid Love due to the inevitable pain that will come from it's removal or the disappointment of Love unrequited.  Do not let those other life lessons change the way you approach your fellow man.  We are all of the human condition and have our share of challenges and disappointments.  Those things should draw us closer together, not force us apart.  Be brave, ask how someone is doing and really mean it ....  be curious, spend the time, for it is fleeting.

Play Framework 2.x on Windows Azure

Today I am going about setting up a Play Framework 2.1 Scala based project on Windows Azure.

First, signup for a free 90 day windows azure account at https://account.windowsazure.com/signup?offer=ms-azr-0018p

Second setup eclipse with the windows azure deployment plugin.  Use eclipse's Install New Software and enter http://dl.msopentech.com/eclipse for the url.  If you don't have azure sdk 1.8 installed it will be automatically installed when you select new Windows Azure Deployment project in eclipse.  It may take a while as the .Net framework 4.0 will be installed also.  A guide is available at http://msdn.microsoft.com/en-us/library/windowsazure/hh694271.aspx.

Third, setup new azure deployment project in eclipse.  I downloaded publish settings from my azure account and saved locally, then pointed the eclipse plugin to it.  A project was setup with a sample war file, various deployment scripts.  Once deployed, the cloud service was setup on azure automatically and the application deployed.  The first deployment is taking a while so we'll see if it finished.  Presumably the app will be available at http://playtest.cloudapp.net/

Unfortunately the deployment never finished.  I was however able to goto the manage azure portal and upload the deployment.  It asks for 2 things the "package" and the "configuration".  Both of these are found in the deploy directory of the azure deployment project (WindowsAzurePackage.cspkg and ServiceConfiguration.cscfg respectively).  Select them and click the check mark to begin the upload.  After a while (~ 20 minites) the application finish uploading and begin deployment.  Once that's complete you can access the app.  My example is at http://tomcattest2.cloudapp.net/HelloWorld/

Now, looking that the WorkerRole1 directory, I noticed the artifacts are in there -- jdk, tomcat war file.  So what if instead of a war file I have a play dist zip?  And further, what if the start.cmd didn't run catcline_home/startup.cmd but ran a java command to run the play app.  So I created new play app (play new play2Test) and then created a dist (play dist).  Then in the WorkerRole1\approot\start.cmd I added

start java -cp ".\play2test-1.0-SNAPSHOT\lib\*" play.core.server.NettyServer .

where play2test-1.0-SNAPSHOT is the dist of my empty play app.

Lastly, I updated the worker role components - right click the worker role and select properties/components.  I removed HelloWorld.war file and added my dist.  Told the worker to unzip it in the approot directory so that my java command above would find all the jars and run the app.  I tested locally using the azure emulator and it worked.  I also changed the endpoints to map port 80 to port 9000 the default netty port for play apps.

Then I began the deploy to cloud step which rebuilds the deployment for cloud instead of local and stopped it after the build was complete and the deployment had begun.  Then went to azure management portal and manually uploaded.  With any luck the app will be available at http://play2test.cloudapp.net/.

Play Framework 2.1 and Scala

After a bit of a wobbly start to the day, I finally got my brain activated and started plotting my next technical adventure.  I've been experimenting most recently with javascript frameworks like angularjs.  I found angular pretty good to work with, once I got over the initial learning curve.  MVC, Dependency injection, testable javascript, all good!  Unfortunately I didn't really realize the hoped for benefit of device specific rendering.  It seems to me that the nodejs server renders html to send to the browser, just like any other framework like grails, spring, jsf and play.  I enjoyed my experiences with Play 1.24 a year ago or so, and thought it would be nice to upgrade and work with scala instead of java.  Turns out, Play makes a good on ramp for scala experimentation.  Here's what I've done so far:

First things first, get play framework from http://playframework.org/.  I downloaded and unzipped the most current (2.1.RC2) and setup my machines path statement (Windows).  From there, I could follow the tutorial at http://playframework.org/documentation/2.1-RC2/ScalaTodoList.

I originally used my eclipse 3.7 JEE for editing after having run "play eclipse" on the todolist project.  Later I found the scala ide plugin for eclipse juno and downloaded and installed them from http://www.eclipse.org/downloads/ and http://scala-ide.org/download/milestone.html respectively.

I added twitter bootstrap to the tutorial app and pushed everything to my github account at https://github.com/sbasinge/todolist.

Now I am really ready to get rolling, but first I need to review the sample apps, in particular the comet and websocket based apps.  I think it would be interesting to create a online card game of some sort that uses comet or websocket for pushing cards, others actions, results, etc.

I'll let that stew for a while.  In the meantime, have a great time experimenting on your own -- and remember it's not as hard to do something, as it is to get started!  

Node.js and Angular

I started a couple of weeks back looking at MongoDB and Node.js as a means to create simple service application to return json data based on Spatial queries.  The idea that you can query for things that are X miles away from you is pretty compelling and almost normal operation on the web these days.  My current client has a need to do something similar so I set out to investigate MongoDB and Spatial queries.  I found a great example at http://loutilities.wordpress.com/2012/08/10/dogtag-app-in-30-minutes-part-1-node-js-and-mongodb/ which  had all the basics that I was looking for.  It took me about 2 hours to get the service application up and running on my openshift account.

The example uses Sencha touch for the client, which I have had some exposure to, but I really wanted to use a javascript page templating library like Mustache or Angular instead.  After a bit of research I found Angular's bundling of Jasmine and Testacular to be an awesome way to build TDD/BDD into a javascript application from the ground up.  I also like the model/view/controller implementation in Angular and it's straightforward templating language.

I haven't made it to my goal just yet but do have the json service running (Node.js over MongoDB) at https://petfinder-basinc.rhcloud.com/dogtag and I have the angular-seed project cloned and ready to begin web ui development.  So far I have invested about 4 hours and have learned a great deal so far.  

I can't wait to get started on the UI!

1. Started by setting up node.js server application on my openShift account using this as a guide.
2. The went thru the angular tutorial/intro at http://docs.angularjs.org/tutorial/step_00
3. The clone the angular seed project using "git clone https://github.com/angular/angular-seed petfinder-client"
4. Run the seed project using "node ./scripts/web-server.js"
5. Review seed app at http://localhost:8000
6. Review end-to-end test results at http://localhost:8000/test/e2e/runner.html
7. Next up is to link angular app to petfinder app on openshift.

Experiences with The Play Framework

A friend of mine recommended I look at the Play framework.  It was about the same time as I had decided that using a stateful architecture like JSF/JEE was a bad fit for mobile development.  Play is a stateless architecture based on JPA and a page templating language that allows Groovy closures and Expression Language to bind to backend beans.  More control over the HTML output can be achieved when you are writing the markup as HTML to begin with, versus the JSF tags.  So I've spent a few weeks working/playing with Play, JQuery and JQuery Mobile and here are a few topics and lessons learned.

1. Test Driven Development.  Play comes with a transactional test framework out of the box.  They recognize that you must test first.  Setting up a new Play project will give you a unit test (JUnit based), integration test (HTML Unit based) and a functional test (Selenium based).  You can extend and modify them to get your own testing off and rolling.  The cobertura plugin gives you code coverage right out of the shoot also, so you can see how well you are doing with your tests.
2. JPA Extensions.  A few convenience classes extend JPA to make base entities easier to setup, and collection maintenance slightly less problematic.  The injection of entity manager into the JPA beans makes the self-reliant, i.e customer.save() will save a customer object, no need for a 3rd party manager to do the work for you.  It is critical to get this layer started off on the right foot so that you will have a nice reusable, extensible set of logic and persistence at your disposal thruout the project.  
3. Controllers and page mapping.  The routing file maps incoming requests to controllers.  Controllers automatically marshal java POJOs and can validate them against javax.validation validators.   Error messages are re-rendered back to the ui and can be global (for the page) or field specific.  Mappings can be done based on request type, i.e. GET/POST/PUT/DELETE can map differently.
4. Page markup is done by writing the appropriate view html file.  A controller method Widget.index will look for the view file widget/index.html.  Further the index method will use render(...args) to initiate the rendering and pass POJOs to the page scope.  Write up the index.html by extending a site wide template.  Then use the beans set in the page scope to bind the page to your beans.  For example, if a Customer class has a lastName attribute, the the input text field with the id/name of customer.lastName will bind to the bean when you save the form.  There's lots of good examples on the Play framework site and in the apps in the distribution.
5. JQuery.  The few JQuery plugins that I've found invaluable are DataTables, MaskedInput, TimePicker, SelectMenu and RoundAbout.  These provide my application the sortable/paginated/filterable datatables, input masks for phone numbers/dates/etc., date and time picker, select one and select many pulldowns, and a carousel for scrolling thru data.  I have found that I like to define extra attributes on the html elements that I can use in JQuery selectors to control how elements get formatted.  For instance, if I change the type of an input field to be phone, then I can select and mask all phone numbers by using '$("input[type='phone']").mask("(999) 999-9999")'. 
6. JQuery Mobile.  There's two approaches to developing pages for JQuery Mobile.  In the first method, the server will deliver an html page that has all the html your mobile site will need.  Pages are divs or articles with the data-role=page.  Hrefs can be used for this 'internal' navigation via hashtag, e.g. <a href="#pagetwo" ...  You can attach javascript to the pageinit method and call the appropriate server url to get page contents and load them dynmically.  The other option is to use 'external' page navigation where the navigation link would use an external url, e.g. <a href="pagetwo.html" ...  JQM will automatically display a loading indicator, call the server to get the page, display error message in case of problems and replace the viewable DOM.  Pretty easy but less like to work in offline mode.  I am still discovering the best options for me in this area and JQM has a good page on navigation techniques at  http://jquerymobile.com/test/docs/pages/page-links.html.
7. Cloud Deployment.  I've used Heroku for cloud deployment for the Play applications I've developed.  Heroku has native support for Play! build lifecycle, so you are essentially performing a 'git push' and let Heroku build and deploy the application.  Postgres is the default database and the application.conf file has the settings you need to deploy to postgres.  Heroku will define a ${DATABASE_URL} that you can use in the conf file to connect to the database when in production mode:
1.  %prod.db=${DATABASE_URL}
2. %prod.jpa.dialect=org.hibernate.dialect.PostgreSQLDialect
3. %prod.jpa.ddl=update
8. Amazon S3.  Heroku only gives you temporary file based storage so if you want to store images on the file system you need to goto a provider.  Heroku is using Amazon EC under the covers and there are a few plugins for Anazon S3 (super simple storage).  I used some java code posted by James Ward ( https://github.com/jamesward/plays3upload) and tweaked it ever so slightly to cache the images in Heroku temporary storage once they are downloaded from AS3 so as to avoid going to get them thousands of times at which point Amazon will begin to bill you.
9. HTML Application Cache:  In concept it's like browser cache that survives restarts.  For mobile applications it can really make a difference to have javascripts, css and images already on the device. The downside of course is how to update things when they change.  Also problematic is the 'master' page will be stored in application cache too, so if the page is dynamically generated on the server things are apt to go awry.  Still working thru some issues on this one myself, but so far the pages are usable in 'airplane' mode when I use internal JQM navigation and I get less caching issues when I use 'external' navigation.

In summary, I've found working with Play! to be straightforward.  It's nice to have a web application framework that has everything you need to develop a web application right out of the box.  I am still uncertain about reuse of page markup particularly if you have a page that will dynamically update small fragments of itself.  I have written the page and the page fragment separately and duplicated markup in both. Also, the mobile pages are really similar to the browser/desktop pages with some reformatting.  Once again the display markup is duplicated.  There's not much in the markup, but it does slow things down when you need to make the same change in more than one place.

You can download Play! and learn more about it at http://www.playframework.org/.

More about JQuery Mobile at http://jquerymobile.com/demos/1.0/docs/about/getting-started.html

See my application on Heroku at http://golfplus.herokuapp.com/

  and http://golfplus.herokuapp.com/mobile

FredHQ's Roundabout: http://fredhq.com/projects/roundabout/
DataTables.net: http://www.datatables.net
Masked Input: http://digitalbush.com/projects/masked-input-plugin
Select Menu: https://github.com/fnagel/jquery-ui/wiki/Selectmenu
Date Time Picker: http://trentrichardson.com

Mobile Applications with HTML5 and CSS3

The pendulum swings:  it seems like web application development has been a square peg in a round hole for a while now.  We want highly interactive, user responsive web applications that feel like desktop applications.  We want separation of business logic from presentation tier.  We use JSP, ASP or JSF to act as the intermediary between the client and business tiers (take in html, process and emit html).  The HTML spec was written in a request/response paradigm which is hardly interactive and responsive.  So we add on Javascript to give web sites some interactivity.  And from here the worm begins to turn......

Javascript evolved from a tool marketers could use to add some sizzle to a web site, into a full fledged framework for control of the browser.  With CSS3, you can take advantage of local hardware to perform faster renderings than the browser could do alone.  All this makes me wonder if the JSP, ASP or JSF paradigms work in mobile phone development since they are both server side templating and emission of HTML.  With more advanced HTML and Javascript specs, could the browser really BE the templating and emission of HTML tool?  Could you just use the server to accept, emit and validate data via JSON/XML or whatever?  Would that allow the browser to store the data in local cache for later use, like when you get off the airplane or finish a phone call?  If this approach is good for the phone, then why not the desktop user?  Could web applications be written using HTML/JavaScript and JSON -- with a Spring, JEE or .NET stateless service handling get/post requests?

I don't know the answer.  It seems to me that the HTML spec may be missing some necessary templating rules to make that happen, i.e it would be nice to have a site format with top/left nav and footer applied to all pages.  Wait!  isn't that CSS' job.  What about large data, like images or content from a CMS?  The browser does a good job of caching these things locally already.

As browsers advance in efficiency and capability, and W3C has finally started to move the HTML/CSS specs forward, Maybe it's time to rethink the paradigm.

MySQL Database on OpenShift

I've been working on an application for my golf club that will allow us to arrange tee times, sign up and play, and report our scores.  I want to build the application with JEE6 technologies like CDI/Weld, JSF2 and JPA2. I started using JavaDB as a database.  Then I found OpenShift from RedHat as a hosting alternative.  It allows me to build the application locally on JBoss AS7 and then publish it to my OpenShift account using Git.  OpenShift also allowed me to change the DB over to MySQL by simply installing MySQL into my account using rhc-ctl-app -a "fw" -e add-mysql-5.1.  You can also add phpAdmin to make administration of your DB easier.  Here's a good blog on setting up OpenShift, MySQL, phpAdmin and Redmine: https://www.redhat.com/openshift/blogs/phpmyadmin-your-way-into-openshift-express-database-management-bliss

 You can see the application running at http://golfplus-basinc.rhcloud.com/.  I am now working to get Google Analytics and WebMaster tools hooked up to the application.  Once that's done, I can focus on the android cell phone component.  I will be reviewing phoneGap, Sencha and Tiggr as alternatives to straight up Android SDK.