When the world ends...
frameborder="0" allowfullscreen>
Nov 11, 2011
Nov 9, 2011
Trans-Application
In the last 10 years, with the rise of Apple devices and the mobile movement, applications must be cross-platform to survive. But lately, with Android or the Chrome browser, we see a new trend emerging where devices are created to be compatible with specific OS or applications. I call this Trans-Application.
I figured, we're already using the cross-platform, cross-device and cross-console when we refer to software compatibility, now we need a prefix for device compatibility.
Applications are gaining more and more power. Getting to FaceBook is more important than the way you get to it. Would you be surprised if there was a FaceBook tablet? It's not that crazy since 10 years ago people would have laughed at you if you had mention the possibility of a Chrome Book laptop.
Devices will soon have to conform to more than OS demands but probably to applications demands.
Trans-Application... or maybe Trans-App.
I figured, we're already using the cross-platform, cross-device and cross-console when we refer to software compatibility, now we need a prefix for device compatibility.
Applications are gaining more and more power. Getting to FaceBook is more important than the way you get to it. Would you be surprised if there was a FaceBook tablet? It's not that crazy since 10 years ago people would have laughed at you if you had mention the possibility of a Chrome Book laptop.
Devices will soon have to conform to more than OS demands but probably to applications demands.
Trans-Application... or maybe Trans-App.
Nov 8, 2011
The deep end of the pool
When we think about Cloud computing two big players come into mind; Microsoft Azure and Amazon Web Services (AWS). A lot of people think that ‘Cloud is Cloud’ so both of them must be offering the same product, right? Well, one major difference between the two may change this point of view. Their philosophy of cloud development is radically different.
Before talking about those philosophies, another obvious difference must be mention. AWS is an Infrastructure as a Service (IaaS) while Azure is a Platform as a Service (PaaS).
Because a Cloud infrastructure is analog to a Grid infrastructure, processing can be distributed between multiple instances. So, for a process to really use the Cloud power it should be highly parallelized. Also, anybody that look into Cloud development long enough realizes that scalability and reliability can only be achieve through an abstraction layer (PaaS) that will manage self contained tasks and will be resistant to the failure of one or many instances. Finally, we also know that the state of availability in a Cloud will change over time. A Cloud process must adapt to that change and should proactively monitor availability instead of stopping when encountering availability issues.
This level of development architecture is not easily achieved. Developers who find that simple are most probably using other important principles like multi-threading and error recovery. This can all be done on a multi-core computer. When you add the complexity of distributed computing (grid computing), development architecture becomes even harder.
Now, back to philosophy.
When approaching Cloud Computing, the architect of a non-optimize system must decide to either, continue using their current philosophy or upgrade it by including parallelism, resilience to task failures and adaptation to changes in availability. This can be an overwhelming task and some architects choose the status quo.
The difference between Microsoft and Amazon is that Microsoft’s Azure is adhering to those optimization principles and therefore steer the users toward developing that way. On the other hand Amazon provide access to a bare bone IaaS the lets you run your processes no matter how non-optimize they are.
So, there you go. For non-optimized developers, developing with Azure is like learning to swim by jumping in the deep end without a flotation device.
I like the challenge!
Before talking about those philosophies, another obvious difference must be mention. AWS is an Infrastructure as a Service (IaaS) while Azure is a Platform as a Service (PaaS).
Because a Cloud infrastructure is analog to a Grid infrastructure, processing can be distributed between multiple instances. So, for a process to really use the Cloud power it should be highly parallelized. Also, anybody that look into Cloud development long enough realizes that scalability and reliability can only be achieve through an abstraction layer (PaaS) that will manage self contained tasks and will be resistant to the failure of one or many instances. Finally, we also know that the state of availability in a Cloud will change over time. A Cloud process must adapt to that change and should proactively monitor availability instead of stopping when encountering availability issues.
This level of development architecture is not easily achieved. Developers who find that simple are most probably using other important principles like multi-threading and error recovery. This can all be done on a multi-core computer. When you add the complexity of distributed computing (grid computing), development architecture becomes even harder.
Now, back to philosophy.
When approaching Cloud Computing, the architect of a non-optimize system must decide to either, continue using their current philosophy or upgrade it by including parallelism, resilience to task failures and adaptation to changes in availability. This can be an overwhelming task and some architects choose the status quo.
The difference between Microsoft and Amazon is that Microsoft’s Azure is adhering to those optimization principles and therefore steer the users toward developing that way. On the other hand Amazon provide access to a bare bone IaaS the lets you run your processes no matter how non-optimize they are.
So, there you go. For non-optimized developers, developing with Azure is like learning to swim by jumping in the deep end without a flotation device.
I like the challenge!
Oct 29, 2011
When not coding...
I once worked in the video game business. Hopefully, with time a medication, I'll get over the nightmares :). Jokes aside, I was there as a software developer and I was secretly dreaming about introducing (in that studio) the use of sculpting during the character design phase. Finally, around 2009, the timing was right and during the design of a new game, I started working on the main character of a dinosaur game, a T-Rex!
My goal was to have the T-Rex stand in a dynamic pose without the tail touching the ground.
Sadly the game was cancelled during design. I never had time to go beyond the basic shape. My next step would have been to add the front legs and skin details. It was fun while it lasted.
My goal was to have the T-Rex stand in a dynamic pose without the tail touching the ground.
Sadly the game was cancelled during design. I never had time to go beyond the basic shape. My next step would have been to add the front legs and skin details. It was fun while it lasted.
Lego RC car
I've just stumbled on this picture from last year when I build a Lego RC car. It is motorized using the Lego Mindstorm 2.0 Brick and two motors. (one for steering and one for propulsion).
For the controller I simply used the Lego Mindstorm remote.
It only had one speed: darn slow. It didn't stopped the kid from playing with it for days.
Edit: you can also see my Mini RC car project here (Using Arduino, Bluetooth & Android)
Subscribe to:
Posts (Atom)