Monthly Archives: February 2014

Sinatra for Beginners

Learning Sinatra

At Rails Girls Next we actually didn’t do any Rails at all. There were three components which took up the entire day and they were 1) Coding in pure ruby 2) Testing with minispec and 3) Introduction to Sinatra.

I hadn’t heard about Sinatra until the day before, when my Coder Friend suggested I use it for my new flight app idea. Apparently Sinatra is about 1% the size of rails – so it’s lightweight. Having said that, it’s just as easy, if not easier, to set something up in it.

To learn more, I did these tutorials about Sinatra, on Net Tuts, and I’m linking to them here, because actually navigating between them isn’t so easy.

Unlike Rails, when you start a Sinatra app, you don’t have all files and everything set up. You just install your Sinatra gem, open a new file and type in require ‘Sinatra’. This is the start of your Sinatra app.

So in that base file that you just opened, you can write all your ruby. Which in this case included;

  • Requiring gems
  • Routes
  • Helpers – e.g. the thing for XSS protection below
  • Linking to a database

You can also make a public folder to put in your css files, images, etc.

The other folder you can create is a ‘views’ folder, where you put all your html pages (saved as erb files).

EDIT: I have just discovered that if you want to add external css and js files, like in bootstrap, you need to put them in another folder in your root directory, and call it ‘public’.

I have now done the tute, and I am going to tweak it to make it my own, BUT, I still have a few questions to ask someone at the next opportunity: 

Questions About Sinatra / Things I need to investigate more

You may be wondering “what about SQL injections?” Well, DataMapper handles that for us just as long as we use DataMapper’s methods for getting data from the database (ie. not executing raw SQL).

  1. Must look up what they mean by “Using DataMapper’s Methods”
  2. How do I organise my base Sinatra file? Should I have several of them when they get very big? Should the database connection go in a separate file?
  3. How do I know what order to put my routes in? E.g. the tutorial said I couldn’t put my RSS one above my get :id one – can I not put anything above that get :id one?

Just remember to escape all user-submitted data when creating other web apps in the future!

And finally, this quote, makes me think I need to make a big list of all the “And just remember…”. Maybe a checklist!

 

 

Leave a reply

Ruby Conf Sydney 2014

Only 2 days ago I was feeling a bit apprehensive about attending Ruby Conf in Sydney. I wasn’t sure what I would get out of it, I thought I wouldn’t understand any of the lectures and that because I wasn’t a real programmer,  I wouldn’t fit in.

However, after the very first keynote, I was inspired, reinvigorated and so glad I came. The take home for me from that first keynote was that – yes, programming and developing apps is an exciting and totally possible way for me to influence the world around me – and I want to keep going ahead and trying to do that.

The Highs of Ruby Conf

  • The talk about alternative pathways to becoming a programmer
  • The venue – Luna Park-  with beautiful views of Sydney Harbour, the Harbour Bridge and the Opera House.
  • Getting to go on the rides!
  • Seeing the people I had met at Rails Camp, Roro and other events.
  • The second keynote, which was on diversity, humility and civility by Pat Allan. You hear some horrible things online about the brogrammer culture. These words, coming out of the mouth of a popular Australian programmer, made me feel really hopeful.
  • Missing out on a few of the talks, which meant that I got to have longer, more interesting conversations with people outside the frantic/loud group time in between talks.
  • Being reminded AGAIN about how lovely, welcoming, helpful and interesting the members of Ruby Australia are. One of the mentors from Rails Girls Brisbane, which I attended last June, remembered me and came over to ask me how my coding was going. Just so lovely.
  • Getting some thoughts, from a range of programmers, about the apps I am currently building.

The Lows of Ruby Conf

  • I didn’t go to the Yum Cha, which meant I also missed out on surprise Karaoke!!!

What I Learnt at Ruby Conf

  • We need to keep innovating, and learning how to do new things, because there is skill erosion when things are too easy
  • That with the rise of the international community, and the ability for remote working or outsourcing, you can either be a commodity or part of the creative class – i.e. what value will you add above being able to code?
  • That maybe I should start using MiniTest instead of Rspec, because MiniTest is lightweight and ships with Ruby.
  • That I should do a Computer Science course online (or at least the first few subjects) – Stanford was recommended to me.

Things I need to look up now

  • Learn how to use MiniTest
  • What is mocking/stubbing?
  • What is a struct?
  • Database theories – ACID vs CAP
  • What is a distributed system (databases)
  • Wtf is a node? (Database)
  • MongoDB (everyone making fun of this)
  • Clustered Databases
  • Node.js
  • Middleman?
  • Blocks vs Procs vs Lambdas

Diversity in the Speakers at Ruby Conf

The idea of female speakers is something that has been discussed in programming circles online a lot recently. The final keynote speaker at Ruby Conf, Eleanor Saitta, finished her speech with a slide of names, (all women I assume) saying something along the lines of “These are just 34 names of female speakers I found within 5 minutes of searching on Google, and who would have been great speaking at this event.”

Unfortunately she was the last speaker, and just after she finished they got all the speakers on the stage – which demonstrated quite clearly, how white and male the lineup was.

Of course the Ruby Conference had tried to get female speakers, and it featured a male speaker who spoke of the importance of diversity in his keynote. But as Eleanor pointed out on Twitter, all she can judge it is by the results – not by the trying.

That old favourite “but we just want the best speakers” was also trotted out. Conference organisers don’t want to choose female speakers, just for being female. They think their attendees deserve the best speakers no matter what their sex. But, with the massive gender imbalance in coding, the odds of getting the best speakers is always going to be in the males favour.

Saying you want female speakers, but only if they are the best speakers, doesn’t immediately result in diversity. Because in an 80% male industry, the best speaker is more likely to be male.

