1. Scottish Ruby Conference !
2014
Michael Griffiths
I recently attended the Scottish Ruby Conference and I have very kindly been invited to give a presentation to briefly cover some of the topics that were discussed there.!
3. Code should be……
Simple Unclever
Favour this…. Over this….
Code should be simple and unclever! !
!This is important for you as a developer and other members of your team who need to be able to read and understand your code.!
4. This is bad…
This code is hard to understand…
But, done wrong, Abstraction can be worse…
As developers we've all been guilty, at some time, of trying to be too clever with our code, in an attempt to make something reusable for every possible case, or condense our code into the lowest possible
factor. What we end up with is code that no-one, not even ourselves, can understand.!
!But often by trying to predict the future we forget about the present, which is to provide a solution for a problem NOW, as simply and quickly as our skills allow us.!
!We all agree that repetition in code is a bad thing, but..., until we see the repetition for ourselves we simply can't determine if there is a real need for abstraction in a particular case.!
!So... Wait for the abstractions to make themselves obvious and avoid predicting all possible outcomes because the wrong abstraction can sometimes be more expensive than no abstraction.
5. Reading Code
Reading Code!
!As developers we have all read code, whether to learn a new language or figure out how our code or someone else’s code works in a bid to reuse, extend or improve it.!
!We should all read code regularly because the more code you read the better your understanding will be which will ultimately make you a better developer.
6. What code should I read?
Any code!
!
Find something out of your comfort zone
Look on git
find old bug fixes… See if you can do it better!
So what should we read, aside from our own code.!
!Well, pretty much any code, especially code that takes you out of your comfort zone. It doesn't matter if it's current or obsolete as long as it challenges you and makes you think about how you code.!
!Read the code and understand how the classes and their methods work.!
Look on git, find old bug fixes to help you understand what was wrong and how it was corrected.!
See if you can do it better.!
And always try to pick out code that addresses a problem which interests you. It's much harder to stick at it if you find the subject boring.!
!Or see if you can find a problem area within rails that interests you or has particular relevance to your work. Try and work out what it's doing, how it's doing it and maybe even find a solution.!
!How to read code.!
Use a method called skim map. Look at the structure first, not the detail. This helps us have a much better understanding of what the code should achieve.!
!It's much easier to remember the layout and structure of code than it is to remember specific lines of code. Think interfaces, not implementation.!
!Remember turns in the code and the shape of the code in the file.!
Learn how each method relates to one another and understand why it is structured that way.!
!To summarise, code reading is very important to us as developers. It's something we do at some point of every day. And just like every other skill, practice makes perfect!
8. I Have No Idea What I’m
Doing!
Tom stuart
web: http://codon.com/
git: https://github.com/tomstuart
twitter: https://twitter.com/tomstuart
The second talk - I have no idea what I’m doing
9. Ever feel like this?
Well, your not alone…
We've all been there at some as software developers. We sit down to start writing some code and it suddenly dawns on us that we have no idea of what to do.!
!Yes, This even happened to David Moyes!!!!!
!
10. The Impostor Syndrome
Sometimes, exposure to new language features or technologies…
Or even… Can sometimes result in feeling like…
This is a perfectly reasonable situation to find yourself in for any number of reasons, be it a language your relatively new to or an area of technology that you've never had to deal with before or something as
simple as a memory block.!
!It's at moments like these we might start doubting our ability, commonly known as the Impostor Syndrome. This has the affect of making us unable to internalise our success or accomplishments.!
!We feel as though any past achievement is down to luck, timing or even deceiving others into thinking we are more intelligent or competent than we really are!
11. Dunning Kruger Effect
Definitely more of a concern than the Impostor syndrome
The flip side of the impostor syndrome is known as the Dunning Kruger effect, where someone truly is unskilled in a particular area of expertise but are either unaware of it or refuse to believe it.!
!The Dunning Kruger Effect is a problem for as long as you refuse to believe you lack a skill. Eventually you have to admit that your not the expert you think you are, come clean and do something about it. !
12. How the Impostor Syndrome and Dunning Kruger Effect Relate
When a group of people from from both these extremes of perceived ability are tested in an area of expertise and asked how they think they did, as expected people from the Impostor syndrome side believe
they did bad where people from the Dunning Kruger end believe they did very well.!
!But when everyone has a chance to review how others in the group have performed, the people at the Impostor syndrome end now realise, and believe, they did well, whereas the Dunning Kruger effect
individual will still believe they did well. This shows that the Dunning Kruger effect is a bigger problem. !
The Impostor Syndrome can be overcome by being aware of others abilities and understanding that your much more capable than you think.!
13. Shoshin
Adopt a beginners attitude to a problem
!
Sometimes being an expert can work against you
Shoshin is a Japanese term that translates to Beginners mind. It suggests that if we close our mind to the expert knowledge we have, and pretend we are a beginner who knows nothing, then we are open to
many more possibilities and can be more flexible in our approach to a problem. We can then use our expertise to guide us in a different approach
14. Experiment
There are different ways to complete a certain task
Make mistakes Admit to mistakes Learn from them
When we come across problems in development we should experiment with different ideas and not always feel we have to do things a certain way. !
!Brand new software or features lacks the knowledge of old established software and so allows more flexibility in material exploration but we can still use TDD methods to reproduce bugs and explore different
options for existing software.!
!Most importantly, understand the problem, this will ultimately allow for better abstraction, code reuse and refactoring in the long run.!
!To summarise, nobody knows what they're doing all the time. Admit to your mistakes, publicly and encourage others to do the same. Remember ignorance fuels creativity, make mistakes and learn from them.
16. Not Invented There:
Things Rails Didn’t Innovate
web: http://calebthompson.io/bio.html
git: https://github.com/calebthompson
twitter: https://twitter.com/thompson_caleb
Caleb Thompson
You may or may not be aware that most if not all of the patterns and techniques used within the rails environment were invented somewhere else, long before rails was invented and here are a few examples.
17. Some Ideas that Rails Stole
MVC ReST
Convention over Configuration ERB
Active Record
MVC is a (compound) design pattern and was developed in 1979 by the creator of Smalltalk.!
MVC was primarily planned for use in n-tier (non web) systems and it splits a system into 3 distinct parts, a Model, View and Controller. While rails didn't come up with the idea of MVC, to separate concerns in
web development, it was one of the first frameworks to adopt MVC which marked the way for many other frameworks to use this pattern.!
Active Record is a design pattern first named in 2003 by Martin Fowler. !
In simple terms Active Record is an object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. In Rails this represents the Model.!
ReST is Representational State Transfer. It relies on a stateless, client-server, cacheable communications protocol - and in virtually all cases, uses the HTTP protocol.!
Rest is used in rails to communicate actions via the HTTP verbs, GET, POST, PUT and DELETE which translate to the seven standard actions INDEX, NEW, CREATE, SHOW, EDIT, UPDATE and DESTROY
via it's routing mechanism.!
Again, while rails didn't invent the ReST architecture it did make it popular.!
Convention over Configuration is a description or template for how to solve a problem that can be used based on the situation when programming using Ruby on Rails and reduces the number of decisions that
developers need to make, allowing simplicity, but not necessarily losing flexibility of the code being processed. !
A simple example is, if there's a class User in the model, the corresponding table in the database is called users by default.!
By adopting convention over configuration Rails allows us as developers to concentrate more on the business logic specific to our task and lets rails worry about the configuration, most of the time.!
ERB is actually a feature of the ruby standard library, that enables you to generate any kind of text, in any quantity, from templates. It allows you to combine plain text with Ruby code for variable substitution and
flow control, which makes them easy to write and maintain.!
Rails makes good use of ERB, most notably in views, allowing us to mix static text with variables.
18. Use others ideas
Don’t re-invent the wheel
Keep things simple
And…
So as you can see Rails has combined good ideas from many sources giving us an environment which allows us to create easy to scale web applications and quick prototyping of applications, which would
otherwise take much more time and be a more painful experience.!
We can take a lot from the concept of rails and adopt it in the way we develop. It should encourage us to use others ideas, keep things simple and be aware that most problems have already been solved and
that we shouldn't re-invent the wheel.
20. Concurrency for !Dummies
(Who Don't Get It (...Yet))
Kerri Miller
web: http://kerrizor.com/
git: https://github.com/kerrizor
twitter: https://twitter.com/kerrizor
We usually think of concurrency as multi-tasking, code doing multiple tasks at the same time.
21. Conflicting Needs
An analogy for concurrency could be cooking a three course meal for many people.!
For each food you are cooking there are conflicting needs – for example multiple temperatures at which you cook each food.!
!There are many things battling for one resource – the oven.!
The need to interact with other food items – all food items for a particular dish need to arrive at the table at the same time – or ingredients need to be combined together to form part of a dish.!
!Concurrency is not the same as parallelism. Concurrency is about dealing with lots of thing at once whereas parallelism is about doing lots of things at once.
22. Threads in different Ruby Versions
When using concurrency in traditional object oriented languages we think of a process with multiple threads running inside that process each containing an individual point of execution within that process.!
!Now since version 1.9 ruby has been able to create native threads but the problem is that ruby uses a Global Interpreter Lock or GIL.!
GIL is a locking mechanism meant to protect your data integrity and only allows data to be modified one thread at a time. This prevents threads from corrupting data but also doesn't allow threads to run in true
concurrency.
23. GIL - Global Interpreter Lock
Now some people will suggest using a ruby implementation that doesn't use a GIL, such as J Ruby, which then leaves you with same pros and cons that you have when multi-threading in Java. !
!However this approach puts more responsibility on the developer and you now have the added burden of making sure your data is safe, doesn't deadlock and that code, gems and plugins are thread-safe.
24. The Actor Model
But there are alternatives.!
For example we can use Actor gems instead of threads. The Actor model operates by passing messages. Individual actors within a process are allowed to send messages asynchronously to one another but
there is no shared memory state as you would have with a thread. Instead information about state is communicated via message.!
!Also there is the Reactor pattern where the heavy work of making blocking Input / Output calls is delegated to an external service, known as the reactor, which is able to receive concurrent requests.!
The reactor is given callback methods that it triggers asynchronously based on the type of response it receives.!
A simple analogy would be Do you want to eat out or eat at home. If you say Eat Out then I will book a table at your favourite restaurant. If you say Eat in then I will go and buy some food from the supermarket
and then start cooking.!
!Concurrency can be a difficult topic to understand and get right. It requires a different way of thinking and needs new patterns and abstractions.!
Concurrency isn't usually an issue that we consider as rails developers but from a ruby perspective there is nothing stopping us from experimenting with the different options out there as we explore deeper into
the ruby language.!
26. Thread Safety First
Emily Stolfo
git: https://github.com/estolfo
twitter: https://twitter.com/EmStolfo
27. I'm going to use a music analogy as a brief explanation of threads in Ruby.!
You can think of the Global Interpreter Lock as the Conductor, a native thread being an instrument and a green thread as a note that the instrument plays.!
!In ruby version 1.8, only one instrument could play only one note.!
28. In ruby version 1.9 the difference is that you can now have many instruments, or threads playing one note, green thread, at a time
29. JRuby allows you to take this a step further by allowing many instruments, or threads to play many notes, or green threads at once and is no longer restricted access by the conductor, or GIL and so threads are
able to share state.!
!So as you can see there a varying degrees of what you can do with threads, depending which version of ruby you are using.!
!Worrying about writing thread safe code shouldn't be an issue in a rails environment, as rails takes care of this for us. But it it is still something we should be aware of as Ruby developers.!
!Some tips for writing thread safe code, starting with the safest options first are:!
Avoid sharing data across threads – this is obviously the best option if possible.!
If you can't avoid shared data, at least avoid shared mutable data, don't allow data from one thread to changed in another thread.!
If you can't avoid shared mutable data, use concurrency primitives.!
The top two concurrency primitives at your disposal are Mutexes and conditional Variables.!
30. Mutex
With a mutex you effectively lock the part of code that you want to be thread safe, blocking any other thread from access until the current thread has finished. Special consideration should be made for Input /
Output processes where Locking should be avoided.
31. Resource consideration
Resources are another consideration. For example if 10 threads are woken up after waiting for something, but only one thread can continue then this is a waste of resources. There are now 9 threads doing
nothing.
32. Conditional Variable with Mutex
A Condition Variable can be used to communicate between two threads. A conditional variable is basically a flag associated with a specific mutex. !
Imagine a thread has a mutex locked but for some reason can't continue because of some condition beyond it's control. !
A conditional variable will allow the thread to sleep until the conditions are met. !
While then thread is sleeping the mutex is released allowing other threads access. !
When the waiting thread is eventually woken, by another thread changing the conditional variable, the waiting thread no reacquires the lock on the mutex and is allowed to continue.!
!
When using concurrency it is important to test under all possible conditions.!
Test with different implementations, test with many threads and use patterns for precision. Examples of these are the rendezvous and barrier pattern.!
To summarise, Thread safety shouldn't be an issue in the rails environment but it it is something you should be aware of, especially if you consider using JRuby which carries all the pros and cons !
present in Java.!
34. Web Applications From
Scratch
Tom Stuart
web: http://codon.com/
git: https://github.com/tomstuart
twitter: https://twitter.com/tomstuart
This was a workshop so I will briefly touch on what it covered.!
The workshop started with how you would implement a basic web application using ruby classes!
We already know how to build a web application in Rails. We understand the general structure of web applications and the main pieces involved: the server, the router, the controller, the model, the view.!
!
But have you ever wondered how these pieces work, and how they fit together to create a working web application? Do you understand what all the code in Rails actually does, and how? Are there any options
when the framework doesn’t quite work the way you want it to?!
This workshop removed the magic to show exactly how every part of a web application does its job.!
It used bare-bones Ruby, with code from the standard library and then showed us how to use the Rails web frameworks to offload some of the grunt work and help in understanding how the various parts of the
framework do a particular job.!
Another benefit of attending this workshop was the offer of a complimentary copy of the ebook being written by Tom, when it is completed.!
It will be a full tutorial and will walk through the whole process involved in this workshop.!
I think this will be a very interesting and helpful task to complete both as a team and individually to further improve our understanding of rails.
36. Sketch Noting:!
Creative Notes for Technical Content
git: https://github.com/jessabean
twitter: https://twitter.com/jessabean
Jess Aldridge
Sketch noting is a visual note taking method that allows focus and improves memory and is fun.!
All you need to get started is a pen and paper.
37. You Can Draw Basic Shapes
But what if you can't draw! !
As long as you can draw basic shapes such as square, triangle, circle, arrows you can sketch note. !
It's not about being an artist it's about improving your interpretation of a subject using images as well as text.
38. So How do you Sketch-note!
Pay attention to the speaker. Follow what the speaker says, not the slides. It's about listening.!
Listen for key points. Avoid live coding.!
You can use post it's to retain ideas that you can later go back to in more detail.!
!Capture what stands out to you. Capture the context, language style in your own visual language and use question bubbles and quoters for emphasis.!
!Sketch-noting is a great way to interpret the subject in a way that you understand. !
Don't be afraid to share your notes with your team and look at others sketches. This will help improve you note taking skills.!
!Some practical tips for sketch-noting are:!
Get in a comfortable position with as good a light source as possible and avoid distractions.!
Slow down, your handwriting becomes more erratic if you you try to write down everything too fast.!
Use large letter, make things clear.!
!Play around with different layouts – some layouts are more suited to certain subjects than other. Experiment and see what works best. !
!Add the decoration, shapes last. It's important that you actually have the textual content to start with. The decoration highlights various areas of importance.!
!As with anything practice makes perfect. Start by sketch-noting from videos where you can pause and work at your own speed to build up confidence in sketch noting.!
!It's fine to copy someone else’s style of sketch-noting or experiment and find your own style.
40. UXing Without A UXer
git: https://github.com/chrissywelsh
twitter: https://twitter.com/chrissywelsh
Chrissy Welsh
Ux, user experience is about creating easy to use interfaces and giving the end user a great experience.
41. UX is about giving the user a great experience
The path from the original product vision to the actual end product is not a straight line from A to B.!
!The various stages of the product will deviate along the way as you attempt to address a Great user experience, Happy users and Easy interfaces.
42. Do you have a Vision?
Lets start with the vision. Do you have a vision. What one thing do you want the product to do well.!
When you have the vision share the vision.
43. Know your User
Do you know the end user. Who are they? !
Really think about and write down who will use your product.!
Write down their age, education, job description. Give the user a name. Giving this imaginary user a name makes it feel real.!
It's also very important to have the correct persona for your imaginary end user as this will have an impact on how you design and develop your product.!
!For each user you create make a table or list with the following information;!
User details, name, age and job title.!
Key Goals of the user.!
User behaviours!
What we must do to satisfy this users requirements.!
What me must never do
44. Wireframes
Fast prototype - Disposable
!Wireframes allow us to create a layout quickly. You can easily see if you have everything you need.!
Wireframes allow fast iteration of prototypes, and it is much cheaper than changing code.!
!So why wireframe – Because having one idea is great. Iterating on an idea is better but being able to try multiple ideas gives you the best solution.
45. All you need to start wire framing
The basic tools you need to wireframe are pen and paper although there is software out there if you prefer.!
Wireframes don't have to be artistic, it is more important to clearly show the features.!
!Don't get attached to your wireframes, know when to scrap your work and start again.!
!Don't forget to evaluate your product. Look at things from a users perspective. If you can't evaluate a product fairly yourself, get someone else to evaluate for you.
46. The End Product
You have to decide to…
Keep It Or Bin It
Lastly, when the end product isn't exactly what you expected you have you make a decision to keep it as it is or bin it and start again.
47. The Dark Side Of Ruby
web: http://www.joshsoftware.com
git: https://github.com/gautamrege
twitter: https://twitter.com/gautamrege
Gautam Rege
This talk was not as sinister as the title suggests, but it certainly was a good introduction to the language underlying the rails framework that we use.!
!Using rails we are often protected from a lot of the inner workings of the ruby language. This can be a good and a bad thing.!
!It is good in that we have less things to worry about and can trust rails to do it's magic and everything, usually, just works. !
!But there will be times when rails doesn't do things quite the way we expect, we might need!
finer control over the way rails carries out a task or we might need to write a gem or library in ruby.!
!This is when we have to dig deeper into the language on which the rails framework is based and start understanding the magic that we take for granted.!
!This talk briefly covered some of the weirdness and gotcha's within the ruby language that are usually well hidden from us as rails developers.!
!This talk didn't make me a ruby master but it did make me want to gain a better understanding of the language I'm using everyday.!
!Rails is quite unique as a framework in that it lets you develop a working web application with only the most basic understanding of it's underlying language. !
But it would be disappointing to think that you could be missing out on what Ruby has to offer as an exciting and powerful language.!
!This talk has certainly inspired me to dig deeper and one day master ruby.!
49. Scottish Ruby Conference !
2014
!Summary!
This was actually the first conference I have ever attended so I wasn't sure what to expect.!
I quickly realised that the ruby community is very inclusive, not exclusive as I first imagined.!
It was interesting to learn about other peoples backgrounds in software development and to tell people about mine.!
!It was amazing to see that most people had crossed over from various other languages, PHP, Java and even .NET.!
!I think this speaks volumes for the growing popularity of the ruby language and rails framework and looks like it will continue to be one of the dominant languages in web development for some time.!
!This conference wasn't just about the ruby language, but also the various disciplines that are required to be a good developer, for your team and your customers.!
!I thoroughly enjoyed my experience and would highly recommend others to do the same.
