A “FREE” Git and GitHub Course – 10th batch

A “FREE” Git and GitHub Course – 10th batch

Registrations are now open for RubyLearning’s popular “Pay if you like” online Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your SSH Key
  • Introduce yourself to Git
  • Add some additional Git settings
  • What’s GitHub?
  • Set up your GitHub account
  • Follow a Friend
  • Watch projects
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 25th Jan. 2014 and runs for a week.

The first nine batches were a run-away success. So hurry, registrations have started.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 10 for the course. Since this is a “Pay if you Like” course, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 10 or more, we shall email them a copy of the book (.pdf) “Using Git & GitHub eBook” – the course is based on this book.

How do I register?

  • First, create an account on the site and then pay the fees of US$ 10 by clicking on the PayPal button Paypal
  • After payment of the fees please send us your name to satish [at] rubylearning [dot] org so that we can send you the eBook, which normally takes place within 48 hours.
  • If you want to take the course for free, please just create an account and send us your name (as mentioned above).

Mentors

Satish Talim and Victor Goff III from the RubyLearning team.

Some Highlights

RubyLearning’s IRC Channel

Some of the mentors and students hang out at RubyLearning’s IRC (irc.freenode.net) channel (#rubylearning.org) for both technical and non-technical discussions. Everyone benefits with the active discussions on Ruby with the mentors.

Google Hangouts

There is a Hangout Event that is open for students, for drop-in hangouts where students can pair program with mentors or with each other. This is often where you can get help with your system, editor, and general environment. Anything that can help you with your coding environment that you are having problems with are usually discussed interactively here.

Git Repositories

Shared (private) repositories available for those that want to learn git and the revision controlled programming workflow. This allows students that want to collaborate while learning. This is a great way to record your progress while learning Ruby.

How does the course work?

For details on how the course works, refer here.

Technorati Tags: ,


(Powered by LaunchBit)

A “FREE” Git and GitHub Course – 9th batch

Send to Kindle

A “FREE” Git and GitHub Course – 9th batch

Registrations are now open for RubyLearning’s popular “Pay if you like” online Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your SSH Key
  • Introduce yourself to Git
  • Add some additional Git settings
  • What’s GitHub?
  • Set up your GitHub account
  • Follow a Friend
  • Watch projects
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 3rd Aug. 2013 and runs for a week.

The first eight batches were a run-away success. So hurry, registrations have started.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 10 for the course. Since this is a “Pay if you Like” course, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 10 or more, we shall email them a copy of the book (.pdf) “Using Git & GitHub eBook” – the course is based on this book.

How do I register?

  • First, create an account on the site and then pay the fees of US$ 10 by clicking on the PayPal button Paypal
  • After payment of the fees please send us your name to satish [at] rubylearning [dot] org so that we can send you the eBook, which normally takes place within 48 hours.
  • If you want to take the course for free, please just create an account and send us your name (as mentioned above).

Technorati Tags: ,


(Powered by LaunchBit)

A FREE Git and GitHub Course – 8th batch

Send to Kindle

A FREE Git and GitHub Course – 8th batch

Registrations are now open for RubyLearning’s popular Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your SSH Key
  • Introduce yourself to Git
  • Add some additional Git settings
  • What’s GitHub?
  • Set up your GitHub account
  • Follow a Friend
  • Watch projects
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 4th May 2013 and runs for a week.

The first seven batches were a run-away success. So hurry, registrations have started.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 5 for the course. Since this is a “Pay if you Like” course, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 5 or more, we shall email them a copy of the book (.pdf) “Using Git & GitHub eBook” – the course is based on this book.

How do I register?

  • For the “Free” participants, register on the RubyLearning.org site and send us your name and registered email address while creating an account at RubyLearning.org to satish [at] rubylearning [dot] org We will enroll you into the course which normally takes place within 48 hours.
  • For those who want to contribute, you can pay either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, the various courses and provide quality content to you.
  • Once you pay the fees below, register on the RubyLearning.org site and send us your name and registered email address while creating an account at RubyLearning.org to satish [at] rubylearning [dot] org We will enroll you into the course which normally takes place within 48 hours.

After you click the “Pay Now” button below, you will be taken to a webpage as shown below.

Please enter the amount you want to pay for the course in the “Item price” field and click on the “Update” link. You can safely pay via PayPal.

You can now pay the Course Fees by clicking on the “Pay Now” button below.

Technorati Tags: ,


(Powered by LaunchBit)

“Free” Git and GitHub Course – 7th batch

Send to Kindle

“Free” Git and GitHub Course – 7th batch

Registrations are now open for RubyLearning’s popular Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your SSH Key
  • Introduce yourself to Git
  • Add some additional Git settings
  • What’s GitHub?
  • Set up your GitHub account
  • Follow a Friend
  • Watch projects
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 9th Feb. 2013 and runs for a week.

The first six batches were a run-away success. So hurry, registrations have started.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 5 for the course. However, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 5 or more, we shall email them a copy of the book (.pdf) “Using Git & GitHub eBook” – the course is based on this book.

How do I register?

  • You can pay either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, the various courses and provide quality content to you.
  • Once you pay the fees below, register on the RubyLearning.org site and send us your name and registered email address while creating an account at RubyLearning.org to satish [at] rubylearning [dot] org We will enrol you into the course which normally takes place within 48 hours.

After you click the “Pay Now” button below, you will be taken to a webpage as shown below.

Please enter the amount you want to pay for the course in the “Item price” field and click on the “Update” link. You can safely pay via PayPal.

You can now pay the Course Fees by clicking on the “Pay Now” button below.

Technorati Tags: ,


(Powered by LaunchBit)

Git and GitHub Revised Course

Git and GitHub Course

Registrations are now open for RubyLearning’s popular Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your local repository folder
  • Create your SSH Key
  • What’s GitHub?
  • Set up your GitHub account
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Watch projects and people
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 29th Oct. 2011 and runs for a week. You first need to register on the site and then enroll into the course. After registration, you can download the “Git and GitHub” eBook (a US$ 7 value) for free.

Early Bird Registration Discounts

  • For the first 5 registrations, Course Fee: US$ 7 per participant
  • After the first 5 registrations, Course Fee US$ 14 per participant

The course fee goes towards maintaining RubyLearning and helps provide quality content to you.

The first five batches were a run-away success. So hurry, registrations have started.

Technorati Tags: ,

June 23, 2011: Distributed Magic Control

1. Today’s News: Github for Mac

Odds are you heard this one already, but the fine folks at GitHub announced a Mac desktop client. It differs from, say, GitX in that it attempts to be a front end to your entire GitHub account rather than one particular repo.

I haven’t used it a ton yet, but a couple of quick impressions:

  • I think we can now definitively say that Tweetie and Loren Brichter is to the current set of Mac applications what Delicious Library was to the batch a few years ago — the source of a widely used design aesthetic.
  • It’s got a nice set of branching features, the one thing I’m really missing is a way to browse the actual current state of the files in the repo, though I guess you can always go to GitHub itself for that information. It feels a bit feature-light overall.
  • I’m guessing the main users of this initially will be team members who aren’t commonly on the command line, but who need current code, like designers. (Though I do use GitX a fair amount to visualize history, and might use this in its place for some things). The merge tools are interesting, I’ll probably try them once to see what they are like.

2. JavaScript Gripes

If you think the main problem with this blog is that I don’t link to enough cranky rants about JavaScript, here’s one by Fredrik Holmström, of the IronJS project. The strong claim is this:

my point of view after having developed IronJS is that there are a couple of critical problems with JavaScript that prevents it from ever being a viable alternative as development platform for server application development.

I suspect the gripes themeselves will be broadly familiar to JavaScript fans — lack of namespace support, crazy language design choices, lots of run times. It’s nicely ranted, though points off for using the comparison between JavaScript: The Definitive Guide and JavaScript: The Good Parts, that’s kind of hacky.

3. jQuery Mobile Goes Beta

jQuery mobile came to my attention via Obtiva apprentice Carl Thuringer. It’s a cross-platform framework intended to simplify web applications targeted at mobile browsers using HTML 5 and JavaScript. It looks really nice, and they just announced beta 1

4. Pottermore

Also nearly breaking news about another RailsRx obsession, ebooks. According to multiple sources, J. K. Rowling’s new Pottermore site will be the curated official fan site she’s always wanted. Also, Rowling will apparently self-publish cross-platform ebooks of the Potter series.

This is interesting for a couple of reasons, not least of which is that it’s another blow to the long-standing model where publishers and labels used bestsellers to subsidize everybody else. As far as I can tell, nobody has mentioned what she’s going to price the books at, but it seems like her overhead costs per-book at this point are rather low. I doubt she will, but it’d be interesting if she tried to break the current price structure by hitting a $4.99 point. I suspect she’s more likely to do a middle ground of $9.99.

5. Soccer Stats

And, as a longtime baseball stat nut, this article about new statistics taking over soccer was interesting. One big flaw in the new soccer stats is obviously that it’s nearly impossible for the casual watcher to track the stats, since they are measuring things like how much distance each player runs at top speed and the like. Still, I like the look at how you even begin to measure a complicated system like this, and how you determine what’s important to look at.

Filed under: Git, Harry Potter, JQuery

How does one effectively combine Ruby with Git for source control?

How does one effectively combine Ruby with Git for source control?

This guest post is by Erik Andrejko, a software developer living in San Francisco who spends his days working on web applications and solving data mining and machine learning problems integrating Ruby, Clojure and Java. When not spending time with his family, he blogs about web development and user experience at railsillustrated.com and can found on Twitter at @eandrejko.

Introduction

Erik Andrejko Source control is one of the primary tools of a developer’s toolbox and can be one of the most powerful. Git is one of the most popular source control systems used by Ruby developers and one of the most powerful available. Following good Ruby development practices, such as good use of unit tests, and disciplined code organization allow one to easily make use of some of most powerful features of Git. With good habits, Ruby and Git are a potent combination.

This article assumes some basic familiarity with Git concepts and commands and discusses effective use of Git with Ruby projects. Git can take some time to learn well, a good introduction can be found at gitref.org and the canonical comprehensive reference can be found at Pro Git.

Use Feature Branches

Git is remarkably capable of creating separate development branches and later merging those branches. A good developer can use this to their advantage by using feature branches. A feature branch is a branch of the codebase used to implement a single feature.

To create a feature branch in Git just create a branch:

git checkout -b feature

Once you get into the habit of using feature branches it is not uncommon to have many of them simultaneously, so it is helpful to name the feature branch with some descriptive name.

Doing your development work on a feature branch provides many benefits:

  • You can develop the feature over time and switch back to the master branch at any time to have a known good version of the code.
  • You can abandon the feature at any time without having to carefully revert a partial implementation.
  • You can change your commits on the feature branch before committing them to the master branch.

When the feature is complete you can move the commits to the master branch with either a git merge:

git checkout master
git merge feature

or alternatively with a git rebase, depending on how you prefer the history to be maintained:

git checkout master
git rebase feature

When doing a merge, an additional commit will be created on the master branch which will show that two branches have merged at that point. Thus the history will forever reflect the existence of your feature branch. Some developers prefer to avoid having these merge commits in the history. To avoid these additional merge commits use git rebase instead, which will move the commits from the feature branch onto the master branch without creating an additional commit keeping the history of the master branch linear.

Rewrite to Keep Your Commits Clean

When using a feature branch it is generally a good practice to take the opportunity to rewrite the commits before placing them on the master branch. Generally, changing commits is often discouraged in Git and many Git guides advise against changing history by rewriting commits. This is good advice, as rewriting commits on a shared branch will cause headaches for other developers. However, on your private feature branch you can change any commits you like before they become published on the master branch.

To rewrite your commits, from the feature branch use git rebase with the --interactive flag:

git rebase --interactive master

which will start an interactive rebase. Using an interactive rebase will enable you to:

  • Merge commits together (known as squashing).
  • Change the order of the commits.
  • Change the content of commits and their messages.

Another important task before publishing your feature branch is to ensure that all the unit tests pass after each commit. As we shall see later, this will make it easier to use another powerful feature of Git.

Ruby and Git play well together

There is one disadvantage to using feature branches instead of just placing all commits on master: merge conflicts. Generally Git is very adept of avoiding merge conflicts but some conflicts are unavoidable.

For example, suppose that on the feature branch we add the has_coupon? method to the User class:

class User
  def name
   @name
  end

  def has_coupon?
    !coupons.empty?
  end
end

If on the master branch, another developer were to also add a method to User after the name method there will be a merge conflict when merging or rebasing the feature branch onto the master branch. This type of merge conflict often occurs when classes get large and are often changed. o prevent this kind of conflict use Ruby modules to organize the methods in the User class.

On the feature branch change the User object as follows:

class User
  include CouponMethods

  def name
   @name
  end
end

and add a new file coupon_methods.rb containing the new methods:

module CouponMethods
  def has_coupon?
    !coupons.empty?
  end
end

Since we have added a new file with we will likely avoid any merge conflict if another new methods are added to User in the master branch. Of course, if two developers both add include statements to the top of the User class there will again be a merge conflict. However fixing a conflict which involves only a single line is easier than a conflict involving many lines of method definitions.

Ruby is flexible enough to use a pattern that guarantees no merge conflicts. If we change coupon_methods.rb to:

module CouponMethods
  def has_coupon?
    !coupons.empty?
  end
end
User.send(:include, CouponMethods)

then there cannot be a merge conflict as no two developers will change the same file. Generally, it may not be a good practice to extend the User object in this way. It does illustrate that Ruby can be made to play very well with Git when the need arises.

Using submodules to extend classes in a unobtrustive way is particularly useful when modifying third-party code. In these cases avoiding merge conflicts is particularly important as it is usually more difficult to resolve the conflict when the other developer is not readily available to help or when test coverage is lacking. By modifying third-party code in Ruby ouside of the original source files you can avoid the need to resolve any merge conflicts when updating that third-party code. Typically in these cases a good suite of units tests testing both the original third part code and the modified code is essential to ensure that the behavior of the updated third-party code with your changes stays the same.

When Something Goes Wrong

Bugs are inevitable and Git has several features designed to help debugging. When a bug is discovered, the first place to look to find the commit that introduces the bug is to use git log to look for modified files and search for the obvious candidates.

The git log --stat command will show each commit message together with a list of files modified by that commit.

git log --stat

If you want to isolate the output of git log --stat to a particular subdirectory or file, you can provide a path:

git log --stat lib/

It is preferable to avoid adding bugs in the first place and Git has some tools to help. In Ruby it is common to use descriptive method names in place of comments in the source code. Commit messages provide an alternative source of comments for each source file. To see the commits which are responsible for the current state of every line of code in a particular file use the git blame command.

git blame lib/user.rb

The first column of the output will be the SHA of the commit. To view the commit message for this commit pass the SHA to git log which will show the commit message at the top of the log:

git log 1d35a63e

Often, the commit message will provide very useful information about the intent behind a particular line of code.

Sometimes the source of a bug is not found in the expected place. In this case finding the commit which introduces a bug can be difficult. Fortunately git provides a tool which can be incredibly useful and is guaranteed to find the commit which introduced the bug: git bisect. The git bisect command is designed to perform a binary search of the commit history to find the first ‘bad’ commit. To start a bisect, checkout the commit which is known to contain the bug, mark this as ‘bad’, check out any commit known not to have the bug and mark this as ‘good’:

git checkout known_bad_commit
git bisect start
git bisect bad
git checkout known_good_commit
git bisect good

After marking a commit as ‘good’, Git will start a binary search of the commit history between the ‘good’ and ‘bad’ commit by checking out a series of commits. After each checkout, mark the commit as ‘good’ or ‘bad’ with the git bisect command. Eventually Git will report the first ‘bad’ commit along with its commit message. Once completing the bisect you can restore Git to its original state by running git bisect reset. Alternatively if you make a mistake marking a particular commit or otherwise want to start over you can also use git bisect reset.

Bisecting a long-range of commits can be time-consuming and fortunately this process can be automated. If you are using good testing practices, you will likely start after identifying the bug by adding a failing test. You can use this failing test to run git bisect automatically using git bisect run:

git checkout known_bad_commit
git bisect start
git bisect bad
git checkout know_good_commit
git bisect good
git bisect run ruby test/unit/unit_test.rb

Using git bisect run will checkout a series of commits and run ruby test/unit/unit_test.rb after each checkout. If the test passes the commit will be marked ‘good’, if it fails the commit will be marked ‘bad’. Assuming that you simply edit test/unit/unit_test.rb you may run into trouble if any of the intermediate commits also change test/unit/unit_test.rb as Git may not be able to resolve the conflict. In this case, you can temporarily add the failing test to a new file before using git bisect run.

It is should now be clear why it is important to keep the unit tests running after each commit. If not, using git bisect run may find the wrong commit.

Any program can be used with git bisect run, not just a Ruby test. For some bugs it may not be possible to add a failing test because not enough information about the source of the bug is known. In this case, as long as the bug can be detected by some automated means you can still use git bisect run to find it. To use any Ruby program with git bisect run use the exit method to pass the correct state back to Git. f the test passes: use exit(0) to exit the Ruby program and indicate to git bisect run the commit is ‘good’, if the test fails use exit(1) to exit the Ruby program and indicate to git bisect run that the commit is bad.

Git bisect is one of the best features of Git and has been used to find some difficult to trace bugs. Even better, by automating the search with git bisect run, no matter where the bug was introduced, it will be found.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

If you are new to Git then the Using Git & GitHub eBook would be useful to you.

Technorati Tags: , ,

June 16, 2010: What Shoulda We Do?

Top Story

Thoughtbot talks about their plans for Shoulda moving forward. The big takeaway is that, while the context library will be separated out for use in Test::Unit, both Shoulda style and Shoulda effort will be focused on RSpec integration.

I have some complicated thoughts about this one. I’m thrilled that Shoulda is being maintained — it’s a tool I’ve used a lot, and I was starting to get worried. And they should move their open source tool in any direction they want. But, of course, I can’t help thinking about how this affects me, and having Shoulda be primarily a complement to, rather than an alternative to, RSpec has an interesting effect on the book I’m in the middle of writing.

It’s so funny how these things change. It’s been about eighteen months since I started writing what would become Rails Test Prescriptions. At the time, I was not a big fan of RSpec, largely because I didn’t like the heavily mocked style that seemed to go along with it. With the emergence of Shoulda and the factory tools, Test::Unit had gained basic functional parity with RSpec. It also seemed like Shoulda/Test::Unit was really starting to gain community mindshare.

So, I wrote the book intending it to be a basically tool-agnostic guide to Rails testing, but with most of the examples in Test::Unit on the grounds that a) Test::Unit is part of the core Ruby and Rails stack, so it’s always around, b) it’s what the core team uses, c) I personally was using Test::Unit, and d) RSpec already had a book, so it seemed prudent for many reasons to find my own space. Those of you who bought the Lulu version will remember that it has longish chapters on Shoulda and RSpec, treating them more-or-less equally as alternative mature test frameworks.

