skysight-inc/HackerNews huggingface dataset:
One could leverage something like Arch PKGBUILDs or nix recipes to create C/C++ "package manager". C/C++ libraries aren't really hard, all you need is "root directory" with the common {/include,/lib} layout. For C you could even have binary libraries, but for C++ binary libraries are gonna be quite a problem, because there's no ABI compatiblity and even different compiler flags can cause ABI incompatibility.
I may have misunderstood the question so feel free to push back if this doesn't make sense -

We use Postgres Row Level (RLS) security, so you can do some very advanced rules. For example, one of our team built a social network with PG and RLS:
https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e...

RLS is flexible enough to cover multi-tenant scenarios, though it's up to you how you structure your schema to make it work.
Introducing Marsbot for AirPods
I don't understand this acceptance of meritless praise, much like body positivity towards the morbidly obese who are on the verge of dying. It's tantamount to rationalizing cheating on a test person gets a job versus those who do all of the work do not.

Also, if someone believes they're not an expert at something, then maybe that's a clue to master it rather than riding on the coattails of image or happenstance?
You can actually make closer to $10/month in gift cards via Bing. No clue where the buck fifty figure came from in the GP.
The feature backlog is rarely more important than performance but you often see it being pushed ahead of nonfunctional concerns for presentational reasons.
Trusting corporations (or any entity free from limitations and background checks) seldom bring the expected results.
Pageable also adds window functions (limit, offset). If you are going to compare, please be courteous and do it right.

When app starts up, Java compiles these declarations and will abort if the declared function actually does not match the entities. This is a huge safety net, which you would not have when you write SQL. And also when you write SQL you have to take care and unpack the "select *" into your fields etc etc. I suspect this is much more important downside than you might realize.
Well, the general idea seems usable enough; X time units from a specific reference point. Conversion is then done to whatever local time-keeping system you might have.

Leap seconds are based on conditions here on Earth and wouldn't really be needed on Mars or Venus. They might have different peculiarities though, and they wouldn't be usable on Earth. In that situation, a single point of reference would be useful for conversions.
The commenter's comment [1] is absolutely fine, though.

Hipp's response is also fine! The only thing that wouldn't be fine is if someone inappropriately reacted to that comment as an insult.

[1] https://fossil-scm.org/forum/forumpost/7840137009?t=h
Loving the "are we ok with this ?" take - as if anyone cares.
Top React Native Ubereats clone template 2020
How can unfairness be spread "evenly" when it is a amorphous, unique, and situational impression? Also, isn't that like a wrong rationalizing its existence by another wrong?

Let us consider unfairness such as forcing a kid to ride a bus 3 hours per day when there is a perfectly good school next door they can't attend because they're Asian. Does that "fix" segregation because it's an "equal" unfairness too?

Two wrongs don't make a right, but three lefts do.
My wife is a pet sitter and has been bitten by a dog. She called me, but couldn't explain or tell me her location and me being terrible with directions drove around aimlessly and couldn't find her. After this, she decided it was best we both share our locations so we know each other's location just in case something like this happens again.

The geofencing thing would be so I could time when to start cooking dinner and have it ready for when she gets in. I work from home so it's easy for me to cook and I just like to have it ready and stay warm by the time she gets in.
There's great reasons to use ORMs (rapid prototyping, for instance) but "flawless" does not inspire confidence that you are aware of the pitfalls that people experience.

Secondly, migration systems are an entirely different beast than ORMs! I'd certainly recommend that regardless.
Most people will believe whatever they read in the newspaper, and newspapers are unanimous in their opinion in this regard. As seniors were suffocating to death in the old folks homes, newspapers were pushing Cuomo as a _presidential candidate_.
XgeneCloud:

An open source alternative of Parse for SQL databases : https://github.com/xgenecloud/xgenecloud

* Instantly generates REST APIs & GraphQL APIs on 'ANY' MySQL, PostgreSQL, Microsoft SQL Server, SQLite & MariaDB databases.

