Are there any really good Python or Ruby projects on github that have consistently atomic commits and a TDD style of coding? I would be cool to narrate a project like it was a sports event.
Most could be narrated with "Oh, now he's gone and done it, he's committed a patch that totally breaks the regression tests and introduces a major incompatibility bug. Yeah, this is going to be trouble down the road if he bundles up this and releases it as a...oh no. Are you seeing that? It's up, it's being downloaded already, and it's only a matter of time until the issues start coming in. Ted? What's your take?"
"It looks like he's heady towards the deadly Factory Factory Factory if he isn't careful, Ted."
"Oh yeah, it's either that or proxy objects all the way down"
"Oh whats this?! He's pulling out an FSM, what a good move"
"I like the way this is headed, let's see if the tests pass"
"Ohhhhhhh, noooo, the parallel processing tests all broke; that's why they call it a Finite State Machine, not a Whole Bunch of States Machine, Frank."
"How is he going to fix this one up?"
"Queues?"
"Yeah, probably Queues."
"Oh no rookie mistake, he's using the built in Queues, not the multiprocessing Queues, this is going to cause some nasty bugs"
"Looks like the referee has to jump in here. We've got a memory allocation error. That reference was freed twice and now, yeah, that's his third yellow card so he's going to have to hit the bench and sit this one out."
"Ouch! That's got to sting. At least it's not like last game when number 49 got into a heated argument after he got a red card for forgetting to escape SQL."
"At the end of the day, the code threw an exception, and our programmer failed to catch it. They put in a good game and tried their best. That's all you can ask for really."
I would really like to see case studies be a result of GitHub. There is so much data available to us thanks to Git, that it wouldn't take that much besides some commentary here or there to have a GitHub repository be a very powerful teaching tool.
A good programmer's "DVD Commentary" would teach me a lot, I think.
After all, if we were only interested in deconstructing finished products, there would be no Food Network.
Not quite. The food network is mostly about recipes that have already been created and tested. The equivalent would be putting up the git commits after the project is ready.
It's really intimidating for new coders to have their work publicly available. The programmer community are very harsh critics and I know I don't want someone to come looking through my code and call it shit. I know it's not very likely but it's still a fear however irrational.
There are times when you hope someone will find your project useful but know (or probably feel) that everyone else is better than you so you end up qualifying your work with some "it's not finished" or "I know this is crap but.." statement.
It's weird because we have this fear (I keep saying we and I'm not sure if this is a universal sentiment but it definitely applies to me) of harsh criticism but we're also proud of our work and hope its good enough for people to find useful. I guess the solution is to keep your public repos but be careful how you promote them outside of GitHub and "good" programmers also need to be just a bit nicer with the tone of their criticism. It takes guts to show off your work I think.
Making your code public is a good exercise in taking the criticism of others, and learning which type of criticism you can easily discard.
My GitHub page is far from impressive, it's mainly a collection of project that I think are fun to work on, or things I like to play around with in my spare time. Still, I make half-baked things public because I'm hoping someone will come along and offer feedback.
Fogus: What would you say to people who claim that Clojure is not a “real Lisp”?
Hickey: Life is too short to spend time on such people.
So even the creator of a programming language (not trivial to implement!) has to field a fair amount of flak from nay-sayers.
So if you're inspired to write something, put it out there. The worst thing that can happen is that someone will offer to help. The people tearing it down are spending their lives criticizing rather than creating.
The ideal solution is to be less talk, more action. You can fork a repo in Github and submit a pull request when you're ready. Instead of typing out a long complaint, clone the repo and try and fix it if you can. Then push it back, and you've solved the problem for everyone once it's done.
Realistically, though, I think you should avoid putting your code in the public domain until you're ready for the criticism or the feedback. Working in the open right from the start and expecting people to stay hush until you personally announce it is a stupid idea if you're concerned about people spreading the word too soon. You're not going to be able to issue an embargo on your work until a set time.
In this respect, why would you even push your code to a public Github repo in the first place if you objectively knew it wasn't ready for public consumption?
Github offers some pretty good version control stuff that git alone doesn't. There are alternatives (bitbucket offers private repos with similar functionality), but if you like the functionality of github and don't want to pay to keep your project private, then it's really your only option. Fortunately there's so much on github it's probably quite unlikely that anyone's even going to look at your code unless you're already known for doing another project.
I think there's a big difference between just having a public repo and actually promoting it. It wasn't too long ago that I myself wasn't using version control and decided to learn Git. Someone who's just learning isn't likely to pay for a service like that until they get some experience and understand how to really use it. In the meantime they're putting up half baked projects and little experiments that are awesome to them but worthless to everyone else. Don't you remember being a beginner and thinking you've just done something cool and advanced only to find out later that what you did before was actually pretty mediocre?
Now, of you're out there actually promoting something you've made it's a different story. You really shouldn't be bragging if you really feel something isn't quite ready. But then again I come back to my point about criticism. There's constructive criticism and there's overly harsh criticism. You're right,mthere should definitely be more talk and less action but we all know how we are. I've seen it a million times. A really cool project comes along and there's always those smartest-programmers-in-the-room types that have to tear it apart like its garbage instead of offering up some constructive suggestions or actually taking action. It'll probably never stop so the best we can do is try to grow thicker skin as project creators and try to be more constructive and less snarky as critics.
Your comment could be said for any creative activity so you're not alone in your fear. Art, music, writing, etc... all take guts to release and hear the criticism. Thing is, hearing criticism gets easier the more you hear it. Take what you can from the criticism and keep improving.
There should be like a "close" option in github once you create a repository, a project that anyone can fork but can't follow and it means that the project is not ready for prime time.
Isn't that pretty much the same as a private repo? I don't think that would be very useful. I think the public or private options are fine. If something isn't ready I doubt anyone would want to follow. Projects that aren't ready have a high probability of never being ready. Plus it goes against the "social coding" part of github. I think the way they do gives you more incentive to finish something once it's public. As for private repos, well I assume if you're paying money for it then you're not fucking around plus I'm sure once the money rolls in GiHub doesn't care if you're social about your coding or now. I mean, it's a great site but it's still a business.
