Archive for the 'Java' Category
Posting en Twitter desde teléfonos con Symbian
Como mencioné en un articulo anterior soy un usuario de Twitter, me gusta postear de manera regular, para lo cual uso el magnífico cliente Twiterrific.
Sin embargo me hacía falta un cliente para postear desde cualquiera de mis dispositivos móviles…
Y bingo!!! hoy descubrí Twitteresce, que es un cliente con el cual puedes postear desde los teléfonos móviles que usan Symbian como su sistema operativo.
Entonces, aprovechando mi nueva adquisición: un Nokia N81, lo instalé e hice mi primer post de prueba:

Eclipse Europa
Hace un rato que estoy alejado del mundo Java sin embargo bajo mi experiencia uno de los IDE’s más sólidos y fáciles de usar para trabajar en esta plataforma es Eclipse.
Hoy ya está disponible la versión 3.3 con el nombre clave Europa, en este artículo publicado por Software Gurú se detallan las características más notables del release.
No comments | Related postsTraducción de fechas en PHP y Java
Al desarrollar un sistema debemos de hacer uso de los beneficios del lenguaje o tecnología sobre la que desarrollamos, por ejemplo no podemos programar igual en Java que en PHP, ya que ambos lenguajes tienen diferentes características. Java y algunos otros lenguajes como C# tienen como parte de sus librerías estándar soporte para i18n y l10n, otros lenguajes como Ruby o PHP hacen uso de librerías de terceros para dar soporte a esta característica.
Este comentario viene a propósito de que recientemente tuve una plática por IM con una amiga y me preguntó por una función para hacer la traducción de una fecha con el formato dd/mm/yyyy a dd/NombreMesEnEspaniol/yyyy en PHP, entonces escribí la siguiente función
function translate_date ( $date )
{
// Patron para dividir los elementos de la fecha
$regexp = "^([0-9]{2})[\/.-]([0-9]{2})[\/.-]([0-9]{2,4})$";
// Verificamos que se cumpla con el patron
if ( ereg($regexp, $date, $date_splited) )
{
list( , $day, $month, $year) = $date_splited;
} else {
throw New Exception("Formato de fecha invalido !");
}
// Creamos el arreglo de conversion
$months = array( "01" => "Enero", "02" => "Febrero",
"03" => "Marzo", "04" => "Abril",
"05" => "Mayo", "06" => "Junio",
"07" => "Julio", "08" => "Agosto",
"09" => "Septiembre", "10" => "Octubre",
"11" => "Noviembre", "12" => "Diciembre",
);
// Obtenemos el nombre del mes
$long_month = $months[$month];
return $day."-".$long_month."-".$year;
}
?>
Mientras desarrollaba la función recordé una ocasión en la que haciendo una revisión de código en un proyecto desarrollado en la plataforma Java, encontré una clase de utilerias misceláneas que contenía una función con el mismo propósito que la desarrollada en PHP.
El algoritmo era mas o menos así:
- Dividir la cadena asumiendo que tiene un formato dd/mm/yyyy en tres secciones
- Obtener el valor de cada sección
- Asignar los valores obtenidos a variables para contener día, mes, año
- Dependiendo del valor numérico del mes obtener su nombre en español
- Concatenar una cadena con el formato
- Regresar la cadena con el nuevo formato
Simple no?!. Al estar escrito en Java y teniendo en cuenta el soporte de Java para i18n y l10n, era mas limpio usar un objeto SimpleDateFormat con un objeto Locale dándole mayor mantenibilidad al código, como se puede observar en la siguiente función.
SimpleDateFormat dateParser;
SimpleDateFormat sdf;
Date dateToTranslate;
ParsePosition position;
Locale locale;
dateParser = new SimpleDateFormat("dd/MM/yyyy");
position = new ParsePosition(0);
dateToTranslate = dateParser.parse(date, position);
locale = new Locale("ES");
sdf = new SimpleDateFormat("dd/MMMMM/yyyy", locale);
return sdf.format (dateToTranslate);
}
En estos dos ejemplos podemos observar la diferencia en la implementación en dos diferentes lenguajes de una misma función, haciendo uso de las características de cada uno de ellos.
Nota: En los ejemplos existe hard-code intencionalmente solo para hacerlos más claros, evidentemente es una mala práctica.
2 comments | Related postsJava es ahora Open Source, Alwas Open. Now Free.
Hasta el día de ayer, el código del JDK de Java fué accesible a cualquiera que lo quisiera bajar y compilar para su plataforma específica, pero el uso de los binarios producidos después de esta compilación no podía ser distribuido libremente. Por ejemplo, los usuarios de FreeBSD hasta antes de la versión 1.5 del JDK tenían que hacer la generación del compilador por cada servidor o workstation.
Hoy Sun ha anunciado bajo el slogan de Alwas Open. Now Free el cambio de licencia de sus fuentes a la licencia GLP v2, y provee de toda una infraestructura para poder hacer contribuciones.
Que bueno que Sun se decidió a dar este paso, pues esto ayudará en gran medida a la adición de mas características al lenguaje, mayor rapidez en la corrección de bugs y lo que es más importante dar la oportunidad de portarlo a muchas más plataformas.
3 comments | Related posts


Suscribete por correo