There was a third ruling in November 2022 for the case, so I wouldn’t say hiQ won. Based on a quick scan, the ruling ended up being that hiQ did violate TOS but that no action ended up being taken for either side.
oh interesting, thanks for the link. Yeah I guess they only "won" on the CFAA claims and even then your link makes it sounds less clear than the older link I provided.
What is clear is that Linkedin is not playing around about logged-in scrapping.
Your description of always feeling hungry after keeping it off is rather worrying to me, since I’m getting close to my target weight after a 1 year+ journey of diet and exercise.
I do remember reading before that the fat cells that get created when you gain weight never really go away, they just “deflate”. So after you lose weight, you are more likely to gain the weight back than someone who is at the same weight now but who has never been bigger than that.
I also recall seeing a study that your body sends you extra hunger pangs to gain the weight that you lost back, because it assumes that losing weight means you’re in fight-or-flight mode, so it wants to make sure you survive. That’s why a weight loss drug where an extra 300-400 calories per day were excreted via urine did not show significant results.
I couldn’t find the exact study for the second part. So I’ll just leave a general reference from Northwestern alluding to the same results.
The best advice I can give is to keep weighing yourself by your current schedule, and plan on doing so forever.
I definately give up at some point, then lived in denial for 6 months or so, by which point a lot of the damage was done (certainly psycologically). I don't know if I would have controlled it better if I saw the weight coming back on, but at least I wouldn't have been pretending otherwise.
I'm not losing weight again, and I've set a reminder to weigh myself (I've set it to weekly, I know some people do daily or whatever). I'm planning on that being active forever.
I've lost 130lbs through calorie counting. I was hungry in the very beginning, maybe the first few weeks. After that my hunger adapted to my diet and I have no issues with it now.
I was worried about all that stuff about the body never adapting back after being used to eating a certain amount but it just hasn't come up. Maybe that's more likely to happen if you go too fast. I've been keeping a steady pace of ~1.3lbs/week which is slow but easily sustainable.
It also helps hunger to eat more protein, not avoid fat too much, and avoid simple carbs.
Kinesis has a 60-day money back guarantee if you buy from them, minus the cost of shipping. These are also sold on Amazon, which has a really good return policy so you can return the item with no hassle if you don’t end up liking it.
Of course, this is all presuming that
A. You have enough capital to buy the keyboard and are ok with not having $300+ for a month or two
B. you can get used to the keyboard within a 30 day period and get a feel for how you’d like to use it full time
Unfortunately their store was closed thoughout most of 2021 due to COVID. I orded a Advantage 2 from the sole NZ distributor who do not honour that deal. Cost 500USD only to discover it was very uncomfortable for an "ergonomic" keyboard. I dont think my shoulders are particularly far apart but I still had massive pain due to the ulnar deviation caused by the keywells not sitting at an angle that suited by shoulders.
Another few hundred dollars in mods to get QMK and lower thumb keys and while some other issues were resolved, I cannot type on it for more than a minute without intense pain in my left wrist.
I’m still a little confused on what dbt does after reading the article. Is it like Trino that generates materialized views as output, with built-in version control and other features?
In your case, dbt would be the tool to manage your Trino view programmatically:
* You define the sql queries that select the input data as models and the dbt scripts (also sql) to combine/manipulate the models.
* On running, dbt will generate the Trino SQL queries to join/transform these models into the final result (also a model).
* Depending on your configuration, any models can be stored as a Trino view or it can be materialized as a data table that's updated every time you re-run the dbt scripts.
I'd list the DAG and testing as core features as well, but yeah, basically. In a very transparent and non-magical way (I despise magical data solutions). If that summary doesn't resonate with you, it's probably not the tool for you. No need to force it.
I'm not familiar with Trino at all, but that sounds like a specific database. dbt is not a database, it is tooling for working with databases.
I work in one of the data platform teams at a social media company. Between our 3 HDFS clusters, we're storing more than an exabyte of data. At our scale, we have to tune our workloads carefully to make sure that problems of scale are not noticeable to internal customers (data scientists, analysts, etc.).
We basically have an entire org of highly paid engineers focused on making sure people can use that data efficiently. So we have a team of people working on storage, on Spark, on Presto/Trino, on data ingestion, and so on.
So my understanding is that we're investing in engineers to improve data science productivity, so that they can do analysis without having to understand the internals of all our systems, so that executives can make informed decisions backed by data to continue printing money. Or something like that...
This type of infrastructure is worth tooling out and productizing. I know a few places are doing it and it's hard to not have Software Engineers behind the scenes supporting clients.
Maybe you make it a SaaS so companies only need to hire daa scientists if you can optimize the ETL process.
Funny enough, the model for the cover photo was actually a professor of computer science at my university (recently retired, I believe). I'm a bit surprised that this pocket guide is well-known in the mushroom hunting community.
We hire entry level SREs (new grads) as well. The job listing might have been closed already for this year, though. I also saw a couple junior SRE listings (as in not new grad but not senior level either).
The goal of these work visas is to hire someone with specialized skills to do work when the company can't find someone with the necessary skills locally. From a quick skim through the DoJ briefing, the argument which the DoJ makes is that Facebook knows that they have more power over employees that depend on them for work visas, and games the system by creating special job listings that only the applicant seeking a visa would know about and apply for.
On an intellectual level, I guess the distinction is in how you define "highly skilled" workers. Are all software engineers considered highly skilled? Or is there a distinction between a general engineer and someone who has experience and expertise in a specific subfield such as mobile development or infrastructure?
My way of thinking about it is with the latter. I would think that the DoJ is not happy with the idea of Facebook jumping through a bunch of hoops (mentioned as making positions invisible on their career site and requiring an application via physical mail while rejecting any U.S. candidates) to guarantee a work visa for someone to do specialized work that the company supposedly couldn't find any qualified Americans for when the person they hired doesn't even know what type of work they'll be doing or what team they'll be joining until after they go through 5-10 weeks of bootcamp, and which may end up not even aligning with their specialization.
Given that new hire engineers at Facebook sign an offer letter and are officially employed while they go through bootcamp before the whole team matching process, I don't think it's possible for someone to not get matched to a team, at worst they would get assigned to a random team with headcount at some point, which would really raise the chances of that person not working in their specialty.
If this assumption is true, the DoJ would definitely not be happy that Facebook was supposedly not able to find a qualified citizen/green card holder to do this job, but the new hire on a visa may not be qualified to do it either and there were most likely citizens/green card holders applicants who actually do have experience in that area of work.
Sorry if this is a bit ramble-y, I'm fairly new to HN.
> The goal of these work visas is to hire someone with specialized skills to do work when the company can't find someone with the necessary skills locally
The interesting thing is how difficult it is to understand the specific goal(s) of legislation. It depends on who you ask.
Correct me if I’m wrong, but Facebook hires people under a generic role (Software Engineer) and then has them choose the team they will join after a “bootcamp” session. So they are not preallocated to a team to fulfill a specific need, and it’s not a direct 1 requisition to 1 person type system. I believe that’s what the above poster was referring to when they mentioned Facebook hiring to be general.
The purpose of the program seems to be to bring in workers where there is a specific need, so if it’s a generic role then that’s not helpful to their cause.
To build software so you can compete with other software companies? These big companies have large engineering offices overseas as well, if they can't hire in USA they'd just put these people there instead. They wouldn't start hiring less qualified Americans as many in this thread seems to believe.
“Building software to compete with other companies” wouldn’t be specific enough for me if I was the judge.
If you said to me “we are building a VR headset and there is a specific image technique we want to employ to correct for foveated lenses, and we want to bring in an image processing expert” then that would be different if I was the judge.
I’m not arguing what should be the case, I’m saying what I think the intent of the current law accommodates for.
> If you care more about latency than consistency you have an 'eventually consistent' system, where a write will eventually propagate, but a read might get stale data.
Not just stale data, you can also have states which never actually existed. I'll steal the example from Doug Terry's paper "Replicated Data Consistency Explained
Through Baseball" because it's really good. Linked below.
Say you have a baseball game which is scored by innings. It's the middle of the 7th inning, and the true write log for the state of the game is as follows:
If you were to read the score at this point in time, and your system is strongly consistent, the score can only be 2-5 or a refusal to serve the request. If your system is eventually consistent, the score can be any of the following: 0-0, 0-1, 0-2, 0-3, 0-4, 0-5, 1-0, 1-1, 1-2, 1-3, 1-4, 1-5, 2-0, 2-1,2-2, 2-3, 2-4, 2-5.
https://www.natlawreview.com/article/court-finds-hiq-breache...