In the interim, tools have ebbed and flowed. Cucumber came out, with very strong RSpec support (especially at first), starting a bit of a trend of new tools supporting RSpec over Test::Unit. The single-assertion style from Shoulda seemed to gain some traction among RSpec users. I started actually using RSpec more, and liking it.

At the same time, some things haven’t changed. I’d still like the book to be framework agnostic to the extent possible. Test::Unit is still the Rails default, and is probably still easier for a somebody new to testing to understand. But I think I have some re-writing in my future.

Oh yeah, other links

Martin Fowler on what makes a good team room for an agile project.

Speaking of RSpec 2, here’s one of what I hope will be many posts from David Chelimsky about a new RSpec feature, metadata and filtering.

Gitbox is a new Max OS X interface for Git. Currently seems less full featured than the GitX fork that I use, but it does seem like a nice start.

Relevance announces PDFKit, a new library for PDF generation, along the lines of PrinceXML. I don’t see this as a replacement for Prawn at all, though. There will always be cases where direct generation makes more sense. And there will always be cases where conversion makes sense. I think doing a book with Prawn would have been challenging, for example.

Finally, here’s a simple little survey of the Ruby community. I note parenthetically that RSpec has 42% of the vote for Preferred Testing Framework, with Shoulda and Test::Unit having a combined 31%.

