Litany Against Fear

If you’re looking for the copious amount of notes I took for the conference, check out this post.

Speakers, if you have slides up, blog posts, or other stuff you want me to link to, let me know and I’ll make sure to add it.

I had a ton of fun at this conference. I was really honored to meet some of the smartest people in the business and really get a feel for the community at large. I think the most interesting part of the conference was the mix of people involved…it felt more like a big usergroup meeting than anything. Some people were very experienced, yet others were just starting to look into Ruby and what it has to offer them. Getting perspectives from both sides of the coin was very enlightening.

The boston.rb pub night/crawl was a great time too. (At least for most people) I definitely want to see the rochester.rb group start up again with focused presentations and I’m going to work towards making that happen. So, what I learned in a much simpler format:

• Test all the fucking time. There’s no excuses. Pick a testing framework and go with it.
• Ruby is slowly moving into the enterprise, and we have to fight hard to keep it fun and exciting.
• Agile development principles are at the core of the Ruby community.
• Pair programming helps a lot but is a skill to be learned.
• Have fun and be passionate about your work.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk by Michael Hartl who runs Insoshi.

Michael wrote Railspace and was part of Y Combinator and built insoshi out of those experiences. It’s a developer run social network. They got onto GitHub during their beta and it’s really helped them out.

Another huge project on GitHub is Rails. Explaining the basics of Git and collaboration. Pushing to repositories, and most importantly: pulling down changes from cloned copies of the source.

Going over a few features of Insoshi. One such feature is common contacts, which should be as simple as Person.common_contacts_with(@other_person). Contributors submit code constantly that isn’t tested and somewhat messy, so it helps to clean it up. We’re going to go through the process of cleaning it up since there’s various problems from functionality to database vendor problems.

Showing off GitHub and forking a repository. Forking a repo…it’s absolutely the same! They have 2 branches: master (stable) and edge (slightly less stable). Forks can maintain separate branches too. They have a custom script that pulls down changes and creating a separate branch for your own changes.

Now that we have a forked repo and it’s updated. So let’s change the code write a test for our new functionality FIRST. Wrote a failing test and going to fix it in the code. Used the & operator to find the intersect between two arrays: person’s contacts and other person’s contacts.

Showing the git commit and push commands and the diff up on GitHub. The pull request feature on GitHub lets you make the project maintainers aware that you’ve made changes and lets them bring in your work. From there it’s out of your hands, but they will be notified.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk by Matt Bauer from Pedal Brain.

Large amount of data in their system with cycling. Tires, speed, wind, etc. 46 data points. 29 collected every 5 seconds. 1.7 TRILLION data points (50 GB!) with over 5000 concurrent requests. Everything from GPS location, power, etc. Devices are peridocially connected so data much be captured quickly and latency must be low. Realtime reporting of where cyclists are at with this system. Ability to do reports on many different levels. Typical report is 40k-220k rows.

They settled with lighttpd, merb, and sleepycat software’s stuff with BerkeleyDB. It’s fantastic: open source and highly concurrent. Can scale to 256 terabytes! Fully featured DB too…ACID, locking, and more. What’s special: it’s embedded, written in C with many bindings. No SQL or schema, doesn’t operate on keys or data. Like sqlite, but way more battle tested.

Two data stores. Concurrent data store: no recoverability or transaction capabilities. Transactional data store: fully recoverable and complete ACID feature set. So it’s very powerful…but is it good through Ruby? YES! Showing off quite a few tests about how blazingly fast it is. No marshalling data over the wire or through a socket so it’s very fast.

Very difficult to handle though. All sorts of special constraints that can be customizable. Two bindings that let Ruby talk to Berkeley. Guy Decoux wrote the original, which is pretty slow and built for a much older Ruby version. The newer once with Dan Janowski is an exact implementation of the C API, quite stable. Only three test cases though.

Guy’s bindings let you feel like the data is literally an object in Ruby. Dan’s way is a lot like C. A bit messy and uses bit flags, but it’s a direct translation from C anyway. There’s only one table with BerkeleyDB, but different types of access:

