Roll the Bones

Por que a pessoa é descuidada?

O pensador pensa seus pensamento através do hábito, da repetição, da cópia, o que gera ignorância e sofrimento. O hábito não é descuido? Vigilância cria ordem, mas não cria hábito. Tendências estabelecidas só geram descuido. Por que a pessoa é descuidada? Porque pensar é doloroso, cria perturbações, traz oposição, pode fazer as ações da pessoa irem contra o padrão estabelecido. Pensar-sentir amplamente, tornar-se vigilante sem escolha pode levar a profundezas desconhecidas, e a mente se rebela contra o desconhecido; assim ela vai do conhecido para o conhecido, do hábito para o hábito, de padrão para padrão. Tal mente nunca abandona o conhecido para descobrir o desconhecido. Percebendo a dor do pensamento, o pensador se torna descuidado através da cópia, do hábito; tendo medo de pensar, ele cria padrões de descuido. Como o pensador tem medo, suas ações nascem do medo, e ele considera suas ações e tenta mudá-las. O pensador tem medo de suas próprias criações; mas a ação é o autor, então o pensador tem medo de si mesmo. O pensador é o medo em si mesmo; o pensador é a causa da ignorância, do sofrimento. O pensador pode se dividir em muitas categorias de pensamento, mas o pensamento é ainda o pensador. O pensador e seus esforços para ser, para se tornar, são a própria causa do conflito e da confusão. - Krishnamurti, J. Krishnamurti, The Book of Life

Journey from a Mission and Vision to Performance Measures that Work

Mama Said

Mama, she has taught me well
Told me when I was young
"Son, your life's an open book
Don't close it 'fore its done"
"The brightest flame burns quickest"
That's what I heard her say
A son's heart's owned to mother
But I must find my way

How to troubleshoot a slow running query in SQL Server

 “ I have a slow running query , what steps can I take to speed up the query and achieve an optimised execution plan?” .

Troubleshooting database server performance is an in-depth topic. A methodical  and repeatable approach solving the root cause is the perfect situation for any DBA.   There are different approaches to SQL Server Tuning. In reality , the root cause may not be a SQL query issue , it may be SAN  , SQL Server configuration issue or workload has suddenly increased.

But of course, you’re under pressure and the query is causing  delays for the end users.The steps below expand on earlier post :SQL Server Rapid Tuning, providing a very simple emergency approach.

The steps below are a straightforward approach to troubleshooting sub optimal SQL Execution Plans. Follow the steps and repeat as necessary.

Step 1)       Statistics – Is Auto Create and Update Statistics Enabled? If Auto Create statistics is disabled , this may indicate out of date statistics. If Disabled, than proceed to  Update Statistics – use sp_updatestats to update all statistics on the database. Run the query and check if any improvement.

Step 2)       If  Auto Create and Update Statistics is Enabled, Identify the longest running queriesor highest impact queries .( If the queries have high CPU usage go to step 6). Long duration and highest IO should be a priority.

Step 3)       Place every query in the SSMS and analyse the execution plan. First – check for tables or index scans.  If large table \ index scans are occurring – progress with Query Analysis.  The Query Analysis should ask questions such as : Are all JOINS valid ? Are the JOINS returning excessive data ? Search argument validity?   Functions in predicate? 

Step 4)       If no table or index scans exist and  the query is complex , for example a large transaction managing a booking process –  check for : excessive joins, temp tables, DDL changes,sub – queries , no set based approach to writing the queries. Review  the query ,  break it down into smaller parts or analyse the JOINS to invoke a new execution plan , ensuring a similar transaction integrity is retained

Step 5)       If the query is simple and no no index \table scans exists and executing in  SSMS responds with acceptable  performance - analyse the Application and how it processes the resultset.   Ask the right question a) are just relevant results returned?  Talk to the application developers.

Step  6)       If the query is no faster in SSMS , more complex query tuning is required,  research other methods or contact a performance tuning expert

Step 7)       If in Step  2 you identified queries  with high CPU usage , analyse in SSMS for Hash Joins, Sorts, Filters.  If any of these exists , progress with Query Analysis.

Step 8)       Repeat until the problem disappears.

Como apresentar seus dados em gráficos e tabelas

Types of Concurrency Control

When many people attempt to modify data in a database at the same time, a system of controls must be implemented so that modifications made by one person do not adversely affect those of another person. This is called concurrency control.

