THIS CONFERENCE WAS NOT RECORDED BY CONFREAKS
Over the past few years, Rubyists have started to rely on implementations like JRuby and Rubinius to provide them with true thread-level concurrency. But the community and the libraries available are still growing into this new world. This talk will survey techniques and strategies for writing libraries and applications that are thread-safe using simple coding patterns and readily-available libraries. The future of Ruby is concurrent...be ready for it.
When you talk to most people about Rails performance the conversation usually turns to concurrency. How can my Rails app handle 60 simultanious requests per second? How do I webscale?
Although the topic of concurrency is important, we won't be focusing on that during this talk. We want to focus on end user speed.
For every extra second your application takes to load your conversion rates will drop by an average of 7%. While most people start tweaking their backends to squeeze every extra ms in response time, more often than not (80-90%) of the actual time spent loading your application is on the front end and the network stack. This is where you should start.
We will cover a range of techniques and provide benchmarks along the way to show how much performance you can expect from each step along the way. We'll also cover some backend performance tuning as well.
Here's some of the topics we'll cover:
How to accurately benchmark performance
Asyncronously loading assets
Reducing requests per page
Rails http streaming (chunked responses)
What is SPDY - and how to use it
What CDN is right for your app?
Server location and why it matters
Domain Driven Design is a software development process that focuses on the finding a common language for the involved parties. This language and the resulting models are taken from the domain rather than the technical details of the implementation. The goal is to improve the communication between customers, developers and all other involved groups. Even if Eric Evan's book about this topic was written almost ten years ago, this topic remains important because a lot of projects fail for communication reasons.
Relational databases have their own language and influence the design of software into a direction further away from the Domain: Entities have to be created for the sole purpose of adhering to best practices of relational database. Two kinds of NoSQL databases are changing that: Document stores and graph databases. In a document store you can model a contains relation in a more natural way and thereby express if this entity can exist outside of its surrounding entity. A graph database allows you to model relationships between entities in a straight forward way that can be expressed in the language of the domain.
I want to look at the way a multi model database that combines a document store and a graph database can help you model your problems in a way that is understandable for all parties involved.
Ruby and frameworks based on that are not just for scripting and web development. Ruby can be used to build telephony/voice apps which, on one hand, can talk to humans over regular phone calls and on the other, interact with any external service (including your Rails app). You can imagine how powerful this can be to build voice enabled apps with nothing more than your existing Ruby skills. If you ever wondered how they build all the IVR systems, it’s time to stop wondering and start building one, right now !
In this talk, I will introduce the audience to an open source framework called Adhearsion which is written in pure Ruby and allows you, the Ruby developer to integrate with telephony services like FreeSWITCH, Asterisk etc and also your existing Ruby/Rails app to build great, voice enabled services with very little effort and learning curve.
There were around 120000 ruby developers in the world 4 years ago. And the rate at which IT industry(particularly ruby and rails community) had grown in the past 4 years, it is safe to assume that this number would be much much higher, but lets proceed assuming 120000 ruby developers.As of 27-dec-2013 17:15 IST, there are 68,036 ruby gems available for download. So, the average number of ruby gem per developer comes out to be 0.57
Lets accept it, this is not a very impressive figure. So,what has stopped us from building gems and helping the ruby community grow? It could be one of the following reasons:-
1.) Its like sending a space ship to Mars - complicated process
2.) I can't do that, it's only for experts - calibre
3.) Who has the time? I work 24x7 - busy
4.) There are people already doing it, why should I work hard for it and open source it. I am not that crazy - lazy
5.) Is it really needed, it's so trivial? - useless
During the course of the talk, I am going to explain how ridiculously easy it is to build and publish a gem, what is the proper way of debugging a gem and how does building open-source software helps in your career growth? After this talk, I hope we all will try to improve upon the figure of 0.57 !!
When it comes to delivering a fast, near real-time UX, the traditional AJAX techniques have several short-comings. Polling creates additional HTTP overhead, is prone to latency issues and long polling is at best a hack. And don't we all love hate hacks! With Server Sent Events, you can push data to the app whenever it's available, WebSockets are in fact bi-directional, full-duplex. With this understanding, we will look at Server-Sent Events, WebSockets & WebRTC from a browser and server perspective. We will also look at all pieces we need to fit in, to get the big picture.
Concepts and app Integration with:
Server Sent Events
Related Open Source projects
Further reading, and opportunities to contribute and create
Learn the involved concepts
See relevant code from popular open source projects
Know where to look for further reading
This talk covers following SOLID design principles in Ruby with live code examples.
Single responsibility principle: an object should have only a single responsibility.
Open/closed principle: an object should be open for extension, but closed for modification.
Liskov substitution principle: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
Interface segregation principle: many client specific interfaces are better than one general purpose interface.
Dependency inversion principle: depend upon abstractions, do not depend upon concretions Talk will have live code example which will be evolved step by step to use all SOLID principles.
This talk will also answer the question why just following these principles will make your code more clean readable, extensible and better. Also make you better programmer.
Talk would take around 30-40 minutes. Talk would be definitely useful for both noob and advanced Ruby programmers.
There are thousands of local Ruby groups worldwide. Sadly, many suffer along, become stagnant, some even die off. How can you make your local Ruby Group better and in so doing, improve the global Ruby Community?
This talk focuses on the human side of getting a group together and making it successful so the members, as a group can contribute to the larger community. It is a universally useful guide to improving all parts of the ruby community, starting on a local level.
Ruby 2.1 has introduced a lot of internal changes and tools that make it easy to build profilers using those tools.
In this talk, I will be talking about:
Detailed explanation of the internal changes brought upon in Ruby 2.1 particularly about the instrumentation provided in the latest version.
How other projects use these low-level features to develop high-level libraries. example: MiniProfiler, StackProf.
What information can one get out of using one of these tools.
Build a basic profiler using these tools.
Have you ever thought about what would happen if you lost your eyesight or your hearing? The world in general is a hostile place for people with disabilities. Those of us who do not have to deal with disabilities rarely think about what it must be like.
As developers, isn't one of our jobs making the world a better place, and doesn't that especially include making it better for those who have it the hardest?
The Web is powerful because anyone and everyone can access it and it can offer disabled users access to information and interaction that was never available before. And yet, because we assume that it must be difficult, we don't bother.
But accessibility doesn't have to be tough, it doesn't require learning a new set of tools. We can use the same tools that we already use, we just need to use them correctly and follow a few simple guidelines. And the best part, making your site accessible also improves usability for everybody else!
We will take a look at
accessibility challenges when building dynamic web applications with Ruby on Rails (3 minute intro)
understanding how usability is affected by disabilities (3 minutes)
understand how Assistive tools work (3 minutes)
and how we can use the best tools in HTML5, JS and in Rails to improve accessibility (22 minutes)
The focus of this talk will be on taking a Ruby on Rails application with extensive AJAX, and making it accessible. This will be a practical, code driven talk.
Rails is known as a productive platform to serve your Ruby application, and at the same time, Rails is a very well written piece of Ruby code. The whole framework is written in the same language as the one you use to compose your apps, and everything is open-sourced. There's no secret. It's just Ruby.
This talk encourages you to step into the Rails code base. Through this talk, you probably will get to know:
How Rails boots
How Rails loads itself, libraries, and your application
How Rails handles requests
How Rails interacts with databases
How to read Rails
How to debug Rails
How to patch Rails
How to extend Rails
After attending this talk, you will find that the framework is no more a black box for you.
Rails was written in 2004, a time when RDBMS ruled the world and Pierce Brosnan was still James Bond! Today there's a plethora of NoSQL solutions gaining traction all around the world. Neo4J is the world's leading graph database. Written in Java, it serves some of the world's top companies and startups being 1000x faster than MySQL when it comes to deep joins. A graph database allows you to model your domain knowledge naturally as nodes connected by relationships, both of which can have an arbitrary number of properties and without the headaches of normalization and other RDBMS idiosyncrasies. ActiveGraph is a fast, minimal Ruby ORM for Neo4J written on top of Neon - slim ruby binding for Neo4J. ActiveGraph integrates with Rails bringing everything you know and love about ActiveRecord on board. I'll tell you how you can easily swap out ActiveRecord and slid in ActiveGraph without disrupting your applications and almost instantly gaining performance, productivity and scalability by over several times and I'll tell you why you should embrace and love graphs, maybe even marry them! We as a community need to build better tools so more and more people can embrace this new approach and technology for data modelling.
Natural Language Processing (NLP) is the art and science of making sense of user-generated data. It is a combination of state-of-the-art computer science techniques and linguistics. Being able to analyze plain text data allows us to gain a lot of insights. Popular NLP tasks are text summarization, keyword extraction or automatic extraction of the author's opinion from a text. In the age of social media, only NLP provides solutions to analyze what users are really care about. Companies such as Google or Facebook invest millions in NLP solutions to harvest information from all the data they have been gathering over the years.
In this talk, I will present you a real-world NLP problem. We will discuss this problem from both, the linguistic and the computer science perspective. Throughout the talk, we will develop a processing pipeline to efficiently solve this problem in an automated fashion. An NLP pipeline usually consists of multiple components, each solving one aspect of the problem and presenting its own challenges. Among other things, you will learn how to tackle the following essential NLP problems using JRuby and OpenNLP:
Part-of-speech tagging, and
Named entity recognition.
The revelations of Edward snowden has shown how deep the states are stooping to get hold of your data, People who did not care how your data is stored online in your Saas applications are now asking questions, and tough ones. The talk will be about what to do to protect your data from Govt and in that make the application less easy to hack for other people as well.
The structure of the talk is following
How the current default rails setup on the cloud is not enough.
Why is it important?
How to secure the shell of the application
Why just securing the shell of the application
Auditing things that might be leaking information that other people
Mysql databases/ Third part calls/ Insecure gems/ Insecure filesystems
Infrastructure choices. Where to host, what to look for in hosting providers.
How to implement a system that provides a push button secure me plan.
Caveats and Fine print.
What this is not
I am not talking about making the application hack proof( there will be some authentication security stuff)
I am not talking about running a security audit of the application( there will some of the how to audit bit)
I am not talking about cryptography and Security fundamentals
As rubyist, what has been increasingly difficult is to find out where our code went wrong. As programmers there are studies which indicate that we spent 60% of our time debugging and trying to find an answer to these questions. That's like "more than half of the time". What if we could reduce this wasted time? After all, every penny (second) saved it a penny (second) earned.
Fortunately, we do have tools which have made it possible to make it not only fast and easy but fun too. One such tool is PRY. The stats show that PRY has been downloaded million times (~4.8M) already. So we think it makes a lot of sense to explore why people are using it. Still there still is a larger group of rubyists out there who probably are not using PRY; not because they don't want to but because either they do not know that such a tool exists or because they don't know what ALL it can do to.
In this talk, we will be talking and doing some hands on with PRY and its plugins to showcase how we can speed up development by reducing the debugging time.
Bundler is a core part of the Ruby ecosystem, It takes away the pain of managing your project dependencies manually. Programmers just need to call "bundle install" (or just bundle) and all their problems regarding which gems versions to install is taken care by Bundler.
This talk will discuss the internals of Bundler AKA what really happens when you call "bundle install" on your project. I will discuss how "bundle install" used to work mainly the network call to Bundler api, the dependency resolution and installation of gems.
I will also discuss on how "bundle install" is being improved in numerous ways. Mainly,
The new index format which caches more information, makes fewer requests.
The improved dependency resolution algorithm.
Parallel gem installations which improves gem installation by 40-60%.
The Metasploit Framework (MSF) happens to be the largest ruby project and suprisingly enough, not many rubyists seem to know about this project, but it means the world to those who use this framework - the Penetration Testers.
This session would cover a component of MSF called Meterpreter. Meterpreter is an advanced payload which uses DLL injection to hook into an existing live process on the remote system. It provides a remote shell which can be used to run scripted attacks or to gather information from the victim host.
With some simple ruby code and the shell provided by meterpreter, I shall demonstrate gathering restricted information from a victim host post-exploitation.
Note: This session could be thought of as a follow-up of my previous session titled "Pelting Rubies" at RubyConf India 2013.
We will first talk about the kinds of metrics which we might be interested in and why
Then we will talk about how we can generate some of these metrics ourself.
There are existing tools out there, we will not talk about them directly
But we will cover how these tools work internally.
we want to know:
1. how to parse ruby code. (ruby_parser or parser)
2. how to make sense of the parsed code (sexp_processor)
3. visualization. how to make sense of all these metrics you have collected.
4. how and what metrics can we generate from running production code. eg. dead code analysis, GC runs, method hit counters etc
Why this talk?
With Rubinius and JRuby making good progress, we do have truly parallel Ruby implementations
Ruby adoption is increasing in more complex applications where performance is critical
Traditional Ruby application architecture involves multiple processes to achieve parallelism. In this talk we will explore other architecture options using Rubinius and JRuby to build truly parallel applications. Topics covered will include.
Moving from Processes to Threads
Power of JRuby