An Example Kanban Board for DevOps

Does it sound familiar?

The Right Mindset

Research has shown that the mindset that people have about their own abilities and more specifically where those abilities come from has a significant impact on how people learn and grow. Dr. Carol Dweck, and professor and researcher of social and developmental psychology, described this in terms of two different mindsets. With a  xed mindset, people believe that their talents and abilities are innate, fixed traits - either they are naturally good at something or they aren’t, and that state is seen as immutable. In a growth mindset, talents and abilities are seen as things that can be learned and improved with effort and practice. These mindsets can impact how peo‐ ple work, how they approach challenges, and how they deal with failure.

Personal Transition Curve

Value Stream Mapping on Software

THE MACHINE LEARNING PROCESS

Data Collection and Preparation
Throughout this book we will be in the fortunate position of having datasets readily available for downloading and using to test the algorithms. This is, of course, less commonly the case when the desire is to learn about some new problem, when either the data has to be collected from scratch, or at the very least, assembled and prepared. In fact, if the problem is completely new, so that appropriate data can be chosen, then this process should be merged with the next step of feature selection, so that only the required data is collected. This can typically be done by assembling a reasonably small dataset with all of the features that you believe might be useful, and experimenting with it before choosing the best features and collecting and analysing the full dataset.
Often the difficulty is that there is a large amount of data that might be relevant, but it is hard to collect, either because it requires many measurements to be taken, or because they are in a variety of places and formats, and merging it appropriately is difficult, as is ensuring that it is clean; that is, it does not have significant errors, missing data, etc.
For supervised learning, target data is also needed, which can require the involvement of experts in the relevant field and significant investments of time.
Finally, the quantity of data needs to be considered. Machine learning algorithms need significant amounts of data, preferably without too much noise, but with increased dataset size comes increased computational costs, and the sweet spot at which there is enough data without excessive computational overhead is generally impossible to predict.

Feature Selection
It consists of identifying the features that are most useful for the problem under examination. This invariably requires prior knowledge of the problem and the data; our common sense was used in the coins example above to identify some potentially useful features and to exclude others.
As well as the identification of features that are useful for the learner, it is also necessary that the features can be collected without significant expense or time, and that they are robust to noise and other corruption of the data that may arise in the collection process.

Algorithm Choice
Given the dataset, the choice of an appropriate algorithm (or algo- rithms) is what this book should be able to prepare you for, in that the knowledge of the underlying principles of each algorithm and examples of their use is precisely what is required for this.

Parameter and Model Selection 
For many of the algorithms there are parameters that have to be set manually, or that require experimentation to identify appropriate values.

Training
Given the dataset, algorithm, and parameters, training should be simply the use of computational resources in order to build a model of the data in order to predict the outputs on new data.

Evaluation 
Before a system can be deployed it needs to be tested and evaluated for ac- curacy on data that it was not trained on. This can often include a comparison with human experts in the field, and the selection of appropriate metrics for this comparison.

Lessons from Predictably Irrational

1. The Truth about Relativity: Why Everything Is Relative—Even When It Shouldn't Be
1. Our mind is relative-oriented. Thus, we always try to based on something to make a decision.
2. The Fallacy of Supply and Demand: Why the Price of Pearls—and Everything Else— Is Up in the Air
1. The demand is controlled by the perception of value.
3. The Cost of Zero Cost: Why We Often Pay Too Much When We Pay Nothing
1. When we get a zero cost thing we felling an obligation to pay for that in somehow.
4. The Cost of Social Norms: Why We Are Happy to Do Things, but Not When We Are Paid to Do Them
1. The best rule. We living in two worlds: social and market. If we tryed to pay something social using a market system, probably we will have a problem.
5. The Influence of Arousal: Why Hot Is Much Hotter Than We Realize
1. Try to relax and do not make decision when you are in arousal state. The market of sex is based on this rule
6. The Problem of Procrastination and Self-Control: Why We Can't Make Ourselves Do What We Want to Do
1. Restricting our freedom (equally spaced deadlines) is the best cure for procrastination.
7. The High Price of Ownership: Why We Overvalue What We Have
1. We still believed that in general the ownership of something increases its value in the owner's eyes
8. Keeping Doors Open: Why Options Distract Us from Our Main Objective
1. In the context of today's world, we work just as feverishly to keep all our options open. Given a simple setup and a clear goal (in this case, to make money), all of us are quite adept at pur­ suing the source of our satisfaction, or, get many options
9. The Effect of Expectations: Why the Mind Gets What It Expects
1. When we believe beforehand that something will be good, therefore, it generally will be good—and when we think it will be bad, it will bad. 
10. The Power of Price: Why a 50-Cent Aspirin Can Do What a Penny Aspirin Can't
1. We still believe that a expensive goods is better rather than a cheap goods.
11. The Context of Our Character, Part I: Why We Are Dishonest, and What We Can Do about It
1. Our honesty monitor is a quite flexible, adapting on our culture, and our decisions about honesty is based on a cost/benefit analysis.
12. The Context of Our Character, Part II: Why Dealing with Cash Makes Us More Honest
1. The days of cash are coming to a close. Cash is a drag on the profits of banks—they want to get rid of it. On the other hand, electronic instruments are very profitable. 
13. Beer and Free Lunches: What Is Behavioural Economics, and Where Are the Free Lunches?
1. As long as these mechanisms provide more benefits than costs, we should consider them to be free lunches—mechanisms that provide net benefits to all parties.

