I have recently read a very interesting article on the WhileTrue blog, regarding the funny situations in which Microsoft Visual Studio would have achievements, like modern games. You can read the full article here.
While reading the article, I noticed that most of the achievements, also apply in Adobe Flex, but we do have some specifics. Let me give you a few examples:
The fixer: 2 consecutive hours of writing code in debugging perspective.
The hypochondriac: 10 consecutive clean builds on a single project.
No room for error: Finishing a project with Build automatically turned on.
The non-believer: 3 consecutive SVN updates required in order to actually download anything.
luni, 31 ianuarie 2011
luni, 17 ianuarie 2011
Keeping development issues at bay
If you work in web/software development, I'm sure that you encounter very often issues of varying difficulty. One thing that adds to the overall complexity of an issue, is having to specify a time frame needed to resolve it. If we were to classify the issues one can encounter while coding, we get two categories of issues:
1. Issues that you have encountered in the past (directly or indirectly) and you have a pretty good idea about the time needed to resolve it, even if there are some minor variations from your past experience
2. Issues that you have never come across before; in this case, estimating the time needed would prove to be more difficult
However, the first category of issues, contains a small subcategory of issues that rarely surface, but when they do, they can be quite a pain to deal with. I'm talking about issues that not only have small variations from your past experience, but on top of that, the context differs in which the issue appears differs also. Why is this a problem ?
Let's consider the first category of issues. Dealing with an issue that you have approached in the past is usually an easy task, regardless of the time needed, because once you have the necessary experience, you know which way to go. When approaching issues from the second category, if you're lucky enough to not have to specify a time frame, you can go at it at your own pace.
Now consider having to deal with an issue which you have solved in the past, but with a few variations and in a different context. Since you already have experience with it, you might be tempted to give a very optimistic time schedule because you disregard the individual details of issue. So instead of resolving the issue in, let's say, two hours, you end up doing it in two days. Not only does this screw up your schedule, but it can also be very frustrating to spend two days on a feature you initially planned to solve in two hours.
How can we overcome this kind of issues? Well sadly, there is no way to actually recognize one, until you have already missed the deadline. Then, you find yourself in the situation when someone comes you and asks to see your work and you have done only about 20%. I'm sure no one would like to be in that situation. But if you do find yourself in such a "mess", the best idea would be to split the issue in smaller steps.
What I mean specifically, is that the first thing to do is to break it up in the things that you have already resolved in the past and you can use that experience, and the ones that relate to this specific context. Next, make sure that you fully understood the issue. Nothing beats the frustration of finishing a task, and then having to make changes because you didn't understand the requirement all the way and you assumed some things that turned out to be wrong. Having this separation will help you in deciding what to focus on at any given moment, because clever as developers may be, they can only focus on one thing at a time :)
And one more thing that can really help overcome the issue is not being afraid to interact with your colleagues. I'm sure the at times, we find it hard to ask other people regarding how to solve an issue, because we assume that we'll appear unable to resolve it in the first place. That is a misconception. The experience you get by interacting with other people is much greater than the one you get by solving issues on your own. Even if you are absolutely sure you can solve an issue, if you (and they) have time to spare, present the issue and your method of resolving it. They could give you an alternative, which might actually work better (in this case don't be afraid of admitting it), or at least point out some details that haven't crossed your mind, which could help planning and save you a lot of time in the long run.
And if you have already been there, make sure you avoid the issue in the future by thoroughly examining each issue, regardless of its complexity, then making sure you have taken into account all the details that could screw up your initial estimate. This might sound like too much of an effort, but in time it will come natural to you, and hopefully you won't fall into the trap of underestimating the effort needed to resolve a seemingly simple issue.
Until next time, have a good one,
Romi
joi, 6 ianuarie 2011
Conways' game of life, a more natural approach
A few weeks ago, I attended a local programming event, entitled Code Retreat. The main purpose was to give coders a chance to focus on something other than designing / implementing features and meeting deadlines. The main focus of the event was the code itself. We had to code a version of Conway's game of life, but instead of actually finishing the task, we had to develop the application in pairs and follow some rules which underline Agile practices, for instance, all methods should be shorter than 8,6 or 4 (easy, medium, hard) lines, don't use cycles, don't use conditional statements, use very descriptive variable and method names etc.
I never thought just messing around with code could be so much fun. By the end of the event we have experienced multiple ways of implementing the application, and I have learned quite a bit of very handy tricks for coding. The ideas we discussed persisted in my head for many days and I wanted to have another go at implementing the application, since none of us got the chance to finish it at the event.
Here is what it looks like, the final version, because after getting the basics down (e.g. cells, universe, iterations etc.), I just added stuff to it: Life game.
Let me say a few words about the code. First thing, I used the Parsley framework to develop it, because it is perfect for quick development of Flex applications, then there are a few details that are worth mentioning, regarding the dynamics of the game.
When implementing the application, there are basically two paths you can go by: the first would be to focus on the universe - which is to say, the grid that holds the cells (its most simple form is a n x n matrix, consisting of "dead cells") - specifically, at each iteration, the grid parses all the locations and updates the cells accordingly (the living ones that don't match the conditions die, and the dead ones that do meet the conditions, come alive).
Then, the second way is to focus on the cell. Each cell holds its number of living neighbors, it has two states (alive/dead), and it can update itself. The grid just parses all cells, passes the number of living neighbors to each cell, and lets it know when to update its state.
Both of these solutions work equally well in practice, and implementing one of the two is basically a matter of preference. However, in my opinion, none of them seem to reflect the way our natural universe actually works. What I mean, is that the universe does not consist of "dead cells" that "come alive" according to some rules, and another thing, once a cell dies, it shouldn't be able to come alive again (i.e. it shouldn't be allocated in memory). The universe should just manage the living cells, then spawn new ones and finally remove dead cells forever (yeah I know, it's an oversimplification but I feel it reflects the best way of how our universe works). So instead of actually having a grid of dead cells, we just need to have a list of living cells and let them do their business. This way we balance the focus between the universe and the cell.
The next problem to solve is how to instruct the cells to multiply. Again, we can look to our universe for an answer. If we assume that a cell is aware of its own position in the universe (in this case a 2D grid), the natural thing for it to (want to) do, is to multiply in all available directions (NW, N, NE, W, E, SW, S, SE) - as a side-note, I got this idea from Richard Dawkins' book The selfish gene - because a cell shoud not "care" if it can or not multiply on a specific location, it's just "wired" to do so; the universe should "tell" the cell if it can spawn an offspring at a particular location, or not - as we are about to see. OK, now that we got that down, our application is starting to function more and more like the real universe.
Now the only problem that remains, is how to spawn new cells in the universe. Let's do a quick recap:
1. The universe consists only of the living cells.
2. Cells spawn their offspring in the adjacent locations to their position, 8 in number.
According to the game rules, a new cell is born if it has three living neighbors, which is the same as saying "a new cell is born on a particular location, if three already living cells want to spawn their offspring on that same location". This way, it's like three organisms need to "come together" in order to create new life... talk about a menage a trois :)
So this way, the universe is responsible for "telling" the cells if they are allowed to multiply or not, being according to the game rules, or within the grid limits. In fact, the cells don't even know if one of their spawn locations was used to spawn a new cell, nor should they care. And correct me if I'm wrong, but this method reflects how the universe actually works, in principle at least :). So the final flow of the application looks like this:
1. The universe consists only of the living cells.
2. Determine all the locations in which cells want to spawn their offspring.
3. The universe parses those spawn locations and looks for triplicates.
4. The universe spawns new cells on locations that can be classified as triplicates.
Feel free to check out the application here (view source enabled) and let me know what you think.
'Till next time, take care!
I never thought just messing around with code could be so much fun. By the end of the event we have experienced multiple ways of implementing the application, and I have learned quite a bit of very handy tricks for coding. The ideas we discussed persisted in my head for many days and I wanted to have another go at implementing the application, since none of us got the chance to finish it at the event.
Here is what it looks like, the final version, because after getting the basics down (e.g. cells, universe, iterations etc.), I just added stuff to it: Life game.
Let me say a few words about the code. First thing, I used the Parsley framework to develop it, because it is perfect for quick development of Flex applications, then there are a few details that are worth mentioning, regarding the dynamics of the game.
When implementing the application, there are basically two paths you can go by: the first would be to focus on the universe - which is to say, the grid that holds the cells (its most simple form is a n x n matrix, consisting of "dead cells") - specifically, at each iteration, the grid parses all the locations and updates the cells accordingly (the living ones that don't match the conditions die, and the dead ones that do meet the conditions, come alive).
Then, the second way is to focus on the cell. Each cell holds its number of living neighbors, it has two states (alive/dead), and it can update itself. The grid just parses all cells, passes the number of living neighbors to each cell, and lets it know when to update its state.
Both of these solutions work equally well in practice, and implementing one of the two is basically a matter of preference. However, in my opinion, none of them seem to reflect the way our natural universe actually works. What I mean, is that the universe does not consist of "dead cells" that "come alive" according to some rules, and another thing, once a cell dies, it shouldn't be able to come alive again (i.e. it shouldn't be allocated in memory). The universe should just manage the living cells, then spawn new ones and finally remove dead cells forever (yeah I know, it's an oversimplification but I feel it reflects the best way of how our universe works). So instead of actually having a grid of dead cells, we just need to have a list of living cells and let them do their business. This way we balance the focus between the universe and the cell.
The next problem to solve is how to instruct the cells to multiply. Again, we can look to our universe for an answer. If we assume that a cell is aware of its own position in the universe (in this case a 2D grid), the natural thing for it to (want to) do, is to multiply in all available directions (NW, N, NE, W, E, SW, S, SE) - as a side-note, I got this idea from Richard Dawkins' book The selfish gene - because a cell shoud not "care" if it can or not multiply on a specific location, it's just "wired" to do so; the universe should "tell" the cell if it can spawn an offspring at a particular location, or not - as we are about to see. OK, now that we got that down, our application is starting to function more and more like the real universe.
Now the only problem that remains, is how to spawn new cells in the universe. Let's do a quick recap:
1. The universe consists only of the living cells.
2. Cells spawn their offspring in the adjacent locations to their position, 8 in number.
According to the game rules, a new cell is born if it has three living neighbors, which is the same as saying "a new cell is born on a particular location, if three already living cells want to spawn their offspring on that same location". This way, it's like three organisms need to "come together" in order to create new life... talk about a menage a trois :)
So this way, the universe is responsible for "telling" the cells if they are allowed to multiply or not, being according to the game rules, or within the grid limits. In fact, the cells don't even know if one of their spawn locations was used to spawn a new cell, nor should they care. And correct me if I'm wrong, but this method reflects how the universe actually works, in principle at least :). So the final flow of the application looks like this:
1. The universe consists only of the living cells.
2. Determine all the locations in which cells want to spawn their offspring.
3. The universe parses those spawn locations and looks for triplicates.
4. The universe spawns new cells on locations that can be classified as triplicates.
Feel free to check out the application here (view source enabled) and let me know what you think.
'Till next time, take care!
Abonați-vă la:
Postări (Atom)