Video recording and production done by Ancient City Ruby
Whether you're a student or a CTO, it's worth taking a moment to consider the transition from student to professional. The Junior Jump will explore strategies that will help you become or mentor a confident junior developer. We'll discuss how candidates and employers can use the interview stage to set a foundation for a productive transition, how to figure out what kind of mentorship/pairing model will work best with the resources available at your company and examples of projects that are challenging and appropriate for developers transitioning into their first jobs.
I'll draw on my own experience working on the DMCA claim system at Kickstarter, as well as interviews with experienced software leads and developers currently in their first jobs. We will hear anecdotes from developers from university, bootcamp and self-taught backgrounds and as well as engineers experienced in mentoring junior devs at very diverse companies.
There are a lot of reasons I love Ruby. It makes me a happy programmer. Apple recently released its latest programming language into the wild, Swift. Swift is an object oriented-programming language with a functional personality.
I will give you the whirlwind tour of what I have learned in my dabbling with the language. We will compare constructs in Swift to similar implementations in Ruby and contrast the differences. We’re talking language and syntax here, the good stuff. No need to bring your iOS or Cocoa chops :wink:. Perhaps we have established a trajectory to find happiness developing native applications as well?
Docker’s lightweight virtualization may supplant our hypervisor-backed VMs at some point in the future, and change the way that tomorrow's Ruby applications are architected, packaged and deployed. Using Docker, your Ruby applications will sit atop an excellent platform for packing, shipping and running low-overhead, isolated execution environments. You will get a brief intro to the Docker ecosystem, get to know the tools and processes needed to create containerized Ruby applications, and learn best practices for interacting with the Docker API from Ruby.
Have you ever worked on a soul-destroying Rails application? I have! Inconsistent and non-idiomatic code, spaghetti concerns, and terrible, excruciatingly slow tests are just a few of the symptoms you might encounter – with complete developer indifference being the sad consequence.
As a traveling consultant and software journeyman, I’ve picked up a bunch of hacks along the way to help make the unbearable bearable. Don’t give up hope – this is a job for the rescue squad: RAILS EDITION!
For the past 6 years, I’ve run the Ruby Survey (almost) every year. It asks the same questions every year, plus some new ones. It’s goal is to track changes in technology, community, fashions, attitudes, and tooling. This is the first time I’ll ever be fully sharing the data and it should make for an interesting exploration of the past, present, and maybe future of the Ruby ecosystem. Oh, and I’ll probably cuss a lot too.
We all want to work for a company that cares about and promotes a balanced, fun, and, in a word, "awesome" culture, but unless a company has safeguards in place against bad clients, bad projects, and bad apples, this great company culture only exists on paper. What can we do as developers, team leaders, or mentors to protect ourselves and others from cultural failure? What are successful companies doing to maintain their workers' happiness? By examining what a developer needs for professional happiness, this talk will propose a functional, actionable company culture model while exploring the sometimes difficult task of owning your company culture and protecting it when things go wrong.
** We apologize for technical difficulties - This video starts a bit into Noel's talk. **
What makes some projects succeed and others fail? Often the problem is that the stakeholders in your project have stopped trusting one another. The root of this problem is not always technical, but can be that your team has structured its workflow in a way that is making your life more difficult and making it hard for stakeholders to understand and accept your progress.
As developers, we tend to dismiss project process as a "soft skill", right up until the moment you hit a deadline and realize you needed a better structure in place six weeks ago. Estimation is a particularly fraught process, and tension between developers and stakeholders will often manifest there first.
You may think that ugly project management is a fact of life and there's nothing you can do about it, but that's just not true. Agile processes are filled with small ways you can increase trust and improve the way your team works.
ORMs such as ActiveRecord or DataMapper are fabulous tools that have improved the speed at which we're able to develop working, shippable products. As DSLs for working with our persistence layers, they've proven their worth time and time again, but at the cost of stunting our collective knowledge about the built-in, powerful features that different databases have to offer. Let's take a look at some of those features, rediscover what we've left behind by accepting abstraction, and recover some tools that can help ensure the long-term health of our applications.
At some point every Rails developer needs to build an API, but what's the best way to do it and avoid the mess many run into when serving multiple client applications?
In this session, we'll go over how to use Rails to leverage the HTTP protocol and build rock-solid web APIs. This includes fine-tuning route endpoints, content negotiation, versioning and authentication. We will also review common practices for keeping your code organized, clean and testable.
As Rails enters its tweens, “legacy Rails” projects are increasingly common. Even if you haven’t dealt with such projects, every line of code we leave in production is destined to become legacy code. As developers, our everyday decisions make it easier or harder to work in a codebase over time. I’ll share some of the decisions, both wise and unwise, that I’ve made or encountered in five years of working with aged Rails codebases. With just a bit of forethought, your Rails projects won’t be “aged” or “legacy” - they’ll be timeless.
Did you know that SketchUp has a Ruby API? Did you know that you can use SketchUp to do all kinds of things, including designing 3D printing templates? In her past career in the solar energy field, Meeka Gayhart used SketchUp for doing renderings and shading calculations for solar arrays. Come learn about how easy SketchUp is to use, and how to create your own drawing and design tools.
What happens to Ruby when Rails dies?
Ruby rode the Rails rocketship to worldwide renown. While a handful of developers were writing Ruby code before Rails came along, many (if not most) of us owe Rails a debt of gratitude for taking Ruby mainstream, thus allowing us to make a living writing code in a language we love.
However, the application design preferences expressed by Rails are falling out of favor. Our apps have more complex domain logic that becomes burdensome to manage by following "The Rails Way."
Is that it, then? Does transitioning from Rails mean leaving Ruby behind?
If we're being honest, I think it's fair to say that all of us have thought about this at one point in the past year or two, or maybe before. Whether while we're cursing the mess we got ourselves into with ActiveRecord callback spaghetti or complicated modeling brought on by the predisposition to make everything in app/models a subclass of ActveRecord::Base, we think "this just isn't fun anymore. What happened to the programmer happiness I felt when things were simpler?"
But I strongly believe that even in a world where it's said that every programming language needs a "concurrency story" and functional programming is on the rise, there's room for Ruby. It's certainly not a language I want to stop writing any time soon, even if only as part of a larger whole.
There's no easy answer to the question posed at the start of the talk description, so don't watch this talk expecting to hear one. Instead, expect to be prompted to think critically about the way you view yourself as a programmer, and what that means for your life and career.