Entropy utopy

Java reflection

2011-08-19T08:53:00.001-07:00

How to test private methods? One solution is using java reflection, here is a utility class defining a static method, wich allows invocation to the private mehods we want to test.

package org.marwan.alephn.test.utilities;

import java.lang.reflect.Method;

/**

* A class with reflection utilities for testing private methods

public class ReflectUtilities

{

/**

* To be used in case of need to test private methods with

* return type, a cast to the type

* @param aClass

* Name of the class witch declares the method to be invoked

* @param instance

* An instance of a aClass

* @param aMethod

* Name of the method to invoke

* @param params

* Class type of the parameter of the method to invoke

* @param args

* Arguments for the method to invoke

* @return Object to be cast to the return type of the method invoked

* @throws Exception

* If error

public static Object invoke(final Class aClass, final Object instance,

final String aMethod, final Class[] params, final Object[] args)

throws Exception

{

Object o = null;

try

{

final Method m = aClass.getDeclaredMethod(aMethod, params);

m.setAccessible(true);

o = m.invoke(instance, args);

}

catch (final Exception e)

{

throw e;

}

return o;

}

Good and quick reference to check for java reflection uses:

http://www.java2s.com/Code/Java/Reflection/CatalogReflection.htm

Basic modifiers you should know before programming in Java

2011-08-11T07:24:00.000-07:00

The static keyword can be used in 4 scenarios

1) static variables

It is a variable which belongs to the class and not to object(instance)
Static variables are initialized only once , at the start of the execution . These variables will be initialized first, before the initialization of any instance variables
A single copy to be shared by all instances of the class
A static variable can be accessed directly by the class name and doesn’t need any object
Syntax : <class-name>.

2) static methods

It is a method which belongs to the class and not to the object(instance)
A static method can access only static data. It can not access non-static data (instance variables)
A static method can call only other static methods and can not call a non-static method from it.
A static method can be accessed directly by the class name and doesn’t need any object
Syntax : <class-name>.
A static method cannot refer to "this" or "super" keywords in anyway

3) static blocks of code.

The static block, is a block of statement inside a Java class that will be executed when a class is first loaded in to the JVM

class Test{

static {

//Code goes here

}

4) static Inner class.

Make an inner class top-level class

The final keyword can be used in 4 scenarios

1) final variables

It is a variable which can not change its value

2) final method

It is a method which can not be overriden and dinamically looked up (Polymorphism)

3) final field

It is a variable which can not change its value. Static final fields are compile-time constants.

4) final class

It is a calss which can not be subclassed

Modifiers keyword for access levels

**Access Levels**
	Class	Package	Subclass	World
`public`	Y	Y	Y	Y
`protected`	Y	Y	Y	N
no modifier	Y	Y	N	N
`private`	Y	N	N	N

The transient keyword can be used for a field

1) transient field

It is a field to not to be serialized with the object serialization.

The synchronized keyword can be used for a method

1) synchronized method

For a static method, a lock for the class is acquired before executing the method. For a non-static method, a lock for the specific object instance is acquired.

The native keyword can be used for a method

1) native method

It is a method witch is platform-dependent. It doesn't have body, only signature.

Le potentiel des enum pour les Logs et messages d'erreur

2011-07-24T17:18:00.001-07:00

Dernièrement j'ai travaillé sur la gestion des erreurs et des logs dans un très grand projet. Une des bonnes pratiques que j'ai pu connaître, est de regrouper tous les messages de logs, exceptions ou autres de la librairie en développement dans un Enum. Ceci permet de forcer les développeurs a définir toutes les propriétés requises, et de respecter la structure des messages de log et d'exception établit, ainsi que l'utilisation de ces derniers dans les logs et exceptions.

Un bon exemple d'un message descriptif, bien structuré, à produire dans la log ou pour décrire une exception peut être le suivant. Un message qui contient son code, son libellé, l'impact et l'action, sous la forme : code - libellé | impact | action.

Le code du message peut être préfixé par le package ou composant qui produit l'erreur.

Le code source java doit référencer l'une des valeurs énumérées de notre classe de Log, (donc pour un nouveau message créer une nouvelle valeur) ; cela permet ensuite de pouvoir trouver où sont utilisés chaque message (Référence / Workspace), de les renommer sans risque, ...

La déclaration de la valeur est en fait un appel à un constructeur à qui l'on passe le code du message, le libellé du message, l'impact de la cause du message (sous forme de valeur d'une énumération), et l'action à entreprendre suite au message (sous forme de valeur d'une énumération).

Pour raison de performance, on n'utilise pas de fichier de propriétés pour associer le libellé au code, ceci est fait directement dans la classe. L'impact et l'action sont des énumérations internes, qu'il convient d'utiliser ou de compléter. Leurs déclarations de valeurs sont aussi des constructeurs auxquels on passe une description courte et une description longue, la première devant être incluse dans le message de log.

Les valeurs énumérées et les descriptions sont en français. On peut créer une interface de cette classe Log, Ilog, est écrire une implementation pour chaque langue supporté par notre application. Après par fichier de configuration on pourrait désigner une implementation ou une autre à instancier pour notre application installé.

Se référer à Enums pour une explication sur l'utilisation avancée des énumérations.

Design principles

2011-07-24T17:13:00.000-07:00

Fancy words are beeing used by many software developpers. I can hear in my office many people discussing design patterns. I find it curious that most of those developpers knows many of design patterns but don't know anything about design principles. It is usual in our entropic world to do and talk about things without knowing why.

Here are the five design principles u should know, before designing Object Oriented applications.

Open Close Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they don't use.

Single Responsibility Principle

A class should have only one reason to change.

Liskov's Substitution Principle

Derived types must be completely substitutable for their base types.

For more details, check for ur own benefit, this reference:

http://www.oodesign.com/design-principles.html

Designing thread safety

2010-06-30T18:12:00.000-07:00

Java language and API supports multi-threading, so let's discuss briefly the key points, we should consider designing thread safe.

Why do we need thread-safe? Well, because multithreading is built into Java, it is possible that any class you design eventually may be used concurrently by multiple threads. You needn't (and shouldn't) make every class you design thread-safe, because thread safety doesn't come for free. But you should at least think about thread safety every time you design a Java class.

Given the architecture of the JVM, you need only be concerned with instance and class variables when you worry about thread safety. Because all threads share the same heap, and the heap is where all instance variables are stored, multiple threads can attempt to use the same object's instance variables concurrently. Likewise, because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. When you do choose to make a class thread-safe, your goal is to guarantee the integrity -- in a multithreaded environment -- of instance and class variables declared in that class.

You needn't worry about multithreaded access to local variables, method parameters, and return values, because these variables reside on the Java stack. In the JVM, each thread is awarded its own Java stack. No thread can see or use any local variables, return values, or parameters belonging to another thread.

Given the structure of the JVM, local variables, method parameters, and return values are inherently "thread-safe." But instance variables and class variables will only be thread-safe if you design your class appropriately.

How to make an object thread-safe?

There are basically three approaches you can take to make an object thread-safe:

Synchronize critical sections: For this approach is essential to make all fields that you need to coordinate multithreaded access to, private. (only the fields involved in any temporarily invalid states). Otherwise it may be possible for other classes and objects to ignore your critical sections and access the fields directly. Then, you need to mark the object's critical sections as synchronized. A critical section is a bit of code that must be executed atomically, that is, as a single, indivisible operation. (use the Syncronized modifier).
Make it immutable: An immutable object is one whose state can't be changed once the object is created.Immutable objects are, by their very nature, thread-safe simply because threads have to be able to write to an object's instance variables to experience a read/write or write/write conflict. Because no methods (only the constructor) of an immutable object actually write to the object's instance variables, the object is by definition thread-safe.In this approach to making an object thread-safe, you don't mark critical sections as synchronized. Instead, you separate out the critical sections that read instance variables from those that write to instance variables. The critical sections that read are left as-is. The critical sections that write must be changed so that, instead of altering the current object's instance variables, they create a new object that embodies the new state and returns a reference to that object.
Use a thread-safe wrapper: The third approach to making an object thread-safe is to embed that object in a thread-safe wrapper object. In this approach you leave the original class (which isn't thread-safe) unchanged and create a separate class that is thread-safe. Instances of the new class serve as thread-safe "front ends" to instances of the original class.

Why not just synchronize everything?

thread safety may involve a performance penalty. For example:

Synchronized method invocations generally are going to be slower than non-synchronized method invocations. In Sun's current JVM, for example, synchronized method invocations are 4 to 6 times slower than non-synchronized method invocations.
Unnecessary synchronized method invocations (and synchronized blocks) can cause unnecessary blocking and unblocking of threads, which can hurt performance.
Synchronization gives rise to the possibility of deadlock, a severe performance problem in which your program appears to hang.

Using immutable objects
Achieving thread safety by making objects immutable (Approach 2) works well when objects are small and represent values of a simple abstract data type. The Java API includes several examples of immutable objects, including String and the primitive type wrappers such as Integer, Long, Float, Boolean, Character, and so on. If the overhead of immutability (excessive creation of short-lived objects) may at times be too inefficient, you can define a mutable companion class that can be used when the immutable version isn't appropriate.

Using wrapper objects

The wrapper object approach to thread safety makes the most sense when you want to give clients a choice between a version of a class that is thread-safe and one that isn't. This approach also makes sense when you're a client of someone else's class that isn't thread-safe, but you need to use the class in a multithreaded environment. Once you define your own thread-safe wrapper for the class, you can safely use the class in a multithreaded environment by going through your wrapper.

When to make classes thread-safe

Your thread-safety decision should be based simply on whether or not your class will be exposed to potential write/write or read/write conflicts by your programs. To know whether or not such conflicts are possible, you just have to know how your program will work.

If, instead of creating classes for an applet or application, you are creating classes for a library, either one that will be shared in-house or will serve as a product in its own right, you have a different problem. You may not know exactly how the classes will be used. In such cases, it may be a good idea to give clients a choice via the thread-safe wrapper approach.

Resources

Resources and discussion forum.

http://www.artima.com/designtechniques/

¿Porque usar los tags de struts de la librería html si lo que me genera es codigo HTML?

2009-11-02T04:02:00.000-08:00

Dépues de plantear la cuestión de ¿Porque usar los tags de struts de la librería html si lo que me genera es código HTML?
He averiguado que los tags de struts HTML, te rendrizan el HTML y además te enlazan los campos de HTML con las propiedades de tu actionForm. Por lo cual te ahorra en la action hacer el getParameter de todos y cada uno de los elementos de tu form para asignarlos a tu actionForm. Otra de las ventajas es que permiten recuperar "resources" del fichero de recursos según el idioma predeterminado de navegador (i18n). Para un tag "img" por ejemplo los valores de "altkey" se recogería de los ficheros de recursos según el idioma del cliente,como es el caso para titlekey. Cabe mencionar que se puede poner “alt” ó “title” en el tag, sin problemas.

¿Como surgió OOP?

2009-10-29T07:25:00.001-07:00

Vamos a frikear un poco y hablar del punto de vista de metodología de la ciencia como surgió OOP. Déspues de haber leído el siguiente artículo: "Existe una bala de plata" de Brad J. Cox. sobre la crisis del software, que podréis encontrar en el site de Cox.

Junto a los artículos titulados 'No Silver Bullet, Essence and Accidents of Software Engineering' y 'No silver buller revisited' se dibuja una buena perspectiva acerca de la crisis del software que vivimos en un pasado y qué seguimos viviendo de vez en cuando, todavía existen muchas funcionalidades y APIs que deberían ser cajas negras para nostros, pero sin embargo, siempre acabamos investigando un buen rato hasta verlas grises, ó blancas del todo, para su manejo.

En 1968, la Conferencia sobre Ingeniería de Software de la OTAN acuño la expresión "Crisis" para indicar que el software era escaso, caro, de insuficiente calidad, difícil de planificar y casi imposible de gestionar.

De otra parte, algunas publicaciones de Fred Brooks especialmente No Silver Bullet: Essence and Accidents of Software Engineering aducen que las dificultades son inevitables, ya que surgen de la esencia ineludible del software. ¿Como explica Brad j. cox esta crisis? ¿Qué son los criterios que nos permiten reconocer que efectivamente vivimos una crisis de software?

Muy bien, notamos que los componentes del dominio del software obedecen unas leyes específicas de un caso único, no existen directrices generales que pongan orden en el ámbito del software, no podemos evitar la confusión en clasificarlos ni en definir con precisión los conceptos usuales en este dominio.

La comunidad del software mantiene su encaprichamiento con los procesos que utilizamos para la construcción de objetos, persiguiendo la perfección, en vez de centrarse en hacer software tangible y dúctil ante la manipulación del sentido común facilitando a los consumidores de software que cada uno resuelva sus propios problemas especializados de software de la misma forma que se resuelven los problemas de fontanería: montando soluciones a partir de un robusto mercado de componentes reutilizables y fácilmente asequibles que, a su vez son suministrados por múltiples grados de producción de nivel inferior.

El desarrollo de un mercado robusto y muy detallado de componentes de software reutilizables en el cual podemos encontrar piezas estándar implica una arquitectura multinivel de software análoga a la arquitectura multinivel de hardware.

Al leer estos textos se refleja claramente una corriente de metodología científica que converge y corresponde con los paradigmas de Thomas S. Kuhn.

Fases del desarrollo científico de acuerdo con los paradigmas de khun:

Pues tenemos una etapa précientifica: Después de la revolución industrial, que había provocado suficientes avances, produciendo importantes logros en el transporte, las comunicaciones y la informática. La era de la información, el recurso crítico para convertir datos en bruto en información útil, estaba empezando.

Luego tenemos la fase de Constitución de paradigmas: El modelo centrado en los procesos

Otro componente de los paradigmas de Khun que se cumple; Ciencia Normal: Los programadores no se cuestionan el paradigma ni sus realizaciones. Esta fase se caracterizó con una gran productividad. Sin embargo, esto no quita la existencia de anomalías que han ido apareciendo al marco del paradigma.

Anomalías: Plazos incumplidos y presupuestos que se podían disparar en el desarrollo de algunas aplicaciones, llevando en algunas ocasiones a productos fallidos.

Crisis: El software era escaso, caro, de insuficiente calidad, difícil de planificar y casi imposible de gestionar.

Revolución científica: Una revolución industrial del software basada en piezas reutilizables e intercambiables.

Nuevo paradigma: Tecnologías orientadas a objetos

Este suceso de la crisis de software se puede explicar tambien de acuerdo a una metodología científica elaborada por Imre Lakatos, el falsacionismo refinado.

Falsacionismo refinado:

Una Teoría T es falseada por otra T’ si y solo si:
1) T’ tiene un exceso de contenido teórico respecto a T.
2) T’ explica todo el éxito previo de T.
3) Una parte del exceso de contenido de T’ resulta corroborado.

Lakatos plantea con el falsacionismo refinado una crítica al criterio irracional de sustitución de teorías y al concepto de revolución científica. Aplicando dicha metodología, el cambio de paradigma estructurado centrado en procesos por el paradigma orientado a objetos no resulta coherente. Pues, no se cumplen las condiciones para poder falsear el modelo antiguo y aducir el cambio de paradigma.

Otro hecho en la historia de informática que planteó un cambio de paradigma es por ejemplo: la aparición de los computadores personales y su encuentro con las redes. Esto ha introducido cambios radicales en la práctica informática, ya que el modelo al cual se aspiraba antes era que con unas pocas de aquellas enormes máquinas como el ENIAC se suplirían las necesidades computacionales de la época.

Aquello supuso cambios auténticos humanos y empresariales, tanto en la industria tecnológica (arquitecturas de ordenador, modelos de programación, arquitecturas de sistemas operativos…) como en la sociedad.

Seguiremos viviendo procesos de evolución entre entropías tendiendo a utopías.

Diferencias entre forward y redirect

2009-10-29T04:06:00.000-07:00

Un redirect implica enviar un codigo http 300 con la url de redirección al cliente, y será este ultimo quien realizará una nueva petición a esa url. En cambio un forward es un mecanismo interno del servidor de aplicaciones que sirve para seguir gestionando la misma petición con otro elemento (otro jsp, otro servlet, etc) pero, en cualquier caso, no hay comunicación con el cliente.

Si haces un forward, el objecto que gestione la solicitud a partir de ese momento tendrá acceso a la misma instancia de HttpServletRequest que antes del forward (ya que es la misma peticion). Un ejemplo claro de forward que aparece en struts y en cualquier mvc es entre el controlador (tu Action) y la vista (tu jsp).

<send:Redirect to="/supagina.html" />

<send:forward to="/supagina.html" />

Es mas común y eficiente usar un forward, el redirect tiene sentido si necesitas que el nuevo recurso del redirect que va a atender la petición sepa cual es la url del cliente.

En scriptlet un redirect, se invoca directamente sobre el objeto impliticto response, sería algo así:

response.sendRedirect("/suPagina.html");

El scriptlet para hacer un forward, se invoca sobre un objeto RequestDispatcher que primero habrá que instanciar:

RequestDispacher rd = request.getRequestDispacher("/resource.jsp");

rd.forward(request,response);

Otro metodo util del request dispatcher es el include, permite incluir el texto de un fichero dentro de la página:

RequestDispacher rd = request.getRequestDispacher("/resource.jsp");

rd. include (request,response);

La forma de hacerlo con un tag sería la siguiente:

<jsp:include page="sub_botonera.jsp" flush="true">

Tambien se le puede pasar parametros, que se pueden recoger de la "request.getParameter":

<jsp:include page="scripts/login.jsp">

<jsp:param name="username" value="jsmith" />

</jsp:include>

Un include tambien puede hacerse de esta foram pero tiene menos juego:

<%@ page include="/pagina.jsp" %>

Etiquetas JSP

2009-10-29T03:36:00.000-07:00

Las etiquetas pertenecientes a la especificación JSP. Proporcionan una funcionalidad básica.

Un primer grupo de etiquetas proporciona funcionalidad a nivel de la página de una manera muy simple:

- <jsp:forward></jsp:forward>, redirige la request a otra URL.

- <jsp:include></jsp:include>, incluye el texto de un fichero dentro de la página.

- <jsp:plugin></jsp:plugin>, descarga un plugin de Java (una applet o un Bean).

Un segundo grupo permite manipular componentes JavaBean sin conocimientos de Java.

- <jsp:usebean></jsp:usebean>, permite manipular un Bean (si no existe, se creará el Bean), especificando su ámbito (scope), la clase y el tipo.

- <jsp:getproperty></jsp:getproperty>, obtiene la propiedad especificada de un bean previamente declarado y la escribe en el objeto response.

- <jsp:setproperty></jsp:setproperty>, establece el valor de una propiedad de un bean previamente declarado.

JSTL y EL buena alternativa a Scriptlets

2009-10-20T05:26:00.000-07:00

La creación de sitios Web dinámicos en Java, requiere la incrustación de scriptlets para algunos (código Java embebido). Se pueden identificar algunas debiladades en dicha práctica, entre las cuales se citan:

El código Java embebido en scriptlets es desordenado.
Un Desarrollador Web que no conoce Java no puede modificar el código Java embebido.
No permite a los diseñadores y personas que describen la lógica de presentación que actualicen el contenido de la página con facilidad.
El código de Java dentro de scriptlets JSP no pueden ser reutilizados por otros JSP, por lo tanto la lógica común termina siendo re-implementada en múltiples páginas.

JSTL Java Standard Tag Languages y EL Expretion Languages, son extenciones a la especificación Jsp de sun, surgieron para simplificar el desarrolllo de JSP's, y eliminar los problemas citados previamente.

En este post comentaremos la sintaxis de JSTL, en concreto de su librería core, que representa el lenguaje de control de flujo en una JSP, en paralelo hablaremos de EL que representa el lenguaje de acceso a datos.

Primero y ante todo, para poder escribir tags JSTL y que estos seán interpretables habrá que incluír la directrice:

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>

Instrucciones de selección

A continuación, Veamos cual es la sintaxis de las instrucciones de selección que se pueden hacer con JSTL. Empezamos con las más simple, con un ejemplo. El codigo ilustrado abajo.

<c:if test="${!empty cookie.userName}">
Welcome back <c:out value="${cookie.userName.value}" />
</c:if>

En JSTL, la palabra reservada "empty" , comprueba que un valor es vacío (null, string vacío, o una collección vacía).

Seguimos con la estructuras de selección multiple, este ejmplo ilustra la sintaxis de un swith case:

<c:if test="${pageContext.request.method=='POST'}">

You entered:

<c:choose>
<c:when test="${param.enter=='1'}">One
<br />
</c:when>
<c:when test="${param.enter=='2'}">Two
<br />
</c:when>
<c:when test="${param.enter=='3'}">Three
<br />
</c:when>
<c:otherwise>
<c:out value="${param.enter}" />
<br />
</c:otherwise>
</c:choose>
</c:if>

Mencionar que un tag "else", no existe como tal en el core de JSTL. Pero se puede hacer una sentencia "if else", recuriendo a la estructura anterior, haciendo un "when" y un "otherwise". Ejemplo:

<c:choose>
<c:when test="${param.enter=='1'}"> HOLA</c:when>
lt;c:otherwise> ADIOS </c:otherwise>
</c:choose>

En los ejemplos anteriores habréis constatado, que se han usado expresiónes EL para recuperar valores de distintos atributos y distintos objetos. Para los objetos implicitos está la siguiente correspondencia que viene bien tener en claro:

//Solo recupera parametros Strings que se han mandado por la url, vía Post o Get.
${param.test} --> request.getParameter("test") ;

//Recuperan un objeto cuya clave se pasa como parametro, es un hashMap definido.
${requestScope.test} --> request.getAttribute("test");
${sessionScope.test} --> session.getAttribute("test");
${applicationScope.test} --> application.getAttribute("test");
${pageScope.test} --> pageContext.getAttribute("test");
${test} --> pageContext.findAttribute("test");

Definir una variable

La forma de definir una variable, es la siguiente:

<c:set var="noOfRows" value="10">

Se le puede especificar el atributo "scope" que puede tomar los siguientes valores: page, request, session o application. Por defecto cuando no se especifica el scope toma el valor page

Instrucciones de repetición

La forma de iterar con JST es mediante la instrucción "forEach" y además se le puede especificar los atributos begin y end.

<c:forEach items="${forecasts.rows}" var="${city}"
begin="${param.first}" end="${param.first + noOfRows - 1}">
City: <c:out value="${city.name}" />
Tomorrow's high: <c:out value="${city.high}" />
Tomorrow's low: <c:out value="${city.low}" />
</c:forEach>

Tratamiento de urls:

Los ejemplos anteriores funcionan bien mientras se utilicen las cookies para seguimiento de sesión. No está todo dado; el navegador podría tener desactivadas las cookies, o no soportarlas. Por lo tanto es una buena idea activar el contenedor para usar la reescritura de URL como backup de los cookies. La reescritura de URL, como podrías conocer, significa poner el ID de la sesión en todas las URLs usadas en los enlaces y formularios de la página. Una URL reescrita se parece a algo como esto:

myPage.jsp;jspsessionid=ah3bf5e317xmw5

Cuando el usuario pulsa en una línea como esta, el identificador de sesión ID se envía al contenedor como parte de la URL. La librería corazón de JSTL incluye la acción , que tiene cuidado de la reescritura de URL por nosotros. Aquí está como podemos usarla para mejorar la generación del enlace "Previous Page" del ejemplo anterior:

<c:url var="previous" value="foreach.jsp">
<c:param name="first" value="${param.first - noOfRows}" />
</c:url>

<a href="<c:out value="${previous}"/>">Previous Page</a>

Usar import ó include:

<c:import></c:import> es una acción más flexible que la acción estándar <jsp:include></jsp:include>. Podemos usarla para incluir contenido desde los recursos dentro de la misma aplicación Web, desde otras aplicaciones Web en el mismo contenedor, o desde otros servidores, usando protocolos como HTTP y FTP.

En este post se ha intentado introducir a la buena practica de usar JSTL y EL, existen todavía otras librerías de JSTL, para formateo de datos y internacionalización, tratamiento xml y para la gestión conexiones a bases de datos. La core es la más útil ya que se ocupa de las cosas básicas como son iteraciones, condicionales, manipulación de URL y otras funciones generales, por esta razon he optado escribir sobre ello.

Inicios de la abstracción del hardware

2009-09-22T04:15:00.001-07:00

En los albores de la programación no había ningún tipo de abstracción. La “programación” en aquel entonces era completamente diferente a como la conocemos ahora. En general el hardwareproporcionaba un medio de escribir códigos hexadecimales en su memoria, y una vez en memoria los códigos eran procesados.

El primer ordenador personal que jamás se vendió fue el MITS ALTAIR 8800. Esta pieza de tecnología venía equipada con 256 flamantes bytes (no, no kbytes) de memoria RAM – ampliables, eso sí, a 2, 4, 8 ¡e incuso 12 KB! La introducción de códigos hexadecimales se realizaba utilizando algunas “palancas”, que al ser accionadas modificaban el valor de los bits en la memoria, mostrándose el cambio en los LEDs.

La primera evolución fueron los ensambladores. En lugar de escribir el código directamente en binario, el programador utilizaba nemotécnicos. Así, se pasó de escribir “0xFFAC” a escribir algo parecido a “ADD A,B” N.B: Los nemotécnicos no aislan al programador del hardware; para programar en lenguaje ensamblador es necesario conocer la máquina tan bien como cuando se programa directamente en código máquina.

El primer entorno de programación (limitado) que permitía “ignorar” el hardware fue BASIC. Conociendo una serie de conceptos abstractos, era muy sencillo escibir programas interpretables por antlair BASIC ADD A,B pasó a convertirse en LET speed=speed+aux.

N.B: El Altair BASIC fue un intérprete para el lenguaje de programación BASIC que corría en el Altair 8800 de MITS y posteriormente en las máquinas de Bus S-100. Fue el primer producto de Microsoft (como Micro-Soft), distribuido por MITS bajo contrato. Altair BASIC fue el principio de la gama de productos de Microsoft BASIC.

Extended BASIC fue el primer software comercial que desarrolló un tal Bill Gates. Con el tiempo, no obstante, los lenguajes de programación han ido evolucionando más y más, añadiendo más y más abstracción, de manera que hoy en día la mayoría de programadores desconocen por completo la arquitectura de la máquina sobre la que están programando. Los lenguajes compilados más utilizados fueron, primeramente, FORTRAN, y más tarde C.

Restaurar el Grub

2009-09-22T03:05:00.000-07:00

Al instalar cualquier sistema operativo Microsoft, se sobreescribe el MBR, borrando nuestro sistema de arranque, lo cual es molesto para algunos usuarios nuevos de Linux, ya que no pueden acceder a su máquina Linux. Lo curioso es que sistemas operativos Microsoft se detectan entre sí, y no borran la información de arranque de otros sistemas operativos Microsoft, pero las de otros sistemas operativos, sí.

Para recuperar nuestro sistema de arranque, introducimos un LiveCD de Ubuntu, lo arrancamos, y ejecutamos por consola:

sudo cfdisk

Identificamos la partición de linux, suele tener un sistema de archivos ext3, en mi caso es: sda4. Una vez localizada dicha partición la montamos:

sudo mount /dev/sda4 /mnt/sda4 -t ext3

y luego reinstalamos el grub en sda


sudo grub-install --root-directory=/mnt/sda4 /dev/sda

Ya tienes tu Grub restaurado con dos comandos ejecutados.

IA : Algoritmos de búsqueda en Juegos

2009-06-19T09:04:00.000-07:00

A fin de comprender el funcionamiento del algoritmo alfa-beta para la búsqueda en juegos dejaré un ejemplo de una implemetación de dicho algoritmo en una próxima entrada de mi blog. El ejemplo que dejaré publicado fue implementado para calcular la mejor jugada para un juego de origen africano, como no, bipersonal llamado OWARE ó wari.

En juegos bipersonales el algoritmo más usado es el denominado Minimax. El procedimiento de búsqueda Minimax es una búsqueda en profundidad (DFS) de profundidad limitada. Este algoritmo es bastante costoso en cuanto a complejidad temporal. Para acotar el espacio de búsqueda de la mejor jugada, encontramos otros algoritmos como: Alpha Beta, SSS*o Scout.

Vamos a explicar el principio de como funcionan todos estos algoritmo de busqueda mencionados aplicados a juegos, sin entrar en los detalles de complejidades espaciales y temporales de los mismos, pues los dejaremos para proximos Posts. Partiendo de un estado del juego, por ejemplo un tablero, que representará el nodo raíz de nuestro arbol de busqueda, bifurcamos todas las posibles jugadas, obtenemos N estados nuevos de tablero en el nivel 1, luego volvemos a bifurcar todas las posibles jugadas que puede hacer nuestro adversario, volveremos a obtener N estados nuevos para el nivel 2, y así sucesivamente, hasta llegar al ultimo nivel (que fijáremos dependiendo de las limitaciones tiempo y memoria) donde evaluaremos los tableros, ventajas y desventajas de cada uno. Para evaluar los estados del tablero finales, los que corresponden a los nodos hoja de nuestro arbol, llamamos a una fución de evaluación, que tendrá como propósito, para un estado dado de un tablero, analizar y ponderar de forma óptima y eficiente el estado de este último según los criterios que se hayan tomado en consideración. Es obio que la función de evaluación desempeña un papel muy importante en la búsqueda y obtención de la mejor jugada.

Esta función nos devuelve el mejor resultado obtenido, vuelta atrás, y ya tenemos la mejor jugada.

Ahora bien, el MiniMax es el algoritmo más costoso en cuanto a complejidad temporal y espacial, su mejora es el alpha-beta, introduce poda teniendo en cuenta cotas superiores e inferiores de los espacios de búsqueda, limitando así el espacio de la solución. SSS* es más eficiente en caunto a complejidad temporal, sin embargo consume bastante recursos de memoria. Scout reduce las complejidades temporales y espaciales de forma espectacular en algunos casos.

Si otpaís por implementar alguno tenerlo en consideración.

¿En que consiste el mito de que la informática es un campo de programadores?

2009-06-19T08:49:00.000-07:00

Este mito consiste en percibir el campo de informática como un campo que se basa y se resume fundamentalmente en la programación. Ya que firmemente es alojado en películas, novelas, noticias, publicidad, discursos políticos, percepciones de otros científicos e ingenieros, y en las mentes de principiantes anticipados a nuestra profesión. Que es más, muchas personas creen que la informática es sólo un campo de tecnología sin mucha ciencia e ingeniería; la palabra “ciencia” en este campo parece inmerecida. Peter J. Denning Comenta en su articulo: The Field of Programmers Myth, The persistent public image of computing as a field of programmers has become a costly myth. Reversing it is possible but not easy.

¿Cómo se puede hacer frente a esto?

Establecer y afirmar un gran marco de principios de una nueva representación de nuestro campo que acentúa nuestros principios científicos y de la ingeniería y nuestras cuatro prácticas principales es clave para hacer frente a esto. Nuestros principios fundamentales están en el diseño y en la mecánica de cómputo, comunicación, coordinación, y la automatización. Estos principios no fueron tomados prestados de otros campos; los informáticos los desarrollaron. El examinar este mundo por una ventana de programa no permite ver lo que verdaderamente representa. Nuestro desafío debe adoptar una visión más amplia del campo, que revela la ciencia y no confunde la ciencia y la práctica.

¿Como formar a nuestros ingenieros teniendo en cuenta esto?

Para Fred Brooks el escollo fundamental de la programación, es y siempre será, el comportamiento complejo de sistemas de software grandes. Según él, el desarrollo y la producción de software es esencialmente un problema de talento y diseño que sólo puede ser encontrado por una determinación y preocupación por cultivar a grandes diseñadores; No cultivando a grandes programadores. Subrayando la importancia del diseño de sistemas. La adquisición de un talento y una habilidad en asimilar ideas y conocimientos, tienen un enorme efecto sobre la calidad del trabajo: desarrolladores buenos de software son a menudo 10 veces más productivos que principiantes. Brooks sugiere hacer un esfuerzo concertado para enseñar a la comunidad de informáticos ser grandes diseñadores y desarrolladores de software expertos.

De otra parte, tenemos a Dijkstra, un creyente apasionado en la visión matemática de programas y programación, piensa que el modo correcto de enseñar la informática es ofrecer una docencia más sólida en la derivación formal de programas de los predicados lógicos que expresan sus requisitos, proponiendo eliminar de los cursos de principio, asignaturas que abarquen el estudio del verdadero mundo de lenguajes de programación.

¿Cuales son las habilidades que debe tener un profesional de TI de acuerdo a Dening?

Un profesional de TI de acuerdo a Dening debería tener el conocimiento extenso de bibliotecas y algoritmos básicos y ser capaz de juntar muchos módulos en un sistema que satisface a clientes. Tendría el conocimiento extenso de los acontecimientos históricos en el programa, sería capaz de diseñar sistemas de software grandes que combinan muchos niveles de abstracción, y definiría los nuevos métodos que mejoran toda la práctica de programa.

Denning hace cuatro recomendaciones para ayudar a reorganizar el plan de estudios para la enseñanza de nuestra disciplina de un modo coherente.

1. Enseñar el pensamiento algorítmico. El pensamiento algorítmico es una práctica mental de ingeniería y el descubrimiento científico que conceptúa problemas con representaciones digitales y busca algoritmos que expresan o encuentran soluciones.

2. Agrupar la enseñanza de prácticas en una sección de Prácticas de computación del plan de estudios.
Los cursos ahora son etiquetados Informática 1 y 2, pudiendo en la mayor parte de casos ser etiquetado de nuevo Programando Prácticas1 y 2. La introducción a la ingeniería de software puede ser modificada para ser la introducción a prácticas de sistemas. Un curso de prácticas de modelado tendrá que ser añadido a la mayor parte de planes de estudios. El curso de diseño cada vez más popular también puede enseñar prácticas de innovación.

3. Estructurar un marco que da clases alrededor de una escala de capacidad en la práctica.
En cualquier dominio, la escala de capacidad describe los niveles aprobados de habilidad que uno puede lograr dando bastante práctica y experiencia. Definir a los criterios que nos permitirían juzgar el nivel en el cual alguien funciona. Clasificar tanto la calidad del trabajo como la calidad del funcionamiento. Conseguir a profesores con experiencia en el campo para estos cursos.
Aplicando esto, podemos ver criterios diferentes en cada nivel.

4. Enseñar la práctica de detección y corrección de errores. Incluso la gente más experta hace errores.
El provocar errores es parte del proceso; el descubrimiento, la corrección, y el estudio de ellos son parte de la práctica.
Los estudiantes tienen que ver desde el principio como conectar abstracciones a acciones.

Dening propone el establecimiento de una gran Biblioteca de Principios para apoyar a la gente de nuestro campo en el estudio de los principios y la representación orientada de la informática. La Biblioteca contendría secciones para los grandes principios: el diseño y la mecánica, también para las prácticas principales: la programación, modelado de sistemas, y la innovación, y a continuación las tecnologías principales. Cada sección ofrecería materiales de clase, tutoriales para principiantes, intermedios, y avanzados; seminarios; resúmenes históricos de la evolución de principios y prácticas; Convendría que esto sea supervisado por unos redactores que se preocuparían de la calidad, la consistencia, y la exactitud de los materiales incluidos. Esto sería la parte de la Biblioteca ACM Digital.

Arte

2009-06-19T08:35:00.000-07:00

¿Qué sería la vida sin arte?