Static Typing

Static type checking can improve the developer experience by preventing type errors and improving editor assistance. Static type checking is most commonly implemented with type declarations in code, and the third-party Sorbet library implements type declarations for Ruby. However, Yukihiro Matsumoto (the creator of Ruby, aka “Matz”) has emphasized in several RubyConf keynotes that Ruby will not add type declarations officially. Instead, the Ruby approach to static type checks is via Ruby Signature (RBS) files: separate files that record type information, analogous to TypeScript .d.ts files. RBS files can be written by hand or automatically generated by tooling.

RBS was introduced in Ruby 3.0, but up until now, its benefits have been largely theoretical. But those benefits are now starting to manifest with TypeProf-IDE, a VS Code extension created by Ruby core member Yusuke Endoh. This extension runs TypeProf on Ruby code as you edit it, inferring types, generating RBS type signature files, providing inline documentation and autocomplete, and calling out type errors. You can try out TypeProf-IDE today by following along with my TypeProf-IDE tutorial blog post.

Performance

Execution speed, I/O throughput, and parallel processing can all be grouped under the heading of performance, and work is happening in Ruby in all these areas.

Ruby execution speed is being worked on from multiple angles. First, performance enhancements are being made within YARV, the main CRuby interpreter. One significant example is Eileen Uchitelle from GitHub presenting “How we sped up CVARs in Ruby 3.1+”. Although CVARs, or class variables, aren’t used very widely in Ruby application code, they are heavily used within Rails itself, so any applications built on Rails will benefit.

Besides the interpreter, there are several ongoing efforts to compile Ruby to native code. MJIT is a just-in-time compiler that was included in Ruby 2.6. At this year’s RubyConf Shopify presented another JIT compiler, YJIT, which is included in the first Ruby 3.1 preview release. Stripe presented the Sorbet Compiler, an AOT (ahead-of-time) compiler that is in development, which leans on the static type information in code that uses Sorbet type declarations.

I/O throughput has been significantly improved via async fibers. Fibers are a lightweight concurrency mechanism that has been in Ruby since 1.9. The async gem, created by Samuel Williams, uses fibers to allow a Ruby program to switch to other fibers when blocked on supported I/O operations, without requiring any special language syntax. Bruno Sutic posted a helpful overview of the async gem, and presented more detail in his RubyConf session on Async Ruby. Async can be used back to Ruby 2.5 if you use async-specific I/O gems. But in Ruby 3.0 and above, all blocking operations are compatible with async, whether in the Ruby standard library or other gems. Fibers do not provide parallel execution: even with multiple cores, only one fiber can be actively executing at a time. But one Ruby process on one core can run millions of fibers concurrently, as Samuel Williams has demonstrated via a Ruby server handling one million WebSocket connections.

While async fibers do not run in parallel on multiple cores, Ractors were added in Ruby 3.0 as an experimental multicore concurrency mechanism. Each Ractor has an isolated object space and allows only limited sharing of data to other Ractors, which avoids threading issues like race conditions and deadlocks. As a result, Ractors are not bound by the Global Interpreter Lock, allowing true parallel processing on separate cores. Currently, each Ractor has its own native thread, but future work will allow Ractors to share threads to reduce the memory consumption of Ractors and make them easier to work with. At RubyConf Vinicius Stock demonstrated using Ractors to run tests on multiple CPUs.

Matz had set a “Ruby3x3″ goal to speed up Ruby 3 over Ruby 2.0 three times for some significant benchmarks, and Ruby 3.0 met that goal. This push for performance will continue: in this year’s keynote, Matz set a new performance goal, “Ruby3x3 Redux”: a future Ruby 3.x release will be three times faster than Ruby 3.0 in some benchmarks.

How to Think About Ruby

These new features seek to reduce the distance between Ruby and other languages: to gain some of the type safety of statically-typed languages, the I/O throughput of async languages like Node, and the parallelism of channel-based languages like Go. But there are several factors that limit how far Ruby can go in these directions. The first is compatibility: the core team doesn’t want to break existing Ruby programs if at all possible. The second limiting factor is language design: Matz called Ruby a human-oriented language, and although type safety and performance are being prioritized, they won’t be pursued in a way that compromises what the core team sees as Ruby’s human-oriented design.

The point of these language improvements is not that they erase the advantages other languages have. When the most important factor in your system is I/O throughput, multicore processing, or type safety, you wouldn’t want to choose Ruby from the start: you would want to go with a language like Node, Go, or Haskell respectively.

The way to think about these improvements to Ruby is that they incrementally increase the set of problems for which Ruby is a good solution.

For organizations already using Ruby, these improvements mean that they will be able to do more in Ruby before needing to write a native extension in C or Rust, before needing to extract a microservice in another language, or before considering a rewrite.

For organizations considering what technology to use for a new project, these improvements to Ruby mean that they don’t need to so quickly give up Ruby’s productivity benefits for the sake of other needs. There are still many systems for which the controlling factor is the ability to deliver functionality quickly and with minimal development cost, including startups needing to find a product or market fit and internal teams with a limited budget. Systems like these benefit tremendously from Ruby’s high level of abstraction, its rich and mature library ecosystem, and Rails’ support for delivering web services and applications with minimal effort. Each improvement to Ruby removes one more “what if” that could make decision-makers hesitate:

