Menu
abriraqui
  • reflexiones
  • publicaciones
  • hackership
  • experiencias
abriraqui

While doing testing you learn that #Hackership is more than learning to code

Posted on November 20, 2013December 28, 2013

Tweet

Today was Grey, rainy, gloomy, those kind of days that make hard wanting to do something. They are very common in Berlin but I don’t get use to them and I don’t like them.

Imagen #LeyAnti15MIf you add that, the first tweet I read while having breakfast, was about how the Spanish government wants to approve a law which will fine people between 30 thousand and 600 thousand euros if they do sit-ins in front of the Parliament, if they cover their faces in protests, if they take pictures of the police that they may find offensive (like the police beating up to death, as it happen a month ago in Barcelona), scratches as the ones done by La PAH, which consisted on groups of people affected by mortgages going in front of politicians or bankers houses with banners saying, “it is possible but they don’t want”, while in Spain there are more than 3 million empty houses, bankrupted banks have got the money from the bail out while evicting thousands of people from their houses because they cannot pay anymore the mortgage.

In Spain now there are more than 3 million people that live with less than 300Γ’β€šΒ¬, there are 6 million of people unemployed, 1 million families with no income, education, health care system is being privatize, social cut are endless and one has to wake up reading a law that wants to avoid any kind of mobilization or protest that demands government to think about people rather that about the banks. No, sorry, today the day did not start in a good way.

I still decided to go walking to the hackership, maybe to walk would neutralize the feeling of impotence.

While trying to find the sense of being here, of getting inside of the hackership bubble, I remembered that a couple of days ago I re-read the hackership.org blog’s first post where it says

Everybody needs a hacker

“Hackership is not just some place where you learn to code better, it’s about more than that.”

Just this sentence convinced me that Berlin was the right place to be for now, not sure for how long, but…

I’ve learned all that I know about technology in similar spaces, the hacklabs, in a more political context, more informal, a long time ago. When we founded the hacklab “wh2001-cielito lindo” in 2001, we wrote

Hacklab wh2001 - cielito lindo logo“Because is not very useful and almost sad to learn alone things you can easily learn with others.
Because we don’t want to be isolated of the world that surrounds us.

Because each one’s room is too small to build computer networks.
Because the digital does not substitute the organic.
Because is joyful to learn and do things together”

So yes, I recognize the feeling in the hackership, is more than about coding, is like being home,
By the time I arrived to the Betahaus I was almost convinced that it was such a bad day.

I started reading a comment a friend posted in the blog yesterday about testing. He recommends:

Some tips: you can use shoulda and shoulda-matchers to simplify some common specs about validation and associations:https://github.com/thoughtbot/shoulda
Also, I recommend reading these best practices:
And some good tips by @dhh: http://37signals.com/svn/posts/3159-testing-like-the-tsa

Then we did the stand up round, without the HS organizers, we are growing up πŸ˜›

I checked a couple of urls that I had on one of the endless tabs, they are nice views for calendars:
in form of gem: https://github.com/davidray/twitter-bootstrap-calendar

in form of template: https://github.com/Serhioromano/bootstrap-calendar

Time to commit to github the changes done yesterday. Though I try to do smaller commits locally, for now I will only commit once a day to github :-/

Then began dealing with migrations and associations in rails.
Since an event will have a belongs_to one location association and a location a has_many events association, I had to create the migration for that. The best thing to check the rails guides

Then when running event_spec.rb I had an error:

Loading development environment (Rails 4.0.1)
1.9.3p194 :001 > e = Event.new(:name => '3d lala', :type => "lalala" , :day => Date.today)
ActiveRecord::SubclassNotFound: Invalid single-table inheritance type: lalala is not a subclass of Event

So it turn up that the word “type” is kind of a reserved keyword, that gives this error, so time to rename the column in the table,for that

first do a migration
Γ’ΕΎΕ“ webcalendar git:(master) Γ’Ε“β€” rails g migration RenameTypeInEventsTable

Then open the migration and do the “renaming” part

class RenameTypeInEventsTable < ActiveRecord::Migration
def change
rename_column :events, :type, :event_type
end
end

Then do

rake db:migrate

Now everything should be fine πŸ™‚

Then doing some reading, checking codeschool rspec course, to implement some of the things in my tests.

And finally discovering cool improvements to the working environment

tmux for emacs and rails for emacs

So it looks like tomorrow will be the day to spend sometime trying to improve the working environment πŸ™‚

So finally, it was not a bad day, thanks to be surrounded by nice people

5 thoughts on “While doing testing you learn that #Hackership is more than learning to code”

  1. Jaime Iniesta says:
    November 21, 2013 at 8:08 am

    Hey Carolina,

    Yes it’s great to belong to a hacker community, well, it feels great to belong to any community after all.

    I checked your webcalendar app, here are some quick tips:

    * Avoid storing database.yml in git, it’s better to let each developer decide on her settings. Add it to .gitignore and provide a database.yml.example instead.

    * On your has_many relations, you might want to specify what to do on destroys, with the :dependent option (it can be :destroy, :nullify or :restrict). Like, if a post has_many :comments, if we destroy the post, should we destroy automatically its comments?

    * Optionally, you can do this at the DB layer using foreigner:

    https://github.com/matthuhiggins/foreigner

    * If you’re going to count your associations, like showing how many events a location has, you can make it more efficient using the counter_cache option:

    http://guides.rubyonrails.org/association_basics.html#counter-cache

    * It’s a bit early to introduce cache in your app, but when you do you might be interested in using the touch option on your belongs_to association:

    http://guides.rubyonrails.org/association_basics.html#touch

    http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works

    * I think your model specs should be on a specs/models folder

    * You should hide your secret token, remove it from git and change it to a new one:

    http://blog.berylliumwork.com/2013/02/hide-secret-token-of-rails-in-git.html

    What do you think?

  2. carolina says:
    November 25, 2013 at 3:38 am

    Hey Jaime,

    Thanks for all your advises :-).

    I’ve taken most of them into account or into practice, added to .gitignore database.yml and secret_token.rb and generated a new one πŸ˜‰

    I’ve created the models directory and cached locations πŸ˜‰

    But not sure about the :dependent destroy with events, since even if a location closed or a organizer would dissepear I guess it would be ok to have the event as part of the history of events, right?

    Many, many thanks for checking things out :-)))

  3. Jaime Iniesta says:
    November 25, 2013 at 7:30 am

    Sure, I didn’t mean to say you need to destroy them, but that you have to think about what to do: destroy, nullify or restrict.

    What you cannot do is keep an reference to an ID that no longer exists.

  4. carolina says:
    November 25, 2013 at 8:12 am

    Hi again,
    Would it make sense to say that an Event belongs_to and organizer dependent :nullify .. so if the organizer_id is gone I’ll keep the event without problems?

  5. Jaime Iniesta says:
    November 25, 2013 at 9:09 am

    It makes sense, but the option is on the has_many side:

    Organizer has_many :events, dependent: :nullify

    In this case, when an organizer is destroyes, the events will be kept on the DB, but their organizer_id will be set to nil.

Comments are closed.

©2023 abriraqui | Powered by SuperbThemes & WordPress