armincerf

Artis | Lead Front-end Developer | React, TypeScript | Remote (UK Hours)

Artis is a rapidly growing fintech company building innovative financial products focused on fast-moving market data. We provide powerful grid-based data displays (AG Grid) and real-time candlestick charting (TradingView Lightweight Charts) to our expanding user base.

We’re looking for a Lead Front-end Developer who: - Is an expert in React and TypeScript. - Has strong knowledge of Web Workers and performance optimization. - Can effectively lead and mentor a growing front-end team.

Bonus points for experience with: - WebAssembly (WASM) - Rust - Real-time/multiplayer applications - Working with financial data and financial products

You’ll thrive if you: - Enjoy solving challenging performance and scalability problems. - Prefer minimal bureaucracy and straightforward collaboration tools (Linear, Slack). - Are comfortable working remotely within UK working hours. (London-based is a plus, not mandatory.)

Salary: £100,000 – £120,000 per year. Apply directly at: careers@artis.works

Artis Works | Full-Time | Backend Engineer | Remote | £75k-95k

Artis Works leads financial innovation by empowering trading firms, brokerages, and institutions with advanced technology. Our flagship product is responsible for taking high frequency tick data from the market, and combining it with user supplied data and custom formulas to produce insights for traders. We surface high quality, low latency historical and live data across 4 continents.

See more about the product at https://artis.works

Position Overview:

We're looking for a motivated backend engineer to join our dynamic team. You'll design, build, and launch essential cloud services from the ground up, significantly impacting our products and success.

Requirements:

Experienced or interested in Rust, or proficient in JVM-based languages (especially Clojure).

Skilled in building real-time data processing and multi-threaded, latency-sensitive systems.

Familiar with stream processing (Kafka, Pulsar, Flink) and distributed systems.

Capable of building secure, scalable, and reliable systems with attention to monitoring and graceful failure.

Experienced with relational, non-relational, and time-series databases.

Familiarity with cloud infrastructure, especially AWS, is a strong advantage.

To apply send an email with a cover letter and/or CV/Resume to careers@artis.works

might not meet your needs but I had similar issues and found an app called rcmd, it lets me easily bind keybinds to my commonly used apps, and you can also easily toggle between multiple windows of the same app via the keyboard

https://lowtechguys.com/rcmd/ - no affiliation, and probably other similar options are available

It says gel is to Postgres what typescript is to JavaScript, so can I add gel to an existing Postgres instance and get the benefits of the nicer query language or does it rely on special tables? If I use some other extension like timescale is that compatible with gel?

And is there a story for replication/subscribing to queries for real time updates?

Postgres is so powerful partly because of its ecosystem, so I want to know how much of that ecosystem is still useable if I’m using gel on top of Postgres

Oh, I totally agree that 'people' (which I guess refers to any potential user of a DBMS) often do need temporality (or even bitemporality), but they don't consider that the database should have this baked in, or they just don't consider it much at all.

I'm fully on board with XTDB and similar solutions for this reason. Most people still gravitate towards Postgres and similar databases without giving much thought to these temporal challenges, even though those options lack a robust solution for the temporal issues that so many systems demand.

Ok but XTDB has a lot in common with Datomic and is open source but still hardly widely used. I think this is partly because most people don't consider 'temporality' as a feature a database should offer; rather, they believe temporal problems should be solved via proper schema design and application logic. Additionally, using datalog (or any esoteric query language that isn't SQL) locks you out of many battle-tested tools that enterprises rely on.

The XTDB team has pivoted towards a SQL-first approach (though still supports datalog) and now 'only' has the 'But why not just use Postgres' problem to solve.

Having personally moved from trying to use Postgres for everything (including lots of timeseries data with Timescale) to a dedicated and relatively unknown DB built purely for the purpose I want it for (QuestDB), I am all for more people trying to build databases that do specific things better than Postgres. However, it will be very difficult to create something that does literally everything Postgres can do but better, which probably makes Postgres the sensible choice for the majority of applications.

Artis Works | Senior Engineer Frontend and Backend (2 separate roles available) | Rust, Clojure, TypeScript | Remote (Europe time zone, UK preferred)

We’re building a collaborative, local-first set of tools that take raw financial market data from multiple financial exchanges and allows users to create excel-like formulas using both the market data and user-entered data as inputs. The problems we are solving are extremely challenging, but we have delivered a working V1 and have a rapidly growing dedicated user base and recently secured VC funding.

Both roles are for senior developers:

  - Frontend is React/strict TypeScript/local-first DB + sync engine, custom formula evaluation engine written in rust compiled to WASM (no Rust/WASM expertise necessary for this role)
  - Backend is mostly Rust + some Clojure (no Clojure experience needed), k8s/Postgres Aurora, QuestDB, Kafka.

