Jazoon 2013 – Open Safety For Drones

25. October, 2013

Jazoon 2013 badgeDrones – fully or partially autonomous aircraft – are the second most wide-spread form of private-owned robots today only challenged by room-cleaners. The current estimation is that there are 500’000 drones currently in use. Parrot AR alone sold about 250’000 units. In his talk “Open Safety For Drones,” Lorenz Meier asks important questions about safety, regulation and how this area will develop in the future.

When it comes to safety, then there are two areas: Safety when developing drones and safety when using them. People have started to demonstrate the usual stupidity by flying drones in crowded areas without regard to safety. Lorenz showed a video where an inexperienced controller flew a drone in Manhattan until it crashed into skyscraper and dropped into the streets below. In another example, someone flew a drone through a campus. I say “through” because he went below footbridges that connect the first floor of buildings, eventually passing a bus on the way. The “pilot” also failed to catch the drone after the stunt, crashing it into a hedge.

It will be interesting to see how legal bodies like the FAA respond to things like this.

Despite this, autonomous drones are already useful. A nice example is the new 3D model of the Matterhorn.

A more related issue is the other one: Building safe aircraft. Bugs in a drone can really ruin your day (or life). How can we make sure that hundreds of thousands of lines of code have an acceptable number of bugs?

The issues here are many:

  • If you want to fly an autonomous aircraft, you need to license it.
  • Regulation for drones are non-existing or immature. They might try to handle you like a normal aircraft manufacturer (think Boeing or Airbus). Can you even afford to apply for such a license?
  • You’re using an image recognition software. It uses a math library. In that library, a single line of code has changed. What is the impact on the safety of your drone? How do we bring safety and the need for faster iterations together?
  • Regulators might insist that you license the whole thing again.
  • To get real engineers on your project for a new drone, your API must be really simple. As every seasoned developer knows, nothing is harder than “simple.”

A word on the safety of military drones: Not a single one of them is allowed in civilian airspace. But it’s probably very expensive. Germany spent €562 million to certify the EuroHawk drone. The project was cancelled and the defense minister “referred to the project as being ‘a horror without end'”.

So how can we make a DIY drone ever safe?

There are some approaches:

  1. Involve as many people as possible in a project. Everyone will find something that can be improved.
  2. Allow commercial use of your project. Companies have completely different views on safety than hobbyists.
  3. Collect logs of your flights and share them. Share your project on github and make sure you include the hash of the changeset that was used to run the drone.
    Over time, you can use statistical data to locate even “once in a million years” bugs.

But there are good news, too. With a plane, you have X people on the aircraft and 0 on the ground (most crash in empty areas). With a drone, you have 0 people on the aircraft and X on the ground. But using the laws of physics, it’s pretty simple to estimate the maximum radius that a drone can still travel if it’s “brain” shuts down right now. That means we can test them pretty safely in a virtual cage. Also, since all the components are open, we can run extensive simulations before bringing the thing into the wild.

But the OSS approach also has drawbacks. With OSS, a unit test is easy to write, the test case is known and if something goes horribly wrong, we might experience data loss.

With unmanned systems, the worst case is loss of life. And where do you get your test cases from? How do you plan to test for a broken coil in an actuator? An overheated battery which results in unstable power? Wind gusts? Collisions with birds? Interference with other electrical systems?

Maybe it’s time to open a new field:

Open Safety – Build a safety track record in confined test areas in an open, community-driven process, and only let statistically proven safe systems out of the sandbox. SHARE validation results on the library and version level across systems.

Open Safety Manifesto

  1. Dropping is Free – Ground impact must only damage vehicle
  2. Anytime Shutdown – A separate shutdown unit is present to enforce a drop
  3. Built to Drop – Battery protected against impact, parachutes, etc.
  4. Every Flight is Logged
  5. Every Log is Reviewed – Can be done on Droneshare

State of the Art

Sites like Droneshare have collected so many flight hours for some drones to satisfy normal regulation rules.

Keep in mind that certification alone doesn’t make things safer, they just help to catch the most common errors. Simulations and test protocols improve the situation further. Lastly, lots of people mean that every part is tested in thousands of ways. Software developers know how quickly someone else finds problems with their work (one reason why pairing is so unpopular).

A big problem is YouTube since it teases out the “I more stupid” behavior in humans.

