Posted by brandon in Development on
Jul 16 with 1 comment
A rundown on some good Java synchronization links I’ve run across recently:
Vector vs. Collections.synchronizedList Discusses using a Vector versus wrapping a List (usually ArrayList, but other Lists as well) with Collections.synchronizedList. The rule of thumb that’s bandied about is to use Vector when you need a synchronized list and a plain List (ArrayList) otherwise. But this bothers me because then what’s Collections.synchronizedList for? Well, this article argues that Vector should be deprecated and you should always use Collections.synchronizedList which I wholly agree with.
Synchronization discussion on JavaPosse Explains ConcurrentModificationException in context of HashMap and HashTable (look for Reiner’s comments). This exception is widely misunderstood and many people misunderstand it as in this discussion. Again, it is stated to use Collections.synchronizedMap over HashTable and that HashTable (as Vector) should be deprecated.
Do Java6 Threading Optimizations Actually Work, and Part 2 Excellent overview of Java6 threading optimizations and if they actually work with measurements. Any article that discusses performance without hard numbers should be tossed straight away.
Posted by doug in Product on
Jul 15 with 1 comment
First of all, what is a micro business?
Great question, one that I get asked more often than expected. I mean, it seems fairly apparent - businesses that are run by moonlight, early stage mom and pop stores, and the like. Everyone from the part time Etsy seller, to the eBay superstar, to the 30 employee yoga studio in a downtown metropolis.
Now, I’ve done a bit of marketing and sales in everything from micro, small, to enterprise big box, and everyone’s interested in the same things:
- Acquisition
- Retention
- Upsell
The BRS feature set seeks to distill these three activities down for micro and small business owners, wrap it up in a nifty-and-easy-to-use product, and deliver it in a software-as-a-service package.
Posted by doug in Announcement on
Jul 11 with no comments
I’m sure many of you have noticed the look and feel upgrades around here. There’s a few items to go, but in the grand scheme of things - the cake has been frosted. Time to go in and add the piping, roses, and those little chocolate dots. This is where the metaphor ends, because there’s no cake metaphor for continuous update and maintenance … or is there? Let me know.
Blog-enabling has been fun, but I’m looking forward to actually writing more relevant content. One-post-a-day! I can do it! GO ME!
Posted by brandon in Development on
Jun 27 with 2 comments
A Java library that I’d like to see that I can’t seem to find is an exception library. Now, your first reaction might be something like, that’s silly because an exception doesn’t make sense outside of the context it’s used in. But, what got me thinking about this assumption was the general thoughtlessness and messiness you see in exception hierarchies of applications. I think this is generally because exceptions have minimal dependencies. This makes them easy to add and individually low impact so programmers add them willy-nilly with little thought. But like grains of sand in an engine, they can add up and becomes become a major irritant. My first clue that this is not the way it has to be is from the Spring framework’s database exception hierarchy. Spring’s exceptions actually get a lot of treatment and it’s obvious that they actually thought this one out! Also, in Joshual Bloch’s Effective Java Item 42 states “Favor use of standard exceptions”. So putting these together, you get: exceptions should be actually designed (rather than added ad-hoc) and they should be general.
This of course leads to the idea of using an exception library. The JDK has a few general exceptions that are quite useful but they do not cover that many cases. Spring has a good general database hierarchy but not any for other areas. Unfortunately, in my search, the exception library aisle (going back to shopping) is empty. Maybe I’m not looking hard enough?
Posted by brandon in Development on
Jun 22 with no comments
With all the open source projects out there, it can be difficult to evaluate all the libraries for any given task, especially for smaller areas where there is no established patterns. This process feels a lot like shopping: first, make a list of available products, and then evaluate each one. The evaluation process can be excruciating depending on your personality. So I’ve been trying to take the advice of my 7-year old who tells me, “why do you always do you always think about things so much, just choose”. The last time I had to shop for a library was in evaluating Java JSON libraries last week. Each of the 17 libraries on the JSON.org site seemed just as good as the other. So I quickly flipped through each one and two stood out to me: JSON Simple and Jackson. If you look at the two links, I think you’ll get an idea of what appeals to me: simplicity and an academic approach. In the end, I chose Jackson because the guy who wrote it (Tatu Saloranta) seems like one of those clever C guys with the emphasis on efficiency and the old school interface. In an uncertain environment, I’ll take one of these guys over the new-fangled interface with 5 external jar dependencies any day.
Posted by brandon in Development on
Jun 16 with no comments
I think that one statement demonstrates what’s good and bad about Java (the language):
int x = ...
if (x) ...
Of course this doesn’t compile in Java because the variable x does not evaluate to a boolean.
Supporters will state something like, duh — only booleans can be used as conditions; this is
consistent and explicit, and this type of implicit casting leads to errors.
My thought is: yeah, you guys are right; managers love this and it’s easier to teach students; but … sigh … nevermind.
Posted by brandon in Development on
Jun 13 with no comments
Peter Kriens, the OSGi Director of Technology, gives JSR 277 a smackdown in this InfoQ Video (at about 14:30) and in this blog post. The relationship does seem to be getting patched up though. The impression that Peter gives is that the JSR 277 does not have enough real world experience and are ignoring advice from people like him with years of actual implementation experience. But it looks like that OSGi is gaining so much momentum that it cannot be ignored and the spec will change to accomodate it or it will be DOA.
Posted by brandon in Development on
Jun 10 with no comments
We’re building the site out so posts for now will tend towards the technical side.
So we noticed that the form pages were loading slow. In our internal builds we have timing info for each freemarker page being loaded, including any Struts2 tag template page since we built our own theme. Oops, look at that, a form with about 15 simple fields is taking almost 4 seconds to load. Hmm, scratch to the head. Well, let’s try the simple thing first and inline a few of these Struts2 template tags. Surprise, much snappier. Inline all the form UI tags and now we get sub-second loads. If you’ve looked at the Struts2 templates you’ll see that they have a lot of logic and do a lot of including of other pages. But I’m not really sure why the performance is sooo slow; there is a clear conclusion though: unacceptable.
That splash is the sound as we throw away our tag theme and rid ourselves of the Struts2 UI tag architecture. One thing that made this easy was that after playing around with it, the Struts2 UI form taglibs are just kinda goofy; especially with so much non-customizable markup in the templates themselves. This makes using the XHTML theme useless. Also, what’s up with that Ajax theme, what a mess. I’m sure to have more comments about Struts2 in the future, but please don’t let this dissuade you from using or trying Struts2; it’s a great framework and the whole interceptor abstraction is a thing of beauty.
Posted by doug in Product on
May 29 with no comments
The original product description for Big Red Switch reads:
“CRM for micro and small business”
So, what does that actually mean? Customer Relationship Management
Getting and keeping customers for micro (one person, part time, moonlighters) and small (up to 500 employees) business (that’s you!).
