reviews, ruby, thoughts
Rails Rumble was an amazing experience. I think I slept about 6 hours over a 56 hour period and while I became grouchy I don’t think I ever stopped having fun. The fun stopped after the first day of voting. Starting during the second day of voting I <3 Games plummeted in the rankings. I am not really sure what happened to cause this fall. I am not the most objective person but in testing some of these other apps I’ve run into some real problems that I don’t understand how something that doesn’t quite work could be ranked higher than our app which I think is about 90% done.
Problems with voting
- With any voting system there are always ways to game the system. The OpenID requirement for Rails Rumble voting would make gaming rather easy I would think. Without a captcha or email validation it would be fairly easy for a machine to sign up for voting as many times as it wanted.
- Voting with most people for Rails Rumble is only based off of a glance, there is very little actual signing up to use the app going on.
- No way to explain what your feelings about the app were.
I think if some of these issues were addressed I would feel a little better about the voting system. I think the 8 random apps a day idea was a good one that helps prevent the event from becoming an popularity contest.
Gaming the system is always going to be a problem. Bots can be created that get around almost every system to stop them, but when the systems are few and far between to stop them they can have a field day and can dramatically skewer results. I do know a few people who aren’t bots that just said “Oh, well I’ll just give every other app 1 star across the board” and it shows. Rather than 3 stars being the “average” value for an app it is the high value. I know there won’t ever be a 5.0 over all app, but we’re talking about 2.9 being the high value and 1.6 being the low value. That is a lot of 1 and 2 stars over the 4 or 5 stars. On a scale of 1-5 then 3 should be the average, that should be “this app is unremarkable, there is nothing wrong, but nothing right either” instead if we keep going along the way we are currently going then 2.9 is going to be the winning score, which using the normal averages would mean that it is slightly below average, and while I’ll be the first to admit none of these apps are above average against an application where you have an unlimited time frame and tons of QA testers. If you keep in mind that every single one of the apps was designed in 48 hours by 1-4 people I would have to say a great many of them are above average.
One of the problems I have with the voting system is that the results tend to be skewed towards pretty on the front page apps. Powered By Geek didn’t exactly cater to this, we hid a lot of functionality after sign up, but we did put a little video up explaining about the app. The real problem I have is the number of people who aren’t even signing up who are voting on the app. I know for a fact that our login/signup process works because we had a guy dedicated to testing that procedure during the actual competition and I’ve created about 10 accounts as well with my numerous Open IDs and as regular users. Looking at our numbers we’ve had 79 users sign up, and when you take into account all my test accounts that is about 70 users total who have signed up and yet we have 240 votes on our site. That is a 1:4 ratio of people who actually looked at our site vs people who just voted either after looking at our home page or without looking at the site at all.
I’m wary to point my finger at people and point out flaws as to why they shouldn’t be at their position, however some of the apps I tested had main functionality broken and yet they are sitting in the top 30 spots. Testing is almost nonexistent, a friend was testing other sites and uploaded a picture that he figured would disappear after a while but instead it was on there for over 24 hours. The site only had slots to show 5 pictures that means that it took over a day to upload 5 pictures on the site.
My final real problem is that there is no way to tell why people voted one way or another. I think a short description on why they are voting one way or another would help everyone involved to understand what people liked and what people disliked about the app, not to mention it would make it easier to tell when someone was gaming the system.
Overall I think the Rails Rumble brings an awesome service to the community. 48 hours with the right motivation (competition) is really useful as it can really get an interesting idea or product built. Not to mention it helps bring you together with friends towards a common goal. I really just wish everyone could come away from it feeling like the voting wasn’t just a game.
If you’ve ever been a contractor you too have faced the juggling act that is having many different projects in the air. There is quite a bit of work that goes in to just managing those projects, much less actually doing the work on them. I’m going to write a bit about how I handle them and manage to keep a semblance of sanity. Right now I’m looking at my “in progress” list and I’ve got 10 projects open at various stages of completion.
One of the big problems with having so many projects going at once is that there is just no way that you can remember where you were with each project. There are a ton of great online tools that I would recommend for keeping everything organized.
Before you start signing up for every organizational tool out there though, I would impart a tale of woe on you. Starting a large project Powered By Geek wanted to make sure we crossed all the T’s and dotted all the I’s so we set out to use just about every organizational tool out there. We had Basecamp, Campfire, Lighthouse, a Wiki, a large chunk of API documentation, Google Docs, and many more. We actually had everything in a proper and logical place, however the organizational scheme that we used backfired. Trying to get into the swing of a project and having to open up 10 different tabs and login to 10 different tools soon ended up with people getting lazy (I happened to be the laziest of them all) and just throwing documentation together into other tools, trying to consolidate it so I didn’t have to track it across other tools. Things quickly got out of sync, and confusion starting happening between developers. However once we had pared down the list of apps to just a few major ones and kept information in less places things started to move a lot smoother. The moral of the story is to try to organize stuff as well as you can within a few tools that you are comfortable with, and then slowly integrate other tools if there is a need for them.
My MUST HAVE tools are really rather simple. You need ticket tracking, milestone tracking, repository tracking, a place to write messages and warnings, and finally if you have more than two people a place where you can all get together and talk about the project(s).
Ticket Tracking, Milestone Tracking, and Notice/Messages
Lighthouse is a great tool and manages to fairly simply cover most of the needs of a small contracting house. The ticket tracking is fairly easy to use (simple enough that you could give a client access and have them report the errors/changes themselves) and is also pretty customizable. It also allows for milestones to be created and tickets assigned to them which makes it somewhat easy to see a break down of milestones and how far along you are on them. Its message system is decent (I’ve been using it to write standards and code guidelines), I wish it stood out more but as long as people know to check it then it is useful. Lighthouse only really does the ticket system well, the rest of the items it does just good enough that it makes sense to use the features rather than bring another tool into the mix, but it is fairly inexpensive. The ticketing system does lack some somewhat standard features though such as parent/child ticketing and time tracking, but you learn to live without them (or in the case of time tracking you learn to just keep track of it somewhere else). Since most of PBG’s projects are done on a task/goal basis the time tracking wasn’t that big of a deal for me.
As of right now, there is no better choice for a code repository than Github. If you are managing multiple projects then I don’t think it is possible to live without Github. If you aren’t using it, then I would seriously look at switching over. The only drawback to it is their strange payment levels, because of the limit on private repositories you’ll often have to pay for a much larger package than you would need (it basically amounts to a dollar per private repository). Other than the payment schema (which still isn’t very costly) it is probably the best investment in easily adding and managing your projects.
Most of PBG’s projects are usually done with Lynn and I, so we just use Gtalk for our messaging system. As soon as you add a third person however, you need a place to go to type questions and ideas where everyone can read them. Preferably a place that is logged and allows you to upload attachments. For this I would recommend Campfire the multi-line paste tool isn’t as nice as Pastie or Gist but it does allow you to fairly simply paste a chunk of code and have it easily readable by everyone. It allows you to upload attachments or paste picture urls and have them show up in the chat. It’s a great tool for talking to everyone (even if they aren’t on the same work schedule as you, since the chat log will always display the entire conversations). It’s not all that pricey either, which means it’s great to try and see how everyone gets along using it.
With multiple projects it’s very easy to get overwhelmed. If you have 5 different projects open in TextMate, 5 different terminal tabs running servers on 5 different ports and you jump between the projects fixing bugs and working with different people on the different projects then you’re likely to lose your mind. Development requires your mind to warm up to your project. The flow of one project is often vastly different than another project (an online classified site has a different mindset than a life streaming site), so set a side time where you focus on one project (a couple of hours, a day, a week, whatever) so you can get into the mindset of the one project.
Line your ducks up before shooting. I’ve found that using the ticketing system to dictate where I need to go and what needs to be done works the best. I make myself tickets for everything, from features that need to be completed, to a link that needs to be added on to the page. Then once I’m in the flow of that one project I can burn through all the tickets quickly and efficiently. The best part about using a ticket system is that you can think about the project any time you want, come up with a good feature idea and submit your self a ticket explaining it, then forget about it. Trying to juggle ideas around your head will only lead to you missing something that you thought was wonderful and having a coworker ask you why the feature you thought was such a great idea was left out.
Write notes to your self in a centralized place. Commenting your code and documenting what you’ve done is probably the one most noticeable failing in every developer I’ve met, and this is usually because the developer has all the commentary for the code written up in his head. I know when someone asks anything about any of the projects I’m working on, I can usually tell them what file they need to edit, where they are looking, what the variables are named, what method is doing what, etc. The problem with this is that the more projects that you are involved with the more likely it is that you’re going to get some things confused. When I was doing 2-3 projects at once this wasn’t a problem, but when you start to get into the double digits this problem starts to show up. My solution to this is to write little notes to myself and others explaining what is going on, similar to actually documenting my program. This helps because now I don’t have to keep everything that is going on in memory and people don’t have to ask me questions that would be trivial to answer themselves if it was written down. It is more work, and it’s dull work that seems to have no purpose, until you go back into a project after a month break and can just quickly read over your notes and get back into the swing of what you were doing and how you were thinking.
Try not to leave things hanging. Unless you are working on something daily, you’ll want to try to avoid leaving things half completed. Finish out tickets completely and get to a good stopping point before you close everything out. That way you don’t need to remember exactly where you were at the next time you start up. If it’s unavoidable and you absolutely have to stop half way in then write your self a detailed note on where you were at and your current thoughts on how to proceed. This will make sure that you can pick up where you left off and hopefully put the finish on it before you have to stop again.
I hope these thoughts help. With Rails development being cyclical in nature and companies managing multiple projects at the same time this issue is going to be cropping up more and more.
In the recent past there have been a ton of applications that I’ve followed almost religiously. I’d read forum posts about how their software or service was coming along great, then they disappear off the face of the planet for months of a time, with no updates. Lynn Wallenstein and I were talking last night and we decided that there should be a standard for development communications. Right now it’s still in the early idea phase, but any input would be appreciated.
As a developer, especially one that works with insane deadlines, I know that you can’t always hit the mark. As a corporate developer, I’ve also learned that if you aren’t going to hit a deadline it’s good to to just put it out there and let everyone know what is going on. In the corporate world it is a necessity, plans need to be changed, milestones need to be rearranged. With the rise of web based services, and small application development, it’s easy to say “It free or almost free, be happy that we’re doing it at all”, this is an understandable attitude, and one I’ve often shared, but it doesn’t help the people who actually use your service, and people who want to rely on your software.
Lately I’ve noticed development teams (especially Rails) have a very hot/cold development cycle. Powered By Geek does it, as well as many others. We have so many great ideas that we want to get done, and the minute we hit a good new idea, development on our other, on going, projects slows down. Or we’ll get a client job that takes priority over the rest of our side projects, which moves all the different items we’re working on to the back burner. Fairly often this is accompanied with little to no updates on progress, or even a mention that we’re going to be putting it on hold.
A development communications standard would lay the ground work for development teams to do public communications with progress. This wouldn’t leave customers so frustrated when their favorite software mentions a linux version coming soon then disappears for 6 months, or a service that you’re really interested in stops almost all communications about the project.
I personally love the idea, both as a developer and as a consumer. As a developer, more communication with your core audience, letting them know when things are going to be done and what is going to be done, is a good practice. As a consumer, knowing when things are going to be happening and what to look for would resolve the disappointment I feel when I look at a blog entry about a feature or product I really want, only to see that it was dated 6 months ago and there hasn’t been an update since.
With the recent change over to my Mac, I’ve started to really take a look at the differences between SVN and GIT. I’m still in the process of learning how to use both bundles for TextMate so when I’m actually in “work mode” I’ll usually forego playing around and just use the command line and I’ve noticed some definite differences.
SVN is actually what I’ve been using the longest, and am much more familiar with. However using it from the command line is something I’m not very familiar with because up until my switch to my Mac I have always used TortoiseSVN which is probably the best implementation of an SVN client out there because of it’s integration right into the Explorer shell.
Some of the pros of SVN:
- Output is much more descriptive
- Without branching it is completely straightforward
- A lot of documentation out there to help you get started
- Easier to move between old revisions
And, of course, some of the cons:
- Slow and clunky feeling
- Hard to setup initially
- Pain to fix merge errors
- Branching is a chore
- Require an “always on” server/connection
Pros In Depth
By default, committing, updating, checking out in SVN yeilds very clear and easy to read output.
Macintosh:upillar_motors danahern$ svn up
Updated to revision 5776.
You get a clear understanding of what it is doing every step of the way. With GIT the updating is a little harder to understand
Macintosh:truth danahern$ git pull
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (10/10), done.
Unpacking objects: 100% (14/14), done.
remote: Total 14 (delta 4), reused 14 (delta 4)
ecd1c5c..73c70a0 master -> origin/master
README.txt | 62 +++++++++++++++++++++++++++——————————–
1 files changed, 28 insertions(+), 34 deletions(-)
Straight forward workflow
As long as you aren’t branching SVN’s workflow is a lot more straight forward than GIT. You have your server repository which is the definitive copy, then you have your local copy that you work on and then check files into the server repository.
Tons of documentation
Both have been around for a long time, however GIT has only recently really hit the limelight as the new choice for code repositories. SVN has oodles of documentation out there, and while this won’t be a factor for much longer, GIT is still catching up with regards to documentation explaining the how’s and the why’s.
Moving between revisions
This might be a short coming on my part, but SVN feels a lot easier to move between revisions. You do a little research to see what revision you want to grab and then just do an update with a “-r <revision number>”. I haven’t yet gotten the hang of reverting to previous revisions with GIT. Thanks to Pieter, I’ve found out that reverting in GIT is just as easy as SVN (In fact far easier when using Github). git checkout
Cons In Depth
Slow and Clunky
SVN really doesn’t excel at giving me the feeling that it’s actually doing something. It feels slow, committing a large file or groups of large files leave you sitting at “Transmitting Data.” forever. No status indication, which means you don’t know if you should sit there and watch, or maybe go grab a bite to eat, enjoy some TV then come back and hope it is done.
Hard to setup initially
I haven’t really ever had to do this by my self, but from the experiences I’ve had with others as the developer waiting patiently to start a project or drop an already alpha product into subversion this seems to be a time consuming and difficult process. I can’t go into the details on what went wrong each time, but I do know that by the end of the process everyone involved was frustrated and praying that there would be a better solution one day. It should be noted though that once it’s up, as long as you don’t change anything, it stays up pretty solid.
Pain to fix merge errors
Merge errors are a way of life when working with others on a code repository. The merge errors in SVN are a pain to fix. Not only does SVN leave the file name with extra characters with the files diff’d into the file name, but it generates 3 different versions of the file and sticks those in there as well. In reality, one of those solutions or the other would make more sense as a standalone.
Branching in SVN
Branching in SVN is actually so much of a pain, that rather than creating a branch we’ll either create a new repository or just say “screw it” and make a backup copy of the repo and just start committing. Once you use git’s branching there is no way you could actually stand to go back to SVN.
Require an always on connection
This hasn’t been a real problem for a while, however, on the occasions where our SVN server goes down or for some reason or another I can’t connect to it all development stops.
Git is the relatively new to me versioning software. I haven’t checked out any of the GUI based interfaces for it yet (and at a glance it would appear there aren’t many), but the command line version has been treating me right for a while now.
Some of the pros of GIT:
- Everything is faster than SVN
- Branching is a breeze
- Merge is amazing
Some of the cons:
- Hard to understand what is going on
- Github’s pricing system
- No really good UI
- Few web based tools
Pros In Depth
Everything is faster
This might be just a perception, but everything on git seems faster than SVN. From checkout, to merge, to commit, everything seems to speed along on git. It could be just that it’s more verbose, you can see it actually working instead of sitting there pondering
My heart actually expands three sizes at the thought of how easy the branching is to handle on git. So many projects I’ve worked on would benefit greatly from being able to branch off and work on a big revision. The problem that’s held me back so far is that SVN is such a pain to branch, I look forward to getting to branch a lot more.
Github is a great tool. I would almost wholeheartedly recommend it, and if you only have a few things you’re working on I do in fact recommend it from the bottom of my heart. It is amazingly simple to setup, and if you see a public project you’d like to patch it’s actually impossible to mess up checking out, and commit a patch. There are some problems with it, which I’ll expound upon in the con section.
Git is infinitely better at handling merging when compared against SVN. I’ve actually never had a bad merge issue with git. It’s also far faster than the SVN merge. It’s a win all around.
Cons In Depth
Hard to understand
Git’s pro is also a con. It’s very verbose, it tells you exactly what is going on. It’s hard to understand what it is doing at every step. Especially when compared to the simple output of SVN. (To see an example scroll back up to the SVN Pro)
Github’s pricing schema
No one knows better than I do the value of making a buck off your hard work, and I would be more than happy to pay for such a wonderful service as Github. The problem I have with Github’s pricing schema is the limit on space or projects. However, the way it is setup is based on public/private repos as well as space, this means that because of the limit on private repositories you can’t post all your private client work. Powered By Geek contracts out to a LOT of companies, and if we want to host all our repos with them then it would cost us a small fortune.
No good UI tool
As of right now there isn’t a good graphical user interface for interacting with git repositories. SVN has been main stream for a while longer and has had more time for tools to develop, and between Versions on the Mac and Tortiose on Windows. Right now the Git GUI tools are very basic, and not really useable.
Few web based tools
There aren’t that many web based tools out there for viewing repositories. The SVN tools are pretty mature and refined, however, the git tools aren’t there yet. From the little I’ve read, the git API tools are still developing. So I don’t think this is going to be a con for very long.
I think for our new projects GIT makes a lot more sense than SVN. Since I’ve been working with git with the command line and have gotten used to it I can’t really imagine moving back to SVN. Git really seems like the better tool, but it needs to mature a little more, I think shortly there will be no real con to using git as opposed to SVN.
introduction, thoughts thoughts
Starting with this post I’m going to try a new format for my writing style as recommended by Lynn. Focus more on bullet points and logical breaks, less on writing what comes to mind.
- Why I do it?
- What I do?
- How do I do it?
- What I’ve learned?
Why I do it?
Lately, due to an abundance of free time, I’ve driven myself into working almost constantly (I live in a town whose night life ends around 9pm, and isn’t much of a life to begin with). Over a year ago I moved to St. George, Utah to work for a small internet startup. You won’t find me talking about my day job much here though because while it’s nice for a day job it’s not where my passion lies. However, far before I moved up here I fell in love with Ruby on Rails and was working with Powered By Geek and Lynn. Since my day job can only bring in so much revenue and frankly isn’t as creatively satisfying as my PBG projects, I not only spend 8 hours at work, but come home and spend some time almost nightly writing code.
What do I do?
How do I do it?
First off, if you’re going to spend 10-16 hours a day working you need a stead supply of caffeine. It might not be the most health conscious thing, but to maintain higher brain functions, I feel like I need to keep a flow of caffeine.
Second you need to love what you do. I had been playing with programming since I was 12 years old, however until I ran into Ruby on Rails I was content to specialize in IT Administration. Once I started learning Rails though I was hooked. I started to love web development, it became fun and the framework gave me a structured device to create something unique. Not to mention the gems plugin manager, where I don’t feel like I’m constantly reinventing the wheel.
What I’ve learned?
I’ve learned Ruby on Rails far better than if it was just a hobby or a full time job. It’s both my hobby and full time job. I’ve also had the opportunity to see other developer’s code, sit down and ask questions about why they do things a certain way.
Databases and optimization have also been a huge issue to learn. There is only so far you can take an idea with an unoptimized database (which iStalkr taught me). Once again I got a chance to work with people who specialize in databases and could give me pointers on how to improve. Databases, unfortunately, seem like something that you can only learn optimization for after you run into the issue.
Other items I’ve learned are:
- Site APIs (digg, delicious, flickr, etc.)
- RSS (both creating them and parsing them)
- XML (parsing and creating)
- Facebook (app creation)
- Lots more!