Thinking in programming

Things I like to talk about programming

Flex Coding Conventions

with 3 comments

This document is intended to set the coding
conventions for the Flex side.

General Requirements

Only the most recent release of Adobe Flex
should be used. Currently the release is “Flex 3”.

Standard object oriented programming principles
must be used in the Flex code development.

A concept for error handling should be provided
and used by the Flex developers.

A concept for security should be provided and

Necessary Development Concepts

The following is a list of necessary concepts for Flex application development:

  • Error handling and reporting.
  • Application security and authentication.
  • Client side input validation. In certain modules, it may be necessary to create concepts for L10N and I18N.

Packages

All package names should be meaningful and
should be prefixed with com.companyname. For example, org.rogerpadilla

When importing packages into classes, it is
preferred to import concrete classes instead of entire packages.

Files

All files must be encoded in the UTF8
format.

  • MXML file names: UpperCamelCase.mxml
  • ActionScript file names: UpperCamelCase.as for classes and all interfaces should be prefixed with I ( IUpperCamelCase.as).

Classes, functions and code

The following is the set of coding rules
for ActionScript:

  • There should not be magic numbers, strings or values present in the code. Easily accessible constants, property files, xml files should be created where all such values will be kept. For example, a remote service URL should not be hardcoded.
  • Each class, function and class property should be commented. Non-obvious blocks of code should be preceded with a commented explanation of what they do.
  • Multiple variables should not be declared in a single line.
  • Multiple statements should not be placed on a single line.

The following is the set of coding rules
for MXML:

  • Use external style files.
  • There should be only one script block per MXML file, and it should follow the same guidelines as usual ActionScript files, because it should be exportable with asdoc.

Documentation

All MXML files should contain a brief
desctiption if what they do and where they are used.

All ActionScript classes, functions and
class attributes should be commented with meaningful information in English. It
should be easy to create a documentation export using Flex’s asdoc tool,
where all packages, classes and functions can be reviewed.

For functions, there should be at minimum a
@param tag for each parameter, @return tag for returned
values, and a description of what the function does.

Written by roger.padilla

March 31, 2009 at 10:28

Posted in Coding Conventions

Tagged with ,

Te queda una semana de vida. ¿qué vas a hacer con ella?

with 5 comments

Imaginen por un momento que alguien les dice que les queda una semana de vida. ¿Qué harían, ante tal perspectiva? La pregunta es peliaguda desde el momento en que se plantea, y a medida que se reflexiona, se entra más a fondo en una espiral en la que parece no existir la respuesta correcta. ¿Pero realmente, qué es una respuesta correcta? Esta es otra interesante pregunta, a la que quizá dedique unas líneas otro día.

Volvamos al asunto. Solamente hay que ponerse en situación. Joder, es una putada, pero esto no es un juego. O bueno, quizá sí, pero el objetivo es conocernos un poco más a nosotros mismos, con lo cual es un juego muy serio, digamos que instructivo. Como el Mecano, vamos. Bien, mucha gente diría que visitaría a sus seres más queridos, que pasaría todo el tiempo con ellos. Otros dirían que eso no le aporta nada, porque cuando desaparezcan nada quedará de ellos y que para cuando desaparezcas ya todo dará igual, se deprimirán y quizás se suiciden, como venganza ante la muerte, para decidir ellos el momento final. Otros, terceros, se gastarían todos sus ahorros en grandes lujos, en vivir la vida a lo grande, a mandarlo todo a la mierda en un intento de vivir deprisa. Quizá habría un cuarto tipo, los buenos samaritanos, que aprovecharían el resto del tiempo para hacer el bien a los demás, dedicarlo a ayudar todo lo que puedan a sus congéneres, para sentirse mejor. Cadena de favores, y esas cosas. Y el antagónico de este grupo, psicópata enfermizo quizá se dedicaría a delinquir durante toda esa semana, sin reglas, ni leyes, libertinaje, pues no hay miedo a la prisión ni a la perpetua ante la perspectiva de la inminente visita al barquero Caronte.

