This is my first Android development test using the NDK and OpenGL-ES. I quickly adapted some simulation code I found on the web and rewrote the rendering layer to make it compatible with OpenGl-ES. I also fixed a couple of bottlenecks to make it run faster. Here's a video of the result.
So far I like working with the Android NDK and OpenGL-ES although I'm not a big fan of the Eclipse IDE (development environment). Now I'm going to start a shippable project to really get the feel for this new platform.
Nov 2, 2010
Snow balling
I admit I'm still buying Legos and a vast majority of those are Lego Technics and Mindstorm that I use for prototypes and robots. But, from time to time like any 37 year old kid, I get a kit simply because it looks cool. Hence I have the Lego X-Wing.
This magnificent piece of design dating from the back-when-lucas-was-good era was siting on my work desk and my son, playing with it, said “Dad, can you make the ladder to climb in?”. Any reason to get my Legos out is a good reason, so Voila!
My son was happy but, like any good geek would, he had the obvious thought; what about the cane gizmo to get R2 in and out of the ship? The clouds parted and a ray of light beamed down on me. I was so ready for his demand... maybe I was too ready.
Not only did I built it but I made a working version using Lego Mindstorm motors and the remote control.
The rotation is powered with gears and the up-down motion is done with a pneumatic piston and a switch to select up or down (directing the air flow to the top or bottom of the piston). This extra manual step will come back to haunt me latter.
After watching my son playing with the crane for a bit, it was apparent that it's reach had to be improved. After all, I could still plug a third motor to the system. Some minutes latter version 2 was alive.
The base is resting on gliding 'skis' and stays in place because two of them are sitting in a groove. One side of the groove serves also as the row of teeth used by a gear (attached to the crane base) to pull or push the whole system. This gear is using a pulley system and so it just slips if the kids reach the end of the tracks (no grinding gears). The pneumatic switch had to be repositioned so that it would not jerk the whole assembly every time it's used (that switch is a real pain). Finally. the arm of the crane was also lengthened.
The kids (and I) played with that version for days. I added a weight in the back to prevent the 'gliding gear' to skip. This is the final version of this design:
In conclusion
The main problem with this crane is the pneumatic switch. All the other movements are made with the remote and the switch make the experience of using the crane awkward.
A second important point is to make it error proof. The pneumatic piston system and the pulley system permit the errors in the crane manipulation without breaking anything. On the other hand, the direct gears that are used to rotate the crane can skip, grind or break if something goes wrong. Also the tubing for the piston prevents the crane from doing a continuous rotation and could rip of. (We had a terrible accident where Han Solo was thrown across the flight deck...)
So the next project will be a new crane with a completely different design that can lift heavier loads and where all the controls are done using the remote. This system will also be error proof by using systems like:
* Pulleys
* Slip gears
* Automatic reverse
This magnificent piece of design dating from the back-when-lucas-was-good era was siting on my work desk and my son, playing with it, said “Dad, can you make the ladder to climb in?”. Any reason to get my Legos out is a good reason, so Voila!
My son was happy but, like any good geek would, he had the obvious thought; what about the cane gizmo to get R2 in and out of the ship? The clouds parted and a ray of light beamed down on me. I was so ready for his demand... maybe I was too ready.
Not only did I built it but I made a working version using Lego Mindstorm motors and the remote control.
The rotation is powered with gears and the up-down motion is done with a pneumatic piston and a switch to select up or down (directing the air flow to the top or bottom of the piston). This extra manual step will come back to haunt me latter.
After watching my son playing with the crane for a bit, it was apparent that it's reach had to be improved. After all, I could still plug a third motor to the system. Some minutes latter version 2 was alive.
The base is resting on gliding 'skis' and stays in place because two of them are sitting in a groove. One side of the groove serves also as the row of teeth used by a gear (attached to the crane base) to pull or push the whole system. This gear is using a pulley system and so it just slips if the kids reach the end of the tracks (no grinding gears). The pneumatic switch had to be repositioned so that it would not jerk the whole assembly every time it's used (that switch is a real pain). Finally. the arm of the crane was also lengthened.
The kids (and I) played with that version for days. I added a weight in the back to prevent the 'gliding gear' to skip. This is the final version of this design:
In conclusion
The main problem with this crane is the pneumatic switch. All the other movements are made with the remote and the switch make the experience of using the crane awkward.
A second important point is to make it error proof. The pneumatic piston system and the pulley system permit the errors in the crane manipulation without breaking anything. On the other hand, the direct gears that are used to rotate the crane can skip, grind or break if something goes wrong. Also the tubing for the piston prevents the crane from doing a continuous rotation and could rip of. (We had a terrible accident where Han Solo was thrown across the flight deck...)
So the next project will be a new crane with a completely different design that can lift heavier loads and where all the controls are done using the remote. This system will also be error proof by using systems like:
* Pulleys
* Slip gears
* Automatic reverse
“Gentleman, we can rebuild it. We have the technology. [...]”
Oct 28, 2010
The neverending Story Points
Here's my second shot at explaining Story Points for estimation in Scrum:
When I switched to points I decided to if I could meet those two points;
1) find and argument that justify the switch and that will convince the team
2) Find an easy method to use it.
Phase 1: Convincing
It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.
This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.
Phase 2: Putting Points in the Backlog
This step is done with the participation of the entire scrum team.
Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.
Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.
NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.
That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.
Phase 3: Velocity & Estimation
To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.
That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value
When I switched to points I decided to if I could meet those two points;
1) find and argument that justify the switch and that will convince the team
2) Find an easy method to use it.
Phase 1: Convincing
It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.
This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.
Phase 2: Putting Points in the Backlog
This step is done with the participation of the entire scrum team.
Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.
Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.
NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.
That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.
Phase 3: Velocity & Estimation
To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.
That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value
May 6, 2010
Serendipity
If you get unwanted or strange results, don’t dismiss them right away.
Ask yourself the question “Can this be used for something?” If it might, take notes of all the parameters so you can reproduce this result whenever you want. Think of it like experimental cooking, if you find something great you save that bunch of steps and ingredients and give it a name. If you don't, this rare event will be lost again.
By the way, this does not only apply to science and cooking. Think about this in everything you do.
Ask yourself the question “Can this be used for something?” If it might, take notes of all the parameters so you can reproduce this result whenever you want. Think of it like experimental cooking, if you find something great you save that bunch of steps and ingredients and give it a name. If you don't, this rare event will be lost again.
By the way, this does not only apply to science and cooking. Think about this in everything you do.
Apr 1, 2010
One hit machines
I believe everybody has the capability to create one good piece of art in as many fields in which they have an interest. Not two good pieces... but probably one in many different fields.
Even though we're not all song writers, painters or industrial designers. I think that we all have it in us to create one good thing in all those fields. That is, if they are of interest to us to start with. If something is interesting to us we think about it in more details and we have a precise mental picture of what the 'best' is for that subject. Let's take song writing as an example. For most of us, since it's just an interest (as opposition to a passion) we don't work in that field and so for years we just roll around that one image of what makes a good song, and the best styles and the kind of subjects we like. We might even catch ourself thinking how cool it would be to hear more songs fitting that bill. So if at a given moment somebody was to ask us “Can you write me lyrics for a good song.” we could say “Yes! I have the perfect song.”. And than the flood gates would open and we would put that song on paper in no time, injecting in it every ideas we've ever had about what would make a good song.
It would, most probably, be our only song. At least for quite some times. This is because all we had went in that one song and we're left with nothing to create a different one.
I could probably ask anybody to design a good cell-phone interface and (if they use cells) they would all have a pretty finite idea on the perfect size, color, finish, button shape and many other details. It's all cool but can they design ten new phones every years? My guess is no. Of course the world is full of exceptions so there are people good at everything and others that couldn't make anything good in fields they love.
Mental pictures let the designer in us give a shot a everything. Unless we actively work at it, I think our 'inner-designer' only works on one concept which is 'the coolest' (for us). Once that concept is used... the tank is empty.
Even though we're not all song writers, painters or industrial designers. I think that we all have it in us to create one good thing in all those fields. That is, if they are of interest to us to start with. If something is interesting to us we think about it in more details and we have a precise mental picture of what the 'best' is for that subject. Let's take song writing as an example. For most of us, since it's just an interest (as opposition to a passion) we don't work in that field and so for years we just roll around that one image of what makes a good song, and the best styles and the kind of subjects we like. We might even catch ourself thinking how cool it would be to hear more songs fitting that bill. So if at a given moment somebody was to ask us “Can you write me lyrics for a good song.” we could say “Yes! I have the perfect song.”. And than the flood gates would open and we would put that song on paper in no time, injecting in it every ideas we've ever had about what would make a good song.
It would, most probably, be our only song. At least for quite some times. This is because all we had went in that one song and we're left with nothing to create a different one.
I could probably ask anybody to design a good cell-phone interface and (if they use cells) they would all have a pretty finite idea on the perfect size, color, finish, button shape and many other details. It's all cool but can they design ten new phones every years? My guess is no. Of course the world is full of exceptions so there are people good at everything and others that couldn't make anything good in fields they love.
Mental pictures let the designer in us give a shot a everything. Unless we actively work at it, I think our 'inner-designer' only works on one concept which is 'the coolest' (for us). Once that concept is used... the tank is empty.
Subscribe to:
Posts (Atom)