• “What if the development team gets big enough that we need type safety? Oh, then we can use RBS or Sorbet.”
• “What if we need to handle lots of WebSocket traffic? Oh, then we can use async fibers.”
• “What if we need to maximize CPU core usage for a lot of computation?” Okay, that one would still be a stretch for Ruby, but at least Ractors mean you won’t be locked into one core.

These enhancements to Ruby are expanding the set of systems for which the language can offer that velocity benefit. Companies can get a leg up on their competition by recognizing when they have a system for which development velocity is the controlling factor and taking advantage of Ruby’s strengths. RubyConf 2021 demonstrated that Ruby continues to evolve as the core team, individual contributors, and large companies make substantial investments in it.

The post Where is Ruby Headed in 2021? appeared first on Big Nerd Ranch.

Setup

First, install Ruby 3.1.0 preview 1. If you’re using rbenv on macOS, you can install the preview by executing the following commands in order:

• brew update
• brew upgrade ruby-build
• rbenv install 3.1.0-preview1

Next, create a project folder:

• mkdir typeprof_sandbox
• cd typeprof_sandbox

If you’re using rbenv, you can configure the preview to be the version of Ruby used in that directory:

• rbenv local 3.1.0-preview1

Next, initialize the Gemfile:

• bundle init

Next, let’s set up Visual Studio Code. Install the latest version, then add the TypeProf VS Code extension and the RBS Syntax Highlighting extension.

Open your typeprof_sandbox folder in VS Code. Next, open the Gemfile and add the typeprof gem:

 git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }

 #gem "rails"
+gem 'typeprof', '0.20.3'

Now install it:

• bundle install

Getting Type Feedback

To see TypeProf in action, let’s create a class for keeping track of members of a meetup group. Create a file meetup.rb and add the following:

class Meetup
  def initialize
    @members = []
  end

  def add_member(member)
    @members.push(member)
  end

  def first_member
    @members.first
  end
end

It’s possible you will already see TypeProf add type signatures to the file, but more likely you won’t see anything yet. If not, to find out what’s going on, click the “View” menu, then choose “Output”. From the dropdown at the right, choose “Ruby TypeProf”. You’ll see the output of the TypeProf extension, which will likely include a Ruby-related error. What I see is:

[vscode] Try to start TypeProf for IDE
[vscode] stderr: --- ERROR REPORT TEMPLATE -------------------------------------------------------
[vscode] stderr:
[vscode] stderr: ```
[vscode] stderr: Gem::GemNotFoundException: can't find gem bundler (= 2.2.31) with executable bundle
[vscode] stderr:   /Library/Ruby/Site/2.6.0/rubygems.rb:278:in `find_spec_for_exe'

In my case, the command is running in my macOS system Ruby (/Library/Ruby/Site/2.6.0) instead of my rbenv-specified version. I haven’t been able to figure out how to get it to use the rbenv version. As a workaround, I switched to the system Ruby and updated Bundler:

• rbenv local system
• sudo gem update bundler
• rbenv local 3.1.0-preview1

For more help getting the extension running, check the TypeProf-IDE Troubleshooting docs. Of note is the different places that the extension tries to invoke typeprof from. Ensure that your default shell is loading Ruby 3.1.0-preview1 and that a typeprof binary is available wherever the extension is looking.

After addressing whatever error you see in the output, quit and reopen VS Code to get the extension to reload. When it succeeds, you should see output like the following:

[vscode] Try to start TypeProf for IDE
[vscode] typeprof version: typeprof 0.20.2
[vscode] Starting Ruby TypeProf (typeprof 0.20.2)...
[vscode] Ruby TypeProf is running
[Info  - 9:03:49 AM] TypeProf for IDE is started successfully

You should also see some type information added above the methods of the class:

Well, that’s not a lot of information. We see that #add_member takes in an argument named member, but its type is listed as untyped (which means, the type information is unknown). It returns an Array[untyped], meaning an array containing elements whose type is unknown. Then #first_member says it returns nil, which is incorrect.

Improving the Types and Code

For our first change, let’s look at the return value of #add_member. It’s returning an Array, but I didn’t intend to return a value; this is just a result of Ruby automatically returning the value of the last expression in a method. Let’s update our code to remove this unintentional behavior. Add a nil as the last expression of the method:

 def add_member(member)
   @members.push(member)
+  nil
 end

Now the return type is updated to be NilClass, which is better:

Next, how can we fix the untyped? Endoh recommends a pattern of adding some example code to the file showing the use of the class. Add the following at the bottom of meetup.rb:

if $PROGRAM_NAME == __FILE__
  meetup = Meetup.new
end

Next, type meetup.ad below the line where meetup is assigned. (We’ll explain the $PROGRAM_NAME line in a bit.) An autocomplete dropdown will appear, with add_member selected:

Because TypeProf can see that meetup is an instance of class Meetup, it can provide autocomplete suggestions for methods.

Click add_member in the list, then type an opening parenthesis (. VS Code will add the closing parenthesis ) after the cursor, and another popup will appear with information about the method’s arguments:

It indicates that the method takes one argument, member, and returns nil. Also note that the type of member is still listed as untyped; we’re still working toward fixing that.

Pass a string containing your name as the argument, then add the rest of the code below:

if $PROGRAM_NAME == __FILE__
  meetup = Meetup.new
  meetup.add_member('Josh')
  first_member = meetup.first_member
  puts first_member
end

What’s the significance of the if $PROGRAM_NAME == __FILE__ conditional? $PROGRAM_NAME is the name of the currently running program, and __FILE__ is the name of the current source file. If they are equal, that means that this Ruby file is being executed directly, which includes when TypeProf runs the file. So this is a way to provide supplemental information to TypeProf.

