RubyConf Roundup: Day Two

I just finished the second day of RubyConf 2012 in Denver.  There were more great talks and a ton of information to digest!  Check out the following for synopses of some of the talks I attended.


RUBY VS THE WORLD
Matt Aimonetti
Slides

Here, Matt gave us a tour of three modern programming languages: Go, Clojure and Scala.  Matt discussed strengths, weaknesses and applications of each, and described them in relation to Ruby.

Matt compared programming languages to human languages, in that the way languages are designed affects our worldview and the way we solve problems.

Bad ways of evaluating a language:

1. Looking at "hello world" only
2. Looking purely at syntax.  This might give you a feeling about the language or its aesthetic, but no deep insight.

Good ways of evaluating a language:

1. Looking at the language's philosophy
2. Looking at use cases for which the language was designed
3. Trying to look at the language with new eyes, like it's the first language you learned

GO:
Compiled, structural, typed, object-oriented, and functional.
Learning curve: normal.
Has the concept of a pointer, so C experience helps.

Matt showed a Go use-case with concurrency, walking through a short program to fetch three URLs at once.

Matt created a function that fetches URLs and created a channel (a broker for concurrent tasks) to do the work.  He then created a "go" function, which runs asynchronously and fetches the URLs.  Finally, Matt implemented a for loop where you (a) ask if there's anything ready in the channel, (b) get it, if it's there, and (c) add it to an array.

Philosophy: Go tries to be the new C. It's not a big language and it's easy to remember.

What's bad about it?  It can be too low level, it doesn't have great garbage collection, and it has "weird" conventions at times.

What's good about it? It has simple specs, modern standard libraries, great concurrency support, very fast compilation, flexible code organization, a simpler take on OO, functional programming features, good error handling, and good documentation.

CLOJURE:
Clojure is a compiled, dynamically typed, functional, mostly object-oriented language.

Learning curve: difficult.

One use case: data processing.

Philosophy: Clojure is "the pragmatic scheme." Scheme and Lisp are great, so Clojure adds more object-oriented features to make it more useful in the real world.

What's bad?  It's not very simple, not always consistent, one needs to know lots of functions and macros, it's not really web-focused, it can cause a "brain stack overflow," it can be a difficult mental context switch, and it has cryptic error stacks. (whew!)

What's good?  Matt didn't go into this in great detail.  He didn't really sell this one.

SCALA:
It's the closest of these languages to Ruby, according to Matt.  It's both OO and functional. It's compiled and can have either static, inferred or dynamic types.  Learning curve is moderately difficult.

One good use case, according to Matt, was for Service Oriented Architecture, or whenever you need a more "enterprisey" Ruby.

Scala has lots of familiar elements if you're coming from a Ruby background.  It has enumerable objects, anonymous methods, default method parameters, metaprogramming features like method_missing, duck typing, mixins, and a focus on testing.


Philosphy:  Scala is like Ruby, minus the scripting, plus static typing.  Matt called it "the academic version of Ruby."


What's good?  Scala has a focus on tests, inner methods, lazy evals and streams, a great garbage collector, good performance, and good tool/IDE support.  It's it's easy to get started, has inferred types, uses flexible functional approach, includes modern concerns like parallelism and pattern matching, and has a very active community.

What's bad?  According to Matt, Scala has a huge surface, a stiff learning curve, "abused" OO syntax, and poor documentation.

OVERALL:
How did this language exploration affect how Matt writes Ruby?  Matt noted that Ruby is as functional as it is object-oriented,  and these two paradigms are complementary.  In Matt's view, functional programming should be used to extend your program with new operations.  Object-oriented programming should be used when the data in your program evolves.


HOW TO BUILD, USE AND GROW INTERNAL TOOLS
Keavy McMinn
Slides

Keavy, who works in a large distributed team at Github, discussed (a) use-cases for developing internal tools and (b) best practices for using internal tools.

Central theme: Create the culture you want at your organization through internal tools.

Most people use and abuse internal tools, like using email threads for "everything."

Keavy discussed three use-cases for internal tools, each brought about by someone's "pain."

PAIN #1:
"I don't know who is working on what."

