PUN meeting 19 May 2011

Peter Hilton: Welcome to Lunatech

Sorry, I have not written any python myself. ;-) Technically focused company. We do almost everything in Java. We use an open source stack. So not very different in mindset, we just don't do a lot with python. Focused on back end stuff. Commercial IT services. Ten years ago we used Perl. I don't know why we switched to Java as I was not there at the time. I also don't know why we stay with Java. Actually, Scala is a more likely successor for us than python. We make money, which allows us to put this beer on the table. We hire hard-code geek programmers, creative rocket scientists, people who get things done, tech wizards with ambition, obsessive-compulsive types, managers in suits (not!!!). Python paradox: potentially you have more good candidates than in Java as there are so many bad Java programmers. We have a coding question for job interviews. We had to make it simpler or too many people would fail. It was not a question of: pass this test and you are hired, but pass this test and we can continue with the job interview.

Kit Blake (Infrae): VisitorVu: Real-Time Visitor Tracking for Your Website

http://brusselnieuws.be. Three different news sources coming in. They wanted to know real-time what was going on on the website. Direct hits on the web site, searches, external links, internal links. Popularity. Tag cloud. We are considering offering this as SaaS; we are probing if there is interest in the market. So maybe you or your clients? See http://visitor.vu/ and the code.

Steve Alexander: Interactive code previews

I ran a large software team at Canonical. Mostly I was hiring Python programmers. I was always looking for existing code that interviewees had already written and that was out there being used. Then I quit my job and took acting classes, did coaching, etcetera. How do people communicate, that's what I am busy with.

Seizing the task. Fix a bug, optimize, write a blog post, all are tasks. Rubber duck programming: you buy a rubber duck and explain him the process of what you are going to do. By talking and hearing yourself back (or maybe writing and reading it) you focus and it becomes easier to see if it still makes sense. Geir Baekholt at Jarn: "When doing a task, we talk it through with another person." Are you a good listener. Presume a lot: they have expertise (else why are they working here), they can find things out for themselves, are creative. Destroy ambivalence: not maybe/possibly/whatever, but yes or no. If an issue is in a bug tracker for too long it sucks the life blood out of a company, product, community. Motivational interviewing: don't try to make someone enthousiastic or offer 'helpful' solutions that the idiot other has probably not thought about, but ask him about his own motivation and how he could make himself more motivated. I started as a very technical manager, which made people look up to me too much as I could maybe do their job better. If you hire someone, believe in his skills and trust him; try to find smarter people than you.

You see a lot of small software companies in The Netherlands; that is cool. Every company seems to have its own culture. It is important to attract good people: I want to work with people I want to work with.

See http://www.nowtalking.nl/

Steve Alexander presenting at PUN [Photo by Jasper Spaans]

Matthijs Kadijk: Some nice things you can do with google data APIs

I am an independent software developer. Just moved to the Creative Factory in the Maassilo in Rotterdam. Most of the Google services have AP Is that you can talk to within your program. RESTFul web services, an xml version based on ATOM feeds, json available too using alt=json parameter, OAuth authentication. Some use cases: schedule an SMS (text) message, add an appointment to a calendar, import data from Office docs without having Office, perform OCR, create a PDF invoice. Google code has a python client lib gdata, available via PyPI: http://pypi.python.org/pypi/gdata The python implementation does lag behind the other implementations a bit, so maybe some of us can help? The services can respond slowly, so watch your timeouts. Read the source code of the library to find non-documented features. Let the user do a manual login first, otherwise you can get a captcha. Use stored access tokens to prevent blocking after too many login requests. And you may want to consult an expert when you run into problems.

Nicolas (Lunatech): Play! framework and Python, what's the deal?

The Play framework makes it easier to build Web applications with Java and Scala. Could be Jython with the right modules. Lunatech has contributed to this. It is inspired by Django and Ruby on Rails. The scripting aspect is done in Python. We try to be language agnostic. You don't need to restart the server when you change your Java code; this is done on the fly. There is a community around it that develops extra modules. See http://www.playframework.org/

Sylvain Viollon (Infrae): Demo of infrae.testbrowser

With infrae.testbrowser you can test web applications that run on WSGI. You can ask the test browser to look for content with xpath expressions or css selection. So you can more easily make sure you don't get an error when there are two inputs with the same name. It can also talk to Selenium and execute the tests in a real browser.

Jan-Jaap Driessen: Hackathon

We did a hackathon/sprint in Rotterdam two weeks ago. About ten people showed up. Was a good day. I can set up a new meeting but others can do that too. I am planning one in a week about deployment. Keep an eye on the mailing list of PUN. Let's learn from one another and exchange ideas and code together.

Beer and pizza at the PUN [Photo by Jasper Spaans]