Med fokus på din virksomheds forretningsgange watermark with eaktion circles

Archive for the ‘web development’ Category

Templating with Smarty for Ajax Enabled Applications

Thursday, August 18th, 2011

JavaScript is the future

The future is pretty clear to me, JavaScript will be the one and only on the web.
And I mean both on the client side and the server side. Am I going crazy?
Just wait for node.js to be ready for prime time and let the YUI Library be finished with the application framework, then we start talking.

However, while we wait for the day of the grand merging of technologies, we still have to do some work and keep the code nicely organized. Smarty helps me to do that. I use Smarty templates to separate code from presentation and (among other things) Smarty plugins to organize my code.

In the meanwhile, get YUI and AJAX to work nicely with Smarty and PHP

When I started using Ajax it was with the help of Xajax. What I like of Xajax is that it allows me to target a single function right from the client code, and to control the JavaScript code from inside the PHP code. A pretty fine grained 2-way communication.

Now that I use YUI more and more, I wanted to get rid of the duplication of JavaScript code that is caused by having to load both the Xajax and the YUI JavaScript libraries. Anyone serious about JavaScript would have no doubt, I had to say goodbye to Xajax.

However, YUI is naturally slanted to the JavaScript side. With YUI you produce modules and stuff that encapsulate XHR transactions, and you pass a url to the transaction. On the server side you’re on your own for how to organize your code in a manageable way.

Manageable to me means among other things that:

  • I can include my php files from wherever I want, especially from outside my server root
  • I can have a one-to-one relationship between the page I’m showing to the user and the code that supports it
  • I don’t need to create extra urls just to pull in responses to my JavaScript code
  • I don’t have to reinvent a new set of conventions each time I write some JavaScript code

These are the things I felt YUI was making difficult to me.

To make up for this I’ve developed a set of two modules: inlineXHR(php), a lightweight PHP module, that works together with inlineXHR, a lightweight JavaScript module for YUI 3. With the two inlineXHR modules, I have re-established a fine grained 2-way communication between my PHP code on the server side and my JavaScript code on the client.

Now I can again target directly from JavaScript, PHP functions, class methods and Smarty plugins. All AJAX / JSON stuff is taken care of once and for all, the cursor is spinning when it has to, errors are logged to console or popped up in alerts, and I can write PHP code without even thinking about the fact that the output has to be sent through the wire, as JSON.

If you use YUI and PHP, and you too think that life is too nice to use time reinventing the wheel each time a JS code need to talk to your server, you might want to give it a try. It’s free, open source and BSD licensed.

Click to see usage instructions and working examples

Upgrading from Debian Lenny to Squeeze (version 6)

Monday, June 6th, 2011

You want to update to Debian Squeeze from Lenny. You don’t want to scour the whole Debian documentation just to be sure not to have overlooked details that apply to your situation. Here is a complete step-by-step tutorial for upgrading to Squeeze from Debian Lenny.

In 4 steps is listed here the procedure we’ll follow. There are quicker, more risky, procedures, however the time saved doing otherwise is count in seconds, who bothers.

  1. minimal system upgrade, followed by
  2. a kernel upgrade, udev upgrade and reboot, and then
  3. (optionally) upgrade the packages associated with your critical services.
  4. full upgrade

I spell out here all the preconditions that apply for this condensed but complete step-by-step tutorial for upgrading from Debian Lenny to Squeeze. You can easily find out if this is for you or not. For web developers that use Debian as a testing/production machine this will apply in 95% of all cases.

If you don’t meet all preconditions you’ll have to go read the full documentation.

Our Goal

The goal is to be able to update from a remote terminal with as little disruption and as few risks as possible, by risks meaning the need to resort to a local console to fix problems. However no guarantees are given. None at all. The only guarantee I can give, is that I have tried the upgrade myself on 3 different Debian boxes. On one it failed because I followed a different, shorter, recipe. Two were successful following this one.

Preconditions for the Upgrade

Your Debian Lenny is a pure command line installation (no GUI, that is, x-server and more). You are running some servers and other stuff, but you don’t have external users logging in their own /home directory to care of.

You have a Debian Lenny (version 5) that is up to date to the last update point. Otherwise

aptitude update

aptitude full-upgrade

should resolve any issues. Verify with

dpkg -l | pager

no packages should have a combination of h and fh as the first 2 flags in the output.

it might be bad if you have any other combination of letters. Here is an excerpt of mine.