Keavy showed how Github built a simple social tool where you can say what you're working on.  "I am next shipping X."

Keavy observed that this visibility makes developers more motivated to do a great job on projects, and added a sort of "friendly competition" dimension to communication.  "We see awesome get shipped, so we want to ship awesome too."

PAIN #2:
"I feel disconnected because I am remote."

I was surprised to see that about half of the audience works remotely when Keavy asked!


Keavy said that Github deals with this, in part, by not "abusing" tools that require everyone to be in the same place at the same time, like physical meetings and phone calls.  Github employees are spread out across many different time zones, so coordinated meetings can be tough.

On the other hand, one audience member noted that these distributed practices (email, pull requests, tickets, social feeds) can be much more time-consuming than coordinated meetings, because of the long feedback cycle.


Github has also implemented "fun" tools to help folks feel connected.  They have a company music feed where everyone can listen to the same music, and everyone can rate/select songs that are played.  Employees can even change the volume!

Keavy noted that digital communication can be tough. When the message is neutral, it's usually perceived as negative over the Internet.  Positive language is generally much more powerful.

Keavy mentions: A big challenge with distributed teams is that people have a tendency to "hide" until their work is  complete and "shiny," and then show their work after.  This is usually bad for both company culture and project momentum.  Committing early and often works much better.

Keavy calls Github's paradigm "cooperation without coordination," as most work is asynchronous.

PAIN #3:
"I don't like {something that's being done in the company}."

Keavy said that teams should always be giving and receiving feedback on internal processes.  ALWAYS.  Don't just "go with the flow" in terms of internal tools/processes; think of ways to constantly improve them.

Github has an "ideas" feed, where employees are always suggesting ways to work better together.  They receive over 30 ideas per month and even more comments on those ideas.

If there's a tool you're using for everything, that's a red flag.  It's hard to opt out of long email threads, but not as hard to opt out of a ticket you're watching, a pull request, or a more specific tool.


ARDUINO THE RUBY WAY
Austin Vance
Slides

Austin gave an overview of his experiences with Arduino, and discussed the use of Ruby to control Arduino devices.

Arduinos ship with a basic IDE and a "stock" C++-based DSL.  It lets you compile and verify code.

Austin showed us RAD, a system for Ruby Arduino Development.  Debugging is hard in RAD, and it's not under active development, so he avoided this.

Austin noted that Node.js works really well with Arduino, since Arduino devices are asynchronous as well as Node.js.

He also showed us Duino, a C++ library you put on the Arduino that acts as a service.  You can use node.js to talk to service, just like any web service, and abstract away some of the hardware details. Austin wanted to write Ruby, though, so he created a Ruby library to do what Duino did.

Goals of this library: Fully tested, easy to extend, great documentation, zero startup time, fun.

Architecture:
There's a "Board" class that's the programmatic representation of the Arduino.  It has pins, it has I/O, it knows how to talk to and read things. One thing it doesn't do is communication, though.

The "TxRx" (domain-specific term) class handles sending and receiving messages.  TxRx functionality is injected into the board, so you can write an adapter for Wifi or Bluetooth  as long as you adhere to same public interface.

There's a "Components" module that sets up pins, makes sure the board is there, etc.

The architecture involves passing functions around, as procs, so the system can respond to future events like button presses.  You can pass event-specific data into the procs, like the magnitude (distance) of a proximity sensor event.

Finally, Austin hooked all of this up to a Sinatra app, and used it to control his Arduino-based t-shirt cannon.  He let the audience interact with the app through their laptops, fire t-shirts, and much fun ensued!


INSIDE RUBYMOTION
Rich Kilmer
[no slides yet]

Rich showed us RubyMotion, a system that lets us write Ruby Code, compile it to Objective-C, create iOS apps, and ship them.

EverClip, for example, is built completely in RubyMotion.  It makes use of 3rd-party objective-C libraries, won an award, and is for sale in the app store.  Upshot: It is possible to make money with RubyMotion.

RubyMotion is like Ruby, but statically compiled.  It features a terminal-based toolchain, and you can keep using your favorite editor.   You can use any Ruby feature, including metaprogramming ones, except eval.

