google reader refugee.
1976 stories
·
48 followers

Buzzfeed’s 23 favorite Ask a Manager letters

1 Share

Buzzfeed just did a round-up of their 23 favorite Ask a Manager letters. It’s full of classics. You can read it here:

Buzzfeed’s 23 favorite Ask a Manager letters was originally published by Alison Green on Ask a Manager.

Read the whole story
pfctdayelise
1 day ago
reply
Melbourne, Australia
Share this story
Delete

Fearless Concurrency in Firefox Quantum

4 Shares

These days, Rust is used for all kinds of things. But its founding application was Servo, an experimental browser engine.

Now, after years of effort, a major part of Servo is shipping in production: Mozilla is releasing Firefox Quantum!

Rust code began shipping in Firefox last year, starting with relatively small pilot projects like an MP4 metadata parser to replace some uses of libstagefright. These components performed well and caused effectively no crashes, but browser development had yet to see large benefits from the full power Rust could offer. This changes today.

Stylo: a parallel CSS engine

Firefox Quantum includes Stylo, a pure-Rust CSS engine that makes full use of Rust’s “Fearless Concurrency” to speed up page styling. It’s the first major component of Servo to be integrated with Firefox, and is a major milestone for Servo, Firefox, and Rust. It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust.

When a browser is loading a web page, it looks at the CSS and parses the rules. It then determines which rules apply to which elements and their precedence, and “cascades” these down the DOM tree, computing the final style for each element. Styling is a top-down process: you need to know the style of a parent to calculate the styles of its children, but the styles of its children can be calculated independently thereafter.

This top-down structure is ripe for parallelism; however, since styling is a complex process, it’s hard to get right. Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical! We use rayon —one of the hundreds of crates Servo uses from Rust’s ecosystem — to drive a work-stealing cascade algorithm. You can read more about that in Lin Clark’s post. Parallelism leads to a lot of performance improvements, including a 30% page load speedup for Amazon’s homepage.

Fearless concurrency

An example of Rust preventing thread safety bugs is how style information is shared in Stylo. Computed styles are grouped into “style structs” of related properties, e.g. there’s one for all the font properties, one for all the background properties, and so on. Now, most of these are shared; for example, the font of a child element is usually the same as its parent, and often sibling elements share styles even if they don’t have the same style as the parent. Stylo uses Rust’s atomically reference counted Arc<T> to share style structs between elements. Arc<T> makes its contents immutable, so it’s thread safe — you can’t accidentally modify a style struct when there’s a chance it is being used by other elements.

We supplement this immutable access with Arc::make_mut(); for example, this line calls .mutate_font() (a thin wrapper around Arc::make_mut() for the font style struct) to set the font size. If the given element is the only element that has a reference to this specific font struct, it will just mutate it in place. But if it is not, make_mut() will copy the entire style struct into a new, unique reference, which will then be mutated in place and eventually stored on the element.

context.builder.mutate_font().set_font_size(computed);

On the other hand, Rust guarantees that it is impossible to mutate the style of the parent element, because it is kept behind an immutable reference. Rayon’s scoped threading functionality makes sure that there is no way for that struct to even obtain/store a mutable reference if it wanted to. The parent style is something which one thread was allowed to write to to create (when the parent element was being processed), after which everyone is only allowed to read from it. You’ll notice that the reference is a zero-overhead “borrowed pointer”, not a reference counted pointer, because Rust and Rayon let you share data across threads without needing reference counting when they can guarantee that the data will be alive at least as long as the thread.

Personally, my “aha, I now fully understand the power of Rust” moment was when thread safety issues cropped up on the C++ side. Browsers are complex beings, and despite Stylo being Rust code, it needs to call back into Firefox’s C++ code a lot. Firefox has a single “main thread” per process, and while it does use other threads they are relatively limited in what they do. Stylo, being quite parallel, occasionally calls into C++ code off the main thread. That was usually fine, but would regularly surface thread safety bugs in the C++ code when there was a cache or global mutable state involved, things which basically never were a problem on the Rust side.

These bugs were not easy to notice, and were often very tricky to debug. And that was with only the occasional call into C++ code off the main thread; It feels like if we had tried this project in pure C++ we’d be dealing with this far too much to be able to get anything useful done. And indeed, bugs like these have thwarted multiple attempts to parallelize styling in the past, both in Firefox and other browsers.

