@richmondjug Apache Hive "deep dive" Rm 103 UR, Jepson Hall
Next: May 15, 2013 @ 5:30 PM
Where: University of Richmond, Jepson Hall
Presenter: Jyot Singh and Rising Tides Solutions
Topic: Hadoop & Big Data
Our 2012 Calendar:
DATE SPEAKER TOPIC SPONSOR
====== ================= ========================= ======================
Jan 18 RJUG Members Lightning Talksd TEKSystems
Feb 15 Jimmy Ray Groovy Dynamic Edges ICF Ironworks
Mar 21 Tim Stone Stripes Framework ICF Ironworks
Apr 18 Mike Cantelon Node.js Apex Systems
May 16 Ken Rimple Spring Roo Astyra.com
Jun 20 Stuart Sierra Intro to Clojure Technisource
Jul 18 Bob McWhirter JBoss Torquebox TBD
Aug 15 RJUG Members What to do with RJUG? none
Sep 19 David Chandler Android Apex Systems
Oct 17 Scott Leberknight ZooKeeper Apex Systems
Nov 21 SyncRVA/RichTech TedX Conference / SyncRVA RJUG
Dec 19 N/A Holiday N/A
I’ve had a few conversations lately about software tools and technologies — how to use them, how to pick them, how to know when to change, etc. These conversations can be exciting, educating, emotionally charged, productive, and sometimes not.
In a recent, very positive exchange, one colleague asked if I preferred Maven over Ant or Ant + Ivy simply because I had more experience on Maven.
Generally, I couldn’t say I preferred one technology stack over the other because I simply don’t know enough about the organization to make the call.
From a purely technical perspective though, my gut told me there is a brighter future in Maven than in Ant+Ivy. My reasons for this opinion are grounded in my experience, so I decided to research a few factors I consider important when it comes to technology tool selection.
Latest Stable Release
Couple of interesting observations from the stats above:
- While Ivy is ‘2 years newer’, it’s last stable release was roughly 2 years earlier than Maven.
- There are roughly 1500% more GitHub repositories referencing Maven than Ivy
- There are roughly 1400% more contributors for Maven than Ivy (according to ohloh.net, anyway)
Google Trends also has an interesting view contrasting these two projects: Google Trends: Apache Maven, Apache Ivy
When discussing open source software projects, I usually think “we need to consider the vibrancy of the community”. How many people and organizations are contributing? How often? What other well known projects integrate with this tool?
From my view - when it comes to technology selection, it’s often OK to “follow the crowd”.
We're now on:
- LinkedIn at http://tinyurl.com/rvajug
- Facebook at http://www.facebook.com/home.php?sk=group_145394238851870
- Twitter at @richmondjug
Please join the LinkedIn and FaceBook groups and follow us on Twitter.
Thank you Romain Lheritier for getting us to FB and LIN!
If you ...
- Would like to present to the JUG
- Know of someone who you’d like to see present at the JUG
- Meet someone who has an interesting topic
- Are interested in a particular topic
Please send us your ideas or direct potential speakers our way.
Chris Allport can be reached at email@example.com
It always bothered me that the JSR168 <portlet:actionURL /> and <portlet:renderURL /> tags didn’t encode their HTML character entities. The lack of encoding causes your HTML 4 or XHTML 1 markup to fail automated validation. After flipping through a bit more of the JSR286 spec, it mentions that in JSR168 “the behavior in regards to XML escaping URLs written by the tag library was undefined” 1. So, some vendors may have encoded and some may not have (as of 2.7 JBoss Portal, for example, does not).
Well, it turns out that the JSR286 expert group noticed that and accounted for it. Section 10.4.1 defines a new container runtime option: javax.portlet.escapeXml. The option causes portlet URLs to be escaped and is true by default. This is primarily for backwards compatibility so that older portlets that dependended on unencoded URLs will work on a portlet 2.0 container.
For example, you wouldn’t want to call the following:
Because the URL above would be encoded, your ‘id’ parameter wouldn’t be passed along properly.
It’s always nice to see this kind of improvement in the spec; hope this is helpful for you!
I thought I’d throw together a quick precursor to another post I plan on finishing in the next few days. This post is about portlets - or, how to structure the HTML markup for a JSR168/JSR286 portlet, to be more specific.
I’ve worked on theming portal user interfaces for a few years now, primarily on IBM WebSphere Portal and JBoss Portal. On WebSphere, you develop what’s called a ’skin’ - where the markup for a given portlet lives. JBoss has a similar but more granular concept called ‘renderers’. Being a big fan of the principle of semantic markup or POSH, I’ve come to think that all portlets should have the same general shell or HTML markup.
So, I present the perfect portlet markup:
<div class="portlet-window"> <div class="decoration"> <h2 class="title">portlet title</h2> <ul class="controls"> <li class="skip"><a href="#skip_$PORTLET_ID">skip this window</a></li> <li class="mode edit"><a href="#">edit this window</a></li> <li class="mode view"><a href="#">view this window</a></li> <li class="windowstate minimized"><a href="#">minimize this window</a></li> <li class="windowstate maximized"><a href="#">maximize this window</a></li> </ul> </div> <div class="portlet-content"> portlet content </div> </div> <a name="skip_$PORTLET_ID"></a>
You might notice this layout:
- follows the JSR168/JSR286 naming standards for window, decoration, controls, etc.
- marks the portlet title up as a level 2 heading; from my experience this is the ‘right’ choice for the portlet title as the portal page title itself should be the level 1 heading
- to promote accessibility, renders actual text content in the mode/state menu anchor links (which should be internationalized and can be replaced with appropriate icon images using your css image replacement technique of choice, of course)
- to promote accessibility, adds a skip link to the mode/state menu for skipping the content of a given portlet (this is very useful for screen readers and can be removed from the page using your css text hiding method of choice)
Note that one or more the elements in the shell may be removed. For example, sometimes portlets won’t display their portlet title, which is often the case with content-manged portlets (ideally, this would be a configuration rather than separate skin or renderer).
By the way, this post is intended to be a bit controversial; hoping to challenge my audience (if there is one =P) and maybe to come to some kind of consensus.
So what do you think? Did I get it right? What would you change or improve to this portlet markup?
Sometimes I look at old draft blog entries and ask myself “what was I thinking?”. Every once in a while, though, I look at an old draft post and say “hey, that’s pretty cool!”. This article fell into the pretty cool category, not so much for the content, but the example app, so I hope you enjoy it (OK, you can skip to the end now).
There’s a long-standing, accepted pattern for handling form submissions in web applications; it’s usually called the post redirect get pattern. The goal of the pattern is to prevent the payload of a HTTP POST request from being stored in the browser history.
Keeping the POST data out of the browser history helps prevent duplicate form submissions and also is the best way to make sense out of navigating backward/forward through the history after a post. Imagine refreshing a webpage without the PRG pattern after making a credit card purchase.
To speak in HTTP terms, the PRG pattern intends to handle the non-idempotent nature of the POST method. As defined by the HTTP specification, it’s not safe to submit the same POST data more than once, so the PRG pattern prevents the user from resubmitting POST data when refreshing their browser window or navigating through their browser history.
As I mentioned, this is a long-standing pattern and as such, there are several references available that describe it in full detail:
It is also widely implemented in most modern web application frameworks (eg: JBoss Seam, Ruby on Rails) and because it avoids problems caused by HTTP itself, it is implemented in various web-specific languages/frameworks (JavaEE, .NET, PHP, Python, Ruby, etc).
OK, so why did I think this post was worth finishing? Well, many moons ago, I built out an example application in PHP demonstrating the post redirect get pattern.
Hope you find it useful.
- 1 of 2
No upcoming events scheduled; check back soon!