Slashdot Mirror

Ward Cunningham calls it technical debt. It's what you accrue when you don't mercilessly simplify the design of your application every time you check in.

http://www.martinfowler.com/bliki/TechnicalDebt.ht ml

Thanks for the links. IMHO, only the last one is coherent. To abuse on old joke around here, in Soviet Russia, frameworks call you.

What Spolsky (and everyone here) is complaining about isn't really about frameworks versus libraries but more about heavy weight versus light weight. Frameworks can get heavy because they tend to combine lots of functionality in a way that introduces a lot of dependencies, thus increasing coupling (which, in software engineering, is a bad thing). That's where the feeling of having to deal with a lot of stuff that you don't care about comes in. A lightweight framework tends to chunk all this complex functionality into a set of relevant services then uses Dependency Injection as the plumbing to connect the services together. A really great book on this topic is Better, Faster, Lighter Java.

First let me disclose I that I have worked with Java web apps
using Kiva, JRun, ATG Dynamo, Tomcat, Websphere, Spring Framework, JSEE. I have
also worked Perl+CGI, a smattering of cold fusion, plain old php,
drupal, cakephp (rails like php framework).
I am currently working on deploying a rails app.

So what is my take on Ruby/Rails?

Briefly here are the pros/cons as I see it:

pros:
    1) Ruby feels good to program in. Like Perl,PHP, or LISP you can
    layout data using the language itself. So unlike Java you don't
    find yourself needing XML to configure everything.

    2) Ruby is dynamic. Nothing new here. But this allows you to
    "build up" the language to support your problem domain. Sure,
    Java supports this to some degree, but it is much more
    complex and verbose - where in Java you might need dynamic
    byte code insertion in Ruby you just open up a class and "do it"

    3) Rails was "extracted" from a real life web application - not designed
    by a committee. The bottom line is that you find lots of support for
    "things" you are likely going to want to do in your application. You find
    that many of those "easy", "i can do it in a few hours/days" sort of things
    have already been taken care of for you.

    4) Rails is opinionated. It lays out your directory structure for you, It
    likes you to obey certain naming conventions. What is good about this is that
    a) you don't have to think about these things b) less experienced people get a
    decent skeleton MVC architecture to work with.

  Cons:

  1) The Ruby libraries have no where near the depth or maturity of what you find
  in Java. This is improving, but in a high stakes enterprise environment where
  from one day to the next you never know what you might be asked to integrate with
  this is definately a consideration.

  2) Rails works best with new applications where you have control over the database.
  If you can't control the database schema or it is already in place you can possibly
  bend Rails to work for you...but trust me, there is no 15 minute screencast that is
  going to hold your hand.

  3) Rails is (by all indications) not a framework that caters
  to enterprise users. You can take that however you like - this makes some people giddy -
  For others it gives pause. See http://www.martinfowler.com/bliki/EnterpriseRails. html for
  a perspective on this.

  4) Ruby's runtime environment is evolving. Most people seem to agree that Ruby needs a VM (
  these are under development). Also Sun has a few guys working JRuby - Ruby compiled down to
  java bytecode. But these aren't production ready.

  5) Rails uses the ActiveRecord pattern for ORM. In a nutshell, the further your domain objects
  diverge from their representation in the database the more likely Rails is not going to work for you.

In the end, it comes down to selecting the right tools for the job. Where you have a new app, time to market
is critical, and budget is small then Ruby/Rails can be a great tool. Where you have a complex domain, existing
database, and the need to integrate with all sorts of exotic systems or middleware you might want to look elsewhere.

First off, you should be practicing TDD (Test Driven Development) as discribed here: http://en.wikipedia.org/wiki/Test_driven_developme nt as
  well as Continuous Integration as discribed here: http://www.martinfowler.com/articles/continuousInt egration.html.

The next thing you need to do is hire some testers. TDD and CI can help make fantastic improvements in the quality of your code, but you will never replace the time and effort of another human working to break your code.

Two of the greatest rallying cries in XP are the slogans "Do the Simplest Thing that Could Possibly Work" and "You Aren't Going to Need It" (known as YAGNI). Both are manifestations of the XP practice of Simple Design.

