Litany Against Fear

…who would they be? I’m following a staggering number of people (1,337 to be exact), and the signal vs. noise ratio is just getting out of control. I’m not sure how I got into this situation: I just started following everyone that followed me, and it spun out of control. I see a few options from here:

1. Remove everyone and start again.
2. Set up groups in TweetDeck and continue to follow a ton of people.
3. Slowly whittle away until my following/follower ratio is down to 1:1.

This got me thinking…what if you could only follow 10 people? Who would I follow and why? I present my list, and I encourage you to think of your own.

1. ablissfulgal: My girlfriend. I don’t need to explain this one.
2. mittense: Former coworker from Stardock who plays way too many video games.
3. GarrettAtreides: Classmate at RIT, MS lover, and all around goofy dude.
4. AmazingSyco: Classmate at RIT, Cocoa hacker, and all around funny dude.
5. chorn: Local Ruby fan that’s a riot. Supposedly he’s a CTO too.
6. BreakingNewsOn: For those who prefer their news in ALL CAPS.
7. defunkt: One of the GitHubbers and an awesome Rubyist.
8. faithfulgeek: Convert to the Ruby/OSX world from Microsoft. I’m going through the same transition.
9. nakajima: Ruby ninja who’s a code machine. And he’s hilarious.
10. guykawasaki: Entrepreneur extraordinaire. I’m listed on his site as a Twitterati too.

To those who didn’t make the cut, don’t feel bad! It’s not that I don’t want to communicate with you, just most likely I can communicate easier through a different channel (IRC, IM, what have you).

Who would you follow? Let me know in the comments or make your own blog post!

I just gave a talk at the Society of Software Engineers‘ Tech Talk Thursdays about Git and GitHub. The talk was a mashup of Scott Chacon’s various resources on Git along with Michael Hartl’s presentation on contributing to Insoshi with GitHub. I think it went pretty well and it was followed by some good discussion.

The talk is an introduction to Git from the perspective of a student who has used version control before (and hopefully has learned a bit of graph theory). I went over the little history that Git has, why Git rocks, and how helpful and easy it is to use GitHub. Check out the slides: (yes, there’s puppies)

It was definitely a lot of fun. (I almost wish someone was taking notes!) Someone was taking a video, so hopefully it’ll be up soon. Next time I give the talk I want to show how easy it is to convert from svn/cvs as well as create and browse repositories since I got a lot of suprised looks about git init and git instaweb during Q&A.

The sixth edition of my column is live: http://github.com/blog/246-github-rebase-6

I’m slowly improving the parsing process. For the last edition I broke out all of the work the app does into rake tasks, and then the Rails site is just for viewing the data. Basically there’s a few steps:

Download ATOM feeds (This week, 1400. Last week, 1200).

Check that all of the downloads went ok. (Bad gateway errors happen to good people)

Parse the files, making sure that events are unique and users forkers are logged.

Surprisingly I’m relying less and less on my app to get the column together, which is good. Huge kudos to the GitHubbers for creating the Recently Created page for each language. This helps me diversify the column while avoiding a lot of data crunching on my end.

Next week I definitely want to parse the entire month’s worth of events to really see the trends come out. Luckily their atom feed goes back 4000-5000 pages (of 30 events each) or this wouldn’t be able to happen. What this will mean is that I’ll actually have to optimize the download and parsing as much as possible. Stay tuned!

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 is a talk from Will Koffel from Sermo.

Sermo is in the health industry and builds a social network for licensed physicians in the US. They have roughly a quarter of all professionals in the field signed up in the country. (100,000!) Creates a unique model for other businesses to come and get opinions from hundreds of doctors. Built with traditional Java setup. J2EE. JBoss. Moving to Ruby now.

1) Lust. Why would you bring Ruby into your business? Don’t jump in blind to it. Keep it professional! Top-down adoption in the organization: CEO latched on first by polling VCs. Choose it for the right reasons.

2) Gluttony. Teach it who’s boss. Is Rails too opinionated for your business? They have some interesting decisions that they didn’t want to change: No production SVN, sprocs/funcs. Make conscious choices about what to use.

3) Greed. Don’t need to take the plunge and go 100% Ruby if you don’t need to. Slowly brought Rails in through some ugly iframe hacking and session cookie reading. They use Thrift from Facebook in house to let Java and Rails talk to each other. Uses the Thrift server front-end to talk to the Rails app sitting in the background.

4) Sloth. Rewriting your front-end in Ruby just isn’t enough. Architecture, services, and data are still critical. Plenty of new constraints since they’re using two languages.

5) Wrath. Leads a trail of technological tears for the former stuff in use. JSP is being phased out, but destruction is sure to happen.

6) Envy. Change is hard. Ruby training offered for all developers. Some of the code has an ‘accent’. Build inclusive systems first. Lots of differences between Java developers that are stuck in a inheritance/package paradigm instead of Ruby mixins.

7) Pride. The deadliest sin! Don’t let the love morph into hate of other languages! Be PROUD though! Find the right ways to introduce Ruby into your organizations. Give back to your Ruby community! Start or join a usergroup! Help the language mature, it’s going to have the same problems.

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.