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
So I just gave a lightning talk about shoes. Here are the slides for talk, it was (mostly) a stripped down version of an introduction talk to shoes, which I gave ate Ruby User Group Berlin.
So here are the slides:
Cheers and thanks for wrov_love.rb – it was a cool conference!
Tobi
Hi everyone,
here go the slides from my talk this morning at the RailsGirls Berlin December workshop. It’s a basic introduction to web applications and Ruby. Enjoy it and feel free to use it everywhere – if you got questions comment
So enjoy RailsGirls and enjoy coding! Hopefully see you around for the afterparty and feel free to grab me any time if you want to ask me something or just chat!
Cheers,
Tobi
Hi everyone,
at first sorry to my English readers but the remainder of this post will be written in German! This is due to the fact that this post is about a german podcast. I promise to write a blog post about learning Ruby in English in the future
German part of post:
Hallo alle zusammen,
vor einigen Wochen wurde nun der Podcast veröffentlicht bei dem ich mich zusammen mit Jan Lelis über das Thema “Ruby lernen” unterhalten habe. Der Podcast geht 72 Minuten und ihr könnt ihn euch hier runterladen. Im Podcast erfahrt ihr unter anderem warum man gerade Ruby lernen sollte, Hinweise auf Lehrmaterial werden gegeben, es wird viel über Ruby und Lernen generell geredet und ein bisschen was über mich erfahrt ihr auch noch 
Eine kleine Ergänzung gegenüber des Podcasts habe ich noch. Ich habe inzwischen noch eine gute deutsche Ressource zum Ruby/Ruby on Rails lernen gefunden: Ruby auf Schienen.
Für die interessierten Hörer gibt es bei den rubykraut podcasts auch noch mehr zu entdecken: Der Podcast ist noch jung aber es gibt auch schon Folgen zu Syntactically Awesome Stylesheets, dem Framework Padrino und den verschiedenen Ruby Implementierungen!
Viel Spaß beim Hören, Feedback ist wie immer willkommen und sorry für die verspätete Meldung, ich war gesundheitlich etwas angeschlagen.
Tobi
Hi everyone,
I just slightly updated my slides Slides: Where to go from here (PDF) for the RailsGirls workshop today.
You can also watch them and download the odp at slideshare.
Cheers, enjoy coding and check out my resource section for even more guides etc. for beginners and advanced coders!
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
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
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
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.
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.
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
Do you know what #rubythankful is? It’s a hash tag, those are commonly used on Twitter to mark special things. There is even a website displaying all the recent tweets that have been marked as #rubythankful. It first came to my notice (or maybe it was even created) during the summer of 2011 when there was a little drama going on in the Ruby community, which I don’t want to blog about since enough has been said and it had a happy ending (1000s of dollars of donations). During that time someone introduced the #rubythankful hash tag and I was seeing many people tweeting about how awesome this hash tag is and how much they love it. So how about now? How many people are #rubythankful these days?
Not so many it seems (screenshot taken on the 21st of December)
At the moment of this writing there is just one tweet up there, which was tweeted by myself… and it isn’t the first time that the situation is like this.
So people aren’t using a specific hash tag on twitter and as a result of that some home page looks pretty empty – no big deal huh? Well maybe it is, maybe it is not. I just think it’s kind of sad. Everybody seemed so excited about it, I was seriously hoping that it would be something that we, as the Ruby community, could adopt as a whole and incorporate into our culture.
At this point a little information about myself: I say “we” but I’m pretty new to the Ruby and open source community myself (in fact I just really started in the summer of 2011) so this is my point of view, the one of a newbie – so full of enthusiasm.
And by incorporating it into our culture I don’t mean simply tweeting with the #rubythankful hash tag every now and then. It’s more the spirit that counts. In the open source community there are tons of people spending a lot of time creating software and then giving everybody full access to it. I think that this is one of the most AWESOME things out there. I mean, think about it, those people and the software they create make our lives easier every day – would it be so hard to say “thank you!” every now and then? All too often I see people ranting about open source projects for how they do things, for changes they haven’t implemented, for changes they implemented etc… these people probably use these tools regularly but instead of getting around to show some appreciation I see them criticizing the work that maybe even helps pay their bills. Of course this isn’t the rule, but it happens.
Saying thank you helps, as it shows a good attitude and it shows open source contributors that their work is valued (I’m always totally happy when someone thanks me for something I did, but well I’m still new). But why stop here? Why not contribute to a project you like? So far all the maintainers I’ve contacted in the Ruby world have been super helpful. Maybe you have this little helper method you use every time when you use a specific gem, maybe people would like it to be part of the gem? Why not just look in the issues on github and see if you can help make one of your favorite gems a little bit better? It’s a cool feeling plus you probably learn much about Ruby and the gem while doing so. I used to be REALLY uncomfortable with Meta-Programming until I read and reused some of _why’s code in hacketyhack!
And if that seems a bit too much, just filing an issue to make the maintainer of a project aware of a problem also helps a great deal!
I also write this post because I feel that this is a more general problem in modern societies, at least in my experience. You can do something well a hundred times and people will rarely thank you or compliment you. However, if after those many times where you did something good you do something wrong, people are way more likely to criticize you/the project than they are to compliment some good work.
I guess my point is that we should probably be a little more thankful for all the awesome things people do. When I was beginning to learn Ruby I read a saying “Matz is Nice So We Are Nice” – I loved that! Unfortunately I have failed to hear it ever again… it would be nice if the Ruby community could readopt this saying and maybe give the #rubythankful a little more love again… or maybe even more.
So will you use the #rubythankful hash tag? I know I will.
So some weeks ago (unfortunately I didn’t really have the time to post this immediately) I ran into the following problem, I wanted to match the following snippet:
Shoes.setup do gem 'twitter' gem 'oauth' gem 'launchy' gem 'feedzirra' end
I wanted to do this in order to transform a (red) Shoes application to a green shoes application (where the gems are handled by ruby gems as you are used to, as it uses a normal ruby interpreter). So how do you match this with a regex? I ran into 2 little problems.
First: I wanted to match Shoes.setup do – end, and everything in between. Unfortunately “.” just matches any single character, no whitespaces. After a bit of google action I found out that the m-switch exists to alter this behavior for the regex. So there we go…
But what is this? It replaced the whole file! How could that be? Oh yeah, underneath there is a whole program with its own “end” – and regexes are by default greedy and try to match as many characters as possible. So everything in between Shoes.setup do (the first thing in the program) and the last end… so how to make a matcher non greedy? Just add a question mark (?) after the matcher!
So in the end the regex looks like this:
/Shoes\.setup do.*?end/m
I could have known this way faster if I would have just stick with my favorite Ruby Regex reference, Rubular! It has an amazing short reference and now is also linked at the Resources page.
Yesterday I ran into a nasty problem while doing a task for Mendicant University (it is an awesome free university for learning Ruby and other stuff). I am not allowed to show you my work from there yet so please go with this kind of constructed example for now:
class Person
attr_accessor :name, :age
# just for demonstration purposes
# (otherwise it'd be initialize(name, age) )
def initialize(&block)
instance_eval(&block) if block_given?
self
end
end
p = Person.new do
name = "Tobi"
age = 22
end
puts p.name # nothing (nil)
puts p.age # nothing (nil)
So what’s wrong with this? What happens in the block is that local variables are assigned. So Ruby doesn’t use the setters for the instance variables.
We could go ahead and do:
p = Person.new do self.name = "Tobi" self.age = 22 end
But who would want that? I don’t want to write self. all the time, it feels like too much repetition to me!
Well Dual-Purpose Accessors to the rescue! Those are accessors that work as getters and setters at the same time (you’ll see how in a second). This way you are able to maintain a nice DSL feel to what you are doing:
class Person
def name(n=nil)
return @name unless n
@name = n
end
def age(a=nil)
return @age unless a
@age = a
end
# keep the other cool setters
alias_method :name=, :name
alias_method :age=, :age
# just for demonstration purposes
# (otherwise it'd be initialize(name, age)
def initialize(&block)
instance_eval(&block) if block_given?
self
end
end
p = Person.new do
name "Tobi"
age 22
end
puts p.name # Tobi
puts p.age # 22
This is more code, yes. But it really comes in handy when you have got a lot of different values you want to set. I really like this technique as it has a real nice DSL-ish feeling to it. However you shouldn’t overdo it, as in this case it’d be overkill and you could just write an initialize method which as name and age as arguments. However I looked for a small simple example and hopefully nailed it.
The idea is taken from Gregory Browns free awesome book “Ruby Best Practices” which is also part of my Resources page.
Opinions or anything else you want to say? Please comment!
PS: Thanks again to everyone on IRC who helped me track down the problem
