BigSmoke

Smokes your problems, coughs fresh air.

Tag: Sicirec

Hardwood Investments Wiki

July 16, 2008 /

Before the company was forced by the Netherlands Authority for the Financial Markets (AFM) to seize most of its activities, Sicirec had always used it website to provide teak investors with a somewhat independent view of the hardwood investment market. It has to be said that Sicirec’s critical view on the management of various teak plantation made the company a little unpopular with said managers (such as Ebe Huizinga of Flor y Fauna fame).

Screenshot of my Hardwood Wiki

Like I said, Sicirec had to suspend most of her activities as an intermediary by mandate of the AFM. In order to survive and to continue the realization of their philosophy the company had to reorganize and focus on new projects. Where previously they had been focused on servicing the interests of a investments in third-party projects over which they had little to no control, they’re now developing their own projects (and also are still offering investments in the Sicirec Forestry Mixfund, which is the only investment option that remains of the old organization form).

As a previous Webmaster of www.sicirec.org, I had never been entirely satisfied by the limited possibility to really effectively inform all types of hardwood plantation investors within the constraints of a company website. That is why, during the final website cleanup round, before I resigned as Webmaster, I started a wiki about hardwood investments independently of Sicirec. With permission by Popko van der Molen, my dad and then director of Sicirec SA, I used much of the existing information about the various plantation companies that Sicirec maintained on their website as the seed content for this wiki.

Actually, most of the seed content was in Dutch, so after translating some of it for the English language wiki, I started a Dutch language version sister wiki and copied most of the content there. Since then (May, 2007), the Dutch version has grown to 500 pages, while the English version has remained at a meager 77 pages.

If you have anything you want to know or say about hardwood investments, you might like one of my wikis:

Scaling bitmap graphics versus scaling vector graphics

February 27, 2007 /

Due to some organizational changes, past December, I had to remove the S.A. suffix from the Sicirec logo:

Sicirec logo with “S.A.” - scaled some time earlier
The original logo with the “S.A.” suffix intact.

After removing the S.A. suffix from the vector file in Illustrator’s vector format, I wanted to export the logo to a small PNG again. Annoyingly, though, the PNG—if I wanted Illustrator to respect the correct aspect ratio—could not be the same width as the original PNG if I gave it the same height; it would always be one pixel higher. If, however, I exported it as a huge PNG corresponding to the vector’s original dimensions and scaled it down in The GIMP, the dimensions turned out about the same.

It was then that I noticed that The GIMP’s scaling algorithm is actually very decent. From just looking at the two images below, you need a moment or two to notice that one is a little sharper than the other. Obviously, that’s the Illustrator version.

Sicirec logo without “S.A.” - scaled in The GIMP Sicirec logo without “S.A.” - scaled in Adobe Illustrator

In the end, though, neither version integrated easily with the complex layout which I had based around the logo image, so I simply opened the existing PNG image in The GIMP and erased the S.A. suffix.

Sicirec logo with the “S.A.” suffix removed in The GIMP
The original PNG after the GIMP treatment.

I still don’t understand why I couldn’t repeat the scaling result of the original image in Illustrator. But, I’ve probably wasted enough time on a rounding issue that isn’t even an issue…

Apache’s ForceType directive overrides AddCharset directives

February 26, 2007 /

Yesterday, after uploading a refreshed www.sicirec.org, some character encoding issues popped up because I had converted the website’s content from ISO-8859-1 (Latin 1) to UTF-8. (I wanted to be able to type and paste special characters from PuTTY into VIM without worrying about the particular encoding of each file.)

The Apache HTTPD at InitFour, our webhosting provider, is configured to send ISO-8859-1 by default, while the one on our test server is configured for UTF-8. This caused a little bit of a surprise when I uploaded the refreshed website and saw all characters outside the ASCII range mangled on the life website!

I quickly dug into my .htaccess file to add the AddCharset utf-8 .xhtml directive. To my surprise, this didn’t do squat. A lot of fiddling, reloading and researching later, I realized that the following section in my .htaccess file rendered the AddCharset directive irrelevant:

<Files *.xhtml>
ForceType text/html
</Files>

I had to change the ForceType directive to include the charset as a MIME parameter:

<Files *.xhtml>
ForceType 'text/html; charset=UTF-8'
</Files>

Now, it all seemed to work. (Except that it didn’t really because I do some ridiculously complex content negotiation stuff involving a 406 handler in PHP that virtuals the most appropriate variant when no match is found. This script didn’t send a useful Content-Type header. After first adding it to the script, I noticed that the AddDefaultCharset is actually allowed in .htaccess context—a discovery which luckily rendered the other hacks useless.)

Replacing the trunk of a Subversion repository with a feature branch

February 25, 2007 /

For the Sicirec website, I use Subversion to track all changes. When working on big changes which take more than a day to implement, I follow the Feature Branches branching pattern. This pattern means that the trunk remains relatively stable and usable for everyday updates while I can climb in a feature branch whenever I want to work on the big new feature(s).

Subversion’s merge tracking is non-existent. This means that, when I climb from branch to trunk and back again a lot, I have to manually keep track of all the changes in trunk/ that I merged into the branch. Every one such change, once merged, loses much of its meaningful history unless I painstakingly merge all the commit messages of the patch into the message of the commit that I do after the merge.

Today, after having maintained a branch for months to keep it somewhat in sync with an every-changing trunk, I’m at the point of having to merge the branch back into trunk. This is rather nightmarish because there are bound to be the many merge conflicts that I already suffered whenever merging changes from the trunk into the branch and then multiplied some.

To avoid torture, I decided I’d rather just replace the trunk with my feature branch. This is especially attractive because I then retain the history of the branch which is a little more useful to me than the history of the trunk.

I googled around a bit and could find one thread discussing a similar problem. The solution proposed there seemed to involve a few too many steps for my taste, so I did the following:

# From the working copy of my branch:
$ svn del file:///repos/trunk -m "Temporarily deleted trunk."
$ svn mv file:///repos/branches/my_branch file:///repos/trunk -m "Moved /branches/my_branch to /trunk"
$ svn switch file:///repos/trunk

That worked perfectly fine. (Except that I still want automatic merge tracking, dammit!)

Unique constraints and indexes in PostgreSQL

February 2, 2007 /

This afternoon, I had to add a unique index for some table in the Sicirec PostgreSQL database. I had already assumed that I needed to use CREATE UNIQUE INDEX to create my new unique index until I noticed, thanks to pgAdmin‘s clear GUI, that some tables clearly had unique constraints and unique indexes while one table lacked a unique constraint and only had an unique index defined.

This motivated me to take a closer look at PostgreSQL’s documentation on unique indexes:

Note: The preferred way to add a unique constraint to a table is ALTER TABLE ... ADD CONSTRAINT. The use of indexes to enforce unique constraints could be considered an implementation detail that should not be accessed directly. One should, however, be aware that there’s no need to manually create indexes on unique columns; doing so would just duplicate the automatically-created index.

Grepping for CREATE UNIQUE INDEX in our migration history quickly revealed that the index which lacked an accompanying constraint was indeed created by CREATE UNIQUE INDEX instead of by ALTER TABLE ... ADD CONSTRAINT. So, now I know that, indeed, I have to use ALTER TABLE ... ADD CONSTRAINT instead of CREATE UNIQUE INDEX to add unique constraints with accompanying indexes to existing tables.

© 2024 BigSmoke

Theme by Anders Noren — Up ↑