Guaranteed Success March 26th, 2008
Taken from an email written by a good friend of mine about the number of downloads for our open source social network platform, Lovd By Less:
Talking to you on Thursday it was obvious that you were genuinely surprised by the success of LovdByLess. The fact that you were surprised is shocking to me. Take the single-most sought out feature in one of the hottest languages of today and have one of the best Rails shops in the country build the functionality, design the site, and bundle it all together for no cost.
Obviously flattering, but from our perspective very far from the mark. We have been genuinely surprised by the number of people who have tried, downloaded and contributed code back to Lovd. There is no guarantee of success. We had an interesting idea have executed well.
Our recipe for success is:- Have a good idea.
- Work really, really hard.
- Be lucky.
We have been blessed with a lot of good ideas, a really strong work ethic, the ability to see what’s important and stick to it, very understanding families, and luck. Our parents have always supported our careers and have guided, mentored and inspired us. We have occasionally been called arrogant or self-promoting, but truly what we have is a fear of failure. We self-promote because we don’t have any expectation that someone will do it for us. We succeed or our families don’t eat. Just like the rest of you.
Last year I worked over 4000 hours. This year I am trying to keep the number close to 3000.
We work hard. We participate in open source. We blog a lot. We write and act honestly. We try to make things easy for our users and ourselves. Any measure of success that we have or will have comes from these things. We don’t expect to succeed. We just keep trying.
And we are grateful. We are overjoyed that people enjoy our opinions enough to read and subscribe to our blog. That people like our work enough to use our products and ask us to work on their products. That people download our software and contribute back.
Thank you all for allowing us to share ourselves with you. And while we don’t expect it, we do appreciate it.
Got Git? HOWTO git and github March 25th, 2008
Background:
Last week we released the open source social network Lovd By Less. Almost immediately we had requests for people wanting to add code back into Lovd. Lovd had been housed in a private svn repository and distributed via a zip file. This was really good for me, but not so for people that want to take the current version, build on it and later merge whatever newer version of Lovd is available into their app. Although I hadn’t yet tried git I knew that it made this sort of branching a lot easier than subversion, so I decided to try it.
Getting started with Github:
Github is the new cool git repository website (social network for geeks). I asked a friend for an invite and got started. Creating a github account and repository is really easy. The instructions are well laid out. The last step is to export your svn repo into the git directory and then commit and push. I’ve been told that if anyone needs a git invite to let me know and I’ll be given invites to send out. So let me know.
Now what?
So now I had my git repo setup on github and I started sending out the repo’s public address. And before I know it I had my first patch. Now what? I read Dr. Nic’s blog post about git when it came out, so I went back and read it again. After reading a few times I realized two things: (1) That git is very complicated and (2) Dr. Nic is a way bigger StarWars geek than I ever gave him credit for. I called my friend Josh Owens (of the Web 2.0 Show) and asked for some help. Josh talked me through my first merge and push, but I still didn’t quite get it. The next day I was trying to merge another patch (branch) and since Josh wasn’t around I went into #github where Tom Preston-Werner (mojombo) helped sort me out quite a bit.
Disclaimer:
I am still new at git so I may have things wrong, so if you find an error or omission, please say so in the comments.
Git explained (I think):
Understatement: Git is very different from Subversion. Git is a distributed source control system, which means you can work disconnected from the main repo (branch) and still commit. But you commit to your local repo (branch). The basic flow is (some crucial steps have been left out for now. I’ll fill those in later. Don’t use the following as a step by step guide, that comes later):
- git clone. This basically tells your local git to go out an pull the files from the server.
- Make your changes.
- git commit. This commits your files to your LOCAL repository, not the one on the server.
- git push. This “pushes” you committed changes up to the server.
OK, so far so good. This feels a lot like svn. So much that it’s time to get overconfident and think we get git. But we don’t. And our confidence is about to be shaken like a dry martini.
But I have my own repo and people are trying to commit to me. What do I do, how does that work?
You are the master:
In git everything revolves around branches (github calls them forks1). When you create a git repo, that main branch is called “master.” Your master branch is kind of like what trunk is in svn. When someone wants to fork/branch your master, they go to your page in github and click the fork button. Now they have a fork/branch of your master branch. When they are ready for you to check out their changes and merge theirs back into your master they’ll send you a message via git hub. You’ll get this message in your inbox and have no idea what to do with it. Cool.
The first thing to notice is that the url for their branch looks a lot like the url to your master. My “public clone url” is git://github.com/stevenbristol/lovd-by-less.git. Dr. Nic’s looks like this: git://github.com/drnic/lovd-by-less.git. The similarities matter.
To get Dr. Nic’s branch and merge it into my master I do the following (let’s assume I have my master cloned to /lovd):
NOTE: Put the contents of this pastie in the top of your ~/.bash_profile file to see which branch you are currently working in. This is demonstrated in the examples below. The part in parens is the branch. (Another version of the same thing.) (After changing your ~/.bash_profile file you’ll either have to restart terminal or source the file to see the changes.)
- /luvd(master) $ git remote add drnic git://github.com/drnic/lovd-by-less.git
- /luvd(master) $ git pull
- /luvd(master) $ git checkout -b drnic/master
- /luvd(drnic/master) $ git pull drnic master
- [look at the files, rake, test, etc]
- /luvd(drnic/master) $ git status
- /luvd(drnic/master) $ git checkout master
- /luvd(master) $ git merge drnic/master
- /luvd(master) $ git status
- /luvd(master) $ git commit -a
- /luvd(master) $ git push
- Step 1 tells my local git repo to add a new remote repository. This means that the same repo can pull and push to two different server2. There is nothing analogous in svn. The syntax is “git remote add {name} {url}.” I am naming this remote “drnic,” because I am going to pull his branch.
- Step 2 simply pulls my local master. This is like doing an svn up. I do this because I gave commit rights to someone else and I want to make sure I have the latest changes in my local master. Step 4 also does a pull, but there we have to specify where we are pulling from. Here it defaults to the “origin,” which is my git master on github.
- Step 3 is a bit confusing because I am not doing anything like an svn checkout. A git checkout basically changes the branch I am working with. The -b switch means to create the new branch3. Notice that in steps 1 -3 I was in branch master (master) but after I “git checkout drnic/master” I am in branch drnic/master (drnic/master4). Get ready: Rather than have each branch in a different directory on the file system, all the branches live in the same directory. What? Exactly. Try this: Open Textmate and open a file that you know has changed between the two branches. Now go in to terminal and “git checkout {other branch}.” Go back to Textmate and notice that the file did actually change. What? Exactly. Isn’t this cool? But it means you must use the .bash_profile hack to know what branch you’re working in. Other wise you will go crazy. You can also do “git branch” which will tell you what branches are available locally and which one you are in.
- Step 4 just says pull all of the files from the remote repo named “drnic” (which we created in step 1) and the branch, in this case “master.” Syntax: “git pull {name of remote} {name of branch}.” This is kind of like an svn checkout.
- Step 6 shows which files have modifications. If you didn’t change anything then you can go on to step 7, otherwise you might have to git commit to your local branch of drnic’s branch of your master. (Don’t feel bad if you have to reread that a few times :)
- Step 7 puts us back in the context of our master branch.
- Step 8 merges the local drnic branch into our master branch.
- Step 10 commits all unadded files to the local master repo. Unadded? Yes, in git a file with local modifications needs to be added back into the repo for committing. You can do this with “git add {file}” or just git commit all the added and unadded files.
- Step 11 pushes your local changes back to your origin (master branch on github). Now other may fork/branch your master and start again. Easy right?
You just want to patch some else’s repo:
This is really simple. Here are the steps:
- Go to github and click the “fork” button.
- git clone git://github.com/stevenbristol/lovd-by-less.git
- cd lovd-by-less
- Make your cahnges
- git status
- git commit -a
- git push
- go back to git hub and click the “pull request” button.
- Step 1 will create you own fork of the repo where you can make your changes. Click this on the person’s page you want to fork from.
- Steps 2-7 you should understand by now. (I hope. :)
- Step 8 will send a message to the person notifing them that you have something for them to see. Click this from your repo page.
References:
- cheat git
- http://drnicwilliams.com/2008/02/03/using-git-within-a-team/
- http://github.com/guides/
- http://wiki.sourcemage.org/Git_Guide
- http://git.or.cz/gitwiki/QuickStart
Notes from Dr. Nic:
1 Technical not correct. “Within a repository/clone you can have branches. A fork is a clone of a repository. Its a conceptual thing.” He continues, “I could manually create a fork by cloning 1+ branches from a target repository, then push that repository to my own remote repository. At this stage, I’ve theoretically got a remote clone of your remote repo. “Forking” is a nice word for this.” This is how someone can take Lovd, put it in their own private repo, build their app on top of Lovd, and easily get the latest patches from Lovd into their new killer app.
2 “A “remote” repo and a “local” repo contain the same information about the commits etc. The difference is that a “local” repo has a checkout of one branch plus a .git folder containing all the commit info. The remote repo just contains the commit etc information, but no checkout (see “git checkout—bare” I think creates a remote repo that you could host on from your laptop’s ~/Sites folder for example.”
3 ””git checkout -b drnic/master” – I tend to use “local/drnic/master” now – using local/ as a namespace to separate it out from any clashes with the remote repo. I think this is different from my original blog post.”
4 “The -b switch means to create the new branch, based on the current branch.”
Everybody meet Lovd, Lovd meet Everybody March 17th, 2008
Last night, after many hours of labor we birthed Lovd. He entered the world around midnight. With 1201 lines of code and 940 words (not lines, words) of CSS. LovdbyLess is an open source social network, written on rails. You can adopt this infant piece of code and mature it into whatever social app you wish. We brought Lovd into the world because we saw a need for an open source social network. While we don’t believe that the world needs another social network, we do believe that most sites can benefit from some sort of social interaction, software is about communication after all. Now everyone has a platform they can write their application on without worrying about these details, you can concentrate on your app. We just want to help people get off on the right foot. We wrote LovdByLess for you.
Here are some of the features:
- Follow a user, mutual following is friending.
- User-to-User Messaging
- Profile Comments
- User Blogs with Comments
- Photo Gallery with Captions
- Site Search for Friends
- Profile Bio and Information
- User Dashboard (Recent Activity of Friends)
- Emailed Activity
- Flickr Integration
- YouTube Integration
Here is the Download link.
If you want to see the first website written on the Lovd platform, check out Imitate Life.