technical

You are currently browsing the archive for the technical category.

I’ve just added (the beginnings of) a new feature to YAK (user-funded development) that will probably only be useful to one or two users — but it’s worth mentioning anyway.

[yak_get_remote...] is a new tag which can be used in a product post. This allows you to set up a store on one blog, then use the products (posts) on another. The basic idea is that you can have a central store with all your products, then separate (smaller) sites which pull in specific relevant products. When you click the buy button on the smaller site you are, of course, redirected to the central store.

There are 2 fundamental limitations:

1. it currently only works with libcurl (thus your PHP install must have curl enabled)
2. there is no way (at the moment) to redirect back to the original site. For example, the central store might be setup on site A, and 2 or 3 specific products linked on site B. A customer clicks the buy button on a product in site B, and is redirected to the shopping cart on A. At which point the cart should present a link to return the customer to the calling page.

Usage of the new function will be as follows:

1. On the Yak->Settings, under the Advanced tab, set a remote server and path. For example:

http://myserver.com
/myblog

2. In a post, use the tag: [yak_get_remote_n] where n is the id of the post in the remote store. For example:

[yak_get_remote_9]

Which will embed the content of post #9.

The new functionality does point toward a necessity for affiliate functionality (as briefly mentioned here) — but that’s a much larger effort that may need to wait. The new tag is currently in the repository, and will appear in the next release of YAK.

This post is to capture (in one place) a number of features (and thoughts around those features) that have been suggested for future versions for YAK, both via email, and on the Suggestions page. It may also spark further discussion. Presented in no particular order:

  • Affiliates program - setup affiliates in YAK settings (select from registered users), then affiliates would be able to login to your WP admin panel and view their progress, perhaps setup keywords to manage a campaign? Not sure here. I favour a simple approach as much as possible, but it very much depends on whether a simple approach provides any value. This is probably one of those features that might have to wait until someone wants to fund the development, because it’s only a real user who’s going to come up with something that actually might be useful in the real world.
  • Better address configuration — which fields should be included, how they should be labelled (over and above the i18n labelling). Which leads onto…
  • Better WP integration — a registered user could enter their address, and this would be used when ordering. Which, as a by-product, should mean that a user could login and see their order details (i.e. order tracking).
  • Multiple shipping options — at the very least provide for a configurable number of shipping options. Better yet, provide hooks for alternative shipping engines.
  • Tax Calculation — calculating the Infernal Revenue Services’ cut of your sales isn’t something YAK does at all, at the moment, which has been a problem for some. At the very least, a simple tax calculation engine would allow you to specify a tax percentage for a country (have to add states, for the United States and Australia), but would this be enough? Feedback sort on this particular possibility.
  • Workflow — at the moment we have “Send Stock”, “Cancel Order” and “Reset”. Are those enough? I started an email discussion with a user about a year ago about workflow, but they never replied after an initial couple of messages.
  • Order filtering — the ability to specify date ranges, display today’s orders by default, etc (suggestions?)
  • Product filtering — at the very least, a pick list of the alphabet for filtering at the top
  • Export — csv(?) export of your orders, your customers, and perhaps your product list. The latter may not be necessary, if I come up with something reasonable in terms of an xml feed for products.
  • Wordpress MU compatibility — only if I find a step-by-step installation guide that’s any good…
  • Cart widget — display the current basket contents (summary) on the page.
  • More download options — one request has been to allow for a configurable email to be sent out (rather than a download link). I was also thinking about tokens for support activities (i.e. buy a support token), which lead me onto the idea of creating a semi-secure sub-page of the download product (in this case a “support product”) where customer and technician can discuss the job. Useful for me, and at least one other user I’ve talked to, but it’s a fairly limited domain, so not sure about adding it as a core feature.
  • Checkout navigation breadcrumbs (suggested by Chris). Fairly easy to add, so this will go up the priority list.
  • Related products — “other products you may be interested in” (again suggested by Chris). Displayed when a customer adds to their basket.
  • Additional gateways — one of authorise.net or PayPal Payments Pro integration. And fix Google Checkout so that we have end-to-end integration.
  • SKU — I added product code quite a while ago, intending to use it for SKU, but it doesn’t make sense in light of multiple product types (one product with multiple types will have multiple SKUs). Adding SKU support also means adding the facility to search by SKU with a suitably nice URL (obviously time to brush up those mod rewrite skillz).
  • Rewrite! Tidy up the codebase. Or start again with lessons learned from the past couple of years, and spend more time in the WP codebase to make sure YAK is consistent. This will happen once I win the lottery (considering I buy a lottery ticket about once every 1-3 years, calculate the probability for yourself ;-) )

And some additional stuff (not specifically related to development):

  • Add discussion forums and move all the comments into the forums. I tried to do this before, but probably could’ve done it better, so might be worth trying again. Having 450 comments in General discussion is getting rather unwieldy.
  • Site redesign — easier if WP properly supported multiple themes

I think that’s pretty much it. If there’s something I’ve missed that you think should be in this list, please leave a comment here. If anyone wants to fund development on one or more of these items, send me an email to discuss, otherwise you’ll have to wait until they trickle in over time.