When you added this code, the type information should have updated to:

Why does this added code affect the type of information? TypeProf executes the code to see the types that are actually used by the program. By supplying an example of using the class, TypeProf has more type information to work with. Future TypeProf development may allow it to be more intelligent about inferring type information from RSpec tests and usages elsewhere in the project.

Note that TypeProf now indicates that the member argument is a String, and that #first_member may return either a NilClass or a String. (The reason it might return a NilClass is if the array is empty.)

Making the Code Generic with Type Variables

Let’s put our object-oriented design hats on and think about these types. Is it specific to Strings? No, the code doesn’t make any assumptions about what the members are. But TypeProf has coupled our class to one specific other class to use!

To prevent this, we can manually edit the RBS type signatures generated for our class to indicate just how generic we want Meetup to be.

Create an empty typeprof.rbs file in your project folder. Next, command-click on the type signature above #add_member. The typeprof.rbs file will open, and the RBS type signature for that method will be automatically added to it:

Next, go back to meetup.rb and right-click the type signature above #first_member. This adds the signature for that method to the RBS file too, but as a separate class declaration:

To keep things simpler, edit the RBS file so there’s a single class with two methods in the same order as in the Ruby file, and save the file:

Now, let’s edit the signature to use type variables. A type variable is a place where, instead of referencing a specific type, you use a variable that can represent any type. Everywhere the same type variable appears, the type must be the same.

First, add a [MemberT] after the Meetup class name:

Next, replace the two occurrences of String with MemberT:

What this means is, a given Meetup instance applies to a certain type, called MemberT. That’s the type of the member you pass in to #add_member. That is the same type as what the return value of #first_member should be. So if you pass in a String you should get a String back. If you pass in a Hash, you should get a Hash.

Switch back to meetup.rb. If you don’t see the type signatures updated, you may need to close and reopen meetup.rb. Then, you should see updated type signatures:

Note that our MemberT types appear in the signatures of #add_member and #first_member. Also note that the signatures have a # in front of them: this indicates that they’re manually specified in the RBS file.

Now, let’s see what help this gives us. In the statement puts first_member, start typing .up after it. Note that an autocomplete dropdown appears and #upcase is selected:

TypeProf knows that member is a Meetup object. Because you passed a String into the #add_member method of the meetup object, TypeProf can tell that meetup’s type variable MemberT is equal to the type String. As a result, it can see that its #first_member method will also return a String. So it knows first_member is a string, and therefore it can suggest String’s methods for the autocomplete.

Click upcase to autocomplete it. Now note that first_member.upcase has a red squiggly underlining it. Hover over it to see the error:

It says [error] undefined method: nil#upcase. But wait, isn’t first_member a String? The answer is maybe. But it could also be a nil if the meetup hasn’t had any members added to it. And if it is nil, this call to #upcase will throw a NoMethodError. Now, in this trivial program we know there will be a member present. But for a larger program, TypeProf will have alerted us to an unhandled edge case!

To fix this, we need to change the way the type signature is written slightly. In the RBS file, replace (NilClass | MemberT) with MemberT? (don’t miss the question mark):

? indicates an optional type, a case where a value could be a certain type or it could be nil.

Now, in the Ruby file, wrap the puts call in a conditional:

 first_member = meetup.first_member
-puts first_member.upcase
+if first_member
+  puts first_member.upcase
+else
+  puts 'first_member is nil'
+end

If the red squiggly under the call to #upcase doesn’t disappear, close and reopen meetup.rb to get TypeProf to rerun. After that, if you made the changes correctly, the underline should disappear:

TypeProf has guided us to write more robust code! Note that currently TypeProf requires the check to be written as if variable; other idioms like unless variable.nil? and if variable.present? will not yet work.

Next Steps

If you’d like to learn more about TypeProf-IDE, Endoh’s RubyConf 2021 talk should be uploaded to YouTube within a few months. In the meantime, check out the TypeProf-IDE documentation and the RBS syntax docs. And you can help with the continued development of TypeProf-IDE by opening a GitHub Issue on the typeprof repo.

Thank you to Yusuke Endoh for his hard work building the TypeProf-IDE integration, for his presentation, and for helping me work through issues using it during RubyConf!

If you’d like to work at a place that explores the cutting edge of Ruby and other languages, join us at Big Nerd Ranch!

The post Live Ruby Type Checking with TypeProf-IDE appeared first on Big Nerd Ranch.

1. Interrupting Less Important Renders in React 18

Shruti Kapoor demoed the new startTransition API as part of her talk on “What’s New in React 18?” This API keeps the rest of the UI responsive while carrying out an expensive re-render. This could be used to allow interrupting the rendering of a complex drawing or large table to keep the input elements, selectors, and sliders that control the settings responsive and up to date. This works by marking all the state updates inside startTransition as transitions. These transitions will be interrupted if new data comes along and the stale updates will be thrown out by React. They are still synchronous and unlike setTimeout(..., 0) they start immediately. Another bonus feature is a pending state available with useTransition so you can apply a loading state to the not yet updated content. I’m excited to use this with my next graph or large table! You can read more about it in this discussion.

2. Security implications for hrefs

Syneva Runyan shared a variety of ways to inject javascript into a page of a React application. One that I had not thought of before was the ability to use the javascript: protocol to inject scripts using the href prop.

