n0w

6 ms·

1.
by n0w 6mo ago
The author seems to have either misunderstood the API they're referencing or are assuming US only addresses. The specific endpoint they're calling seems to be for US specific zip codes. The point stands that this doesn't &qu
2.
by n0w 8mo ago
They're likely trying to retrieve source maps
3.
by n0w 10mo ago
Code is a specification. You cannot have a program unless you specify how it works.
4.
by n0w 11mo ago
This is an interesting idea. I wonder if it's more that we have different "levels" of memory instead of generally "poor" memory though. I'm reminded of an article on the front page recently about the use of blo
5.
by n0w 1y ago
A CRDT is any data structure that meets the definition (associative, commutative, idempotent, etc...) Event Sourcing is not strictly designed to achieve eventual consistency in the face of concurrent writes though. But that doesn't mea
6.
by n0w 2y ago
I think the suggestion is to encapsulate global mutable state behind a strict interface (if you want global mutable state)
7.
by n0w 2y ago
100% The only point from the article I agree with strongly would be putting the keyboard away for a bit and picking up a pencil & some paper and trying out some rough sketches (though I think you can do this just as well at your regular
8.
by n0w 2y ago
The API surface of some struct is determined by visibility, not by whether a member of the struct is a method or a field. I can't remember the specifics for why fields cannot be used within a Go interface but I do remember missing it a
9.
by n0w 2y ago
I can't remember where I picked it up from, but nowadays I try to be mindful of when things are "accidentally" repeated and when they are "necessarily" repeated. Abstractions that encapsulate the latter tend to be a
10.
by n0w 2y ago
This all strikes me as very similar to promise pipelining and distributed capabilities from an OCap system like E. Any code sending an outbound request in reaction to a write is causally related and could be represented as a pipelined promi
11.
by n0w 2y ago
CRDTs seem to give the best experience when they correctly model the "intent" of changes. But a diff between two different states of raw text can't convey the intent of a code change (beyond very simple changes). This is why
12.
by n0w 3y ago
This sounds a lot like letting the monkeys bang away on typewriters while you sit back waiting for Shakespeare... TFA seems to present reasonable advice. Yet lots of comments here don't seem to agree that "give experts necessary c
13.
by n0w 3y ago
These are called "tagged templates": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
14.
by n0w 3y ago
> I don't know why the job postings make the backlog the focus of what they're looking for. I can only imagine that hiring managers and recruiters have a very poor understanding of product management, reducing it to the mere ma
15.
by n0w 3y ago
Maybe you're right. If so, I've only ever worked for companies with leadership that sucked at communicating. I don't think it's that simple though. My personal belief is that leadership rarely has a good reason for obtus
16.
by n0w 3y ago
You've got more than one app sharing a db when you deploy a new version. Unless you're happy with downtime during deploys as the cost of not having to manage how your schema evolves. These kinds of best practices make sense regard
17.
by n0w 3y ago
The more I learn about the relational model from a first order logic perspective, the more I wonder what we would have ended up with if more people thought of data/databases in this way (as opposed to the more record/object school
18.
by n0w 3y ago
I'm not convinced. I don't think products necessarily accrete features because the existing users need them to do more "stuff". Additional features tend to target new/different subsets of users in an attempt to incr
19.
by n0w 3y ago
Oh, hey. That's cool. I hadn't realised Douglas Crawford worked on E. I haven't actually looked but I wonder who else participated? E had some really cool ideas, it's sad that it doesn't seem to be that well known!
20.
by n0w 3y ago
> "knowledge or lack of knowledge does not differentiate..." I agree wholeheartedly. Knowledge, or even intelligence, shouldn't be the most highly valued skill in a team lead. But there are many people extremely confident
21.
An Ode to the Granovetter Diagram(erights.org)
2 points by n0w 3y ago|0 comments
22.
by n0w 3y ago
As someone interested in pursuing similar ideas I would recommend taking a look at Object Capabilities and the E Language if you haven't already. I believe Sandstorm.io (and Cap'n Proto) at least adopts some of the ideas.
23.
by n0w 4y ago
I came across this after seeing relic[0] submitted the other day and thought it was pretty interesting. I've been into CRDTs for a while and have started wondering about generic mechanisms for distributed data. This lead me to read a l
24.
Out of the Tar Pit (2006) [pdf](curtclifton.net)
119 points by n0w 4y ago|66 comments
25.
Linear Logic and Permutation Stacks–The Forth Shall Be First(web.archive.org)
3 points by n0w 4y ago|0 comments
26.
by n0w 4y ago
Thank you for taking the time to reply so thoroughly, this seems like very actionable advice. Sounds like it's going to take a lot of effort to put into practice, but that it'll be effort well spent!
27.
by n0w 4y ago
This is something I really struggle with. I think this difference of perspective is one of my greatest strengths, but in the last few places I've been I ended up burning out trying to get others to see the same things. Have you got any
28.
Dala: A Simple Capability-Based Dynamic Language Design for Data Race-Freedom(arxiv.org)
3 points by n0w 4y ago|0 comments
29.
by n0w 4y ago
I enjoyed the article, but I found the description of taste a bit nebulous. I think part of it is the knowledge and experience you base your expectations/perspective on. I would argue that there is a subjective aspect to taste that is
30.
by n0w 4y ago
> Remember: it’s your job to come up with the solution, not the customer’s. When you go back to ask them questions, ensure you’re not simply asking them to design the solution for you. If they could do that, they’d probably have done it

More ›