Tag: Ruby on Rails

Slides: Ruby to Elixir – what’s great and what you might miss

This is a talk I gave at the Polygot Tech Meetup in Berlin in April. It has parts of my previous elixir talk while adding a new perspective more directly comparing Ruby and Elixir as well as being shorter as it was used as an intro to a fun panel discussion.

Abstract

Elixir and Phoenix are known for their speed, but that’s far from their only benefit. Elixir isn’t just a fast Ruby and Phoenix isn’t just Rails for Elixir. Through pattern matching, immutable data structures and new idioms your programs can not only become faster but more understandable and maintainable. While we look at the upsides we’ll also have a look at what you might be missing and could be improved.

Slides

Hire motivated talented Ruby/Rails engineers from an educational program today!

So if you are here, you are probably looking for some Ruby/Rails engineers. Many companies (and therefore recruiters) are but they are hard to find. Luckily we have programs in place to get more people, especially woman, into coding, such as Rails Girls (and our local Berlin group) and Open Tech School. With the current shortage of programmers I want to urge you to give alumni of these programs a chance. The programs go far in their support, it ranges from workshops, to weekly meetups and even a full 3 month hands on learning program with good coaching/mentoring like Rails Girls Summer of Code (I wrote about ways to continue to learn here). But the last step of success is mostly out of the hands of those programs. It’s in the hands of companies to give the alumni a chance and hire them as an intern, trainee or junior developer (yes I believe some are ready to be a junior developer).

Why should I hire alumni?

I believe there is one thing you need to especially consider when thinking about alumni from such a program: those people made a deliberate choice to quit whatever their former career was and get into programming. You know it can be hard and rough – especially when you are starting and you are mostly on your own. It takes a lot of determination to go through with it. Determination to sit at home and figure out that one bug in your sample application instead of watching TV or whatever. And a lot of passion.

Also they bring in all their rich experiences from their former careers which can help in a number of ways that none of us can predict. They’ve got ideas that I couldn’t even dream off.

Moreover programming and technology is full of self-taught individuals, so it should be second nature for us to give them a chance. At a recent Berlin JavaScript user group I asked how many attendees had undergone formal computer science education – just ~60% of them raised their hands. Which means ~40% didn’t – quite impressive!

These are not your common graduate students

When you assess these programmers for a position please keep in mind that they haven’t undergone any formal education. They know about Ruby and Rails but they might not know about Java or the lambda calculus or the inner architecture of a CPU or whatever they teach you at a university… (note: I’m studying and am at the end of my Master studies).

The question is: is all that knowledge really important? In my opinion: No it mostly is not! I believe that a lot of this knowledge is not necessary for a specific job and that you can pick up what you need when you face a problem. Example: UTF-8. It’s really great to know how UTF-8, Unicode etc. work but what are the practical implications? For me it mostly boils down to: “Oh look some character is not displaying correctly. Okay let’s change the encoding to UTF-8. Works.”

There also are a lot of things that you rarely ever touch again like Turing machine, formal grammar, details of how the Windows Kernel works, higher math, TCP/IP stack… I could go on. Of course this all depends on your field of work: If you do 3D computation you probably need higher math. If you do network security or some optimizations you need good TCP knowledge (which is totally interesting by the way). But most of the time you don’t and then when you get to it you will have to refresh your knowledge again either way.

Also alumni sometimes might not know what a specific term means (e.g. polymorphism) but chances are they already use the concept – they just don’t know the name.

Meet some Rails Girls Summer of Code alumni

As you might know I’m from Berlin and so I know some of the local teams. A lot of them are looking for jobs right now and I asked them if I could include them in this blog post and here are the people that I know, asked and said yes. I want to highlight that I know all of them as extremely motivated and capable learners and programmers. All of them were coached during the summer by coaches I know and highly respect 🙂

I might not be up to date with their current job status, so some of them might already have a position. In that case, keep them in mind for the future 😉

So without further ado, let me introduce:

Susanne and Tam from Team Highway to Rails

I’ve known Susanne and Tam for some time – they are among the founding members of the rubycorns, a weekly study group that Til and I coach. The two of them have always shown a great interest, motivation and effort (especially when working on homework) in the study group. So it was no surprise to me when they applied for Rails Girls Summer of Code. Unfortunately they were rejected. But here comes the real surprise and what really impressed me: they didn’t even think of giving up. Nor for a second. They buckled up, put in the extra effort and looked for an opportunity how they could make it happen for them either way. That’s some real motivation right there. And they found Absolventa where they did their voluntary Summer of Code as Team Highway to Rails. They worked on event_girl an “open event-logging system with triggers/hooks to run arbitrary tasks when an event is matched or not matched.”.

