CSS @scope is a new at-rule for natively handling āscopeā in CSS True to its name, it allows you to scope, or limit the reach of your selectors to specific html regions. The idea is that this lets you express ownership of styles that span multiple elements. This has been a long requested CSS feature, and tool like CSS Modules exist specifically for this feature alone. With @scope, you can now do this in native CSS with no tooling
Modern web dev is 3 things:
A theory Iāve had about tech libraries I think since lambda first dropped. You can do stack improvements in 2 ways. Bottom up, where you build on a better solution from the get go, or top down, where you migrate an existing system to a better solution. I think top down is the way to go. It technically reaults in more work involved in migration, but when youāre at that point you can much more objectively evaluate if something like lambda will be a solution that works for you. This is true for so many things in tech, and Iām thinking about it again with stuff like htmx.
Learnings from making a vanilla CSS framework that can compete with the latest JavaScript styling frameworks
Lately there have been a slew of articles coming out either bashing or at least calling into question the current state and direction of React. As someone whoās used React for work and play for quite a long while now (2015)
Iāve been doing a lot of experimentation lately on design engineering, and specifically how to better leverage CSS. This started when I was working on rebuilding my personal site, and I wanted to drastically cut back on the degree of build tools I was using, and try and see how far I could get with just modern vanilla CSS. As it turns out, you can get pretty far these days. CSS custom properties and nesting in particular were the single golden features that allowed me to finally, completely move on from SASS. At first things were great. I followed all the CSS methodologies and techniques I had learned over the years:
In 2024, I've developed an approach to CSS styling that I really enjoy, but also haven't seen done anywhere else. It is built on the following principles
:has() and :where()Something Iāve been thinking about a lot lately while Iāve been working with the Ramda library has been the different kinds of functions there are. In functional programming, there are names for different kinds of functions that share a common use case. I think knowing about them can be a useful thing to know, even if you donāt program in Haskell or the like.
There is no caching layer built-in. All requests, even for static assets, will trigger a separate function call. This has 2 really bad consequences:
Something that came to mind while I was watching a video. The video mentioned how there were opponents to the development of the CIA at the time, and secret government systems in general. I found this very interesting because I always assumed opposition to that sort of thing developed after the fact as a reaction the wrongdoing This is like the third time Iāve run into this phenomena:
This site is first and foremost built around content. I have no formal structure or schedule to my writing. The only general rule of thumb I follow is to lean on the side of writing more, even the insignificant. The getting things done framework talks about getting things out of your head and onto paper, and Iāve found that to be very helpful for keeping my thoughts clear; both as an software engineer who has to keep a lot in brain ram, and as someone with ADHD. The vast majority of my creative writing is done on my phone while Iām on the move; on the bus/train, while walking, or while waiting in line. I tend to do my best thinking while Iām in motion. I do all my writing in a mix of Google Keep and Notion. I primarily use Google Keep out of long-term habit. It was the first note-taking app I got used to all the way back in high school on an old samsung galaxy phone. I discovered Notion in 2017, but for a while the mobile app was fairly complicated and slow on my android phones, which created a lot of friction for me as a largely impulse-driven writer. Nowadayās though I have a modern iPhone and the Notion app has come a long way, so this may change in the future All of the content you see on this site comes directly from my Notion. I consider it my reliable long-term knowledge archive. My Notion is extremely simple, I just use pages and links mainly, no databases or anything of the sort. You can definitely over-organize your Notion if youāre not careful (I have many times), so keeping the structure flat and simple helps me focus more on the content than the tool.
The current with macro sucks because itās impossible to know which function the error is coming from, which makes it harder to know how to handle it.
Build an improved macro that gives you the unintended input, and which function in the sequence it came from
Original Thoughts (not sure when I wrote this):
create function imported like from core import create you could implement the create logic for every type you wanted. Then you wouldn't have to have a million create methods
How I feel now (Aug, 2023):Enum protocol
Something that took me a long time to understand in elixir was when protocols were appropriate to use. Basically, they are a way of defining abstract data types, without being bound to a specific data structure. So they define a type through its behavior, not it's structure
There are 2 examples that really made this sync in for me.
The first is how you can make a queue protocol, and then implement it 2 different ways depending on the underlying struct
The second is how ranges are defined in terms of structs, yet still implement the enum protocol.
The third is how you can invent your own numbers by defining and implementing a ānumberā protocol. A number is anything that supports the āadditionā and āsubtractionā protocols for example. That's a bit contrived, but it helps illustrate the point that you can define something in terms of what it does, just as much as you can define something in terms of what it is
Types are defined in terms of their behavior, rather than in terms of sets of values.
Golang has it right with this. You add both structs and interfaces with the type keyword.
Something that really took me a lot of effort to wrap my head around was the reality that how you model and understand data, and how that data is best persisted, are two distinct concepts and should be handled separately. Often timeās we view the database tables as our source of truth, and write our APIās around the schemaās it provides. The catch is that, as your application getās more complex, you realize that you need to wrangle that schema more and more to fit more complex transformations. This can often lead to over-fetching data, because you only need small pieces of data from a bunch of different tables. Alternatively, database tables, or serializations schemaās to be more broad, should be an afterthought when designing your application. Design with a model first, and then figure out how to best persist it, not the other way around. A good practice Iāve taken to is designing my models to work in-memory first where I have the full freedom of my programming language, and then once the functions are figured out, I get to work on persistence. More often than not I find that the model canāt be perfectly modelled to any particular storage system, so you have to make tradeoffs. But I think this is a good thing, because it forces you to think more about storage solutions in the context of your specific data needs, and less about how to compromise your internal model for the sake of your storage solution. This is the solution to the problem I had when I began working at MP and had to argue about the best storage solution for our company.
When only a single server and database is involved in the application, OAuth2.0/OIDC is overkill. It's easier to just use regular session to control access to your backend API. The primary use case of OIDC is if you need to support enterprise SAML, or if you want other sites to support "Sign up with X" for your service.
Hey, Iām Jacob!!!!!!!! š Today Iād like to talk about Elixir at Discord, but as a larger theme I sorta wanna talk about using Elixir at work, and sorta take you on a journey of how I started using it at work, how itās been, and whether I would recommend it to others. And to illustrate that, Iām gonna be sharing a couple case studies and war stories/campfire stories
Talks/speakers to learn from:
So just by show of hands:
Today is your first day on a content moderation team!
Your first job is to build a content filter so that people who write phrases with bad words are automatically censored.
For example the phrase,
You are a stupid person
Would be censored to read as:
You are a ****** person
An app is just a reducer of the world state and a command Services should just be viewed as opaque data structures. Ex, typeform is just a big dict of workspaces, forms, and responses Wrap all services up as one opaque āworld stateā data structure. Pass this in to all top-level functions. Think of it like the conn/token pattern in elixir Use in-memory data structures to test, effectful one in production Alt, use in-memory handler in testing, live handler in prod
Something I thought about earlier this week that I wanna better wrap my head around is the idea of reactive records, or reactive tables.
The basic idea is that instead of having general handler functions that manipulate a lot of tables all at once, you instead have messages that each table can opt-in to subscribing to. This would mean that update logic is spread out over more non-colocated pieces, but it also means that each update piece is easier to wrap your head around.
Wanna build a little MVP thatās just a thin layer on top of Plug I think a good starting goal is just to use like a To-Do app as an example application
To-Do API spec
Rex!
A simple and intuitive data validation library for Elixir
In all my musings on an independent framework I got hung up on parameter validation.
One of the big things that spawned the idea in me to build my own framework was that I wanted to turn this:
def create_article(conn, %{"author" => author, "content" => content}) do
with {:ok, article} <- Library.create_article(author, content)
endInto this:
Related to the core game loop. For it to be a loop, it needs positive feedback. And that feedback needs to be in service to someone people intrinsically want, ideally without direction. Perfect example is Minecraft. You wanna build stuff. You may not even be that creative, but you at least want a tiny shelter at first. So you go to the mines, get what you want, and build it. But the experience of the mines and of building reinforces your imagination for what you can build. So you wanna go back in the mines, and the loop begins. At MP I think we struggled with this because we started coming up for loops with Checkmate, but couldn't define and build around what people really wanted. It's easy to say insights about their friends, but what kinds of insights? Can it grow? Can it evolve? Can it be sought out without user educa
I feel like the term MVP has really been misused to mean ābuild something that mostly works, and then ship it to see how it faresā. More often than not, Iāve seen this lead to either great ambitions with their foot shot because there wasn't any polish, or projects that are built on rough foundations and fail to innovate over time. Build good shit, just build it small, cut out all the bullshit and just include what's essential and meaningful
A cool example of this I stumbled upon was in Checkmate. In Checkmate, the data structure I try to expose to the client is a graph. And, on the backend I try and represent the entirety of all clients as a graph as well. But I noticed that the client graph may not be a 1-to-1 slice of the server graph.
Through reading about DDD, Iāve learned the power in being self-aware of your teamās language when describing a problem. The terms they use, and more importantly the terms they donāt use, define how they think about the problem at hand. As developers, I think one of our supreme goals and challenges is to build a system that fits that mental model as closely as possible. The language you use defines the API you build
Weāve noticed at MP that 2 weeks isn't a good cycle system for us. It's too short for us to deliver anything we find meaningful. We end up cutting corners and running over, and it's just not a fun experience. We want to experiment with longer time frames to find a better balance between working fast but delivering chunks of work that move the needle
Managers and workers fundamentally have a clash of incentives when it comes to laying out deadlines. Workers are paid regardless of how much value is delivered, so they are incentivized to make deadlines as far away as possible. Managers have to deliver as much value in as short a time as possible, so they are incentivized to make deadlines as short as possible. How do you reconcile this?
I think I prefer my job to be product science, rather than product development. Product science is such a term I vibe with
I've worked with quite a handful of early stage companies at this point, and something I've had religiously beaten into me is the importance of speed. Putting as many good ideas into production as quickly as possible is the key to success, so they say. But I donāt think I've seen any companies do speed right. I think speed is overrated, and what really matters is adaptability, and consistency
Most teamās are pretty good at prioritizing good ideaās over bad oneās. But to succeed in a startup, you need to be able to put the great ideaās, the oneās that will truly catapult your business, over the good ideaās, the oneās that have some growth, but nothing particularly spectacular.
When building products there are often issues that are never urgent, but get progressively harder to resolve for every day they aren't. Migrating a database table is an example. These problems can often cause death via 1000 paper-cuts when left unattended to. So the question is, at what point do you resolve them? I feel like you can learn so much about a company and their culture by how they handle paper cut issues. It speaks a lot to engineer empowerment and whether engineers have an active desire to improve their product. Like do they just solve it, or make a ticket to do it later? This also applys at a larger scale to things like C++ vs Rust. Rust kinda grew due to all the paper cut issues that accumulated over time with C++. But perhaps this is inevitable and just the nature of software. Like nothing can be perfectly designed in realtime, so adapting to change is the priority. And in things like programming languages you cant really ever undo a decision
What do you do as a manager when it is 5PM on a Friday and a critical bug is found? Do you ask someone to suffer by staying late? Or do you let the userās suffer by not fixing the issue until later?
I think all meaning of the term MVP has been lost People need a more concrete way of building and testing ideas The 1-feature-app is a constraint designed to keep scope down, and put more focus on testing
External Validation
External Sources
Another issue that came up in Marriage Pact. We are in the process of building out our first real infrastructure, including a repository to hold user data long-term. Since there was very little existing code, we had full reign over what we wanted our tech stack to be (with the exception that we host most of it on AWS). The first major decision was choice of database. Myself, and 2 other devs wanted to use PostgreSQL. The dev who was largely responsible for our cloud/backend operations wanted to use DynamoDB. This actually turned into quite the heated debate, with solid arguments made on both sides. Unfortunetly, while we were debating, time was ticking, and the eventual solution we arrived at was to go with what the backend dev wanted, despite not really feeling ok with it. I found the exchange really interesting, because it's a conflict I've now encountered on every greenfield project I've worked on, across multiple teams. So the question becomes, how do you solve problems like this in an efficient matter, where both sides have strong arguments, and both sides believe they are correct?
Lots of lessons learned here from Marriage Pact. Talked about Hooked a lot, and made an active effort to design addictive skinner boxes, without any discussion of the ethics. Ethics are a difficult topic to bring up, because choosing not to use these tactics could mean your business fails
Most of my work is in building MVP's and greenfield projects, and the most common technical concern I receive is "Will it scale?". The very mention of that question can spur pretty heated debates. Should we build an Express server, or go with Serverless functions? Do we use PostgreSQL, MongoDB, or DynamoDB? Should we put everything in a vm and scale vertically, or should we Dockerize everything to make horizontal scaling easier? Should we use Ruby+Rails, or maybe Elixir+Phoenix? Should we build our own auth system, or use Firebase Auth? Hopefully I'm not offending anyone by making these comparisons, I realize there may be some false equivalencies since not all projects are the same, and every technology has it's sweet spot. But, many developers have to grapple with questions like this every time they start a new project, myself included. Many teams fear "The Big Rewrite" Very few large companies are still running on the infrastructure they started with.
A lot of companies love to build MORE features to improve the quality of an app. But every feature adds complexity. I think a better approach is to build a feature to evaluate an idea, and then use the feature to evaluate if the idea should be changed, added on top of, or removed
The dream of every programmer is to have their system built like legos. Where all they do is mix and match the legos together to build different things. In reality though we play the role of both the Lego builder and the Lego designer. We not only build legos into different things, we also decide what the pieces are. And it's deciding what the pieces are that really sucks. But something I realized is that, most often when building software systems, we build with big legos first, and slowly make our pieces smaller and smaller over time. Like if we wrote a JSON parsing library, the library would be the one piece. But if we then also needed to support XML parsing, the best idea would be to make a pluggable parser with a JSON and XML module. So we now have more pieces. But what's interesting is that the parser and the json module are now split, despite having the same functionality. Why do we build things that way? Why not start by building with a pluggable parser piece and a JSON plugin piece? I think the answer is that it's usually bad practice to pre-emptively build things in pieces, for 2 reasons:
Early on I felt that having a central place where teams wrote up tasks was the perfect way to do development. But, while I still think that thinking things through is a smart move, I am less persuaded by the centralized write and execute style. Writing operationally-perfect feature specs is draining, and so are executing on them. It makes you feel like a code monkey. Plus, it just doesnāt jive with some people. At MP, we have found that giving individuals the freedom to write their own specs in the way that best suits them to be more effective for our small, rapidly changing product development environment
Something I learned from Evan, but I see it a lot working in startups. It's very emblematic of the wrong startup philosophy, shipping unpublishable work. Every feature published to users should be usable, even in the very beginning
Build loops not tasks. Keep them small. Do nothing else until it's good
Some people say integration tests and unit tests, ive found that that isnt really a good name because it doesnt well convey what im using them for. I prefer specs and tests. Specs are less about verifying correctness of code, and moreso about documenting and keeping track of product features. This enables you to change code internals while knowing if it breaks or conflicts with the previous features you wrote. Tests are about automated debugging, and are the first line of defense. If something in my app is broken, and i have a rough idea of what systems it might be affecting, i can run the test suite on that section of code to start weeding out potential root causes of the issue.
In a perfect world specs could be used as a source of documentation, or a way to generate documentation, but that may be a pipe dream.
Debuggable code is very easy to isolate. Code is easy to isolate when it runs no effects whatsoever, or if it does it only does one, and the effect is the focus of the code
Debuggable code is very transparent. You can know what data is in the system when it fails, so its easy to reproduce later
Debuggable code has easy to understand intent. You can easily build an intuition about how a piece of code should work, so you can quickly discern why the code is deviating from how its intended to function. Related, theres a lot of internet discourse about how to document code, and how it should convey why the code is there, not what it does. (1) if you feel the need to convey what a piece of code does, its a good sign you need to refactor the code, usually but not always by just puting the weird logic in an isolated function with a good name. (2) i think what should be commented is intent; what are you trying to do here. Note, this is different from docstrings or the like, which help consumers understand what a piece of code does. Comments discuss internals
Debuggable code is consolidated. You can see an entire stack of functionality from a single file or folder, and dont have to jump around and understand how a whole bunch of unrelated systems work in order to understand how the faulty system works
Isolate
Expose
Consolidate
Document
Iāve noticed that, from working so much, itās given me a sort of tunnel vision, where I donāt really see myself outside of work. But thereās really a whole world out there outside of what you do. Reading has helped me get rid of the tunnel vision, and be more present in a holistic sense, as a person in the world with infinite opportunity
As an engineer, you take ultimate responsibility for the things you build. You simply cannot hide behind designers and product managers and implement the features asked of you. You need to take ownership, both of the quality and the features
Something I've noticed after many hours of researching software architecture is that good architecture is felt, not seen. Looking at complex DDD folder structures LOOKS like good organization, until you actually try adding a feature and it requires changing like 100 things. By contrast, architecture that looks like a jumble of flat files can actually be very easy to change and organize
The tantamount conventional startup wisdom is to build small and build fast. I donāt disagree with this sentiment, but I do think many companies have run into the āas soon as a metric becomes a goal, itās no longer a good metricā. Many companies expect their team members to work fast, but often it forces them into a position of prioritizing speed above happiness, curiosity, planning, and quality. I prefer the belief that speed is the result, not the rule. If you have a framework for consistently shipping, and your team is healthy, motivated, and inspired, speed will take care of itself. As a leader, if speed is not what you want it to be (and more than likely it wonāt be), I err on the side of first ruthlessly reprioritizing, and if that doesnāt work to hire, and if that doesnāt work to be transparent with the team on where weāre at, and let them know what crunching will and wont get us
Something I've experienced with every remote team I've worked with is the "micro-delay" phenomenon. Essentially, because most (if not all) conversation among remote teams is handled asynchronously (most commonly through Slack), it can take a very long time to make any meaningful decisions. The problem is that any one engagement isn't so long that it's a problem. A reply can usually come within 1 hour, to as long as 1 day. But, these engagements tend to stack on top of each other, meaning it can take upwards of a week to have any meaningful discourse. If the team was fully in-person, this situation would quickly dissolve, as I could easily just go talk to someone and have a quick chat. Part of the problem is that most of the remote teams I've worked on aren't full time, so the in-person solution would only alleviate the problem, not solve it. There are some interesting solutions I've seen implemented that solve this problem. The team at Admiral uses an always-on camera system during working hours. So even though the team is distributed, they are still effectively in the same room with each other. Another solution is "office hours", where team members have no-appointment-necessary timeslots where anyone can stop by and have conversation. I feel like this system is more realistic for part-time teams.
Probably one of the best things I've have noticed while working on Marriage Pact. I've often read that you should build with cross-disciplinary teams, but seeing it in action really gives me a better appreciation for it. When you have people all faced with the same problem, but coming from vastly differing perspectives, they will solve problems in ways each individual contributor would never even think to entertain. I've noticed this most on the product team, where my 2 colleagues come from a more traditional design background (whereas I have a more software-oriented background). There are entire concepts they will throw out simply because they thought it was technically impossible, only to find out it could be done with relative ease. Or moreover, they will simply accept certain hardships in their process because they can't reason about a way to improve it as a designer. And the reverse is true for me as well.
An issue that was presented to us at Marriage Pact. To make a strong pitch for investors, we need to show strong levels of engagement. This has created a push from management onto the product team to come up with ways to engage our audience on a more regular basis. But this creates a problem, because there doesn't seem to be a whole lot of interest from our audience to engage on a daily basis with our product. There is a disconnect between what our investors need, and what our users want. So the question is, are we solving a real problem?
A phenomenon I have noticed among many of my friends and colleagues in college. Resume Driven Development is essentially the theory of learning about and implementing technology based on it's likelihood to land you a job in the future.
Something Iāve noticed over the course of many projects and having worked with many different teams. Giving people individual agency and trust is the way to creating better products. Dictation, where a manager or leader imposes a vision onto others, results in subpar creative thinking, and can really burn out a team. When engineers and designers are reduced to cogs that take some input and are expected to produce some output, they will feel it, and their sense of personal fulfilment and professional investment in an idea will diminish.
Lessons Learned:
A startup cosplayer is someone who looks and acts like the kind of "entrepreneur" you would see in a movie or on Instagram. Although they may want to run a successful startup, their primary motivation for doing so is not to solve a problem, but so they can look, act, and "feel" like a startup founder. You should really be wary of people who are like this. For one, they can poison the mind. I experienced this first hand the first couple years I was in college. I went to a lot of "networking" events, where people in flashy suits talked about how much "business" they were doing. I began to associate the two in my head. To be a startup meant to have the aesthetic of a startup, and to be a founder meant taking on the persona of a startup founder. I think this gave me a lot of insecurity for a while, because my small business was easily forgotten compared to all the big cool things these startups were doing (or rather, were gonna do). But, as I met more and more founders and business owners across the startup landscape, I realized that those people were largely putting on a show. The most successful founders I met didn't look or act anything like what I've been describing. On the contrary, they were less formal, more passionate about their work, and, most importantly, kinder. I've found a good way to tell the difference between someone who is genuinely passionate about their startup, and someone who is performing startup cosplay, is by how wholeheartedly kind they are to people. I've noticed that a lot of startup cosplayers engage in "toxic positivity". You've probably seen what I'm talking about online; its the "I wake up at 2AM to start work and you should too #RiseAndGrind" type. For a time, these people really got under my skin, because from the outside, these looked like the kind of people who were really making it. But, again, most really good people who work in startups don't act like this. There are certainly a lot who wake up early and spend way too many hours working during the day, but there is a difference between having a lifestyle and projecting a lifestyle. I've also found that startup cosplayers tend to be kind in a very transactional sort of way. My favorite example of this is the ulterior-motive-lunch trick. Every few months or so, an acquaintance I've met will reach out with something along the lines of "Hey man, haven't heard from you in a while, would you be down to get lunch later this week and catch up?". When the day arrives, the conversation almost always goes along the lines of this formula: Get food ā engage in small talk, maybe catch up on what they have been dong for work ā "ok, so there is this thing I've been thinking of doing" ā pitch about idea that they want to involve me in. Now to be fair, in isolation I think there is nothing inherently nefarious about this sort of behavior. But, you need to keep an eye on it, because if you find that the only discourse you have with someone pertains to work, they are viewing you less as a person and more as a resource.
See also, Renaissance developers Itās the idea that a software engineer should be product oriented, and have an active hand in the design and direction of a product.
āFeature Factoryā is a more common term for this Basically, itās a belief by management or leadership that the success of a product is a function of itās feature count, which simply isnāt true. Adding more to something can definitely improve it, but it can just as easily do the opposite
Software mileage is one of my favorite ideaās. Early on in a projects development, youāll be faced with an immense amount of decisions to be made about āthe stackā. What programming language do I use, what hosting platform, what frameworks, tools, and libraries. You also may think this when desiring to learn a new tool of the trade, like pick up a new programming language or framework. When youāre in this situation, as I have been in many MANY times, I like to use the āmileageā theory of software usefulness. In essense, the mileage theory is the complexity or difficulty involved with some thing, divided by how long you think youāll be able to use it before you have to replace it. Take for example, PostgreSQL. Postgres is one of the most advanced data management systems ever invented. It will take some time to pick up and learn itās quirks, especially if you donāt know SQL going in. However, once you get a grip on it, Postgres will more than likely serve you for a very long time, even if your project goes to the moon. And moreover, if it doesnāt youāll more than likely be able to apply those skills again to a new project. High skill, but high lifespan, so the mileage is good.
Use Plug as a base
Include time-based API versioning
conn field like sodef create(%Plug.Conn{req_headers: "11-21-22"} = conn, _params) do
# Handle new version
end
def create(conn, _params) do
# Handle old version
endInclude request idempotency
@dataclass(frozen=true), this helps denote that the class is purely for use as a transparent data structure.self but never write to it. Moreover, they should never execute side effectsJust build my existing Cognito solver into a separate package
Use Redix as a base Build basic data wrappers around types Build an improved engine with NIFs
Paul Graham is a bit of a weird dude, especially in recent years, especially on Twitter X, but I do believe he has some good, hard earned wisdom on building products and working with people.
This particular quote Iāve found to be exceptionally true in my professional and personal life:
Demonstration of managed effects in Elixir
Some thoughts and logic on how to do good software architecture and design
The major thing we're trying to do here is separate the DATA from the RUNTIME.
Startup Teams can vary in size from 4 or 5 to well over 100, but must include the following components
TIP: Beware of Fake Progress, actions that may give you more eyes or legitimacy, don't actually move the needle of progress for your team in the near future, and thus shouldn't count as "progress".
Examples include:
The fundamental goal of a startup is to grow it's primary metric