Ted is a project mainly written in JAVA and PHP, it's free.
ted can find episodes of any TV show you like to watch
Check-out the sources from GitHub:
$ git clone git://github.com/ted/ted.gitCurrently to build ted, both ant and maven are required:
$ cd ted/ted-api
$ mvn
$ cd ..
$ antTed can be run from eclipse by following these steps:
TED_LIB_DIR to point to the newly
created lib directory in ted.ted-server from inside eclipse running the nu.ted.Server class.
This will start the server running on localhost port 9030. Any client written
using the ted.thrift API should be able to talk to the service on this port.Or what in the world I'm talking about.
In Ted there is a back-end domain model. This is the data that will be persisted between restarts of the ted-server. When possible they will use the simplest and shortest names for an item:
The ted project is currently hosted in GitHub. If you have a GitHub account and would like to contribute we recommend you fork this repository. If you just want the latest source you can clone from: git://github.com/ted/ted.git.
For developers that are using GitHub, this is some information that may make it easier to submit changes and keep in sync.
First you have to know about remotes. A remote is simply a remote repository. Where non-distributed VCS use one remote, Git allows you to have any number. So changes can be pushed and pulled from/to many different locations. To keep it simple(er) here we're just going to use two. We'll get into them in a minute.
We're going to create a Fork of the main git repository. With Git everyone has
all the source, and anyone can create a fork. So if you decide you can write a
better ted, do so, and people may start forking your repository instead of the
ted/ted repository. To fork the main repository log in to GitHub and browse to
http://github.com/ted/ted. Click the 'Fork' button. After a slight delay you'll
end up with your own
This
Next we'll clone the
$ git clone [email protected]:<username>/ted.gitAfter creating a local copy of the source Git will setup the first remote. This
remote will be called 'origin' and will point back to
To make keeping up to date with ted/ted and changes from other developers we'll next add a remote that points back to that repository. To do this run:
$ git remote add upstream git://github.com/ted/ted.git
$ git fetch upstreamNow there are a lot of ways you could go from here depending on your Git experience. We'll explain one workflow, but feel free follow your own. As long as we get a patch from you, we don't care how your repository looks.
Branch-per-feature:
For this workflow we're going to keep
Update Master:
$ git checkout master
$ git pull upstream master
$ git push origin masterTo write a feature (or fix a bug), do the following:
Doing Work:
$ <do 'Update Master'>
$ git checkout -b <branchname>
Loop:
$ <work>
$ git add <changed file>
$ git add <changed file>
$ git commit
$ git push origin <branchname>Do the work loop as many times as makes sense. You can also amend patches, or
squash some together, or whatever else. When ready to publish that branch to the
outside work the last command will push it to
When the pull request is accepted and your patches included in the ted/ted
repository you may delete your local branch. The commits in your local branch
will be slightly different from the commits added to the ted/ted repository
because the ted/ted branches were committed at a different time (likely by a
different person). Don't worry, you'll still be listed as the author on any
patches you send. To delete the branch at
$ git push origin :<branchname>While working in this branch you find changes made to ted/ted/master that you would like to include in your branch. There are a couple ways to do this. Here we will show the way to do it rewriting history. This is not what you'd normally want to do on a published branch because other people could have commits that extend that branch. Do not do this if you've sent a 'Pull Request', or at least send a message asking us to abort the pull.
Rewrite history to move changes ahead:
$ <do 'Update Master'>
$ git checkout <branchanme>
$ git rebase master
-- may have to fix commits here if there's conflicts
$ git push -f origin <branchname>The reason we're showing a rewrite of history instead of doing a merge is because if you find a conflict in the rebase you can fix that one commit and keep a linear history, whereas if you find a conflict in the merge the fix will instead be included in the merge commit. The '-f' to the push will force this push to happen, even though it rewrites history.
Either way, moving a branch will hopefully be a rare occurrence. If kept small we should be able to pull in these branches and have them disappear quite often.
If you have any Git or GitHub questions please send me (KenMacD) a message on GitHub directly.
Quick list of jars pulled down by Ivy, and their license (current 6/10):