duke_sam

There is a visa (It's one of the E visas) for people bringing capital into the states but you it's not a trivial amount and you need to prove that you will employ a certain number of Americans.

#2 is partially handled by rdio (http://www.rdio.com/) you can create and share playlists and any number of people can listen to them. Not sure about collaborating on playlists but considering the heavy social aspect of the site I would be surprised if that feature never arrived.

I've been bitten by the lack of progress measurement and having "agile" requirements before. In most cases my physical presence is a crutch for a bad process, it allows people to make ad hoc decisions because they can grab me and talk in the hall for 10 minutes.

If people being physically present is no longer a given then some level of structure has to be put around decision making and disseminating the results of that to the rest of the company. Too many times I've lost days of work because X was changed to Y and I wasn't at my desk when people were herded together to make that decision.

Having people geographically distributed forces you to deal with communication up front. People are trained to use mailing lists, IM, bug trackers, commit messages etc. properly rather than assuming that if someone wants to know wtf just happened they can shout at you across a room. You hit problems like Mike being the only keeper of process Z early rather than on day 1 of Mike's 2 week vacation to somewhere with no cell reception...

You seem to be complaining that when using a language new to you in combination with a large framework written in that language you would have been forced to read the (very good) documentation to figure out what was happening.

The inconsistencies you mention are (in a well written code base) very rare. If you call a method get_name() odds are you are going to get back a string. If you seem to randomly get back an int or a dictionary or a datetime object it's a pretty good sign the code is foobar'd. Good Python programmers don't abuse the dynamic nature of the language. Methods should return predictable types (documentation is important), it might return different types depending on the input but this should be documented and obvious (say a parse date method that returns a datatime object if you pass it a string containing a date and time). The values() example you use is very clearly documented as returning a ValuesQuerySet that supplies dictionaries not models (http://docs.djangoproject.com/en/dev/ref/models/querysets/#v...).

In a number of years using python, the standard library and 3rd party libraries I've never been left wondering "If I pass X to this method what the hell type am I going to get back". Just like in C/C++ I need to remember it returns a list or a string or a dictionary but that's usually where the mental overhead stops.

Python is dynamic which means it's flexible. Flexibility is usually reached by sacrificing simplicity so Python encourages testing and good documentation. I would argue that these are both necessary features of any good code base, Python is just more upfront about this than a number of languages.

There are more potential connections in between neurons in the human brain than there are atoms in the universe.

Or at least that is the way I heard it.

Well at least getting the word out will do some good. If companies stop trying to establish a presence in Russia because of actions like this then maybe some change will come about. The biggest problem at the moment is that Russia supplies vast amounts of crucial energy to Europe. With that kind of leverage it's hard to see how political leaders in the EU will have the backbone to encourage Russia to stop acting like a corrupt dictatorship.

This is a very big deal. In the past getting ready access to this information required a lot of free time or handing _very_ large sums of money over to the aggregators. The next step is to hook these decisions up these decisions the pieces of statute that they effect.

Well I'd be more likely to use a piece of code if I see that people have constant commits that are raising the quality of the code base. At least this way you aren't just going by commits/releases, you get to see how they changed the quality of the product.

It was part of the Django Dash so the guys only had 2 days to build it, hence the scaling issues :D. AFAIK they are continuing work on it (add support for SVN/HG etc.) so stability should improve pretty fast.