spronkey

Yeah, I agree. Lazy loading in ORMs what happens when people want OO databases. And by OO databases, I mean everything to act like it's in an in-memory collection.

Sounds nice, but in reality, latencies, networks, massive data sets, atomicity of operations, and a whole host of other annoyances get in the way.

... so it ends up being simpler and easier in the long run to be very explicit about your interactions with data stores. Took me a long time to get to this point.

I'm struggling to understand how the transition from integration test to unit test might manifest in terms of a real world refactoring.

My 'integration tests' almost always cross the boundaries of two or more (theoretically) well-defined APIs. If they're within those boundaries, well, they're not really integrating anything, so I would just consider them a unit test.

Do you have any examples of this?

What kind of MacBook did you use, and did you plug it in to an external display?

My 2013 15" MacBook Pro is extremely loud when plugged in to one or more external displays. Seems to be related to the fact that its fans are either off, or at 100%. Or at least have a very late, aggressive curve. It's also very loud when the CPU is constantly pegged at 20% or more, which is basically a given when running Xcode.

I can offload some things to the cloud, but I can't offload my UI and local apps, which are the things that cause the really loud noise.

When it's under a light load, it's very quiet - moreso than most non-Apple machines I've used. But under heavy load, a number of other machines seem to be much better at expelling their heat without sounding like a jet engine.

This. Make it upgradable. RAM and multiple M.2 please.

And make it shut the hell up, or let me offload compute to something that has big fans.

Too bad it had a terrible name...

Seriously, doing bulk emailing you find that mail services are often the dustiest, cobwebbiest things on the internet. I swear some of these things have been sitting untouched for literal decades.

In more than one industry I work with it's nigh on impossible to gain access to DNS records for bulk mailing purposes. Third parties may hold control over domains, and your emailer may not be important enough to get someone to actually put in a work order to get records changed etc etc.

Not always easy to fix the human side.

Ultimately you're not going to get the best deliverability unless you have access to the DNS records you are sending from, because you won't be able to pass DMARC.

However, you can still pass SPF and DKIM checks by using your own domain, which involves taking advantage of SMTP's envelope sender address. This can get you acceptable deliverability, assuming good IP, non-spammy content, low volume sending, bounce management etc.

There's a pretty good StackExchange answer here that explains the differences between SMTP envelope and message aspects in more detail: https://security.stackexchange.com/questions/30732/why-is-it....

There's also a good MSDN blog post series on the various email authentication techniques and how to get them working: https://blogs.msdn.microsoft.com/tzink/2013/04/24/how-to-set...

The gist: set up an address, and SPF and DKIM on a domain you control, and use that address as the SMTP envelope sender. Then "spoof" the FROM header.

The caveats: this technique is still used by some spammers; some clients will display "From: (your domain email) on behalf of (actual sender)"; some MTAs use SenderID which applies SPF to the FROM header's domain; some (but not most) providers almost need DMARC to get bulk email to the inbox nowadays.

And a second hammer in a geographically separate location for resiliency so you can bill three times.

IDEs can still substantially aid in refactoring with runtime type checking and return type annotations - see WebStorm and PHPStorm for two good examples of this. It isn't perfect - but certainly for things like changing the return type of functions, it will usually get you at least 90% of the way there.

Now, whether you consider that's actually helping solve the refactoring, or actually introducing new bugs, well - that's another issue :)

I miss Opera 12 so much :'(

This is basically the workflow with TDD though, and if you're writing a large number of tests up front, you're certainly doing it wrong.

I would agree most of the time. However in my experience you often end up with at least some small part you have to figure out how to test-drive - i.e. using a dependency. Then you have a choice of "TDD this and write proxies or some other kind of wrapper around everything", or "just go with it".

Amen. And this is what spikes are for :)

I TDD, but I don't TDD my spikes. Sometimes I write an almost working system before I start actually working...

Definitely seconded. Do a bit of .NET (non-core) maintenance too, so it's not like I'm completely unfamiliar with it.