Want to get in touch with them? Great!

Carla Drago from Team Inchworms

Carla has been one the first students we ever had at Rails Girls Berlin and went on to be one of the founding members our famous first study group the Ruby Monsters. After finishing their initial project the group went on to their next project: the speakerinnen liste. The “monsters”, as we call them, now help on multiple workshops as coaches teaching new attendees Ruby on Rails, which is awesome. As a little fun memory from myself: I once went to their project group meetup several months ago eager to help them with problems. Many didn’t need any help at all and when they did it was a hard problem, that took me quite some time to figure out. During this summer of code Carla worked as a member of team inchworms on sinatra and farmsubsidy. Here is Carla’s LinkedIn.

Laura Wadden from Team Railsgrrls

I met Laura for the first time when she was in my group at our Rails Girls Berlin anniversary workshop. Right from the start I noticed that she had an extraordinary fascination for programming. Laura has a strong background in working with nonprofit organizations, fundraising and event organization as this is what she mainly did before her journey into coding. During this summer she worked on the learners directory and a new programming language on top of Rubinius called lani. I’ve been the mentor for the learners directory, but her deep interest into how programming languages work really impresses me. During the summer of code this team had their own table at the Soundcloud offices – giving them one of the best learning environments one can think of with lots of awesome people around to help. Oh and here is her LinkedIn profile.

Nina Breznik of Team Spree Girls

Nina also had the luck of being able to work from the SoundCloud offices, that’s where I met her. Her team is working on the spree commerce project an online web shop written in Rails. It’s quite the challenge to understand a system as complex as spree, even more so as a beginner. As far as I can tell they are doing well and making progress – also thanks to the supporting environment. You can find her on LinkedIn.

A few words of thank you

Last but not least I want to thank everyone who was ever involved in a free educational program. Be it sponsor, organizer, coach or mentor. You are awesome! Without you all of this would not have been possible. I especially want to highlight Sven Fuchs and TravisCI without whom Rails Girls Summer of Code would not have happened. Period. Also github for their gracious donation (and for being super supportive and awesome in general). And to SoundCloud once again not only for their donation, but for offering work spaces and coaches  to 5 students (did I forget anyone?) and the possibility of an internship for two students afterwards.

I’d really like to thank each individual but this blog post is too long already. So this heart will have to do: But really, thank you so much!

And as for the purpose of this blog post: If you want to hire or just talk to any of the programmers listed here please do so. This of course not only goes for them (those are just the ones that I happen to know pretty well and got permission to “advertise” them). This goes for everyone. There are lots of people out there who want to make a career change and lots of companies in need of good, passionate developers. Get together, together you can reach your goals. Help them make the next step and I’m sure you won’t regret it.

Web Application introduction Slides from Rails Girls Berlin May 2013

Hi everyone,

It’s the well known web application introduction, this time without the Ruby introduction as the Ruby Monsters already did this! This time it also has a Bentobox exercise, so enjoy!

Hope you enjoy the rest of the workshop and that the slides help you with your learning 🙂

Oh, and a link to the cheat sheet which I mentioned.

Cheers,

Tobi

Teaching a course about web development at Humboldt University

Hello everyone,

just a quick note but I’m extremely excited to finally announce that I will be teaching a course about the basics of web development at Humboldt University Berlin. The course is meant for bachelor students who don’t study computer science. It’s a total basics course, no prior knowledge required. The course will start with basic HTML and CSS, then we’ll get into some Ruby and then some Ruby on Rails. So in short, it could be perfect to be the start of your journey into Programming. And a useful skill to have, in the spirit of this awesome video.

The course will be every week on Wednesday for 9 weeks (starting in May) for ~5 hours + breaks. The course will be held in German. The course is limited to ~14 students.

Link to the full course description (German)

If you are a student interested in the course, feel free to get in touch with me for questions etc!

In the end, a big thanks to everyone who helped making this happen! Especially Dajana 🙂

Cheers,

Tobi

Slides from the Febuary 2013 Rails Girls Berlin workshop

Hi there,

So here are the slides from my talks from the Rails Girls Berlin workshop on Saturday, in their chronological order:

Introduction to web applications (the one with the map)

I love programming

The slides are Creative Commons Attribution license – so feel free to share and modify them but say where you got them from 😉

And as a little bonus I was allowed to post the beautiful Rails Model View Controller comic drawn by Anja of our Ruby Monsters project group – the comic is Crative Commons as well if I understood her right!

mvc1

