Your question is lacking quite a bit of context. You haven't for example mentioned how much experience you have with the language, how much programming experience you have in general and other useful things such as what you are using Java for.
Now for recommendations there are a lot of directions that you can go:
* for one the language has a lot of features that all the fancy frameworks use, you should know these so you don't end up using some blown up solution when all you needed was a simple servlet. This would include things like: collections, generics, annotations, enums, concurrency, IO & NIO, JAXP, sockets, servlets, JSP.
This part is pretty heavily covered in Bruce Eckel's "Thinking in Java". Not the easiest read, but definitely a very complete language reference. Servlets & JSP are pretty well covered in "Head First Servlets & JSP".
* another point to consider are general practices that transcend language such as coding practices, design patterns and testing.
You already mentioned "Effective Java", which would be the first one I would recommend in this category.
A very good book about coding practices based in the Java world would be "Clean Code" by Robert Martin. "Head First Design patterns" are very easy to digest, while the "Design pattern" book by the GoF is heavier reading. For testing I would definitely recommend you have a look at "Growing object oriented software guided by tests".
* depending on your field of work you might or might not be interested in Java memory stuff. This includes things like how and where objects are kept in memory, gc algorithms etc.
* finally, and in my opinion the lowest return of investment you could get, is by going for some framework. Not that this is bad, but generally frameworks tend to have shorter lifespans than the language itself and they usually change between projects so all your new Spring chops might not help you on your following project that uses EJB.
I'm not going to recommend anything here, since this is a very fuzzy topic and it depends on the problems you are tackling.
I guess our experiences might vary with what happens to prototypes/first cut implementations.
From my experience what starts off as a simple proof of concept/prototype that is done quick and dirty to validate an idea, ends up being the actual production code. This is due in part to clients that come and say: "well it works, why rewrite it? you can just fix bugs if they come up", making you have to maintain what was originally meant to be a throw away implementation.
While right now your intentions might be to rewrite, I do believe that you might reconsider this decision once you have a couple hundred users to please, who all want new features or bugs fixed. Now I do not know what your idea is and how critical time to market is for you but I would recommend that you consider removing non-essential features to get it out quicker rather than skipping quality.
I will have to disagree on this, this advice is only good if your sole purpose is to make a quick buck. If you want to start a long term solid business than I suggest you treat people like humans and not like cheap interchangeable pieces as this post suggests.
Think of it this way, since you are not the one developing the application how much will you know about all its inner workings? When you will have customers and a critical bug in production who will solve it?
If you intend to outsource it I will suggest that you do not look for a cheap quick hack, but rather look for a freelancer with a decent rate, with whom you can build a working professional relationship. You want someone that will stick around for the long run and take responsibility for the software he develops, since building it is just the first step.
I have to agree here, transparency is key, trust is a very important part of human relations. You build this by starting with a couple of tasks where you pay the subcontractors hourly rate, to feel each other out, but you need to make sure you are clear about what you want after that: project based work, help on various tasks with an hourly pay model etc.
Since good subcontractors are hard to find you should not treat them as interchangeable pieces and try to get the lowest rate possible. Being transparent will go a long way towards building a professional relationship that will allow you to collaborate long term on multiple projects.
On this note, I would be interested in hearing what you are looking for as I would enjoy doing some subcontracting considering I do not really enjoy the whole client dance. You can find my e-mail in my profile.
Very interesting read. I have to admit that I have been guilty of this self handicaping on more than one occasion. The self illusion of being able to achieve great things if you just put in the time is very difficult to overcome. To me I believe that the difficulty comes from a mix of complacence & fear of discomfort.
One thing that still bugs me to this day, is why this types of issues seem to be more prevalent in the software industry than anywhere else. Has anyone have an idea as to why this is?
As some of the people in this thread have already suggested, the idea of taking a gap year is all about having a plan/purpose. Taking a year off just for the sake of it, is not worth it.
From the way your question is phrased it feels like you want to take a gap year, but don't have a reason yourself. If this is the case the answer is simply put: don't do it.
On the other hand if you have some ideas and want to validate them and see if they are worth it, post them and we can give you feedback on them. This way the discussion would be a lot more constructive.
as someone who shied away from regular IDEs to use Emacs for programming work, I would recommend that you start setting things up for some very specific need.
As it was already pointed out, Emacs is huge and you will never stop learning it. Therefore, if your main line of work implies writing Java code, I would recommend you look for some tutorials that are particularly aimed at that, and build on those as you need more out of your editor. For example right now I am looking at learning org-mode to be able to do time tracking with it.
If you seriously consider using Emacs all the time I would recommend remapping the Ctrl key to Caps Lock for easier typing.
Since you were asking for some tutorials, these are the two tutorials that I found most useful in defining my Emacs setup:
I am no where near a proficient Emacs user, but maybe I can provide some insight as a fellow learner if you get stuck. I believe my e-mail should be in my profile if you have any problem starting up with Emacs.
I have no intention of stopping. I guess my curiosity was more along the lines of whether it is worth it to dig deeper and learn more Java, or if it would be better to go for some other languages.
I'm also pondering about switching jobs for this, since the best way to learn in my opinion is to force yourself into real projects with new technologies and not just hack on some small projects for a couple of hours each week.
In all honesty I can understand where you're coming from. However, there is a discrepancy as far as I'm concerned between what you're selling and how you're selling it. In this case you are trying to sell quicker updates, better stability and performance to mostly enterprise customers, with a "we all like to geek around on linux" attitude. If you were trying to sell me on using Oracle Linux for my own development PC the tone would have been quite fine, but for your target audience it seems slightly out of place.
Furthermore, if you are indeed correct and Oracle Linux is something useful that a lot of people will benefit from I seriously doubt that zealotry will stand in the way of its adoption. I guess we will have to wait and see.
This is the exact same feeling that I'm getting from this announcement. To me this just feels like a publicity stunt, where Oracle is aiming to get a slice of the CentOS/RHEL market with very little investment.
As far as I'm concerned this isn't even a valid attempt on their behalf to earn the trust of the Open Source Community. Taking something that already works and touting your own horn about how you can provide faster updates isn't really something that a big corporate player that wants to get into the open source market should be doing. I'm sure there are plenty of technologies at Oracle, that if open-sourced would have a much bigger impact, and would put them in a better relationship with the open source community.
Finally, when you are an enterprise/corporate player, and your press release for a new product is littered with "this is not a gimmick" there is definitely something wrong. In all honesty this just sounds like one of these "come with me kid I'll give you some candy! It's gonna be ok don't worry, just a little further". This is not something I would expect from such a big company.
Hmm, a good geocoder sounds a bit ambigous to me. As far as I can tell geonames has an API with both XML and JSON for getting longitude and latitude off of city names, so I am not sure what exactly you believe can be improved by crossing data from OpenStreeMaps. Could you maybe clarify exactly what you had in mind?
When you say front end to MongoDB, what exactly are you thinking of? This makes me think of something along the lines of phpMyAdmin, are we on the same page here?
This actually sounds pretty interesting and I would really like to fiddle with this idea. The thing is right now it actually feels like biting off a bit more than we can chew. I might just come back to this idea somewhere in the future, since I find it really intriguing.
While I do agree with what you said as a general statement, I have found quite a few sticking points in applying this to web applications.
Firstly, I for one have seen very little interest in the open source-ing of web application code. I might be wrong, but as far as I know there are only a few bigger websites that put out their code (such as reddit if I'm not mistaking).
Secondly, to fix a problem with the skills we are trying to use(web development mostly) you need to host it, launch it and then maintain and manage the site. While getting what we build up and running would not be too big a problem, neither of us would have the time to invest in maintaining and managing the site. Therefore, we thought that it would be more beneficial to help someone with their backlog.
So, to sum it up, we thought of this more along the lines of: "hey, you know that thing that you have been thinking of building, but have been putting it off for months? pitch it to us and we'll make it for you".
Now for recommendations there are a lot of directions that you can go:
* for one the language has a lot of features that all the fancy frameworks use, you should know these so you don't end up using some blown up solution when all you needed was a simple servlet. This would include things like: collections, generics, annotations, enums, concurrency, IO & NIO, JAXP, sockets, servlets, JSP.
This part is pretty heavily covered in Bruce Eckel's "Thinking in Java". Not the easiest read, but definitely a very complete language reference. Servlets & JSP are pretty well covered in "Head First Servlets & JSP".
* another point to consider are general practices that transcend language such as coding practices, design patterns and testing.
You already mentioned "Effective Java", which would be the first one I would recommend in this category.
A very good book about coding practices based in the Java world would be "Clean Code" by Robert Martin. "Head First Design patterns" are very easy to digest, while the "Design pattern" book by the GoF is heavier reading. For testing I would definitely recommend you have a look at "Growing object oriented software guided by tests".
* depending on your field of work you might or might not be interested in Java memory stuff. This includes things like how and where objects are kept in memory, gc algorithms etc.
Have a look at this presentation from JVM tuning at Twitter and see if this is your thing: http://www.infoq.com/presentations/JVM-Performance-Tuning-tw...
* finally, and in my opinion the lowest return of investment you could get, is by going for some framework. Not that this is bad, but generally frameworks tend to have shorter lifespans than the language itself and they usually change between projects so all your new Spring chops might not help you on your following project that uses EJB.
I'm not going to recommend anything here, since this is a very fuzzy topic and it depends on the problems you are tackling.
Let me know if you need other ideas.