andrewgodwin

I still find a decent amount of the integration, like KIO, is still there and works well - it puts MacOS and Windows to shame in terms of how I can just interact with files anywhere as if they're native within KDE apps.

It's kind of a shame that Konqueror fell to the wayside, but modern browsers are so complicated I cannot fault them for focusing elsewhere.

This is where I separate "manager" from "leader". As a principal level IC, I'm part of "engineering leadership" along with the senior managers, but not a manager.

The work isn't that different to management, sure, but it is different. You're not doing performance reviews... but if someone is over performing you can help get them promoted and if you think someone is doing really badly you can help get them fired.

Unfortunately, at their stated range of 160nm, you're looking at only getting as far as Big Sur before the entire craft needs a recharge - it's much more aimed at island and port hopping, I suspect, than long distance travel.

Still, I am excited to see ground-effect vehicles/ekranoplans back in vogue!

Author here - it's just to reduce support surface area. I know I'll need PostgreSQL's full text indexing and GIN indexes for hashtags/search eventually, and I probably also want to use some of the upsert and other specialised queries, and it's easier to just target one DB I know is very capable.

For reference, when I say "small to medium", in my head that means "up to about 1,000 people right now".

I'm (worriedly) curious how this will affect people trying to change jobs on a H1-B, as technically you need to file a new petition each time, and I can see them somehow denying those too.

I've replied to the post on the forum, but if this is the default way Jupyter runs then we're going to have to figure something out longer-term. Calling the Django ORM from an async thread just isn't safe...

I'd love to hear your suggestions for changes we could make while keeping it somewhat WSGI-compatible. It took a few years to refine it to where it is now, so it's not like we just threw something at the wall.

Well there's no actual async support for views in 3.0 - we missed the cutoff due to performance concerns! Hopefully it'll be in 3.1.

It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.

I would agree with some of the points - speed (which is stretched over two points), concurrency, and the ability not to do magic as easily, but several of the points (compile time, available developers, strong ecosystem) are not a "versus Python" at all but rather against other languages.

Personally, I see a language like Go and Python as solving different spaces. I wouldn't write a lot of website business logic in Go, and I wouldn't write a low-level TCP redirection daemon in Python.

I can't say much on the subject, at least not without official approval, but understand that the original Lanyrd team have not forgotten about the site; asking us to fix it isn't really giving us any new information (sadly).

If you want to make requests of any kind you're better off reaching out to Eventbrite directly.

There is, actually - the US has a (slightly worse) government data repository, but there's several LIDAR sets of the Bay Area, mostly from coastal surveys.

As long as you can convert the data into a height field it's possible. I reckon you could do contours with interpolation.

I'm the main person in Django working on 2), and this is interesting for sure, though our current code is based on Twisted since we need python 2 compatability (there's some asyncio code, but not a complete webserver yet)

He is indeed - he helped me with the Django proposal, actually. He's the one setting the direction for what to include and what to keep separate.

We're not bringing in the whole of Django REST Framework, just some of the underlying mechanics that are useful for all apps (like content negotiation). DRF will remain a third-party project.

As for Python versions, there isn't any plan to drop 2.7 yet and Channels will work on it. It might be we move to Python 3 only at some point in the future, but there are no firm plans right now.

I agree a little bit, but also part of building out a framework is making choices for people - waiting, looking at the problem space, and picking a solution that most people will be happy with.

There are some projects that Django is not the right solution for and something like Flask/Werkzeug is definitely better, for sure, but I'm hopeful that the work being done here will help out the majority of people; it brings a lot more than just WebSocket support to the table, that's just the headline feature most people run with.

Yeah, it's a fantastic step and we're very happy they piloted the program. The Django Software Foundation has also hired a part-time fundraiser to try and make the project self-sustaining; we're trying to make the project sustainable as a whole and not just a timesink for those who are lucky enough to have unpaid spare time.

I'd say Hyperloop is like normal high-speed rail; you have a few main stations, and then supplement links to those with metro and light rail services.

The DLR article says that, if the solar panels work, it'll last a lot longer - until it gets too close to the sun and the heat gets too great (about 2AU):

http://www.dlr.de/dlr/en/desktopdefault.aspx/tabid-10081/151...

I do like the Surface 3; it's a lovely piece of hardware, Windows 8.1 is an improvement, and for a desktop OS, the touch interface is pretty good. It's the best Windows computer I've ever owned, but I still turn to my Linux laptop for coding; the tooling and packaging for the languages I use just isn't really there on Windows.

That said, they need to improve their messaging - this is the first time, as a Surface 3 owner, that I've heard about this Surface Hub app that lets me adjust my pen sensitivity (and I've wanted that for a while!).

"Best structured" is definitely true - part of the reason we can use it to power all the new Eventbrite APIs is because we can easily remove one or two pieces and swap in our own without breaking the rest. Makes my life a lot easier!

You're free to use Django without the template language - that's a relatively simple replacement and one we're looking into making even easier.

The ORM/SQLAlchemy is a more difficult issue. To some extent, Django _is_ its ORM, and making that modular is extremely difficult. You can remove the ORM, but you'll obviously lose everything on top of it - admin, migrations, generic views, etc.

I personally believe that while the ORM is not as configurable as SQLAlchemy, that's one of its strengths; having a relatively fixed target makes writing things that rely on it a lot easier (migrations would have been much harder given SQLAlchemy as a base, for example).

It will prompt you if an app doesn't yet have migrations and ask if you want it to. That prompt is currently a bit aggressive - asking you every time - but that will be fixed soon.

It does them all at once. The new system knows about interdependencies, so if you have ForeignKeys between apps it'll make all of them in the right order.

No, this is a complete rewrite and a different way of doing migrations than South currently does. There should also be a South 2 eventually that is mostly compatible with this new migration design, for those stuck on older Django.

For anything on Django 1.7 (the version it will come out in), yes, South will no longer be needed. Older versions of Django should get a South 2 in the next few months with a lot of this code backported.

I'd like to point out that this is just a first working version, and there's still some work left to do, but I'm very relieved this is finally merged!

I've seen RDS have significant per-query overhead, and some very, very variable read times - in particular, some simple SELECTs randomly taking > 10s every so often.

Sad to see the recommendation to use MySQL - in my experience RDS hasn't been worth the effort - but I'm probably biased since I already invested the time in automating PostgreSQL replication setup.