Throttling Back My Writing Schedule

For a while, I have been writing a post a day.  Then I took a vacation, and cut back to 2-3 times a week in order to spend more time with the family.  I actually like the 2-3 times a week schedule because it lets me take time that I was previously using to write and spend that investigating new technology and tools.  Or to write meatier posts.

So, I think that will be the new normal.

Just wanted to let you know.

PS If you don’t want to check back periodically, you can subscribe to my blog.



My Favorite Eclipse Shortcuts

Learning your tools can make you far more efficient, whether those tools are Photoshop, Sublime Text, or Microsoft Word.  I do a fair bit of java development, so I use an IDE called Eclipse.  Here are some of my favorite shortcuts. (Note that you can personalize eclipse shortcuts via the menu outlined here.)

  • control-shift-t: look up a particular type/class by name
  • control-shift-r: look up a particular file by name
  • alt-shift-c (custom): check in the file I’m working on
  • control-f5 (custom): re-run the last thing I ran (typically a unit test)
  • control-h: search through any files for a given string (can set up patterns for the file names if desired)
  • control-f8: shift perspective (from java to debug, for example) without my hands leaving the keyboard

Also, I always install vrapper, which lets me move around my editor screen via the vi movement keys.

What shortcuts do you use to get around eclipse?


Should you be mapping or using a GPS?

gps photo

Photo by Jimmy_Joe

I recently spent a long time in the car, driving cross country. I had a GPS that led me from across the USA, including through New York City, at 60-80 miles an hour. It was easy and convenient to focus on the road and the radio while listening to the dulcet tones of the GPS, but I missed the map reading and location awareness I’d had in previous cross country trips, when using a Rand McNally atlas. Because all I’d been doing was following directions, I didn’t have the understanding of the larger context–how roads fit together, what cool places were just off the interstate, or even which city I stopped in for lunch.

In the vein of Mark Suster’s “Is it Time to Learn or Earn” (which is definitely worth a read), I wanted to talk about whether your current task is a “mapping” task or a “GPS” task, and what each type of task looks like.

Mapping tasks can be high level or low level, but share the following characteristics. They:

  • require you to look at the big picture
  • are focused on a long term goal, not tactics
  • often result in serendipitous results
  • take longer
  • sometimes require backtracking from dead ends
  • make you stop every so often and look around
  • have learning as a direct goal
  • require iterative search queries

Examples of some of my past mapping tasks include selecting a public records data vendor, hiring an employee, creating my first REST API, and making my first departmental budget. Don’t be afraid to ask for help with mapping tasks, or to stop every so often and make sure you on right track.

GPS tasks, on the other hand, tend to be tactical. GPS tasks:

  • often have clear directions (sometimes from others, sometimes from your experience)
  • don’t require you to understand context
  • require little, if any, exploration
  • are action oriented
  • often are smaller in scope
  • have learning as a by-product, if at all
  • can be phrased as a single google query
  • may not be core to your business or job

Some of my past GPS tasks include: setting up a virtual server for development, finding a way to display release changes in maven, connecting to the QuickBooks Online API and writing an employee review (after the first one).

The main difference between these tasks is the amount of context needed. With mapping tasks, you have to have your head up and be “looking around” at the problem landscape. With GPS tasks, you can put your head down and just “drive” toward task completion.

If you do a GPS task often enough, you’ll start to acquire context, just as if you drive with a GPS around a new city for a few days, you start to see how the streets and areas fit together. The first time you do something relatively complex, like setting up a new server, hiring or making a department budget, it will be a mapping task–but after a few times it may turn into a GPS task (especially if you document your process).

Next time you take on a task at work, think about whether it is a complex, big picture task that would be best handled by mapping, or a quick, “gotta get this done” task that you don’t need to fully understand.



Preparing Your AngularJS App for Deployment

angle photo

Photo by kevin dooley

I have recently been working on an AngularJS CRUD front end to a REST API (built with DropWizard).  I have been working off the angular-phonecat example app (from the tutorial).

After making a few changes, I wanted to deploy the app to a standalone web server (Apache2).  I naively checked out the codebase on the web server, and visited index.html.

I saw a blank screen.  Looking in the console, I saw this error message: ReferenceError: angular is not defined

Whoops.

“Looks like there’s more to deploying this application than I thought.”  Some searching around doesn’t reveal a lot, maybe because deployment is just taken for granted in the AngularJS community?  Or I don’t know what questions to ask?

Regardless, the fundamental fact of building AngularJS apps for deployment is that, at least with the angular-phonecat base, your dependencies are managed by bower and/or npm, and you need to make sure you bundle them up when you are running on a web server that isn’t the npm started web server.

In practice, this means writing a Gruntfile (or, actually, modify this Gruntfile), which is similar to an ant build.xml file–you write targets and then gather them together.

