tomseldon

They give permission to modify their computer/device, but obviously there's an implicit trust that it isn't going to do something horrifically bad.

Trusting a builder to come in to your home and change things- you'd be pretty angry if they took down a supporting wall to put up a new light fitting (and you'd probably have some legal comeback).

I'd like to see that out of pure curiosity, but I would almost definitely struggle to get excited about it without the human element.

I think most wouldn't be that interested if there wasn't an actual driver (in the car, too, not some remote thing), even if it's ultimately faster.

I like also how the README disagrees with itself several times on what tech it's using :D

> Angular(4.2) E-Commerce front-end framework for spreecommerce

> built with ️ using Angular2, Redux

> built with ️ using Angular 5, Redux/ngrx-store 4

> Current version of Angular is latest release 4.0.0.

I don't mean to sandbag the project at all, it looks good (I haven't really dug into it yet)! But would be nice if the README could decide on what it actually is. :)

Redux is a paradigm for handling data flow / application state in an application, whilst Angular is the framework running the application.

They're not mutually exclusive :)

Without using something like Redux, you can get by just fine for small apps (and arguably it could be more of a hindrance and over-complication than a help), but for anything more serious it can help a lot.

Similar acceleration figures to a litre sportsbike (though the new Roadster takes it to a faster level again, but still in the same ballpark).

The acceleration is mind-bendingly fast at first, but after a while, you get used to it and it just feels kind of normal. I can't imagine the new Tesla being any different.

Not to play down the achievement at all, those stats are amazing! But highly doubt there's a health risk associated with some mild longitudinal G forces, assuming you're in otherwise good health.

A few places have reported this, but it's slightly misleading as what they've actually said is they'll stop making "gas only" cars by that date. So, a mix of hybrid or all electric.

That might have been what you meant, but just pointing out that it's not necessarily "all electric".

I've had all of these problems where I've had to roll my own solution in some way.

Whether that was trying to get source maps to work when compiling + minifying via Google Closure and Webpack, or using Babel and Webpack back when the underlying source map util (I forget the name) didn't support certain things and having to fudge it myself (I forget the specifics).

They worked, but they were fairly brittle.

Now, tooling seems to have been improved a lot and using things like `angular-cli` means I don't have to do any of the setup anymore and I haven't had these kinds of problems in a really long time.

Ok, the delay from output to showing the source map is still an issue, but it's not one I find a problem. A few seconds after page load is acceptable to me before going digging through the source, and any breakpoints set in the source files continue to work.

Overall, for me, the weak point wasn't the source maps themselves, but the idiot setting up the build tooling to make them possible (me). :)

If you're in the UK, have a look at Monzo. Not a credit card, but very useful to use abroad. They don't charge a transaction fee when abroad, and the currency conversion is tracked to the MasterCard rate (whereas other providers tend to do card issuer + their own cut on top).

Result is it's very cheap to use abroad. :)

Testing the change is one thing, but if the original people were hired and asked something very similar, you have an existing group selected based on that characteristic and so will likely do well.

e.g. if you have always done a whiteboard interview, then you've selected for people that do well in that type of scenario. Changing the question but keeping the format will likely just prove that those people are still suited to that type of task, but not that an otherwise good hire will be filtered out.

I'm not against whiteboard interviews or similar, but just pointing out that selection bias is an important factor here if you're judging effectiveness by comparing it to results for existing employees.

I disagree that there's no positive effect. A difference in code styles can introduce cognitive load, though naturally the actual effect will depend on the individuals involved, and the actual differences (for some, I agree it could be a non-issue).

> Hopefully, you feel as passionately as I do about your own stylistic choices. My approach works best for me; but, it's not for everyone. And, clearly, other people's choices don't thrill me. It's a completely subjective matter.

I do not. I do have preferences, but I'll let them go quickly in favour of following a standard convention for a given project. I care more about consistency than my own subjective opinions on code style.

I would agree that manual code style checking is painful. I've previously used jslint, eslint, tslint, etc. and I always forgot to run it locally, and then get frustrated when it inevitably failed during CI. There's tooling to address that (syntax highlighting in editors, git hooks, etc.) but it doesn't completely alleviate the problem.

Personally, I quickly adapted and the initial friction of adjusting my workflow (and co-workers theirs) meant a more consistent code base. I was pretty happy with that.

Lately, I've been using Prettier.js that runs on save, and frankly I think it's fantastic. I don't always agree with the specific format it's chosen, and there's at least a few things it doesn't handle (e.g. superfluous new lines), but for the most part I no longer need to think about what my code looks like (stylistically, anyway).

A lot less cognitive load, more consistent code base.

Infrastructure wise, I'm absolutely guilty of this as well. I have found that there's a middle ground...

You (probably) don't need the microservices and the complexity that comes with it, upfront. A monolith (and the simplicity in terms of deployment, logging, monitoring, etc. etc.) will probably do early on.

However, you don't want to shoot yourself in the foot for when it turns out you do need those things.

I try to write code in self-contained modules, with well defined boundaries, and glue it together in a monolith. If/when it needs to be split out into separate services, it becomes much easier.

So, application/business logic code: keep the standards high, do shit properly. Glue code to keep it all together? Less important. You can rip that out later and move to different infrastructure with the same code.

That's very generic advice, and I seem to always break my own rule on this at some point... but I find it's a better mentality for when shit just needs to get done.

Doesn't help with tech choice in general though (and I'm often guilty of this as well...).

So this is a shameless, inexcusable plug but as it's relevant to the blog post...

If you're using Google Closure with Gulp in your work flow, you may find gulp-gjslint useful (https://github.com/TomSeldon/gulp-gjslint).

It's a gulp wrapper around gjslint, I. E. a Google Closure linter. :)

After visiting the site I got a desktop notification thanking me for subscribing. I neither subscribed, nor allowed desktop notifications for that site... Not sure what's happened there, but can't be good!