The way YAGNI is usually described, it says that you shouldn't add any code today which will only be used by feature that is needed tomorrow. On the face of it this sounds simple. The issue comes with such things as frameworks, reusable components, and flexible design. Such things are complicated to build. You pay an extra up-front cost to build them, in the expectation that you will gain back that cost later. This idea of building flexibility up-front is seen as a key part of effective software design.

However XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let these structures grow as they are needed. If I want a Money class today that handles addition but not multiplication then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'll still leave it till that next iteration.

One reason for this is economic. If I have to do any work that's only used for a feature that's needed tomorrow, that means I lose effort from features that need to be done for this iteration. The release plan says what needs to be worked on now, working on other things in the future is contrary to the developers agreement with the customer. There is a risk that this iteration's stories might not get done. Even if this iteration's stories are not at risk it's up to the customer to decide what extra work should be done - and that might still not involve multiplication.

This economic disincentive is compounded by the chance that we may not get it right. However certain we may be about how this function works, we can still get it wrong - especially since we don't have detailed requirements yet. Working on the wrong solution early is even more wasteful than working on the right solution early. And the XPerts generally believe that we are much more likely to be wrong than right (and I agree with that sentiment.)

The second reason for simple design is that a complex design is more difficult to understand than a simple design. Therefore any modification of the system is made harder by added complexity. This adds a cost during the period between when the more complicated design was added and when it was needed.

Now this advice strikes a lot of people as nonsense, and they are right to think that. Right providing that you imagine the usual development world where the enabling practices of XP aren't in place. However when the balance between planned and evolutionary design alters, then YAGNI becomes good practice (and only then).

So to summarize. You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to it because it increases the cost of modification even if it costs nothing to put in. However you can only sensibly behave this way when you are using XP, or a similar technique that lowers the cost of change.

Martin Fowler has written a few words on the subject Is Design Dead?

Highly recommended, grab a cup of coffee ...or two ;)

This looks really interesting: Adam and Eve
Has Anyone tried it out ?
It looks like they take the approach of using a domain specific language for building the GUI.

Simon.

I wholeheartedly recommend this Martin Fowler's article to start with.

Yes, that is true. Find the new job before quitting the old. Personal and professional growth is absolutely a part of the decision criteria for selecting and staying with a job. The fact that it has taken the original poster years to figure this out does not say anything positive about his or her drive.

Read some books. Here are some recommendations.

• The Practice of Programming by Kernighan and Pike is an all time classic. This one is my strongest recommendation.
• Is object oriented programming the next step for you? Here is a classic by Grady Booch.
• I find Martin Fowler to be a great author on next step kinds of topics for software developers.
• Are design patterns the next step for you? The original GoF book is my recommendation.
• Are relational databases your next step? My favorite book on this subject is a LAN Times Guide to SQL.
• Is the next step to be a team lead? Then you should really read Code Complete by Steve McConnell.

See http://www.martinfowler.com/bliki/C3.html. Sounds to me like your on the right track.

I was recently reviewing a software design document that correctly paid much-needed attention to the objective of supporting configurable behavior. As opposed to simply documenting how the design would accommodate said configurability, the design description also included the following commanding statement a number of times: "The configuration data will be stored in XML." I

It only sounds like that if you skip the important parts.

Agile methods are not about skipping requirements, or modeling, nor about coding in a casual or non-deliberate way.

Agile methods are about recognizing that requirements are a moving target, That the more you implement your solution, the better you will understand the model, and possible problems with your model of the problem domain, and that the best program on earth is worthless if it doesn't work for the end users.

So, there's a large collection of techniques that most programming veterans (OO or otherwise) utilize to help get things up and running without having to send anyone "over the waterfall."

Check out Dave Thomas and Andy Hunt, Martin Fowleror the Portland Pattern Repository for a good starting point.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

I wish you guys still in school or freshly graduated knew how often the rest of us roll our eyes every time we hear "my thesis" or "my prof". Your college education will be of marginal vaule to you as a programmer. Most of what you use will be from experience gained after you graduated. You won't necessarily be a good programmer just because you made good grades either.