ii  apt-utils    0.7.20.2+lenny2    APT utility programs
ii  aptitude   0.4.11.11-1~lenny1  terminal-based package ...
rc  aspell-en     6.0-0-5.1                  English dictionary for G...

ii is OK, rc is OK

From here on we’ll use Apt instead of Aptitude (it is officially recommended for a Lenny to Squeeze upgrade)

Other preconditions to “qualify” for blindly following this step-by-step recipe:

You don’t have third party packages (from repositories other than the official Debian Lenny repositories), if you do, remove them prior the upgrade and treat their upgrade independently.

“If you are using some VPN services (such as tinc) they might not be available throughout the upgrade process”

“You should not upgrade using telnet, rlogin, rsh”, you might loose connection, use ssh instead.”

“If you have configured APT to install certain packages from a distribution other than stable (e.g. from testing), you may have to change your APT pinning configuration. In this case you want to read the whole document on Debian org.

Let’s start

1 Minimal System Upgrade

Take a backup of

  • all /etc
  • the file ./curr-pkgs.txt after having done: dpkg --get-selections "*" > ./curr-pkgs.txt
  • /var/lib/dpkg
  • /var/lib/apt/extended_states
  • /var/lib/aptitude/pkgstates
  • Any other files you care of (DB, web files, /home files etc.)

Do evaluate ”what if” in case you should be forced to reboot from the console terminal and the off/on button on your box.

If things go wrong this is the link you need.

Start doing your upgrade.

Change the sources to squeeze:

less /etc/apt/sources.list

Substitute any occurrence of lenny with squeeze. Don’t use stable, to avoid getting into troubles at the next version upgrade, write squeeze. Codenames are unique, category names are not.

Also remove sources for debian-volatile that are no longer used. Be sure to have all of main, contrib and non-free (for network cards firmware)

Here are my sources :

deb http://ftp.de.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.de.debian.org/debian/ squeeze main contrib non-free

deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free

deb http://ftp.de.debian.org/debian squeeze-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian squeeze-updates main contrib non-free
Ctrl-c
Y

Record your upgrade session with

script -t 2>~/upgrade-squeeze1.time -a ~/upgrade-squeeze1.script

When finishd you’ll stop recording typing: ”exit” Timing info is in the .time file, you can see all what happened and console messages reading the .script file.

Now enter:

apt-get update
apt-get upgrade

(we’re only doing a minimal upgrade now)

You might need to open an extra terminal during the upgrade to examine some situations as to be able to reply to questions posed to you by the upgrade process. To do so type

Alt-right arrow.

2. Upgrade Kernel and Udev

Upgrade the kernel
Start by finding a suitable linux kernel image

apt-cache search linux-image-2.6.

And choose one that suits your architecture and is equal or older to linux-image-2.6.26-2

apt-get install linux-image-2.6-<your flavor>

Although you had non-free among your sources you might end up into the following situation, due to bad handling of firmwares by the installer:

W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3_tso.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3.bin for module tg3

In this case install manually the nonfree firmware package:

apt-get install firmware-linux-nonfree

And you google about it to be reassured that you’ll have the correct driver installed anyway.

In another case I got the corresponding message for another driver:

This system is currently running Linux 2.6.26-2-686 and you are installing Linux 2.6.32-5-686.
In the new version some of the drivers used on this system may require additional firmware files:
r8169: rtl_nic/rtl8168d-2.fw, rtl_nic/rtl8168d-1.fw

choose not to do anything, however I ended up anyway with a well functioning Debian, go figure it!

Install the new version of udev

apt-get install udev

stop the script recording by entering ”exit”
Reboot the system.

Restart recording in a different filename with

script -t 2>~/upgrade-squeeze2.time -a ~/upgrade-squeeze2.script

3. Optionally Upgrade Your Critical Packages

For extra control, on a production machine, upgrade some individual packages by their own.

apt-get dist-upgrade <package-name>

Go on doing the full upgrade

4. Complete the Upgrade

apt-get dist-upgrade

Do the various configuration as asked during the process, if you choose to upgrade to the configuration  (which is recommended) you can always retrieve the old configuration in the .dpkg-old version of your config files.

Enjoy your new Debian.

You won’t fund my startup? I give you a free software tool!

Wednesday, March 30th, 2011