Me interesan todos estos tipos, pero todos tienen algo en común que les caracteriza profundamente: todos cambiarían de forma más o menos radical sus vidas. El egocéntrico solitario pasaría los últimos momentos con su familia, los fuertes moralistas con grandes ideas para el futuro se desmoronarían como castillos de naipes, sumergidos en los mares de la depresión y, quizá, el suicidio; para los terceros, austeros usureros ahorradores para las generaciones futuras, el shock les produciría la fiebre de vivir ahora deprisa; los no empáticos, egoístas que viven en su nube de algodón se convertirían en misioneros sin fronteras, y los espíritus tranquilos y extremadamente tímidos desatarían la furia sociópata que siempre llevaron dentro.

Sé que estoy generalizando, pero es fácil pensar en todos estos arquetipos. No digo que yo no pertenezca a ninguno de ellos, pero pienso que la respuesta correcta sería seguir haciendo lo que he hecho hasta ahora. Imposible, ¿verdad? ¡Qué utopía! ¡Qué imbecilidad! No me digas que tus últimas horas las “gastarías” haciendo lo que has hecho siempre. Bien, ahora yo les diré que si tanto les trastorna esta respuesta es porque quizá no están viviendo como desearían vivir.

Aquí quería llegar, amigos: todos somos, en mayor o menor medida, dueños de nuestro destino y de nuestra forma de vivir. Desafortunadamente hay gente que no puede, pero la mayoría, al menos en los países desarrollados, tenemos esa inmensa suerte. Puede ELEGIR cómo quiere vivir su vida. Si tus últimos momentos no serían igual que el resto es porque quizás no estás viviendo adecuadamente. Es un cambio de filosofía, amigos: “vive cada momento como si fuera el último”, pero no atropelladamente, entiéndanme. La idea es no dejar todo aquello que deseamos para el final, aprovechar que estamos vivos, valorar lo que tenemos y estar agradecidos por ello.

La idea es decir: voy a visitar a mis padres y a mi familia más a menudo, mejor visitarlos ahora que llevarles flores cuando estén criando malvas. La idea es pensar: voy a cogerme unas vacaciones y visitar la India, un país que siempre quise visitar, por ejemplo. Es cavilar en lo banal que es casi todo en esta vida y que al final, lo único que merece la pena realmente son las personas. Es reflexionar: debería apadrinar un niño, donar dinero a cierta organización, pensar en algo para que los demás puedan disfrutar de la vida con plenitud, como lo hago yo. Finalmente, la idea también es: voy a enfrentarme a los demás, no callarme lo que me sienta mal, ni dejarme pisotear; voy a quererme a mí mismo y a intentar que se me respete igual que yo respeto a los demás. Así seré más feliz.

Por ello, a la pregunta: ¿qué harías si te quedara una semana de vida? creo que la respuesta correcta debería ser: lo mismo que he hecho todos los días hasta el día de hoy…

Espero que hayan reflexionado un poco con estas líneas. También me gustaría recibir sus opiniones al respecto.

Original en: http://luixrodriguezneches.wordpress.com/2008/06/27/te-queda-una-semana-de-vida-%C2%BFque-vas-a-hacer-con-ella/

Written by roger.padilla

March 31, 2009 at 09:53

Posted in Interes General

Conventions for Creation of SQL Queries, Indexes Tables and Fields

with 4 comments

  1. Whenever added a new table/field to the database, a comment with his purpose must be included.
  2. Use NOT NULL. Always define columns as NOT NULL unless there is a very good reason not to do so:
    • can save up to a byte per column per row of data
    • nullable columns make indexes, index statistics, and value comparisons more complicated.
  3. Use UNIQUE INDEX. If you have verified that each value for that index will/should not be repeated, then use an unique index (UNIQUE INDEX).
  4. Declaring the data type of a field to the more fixed-value, i. e., if you know the value of an int field is always going to become smaller than 10000, the you should use SMALLINT instead of INT.
  5. Use the smallest possible value for the lengths of the text fields. If you know that a zip code field will always hold not more than 10 characters, then you should use VARCHAR (10) and not VARCHAR (25).
    In cases like encrypted values with the MD5 algorithm, use CHAR (32).
  6. While write reserved keys use always capitalized sustained.

