For some years I am asking myself what is a good developer?
Maybe a better question is what are the knowledges need to be a good developer?
Here is what I consider need to be a good developer:
- strong OOD & OOA - apply them in all the code that is written. There is no GOOD reason to produce bad quality
- strong knowledge of the programming language used in projects
- respect for written code and for application(do not crash the entire design and principles ONLY because a pushy client wants the code ready yesterday)
- understand the whole architecture applied into the project
- learn new techs, principles day by day .... do not wait for someone to tell you what you should learn ...
- ability to clarify the requirements for the assigned tasks
- ability to estimate the tasks
- ability to keep the deadline
- ability to organize his tasks considering the dependencies of other's tasks
- ability to manage the communication with the client
- the guts to say NO
- teamplayer
- know what should be asked ... not to much dummy-questions to overkill the communication, but enough questions to clarify a situation
- direct communication - keep all the unclarities up-front, do not hide them. Say what is wrong when you see it, even if this is hard to be accepted by the person which you are in dialog
- accept criticisms, accept failures -- nobody is perfect
More to come ...
Saturday, March 17, 2007
Saturday, March 10, 2007
Unify the UI frameworks
On Java community there are a lot of options to be chosen when you want to start implementing an application that has a UI.
Depending on the type of the client you can choose frameworks like:
For web clients:
- struts 1.x, 2.0
- tapestry
- MyFaces
- Ajax based one: GWT, RAP
etc.
For desktop clients:
- Swing
- Eclipse RCP
etc.
There so many doing basically the same things but using different approaches.
When you want to implement an application having clients which use the application from:
- web
- mobile phones
- desktop
then you are in big trouble.
Which are your options:
- decide for each client the framework to be used
- do 3 times the same client UI using 3 frameworks ...
Pretty good right? And also "extremely efficient" ;(.
I have some questions:
- why should we have 3 different implementations?
- is the UI so different depending on the client type?
I think that answering to the second one, I have the answer for the first one :(.
From the development point of view, it should be only one implementation of the View which is used by the client, the differences are given by the implementation of the view using the capabilities of the client UI.
Let's see what I want from a client UI:
- using some UI controls to display the information to user, and to collect the interaction of the user
- combining these UI controls to have complex views
Here is my proposal"let's abstract more the UI and define a framework having the following characteristics" :
- define a standard collection of the UI controls(e.g: window, buttons, checkboxes, etc)
- collect the user actions into a Event based manner
- assure a good performance
- native support for MVC
Additionally:
- provide addapters of these abstract framework for:
- desktop clients
- web clients
- mobile clients
Having all of these we get the following:
- reduce the pain of implementing the UI for different types of clients
- reduce the leaning effort
Am I right, or I just start a discussion about another useless Java framework :(?
Depending on the type of the client you can choose frameworks like:
For web clients:
- struts 1.x, 2.0
- tapestry
- MyFaces
- Ajax based one: GWT, RAP
etc.
For desktop clients:
- Swing
- Eclipse RCP
etc.
There so many doing basically the same things but using different approaches.
When you want to implement an application having clients which use the application from:
- web
- mobile phones
- desktop
then you are in big trouble.
Which are your options:
- decide for each client the framework to be used
- do 3 times the same client UI using 3 frameworks ...
Pretty good right? And also "extremely efficient" ;(.
I have some questions:
- why should we have 3 different implementations?
- is the UI so different depending on the client type?
I think that answering to the second one, I have the answer for the first one :(.
From the development point of view, it should be only one implementation of the View which is used by the client, the differences are given by the implementation of the view using the capabilities of the client UI.
Let's see what I want from a client UI:
- using some UI controls to display the information to user, and to collect the interaction of the user
- combining these UI controls to have complex views
Here is my proposal"let's abstract more the UI and define a framework having the following characteristics" :
- define a standard collection of the UI controls(e.g: window, buttons, checkboxes, etc)
- collect the user actions into a Event based manner
- assure a good performance
- native support for MVC
Additionally:
- provide addapters of these abstract framework for:
- desktop clients
- web clients
- mobile clients
Having all of these we get the following:
- reduce the pain of implementing the UI for different types of clients
- reduce the leaning effort
Am I right, or I just start a discussion about another useless Java framework :(?
Why blogging?
I was wondering why a lot of people keep blogs.
Here are some possible answers:
- experience the writing skills
- express thoughts
- fun
- just being cool
I think I will do it for the first 3 reasons.
I am a little bit upset because my preferred names are taken by someone else. :(
I am going to post on my blog thoughts about:
- technologies
- life
Here are some possible answers:
- experience the writing skills
- express thoughts
- fun
- just being cool
I think I will do it for the first 3 reasons.
I am a little bit upset because my preferred names are taken by someone else. :(
I am going to post on my blog thoughts about:
- technologies
- life
Subscribe to:
Posts (Atom)