ccleve

My email appears in six breaches. Only one of the companies I recognize. I have never done business with the other five.

This pisses me off. Not that the data was stolen -- these things happen. It pisses me off that my data was shared with third parties without my knowledge or consent. And no, a paragraph buried in the basement of a privacy policy does not constitute informed consent.

This system would be more useful if it could report how these companies got my data. I want to know who betrayed me.

It wouldn't be a terrible thing to have privacy legislation that forces companies that sell your data to disclose what information they sold, when, and to whom.

How are temp tables or CTEs more tightly tied to a schema than the original query? They both reference the same set of tables and columns, and both depend on indexes being in place. A schema change will break both, in equal measure.

It isn't clear to me why so few of these optimization articles talk about temporary tables. They are my go-to solution for many situations.

Temporary tables are great because they break the problem down into smaller pieces. They make the query much more understandable. They are way easier to debug. They are way less sensitive to failing because the query optimizer decides to do things differently because table statistics have changed. They will often eliminate the need for exotic syntax.

You also have the opportunity to add secondary indexes to these tables.

When you create a temporary table, you are essentially doing the work of the optimizer yourself. That's perfectly ok if you know things about the data that the optimizer doesn't or hasn't successfully figured out on its own.

They're not for every situation; they only work well when the intermediate tables are small and fit in memory. But that is very frequently the case.

Agree. It would be good if Github could enforce some standards as well. Maybe I should read the docs to see if they do...

Hey Microsoft, if you're listening, you should throw Sonatype or other Maven-related organizations a few bucks. They deserve it.

This is really outstanding.

It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype.

On the other hand, it took me three days to release a new version of one of my artifacts the other day. The process for doing a Maven deploy is very complex. It took hours to get my private key to work because the key registries were slow. Then the staging server was slow, and kept timing out. Support was responsive, and said they were dealing with a DDOS attack. On top of that, it takes a while for artifacts to show up in the registry even after they have been uploaded. I'm glad that getting that artifact out wasn't an emergency.

This new Github service separates the registry from the artifact storage, which is the right way to do it. The registry should be quick to update because it's only a pointer. The artifact storage will be under my control. Credentials and security should be easier to deal with. I really hope this works out.

Agree. That's the approach I took with Norm (https://github.com/dieselpoint/norm). The general idea is that I just wanted to get rid of JDBC boilerplate and use plain Java objects, but not stop using SQL. Being lightweight is the key.

I remember reading that electric motors are much lighter than gas engines for the same amount of power. This difference can at least partially offset the added battery weight.

Also, it's possible to have multiple, small electric motors with no loss of efficiency. That isn't possible for a gas engine. Multiple motors could add some redundancy, and therefore reliability.

I think we're going to see a lot of interesting designs over the next few years.

Looks like you're using undraw svgs with the default color. You can change the color by clicking the color button in the upper right corner of the undraw site.

I'd add some examples of emails that look good that are done in Markdown. Starter templates would be really helpful.

I'd change the limit from X emails/day to X/month. Who sends mass email every day?

I can't tell what the pricing would be for a much larger number of emails without signing up. Do it the way Mailchimp does -- put your pricing slider outside the signup.

I have spent quite a lot of time building a database in Java. It's not a small undertaking.

I've gone through as many books and papers as I can, and there is only one, one, that gives an overview and actual examples of building a system that processes SQL. Everything else is theoretical or so general that you don't get enough direction to get started.

It's "Database Design and Implementation" by Sciore. It's a little dated, but not by much. It is an underappreciated resource.

Way too many to list. Read the article itself, there are links and references.

Anti-free market thinking pervades academia, despite the fact that free markets have generated an unprecedented level of material wealth. Markets feed, cloth, and employ academics who haven't the faintest idea where the money comes from.

No one disputes the fact that monopolies capture an undue amount of wealth. But to launch a general attack on entrepreneurship is fatuous and offensive. I'm sitting here are my desk living that life right now, creating a product that, down the road, will indirectly make that smug academic wealthier. Maybe he should spend five minutes in the business world. He might learn something.

