< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #11 - May 19, 2019

Here are the top threads of the week, happy reading!

Top comment by aequitas

Makefiles. I always dismissed them as a C compiler thing. Something that could never be useful for Python programming. But nowadays every project I create has a Makefile to bind together all task involved on that project. From bootstrapping the dev environment, running checks/test, starting a devserver, building releases and container images. Makefiles are just such a nice place to put scripts for these common tasks compared to normal shell scripts. The functional approach and dependency resolving of Make allows you to express them with minimal boilerplate and you get tab completion for free. Sometimes I try to take more native solutions (eg. Tox, docker) but I always end up wrapping those tools in a Makefile somewhere forthe road since there are always missing links and because Make is ubiquitous on nearly every Linux and macOS it is just all you need to get a project started.

Example: https://gitlab.com/internet-cleanup-foundation/web-security-...

Running the 'make' command in this repo will setup all requirements and then run code checks and tests. Running it again will skip the setup part unless one of the dependency files has changed (or the setup env is removed).

Top comment by schuetze

Thinking in Systems: A Primer by Donella Meadows

Once you start looking for positive and negative feedback loops in the world around you, it's hard to stop. In particular, Meadow's book is great because it also goes beyond +/- loops in isolation, and shows more complicated patterns, such as eroding goal patterns and traps that often cause public policy interventions to fail.

Top comment by CareyB

Not really. Wix and GoDaddy clobbered it, and now there are others. At one point I had over 30 sites requiring regular maintenance, and upgrades. Plus a few I developed, installed on other servers, and did not maintain. Now I’m down to about four. These days there’s almost always someone in a small business’ office with the requisite skills to do basic upgrades, and small changes. I get called when things go wrong, or there’s a major overhaul in the offing. Many small businesses do quite well with a Facebook page, or some other self development tool. The sites look amateurish, and derivative, but they get the job done. All you want is the ‘Who, what, where, when, and why’, and standards are so low there’s no functional penalty for having a lame Web presence. I find more clients hiring full time ‘social media’ specialists rather than me. I have pondered becoming a ‘social media expert’, but the fact that I have worked building some of the early experiments taints me against the concept.

Almost all Web sites are similar these days, and there’s a value to designing the UI/UX in a way users expect. I suggest that, for startups, and small businesses, there’s virtually no need for anything other than a basic Web presence. With the rise of social media, the appropriate account(s) will solve that problem for most.

I worked through the wild west of this industry, and it was semi-fun, but I think we’ve moved on, things have settled down, or are settling down, and there’s a minimum sufficient requirement for a Web presence that’s pretty freakin’ minimal.

Top comment by phatfish

I have used it as a default for at least 2 years. I'd estimate drop back to Google for 20-25% of specific "subject matter" searches, mostly around technology. Probably a bit less than that for general searches.

Most of the time I run the same search on Google the results are very similar for the top hits. But Google does seem to produce helpful results that are not exactly what I searched for more often.

DDG also skews heavily to US results which is a pain. Any Amazon links are always to .com and not the regional site. Just a general understanding of region specific results seems to be missing, and I end up qualifying searches with the country or town.

Top comment by mud_dauber

If you're looking at this from an architectural perspective, consider grabbing a copy of Hennessey & Patterson's "Computer Architecture - a Quantitative Approach". It covers topics like branch prediction, instruction set design, memory/caching, and so on. A classic.

If you want to get really deep into the physics of IC Design, one of my favorites is "CMOS Design, Layout & Simulation (Baker). It covers spice modeling, physical transistor construction, and a variety of digital/analog/memory circuit concepts.

Finally: the link to this article was literally right underneath the link to yours when I opened HN news this morning: https://medium.com/@veedrac/to-reinvent-the-processor-671139...

Top comment by keithwinstein

Low-latency packet video can work incredibly well over a dependable network connection (with a known constant throughput and no jitter), low end-to-end per-packet latency, and good isolation between everybody's microphone and speaker. This was mostly solved in the 1990s.

A lot of what makes Skype/Facetime/WebRTC/Chrome suck are the compromises and complexity inherent in trying to do the best you can do for when these things don't hold -- and sometimes, those techniques end up adding latency even when you do have a great network connection.

Receiver-side dejitter buffers add latency. Sender-side pacing and congestion control adds latency. In-network queueing (when the sender sends more than the network can accommodate, and packets wait in line at a bottleneck) adds latency. Waiting for retransmissions adds latency. Low frame rates add latency. Encoders that can't accurately hit a target frame size on an individual frame basis add latency. Networks that decrease their available throughput (either because another flow is now competing for the same bottleneck, or the bottleneck link capacity itself deteriorated) cause previously sustainable bitrates to start building up in-network queues, add latency.

