Friday, March 16, 2012

Java - Getting the memory size of an object.

Because the way Java language and the way JVMs are implemented, this apparently trivial task is more complex than it may seem specially when compared to C++ where all objects have a size() method. Java memory architecture is built to abstract the developer from direct manipulation of memory so that the developer can focus on more relevant tasks, this comes with a price.

There are 3 basic approaches you can take in order to do this all with their pros and cons:
  • Memory guess (Heap Size prior object creation - Heap Size after object creation = Object Size)
  • Java Instrumenting Query
  • Serialization

Memory Guess
This is the simplest approach because of the fact that you have a pretty easy access to the Heap Size via:
 Runtime.getRuntime().totalMemory();


The issue with this approach is that you cannot control what is being thrown into the heap at a given time, JVM is shared by a lot of processes that run in a given machine so this is a error prone approach that is not recommended.

Java Instrumenting Query

Starting on Java 5, all JVM have built in instrumentation features . This features can be used to monitor objects size in memory by creating an agent and setting it up for the JVM. This is by far the most precise method of getting the object's size from memory, but it's by no means the easiest/straight-forward. Another drawback is that this may change depending on the JVM you are using (the next example applies only to Oracle's Standard JVM 5 )

The agent looks something like this:

import java.lang.instrument.*;
import com.somepackage.SomeClass;

public class MyAgent {
  public static void premain(String args, Instrumentation inst) {
    SomeClass obj = new SomeClass();
    long size = inst.getObjectSize(obj);
    System.out.println("Bytes used by object: " + size);
  }
}
Then you need to register the agent to the JVM by initializing the application with the folowing parameters:

java -javaagent:agent.jar

That will cause the agent to be registered on the JVM instrumenting layer where it will be able to monitor object's size.
Next you can access these feature with something like:
public class MyAgent {
  private static volatile Instrumentation globalInstr;
  public static void premain(String args, Instrumentation inst) {
    globalInstr = inst;
  }
  public static long getObjectSize(Object obj) {
    if (globalInstr == null)
      throw new IllegalStateException("Agent not initted");
    return globalInstr.getObjectSize(obj);
  }
}
As you have certainly noticed this is no as intuitive as it may seem.
Serialization
This technique uses Java's serialization features to calculate the objects size. This is not the most precise way to do it because memory specific serialization works in a slightly different way than regular object serialization but its a pretty good approximation. One drawback of this approach is that it requires the object to be measured to be Serializable.
This is how a method that mesures the size would look like:
public long sizeOf(Serializable object){
 if (object == null) {
  return 0;
 }

 try{
  final ByteCountingOutputStream out = new ByteCountingOutputStream();
  new ObjectOutputStream(out).writeObject(object);
  out.close();
  return out.size();
 }catch (IOException e){
  if (log.isWarnEnabled()){
   log.warn("Unable to determine object size: " + object.toString(), e);
  }
  return -1;
 }
}
One of the greatest drawbacks of this simple approach is that OutputSreams in general are one of the most commonly known resource hogs in Java so you should treat them with care.

Sunday, March 11, 2012

Crítica a "10 Ideas Erróneas sobre PHP"

Hace algún tiempo me encontré con un post que hablaba sobre las 10 ideas erroneas sobre PHP. Me pareció interesante la idea de hacer un arquetípico post de 10 puntos defendiendo un lenguaje de programación, situacion que por si misma me parece un tanto chusca.

Antes de empezar quisiera aclarar algo. He sido desarrollador de PHP por más de 6 años (de hecho siempre me he considerado un PHPer en recuperación). Dada esa experiencia puedo decir sin temor a equivocarme que PHP es una excelente herramienta para el 95% de los proyectos Web (pequeños), es accesible y tiene una comunidad bastante extensa y heterogénea (esto puede ser un problema en ocasiones). También desarrollo en Java desde hace 7 años y he hecho algunos proyectos en C Sharp con .NET, Flex y actualmente me encuentro en un desarrollo que utiliza Grails (Groovy on Rails) y Griffon por lo que he tenido algo de experiencia con tecnologías muy distintas y filosofías casi opuestas.

Puedo decir con mucha seguridad que PHP definitivamente no es suficiente para proyectos Enterprise donde se tienen que considerar cosas como Estándares, Instrumenting, Automatic, Procurring, Mensajeria y casi cualquier cosa que tenga que ver con trabajar en ambientes distribuidos (en cluster). Los short comings de PHP se deben precisamente a la falta de una plataforma de desarrollo dirigida no solo por la comunidad sino regulada por alguna instancia que la mantenga vigente y sobre todo actualizada.

He aquí mi crítica a los puntos tratados en el post mencionado:

1.- PHP no es un lenguaje “compilado”, es un lenguaje interprete:


El hecho de que el motor de Zend permita "compilar" los scripts a un estado intermedio optimizado (bytecode?) no quiere decir que el lenguaje sea compilado ya que esto es una funcionalidad del motor de Zend y no del lenguaje (La inmensa mayoría de los proyectos corren en una instalación estándar de Apache). Lo mismo se puede hacer con Javascript utilizando Rhino (y algo de voodoo) y eso no hace a Javascript un lenguaje nativamente compilado, o si?

2.-PHP no puede… (Acceder a Memoria, Utilizar Hardware, etc.)


El tener que recurrir a un lenguaje de bajo nivel para compensar las carencias del intérprete de PHP valida precisamente esta afirmación. Es lo mismo si yo digo que con Python puedes leer los pensamientos de las personas... claro solo necesitas crear el Hardware que lo transfiera a paquetes compatibles con TCP/IP y lo envíe hasta el servidor donde Python los leerá.

3.- PHP no puede hacer algo que se puede hacer en la lengua X.


Este punto es redundante con el punto 2, creo que el propósito de incluirlo fue meramente de marketing para llegar al mítico "10" en la lista para que se vea más “oficial”. Sin embargo al inicio listé una serie de cosas que PHP no puede hacer y durante el transcurso de las demás criticas incluiré más, y no solo por la limitante de ser un lenguaje Script interpretado y estructurado, sino que a Diferencia de Java o C (Utilizando .NET) PHP es solo un lenguaje mientras que C y Java son Plataformas de Desarrollo. Ahora, casi cualquier cosa es posible con la cantidad de tiempo y recursos necesarios el problema es el esfuerzo requerido para hacerlo, en cuyo caso PHP requeriría un esfuerzo ENORME para lograr hacer algunas cosas que Nativamente los Frameworks de Java y .NET.

4.- PHP es solo para el desarrollo en WEB.


PPH fue concebido con el propósito de hacer paginas dinámicas y es claramente un lenguaje para desarrollos web. Es decir, no puedes programar drivers para una tarjeta gráfica o un Smartphone con PHP, los usos que planteas son solo extensiones del propósito WEB del lenguaje.

5.- PHP solo es controlado por Zend.


En esto tienes toda la razón. Lo que me parece curioso es que puedo inferir basado en tu comentario que por alguna razón consideras que el hecho de que PHP sea controlado por Zend es algo de alguna manera negativo. Me parece curiosos porque eso es precisamente lo que le ha faltado al lenguaje durante más de la mitad de su existencia; Una instancia seria que lo regule, esto permite que la evolución del lenguaje y de toda la gama de tecnologías que las que depende sean dirigidas y sean por lo tanto más exitosas, propongan más avances y por lo tanto atraigan a más desarrolladores. Eso ha sido uno de los grandes éxitos de Java (Con SUN y ahora Oracle) y de C y C++ con .NET (con MS).

6.-La documentación de PHP es incompleta he insuficiente.


Existe documentación oficial del lenguaje y es bastante completa. Sin embargo al no haber regulaciones ni estándares cada Liberia puede o no tener documentación suficiente o de plano no tener documentación alguna, pero esto no es algo exclusivo de PHP ya que lo mismo sucede con Java por ejemplo, aunque en menor medida ya que los desarrolladores Java favorecen grandemente a aquellas librerías que se apegan a las implementaciones sugeridas por Oracle o SUN en su momento y eso es un incentivo fuerte para que aquellas que no lo hacen caigan eventualmente en desuso y desaparezcan. Esta es otra de las ventajas de tener una instancia reguladora.

7.- Los proyectos de PHP no son reutilizables, ya que no son orientados a objetos.


En esto tienes razón también, pero por las razones equivocadas. Wordpress es un CMS y el usarlo no significa reutilizar código. Lo que la crítica plantea es que existe un gran número de desarrolladores PHP que no tienen ni siquiera fundamentos básicos de OOP. El OOP implica (usándose bien) componentes reutilizables por lo que muchos desarrollos en PHP no cumplen con esta buena práctica. Sin embargo, nuevamente esto no es un problema de la tecnología en si sino de la comunidad que hace mal uso de ella.

8.-PHP es peor que Ruby On Rails, Python Django, X framework en otro lenguaje


No creo que se pueda comparar un lenguaje contra un framework. El acercamiento orientado a modelos de Ruby on Rails o Grails es muy útil y muy fácil de usar para cierto tipo de proyectos, pero calificarlo como "mejor" es completamente subjetivo. Ahora es una realidad que el crecimiento de estas tecnologías es algo que debería alertar a los desarrolladores PHP ya que ofrecen lo mismo que la plataforma PHP pero mucho más robusto y accesible. Creo que la transición de PHP a Ruby on Rails es algo que se puede dar de forma muy natural para un desarrollador PHP, muchos de los que conozco ya han comenzado a agregar Ruby a su CV. Ruby debe ser visto como una herramienta más en el arsenal del desarrollador y no como una competencia, estamos hablando de tecnologías de desarrollo no de religiones.

9.-PHP no es bueno para los sitios Web escalables o aplicaciones de alto rendimiento


Facebook es una excepción. La razón por la que esa hecha en PHP no es porque haya sido la mejor opción sino porque era lo que Mark Zuckerberg sabia usar cuando comenzó el desarrollo del sito y desde ahí se comenzó a ampliar el fundamento que el planteó. Facebook ha tenido que compensar las limitantes de PHP utilizando técnicas bastante interesantes de Infraestructura y por eso el sitio opera bastante bien, pero insisto, esto no prueba que PHP sea apto para aplicaciones de alto rendimiento ya que su éxito dependería de herramientas externas (y algo de voodoo). Este artículo por ejemplo habla de cómo tuvieron que reescribir desde cero el Intérprete de PHP para poder hacer su plataforma extensible:
http://www.sdtimes.com/blog/post/2010/01/30/Facebook-rewrites-PHP-runtime.aspx


10.- Los desarrolladores de PHP son baratos porque no están calificados


En esto tienes toda la razón en una parte, es mentira totalmente que la razon sea por falta de calificación. El costo de un desarrollador obedece a las reglas de mercado de cualquier servicio o producto; Oferta y Demanda. Existen menos ofertas para desarrolladores PHP y muchos desarrolladores y muchas ofertas para Java y .NET, y pocos desarrolladores. Es por eso que Java y .NET es más caro porque es un bien "escaso" y por lo tanto los desarrolladores Java y .NET ganan mejor que los PHP (de 25 a 30% más dependiendo del Seniority).
Lo interesante de esto es ¿Qué causa esta diferencia de números?. PHP al ser una tecnología mas accesible permite que más gente con menos experiencia pueda adoptar el lenguaje, Mientras que Java y .NET tienen una curva de aprendizaje mayor y son más demandantes como primer tecnología para la gran mayoría de la gente. Yo creo (aunque no lo podría probar) que el éxito de PHP se debe precisamente a esta accesibilidad (No ser fuertemente tipado, el OOP es opcional, No compilas, no hay un framework o API que debas aprender para poderlo usar, No te metes con Patrones de Diseño si no quieres, No hay Maven ni ANT ni builds, ni dependencias, etc) pero como todo tiene su costo y este es que siempre habrá más gente y más competencia y por lo tanto los sueldos no son tan buenos.

Para concluir:

No soy muy fan de este tipo de posts porque hacen parecer a las tecnologías diferentes como religiones y plantean una división en la gente que no es realista. Las tecnologías son solo herramientas y como tales hay unas que son buenas para clavar clavos y otras para apretar tornillos, esto no las hace ni mejores ni peores. Existen algunas herramientas que tiene más de un uso y otras que son más especializadas eso es todo. Lo importante como desarrollador es que no te aferres a al lenguaje que sabes usar como si fuera un credo infalible y te ofendas cuando alguien que maneja alguna otra tecnología señala fallas de la que tú sabes usar y trates de defenderlas ciegamente. Lo importante es que mantengas la mente abierta y que agregues más de esas tecnologías a tu caja de herramientas y te hagas un desarrollador más completo. Quieres ser un mejor desarrollador PHP? Simplemente aprende Java, Python, Scala, Lingo, C o cualquier otro lenguaje.

Thursday, March 8, 2012

Another nail in the Flash's coffin - The rise of HTML5 Games



You'd probably already heard about Game Closure, but if you haven't this is what you been missing...

Game Closure is an independent student start-up company that developed a pretty interesting and amazingly robust Javascript/HTML5 game SDK. The SDK can be used to create games not only for web browsers (Facebook games) but they can be deployed also to iOS and Android devices. The SDK offers client/server real-time communication so this opens the possibility of massive multiplayer capabilities.

They have been recently in the spotlight turmoil since they presented Pop Star Defense, the first game to run in all mentioned platforms which they presented on Google I/O last summer. The interesting thing here is that this endeavor usually required up to 6 months to accomplish by traditional means to any Game Developer company regardless of their size, but it only took 5 weeks to the guys on Game Closure so everyone is looking at them with dollar signs on their eyes since then. Probably the most notable of this eagerly interested companies are of course the FaceBook and Zynga couple but also includes Motorola and EA.

I'm almost certain that Zynga will be the one ultimately acquiring the company, that's mainly because they lack the any solid HTML5 strategy this becomes obvious when you look at Zynga's game portfolio and realize that its almost 100% Flash based. In a culture where Flash is decaying and lingering like a sick old cat Zynga needs to make a tremendous leap before someone else picks up the market they drop to the floor , so for Zynga, Game Closure is precisely the way to get that leap. It has recently announced that Zynga has pushed the offer to around $100 million green bills, this is almost 8 folds bigger than the last offer Game Closure received (which was around $12 million).

So I guess will be seeing HTML based farms, coffee shops and cities in our friends and wives Facebook. This is just another push towards the edge of the abyss of oblivion for Flash. As I have expressed on on the past, the only thing (IMHO) keeping Flash from flatlining is precisely the dependence Zynga has (had) on it…