mvc2

Cheers,

(green) Tobi

Setting up PostgreSQL for Ruby on Rails on Linux

So every once upon a time I run into the situation, that I have a newly set up machine and have to configure my system again to use PostgreSQL and play nicely with Ruby on Rails. And I don’t want to have to google the set up every time, hence this post (and of course to help people with similar problems). Why PostgreSQL? Well many people like it and you need it for instance for deploying on heroku and your development environment should be as close to your production environment as possible.

What I do here is a way that works for me on my Linux Mint Debian Testing machines. Be aware that this is my development set up – I don’t use this in production.  I’m no PostgreSQL expert so, this just works for me and I hope that it will for other people as well :-). Suggestions/Improvements are welcome as always.

Let’s get started! So at first we have to install PostgreSQL:


sudo apt-get install postgresql

After we’ve don this we need to create a user in PostgreSQL. So we use the user account of PostgreSQL to create a user with sufficient rights. I just take my own account and grant it sufficient rights with PostgreSQL. Don’t forget to substitute my username with yours!

tobi@speedy ~ $ sudo su postgres
[sudo] password for tobi:
# the behavior of createuser seems to have changed in recent postgresql versions
# So now do the following (-d says allowed to create databases):
postgres@speedy /home/tobi $ createuser tobi -d # replace tobi with your user acc name
# In older versions it used to work like this:
postgres@speedy /home/tobi $ createuser tobi # (substitute with your username)
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) n

At this point it would be good to install the pg gem – which is the adapter for the PostgreSQL database. So simply add

gem 'pg'

to your Gemfile. Also make sure to replace existing database gems – like sqlite. Now run:

bundle install

to update your dependencies. That should go smoothly, otherwise you are probably missing dependencies.

Now you still need to modify your config/database.yml. Most of all you need to change the adapter to “postgresql”. Here is the development part of my database.yml for reference:

development:
  adapter: postgresql
  database: ArbitaryDatabaseName
  pool: 5
  timeout: 5000

Make sure that the different environments (development, test and production) have got different databases (meaning the database property should be different). Otherwise they will influence each other and you don’t want that.

In order to finish the set up you need to create all the databases, which should work flawlessly by now:

rake db:create:all

When this is done you should be able to “rake db:migrate” your database as you are used to (and be sure to do so).

I hope this post helped you with setting up PostgreSQL for Ruby on Rails on Linux. If something didn’t work for you, you feel that a step is missing or you just have a useful tip – please feel free to comment!

Updated Resource section

Hi everyone,

just a quick note I updated my beloved Resource section with some quite nice new resources. I also restructured it so that Ruby and Rails got some distinct sections.

When I started this blog sharing resources for learning how to program was pretty important to me and it still is now. I love both teaching and learning. I hope that these resources can help you to learn how to program, teach someone how to program or improve your own skills. But it’s not only programming there, my favorite topic “agile software development” is also mentioned!

Most of the resources are free so go ahead and check them out.

Enjoy and have fun!

Tobi

4 lessons learned from teaching at Rails Girls Berlin

This is just a little post recapping some of my experiences from the last RailsGirls Berlin workshop. By the way, we’ve got a new workshop upcoming this Friday and you can still register! Most of this is a reminder to myself in order to be an even better coach at our next workshop 🙂

1. irb can be great for teaching – but confusing as well

I love irb for teaching. You can show many things quickly and instantly. And you get feedback. You can play. It’s awesome.

However, especially for real beginners it is kind of confusing, even more so if it is the first time that they work with a console. So it’s hard to distinguish what irb is and what the normal console is. In a later mentoring session I also had someone who disliked irb as a whole and rather wanted to write a real program with real files. Everybody likes to learn his/her own way 🙂

However my main take away with irb is the following: Be aware of the nesting! And by that I mean missing parentheses and keywords! You know the result: irb is waiting for the matching keyword/parenthesis. Beginners often don’t notice this and are just wondering why it isn’t working and behaving like with all the others. During our introduction to Ruby this was one of the most common blockers I saw, especially when we started working with blocks. So to get them out of this: Ctrl + C

2. Restart the server after installing a new gem

We all know this one. In order to pick up on some changes the rails server has to be restarted. Although when you’re teaching multiple students it’s sometimes hard to remember. So if a step involving a new gem isn’t working make sure it is installed and restart the server.

3. Save the damn file

Yes save it. Please do. I know it’s the simplest thing in the world but we are sometimes so used to saving our files that it doesn’t even come to mind anymore. I once spent 15 minutes discovering that an unsaved file was the cause of an error. Before that another coach had already spent ~30mins on the same problem. We checked everything until we noticed the little star next to the file name in the tab bar. Then we saved the file, which we had previously looked at like a million times, and everything went well.