* Has a built in GUI to design SQL schema which auto-generates reversible schema migrations.

* And lastly, the entire backend generated can be even deployed as a Lambda Function or GCP Cloud Function or Azure Function App!

Demos are below : Happy to answer any questions

[1] : GUI based schema designer : https://www.youtube.com/watch?v=ETEEcY4mmEg&list=PLhQvP2JTFb...

[2] : REST API creation : https://www.youtube.com/watch?v=gEU-QvmwSKQ&list=PLhQvP2JTFb...

[3] : GraphQL API creation : https://www.youtube.com/watch?v=qaLIpXe1gb0&list=PLhQvP2JTFb...

(full disclosure : Im the Founder of XgeneCloud)
How do you get results of your query to SomeObject then?

I think it depends on the use case, as always. I use Hibernate for our platform, which is used at most by 10-20 people at once. There ORM is a huge help because I can just easily view and edit my model and all its relations and I accept performance hit in this case and if something is too slow, I rewrite it in sql.

Then we have API that uses data of the platform, and there I dropdown to plain handcrafted sql with a little help of JDBI and so far it has been working great and responses are fast.

So I think it is just about stepping back a bit to think and not to blindly accept either side of the argument. Each use case is different.
Taking the strongest version of the argument Python is partly standardized in multiple implementations.

My understanding is that mostly CPython does whatever it wants and the other follows, but it is still better than a single implementation where the boundary between bug and spec would be nebulous.
Interested in more detail on this?
User Journey Mapping to Improve UX – CleverTap
The user journey map is important for discovering what features and functions keep users engaged and what causes users to churn. Follow this template to build a user journey map for your mobile app marketing strategy.
> [...] despite them being constructable from the basic Hangul codepoints.

Unicode strives for the round-trip compatibility with source character sets, and in this case KS X 1001 (KS C 5601 at that time) is a main culprit: it had 2,350 (out of 11,172) common syllables precomposed. But it happens that Korea had supplementary character sets beyond KS X 1001, which were subsequently added to Unicode 1.1 (up to some 6,000 characters), before it was decided that having an algorithmically derived section of all 11,172 syllables is better. This whole situation is now known as the "Hangul mess".
I thought this was what Conan did. Am I missing something?
I don't have kids and like to eat at the same time as my wife as I'm sure many other couples do, this is why we like to have it ready for when they arrive.
... or reduce software engineering salaries. Arguably, people want faster software if they also want faster hardware.
ORMs have their place but they are IMHO overused and frequently fail for reasons that have to do with the good old object impedance mismatch; which is a pitfall that lots of junior developers fall into where they over engineer their database schema to make it resemble some platonic ideal of some class hieararchy. When that hierarchy inevitably starts changing, the schema erodes along with it.

Some symptoms that I've seen in multiple projects:

- requests are slow because every request triggers dozens to hundreds of joins.

- overuse of the @Transactional annotation (spring/hibernate) because of developers slapping it on anything that looks like it might be doing anything with a database while neither understanding transactional semantics or aspect oriented programming (which causes some funny behavior)

- Attempts to implement class inheritance via database tables and corresponding hacks and complexity to query because of that.

- Lack of a coherent database design. IMHO, a good use of ORM should start with a good old database design. A 1 to 1 mapping of your domain to tables is typically not it.

- Over and under use of database constraints, indices, etc. because of a lack of knowledge of how databases actually work resulting in unenforced referential integrity constraints, poor performance, and weak transactional semantics.

I've used lots of different styles of databases over the years. I generally break things down into:

- simple key value stores like redis, memcached, etc.

- document databases like couchdb, elasticsearch. These tend to have schemas and fields

- SQL databases (mysql, postgres, mssql, oracle, ....)

