• Being able to communicate ideas > Being a great technical developer -

• For every great developer that's an asshole, you can find a great developer that won't be an asshole. Don't keep assholes. Google the "no asshole rule". -

• Making the team feel safe to discuss stuff they don't know freely and ask questions that might seem stupid in other teams makes for a great team that's not afraid to challenge assumptions and break through with new skills. -

• TDD is a skill just like refactoring. Learn when it makes sense.

• 80% of architects in enterprise don't have the skills needed from them. including the things stated above.

• Learning the Theory of Constraints and applying it to find bottlenecks in the process, pipelines and structures of your teams/projects is one of the most useful things you can apply to become more productive. -

• Learning what to measure and what not to measure, lagging vs leading indicators can help you communicate to management about what changes truly need to happen to make your team work more effectively. -

• Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't.
  

;TLDR:

sudo codesign --remove-signature /Applications/Skype\ for\ Business.app/

The Long Version:

On Mac OS X 1. Close Skype App 2. Open Terminal (if you don't have XCode Installed, do items 3 and 4)

3. run

Xcode-select --install 

4. install and update Xcode

Most important part:

5. run

sudo codesign --remove-signature /Applications/Skype\ for\ Business.app/

When Done:

• ou will lose your Skype settings.

• when Skype is started the first time you need to enter your admin password and hit "always permit".

• After that you are able to access your virtual cameras again.

cd /etc/pihole
sudo service pihole-FTL stop
sudo mv pihole-FTL.db pihole-FTL.db.old
sudo service pihole-FTL start

I’m sharing here what I’ve learned the hard way. This has now helped me when teaching half day remote classes about TDD:

1. Go into zoom settings

2. Under “Screen Share” -> Advanced -> Screen Capture Mode

3. Set Screen Capture Mode to “Previous Operating Systems”

Also: You might also want to set “Limit your screen share to 8 frames per second” but it has worked well for me without it. even when live-coding, both sharing a screen and an individual app.

OK. We’re all stuck at home (or will be soon). COVID19 is wreaking havoc on our economy and our way of living. It’s pretty intense, but it’s also a time, for those of us who can do it, to grow and learn new skills, get out of our comfort zone and use our time indoors to try to be at least somewhat productive.

Here’s my part in helping people stay indoors: until further notice, all my existing online courses are free for everyone who’s interested. Simply go to the COVID19 ALL-IN bundle and sign up.

You’ll get streaming and download access to all the content.

Some of the content there:

• TDD in Java, C# and Ruby based on Art of Unit Testing

• Legacy Code Refactoring for Unit Testing (C#)

• Pairing Videos on TDD (C#)

• More..!

I’ll disable this probably in a month or two, we’ll see. But take your time. Once you get the bundle, the content will be yours FOREVER. even after I have disabled purchasing it for free. so don’t worry about going slow.

Also, consider signing up for my daily corona dev stream where I work on the upcoming next version of my book, art of unit testing 3rd edition, live:

Have fun, stay safe, stay indoors, and spread knowledge, not the virus.

Yes that also means you can apply the term ‘unit of work’ to higher level abstractions, as well as use these terms when discussing integration, API and end-to-end tests. We’re focusing on the unit testing side.

Definition : Unit of Work

A unit of work is the sum of actions that take place between the invocation of an entry point up until a noticeable end result through one or more exit points. The entry point is the thing we trigger. Given a publicly visible function, for example:

The function’s body is all or part of the unit of work.

The function’s declaration and signature are the entry point into the body.

The resulting outputs or behaviors of the function are its exit points.  

Entry Points & Exit Points

A unit of work always has an entry point and one or more exit points.

It might be useful to give a quick real-world example, or use case, of what you mean by a unit of work. It seems to me the term could span several different components, and it might be helpful to ground it in a real-world concept.

A unit of work can be a single function, multiple functions, multiple functions or even multiple modules or components. But it always has an entry point which we can trigger from the outside (via tests or other production code), and it always ends up doing something useful. If it doesn’t do anything useful, we might as well remove it from our codebase.

What’s useful? Something publicly noticeable happens in the code: A return value, state change or calling an external party. Those noticeable behaviors are what I call exit points. Listing 1.1 will show a simple version of a unit of work.

Why “exit point”?

Why “exit point” and not something like “behavior”?. My thinking is that behaviors can also be purely internal. We’re looking for externally visible behaviors from the caller. That distinction might be difficult to differentiate during “live action” coding. Also, “exit point” has the nice connotation to it that suggests we are leaving the context of a unit of work and going back to the test context. Behaviors might be a bit more fluid than that. That said, I’m not sure. Perhaps this will change in the 4th edition of my art of unit testing book…

Here’s a quick code example of a simple unit of work.

const sum = (numbers) => {
    const [a, b] = numbers.split(',');  
    const result = Number.parseInt(a, 10) + Number.parseInt(b, 10);  
    return result;
};

This unit of work is completely encompassed in a single function. The function is both the entry point, and because its end result returns a value, it also acts as the exit point. We get the end result in the same place we trigger the unit of work, so we can describe it such that the entry point is also the exit point.
If we drew this function as a unit of work, it would look something like this:

I used “sum(numbers)” as the entry point and not “numbers” because the entry point is the function signature. The parameters are the context or input given through the entry point. 

Here’s a variation of this idea:

A Unit of work has entry points and exit points:

let total = 0;
const totalSoFar = () => {
  return total;
};

const sum = (numbers) => {
  const [a, b] = numbers.split(',');
  const result = Number.parseInt(a, 10) +
            Number.parseInt(b, 10);
  total += result;
  return result;
};

module.exports = {
  sum,
  totalSoFar
};

This new version of sum has two exit points. It does two things:

1.     It returns a value

2.     it has new functionality: it has a running total of all the sums. It sets the state of the module in a way that is noticeable (via totalSoFar() ) from the caller of the entry point.

You can think of these two exit points as two different paths, or requirements from the same unit of work, because they indeed are two different useful things the code is expected to do.

It also means I’d be very likely to write two different unit tests here: one for each exit point. Very soon we’ll do exactly that.

What about totalSoFar()? Is this also an entry point? Yes, it could be. IN a separate test. I could write a test that proves that calling totalSoFar() without triggering prior to that call returns 0. Which would make it its own little unit of work. And would be perfectly fine. Often one unit of work (sum()) can be made of smaller units. This is where we can start to see how the scope of our tests can change and mutate, but we can still define it with entry points and exit points.

Entry points are always where the test triggers the unit of work. You can have multiple entry points into a unit of work, each used by a different set of tests.

A side note on design

In terms of design, you can also think of it like this. There are two main types of actions: “Query” actions, and “Command” functions. Query actions don’t change stuff, they just return values. Command actions change stuff but don’t return values.

We often combine the two but there are many cases where separating them might be a better design choice. This post isn’t primarily about design, but I urge you to read more about the concept of command-query separation over at Martin Fowler’s website: https://martinfowler.com/bliki/CommandQuerySeparation.html  

Exit points often signify requirements and new tests, and vice versa

Exit points are end results of a unit of work.  For Unit Tests, I usually write at least one separate test, with its own readable name, for each exit point. I could then add more tests with variations on inputs, all using the same entry point, to gain more confidence.

Integration tests, on the other hand, will usually include multiple end results since it could be impossible to separate code paths at those levels. That’s also one of the reasons integration tests are harder to debug, get up and running, and maintain: they do much more than unit tests, as we’ll soon see.

Back to the code:

Here’s a third version of this function :

const winston = require('winston');
let total = 0;

const totalSoFar = () => {
  return total;
};

 
const makeLogger = () => {
  return winston
    .createLogger({
      level: 'info',
      transports: new winston.transports.Console()
    });
};

const logger = makeLogger();
const sum = (numbers) => {
  const [a, b] = numbers.split(',');
  logger.info(
    'this is a very important log output',
    { firstNumWas: a, secondNumWas: b });
  const result = Number.parseInt(a, 10) + Number.parseInt(b, 10);
  total += result;
  return result;
};

module.exports = {
  totalSoFar,
  sum
};

 You can see there’s a new exit point/requirement/end result in the function. It logs something to an external entity. It could be a file, or the console, or a database. We don’t know, and we don’t care.

This is the third type of an exit point: calling a third party. I also like to call it “calling a dependency”.

A Dependency (3rd party)

A dependency is something we don’t have full control over during a unit test. Or something that, to try to control in a test, would make our lives miserable to get up and running, maintain, keep the test consistent, or running fast. Some examples would include: loggers that write to files, things that talk to the network, code controlled by other teams that we cannot change, components that due to the way they function take a very long time (calculations, threads, database access) and more.  The rule of thumb is: “If I can fully and easily control what its doing, and it runs in memory, and its fast, it’s not a dependency”. There are always exceptions to the rule, but this should get you through 80% of the cases at least.

Here's how I’d draw it with all three exit points, and two entry points together:

At this point we’re still just a function-sized unit of work. The entry point is the function call, but now we have three possible paths, or exit points, that do something useful that the caller can verify publicly.

Test Per Exit Point

Here’s where it gets interesting: It’s a good idea to have at least one separate test per exit point. (it might have more than a single assert, but only on the things related to exit point, that would be changing together. This will make the tests more readable, simpler and easier to debug or change without affecting other outcomes.

Exit Point Types

We’ve seen that we have three different types of end results:

Value Based

§  The invoked function returns a useful value (not undefined). If this was in a more static language such as Java or C# we’d say it is a public, non void function.

State Based

§  There’s a noticeable change to the state or behavior of the system before and after invocation that can be determined without interrogating private state. (In our case the wasCalled() function returns a different value after the state change.)

3rd Party

§  There’s a callout to a third-party system over which the test has no control. That third-party system doesn’t return any value, or that value is ignored. (Example: calling a third-party logging system that was not written by you and you don’t control its source code.)

XUnit Test Patterns’ Definition of Entry & Exit Points

The book XUnit Test Patterns discusses the notion of direct inputs and outputs,  and indirect inputs and outputs. Direct inputs  are what I like to call entry points. That book called it “using the front door” of a component. Indirect outputs in that book can be thought of as the other two types of exit points I mentioned (state change and calling a third party).  Both versions of these ideas have evolved in parallel, but the idea of “unit of work” only appears in this book. Unit of work , coupled with “entry” and “exit” points makes much more sense to me that using “direct and indirect inputs and outputs”. Consider this a stylistic choice on how to teach the concept of test scope. You can find more about xunit test patterns at xunitpatterns.com  

Let’s see how the idea of entry and exit points affects the definition of a unit test.

UPDATED DEFINITION of a unit test:

A unit test is a piece of code that invokes a unit of work and checks one specific exit point as an end result of that unit of work. If the assumptions on the end result turn out to be wrong, the unit test has failed. A unit test’s scope can span as little as a function or as much as multiple modules or components depending on how many functions and modules are used between the entry point and the exit point. 

1.2          Different Exit Points, Different Techniques

Why am I spending so much time just talking about types of exit points? Because not only is it a great idea to separate the tests per exit point, but also each type of exit point might require a different technique to test successfully.

·       Return-value based exit points (direct outputs per “xunit patterns”) of all the exit point types, should be the easiest to test. You trigger an entry point, you get something back, you check the value you get back.

·       State based tests (indirect outputs) require a little more gymnastics usually. You call something, then you do another call to check something else (or call the previous thing again) to see if everything went according to plan.

In a third-party situation (indirect outputs) we have the most hoops to jump through. We haven’t discussed the idea yet, that’s where we’re forced to use things like mock objects in our tests so we can replace the external system with one we can control and interrogate in our tests. I’ll cover this idea deeply later in the book.

Which exit points make the most problems?

As a rule of thumb, I try to keep most of my tests either return value based or state based tests. I try to avoid mock-object based tests if I can, and usually I can. As a result I usually have no more than perhaps 5% of my tests using mock objects for verification. Those types of tests complicate things and make maintainability more difficult. Sometimes there’s no escape though, and we’ll discuss them in future posts. 

Disclaimer: written as a stream of though. So might be a bit incoherent.

It’s no secret that in my previous books on unit testing I’ve advocated for an approach to mock objects that is very different from that prescribed in the the “London School of TDD”. Namely, I usually prefer to use mock objects as little as possible, and to verify them only when the expected end result of a unit of work is calling a 3rd party dependency.

The reasons I usually state for this are:

• since mock objects are testing internal interactions, they solidify our internal design so that it is harder to change later on. Internal interactions always result in either state changes, value results or calling a boundary in the system, so let’s use mock objects only on the boundaries. We can still create local wrapper interfaces for those boundaries, but they still represent a boundary dependency.

• mock objects make tests longer and harder to read write and maintain

• It’s easy to test something that has no value in real life by mistake (that my class calls a method on another class… ok. now what?)

This is almost the exact opposite from the recommendations in “Growing Object Oriented Software Guided by Tests” book and from the now famous paper (well, in our little nische anyway) “Mock Roles not Objects” (PDF).

“…We believe the opposite, that Mock Objects are most useful when used to drive the design of the code under test. This implies that they are most useful within the system where the interfaces can be changed. Mocks and stubs can still be useful for testing interactions with third-party code, especially for avoiding test dependencies, but for us this is a secondary aspect to the technique.”

As I’m working on the third edition of art of unit testing these days, I’m revisiting and challenging my thinking. I did read the GOOS book many years ago and I’ve just re-read it with fresher eyes, but also with more experience of my own, and a few thoughts popped into my head. I’m not sure where they lead yet so I’ll just throw them here before I forget:

1. I always say that TDD requires three skills: good tests, test first and design. And I never focus on design. Mock objects (london school) are all about design of objects and dependencies. It could be that when we want to focus more on our design skill we would want to start using more of the london-school style mock objects? That thought scares me a bit because of the maintainability implications, but…

2. maintainability: If we’re using mocks in our tests to drive the design of roles in our objects, we could take several precautions to prevent test maintainability (maybe)

   1. We can use the mock objects in a non strict manner and not verify on them (thish will just force us to think about the internal design). Things like the old NMock and JMock2 were made for that. Any framework with record-replay ability might fit that, but they are getting long in the tooth. AAA frameworks like fake it easy would not help us here because we only define the interactions as part of an assert.

   2. We could write the test, assert on the interactions, and then delete the interaction asserts and leave only the mocks, but treated as stubs. This relaxes our maintainability later on assuming we have non strict mocks

   3. This could be a sign that our design sucks, so we’d need smaller, shorter interfaces in the system or more roles, or add a middle role for multiple dependencies.

3. We could separate the task fo learning design from the other two skills (test-frist, good tests) by choosing when to use london-style mock objects, and use them only in particular cases

4. Boundaries: It’s true that people can mistakenly just fake external interfaces and use them as mocks in the test. I always advocate for creating an internal wrapper interface instead, that w can control. It could be that the way I explained this before could easily be understood as “fake 3rd parties directly”. And that would be unfortunate. I’ll fix that for my 3rd edition. Fake only things that are under your control, or that are not changing. A 3rd party logger can still change (if you change loggers!)

So what am I trying to say here?

• There might be room for london style mocks in my book after all, but it might have taken me 10+ years to realize it, and I’m still not convinced fully. It could be one of the keys to learn about design, but at what cost?

• My biggest fear is that the cost (tests that keep breaking) far outweighs the value we get from the design, and we’ve all seen long horrible tests with long complicated (also internal) dependency chains. The design skill and the skill of stopping and CHANGING the design when the tests go “OUCH” are not a given in many situations, especially enterprise.

• Given the last point, is it worth it to let the london school test driven design idea go with the understanding that the world is mostly not ready for it yet, and will mostly just abuse it?

• Or is it fair to throw it out there so that what I fear will be a select few will end up using it “correctly” but the rest of the world types blindly on the keyboard to produce a franken-test?

Here’s what the paper has to say about this:

“When testing with Mock Objects it is important to find the right balance between an accurate specification of a unit's required behaviour and a flexible test that allows easy evolution of the code base. One of the risks with TDD is that tests become “brittle”, that is they fail when a programmer makes unrelated changes to the application code. They have been over-specified to check features that are an artefact of the implementation, not an expression of some requirement in the object. A test suite that contains a lot of brittle tests will slow down development and inhibit refactoring.

The solution is to re-examine the code and see if either the specification should be weakened, or the object structure is wrong and should be changed. Following Einstein, a specification should be as precise as possible, but not more precise.”

Easier said than done? this paper was written 16 years ago. I’d love to say “people are ready” but I’m not sure yet.

Mainly, I’m not sure whether Nat Pryce and Steve Freeman have new information to share about these ideas since then and if there are any new lessons learned. I’ll ping them and see if they can respond to this blog post.

• Branching Strategies

• Continuous Delivery Metrics

• Engineering Practices & Automation

• Testing & TDD *

• Security Testing & Pipeline Automation *

• Developer Testing *

• Infrastructure as Code *

• Cross Team Collaboration *

• Feature Teams *

• QA/Dev/Sec Automation *

• DevOps, DevSecOps, DevTestOps and others *

• Feature Toggles & Rollouts *

• Pair Programming & Other XP Practices *

• Anything else you think might be interesting

If you live in Israel are in the neighborhood at some point, please consider sharing your knowledge with the CD/XP agile community.

URL to Submit: http://submit.cdxpisrael.com

Here’s what 5 minutes on it got me (I’ll leave the typos in…):

“every time something happens, I tell myself.

Stop. Think. Act. Do. Repeat.

Is that all it takes for something to happen?

Our mind is a fragile thing. It thinks for itself,

but it can also forget itself. It can litellrally forget that it itself, exists. That's crazy, says the mind to itself.

A mind thinking in third person has a funny way of looking at the word.

Here you are, writing a piece of text on a website.

Why? What's the point?

WHat would be lost if you had simply stopped writing?

What does it take for something to stop? to start?

What does it take to look at something, anything, straight in the eyes, and say "that's on me. I'm doing this".

Yes, it was always possibel for us to conjur images of ourslves, the way we'd like the world to see us.

But is it not the word just a bunch of minds looking back at themselves and asking how other minds see THEM instead?

And in that kind of word, that kind of "hell is other people" world, what does it take to be kind? what does kindness even mean?

Is kindness itself self explanatory? Is there a method to this madness of being untruistic? is there some form in which humans and their minds can coexit, side by side? does a body without a mind "exist" ? not being self aware, much like schorodinger's cat: it's possible that that cat was itself not aware it was in a box.

If a box is, but a box is not aware, is it? Is IT really aware of anything inside of it? How the human complexity of the mind fails to capture this sort of unimaginitive dribble down into a human sized piece of dribble..”

I need JS Savvy tech reviewers for the 3rd edition of the book. Apply here, get a free book with your name mentioned in it if your feedback is awesome.

The Rest

Dear Diary. It has been six years since the last edition of Art of Unit Testing. Many things have changed since then, and many have interestingly remained the same.

I’m writing to you today to let you know that I’ve set up with manning to release a 3rd Edition of Art of Unit Testing in the next year. There are quite a few changes to this edition, and the biggest one is that the examples will be in JavaScript. (It would seem the most useful to the most people and a lot of my work these days is centered around that and Java so I think it makes sense).

( I haven’t decided if they should be in plain JS or in Typescript yet. Would love to know what you think in the comments or on twitter.)

So, I need good people to keep me sane as I transform this book into a JS centric one. People to read each chapter and let me know if things don’t make sense, or of my examples suck, or if there are better ways to achieve the same result.

Would you like to be a tech reviewer for this new book?

You’ll get a free copy of the book and a mention inside the book with your name. Also we’ll become great friends and BBQ together every Saturday (If you’re in the tel aviv area).

Fill out this form and I’ll get back to ASAP.

Schedule:

Nothing is written yet. I should have a chapter or two ready in the next month or two. Maybe earlier. I plan to release each chapter separately to the tech reviewers (typos and all) and get some technical feedback on the code samples and ideas. If that sounds like something you might be interested in geeking out on - it’d be a win-win.

Here is the current plan for the revised Table of Contents

Stack used

• WebStorm

• Git

• Jest

• Node

• Typescript?

TOC (many things will change..)

Pre

• What's new in the 3rd edition

• JS

Part 1 - Getting Started

• The Basics of Unit Testing

  • (new) What's in a function?

    • Return value

    • Noticeable State Change

    • Calling a Third Party

  • (new) Entry Points & Exit Points

  • Units & Unit Of Work

  • Properties of a Good Unit Test

• A first Unit Test

Part 2 - Core Techniques

• Using Stubs to Break Dependencies

  • (new) Faking Callbacks

• Interaction Testing using Manual Spies, Mocks

• Isolation (Mocking) Frameworks

• Digging Deeper into Isolation Frameworks

Part 3 - The Test Code

• Test Hierarchies & Organization

• The Pillars of Good Unit Tests

  • (new) Multiple naming conventions

  • (new) Three important pieces of information in a name

Part 4 - Design & Process

• (new) Unit Tests and a Pipeline Driven Culture

• (new) Playing well with others

  • Other types of Tests

  • Using Test Recipes to Prevent Duplication

• (new) Lies, Damned Lies, and Unit Testing Metrics

• Integrating Unit Testing into the organization

• Working with Legacy Code

• (new) Refactoring DOs and DONTs

• (changed) Design & Testability

Appendix - JS Testing Tools & Frameworks

So, if you want to be a tech reviewer on the book: I’m looking for people with good Node.JS/Javascript experience that would be willing to challenge me on technical details and ideas. Go here and submit yourself. https://airtable.com/shrtohxHT8RSsfBLc

The Group’s page is located at CDIsrael.com

If you would like to be a speaker or sponsor, contact me.

AGENDA:
-------------
18:00-18:30 Networking & Pizza
18:30 - 18:40 Goals for CD Israel + Logistics
18:40 - 19:20 Ant Weiss: Optimizing the Delivery Pipeline for Flow
19:20 - 19:30 Break
19:30 - 20:15 TBD - We are looking for one more speaker!

ABOUT:

Continuous Delivery is much more than simply Dev + Ops. It is also tech leads, compliance, security, project managers, scrum masters, architects, and everything in between - let's learn from each other!

We deal with TECHNIQUES, PRACTICES, PROCESSES (and sometimes tools) that enable true continuous delivery - in large and small companies.

We also discuss influencing such change in large and growing organizations.

Bottlenecks & Pipelines: We feel feel pipelines are the core engines that can drive a software company, That Dev, Ops, Test, Sec, compliance should all be working together around common automated pipelines, and the processes, and metrics that push for and against adoption.

Challenges and insights: We will learn from each other about challenges and techniques that enable true continuous delivery.

Great for Ops, Dev, Security, compliance and agile leadership folks (PM, scrum masters, etc)

There are several factors at play:

• People don’t know you for the first few weeks or even months, to invite you into their circles

• There are meetings, shared history, shared chat groups and apps that you might not be part of so you’ll feel like everyone knows something you don’t (and they do)

• There are just times when you’re not working with anyone and you’re working alone.

Be prepared for situations where stuff just happens:

• People going out to lunch without you

• People having meetings without you (that you might contribute to)

• Chasing people to meet that are never available.

• People canceling meetings with you leaving you with nothing to do.

It’s part of that work life and sometimes it just sucks to feel like people are not including you. They might not do it on purpose, they might view you as an “outsider”. They might disagree with your ideas and avoid working with you.

Be prepared for the mental burden of accepting all this, moving on and continuing to push through.

I think that’s the hardest part of the job.

Things that help:

• Let people know you’re free.

• If I feel bad, I look at this post I wrote a long time ago “When I want to five up”

• Find the people who do seek your opinion and work with them. Realize that usually your job is not to “convince” but to “support” someone who is actively trying to become better. Try to work with those people.

• If your job is to “Convince” then realize that 90% of the time you will be working people who disagree with you. Develop a mental “elephant skin” and realize you will finish every day exhausted - but also learning a lot about how to teach and explain the same concept in multiple different ways and levels. THIS WILL MAKE YOU BETTER AT TEACHING.

• Look at past successes and remember how it felt before they succeeded and realize this is the same pattern repeated.

• Find more customers/teams to work with so you can “breath” other mindsets and gain energy to go back to the place where you feel lonely.

• You are not alone in feeling this. I feel like this. SOme weeks it’s 50% of the time. Some weeks is 5% of the time. But I believe all consultants feel it and have to deal with it.

• Some consultants work in teams so they eat together etc.

• Realize that usually if people avoid you it has something to do with what they feel about what THEY should be doing, not what YOU should be doing.

• This (plus your knowledge and expertise) is one of the reasons you get paid more (you do ask for more money than you’d make as a hired person, right?). Not everyone can handle this. It always easier to be “part of a group”.

• Sometimes at some point teams will let you into their inner circles - that’s a great feeling - and it will help make you a better consultant as you’ll be on the inner scoop of things before they happen, at which point you can do something about it.

• Have a life outside of work: spend time with family and friends and bitch to them about your day at work. Spend time with your kids. Have a hobby (I do music) . Don’t let work be the only thing that makes you happy.

That’s my 2 cents. You probably have other , completely different views on the matter. I’m happy to learn! Put it in the comments.

Here’s the list of possible training or consulting topics.

Feel free to contact me any time so we can arrange something with your company.

get-appxpackage messaging | remove-appxpackage

get-appxpackage sway | remove-appxpackage

get-appxpackage commsphone | remove-appxpackage

get-appxpackage windowsphone remove-appxpackage

get-appxpackage phone | remove-appxpackage

get-appxpackage communicationsapps | remove-appxpackage

get-appxpackage people | remove-appxpackage

get-appxpackage zunemusic | remove-appxpackage

get-appxpackage zunevideo | remove-appxpackage

get-appxpackage zune | remove-appxpackage

get-appxpackage bingfinance | remove-appxpackage

get-appxpackage bingnews | remove-appxpackage

get-appxpackage bingsports | remove-appxpackage

get-appxpackage bingweather | remove-appxpackage

get-appxpackage bing | remove-appxpackage

get-appxpackage onenote | remove-appxpackage

get-appxpackage maps | remove-appxpackage

get-appxpackage solitaire | remove-appxpackage

get-appxpackage officehub | remove-appxpackage

get-appxpackage skypeapp | remove-appxpackage

get-appxpackage getstarted | remove-appxpackage

get-appxpackage 3dbuilder | remove-appxpackage

Get-AppxPackage drawboardpdf | Remove-AppxPackage

Get-AppxPackage freshpaint | Remove-AppxPackage

Get-AppxPackage nytcrossword | Remove-AppxPackage

Get-AppxPackage microsoft.xboxapp | Remove-AppxPackage

Get-AppxPackage SurfaceHub | Remove-AppxPackage

Get-AppxPackage flipboard | Remove-AppxPackage

(from source)

You can check out my online Vim course at http://VimHatesYou.com 

Or you can go directly to the course page at http://courses.osherove.com/p/vim-hates-you

• Main website: enterprisedevops.org

• What is Enterprise DevOps?

• Mean time to change
• Mean time to recovery
• Frequency of Release
• Defect Rate

When producing music, it is important that the music sounds good on multiple types of speakers: in your car, in your iphone headphones, on a boom box by the pool,  in a club speaker system etc.

In that regard priducing the music locally on yoru own speakers is much like “works on my machine”.

Producers will usually take the music and test it out manually in various systems, or have multiple sets of monitors, but still test the music in their car, on friend’s systems and more.

There are also “emulators” for sound. There are some software solutions that emulate how your music will sound through different speakers, in different locations , in different file formats (mp3 has less data than a .wav file, wav file, for example.

Nothing beats real work integration testing though. Much like code.

Here are similarities I see between coding and music production so far:

1. Code compiles into binary - midi is rendered into wav files

2. When producing music you need to take many breaks to get your ears “out of the mix” and get your head clear again. The same goes for coding when facing tough creative problems or complicated code.

3. Software culture is moving in the direction of automation and factories, with architectures that support changing things on the fly. Music production has two opposing factions: a. Newer pop songs are made almost in an industrial fashion (try many tracks in a day, find one that works , then lyrics and vocals are found for it from many contenders; and b. singer-songwriter which is all about manually crafting a song which can take a lot of time. (compare that to a hand crafted optimized piece of code that needs to run at a very low level like a DSP unit or real time calculations)

4. Pair-Programming - > most new music these days is not done alone: there are lyric writing teams, melodic writing teams, production teams.

5. in Music, new digital tooling is taking the place of older generation analog tooling. Instead of filling rooms with huge hardware, people use digital work stations with software plugins that emulates almost every piece of hardware out there. Software coding is fully digital, but used to be very hardware oriented . Software testing is still very manual but automation is starting to take its place.

6. Long term support: Software can keep changing after you’ve released it (new features added etc. Music is usually delivered in multiple different versions: radio mix, PG safe mix, club mix etc.. and music also gets remixed, new covers by other bands are made, remakes by the original band in shows, digitally remastered albums… not exactly the same, but in music all the “stems” (the parts that make the individual atoms of the song) are always saved and can be used to recreate different variations of the song.

7. Code has classes and functions, Music production (digital) also has building blocks: Sound designers use waveforms and combine them, munge them up and process them to create new types of sounds that are then reused by other musicians. If a waveform is the input of code, an LFO envelope is a type of function that operates on that code. Those are just two types of the :atoms” of synthesized music)

8. When mixing, it is encouraged to take many breaks (20 minutes mixing, 15 minutes break) so that your ears don’t get too used to the mix. Programming is also a very tough activity that is helped by taking many small breaks.

9. TDD: In music you might have a “reference” mix - a song you like or a sound you want to sound like that tells you how close you are to getting the same results (loudness, frequencies, etc). TDD is the same way somewhat in that you set yourself a target and see if you measure up to it or not. Music is not automated for this though, and is not a any kind of regression test.

10. Music pros do as much integration testing as possible they make their friends, DJS, their mom and their cat hear the mix all the time because they know they are not objective about how it translates in the real world.

11. There’s more but my head is drawn a blank..