Filed under: Agile, Git, PDF, Relevance, RSpec, Shoulda

June 11, 2010: Get Ready for Whyday

Looks like I did get a few links gathered yesterday. I’m also working on a post about PeepOpen, TextMate, and RubyMine, I had an interesting day with all of them yesterday. I also remember working on a book-like thing once upon a time, and the whole point of doing this daily blog was to give me an incentive to work on the book every day.

Links

August 19th is the anniversary of Why The Lucky Stiff’s sudden withdrawal from the online Ruby community, and Glenn Vanderburg is organizing Whyday for this Aug 19th, as a day to “put your best practices away” and celebrate Why’s unique spirit and contributions by making something great and off the normal path. That sounds like a great idea.

The GitHub team has put up gitref.org, which is a short and clear reference to commonly used git commands (is it missing rebase, or am I going crazy?)

In the “been there, needed that” category, we have this little snippet from Jim Neath for determining an image’s orientation from paperclip.

A couple of Phusion Passenger links: from a couple of days ago, a response to an Igvita article about Rails performance and a preview of performance in the upcoming Passenger 3.

The first Safari extension I might actually use is Instapaper Beyond.

Filed under: Git, Paperclip, Passenger, Safari, why

May 25, 2010: Betas

Top Story

Beta 3 should be out today. The main change in this Beta is the inclusion of the Cucumber chapter, which has been updated both in terms of new tech, and also in terms of conclusions about how to use Cucumber.

