Today I was looking at a lot of the different applications that I normally use on my phone and through my web browser. If I was talking to someone who had never experienced either of these before, they might believe that I generally have a single specific device for a specific task, and that in terms of functionality there would be little overlap of major features. However, for anyone that has experienced either of these mediums, they are aware of the wide variety of applications and programs that duplicated the functions of other applications.
My complain is two-pronged on this issue of applications that start or continue with a Hackathon paradigm. First, the old Unix philosophy says do one thing and do one thing well. On this specific point, I believe that many applications start out with the right intentions, however over time there is a significant feature creep effect that takes place. I believe that this is the result of "Hackathon project" becoming more than "Hackathon projects." The developer of these application feel that they are going to form a company with a project that in terms of complexity should really be no more than a side project. Essentially what I am saying, is to develop and maintain your application X, it _might_ take 2 hours a week once it is launched. However, these individuals choose to attempt to make a 50 hour, startup styled, work week out of these types of projects.
My second issue with the "Hackathon projects" is don't assume that something that you can write in 24 hours is not easily copied. There are a lot of very complex and difficult problem that exist in the world today. Nearly all of these types of problems can not be solved in a short period of time. Additionally, if a product can be made in 24 hours given the proper tools and skills, then it is only a matter of time before there is a large number of people who will be competing with you. Some might even have better products given that they were able to replicate your product in such a short period of time, and then vastly improve upon there after.
With these two issues, I am not saying that Hackathons are bad,Hackathons provide a relativity easy way to create demos to show of skills. However when it comes to publishing a product I believe that people should think a little more about what they are going to create and invest enough time into the product such that it is not just going to be another 1 of 100 "identical" products.
It seems a little strange that I have not yet written a blog entry on my own project JSApp.US
At it stands now, it is my most popular site ever, it laded its self to the reddit/programming page, and was on the top of hackernews for about 3 hours. It seems to be very successful for now and even I have a few applications that are using it, such as count.jsapp.us, it is powering the little visitor count that I have placed on the side bar.
There are a few new features that I am still planing to implement. The first feature is going be a sorta profile that will allow for people to "show off" their applications that they have on JSApp.US. I also have plans to make it so that one can require in files from other users. This should end up like how github handles it with users, the basis will look like: require('other_user/file.name').
I have been using Dropbox for a good amount of time now, and something that I have recently started using Dropbox for is as a back-end system for private git repositories. While Github is great for public repos, if you just want to have a private project synced between a few computers or with another friend on Dropbox then the steps are more or less straight forward.
1) Open up a terminal and cd into your dropbox folder,
2) You have to make a bare git repository that is used to hold all of the git objects, this can be done by issuing the "git init --bare repo.git" command. This will make a new directory called repo.git with all the supporting files.
3) At this point all that is left to do is link up your working git directory with the Dropbox one, the easiest way to do this is cd into the repo.git directory. Then Issue the 'pwd' command, this will give you the absolute path (git will not use relative paths for some reason). Then copy the output from pwd and then cd into your working directory, and issue the command "git remote add origin file://[Paste in what ever came from pwd]"
4) Now that your working directory is linked with the directory on Dropbox issue the command "git push origin master" to load all your files into the dropbox. One thing that you will notice is that this will run a lot faster than when working with a remote repo over the internet. The reason is that you are not pushing files onto the intern but into another folder on your computer. If you look at you dropbox icon at this point you will see that it is syncing a number of files. If you have worked up a larger number of changed between syncing with dropbox you might see that it is syncing in excess of 200 files with the server.
5) To load the project onto another computer you can use the "git clone file://[path to the dropbox repo.git folder]" One thing to note before pulling any changes is to make sure that dropbox has finished syncing all of the files. If you trying and pull or clone out of the Dropbox directory before it is done syncing then you can run into problem as git will look for files that are not there yet as dropbox has not finished syncing, so as a not of caution, wait for dropbox to finish syncing before cloning or pulling.
When you want to share a project with someone else, then all you have to do is share the repo.git folder with that person, they can then run a clone command of that file to make their own working directory. While this does give an easy way to have free private 2 GB of git syncing space, there is no cool Github like web interface for looking at code. And as another note, anyone that can modify the repo.git folder will be an 'admin' to the project as all the server is really is just syncing file between computers.