Feb 212014
 

Rails Girls LogoA bit more of a year ago, I got to know about RailsGirls initiative, I joined one of their workshops and had a great time. So I joined other of their initiatives, like meeting on Sundays in a more informal way to have a coffee while talk about coding, and of course Rails Girls Summer of Code!!, where with my pair @juliaguar, we contributed to Diaspora free social network.

After one year of profiting of all the good work done by RailsGirls, I had the feeling to give back something, so once I knew the Hackday was coming up and also knowing that @phansch was taking part as a coach, made me take the decision to sign as a coach for beginners.

Honestly I must say I had no clue how to do it, nor did I have much time to think about it. Saturday morning arrived, I had a cold, I was tired and thought OMG! how am I going to be able to explain anything. Anyway, the fact was that I was going to the Hackday and let’s see.

After a first “hello” , a coffee (10 a.m. is a good moment to have a coffee on a Saturday), and realizing that I knew some people,  we did a round to introduce ourselves, our name, experience, expectations about the workshop. This time there were around 5 complete beginners and the rest were study groups that work on a week basis and the Hackday is a good excuse to impulse a bit more the project.

Hackday whiteboardSuddenly I forgot about the cold, the fatigue, it was fun being there! So three of us wanted to coach the beginners which was really cool, after setting up rails, discussion a bit how to proceed, where to start from, what was the background of everybody.

We started and decided to have the RailsGirls tutorial as a guide, but we would not use so much the gems, but explain how things worked from scratch, so that Rails “magic” could be better understood. We used the white board to explain the main MVC principles, then went into see how  routing works, how models, controllers, views look like.

We stopped for lunch, everybody brought something and then we shared it :-), and after lunch, for an  hour or so, we had lightning talks, and yes I also gave one, “Free/Libre software and Open Source, because social responsability matters”

After the talks, back to coding!!
At Rails Grils Hackday
So yes, that was how we spent the day, it was a really nice experience, that I would like to repeat 🙂

 

 

 

 

 

Jan 302014
 

travisci-300x225By now we know that testing is important or more than that, vital!! so our apps will always have tests. If you have your code on Github the there is the possibility of using  Travis CI as a Continuous Integration Service that is free for Open Source projects. So every time you do a commit, your tests will be run by Travis and you’ll be notified by mail if they pass or not.

Travis CI documentation is great, everything explained but sometimes when you have a simple project, you just don’t want to go through all the documentation, figure out how it all works, etc you expect to be able to copy&paste a simple configuration file and done.

So, I’ll share the files for a simple case like the webcalendar. Where for testing I’m using rspec, the test DB is sqlite and since the app is deployed in heroku my production DB is postgresql. The configuration files needed are config/database.yml and .travis.yml

The database.yml file looks like

sqlite: &sqlite
adapter: sqlite3
database: db/<%= Rails.env %>.sqlite3

postgresql: &postgresql
adapter: postgresql
username: postgres
password:
database: webcalendar_<%= Rails.env %>
min_messages: ERROR

defaults: &defaults
pool: 16
timeout: 5000
host: localhost
<<: *<%= p ENV[‘DB’] || “sqlite” %>

development:
<<: *defaults

test:
<<: *defaults

production:
<<: *defaults

Don’t worry about seeing here the user and password of the postgreql DB, they work on Travis but are not the ones used in Heroku 😛 …

The .travis.yml file on your root directory that looks like

rvm:
1.9.3

env:
– DB=sqlite
– DB=postgresql

before_script:
– psql -c ‘create database webcalendar_test;’ -U postgres

script:
– RAILS_ENV=test bundle exec rake –trace db:migrate spec

Using this configuration files is working for me, so I help is of some help to some else and does not have to spend a couple of hours trying to figure out how to make travis-ci work on your github account 🙂

 

 

 Posted by at 12:45 pm
Jan 232014
 

