In any *nix system, the command line is the standard method of reliably interacting with the system. We are used to the exhaustive, fast and predictable nature of core-utils as well as the shell itself.
Yet most user-space CLI tools leave much to be desired in terms of the user experience design and playing nicely with other CLI tools.
Ruby's powerful abilities of dealing with textual data as well as its ability to directly interface with POSIX libraries and the underlying system itself makes it a great candidate for writing CLI apps.
Drawing from our experiences, we will discuss -- how to model CLI apps in Ruby; how to test CLI apps; standards to follow while accepting commands, arguments and options; making CLI apps fit nicely into the *nix ecosystem; and delighting users with self-documented, easy-to-use, powerful CLI apps.
There is definitely a need of lightweight view components in rails which are nothing but mini controllers and can be better fit to replace partials and filters. This talk is about Why do we need these lightweight components and details of Merb Parts, Rails Parts, Cells & Apotomo. For smaller applications Filter and Partials don't affect that much, but as the application grows, so your code-base too; then you start seeing just too many filters and partials. So we need a mechanism to serve the unrelated sections on main view using independent mini controllers.
Sometime you want to run untrusted code on your server. Our expirements with sandboxing started with the creation of a hosted continuous integration service called Goldberg Pro, and then continued on with RubyMonk, which needed to prevent users from performing potentially dangerous operations in code they submitted via the website.
Here we discuss various system level, language level, and application level techniques that we tried (and we plan to try in the future) to ensure that the user does not bring down the entire system. Some techniques we plan to speak about include LXC (Linux Containers), Chroots, Ruby's SAFE levels, Kernel level limits, SELinux and PTrace.
Some of our learnings are published in the form of the Open Source ruby gem - secure.
Compared to 2 - 3 years back today's eco-system around IT Operations has changed significantly, The definitive responsibility line between infrastructure administrators and developers has been blurring continuously. We have experienced that developers want to experience same level of ease as its publicly available in form of commodity hardware, computing, monitoring, deployment and source control systems. Lots of IT organizations still go through lot of manual process for provisioning, monitoring, analysis, setup and do not take advantage new age tools. We had these issues in our existing environment as well. WE have been managing our servers using new age configuration management tools but thats not sufficient as we did not bring that advantage to our end users. Earlier 2011, we started working on an internal project called DevCloud - with sole aim to provide self serving / signup environments like popular SCM systems or cloud provider or monitoring system.
The reason I have title ""Everything Ruby"" - because we choose to use Ruby every where for Ops world and as well as Dev world. We used puppet to manage our system, mcollective to create work flows. How did we use open source technologies to create our own enterprise private cloud based on OpenStack and OpenVZ/LXC containers or how did we create build system which scales on demand. In this talk I will be showcasing that how did we manage our infrastructure using Puppet and mcollective, how did we create self serving and self sign up environment. What are the challenges for adminsitrators for moving to Ruby and how developers can take advantage of existing OpenSource toolset built around Ruby to explore deployment patterns, scaling on demand, fireup more containers if required - In summary - how can you create a private cloud for your end users which provides end to end development ecosystem on demand.
Most of us, when designing a website or a webapp, design for a specific size and resolution. But today, users access the site from various devices including their laptops, tablets and smart phones. ""Responsive Design"" is a solution to optimize and display content for a variety of screen sizes and resolutions.
Responsive design is quite simple, all you need is a flexible layout grid, flexible images, and CSS media queries. All right, it's not that simple! It's a downright nuisance trying to figure out the precise percentages required for the width of a container, the margins, the padding ... and once you're done, you still need to do it all over again for a different resolution!
But it does not have to be tough. SASS takes care of all the heavy lifting and calculations, so that you can focus on what matters, getting your work done. I'll show you how you can use the new tools introduced in Rails 3.1 to easily implement a responsive design that works across devices (smartphone, tablet and laptop). Along the way, I'll also cover current best practices and explain the reasoning behind them.
Riffing on Michael Fogus's commentary in his post ""All in the family"" (April 6, 2011) where he questions the classification of languages into families, this talk will discuss why those qualities which make Ruby appealing to us might make Clojure even more so. Broadly, I'll discuss language features and idioms in Clojure as they relate to Ruby, contrast of their respective programming environments, and periodically touch on harmonious aspects between the two.
Within the scope of language, Ruby gives the imperative programmer a toe-dip in the vast pool of functional programming. I'll explore the power provided by purely functional language constructs in a language with true higher-order functions as they extend the basic FP-like constructs we already know and love in Ruby. Because Clojure is (optionally) functional it contains unique immutable concurrency constructs I will briefly introduce, compare to Ruby's available concurrency strategies, and then demonstrate as data types imported into a JRuby program. On the more aesthetic side of the equation, I'll compare declarative Ruby programming (which often necessitates metaprogramming) to declarative Clojure code and use that as a segue into a brief overview of Clojure's simple and powerful metaprogramming facilities. This portion will include a conversation regarding the ""when do I turn this Ruby hash into a class?"" dilemma and how that question is answered at the language level by Clojure.
Moving on to programming environments, the conversation will continue with a comparison of CoffeeScript and ClojureScript: a quick overview of their respective implementations and the interesting consequences of ClojureScript's Clojure-subset status (i.e. Clojure macros are available in ClojureScript, shared client/server code, etc.). Second, exploratory programming in IRB vs. the Clojure REPL, with emacs ""live coding"" and ClojureScript REPL-in-the-browser demonstrations. The last topic will cover build and deploy environments, where Rake and Rubygems still have a distinct maturity and usability advantage over the present Clojure alternatives, Leinigen/Cake and Clojars.
Building a SMS based application involves dealing with 3rd party service providers and mobile network operators. As you can imagine, this is time consuming and, given the cost structures in place, expensive. For quick prototypes it isn't worth the hassle. While waiting for your own short code, only hope would keep you together. However, we've seen the tremendous power and reach of SMS - especially for applications around a social theme at ThoughtWorks' Social Impact Program.
EzSMS is our attempt at providing a SMS gateway that can be setup in minutes. Of course it runs on Ruby! All you need is an Android powered phone, a sim-card and data access. Thus it is very easy to prototype your apps. Gone are the days when we, Android owners, would feel alone. With Android activations outpacing births it seems that a hundred billion phones have found homes.
In this talk we'll explore Ruboto and JRuby and quickly explain how to create a simple Android application. We'll explore the internals of our application and then compare Ruboto and other Ruby flavoured mobile app development frameworks. We'll also apologize to Sting for mishearing his song "Message in a bottle" .
In India, VoIP is not commercially legalized. You cannot terminate a VoIP call to a PSTN or mobile! What does that mean for Indian clients? This talk is very relevant for most companies having a support center, a call center or a helpline in India, since infrastructure costs for the traditional way are sky high! This talk is about how we built a hosted Rails solution for SMEs in India to serve out-bound and in-bound calls (including IVR) in India.
We used Asterisk (the software EPABX) and Adhearsion (a Ruby framework) to build a fully-featured framework for supporting VoIP over a PRI line with QoS integrated. This is not only legal but also a commercially cost-effective solution. In this talk we are going to see the live demo of how we can did this. It includes:
Managing Audit logs of each call.
Recording calls, checking the audio logs, finding anomalies.
QoS Resource utilization - we can verify that all the calls were for business, find out calls which were private etc. and validate the performance of a Tele-caller!
Routing of each call to specific extensions of Tele-callers.
Playing sound files for each call function (busy, ringing, dropped)
Click to call from the web browser using twinkle
Today organizations, including SMEs, have multiple internet connections (ISP) for failover capabilities. However, they can use only one of them at a time. We smelt an opportunity here and realized that it would be really helpful and cost effective if we could use all the internet connections simultaneously - balance the load over different connections and also have a failover incase any ISP goes down. This increases the internet bandwidth and provides failover - we get best of both worlds! There are devices which do this but they are limited only to 2 ISPs and are also expensive and picky about the internet connection (only lease lines).
We have built the gem ""isp-unity"" which is a gem for managing multiple heterogeneous (broadband, wifi, lease line, data-card etc) connections from multiple internet providers. This also has advanced features like quality of service (QoS) for scheduling, prioritizing of traffic and managing bandwidth.
How did we do this? The solution exists in linux kernel but it's very hard to configure and manage and requires lot of technical and networking knowledge. We've built a gem that makes all this very easy. Using chef, we plans to deploy this as an ""Enterprise Gateway Solution"" along with other necessary services like proxy, dns, firewall, vpn, ldap etc, replacing or complementing existing appliances/routers.
After running his consultancy for several years and helping many other businesses succeed, Mikel has interesting and practical insights on how to improve your game, whatever it might be, from being a ruby development consultant, running a development shop, or being part of a larger in house development team. This talk will give you ideas and tools on how to increase your value and therefore your pay packet.
This talk describes a series of agent-based modeling simulations with Ruby, where the data is collected to be analysed with a set of R scripts. The simulations model an artificial society in which matters on economic inequality, the environment and evolution are evaluated.
When we started to architect an enterprise micro-blogging solution as part of the internal collaboration platform for a large customer (henceforth referred by dummy name 'CustCollab'), the next immediate question was "Which web application development framework to use?". Simplicity, productivity, ability to deliver high quality of service (QoS), especially performance and scalability (can't ignore that when you're talking about 200,000+ users and expect high concurrency!), and alignment with CustCollab's technology stack were our top criteria for framework selection. After considerable research on state-of-the-art, we zeroed in on 2 frameworks – 1) "Ruby on Rails" (RoR) for its super simplicity and productivity and 2) "Java Enterprise Edition" (JEE) for its obvious "enterprise" class, high QoS and greater alignment with CustCollab's technology stack. But we just couldn't rule out either one, since each framework had been proven to deliver qualities not so proven in the other framework. Naturally, we started dreaming of a framework which can deliver best of both worlds! And in reality, there lived such a framework – 'JRuby on Rails'!
JRuby is the Java implementation of the Ruby programming language. It enables calling Ruby components from Java code and vice versa, thus giving Ruby, and hence RoR, the power of Java Virtual Machine (JVM). In this presentation we focus more on our experience of how JRuby, and hence JRoR, can do a fantastic job of delivering best of RoR and JEE worlds to an enterprise application w.r.t multiple 'quality of service' attributes like scalability (parallel processing, Garbage Collection, compilation, caching, advanced database connection pooling etc.), extensibility, productivity as well as constraints such as 'alignment with existing/preferred technology stack' etc.
With the help of the real world 'CustCollab Micro-blogging' case in point, this presentation highlights the constraints and tradeoffs involved in deploying RoR in a typical large scale enterprise environment such as that of CustCollab, and demonstrates how the distant, isolated worlds of RoR and JEE can synergize with the help of the JRuby bridge to result in a highly productive and scalable enterprise application development platform. Without the psychological comfort of a long list of well known, time tested large JRuby/JRoR implementations or availability of/access to any large scale enterprise JRuby/JRoR case study, within or outside TCS/CustCollab, which could have decisively supported the early adaption of JRuby in CustCollab, our decision to build CustCollab's enterprise micro-blogging platform on JRoR relied on our time tested confidence on Java/JEE, RoR's assurance of simplicity and productivity, and the faith on JRuby core developers' promise of synergizing the Java and Ruby worlds. And we are pleased to say that JRuby fulfilled its promise!
After successful deployment of CustCollab Micro-blogging platform on JRoR, it is time to share our experience on the JRuby capabilities and the new possibilities. This presentation gives access to a real world JRuby case study of a large scale enterprise implementation. We hope it encourages others to adapt JRuby as well as helps other early adapters to support their choice of JRuby. After all, the JRuby improvisation is well capable of delivering the best of both Java and Ruby worlds, and hence deserves greater attention in the enterprise world!
Ruby is a pure object oriented and really a beautiful language to learn and practice. But most of us do not bother to know or care about what happens behind the scene when we write some ruby code. Say creating a simple Array, Hash, class, module or any object. How does this map internally to C code ?
Ruby interpreter is implemented in C and I will talk about the Interpreter API that we as ruby developers should be aware of. The main purpose of the presentation is to understand the efforts and complexity behind the simplicity offered. I would also like to touch upon the difference in implementation of some core data structures in different ruby versions. Having known a part of C language implementation behind Ruby, I would also like to throw some light upon when and why would we need to write some ruby extensions in C.
Who knows in future someone can come up with one more pure object oriented and even more simpler language written on top of Ruby ? Until that time, let's praise the existing backstage artist behind a beautiful Ruby drama !
Push notifications for web applications can change the way web applications behave - Real time updates, chat services, stock alerts, etc. This was achieved earlier using XMPP, polling or long polling is sometimes too tedious, cumbersome or complicated for Do It Yourself approach.
Welcome Websockets, node.js, backbone.js and Redis pubsub for different ways to push notifications. This talk is about how we use all these in Ruby. I will also briefly touch upon Pusher.com - the online API that can do this on production sites without any setup required! A Live demo is in the offing!
The Ruby language has a very robust and high-performance implementation on the JVM - JRuby. While JRuby by itself brings a lot of (implicit) benefits of the JVM to the Ruby world, the rest-of-the-world isn't without its share of excitement!
Scala, Clojure, Mirah et al have a host of features which make them very expressive and powerful for certain classes of problems. For example, type-safety combined with the compilation phase bring in performance improvements. Or immutability allows for easy-to-reason-about concurrent implementations. Lazy evaluation allows for easier expression and solution of still another class of problems. And for situations requiring you to handle asynchronous situations, there are Actor libraries.
With JRuby, there are two ways to leverage the benefits of these languages. Since everything boils down to classes (and typically, JAR-libraries), one can directly call into these libra
The Ruby community is notable for it's whole-hearted adoption of Agile and XP, especially testing; testing is now a standard practice on the vast majority of Ruby codebases. TDD is commonly recommended because:
It makes for good design, helping one create well encapsulated, decoupled production code
It provides documentation for production code
It minimizes regression issues and makes bugs easy to diagnose and fix
What is rarely discussed is the fact that a test driven codebase exhibits patterns and smells in test code just like it does in its domain code. These test smells are as useful in identifying quality issues as are, say, violation of the law of Demeter in domain code. This talk will cover some of the common patterns and smells that a test driven codebase exhibits and their implications.
Some of the patterns/smells we will cover include:
The long test file
The test with too many assertions
The test that cannot fail
The test that has logic
The implementation bound test
The test with arcane terminology
The test that verifies program flow
The slow test
The test that has complex setup
The test that shows high churn
The test file that shows high churn
We all know the strengths of JRuby. It utilizes the scalability of JVM and provides real OS threads to Ruby. However, there are very few application servers that marry the expressiveness of JRuby with the power of Java. Torquebox is an application server which build upon the JBoss Server and provides enterprise features in Ruby.
In this session we will demonstrate a working application on Torquebox, and also demonstrate Torquebox features such as long running services, messaging and caching with live examples. We believe, these features offer the missing link between Ruby and enterprise integration. We will also offer some insight into the scalability / clustering features of Torquebox.
I am planning to talk on this topic because this topic is very useful for most us and I will basically talk from my experience of coding for Large ruby on rails project, which has approx. 35 engineers working at the code base same time.
My plan is to talk about managing large scale projects and test suite of a large project and how to not let the technical debt run too high.Managing large scale projects code quality, scalability and running Test Suite of a large Rails project can be a challenge. Getting metrics, running selenium with cucumber can eat up lot of time.
I cover some of the below topics,
How to maintain the code quality between the developers on large scale projects
Maintaining the test suite , etc
We also cover below libraries
Borg: distributed Test Suite runner for Rails, using Eventmachine and Redis) which is developed by me
New Relic: a performance management system
Meta programming can be disastrous. While it is cleaner in many cases, it must be used with prudence. This talk will cover the issues that arise from irresponsible meta-programming like overuse of method_missing, ""monkey patching"", and eval.
'method_missing' can be used to create methods on the fly. What people don't realize is that method_missing is called when you typed in an error, and you may define error handling code for this. While it may be easy to create dynamic methods this way, those methods are never actually defined and therefore cannot be documented properly. Instead I will explain the use of define_method which is much more suitable in 80% of cases.
Monkey Patching, or adding methods to an existing class, is also dangerous. Being able to override functions like ""freeze"" is extremely dangerous. Instead I suggest a better way of overriding methods on single objects instead of classes.
Join me on a meta-programming safari where we will learn responsible meta-programming
We want that our Mobile application should be high performing, the development should be rapid and have good usability. There are many mobile application framework available but there is no framework which is best, and we can blindly start working with it.
There is always a confusion at the designing and selecting a framework. In this talk we will discuss which framework to choose. We will discuss different scenarios and the best solution to choose from, this can be on the basis of current architecture, requirements, feasibility and time. We will also discuss strength, weakness, issued faced during development and over score.
The technology which we discuss are Rhomobile, Titanium,Phonegap and Native Frameworks.