Can We Please Kill This Meme Now - <AUTHOR> http://www.stevenberlinjohnson.com/2006/05/can_we_please_k.html

<comment><USER2> The web is great for serendipity and will eventually leave books lagging far behind in that area (it certainly has done this with respect to library stacks). But nothing will ever replace the sense of excitement one can get from antiquarian books if one is a lover of history and traditional learning.

I have an 1850s 5-volume set of the complete works of Aristotle in 2-column format with the original Greek in the left column and with a complete Latin translation in the second. For a language lover like me, the web has nothing even remotely close to this. There _is_ an inimitable sense of discovery you get as you thumb through pages and compare column to column in a work such as this - a sense of discovery that the web can't begin to match.

I think this has to do with both history and aesthetics. Why was such a work ever printed? What does it say about those who did it? Why all the care to put it in handsome bound volumes? Such factors combine with the unusual nature of the subject matter to enhance the sense of discovery one gets when reading such a work. The web can't do this because it can't provide either the historical sense or the aesthetics.

Now imagine a room full of such works from different times and places spanning the centuries. They do indeed provide an amazing sense of discovery that cannot be matched on the web today.

There is no magic to antiquarian books and there is no need to romanticize them. They are just books. But they can be really fascinating. Serendipity with such books _is_ different from serendipity on the web - it goes beyond content to a sense of discovering how people in different times and places lived and about what fascinated them in their day. Perhaps the web can some day capture this same sense if technologists can devise a way to capture a comparable sense of the intangible elements of time and aesthetics. It does not do so today.

Of course, if one's sense of serendipity turns on the content of the information alone, then these intangible factors are irrelevant, but I think it is artificial to try to separate those intangibles from the content itself when it comes to the pure excitement of discovery..

<comment><USER3> "The web is great for serendipity and will eventually leave books lagging far behind in that area (it certainly has done this with respect to library stacks). But nothing will ever replace the sense of excitement one can get from antiquarian books if one is a lover of history and traditional learning."

I find the serendipity bandwidth of wandering around a bookstore much higher than the Web. The Web, however, is more more available to me. But wandering around the real world has a lot going for it.

</comment></comment><comment><USER4> This is a pet peeve of mine. A fun pastime is to tell a book aficionado, or maybe a librarian how in 20 years all their favorite medium will be obliterated completely and how the likes of them will be dismissed as luddites. Just sit back and relax for the next hour while you listen to an ad- lib essay on why books are so great and how they have "life" and how computers are "mechanical and lifeless", and how staring at a computer screen will surely cause asociality (while of course staring at a book is not likely to). I've even heard people tout that the book experience, from the feeling of the covers to the smell of it, is inexchangeable to that "degenerate computer crap". Overly melodramatic.

Do I really believe that books will come to an end that soon? No way. Much later, maybe. Do I hate books? Not at all, I love them. I own many of them and regularly buy, borrow and read more.

Honestly, I'm sad that these people can't identify with all the change they're being subjected to, but I'm tired of the behavior. If you don't like where everything is heading, that's fine, you're free to keep your old ways but if you're going to grumble on about it, then you better stop swimming upstream and start learning the other way too. Maybe the reason I'm so receptive to change is because I was born into an era of it.

<comment><USER5> A book aficionado perhaps, but not a [real, graduated in L/IS] librarian. Library and information science is basically the study of all the stuff hackers like arguing about—what information is, what is or is not important/redundant information, what metadata is needed to efficiently find something, the value of information in different contexts, the best ways to guarantee the preservation or distribution of information, and so on. Librarians were the first people to use (and espouse) search engines. I'm sure they'd absolutely love it if instead of having a huge library building that had to survive with little funding, taking up city space with books that have mostly never been touched (and therefore have to be culled sometimes—not a happy pastime for a librarian), they could run a small stall that checked out e-ink tablets with the sum of all human knowledge pre-installed, and never worry about conserving space by removing information again.

<comment><USER6> Yes, you must remember that _you_ might think of a library as a building full of books, but to a librarian it's always been a means to an end.

A librarian's job is to archive and retrieve information. For them, having to physically unshelve and reshelve books is not an act filled with nostalgia and romance -- the novelty has long since worn off. Moving books around is a tedious cost of doing business. It's what they make the new interns do. They won't miss it any more than grad students will miss photocopying journal articles. [1]

