SQL style guide - <AUTHOR> http://www.sqlstyle.guide/ <comment><USER2> Weird, I really dislike a lot of the suggestions. In particular, an example:

      SELECT first_name AS fn
        FROM staff AS s1
        JOIN students AS s2
          ON s2.mentor_id = s1.staff_num;

We already agreed that staff is a good name for a table, so why are we renaming it to s1? There are all sorts of subtle bugs that arise when s2.mentor_id = s1.staff_num is wrong, and the variable names provide no help here that we're doing things right.

How about:

      SELECT first_name
        FROM staff
        JOIN students
          ON student.staff_id = staff.id;

If you're reading some 50+ line SQL query with a bug, things like this are easy to read and be confident in. Honestly, I think AS should basically never be used for tables.

Likewise, the guide gives the example of naming join tables 'services' instead of 'car_mechanics'. But if I see a table 'car', a table 'mechanic', and a table 'car_mechanic', I instantly know how to join against this in any direction. The hard part of understanding a schema is how it fits together, not what it represents, and when you have hundreds of tables and need to remember that join table's name, it's really, really nice if it's trivial to derive.

Lastly, the guide's recommended indentation for FROM vs JOIN statements seems off to me. Consider:

      FROM riders AS r
             INNER JOIN bikes AS b
             ON r.bike_vin_num = b.vin_num
                AND b.engines > 2

Well, the thing is, the riders table and bikes table have the exact same priority in the query, but this spacing really emphasizes the riders table and it's not clear why.

<comment><USER3> > Honestly, I think AS should basically never be used for tables.

I believe AS is required for self-joins. A common expository query is to find all employees who earn more than their managers, which can be expressed via "select name from staff as employee join staff as manager on (employee.manager_id = manager.id) where employee.salary > manager.salary".

