Honestly that was one of my first thoughts when I saw this, someone is going to draw one of those. People love trying to be offensive in something that barely allows communication. I remember seeing some MMORPG that had no chat where players would log in and just stand in the shape of a swastika.
Makes me wonder if it's reasonable to write an algorithm to detect that.
I built a grid-based music sequencer for the web a while ago that lets people see projects other people made in a side panel.
I very quickly realized I needed some manual content moderation because some people immediately started sharing patterns that looked like dicks and swastikas lol
Which MMO was that in? I'm working on my own and now I have a new worry on my plate. Short of standard moderation, an algorithm to detect it could be interesting.
You could search for the article about how the Lego mmo (or that's what i think it was) was shut down, then stop worrying about it. Unless you want to spend the rest of your natural life on detecting penises, swastikas and everything else. I mean, everything is offensive to someone.
I realized it would be easy enough to detect when certain lines are forming and manually shuffling the players a few spots, but your comment made me smile. Somewhere in there is the start of a biography title.
Here's an extra part of the spec: Deliberately there is no correct WWW browser window width. So you'll also have to account for the swastika writers using a whole range of window widths.
It might be worth considering just changing the rules for the pawn to deal with this. It's hard to tell what it means to move "forward" on a board like this, even after understanding the indicators.
Maybe pawns could just move horizontally/vertically and attack diagonally, regardless of color?
Your constraint should be that if the board is the special case of regular chess, the game should play exactly the same. Allowing the pawn to move towards any side is too much because it would violate this principle.
Perhaps define forward as the direction(s) which, when extrapolated as a rook, would reach the opponent's backrank. If it doesn't exist, the direction(s) which, when extrapolated, terminate on the opponent's half. This would allow extra freedom to pawns in some funky topologies that can occur in your game, but generally follows the principle of least surprisal.
I'm still unsure, as I describe in my reply there, an issue I see is that you can't know the path a pawn would take, unless you know where it comes from.
But since both of you reached the same solution, I'll keep thinking about it.
I get the dillemma, but I don't think it's a problem that the string of squares used to define "foward" isn't always the same as path the pawn will actually take if it chugs along.
This only happens when there's no straight path to the opponent's backrank, so you are allowed to go "sideways-foward" until you hit a square from which there is a clean forward path again.
Agreed that the past should not matter, only the current position.
I remember learning that you get about 100ms for a basic UI interaction before a user perceives it as slow. And you get about 1s for a "full page navigation", even if it's a SPA, users are a bit more understanding if you're loading something that feels like new page.
Getting under 100ms really shouldn't be hard for most things. At the very least it should be easy to get the ripple (or whatever button animation) to trigger within the first 100ms.
It is mental just how different the video game and (web/desktop front-end) realms are.
In the former, one can have a complicated and dynamic three-dimensional scene with millions of polygons, gigabytes of textures, sprites, and other assets being rasterised/path-traced, as well as real-time spatial audio to enhance the experience, and on top of that a real-time 2D UI which reflects the state of the aforementioned 3D scene, all composited and presented to the monitor in ~10 ms. And this happens correctly and repeatedly, frame after frame after frame, allowing gamers to play photorealistic games at 4K resolution at hundreds of frames a second.
In the latter, we have 'wew bubble animation and jelly-like scroll, let's make it 300 ms long'. 300 ms is rubbish enough ping to make for miserable experiences in multiplayer games, but somehow this is OK in UIs.
Agree it's like two separate worlds. Games and web aren't 1:1 tho in relation to whether visual responsiveness is blocking a task.
Games need ultra-responsiveness because rendering frames slower is essentially blocking further user interaction, since players are expected to provide a constant stream of interaction. Being 'engaged' is essentially requiring constant feedback loops between input/output.
On the web the task of reading a webpage doesn't require constant engagement like in games. UI (should) behave in more predictable ways where animation is only there to draw association, not provide novel info. Similarly UI animations are typically (or should not be) blocking main thread responsiveness and (should be) interruptible, so even low frame rates are not breaking the experience in the same way.
But still, your point stands, its crazy what we've come to accept.
I also expect my everyday tools to be responsive e.g. if a "desktop" application lags while typing I'm uninstalling that shit (if there is an alternative sigh).
> It is mental just how different the video game and (web/desktop front-end) realms are.
There is absolutely nothing mental about it, and I'm saying this as someone who's worked on a couple of game projects myself.
Somehow people making these comparisons are never willing to put their money where their mouth is and give random web pages the same level and amount of access to system resources as they give to those "photorealistic games at 4K resolution at hundreds of frames a second".
Usually these issues are caused by doing work in the UI thread (easy, when it’s ‘cheap’) synchronously.
All UI thread frameworks end up doing the UI interactions on a single thread, or everything becomes impossible to manage, and especially if not careful, it’s easy to not properly setup an async callout or the like with the correct callbacks.
It is easy to make a responsive, < 100 ms UI, it’s often harder to keep it that way.
If you're using Flutter, you can start with just the web app. Flutter for Web is definitely not as good as Flutter for iOS/Android, but it's decent, and the web itself is far easier platform to publish on. Then, if people like the app, you can bother jumping through all those bureaucratic hoops and get it on iOS/Android natively.
This is probably the path I will go down, should be easier to get the testers if it's already got some users on the web. Still feels a little unfair that as a new dev, I have to jump through these hoops that existing devs and businesses aren't subjected to.
> 99 percent of reclaimed asphalt pavement being put back to use
Can't that be interpreted as them just not reclaiming asphalt they can't reuse? Genuinely asking, since things like this are often optimally worded for good publicity.
I think maybe some of the confusion is over how asphalt works. It's really easy to reclaim because it is essentially just a phase change operation. I forget the exact temperatures but you heat asphalt up past a certain point and it turns into basically a slurry of whatever hydrocarbon (plus additives) that is doing the phase change and stuff like sand, small stone, etc. The sand and small stone is infinitely reusable so when they resurface they are often scraping up the old, loading it into a machine that heats it up, adds a small amount of the hydrocarbon (and additives) plus some more filler (think sand) and putting it right back down to cool down and solidify.
Cement is a chemical process that can't be easily undone so once you use cement you are hooped, very limited recycling options other than grind it up and use it as filler in the new batch.
The alternative to reclaiming would be to leave it in place and pave over the top (asphalt overlay). That has limits, though, so reclamation will be a requirement over time.
The claim and wording is valid and correct, though. You cannot recycle asphalt if you leave it in place. And what is removed is recycled at a rate of 99%.
If you don't reclaim the asphalt, then it's still in place, and technically still in use.
Fair point, and I don't have enough background to really answer that. I'll look for any information on "reclamation" rates of asphalt - there's got to be some amount that's just lost in general (ground up into fine particles that blow away, fall into drainage systems, etc.), and places where it's just not reasonable to tear it up to bring to a recycler vs. dump it somewhere convenient, but it does _sound_ like they are pretty good about reclaiming and recycling it.
The next chunk in the abstract I quoted is:
"The average percentage of RAP used in asphalt mixtures has increased from 15.6 percent in 2009 to 21.1 percent in 2019. In 2019, the estimated RAP tonnage used in asphalt mixtures was 89.2 million tons. This represents 4.5 million tons (24 million barrels) of asphalt binder conserved, along with the replacement of more than 84 million tons of virgin aggregate."
That gives some context as to how much is actually being reused.
That's like being okay with a candidate Googling the answer during an interview. Not unheard of, but unusual. It seems hard to test someone's knowledge that way.
At my company we tell people that they should feel free to google or consult references at practical coding challenges.
> It seems hard to test someone's knowledge that way.
I don’t really want to test knowledge but skill. Can you do the thing? At work you will have access to these references so why not during the interview?
Now that doesn’t mean that we are not taking note when you go searching and what you go searching for.
If you told us that you spent the last 8 years of your life working with python and you totally blank on the syntax of how to write a class that is suspicious. If you don’t remember the argument order of some obscure method? Who cares. If you worked in so many languages that you don’t remember if the Lock class in this particular one is reentrant or not and have to look it up? You might even get “bonus points” for saying something like that because it demonstrates a broad interest and attention to detail. (Assuming that using a Lock is reasonable in the situation and so on of course :))
I do want to understand their knowledge. I'll preface questions with the disclaimer that I am not looking for the book definition of a concept, but to understand if the candidate understands the topic and to what depth. I'll often tell them that if they dont know, just say so. I'll start with a simple question and keep digging deeper until either they bottom out or I do.
I'm okay with them googling too. And I tell them that at the start. But if they take ages to lookup the answer when others just know the answer, it's gonna hurt their chances.
Sure, they can search it live but you have to assess if they understand what they found. Usually, if they really know their stuff, whatever they find is just gently pushing their working memory to connect the dots and give a decent answer. Otherwise it's pretty easy to ask a follow up question and see a candidate struggle.
It's like in college when you're allowed to take textbooks to an exam. You can bet the professor spent more time crafting questions that you can't answer blindly.
That being said, I think both types of questions have their place in an interview process. You can start with the no searching allowed questions in the beginning to assess real basic knowledge and, once you determine the candidate has some knowledge, you start probing more to see if they can connect the dots, maybe it's architecture decisions and their consequences, maybe it's an unexpected requirement and how they would react, etc.
The knowledge we're testing is related to how well you can do your job. Work isn't closed book - if you can quickly formulate a good query to grab any missing information off the internet then more power to you. I've worked with extremely stubborn people who were very smart and would spend a week trying to sort out a problem before googling it, there are some limited situations (highly experimental work) where this is valuable but... I no longer work with these people.
This one is quite bad though, and generally articles with clickbait titles aren't worth reading imo, since there's likely less sensationalized article on the topic somewhere else.
You need time zones to tell what's "early" or "late" in a place. If you're planning to call someone far away, picking a time "during work hours" becomes very difficult without time zones. You would have to consult some chart that describes when "work hours" are in each region which is basically just reinventing time zones.
> If you're planning to call someone far away, picking a time "during work hours" becomes very difficult without time zones.
Does everyone in your office work the same hours?
We _already_ have the problem of "What are Bob's work hours" because most office workers don't work the same hours. Some folks come in early, some work late -- some come in late and leave early.
That has been common for decades and has become even more pronounced with increased remote work, particularly across time zones.
We shouldn't build our society around a myth of 9-5 office workers.
I'll add that for serious scheduling, people use digital calendars extensively. Some sort of "work hours" would need to be marked on those, but everything else would be simpler.
I don't know what it is as a percentage, but globally there is in absolute terms significant amounts of East-West inter-timezone communication going on all of the time. Like literally, it does not stop happening and is happening right now.
Percentages are misleading when the population is several billions of people conversing and conducting commerce at near-light speed on a global scale. Just the three hour difference between the East and West coast of the United States is significant enough to be worthy of consideration on when to call people on the other coast (or just expect them to get back to you through asynchronous comms) because people on the West Coast are on average waking up three hours later as measured by GMT.
The same is true for the proposed global universal time. Without inter-timezone communication, everyone would just operate relative to their local solar noon, like they did pre-nineteenth century. The 'edge cases' of inter-timezone communication and travel are the only reason we need to care about any kind of coordinated time system.
Makes me wonder if it's reasonable to write an algorithm to detect that.