Timescale, an open-source time-series SQL database for PostgreSQL - <AUTHOR> http://www.timescale.com/ <comment><USER2> Could you contrast this with the approaches mentioned in the series of blog posts starting here: [https://grisha.org/blog/2015/09/23/storing-time-series- in-po...](https://grisha.org/blog/2015/09/23/storing-time-series-in- postgresql-efficiently/)

That blog post grew to be tgres [http://github.com/tgres/tgres](http://github.com/tgres/tgres) [https://grisha.org/blog/2017/03/22/tgres-0-dot-10-dot-0b-tim...](https://grisha.org/blog/2017/03/22/tgres-0-dot-10-dot-0b-time- series-with-go-and-postgresql/)

<comment><USER3> To my understanding, Tgres is really more of a "middleware" layer that collects metrics and performs aggregations on them that are stored back into Postgres (e.g., generates aggregate rates for evenly spaced time intervals a la RRDTool), rather than being a scalable time-series DB itself.

That's useful in many dashboard-based server monitoring applications, but time-series DB have many other applications (and can benefit from more complex queries even in monitoring).

Tgres and Timescale are actually a bit complementary, and you might even be able to use Timescale as a better backend for Tgres.

<comment><USER4> As the author if Tgres, I can chime in here - dr. mfreed is correct.

While Tgres is an application layer, the main motivation behind developing it was to answer the question "can TS be stored in Postgres efficiently, ideally without requiring an extension". Not that there is anything wrong with custom extensions, but I wanted to keep the requirements to the absolute minimum.

I always had issues with people saying that relational databases are fundamentally not suitable for TS storage, and Tgres debunks this by demonstrating that you can sustain very high rates of incoming data by simply organizing the data in a more creative way.

The graphite functionality that Tgres emulates is just there to prove the point - as in, look it does all these things, and it's all in the database.

Hypothetically Tgres could work on top of Timescaledb with a few changes, I just only have so much spare time to tinker with this experimental stuff that I haven't tried it.

Another interesting thing I came across is PgPointCloud [1], it's designed for LIDAR data but is perfectly suitable for time series as well. It is a C extension. It's performance advantage comes from storing large numbers of data points in a variety of compact/compressed formats.

[1] [https://github.com/pgpointcloud/pointcloud](https://github.com/pgpointcloud/pointcloud)

<comment><USER5> It is still not very clear at this point if Tgres approach is sufficient enough, and if timescale adds significant performance advantage over native array based Postgres implementation.

<comment><USER3> I think the broader point is that Tgres is generally focused on computing regular aggregations. Once you do that aggregation, you lose significant information about the relation between data collected at the same time, which eliminates your ability to ask a variety of questions. For some basic dashboarding/monitoring applications you don't need this, for other applications you absolutely do.

So, it's pretty common in Timescale to store raw data in one hypertable (with a shorter data retention policy), and aggregations in a separate table (with a longer data retention).

Regarding native storage, the insert rate really goes down as your table gets large, e.g., Timescale gets 20x higher throughput than PG: [https://blog.timescale.com/timescaledb- vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e)

I don't see a reason this wouldn't apply to Tgres' use of native storage as well...but once you do aggregations (say, per minute), your tables are just much smaller (only 525K minutes / year), so it perhaps matters less.

<comment><USER5> > Regarding native storage, the insert rate really goes down as your table > gets large, e.g., Timescale gets 20x higher throughput than PG: > [https://blog.timescale.com/timescaledb- > vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e)

I actually looked at this benchmark briefly, but couldn't find what kind of PostgreSQL schema you used there. Did you use similar array based schema as was described by Tgress author in his post? [https://grisha.org/blog/2015/09/23/storing-time-series-in- po...](https://grisha.org/blog/2015/09/23/storing-time-series-in-postgresql- efficiently/)

<comment><USER6> We used a pretty basic approach for both: 12 columns - timestamp, hostname, 10 CPU metrics.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> A project I work on has time series stats in postgres--it's essentially an interval, a period, a number of fields that make up the key, and the value. There's a compound index that includes most of the fields except for the value. It works _surprisingly_ well, for tens of thousands of upserts per second on a single postgres instance. Easy app integration and joins are a huge plus. I'm really curious to check this out and see how it performs in comparison.

<comment><USER3> In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres:

[https://blog.timescale.com/timescaledb- vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e)

tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features

<comment><USER8> Ok and if one is partitioning by date and dropping partitions instead of deletes in vanilla postgres how does it compare ?

<comment><USER3> The delete performance will probably be similar, but standard partitions in postgres have a bunch of current limitations.

For example, the insert pipeline is still quite a bit slower, partition creation is still manual, can't do as good constraint exclusion at query time, can't do certain query optimizations we've built in, can't support user- defined triggers, can't handle UPSERTs, doesn't support various constraints, can't do VACUUMing across the hierarchy, etc.

We plan to write a blog post comparing against PG10 partitioning in the future to expand on this a bit.

All this said, we do love Postgres and realize that it's trying to provide a more general-purpose solution, so don't mean this as criticism. We can just build something more targeted at the time-series problem.

<comment><USER8> Thank you for the explanation looks like you have dedicated a good bit of effort to making a good ts solution, will be testing it out :)

</comment></comment></comment></comment></comment><comment><USER9> Why do you usually advertise the write performance? Let's say that I have "100+ billion rows (the number in your landing page)", how much time it takes to run a simple GROUP BY query?

The benchmark repo doesn't actually include the performance comparison between Timescale and Postgres: [https://github.com/timescale/benchmark- postgres#benchmark-qu...](https://github.com/timescale/benchmark- postgres#benchmark-queries-timescaledb-benchmark-query)

This blog post ([https://blog.timescale.com/timescaledb- vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e)) has some query benchmarks and the main benefit it that the hypertable will partition the data smoothly and if we query the table by filtering with timestamp column, it will be fast since Timescale uses partitioning as an indexing method.

<comment><USER3> Write performance is a much simpler metric than query performance, which is HIGHLY dependent on the actual query being performed. Plus, in many time- series settings, you actually need to support high-write rates, which vanilla RDBMS tables can't support.

On the query side, we find that most queries to a time-series DB actually include a time predicate, LIMIT clause, etc. It's pretty rare that you do a full table scan over the 100B rows. (And for these types of broad scans, performance depends on # disks and use of query parallelization.)

Not sure I understand the comment about the benchmark repo doesn't include the performance comparison? That repo is meant to accompany a blog post, which discusses the results ([https://blog.timescale.com/timescaledb- vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e)), while the repo allows you to replicate our results.

<comment><USER9> I mentioned about the benchmark repo because I wanted to learn why you usually advertise on the write performance instead of query performance. The benchmark repo shares the results for write performance but not query performance. Later on, I saw the benchmark for query part in your blog post, which was great.

I agree that full-table scan is not common in time-series use-case and you can't improve the performance in that case unless you use a different storage format. The confusing part for me is that if I have 100B rows, I would probably use a distributed (multi-node) solution unless the dataset includes 50 years of data and I want to query the last week because Postgresql is not good enough when aggregating huge amount of datasets.

Do you have any plan to release distributed version (the chunks may be distributed among the nodes in cluster) or implement columnar storage format?

<comment><USER3> Yes, we're working on a distributed version of Timescale as you describe.

But two clarifications:

1\. It can aggregate better than you might think. We've had people run single- node Timescale with 20+ disks, then couple that with query parallelization, and you can do pretty good aggregation over larger datasets.

Plus because the way the data is partitioned, a GROUPBY will actually get good localization over the disjoint data (i.e., groups can be local to a chunk) and generate more efficient plans given the smaller per-chunk indexes.

(And the various cloud platforms make it _really_ easy to attach many disks to a single machine. Our our published benchmarking is on network-attached SSDs.)

2\. You can use read-only clustering today, i.e., with standard Postgres synchronous or asynchronous replication. So you can scale your query rates with the replicas as well.

<comment><USER9> Thanks for the clarification.

1\. Do you use Postgresql 9.6 query parallelization ([https://www.postgresql.org/docs/9.6/static/parallel- plans.ht...](https://www.postgresql.org/docs/9.6/static/parallel- plans.html#PARALLEL-AGGREGATION)) or your own method for processing chunks parallelly? When we have >1B rows with >20 columns, the IO usually becomes a huge the bottleneck in our experience. If you use multiple disks and parallelize the work among different CPU cores, it would help I guess.

<comment><USER3> Currently support 9.6 query parallelization. Also considering extending with some of our own methods on chunks as well.

(Timescale supports multiple disks either through RAID or tablespaces. Unlike PG, you can add multiple tablespaces to a single hypertable.)

Happy to also go into more details on Slack ([https://slack- login.timescale.com](https://slack-login.timescale.com)) or email.

</comment></comment></comment></comment></comment></comment><comment><USER10> Great to see what you all are doing.

Are there any plans to move timescale to be an extension as opposed to a fork? We've found ourselves at Citus that maintaining an extension lets us more easily stay up to date with current releases. Would love to see the same applied to timescale.

Edit: Looks like it is already one, just was unclear in the docs on the setup steps to me. Well done all.

<comment><USER3> Hi Craig, Timescale person here.

noir-york is correct. TimescaleDB was always an extension, never a fork. So all installations are just a `CREATE EXTENSION` and upgrades between versions just via `ALTER EXTENSION` commands.

But you're absolutely right -- way better than doing a fork!

(Say hello to Ozgun for us.)

</comment></comment><comment><USER11> Please stop tormenting me. This looks like exactly what we need (I was looking into manually partitioning the other day) it's just so annoying there is not yet Amazon RDS support.

<comment><USER3> Customer requests help the process with RDS along :)

[https://github.com/timescale/timescaledb/issues/65](https://github.com/timescale/timescaledb/issues/65)

</comment></comment><comment><USER12> I've come to rely heavily on Cassandra, but I miss good old SQL and adhoc functionality. Systems like Cassandra bring orher requirements when you need flexible data (Spark, for example), technical debt is always a worry for me.

I want to give this a go for sure!

<comment><USER13> Hi, I'm curious what limitations you're running into with Spark SQL?

<comment><USER12> No limitations. Spark works and does a good job, it has many features that I can see us use in the future too.

With that said, it's yet another piece of tech that bloats our stack. I would love to reduce our tech debt: We are much more familiar with relational databases like MySQL and Postgres, but we fear they won't answer the analytics problems we have, hence Cassandra and Spark. We use these technologies out of necessity, not love for them.

<comment><USER13> Ah, I see -- so a thing that I'm curious about is, what do you miss about relational databases? Are they mainly aspects on the operational side, or the usability/API side?

Ultimately, the question that I'm interested in trying to answer is: would it help if there were more ways to make Spark feel like a traditional relational database? (e.g. being able to interact with the Spark driver using MySQL or Postgres wire protocol)

<comment><USER12> Spark already does a good job at that, imo. It's increasingly easy to query information, at this point we are basically writing SQL-like queries with it. BUT, Spark isn't a relational db, or even a storage solution. What I miss is just having the one piece of technology that deals with both storing and querying: Actual relational databases.

It's interesting. 10 years ago I would have probably said something like that "relational dbs will just get better as data grows", quite the opposite happened... Relational has been pushed to the side and we now have to learn a lot of new technologies, in my case: Cassandra; Spark; Pandas (python). This whole stack used to be just MySQL :)... And I miss those days!

<comment><USER13> Ah, yeah. I have so many mixed thoughts on this. I also think that the open source world copying Google's super-decoupled GFS-Bigtable-MapReduce-Dremel- etc... architecture was really not great for operational complexity. Few teams can operate like Google, and maintain so many moving parts in production all at the same time.

At the same time, of course there are some very good points to be made for this sort of storage agnosticism -- mainly from an efficiency standpoint (i.e. being able to choose the storage format for the occasion). I'm really not quite sure if this argument is strong enough for completely sacrificing the simplicity of a traditional database.

Sometimes I think that MPP engines like Spark should take the philosophy of "batteries included but replaceable" \-- that is, basically serving as an all- in-one "database" that provides a default storage engine (e.g. a basic columnstore and a basic rowstore), but still letting the user plug in other data sources to join, only if they want.

</comment></comment></comment></comment></comment></comment><comment><USER14> further evidence of how postgreSQL is eating noSQL. Every good concept first implemented in a custom noSQL solution eventually becomes an extension in postgres.

<comment><USER15> I also do the same when developing: Proof of concept in NoSQL, then go wild with the schema, then watch it become a horrible mess, then refactor into SQL (That being pg or mssql depending on the needs/politics)

</comment></comment><comment><USER16> We have a requirement of saving 100million data points every 5 mins. What options should we explore for real time system for last 15 days of data and archival system for last 3 years of data?

<comment><USER17> I don't have any experience with this type of thing, so that sounds like an incredibly large amount of data. What are you doing that requires it? What type of useful queries are you even able to perform over 432 billion records?

<comment><USER18> 300k+ sensors sampling at 1 hertz would get you there.

</comment></comment></comment><comment><USER19> Alright, I'm excited to check this out. Been teetering on InfluxDB for a while, but not something I wanted to just introduce into corporate. Great work guys!

</comment><comment><USER20> While nice, it suffers from the same problem storing timeseries in any sql database: you have to predefine your tables. For a fixed and known set of metrics, that's all fine, but if you look at the possible outputs of for example Telegraf, things become a bit more tricky to pre-create all tables/schemas...

<comment><USER3> Well...sorta. Postgres/Timescale have pretty rich support for JSON these days (and its more efficient "binary" JSONB), so there are a whole range of options you can do that make it feel much more schema-less than before.

In fact, last month we released a beta version of a Prometheus connector for Timescale/Postgres that allows you to store arbitrary Prometheus metrics without pre-defining all these varied schemas:

[https://github.com/timescale/pg_prometheus](https://github.com/timescale/pg_prometheus)

The same approach should work for Telegraf, we just haven't yet tried to generalize this plugin.

<comment><USER20> Well, JSONB has a performance or afaik a pretty significant disk usage impact if you use GIN. It's pretty nice stuff, but I'm not sure about using it for timeseries. I haven't seen any benchmarks though, this could be useful.

One advantage specialized db's like influx have is specialized/optimized storage layers for the type of data while timescale seems to use normal postgres tables behind the scenes.

That Prometheus extension and adapter however look nice! They seem to be a good drop-in replacement for whatever storage, and the missing link for anything that's able to talk to Prometheus (which is quite a lot, including Telegraf).

<comment><USER3> A common approach we find for storing devops-related time-series data (as you'd find with influx), is to not denormalize the "labels" or "tag set" into the main metrics table.

This obviously saves significant space just by avoiding denormalization, ignoring the indexing overhead as well. You can see that in our Prometheus extension, btw:

[https://github.com/timescale/pg_prometheus#user-content- norm...](https://github.com/timescale/pg_prometheus#user-content-normalized- format)

Regarding performance against Influx, it really depends. We're working on releasing more complex benchmarks soon.

But overall, they have a performance edge if it's a single column scan that precisely matches their particular architecture (e.g., WHERE clause or GROUP BY by a very specific label set). But, we've found that Timescale actually gets higher query performance across a whole set of pretty natural queries (sometimes ridiculously so, as Influx doesn't index numerical values). Plus higher insert rates and full SQL. Not only is the latter point important for enabling many more types of complex queries, but it means that any viz or reporting tool that already speaks to Postgres should just work with us.

<comment><USER20> > But overall, they have a performance edge if it's a single column scan that > precisely matches their particular architecture

To be honest if they didn't - stuff like Influx wouldn't really have a reason to exist. I think 99.9% of the operations in a devops environment will be pretty simple and predictable, it's a a trade-off they make. Queries are mostly there to draw graphs quickly.

I quite like the simplicity of Influx, and while our current use is pretty limited and far from hitting it's limits, for reliability and maintenance reasons I'd prefer Postgres, for which we have quite extensive in-house know- how and tools in place. Prometheus is one of the tools we are considering to add to our monitoring stack, and having the option of storing it's data transparently in Postgres could be very interesting.

</comment></comment></comment></comment></comment><comment><USER21> We have been using Postgres for a smaller event time series database (millions of rows) with good success. Tables are partitioned.

Some user reports (aggregations) are ~5secs so we batch-pre generate them currently.

Eeager to look into this to replace generation of reports with real time reports.

</comment><comment><USER22> This is something i've been meaning to look into for a personal project that has a lot of time series data. It'll be interesting to see what they eventually come up with to make time series data not take quite as much space.

<comment><USER3> Hi Tostino, please let us know how things work.

Regarding compression: While we haven't yet built in any native compression, we regularly run on ZFS and typically get 3-4x compression using that. (Plus with ZFS, insert rates are actually a bit faster, at least when using a single disk (often 25%). It's definitely something to consider.)

Another thing to consider is that Timescale supports easy data retention policies, which can also vary by hypertable (i.e., keep raw data for 1 month, aggregated data for 1 year).

It also supports many disks per server, either via RAID or through Postgres' tablespace. But now you can have multiple tablespaces in a single "hypertable", rather than just one like normal. So especially in cloud settings, it's pretty easy to just add more and more disks to even a single machine.

<comment><USER23> Really interesting to hear you use ZFS for those benefits. Are you using ZFS on Linux or a Solaris variant?

<comment><USER6> We used it on an Ubuntu machine on Azure. We didn't do any real tuning yet, it was just an initial test to ballpark the benefit.

</comment></comment></comment></comment><comment><USER24> Whoa, fantastic!

I have managed to design a vanilla PostgreSQL solution, with partitions and BRIN indices, but there are too many hops to jump. I am excited to check if it will work out of the box. 100 billion rows per server sounds exciting!

</comment><comment><USER25> Great work! I was curious about a few things:

1) Are you planning on using citus for clustering? Or will you have your own clustering implementation separate from Citus?

2) Can you still use barman, wal-e, etc for backups?

3) What are you guys using to generate docs.timescale.com? :)

4) Do you use any sort of custom on disk format?

5) Do you plan on implementing any sort of delta compression?

6) Is there/do you plan to have support for creating roll up/aggregation tables?

Cheers!

<comment><USER6> Thanks, great questions!

1) We are currently exploring all options for clustering, though we are likely to try something on our own. No final decisions made yet though.

2) One of the next tutorials we'd like to do is how to setup using Timescale with wal-e for backups (we use this in a hosted service we have). Generally we should work with tools that work with PostgreSQL, we just want to make sure we cover all the caveats.

3) It's a custom solution we've built sort of organically that converts Markdown files (with some custom syntax) into HTML. :)

4) Currently we do not.

5) We have had high level talks about various ways to better compress data including delta compression, but nothing definitive yet. We do find just running on ZFS gives 3-4x compression, so that's already a nice win if compression a priority.

