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.

Correct me if I'm misunderstanding, but this would allow me to register the desired conversion type for a basic postgres type, to and from JavaScript but not for the return value of a specific function or even a specific invocation of a function.

PostGIS uses a lot of functions like ST_AsEWKT, ST_AsMVT or ST_AsGeoJSON [1] to marshal data. While ST_AsGeoJSON will always return "text", ideally you'd want an invocation of ST_AsGeoJSON to return JSON to your JavaScript, but this wouldn't be true of all "text".

Even better, you would want to declare the structure of the returned JSON via a TypeScript type. GeoJSON is a structured format, so this would likely be a generic GeoJSON type wrapped around a custom type for the specific structure you expect for each geometry type / query.

Anyway, it's a tough problem to solve without introducing TS versions of each specialty function, which would be a large effort for an extension the size of PostGIS. For now I use typed raw queries via the sql<T>`` escape hatch provided by kysely, but if your library made this more ergonomic/safe I'd consider switching!

[1] https://postgis.net/docs/manual-3.5/ST_AsGeoJSON.html

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
 

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!

Try the "Modern Javascript Tutorial"

https://javascript.info/

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.

Unfortunately we are unable to sponsor visas at this time. Please only apply if you are a permanent resident of Australia or have a valid working visa.

FLIP (https://www.flip.com.au/) | Senior Software Development Engineer | Melbourne, AU | ONSITE | Full time

FLIP is looking for talented software engineers to help build out our next generation logistics platform.

FLIP is a customer-centric logistics technology company in the heart of Melbourne's CBD. Our platform connects senders with carriers and takes the guesswork and frustration out of logistics management. We are customer focused and value curiosity, integrity and empathy, both towards our customers and each other.

You'll be joining a world-class team of senior engineers, designers and product experts as we tackle the incredibly difficult challenges in the logistics space. We are continuously learning, and each day brings a new set of challenges, both technical and real world.

As a Software Development Engineer at FLIP, you will be doing a lot more than just writing code. You will work hand in hand with our Product and Design team to set achievable release milestones, and meet with senders, carriers and all of the parties in-between to distill business knowledge into system designs. You will build and operate cloud infrastructure for our microservices, and write the code that lives there. You will work with Front End Engineers to design REST and GraphQL APIs for our Vue-based user interfaces. We have a flat structure, so you and the team will be responsible for planning and iterating on the backlog of work that takes us from system designs to working products.

Our tech stack: event-sourced microservices, mostly golang, AWS lambda where it makes sense, Fargate containers and EC2 where it doesn't, all defined by infrastructure-as-code.

Our website is currently being torn apart and re-written, so the best way to find out more about us is just to get in touch. If you're interested in the role or just have some questions, please reach out to discover@flip.com.au. Applicants should include a recent CV, and mention "HN Who is hiring". No recruiters, please.

A big mistake I made when I started mentoring other developers was making the answers to their questions too easy.

I spent a lot of my early career crawling around on linux servers trying to fix weird bugs in pretty typical web stacks. Later on, when other developers needed help diagnosing an issue on a server I would say something like "sounds like X problem, look at the log file in Y". After several years of this, the same devs were still asking the same questions. I was helping them solve immediate problems quickly and easily, but I was not mentoring them.

Developers don't grow by being given the answers. They grow by trying things and experimenting and solving problems themselves. These are the skills and the lessons that will serve them well as they level up their career. Not giving them the answers but giving them the tools to find the answers.

These days, if there's no urgency, I would say something like "where are the places in the stack where a problem like that might occur, and what can we do to narrow down the set of likely issues?" I might give them some ideas, but let them do most of the legwork.

Some people just don't enjoy teaching that much. I think generally most people get satisfaction from helping others, but some devs just seem to prefer working mostly on their own. They still have to write pragmatic and maintainable code (the "dont make messes" part), and they don't level up others in the business, but they can still be incredibly valuable.

In smaller shops, there really isn't anywhere "further" to go past Senior unless you want to take on leadership of other devs. And it makes sense, in a lot of cases once you get to a certain level of experience the most valuable thing you can do is pass on some knowledge and act as a multiplier for others.

I agree this is an important skill (and attitude), but whether it's a core requirement for senior probably depends on the size of your shop. Senior devs who are keen to mentor, passionate about fixing organizational flaws (process development), and are good at managing upwards are starting to tick boxes for Team Lead or engineering management.

If the team is big enough to support it, I think it's acceptable to have a senior dev who doesn't give a lot back in terms of mentoring but handles their projects and doesn't create messes.

When I started at my current company, Senior Developer titles were given out by management. They didn't have the capability or the information to judge people based on technical skills, and the title was mainly used as a perk to keep employees at the company to avoid having to retrain. I feel like this happens in a lot of places, and is probably the cause of what the author describes in the article.

I'm now a director at the same company, and I've laid out criteria for achieving the Senior role that developers seem to understand. It's now something that they can work towards instead of simply aging into, and it makes the title more meaningful.

Core criteria for a Senior Developer:

* Mastery of their toolset, maybe not 100% but enough to solve any problem.

* Ability to take an entire project from start to completion without assistance. This doesn't mean they don't get any assistance or can't ask for help, but if no one is available, they should be able to arrive at a sensible solution to any problem.

* Understand our business, and prioritize decisions that have a net benefit for the business / team. Balance personal desires for perfection against the pragmatic needs of the customer and our business. We're here to do a job.

* Uses their time effectively. If I see a developer who has a few days of downtime between booked client work, I want to see them take on a task or learn a skill that will benefit the business.

* Client facing attitude and communication that reflects positively on the team. We don't put developers in front of clients often, but each should be able to provide notes in a JIRA to help a client understand an issue or clarify available options. Clear, concise, polite and helpful.

These are skills that I think the average developer would gradually learn in five years on the job, but having them spelled out helps junior and mid level devs understand what is important to the business.

The temperature scale on windy.com doesn't really go high enough to depict how hot it is in Australia today: https://www.windy.com/-Temperature-temp?temp,-27.917,137.109...

Without analyzing it too much this seems to be a perfect visualization of the mathematics of music theory. The lengths of string become quite a direct metaphor for the wavelengths of notes on the music scale, and seeing them move together in progressively different "groups" of notes I imagine closely matches traditional chord structures in different keys.

Quite mesmerizing, and mathematically satisfying at the same time!

Rebase has a lot of options, including squashing many commits into one or more "good" commits. This is usually a good thing if you have commits that are "work in progress" commits. You can use squash/skip to avoid having commits in your history that break the project or feature, which is great if you use git bisect.

The major downside of rebase is that even if you don't squash/skip it changes the hash of every commit. This is very problematic when others have ever checked out your branch locally, or made commits that haven't been pushed. It takes greater communication between the team in my experience.

The ability to quickly spin up a "radio broadcast" in Grooveshark for friends was amazing. With a small group of five friends we set up a Friday DJ rotation where one person would queue songs all day and the others listen in. All the "broadcasts" got saved as playlists, which you could "favourite" from your own account and go back to whenever you wanted. People could make requests when they had a "next track" that would segue well with what you were already playing. It was really fun!

I have never had a period of more high quality music discovery and I sorely miss those playlists, many of which featured obscure/rare/live tracks that simply aren't available in today's music services.

Seeing the example of one facial pose video transcribed to three different looking women, I'm imagining a future where Netflix does a/b testing on its shows, using similar tech to swap out different "actors" to find which one resonates with audiences best.

They could even generate a new "cast" for each market, after only shooting the show once.

The type of curve in your video is probably used in about 1/4 of medium range passes in an intermediate level game of Ultimate. So what you've shown one of the best football players in the world is capable of in a low pressure situation, is typical fare for an intermediate level Ultimate player in a game situation.

There is literally en entire sport called frisbee golf that involves that level of accuracy and control in every throw, at similar distances.

I played a lot of Ultimate in High School in the late 90s, and went on to play for the top University team in Australia in the early 2000s while pursuing my undergrad in Comp Sci.

One thing I've noticed about ultimate that makes a significant difference to other sports, is the degree of control you have over the flight of the disc. Releasing the disc parallel to the ground it should fly straight in the direction you release it. But angling it will cause the disc to curve as it flies, quite significantly depending on the angle.

This allows the thrower to curve the disc around defenders or even out of bounds to reach a spot on the field where only your player can get to.

While you can curve a pass or a shot to some extent in ball spots like football, the degree of control is much smaller. This gives frisbee a "3 dimensional" aspect I find really compelling and really adds to the depth of strategy available to players.

Couldn't the web app also verify that the localhost.example.com domain resolves to 127.0.0.1 before attempting a connection?

How would you run a local HTTPS server without the private key?