For example, a user might be able to enter a link to their homepage. javascript:alert('hi') is a valid URL which would cause the user to receive a popup so purely validating that the link is a URL is not enough for security. Using a larger chunk of code, the attacker could tell the user their session had timed out and request the user’s password.

Currently, you can mitigate this by validating the protocol as well as the url

const url = new URL(userInput);
const isHttp = ['http', 'https'].includes(url.protocol);

Note: This does currently trigger a warning in React, and a future version of React will block the javascript protocol in the href.

3. Accessibility in Code and Content

Homer Gaines offered a wide assortment of ways to improve the accessibility of your website. My favorite code takeaway was making sure the hit area for links at buttons was at least 40px x 40px, which is about the size of a fingertip, so it’s easier for people with less accuracy to tap the button. There a many ways someone could have a hard time hitting a small button accurately from a parent holding a fussy child while trying to order a pizza to someone with a broken arm using their non-dominate hand to long-term disabilities such as Parkinson’s disease. When I am using a website, it’s always frustrating to have to try multiple times to tap a button or, even worse, if I tap the wrong button because they are too small. Thus, I appreciate the effort spent in this area as well.

The content itself is another area for accessibility. Many people have conditions like ADHD or Autism that make reading and concentrating harder. Other people are simply trying to multi-task. Keeping text small and building pages that interact as expected helps these people since it will not be necessary to spend a long time reading instructions or figuring out how to use the website.

4. Refactoring Your Way Up

Adrianna Valdivia encouraged developers to own the code base where they work. Participating in improving it through updating package versions and refactoring the code. Then, highlight the learnings and milestones from your improvements in your 1-on-1s with your manager. This responsibility helped her gain promotions in the company.

5. Techsgiving: Giving Back

If you want to give back but are worried it might take too much time, Genesis Bonds suggested setting up a Calendly link with a couple of time slots per week for mentoring. Then, if someone asks for help, give them the link so they can set up some time with you.

At Big Nerd Ranch, we give back with our internships and our apprentice program.

Culture

I also learned about Atlanta culture and Trap music throughout the conference and by talking to other attendees during the breaks. If you want to learn about React while experiencing ATL and Trap music culture, check out RenderATL 2022.

The post Top 5 Things I Learned at RenderATL appeared first on Big Nerd Ranch.

Like everyone here at BNR, I’m a nerd. So, of course, I immediately want to dive into new developer tools.

Developer Tools

The biggest updates that developers will experience daily are the new Swift Concurrency features. Async/await and Actors are two new, powerful tools that are landing in Swift 5.5 and Xcode 13. You can see Apple’s commitment to these new features in the APIs. Async versions of functions have been added to many of the frameworks you already use, such as Foundation’s URLSession. There’s also @MainActor which is a new way to specify that an asynchronous function or property access must run on the main thread. You can now get compiler errors for wrongly multi-threaded code, like trying to update UI state off of the main thread! This is huge!

Xcode 13 has a fresh coat of paint, with much deeper integration with source control platforms like GitHub. You can create pull requests inside Xcode and see code review comments inline and even reply without leaving Xcode.

Apple’s also launching Xcode Cloud, a continuous integration and delivery platform deeply embedded into Xcode and TestFlight. You can set up builds to deploy and tests to run on different branches of your project, all inside Xcode’s UI. I’m surely not going to miss poking at YAML files.

Swift projects get a new tool for generating documentation: DocC, the Documentation Compiler. Markdown documentation comments in your Swift code can now be compiled into richly formatted documentation pages (à la the Apple Dev Docs) that you can distribute to users of your APIs or even just within your own team.

I’ve waited so long for this one: the new Swift Playgrounds for iPad. Entire SwiftUI apps can be built, tested, and deployed to the App Store directly from your iPad. Even more than before, Swift Playgrounds will be an amazing tool for getting started with iOS development. It’s basically a mini-Xcode, and it looks so fun for those weekend side-projects I’ve been meaning to get around to.

iOS 15

Apple opened the Keynote by introducing us to iOS 15, with a focus on shared experiences. SharePlay is a new feature that allows users in a FaceTime call to have shared experiences, such as seamlessly watching videos together. Video content isn’t the only thing SharePlay supports. The GroupActivities framework allows developers to build app features that users can share live over FaceTime. Definitely check out the SharePlay and GroupActivities sessions this week.

The next focus for iOS 15 is… Focus. This is an expansion of Do Not Disturb that allows you to customize your notifications and Home Screen to hide unnecessary distractions based on contexts you create. The API change to pay attention to here is the updates to notification importance and the new Notifications Summary powered by on-device intelligence. Developers can now specify the importance level of each notification so that users are only interrupted by notifications that are relevant to them at the time. This will be a great way to keep users engaged without annoying them into disabling notifications entirely for your app.

There’s still so much more in iOS, but I’ll move on for now.

iPadOS 15

The iPad gained some extra features in addition to those in iOS 15. Widgets can now be used on the iPad Home Screen, along with a new extra-large widget size that’s exclusive to the iPad. Adding widgets to your app is even more of a good idea this year. Your newly-added widgets can even be surfaced to users via Intent donation and on-device intelligence before the user has explicitly added your widget.

The UI for iPad multitasking got some love this year too. In addition to the gestures for splitting and rearranging app windows, there’s now a dedicated control in the status bar for splitting windows or opening an app in Slide Over. Also, tapping an app icon in the Dock will show a temporary overlay showing the user all of the windows they have open for that app, without needing to go to the App Switcher. This fall users are going to expect that your app supports Split Screen, Slide Over, and multiple windows. If you’ve been waiting, now’s the time to add that support!

