Showing posts with label git. Show all posts
Showing posts with label git. Show all posts
March 01, 2011
303
This is my last blog post here on blogger.com! You'll find my new thoughts, projects and development ramblings at http://dlinsin.github.com.
I migrated to blogger.com in late 2005 and was always quite happy with it. More than 5 years and exactly 502 posts later it's time to move on to something new.
Subscribe to my new blog feed, check my stuff on github or follow me on Twitter.
January 10, 2011
5 Star Rating
A couple of months ago we release our first own App "I think I spider" at Synyx. It features German quotes and sayings directly translated to English. It doesn't make much sense to a none-native German speaker, but believe me it's hilarious for us.
The App let's you rate those quotes with a 5 star rating, which is directly incorporated into a ranking. Up until today the component in charge of the ranking is a simple bunch of UIImageViews wired up with Interface Builder and set appropriately when tapped. That means if you want to give a 3 star rating, tapping on the 3rd UIImageView would fill up the 2 previous one as well. Same goes for changing your mind and going from a 5 to 3 star rating. The logic would unhighlight the 4th and 5th star.
Now, this works great and it certainly looks beautiful, but have you ever rated an App in the App Store on your iOS device? This is how it looks like:
Apple did a great job of just getting everything right with this small little control. The way you can slide your finger over it and the stars light up is just great. Also notice that if you want to reset the rating and go down to 0 stars, you need to swipe your finger all the way to the left. Note, that you can also touch slightly below the star, in order to see the stars above your fingers.
All those little details were the requirements for the next version of the rating feature of I think I spider. However, having some spare time over the holidays, I though I'd write a little component, which does all of that and more: DLStarRating. You can find the code on github, along with a sample project of how to use the stuff in your next App.
DLStarRating consists of a configurable number of custom UIButtons called DLStarView. They have a different background image for their normal and highlighted state. Those buttons are wrapped in a UIControl called DLStarRatingControl, which does all the touch handling. The buttons are centered in the DLStarRatingControl so keep that in mind when configuring its size.
It's quite easy to use DLStarRating in your code. You can wire it up in Interface Builder (although you won't be able to configure it from there) or in your UIViewController subclass:
To customize the stars, you can replace star.png and star_highlighted.png in the images folder under DLStarRating with your own. The only requirement is that the two images must have the same size.
If you discover any bugs or have a great idea you want implemented, open an issue on github or fork the project and help me out!
The App let's you rate those quotes with a 5 star rating, which is directly incorporated into a ranking. Up until today the component in charge of the ranking is a simple bunch of UIImageViews wired up with Interface Builder and set appropriately when tapped. That means if you want to give a 3 star rating, tapping on the 3rd UIImageView would fill up the 2 previous one as well. Same goes for changing your mind and going from a 5 to 3 star rating. The logic would unhighlight the 4th and 5th star.
Now, this works great and it certainly looks beautiful, but have you ever rated an App in the App Store on your iOS device? This is how it looks like:
Apple did a great job of just getting everything right with this small little control. The way you can slide your finger over it and the stars light up is just great. Also notice that if you want to reset the rating and go down to 0 stars, you need to swipe your finger all the way to the left. Note, that you can also touch slightly below the star, in order to see the stars above your fingers.
All those little details were the requirements for the next version of the rating feature of I think I spider. However, having some spare time over the holidays, I though I'd write a little component, which does all of that and more: DLStarRating. You can find the code on github, along with a sample project of how to use the stuff in your next App.
DLStarRating consists of a configurable number of custom UIButtons called DLStarView. They have a different background image for their normal and highlighted state. Those buttons are wrapped in a UIControl called DLStarRatingControl, which does all the touch handling. The buttons are centered in the DLStarRatingControl so keep that in mind when configuring its size.
It's quite easy to use DLStarRating in your code. You can wire it up in Interface Builder (although you won't be able to configure it from there) or in your UIViewController subclass:
To customize the stars, you can replace star.png and star_highlighted.png in the images folder under DLStarRating with your own. The only requirement is that the two images must have the same size.
If you discover any bugs or have a great idea you want implemented, open an issue on github or fork the project and help me out!
September 14, 2009
Git Svn
Last week I started working for my new company and like most of the IT businesses today, we are running subversion for Source Control Management (SCM). While we are still discussing, moving to a Distributed SCM (DSCM), I didn't want to lose the advantages of working with git. Remembering Samuel's talk at Java User Group Karlsruhe and with a hint from Ollie, I started using git-svn.
The git manual describes the svn capabilities as follows:
You can create a fully featured git repository from the trunk of a subversion repo with the following command:
The git repository, that you just created is hooked to the trunk, passed with URL in the command. To get the HEAD, just run:
Now you are ready to work with git, as if you had cloned a repo from GitHub. You can work with branches locally and commit your changes offline. When you want to share your work and push it back to subversion, you can use the following command:
You might ask yourself how to get the latest changes from your fellow developers? First, you should have no un-commited changes when you run:
The reason for that, is this command is similar to svn update. It uses git-rebase instead of git-merge, in order to preserves linear history.
Those couple of commands got me started in no time and I didn't have to wait for a company-wide repository in order to have all the advantages that come with git.
The git manual describes the svn capabilities as follows:
git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.
git svn can track a standard Subversion repository....Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command.
You can create a fully featured git repository from the trunk of a subversion repo with the following command:
git svn init -T https://svn.hostname.de/svn/projects/project/trunk
The git repository, that you just created is hooked to the trunk, passed with URL in the command. To get the HEAD, just run:
git svn fetch
Now you are ready to work with git, as if you had cloned a repo from GitHub. You can work with branches locally and commit your changes offline. When you want to share your work and push it back to subversion, you can use the following command:
git svn dcommit
You might ask yourself how to get the latest changes from your fellow developers? First, you should have no un-commited changes when you run:
git svn rebase
The reason for that, is this command is similar to svn update. It uses git-rebase instead of git-merge, in order to preserves linear history.
Those couple of commands got me started in no time and I didn't have to wait for a company-wide repository in order to have all the advantages that come with git.
July 29, 2009
Git Stash
After a great talk on Git at the Java User Group Karlsruhe and a couple of other experiences, I started to really dig the Distributed Source Control Management (DSCM) notion and its advantages. A neat and quite helpful feature of Git is stashing.
The Git manual has as an exceptionally helpful description of stashing. They call it "Temporarily setting aside work in progress".
Git's stashing feature saved me quite some trouble a couple of days ago, while working on a side project. I developed a feature on branch "B" and had quite a big change-set, while someone found a bug on the stable branch, let's call it "A".
Coming from SVN, I thought I had to check-in my changes in order to switch to Branch "A" and fix the bug. That's quite ugly, because it screws with your history of commits and even might break your builds. I know that there are other possibilities with SVN, like copying your changed files or creating a patch file. However, to me those all look like workarounds rather than solutions.
So I simply stashed my changes from branch "B" and got a clean branch with HEAD. I switched to branch "A" and was able to fix and commit the bug. After switching to branch "B" again, I simply poped the changes from the stash, as if I had never stopped working on the feature.
After working with Git for some time, I would really recommend people to switch to a DSCM. I'm not alone with this. SpringSource's DM server team migrated their repositories to Git a couple of weeks ago and they didn't hear any complaints from the community. No matter if you choose Git or Mercurial, the advantages of a DSCM really outweigh the initial costs of getting started.
The Git manual has as an exceptionally helpful description of stashing. They call it "Temporarily setting aside work in progress".
While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. You would like to fix it before continuing. You can use git-stash(1) to save the current state of your work, and after fixing the bug (or, optionally after doing so on a different branch and then coming back), unstash the work-in-progress changes.
$ git stash save "work in progress for foo feature"
This command will save your changes away to the stash, and reset your working tree and the index to match the tip of your current branch. Then you can make your fix as usual.
... edit and test ...
$ git commit -a -m "blorpl: typofix"
After that, you can go back to what you were working on with git stash pop:
$ git stash pop
Git's stashing feature saved me quite some trouble a couple of days ago, while working on a side project. I developed a feature on branch "B" and had quite a big change-set, while someone found a bug on the stable branch, let's call it "A".
Coming from SVN, I thought I had to check-in my changes in order to switch to Branch "A" and fix the bug. That's quite ugly, because it screws with your history of commits and even might break your builds. I know that there are other possibilities with SVN, like copying your changed files or creating a patch file. However, to me those all look like workarounds rather than solutions.
So I simply stashed my changes from branch "B" and got a clean branch with HEAD. I switched to branch "A" and was able to fix and commit the bug. After switching to branch "B" again, I simply poped the changes from the stash, as if I had never stopped working on the feature.
After working with Git for some time, I would really recommend people to switch to a DSCM. I'm not alone with this. SpringSource's DM server team migrated their repositories to Git a couple of weeks ago and they didn't hear any complaints from the community. No matter if you choose Git or Mercurial, the advantages of a DSCM really outweigh the initial costs of getting started.
June 15, 2009
Git talk @ JUG-Ka
This coming Wednesday Samuel Mellert (1&1 Internet AG) is going talk about "Distributed SCM with Git" at the Java User Group Karlsruhe. I'm a newbie when it comes to distributed version control and especially Git, that's why I'm really looking forward to this meet-up. The talk starts at 7:15pm and takes place at University of Karlsruhe.JetBrains and ZeroTurnaround are each giving away a free license for their products. We are gonna have a lottery, so if you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.
To get the latest updates of the JUG-Ka sign up for our Google Group or join us on XING.
June 08, 2009
Git(Hub) Pain
This is a little bit of a rant post, so if you are not interested in my subjective experience with GitHub, you should stop reading now.
A couple of weeks ago I started playing with Git. First of all, I love the notion of distributed version control, although it took me a while to wrap my head around it.
I found it quite hard to explain Git or distributed version control in general. The best explanation I heard so far comes from Joel Spolsky, who talked about it on the stackoverflow podcast. It goes something like this:
I have a little side-project with 2 other developers and we decided to use Git as our version control system. One of the reasons why we choose Git, was the limitations we saw in our daily work with SVN and the more important reason - isn't it just cool to try something new?
One way to let others participate in your development, is to have a repository on GitHub. Others can come in and get a local copy of your work, contribute to it and merge it back into your original source tree later on. Everything is accessible and essentially open source. However, if you pay GitHub some money, you can have private repositories with contributors - that's what we did.
The move from SVN to Git wasn't easy. We had to adopt our style of working with version control, because we ran into trouble pretty early. I guess we first needed to grok the mindset of branching and merging, before we could really leverage the advantages of distributed version control.
Unfortunately GitHub didn't help getting started. I don't know if it's because of broken tools or if it was GitHub's fault, but we managed to damage one of our branches. When I tried to pull from the branch I got the following error message:
Since I couldn't find clear information on the problem, I decided to open an issue with GitHub support. Unfortunately after almost a week, I got a reply to my issue which was more than disappointing:
I mean seriously? Is that the best they can do? Sure, it's the easiest way out for GitHub, but not the most customer friendliest way I can imagine. It's just so disappointing, because I like GitHub and I have no problem to pay for their service. In fact, I guess I would have paid them anyways, because they have a great product and deserve some support. I just don't like this kind of "Have you tried turning it off and on again?" - attitude.
However, even after all the trouble we had, I'm still glad we choose Git. I think distributed source control is the future and I would suggest anybody to have a look at it, before starting the next project with SVN.
A couple of weeks ago I started playing with Git. First of all, I love the notion of distributed version control, although it took me a while to wrap my head around it.
Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
I found it quite hard to explain Git or distributed version control in general. The best explanation I heard so far comes from Joel Spolsky, who talked about it on the stackoverflow podcast. It goes something like this:
You are working on a local clone of the full repository and a commit is basically a set of changes applied to a version of that repository.
I have a little side-project with 2 other developers and we decided to use Git as our version control system. One of the reasons why we choose Git, was the limitations we saw in our daily work with SVN and the more important reason - isn't it just cool to try something new?
One way to let others participate in your development, is to have a repository on GitHub. Others can come in and get a local copy of your work, contribute to it and merge it back into your original source tree later on. Everything is accessible and essentially open source. However, if you pay GitHub some money, you can have private repositories with contributors - that's what we did.
The move from SVN to Git wasn't easy. We had to adopt our style of working with version control, because we ran into trouble pretty early. I guess we first needed to grok the mindset of branching and merging, before we could really leverage the advantages of distributed version control.
Unfortunately GitHub didn't help getting started. I don't know if it's because of broken tools or if it was GitHub's fault, but we managed to damage one of our branches. When I tried to pull from the branch I got the following error message:
crusty:doublemill dlinsin$ git pull origin master
error: Could not read 9b82bba67693db3b47189aefea07ec4e1d7be38e
fatal: bad tree object 9b82bba67693db3b47189aefea07ec4e1d7be38e
remote: Counting objects: 13, done. remote: Compressing objects: 100% (8/8), done.
error: waitpid (async) failed
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side.
remote: Total 8 (delta 0), reused 0 (delta 0)
remote: aborting due to possible repository corruption on the remote side.
Unpacking objects: 100% (8/8), done.
error: waitpid (async) failed fatal: error in sideband demultiplexer
Since I couldn't find clear information on the problem, I decided to open an issue with GitHub support. Unfortunately after almost a week, I got a reply to my issue which was more than disappointing:
The best thing to do would be to delete the repository and recreate it with a fresh git push.
I mean seriously? Is that the best they can do? Sure, it's the easiest way out for GitHub, but not the most customer friendliest way I can imagine. It's just so disappointing, because I like GitHub and I have no problem to pay for their service. In fact, I guess I would have paid them anyways, because they have a great product and deserve some support. I just don't like this kind of "Have you tried turning it off and on again?" - attitude.
However, even after all the trouble we had, I'm still glad we choose Git. I think distributed source control is the future and I would suggest anybody to have a look at it, before starting the next project with SVN.
