Current Electric Vehicles | EV Technologist / Electro-Mechanical Engineer | In-Peson (Northridge, CA) | Full-Time
Current Electric Vehicles is a high-end vehicle restoration and electrification company known for our award-winning builds. Our team of engineers, fabricators, and hotrod builders create custom electric powertrains, restore classics, and push the boundaries of EV technology.
We are seeking an EV Technologist / Electro-Mechanical Engineer who will play a key role in designing and integrating electric drivetrains, battery systems, and custom vehicle components. This role requires deep expertise in battery system design, electric motors, inverters, and mechanical engineering principles. The ideal candidate will have a passion for electric vehicle innovation and enjoy working in a hands-on, fast-paced environment.
Please contact jobs (at) current-la.com for a more detailed job description!
Building an electric 1973 Ferrari Dino to compete in the battle of the builders at SEMA in November. Lots of fun electronics and software, as well as mechanical challenges to overcome.
Unix epoch starts Jan 1st 1970 - could this have anything to do with it? As in, we started getting better at keeping records and more detailed data because of computers?
I have yet to come across a replacement for SQL that makes it easier, or more concise, while also remaining feature rich. Not knocking this, but SQL is a pretty solid and time-tested technology for querying structured data. Alas, if we don't experiment then I guess we wont get better.
I think like 85% of the pain points could be solved by (a) allowing statements to start with a `from` clause, (b) some kind of shorthand for field sets, and (c) having some kind of syntax for returning some things as nested rows/objects. Without thinking deeply at all:
from users u join purchases p on p.user_id = u.id
select u{defaults}, u[p{defaults} as purchases]
limit 100 [purchases: 10]
returning rows that make `purchases` into a row-nested collection of up to 10 items instead of creating that many more overall rows and repeating the same user info multiple times.
SELECT
u.*,
(
SELECT
JSON_AGG(p)
FROM (
SELECT p.*
FROM purchases p
WHERE p.user_id = u.id
LIMIT 10
) p
) AS purchases
FROM users u
JOIN purchases p ON p.user_id = u.id
GROUP BY u.id
LIMIT 100;
Starting queries with from - what is the benefit of that beside personal preference?
And you can simply use a cte or a view instead of a field set.
I agree my off the cuff syntax is probably not great, but I do think there's benefit to a more native version of json_agg that doesn't return strings/json, but typed data.
The "start queries with from" is because you get easier and better auto complete and error detection for queries when the tables being used are declared. When you start typing "select some_field" there's basically no way to have good auto complete or correct until the from clause. IMO there are more philosophical reasons too.
Views and CTEs have their place, but also have their shortcomings. That I don't think this solves. But I also don't think they really fill the gap I'm thinking about either.
Same thing happened to me in the early 2000's during the first dotcom crash. Except my contractor rate was nearly double my full time rate. It was rather dumb, but obviously they didn't bring _everyone_ back that they had laid off.
Exactly around the time the GP was laid off and brought back as a contractor.
I have a pension. It's guaranteed because it's a state government job and state governments in the USA are constitutionally forbidden from abrogating contracts (the Contract Clause, yeah, sure, there are exceptions, but this is unlikely to be one of them).
To fund it they spend 23% of my salary (some taken out of my salary, some additionally funded by them).
However if government pensions did go belly up you’d see the use of QE, which will cause inflation, at which point they are still giving you the promised thousands a month but they aren’t enough to live on, and fuck everyone else over at the same time.
