antigravity imported

The first Cracow Python meetup was a huge success! With over 60 people turning up (some of them having travelled up to 3 hours(!) to get there), four presentations, and plans for next event in mind. What's even better - there are going to be three of us now to organise the next meetings. What's even *more* than better - the lectures from now on will be recorded and streamed live. Unfortunately - most of them will be in polish, but foreign speakers are also very welcome, so don't hesitate and come to Cracow! The following meetup takes place on the 21st of February.

And here are the photos.

The Longest Journey

The problem

Running all the tests for our rails app took around 2 minutes on other machines and over 15 on mine.

The solution

Remove all network locations from System Preferences and put them back again.

The journey

I reduced the problem to a single test case with a single test method with a single line. Having no idea how exactly Rails Does Stuff, I ended up putting parts of debug output and tracing rails' inner paths this way. I got to before_filters, then spotted the filter that caused the problem - it was the "black-list" check (provided by a plugin). Obviously, it was a single line of the file: the url resolution.

Now, I was scared - it couldn't be ruby's fault! Fortunately, it wasn't: analogous python library was slow as well. Actually they didn't work at all. Even pinging a non-existent url took 7secs, and on ALL other machines (running various OS's) it took an instant. The guys from #ruby channel at freenode were helping me for around 2 hours (thanks a lot!), but still nothing seemed to fix the problem. I got pretty convinced, however, that my problem was caused by a bug in Leopard's TCP/IP implementation. Feeling a bit more firmly in the topic, I started searching in forums. And there it was: on the ruby forum. I followed the most crazy tip and found out why it was the last message in the thread.

P.S. Blogger provides an OpenID for its users! My way of celebrating the fact was signing up on djangopeople.net (great site btw!)
P.S.2 Ola Bini run recently into the same problem, and put some more knowledge and investigation in solving it.

My hobby 2:

Using sick aliases for common methods

irb(main):003:0> def putse *args
irb(main):004:1>   puts args
irb(main):005:1> end
=> nil
irb(main):006:0> putse "lol"
lol
=> nil
irb(main):007:0> 

My hobby:

Using rails' to_sentence method in my debug output.

It is happening! Cracow python community.

Driven mad by insanely active ruby community in Cracow, I decided to take the matter into my own hands and get pythonistas to meet. I was surprised by how easy it seems to be - the room is provided by my university, blogger helped me create something other people could link to (sorry - it's polish only), I found programmers who have something to say and asked couple of news sites and blogs to announce the event. Let's hope everything will go as planned.

Photo by Pete Reed

Selenium testing in spite of browser differences

If you're using Selenium table tests for functional testing of your web app, you could have tried testing for browser specific issues. I used selenium vars for that (here in rsel format).

store_eval "if(navigator.userAgent.toLowerCase().indexOf('safari')\
              != -1){'some_locator';} \
              else {'some other locator';}",
           'specific_part'
assert_element_present '//div//${specific_part}'

*But* most probably, there should be a better way to do this. We used the trick above to look for specific inline style, which is handled differently in safari and firefox ( a space added after a semicolon in safari). We eventually found assert_element_visible.