Rich showed us how much more complex and verbose an Objective-C "hello world" app is compared to Ruby.  He then showed how we can actually write OpenGL code in Ruby, using C constants and C libraries directly.

RubyMotion starts with Ruby source code, creates an abstract syntax tree, as usual, and then compiles it down into LLVM portable assembly language.  Objective C classes map one-to-one with Ruby classes.

Rich showed us how we can debug in RubyMotion, do the typical "breakpoint" stuff, debug, and see where we are in the Ruby code.  He then showed us how testing support is much more robust in RubyMotion than in Objective-C.

Interestingly, Rich surveyed the audience and found that almost none of the Objective-C developers wrote automated tests for their apps!

Finally, Rich showed us the "console," which looks like ERB, but dynamically compiles your Ruby code, sends it to the iOS emulator, and returns the result.  In other words, you can fetch a button object, change the text, and see it on the simulator in real time!  Lots of "oohs" and "aahs" from the audience there.

When taking audience questions, Rich couldn't come up with a single use-case where vanilla iOS development would be preferable to RubyMotion.  I'm a bit skeptical about that, as mobile developers always talk about how they need to "go native," but I enjoyed this talk nonetheless!

Questions?  Comments?  Let me know!  Read more about all the talks here.

RubyConf Roundup: Day One

I just arrived in Denver and finished up day one of the always-excellent RubyConf.  I met a many smart engineers and saw some really informative presentations!  Here are some synopses of the talks I attended.


MATZ'S KEYNOTE
Yukihiro Matsumoto
Slides

I always enjoy Matz's keynote talks.  As the face of the Ruby programming language, Matz has a great "zen" approach to talks, where he speaks generally about programming for fun, personal fulfillment, and making the world a better place.

Matz talked a lot about finding motivation for projects, how motivation is hard to come by, and how it's the single most important factor in doing a good job on something.

Matz asked, "how do you become a language designer?"  Most folks in the audience had not designed or implemented a programming language.  Matz noted that programming in general is very similar to language design:  As a programmer, you design code, APIs, and interfaces.  "Programming is designing DSLs."

Matz noted that the world is full of bad designs.  He showed how he "hacked" shoelaces by super-gluing them so they wouldn't become untied.

Matz's approach to writing software, according to this talk, is to get inspired and "make it happen."

Matz then talked more specifically about the Ruby language and reflected on the scope of the project.  Starting as a pet project in 1993 (almost 20 years ago!),  it became hugely popular and Matz couldn't really process it while it was happening.

Matz noted that Ruby 2.0 will be "faster, more reliable, more tested, and more fun to use."  He gave a quick overview of Ruby 2.0's features but didn't go into detail (see below for that presentation).

Matz ended the talk by telling programmers to "be motivated, get coding, reinvent the wheel, and make the world better."


ABSTRACTING FEATURES INTO CUSTOM REVERSE PROXIES
Nick Muerdter
Slides

In this presentation, Nick talked about using evented architecture to implement reverse proxies via (a) rack-reverse-proxy and (b) EventMachine Proxy.

Performance:
rack-reverse proxy (RRP) adds much more overhead than EM Proxy for big data requests.  RRP buffers everything in memory, and that is the primary performance bottleneck in the system.

EM proxy deals with data in chunks, and as such, it's much more flexible when dealing with large amounts of data.  Nick noted that EM proxy is more flexible overall.

Some use cases for reverse proxies like these:

• error handling
• web page manipulation
• inserting a standard JS analytics statement in all responses
• implementing email servers

Content-length: You need to deal with content-length if you're modifying the response for client, and must keep it in sync with the actual content.

Gzip responses can also be problematic for reverse proxies.  You need to buffer the entire response to serve the gzipped content, since you can't break it up into chunks.

Nick noted that there's currently a "web services bonanza" in the federal government.  There's a big push toward interoperability, and many organizations are publishing new web services.

Nick's central theme: Look at different ways to architect your software.  Now that you can implement reverse proxies in Ruby, it's easier for them to perform advanced functionality like connecting to the database, communicating with APIs, etc.


SERVICE ORIENTED ARCHITECTURE AT SQUARE
Chris Hunt
Slides

