coder . cl

Scrum is a well known — is it really well known? — agile methodology. It consist on building a project with small iterations on done work and periodic reporting of advances. It is widely used since you can track easily how the project is going and detect problems on early stages. It is not very linked to software modelling and design, instead it uses another kind of construction methods. You can use various kinds of iteration types, depending on how dynamically can you handle the requirements and how indecisive is the customer. You can use iterative, incremental and evolutionary types of iterations, from the greatest to the smallest one. Iterative and incremental handles requirements formally, and evolutionary is more like a kind of craftsmanship, requiring the customer to be very present on the development process.

The past July 19, I’ve made a talk on the Dynamic Languages meet-up explaining some basics of functional programming. The presentation has two parts, the theoretical one, with the proper presentation and the second one with code examples. For the code examples I’ve used Lisp, Haskell and Python, with homologous functions, each one implemented on each used language, to ensure that are concepts were handled.

Being practical in programming is hard. You need to be precise and concentrate enough to build working, well done and elegant solutions at once. Each time you handle a project, it has an assigned time to be developed, so you cannot be very strict and use the most elegant ways to solve certain problems. Is very different to deliver software as is, tested software and verified software. Those are different approaches, and the harder one is to deliver verified software, and probably you will never get enough time to deliver verified software if you work for a company that offers development services.

As you know, when you are working with agile methods, mainly with the Scrum, you need to assign two important metrics on sprint planning. The time estimates and the story points, and both are used to size the software project. Both are separate metrics, a user story with a large size can take less time than lightweight stories. Probably the fault on story points is the fact that they are arbitrary, so I have created a simple spreadsheet to help me on estimates and story-point metrics.

ManyMoon is a very nice project management tool, it provides the proper integration with Google Apps, this means that you can organize your project using the ManyMoon application itself, assigning tasks, tracking time spent and sharing documents through Google Docs. It provides reports about completed tasks, work assignment and costs if time is set to billable. It also provides integration with Google Calendar, so milestones and events are shared through Google Calendar as calendar events. It also provides integration with Google Tasks for the ToDo items. The most important feature, is the simple interface, and it is free.

Everyone that works as software developer has faced the same situation when a software project begins to bring you more than one headache. Sometimes is hard to maintain the motivation while you are developing a software project. The customer do not brings you a clear idea of what does he wants, and you begin to hate reimplementing the same stuff more than one time. Fortunately currently I work with very professional people that is capable to bring me very detailed specs about software projects, and do not happened to me in a long time — at least in two years.

The well known jQuery framework has various methods to handle browser events. All of them differences. The major difference between event handlers, is the timeline where they handle the catched event. For example the bind() method does an event handling according to the page lifetime, but it cannot handle events from dynamically created widgets. The same happens with the one() method, it handles the event just one time, but it does for those widgets that are created from the page and not dynamic content.