http://cargocollective.com/markwangillustration/concepts-sketchesThe year ended after having a great time at the #hackership, Batch-0 officially ended there but for the learners it had not been enough time, and we wanted to continue meeting and learning together, so we launched the proposal of continuing in an unofficial second part of #hackership. Hackership organizers agreed that it would be nice and support us, so we found a new space in K9, and there is where we are now meeting, following the same methodology learned during the Hackership, stand-up rounds, presentations, etc.

So now, let’s see at what point am I. After reading the Dive into HMTL5 guide and implementing some part of the things learned into my webcalendar pet-project. One of the things that interest me more, in general, is semantics, so I’m very happy to see that HTML5 is including semantic markup that can also be extended with the use of microdata.

After changing HTML to HTML5 the main part of the events index page, now looks like this

<body>
<header>
<h1>Webcalendar</h1>
<nav>
<%= render “shared/top_menu” %>
</nav>
</header>
<section>
<%= yield %>
</section>
<footer>
<%= render “shared/footer” %>
</footer>
</body>

These are the basic things:

header represents a group of introductory or navigational aids
section is an element represents a generic document or application section
nav represents a section with navigation links
footer represents a footer for its nearest ancestor sectioning content

I wanted to extend the semantics with microdata, in the same partial _event.html.erb, we have the following

<td itemprop="name" itemscope itemtype="http://schema.org/Place"><%= event.location.name %></td>

<td itemprop="name" itemscope itemtype="http://data-vocabulary.org/Organization" ><%= event.organizer.name %></td>

itemprop refers to the element property (quite obvious, right?) , in the first case is the name of the location and in the second case is the name of the organization.

itemscope, since microdata is about extending semantics you always need to declare the vocabulary that you are usingis and the scope of the properties. You do this by adding the itemtype and itemscope attributes on the outermost element that contains the other elements that contain the actual data. In our case we are using the vocabulary that is defined in http://data-vocabulary.org/Organization.

Is not a too sophisticated use of HMTL5 but its a start :-), things that would be nice to implement is the usage of datepicker and to take the webcalendar offline, this will be pending things for the near future, hopefully.

I was going to write something about the experience of learning how javascript, jquery and ajax interact with Rails, but I’ll leave for the next post, now I feel like going back to code.

 

 

Dec 242013
 

cup - hacker insideHackerships experience has been amazing and  in every amazing experience one has also to evaluate things once it’s over.
The good thing about evaluation is to better  understand the processes in which you took part, to learn from them and also see how can they be improved, of course everything from a very personal experience, from a very personal point of view.

To keep it simple, I’ll just try to list all things learned and the suggestions I would have for future batches.

It is difficult to specify all the things learned since many times is just about clarifying concepts but let’s try to do the list, first of the technical stuff

1.- Test Driven Development, it was the first time that I’ve done TDD and really I’ve find out that is great, I don’t know if to do everything 100% TDD but for sure, for the start and everytime you want to implement a feature, TDD helps me to think about what the app should do and to write the code step by step

2.- RSPEC (unit tests and integration tests), I had used rspec, but normally for doing tests after having the code, which means that normally I didn’t go too deep into it because writing tests was kind of “optional”.

3.- Ruby & Rails (revised the basics,  basics of metaprogramming, learned about implementation of webservices via REST API). Ruby & Rails are endless so I cannot strictly say what I’ve learned, many things I had seen them but not remember them, other have been new, others I thought I understood them but it was not so quite so, so being able to do an app starting from scratch, to have had Q&A sessions has been just great to feel more confident.

4.- GIT (general overview of the usage of git) during the Rails Girls Summer of Code, we used quite a lot of GIT and since it was inside a big project I would say we did kind of a semi-advance use of it, but not really understanding all that was going on, so after hackership it has been more about understanding than seeing something new, which is cool!

5.- Javascript (js basics, interaction with rails and an overview of several frameworks), here is where I miss having more hackership time, I’ve done the very basics but not really got the feeling of JS

6.- Processing (Introductory session), finally seen how processing works after years of hearing about it 🙂

7.- Arduino (Introductory sessions), cool to play around, to see that I actually have no idea of how circuits work, and willing to spend more time on that, is there an spare life to borrow?

