Related
Based on my own experience and on experience of my friends I see that many companies have some strange ideas to develop their own frameworks and SW factories (builds skeleton of application for you). These ideas are usually based on belief that own framework will be much better than anything else available. How to deal with such ideas and how to explain that it is not always good way to go?
Why I think internal frameworks / factories are not good:
Budget & Resources - There is usually only some initial budget to create framework. Nobody thinks about budget needed to maintain and support framework. Nobody can even estimate budget and resources needed for maintaing. At the beginning nobody thinks about maintaining multiple versions of framework to support already existing applications.
Lack of experience - Framework is usually created by people without any such experience or with support of "consultants" - generally much more expensive people with similar skill set.
Architecture / design - any architectural problem in framework affects all applications build using this framework. Bad design decissions in framework force developers to code applications in the bad way.
Technical debt - bad code in framwork is technical debt.
False belief of silver bullet - managers believe that own framework / factory is silver bullet. All application will be written in the same way and it will be easily maintainable. My experience is that it is simple not truth. Even with SW factory each application is specific.
Insufficient documentation - documentation is first part affected by low budget. Framework without documentation is useless. Reflector (.NET) is my best friend.
Insufficient user group - internal framework has only small user group. Small user group means small experience. If I'm using public tool / framework and I have a problem, I can ask question on SO (or similar web) or just try to find answer on google. With internal framework it is not possible.
Policy - company policy force you to use the framework to vindicate framework costs. This goes so far that the framework is chosen before the first requirement is gathered.
Complains to framework are prohibited.
Usage of other frameworks is prohibited.
Why I think companies are doing this:
Arrogance & egoism - sombody in company believes that he can do it better.
Ignorance - ignoring existing frameworks / solutions and the fact that only good frameworks survived long enough to be popular. Ignoring user group and already available informations on the Internet.
Management failure and incompetence - not understanding the impact (especially long term) of this decission. Decission based on incorrect informations. Management without SW development background.
I understand that sometimes own solution or framework for specialized scenario is needed but I'm tired with all these "great internal frameworks" for creating web or desktop applications. Am I wrong? Are these frameworks really needed (.NET and Java world)? Can you provide me some example or reason why it is good to have internal framework / factory?
Edit:
Thanks for answers but I expected some advice how to deal with a problem as a developer (except changing a job) not as a manager.
In my experience the most common cause of excess frameworks is... bored developers! Uninspired developers find that developing frameworks to solve their problems is much more fun than actually solving those problems - the end result is frameworks that suffer from all of the above (because of course the developer only did the fun bits), and possibly don't even solve the actual problem (because the goal was to have fun, not to solve the problem).
The solution is tricky - its difficult to know what it is that motivates developers as everyone is motivated by different things, however motivated developers who are busy doing things that they enjoy don't see to suffer from this ailment!
That said, well thought out frameworks when properly used are definitely a good thing - However if its only going to be used internally then it might be better to instead think of it as an extension to re factoring and code re-use rather than as a framework.
A classic sign that someone is suffering from bored developer framework syndrome is when a framework is being developed to solve the general case when there isn't yet a solution for the specific case:
How can you know how to solve the general case until you have solved at least one specific case?
Until you've had to solve the general case a few times you are only guessing that a framework is even needed.
The second case of course leads to the worst sort of framework - the mammoth generic framework that is only ever used once, to solve a problem which is far simpler than the framework itself.
Instead consider these sorts of frameworks more as an exercise in "extensive refactoring" - if the framework is produced as a way of grouping and tidying common code on an as-needed basis then the framework will grow in size and complexity dynamically - having already solved the problem before you start producing frameworks is nice too as it means you are already experts in whatever it is the framework needs to do.
Finally, try to keep developers from being bored (they get up to all sorts of mischief otherwise!)
Generalization is bad, but here is what I've noticed, especially in large enterprise projects:
Such behavior is generally driven by one of few more software engineers (they usually name themselve software architect) that fall into the descriptions you wrote in your question. Everybody needs to be proud of something to have the courage to wake up in the morning. I will add that they are usually CV driven for that reason and try to apply the latest design patterns without thinking about business implications and ROI. The key is NOT to hire that kind of person (or try to coach him/her to understand business consequences of his/her choices). Trying to make them proud of working for the company instead of working on their framework may help too.
Missed deadlines, bugs, high turn-over tend to be solved by applying fancy methodologies (usually badly implemented) like scrum or hired highly priced consultants that will make things worse,... instead of removing (or coaching) the persons that shouldn't have been hired at the first place.
Removing the person in question is in most case a bad thing since he OWN the thing. So teach him/her to understand consequences of his/her choices is probably the most appropriate way to solve the problem. But to do that, you need a good manager.
So my only advice would be:
Hire better managers that understand very well both business and software development. They won't hire that kind of person or will try to teach them how to consider business in addition of pure software development. They will also understands that the most powerful motivation fuel for employees is making them proud of working for that company.
I would add some other reasons these things evolve, and I have seen this in more than one place:
- Developer lock-in. Once you have the devs coding in a non-transferable skill set, it's harder for them to leave.
- Author lock-in. Once you have several apps under maintenance dependent on the framework, you have the organisation dependent on the administrative group.
- Political control. The centralisation allows the framework to become a channel for political control.
I'm having a bit of an overload of information these past two days.
I'm planning to start my own website that will allow local businesses to list their items on sale, and then users can come in and search for "Abercrombie t-shirt" and the stores that sell them will be listed.
It's a neat little project I'm really excited for and I'm sure it'll take off, but I'm having problems from the get go.
Sure I could use ASP.Net for it, I'm a bit familiar with it and the IDE for ASP.Net pages is bar-none, but I feel this is a great chance for me to learn something new to branch out a bit and not regurgitate .NET like a robot.
I've been looking and asking around but it's all just noise and I can't make an educated decision.
Can you help me choose a framework/platform that will make me learn something that's a nice thing to know in the job market, but also nice for me to grow as a professional?
So far I've looked at:
Ruby on Rails
Kohana
CakePHP
CodeIgniter
Symfony
But they are all very esoteric to me, and I have trouble even finding out which IDE to use to that will let me use auto-complete for the proprietary keywords/methods.
Thank you for your time.
Have you considered ASP.NET MVC?
You will learn MVC architecture and client-side programming with javascript and jQuery, in a nimble platform that produces clean markup. If you are used to ASP.NET, you will be surprised at the clarity of design.
The NerdDinner tutorial is the go-to guide for getting started.
I suggest you try the whole Java eco-system.
Both similar and different to the .NET world, a lot of open-source frameworks.
Eclipse is a very good free IDE.
Also, why not go with GWT for the client side ?
In any case - enjoy !
Because nobody's mentioned it yet, I'm gonna have to suggest Rails.
I'm sure you're going to hear arguments for each framework you mentioned (and probably some you didn't), but I"ll be brief and explain why I got into Rails, having tried several of the others in your list:
It's beautiful. Coding in Ruby actually makes me happy. I find that I'm removed from a lot of tedium I've come to associate with large projects, and it's totally changed my coding career - I would literally hate to think how much less content of a programmer I'd be had I not taken the plunge. My only suggestion here would be to just try it.
Besides the succinctness of Ruby, Rails got me thinking in a more modular, logical and maintainable manner. As well as the great community, I really subscribe to the principles Rails stands for (especially the emphasis on DRY code), but all of the frameworks you mentioned have their recognized (and controversially disputed) pros and cons.
Each one is both similar and unique in varying degrees and aspects, and ultimately it's up to you to decide - Do some research; deliberate as to whether you're looking for huge libraries, a strong community, cutting-edge updates or assurances in tight documentation. Figuring out what you hope to gain from a framework is a great way of choosing the right one. But you should go for Rails anyway ;P
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've noticed many questions on here from new programmers that can be solved using libraries. When a library is suggested, often times they respond "I don't want to use X library" Is it the learning curve? or ? Just curious!
A lot of new programmers are still working at a very low level of abstraction, learning the trade. That's something everyone has to go through. It takes a while to "move up the stack" so to speak.
Once programmers realise that they spend most of the time solving the same problems as someone else already did, and the goal is to realise "business value", then they can really appreciate the value a good library brings.
When you're still learning the ins and outs of a new language, also having to learn how to use a 3rd party library can look like too much work. Also, libraries tend to be badly documented - or at least have documentation that seems totally opaque to a new(er) programmer.
So, faced with trying to solve problem X, saying "use a library" can sound a lot like "solve problem Y THEN problem x".
(Also, their professors told them not to. I managed to get all the way though my undergrad in C++ without learning the STL existed. Boy, did THAT cook my noodle.)
Some people, when confronted with a
problem, think “I know, I'll use a
library.” Now they have two
problems.
Seriously - this is a reasonable way for a newbie, already overwhelmed by new language, programming environment, paradigms, keystrokes, etc. to react to the suggestion to use a library. If you've got a solution, but it's not working, there are many potential sources of error; sorting through them is a challenge. Adding to them can seem irrational.
"Use a library" means find the library, download it, install it in your project, and call the necessary function. Not hard, if you're used to it (and there aren't corporate policies against it, and you have reason to trust the vendor, and the library itself has minimal dependencies, etc.). But if it's all new to you, when you ask a programming question and get back a system configuration answer, it can seem unhelpful (even if it is not, in fact).
Almost always it's because their professor has told them that they can't.
Sometimes it's just because they want to learn it themselves, but I'd say that's rare.
It's the learning curve.
Using libraries is probably one of the worst things a learning programmer can do. Instead of learning how to code, they're learning how to use specific APIs that other people implemented. I'm not saying that every programmer has to understand every single thing that they use, but programmers who know the ins and outs of a computer (digital logic, assembling op-codes, etc) usually have an edge over people who've started with something like Java Swing and are just throwing together libraries.
In production, this is a different matter of course. But I think the best course of education is to 'make everything' once, at least. Writing my own web application framework from the ground up really improved my programming skills and abstract abilities. Doesn't mean I'll use that framework if someone hires me to build them an application, but I know the strengths, weaknesses, and reasons behind the things that the 'giant' frameworks use, and it can help me choose a particular framework for a particular situation.
I remember shying away from several libraries simply because I wanted to see if I could create my own algorithm. I didn't want to just give up and let someone do the work for me but rather I wanted to learn from my mistakes. Once I had come up with a solution I was happy with, I looked into the libraries.
So for me it was simply wanting to see if I could do it.
I always have this urge to do it myself, but sometimes I can see my own limitations.
Just recently downloaded a library to create PDF documents, but thats pretty much the only time I can remember.
At least for me, (trying to) do things myself, is my way of learning.
My impression is that many newbie programmers wouldn't consider it their own work if they were to use someone elses libraries.
I don't think that this is necessarily a bad thing. Using libraries is great; it saves time, effort, bugs, etc. However, you learn very little in the process, and for new programmers, learning is the goal. To answer the question, I think that they tend to shy way from libraries simply because they are not used to using them and perhaps they don't know that they exist.
For many poorly documented libraries that are either implemented loosely or in languages that don't allow you to control containment and visibility very well, it can be quite difficult to guess just how the library is supposed to be used.
After you've used it for a while, you've gotten used to the quirks or read other source code that taught you the right way; but until then it can be pretty irritating to use a poorly put-together/designed library. (or even a well designed one that isn't terribly well documented).
If you don't have the source code to the library, that's another problem--you have no control over the ability to keep your program working. This is much more rare these days, but still happens in the case of a purchased library.
Most of the points covered off (for me the main one is the learning curve) but one other I think plays a part:
Because learning about a library is less exciting than coding the same functionality yourself.
More libraries = less billable hours.
I think there's a lot of time that needs to be invested in understanding the library's purpose - yes, a learning curve, but it's more that newbie programmers probably don't know what they need until they have a lot more experience.
Because it's fun.
Because part of maturing as a developer is learning to quickly identify problems which can be solved by a library or existing solution and which need personal attention.
When you're trying to learn how to do things, anytime something is accomplished "magically" by calling AwesomeClass.doAwesomeStuff(), you end up giving away a portion of control. When you are "new" and don't know what you're giving away or why it can be unsettling. This was my primary knock against Rails when I was first learning it. So many things just "worked" and I didn't know why without digging through lots of Rails source (which I generally didn't have time to do).
At least, that's my take on it.
The same reason that more experienced developers do -
Because it can often be as difficult to learn how to use a library as to write the part of it you need yourself. And at least then you can understand how it works when it doesn't do what you expect.
An experienced developer just has experience at understanding how to use libraries so more likely to consider it. An inexperienced developer it's one more thing to learn...
I'm a programmer, not a psychologist! :)
It was a long, long time ago for me, but it was because I wanted to learn and experience. I didn't want to use something I did not understand, so if I didn't think I understood the library and could program it myself, I tried not to use it. There might have been a bit of fear too; programming gives you a feeling of control, and using a library is like giving away this control.
Answer from a noob -
"I am not sure how to use the libraries or even how to access them or how it works"
Libraries often come with the overhead of learning some API and it's paradigm. It can get complex fairly quickly, and I could easily understand that beginners would prefer something a bit more in their comfort zone. From my experience, I found most libraries & frameworks seem to do a great job abstracting some tedious routine, but when I need to either extend this functionality, or use it in a way that's not intended, it can be a handful.
I think it's one of those things where "practice makes perfect".
Well, the newbie's purpose might be more solving the problem than implementing a solution. Perhaps what they really want to do is figure out how to solve the problem. I mean, if they're still heavily in the learning phase, it's quite possible they don't want easy answers handed to them.
I think the professors want them to stick to the basics. When I graduated from under-grad school, I knew C++, Java and some other languages but had no clue about libraries and frameworks being used in companies. It was like do you know java..yes..can you write a servlet..no.
For speed demons they rarely use 3rd party libraries and new programmers are usually looking to squeeze every once of speed of of their code. I think if they don't have control over their code they can't get the performance that they are looking for. At least thats why i avoided libraries when I first started to program.
I remember programing my first DAL and avoided all the other free libraries out on the web because I wanted my code to perform at top speed. Later, I discovered that usually its not the code thats the bttleneck its actually the database.
Some open source libraries are buggy or not as efficient as others.
In my eyes another factor is that additional libraries add complexity. Programs tend to get harder to understand, harder to maintain and buggier when getting more complex. I think what makes especially new programmers shy away from libraries is that adding library code increases complexity more than adding your own code - simply because understanding how the library works is still out of their grasp. So it seems to be a problem of both skill and psychology.
I think more fundamental issues can be recognized as a deterrant to using existing libraries.
Part of this as "newbie programmers" is a lack of exposure to libraries. If you don't know they exist, how do you know to use them?
Number Of Options Available. Let's say I'm really interested in learning more about MVC, but if I have to choose between cakephp and smarty and zend and ... well you can quickly see the gears work to discover a way to achieve the goal without investing the time experimenting. Take a look at Freshmeat or SourceForge to get a better understanding at the daunting selection of libraries available.
Questionable support combined with sketchy/outdated documentation for the libraries. Do I want to use this tool that may no longer work or may be abandoned in the future? It is likely that a project will evolve, and so it will for the project of a library too. Will its usefulness last the lifetime of my project or will I be required to re-do this work again?
Using a library requires you to understand the relatively complex design of the library, something that new programmers might not have mastered because all they've ever written is simple/procedural/single-purpose code. For example, to an experienced programmer standard design patterns like template method, observer and command seem pretty obvious, but to a newbie it all just seems like magic and/or unnecessary complexity. For me the turning point was when I got good enough to grok design patterns and write some basic reusable code.
It's been a long time now, but when I came out of college, I knew nothing of libraries. This was in the days of mainframes and mini-computers. Our college had a VAX and the managers were paranoid about students hacking the system, so didn't allow us to even see the library manuals. So, when I first came out of college, I didn't even think of libraries being available.
I am sure there are a lot of reasons why the newbie doesn't want to use the new library. But wouldn't this be a good opportunity, if you have enough time, to show them what the advantage of using the library is? With the people I work with, I will usually provide an example of why something is better than their approach. It helps them learn and mature as a programmer.
Happens that noobs use Libs without knowing, but when they must import/add one that is fairly less documented, there is a fear of unknow. That happens mostly for compiled langs!
In the interpreted, (or compiled IRT), mainly when there is a console, such fear is almost non-existent; since you can require and see if it fails, call a method and see what it returns.
Consoles are tools of bravery !
We are building a RESTful API for our company, which will provide XML, JSON, and potentially other content types.
My team is looking to find a framework which is (In order of priority):
Well Documented
Ideally with good tutorials, and a thriving community and knowledgebase
Follows rational design patterns
Mostly we want consistency in the framework. Naming conventions that don't change based upon which method call you're calling.
Secure
Focused on forcing the developer to perform some form of validation of the GET, POST, PUT and DELETE Variables
Stable
Part of this is maturity, in the sense that the framework isn't changing too often
The other part is a well documented bug list which isn't scarily huge
Scalable/Performance Oriented
We have over 50K users who require significant high availability all around the world. IF our App goes down, people do not have internet in their home. So it's a highly critical environment.
Ideally we could launch the same codebase on 10 servers and just keep adding loadbalancers. We don't want to have to define which server is on which methods....
Integrates well with a Linux/MySQL Environment
We don't have a single MS server. We're not changing that. Sorry .Net fans :-D
I realize this a nebulous goal. There will not be any one framework that meets all of these needs, in fact there will probably be many that meet them in varying ways, shapes and forms.
This is language independent. We already have experience in PHP, but we also have developers who have never written a web application in their life, so learning Python or Ruby or Java is acceptable.
I'll go out on a limb here and suggest Ruby with Sinatra.
Why?
Sinatra isn't "well documented" but is "documented well". Considering that it is much more simple than other frameworks there needn't be quite so much documentation, and since it is built on Rack as a webserver it shares some common documentation with that. But what you need to know is on the website, and it's well written and contains no errors that I've found (IE, it's all up to date).
Most of what you need to know is in the Sinatra Book, the Readme, and the FAQ. Despite the work-in-progress nature of the book its contents are very much accurate and useful. And, if you are still stuck with questions, drop by the IRC chat room freenode.net#sinatra.
Sinatra is capable of being used in a functional/route-based logic method, or by overriding the Sinatra::Application object. You can use either, split your logic and methods into various files, or keep it all in one. It's all up to you.
Sinatra is, of itself, secure. You MUST validate all variables sent by the user, because aside from parsing them and passing them to you, Sinatra doesn't care how valid it is. Therefore, you either enforce validity of your variables or you regret it. ;-)
Sinatra hasn't changed a bunch in the last four months, but it certainly has had maintenance and minor updates. In addition, I've not found the bug list to be large or threatening. It's got virtually everything I need already to build my apps with.
Sinatra doesn't have to be deployed with Passenger, but can easily be custom tailored to be fast. If you use things like Enterprise Ruby and Thin you could proxy to either Nginix or LightHTTPd. If you took two servers you could make one the primary (with the proxy and a number of threads) and the second the database server (with MySQL and a number of threads) and let them loose. This way the tasks are spread across the servers. It'll give you more control than I think Passenger would. (Not to mention better performance.)
I find Passenger (on Dreamhost) to give relatively poor performance when compared against running threads by either Rack, Mongrel, or Thin. That said, once loaded the applications are responsive even in that environment. If I were to predict it, you'd not have a problem with scaling the application as you'd simply have to redeploy your code and restart the threads–nothing that can't be put into Capistrano.
Ruby on Linux is fast and isn't a problem to implement. MySQL with Ruby is easy enough, and there are several really good ORM packages available like ActiveRecord and Sequel. Sinatra won't make you choose one that you hate.
In addition to the answers to your questions, I have a few more reasons.
Sinatra has an easy learning curve, and is very easy to pick up. The biggest problem I had was getting it onto my Dreamhost server since Rack was an older version, but with a vendored version of Rack the problem vanished. If I could, I'd rewrite my latest Rails project in Sinatra with ActiveRecord so as to make maintenance easy upon myself; too much effort was spent in it already.
Thanks to its ease of use and ease of learning, I have found myself more productive in Sinatra without code generators than in Rails with all the code generators. And that's saying something.
Sinatra supports middleware for Rack, and is therefore very flexible in what you can do with it.
If I were to average out the helpfulness of the Sinatra community, on IRC, I'd say that they're more knowledgeable about the framework than the average Rails user–just as a cursory comparison. The reason being that Rails is more accessible to newbies and people who just have no business programming.
Sinatra will support Ruby 1.9. I'm still not entirely certain just how much support for 1.9 there is currently in Sinatra, but I do know they were initially waiting on Rack. As of April 25 this is no longer an issue, so presumably Sinatra is already prepared for 1.9; I know for a fact 1.9 support is in the pipeline for mid 2009, but I don't know how long that will be.
Assuming you can get Sinatra working with Ruby 1.9 with a little effort (version 0.9.2 already supports Rack 1.0, and by proxy 1.9 in Rack's code), before the public 1.0 with support for 1.9, your performance on the Ruby side would be stellar. Even if you cannot, then Enterprise Ruby would help the speed.
Both Django and Rails come pretty close to fitting most of your criteria, except I think that Django's documentation is way better than that of Ruby on Rails'; the documentation for Django is nothing short of amazing (and I'm not being hyperbolic here).
I don't know about the scalability of Django, though. I know Rails scales pretty well (up to a point), but I don't know if the same can be said of Django. (I'm not saying it can't; I'm just saying that I honestly don't know, as I've never written a large application using Django.)
Django also has a pony, in case you secretly desire that, too.
Well. Scalability is nothing easy to get. For Google-like response times, you need something like MapReduce. Ok. Don't kid yourself, super-scalability is nothing for beginners.
As for all the other points, Seaside is clearly best. As for security, check out seaside.st to see why it is inherently more secure than all the other frameworks I am aware of (including Rails and Seam, e.g.). Seaside is reasonably well-documented, but also looking at the internals of seaside is so easy and convenient, that hardly a question remains open for the community to answer, which it does fast usually. Seaside has been stable for many years now, so I think you'll be fine with that.
As for Performance oriented: Run the commercial Seaside, GLASS, and you will get stunning performance compared to a LAMP-like setup, due to the much faster database solution that is integrated, and the framework which trades memory for speed and gets a lot of speed.
Seaside is architectured so well that many people find writing Seaside apps easier than desktop applications. Try it out, you'll love it.
PS: For the record, Seaside is not RESTful.
You can have a look at Django, Python framwork.
It's a very well documented framework, it has an automatic CRUD administrator interface on database and it has also a free book online, that of course you can buy for real :)
Try them all to find out the correct answer!
Well, the people who will be suggesting 'one framework to rule them all' won't have tried them all either!
I guess if there were such a framework, it would be one and only.
For PHP, I've loved the Zend framework (though, to me it is not really a framework). One of it's best features is that each component is independent of the others... So if there is some part of it you don't like, just don't use it. Also, you mention JSON... Zend fully supports JSON in both directions....
Ruby on Rails is vastly documented with loads of plugins and has been tested in scalability already ( see BaseCamp and other solutions made in rails)
Looking at your list of priorities it's hard to say that any one route is the "right" way to go. On the PHP side I've spent a significant amount of time with CakePHP which accomplishes much of what you looking for. But being a guy who hates PHP I would suggest steering clear of anything in that realm.
It's all about style and experience. I've used Ruby On Rails, which isn't the most elegant of languages but it does the job exceptionally well. It hadn't matured as much as using a Spring/Hibernate stack on Java or using .Net which handles almost everything straight out of the box, but it does the job exceptionally well. I prefer the Java/.Net based projects because it fits much better with the way I like to program.
There is no "right" answer, just lots of good ones. ASP.Net MVC for example is a good choice. Forever ago I used Spring on Java which was also fairly effective at accomplishing the job. Even PHP is not a wrong choice. Ruby On Rails, which I have only done two projects with, is very easy to pick up and it makes some rather complicated tasks in other languages fairly simple.
I think that for sheer volume of documentation you can't beat J2EE. It's also believed to be insanely scalable and stable.
Now, from there to really being desirable....
If you're considering Java I would recommend Jersey, it works great and I think it reaches all you 5 goals...
If Java is in your toolkit, look at Stripes.
Rock stable, enthusiastic, though no a spectacularly large community. Good docs, some out of date granted, but the system is so stable even the "old stuff" is relevant. A real nice, recent (late last year) book. Stripes is small enough that the book can, and does, "cover everything".
It's an action framework, doesn't do much in the presentation area (save for forms, mostly, and it has a completely optional templating/layout facility). You can use JSP or FreeMarker, or, really, anything else. It can also do web services (though not as well as something like Jersey).
It is back end agnostic, but there is a JPA integration project for it.
Finally, you can leverage, if you like, all of the other Java/Java EE kit if you want. Since Stripes doesn't consume the entire stack, you have a lot of flexibility to pick and choose the parts you want. Full boat Java EE, Transactions, Session Beans, JMS. Works with Spring (it is "conscious" of Spring and has good integration) JPA, iBatis, Hibernate, raw JDBC, Lucene, JSR-170 Content Repository, whatever.
It's a great piece of kit.
For a 2014 answer, I would recommend Laravel/Slim Framework (PHP), Ruby on Rails/Sinatra (Ruby), Django/Flask (Python), Grails (Groovy, JVM-based language), Play! Framework (Java/Scala) or Sails.js/Kraken.js (Javascript).
Where the first framework mentioned is a bit larger and the second is a bit smaller for the languages where I mention 2 frameworks with the use of a "/".
I hope this helps people that have similar questions 5 years later.
Try cppcms
it is a high performance Web Development Framework
I'm not really asking about how programmers learn how to program. More about specific technologies. If I wanted to learn Hibernate, how do I know what I should know prior to Hibernate? Should I learn JPA before, during or after Hibernate? Is there a better solution to Hibernate? (And I'm not really looking for information on Hibernate specifically)
Maybe stackoverflow is the place to find these answers, but it seems like with the shear vastness of frameworks, apis, libraries, programming languages, platforms, and whatever other techie word you want to use, it takes an extremely long time to come up to speed on what technology to use, when and what you need to know prior to using it.
Sometimes the best way to learn is to just dig in to a framework. Sure, you could use someones wrapper API around something, but if there is something wrong w/ hibernate, then you wouldn't know what's happening.
And to answer "how do i know what i should know prior to hibernate", you don't, that's why you are learning. When learning about c++, started out with simple data types, but i didn't know about pointers yet, didn't need to, but i learned about them when i got there. Just gotta jump in and start playing around.
I use Wikipedia to compare various technologies to copmlete a task, although it can be incomplete with regards to commercial closed-source frameworks (probably because fewer people have access to them).
For specific technologies such as Hibernate, Java, JPA, LDAP (OpenLDAP in particular), Log4J, anything Apache: they all have wikis and/or forums associated with the product that are usually more helpful than a Google search for learning. Many even come with tutorials and you should try them.
Find a book on the subject and read it. Then email the author with additional questions. Most of these authors are more than happy to help especially if you've bought and read the materials they worked so hard to produce.
If that's still not enough for you, go to a conference covering the subject, if you can make it. Again you can meet many of the people responsible for maintaining and/or creating these technologies and I've found they are always willing to answer questions.
go to sites like Coding Horror, Slashdot, Techcrunch etc and find out what people are talking about. Usually if something is popular it's probably something you might want to talk a look at.
There are these things called "books" that are filled with all kinds of knowledge.
A lot of the time the documentation and/or tutorial for any technology or project will mention what prior knowledge is assumed or useful.
So for example hibernate: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#tutorial-intro
"This tutorial is intended for new users of Hibernate but requires Java and SQL knowledge"
For me, the things that have helped my career and taught me what questions to ask are:
Podcasts -- .NET Rocks, etc., which introduce and discuss new technologies and put them in context
Join your local users group, and stick around after the presentation to talk shop with the folks there; you can learn a lot just by hearing what other people are doing and what they are working on learning next
Just look around online and start trying to use whatever tool/technology your trying to learn. As you try to learn one thing, you'll realize your lacking knowledge in other needed areas. at which point you can repeat the process of looking around for this new item you need to learn.
for example, maybe you want to learn Rails, so you start following rails tutorials, but you realize you suck at Ruby. so then you start to focus a bit more on the details of Ruby, then come back to Rails with a little more knowledge and continue on till the next roadblock. this isn't really totally correct, but you get the idea.
you won't always find a full guide of how to use everything. just give it a shot and work it out on your own if you have the time
There is an infinite number of things one could learn. Maybe a better approach would be to think of a project that interests you, or join an open source one, and then learn what you need to know to accomplish what is needed in that project. When you're done, pick a new project that might include new things not learned in the last project.
As far as free sources are concerned, as a .NET programmer I like www.asp.net, and there are many others, such as the ASP.NET quickstart tutorials at http://quickstarts.asp.net/QuickStartv20/default.aspx, C-SharpCorner is good, too, if you don't mind C#.
If you don't object to paying a little money, Lynda.com is a decent place. They have OK tutorials on all kinds of things, not just programming, and I got a decent grounding in Javascript using one of their tutorials. They are adding new things all the time, so if they don't have something on Hibernate now, they may later on. I think their basic rate is $25 per month, but you can just pay for one month and then soak up as many courses as you can find time for.
Asking a more specific question will get your a more specific answer here. When I want to read up on something I usually head to Wikipedia and then Google.
The truth is none of us have the time to read everything we'd like to. So I let someone else do it for me!
The way I solve this is by speed-reading the web - aka. subscribing and reading to other peoples blogs.
Everytime I come across something I'm not familiar with I google it.