Forget monoliths vs. microservices: cognitive load is what matters - <AUTHOR> https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters <comment><USER3> Senior leaders and people that want to get there take note: cognitive load is the base problem one solves for when scaling development organizations. This article is a pretty good introduction -- especially building with empathy and emphasizing "what" over "how". But one can also look to any tech company that provides an API devs like (my fav: Stripe) as an example of what low cognitive load relative to the problem looks like.

Truly talented leaders tend to realize that high cognitive load comes from lots of places besides technical considerations too. It can be hard to think about a problem when you're also dealing with a toxic team member, untrustworthy leadership, lack of organizational focus, shitty HR policies, feeling unsafe at work, etc. Unfortunately, fighting against those elements is a never-ending battle.

Leaders that mix low cognitive load with clear direction and an interesting problem start to approach that highly-sought-after "early startup productivity" that so many companies can't seem to figure out. At least until a re-org, acquisition, or change in the c-suite comes along and blows it all up.

<comment><USER4> This is why people who can't handle too much cognitive load end up being better leaders.

Or in other words... less intelligent people make better leaders.

On a side note, less intelligent people also write more readable code. The principle, Keep it simple stupid, aka kiss is indeed better followed by people who are described by the acronym. So in other words... A simple and stupid person is better at keeping their code and designs simple and stupid than a smart and complicated individual.

<comment><USER5> I respectfully disagree. Simple and elegant code is extremely difficult to write, and the ability to do so is mostly orthogonal to intelligence. However, below a certain threshold of skill and capacity for reasoning about spatial complexity, the developer is much more likely to write confusing, tangled, unnecessary, and verbose code. Reading through a codebase with tons of copy pasted code requires far more effort than a codebase with well designed abstractions. The key phrase there is well designed. What you are describing is someone who know which abstractions to use when and where, and that is a skill that requires lots of experience and technical maturity.

<comment><USER4> I respectfully disagree with your disagreement.

Experience and technical maturity do not equate with intelligence.

Abstractions serve one purpose and one purpose only: to reduce cognitive work load. Any abstraction above a primitive implementation only can offer added inefficiencies . Ex: SQL is less efficient than C++ which is less efficient than assembly. A zero abstraction code base is the usually the most efficient implementation and it will be written in assembly.

So from a technical standpoint, we use abstractions only to reduce cognitive workload because other than that abstractions can only offer inn-efficiencies.

Intelligent people do not put in the effort to learn about or implement proper abstractions because they usually deem it unnecessary to abstract what they perceive to be trivial cognitive workloads..

<comment><USER6> I respectfully disagree with your disagreement of that disagreement.

Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity.

From a technical standpoint efficiency of the code is irrelevant if it's bug- ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python).

If you want to utilize your intelligence to the fullest you abstract away most of the trivial stuff to the point where it pays. You can still go down and inspect or override the abstraction if it's needed. Experience in this case is knowing what to abstract in what manner so it will work for you. Intelligence is the act of keeping everything in a sane state without over-focusing on unimportant stuff.

What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience.

KISS is a suggestion, not a rule. It also applies to abstractions, so in one could argue that doing everything in assembly is actually the "simplest" way of programming, like a rough sketch of a scene is simpler than a full-blown oil painting.

As an aside the whole notion of "intelligence" is a bit twisted with experience IMO. The "classical" IQ applies mostly to dumb pattern matching - <USER2> skill one can perfect. EQ can be trained by getting out and deliberately practicing human interactions.

<comment><USER4> I respectfully disagree with your disagreement of that disagreement of that disagreement.

>Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity.

I am not overlooking anything. The traits you bring up in this statement do offer any performance improvements to the system. Therefore the only other possible benefits that these traits offer is that they reduce cognitive overhead.

>From a technical standpoint efficiency of the code is irrelevant if it's bug- ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python).

Yes. And intelligent people can write more complex code with less abstractions and have less bugs... We agree.

>What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience.

I am not critiquing anything. I have not said anything about my opinion on where or when to add abstractions. I have only commented on how a very intelligent person would do it. I never said I was intelligent... All I said was more intelligent people tend to write less readable code and this can be attributed to the fact that they have less need for abstractions. So no I am not critiquing about when or where to write abstractions.

>The "classical" IQ applies mostly to dumb pattern matching

IQ tests present questions with patterns that the test taker usually has not seen before. A test taker cannot "dumb pattern match" a pattern he has not seen. Therefore the IQ test cannot be testing for "dumb pattern matching." If the IQ test measures IQ and the IQ test is not measuring for "dumb pattern matching" then by concrete logic IQ must not apply to "dumb pattern matching." QED

IQ must apply to something more. A general intelligence.

</comment></comment></comment></comment></comment></comment><comment><USER7> I think the best single observation about cognitive load is in Ousterhout's book A Philosophy of Software Design[1]. In the book he promotes the idea that classes should be "deep", such that their top-level surface API is small relative to the complexity they hide underneath.

This applies to the microservice/monolith debate as well. And it basically boils down to the observation that having lots of shallow services doesn't really reduce complexity. Each service may be simple unto itself, but the proliferation of many such services creates complexity at the next level of abstraction. Having well designed services with a simple API, but hide large amounts of complexity beneath, really reduces cognitive load for the system as a whole. And by "simple API" I think it's important to realize that this includes capturing as much of the complexity of error handling and exceptional cases as much as possible, so the user of the services has less to worry about when calling it.

