aethr
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.
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.
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.
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!
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.
SELECT
COUNT(col_a) as count
WHERE
count > 0
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.
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.
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.
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?
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.
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!
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.
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 [email protected]. Applicants should include a recent CV, and mention "HN Who is hiring". No recruiters, please.
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.
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.
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.
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.
Quite mesmerizing, and mathematically satisfying at the same time!
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.
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.
They could even generate a new "cast" for each market, after only shooting the show once.
There is literally en entire sport called frisbee golf that involves that level of accuracy and control in every throw, at similar distances.
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.