Etapas do Método de Pesquisa

1. Escolha do tema
2. Revisão de literatura
3. Justificativa
4. Formulação do problema
5. Determinação de objetivos
6. Metodologia
7. Coleta de dados
8. Tabulação de dados
9. Análise e discussão dos resultados
10. Conclusão da análise dos resultados
11. Redação e apresentação do trabalho científico
12. Divulgação

Projeto de Pesquisa - Uma Metáfora

No projeto, se combina, se equacionam, os diferentes fatores que influem na viagem (a pesquisa):

1) A motivação pela qual empreendemos a viagem (o problema)
2) O lugar de onde partimos (estado do conhecimento)
3) A escolha do caminho a seguir para não nos perdemos, para chegar onde queremos (o método)
4) A luz que iluminará o nosso caminho (a teoria)
5) As ferramentas que levaremos para abrir o caminho (a técnica)
6) A velocidade que avançaremos de acordo com os recursos disponíveis (aspectos operativos)

7) O lugar que queremos chegar (os objetivos e resultados)

Highway Star - Chickenfoot

Joe Satriani - Love Thing

Yngwie Malmsteen - Live with Orchestra

Mário Sergio Cortella - Provocações Filosóficas

A mente presa

"Nós seguimos como máquinas nossa enfadonha rotina diária. Como a mente aceita avidamente um padrão de existência, e tenazmente se agarra a ele! Como por um prego encravado, a mente é mantida junta pela ideia, e em torno da ideia ela vive e tem seu ser. A mente nunca está livre, flexível, pois está sempre presa; ela se move dentro do raio, estreito ou amplo, de seu próprio centro. Desse centro ela não ousa sair; e quando o faz, fica perdida no medo. O medo não é do desconhecido, mas da perda do conhecido. O desconhecido não incita o medo, mas a dependência do conhecido o faz. O medo está sempre com o desejo, o desejo de mais ou de menos. A mente, com seu incessante tecer de padrões, é que faz o tempo; e com o tempo há medo, esperança e morte." - Krishnamurti, J. Krishnamurti, The Book of Life

Implications for how we build software

From process to architecture

From centralized to decentralized 

From planning to experimentation

From long cycles to short cycles

From large teams to small teams

From internal to ecosystem

From CMM (I) to agile

From cathedral to bazaar

Cândido, ou o otimismo

Até ser expulso de um lindo castelo na Westfália, o jovem Cândido convivia com sua amada, a bela Cunegunda, e tinha a felicidade de ouvir diariamente os ensinamentos de mestre Pangloss, para quem “todos os acontecimentos estão encadeados no melhor dos mundos possíveis”.
Apesar da crença absoluta na doutrina panglossiana, do primeiro ao último capítulo, Cândido sofre um sem-fim de desgraças: é expulso do castelo; perde seu amor; é torturado por búlgaros; sobrevive a um naufrágio para em seguida quase perecer em um terremoto; vê seu querido mestre ser enforcado em um auto da fé; é roubado e enganado sucessivas vezes.
Cândido só começa a desconfiar do otimismo exacerbado de seu mestre quando ele próprio e todos os que cruzam seu caminho dão provas concretas que o melhor dos mundos possíveis vai, na verdade, muito mal.
Cândido, ou o Otimismo é um retrato satírico de seu tempo. Escrito em 1758, situa o leitor entre fatos históricos como o terremoto que arrasou Lisboa em 1755 e a Guerra dos Sete Anos (1756-63), enquanto critica com bom-humor as regalias da nobreza, a intolerância religiosa e os absurdos da Santa Inquisição. Já o caricato mestre Pangloss é uma representação sarcástica da filosofia otimista do pensador alemão Gottfried Leibniz (1646-1716).
Antecipando o sucesso desbragado e a carreira de escândalo do livro, Voltaire, pseudônimo de François-Marie Arouet, assinou a obra com o enigmático Sr. Doutor Ralph.

Feynman, lectures on physics

“Imagine que o mundo seja algo como uma gigantesca partida de xadrez sendo disputada pelos deuses, e que nós fazemos parte da audiência. Não sabemos quais são as regras do jogo; podemos apenas observar seu desenrolar. Em princípio, se observarmos por tempo suficiente, iremos descobrir algumas das regras. As regras do jogo é o que chamamos de ciência.” - Feynman lectures on physics

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

