A Code Kata is a simple programming exercise, practiced repeatably by a developer. Much like a musician practices scales and finger exercises to develop his musical skills, a developer will practice code katas to develop his programming skills.
This talk will be a live performance of a simple TDD-based code Kata, followed by an analysis of the forces and choices involved in the feedback loop between the code and the tests encountered during the kata. By examining this interaction of tests and code, we come to a better understanding of how to use tests to actively affect the direction of our design. By reflecting on the process, we understand how to pick "what to test next".
This talk is targeted for developers who have started using Test Driven Design (TDD) and feel that they don't quite "get it" yet, and are looking for guidance in the technique.
5 years after ruby programming language came into vogue(1995), bioruby came into existence in 2000, both developed in Japan. BioRuby project provides an integrated environment in bioinformatics for the Ruby language. This project is supported by University of Tokyo (Human Genome Center), Kyoto University (Bioinformatics Center) and the Open Bio Foundation.
On one hand we have the Bioinformatics, the large database of the huge genome sequences, the search algorithms to search the gene similarity between different organisms, gene-mutations using the popular search tool Blast, Fasta etc. BioRuby helps us to do the same searching thing using ruby programming language. As ruby is a pure object-oriented programming language(everything in ruby is an object) and being a easy to read and write, it's fun to use here without being lost in the plethora of genomic data.
Learn about the genes, which controls everything you do and find out how you can ease the task of your similarity with a mouse, and I am not kidding! Welcome to the ruby in the living world, integrating ruby with the Bioinformatics and have fun.
Ruby developers are no longer an outcast for creating pure native iOS applications. With revolutionary tool chain RubyMotion we can make use of every bit of powerful iOS SDK and the best part of this is without using Xcode ;)
In this talk we will first introduce you to RubyMotion and next dive deep into how RubyMotion works. We will further discuss how RubyMotion has an edge over iOS development using Objective C, we will discuss in depth on RubyMotions uber cool features like "terminal based development"; "RubyMotion flavored gems", "REPL" and many more
Lao Tzu's ""Tao Te Ching"" is the second-most translated book in the world, after the Bible. It's 81 poems share with us a glimpse of philosophical thought from China, over 2500 years ago. These poems, like other substantial philosophical literature, have largely stood the test of time and still have lessons to teach. We will be reframing the lessons from the Tao Te Ching as lessons we have learned as the operators of humanity's greatest artifact.
On naming: Lao Tzu warns us that names are not eternal and that while names have their utility, we should recognize their limits. We see the same in our abstractions: we can walk too far down the road of pattern-recognition whether named patterns or patterns captured as an encoded abstraction; we can pile up too many abstractions or layers and in our attempt to separate ourselves from complexity we create a new kind of complexity; we can become overly invested in our abstractions, patterns, and layers -- and the names we give them -- such that they outlive their usefulness.
On returning: _why recently released a series of dark stories describing his exit from the public eye and from programming. One of his central themes was his preference for the greater longevity of human languages over computer languages. His fate is a warning: Being a programmer requires that we enter into our endeavour with a willingness to let go of what we create.
On usefulness: ""We turn clay into a pot; But it is the space where there is nothing that makes it useful."" Software is not a physical thing and, as such, most of its construction occurs within our imagination. The words we type into a text editor are only the recipe. Upon execution, these words come to life and a world of hidden beauty and complexity erupts. Even within the runtime environment of a program, there are hidden solutions and hidden problems. There is always more to understand.
On humility: ""Knowing others is wisdom; Knowing the self is enlightenment. Mastering others requires force; Mastering the self requires strength."" Programming is a social task. We must always remember there is no perfection to our craft and that compassion for our coworkers is essential. Here, I will go into a brief story about the worst programmer I've ever known.
Each of these themes (and others) will be explored with code which highlights the idea or exemplifies change over time as described in the passage.
Other themes may include: beauty vs. ugliness, avoiding greed, effortlessness, the impartiality of the universe, accepting disgrace, fruit over flowers, constancy and sustainability, leading without dominating, ""a great tailor makes few cuts"", weapons are instruments of fear, creating without claiming, soft (dynamic) overcoming hard (static), letting go of knowledge and opinions, avoiding distraction, ""without awe there is disaster"", the simple life, laws create thieves, ""a journey of a thousand miles starts with a single step"" / ""give as much care to the end as the beginning"", etc."
"Do you really care about the temperature or humidity or wind velocity? Or do you actually care about catching cold in a windy weather or perhaps getting a heat-stroke in tropical summer?
When you track the Click Through Rates (CTRs) of your email marketing campaigns, do you really bother about the number of people who opened your emails? Or are you looking for the users of the system who are more likely to buy your product?
Which ones among your Facebook Close Friends are the most likely to hang out with you in case you asked them for dinner tonight?
Let's skip the number-crunching analysis that follows. How about building systems which directly take you to the answers you are looking for, without worrying too much about the numbers that play a role in between? This talk opens a perspective of arriving at a solution by applying graph theory in practice. Here we discuss common scenarios where a graph database could fit and scenarios where it need not fit. The talk covers some of the most popular Open Source graph databases available right now.
This talk also covers various Ruby bindings for some Open Source graph databases. Rubyists who are on their course of building software which involves recommendation, predictive analysis, collaborative filtering and context mining, should find this talk useful."
This talk is about how ruby can be used to write exploits and carry out penetration tests using the Metasploit Framework which happens to be the largest ruby project so far. MSF provides array of commercial grade exploits and an extensive exploit development environment, all the way to network information gathering tools and web vulnerability plugins. I shall give a quick intro to the interfaces that MSF provides, different components of the framework, and how it can be used in different phases of security analysis and pen-testing. I shall mainly talk about the usage of ruby for scripting payloads and other exploits.
Security is something that is largely ignored by developers and other IT professionals. I intend to show how MSF makes it simple enough through the use of ruby.
NOTE: This is not a tutorial on security or vulnerability exploitation as RubyConf is not the forum for it. The main focus of this talk will be to demonstrate usage of ruby for pen-testing.
Audience: It can very well be a Beginner level talk since in terms of ruby, I'll stick to the basics; but I wont spend too much time trying to explain pen-test concepts like vulnerability, exploit, payload, etc; so a basic understanding of these would help.
We are all building products - web products , ours or other's; or dreaming about it. And Rails, Agile and Sound OO design makes that simple. As simple as following well laid out instructions ( assuming off course, that a viable idea has first come out of *somewhere* and has *someone* chasing it).
What I intend to do with this talk is to ponder, publicly, on the consequences of introducing a simple design decision while going about *initial* brick laying - splitting the product into separate API and front_end processes from the very start; and consider the tech and biz consequences of this over time.
Duh. An API sounds very elementary; especially if your product is designed to have multiple front_ends spanning the web and mobiles. I would still think this an open topic and an excellent way of spending 25,000 minutes of collective time and here's why:
* I saw this decision taken on a project when it was spawned on which I ended up spending 3 years (and foreseebly another 5 years) on and have been wondering why ever since.
* Over the years, I have alternatively defended and opposed this design principle on grounds of - business scalability, over engineering, maintenance costs
* I have effectively used this design decision to generate drastic business viability in terms of: branding A/B, product pruning and A/B testing, 3rd party vendoring of front_end apps, localization and internationalization
* I have seen the technical consequences of this action play out: initial engineering overhead, cost bonus on front_end revamps, modularity and malleability of core business logic, offshore_ability of front_end modules
I aim to keep the talk lighthearted and with brevity in mind, intend to run through the core idea of a split, common rants, the trade-offs and consequences, business scalability and viability that this achieves, technical and maintainability consequences, ActiveResource and it's limitations, and my vision of the ideal JSONified almost_RESTful API approach.
"The Unix programming model has existed for more than 40 years now. Unix programming techniques and principles have transcended programming languages and frameworks du jour.
Also, Ruby was built for unix hacking. Implementing unix system calls in its standard library was the best perlism Ruby adopted.
Learning Unix programming and its idioms will make you a better Ruby programmer. Your ruby programs will be friendly citizens on your *nix server making them easy to administer. You will be able to daemonize your code at will. Your concurrent ruby code will be easy to grok and debug. You will have deeper understanding into the inner working of popular tools like the Resque job scheduler and the Unicorn web server.
This talk is divided into two parts. The first part will be a dive into the basic building block of the unix programming model: processes. We will learn the application of the myriad unix system calls such as kill(2), fork(2), execve(2), pipe(2) and friends to our processes and understand various important idioms. The next part will involve using the knowledge we've gained to build a Ruby preforking server. Our daemon will follow the classical master/worker prefork model wherein the master will fork and monitor its children and use the operating system to load balance work amongst available children. Our daemon will demonstrate classical unix idioms like daemonizing via double fork(2), administration via signals, IPC via signals and pipes, concurrency via fork(2) and many more."
A survey on how to create an API using different libraries
The objective is to show that Ruby has a rich ecosystem for building API servers pick one that you like
Would be covering Grape and Webmachine for REST APIs and Celluloid for RPC Apis
Grape is like Sinatra but focussed on creating a REST API
Webmachine is a port of an Erlang library which treats the HTTP request-respose cycle as a state machine
Not covering rails-api as it is like Rails
Celluloid is a framework for building multithreaded programs Will be using it to build a RPC server
"All of you are aware that rails makes task of web development a lot faster and easier. But here are a couple of questions to each one of you reading this ("?"). Have you been turning a blind eye to the fact that there are people facing situations that don't allow them to use the web application you develop the way you use? ("!"). To begin with, would you like to literally turn a blind eye yourself and understand how web applications could be used without looking at it?
I plan to reveal the concept of Web Accessibility implementation using W3C's WCAG and WAI-ARIA standards. Finally where can this really be put into rails."
Ruby's strengths lie in its ability to blend styles. We all know about OOP and Ruby, but it often leans functional, as well. There's a style of writing programs called 'Functional Reactive Programming' that is extremely useful in the Haskell world, but isn't really used in Ruby at all.
In this talk, Steve will show you FRP, an implementation of it in Ruby, and how to write programs in this style.
In this talk, Aaron will be speaking about upcoming technologies in Ruby on Rails. He will also be speaking about his experience as an Open Source Software developer, and how this relates to the work that he does in Rails. We'll talk about not just software development techniques, but also techniques for developing ourselves.
Underneath the beautiful veneer of our Ruby libraries lies a twisted tangle of writhing guts. Maybe you're curious how the pieces fit together or maybe you're tracking down a bug, either way it's easy to get lost in the blood and bile that ties our code together. In this talk you'll learn how to use simple and sharp Ruby tools to slice into large libraries with surgical precision. We'll do some live hacking on Rails on the stage and cover useful code probing techniques. Turn your impossible bugs into pull requests, and level up your programming skills by Dissecting Ruby with Ruby.
"Most ruby programmers use git in their daily use. I would like to show that git is beyond just commit and pull/push. I want to show how simple, the basic architecture of git is, so that people appreciate and understand it better.
My favorite reference on git is http://git-scm.com/book. I have a hard copy of the book. In fact, after getting inspired from the book, I conducted a training session on git internally in my company using these slides(http://dl.dropbox.com/u/51548306/git-hands-on-2.pptx)
In this session we will see how we can quickly customize git in Ruby and see the insides of Git. I will showcase commands like:
Shows the content of any git object. We will use this to walk through a chain of commits, their trees and blob objects
Reverts your last commit
git make subtree
Does everything required to do a subtree merge in your git repo
The whole presentation will be in terminal and we will explore the .git folder and see what the relevance, of a particular file/folder is.
"With the rising popularity of JRuby and Rails itself allowing concurrent requests by default, it is about time we Ruby programmers learned something about dealing with concurrency.
This talk will focus on explaining thread safety, immutability and concurrency for the Ruby programmer and how to avoid basic pitfalls and write code that works well in a multi-threaded environment. We will also look at using libraries like Akka that provide a nice abstraction over writing multi-threaded code.
Finally, we will also look at how functional programming deals with concurrency in a better manner and what tools does Ruby provide to write more ""functional"" code."
"If you're living in a cave and coding all alone, then you can safely skip this talk !"
With increasing no of companies, teams and developers making Ruby their primary programming language and a literal explosion of open source libraries, we're done with the era of individual hackers and have entered into the era of large, distributed teams of developers building complex systems with Ruby (and Rails). Therefore, it's imperative that both our private and public Ruby code-bases remain consistently readable and maintainable, while they change hands over longer periods of time.
This talk will highlight the importance of following a consistent 'Style' when writing your Ruby and Rails code with lots of examples along with first hand experiences and opinions derived from years of working with Ruby on several small to very large Ruby code-bases. I will also provide useful references and demo tools which could help your team follow the best practices.
My goal is to make your teammates love your code. Or at least, hate it a little less :-)
Rails - a word that stirs programmer's blood. It brought us testing, easy web app building, database abstraction and hundreds of extension gems. Why not take it to another level and discover how to apply some simple OOP techniques in your Rails project? Let's explore concepts like view inheritance, representers and modeling your domain with plain Ruby objects and learn about some refreshing aspects of this framework.
As Rubyists, we depend on open source software to power large portions of our applications. Ruby is free and open source. High-quality frameworks like Rails are free and open source. Gems are ubiquitous.
Yet there are rumblings that Rubyists take more than they give. And open source requires giving.
In this talk, we'll reflect on the immensely positive impact of open source software. We'll also reflect on why it's necessary and worthwhile to give back. Finally, we'll close with some practical suggestions on how to get involved.