I’ve been looking at providing a basic xml product feed through YAK (needed for some rather esoteric customer requirements) — at the experimental stage, rather than a feature that will actually make it into development or release. I cast around for some standardised XML formats, and hazy recollection (thanks TOGAF) popped ARTS into my head. ARTS is the Association for Retail Technology Standards (developed by the National Retail Federation — NRF’s byline is “The Voice of Retail Worldwide”. Not to be petty, but wouldn’t International Retail Federation be a better name if you’re talking global?) and they publish a bunch of schemas which I figured may be useful — particularly their inventory schema. Why come up with my own format, when I can use the work of someone else?

Unless, of course, the work of “someone else” amounts to a half-meg schema file.

Now, my spider senses start tingling if I come across a single schema file that’s over a few 100 kilobytes, but Netbeans gets it’s knickers in a right proper twist if you try to generate sample xml from this epic monstrosity. 289MB generated before I managed to kill the process.

And oh, what an xml. I don’t think separation of concerns was a primary, secondary or even tertiary thought for whoever sat down with tool in hand to design this particular ’standard’. If a simple type named ActionCommonDataTypeCodesEnumeration isn’t worrying enough, the fact that it contains terms such as Begin, Cancel, Complete, Create, Delete, Dispatch, Lookup, Initiate, Instruction, Information, PartialCancel, PartialComplete, Read, Request, Update, and so on, hurts the back of my brain.
Let’s not get started on PriceCommonData, UnitPriceCommonData, and the myriad other CommonDatas littered through the document. Ack. Aching brain.

Okay, yes, I’m not the target audience, and I haven’t paid the US$149 for the documentation, so I may be reading more into the schema than I probably should, but if I look at it through even slightly REST-tinted glasses, it frankly gives me the heebie-jeebies.

Suffice it to say that I will probably not be using ARTS’ inventory.xsd for my, much simpler, requirements. I may indeed roll my own, but happy to entertain suggestions if someone has a better idea.

…goes to Roy Fielding for the excellent:

That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating

Installing MySQLdb on a Mac is slightly more challenging than expected. It seems like it’s easy enough if you go down the dmg install route; however, I decided to save some time and install the s/w stack I needed using MAMP. Which really is a brilliant time-saver… but not when it comes time to get Python and MySQL talking to each other.

I had a number of problems, some of which are documented here, and starting with this thread here. However, the final clue came from this post. I’ve differed slightly from his solution, basically performing the following steps:

1. install MySQL using MacPorts.

2. copy the libmysqlclient_r dylibs from the mysql dir to the MAMP lib dir, with something like:

cp /opt/local/lib/mysql5/mysql/libmysqlclient_r*dylib /Applications/MAMP/Library/lib/mysql/

3. run the build for MySQLdb (python setup.py build). The final step fails, but you can re-run the GCC command to remove the wrong architecture (-arch) option. In my case, it unnecessarily added -arch ppc. So my final gcc exec is:

gcc -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 build/temp.macosx-10.5-i386-2.5/_mysql.o -L/opt/local/lib -L/opt/local/lib/mysql5/mysql -L/opt/local/lib -L/opt/local/lib -lmysqlclient_r -lz -lm -lssl -lcrypto -o build/lib.macosx-10.5-i386-2.5/_mysql.so

4. create a dir in /Library/Python/2.5/site-packages called MySQLdb and copy the contents of build/lib.macosx-10.5-i386-2.5/ and build/lib.macosx-10.5-i386-2.5/MySQLdb into it.

With any luck you should now be able to connect to the MAMP install of MySQL through Python.

Well, not quite epic. But I certainly managed to make a mess of this last release.

If you’ve downloaded version 1.1.2 of YAK, please try again with 1.1.3. There was a slight problem with the promotion code, calculating percentage-based pricing discount when integrating with PayPal or Google Checkout.

One of the more frequently asked-for feature additions to YAK is support for multiple prices, for products with more than one type. For example, small, medium and large t-shirts should be able to support more than the one price. Well, at long last, version 1.1.2 now supports the concept of an “override price” — set against a specific category of product.

Also included in this release is the facility to add promotions (i.e. discount codes that run for a specific period) — a custom piece of development paid for by a YAK user (thanks Chris!) — Czech translation provided by Frank, and Spanish translation provided by Josep (thanks guys).

The full changelog can be found here: http://www.briggs.net.nz/hg/yak/raw-file/tip/release_notes_1.1.2.txt.

As usual YAK can be downloaded from the WordPress Extend site.

I’ve just committed some minor updates to my Stomp client (stomp.py):

1. removed the ‘lower()’ on header keywords to support case-sensitive headers (patch submitted by Eugene S).

2. added the facility to wait until the socket is connected before issuing a “CONNECT”

3. removed the space between header and value (i.e. header: value becomes header:value) which fixes an incompatibility with RabbitMQ

4. added the missing connect headers (user/pass) to the “CONNECT” command (again fixes an incompatibility with Rabbit).

As usual changes are committed and you can get the latest version from my Mercurial repo here.

I’ve just released a minor update to Yak, fixing a problem found with the products page.

Download it here.

I’ve finally released the first version of the Installation Handbook for YAK (see here for more information). While this is just the first release, if you decide to purchase the handbook, you needn’t worry that it’ll soon become out-of-date — whenever I release a new version, I’ll be sending out copies to everyone who previously bought a copy.