Rust’s productivity

Firefox developers had a great time learning and using Rust. People really enjoyed being able to aggressively write code without having to worry about safety, and many mentioned that Rust’s ownership model was close to how they implicitly reason about memory within Firefox’s large C++ codebase. It was refreshing to have fuzzers catch mostly explicit panics in Rust code, which are much easier to debug and fix than segfaults and other memory safety issues on the C++ side.

A conversation amongst Firefox developers that stuck with me — one that was included in Josh Matthews’ talk at Rust Belt Rust — was

<heycam> one of the best parts about stylo has been how much easier it has been to implement these style system optimizations that we need, because Rust

<heycam> can you imagine if we needed to implement this all in C++ in the timeframe we have

<heycam> yeah srsly

<bholley> heycam: it’s so rare that we get fuzz bugs in rust code

<bholley> heycam: considering all the complex stuff we’re doing

*heycam remembers getting a bunch of fuzzer bugs from all kinds of style system stuff in gecko

<bholley> heycam: think about how much time we could save if each one of those annoying compiler errors today was swapped for a fuzz bug tomorrow :-)

<heycam> heh

<njn> you guys sound like an ad for Rust

Wrapping up

Overall, Firefox Quantum benefits significantly from Stylo, and thus from Rust. Not only does it speed up page load, but it also speeds up interaction times since styling information can be recalculated much faster, making the entire experience smoother.

But Stylo is only the beginning. There are two major Rust integrations getting close to the end of the pipeline. One is integrating Webrender into Firefox; Webrender heavily uses the GPU to speed up rendering. Another is Pathfinder, a project that offloads font rendering to the GPU. And beyond those, there remains Servo’s parallel layout and DOM work, which are continuing to grow and improve. Firefox has a very bright future ahead.

As a Rust team member, I’m really happy to see Rust being successfully used in production to such great effect! As a Servo and Stylo developer, I’m grateful to the tools Rust gave us to be able to pull this off, and I’m happy to see a large component of Servo finally make its way to users!

Experience the benefits of Rust yourself — try out Firefox Quantum!

Read the whole story
pfctdayelise
7 days ago
reply
Melbourne, Australia
Share this story
Delete

Three fun ways to use emoji in your code

1 Share

Emoji aren't just for Twitter and Facebook—you can use them in web code, too! Here are three 💅 examples.

1. Emoji in CSS selectors

Emoji are valid CSS selectors, which means you can name your CSS classes 🍕 or 🥃 or 💩. Monica Dinculescu and Mariko Kosaka put together a clever example (below). In their example, emoji names get literal: the 🌈 class turns text into a rainbow gradient, and the 👻 class hides whatever element it's applied to.

Emoji can be used for CSS class names. Demo code by @notwaldorf and @kosamari.

Emoji can be used for CSS class names. Demo code by @notwaldorf and @kosamari.

2. Modifying emoji with JavaScript

Emoji look like individual characters, but they actually are combinations of Unicode characters and modifiers. Emoji can be joined together by putting multiple Unicode characters next to each other with a zero-width space (👨👩👧 → 👨‍👩‍👧). Unicode 8.0 also supports five skin code modifiers to change the color of human emoji (👸 → 👸🏻👸🏼👸🏽👸🏾👸🏿).

Since emoji are sequences of Unicode characters, JavaScript string operations can join, replace, and otherwise modify emoji. You can do silly things like change emoji skin color or update a family size with JavaScript. (Are you looking for a nerdy way to announce your pregnancy, marriage, or divorce...? Look no further!)

Emoji properties can be modified or deleted. Demo code by @notwaldorf and @kosamari.

Emoji properties can be modified or deleted. Demo code by @notwaldorf and @kosamari.

3. Replace "boring" JavaScript variable names

Are you sick of var i = 0? Is your code reviewer not paying attention? If you answered "yes" to both questions, Dan Thareja made the emojify library for you. The emoijfy library minifies code and substitutes emojis for variable names. You can adjust how aggressively you want the library to minify and substitute.

Screen Shot 2017-11-09 at 3.24.10 PM.png
Screen Shot 2017-11-09 at 3.24.17 PM.png
Screen Shot 2017-11-09 at 3.24.25 PM.png


Read the whole story
pfctdayelise
12 days ago
reply
Melbourne, Australia
Share this story
Delete

