Sunday, February 21, 2010
In Jackson, especially the further you get away from Freehold, the exponentially more likely it is that it will be impossible to hear your interlocutor.
By the time you get to your driveway, all hope of cellular communication has been lost forever. We actually joke here that Jackson is some sort of electronic black hole. :-)
There's actually a cell tower up right across from my main road, but apparently it was never turned on. Something having to do with land rights and legal wrangles that have apparently been going on for years, with no end in sight.
Bottom line, if you want a greater than 10% chance of actually having a conversation on your cell phone, get one from AT&T, or contact the Mayor of Jackson Township.
Tuesday, March 10, 2009
I was in a PNC bank branch on a Thursday and the representative there told me about Virtual Wallet. It provides handy tools online like a calendar and a balance forecast, and if you take advantage of their very powerful and easy-to-use (in my opinion) Online Bill Pay, the calendar becomes that much more useful. But the best part I heard is a 2.6% interest rate for their "Growth" savings account. Not many banks will match that interest rate these days.
So I signed up for the service. As a side note, it wasn't done right, unfortunately. The two new extra accounts (one a reserve checking account with a small interest rate, the other the growth savings account) were created, but it was never set as a Virtual Wallet, so the interest rate on the savings was still .12%, and the online experience didn't change. I called into PNC customer service on Friday. They enabled the appropriate flags, apologized for the branch representative's mistakes, and by Monday, I was good to go.
Well, not really. I've been using Microsoft Money to track my finances since 1996. When I tried to sync with PNC Bank, Money said there was a technical issue with the bank, so I called PNC back. PNC customer service explained that their combined free checking + reserve checking is really treated as one account, so no financial software, not Money, not Quicken, etc., would be able to understand that. But they didn't treat it as a mistake they would correct, but an intended "feature" as, you see, with PNC Virtual Wallet, you would never need to use any other financial software.
Oh, really? I played with the Virtual Wallet interface a bit. You can set up paydays, and give them meaningful names, but you don't see the names for them on your calendar unless you hover over them. And you can't even set a dollar amount for any payday--just a name, start date, and frequency. I also didn't see any budgeting tools, or a means by which to import your Money or Quicken account's data into the tool. You can't export data either in a usable format. So if you wanted to continue to use Money or Quicken on the side and manually import your PNC statements in QIF or OFX, forget it.
Then I thought, maybe I'm too old-school. Maybe it's time to give one of those online financial services a try. I signed up for Mint.com just to give it a whirl. It supported the download and import of data from all other financial institutions with which I have an account, but PNC was a no-go.
Deciding that I'm not going to live with inferior financial software just so I can have a 2.6% interest rate, I called PNC back. I have since discontinued the Virtual Wallet service, and now everybody's happy: Money, Mint.com and me. :-)
Monday, March 02, 2009
I thought that one of the points of offering online services, besides just the general convenience and cost-savings factors, is that you could continue to provide services to your constituents even in the event of severely inclement weather.
Imagine for a moment if a major bank or online retailer posted the above message on its Web site. I think Massachusetts can do better than this.
Wednesday, June 25, 2008
- FireGestures - Allows you to use mouse gestures to control aspects of Firefox, like navigating back and forth through pages, etc.
- Digg Firefox Extension - Provides insight into how many "diggs" the current page has received on Digg.com, enables you to submit the page to Digg.com, and shows you mini-views of the most "dugg" stories at the moment.
- IE View - An oldie but goodie, allows you to immediately open the current page in Internet Explorer, for when people have unfortunately written their pages in a way that they do not render correctly in Firefox (happens with a lot of Intranet pages written with Front Page, for example).
- Interclue - Is this plug-in absolutely necessary? No. It is cool and fun to see previews and statistics of pages before you even go there? You bet. :-)
- ScribeFire - A blog editor that integrates with most blogging sites and allows you to post directly to your blog from your browser, in some cases with better rich text editing and image and video sharing than you will get from the RTE that is provided online by your blogging platform. (Note: if someone can point me to a free, more full-featured [multi-indent lists, table support, etc.], whether it's a browser plug-in or not, I'm open to suggestions)
- Shareaholic - A tool that allows you to share a page or link using almost any of the available social bookmarking tools out there (delicious, digg, facebook, stumbleupon, twitter, etc.).
- Tab Catalog - Renders the contents of all open tags as navigable thumbnails.
- Web Developer - Still one of the most useful add-ons out there for Web developers. It provides insight into styles applied (and real-time editing of them), images embedded, cookies downloaded, and more features than I could possibly do justice for Web site and application developers.
Are there alternatives to the above that you think do a better job?
Are there add-ons that you use on a day-to-day basis that you think are also worth consideration?
A great list of add-ons for Web developers and Internet socialites can be found here.
My favorite add-ons from this bunch so far are the FireShot (for immediately creating, annotating and saving as JPGs screenshots within Firefox) and PicLens (for visualizing as 3D walls images from Google Images, Amazon, and News Media outlets).
Tuesday, June 24, 2008
The upgrade went pretty smoothly. There were just a few plug-ins that I use that are not compatible with Firefox 3:
- deskCut - allows you to create a desktop shortcut for the current page; if there's an alternative out there for Firefox 3, just let me know.
- All-in-One Gestures - allows you to use mouse gestures to easily navigate backward, forward, or through a list of your backward or forward history; an alternative, FireGestures, is available for Firefox 3, and seems to be just as capable.
To get Firefox to successfully open up Adobe PDF files, I had to:
- Shut down Firefox.
- Uninstall Adobe Reader 8.1.2.
- Reinstall Adobe Reader 8.1.2.
- Restart Firefox.
Happy browsing! :-)
Friday, May 16, 2008
- Driving JSF in the context of the Spring MVC lifecycle
- All of the standard JSF components and component libraries work unchanged
- Bread and butter of JSF is its component model
- Lifecycle for rendering and updating component tree
- Could have different vendors integrating with the standard
- The faces servlet, the front controller code, etc., was not found by SpringSource to be particularly useful
- When you run a Spring Faces application, you're actually using the Spring Dispatcher Servlet.
- Spring MVC and Web Flow manage all controller responsibilities (request mappings, navigation rules, etc.)
- JSF handles view rendering responsibilities as a View implementation
- The focus of JSF going forward should be on enhancing its UI component model; specifically improving component interoperability, and ease of authoring new components
- The difference between Spring-centric and JSF-centric approach in SpringFaces is not in the JSF component model.
- JSF faces servlet drives everything, including mapping to views, etc.
- A view-driven approach.
- State is typically stored in HTTP session.
- When user initiates an event, the postback lifecycle is invoked.
- Ultimately that view decides whether to re-render or whether to delegate to a navigation handler to render a new view via faces-config.xml.
- Only Spring integration is that JSF views will be bound to Spring-managed beans for business logic.
- You are limited to standard JSF navigation system
- Can't go to views based on events
- Difficult to modularize faces-config.xml if the modules are independent (but can have faces config fragments; extremely verbose)
- State management not flexible (HTTP session only for every user)
- You are limited to standard JSF navigation system
- Web Flow becomes the navigation model by plugging into that JSF extension point.
- Architecture becomes controller-driven instead of view-driven
- All requests are routed through controllers, which make decisions about which views are rendered.
- What action-oriented developers are used to.
- Bringing model and view together, but handling what needs to be done in the controller.
- With Spring MVC, get full advantage of dispatcher servlet which allows you to customize how views are rendered via URLs
- When controllers are invoked they can use input parameters to execute initialization logic to select the right view, etc.
- With JSF out of the box, difficult to do initialization before view is rendered, and difficult to clean up after a view is rendered.
- With Spring Faces, if there's a problem with handling a given request, instead of it being caught in the render cycle (which is difficult to recover from if you've already written out some of the response), you can catch an error before you render the view at all.
- Either way (JSF-centric or Spring-centric) you need control logic.
- In JSF, it's managed beans, so typically people have to go out anyway and get something like Shale to allow for initialization prior to rendering, etc.
- For people building components, nothing different between a JSF-centric approach and a Spring-centric approach.
- People that have to do the event handling have to know Spring MVC and Spring Web Flow. SWF could be theoretically incorporated into the JSF spec over time to handle events, drive transitions, etc.
- There is so much synergy between the two, it is not out of the realm of possibility that MVC and Web Flow could be combined in some future distribution of Spring focusing on web applications.
- There's a need for both technologies.
- Spring MVC will continue to exist, but the two products may merge at some point for developers to consume.
- More powerful navigational system
- Finer grained scopes (flow scope, view scope)
- Reduce amount of state that's stored traditionally with JSF
- Works with a multi-window application
- Modularization of Web application
- Built-in Ajax event model for rendering partial page fragments after responding to Ajax events
- Spring MVC focuses on stateless, RESTful interactions
- JSF is stateful by nature, as is Web Flow by nature, so that you can execute all phases of the lifecycle within Web Flow
- With Spring MVC, only render phase can be executed. You cannot execute the postback lifecycle.
- Might be able to address this in Spring MVC with custom form controllers, etc., but Web Flow provides this already with more power (flows can be changed without server having to be restarted)
- You may see demand from clients to do more of the lifecycle within form controllers, but this hasn't emerged yet.
- The SpringSource Enterprise Bundle Repository, for example, uses Spring JS and Dojo 1.1 components outside of Spring JS, so they definitely work together (e.g. popup, query API, etc.)
- Would probably have to have another release of Spring JS when another major release of Dojo comes out.
Thursday, May 15, 2008
My business unit is trying to standardize if we can on a single Java-based Web framework going forward to simplify the Web development process, especially as individual developers move from one division to another, or centralized support groups need to maintain multiple applications from multiple divisions.
At the enterprise level within my company, the architecture group says that they will provide support for either Spring MVC or JSF+ (where the + represents the accompanying technologies you would use to provide a more maintainable application and a more rich user experience, e.g. Facelets, Richfaces, etc.).
Now my business unit is trying to decide which of these two frameworks, Spring MVC or JSF+, is the most appropriate to standardize upon for our development community.
What follows are some considerations based on discussions we've had internally thus far.
Please provide any feedback you might have based on your experience with either of the two frameworks. Are any of the perceptions or claims below inaccurate? Are there key considerations that we are not even thinking of that can help us to come to a reasonable recommendation? Any feedback you have is welcome.
- In general, our business unit divisions who have developers coming from a component-oriented programming model background seem to prefer having their developers remain with this programming model when migrating to Java Web app development.
- It provides a more familiar programming environment
- It would hopefully make developers more productive as they would have less of a learning curve
- For those Web application developers that are already coming from a Struts background, obviously their learning curve would be much less steep if they were able to continue to use a page-based, action-oriented Web framework like Spring MVC.
- Knowledge of / Experience with Frameworks
- Within our company, there appears to be a greater amount of experience with Spring MVC than with JSF currently.
- Within the industry, it seems that there is a greater amount of experience with JSF if you are to look at developers' resumes, the greater amount of books and other documentation available, etc.
- A "Comprehensive Spring Training" course that includes about a 2.5 hour session on Spring MVC authored by SpringSource and tailored to our company's needs by another business unit is already available through our training center.
- An additional "Spring Rich Web" course is also already being jointly planned.
- No training modules are yet available internally for JSF, but obviously many are externally.
- Migration of Developers' Skill Sets
- If we were to choose Spring MVC, component-oriented developers would have to learn a new programming model.
- If we were to choose JSF, action-oriented developers would have to learn a new programming model.
- Either way, training and re-tooling would have to take place.
- Anecdotally, it is probably true that we have more component-oriented developers than action-oriented ones.
- Vendor Lock-in
- With Spring MVC, you can write controllers in such a way that they are effectively annotated POJOs, but even the annotations introduce a Spring dependency.
- In all likelihood, we would want to extend some of the controllers that Spring provides based on the use cases for a particular page flow.
- Thus, most likely, selecting Spring MVC means that applications built using it depend upon it, and they can't easily be ported to another Web framework.
- With JSF, you're really just dealing with a specification, so although the JSF RI provided by Sun is the currently recommended RI, there is nothing that ties you to it specifically.
- Maturity / Market Penetration
- The first RI of JSF and the first version of Spring MVC both seem to have emerged around the same time in 2004.
- From a vendor and tools perspective, there has been much more traction around JSF, especially in terms of providing a "drag and drop" user experience for component developers.
- That said, SpringSource itself is now a vendor that offers support for its entire Spring portfolio (including Spring MVC), and the Spring IDE does a decent job at getting users going on building and visualizing Spring-based applications.
- If we're using a combination of technologies for developing JSF applications like Facelets and JBoss Richfaces, would there be an Eclipse plug-in / extension or (if we could justify the cost and complexity) yet another IDE that could simplify and automate the usage of those technologies together?
- If the push from the industry seems to be towards migrating complex UI interactions to the client via Ajax and Flex, what value would JSF+ add on top of this?
- For example, if we were to standardize on Spring MVC for the Web framework, Dojo for the Ajax toolkit, and (when appropriate) Adobe Flex for very rich components that it simply does not make sense to do in Ajax, how would JSF+ improve this picture?
- In addition, if we try to follow our company's enterprise standard of using Dojo for Ajax, and a component library like Richfaces is leveraged, what if Richfaces didn't use Dojo under the covers or it used a different version of Dojo? Would it interoperate properly with any Dojo-enhanced elements of the page that perhaps did not come from a JSF component?
Some Potential Options
- A member of our working team proposed that we recommend the use of Spring MVC as our Web application framework, given its relative familiarity to existing action-oriented developers, its simplicity, modularity, and the overall trend towards doing components more using client-side versus server-side technology.
- There was some definite resistance to this idea, at least until we have some greater insight into where these two frameworks stand in the industry today and what their roadmaps are for future enhancements.
- The possibility of supporting both frameworks was also discussed, but we are trying to narrow down the use of technologies to one wherever possible from an IT simplification perspective if that is plausible.
- It was also mentioned that Spring MVC supports using JSF as its view technology (just as it supports JSP and Velocity), but it is unclear whether that hybrid approach would really provide any benefit to component-oriented developers who would still have to learn the Spring MVC request life cycle.
- Obtain greater insight into and share with the working team:
- The market penetration of each framework
- Perceptions of these frameworks by major technology advisory firms like Gartner, Forrester and Burton
- The future short-term and long-term plans for each framework
- For example, JSF 2.0 and Spring MVC 3.0
- The potential consequences (whether negative or positive) of eliminating one framework or the other from our development environment.