gwillz

The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations.

A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.

But weirder is my Chromium supports the non-prefixed requestFullscreen, when apparently it shouldn't?

shrug.

Perhaps the font and weight are contributing factors?

Typically, I've seen it come about because often package creators have no interest in maintaining their invention. Their PR list is huge, all the tickets are just questions about "why isn't my PR merged?". So someone else creates an alternate or a fork, but so does everyone else.

I don't think anyone _wants_ a thousand packages, but there's a disconnect or miscommunication that's holding us all back.

Mobile is (typically) a single mode application situation, as in, there's no need to control volumes of simultaneous applications separately. It would also be easy to argue that almost no-one needs that feature.

My real issue is how to weed out the legitimate feedback from the bad. No one has ever told me how to identify the difference. It's typically, "yay" means you've done well and "nay" also means you're doing well. When really, either of those responses could be a false positive - but which?

Keen to see more on the QtQuick/QML stuff. I keep reading things about how great it is but never had the time to get into it.

For your "good-to-know topics" perhaps a brief direction for deploying applications? Bonus points for mobile deployment.

https://en.wikipedia.org/wiki/Billion_laughs_attack

It got me thinking about it. JSON is annoyingly simple at times, yes. But that also protects it from some pretty gnarly stuff seen in XML and YAML. I suspect it's a considerable contributor as to why it's the choice transport format.

I wouldn't toss it in with XML just yet.

Maybe we don't cut off people as much, but we sure can't do a zip merge without someone getting upset.

A lot of people criticised the tunnel extension into the city. After all, it only saved ~5 minutes of travel time. I don't think most people in Adelaide fully appreciate public transport yet.

Adelaide is often called the 20 minute city because you can just drive anywhere in under that. But that's changing as our population grows. I really hope there are more projects like this that get funded.

Adelaide used to have _the most extensive tram network in Australia_. It was pulled up around the same time as Sydney pulled theirs but Melbourne didn't (because they're the original hipster). Sydney had the money to reinstall theirs but not Adelaide. There's a lot of politics around fixing our trams - we almost dropped 40 million on a building a right hand turn.

https://mobile.abc.net.au/news/2017-12-01/why-was-adelaides-...

I also think you right. Compilers don't always go well with programming inductees. This is why Python and Ruby are so popular as introductory courses. But this is why I think Javascript has done so well because it doesn't _need_ compiling, which is great for new-comers. When things level up and get complicated, enter JS compilers. It's a 'best of both worlds' sort of thing.

I like 'self'. There's a lot to complain about magical 'this' of every other language - especially in Javascript. Specifying self makes it really clear if it's a member method or a standalone function.

Python really likes the idea of 'seek forgiveness, not permission', aka. abusing try/except. But it's kind of nice:

  # seek permission
  if 'key' in map:
      fn(map['key'])
  else:
      whatever()

  # seek forgiveness
  try:
      fn(map['key'])
  except KeyError:
      whatever()

He's not entirely dumb and I've always got the impression that he's not a fan of his own party.

I suspect he knows exactly what he was saying and how stupid it was. But behind him everyone was aggressively nodding their heads.

Joke's on you, we did that anyway.

Imagine light rays coming out of your eyes. For every ray that hits an object, draw rays to every light source from that hit point.

Light in reverse.

In-between those two steps you can figure out intensity and colour of light, the colour of objects, roughness, transparency, refraction, reflectivity, etc etc. You can even bounce multiple rays to other objects for global illumination and whatever.

> It's not Eclipse.

Shots fired.

Also +1 for a good template.

On topic though, I'm too disappointed in Australia not being able to properly about privacy properly. It's come up a few times and the discussions almost made a difference - the ISP data retention policy, the medical database, something-something about the big banks. There are occasionally little stories that largely go unnoticed about the government quietly asking around for back doors and whatnot.

But every time we roll over and show our belly.

Why is it so hard to convince people this is an important issue?

It's good to know that everyone is together with bringing on async rendering. Thanks for your efforts!

Anyway, as soon as I realised that the two are complimentary, I was always kind of upset at articles like this that misled me for so long.

There was a post on HN that was asking about real-world examples of asyncio code that wasn't `asncio.sleep()`. I think my project is pretty good example for that - and a strange example too because it involved a lot of hardware interfaces.

I've been meaning to open-source the project ever since we axed it. I was the only real programmer on the job, so I'm itching for feedback on it. So if anyone's interested I'll post it here.

I had actually written it 3 times over. First as raw socket server, then in twisted, then on top of asyncio.

So yes, asyncio is a bit of a mess. It's documentation is a bit odd and I have several gripes. What helped we was realising that there was an 'async way' and an 'callback way' to everything in asyncio. So not mixing the two together and ignoring the callback parts really _really_ helped.

I don't know if this is true, but I recall reading somewhere that asyncio was not designed with coroutines initially and this explains the dual-personality of the library. I can't find any evidence that asyncio existed before 3.3, so I can't back that up.

3.5 released true asnyc/await based on the `yield from` form and then 3.6 allowed for async generators.

You were close and your point remains. Although I don't think new tags are the right choice. I think HTML learnt a while ago that more tags doesn't solve everything.

I do really enjoy python async. It's cool to see a feature develop from a hack like that but a language first approach could have avoided some headaches. This is where Grid wins, it's a fresh take without requiring to maintain backwards compatibility with previous attempts.

https://wiki.theory.org/index.php/YourLanguageSucks

You'll find something you like over the others. But it's all just syntax at the end of the day.

The real mastery is programming paradigms. Some languages lend themselves to particular methods and some just can't, or can't do some easily, but just knowing that is important too.

I believe there was a HN about this a while ago but I can't find it.

Literally the first thing I install on a fresh box.

It's hard for me to face stats like these. I can't imagine a world without helmets, much like cars without seatbelts.

Why are people trying so hard to kill mandatory helmets, can they honestly do that much damage?