how should you decide which battles to pick at work?

1 Share

A reader writes:

I have a question regarding workplace conflicts.

I am currently a junior staff member and much of my job involves writing. The thing is, such work tends to be very subjective, and lots of people claim that they have a good eye for design, taste, or writing. I always have this conflict with this manager (not my direct manager). She tends to have very specific ideas about what writing should be like, for example using sophisticated writing (think Harvard Business Review), while I tend to use casual language (think Buzzfeed).

We had differences over a writing project that happened to involve one of her products. I wrote a long form article and sent it to her just to fact-check. She came back and said that it was too casual, and she wanted it to be more specific and formal.

While I have no issues with filling in content gaps, I was not too keen on using formal tone, as I believe that content should be accessible and reader-friendly, not dry, sterile, and bland. I did not back down, and kept rationalizing with her.

Ultimately, she sent it to our Communications head, who commented that my writing needs to be mellowed down and not sound overly casual. It was short of saying that it needs to be formal. I assume it was for my benefit as well, since such work tends to be subjective, even though there are brand or corporate guidelines to stick to, and there may be some leeway I can use.

I can accept this — to try to hold back on being too casual — but I stand by my principle for writing for the mass audience. I gave it some thought, and have decided to reply that I will tone it down, but I will still try to make my writing more digestible and accessible for the mass audience, including using plain, simple language. I will also maintain that my writing will not be overly formal, lest we bore our audience.

More broadly, how do you decide what battles to pick? What kind of situations warrant escalating, and when will you let things go? In my case, I felt that things would have turned out better had I gone along with the manager’s comments and not voiced my disagreement, but at the same time, by giving an inch I fear that she will take a mile in the future, where she wil dictate my writing style, when it’s quite subjective.

I am curious to understand your thought process on this, and what factors you use to assess what workplace conflicts are worth engaging and dragging out, and which you will let go.

Well, let’s address this specific situation and then talk about those questions more broadly.

Ultimately, it’s your employer’s call what kind of work they want. If managers above you are telling you that they want more formal writing, then that’s their prerogative, even if you feel strongly that they’re wrong. It doesn’t matter that “good writing” is subjective. It’s still their call.

To be clear, a good manager will want to hear that you have a different point of view. A good manager will welcome dissent, take genuine interest in viewpoints other than her own, and truly consider input that’s different from her perspective. But ultimately, she may make a different decision that the one you want her to make, and she has the standing to do that. At that point, you need to decide if you can live reasonably happily with what you’re being told to do, or whether you feel so strongly about it that this isn’t the job for you.

What you can’t do is to continue to argue about it over and over, and you definitely can’t just do it your own way anyway.

At absolute most, you can sometimes say something like, “I feel really strongly about this because of X and Y. Would you be willing to allow me to try it my way on an upcoming low-stakes project to test out how it goes?” But if the answer is no, you can’t just ignore that and continue to do it your own way. This is the nature of having a boss.

Now, let’s talk about your broader questions. The same principles apply: When you disagree with your employer about something, decide how important it is to you, speak up if it’s important, and then decide if you can live with the decision if it’s not one you like.

In deciding whether it makes sense to push back on something, you should take a few factors into account: how much you care about it and how unhappy you’d be if nothing changes, how much standing you have to push back (how senior you are, how much your work is valued, how well positioned you are to have special insight into the topic, how much political capital you’ve accrued and spent on other things, and frankly how much people like you personally), and how receptive the person you’re approaching is to input. For example, if your company plans to change some software that you’re the main user of and it’s going to add significant time to your work, it makes sense to push back. If you’re a summer intern who thinks the company should change its dress code, it doesn’t.

And again, if you do decide to speak up and you don’t get the outcome you wanted, in most cases you can’t keep arguing something over and over. If you do that, at a minimum you’re likely to get a reputation for being a pain in the ass who doesn’t understand how hierarchy works, and they may even decide they’d rather replace you with someone who’s easier to work with.

I think there’s an underlying belief in your letter that it’s okay to keep pushing and pushing if you’re right, but work just doesn’t work that way. There are people above you who are in charge of making decisions, and part of your job is to accept and execute those decisions (again, after voicing your viewpoint if there’s an important difference in perspective). If you disagree strongly enough, you can always leave — but you can’t stick around and just keep telling them they’re wrong and they should do it your way.