And In Rails news…

When last we met, Rails 2.3.6 had just been released. Well, in the intervening 24 hours, we’ve bumped all the way to 2.3.8, with two bug fix releases, explained by Jeremy Kemper here and here. I don’t know why the patch releases weren’t numbered 2.3.6.1 and 2.3.6.2 — they’ve gone that route before. Anyway, enjoy.

History

This seems a good time to point to Mike Gunderloy’s historical list of Rails release dates. Confirming that Rails was pre 1.0 when I first saw it, was in the transition to 2.0 when I went to Pathfinder, and was in 2.0.2 when the Wrox book came out.

And then

I’m scheduled to be interviewed for the CoderPath podcast today, currently trying to confirm the time.

Here’s a call for combining RDoc and RSpec. Hmm… having used Python’s doctest, which is similar in goal, I’m skeptical. My sense was that the doctest things wound up being gunky enough that the file got hard to read.

Want to read Scott Chacon’s Pro Git book for free on your iPad? Sure you do.

This is a couple days old, but here’s Avdi Grimm with a nice little piece on Ruby’s Tempfile class.

The projects for the Ruby Summer of Code were announced. Looks like a good range of useful stuff.

Filed under: Git, Podcasts, Rails, RDoc, Ruby

May 14: Moving To Beta 3