• BTree: sorted, balanced tree. Ordered insertion results in full pages.
• Hash: extended linear hashing
• Queue: fixed length records
• Recno: stable record numbers

Variable length key and data means 4 gigs of data. Damn. Transactions and cursors are in there too and can be done completely through Ruby code. Indexes are in too, but requires two separate database connections.

The future: combine the Ruby feel of Guy’s code with Dan’s C codebase, improve tests, more marshaling options. Support for newer version of the DB and moving to GitHub soon.

Databasess != SQL or Entity/Relationship. Just be happy and use Ruby! Use the right tool for the job too, if it’s BerkeleyDB, sqlite, MySQL, or whatever.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by James Golick from giraffesoft.

The Rails community has been outspoken about REST, but it’s starting to get a stigma where it’s associated with only Ruby/Rails/Java. However, that shouldn’t be the case. There’s plenty of other uses outside though.

Classic problem in computer science: two computers talking to each other over the network. Typically this has been done with Remote Procedure Call. The idea that you’re invoking a method on some service. Make the programmer feel like they’re writing regular old code, especially with SOAP and CORBA. Stack takes care of plumbing and isolates you from the complexities of distributed programming.

They have some big problems though, especially in today’s era of computer. Nearly 42,000 lines of code in the SOAP stack for Ruby. It’s huge. They create way more problems than they solve. Fail.

The web came around soon after these technologies, especially HTTP. Fielding described REST originally: representational state transfer. Absolutely anything can be resource. Used all the time: GET, POST. Don’t verb the noun though and complicate things.

Rails sought to standardize on REST. Based around the map.resources and routing system, which helps out a lot. Standardization is GOOD. New hires can be much more productive because of this. Cheap and clean API. Since there’s a standardization at a higher level, powerful tooling is available. Easy and refreshing integration. Ridiculously easy to use it, only a few lines of code to even integrate with Twitter. Even more, this makes happy developers, which can lead to a more profitable business.

Beyond Rails. Building on REST gets you a free server since there’s tons out there already, and a cheap client since they’re already implemented and easy to use. Looking at Starling as an example of this. 24% queue, 76% other shit LOC-wise with REST. Going through implementing a queue in Sinatra, which is really quite easy. Building apps on REST is good since there’s plenty of servers and clients out there that can easy consume and use the services without a lot of code.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by Josh Susser from Pivotal Labs.

Tons of wonders in the world. What the heck happened to Smalltalk though? Spawned many languages, but it was still superior. Yeah, there’s Lisp too. Why aren’t we all programming in Smalltalk? C++ mostly.

Why is it a bad idea to go with C++ (At Apple!) Alan Kay said that 3 things make up OO: encapsulation, polymorphism, inheritance. For C++: WEAK encapsulation, WEAK polymorphism, WTF inheritance. At Xerox he programmed a smalltalk interpreter (or something) in Microcode. C++ is not a high level language. Just a thin layer on top of C, which is just portable assembly. Smalltalk had a lot of great things…IDE, garbage collection, and a huge blind spot.

Josh likes looking at things like their greatest strength is their greatest weakness. Comparing to Superman’s strength and willingness to do good, which Lex Luthor can manipulate.

“An operating system is everything that can’t fit in a language” Very meta: Most of smalltalk implemented in smalltalk. Made of a kernel, which made up the fundamental pieces of the language: primitives, datatypes, IO, fundamentals. Virtual image had everything else: compiler, graphics, network stack. VM can be ported from platform to platform, and the image runs the same.

Virtual image is really cool, but it’s not without cost. Made applications almost impossible to deliver. He was one of the first at Xerox to deliver commerical Smalltalk apps. Very hard since the code was integrated with the user’s data. No concept for namespaces, so screwed if vendors use them together.

So, it’s a bit of a monolith. You’re not using Linux, Windows, etc windowing system, you’re using Smalltalk’s. It’s getting old. C++ sucked up all of the oxygen and steam that Smalltalk had built up in a very short period of time.

