Kartones Blog

I’ve just received a license to eval and review a new tool to generate both help files and blog posts, Helpburner. It’s premise is to be quick and easy to use, with a minimalistic interface:

You handle projects, sections and individual topics (or pages or posts, as you want to use it). Inside them, you will add one of the four pilars of editing content:

• Title text block: The typical title
• Text block: One or more paragraphs of text without images
• Image block: One image from the computer
• Screen capture block: An image that you will capture from the screen (obviously targeted at application help files and tutorials)

Each block/element (the selector is the blue part of the following screenshot) has its own options bar, with contextual ones like text align, colors, hyperlinks…

The blocks can be moved up or down and removed. As you might guess, everything is simplified, for the good or for the bad. It is not a Word clone, but is more suited and faster to use than Google Docs for certain tasks.

Helpburner includes a spell checker also, not bad but at least I couldn’t find a setting to disable it.

About the publish formats, three are available: Export to PDF and HTML for normal help fles, and publish as a blog post. Any blog supporting Metaweblog API can be targeted, so all major blogging platforms are supported.

When creating topics you can specify tags and related topics (very common for blog posts).

This is a sample page of a generated PDF with title, text and images:

Lastly, I would like to talk about small problems or features missing. They are not many and considering that the application is still in Beta can be easily fixed or added, so here we go:

• PDF export is pretty basic: Image quality is not bad but images are embedded not at 100% quality . Also you can’t specify any margin size, or a footer/header.
• I had a small bug when resizing an image (a blue box appears to grab a screenshot?), nothing major but a bit annoying.

At a price tag of 79$ I find it a bit too much for individuals. It is for sure easy to use and you can generate PDFs in no time, but it needs more features to make it really interesting. For blogging,  compared with Windows Live Writer (which is free) it might need “something else” apart from the ease of use.

I’m finally dedicating a (decent) amount of time to read books, so here comes one of the latests I’ve read: The Mytical Man-Month.

Really good and as I said in the review, I’m amazed that the author wrote it 35 years ago and most of it still applies to software development and team management. Definetly worth reading!

Just as I have Firefox and IE addons list pages, I’ve also added another Google Chrome addons one. I still use it as a secondary browser but it is gaining points to become the first one because of its great speed, but I’m missing some extensions yet…

To keep the left column of this blog not too full of links, all the browser addons lists are now available from the general Free Developer Tools page.

Oh, and for the whole site, as per my friend Lowtech’s suggestion, I’ve improved the captcha adding letters, with that and some small improvements to the (crappy by default) feedback messages I hope now people won’t have many problems commenting!

More interesting stuff soon!

When coding with PHP, the first requisite is a proper handling of variables, as they are not typed. We can think that the built-in is_int() function will work correctly to detect integer values inside a variable…

Try this:

$param = '1';
echo is_int($param);

It will return false, because it checks that the type of the variable is an integer… not that the variable’s value can be interpreted as an integer ;)

In order to properly test for numeric values, you have to always use is_numeric() (documentation), and then one of the following options:

a) Do a cast (this works ok to detect floats, but will still fail with integers):

$param = '12.5';
echo is_float((float)$param);

b) Create a regular expression to check numeric formats.

Once again, the problem of untyped languages rises up. With a correctly typed language this wouldn’t happen.
And with an untyped one, I wonder why leaving so many misleading functions instead of deprecating them in favor of correctly working ones…

Today, almost every major site includes at least bits of AJAX calls, whenever to display a shopping cart, to dynamically load fragments of a page, or to pre-fetch the next images in a slideshow. jQuery, mootools, prototype… there is an increasing number of Javascript frameworks that, among other things, allow asynchronous calls to fetch data.

In .NET, although they are starting to migrate to jQuery (as we can see in ASP.NET MVC), by default when you create a .NET 3.5 website it references the not bad but clumbersome ASP.NET AJAX framework. Although I don’t have anything against this practice, sometimes we don’t need so much, or we might prefer to do things “our way” and for example communicate with the client site using JSON.

So this post is going to be like a small 3 steps tutorial on how to do 100% handcrafted basic AJAX requests using ASP.NET. Then you can so many things to it to make as good as you want.

Step 1: Build a HttpHandler

The most efficient way to develop AJAX call handlers in the server side is to use HttpHandlers. We keep the request context, but we skip all ASP.NET forms additional layers, providing a fast code in exchange of requiring a full implementation and management of the output by us.

Code is quite easy, so just remember to add a reference to System.Web to be able to implement IHttpHandler interface. IsReusable in this case is interesting as we can probably be having lots of requests to the handler.

Step 2: Plug the handler in a web project

We will create the website in the third step but doesn’t matters as we just need to add a reference to the handler we’ve just created, and then edit the web.config to add it, under the <configuration> <system.web> node:

We’re configuring our site to enroute all calls that end in .ajax to our handler.

Step 3: Client side coding

Finally, we get to the important part: Making async calls from our webpages. The following example is for one page, of course to reuse it you should place all the <script> code inside a .js file and reference it.

We’re using asynchronous responses using a callback function to not block anything, but yet this is a simple and standard code without advanced checks, no request manager engine, no error handling…

Each time we click on the button we’ll see a timestamped response.

From here, you can improve the handler (or add more) to handle JSON, XML, even HTML templates, the limit is your imagination ;)