Concurrency control theory has two classifications for the methods of instituting concurrency control:

• Pessimistic concurrency control
  A system of locks prevents users from modifying data in a way that affects other users. After a user performs an action that causes a lock to be applied, other users cannot perform actions that would conflict with the lock until the owner releases it. This is called pessimistic control because it is mainly used in environments where there is high contention for data, where the cost of protecting data with locks is less than the cost of rolling back transactions if concurrency conflicts occur.
• Optimistic concurrency control
  In optimistic concurrency control, users do not lock data when they read it. When a user updates data, the system checks to see if another user changed the data after it was read. If another user updated the data, an error is raised. Typically, the user receiving the error rolls back the transaction and starts over. This is called optimistic because it is mainly used in environments where there is low contention for data, and where the cost of occasionally rolling back a transaction is lower than the cost of locking data when read.

Probabilidades

Seven Characteristics of Key Performance Indicators

1. Nonfinancial measures (not expressed in dollars, yen, pounds, euros, etc.)
2. Measured frequently (e.g., daily or 24/7)
3. Acted on by the CEO and senior management team
4. Understanding of the measure and the corrective action required by all staff
5. Ties responsibility to the individual or team
6. Significant impact (e.g., affects most of the core critical success factors [CSFs] and more than one BSC perspective)
7. Positive impact (e.g., affects all other performance measures in a positive way)

What does the architect do? How is an architect different from a senior developer?

These are some of the common questions that get asked over and over again in the industry. We will explain, from the exam developer’s point of view, these questions so you have that common understanding when taking the exam.

"The designer is concerned with what happens when a user presses a button, and the architect is concerned with what happens when ten thousand users press a button."

How to play the guitar

Teoria dos Jogos: O que é Teoria dos Jogos

O que é Teoria dos Jogos e como ela pode melhorar as suas decisões estratégicas? Teoria dos Jogos é o estudo das tomadas de decisões entre indivíduos quando o resultado de cada um depende das decisões dos outros, numa interdependência similar a um jogo.

Mas primeiro é interessante explicar o que não é Teoria dos Jogos: decidir qual carro comprar, por exemplo. Escolher um automóvel é uma decisão complexa pela quantidade de variáveis a considerar. Além do preço, existem a aparência, estilo, tamanho, motor, conforto, acessórios, etc. Para complicar, sempre há um trade-off: nenhum carro possui exatamente todas as características que você gostou. Seria bom se o carro A, como aqueles acessórios, também tivesse a configuração do motor do carro B. Você pode criar um algoritmo (mental ou via computador) para colocar todas as variáveis e pesos de importância (suas utilidades) e criar um ranking. Entretanto, o exemplo do carro é uma decisão isolada - a decisão é só sua e não há interferência de outros no resultado.



Já a Teoria dos Jogos estuda cenários onde existem vários interessados em otimizar os próprios ganhos, as vezes em conflito entre si. Por exemplo, imagine que em sua empresa você tem dúvidas sobre qual ação tomar para aumentar o seu lucro: reduzir o preço, lançar outro produto ou fazer uma campanha de marketing?

No caso de reduzir o preço, conhecendo a curva de demanda, se abaixar o preço em 3%, sua receita sobe 7% pois vai ganhar market-share. Você calculou a relação de preço versus vendas e, conseqüentemente, a migração de consumidores do produto concorrente para o seu. Mas e se seu concorrente reagir e também abaixar o preço na mesma proporção? Como conseqüência da estratégia dele, o seu ganho, antes imaginado como aumento em 7%, muda para uma perda de 5% pois não aconteceu como você previu.



O resultado (ganho ou perda) de uma decisão depende obrigatoriamente da movimentação dos dois concorrentes, tornando a tomada de decisão muito mais complexa. Por isso, você precisa saber quais são os ganhos ou perdas de cada combinação e identificar quais são os incentivos mais atraentes para seu adversário, sabendo que ele está imaginando quais são os seus ganhos para também tomar uma decisão.

Com essas informações e deduções, reduzir o preço não é uma boa estratégia. Então você imagina fazer uma campanha de marketing. Começa outro ciclo de previsões: como ele vai reagir neste caso? Ao se antecipar as ações do seu competidor, você deve repensar antes de agir e visualizar todas as implicações de cada decisão, e ele fará o mesmo simultaneamente.