Chris works at square, which lets anyone process payments easily.  They've made apps for Android and iOS, and have a central Rails API.  Creating a Service Oriented Architecture (SOA) was something their team had to do and had to become better at.

The Square team kept adding features to their product over time, have hundreds of model/controller files in their central Rails app, and have hundreds of thousands of lines of code.  They needed SOA, a better way to scale their growing architecture.

The SOA Creed, like that of UNIX, is to do one thing and do it well.  Usually, the idea is to make a new service for a group of new, related features, unless they relate strongly to existing features.

All of Square's SOA components run on JVM platforms (Java, JRuby, Jython, Closure, etc.).  They can deploy everything via Java, and this normalization is a big win for them.  New components simply require the JVM, and they can run on any server in any data center.

Chris walked us through a "boilerplate" service, which set up documentation, testing, code quality metrics and more for new services.

Chris showed how his team uses FDoc to enforce documentation across services.

A big inspiration for Chris was the book Growing Object-Oriented Software, Guided by Tests.

To test, Chris' team makes fake version the other services, usually in Sinatra, so he only needs to describe the service endpoint.  He uses the tool foreman to boot up fake services and use them for development and test environments.

Square uses cane to enforce code quality standards across different teams and services.  If code quality or style isn't up to snuff, it actually breaks the build (awesome!).

Chris uses cubism.js to visualize time series data from errors and other activity.  He uses the enterprise tool splunk to manage log files and track, say, a payment id, as it goes through different services

Security:  Square uses SSL certificates for mutual authentication between services, as opposed to one-way SSL on websites most of us are familiar with.  Every service has an SSL certificate, and each one has an organizational unit (service name).  This lets their team ensure that a service is authorized for a given action, implemented as a before_filter in Rails controllers.


RUBY 2.0 (ON RAILS)
Akira Matsuda
Slides

Ruby 2.0 is scheduled for release in February 2013.  Akira, on the Ruby core team, walked through the new features.  Lots of this information is available elsewhere, so I'm going to punt on some of this stuff.

Ruby 2.0 is 100% compatible with current stable version of Ruby (o rly?).  The feature freeze was one week ago.