Happy to. I just added my email address to my profile.

Yes.

I did two implementations, one with plain text files and one with a kv store. For plain text files, I had to maintain file offsets of the records so I could traverse backward and truncate records that had to be replaced, and then break the files into segments so I could retire segments that are no longer needed. It had all kinds of little bugs.

Then I reimplemented using a kv store, and it took a tiny fraction of the time. And surprisingly had better performance.

Just create a good interface at the start, use the kv store underneath, and then later if you don't want the dependency swap it out for the more complicated code.

I have a lot of questions about this paper. Parts of it aren't clear to me.

Is anyone aware of a forum where consensus algorithms are discussed? A mailing list, subreddit, or website?

I found a Raft mailing list a while ago, but I'm looking for a place for a more general discussion, where real experts hang out.

To make it work with any kind of performance, all message passing needs to be asynchronous, and you need an event loop to process messages one at a time. Things are much simpler if your code is effectively single-threaded when processing an inbound message. That took me a while to figure out. Futures and promises are very helpful.

It took a while to get the building blocks together: the log file, which can be traversed, read, and rolled back/truncated (use a kv store for this, trust me), and the transport mechanism to deal with sending complex objects and handling errors and timeouts.

Tracking terms, states (leader, follower, candidate), rejecting out of date terms, voting, elections -- it's all very complex. You'll have to build some really, really good multi-threaded tests that simulate out-of-order and dropped messages, then really pound away at the system. And good logging to find that odd corner case that keeps coming up and throwing mysterious messages.

I haven't even tried membership changes yet.

That was my experience as well. The rules around leader election, terms, voting, timeouts and the like are very subtle.

It took me months to do a reliable Raft implementation. The author of the Raft paper, Diego Ongaro, wrote in a comment on a Raft mailing list that it could take weeks.

The Raft paper is really easy to read and understand, but the actual code is very tricky.

I wonder if the date problem is a bug, not a feature?

Is it possible to dump the metadata of a book and check if they have the right date? There should probably be multiple dates for a book -- date written, date copyrighted, date published, date of latest edition, etc.

My guess is that Google does not have a publicly-available issue tracker for Google Books so you can't easily report this problem. Hacker News is a good way to get their attention, though...

It's likely to be difficult. I heard a good analogy once: imagine balancing a broom, handle pointed straight down, on one fingertip. It's not that hard. Now imagine balancing a toothpick. Impossible.

Scale matters. Bigger things are more stable.

Ah yes, didn't know that was there. Would be nice if Maven acknowledged it.

Some kind of standardization would be helpful. In particular, it would be good if a tool could sort on the post-hyphen part so it could know which pre-release version is most recent.

I want to see some support for alpha, beta, pre-release, and snapshot versions.

The problem is that everyone does it differently, and build systems have a hard time distinguishing these non-production-ready versions. For example, I type "mvn versions:display-dependency-updates" and I get a suggestion that I use "junit 4.13-beta-2".

Upvoting the parent. The comment is worthwhile and merits discussion. Should not have been downvoted.

The comment that this is a way of reducing investor risk and may yield a higher valuation is well-taken. But founders should not agree to it, because their risk is far, far, far higher than that of the investors.

A founder gets one shot, or maybe two or three shots, in their lifetime. An investor gets many shots across a diversified portfolio. A founder puts their career and their financial future across in this one basket. They put their sanity and their personal happiness in this basket. An investor puts nothing but a small portion of their, or more frequently other people's, wealth in this basket.

Making it less likely that a founder will get a payoff is just stupid. A founder should do everything they can to reduce their risk, even at the cost of a lower valuation.

Don't do this. MySQL removed result caching because it caused problems. https://mysqlserverteam.com/mysql-8-0-retiring-support-for-t...

I'd love to learn more. I'm in need of a fast engine.

What proprietary engines do you know of that I can look at?

