Two months ago I went to Scarborough. Nice time to finally see someone from Scarborough Linux User Group: Catux and Scarborough group are “sister LUGS”.
We used to chat in the Catux mailing list in 2005 and 2006. 8 years later we met eachother. Amazing!
On the way there one of the trains got delayed so I missed the connection and arrived in Scarborough 1 hour late. Not a big deal because arriving Friday at 9pm or 10pm is not so big a difference. Obviously it could be a problem if it was on the way to the airport or something else.
Two years ago I tried to get an East Coast refund, but the train was late only 28 minutes and the minimum is 30 min. Going back to the station I actually wished that was 31 minutes late and not 28…
Well, this time East Coast refunded 50% of the return ticket because it was 1 hour late, which made me very happy! Actually I think that I would prefer to arrive 1 hour late and get 50% back of an expensive ticket (it was 114 GBP return). So I got 70 GBP, yay!
Unrelated but after this I acquired a free return ticket from London to Brussels for the next Fosdem: the Eurostar was more than 1 hour late (or was 1.5 h?) coming back from the last Fosdem. Good times for refunds.
I installed MultiBit (a Bitcoin client) on my Debian Wheezy. I didn’t know much about Bitcoin so I thought that I’ll install and play around about with it.
I installed Multibit using the “Linux/Unix Installer” (see the instructions).
I ran MultiBit but it didn’t connect to the network. The bottom-left status message always said Connecting… instead of Online.
After a few Google searches, look at the logs, etc. I followed these instructions: this webpage.
With root privileges I had to do:
- edit /etc/sysctl.d/bindv6only.conf
- change net.ipv6.bindv6only = 0 to net.ipv6.bindv6only = 1
- /etc/init.d/procps restart
And then Multibit worked correctly.
When Twitter stopped serving RSS feeds, around May 2013 I think, I implemented a small and light Python Twitter-API to RSS proxy. It connects to Twitter using their API, reads the Tweets and generates RSS or Json.
The Json output is similar to the output served by the Twitter API but if you use this from different applications it helps to centralise the authentication to only one place.
If you are interested in it see the Github page.
Continue reading Twitter2Rss in Python (and how I use Twitter)
On Saturday I went to the new Cambridge Centre for Computing History. Or just.. The Computer Museum.
Hats off to this museum! If you are interested in computers you should really go to the Computing History museum in Cambridge and also to the The National Museum of Computing in Bletchley, which is convenient because Bletchley Park is another place to visit (see a Bletchley Park blogpost, from 2009)
Continue reading The Cambridge Centre for Computing History (computer museum)
We are hiring for different positions at Mendeley (now part of Elsevier). In the team where I work we are hiring a C++/Qt software engineer (see other positions). The C++/Qt position is to further develop Mendeley Desktop, which works on Windows, Linux and Mac.
See the official job description, but bear in mind that we are a bit flexible (if in doubt just apply). You can contact me at carles@pina.cat if you have any questions. If you apply please mention that you come from Carles/Pintant, thank you!
I’ve been working for Mendeley quite a while, now part of Elsevier. See Pintant for hackdays entries: once a month we have a hackday and occasionally I’ve written some posts.
Working at Mendeley is good fun and often challenging. We use many free software tools, we publish some free software things at Github (and I hope to publish even more in the future). I hope that you will like the colleagues.
At Mendeley we have one hackday a month. One day, every month, we can do whatever we want more or less related to our jobs, technologies, etc.
Some months ago I thought that it could be interesting to teach Python to the non-programmers (business, HR, etc.). I wanted them to understand what we do all day programming. I also wanted to practise my teaching and presentation skills. And learn how to plan a teaching day.
I think that the day was a success! (and tiring).
Continue reading Hackday: teaching Python to non-programmers
Short version: Sunday Assembly (congregation without God) is crowdfunding to build a better website / other activites. You can donate.
In London I’ve been to different ceremonies: Catholic, Orthodox, Christian, Budhist, Protestant, etc. I like to see the churches/temples, how they conduct the ceremony, their traditions, how attendants behave, etc.
In one of my visits I discovered they talked, in a quite negatively way, about “The Sunday Assembly”. Two comedians have started a new congregation without God. This consists of the things of some ceremonies (music, tea, social, etc.) without the God or cult.
It really interested me. Also, the co-founder Sanderson Jones, comperes Sunday Assembly and feel free to donate! Donating will help to build the website that will put together people to sing and share things, so it’s a good donation.
I’ve been using my e-reader (Kobo Glo) for aproximately one year now.. I’m very happy with the purchase! I find it very convenient, I explained in the other post (in Catalan).
There is one thing that I’ll miss if everybody uses e-readers. I really like to browse book shelves when I’m invited to someone’s house. I like to see which books I’ve read, or the same author. Or the same style. Or get ideas for new books, feedback of other possible books. Since we are a bit what we read, it’s a way to know the host a little bit more.
If using an e-reader this is not possible, or not possible in the same way. I’m sure that it’s possible using some webs (upload the list of read books, rates and comments). But this is not so natural like browsing the real shelf, pulling a book and asking “so, what do you think?”.
My two suggestions:
There is the concept of User Pain. Useful concept which I’ve used at work. It’s not perfect, might need tweaking for each situation but works well.
In a nutshell: given a software bug it is possible to quantify the pain caused by the bug to all the users based on the type of bug (crash, major, minor, etc.), priority (will the users affected be blocked? or just a small cosmetic problem?), and likelihood (how many users are affected? a few or many?).
But I’ve created what I called the “Developer shame”. It’s a new concept. I thought about this when I felt ashamed we hadn’t fix a bug. It was a small one, easy to fix, only a few users were affected (but we had some requests every now and then). It was one of those bugs that when someone mentioned it everyone wondered “why we didn’t fix it? Easy to fix, and it’s not the first request!”.
Getting some inspiration from the User Pain blog post I’ve assigned some points:
How easy is to fix (always for a single developer)
- 2 points: 0 tea breaks required to fix it
- 1 point: 1 tea break required to fix it
(more tea breaks: out of scale)
How do you respond to the affected users
- 2 points: with a workaround that the developer could have implemented
- 1 point 1: with a generic message
Do you know how to fix it?
- 2 points: you just need to sit down and type the solution
- 1 point: you think that you know but there is a small part that you might need to check
What’s the risk
- 2 points: there is no risk when implementing this. Just new code that doesn’t affect existing code
- 1 point: some risk implementing this (might need some refactoring, changes some existing code)
Just add up the points: the scale of developer shame is from 0 to 8.
I suggest that if it’s 7 or 8: please go and fix. Being ashamed of bugs is not good. Then one feels guilty, and feeling guilty is not good feeling either. It’s better to feel proud of your software.
I’ve spent a couple of months migrating some code from OAuth1 to OAuth2. I helped to shape the OAuth2 services, the first API calls in the new platform, set up all the new infrastructure in the client side.
Usually I like to have, as soon as possible, an end to end working case. It helps to validate the approach, helps to test changes on the server side; start writing unit tests, perhaps some hallway user testing, etc.
Then I add the error handling (what happens when there isn’t a network connection, or the server is not available, or returns invalid answers, etc.).
But after some time working on this project I think that I should have started the skeleton with the “usual” cases: what happens when it’s not working. And then at the end I should have handled the special case, the one that… it works.
So, consider the errors part of the usual code path and then, at the end, add “what happens when everything works well”. I’m exaggerating a bit but you probably know what I mean.
The code, in any of both approaches, is similar. But it avoids some back and forth to add error handling where I didn’t expect to have any.
Next time I’ll do this way. I’ll see what happens then!
|
|
