I’d also say that going back to school is a good way to update your life
and change your profession. I’m a firm believer in getting government
student loans and using them to go to school. They’re cheap, low
interest, and the US government is usually very nice about letting you
pay them back. I’m not so sure about other places around the world
Notice how he says government loans. That I agree with. The private loan system is another beast altogether, one I am dealing with personally. Fortunately with our profession it is not hard to pay off loans.
Yes, government loans. I wouldn't have been able to go to school if it weren't for the government loans I could get. I was poor, and school was damn expensive no matter where I went. Without the government handing me dirt cheap loans and letting me pay them off practically indefinitely I'd be much worse off.
Now, banks and private loan companies can go to hell.
I understand Python gets some mileage in the financial industry, particularly by quant/analyst types. I'm aware that NumPy and matplotlib see a lot of action - are there other open source packages that get a lot of traction? Are there contributions from companies that find their way back into the larger open source ecosystem?
Examining packages like this where you already have a handle on what the code is supposed to be doing might be a good way to consume a lot of (hopefully some good, and probably a lot of not so good) Python code. Regardless of if you find a local mentor, contributing to or writing your own open source packages should prove to be a very valuable experience. Perhaps you could even start a package or set of general packages related to finance. Sort of like what SciPy is to NumPy. (FiPy?)
You didn't specify your sample size and I won't vouch for what people I don't know tell you. You can take it as whatever you'd like.
Next you'll be saying the Django tutorial is the standard way to lay out projects. It's in the documentation, right?
Well, of the people who decided to provide answers on HN or reddit, the consensus was: merge the branch, delete it, then add a tag on the merge commit. And then on IRC the author of this book told me to do the same thing:
The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it.
Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.
Conventions are just conventions anyway. We've established that there's no technical barrier to your two objections. 1) You can clone different branches into different paths, which is exactly like a traditional svn workflow, and a pretty normal thing to do for continuous integrations and the like. 2) And if you never want to delete a branch, you can check on their merged status to determine if they're "done". More clever solutions have been supplied by others in this thread. You needn't convert to git, but it'd be polite to recognize that your objection to git is purely psychological.