rodw · HackerTrans

2 miesiące temudiscuss

Page load time can impact index coverage (depth of crawl), freshness (revisit rate), and ranking.

2 miesiące temudiscuss

Looking like a "touch button" is still looking like a button. Some indication that an element is tappable is still useful.

rodw

2 miesiące temudiscuss

Technically (in the US at least) purely AI-generated content has no copyright, hence any copyright associated with the commit can only assigned to the human authors (or the entity they are working for). As I understand it neither Copilot nor Microsoft should have any actual claim of authorship (from a copyright/IP perspective).

It's still quite problematic IMO

rodw

5 lat temudiscuss

Also, while I imagine Google probably has (or at least easily could have) code-specific heuristics at play, it seems like it may be harder to reliably apply duplicate content penalties to source code listings, especially short code snippets.

Between the constrained syntax, literal keywords, standard APIs and common coding conventions it seems like even independently-authored source code listings will be superficially similar. Certainly the basic/naive markov-chain-style logic that works really well for detecting even small examples of plagiarism in natural language content isn't going to as effective on `public static void main(String[] args)` or whatever.

Obviously there are strategies that could distinguish superficial/boilerplate stuff from truly duplicated code, but between the volume of actual (and often legitimate) duplication on the internet and the (maybe?) low ROI for duplicate content penalties for code relative to other value metrics/signals, maybe this just isn't terribly important as a quality factor?

rodw

5 lat temudiscuss

Funny, it was the "lots of internal linking" bit that felt wrong to me. Not that these low-quality sites don't do that, but I'm surprised to hear that the new algorithm rewards internal links. I'm certainly not a full-time SEO guy, but I happen to have or work with a few sites - some fairly established - that make extensive use of internal links for design/editorial reasons. As far as I can tell they are helpful for (a) user navigation and (b) getting search engines to discover/index the pages but I don't think I've seen any notable advantage in or even impact on ranking based on those internal links (whether in the body copy or in head/foot/side "navigation" areas).

Searching just now I do see some other sources making a similar claim, so maybe I'm just out of the loop. But in my cursory scan I haven't found much detail or real evidence beyond "google says they matter" either. I mean, that's not why those internal links were created in the first place, but it sure would be nice to get a ranking boost out of them too. I wonder what I'm doing wrong :)

rodw

8 lat temudiscuss

Moreover, Node.js's non-blocking, single-threaded nature is great for the kinds of plumbing that things web services and related applications require (The stuff we used to call "database-to-web" applications -- i.e., fetch some content from a data-store and render it and/or accept some content from a client and store it) but seems like a pretty poor match for disk I/O and CPU-bound applications like a database.

And I'm saying this as someone that's actually a big fan of JavaScript and that does a fair amount of enterprise-scale work with it.

EDIT: I meant to add: But, I think this might be beside the point. If you are looking for a language than a large number of people can more-or-less read and write, JS is a pretty good choice. If your objective is teachablity/readability rather than production-quality performance or capabilities, I think JS is probably on the short-list of candidate languages.

I can't find the quote offhand but I think Douglas Crockford or someone like that described JavaScript as "the only language people feel comfortable using without learning the syntax". (This was especially true prior to server-side applications like Node.js, when JS was largely considered a toy-like language for scripting basic input validations). If nothing else, this makes JS a reasonable "executable pseudo-code"--something practically any programming can read and probably most can execute.

rodw

8 lat temudiscuss

Hi Denzel. I replied to a very similar question at https://news.ycombinator.com/item?id=18562007 so rather than repeating myself I'll just point you to that.

rodw

8 lat temudiscuss

Exactly. We sort of backed into this project by starting with HSQL (http://hsqldb.org/) a low-end pure-Java "database" that was popular at the time.

The more we used HSQL the more it became clear that it was more like a SQL-parser wrapping a simple key/value store than a full-on ACID database. We created AxionDB precisely because we needed the kinds of capabilities you mention and at the time HSQL did not provide them and wasn't remotely architected to support them.

To be honest though, creating a moderately robust RDBMS from "scratch" turned out not to be the most ambitious or complex part of the overarching project that spawned AxionDB. The harder part was trying to use Java's primitive, built-in HTML-renderer to create something approximating a fully featured browser. The effort and complexity behind something like Gecko, WebKit, Edge, Blink, etc. is very easy to underestimate. It's a hard problem, made much harder by having to tackle the kinds of content you find "in the wild. Frankly building a database was a much more straightforward problem than that.

rodw

8 lat temudiscuss

"Oddities" might be overstating it, but I remember a number of times a light went off and I though "oh, so _that's_ why Oracle does X". It was the same kind of information you might deduce from looking at a "query plan" from `EXPLAIN` or similar, and the kind of thing you might deduce from a careful review of topics like transaction isolation levels.

It's been a very long time so I'm not sure I can name many specific examples, but IIRC some of the topics that became very clear were things like:

* the importance of the order in which JOINs and WHEREs are applied (to limit the number of rows being accessed per step)

* the relationship between columns that are selected and those that appear in WHERE and ORDER BY clauses.

* the value of tables with a small number of columns (limiting data that must be read per row)

* the cost/complexity of variable-width columns (VARCHAR vs a fixed-length string), again because of the time and complexity required to do something like "skip ahead three rows" in a data file

* the behavior of CLOB/BLOB types (stored external to the "main" table content)

* the various types of transaction isolation levels and the conditions in which it becomes hard or impossible to guarantee isolation without table or row locking

  * etc.

The references at http://axion.tigris.org/readings.html describe some of the theoretical concepts we seemed to think were important or useful at the time.

Also, there's a post at http://heyrod.com/articles/radio-blog/pleasures-of-profiling... that describes a session of performance-tuning on the index implementation that gets into some of the nitty-gritty implementation topics. (But a lot of the issues addressed there were an artifact of Java's primitive vs. object representation, which has been reduced by things like generics.)

rodw

8 lat temudiscuss

For complicated reasons I was involved in a successful project to develop an open-source, Oracle-SQL-compatible, transactional-integrity-preserving, extensible database designed for in-memory performance in Java. In the process of this development "suddenly" the reasons for a whole bunch of performance and syntax oddities in databases like Oracle and PostgreSQL became very clear.

I was shocked to learn that was 15 years ago when I looked up the link to share, but if you are interested in the topic of "how to implement a database" it may be worth a look.

For what it is worth it was listed (not by me) on the C2 Wiki on the "Programs to Read" Page, where it was described as "[A] database written in Java with good unit tests and ShortMethods." [1]

Both statements are true, for a complete working example of a production database (it supported a commercial product for at least 10 years) it is actually a pretty accessible and well documented code-base.

The project is called AxionDB and can be found at [2].

[1] http://wiki.c2.com/?ProgramsToRead [2] http://axion.tigris.org/source/browse/axion/

comments