1. Module#refine and Kernel#using let programmers "monkey patch" code while keeping the scope constrained to the redefining module.  This makes monkey patches much safer and doesn't pollute the global scope. Kernel#using lets you apply that refinement to a specific scope.  Akira went through some example by refactoring ActiveRecord and ActiveSupport to use refinements.  Read more here.
2. Module#Prepend lets programmers include functionality from modules into a class, similar to include, but now methods from the module take precedence over those in the class.  This is a much safer alternative to alias_method_chain, found in Rails, and other monkey patching techniques.  Read more here.
3. Enumerable#lazy lets you perform actions on enumerable objects without evaluating the entire collection.  Akira showed how we could do some processing/evaluation on a range from 1 to infinity, or on a list of all dates, while completing in a reasonable amount of time. Read more here.  
4. Keyword args.  In Ruby 2.0, you can easily accept hash keyword arguments with default values.  This lets you specify and validate hash keyword arguments and provides a cleaner way to deal with multiple hash parameters (like options and html_options in Rails' button_to, for example).  Read more here.

ZERO DOWNTIME DEPLOYS MADE EASY
Matt Duncan
[no slides yet]

Matt Duncan went over some good techniques for reducing downtime during web application deployment.

Matt suggested developers look at a traffic graph and decide what trade-offs need to be made for reducing deployment downtime.  Can you run a migration when traffic is low, if it won't affect many users?  Can you throw money at a faster database to mitigate the situation.

Matt recommended you separate code update deployments from database migrations, the latter of which he calls a "database deploy."  He suggested folks try:

1. Having an initial migration, just to add new fields, as that introduces little to no downtime
2. Have a separate rake task to update records as needed, outside of the migration-induced database lock

He suggested developers use "CREATE INDEX CONCURRENTLY" a Postgres feature, to create DB indexes without causing downtime.  (Not using Postgres?  You're out of luck!)

When updating job queue code, he warned developers that "queues are almost never empty," and to take that into account during deployments.

Matt recommended that developers set version numbers on all external services and make it easy to "roll back" external services in case of failure or errors during deployment.

Matt noted that in many cases, developers can disable a feature while running an complex/expensive deployment to update it.  Say you need to deploy an update to search backend like SOLR, for example.  Perhaps you can (a) deploy a change to hide the search bar in your application, (b) update the search service nicely,  and (c) add the search bar back.  This seemed a bit crazy to me and would require lots of extra effort.

Matt recommended that folks check out rollout, a library to gradually roll out services to a certain percentage of users at a time.


REFACTORING FROM GOOD TO GREAT
Ben Orenstein
[no slides]

Ben walked us though several examples of refactoring Ruby code.  Ben showed some tell-tale "code smells" and applied advanced object-oriented techniques to refactor the code.  IMO, talks like this really show the maturation of the Ruby ecosystem over the past few years.

Ben demonstrated:

1. factoring out functionality into private methods so developers didn't have to read it right away
2. recognizing when classes have "feature envy," or lots of functionality related to a different class
3. using a single concept (like a range) to represent multiple entities (like a start and end date)
4. reducing coupling between systems
5. creating a situation-specific null object so his code could "tell, not ask"
6. depending on abstractions for related functionality, making it easier to mock and test

Ben also showed us examples of good times to refactor:

1. All the time :)
2. When you have "god objects," or objects that try to do everything.  In Rails apps, this is usually (a) the user model and (b) the central object related to your specific app (like "Order" for e-commerce apps).
3. When you see high-churn files, or files that change often.
4. When you have lots of bugs surrounding a specific feature. 

BUILDING MODULAR, SCALABLE WEB APPS? OF CORS!
Michael Bleigh
Slides

Michael talked about CORS, or Cross-origin resource sharing.  Background information available here.

CORS:  As long as other domains implement the protocol, users on one server can get resources from other servers.  Often, this means we can make an ajax call to a different server.

"Like most good things," this doesn't work in IE < 10.

With CORS, your site has access control headers that show whether a given domain is allowed to make ajax requests.  You can specify acceptable domains, or use a wildcard to allow all domains.

There's an additional "options preflight request," triggered when the request is not a simple GET or  has custom headers.  This helps to prevent cross-site scripting and the like.  The preflight response shows access-control-allow-origin or access-control-allow-methods headers, telling the client whether it's allowed to make the request.

CORS disadvantages:

1. Initial complexity
2. Cross-service communication
3. Lack of framework

Michael recommended that Rubyists check out the rack-cors gem.

Michael argues that using CORS for public APIS is a HUGE win, because it's a lower barrier to entry for external developers.  You don't need a server to make requests to your API; it can all happen in the browser.  A developer could implement a locally-hosted HTML file that makes requests your API.  In other words, it's roughly the same burden on you, but much less on third-party developers.

Michael also walked through some security concerns in terms of handling authentication for public CORS-based APIs.  For example, you can't count on secrets since everything is exposed on the front end, and you still want to identify the requesting application.  Github's solution is to only allow CORS requests from domains of registered applications.


Questions?  Comments?  Let me know!  Read more about all the talks here.

Integration Testing in Python

Hey folks!  Here's a presentation I did for the Providence Royal Python Society meetup this winter.  It covers some of the currently-available integration testing tools for Python, as well as my own project, easy-integration.

Integration Testing in Python

View more presentations from Panoptic Development, Inc.

Web App Security: Django and the OWASP Top 10

Security threat: Neutralized.

At my company, Panoptic Development, we've built several applications for the healthcare industry.  Since we often deal with sensitive patient medical data, web application security is a huge concern.  Enter the OWASP Top 10, a collection of best practices for web application security.

What's OWASP?
From Wikipedia:

The Open Web Application Security Project (OWASP) is an open-source application security project. The OWASP community includes corporations, educational organizations, and individuals from around the world. This community works to create freely-available articles, methodologies, documentation, tools, and technologies. 

What's the Top 10?
From the OWASP Wiki:

The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. Versions of the 2007 were translated into English, French, Spanish, Japanese, Korean and Turkish and other languages. Translation efforts for the 2010 version are underway and they will be posted as they become available....As you help us spread the word, please emphasize:

• OWASP is reaching out to developers, not just the application security community

• The Top 10 is about managing risk, not just avoiding vulnerabilities

• To manage these risks, organizations need an application risk management program, not just awareness training, app testing, and remediation

No Easy Answer

Make no mistake - robust security is the result of consistent, ongoing code review, infrastructure expertise, and a broad knowledge of web programming, not a one-time checklist.  Still, when you're dealing with sensitive data, and especially when several organizations work on the same codebase, it's important to have mutually-accepted security standards.

Django:  Frameworks to the Rescue
Full-stack web development frameworks like Django are great for helping a team manage security concerns.  Let's investigate how Django's security features relate to the 2010 OWASP Top 10.  If you need background information on the vulnerability types themselves, I included wikipedia links.


I should also stress that this isn't an exhaustive look into every possible security vulnerability; this just explores some of the most important ways that Django mitigates (or doesn't mitigate) major security concerns.