Top Story

Just a quick update here.

Cucumber chapter newest draft is complete, and I’m hoping it will be beta 3 early next week. Not sure what to do next, I need to look around and see what’s relatively stable with respect to Rails 3.

The book is still on sale. Tell all your friends.

And then

Rails Dispatch this week is about the new routing in Rails 3.

Yehuda Katz has a really nice article on workflow with git.

A brief rant on Ruby 1.9 and encodings.

Finally

The excellent Dive Into HTML 5 book/site has a quick reference on how to detect all kinds of HTML 5 related browser behavior. I’m pretty sure I’ll be coming back to this page again.

Filed under: Cucumber, Git, HTML5, Rails 3, RailsRx, Yehuda

April 27, 2010, Now Writing About Cucumbers

Top Story

For me, the top story is still Rails Test Prescriptions on sale, and my discussion yesterday of the raffle for the old Lulu customers.

Book Status

Now re-doing the Cucumber chapter, which was written long enough ago that it didn’t consider tags. Cucumber has had approximately seventy-million releases in the interim, so there’s some writing to do. This is the first chapter where I’m adding Rails 3 setup instructions, which will eventually go everywhere in the book, of course.

Tab Dump

Have to say, RVM support in RubyMine is potentially really cool.

Kent Beck would like to analogize goat farming and software development. I’ve heard worse.