Once we understand when and where we may make errone­ ous decisions, we can try to be more vigilant, force ourselves to think differently about these decisions, or use technology to overcome our inherent shortcomings. 

Business Rules Engine

A dificuldade de engajamento

Se uma organização fosse um time de futebol composto por 11 jogadores...

• Apenas 4 jogadores saberiam para que lado atacam... 
• Apenas 2 se preocupariam em ganhar o jogo... 
• Apenas 2 jogadores não estariam competindo contra alguém do seu próprio time!!

Competency

How organizations process information

What is Value Stream Mapping?

“All we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes.” (Ohno, 1988) 

1. Overproduction: Producing items for which there are no orders.
   
2. Waiting Time: Employees standing about. Inventory at stand-still.
   
3. Unnecessary Transport: Moving material unnecessarily or long distances.
   
4. Over-processing: Using more steps to produce a product than necessary.
   
5. Excess Inventory: Retaining unnecessary inventory between process steps.
   
6. Unnecessary Movement: Any wasted motion by man or machine.
   
7. Defect: Making incorrect product.
   
   Value is from the customer’s perspective, the customer being the person who uses the output. 
   

Os dois lados da moeda

Medo e prazer são os dois lados de uma moeda: você não pode livrar-se de um, sem se livrar do outro também. Você quer ter prazer toda a vida e também ficar livre do medo – é só com isso que você se preocupa. Mas você não vê que fica frustrado se o prazer de amanhã lhe for negado, você se sente irrealizado, raivoso, ansioso e culpado, e todos os sofrimentos psicológicos vêm à tona. Portanto, você deve olhar para o medo e para o prazer juntos.

- Krishnamurti, The Impossible Question, pp 50-51

O que é Análise de Negócios?

Quem tem culpa no Jardim da Dona Cleusa?

Brigadeiros da Nice

Scientific Method Cool

What is a process?

Five Myths of Traditional Software Development

1. The myth of the specification: Traditional software development assumes that the first task is to determine the specification, and all design and development follows after the specification is finalized. More modern approaches stress spiral rapid development methods in which the specification is constantly being refined. The target is really a combination of related components, not a single application.
2. The myth of software maintenance: The word "maintenance" gives the impression that the software has somehow degraded, and needs to be refurbished to its original condition. This is misleading. The bits in a program do not degrade. They remain the same, while the environment around the program changes. So it is really a process of upgrading or evolving to meet the needs of the changing environment. By viewing it as a maintenance problem, one risks making the mistake of trying to preserve the old structure when its time has passed.
3. The myth of the black box: Abstraction plays a crucial role in the development of reliable software. However, treating a process as a black box with an input/output specification ignores the practical problem of resource usage. When a system built out of these black boxes is too big or too slow, there is no way to improve the performance other than to tear the boxes apart. Some work has been done on the idea of Open Implementation, in which modules have one interface for input/output behavior, and another orthogonal interface for performance tweaking. Adaptive software adds to this by making the orthogonal interface a two way system ÷ there is a feedback loop that provides information on the results of the performance tweaking.
4. The myth of design choices: In traditional software development, the designers consider several alternatives to implement each component, and then make choices based on the desired product. The alternatives that were not chosen, along with the rationale for the choice, are then discarded. That means when the environment changes (perhaps a new communications protocol becomes popular, or the user gets a computer that is twice as powerful), one needs to start all over again to see what choices are now the best. Often, the original programmers have moved on, and so their design rationale is lost. The alternative is to capture the design criteria as a formal part of the program, and let the program reconfigure itself, as the environment changes, to optimally satisfy the criteria.
5. The myth of the expert programmer: Most programmers have pride in their abilities, and feel they can always come up with a good solution, given a suitable specification of the problem. In reality, programmers are only one resource available to a project, and an expensive resource at that. Furthermore, it is impractical to ship a developer with each program (except for very large and expensive custom applications). This suggests that we find a tradeoff where the programmers and designers do what they can do best ÷ formally describe what the program is trying to do. Then the program itself does the calculating and configuring necessary to achieve these goals in the current environment.