Useful info about the most common MySQL Data Types:

/* Unsigned Numeric Data Types */

TINYINT 0 to 255

SMALLINT 0 to 65535

MEDIUMINT 0 to 16777215

INT 0 to 4294967295

BIGINT 0 to 18446744073709551615

/* Text Data Types */

TEXT 65535 OR 64KB characters

MEDIUMTEXT 16777215 OR 16MB characters

LONGTEXT 4294967295 OR 4GB
characters

Written by roger.padilla

March 31, 2009 at 09:25

General Coding Conventions

leave a comment »

Rules

1 Self explanatory code. Make sure your method, class, instance, param and all other self written names in your code are self explanatory.
2 Always include explanatory comments in the code. Make sure every class and method has comments explaining what it does and its purpose, this will make the API documentation easier to understand for other without diving into the code.

/**

  • Get a random prime number starting to search it from a minimal number (default 1)
  • @param minNumber Number Optional minimal number where start the search. Default to 1
  • @return Number Random prime number
  • /

public function findRandomPrimeNumber(minNumber:Number = 1):Number {

}

3 Follow the DRY (Don’t repeat yourself) code philosophy. Make helpers. Make modules. Make plugins. Think in reusable components.

  • If you have a common functionality for two or more classes, please consider to include such functionality in a helper class.
  • If you made a class which have only static functions, like in the case of Utility or Helpers Classes, please consider to use the Singleton Pattern.
4 Avoid too long functions (more than 200 lines). Split to smaller internal functions as needed.

/**

  • /

public function myLongFunction():void {

// Wash clothes
washClothers();

// Now dry them up
dryCycle();

// Notify master that laundry is done
notifyMaster();
}

5 Avoid empty catch blocks. When the exception occurs, nothing happens, and the program fails for unknown reasons.

In general, when a exception occurs, it can be thrown up to the caller, or it can be caught in a catch block. When catching an exception, some options include: inform the user (strongly recommended), log the problem, send an email escribing the problem to an administrator. Deciding what exactly to do seems to depend on the nature of the problem. If there is an actual bug in the program – a defect that needs to be fixed – then one might do all three of the above. In this case, the end user should likely be shown a generic “Sorry, we goofed” message, not a stack trace. It is usually considered bad form to display a stack trace to a non-technical end user, or if exposing a stack trace may be a security risk. If the exception does not represent a bug, then different behavior may be appropriate.
6 Always include { and } on the statements, even if there is a single block code line.
7 Be sure of read all the coding conventions on: Coding Guidelines

Recommendations

1 Only one return on a same function. Do not use returns to break the flow of the code.

  • If you want to know where something is returned, you have to look for the return statement. With multiple return statements you have to go read the complete method and find all the exit points of a method. (isn‘t your method too big?)
  • If you want to log before you exit a method, so with multiple return statements you need to place that logging code before all return statements.

Written by roger.padilla

February 15, 2009 at 15:10

Posted in Coding Conventions

Tagged with

JavaFX v1.0 – Un comienzo prometedor

with one comment

Tras varias expectativas negativas, la primera versión de JavaFX vio la luz en diciembre del año pasado. Para algunos, esta plataforma llega demasiado tarde, para otros, este es solo el inicio de una plataforma con gran potencial. JavaFX promete permitir desarrollar un aplicación, y sin modificarla, ejecutarla en el computador, en el móvil, en la tv, en el automóvil (”en todas las pantallas de tu vida”). Esto aprovechando la ubicuidad y el musculo que Java ha forjado a lo largo de los años.

Una pregunta común es Por que crear una nueva plataforma para esto?: La principal desventaja de los lenguajes con alto nivel de difusión y longevidad como Java es que esas mismas cualidades exigen una fuerte compatibilidad hacia atrás, lo cual limita a su vez su capacidad de evolucionar. Para comprender la razón de ser de JavaFX, también es relevante considerar los siguientes aspectos: un nuevo y moderno lenguaje, RIAs y flujo programador-diseñador en mente, soporte multimedia, Swing 2.0, alucinantes animaciones al estilo Flash, y todo lo anterior sin salir de Java! JavaFX fue pensado para satisfacer todas esas exigencias; la versión 1.0 ha sido enfocada a dar muy buen soporte al trabajo con animaciones, gráficos y multimedia. En otras palabras, se creó una base muy robusta sobre la cual agregar controles gráficos, frameworks para aplicaciones de gestión, etc. Ahora bien, el primer paso fue solido, de aquí en adelante todo depende de cómo Sun haga evolucionar esta prometedora plataforma.

Written by roger.padilla

February 9, 2009 at 22:42

Posted in JavaFX

Tagged with

Can “your” language beat this? – Part 1

with 2 comments

Important: This first post is discussed on JavaHispano.org

This series of posts is not intended to demonstrate the superiority of one language over others, the aim is to find the best way to write code snippets that a GUIs developer faces daily. When i said “the best way“, i mean a proper balance between flexibility and readability, which in my view, defines the quality of a language. The idea is that if you knows a language that allows to improve the way of codifying the snippet shown here (surely you knows), then you published that piece of code here, and then we will evaluate the best. As well are welcomes improved versions of the ones I have posted, and of course, comments in general.

The main reason why i choose JavaFX, is frankly because of i think that is the language that gives more agility to work with graphics (at the moment).

This first part aims to show how to bind two objects, in this case, the color of an object is determined by the text of a text field. If the text inside the text field is ‘aeiou’ then the circle will be filled with the green color, otherwise will be filled with the red color.

Note that understanding the processTheText function as the “controller”, so you can notice the complete separation between the view and the logic.

/*
 * DoItBetter1.fx
 *
 */

