duke_sam

I understand the need to have the schema where it's being used but if you ever need to make modifications like custom fields (say an email field) then your schema isn't just stored in the DB any more. With Django your custom field declarations live in the same place as more mundane fields. If you port that models file to another machine and run syncdb you are going to be left with the same schema with the same restrictions.

If the Django community is so closed why are over a third of the attendees new to Django? If the community was closed and insular we wouldn't be seeing so many people who are at their first DjangoCon and who are eager to contribute to Django.

The current setup is not perfect. The core team, especially Russel, have been very forthcoming about this. They are openly talking about things that need to change and how to change them.

I'm pretty sure if you try to submit the same link multiple times HN will show you the originally submitted story.

It's an extension of the critique leveled at dynamically typed languages by Java/C/C++ devs. How can you possibly work in a world where function foo can return/expect any type?

The more dynamic (powerful?) the language the more leverage good, experienced developers have. They can achieve results in 10 lines of code that are hard/impossible in more static languages (closures, meta-classes etc.). The other edge of the sword is that one dud developer can bring your whole stack down by being too smart for their own good. The more dynamic the system the greater the risk. In Ruby as is pointed out you can have a developer on the other side of your code base royally screw you because he wants feature X of sequences to act differently.

As with all things it's a balancing act, how smart are your devs, how much time can you spend testing and how strict are your coding standards.

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.