Do you have more details on your own designs? Anything you can share?

Disagree. $60 is nothing if this tool saves me hours of time. The developers need to make sure they make enough money to keep the project going.

I like this project way better than Bootstrap Studio or any of the others I've tried.

Some suggestions:

1. As others have mentioned, HTML editing is pretty important. I'd like to see my actual content when picking a layout.

2. Would also like to see a theme picker, so I can cycle through combinations of colors/fonts/etc. and see what looks best. I know I can do that under Change Styles, but I haven't the artistic skills to pick individual values and have them look good.

3. Add a search box component.

4. I don't see a way to add a sidebar menu on the left and have a custom content area on the right. It would be nice to have some way to nest components. This is important because I would probably use this mostly for building admin interfaces and dashboards.

5. Someday, in the future, and maybe this is well beyond scope, I'd like to have Vue components so I could just hook them all together and they just work. I expect that that would be a massive undertaking, though.

#1 & #2 are pretty important. The rest -- I don't think they're critical to having a commercially successful project.

Another vote for Azlo. I have three accounts there, my main business account, which has a decent balance, and two low-balance side accounts.

I abandoned Chase because I got tired of the absurd fees, and the know-nothing perfectly-coiffed straight-out-of-college twits they have working there.

Azlo has zero fees and they're very responsive. Have been mostly happy.

One downside is that you can't hand-write a paper check. You have to use the online bill pay system to mail a check. That hasn't been a major problem. I went a year without touching my Chase checks.

The other problem is that they are a day or two slow when receiving funds via check or ACH. Their hold times are longer. That's a bigger problem. They say they're working on it.

I'm glad they're going to try to get multi-line strings right, but seriously, I (and many other people) have wanted this feature for 19 years.

This is not an exaggeration. I was writing code in Java to access SQL databases in 1999 and needed it to express long SQL strings.

One would think they could move a little faster.

"Don't pave cowpaths" is relevant here.

If the old software is convoluted, it may be because the old business processes are convoluted.

A software rewrite should be done in the context of a business process redesign. Consider how information flows through the organization. Do you really need to do all the things you're doing now? Should different people or departments get different information? Should the product you're selling or the service you're providing change? Should parts of the process be outsourced or insourced?

If an IT department is considering a big rewrite, but doesn't have the authority to look at the business as a whole, then the project is being managed at too low a level. Rewrites make the most sense in the context of a change in the underlying business.

If the school would force teachers to grade on a curve, the problem would go away. Teachers would have only a limited budget of high grades to give away.

Grading on a curve is not without problems, particularly when class sizes are small, but it has a lot of benefits. It makes it easier to compare students across schools when the schools use the same curve.

Sorry, I'm going to be a contrarian here. JWTs can be good.

First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location.

The only real issue is, should session state be on the client or on the server?

Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1) have sticky sessions, which generate problems when a server goes down; 2) have a central session server, which generates scalability and reliability problems; 3) have a Redis-like distributed system, which either a) must do one or more server-to-server round trips on every client call to validate the session, or b) cache session information on a node.

When latency matters, an extra server-to-server round trip is a non-starter. And if you do server-side caching, then cache invalidation and JWT invalidation present similar problems. ("There are only two hard things in Computer Science: cache invalidation and naming things.").

Server-side sessions don't really buy you much. If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work.

JWT is a good solution to the problem. You can store small amounts of session state on the client and simplify the whole system. You can avoid having to do lookups to determine state variables. (What database was the user connected to? Is he in mode A or mode B? What timezone? What language?) Put a short expiration on the token (a minute? five minutes?) and force the user to re-validate against some data store after that.

The benefit is that you greatly reduce internal server traffic at the cost of not being able to invalidate a session within your short timeout interval. Depending on your app, letting someone remain an admin for an extra minute is not a big deal.

And if it is a big deal, you can still handle it by sending a message to each node telling it to invalidate that particular user. A pain, yes, but the tradeoffs may be worth it.