Advanced Hibernate

Advanced Hibernate V2 from Haitham Raik

PrimeFaces vs RichFaces vs IceFaces

In this tutorial we will compare three commonly used libraries which are used on the top of your JSF implementation. Richfaces, IceFaces and Primefaces.

http://www.mastertheboss.com/richfaces/primefaces-vs-richfaces-vs-icefaces

Nossos Pais Tecnológicos

Git Branching Strategy

Git Essencial

http://git-scm.com/book/pt-br/

People Management

Maven: Generating DDL Scripts from JPA Annotations

Java’s persistence API (JPA) makes object-relational mapping very convenient. Persistence providers like Hibernate can create tables and sequences automatically saving lots of tedious work at development time. However, in production systems automatic schema creation isn’t desired.

In many cases you want to tune the schema a bit, like adding an index for speeding up common access paths, renaming constraints and the like. Additionally, an application should run with as little DB privileges as possible, so it’s quite common that CREATE TABLE or other DDL/SQL statements are simply not permitted.

That’s where the Hibernate3 Maven Plugin can give you a good starting point for your optimizations.

Prerequisites

This article is for you if

• you use JPA annotations on your entities
• your persistence provider is Hibernate 3

Configuration

The plugin wraps an Ant task from Hibernate Tools that analyzes your JPA entities and creates a database schema for them.

Add the following to your pom.xml:

hibernate3-maven-plugin 2.2 hbm2ddl jpaconfiguration Default schema.ddl false true false true

Then adjust your persistence.xml file in src/main/resources/META-INF to set the SQL dialect to use for the DDL statements:

The example above uses HSQL (the embedded database that ships with JBoss), but you’ll likely need a different dialect for your production setup. You can get a list of supported dialects from Hibernate’s API documentation. Also make sure that the persistence unit’s name (Default in this example) matches with the plugin configuration and your persistence.xml.

Now execute the hbm2ddl goal from the command line to create the schema:

mvn hibernate3:hbm2ddl

You will find your schema in target/hibernate3/sql/schema.ddl.

Alternatives

If you want to execute hibernate3::hbm2ddl automatically as part of your normal build, you can tie the hbm2ddl goal to the process-classes phase. There’s an example on the plugin’s homepage.

Further Reading

Traditionally, Maven plugins aren’t documented that well. But since hibernate3-maven-plugin is just a thin wrapper around Hibernate Tools, you can find documentation there.

• Hibernate3 Maven Plugin
• Hibernate Tools Reference Guide
• My original blog posting

There’s a lot more the plugin can do, especially if you’re not using JPA annotations, by the way.

Red Sector A

All that we can do is just survive
All that we can do to help ourselves
Is stay alive...

Catcher In The Rye

