Monday, December 15, 2008

"It started with Arjen doing the last lightning talk at OSDC 2008… aquick show of hands on who else had dealt with (or was dealing with)depression. Everybody had a look around, and thus knew that theyweren’t alone. Afterwards, there was more positive feedback whichcontinued over email in the days that followed. Someone suggestedstarting a group, and the same day bluehackers.org was born.

The objective of this initiative is to make visible that there aremany fellow geeks among us who are intimately familiar withdepression, anxiety, or bipolar disorder. It helps to know you’re notalone. And it’s not because we’re geeks, but because we’re human. TheAustralian BeyondBlue site is of course an excellent resource, but,because geeks have a specific work environment, there are alsoparticular challenges in dealing with these issues, and that’s wherewe feel our group can help with additional insights, tips, and postsfrom others with experience.

Using the logo, we can also make the topic visible at meetings andconferences around the world, ensuring that indeed no geek need feelalone in this, or feel unsupported. They can simply look around andsee. Anybody will be able to show their support and understanding, ina kind and non-intrusive manner."

Imagine if many people's education were based on an open source platform

Child takes a sense of ownership / responsibility for OLPC deviceBetter for each to have their own rather than to share for this reasonTarget group is 6-12 years old

Important tenet is connectivity - Can visualise mesh network of who is nearby - FOSS, building blocks, building blocks for creativity

Some of the technology----------------------

Antennae takes 5V in, can be used independently for mesh range estensionSchool server version - jabber, other pooling tech, security tech, alerts if laptops leaves it will shut down unless it can reconnect to school server after some period of time - backs up other laptops, allows teacher monitoring etc - mic jack doubles as voltmeter

Regional Vision--------------- - Great need in the region - Build a strong developer and educator community - e.g. indigenous communities and children in impoverished areas

5000 laptops donated to regional project, trials include many pacific island communitiesProviding sat networking to some of the most remote areasSome potential to travel with OLPC and contribute in the community, volunteers neededwiki.laptop.org/go/OLPC_Oceania

Consideration of cultural values--------------------------------

When rolling out, most pacific culture has healthy respect for teacher as the leader

Try to make sure teachers get the device early, extensive trainining, teacher is the person that gives the children the resource rather than from random externals.

Fit with what groups are already trying to achieve with their schools

Australia's first trial is happening------------------------------------

A single laptop by itself doesn't have so much value, need classroom environment e.g. spelling tests, collaborative writing activity

World's first remote-connected classroom. That is, the local teacher is connected to remote classrooms, video chat etc.

Example of Python shell where you just run demo code then change it yourself as an exercise

Example of a particular troubled kid from a very disadvantaged background who engaged through the laptop environment, partly because he could engage with his interest area, partly because the laptop was his, that he could use according to his own preferences and progress in his own time.

First time patch submitted to OS project: - nerve-wracking experience, judgement - having people look at your code, give feedback etc is very powerful and important, best tool we have to get better as programmers

A few things in code review than can cause social problems - Being told your entire approach is wrong - Better to have a conversation before coding starts - While you're there, totally do something else also * need to be allowed to fix small incremental issues * unclear outcomes (ie "this is bad", not what about it is bad) - Name-calling is bad, doesn't help, talk about code not people - Confusing personal preference with objective worth - Filibustering -- what happens when you are outnumbered, but can win an argument by talking lots - Lag is bad, reviews need to be fast, lag builds up - Need to know who are the reviewers

Good things (how to do good reviews) - Specific feedback - Be thankful for code submits - Ask questions where you don't understand stuff - Before you start coding, talk to someone about it. Anyone. - Decide to who gets the final say to head off future conflicts

Questions: - Worst have experienced professionally is "that's a stupid idea" - Language barriers can be an issue - What happens if there are not enough developers for review? - Generally in favour of doing code reviews in public or opt-out forum - Be specific regarding thanking people also i.e. "I'm looking forward to using this feature"

Brendan Scott, OS lawyer based in Sydney. (opensourcelaw.biz)[n.b. this is particular to Australian law]

* Some analogy about driving to a location with a bit of suboptimal route planning. Many decisions along the way.

* When engaging a lawyer, this is like reading a map before setting out* Not always necessary / justified, this depends on a bunch of things - familiar territory? - time and cost?

Hypothetical business growth path: - start - build it up - sell it

Setting up an incorporated vehicle makes things (significantly) easierThe word "partnership" has a specific legal meaning, including: - you are personally liable for your partners actions in the business - best to avoid unless want to be in this specific relationship

How would you react to someone taking code from a project you are working on? - If you have good record-keeping, can sort out rights relatively easily, even if you don't have a copyright record. Just need records of activity and can bootstrap copyright attribution

Contracts take effect at the time of signing

The conduct of a negotiation limit the things you can say in the future to try and vary the contract -- i.e. major points have been ventilated. Difficult to bring lawyer in at this stage to make nontrivial changes.

What else might a lawyer do for you? - Dispute Resolution. Often a case of identifying what the problem is and identifying win-win or least-loss outcomes - Sometimes knowledge of the law is extremely relevant

Thursday, December 4, 2008

Gentle introduction to version control using BazaarMichael Hudson from Canonical

What is Bazaar?Distributed VCSNo privileged sentral locationaims to be safe, friendly, free and fast