We don't think globally

Escravidão Moderna

Soft Skills

Soft skills, até pouco tempo ignoradas, viraram uma verdadeira modinha no mundo corporativo nos últimos anos. Muito se fala na importância das soft skills e em como desenvolvê-las, o que é um grande desafio, já que primeiro devemos identificar o que elas são.

Idiotices como pesquisas sobre melhores empresas para se trabalhar ganharam muita força ultimamente, dando aos horses a ilusão de que seus empregadores possuem algum dever junto à peonada no que diz respeito a bem estar e condições de trabalho. Dentre os critérios que tais pesquisas inúteis utilizam para qualificar uma empresa como boa ou ruim para se trabalhar está a tal da “meritocracia”, ou “promoção por mérito”. De repente, a peonada começou a se insurgir contra uma das mais antigas práticas Go Horse: a promoção baseada na amizade e confiança.

O horse deve ter em mente que chefe não é pai e promove quem bem entender. Além disso, uma promoção para um cargo de natureza gerencial exclui o promovido do ciclo produtivo, o que faz da promoção por mérito uma grande inconveniência.

Tendo em vista o fato de que as atividades de um gerente se assemelham muito ao trabalho de verdade, porém totalmente alheias à construção do bem ou serviço vendido pela organização, promoções para cargos gerenciais passaram a ser justificados pelas tais “soft skills”. Ou seja, se algum peão ousar contestar uma promoção de alguém que não demonstra, segundo seu julgamento, a qualificação necessária, basta respondê-lo que tal promoção se deu em virtude de soft skills que o recém promovido detém.

Uma soft skill é uma competência ou característica pessoal atrelada à personalidade e que, ao contrário das competências técnicas, não demanda esforço por parte da pessoa que deseja desenvolvê-la. A avaliação de uma soft skill de alguém é vaga e subjetiva, o que torna extremamente fácil a um chefe goHorser justificar a promoção de um amigo incompetente.

Ou seja, soft skills são uma criação de membros goHorsers do Círculo de Confiança que tem como objetivo viabilizar uma fácil justificativa para uma inclusão repentina de um amigo às altas rodas da empresa.

Tal criação se mostrou tão eficiente na obtenção do seu objetivo que, em muitas empresas, ser competente tecnicamente depõe contra o horse. Isso significa que, se desejamos manter um horse competente eternamente na condição de peão, basta rotulá-lo como alguém “essencialmente técnico e sem soft skills”. Hoje é muito comum o fato de horses omitirem suas qualificações técnicas para manterem vivas as suas chances de ascender ao Círculo de Confiança.

Conheça algumas Soft Skills:

Nome Técnico: Sociabilidade
Significado: Vaselina
O que é: capacidade de dar tapinhas nas costas e sorrir para colegas escrotos e sem escrúpulos de quem se possa vir a precisar algum dia.

Nome Técnico: Capacidade de Persuasão
Significado: Manipulação de Otários
O que é: não importa o quão estúpida seja uma ideia, dependendo da convicção com a qual a defendemos, podemos convencer os otários a segui-las.

Nome Técnico: Liderança
Significado: Cenoura na frente do burro
O que é: ninguém faz nada sem receber algo em troca, e são vistos como líderes aqueles que ganham o apoio da massa ludibriando-a com promessas vazias.

O advento das soft skills trouxe a nós, goHorsers, um efeito colateral positivo: tem muito horse que quer crescer através do desenvolvimento desse tipo de competência, ignorando o fato de que as soft skills são usadas para justificar uma promoção DEPOIS que a mesma ocorre, e não antes. Isso gerou um vasto mercado a se explorar: cursos e treinamentos de comunicação, negociação, técnicas de apresentação e outras inutilidades.

The Master Algorithm

You may not know it, but machine learning is all around you. When you type a query into a search engine, it’s how the engine figures out which results to show you (and which ads, as well). When you read your email, you don’t see most of the spam, because machine learning filtered it out. Go to Amazon.com to buy a book or Netflix to watch a video, and a machine learning system helpfully recommends some you might like. Facebook uses machine learning to decide which updates to show you, and Twitter does the same for tweets. Whenever you use a computer, chances are machine learning is involved somewhere. Traditionally, the only way to get a computer to do something—from adding two numbers to flying an airplane—was to write down an algorithm explaining how, in painstaking detail. But machine learning algorithms, also known as learners, are different: they figure it out on their own, by making inferences from data. And the more data they have, the better they get. Now we don’t have to program computers; they program themselves.

