skysight-inc/HackerNews huggingface dataset:
On the serverside (which may be "local" depending on where your server is running), the history for the rooms you participate in is stored as a matter of course. Matrix operates by replicating that history between the servers participating in the conversation. If that history is e2e encrypted, any device with the necessary cryptographic ratchet state can decrypt it. (Note that rooms may be configured to change ratchet frequently to deliberately stop history being decrypted multiple times, providing a form of PFS).

On the client side, it depends on the client you're using. Many native Matrix clients and many bridged clients give the option to store local history (whether it was originally encypted or not). Smarter clients will store it encrypted at rest by whatever mechanisms the OS and hardware provides.
It is a very different place today.

And yet this text pops up on the front page of hacker news.

I assume it is because of the events in Dallas; but why discuss this text and not the actual event or a million other things related to the topic of race and racism?
Deaths as Indian troops open fire on Kashmir protesters
Show HN: Bookup App - location-based print book swapping
If new business rules completely invalidate your abstractions in ways that aren't easily fixable, you're doing it wrong. Those wacky pathological cases should just be new implementations that plug right into your existing stuff, even if it requires slightly reworking the abstraction it's better than giving up and duplicating everything. If you're finding duplication easier, it just means you're abstracting things poorly and need to get better at doing it. Mostly likely, you've abstracted too early before you had enough different cases to actually understand how to split the concrete from the abstract correctly.
I understand that this is taboo, but I am utterly baffled as to why I lost karma for this.

Creating a system to traumatise a cat is objectively more harmful than making areas you don't want a cat to go repulsive to the cat.

I've seen the latter method work beautifully with nervous cats, kittens, older cats, etc. Whereas I would have reservations about using the former method with those types of cats because it serves to be startling and traumatic to a cat.
What you should do, when messy business requirements break your pretty abstraction is a) find an appropriate new abstraction, and b) refactor the current code to use the new abstraction. Abstractions aren't forever, they're meant to change and be replaced as appropriate.

Now doing the Right Thing may sometimes require additional work even for a simple (but unfortunately abstraction-breaking) feature. That's why people like to duplicate and then leave things duplicated - because it's the lazy option. You can get some more technical debt in exchange for being done this afternoon. But we all know what happens when you accumulate too much of that debt.
Police are more fearful because their role towards people is often adversarial. They are constantly fed stories about random people shooting at them in broad daylight during routine traffic stops, etc.
You're wrong, and it's because you're cherry picking yet again. Murder is highly race-on-race, and because blacks have a smaller percentage of the population, they only appear to be higher per capita [1].

Of course, since your last comment seems to hint at confirmation bias, I'm sure you'll dismiss any real statistical analysis as "scrubbing".

[1] http://qz.com/556988/here-are-four-charts-on-race-and-murder...
Lots of RPython development can be done in the repl, code can be debugged with pdb. Not nearly as difficult as it is often made out to be.
> Every single one of those rituals has value. Just because you're happy coding quietly, alone, in a darkened room with the door shut, doesn't mean everyone is.

The reverse is also true. Just because a daily standup has value for some doesn't mean it has value for everyone.
> Feels a bit like we are at the tail end of a pretty big macro cycle of tech companies green lighting big initiatives with optimistic mindset and now a few years later the due bill is coming and the bets just didn't pay off.

Exactly my perceptions as well. It seems like VCs and the tech scene in general put growth over profit in a big way for the last 3 - 5 years. That's a fine way to be for a lot of businesses, but my feeling is that companies and the hivemind got a little to comfortable with it, and rather than delaying profits for growth in the short term as an explicit strategy, began to take it for granted as an acceptable way to operate a business in the early days.

The days when "Ramen profitable" mantras abounded and everybody praised 37signals have definitely quieted down, including on HN.

And now it's been long enough that the tide's going out and we're seeing who's still got trunks on.

I don't think the whole thing is going to crash into the ground, but I think "peak easy money" occurred in the past 24 months and has passed. I expect companies to have to work harder to prove they're actually bringing in cash.

IMO, this is just as it should be and the market is correcting for valid reasons.

----

Semi-related anecdote: SF's insane rent prices have mostly plateaued in the last 9 months, especially compared to past growth, and I hear the occasional whisper of them falling. Most news orgs get SF rent prices way wrong (by extrapolating bedroom prices from home purchases, not rentals, for example), but as someone who's lived in the city for a few years and changed apartments annually, I've got a decent calibration for the market. This is a trailing indicator, and to me signals that tech workers are less financially risk tolerant, and perceptions of "my financial situation is stable or poised to improve" are on the decline. Nearly all of my friends express worry over finances, despite making north of 100k.
Grief. I've made a point of actively choosing items sold by (not fullfilled by) Amazon or other sellers I trust for certain types of product specifically to avoid the fake crap.

