Follow treslines by email clicking Here!

Friday, December 9, 2011

Whats your code style? isBigger contest!

Whats your code style? isBigger(...) contest!

Rules

Hi there! In this blog i want to see and learn from you. Post a), b), c) and so to show us how you code and why. Share your expirience with us. You may type/post your own solution if it isn't here. The goal of this post is to figure out the best code snippet to solve a specific, concrete problem as clean as you can and to share it with the world. 

The Task

Tell us how you would resolve spontaneously following current task:
how would you write a method that checks if one value is greater than the other? 

Solution A)

boolean isBigger( int a, int b){  boolean result=false;  if(a>b){   result=true; } return result; }

Solution B)


boolean isBigger( int a, int b){ 
 if(a>b){
  return true;
}
return false;
}

Solution C)


boolean isBigger( int a, int b){ 
 return a>b? true: false;
}

Solution D)


boolean isBigger( int a, int b){ 
 return a>b;
}

Solution E)


boolean isBigger( int a, int b){ 
 return Integer.valueOf(a).compareTo(Integer.valueOf(b)) <0;
}



Solution F)


interface compare<T>{
 boolean isBigger(T a, T b);
}



Solution G)


<T> boolean isBigger( T a, T b){ 
 return a > b;
}



Solution H)


boolean isLeftValueBiggerThanRightValue ( int leftValue, int rightValue){ 
  return leftValue > rightValue && leftValue != rightValue;
}



Solution I)



<T> boolean isBigger( T value1, T value2){ 
 final int equal = 0;
 return T.valueOf(value1).compareTo(T.valueOf(value2)) > equal;
}


Solution J)


you may post your own solution... Post you comment at the end of this blog!

How can i motivate other developers ?

Well i do that by talking about, i wear my treslines.com t-shirt, i wear my bracelets with the CCD (Clean Code Developer Initials and colors) and i use my brand new treslines bag. It feels fantastic and even on the train people start talking to me asking about it. It is also a great idea to motivate agile teams and to share your expirience. You may want a great gift to show your appreciation to your team. Surprise them with a gadget from www.treslines.com. I love it.

Other interesting blogs

How could we improve the quality of this article ?

If the content of this article does not help you, so please tell us how to improve the quality of it by giving your contructive feedbacks at the end of this blog. If it was useful to you giving and resuming to you the most important aspects of the subject treated, saving you a lot of time, then help us to maintain this blog with a little appreciation. With a small amount of your choice you help us to cover the prime costs like:
Hosting, autors’s research work, editorial work, blog quality, motivation to make things better than others resulting in a very useful information pool for you and a lot of other developers. Important : If you do not have the possibility to donate a little amount, than recommend this page to your friends. Thanks !





Source code convention tools

Literature, good books and references

How can i subscribe/feed this blog ?

Subscribe : click on the link at the end of this blog

Want to stay up to date ?


How can i rate this blog ?

Press google+1 once !

Where do i find more clean code knowledge and gadgets?

 

Tuesday, September 6, 2011

Clean code theory in English


Clean code theory in English
Table of contents

Clean Code Theory
What do the colors mean ?
When do i change from one color to another ?
What does red, orange, yellow, green and blue mean ?
How can i motivate other developers ?
How could we improve the quality of this article ?
Source code convention tools
Literature, good books and references
How can i subscribe/feed this blog ?
Want to stay up to date ?
How can i rate this blog ?
Where do i find more clean code knowledge and gadgets?

Clean Code Theory

Hi there! Inspired by the geman website www.clean-code-developer.de i have lauched the treslines.com initiative with the aim to make it also popular to the english speakers. In this blog i wanna make you familiar with the basic colors of the clean code initiative and its meaning.

What do the colors mean ?