Pedro Domingos

http://homes.cs.washington.edu/~pedrod/

About the Time

Time is a HUMAN CONSTRUCT .  Outside of human understanding IT DOES NOT EXIST. It is a template which humans have made & applied to help us understand the ' human condition '.  i.e. That we live on a tiny planet within the solar system & move around a large star called the Sun. Time is a template applied to movement so that we can easily understand how ' THINGS CHANGE ' -  How THINGS CHANGE is what we call time. Time of itself -  does NOT exist - MOVEMENT & CHANGE exist  -  TIME IS A MAN MADE CONCEPT.  IT DOES NOT EXIST OF ITSELF IN NATURE.

The Smallest to the Biggest thing in the Universe

The difference between augmented reality and virtual reality is the difference between information retrieval vs. immersion experience.

Flow is the intersection of prevailing improvement methods

The First Law of Supply Chain

Life cycle of a product

Input/output control

Priority planning and production activity control

Capacity versus load

Star Wars the Force Awakens - Heavy Metal Version

Please hear my anguish words of truth

MICHAEL ANGELO BATIO - 2x Again

The Very Best of Deep Purple (Full Album)

Rewrite!

Behavior is the most important thing about software

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

Legacy code is simply code without tests

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t mat- ter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Refactor x Rewrite

The Legacy Code Dilemma

“When we change code, we should have tests in place. To put tests in place, we often have to change code.”

[Feathers 2005]

Developers and architects like to build things

Reasons for the code base getting worse over time,

• More and more features. It leads to increased complexity.
• Shortcuts and hacks to support “We need this fancy search till August. Period!” features
• Developers rotation. New developers don’t know all the fundamental decisions and ideas behind the architecture. Knowledge gets lost with transition inevitably.
• Development team growth. More people - less communication. Less communication - bad decisions.

Regra de Bourdichon & Darli

Structure for organizing around project based work

Types of Organizations - Project Management

Sustentabilidade social e ambiental

Pela visão organizacional, muitos processos de negócio têm sido desenhados para grande consumo de recursos, pilhagem do meio ambiente, emprego de tóxicos, geração de lixo, degradação, desperdício e produção ineficiente. Resultado frequente de uma mentalidade produtiva atrasada e pedagogia do desperdício que podem tornar o negócio insustentável em longo prazo. Em vez de transformar seus processos e melhorar a capacitação das pessoas, muitas organizações preferem perpetuar seus métodos obsoletos por meio de tecnologia melhorada.

Pela visão da sociedade, pessoas com carência material eterna e um senso de competição do ter, consumo desnecessário e desperdício associados visceralmente ao modo de vida moderno. Pessoas ávidas por incorporar velhos hábitos de consumo sonhando em adotar os mesmos padrões e estilo de vida que coletivamente remetem o planeta ao colapso ambiental. Mas como será possível satisfazer as necessidades de novos consumidores ou de consumidores ingressando no mercado consumidor ou ascendendo à pirâmide social sem incorrer em falhas do passado?

O pensamento econômico contemporâneo é centrado na produção e circulação, não importando exatamente de onde vem as matérias-primas ou para onde vão os resíduos. Organizações, governo e consumidores buscam lucrar, arrecadar ou satisfazer suas necessidades isoladamente e o fazem bem. Coletivamente, contudo, caminham para o "ecocídio" com a devastação do meio ambiente que, em última instância, é a infraestrutura básica para todas as atividades.

Desenho do novo processo

Notações de modelagem de processos

Processos de negoócio intensivos em conhecimento devem ser identificados e tratados adequadamente

Economias desenvolvidas estão cada vez menos baseadas na indústria e cada vez mais em setores do conhecimento, deslocando a importância de ativos tangíveis para ativos intangíveis. É certo que os diversos aspectos de processos de negócio envolvem conhecimento, desde a complexidade do domínio de interesse até o grau de experiência e conhecimento específico exigido de participantes do processo. Entretanto, processos de negócio intensivos em conhecimento (KIBP – Knowledge Intensive Business Process) nem sempre são estruturados e se caracterizam pelo envolvimento de pessoas e criatividade de forma muitas vezes complexa e de difícil automatização. Tais processos, via de regra, são dependentes do conhecimento das pessoas e seu fluxo se estabelece de forma evolutiva e dinâmica, não podendo ser claramente definido a priori, mas em tempo de execução. Geralmente é possível identificar nas organizações processos que são, plenamente ou em parte, intensivos em conhecimento. São exemplos os processos de atendimento médico, criação em marketing e pareceres jurídicos.

