Make Hay while the Sun shines, and follow the sun....

Facebook Stetho debugging tool

http://thenextweb.com/facebook/2015/02/18/facebook-releases-stetho-powerful-debugging-tool-android/

Http/2 - first major update in 16 years

http://thenextweb.com/insider/2015/02/18/http2-first-major-update-http-sixteen-years-finalized/

ITIL - Relationship between Incident Management, Problem Management and Change Management...

This is a published article from ComputerEconomics.com by Robert Boyd. 

The article source is here: http://www.computereconomics.com/article.cfm?id=1074

I reproduce a part of it below. 

• At TIME = 0, an External Event is detected by the Incident Management process. This could be as simple as a customer calling to say that service is unavailable or it could be an automated alert from a system monitoring device.
        
  The incident owner logs and classifies this as incident i2. Then, the incident owner tries to match i2 to known errors, work-arounds, or temporary fixes, but cannot find a match in the database.
   
• At TIME = 1, the incident owner dispatches a problem request to the Problem Management process anticipating a work-around, temporary fix, or other assistance. In doing so, the incident owner has prompted the creation of Problem p2.
   
• At TIME = 2, the problem owner of p2 returns the expected temporary fix to the incident owner of i2.  Note that both i2 and p2 are active and exist simultaneously. The incident owner for i2 applies the temporary fix.
   
• In this case, the work-around requires a change request.  So, at Time = 3, the incident owner for i2 initiates change request, c2. 
• The change request c2 is applied successfully, and at TIME = 4, c2 is closed. Note that for a while i2, p2 and c2 all exist simultaneously.
   
• Because c2 was successful, the incident owner for i2 can now confirm that the incident is resolved. At TIME = 5, i2 is closed. However, p2 remains active while the problem owner searches for a permanent fix. The problem owner for p2 would be responsible for implementing the permanent fix and initiating any necessary change requests.       

Code Smell

A code smell is an indication of the presence of an underlying problem within a software code. It could indicate a problem with s/w design, or architecture. Code smells are symptomatic of a system bottleneck that prevents / limits the development of s/w or increases the likelihood of a s/w failure.

 

- Code Smell

- Design Smell

- Architecture Smell

 

Common Code Smells (Wikipedia)

1. Duplicated code: identical or very similar code exists in more than one location.
2. Long method: a method, function, or procedure that has grown too large.
3. Large class: a class that has grown too large. See God object.
4. Too many parameters: a long list of parameters is hard to read, and makes calling and testing the function complicated. It may indicate that the purpose of the function is ill-conceived and that the code should be refactored so responsibility is assigned in a more clean-cut way.
5. Feature envy: a class that uses methods of another class excessively.
6. Inappropriate intimacy: a class that has dependencies on implementation details of another class.
7. Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See Liskov substitution principle.
8. Lazy class / Freeloader: a class that does too little.
9. Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice.
10. Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.
11. Excessively short identifiers: the name of a variable should reflect its function unless the function is obvious.
12. Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions.
13. Ubercallback: a callback that is trying to do everything
14. Cyclomatic complexity: too many branches or loops; this may indicate a function needs to be broken up into smaller functions, or that it has potential for simplification