It's an odd term, but one that inadvertently brings attention to concerns such as privacy and identity persistence.
Such concerns are far less obvious to laypeople when terms like "real-time modeling of traffic flows" are used. Perhaps, the choice of term is fortunate after all.
Sometimes it really shows that many early Wikipedia articles were someone's labor-of-love about a relatively obscure topic, and even today there's uneven levels of notability across the encyclopedia.
Instead of these hyphenated iron laws of transportation demand that no one has ever heard of that all say the same thing, the article of "induced demand" ought to suffice, and these formulations, if they exist original sources at all, ought to become references in that article's footnotes.
The clearest benefit of conferences for developers is networking and the "hallway tracks" -- the emergent discussions that arise after talks. The social processes of these are hard to replicate online. The asynchronous nature of online text chat, perhaps the most apt widely-deployed alternative, already lessens the urgency and spontaneity of the discussion. There are people who don't take advantage of the opportunities to insert themselves into emergent conversations, and unless their presence alone is a positive signal for the company, they're largely wasting their company's money.
The clearest benefit of conferences for sponsors is the potential lead between frontline-but-backoffice workers who work on a particular topic to the decision-makers behind them who can influence purchasing. Being present at conferences fosters passing familiarity of developers with the product, which helps conversations that occur between those developers and their bosses later: the emails from the higher-ups that ask "what do you think about Product?", and the off-the-cuff gut assessments that follow. Irrespective of the developer's initial reaction, name recognition of the product sticks around and often makes it to later rounds of evaluation and assessment.
This whole case is contrived, and both actors acted in bad faith, so the outcome will be troubling no matter what.
If Oracle wins, others can claim that their API is copyrighted and weaponize copyright law to sue anyone they don't want to interoperate with them -- despite the whole point of APIs being that interoperability.
If Google wins, it means anyone will be able to hijack the syntax, semantics, and interfaces of an ecosystem verbatim for commercial ends to promote an incompatible implementation, like they've done with Android. To protect against this, patents and NDAs will proliferate, and black-box organization and SaaS business models will solidify as the only (commericially) sensible way of distributing software.
In a JWS the header is integrity-protected by the signature if the alg isn't none. This is prominently noted in the specs and alg=none artifacts are referred to as "unsecured JWS". In a JWE the protected header is integrity protected by the AEAD cipher, because all encs must be AEAD.
The alg=none substitution issues happened because of bad usage of mediocre libraries. Other algorithm substitution can arise for the same reason. The invalid curve attacks were the ones that the spec didn't call out as a security consideration.
I support the arguments that say algorithmic agility is a bad idea and a new protocol with algorithmic agility shouldn't have come out at a time when other protocols (like TLS) were finally starting to catch on to this fact. But the JWT cat is out of the bag, and won't go back in: it's widely deployed and people are using it thinking it's solving problems they actually have. Education is the proper remedy.
The PASETO effort attempts to provide better answers and better design to an audience familiar with JWT, but there's also been an uptick in the kind of advice that heavily condemns JWT without supplying some migration paths. That latter brand of advice is harmful.
Most people use the JWT compact serialization, which cannot carry the unprotected header at all. If you're exchanging JWT compact tokens, the header is protected by the signature or the encryption.
Much of the ahead-of-the-curve, aspirational tech stack posts featured on HN are the blogging equivalent of Instagram-polished shots. On a personal blog they're equal parts self-expression and self-promotion; on a company blog they're equal parts deep dive and recruitment teaser. It's okay. Some readers will feel intrigue, some confusion, some envy. They'll wonder why they can't use those new tools at their work.
It's nice to recognize there exist developers who seem to stand apart from the vocal ones who make these posts, but they're not a single class. Some brag just as much, just in different circles. Some don't brag, but they do lots of good work. Some put out work that's not so good, and they may or may seek to represent their accomplishment regardless. The only factor they clearly share is their underrepresentation and their lack of attained popularity in talking about their work on social media.
As tempting as it may be, it's a big reach to conclude due to their underrepresentation that their tech stacks are conservative, or even dated; it's not a given that their work is solid and they're hard at work solving business problems given numerous constraints and office politics. Efforts to define this population by their rejection of shiny hype just perpetuates a kind of fictitious class divide between "fancy" developers and "plain" developers, when the real class divide is between management that is desperate for results, and IT workers that are desperate for empowered decision-making and resources. Businesses are under tremendous pressure, and silver bullets read about elsewhere carry great appeal. Transplanted organically by enthusiastic developers or by order of management, such solutions rarely work, because changing just a few inputs of a complex process won't deterministically give a better result. And mediocre results of a messy process make for a different genre of writing.
Maybe there's a class divide after all: between developers who are privileged enough to cook up all sorts of clever, custom solutions to challenging problems and can write about it, and those who spend their whole workday surviving the onslaught of nonsensical demands and deliver something mostly working in the end.
PayPal Cash Plus has a ton of features, but there's lots of fees [1][2]. You earn no interest. It's not a good deal, other than it being familiar.
Square Cash, now known as the 'Cash' app, is a strange hybrid of a P2P payment network and a spendable balance that gives a debit card and you can direct deposit into. You earn no interest. It's odd. It targets a hip young consumer who wants ease and convenience and doesn't know any better. It has... some... virtues? Just not ones that make it worthwhile to use it instead of some rival that earns interest.
Depending on your exact use-case, it will vary which one of these is ripoff-tier and which one is so-so. I have a low opinion on nickel-and-diming fees for convenience features, so I find the PayPal Cash Plus offering the most grievous. Square Cash just has a weird use-case that isn't my use-case.
See the history of the Stabilization Act of 1942 [1] and Executive Order 9250. Wages were frozen by law, but not benefits, so companies began offering benefits, including health insurance [2] The next year the IRS decided these were nontaxable, until it changed its mind in 1953, only to be overruled by Congress in 1954 [3].
It's disruptive as this kind of product moves downmarket, at least in the sense of mindshare and marketing, if not always in terms of customer segment. These accounts may be common knowledge among people who invest online and interface with brokerage firms, but others might not know about them.
The recent marketing tactic by newer firms is to convince people to migrate from checking and savings accounts, to catch the demographic that has (for whatever reason, presumably related to cashflow, lack of info, or generational anxiety) already decided that online investing may not be for them. Perhaps they'll change their mind once they're past your acquisition funnel.
I didn't see 'cash management accounts' on the list, but I think these are among the best products. They're not too common, but more are appearing now.
There's the classic ones that combine various investment products and slush balance that's insured by a bank sweep in the same interface, and the new ones that abstract completely away from the underlying storage of the money, and provide some familiar features (debit card, bill pay, ACH transfers) and perks (high interest rate, no fees).
The latter kind is a great, low-risk, low-effort store of spending money for people with unpredictable income and/or spending who have little time or cushion to invest in products with higher returns and need the liquidity. It's a compelling alternative to a traditional US checking account at a large bank, where most of this demographic has their money.
Tumblr's adult content ban was likely a last-ditch effort by Tumblr, encouraged by owner Verizon, to salvage some business value out a hectic social (re-)blogging site that seemed like a questionable fit even for the previous buyer Yahoo.
Verizon embarked on an ambitious effort to be a force in online content and display ads, so that they'd produce worthwhile content that would contribute to them running a bigger and more successful ad network. They bought AOL and its magazines to make it happen, and a few years later they acquired the content arm of Yahoo when Yahoo pivoted to an investment holding company.
Porn blogs were a big and visible part of Tumblr, but Tumblr's unwillingness to use coarse filtering meant that they were poorly policed. Porn blogs were overwhelmingly run by bots and hosted stolen content, they'd spam-follow unrelated accounts to game search engines, and they'd generally be a nuisance in every way, despite attracting a fair amount of viewers. The Apple App Store fiasco gave a convenient pretext to roll out the coarse filter to whack porn blogs and make the site more palatable for advertisers, but the collateral damage also affected erotica, art, sex-positive communities, and various LGBTQ communities. Meanwhile, ads on Tumblr have gotten a slight bit more frequent since the Yahoo days, but hardly any more relevant or less low-rent.
The author is clearly passionate and brings a lot of detail, but it was always my amateur impression that Walmart won primarily on footprint. They covered the country in stores, and not just the suburbs, but also rural America where the likes of Target and Kmart never ventured, and shops with much smaller selections and different formats were the norm.
I don't perceive Amazon as an 'unbounded' Walmart like the author does, but as an aggregator as thoroughly analyzed by Ben Thompson of Stratechery fame. They bootstrapped a destination with undifferentiated products, a broad selection, and convenience, and later bolted on a marketplace to further capitalize on the traffic. But the dynamics of customer-facing marketplaces are very different from those of internal ones like those of Walmart and McDonald's. McDonald's puts out specs and has suppliers compete for restaurants' buys, and Walmart and Costco have immense purchasing leverage with suppliers, this process results in optimizing the desired quality-to-cost ratio the retailer wants to target.
Amazon, on the other hand, is a free-for-all, where selection is overwhelming, products with obscure branding appear to rip each other off to the point where no obvious choice rises above, human curation is absent, reviews frequently appear gamed, prices change arbitrarily, products are gated behind Prime and are subject to obscure shipping math, and despite being long perceived as having low prices, pricing on products is now being used as a signal. Amazon is hardly anything more than a digital flea market, where Amazon is the landlord and some of the vendor booths are staffed by them directly. A wildly successful and profitable one, and one that draws marketshare away from traditional retail, but it diverges so far from the formula of retail that comparisons with them are of questionable value.
Not sure if the comparison to Conway's Law works. The key goal of layering is abstraction, so that one can be productive without having to know details about the layers below, but much of optimization is about exploiting details in the layers below for gain. Clearly, these goals are in conflict.
After posing a hypothesis, the post talks about security and process isolation. But the problems raised aren't in line with the hypothesis: the challenge in these cases isn't "insufficient communication" between the levels of the stack, but rather a discrepancy between the abstraction's actual behavior vs. a human's desires and expectations about big-picture topics.
These abstractions often compromised by information leakage through side effects that executing code can observe or deduce, leading to the class of vulnerabilities that have long been around, but have received far more attention since Spectre.
Protecting against timing attacks and other side-channel attacks requires the observable state of the system to not vary due to execution in a different security domain. Timing attacks are particularly frustrating, because processes can estimate their execution time even without external timers, so it can compare the time taken between different calls. Cryptographic operations often take special care to avoid leaking information through timing, but the same discipline isn't commonplace in system calls or userland code. And shared caches will leak info in timing but greatly improve performance.
Hardware isolation is an effective solution for curbing timing attacks for systems that don't communicate over a network. It's not sufficient in the case of networked systems, because the network and its connections form another source of observable state that's likely full of unrelated side-effects.
Discord hits a sweet spot of design choices that make sense for online friends occasionally intermingling with strangers on the Internet. It's free and has share-URLs to onboard into the product, it's pseudonymous so one can be known by a chosen persona, it's centrally hosted so DOS-attempts don't impact users' networks, but the management and moderation of channels and spaces is distributed. History is searchable, 1-to-1 conversations exist, voice chat is optional but effortlessly available.
IRC is the ancestor of this kind of chat, but IRC isn't as widely known as it was in past generations, it has connection privacy challenges, and has a less cohesive service identity and onboarding story that people have come to expect with the spread of centralized services. Slack is another modern, centralized take on IRC, but reveals one's email address, and multiparty voice chat is gated behind paid plans and limited in size. Gamer voice chat systems are decentralized and are lacking in text chat. Old instant messaging networks have been shut down, new ones either don't have desktop clients, don't have a good group voice chat, or reveal personal info. Skype was fine on all three and was a hangout tool for many, until Microsoft ran it into the ground.
It's a bit of a meme now that companies are putting out chat services yet no one can do them right. Surely there's economic forces at play, and rich media chat is probably expensive, but there's companies with very deep pockets who could run it as a loss leader just to starve their competitors, to commoditize their own complements. But cloud storage for individuals or video hosting like YouTube is also expensive, yet an upgrade path exists for users who want to pay. Google has thoroughly ceded chat to Facebook and still can't sort their strategy out, Facebook is just now realizing that they could tackle a more private chat too and they could satisfy that demand, Microsoft has morphed Skype into everything from Windows-integrated platformwide IM to a bad Snapchat clone and back again to a WebRTC shim, this time with a Chrome-only client. Asian apps capable, but are focusing on other markets and aren't as well known in the US. Telegram still doesn't have group voice calls. VC companies focus on the enterprise where willingness to pay is higher, amounts are higher, but use-cases are different.
I agree with the points raised in the writing, but it mixes automation, abstraction, and industry consolidation as if they weren't separate processes. As such, the transformation being described isn't an impending cliff, but an ever-present pressure of economic forces that affect all business all the time, and one is wise to watch for.
Automation replaces repetitive work with tooling and work that's more complex. Abstraction allows one to delegate to another for details, which may include choosing from a palette of pre-made options. Consolidation will come about as fewer independent players can sustain themselves in the market. Some will be out-competed by economies of scale, some will be starved by restrictions on intellectual property and lack of access to expertise.
This process has already played out for "small business websites", yet there's still lots and lots of web developers and web designers employed or freelancing. The current wave of WYSIWYG website generators is actually very good, and they have add-ons and integrations that make sense for their target market. But plenty of clients don't want to mess around in it, so they'd rather hire someone. This could be maker of the generator, or it could be an outside consultant. In either case, the person brings judgement, experience, and creativity, to tailor the deliverable to the needs of the client. These are skills resistant to automation, but not immune to abstraction and consolidation.
In the end, the antidote is the same as it always was: be adaptable, be personable, be resilient, and be resourceful. These are especially important in one is in a comfortable job shielded from most competitive pressure, because they will be the most surprised and unprepared if their current employment is made redundant.
1. Communicating clearly in 'business language' is essential when the junior developer interfaces directly -- not through an intermediary -- with business people and stakeholders. This tends to happen in heavily siloed BigCos, especially in places where IT is just a business unit among many, much more so than in SV or startups. But it's also a skill that one rarely has an opportunity to use in isolation, away from the pressures of estimation, project management, of implicit requirements-gathering by listening to business units segue to different business problem, and sometimes of fudging and obfuscation and make-believe falsehoods to soften the impact of reality. These are complex dynamics usually played at the senior team lead level. Most team leads know this, and don't subject junior engineers to this game with no help.
2. These sorts of high-level expectations tend to get peddled around a lot, not the least bit because it's both noncontroversial advice and a desirable baseline, but they aren't even always necessary. Often, the systems one will work on already exist, they already don't conform to an idealized model because of a series of fixes and mistakes made under pressure. These points are a stand-in for saying you should design and code in a way that future maintainers can make sense of what was written. Sometimes that's using patterns and strategies that are well known, instead of a contrived variation. Sometimes that's staying true to the existing design of the product and the codebase, because tacked-on parts in a different style will increase complexity of the whole.
3. Interfacing in the design and mechanical sense, and achieving that design consensus using interpersonal relations are really two separate skills, and once again it's reasonable to expect that consensus to be set not solely by junior staff between different business units. After all, interfaces and system boundaries ought to have business significance -- not only because of the implications of Conway's law, but also because interfaces and their outputs are often the only orgwide-visible products of the business unit. They must stand up to, or meet the challenge of future pressures such as planned re-use and enhancements, some of which will conflict with the intentions behind the original design.
Well, the people who dismissed the term 'serverless' early on as trite, misleading, and vague were proven right: these days it's a cloudy notion about something loosely cloud-related, such that posts like need to exist that can clarifying all the possible meanings with one-liners using real terms of art; yet the term clearly has cachet with technical-ish and nontechnical decision-makers as a Solution that unlocks Value and other more-good-than-bad outcomes that are bullet-shaped and made out of silver.
Players who jump on the term train are complicit in milking the confusion of people for gain. And that's perhaps much of the reason why we haven't unlocked the concept's value. To move forward, it would be useful to clear the air at the start, but the direction that consultants, customers, cloud providers, and developers will take the message is far from certain.
In a typical BigCo, much of the "soft service" processes are run by their own group, far removed from the reach of the automation implementers whether they're internal or external.
A top-down mandate to bring increased automation will require the implementers and the business unit to meet, agree on requirements, and exchange detailed information about the existing process which may or may not be formally codified. This process is frequently done without the involvement of frontline service workers, so the information being exchanged is done by people at least one step removed from the details of the work, and it just gets worse from there, like a meeting-filled, high-stakes variant of the telephone whispers game.
The opposite case is where a business unit develops their own highly computerized solution, but the process, when discovered, is unacceptable to the BigCo. The subject matter expert can seldom contribute technical artifacts into the sanctioned rewrite, so the rewrite becomes an imperfect facsimile, and the subsequent migration will cause issues.
In both cases, much of the conflict comes from the users of the software not being contributors to the software, in a broad sense of that word. And, service unit employees are often already tiered between process administrators and task executors with no obvious path of advancement between them, such that the frontline workers can be automated out of a job entirely. On top of the organizational barriers, this creates a structural disincentive against contributing to a solution.
Such concerns are far less obvious to laypeople when terms like "real-time modeling of traffic flows" are used. Perhaps, the choice of term is fortunate after all.