jevakallio

Marker | Product Engineer + Full Stack Engineer | Onsite/Hybrid, London, UK | Full-time | https://marker.page/jobs | £100K - £170K + equity Marker is an AI-native Word Processor – a reimagining of Google Docs and Microsoft Word.

We are a small, early stage team of experienced engineers, designers and product people, building the next generation user interface for people who care about writing, enhanced by collaborative workflows and augmented by human-centred agentic AI editorial assistants.

We're hiring for:

- Full stack engineer (React/TypeScript/Prosemirror/Cloudflare): https://marker.page/jobs/product-engineer

We are looking for:

- Senior, high-agency people with relevant experience in the technologies outlined in the role

- Full-time, based in London, UK or nearby (co-working some days of the week from our offices)

Massive bonus points for:

- If you've built text editors before and enjoyed it enough to do it again :)

- Interest in local-first, sync engines, CRDTs, and all that fun nerdy stuff

- Personal interest in the act, craft, and quality of written expression

- Experience and specialisation in one of the following: Design Engineering, Hybrid desktop applications (e.g. Electron), Hybrid mobile applications (e.g. Expo)

Reach out through https://marker.page/jobs and tell us a bit about yourself!

Marker | Product Engineer + Full Stack Engineer | Onsite/Hybrid, London, UK | Full-time | https://writewithmarker.com/jobs | £100K - £170K + equity

Marker is an AI-native Word Processor – a reimagining of Google Docs and Microsoft Word.

We are a small, early stage team of experienced engineers, designers and product people, building the next generation user interface for people who care about writing, enhanced by collaborative workflows and augmented by human-centred agentic AI editorial assistants.

We're hiring for:

- Frontend-focused full stack engineer (React/Tailwind/TypeScript, ProseMirror+Tiptap, Y.js): https://writewithmarker.com/jobs/product-engineer

- Backend-focused AI engineer (TypeScript, Cloudflare Workers, Durable Objects, CRDTs, Workflows, Prompt/Context engineering, Agent orchestration): https://writewithmarker.com/jobs/ai-engineer

We are looking for:

- Senior, high-agency people with relevant experience in the technologies outlined in the role

- Full-time, based in London, UK or nearby (co-working some days of the week from our offices)

Massive bonus points for:

- If you've built text editors before and enjoyed it enough to do it again :)

- Interest in local-first, sync engines, CRDTs, and all that fun nerdy stuff

- Personal interest in the act, craft, and quality of written expression

Reach out through https://writewithmarker.com/jobs and tell us a bit about yourself!

Foam author here. Yes it can. GitHub support is purely optional. I've improved the Getting Started guide to reflect this.

Foam author here!

Fiddly, yes. This is very early stage project and in need of polish.

Lacking backlinks, however? We actually got those, thanks to the VS Code Markdown Notes extension:

https://foambubble.github.io/foam/backlinking

Amazing! Please let me know in GitHub issues or Twitter DMs how you get along. This is a very early alpha release, keen to hear feedback at all levels!

Foam author here! I am very open to all suggestions in this area. Foam is a new project I built solely to my own requirements, but I'm actively seeking feedback on how to make it more broadly applicable as per our principles: https://foambubble.github.io/foam/principles

FWIW, subdirectory linking support is not far away. Work is being tracked on GitHub at the issue below, and I already have a WIP PR in the works: https://github.com/foambubble/foam-vscode/issues/8

If you have any more suggestions and ideas on how to improve Foam, feel free to open issues on GitHub!

Foam author here! I'm not personally familiar with VSCodium, but contributions in this area would be extremely welcome as long as they don't prevent any of our Roadmap features working on VS Code!

Check out the contribution guide here: https://foambubble.github.io/foam/contribution-guide

Foam author here! I also don't like dependency on Jekyll, and over time I want to build a bespoke static site generator for Foam (possibly based on Gatsby) that's able to create a richer browsing experience.

Thanks for the idea! I have quite a few on the Roadmap already, and would love to hear more in GitHub issues

https://foambubble.github.io/foam/roadmap

Hi! Foam author here. We generate markdown references to bridge [[wiki-link]]s to work with Markdown tools. For the time being this is optimised for a) the editing experience in VS Code and b) the GitHub pages publishing pipeline, so it's more convenient to generate markdown links without the `.md` suffix.

See bottom of the file here for example: https://raw.githubusercontent.com/foambubble/foam/master/rea...

This means that for the time being links are broken in the GitHub markdown preview.

I'll look into getting this fixed, but not sure what the best way forward is.

Yes.

That's actually a good idea. Right now we pay the salary to you, and you can then donate it to a charity. It would be way more tax efficient to just skip the middle step.

Will take this under consideration!

I guess they'll have to work overtime to process all the applications ;)

