vmind

The likely endgames of 'no tracking' (accelerated by automating rejection rate up to 100%) are:

- drastically reduced free content (see the rise of paywalls on most news sites)

- an arms race to find other ways to track (see rise of cookieless tracking and retargetting approaches, first party cloaking, etc)

Not to say the latter wouldn't always be there, and but fact is a good chunk of the web is free and stuffed with ads because that's the only way to stay afloat, people simply don't want to pay for content.

Silico | Compiler Software Engineer | London, UK | REMOTE (UK) | FULL TIME | https://www.silicoai.com/

Silico is developing a flexible simulation and decision support platform, enabling businesses to better plan and evaluate their decisions.

We're hiring a Compiler Engineer to join our team and work on our core engine toolchain, an interactive compiler for analysing end user formulae to provide LSP-style editor support, as well as compilation into high performance code for execution. Another facet is bringing powerful techniques such as auto-differentiation to our users seamlessly via the compilation pipeline.

Our engine is written in Rust, supporting a TypeScript/React SPA, and run server-side as well as client-side via WASM.

Full Job description and application portal: https://careers.silicoai.com/jobs/1679527-software-engineer-...

The UK at least has legislation which applies during elections and referendums (https://www.ofcom.org.uk/tv-radio-and-on-demand/broadcast-co...).

Silico | London, UK | Multiple Software Engineer Positions | Full-time | Fully Remote (UK Only) | https://silicoai.com

At Silico we're building a simulation platform to enable businesses to use forecasting and simulation to plan for tomorrow. We're still a small team of 5 engineers, so join us early and help us shape our team and product going forwards!

We're VC funded and in the process of starting a new wave of hiring, currently prioritising for a Backend Engineer with experience with Kubernetes and Golang and/or Rust, with new roles on the frontend in TypeScript, React & Rust in future. Please see our careers site or the linked job posting for more information, or contact me directly at chris@silicoai.com.

Careers Site: https://careers.silicoai.com

Backend Engineer Role: https://careers.silicoai.com/jobs/1369103-software-engineer-...

Arrow itself is a standardised in-memory columnar data representation. The benefit of this is you can then send data between processes without needing to be concerned with serialise/deserialise. There's then a growing ecosystem around this, e.g. Flight for making the sending of data easier, DataFusion for querying, etc.

Sheetless | London, UK | Full-Time, Remote (UK Only) | https://sheetless.io

Sheetless makes it easy to model complex systems and explore decisions before making them in the real world. We're building a platform that allows analysts, data scientists and management to build and collaborate on better decision making. From no-code model building, through scenario simulation, data comparison and generating actionable insights into the systems at work.

The challenges involve building highly interactive and data intensive interfaces in a Simulation IDE, spanning the gamut from UX concerns through to low-latency compilers. We're also building out the infrastructure to enable simple data connectivity for models, real-time analysis, and scale-out for compute intensive workloads for analysis and optimisation.

We're currently 5 people, have recently secured VC backing (pre-seed) and are building out a core engineering team, with positions open on frontend and backend. Technology stack is TypeScript (Next.js), Rust, Hasura, and deployed on GCP. We're interested in Go/Java engineers with DevOps experience for the backend role.

More info on our careers portal at https://careers.sheetless.io

Sheetless | London, UK | Full-Time, Remote (UK Only) | https://sheetless.io

We're building a simulation platform for the modern enterprise, enabling organisations to build digital twins of themselves, to bring together data and human knowledge to give better support and guidance in making decisions. We believe the future is in tools that provide collaborative and explainable predictive power to decision makers.

The challenges involve building highly interactive and data intensive interfaces in a Simulation IDE, spanning the gamut from UX concerns through to low-latency compilers. On the server side we're then providing services around on-demand computation, analysis, and compilation.

We're currently 3 people, have recently secured VC backing (pre-seed) and are building out a core engineering team, with positions open on frontend and backend. Technology stack is TypeScript (Next.js), Rust, Hasura, and deployed on GCP.

- https://careers.sheetless.io/jobs/981287-frontend-engineer

- https://careers.sheetless.io/jobs/985470-backend-engineer

Excalidraw can store the files, although it's a little hidden: the link option in export gives a link that downloads an encrypted JSON from their server.

Apologies, had the group configured incorrectly, this should now work. Thanks for letting us know!

Sheetless | Front-End Engineer | London (Remote) | Full Time | https://sheetless.io

Sheetless is creating a modelling tool to bridge the gap between spreadsheets and specialist packages, helping people to move their knowledge about the systems they know out of their heads and spreadsheets. We're making it easier for people to understand systems and make better decisions to improve them, whether that's a business, or the environment.

We're a SaaS product, developing using TypeScript/Rust languages. On the frontend we're using a stack of React/Redux/Next.js/Material UI, along with some Rust modules powering the simulations. As a first hire, we're looking for someone comfortable and capable to build out new UI/UX around building simulations, with a focus on making things accessible for non-experts.

We're early stage, with initial funding and eager first customers. We're fully remote, but with a preference for being within a timezone or two of the UK.

If you're interested, you can find a full job description and contact details at https://sheetless.io/careers

I've found Rust is great for doing heavy lifting (parsing/compiling/graph analysis, etc) on the frontend, as long as you can define the boundary between wasm/JS reasonably cleanly. And in that code I don't think there's a productivity hit as you can benefit a lot from the stricter types (ADT pattern matching, etc) and more reliable performance.

For more straightforward UI code, I'd agree that TypeScript strikes a much better balance right now, especially for (almost) seamlessly working with the wider ecosystem. I moved away from Scala.js because defining the boundary transition was quite error prone, but maybe I was missing something.

I don't think it's fair to say React hooks are optimising for writability, even if they are much shorter, but modularity. While lifecycle methods are 'obvious and straightforward', they often spread related functionality across multiple different functions, which can be more easily grouped together with hooks. And if you have similar lifecycle-based functionality that needs to be shared between multiple components, you end up with a variety of not-great solutions, whereas that is simple with hooks.

That's not to say hooks aren't without a downside, it is more to learn, with a different mental model, and their own edge cases. But having used hooks exclusively for a larger project, I couldn't imagine going back to lifecycle methods.

Personally, beyond development, I haven't found rollback migrations particularly useful. Once you've run migrations on a live database, it's often much simpler operationally to treat any rollback as a new migration, to keep things append-only.

From that perspective, while rollbacks are nice, the technical investment needed to auto-generate sound rollbacks for all DDL operations is probably vastly outsized compared to the benefit, so I can see why it wouldn't be a high priority, especially if targeting multiple databases. If you're writing things by hand, there's not a whole lot of difference between the two.

Sheetless | TypeScript Engineer | https://sheetless.io | London, UK | Full-time | REMOTE

Sheetless is creating an IDE for simulations, helping people to move their knowledge about the systems they know out of their heads and spreadsheets, and into a more helpful tool. We're making it easier for people to understand systems and make better decisions to improve them, whether that's a business, or the environment.

We're a SaaS product, developing using TypeScript/Rust languages. On the frontend we're using a stack of React/Redux/Next.js/Material UI, along with some Rust modules powering the simulations. As one of our first hires, we're looking for someone comfortable and capable to build out new UI/UX around building simulations, with a focus on making things accessible for non-experts.

We're early stage, with initial funding and eager first customers. We're fully remote, but being within a couple of timezones of the UK is preferred.

If you're interested, you can find a full job description and contact details at https://sheetless.io/careers

1 round doesn't give a very good layout, 8-10 rounds seems to be enough for a good layout most of the time

This doesn't seem to have been updated in a year. How does this compare to other projects such as https://github.com/jsverify/jsverify which are currently more active?

Postgres used to have timetravel built in, but there's still a basic timetravel implementation in the contrib: http://www.postgresql.org/docs/9.4/static/contrib-spi.html

Looks good, just giving a shot at integrating. On the API, it would be great if your events API would accept a user-agent string, would make generating events on the server easier, and lighten the JS blob for clients.

"awesome" lists are rather common, there's even a meta-awesome list of them:

https://github.com/sindresorhus/awesome

Relay looks like it will partially replace Flux if you're using it to manage the client<->server state, but Flux still seems necessary if you have a lot of intra-client state to manage (such as in a document-editing SPA).

Thanks, that's useful, I'll take a look at moving across.

Is there much benefit in using Phoenix for the server for a SPA where 95% is API routes, over using Plug directly? I guess it might make adding websocket services easier in future? (I've been very impressed with Plug/Ecto, just wondering if moving over to Phoenix while not too entrenched would be worthwhile.)

Well yes, it's not ideal for all development, but you professed a need for smaller filesize, which it's ideal for. Naming conventions can alleviate most of the variable issues, it's just another way to solve the problem that has some advantages and disadvantages.

(I don't use it myself, due to the current project being too large, so I use require.js in conjunction with amdclean which removes a lot of the module loader overheads.)

If it's just a snippet, and require.js made up 20% of the filesize, then why not just have a single file, or assume a single closure and concatenate a few files together? You'll gain even better filesize from minifying inside a single closure. The formalised step up from this is SMASH, which is how d3 is built: https://github.com/mbostock/smash

Rust relies on a newer version of LLVM than Emscripten is based on (as Emscripten-fastcomp is based on the PNaCl fork of LLVM, which is lagging behind). Once the PNaCl fork is updated and Emscipten rebases, or they rebase onto LLVM proper, then it should be doable fairly easily.

The second link by uulbiy (https://www.reddit.com/r/privacy/comments/2j9caq/anonabox_to...) shows they were much more deceptive (in direct questions) than just being vague on their kickstarter page.

Not who you're replying to, but there's a similar class at Cambridge where you implement pong/game of life on an FPGA board. Some of the practical course notes are available publicly, though the full computer design notes referenced are not. There may be some interest in the basic sources and approach however: http://www.cl.cam.ac.uk/teaching/0910/ECAD+Arch/

(Linked to the course I know from a few years ago, the course has since changed)

Yes, this seems like a much better approach. I mean, creating components based on path state is completely trivial, once you have state driven by a router, and lets you be explicit about how state is moving around. react-router seems to be taking a more covention over configuration approach (this.props.activeRouteHandler? Really? Why does the top level routing need to specify the deeply nested components? What if there are multiple components in the interface that depend on the route? etc. etc.).

Do you mean a ClojureScript compiler compiled to JavaScript? ClojureScript can be compiled and run in v8 just fine right now.

There are actually two main React libraries for ClojureScript, Om[1] and Reagent[2]. There are also other libraries for doing the templating if you prefer hiccup[3] or enlive[4] style templates, which I find a bit more readable than straight function calls.

Overall though, React seems to be shaping up as a great solution for building reactive templates that isn't tied into larger frameworks like the solutions within AngularJS or Ember.js.

[1] https://github.com/swannodette/om

[2] https://github.com/holmsand/reagent

[3] https://github.com/r0man/sablono

[4] https://github.com/ckirkendall/kioo