For my initial Gruntfile, I wanted to make things as simple as possible, so I stripped out some of the fanciness of the g00glen00b file.  In the end, I had two tasks:

  1. bowercopy to  copy my bower dependencies to a temp directory.  I tried to use the bower grunt task, but wasn’t able to make it work.
  2. compress to gather the files and build the zip file

These were bundled together in a ‘package’ task that looked like this: grunt.registerTask('package', [ 'bowercopy', 'compress:dist' ]);

The compress task is complicated and took some figuring out (this post was helpful, as was a close reading of the task’s readme page and the page detailing how file objects can be dynamically generated). Here’s an example of the dist task:

 compress: {
          dist: {
            options: {
              archive: 'dist/<%= pkg.name %>-<%= pkg.version %>.zip'
            },
            files: [{
              src: [ 'app/index.html' ],
              dest: '/',
              expand: true,
              flatten: true
            }, {
              cwd: 'dist/libs',
              src: [ '**' ],
              dest: 'bower_components',
	      expand: true,
            },
              // ... more files definitions 
            ]
          }
  }

I want to unpack this a bit. First, the options object specifies an archive file and the name of the file. You can see that it is dynamically created based on values from the package.json (which is read in earlier in the grunt config file).

Then, the set of files to be added to this archive is specified. The src attribute outlines the list of files to include in the zip file. src handles wildcards (* for all in the directory, ** for all in the directory and subdirectories). The dest attribute, in contrast, indicates the directory where the file is to land in the zip archive. The expand attribute lets grunt do dynamic file matching (more here). The flatten attribute removes all the leading paths from the source files–if you didn’t have flatten:true in the index.html entry, it would be placed at /app/index.html in the zip file. The dist/libs entry handles all the dependencies that were copied to that tmp directory by the bowercopy task. What the cwd attribute tells grunt is to act like it is in that directory for the src attribute. So, a file at dist/lib/foo/bar will be treated like it was foo/bar and, in the task above, copied to bower_components/foo/bar in the zipfile. This allows one to maintain the same directory structure in my index.html file in both dev and production.

Finally, you need to install grunt and run grunt package to get your zipfile with all dependencies, for deployment.

There are a lot of other beneficial changes grunt can make to your app before deployment, like concatenating css and minifying the javascript, and I encourage you to read this post for more information, but this was enough to get the app running in an environment without npm or any of the other angularJS toolchain.


Java REST API Framework Options

resting photo

Photo by shioshvili

I’ve been working with a couple of REST API solutions that exist in the Java tech stack.  I haven’t seen any great analysis of REST API solutions (though Matt Raible does mention some in this exhaustive slide deck about Java frameworks [pdf]), so wanted to share my on the ground experience.

First up is restSQL.  This framework makes it easy to get data from a database to a JSON or XML REST API and back.  If you have a servlet container available, you write two configuration files, one with a SQL query and one with db connection information, and you have a RESTful API.  For prototyping and database access, it is hard to beat.

Pros:

  • Quick to set up
  • Only SQL knowledge is required
  • No programming required
  • Allows simple mapping of db table to resource, but can include one to one and one to many mappings
  • Supports all four REST operations out of the box
  • Supports XML as well as JSON
  • Is an embeddable java library as well as a standalone framework
  • Project maintainer is engaged and the project is moving forward