Military (Ab)Use

Another issue is the (ab-)use of this work in military drones used to kill. The scene is aware of this but they currently feel that the good (like cheap access to aerial photography, autonomous mesh networks built by drones in disaster areas) to outweigh the risk. A more visible discussion about OSS and hardware in military projects would be welcome. Some projects forbid military use (Gnutella). It’s worth noting that the US Navy has started to buy Linux based drones. Personally, I find things like the Samsung SGR-A1 military robot sentry (with 5.56 mm robotic machine gun and a grenade launcher) disturbing. Especially when it’s being advertised to be able to “identify and shoot a target automatically from over two miles (3.2 km) away.“

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – How To Do Kick-Ass Software Development

24. October, 2013

Jazoon 2013 badgeOne of the most important aspects of agile is to notice your problems and solve them. How? A good strategy is to look what others did. In “How To Do Kick-Ass Software Development,” Sven Peters shares his experience with “Kick-Ass Software Development at Atlassian” (slides on slideshare, video on vimeo). Yes, he have the talk wearing the “Kick-Ass Super Hero Costume“.

A short refresher what agile aims to be (slide 12):

  • better software
  • less overhead
  • faster development
  • happy customer
  • happy developers

This only works when you continuously improve. Legacy teams, can you hear me?

Kick-Ass Software

But before we can start: How do we know we build the right thing? Bad example: The Microsoft Kin. Never heard of it? They sunk about $1 billion in the project. Makes you wonder how you could miss it, right? (slide 25)

Better solution: Fake it. IBM made extensive experiments with a state-of-the-art speech-to-text system before starting development. How did they do it? They hired an extremely fast typist who remote-controlled word. Cost? Negligible. Result? Text-to-speech won’t sell – people can’t edit the text fast enough using words, they are hoarse after eight hours and the whole thing really breaks down in an open office space. (slide 27)

Use paper prototypes. Something geeks eventually forget: You can drag a piece of paper over a (wooden) desktop just like a window over a screen. (slide 28)

Quick and easy feedback: Easy to find, simple, fast to submit (slide 32). Customers love it! But remember to protect your developers. Gmail uses the “Sh*t umbrella” (slide 38). But not everyone is Google. Put each developer into a support seat once in a while. Not only can they solve problems much more quickly, they also learn to look at their work from the customer perspective (slide 42).

Kick-Ass Team

In most companies, there are way more developers than testers. Atlassian has a ratio of about 13:1. This creates bottlenecks and issues with accountability and scalability (slide 46).

Solutions: Dev X tests features of other devs. (slide 49)

Use “DoTing” – Developers on Test (slides 50 -56):

  • Give developers the same training QA receives
  • Pair testers with devs
  • “Blitz Test” – Once in a while, invite everyone in the company to try the product
  • Use test recipes
  • Split sessions (1 dev and 1 QA test the same feature independently)
  • Bug Hunter (have someone try really hard to break the app)

Remember “Quality is everybody’s responsibility.” (slide 57)

At the Jazoon, the slides about design were skipped due to time constraints.

Again: Department barriers slow you down. Work together as one team! Keep improving! (slide 69, see also: WIKISPEED in “Test First Saves The World”)

Kick-Ass Collaboration

The lonesome cowboy coder is a relic but teams always mean trouble. Interesting video of a heavy-traffic crossing without signals on slide 73. “Traffic Rules protect us from accidents” -> “Development Rules are protecting us from making mistakes”. Like we need a concurrency library in our preferred language, we need a “Fast + Simple Workflow For Parallel Coding.” Otherwise we will be slow and some people will enable their “god mode.” (slide 77)

DVCS make this simple. Create a branch for every task (slide 78). They should have short lives (2 days).

“Pull Requests can improve your code quality” (slide 80). This helps to spread knowledge. But keep an eye on the blame game!

Everyone in the same room would be great but it’s not always possible: People travel. You really want to pull some experts two weeks out of his family? (slide 85) Ask yourself: “Where do I work best?” The answer often is: It depends (slide 86). Make sure people can stay in the zone when they have to.

Make sure you can communicate effectively (slide 87). Emails look great (slide 88) but they cause problems (slide 90). Try chat. Invent your own Portal Device.

Most importantly: Remove friction!

Kick-Ass Automation

