Sure but it still requires trusting them when they pinky promise they won’t send any recall data. Fuck them tbh. It just makes me feel even more right about my decision to switch to Linux years ago.
That’s the part that makes everybody nervous though. Everything from the global dragnet surveillance network to the marketing company behind your grocery store app is most interested in “metadata.”
Companies like Microsoft will loudly say they don’t want your cat pictures and memes and college papers, they’re not tying your usage to an explicit file with your name and favorite pasta varieties…
…BUT that forced transmission of “anonymous user data”, could potentially be super effective in identifying and manipulating you. With enough of it, you can easily put together a profile of an individual.
Heck, for a while, TOR would advise against resizing your brower window because the window size in pixels could potentially help fingerprint you on the web. How nuts is that?!
Most people actually worried about a spook digging through “videosHomework” are indeed paranoid.
But there’s been a lot of research at what can be done even if you’re just “userID 1284hdkfuw724bfiueb”
Also, JavaScript…why are you the way you are? Does anyone have advice for learning it so it makes sense? I can’t even get tutorial projects to run properly…
Because they didn’t want to train their JS developers and didn’t want to cause friction for new projects. They get to say they’re using TS, with basically none of the real advantages. (Apart from general rational error checking.)
And that probably requires not going with a tutorial. Because the JS ecosystem scorns at “simple”. Just make some HTML scaffold and use MDN to understand the DOM.
I like Douglas Crockford’s talks about the “good parts” of JavaScript. They’re old and probably a bit outdated, but he explain quite well the history and why JavaScript is the way like it is.
It clicked for me when I saw them the first time. Still hate JavaScript though.
What Crockford did was enable a lot of devs to realize there was a viable development platform built into the most prolific and open network client in the world. For that he should be commended but it should have never been taken as “this is a viable general purpose language”.
He also showed that JavaScript has more resemblance to functional programming languages rather than object oriented ones. If you try to treat it as an object oriented language like Java (like the seem to imply), you will have a bad time.
Can it even make sense tho? To me JS is an example of a not too good thing that people started too eagerly so now they’re trying to make it make sense.
The problem is that all projects start small, and frankly most of them die small. Aiming for microservices architecture right away is a surefire way to get the project killed before anyone would benefit off of the microservices.
The other angle is the majority of Devs are just… Not good…
A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
I’m saying this as someone who has been mired in scope creep and over engineering solutions many times in my life because “what if 5000 people need to use it at once?!”
In most cases all you need is a database, a single thread and a simple API. Build it and then as the problems come grow with them. Try to take into account issues of scale but realize you can’t and shouldn’t solve every scenario because there are too many variables which may never exist.
A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
Maintainability is one of the most important if not the most important goal when programming. If a dev only designs a solution that fits for exactly the current situation but doesn’t allow any changes, it’s not a good dev.
But yeah, if you start small, a solution that’s made for that is preferable. You can still refactor things when you get magnitudes larger and have the budget.
The tricky thing about software development is this balance: you don’t want to hobble your system by designing only for today, because that could waste a whole lot of time later when needs change, but you also mustn’t paralyze the project by designing for all possible tomorrows. Finding a middle path is the art, and the only proof that you got it somewhat right is that things get done with relatively few crises.
Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.
Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.
Often a simple solution is the most maintainable solution. In my experience, the code that’s most difficult to maintain are often made by devs who tried to plan ahead. The code turns over engineered to allow for stuff that never materialized.
You evidently haven’t met my colleagues. There are always people who go for the quickest hack despite the trouble it stores up for later, and they’re usually encouraged by management.
I always lump microservices architecture as premature optimization, one that should be used when you’re maxed out of resources or everything is too spaghetti.
I love the idea. And I even pitched it for a specific project. But I had to eat humble pie when the devops nerds threw more servers at the problem and it worked better than I expected.
Sounds like that thing was already designed to be horizontally scalable. Was your error related to not realizing that? Or what was the problem being solved by microservices?
Microarchitecture needs to be broken up into components. Those components need to send messages to each other. Components sending messages to each other is arguably the core of what object oriented design was trying to do all along. If your devs were bad at classifying components in an object oriented design, then they’ll probably be bad at it in a microarchitecture, too. Worse, the actual system is now likely spread amongst many different version control repositories, and teams stake out ownership of their repositories. Now you get more blockers spread amongst several teams.
Where the network layer comes into play is to replace something that used to be running in a single CPU core, or sometimes different cores on the same motherboard. Unless you can exploit parallelization for your use case, the kind where you have more threads than the number of CPU threads a single motherboard can handle (which can be several hundred on current systems), this will always be slower.
Being an older system admin this is how we worked. Would generally have an A and B side and maybe C on our stacks. Most of the time what I supported would be A and B clusters in two data centers and then do either 100% on our primary site or do a mix of traffic between our two sites
Most software developers have no concept of real world limitations and issues like tolerances, failure, probability, latency, hysteresis, ramp-up etc. because they’re not engineers.
Normally they’d be expected to at least account for software-specific aspects like ACID or CAP or some vague awareness of the fact that when you’re dealing with multiple systems the data may not always arrive as you expect it, when you expect it. But even that is a crapshoot.
This is why I always write my methods from bottom to top. This way I’ve always got a return statement and I use my variables before they are even declared.
That’s true, in fact I’ve started doing that myself. Same with methods, instead of going and writing the method and then coming back to use it, I’ll write the invocation first.
I could’ve used a lot of things, but I’m on my phone and I wanted fewer characters to render it, whilst being sure it would work without having to run it.
Also, I am pleased to have maybe helped. Perhaps we can be friends, you and I. Perhaps not. Idk, maybe you punch dogs, why would you do that? Seems mean.
Have you ever just, like, edited a comment? How do people know when you did it? I guess if I were writing a thing to check it I’d use a registry of timestamps and checksums… So, like, ok, you can track, but why, how does it look?
Anyway sorry I had some drinks between now and first post, goodnight
Code as given can be made valid in scala I believe. My starter was based on that assumption. I think raku can do it too, but you would probably have to x = $ to make it work…
Edit: misread your comment slightly, CBA to change mine now. It is what it is
Apple Taste Pro is a white sausage-shaped devices that you shove down your throught and controls your taste buds, olfactory system and controls breathing.
Apple always announces products like they are the only ones, except maybe with the first iphone. “this is the best iPhone yet” not the “best smartphone in the market”.
Also they wouldn’t call it sex toys, they would call it a whole new revolutionary class of communication devices.
Personally I wish someone would make headphones that comes with a wireless “subwoofer” that attaches somewhere to your body and vibrates to the bass. The closest I found to this was the Skullcandy Crusher series. But the motors are in the headphones, which makes them bulky. Still, hardest hitting bass I’ve ever heard in a pair of headphones. It is unfortunate that a more prestigious brand won’t take the concept and evolve it.
Don’t get me wrong, they’re amazing for bass-heavy music; they’re just not so great if you care about things like imaging, sound staging, a neutral frequency response, and low latency Bluetooth, none of which the crushers are particularly good at. The Crusher Evo has such bad staging, for example, that they almost sound mono. Makes them completely worthless for movies and games (which is a shame, cause movies and games could always benefit from more bass).
The green Merged means that the pull request was submitted into the branch.
The DO NOT MERGE text is an instruction for automerger. Android is developed in a truly startling amount of related git branches. Automerger is the tool that propagates commits back and forth to make sure pull requests get to all flavours, versions and devices.
DO NOT MERGE tells Automerger not to propagate that pull request to newer versions of Android, i.e. it’s a fix for the currently released version that’s not relevant to the next development version of Android for whatever reason.
Also seen, although more rarely, is DO NOT MERGE ANYWHERE which tells Automerger not to propagate the pull request to any other branch other than where it was originally submitted, including branches for related products on the same version of Android.
Interesting, thanks for explaining. Like someone else was saying it is already in AOSP not introduced in lineage which makes sense since it is just a cherrypick
I won’t claim that J. Random Hacker will have issues understanding it – it’s a neatly tied bundle of necessary complexity without any distracting parts (like efficiency), if you sit down with the thing (ideally starting the whole series from the beginning) you’ll be able to grok it (and have learned a lot). However, understanding HM isn’t the same as being able to extend it, which includes proving soundness of the system, that kind of stuff is a specialised field within a specialised field within academia with more open questions than answered ones. The reason Rust doesn’t have HKTs? Because their interaction with lifetimes is insufficiently understood. Those kinds of questions can easily start 20+ years of research only to be answered with “yep that’s inherently unsound/uncomputable/whatever”.
Oh, EDIT, forgot: AI-enabled typing is obviously a completely braindead idea. I don’t need a second lazy, impatient, hubristic idiot looking at my code, I need something to catch mistakes. Something deterministic, rule-based, pure unerring logic. Which is exactly what type systems are and do.
AI-enabled typing is obviously a completely braindead idea.
I agree. However, and I know I’m practically reading tea leaves here, but I read that last line as a suggestion that AI would replace programming outright.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.