About Madison Ruby Conference - produced by .
About Madison - produced by .
Ruby is good for more than just making web pages and APIs. Its expressiveness makes it a good candidate for creating real world simulations. Out of the box, Ruby has some nuances that might make you think otherwise. In this talk, we'll review why Ruby is a great choice for creating simulations, and discuss hurdles and solutions for problems that you will run into. Topics include concurrency, domain modeling, testing, and more exciting topics.
Everyone acknowledges that the software field has an issue with gender balance, but there are many of arguments about what to do about it. Recent events have caused the community to scrutinize how they treat the issues of race and gender. The social justice community uses the term 'anti-oppression' to describe techniques for being more inclusive to people of a wide variety of backgrounds, ethnicities, sexualities, and genders. Software developers generally lack exposure to these terms and techniques.
In this talk, Lindsey and Steve will introduce basic anti-oppression concepts, and provide specific examples of situations where we as software developers can use these tools to engender a more inclusive community.
As systems grow in scope and complexity, the old way of using deterministic methods to analyze a system is becoming less and less relevant. Given the enterprises new love of catch phrases like "Big Data" and "Data Science" - it is now more important than ever that those of us who write software understand the basics of statistics.
Some data is better generated in batch, for example: user session data, ad click through rates, sales conversions, and recommendations.
Unfortunately, to generate these useful pieces of information you have to process GB, or maybe even TB of log and database data files.
Enter Hadoop Map-Reduce, a linearly scalable way to process vast amounts of data with relatively trivial code.
Getting started with Hadoop can be a total time sync, to prevent this, I'll try my best to lead you in the right direction and go over the following points:
1) MapReduce and Hadoop 101
2) Getting Data into Hadoop
3) Running a MapReduce job in Ruby (!)
4) An overview of Ruby MR helper frameworks
5) Using SQL for ad-hoc data queries via Hive
6) Integrating these jobs into your ruby app framework (scheduling, starting jobs, getting the data out again)
Plus the bonus:
7) How to use this setup to automate A/B testing and totally blow your mind.
The bar for contributing to open source is much lower today due to technologies like git & github... _or is it_?
It is now downright simple for developers to be able to fork projects and send pull requests upstream. As such, the number of forked projects and pull requests have scaled up. But all that burden has been shifted back to the maintainers of the original project. They're left with the decision to accept the patches as-is, reject them, or rewrite them in a more generalized form.
In other words, the maintainers are faced with the decision of increasing maintenance complexity, increased animosity / drama, or somehow distilling the underlying reasoning behind the change and abstracting them so they're usable by everyone.
The latter is both the hardest to do and the most beneficial to all parties involved and much of that effort can be done before the pull request even goes upstream.
It may seem unusual, but my greatest understanding of software development comes not from computer courses or books but from my background in Theatre. In a performance many separate parts (acting, lighting, sound, costumes) must be developed independently, but still form a cohesive whole to express a director’s vision. The same is true of software development. Design, code, databases, testing, etc. must all connect seamlessly to create an illusion for your audience. This talk will cover coordinating disparate elements which must work independently but also complement and enhance each other, assembling your cast and crew, audition techniques, dealing with divas and your artistic visionary's whims, surviving opening night, dealing with reviews, and much more.
An examination of the internal and external problems you'll face in all levels of the business. Using humor as a weapon, Martin Atkins will point out the obvious, throw light in some dark corners and create another illuminating event illustrating the realistic, attainable goals that are possible in the new business.
A Lightning talk is a short presentation. Unlike other presentations, lightning talks last only a few minutes and several will usually be delivered in a single period by different speakers. In this case You. There will be an open sign up for talks in these slots and speakers can bid their way to the top of the list by delivering their message in the shortest amount of time.
Clyde Stubblefield (born April 18, 1943 in Chattanooga, Tennessee) is a drummer best known for his work with James Brown. Stubblefield's recordings with James Brown are considered to be some of the standard-bearers for funk drumming, including the singles "Cold Sweat", "There Was A Time", "I Got The Feelin'", "Say It Loud - I'm Black and I'm Proud", "Ain't It Funky Now", "Mother Popcorn", and the album Sex Machine. His groove on James Brown's "Funky Drummer" is believed to be the world's most …
Convinced that nobody can bully method_missing() and get away with it, Nusco resolved to present a talk about it. When is method_missing() appropriate, and when should you pick an alternative metaprogramming magic spell instead? Is method_missing() really dangerous? What are the common method_missing() pitfalls, and how can you avoid them?
This talk applies the concepts of chaos theory to software development using the Bak–Tang–Wiesenfeld sand pile model as the vehicle for exploration. The sand pile model, which is used to show how a complex system is attracted to living on the edge of chaos, will be used as a both a powerful metaphor and analogy for building software. Software, it turns out, has its own natural attraction to living in its own edge of chaos. In this talk, we'll explore what this means and what to do about it.
The speaker's hypothesis is that by understanding how complex systems work we can gain insights to better understand and improve the act of building software. By looking through the lens of the sand pile model we'll explore the following:
* what chaos theory and the sand pile model can tell us about software development
* how the act of building software compares to complex systems from the perspective of chaos theory
* how software is naturally attracted to its own chaos
* the impacts on software living perpetually on the edge of chaos
* how existing software practices can be used to detract software away from chaos
* what this means not only for our software, but for our teams, and ourselves individually
This thought-provoking perspective will leave you with new ways to think about software. You’ll walk away having learned about chaos theory, complex systems, and how they apply to software.
One of the best ways to make applications perform well is to develop them to handle things in parallel and asynchronously. From parallel processing to asynchronous IO, when you need an application to perform well you need to think asynchronously. This talk will cover various means of parallel processing and asynchronous communication available to Ruby applications such as threading, using multiple processors and non-blocking IO. It will also cover libraries built to support asynchronous execution such as Resque and EventMachine.
Rails owes much of its popularity to how it has helped many startups
take products to market quickly. Using Rails and similar frameworks has
enabled many startups to compete with far larger companies who are
burdened with complex architectures and outmoded technologies, and
revolutionized the practice of web development.
But what happens when enterprises use Rails to compete with *startups*?
Can a framework born out of frustration with "the enterprise way" of
web development become a new standard for how large organizations solve
their web development problems? Is Rails an anti-enterprise partisan
framework, or does it want to increase the joy of developers regardless
of the nature of the organization for which they work?
I think the answers to these questions are important for the future of
both Rails and many complex enterprises that could benefit from the
Rails approach to web development.
I'll take a case study of Rails adoption within a larger company
(Getty Images) to talk about:
- How Rails fits into complex multi-application environments
- Arguing the case for Ruby in a Java/.NET dominated world
- Sane, lean architectures for managing change driven by different
parts of a business
- What the Rails community has to learn from the Enterprise
- Organizational patterns of adopting new technologies
- Using open source to help enterprises be more competitive
- Strategies for paying down technical debt as you go (without going
A lot of Ruby developers use Rails for their everyday projects. Often they toy around with front-end themselves or outsource it, ending up tangled in a web of css-all-over-the-place.
Keeping your front-end code clean is hard. Before you know it you're suffering from CSS specificity issues and not-really-generic partials. Find out how to keep things tidy using the HTML5 document outline and modular Sass & CoffeeScript, for truly reusable code.
One in six people in the united states has a "disability". Some of these prevent them from using the internet. They may have low or no vision, balance issues, hearing issues, or motor control issues. I'll discuss what we can do as developers to conquer these hurdles and deliver a rich user experience to everyone regardless of abilities. Technology can be the great equalizer if we spend a little time making it so. It's easier than supporting IE6.
You've landed a great opportunity to work with some of the smartest people in the industry. You can barely contain the enthusiasm to learn and contribute to the team. You may not have all the required technical skills on day 1, but you are confident that you will get there with the support from your team. It's exciting & stressful at the same time because you need to start contributing right away.
A lot of developers find themselves in these shoes, just as I did in not-too-distant past. This talk offers specific strategies and tactics developers of all skill levels can use to start making an immediate impact. These strategies have enabled me to contribute quickly on a new team and I want to share it with you so that they can help you on each new project or team you work with.
The talk will primarily focus on:
* Techniques for quickly learning a new codebase
* Finding ways to have a significant impact quickly
While this talk is from the perspective of someone new to the team, I feel that it will also help experienced developers better understand the mindset and needs of new team members necessary to help them onboard new developers quickly and effectively.
We live in a time of rules. These rules are collectively created in the guise of our own protection and safety. Rules, however, come with steep cost: risk aversion. This session is an exploration of the rules that inform our behavior and an exploration of how to break them to drive innovation both in the work we create and the lives with live. Be more. Go Gonzo.
Being programmers, we think of our users like we think of our code. That is: rationally. However, our users are emotional, irrational, and specifically evolved animals. The study of Sociobiology has some really interesting insights for software developers about who your users really are and how you can influence them. For instance, badges seem dumb to me, but why do they work so well for other people? Why do people keep playing Farmville? From AAdvantage to Klout, manipulating people with evolution is all around!