Also, SQL allows a sub-select to be listed in the FROM clause. But in such cases, the sub-select must be given a name (tables have a name, but sub- selects don't).

As an aside, the keyword "AS" is allowed by not required.

<comment><USER2> Sure, I forgot the self-join case. In my experience these are a minority of joins, but definitely. In postgres at least, a lot of self-joins can be solved with a DISTINCT ON instead.

Sub-selection with a FROM clause, yeah, those definitely need names. But those don't have perfectly good names that everybody already knows, whereas tables do. If you're maintaining somebody's code and they declare

      foo_bar = 10

I think it'd be pretty strange to ever consider writing

      fb = foo_bar

just because you find foo_bar too long to write or something.

</comment></comment></comment><comment><USER4> Try to use only standard SQL?

Stopped reading right there.

There is no way you can port SQL Server to MySQL to Oracle to PLSQL without rewriting virtually every single query. They're all too different.

So why bother? Write idiomatic code that other programmers used to that engine will understand.

Not only that but different engines like different things. That blazingly fast nested subquery in MS SQL will become a massive performance problem in MySQL.

There is no such thing as portable SQL, don't pretend there is.

Not only that, often the standardised way is worse than the vendor specific way (e.g. INFORMATION_SCHEMAS vs built in sp_ from MS).

<comment><USER5> I completely agree with this. One should never plan to change database engines -- it just happens so rarely and it's such a big deal that planning for it is a waste of time.

It would be like coding in Java in such a way to make porting to C# easier in the future (or vice-versa).

<comment><USER6> So it isn't true anymore that quickly growing companies often need to go from one of the open source DBs to Oracle, after a decade or so?

(OK OK, that is a good problem to have.)

Right now I miss Oracle. (Never thought I'd say that. :-) )

<comment><USER5> It's highly unlikely you could ever use generic enough SQL to go from open source DB or Oracle. Best case you wouldn't be getting the best performance out of your open source database and then you wouldn't be getting the best performance out of Oracle.

It's better to build for the platform you have than build for a mythical common platform that contains the minimum features of syntax of all of other DBMS (which probably doesn't exist). If you change DB platforms, you're just going to have to rebuild.

<comment><USER6> OK, your point is not that DB changes won't happen -- but that there is no use to prepare and think about it beforehand. Sounds reasonable to me.

<comment><USER7> Kind of like premature optimization, "premature compatibility" can be a performance/labour-hours killer.

</comment></comment></comment></comment></comment></comment><comment><USER8> I never get the fussing with aligning. I get the importance of clean indenting, but so much SQL I see looks like the writer spent a long time tweaking the alignment with spaces to make sure the data types lined up perfectly or the ON clauses or what have you.... And then had do do it all over again the moment they changed something.

Just indent when scope changes, and don't align things. Alignment is a time- sink.

<comment><USER9> I always think of the DB, as the last castle of a program. When everything else fails, the DB should function. Programs are maintained way more than they're written.

No matter how hard I try to keep my code-base clean, it gets cluttered.

That's why I strive to create a powerful base structure and make them bulletproof.

Whatever may come (depression, personal problems, fatigue, stress, deadlines, etc.) this skeleton keeps the app alive.

In my experience code that is written now, will stay and that complete rewrite I've been dreaming about will never happen :D.

So IMHO it's better to design the core funcionality exhaustively and try to create a failproof code-base.

My intellectual capacity fluctuates and I'm never as productive as I want to be. I need a safety rope for my dumber version, who has forgotten about the code and has no idea where to start :)

Indenting, and aligning helps a lot, when I try to load the code back into my memory.

<comment><USER10> "I need a safety rope for my dumber version"

I like this. 14:00 Numberwang appreciates the effort.

</comment></comment></comment><comment><USER11> Though mostly good advice, I definitely disagree with this:

      DONT:
      Plurals—use the more natural collective term where possible instead. For
      example staff instead of employees or people instead of individuals.

I like naming my tables as plurals so that foreign keys to the table rows can have a name that relates to the table name. For instance, having column `Orders.employee` as an FK to an `Employees` record makes much more sense than having column `Orders.employee` as an FK to a `Staff` record.

<comment><USER12> The debate about singular/plural naming for relations comes up frequently. In my opinion, it stems from the fact that English has only 2 forms for all the possible grammatical cases. It has only a different form for the singular and plural cases, and thats what people concentrate on. I propose to take a step back.

There are quite some languages that have different forms for the nominative, accussative, dative and genetive case. Lets take Latin and the concept of an unpaid developer ( _servus_ ).

Servus is nominative singular. Lets make it plural: _servi_.

      Select from servi...

oh wait, we have a from so we need an ablative plural here. So we get:

      select from servis...

What about updating? Then we need a plural accusative form:

      update servos...

But are we updating the whole collection or just a single record? Then we should probably talk about _servum_. Et cetera ad infinitum.

This _might be a little overstretched_.. Why don't we __just use the normal form __(the style guide talks about _natural_ ) of a noun? Good question, that is the singular nominative form. So, why make a special case for plural and ignore al other grammatical concerns?

<comment><USER13> Ian Mackinnon, is that you? ([http://stackoverflow.com/a/3894235/1163893](http://stackoverflow.com/a/3894235/1163893))

<comment><USER12> Nope, i am not. But good catch, since his comment on SO made me originally see the light. :)

</comment></comment></comment></comment><comment><USER14> I have often seen commas placed at the start of each line when columns are being listed. I'm a little surprised this guide doesn't follow that convention. It would fit nicely with the established pattern of lining everything up:

      SELECT first_name
           , last_name
           , email_address
        FROM users

Can anyone speculate why it's not done this way in the guide? I think the reasoning behind it was to make later modification easier because adding or removing the last field required modifying two lines.

<comment><USER15> This is a pretty commonly asked question. The answer is two fold:

1\. putting the comma before doesn't actually make commenting out columns easier - it just moves the problem to the other end of the list. Just try commenting out `first_name` in your example and you'll see what I mean.

2\. because normal convention would be for the comma to come immediately after an item in written English.

<comment><USER16> Re; #1, I also use comma-first indenting and I actually put each field in it's own line specifically for ease in commenting (first_name would have its own line)

<comment><USER15> This doesn't solve the problem at hand either unfortunately. You'll still have a hanging comma in front of `last_name`:

      SELECT
          -- first_name
           , last_name
           , email_address
        FROM users

When parsed it will look like this query error to the system:

      SELECT
           , last_name
           , email_address
        FROM users

</comment></comment></comment></comment><comment><USER17> If you're using Rails, your life will be much simpler if you do use an 'id' column, use plurals for table names, and name your join tables 'bars_foos', i.e. using the plural on both sides and in alphabetical order.

Don't really agree on indenting joins that are at the same level as FROM. There's not much semantic difference between the table in the FROM clause and one in a JOIN clause. Subqueries should be definitely be indented when nested.

Don't really agree with the leading whitespace alignment either. Alignment across lines is generally troublesome when combined with team development and version control: it leads to merge conflicts. If you start using 'GROUP BY' that forces you to introduce whitespace in your 'SELECT' line to bring everything into sync, then chances of a conflict increase quite a bit.

Don't 100% agree on using IN either, in particular if you're using a tuple membership check. That is, `JOIN x ON (x.a, x.b) IN ((1, 2), (2, 3), (4, 5))` certainly looks neater than the equivalent mix of ORs wrapped around ANDs, but it usually performs quite a bit worse because not many people write their SQL that way and the DB is not normally tuned for it.

A much bigger concern from my perspective (reviewing PRs from other developers) is writing SQL that will perform well for the database and data sizes. There are massive perf pitfalls around NOT EXISTS vs NOT IN, and it's easy to get horrific performance out of MySQL especially if using a subquery in the WHERE clause.

Structuring things as a join gets much more predictable performance, and structuring a set of joins as nested subqueries instead of joins at the same level (or using extra parentheses in Postgres) gives the SQL author more control over what will be done. Don't trust the optimizer to know best. It often doesn't and if it chooses wrong, it can hose a release. Measure, as always.

<comment><USER18> > Don't really agree with the leading whitespace alignment either. Alignment > across lines is generally troublesome when combined with team development > and version control: it leads to merge conflicts.

I'm definitely with you there. I've written about the disadvantages of this kind of column alignment several times on HN, so won't repeat them here. (Well, if anyone asks, I'll dig up a specific comment or two.)

I have a suggestion that can help anyone cure the temptation to column align all the things: Try coding in a proportional font for a while.

Contrary to popular wisdom, proportional fonts work fine for most kinds of programming. The only thing you can't do in them is column alignment, and in most cases this limitation is a _good_ thing.

Instead of column alignment, you'll be forced to use indentation, and you may discover that indentation alone gives you enough ways to make your code structure clear without arbitrary alignment.

In my case, it happened the other way around. I got tired of the problems that column alignment caused, so I stopped using it and switched to indentation only. Some time later I was curious and tried a proportional font, and the code was still just as readable as before. So now I use proportional fonts all the time, and I'm no longer tempted to use column alignment.

</comment></comment><comment><USER5> My SQL style guide is quite a bit different from this:

* Use consistent and descriptive identifiers and names.

* Make judicious use of white space and indentation to make code easier to read.

* Try and use the same column/table naming convention as your programming language. If you language uses camelCase, use that. If it all possible, names should be the same everywhere to prevent confusion.

* Table names should always be in the singular: "Person" instead of "People", "Invoice" instead if "Invoices". This removes all pluralizing ambiguity and makes sense when mapping to class names, etc.

* Concatenate two table names together to create the name of a relationship table (especially in the case of many-to-many) unless a more appropriate name makes sense.

* Use TableNameId as the primary key column name.

\---

* Do not use descriptive prefixes or Hungarian notation such as sp_ or tbl.

* Do not plurals -- don't even use collective names

* Avoid quoted identifiers

* Avoid underscores -- except for use a poor-mans namespacing

* Avoid simply using id as the primary identifier for the table.

* Avoid aliasing as much as possible unless joining the same table multiple times. In that case, use a descriptive name. Never use short one or two character aliases.

* Avoid putting keywords in all caps -- use an editor with syntax highlighting instead.

</comment><comment><USER19> An interesting read! I do follow certain rules when writing SQL, and I agree that having them and following them is a good idea. Plenty of what is in the article looks like good advice.

However, these rules do not always appear to be consistent with how the code in (most) other programming languages is written. Consider indentation, for example. The usual approach is to line up those elements of the code which correspond to the same logical level of the flow, whether it is C++, Javascript, or Lisp. So rather than (quoting from the article)

      SELECT file_hash
        FROM file_system
       WHERE file_name = '.vimrc'

I would rather see either

      SELECT file_hash
      FROM file_system
      WHERE file_name = '.vimrc'

or

      SELECT file_hash
          FROM file_system
          WHERE file_name = '.vimrc'

(The difference here is the same as between indented and non-indented braces in C.) I think this is especially useful when we have multiple joins or inner queries.

Many suggested rules are indeed consistent with what I have seen to be accepted as best practices. Such as naming a table in singular (more precisely, giving it the name of what a single row corresponds to), or avoiding the infamous Hungarian notation (pretty much an accepted best practice in most languages that I have seen).

Overall, I think, a good first step towards building best practices.

<comment><USER20> It's good advice, but the formatting shown is not conducive to quick editing imo.

Here's your huckleberry:

      SELECT
      	fs.id,
      	fs.file_hash
      FROM
      	file_system fs,
      	other_table ot
      WHERE
      	file_name = '.vimrc' AND
      	fs.id = ot.file_system_id

<comment><USER19> Yes, this is better. BTW, I saw people writing things like

      fs.id
      ,fs.file_hash

and

      file_name = '.vimrc'
      AND fs.id = ot.file_system_id

which has subtle advantages (such as easier editing).

Also, I cannot bring myself to writing SQL keywords in all caps. It feels ancient. Just a matter of taste.

</comment></comment></comment><comment><USER21> "Where possible avoid simply using id as the primary identifier for the table."

Has anyone had trouble by using surrogate primary keys? I've found the opposite of what the author said could be more true: composite keys should be avoided instead.

<comment><USER22> I think the author was talking about (not) using `id` as the column name, e.g. `user.user_id` instead of `user.id`

<comment><USER23> ON second reading I think you are correct. I agree on this point then, as it helps when joining through a denormalized table that references multiple PK ids, ex: I think: user_id = role_id is more readable than the likely alternative: u.id = r.id

<comment><USER24> it also lets you use the join foo using(foo_id) syntax, which I quite like

</comment></comment></comment></comment><comment><USER25> Naming conventions are pretty controversial I think.

The databases I deal with are mostly for storing time series data taken from measurement instruments (i.e Load Cells, Thermocouples, Flow transmitters, Pressure gauges etc). We seem to use prefixes to distinguish columns i.e.

MS_ (Mass in Tonnes, MS_KG_ etc. Is used If not stored as Tonnes) VL_ (volume, in cubic meters) RT_FL_ (is Flow rate in normal cubic meters per hour) TP_ (is temperature in degrees Celsius) PR_ (is gauge pressure in KPa)

I've seem some databases which didn't use a prefix convention and in my experience it was a real nightmare trying to keep track of units etc.

There is an ISO standard for naming conventions ISO:11179 - My work's databases are (apparently) configured based on this but I'm sure the DBA's extended it in a bunch of ways.

<comment><USER8> I tend to prefer English suffixes and camelcase rather than Hungarian prefixes and underscores. Like, for a steel coil, InnerDiameterMM, MassTonnes, GaugeMM, etc. I prefer to leave abbreviations for cases where it's obvious even to non- experts, like mm for millimeters.

<comment><USER25> My only issue with that is you'd wind up with some very long column names.

Using prefixes you can encode a lot of information in a relatively short ID. Which may or may not be useful. As you mentioned though the downside is it requires some domain knowledge to decode.

A lot of our columns are in a form like this:

TP_TSC_HEX1_XXXXX

(where XXXX is some ID usually from scada system)

I can see from the name this is a temperature corresponding to thermocouple id: XXXX in TSC Heat exchanger 1.

Edit: I should also mention some programming languages (not sql) have a language feature for specifying named ranges (I think it is called lazy evaluation) which tends to favor prefixed names over suffixed - I.e x1,x2,...,xn to iterate over the prefixed range. We use SAS heavily at my work which supports using this syntax, which probably influenced the design of our DB tables.

</comment></comment></comment><comment><USER26> Still dont get why sql uses all caps for keywords. It's one of the few languages that has it as a best practice. I can read C/JavaScript/go just fine without all caps.

I do it anyway to conform.

<comment><USER27> You can ignore the boilerplate if its in CAPS. Quite a few DB engines enforce as a syntax error a SELECT that isn't in the precise order of FROM WHERE GROUP HAVING ORDER LIMIT (plus some others depending on your DB). You and I understand what we mean if we write

LIMIT 10

SELECT *

FROM wtf

but many DB engines will be unhappy because LIMIT has to be after FROM, etc.

Once you're used to the strict order rules, you can skip reading anything in CAPS as long as the bug you're fixing isn't that they're myspeled or order out of.

</comment></comment><comment><USER27> Encoding. Needs a standard for encoding. "We are all UTF-8 here" As a parody of a bad design: this table is UTF-8 except for that column which is UTF-16 LE and that column of names is CJK and the street addresses column which is 7bit ASCII.

If you embed encoding into a design where the data changes like putting png files into a column named icon_gif, you are deserving of physical punishment. A better design is column binary_blob_28 should really have a sister column named binary_blob_28_mimetype. And don't get cute and use silly names for mimetype, if IANA's never heard of it you probably shouldn't be using it as a name.

Oh and while you're all unicoding for a good time, standardize that everything you write is run thru a normalizer as appropriate, or at least "you tried".

Another fun area not covered (or I missed it) is nothing is more hilarious than a timestamp without associated timezone. So is 1846 a good Central time to eat dinner, or a good UTC time to eat lunch in the midwest USA, or ... some DB support a surprising amount of TZ conversion although TZ always turns into a surprising amount of pain. "We're storing every time as UTC" isn't the worst idea ever.

Where possible ALWAYS use "id" as the name of the table primary identifier and its always a bigint... why burn infinite limited brain cell cycles trying to figure out the prikey of an arbitrary table "hmm well table employee uses MD5(social_security_or_equiv) which is a 16 byte char as its primary key but table source_code uses git hashes now is it the full 40 bytes or is 7 byte prefix good enough (usually is...). If you have to look up every foreign key or even worse, guess, or worse yet, guess and get it wrong, thats the last time your prikey won't be a bigint named id. Oh and as a corollary all your foreign keys will always be named "something_id" type bigint where "something" is the exact table name, not just close.

For the largest subset of equipment you'll interconnect with, figure out the best hardware supported hash and use it for non-security (de-duplication, for example) purposes. That may very well be md5, or maybe the lower 4 to 6 bytes of md5, or whatever.

Speaking of security the guide didn't go into it, so unless you're conferred with someone who knows the problem domain plus a little about security, assume your DB will downloaded next week and published on wikileaks ... don't do something stupid with sensitive data. If theres no reason to store sensitive data, then don't store it at all to begin with!

</comment><comment><USER28> Further suggestions:

\- If a field should never be NULL, put NOT NULL in the field definition. If a field should be unique, put UNIQUE in the field definition. This improves both correctness and index performance.

\- A useful format for CREATE TABLE is the one you get back from SHOW CREATE TABLE.

</comment><comment><USER29> The suggestion to right-align the root keywords (e.g. SELECT, FROM, WHERE) and left-align everything else does make the SQL look good.

But I can't think of a single editor that makes this type of alignment formatting easy to do. Can you?

<comment><USER30> emacs C-u M-x align-regexp can do this, if you give it a regexp matching the keywords you wish to right-align and enter -1 when prompted for "group to modifiy". It would still be a hassle though.

</comment></comment><comment><USER31> Can anyone explain what this means?

> 1\. The key should be unique to some degree.

If it's talking about primary keys (which it seems to be), it should be unique, full stop.

If it's not, where does uniqueness come in? Is it actually talking about indices, which, if I understand correctly, should have a wide spread of values (without any of them necessarily being unique) if they're to be useful?

<comment><USER32> It is just the terminology.

Technically, a key is any column (or a set of columns) that you use to find records. It does not need to be unique. But it tends to be more useful if it is more selective, I guess that's why they say 'to some degree'.

So now, if a key is also unique, it is called a 'candidate key'.

In general, you can have more than one candidate key in a table. For example, a natural key (such as order#) and a surrogate key (e.g. 'id').

Among candidate keys, you pick one, and call it 'primary key'.

<comment><USER31> > Technically, a key is any column (or a set of columns) that you use to find > records.

Isn't that an index rather than a key?

I thought 'key' meant:

\- a superkey (any set of columns the values of which must be unique in any given row; in a properly relational model, any relation will have at least one, the trivial superkey, the set of all attributes in the relation)

\- a candidate key (a minimal superkey, i.e. one without redundant columns -- if you remove any column from the key, it will cease to be unique)

\- a primary key (the candidate key considered to be and designated as the most important)

\- a foreign key.

<comment><USER32> I agree, the definition I provided (not mine) sounds more like an 'index' than a 'key'.

I am not familiar with that usage, I am used to 'key' being used as a logical concept, a constraint, while 'index' is a physical concept, some structure that is there 'just' to make shit go faster.

Anyways, some sources don't even define the word 'key', but use it to mean 'unique key'.

And some other sources (like the one by OP) use it to mean something else (totally not unique), as they recommend that it be 'unique to some degree'

And then some others use the definition I provided above. Is that the one meant by OP? I don't know.

I any case, I guess OP meant something like "indexes should be highly selective'. Which BTW is a performance tuning advice, I am not sure that that belongs in 'SQL Style Guide'.

</comment></comment></comment></comment><comment><USER33> Glad to see I conform to the guide in most places, but one thing I have been doing for nearly all 35 years of my programming career is to prefix my SQL views with `vw` so that I can tell immediately in my queries when I am referencing a view that may be made up of other queries.

<comment><USER34> With this style, you lose the ability to transparently switch out a view for a table.

</comment></comment><comment><USER35> Now we need a formatter/linter too

<comment><USER36> I'd love this tool. If you know a great one, please share it

<comment><USER37> If you're using MS SQL Server, this tool is popular...

[http://www.red-gate.com/products/sql-development/sql-prompt/](http://www.red- gate.com/products/sql-development/sql-prompt/)

... and this tool appears to have similar refactoring capabilities...

[http://www.ubitsoft.com/products/sqlenlight/index.php](http://www.ubitsoft.com/products/sqlenlight/index.php)

</comment></comment></comment><comment><USER38> The part about indentation is a bad practice to follow. Indenting the code that way is not maintainable. I witnessed that multiple times in my career and adopted three simple rules:

        1. Use only one space character between any two words.
        2. Use only one tab (4 spaces) per indentation level.
        3. Use no more than two blank lines to vertically separate parts of the code.

These three rules are simple, easy to remember and I'm applying them to any language I work with.

</comment><comment><USER39> This is great, agree with many of the suggestions.

The worst SQL for my eyes is the stuff that has multiple columns, etc. on the same line. Makes diffing stuff 2x as hard and you can't parse as much information. Though maybe I'm just used to that at this point.

</comment><comment><USER40> Let's just agree that we will all disagree.

Then let's agree just to accept that there is no ideal, but that there is benefit in using the same formatting, and that perhaps we should create a sqlfmt utility like gofmt and all just use that.

<comment><USER41> Ah, but what RDBMS should that sqlfmt utility target? There are large differences.

Here's one for TSQL. I find it very useful when spelunking through customers' almost invariably awful SQL.

[http://poorsql.com/](http://poorsql.com/)

</comment></comment><comment><USER42> Arrgghhh... yet another set of rules with no rationale or justification.

<comment><USER15> Have you read Celko's book? If not I suggest you do. As the guide states at the very top that is where you'll find the detail you're after.

</comment></comment><comment><USER43> I have only done a little bit of work with SQL. Could someone please go into a bit more detail on a couple of these points for me?

> Plurals—use the more natural collective term where possible instead. For > example staff instead of employees or people instead of individuals.

> Where possible avoid simply using id as the primary identifier for the > table.

<comment><USER27> The first one is just poorly stated but is correct in spirit. Use the most inclusive and flexible name allowed by the business logic without being overly generic. Some would say thats the natural term, I guess. The first example of using "employee" as a term invokes murphy's law that the company will hire their first contractor or intern the first week the software ships, resulting in much confusion, wait you've got a column for employees wheres the column for contractors? The second example guarantees that someone in production will confuse the individual serving ice cream cup production table with your HR list of employees if you use the overly generic word "individual". Or maybe those individuals are sales prospects, not employees.

The second one is simply wrong because it burns brain cells when you come back to debug or extend something a year later and nobody memorizes the prikey of table production_quality_results, is it the serial number of the mfgrd object or the timestamp of the QAQC inspection or the serial number of the inspection activity or ... and when you look at column names in table 131 is drivers_license_id a foreign key to a row in the drivers_license table or just a raw store of data, like this is just where you store it in the system? This is especially hilarious if your FK and data source are similar bigint type, like a bigint to connect a FK to a prikey or is your component serial number literally a bigint itself, assuming the prikey is the data itself without dereferencing it will be a hilarious bug, "it seems serial number 10 doesn't exist in our assembly line" "Whoops thats actually row 10 of the production table, serial number whatevs".

<comment><USER15> I am totally lost when it comes to your comments on the second item. It seems you're trying to say that surrogate keys are easier to find or perhaps guess.

The indexes set out against a table can generally be accessed with a query making it very easy to work out what existing index suits your use case best.

</comment></comment></comment><comment><USER44> A guide is better than no guide. I like the part about adding suffix strings to variables. Two things I would changes

* Add commas before the variable * Do not use single letters for aliases. Some versions of hive will throw exceptions. Plus seeing tables a, b, c, d joined together is annoying to read.

</comment><comment><USER45> I really like his indentation. I'm gonna use it. Most of it has been my style for a long time.

<comment><USER23> If you're writing a lot of ad-hoc queries, I prefer to have keywords on their own line and also put commas at the start of the following line vs end of the previous. It lets you comment stuff out easier as you experiment. In a production query the only hard rule should be, "Please be consistent!"

<comment><USER15> Putting the comma before doesn't actually make commenting out columns easier - it just moves the problem to the other end of the list. Just try commenting out the first column in your SQL and you'll see what I mean.

</comment></comment></comment><comment><USER46> [https://www.reddit.com/r/SQL/comments/3efmn0/sql_style_guide...](https://www.reddit.com/r/SQL/comments/3efmn0/sql_style_guide_a_consistent_code_guide_ensuring/)

</comment><comment><USER47> Trouble with this kind of thing is that if you make it general enough to apply to most situations you can't really say anything (too many exceptions) and if you get opinionated then your guide doesn't apply to a wide class of use cases.

Stuff:

1\. Advice like "Use consistent and descriptive identifiers and names" \- is general programming advice, not SQL style advice, and is so bland as to go without saying (would anyone seriously recommend being inconsistent or non- descriptive?)

2\. Preferring standard SQL to vendor-specific SQL just isn't practical for nontrivial use cases.

3\. "Use / _..._ /-style comments where possible" \- why? This makes commenting out large blocks of code really fiddly. Using double-dash comments, even for multiple-line comments, leaves / _..._ / usable for knocking out big blocks of code.

4\. The advice on table naming - if a table contains one row per xyz, then calling the table xyzs and calling its id xyz_id is sound practice, arguably even if this does violence to the natural language in which xyz is a word. This reduces cognitive load on devs and makes the naming more predictable, especially bearing in mind that not everyone speaks the same first language.

5\. No idea why "cars_mechanics" is worse than "services". "services" could mean practically anything.

6\. There's a lot more to be said about table aliasing. Personally I prefer a, b, c... and then in derived tables, different groups of letters such as x, y... or p, q... . Stuff which requires an alias which will never be used (e.g. a derived table which is simply selected from) is aliased by _.

7\. The guide says Hungarian prefixes are to be avoided, but a _num suffix denotes a number? Doesn't seem consistent.

8\. All the advice on portability is unnecessarily opinionated. Portability is a concern that varies from completely unimportant to completely necessary, depending on what you're trying to achieve.

9\. Indentation and layout - there isn't a "one size fits all" rule - it just comes down to judgement and taste. The given examples also look weird:

      SELECT r.last_name
        FROM riders AS r
             INNER JOIN bikes AS b
             ON r.bike_vin_num = b.vin_num
                AND b.engines > 2

(a) Tables "riders" and "bikes" are siblings in this join so why are they indented to different levels? (b) The AND isn't symmetric with respect to its operands.

IMHO this is better:

      SELECT
        r.last_name
      FROM
        riders AS r
      INNER JOIN
        bikes AS b
      ON
        r.bike_vin_num = b.vin_num
        AND
        b.engines > 2

Arguably, "b.engines > 2" should be in a WHERE clause instead of the ON clause, because it doesn't refer to table r. The query result is the same and the query planner probably produces an identical plan (depends on engine, of course), so this is genuinely just a style/semantics point.

10\. "Avoid UNION" \- why??

11\. Avoid vendor-specific data types - this just isn't practical real-world advice. Sometimes you commit to a certain DB because you need to use its specific feature set. That's OK.

12\. "Prefer NUMERIC and DECIMAL to REAL and FLOAT because rounding errors are annoying". This is _completely_ determined by your specific requirements! Essentially this advice is saying "always prefer arbitrary-precision arithmetic". 32-bit and 64-bit floats are _much_ faster and more compact than arbitrary-precision and are accurate enough for a very wide class of use cases. IMO this advice should be turned on its head: "use floating-point unless you know you need higher precision and you understand the performance/storage implications" \- which would be the default approach in most programming scenarios.

13\. "Avoid table partitioning" \- this is a design/performance concern, not a style concern, and it depends entirely on use case.

14\. "Avoid EAV, use a different product" \- not real-world advice. Most devs don't have the luxury of just introducing different products when they run into an awkward scenario, and even if they did, introducing a whole new DB engine carries major overhead. Sometimes you just suck it up and have a small EAV wart in your design.

<comment><USER15> I think a lot of this comes down to what appears to be a simple misunderstanding.

 _Avoid_ \- in this context means that where it does not make sense (for performance, readability, etc reasons) then don't follow the guide. Follow it where possible and be mindful of when you deviate that you're adding to tech debt.

</comment></comment><comment><USER48> > If there is already a correlation with the same name then append a number.

And then applies it for this query:

      SELECT first_name AS fn
        FROM staff AS s1
        JOIN students AS s2
          ON s2.mentor_id = s1.staff_num;

I think that's terrible. s1 and s2 sound to me like they're instances of the _same table_ that you had to JOIN with itself for some reason.

<comment><USER49> Agreed, there is a _lot_ I disagree with from the article, but this is the only one that my mind lashed out at as simply being WRONG. The only time I have seen numbers used on aliases in 10+ years is on self-joins. Even on self- joins I prefer to see something in the alias that identifies why that particular join is part of the query, but the reality is that such a descriptive name would often be so long that you're more likely to see a numeric suffix.

</comment></comment><comment><USER50> Regarding lower-case/hungarian notation etc, the membership table in my database is:

      tblMember
      </comment><comment>---
      MemberID
      MemberUsername
      MemberDateJoined

etc

Is this very non-standard formatting for SQL?

<comment><USER5> Why prefix your tables with tbl? Do you prefix your functions with "fun" and your variables with "var" and your classes with "cls"? It's completely redundant.

<comment><USER32> Some people do it to avoid clashes with reserved words.

Example: in some DBMSs, you cannot name your table 'user' because it is a reserved word.

"user" (double quotes) works, but there may be gotchas as sometimes double quotes suddenly make identifiers case-sensitive... but only if the filesystem is case-sensitive... things like that.

So you can either deal with the gotchas or say fuck it, put a prefix "tbl" and call it a day.

<comment><USER5> I'd much rather just name that table AppUser than prefix every single other table with "tbl". That's just taking one minor annoyance and multiplying it a thousand times.

</comment></comment></comment></comment><comment><USER10> Anyone use these fellas [] ?

<comment><USER37> Yes, though generally only if a field or table name happens to be a SQL keyword.

<comment><USER51> In SQL server? In PostgreSQL you would wrap with double quotes. Which kinda sucks when your language uses double quotes for strings and you have to escape.

<comment><USER37> Yes, in SQL Server.</comment></comment></comment></comment>


10 petaflop supercomputer in the making, will take US back to 1 on top500  - <AUTHOR> http://www.ncsa.illinois.edu/BlueWaters/system.html

<comment><USER2> This is going to sound somewhat shallow, but I hope this new installation gets some decent visual design. Look at some of the classic supercomputers, such as the fantastic Thinking Machines CM-1: <http://www.mission- base.com/tamiko/cm/CM-1_500w.gif>

Now look at the current reigning champ in 2010: [http://www.blogcdn.com/www.engadget.com/media/2010/10/mod-65...](http://www.blogcdn.com/www.engadget.com/media/2010/10/mod-656188tianjin1.jpg)

Sure, the visual design of a supercomputing installation doesn't have any bearing on its actual utility. But having a certain presence commands respect—even if the researchers using it know it's just stagecraft, there's an undeniable attraction to working on something that isn't just a great engineering achievement, but also _looks the part._

<comment><USER3> Huh, maybe it's because I already know what it does, but I actually think that racks of machines are _really_ cool looking.

Stuff like this: [http://www.google.com/images?hl=en&q=Marenostrum&gbv...](http://www.google.com/images?hl=en&q=Marenostrum&gbv=2&um=1&ie=UTF-8&source=univ&ei=jbPkTIXqMYnEsAPu69jVCA&sa=X&oi=image_result_group&ct=title&resnum=3&ved=0CDcQsAQwAg&biw=1066&bih=566)

is just _really_ cool.

<comment><USER2> Well, yes, but that's the MareNostrum!

It may be a bunch of 1U blade servers, but the architecture plays a huge part in building its presence: The location, the contrast between classical ecclesiastical design and stark modernism, the glass, the color choices, the dramatic lighting...

Compare that with a gray room with a drop ceiling and fluorescent lights. The hardware may be the same, but the effect is not in the same ballpark!

</comment></comment></comment><comment><USER4> I went to a presentation at my school about this computer. There are two main goals to the project. One is to be a usable supercomputer meaning that it will be much more userfriendly to actually use to write software for. Another is the goal of actually getting 1 petaflop of sustained performance. Whats interesting is they were able to get the building under budget and ahead of schedule due to the housing crisis. They also want to make the computer much more energy efficient and they aim to be more efficient than modern datacenters.

<comment><AUTHOR> yes, they seem to be using the Power 7 architecture by IBM , which is quite energy efficient compared to most other architectures, and also they are planning to use UPC(Unified Parallel C) or similar languages for applications running on the system, that a good step towards better usability. But that does not matter as a super computer is always(mostly) used by a small group of highly qualified scientists.

</comment></comment><comment><USER5> You know, they start waking up at around 1 Petaflop.

<comment><AUTHOR> I quite did not understand what "waking" up means, but it seems that Blue waters will indeed have a sustained performance of more than a petaflop with adapted applications !

<comment><USER6> skynet'ing

<comment><USER7> Skynetting

</comment></comment></comment></comment><comment><USER8> For anyone wondering about the "back to 1" part: the Chinese very recently (this week?) took the spot with their 2.5 petaflop Tianhe-1A. It's made from Xeons, Fermis, and Feiteng-100s. Right now they're having trouble actually utilizing the machine; very little of their software takes advantage of more than a modest number of cores.

<comment><AUTHOR> mostly the problems with utilizing the system completely are the same ones a common programmer faces when trying to use GPUs for general purpose programming, the problem of transferring the data to be handled from the main memory to the GPU's memory. Though Tianhe-1A has a very high peak performance, the sustained performance seems to be comparatively low !

</comment></comment><comment><USER9> What are some real world applications for this bad boy? Is this a for-profit endeavor where real companies can rent this computer out to do stuff with it?

<comment><USER10> These things are most useful for research via numerical simulation. The uses that would come closest to aiding for-profit endeavors would probably be various simulations of systems still in the design-phase. For example, simulation of a car crash, simulation of aerodynamics of an automobile or airplane, simulation of the fluid dynamics of a jet engine, simulation of hydrodynamics of a new super-tanker design, etc.

Such simulations are fairly common today, although generally super-computers of this magnitude aren't needed for them.

</comment></comment><comment><USER11> Talking about HPCs anyone at SC10? If you are I'd like to meet up with other HNers at the conference. I'm stuck in a booth until 3pm (3445 ciena demoing some brain imaging app over high bandwidth links) but it be cool to have a hn meetup afterwards in some bar. Only issue will probably be choosing a bar from NO large selection.

</comment><comment><USER12> It is still kind of mindblowing that the entire Amazon cloud shows up as 231st of the top 500 computing clusters (top500.org). Are all these other systems just sitting around crunching proteins? They should start hooking these bad boys up as EC2 mega-instances.

<comment><USER13> That list claimed that all of EC2 had only 7000 cores, which seems absolutely ridiculous to me. I'm more inclined to believe that the list is full of shit than to think that EC2 has so much less computing power than these other supercomputers.

<comment><USER14> Amazon ran Linpack on 7000 cores and submitted it to Top500, so that's what appears on the list. Maybe they could have done a larger run, but keep in mind that regular EC2 machines are unsuitable for HPC; I can believe that they only have 7000 cores in the compute cluster machines.

<comment><AUTHOR> that is still unbelievable ... they sure have more cores than that just in EC2, and anyway looks like the new GPU instance offerings were not included in the benchmarking, that would have shot the rank up by an order of magnitude !

<comment><USER15> The Top500 benchmark for EC2 was run on some of our Cluster Compute instances. It was definitely not run on the entirety of EC2 (what would we do, kick everyone else off?).

<comment><USER16> Any chance you guys ran it on the new GPU cluster before opening it to the public? Would have been cool to get the benchmark on that entire thing b/f customers started running stuff on it.

<comment><USER15> Not that I am aware of, but the AWS team is big (and getting bigger) and lots of stuff happens that I know nothing about.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Does anyone know why there's a ten-fold difference between peak and sustained power? I would have thought it'd be more like 50%, but I don't work with HPCs.

<comment><AUTHOR> The performance is measured with LinPack which mostly does FP operations and is optimized to run on the architecture, when normal programs are run, it is tough to run them at full utilization, this is because, a lot of time might be spent in data transfer or I/O apart from the computation ... there would be various other factors !

</comment></comment><comment><USER18> The buildings on our campus keep their lights off for the majority of the day, probably to make room on the grid for this machine's energy usage.

</comment><comment><USER19> i was really excited when they started construction on the building that houses those machines. it's finished now, but i was able to attend the less than glamorous pre-open house* =]

* <http://bit.ly/dkJiaZ>, <http://bit.ly/9mEo2e>

<comment><USER20> It's much cooler now, but access is more restricted. I think you can still get tours if you arrange ahead of time <http://www.ncsa.illinois.edu/AboutUs/tour.html> . If you do, if you look really hard in the far corner of the room you might spy the little Top500 machine I worked on this fall.

</comment></comment><comment><USER21> The networking hardware can read and write directly to L3 cache. That's just _cool._

</comment><comment><USER22>
      The key component is the hub/switch chip.
      The four POWER7 chips in a compute node are
      connected to a hub/switch chip, which serves
      as an interconnect gateway as well as a
      switch that routes traffic between other hub
      chips. The system therefore requires no
      external network switches or routers,
      providing considerable savings in switching
      components, cabling, and power.

Sounds a bit like the design SiCortex had for their machines (before cashflow interruption killed them).

<comment><USER20> Most supercomputers with multi-socket nodes have had something like this for similar reasons. The earliest reference I can find is here [http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefi...](http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA166610) , but more modern examples of the idea are the Cray SeaStar [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.150...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.150.7293&rep=rep1&type=pdf) or even SeaMicro's I/O virtualization ASIC if you squint the right way <http://www.seamicro.com/?q=node/38> .

SiCortex had some neat ideas, it was a shame to see them go.

<comment><USER22> Thanks, I learned some new things.

</comment></comment></comment><comment><USER7> Anyone want to guesstimate the date of the first exaflop computer?

<comment><USER20> If you believe that the trend-line that has held surprisingly steady for the last 17 years ( <http://top500.org/lists/2010/11/performance_development> ) will keep going, than by my crude eyeballing it looks like about 2019. Granted, there are a lot of good reasons to think it won't quite hold.</comment></comment>


Google Chromium, sans integration with Google - <AUTHOR> https://github.com/Eloston/ungoogled-chromium <comment><USER2> At that point why not use Firefox and help fight Chrome's engine dominance?

<comment><USER3> A lot of things don't work on Firefox, or work worse.

If you are against Google pushing their "evil" stuff on people -- not just you, but all people -- well, Google thinks they can get away with that because people consider their browser better (or those people are just more comfortable with Chrome). Stuff like this, i.e. more options for people, is actually very helpful in reigning Google in a bit. Other Chromium based browsers such as Edge or Brave help as well.

BTW, my personal pet peeve with Firefox is lack of MIDI support, but there are lots of other things. I like that I can search Google by voice in Chrome, and my 6 year old loves that especially. (I don't know if ungoogled-chromium can do that though) I like the way you can grab tabs and drag them around and you know where they will go with Chrome before you drop them. (I have several monitors so this is a many-times-a-day thing for me and it feels awful in Firefox, comparatively). And I hate the ads and recommended sites on the "new tab" page.

<comment><USER4> This is precisely why I use non-Chromium browsers as my daily driver. It's their constant push for non-standard APIs and aggression towards other browsers that doesn't implement their favored APIs that's cementing their dominance. Not having support for Google features shouldn't be a reason not to support other browser engines.

Some examples:

[https://news.ycombinator.com/item?id=17606027](https://news.ycombinator.com/item?id=17606027)

[https://twitter.com/Rich_Harris/status/1220412711768666114](https://twitter.com/Rich_Harris/status/1220412711768666114)

Some additional rants:

> I like that I can search Google by voice in Chrome,

Chrome is a blessing for enthusiastic Google users, but not all people feel the same way.

> MIDI support

More access to HW is the last thing I want from the web at this moment. I'd rather that browser vendors focus on making the privacy footprint smaller, not bigger.

> And I hate the ads and recommended sites

You're going to see more of those on Chrome when uBo ceases to stop working along with all other manifest V2 extensions.

<comment><USER3> >> I like that I can search Google by voice in Chrome,

>Chrome is a blessing for enthusiastic Google users, but not all people feel the same way.

My six year old isn't so much an enthusiastic Google user, but she sure does like voice search, since it is really the only option.

>> MIDI support

>More access to HW is the last thing I want from the web at this moment. I'd rather that browser vendors focus on making the privacy footprint smaller, not bigger.

I'm not really seeing Chrome suffering from privacy problems coming from MIDI devices.

But, you know, if you aren't into making music or learning keyboard or what have you, I guess you wouldn't care about MIDI. It's kind of a big deal to me (and again, 6 year old), so I'd miss it badly. Likewise, if you aren't into videochatting you'd probably be fine if your browser doesn't talk to your webcam or microphone. Etc. Ok.

BTW, if the browser doesn't support MIDI, and you want to use MIDI, you need to install native apps. Those are often a bigger threat, need to be made for each platform, etc.

<comment><USER4> > I'm not really seeing Chrome suffering from privacy problems coming from > MIDI devices.

Here's a CCS paper detailing why it's a bad idea for browsers to expose HW details without careful consideration:

[https://www.cs.princeton.edu/~arvindn/publications/OpenWPM_1...](https://www.cs.princeton.edu/~arvindn/publications/OpenWPM_1_million_site_tracking_measurement.pdf)

> if you aren't into making music or learning keyboard or what have you, I > guess you wouldn't care about MIDI

Considering the aforementioned problems, why would it make sense for browsers to prioritize MIDI above all else? And I highly doubt your six year old would refuse to use native apps, given the chance.

> (native apps) are often a bigger threat

I choose my native apps with care. For many apps, moving to the web doesn't mean that I would have to stop caring about trust. It just means that I would have to start being more careful about which sites I visit if browsers keep on exposing random HW details.

> need to be made for each platform

If you're only supporting Chrome, then you've stopped caring about portability. You're making it the user's fault if they don't use Chrome.

<comment><USER3> "why would it make sense for browsers to prioritize MIDI above all else?"

Who said above all else? That's pretty black and white. You could make the same argument if Firefox didn't support, say, microphone or camera. If you don't happen to use them (say, you don't use video chat as many didn't prior to 2020), you could ask why they are so important.

It's just one thing that Chromium does (and has done for year), that Firefox doesn't.

>And I highly doubt your six year old would refuse to use native apps, given the chance.

Which native app? The one she uses only works in a browser, and wouldn't work natively because it uses other things a native app can't use (such as YouTube interaction/synchronization). Also the graphics are far superior to anything I've seen not done in a browser, because it taps into other things that would be immensely difficult if the browser didn't make them available at a pretty high level.

[https://youtu.be/64PkqQuE9h8](https://youtu.be/64PkqQuE9h8) [https://www.youtube.com/watch?v=NV6rdmdZnkA](https://www.youtube.com/watch?v=NV6rdmdZnkA)

And that app works on her Chromebook, as well as on my Windows and Mac machines.

I get that you like Firefox, but I don't see "you can just do that with a native app" as a great advertisement for it.

</comment></comment></comment></comment></comment></comment><comment><USER5> I'm sorry but I'm not going to install a browser built by random people.

> NOTE: These binaries are provided by anyone who are willing to build and > submit them. Because these binaries are not necessarily reproducible, > authenticity cannot be guaranteed; In other words, there is always a non- > zero probability that these binaries may have been tampered with.

<comment><USER6> There are packages available for popular GNU/Linux distributions based on the openSUSE build service, which are not uploaded by random people.

If your distro is unsupported, you can install Nix or Guix and use that to install ungoogled-chromium.

<comment><USER7> Are the distributions reviewing the patchset against Google Chromium upstream and affirming that, to the best of their knowledge, no additional threats will be delivered to those who choose to use this?

The risk isn't in who _compiles_ it. The risk is in the patches themselves coming from an untrusted third party, and being presented as a complete fork with significant functionality changes in support of the author's beliefs. If it was "here's a minimal patchset that's rebased against Chromium upstream, here's instructions to checkout Chromium and rebase our patchset onto it" then that would be possible to trust. This isn't that.

<comment><USER6> I'm not sure I understand the question. ungoogled-chromium _is_ "a minimal patchset that's rebased against Chromium upstream, here's instructions to checkout Chromium and rebase our patchset onto it".

[https://github.com/Eloston/ungoogled- chromium/tree/master/pa...](https://github.com/Eloston/ungoogled- chromium/tree/master/patches)

Apart from the patches, UC does two more things: substitute all "google.com" (and some other) domains with nonsense like "9oo91e.qjz9zk" in order to catch regressions; and prunes all binary files that are distributed with the original Chromium source.

The repository comes with a script that can do all three things. It is not a fork of Chromium, if that is what you were thinking.

I can't speak for other distributions, but for GNU Guix I have reviewed the patches and read the diffs for every new version. I assume most other packagers do the same.

</comment></comment></comment></comment><comment><USER8> ungoogled-chromium has absolutely zero telemetry. It's the gold standard for browsers and a rare breath of fresh air in the polluted world of modern software.

Firefox, in contrast, is nowhere close. It includes trackers, "pings", "experiments", ads, sponsored search engines, bundled extensions, and phone- homes. Despire Mozilla's open-source and privacy rhetoric, its level of bundled spyware is not very different from any other commercial software product.

<comment><USER9> >its level of bundled spyware is not very different from any other commercial software product.

Maybe that is more a sign of how necessary it is, rather than indication that Mozilla is somehow an evil company.

"Phoning home" let's them know which features are being used and need to be maintained, and where the bugs are occurring. Experiments are how Firefox tests improvements in a controlled way. Sponsored search engines are how Firefox can exist at all.

<comment><USER10> > "Phoning home" let's them know which features are being used and need to be > maintained

This is part of the reason modern software is often crap. It gets sanded down to only the most used features, screwing over anyone with a slightly niche use case in the process.

<comment><USER11> I think Firefox would be more "crap"py if every feature at least one of its users wanted was included. The binary size and startup time would suffer, new feature development would slow to a crawl as every change becomes more difficult, and the interface would be clogged with things I don't want.

</comment></comment></comment></comment><comment><USER12> Would be great to understand what communication with Google servers can be turned off via setting changes rather than code changes, and what cannot.

<comment><USER13> Even basic things like auto-suggestions in the URL bar can't be turned off any more. A while ago there used to be an option for it but it was removed. So when you enter an URL it's automatically sent to Google as you type.

<comment><USER14> The setting is 'Autocomplete searches and URLs', just type it in the settings search box. It's still there.

<comment><USER13> Indeed it's still present. Thanks for pointing it out!

</comment></comment></comment></comment><comment><USER15> I am a regular user of both chrome and ungoogled chromium browser. here are my insights: even though both are fork of chromium, UC consume much less ram as compared to chrome. a youtube page will take ~450mb in chrome but same page will take ~280mb (tested personally). You can install all chrome extensions in UC, there's also a seperate extension for updating these extensions. you can't "sync" data in UC (bookmarks, passwords, cards etc). there's no straight forward way to update UC.

<comment><USER16> Wow. Have others experienced this too?

Jerrygoyal, any other pros or cons so far?

</comment></comment><comment><USER17> Also see: [https://iridiumbrowser.de/about](https://iridiumbrowser.de/about) [https://github.com/iridium-browser](https://github.com/iridium-browser)

<comment><USER18> ^^^ This. Fantastic stuff and I love it so far!

</comment></comment><comment><USER19> What is the difference between Chrome and Chromium exactly if the latter needs to be ungoogled?

<comment><USER20> Chrome includes proprietary (licensed) binary blobs such as certain DRM features similar to widevine.

<comment><USER21> I think OP's question was why do we need an "ungoogled chromium" in the first place, shouldn't stock Chromium already be ungoogled? And if it's not, in practice how is it then different from Chrome?

</comment></comment></comment><comment><USER22> Non-technical Chrome users who cannot "un-Google" can at least set shortcuts to clear cookies, history, etc.

Go to chrome://settings/searchEngines

Click "Add" and instead of typing a search engine URL, enter

       chrome://settings/clearBrowserData#c

For "Keyword" one can enter a single character, e.g., "c".

Select options, e.g., Advanced tab, Time range: All time, check all boxes. (The boxes will remain checked on the next invocation.)

Now, whenever the user wants to clear the browser data, she can just type "c" in the Address Bar.

No need to keep typing "chrome://settings" or keeping a tab open for settings.

User-agent can be changed through Developer Tools, without the need for extensions, however other headers are not accessible. Technical users who avoid using extensions can use a localhost proxy to delete headers, including Cookie where it is unnecessary.

Despite all the user fingerprinting that is done using HTTP headers such as User-Agent, relatively few sites actually require User-Agent and other headers. For almost all sites, the only requirement to successfully retrieve the page is the Host and, often enough, Connection headers.

Specific resource requests can also be blocked in Developer Tools without installing extensions as a "poor man's ad blocker". Using Developer Tools, dummy Javascript resources can be loaded from local sources to remove undesirable page characteristics.

However neither ad-blockers nor stripping headers prevents all the fingerprinting. If one is not happy with browser-based tracking, then using a "modern browser" with so many advanced features to retrieve a page of text is a trade-off, and, arguably, overkill.

</comment><comment><USER23> what is the difference to Chromium for example in Debian?

</comment><comment><USER24> Does this, or any other distribution of chromium, have an auto-update mechanism similar to chrome's? I dislike having to manually install updates.

<comment><USER25> [https://chromium.woolyss.com/#updaters](https://chromium.woolyss.com/#updaters)

The portable versions on that site are just preconfigured chromium updaters (called chrlauncher)

[https://chromium.woolyss.com/f/chrlauncher-win64-stable- ungo...](https://chromium.woolyss.com/f/chrlauncher-win64-stable- ungoogled.zip)

</comment></comment><comment><USER26> Excuse my ignorance, but apart from defaulting to Google search engine, what are the negatives and hidden google effects of a vanilla chrome install?

<comment><USER27> Chrome has metric gathering, experimentation, account management, bookmark and data syncing and a bunch of other calls to Google's services whether you're using Google Search or not.

Some people would prefer their browser is not leaking so much information to Google, but perhaps appreciate the quality of the underlying Chromium application.

<comment><USER28> Indeed. Mozilla needs to fork it and be done dumping money and manhours into Gecko-based insecurity.

</comment></comment></comment><comment><USER29> Available in Homebrew Cask, if Mac people want to try it out.

I have it installed almost exclusively to use the UniFi web UI, which is buggy as hell on Safari.

<comment><USER30> Not very secure, since anyone can upload the binaries there.

[https://github.com/ungoogled-software/ungoogled-chromium- bin...](https://github.com/ungoogled-software/ungoogled-chromium-binaries)

> These binaries are provided by anyone who are willing to build and submit > them. Because these binaries are not necessarily reproducible, authenticity > cannot be guaranteed.

</comment></comment><comment><AUTHOR> Safari is my day to day browser and I have Pi-Hole installed. Less trackers less bandwidth consumption; I am happy.

<comment><USER31> Pi-Hole only blocks entire hosts - which is great for devices (/apps) on the network that cannot install adblockers. But for a webbrowser you'll need an extension to block many additional trackers/scripts.

</comment></comment><comment><USER32> Is there any similar service for Gmail, integration only with mail servers? Similar client-side experience, No ads, no data collection. etc

It could be first step for de-googlifying

<comment><USER33> I'm curious because I have never heard from someone preferring the Gmail client-side experience. Can you elaborate?

While certainly usable, isn't the client-side experience one of the negative points of Gmail? (generic icons all over the place, resizing/reloading behavior erratic, load time, settings discovery hard, …)

<comment><USER34> It has very nice Vim-like keyboard shortcuts, a good UI for setting up advanced filtering rules, it loads instantly (on my computer, at least; this has gotten much better recently), and text editing features like Smart Compose and the Googlified spellchecker beat everything else.

I can see why you might not like it if you're used to Outlook or Thunderbird, but it meets my needs perfectly. It also integrates with Google Keep, Tasks, and Calendar, which is nice.

(Some people seem to seriously underestimate how good Smart Compose is---it's learned all of my favorite combinations of words and I can basically write entire emails and documents by typing a few letters and then mashing the tab key to accept all of the autocompletions)

</comment></comment></comment><comment><USER7> This title is misleading. There are significantly more patches here than just "remove integration with Google".

</comment><comment><USER35> I use ungoogled-chromium for sites that don't behave well on Firefox (due to needing third-party cookies and so on). I find the extension[0] allowing for the installation and updating of Google Chrome App Store extensions to be immensely valuable.

[0] [https://github.com/NeverDecaf/chromium-web- store](https://github.com/NeverDecaf/chromium-web-store)

<comment><USER36> Thank you for this link! Not being able to easily install extensions into ungoogled-chromium was the main reason I've not switched to it as my main browser.

<comment><USER37> > Not being able to easily install extensions into ungoogled-chromium

You can.

1\. Download the .crx file(s)

2\. Rename to .zip, unpack

3\. Visit "chrome://extensions/" page

4\. Select Developer Mode, then Load unpacked, select folder of previous extracted zip file

5\. There you go.

<comment><USER38> Easy:

0\. Visit store, find extension, hit install

Not as easy:

Do the same, but now add 5 more steps.

</comment></comment></comment></comment><comment><USER39> I use this as an alternate browser to my usual (safari) and for dev. It's brilliant, highly recommended.

</comment><comment><USER40> FWIW, Microsoft Edge on macOS is a better Chrome than Google Chrome. It's based on Chromium and has shown superior performance on my machine. Plus, it has a nicer settings menu than Google Chrome.

*no affiliation with MS.

<comment><USER41> Is there an equivalent project like in OP for the Edge build of Chromium? I really want the Vertical Tabs Edge is supposed to have soon. Or maybe it already has them?

I haven't found a great extension for Chrome that works well with proper window and cursor focus when opening new tabs and not interfering with system keyboard shortcuts when using it cross-platform. I use Sidewise for now, which is actually okay but has some rough edges.

I'm hoping the solution in Edge might actually be a Edge extension instead of Edge functionality, so that I can maybe even adapt to run under Chrome or Firefox.

<comment><USER42> "Edgium" is not open source

<comment><USER41> I thought I read that it's planned to be?

[https://github.com/MicrosoftEdge/MSEdge](https://github.com/MicrosoftEdge/MSEdge)</comment></comment></comment></comment>


How We Built an iOS App, an Android App and a Node.js API in 20 Hours - <AUTHOR> http://blog.semantics3.com/how-we-built-an-ios-app-an-android-app-and-a-node-js-api-in-20-hours/ <comment><USER2> I congratulate them on acheiving your goal of writing an app in such a short time, but I whole-heartedly condemn this app's principle idea. Far from being a force for good it feeds into the incredible paranoia that seems to be prevail in the United States, that everyone is out to get them, and that there are such things as "good areas" and "bad areas".

There are huge problems in justifying this kind of classification, not least because ordinary law abiding citizens who are in a majority also live and work and play in so-called "bad areas" and never suffer crime. What becomes of their house values if such an irresponsible app were to become popular? Their (very) hard earned cash paid as mortgage payments gone to waste.

This app is pernicious in every sense. Even wealthy well-to-do areas can become ghetto-ized: If you tally up the number of burglaries or attempted burglaries in these areas you might find the stats show a different image.

We are not living in some post-apolcolyptic movie world, this is real life and has hard working real people in it, with families and children, who have no choice but to live where they can afford to, and I don't see how this app could ever be considered as "making the world a better place". For who exactly?

This kind of app threatens to push people who live in the targeted areas further down the food chain, and I just wish the developers would have been a bit more socially responsible, in their thought processes.

Rant over. Hopefully a lesson learnt.

<comment><AUTHOR> The app was born out of personal experience. Within a month of moving to Philadelphia, I was assaulted on two occasions, including once on my very first day there. I put that down to my lack of knowledge of the area; I later discovered that a more knowledgable person wouldn't have accidentally wandered off at that time of evening to that particular area. Turns out, some of my neighbors had had similar experiences in the past in the very same area. I was later warned by local authorities that the area was known for the phenomenon of "gentrification".

Personally, I was scared out of my wits after those two incidents and landed up staying home many evenings for fear of a repeat incident. I think such an app could've really helped the general quality of my life in terms of reducing my apprehension.

I do see your point. To be honest, I didn't give the macroscopic windfalls excessive consideration. I had focused rather on the gains to individuals who stand to face the same situations that I did.

The app has not been released publicly so I think I'll do read a bit about crime patterns and their correlation to demography before taking any further step. Thanks for brining this to attention.

<comment><USER3> Having been raised in the Philly area I've heard this story from non-natives a number of times, so its pretty common.

That said I think the flaw in this from a positioning perspective is it shouldn't be an alarm that says "Danger, get out now!!!" like you're in a biohazard zone, its should be positioned more like a "Street Sense" radar.

Basically you learned urban street smarts in the hardest way possible. Make this more about softening the risks of navigating unfamiliar urban areas by giving folks the same level of street smarts as a native, and less about a shock and fear-based motivator and you'll be on the right track.

I would also consider focusing on safety by highlighting safer routes pointing out things like density of businesses and street lighting, police stations etc.

<comment><USER2> Totally agree. This is a much better approach.

</comment></comment></comment></comment><comment><USER4> The feat of building that kind of app is impressive. I sure as heck can't do it, yet. I do have a few comments, though.

Refine your data classification. On one of your screenshots, you are listing "Arrests" as a type of crime. That's confusing. Also, consider filtering for violent crime rather than crime in general. That would be more in line with the stated purpose of your app.

Realign the usage from a real-time application to a planning application. You don't want your users to be fiddling with a smartphone in a bad neighborhood. That really increases the odds of getting mugged and defeating the purpose of the app.

I agree with some of the other posters that you should tone down the alarmist tone of the app. If nothing else, it's more professional.

Congratulations on your experiment.

</comment><comment><USER5> What's the time function on your graph? Are you only showing the last X weeks or all time? Things like police patrols could affect the frequency of crime over time, and that may change your predictions and confidence intervals.

EDIT: Depending on your data freshness, you may want to do something like push notifications if a crime happened in your area in the past 4 hours. That way if someone walks through a "good area" but there's recent crime they should be more vigilant.

<comment><USER6> We managed to gather data for about a month when building this app. Some of them were as recent as a few hours and some a few days.

We implemented a weighted average algorithm to calculate the risk levels and how confident we were of the data. For the risk levels I took into account 1) How recent the data was 2) What time of the day it occurred relative to the time of query (for eg: the crime occurred at 4pm on another day and its 5pm now, it will be given a higher weightage compared to something that happened at say, 11am.) 3) The severity of the crime itself (murders >> theft) 4) Number of occurrences of crimes in the area

The assignment of weights wasn't thoroughly scientific though. It needs some tweaking.

And thanks for the suggestion on push notifications :)

</comment></comment><comment><USER7> I had similar idea whileback so this app is interesting.

What I would change:

1\. Remove crime details. They are unnecessary. 2\. Replace pins with transparent canvas overlay showing level of danger or safety in shades of red and green. 3\. Let user set the desired 'shade of danger'. A simple horizontal or vertical color selector showing shades of red will do. App should buzz every N minutes when users is in area with deeper shade of red unless they press the override button.

That's all.

</comment><comment><USER8> Tip of the hat: you beat me to the punch (though I really wondered about the proper lawyerese for deploying a service like this)...

Of course, the corresponding app, badguy, which alerts would-be criminals to the likely patrol routes of cops, is likely to follow shortly thereafter from the black hats.

</comment><comment><USER9> Great, give clueless "project managers" another reason to think anything of value can really be accomplished in a day or two.

</comment><comment><USER10> Is this available on the App Store yet? Or is there an estimated date?

<comment><USER6> The designer of the iOS app is sadly a perfectionist and is refusing to put it up on the store until its pixel perfect!!(by his own standards)

In all seriousness, we have a bit of work validating the ranking algorithm, pulling in more sources and general UI cleanup stuff. We are really keen on putting it on the store though. Maybe a couple of weeks to a month?

<comment><USER11> I travel a fair amount for business and have contacts that also travel quite a bit. Let me know if you'd like some beta testers once you get beyond the California area.</comment></comment></comment>


Ask HN: We think micro-stock is broken, please rate our 3 ideas... - <AUTHOR>

http://quillu.com/stock  - easy discovery using social graph and image analysis to rank algorithmically.
http://quillu.com/marketplace - 99designs for microstock
http://quillu.com/news - sell your Instagram pics
http://quillu.com redirects randomly to one of the three links above, is this a good idea for "a/b/c testing"?
Thanks very much, all feedback appreciated, please be as brutal as you like :) Thanks Rik <comment><AUTHOR> With clickable links...

<http://quillu.com/stock> <http://quillu.com/marketplace> <http://quillu.com/news></comment>


Ask HN: Why developers at startups use 3 monitors? - <AUTHOR>

Hello,
There is something that confuses me, and I can't find an answer for it.
Why the developers at startups, use 3 or 2 monitors? What is the point from using many monitors?
Why a startup would spend 3x on monitors, while they can save that money? Is there a ROI from using 3 monitors per developer?
I am really curious to know...
EDIT: It would be great if you tell me how do I install 2 monitors per machine... Does the hole screen appear devided into 2 screens? Or the 2 monitors dislay the same thing? <comment><USER3> I use synergy <http://synergy2.sourceforge.net/> for sharing one mouse and keyboard across two monitors and OSes. I use Linux on the right and Mac on the left. Would never go back. Like someone said read documentation on one, code on another.

<comment><USER4> Cool setup, thanks for the info. I know you can do that with vnc somehow as well.

</comment></comment><comment><USER5> 1) Why? As others have said, enhanced productivity. I usually keep API docs, examples, and a terminal with autotest on my secondary. Also, in my case, my machine is a laptop (I use that screen as my secondary) and knowing I have a 24" screen waiting for me is incentive to come into the office instead of telecommuting or siting in a coffee shop :).

2a) How? Been awhile since I've had to deal with installing new hardware, but as far as I remember, you can install new video cards and it'll register fine (or get a card that has two DVI ports). As for OS support, I think Windows does it (although I don't know if you have to have a certain edition), Mac supports it on most models out of the box (in the past you had to do a software hack on iMacs, don't know if that's still the case—other than that completely painless), and I know it's possible with Debian (probably most other Linuxes as well).

2b) What's it look like? Most current hardware will support spanning across multiple screens (OS support: see caveats above). In the past, some video adapters didn't have the horsepower to do anything other than mirroring (where the screens show the same thing), but all of the ones I've dealt with recently can (again, YMMV). Mirroring is still useful when hooking up to a projector, but beyond that, spanning is the way to go.

</comment><comment><USER6> Definitely try it. I will never be able to go back to one monitor.

Here are some statistics: <http://www.codinghorror.com/blog/archives/000012.html>

Here are instructions: [http://lifehacker.com/software/dual-monitor/how-to- set-up-du...](http://lifehacker.com/software/dual-monitor/how-to-set-up-dual- monitors-218991.php)

<comment><AUTHOR> Thank you so much for the link to the video.

It's very easy to setup and really amazing... I just tested it out on my laptop with my computer's monitor(I plugged my computer's monitor in the laptop instead)... and it's really cool.

</comment></comment><comment><USER7> I use two 15 inch laptops (Vista and Kubuntu) and one 22 inch screen in the middle.

Depending on the type of work I do (Windows development or _nix) I physically switch main screen between two laptops. For example, when I do Outlook add-in dev, my screens might look like this:

Vista laptop: Outlook where I test. Vista main screen: Studio. Kubuntu laptop: docs.

or

Vista laptop: docs. Vista main screen: Studio. Kubuntu laptop: VMWare with different OSes. This way I don't overload Vista machine which is already running studio.

For _nix dev, I like this setup:

Vista laptop: chats, music, videos, whatever. Kubuntu main screen: Emacs fullscreen. Kubuntu laptop: docs.

As is probably obvious, my setup looks like this:

Vista - Main Screen - <USER2>

I also use synergy to handle supporting laptop (Kubuntu or Vista) from main machine.

I have to say, it really helps. There is a lot of ease on my brain which helps me relieve some of the anxiety.

</comment><comment><USER8> I can think of a couple of reasons

\- Sheer geekery (though that doesnt work with your comment about cost, I admit).

\- Multiple PC's (example: at my desk I have a dual screen setup for working on, a 3rd screen connected to a different PC for email, IM [chatterous via Gtalk ftw] & personal stuff and a smaller screen off to one side which is a build machine / test client. Using a KVM to share Kb/M _but_ still being able to see all screens is a great advantage :))

</comment><comment><USER9> It's a documented trend that more monitors enhances developer efficiency. There is a point of diminishing returns as well, so two or three is the sweet spot. Some can see improvement with four, but not many.

I apologize, I can't find the source of the study for efficiency.

That being said, some prefer a single screen. I love dual screen as I'm a big proponent of code on one screen and website on the other so I can easily see the results of my code.

</comment><comment><USER10> I have a main setup comprised of 3 displays with one desktop and a laptop, it's quite nice to work like this, especially when I run macosx and then have windows in vmware fusion on another display.

The only thing I'm torn on is rotation. I've flipped a display 90 degrees around and I can't decide if I like it or not. It's decidedly odd but quite useful in some ways (i.e. for me, reading long things without using scroll so often).

</comment><comment><USER4> Left monitor has mozilla with tabs and behind that a terminal with database command line.

Right monitor has outlook and my main terminal window plus itunes in the background (or whatever I'm listening to).

It is incredibly nice to compare 2 files across the monitors. Also it is nice to be able to have ie6 or ie7 in one windows with mozilla or safari in another to make sure everything lines up correctly.

</comment><comment><USER11> Imagine you're trying to write a letter on a piece of paper but the desk you're writing on is only 3cm². Were it bigger, it would be so much easier.

</comment><comment><USER12> Testing sites for browser compatibility and rendering issues, most likely; though having 1+ screens probably isn't necessary. I would think it would be much easier, and more cost-effective to go with a KVM switch than a bunch of different monitors. Perhaps could be useful for testing site renderings on different monitor resolutions.

</comment><comment><USER13> Once you've had double-headed there's no going back. Try it!

</comment><comment><USER14> 2 monitors is cheaper than 1 really big monitor. more screen space makes multitasking easier, improving productivity.

</comment><comment><USER15> maybe it's the 'secret weapon' for those startups

is there any data of #monitors used during early product development on various startups?

<comment><USER6> All of the studies out there are pretty rudimentary, so, I would doubt that there are detailed statistics like that.</comment></comment>


Tunable Delete Aware LSM Engine - <AUTHOR> https://disc-projects.bu.edu/lethe/ <comment><USER2> It is not clear expiration time per layer is much better than the commonly used strategy of compacting to a single layer periodically.

For KiWi, storing deletes separately could be interesting but I'm not sure about its exact disk layout and how the resorting works.

<comment><USER3> > For KiWi, storing deletes separately could be interesting

The deletes in different list is super useful in row-major mode if the data bandwidth is an issue and the delete lists can entirely remove the row from the IO.

Apache Hive switched to splitting up the deletes and insert files a while back to get some row-read savings when parallelizing reads - this is pretty much standard tombstoning (but with an immutable fs), but the LSM style merge sucks when you have a scan project/SELECT + schema evolution across different files.

The delete records always have a fixed schema and a single insert sequence is compacted/inserted in the same schema, which prevents the need to switch schema between rows when being read.

Even if the schema rarely changes, but just assuming it can happen and checking for it is slow across row versions of the same row.

</comment></comment><comment><USER4> This is pretty impressive. I didn't expect we'd get another innovation in database architectures for a while.

Do you think SQLite 4 will adopt this?

<comment><USER5> Work on SQLite 4 has concluded: [https://news.ycombinator.com/item?id=15648280](https://news.ycombinator.com/item?id=15648280)</comment></comment>


Ask HN: Should we have a "Who is hiring?" for non-profit volunteer positions? - <AUTHOR>

We are a non-profit (http://www.secfirst.org) currently looking for a volunteer copywriter to help us with some content and PR stuff for the launch of our app, Umbrella - which helps journalists/aid workers/activists manage their security.<p>It only requires a few hours of volunteer time so doesn't really fit into the current "Who is hiring?" - which is full, part-time or internships. Thus does it make sense to have a "Who is looking for volunteers?" <comment><USER2> And maybe internships...

<comment><AUTHOR> I think the current "Who is hiring?" also includes internships? (But I can see a valid reason to switch it to a volunteer thread also)</comment></comment>


Is the semantic web just hype? - <AUTHOR>

Do you think the semantic web is just hype, or is it noteworthy?<p>http://www.webepags.com <comment><USER2> Yes. See 21:00 <http://www.youtube.com/watch?v=LNjJTgXujno>

Money quote: "Semantic web: The future of the web and always will be."

<comment><USER3> Hilarious. The guy asking that question is a very close friend of mine and I've never stopped giving him crap about it.

</comment></comment><comment><USER4> It depends on what you do with it. ;-)</comment>