The Handbook covers basic installation, setup for gateways such as PayPal and Google Checkout, downloadable products, multiple types of products, etc. If you’re having difficulty with the basic instructions on the YAK page, this is hopefully the best place to start.

I’ve just released YAK version 1.1.1 (although it won’t show up on the WordPress site for a while).

This release includes the following changes:

  • “Hard-code” the PayPal IPN page. This means you don’t need to create it manually. Instead just specify: http://yourdomain.com/wordpress/wp-content/plugins/yak-for-wordpress/yak-paypal-ipn.php
  • Add Italian translation, provided by Roberto Mogliotti.
  • Change the download message to use the tag [downloads] rather than a code.
  • Change the email confirmation message to use tags rather than codes.
  • Fix a nasty problem zeroing price and alternate title when commenting on a product.
  • Fix a problem with the random order number.

I’ve also removed support for the old tags (the html comment form such as <!−−yak_buy−−>), so you’ll need to change your posts to use square brackets if you upgrade (e.g.

YAK shopping cart plugin for WordPress
).

As usual, this release has only been fully tested by… well, me… so there may be some bugs I’ve missed — if you find something, please post on the Bugs page or email me directly.

I’m experiencing a rather annoying technical problem, which is holding up the YAK release — and consequently the release of the YAK Handbook.

Google Checkout integration requires https, but when testing I’m currently getting the dreaded error:

Protocol https not supported or disabled in libcurl

This despite the fact that curl -V gives:

curl 7.18.2 (i386-apple-darwin9.4.0) libcurl/7.18.2 OpenSSL/0.9.8h zlib/1.2.3
Protocols: tftp ftp telnet dict http file https ftps
Features: Largefile NTLM SSL libz

And port installed gives the following output (excerpted):

curl @7.18.2_0+ssl (active)
curl-ca-bundle @7.18.2_0 (active)
lighttpd @1.4.19_0 (active)
mysql5 @5.0.51a_0+server (active)
php5 @5.2.6_1+fastcgi+macosx+mysql5 (active)

I’m obviously missing something, but no idea what. Hoping that any Mac gurus who happen to come across this might have a suggestion or two…?

Cloud Camp London:

First talk, good. Last talk, good. Stuff in between… meh.

Highlights of the evening: catching up with Ben. And, after 7 years, finally meeting Alan (the last talk!) in person…

…even if it was only for a few minutes. ;-)

I’ve just released a bug fix (version 1.0.3e) for the stable version of YAK. This fixes the bug where prices are cleared if a customer submits a review (by commenting on a product).

If you’re using 1.0.3d, I recommend you upgrade immediately.

The experimental release (1.1.0-exp) is still unpatched, and will be replaced by version 1.1.1 in a few days.

There’s a nasty bug in the latest version(s) of YAK. It’s definitely present in 1.1.0-experimental and probably in 1.0.3d as well. Basically if you have comments enabled on products, and someone adds a comment, it can wipe the prices.

It’s fixed in trunk (in source control), and I’ll be releasing an updated 1.1.1 version shortly which includes the fix. I’ll also be releasing a patched version of 1.0.3d just in case people don’t want to upgrade to the latest and greatest.

In the meantime, if you’re running either of those versions, I recommend you disable comments on those products for the moment.

Why do Apple laptop upgrades cost 200% more than Dell’s?

Erm… economies of scale might have something to do with it, perhaps?

CNet only manages to touch on that in their conclusion…

So why so pricey, Apple? Less buying power? Greed? Good business sense?

…whereas it perhaps should’ve been the focus.

A quick googleage would’ve uncovered that in the 3rd quarter of 2007, Apple sold 1.1 million Mac units in the US. Dell sold 5 million PC units in that period. I’m going on the assumption the difference is similar on the worldwide scale, but perhaps it’s not. Dell’s worldwide figures might be much larger in comparison.

In any case, if I’m buying 1 million items from you, it seems likely I’m going to get a much larger discount than someone who’s only purchasing around a fifth of that amount. Which might account for at least a percentage of the difference. It might not as well, but surely the possibility invites more than 3 words in a conclusion…?

I’ve decided to release 1.1.0 of YAK for Wordpress as an “experimental” version. It hasn’t been fully tested yet, but enough people are hanging out for some of the features that I hope a few early adopters might kindly help out with the process.

1.1.0-exp includes features from the not (publically) released 1.0.4:

  1. Add new non-unique order id
  2. Move javascript on cart off page and into separate script. split javascript into generic and admin specific files — to stop problems with (missing) jquery on the wp pages.
  3. Add warning message for people with session.auto_start turned on.
  4. Integrate YAK back into the WordPress menu structure. The top-level menu was a nice idea, but it’s inconsistent with all other plugins (plus isn’t recommended, according to the WP devs). You can now get to YAK’s options through Settings->Yak, and to Orders/Products/Sales Reports from the Manage menu.
  5. Fix PHP4 problem with the view products screen

Along with a few additional features:

  1. Add https support
  2. Add first cut of Google Checkout integration.
  3. Tidy up setting payment types (drop downs now rather than input boxes). Add setting of a credit card landing page.
  4. Add support for tags with square brackets [ ]. The html-comment version of tags will be removed in an upcoming release

Google support is minimal so far. It’s one-way integration at the moment (allowing customers to submit an order through Google Checkout) — with no automated return path for handling purchase. That will come with a later release.

