aethr

The answer to this problem as it's currently being pursued is renewable carbon feedstocks. Growing things like canola on marginal land, harvesting it and turning it into biofuels and LCLFs (low carbon liquid fuels) using renewable solar/wind energy.

It's not a solved problem, though. Truly renewable carbon feedstocks have to source their carbon from the air, not the soil, which has to be continually measured. Land selection for carbon feedstock projects has to ensure it doesn't induce land-use change in other locations due to displacing other things like food production, etc. Otherwise the emissions and environmental harm from those downstream effects have to be included in the carbon positive/negative calculations for the project.

In the logistics industry the commonly held wisdom is that there really isn't any accepted system for "how street addresses work". Different countries have completely different systems, and even within a country there are often many different conventions.

The thing that really matters in delivery is whether the address on the consignment has enough information for an operator to complete the next leg. By the time an item makes it to the region where the delivery address is situated, the local operators usually have enough understanding of the local system to get the item to its destination.

Even if the city in the article has a well defined system, it's probably not feasible for a global product like Google Maps to understand and encode every regional system. This is the problem that geocoding schemes (what3words, etc) are meant to solve, creating a single system that applies globally. But like many "rational" systems that attempt to replace entrenched practices, they struggle to gain traction.

Systems like litdb typically include (or work alongside) a schema migration tool, which either reads the current structure of the database and writes that back to a TypeScript file, or reads a TypeScript/schema file and generates a migration to update the database to match the schema. I haven't seen one that works perfectly, and it's up to you to keep it up to date, but as I said it shrinks the surface of where "mistypes" can occur.

It's quite similar to working with a web API. You can invent all the types you want, maybe generated from an OpenAPI schema, but if the server sends something different, TypeScript can't help you. That's not what TypeScript is for.

At the end of the day, most non-scalar TypeScript types "aren't real". Objects can be mutated at runtime, libraries can ship incorrect types, TS can be mixed with JS, etc. We try to introduce types as early as possible to catch a wide swath of possible errors, but where it's really important you still need to verify at runtime.

Using `as` in TypeScript is a dangerous practice, since it sidesteps the entire type safety system. If it has to be used, it should be used minimally, in controlled circumstances. Using a system like this allows your types to be specified in a very small surface for re-use. If they have to be changed, they can be changed in one place (the schema) which will cause type warnings to flow out if there are any problems.

Futhermore, a lot of the value of these systems is to provide type safety within the query. You choose a typed column in your select clause, and then in your join or where clause the column type is inferred, and warns you if you attempt a comparison that doesn't work with that type.

If the purpose of TypeScript is to add type safety to your logic, why wouldn't you want type safety in the logic that happens to be database queries? I haven't used this library but have used kysely which seems very similar, and all the benefits I enjoy from TypeScript, I now enjoy in my SQL.

> It seems like a step back to have to write SQL in Javascript syntax with a non-standard API.

Like TypeScript, this is an attempt to add type safety and hinting to an untyped language: SQL. With that in mind, some compromises seem inevitable.

Using (from -> where -> select), how would you provide type hints on the where clause when your select includes non-table columns?

  SELECT
    COUNT(col_a) as count
  WHERE
    count > 0
 

Kysely uses (from -> select -> where), and allows joins and selects in multiple places, like (from -> join -> select -> join -> select -> where).

Having recently been down this journey with kysely, these type-safe query builders still seem to have a large gap when it comes to the return types of SQL functions and opaque types.

My current project uses PostGIS which uses opaque types for storing geometry. Geometry columns are added to tables via a function instead of traditional alter table syntax, and select/where clauses on geometry columns need to use PostGIS functions to render the column into useable data.

Unless a system like Litdb includes an easy way to provide type definitions for function return types, it won't be usable with an extension like PostGIS without heavy use of escape hatches, at which point most of the value is lost.

Solar and wind definitely make the most sense wherever feasible, but it's important to keep in mind you can't just build solar and wind farms anywhere. China has moderately good solar capacity in the north, but generation there will be seasonal due to how far north it is. The north of China is also not close to the majority of the population, so transmission will be an issue.

