Java Frameworks and Components 153
Java Frameworks and Components: Accelerate Your Web Application Development | |
author | Michael Nash |
pages | 477 (14 page index) |
publisher | Cambridge University Press |
rating | 9 |
reviewer | Simon P. Chappell |
ISBN | 0521520592 |
summary | A tour de force! With only one quibble, this is the definitive work on Web Application Frameworks. |
Overview
This book is a superb exploration of the current state of the web application development framework market. Both commercial and open-source/free frameworks are examined in detail.The book works through a logical progression, starting with a discussion of what a framework is (and, of course, what it isn't) before moving on to an examination of the benefits that they bring to development efforts. The meat of the book is in the next couple of chapters where a framework (no pun intended) is explored to select and compare frameworks. A list of current frameworks is given, each being described, with strengths and weaknesses highlighted.
The trailing chapters cover aspects of development that are affected by the use of frameworks, including the obvious ones like IDE support and methodologies.
What's To Like
The aspect that most impressed me was the depth of research that has obviously gone into this book. I think most of us know that frameworks are good, and a reasonable number of us could list several reasons why they are good, but I suspect that very few of us could generate such a comprehensive and cogent rationale for using a framework.The information density in this book is quite high. Normally, I read technical books quite quickly, but this one took a while, because every good point prompted much thought and consideration. This was impressive to me after seeing so many books coming to the market that have simplification as their rationale for existence. The selection of an appropriate framework for web application development is not a simple task and this book takes it very seriously.
While non-free frameworks might be a non-issue for some of the Slashdot crowd, those of us working in corporate I.S. have to be very aware of the differences and our local management's attitudes concerning it. The book does come out strongly in favour of open-source and free software, but does not let this bind the discussion in any way. Commercial and free software are judged equally and fairly throughout.
Pragmatic is a much over-used word these days, but I would describe this book as pragmatic. The advice given concerning framework selection, urged people to consider many factors, including existing frameworks used in-house, the type of project, the degree of accordance between the services provided by the framework and the requirements for the system being written. I have seen many a framework selected because it was buzzword compliant, so this advice was a refreshing change.
What's To Consider
After enjoying the book, to reach the case studies and be disappointed was, well, disappointing. The case studies seemed rushed and lacking in substance. The idea of comparing and contrasting the four leading frameworks to solve the same problem was a good one, but somehow it didn't quite come off. The Struts case study got to me the most: I have conniptions everytime I see business logic in actions! Perhaps the case studies could be dropped in a future edition?
Summary
A tour de force! With only one quibble, this is the definitive work on Web application frameworks.
Table Of Contents
1. Components and Application Frameworks
2. Components: The Future of Web-Application Development
3. Application Frameworks: What Do They Provide and What Are the Benefits?
4. Choosing an Application Framework
5. A Catalog of Application Frameworks
6. Comparing Frameworks
7. Open Source and Components/Frameworks
8. Development Methodologies and Design Patterns
9. Integrated Development Environments
10. Strategies for Using Frameworks: Best Practices
11. Conclusions: The Future of Frameworks and Components
Appendix. Case Studies
You can purchase Java Frameworks and Components: Accelerate Your Web Application Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Case Studies (Score:5, Insightful)
aren't? (Score:3, Interesting)
Re:aren't? (Score:1)
http://otn.oracle.com/oramag/oracle/02-nov/o62odev _java.html [oracle.com]
If you ask me, the whole thing is retarded. Whenever you get these high level abstract frameworks, they imply limitation and slowness, both in running and writing. (Examine Zope as a perfect non-java example.) People forget that learning new frameworks takes lots of time, time that could have been spent just writing code. They also limit what you can do for everything they give half the time.
I us
WTF is "infrastructure code"? (Score:3, Interesting)
I think I understand the term, but does that mean it's a given that any application is built around a "framework"?
All well-constructed software is sliced into coherently-discrete layers that are solved as individual problems, but I believe the "framework" concept is largely a commercial concept designed by certain vendors to enable them to sell large, complex toolkits.
Are we not in danger of taking this commercial model and turning it into dogma, in which your application shall be built around a framework and the only choice is "which one?"
Re:WTF is "infrastructure code"? (Score:5, Informative)
lots of apps need to validate form input, connect to a database, retrieve data and save settings. these are generic "framework" tasks that apply across a wide range of applications. You start with these base foundations (either you roll your own or use someone elses), and decorate it with your particular business needs.
Frameworks like Struts for web apps include much of the stuff you would do yourself anyway: authentication, validation, form repopulation, session management. since lots of geeks/nerds get together to create these frameworks they are often more complete than something you would whip up yourself.
Since they do stuff you were going to do anyway, they can save tons of development time. that's why it's an important topic to be educated about. they are not just "make money commercial concepts."
Re:WTF is "infrastructure code"? (Score:3)
This is the ideal, but it doesn't always work out in practice. From what I've seen in the real world, a common thing is to adopt a framework, like Struts or J2EE, then think it isn't necessary to really study it and learn its nuances, then look confused when the application breaks and is very hard to debug due to the two or three extra layers of software. The result is a bunch of programmers pointing fingers until en
Re:WTF is "infrastructure code"? (Score:2)
Those "extra" layers of software are arguably layers that you should create yourself anyway, just to separate out presentation logic, business logic, etc. If it breaks, ideally you will have the source code, so no big deal. Either way, you should have support in the form of a community or a business. Had you rolled it all yourself, you'd be on your own.
Personally, I'd rather see someone I put to task working on solving the problem than writing and debugging new wrappers for everything they way they think
No more low-level code? (Score:1, Funny)
Re:No more low-level code? (Score:1, Funny)
I'm afraid I can't do that Dave.
Re:No more low-level code? (Score:3, Insightful)
Who are you? (Score:5, Interesting)
At least try to provide a disclaimer. Otherwise, an excellent review of a technical book published on probably the largest technical web site on the internet. Smells like fish, tastes like fish to me.
My 2c.
Re:Who are you? (Score:3, Informative)
He's some dude who works for Land's End. [google.com]
wbs.
Re:Who are you? (Score:5, Informative)
I am the author and I appologise for forgetting to put a little something about me in the review. My excuse is that I'm too humble, but who knows if you'll buy that?
I am a Java developer with Lands' End. In fact, I was the first Java developer that LE hired, and I've been with the company five years now. I have worked with Java since version 1.0 and was also responsible for the first Java program written at my previous employer (CUNA Mutual Group
I have a slight relationship with the publishing houses, in so far as they send me books. I have no connection to the authors. I get to keep the book, but there is no payment for these reviews. I am highly opinionated, so if I say that I like a book, then that's the straight dope. Check out my personal website if you want proof of my willingness to express opinions (http://www.simonpeter.com/)
Hope this helps, and I'll put in a bio next time.
Simon
Re:Who are you? (Score:1)
Actually, Lands' End (the company) is named after Land's End, the most south-west tip of the United Kingdom. The founder of the company was a transatlantic racing sailor, and Land's End is the start or finish point (depending upon direction) for most transatlantic races.
Re:Who are you? (Score:1)
Re:Who are you? (Score:2)
In some respects, I think the editors at Slashdot need to understand their power a little better. This is a popular site, and a lot of people read the articles here. With that popularity - even though Slashdot might not be considered "official" media - comes a certain level of responsibility. I believe that part of that responsibility is demanding that submitters, when there is the possibility of a conflic
Why not write your own Framework? (Score:5, Interesting)
Other groups (sitting a few feet away from us), have gone through a couple framework tools, ending up with struts.
I really don't see a difference in either approach. So many times writing your own tools is frowned upon, but when you're talking about small scale projects, why not? Do you really need every feature of struts to display a fairly simple website? A few forms, polls, etc.. why install such a massive package?
For my home machine, I wanted a couple forms, a photo album, and fairly simple navigation. I wrote it in a night. It would have taken me just as long to download the tools, install them, and set them up.
I think the problem is that it's a very "in thing" to use the latest tools. The technology lead for the other team was pushing for one open source solution before, then was pushing for struts, now is pushing for some other "cool" tool. I would rather focus on writing for what is needed, rather than for what is a cool solution.
Re:Why not write your own Framework? (Score:1)
You'll hear people argue that using an open source framework (and most are) will allow you to modify the code, but once you down the path of making changes, forget about upgrading as new versions are released...
My 2 cents
Re:Why not write your own Framework?-OSS Perils. (Score:2, Interesting)
I'm not saying the OSS are bad... I'm saying that when a system allows for a user to make changes, and I choose to take advantage of that (as an end user), that I am leaving the path of upgrades, and commiting to sticking with that version for the foresee-able future...
If I go an modify low-level (non-module) linux source code, in a particular distribution of Linux, do not submit by code changes back, then if I want to upgrade to the latest and g
Re:Why not write your own Framework? (Score:1)
Re:Why not write your own Framework? (Score:2, Interesting)
Re:Why not write your own Framework? (Score:2, Informative)
IMHO the good parts about PHP are also the bad parts. ie, * you don't have to say what type a variable is, but that means you can't specify a type of parameter to a function. * you don't have to specify scope, but then you can't protect functions that should be private etc.
I looked at a lot of Java code for ideas on what I could do with PHP to
Re:Why not write your own Framework? (Score:2)
Re:Why not write your own Framework? (Score:5, Interesting)
It is MUCH easier to find a programmer familiar with Struts than it is to find one familiar with your framework. When you leave the company, move onto other projects, or (god/allah/diety of your choice forbid) are hit by a bus your proprietary framework now must be maintained by someone else. If you had used a standard framework to do the same thing, then you can easily go out and find a programmer who can more easily step in and fill that role.
There are, of course, lots of other benefits. When your framework has a bug, it requires your time to find and fix it. One open, free frameworks it's often fixed before you even know about it. When you have lots of developers working together on a mission critical piece (the framework), then your application benefits with only a small effort from you. The whole is MUCH greater than the sum of it's parts in this case.
The only caveat to this is knowing when a tool TRULY meets your needs. I'm a PalmOS C++ programmer (a rare beast:) ) and while there are a couple of nice C++ frameworks out there, neither begins to address the level of abstraction that I desired. I could have used them, but would have spent more time fighting the framework than I would from enjoying it's benefits. So I rolled my own. If there was a framework that truly met the needs of my application, I would have used it in a heartbeat. It sounds like the problem for your 'other groups' isn't the frameworks, but their inability to accurately understand how the framework fits into their product.
Re:Why not write your own Framework? (Score:2)
I think the risk of established frameworks, the trade-off, is that they are not going to be optim
Re:Why not write your own Framework? (Score:2)
How's that road to hell coming?
Re:Why not write your own Framework? (Score:2)
In my defense, I do revisit things pretty much every day and comment out *something* or clarify the code better. In my current situation, that's the appropriate use of time, because I only have 2 other developers relying on this code base, and they already know it pretty well. I try not to envision the "getting hit by a truck scenario", since I'm a firm believer that you always get exactly what your thoughts dwell on (*)
(*) except for t
Re:Why not write your own Framework? (Score:2)
It should be stressed that frameworks are most helpful when they are open-sourced. Fixing the bug first and, then, notifying the maintainers later is something that really saved my ass once.
Re:Why not write your own Framework? (Score:1)
Only if you're willing to stay on the bleeding edge.
I am a developer at one of the web's busiest sites. If we were to incorporate a framework, it wouldn't be very long before our unique requirements (some legacy-driven, some traffic-driven) would require a code fork.
There are many reasons why a framework is a useful addition to the codebase and just as many reasons why it is not.
Re:Why not write your own Framework? (Score:2)
I wrote my framework because at the time, there wasn't anything out there that was decent and fit my thoughts and opinions about "how it should be done". So far, it's wo
Re:Why not write your own Framework? (Score:2)
Our library (it was "mine" once but now it is a shared effort of about 4 developers in a group of 30) does about the same as struts, and also contains custom tags. It is not configured by ugly xml files though, but 100% based and focussed on JDBC.
The library itself was a relatively small effort, and it pays back because it is totally tailored to our needs. The project is large enough to justify the
Re:Why not write your own Framework? (Score:4, Informative)
It was one of the overlooked disasters.
Things looked pretty good for the first year or so when the requirements were straightforward and the persistence mapping quite simple. As the product grew the frameworks we built got very complicated very quickly and everything we built was in some form available in other products. Maybe there wasn't a one for one feature match but I think the small discrepancies absolutely did not justify the effort spent on building your own application framework.
Why anyone would build a persistence layer when Toplink and Hibernate are both excellent tools which will almost certainly outperform homegrown solutions.
Same with struts. We built our own struts-like framework with our own tag libraries and our own templating engine. Now we have to have people dedicated to maintaining that stuff all the time and at least keeping pace with the popular frameworks.
Re:Why not write your own Framework? (Score:1)
On the other hand, it can have MAJOR downsides. If the technology choice is wrong, or if the dvelopers are not quite up to the task (despite protestations to the contrary), things can go quite horrible.
At the company I work for, a couple of guys were given the job of building a development framework for building ALL internal infrastructure applications on. For some, utterly u
Re:Why not write your own Framework? (Score:2)
Rolling my own... (Score:1, Interesting)
Re:Rolling my own... (Score:1, Funny)
I smoke GNU/Pot that I roll myself.
Re:Rolling my own... (Score:1)
So I wouldn't say it was 'simpler,' but definantly more fun. :)
Re:Rolling my own... (Score:4, Insightful)
You get to be Da Man who gets called at 3am when one little thing you forgot brings the whole shebang down. You get to be Da Man who gets to enhance it for every little niggling request from your fellow coders. You get to be Da Man who has fingers pointed at him first, then find out later somebody's app didn't follow your rules. You get to be Da Man who meticulously documents it, so they know those rules.
You get to be Da Man who can't take vacation or call in sick.
I gave up my desire to be Da Man some time ago.
Garg
Did you actually read the book? (Score:4, Insightful)
That being said. Java's frameworks tend to be very high quality and easy to work with in my experience.
Useless (Score:5, Interesting)
Are we talking GUI frameworks, JSP Engines, Web application frameworks, what?
This "review" told me nothing.
Re:Useless (Score:1)
Which frameworks are covered (Score:4, Informative)
Avalon, Cocoon, Expresso, Arch4j,
ArsDigita ACSJ, Turbine,
Wakesoft Architecture Server, Niggle
Systinet's WASP, realMethods, Brazil
OpenSymphony,
JSF (not quite a framework per se, but covered),
Struts, Maverick, Scope, WebMacro,
Velocity, Tapestry, Barracuda, HyperQbs,
Tea, Freemarker, Echo, Xerces, Xalan,
Axis, Slide, Roaming Wireless Framework,
JADE, Openadaptor, JUnit, Anteater,
Jetspeed, OpenPortal, uPortal, Simper,
Object/Relational Bridge, Castor,
jRelational, Batik and Keel,
along with mentioning more briefly a lot of others.
(disclosure: I'm the author - of the book, not the review - so opinions may be biased
Mike
Re:Which frameworks are covered (Score:3, Interesting)
I'm curious though, why you lump everything together under the word 'framework.' To me, framework implies a particular programming model that must be maintained. So JUnit is indeed a framework, though it doesn't at all compare directly with Struts, a framework with a completely different purpose. When I looked at the table of contents, I expected to see some sort of classification scheme.
And things like Xerces I wouldn't class as a framewor
Re:Which frameworks are covered (Score:2, Interesting)
I thought Xerces was just a tool/API as well at first, but with bit of digging I found it actually is more of a framework, with pluggable implementations, a component structure, several different APIs, etc. That's why I though
framework, insfrastructure and other buzz words (Score:4, Insightful)
And lately, I have started looking at Java as a corporate-hep buzzword too, not to mention .NET, and a hoarde of other ones.
Whatever happened to the concise, well-written, to the point books of a few years ago. Kernigan/Ritchie's C book comes to mind, though it was a C Reference Manual.
Re:framework, insfrastructure and other buzz words (Score:2)
Amen, brother. I spend as much time sifting through useless books as I do reading useful ones these days. K&R was wonderfully direct. Even the nutshell books aren't that direct anymore.
Devon
Hard to keep track (Score:5, Insightful)
I find myself in a rather ironic position now. A few years ago I was a strong proponent of frameworks. I saw no reason why essentially the same code should be rehashed slightly differently when a framework could be made of the core material and the rest customised as required. Now I have to press the pause button when a framework is put forward to determine if it suits our requirements or is complete overkill for what we need or forces us into an excessively complex architecture to facilitate it.
While still in favour of frameworks I believe you can have too much of a good thing. I think many frameworks available today ignore the "frame" part of the concept and actually try and fill in all the code for you.
Re:Hard to keep track (Score:2)
Aside from the app server, we never used all these fancy frameworks.
Standard frameworks not always the answer... (Score:1, Interesting)
So we rolled our own. Since java has interfaces, built in rpc, threading, and db-independant DB accesss, and most IDEs support some refactoring, it was pretty easy. Except for that cla
One man's framework is another's prison (Score:2)
What I've found that often works far better is:
- divide system into major business-oriented (vertical) sub-systems (assemblies, whatever). Examples of these sub-sytems would include 'party', 'inventory', 'order', etc.
- if possible build these sub-systems using highly adaptable code or based upon well-conceived patterns
- glue the assembles together using a highly productive / adaptable language - python, etc.
If
Low Level Java (Score:5, Funny)
And all this time i've been writing all my bytecode with a hex editor, like a sucker.
Re:Low Level Java (Score:2)
Well, what's even funnier is that this is pretty much the exact same thing people said about Fortran and, then, C.
When people say things like "finally you don't need to write low level code," they are really advertising how ignorant they are about software engineering and history.
Re:Low Level Java (Score:1)
I can't stand hearing people say this as well...
Inspite of all these great frameworks that are poping up everywhere... You still need to understand how the code works inorder to utilize it properly.
Yeah Frameworks are Great (Score:2, Insightful)
I'll say
Re:Yeah Frameworks are Great (Score:2)
While I don't quite agree with If your web-app is so complex as to need a framework, your web-app probably sucks, since even a simple bank-balance application can benefit from a good framework.
However, I'm afraid that the backlash may take much longer to arrive (and we'll be stuck coding in the ghastly web-app universe for aome time). The reason is that kludge after kludge will be layered on top of the browser (Sparkle, anyone [slashdot.org]) as an attempt to "get by".
Re:Yeah Frameworks are Great (Score:3, Insightful)
Second, what's wrong with Javascript? It is very useful in a web app. Field validation, UI enhancement, etc.
Third, I think you are ignoring all of the benefits of deploying a web app VS a standalone application. Such as support (much simpler IMH
Re:Yeah Frameworks are Great (Score:3, Insightful)
JavaScript would be great if you could count on it being implemented correctly on every browser. That goes for a lot of browser features. Browsers were never intended for the UI work they're not being used for. If I have to implement a heaping helping of UI code in JavaScript, why not just go back to C and do it using a protocol where I can actually maintain the state of my application from moment to moment?
I am not ignoring all the benefits of deploying a web app Vs. a standal
Re:Yeah Frameworks are Great (Score:2)
Re:Yeah Frameworks are Great (Score:1)
Re:Yeah Frameworks are Great (Score:5, Insightful)
I spent 1 month looking at all the enterprise level technologies out there (You know... anything with distributed transactions, RMI of some sort, and security infrastructure). I spent 3 months learning J2EE. I spent 3 months looking at different frameworks. I eventually decided to go Web-Start. I really really wished there were books that compare the technologies out there based on performance, popularity (increases the number of jobs you can work at and the number of employees you can pick from), and time to completion (ease of use). Java almost has too much choice.
Here are some questions that should make my point.
How do you want to access your data?
JDBC, JDO, Hibernate, CMP, or some weird object-database?
What reporting package do you want to use?
Custom (using iText, FOP, or just plain AWT to the printer?)
JasperReports
JFreeReports
or one of the plethora of commercial packages?
What kind of client do you want?
HTTP, Web-Start, Standalone, or SOAP to Mozilla or
If you go HTTP, what web framework do you want to use?
JSP/Servlets directly, Struts, WebWork, or some conjured up Velocity template?
If you go Web-Start or Standalon, what GUI TK do you want to use?
SWT, Swing, Thinlet, Luxor, Swixml, AWT (for 1.1 compatibility), etc.
Do you want MiddleWare? What kind?
Session Beans, Message Beans, Message queue's and some custom apps... with or without SOAP? Would you like a nice XML-RPC to go with that? Maybe you want something a bit more network centered like Jini? Maybe you have to work with some old CORBA software.
Oh, BTW, what operating system do you want to run it on? (Linux, Mac, BSD, Unix) What application server? (JBoss, Jonas, Pramati, WebSphere, WebLogic, SunONE, JRun, Resin) What database server? (MySQL, PostgreSQL, Oracle, DB2, McKoi, Hypersonic, Firebird, MS SQL) What JVM? (SUN, IBM, JRocket) Do you need charting for your reports? (JFreeCharts, bah... just search google for java charting)
My head hurts now, and I want to cry. When someone ends the madness, please wake me up and tell me what year it is, and which packages I should use, because if I look at them all, by the time I'm done, I'll have to start all over.
Re:Yeah Frameworks are Great (Score:2)
http://jakarta.apache.org/commons/net/apidocs/i n de x.html
Is the documentation.
A peice of advice for anyone that can't find an API that does what they want in Java: Go to jakarta.apache.org. Anything you can think of is there, and it's under the Apache License so you can use it anyhow you want.
Anyone who wants to do full text indexing should try Lucene. It's faster than any other indexer (I've tried them all, even the C cod
turbine (Score:2, Interesting)
thanks.
Re:turbine (Score:2)
i'm working on a turbine based project right now. the framework has some good concepts (services, user management, security), but the project organization is seriously lacking discipline. things don't always work as advertised, and if you're building a large-scale app, be prepared to dig into the turbine source and do some hacking.
there's also an issue with turbine 2.3's (latest/greatest) choice of build systems. you are required to use maven, a project management tool built on top of ant, and that proj
Re:turbine (Score:1)
Sample chapter (Score:4, Informative)
Unfortunately, like the 'review' - it doesn't mention which frameworks the book covers though.
Application frameworks vs webapp frameworks (Score:5, Interesting)
The problem is that technologies change over time. Tech-oriented frameworks make writing the app easier in the short run, but they don't consider the long-term life of the app. Applications that are tightly coupled to any given tech become a liability as that tech ages, and quite often migration to a new tech involves a ground-up rewrite of the application. Instead of tying the app to a framework like Struts or a tech like EJB, write the app to stand on its own, using interfaces to the various techs it needs. Particular technologies like Struts (for a web UI) or EJB (for persistence) can be swapped in + out of the application as necessary without changing the function of the application itself.
There are a number of benefits to a technology-agnostic approach like this. The technology implementations can be upgraded: find out that EJB is a dud? Switch to Hibernate! Perhaps more interestingly, the technology implementations can be supplemented: Have a web UI, but need to ship a desktop application too? Plug in the desktop app tech implementation and presto! You now have both a web UI and a Swing/SWT/etc UI for the same app. Testing becomes far easier too, because you have clearly defined boundaries between the different components of the app (so it's easy to figure out which part isn't behaving).
There are drawbacks, of course. To work as advertised you need to invest a fair amount of architecture to get such a system off the ground. Someone has to write the tech implementations, as well - an SWT UI for your app won't just fall out of the sky when you want it.
Everyone has their pet project. Mine is Sandboss [sandboss.org], an approach to enterprise application development that's application-centric, not technology centric. It concentrates on the app itself - you don't wind up with a "Struts application" or an "EJB app". Instead you wind up with an application that can use Struts and EJB, but can also work with Hibernate and WebWork. It's not for everyone - it requires a fair amount of committment to the methodology - but it works well in practice. The time savings are pretty incredible, and the components really are reusable.
*There are many places where a front end for a database is all you need. Of course, once the requirements for that project start to grow you'll wish you had something more powerful.
Re:Application frameworks vs webapp frameworks (Score:2)
Re:Application frameworks vs webapp frameworks (Score:2, Interesting)
So which Framework won? (Score:1)
Personally I prefer the Framework provided by J2EE. It seems most frameworks just add a redundant layer on top of that, repeating the same functionality.
It's been a while that I took a look at Struts, but what's the main advantage of a Struts Action over a Java Servlet? I think they are actually both meant to do the same thing. As far as I remember, the Struts Actions even get the HttpServletRequest passed as a parameter.
Re:So which Framework won? (Score:1)
Re:So which Framework won? (Score:1)
Re:So which Framework won? (Score:1)
I think none, and I'm quite sure it won't work -- you human paraquat!
Re:So which Framework won? (Score:1)
frameworks rule (Score:2)
Every new body on the team gets to sit and read the Struts book - it takes govnt weeks to get you a PC and months to hook it up.
But the application they eventually get to work on is a terrible mess of logic-laden JSPs, clueless beans and stored procedures doing String manipulation.
If it doesn't include Open for Business (Score:1)
Pasta Sauce Analogy ( and opinion - obviously ) (Score:1)
When I cook pasta, and I am in a hurry, or I don't care if it tastes a little different to how I want it to, I buy a jar of premade pasta sauce.
When I am cooking for a special occasion, I wouldn't even dream of it. I know how to make a killer sauce, so I can make my own from scratch. The taste is always tailored to the occasion when I do so. The only other consideration is that it takes longer.
Curry
On the other hand, I do not know how to make curry from scratch. Thus, no matter what the sit
bad review (Score:2)
General Frameworks Often Suck (Score:2)
The problem with general frameworks is that they are often too general. The wave of the future is going to be business specific application / database servers that are stitched together with open messaging schemes.
So, instead of having one general framework with a middle tier in some webish / code combination talking to a SQL server, you'll have a messaging bus that stitches together various domain specific database servers.
Re:No more low-level code ? Hum... (Score:4, Insightful)
Re:No more low-level code ? Hum... (Score:1)
So, yeah. It's a hot button. But the leader text was misleading. Many journalists do it, but that doesn't make it OK.
Re:No more low-level code ? Hum... (Score:3, Informative)
Re:No more low-level code ? Hum... (Score:5, Insightful)
Please please tell me you aren't writing web application frameworks to be served from your handheld devices.
Obviously, the guy that submitted this story doesn't know about handheld devices and embedded software.
The poster didn't imply that no-one will ever have to write low level code again. He said that you shouldn't have to in this specific context, which is web application frameworks. Of course there will be other areas where low level code is still quite neccesary, no-one said otherwise.
Re:No more low-level code ? Hum... (Score:2, Insightful)
It seems there is a huge blind spot concerning "the rest of the code". Not everyone is coding web pages and Java/.NET commerce systems! What about the applications like MS-Word, Mathcad, Compilers, or BitTorrent. OK, the last example is written in Perl which is not really a low-level language but it is certainly not a framework like
Not Perl (Score:3, Informative)
Re:Not Perl (Score:1)
However... is the number of serious programmers who prefer Python larger than the number of serious programmers who prefer C/C++? By serious, I mean the number of people who would contribute meaningful improvements.
I'm not trying to flame python programmers here. But there seems to be a LOT more C and C++ programmers than Python programmers. After all, most of the software I see on the internet is written in C. BitTorrent is an exception rather than the
Re:Not Perl (Score:2)
Re:Not Perl (Score:2, Funny)
Bollocks Bollocks Bollocks. As someone who has recently started working with a large code base in Python, I can assure you it is possible to write unreadable code in python.
Having Readable code depends entreily on the programmer who wrote the code and very little on the language they use.
Re:No more low-level code ? Hum... (Score:2)
And, while this book is about frameworks, not languages, your concept of "low-level languages" seems a bit confused. Your example applications could all be written in Java or some other high-level language of your choice. Take a look at the Eclipse Java IDE which is written entirely in Java (minus the backe
Re:No more low-level code ? Hum... (Score:1)
The intent I was trying to communicate was that the existing framework is not always sufficient and that working around the limitations may cost just as much or more than the savings gotten by using the framework. I was using the term "low-level" to denote programming environments with less of a predefined support st
Not just little devices (Score:5, Insightful)
Often these frameworks ("always" in the case of middleware) will add not just overhead (latency or burnt CPU cycles) to your system, it can add complexity. When given the choice of incorporating some already existing framework, or re-inventing the wheel, I often (but not always) choose to re-invent the wheel.
See, I will end up with a wheel that I know. A wheel that spins like it should, and doesn't spontaneously start brewing coffee, because someone thought that would be a great idea.
Some are religiously against re-inventing the wheel. But hey, the wheel is a well known technology, it is not necessarily very difficult to re-invent it. This amount of work, compared to the long-term implications of being dependent on something that you do not "own", make a little re-invention here and there well worth it.
Earlier on slashdot today you saw ATMs being hit by an RPC worm. Why is an ATM vulnerable to an RPC worm? Because it runs RPC. Why does it run RPC? Well, because nobody re-invented the little wheel it would have been to do a simple data transfer over a TCP connection. No, they chose either to use RPC, or to use a significant amount of middleware which did not allow them to disable RPC (otherwise, why would it have been enabled?).
If people feared re-invention a little less, and once in a while re-wrote that darn wheel instead of relying on frameworks and middleware that they cannot possibly hope to fully comprehend, you would not have ATMs being hit by RPC worms. Ximian Evolution would not take up hundreds of megabytes of memory. Web sites would not mysteriously hang if the MS ASPX interpreter got stuck. My PHP sites would not start giving load errors on every 5% of the hits after a bad call to a file load routine half a decade ago.
The world would be a better place.
Now go re-invent, please.
Not just little devices-Dark Ages. (Score:1, Insightful)
Computer Science will never mature as a discipline as long as is NIH is so prevalent. It's not a cool, but then building anything has "not cool" elements.
Re:Not just little devices-Dark Ages. (Score:5, Insightful)
A standard fastener like a bolt has probably less than a dozen parameters to worry about. Things like length, thread pitch, diameter, head shape, alloy strength, etc.
If instead, each standard bolt was like a software component and had an API with thousands of parameters to worry about, you can bet that the architects would consider having simpler custom designed bolts machined for each project that match the unique requirements of that job.
Re:Not just little devices (Score:1)
Yes, you're right. Frameworks can add complexity and overhead. But they also provide for rapid app development, common functions, and a shorter learning curve. The reason I found it frustrating to work in Java in the beginning was because I had to re-invent the wheel everytime. I use to do the same in other languages, until I got pissed off and began writing my own frameworks. I never got to work in Java enough to do one for it, but anything would have been better then progr
Re:Not just little devices (Score:2)
I see what you are saying, but sometimes, even a wheel is complex.
Re:Not just little devices (Score:2)
--
Re:Not just little devices (Score:2)
This will really wack your mind...
Early on in my career here (7 months ago) I asked why we would be so bold as to develop our own webserver and not use apache (after all, we aren't in the webserver business) and I actually got yelled at. "It's way more secure if we write it" they screamed. I laughed inside, especially now that I have scene the code.
One guy suggested the use of signal handling in our app. This made o
Re:Not just little devices (Score:2)
There are a handful of people in the world who are actually are capable of coding a secure web server and, no offense, but I doubt they work for your employer.
Good luck!
Re:Not just little devices (Score:2)
Oh well. Good idea though, it might work were rationality is practiced!
Thanks!
Re:Not just little devices (Score:3, Funny)
Why is an ATM vulnerable to an RPC worm? Because the people who made the ATM were dumb enough to run it on Win2k, which was running DCOM _by default_
Re:Frameworks are for wimps (Score:1)