These updates hopefully make configuration a lot more user-friendly — particularly the changes to the Payment Types. Note that if you decide to upgrade, please make sure you backup your installation, and you double-check all your configuration options after upgrading.

YAK version 1.1.0-experimental can be downloaded from the WordPress Extend site.

I’m now charging for support of YAK for WordPress. Basically for anything that can’t be handled via a few messages on the General Discussion page or on the Bugs page.

The main reason for this change is that I can’t justify (particularly to the family) the amount of time I spend both on development and bug fixing, AND on the volume of support requests I get (at times).

See the new Support page for more information.

A recent file rearrangement on my server resulted in all the links for “Snake Wrangling for Kids” breaking.

The problem is fixed now, and the zip files should be accessible again.

YAK 1.0.3d has been released (the WordPress plugin page hasn’t updated yet, but the files are currently available from Sourceforge).

Please backup your existing installation before upgrading. Deactivate, remove the current yak-for-wordpress directory, then copy the new version into the plugins dir and re-activate. You’ll need to double-check the configuration settings, because many input boxes have changed to drop-down selects (for category and page selection for example… see below). This upgrade will also require you to go through your products and set the price in the “YAK Product Details” tab (see point 5 in the changes below) — the custom fields are no longer required.

This release includes the following bug fixes:

  1. Problem with table creation.
  2. Country options not saving properly.
  3. Fix an odd problem with globals.
  4. The return URL appears to be broken with PayPal IPN. PDT works fine, but IPN seems to wind up back at the home page of the blog. Added a fix to cleanup the order from the shopping cart when this happens.

And the following changes:

  1. Frank Malina’s new look-and-feel.
  2. French translation (provided by Charles Dixon-Spain).
  3. Change money format and currency format to be simpler drop down boxes.
  4. Change the download url from the settings screen so it is now an override (i.e. optional).
  5. Add new data input on the post/page edit screen for yak price and title (replacing the old method of using custom fields).
  6. Remove the “Auto Set Price” option (doesn’t make a huge amount of sense now).
  7. Fix the Auto Set Quantity so it works with selected categories.
  8. Tidy up the stylesheet.
  9. Add a hidden link to the checkout and to the buy button form — vain hope that this might drive more search engine traffic to the YAK plugin page — if you don’t want the link included, it can be switched off on the Basic settings page.
  10. Change the product category (settings page) from an input box to a dropdown.
  11. Change the redirect on buy (setting page) from an input box to a dropdown.
  12. Change the return and cancel urls on the PayPal settings page to a dropdown so you can select a page rather than having to type a url.

The latest YAK release is slightly delayed because I’ve, thus far, been completely unable to test PayPal integration.

First problem: The return URL doesn’t appear to work (cancel return URL works fine). PayPal keeps sending me back to the index page of my test site.

Second problem: When trying to save the Website Payment Preferences (in PayPal Profile) I get a “Page Not Found” error. So there’s no way to change between IPN and PDT. This has been broken now for at least 5 days.

If anyone is using YAK and PayPal and is willing (and able) to test both IPN and PDT integration, please let me know. Worst case scenario, I’ll release this version as unstable, and wait for PayPal to fix their problems…

UPDATE: Problem solved. PayPal have updated their site, but this has somehow corrupted old test accounts. Deleting the old account and creating a new one fixes the problem.

Interestingly, there doesn’t seem to be a WordPress Community group on LinkedIn.

Or, possibly, there are dozens. There’s no way to tell since LinkedIn’s Group directory isn’t open and also isn’t searchable. Unless you’re lucky enough to find the relevant group on someone’s profile, you’re stuck with creating your own.

So that’s what I’ve done. If anyone is interested in joining, the invitation link is in the groups section of my profile.

And let’s hope LinkedIn develops a really good ratification process for merging millions of one-member groups… ;-)

It’s been over 2 years since I released YAK for WordPress (6th of March, 2006 according to Sourceforge), and the forthcoming release finally starts to tidy up a few loose ends. It was always a bit hacky — from a user interface perspective, that is — and 1.0.3 sorts out a few of the most obvious problems (this is not to say it’ll be perfect, of course).

YAK has always represented a reasonably significant investment in time. I don’t put a huge amount of effort into development now that it’s hit the 1.0 release, but popularity brings an inevitable increase in the number of calls for support.
Family commitments mean that I have less time available — or at the very least, it’s harder to justify spending the time. The obvious answer, suggested by a couple of people, is to commercialise (at least in part) the plugin.

There are plenty of open source projects which have at least a small commercial component. And plenty more which are mainly commercial, but release unsupported open source versions. An example of the former are projects which have paid-for documentation. An example of the latter would be something like JBoss or MySQL, which release community and enterprise versions of their apps — the enterprise version, rather obviously, providing commercial support.

So this brings me to a question: where to, with a semi-commercial version of YAK?

There are a few options on the table:

  1. Reduce the detail of the online documentation and release a paid-for installation manual.
  2. Release a supported, commercial version of the plugin with the latest features, and the open source version (with those features) would follow a few months later (only the commercial version would be supported).
  3. Per-request charge for support, perhaps based upon the time taken.

What do you think? Any better ideas?

Well… not so sudden.. but yesterday I realised that this year will be the 30th anniversary of the first time I sat down in front of a blinking white cursor.

