We had a Python meeting tonight (18 april 2013) in Delft at the fox IT offices.
I especially liked the open source marketing talk, telling us how to properly tell others about our great projects.
(Note: my brother Maurits also made a summary)
I gave a quick lighting talk about my githubinfo script that gives you reports on the amount of tests in the last week per project and per developer. Handy for raising awareness for testing amongst your colleages if you mail around the results once a week!
The source code is at https://github.com/nens/githubinfo .
I already blogged about it, so you can read more there.
Ronald works on detact, a fraud detection for online banking, trying to detect fraud in http traffic for online banking. They sell it to banks. The low-level stuff is in c++, the rest in Python.
How do they make it? They use git, so they can use Gerrit, a code review tool. Every commit gets
pushed first into a special
gerrit branch on github and ends up in the
gerrit tool. Every commit needs two upvotes before it gets included. One of
the votes comes from their continuous integration tool.
Continuous integration tool? They use jenkins for that. It integrates real well with gerrit, which has a plugin for it.
Deploying? They try to deploy continuously. They have to play cat-and-mouse with online criminals, so they need to respond quickly. That’s why they put so much effort into testing, continuous integration and code review. Everything has to be deployable most of the time.
Some of the tools they use for operations: irc, fabric, sentry, munin, nagios, request tracker (for sending out SMSs at night). Sentry aggregates all your error messages from your various servers. So you deploy and start monitoring sentry for a while. Works quite well.
About irc: look at https://github.com/ronaldevers/botlerplate for some easy boilerplate to quickly create your own simple bot. If you need more functionality, use github’s hubot. It has lots of functionality, you can do a lot with it. (Update: I mis-interpreted what he said initially, but he mailed me and said he was positive about hubot, so the original text in my summary (which was negative about hubot) was wrong).
Fabric uses SSH to execute commands on your servers. You write the commands in Python. They use it to roll out their software on their servers. They do some weird hacky great Python globals hacking here:
for customer in customers: globals()[customer] = some_method_that_returns_a_customer_function
Closing comment: use requests when you talk to something via HTTP. It also makes it easy to consume JSON. HTTP and JSON are your friends.
How to get more attention for your open source project. Many people make open source software, but make small mistakes in telling the world about them. The sad thing is that you’re doing yourself a disservice because you don’t help people use your software this way. This talk gives you a few simple marketing tips to help you.
Get your users engaged, talk about them.
People care about themselves, so talk about them, not about yourselves. For instance, Ruby “helps you write...”. A bad example is sqlalchemy: “it provides a full suite of...”. That’s impersonal and not about me, the reader. Being personal helps!
Think of the pain. Why did you start your project? What problems does it solve?
Talk about pain. “I don’t have enterprise software” isn’t a pain. “My code isn’t beautiful” is a pain. Tell your user what their pain is, so what their
A good example: Django. “Django makes it easier to build better web apps more quickly with less code.” So web apps are difficult to write, good apps are hard, good apps take too long and good apps are a lot of work. Hey, that are pain points that I can understand.
A bad example is Flask. It “uses werkzeug and it is BSD licensed”. So apparently the pain I feel is that I’m not using werkzeug and apparently I’m bothered that I’m not using specifically the BSD license?!? (Somebody commented that the right way to tell it is somewhere else in the docs).
Think about benefits first.
Benefits first, not a list of features. Features are only useful as support for the benefits you claim.
A good example: ”... rely on MySQL to save you time and money”. Words like that make the benefits clear. Benefits are good. A benefit gets you from :-( to :-). PostgreSQL’s just lists a huge number of features. That doesn’t help.
Show, don’t tell.
A picture is worth a thousand words. We all know this. But do we do it?
A good example is the requests library. On the home page is a quick code example that shows how easy and good the library is. The httplib2 page doesn’t show a thing. It doesn’t show how beautiful or bad it is.
So focus on:
(Jeroen has an excuse, btw, for not talking to sqlalchemy and flask yet: they just got a baby :-) )
Nothing? Zero. IT is zeros and ones. He checked his own source code: 58% zeros vs 42% ones. You can find the script at https://github.com/jap/bittally .
None is is also nothing. But sometimes you get None back from something that you later want to call, so you first have to check for None. Someone suggested to make None callable, returning None again, in PEP 336. It was shot down.
So he wrote https://github.com/jap/nihilo:
>>> from ninilo import nihil >>> nihil + 5 5 >>> nihil.something() nihil()
Some evil mind in the room suggested
from nihilo import nihil as
None... (Jasper checked later: this doesn’t work.)
Onno is a scientist at the UVA in Amsterdam.
Scientists, especially physisists, invented the atom bomb. And they also write
some of the worst spagghetti code. For their particle accellerators they
really need to write their own software as their’s nothing
off-the-shelf. Version control means copying folders
my_code.final.final2. Testing is non-existent.
And those people are supposed to cure cancer and so?
The solution is to educate scientists. Testing. Version control. And when to stop and get a real programmer on board.
There are some people in Canada, Software carpentry, that teach scientists to program properly. Using Python. In a few weeks they come to the Netherlands to give courses here.
If you have ideas, please tell him.
A question: isn’t it required to publish your code along with your research? Answer: no it isn’t. That’s idiotic and weird, but it isn’t. Despite the “peer review” that’s touted in science. Bad.
You’ll see a lot of
js.* projects on pypi: those are fanstatic
js.html5shiv, etc. You can use your python stack to work with those
resources. Including version numbers!
install_requires=['js.jquery > 1.4',
Fanstatic handles combining resources (“bundling”) and compilation (minifying, compiling, coffeescript, etc). It saves you time!
You “require” resources in your code:
And... your resources can also require other resources. So if you need jquery, you just specify the requirement and fanstatic takes care of it. Nice. He demo’ed it and it all worked as a charm. Dependencies, compiling, bundling, minification.
Fanstatic works with WSGI, zope, flask, django, etc.
You can also have fanstatic serve your static resources via some separate static website.
Note: fan**st**atic instead of fantastic.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):