Hacker Newsnew | past | comments | ask | show | jobs | submit | MichaelNolan's commentslogin

> Fiberhood coop sells a 16kWh battery for $1800

Is that available in the US? Can you share a link? That’s an amazing deal. I’ve been recommending server rack batteries (5kwh for $750) to people but if there is something better I’d love to see it.


Price quote in this thread below, 10.680 kWh for $700.30, $230 for charge circuitry, electronics, we call Enernet Power router.

Fiberhood has an office in Tucson Arizona and will ship to the US if you want to to pay Trumps tariffs. I'm not aware of reasonably priced good battery or inverter makers in the US, besides ourselves (we are a non-profit so we are cheaper).

It is however not that simple to just give you a link, we need to hear from you for what electronics the software system needs to be fine-tuned. We need to understand what battery and electronics you need for each situation. As a scientist I know for a fact that no one in the world makes good battery systems yet, they are all wrongly designed (especially the ev and car batteries). You can easily spot that yourself, no one charges each individual battery cell individually in parallel. Everyone, including the scientists, charges battery packs in series and has battery management systems and ac-dc or dc-dc inverters that are not designed for the particular battery type and brand. Not a single one. If you ever find one that does charge and discharge each cell in parallel and slowly between 50% and 80%, please tell us and we'll tell the world. Right now only Fiberhood electronics charges cells correctly with specially made charger circuitry. The $0.50 to $2 networked printed circuit boards per battery cell we currently sell are the prototypes for the $0.10 battery charging microcontroller chips that we are making.

You can find dozens of Youtube influencers who test and or build cheap serially charged battery packs and your server rack batteries and inverter systems that you can find on professional China business directories, Tabao, Aliexpress and the like. But they are not exactly what you need and they damage your cells by charging them wrongly. No service, no warranties, no insurance, no buyers protection, buyer beware.

Be aware that ordering such systems directly in China is fraught with difficulties, its easy to lose your money.


> But I keep wondering if they could integrate at a lower-level than the source code.

I’m sure they could, but targeting go source code has the benefit of giving early adopters an escape hatch. If it targeted LLVM directly, I would never consider using this at work since the risk of it being abandoned is too high. But since it targets go source, I would perhaps consider it for some low importance projects at work.


The standard go toolchain doesn't use LLVM. Go has its own assembly format and machine code generation.

How big of an install are you looking to do? I just did a ground mount install on my property. (4kw panels, 5kwh battery) If you are good with your hands, and can follow instructions then I would recommend you do the work your self. The actual installation of the panels and battery are close to plug n play. The cost of an electrician can easily double the project costs for small projects.

For the panels I did whatever was cheapest on signature solar. For batteries and inverter I did eco-worthy. (eBay for that, they run sales pretty often) in total is was $1000 for the panels (that included delivery) and around $1200 for the battery and inverter. If you have a truck then you might be able to find cheaper panels locally.

On YouTube check out DIY Solar Power with Will Prowse. He is a certified electrician and publishes part lists and plans that are easy to follow.



Kind of a weird headline. It makes it sound like this just happened. But it happened almost 2 years ago. Reading the article is also a bit confusing. I finally figured out they are only referring to utility scale solar and not total solar (utility plus behind the meter)

My overlay of the data: https://eia.languagelatte.com/

Raw data: https://www.eia.gov/electricity/data/browser/#/topic/0


Presumably we have dammed everything that made sense to (and some that didn't), so solar / wind will keep growing while hydro is unlikely to change (unless it drops).


> Waymo fatalities: 0

By some measures Waymo is actually at -1 fatalities. There has been one confirmed birth of a child in a Waymo. https://apnews.com/article/baby-born-waymo-san-francisco-6bd...


I think the car would have to be more actively involved in the process for that to count. :)



Uber does offer a similar setting in some markets. It took a while to roll out in the US because of legal uncertainties. So Uber waited until the feds gave them a promise that no action would be taken related to offering a “women only” or “women preferred” feature.


If you’re using Alpine already, then is there a good reason to use HTMX over alpine Ajax? They both look quite similar to me, but I don’t do enough front end work to tell the difference.

https://alpine-ajax.js.org/comparisons/


Htmx offers more flexibility than Alpine Ajax. Here's an example: htmx allows using relative selectors, which allow you to target elements relative to the triggering element in the DOM tree. This gives us a lot of power for swapping in pieces of UI without having to make up ids for lots of elements.

I have a blog post in the works for this feature, here's a small code sample I made to show the idea:

    <div class="card"> ╾──────────────╮
      <header class="card-header">    |
        <a                            |
          class="button is-link"      |
          title="Load links for #167" |
          role="button"               |
          aria-expanded="false"       |
          href="/app/notes/167/links" |
          hx-trigger="click once"     |
          hx-boost="true"             |
          hx-push-url="false"         │
          hx-target="closest .card" ╾─╯
    ╭───╼ hx-swap="beforeend show:none"
    |   ><b>±</b></a>
    |   <a
    |     class="card-header-title"
    |     href="/app/notes/167"
    |     hx-boost="true"
    |     hx-target="#note"
    |     hx-swap="outerHTML transition:true show:window:top"
    |   >#167 Velificatio</a>
    | </header>
    ╰╼
    </div>


I have tried to use exclusively each of the libraries to better understand their limit, overtime I got to the following observations:

- htmx is more straightforward (because a lot of the magic basically happening in the backend) and helps a lot to keep some sanity.

- Alpine shines when you need more composition or reactivity in the frontend. But it gets verbose quickly. When you feel you are reimplementing the web, it means you went too far.

For pagination, page structure, big tables, confirmation after post etc. I usually go with htmx. Modals, complex form composition (especially when you need to populate dropdowns from differents APIs), fancy animations, I prefer Alpine. (I probably could do that with htmx and wrapping it in a backend - but often more flexible in the frontend directly.)

To me, the main reason why I use these libraries, is what I write today will still be valid in 5 years without having to re-write the whole thing, and it matters since I have to maintain most of what I write.


> The real problem with Java in particular is you'd end up chaining calls ... and have no idea from the error or the logs what was broken from: a.b.c.d();

That’s been solved since Java 14. (5 years ago) Now the error will tell you exactly what was null.

And “soon” Java will have built in support for expressing nullability in the type system. Though with existing tools like NullAway it’s already (in my opinion) a solved problem.


Chaos testing is such an interesting idea. At my last job we didn’t have access to any of these tools. So I made a poor man’s chaos testing library for Java and spring services. At the application level we would inject random faults into method calls.

It doesn’t test nearly as much as the real tools can, but it did find some bugs in our workflow engine where it wouldn’t properly resume failed tasks.


> but it did find some bugs in our workflow engine where it wouldn’t properly resume failed tasks.

So ad-hoc, home-grown, chaos testing is still a useful exercise!


No one has used this code in years, and its kind of half baked, but here it is https://github.com/Michael-Nolan/Public/tree/main/SimpleChao...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: