22 Jun

NFJS Fall 2010: What do you want to learn?

Posted by mattstine in nfjs.

Hi everyone! I’m currently in the process of developing new talks for my Fall 2010 NFJS tour dates. While I don’t know yet where I’ll be speaking, I can tell you that I’ve registered availability for the following shows:

  • Boston, MA
  • Seattle, WA
  • Atlanta, GA
  • Minneapolis, MN
  • Chicago, IL
  • Denver, CO

So, if you’re in one of those cities and you’re thinking about attending NFJS when it comes your way (see here for the schedule), I’d like to know what you want to hear about assuming I come your way.

To narrow down the potentials a bit, here are my personal areas of focus:

  • Agility/Lean/Kanban
  • Native Mobile and Web Mobile Software Development (iPhone/iPad/Android)
  • Web Development in General (HTML5/CSS3/JavaScript)
  • Modularity and OSGi

If there are any topics from these four areas that you’d like to hear more about, please speak up in the comments section. And even if you’re not in one of these cities, most of any talks I develop for the Fall will likely show up on the 2011 tour as well, so please speak up anyway!

Thanks in advance for your feedback!

3 Jun

Don’t build software that’s TOO smart!

Posted by mattstine in agile, development.

I had an extremely successful meeting with one of our clients yesterday. We were discussing how we wanted to go about migrating her laboratory from its current system (one that we built several years ago) to our new lab management platform. At some point during the discussion I made the statement, “We tried to make the previous system too smart! We’re not repeating that mistake this time.” Of course, she was in complete agreement with that principle. I’ve had similar interactions with our other clients that are making migrations (rather than encountering our system for the first time on this new version), and although I’ve never explicitly stated the principle that way, similar sentiments have abounded.

What is too smart software? In our case, it was a system that attempted to encapsulate every single rule of “business” process that occurred within a given laboratory. Many times statements were flung around like “will it ALWAYS happen this way,” “what should we do if this happens?” etc., etc., etc. We tried to cover every single possibility, and we did an excellent job of preventing users from ever breaking their own rules. What we didn’t realize (and we’re not unique – this problem is RAMPANT) is that the rules CHANGE. Rules come, rules go. Sometimes the rule remains, but there are a few exceptional cases that must be dealt with. Our system simply couldn’t deal with a world that worked this way – and thus, our system was completely unfit for the real world.

We set out with a different mission this time. If there’s one overriding characteristic of SRM (Shared Resource Management) 2.0, it’s the explicit assumption that the world will change continually. We don’t attempt to tell you how you must use this system. We capture your data, we invoice for your services, we run your reports – but YOU, the user gets to decide how you’ll interact with it. If your workflow changes, we change with you. Now the devil is in the details. It’s taken roughly 20-30 man years worth of effort to build a system like this, and it hasn’t been easy. But in the end, we’re finding that those years were much better spent ENABLING our users rather than PREVENTING our users from getting things done.

I’m not sure that I’ve gotten my point across in this brief diatribe, so I’ll attempt to sum it up here. If you’re developing a system, figure out the 2 or 3 things that will make your users’ lives AWESOME, and do those 2 or 3 things extremely well. Don’t do the rest AT ALL. Don’t build a system that attempts to be smarter than the knowledge expert using it – it’s a means to your user’s end, not an end in itself.

28 May

Announcing NOSQL Summer Memphis

Posted by mattstine in cloud, jug, nosql, Uncategorized.

I recently stumbled across the NOSQL Summer website via my friend Alex Miller’s blog. The idea is to setup a summer reading club focused around databases and distributed systems. Groups will gather “worldwide” to discuss various papers and the hopefully submit the substance of their discussions back to the NOSQL Summer website in the form of annotated papers.

This sounded like a great idea to me, so I decided that we’d co-locate a NOSQL Summer discussion with our monthly Memphis JUG meetings. You can find the details of our NOSQL meetings at http://nosqlsummer.org/city/memphis. We’ll start at 5:30 and run until 6:15-6:30. If you’re interested in these discussions, come on out to Southwest TN Community College on June 24th (even if you’re not a Java type!).

Our first paper will be The End of an Architectural Era (It’s Time for a Complete Rewrite). Please read it before the meeting and come prepared to mindshare.

If there’s enough interest in these discussions, we could start having a lunch time discussion at a centrally located restaurant halfway between each JUG meeting. We can discuss this at our first meeting in June. I hope to see you there!

6 May

First thoughts on “Seven Languages in Seven Weeks…”

Posted by mattstine in bookreviews.

I recently started reading the beta copy of Bruce Tate’s Seven Languages in Seven Weeks from the Pragmatic Bookshelf. While I’m certainly NOT on pace to actually complete the book in seven weeks, I have been steadily plodding along. Reading this book takes me back to my days as an undergraduate computer science student at the University of Mississippi. As with most CS programs, we were all required to take a “Survey of Programming Languages” course toward the end of the curriculum. Tate’s book is very similiar to walking through this course, except:

  1. Tate’s text and suggested exercises are intensely practical, targeted at actually getting something useful done in the language.
  2. The language selection is entirely relevant to today’s practitioner. Chances are good that you’ll use a language from this set in your day job sometime in the next decade. Ignoring that, chances are good that you’ll use some language that is a “close cousin” of a language from this set.
  3. Your thinking about programming in general will be challenged by each chapter. This is not a leisurely read. You cannot “coast” through this course.

At present I’m slowly working through the chapter devoted to Io. Io is a prototype-based language, close-cousins with Lua (of recent iPhone game development controversy) and JavaScript (can’t think of a practical use for this guy…umm…oh wait!). I’ve very much enjoyed Bruce’s treatment of the language, with his descriptions of the feature being as “visual” as words can effectively be – who else could liken languages to popular movie characters and get away with it? Before working through Io, Bruce and I tackled Ruby together. Ruby is an old and unfortunately neglected friend of mine. We’ve had our fun together doing a couple of small Rails applications, JUG talks and a (so far) unsuccessful trek into the world of OSGi, but unfortunately we haven’t hit the big time in my day job. Working through this chapter really served to reignite my enthusiasm for the language, especially as it relates to the rich ecosystem of testing tools available in the Ruby and Rails communities.

In short, only two chapters in I’d thoroughly recommend that you purchase this book. Like Beyond Java before it, Bruce has again challenged us to step outside of our comfort zone. If nothing else, you’ve got seven kickstarts into learning your “Language of the Year.”

29 Apr

OSGi on Rails?

Posted by mattstine in java, osgi.

I’ve seen quite a few blogs/articles/etc. lately related to the adoption (or lack thereof) of OSGi in the mainstream web application/enterprise application space. A nice summation of these is encapsulated in this excerpt from a comment by Peter Kriens on DZone (you’ll find it in the comments section for http://java.dzone.com/articles/osgi-perspectives:

Yes, one of the next frontiers is to make OSGi easier to use for the web app developers. The solid foundation is there, so stop whining and help us create the tools, books, and tutorials that will make OSGi palatable in those markets.

There’s nothing like a call to action to get me stirred up. It’s no secret that I think OSGi is an excellent tool for tackling the complexity of enterprise applications (see my talks on the NFJS tour this year: http://www.nofluffjuststuff.com/conference/speaker/matt_stine). However, I will readily admit that the learning curve for tackling any non-trivial application in OSGi is rather steep. My bar for non-trivial is quite low – try learning OSGi while simultaneously attempting to get a mainstream framework like Hibernate working properly.

I think that what we need is a tool that will enable a developer new to OSGi to get an OSGi-enabled web application up and running fairly readily. In fact, I think it would be good to absolutely minimize the amount of OSGi know-how required to get a basic web application into production, while at the same time leaving all of OSGi available just under the covers so that it can be easily accessed when I know what I need and how to use it. So here’s my proposal:

1) Follow in the footsteps of AppFuse, Grails, Rails, Roo, etc. and put together a web application toolkit that will allow one to instantly spin-up a deployable OSGI-enabled web application.
2) Since we’re talking about catering to mainstream here, Java the language ought to be the primary language used for development. With that said, we should not put up any barriers to using other languages available on the JVM.
3) Bootstrap a DB-agnostic persistence layer leveraging JPA and make it easily accessible across the application bundles.
4) Bootstrap a dependency injection framework for OSGi services based on the Blueprint standard.
5) Bootstrap a security layer and provide a basic user/role security module with provided login, logout, etc. facilities.
6) Pick a set of modern Java web application frameworks (e.g. Spring MVC, Struts 2, etc.) and make them easily pluggable.
7) Wrap a nice build system around all of this that leverages a modern build tool (e.g. Gradle or Maven 3), the best of the PAX Tools features (especially Pax Construct, Exam, and Runner), and good facilities for automated testing.

So, who’s with me? I’m open to any suggestions/comments/rants, etc.

2 Apr

JUG Leadership Lessons Learned on SlideShare

Posted by mattstine in java, javaone2009.

I’ve been playing a bit with SlideShare today and I took the opportunity to upload the slides from my Java.net Community Corner interview with Kevin Farnham at JavaOne 2009. SlideShare has a nice feature that allows you to sync up the audio from an MP3 file with your slides, and since both were available, I thought I’d give it a try. The interface is extremely easy to use and I’m very happy with the outcome.

This talk covers the various things I’ve learned about leading a Java User Group over the past few years. I would say that these are definitely applicable to leading any type of user group, so even if you aren’t a Java person, you might find some meat here. Enjoy!

16 Feb

Dead Programmers Society

Posted by mattstine in development, programming.

A local Pastor once gave the advice of introducing ourselves and our kids to dead people. It is his belief that if his kids grow up idolizing the likes of Eric Liddell, Jim Elliot, and Hudson Taylor, they would be far better off than by looking up to many of our so-called “heroes” of today. I happen to agree with his advice, but that’s not the subject of tonight’s blog entry.

I think that this advice is very applicable to us as software developers today. While our industry is still young enough that a great many of our “founding fathers” are still around, it is surprising to see how often their work and contributions go unnoticed by the vast majority of us. At the January Memphis/Mid-South Java User Group meeting, our program focused on books that all of us as developers should read. Four of us gave our takes on the topic. Joel Neely, one of a few people that I learn from every time I get near them, pulled yet another rabbit out of his hat by focusing on several books, all of which had been published before the majority of us were out of diapers! One book struck me in particular: A Discipline of Programming by Edsgar W. Dijkstra. In it EWD “presents a formal approach to developing (non-deterministic!) algorithms, using what we would now call a DSL for algorithm design. Incidentally, that book was published in 1976.” (Thanks Joel for the excellent summary). I’d like to pull out just a couple of quotes from that book:

A most important, but also a most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language, this influence is – whether we like it or not – an influence on our thinking habits.

Just out of curiosity, does this sound anything at all to you like the frequent admonitions to learn a “language of the year (LOTY)?” Of course that isn’t the context of EWD’s quote, but the underlying principle remains the same. Almost universally accompanying that admonition is a statement along the lines of “even if you never use it in your day job, it will affect THE WAY YOU THINK about programming during your day job.”

…a carefully chosen separation of concerns is essential for the design of in all respects, high quality programs…

Does “loosely coupled, highly cohesive, modular architecture” come to mind?

…the fact that programming languages could be used as a vehicle for instructing existing automatic computers, has for a long time been regarded as their most important property…we shall try to redress the balance, and we shall do so by regarding the fact that our algorithms could actually be carried out be a computer as a lucky accidental circumstance that need not occupy a central position in our considerations…I view a programming language primarily as a vehicle for the description of (potentially highly sophisticated) abstract mechanisms.

I hear so much of what is bandied about today as “new” embodied in this quote. The calls to liberate programming from its “C” roots by banishing primitives, because hey, primitives are only their to keep “Java from being too slow!” The calls to favor “essence over ceremony” in language design by eliminating boilerplate code in favor of sensible defaults that clear away the noise from the algorithmic intent that we’re trying to communicate. The constant reminders that it’s more important for our code to be readable to humans, not to computers, because that’s what compilers are for.

What’s the point? The point is that most, if not all, of the ideas that are “new” today are simply restatements of past ideas in a different context. A wise man, one much wiser than I, once said “…there is nothing new under the sun” (Ecclesiastes 1:9). Edsgar W. Dijkstra passed from this earth in 2002, but his ideas live on, and they are very much applicable to software developers today. There are may others like him: Donald Knuth, John McCarthy, Alan Turing, David Gries – some dead, some alive, but all giants upon whose shoulders we stand. We would do well to consider their words.

6 Jan

LOTY/TOTY for 2010

Posted by mattstine in loty, Uncategorized.

If anyone’s interested, here’s a clue as to what I’m working on in 2010:

10 Nov

Securing Grails Plugin Artifacts with Filters

Posted by mattstine in grails, groovy.

So you’ve just installed the handy dandy Spring Security plugin (http://grails.org/plugin/acegi), which makes it incredibly easy to secure entire Grails controllers and/or controller actions with annotations, such as the following:

This is enabled by turning on controller annotations in your SecurityConfig.groovy file:

So all is now good in our project. We can secure either controllers or actions with annotations, enabling us to declaratively setup security side-by-side with the code that we’re securing in a very straightforward manner. You can continue developing your Grails applications with glee, fully assured that security is no longer an issue. But wait, one day you decide to install one of the many useful Grails plugins that add controller artifacts to your application. Lo and behold, you have no way to secure those controllers! Of course, you could descend into $USER_HOME/.grails/$GRAILS_VERSION/projects/projectName/plugins/pluginX and hack the source code for your individual instance of the plugin. This ought to work, but you’re now rather constrained in that every time you update the plugin you’ll need to remember to go make this manual change. That doesn’t sound very agile at all, does it? OK, so how about forking the plugin? This is a little bit better, but now you have the burden of merging changes from the global plugin repository to yours every time a new release happens. This is better, but still a bit cumbersome. How about becoming a committer and adding it to the global source? Of course not. Not everyone will want to secure their plugins the same way you do, and you’ve just introduced a rather unnecessary dependency on the Spring Security plugin. I say all this in an attempt to paint a grim picture. In reality, we’re actually in very good shape. Grails Filters to the rescue!

All that you need to do is create a Grails filter that will match requests to the plugin artifact in question and then delegate to Spring Security for authorization. If they are authorized, you simply return true. If not, you can direct them to your login screen. It’s this simple:

As you can see here, I’ve secured both the Blurb plugin and the Settings plugin in this manner by requiring that the logged in user be in the ROLE_ADMIN role. Now as Glen Smith would say, that’s a snack!

Update: Burt Beckwith enlightened me to an approach that will get this done without the use of filters that will also direct you to the requested URL after login rather than the main page. Unfortunately I’ve never been able to track this down before. Just add the following to SecurityConfig.groovy:

4 Nov

Pomodoro: The First Iteration

Posted by mattstine in agile, goals, office, Pomodoro, work.

I spent about an hour last night reading through Francesco Cirillo’s e-book The Pomodoro Technique. Up until this point I knew the basics of the technique, but I really wanted to drill down and get the details. I won’t explain those here – visit http://www.pomodorotechnique.com/ to get the lowdown. What I want to talk about is my experience applying the technique this morning.

I managed to complete two Pomodoros. Each of the Pomodoros was filled with internal interruptions of various kinds. One of the first things that I observed was something that I already knew from yesterday’s TADD post: I am definitely not used to focusing on one distinct task for any prolonged length of time. My mind was constantly bouncing around from idea to idea, almost as if my R-mode had a “memory leak.” My first Pomodoro was primarily a reading task – I used it for my daily Bible reading and meditation. This part of my day brings it’s focus challenges anyway, as I’m not doing anything tactile. I find its much easier to focus when I’m typing or writing something. The Pomodoro offered no relief from this, save a plan for dealing with the interruptions as they came up. First, note down that one happened with an apostrophe, and second, write the todo item or idea down on my inventory. This definitely helped to refocus my mind on the work at hand, but I still wish I could find a way to prevent those streamer thoughts from landing in the first place.

The second thing that I observed was that my workspace is not at all setup to encourage focus. In recent months I’ve stopped using task-focused desktops in OS X, something that Neil Ford recommends in The Productive Programmer. I was reminded of this later in the day today reading his latest blog entry. I think it would be a good idea to use my first Pomodoro of the day to setup task-based desktops for each of the tasks on my TODO list. I could fire up all of the programs necessary and drop them on to a space. Since a lot of my work is focused on web-based applications, I think I’ll probably use Fluid (http://fluidapp.com/) to create site specific browsers for the web applications that I need for each task. Another thing that I need to do is turn off the ringer on my phones and the new message notifications on Entourage. One tool that I did already have in my arsenal is Doodim, which blacks out everything except for the currently focused window on OS X. The only problem with Doodim (http://www.lachoseinteractive.net/en/products/doodim/) is that it doesn’t work with external screens, so only my MacBook Pro’s screen gets the benefits. I counteracted this by making sure that the window I was actively using was on the external screen and maximized, but this won’t work for some tasks during which I might have multiple small windows to interact with.

The final thing that I observed is that I still definitely live in an interruption-based work environment. My third attempt to complete a Pomodoro was repeated three times, and none of these times did I make it without having to stop and actively handle an external interruption. The difference? My office door was open. My first two Pomodoros were completed with the office door closed and my “Ssshhh…Genius at work!” sign on the door. This is going to be a tough one to handle. I don’t want to keep my office door closed all day, for more reasons than one. First, I don’t want to seem completely unapproachable. I’m a manager these days, and a huge part of my job is being available for people. For me, some interruptions will always be OK. But how can I sort those out prior to them happening? This is something I’ll be stewing on over the next couple of days. Second, my office turns into an absolute OVEN when the door is closed for too long. We have a really strange HVAC system that completely overreacts to small changes in the temperature. Unfortunately, it always seems to think I need to be slow cooked. ::SIGH::

So, there you have it. I’ve learned a lot – I observed quite a view things about my work patterns and my environment, and will be working over the next few days to make changes to both to support better focus. If you have any comments or suggestions, please feel free to comment. Thanks!

« Older Entries
Newer Entries »
Follow

Get every new post delivered to your Inbox.