Though, maybe legacy knowledge isn't helping...

Whoever posted this took a very, very pessimistic 3770. Here's a much more representative result: http://browser.geekbench.com/v4/cpu/compare/3036382?baseline...

I also have strong suspicions that real world workloads that aren't so cache-optimised would swing massively in favour of the 3770 as well. The best benchmarks we have of that unfortunately are things like 3DMark physics bench (the old A9X was half as fast as even an M-5Y71 in that benchmark).

It's also worth noting that for TDP comparisons, even Intel's own 35w and 45w parts compare favourably to the desktop parts, and newer generations increase this gap substantially. Some multi-core geekbench scores per watt (higher is better):

77w i7-3770: 162 - 45w i7-3770T: 255 - 45w i7-3632QM: 257 - 17w i7-3687U: 315

3.5w - 7w i7-7Y75? 900 - 1800.

A10X, assuming it's 5W TDP? 1800.

Well, Intel kinda paved the way for most of the performance improvement ideas in these CPUs already. The fruit is hanging further and further up the tree.

It's unlikely that the A series would be able to compete with the Intel CPUs at significantly higher TDPs from the get go - especially when you start considering interconnections between cores etc. They might be able to get close to lower TDP desktop i5s, but then just look at the difficulty Ryzen is having at doing just that...

CPU performance doesn't scale linearly with TDP at all. Even Intel's own lower power offerings look insanely awesome when you consider performance per watt vs their higher end parts.

Well, it is somewhat on iOS because somehow Apple's software gets extremely heavy. Wirth's law or something. The iPad 2 used to feel pretty damn speedy, now it's an absolute dog.

It really does. Especially when your options for "walking away" have similar bullshit authoritarian contracts.

Also, considering how much money megacorps can make of employees' ideas, I'd say that many aren't fairly compensated at all.

Doesn't the "we own all your output" line also sway employees against pursuing their own potentially world-changing ideas as well? Is that good for everyone?

All else being equal that's usually true though - a 750W model of the same PSU will usually draw more at 75W output than the 650W model of the same PSU. But with 80+ gold and above the difference will be negligible.

But what if I could plug my phone into a dock that gave me substantially more power, but I didn't have to make a massive context switch i.e. wait for syncing over a network for files etc, or log in again and load up what I already had open?

The charging light was a good innovation back when Apple introduced it. The rationale for having it there hasn't changed. Removing it was a clear regression.

Yep. I'd also mention how many viable alternatives to Google products and services they have shuttered because Google offer theirs "for free".

They have an almost-monopoly on the advertising space, their resources and size make it difficult for others to compete with them, and they treat their users like dirt. Wait sorry, they don't have any users, they have products. And they treat those like dirt.

I wouldn't give Lithium Ion-based stuff to kids to play with unsupervised. NiMH for the win.

It is highly unlikely that thermal runaway was caused by the computer overheating.

It's far more likely that a defect in the battery caused this. Perhaps the laptop tried to draw too much power from the battery, and it failed.

The craftsman: https://www.youtube.com/user/PaulSellersWoodwork

The engineer: https://www.youtube.com/user/Matthiaswandel

And the madman: https://www.youtube.com/user/stevinmarin

foobar2000 might be customisable, but it comes with terrible defaults in comparison to WinAmp UI-wise. I've tried foobar2000 a few times, but I never have the energy to make it work nicely.

It's better on macOS. But it's still awful. The benchmark here is actually iTunes itself, which was substantially better 5 years ago.

For another example, a thread today brought up Winamp. Winamp's last major updates happened, quite literally, a decade ago.

This is a player that works just fine on Windows 10, and there's definitely a case to be made that it's better [overall] than any more modern alternative.

This type of software can never happen on iOS, and is quickly becoming a relic on Mac OS.

The core principles of good software haven't changed much over the years. UI (in HCI terms) has in many ways not moved forward much at all. Apple are changing their platform it seems, more for the sake of change, than for the sake of real progress. And they're forcing some really good software out because of it.