8.- The existence of Haskell, Scala .. coming to know things that I did not even know that existed is cool

9.- SCRUM methodology or at last some of the basics

10.- Written a post every single day, which is the first time I manage to do it
11.- Walk everyday 45 minutes
12.- Be on time

The last for things are not technical things but in the case of SCRUM I think is really important to get familiar with the way of doing, since it’s apply in many working environments, though SCRUM I guess is not one strict methodology but something that people tend to adapt to their needs or their particularities.

To write a post everyday during 6 weeks in my case means, that I’ve been highly motivated to be able to do so. I do like writing, I like it a lot but normally I don’t find the time, or how to write about something or…but when hackership started I decided that I wanted to do it. In the last years I’ve been more aware of the importance of story telling  but, except in a specific context, I had not manage to carry it out it a continuous way, hackership has motivate me enough as to be able to narrate the everyday life, for that I set a couple of rules to myself, one I would write without doing much revision of texts, not much thinking about it, just say it, another one was, it not just an exercise to let others know but also for me to revise things learned, thoughts had, references read, articles discovered, writing has been part of the hackerships flow.

Walking 45 minutes, everyday, was mainly a need, my body would not be able to survive without doing some exercise, feel some movement, see the daylight even the dark days, but of course is also a sign of motivation to do it before 10am, it has been nice to see Berlin during the morning, empty streets, full trams, bikes cycling in queue, discover new routes to places, get some fresh morning air.

And to be on time, well that has been quite a challenge, I’m normally the sort of person that arrives almost on time but not so much on time, except for key meetings, dates, etc. In my daily life, time is something flexible, more or less I try to be on time, but when doing things, is also important to finish the task you’re on, when meeting someone in the street is always important to stop and say hello properly, when you need to buy something is better now that later because who knows what can happen later, so yes normally for me time is flexible, a flexibility of 10-15min but during HS I’ve been almost British.

To that we have to add, other kind of things learned in workshops that are not specific but that help to understand the developers real environment, as the meeting of front-end and back-end, how to get unstuck, how to proceed with job interviews … probably more that I’ve now forgotten, but that have helped not to only learn about a specific language but how technology works (sometimes).

Mafalda But even if everything has gone pretty well and I’ve enjoyed a lot, I do have things that I’ve missed and suggestions for future batches,

1.- Pair programming, I missed working on teams also because many of the tools learned make more sense when used in teams. Pair programming can be s good approach. This is something which I’ve had heard for a long time but also not really pay much attention to it, or let’s say not had the option of really doing it, this summer in the Rails Girls Summer of Code, we did pair programming and I really liked it, is a way to do many of the things that we say is good for learning but that then we don’t do.

For example, if you do a proposal of how to implement something you have to explain it, you have to be able to listen to improvements to the proposal or do something different that your pair proposes and makes more sense, you learn to make better questions, you have 4 eyes to check things, code or find out what was miss spelled, you learn to work in a team, so of course it can happen that you don’t like your pair, but as a whole I would say that pair programming is a better option for learning, can also mean to do some stuff on your own but knowing that your pair will check it, use it, etc.

2.- Working on open source projects, here I won’t be too objective, I am a real fan of free software, actually that is what got me into technology, so  to include as part of a learning process the knowledge of how to collaborate with others in already existing software, you have to read code, you have to ask good questions, you can contribute to a product that is for the benefit of a community and if your contribution is merged it feels cool!

So, I think is good for everyone,  to get more developers that can support free software tools and to take advantage of the great knowledge that is out there, so it would be the following thing to do after the “read fucking code”, which is possible because is open.

3.- Schedule workshops with a bit more margin. I think one feelings was that sometimes the workshops proposed were of great interest so you didn’t want to miss them, but at the same time the schedule change so much that it was difficult to organize your work, not sure how to improve it, but perhaps think in advance which workshops could be done earlier in the batch process, times …