- Nosql object databases (mongodb, firestore, etc.

I tend to mix these styles and would happily use postgres as a document store. IMHO if I'm not going to query on it, putting it in separate column adds little or no value. If I am going to query on it; it should have an index.

Years of using document stores have taught me the value of de-normalizing stuff like user names and other things that rarely change but are a part of pretty much everything. I've ripped out hibernate in favor of JDBCTemplate + TransactionTemplate on several projects where hibernate was causing more problems than it solved. Hand crafted joins are pretty easy to do.
And nothing is going to stop you from doing this, you can pack you query (native or JPA-QL or HQL) into @Query annotation and be done. The good thing is that it will do mapping for you.

The advantage of using findEntitiesByIdAndCreatedAtAfterOrderByCreatedAtDesc is that you will get for free paging support (which is not trivial and has to be done properly for each database engine, simple approach with using limit typically is very inefficient).

Also, most of the queries will be something simple to fetch some entity using some business identifier or primary key, not being forced to write down all those simple queries is a productivity boost.

For more complicated queries you can fallback to writing query manually.

There is also maturing Spring Data JDBC project that kind of has "best of both worlds".
The Supernova that measured the universe [video]
Where do you get 1% from? We're several orders of magnitude further than that from the Landauer limit, if that's what you're referring to.

However, there is considerable economic incentive to keep Koomey's law going - mostly from mobile these days, since increased computations per joule means longer battery life.
Is there a data issue here? If you look at ST16000NM001G they reference a failed drive in Q2 2020 (https://www.backblaze.com/blog/backblaze-hard-drive-stats-q2...)

I quote - >Note: The Seagate 16TB drive (model: ST16000NM001G) does show 59 drives and is listed in the report because the one failed drive had not been replaced at the time the data for this report was collected.

How can we be back to zero drive failures?
When working directly with SQL instead of an ORM, how do you elegantly handle things like parameterizing table names or having flags that turns on or off filters?

In non-ORM codebasese I am seeing patterns where sql queries are "copy-pasted" together and I am not sure I like it.

Just imagine the following example had hundreds of lines of SQL and several optional filters, some of which could themselves be several lines long:

def get_data(table1, table1, use_subset=True):
if use_subset:
filter_query = "AND column2="subset_value"
else:
filter_query = ""

query = f"""
SELECT
*
FROM
{table1}
JOIN
{table2}
WHERE
column1="value"
{filter_query}
"""
I strongly question "doesn't require a validation pass".

1. Your code drops naked continuation bytes entirely.

2. If a valid multibyte character is followed by extraneous continuation bytes it will not decode correctly.

3. Using the wrong number of continuation bytes is a giant mess and can give you arbitrary numbers in multiple ways.

The second one especially is a behavior that's hard to defend.
Why I write: The Feynman Technique for learning
Safari is plagued with these issues, it's the new IE.
The whole focus seems to be on implementing privacy features to advertise Apple's privacy focus. CSS bugs are not fixed and newer APIs are not implemented.
It's all about technique and the style you want to develop. Two singers can have very different voices too.
The only limiting thing I've experienced with ActiveRecord is when the database becomes larger and more complex. The performance takes a bit of a hit. Which isn't ActiveRecords fault, it's the developer's lack of understanding how the database works.

Most of the issues I see is a lack of understanding of things like N+1 queries. I see this mistakes from junior to senior level. ActiveRecord has built in solutions to fix them too. Some developers don't know about them.
But static sites are nothing new. JAMStack seems to pretend to be something "above" just a static site, without ever being clear what it actually is.
I thought Java's locking worked fine as long as you didn't make your locks public or lock on `this`. What is Rust doing that's an improvement?
> why do we want to use SQLite as one

Because SQLite is ubiquitous. It's simply everywhere. And it doesn't need a dedicated server to run.
That's a good point, you can actually change the way a sax sounds quite strongly, there are even people who modify their reeds. The difference between the way the same instrument family sounds on say Pink Floyd's "Dark side of the moon" (Dick Parry) sounds versus say Brandford Marsalis, Michael Brecker, Fela Kuti, Grover Washington or (god forbid) Kenny G is huge.

Of course 'saxophone' is a whole range of instruments going from Low-E giants to saxes so small you have to have pretty small fingers to not hit two valves at the same time.

The mouthpiece and the reed thickness are a big factor in this as is air pressure, 'tonguing' the reed and how you shape your mouth cavity. Endless variation.

But the basic harmonics are baked into the instrument, those would be very hard to change though I'm sure it is possible to manipulate which ones get amplified by the above changes to the environment.

https://www.youtube.com/watch?v=kZjZBe6o78M

Is a nice example, it would be a pretty boring song without that raging saxophone.
It makes sense .. if all you have is a hammer ..

The problem is exacerbated though by the amount of churn on styles of hammers, and newer developers are often too hammered to pickup other tools ..
Like I've said previously, my wife is a pet sitter and has been bitten. It's good to know where she is so if the situation ever happens again, I can find her.

The geolocation thing for me was purely so I could get dinner ready for the both of us in time since we like to eat together.
Yep. It's become more of a "hey you, look at me" kind of thing for us with my '?' being a "yo, you've got my attention- what's up?" kind of response. It works this way for him and I, but I wouldn't expect it to be an inherent shorthand in any of my other relationships.
No, "used for pet project by mismanaged megacorp" is not a sign of seriousness. (I'm sure there's some team inside FAANG that's using Brainfuck in production right now.)

"The Rust development team isn't interested in supporting your obscure embedded architecture" or "sorry, this platform was phased out due to technical debt" is what I mean by not serious.

Look at Python and how any attempts to make alternative interpreter implementations ultimately failed. (And they at least have PEPs.)
Granted the immense infrastructure investment, but why not ditch electrical and natural gas for hydrogen? Hydrogen is much safer, cleaner, and less lossy than either.
I think you just explained the point of the article to yourself.

That when a politician brags about unemployment being so low to a voter, they're doing so to fool the voter, who likely associate unemployment rate as a measure of how well off everyone is doing, while in reality it doesn't, because if you look at the "true" unemployment, i.e., what that voter is thinking, which is how poor are Americans overall, well you'd actually see a pretty glooming picture with a large number of Americans living below poverty and the number growing year over year.
Components were an implementation detail, to an immediate-mode rendering paradigm for DOM.

Previously we had been doing retained-mode rendering. We would modify & shuffle around the pieces of the page.

React's components were there to let you re-render the app quickly. When state changed, a new render happened, with new elements emitted. You didn't think of what elements used to be there.

React was about the virtual dom. It was about creating an abstraction to let us not have to regard what was on the page, when we were deciding what is on the page. Incidentally, imo, that involved components, but components, while comprising numerous html elements, serve a very similar function to html elements (especially to web components), and were not, imo, a particularly novel part of React. Yes, there was a lot to their creation & implementation, there was a lot of tech work that went into making Components a thing. But components, to me, are far outshadowed by the vdom, by the performance & speed of a data-system designed to go diff & en-act desired state into the live DOM tree.

In kubernetes world, we'd call the vdom a controller. It reads the canonical state, the component tree, and insures the target DOM machinery is kept up to date & reflects this desired state.
Including a real DB in continuous integration is a must for any development IMO. (And these days usually very easy to throw up a database using Docker -- each of our full CI runs runs in 2 minutes and does hundreds of "create database" calls and populate real SQL databases from scratch..)

For instance:

1) You want to implement idempotency in your backend by using uniqueness constraints in your DB
2) That's important to test
3) That's not really tested unless you include a real DB