However, I really don't like OMG's MDA. There's an article on the Web by David Frankel that explains very well why UML isn't quite up to the task (see http://www.bptrends.com/publicationfiles/01-04%20C OL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf, and see also http://www.martinfowler.com/ieeeSoftware/mda-thoma s.pdf).

I have an immense amount of professional respect for Martin Fowler. I'd like to qualify some of his and others informed statements about MDA and UML. There are a number of folks out there that tend to take casaul connections to the extreme (i.e. what works for some will work for all). I beleve that Martin was trying to guard his hearers against such thoughts. I think what he meant was that UML in it's entirety is not declarative enough (or just plain flexible enough) to serve as the sole language by which to holistically describe computer programs. This is an easy pill to swallow, because in fact, UML (plus OCL) is (in my humble experience) declarative enough to at least describe the entities of a system, the roles they play, their values, and the relationships betweent them. I wouldn't push for more however... really... I don't even see a benefit.

What makes *that* example usable or unusable however, really boils down the implemenation of the given MDA tool.

I for instance have had great success with a tool called AndroMDA. The code it generates is quite well formed and organized. I am so happy and impressed with the code it generates that I have actually learned a few things just by reading the generated code. This is a far cry from the "yuck" days of Rational Rose 1.0.

However, I really don't like OMG's MDA. There's an article on the Web by David Frankel that explains very well why UML isn't quite up to the task (see http://www.bptrends.com/publicationfiles/01-04%20C OL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf, and see also http://www.martinfowler.com/ieeeSoftware/mda-thoma s.pdf).

This is not to say I fully agree with Microsoft's DSL and Software Factory concepts. I certainly see more debate is needed. In a sense, MDA is bad because I feel it will stall the debate, as vendors rush to implement their tools around a model some considered flawed, and a great many just plain hard to use in practice.

Haha you make me laugh.. vs.net is like being in the stone age. Take a look at intellij idea .. or even eclipse even though i prefer the first. http://www.martinfowler.com/bliki/PostIntelliJ.htm l Even Jbuilder6, years ago was a better IDE than vs.net 2005 is today... i hate every time i have to work with it.. it doesnt have half the features that most Java IDEs do.. and the ones it does have is poorly implemented compared to most Java IDEs.

For you I'd recommend GME (read the tutorials first) and finish up with Martin Fowler's Language Workbenches

Then I would recommend a DSL and an appropriete support environment(PDF)

• design optimization
• creative design
• the creation of art
• artificial life forms

I understand it, but only because I already know this stuff.

A better article to start with is: Inversion of Control Containers and the Dependency Injection pattern, by Martin Fowler. It's older than the one mentioned in the story, but still relevant.

1. write unreadable code
2. write unreadable code, but try to comment it readable
3. write readable code

Example:

1. if (uFileHeader & 0xFF1234)
   
   
2. if (uFileHeader & 0xFF1234) // check if the file header is valid
   
   
3. #define VALID_FILE_HEADER 0xFF1234
   ...
   if (uFileHeader & VALID_FILE_HEADER)
   
   

This second way is the same as Martin Fowler in his book Refactoring refers to as writing comments as using deodorant to cover up that the code stinks. This is a great book, highly recommended. The Pragmatic Programmer is also very good (I have not read the two other books mentioned in the parent post).

As a rule of thumb (in my personal experience), the majority of all one-line comment are deodorant.

Note that even though the comment by itself might be enlightening and add (even great) value to the code (like "// check ..." above), the code is "always" better of if what the comment expresses is incorporated directly into the code instead.

One way to increase the quality of comments is to literally put a price tag on them. If you were to pay a consultant to insert the comment, how much would you be willing to pay him/her? Use a 10-based scale, say $100, $10, $1, 10cent (and also consider the negative side of scale, i.e. if a given comment exists, how much would you pay him/her to remove the comment?). Then remove all comments below a given value, say $1.

How many of you could have argued that spending say $1 to add the comment below would be a good investment?

while (! feof(stream)) {
do();
what();
ever();
with();
the();
file();
} // end while

On the other hand, you might sometime stumble over great comments that you could defend spending $100 to get written if they did not exist (these are multi-line comments/stories perhaps on the form "We tried earlier to do things in such and such way but that did not work out very well because of whatever. An besides blah blah..." or something similar. ).

I often complain about comments written by my colleagues so I have a reputation of being opposed to writing comments. But I am not against writing comments; I am against writing valueless comments.

--
When comments lie about the code, both are probably wrong.

Ruby on Rails is now a supported platform at ThoughtWorks! (home of Martin Fowler)

Osty, you have poor reading comprehension. You're attacking exactly the opposite of what I was saying. Go back and read my message you're replying to more carefully, and while you're at it, read the article and watch the video so you'll be more qualified to participate in the discussion.

My point is that SQLObject does insulate you from SQL injection attacks and database dependencies, in ways that Ruby's ActiveRecord does not.

Of course you're ignoring the problem of database portability, because the hammer you want to attack all problems with seems to be stored procedures. If the goals are database portability and database application programming with a scripting language like Python or Ruby, then your hammer breaks the original goals, so it's the wrong hammer. I want to integrate my existing Python code with the database, not rewrite it all as stored procedures -- that would make no sense whatsoever. If I wanted somebody to tell me to write database dependent code, lock myself into the biggest database with the most features, and give up my scripting language of choice, then I'd call Oracle, bend over, and do exactly what they told me. But I'm not that massochistic.

Here is a typical snippet of Ruby/ActiveRecord code, and you can clearly see that it has SQL code written in as quoted strings (sorry about the indentation -- slashdot is now ignoring nbsp's as well as pre's, which makes it hard to discuss code):

def self.authenticate(login, pass)
find_first(["login = ? AND password = ?", login, sha1(pass)])
end

Here is the equivalent Python/SQLObject code, which you can see uses Python syntax to accomplish the same thing, without quoting any SQL code at all:

def authenticate(self, login, pass):
return User.select(AND(User.q.login == login, User.q.password == sha1(pass)))[0]

This is accomplished with the "SQLBuilder" utility, that lets you write python expressions like "AND(person.q.first_name == 'John', person.q.last_name == 'Doe')" instead of raw SQL expressions like "(person.first_name = 'John' AND person.last_name = 'Doe')".

SQLObject also supports methods called "startswith()" and "endswith()" and a function called "LIKE", which insulate you from the differences between SQL "LIKE" syntaxes, so you can portably write "User.q.firstName.startswith('X')" instead of "User.firstName LIKE 'X%'".

Of course the 15 minute Ruby on Rails demo didn't get deep enough into programming a complex web application, that they had to show you any of the SQL dependencies and other warts of Ruby on Rails. They're evangelizing, not airing dirty laundry -- what do you expect?

SQLObject and ActiveRecord are based on a lot of the same ideas (Martin Fowler's Active Record model), but SQLObject is also different than ActiveRecord in many ways. Ben Bangert's compares SQLObject and ActiveRecord in his talk, "Presentation on SQLObject & FormEncode", that he gave at the Bay Area Python users group.

SQLObject is a pure ORM (Object-Relational Mapper), while ActiveRecord is a full fledged Model (as in MVC). Both SQLObject and ActiveRecord let you automatically read in an existing database schema. But SQLObject also lets you define the schema in Python and automatically generates the tables (for any database) from the Python declarations -- it works either way! SQLObject also supports runtime column changes, so it can be used to implement dynamic database schema editors.

-Don

There's your problem -- you're mixing SQL code in with your app code. Bad developer! Bad! You're introducing SQL injection holes

Python (and other sane languages) use something like query("select * from foo where name = %s", (name,)) (SQLObject gives this a different syntax, but same idea). With this, if you forget the substitution or do it incorrectly it will be Completely Broken -- because you'll be sending a query like select * from foo where name = Tom. This is a good poka yoke.

As far as putting SQL in the code, sometimes a query is best expressed at the time you will use it. If you want all customers in an area code, is it really best to make a customersInAreaCode(areaCode) method, or just use Customer.selectBy(areaCode=X)? They look pretty much equivalent to me -- except the latter comes for free, and is completely localized to the place you use it. That localization is a negative if it means you are duplicating code; however, creating an abstraction before any duplicate code would be created is also a negative.

As far as the other issues: SQLObject uses the Active Record model (which Rails' ActiveRecord happens to be named after) and is best suited to Application Databases. There are pluses and minuses to this. You can often use a mixture of both styles, if you find a need. But if you are an organization of web developers without dedicated database personel and with a tight schedule, you will be best served by the Application Database style of development, because (from a developer's point of view) it gives you the most control.

There's your problem -- you're mixing SQL code in with your app code. Bad developer! Bad! You're introducing SQL injection holes

Python (and other sane languages) use something like query("select * from foo where name = %s", (name,)) (SQLObject gives this a different syntax, but same idea). With this, if you forget the substitution or do it incorrectly it will be Completely Broken -- because you'll be sending a query like select * from foo where name = Tom. This is a good poka yoke.

As far as putting SQL in the code, sometimes a query is best expressed at the time you will use it. If you want all customers in an area code, is it really best to make a customersInAreaCode(areaCode) method, or just use Customer.selectBy(areaCode=X)? They look pretty much equivalent to me -- except the latter comes for free, and is completely localized to the place you use it. That localization is a negative if it means you are duplicating code; however, creating an abstraction before any duplicate code would be created is also a negative.

As far as the other issues: SQLObject uses the Active Record model (which Rails' ActiveRecord happens to be named after) and is best suited to Application Databases. There are pluses and minuses to this. You can often use a mixture of both styles, if you find a need. But if you are an organization of web developers without dedicated database personel and with a tight schedule, you will be best served by the Application Database style of development, because (from a developer's point of view) it gives you the most control.

If you spend a lot of time coding in Java, take a look at any of the popular blogs at jroller.com.

Take a look at the blog aggragation of all the speakers from the No Fluff Just Stuff coference series (www.nofluffjuststuff.com) - disclaimer: I'm one of those speakers.

If you read Dave and Andy, you will also want to read Mike Clark:
http://www.clarkware.com/cgi/blosxom/index.rss

Martin Fowler's Blog:
http://martinfowler.com/bliki/bliki.rss

The Daily WTF has some great examples of horrible code:
http://thedailywtf.com/rss.aspx

Johanna Rothman has a good blog on software management:
http://www.jrothman.com/weblog/RSS/mpdblogger_rss. xml

as does David Anderson:
http://www.agilemanagement.net/Articles/Weblog/Why EstimatesareMuda.html

The winner is...
I think DSLs are going to radically change the way that people code. DSLs potentially provide the meta-prgramming ccapabilities of LISP with the transparency and idiot-proofing of a language like Java. We may even see a hierarchy of software engineeringh develop, with one type of hihg-level coder deveoping DSLs and others able to use these languages easily within their own areas of expertise. For more, check the following links:

http://www.jetbrains.com/mps//
http://www.martinfowler.com/articles/languageWorkb ench.html
http://intentsoft.com/

http://www.martinfowler.com/articles/languageWorkb ench.html

"Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness."

Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness.

Okay, there is CRUD and then there are CRUD-screens.

Rails automates CRUD class generation. This is a popular and useful pattern. Rails has an outstanding implementation of this. It does have a few performance weaknesses, but they don't seem to inhibt many applications.

Rails also has a CRUD-screen generator set called "scaffolding". Scaffolding isn't really meant for production use. It's a nice way to force the app to get started. You then add things as you go, overiding the generated pages with real pages. It's unfortunate that many demos use scaffolding, because its really a very tiny part of Rails development.

The Rails framework does indeed auto-generate some other things. But they're extrmely generic.

This guy provides an intro to agile methodologies. Not being familiar with this notion and not having finished the article, I don't know how you'd apply agile methods (or eXtreme Programming methods, of which "agile" seems to be an offshoot) to system administration but this text from the article seems to indicate that it might be possible:

The following factors suggest an adaptive [agile] process
* Uncertain or volatile requirements
* Responsible and motivated developers
* Customer who understands and will get involved.

These factors suggest a predictive process
* A team of over a hundred
* Fixed price, or more correctly a fixed scope, contract

The way you answer reflects a rigid top-down mindset. After reading some of Paul Graham's essays, I began to question that way of thinking and asked myself if Rails could be built easily outside of Ruby, or alternatively, whether the types of problems that Rails addresses are more efficiently handled by your top-down list of components. Rails is more than a UI framework; it's being grown from the language up towards web app solutions. If you read some of Graham's essays in the light of Ruby on Rails, you might reconsider.

Graham suggests new languages may be trending towards LISP, perhaps because LISP was initially a theoretical exercise by McCarthy, a gedankenexperiment not really designed to be shoehorned into 1958 computational constraints, but rather discovered "when you try to axiomatize computation." (See Graham's full postscript paper The Roots of Lisp .) FORTRAN and C, on the other hand, took a lot of cues from the hardware; they had to be fast. Over time, the lower-level languages have been relegated to handle algorithmically-simple, computationally-needy problems, while the scripting languages - PERL, PHP, Python, Ruby - have been getting fast and moving from simple glue to more complex processing tasks.

Two decades have passed since I looked at LISP code, and I'm wondering if I like Ruby because it's as powerful as that language in my distant memory, yet more aesthetically pleasing syntax-wise since I'd been coding in C, C++, and PHP. It's refreshing to be using a true object-oriented (message-based) language that has strong (as in "walks like a duck") typing, closures, and seemingly dynamic everything (types, open classes). Although I'm relatively new to Ruby and Rails, I can see this is a language I'm going to enjoy using and figuring out.

Graham talks about bottom-up design , changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.

"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.

Just as standard Ruby lets you use "attr_writer :some_attribute", Rails provides a formalism for defining data relationships like "has_many :data_thing". The Ruby Way seems to run deep. It'll be interesting to see if Rails manages to adhere to that philosophy as it expands.

When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process. For Python users, the port might not be incredibly difficult. For C users, it might be easier to build a Ruby interpreter.

One of the knocks against Zope 2, a leading Python app and backend server framework, was how un-Pythonic the framework appeared to some developers

Read Martin Fowler on closures - it's a very good introduction to the topic, and uses Ruby as the example language.

The ORM layer is a weakness I think, the author is clearly not interested in understanding the relational model and has admitted as such in the mailing list. He commits the The First Great Blunder.

A bit off topic, but the first great blunder that you refer to is not exactly universally accepted as an irrefutable truism. That being the case, this doesnt seem to a major barrier to me. My understanding is that the ORM layer is based on the ActiveRecord pattern which is described by Martin Fowler in his book Patterns of Enterprise Application Architecture.

You could argue that all the other OO notation schemes, OOT, Booch, etc.. could be used as languages as well, I don't think the argument is particular to UML. Unfortunately, I don't think most folks would use UML for anything more than documentation and 'sketching'. You could think of UML as a language or dialect to communicate with. Is that what Mellor is suggesting?

I think the original author of this thread was referring to the actual application of UML as a programming language, and not as a dialect for materializing thoughts in a software process.

Go ahead and check into some of the references. As I mentioned, those experts classify 'programming language' as one of the three major modes of UML use. Of course, Fowler seems to consider executable UML as a 'holy grail' ideal that probably will never be practical, but there are ways to go about it. Mellor's recent book 'Executable UML' explores some of this. In general, some of the feel I get (remember, I haven't done UML as Programming Language myself) is that in those cases UML is the language worked in, and it can later be compiled to lower-level languages just as to execute C++ was originally compiled to C and then assembly while the programmer stayed working in C++.

To get up to speed on things, I'd suggest UML Distilled to get a good overview of things. Although he focuses on the ways most folks use UML, he does explain the "UML as Programming language" use as well.

At the company I worked for until very recently we mostly used 'UML as a sketch' on the whiteboard as a way of turning our ideas into something concrete we could implement...

I'd definitely have to strongly second this. I've seen this boil out from working at a few different companies. Those who used UML most strongly also seemed to gain less from it (and one architect seemed amazed and could not even fully grasped the concept that I'd been doing OO design for years without any UML at all... even when many projects I worked on even predated UML).

And it's not only my professional opionion and experience that lend support to this. Martin Fowler himself professes this position, and explains it fairly well throught UML Distilled

At the company I worked for until very recently we mostly used 'UML as a sketch' on the whiteboard as a way of turning our ideas into something concrete we could implement...

I'd definitely have to strongly second this. I've seen this boil out from working at a few different companies. Those who used UML most strongly also seemed to gain less from it (and one architect seemed amazed and could not even fully grasped the concept that I'd been doing OO design for years without any UML at all... even when many projects I worked on even predated UML).

And it's not only my professional opionion and experience that lend support to this. Martin Fowler himself professes this position, and explains it fairly well throught UML Distilled

UML is used only for notation and documentation

Actually, you're wrong there. It's a floorwax AND a dessert topping.

As Martin Fowler states in UML Distilled:

"In fact, the UML is a few different things to different people. This comes both from its own history and from the diffrent views that people have about what makes an effective software engineering process."

UML can be a programming language in and of itself, where all the code for some application is UML, or it can also be merely used for varrying degrees of documentation.

Both he and Steve Mellor independently came up with three modes in which most people use the UML:

• Sketch
• Blueprint
• Programming Language

Sounds like you're familiar with the first two, but the latter does exist as one of the primary three modes.

UML, like most other other software engineering fads exist mostly because groups like OMG want to push new consulting fees to large commercial companies, publish more series of books and create forums for them to lecture to (and charge fees).

On this, I'd also would have to say you're probably a bit off. The UML exists mainly because there was a Tower of Babel of somewhat similar approaches to the same problems being invented and used all over the place. At least the UML did manage to unify that mess. Of course, the consultants would be makining money regardless, however my personal feeling is probably that the multiple pre-UML solutions would have offered them even more fertile ground to exploit.

UML is used only for notation and documentation

Actually, you're wrong there. It's a floorwax AND a dessert topping.

As Martin Fowler states in UML Distilled:

"In fact, the UML is a few different things to different people. This comes both from its own history and from the diffrent views that people have about what makes an effective software engineering process."

UML can be a programming language in and of itself, where all the code for some application is UML, or it can also be merely used for varrying degrees of documentation.

Both he and Steve Mellor independently came up with three modes in which most people use the UML:

• Sketch
• Blueprint
• Programming Language

Sounds like you're familiar with the first two, but the latter does exist as one of the primary three modes.

UML, like most other other software engineering fads exist mostly because groups like OMG want to push new consulting fees to large commercial companies, publish more series of books and create forums for them to lecture to (and charge fees).

On this, I'd also would have to say you're probably a bit off. The UML exists mainly because there was a Tower of Babel of somewhat similar approaches to the same problems being invented and used all over the place. At least the UML did manage to unify that mess. Of course, the consultants would be makining money regardless, however my personal feeling is probably that the multiple pre-UML solutions would have offered them even more fertile ground to exploit.

One-time Object Relational Mapping code generation is only useful if you get the data structure right first time and the requirements don't change. This rarely happens, in my experience. Martin Fowler's (of Refactoring, Analysis Patterns fame) employer offer a consultancy service (I read in one of Fowler's articles) for automatic DB change management, tied in with code changes. The other way to do it is all at runtime and in code, but you need runtime support for class creation etc. (like in CLOS-MOP). This works by having the simplest, most general way of accessing data, but you have to handle all the possibilities at runtime.
Summary: needs way of keeping generated code in synch with changing DB schema.

If you listen to people like Martin Fowler (and I do, because he's a smart guy). You start to believe that the first and most significant factor in the success of a software project is getting the best people. Most experinced software managers know what Fredrick Brooks figured out in the 1970's, which is that a good programmer can be 10 times more productive than a bad one.

To laypeople, this is so counterintutive as to be absurd, especially considering that you can't measure productivity, but it is nonetheless true. While picking the right development process, management team, tools, etc. are important, nothing is as important as getting the best people that you can find. Although you have to pay them twice as much sometimes, the ROI on a good developer is going to be 200%-500% higher than a bad one.

If you listen to people like Martin Fowler (and I do, because he's a smart guy). You start to believe that the first and most significant factor in the success of a software project is getting the best people. Most experinced software managers know what Fredrick Brooks figured out in the 1970's, which is that a good programmer can be 10 times more productive than a bad one.

To laypeople, this is so counterintutive as to be absurd, especially considering that you can't measure productivity, but it is nonetheless true. While picking the right development process, management team, tools, etc. are important, nothing is as important as getting the best people that you can find. Although you have to pay them twice as much sometimes, the ROI on a good developer is going to be 200%-500% higher than a bad one.

The big question was how to handle all the stuff that would normally be considered GUI code-specifically, the hit-testing: Where do users click, and what should happen when they click there?

I suspected that hit-testing would be the most complex part of the application, so I wanted to ensure that I had tests for it. It also didn't belong in the model, since that should contain only basic game concepts. I needed an intermediary class somewhere: The Swing code would get a mouse event and delegate it to this intermediary class. The intermediary would interpret the mouse coordinates and determine if something had to happen. It would possibly do this by interacting with the model. If anything did happen, an event would be broadcast back to the Swing class.

In MVP, the View actually serves as both the view and controller (presenting output and managing input). The Model is the Model, as in MVC. The extra middle layer is considered a bridge between the View and the Model. It's specific to the application and is often considered throwaway if the View needs to change (for example) from Swing to HTML. In this situation, the Model would remain unchanged.

The big question was how to handle all the stuff that would normally be considered GUI code-specifically, the hit-testing: Where do users click, and what should happen when they click there?

I suspected that hit-testing would be the most complex part of the application, so I wanted to ensure that I had tests for it. It also didn't belong in the model, since that should contain only basic game concepts. I needed an intermediary class somewhere: The Swing code would get a mouse event and delegate it to this intermediary class. The intermediary would interpret the mouse coordinates and determine if something had to happen. It would possibly do this by interacting with the model. If anything did happen, an event would be broadcast back to the Swing class.

In MVP, the View actually serves as both the view and controller (presenting output and managing input). The Model is the Model, as in MVC. The extra middle layer is considered a bridge between the View and the Model. It's specific to the application and is often considered throwaway if the View needs to change (for example) from Swing to HTML. In this situation, the Model would remain unchanged.

In that case I agree with the article (and disagree with the /. summary). Martin Fowler summarizes the differences in attitudes here. I personally prefer a directing attitude, and think it's the best way for the industry to proceed. I can understand how people might prefer using enabling tools, but for every person who can handle the responsibility, there are five others who can't (and we can't just leave them behind).

I've worked with Thoughtworks on a few projects and they looove XP. They also love the idea of refactoring and used to keep a project wiki for each project - similar to what is being described here, except without the historical info.
Martin Fowler, owner of Thoughtworks and XP evangelist, keeps a Bliki (his name for a cross between a Blog & a Wiki)

Projects which are not archected for expansion will screech to a halt and become a boneyard for the project which is better architected.

There are alternatives to big upfront requirements, architecture, and design phases: Is Design Dead?

On the other hand, the larger the team, the more structure is required; you don't want one person breaking what another person took four weeks to complete.

Well, more structure is one option. Or you could just write self-defending code. A good unit test suite combined with a Continuous Integration tool means that if somebody breaks something, they'll get an email a few minutes later.

On my last few projects, we've ended up with about a 50/50 ratio between test code and production code. You'd think that it would slow things down, but it really makes development faster. I spend about ten minutes a week using the debugger, and very little time wondering what something does.

On the rare occasions when I can't figure out what some chunk of code does, I'll just comment it out and run the tests. If nothing breaks, then I delete it and move on. And if something does break, then I delete it and write something clearer in its place. It's very freeing!

The notion of templating in PHP (or any web platform) is described by Martin Fowler in Patterns of Enterprise Application Architecture as the Template View.

Implementation of the Template View is examined in some detail at http://wact.sf.net/index.php/TemplateView, which begins looking at "Why use templates" then examines different styles of templating, in terms of their markup and the API they provide to populate the template with data. The purpose is to lay this discussion to rest once and for all.

Where PHP's concerned, the real question is why has everyone (and their dog) written their own template engine? In an ad hoc survey we counted over 80 public domain template enignes "out there"

What's even more puzzling is why 90% of them all look the same with markup like;

...and a pinhole API like;

My guess at the reason why is public here

As to what template engines in PHP are actually worth using, there are only two IMO;

The first is PHP itself - use some self discipline and keep the pages where code gets mixed with HTML to the most basic PHP syntax - just the flow control statements like if/else, while and foreach.

The second is any which can offer templating capabilities similar to Java's JSTL or ASP.NET. Which is where WACT comes in. Check the examples to get the idea.

The notion of templating in PHP (or any web platform) is described by Martin Fowler in Patterns of Enterprise Application Architecture as the Template View.

Implementation of the Template View is examined in some detail at http://wact.sf.net/index.php/TemplateView, which begins looking at "Why use templates" then examines different styles of templating, in terms of their markup and the API they provide to populate the template with data. The purpose is to lay this discussion to rest once and for all.

Where PHP's concerned, the real question is why has everyone (and their dog) written their own template engine? In an ad hoc survey we counted over 80 public domain template enignes "out there"

What's even more puzzling is why 90% of them all look the same with markup like;

...and a pinhole API like;

My guess at the reason why is public here

As to what template engines in PHP are actually worth using, there are only two IMO;

The first is PHP itself - use some self discipline and keep the pages where code gets mixed with HTML to the most basic PHP syntax - just the flow control statements like if/else, while and foreach.

The second is any which can offer templating capabilities similar to Java's JSTL or ASP.NET. Which is where WACT comes in. Check the examples to get the idea.