4 ms·

GitHub is a fish bowl

69 points by jamesmoss 15y ago

jQueryIsAwesome 15y ago
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.
- billpatrianakos 15y ago
  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.
- rue 15y ago
  A technical solution to a social problem. (The problem isn't that people follow or fork WIP repos; it's that you care whether they do or not.)
3pt14159 15y ago
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.
- astrodust 15y ago
  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?"
  - 3pt14159 15y ago
    "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"
    - astrodust 15y ago
      "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."
      - mapleoin 15y ago
        So, seriously now. Can we do this? It seems like a lot of fun!
    - FuzzyDunlop 15y ago
      "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."
billpatrianakos 15y ago
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.
- bitops 15y ago
  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. In terms of negative feedback, I refer you to this interview with Rich Hickey. http://www.codequarterly.com/2011/rich-hickey/ http://www.codequarterly.com/2011/rich-hickey/ Here's the section I'm thinking of. 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.
- deleted 15y ago
  [deleted]
- FuzzyDunlop 15y ago
  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?
pnathan 15y ago
I have been very happy with github. I've been using it for the last few months and it's worked pretty well. Specially for hg-heads like me. :-)
oflannabhra 15y ago
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.
BCM43 15y ago
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.
tomjen3 15y ago
That's a nice thing about bitbucket: private repos. Release when you want to.
lukev 15y ago
Am I the only one who almost always starts projects as private repos and only puts them public once they're at a reasonable alpha or beta stage? When I'm still regularly trashing all my code and starting over, it doesn't do anyone any good to follow the repo.

69 points by jamesmoss 15y ago

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.

billpatrianakos 15y ago
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.
rue 15y ago
A technical solution to a social problem. (The problem isn't that people follow or fork WIP repos; it's that you care whether they do or not.)

3pt14159 15y ago

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.

astrodust 15y ago
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?"
- 3pt14159 15y ago
  "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"
  - astrodust 15y ago
    "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."
    - mapleoin 15y ago
      So, seriously now. Can we do this? It seems like a lot of fun!
  - FuzzyDunlop 15y ago
    "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."

billpatrianakos 15y ago

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.

bitops 15y ago
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. In terms of negative feedback, I refer you to this interview with Rich Hickey. http://www.codequarterly.com/2011/rich-hickey/ http://www.codequarterly.com/2011/rich-hickey/ Here's the section I'm thinking of. 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.
deleted 15y ago
[deleted]
FuzzyDunlop 15y ago
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?

pnathan 15y ago

I have been very happy with github. I've been using it for the last few months and it's worked pretty well. Specially for hg-heads like me. :-)

oflannabhra 15y ago

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.

BCM43 15y ago

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.

tomjen3 15y ago

That's a nice thing about bitbucket: private repos. Release when you want to.

lukev 15y ago

Am I the only one who almost always starts projects as private repos and only puts them public once they're at a reasonable alpha or beta stage? When I'm still regularly trashing all my code and starting over, it doesn't do anyone any good to follow the repo.