The Productive Programmer

Presenter: Neal Ford (ThoughtWorks)

The Productive Programmer session was based on the book The Productive Programmer, presented by the author. Below is a quick outline of the session. I'll be honest, this session was kind of long and I may have nodded off in a couple of places.

The slides have not been posted yet; I'll try to remember to update this post when they become available.

• Mechanics

  • accelerators

    • typing is faster than navigating

      • use gui tricks to minimize mousing
        

    • multiple clipboards

    • pushd/popd

    • command line/file explorer integration

    • use shortcuts instead of menu entries

    • templates/macros

  • focus

    • ergonomics

      • get a comfortable chair

      • dual monitors

      • good keyboard/mouse

    • developers should have root

    • war rooms instead of cubicle farms

    • locus of attention: The Humane Interface by Jef Raskin

      • pop-ups/distracting dialogs

        • screen dimmers

      • internet/games

      • instant messaging/email/twitter

    • maintain concentration
      

      • turn off notifications

      • don't keep email open

      • turn off instant messaging

      • put on headphones

      • create office “quiet time”

    • the higher the level of concentration, the denser the ideas

    • focus techniques

      • search > navigation

        • replace file hierarchy navigation with search

      • rooted views

      • use virtual desktops (virtuawin)

  • Canonicality

    • define things once

  • Automation

    • obvious

      • one-command build

      • continuous integration
        

      • version control

      • documentation

    • tools

      • automated interaction

    • to automate or not

      • set a time box

      • analyze the ROI

        • time_for_task * times_repeated > time_to_automate

      • don't shave yaks
        

