code that changes together, lives together
indirection is great! one of the best things you can do to look smart is recommend pulling out some shared code and make both sides point at that, this is how i pass job interviews and contribute to meetings i haven't been paying attention to.
it makes the code more complex, but for a good reason.
if you have a program b that consumes data from program a, that is simple:
(data in -> program a -> data out) -> (data in -> program b -> data out
that is great. but later, you learn there is going to be a new program c that
consumes data from program a. it might be a swell idea to pull out code that
is used in both places into a sharedlib, once you notice they are always
changing together.
now you have something more complex! data goes into program a, program a
maybe talks to sharedlib before sending it on to program b and program c
who both talk to sharedlib. indirection! it takes a little longer to track
down where data is being transformed, but you get a benefit in that you can make
a change to sharedlib and it will be picked up by the programs without having
to make a change to all three.
the idea is to make code that changes together live together.
similarly if you have a bunch of code in repo a and a bunch of code in repo b that requires a PR in both places any time there is a change then it might be
good idea to pull code from repo a and repo b into repo shared too. code
that changes together, lives together. if you find over time that it's requiring
a change to repo a and repo b and repo shared any time you make a change,
then maybe you'll want to put all of those in one repo.
however: don't pull things out into shared libraries simply because you believe they may one day be used by other things, wait until you actually need them, wait until you can see it will reduce churn or duplication to separate it. never introduce indirection simply because you believe it may one day reduce duplication. DO REPEAT YOURSELF, until you can see the patterns. do not introduce configuration, shared code, environment variables, overloaded functions, dynamic dispatch, delegation, ..., until you can see that it will make the codebase better.
do not use any indirection at all until it is needed. constantly watch your repos, if there are a lot of examples of two (or more) repos requiring synchronized PRs then either make it one repo or pull the shared concept into a new package that both of the others depend on.
force faux bold and oblique website fonts
EDIT this does not work reliably across browsers so ignore all of this
today i found out about a little trick you can use to force the browser to synthesize its own bold and italic for a font, when you really want it to.
i wanted to change my font to be Geneva, to fit with my new Macintosh System 1 inspired theme. it doesn't have bold and italic styles. with web fonts, if they don't have bold and italic styles the browser will go ahead and imagine some. this is something people try to avoid. that's great for Adobe but im different.
i'm not using web fonts (falling back to other fonts on other platforms). it doesn't happen with local fonts, though, so what do we do?
@font-face {
font-family: 'Geneva';
font-style: normal;
font-weight: normal;
src: local('Geneva');
}that's right! define a web font @font-face whose only src is the local font
you want, and state that it only has a "normal" style and weight.
you could also use this to have an alias for your font stack by adding more font
names to the src, e.g. "src: local('Geneva'), local('Verdana');" but that's
probably an even worse idea than what i'm already doing!
let's go