XML Developers Association’s meeting on CSS with CSS Zen Garden creator Dave Shea. CSS layout hints and tricks.

The CSS presentation was great. Thanks Dave, thanks ActiveState for organizing event. This is one of the best, the most “right to the point”, the most elegant presentation I’ve seen to date. There is nothing more to add. You’ve got to see it:

http://mezzoblue.com/presentations/2005/vanxml/

I please don’t forget to check out the designs (Total designs listed: 779):
http://www.mezzoblue.com/zengarden/alldesigns/

Random pieces of information that caught my attention:

- only recently (since 2003) most browsers caught up with CSS specs
- days of tables and font tags are over
- offload look and feel into CSS
- basically only 3 layout concepts: box model, float and positioning (absolute and relative)
- CSS operates on HTML e.g. layer above it
- keep CSS in separate file
- CSS defaults are different in different browsers, reset them to the values you know
- avoid relative positioning
- IE has a lot of bugs with floats
- IE has got most CSS bugs, check the presentation on how to deal with them
- IE conditional comments are very useful to trigger browser specific behavior
- ironically presentaton doesn't work on IE 6.0.3790.1830

Thanks again Dave.

This was my first XML Developers Association meeting. I went there undercover. To disguise my identity I was wearing my Java hat. ;-) Giving the choice to use XML or “something else” for the job at hand, I would choose something else. {rant} The more I work with XML, the more I get an impression that this rule has to be set in stone with no exceptions. Latest discovery of YAML solidified this position even more. Down with XML(XSLT, XPATH, XQUERY and whatever else X) - long life Python, Ruby and YAML. ;-){/rant}

Vancouver Ruby user group kick-off meeting. Ruby on Rails AKA RoR.

Many thanks to the meeting organizers from Active State for preparing the meeting and thanks Alex for the presentation. It was quite entertaining and great fun. I always feel for the presenter and I understand how hard it is to present something that has an ambition to be a revolutionary technology. However, I must say that first part of the presentation sounded very metaphysical. Some of the lingo was also quite confusing at times: the smart servant vs. dumb servant methaphore etc. There is probably better analogy. Ruby opens up a whole new exciting discussion about what the modern programming language should look like. Jumping ahead a bit I would say that for the large and medium size projects Ruby is still very young. The Wikipedia page on Ruby seems to be the best starting point to learn about Ruby. Here is what I’ve learned during presentation and my comments.

1. Ruby software developemnt philosophy is based on:

- Less is More. e.g. less code to write, less code to maintain, less bugs etc.
- Worse is better. e.g. not everything we do in life needs to be “award winning”. The same as “Good enough” principle.
(Certainly true for many applications, 2nd rule exceptions: Mac, iPod, pick device or product you really like)

2. Ruby is a natural choice for Domain Specific Languages.
(Best choice I’ve seen to date, mostly because of semantic of the language. However it could be only matter of time before these features will get abused. Some of the similar futures were deliberately not included into Java )

3. Ruby chooses convention over configuration. It allows minimizing number of XML or other types of configuration files to deal with and therefore reduces complexity and makes app better maintainable.
(Cool)

4. The point was made about a “bureaucratic” approach taken while developing using other languages and frameworks for them. This is usually means that often you are forced to update things in way too many places at once which is redundant, error prone, takes more time and most importantly totally unnecessarily.
(Amen brother)

5. Ruby on Rails is a domain specific language for developing web based application and it’s very “opinionated”. It dictates you the way the app should be structured. It also means that it might be very hard to do the things which are “off beaten path”. Another example of DSL using Ruby is Rake (make for Ruby) http://rake.rubyforge.org/

6. “Trails” is an attempt to implement similar to RoR concept in Java. In presenter’s opinion it makes things even more complicated.

https://trails.dev.java.net/
http://jroller.com/page/ccnelson/Weblog?catname=/Trails

7. For one reason or another Ruby programmers seems to develop a strong negative bias towards Java. This is a curious psychological detail. I remember sort of the same thing happening in 1995 towards C++. 10 years later, is Ruby the holy grail? Or is it just going to push Python little aside? Is Java legacy will be one of COBOL or C? My answers are NO, YES, NO, YES.

8. Anything that Dave Thomas is writing about is really worth knowing!

Some more interesting links:

http://en.wikipedia.org/wiki/Ruby_programming_language Wikipedia Main Entry for Ruby

http://onestepback.org/articles/10things/index.html 10 Things Every Java Programmer Should Know About Ruby