Developers automate everything for everyone else. Spend some time each week to automate a menial/manual task for them (slide 101).

4 steps to tame monster builds (slide 104-110):

  1. Instead of having everyone build everything, pass the artifact
  2. Run your tests in parallel. They are independent of each other as they should be, right?
  3. Have a build strategy. How often do you build what part?
  4. Make your stats visible. Use wallboards, information rediators.

Automatically disable flacky tests (113). Use SonarQube and similar tools to detect problematic code. Use Freud to find your own anti-patterns (115).

Finally

Remember managers are also humans (123).

Share stories of success and failure (124).

Remember: To be awesome, you have to step out of your comfort zone (126)

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – User Storytelling: The Lost Art of User Stories

24. October, 2013

Jazoon 2013 badgeIn her talk “User Storytelling: The Lost Art of User Stories“, Ulrika Park (blog, slides on slideshare) made a case to become aware of the spreading practice of “snapshot user stories.” As an example compare “give warrant to use the bonus” (slide 14)  to slide 16:

Elisabeth sees in the MyStore newsletter that she this month has got 12€ in bonus and that she has a total of 16,7€ in bonus on her club card.
E’s husband Claes go to the store. He has a club card too. “You can probably pay with your card” says E.

Claes shops. When he will pays, no bonus is withdrawn from the sum at the cashier.
So he pays the whole sum and gets home. “Strange why can’t I pay with the bonus, how does this work”

E already has a registered user on mystore.se Sometimes she logs in to see her credit card balance.

E logs in and see the saldo “16,7€”. She clicks the balance and enters “events page”

There she sees that she’s bonus owner and that her co-bonuxcollector is Claes.

She gets information that she needs to sign warrant for him and choose the option to print a form.

She choose to print the form, checks Claes, signs the form and goes to the mailbox the day after.

2 weeks later she gets a letter from MyStore that confirms the warrant is verified. A week later Claes goes shopping. This time, the bonus is withdrawn from the total buy.

I think even without the highlighted parts, you can quickly see that the whole story is much richer than the “more efficient snapshots.” Moreover, it helped to expose some critical problems that no one noticed before:

  • Hidden expectations (user must already be registered)
  • This process takes four weeks! Do we really want that?
  • It helps more people. QA will be able to derive test cases from this. Developers will know much better what is expected from them. BAs will know which questions to ask.
  • It’s pretty easy to follow it, even if you’re not a software developer. Remember that these stories were meant as a means to communicate better with customer and managers?

A good story has these properties:

  • A hero
  • A platform
  • An enemy or challenge
  • Emotions (“how does this work?”)
  • Allies (cashier, web site)
  • A mission to accomplish

Everything is held together by a logical sequence of events.

Related articles:

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – Big Data beyond Hadoop – How to integrate ALL your Data

24. October, 2013

Jazoon 2013 badgeBig Data is being used everywhere. Kai Wähner mentioned a couple of examples in his talk “Big Data beyond Hadoop – How to integrate ALL your Data” (slides on slideshare):

Anyone else getting worried by these “success stories”? How do you feel as a mobile customer that your mobile company tries to prevent you from leaving? How about using Big Data to notice bad customer service and prevent making customers unhappy? How do Macy’s competitors feel about this “monitoring”?

Anyway …

One great point was “Silence the HiPPOs” (highest-paid person’s opinion). With the ability “to interpret unimaginable large data stream, the gut feeling is no longer justified!”

Why Big Data? 3 V’s: Volume, Velocity, Variety. But don’t forget the fourth: Value (slide 8)

Before you can start analysis, you need to get the data from somewhere. That usually means integration of a foreign system (reading the data), manipulation of the data (like string to int or date conversion, etc.) and filtering (duplicates, importance, …). See slide 9.

Beware that Big Data is no silver bullet. If you have a gigantic amount of data with poor quality, that will just give you huge problems.

When planning for a Big Data project, begin with a business opportunity (slide 22). Chose the right data (don’t just import everything because you might need it), combine different sources and use easy tooling (slide 26).

Be wary of ETL tools. The network will quickly become your bottleneck.

For the actual implementation, he suggested to look at Apache Camel (slide 34) as a pure integration framework and the talend Open Studio (slide 56) as an example of an integration suite.

1 Comment | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Visibility Shift in Distributed Teams

24. October, 2013

