by Sarah Allen
Heard about JRuby, but unsure how to dive in and start using it? I'll take you through your first steps. We'll handle how to install JRuby, examine some of the runtime differences between JRuby and MRI, and take a look at some of the JVM deployment and diagnostic tools at your disposal.
Space is limited, please register at http://www.eventbrite.com/event/.... Choose the "Getting Started with JRuby" ticket. Only valid with a conference pass.
Learn all about Graph Databases and how you can add Neo4j to your projects. After a quick introduction, you'll learn how to use the REST API directly from Neography to get the basics and then hands on experience with JRuby and Neo4j.rb.
We'll cover property graphs, common use cases, domain modeling, algorithms, visualization, gremlin, cypher, deployment to heroku, graph indexing and answer all of your questions.
Space is limited, please register at http://www.eventbrite.com/event/.... Choose the "Intro to Neo4j" ticket. Only valid with a conference pass.
With so many languages on the Java platform, there are real benefits to learning and using them. However, these languages bring along some challenges as well. Attend this keynote to learn, from a world renowned polyglot programmer and author of books on multiple languages, the pleasures and perils of being a polyglot programmer.
Surely something JRuby-ish from the JRuby guys.
by Jeff Casimir
Rails 1.0 was about proving we could build the same functionality as the other web frameworks, but doing it faster. Rails 2.0 was about pushing the vanguard forward, setting new trends for how the web should be built. Rails 3.0 paid down technical debt and laid the foundation for our future. Now what?
Rails has always guided developers down the "golden path" of best practices. Let's look at potholes needing filling, ways we can straighten the dangerous corners, and figure out where this road might be heading.
by Ian Dees
At last year's JRubyConf, we talked about Thnad, a fictional programming language. Thnad served as a vehicle to explore the joy of building a compiler using JRuby, BiteScript, Parslet, and other tools. Now, Thnad is back with a second runtime: Rubinius. Come see the Rubinius environment through JRuby eyes. Together, we'll see how to grapple with multiple instruction sets and juggle contexts without going cross-eyed.
by Joe Kutner
This talk will help you bridge the gap between enjoying JRuby, and using it in the real world. JRuby can simplify your deployment architecture, while making your application more reliable, scalable, and easier to manage. You'll quickly see the benefits, but it will require a new technology stack.
There are three deployment strategies that can be used with any Rack-based JRuby application, and this talk will provide an overview of each of them. We'll also discuss the technologies that make them possible, and when it's appropriate to use each strategy. You'll learn how the Warbler gem can be used to create an web application archive file. Then we'll discuss how the light-weight Trinidad web server can be used to create a flexible, modular deployment that still feels friendly and familiar. Finally, you'll learn how to power an application with TorqueBox, an all-in-one environment that includes built-in support for messaging, scheduling and daemons.
by Sarah Allen
Test-driven development is mom-and-apple-pie to Rubyists, but knowing that a product will work goes well beyond bug-free code. How do you catch a design flaw early when all your tests are green? We'll look at some techniques for vetting your go-to-market strategy and other things you should be doing *before* you start writing code.
by Jim Remsik
This talk will seek to raise recognition in our community to the fact that there are real people behind Open Source Software. We'll analyze the black box retrieved from the wreckage of well-known community disagreements. Suggest how to move the conversation forward as well as discuss tools and techniques for diffusing potentially explosive situations.
by Christian Doten
by Nate Schutta
Technology changes, it's a fact of life. And while many developers are attracted to the challenge of change, many organizations do a particularly poor job of adapting. We've all worked on projects with, ahem, less than new technologies even though newer approaches would better serve the business. But how do we convince those holding the purse strings to pony up the cash when things are "working" today? At a personal, how do we keep up with the change in our industry?
This talk will explore ways to stay sharp as a software professional. We'll talk about how a technology radar can help you stay marketable (and enjoying your career) and how we can use the same technique to help our companies keep abreast of important changes in the technology landscape. Of course it isn't enough to just be aware, we have to drive change - but how? This talk will consider ways we can influence others and lead change in our organizations.
by Yoko Harada
A month before the JRubyConf 2011, pure Java Nokogiri made the first release. Since then, pure Java Nokogiri has caught people's attention. It is faster than FFI version, no struggle to install, no worry about a dependency, etc. Prior to the JRubyConf 2012, pure Java Nokogiri made the second release. The latest version had a Java integration feature as well as many bug fixings. Doesn't it sound awesome? Not just that. It is already a Tokaido-nized. It can be integrated with JVM languages. It is a well-used JRuby extension. It made performance improvement. Why don't you create something like this? I'll dig into how pure Java Nokogiri made that.
by David Wood
Jun Group is the leader in social video distribution for Fortune 500 brands. This means fielding thousands of requests per second from the largest Facebook games, websites and mobile applications. The industry demands real-time reporting in this data-rich milieu, and our tightly-integrated partners demand zero-downtime solutions. The company's explosive growth made getting there a breakneck race for the technology team, from MRI Rails prototype to Cloud-based infrastructure.
Our team attended JRubyConf in 2011, and afterwards we chose to use JRuby in our fight to reach web scale, not only to boost performance but to escape to the Java platform and language ecosystem (and leverage cheap Amazon Elastic Beanstalk JVMs).
This is the "performance" talk I wish I had seen. We explain both the architectural and operational work involved in our move and how it enabled us to hit our time-to-scalability, reliability, and feature targets. Along the way we can discourse on the surprising opportunities that spring from multi-lingual, JVM-based development and the crucial benefits of regaining "working" multithreading, for instance as they relate to our sub-second clustered monitoring and self-tuning capacities, or our data storage and caching strategies.
by Xavier Shay
An experience report! Follow the journey of JRuby at Square, from humble beginnings to becoming the accepted standard for deploying Ruby applications. Along the way we'll discover the ups and downs of many packaging and deployment options, Java integration, mutual SSL authentication, real threads, cross-ruby compatibility, and a few surprises thrown in for good measure.
Two words seldom heard in the same sentence are Ruby and Graphics… at least without laughter soon following. We've heard it all before: Ruby is too slow; real graphics are done in C, CplusPlus, or Assembler; there's no support for OpenGL in Rails.
The excuses may be many, but the reasons are few. With JRuby we have access to a tool that bridges the worlds of Java and Ruby. With Java Native Interface (JNI) we have a bridge to the world between the low level interfaces that rule the bitmapped and bump-mapped world. Combining the two allows us to use a language we love to tackle problems that used to be the domain of esoteric solutions in low level languages.
This talk explores how to use our favorite scripting language and the breadth of the Java ecosystem to generate interactive visualizations with less pain and fewer segfaults than we've come to expect for using Ruby to tackle "low level" problems.
The object database never became a huge success despite some real benefits like no impedance mismatch, no need for a complex or leaky ORM layer and great performance (e.g. no slow JOIN operations). A graph database has similar advantages but not the same disadvantages since it avoids coupling the database with a programming language. Instead, it uses the simple language of a graph (node, relationship and properties) for interaction with the database.
There are many problems which, really, only a graph database can solve properly. We'll show you the real world challenge, transposing from whiteboard to graph database using Neo4j running in Rails.
If your database cause you trouble because you need to persist or query data with many relationships between entities or if you're just curious why we believe graph databases are the next big thing then this talk is for you.
by Tony Arcieri
Threads versus events: which should you choose? How about both? In this talk you'll learn about the Celluloid concurrency framework, which combines OOP and the Actor Model to give you concurrent Ruby objects. You'll also learn about how Celluloid lets you combine blocking I/O and asynchronous evented I/O, offering you all the benefits of EventMachine without the restrictions of a single event loop. The talk will also provide a brief introduction to DCell, a distributed extension to Celluloid.
The interactive industry has a little PR problem: half the world sees us as reclusive loners sitting in dark rooms, and the other half sees us as app-happy adult kids riding through offices on scooters. However inaccurate this is, we have to change it. Future projects are riding on it, our industry is depending on it, and end users need it.
The web is about people. And the quality of our work on the web directly correlates to how well we work with people. We have a responsibility to make projects better and to create end products that are actually--in practice--the best solutions for our clients' problems. We have to learn to talk about what we do and how we do it, we have to teach clients how to think intelligently about the possibilities and realities of interactive products, and we have to ask our team members to do the same.
A lot of this starts with a good process. A good process serves every team member. Most importantly, it facilitates productive communication and collaboration, a critical requirement for good work. But to be good, a process needs team-wide participation. It only benefits everyone if everyone takes part, and projects go smoother only when the full team is involved. Everyone who works on interactive teams should care about and demand good process.
Drawing on our new book, Interactive Project Management: Pixels, People, and Process, we'll discuss the framework the Geek Girls Guide developed to establish a high standard, industry-wide way of approaching digital projects. We'll outline how to collaborate well no matter what role you play on the team, give a high-level overview of an interactive process that works with any type of interactive product, and articulate the kind of thinking that's required for successful, effective results.
21st–23rd May 2012