Why did that happen? C++ was not better than Smalltalk, but it was just enough better than C. Didn’t require a big conceptual leap, plenty of tools, easy to implement, tons of tools already available for C. Most important things: Could actually ship applications with C++ to customers. Just enough more productivity! Sometimes, good enough is good enough.

That brings us to Ruby. It would really suck if we were all programming in the modern equivalent of C++. It’s not in immediate danger of facing Smalltalk’s demise, but it couldn’t hurt to think about ways to strengthen Ruby. Not going to fix the language, but fix the language.

Rails. Most people came through it, and web development is the center of what’s being done with Ruby. However, in the long run it’s a niche….like PostScript. The next Ruby ‘killer app’ will be outside of the web development domain. Not sure what yet though.

Proposing that the reasons why people like Ruby is also because of agile development. There’s a higher percentage of Rubyists that actually do use agile development techniques. It brought joy back to his programming experience because of that. Best thing about Rails is the test directory and how it encourages TDD. RubyGems too since most ship with tests. There’s a culture of agile development around Ruby and it’s essential to its future. Performance issued may be solved by Maglev, Rubinius, YARV, etc.

The amount of metaprogramming in the language helps with the TDD movement. The problem is in development tools: we don’t have a good IDE! It’s a joy to program in it, but it makes it hell on an IDE to understand what’s going on with the language. Smalltalk made decisions to limit the language so good development tools could be created. Simple refactoring methods like extract method, renaming are easy in Smalltalk. Not so much in Ruby because of its dynamic nature.

Going through how update_attributes works…it uses send to dynamically set attributes. It’s incredibly powerful and expressive, but it makes refactoring difficult. This may be preventing people who are working with Java and used to refactoring tools to move over. No way to fully statically analyze a Ruby program…you’d need to solve the halting problem: Run the program to see what the program does. Why don’t we just do that? Run tests to see what’s interesting about the program.

Showing off a little example to see what methods have been called on what classes. Can easily hook into Ruby metaprogramming to figure it out, but the main problem with this is that it can be very slow and you need to run the whole program.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Foy Savas. He’s a Ruby Application Developer and a contributor to Merb and DataMapper Just for Foy:

Dan, you better pay up.

The list of web frameworks goes on and on! It’s important to keep an open mind. Merb has influnces from Django/Pylons from Python. It’s meant to do what Rails is bad at: quick responses. What is it now? High performance, quick to deployment, fully scalable.

We can make analogies between the frameworks.

Application performance: Looking a graph of how the frameworks stack up for requests per second. Fastest is merb routing, faster is merb controller, merb itself handles rendering pages. Rails and Merb eat cake for breakfast…but merb blazes ahead! How? Uses Ruby, Picks the best, tests for speed. No Symbol#to_proc, considered evil. Merb saves big with design decisions. Merb inline templates into controller as methods! No copying like Rails does. Merb is committed to performance: future releases can’t be slower.

Abstract controller: exception, mail controllers. No double renders. Merb uses case statements instead of responds_to. Merb has a worker queue baked in with run_later! Pushes it out of the request, response cyce. Merb is Rack-enabled. Super easy. Magical stuff is possible with Rack middleware and multiple versions of Merb. ActiveSupport is a kitchen sink. Extlib isn’t. Only what you need, nothing you don’t. Matz loves the Merb too.

DataMapper kicks AR’s ass. Auto-migrations, identity map, lazy loading data sets. Rails loves alias_method_chain. Merb hates it and would rather just refactor. The Merb API public method interfaces doesn’t change without timed deprecation. Private methods aren’t supposed to be used so they can factor. Plugins are gems!

Merb Slices: Rails engines and an official part of the app. Extract code from your app and use it on others. Merb Auth: RESTful authentication that uses the cascading strategy pattern. And more. So much more.

Tons of Rails production examples. Not so much Merb. But they should be counted as Ruby apps.

Marketability! They’re looking to get real with Rails. Looking for smart people no matter what. Gotta respect the leaders of the community.