Said cursor was a small rectangular block, about 4 millimetres by 5 millimetres, and the machine was the Radio Shack TRS-80 — bought by my father for what is, now, quite a lot of money for a computer, comparatively speaking. That was also the year I started to learn programming (BASIC) — using a book which was the inspiration for my own programming book for kids. I was 8 years old at the time (in case you were wondering).

Thirty years is quite a long time to be using computers — although that’s elapsed time, rather than actual. There was a good period in my late teens when motorbikes were far cooler than computers…

If anyone is interested in previewing YAK 1.0.3, please get in contact. This release adds a new (admin) UI design (provided by Frank Malina), and fixes a couple of nasty bugs that emerged with the latest version of WP (tables not being created, globals not working as they used to, etc).

Apart from the new UI, there are no major feature improvements in this release, however there are a couple of “big ticket items” I’m thinking about adding in version 1.0.4.

In a moment of either inspiration or madness (I’m pinning my hopes on the fact that there’s a thin line between madness and genius), I decided to start work on a version of SWFK for the OLPC.

There are a couple of reasons why this is more of a challenge than the other versions of the book:

  1. I don’t have an OLPC
  2. The version of Python installed on the OLPC includes neither Tkinter nor, more importantly, the turtle module.

The first point is easy to solve. I’ve been running OLPC on VirtualBox (occasionally) for a few months now, so at least I have a vague idea of how to interact with the Sugar interface.

The second point is slightly more problematic. As far as I’m aware, the OLPC runs GTK, and so the pygtk module is available — but I have yet to come across a turtle implementation for gtk (ignoring, for the moment, the TurtleArt activity already installed on the OLPC, which I don’t think is particularly useful for my purposes).

It seems like quite a fun project — implementing the turtle module using pygtk — until you consider the arcane pygtk API, the (IMHO) lack of reasonable documentation (I’m not particularly impressed by the pygtk reference manual… particularly the lack of index), and simple examples to expand from.

Technical issues aside, a week later, I’m considering the semantics of an OLPC edition of the book. SWFK for Windows, Mac and Linux, all target the same fundamental audience. An OLPC edition has a completely different potential audience. The Western+English market is, no doubt, vanishingly small — so while, to date, I’ve had over 6500 downloads, I’m guessing an OLPC edition might garner less than 1-3% more. The real market would be translated versions (assuming the interest in translating actually results in translations) — but that begs another question: will kids in non-Western countries actually understand some of the references? Is talk of DVD players, in-car computers, Nintendos, etc (i.e. some of the references in chapter one, for example), at all meaningful in the developing world? I’m doubtful.

Which leads me to posit the question, is it worth the not-so-insignificant effort?

What do you think?

Genius or madness?

Long awaited by… well a couple of people at least… I’ve recently been working on splitting out Snake Wrangling for Kids into 3 separate editions: one for Windows, one for Mac and one for Linux.

This proved rather more challenging than expected (rather characteristic of LaTeX as a whole actually), and I haven’t fully proofed the final result yet. Those interested can check out the new editions here:

SWFK - Linux Edition
SWFK - Mac Edition
SWFK - Windows Edition

The Mercurial repository (here) containing the LaTeX source has also been updated with the latest changes.

So I’ve sort-of figured out how to do conditional blocks. The following LaTeX initially appears to work:

\newboolean{cond1}
\newboolean{cond2}

\setboolean{cond1}{false}
\setboolean{cond2}{true}

\ifthenelse{\boolean{cond1}}
{
A block of conditional text in here.
blah blah
}

\ifthenelse{\boolean{cond2}}
{
A separate block of conditional text in here.
blah blah
}

I say initially appears to work, because it works fine for the first 4 or 5 attempts, but then some combination of blocks (\begin{verbatim} for example), causes it to break on the 6 attempt. If I include a verbatim block in that 6 attempt, latex outputs an obscure error message… something along the lines of:

Runaway argument?
some code here \end {verbatim} \end {listing}
! Paragraph ended before \@xverbatim was complete.
<to be read again>

Which is rather infuriating, considering that I’ve got verbatim blocks in the previous conditional sections (it doesn’t complain about those), and because I’ve almost got the answer to my problem.

Does anyone out there know of a way to have conditional blocks in LaTeX that are controllable by external parameters?

The sort of thing I want to do is something like:

\configurablesection{someparameter_1}
some stuff here (this is block1)

\configurablesection{someparameter_2}
some different stuff here (this is block2)

Then, from the command line, set a parameter to include the text in block 1 AND/OR in block2, and produce different output as a consequence.

Any pointers welcomed!

I’ve had a few requests to release the “source” to Snake Wrangling for Kids, by people interested in translating the text into another language.

SWFK is still a work in progress — although that progress has been rather slow since we moved to the UK — but I can’t see any reason why I should put off releasing the LaTex source until some sort of mythical completion date, particularly not when there are willing participants out there.

So for those who are interested in translating SWFK to another language, the latex “source” can be found in the following Mercurial repository:

http://www.briggs.net.nz/hg/swfk

Note that it isn’t “buildable” in its current state. I haven’t added the image files yet because some of them are rather large (the cover alone is over 2MB) — the wonders of the EPS format. Mercurial doesn’t seem to handle excessively large image files that well (at least not on my web host it doesn’t), so if anyone has ideas on that front, let me know.