We try to keep red tape and bureaucracy to a minimum and mostly just use linear and slack for collaboration but are always open to process suggestions from anyone on the team.

Apply at https://www.artis.works/careers or DM me/reach out to alex at artis.works.

We’ve been using triplit to store user settings that can be managed by admins, it’s important users always feel like the app runs locally and they often don’t have good internet but we still needed sync as the users often switch devices and admins need to see and manage other users settings.

Overall triplit has been really great, both as a frontend dx and also their support - whenever we find an issue or have a feature it gets handled very quickly by the team which is awesome!

As soon as they have an answer for HA deployments we will be moving more critical data there instead of Postgres

"syncing doesn’t work without a server"

I don't think this is true, granted there are some big challenges to transfering data between devices without a central server, but there are several projects like https://dxos.org/ which use p2p, and also there's https://ditto.live/ which uses bluetooth/wifi direct for cases where all users will be in the same room or on the same local network (imagine wanting to play chess with a friend sitting in a different row on a plane without wifi - I was in this situation recently and was pretty surprised that I couldn't find anything on the app store that could do this!)

Of course most of the time its better to have a server because p2p still has a lot of difficulties and often having a central 'source of truth' is worth the costs that come with a server based architecture. So imo things like https://electric-sql.com/ or https://www.triplit.dev/ or the upcoming https://zerosync.dev/ will be far better choices for anyone wanting to build a local first app used by many users.

XTDB is MIT and has clients for Java or HTTP if you don't want to write Clojure. Not every Datalog implementation is 'about Rich Hickey'

Vite uses Esbuild for development builds, and they have an answer for why they don't use it for prod builds here https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

You can plug any usb device into an iPad and use the files app to copy stuff over? I use an external usb c ssd with my iPad for my photography work flow. file management has come a long way in the past couple of years.

If it’s just pdfs I would probably email them though

This looks great and all but the new drawer icon covers up a key button on our app.. ironically the person who noticed took a regular screenshot and shared it in slack

It gets activated on any audio source in a surround sound format, it can’t be applied to stereo sources because stereo audio doesn’t contain any positional info

I have been using the base model 8gb m1 Mac mini as my main work machine since it came out, the only time I have noticed a ram limitation was when I ran out of storage space and it couldn’t swap anymore. Pretty amazing since this computer cost $2000 less than my 2019 MacBook Pro and is noticeably faster (Clojure development and some hobby music production)

Maybe I’ll regret it in a few years if the ssd dies due to the extra load though… I do really wish the storage was easier to change

I can't memorize all thousands of functions to manipulate lists and hashs in clojure (get-in, map-vals, conj, dissoc, select-keys, sorted-map-by, do you know what all those do?) which do a lot, I felt clojure was dense, the opposite of little cognitive load

Funny, I would say that it’s the functions for manipulating data structures that makes clojure a joy to use. To me it feels like there are very few of them, and there’s a lot of consistency which makes it easy to guess what one does if you haven’t seen it before (once you’ve learned map, map-keys/map-vals/mapv don’t really need learning etc). Yes there are actually a lot, but I basically only use a dozen or so. Would be interesting to see the frequencies of clojure syntax vs other languages.

Clojure was my first (professional) language though, and I have used it every day for the last 4 years. I guess it’s different if you’re trying to learn it on the side.

I have dabbled in a few other languages on side projects (js/go/swift/svelte) and while there are definitely big improvements to be found in the tooling, nothing really matches Clojure as a language for me. Though I won’t claim that ‘clojure is more productive’, I will claim that ‘I am more productive with Clojure’, probably largely for the same reasons that you are not, it’s comfortable for me.

You'd think they would just use the same 2FA methods that are popular for logging in. 'We sent a notification, click accept on it to continue' or 'read the 6 digit authenticator code' would be re-useable for their web login and there are a ton of libraries and info that make it easy to implement.

Most of the electron apps out there already have native iOS versions which will run natively on AS macs too, that should go a long way to smooth the transition (and will be interesting to see how much extra RAM you gain from not needing slack/spotify/notion etc to run on Electron).

I guess there will still be issues for people who need to run VMs or media apps like Adobe CC etc, and also it will take a while for some dev environments to be fully supported (https://github.com/Homebrew/brew/issues/7857 for example shows it will take some time to get to feature parity).

Overall though a lot of the hard work has already been done, and I'm sure in 2 years time or whenever the transition is 'complete', mac owners will be getting much more value for money with few drawbacks (the main one being higher walls around the garden)