Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Merge branch 'master' of

  • Loading branch information...
commit 8913f43ea82adb75e8e25a89fc04887a59f73074 2 parents 6b04b9b + 46aa00f
@jmejia jmejia authored
16 source/projects/binary_search_tree.markdown
@@ -19,13 +19,19 @@ A binary tree is built from *nodes*. Each node has:
Build a binary search tree which can:
+* `insert` a new unique value into the tree
+* verify/reject the presence of a value in the tree with `include?`
+* report the depth of a node in the tree with `depth_of`
+* find the `maximum` value in the tree
+* find the `minimum` value in the tree
+* implement a `sort` that outputs an array of the values in sorted order (by traversing the tree, not using Ruby's sort method)
+As the final challenge, add the ability to `delete` a value from the tree and repair the tree.
+Beyond your tests, data should come in and go out using files:
* import data from a file with one value per line (values are unique within the input)
-* output a reasonable visual representation of the tree out to the terminal
-* verify/reject the presence of a value in the tree
-* find the maximum value in the tree
-* find the minimum value in the tree
* output a file, similar to the input file, with the values in ascending order
-* delete a value from the tree and repair the tree
## Extensions
2  source/projects/eventmanager.markdown
@@ -1,4 +1,4 @@
-Iteration 3---
layout: page
title: EventManager
sidebar: true
2  source/projects/little_shop.markdown
@@ -48,6 +48,8 @@ You should not write code or migrations until a story calls for it.
Teams will meet with the product owner regularly and demo completed stories. The product owner will request additional features at each meeting and those stories should be completed prior to your next meeting. Project scope and requirements can change at the discretion of the product owner so following an agile approach is really important.
+It is expected that teams will have meaningful discussions and code reviews using comments on Github. Your instructors will be looking for this. Commits should also have meaningful messages. If you have commits that say things like "Fixing hound complaints.", you will likely be asked to [squash]( those commits. Rebasing should be done _before_ the branch is merged into master or you will run into problems.
The master branch of your project should always remain in a state where it can demoed and deployed... yes, even days that you don't have any _planned_ meetings.
Everyone will provide feedback for group members at the end of the project.
Please sign in to comment.
Something went wrong with that request. Please try again.