macOS 12 Monterey

Lots of macOS updates are coming this year. SharePlay support also comes to macOS, AR authoring gets some new tools such as the Object Capture API, and Mac Catalyst apps get some new APIs to be better macOS citizens like menu button styles and more native cursor types.

The Shortcuts app comes to the Mac this year, part of a multi-year update to scripting and Automator. Like on iOS, Mac apps can now offer actions to the Shortcuts app to allow users to build custom workflows.

TestFlight for Mac is coming later this year, so beta testing apps will finally be unified across all of Apple’s platforms.

Here’s to an overstuffed WWDC week!

Thankfully we can all take in all these new session videos at our own pace. I recommend watching all of the “What’s New” sessions in areas you’re interested in first. Then, download the latest Xcode beta and follow along with the deeper sessions and try out the APIs as they talk about them, pausing the video as necessary. There are even some code-along sessions built around this type of live experimentation. Pace yourself, drink water, take bathroom breaks, and remember to have fun!

The post WWDC21 Round Up appeared first on Big Nerd Ranch.

Last week, I attended CSS Dev Conference, the “conference devoted solely to CSS, the design language of the web.” It was held in Estes Park, Colorado at The Stanley Hotel, famous for inspiring Stephen King to write The Shining.

After three days of amazing sessions and getting to hear and meet some of my front-end development heroes, I thought I’d do something a little different from the usual recap. A conference at a haunted hotel deserves no less.

So I present to you…

1. Zoe Gillenwater reads my diary

The opening keynote was given by Zoe Gillenwater, web designer, author and expert on accessibility and responsive web design (RWD). Her talk, “Just One,” was about “evolving who we are as web designers and developers by focusing on the power of ‘just one’ in learning, failing and accepting.”

She pointed out that we often feel like we cannot call ourselves experts in certain areas. She herself would say things like “I’m not a JavaScript person,” when in fact she’s actually pretty good at it. I think a lot of us can relate to this feeling.

Another key point was that you shouldn’t “compare your inside with someone else’s outside.” Meaning, we have a tendency to see the great work of others and just chalk it up to them being geniuses who are better than we’ll ever be. As a developer and an artist, I’m absolutely guilty of this behavior. I’ll see some slick widget or site and think that I could never have come up with that. Most of the time, the reality is that other person may have worked weeks or months on that widget and filled up an entire swear jar getting it to work. And in the end, it’s okay to experiment and fail, so long as you use it as a learning (and teaching) experience.

This was my favorite talk of the entire conference by far. It was as if Zoe knew exactly what I and many other developers deal with every day. Time to change the password on my journal.

2. I should do sketch notes

Select sessions were “sketch-noted” by designer and UX consultant Ben Norris. Ben was hired by the conference, and his hand-drawn notes help to better convey concepts and make them easier to retain. I’m a self-confessed horrible note-taker, but watching Ben in action makes me want to try these.

3. Accessibility is on everyone’s minds

One pleasant surprise was the recurring theme of web accessibility. Dennis Lembree of PayPal led a session called “Usability and Accessibility CSS Gotchas,” in which he highlighted a metric ton of tips and tricks to avoid common mistakes in accessibility implementation.

I was impressed to hear a few other speakers touch on the subject, including Wendee Fiorillo in her “Cascade Engineering” talk and Manik Rathee’s “Building Obama,” which covered how the Obama campaign’s donation form became known as a “masterpiece of interaction design.”

As an advocate of usability and accessibility, I think we still have a long way to go towards an accessible web, but I’m more encouraged than ever by our progress.

4. I’ve been doing some accessibility wrong

Speaking of accessibility, I thought I’d share a practice that I found out I was doing wrong. In Dennis Lembree’s CSS Gotchas session, he talked about best practices for hiding content, both for sighted and visually impaired users.

For instance, if I needed to hide some content from sighted users only, I might have done something like this:

    .hide {
        position: absolute;
        left: -9999em;
    }

However, the better practice is to use the “clipping method,” which is better for screen readers on touch-screen devices and RTL language support, like so:

    .hide {
        position: absolute;
        clip: rect(1px, 1px, 1px, 1px);
    }

Another good tip was to never rely on height: 0 alone in transitions, but rather in conjunction with visibility: hidden.

5. Chris Coyier can rock a keynote

The Stanley lit up red for Halloween.

If you’ve never seen Chris Coyier, creator of CSS-Tricks.com and CodePen, give a talk, you’re missing out. He’s funny, articulate, super smart and passionate about all things CSS. As it turns out, he’s also adaptive. His talk, like all the keynotes, was held in the Stanley’s concert hall, a separate building away from the hotel. This building is notoriously unkind to anything electrical (the crew from Ghost Hunters once made it the focus of an investigation). In fact, it was plagued with audio and video problems all week.

When Chris started his talk, his wireless mic produced feedback that can only be compared to a 747 taking off in the room. Without missing a beat, he went into an impromptu air guitar session to diffuse the situation. Rather than battling with the mic, he removed it and went unplugged the rest of the way.

His keynote, “How To Stay Up To Date On Web Stuff,” dealt with the dilemma we all face: how to keep up on every new, shiny thing that comes along. To make a long story short… you don’t. Nobody can. Instead, we must decide what we want to focus on and learn what interests us. He also gave great advice on how to choose new technologies to implement on projects, asking “Is a technology just short-term cool or long-term right?”