Jazoon 2013 badgeLike many agile tools, distributed teams make problems more visible. Pawel Wrzeszcz listed a couple of those in his talk “Visibility Shift in Distributed Teams” (slides on slideshare) and gave ideas for solutions.

One of the first issues will probably be trust. If “working at home” is believed to be equivalent to “spends add time on Facebook”, you have a trust issue. Managers worry that their “underlings” stop working as soon as they are out of sight, colleagues worry that they have to do all the work for the slackers. You have a “value vs presence” conflict.

Value here means “value for the customer” – how do they profit from what the team members do? Presence is about control. A need for surveillance is always rooted in distrust.

The solution here is to make progress visible: There should be a central place where you can see who works on what and what their progress is. You can have a web site that lists any changes made to the project sources – most DVCS give you this for free. Set up CI and use public backlogs to track progress. If everything else fails, you can send an email with daily status updates. Have meetings where people focus on what they have achieved and what keeps them from reaching their goals.

“Value delivered” should be king.

The next challenge is usually communication. During face to face, about 55% of all information is conveyed nonverbal. Tone makes up 38%, the words alone count for a mere 7%. In other words, if the text in this post lacks 93% of the information you would get if I explained the same to you in a personal meeting (source).

This why you must have a video conferencing system of some kind. It’s not nice-to-have; lacking one is like sabotaging the project.

Also be aware of the effectivenes of your communication channels. Tune narrow channels.

Use video conferences for daily standup (short, personal), chat for discussions (longer, open ended, needs transcription, not very formal), phone calls (complicated, personal, urgent), face-to-face (important). If you have a distributed team, make sure they meet face to face once per month. Flying them in might be expensive but not doing this might ruin your chance of success.

Be more personal in video conferences. Pawel mentioned the “4th question” to form bonds: Which book did you read lately? How do you exercise? This is the social glue that you need when you don’t work in one place.

Use retrospectives regularly to identify important problems that the team wants to solve.

Related articles:

Leave a Comment » | Conference, Software | Tagged: , , , , | Permalink
Posted by digulla

Jazoon 2013 – True Git: The Great Migration

24. October, 2013

Jazoon 2013 badgeStefan Saasen told the tale how Atlassian migrated from SVN to Git in his talk “True Git: The Great Migration.” (slides on slideshare)

Atlassian has resources on their website if you want to know more about Git and how to implement your own workflow using it.

Key points from the talk:

  • Branching and merging are first class concepts in Git (unlike Subversion, where they were added as an afterthought)
  • Especially the merging support in Git is much, much better
  • You can use clever tools like bisect to zoom in on bugs
  • History rewriting allows to clean up mistakes
  • Adoption for Git is on the rise. In 2015, most companies and projects will have migrated to Git or another DVCS
  • Use a centralized repo for your enterprise – all the processes and tools will be much easier/happier
  • Make sure you have defined a clear workflow and your developers know about it

Leave a Comment » | Conference, Software | Tagged: , , | Permalink
Posted by digulla

Jazoon 2013 – Spring Framework 4.0 – The Next Generation

24. October, 2013

Jazoon 2013 badgeIn his talk “Spring Framework 4.0 – The Next Generation,” Sam Brannen gave an overview of the new features of Spring 4.0 (slides on slideshare).

Spring, which has moved to http://spring.io/, is going to version 4 which means they add support for Java SE 8 and Java EE 7.

As a Spring developer, this means better Groovy support, being able to use lambda expressions and method references in Spring callbacks, support for “JSR-310 Date-Time types for data binding & formatting, a new @Conditional mechanism for bean definitions, & a new WebSocket endpoint model.”

Things that I took home from this talk:

  • Spring Boot is a new project to make it easier to set up “Spring-powered, production-grade applications and services with absolute minimum fuss.”
  • @Lazy is now supported to annotate the place where a bean is injected (formerly, you could only use it to make it lazy at the definition)
  • There is a new API for messaging with support for WebSockets. In this context, you may want to have a look at stomp “the Simple (or Streaming) Text Orientated Messaging Protocol.”.
  • Spring 4 supports Java EE 6 through 7 and SE 6 through 8
  • Repeatable annotations will make code more compact

The slides should appear soon on slideshare/sbrannen.

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Spock: boldly go where no test has gone before

24. October, 2013

