Related
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.
I realize that this may be subjective but I truly need an answer to this and I can't seem to find anything close enough to it in the rest of the Forum. I have read some folks say that the framework (any MVC framework) can obscure too many things while others say that it can promote good practices. I realize that frameworks are great for a certain level of programmer but what about individuals starting out? Should one just focus on the language or learn them together?
I think web development is way more than anyone grasps when they first start getting into it! Read this and know that it is all optional...but required to be really good at what you do.
I suggest that you spend time learning your language first. I would suggest learning C# simply because it is vastly more marketable and it is usually directly supported in most of MS products. By learning C# - programming in ASP.NET, console apps, servers, services, desktop apps, etc. will all be within your reach. You can program for most of the MS products as well as on many Linux type platforms.
Once you have this down then you can move to programming for the web as programming for the web has some intricacies that most other environments don't have. Concepts such as sessions, caching, state management, cross site scripting, styling, client side vs server side programming, browser support, how HTTP works, get vs post, how a form works, cookies, etc. are all at the top of the list of things to learn separately not to mention learning the ASP.NET base frameworks and namespaces.
Once you have the programming language down and then the concepts of web programming I suggest that you pause and learn database design. Don't worry about performance just yet...try to first learn good design. Performance will come next. A good start for you is Access (blasphemy I know). It is easy for a beginner to work with. And it translates into a more robust platform such as SQL Server easily. Learn at the very least some SQL...but I suggest that you learn as much as your stomach can handle. I heard someone say that SQL is like the assembly language of the database. The number one thing that slows an application to a halt is piss poor database design and poor queries. Once you have this knowledge - stuff it away in the back of your mind and take a look at a good ORM. NHybernate is probably best at the moment but is more complex that the basic learner needs. For that reason I currently suggest getting LINQ to SQL up and running as it is SUPER EASY to work with. Then look at Entity Framework (although I still think it sucks...and you should wait till EF 2.0...ERRRRR...now 4.0 released with .net 4.0). Then NHybernate.
Now is the time to start to understand the infrastructure that is required by web development. You may bump your head against this as you learn some of the web programming stuff. But you need to understand the basics of DNS, IIS, load balancers, sticky routing, round robin, clustering, fault tolerance, server hardware setup, web farms, cache farms (MemCached Win32, Velocity), SMTP, MSMQ, database mail queuing, etc. Many people may say you don't need this. That there will be some knowledgeable network admin to help you out here. However they generally know things that impact them...not you. The more you know here the more valuable you will be to the company that hires you.
Now you can get into the details of best practices and design patterns. Learn about the basics such as repository pattern, factory pattern, facade pattern, model view presenter pattern, model view controller pattern, observer pattern, and various other things. Follow Martin Fowler and others for suggestions here. Take a look at concepts such as inversion of control, dependency injection, SOLID principle, DRY, FIT, test driven design, and domain driven design, etc. Learn as much as you can here before moving to the next step.
NOW you can think about frameworks! Start by creating a basic application with ASP Classic (comes with IIS for free!). This will give you a flavor of a no frills web development environment. Take a look at ASP.NET web forms (briefly) to see how MS attempted to make things easier by hiding all the complex stuff (which you now know how to manage on your own from your readings of the above materials!!!). Now you no longer need ASP.NET Web Forms. Move immediately to ASP.NET MVC. The MVC framwork gives you all the power you need to create a good easily manageable web application. If you build something really big no framework for pure web development may be able to deal with what you need. However MVC is way more extensible for such UBER custom scenarios.
Now that you have made it through the journey to ASP.NET MVC you can take a look at things such as Microsofts Enterprise Application Blocks (such as they use at MySpace). Take a look at Elmah error logging (a must have). Look at how to build a custom SiteMapProvider for your MVC site. If you need to get into searching stuff understand Lucene.NET.
And if you made it this far...you are ready to figure out the rest on your own as it comes up! Have fun. There is a lot of room in this space for a person with some understanding of all of the above concepts.
You'll be using SOME sort of framework. The question is, what level do you want to learn at?
You'll probably not care to learn about asynchronous I/O and mutlithreaded vs. select/poll styles of web servers.
So then, your language of choice is going to provide a layer atop this, the languages preferred "web interface" API. For Java it's Servlets, the lowest level you'd typically code at for server side web applications.
You should find what this "lower level" layer is in your language and learn the API at least. You should know basic HTTP like status codes, cookies, redirects, POST vs GET, URL encoding, and possibly what some of the more important headers do.
You'll then come to appreciate what these higher level frameworks bring to the table, and be better able to evaluate what is the appropriate level of abstraction for your needs/project.
Web development requires a certain degree of organization, since it relies so much on separation of concerns. The browser, for example, is designed to display data and interact with the user. It is not designed to lookup data from a database, or perform analysis. Consequently, a web development framework can help provide services that are needed to make the browser experience a practical one.
The nice thing about employing a platform is that it will provide core components essential to the making of any web application that you won't (and shouldn't) have to think about, such as user membership, for example. Many of the design decisions and deep thinking about how to implement these services has already been done for you, freeing you to focus on what you actually want you application to do.
Of the available frameworks, I find that frameworks that implement the MVC (model-view-controller) pattern are very practical. They clearly organize different functions of web development, while giving you full control over the markup presented to the browser.
All that said, you will need some fundamental skills to fully realize web development, such as HTML, CSS, and a core programming language for the actual underlying program, whether you use a platform or not.
I don't think I agree with the Andrew. I don't think learning C is a pre requisite for web development. In fact, learning something like Javascript, Action-script or PHP is often easier due in large part to the vast numbers of sites and tutorials available, and are enough to expose you to the fundamentals of pretty much every programing language. Variable, Conditions, Loops and OOP. I just think learning C# introduces a lot of learning that isn't really relevant to web development such as pointers and memory management.
As for wether you should learn a framework first? Definitely not. Never ever. You need to be able to stand on your own two feet first and be comfortable with HTML/CSS, Server Side Scripting (PHP/ASP/Python/Ruby whatever) and love it or loathe it, but you're going to have to have a decent understanding of Flash and Action-script.
The order in which you learn these is entirely up to you. But my learning plan would go like this...
Start with HTML. It takes about half an hour to get the basics (it's made up of tags with attributes, end of lesson 1) and it's good to get it out of the way first.
Then start leaning CSS. You'll get the basics again, very quickly. But CSS is a minefield so expect to spend the rest of your life figuring it out.
Next up Action-script. Most people wouldn't agree with me, but bear with me. HTML and CSS aren't programming languages. Action-script is. And learning a programing language for the first time is difficult and tedious. The advantage Action-script has over most other languages is that the results are very visual. It's enjoyable to work with and you can sit back and take pride in your accomplishments at regular intervals. This isn't possible with server-side scripting languages or Javascript and there's a whole host of stuff you need to learn to get server side scripting up and running. You can't build space invaders in with PHP for example.
I've changed my thinking here. I would encourage beginners to ignore ActionScript and focus on Javascript. I still believe that being able to see stuff on screen quickly is a good motivator, but I would encourage people to look at canvas tag tutorials and frameworks. Javascript has come a long way since 2009, and is now the lingua franca of programming, so it's incredibly useful. My initial point about HTML and CSS not being programming languages still stands.
Then, you can start with your server side language. At the same time, you're going to have to figure out the database stuff. I recommend PHP and MySQL because it's free.
Again, I've changed my thinking here. I would encourage beginners to use Javascript on the backend (Node.js), and split their database learning between relational databases and noSql solutions such as Mongo.
Then.... learn your framework. Or better yet, roll your own. That's what I've been doing and it's supercharged my learning.
If you're getting into web development, You HAVE to know how those building blocks work. You don't have to be an expert in all the areas, but you should try to become an expert in at least one of them. If you start learning a framework before you get the fundamentals you'll be in a sticky middle ground where you don't understand why things don't work which will infuriate you, and anyone who has to work with you.
you should learn how to use framework because it would be helpfull for u in the future also it is easier to learn.
MVC will help you a lot .. trust me ... i was developing web project not using mvc and it is like mess ... (in the past there are no well know mvc and i never heard about it)
Short version: yes, and then some.
FWIW : This more generic answer may be of use to someone out there.
What: Frameworks take out tedium of using boiler-plate code again and again. They hide complexity and design issues under wizards and conventions. They also use special libraries, design patterns etc. in ways that are far from obvious to a beginner.
So using a framework is good for getting things done without knowing exactly how - like using an ATM without knowing the internals. You just add your code bits in certain places and things 'just work'.
HTML > CSS > Ruby > SQL > Rails/Javascript framework > Libraries would make for a good learning track. Rest you learn as you go along by being curious, hanging out on forums or as extended learning as need arises.
HOW: The problem starts the minute you step outside simple text-book examples (i.e. when you try to get it to do something even a bit different).
Decoding cryptic error messages when it seems like you've done everything right but things still don't work. Searching on error strings in forums may help out. Or just re-starting from scratch.
Reading up articles and books, videos, trial-and-error, hard-work, search-engines, stackoverflow/forums, local gurus, design articles, using libraries, source-code browsing are a good way to climb the learning curve gently and on a requirement basis.
Working-against-the-framework is the number one problem for beginners. Understanding what the framework expects is key to avoiding white-hair in this phase. Having enough insight to manually do what the framework automates may help reduce this second-guessing effort.
WHY: For more advanced debugging/design, it's good to know what the framework is doing under the hood esp. when things don't work as you planned. Initially you can take the help of local-gurus or forum gurus who've already done the hard work. Later as you go deeper you can take on more of that role. For example there's a "rebuilding rails" book which looks under the hood of Ruby on Rails.
Note: Some of the tips are oriented towards Ruby/Rails but you can easily substitute your favourite language/framework instead.
I have inherited a broad, ill-designed web portfolio at my job. Most pages are written in Perl as most of the data ingested, processed, and displayed on the site comes in the form of flat-files which then have to be meticulously regexed and databased in our MySQL and Oracle databases.
As the first IT-trained manager of this environment, I am taking it upon myself to scrub the websites and lay down some structure to the development process. One of the choices I have been given is to choose whether or not to continue in Perl. There is substantial in-house talent for Java and PHP is rather easy to learn. I have considered taking the reins off the developers and letting them choose whatever language they want to use for their pages but that sounds like it might be trouble if the guy who chose PHP gets hit by a bus and no one else can fix it.
As the years go by hiring Perl programmers becomes more and more difficult and the complexity of maintaining legacy Perl code from previous developers whose main focus may have been just getting a page up and running is becoming very resource-consuming. Another, previous (non-IT) manager was more focused in on quick turnaround and immediate gratification of pages rather than ensuring that it was done right the first time (he has since been promoted outside our branch).
The production server is solaris. MySQL has most of our data but new projects have begun using Oracle more and more (for GIS data). Web servers are universally Apache. We live in an intranet disconnected from the regular internet. Our development is conducted in an Agile, iterative manner.
Whatever language is chosen to push forward into, there are resources to have the existing development staff re-trained. No matter what, the data that comes into our environment will have to be regexed to death so perl isn't going away anytime soon. My question to the community is, what are the pros and cons of the following languages for the above-defined web dev environment: Perl, PHP, Java, Python, and --insert your favorite language here--. If you had it to do all over again, which language set-up would you have chosen?
Edits and Clarifications:
Let me clarify a bit on my original post. I'm not throwing everything away. I've been given the opportunity to adjust the course of the ship to what I believe is a better heading. Even if I chose a new language, the perl code will be around for some time to come.
Hypothetically speaking, if I chose Assembly as my new language (haha) I would have to get the old developers up to speed probably by sending them to some basic assembly classes. New pages/projects would be in the new language and the old pages/projects would have to play nice with the new pages/projects. Some might one day be rewritten into the new language, some may never be changed.
What will likely always be in Perl will be the parsing scripts we wrote years ago to sift through and database information from the flat files. But that's okay because they don't interface with the webpages, they interface with the database.
Thank you all for your input, it has been very very helpful thus far.
It seems that your problem is more legacy code and informal development methodology than the language per se. So if you already have Perl developers on staff, why not start modernizing your methods and your code base, instead of switching to a new language, and creating an heterogeneous code base.
Modern Perl offers a lot in terms of good practices and powerful tools: testing is emphasized, with the Test::* modules and WWW::Mechanize, data base interaction can be done through plain DBI, but also using ORM modules like the excellent DBIx::Class, OO with Moose is now on par with more modern languages, mod_perl gives you access to a lot of power within Apache. There are also quite a few MVC frameworks for Perl. One that's getting a lot of attention is Catalyst.
Invest in a few copies of Perl Best Practices, bring in a proper trainer for a few classes on modern development methods, and start changing the culture of your group.
And if you have trouble finding developers that are already proficient in Perl, you can always hire good PHP people and train them, that shouldn't be too difficult. At least their willingness to learn a new language would be a good sign of their flexibility and will to improve.
It is always tempting to blame the state of your code on the language its written in, but in your case I am not sure that is the case. Lots of big companies seem to have no problem managing huge code bases in Perl, the list is long but the main Web companies are all there, along with a number of financial institutions.
I would bring in someone who is very good at Perl, to at least look at the current design. They would be able to tell you how bad the Perl code really is, and what needs to be done to get it into good shape.
At that point I would start considering my options. If the Perl code is salvageable, well than great, hire someone proficient in Perl. Also train some of your existing staff to help on the existing code-base. If you don't have someone proficient in Perl in charge of the Perl code, your code-base may become even worse than it already is.
Only if it was in terrible shape, would I consider abandoning it for another language. What that language is, that is something your going to have to think about that yourself.
p.s. I'm a bit biased, I prefer Perl
If regex is important I would choose a language with good support.
If you would use java, you will not be able to just copy paste your regex code from the perl code because the slashes have to be escaped. So I would vote against java.
I'm not familiar with php enough to know its regex features, but given your choices I would go for python. You can create cleaner code in python.
Would ruby also be an option? It also has good perl like regex support and rails supports agile web development out of the box.
first off let me point out that MySQL's spatial extensions work with GIS.
Second, if you have a bunch of Perl programmers that will need tow ork on the new sites then your best bet is to choose something they won't have too much trouble understanding. The obvious "something" there is PHP. When I learnt PHP I'd done some Perl years ago and picked up PHP in no time at all.
Switching to something like Java or .Net (or even Ruby on Rails) would be a far more dramatic shift in design.
Plus with Apache servers you already have your environment set up and you can probably stage any development as a mix of Perl and PHP reasonably easily.
As to the last part of your question: what would you do it in if you could do it over again? To me that's a seprate and basically irrelevant question. The fact is you're not rewinding and starting over, you're just... starting over. So legacy support, transition, skills development and all those other issues are far more important than any hypothetical question of what you'd choose in a perfect world if all other things were equal.
Love it or hate it, PHP is popular and is going nowhere anytime soon. Finding skiled people to do it is not too difficult (well, the dificulty is filtering them out from the self-taught cowboy script jockeys who think they can code but can't) and it's not a far step from Web-based Perl.
If your developers are any good, they'll be able to handle anything thrown at them. Deciding what language to use is quite a tricky strategic position, but I recommend you think very carefully before introducing any MORE (i.e. don't).
Unless of course, there is something that you absolutely cannot do (or cannot do sanely) with what you've got.
I think choosing a single language is key and if your database is primarily MySQL, then PHP seems like the obvious choice. It naturally works with your database, it's open source and there is tons of documentation, source code, doesn't require compiling, etc.
People come and go through positions and any website will evolve over time. If you have the ability to set some guidelines and rules, I would choose something that is forgiving, common-place, and easy(er) to learn.
I'd also suggest writing it down so people in the future don't re-invent the wheel.
I'm at a point in my freelance career where I've developed several web applications for small to medium sized businesses that support things such as project management, booking/reservations, and email management.
I like the work but find that eventually my applications get to a point where the overhear for maintenance is very high. I look back at code I wrote 6 months ago and find I have to spend a while just relearning how I originally coded it before I can make a fix or feature additions. I do try to practice using frameworks (I've used Zend Framework before, and am considering Django for my next project)
What techniques or strategies do you use to plan out an application that is capable of handling a lot of users without breaking and still keeping the code clean enough to maintain easily?
If anyone has any books or articles they could recommend, that would be greatly appreciated as well.
Although there are certainly good articles on that topic, none of them is a substitute of real-world experience.
Maintainability is nothing you can plan straight ahead, except on very small projects. It is something you need to take care of during the whole project. In fact, creating loads of classes and infrastructure code in advance can produce code which is even harder to understand than naive spaghetti code.
So my advise is to clean up your existing projects, by continuously refactoring them. Look at the parts which were a pain to change, and strive for simpler solutions that are easier to understand and to adjust. If the code is even too bad for that, consider rewriting it from scratch.
Don't start new projects and expect them to succeed, just because your read some more articles or used a new framework. Instead, identify the failures of your existing projects and fix their specific problems. Whenever you need to change your code, ask yourself how to restructure it to support similar changes in the future. This is what you need to do anyway, because there will be similar changes in the future.
By doing those refactorings you'll stumble across various specific questions you can ask and read articles about. That way you'll learn more than by just asking general questions and reading general articles about maintenance and frameworks.
Start cleaning up your code today. Don't defer it to your future projects.
(The same is true for documentation. Everyone's first docs were very bad. After several months they turn out to be too verbose and filled with unimportant stuff. So complement the documentation with solutions to the problems you really had, because chances are good that next year you'll be confronted with a similar problem. Those experiences will improve your writing style more than any "how to write good" style guide.)
I'd honestly recommend looking at Martin Fowlers Patterns of Enterprise Application Architecture. It discusses a lot of ways to make your application more organized and maintainable. In addition, I would recommend using unit testing to give you better comprehension of your code. Kent Beck's book on Test Driven Development is a great resource for learning how to address change to your code through unit tests.
To improve the maintainability you could:
If you are the sole developer then adopt a coding style and stick to it. That will give you confidence later when navigating through your own code about things you could have possibly done and the things that you absolutely wouldn't. Being confident where to look and what to look for and what not to look for will save you a lot of time.
Always take time to bring documentation up to date. Include the task into development plan; include that time into the plan as part any of change or new feature.
Keep documentation balanced: some high level diagrams, meaningful comments. Best comments tell that cannot be read from the code itself. Like business reasons or "whys" behind certain chunks of code.
Include into the plan the effort to keep code structure, folder names, namespaces, object, variable and routine names up to date and reflective of what they actually do. This will go a long way in improving maintainability. Always call a spade "spade". Avoid large chunks of code, structure it by means available within your language of choice, give chunks meaningful names.
Low coupling and high coherency. Make sure you up to date with techniques of achieving these: design by contract, dependency injection, aspects, design patterns etc.
From task management point of view you should estimate more time and charge higher rate for non-continuous pieces of work. Do not hesitate to make customer aware that you need extra time to do small non-continuous changes spread over time as opposed to bigger continuous projects and ongoing maintenance since the administration and analysis overhead is greater (you need to manage and analyse each change including impact on the existing system separately). One benefit your customer is going to get is greater life expectancy of the system. The other is accurate documentation that will preserve their option to seek someone else's help should they decide to do so. Both protect customer investment and are strong selling points.
Use source control if you don't do that already
Keep a detailed log of everything done for the customer plus any important communication (a simple computer or paper based CMS). Refresh your memory before each assignment.
Keep a log of issues left open, ideas, suggestions per customer; again refresh your memory before beginning an assignment.
Plan ahead how the post-implementation support is going to be conducted, discuss with the customer. Make your systems are easy to maintain. Plan for parameterisation, monitoring tools, in-build sanity checks. Sell post-implementation support to customer as part of the initial contract.
Expand by hiring, even if you need someone just to provide that post-implementation support, do the admin bits.
Recommended reading:
"Code Complete" by Steve Mcconnell
Anything on design patterns are included into the list of recommended reading.
The most important advice I can give having helped grow an old web application into an extremely high available, high demand web application is to encapsulate everything. - in particular
Use good MVC principles and frameworks to separate your view layer from your business logic and data model.
Use a robust persistance layer to not couple your business logic to your data model
Plan for statelessness and asynchronous behaviour.
Here is an excellent article on how eBay tackles these problems
http://www.infoq.com/articles/ebay-scalability-best-practices
Use a framework / MVC system. The more organised and centralized your code is the better.
Try using Memcache. PHP has a built in extension for it, it takes about ten minutes to set up and another twenty to put in your application. You can cache whatever you want to it - I cache all my database records in it - for every application. It does wanders.
I would recommend using a source control system such as Subversion if you aren't already.
You should consider maybe using SharePoint. It's an environment that is already designed to do all you have mentioned, and has many other features you maybe haven't thought about (but maybe you will need in the future :-) )
Here's some information from the official site.
There are 2 different SharePoint environments you can use: Windows Sharepoint Services (WSS) or Microsoft Office Sharepoint Server (MOSS). WSS is free and ships with Windows Server 2003, while MOSS isn't free, but has much more features and covers almost all you enterprise's needs.
On an average, how much time does it take to become proficient in development using JD Edwards? Is it easy to learn? Are there any prerequisites?
I'm assuming you're interested on learning the development skills of JD Edwards, not the business processes that the system actually implements.
There are 2 versions of JDE. One runs over AS/400 plataforms, DB2 database and uses RPG (language) to implement reports and functionalities. I'm not acquainted with that version (did very few interface jobs and they were all complicated due to DB2's differences from my usual flavours of databases - Oracle or SQL Server).
The other version is EnterpriseOne (formerly OneWorld). I started developing for this version in 2000 and kept active until 2006. It's very easy to achieve the basic level of development and then you get to face the oddities and known issues from the system and how to dodge them and that's when you become experienced.
All development tools are internal to JDE. There's a table designer, a query designer (with a grid interface that resembles any visual query designer), an interactive programs designer (forms), a report designer and a business rules designer.
If you have experience with any RDA tool (like Visual Studio, for instance) and development for databases, you will be able to use this knowledge to ease the learning curve. In my case, I was a SQL programmer and I had a lot of experience with Visual Basic and Microsoft Access. I was able to use that experience by understanding the underlying concepts of the system and adapting for them. It took me about 25 hours of training with a more seasoned programmer to get me ready to at least do basic stuff on real customers. This amount of hours varies from person to person, obviously.
However, I can say that I only started to feel that I was understanding the tools and the process after 6 months of daily work on my first customer. After about 12-18 months, I was ashamed of the first applications that I wrote, so I actually went back and rewrote some on my own time... :-)
The thing about JDE is: there's very little coding/functionality on the database side (because it used to be flexible on databases choices). All the forms and reports are written inside the actual system by way of the designers.
All "coding" is done by way of a simple (and sometimes dumb) point-and-click interface. For instance: you don't write an assignment statement, like var = value. You select the Assignment button, then you select the variable in a list, then you select the value in a list (or enter the value, if it's fixed).
All the rules behind forms, reports and business rules are created that way. One exception: when you're writing a business rule, you can opt between using this approach (called Named Event Rule - NER) or using the C language (called Business Function).
If you choose NER, after you finish, the system actually converts that to C.
There are debug functionalities for forms, reports and business rules.
This is basic development. There are other tools and functionalities that are usually assigned to developers and so you will be able to do a lot more. I've worked a lot with interfaces, interoperability, workflow and more.
Also noteworthy is that JDE has an internal tool for managing objects, version control, checkins, checkouts and transfering objects from one environment to another to complete the development cicle.
As a developer, the more you learn about the business processes being implemented, the better. You get to learn the inside (code, specs) and outside (process) for the functionalities and this helps you as a developer and helps you in your career (and paygrade).
Now, my only caveat regarding my answer: as I've mentioned, it's been a while since I left JD Edwards development. As far as I know, things are pretty much the same, but I can't say for sure.
Best advice I can offer: go to www.jdelist.com for specific questions and help with issues. Be polite, try to ask questions about specific matters instead of general questions (I mean: if you ask those guys how long does it take to learn JDE, they will probably ignore you, but if you ask stuff like "in your opinion, what are the most complex tasks for a JDE developer to master?" you will probably get some pretty good answers).
Hope it helps and wish you good luck with JDE. After the initial bump, I enjoyed my ride on it quite a lot.
You can start with the JD Edwards EntepriseOne Developer guide to learn about object management work bench, design tools for table, form and reports and API for Business Functions.
https://docs.oracle.com/cd/E53430_01/nav/development.htm
As far as I can tell, it depends on the version of JDE. There are a lot of different components, and different versions (from what I can tell.) For example, a sister company of ours is running JDE over terminals to an AS/400. It's all "Green Screen" text-based screens, typing three letter commands at a command prompt, and using the cursor to move around the screen.
I haven't tried to learn it in depth yet, but trying to learn enough to do basic support has taken me several months at a few hours a week. Think of JDE as a baby version of SAP, that gives you an idea of the scope of your question.
I taught some classes about JDEdwards EnterpriseOne Development.
One of my students who never programmed before took about 320 hours of trainning to be able to do some developments on JDEdwards. Nowadays he's a coworker and a good programmer.
His 320 hours of trainning was:
During 5 months I taught on saturdays, 8 hours
Then he got another trainning which was 4 hours week and 8 hours on saturdays for 5 weeks
As I've said after all this, he has being able to perform all tasks of a JDEdwards Developer.
And my advice to who is going to study this is to have a good knowledge of SQL and have programmed before in any compiled language, it helps a lot.