I agree this could be the case, except that there is no pressure to work on anything work-related. You can literally contribute to any OSS project, whether it's your own video game side hustle, a learning project in a language we don't use, or, if the mood strikes, also one of our projects' dependencies.

This is a great idea. I don't know if it's even a starter, tax code wise, but would be amazing if it could be done.

For the time being, we are happy with $20 for the reasons outlined in the post itself. It's not an incentive, it's a reward, and a purely optional one. Many people in the company (I'm the author) do work on Open Source and don't make use of the benefit, because they don't care about the money. This, for us, is fine.

It's set at 30 hours a month. This is not for budget reasons, only to discourage excess working off-hours. This adds up to about a workday per week, which is what we feel is reasonable.

Author of the post here.

Realistically, we can't pay people full engineering salaries to do random OSS. Our team can already contribute to OSS on their work time when it relates to their work, or our own projects, but for the personal interest/passion projects without direct benefit for us as a company, it doesn't scale. Doubly so when we have a pretty strict "no overtime" policy of working no more than 40 hours a week.

We have failsafes in place in case anybody gets a bit too excited about free time OSS. We limit the Sauce hours you can do in a month for this reason, but nobody has hit that max yet, so it doesn't seem to be a systemic problem.

I love the annotated source code, but I wouldn't necessarily recommend the Underscore library code itself as learning material to budding developers - it's optimised for size and performance, not legibility and idiomatic style. I remember being a budding JS dev once upon a time, and being quite perplexed by it :)

It's written with Docco, a tool created by Jeremy Ashkenas. It's used in docs of his other projects, such as CoffeeScript and Backbone, too.

http://ashkenas.com/docco/

Hi! I'm the author of the library, and just wanted to say that you are absolutely correct about Redux Offline not being a suitable solution for weeks of active offline use :)

Regarding the "get a connection within one hour", that's only for automated, scheduled retries. When your app becomes online or is started up, no matter after how many hours or days have elapsed, we do continue retrying the messages unless you have a discard policy in place to remove them. The limited retry policy is related to not banging on a backend that is down or unreachable, etc.

Correction to the previous: The CycleConf changes are now part of the official cycle-react-native repo: https://github.com/cyclejs/cycle-react-native

We looked at Fastlane and thought it looks very interesting, but because we didn't have personal experience with it, we decided to go with what we know: Bitrise for the CI, CodePush for the app live updates.

We would love see contributions that add Fastlane configurations though. If you're interested in helping out, please open a GitHub issue and let's discuss what should be done.

Please take a look and let us know if you run into issues! We've just launched Pepperoni, and it's not yet as polished as we want it to be, but we'll be there soon.

For comparison's sake, check out https://github.com/bartonhammond/snowflake - it's quite similar to Pepperoni, and at this moment a bit more mature.

In the long term we want to make Pepperoni more comprehensive, documented and stable. We have some different opinions compared to Snowflake's - that's why we are building our own. A topic worth a blog post, though, too long to expand here and now.

Haha, I work at Futurice, and I wish I knew the answer to that question :)

Here in the UK it rhymes with Avarice. In Finland it's more like Future Rice.

Great question! We are investigating adding Relay support, as well as a PostGraphQL endpoint (Postgres+GraphQL) to the soon upcoming Pepperoni Backend Kit.

Right now we've included what we know works well, and we don't yet have experience with Relay in React Native apps. Contributions welcome, though :)

Thanks for your interest! It's definitely more of a project boilerplate. We have big ideas for the future, but starting out small.

Thanks for the notes on the mixed messaging, we'll tweak the website to be more informative.

Thanks for the feedback! One of our team members is working on a sample app, launching as soon as it's done :) We didn't want to delay the release until "everything" was complete, in order to gather input such as yours. If you're interested on learning when the sample app is released, please subscribe to our mailing list and we'll let you know!

Pepperoni App Kit is going be fully backend agnostic - we haven't implemented all the bits yet, but the only assumption we will be making is that your data is JSON served over HTTP, using JWT authentication - and the authentication bit can be easily changed.

We are also going to implement a Pepperoni Backend Kit, based on node.js. The App Kit will not require you to use that backend, though.

I'm one of the authors of Pepperoni, as well as contributor to Cycle Native. I would love to see Cycle.js become a first class citizen of the React Native ecosystem.

At CycleConf last month we hacked around improving the Cycle/RN interop and solving a few of the big problems that prevented using Cycle Native for real apps, and ended up rewriting most of the Cycle Native internals. Our work is not yet fully merged to the official repo, needs a bit of cleanup before we can do that.

The work in progress is here: https://github.com/jevakallio/cycle-react-native

Take a look at http://cycle.js.org - it implements essentially the same concept using RxJS instead of csp and virtual-dom instead of React.