I’ve lived in SF for 11 years now and it feels like city is mostly full of people who actually want to be here now. Even in covid times, I feel like there’s a better sense of community and civic engagement with neighbors. I also was super annoyed by people who came to SF that said it’s not diverse, when it was them not exploring outside of the tech world. All anecdotal, but life in the city is actually kinda awesome despite covid, but I do miss bigger hangouts than just a small social circle, which isn’t allowed anymore even.

I've lived in SF for two years now. I _choose_ to live in SF, at 34, and I commute to south bay for my job, with a bit more WFH now than before COVID but I sometimes still commute.

I don't want to get into details but the other thing I like about the people staying in SF because they chose to is a healthy disregard for authority together with a very smart sense about how to take care of themselves and others. It's saving me from terrible depression or going into complete isolation in COVID times.

Lyft already has it, and it's in the app if you are a driver and the region supports Lyft Line. You set a destination you are driving to, and it'll match up with any Lyft Line passenger going sorta same direction: https://drivers.lyft.com/customer/portal/articles/1778131-de...

Loggly, San Francisco, CA (Financial district) - Full Time

Looking for Full-stack, Frontend, Backend engineers. We're trying to make logging, instrumentation, and log analysis simpler for fellow devs and their lives easier.

Back-end: Mostly a java/python shop with heavy use of ElasticSearch and Kafka. If dealing with search, scale, or machine learning is your thing, you'll have a lot of fun here.

Front-end: Django/python, Angular/js, sass is what we use to make mostly single-page-applications. We're looking for generally competent html/css/js/serverside/CRUD devs who can pick things up.

email jobs@loggly.com and mention HN

"The right way to do things the first time is the way that gets it working the fastest so you can see if your solution even makes sense.

The right way to rewrite it once that works is to make it fault-tolerant and scalable.

The wrong thing to do is build a giant system first, and try to account for every possibility."

Great quotes. There are exceptions, such as when you're making a libarary, utilities, or APIs, but in most cases, you ain't gonna need it (https://en.wikipedia.org/wiki/You_aint_gonna_need_it).

Continuation Passing SPOILERS:

f_success = function() { gC(success, failure); }; f_failure = function() { gC(failure, failure); }; fC(f_success, f_failure);

For me, the trick here was to forget about the words "success" and "failure" because they have too much semantics embedded. I had to re-word the problem like this: call f3, if first argument of f1 and f2 are called. All other roads lead to f4. Both f1 and f2 has to be called in the chain no matter what.

Also, this is the first time I've seen such a pattern. Is there a practical application of such pattern? I think it's ok to have a single level of closure to continue execution, but if it goes to that many levels like the sample problem, it'll be a nightmare to maintain for people who have not seen your code yet.

The real problem is that assistive technology is very slow to catch up with the technology and are expensive. For example, JAWS, one of the most popular screen readers, is around thousand dollars, and people purchase these type of software not on a regular basis and don't update year to year. Even if the screen readers catches up, it will be a while until the adoption spreads due to the high cost. Also, as you can imagine, disabled people do not make a lot of money ON AVERAGE (not saying you can't be well off being disabled), so upgrades do not happen often.

Another thing that sucks is that reader interface are not standardized. Try using JAWS, then Voiceover on Mac OS. Way you use them is very different and way it works is different too.

Accessibility is a tough problem, but I don't think we should hold back on using modern technologies and process. We should definitely have accessibility in our minds and know in our heads that it is hurting some users in using these new technologies however.

I would take it a bit further and ask all web developers to try to use your own site with a screen reader and turn off your monitors. It's quite an experience. For Windows, use JAWS, for Mac, use Voiceover (it's free and embedded to Mac OS)

> It's quite an experience

It is, but it is mostly meaningless unless you are willing to spend a lot of time doing that and thus coming closer to the true experience of the blind users.

For Linux, use Orca, also free and in most repositories.

she's referring to "classitis": http://www.sitekin.com/blogdetail/avoid_CSS_Classitis

in that example, classitis is when you give a class "item" to every li element, the using .item to style it while the alternate way to do it is using the descendent selector (.parentcontainer li). Nicole Sullivan is saying this can lead to specificity war over time.

Yep, it's this one.

I apologize to others for the lack of context that the slide by itself gives. I got the summary of this talk from a co-worker who actually went, so I had the context in back of my mind. The slidedeck naming is still too sensationalist though for what it's actually about: over time, css gets degraded because developers get into a firebug-hack mentality leading to overwrites by specificity until it gets too big and messy to maintain. I'm still not too clear what she's proposing as a solution to this though; she does give an example of her success at facebook, but that example is a one-time fix, not necessarily a practice that stands on its own over time.

I think he was talking about "developer privacy safeguards". Basically, there is none.