From the code review I learned how difficult it can be working with a third party application. Say you have set up an application with a design that fits it nicely, and a flow that suites all of your needs. Then, suddenly your customer wants you to use an unanticipated third party program or web service in your application. Even if you have a nicely organized, highly decoupled and flexible program, implementing a third party into the mix can be quite a challenge.
The first challenge would of course be understanding how this third party program works. This might be reasonable, but your employer wants you to start implementing it NOW. So you start writing code, rather guessing how it works, and within less time than you might think, you get a bit of a mess. The more you incorporate the third party app, the more you learn about it, and the more you realize that you were wrong when you started working with it. Yet, you can't just go back and try again because your customer is expecting functionality and isn't all that pleased when you tell him/her that you have to take it away.
Another issue is that you might be fitting a square block into a round hole. You have this pretty design that you are extremely pleased with, and suddenly you have to find a way to jam some ugliness into it. Not saying all third party apps are ugly, but it seems like thats how they always appear when you first realize you have to fit it in with your design. Of course, you can't suddenly redesign your entire program just to work with this third party app, because your customer would freak. Instead you have to use some hodge-podge means to link everything together. If your not super careful, which is extremely difficult but always easy in hindsight, you will wind up with a mess.
The way Micah and I did the estimating was pretty interesting, and made a lot of sense. He set up a table with the features - an optimistic - a realistic - and a pessimistic estimate of how long the each feature would take. Then he calculated the standard deviation for each feature, and for the project as a whole. This gave us a pretty big range for how long this project might take, which I believe is necessary since it is virtually impossible to accurately estimate a fair sized project before you even get started.
From the talk and after:
* Mix-in: A way to add functionality to a class or instance by making a new class or module which isn't meant to be instantiated. In Ruby, you can do this by creating a module with some concrete methods, and then extend from this module in some other class.
* Comet: This is a HTTP means to maintain a long held link between a server and a browser. Typically HTTP sends a request, waits for a response, then sends data. This is a very tedious process, and doesn't fit all models. Using Comet allows the server to keep an open connection and send data without receiving any reply. Systems similar to Google Wave, with live updates, would use something like comet.
* Actors: An actor is actually a mathematical model for performing parallel or concurrent computation. When using the model, everything is an actor. Actors don't run sequentially or in a particular order, but run simultaneously. Actors can send messages to one another, create new actors, and perform some specific actions. Since everything is an actor, there is no supreme controller, thus actors can only talk to actors they know about. One of the biggest advantages to the Actor Model is that it separates the sender from sent communications.
- Supervised Actors: This is an Actor Model, but with a supervisor for each actor that can monitor its activity. The main purpose I gathered from the supervisor, is that if the actor is destroyed for whatever reason, the supervisor can see this and restart the actor.
* Cake Pattern: The Cake Pattern is a way to implement Dependency Injection, largely in Scala.
No comments:
Post a Comment