How do you teach proper software engineering? How do you design a teaching program that highlights the pain of maintaining software to students who have never actually had to maintain software? And, while doing that, how do you keep your students engaged?
Teaching at an experimental group at the Technical University of Moldova, I’m able to employ new techniques including testing, live coding and software maintenance into a regular university curriculum.
Crystal is a typed, LLVM compiled language that reads (mostly) as Ruby.
If you’ve ever faced a problem in which you would like to use Ruby (because it is awesome), but it is just not performant enough, maybe Crystal is the solution you’ve been looking for.
Crystal’s standard lib comes bundled with support for WebSockets, OAuth, MySQL, and other nice utilities. It has a very simple testing framework, dependency management system, and even the beginnings of a web framework.
This is a very exciting time to come aboard the Crystal train, especially coming from a Ruby background.
As a developer, diving in a new code base is not uncommon: you’ve just been hired, you change of project, you want to help an open source project, the open source library your project depends on is buggy, etc. It’s like entering in a underwater cave, you don’t know the treasures or the monsters you’ll find there, neither if the path is treacherous or if it’s a true labyrinth where you’ll get lost. You can prepare yourself, you can plan your visit, you can equip yourself, you can survive and find the gem you’re looking for…
Up until the 17th century, the world was mostly limited to what we could see with the naked eye. Our understanding of things much smaller and much larger than us was limited. In the past 400 years our worldview has increased enormously, which has led to the advent of technology, space exploration, computers and the internet. However, our brains are ill equipped to handle dealing with numbers at these scales, and attempt to trick us at every turn. Software engineers deal with computers every day, and thus we are subject to both incredibly tiny and massively large numbers all the time. Learn about how your brain is fooling you when you are dealing with issues of latency, scalability, and algorithm optimization, so that you can become a better programmer.
How often have you heard – or said – the phrase “$PERSON just isn’t technical”?
If you’re our speaker, you’ve heard it plenty of times over the past 15 years, and frequently applied to yourself and other colleagues who didn’t quite fit into well understood “technologist” categories.
But what does technical actually mean? What makes someone technical? What makes them not technical?
In this talk, the speaker will explore how “not technical” is dangerous phrase we use to ensure that we need never question our hidden biases about others and their aptitudes. She will demonstrate how this phrase not only encourages a lack of collaboration, but leads to stagnation in the growth of your orgnization by actively discouraging your peers from learning new skills.
She will conclude with concrete steps attendees can take to better understand the capabilities of everyone on their team – coders or not – so their projects, company or teams can be most successful.
Every other company is looking for ninjas, cowboys or superheroes. Every other conference talk is full of jokes, puns, comedy skits and personality. Nowadays, conferences breathe showmanship, but in our need to be the best of the best, the funniest of the funniest, we are excluding others. When less than exceptional becomes not good enough, the barrier of entry goes up and it is the underrepresented groups that suffer. When did we start mistaking programming conferences for stand up comedy shows? Our drive to be edgy, exceptional, memorable or controversial too often ends up with distressed audiences and badly handled PR scandals. This talk’s aim is to reflect on how this is a problem, how we’re all losing and how the cult of the stage hero needs to stop.
Ruby is a great language for building CLIs. There’s an amazing selection of existing libraries like Thor, GLI, or even OptionParser. You probably use a number of Ruby tools everyday like chef, the heroku toolbelt, , and of course the rails command line tool.
Though it’s easy to build a Ruby CLI, distributing it to end users is much more complicated because it requires a Ruby runtime. One option is to rely on Ruby being already installed on the end user’s computer. The other is to bundle ruby as part of the distribution package. Both of these are problematic so much that Vagrant, CloudFoundry and hub (Github command-line tool) have all switched over to Go.
But there’s still hope! In 2012, Matz started working on a lightweight embeddable ruby called mruby. Since mruby is designed for being embedded in other compiled languages, it also solves the distribution problem. In this talk we’ll look how we can write CLI tools using mruby to produce a self-contained binary that can be shipped to end users.
The Junior Jump deals with a topic that is increasingly important to the Ruby community--onboarding new engineers into their first jobs. We’ll discuss how the interview stage can be used to design a roadmap for a new engineer’s early days, how to select meaningful and appropriate projects and how to come up with a mentorship model that works given the resources at your organization. We will here anecdotes from junior developers from diverse backgrounds (bootcamp and university grads as well as self taught programmers) and more senior developers with experience onboarding new engineers.
Working as a developer while raising a child isn’t as difficult as you may think. A big share of adults are parents, and many can still become one some day. Becoming a parent changes a lot of things in your life. What it doesn’t change is your ability to work. It surely changes your priorities, and you don’t get much sleep during the first years, but this doesn’t have to prevent anybody from doing awesome work. If we have this in mind, it’s strange to observe what an exotic status parents and children have in our industry. The share of family-friendly employees and workspaces is tremendously low. Also, work organised in a way that doesn’t require everybody to work 40 hours a week is particularly rare, as my current difficulties finding a new job with less hours have shown. Parents in our industry have just become visible in recent years. Therefore, parents are often disregarded when a startup is founded. Creating a family-friendly workspace isn’t difficult, it’s just uncommon. This talk will introduce what it means to be a parent working as a developer and how work can be organised in a family-friendly way. It will show which benefits there are for everybody working in a family-friendly workspace, leaving you with a practical list of ideas how you could improve your work-live.
Since the inception of the programmable computer we have grappled with the challenge of validating the outcome of a conversation in code between a human and a machine. Programming as a performance embraces this challenge, putting it at the centre of a performance. Focusing on the liveliness and complexity of dancing with a machine in realtime. In a performance a human edits and writes algorithms, expressing their thoughts and composition in front of an audience. Binding to their fingertips control of light, sound and poetry. Sharing their screens and code and its effects on the world.
This talk will dive into the world of the live programmer and how you can turn your Ruby coding skills into a live performance. Discover what performance and expression has to teach us about programming.
Have you ever been told you’re “too direct,” or feel like you don’t understand what others want? Or on the other side, do you think others are often too confrontational? These are Ask vs Guess Culture differences. Ask folks believe it’s ok to ask anything, because it’s ok to say no, while Guess folks prioritize not imposing on others. It’s a culture clash that isn’t often recognized, yet causes quite a bit of tension and frustration. This talk will cover the nuances of these different communication styles, as well as strategies for bridging the gap. Gaining an understanding of these differences and learning specific tactics for a professional context will make you a drastically more effective communicator.
Life is good. More and more people who never thought they could code, people of diverse backgrounds are learning to write Ruby and become full time developers. Outreach programs are doing an amazing job of getting these people into the community, but now we are facing an even bigger problem. Getting them to stay there. 57% of women alone leave the tech industry once they are there. At every turn, we are told we can’t do it, offered different untechnical positions, or bullied out by toxic cultures. This talk will explore the barriers people of different backgrounds face to stay in technical positions, even once they have overcome the barriers to get there. It will present different perspectives and bring light to things we can do as an individual, an employer, a co-worker and as a community to solve this large problem that we face.
Every time we solve an everyday programming problem we learn from its solution. When we come across a similar problem later on, we think “aha! I’ve seen this before! I know how to solve it!”. Many of us are also familiar with design patterns, which are abstractions that solve entire classes of problems. There also exists, however, a different kind of pattern. But, as opposed to help you structure a whole compiler or business application, these patterns love hiding in small things like methods or functions, or even binary operations. They whisper to you when you concatenate two strings. They leave a trail of breadcrumbs every time you map over a list. These abstractions have superpowers, too. They can separate the what from the when, or even from the how. They can add together things other than numbers. They can control time, or take over the control flow of your program entirely. In this talk you will discover the amazing power of small abstractions. After that you’ll start hearing their whispers and seeing their breadcrumb trails. And only then you will be ready to let them unfold their full potential in your programs.
"Did you really think you could make changes to the database by editing the schema file? Who are you, Amelia Bedelia?"
The silly mistakes we all made when first learning Rails may be funny to us now, but we should remember how we felt at the time. New developers don't always realize senior developers were once beginners too and may assume they are the first and last developer to mix up when to use the rails and rake commands.
This talk, presented in a storybook style, will be a lighthearted examination of some of the common mistakes (and causes of those mistakes) made by beginner Rails developers.
Kids have this magical ability to take something you think you understand well and turn it upside down within an instant. They challenge norms and ask questions that you never thought existed or could be asked.
In this talk, I’ll go over some of the challenges I faced introducing kids to the world of programming, and how their inquisitiveness changed the way I look at software development, how I learn to get better at it and finally, how it boosted my confidence in my code. Teaching anyone is a rewarding, learning experience, and it motivated me to become active in the community.
There are some myths around Science – it’s boring, useless, difficult. Many of them are heard while we are young, and many people tend to take then for the entire life. Science is very important, specially on Computer Science and Engineering, for building the basis of our logical thinking.
This talk gives a quick introduction into the not so well known Fiddle, which is a part of MRI since 1.9. It allows directly interacting with C code via a Foreign Function Interface, which allows wrapping native code without compiling C extensions, making the live of users of your projects much easier.
Dajana will be joined by Leslie Hawthorn to give this talk!
When considering how to design products, teams or even common every day household objects, empathy doesn't end up on the required features list. Yet, without empathy, teams with enormous technical skills can fail in their quest to deliver quality products to their users. Incredible projects fail to create communities because they don't exercise it. Fail at empathy and your chances of failing at everything skyrocket.
Contrary to what you may have heard, empathy is not something you're innately born with - it's a skill that can be learned, cultivated, refined and taught to others. In this presentation, your lovely co-speakers will discuss the value of empathy, how you can cultivate in yourself and your organizational culture, and conclude with concrete steps for leveling up in your interactions with your fellow human beings.