Commercial For Driverless Car

21. July, 2015

A man stumbles our of a bar with his friend. They are both very drunk. Laughing, they cross the street and approach a long row of cars parked on the curb. In the next scene, one of them is talking to two police officers.

«Had a lot?»

The man fumbles with his car keys. «Yup. Stay away from me, no alcohol on shift!»

The police officers laugh and watch the man crawl into his car which is parked on a long row of cars at the side of the street. The man starts to sing “Home sweet home, take me home.”

Further down the street, his friend tries to get into another car. The police officers look at each other.

«Had a lot?» they ask the second man.

«What? Oh, well, no … not … that … mush.»

The police officers arrest him. He struggles: «Leave me alone! What are you doing? Why arrest me and let my friend go?» While they put handcuffs on him, the first car moves silently out on the street.

Just as it vanished behind a truck, the police offers drag the struggling man along the front of the track.

For a long moment, the truck blocks the view.

The camera slowly moves along the truck until you can see along its front.

The light of the car on the street illuminate the legs of the men. The light is moving and so is the car.

The driver can be seen laughing and dancing in his car, apparently neither of his hands is on the wheel.

His car is slowly stopping. The police drag the man over the street. The car moves on, takes a turn.

Black screen with message: Driver-less cars makes drinking more fun for you and everyone.

Related:


TNBT – Creating Tests from the Debugger

20. July, 2015

From my series “The Next Best Thing“:

Often, you will find yourself in a debugger, trying to follow some insanely complicated code to find the root cause of a bug.

I would like to see a button in my IDE which reads “New Test Case”. It should example the current program state, determine (with my help) what part of the code I want to test and then copy the current state into a unit test. In a second step, I could then trim down the unit tests but I would have all the input, all necessary dependencies would be there, correctly initialized.

It would also be great if the IDE would track the state of the code from which the unit test was generated. If the code changes too much (indicating that the unit test might become outdated), I’d like to see that. Or maybe the IDE could figure out by itself when code tested in such a way deviates “too much.”

Along the same lines, the IDE should be able to inject probes into the product code. As I click buttons and enter data in the UI, the IDE should generate a series of unit tests under the hood as described here. If you’re using frameworks like Spring, the tests should come with minimal (or mocked) dependencies.


Replacing Integration With Unit Tests

15. July, 2015

Google asks to “Just Say No to More End-to-End Tests” – just go and read it.

The suggestion in the document is to have a testing pyramid. A few (slow, expensive, dangerous) End-to-End (E2E) tests, more integration tests (IT) and a whole lot of unit tests.

My approach is to aim for 100% unit tests by breaking down the E2E and integration tests into chains of unit tests.

Example: You want to test whether you can save a UI field in a database.

The naive approach would be to create the UI, create a DB, simulate user input, click the save button, check the data in the database, update the UI afterwards.

My approach is to cut this into individual steps and use the output of test X as input for X+1. For unit tests, output is always a constant, so this doesn’t create dependencies between the tests except for the fact that some are the logical next steps. Tests can still be executed in any order.

But back to the example. The first set of tests would put various values in the UI, simulating user input. The tests would just read the values from the fields and compare them against expected values.

The next set of tests would be for the input validation. These tests would reuse some of the “expected output” values from the previous tests. No UI would be necessary (the code to test the display of validation messages would be in another set). We’re only interested in “do we get the correct error for input value FOO” where FOO is a constant.

The input validation tests can be grouped into two sets: One where the input value passes the validation and another (probably a much bigger) where the validation fails.

For all the inputs where the validation succeeds, we write a test that writes this value (again taken from a constant) into the database.

Lastly, to update the UI, we write a set of tests which examine the state of the database. And another set which tests that a certain state appears correctly in the UI.

As you can see, at no time we have a runtime dependency of tests. Tests work in any order. If the output of one test changes, only a small number of tests need to be updated (if at all). The IDE will help you locate all tests which are connected.

Instead of using the constant directly in an assert inside of a test, you can refer to it from an annotation. Now you can write tests that make sure that an output value is also used as an input somewhere.