I’ve just fixed (rather hurriedly) an annoying bug in domyinvoice.com. Invoices generated for a project with a daily rate (rather than hourly) were calculating the days incorrectly — basing the calculation on the number of tasks rather than the distinct list of days. Easy to fix, but since I haven’t been doing any Python for the last couple of months, it took a few hours longer than it should have.

Do My Invoice, my web-based, RESTful invoicing solution, has been live for a couple of months now. Admittedly there hasn’t yet been a large number of registrations, probably because I haven’t really promoted it other than through this low-traffic blog, and because I hope that word-of-mouth may eventually kick in and result in a few more paying customers.

Interestingly though, I’ve somehow made the second page of Google results (currently sitting at position 16) for the keywords “web based invoicing”.
However, for the term “web based invoice”, the site is either so far down the list it can’t be found, or it doesn’t appear at all.

Also interesting: 3 weeks ago, DMI was at position 83 for the search term “invoices”, yet I can’t find it anywhere in the first 100 pages now — obviously we hit a broken rung in the Google ladder and fell down a few hundred feet.

Completely off-topic, but one thing this has highlighted as a gap in Google’s toolset is “Search Within”. It would be really useful to enter a few search terms, then find exactly where another term sat in those results. In other words being able to enter something like: “domyinvoice within: web based invoicing“, which gave you the results found within a set of results, along with the index positions. Seems like a killer Google feature for web developers, marketers and the like.

YAK 1.0.2a

Yet another release of YAK — this one fixes a problem with activation. Basically the db tables weren’t being created on a new activation (i.e. the first time it’s installed). This wouldn’t have affected upgraders.

Apologies to anyone who had problems, and hopefully this release will work better.

A recent release of Do My Invoice was a minor update to add more documentation for the various resources used in the application. DMI is a REST application — well, at the very least, that was the initial design goal — so there are some basic access points for most system resources.

For example, you may call GET to request your user profile:

    http://www.domyinvoice.com/resources/[username]/profile

Using CURL the request:

curl -X GET -u joebloggs:password http://www.domyinvoice.com/resources/joebloggs/profile

…will return something like…

<profile>
    <username>joebloggs</username>
	<email_address>joe@bloggs.com</email_address>
	<first_name>Joe</first_name>
	<last_name>Bloggs</last_name>
</profile>

Resources in DMI are self-describing, thus with the addition of a single parameter, you can view the documentation for that resource. Thus the url…

http://www.domyinvoice.com/resources/joebloggs/profile?help

…returns a list of the HTTP verbs accepted by the resource, basic description and more detailed information about each verb. If you don’t have an account (it’s free for the first month, by the way), you can see a static version of this help information here.

Another example, is the clients resource. You can GET a list of clients:

curl -X GET -u joebloggs:password http://www.domyinvoice.com/resources/joebloggs/clients
<clients>
	<client id="76">
		<client-name>test company</client-name>
		<address1>address line 1</address1>
		<address2>address line 2</address2>
		<city>London</city>
		<postcode>sa1 sa2</postcode>
		<country>United Kingdom</country>
	</client>
</clients>

A client can be added with the use of an HTTP PUT:

curl -X PUT -u joebloggs:password http://www.domyinvoice.com/resources/joebloggs/clients/test+company+2 -d @-

address_1=23+Wrights+Lane&address_2=Kensington&city=London&postcode=W8+6TA&country=GB&currency_symbol=£&currency_format=1&sales_tax_label=VAT&sales_tax=0.175

Which also returns the created client (assuming nothing went wrong):

<clients>
	<client id="80">
		<client-name>test+company+2</client-name>
		<address1>23 Wrights Lane</address1>
		<address2>Kensington</address2>
		<city>London</city>
		<postcode>W8 6TA</postcode>
		<country>United Kingdom</country>
	</client>
</clients>

Said client could then be deleted with the use of the DELETE verb:

curl -X DELETE -u joebloggs:password http://www.domyinvoice.com/resources/joebloggs/clients/test+company+2

The obvious advantage of using RESTful resources internally is that I’m effectively providing an external API for free — in other words, without requiring any additional development effort.

YAK 1.0.2

Version 1.0.2 of YAK has been released.

This version is a slightly more involved upgrade than previous editions. Because WordPress’s automated build system creates a distribution from the subversion repository, the directory in the filename isn’t just “yak” — it’s “yak-for-wordpress”. This appears to cause problems when I’ve named my main plugin file: “yak.php”. As a consequence, the new name is “yak-for-wordpress.php”.

Thus, before upgrading, you should backup your wordpress installation, then deactivate and remove the old yak directory. Extract the contents of the new distribution and re-activate.

Changes in this release are included in the release notes here, but to summarise:

  1. order status is automatically set to STOCK SENT when all funds have been received for a PayPal order, if the order contains only downloadable items
  2. the ‘default’ category has been removed from the products drop down. This means you can still turn the drop-down on by default for products with more than one option, and the products that are tagged as ‘default’, won’t include the dropdown.
  3. fixed a problem with apostrophes in yak title, download and confirmation email
  4. fixed a problem with PayPal shipping with multiple items
  5. fixed a problem with PayPal verification (item names need to be properly encoded)
  6. tidied up the confirmation email and code

Any problems with this release, please let me know.

Version 0.7