I know you all have been following this story closely, so you’ll be pleased to know that you can now bring your iPad into Israel with impunity. Again, carrying two of them with the roman numerals I to X as wallpaper.

Macworld has released an epub-formatted, iBooks compatible, user guide to the iPad.

Webrat bumped it’s version to 0.7.1.

I frequently complain that there’s no good visualizer for git repositories. This fork of GitX looks like it comes pretty close, though.

Finally

I’m pretty sure I disagree with some of this article by Josh Clayton talking about integration tests being more useful than unit tests. He’s probably right about integration tests being more useful for ultimate correctness, but that’s not everything that TDD is about. Unit tests are critical for the development process, and writing great code in the moment of development, and for supporting design changes and refactoring. Unit and integration tests have two complementary functions, just because they cover the same code doesn’t mean they are redundant.

Filed under: Cucumber, Git, iPad, Kent Beck, RailsRx, RubyMine, testing, Webrat

April 23, 2010: Still Alive

Top Story

If you think the top story is going to be anything other than the continued launch of Rails Test Prescriptions, well, you probably don’t know me very well. I may not be a marketing genius, but I do know the value of repetition. I mean, if there’s one thing I know, it’s the value of repetition.

Thanks to everybody who made yesterday fun: those of you who bought the book, those of you who blogged or tweeted about the announcement, and anybody who read this. And if you haven’t bought the book yet, well, I’ll repeat myself.