Organizações encontram problemas em suas iniciativas de transformação em processos intensivos em conhecimento, pois normalmente é difícil capturar a dinâmica desses processos através de técnicas tradicionais de modelagem de processos. Outro problema é quando se busca padronizar processos intensivos em conhecimento correndo-se o risco de limitar em demasia a criatividade na execução do processo e reduzir a criação de valor. Portanto, é importante que os processos intensivos em conhecimento sejam corretamente identificados e tratados com técnicas adequadas para que a transformação não resulte em mais danos do que benefícios. O aumento da necessidade por um melhor tratamento de processos intensivos em conhecimento tem estimulado o surgimento de abordagens especializadas, tais como processos declarativos centrados em objetos e gerenciamento adaptativo de caso.

CBOK 3.0.

Simple business process model with role information

Internal structure of value chain

Message-oriented Middleware

Evolution of Enterprise Systems Architectures

Roger Waters The Wall Official Trailer 1 (2015) - Documetary HD

Business process lifecycle

Estimate uncertainty

An Interactive Life Cycle

Iterative-incremental Development and the Rational Unified Process

Changing focus across the RUP lifecycle

Managing requirements

Example elicitation and analysis methods

Pragmatic Thinking and Learning - 48 Tips

1. Always consider the context.
2. Use rules for novices, intuition for experts.
3. Know what you don’t know.
4. Learn by watching and imitating.
5. Keep practicing in order to remain expert.
6. Avoid formal methods if you need creativity, intuition, or inventiveness.
7. Learn the skill of learning.
8. Capture all ideas to get more of them.
9. Learn by synthesis as well as by analysis.
10. Strive for good design; it really works better.
11. Rewire your brain with belief and constant practice.
12. Add sensory experience to engage more of your brain.
13. Lead with; follow with.
14. Use metaphor as the meeting place betweenand.
15. Cultivate humor to build stronger metaphors.
16. Step away from the keyboard to solve hard problems.
17. Change your viewpoint to solve the problem.
18. Watch the outliers: “rarely” doesn’t mean “never.”
19. Be comfortable with uncertainty.
20. Trust ink over memory; every mental read is a write.
21. Hedge your bets with diversity.
22. Allow for different bugs in different people.
23. Act like you’ve evolved: breathe, don’t hiss.
24. Trust intuition, but verify.
25. Create SMART objectives to reach your goals.
26. Plan your investment in learning deliberately.
27. Discover how you learn best.
28. Form study groups to learn and teach.
29. Read deliberately.
30. Take notes with bothand.
31. Write on: documenting is more important than documen- tation.
32. See it. Do it. Teach it.
33. Play more in order to learn more.
34. Learn from similarities; unlearn from differences.
35. Explore, invent, and apply in your environment—safely.
36. See without judging and then act.
37. Give yourself permission to fail; it’s the path to success.
38. Groove your mind for success.
39. Learn to pay attention.
40. Make thinking time.
41. Use a wiki to manage information and knowledge.
42. Establish rules of engagement to manage interruptions.
43. Send less email, and you’ll receive less email.
44. Choose your own tempo for an email conversation.
45. Mask interrupts to maintain focus.
46. Use multiple monitors to avoid context switching.
47. Optimize your personal workflow to maximize context.
48. Grab the wheel. You can’t steer on autopilot.

Project knowledge over time

This is your brain

Skill distribution

Dreyfus model of skill acquisition

5 coisas que os Estoicos podem te ensinar sobre desenvolvimento de software

1. Vire o obstáculo de cabeça para baixo

“Escolha não ser prejudicado e você não se sentirá prejudicado. Não se sinta prejudicado e você não o será” – Marco Aurélio

Os estoicos tinham um exercício chamado “Virando o obstáculo de cabeça para baixo”, no qual eles simplesmente tentavam ver o problema de um ângulo diferente, que é benéfico para você. Por exemplo: back-end não é seu negócio, mas sua empresa precisa de alguém que desenvolva em Java. Você pode enxergar essa situação como um obstáculo ou como uma oportunidade para aprender uma coisa nova.

2. Você tem muito tempo

“Não é que nós temos pouco tempo para viver, é que nós desperdiçamos um monte dele. A vida é longa o suficiente, e uma quantidade generosa é dada a nós para atingirmos as maiores conquistas se investirmos bem. Mas quando desperdiçamos tempo em luxo desnecessário e em atividades que não são boas, nós somos forçados pela limitação da morte a entender que tudo passou antes que nós percebêssemos que estava passando. Então é isso: não temos uma vida curta, nós a tornamos curta, e nós não somos mal suportados, nós é que desperdiçamos tempo… A vida é longa se você sabe como usá-la” – Sêneca