Well, In the initiative there are 7 rotational degrees. It starts from black, thru red, orange, yellow, green, blue till white. Black means only that you are interested in learn more about it and are preparing yourself to get started. Personally, i do not thing that we nescessarily need this degree. It says only that you are interested in it. www.treslines.com offers gadgets to support the iniciative. There you’ll never find the colors black and white. The white degree means that the developer are working with a huge openminded horizont. Instead of wearing the white degree, the developer should turn back to the first degree and start it from the beginning again. Thats the reason we say ratational degrees.

When do i change from one color to another ?

Well, thats up to you. I recommend a period of 1-2 month each degree.

What does red, orange, yellow, green and blue mean ?

These are interesting degrees. In it we will find always design principles to apply and best practises to use. Check www.treslines.com for gadgets and know how about clean code as well agile development.

 
Principles
1. Don't Repeat Yourself (DRY)
2. Keep It Simple, Stupid (KISS)
3. Favor Composition over Inheritance (FCoI)
4. Beware of Optimisations (BoO)
Practises
1. Scouts rules
2. Root Cause Analysis
3. Version Control
4. Simple Refactoring
5. Daily Reflection of your Work

 
Principles
1. Single Level of Abstraction (SLA)
2. Single Responsability Principle (SRP)
3. Separation of Concerns (SoC)
4. Source Code Conventions
Practises
1. Issue Tracking
2. Auto Integration Tests
3. Read, read, read
4. Reviews
  
Principles
1. Interface Segregation Principle (ISP)
2. Dependency Invertion Principle (DIP)
3. Liskov Substitution Principle (LSP)
4. Principle of Least Astonishment (PoLA)
5. Information Hiding Principle (IHP)
Practises
1. Auto Unit Tests
2. Mockups
3. Code Coverage Analyse
4. Participation in professional events
5. Complex Refactoring


Principles
1. Open Close Principle (OCP)
2. Tell don't ask
3. Law of Demeter (LoD)
Practises
1. Continuous Integration I
2. Static Code Analysis
3. Inversion of Control Container
4. Expirience  sharing
5. Measure of Errors

Principles
1. Design & Implementation do not overlap (no inconsistency)
2. Implementation reflects design
3. You Ain't Gonna Need It (YAGNI)
Practises
1. Continuous Integration II
2. Iterative development
3. Component orientation (package structure)
4. Test First

How can i motivate other developers ?

Well i do that by talking about, i wear my treslines.com t-shirt, i wear my bracelets with the CCD (Clean Code Developer Initials and colors) and i use my brand new treslines bag. It feels fantastic and even on the train people start talking to me asking about it. It is also a great idea to motivate agile teams and to share your expirience. You may want a great gift to show your appreciation to your team. Surprise them with a gadget from www.treslines.com. I love it.

Other interesting blogs

How could we improve the quality of this article ?

If the content of this article does not help you, so please tell us how to improve the quality of it by giving your contructive feedbacks at the end of this blog. If it was useful to you giving and resuming to you the most important aspects of the subject treated, saving you a lot of time, then help us to maintain this blog with a little appreciation. With a small amount of your choice you help us to cover the prime costs like:
Hosting, autors’s research work, editorial work, blog quality, motivation to make things better than others resulting in a very useful information pool for you and a lot of other developers. Important : If you do not have the possibility to donate a little amount, than recommend this page to your friends. Thanks !





Source code convention tools

Literature, good books and references

How can i subscribe/feed this blog ?

Subscribe : click on the link at the end of this blog

Want to stay up to date ?


How can i rate this blog ?

Press google+1 once !

Where do i find more clean code knowledge and gadgets?

 

Friday, September 2, 2011

What are the contraindications for agile projects? (checklist)


What are the contraindications for agile projects?
Table of contents

What are the contraindications for agile projects? (checklist)
When are agile methods suitable ?
How could we improve the quality of this article ?
Source code convention tools
Literature, good books and references
How can i subscribe/feed this blog ?
Want to stay up to date ?
How can i rate this blog ?
Where do i find more clean code knowledge and gadgets?

What are the contraindications for agile projects? (checklist)

When are agile methods suitable ?