And automatic echo cancellation can make audio incomprehensible, no matter how good the compression is (but the alternative is feedback, or making you use a telephone handset).

Another problem is that the systems in place are just incredibly complex. The WebRTC.org codebase (used in Chrome and elsewhere) is something like a half million lines of code, plus another half million of vendored third-party dependencies. The WebRTC.org rate controller (the thing that tries to tune the video encoder to match the network capacity) is very complicated and stateful and has a bunch of special cases and is written in a really general way that makes it hard to reason about.

And the fact that the video encoder and the network transport protocol are usually implemented separately, by separate entities (and the encoder is designed as a plug-in component to serve many masters, of which low-latency video is only one, and often baked into hardware), and each has its own control loop running at similar timescales also makes things suck. Things would work better if the encoder and transport protocol were purpose-designed for each other and maybe with a richer interface between them (I'm not talking about changing the compressed video format itself; just the encoder implementation), BUT, then you probably wouldn't have access to such a competitive market of pluggable H.264 encoders you could slot in to your videoconferencing program, and it wouldn't be so easy for you to swap out H.264 for H.265 or AV1 when those come along. And if you care about the encoder being power-efficient (and implemented in hardware), making your own better encoder isn't easy, even for an already-specified compression format.

Our research group has some results on trying to do this better (and also simpler) in a principled way, and we have a pretty good demo video: https://snr.stanford.edu/salsify . But there's a lot of practical/business reasons why you're using WebRTC or FaceTime and not this.

Top comment by crispyambulance

Isn't that the primary purpose of transactions?

I mean, every time you write to the database, you open a transaction, do you stuff and close it. It either works or it doesn't. If it doesn't, then it rolls back. Isn't that enough?

I guess I am saying that for complex integrity checks, it should be the responsibility of the application's data layer.

On the other hand what is meant by "complex"? Is it "complex" because of numerous, ever-changing applications that touch the database or is it just one application and a database with a lot of tables?

In the case of wild, numerous applications, I suppose that database-side integrity controls are needed. If you really have ONE application touching the database, it might be better to have the application police integrity. Perhaps there's more than one answer?

Top comment by freedomben

It would be really interesting to get a packet capture of what exactly they are sending in the payload.

Some of it may not be tracking, but rather eager loading info. Like each time a call comes in I bet they query the spam call database to see if the number is spam so they can show their warning. I really like that feature. It would be good to know what is really "tracking" and what is not.

Top comment by closeparen

I've been compiling a mental list of things I want to know about a potential team. The code itself is not one of them - too sensitive to get access to, too large and context-dependent to evaluate from an outside perspective. But I do have a bunch:

- How is the physical space, crowding, noise level, workstation quality? How many hours a week do you spend in meetings? How to decision makers think about focus vs. collaboration?

- What is the process by which a proposed code change gets to production, and how long does it take? Code review? Linters? Unit tests? Integration tests? Human QA? CI/CD?

- What is oncall like? How many alerts per shift? Signal to noise ratio? How do you manage incidents? What are postmortems like? Are they about accountability, system hardening, or trying to balance both?

- What are some of the debugging/observability/operational tools you've developed for your product? What are the stories behind them?

- How do decision makers think about tech debt vs. feature velocity? What if any official support is there for getting tech debt items worked on?

- Can I fix & try things on my own initiative in addition to meeting assigned tasks, or must every work hour be dictated by the process/PM? Is an architect telling me exactly how my code has to be structured or am I making my own decisions?

- Where do deadlines come from? How real are they? What happens when a project is looking like it won't meet its deadline?

- What would happen to the business if your team disappeared? What are your current projects and why do they matter?

Top comment by pgroves

Sorry if I'm reading between the lines too much, but 28 cores and 56GB RAM for a business that is not covering it's own cloud costs sounds like a lot of compute resources. Unless maybe you're doing something unusual and have a lot of data when you don't have a lot of users yet. I would try to aggressively cut those numbers, not the price per core, and stay with DigitalOcean if it was me. I've been forced to use cheap, less reliable VMs and it's a huge time waster unless you have a big team and big dev budget to code around it.

You might need to slightly, "prematurely" optimize your computations to get by with less compute power, but if you're broke you're broke. Don't forget that the first few times you really need more compute resources, you can resize production to a bigger machine(s) in 10 minutes and that's not "wrong", even if it's not going to be the long term solution.