Web/database development and more...

Pages: << 1 ... 7 8 9 10 11 12 13 14 15 16 17 ... 60 >>



Testing web applications

  23:20:20, by fplanque   , Categories: Développement Web
Client Side Testing

Note to myself: unit testing is a great thing and I should do it more, I plan to do it more. But, unit testing is not enough...

What we need for web applications (or complex dynamic web sites if you prefer) would be something like this: the TEST program would act like a regular web browser, executing javascript and all the rest. The main difference with a web browser would be that the TEST program would be scriptable.

You could script it to log in, enter data into forms, perform search requests, check that the requested data appears on the screen, etc... You may even want to compare the generated HTML with a prerecorded excerpt. You may want to tolerate differences like white spaces and may be even non structural tags (ignore spans, styles attributes, etc...)

Of course, you'll want the TEST program to validate the XHTML output as well as the CSS styles.

Advanced testing would involve sending onclic events to specific objects on the page and see how the javascript behaves.

You'd have different scenarios you could run in sequence to fully test your application.

Even better: you could run multiple scenarios concurently (you'll need cookie isolated client threads for this) in order to stress load your application and record response times.

God, I gotta stop dreaming about it and find that gem...


I found a few potentially interesting tools here:

  1. Puffin Automation Framework. Open Source. (also see this paper)
  2. QEngine WebTest. Free / Commercial.
  3. WAPT Web Application Testing. $ 250.
  4. WebKing. Commercial.
  5. OpenLoad. Commercial.
  6. Web Performance Trainer. 499 € +.
  7. iOpus Internet Macros. $30 - $499.
  8. eValid

Mucho later:


Hungarian notation on steroids: semantic types &amp; suffixes

  23:51:00, by fplanque   , Categories: Développement
Hungarian notation

Joel on Software’s latest bewildering article advocates correct use of the – often misunderstood – Hungarian notation: “Making Wrong Code Look Wrong“.

Basically, calling a variable unBorder because it’s an unsigned int is pointless. What’s useful is to call it xwBorder because it’s an horinzontal “x” coordinate (versus a bytecount for example) that refers to the window “w” (versus the screen or the document for example). If this doesn’t feel a 100 times better to you, go read the article now! :)

I really agree with the fact that knowning the system type of a variable when you read it is pretty much useless most of the time – especially in the age of typeless scripting languages like PHP. Knowing the semantic type of the variable is much more interesting.

As I have written before in my coding standard guidelines, there’s a situation, though, where I still like to use system types in my variable names: when I deal with Objects. For example I might use variable names like source_File and destination_File!

First, because if the Objects are properly named, then the variable names refering to them will make sense.

But there’s more: as you might have noticed, I used the object name “File” as a suffix, not as a Hungarian prefix. The reason is that if I have a method called File::rename() that I want to refactor for some reason (like merge it with File::move() ), I might need to check every place where it’s called. Actually, as I have learned from b2evolution development, these things happen all the time on larger projects…

Now, by suffixing vars with the object name, I can easily do a project wide search for File->rename( and I’ll find all calls to the method, in various contexts such as source_File>rename(), destination_File->rename(), temp_File->rename(), log_File->rename() … you get the idea…

If I have one variable misnamed as in list->rename() for example, I would not find it… unless I decide to search on just ->rename(… but I wouldn’t want that! It would get me a lot of noise like: some_Collection->rename(), some_User->rename(), some_Group->rename(), etc…


Quel avenir pour Dreamweaver?

  19:57:43, par fplanque   , Catégories: Media Web, HTML & CSS, Développement Web

Dreamweaver A mon avis, même si Adobe garde la marque "Dreamweaver" ainsi que la base de code de ce logiciel, ils ne le garderont pas tel quel. Ils procèderont à un remaniement sensible pour l'adapter à leur "culture" et leur "phylosophie de l'interface utilisateur".

Il n'y a qu'à regarder les suites applicatives de Adobe d'un côté et de Macromedia de l'autre. Toutes les applications, au sein de chacune des deux suites, partagent des menus communs, des outils communs, des icônes communes et des palettes flottantes communes.

Pour faire la même chose dans les deux cultures, on procède différemment... parfois très différemment!

Adobe ne gardera certainement pas une interface Macromedia au sein de sa "suite graphique". S'ils tuent GoLive au profit de DW, ce sera avec un remaniement profond... et donc ce ne sera plus vraiment DW...

M'enfin, on peut toujours rêver que l'interface de DreamWeaver en sorte bonifiée! A vrai dire, je suis pas franchement fan des interfaces Macromedia...

Les menus Modifier/Commandes/Site.. c'est hyper confus!! On ne sait jamais vraiment où chercher... Et d'ailleurs on ne se poserait pas la question s'il ne manquait pas plein d'options essentielles dans les menus contextuels/clic-droit...) |-|

Et surtout, avec un peu de bol, Adobe va rajouter un p>:XXg de bouton <div> dans l'interface. Franchement, un outil qui se vante de faciliter l'édition de pages XHTML+CSS qui ne prévoit pas de bouton facilement accessible pour insérer des DIV, ça rime à quoi!?? >:-[

PHP Variable names, Member names, Class names

  19:37:16, by fplanque   , Categories: PHP

I have just extended my PHP coding standard guidelines with these rules about variable naming:

  • Remember this is PHP, not Microsoft Visual C++. There is actually little value in naming variables something like strFullTitle . Something like full_title is definitely enough and much easier to read!
  • As an exception to the previous rule, we'll preferably prefix private or protected member variables of a class with an underscore as in _full_title. This serves as an easy reminder that the variable is not designed to be called in any other ways as in $this->_full_title .
  • Class names should start with a capital, as in Book .
  • Variable names should be all lowercase, as in $title = 'A brand new day'; except when they are object references as in:

    $a_Book = & new Book( 'A brand new day' );
  • When naming object references, always end their name with the name of the class as in $a_Book or $another_Book instead of Book_to_read for example. This allows to easily search & find all calls to a given method of a given class. You could for exampel easily search on this string: "Book->get_title(" .

Pages: << 1 ... 7 8 9 10 11 12 13 14 15 16 17 ... 60 >>