6. Responsive images are still a mystery

According to Christopher Schmitt in his “Adaptive Images In Responsive Web Design” session, more than a year ago he and Chris Coyier had determined there were already at least 24 different responsive image solutions floating around. Most required JavaScript, and many also required server-side scripts. Today, there are even more solutions vying for our attention, including specifications for new HTML methods, such as the srcset attribute for <img> tags, and the (now deprecated) <picture> element.

At this point, which method to implement depends greatly on the needs of your site (or app), and they all come with trade-offs. Hopefully a clear (and browser-supported) winner will emerge soon, but for now, it’s still the wild west for responsive images.

7. Holly”wood” is fake

A quick bit of Stanley Hotel trivia: on a tour of the lobby, our guide shared that the beautiful woodwork we saw was, in fact, not wood at all. When the film crew came to the Stanley in 1996 to shoot The Shining miniseries, they thought the place needed to look warmer and darker. So they added some plaster and drywall beams and airbrushed them to look like the piñon pine found in the billiard room. It looked so good, the hotel decided to keep it after production had wrapped.

8. Style guides are the new black

With the rise of responsive web design, it’s becoming more and more important to document modules and components in style guides that not only serve as reference for developers, but also as living tests for our CSS.

Showing excellent examples from the BBC, Github and Starbucks, Shay Howe showed how creating style guides with real code can help maintain consistency, improve workflow and “educate through standards.”

Nicole Sullivan’s closing keynote, “Creating Living Style Guides,” helped drive this idea home by showing real-world examples based on her work in refactoring the bloated CSS on a large site.

I know from experience that something like a style guide might be the last thing you feel you have time to focus on, but also trust me when I say you’ll be thankful you made the time.

9. SASS still has a few tricks to teach me

I’ve been using SASS for CSS pre-processing for a while now, but I’d never seen this bit, shared by Micah Godbolt in “Get Your Sass in Line: Tips and Strategies for Teams and Large Projects.”

You can create a SASS mixin that can output the content (i.e., the css attributes) passed to it via an @include statement:

    @mixin respond-to($width) {
        @media (min-width: $width) {
            @content;
        }
    }
    @include respond-to(1024px) {
        .sidebar { float: left; }
    }

This will output:

    @media (min-width: 1024px) {
        .sidebar { float: left; }
    }

This is a handy bit of abstraction I’d never seen before, but have happily tucked away in my bag of tricks.

10. Abstract and reduce

Both the SASS talk and the all-day SMACSS workshop by Jonathan Snook really drove home the importance of reducing dependencies in your CSS. Each separate module or component should be able to live on its own, without any specific containing structure. This makes them way more modular and testable, with the added benefit of being droppable directly into your “living style guides” (remember those?).

11. 3D transforms are seriously cool

Chris Ruppel’s session, “Unfolding the Box Model,” was a mind-blowing excursion into the world of 3D transforms in CSS, and one of the most popular talks of the conference. Simply talking about it won’t do it justice. Do yourself a favor and check out his live demo on Github. Use your left and right arrow keys and prepare to be amazed.

12. People who speak at conferences are just like us

I stood outside the infamous Room 217.

On the last day, all the speakers were assembled for a wrap-up Q&A panel. I asked them, “How do you balance speaking, writing and podcasting, versus doing actual client and consulting work, versus having a family life?”

Nicole Sullivan responded that most of them probably got a lot less sleep than they should, take on too many commitments and have a problem saying “no.” Chris Eppstein shared a touching story about how he used to be a workaholic and then realized “my two-year-old was now seven,” which made him shift some priorities.

Another popular bit of advice was to stop comparing yourself to others. Only you can decide what your work/life balance should be. So often we see what others are cranking out and think to ourselves, “I’m a total slacker,” but in reality, those people may be missing out on the things you take for granted. A nice little bit of perspective from folks many of us have looked up to our whole careers.

13. F.O. Stanley was the 1900s equivalent of Steve Jobs

Portrait of F.O. Stanley

When you stay at The Stanley Hotel, it’s impossible not to hear stories about its creator, Freelan Oscar (F.O.) Stanley and stand in awe of his accomplishments. Not only did he build the hotel and revitalize Estes Park, he co-invented the Stanley Steamer, a car that ran on steam and was capable of speeds of more than 125 miles per hour. He also held many patents, including one for photographic dry plates, which he later sold to Eastman Kodak. Oh, and he also made violins he sold for $100 apiece, which now sell at auction for five figures.

It seems that every day, I was learning some new fact or bit of trivia about F.O., and I became intrigued by this Rocky Mountain entrepreneur. If he does indeed haunt The Stanley, I’d like to think he would be happy to have so many great minds converge on his hotel to fill their brains with three days of learning in the crisp mountain air.

The post 13 Scary Cool Things I Learned at CSS Dev Conf 2013 appeared first on Big Nerd Ranch.

Last week, I got to attend a tech conference… without internet access.

I was lucky enough to go to dotRB, a unique Ruby conference, and I loved the format, approach and experience.

A different approach

dotRB’s goal is to offer brief, TED-talk-quality talks in a scenic setting…without providing internet access to the attendees. During the first session, I sat on the top terrace level. Looking out over all the lower terraces and the opera level without seeing lots of bright screens and hearing the rapid typing of the conference-goers was such a neat contrast from other Ruby events I’ve attended. Instead of tweeting about the speakers and the talks, everyone was actually absorbing the presentations. And given the historic setting, a wireless-less conference seemed only natural.

