As you can see below I have added the social bookmarks buttons at the bottom of each article. The buttons are for the following sites.
The links will direct you to their widget page.
The code to add these buttons is:
Notice that the one for technorati is special. I have not found exactly what I wanted. It favorites the blog itself not only the article. Therefore, this part of the code is not suitable for your blog ! You need to adapt it. For the other links they should work as such on your blog.
If your blog engine is Typo simply add the previous code to /themes/your_theme/views/articles/read.html.erb, typically after the line :
<%= render :partial => 'article', :object => @article %>
And you which social bookmarking websites do you use ?
Why is GIT so interesting ?
With git, I have been doing some gardening these days. Indeed I growed trees, cut branches, grafted branches.
I have been using a Version Control System (VCS) only for one year. That is about since I started the Thinkosphere project. I have been using SVN. At first I was like “Hey this is so cool”. SVN is a real time machine or at least a past time machine. You can easily go back in time to get the state of your source code from months ago. Unfortunately you cannot go forward to the future (with GIT you will be somehow able to do that !).
So after the honeymoon with svn, I began to find some limitations. Mainly I was missing an easy way to have two repositories talking to each other. Let’s see why. Here is a concrete example of how a Distributed Version Control System (DVCS) can be useful. This blog is powered by Typo which is open source. I downloaded the source code and I put it into a repository of mine to be able to make some minor changes (for instance these ones). But doing this I lost the connection with the original repo. That means I cannot easily upload my changes to the “main” repo neither can I go forward in time by downloading the last changes on the main repo.
This is exactly the kind of situation which git was designed for. Indeed with git the various repos can easily communicate with each other. So I can merge the latest updates from the main repo to my own local repo.
Let us see the setup of such a configuration in details. I will not use the example of this blog because it is still theoretical as I have not migrated it to git yet. Instead, I will use the exact configuration I am using to contribute to Open Flash Chart plugin and its test app.
Notice the setup is well explained in the excellent GIT User’s Manual at this chapter from which I am taking the following graph:
you push your personal repo ------------------> your public repo ^ | | | | you pull | they pull | | | | | they push V their public repo <------------------- their repo
Let us go over the steps. Imagine you want to download OFC test app, you want to make your own modifications while being able to regularly download the updates and you also want to upload your changes.
For the configuration resulting from the following tutorial, I can precise this:
- your personal repo = local repo = repo on your computer = repo in your working copy
- your public repo = repo on github, mine is here
- their repo = repo on PullMonkey’s computer
- their public repo = ‘official’ repo = repo on PullMonkey’s github
Let me precise also some GIT Vocabulary :
- To upload your changes from a repo to a repo is to push.
- To download your changes to a repo from a repo is to pull (to be precise pull fetches the changes and merge them to the current branch).
- To upload your changes from your working copy (or working tree) to your repo is to commit.
- To download changes from your repo to your working copy is to checkout (checkout command is also a simple command to switch between branches).
- Downloading a repo to create a repo : clone.
First, your fork the public repo to a public repo of yours:
You go there you click on fork. (you will need a github account)
Then you download (clone) your repo to your local repo :
git clone git://github.com/pullmonkey/ofc_test_app.git
(It both creates the repo and checks it out)
Now you make some changes. You commit them:
git commit -a -m "my changes"
You want to upload your changes to your public repo:
You want them to take into account your changes. You send them a pull request through email or github.
They agree to try it, they pull from your repo to their repo. They love it. They push it to their public repo.
They also made some more changes. You want to get them.
The first time you need to add the address of the public repo:
git remote add their_public_repo email@example.com:pullmonkey/ofc_test_app.git
Then, here is the GIT’s beauty, you pushed to a repo but you pull from another repo:
git pull their_public_repo
You can add as many repos as you want. You can see all these repos from a part of the global tree of the application development. Each repo is a tree branch. More than that each repo can contain several branches. Each branch can have a purpose: development, test, release etc. So have a happy gardening and happy time travels with git !
Any mistake, any problem or everything works ? Leave a comment !
As I am a private pilot, all this push/pull stuff made me think about the push/pull aircraft :
Notice it has two propellers aligned with the fuselage one to pull and one to push.
On October 24th, David Lowenfels aka dfl added the beginning of a test app in OFC plugin. As I had myself a local test app used to play around with OFC I thought it would be nice to add my test code in the OFC plugin. This code is actually made mainly by Charlie’s examples taken from his blog and my own examples.
A test app would be useful for 2 main reasons. The first one, as it says, is for testing purposes. The recent changes brought to OFC plugin were great but they were lacking some tests (functional tests and backward compatibility tests). So more tests are definitely necessary. The other reason which is almost more important is the need for working examples. The examples exist on Charlie’s blog and they are very helpful. As they exist why not gather them in an example app ? The examples will be yet more useful and clear.
So first, I worked directly on the app put by dfl in the test directory. But quickly I found it weird to have an application inside a plugin and using this plugin with the application inside etc. You get the kind of recursive situation (not as bad as it seems though!). So I proposed to Charlie to simply make a side test app. For now, the app is here in my repo on github but as it is more natural to put it close to the OFC plugin, Charlie will fork it and the “official” repo will be on his github repo probably here [EDIT: this is done].
[EDIT] If you also have your own OFC test app, and you want to contribute, have a look at this post explaining how to do it with GIT.
Taken from the README :
Both a testing and tutorial application for Rails Open Flash Chart Plugin.
1) Install with:
git clone git://github.com/harryseldon/ofc_test_app.git
EDIT PullMonkey’s version not up to date.
git clone git://github.com/pullmonkey/ofc_test_app.git
2) Run your server:
script/server -p 3000
EDIT 3/9/2009 This app is running live here.
All your comments on how to test a Rails plugin are welcome.
Yesterday, I needed a scatter line chart for my project. I saw that my current version of OFC did not do it. However, I saw that a new version that has the feature had come out : OFC version 2 Gamera. Looking at pullmonkey’s blog, there was nothing new so I was afraid the update was not made yet. Another look, this time directly on github and good news Charlie had updated OFC2 plugin. To be precise, last commit says “open flash chart gamera not tested yet, but available for those that want to try it out”. So let’s try out the part that interests me: the scatter line chart. I am directly translating this example from Teethgrinder just like I had done for another OFC example.
Then, here is the controller (test_it_controller.rb). You still have the original php code (and I still hate the $ sign before every variable).
class TestItController < ApplicationController def index_scatterline @graph = open_flash_chart_object(600,300,"/test_it/graph_code_scatterline") end def graph_code_scatterline # based on this example - http://teethgrinder.co.uk/open-flash-chart-2/scatter-line-chart.php #$chart = new open_flash_chart(); chart =OpenFlashChart.new #$title = new title( date("D M d Y") ); title = Title.new(Date.today.to_s) #$chart->set_title( $title ); chart.set_title(title) #$s = new scatter_line( '#FFD600', 3 ); scatter_line = ScatterLine.new( '#FFD600', 3 ) #$v = array(); v = Array.new #$x = 0.0; x = 0 #$y = 0; y = 0 #do while x < 25 # $v = new scatter_value( $x, $y ); v.push(ScatterValue.new(x,y)) # // move up or down in Y axis: # $y += rand(-20, 20)/10; y += (-1+2*rand)*2 # if( $y > 10 ) # $y = 10; if y>10 y=10 end # if( $y < -10 ) # $y = -10; if y<-10 y=-10 end # $x += rand(5, 15)/10; x += (5+10*rand)/10 #while( $x < 25 ); end #$s->set_values( $v ); scatter_line.set_values(v) #$chart->add_element( $s ); chart.add_element(scatter_line) #$x = new x_axis(); x_axis = XAxis.new #$x->set_range( 0, 25 ); x_axis.set_range(0,25) #$chart->set_x_axis( $x ); chart.x_axis = x_axis #$y = new x_axis(); y_axis = YAxis.new #$y->set_range( -10, 10 ); y_axis.set_range( -10, 10 ) #$chart->add_y_axis( $y ); chart.y_axis = y_axis #echo $chart->toPrettyString(); render :text => chart.to_s end end
The view code is as simple as usual (index_scatterline.hml.erb):
You can check out here the graph that is made. The graph is randomly generated so if you refresh it, it is normal that it changes. As a bonus you notice this graph looks like a stock market chart (hum is stock market random? I will need another post to explain that. Until then use your common sense).
class TestItController < ApplicationController def index_js_4 end end
Here is a quick tuto to setup a repository with svn on an online host assuming a ssh connexion. We will use the command line as you will probably need to use it to work on your remote server.
Your local source code is in /home/localaccount/myapp
Your remote space is on /home/remoteaccount/www/
Let’s create the repository directory on your remote account :
cd /home/remoteaccount/www mkdir svn cd svn mkdir myapp
Now, we tell svn to make this directory a repository:
svnadmin create –fs-type fsfs ./myapp
As a good practice, we will create the usual branches, tags, and trunk subdirectories in the repository.
First we create a directory structure :
cd /home/remoteaccount/www/ mkdir structure cd structure mkdir branches tags trunk
Now we import the structure:
svn import /home/remoteaccount/www/structure/. file:///home/remoteaccount/www/svn/myapp –message ‘Initial repository layout’
Finally we import the source code:
Run this command on our local account:
cd /home/localaccount/ svn import /home/localaccount/myapp/. svn+ssh://firstname.lastname@example.org/home/remoteaccount/www/svn/myapp/trunk –message "initial import"
(do not forget the /trunk/) If you have a ssh properly setup with rsa key you won’t have to type any password.
I find this tuto quite hostile but my point is to use the command line. In general, I use a GUI (subclipse) but the only case where I have to actually type svn commands is when I setup a repo on my remote server. Maybe you are in the same case !