Surely Amazon must have some clue the damage this is doing to their brand?

Seems time has come to buy from retailers that don't have highly suspect marketplaces intermingled on their sites.
I worked at a place where they would frequently use 'no' as the abbreviation for 'number'. I never could bring myself to do that.
You're arguing against a strawman nobody said blacks were being subjected to de facto police genocide or that they were more likely to be killed by police than anything else. Nobody even suggested those things.
i wonder if Quora is growing or dying?
Flu medication :) In Austria if you have a "Gripperl" doctors prescribe you to spent some time in bed, pharmaconcern infused fear is not at the level as in the U.S. yet.
Not to mention that black slaves were sold to whitey by black Africans.
The stupidest, most counter-productive aspect of all these MOOC systems is the artificial schedule imposed on the course.

I think that comes from imitating "physical" courses, which are designed to be completed in a predetermined amount of time. As the sibling comment alludes to, it also gives some motivation for actually finishing them.
Funny how you tell people to become independent from services, then go ahead and advise techies to set up their own cloud on VPS.
> If new business rules completely invalidate your abstractions in ways that aren't easily fixable, you're doing it wrong.

Why, you might have been doing it right all along. The abstractions were good for old business rules, but are wrong for new business rules. You need to replace your abstractions with better ones. You can't expect to predict future business requirements perfectly 100% of the time; there's no shame in having to rewrite stuff to accomodate changing reality.
That there were Africans involved in the slave trade has no bearing whatsoever on Einstein's argument.
So far, I couldn't find any one that works, but maybe I'm missing something :(
Visual Studio Code 1.3 Release (Now with Tabs)
Basically, hire only programmers who aren't good enough to get a better job.
Those are some super cool stories that you just enthusiastically listed. Thanks.

Do any of these involve anyone other than just you? You know, that offer a comparison and are relevant to the discussion?
It's sometimes actually the best option. We're talking about principles in a vacuum here but I have seen so many tall class hierarchies where now in order to change one isolated feature that shouldn't affect the rest of the system, I'm creating consequences for the whole system.

Decoupling is a more important principle for maintenance than DRY. Obviously you want to factor out common bits of utility code but you absolutely do not want to force all code into the same model.
With some materials changes I can imagine a moving walkway of sorts. However like at the airport it would be a lot more pleasant to use /within/ an at least partially enclosed environment.

Every time I think of this type of topic I wonder how long we're going to leave cities the way they are now. Having at least glassed over streets, separated pedestrian and roadway layers (makes sense when both need more space), and later stopping cars at the border entirely and having a network of the moving walkways within makes sense.
While this should never be the goal, it's really easy to convince me to do this. Give me an impossible problem and the agency and support I need to accomplish it. And finally, actually reward me for success.

Give me a project of busy work or "connecting lego" as we call it, and you'll be lucky if you get that 2-4 hours the responder is referring to.
https://en.wikipedia.org/wiki/Moscow_hostage_crisis_chemical...

"Safe", no. Better than a bomb, absolutely.
As I said: "Every good idea is turned into a bad one by the relentless management quest to Taylorise clue."
Good point

Having read enough appeals cases I will maintain what I mentioned about what prosecutors have discretion over.
Good abstractions aren't about predicting, they're about being nimble so that when change does come along, it's easy, because you don't have a ton of duplication to fix in order to change the abstraction. The new business rules don't belong in the abstraction in general anyway, they belong in the concrete implementations, that's the point of having implementations.
Is it just me or did the author just provide the perfect argument for pattern matching in function calls as seen in Elixir? One can easily split/fork the functionality of the same abstraction depending on the arguments. This preserves the names (which preserves the abstraction), but extends the functionality to adapt to the new use case in parallel, without any dependencies.

Also, by "wrong abstraction", the author is arguing for abstractions to be backed by reasoning, not circumstances a coder might find themselves within code. Duplicate code is not itself reasoning, but a circumstance. Though it can be abstracted away, elimination cannot be the only reason.

This also highlights why more languages need features to help the coder who finds themselves in these situation. Circumstance is a context, and is driven by dependency. Again, dependency is the enemy. We need tools and code that fight it, not cause or encourage it.
> Russian authorities stated that 1,491 people, including 311 children, sought medical attention in Chelyabinsk Oblast within the first few days.
You know what would be AMAZING? If there was a Coursera course (or some other MOOC course, books, etc) that explains how archive.org works from the foundational technologies upwards. So, like, you could build your own mini version of archive.org as an exercise. It'd be a fascinating project and could be a great case study in web archiving techniques and information retrieval. Does anything like this exist already?
What percentage of families in society overall are dysfunctional?
Does anyone here believe that online activity isn't being collected? Imho the only sane thing to do is assume that anything that can physically be captured is being captured, regardless of laws. Therefore, the discussion should instead focus on defeating the physical technological limitations, rather than seeking to apply legal controls.
I disagree, when we industrialize killing and mayhem with seemingly little consequence, nothing good will come out of it.

As for Asimov, I think he was on to something; your milage obviously varies.
> Keep in mind that glaciers always melt. And cause landslides. And new ones form. Been happening for millions of years.

Keep this in mind, from the article:

> Scientists say the slides will most likely continue as warming temperatures cause more glacial melt.

Also, keep in mind that mussel shells were 27% thicker in 1970 than they are now, due to ocean acidification. Keep in mind we just came out of a streak of the 12 hottest months on record, and, lest we feel complacent, that's only because the 13th month was the second hottest on record. Keep in mind that we're about 4 years away from having no glaciers in Glacier National Park.

In the completely neutral spirit of keeping things in mind, keep all those things in mind, too. As a matter of fact, I recommend to you, and to everyone here, go online and find climate-related things to keep in mind.

Thank you for your concern.
Like I said, it's a judgment call on a case by case basis. Taking 'DRY' to an extreme leads to an overly self-coupled code base, taking decoupling to an extreme leads to the need to apply the same fix in multiple places.
There's probably not much constructive discussion to be had on the event here. These are social problems at their roots, not technical ones.
I agree. I my mind, DRY really is not about similar looking lines of code. I think of it as an attempt to strive for a concept-to-implementation-ratio of 1.
The older I get, the less I value "cleverness" in programmers. I used to delight in writing code golf one-liners. But now I realize it detracts from solving the hard problems, and it makes simple problems harder.
I have great admiration for Toyota.

I suspect there are two related reasons:

The first is marginal improvements. Here's a quote from the New Yorker article.

Toyota implements a million new ideas a year, and most of them come from ordinary workers. (Japanese companies get a hundred times as many suggestions from their workers as U.S. companies do.) Most of these ideas are small—making parts on a shelf easier to reach, say—and not all of them work. But cumulatively, every day, Toyota knows a little more, and does things a little better, than it did the day before.

This sounds like to me, an example of Linus's Law: many eyes make all bugs shallow. To put it prosaically, the fuck-up rate will be lower because the gap between expectations and reality is closer.

The second part is with respect to automation. I suspect one of Toyota's secrets is to deliberately introduce redundant workers into processes that are normally fully automated.

This comes out of an observation from the father of economics; that men and women observing a system intimately will gradually conceive of ideas to improve it. A robot or AI cannot do this. They could probably do it if an AGI solved the frame problem but to date that is science fiction.

The net affect of this is that Toyota is smarter than GM on reliability. Of course in a world with rapidly rising salaries Toyota's reliability may lose out over flashier innovations. For now though, it is the King.
Well yes, it would be less damaging for the UK's fintech industry if the government opts to defy the will of a population that voted Out in a campaign dominated by debate over "control of immigration" in order to remain in the Single Market, precisely because all of the harmonised regulation you've claimed is the problem would continue to apply...
The Referendum was non-binding, thus there has been no change to the law as a result of it.

It's also important to note that, IIRC, the Right to Privacy in the Charter of Fundamental Rights stems from Article 8 of the ECHR, thus still part of UK law via the Human Rights Act and has the same scope as specified in the ECHR. Though typically interpreted broadly, it is not a blanket right:

> There shall be no interference by a public authority with [the right to privacy] except such as is in accordance with the law and is necessary in a democratic society in the interests of national security, public safety or the economic well-being of the country, for the prevention of disorder or crime, for the protection of health or morals, or for the protection of the rights and freedoms of others.
> For a long time I've thought that Don't Repeat Yourself is the most important software engineering rule.

It's not. "Don't introduce unnecessary dependencies" and "keep dependency
graph without cycles", "keep things modular" and "all operations in a unit
(function, module, ...) should be from the same abstraction level" are just as
important, if not more, but they're a little more high-level, and thus less
actionable. DRY is just simple to enforce, that's all to it.
Yes, it is. I've made a small HN career of countering this meme whenever it comes up :)

It's a classic form of no-true-Scotsman, but very popular.
You can always abstract away duplicated code after - what you cannot do as easily is fix a bad abstraction. It leads to a world of pain.
they are still the same kind of machine
>I believe a lot of people we now see as noble were just the right person in the right place at the right time, and the more we dig in today, in hindsight, the easier to see their personal flaws.

Noble or not, people have flaws.

What's important about them isn't their flaws (which millions share) but their unique insights (which millions don't share).
These types of situations are very common in "view" and "view controller" classes.

Someone tries to DRY a complex view that handles takes in many options and parameters to address several use cases.

A redesign or requirements change happens and now you have an over complicated view class that needs to get deconstructed. Or you can try and build on top of /subclass/extend an over complicated thing. Neither is ideal.

Reading and understanding code is A LOT harder and time consuming than writing new code. So in reality, this view would just get rewritten (duplicated) anyway.
That's true for all advice, especially in software development.
> Better solution, move the duplicate code into a common abstract superclass. Allow the views to differ where they're concrete and keep the common code abstract in the superclass. Then you can't ever break one implementation by changing another implementation, your core complaint.

And then you suddenly find yourself having a "god object", a class that does huge amount of things and most of them are not related to anything else in the class - they just exist to facilitate code deduplication lower in the inheritance tree.

And then, one page really needs a different version of a behaviour that's common to many of them, and you're back to either duplicating or polluting the "god object" even more.

Inheritance is a bad tool for this problem. It's better to separate different pieces of functionality and then compose them in views. If your view needs a component behaving in a slightly different way, then you can just create a new component (or even subclass the old one, if you must).
Oof, yeah. If what I've experienced is at all indicative, agile and outsourcing mix like nitroglycerin and shaking.
You arw reducing it to Android, the only mobile platform where Java has a meaning.

On iOS, WP, Tizen and anything else Java support is quite worse than having to deal with C++, specially since it is a first class language on those platforms.
Yeah, I saw that. Looks like the shockwaves were the primary mode of injury, though I guess that will always be the primary mode of injury in a large explosion. No deaths that I could see, which is good. I remember seeing the dashcams back then
Its interesting how much sympathy is expected for these people who make a silly little product and have foreign competition, but would a reaction be similar if it was an Amazon Basics product?
You have to read it as "independent from specific services". The scripts configuring my VPS don't care what provider provides the VM below it. Keep a current backup in independent places and you can get your full set of services back up quickly. But of course it is overall more work, not always the same feature set (good and bad), ...
The books and digital videos I get have been great quality.
> I can say that almost all rapists are men. Obviously that doesn't mean that all men are rapists, it means that the probability that a given rapist is a man is very high.

You can't determine the probability of an individual like that, at least without more data. I can say that almost all the people who contract HIV are african american or men who have sex with men, that does not mean that the probability of any given homosexual or black person having HIV is high (greater than 50%). The vast majority of men have never raped a woman and will never rape a woman.
Just Say No to High-Speed Rail
Even for someone who (probably) agrees with you, this is a poor way to argue. "And no, you can't sit there and argue..."? If your own argument is strong --- and, in this case, it should be --- you should have no trouble calmly dismantling rebuttals.

It's weak arguments that demand to be propped up with bogus foreclosures like this.

It's not, however, the flimsiness of your rhetoric that compels me to respond. Rather, it's the implication that merely by reading your comment I must somehow be complicit in an argument that police violence isn't problematic. You probably didn't mean to suggest that literally everyone on this thread disagreed with you on police violence. But that's what you wrote.

I object.
I had no idea this was the case, makes me even warier now. Seems like a fairly big gamble to take with their brand image...most of the knockoff stuff I've encountered has been pretty obviously junk.
Exactly this. At Abebooks[1], they had a Servlet called "AbeServlet" that was duplicated for every new page that needed behaviour. By the time I arrived there were close to 200 different servlets all copied from the same "template". Eventually a new requirement came: we need to support i18n because of a merger with European counter-parts. French, British English, Spanish, and German.

Hundreds of servlets had to change. Took about two weeks of coding by several developers.

When I arrived, I created "AbeMetaServlet" (bad name, but good idea). All my servlets extended from it, as it contained common behaviour. To make my pages i18nized, I changed something like a dozen lines of code and was done in less than an hour--about 16 servlets, if I recall. I didn't know about the upcoming merger. I simply despise duplicating code.

There was another example at that shop where they had processes that started up, ran to completion, then paused until time for the next run. All the batch processes had been copied from a template with no thought to the future.

I was tasked with updating a batch job for associating pictures of book covers with inventory that vendors uploaded. Rather than copy/paste, I rolled my own and fixed a bug. (There wasn't any code that could be re-used, architecturally.) The bug added several hours of run time to the picture maintenance process. The first task each batch job performed was to fetch a list of 10,000 vendor names over an abysmally slow network drive. Undoubtedly this bug was copy/pasted into the other processes.

I re-wrote the code to request the vendor names from the database--and only open up directories for valid vendors. The code, which originally ran in something like 12 hours, was reduced to 8 minutes.

All the batch jobs likely suffered from this error. Including the one that took almost 24 hours to run. Anyone know what happens when a batch job needs more than 24 hours to finish?

Anyway. Had a proper design been developed at the start, one simple change would have made all the batch processes faster.

[1]: http://www.abebooks.com/
Well, this is exactly what the brexiters asked for. Good Jobs becoming available to them.