Chepech - "Ars est celare artem"

The Agile manifesto was the common ground found by a (heterogeneous) group of 17 software development experts (who now call themselves The Agile Alliance) with different backgrounds that included Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. They all agreed, in spite of their dramatically different points of view,  on a list of 12 base principles of how software development should be managed. This 12 point list is now known as the Manifesto for Agile Software Development . Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Busine

Everyone working in any IT market with a serious enough  job knows for a fact that the all time champion of outsourcing is by all means the exotic sub continent of India. India has the great advantage, besides the currency exchange differences between USD and Rupiahs, that they have a this huge population of well trained, English speaking people (its entire population is around 900+ million that's 9 times Mexico's ). This makes them the worlds largest talent pool (second after China) for all USA based operations. India also embraces a self improving and study culture that most people adhere to. They also are perceived as a more westernized culture compared to Korea or China which is a bonus for any USA organization outsourcing operations with them because that turns communication flow smoother. USA businesses prefer them for all those reasons and this preference is the cause of the great economic growth they have been experiencing in the last 2 decades. Moving operations

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 recommend

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 def

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 sinc

When interviewing a new candidate to work in our team its easy to focus on the technical experience and knowledge s/he has. This is completely valid considering the candidate is intended to cover a position in the team that demands her/him to be as tech savvy as possible. However this in fact causes that we sometimes overlook on a set of skills that can prove far more vital to the general health of the project and to the development of the person we are interviewing than specific technical skills. I'm of course referring to soft-skills and general emotional intelligence. I can't overemphasis how critical it's for us to recognize skills that lay beyond technical knowledge during an interview. The ability to recognize those from those required technically means the difference between hiring someone who will be willing to learn and adapt to how we do things while eventually adding value to the team and hiring an otherwise apparently qualified individual with that turns into a

One of the things that I love of the software development trait is how fast things change. We are in a never stopping stream of new ideas, changing paradigms; the essence of pure innovation. However, once in a while we look back to old dusty corners of what we used to do and believe and find out that those old forgotten ideas taken from mistaken were actually right all the time. Such is the case for REST architecture, a pretty old idea that fell into oblivion just to become the new trendy buzzword a couple of decades later. Just for historical context; REST architecture was created along with the HTTP specification almost 20 years ago. The idea behind REST is to provide access to resources via an URI, each URI returns the resource representation on a different state, part of the data retrieved from each step contains the means (links) to access a different resource's state (sounds pretty familiar when explained in that way, doesn't it). If you haven’t heard of REST unti