Reflective Surface
Still powered by a contradiction in terms
Archive for Software Development
December 6, 2007 at 2:30 am · Filed under Geek Stuff, Software Development
The first programming tool I ever used was Turbo Pascal 5.0, in 1994. A 5 1/4 disk, passed around by a professor, was the gate to a world that had interested me since my first readings about computers and their capacity to be told what to do. From release 5.0, I quickly jumped to 5.5, which offered rudimentar OOP support, and soon was using 6.0, which allowed programmers to use much more interesting OOP features and had excellent graphic support. I started programming my own graphical window manager until I realized it would be too hard to compete with Windows.
My interest in Borland products didn’t dwindle soon. After a brief fling with Turbo C++ 3.0, I went on to program in Delphi from 1997 to 2003, with sporadic uses until 2006. When the company I worked for changed its entire product platform to .NET, I had no choice but to follow. Borland’s frequent strategic mistakes didn’t help as well. Soon, one of my favorite tools was just a memory. I still have a copy of Borland Delphi 6, which I purchased with my own money, but the CD has probably stopped working by now.
After so much time away from the community–I used to be very active in the Borland newsgroups, specially those related to Web programming–I was surprised to hear that Borland restored and modernized their Turbo line of tools. There is now both Turbo Delphi and Turbo C++, new versions of Turbo Pascal and Turbo C++. For those into Microsoft tools, there is also a Turbo Delphi for .NET and Turbo C#.
Obviously, those are basic versions, stripped from any professional or enterprise features. Nonetheless, it’s nice to see Borland returning to its roots, even though those tools won’t sell enought to justify their existence. Then again, who knows, names can be powerful. Since there a free version of Turbo Delphi, I guess I’ll be programming in Delphi soon again.
Better than Turbo Delphi would be a new version of Turbo Pascal. I still have a disk around with lots of interesting programs to run.
March 5, 2007 at 8:17 pm · Filed under Software Development
The project has been approved at RubyForge, so it can be downloaded from there now or installed via the usual gem install htmldoc command. The documentation is accessible as well, and there is a Subversion repository for those interested in download the files directly.
As I said in the previous entry, I hope this library is useful to others as it was to me.
March 5, 2007 at 9:59 am · Filed under Software Development
Anyone using Ruby and Rails knows that there are few decent reporting tools, and many of them are very hard to use. Since there’s no native solution, most developers resort to a combination of other tools to put their reports together.
In my last projects, I tested a lot of solutions and found one setup that I consider satisfactory: I’m using HTMLDOC to generate PDF reports from HTML input. HTMLDOC is an open-source application that converts HTML input to formatted HTML, PDF or PostScript output.
HTMLDOC is an excellent tool, but it’s an application, which means you need to invoke it and control its execution as a process. To make the job easier, I created a plugin/gem that allows me to use HTMLDOC via a Ruby class, with a couple of simple methods.
While I search for a permanent place for the project (RubyForge, for example), I’m making both the gem and the plugin available here. The usage information can be found in the README.txt file.
In order to use the class, you will obviously need the executable. Although HTMLDOC is open source, binaries are only available in paid versions. For Linux, the easiest option is to compile it yourself, which is quite simple. For Windows, old binaries can be found on the Internet. Obviously, they lack the most recent fixes. If you are deploying to Linux, though, that’s not much of a problem since you can test most of the options on Windows and run the most recent binary on Linux.
I hope this library will be as useful to others as it has been to be. If you have any comments, suggestions or fixes, please contact me.
February 15, 2007 at 4:09 pm · Filed under Software Development
After hours of frustrated attempts, I finally managed to get a working Squeak development image with both Seaside and Glorp loaded–with invaluable help from Ramon Leon of On Smalltalk fame, who found out what I was doing wrong. The image is built upon the full 3.9 Squeak image, and was tested on both Windows and Linux.
It took me a few tries to get Glorp loaded into the image since the port was created for the 3.8 release, but it seems to be working well now. I had to patch a couple of methods, and now most of the tests pass (only three out of seven hundred are failing now, and I believe one of them is too version specific and should be rewritten anyway). This version requires PostgreSQL 8.2 with plaintext authentication enabled.
If you are interested in giving Smalltalk a try, Squeak is a good way to start. This development image requires only the stable release, which can be easily found on the Squeak site, a nd will work on any of the support platforms.
February 7, 2007 at 6:15 pm · Filed under Software Development
In the past few days, I downloaded and briefly tried a bunch of different Smalltalk implementations, trying to decide for one of them. There are dozens of different implementation, each with its own pros and cons. The language itself is, obviously, the same for all implementations. What makes each implementation unique are the kind of environment offered to the developer, which can vary from a simple command-line workspace to packages allowing a developer to build and deploy applications or services to multiple platforms.
One of the first things I noticed about the implementations was the price of some of them. There are free implementations, of course, and non-commercial versions of most of the paid ones. But some non-free versions, like VA Smalltalk, can cost upwards of eight thousand dollars. For others–like VisualAge, from IBM, and Cincom Smalltalk, from Cincom–I couldn’t even find the price. I don’t want to imagine what they would cost for a single developer or a small company. In my opinion, if a company has to hide the price of a product, it’s always beyond the reach of mere mortals.
Both Cincom and Object Arts make free implementations available for non-commercial development: Cincom with its VisualWorks product, and Object Arts with Dolphin Smalltalk. Dolphin Smalltalk is a purely Windows implementation, much like Smalltalk MT, from Object Connect.
As I intend to develop both desktop and Web applications, my primary choice, of course, would be an implementation with support for both tasks. For Web applications, I’d like to use Seaside and Glorp, a requirement which narrows the playing field. On top of this, I’d like to use an implementation supporting both Windows and Linux. There’s only one implementation that fits those criteria: Cincom’s VisualWorks.
There’s also Squeak, which fits those requirements to a certain extent but whose implementation is too geared for educational use, and whose own version of a graphical interface is too weird and changes too much for my tastes. It’s a fast and good implementation, but not what I’d like to use now.
At the moment, I have Squeak, Smalltalk MT, Dolphin Smalltalk and VisualWorks running on my computers. Smalltalk MT and Dolphin Smalltalk are excellent products, very polished, which is kind of expected since they only run on Windows and can afford to adopt all the conventions of that plataform. On Linux, I have Squeak (just for the fun of it) and VisualWorks. VisualWorks is very complete, but lacks some polish in terms of GUI development. On Windows, it uses its own components and on Linux runs on top of OpenMotif. As far as I know, there’s no support for Qt or GTK.
With all those differences, I wonder if that’s one of the causes behind the lack of enthusiasm about a language that, for all accounts, is still way ahead of its time. Even the fact that it’s based on images is not a problem considering that the possible objections for that–lack of “proper” executables and team development–have been addressed a long time ago. I can understand that Lisp failed to reach mainstream acceptance because it’s too esoteric. But Smalltalk is a normal imperative language, with a simple and powerful syntax. I don’t know if a standard implementation would make it more acceptable in market terms, but it would certainly make it more interesting. I guess that’s why people are interested in #Smalltalk, which is based on .NET. Unfortunately, it isn’t ready for production yet.
Those considerations apart, Smalltalk remains a mature and extremely relevant language. Seaside and Glorp, with their conceptual similarity to Rails and ActiveRecord, are giving it a lot of visibility now and I wouldn’t be surprised if more public commercial applications based on that combination started appearing this year. Undoubtedly, most languages in use today would gain a lot with a growing Smalltalk user base.
January 13, 2007 at 6:59 pm · Filed under Software Development
For those interested, version 0.44 of the best Rails mode for Emacs has just been released. For those developing for Rails using Emacs, there is no other extension so feature rich like it. This new version fixes many bugs and introduces a couple of new features worth checking out.
I’ve contributed with a few patches and if your are interested in helping out, the leading programmer of the extension is a nice guy and will gladly accept your contributions. 
March 25, 2006 at 6:46 pm · Filed under Software Development
Recently, I spent a week helping in the presentation of an application developed for the internal use of a client of mine. The project, although nicely specified, suffered with the change of key people during its implementation phase, and, because of the problems resulting from those changes, I wasn’t particularly confident in the outcome of the presentation.
Fortunately, despite the error screens occurring at the most unappropiate moments of the presentation, the general impression of the end users of the application was very positive, and I believe the corrections that will be implemented in the next phase of the project will be sufficient to finish it in satisfactory way.
The most problematic point about the presentation, in my opinion, was the use of test data. After seeing how much doubt and confusion the use of test data caused, the first point in the checklist for presentation from now on is: never, never, ever again, use fictitious data in a presentation system. It’s a obvious rule, but I guess it only became clear to me now because of particularities in this system which make test data especially bad. And there is always the possibility that some developer will have written something really embarassing in a text field which will cause a bad impression on the users.
Another point is the use of primary keys in the interface. Primary keys are an implementation detail that doesn’t belong in the presentation tier. Some developers seem to like using them as record identifiers but users will only become confused by such “random” numbers appearing in the midst of other data.
Presenting applications, I’m now realizing, it’s a really complex task for engineers types like me, because it depends on skills that belong in the area of management. But life is like this: you only learn things by experience.
At least, I finished the presentation with the certainty that the application is doing what it was supposed to do: radically simply the work of the users and promote processual changes in the way that work is done. It would only be better than that if the application did all the work by itself.
March 18, 2006 at 9:40 pm · Filed under Geek Stuff, Software Development, Technology, Web, Weblogging
With the recent developments in the RSS world, including the launching of Windows RSS Plataform, the discussions about the use of the format as real platform is undergoing a change. Now, there is a lot of talk about how developers can maximize the potential of the format e how they can solve the existing infrastructure problems.
In all that I have read, I didn’t see much discussion about mutable RSS feeds, that is, interactive feeds that allows users to pass data through the aggregator itself, changing the future behavior of the feed based on their choices.
Obviously, support for such interactivity isn’t present in the current crop of aggregators — at least, in none of the many I know and/or tried. In fact, a persistent fear of security problems that could be caused by such interactivity pervades the entire area. XSS and similar exploits caused most aggregators developers to completly eliminate the use of objects, forms and JavaScript inside RSS feeds.
Such an approach puts extreme limits on what you can do with RSS, of course. More than an year ago, answering a question posed by a friend of mine, I wrote here about interactive RSS feeds. The application I designed to test the concept at the time (a very simple prototype) is still running and can be accessed in the test area of this site. It’s a RS feeds that instead of simply presenting content, allows users to act on its entries. Given the limitations present in the current generation of feed readers, you will probably need to open each entry in the browser to see the feed in action.
The big question is: what can we really do with RSS? Is a read-only platform enough? I don’t think so. Considering the context in which I created the application mentioned above, that of a course served through RSS, a read-only plataform is not that interesting. A typical course has an activity tree that’s completely dependent on the students’ choices. A read-only format would not provide a complete experience in such a scenario.
As mentioned before, there are real security concerns involved in allowing users to interact with a feed. Allowing any kind of content can lead to episodes like the one caused by Mark Pilgrim a couple years ago, whose RSS feed “took control” of hosting computer with a clever use of HTML. The text he wrote later about the subject impacted the development of an entire generation of aggregators. Yet, browsers handle the same issues today and — despite some problems — they do just fine.
Before I start repeating what I already said in the other article, I believe RSS can evolve a lot beyond what it is today. New applications — especially in the much hyped Web 2.0 style — depend on a bigger possibility of interaction than that offered by aggregators today. Since the competition in the area seems to be big, I guess it won’t take long until we see changes.
June 21, 2005 at 11:12 pm · Filed under Software Development
In the ten years since I started to work developing Web applications, I learned something well: never trust a library to write the HTML for you. The more I work with Web applications the more persuaded I am that this is a good rule. Any library that hides the generation of the presentation layer behind complex routines or components tends to limit choice and make optimizing the resulting HTML a real pain — if possible at all.
The problem with such kind of abstractions is that they leak too easily, leaving the developer in a situation in which he must uses the abstraction only for simple things and break it every time something more complex is needed.
Take .NET, for example, since it’s especially awful in this area. Created to completely eliminate the need to write HTML by hand, it ends up uselessly complicating the job of programmers, forcing them to deal with two interfaces at the same time to achieve an objective that concerns only one of them. The result is a half-baked solution, hard to read and hard to maintain, with unpredictable results in different platforms.
Effectively, those libraries ignore the decisions made by the programmers, generating code that may, at first glance, behave the way the programmer intended it, but that is often so riddled with collateral effects that it will surely cause problems in the future.
This is fatal when Web standards come into the equation. Taking .NET as a example again, one of its components is intended to simulate a panel in a normal UI. On Internet Explorer, the component is correctly rendered as a <div>. On Mozilla, however, it comes out as a <table>, completely changing the page’s semantics, which, on its turn, will affect style sheets and scripts related to it.
When I started programming for the Web, it was the sheer boredom of creating all the widgets needed for a page by hand that lead me to create my first libraries to take care of writing HTML for me. Learning by experience that those libraries more often hindered me than helped me, I went to the opposite extreme, using templates engines that simply exposed the data coming from the business layer to the presentation layer in the form of arrays and hashes, using looping statements and simple functions to enumerate items or select between to values. That didn’t help me either.
With my recent experiences in Rails, I’m finally seeing how a framework can eliminate the boredom of writing HTML code while still keeping readability. Rails offers functions to generate HTML but those functions are generally simple and transparent, a simple layer over the presentation layer itself. This thin layer is flexible and it’s simple to customize the functions to generate only what you really need. They save time on simple tasks without preventing complex tasks from being done.
Rails, of course, is not perfect. Some of its functions can only be customized if they are overridden — error_messages_for comes to my mind, for example.
Others tools are worse. PHP blends logic and presentation in an unacceptable way. On the other hand, .NET presumes to separate them but they remain tightly coupled behind the scenes. The various libraries and frameworks for Java make both mistakes. Rails attained a good balance of this area mainly because of its good use of MVC, but care must be employed when designing new function to avoid trying to excessively simplify things.
Anyway, it seems things are starting to get better. More and more people are thinking about those subjects, and I believe new libraries will be even more practical in this area.
May 30, 2005 at 11:48 pm · Filed under Software Development
Ju Rao’s Homepage features a big list of (supposedly) free computers books. The list also includes tutorials and lecture notes, and the topics range from database programming to web programming.
« Previous entries ·
Next entries »