(Important caveat: If the issue is very serious — something like unsafe working conditions, sexual harassment, or illegal labor practices — that changes the calculation. You should always default to speaking up in those situations. And in those cases, it will often make sense to amplify the power of your voice by speaking up with others, as a group.)

Here are some related posts that explore different aspects of this:

how to disagree with your boss and keep your job

how to disagree with your boss in a meeting

when should you go over your boss’s head?

can your employer do that? probably, but you can still discuss it

what to do when your employer is breaking the law

how should you decide which battles to pick at work? was originally published by Alison Green on Ask a Manager.

Read the whole story
pfctdayelise
13 days ago
reply
Melbourne, Australia
Share this story
Delete

James Bridle on the dark, strange underworld of YouTube kids videos

1 Comment and 2 Shares

it only takes five or six related video clicks to get from benign to disturbing stuff

Read the whole story
pfctdayelise
14 days ago
reply
Melbourne, Australia
Share this story
Delete
1 public comment
MotherHydra
15 days ago
reply
And folks have only been complaining about this for 6 months now, while YouTube has bee. Complicit in allowing the content while censoring news networks and personalities that express wrongthink. YouTube is utter shit, I will celebrate the day this platform dies because it will be a net win for humanity.
Space City, USA
peelman
14 days ago
Agreed. I really expected Microsoft or somebody (anybody) to come up with a competitor by now. Vimeo just never had the right revenue model it seems.

Toxic experts

1 Comment and 5 Shares

I wrote Big-O: how code slows as data grows to explain Big-O notation. My goal was to explain it in broad strokes for people new to the idea. It grew out of thinking I'd been doing about beginners and experts. In the comments, there was an unexpected and unfortunate real-world lesson.

An anonymous coward named "pyon" said I should be ashamed. They pointed out a detail of algorithmic analysis that I had not mentioned. It's a detail that I had never encountered before. I think it's an interesting detail, but not one that needed to be included.

Pyon is an example of a toxic expert. People like this know a lot, but they use that knowledge to separate themselves from the unwashed masses of newbs. Rather than teach, they choose to sneer from their lofty perches, lamenting the state of the world around them, filled as it is with People Who Don't Want To Learn.

The important skill pyon and other toxic experts are missing is how to connect with people. They could use their knowledge to teach, but it's more important to them to separate themselves from others. Points of correctness are useless without points of connection.

Toxic experts care more about making distinctions between people to elevate themselves than they do about helping people. Beware: they are everywhere you look in the tech world. It's easy to run into them when you are trying to learn. Ignore them. They don't know you, and they don't know what you can do.

Pyon is fixated on a particular detail of algorithmic analysis, and feels that it is essential to understanding Big-O. I can tell you is that I am doing fine in my 30-year career, and I had never heard that particular detail. My Big-O piece wasn't meant to be exhaustive. There are entire books written about algorithmic notation. I even wrote at the end, "There's much more to algorithm analysis if you want to get into the true computer science aspects of it, but this is enough for working developers."

But pyon can't see the forest for the trees. Experts have spent a lot of time and energy learning what they know. They love their knowledge. They wouldn't have been able to get where they are without a passion for the subject. But sometimes they have a hard time seeing how people can be successful without that well-loved knowledge. They've lost sight of what it means to be a beginner, and what beginners need to learn.

Toxic experts will latch onto a particular skill and decide that it is essential. For them, that skill is a marker dividing Those-Who-Know from Those-Who-Don't. These shibboleths vary from expert to expert. In the current case, it's a detail of algorithmic analysis. I've seen other toxic experts insist that it's essential to know C, or assembly language, or recursion and pointers, and so on.

I'm not saying those aren't good things to know. The more you know, the better. Every one of these topics will be useful. But they are not essential. You can do good work without them. You certainly don't deserve to be spat upon.

The ultimate irony is that while pyon and other toxic experts are bemoaning the state of the industry because of missing knowledge, they are highlighting the main skill gap the tech industry needs to fix: empathy.

Read the whole story
pfctdayelise
18 days ago
reply
Melbourne, Australia
Share this story
Delete
1 public comment
jepler
17 days ago
reply
I'm a recovering toxic expert :-/
Earth, Sol system, Western spiral arm
digdoug
16 days ago
Me too, it's amazing how much hate I have for people that haven't started recovering yet!
Next Page of Stories