After including a real DB in our CI setup I will never move back.
I am against using stored procedures. In the projects I saw where SQL code was encapsulated by stored procedures the business logic was inconsistently split between the application and the database making maintenance much more complicated than it should have been. I am in favour of stored procedures to avoid several roundtrips to the database but only when performance really matters. The case on tweaking SQL performance does not convince me. Where I work we execute performance and load tests before every release of the application and we are expected to meet performance targets that are documented in the release notes.
The Downside of Medical Progress (2009)
The article is long and swerves around quite a bit but I found it to be worthwhile. I'm working on an MVP and the last two sections were enlightening. ("Complexity Has To Live Somewhere" and "Replacing, Adding or Diffusing?")
Hey David, I've been thinking about using Retool within a data warehouse context, as I see you created a Snowflake connector. I feel like direct CRUD access on data in the data-warehouse that exists elsewhere by business users might be an antipattern, but I also can see many scenarios where this might be useful. Do you have any users/use-cases/demos where this has been used successfully?

Thanks!
You start using an orm when you're basically rewriting a crappier version of one.

You stop using an orm when you're wasting time going through it's documentation trying to figure out how to do something tricky for some obscure ad-hoc execution.
A free cross platform app for using machine learning with few clicks
> SQL has a knack for doing really easy things well, and moderately complicated things badly. I would assume by default that anything involving graphs should not involve SQL