Agiler Background:
The agile approach is not always the best solution. There are work environment or circumstances that militate against the agile approach. Below are the contra-indicators to observe and evaluate:.


Agile Contraindicators:
These are the criteria, which does not speak for the agile approach. In this case, other approaches shall be favored.

                Contraindications Customer
o  The project goal is not SMART. The goal is not clear. (specific, measurable, appropriate, relevant, terminated)
o  process is defined and regulated. (e.g. by Authority or Law)
o  Nice-To-Have-projects. If the pressure required is missing or it has no great significance for the organization. (No pressure = no result value)
o  Customer’s decision takes a long time. When agile process, the feedback is an important element. The absence of this element, makes the project to fail.
o  Lengthy change request process. These are formalized change process. The project stays still.
o  No user or customer contact. Projects without user or costumer contact are difficult to perform agile.
o  customer does not control the outputs. The customer must take care of the project. At least 50% of the time available shall be invested, otherwise the above-mentioned problems will arrive.
o  creation of life critical software. If the meaning of provability is higher than the agile approach.
o  fear of responsibility. If errors are not seen as an opportunity to learn, but interpreted as misconduct charge.
o  Client does not support the agile approach. To customer needs to come and play its role in the feedback activity.
o  No work on site possible. For agile methods is the close cooperation with customers and users very important.
o  fixed price projects - in such cases, consider whether or not feature driven development would be appropriate. It comes from fixed-price combinations.
o  Client is an authority - If the Customer is an authority, most of the decision paths takes to long, fixed price, a given process, i.e. a collection of some contraindications.

Contraindications Developers
o  No experience with agile projects, and no coach available.
o  unwillingness or inability to learn. Agile software development is a learning process.
o  culture of command and obedience - in a strictly hierarchical culture that grants the instructions almost like commands, each devbeloper is controlled so that any error is found for a guilty person, are not suitable for the application of agile methods.
o  If developers do not want user contact - then it is hardly possible to apply agile methods.
o  High developer fluctuation which is not good for the team
o  Developer does not accept to work on site if needed or possible.
o  No management commitment to an agile method - without it is not possible.

Contraindication Technology
o  Long build time

Agile Tip!
Book tip: Agile software development, values, concepts, methods of Wolf-Gideon Bleek - Henning Wolf-Morgan Kaufmann Publishers, - ISBN: 978-3-89864-473-0


How could we improve the quality of this article ?

If the content of this article does not help you, so please tell us how to improve the quality of it by giving your contructive feedbacks at the end of this blog. If it was useful to you giving and resuming to you the most important aspects of the subject treated, saving you a lot of time, then help us to maintain this blog with a little appreciation. With a small amount of your choice you help us to cover the prime costs like:
Hosting, autors’s research work, editorial work, blog quality, motivation to make things better than others resulting in a very useful information pool for you and a lot of other developers. Important : If you do not have the possibility to donate a little amount, than recommend this page to your friends. Thanks !





Source code convention tools

Literature, good books and references

How can i subscribe/feed this blog ?

Subscribe : click on the link at the end of this blog.

Want to stay up to date ?

Follow : @algoritmo4j

How can i rate this blog ?

Press google+1 once !

Where do i find more clean code knowledge and gadgets?


Monday, August 29, 2011

Why do you need a valuable system documentation?

Why do you need a valuable system documentation ?
Table of contents

How to write valuable system documentation with agile principles ?
How can i figure out if my documentation is valuable ?
How does the structure of a good documentation looks like?
Why do you need the system-documentation in this sequence?
How can i optimize my system documentation?
Don’t i need process documentation?
How can i avoid redundant documentation?
How could we improve the quality of this article ?
Source code convention tools
Literature, good books and references
How can i subscribe/feed this blog ?
Want to stay up to date ?
How can i rate this blog ?
Where do i find more clean code knowledge and gadgets?

How to write valuable system documentation with agile principles ?

