Joe Gregorio

I got so peeved at the crap platforms (well there not all crap but they certainly have lots of restrictions) that I wrote my own. My own efforts are just as crap but it's my crap. I can fashion my tools to work the way I want it instead of how someone else decided. For example I need something that I could (can)

- write/edit with a worst a text editor or best an web ui

- ability to markup in a meta format

- access to the source in a language(s) I use

- good db access tools

- ability to evolve and add new layers or technologies

I also have some quirky requirements. I want static pages primarily (at least at the moment). I care more for load speeds and readability than the ability to interact RT. (currently process interaction on delayed batch close to RT). For all the disadvantages this has a few advantages namely speed and fewer moving parts exposed.

My first effort was a Perl script transforming POD (Plain Old Text) files into markup. The next effort is a Python app using Django to store RestructuredText (python based plain text markup) markup in a MySQL db spitting out valid xhtml static pages. And I've already got a third system in mind using various editors with a light weight middleware web server using a db for backup but exporting to atom (something like http://bitworking.org/projects/1812/ ) and serving a combo of static pages and dynamic using some browser/Javascript approach.

Probably the most important thing is how it handles the data. To tell you the…

A couple of things seem off on this perspective, mostly that modern web development has gotten weird, irrespective of Rails.

"The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple."

First, I found Rails simple and easy, but it has become more complex over time as it has grown to support a variety of uses. The simplicity is not just because of Ruby, which is a low ceremony language, but rather because of the simple structure of the application, with a clear separation of concerns, very easy to find where a particular code item went.

"The meta-programming and object injection that makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug. "

Dependency oriented development is a real problem, but it is insane to blame that on Ruby. I was working with an enterprise Java team last year that had over 1000 .jars in their build. It doesn't necessarily make it hard to debug, but it does mean you have understand a wide variety of different libraries. People are willing to load a library for the simplest of functions (as the leftpad npm case showed). Again, nothing to do with Rails or Ruby in particular.

"The magic of active record, the crazy levels of duck typing and the expressiveness of ruby, are exactly why it runs poorly even on your development box."
This is highly dubious- it's very fast on my dev box. The Ruby interpreter keeps getting better, even taking…

I think I'm understanding now why others below have such doubts about the simplicity of what I describe ;-)

You're describing two problems - the first is around message delivery (in-order, exactly once) and the second is a distributed transaction. Both of these problems are solved by separating message transmission from message processing.

First, in-order and exactly once. Lets assume we have two systems. One we'll call the messaging client (MC) and server (MS), which sends and receives messages. The other we'll call a system of record, also client (SoRC) and server (SoRS), which is the system that has, say, an exactly once requirement:

SoRC -> MC -> MS -> SoRS

Lets say that I'm ordering a pair of shoes from Amazon. I don't want to receive two pairs, and I also don't want to receive no pair. Receiving a single pair of shoes exactly once is a business function. The fact that the message containing my order has been received exactly once provides no assurance. What if the ordering system on the other side rejects my order because I entered an invalid product code? Even a semantically correct and valid product code doesn't help me if the shoes are out of stock. I want those shoes, not the certainty that the message was delivered. The assurance that my order was delivered once and only once is therefore a business rule, and completely immaterial at the messaging level.

Therefore I can send a once, and exactly once message to the server a 1000 times over. The server-side…

No, but RSS is a schema with a specific, narrowly defined purpose: to syndicate article-based web pages (and even so, there are 5 or 6 different versions, not including Atom - though your point stands and I don't want to get sidetracked over a quibble).

A more apt comparator may be WSDL, which theoretically allows a SOAP web service's remote procedure calls to be discovered programmatically but in practice is such a messy, complicated, leaky abstraction that it's often easier just to build XML templates manually and POST them to the endpoint.

Well, two points:

Firstly, I think WSDL (and WADL) are working at the wrong abstraction level. I think one of the reasons why REST is cleaner is because unlike SOAP it's data oriented, not RPC. And I believe it's possible, as long as your API is data oriented too, to map that to generic formats that don't feel messy.

I had already mentioned RDF (Resource Description Framework), but I'll mention it again; RDF is a layer between the serialization and the concrete schemas, giving very specific but open ended semantics to its documents.

Unlike WSDL, it's very simple: it consists only of four concepts: triples, which are composed of objects (which is always a resource, and is represented as an URL), subjects (which can be other resource or a literal value) and a predicate (which relates that object with the subject in some way, and which are specified by a schema). Then, a document is just a bunch of statements about one or more…

So here (http://fewagainstmany.com/blog/python-micro-frameworks-are-all-the-rage) is a post that lists some micro-frameworks for Python, such as web.py. Many of them are similar to Sinatra for Ruby (if you are familiar with that framework) and basically allow you to create very simple web applications in a single file if that is what you desire. While these are not inherently MVC, they can be used as the underlying foundation for your very own MVC framework.

As for MVC, the other big ones for Python (other than Django) are Pylons and TurboGears. Of course there are some other very heavy weight ones as well, such as Zope and Plone, but my knowledge of these is very limited, so I'll leave them for someone else to comment on.

Finally, you can could always use the WSGI spec directly and just slap together all the other "best of bread" pieces to make your own simple framework. It's actually pretty easy to do so, and the best tutorial I've found on doing just that is on Joe Gregorio's website (http://bitworking.org/news/Why_so_many_Python_web_frameworks). Check it out, it's definitely worth running through once to at least get an idea of what other frameworks are doing under the hood.

You said: As bayareaguy noted: "You have to read the original article very closely or you'll miss their point: in terms of distributed database research, MapReduce is a step backwards."

This to me is really funny since I don't think you can view MapReduce as distributed database research. I haven't used it, and while I admit that I might have gotten it all wrong, to me its a library/dsl/paradigm/technique for parallelization of certain data-processing tasks. So to me that statement makes as much sense as "lisp, viewed as a monitor , is a step backward compared to lcds".

Others, that I consider smart, have noticed http://bitworking.org/news/288/Stonebraker-on-MapReduce

Also, while it was a while since i viewed the techtalk on bigtable, and I really agree BigTable is a column-based DBMS, I can't seem to remember that they built it to get around deficiencies in MapReduce, I understood it as a compliment. BUT it might have been much more constructive if, as someone said higher up, they wrote the original article about BigTable, because I do believe that their criticism is actually valid (as in apples vs apples) in some cases regarding BigTable.