Por isso, a melhor recomendação é: antes de tomar uma decisão, coloque-se no lugar do concorrente e imagine qual seria a reação dele dadas as ações e incentivos existentes. Simultaneamente ele fará o mesmo - entender quais são suas motivações e ações para que ele tome a melhor decisão. Este é ciclo sem fim: você pensa que ele pensa que você pensa que ele pensa que....

Teoria dos Jogos é isso: entender que sua decisão não é independente e ambos os ganhos dependem da combinação de muitas ações em cadeia até chegar em um equilíbrio. Este equilíbrio é o chamado Equilíbrio de Nash, em homenagem a John Nash Jr, prêmio Nobel de 1994 e que foi personagem de Russell Crowe no filme Uma Mente Brilhante, ganhador do Oscar de 2002.

Outras analogias interessantes sobre decisões interdependentes são o Dilema da Ponte e o Dilema do Vagão de Trem.


Teoria dos Jogos: o intuitivo agora sistematizado

Pensar no concorrente e nas ações-reações antes agir parece ser muito intuitivo. Você já pensa assim, certo? Então, por que precisaria da Teoria dos Jogos para uma atitude tão óbvia? Resposta: porque a Teoria dos Jogos oferece metodologias que organizam o seu raciocínio nos jogos do cotidiano com seu concorrente, chefe, subordinado, colega de trabalho, cliente, fornecedor, vendedor, amigo, esposa/marido, governo, consumidor e outros.

Nesta caixa de ferramentas existem alguns conceitos estruturados que ajudam na comunicação e no entendimento de como as pessoas decidem. Exemplos:

- matriz de resultados ou esquema de incentivos
- jogos seqüenciais versus simultâneos
- cooperação versus competição
- dilema do prisioneiro e equilibrio ineficiente
- equilíbrio de Nash
- estratégia dominante e backward induction
- jogos repetitivos e estratégia mista
- informação incompleta

Assim como várias teorias de administração ajudam a estruturar o seu pensamento nas decisões competitivas, a Teoria dos Jogos possui modelos formais e exemplos que facilitam o entendimento nas decisões interdependentes, além de facilitar a comunicação e treinamento dos conceitos como qualquer teoria formal. A base da teoria é colocar-se na posição do outro e raciocinar o que você faria em cada situação, modelando todas as interações com benefícios/prejuízos de ambos e daí tomar a melhor ação estratégica.

A Teoria dos Jogos, como disciplina independente, não resolve todos os problemas, mas apresenta vários insights para melhorar seu pensamento estratégico como um elemento complementar das demais Teorias de Decisões. Para se aprofundar e para ser um bom estrategista, é importante unir os conceitos das disciplinas de Estratégia, da Economia Clássica (como preferências e utilidades, resultado esperado, risco e incerteza, free-rider, assimetria de informações) e da Teoria Comportamental (heurísticas e viéses cognitivos). Neste último caso, quanto mais você souber quais são os incentivos e reais motivações do seu concorrente ou parceiro, maiores as suas chances de ganhar o jogo. A união de todos os elementos é uma grande forma para melhorar suas decisões estratégicas.

Fonte: http://www.teoriadosjogos.net/teoriadosjogos/list-trechos.asp?id=24

Night Terrors

Night terrors is a phenom that occurs in children between 3 and 6 years old.

symptoms:
- sleepwalking
- to scream while sleep
- scaring while sleep

causes:
- sadness
- greasy food
- lack of sleep routine

treatment:
- don't awake the children
- help them with the goods words
- follow a sleep routine

Night terrors doesn't leave memories and last for much time.

A Couple of Surreal Pictures

Improving Performance

The two factors that determine the system performance are as follows:

• Processing time—The processing time includes the time spent in computing, data marshaling and unmarshaling, buffering, and transporting over a network.
• Blocked time—The processing of a request can be blocked due to the contention for resources, or a dependency on other processing. It can also be caused by certain resources not available; for example, an application might need to run an aggressive garbage collection to get more memory available for the processing.

The following practices are commonly used to increase the system performance:

• Increase the system capacity by adding more raw processing power.
• Increase the computation efficiency by using efficient algorithms and appropriate component models technologies.

Introduce cached copies of data to reduce the computation overhead, as follows:

• Introduce concurrency to computations that can be executed in parallel.
• Limit the number of concurrent requests to control the overall system utilization.
• Introduce intermediate responses to improve the performance perceived by the user.