To make it more even you would have to either

a) increase the number of women to be 50% – and there is a lot of work being done to encourage this, but of course it is a longer term goal; or

b) provide more opportunities for women to get experience in speaking (so that they can be better speakers) or other kinds of training to improve their speaking. Maybe more assistance to help them put together great topics by the conference organisers?

I’m not 100% sure what the answer is, but I know that just saying “We tried, and there just aren’t enough great women speakers” probably isn’t enough to increase diversity. It’s just leaving it to chance.

Leave a reply

Regex Resources for Beginners

Learning Regex

Learning regex is an essential skill for a programmer, and sometimes for people who aren’t programmers! Working in web analytics, I have found regex useful for filtering large amounts of data. Having said that, my regex skills were on the amateur side, so I decided to make a concerted effort to improve them.

Regex Resources

I started out with this tutorial.

I used this regex engine to help me work through examples.

This series from Luna Metrics on regex, helped me better understand lots of different expressions, by relating it to something I understand – Google Analytics.

This regex game helped me cement my knowledge (It’s fab, try it!)

Regex Cheat Sheet

( ) is like in maths – it holds a function inside, and signals priority

[ ] Match only one character inside these square brackets

[^ ] Don’t match any of the characters in the square brackets if it starts with a carat!

\ Turns off the special meaning of the next character

| means or

? means the previous character is optional. i.e. matches something 0 or 1 times.

^ means the expression has to start with this (start of a line)

$ means the expression has to end with this (end of a line)

. can be anything

* Match 0 or more times

(so if you write .* it will match anything)

! means do not match

+ Match 1 or more times

{n} Match exactly n times

{n,} Match n or more times

{,n} match n or fewer times

{n,m} match at least n times, but not more than m times.

\d means  [0-9]

\D means [^0-9]

\s means [\t\n\r] which means whitespace

\S means [^\t\n\r] which means non whitespace

\w means  [0-9a-zA-Z] means word char

\W means  [^0-9a-zA-Z] means  non word char i.e. space or punctuation

What is a Backreference

Back reference is a number after a slash, e.g. \1 or \2. This means you need to go back to the first or second (respectively) set of round brackets in the expression, and repeat it.

 

Leave a reply

Starting in Testing Plus Cheat Sheets!

Capybara and testing

This is a Capybara. I didn’t even realise they were a real thing

Now that I have done my beginners course and made a few little apps on my own, I am trying to get into Test Driven Development. This is recommended by proper, professional rails developers, and from my first forays, I see the point.

First,  by writing the tests it really makes you think about what you want your app to do.

Second, and probably more importantly, it gives you an important heads up as to whether anything in your app is broken through showing failing tests.

I am learning through building an app with my Coder Friend, reading blogs online and also I have bought this book on rspec testing.

Michael Hartl’s introduction to Rails tutorial included tests, but I didn’t really do them because they wouldn’t work for me, and I didn’t understand them anyway. Learning Rails is a big step, especially for a non-developer, I’m not sure if you should learn testing at the same time. (I’m not sure – what do you think?)

In February I will go to Rails Girls Next, a follow up to Rails Girls which will include a section on testing (Must make big long list of all questions before then).

Gems I use for Testing

Rspec – Testing tool for Ruby

Capybara – Browser simulator (i.e. pretending to be a user for your app)

Fabricate – Object generation library (i.e. make up pretend instances of your models)

 

I love Cheat Sheets

Rspec Cheat Sheet

Capybara Cheat Sheet

I can’t find a cheat sheet for Fabricate – but I think this will have to do.

Leave a reply

Beginners Notes on Rails Forms

Lately I’ve been working on an app with a slightly more complicated than normal form structure (i.e. more complicated than those for beginners, not for real programmers) – and so I’ve been trying to read up more on forms (particularly the section in Rails Guides). This is a distillation of some of the most important things I think I will need to remember.

1. The basic form opener is form_tag, which has two important arguments

- Path for the action

- Options hash, including method of form submission and options such as form element class.

e.g.  <%= form_tag("/search", method: "get") %>

2.  Basic helpers end in ‘tag’. 

Otherwise they are helpers that work on model objects.

text_field_tag
check_box_tag

These result in <input> elements in the form. The first parameter to these is always the name of the input
<%= text_field_tag(:query) %>

equals

<input id = "query" name = "query">

value = params[:query]
3.  The alternative to the form_tag is the form_for tag

form_for binds a form to a model.  Form_tag is more general – but it can also be used to make changes to a model

Normal form_tag

<%= form_tag(action, method) do %> blah blah

form_for tag

<%= form_for @article, action, do |f| %> blah blah

And then within the forms…

Norrmal form_tag

<%= text_field(:person, :name) %>

form_for tag

<%= f.text_field :name %>

i.e. with form_for you don’t need to keep re-iterating the model name.

Whether you use form_tag or form_for will also determine where things go in the params hash.

form_tag

value = params[:comment]


form_for

value = params[:article][comment]

 

4. The fields_for helper can be used for nested attributes

 

5. Mass assignment

When in your controller you use something like

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

This is letting everything be passed through in the Users params hash to your User.new method – which is not good, because hackers can pass random values through.

Instead, you can use Strong Parameters (which is automatically shipped in Rails 4). In Strong parameters you call permit on the attributes you want to allow through to the controller – you have to actually specify.

@topic.update_attributes(params[:topic].permit(:name)

Becomes

@topic.update_attributes(topic_params)

Where

Def topic_params
Param[:topic].permit(:name)
end

Or

Def topic_params
Params.require(:topic).permit(:name)
end

I’m still working on learning more about forms in Rails, but these are the things I have taken from my readings so far.

 

1 Reply