hownowbrowncow

3Play Media | Principal Front-End Engineer (Growth) | Boston, MA | 1-day-in-office hybrid or fully remote (USA only) | Full-time | 3playmedia.com | $200–250k + bonus + equity

3Play makes content accessible across disability and language. Our human-QA'd captioning, audio description, subtitling, and dubbing services are used by over 10,000 media, higher ed, creator, enterprise, and government customers. We’ve worked on really cool projects: recent examples including captioning the 2024 Paris Olympics and providing quality AI dubbing for high-profile YouTube creators.

I'm leading the Growth team, and we're working to build new, beautiful UI experiences on our long-loved services. Our stack is a Remix/Rails product and Astro/Sanity marketing site, both backed with modern design system foundation (what you might expect with Typescript, Tailwind, ShadCN, Tanstack, etc). I'm looking for a principal-level engineer with strong taste in front-end: someone who cares about UX and styling, takes accessibility and page weight seriously, builds strong validation / testing harnesses, and keeps a dependency tree sane instead of letting it metastasize.

The other part of this role is contributing to our agents and workflows. We've invested heavily here with the right mix of enthusiasm, guardrails, and budget. You'll have heavy influence over how it evolves: what we hand to agents vs. keep in human hands, how work gets specified and parallelized, how we keep the results beautiful, and where the security and review gates live. There’s a ton of opportunity to work with the latest AI tooling and determine best practices as the industry matures. We’re a small team happily working over 15 years with high impact, high autonomy, and low bureaucracy. Come join us! Apply at https://www.3playmedia.com/company/jobs-post/?gh_jid=7761973.... Mention HN when you apply!

We're at the point where each day this week I lose PR comments and have to come back later. Constantly slowing down work.

Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout.

One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.

3Play Media | Staff API Engineer | Boston, MA | 1-day-in-office hybrid or REMOTE (US, CA) | Full-time | 3playmedia.com | $170-$190k w/ 10% bonus + equity

3Play is a company focused on ensuring content is accessible to all across disability and language. Our human-QA’d live captioning, transcription, audio description, translation, and dubbing services are used by over 10,000 higher ed, enterprise, media, and government customers.

I’m leading a team that focuses on globalization/localization of content. We are currently investing in new dubbing tools using voice synth and translation models. It’s a really fun challenge since 3Play has a contractor market for filling in places where models don’t have enough accuracy or yield poor results; a unique position to be in for designing workflows and fine-tuning models. I’m looking for a strong API engineer who has established Rails experience and enjoys collaborating on integrations, productionizing models, and working closely on new editor views in Remix. It’s a small team; we’d get to work closely together and you’d be very influential with the direction of the product!

Feel free to email your resume at nathanael [at] 3playmedia.com or apply directly with the full posting at https://www.3playmedia.com/company/jobs-post/?gh_jid=6003662.... Mention HN if you apply on the site!

Amazing.

One wonders how you might gain a representation of physics learned in the model. Perhaps multimodal inputs with rendered objects; physics simulations?

Even the videos at the latest WWDC have been really challenging. For example, the videos showing new Document Driven apps in SwiftUI never released their sample code as a lot of developers sought here: https://developer.apple.com/forums/thread/651193. They really just presented a glorified demo and a few slides.

And yet the old approach for Document Driven Apps is completely out of date straight from the banner page here: https://developer.apple.com/document-based-apps/ (https://developer.apple.com/library/archive/samplecode/Shape...). As mentioned in a lot of comments, there's a real desire to build apps natively but held back by bugs and the lack of entry through even sample code.

I work on the marketplace team—most of our software engineering roles are remote friendly, especially on the marketplace and transport teams. I recommend applying as we have a strong ratio of remote folks and can place you in teams where that’s well supported.

I'm quite sad they have removed 3D Touch from the phones. A minor feature I really enjoy with quick peeking — and bummed to lose that touch information for apps like Procreate Pocket and other drawing tools.

Yikes.

I agree that this might help you move quickly when starting a project and might be a fine approach for a small prototype or personal site (or, more unkindly, in a consulting project). But you pay a huge cost: maintainability. There is no encapsulation at all, not to mention the pain of having all these generic classes floating around, colliding with anything that might accidentally match. I’ve worked on projects like this where huge HAML views chain many of these functional CSS classes. It makes it very difficult to accommodate new external components or design updates which I would say are pretty much inevitable in any product company. Even if you don’t add anything new, good luck updating the entire system to adjust the padding on all buttons unless you were disciplined enough to truly create encapsulating classes (which is really the opposite approach of functional CSS anyway).

I really think CSS modules got it right (or similar approaches where you have a unique class name per component). Our team approaches component styles like a UIView in iOS—it should render acceptably with reasonable constraints. This means any parent component / view can render this and set display: block, flex, etc and the contents should largely adapt. These days this is pretty easy with flexbox and grid. Even better—you can ensure that the markup classes stay private to you and only allow modifications through JS (or mark some classes as :global). Even better than that—your components can adopt delegation or renderProps to allow parent views to replace / modify with their own markup so everything in the component can truly be encapsulated.

See also: https://gist.github.com/localjo/59bb12b7a4789e01e3782cf8a103...

Good to make sure you team members who might have installed within that time period nuke out all their node_modules.

Update: NPM is revoking _all_ tokens between 2018-07-11 00:00 UTC and 2018-07-12 12:30 UTC.

https://status.npmjs.org/incidents/dn7c1fgrr7ng

I’m thrilled about this change. Been trying apps to block for time such as Freedom, but it’s difficult to time blocklists, find how to block apps, and do all of this on a schedule. After a while I’ve realized every feature to effectively manage screen addiction while still remaining a good experience really needs to be baked into the OS. The direction Apple is taking looks fantastic—the only thing I hope for is specific Safari blocks in a addition to the app level timers.

Status page still says up. Thanks for posting.