On the onStartup Linked In group someone posted what boils down to the question “what do you do when you realize that no VC would finance your startup”. Among the many “combat” answers, there was one that I picked up as the path I would follow in such case.

Some months later I have in fact been contacting some VCs and I’ve got a bunch of negative replies, directly or indirectly. I have understood the arguments and made some realizations. So I got back to that one answer and now I’m going to  follow that path.

  1. Why did they turn me down
  2. What did I understand and
  3. What is the path I will follow,

you’ll ask? Well here it comes, but first comes the answer to another fundamental question:

0. Why did I spoke to VCs in the first place?

0. To try and get funds of course, but also and most importantly to come out of my comfort zone, to stop coding and start thinking, that is, to start relating to reality as it presents itself on the market place, VCs being a part of the market.

This means that I used VCs more like sparring partners than possible sources of funds. Of course, if they would have chosen my startup to invest in, that would have been an added bonus, however not getting funded has not been a complete failure at all.

Question 1. Why did they turn me down?

To make it short, among the different reasons they gave me, the fundamental one is that I’m out too early, the project is untested with real people so as things stand now, although lots of proof of concepts has been done on the critical technical aspects, the whole thing  to them is not much more than pies in the sky. (Other untold reasons deserve their own post, stay tuned for more).

Question 2. What did I get out of this exercise (speaking to VCs)

The fundamental result of doing this is that I had to prepare myself for speaking, that is I had to speak out my ideas, so people understand them. I saw the reactions on their faces when I spoke, I heard the arguments used to test my ideas. Still more important: I heard the many people I spoke with to prepare for speaking to the VCs. Further, each VC  wants you to present your idea in a different way, someone wants you to make an “odd presentation” that shows whether you’re able to stand out of the crowd, others want a 3 minutes pitch, others again want to see your exec summary first, while some wants to see the whole business plan, before engaging in any discussion.

Staying in good shape

This alone got me at work to refine my ideas and plans to make them viewable from all these different angles. It compelled me to cut down the fat and get to the essence of what is the product, what makes this different from others, what will make it or brake it.

It’s a heck of a lot of work to be doing for getting nothing, isn’t it? Yes, It ‘s a lot of work but not for getting nothing. What I got is very important. And I’m still glad I did this “too early”. The real outcome of this exercise is the cutting down, so that the shape of my business proposition is clear and explicable to many different people. Guys that not just listen politely to you, but that are there to question you and to doubt your skills and plans because they themselves have something at stake.

When you prepare to really try and convince such people your mindset changes. It is a big step closer to reality. Of course, as it is said, the biggest step is making the first person to open the wallet and pass over some money to you.  However, when that happens, you will want to know exactly why.  For an IT entrepreneur the exercise of speaking to possible investors is a more involving test than just putting up some functionality with a link to a payment gateway.

“No I don’t like coding

The irony of this is that  one VC told me, “why do you do this, because you like coding, don’t you?” Well it was just a test from him, because he meets so many “business people”, programmers that put up a system because they like coding and they like what they code, no matter if this is what the market likes, and it would be lovely if someone would pay you for doing what you like instead of the other way around. And no, that was not the case, however he was still not so happy to hear that, “no, I don’t like coding for the sake of it, as a matter of fact I haven’t coded anything at all yet”. In the end he wanted to try the system out with some would be customers, while in the end I wanted to try my ideas out with him.

What now?

Now the one path to follow, remember? the answer I picked up on the group forum. The path is to think an MVP,  a Minimum Viable Product, cut down on dreams, functionality and – most important – time and cost, and bootstrap the whole thing, i.e. just doing by myself. This is what I’m working at now. The technical/design principles however are the same as I told you last time. As a demonstration of that I want to give you the promised goody, that is a preview and a tool that follows those same principles, having some elements of the described principles 2 – 4. For you that don’t bother reading the last post these are:

2. Don’t make me think
3. Software as candies
4. The fun theory

A free software tool

I will use this tool myself to wrap in my webapplication the day it will hit the market (keep your breath, it’s within view). You can use it too if you are skilled enough to understand how to bring it to good use. NB! It is not for everything or for everybody.

The tool is a 3 panes Split Desktop. You find it on its project page with detailed explanation for how to install and use it.

I would love to hear from you, either here on this blog or on the YUI Library forum for the SplitDesktop

See you soon, Paolo Nesti Poggi

SliderWindow – a YUI based widget for communication to the user

Wednesday, August 6th, 2008