Cons:

  • Requires a servlet engine, and you have to restart it for changes to your configuration to be picked up
  • Output format has limited customization
  • Only works with mysql and postgresql databases (though there is some experimental support for Oracle and MS SQL)
  • Doesn’t work with views
  • The security model, while fine grained, isn’t modern/OAuth (can be solved with an API gateway (like 3scale, Tyk or ApiAxle) or proxy

The next framework I have experience with is Dropwizard.  This is a powerful framework that creates uberjars that you can run on any port as a standalone service.  It’s not limited to providing a JSON representation of database tables–if you can create a Java object, Dropwizard can serve it up as a JSON resource.

Pros:

  • Community support
  • Extreme output formatting flexibility, but be prepared to write a custom deserializer if you want to handle anything other than reads of custom formatted objects
  • Supports any database that hibernate supports
  • Built in testing support
  • Brings together ‘best of breed’ tools like Jersey, Jackson and Hibernate, so you don’t have to do the integration yourself
  • Great documentation

Cons:

  • Have to roll your own deployment solution (tarball, chef, puppet)
  • No services startup script provided
  • Shading can slow down development
  • Not yet at 1.0 release

The last one I don’t have familiarity with, but a colleague used it in the past.  It is Sparkjava.  This is a lightweight framework that fits when you have an existing Java library with functionality you want to expose.  I’m not competent to write pros/cons for this framework, but wanted to mention it.

The gorilla in the room that I haven’t had experience with (in terms of writing RESTful webs services) is Spring.  I would definitely include this in any greenfield solutions review.



#TBT: Business Process Crystallization

crystal photo

Photo by włodi

This is a repost from over a decade ago, about how software coalesces and defines business processes. The post is a little rough (“computerizing tasks”?), but hey, I’d only been blogging for months.

The ideas are sound, though. The longer I’ve been around this industry, the more the ideas in this post are reinforced.

————————————————————-

I’m in the process of helping a small business migrate an application that they use from Paradox back end to a PostgreSQL back end. The front end will remain written in Paradox. (There are a number of reasons for this–they’d like to have a more robust database, capable of handling more users. Also, Paradox is on the way out. A google search doesn’t turn up any pages from corel.com in the top 10. Ominous?)

I wrote this application a few years ago. Suffice it to say that I’ve learned a lot since then, and wish I could rectify a few mistakes. But that’s another post. What I’d really like to talk about now is how computer programs crystallize business processes.

Business processes are ‘how things get done.’ For instance, I write software and sell it. If I have a program to write, I specify the requirements, get the client to sign off on them (perhaps with some negotiation), design the program, code the program, test it, deploy it, make changes that the client wants, and maintain it. This is a business process, but it’s pretty fluid. If I need to get additional requirements specification after design, I can do that. Most business processes are fluid, with a few constraints. These constraints can be positive: I need to get client sign off (otherwise I won’t get paid). Or they can be negative: I can’t program .NET because I don’t have Visual Studio.NET, or I can’t program .NET because I don’t want to learn it.

Computerizing tasks can make processes much, much easier. Learning how to mail merge can save time when invoicing, or sending out those ever impressive holiday gift cards. But everything has its cost, and computerizing processes is no different. Processes become harder to change after a program has been written or installed to ‘help’ with them. For small businesses, such process engineering is doubly calcifying, because few folks have time to think about how to make things better (they’re running just as fast as they can to stay in place) and also because computer expertise is at a premium. (Realizing this is a fact and that folks will take a less technically excellent solution if it’s maintainable by normal people is what has helped MicroSoft make so much money. The good is the enemy of the best and if you can have a pretty good solution for one quarter of the price of a perfect solution, most folks will choose the first.)

So, what happens? People, being more flexible than computers, adjust themselves to the process, which, in a matter of months or years, may become obsolete. It may not do what they need it to do, or it may require them to do extra labor. However, because it is a known constraint and it isn’t worth the investment to change, it remains. I’ve seen cruft in computer programs (which one friend of mine once declared was nothing but condensed business knowledge), but I’m also starting to realize that cruft exists in businesses too. Of course, sweeping away business process cruft assumes the same risks as getting rid of code cruft. There are costs to getting rid of the unneeded processes, and the cost of finding the problems, fixing them, documenting them, and training employees on the new ones, may exceed the cost of just putting up with them.

“A computer lets you make more mistakes faster than any invention in human history – with the possible exceptions of handguns and tequila.” -Mitch Ratcliffe, Technology Review, April 1992

A computer, for the virtue of being able to instantaneously recall and process vast amounts of data, also crystallizes business processes, making it harder to change them. In additional to letting you make mistakes quickly, it also forces you to let mistakes stand uncorrected.


Headline: Android User Buys App

cash register photo

Photo by liewcf

A few weeks ago, I bought my first app on Google Play.  Wait?  I thought Android users don’t buy apps?  Well, what can I say, I like to break the mold.

Actually, I think I’m pretty typical for a high end Android phone owner.  I have had an Android phone since 2010–I paid hundreds of dollars for each of my phones.  My wife is a diehard iPhone owner.  At the time I purchased, she wondered why I wanted to buy an Android.  The application process for writing apps is one reason, and another is being able to write an app, on whatever computer I wanted, and install it on my phone.  Now I’m in Google’s ecosystem, and it would take a lot to pull me out of it.

Regardless, I finally bought an app!  I was looking for music on my phone, and have long been a fan of soma fm, ever since John Argo introduced me to them–about a decade ago.  Groove Salad is excellent for doing development.  I looked up their app, and it was $4.  soma fm is one of those organizations that I’ve been meaning to contribute to for years (like KGNU, they are listener supported and commercial free), but never got over the hump.

This was my chance to support the radio station which I loved!  Google made it easy–just had to enter a billing method (options included credit card, paypal, and bill to my phone account) and re-enter my password.  (Yes, I realize this was a small donation in the scheme of things.  The app has convenient links to the donation page.

So, what does this anecdote mean for people looking to make a living selling apps?

Don’t count on me, because the only app I’ve ever paid for was because it was a donation.

I had a long conversation with a friend about this and it appears to me that mobile apps are, in the vast majority of cases, complements to existing businesses, and not businesses themselves.  That was my experience at 8z as well. Being a complement is still a ginormous market, but it isn’t a goldrush for individuals.



© Moore Consulting, 2003-2017 +