If a test fails, only a single test fails. If the validation changes and a value isn’t valid anymore, the DB test might still pass. This is good: We don’t want code to fail unless it’s really broken. The DB interface might be able to write “illegal” values into the database but the validation layer is responsible to catch them. Don’t mix responsibilities.

In E2E or integration tests, a single failure somewhere in the whole chain of operations breaks the whole test. With the approach outlined above, a single failure just breaks very few tests. Each test still runs only a small number of code lines, making it easier to locate the cause of the problem. Tests are fast, you can run tests for a subset of the chain – why test the database when you’re improving validation? Or start the whole UI? You can run fast tests all the time and mark slow ones (UI, DB) for “run only on CI server“.


Installing Epson Perfection V300 Photo on openSUSE 13.2

3. July, 2015

Locate Linux drivers on http://download.ebz.epson.net/dsc/search/01/search/?OSC=LX
Search for “v300″

The search gives two results:

  1. “iscan plugin package” from 2011
  2. “core package&data package” from 2015

You need both. The first one is esci-interpreter-gt-f720-0.1.1-2.* which is a necessary plugin for iscan to enable the software to talk to the scanner via USB. Without it, you get odd “Permission denied” errors and “scanimage --list-devices” will come back with “No scanners were identified.”

Then get iscan-2.30.1-1.usb0.1.ltdl3.x86_64.rpm (not sure what those files with a ~ in the name at the top are) plus iscan-data-1.36.0-1.noarch.rpm from the second search result.

Install all three of them at the same time.

Both scanimage and xsane should now be able to detect and use the scanner.

Related:


Is Climate Change Just A Lot Of Hot Air?

26. June, 2015

A thought-provoking video by MinuteEarth:


The Quest to End Poverty

25. June, 2015

Poverty is a huge problem, even for those not affected. At best, the sight is disturbing, at worst, the sicknesses bred by many people crammed together don’t care much for bank accounts – even when it might help that you can pay doctor’s bills and meds.

In 2011, over $150 billion were spent on development aid. That sum sounds staggering if you look at the number alone. Keep in mind that the world’s GDP in 2011 was 75’621 billion (use the table view to see per country numbers) – aid is 0.2% of that. The US military budget alone was $610 billion. World-wide aid was just a quarter of what the US spends on its military.

What’s more, a lot of that money never leaves the donor country – it’s used to “pay” for debt which the receiving country already has towards the donor – or it’s vouchers for goods which the donor produces (like guns and other military equipment). As odd as that may sound at first: Development aid is often another tool to develop your own country. If it helps a struggling third world place, all the better.

But the problem runs deeper. Too deep to explain in a blog post but TED compiled a list of 11 through provoking talks how we could end poverty. My favorite didn’t make it into the list: Gary Haugen: The hidden reason for poverty the world needs to address now.

Think!


SoCraTes Day: Testing the Impossible

21. June, 2015

I’m back from SoCraTes Day Switzerland where I help a Code&Hack session called “Testing the Impossible”.

The session is based on this Mercurial repository de.pdark.testing.

Transcript

  • 20150619_105103-socrates-day-testing-the-impossible-page1Space Shuttle – They Write the Right Stuff
    • Why wasn’t the bug caught by QA?
    • Why did the bug escape dev?
  • Personal Bug Diary
  • Team Culture: Strengths va. Blame Game
  • Miscommunication with Customers
  • Anyone can press the “Red Button
  • Make failures cheap. Fail fast.
  • I’m wrong. I have learned something.
  • Bug-.hunting takes time and mindshare.
  • If you found a bug, write a test for it

How do I test randomness?

  1. Test small pieces
  2. Fix things that varies (IDs, timestamps, etc.)

How do I test a DB?

  • 20150619_105103-socrates-day-testing-the-impossible-page2Layer between DB and App code which allows to switch between real DB and mock
  • Verify generated SQL instead of executing it
    • Fast
    • Allows to test thousands of combinations easily
    • Useful for code that builds search queries
  • Run SQL against real DB during the night (CI server)
  • H2 embedded DB can emulate Oracle, MySQL, PostgreSQL, …
  • Test at various depths (speed vs. accuracy)
  • Testing Walrus dives deep!

Follow

Get every new post delivered to your Inbox.

Join 343 other followers