What’s the Merb Advantage? Gems. Modularity. Performance. Stack agnosticism. Open-Endedness.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Chad Pytel and Tammer Saleh from Thoughtbot.

They’re gonna talk about things that they’ve seen that have gone wrong in the Rails world. It’s not gonna teach you to do TDD. It’s gonna show you how to fix code better.

Move code from controller to the model. 14 lines is TOO long for the create action. Might be crazy but you need to keep your guard up. Some crazy stuff is going on in this method. Transaction, catching an exception too. Refactored so it’s a bit smaller, but not ideal yet. Refactor by identifying parts of code that are identical. Try to weed out unnecessary code too. Use AR callbacks when you can, a LOT easier. DO WHAT YOU MEAN. Have expressive callback names. Constantly check for code that isn’t needed. Don’t violate the Law of Demeter…keep things DRY and look into the rule when you can. Use conditional callbacks in Rails 2.1 to remove even MORE code. Once again, push actions down into callbacks when possible. Get rid of transactions if you can. Only rescue exceptions if they are truly exceptional!

Putting too much domain knowledge in the controllers is BAD. They move state checking out of the controller and into the model by defining a hash and dynamically creating methods to check the state. Tackle large refactoring iteratively! Shove business logic into the model. DRY DRY DRY. Use named scopes instead of having complex finders in your controllers.

User Roles. See them all the time in apps. Ugly, messy, thoughtless code. Instead of having a role model, use boolean fields if you only have a small number of roles. If more than that, use has_many and not HABTM. Don’t build beyond the requirements and don’t jump to models prematurely.

Bad code happens to good people. This was all production code that they definitely wrote, but looked like crap 3-6 months down the line. The real lesson is to always be refactoring.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by David Berube.

Rails on Windows happens because sometimes it’s a MS shop that isn’t fully converted to Ruby. Fundamentally, Windows is not a good operating system. It just isn’t POSIX. Most Rails devs are using OSX and are deploying on some version of Linux. Windows definitely isn’t suitable for a server environment.