I’ve just uploaded the latest version of SWFK. This fixes a few issues with continuity (such as referring to functions before they were actually explained), adds a basic explanation about the use of brackets and order of operations (which I think was a serious omission given the context), and other minor grammatical and code fixes.

The only major change is to add a few exercises to the end of some of the chapters, plus a new appendix for the answers. This is a work in progress. Exercises are currently missing from Chapter 9, and possibly aren’t as detailed (nor fun) as they should be.

But they’re a start…

The latest version of “Snake Wrangling for Kids” has been uploaded, and is now available on the main page. This is the LaTeX conversion I mentioned in a previous post — but I’ve now applied a Python code checker to 99% of the example source code. Hence I’ve fixed up a few omissions, bugs, and so on.

Automating the testing of example code proved more challenging than expected. In the end, I failed miserably to get doctest working they way I wanted, and had to roll my own testing code which works for a majority of the examples. It’s not perfect, but picked up a few problems, so I’m reasonably happy with the end result… even if it is a complete hackjob.

I’ve finished the initial part of my conversion of SWFK from Word Processor format to LaTeX. Positive aspects? Looks much better than the original; I like working in a text-based format plus I’ll be able to automate the double-checking of my examples (not completed yet); and lastly the file size is a 3rd of what it was (hoorah for my bandwidth!). Negative aspects: the format is more obscure (not a big problem obviously) and the number of pages has significantly increased. LaTeX is a lot more liberal with whitespace than I was, plus I’ve probably accidentally increased the size of some of the images, which won’t have helped. So my apologies to anyone who wants to print it, and has to kill more trees as a consequence.

Download is available from this link, but I haven’t updated the main page yet. Note that this is a draft-draft. In other words, it already was a draft, and now it’s more of a draft… ;-) I still need to tidy up some of my layout ‘messes’, plus re-check all example code, and a few other bits and pieces. Another positive aspective of converting to LaTeX is that I found a bunch of naff typos that appeared in latter chapters (and appendices), where my editing prowess obviously rather severely tailed off…

Feedback on the new format/layout welcome.

I started learning C programming in, or around, 1991. Up until that point, I had been exposed to Basic, Pascal, Modula-2, and (I think) Prolog. C was… somewhat of an eye-opener. Anyone who has had to come to grips with pointers and memory management in C, will know what I mean (and thank goodness for the Borland C IDE help system - unparalleled as a learning tool).

At University, we had papers that required learning a functional language and assembler, but neither of these were like the screaming brick wall that I hit in my second year when I decided to learn C.

Actually, since then, I can’t think of a single technology where I’ve experienced a similarly steep learning curve.

Until LaTeX.

I knew what LaTeX was, of course. But neither had the need, nor in fact, the interest, in learning it before. But after deciding I needed to move SWFK out of the atrocious (and, from an automation perspective, useless) word processing format it’s in at the moment; and after a few aborted attempts to get some reasonable output from various docbook toolsets, I’ve been provided with just the incentive.

But the learning curve is excrutiating.

Get one thing working, and the next thing stops. Change this and effect that. It was all me, of course. There’s nothing wrong with LaTeX after you get used to how it works. But, oh that learning curve. I haven’t felt such a need to scream and yell at my computer in a decade.

This is not to say things are perfect now. I still can’t get the front cover to look centered (advice from a LaTeX guru would be greatly appreciated) and, at times, LaTeX seems to think it knows, better than I do, where to put figures. Working out how to put visible spaces in a \verbatim block is also proving a little challenging. But the overall result does look, in my opinion, much nicer.

Anyone interested in proofreading the new version, please let me know.

I’ve partly changed my mind about the addition of WPForum. I’m leaving it there for YAK, but have decided that it’s not necessarily useful for the other projects (such as SWFK). Instead, I’m giving the wp-thread-comments plugin a try. At least you won’t necessarily have to register in order to comment.

Unless, of course, someone has a better idea…?

Spring has a rather nice scripting framework that I haven’t paid much attention to, more from a lack of need than any real lack of interest.

One thing I recently noticed, is that there are only 3 supported scripting languages: Beanshell, Groovy and JRuby. Now Beanshell (for myself at least) was interesting about 4 or 5 years ago (maybe longer… since I can’t quite recall when it was first released), and I have little interest in Groovy (read “little interest” as “no interest”).

A bit of googling only uncovered a brief discussion about adding Jython support back in 2004 (I haven’t been able to find any code to go with that discussion), and Rhino-in-Spring which, as far as I can tell, is aimed at the web tier. Interesting that 2 of the most popular (IMO) scripting languages are rather conspicious by their absence from the core Spring distribution. Or if not absent, then certainly not very visible.

I’ve been looking for a reason to hack around with Spring extensions for a while, so this seemed like the opportune moment. Following one of the comments in that 2004 discussion, I started with cloning GroovyScriptFactory and a few other classes from the scripting package, and then hacked away the bits I didn’t want or need.

GenericScriptFactory is my abstract base class, and contains most of the code from GroovyScriptFactory. Subclass JythonScriptFactory is the workhorse for Jython scripting, while RhinoScriptFactory is obviously for Javascript code.

The cool part — I’ve implemented a NamespaceHandler for both, so bean configuration looks like this for Jython:

<script:jython id="test1" script-source="test.py"
               bean-name="mytest" return-type="test.TestInterface"
               interpreter="pythonInterpreter">
    <script:property name="test" value="jython prop from spring" />
</script:jython>

and for Javascript (Rhino):

<script:rhino id="test2" script-source="test.js"
              bean-name="mytest" return-type="test.TestInterface"
              scope="jsScope">
    <script:property name="test" value="javascript prop from spring" />
</script:rhino>

You’ll note that in both cases the attributes are passed to the factory, but properties are injected after the bean (in whatever language) has been created. A distinction which is rather useful when you think about it. This is the same as the other scripting languages already built-in to Spring.

You can see the full configuration file here, which includes setting up a PythonInterpreter for Jython, and a global scope for Rhino.

The sweet spot is, of course, this configuration:

<script:jython id="test3" script-source="test.py" bean-name="mytest" return-type="test.TestInterface" interpreter="pythonInterpreter">
    <script:property name="testInterface" ref="test2" />
</script:jython>

test2 is the object created by the Javascript code, and you’ll note that it’s being injected into the object created (in this case) by Jython code. The opposite works as well, meaning you can call Jython code from Javascript and Javascript code from Jython (well, at least through Spring injection). Exactly why you’d want to do this, I don’t know, but it’s a fun feature.

In either case, my classes implement a simple Java interface, meaning the beans created by both scripts are useable from Java as well — as you can see in the Test code:

public static final void main(String[] args) throws Exception {
    ApplicationContext context = new ClassPathXmlApplicationContext(new String[] { "beans.xml" });
    BeanFactory factory = (BeanFactory) context;

    TestInterface ti1 = (TestInterface) factory.getBean("test1");
    System.out.println("jython test: " + ti1.getTest());

    TestInterface ti2 = (TestInterface) factory.getBean("test2");
    System.out.println("rhino test: " + ti2.getTest());
}

Anyone interested can find the whole thing (very much a work in progress) in a Mercurial repository here.

Version 0.4

The link on the Snake Wrangling for Kids home page, now points to version 0.4. In this update, I’ve re-ordered the chapters somewhat (as previously discussed on the Python Edu-sig mailing list), fixed a few references to code that wouldn’t work in Python2.4, included a brief discussion on while-loops, and added a long lamented (at least, by me) Table of Contents.

I have to say, OpenOffice.org is starting to become rather unwieldy. Partly my fault, because of the way I wanted to layout the book, but also because it’s not obvious how to accomplish certain layout & style tasks that are necessary to make a PDF look less like a unprofessional pamphlet and more like a professional piece of work.

Anyway, the latest version is downloadable from this link.

Gusty

My upgrade to Gusty Gibbon (Kubuntu) was a staggering failure to start with. First had some repository fetch failures (my fault for not tidying up Apt’s sources list). Then had a couple of errors extracting (or dl’ing… I forget now) some packages, followed by an error “Modifying software channels” which seemed unrecoverable (i.e. it would interminably hang at that point). Reboot, try again, same problem.

In the end I gave up and downloaded the upgrade CD, burnt it and tried with that, only to experience at least one of the problems again. All seemed lost until I specified -not- to download updates during the upgrade and everything seemed to work swimmingly after that.

Still. Hardly a stunning endorsement for the user-friendliness of Linux… but at least it worked in the end.

Some time ago I decided I needed a text editor with minimal distractions. I can’t stand the sheer volume of buttons on the average word processor. Even AbiWord, which is skeletal in comparison with OpenOffice or Word, is still too busy at times (I miss Q&A Write actually — the Word Processor I used to use back in the days of MS-DOS).

A google search at the time turned up WriteRoom, which is Mac-only. But not much else.

So, of course, I developed my own alternative.

It didn’t quite fulfill the vision, so I dumped it in the “deprecated projects” list after it languished, unused. But I’ve been coming back to the idea lately, and finally did a bit more research on the various buttons you can push in PyGTK.

So, the Vanilla text editor is now -slightly- more supported than it was before (i.e. I’m probably going to use it myself), and is a bit closer to the vision. It’s completely configurable (background and foreground colours, font, key map, etc are all set from an ini file), and now runs full screen (as it should’ve from the beginning).

Only the source is available at the moment (Python2.5 and PyGTK2.0 required), but I’ll eventually make a commercially supported package available if there’s any interest.

Disappointingly, but perhaps unsurprisingly, there are no plugins for WordPress which provide bug-tracking capabilities. Well, at least none that I’ve been able to find. I did consider the possibility of developing one myself, but I have enough to do in my spare time as it is. The family would probably kick me out of the house, if I started another project…

However, I did want a basic bug tracking system for Do My Invoice, and it makes sense to also use it for YAK (and perhaps some of my other low volume projects).

After a bit of searching, I came across Mantis, a PHP bug tracking system which looks simple enough for my needs, and perhaps approachable enough for other users to easily post their issues and feature requests. It was certainly easy to install, which makes it one of the more attractive candidates… (that said, I wouldn’t have minded using FogBugz, but don’t have the budget for the moment).

So if you have features or bugs for Do My Invoice, or for the YAK shopping cart plugin, please sign up for a new account at:

http://www.briggs.net.nz/bugtrack/

In the case of YAK, the comments on the project page is still the place for support issues and, in the case of DMI, the email for support requests can be found on the dashboard after you’ve logged in.

Too Much Cache