Eu concordo que às vezes seu chefe pode criar deadlines difíceis. Mas na maior parte do tempo, os desenvolvedores de software reclamam sem entender que eles não estão usando o seu tempo bem o suficiente. Fatores externos, como deadlines, não são sua culpa. Mas ser improdutivo é totalmente culpa sua.

3. Sem falha não há crescimento

“O que aconteceu com você o impediu de: agir com justiça, generosidade, autocontrole, sanidade, prudência, honestidade, humildade, simplicidade e todas as outras qualidades que permitem a natureza de uma pessoa para se satisfazer? Então, lembre deste princípio quando algo ameaçar te causar dor: a coisa em si não é de todo ruim, passar por ela e sobreviver é a grande sorte” – Marco Aurélio

Projetos podem dar errado, seu código pode levar a uma perda enorme de dinheiro ou você pode ser demitido, mas você tem que saber que existe vida depois do fracasso. E não é só isso, mas com o pensamento certo, quando você se recuperar de cada fracasso você estará mais forte e pronto para brilhar de novo. Lembre-se de que se você não está fracassando, você não está crescendo.

4. Não apenas leia. Pratique.

“Não diga apenas que você leu livros, mostre que por meio deles você aprendeu a pensar melhor e a ser uma pessoa mais reflexiva e sensata. Livros são os halteres da mente. Eles são muito úteis, mas seria um erro supor que alguém progrediu apenas por internalizar seu conteúdo”. – Epiteto

Ler é ótimo, especialmente para aprender por meio dos erros de outras pessoas. Mas ler, apenas, sem aplicar o que você leu, é um completo desperdício de tempo. Eu tenho visto muitos desenvolvedores lendo posts em blog, livros e outros tipos de conteúdo mas não aplicando quase nada disso. O propósito da educação é internalizar conhecimento, mas definitivamente é necessário tomar alguma atitude a partir disso.

5. Aprenda a lidar com as pessoas

“Comece todos os dias dizendo para si mesmo: hoje eu devo encontrar interferência, ingratidão, insolência, deslealdade, má vontade e egoísmo – tudo isso por causa da ignorância das pessoas em saber o que é bom ou ruim” – Marco Aurélio

A parte mais difícil do desenvolvimento de software com certeza não são questões técnicas, mas como lidar com as pessoas. Os estoicos lidam com esse tipo de adversidade usando uma prática chamada de “premeditar as expectativas”: todas as manhãs você deve acordar, sentar silenciosamente e ser muito pessimista. Dessa forma você já estará mentalmente preparado para as adversidades que te acontecerem e eles não te afetarão tanto.

Em resumo, o estoicismo nos ensina a não lutar com a natureza das coisas. Ao invés de investirmos energias em coisas que não conseguimos mais mudar ou de tentarmos evitar o inevitável podemos nos concentrar em ter a mente tranquila para a transposição dos obstáculos. A natureza do mundo de desenvolvimento de produtos digitais pode ser muito severa para os olhos de uns, porém, com o treinamento mental e preparação comportamental podemos nos tornar mais fortes para as adversidades.

Fonte: http://blog.concretesolutions.com.br/2015/11/estoicos-e-software/

Agile Methodology - Roger Pressman

The infamous three circles of information architecture

How to Solve Missing Values

1. Ignore the tuple: This is usually done when the class label is missing (assuming the mining task involves classification). This method is not very effective, unless the tuple contains several attributes with missing values. It is especially poor when the percent- age of missing values per attribute varies considerably.
2. Fill in the missing value manually: In general, this approach is time-consuming and may not be feasible given a large data set with many missing values.
3. Use a global constant to fill in the missing value: Replace all missing attribute values by the same constant, such as a label like “Unknown” or −∞. If missing values are replaced by, say, “Unknown,” then the mining program may mistakenly think that they form an interesting concept, since they all have a value in common—that of “Unknown.” Hence, although this method is simple, it is not foolproof.
4. Use the attribute mean to fill in the missing value: For example, suppose that the average income of AllElectronics customers is $56,000. Use this value to replace the missing value for income.
5. Use the attribute mean for all samples belonging to the same class as the given tuple: For example, if classifying customers according to credit risk, replace the missing value with the average income value for customers in the same credit risk category as that of the given tuple.
6. Use the most probable value to fill in the missing value: This may be determined with regression, inference-based tools using a Bayesian formalism, or decision tree induction. For example, using the other customer attributes in your data set, you may construct a decision tree to predict the missing values for income.

Mean, median, and mode of symmetric versus positively and negatively skewed data