The twenty minutes slated for each speaker ensured that no time in the talk was wasted; this isn’t to say that we didn’t hear about velociraptors from George Brocklehurst or deadly “cookie” recipes from Konstantin Haase, but I found that each speaker was very purposeful in the material he or she covered. As a listener, my curiosity was piqued repeatedly, and I was given enough information to begin informed research of my own. Each speaker had time to either cover an idea in a full and broad way, or to cover one facet of an idea in a deep way; this led to a nice medley of approaches and topics. It felt like a proper variety show.

Two of my favorite talks could not have been more different. The first was by George Brocklehurst and featured a live coding session that showed how to include good “unixy” error handling and documentation when running Ruby programs in the console; his goal was to present an interface good enough to illicit the famed exclamation “It’s a unix system; I know this!”

The other was from Erik Michaels-Ober, who outlined the history of the technological leaps from the Big Bang to the invention of language, of written word, of paper, of the printing press, of the telegraph—all the way to Twitter. He reminded us that each tool required the invention of a prior tool, and challenged us to continue building the tools of today, because the tools of the future depend on them.

For those who want to hear about a range of subjects deemed interesting by some of our accomplished peers, dotRB is for you. It was a great opportunity to learn together—fully engaged.

The post dotRB: Getting Plugged In at a Wireless-less Conference appeared first on Big Nerd Ranch.

I recently went to Boulder, Colorado, for the 2013 Rocky Mountain Ruby conference. More than 300 Ruby enthusiasts gathered there to attend workshops, presentations, drink ups and more.

The talks

For me the highlight of the conference was the presentation given by Eugene Kalenkovich titled “Rails: Shadow Facets of Concurrency.” Eugene used some simple examples to show how concurrent processes can create real problems in Rails code. He used code to assemble “dogs,” each made up of ActiveRecord objects called Dog, Head and Leg. Head belongs to Dog, Dog has many Legs, etc. Running on a single process, the code behaved as expected in specs, assembling 20 full dogs from the component parts.

Kalenkovich then introduced concurrency to his code, simply by adding ‘concurrently do’ to his spec. The result was a humorous collection of headless dogs with seven legs, two-headed dogs with three legs, one-headed dogs with 10 legs, and more (As Andres Alvarez noted, coders don’t play God, but…). Kalenkovich then showed us how to prevent these problems by applying some simple data integrity checks, keeping our reputation as mad-scientist developers minified.

His examples were humorous, light-hearted and effective (he also did a demonstration of concurrency problems with deployment using audience members and lollipops), but they did an excellent job of making simple some of the problems we face with concurrency, a topic that can sometimes feel overly complicated and hard to understand.

Katrina Owen gave a talk called “Here be Dragons,” which applied game strategy theory and the concepts of “winning” and “losing” to cooperative software development and refactoring on long-term projects—this provoked some very interesting thoughts in my naturally very competitive brain.

Ben Smith also gave an excellent presentation called “How I Architected my Big Rails App for Success,” which detailed how the application he manages scaled as it grew, and how the development and operations teams have handled the growth needs by extracting individual components of a single Rails app out into many independent engines.

The presentations I found most valuable were those that focused on the problems that successful applications have once they grow and scale. As I progress as a developer, I encounter more frequently the problems caused by the success and growth of an app, which are good problems to have, but can be challenging nonetheless. Having a chance to see how other developers have tackled these problems is invaluable to me, and I definitely felt that I got access to lots of new information at RMR13.

I also learned about a new deployment platform designed specifically for Rails called Ninefold. Ninefold aims to be a player in the cloud deployment market currently dominated by Heroku. I promised the Ninefold guys I’d bring their pitch back to Big Nerd Ranch for our developers to test and and experiment with. One of the devs on my team has already opened an account and is sending me his impressions.

If you’d like to check out the presentations, videos will be available soon on Confreaks.

After the end of the conference, I hiked to Mt. Sanitas and back.

The community

One of the great things about this conference was its emphasis on charitable giving, specifically in regards to Colorado flood relief. Just a few weeks before RMR13, Boulder and the surrounding area were devastated by a 100-year flood event that caused more than $90 million worth of damage to the county. At the conference I found out about a charitable fundraising application built on a Ruby platform called Booster.com, which provides a means for crowdsourcing charitable giving via t-shirt sales. They spotlighted a campaign to help raise money for flood relief efforts. In the end, RMR13 was able to give a total of $5,280 to charitable causes, and it was great to see the Ruby community coming together to help others.

I met a bunch of new people who were fans of Big Nerd Ranch and I had a great time at the conference. A lot of people seemed surprised, and impressed, that I had traveled all the way from Atlanta to attend. I think that reaffirmed a goal of the organizers that the conference be national in scale or even global in its influence. I met an alumnus of our beginning iOS course at Banning Mills, which was cool. I would definitely recommend attending Rocky Mountain Ruby in 2014 to anyone in the Ruby community, and I hope to return myself.

The post Digging Ruby in the Rockies: Rocky Mountain Ruby 2013 appeared first on Big Nerd Ranch.

In my professional career, I’ve never felt prouder than when I was accepted as a speaker at RubyConf India. I’ve spoken at numerous user groups, helped organize events, and even performed in front of huge crowds, but this was the first time I had been given the opportunity to speak at a conference.