1. Code Injection:  For most Django applications, the primary code injection risk is SQL injection.  Django protects against SQL injection through its ORM abstraction layer, which automatically escapes input.  Note that it's possible to perform raw sql queries with Django, any any such code should be manually audited for if it interacts with direct user input.  Though raw SQL is needed occasionally, especially for optimization, it's generally a code smell in a Django application.
   
   If your application interacts with any other backends, like LDAP, you'll want to investigate those third-party libraries separately.  Client-side javascript is also mitigated through its templating system; see #2 below.
   
   
2. Cross-site scripting:  Generally, the most important way to mitigate XSS is to prevent unescaped user input from making it into your application's rendered HTML. Django’s templating system facilitates this by automatically excaping all variable values.  If you don't want to escape something on the front end, you have to explicitly tell Django not to escape it.  In your code reviews, you can concentrate more on the few areas of your app where you don't escape user input.
   
   
3. Session hijacking:  With the default Django SessionMiddleware, the framework doesn't allow any session data in the url.  Session IDs are also stored as hashes, mitigating brute force attacks.
   
   While you'll still want to ensure your code doesn't expose direct session data to the user in any way, Django makes it difficult to expose that information.
   
   
4. Insecure direct object references:  Django has several mechanisms in place to mitigate IDORs.  It provides a special "slug" field if you don't want to pass object IDs around as parameters.  Django 1.2 also lets you explicitly name read-only fields in the admin, so you can prevent users from hacking together forms that alter protected  data.
   
   Note that you'll still want to manually audit your code to expose areas where users can access arbitrary object data, especially outside of the admin.
   
   
5. Cross-site request forgery:  Django has built-in CSRF protection middleware, so it would be extraordinarily difficult for an attacker to maliciously submit a form to your site using an authenticated user's credentials.
   
   
6. Security misconfiguration:  This is one item that is largely outside the domain of the web framework itself; it's more about the application's deployment environment.  You need to keep up with Python security updates, Django security updates, and keep track of any third-party libraries you use for security updates.  You need to disable ports/services you don't use, and more.  With complex apps, this can be a huge job.
   
   Fortunately, there are great, frequently-updated blogs for both the Python and Django core teams where you can keep track of security updates.  It's also easy to follow security announcement lists for your web server (e.g. apache, nginx) or operating system to keep track of security updates.
   
   
7. Insecure cryptographic storage:  If the only secure information you're encrypting is user password data, you're all set if you use Django's built-in user authentication.  Django encrypts password data using SHA1 by default, but also supports MD5 and crypt out-of-the-box.
   
   If your application directly stores or manipulates any sensitive user data, you'll need to audit that code manually.  Fortunately, OWASP maintains a great cryptographic storage cheat sheet to help you along the way.
   
   
8. Failure to restrict URL access:  Django has great built-in support for restricting access to specific content.  Access is always controlled at the view level, before anything is rendered.  You're able to restrict access for specific actions or for entire views.  Note that you'll still want to audit each url/action in your app to ensure that you're restricting access the way you intended.  It's easy to miss a @login_required decorator or forget to lock down an AJAX action.
   
   
9. Insufficient transport layer protection:  In many cases, strong transport layer protection means using SSL.  Though this falls outside the domain of Django itself, the framework does provide some help:  Django supports the secure cookie protocol (PDF link to research paper), and also allows developers to force the use of secure cookies over HTTPS.
   
   
10. Unvalidated redirects and forwards:  Because of Django's robust, built-in URL access restriction (see #7), it would be very hard for an attacker to take advantage of unvalidated redirects.  Again, since access is handled at the view level, you can't [easily] redirect users to a different url on your site without access control.
    
    Additionally, Django's built-in user authentication system doesn't allow off-site redirect links as url parameters.  Note that you'll still want to audit your code for any manual use of redirect links in URL parameters.