A schema may have only one, or anyway, comparatively very few instances, of recursion.

In this case, using two separate data stores would be too much overhead; if the CTE doesn't do anything particularly fancy, that is, if it just retrieves records recursively associated via keys, it's not implicitly hard to debug (actually, there isn't much to debug).

A point in case is GitLab's users management, which dropped MySQL also because of the lack of CTEs (at the time).
It has nothing to do with it being interpreted (this is a common misidentified issue with dynamic langs).

The fundamental issue is that python is a pointer machine: everything requires a dynamic lookup in memory.

Eg.,

x = [1, 2, 3]

len(x)

Here `x` is an actual string in memory which is a key in a locals() dictionary which holds values. (cf. with C where it is just a memory address).

Likewise the list is a list of pointers (not a sequential array). And its heterogenous, ie., the contents can be of any type.

Likewise `len` is a string into a dictionary of functions which has to be looked up.

etc.

The whole thing is many levels of indirection. Applying an operation to a value (eg., even x + y) requires jumping around the memory of the machine many times.

This is necessary, in general, to deliver on the dynamic lang. features python provides.

Julia solves some of these issues by using static type information to ditch this dynamic behaviour. My suspicion is that python can follow a similar path (eg., above, x should be compiled to a static homogenous array of ints).
I second this. For example, Django's ORM is actually very advanced these days, allowing you to squeeze out the performance in many, many cases. While I agree that ORMs should not always be used (sometimes you just need raw SQL, especially on very large databases), I think the ORM hate is a bit overstated on HN.
It's too bad you're being downvoted. I had a similar reaction, and I think you're on to something important.

Many adversarial cases are good examples of this: a DL model being completely thrown off by something very incidental, that a human would instantly recognize as not being within a class. Not just something a human would instantly recognize as not being within a class, but something a human would be perplexed by as an adversarial case.

The point isn't that humans are better or worse, it's that the models do often seem to be overfitting, but overfitting in a way that isn't evident until the inputs are generalized beyond whatever is in the development samples. Put another way, they might be learning something about your development datasets more so than the actual features of interest, which is the whole idea of overfitting. It's just that what it means to "generalize" is much broader.

It's a really interesting piece but I think there's lots more to the story.
The problem is that Hangul had too many composable encodings from each vendor. As a result the government went to yet another standard (KS X 1001) that fits better to the ISO/IEC 2022 infrastructure. It was too late when the standardized composable encoding was specified as an annex to the original standard in 1992: Windows 95 didn't care about the annex and introduced their own extension to KS X 1001, now known as the code page 949 and standardized in the WHATWG Encoding standard [1].

[1] https://encoding.spec.whatwg.org/#index-euc-kr
I concur, it's the best solution for analog Video-8 tapes. Buy a Digital-8 camcorder with DV. You may get a better picture with some kind of bespoke high-end rig with rebuilt camcorders and studio digitizing equipment, but for mere mortals, it's the best solution.

I can only add, that for me it worked best to capture the tape all in one go, and not try to start-stop the camera with DV control. Be it deteriorating tapes or whatever the cause, but the capture software had problems resuming the camera if it was ever paused.