When all is said and done
We're not the only ones
Who look at life this way
That's what the old folks say
But every time I see them
Makes me wish I had a gun
If I thought that I was crazy
Well I guess I'd have more fun
(Guess I'd have more fun)

Luz, trevas e o método científico

É Tão Bonitinha Não?

Deep Purple - Child in Time

Cientistas de Dados x Engenheiros de Dados

Machado de Assis

"Felizes os cães, que pelo faro descobrem os amigos."

Machado de Assis

Jethro Tull - Cross Eyed Mary

Déspotas

“Há três tipos de déspotas. Aquele que tiraniza o corpo, aquele que tiraniza a alma e o que tiraniza, ao mesmo tempo, o corpo e a alma. O primeiro é chamado de príncipe, o segundo de papa e o terceiro de povo”.

Oscar Wilde

Awesome

7 Economic Attributes Compared

Think about economy. The main question is "mind set".

Market Economy (AS-IS)	Earth Economy (TO-BE)
Consumption	Preservation
Obsolescence	Optimum Design
Property	Access
Infinite Growth	Steady State
Competition	Collaboration
Labor for Income	Mechanization
Scacity/Imbalance	Abundance/Equality

Best Best Practices Ever

1. Write programs for people, not computers.
   1. a program should not require its readers to hold more than a handful of facts in memory at once
   2. names should be consistent, distinctive and meaningful
   3. code style and formatting should be consistent
   4. all aspects of software development should be broken down into tasks roughly an hour long
2. Automate repetitive tasks.
   1. rely on the computer to repeat tasks
   2. save recent commands in a file for re-use
   3. use a build tool to automate scientific workflows
3. Use the computer to record history.
   1. software tools should be  used to track computational work automatically
4. Make incremental changes.
   1. work in small steps with frequent feedback and course correction
5. Use version control.
   1. use a version control system
   2. everything that has been created manually should be put in version control
6. Don’t repeat yourself (or others).
   1. every piece of data must have a single authoritative representation in the system
   2. code should be modularized rather than copied and pasted
   3. re-use code instead of rewriting it
7. Plan for mistakes.
   1. add assertions to programs to check their operation
   2. use an off-the-shelf unit testing library
   3. use all available oracles when testing programs
   4. turn bugs into test cases
   5. use a symbolic debugger
8. Optimize software only after it works correctly.
   1. use a profiler to identify bottlenecks
   2. write code in the highest-level language possible
9. Document design and purpose, not mechanics.
   1. document interfaces and reasons, not implementations
   2. refactor code instead of explaining how it works
   3. embed the documentation for a piece of software in that software
10. Collaborate.
    1. use pre-merge code reviews
    2. use pair programming when bringing someone new up to speed and when tackling particularly tricky problems

The only extra I would have included would be:

11. Maintain and update older code.

Expressões Idiomáticas - Idioms

A Língua Inglesa possui algumas armadilhas para quem não a fala como língua materna, dentre elas estão as Expressões Idiomáticas (Idioms), que são figuras de linguagem onde um termo ou a frase assume um significado diferente do que as palavras teriam isoladamente. Assim, não basta saber o significado das palavras que formam a frase, é preciso olhar para todo o grupo de palavras que constitui a expressão para entender o seu significado. As Expressões Idiomáticas trazem conotações diferentes, que, na maioria das vezes, estão relacionadas às suas origens. É importante salientar que os idiomatismos não foram criados para serem armadilhas para os falantes estrangeiros, pelo contrário, elas tornam o Inglês Falado (Spoken English) mais natural. Relacionamos abaixo alguns exemplos de Expressões Idiomáticas mais usadas pelos falantes nativos da Língua Inglesa.

Act your age = Não seja infantil

All day long = O dia todo

Beyond a shadow of doubt = Sem sombra de dúvida

Blood is thicker than water = Os laços de família são mais fortes

Cross my heart = Juro por Deus

Everybody says so =Todos falam assim!

For goodness’ sake! = Pelo amor de Deus!

Good Lord! = Meu Deus!

Hand in Hand = De mãos dadas

I did quite well = Sai-me muito bem

Keep your eyes peeled = Fique atento
Leave it to me = Deixa comigo

Like hell! = Uma ova!

May I have the floor? = Posso falar?

Mum’s the word = Boca de siri
Never heard of = Nunca ouvi dizer

Never mind = Deixa prá lá / Não tem importância

Once and for all = De uma vez por todas

One never knows = Nunca se sabe

Pretty soon = Em breve

Quite a bit = muito, um montão, bastante, um bocado

Right over there = Logo ali

See you there = Até lá

Shoot the works = Manda brasa

Talk is cheap = Falar é fácil

Thank God = Graças a Deus

It is up to you = Você que sabe

You know best = Você é quem sabe

Take your time = Não se apresse

So far, so good? = Até aqui, tudo bem?

It is not your business = Não é da sua conta

To kick the bucket = Bater as botas / Morrer

How come? = Como é que pode?

How are you doing? = Como está?

The Age Of Big Data - BBC Documentary

Fala a verdade: você não sabia que era dele né?

Poor Man

Who would be a poor man, a beggarman, a thief If he had a rich man in his hand.

Software como Produto ou como Serviço?

Comportamento & Palavras

“Nada é mais destrutivo para a melhoria do que pessoas cujo comportamento é inconsistente com suas palavras.”

 (J. P. Kotter)

Manual de Sobrevivênvia no Corporativismo

PRINCÍPIOS E CONSELHOS PRÁTICOS GERAIS

• Princípio Número 1: “Money first”. Isso de valores ou princípios organizacionais é coisa pra filósofo.
• Nunca questione o status quo ou o que você aprendeu na escola. Afinal, tanta gente não pode estar errada por tanto tempo.
• Não perca muito tempo com análise e planejamento. Considerando o seu nível de inteligência e experiência, bastam um ou dois dias (quando muito) para definir uma estratégia.
• Continue gerenciando através de departamentos. Estabeleça metas numéricas para cada departamento e exerça tremenda pressão para que sejam cumpridas. Exija explicação para o mínimo desvio em relação às metas.
• Não meça nada; paute-se sempre pela sua grande experiência. Mas o extremo oposto é também uma alternativa eficaz: meça tudo; transforme a coleta de dados e a elaboração de relatórios e apresentações numa refinada arte, amplamente praticada na empresa.
• Não padronize nada; o TIRO (a Técnica Intuitiva para Remover Obstáculos) e o improviso devem ser os principais métodos para buscar melhorias. Ou se preferir o extremo oposto, burocratize tudo; implemente controles em abundância.
• Não delegue nada; afinal ninguém fará melhor do que você. Mas se preferir, delegue tudo; não se envolva diretamente com nada (o alto do Olimpo Corporativo é bem mais seguro).
• Concorde com tudo. Faça lindos discursos, mas não vá muito além disso. Depois de algum tempo o modismo passa e tudo volta ao normal, exatamente como sempre esteve.

GESTÃO DA OPERAÇÃO

• Primeiro Corolário (derivado do Princípio No. 1): A prioridade é reduzir custos. Sempre será possível espremer um pouquinho mais.
• Quando alguma melhoria trouxer aumento de produtividade, aproveite para reduzir os gastos com a mão de obra: demita. E exija que os que ficaram continuem buscando mais produtividade.
• Sempre que possível, assegure-se de que todos os recursos produtivos (pessoas inclusive) estejam  trabalhando a 100% (ou mais) de sua capacidade. Se houver acúmulo crônico de trabalho em algumas áreas, não afrouxe e nem desanime. Isso é até bom, pois assegura que eles  sempre terão trabalho pra realizar.

GESTÃO DE PESSOAL

• Não invista muito em ter pessoal competente; isso custa muito caro. Em vez disso, estabeleça controles rígidos para evitar que cometam erros ou que “folguem”.
• Mantenha um sofisticado sistema de remuneração variável. Fisgue o seu pessoal pelo estômago: quem não estiver acima da média, que ganhe bem pouquinho. Quem sabe assim eles se animam, e no futuro todos terão desempenho acima da média...
• Exija que todo projeto de melhoria dê retorno financeiro de pelo menos X dólares (coloque um valor de X bem alto, que seja um “stretch target”).
• Não hesite em interferir em assuntos operativos diretamente. De vez em quando é bom “passar por cima” do responsável direto. Vantagens: sua autoridade será reforçada, e todos saberão que têm um chefe.
• Estenda o Balanced Scorecard até o nível individual.

SOBRE CLIENTES

• Não desperdice tempo e recursos em investigar o mercado e conhecer os clientes. Afinal, você e seus pessoal técnico já sabem o que eles necessitam.
• Coloque o cliente no seu devido lugar: em segundo plano. Lembre-se do primeiro princípio: “money first”.

Gestão de Processos e Gestão por Processos: uma grande diferença!

Por influência da ISO9000, a maioria das empresas hoje têm seus processos definidos e padronizados. Mas praticamente todas elas continuam padecendo dos males clássicos da administração departamentalizada: má comunicação entre áreas, objetivos conflitantes, erros, retrabalhos e um crônico combate a incêndios. Como isso é possível se a “visão de processos” já está implementada, até com certificação internacional?

O que explica este aparente paradoxo é que a padronização de processos em tais empresas é feita processo por processo, isto é: os processos de trabalho são identificados, equipes de padronização são mobilizadas e no final temos um intrincado arquipélago de “ilhas” de processos! As coisas até fluem, mas apenas dentro das fronteiras de cada ilha. Na prática, o que isso fez foi apenas transformar os velhos problemas de comunicação que havia entre departamentos em novos problemas de comunicação entre processos. O que antes era o Departamento de Vendas, agora é o “Processo Comercial”; o Departamento de Engenharia de Produtos agora cuida do “Processo de Desenvolvimento de Novos Produtos” etc. O que antes eram as metas departamentais agora recebem um novo nome: “Key Process Indicators” ou coisas do gênero. Na prática, cada um continua puxando a brasa pra sua sardinha, perpetuando os problemas da administração departamentalizada. O estilo de gestão não mudou; continua a velha cobrança de metas numéricas para cada área funcional.

Não houve uma transformação organizacional. Excetuando-se algumas melhorias pontuais, não houve um salto qualitativo no desempenho da empresa. No frigir dos ovos, só foi acrescentado um elemento novo: o custo de manutenção de toda a parafernália pesada de documentos do “novo” “sistema” de “gestão” (três mentiras numa só expressão, pois não é novo, não funciona como um sistema, e não merece o título de verdadeira gestão). Isto é a “Gestão DE Processos” que se vê por aí. Bem diferente seria implementar a “Gestão POR Processos”, isto é: “Gestão do Sistema de Negócios através dos Processos Empresariais”, partindo da necessidade de todas as partes interessadas para revisar toda a estrutura das atividades do negócio (não apenas qualidade, meio ambiente e saúde ocupacional), garantindo seu alinhamento à satisfação das partes interessadas e padronizando os processos de maneira integrada, a partir de um modelo sistêmico. Em poucas palavras: padronizar o fluxo contínuo de materiais e informações de ponta a ponta na empresa, em resposta ao mercado e demais partes interessadas. Isto é Gestão por Processos.

UX and user context

Treze pontos do Método Montessori

1. Baseia-se em anos de observação da natureza da criança por parte do maior gênio da educação desde Friedrich Froebel.
2. Demonstrou ter uma aplicabilidade universal.
3. Revelou que a criança pequena pode ser um amante do trabalho, do trabalho intelectual, escolhido de forma espontânea, e assim, realizado com muita alegria.
4. Baseia-se em uma necessidade vital para a criança que é a de aprender fazendo. Em cada etapa do crescimento mental da criança são proporcionadas atividades correspondentes com as quais se desenvolvem suas faculdades.
5. Ainda que ofereça à criança uma grande espontaneidade consegue capacitá-la para alcançar os mesmos níveis, ou até mesmo níveis superiores de sucesso escolar, que os alcançados sobre os sistemas antigos.
6. Posições para a melhor procriação na fase infanto-juvenil
7. Consegue uma excelente disciplina apesar de prescindir de coerções tais como recompensas e castigos. Explica-se tal fato por tratar-se de uma disciplina que tem origem dentro da própria criança e não imposta de fora.
8. Baseia-se em um grande respeito pela personalidade da criança, concedendo-lhe espaço para crescer em uma independência biológica, permitindo-se à criança uma grande margem de liberdade que se constitui no fundamento de uma disciplina real.
9. Permite ao professor tratar cada criança individualmente em cada matéria, e assim, fazê-lo de acordo com suas necessidades individuais.
10. Cada criança trabalha em seu próprio ritmo.
11. Não necessita desenvolver o espírito de competição e a cada momento procura oferecer às crianças muitas oportunidades para ajuda mútua o que é feito com grande prazer e alegria.
12. Já que a criança trabalha partindo de sua livre escolha, sem coerções e sem necessidade de competir, não sente as tensões, os sentimentos de inferioridade e outras experiências capazes de deixar marcas no decorrer de sua vida.
13. O método Montessori se propõe a desenvolver a totalidade da personalidade da criança e não somente suas capacidades intelectuais. Preocupa-se também com as capacidades de iniciativa, de deliberação e de escolhas independentes e os componentes emocionais.

Software Requirements

Software Engineering Code of Ethics and Professional Practice

ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional Practices

PREAMBLE

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development,
testing and maintenance of software a beneficial and respected profession. In accordance with their
commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC — Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in the
best interests of their client and employer consistent with the public interest.
3. PRODUCT — Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. JUDGMENT — Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and
maintenance.
6. PROFESSION — Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.
7. COLLEAGUES — Software engineers shall be fair to and supportive of their
colleagues.
8. SELF — Software engineers shall participate in lifelong learning regarding the
practice of their profession and shall promote an ethical approach to the
practice of the profession.

The ACM/IEEE Code of Ethics (© IEEE/ACM 1999)