Grail's test is a cfDNA test. It detects DNA fragments in blood that are indicative of specific methylation patterns that are in turn indicative of possible cancerous growth. While a good approach, there are continued sensitivity challenges with cfDNA tests.
This research is a high quality longitudinal retrospective study of protein cancer biomarkers, not cfDNA. Protein biomarkers are a complementary signal that has the potential to boost the sensitivity and precision of these tests, especially when the signals are combined together.
I’ve had very expensive pen testers tell me to do this as recently as last year. They folded instantly at the first sign of pushback, so it seemed to me something that had been sitting in a checklist for years without anybody questioning it, making every website and app they audited worse.
Its like those policies where the password needs to change every 60 days that was found to actually reduce security because of the count-up-by-one passwords people would use. For places where that's been a rule forever it is really get it removed.
I don't agree with it either, but the reasoning i've always seen has been along the lines of, "it prevents people from putting passwords into the clipboard which can be stolen by other programs", and then similarly for disabling browser or password manager autofill "because it prevents people from making a mistake and letting a field get filled with a password when it shouldn't". Basically leading to "users should just manually type in and remember all their passwords" at the extreme end of the reasoning.
That doesn't make sense. If I wanted to type a password into some other program for whatever reason I wouldn't find out that I can't paste into the password field until I had already tried.
I know it's not your argument but that doesn't make sense either. Processes on desktop OSes can read each other's memory anyway if they're being run by the same user.
That and overly restrictive password rules. I often generate passwords using a PRNG or hash function that I know are pretty strong, even if it didn’t actually pick a number.
Most common are the passwords that don’t allow certain characters which leaves me thinking: (1) they must have SQL injection bugs all over the app and (2) they probably aren’t hashing passwords. Either way it’s a clear confession of malpractice.
A weird one in that example is that you aren’t allowed to use any trigraph that appears in your email. I find it amusing because last month I was working on an application that has a large number of autocomplete boxes that start showing options when you enter the first three characters and I must have filled out the form hundreds or not thousands of times so I wrote a little Python script that would compute the trigraph frequencies for any set of names. I found out the most common trigraph in country names is “and” for instance.
>(1) they must have SQL injection bugs all over the app and (2) they probably aren’t hashing passwords.
Actually, one I've run into is web-framework-level security systems that are hard to disable. Stuff that prevents users from keying in, like XSS attacks. It's not that the password field is being used unsafely, it's that the web framework they're stuck on makes disabling security on a certain text field more complicated than it needs to be and telling the users "screw it, don't use this character in that password" is easier than figuring out how to get the Rube Goldberg machine to do what you actually want. Back-end languages aren't hot garbage like html+js+css so usually it's normal proper BCrypt in the back.
Obviously a modern web framework won't have this problem, but a lot of sites are old and still running on messy cobbled-together piles of JQuery.
I had that problem with ASP.NET back in the day. The creators seemed to think it was impossible to properly escape user HTML against Javascript injections and sometimes you just had to destroy bad strings completely.
It was trashing API keys and passwords which is a problem when "the customer can't log in". I didn't have a hard time disabling this behavior at all though. My feeling is that it is impossible to "live with it" because I didn't know exactly what rules I had to follow to not get strings corrupted.
There's also the chance that this is because "security made me".
More than a few times I've written properly sanitized and parameterized applications, and security came along after the fact and told me we had to prevent input of certain characters. Didn't matter that we handled it just fine, didn't matter that it was safe to put it in. Security's argument was that some other team, some where, at some future time might somehow reuse our data and not follow the same best practices.
So no special characters in your password because some engineer in the future might possibly introduce a bug.
What about all these sites now only showing you login input boxes one by one, what’s up with that???
Enter username, click, now enter password is revealed.
Some sites, password manager manages to do both even if only one is shown but usually not.
It’s a common known fact that every person is born with a certain max number of clicks and taps. We all only have so many clicks left in our lives, that’s one less click that I’ll be able to use doing what makes me happy like doom scrolling Twitter. Dammit.
For many it's to support SSO. so if you put in an email ending in `@company.com` and Company signs in to that site with SSO they direct you to the right place.
You should check out the government's website for buying treasury bonds. Paste and keyboard inputs are disabled, you HAVE to click on an on screen keyboard to enter your password.
I honestly thought it was some kind of parody when I saw this. I clicked out and checked the link again just to be sure I was on the right site. Fortunately, I believe they have changed this now
Email or other "ID" fields as well. I use 1password, and besides the password part, it's nice to just click on a field and copy/paste knowing you wont make a typo.
> A lot of time was spent integrating social features that no one uses. That time could have been spent on quality & latency.
Goodreads integration is the best! I track books I want to read with it and then when I’m ready for a new book use the integration to download a sample on the spot
Or perhaps the news media has been increasingly effective at convincing us the world is terrible. Perceptions have become measurably detached from reality:
Or perhaps the reality on the ground for the working and middle class masses is not the same reality experienced by the elites, and the upper middle class with $150K+ salaries, or measured by stock market growth, and such...
On the other hand, it's hard to build safe self-driving cars without actually deploying them in the real world. If we can tolerate some level of risk, we can get to self-driving cars sooner.
Every year we delay having safe self-driving cars, about 50,000 people die on the road who don't need to die.
Is it that scary? California has 40 million people, so it's about $500 per person. And the electric car mandate is 10 years out (2035), which means it's about $50 per year per person, and the median household income in CA is about $90K.
Former Californian; sky high taxes including 10%+ sales taxes and even just paving asphalt properly is a fool's errand. No, we don't speak about high speed rail.
So yes, it's a scary number. Scary in the sense that the abyss of fiscal laundering and waste is terrifying.
I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.
I normally interview in Java, partly because I know it's deepest demons, and partly because pretty much anywhere will let you interview in it.
But recently I interviewed for a staff engineer position and there was a portion that was "API programming." Just writing a basic REST API to CRUD a model object. And I was like, oh my god, I know what I have to do. So I used rails. It was an hour and 15 minute block, and I ran the interviewer out of extensions to the problem after 30-40 mins. So we just chatted for 20 more and then both went to an early dinner.
(Unfortunately I didn't get the job - they were hiring a staff engineer but afaict ended up downgrading the seat to a senior engineer spot (50% the total comp) and rejected me and the other guy who was interviewing for the staff spot.)
But damn did I feel like I properly represented Ruby and rails in that one interview.
Maybe that was the problem, Rails and Ruby for this problem didn’t demonstrate enough challenge for the role, so it didn’t show you off enough in the interview.
I actually had a similar thing happen to me, blazed thru a similar "design an API" type question flawlessly, but they didn't like that I didn't write up a lot of custom code for standard CRUD stuff...
It's like they wanted me to overcomplicate things for some reason
That could be framed as an interviewer skill issue. We're supposed to give the candidate space to demonstrate both their productivity and their talent. So if expecting a programmer to reveal their abstract thinking capacity through some complex domain-specific task, building a REST API for CRUD may not be the ideal vehicle, being so mundane as to lend itself unquestionably to off-the-shelf framework solutions almost any mature language.
Eh maybe. But if they want someone who can wank off instead of ship things, then I don't know that I want to work there. And I'll never know since places don't give you feedback despite the time and interest you showed.
I would imagine with cutbacks on spending/investing I think people getting leaner and meaner will re-visit the sheer productivity you can get out of it.
Sure shaving the last 10/10ths of having a SPA with simple API based back end gets the ultimate user experience and speed but that cost curve goes up significantly for that last 10th (if you were to compared to an 'old school' Rails app)
I can't even fathom what it would have taken to build our startups' product in say React + Node (as an example..) vs OG Rails SSR. I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison.
> I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison.
Seconded. At my org, Ruby/Rails is our competitive advantage.
Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed.
The main downside is rails doesn't scale well re: complexity so regular refactors are necessary (ours is a high-volume big data app).
For performance/cost, it took some doing but by strategically moving business logic to higher performance techs we've even managed to get to a great spot there.
While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement full multi-level bills of materials? "
I said "no, can't do that - that's huge".
A weekend later of experimentation (thanks to one very kick-butt gem on that has an amazing way of managing trees) "actually, we may just be able to - it's going to be a long road though - setting expectations..."
A period of time later we've now implemented a full BOM planning/tracking system, tested well upto and beyond the numbers of items these types of companies expect.
To the point they cancelled their renewal with a big/established ERP vendor and went with us instead.
There's definitely some instances where speed to market trumps everything else. We can go optimise queries later on.
What's been fascinating is I left my day job 2 years ago (to the month). We've gone from unheard of to becoming the market leader in our space. There is absolutely no way that could have been done with any other stack (without spending 5x the money - and I argue that co-ordinating a bigger developer team it almost wouldn't matter what money you throw at it, it gets exponentially harder getting everyone on the same page for delivery).
At my old workplace I couldn't convince the .NET team for love nor money to look outside the box.
Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).
> Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET.
And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs.
I've worked with enough .NET world to know what the tradeoffs would have been.
For instance the critical library that enabled this piece of functionality, the nearest thing in .NET world looks to have 1 star on github, last updated 4 years ago. The ruby gem has 1.8k stars, tonnes of commits and upto date.
So if you were to implement that in .NET you would be (a) hitting the books (b) re-writing that library or (c) doing a hugely in-effecient/naive implementation that wouldn't scale.
In RoR land - drop in the gem and be prototyping that afternoon.
Sure if I was VC backed, and had money to burn, it might be a bit more interesting to use .NET - if were targetting more enterprise oriented clients and potentially wanted an on prem option, then yeah - .NET. Wanting more access to developers in our country - .NET, that's the predominant market. Etc etc.
Ruby is subjectively a worse language than C#, it has worse tooling (as testified by Ruby developers), worse expressiveness and, most of all, much worse performance.
If there isn't an SDK for something in .NET but is in Ruby, it speaks for the poor quality of an engineering culture in that company (as it is likely they offer Java SDK at the same time). And even in that case, you can just generate a client from OpenAPI manifest. Or a gRPC client from .proto (even better). Or if it's an algorithm, you're much better positioned with all the low-level tools C# offers to write something performant with reasonable amount of effort.
And even if that doesn't work, you can just call C bindings by using one of many existing binding generators or just `[LibraryImport]` the calls directly with little effort, after all, C# is a proper C language with C structs and pointers.
But most importantly, you get robust results and consistently good performing application with no scalability issues, good build system and very little risk of accidentally breaking the codebase.
And you don't need to make a developer productivity tradeoff in order to achieve that. I don't know when the bad reputation has to go away, but surely we're long past that point.
I will admit that the .NET ecosystem has gotten way better since being more friendly towards Linux users/environments and I used to code a lot of C#.
I love both Ruby and C# - I don't think one is better than the other. Ruby also has good interop with C. The performance of Ruby is good enough for most use cases. Scaling a Ruby app via multi-process scaling has worked perfectly fine without major issues for most use cases. The open-source 3rd party libraries in the Rails world have a certain "feel" to them.. as if they were written by devs that care a LOT about the - excuse the trendy term- DevEx that are often missing in the C# world.
Call it bias due to familiarity but Rails continues to remain the most productive option to bootstrap a web app/startup for me. Often I think most of the dissonance is simply due to difference in philosophy. Devs don't like Rails because its not "their way" and not that it is inherently better.
Pick the tools you like to use, most productive with, and most appropriate for the application - thats it. No need to nitpick on language semantics, tooling, or performance if those are not even major considerations for what you are building.
If you haven't given Turbo and Stimulus a shot, I would recommend it. Way faster to write than React, and super fast and performant. I would say its definitely the way to go with Rails pages that aren't extremely simple.
Could you share the kinds of situations in which you've seen Stimulus and Turbo really shine?
My team inherited a Rails app, which used Turbo and Stimulus and we really struggled to create UIs that matched our design team's vision. We eventually had to move to react + MUI just so that we could build a webapp with a modern look and feel.
None of us come from a rails background, so I'm sure that a big part of our problem came from us trying to bend Rails to our will rather than embracing it - if you have any advice on articles / books that embody the rails approach, I'd be really grateful if you could share them.
How Stimulus and Turbo work together, is basically this: Turbo lets you do partial page updates. Stimulus works a bit like a super light framework for UI only functionality (Toast messages, Error notices, etc). We have made both applications that are pretty stateful and more display and read only, and its way faster to both develop and run than React pages imo. Compared to standard ERB pages in Rails, where if you want to change some value on the page, you need to reload the whole page. Turbo lets you split these up into components with their own controllers, and views, and components. Then only reload the components you need to reload. So you end up with a lot more performance, a lot less redraws, and a lot less database activity for complicated pages.
I remember what happened in the early 2000s and how companies pulled back on the tech they were using. A few years ago I was convinced that fat front-end stacks are a luxury of companies with "free" money, and that the industry would be making tough choices. (To be clear, there are applications that the SPA approach is best for, but many applications are being built that could just as well be served by an old-school PHP and Jquery app)
I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.
I do like how NextJS has done a good job of bridging the gap between SPAs and classical back-end apps (for example, file-based routing). My understanding (with limited experience) is that the deployment story is great for Vercel, and less so for other platforms (requiring you to own a lot of the build pipeline, which is one of the bigger pain points of modern JS)
It was done before ORM became en vogue using SQL and recordsets. When it got too hairy we'd just put an abstraction in place, similar to how many apps end up doing the same atop the ORM via service objects, etc.
3-4 years ago I was convinced that Rails was in its sunset years. JS had all the energy, Ruby conferences were disappearing, and it seemed like there was no new open-source development happening: we were all just using the same gems we'd used for years.
I'm happy to say that I was proven very wrong. New conferences have sprung up, over-the-wire is trending well against SPAs, and there's been a ton of new features and approaches that have kept Rails and Ruby very relevant to modern development.
I'm running Tech Talks Weekly newsletter, so I'm following lots of various conferences. I must say Ruby/Rails community is increasingly active and growing after the pandemic. There are lots of conferences planned for this and the next year including RailsConf, Rails World, Baltic Ruby, and many more.
From personal experience, I also appreciate that it's one of the easier stacks to keep updated with the latest and greatest. I've upgraded projects from sprocket-backed asset pipelines to bun in a couple days time, and the new tooling you get with modern rails really make upgrading worth it.
Last year I started a new project[1] for a member management platform and really fell in love with the new jsbundling pipeline paired with stimulus, it feels like I've rekindled my passion that led me into programming initially; the ability to hack & prototype with rails is pretty unmatched (though it's worth mentioning Django holds a special place in my heart as well)
Where do you get the idea that the rails ecosystem is striving? I work on a big Rails monolith as part of my day job and the amount of abandoned libraries in the ecosystem and general quality of libraries is pretty miserable if compared to Golang, Java, Python, JavaScript and others.
I'm not saying it's a bad technology choice for a new company when all you need is to build a CRUD web app fast, but I wouldn't use it for anything that requires you to serve >1MB of JSON API responses or anything that requires concurrency, substantial IO, lots of API interactions with external services, low latencies, lots of memory or compute heavy computations, etc.
We use grape-api for some of our API endpoints. I needed to set some custom cache headers for some GET API responses and was looking into gems that do that for grape. They have a list of 6 libraries in their docs [1] that they recommend.
Their newest commits were 4, 9, 9, 10, 8 and 9 years ago, respectively. This is just one example, but I would bet half of the libraries in our transitive dependency tree haven't seen any maintenance in this decade.
Rails is *ancient* in the context of tech though, I think it's fair to criticize the skeletons in the closest while not necessarily refuting that the ecosystem is still active.
An equivalent example imo is the PHP ecosystem, which itself has been growing rapidly and thriving over the years -- but at the same time if you did deep enough you'll find a graveyard of long since abandoned frameworks, libraries, etc...
I think both PHP and Ruby still have and will keep their niches, but in my opinion they don't provide the building blocks to expand outside of their niche and grow much at this point. If you contrast that with let's say Rust, which at least has the potential to become successful across a wide field of applications.
The problem that I can see with Ruby in particular is that its niche is getting smaller and smaller as the world evolves around it. Interactions with external services that are on the critical path to serving requests are becoming more common. Interactions with actual contents of pictures and documents are becoming more common. Concurrency is a major missing building block to build modern apps compared to 10 years ago, and the answer of the Rails community has mainly been YAGNI (although there are efforts to incrementally improve things, but no fundamental shift in language or runtime design).
Ruby introduced language native fibers and actors since 3.0 and they work pretty well. Concurrency could still be better but I'm with the YAGNI crowd - unless you are building something that requires a ton of async you probably won't need it. If you do need it, there are admittedly better tools for the job.
Brother, did you just called PHP a niche and offered a prognosis on how they might be able to keep it? :)
And then talked about Rust as it was a general purpose language that all the potential to become the top language for most programming in the World?
I’m joshin’ but seriously, PHP is HUGE and Ruby was always small even when they were loud on the internet.
Rust is a systems language currently being used as a big hammer for everything and a somewhat obnoxious community just as Ruby, then Node, then Go were when their day in the Sun was.
I’ve seen the exact template of your comment throughout the years, it fine, it belongs to this particular point in time and in your of the woods, there are more.
Ruby is incredible. It is still one of the best choices for a platform to build a company or a product quickly with. If it cannot keep up with your scale, throw more hardware at it and it will still be worth it in terms of time and man-hours saved.
I only ever wanted compile-time linting and better autocompletion such as in the case of Elixir LS. Does something like that exist for Ruby now? How is Crystal these days?
There is ruby-lsp and ruby-lsp-rails. For the former to shine you do need to use sorbet but for any moderate to large sized rails app I'd personally recommend it anyway. Yes it's not perfect, yes it has a learning curve but boy does it make refactoring easier, faster and safer.
ruby-lsp-rails builds on top of that and hands out information on models and routes mostly
The only gripe I have with the Ruby ecosystem (and transitively to Rails) is that RubyGems is not curated, and many gems have bitrotted into broken obsolescence over the years, but these are presented with equal standing to those that are actively maintained, and it takes a discerning eye & additional effort to tell the abandoned ones apart from packages that are simply very stable.
There’s also a ton of idea placeholder and half-baked proof-of-concept gems. These are easier to spot (usually released once, years ago) but are now nothing but squatters on the namespace.
Even if human effort is too much to ask, a filtered subset of packages that successfully bundle and pass their own tests for specific Ruby version+arch would be helpful. More broadly, perhaps that RubyGems should even be entirely siloed for each annual Ruby release, since this tends to be the boundary of breaking changes to the language (see also: semver) and approximately the cycle on which unmaintained packages become an obstacle to the update of shared dependencies.
Yes - Ruby Toolbox is handy, one of the discovery and currency assessment tools I use too, and is good at surfacing projects that are actively developed, but it takes a metric driven approach that's intrinsically weak at distinguishing between abandoned code and stable code. It won't reveal when a decaying gem will cause other dependencies to be held back, and Ruby Toolbox suffers from the same fundamental blindness to compatibility with specific language editions that RubyGems has. Since it’s not a part of RubyGems, it ultimately can't offer a reliable barrier to inadvertently installing bitrotted code.
None of this is meant as a criticism of Ruby Toolbox, because it never claimed to do all that, nor can we expect it to. All said & done, and to reframe things more constructively, I think there's a missing piece in the community infrastructure puzzle that someone could fill if they had the time, inclination, and build farm to do it.
This thread seems to be getting some views. I'm looking to break into the Rails work, but it seems rough trying to get into a job doing Rails work as a junior, not quite senior role. I have other development experience, primarily in Ruby and Objective-C.
Any advice? I know the job market is a bit of a rough one right now as well.
For Juniors it's tough (in general, though it's always been tougher in rubyland), because even the most well organized codebases tend to turn into a bit of dynamic magic spaghetti that can be hard to follow if you're not familiar with Ruby's dynamic nature. Getting newcomers to the language/framework onboarded to old projects (and most Rails projects will be old ones these days) can be a bit of a mess and take a lot of time and effort, so a lot of companies are weary of getting juniors.
That said, if you can display you have knowledge of the more important Rails libraries like ActiveRecord, ActiveJob, how Rails handles the MVC pattern etc., then your chances are much better. It's a bit of a magical framework when you first start working with it, so it's important to know what it does behind the scenes, at least a tiny bit, since otherwise it's easy to get lost.
If you are looking to become more competitive as a candidate, I strongly recommend that you look at one of the more popular languages / frameworks instead of focusing on Ruby on Rails.
Despite the major investment made by Stripe and Shopify, my experience is similar to that of this commenter: https://news.ycombinator.com/item?id=40161561 - like them, I've found the open source libraries available in the Ruby + Rails ecosystem to be aging and less well supported than that of more popular languages / frameworks like GoLang / Java / Python.
Rails is delightful to work in and very thoughtfully constructed, and the Rails community is helpful and welcoming. However, if your priority is to maximize your chances at getting hired, I would look towards GoLang / Java / Python etc, which are far less enjoyable to work in but far easier to find jobs for.
My advice would be to either start contributing to an existing FOSS ruby gem or to create your own for some specific purpose.
That will allow you get familiar with the ecosystem so that you can hit the ground running and also allow you to point to experience during the screen and interview phases.
> This take feels more like being upset about one individual's (Vlad) personal opinions about privacy and politics. But in my opinion, it fails to realize that assigning one person's views to an entire organization is a fallacy. Even if they are the leader.
And Vlad didn't even say anything that crazy from a political perspective. "News should not only be about politics" is super reasonable, and I found myself agreeing with him much more than the person he was talking to.
It'd be reasonable if it was achievable. News are always colored by politics. And usually the people who want "apolitical" news are just defending the status quo they've internalized as the baseline (which especially in the US is by no means a commonly understood one).
Let's put it a different way, if Vlad wasn't apolitical, like all the haters seem to be complaining about, I wouldn't be paying Kagi any money, it wouldn't even be on my radar.
While no one can truly be unbiased, I want them to try. Arguments against this are just sophist nonsense, and I'm not convinced they are made in good faith.
He isn't apolitical. He thinks he is apolitical, which is more troubling than being openly political. (Well, unless you're Elon Musk political, I suppose.)
Someone who believes in objective truth believes their own viewpoint to be the only valid viewpoint, as indeed we see in the quotes in TFA.
Yeah it is political lol. What do you think political means? Why is it important to society that we know more about old people in the old age homes? Do they need more or less support? Social security and supporting older people past retirement is a political choice. Choosing to publicly fund Healthcare for the elderly is a political choice. Who owns the newspaper? What are their goals? Why are they using their limited space to express this story?
Political isn't always negative but the news is always political. All news, including good sources like NPR, is promoting a point of view. Nothing is impartial even if that's the goal. Ignoring this doesn't change it.
https://www.galleri.com/