Tab Dump

A couple of quick ones here:

A ruby Mandlebrot set generator short enough to fit in a tweet.

Here’s a Ruby library to the TextCaptcha humane and accessible Captcha library. I really hate twisted image Captcha’s — the Wrox book even has a minimal implementation of this kind of problem-solving Captcha idea.

Git bisect is one of those things you’ll use about once every six months, but when you do, it’ll be totally amazing.

Sarah Allen has some comments on Shannon JJ Behrens testing talk. JJ and I worked together about — oy — ten years ago now, where he tried (and temporarily failed) to talk me into switching Python from Java. I find the idea that both of us are now talking about Ruby testing to be wildly funny.

Also, nobody seems to know exactly why Israel has banned the iPad, but Time magazine sees corruption.

Finally

Things that make me happy: Noted character actor William Atherton is interviewed in the Onion AV club, and had two great things to say about one of my favorite movies, Real Genius.

Anywhere I go in the world now, that movie is as popular most anywhere as Ghostbusters or the Die Hards. It’s amazing, and it has a constant following in college kids. It isn’t something that seems to age.

And:

They popped the popcorn for three months. There was a machine in the studio that did nothing all day long but pop popcorn…Then they took it way out to canyon country and a subdivision that was just being built, and they threw it into this house that they pulled down. It was real old-fashioned stuff. Now they’d do it digitally, I guess, but in those days, you had to pop the dang popcorn and put it in a truck and schlep it out to the valley.

And now I’m smiling.

Filed under: Fractal, Git, Lame Repetition Jokes, RailsRx, Real Genius, Ruby, testing

Rails Rx Standup: April 12, 2010

Top Story

For a while, it looked like the top story was going to be Apple’s new developer Rule 3.3.1, described here by John Gruber. More on that in a second.

But the real top story is the news that Twitter has bought Tweetie, intending to rebrand it as Twitter for iPhone, and dropping the price to a low, low, free. Eventually, it will be the core of Twitter for iPad. Wow.

Tweetie is probably the only case where I actually prefer the iPhone experience to the desktop experience, but I’d also be very sad if Tweetie for Mac was orphaned. (Not least because I just bought the MacHeist bundle in part as a way to get the Tweetie Mac beta sooner…). Later update: Tweetie developer Loren Brichter said on the MacHeist forum that the next Tweetie/Mac beta will come out.

I actually suspect that at least some of the existing iPhone Twitter clients will be able to continue — there’s clearly room in the ecosystem for apps that have much different opinions than Tweetie. It depends on how aggressive Twitter is planning to be. Dropping Tweetie’s price to free strikes me as agressive, although it may just be that the Twitter team is averse to direct ways of making money.

As for the Apple story, it’s a familiar space. Apple does something — in this case, blocking apps not originally written in C, C++, or Objective-C — that might have a reasonable user or branding component (keeping the iPhone platform free of least-common-denominator cross-platform apps) and taking it just too far for users or developers to be comfortable with it. That’s, of course, an understatement, as a lot of developers are really angry. Gruber’s point about the Kindle apps is good (and was later cited by Steve Jobs), but on the whole, I think this is a bit to far for Apple, or maybe I’m just upset that that the door seems to have been slammed on MacRuby apps for iPhone ever being feasible.

Book Update

Still working on the Webrat/Capybara chapter. Describing two tools that are so similar is really challenging for me — when there’s a difference, keeping it clear which tool is under discussion.