Jazoon 2013 badgeIf you look at your tests, do you see a lot of repetitive patterns? Or are you looking for a way to express your intent more easily? Then, Spock might be for you. The talk “Spock: boldly go where no test has gone before” by Andres Almiray (slides on slideshare) gave a good introduction to the framework. Here is an example:

class HelloSpock extends spock.lang.Specification {
    def "length of Spock's and his friends' names"() {
        expect:
        name.size() == length

        where:
        name     | length
        "Spock"  | 5
        "Kirk"   | 4
        "Scotty" | 6
    }
}

In a nutshell, this creates three tests, running the assertion name.size() == length for each tuple of values. Here is an example how to test a stack.

But this is just one of many ways which you can use to describe tests that Spock should execute for you. The page “WhySpock” lists 10 reasons.

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – STJS: Managing JavaScript application complexity

24. October, 2013

Jazoon 2013 badgeThe talk “STJS: Managing JavaScript application complexity” by Alexandru Craciun (LinkedIn) and Nicolas Piguet (LinkedIn) focused on one of the major pains with JavaScript: It’s easy to get started, you have can quickly build a useful app which then just as rapidly turns into a maintenance nightmare (slides).

They used ST-JS as a tool to reign the dragon.

In a nutshell, ST-JS is a tool that parses Java code and converts it into JavaScript.

What ST-JS isn’t: It’s not GWT (see the FAQ). The code can be edited in your IDE, it compiles but it doesn’t run directly. The Java code is just used to allow you to write type-safe code using all the amenities of a modern Java IDE to write JavaScript. But if you want, you can implement so parts – think about sharing POJOs between your Java code and the script in the browser.

This works by writing thin wrappers (usually just a bunch of Java interfaces) to simulate the API layer of a JavaScript framework like jQuery. This code is called a bridge, here is a list of already available ones. You can then write code using code-completion, JavaDoc popups and type safety. You can apply tools like PMD, FindBugs, SonarQube (formerly Sonar), dead code analysis, …

The tool will then convert this code into JavaScript. A standard JUnit runner can now execute it by opening a browser window or simulating one using env-js and Rhino.

The output of the tool is plain JavaScript. To run it, you just need to include stjs.js which you can serve statically from your server.

As I see it, this project has the following benefits over anything else I’ve seen so far:

  • Full support from your Java IDE – Code completion, refactoring, type/JavaDoc popups, jump-to-definition, …
  • You can split the JavaScript mess easily into classes and packages
  • Not intrusive, low complexity
  • Easy to build bridges to other JavaScript frameworks
  • Allows to share POJOs between Java and JavaScript

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Test First Saves The World

24. October, 2013

Jazoon 2013 badgeThe opening keynote “Test First Saves The World” by Joe Justice introduced WIKISPEED. The project aims “to deliver a mass-production, ultra-efficient, Comfortable Commuter Car, the C3“.

You can find the current list of bugs here.

Some important points about this car: Building the first road-worthy prototype took only 3 months. A team of untrained individuals can build one of them in about one day. It runs on 2.8 l gasoline per 100 km.

In comparison: Professional car manufacturers need hundreds of people and 3 years to build something which dozens of trained teams can assemble in a few hours. And the result is either four times as expensive or pollutes the environment more.

Sounds good? They use scrum. They proved on several occasions that the method works very well for hardware, too (Forbes, CNN Money).

I agree with Joe that scrum is now entering the 3rd phase of the hype cycle: Only the most conservative companies remain cautious.

But scrum isn’t easy – if our problems were easy to solve, we wouldn’t need help, right?

While you can spend some money on training (for example, by asking scruminc to send Joe to your place), you need to remember one of the most important points of scrum: Continuous improvement.

Conclude every spring with a retrospective, identify one item that the whole team wants to have solved – more plants, better soap, an additional microwave, more light, new computers, you name it. Put that as the first item in the next spring and work on it first. Don’t forget to define acceptance criteria.

Or do you like working in a place where the general mood is that “nothing ever changes – especially not for the better”? Everyone knows that happiness and quality will make teams more productive. It’s high time to take a stand in the face of “it’s just the way it is.”

Joe’s next project? A $100 house for homeless.

What’s your’s?

Leave a Comment » | Conference | Tagged: , , , | Permalink
Posted by digulla

Next Entries »