If you have known me for a while you're probably aware that I'm a frequent sufferer of headaches. I have even blogged about it here before. Having gone through another pretty bad week I decided I needed something which helps me get a better picture of my headaches. Whenever a headache strikes I want to be able to easily log its occurence and its strength.
I went in the direction of a very basic smartphone app. My phone is rarely very far away, and starting it up, opening the app and taking a measurement is a pretty fast and painless process. So it seemed like a natural solution.
I now have a basic app running, and in its current incarnation it looks like this:
Yeah, not very pretty, and full of debug info. But in bit of a return to the roots of this blog I wanted to actually write about this project as I'm developing it. Which means you'll get to see the nitty gritty details.
At this point the app is usable, I can collect the data on my computer, and I can visualize that data for inspection (I'll show more of that in future posts). There are a few more features on my wanted list, such as adding tags when logging headaches.
I have shared the code on Sourceforge for those who want to take a look. And in any case you'll be able to read more about my progress here soon.
9 comments:
Sounds interesting.
What technologies are you using? Also, why not Github? SF has had its best days unfortunately...
I'll talk about my choice of technologies in an upcoming post. I'm going to have to do that anyway so people can have some background when I start writing about technical details.
About SF: I'm very happy with it. At the moment SF feels like an old reliable friend, and I don't see the point of switching.
As for Git: I actually find it more confusing than just basic SVN. (Maybe you can share your Git-FU with me some day ? :-) )
Sure :-)
There is no benefit svn vs git if this is a one-mans project (besides maybe offline commits ... which is hardly a reason).
But the real benefit is for open source projects is the pull request mechanism. Take for example https://github.com/Activiti/Activiti/pulls, since we have this we have
1) way more contributions
2) way easier for us to incorporate patches into the project
But indeed, a live demonstration probably will convince you immediately ;-)
Mercurial is more user-friendly then Git and it's still a lot better then SVN. Local commits and branches is something I use all the time just to try out stuff. I think the question you should ask yourself isn't 'why switch?', but rather: 'why not?' :-)
@Randy: interesting! Do you have anything in particular in mind when you say it is more user-friendly than Git ?
This might be because I started out with Mercurial and only later 'learned' Git, but Mercurial behaves more like you expect:
- You have a tree of nodes. Each node contains a patch, has an associated branch name, commit message, etc. The only difference between a local copy and a remote copy is which nodes you have. You work with this tree by specifying a current node and working on top of this situation. Actions like branching, merging, grafting (cherry picking a single commit from a different branch) and rebasing (cutting part of a branch and pasting it somewhere else) can be easily 'visualized'. I suspect this is all similar to the way SVN works.
- In Git on the other hand branches are just a special kind of tag. Once you state that commit B is the 'development' branch, it's parent commit A no longer has an associated branch name. If during the development of a feature you merged other branches into your feature branch (which I think is considered not that good a practice, but okay), it becomes hard to see which commits are part of your feature branch and which are not. On top of that you will 'lose' commits constantly at first. If you currently are at commit B and want to continue working from it's parent commit A, the first reaction is to either checkout that commit or specify that the feature branch should be reset to that state. Both actions can remove the child commit B. The fact that branches are only a kind of tag also leads to so called 'remote branches': each branch exists multiple times on your local machine, once for your local branch and once for each server you pull from (so a commit can have the branch labels 'feat01' and 'origin/feat01'). All this leads to things like tracking branches and fast forward merges. Pfff :-|
All this being said: Git is generally considered better then Mercurial because it's more powerful in certain areas.
http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/
http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/
Interesting; thanks!
Main advantage for git over mercurial as I see it :
* Its staging area can be nice to have if you're in the habit of working on multiple things at once but want them in separate commits.
* Its automatic rename/move tracking, because it looks at the (blob) content instead of working with files.
Mercurial does have an easier workflow though, for simpler things and its 'mental model' is a lot cleaner I think.
A nice GUI for both Hg and git (both win and osx) is sourcetreeapp (@atlassian). You need a license after the trial period, but it's free.
Advantage of Hg and Git over svn is mainly speed and the fact that you can continue to work offline. Oh, and their merging feature actually works :)
@Yanic Mercurial allows you to commit selected chuncks and files. So I guess this is very similar to the Git staging area. Rename detection isn't automatic, but it is supported (at least if you use TortoiseHg). Or you can specify it yourself on the command line :-)
Post a Comment