walk through your next week and carry a notebook, making a note of all the things you think of that you wish existed, but don't. when i do this, it's generally through little irritations, conveniences that save me 3-4 minutes, realizations about people's work process -- that kind of thing. go fishing in the real world. do this until an idea for a product hits you. it will, and likely soon: something you want or need that no one provides.
in the meantime, get into a startup, on an equity basis. look for contribution to the work, not a paycheck. learn the atmosphere, see what works and what doesn't. get involved with your local user groups and search for a partner, someone like-minded.
put down the tech for a bit and read. spin down the head for a bit. my best ideas happen when i'm not thinking about them.
it's really a question of the want-to. if you have that, you'll be okay.
seems like git isn't designed to handle long-running branches, or branches with more than one committer. i'm still pretty novice at git, and was hoping this article could clear that up, but mailing patches around seems .. inefficient.
anyone want to correct me? i like git in most respects, and am now using it on a few projects.
Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...
As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.
It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.
As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.
with git you don't checkout, you clone. then you branch that clone locally. if you want other people to work on that branch, you can git push that branch to the origin server repository, and other people can then git pull it, and of course any member can then simply git push it whenever they commit and it will be widely available.
If you're working with other people: Pair Programming. Fastest way to learn anything.
On your own? I'd look for a reasonably simple project on github, or somewhere the source is available. Before you start trying to understand everything, prime your brain with a little previous exposure. Look through the directory structure, look through the source code. See if anything makes sense. Build it, to understand the build process. Run it. Now change something. Could be a title bar, a background image, a validation. Just something. Build it. Check your work.
Now your head is in the right space to learn. Find a cheat sheet, and go through that. Go back to the app you're fiddling with and walk through it again with the cheat sheet handy. Change something more fundamental. Build. Check.
After you've gotten the cheat sheet (primer) understood, build something from scratch. As run4yourlives mentioned, the blog is the new hello world. Build that, build a file uploader, and build something event-driven and flashy. At this point, you'll want to go through a book -- but skim the whole book first to get a sense of where things are.
Now dive deep. As you are learning, write stuff down -- build a tutorial. Try to explain it to someone else (that always helps me, anyhow). By the time you finish writing your tutorial, you'll be ready to contribute, and you'll learn more on the job.
the win on this article is the comments: he posted the article, someone cracked the license generator, posted the source. there was a brief, friendly discussion about this.
if it were one of my previous employers, they would've immediately sic'd lawyers, the fbi, homeland security, and anyone within shouting distance on the commenter. (the head of the legal department once got up at a quarterly meeting and ecstatically announced how many people had been prosecuted that quarter. there was an uncomfortable silence that followed, as everyone began expecting security cameras installed in every room. they started appearing shortly thereafter.)
the authors sense of humor about this and pragmatic outlook is appreciated, and in my mind, correct. do what you can, make it easy to buy, make it uninteresting to break, have free versions available for people who need them.
In the article he stated why he sees no point in making it hard to crack the code open, then someone posts this code and mentions that he is no pro hacker, but just was able to use his newbie-skills in flash because there was absolutely no obfuscation or something - and now Peldo is researching and asking for ways how he could do better.
Hi there, this is Peldi. A little update: I will be trying out SecureSWF tonight, after a twitter friend recommended it: http://www.kindisoft.com/secureSWF/ - we'll see. :)
Yes, a little. The guy made a good point that making life harder to beginner-level hackers is a good idea, so that's what I think I'll do. I'll update the post after the dust settles a bit. :)
most textmate dev nowadays is being done in bundles. while the elastic tabs thing doesn't work quite right in textmate, textmate's tabbing (soft-tabs to convert tabs to spaces, backspace to go back a 'tab', autoindent based on syntax conventions) is pretty satisfactory.
one thing it doesn't do that looks REALLY appealing with elastic tabs is multi-tabbing, especially to appropriate spacing on multiline parameter lists. i'll add 'write a bundle to do this stuff' to the long list of projects that fall behind the startup.
also midwestern, and have also historically had problems finding edgish work there. they like their .NET and their java. also, work rates are terrible. i can generally expect to take a $30K pay cut working locally in central ky/southern ohio/northern tn as opposed to working remotely.
even if there were some random startup, you still wouldn't be able to participate in the startup community you would in the bay, or boston, or chicago, or ny. there'd be no networking, no idea sharing across company lines, no post-work barcamps. part of the fun of a startup is the culture.
good luck. as for me, i'm hoping YC comes through for us so i can move to the bay.
in the meantime, get into a startup, on an equity basis. look for contribution to the work, not a paycheck. learn the atmosphere, see what works and what doesn't. get involved with your local user groups and search for a partner, someone like-minded.
put down the tech for a bit and read. spin down the head for a bit. my best ideas happen when i'm not thinking about them.
it's really a question of the want-to. if you have that, you'll be okay.