Easy way to get started is the One Click Ruby Installer (http://rubyinstaller.rubyforge.org) Many intrinsic pitfalls.

• Automatic binary conversion: LF => CRLF. Sucks since you need a special flag to tell Windows not to touch it.
• No Kernel#fork. Can’t do anything about it.
• No GNU (commands).
• No Compiler.

Running the actual development environment takes a lot of work. Visual Studio does have Ruby in Steel (but that costs money). NetBeans is clunky. He recommends using gvim, despite the obvious learning curve, since it can easily translate on UNIX systems. Emacs? E-text editor too has bundles, but don’t work all the time.

POSIXing your Windows box will never happen 100%. Cygwin is a good way to emulate the environment, but it sort of sucks. There are a few ways to emulate linux utilities too: unxutils, gnuwin32. Plenty of other tools too: PuTTY, Filezilla/SmartFTP, Litestep for Virtual Desktops and more.

Why switch? Go for Ubuntu! (If you can) It’s awesome. There are some bright sides…FXRuby and shoes for GUI stuff, and OLE isn’t too bad within Ruby either.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Jon Larkowski from Hashrocket.

Subset of Obie’s The Hashrocket Way talk. No mismatch between what the customer says and what the tests give. Hashrocket values agility & transparency. Communicate all the f***ing time, but only if the overhead is low. Two lines of communication:

• Client to developer
• Developer to developer

Tools they use:

Pivotal Tracker: Awesome tool. They don’t write a line of code unless if a story in the application supports. Seriously, just check out http://pivotaltracker.com Tells you when features will be done with velocity. Again, just go to the site. This helps them out with communication because it lets them know who’s working on what. Also a huge scheduling tool. Helps developers talk to developers with estimation efforts.

Stories: All work is driven on stories. Only code what’s on the card. Stories are tokens of a conversation. Writing stories at a developer level where they can start implementing it is important. They used to use index cards but now they just use the Tracker. They slowly train customers to write their own stories. Standard forms:

• As a / I want to / So That
• Given / When / Then

They want to understand development efforts in a larger context, so this helps out to see the bigger picture.

Pair programming: Keeps developers honest, focused, and leads to higher quality code. There’s two wheels on the axle since there’s more than one person that knows the code. Laptops on either side of the computer. Ping Pong: one dev writes a failing test, other writes code to pass the test, rinse and repeat. Daily standups for the entire company.

Testing: Express client stories as tests with Cucumber and normal MVC tests. RSpec specdoc format creates documentation. Durable system specification since it’s in English. Tons of techniques used: RSpec, MVC, Factory Girl, Cucumber, Selenium, RSpactor (instead of autotest), Continuous Integration (CruiseControl), even clicking on stuff too.

Delivery: All the f**cking time. Delivered multiple times a day! Very tight feedback loop with client. Smoke test together to demo features. Deployment with Capistrano to EY or EC2. Some Passenger use.

Client Acceptance: Developer-assisted! Hold their hands for a while. Video chats, use the Tracker (automatic updates too). Daily standup with client to touch base.

Impedance Matching: Clients, developers, testers…all speak different language. The goal is maximum power transfer! Need to be able to talk to clients in their language, and not in geek speak. Bridging that gap requires a geek-to-english filter. Code however is a different answer. Getting the code to a geek speak standard is easy with regular code and MVC tests. With integration tests, it can bring that up to a level where both developers and clients can understand it: ENGLISH.

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Matt Pelletier from Eastmedia.

Going to talk about the mobile world. ~280 million PC sales worldwide. Around 1.2 billion mobile handsets too. The technologies that are in play:

• Voice
• SMS
• MMS
• Mobile Data Services

Voice: How all of the telcoms started, obviously. Normal calls. Robots too. Tons of VoIP technologies too: Voice XML, Asterisk/Adhersion

SMS: Just recently started to surpass the number of voice calls in the States. SMS has long been used in South Korea/Japan. More SMS than email there! Mobile Terminated: you send a text message, Mobile Originated: you recieve a text message. SMS works even during emergencies and when phones are normally down since it wasn’t originally a consumer service. There’s no metadata associated with an SMS though…just time and 160 characters. Can’t reply even.

MMS: “A total shit show”. Even Apple ditched it and used email. It’s very carrier specific and abritrary. Hard problem to solve though.

Mobile Data Services: Most sharply rising area that’s important to businesses. WAP 1.0 was a disaster. WAP 2.0 is a trimmed down Web. Trimmed down version of XHTML. Matt used this for their New York Jets project, which got 2 million hits within 4 hours when Brett Favre got signed. Crazy. The “REAL” internet. is involved here too, sans Flash. Browser War v2.0: MobileSafari, Opera, Android Browser, Skyfire. Tons of apps now too. These used to be controlled by carriers in the US, but it’s changing. This is being slowly eroded by the App Store and Android’s Marketplace. App development process is MUCH better than it used to be, but it really isn’t the Web. MANY MANY operating systems on each phone. The best approach to creating these seems to be hybrid: SaaS, iPhone app consuming a Rails app.

Smartphones are becoming more and more common. What exactly do people want? Twitter/Facebook: talk to each other, find places, search. Americans use the mobile web as an extension of the desktop. Location Based Services aren’t quite there yet. GPS is still slow. Not able to figure out exactly where you are yet.

Spot.io: Post online strange stuff you see that’s location based. Entry points: Twitter, IM, Email, API with OAuth, iPhone client. They’re also parsing english to extract the most knowledge. Using a hand written parser since people don’t write the same on Twitter as they do on the Wall Strett Journal.

iPhone Development: Feels like Rails community 3-4 years ago. Sparse domain knowledge and poorly organized. Apple’s SDK has code examples but has a lot of holes and problems. Not many good code conventions, but not that bad given it’s been out for a year. Apple and Google have squeezed down the multiple layers of complexity to a point where you just have to worry about the APIs.