I'm in CO so pay a lot of attention to this as it's a law to post salaries here. I really haven't seen THAT many CO excluded jobs. I definitely have seen them. More often than not I just see no mention of the statute/salary at all.
this looks like something i could host for the community, but wayback is having issues letting me look at more than just the page you linked. If you remember anything about the architecture or how the data was portrayed/displayed, email me at my webzone (i just updated my profile).
It looks like it was manually vetted, which i could not do for the community. i could see it being gamified or otherwise attacked, and i'm loathe to say it but LLM+RAG and a way for users to flag records might suffice to start.
In fact, what might be easier is a fediverse bot or similar that is both input from users to a job posting URL, as well as posting automatically vetted "excluded in <territory>" that's backed by an rss feed of a simple LIFO index page. That way you get the best of all three worlds for the UI and i don't have to set up email.
It would have to be "REMOTE (US EXCEPT CA, CO, CT, MD, NV, NY, RI, WA)" unless there is something different about the WA transparency law that I don't know.
Yahoo at the time was clearly underestimated from a developer point of view. Everyone just saw them losing ground to Google in web search, but they had a really strong development team at the time. Lots of great stuff was open sourced, even though they did not win the same status as Google
- YUI was a really good frontend framework based on components and events. It was so easy to create complex interfaces compared to others at the time.
- Hadoop open sourced big data management
- Vespa was a really good search engine in terms of performance and functionality. It seems to still be alive at http://vespa.ai
- They provided several useful APIs without the restrictions that Google and others often placed on their products.
They made some bad strategic decisions and other business decisions, but they had a lot of exciting technology that was often overlooked.
Yahoo should have pivoted from "web services" to IaaS like Amazon did with AWS, because it was no secret that Y! employed some of the best data-center folks besides Google and Microsoft. Could have been a different story?
I've used it briefly. I don't necessarily think it was too early but it was such a niche tool, hard to find, barely advertised to its potential target group, lacked documentation, demos and a community. I think, it was simply a result of Yahoo's chaotic product management at that time. They had a few gems that didn't get the attention they deserved - internally and from the public.
I find them quite limited but I understand the need and also that not everyone can parse a structured response. It's nice that they have free versions though.
Although more complicated to use but also free, I get a lot more functionality from PythonAnywhere, Cloudflare Workers or Oracle Cloud free tier.
I was at Yahoo from 2004-2011. Yahoo often had products before the market was ready for them. Sometimes, the product would hang on and grow with the market; sometimes it would get shut down.
In some cases, like mobile, Yahoo was both too early and too late.
There was a good amount of time where Yahoo would launch something, shut it down, then Google would launch the same thing to much success. Of course, now Google is in the habit of shutting things down, another thing Yahoo did first ;)
I used to think there'd be a lot of value in going through Yahoo PR launches from N years ago and if Yahoo had shut it down, consider if it makes sense as an independent business. Although it can be hard to tell why they shut things down, so it might not be obvious which things were the product worked but the market wasn't there and which things had non-obvious issues that made the product unworkable in practice.
At the risk of appearing to take a cheap shot - I think if this was built at Google there’s a good chance it would’ve been abandoned or cancelled there too
Wow, I had no idea! What an awkward name, too. It's funny, "Pipes" doesn't on its own doesn't stand out as a spectacular name, but compared to "Mashup Editor" it's clearly superior. I wonder why - one syllable vs five, with a nod towards *nix pipes maybe?
Both Mashup Editor and the fact the name is based off Unix pipes is called out in the Wikipedia article, as well as describing the difference (albeit trivially) between Google and Yahoo’s offering.
One sounds like an actual product and the other sounds like an add-on to something else.
"Yahoo Pipes! $7.99 a month with a generous free tier!"
"Mashup Editor included with every Google Cloud subscription above $5/month."
You never want a product to sound like an add-on: Add-ons are low-value and generally used to rent seek off of people who are already locked in. Naming something in a way that it feels like its own standalone product will inspire consumer confidence.
Generic word + descriptor is an easy way to sound like an add-on.
"Video Editor" could be for anything, but is certainly not an independent product.
"Pachi Video Editor" sounds a bit more like its own thing.
"Pachi Cutting Room" is closer to the mark, despite being two words and a company name.
Interesting take, especially if you factor in action on climate change. The US is unable to get anything done, while the EU has a track record of getting results.
As retail investor there's great downsides to market makers too. The prime example; the true price of the underlying is obscure when executing an order. Where the whole point of the market is to create price efficiency. When anyone creates a limit order in the middle of the spread it's often filled instantly, but not market moving. Other investors now do not have the same information as the market makers have who filled the order. So either they should publicly log each trade so all brokers can show what the true last price was and change in positions with that, or PFOF creates information dissymmetry. Markets should be transparent, and if you make money through obscurity that's against what the market is for.
Another problem is that market makers tend not to provide liquidity when it's most needed; when markets are most volatile and unpredictable. The GME spreads for example were very wide. When the market is very volatile they tend to increase the spreads until the market is predictable (as far as they can be) again. Effectively they're like bad insurance companies: When you need them they're nowhere to be found, when you don't they'll gladly take your money.
It's for everyone involved, except ones that make money of PFOF plus the market makers, probably better to have transparent inefficiency in pricing, then have defuse pricing which in some cases might be in your favour.
You describe two phenomena that appear to be true of every two sided market ever, namely:
- One can typically get a better price than what is displayed or quoted
- The price of liquidity is higher when markets are volatile
While yes, nobody would argue those things are good, can't they just assumed to be the nature of markets? There doesn't appear to be anything about the micro structure of modern capital markets where HFTs thrive (stocks, some options, FX, etc.) that makes these particularly bad.
But an increasingly large number of trades are actually done by the market makers themselves, "off exchange" or in "dark pools". And when more and more transactions are not done on "lit" exchanges, especially when systematic, this does hurt price discovery (and possibly other safe-guarding tools and analyses that come with that public and transparent data).
The issue tracker I think is a better place for such a feature request.
Last time I worked on the attachment code, there wasn't a persistent database relationship for uploads and notes. Which would make this feature hard to implement, it would be a great feature though!