Hi there! In this blog i wanna show you, why agile concepts need a valueable documentation and why to many developers missunderstand the agile manifest. You’ll see and understand how to structure the documentation, to figure out a good, valuable documentation saving a lot of time. This blog will give you some tequiniques and methods and best practices making your company more profittable as you always has dreamed of it. Share this expirience with other developers.

How can i figure out if my documentation is valuable ?

Well, to understand that, we must find out what is essencial needed and why! To do so before writting any documentation ask yourself those valuable questions:



Document purpose : Why do i really need this documentation ?

Documentation sort : How does the minimally systematic looks like ?



If you can’t aswer those questions, do not spend a lot of time writing something that nobody will read. We only write documentation if it brings an additional benefit.



Important: If it is possible to solve or clear something over conversation, favor this way over writing documentation.

How does the structure of a good documentation looks like?

Well first of all we must know, what kind of documentation a software really needs and how to differentiate between system-documentation and stakeholder-documentation.



A system-documentation looks normally like this acc. to the best practises :



·         Architecture overview (maintenance, build deployement, development)

·         Interface handbook (for external partners)

·         Operating handbook (for operation, installation etc.)

·         Admin handbook (for context administration)

·         Support handbook (after delivery and only if needed)



This was a template. To be sure you have covered the needs of your stakeholders show it to them and ask for feedbaks. It is always better to make pro-active a proposal because otherwise the stakeholders could say: i need it all or everything is nescessary.

Why do you need the system-documentation in this sequence?

Well thats a good and very important question, because here you get the reasons why it tis essencial to have it.


We can expect that the maintenance and support/service phase is avarage 3 times bigger than the construction phase. In agile contexts even much bigger because of the short delivery cycles. The system-documentation you need exactly for this phase. (For the life cycle after delivery). For this reason the system-documentation must document mainly all information you need to maintain and support the system without asking developers or getting know-how from experts, that may no longer work in the company.


Construction vs Maintenance (3-5 times bigger)

|__________|__________|__________|__________|__________|__________|

How can i optimize my system documentation?

Well the principle here is not what ist possible, but what is really nescessary. Project-documentation is not a system-documentation. Favor the direct conversation with the stakeholders and ask them what they really need and why. The system-documentation contains in most of the cases all information needed.


The only reasons to write project documentation are :


·         Big projects : If the direct project communication is not possible.

·         High risk : to control risks. Usually medical projects and projects for the state.

·         Law requirements : the law requires it.

Don’t i need process documentation?

Good question. Sure! Process documentation is an internal and structural documentation. The most companies has it already, since they are ISO-Certified. This kind of documentation defines rules, process, concepts, models, project plan, meetings etc. If your company does not have an established process documentation you should do ti now ! Don’t think you can live without it. This is only true if your company has 3-5 employees.

How can i avoid redundant documentation?

Example : You do not have to write additional documentation if the information is normally only available for developers. Cookbooks, Source code, JavaDoc etc. describe and help developers enough. Do not spend time, documenting those things. Developers will do it automatically, if they need. Instead you should insist on a cookbook by developers. (developers should do that at a minimum to ensure know-how-transfer)

How could we improve the quality of this article ?

If the content of this article does not help you, so please tell us how to improve the quality of it by giving your contructive feedbacks at the end of this blog. If it was useful to you giving and resuming to you the most important aspects of the subject treated, saving you a lot of time, then help us to maintain this blog with a little appreciation. With a small amount of your choice you help us to cover the prime costs like:


Hosting, autors’s research work, editorial work, blog quality, motivation to make things better than others resulting in a very useful information pool for you and a lot of other developers.

Important : If you do not have the possibility to donate a little amount, than recommend this page to your friends. Thanks !






Source code convention tools

Literature, good books and references

How can i subscribe/feed this blog ?

Click on the link at the end of this blog.

Want to stay up to date ?

bookmark: www.treslines.com or follow :  @algoritmo4j

How can i rate this blog ?

Press google+1 once !

Where do i find more clean code knowledge and gadgets?