As of yesterday we have released a new widget: SliderWindow.  This post is to explain why and how it is to be used, and to be able to receive comments from you, so don’t be shy, post your comments. The comments are moderated so it will take a while before they appear on the blog.

You can see it in action here.

Why a new widget?

The Ajax style of application has removed the typical browser behavior of posting to the server and reload of a new page. It was a nuisance for many reasons and we love the fact that it is no longer there, however this behavior also provided the user with several clues about what was going on. At least two:

  1. something has been sent
  2. something has come back

In an Ajax application we usually provide a spinner, or a time glass cursor, to signal that we’re waiting a response from the server. When the action has updated something some other visual clue must also be provided to notify the user of what has actually happened:

  1. If you delete an item, that item might have to be greyed out on the screen, or removed in a noticeable way.
  2. If you edit an item you edit it on the screen, and to be sure that the server actually has received and saved your changes something more than just your changes on the screen must be sent back and shown to the user, whether it be an “OK”, “item saved” or a color transition of some fixed item on the screen.

Ok, we do this, what’s the problem then, one could say? The problem is that in a complex application the user receives:

  1. A great quantity of feedback messages
  2. A great variety of feedback messages

1. Great quantity

The sheer amount of situations in which the user needs to get a simple “OK” from the application requires that you have a dedicated area on the screen for this kind of messages. Pop up messages that require a click or enter by the user are of course a no go. However your “OK” must disappear or change colour after they have been displayed, otherwise the user won’t know which “OK” is which.

2. Great variety

In my experience the application needs to send to the user a fair amount of different kind of information, in many different situations and to different purposes.

The first instinct of the developer (er.. well, my first instinct)  is usually to device something specific for each of these situations, but one ends up with the “usual” mix of good and not so good solutions for each individual case. This disadvantage is, that no matter how perfect each of these solutions is in each particular case, they are different from what happens in any other case, and this, for the user, is in itself a very bad thing:  the user needs to know what to expect in different situations that, by the way, might not seem so different to her/him after all.

Especially this second aspect urged me to device something that:

  1. did not take up too much space on the viewport;
  2. could easily and always be noticed by the user;
  3. did not necessarily require an action from the user;
  4. could be controlled in a way to enforce some action from the user, in situations where this is mandatory;
  5. could display any amount of information;
  6. could keep this information available for the user to retreive it at her/his convenience;
  7. had a fairly predictable behaviour;
  8. should be working with YUI.

I believe that with the SliderWindow I have reached these goals.

How to use it

When the SliderWindow is installed (see the easy installation instructions and examples ) you can always call it from the application and publish a message inside it, whereby the SliderWindow :

  1. will slide open and close within approx. 1 sec, OR
  2. will slide open and remain open until the user closes it
  3. can be clicked open by the user, clicking on its 5 px thin, visible right border, OR
  4. can be opened by the user, hitting Ctrl-right arrow
  5. can be closed by clicking the close icon or by hitting Ctrl-right arrow

If your message is just a “OK” or “Order xxx is updated” or even kind of “The new order has got no. xxx. ” you probably will want to open and close the window right away. It’s routine messages.

However if your message is something like: “The added student has has no available allotment and won’t be able to receive books, unless the allotment is updated”, where this might be an unusual situation and still a legal one, you will probably send the message and leave the window open, to be sure the user has seen the message.

In the end your users will tell you which messages they want to be forced to acknowledge. In general they will want to be forced to acknowledge messages, that require them to do some physical action, ie. checking something on a paper file, verifying the functionality of some machine, retriving some item from a depot  or similar things. What specifically will depend on the company business routines and level of on-line integration/automation.

For system errors or user errors we don’t use the SliderWindow and make use of a YUI dialogue with a red header. This requires always a click to be closed, and marks a clear difference from this kind of messages.

Well, thinking about this, a possible improvement could be to add a method to control the color of the window and send error messages to the SliderWindow too, taking care to change the color of it, and leaving the window open. What do you think?

Requirements and some tech info

SliderWindow requires some YUI files, and only one .js and one .css additional file (plus assets directory for the  3 images). It is an extension of the YUI module that has pre-applied a container effect object to create the sliding movement. It is released under a BSD licence.

If you want to change the color of the window just add 3 new images for header, handle and footer and add your css file to override the paths for these 3 images. Currently you need to respect the same size though.

Go to the installation and example page and/or leave a message.