(God, do you realize how much of my life was wasted lugging giant bound journal volumes around, shlepping them on and off of photocopiers, just because I went to grad school five years too soon? You young whippersnappers don't know how easy you have it!)

\---

[1] With the important caveat that librarians are not at all impressed with the archival quality of electronic media. There's nothing like being handed a truckload of seven-inch floppy disks and being told to preserve the contents for the next 500 years. The job has its challenges.

<comment><USER7> Curiously, I don't think I know of any librarians working at Google. I wonder what they'd think of the zillions of documents at every engineer's fingertips here.

</comment></comment></comment></comment><comment><USER8> Horrible title for actually quite an interesting discussion.

<comment><USER9> Absolutely. He bases it on the analogy of library browsing.

I agree that its a played out symbol. And I'm a librarian.

</comment></comment><comment><USER10> There's quite a bit of serendipity on Wikipedia: <http://xkcd.com/214/>

Almost all Wikipedia articles are within 4 hops of each other. You can open as many tabs as you like, but now you have the choice.

<comment><USER11> > Almost all Wikipedia articles are within 4 hops of each other.

Neat fact, do you happen to have the source? I'd be interested in hearing more on this.

<comment><USER12> I couldn't find anything definitive, but here are some papers on the topic:

<http://mint.typepad.com/mypapers/pp017-lizorkin.pdf>

<http://www.fran.it/articles/wikimania_bellomi_bonato.pdf>

[http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=arnumber=4...](http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=arnumber=4559785)

</comment></comment></comment><comment><USER13> I don't actually think of books so much as I think of browsing stores for actual goods. On the one hand, I have too much stuff (<http://www.paulgraham.com/stuff.html>) on the other hand, I'm far more likely to unexpectedly encounter a useful _and actually buy_ a thing (say a cooking tool) at the mall than online (even something simple, like a quality spatula).

I wouldn't even look at cooking items online. No AI recommendation engines have ever recommended cooking utensils to me that I can remember, and certainly nothing that I was interested in. I've never made a conscious decision to outfit my kitchen, so I've never gone on an online shopping spree for that sort of thing. However, if I walk by Williams-Sonoma in the mall, I may stop in and check out what they've got.

</comment><comment><USER14> People use the net to find a wider array of information than they did before, but they don't go as deep. On the other hand, book readers are much pickier in choosing the topics they delve into. I could probably go through my entire cycle of sites in the time it takes me to pick out a book at Borders.

I'll never forget stumbling across the 17th century tulip craze in a book from my public library. I never heard another word about it until a Matt Taibbi article a couple months ago. On a long enough timeline horizontal browsing intersects with information once reserved for those who dig deep, but how many almanacs would you have to read to know as much as a librarian?

<comment><USER15> Interestingly, the tulip craze was one of the early and more memorable things I've found stumbling the web. I believe some people were comparing it to the dot-com bubble.

</comment></comment><comment><USER16> There is something fantastic though to being stuck listening to crap on the radio and suddenly a wonderful song comes on. Pleasure through forced deprivation.

<comment><USER17> At least in Maine, on commercial stations, I statistically find less moving new music than on, say, thesixtyone. But I tend to appreciate a song most after a few listens, on the album or a mix, and view the radio and (contemporary) web as mainly just a means of discovery.</comment></comment>


SpaceX shows off how we might get to Mars - <AUTHOR> https://techcrunch.com/2016/09/27/spacex-shows-off-its-interplanetary-transport-system-in-new-video/?sr_share=facebook <comment><USER2> I like the way that this is set up to be iterable. Being able to stick the landing on the BFR isn't actually necessary. No reason you couldn't use two rockets to launch the fuel and ship separately.

Beautiful, here's hoping they can pull this off. Best of luck to SpaceX.

</comment><comment><USER3> going live now [https://www.youtube.com/watch?v=A1YxNYiyALg](https://www.youtube.com/watch?v=A1YxNYiyALg)

<comment><USER4> Thanks for the link... I was just right on time when Elon came in :)

</comment></comment><comment><USER5> What I don't quite get is that if we feel like we could figure out how to live on Mars, couldn't we relatively easily figure out how to live on a hot Earth?

<comment><USER6> The idea is to be a multiplanetary species. Not leave Earth for Mars. Plus, it's just really fucking awesome. That alone is enough reason for it to be pursued imo. Exploring and doing cool new things is part of what makes life worth living.

<comment><USER4> We have made our earth worse for habitat, in the name of doing "cool things" and "make life worth living". But still we can live here and find happiness, unlike Mars. Living in Mars and building cities there is wonderful. The project might even succeed completely. But people will find more "emptiness" in space than on earth.

<comment><USER2> > But still we can live here and find happiness, unlike Mars.

This is a wholly unfounded statement.

</comment></comment></comment></comment><comment><USER7> One way trip to Mars. Rightfully so, the first trip to Mars should be one way.

[edit] Presentation is ongoing and there is a return trip. Cool.

<comment><AUTHOR> While we are already trying a hard thing of getting to Mars, why not make an attempt to get back instead of "doing nothing"?

<comment><USER8> Fuel. We have two options to to get back from Mars. Bring the fuel with us or harvest the fuel there. Bringing the fuel is unrealistic, "The bottom line of all these calculations is that you can get about eight times as much stuff to Mars for the same amount of fuel if you send it one-way instead of trying to bring it back!"[1] So let's mine the fuel there. We've never done that. We don't know how long it takes. We have to bring all the equipment in one go, it might even increase the weight of the mission by 8x!

The whole one-way thing is just the easiest. It's no guarantee you're stuck on Mars forever(future flights might be better equipped for return), and it's far simpler than making a guarantee that you won't get stuck on Mars forever.

[1] [http://www.polaris.iastate.edu/EveningStar/Unit7/unit7_sub2....](http://www.polaris.iastate.edu/EveningStar/Unit7/unit7_sub2.htm)

</comment></comment></comment><comment><USER9> Notice the progression of Red, Green, and Blue Mars at the end.

</comment><comment><USER10> Aren't we sorely missing water on mars though?

<comment><USER2> Mars has lots of water. It happens to be locked up as ice, but there's plenty of water on the planet.

</comment></comment><comment><USER11> Duplicate [https://news.ycombinator.com/item?id=12591517](https://news.ycombinator.com/item?id=12591517)</comment>


Netflix tests varying play speeds – and filmmakers are not happy about it - <AUTHOR> https://twitter.com/JuddApatow/status/1188867694474350592 <comment><AUTHOR> I don't see the point of the filmmakers. Nobody will criticize them for a bad film if they don't watch the movie in the intended play speed. Or am I wrong?

</comment><comment> m-p-3 > Leave them as they were intended to be seen.

This kind of feature is present in many other devices and services, like our DVD/Blu-Ray Players, YouTube, etc

Who the hell cares if someone watches a movie on slow-mo or slightly faster? Netflix is merely offering the option, they're not forcing the audience to do anything and it will definitely not be playing slower or faster by default.

Judd Apatow sounds entitled.

</comment><comment><USER2> I'm dismayed that none of the filmmakers see this as the accessibility issue it is. Being able to play at slower speeds can help people with various disabilities. I'd liken this to them being against subtitles.

</comment><comment><USER3> Hang on, haven't broadcast TV channels been doing this for years? Pretty sure all those Saturday reruns are played faster to fit in more ads

<comment> m-p-3 Broadcast TVs are using this to cram more ads in the same timeslot as you said, which is IMO somewhat unethical, as it alters the experience for everyone.

In Netflix's case, they're merely adding the _option_ to do it, they have absolutely no plan of speeding up or slowing down the content by default.

It's as if Judd Apatow didn't read the article he's referring to.

</comment></comment><comment><USER4> I just wish they would fix skipping around in a show or movie, but higher speed playback would make me have to skip less in shows</comment>


Google wins patent on face-to-unlock feature - <AUTHOR> http://news.cnet.com/8301-1035_3-57506457-94/google-wins-patent-on-face-to-unlock-feature/

<comment><USER2> What if I put a picture of someone's face in front of it, will that work?

<comment><USER3> Yes. At least, as-implemented.</comment></comment>


Domain-Oriented Observability - <AUTHOR> https://martinfowler.com/articles/domain-oriented-observability.html <comment><USER2> I hoped from the intro that they would be suggesting an approach that was standard at Google a decade ago, that the rest of the world never adopted.

But no such luck.

However if anyone is creating a distributed product today in 2019, here is an excellent suggestion. Free of charge.

In whatever common code you have for your RPCs, add the ability for an RPC message to be traced. If it is traced, then you will log when it is received, when you reply to it, and also cause all RPC messages you send while handling it to also be traced.

At your front end you can then pick an arbitrary fraction of your traffic, say 1%, and trace it.

Tracing such a small fraction of traffic means that you can instrument it in real time, gather the logs, and create a complete view of how each web request cascaded through your system. And then whenever you run into a slow request that only happens for a small fraction of your traffic you can find a request that was both instrumented and slow, and then dig into those rare problems that happen here and there, then add up.

If you don't do this, then good luck tracking down the performance problems that happen 5% of the time, 3 RPC calls from the front.

<comment><USER3> This is basically what [https://www.jaegertracing.io/](https://www.jaegertracing.io/) / [https://opentracing.io/](https://opentracing.io/) are intended to do. Not sure who widespread they are, but e.g. Uber uses it: [https://eng.uber.com/distributed-tracing/](https://eng.uber.com/distributed- tracing/)

<comment><USER4> In my experience its pretty common? Aside from projects like [https://opencensus.io](https://opencensus.io) a lot of other technologies not primarily about tracing like service proxies (Envoy, linkerd, etc.) also support various types of tracing based on message id's.

</comment></comment></comment><comment><USER5> I've had good success using decorators and infrequently also metaclasses to cleanly solve this type of thing in Python.

However I somewhat disagree with the article in the sense that instrumenting reporting logic is just table stakes bare minimum of software in a business. 90% of business software is about creating a report for somebody somewhere, often needing to be rapidly changed for ad hoc requests from product or management people. Reporting code _is_ the code. It may even _be_ the business logic in a truer sense than the application logic itself.

Another lesson along these lines applies to machine learning and modeling systems: the mathematical algorithm is always the easiest part. The hard part is situation-by-situation customized data ingestion (things that cannot be solved by standardizing on platform-specific data formatting, like Hadoop or Spark), and then also defining business metrics that capture the success of the model at a high level (as opposed to engineering metrics like accuracy, precision and recall, etc).

Model training and the 10% of the project spent tweaking an algorithm or optimizing things just pales in comparison to the type of systems you need to facilitate efficient custom data ingestion that can be arbitrarily different on a per project basis.

</comment><comment><USER6> I'm not a fan of logging errors and returning success codes in lieu of throwing them. It leads to some very nasty support tickets and difficult to debug problems.

There's also a lot of mixed concerns here around in place logging and analytics collection for something that is a very business-logical focussed class.

If you're wanting to do things like this, I'd encourage you to have a look into a message driven Domain driven design structure. It's approach would be:

\- remove all logging and analytics concerns from the class

\- throw errors based on business rule violations, or alternatively publish a failure type message if it's logic path that had compensating actions

\- publish all mutations of the shopping cart as immutable events

\- subscribe to events related to analytics/logic and do that work in a handler, or do it in a higher level application service so the shopping cart just contains shopping cart concerns

A lot of this can be distilled down to basic DRY and SRP principals

<comment><USER7> Returning an error code or throwing an exception result in the same problem. In one case, the error code is ignored. In the other, the exception is swallowed. I bet that monadic binding (as now widespread with the use of promises) can be equally abused.

The problem is in the engineering culture, not the particular tool used.

</comment></comment><comment><USER8> I would rather use Publisher-Subscriber pattern here. Everytime i want to "log", i'll send a "log" event. Publisher doesn't care it'll send to whom, because it's not its responsibility.

</comment><comment><USER9> The examples are interesting in that why is it the Shopping carts responsibility to report the results of the discountService?? If the metrics have to be surfaced, someone, somewhere needs to surface them: and I've been finding it achieves the cleanliness and doesn't break encapsulation when the service (discountService) is responsible for its own hooks, or monitoring adapter. Like mlthoughts2018 i've been finding success using decorators for this because it keeps the domain logic clean of metric/monitoring code:

(shameless plug i recently wrote about how decorators can be used to keep the domain metric/plumbing free)

[https://medium.com/dm03514-tech-blog/designpatterns- consider...](https://medium.com/dm03514-tech-blog/designpatterns-considering- decorators-b4968a8006e8)

(also just disclaimer: Team's i've been on have had lots of success using the approach outlined in the article, injecting a metrics/instrumentation object, it cleans up the domain logic, is easy to provide a stub implementation during tests, and abstracts the from metric implementations.

\</comment><comment>

A decorator version might compose the production code by wrapping the domain logic in metric adapters:

      metrics = InstantiateMetricsClient()

      ObservableShoppingCart(
        ShoppingCart(
           ObservableDiscountService(
             DiscountService(

             ),
             metrics=metrics,
           )
        )
        metrics=metrics,
      )

\----

Another option that I've seen be used successfully is to completely decouple domain events and the surfacing of domain events by having the domain generically emit events, and the logging/metrics subscribe and surface those however it decides.

\----

I feel like for normal logging statements and metrics it only borders on being an issue, but when metrics include many timing wrappers, or when tracing (which involves much more reporting) is involved explicit adapters help to really keep things clean.

</comment><comment><USER10> Fowler just reinvented GoF pattern Observer. There was a reason we called it "pattern", which is now being devalued by a new name for an old thing.

<comment><USER11> Although it's on Fowler's website, it seems this article was written by someone else.

<comment><USER12> Indicated in a panel at the top:

 _Pete Hodgson : Pete Hodgson is an independent software delivery consultant based in the San Francisco Bay Area. [...]_

</comment></comment></comment><comment><USER13> Looking forward to where this article is going. It looks a bit AOP-y to me.

</comment><comment><USER14> Zipkin. You've reinvented zipkin.

<comment><USER15> How is this reinventing Zipkin?

Zipkin looks like a library for collecting and inspecting distributed traces. This post is about how to keep your instrumentation code clean. Unless I missed something while I was reading it, it doesn't say anything about the underlying infrastructure.</comment></comment>


How to Stop Your Smart TV from Spying on You - <AUTHOR> https://www.wired.com/2017/02/smart-tv-spying-vizio-settlement/ <comment><USER2> Step 1: Don't buy a smart TV. Stick with a smart hub and dumb devices.

<comment><USER3> I thought exactly same :)</comment></comment>