Quality decisions must be based on quality data

Data preprocessing is an important step in the knowledge discovery process, because quality decisions must be based on quality data. Detecting data anomalies, rectifying them early, and reducing the data to be analyzed can lead to huge payoffs for decision making.

MVP

Barcelona Embraces IoE to Create a Smart City

Cubes and Their Components

Dimensions are strings; measures are numbers.

Domain Driven Design

The ultimate purpose of software is to serve users. But first it has to serve developers. This is especially true in a process that emphasizes refactoring. As the program evolves, developers will rearrange and rewrite every part. They will integrate the domain objects into the application and with new domain objects. Even years later, maintenance programmers will be changing and extending the code. People have to work with this stuff.

Domain Driven Design

When a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of MODEL-DRIVEN DESIGN – that the model supports an effective implementation and abstracts key insights into the domain – is half gone, and the resulting models will be impractical. Meanwhile, if the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Finally, the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a MODEL-DRIVEN DESIGN.

Decisão

Decidir implica optar por uma alternativa de ação em detrimento de outras disponíveis, em função de preferências, disponibilidades, grau de aceitação do risco etc. Nessa visão, decidir antecipadamente constitui-se em controlar o seu próprio futuro. Essa é uma visão bastante proativa no que se refere ao processo de gestão de certa organização. (ANSOFF, 1977, p.4).

Mapas

"Não nascemos com mapas. Temos de desenhá-los, e esse desenho requer esforço. Quanto mais esforço fizermos para apreciar e perceber a realidade, maiores e mais detalhados serão nosso mapas. Mas muitos não querem fazer esse esforço. Seus mapas são pequenos e incompletos, suas visões do mundo, estreitas e ilusórias"

M Scott Peck

Tim Minchin - The Fence

Donkey Kong Country - Aquatic Ambience

Urban computing

Urban computing is a process of acquisition, integration, and analysis of big and hetero- geneous data generated by diverse sources in urban spaces, such as sensors, devices, ve- hicles, buildings, and humans, to tackle the major issues that cities face (e.g., air pollu- tion, increased energy consumption, and traffic congestion).

I have stood on the shoulders of giants

"Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central problem we face in all of computer science is how we are to get to the situation where we build on top of the work of others rather than redoing so much of it in a trivially different way. Science is supposed to be cumulative, not almost endless duplication of the same kind of things".

Richard Hamming 1968 Turning Award Lecture 

Solitude

My name it means nothing, my fortune is less My future is shrouded in dark wilderness Sunshine is far away, clouds linger on Everything I posessed, now they are gone  Oh, where can I go to and what can I do? Nothing can please me only thoughts are of you You just laughed when I begged you to stay I've not stopped crying since you went away  The world is a lonely place, you're on your own Guess I will go home, sit down and moan Crying and thinking is all that I do Memories I have remind me of you

The Decision Hierarchy

Decision Essentials

Beckett - A Rainbow's Gold (Old Grey Whistle Test 1974)

Karn Evil 9 - Emerson, Lake & Palmer

Emerson, Lake & Palmer - Lucky Man

Triumvirat - Spartacus

Twisted Sister - We're Not Gonna Take It

Iron Maiden - For The Greater Good Of God - piano cover

Effective Java (Remarked) - Serialization

Item 74: Implement Serializable judiciously (design, portability, performance, scalability)

A major cost of implementing Serializable is that it decreases the flexi- bility to change a class’s implementation once it has been released. A second cost of implementing Serializable is that it increases the likeli- hood of bugs and security holes. A third cost of implementing Serializable is that it increases the testing burden associated with releasing a new version of a class. Implementing the Serializable interface is not a decision to be under- taken lightly. Classes designed for inheritance should rarely implement Serializable, and interfaces should rarely extend it. Inner classes (Item 22) should not implement Serializable. To summarize, the ease of implementing Serializable is specious. Unless a class is to be thrown away after a short period of use, implementing Serializ- able is a serious commitment that should be made with care. Extra caution is war- ranted if a class is designed for inheritance. For such classes, an intermediate design point between implementing Serializable and prohibiting it in sub- classes is to provide an accessible parameterless constructor. This design point permits, but does not require, subclasses to implement Serializable.

When use? always.

Item 75: Consider using a custom serialized form (design, portability, performance, scalability)

Do not accept the default serialized form without first considering whether it is appropriate. The default serialized form is likely to be appropriate if an object’s phys- ical representation is identical to its logical content. Even if you decide that the default serialized form is appropriate, you often must provide a readObject method to ensure invariants and security. To summarize, when you have decided that a class should be serializable (Item 74), think hard about what the serialized form should be. Use the default serialized form only if it is a reasonable description of the logical state of the object; otherwise design a custom serialized form that aptly describes the object.