'bzr init''bzr add''bzr ci -m "initiam import"'

'bzr push' uploads or updates branch data on the server'bzr branch' - get a copy of a remote branch'bzr pull''bzr merge'

Some concepts-------------

WorkingTree - collection of version controlled files and directoriesRevision - A snapshot of a working tree and the fundamental object in bazaarBranch - An ordered series of revisionsRepository - A place where revisions are storedCommit - create a new snapshot/revisionDelta - the difference between two revisionsMerge - determining the outstanding revisions in one branch and applying them to another

* Can run a centralised model, then works quite like SVN

* Or, can run semi-centralised - Mainline or trunk reflects current mainline - New features developed in own branch - Patch Queue Manager (PWM) can enforce this / guard a branch

* Full distributed - Developers maintain their own branches - Share / Merge p2p - Can still use PQM to maintain a test-suite protected mainline branch

* Mixed-mode obviously possible

Advantages----------Don't need to give people commit rights to trunk to allow them to contribute (can send their revisions to other developers directly via 'bzr send')

A Bit About Launchpad---------------------A web-based tool to support open source software developmentDesigned to scale

What makes a good unit test suite?- readable: intent and implementation is clear- reliable: pass/fail when it shoud- usable: easy to run, fast, debuggable

Very quick overview of unittest:- Subclass unittest.TestCase- def setUp(self): foo- def a bunch of methods (will all be test cases)- single unit test is represented by a TestCase instance- then run tearDown- report the result to a TestResult object

Why is this good?- Standard, most other frameworks will interoperate with it, batts included- Not Python-centric, xUnit implementation, general programmer awareness- Encourages good structure in tests- By default, tests are isolated from eachother- Easy to reuse a test fixture definition between multiple tests (reuse setUp and tearDown)- Group tests by common needs- test cases have explicit names, so clearer reporting, can be specific about what failed & where

Unittest is pretty easy to extend.- extensions have a good chance of being fairly compatible with other test frameworks- examined addCleanup logic, add cleanup code immediately after, e.g., adding a lock- (Bazaar extension) multiply_test_suite_by_scenarios is a function that takes a test suite and a list of scenarios

A couple of extra libs worth knowing about- launchpad.net/testtools: miscellaneous extensions from various projects- launchpad.net/subunit: runs unit tests in separate processes to support test isolation- launchpad.net/testresources: is a library to manage the initialisation and lifetime of expensive text fixtures

Some bits are bad:- no standard tool to load and invoke a test suite- parts of the API could be better (lots of 3rd party stuff needed)- set of built-in assertions is a bit small- documentation in the std lib is a bit weak

- fundamentally quite capable, pretty easy to usefully extend, would be great to get extensions back into std lib.- launchpad.net/pyunit-friends

This presentation talks about how useful OS is to Google. Starts presentation with hardware history of Google, showing Linux ancestry. Current systems are big rack systems, but still running customised linux software with heaps of OS libraries involved.

Google has found about 3.5 billion lines of OS code in unique files, which is more than any of the big players individually have written.

Does this to maintain independence from external software companyAllows you as a software company to do something out of the ordinary without showing your hand / without external dependencies

How does Google take part?--------------------------

8.5 million lines of code released in AndroidRelease about 1 million lines of code outside of thatImportant for engineers to be able to interact with peers in the community, not get out of touchProvides good code hosting with version control, issue tracking, wikiHires some people directly because they are seen as importantSponsors GSOC -- create new OS developers

Questions---------

Why didn't Google create their own open source license? * Don't trust licenses that arent's used much * Real combination problems when integrating projects * Not everyone trusts Google, so using well-understood licenses is good for this * Obvious what Google means by using a license as people are familiar with them * Developers don't need to understand new legal terms, familiar with known licenses * Uses Apache a lot because it has specific things to say about patents (personal comment -- helps avoid patent issues -- not exactly sure how but seems to provide some end-user protection against patent infringement through using the software)

Yesterday (Tuesday 2 Dec, Sydney AUS) was day one of the OSDC 08 conference. It began with a Google Hackathon, where a few Googlers presented some of their latest technologies. These includes both open source projects which they sponsor (or at least contribute developer time) and closed-source but free-access systems. These systems were: * OpenSocial * Something about an open map layer system * AppEngine

This was pretty neat, and I successfully copied-and-pasted my way to a functioning OpenSocial application which would allow me to give my friends virtual acorns in a variety of social network containers. Google make available a number of things to make this easier, including comprehensive examples, a number of free hosting solutions and a sandbox environment for Orkut to deploy test applications.

I haven't been active in this area of development before, but a great deal of the complexity of managing such an application has been stripped away to allow any potential developer to concentrate on application functionality instead of systems maintenance.

Following this, I visited the Google offices as a part of the Sydney Python User's Group meeting. At this meetup I presented on the topic of AI in Python. At this stage, I prefer not to make my slides web-available but would be happy to supply them via email to anyone at the presentation or who would like to engage on the topic offline. Since AI is such a huge area, with so many potential audiences, there is a lot of ground for misinterpretation of a slide or bullet point if taken out of context. I had great fun however, and greatly enjoyed catching up with everyone at the pub afterwards.

Props to Christoph, Mark, Alan, Richard, Mark, Matt, Alex, Joel and everyone else that I met whose names I can't right now recall. Thanks for making my stay a nice one!