kyllo

Thanks for the link, this is a good formal description of the one main problem I'm seeing with this type of architecture (undeclared consumers) as well as several others I hadn't thought of.

Right, like no Analysis & Reporting Services on Linux means if you're using it for BI, you're probably still running it on Windows.

Hosting SQL Server has been another common use case for Windows Server for a long time, though it can run on Linux too now.

Mostly because it's generally recognized that inheritance was a bad idea. "Prefer composition and interfaces over inheritance" and such.

Also because mutable object state is problematic--it makes a large system harder to reason about and certan types of bugs more likely, and makes thread safety very difficult.

Yeah, my first two questions were: "Why don't you get the data from the upstream team's API? Have you discussed this design with them?"

It also happened to me once before--a production system took a dependency on one of my streams in the data lake without my knowledge, and no SLA, then when I made a change to it, they came out of nowhere, blowing me up with e-mails and meeting requests. I told them to go pound sand.

Security and privacy risk are also good things to consider, thanks. Our data lake does have processes and protections in place for this (GDPR tagging and deleting, retention policies, security groups for access control) but just because my streams are compliant doesn't mean downstream consumers are.

I interviewed someone who worked in the IT department at one of the largest manufacturers of commercial vehicles, and a mainframe / COBOL shop. He described their development process. It involved printing out your source code, hole-punching the paper, putting it into a three-ring binder, and placing it in the physical inbox on the desk of the person who was assigned to conduct code review.

I had never heard of queueing theory until I read about it in a supply chain management textbook, and would have appreciated being at least aware of its existence much earlier than that. This is light, but it's a great way to introduce the topic to people who have never been exposed to it.

By the way, I also worked in a supply chain management department of about two thousand people for three years and I never heard anyone else mention queueing theory while I was there, so now I really wish at least this blog post were required reading for everyone in that department.

"enforce the verifications across the code" is the point.

I've worked with a ton of Python code that looks like this:

    def foo(bar):
        # do stuff
        return baz(bar)