4.- Have sessions in a “coderetreat” way of doing. The experience of participating in te coderetreat global day, has showed me that it is really a good way of learning or improving to code. Coderetreat is basically

  • TDD over just one problem, Conway’s Game of Life,  the basic issue is to think how to approach a problem, not so much if you know a programming language or not (you can be a beginner and just help to think on the approach)
  • Do pair programming and see and feel that there are a lot of different ways of doing things and that there is not the “best” way of doing them
    to start from scratch so you don’t feel attach to the previous code that can be worse than the one you can start in the next session
  • to have 45 min sessions which means that you know you are not going to be able to implement the whole problem just to set it up so you don’t feel the stress of having to finish anything like in hackathons just the aim of learning new ways
  • the option to see how things work on a different language that is not the one that you normally use, so pairs won’t be separated depending on languages

I may forget things now, but I’ll write a post just to tell about the experience on the coderetreat global day.

For the moment is all I can think of as an evaluation, I may update it if more things come to my mind.

 

 

Dec 202013
 

Everything has an end, or changes its state. That is what is happening with hackership, the everyday life comes to an end, but for sure is not the end, that is just not an option.

The day started as always, or at least I suppose, the last day I did not feel like working, I had woke up thinking on all the pending stuff that I have to do before going home, so I went late but when I arrived to Betahaus I saw everybody amazingly concentrated, as if it were a normal day, not the day of the closing event. It seemed to be just another hackership day, I guess it was a a way to stop time, to retain hackership, just some bags with Christmas cookies gave us a hint that it was a different day, Dec 19th 2013.

At 15h we had our last round of presentation of the project that we were working on, the moment to share the coming future and to thank every single person for making this experience happen. No-one new what to expect but I think everybody has the feeling that this experience exceeded expectations.

Empty space

After this last round, it was time to rehearse the closing event, everything had to be perfect, so there we were, talking to the non-existing audience and ourselves. We heard the introductory speech, the learners panel was a good moment to share the experience of participating in hackership, and of course was unique, not all the ideas and comments were repeated afterwards, some questions were modified, some improvised, but the conversation was flowing.

On the back others were setting up their laptops, where they would show the work done during hackership, it was time to share what had been learned, while also it was time to set the table with cookies, sweets, cake and some other stuff that would make the socializing part a bit more entertaining.

preparing Hackership closing event

We also rehearsed the graduation ceremony, OMG!! I thought I would always skip this kind of things, too old for this but this time, the certificates were going to be awesome, so it was worth it 😀 .. also sometime ago I learned that certain rituals are kind of ok, is just an excuse to gather, to share, to present things to others.

The rehearsing time took longer than expect so basically we linked it up with the “live” event. People started to arrive, some known faces, is always nice to see friends, some unknown faces, nice to see them too, it means other people is interested in the project, to support it, to join it, to…who knows?

So I think everything went perfect, the introduction to the idea of hackership

introductory_speech

the learners panel which was great, many things shared but I was surprised that when talking about the workshop about how to get unstuck, nobody mention the most important clue “Read fucking code”, maybe it was not the right thing to say in a ceremony :P, a great video summarizing the 6 weeks,

hackership learners panel

 

the graduation ceremon,and at the end, we gave the organizers also their certificate, for making this happen and with it some invitation to a spa, just to relax a bit after all these crazy weeks and some other stuff that we thought they would like.

Without the organizers, hackership would have not happened, so many, many thanks!! and also thanks to the hackers in residence that spent time with us 🙂

 

indiegogo logoAt one of the most important things that happened during the event, was the launching of the crowd-funding campaign, so yes!! time to donate some money for an awesome project, learning experiments like this are worth supporting them, so please donate and spread the word, thanks!!!

 

 

Little by little people began to leave, time to go, to relax, some stayed drinking calmly the lasts drinks, everything went quieter.

But I said that the certificates were going to be great, here is the proof, checksum included  🙂 … nice right?

hackership certificate

 

And this seemed almost the end, but if you look closer, life is like a fractal, when you think is over everything starts again, so stay tuned!!