Originally, I based this notion on the surprising number of people I talked to who were involved in some sort of Agile adoption that was basically bunk: Iterations that weren’t iterating. Testing that wasn’t testing. Top-down power relationships. Cargo cult Agile. Fixed deadlines and fixed scopes. Teams that aren’t teams. Project managers who pretend to be Scrum Masters. Oceans of Scrumbut.

RubyDrop

RubyDrop is my first ever Ruby project that aims to be an open-source, roll-your-own, Dropbox clone using Git as the backend. There's still a lot of details to work out, and the code may be a little messy, so you'll have to bear with me (it's a process).

Prerequisites

• RubyGems
• Grit
• Ruby 1.9+ (need require_relative function)

How to Run

You can start RubyDrop by simply running:

./RubyDrop &

By default, the RubyDrop folder that it monitors is created (if it doesn't exist already) at ~/RubyDrop. To change this path, simply edit config.yml. It also initializes a Git repository in the folder automatically, if it doesn't already exist.

Handling Remote File Syncing and Tracking

After much deliberation, I have decided to go with Git for handling file tracking and remote file syncing. We'll see how well this pans out...

Currently, you must manually create the git repo on your remote server. This will be automated as soon as I can write RubyDrop-Server. If you are new to Git, this is how you do it (assuming you are SSH'd into your remote server):

First, you will probably want to make a new user for RubyDrop:

adduser rubydrop

Then, make it possible for RubyDrop to make a passwordless SSH connection to the server:

"Shortest passwordless ssh tutorial, ever"

Finally, you will need to make the repository folder on the remote server (login to the remote server the newly created 'rubydrop' user):

cd ~/
git init RubyDrop.git --bare

That's it! Yes, I'm aware that was a really rough guide.

Controlling RubyDrop

RubyDrop has a TCP interface that you can use to communicate with it while its running. The simplest and easiest way to do so is by using telnet.

Here's an example that halts the RubyDrop daemon (by sending 'stop'):

telnet localhost 11311
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Thu Nov 25 03:23:48 2010
Welcome to RubyDrop
stop
RubyDrop daemon halting!
Connection closed by foreign host.

TCP Interface Commands

• config_get [name]
  • Retrieves the value from the RubyDrop config specified by [name]
• stop
  • Halts the daemon
• quit
  • Ends the TCP session, but leaves the daemon and TCP server running

Instead, imagine a simple and slim build server tool that is maintained by the Ruby community itself (just like Gemcutter is, or many other infrastructure/tool-level projects are) in order to support all the open-source Ruby projects/gems we’re using every day

Concurrency is certainly  not a new problem but it’s getting more and more attention as machines start having more than 1 core, that web traffic increases drastically and that some new technologies show up saying that they are better because they handle concurrency better.
If that helps, think of concurrency as multitasking. When people say that they want concurrency, they say that they want their code to do multiple different things at the same time. When you are on your computer, you don’t expect to have to choose between browsing the web and listening to some music. You more than likely want to run both concurrently. It’s the same thing with your code, if you are running a webserver, you probably don’t want it to only process one request at a time.
The aim of this article is to explain as simply as possible the concept of concurrency in Ruby, the reason why it’s a complicated topic and finally the different solutions to achieve concurrency.

TL;DR You can pass objects that respond to call to the scope method in Rails 3.1.

Somehow missed this earlier!

Testabale, composable, OO named scopes coming rails 3.1!