Not at all the same thing I admit, but the company I work for has a product that limits the number of transactions (per user) to 1. Where "transaction" is roughly equivalent to an HTTP request. So if you run a query that takes 30 seconds, get bored, open up a new tab to do something else in the product, your new tab will hang until the transaction in the previous tab has completed.
I hate it.
There is a special URL that will kill your running transaction. All of the engineers know it and have it bookmarked, but it's undocumented.
Ha. When I moved into my town, the public library's online book search was only turned on from 9-5, monday through saturday. Apparently it was so unstable they didn't want anyone trying to use it unless they had an IT guy on hand? I'm guessing? Anyway, they eventually outsourced to bibliocommons, but oy, what a ridiculous limitation to have as late as 2007.
The official government website for accessing information about property ownership information in Slovenia only works during working hours -- mon-fri 8h-20h.
A local pizza place has a website that closes outside of business hours. Which is infuriating if you're trying to figure out business hours in the first place.
There is a Dutch chain of baby necessities which is owned by a fundamentalist Christian. You wouldn't know except for the infuriating message their websites (there where some mergers and I think this affects two large online shops) on Sunday, all day long, are closed because of the Sabbath. A multi million Euro business which just shuts down all of its websites on Sunday.
The owner can apparently afford it, because I ran into this when we made a baby and was comparison shopping for a stroller. Obviously you move on and go somewhere else. The owner literally misses sales for his beliefs.
Now I don't want people working Sundays shipping stuff people bought, but those websites can do their thing perfectly without anyone lifting a finger until they come into work on Monday to a stack of orders to handle.
B&H (https://www.bhphotovideo.com/) is somewhat like this. Super popular business, but you can't order online on Saturdays. You can browse the website, just not place an order. Their physical store is also closed on Saturdays, and closes early on Fridays. They also close for days/weeks at a time for Jewish holidays.
I saw a single-panel comic once of an old man, manacled, alone, in a dank dungeon cell. The caption is "I know not how long I have been in here. The days and years flow together, and my mind is haunted by memories. But I want Chick-Fil-A, so it must be Sunday."
A national train company where I live in limits the number of transactions (per user) to 1. Where "transaction" is roughly equivalent to a browser tab - the website will aggressively scold you if you try to open another tab and refuse to load!
I think it's realated to the session mess they have in the backend but it's very annoying (especially when buying train tickets and comparing offers, of all things).
A lot of ERPs try to limit the number of tabs; I don't fully understand the reason - it may be because of the stuff they do in the browser before syncing to the database at submission/commit time, so they want to avoid apparent inconsistency?
Maybe too many people were overloading the system by opening too many tabs, making it worse. Sounds like this application needs basic fine tuning (I bet there's 0 indexing on the database, and who knows what else).
Or you can type “cancel_my_transaction.do” in the navigator filter bar. Related tip: you can quickly bring up any table by typing “table_name.list” (s/.do/.list/ from the single-item url) there instead of poking around for a link. “sys_user.list” is probably the one I use most often.
I'd wager the overhead of manging a mutex to see if a user is currently using their transaction is greater than the occasional second transaction a user may occasionally invoke in most situations.
<h2>
Only you can see this website.
</h2>
<p id="suckers"></p><br/>
<img class="trophy glow" src="https://cdn.glitch.global/1543e9b8-e528-46e7-9375-25300add0f54/trophy.gif?v=1646925832589" alt="clip art animated gleaming first place trophy"/>
Looks like it's no longer in the html source, but it can still be viewed in the javascript source code:
if (status === "inside") {
text.push("i am the only person who can see this website.");
text.push(link);
if (waiting > 1) {
text.push(`${queueLength - 1} people are waiting to get in.`);
}
text.push("want to see it? get in line, sucker.");
} else {
text.push("only one person at a time gets to see this website.");
text.push(link);
text.push("get in line behind me.");
if (waiting > 1) {
text.push(`currently, ${waiting} people are waiting.`);
}
}
text.push("i'm here for me.");
failed to start application on imherefor.me
This is most likely because your project has a code error.
Check your project logs, fix the error and try again
When I was in college, someone discovered that you could call 1-900 phone sex lines from the pay phones for the cost of a local call and the college would be billed for the phone charges since the phone was in their name. People were racking up thousands of dollars in charges until the school started placing "observers" near the phones to nab whoever was calling them.
Made "examples" of a few unfortunate students until they could fix the problem internally.
I once worked for a Cambridge startup called Sayagle where you would Yagle for SayaCash (don't ask).
I started after the website was built by a cheap offshore team. It was built with JSF and we soon found that no one thought about multithreading because they only ever tested it with a single user.
Needless to say, when more than 10 users were active on the site, they would start to experience problems, like seeing eachothers data and stuff. "We" fixed the problem by adding more servers while I tried to rewrite the whole thing using spring and jsp.
The idea was that you would visit participating merchants, spend money there and they would give you codes on stickers that they generated from our site and then the customers would use those codes on the site with purchase amount to get sayacash.
One problem we had was that the codes we generated turned out to be invalid because... we didnt know why. We generated the codes, but they werent in the database. Where did they go?
The customers would try to enter them, and be told that they are invalid, or go to their dashboard and see stuff that wasnt theirs because there was only one session object for the entire app.
It was a huge mess. At some point we made a video that would explain how the site was to be used. You can find it here: https://www.youtube.com/@sayagle.
Every single person in every video was employed by this company. The tea place in the first video was owned by the founder. :)
Wow in the first video the man behind the camera refers to customers as clowns. Acts as if the guy he grabbed is stupid and not capable to enter a code on the web page. So weird.
It sounds like this was a terrible, terrible, terrible, terrible, terrible company. I suppose it's telling that a Google search mostly turns up your story about the company, and an assortment of random mentions from a decade and a half ago. How did Sayagle die in the end?
My employer let me pick my own gift from a website with countless products. I visited regularly to progress looking over the gifts. The small print said you had something like 7 days to chose. After 2 or 3 weeks I finally made a choice, it congratulated me, deducted the points from my balance and provided tracking information. Then nothing happened. I could even log in again and spend the remaining points but nothing shipped.
It's not that uncommon in some languages where you have a long running monolith (.NET, Java, etc) instead of an instance of something that spins up per request (Node, PHP, etc). If someone does something silly like setting the session handler to be scoped to the monolith app rather than having a scope of a single request you end up with users seeing one another's data. It's dangerously easy to do in some frameworks.
No, more likely someone's used global or static variables. It's got nothing to do with monoliths vs micro services. You can do the same global/static variable crap in a micro-service.
Plus you didn't even need to multi thread in old school asp.net, IIS would create a new process for every request back in the day.
.Net did have a notorious 'session' object, which was the cause of a lot of problems due to novice/offshore programmers, but not the symptoms described above.
I'm not sure why you've targeted monoliths and .net/java, but the problems described above are usually caused by multi-thread/shared variables, which weren't a common thing to do in asp.net. You'd really have to go out of your way. I've seen some terrible .net code written by novices or poorly trained offshorers, but nothing like that.
I'd be more likely to bet they rolled their own cookie or session management or jwt token manager, and I'd guess it was an early js/nodejs app before that ecosystem stabilized when people were raving about going framework free and then footgunning themselves.
I don't think node really existed when this was made in late 2009. It was built with jsf: Java server faces. Its a bit like a more enterprisey version of GWT. Everything on the page was a huge class with lots of horrors that eventually became html css and js that you never wrote.
I checked, node existed but it was a toy compared to jsf.
we implement one for event registration. without queuing, you end up with some hidden complexity around whether a ticket in a cart counts towards the limit or not, and when it goes back into the available pool if that cart doesn't check out in time. none of it is too difficult to implement, but it is difficult to explain to users and creates experiences that frustrate people are or are perceived as unfair. for example, an event can be "sold out" while a payment is processed, and then the event becomes briefly not sold out again if the payment is declined.
a queuing system is easier for people to understand - you get in line, you have three minutes to complete your purchase when it's your turn, and everything that was available when you started your session is available until your session ends. people are still frustrated to have to queue, but at least they can form a mental model for what's happening.
IMHO a lottery system would be a better way to solve this, but event promoters tend to hate that and want a first-come first-served experience. i don't really understand why.
To your last point, I’ve always understood their sentiment to be along the lines of:
- differentially rewarding those customers willing to put in higher levels of effort
- inflating attendees’ sense of the purchase’s value, since they’ve sunk work into acquiring the right to attend/buy
- adding a sense of agency: you “could have” gotten the tickets if you’d just showed up earlier, you have only yourself to blame
- discouraging the sense that the lottery is “rigged” or inundated with scalpers
- for that matter, offering some form of social proof that “other people” (rather than bots) are buying the tickets: taking the amount of time that people take to check out, that sort of thing
- which also offers tangible social proof of the promotion’s desirability: “1,000 people in line around the block” counts for more buzz than “5% chance of being able to spend money on this thing”
- potentially more reliable gauge of the true level of demand, so we can get the right size of venue next time: a lottery rewards trying to game your number of entries, and, depending how it’s constructed, may encourage people to enter on a lark even if they don’t intend to buy
I remember first time writing a web-shop I thought things would be reasonably static. Gradually I changed my mind, it is more like a first person shooter. The new product sticks it's head around the corner and the first one to shoot it gets the kill but it only counts if you make it safely though the transaction in time. Picking customization while the evaporate is like trying to land a head shot.
Hardcore fans demand to feel they earned their spot by having more endurance, being quicker, even if it ends up being kind of luck when it opens up.
I’ve seen something through Ticketmaster that added a lottery system, giving a certain percent of users a shot at tickets a bit before it gets opened up to everyone else. And people with Amex cards or people who demonstrated devotion.
Virtual Queueing / Online Queueing are the terms to find them.
The reason companies use them is for stuff like tickets releasing for an event at time X. People will spam the site and a random number of them will get through which incentivizes people to Sybil whack the site. Much better to provide first-come first-serve with no advantage to late joiners. Of course still not optimal, so some events will offer an initial queue to people who've been before or so on.
The queue here seems to work poorly. Looked at the site and I was 162. Looked away and back for literally 2 seconds, I was 164. alt tab and back again, I was 176. Again and I was 188/188. Now I'm 140. What?
It says on the page: Don't leave or you'll lose your spot. The queue worked fine for me as long as I stayed on the page. I assume it uses focus/visibility events and puts you at the back of the queue unless you keep it open and focused.
The queue length is jumping about a lot as people are visiting and leaving, because hn.
I pulled this up out of fun curiosity, and then found it harder than expected to close the site because “what if I lose my place?”. And so that’s basically how marketing works in a nutshell.
1. this is an AWESOME art idea
2. even more awesome is the single comment to hoffm's first post about this site a few months ago (https://news.ycombinator.com/item?id=30700024) and I hope HN keeps it that way
I hate it.
There is a special URL that will kill your running transaction. All of the engineers know it and have it bookmarked, but it's undocumented.