What does `foo()` return? I have to go read the body (or docstring if I'm lucky) of `baz()` to know that. And `baz()` might be another level of indirection to `quux()`. If I change what `baz()` returns, now I need to grep my codebase for all call sites of `baz()` and verify that the new return type is acceptable at each of them, and make changes if not. This is super time-consuming and error-prone, especially when a compiler (especially with an IDE refactoring tool) could do take care of it for me in seconds. It's easier if I have a good test suite, but that means I'm just implementing static type checking with runtime tests, which is more code that I have to maintain.

You sound smart, but I don't want to have to be that smart when I'm refactoring code. I want the compiler to do as much thinking for me as possible. I want to be able to change it in one place and have type errors to remind me of any other places in the codebase I forgot to change.

Static analysis doesn't solve all your problems, but it solves enough of them to be a very useful technique.

Speaking of TS, here is a good argument for static typing:

>Change a front-end React prop, then follow static type errors through the statically typed API, into the backend, all the way down into the database where they force a change in the Postgres schema. The system won't even compile unless React can talk all the way down to Postgres.

https://twitter.com/garybernhardt/status/1140695491685933060

How would you compare/contrast Retool with Microsoft PowerApps? https://powerapps.microsoft.com/en-us/

(Microsoft employee here, but I don't actively use or work on the PowerApps product myself)

Java and Go today are much better to work with than Java was in, say, the early 2000s, but to realize the productivity boost of a dynamic language within a statically typechecked language, you need type inference and a REPL.

You still don't get this with Java or Go, but you certainly do with ML-like languages (Haskell, SML, OCaml, F# etc.)

A lot of Haskell developers will tell you that writing Haskell feels a lot like a functional Python, and they use Haskell for scripting as well as application development.

core.typed never really caught on though, what seems more popular is Schema which focuses on annotating and validating the structure of lists and maps: https://github.com/plumatic/schema

Groovy is one language that is dynamic but also has an optional statically typechecked compilation mode.

That's debatable, I'm American and would take an offer of a "steak dinner" to literally mean steak. Even presupposing you're correct that it's generally understood by Americans as an idiom, assuming that non-Americans understand American idioms is a form of ignorance, if not deliberate arrogance.

No one's saying "assume they are vegans," we're saying "don't assume they eat meat." Big difference.

Pork is probably even less popular than beef among Indians. At least a lot of the Muslims eat beef, but they don't eat pork. A majority of the Hindus, Buddhists, and Sikhs eat neither.

For real, any corporation employing a significant proportion of Indian people (hell, even non-Indian people too) should be culturally sensitive enough to know that any offer of a morale dinner must feature vegetarian options. This is basic cultural sensitivity and anyone who doesn't understand this has no business managing people.

Only about one-quarter of Indians eat beef, so it's not at all safe to assume that any random group of Indians you encounter will be majority beef-eaters.

Ah you're right, I guess I was thinking of Transatlantic, which is a shorter voyage with smaller vessels.

Something that blew my mind was learning that (depending on oil prices of course), a container ship can burn through up to a quarter million dollars worth of fuel on a single transpacific voyage.

Sure, but building a data center in a metropolis can be a lot more expensive than building it in a rural area because of other factors like higher land values, taxes, energy costs, etc.

The ocean freight for Shenzhen to Lagos probably costs 2-3x more than Shenzhen to Los Angeles, but ocean freight alone is still a tiny fraction of the total landed cost of the data center.

Container ships have internet via satellite today but they use it only when absolutely necessary because it's very slow and expensive. If and when the cost and bandwidth of satellite internet fall to within parameters that make it competitive with fiber optic cable, perhaps.

Microsoft and others are also testing miniature undersea data centers, and using seawater for cooling could help address air conditioning costs: https://news.microsoft.com/features/under-the-sea-microsoft-...

Logistics infrastructure is one major cost factor. To get a data center up and running requires moving large quantities of heavy, high-value, and relatively fragile equipment through ocean ports and over roads and/or railroads. In regions of the world with less quality infrastructure, it's significantly more expensive to transport that stuff.

For the last 6 months or so I've been tracking my time with org-mode in Emacs, and I typically get about 4-5 hours of productive time a day. The rest is taken up by meetings, e-mails, chat, coffee breaks, and task switching overhead.

The time tracking is just for me, I don't share my logs with anyone else. So far I believe it's kept me focused on achieving specific work goals and not getting distracted, leading to more concrete achievements I can cite in my annual performance review.

There are varying degrees of skill and competence in business analytics just like there are in software development.

To put a finer point on it, they'll pay a lot of money for tools that require less-skilled labor to operate. They will gladly spend a lot of money on Tableau to avoid paying the salary premium to have "those who program" build them an analytics system. It costs much less to hire business analysts who don't program (aside from SQL).

The fixation on the nuclear family and its supposed decline, is transparently reactionary ideology. The term "nuclear family" was first used in 1947 and didn't even become the most common form of household until the 1960s or so.[1] Prior to that (and still today in many less-industrialized cultures), cohabitation with extended family and communal parenting arrangements were much more common.

You could just as easily blame capitalism for making people lonely by concentrating lucrative employment opportunities in just a few cities and encouraging young people to uproot their lives and relocate for work.

[1] https://bebusinessed.com/history/history-nuclear-families/

That's a base salary of $136,750 plus stock and bonus. It's a middle-class salary given the high cost of living in the region[1] and the competition for talent. It's also not at all out of line with what investment banks and white-shoe law firms pay their associates.

Meanwhile, I believe younger talent is underpaid across the board in industry. In many cases junior employees make less than half what their more experienced colleagues do, even though the juniors tend to take on more than their fair share of the workload, and they often are relegated to doing the tasks and projects that the seniors don't want.

I think this is mostly based on ingrained beliefs in dues-paying and hazing culture (tendency for existing members of an in-group to exploit the newest members) rather than any empirical measure showing that juniors are that much less valuable from a productivity standpoint.

[1]It's estimated that you need to make north of $200k a year to be able to afford to buy a single-family home in the SF area: https://sf.curbed.com/2019/3/25/18277602/income-buy-home-san...

In a high level language, yes, you should probably refactor code that looks like that. In C, no--just write the nested loop that iterates the pointers over the array, and use break or goto.

The amount of incidental complexity. Reading through their SOAP service spec and coding up a program to interact with it took several times as much effort as coding against a similar REST API would have.