john567

Put some effort into defining scope and prevent yourself from improving your design as you go. (There may be time for that next time)

Know your platform!

If you know exactly how well the different things you need are going to behave you are free to take every shortcut out there. If you're experienced you'll carve out a space for you to return to if you need. i.e. you make things modular where needed.

The first iteration should be working code and unless there's time to make improvements you don't. You move on to the next thing.

I've had a Yubi Key for almost 5 years now. Zero issues.

If you can build this from common basic components it should turn out ok. I think the trick is discovering what your application needs. What kind of interface it should be and what goes where. The it's mostly the same thing over and over again until it's not. Then this exploratory phase starts all over.

I like to draw experience from game engines. They typically build success around a few key components that have well defined constraints. As long as the right constraints are in place it's possible to make a fun experience. If you have the wrong constraints and you find yourself constantly battling the system then stuff is all wrong and you need to find a new approach.

It's a bunch of bureaucrats in Brussels that care surprisingly little about the people who happen to live in Europe.

So how is it that this dysfunctional body is going to produce anything resembling a social network the people would like to use?

I try to reward good behavior more so than I punish bad behavior. Things we're definitely simpler when they were younger but now they lie and make up stuff. I never lie or make stuff up. So, where does this behavior come from? And I never punish them for telling the truth.

But the idea that the bag is some reward and that you can lose some of it if you miss-behave and then maybe earn it back. That's reasonable.

I typically employ a progressive punishment in the form of a timeout. Go to your room for 5 minutes. If they don't respect that, it's 10 minutes up to 15 minutes. Culminating in: no iPad for you today.

Sometimes I ask them what the consequences for breaking the rules should be. And I get very reasonable suggestions.

I think more context is needed here.

I do agree that, as I read this and thought that there's some really nice advice in there this one struck me as slightly off putting.

I can only speak from experience with my own kids and while I try to encourage them and to be respectful there are situations when they need to learn what happens when you cross the line.

I'm not sure people turn out ok if they never experience painful moments and I'm not sure protecting our children from every repercussion is the best way. I'm undecided on this very topic and I certainly try to be positive and encouraging in every situation.

> I've seen many devs work with broken environments and just ignore the problems because it doesn't actually stop them, or because they don't realise it's broken.

That sounds like an educational issue. I work in a small team in a small organization.

He has said, on numerous occasions, that he wants to advance society and make humans multi-planetary. And if that's due to his ego and how he wishes to be remembered then God bless his ego. He has made an amazing amount of interesting things happen!

Remember, he was part of Trump's advisory board, even for a short while. Whatever he learned might influence his decision. And I bet they are going to reverse a lot of bans...

Since Twitter doesn't make money and he's paying a lot of money for it, I wonder how he will turn such a large machine profitable specially when I believe Twitter have a large number of employees that oppose Elon's agenda. This is the most perplexing part to me.

Making Twitter a better place is a good thing though and it is a place where I've spent considerable time. I've been temporarily banned for using the wrong word combination in Tweets and I find that disgusting. I hope Elon can take the user base and improve on it. I do think that this overly suppressive direction Twitter has taken over the past time is the wrong choice. I am cautiously optimistic.

I think the Go concurrency model is a lot nicer, and it's considerably better throughput wise.

As much as I enjoy writing JavaScript is riddled with stupid stuff and lack sensible primitives but I do care about computational performance because I have a lot of code that I want to optimize and towards that goal JavaScript and V8 gets in the way. Even if it's a good VM it can get really ridiculous from a performance point of view.

Having the same code running on client and server when your application is split between running both on client and server is very convenient.

As an example, a React application with server rendering and then progressive enhancements on the client. Very common pattern.

This can be done in different ways but with Datomic you can request a point in time database. This database doesn't exist so it needs to be "sourced" from history. This means running through everything that happened up to some point to create a snapshot of the database state (or query).

First, everything is an entity, so you can enrich attributes with information about how they should manage PII/SPI data. There's nothing built-in but you can build meta models easily.

Second, if you really have stringent requirements you would encrypt the data that is to be protected and throw away the encryption keys when the data needs to be purged.

Datomic does allow you to opt out of history so the keys would not be recoverable in that case.

Or, you just excise the data, at which point the information will be purged from the database. It's not instant, index rebuilds and garbage collection need to take place before it's really gone.

You're in control. The fact that you have history isn't a problem.

Also, because the database is a value. You can easily do mock data and isolated transactions locally to experiment and test. This makes some things easier.

Another cool thing is how you do cross database queries by simply passing multiple databases to a function. It will pull in the subset of the dataset needed to compute the query result. It's that easy to do.

It's not good at dealing with high volume transactions (a lot of writes) it's not too bad but it's not built for that primarily.

You won't be able to "source" and recreate the past without some work and unexpected things will happen when you "source" the past with the most recent code.

It useful but the history aspect is easily misunderstood.

JavaScript is also not the language people write in, it's the target. People compile there code into JavaScript more so that writing it.

The reason you have JavaScript on the server side of things is that it bridges the browser gap. You get to share some bits between your client and server code. Also, if you have hybrid rendering solutions it's really convenient.

You don't exclusively run Node everywhere just because you have Node.

It's a tool that can do some things really well. That's it.

There was even SWF player implementations in JavaScript at this point in time.

Somehow, I don't think the death of Flash had much to do with it. Rather, the app ecosystem replaced a space that, that for a limited time, was occupied by Flash based web stuff.

This isn't perfect but something like, math express things while computation progresses things.

You could argue that a particular mathematical framework is computational but I'm just trying to exemplify a distinction.

He may be off putting at times but when he gets in to it he can be very interesting to listen to.

I find it interesting. He has a lot to prove but good on him for trying to make progress. Who knows what this could lead to.

When you write your code in a way that is akin to what you would do in a static environment, V8 emits additional type checks, if these pass, then it will run your code through a optimized version of the code that makes certain assumptions about the data types in use. If these type checks fail, then V8 will deoptimize the function/code.

Deoptimization needs to happen because the assumptions made about the execution of the code was wrong and the optimized code cannot handle this special edge case. V8 will then revert to less optimal code for the specific case but this code is more general and can handle the special case that occurred.

V8 can and will toggle between optimized and unoptimized versions of your code now and then but it has limits. If it cannot settle on a version of your function that is optimized it will stop trying to optimize the code because the cost of doing so is significant.

When you write your JavaScript as if it was more statically typed than it actually is, you do enjoy optimization benefits from V8.