package doitbetter;

import javafx.scene.control.TextBox;
import javafx.scene.layout.HBox;
import javafx.scene.paint.Color;
import javafx.scene.Scene;
import javafx.scene.shape.Circle;
import javafx.stage.Stage;

var theText = "";

Stage {
    title: "Binding between GUI controls"
    width: 400
    height: 200
    scene: Scene {
        content: HBox {
            spacing: 10
            content: [                
                TextBox{                    
                    text: bind theText with inverse
                }
                Circle{                    
                    radius: 10 centerY: 10
                    fill: bind processTheText(theText)
                }
            ]
        }
    }
}

function processTheText(auxText){
    if(auxText == "aeiou") Color.GREEN else Color.RED
}

Written by roger.padilla

January 15, 2009 at 18:11

Posted in Uncategorized

Tagged with

JavaFX, why?

with 6 comments

It’s not a secret that for a developer is a dream to be able to build an application, and without modify it, run it in the computer, in the cellphone, in the TV, in the car, in all the screens of the life.

However, why to create a new platform for this?: The main disadvantage of the languages with a high level of dissemination and longevity such as Java, is that these same qualities requires a strong backwards compatibility, which in turn limits its ability to evolve.

JavaFX was precisely designed to meet these demands, while provide a new and modern language, RIAs, developer-designer work flow in mind, multimedia, Swing 2.0, amazing Flash’s style animations, and all this without leaving Java! Version 1.0 has been focused on providing a very good support to work with animations, graphics and multimedia. In other words, has been created a very strong base on which to add graphics controls, business applications frameworks, and so on.

For some, JavaFX is coming too late, for others, this is just the beginning of a platform with a great potential. The first step was solid, from now on everything depends on Sun supports to this promising platform.

Written by roger.padilla

January 13, 2009 at 17:33

Posted in Java Swing, JavaFX

Tagged with ,