2012-03-29
POSSCON 2012
I had a great time at POSSCON 2012, met up with Steve Graham (a fellow Triangle Resident), got to talk to Jon 'Maddog' Hall, and a whole host of Open Source luminaries. I even learned what a Palmetto is.
My talk was An Introduction to Grails where in I live code while explaining each line. The source code is up on github now if you want. The slides are naturally available below:
POSSCON is definitely a conference you should check out.
Labels:
talk
2012-03-20
Functional Programming in Java @ TriJUG
Last night's slides presented at TriJUG.
Code is available on github. Special thanks to Muhammad Ashraf for his contributions and peer review.
Code is available on github. Special thanks to Muhammad Ashraf for his contributions and peer review.
Labels:
talk
2012-02-11
F.lux
F.lux is a free as in beer application that alters the color of your screen. It can help people who have problems sleeping after heavy computer use. At minimum it makes your laptop feel more cozy at night.
I don't normally write endorsements for applications in this space but I had to make mention of a bit of software written by David Santiago. The idea behind F.lux is that your laptop is designed to look good during the day, at night the color balance changes around you and your laptop's color should too.
I recently moved myself to a new MacBook Pro and it's crisp display does look quite good during the day. I had found myself using the laptop late at night wanting to get a little something done. Some how, these late night coding adventures would end up stretching later and later. Recently, I looked up and noticed it was 4:30 am and I wasn't tired.
I had been told about F.lux by another MacBook Pro owner and so I installed it that early morning. The software immediately altered my screen color to a pleasant amber tint. Within five minutes I was sleepy.
I had not realized what a huge effect staring at the blue tinted screen was having on my sleep cycle. I wonder how many other professional computing people are suffering from a similar problem and are completely oblivious to it.
If you suspect you might be one of the people who like me are very effected by local lighting you should definitely take this for a spin. If David Santiago had a tip jar I'd definitely drop a few bucks in there. He deserves a beer for saving my sleep cycle.
Thanks David.
2012-02-08
Google+ ate my blog.
I am simply not blogging anymore. The content I would put here is ending up in Google+. I'm not sure why that is. Using Google+ seems more targeted and lighter weight than using a blog.
A blog feels heavier, more official and more permanent. Google+ feels less permanent and lighter. That's just the impression I have. I know logically that both medium are potentially longer lasting than concrete and more public than a billboard plaster over the moon.
The experience of blogging involves "going to" the blog where as a Google+ experience is both reading and writing at the same time. The user experience is fluid. The content can be the same size, shape, and form for the most part but the feeling of disengaging and "going off to write" is much more psychologically present with a blog. It feels like "something I have to do" as opposed to something that just happens while I'm doing another thing.
It would be nice if there was a way for my Google+ posts to flow into my blog with the addition of a tag. Maybe someone could write that and become famous for it.
Okay, enough of that... we have work to do. Now get to it!
A blog feels heavier, more official and more permanent. Google+ feels less permanent and lighter. That's just the impression I have. I know logically that both medium are potentially longer lasting than concrete and more public than a billboard plaster over the moon.
The experience of blogging involves "going to" the blog where as a Google+ experience is both reading and writing at the same time. The user experience is fluid. The content can be the same size, shape, and form for the most part but the feeling of disengaging and "going off to write" is much more psychologically present with a blog. It feels like "something I have to do" as opposed to something that just happens while I'm doing another thing.
It would be nice if there was a way for my Google+ posts to flow into my blog with the addition of a tag. Maybe someone could write that and become famous for it.
Okay, enough of that... we have work to do. Now get to it!
2011-12-01
What is Computer Science?
"Computer Science is the Science of Computing Machinery."When I hear this I want to put a stick in the eye of the person who just said it. That's not a definition, it's a slogan. Yet, this is the definition used in most textbooks that even try to tackle the subject.
Let's sit down and try and break this apart. When do we cross the line from just being a machine and becoming a computing machine? Where is the distinction? Perhaps that will tell us something.
If I take a light bulb and plug it in and it turns on, that's not a computing machine.
If I take a light bulb and plug it in and it flickers... not still not computing since the flicker is random and has nothing to do with anything outside the light bulb.
If I take a light bulb and plug it in and it doesn't light. That's not computing, that's broken.
If I take a light bulb and it has a sensor so that when I plug it in, it doesn't light ... until I darken the room. In the dark it turns on, and in the light it turns off.
This machine has now crossed into the realm of computing. Albeit the simplest possible processing is happening: an outside stimulus is causing a response. We could call this a stimulus-response agent. Even so, this is now a computing machine and what is going inside this simple device is the very smallest beginning of something of interest.
Now, name a system that we can clearly define as a computer that does not exhibit some form of this behavior. Even a batch processing system that starts at a given time takes input or stimulus from outside itself, processes this inside itself, and then produces output.
What is Computer Science? We study something called "Computing" perhaps that should have been the name of the field? Computing is really what I've been working with my entire career and that's really what the degree is all about.
2011-11-17
The Life Cycle of Plugins & Addons in the Enterprise
I'm probably one of the few people in the world that has had the opportunity to work with both Grails and Spring Roo on extended projects. In both environments I've discovered a strategy around code reuse that is a bit different from what I normally observe in the Enterprises I consult with.
Both Spring Roo and Grails feature a reusable component system. They are similar enough you can use similar strategies in the enterprise with either Spring Roo or Grails. If you are in an enterprise that uses both Grails and Roo (these companies do in fact exist), I recommend that you develop common functionality in Spring POJO then graft a Grails plugin and/or a Spring Roo addon over the top.
In Grails, plugins are powerful sub-applications. A plugin can provide a command line script to the Grails CLI, a library, a library dependency, to a full set of Model View and Controllers or anywhere in between.
In Spring Roo, we term these reusable components addons because they do not necessarily contribute runtime functionality to the final system. Spring Roo's philosophy of having zero runtime footprint means that you don't have a Roo runtime to hang your hat on. What you do have is a very powerful Command Line Interface (CLI) that you can leverage along with a templating system inside your Roo addon to allow your end-user-developer to generate their own components. Instead of shipping function as you do in Grails, in Roo you provide a mechanism for guiding the developer through generating function.
Whether you are shipping function wholesale, as you do in Grails, or you are providing functional templates as you do in Roo, in an abstract sense I've discovered the same pattern applies to both Roo and Grails. You start with a pilot project for the addon or the plugin and you lift it out of the pilot project allowing it to graduate to a shared enterprise-wide repository.