China's high to moderate quality solar capacity will be built out very quickly, and it won't provide enough to close the gap from fossil-based generation. From there, the cost of solar generation will rise as low quality capacity is developed.

China will need a way to import some of their energy generation, possibly through by importing goods like iron and steel that have a high energy production cost, from countries like Australia that can produce them using renewable energy (green iron / green steel) using Australia's almost limitless solar resources.

Since much of Australia's coal is also used in places like China to smelt their local and imported iron and steel, this could further drive down production of coal.

There are plenty of use cases where an established CSS framework is a good choice. For PoCs, internal tools or dashboards, or just short lived projects, you can get very far by utilising a framework.

But if you're building a product, or UX / design is important to your project's success, then I completely agree with the author. You will quickly run up against the boundaries of what the framework provides and start fighting it. The methods the framework uses for extensibility won't be adequate and will hinder your attempts to customise it in the way you want to. Starting with custom CSS means you build things the way that makes sense to you and your team, and avoids a costly refactor later when you decide to ditch the framework.

That does mean that your team will end up designing their own framework! Developers with enough skill and experience to do that well are not always easy to find.

I disagree with the criticism of SASS, but with all the new features landing in modern CSS, it's not nearly as useful as it was even 2 years ago.

One thing that's keeping my hand on the mouse and stopping me from going full keyboard, is the free scrolling mousewheel on logitech mice. I find it such an ergonomic and natural way to get to the right place in long documents (and code).

What I would really love is a keyboard with this sort of scroll wheel embedded just on the edge of the keys. All the keyboards I see with knobs / rotary encoders look cool but I can't see myself using a vertical knob for scrolling a document. Do any custom keyboard builds feature a mousewheel?

Different levels of code quality are important for different teams / projects. Teams that are still discovering the domain and defining patterns should aim for a lower quality so they can iterate more easily. In this mode, knowing that code was written quickly and is fine to throw away / reshape is critical. Aiming for Very Good is likely to be a waste of time here.

In other projects, the domain is clearer, or the system already has well defined patterns that should be followed. In this mode fast iteration is also possible, but it's because the code is clean and follows strong patterns making it easy to understand. Good Enough code here is quite likely to slow the team down as they grapple with needless bugs and code that's hard to decompose / refactor.

The most important aspect of quality is that the team defines the level of quality that's needed for the project or the work being undertaken, and they deliver to that. Have the conversation up front about what level of quality to aim for and why. Then the team is on the same page, and everyone can move forward with the same expectations.

Mentioned in another comment, but if you like Baraka, seek out the film Man With a Motion Picture Camera (or Man With a Movie Camera), it's the progenitor of both Baraka and the qatsi trilogy. There's a version with a score performed by Cinematic Orchestra that is just amazing!

Some amazing music that never seemed to go mainstream:

The Cinematic Orchestra, great modern jazz with a beat. Try the album Everyday. If you're into film there's a version of the 1929 Dziga Vertov film "Man With a Motion Picture Camera" that has a score performed by them, also excellent.

Patrick Watson - Close to Paradise. An ecclectic concept album, one of my all time favorites.

Jaga Jazzist - Starfire. Their early albums are great also. Hectic, energetic ensemble jazz with lots of overlapping time scales and patterns. Sounds a bit chaotic at first but once you recognise the patterns it just clicks and is super fun!

I am working on this right now on a medium-sized project, and it's deceptively more work than we anticipated. While Vue's component API itself is remaining mostly backwards compatible with Vue 2, most of the "core" supporting libraries have changed their APIs: Vuex, VueRouter and vue-test-utils in particular.

After the package update and some very basic find/replace across our codebase, about half of our 600+ tests had to be significantly updated. If your tests regularly mock a Vuex store or a router, be prepared to be making a lot of updates.

If you're using some of the features being removed (filters, $on/$off/$once, etc) or make heavy use of custom plugins, it's not going to be painless.

Having said that, I love the direction the new API is heading and 95% of the changes we have to make are for the better in the end, so it feels worth it.