• Practice

  • composed method

    • divide your program into methods that perform one (and only one) identifiable task

    • strip generic code out to new methods

  • test driven development/design

    • creates consumption awareness

    • forces mocking of dependent code

  • static analysis

    • cpd – copy/paste detector

  • citizenship

    • bunch of java stuff (ZZzzZzzzzZzZzz.....)
      

  • yagni (you ain't gonna need it)

    • build what you need now, don't indulge in speculative development

    • increases software entropy

    • don't need frameworks for everything

      • Avalon is a framework for building frameworks
        

  • question authority

    • that's the way it's always been done

    • know when to break the rules

    • non-intuitivity

      • pair programming

        • produces code 15% less efficiently than two programmers working independently, but with 15% fewer defects

  • single level of abstraction principle

    • keep all code of a method at the same level of abstraction

  • polyglot programming

    • leverage existing platforms with languages targeted at specific problems

    • many different languages that compile down to JVM byte-code

    • not “resume driven development”; the right tool for the job
      

  • every nuance

    • learn all the “back alleys” of your chosen language

    • $1000 plumber: $1 dollar for closing a valve, $999 for knowing which valve to close
      

  • anti-object

    • ?? (ZzzZZzzzZZZzzzzz....)
      

DTrace Hands-On

Presenter: Angelo Rajadurai (Oracle/Sun)

The full tutorial is available here, or you can grab the OSCON slides here. There is also a Google group set up here.

Why DTrace

Some performance issues only show up in production and DTrace allows you to perform live instrumentation in a production environment. DTrace doesn't require a debug binary or access to source code. The instrumentation can be performed on demand and you can probe any arbitrary location. Active DTrace probes require little system overhead, and disabled probes require no overhead.

Simple Example

% dtrace -P syscall'/execname==”java”/{@[probefunc]=count()}'

This tells DTrace that you want to use the syscall probe to count the number of system calls made by the 'java' executable.

D-Scripts

More complex setups are easier served using scripts. DTrace uses it's own scripting language called D-Script. The simple example above is actually a simple D-Script. More complex D-Sripts will allow you to introduce variables, stack multiple probes, and format output.

DTrace Patterns

Event Trace: Basically printf() debugging. Good for rare events, but gets very expensive. One thing I discovered today is that printf() performs ~2400() system calls to print a string.

Count: A collection or summary of events. The simple example above is uses the Count pattern.

What's In Between: Traces everything that happens between two events (eg function entry/exit).

Time Spent: Performance profiling. Find the amount of time spent in a function.

Profile: A polling probe that takes a sample over time to create an overview.

Gotcha's

Probes do have a performance impact. This is usually small, but it possible to unintentionally cripple a production system. DTrace contains a “killswitch” that should prevent you from completely killing the system.

DTrace only provides probe results. It can't tell you what to probe, or interpret the probe results. It's just an instrumentation tool.

General Approach

1. Define problem

   1. program foo is running much slower on Wednesdays

2. Verify “known” conditions

   1. “It can't be the disks, we just replaced them”

3. Attempt to reproduce the problem.

   1. If the problem can't be reproduced, it can't be instrumented

4. Isolate the problem

   1. CPU, I/O, Network, etc

5. Determine if other tools are more applicable

   1. Vendor supplied instrumentation packages

Android 101

Android for Java Developers

by Marko Gargenta

Meta data: http://www.oscon.com/oscon2010/public/schedule/detail/13330

Slides: https://marakana.com/static/courseware/android/Slides-OSCON.pdf

10 people last year at this talk at OSCON. This year: 100+

Writing an O'Reilly book: Learning Android.

Agenda

The Stack

Android SDK

Hello, World

Main Building Blocks

Android User Interface

Operating System Features

Debugging

Summary

The stack … good overview. See the graphic at http://developer.android.com/images/system-architecture.jpg.

Android Software Development Kit (SDK) … overview of what is included.

Using Eclipse is pretty standard but you don't have to. Android SDK included many command-line tools that integrate well with other Integrated Development Environments (IDEs).

SDK includes AVD Manager, a tool for creating Android Emulators. Version 1 of the SDK was released without any Android hardware (like the G1, Droid, Incredible, etc). Emulators can be created for many combinations and permutation of hardware abilities. For example: an emulators that doesn't have a camera, gps chip, et al. Can create mock sd_cards, etc. DDMS perspective in Eclipse can simulate GPS position, phone calls, SMSs, et al.

Review of $HOME/.android

ls avd

cat avd/.ini

“Hello, World”

(Basically going over: http://developer.android.com/resources/tutorials/hello-world.html)
http://www.google.com/

Created a “Hello, OSCON” project in Eclipse

Review of what was created

~/workspace/HelloOSCON> ls

AndroidManifest.xml

assets/

bin/

default.properties

gen/

res/

src/

R.java is the glue between Java and XML. Bascially a bunch of pointers.

Review of Eclipse Android XML creator, for strings.xml for different languages, layout.xml for landscape views, et al.

http://www.google.com/

Review of /bin - .classes, .apk, et al.

The adb tool.

$ adb shell

$ ls

$ ps

$ adb --help

Android Debug Bridge version 1.0.26

Main Application Building Blocks

(The meat of the talk)

Activities – roughly, the screen.

An activity is to an application what a web page is to a website. Sort of.

Usually have a main activity.

Typically requires lotes of memory, processor needs.

One running at a time with many sleeping

Well defined lifecycle (see http://developer.android.com/images/activity_lifecycle.png)

How/when onCreate() gets called.

Intents – represents events or actions.

Like HTML hyper-links between webpages. Sort of.

Can be implicit or explicit.

See the Home application sameple.

The home button sends a “home” intent.

Services – a piece of code that runs in the background. No UI.

Well defined lifecycle.

Usually much lighter on resources than activities.

Content providers – interface to shared data between applications.

Content URI, insert(), update(), delete(), and query().

Android built-in examples: contacts, settings, et al.

Broadcast receivers – an Intent-based publish-subscribe mechanism.

For example: when an SMS arrives.

A review of his MyTwitter app to ties together all the building block consepts.

Android User Interface

Procedural: in Java

Declarative: in XML

Best approach uses both.

Hands-on developing a layout.

Views and Layouts

Linear Layouts...

Android units: dp (density-independent pixel)

dip (synonym)

sp (similar but also scaled by user for fonts)

In layouts, the order of siblings matters.

Layout weight property

“...” in the property editor in Ubuntu Eclipse is buggy

Write a little gui with Eclipse, main.xml

Connected with this Java:

package com.blogspot.oscon2010;

import android.app.Activity;

import android.os.Bundle;

import android.util.Log;

import android.view.View;

import android.view.View.OnClickListener;

import android.widget.Button;

import android.widget.EditText;

public class MyTwitter extends Activity implements OnClickListener {

/** Called when the activity is first created. */

@Override

public void onCreate(Bundle savedInstanceState) {

EditText editTweet;

Button buttonUpdate;

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

// Find the views

editTweet = (EditText) findViewById(R.id.editTweet);

buttonUpdate = (Button) findViewById(R.id.buttonUpdate);

buttonUpdate.setOnClickListener(this);

}

public void onClick(View view) {

Log.d("Twitter", "Button clicked");

}

}

$ adb logcat # for viewing log via command-line

Summary...

Distributed Version Control

Watch out Git, here comes Vereacity...

Sights

Headed down...

Outside...

There!...

Inside...

Sad Chris...