6) This is definitely on our roadmap but again is also in the early stages.

Thanks!

</comment></comment><comment><USER26> This looks cool. I love things that get rid of extra dependencies. Influxdb is nice but then I have to support it, get stuff into it and get stuff out of it.

Timescale isn't currently supported by RDS/Aurora though, so it looks like more influx for me wooohooooo!

<comment><USER3> We've been talking with Amazon, and you can help the process along:

[https://github.com/timescale/timescaledb/issues/65](https://github.com/timescale/timescaledb/issues/65)

<comment><USER26> Nice!!!

Edit: emailed them, hopefully I matter a teensy bit.

</comment></comment></comment><comment><USER27> How would this work together with something like Stolon? [https://github.com/sorintlab/stolon](https://github.com/sorintlab/stolon)

<comment><USER3> Generally speaking, a TimescaleDB database just looks like Postgres to admin tools. So this looks interesting, and we are already internal Kubernetes users.

Will have to look at more.

</comment></comment><comment><USER28> Can this be queried with Grafana or some other visualization tool?

<comment><USER3> If the viz tool can speak to Postgres, it works with Timescale. Tableau, Superset, SQLPad, Mode, Plot.ly, etc.

We internally use Grafana through a REST interface to a timescale backend. (And in fact, that's how we visualize the Prometheus data we store in Timescale: [https://github.com/timescale/pg_prometheus](https://github.com/timescale/pg_prometheus) )

But, Grafana Labs is still working on a native Postgres connector (MySQL released earlier this year). They promise us soon :)

</comment></comment><comment><USER29> Is the business model to charge for the clustering release?

<comment><USER30> Timescaler here. Although we haven't done any official announcements w.r.t. clustering, our plan is for this to be open source, like the single-node version.

<comment><AUTHOR> Learning from the RethinkDB 'situation' [1] - do you have a viable business plan and are you monetising the database already?

1\. [https://news.ycombinator.com/item?id=12649414](https://news.ycombinator.com/item?id=12649414)

<comment><USER30> We wouldn't do this if we didn't believe we could make a business out of it. That said, we are at a pretty early stage at this moment and are looking at many different options. As you may know, and if you've been following the discussions around business models for open-source projects, there are many approaches as well as challenges. All I can say is that we have been following the discussions and we are drawing lessons from past failures and successes.

</comment></comment></comment></comment><comment><USER31> At a higher level, is this the same concept as Datomic?

<comment><USER32> Not at all, although there are some similarities at a lower level (First class notion of time). Datomic has a much tighter focus on immutability, auditability, and database-as-a-value. Datomic isn't a good fit for use as a general purpose time series db where you have billions of observations.

</comment></comment><comment><USER33> So this is based on Postgresql. How does it compared to other solutions that are written from scratch to be a time series DB like influxDB?

<comment><USER6> We are working on benchmarks comparing ourselves to other solutions so hopefully we'll have concrete numbers on those soon. (Incidentally, we did a blog post on us vs plain PostgreSQL today: [https://blog.timescale.com/timescaledb- vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e))

At a high level though, we do find that having native support for full SQL to be a big win. Also, if you already store metadata or other relational data that you want to combine with your time-series data, it's great to be able to use one DB instead of separate solutions. Performance wise we do believe we are competitive and in some cases much better, and we have the 20 years of stability from PostgreSQL to build on.

<comment><USER34> I look forward to a KDB comparison. Please dont forget them.

<comment><USER35> Me too.

At first blush KDB is orders of magnitude faster, especially if using a GZIP card.

But Timescale is open source and not core locked.

¯\\_(ツ)_/¯

<comment><USER33> > At first blush KDB is orders of magnitude faster

Are there actual benchmarks that show KDB being orders of magnitude faster than Timescale? How many orders of magnitude are we talking about?

</comment></comment></comment></comment></comment><comment> shady-lady What is the extra size on disk as a result of using this? I'm guessing there's some overhead?

<comment><USER3> There's not really any meaningful extra size for Timescale compared to standard Postgres.

I mean, there's a little extra information about each chunk (table name, its constraints, triggers, etc), and we cache this information in memory to speed up the query/insert side of things. But it's pretty common for these chunks to be on the order of 100s MB to GB, so this is just noise compared to the underlying data/indexing size.

So on the real storage size, the only potential difference is index size: say 50 indexes over 2GB data each vs 1 index over 100GB data? Haven't really looked into this for all different index types, but seems rather modest. Can try to dig up some more data.

<comment><USER3> Looking at the tables we used for recent benchmarking comparing Postgres vs. Timescale ([https://blog.timescale.com/timescaledb- vs-6a696248104e](https://blog.timescale.com/timescaledb-vs-6a696248104e)):

PG 100M rows: 30.98GB (1 table)

TS 100M rows: 30.93GB (1 hypertable, 6 chunks)

Same results for the 1B table, just 10x larger (and TS has 10x more chunks).

<comment> shady-lady Wow. impressive. would have thought there would have been more overhead.

</comment></comment></comment></comment><comment><USER5> How timescale fits postgres maintenance patterns(replication, backup)?

<comment><USER3> Basically just looks like a postgres database on the admin side.

Replication works (we aren't munging with the WAL), docs for backup/restore ([http://docs.timescale.com/api#backup](http://docs.timescale.com/api#backup)), and you can just use pgAdmin.

</comment></comment><comment><USER36> How does this compare to Vertica?

</comment><comment><USER37> Why no redirect to https here?

</comment><comment><USER38> Any support for RDS? :)

<comment><USER3> We're talking with them...and you can help: [https://github.com/timescale/timescaledb/issues/65](https://github.com/timescale/timescaledb/issues/65)

<comment><USER39> I submitted a request; my company's not huge but I hope it helps.

Timescale looks like the most promising replacement to InfluxDB on the market. Influx has been a source of pain, data corruption and other various issues; what a world it would be if we could use timescale!

The main blocker for us is Grafana support actually. I know Grafana is working on a Postgres connector; I am quite excited about this.

<comment><USER40> You might have experienced data corruption in an old version of InfluxDB, but we haven't had any reports of that kind of thing in over two years. There are certainly still things to be improved, which we're doing all the time, but we take data integrity seriously.

<comment><USER39> I shouldn't have said data corruption, I just meant time corruption: [https://github.com/influxdata/influxdb/issues/8424](https://github.com/influxdata/influxdb/issues/8424)

I was never able to fix this.

</comment></comment></comment></comment></comment><comment><USER41> Any SQL database can do time-series well with more functionality then the specialized stuff like influxdb which doesn't really have much reason to exist at this point.

Citus is a another good alternative and SQL Server and MemSQL also have in- memory and columnstores if you need the performance and scalability.

<comment><USER20> Not really true. I point whatever thing that talks something like influx to it with the right credentials and it outputs whatever metrics it wants to it. No need to manage/pre-create all your tables for every single possible metric out-there.

I seriously dislike nosql databases for most purposes, and am absolutely a Postgres fan - but timeseries is the only thing I've encountered that benefits from a dedicated schema-less database engine.

<comment><USER41> How's that any different than something that talks SQL? It's the most universal data language there is.

Why do you have to make new tables? It's 1 table with _timestamp_ , _name_ , _value_ to store all your metrics and you can use an array or json column if you have extra non-structured data. Add in the SQL joins and analysis and you get a much better tool for timeseries.

<comment><USER20> > How's that any different than something that talks SQL? It's the most > universal data language there is.

To use SQL you need to know the schema you're working against. Every single tool has to agree on a specific schema - and there are tons of existing tools that push infrastructure/system metrics into timeseries databases. For them it's simple, Influx uses some API, OpenTSDB uses another, Prometheus uses yet another - but they're all pretty simple to use. If you would point them to a Postgres database on the other hand, they wouldn't have a clue what fields to insert.</comment></comment></comment></comment>


GoodUI.org - <AUTHOR> http://goodui.org/

<comment><USER2> By the time I got to #9, helpfully labelled a "conversion tip," I became convinced that this wasn't about good user interface, this was about how to sell more stuff. Which... I mean, there's lots of people in the world who want to sell stuff, so there's an audience. But it's not a good name for what they're trying to do.

</comment><comment><USER3> Bah, I thought this was going to be something universal but it is just the 523rd site about how to sell things to people by designing your generic website with "conversion tactics" and psychological manipulation.

</comment><comment><USER4> It's important to note that a lot of these tips aren't good UI for the user, but for the business itself when attempting to manipulate the user. I wish it would have been labeled more appropriately.

</comment><comment><USER5> Some of the advice seems to be oriented for a US-like culture (e.g. be direct). Other cultures might have different conventions, I think.

</comment><comment><USER6> I found it ironic that the site itself doesn't follow the very good advice it's giving. A case of "Do as I say not as I do" I suppose.</comment>


Data migration with Kubernetes and Flocker - <AUTHOR> https://clusterhq.com/blog/data-migration-kubernetes-flocker/ <comment><AUTHOR> We're super excited about bringing portable volumes to lots of different orchestration frameworks, including Kubernetes. Any questions, we'll be hanging out here, so ask away ;)

<comment><USER2> Are there any plans to migrate volumes that aren't ZFS backed? (or does it do this already?)

I'd think that the workflow would be similar to migrating ZFS snapshots, just extracting volumes from docker directly, and sending tarballs to the new node, as opposed to the built-in ZFS send/receive. It probably wouldn't be as efficient, but it would make Flocker an easier sell to more people.

Another question - about what size do you think portable volumes need to be before they stop making sense and you need to move to some other kind of either shared storage (NFS) or remote object storage?

<comment><AUTHOR> We are working on block device backends which integrate Flocker with OpenStack, EBS and more, as well as ZFS on local storage.

Doing a tarball based export-import backend would be an interesting Flocker backend ;)

With regards large volumes, adding more backends to Flocker will definitely open up the scope for volumes then a ZFS pool (zpool) you'd want to have on a single node. Generally though, when you need to scale data up to larger scales, it's better to use a distributed data store which can shard your data across a larger number of smaller stateful containers, which can also be managed by Flocker, but of course that's application-dependent.

<comment><USER3> Great to see development in storage with docker!

I like how this migration works. What about live migrations? Maybe I misunderstood, but I think in the tutorial the service is offline for some time. What about maybe applying backpressure (tcp level) to timeout the request while migration is underway?

Edit: If we are doing tarball migrations, then maybe i'd rather have an rsync backend :)

Oh and if we are doing large amounts of data migration (gigabytes), maybe even use something akin to something like what bittorrent sync is doing? The scenario would be that you use bittorrent sync (this is a theoretical example..) to one-way migrate continuously (to maybe multiple hosts..??), then pause/hold traffic when satisfied, complete final sync and you are migrated.

<comment><USER2> I had a similar question, but my impression from the tutorial (and my pondering) is that you couldn't really do a live migration with containers. I'm not sure it will ever be supported. I don't think that the host would have enough information about the processes in order to capture their state and migrate running processes to a different host.

I'm not sure this would even be possible outside of a virtual machine. VM hosts have significantly more information and control about the VM than the container host has about the container. For example, a VM host knows exactly what memory is hot and what is cold to enable sub one-second switchover times.

It might be possible to add such support to the Linux kernel itself to support process migration between hosts, but that's the level of work required.

The alternative that I was thinking about using your standard high- availability tools to create a new worker on the new host, then gradually remove existing workers on the old node. I think that might be the only way to really make "live" migrations work from a practical standpoint. For web-like services, this would work. For others, it may not be practical.

EDIT: Looks like the checkpointing running processes might work after all! (see: [http://en.wikipedia.org/wiki/CRIU](http://en.wikipedia.org/wiki/CRIU)) I must admit that I'm still a little skeptical, but would love to see this working!

<comment><USER4> CRIU has worked fine for a long time. I've used CRIU under LXC in a lab, and CRIU alone in production.

This problem arises because Docker positions their intrinsics as novel containers, even though there was an entire field of prior art long before Docker showed up. Hence your confusion and worry checkpointing will never be supported; it already was, but you didn't know about it, because to you Docker == containers. One of my many problems with Docker, because they feed that.

Look how easy it is: [http://criu.org/LXC](http://criu.org/LXC)

<comment><USER2> From that example, it's pretty clear you can checkpoint and restart a container with CRIU, but can you migrate that state/checkpoint file to a different host? I can see restarting it on the same host, but a different host sounds "difficult". That's what I have the most questions about. I'm not sure how that would work between systems, particularly open files handles, sockets, etc... If you have a "share-nothing" architecture, I think that would be easier, but it you have to maintain some kind of state within the container, things get real hairy fast.

I have to agree though that it seems strange to me that Docker has gotten a lot of support so quickly when things like LXC, FreeBSD Jails, or Solaris Zones have been established for so long. I've only played with Jails a bit, having done more work with full virtual machines in Linux. The other containers, I at least had a familiarity with before Docker (nothing in production). However, I had not heard about CRIU until today. But it looks really interesting!

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Well done, Kai! Cannot wait to try it out ;)</comment>


Americhrome (2011) - <AUTHOR> http://www.themorningnews.org/article/americhrome

<comment><USER2> This is quite interesting article, but it's quite weird to read without the presentation of mentioned colors.

<comment><USER3> It's hard to tell for many of them (there are lots of darker colors), but, everywhere the author mentions an FSxxxxx color number, the number itself is colored with an approximation of the mentioned color.

Could be easier to see, though. Using blocks of color instead of colored text would make the colors easily distinguishable. It seems weird to have so much text and so few visuals in an article about color...

<comment><USER4> Hi, I'm the publisher of the site. Great suggestion, and we've updated the text to background colors.

<comment><USER3> Cool-- that looks nice.</comment></comment></comment></comment>


Google Pixel's Assistant Can Now Control Your Smart Home - <AUTHOR> https://www.technewsinc.com/google-pixels-assistant-can-control-your-smart-home-367456/ <comment><USER2> I just tried this, I don't have a pixel but I _did_ have control over my hue bulbs. Now I don't.

Sometimes google's releases are utterly baffling to me, I have _no idea_ what capabilities I have or should have with a variety of their software. Sometimes it's not released yet, or it is, but on a rolling upgrade so I won't get it for weeks or it's there but because a language setting is "UK" it's not enabled and even _then_ it seems like functionality is coming and going.

</comment><comment><USER3> A big problem with all those talking speakers - "IOT Hubs" or how they call them is that people have very little incentive to use them over their phones.

The current wave of smart home devices like Google Home or Echo are nothing new, similar devices were available from OEMs for years, and no big brand was willing to sell them for that obvious reason.

Samsung made the right bet to glue all of their smart home offerings to their smartphones. Google's idea with nest was a miss because nobody was ready to buy it just to play with specially locked down "Made for Nest" webcams and other appliances, when everybody can buy a 10$ Chinese webcam that works just fine by itself.

Same with HomeKit fiasco, nobody really needs overcomplicated platform- lockdowned appliances that do not work without cloud connectivity and enforced DRM verification every 24 hours, when "Uncle Liao Electronics" provides what is a superior alternative in eyes of an average consumer

<comment><USER4> Does having the assistant always listening on your phone drain the battery any faster?

<comment><USER3> It does on phones where voice detection is not ran on a separate chip.

</comment></comment></comment><comment><USER5> > Tni Editorial Team - February 12, 2017

</comment><comment><USER6> This has been available on the Assistant for over a month already...

<comment><USER4> Article says:

> _It is unfortunate that the Home Control feature is not available on Pixel > Phones right now because it was available for a limited edition._</comment></comment>


The NSA back door to NIST - <AUTHOR> http://jiggerwit.wordpress.com/2013/09/25/the-nsa-back-door-to-nist/

<comment><USER2> "The back door to the algorithm is the number e such that P = e * Q. To use the back door, one must know of the value e. The NIST standard does not disclose e (of course!), and extensive cryptographic experience suggests that it is hard to compute e from the coordinates of P and Q (unless you happen to own a quantum computer). This is the problem of discrete logarithms. But starting with e, there is no difficulty in creating a pair P and Q. The back door is universal: a single number e gives back door access to the internal state of the algorithm of all users worldwide."

Hah. So this is what the leaks referred to, the backdooring of standards. E.

Thanks for the link.</comment>


Lessons from the Debian/OpenSSL Fiasco - <AUTHOR> http://research.swtch.com/2008/05/lessons-from-debianopenssl-fiasco.html <comment><USER2> Provide as many tips and rules of thumb as you want. Sometimes, it's safe to modify code you don't understand. And then, those tips will help. But that all goes out the window when it comes to security code. If you don't understand security code, don't mess with it.

</comment><comment><USER3> Excellent points here, especially the bits about the rationale behind patching major packages when maintainers should be taking the extra time to submit patches upstream instead.</comment>


Skype legend Morten Lund bankrupt - <AUTHOR> http://uk.techcrunch.com/2009/01/14/as-raw-as-it-gets-startup-legend-lund-bankrupt/ <comment><USER2> Techcrunch got the facts wrong (again). It's 10 million Danish kroner (DKK), not krona, which is equivalent to 1.76 million USD at the current exchange rate. He promised he would give 10 million to the former CEO and the former chairman of Nyhedsavisen, the newspaper he invested in, if the newspaper closed. They sued him because he didn't pay up, and then was declared bankrupt.

According to an article in Børsen (<http://borsen.dk/executive/nyhed/140074/>) he said he personally invested 105 million DKK (not 10 million) in Nyhedsavisen. Money that he had loaned.

</comment><comment><USER3> Its amazing that someone as intelligent as Morten Lund would invest every single penny into a single venture.

But I think he'll live through this...just watch his Le Web presentation...he seems really upbeat.

</comment><comment><USER4> He's a good entrepreneur and a tech guy. What would possess him to invest heavily in a newspaper? It's so far from technology, and it's a dying industry.

Memo to anyone thinking of investing in companies: when considering in what field to invest, the word _dying_ should be a huge red flag.

<comment><USER5> He invested in a free newspaper, not a traditional one. In a speech in Berlin he said that he is always trying to change the rules of the game. By the way newspapers aren't dead, they are just evolving.

<comment><USER4> Oh, so it had less revenue than normal. I guess it was a sound investment then.

That is cooler, but also not the wisest idea economically. Investing so much of your money based on your ideals rather than because you think it's a good idea is a good thing to do principles/karma-wise, but it does make you more likely to make a bad investment.

<comment><USER6> "Oh, so it had less revenue than normal."

It has less kind of revenues, not necessarily less revenue. I don't know in Denmark, but in Spain free newspapers are flourishing and there's even tough competence (Metro, 20 Minutos, ADN, Que...). They live on ads and are pretty healthy.

Edit: In fact, paid newspapers here live more on ads and government aids than nominal price.

</comment></comment></comment></comment><comment><USER7> I really love this talk, I've already sent it to several friends (including a couple of McKinsey suits, ha).

I don't agree with all of the parts about strategy being pointless. There's a grain of truth -- like go with your gut or something, but he takes it too far. But it is probably worth noting that I think his end game is happiness, innovation and spontaneity versus financial success.

The things I love (and I mean love) about this are: # rollercoaster of entrepreneurship # talking about how everyday is like a recession for entrepreneurs # his general outlook on life and doing something very satisfying rather than scamming for a buck

</comment><comment><USER8> Strange how someone can make such a stupid investment.

The bright side of the story is that it shows that anyone can hit big time -- even people with poor investment skills (in non-tech areas) like M. Lund...

</comment><comment><AUTHOR> is he really bankrupt if he has stock in 88 companies?

<comment><USER9> His ownership of these companies is included in the bankruptcy proceedings, and will be sold off to compensate his personal creditors.

<comment><USER10> may I ask how do you know that?

<comment><USER9> I'm Danish and it says so in the Danish newspapers :-)</comment></comment></comment></comment>


Where Web UI Libraries Are Heading - <AUTHOR> https://dev.to/ryansolid/where-web-ui-libraries-are-heading-4pcm <comment><USER2> Nice read!

I think the ultimate approach to front end will be streaming SSR + partial hydration like Marko does, for the first request. Then a client side router that loads pieces of HTML a la AJAX that are also partially hydrated from code splitted pieces of JS.

Obviously all neatly tied into a framework that runs on a Node/Deno server or a cloud function, and allows you to focus on simply making components.

<comment><AUTHOR> Yeah I think that is the convergence point. Marko actually has a bit of a head start in some ways. But they need to look at the client part which I imagine with users like EBay is less necessary. React is likely getting pretty close, but I think their library size is making them consider how to remove the client routing piece. Preact still has the hurtle of getting their rendering as powerful as React Concurrent Mode. Solid's primitives are small and a nice stand in for Concurrent mode, but has the loosest data model which makes hydration tricky. But it will happen as all pieces are independently solved. It's actually not that simple for anyone to put it all together.</comment></comment>


700 megapixels served in under 700 miliseconds - <AUTHOR> http://mag.prodibi.com/2016/11/10/700-megapixels-through-the-interwebs-in-under-700-miliseconds/ <comment><USER2> There is opensource component that does this: Open Seadragon [https://openseadragon.github.io](https://openseadragon.github.io)

You pass a big image to "vips dzsave" [http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS](http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS) and it creates a .dzi file describing the tiles and a set of directories with zoomed in tiles. Then you add a div to your HTML and execute this js

        viewer = new OpenSeadragon({
                        id: "openseadragondiv",
                        prefixUrl: "/Scripts/openseadragon/images/"
                    });
        viewer.open(pathToDZI);

It also has plenty of useful plugins, eg. Scale bar [https://pages.nist.gov/OpenSeadragonScalebar/](https://pages.nist.gov/OpenSeadragonScalebar/) or Annotations (to draw on the image) [https://github.com/Emigre/openseadragon- annotations](https://github.com/Emigre/openseadragon-annotations)

<comment><AUTHOR> Yeah pretty much the same idea, but not the same packaging. If you just want to quickly add a big pic in your blog and are no dev (noob here) this is everything you need. Same choice as embedding a youtube/wistia/vimeo or hosting and streaming it yourself I guess.

</comment></comment><comment><USER3> Misleading title. This uses zoomable tiles which has been done for a decade already. It is most definitely _not_ serving 700MP in 700ms.

</comment><comment><USER4> Only parts of image is requested based on where you zoom . Image is divided into number of slices and fetched on demand .

<comment><USER4> My guess is it works well for very large images . For smaller images of real world , I am not sure how effective it is ( apart from usual optimizations ) .

<comment><USER5> I think this is something that should be present everywhere. Especially when serving customers from countries with unreasonable data caps enforced by ISPs.

I have seen some times load up 5-6 MB files when a 100-200kb image would have done the job.

If us developers could have an easy way to do this, I think it would really make the internet a lot faster.

</comment></comment></comment><comment><USER6> Quite misleading indeed and definitely done before. NASA released a 46000MP picture of the milky way in 2015, which is also available online[1] using the same technique.

[1] [http://gds.astro.rub.de/](http://gds.astro.rub.de/)

<comment><AUTHOR> Mea culpa on the title... Tech is not new, but the convenience layer on top is. Everything is taken care of.

</comment></comment><comment><USER7> Here's an open-source time-proven project for huge image visualization over web: [http://iipimage.sourceforge.net/](http://iipimage.sourceforge.net/)

</comment><comment><USER8> Can somebody explain how this works?

<comment><USER9> It works like google maps. The high resolution image is sampled into several layers of lower resolution. You can call it levels.

Every level is split into quadrants.

So when someone zooms in, it will fetch the quadrants that is visible to the browser viewport. By doing this way, the browser doesnt have to load the rest of the image and thus save alot of bandwidth!

<comment><AUTHOR> Exactly. Part of the same logic when you stream video: not 100% of the frames are loaded at once, but they come in eventually.

</comment></comment></comment><comment><USER10> Stupid clickbait about NOT serving 700 megapixels in under 700 milliseconds but just about 5 megapixels in about 24 images of < 50 kilobytes each. Big whoop...

</comment><comment><USER11> Would be awesome if Flickr or 500px would use this kind of tech.</comment>


Code only says what it does - <AUTHOR> http://brooker.co.za/blog/2020/06/23/code.html <comment><USER2> _This is a major problem with code: You don 't know which quirks are load- bearing. You may remember, or be able to guess, or be able to puzzle it out from first principles, or not care, but all of those things are slow and error-prone._

This is a problem from both the negative (not breaking things) and positive (knowing how to add things) perspectives. The positive perspective was written about by Peter Naur in one of my favorite software engineering papers, "Programming as Theory Building," in which he describes how the original authors of a codebase have a mental model for how it can be extended in simple ways to meet predictable future changes, which he calls their "theory" of the program, and how subsequent programmers inheriting the codebase can fail to understand the theory and end up making extensive, invasive modifications to the codebase to accomplish tasks that the original authors would have accomplished much more simply.

I highly recommend finding Naur's paper (easily done via Google) and reading it to understand why divining the "theory" of a codebase is a fundamentally difficult intellectual problem which cannot be addressed merely by good design, and not with 100% reliability by good documentation, either.

<comment><USER3> I think I have to disagree with Naur on this, in that people using the Scientific Method don't ship their theories, but we do.

As a scientist who has just succeeded in testing a hypothesis, I now need to go back and document a simplified series of steps that should lead any independent party to the same phenomenon. Once we are on the same page, they can confirm or refute my theory based on their own perspectives on the problem space.

During that process I may discover that I based half of my experiment on another hypothesis that I never tested, or was plain wrong. Now I've discovered my 'load bearing' assumptions. I may discover something even more interesting there, or I may slink away having never told anybody about my mistake.

Essentially, scientists still 'build one to throw away'. We haven't in ages. And my read on Brook's insistence that we build one to throw away is that it was aspirational and not descriptive. And notably, he apparently recants in the 20th anniversary edition (which is itself 25 years old now):

> "This I now perceived to be wrong, not because it is too radical, but > because it is too simplistic. The biggest mistake in the 'Build one to throw > away' concept is that it implicitly assumes the classical sequential or > waterfall model of software construction."

So we are very much at odds with the scientific method. And we have the benefit of hindsight. We have seen the horrors that can occur when you take the word Theory out of context and try to apply it to non-scientific theories. We should learn from the mistakes of others and summarily reject any plan where we do it too.

In other words: next metaphor, please, and with all due haste.

<comment><USER4> I think I have to disagree with you on this one, I've used the scientific method (though not in an explicit checkbox-y way) plenty of times to ship and debug code.

In particular, since (as I've said on this forum many times) I work primarily on the maintenance end of software. I don't know what the creators or previous developers were thinking, especially with more recent projects (documentation quality has really gone down hill, people call autogenerated UML diagrams "design docs", but without commentary they only reflect the state of the system, not its design). I have to try different changes based on my understanding of the system and see the consequences. That is, I form a hypothesis about what will happen if I do X, I do it, I collect the results and I've either confirmed my hypothesis, refuted it, or left it in an indeterminate state. I form another and repeat. Over time I build up a model (theory) of how the system behaves and should be updated/extended. Since I can't keep tens of thousands of lines of code in my head, let alone hundreds of thousands or millions, I always only have a model (theory), because I never have the totality of it in my mind. Though good code, with good use of modules, makes it easier to keep large chunks in mind, I still have to have a model of how those modules work and work together.

Hell, this is half (or more) of testing for older software systems. You put in some input and see if you get the output you expected. If you don't, you evaluate why (is my model wrong or is the system wrong) and repeat.

<comment><USER3> I don't mean 'use' as in a #7 torx wrench. I mean 'use' as in air.

I have shipped bug fixes using organized hypothesis checking as well. Especially sanity checks (make sure the instruments are working). But it is not the software developer's default behavior, and I'm sure you've lamented it just as I have. You and I are tourists, and many around us aren't even that. So when we speak of whether 'we' apply formal rigor to our work? Is it still rigor when there is no discipline? I don't think rigor is something you do on a random Thursday. It's something you do all the time.

So no, 'we' do not _use_ the scientific method. We dabble.

And so when someone like Naur tries to summarize software with a line about theory proving, he's not speaking about everybody. If he were honest he might not even be speaking accurately about himself.

ETA: But he's talking about the long arc, not a single bug fix. That we are circling in on what the actual problem is and feeling it out with code. But since we stop at "if it ain't broke don't fix it", we never actually crystallize the thing we built. We never test the hypothesis we suppose that we have created. We have spot checked this organic thing that never gets pinned down and might actually be DOA. We hope the evidence we are wrong is just 'glitches' or problems with the user's machine. Until someone comes to us with a counter-proof that shows unequivocally that we were wrong.

Which leads to problems like those mentioned in this comment tree.

</comment></comment></comment></comment><comment><USER5> So many times this.

"Clear code shouldn't need comments" \- clear code can make it easy to see _what_ but it can never say _why_. Let me know what corner cases you thought about when you wrote this.

"The comments are in the commit messages" \- almost nobody _ever_ goes looking for them there, they're effectively invisible from `git blame` when they _remove_ lines, people rarely make fine grained enough commits to be able to target specific lines or blocks sufficiently with context.

"Nobody ever updates comments, so they're always out of date" \- don't hire such people. It is an crucial task _resolving_ the meaning of comments to make sure everything still makes cohesive sense. Neglecting to do this will often lead to commits that don't quite grok any subtleties of the original design. Don't make the _reader_ of the code do the job of trying to piece together the scattered history of 5 different people's intentions. Of course, it's also useful to try to keep comments as close to the code in question as possible so that references which need updating are obvious to see.

<comment><USER6> > _almost nobody ever goes looking for them there_

I've seen this claim a number of times and it's always so odd to me. One of my most common activities each day - certainly more common than the activity of writing new code - is reading the commit history for different files. It's always surprising to me to hear that this is an uncommon thing to do.

Edit to add: But I also think comments and documentation of all kinds are good. I don't advocate good commit messages instead of comments, but rather in addition to comments. The more documentation the better.

<comment><USER7> Which tool do you use to view commit messages and revisions for each file? I think one of the reasons this is uncommon is due to lack of tooling (or wide- spread knowledge of them). I'd really like to be able to easily see all the previous commits that affected a specific line while I'm editing code. But I usually have to resort to interacting with git, rather than having something popping up on my screen (I use pycharm and vim regularly).

<comment><USER8> Not the person you were replying to, but in PyCharm:

\- right click on the line number, click Annotate; this gives you the commit date and author in the gutter

\- hover over the date/author name; this gives you the commit hash and message

\- click on the hash itself in the popover; this shows the git commit graph on the Version Control tab

\- right click on the date/author name, click Annotate Revision; this opens up the version committed then, with its git blame in the gutter.

<comment><USER7> That's nice, and setting the options to detect movements really improves it. It'd be nice to see the commit message, rather than the author, without the need to hovering, though.

</comment></comment></comment></comment></comment><comment><USER9> If I had a nickel for every programmer who thought their code was so good it didn't require comments... or thinks somehow that unit tests make up for comments... only to come back years later and have no idea why the logic is working how it is.

<comment><USER10> This was a thing at my last job. The lack of comments always made me cringe. While not every line needs a comment, there's a reason why comments would be useful, especially in security software.

I learned a lot of bad habits there and I'm glad I no longer work there.

Their excuses were literally "no one reads comments" "no one keeps comments up to date" "my code is self documenting" etc.

<comment><USER9> The self documenting one always gets me. It's not like the person has never read code that is difficult to understand.

Yet they think it is just other people who write 'bad' code. Their own code can't possibly be bad. In fact it is so good that it 'documents itself'. It's just a statement that drips with arrogance.

<comment><USER10> Ya, but with a security product there are important considerations and while we commented on areas where we fixed a bug due to something fixable, it was a pain in general.

Decisions maybe don't belong in code but with a security product I feel there has to be some quality level of comments to explain why and how. Someone coming along later can't be expected to be in the authors head and the author won't remember all this stuff years later when it might matter or need to be rewritten.

Such a shit show

</comment></comment></comment></comment><comment><USER11> I agree with most of the points made here, though I think some of the bias toward up-front exhaustive documentation is probably not a good fit for most of the projects I've been a part of. Prototyping often reveals necessary changes due to resources constraints, or to unconsidered corner cases. Documentation needs to be a living thing as much as the code, and I think that pushes you toward documenting within the code more than externally.

One of the more important points the author brings up is that authorial intent and the 'why's of comments are the most important. A corollary I'll bring up to that is that the 'what's should be encoded in tests. Tests can be great documentation, and they have the added benefit of informing developers when the goals of the software is being voided (when they fail).

What has worked for me is conceiving of documentation this way:

\- Design Documents: Historical use only, not to be updated.

\- Readme: intro to project; why it exists, overview of how it's meant to function, how to edit, etc. Tends to be updated when big things change.

\- Code comments: why something exists, what considerations were made in that code's creation

\- Test descriptions and comments: binding goals of previous development to future development

This approach has done a pretty good job of keeping documentation from getting too out-of-sync with code while enforcing basic business objectives, still tilting the balance toward development rather than documentation.

<comment><USER12> This is quite good actually.

I would add that some elements of design are worth keeping up, like a general architectural overview and the details of some things, like state-machines or specific kinds of statefulness.

It can be done in the comments, at the package level, that way developers can keep it up to date without much fuss.

</comment></comment><comment><USER13> A big issue with documenting what the code does is that the code and documentation can very quickly fall out of sync. As this posts says, it's much more useful to document the intent of the code, or _why_ there's this mess of seemingly hacky code (see issues #80681, #82108, #66065).

Also be wary of unit tests that are overly tied to the specifics of an implementation. These can be worse than useless when it comes to changing code. I.e. asking "why are my tests failing?" and finding out it's only because I breathed near the code.

<comment><USER14> System tests too!

The last code-base I worked on had do-everything system tests (with unexpectedly good coverage, I'll admit). They were so slow and passed often enough that I didn't immediately spot flakiness.

I got suspicious when the tests started failing regularly when I added new unrelated code.

</comment></comment><comment><USER15> I've had similar arguments here once or twice. There's so much context that isn't deducible from code.

You rarely need to document the "how" (that much should be evident if the code is well-written) but you absolutely should document the "why" (or, often as important, the "why not": what code _could_ be here but isn't).

<comment><USER16> I agree that you shouldn't document "how", but when I'm reading unfamiliar code, I find I what I miss is "what", not "why".

To my mind, in well-written code each function should be documenting its contract: what it assumes, what it guarantees if that assumption holds.

(And if it turns out that what you'd write is just the function's name and its parameter and return types with a few grammatical particles added, maybe it's OK to omit the documentation.)

Then if you find that in order to do that you have to write a little essay, or you need terminology that doesn't correspond to a named thing in the codebase, or you're repeating yourself in multiple comments, that tells you something you need to put in higher-level documentation.

<comment><USER17> Yes. Floyd-Hoare logic is worth learning about in this sense — a formal system for imperative languages where the rules essentially say "given preconditions X and code Y, if X is true before you run Y, we guarantee Z to be true afterwards". I've never ever ever proven code correct using this formalism, but that way of thinking permeates my every action as a programmer.

</comment></comment></comment><comment><USER18> I think the most reliable thing to see what quirks are load bearing is tests, particularly regression tests. You change something, you break expected behavior, you fix it and you write a test. Now the next person may wonder if some quirk is load bearing, but they'll know for sure when running the regression tests.

Additionally, I'd say naming things, though one of the hardest things we have to do, can go a long way towards explaining the "why". Some programmers I've worked with have a knack for knowing just went to break a giant line into separate lines, giving local variables great expressive names, and all of a sudden the code reads a million times better.

All that being said - I agree with most of the points of the article and do push my teams to do a lot of upfront writing down of designs. These things tend to go stale, but in the moment they're a great tool for fleshing out ideas and sparking discussions.

</comment><comment><USER19> My pathway into software development was through electrical engineering and embedded systems. So I don't know if this applies to other ways into software development as well. But what really stood out to me in the beginning was how useless code comment where. I would almost always see code like this:

      x = 1;      // assign 1 to x
      y = x * 2;  // multiply x by 2

I don't know if it was because they thought electrical engineers needed to be explained everything about code. Or if it was because all teaching material used this style and people just copied it. But I never understood why you would add comments like this, but had to do so anyways otherwise I would not pass my exams.

It took me a while to learn that comments are the tool in which you can express your expectation of what the code should do.

<comment><USER20> Those samples were probably written by someone who had learned how to code in assembly language. In assembly, this kind of comment reminds the reader of the semantic meaning of what is in each CPU register. It could be very useful. Then the person learns C and never drops this habit.

</comment></comment><comment><USER21> It gives me no end to pain that "Comments are lies because they aren't code" is a fad that we're currently suffering through as an industry. For decades prevailing wisdom was that comments were a net benefit, and now in the last few years this trend has become prevalent. How much perfectly-good code is going to have to be rewritten from scratch in 10 years because no one remembers what it does?

<comment><USER22> If no one understands what it does, it's not perfectly good code is it? Of course there are rare cases where code cannot be simplified, made more readable or self explanatory and in those cases comments are vital. But the aim should be for the vast majority of code to be easily readable by humans.

<comment><USER4> Essential versus accidental complexity.

Perfectly good code can be unclear because of the accidental complexity included within it. Memory management, error handling (especially in languages with less expressive type systems), configuring hardware/database/network connections, etc. Those things are important, but they prevent the essential portion of the program from being expressed on its own.

Type systems, a brief example: C versus Ada. Implement a network protocol where the data packet has specific n-bit sized fields with ranges less than the maximum for that size. You can easily do this in both languages. But in C, you'd either need to add bounds checking to all of those fields or risk letting errors propagate. That error handling obscures the essential portion of the program. In Ada, you make a type that is n-bits and only accepts values of the correct range. The errors can still exist in received packets, but the error checking is partially elided from the code because the type system itself can catch it.

There's nothing _wrong_ with the C code, and there's nothing _wrong_ (many will disagree with that) with choosing C to implement the protocol. But it will increase the complexity due to factors beyond the inherent, essential complexity of the network protocol itself.

</comment></comment></comment><comment><USER23> The marketing corollary is that metrics only tell you what happened, they cannot tell why. Yet somehow, entire companies have been built on the promise that they can answer the "why" by looking at the metrics.

</comment><comment><USER24> Relevant: Writing system software: code comments. from [http://antirez.com/news/124](http://antirez.com/news/124) \+ [https://news.ycombinator.com/item?id=18157047](https://news.ycombinator.com/item?id=18157047)

</comment><comment><USER25> I comment my code[0].

I don't particularly care what people think about it.

I will say that I have turned over a _lot_ of code, over the years, and virtually _never_ get asked about what it does. When people ask me about my code, I generally tell them where to look, and contact me if they need explanations.

I don't get contacted, so I guess they could figure it out.

I also tend to write a lot of supporting documentation.

We do have to be careful, though. Documentation can easily become "concrete galoshes"[1], so things like header/auto documents are pretty important.

[0] [https://medium.com/chrismarshallny/leaving-a- legacy-1c2ddb0c...](https://medium.com/chrismarshallny/leaving-a- legacy-1c2ddb0c8014)

[1] [https://medium.com/chrismarshallny/concrete- galoshes-a5798a5...](https://medium.com/chrismarshallny/concrete- galoshes-a5798a55af2a)

</comment><comment><USER26> What I've noticed is that code is the only medium of communication that is non-ambiguous. Designers, product people, stakeholders, etc, all use _ambiguous_ mediums. It's impossible to understand just how pedantic and explicit you need to be when writing code versus, say, giving your human colleagues instructions.

So it's 0% ambiguity for code. 100% ambiguity for the rest. In other words, communicating with the computer is overly pedantic, and code bares all the frustration. Can we make it more fair? 70-30 perhaps?

Rather than concentrating on mediums that help with communication (as this post mentions: Design Docs, TLA+, comments…) I want a new medium that allows me share the burden of overscrupulousity with the rest of the people in my team, and not just developers.

<comment><USER27> Pseudocode, perhaps?

</comment></comment><comment><USER28> When I teach coding I tell the students to document their code well but don't document _what_ the code is doing it. That should be evident from the code itself (if it's not, then consider a refactor). Rather, explain _why_ the code is doing it.

</comment><comment><USER29> The counterexample here is the declarative style of programming. Most ideally this looks like an executable spec and is documentation itself.

<comment><USER30> Sure, but then you offload the complexity to the functions used as the declarative building blocks, so you do the documenting in a different place, though you will probably end up documenting complex declarative business logic anyway. (like why is process X that is so similar to process Y require Z different declarative blocks)

</comment></comment><comment><USER31> This article fits nicely with the recent post discussing how Linus spends the majority of his time writing emails. For projects with n+1 contributors, inter-contributor communication is just as important as what code is being written. Emails, commit messages, code comments, docs, are all just different ways to communicate.

I always think of the Underhanded C Contest[^1] as my favorite example of readable code that doesn't act as expected after a quick read.

[1] [http://underhanded-c.org/](http://underhanded-c.org/)

</comment><comment><USER32> If you want your cake and also the ability to consume it, you might want to consider what functional programming can do for you regarding the ability of your codebase to self-document itself. Having type systems that are very closely aligned with the abstract business model is the best way to avoid frustration when you are trying to figure out why something is the way it is.

The trick is understanding that functional vs imperative is a spectrum, and trying to force 100% on one side or the other is how you wind up killing any project. We find that keeping our business-level abstractions functional with the underlying infrastructure code imperative provides the best of both worlds. The code that is changing and analyzed most frequently is in the functional domain, whereas code that we touch maybe 1-2 times per month lives in an imperative domain (but sometimes functional wherever it makes sense here too).

<comment><USER33> I find functional code much shorter and cleaner, but also when you want to change something along a new axis you need to do a much bigger rewrite than with imperative/procedural/object-oriented code.

OO code: "here's a detailed and long-winded description of what happens that's hard to understand. Ignore 95% of it and change that 1 little detail and hope for the best"

Functional code: "here's a concise and easy to understand description of what happens, understand it fully, throw it away, and create a new, just as clear and concise description of what should happen from now on"

</comment></comment><comment><USER34> The huge value that I see in a formal specification language like TLA+ is that we could have a precise way of communicating the problem in a way that is agnostic to the implementation language.

Imagine something like StackOverflow, but instead of posting a question, you post a formal spec. Thinking even further, you could then find a way to combine/interface these specs and build something like a global database of computational problems.

We're currently doing this already with StackOverflow, but we're focusing on the implementations, not the problems themselves.

Please correct me if there's a mistake in this line of thought, I'd love to know.

<comment><USER35> What you're talking about there is a Model Repository. We're building one at the bank I work at, except because our modelling language (or meta model) is based on OMG's MOF we can generate artifacts (code) from our models. You can't do that with TLA+ as far as I know. It's pretty powerful - you can compose models together very easily, as well as generate loads of useful things for data-in-motion.

<comment><USER34> Hey, thanks a lot for your response! It's really hard to search for abstract ideas like this if you don't know the terminology (like Model Repository), so this is super helpful. This is a very interesting topic for me, may I ask you a few questions? I sent you a request on LinkedIn.

</comment></comment></comment><comment><USER36> False. If we used only meaningless symbols like "A", "B", etc. for names, then it would be true. But if I have a method named "addItemToCart", then I know what it _ought_ to do. If it does NOT in fact add the item to the cart, then I've found a bug. It's true that a short method name might not capture all of the subtleties, but usually the variable names within the method can give you an idea of what the intent of the programmer is as well. Obviously there are still things you should write comments for, but really well-thought-out names can get you surprisingly far.

</comment><comment><USER37> About the only time I use comments are to delineate a block of code that for whatever reason can't be a method or because I am working around some bug and I think I might be tempted in the future to remove that code as "useless". (Think "the dispatch_main here ensures that the code runs on the next runloop iteration, which is necessary for the animation to work".)

</comment><comment><USER38> Code is a mixture of what and how (and with IaC, sometimes who and where).

I agree that "why" is the role of documentation. I've been experimenting with tying the two together with (machine checked, automatically surfaced) cross- references, so we can better know what bits of documentation a test supports, &c. I haven't yet gotten rigorous about it.

</comment><comment><USER39> "works as coded"

My last job we used to say that if asked whether our code was correct or bug free ;). Often the devs get thrown under the bus if something doesn't work "correctly" when in reality it might perfectly pass all unit tests based on the best understanding of the problem.

Of course whether we could get any support to help define "correct" from anyone was another matter...

<comment><USER40> This fits my theory of programming, and theory of bugs - We take a problem, create a plan, and then write code that implements that plan.

Defects can come from:

       * having/being given the wrong problem

       * right problem, but plan does not actually solve it

       * right plan, but your code did not correctly implement it

<comment><USER27> Then of course there are the maddening cases of accidental correctness. ie. a bug in your implementation of the wrong plan does the right thing.

</comment></comment></comment><comment><USER41> I'm looking at some ETL code from the dark past, and it uses low-level Db code to shovel in .csv files like a boss.

I'm all' "Well, I guess that code that obtains the .csv files must be rock solid."

Famous last words.

A freshly done system later, I'm left to infer that there had been some other cleansing to to which I was never privy.

</comment><comment><USER42> The "why" can be expressed in code.

Think of "Event Storming". A great way to talk about the "why" and to grow an understanding of how a problem can be solved. The result can be multiple "flows" that describe a series of events from the first command to the expected outcome.

We have the option to directly translate a flow to code. And by keeping the flow in one place, we also keep a direct mapping from our code to the EventStorming-results. The "why" will not be lost. The code can contain multiple flows and every flow can have a scenario-like description like: "the user is able to select a product"

This is what my passion is all about. To keep the "why" in one place. This also enables better collaboration between multiple disciplines (like UX <-> DEV)

This is the idea behind scenario based programming. I am working on an open source project: [https://github.com/ThomasDeutsch/flowcards](https://github.com/ThomasDeutsch/flowcards)

Write me a line if you would like to get involved.

Have you found other solutions for this problem?

</comment><comment><USER43> Should we be looking out for lying code? [https://softwareengineering.stackexchange.com/questions/2023...](https://softwareengineering.stackexchange.com/questions/202352/should- we-be-looking-out-for-lying-code)

</comment><comment><USER44> Here is little demo of codeBERT - [https://youtu.be/oDqW1JHmaYY](https://youtu.be/oDqW1JHmaYY)

codeBERT is trying to predict if a certain function and its docstring are associated or not.

Thought about sharing it, I guess it is interesting in this context

</comment><comment><USER45> Ja to me the "rule-of-thumb" is still: "Code Is The How, Comments Are The Why"

</comment><comment><USER46> Any thoughts on applying this article to...

programming languages defined by a single portable implementation?

</comment><comment><USER47> So.. code is what it is?</comment>