Las expresiones regulares pueden ahorrar muchas muchas líneas de código y bien usadas pueden dar una enorme potencia a la hora de realizar búsquedas. Lo malo es que si no las usamos con asiduidad es muy difícil dominarlas. En Virtuosi Media han publicado una lista de 37 expresiones regulares probadas. Por si a alguien le interesa, aquí está el enlace: 37 Tested PHP, Perl, and JavaScript Regular Expressions. El artículo cuenta además con una serie de enlaces relacionados muy interesantes como el testeador de expresioens regulares.
He visto en el blog de Julio César Pérez que ha publicado un post completico dando algunas pautas sobre como hacer un buen diseño e implementación de un servicio web. Me lo apunto por si en el futuro tuviera que hacer alguno (no será por falta de ganas).
En programacion.net hay un tutorial sobre internacionalización de programas java con el uso de ficheros de propiedades y las clases ResourceBundle y MessageFormat que es de lo mejor que he visto. Os lo recomiendo.
Acabo de leer en Oracle Notepad un artículo muy interesante sobre la ordenación de resultados en castellano. Nunca pensé que la ordenación sería así. Supongo que porque en todas las bases de datos Oracle con las que he trabajado tenían el parámetro NLS_SORT fijado en español.
Para comprobar con qué ordenación por defecto está configurada nuestra base de datos basta con hacer una select de la tabla NLS_PARAMETER:
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS; PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_CSMIG_SCHEMA_VERSION 5 NLS_LANGUAGE SPANISH NLS_TERRITORY SPAIN NLS_CURRENCY ? NLS_ISO_CURRENCY SPAIN NLS_NUMERIC_CHARACTERS ,. NLS_CHARACTERSET WE8ISO8859P15 NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD/MM/RR NLS_DATE_LANGUAGE SPANISH NLS_SORT SPANISH NLS_TIME_FORMAT HH24:MI:SSXFF NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR NLS_DUAL_CURRENCY ? NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_NCHAR_CONV_EXCP FALSE NLS_RDBMS_VERSION 10.2.0.4.0
Estaba importando un esquema “conflictivo” en mi oracle XE cuando de repente me ha dado un error de final del canal de comunicación. Después de eso (o antes quién sabe) el listener se ha caído. Todos los intentos posteriores por levantarlo han fallado.
Continue reading »
Acabo de enterarme a través de un post en el blog de www.digitalalchemy.tv que con tu cuenta de gmail puedes generar ilimitadas direcciones de correo. Tal como se explica en el post poniendo entre el nombre y la arroba un símbolo más y la cadena que quieras te seguirán llegando los correos a ti. Por ejemplo si tu cuenta es micuenta@gmail.com, los correos que envíen a micuenta+trabajo@gmail.com te seguirán llegando a ti. Y alguien puede preguntarse “¿Y esto para qué me sirve?”. Pues tal como explican en el post te puede servir para clasificar tu correo o incluso para saber qué lugares están exponiendo tu dirección a spammers.
Recientemente me han actualizado la versión de la base de datos 10g. Me llevé una gran sorpresa al ver que las consultas con GROUP BY ya no estaban ordenadas por los mismos campos de la cláusula. He programado en Oracle 8 y 9 y siempre había dado por hecho que, salvo que necesitara uno distinto, el orden sería el mismo que el del GROUP BY. He leído en un blog que Oracle ha cambido la estrategia de ordenación por defecto en la 10g. Ahora es HASH GROUP BY y comentan que tiene un bug que se resuelve en la 11g. En el blog dicen que oracle recomienda (en las versiones con el bug) poner el parámetro _gby_hash_aggregation_enabled parameter a FALSE o optimizer_features_enabled a 9.2.0.
Sin embargo, leyendo la nota 345048.1 ‘Group By’ Does Not Sort If You Don’T Use Order By In 10g lo que entiendo es que no es un bug. Sencillamente es un efecto colateral del algoritmo de agrupación (antiguo) lo que hacía que salieran ordenadas. Nunca ha habido garantías de ordenación. Por tanto toca poner order by a todas las consultas con group by lo que puede conllevar unas cuantas horas de divertida revisión del código.
Acabo de leer en un artículo de Tom que el interfaz de sql*plus para windows desaparecerá en próximas versiones de Oracle. En su lugar dejarán sólo el cliente para DOS y el iSql*Plus. A mi me da igual porque siempre he tenido la suerte de poder usar el sql*plus en el shell de linux, pero para mucha gente va a ser una putada. Un argumento más para pasarse al lado oscuro de Lord Toad.
Estoy programando unas paginillas con Hibernate 3 y JDeveloper. Hice primero las clases del modelo y las testeé. Todo funcionaba perfectamente hasta que traté de invocarlas desde un backing bean. El error era: ClassNotFoundException: org.hibernate.hql.ast.HqlToken. Después de mucho buscar resulta que el amigo AMIS tenía la solución. Agregé esta línea a mi hibernate.cfg.xml:
<property name="query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</property>
Me gustaría encontrar otra solución mejor, pero de momento puedo ir tirando con esta. El problema parece ser un conflicto con un jar del OC4J embebido. Como en este proyecto no estoy usando librerías propietarias de oracle y finalmente desplegaré sobre un tomcat luego sólo tendré que eliminar esa línea del fichero de configuración.