When use? always.

Item 76: Write readObject methods defensively (design, portability, performance, scalability)

When an object is deserialized, it is critical to defensively copy any field containing an object reference that a client must not possess. To summarize, anytime you write a readObject method, adopt the mind-set that you are writing a public constructor that must produce a valid instance regard- less of what byte stream it is given. Do not assume that the byte stream represents an actual serialized instance. 

When use? always.

Item 77: For instance control, prefer enum types to readResolve (design, portability, performance, scalability)

To summarize, you should use enum types to enforce instance control invariants wherever possible. If this is not possible and you need a class to be both serializable and instance-controlled, you must provide a readResolve method and ensure that all of the class’s instance fields are either primitive or transient.

When use? always.

Item 78: Consider serialization proxies in stead of serialized instances (design, portability, performance, scalability)

In summary, consider the serialization proxy pattern whenever you find your- self having to write a readObject or writeObject method on a class that is not extendable by its clients. This pattern is perhaps the easiest way to robustly serialize objects with nontrivial invariants.

When use? always.

Effective Java (Remarked) - Concurrency

Item 66: Synchronize access to shared mutable data (stability)

In summary, when multiple threads share mutable data, each thread that reads or writes the data must perform synchronization. Without synchronization, there is no guarantee that one thread’s changes will be visible to another. The penalties for failing to synchronize shared mutable data are liveness and safety failures. These failures are among the most difficult to debug. 

When use? when you need to avoid dirty-reads.

Item 67: Avoid excessive synchronization (stability, performance)

As a rule, you should do as little work as possible inside synchronized regions. Obtain the lock, examine the shared data, transform it as necessary, and drop the lock. 

When use? always in threads that you do not need to avoid dirty-reads.

Item 68: Prefer executors and tasks to threads (design, stability)

The Executor Framework also has a replacement for java.util.Timer, which is ScheduledThreadPoolExecutor. While it is easier to use a timer, a scheduled thread pool executor is much more flexible. A timer uses only a single thread for task execution, which can hurt timing accuracy in the presence of long- running tasks. If a timer’s sole thread throws an uncaught exception, the timer ceases to operate. A scheduled thread pool executor supports multiple threads and recovers gracefully from tasks that throw unchecked exceptions.

When use? always.

Item 69: Prefer concurrency utilities to wait and notify (design, stability)

In summary, using wait and notify directly is like programming in “concurrency assembly language,” as compared to the higher-level language provided by java.util.concurrent. There is seldom, if ever, a reason to use wait and notify in new code. If you maintain code that uses wait and notify, make sure that it always invokes wait from within a while loop using the standard idiom. The notifyAll method should generally be used in preference to notify. If notify is used, great care must be taken to ensure liveness.

When use? always.

Item 70: Document thread safety (design, readability)

To summarize, every class should clearly document its thread safety proper- ties with a carefully worded prose description or a thread safety annotation. The synchronized modifier plays no part in this documentation. Conditionally thread-safe classes must document which method invocation sequences require external synchronization, and which lock to acquire when executing these sequences. If you write an unconditionally thread-safe class, consider using a private lock object in place of synchronized methods. This protects you against synchronization interference by clients and subclasses and gives you the flexibility to adopt a more sophisticated approach to concurrency control in a later release.

When use? always.

Item 71: Use lazy initialization judiciously (performance, stability, scalability)

In summary, you should initialize most fields normally, not lazily. If you must initialize a field lazily in order to achieve your performance goals, or to break a harmful initialization circularity, then use the appropriate lazy initialization technique. For instance fields, it is the double-check idiom; for static fields, the lazy initialization holder class idiom. For instance fields that can tolerate repeated ini- tialization, you may also consider the single-check idiom.

When use? it depends pretty of context. Is hard to define when.

Item 72: Don’t depend on the thread scheduler (design, stability, readability)

In summary, do not depend on the thread scheduler for the correctness of your program. The resulting program will be neither robust nor portable. As a corollary, do not rely on Thread.yield or thread priorities. These facilities are merely hints to the scheduler. Thread priorities may be used sparingly to improve the quality of service of an already working program, but they should never be used to “fix” a program that barely works.

When use? always.

Item 73: Avoid thread groups (design)

To summarize, thread groups don’t provide much in the way of useful functionality, and much of the functionality they do provide is flawed. Thread groups are best viewed as an unsuccessful experiment, and you should simply ignore their existence. If you design a class that deals with logical groups of threads, you should probably use thread pool executors.

When use? always.