User Reviews
about 1 year
ago
Haml:
Haml makes editing HTML more comfortable
by
Peter Bex
With regular HTML (or ERB), closing tags all the time and indenting gets annoying and it's too easy to get the nesting wrong, especially when you have some nested conditionally shown HTML fragments or after moving stuff around in a HTML file.
Haml fixes these problems once and for all: it replaces opening/closing tags to nest tags by using indentation to indicate the structure.
The Haml syntax makes the tree structure of HTML
... [More]
much clearer and with the Emacs mode that's shipped with it, editing is really a breeze.
There are also some disadvantages: Haml's syntax does not allow hashes on both the attributes side and the content side of a tag. It also makes it hard to nest things in such a way that only the outer part of markup differ, with common inner content. You're forced to use a partial then, or repeat the inner content for each variation of outer markup.
Last but not least, inline javascript (or other types of non-html content) is painful when you need to use Ruby code in it, because the Ruby is evaluated in another environment than the surrounding template.
On the whole, Haml gets a well-deserved 4 stars, for making my Rails templating life much easier. [Less]
1 of 1 users found the following review helpful.
Was this review helpful to you?
Yes
|
No
about 1 year
ago
by
Peter Bex
As a Schemer who codes PHP at work, I know the pain of having to code in a crippled language (one bright spot: at least PHP 5.3 will have real anonymous functions!). It's great that someone's working on a set of tools to make proper functional programming easier in PHP.
I've browsed the source for a bit, and already found a couple of things I recognise from the all the Greenspunning we had to do to make PHP bearable for CASCO
... [More]
(http://www.ohloh.net/projects/casco); most interesting is the dynamic scoping functionality; we had just come up with this ourselves a few weeks ago :)
We're probably not going to use this framework in CASCO because we've already decided upon a fully object-oriented programming style (without good namespacing, classes are the next best way to keep functions grouped and out of the way) and already have selected SimpleTest for our testsuite, but I still would like to wish this project all best of luck! PHP really needs better programming tools.
Love the project name, by the way ;) [Less]
1 of 1 users found the following review helpful.
Was this review helpful to you?
Yes
|
No
7 months
ago
typeface.js:
Great font replacement library!
by
Peter Bex
Finally, a purely client-side Javascript (no Flash, no images) font replacement library!
This library is small but functional, and has zero dependencies.
It's pretty fast, and has decent support for all browsers except Opera (but that's a bug in Opera, which is fixed in the upcoming version).
It has a server-side companion script to convert truetype fonts to Javascript files, which is unfortunately not freely available
... [More]
at this point; you'll have to upload your fonts to the webpage, for now.
Because it draws the fonts using the Canvas element (or VML in IE), it cannot support the full CSS transformation and effects you can apply to type, which is a shortcoming you have to be aware of.
You will also have to keep in mind that CSS font "properties" like font-weight and italics (but *not* underlining) are actually different fonts in the same font family so you'll have to upload the bold version of the font to generate a Javascript font file in order to be able to use it to replace text in elements that are styled with the font-weight property (remember, headings are boldfaced by default).
All in all, I'm very happy with this library because it makes maintenance of website headings in a CMS less of a chore -- in fact, it allows our customers to manage the headings as content without worrying about generating a new background image to replace the text with, every time. [Less]
Was this review helpful to you?
Yes
|
No
2 months
ago
racc:
Cool stuff
by
Peter Bex
Having suffered from bad performance of a TDP4R-based parser, I turned to racc to see if performance could be improved. Since racc generates LALR(1) parsers, I expected much better performance than I got with the backtracking recursive descent parsers you can write with TDP4R.
This expectation was correct - the parser was a lot faster. I had used yacc in C projects before, and I really liked how familiar racc feels! I got started quickly
... [More]
and managed to convert the parser easily. The parser's code size is comparable to the one I wrote with TDP4R, which kind of surprised me since you can do neat things with higher-order functions, while the racc parser has to be very straightforward, BNF-style.
The main disadvantage of using racc was that racc requires an edit-compile-test cycle, something that can really slow down your development process. TDP4R is pure ruby and does not require any preprocessing. Another disadvantage is that because it looks and feels so much like yacc, you're programming in an entirely different language that is not Ruby.
I really liked the way racc provides feedback about rule conflicts; it helped me detect and get rid of a superfluous rule (reduce/reduce conflict) which might also have been the cause of *some* slowdown in my original parser. Another neat feature is the debugging output log it can produce, which contains all the rules and states the parser knows about. It takes some getting used to and it's hard to grok the output, but it's very helpful even if you don't fully understand everything. And there's even a way to automatically get debugging output from a working parser while it is analysing its input.
I also briefly tried out Treetop, but didn't like it. It also requires compilation, is an extra dependency (the racc runtime ships with plain Ruby) and its syntax tree objects are not very convenient - it's much nicer to just return the final data structure straight from the parser.
I still like TDP4R for its ability to quickly hammer out a parser, but I'd certainly consider using racc from the start in a project where I knew parsing could be a major bottleneck. If I wasn't sure, I might use either; it's easy to do some prototyping in TDP4R and then convert the parser to racc. Just be careful not to rely on higher-order functions or dynamic combinators :) [Less]
Was this review helpful to you?
Yes
|
No
