One way to network is to go to job interviews. Be open about the fact that you're mostly interested in contracting and maybe you'll consider joining after a time (which is true in my case - there's a lot of overhead in contracting).

People forget that doing backward breaking changes take a while. Python 3 was released at the end of 2008, 2 years after Java 6. How many systems you know still run on Java 5?

Java 6 did not break backward compatibility (code written for Java 5 generally runs fine on Java 6).

Code written for Java 2 runs fine on Java 8, with extremely limited exceptions. Java, just as Windows, is used too much in enteprise apps to lose backward compatibility.

Yup. Biggest roadblocks in java update are bytecode manipulation libraries and at the moment maven.

I'm still intrigued by this situation: I'm running my software on java 8, but I can't compile it as java 8 unless I do that by hand (... really?)

Two things: 1. IMO sup (http://supmua.org/) is more mature and does about the same. However it's interface is a curses based one which is a plus and a minus. 2. Why not use an existing search products (like xapian)?

This is actually answered in the FAQ on our Indiegogo campaign: http://igg.me/at/mailpile

Mostly, the reason we do things the way we do, is because one of our primary goals is to make an end-user desktop app. Packaging is therefore a significant task and minimizing dependencies will help a lot.

We still have quite a bit of work to do on our website and message.

One of the reasons I started lumail (http://lumail.org/) was because none of the existing console clients worked for me. Specifically sup will die importing my 2013-1994 = 19 year mail archive.

If you have more ways to improve your I/O - please share :)

Instead of managing your own grid, you can use saucelabs.com

So you end up committing untested code? (since you did test the whole change, not just part of it).

Sounds like a bad idea to me.

None of this implies committing untested code. The index is not a commit; it is a pre-commit staging area. When you use 'git add -p', you are adding hunks to the staging area, not committing them.

What's the difference? When you're done staging your patch, you can then check out the staging area and run unit tests on it prior to promoting it to a commit. Doesn't compile? Tests fail? Restage as necessary.

Really? I'd definitely commit before running tests. You can always use reset to redo the commit later. Branches are cheap, commits are cheap.

I usually do something like:

  git add -p
  git commit
  git stash
  <run tests>

If it fails then I can stash pop and commit -p --amend and try again.

With stash -k you can test without committing first. Although git is very flexible regarding this, I prefer to at least test the code before committing it.

`git checkout-index` allows you to run tests on the index before committing and without messing with your working tree. The only downside is that it might take a while for a large project. Example script: https://github.com/philc/vimium/blob/master/git_hooks/pre-co...

When you're done, just use Bernhardt's "run-command-on-git-revisions" to run tests on each of the commits to ensure they are all working code.

https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...

Nothing wrong with committing untested code, it's pushing it as a ref one can reasonably expect people will merge/fast-forward to that it becomes a problem. git add -p is a nifty workaround for the type of people who don't like the workflow of "commit early, commit often" (some people have 'save file' bound to also make a commit) but who still want to have lots of small, contained commits.

Not a huge deal, but it can become problematic when you're using something like git bisect.

So what? Just test the commit after you've made it. You can always reset and try again before pushing.

A lot of times I use "git add -p" to cleanup code, e.x. if I added some extra logging statements I don't want to commit I can go through adding everything except the log statements, then reset everything that hasn't been added to the index.

git stash -k; make test; git stash pop, git commit;

Problem solved.

The problem is with the process, people will forget. You probably need to automate this.

If people forget to test their commits, they're going to forget them without using git add -p too.

test: stash-keep-index

Committing untested code is an excellent idea. You should do it several times a day. Pushing untested code to a shared branch on a public remote is a bad idea.

That is most definitely a major issue of this technique, though it can probably be mitigated through various hooks.

I find this technique great to keep unrelated fixes in separate commits. A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line. Keeping the barrier low for committed code is one of git's best features.

> Keeping the barrier low for committed code is one of git's best features.

When I first learned git, I was told, 'You'll never have to comment out code again'. Keeping the barrier for commits low (along with git -p and git rebase -i) makes this a reality.

> A single revision may not pass a set of unit tests, but the entire feature branch will before being merged into the release line

I really don't care a whit about your feature branch when your broken commits mean I can't bisect an issue.

Also note that _ has a meaning in the Python REPL - it's the value of the last expression.

_ is also used in the node.js REPL to mean the last expression. This means that you can't require() underscore.js as you normally would and must instead choose a different name.

Yes, I'm aware of this problem, underscore.php solved this using double underscores maybe I can add a noConflict method to rename the library and free up underscore variable.

Just installed beta1. Opened terminal and then:

    $ python --version
    Python 2.7.3

Yet again, instead of trying to fix the existing, someone writes yet another library.

This was my thought, too: there seems to be a limit beyond which memcached simply breaks. I learned this 5 years ago, and it had nothing to do with Python.

Well, if there are too many users of an existing library, it makes it hard to do large changes. So in their case, it seems like the original library would silently fail on exceptions, they want to make things bubble up to the top which could be bad for a large number of users who have been depending on the silent-fail operation.

I did an upgrade from 11.10 to the 12.04 beta. Seems to work fine.

Same, just a few days ago. Worked perfectly, no hitches, and 12.04 (even the beta) is noticeably superior to 11.10.

My laptop battery life jumped from 4.5hrs to 7, kernel panics with too many Chrome tabs open and/or Flash playing are a thing of the past, etc.

One of the best upgrades I've ever done.