4. Explain, but simplify

Explain what which part does but don’t aim for perfection or total correctness. In other words: Lie to simplify. Focus on the most important knowledge. I gave very short introductions to the MVC-pattern (while looking through the code) and refined them until the student seemed satisfied.

And don’t omit the explanation. I know that Rails involves a lot of magic and it might be hard to explain, however I heard from some students that nobody explained the distinct roles of the model, the view and the controller to them. They didn’t know what happened where. This left them really dissatisfied. They’ve built this awesome thing but had no idea how it works.

I hope that these tips might be helpful for you when you are coaching. There are probably some more of these to come after the next workshop 🙂

Secure your Rails apps!

It is time to secure your Rails apps! I mean it is always time to do that, but (as you might have heard) github just got hacked. So if you have a public facing Rails app you should really ask yourself “Can I be sure that our security standards are better than the ones of github?”

What happened?

A russian programmer started an argument about the mass assignment vulnerability and how Rails could provide better protection against it. However the issue got closed again and again as it was basically argued that securing the app is the responsibility of the programmer. So he took a different approach, demonstrating that the vulnerability is even present in one of the biggest and well-known Rails applications: github itself. He managed to make a commit to the Rails master branch, which turned into a lengthy discussion including some memes. He also created a ticket which appears to be from the future by abusing this vulnerability. For the sake of completeness, he informed github of the presence of these vulnerabilities first. You may also want to checkout github’s summary about the incident.

I don’t want to discuss whether his actions were right or wrong, but in the end Rails changed the default for new apps to make this vulnerability less common, which is a good thing to my mind.

What is this mass assignment vulnerability?

The mass assignment vulnerability is described pretty well in the Rails security guide – which you should absolutely read in its entirety! Basically the problem is the following:

Whenever you scaffold generate code for some resource in Rails, which is pretty common, you can see a snippet like this for creating a resource:


@user = User.new(params[:user])

What this does is create a new user, with all the attributes set to the values that got transmitted from a form and are now in the params[:user] hash. This is very concise as here you can mass assign everything the user entered: name, email, description etc. Cool right? This is why it’s not only generated but also written pretty often. Yeah so far so good.

The problem starts when you got some attributes in your model, which you don’t want your users to have direct access to. For instance the boolean admin, determining if a user is an admin or not. The attacker may use tools to manipulate the html form and hence the transmitted parameters to include the key value pair: admin: true ! So params[:user] may look like this:

params[:user] = { name: 'Evil', email: 'evil@example.com', description: 'I am an admin soon', admin: true}

And all of a sudden our newly created user is an admin and can do everything he/she wants to do – which was totally unintended by the developer! Of course this also works with updating records and not just with creating them.

This issue is actually pretty damn well-known and was also a big story during the start of the Diaspora social network (among many other vulnerabilities).

Holy sh**! What can I do to protect my app?

Well in general it is pretty easy to protect against this kind of attack you just have to add attr_accessible to all your rails models. This white lists the attributes, that can be assigned during mass assignments. Everything else can not be assigned during mass assignments. So for our example this would look like this:

class User < ActiveRecord::Base
  attr_accessible :name, :email, :description
  # rest of class omitted
end

Notice that admin is missing from the attributes after attr_accessible. That’s because we don’t want to have it mass assigned during creation/update. So now go ahead and secure your Rails applications, or stay for the pro-tip…

Pro-tip: Use Brakeman

Brakeman (can also be found on github) is a static analysis tool (fancy term for: looks at your code, doesn’t execute it), looking for vulnerabilities. So it is a vulnerability scanner for Ruby on Rails. It takes a good look at your source code and informs you of any found security vulnerabilities including the confidence of the scanner that this is indeed a problem (e.g. not a false positive). It seems to find mass assignment vulnerabilities very reliably and it also informed me of a possible Cross-site scripting (XSS) vulnerability in my Rails version (3.2.0) and recommended an update to 3.2.2, as this version fixes the problem. So it is also pretty up to date and I can only recommend it. Now go ahead and gem install brakeman or add it to your Gemfile.

However the default output isn’t very beautiful on my system and hides many important parts so I’d recommend you to run:

brakeman -f html -o brakeman.html path/to/app

For a bit prettier html output. Hope that this helps. And don’t forget to add this brakeman.html to your gitignore. Oh by the way: they also have a plugin for Jenkins/Hudson.

So now go ahead and make your Rails apps more secure!