[1]: [https://www.amazon.com/Philosophy-Software-Design-John- Ouste...](https://www.amazon.com/Philosophy-Software-Design-John- Ousterhout/dp/1732102201)

<comment><USER8> Yes, Ousterhout's work is still a great read decades after he published.

What people forget when doing microservices, server-less, or other 'modern' ways of breaking up software into more or less independent things is that these are just variations of decades old ways of breaking stuff up. Whether you are doing OO, modules, DCOM components, or microservices, you always end up dealing with cohesiveness and coupling. Changing how you break stuff up does not change that. Breaking stuff up is a good thing but it also introduces cost depending on how you break things up.

In the case of microservices, the cost is automation overhead, deployment overhead, and runtime overhead. If your microservice is a simple thing, it might be vastly cheaper to build and run it as part of something else. I've actually gotten rid of most of the microservices and lambdas we used to have to get a grip on our deployment cost and complexity. We weren't getting a lot of value out of them being microservices. The work to get rid of this stuff was extremely straightforward.

<comment><USER9> > In the case of microservices, the cost is automation overhead, deployment > overhead, and runtime overhead.

Having just migrated a software to AWS, and seeing other project being re- engineered as lambdas, I can only related to this.

</comment></comment></comment><comment><USER10> In my experience, communication skills are always the bottleneck.

> But with the coming-of-age of IoT and ubiquitous connected services, we call > them "stream-aligned" because "product" loses its meaning when you're > talking about many-to-many interactions among physical devices, online > services, and others. ("Product" is often a physical thing in these cases.)

Foreboding over IoT is not a strong argument against product teams. Whether it is product teams, streams, microservices, or monoliths: people have limitations on how they can maintain equilibrium and the current set of processes and tools overwhelm it at the cost of productivity.

I agree with the spirit of the argument, but I think it's counter intuitive to suggest "yet another" thought construct based on a premise of under-loading cognitive faculties.

<comment><USER11> As somebody who worked quite a bit on various smaller film sets it always shocka me just _how_ bad people in IT often are when it comes to communicating either within their teams, with their code or with non-IT people.

It certainly got better in some ways, but nowhere near the military precision of a well tuned and experienced film crew.

<comment><USER12> But film crews don't have to invent a vocabulary for each film. The special terms used are all the same.

Developer teams juggle multiple special-purpose vocabularies specific to the technology stack they use, the techniques they employ within the technology stack, the language of the domain they are encoding in software, and the language of the software solution itself.

The set of vocabularies gets expanded or swapped every time you add a person, a technology, or a new project.

Of course we're "bad" at communicating! It's a harder cognitive problem space to convey meaning in.

<comment><USER13> You can absolutely create a culture where there's a shared amount of base concepts though. Communities form in code around those vocabularies - if you have no shared vocabulary you don't have a team, you have a bunch of individuals.

</comment></comment></comment></comment><comment><USER14> This article was initially inspiring and interesting, but eventually I think it is a mud of "sound lies".

I like the idea that human cognition has a huge impact on our lives and it certainly has. But trying to pull off a new pradigm shift on the congnition hype train is annoying.

What is true for me is that even average software and systems we build can get insanely complex. To fix it, it is just suggested to reduce the product size, train / hire people. It is absolutely not wrong, but the narrative is. If we talk about congnitive load we should look at formalism. Yes it sounds awful. But having clear rules of yay's and nay's is when designing and evolving systems can clearly reduce cognitive load, because I cannot remember all the stuff people failed at in history.

PS: Please don't mix up fomalisms with principles.

<comment><USER15> This sounds about right. Also it feels like as a paradigm shift it's not so far from Conway's Law already

<comment><USER16> Conway's law. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other.

[0] [https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

</comment></comment></comment><comment><USER17> Splitting your app up based on "cognitive load" is just as bad a boundary as 100 LOC per microservice. It's an arbitrary measure and varies widely per developer.

The most "correct" way I've ever seen applications divided is based on knowledge domains ala domain driven design (DDD). Drawing boundaries around the domain functionality of your business or operations means that the domain can be ignorant of other parts of your system.

</comment><comment><USER18> This is the issue at the heart of most architecture and language/idiom arguments.

We're meat bags selected for avoiding predators, telling stories around a campfire, and poking things with a stick and we're trying to reason about and craft functioning complex systems. Until the machines take over, the optimal language or architecture will be the one your team can both make sense of and employ with relative ease, full stop.

<comment><USER19> Your reply is exactly what I needed as ammunition to people who don't see how machines can really help us in the future - if you don't mind, I'll paraphrase this comment! Too many people I talk to who aren't computer programmers but maybe, designers or architects who have been to a few conferences, don't believe there is revolution yet to come.

<comment><USER20> I'm a 47 year old programmer who doesn't think a revolution is yet to come because I actually think programming is far more creative in nature than we can ever give to a machine.

Not that there won't be tools to assist the human programmers, but the robot uprising will never occur until we can at least answer the very basic question of _why will the robots care, and how exactly, in some non-hand-wavey fashion, will they get creative about solving novel problems?_

Consider this: You can write a genetic algorithm maker which will randomly iterate through all possible abstract syntax tree morphs and then run a test that evaluates whether the code "performs better" as a solution to some given need, and eventually you might strike upon some novel way of solving a problem through pure randomness. But here's the thing: _The ultimate arbitrator of "what is better" will always be a human and the ultimate agent of "need" is a human as well_. Machines just don't "need" things, like a faster way to ray- trace so your videogame open-world simulation is more immersive, or even a nicer GUI, much less a better way to make money... _People_ need all these things, and _people_ evaluate whether the machine reduces those needs. _Machines_ DNGAF.

<comment><USER21> When people say to me eventually computers will program themselves and I'll be out of a job, I think that'll be the least of our worries, as humans will become redundant.

<comment><USER22> I like to say that programming is the last job that will be automated. To normal people it's a turn of phrase; tech people understand that I'm literally referring to the impending end of life as we know it.

</comment></comment></comment></comment></comment><comment><USER23> Being able to keep the system you are working on in your mind with sufficient but excessive detail is key. Keeping the system in all is parts "as simple as possible and as complex as necessary" (that is my engineering philosophy) is what make se all the difference. I used to think: since I am smart I am going to write something more complex because I can manage that. Wrong. For the smart and dumb engineer a simpler system is faster to build and moreover easier to maintain.

Managing dependencies (briefly mention in the article) is even more important. In a large organization what show you down the most is having to wait for somebody else. Having autonomous teams as much as possible is part of the equation to keep a growing organization able to move fast.

That said everything else being equal (you are writing a good code, you have good engineers, etc), a monolithic system tends to be easier to debug (one stack trace is easier to debug than a trail of logs), the code base is usually easier to refactor.

Where a monolithic system makes things harder is asynchronously deploy different parts of the system and scaling different parts of the system at a different pace.

As a rule of thumb, trying to keep things in one system until it is evident where the cut should be and it is clear it is time to do it help to keep both infrastructure overhead and cognitive overload under control.

But there is no silver bullet.

Check also: [http://www.codingthearchitecture.com/2014/07/06/distributed_...](http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html)

</comment><comment><USER24> I believe one of the main reasons for ending up with a microservice is that you just don't want to implement certain functionality yourself.

If you are running things like sentry, wordpress, mediawiki, keycloak, forums etc and interconnect them in meaningful ways, that is essentially a microservices architecture.

</comment><comment><USER4> This paradigm will be inn-effective in my humble opinion.

It will be because it involves prediction. Cognitive load is unknown. If predicting when a project will complete is hard, predicting how large and where the most cognitive load will be is going to be just as hard if not harder.

<comment><USER21> I think it requires reaction rather than prediction.

</comment></comment><comment><USER25> > Intrinsic cognitive load, which relates to aspects of the task fundamental > to the problem space. Example: How is a class defined in Java?

Article gets this wrong immediately. Intrinsic should be to the characteristics of the feature being developed not about the mechanics of your tools. They are secondary brought in your _solution space_. It bothers me when core terms are misused making it seem not worthwhile to read on.

</comment><comment><USER26> I have found myself tending more and more towards a style where I break even some relatively small modules up into fairly small pieces, and I have very, very clearly specified definitions for "what this module consumes" and "what this module provides". (I have not quite reached "very, very clearly". At the moment I'm still resisting the sheer amount of keyboard typing it takes to be clear. But I can see I'm trending this way.) In essence, take the idea of a dependency-injected function that uses no globals, and bring the same organization up to the module level.

Nominally, languages support this, but a lot of it is still implicit. For instance, do you have a command you can point at a module of your code and get a complete report of A: what libraries this code uses and B: exactly which subset of calls from those libraries this code uses? There's so many languages and environments and IDEs and such out there I imagine the answer may be yes for a few of you, but probably not that many, and even fewer of you use it.

The primary reason I find myself moving this way is to try to make it so you can read a piece of code and the cognitive overhead is minimized, because there's a clear flow: 1. Here are my assumptions. 2. Here is my environment. 3. Here is what I do in that environment. 4. Here are the test cases that show that the thing I wanted to do is in fact done. In current languages, these things are not exactly "all mixed up", but they are not exactly cleanly separated, either.

I realize this may sound vacuous and obvious, but, err, if that's so, a lot more of us could stand to actually _do_ it, to put it in politic terms. I think the languages and environments work against us in a lot of ways by making it very easy to add dependencies without much thought and weave all those concerns together into one big undifferentiated mass.

In the last few weeks, I've had a language coalescing in my head, which I'm not particularly happy about since I have no chance of being able to implement it, and one of the things it does is to encourage this sort of thing by making it easy. Basically, whenever importing a library, it would automatically add a layer of abstraction between your code and that library that allows you to override that library wholesale for testing purposes or something. I do this manually in a lot of languages I work in, but it involves writing a tedious layer that just takes calls to "A" in one side and routes calls to "A" out another. There's an idea of a "context" that you can pass to a module that would do this override. Basically it would be a statically-typed ability to monkeypatch, safely, and in a way where by and large, the compiler could optimize access to the "default" implementation such that you should generally not be paying an abstraction penalty. Then there would be a report that you could use the runtime tooling to generate that would tell you exactly what external functionality you're using, and you could use that to guide you in your override so you only implement what you need.

(I have a mental image of a cell, which being biologic, doesn't really do anything cleanly, but taking it metaphorically, you can see cell walls declaring the things they will allow to pass through, and with only a bit more work we can clearly declare what comes out.)

There are, of course, bits and pieces of this scattered all over the language landscape, but I'm not aware of anything that quite has everything I want in one place. (Perhaps surprisingly, Perl's "local" keyword is the closest single thing I know, albeit not written in a way that can support threading well which I'd want to fix. You can use local to override arbitrary function/method symbols, and it will be scoped within that local only, giving you that "dynamic language" monkeypatching while preventing it from being global state.)

Part of the idea of that report too is that it would be part of the documentation for a module, further increasing the ability to pick up any arbitrary module in a program, and cleanly cut away "look, this is exactly what this particular module does. You may not necessarily know what the other modules this communicates with is doing with that stuff, but at least you know what _this_ module is doing." Again, that may sound like it's a thing that all languages already do when you bring up simplified mental model of a codebase, but think about this next time you're hip deep in code you've never seen before and you hit the thirtieth line of code and suddenly, oh crap, it just referenced another module I've never heard of.... this is when your cognitive load goes through the roof.

<comment><USER27> > I have found myself tending more and more towards a style where I break even > some relatively small modules up into fairly small pieces, and I have very, > very clearly specified definitions for "what this module consumes" and "what > this module provides". (I have not quite reached "very, very clearly". At > the moment I'm still resisting the sheer amount of keyboard typing it takes > to be clear. But I can see I'm trending this way.) In essence, take the idea > of a dependency-injected function that uses no globals, and bring the same > organization up to the module level.

I'm not quite sure how this is different from classes. Visual Studio build out reports on call and data flow so you can easily see what calls what and what dependencies you have. You can also do neat things like see what code is dependent on a given library.

> In the last few weeks, I've had a language coalescing in my head, which I'm > not particularly happy about since I have no chance of being able to > implement it, and one of the things it does is to encourage this sort of > thing by making it easy. Basically, whenever importing a library, it would > automatically add a layer of abstraction between your code and that library > that allows you to override that library wholesale for testing purposes or > something. I do this manually in a lot of languages I work in, but it > involves writing a tedious layer that just takes calls to "A" in one side > and routes calls to "A" out another. There's an idea of a "context" that you > can pass to a module that would do this override. Basically it would be a > statically-typed ability to monkeypatch, safely, and in a way where by and > large, the compiler could optimize access to the "default" implementation > such that you should generally not be paying an abstraction penalty. Then > there would be a report that you could use the runtime tooling to generate > that would tell you exactly what external functionality you're using, and > you could use that to guide you in your override so you only implement what > you need.

C# has this feature and calls it "Microsoft Fakes" but they got a lot of vocal pushback from the TDD community who see great value in adding dependency injection and an interface to every library call you make. But boy is it useful for unit testing legacy code and reducing boiler plate required for testing.

Honestly everything you mention is available on the .NET stack.

<comment><USER26> "I'm not quite sure how this is different from classes."

Well, depending on your definition of classes, I suppose. "A struct bundled together with methods for operating on it + some sort of polymorphism" on its own doesn't say anything about dependency management. But get 10 programmers together and ask for a definition of "class" and you can easily get 15 answers.

"Visual Studio build out reports on call and data flow so you can easily see what calls what and what dependencies you have."

Does it really have a report of exactly what APIs you use out of a module? I'd love to see an example of that if it's not too difficult, not because I disbelieve you, but because I'd love to see it. I know I've seen plenty of flow diagrams for what "libraries" or "modules" you use (whatever word is appropriate to your language), but knowing that you use "the AWS S3 module" is much less informative than knowing "you only use GetObject", to be specific about an example.

"C# has this feature and calls it "Microsoft Fakes" but they got a lot of vocal pushback from the TDD community who see great value in adding dependency injection and an interface to every library call you make."

I am not intimately familiar with this feature, so please do correct me if I am wrong. But I observe that according to this page: [https://docs.microsoft.com/en- us/visualstudio/test/isolating...](https://docs.microsoft.com/en- us/visualstudio/test/isolating-code-under-test-with-microsoft- fakes?view=vs-2019) that for stubs you have to manually create an interface, and for shims you're in a situation where the code is being rewritten dynamically. I would propose making it so that all library usage is automatically an interface type created by your usage. And as it would be implemented in the language spec, rather than being done by instruction- rewrite very late in the process, it would also be something that could be built on by other things.

To be clear A: I'm well aware that I, just like everybody else, do not have any totally unique and new ideas literally never considered by anyone ever, so I am well aware that there are things like this in various bits and pieces elsewhere and B: I'm not exactly "criticizing" the .NET stack, especially with my vaporware-beyond-vaporware ideas. I'm just observing that there is an engineering difference between the things that run as instruction-level rewrites very late in the process and things integrated at the beginning. That's one of the ways Microsoft and Oracle/Java punch above the "weight" of what I'd otherwise expect from the languages in question merely on their features, and a legitimate advantage of being on their stacks, but even for something the size of Microsoft, that's where you have to stop advancing. You can't really build on that sort of tech because you can't stack that many such features together before the complexity exceeds what even those entities can deal with.

(There's also some other features in my highly vaporous vaporware language that this integrates with in some other ways, which is why I'm concerned about needing to be able to build on these features more officially than last-minute assembly rewrites.)

<comment><USER27> I didn't mean to say "look your idea's not unique", hust a hey if your interested in those features I happen to know of some similar features on my preferred stack.

But here's an example of a dependency graph from ndepend(a plugin) [https://www.ndepend.com/docs/visual-studio-dependency- graph](https://www.ndepend.com/docs/visual-studio-dependency-graph) You can break it up by namespace or class(I believe).

> and for shims you're in a situation where the code is being rewritten > dynamically. I would propose making it so that all library usage is > automatically an interface type created by your usage. And as it would be > implemented in the language spec, rather than being done by instruction- > rewrite very late in the process, it would also be something that could be > built on by other things.

Mind explaining the advantage of auto-generating interfaces for library usage over shims? And a couple of other questions, is an interface automatically generated on compile for every exposed class? How does this work for static class usage?

<comment><USER26> Thank you for the example.

"Mind explaining the advantage of auto-generating interfaces for library usage over shims?"

For the particular definition of "shim" used by Microsoft, the fact that it's always implicitly there, rather than something you have to generate and add to the code. For example, if you import the "strings" library and use only "TrimSpace" and "IndexOf", there would be a way to A: have the tooling system directly feed you a listing of "this is what you use from this library/object/etc.", possibly even pregenerating the manifested interface and an initial stub object for you and B: there's a way to coordinate passing your new interface as the implementation of the "string library" that is going to be used for a particular run time context. The compiler can also statically test that your implementation completely covers the module; if you add a call to string.ToLower(), the compiler can complain that your shim is now incomplete.

For static usage, I expect to say that the common use case is that you use the default implementation of the strings library, and in that case, it can be statically compiled as usual. I observe that in practice there's almost always a "real" implementation that is used everywhere except tests. If you're willing to pay the price for dynamic resolution, you'd be able swap out whatever you like during runtime though.

In the common case, I expect it would look a lot like what a modern language does; you say "import string" (somehow), and you just get on with using the string functions. If you don't want to override that, you don't see anything strange.

Languages that already have some similar features would include Python, where a module comes in to your namespace as just another object. In Python it's pretty easy to "duck type" up something that looks enough like a module that you could replace one if you want. I don't see it done often, probably because it's a global variable modification, but it's an example of how you can conceive of a library or module as something other than a completely static import of a static name.

(Hypothetically, you could even get some dynamic overrides to be compiled statically in some cases. There are languages like Rust that successfully do that sort of thing a lot. However, that has a lot of preconditions for it to work, and requires a great deal of sophistication in the compiler. Initially I'd punt; performance is not my #1 goal, and if the implementation just fell back to dynamic resolution it wouldn't be the end of the world. Plenty of languages do just fine with having vtables.)

</comment></comment></comment></comment></comment><comment><USER28> _Broadly speaking, you should attempt to minimize the intrinsic cognitive load (through training, good choice of technologies, hiring, pair programming, etc.) and eliminate extraneous cognitive load (boring or superfluous tasks or commands that add little value to retain in working memory). This will leave more space for germane cognitive load (where "value-added" thinking lies)._

The whole point of design is reducing cognitive load. Whenever you are looking at a given thing, you shouldn't need to keep more than about 10 things in your head to understand it completely, preferably less. Programming hardly ever blows up your brain with one fantastical concept. Instead, you're worn down with a hundred thousand cuts.

</comment><comment><USER29> Microservices are designed differently than monoliths. The architecture _enables_ you to easily do something. Cognitive load isn't what matters, it's the engineering. You can spin microservices up and down to meet demand. You can put them in containers to build an anti-fragile system. You can load balance them. That's much more difficult and more expensive to do with monoliths. The author is thinking of the distinction like an ivory-tower CS professor who thinks he's talking about abstractions, when you're actually talking about design and engineering.

</comment><comment><USER30> Another way of rephrasing Conway's law?

</comment><comment><USER31> This should be the motto for almost everything.

Forget X vs. Y. Cognitive load is what matters.

</comment><comment><USER32> Microservices and monoliths have never been about cog load. Its an implementatiom detail that solves scaling, deployment and team managment problems.

The cog load should be fairly similar weather you jave micro or monolith.

There are good and bad abstractions but in the end the cog load is a sum of the leaves and this never changes in the tree. In fact the cog load is better with bad abstraction , or no abstraction.

Hard coding is no cog load. Its in that file that function for that feature.

</comment><comment><USER33> Unless you have a concrete way of measuring something as abstract as "cognitive load", the situation is as it ever was: the stuff liked by me is low cognitive load; the stuff liked by people who disagree with me is high cognitive load.

(Feel free to sub in "complexity", "cohesiveness", et cetera, for "cognitive load")

<comment><USER34> > Feel free to sub in "complexity", "cohesiveness", et cetera, for "cognitive > load"

"...the situation is as it ever was: the stuff liked by me is rationally oriented by reasonable goals; the stuff liked by people who disagree with me is nothing but a post-hoc rationalization of their arbitrary preferences."</comment></comment>


Confessions of a Serial Conference Attender - <AUTHOR> https://www.linkedin.com/pulse/confessions-serial-conference-attender-charu-jangid?trk=hp-feed-article-title-comment <comment><USER2> the link seems right, but for me it shows a completely different article?</comment>


Microsoft Open Sources WPF - <AUTHOR> https://github.com/dotnet/wpf/commit/ae1790531c3b993b56eba8b1f0dd395a3ed7de75 <comment><USER2> <collective yawn>, the Innovators</comment>


Self-Control in Chimpanzees Relates to General Intelligence - <AUTHOR> http://www.cell.com/current-biology/fulltext/S0960-9822(17)31676-7 <comment><USER2> Small reward now or larger reward later? In real life we might think: why can't I just have _both_?

Yet it frequently _is_ a matter of 'either or' since the smaller reward robs me of the _mental resources_ required to create or bring about the larger reward. For example if I party now I won't get the new job later on because I won't have the energy to learn the relevant skills.

<comment><USER3> You can have both. Invest 10% of your salary each month in a retirement fund, eat out with the rest, net costs like rent. You'll retire a millionaire. You just need to size the rewards correctly.

<comment><USER4> I never understood this... if there was some investment strategy that beat inflation, then if everyone used it, inflation would catch up to it.

So if you invest 10% of your salary all you're doing is saving 10% adjusted for inflation, assuming your investment vehicle doesn't do worse than inflation. And then when you retire you just live off that.

There is no free lunch. In Capitalism, millions of people are in a rat race to survive and eat.

<comment><USER5> > if there was some investment strategy that beat inflation,

There is, stocks average 7% returns after inflation.

> then if everyone used it, inflation would catch up to it.

Inflation is caused by the government printing money faster than the economy grows, not investments.

<comment><USER4> It can be caused by both.

Inflation is a result of a large number of people being able to pay higher prices for the same goods.

<comment><USER5> The act of spending does not create money.

<comment><USER4> That is not relevant to what we were talking about.

<comment><USER5> How do you think money is created?

In any case, no matter how wealthy Fred is, if Fred spends an extra $1000 on X then he has $1000 less to spend on something else. How is that supposed to result in inflation? Spending money doesn't magically put more money in one's pocket (despite wishing it did!), it means you've got less money.

<comment><USER6> Inflation means, afaik, only that the same amount of money has lesser purchasing power than it previously had.

This is an effect that can have various causes. One of them is that the government or Central Banks printed more money. Another way this could happen is if there was an influx of income in your region. This effect is less visible in today's economy with cheap and easy shipping of products, but can still be observed in objects that are pretty much impossible to ship. The only example that comes to my mind right now is housing.

<comment><USER5> > Inflation means, afaik, only that the same amount of money has lesser > purchasing power than it previously had.

That's a tautological definition.

Money's value is determined by supply and demand, just like everything else. If there's more money representing the same amount of goods, the money gets devalued and you have inflation.

To understand inflation one must understand how money is created and destroyed, i.e. what determines the supply of money. Spending money faster does not create more supply, and McDonald's raising their prices is not inflationary because they did not create more money.

Money is created by printing it, or by the creation of debt. Money is destroyed by burning it or by paying down debt.

<comment><USER6> Well, Wikipedia seems to agree with that tautological definition.

While McDonald's alone increasing their price wouldn't be inflation, it could become that if a significant part of the businesses in that location increased theirs as well.

It's just really hard to find examples of this today. It's mostly limited to holiday hotzones, rent and similar.

<comment><USER5> > Wikipedia seems to agree with that tautological definition.

It reminds me of when I saw a technical analyst on CNBC sagely note that the reason the P/E ratio was high was because the Price rose faster than the Earnings. Sheesh!

It is not inflationary if McDonald's increases their prices. Spending more at McDonald's means you have less to spend elsewhere. Your spending does not create more money to replace it.

Consider if the money was a fixed number gold coins instead, and you'll see that anyone raising prices does not result in more gold coins.

<comment><USER6> well, now we've gone full circle.

Inflation does not mean that the amount of money was increased. This is "just" the primary way a government or central bank controls the inflation

The definition of inflation is limited to the devaluement of a currency. This means that it can only be evaluated by comparing that currency to actual goods / services that can be bought / used.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> social interaction gives immediate feedback. So, if your brain(s) are hunting to optimal strategies, being able to do net-present-value in a socialized competition is highly likely to get strong re-inforcement.

net-present-value to determine to plant the yummy seed for a fruit tree later has huge upsides, but demands less strong linkage ("seasons" == delay == plant now eat in 3 years) which I think is probably a product of stronger models of net-present-value than a chimp routinely builds.

the kinds of test they are administering have short cycles. they play to the social interactions chimps experience in the wild.

Try and ask the chimp to deposit into a food-based "pension fund" for its children and mates instead of eating the goodies, and see how many can learn to accrue compound interest</comment>


What We Buy When We "Buy Now" - <AUTHOR> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2778072 <comment><USER2> Companies should not be able to legally use the words "buy" or "purchase" for anything that can have license or access revoked or does not allow transfer of ownership.

<comment> Mountain-Jack Amen to that. It cannot get more misleading than that.

Using the word "buy" instead of "borrow" is done willfully to mislead the consumer as they know that the consumer would otherwise be less likely to enter into the transaction. Buying implies that you have the power of having ownership to a non-exclusive single copy of the work wherein the ownership lies in the ability to command over that ownership (by, for example, giving it to somebody else).

<comment><USER3> You might also argue that people are buying a license and thus "buy" is appropriate.

<comment><USER4> Then it should say "Buy a license now!" rather than "Buy a product now!"

<comment><USER5> It just says buy now. I've never seen a button that said "buy a product now".

<comment><USER6> But it's always next to a picture or description of the product, not a license. That seems pretty misleading.

<comment><USER7> I don't like the whole "own it on Blu-ray and DVD" scheme either. I would love to see the end of copyright and just some sort of compensation for releasing unauthorized private data without any significant public utility but I don't know how to define things like public utility.

</comment></comment></comment></comment></comment></comment></comment><comment> awinter-py Love that when amzn chose a book to 'disappear' off every kindle it was 1984. Talk about testing the waters.

[http://www.pcworld.com/article/172953/amazon_kindle_1984_law...](http://www.pcworld.com/article/172953/amazon_kindle_1984_lawsuit.html)

</comment><comment><USER8> Maybe we need a new word? Something short for "buy a lease like license for an indeterminate time". Halfway between buying and renting. "Brent?"

Ex: "Hey can I borrow your Star Wars movies for a marathon this weekend?"

"Sorry bro, all of mine are brented."

<comment><USER6> How about just "License now!"

</comment></comment><comment><USER9> Url changed from [https://boingboing.net/2016/05/13/clicking-buy-now- doesnt.ht...](https://boingboing.net/2016/05/13/clicking-buy-now-doesnt.html), which points to this.</comment>


HoloJS – A framework for creating UWP applications using JavaScript and WebGL - <AUTHOR> https://github.com/Microsoft/HoloJS <comment><USER2> Very similar to my work here: [https://github.com/lwansbrough/HolographicJS](https://github.com/lwansbrough/HolographicJS) that got no love on HN. :(

But I'm really happy Microsoft has chosen to create something similar - I had hoped they would. Their implementation seems quite solid, I wonder if it supports libraries like Three.js yet.

If anyone is wondering why you might use this, the reason is pretty simple. Before this, there was only two ways to build HoloLens apps: Unity, or C++/DirectX. DX is great but slow to develop, Unity is fast to develop but requires a ton of prerequisite knowledge, and it consumes a ton of RAM. Baseline for this project will probably be similar to mine (around 15MB) whereas Unity's baseline in my experience is around 10x that at 150MB. This is substantial on HoloLens, because the maximum amount of RAM allotted to any application is 1GB.

I'm looking forward to seeing this bring web developers into the new world of MR. I'll be interested to see if this can be coupled with React VR for rapid prototyping.

<comment><USER3> > Very similar to my work here: > [https://github.com/lwansbrough/HolographicJS](https://github.com/lwansbrough/HolographicJS) > that got no love on HN. :(

Yeah, it's only open source if MS/Google/Facebook/Mozilla is doing it.

</comment></comment><comment><USER4> This seems like a lot of work. Couldn't Microsoft just support the WebVR API interface in Edge or some other type of AR extension into Edge? That is all I would want. Then I can just use ThreeJS or Babylon.js with it from a normal website, and then there is no need to ship custom desktop applications with embedded.

I guess I do not want to ship applications if I don't have to.

<comment><USER5> To be honest, I don't want a webapp. Webapps may have a good thirty second use case, but adter that, i want something thatnis with all my other programs that I can pin to a menu/quick launch bar, that runs in a different process space so that a bug in a different program doesn't take down your program, etc. I want the same UI/UX as a native app, and that's something tat webapps still fail terribly at.

<comment><USER6> Those sound like an odd bunch of criteria. I'd go for a list more like:

1\. Performance (either speed of opening if it's the kind of app you open and close a lot) or just responsiveness in use 2\. Quality of user experience 3\. Stability 4\. Cost. 5\. Features 6\. Interoperability

At the moment across a range of app types it's roughly 50/50 between web apps and native apps and I occasionally switch alleigence.

<comment><USER6> Oh silly me for forgetting the markup rules once again. What were those arguments against WYSIWYG again?

</comment></comment></comment></comment><comment><USER7> UWP = Universal Windows Platform, did not know that.

<comment><USER8> LIkewise.

</comment></comment><comment><USER9> How does this relate to the existing Windows support for JS apps via wwahost and the WinRT JS projection? Does that not work on HoloLens for some reason?

<comment><USER2> This uses the same engine, however _that_ host doesn't provide any support for 3D. You wouldn't be able to write WebGL in it, for example. This library exposes a WebGL interface to the JS environment.

</comment></comment><comment><USER10> Interesting. With a little hackery, it should be fairly easy to get this working with PlayCanvas. I'm not sure why it needs to use a new element type though (canvas3D).

<comment><USER11> Canvas does not support all the 3D elements needed for spatial recognition and accessibility via 3D audio. I'm hoping to read through and see canvas3d support that feature.

<comment><USER3> What does Canvas have to do with audio? Web Audio has the necessary components to do spatialized audio. And spatial recognition is an input. Canvas is for output.

</comment></comment></comment><comment><USER12> Wish I had known what UWP was before I clicked the link.</comment>


OS X 11 concept inspired by iOS 7 - <AUTHOR> http://www.ajambrosino.com/os-x-11-concept/

<comment><USER2> Sorry, but it completely escapes me why on earth I should spend good money on a __27 inch __screen when it will be populated with the most basic looking UI elements.

Is there a reason everyone currently thinks an icon does not have to look great anymore? Just make it as flat and non-special looking as possible and you're set.

Is there a reason why it seems like the brightness setting was cranked up to eleven on every icon? The screens are backlid. You can actually see the icons in the dark. They do not need to burn through the screen on their own with the brightest colors known to man.

What would be the next step? The rounded corners on the icons are "too dated looking" Let's just use 90 degree corners everywhere? Microsoft celebrates win after win with that decision, right?

In all seriousness, if you want a simpler look on mobile devices, that's fine. But we just have to look as far as Microsoft to know that a tablet UI on a desktop is a very very bad idea. Not just function wise but definitely user experience wise. If people are hell bend on making their desktop OS that "cute and bright" they should use candybar or maybe Apple should incorporate themes to a point where one could choose to use whatever setting they like best instead of being forced to use the subjectively child like UI of iOS7 compared to the iOS6 one. I don't think one can deny that compared to iOS6, iOS7 with it's candy colors everywhere is looking more juvenile and is clearly targeted to younger people. I don't think a regular grown up or business man using his iPhone daily rejoiced when they saw these bright colored icons everywhere.</comment>


So far, no spike in coronavirus in places reopening, U.S. health secretary says - <AUTHOR> https://www.reuters.com/article/us-health-coronavirus-usa/no-spike-in-coronavirus-in-places-reopening-us-health-secretary-says-idUSKBN22T0HN <comment><USER2> > _... but it was still too early to determine such trends, ..._

It will take around 2 weeks for increased contacts to start to show symptomatic patients, to report "We've re-opened and there's no spike" seems irresponsible, bordering on dangerous.

<comment><AUTHOR> To be fair it's been over three weeks since Georgia reopened (0)

0) [https://www.google.com/amp/s/www.newsweek.com/its-been- one-w...](https://www.google.com/amp/s/www.newsweek.com/its-been-one-week- since-georgia-eased-its-coronavirus-lockdown-reopened-businessesheres- where-1501487%3famp=1)

<comment><USER3> Are the churches open yet? From what I see, Georgia religious leaders (at least from mainstream denominations) are hesitant.

<comment><AUTHOR> I think it's good for people to move at a pace they're comfortable with.</comment></comment></comment></comment>


Enabling IPv6 in Docker - <AUTHOR> https://ungleich.ch/u/blog/how-to-enable-ipv6-in-docker/ <comment><USER2> This is a bit of a tangent, but what is the state of IPv6 in general right now? Can I switch to IPv6 for my home network and use it exclusively?

<comment><USER3> No, sadly not. There are plenty of sites that are not reachable via IPv6 yet. github for example does not work over ipv6.

<comment><AUTHOR> While that is true, you can still fully run your network IPv6 only. At the border router, you can simply use NAT64 to reach the IPv6 Internet.

</comment></comment></comment><comment><USER4> Unfortunately, there is no easy way to enable IPv6 for docker when you have a dynamic IPv6 prefix (home ISP).</comment>


Beautiful new pricing page converting worse - <AUTHOR> https://www.youtube.com/watch?v=7969wChUMiA <comment><USER2> so more information was added when the new page was created? which made it seem like the deal was good for the higher tiers?</comment>


America's Newest Profession: Bloggers for Hire  - <AUTHOR> http://online.wsj.com/article/SB124026415808636575.html

<comment><USER2> He says that there are 20 million bloggers, and 450K are making a living at it, more than there are programmers almost as many as are lawyers. Any of you out there doing better as bloggers than programmers? This HN gig isn't making me rich.

<comment><USER3> my blog pays my rent and food while i work full-time on my startup. so it all works out. :-)

<comment><USER4> Paul I have to say, and I mean this as a compliment ... you're the exception to the rule when it comes to blogging.

Although I do agree with the overall notion that it's easy to make _some_ money with your blog/personal site.

<comment><USER3> well put jose. and it took me 3 years to even get near the point where the blog could pay for more than a cup of coffee each day.

</comment></comment></comment></comment><comment><USER5> "While many bloggers probably support unionization in general, they have no union of their own."

What a preposterous statement to make. "I write a blog, ergo I'm a unionist."

Here's my statement to match: "While not all journalists use sweeping generalizations, most prefer it to any actual research"

</comment><comment><USER4> Blogging is a job like any other, what you actually do differs from coding but the end result can be a decent living either way.

And a lot of hard work, creativity, luck etc.</comment>


Hackers use an ordinary light bulb to spy on conversations 80 feet away - <AUTHOR> https://www.forbes.com/sites/daveywinder/2020/06/14/how-to-use-an-ordinary-light-bulb-to-spy-on-conversation-80-feet-away-security-research-lamphone-hack/ <comment><USER2> Previously discussed here:

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

Reminds me of a 2014 work by MIT on extracting audio signals from vibrations of objects in a video [0] which I found was truly fascinating. I guess someone was paying attention to bring this to production mode out of the lab.

[0] [http://news.mit.edu/2014/algorithm-recovers-speech-from- vibr...](http://news.mit.edu/2014/algorithm-recovers-speech-from- vibrations-0804)

<comment><USER3> Also interesting (though different): [https://en.wikipedia.org/wiki/The_Thing_(listening_device)](https://en.wikipedia.org/wiki/The_Thing_\(listening_device\))

<comment><USER2> What a beauty!

"The Thing" was designed by Soviet Russian inventor Léon Theremin, best-known for his invention of the theremin.

</comment></comment></comment><comment><USER4> That's why those good-ol'-fashioned windowless, inner, Faraday-caged rooms with concrete foundations separate from the rest of the building with their own isolated power-supplies are still probably the go-to place for the paranoid. I remember those in a gov contracting facility in the Boston area -- I'm sure there are more.

<comment><USER5> You forgot the dampened suspension and vacuum/air gap.

<comment><USER6> Let's not get carried away - that's for earthquake / nuclear shockwave protection, not information security.

</comment></comment></comment><comment><USER7> > hooking up an electro-optical sensor to a telescope and pointing it at a > light bulb, but that's the meat and potatoes of the sub $1,000 (£800) > hardware hack at least. Fluctuations in air pressure on the surface of the > hanging bulb are created by the sound of conversation, or music, and make a > hanging bulb vibrate.

Isn't this the same technique used to listen in on a conversation using a glass window?

<comment><USER8> One thing that's not obvious to me from TFA is why an incandescent bulb is called out specifically. It seems to me that a hanging LED bulb would be just as vulnerable, as might a glass chandelier of sorts.

I also wonder whether Christmas trees with hanging ornaments are vulnerable. These are often placed in a prominent window, so it might be quite easy to start listening in on conversations in people's living rooms or business lobbies.

<comment><USER9> >> One thing that's not obvious to me from TFA is why an incandescent bulb is called out specifically.

Because they produce light continuously. An led, CFL, or other will actually flicker at 120Hz.

An incandescent bulb still has 120Hz power going in, but because it depends on heating to produce light and the filament has some thermal capacity, this is largely smoothed out.

<comment><USER10> I have noticed LED bulbs keep glowing for a short period of time after turning them off:

[https://www.quora.com/Why-do-LED-bulbs-keep-glowing-even- aft...](https://www.quora.com/Why-do-LED-bulbs-keep-glowing-even-after- switching-it-off-and-then-they-slowly-dim-out)

I imagine there is still some flicker, but it seems to be smoothed out pretty well on LEDs also.

<comment><USER9> I've seen that too. I think they're using a phosphor of some kind to convert UV wavelengths to visible light. That would have some persistence for those wavelengths.

</comment></comment></comment></comment></comment><comment><USER11> already submitted here, from the real source not the lousy forbes article : [https://news.ycombinator.com/item?id=23498185](https://news.ycombinator.com/item?id=23498185)

</comment><comment><USER12> Source: [https://ad447342-c927-414a-bbae-d287bde39ced.filesusr.com/ug...](https://ad447342-c927-414a-bbae-d287bde39ced.filesusr.com/ugd/a53494_443addc922e048d89a664c2423bf43fd.pdf)

Modern LED fixtures and lamps may be more resistant to this. Who has a hanging incandescent bulb anymore? That being said, a person looking for bugs may not notice a otherwise normal looking hanging incandescent fixture.

<comment><USER13> A lot of bars, cafes, etc use decorative bulbs with thin, easily vibrating wires inside (even though LED-based). I can imagine such a bulb at a home, too.

</comment></comment><comment><USER14> While the title is about lightbulbs this looks like the same principle as using a laser to measure the vibrations on the surface of a window in order to listen to the audio inside a room (something that's been science fact since at least the early 90s). I don't see why the laser or optical sensor couldn't be measuring vibrations of something _inside_ the room: a clear line of sight and a mylar balloon might be the perfect tool for such passive surveillance trick.

<comment><USER8> "Ok, we want to know Raganwald's age. Point a laser at the mylar Happy Birthday balloons and let's listen in on the singing. Take notes! Are you one, are you two, are you three..."

Um, chief?

"Shhh! I'm listening! Are you fifty-one, are you fifty-two..."

Chief!

"Be quiet, damn you. Ok, he just turned 58. Did you get that?"

Yes, chief. I got that. When I pointed the laser at the balloons, I could clearly see a "five" balloon, and an "eight" balloon, and while Raganwald has some very old-fashioned ideas about programming, I don't think he's eighty- five.

"Good work. Now make me another coffee."

<comment><USER15> This is the comment I'd like to end my HN career on. Goodnight for now and very pleasant dreams.

</comment></comment></comment><comment><USER16> This is very unlikely to be practical in any way. Just ask yourself how many times you've seen a lightbulb in the last five years. Sure, you've seen plenty of light fixtures, lots of neon tubes, some LED bulbs, etc, but an old fashioned light bulb, not enclosed in any type of lamp shade?

That aside, how are you going to discretely point a telescope at the light bulb from a distance of 25 meters? You might as well point a parabolic microphone at them and get a better signal.

<comment><USER17> I've seen a fair number of naked lightbulbs in the last few years in hipster restaurants, coffee shops, etc. If done right, it can actually be a pleasing aesthetic.

I think your general point is right though, it's not terribly practical.

<comment><USER18> Half of those are actually LEDs.

[https://en.wikipedia.org/wiki/LED_filament](https://en.wikipedia.org/wiki/LED_filament)

</comment></comment></comment><comment><USER19> A different site, but the topic was posted before (and made to front page): [https://news.ycombinator.com/item?id=23498185](https://news.ycombinator.com/item?id=23498185)

</comment><comment><USER20> We need a device like a mask or helmet which can encrypt our voice before put it to the internet. Just like a VR glasses.</comment>


Naming Methods, Properties and Objects  - <AUTHOR> http://blog.millermedeiros.com/2011/07/naming-methods-properties-and-objects/

<comment><USER2> Really good.</comment>


Sniffing Browser History with No Javascript - <AUTHOR> http://www.making-the-web.com/misc/sites-you-visit/nojs/ <comment><USER2> You can protect yourself against this by disabling a:visited. Here's a Firefox plugin that does it intelligently, without breaking the functionality on sites where you actually clicked a link.

<http://safehistory.com/>

</comment><comment><USER3> This shouldn't be news, since nothing about the original flaw --- which is _years_ old --- involved Javascript.

<comment><USER4> Also, this exact method (css background) was mentioned last time the js version came up on hacker news. How many more times will this be posted?

<comment><USER5> I seem to have missed all the previous times it was posted :-(

I am surprised that the browser try to be smart about loading images defined in the CSS.

</comment></comment></comment><comment><USER6> Great but I would be really interested if someone could demonstrate an application deriving some real world use out of these information. Seen many demos of this browser sniffing but is any one using it for real?

<comment><AUTHOR> it could be useful in targeting ads, i.e. tracking users other website habits to show them much more relevant ads.

Let's say HN has ads. And it sees that you just came from a Python tutorial site. Instead of showing you a random programming book, the ad would show you a series of Python books.

<comment><USER3> Let's say you're a staffer for a Republican congressman, and I'm an innocuous web page you've visited. Oh, look! You've visited a lot of gay pornography sites! I think I'd like you to start paying me $50 a month now, so I can "protect" you from negative publicity.

<comment><USER7> Because a Democratic congressman wouldn't have any political problems whatsoever if found to have visited gay porn sites. :)

<comment><USER3> I didn't give much thought to this example but I think it makes the point OK.

</comment></comment></comment></comment></comment><comment><USER8> If you're upset about this, wait until you hear about Google Analytics...

</comment><comment><USER9> It'd be nice if NOSCRIPT could have an option like: "Don't share my browser history with this site". If that option were on, the page just wouldn't have any 'visited' links at all. I could live with that.

<comment><USER10> There already is a Firefox plugin for that (<http://safehistory.com/>). NoScript, unsurprisingly, is only for _JavaScript_.

</comment></comment><comment><USER10> This inspired me to take the concept even further: <http://news.ycombinator.com/item?id=655101>

This will only work in Opera and Gecko-based browsers.

</comment><comment><USER11> Isn't the utility of the technique watered down by the fact that the attacker has to precompile a list of addresses? Anything not in that list won't be mined.

<comment><USER3> Great, so now there's recurring revenue in it for the business that sells subscriptions to targeted lists.

</comment></comment><comment><USER12> So... this browser thing, actually -is- gathering analytics from anyone who visits it. :P

</comment><comment><USER13> Apparently it crashes Chrome.

<comment><USER14> No crash on Chrome 2 here.</comment></comment>


History of Erlang and Elixir - <AUTHOR> https://medium.com/@Serokell/history-of-erlang-and-elixir-ab54415dbf9a <comment><USER2> Argh. Odd statements about "Erlang was implemented in Prolog, therefore, it's an FP language" aside, I was interested to read more on Elixir's meta- programming, and was assured that this code was a great example[1]. But there was no further discussion, just a Github link.

For anyone else wondering the same, the Elixir docs give more insight into quote/unquote[2]...

...but I'm still unsure as to why the Unicode code uses it. Most of the time it's unquoting byte_size - but why does what looks like a function call need to be unquoted?

It looks like it's defining the same function with different pattern matching clauses using it, e.g.,

      for codepoint <- cluster["CR"] ++ cluster["LF"] ++ cluster["Control"] do
        def next_grapheme_size(<<unquote(codepoint), rest::binary>>) do
          {unquote(byte_size(codepoint)), rest}
        end
      end

Would define next_grapheme_size with an arg pattern that matches each code point, effectively creating a pattern match switch without boilerplating it? I think? Keen to hear from someone who knows Elixir.

But yeah, some more detail on a) what it's doing and b) why it's awesome would've been nice.

[1]: [https://github.com/elixir- lang/elixir/blob/0d32ea6bc4bcbd626...](https://github.com/elixir- lang/elixir/blob/0d32ea6bc4bcbd626de98b2e2b493a42a4423992/lib/elixir/unicode/unicode.ex) [2]: [https://elixir-lang.org/getting-started/meta/quote-and- unquo...](https://elixir-lang.org/getting-started/meta/quote-and-unquote.html)

<comment><USER3> The unquote in your code example doesn't necessarily _need_ to be unquoted, it would be enough to unquote the codepoint variable here. The point, I guess, is about at what point you want to evaluate the code. There is a great little function called Macro.to_string that might make this more clear:

      Macro.to_string(quote do: length([1,2,3]))

will return "length([1,2,3])", so it basically creates a macro that, if included in some code, will calculate the length of the list [1,2,3] at _runtime_.

      Macro.to_string(quote do: unquote(length([1,2,3])))

will return "3" instead, it basically executes the length function at _compile time_ and then the macro will simply return that if called.

So the code example you provided basically calculates the byte size at compile time and will then only return static results at runtime.

<comment><USER2> Thanks! That makes it clearer. So presumably the for loop it's nested in is also evaluated at compile time?

<comment><USER3> Yes, exactly. This code basically runs at compile time and creates functions that return static results. This case doesn't have to be wrapped inside of the quote thing (I'm not even sure if it would compile if you did...), which is somewhat confusing in my opinion.

</comment></comment></comment></comment><comment><USER4> Not a bad article but Phoenix is not "hands down the best web development framework that is out there".

It's quite great at what it does, and it's obviously technically well done, but it's also very not "battery included" so you have to shop around for a lot of things like Authentification/Authorization, i18n etc.

Also templating feels a bit old school. After using extends and blocks with Jinja2 and Twig the "layout that includes your action view" model feels so rigid and limited. It seems you can use render_existing/3 that would be equivalent to content_for in Rails but that's not that obvious to me

It's unfortunate because LiveView puts back server-side rendering on the map and it's exciting.

<comment><USER5> I personally like that Phoenix is kind of a middleweight framework, but at least one of batteries you mentioned as missing is being addressed. José is working on an authentication solution built into Phoenix.

<comment><USER6> Authentication is hard, but to be honest, building your own authorization framework is actually really easy in phoenix. Mine is about 80 LOC, and most of it came from the phauxth generator. Granted the default is rather broad, so I've added a few functions to handle some role specific stuff.

</comment></comment></comment><comment><USER7> elixir is npm for erl.

the single example you need to know to snub it:

       x = 1
       x = 2

thats valid elixir. you're better off using javascript or php at this point

<comment><USER8> that's valid javascript (it's also very dangerous javascript)... and would be valid php if you sandwich it between a $ and a ;

elixir is not npm for erlang, hex is more like npm.

<comment><USER7> elixir is mix. mix is hex.

hence elixir is npm for erlang</comment></comment></comment>


Grundsaudaag Jour de La Marmotte Groundhog Day - <AUTHOR> https://medium.com/@beautyon_/grundsaudaag-jour-de-la-marmotte-ground-hog-day-8570677dd90b

<comment><USER2> Beware anyone who lumps all those who disagree with them into a single group. Beware even more if the person then imputes motives and thoughts to the opponents.

The author spends quite a bit of time calling out opposing arguments as fallacious, but spends the rest of the time either begging the question (bitcoin is great - not saying _why_ bitcoin is great, only saying what nefarious motives underly those who say bitcoin isn't great) or constructing straw men (is there a serious (not fringe) argument that all software everywhere should be under government regulation? I would like to see a reference, please).</comment>


Clear First, Clever Second — Wording your UI  (with slidedeck) - <AUTHOR> http://contrast.ie/blog/the-language-of-interfaces/

<comment><USER2> There are some good examples in this slide deck, but it seems to be lacking a deeper explanation of "why" the author came to each conclusion.

There is a reason companies choose abstract words for their products. If the Wii was still "Nintendo Revolution", it would quickly become un-revolutionary. If Twitter was called "Status" or "Update", they would be narrowly defining their intent for the product. Abstract names don't carry the baggage of a definition.

As an aside: I am coming to hate these slide decks filled with one-liners and little context. Why can't we get a transcript of what the speaker was saying for each slide?

<comment><AUTHOR> You sure can. But I have to go write that up too.

The Why was explained in the talk itself , naturally. The video will be posted

<comment><USER3> destraynor, thanks for the presentation, a lot of good thinking there. Subtle differences between "verbs" and "nouns" of interfaces and cultures they create inside social networking services is one of the reasons that I don't believe in the idea of federated social networks, i.e. sharing superficially similar content "nouns" and "verbs" between social networks.

Waiting for the video of the talk!

</comment></comment></comment><comment><USER4> I hated when Gmail changed "Older" and "Newer" in favor of "<" and ">".

It wasn't "Previous" and "Next", since it wasn't clear, but with the UI redesign they skipped that consideration.

<comment><USER5> Also I hate the "go back to inbox" button that looks exactly like a reply arrow

</comment></comment><comment><USER6> Be sure to click through the slides. The blog post may not be overwhelmingly useful, but the presentation has plenty of helpful examples of interface copywriting done right (and wrong, too).

</comment><comment><USER7> Don't forget proper spelling and grammar. Poor spelling and grammar risk derailing your reader's train of thought.

</comment><comment><USER8> I actually like the idea of a Dribbble for copywriting a lot!</comment>