YAGNI

Logical layers are merely a way of organizing your code. Typical layers include Presentation, Business and Data – the same as the traditional 3-tier model. But when we’re talking about layers, we’re only talking about logical organization of code. In no way is it implied that these layers might run on different computers or in different processes on a single computer or even in a single process on a single computer. All we are doing is discussing a way of organizing a code into a set of layers defined by specific function.

Physical tiers however, are only about where the code runs. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers.

Pink Floyd HD Pulse Live at Earls Court 1994

You'd Better Writer a Effective Code - Java Effective

Creating and Destroying Objects
Item 1: Consider static factory methods instead of constructors
Item 2: Consider a builder when faced with many constructor parameters
Item 3: Enforce the singleton property with a private constructor or an enum type
Item 4: Enforce noninstantiability with a private constructor
Item 5: Avoid creating unnecessary objects
Item 6: Eliminate obsolete object references
Item 7: Avoid finalizers

Methods Common to All Objects
Item 8: Obey the general contract when overriding equals
Item 9: Always override hashCode when you override equals
Item 10: Always override toString
Item 11: Override clone judiciously
Item 12: Consider implementing Comparable

Classes and Interfaces
Item 13: Minimize the accessibility of classes and members
Item 14: In public classes, use accessor methods, not public fields
Item 15: Minimize mutability
Item 16: Favor composition over inheritance
Item 17: Design and document for inheritance or else prohibit it
Item 18: Prefer interfaces to abstract classes
Item 19: Use interfaces only to define types
Item 20: Prefer class hierarchies to tagged classes
Item 21: Use function objects to represent strategies
Item 22: Favor static member classes over nonstatic

Generics
Item 23: Don’t use raw types in new code
Item 24: Eliminate unchecked warnings
Item 25: Prefer lists to arrays
Item 26: Favor generic types
Item 27: Favor generic methods
Item 28: Use bounded wildcards to increase API flexibility
Item 29: Consider typesafe heterogeneous containers

Enums and Annotations
Item 30: Use enums instead of int constants
Item 31: Use instance fields instead of ordinals
Item 32: Use EnumSet instead of bit fields
Item 33: Use EnumMap instead of ordinal indexing
Item 34: Emulate extensible enums with interfaces
Item 35: Prefer annotations to naming patterns
Item 36: Consistently use the Override annotation
Item 37: Use marker interfaces to define types

Methods
Item 38: Check parameters for validity
Item 39: Make defensive copies when needed
Item 40: Design method signatures carefully
Item 41: Use overloading judiciously
Item 42: Use varargs judiciously
Item 43: Return empty arrays or collections, not nulls
Item 44: Write doc comments for all exposed API elements

General Programming
Item 45: Minimize the scope of local variables
Item 46: Prefer for-each loops to traditional for loops
Item 47: Know and use the libraries
Item 48: Avoid float and double if exact answers are required
Item 49: Prefer primitive types to boxed primitives
Item 50: Avoid strings where other types are more appropriate
Item 51: Beware the performance of string concatenation
Item 52: Refer to objects by their interfaces
Item 53: Prefer interfaces to reflection
Item 54: Use native methods judiciously
Item 55: Optimize judiciously
Item 56: Adhere to generally accepted naming conventions

Exceptions
Item 57: Use exceptions only for exceptional conditions
Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
Item 59: Avoid unnecessary use of checked exceptions
Item 60: Favor the use of standard exceptions
Item 61: Throw exceptions appropriate to the abstraction
Item 62: Document all exceptions thrown by each method
Item 63: Include failure-capture information in detail messages
Item 64: Strive for failure atomicity
Item 65: Don’t ignore exceptions

Concurrency
Item 66: Synchronize access to shared mutable data
Item 67: Avoid excessive synchronization
Item 68: Prefer executors and tasks to threads
Item 69: Prefer concurrency utilities to wait and notify
Item 70: Document thread safety
Item 71: Use lazy initialization judiciously
Item 72: Don’t depend on the thread scheduler
Item 73: Avoid thread groups

Serialization
Item 74: Implement Serializable judiciously
Item 75: Consider using a custom serialized form
Item 76: Write readObject methods defensively
Item 77: For instance control, prefer enum types to readResolve
Item 78: Consider serialization proxies instead of serialized instances

Simulation in Bizagi - explained