Also I’ve got the probability that I’ll have an article in an upcoming issue of the Pragmatic Magazine. This will probably be based on material from the book, but edited to fit the magazine article format. Probably either factory tools or mocks. Or maybe Ajax testing. Haven’t decided yet.

Tab Dump

Don’t think I’ve mentioned this yet, but here is a cool presentation of RSpec tricks. Some of these don’t work in RSpec 2, though.

While we’re on the presentation kick, here’s a nice intro to Git from James Edward Gray.

If you’ve ever tried to deploy Agile in a hostile environment, then the recent This American Life episode about the General Motors/Toyota NUMMI plant will resonate for you.

And Finally

A comparison of a boatload of Ruby test frameworks, being used in Iron Ruby to test some .NET code. I admit that I was not familiar with all the frameworks used here.

Filed under: Agile, Apple, Git, RSpec, standup, testing, This American Life, Twitter

Fixing the Heroku "Too many authentication failures for git" problem

Getting an error like this when you push to Heroku?

electricsheep:herokuapp look$ git push heroku master
Received disconnect from 75.101.163.44: 2: Too many authentication failures for git
fatal: The remote end hung up unexpectedly

If you like to create an ssh key for each server you use, you run this risk.

The reason is that unless you specify which key to use for a host, ssh-agent sends each key in turn until one works. However some server configure sshd to reject connections after too many attempted logins. For example, Dreamhost does this (see Dealing with SSH’s key spam problem for details). This is especially annoying if you weren’t even planning to use key-based authentication (as is the case on Heroku).

You can fix this by setting IdentitiesOnly yes in your ~/.ssh/config file. You can do this on a host-by-host basis.

host foobar.dreamhost.com        
        IdentitiesOnly yes

Heroku is a bit difficult to do this for because they don’t have a single IP address or domain (that I know of) you can configure this for.

As a workaround, clear your identities:

ssh-add -D

(Thanks to my friend McClain for his help with the ssh-add command.)

Fixing the Heroku "Too many authentication failures for git" problem

        Getting an error like this when you push to Heroku?
electricsheep:herokuapp look$ git push heroku master
Received disconnect from 75.101.163.44: 2: Too many authentication failures for git
fatal: The remote end hung up unexpectedly
If you like to create an ssh key for each server you use, you run this risk.


The reason is that unless you specify which key to use for a host, ssh-agent sends each key in turn until one works. However some server configure sshd to reject connections after too many attempted logins. For example, Dreamhost does this (see <a href="http://adterrasperaspera.com/blog/2009/03/15/dealing-with-sshs-key-spam-problem">Dealing with <span class="caps">SSH</span>’s key spam problem</a> for details). This is especially annoying if you weren’t even planning to use key-based authentication (as is the case on Heroku).


You can fix this by setting <code>IdentitiesOnly yes</code> in your <code>~/.ssh/config</code> file. You can do this on a host-by-host basis.
host foobar.dreamhost.com        
        IdentitiesOnly 
Continue reading "Fixing the Heroku "Too many authentication failures for git" problem"

Oh My Zsh gets theme support

I just pushed a small change to Oh My Zsh, which gives it rudimentary support for themes. What I’m hoping to do is collect prompts from tons of people and make it simple for others to find a PROMPT that works well for them.

robbyrussell's oh-my-zsh at 2c9f74b5c3f6910e7c66601008e9ddd0444b70c7 - GitHub
As of right now, there are only three for you to choose from. So, please head over to github, <a href="http://github.com/robbyrussell/oh-my-zsh/">fork Oh My Zsh</a>, add your theme, and send a pull request. :-)
zsh /Users/robbyrussell/Projects/development/planetargon/brainstorm 2014 zsh
Once I get it merged in, we&#8217;ll get a screenshot of it added to the Oh My Zsh wiki. (<a href="http://wiki.github.com/robbyrussell/oh-my-zsh/themes">see themes</a>)


<p>I know that many of you have some really sweet prompts configured as I got a lot of response with my post, <a href="http://www.robbyonrails.com/articles/2009/02/13/show-me-your-and-ill-show-you-mine-terminal-prompts-with-git-branches" title="terminal prompts with git branches">Show me your and I&#8217;ll show you mine</a>.</p><div class="feedflare">