One of the things I love about Flex is how extensible it can be. You are able to make composite components to do almost anything you want using out of the box components. However, if you really want to take advantage of its power, it helps to have a good or in depth knowing of the interfaces that come with it. The reason to proclaim the importance is that using these interfaces, you will be able to create extremely light weight components, but you will be able to make them do whatever you want (in a programming sense of the phrase).
There are, of course, quite a few different interfaces. I have looked through them and picked out five interfaces that I consider to be the more important ones. For each, I will give a brief explanation of why they are important and where you would normally use them.
Best Practices, Flex, Learn This
As mentioned in a previous article, one thing I like to do when giving interviews is throwing out a curve ball. A standard type of questions I like to ask about are design patterns. Normally I will ask them to describe a specific pattern and seeing that both Strategy patterns and Decorator patterns are pretty common, I will ask about those. Most of the time, they can answer at least one of those. Whenever they answer both, I like to throw in the ‘Describe the difference between them and when you would use them.’
I ask this normally because it is kind of a gray area. Well maybe gray area isn’t the correct phrase, but they are strikingly similar*. They both encapsulate and delegate the behavior of the classes. They both encourage composition. Both are great alternatives to inheritance. And they both allow for new behaviors to be easily added to existing classes. With all the similarities, its hard to see where they differ, making it a great question to ask in an interview.
Best Practices, Design Patterns, Learn This, Opinion, tutorial
Everyone dealt with it in some form of another. Either you have given your estimations and you missed it by a long shot or someone handed you some estimations and they grossly underestimated the amount of work. And when that mark is missed, its the wag of the finger and the rain cloud of shame upon you. Management has deemed you a failure. Way to go.
But why does it happen as often? Are they the same constant hurdles over and over? Is it management? Lack of tools? Bad team? Or dare I say, was it you? (Of course not, its never OUR fault). Who are making the estimations? Is it you? Your team leader? Marketing? Upper management? For me, I can see mostly from the developers point of view because, hey, I am not a manager. Here are some of the issues I have ran into over the various projects and possible ways to avoid them in the future.
Best Practices, Opinion
Recently at work, I was approached by my boss and was tasked with estimating how long it would take to fix a list of bugs. I accepted and said I would have the estimation come end of day. Then I found out which project this was for. It was *THE* project. Every company has this project. It’s the project that no one likes working on. The codebase is horrible, poorly designed and could be described as brittle at best. The problem isn’t just the code looks bad, it is just that to fix a bug in here causes a rippling effect through out program.
Instead of offering a time estimation, my manager got something pretty much every manager hates to get. She got a list of what needs to be rebuilt and how long it should take. Almost everywhere you read, they say rebuilding an application should never happen. I can agree with this to a point. When developers use that word “rebuild”, they often use it like a child who just found their father’s gun in the closet. It can be dangerous and not treating this with careful planning and consideration, you will be rebuilding yourself right into a corner.
Best Practices, Opinion, Random Notes
This is a new series that I will be starting, called “Don’t do this”. Basically it is a spin on another series I started called “Learn this”, but it is more of an observation of things that I have had to learn a lesson from.
In this article, I want to discuss the dangers of allowing junior developers to “cowboy code“, or do whatever they feel is right. The junior programmer does not know what “right” is, or better yet, has not shown you what right is. A lot of people might think this is common sense, but it isn’t. I have seen it too many times and lately I have been trying to become more aware of it. Ignoring this is not only bad for the code base, but it is bad for you, the client and the actual junior employee.
Best Practices, Don't do this, Opinion