Further reading:

• The full OWASP 2010 Top 10 list
• Django security documentaiton
• Slides: Django and OWASP 2007 Top 10

Redmine-lite Released

I recently released redmine-lite, an easy-to-install fork of Redmine 1.0.3-stable, a project management and issue-tracking tool.

Redmine-lite has smart conventions that help you set up your instance quickly and painlessly.  In fact, you can set it up and deploy it on your server in under five minutes.  Out of the box, it's set up to use the sqlite database, the thin web server, and Gmail for outgoing messages.  

Redmine-lite is ideal for developers whose organizations require them to host issue-tracking software locally, but don't have much time to set up and administer a system.  Redmine-lite was the result of an enterprise client project.  At the time of writing, we're using this for a project with about 8 users, and it's currently tracking about 2-300 issues.


Check out the 90 second screencast!

Dependencies:  git, bundler, rvm.

Further reading:

• check out the github project 
• view slides from my presentation on redmine-lite at RIRUG
• follow Panoptic Development on twitter.

MagicRuby Roundup

Last week, I attended the MagicRuby conference in Orlando.  Aside from all the content in the talks, I learned three important things:

1. Rubyists are always trying something new and interesting.
2. Disney World is a great place to hold a conference.
3. Orlando has a fun and enthusiastic Ruby community!

I saw a lot of great talks at this conference.  I'm attempting to condense 30+ pages of notes into only the most important information.  I'll tell you (a) where to find slides/video, (b) who I think should check out each talk, and (c) what I think the most important points are.

This doesn't include every talk, but it includes most of them.

----------

Cultivating Cucumber  (Slides)
Les Hill, Hashrocket

Who should check it out?

• Developers interested in improving TDD and BDD practices.  
• Developers unsure of whether to use Cucumber.

Short take:

• Great summary of the features of cucumber:  Hooks, tags, steps, and more!
• Good explanation of Cucmber's strengths (like the use of natural langage) and its weaknesses (like the need to maintain all those regexes)
• Good discussion of best practices for organizing and refactoring cucumber suites.
• I wish there was more discussion about the types of projects where cucumber is most useful.

----------

Geospacing Your Ruby (Slides)
Peter Jackson, Intridea

Who should check it out?

• Developers of spatially-enabled apps
• Developers working in government, urban planning or environmental modeling.
• Database Administrators (for those of you in the enterprise)
• Geography/map buffs.

Short take:

• Great overview of spatial terms, geometry, map types, etc.
• Great overview of existing database and front-end tools for spatially-enabled apps.
• Good suggestions for interesting spatial data to model and useful ways of displaying it.

----------

Loving your Customers, Loving your Peers (No slides available)
Alan Johnson, Carsonified

Who should check it out?

• Technical people who deal directly with customers
• People who want to improve the reputation of the Ruby community
  

Short take:

• A "feel good" presentation, rife with humorous anecdotes and pop culture references.
• A good reality check for developers who are quickly dismissive of non-ruby technologies, Microsoft, etc.
• Lots of great suggestions on how to treat customers better, how to empathize with customers, and how to enjoy your job more.

----------

Code is not Enough (No slides available)
Gregg Pollack / Caike Souza, EnvyLabs

Who should check it out?

• Entrepreneurs
  
• Freelancers
• Software development shop owners
• Employees of small companies
  

Short take:

• Good commentary on many important engineering management concepts:  Setting expectations, delegating tasks, etc.
• A good discussion on software development as a craft vs an art.
• Good suggestions for developers, like "don't be afraid to ask for help" and advice on how to "get in the zone" while programming.
• Great advice on creating a culture of learning at your organization (especially the "book club" suggestion)
• Good insight into effective networking and "making friends rather than sales"
• Asserted that developing a product for another company is more difficult than developing and launching your own product (I don't necessarily agree)

----------

Exceptional Ruby (Slides and More)
Avdi Grimm

Who should check it out?

• Just about any Ruby developer.

Short take:

• Good review of exception syntax and handling in Ruby.
• Great discussion on when to use exceptions in the first place ("exceptions are for exceptional situations")
• Review of many design techniques for handling and managing exceptions
• Reviewed some common software design pitfalls related to exceptions.

----------

What happened to Desktop Development in Ruby? (blog post)
Andy Maleh, Obtiva

Who should check it out?

• Developers interested in desktop applications
• Developers interested in the current state of desktop application programming in Ruby.
  

Short take:

• Great review of current desktop development frameworks:  shoes, wxWidgets, Limelight, Glimmer
• Excelent insight into what's wrong and what's right with each framework.
• Great perspective on what makes a well-designed desktop app framework.

----------

Keynote (No Slides Available)
Dave Thomas, Pickaxe Author

Who should check it out?

• Dave Thomas fans
• Project managers and developers looking to improve software development methodologies.
  

Short take:

• Great review of what it really means to practice "agile" development.
• Insightful  recursive algorithm for software development:  Where do we want to be?  Where are we now?  How do we improve our position? Repeat. 
• Good use of a one-wheel balancing robot as a metaphor for prioritizing and executing incremental software changes.
• Advocated the "ten second audit" for developers:  Why am I doing this?  Does it have to be done this way?  Does it have to be done at all?
• Insightful, humorous commentary on overzealous cucumber evangelists and constantly-changing tools in the Ruby community. 

----------

Crank up your Apps with Torquebox (Slides and Video)
Jim Crossley, Red Hat

Who should check it out?

• Enterprise developers who want to work with Ruby but must develop in a Java ecosystem
• Developers challenged with building scalable, distributed web applications.
  

Short take:

• Good overview of everything Torquebox:  Configuration, JBoss, messaging, queues, processors, services, scaling techniques, and more.
• Good discussion of use-cases for Torquebox, its performance, and potential future changes.

----------

How I Lerned to Stop Worrying and Love the Cloud (Slides)
Wesley Beary, Engine Yard

Who should check it out?

• Developers currently using or interested in cloud-based infrastructure.
• Anyone overwhelmed by the choice of cloud providers.
  

Short take:

• Great overview of Fog, a vendor-agnostic cloud interface that works with many popular providers, such as EC2 and Rackspace.
• Discusses many good use-cases for Fog.
• Helpful, tutorial-style explanation of how to use Fog to interface with a cloud provider.

----------

Documentation is Freaking Awesome (Slides and More)
Kyle Neath, Github

Who should check it out?

• Open-source authors.
  
• Any developer who might, at some point in the future, hand off their project to someone else.  :)
  

Short take:

• Very straightforward, "common-sense" talk about why documentation will help your project.
• Discussed many useful ways to improve documentation, covering everything from the README to RDoc to Yard to "Having an awesome web page."

----------

Please let me know if there are any errors, of if you can point me to any slides that are currently missing!

Oracle on Rails: Can Proprietary and Open-Source Play Nice Together?

We're starting a new enterprise Rails project at Panoptic Development (that's right, enterprise Rails), and we're using the Oracle database. Yes, we all know that Rails plays best with other open-source databases like PostgreSQL, but sometimes development teams don't have the luxury of choosing the database.

The upshot of all this? We'll hopefully be contributing some articles and open-source code to help other developers work with the proprietary, enterprise behemoth that is the Oracle database.

I've started with a quick fork of Raimonds Simanovskis' useful rails_3_oracle_sample application, adding some documentation that helped me get things started.

Raimonds seems to be working harder than everyone else to integrate Oracle with Ruby on Rails, so check out his excellent blog.

Most Rails developers work in small, agile teams without a dedicated DBA, and that's often quite different from the workflow in large organizations using Oracle. Here's one of Raimonds' presentations (from three years ago!) that helped get me into the Oracle mindset:

Using Ruby on Rails with legacy Oracle databases

View more presentations from rsim.

Stay tuned for more updates.