http://www.ruby-lang.org/en/ Ruby: Programmers' Best Friend

http://www.poignantguide.net/ruby/ Great Ruby book on-line. Adam, thanks for the link.

http://www.lesscode.com Lesscode is not about quantity

AJAX, blogs, knowledge, mitosis and everything else ...

Just before I quote another blogger again, I would like to mention a very productive and efficient way to keep your blog going. Instead of writing your own thoughts and then taking a heat and feel ashamed for the stupidity of your own opinions - one can instead quote somebody else. No risk and little time required. And BTW, this is not my idea either, I've heard about it first from Scott's Adams "The Way of the Weasels". As Alan Watts pointed out once: most books - are books about books and our libraries are multiplied by mitosis. The Internet and blogs are sort of multiplying the same way but a lot faster.

The author of the article above sounds quite right. Disclaimer: I'm yet to write a single AJAX application and I don't think author did either.

http://www.jroller.com/page/MikeSlattery/20050308#ajax_is_a_mistake

Most of the article is fine. I don't agree with the opening line that "AJAX thing is a pure crap". "Pure crap" sounds like an oxymoron. ;-) To me AJAX is a very creative and very expensive way to overcome clumsiness and limitations of the web technologies. CSS + HTML + HTTP + XML + JavaScript + whatever: is a big hairball of stuff. I think it's a matter of time before that this mess will have to be replaced with something that is:

- single semantic
- cross platform
- secure
- transparently distributed (sort of like RMI)
- both state full and stateless as required
- richer, interactive user interface like in desktop apps.

AJAX is just another attempt to "build a house on a sand" ... I know, sometimes it's hard to find good metaphors :

Top 5 and bottom 5 Principles of Enterprise Architecture from the summit

Interesting info taken from here, nice format and curious results. I would agree with everything except open source: one should not assume that opensource product is by definition better - do your home work. The same is true for any other product: free or otherwise. And yes, it takes one bad apple to get a bitter taste ...

***

Top

1) Use a layered architecture.
2) Build Automated Regression Tests, which was tied with:
3) Manage your application as you would a software product. eg: frequent and numbered releases, same rigour as a product.
4) Use the smallest team you possibly can tied with:
5) Attach the domain problem first (or - work on your domain model before other parts of the app).

Bottom

1) Use Model Driven Architecture.
2) Determine all your requirements upfront.
and a three way tie between:
3) Use EJBs.
4) Prefer web based UI's.
5) Prefer open source projects.

Dawkins' Selfish Gene, Intentional Programming, Java, C etc. http://www.edge.org

Just found a great site and can't stop reading articles from it. I haven't seen anything of the kind before. The site covers a wide range of topics on science and technology.

Interestigly enough there is a article that links together two topics I was pondering about last week which I thought had nothing to do with each other: biological evolution and programming languages. Bizzare? Read on ...

... Programming languages are really just vehicles to supply abstractions to programmers. People think of programming languages as being good or bad for a given purpose, but they are really criticizing the abstractions that a language embodies. The progress in programming languages has been incredibly slow because new programming languages are difficult to create and even more difficult to get adopted. When you have a new programming language, the users have to rewrite their legacy code and change their skills to accommodate the language. So, basically, new programming languages can come about only when there is an independent revolution that justifies the waste of the legacy, such as Unix which gave rise to C, or the Web which gave rise to Java. Yet it's not the languages that are of value, but only the abstractions that the languages carry.

It's very much like Dawkins' idea that it's the genes, not the individuals, that are important in evolution. And, in fact, what's being reproduced are the genes, not individuals. Otherwise, how would we have worker bees and so on. We are doing the same thing; it's abstractions that matter, not languages. It's just that we don't think of abstractions without languages, because languages used to be the only carriers for abstractions. But if you could create an ecology in which an abstraction could survive independent of everything else, then you would see a much more rapid evolution for abstractions, and you would witness the evolution of much more capable abstractions.

To enable the ecology, all you have to do is make the abstractions completely self-describing, so that an abstraction will carry all of its description, both of how it looks and of what it does. It's called intentional programming because the abstractions really represent the programmers' original computational intent. And that's what the important invariant is, everything else of how something looks or how something is implemented, these are things that should evolve and should be improved so they can change. What you want to maintain invariantly is the computational intent as separated from implementation detail. ...

http://www.edge.org/digerati/simonyi/simonyi_p2.html