As time goes by, you work on the addon or plugin as a separate project. Each project that uses the addon/plugin will keep track of its own versions of these addons meaning it is important to keep those old revisions available just in case. You will also want to tag each released revision in the event you need to back port fixes into old releases should a critical project get stuck on an old version of Roo or Grails for some reason.
The advantages to the enterprise would be a single place to revision control the client components of a Single Sign On system, or a single place to revision control and distribute shared client functions, look and feel components, or other commonly reused system components.
Both Spring Roo and Grails feature a reusable component system. They are similar enough you can use similar strategies in the enterprise with either Spring Roo or Grails. If you are in an enterprise that uses both Grails and Roo (these companies do in fact exist), I recommend that you develop common functionality in Spring POJO then graft a Grails plugin and/or a Spring Roo addon over the top.
In Grails, plugins are powerful sub-applications. A plugin can provide a command line script to the Grails CLI, a library, a library dependency, to a full set of Model View and Controllers or anywhere in between.
In Spring Roo, we term these reusable components addons because they do not necessarily contribute runtime functionality to the final system. Spring Roo's philosophy of having zero runtime footprint means that you don't have a Roo runtime to hang your hat on. What you do have is a very powerful Command Line Interface (CLI) that you can leverage along with a templating system inside your Roo addon to allow your end-user-developer to generate their own components. Instead of shipping function as you do in Grails, in Roo you provide a mechanism for guiding the developer through generating function.
Whether you are shipping function wholesale, as you do in Grails, or you are providing functional templates as you do in Roo, in an abstract sense I've discovered the same pattern applies to both Roo and Grails. You start with a pilot project for the addon or the plugin and you lift it out of the pilot project allowing it to graduate to a shared enterprise-wide repository.

As time goes by, you work on the addon or plugin as a separate project. Each project that uses the addon/plugin will keep track of its own versions of these addons meaning it is important to keep those old revisions available just in case. You will also want to tag each released revision in the event you need to back port fixes into old releases should a critical project get stuck on an old version of Roo or Grails for some reason.
The advantages to the enterprise would be a single place to revision control the client components of a Single Sign On system, or a single place to revision control and distribute shared client functions, look and feel components, or other commonly reused system components.
2011-11-01
The Highly Monitored Grails Application @ SpringOne 2GX 2011
My second talk at SpringOne 2GX was "The Highly Monitored Grails Application" and it had a great turn out from a large and lively audience. This was fantastic especially considering I was presenting as the very last presenter of the conference. This was one of the best received talks I've ever given.
The talk was demo heavy and so, while there's not much in the slides we spent a lot of time in my IDE, at the command line, and running through ways to monitor and work with live Grails applications. We even manipulated the hibernate settings in a running Grails application! Great fun!
Definitely the highlight of my SpringOne 2GX conference!
The talk was demo heavy and so, while there's not much in the slides we spent a lot of time in my IDE, at the command line, and running through ways to monitor and work with live Grails applications. We even manipulated the hibernate settings in a running Grails application! Great fun!
Definitely the highlight of my SpringOne 2GX conference!
Labels:
grails,
groovy,
SpringOne 2GX,
talk
Subscribe to:
Posts (Atom)