My goal was to put together a quality presentation on debugging that would help the attendees in at least one small way. If each person, from advanced to beginner, were to walk away with at least one new insight or piece of information, then I would be happy.

I found myself achieving that much and more. I met so many friendly people at this conference, had a lot of good conversations and made a number of #rubyfriends—more than at any other conference I’ve attended. And while the accolades and interest in my talk were wonderful, discussing my work, good code and great co-workers at Big Nerd Ranch was the best part of all.

The Talks

There were many other excellent talks at the conference and I enjoyed all of the ones I attended, but I found myself most inspired by three talks in particular:

1. Siddhant Chothet’s talk on accessibility and Ruby illustrated how easily the Ruby community could improve accessibility for users and developers. This talk wowed us as Siddhant demonstrated the challenges and impressive capabilities of blind developers. I would be remiss if I didn’t note that though Siddhant did have slides, he did not read from them, as he is blind himself. Not only was this his first talk at a conference, Siddhant gave the whole presentation from memory! If you want to support his work, check out the brails project.

2. Sau Sheong Chang created beautiful music for us using pure Ruby, turning tweets into music. He shared just enough of the basics of music theory and the physics of music to walk us through his newly released muse gem. I love music and have played the piano for many years, and I look forward to creating music with one of my favorite tools, Ruby. Step one? Add a hubot script that makes use of muse in some fashion.

3. Our own Andy Lindeman gave the closing keynote. In this talk, he revealed how much we all benefit from open-source software, thanks to the many developers who have given freely of their time and effort. I highly recommend that everyone in the Ruby community see the talk. While Andy’s talk focused only on the code written in Ruby libraries, I find myself flabbergasted at how much benefit we derive from open source, free technologies when considering the full stack of operating system, database server, web server, web browsers and client-side technologies!

Next year

But a summary of a few talks alone doesn’t do this conference justice. It’s definitely a should not miss, and I’m already planning a talk for next year. I hope to see you there.

The post Inspiration and New Friends at RubyConf India appeared first on Big Nerd Ranch.

We’re settling into our usual routines after returning from a great week in San Francisco and WWDC. We wrote about the WWDC keynote, both its focus on users and on its attention to the details. Aaron spoke at AltWWDC and at the Union Square Apple store. We ate delicious food and managed to sneak in visits to a few sights.

More photos available on our Instagram.

And of course, we threw a thank-you party to celebrate our clients, alumni and supporters, complete with fortune tellers, handwriting analysts and  a photobooth with a variety of props and swag.

Check out the rest of the photobooth photos on Flickr.

We’d also like to announce the winners of our scavenger hunt:

• Ted Moskalenko and Barlow Tucker each won a trip to Big Nerd Ranch West, including a bootcamp of their choice, meals and accommodations.
• Barlow also won breakfast with Aaron Hillegass the day after our party.

• Del Brown won a free bootcamp at either our Atlanta-area Ranch or Big Nerd Ranch Europe.

• Warren Moore won 25% off any bootcamp, and Julie Johnston won 20% off.
• Veronica Haskell won a combo pack of our programming guides.

Thank you to everyone who made it such a great success, and we look forward to seeing our friends, old and new, next year!

The post WWDC Gypsy Caravan appeared first on Big Nerd Ranch.

Big Nerd Ranch recently sent Brian Gardner and me to the Railsberry Conference in Krakow, Poland. Having been to several Rails conferences already, I expected some technical talks, Agile process talks, and the requisite talk on refactoring.

What I found at Railsberry, which is advertised as the conference for “curious” Ruby on Rails developers, was far from formulaic and typical. It was one of the most unique, fun and well-organized conferences I’ve attended in my career as a developer.

A different kind of conference

So how did Railsberry show me a different kind of conference experience? First off, ask yourself this question: Have you ever been invited to attend a contemporary dance performance by the conference organizers? Odds are that you haven’t, unless you’ve attended Railsberry.

Have you been able to swing back and forth while watching a lightning talk? Odds are, again, that you’ll have to say no. But this is what the modus operandi is at Railsberry; in fact, upon arrival at the conference, you’re inundated with a different look and feel. The conference itself is an experiment, meaning that the organizers try different, new ideas and see if they work. They embody a curiosity towards everything that permeates the entire two-day, single-track event. I was actually initially greeted and welcomed by conference staff wearing laboratory coats! (Were they experimenting on me?) When a conference speaker wasn’t able to attend the conference, it was no big deal. The conference organizers simply opened the floor for more lightning talks.

Learning something new

Let’s not forget the reasons we attend conferences: to learn something new. And there was a slew of great talks by a variety of speakers from various professional positions. We listened to Gregg Pollack walk us through the current state of the online education business as it pertains to learning code. We were enlightened by Fred George’s talk on implementing Agile methodology for any development team. As a 40-year industry veteran, his insight into how a company “should” do Agile was eye-opening, to say the least. He even called out some of the practices that we currently use at Big Nerd Ranch (our ego is not damaged; indeed, we love learning from others as much as we love teaching). The most outstanding and thought-provoking presentation was Joseph Wilk’s talk called “Creative Machines,” where he explored the ways that computers can produce music.

All in all, this event is a standout amongst the global collection of technical conferences a Ruby on Rails developer could attend. It was entertaining, thought-provoking and fun. I can’t recommend this conference more highly.

The post Railsberry: A Different Kind of Conference appeared first on Big Nerd Ranch.