HN user

robodan

44 karma

Working for the man and dreaming of a mobile robotics startup.

Posts0
Comments27
View on HN
No posts found.

The public version of Google's build tool is Bazel (it's Blaze internally). It has some really impressive caching while maintaining correctness. The first build is slow, but subsequent builds are very fast. When you have a team working on similar code, everyone gets the benefit.

As with all things Google, it's a pain to get up to speed on, but then very fast.

Partial check outs are standard because the entire code base is enormous. People only check out the parts they might be changing and the rest magically appears during the build as needed.

There are sections of the code that are High Intellectual Property. Stuff that deals with spam fighting, for example. I once worked on tooling to help make that code less likely to be accidentally exposed.

Disclaimer: I used to work there, but that was a while back. They probably changed everything a few times since. The need to protect certain code will never go way, however.

Bose sells line array speakers that will happily work if placed behind a standard mic. They are using anti-feedback DSPs to cancel the audio loop this creates. They can be used in a speaker per performer setup.

What is weird is that they don't talk about this. There is a graphic on products that can do this that show the speaker behind the mic. That's it, no text at all. I think the moral of this story is that marketing is weirder than engineering...

Product market fit is a real thing. I'm a typical low end table saw user. You can ignore me at your peril, but many people will have similar values.

I just finished a flooring project that made use of the table saw. My low end $350 saw was perfect for the rip cuts. There isn't another tool that would do it as well, but I might be tempted to try if a low end table saw starts at $500 (which is already way lower than the cheapest SawStop sold today). Do you have data on safety of alternate ways to solve a problem when the obvious solution has been priced out of reach?

As far as what manufacturers promise, I want to see the contract. We been promised "it will be so cheap you won't even notice" so many times that I just assume is marketing bluster from the get go. They will charge what the market will bear and they will exit if there isn't enough profit. Things they said in a committee room are meaningless. The only thing we know for sure is that what has worked so far is about to get banned.

Obviously I don't have time to do all the research you have done. I'm just a typical low end user who is looking at what it will cost me and what options are likely to disappear.

what the manufacturers said You expect me to believe that? Really now. And the BOM is not the only cost, but +$50 on the BOM is probably +$100 retail.

What will the manufactures try to extract is the better question? Answer: As much as they can.

The only other saw with similar technology (Bosch) to hit the US market cost 50% more than the similar SawStop product. They had to pull it due to patent issues (despite attempting a different approach), so we don't have good market data on how well it sold.

This just reeks of regulation forcing everything to be more expensive. I'd rather just see the patent go away and see what the market really does. I really can't image this technology being added to low end saws for less than $150 retail and then you have the per activation costs. It really kills the low end market, when a minimal saw is $500.

That $50 number seems incredibly optimistic. Just the rebuild cartridge is selling for $99 right now: https://www.sawstop.com/product/standard-brake-cartridge-tsb...

And the saw frame has to be much stronger to handle the force of stopping that blade. Throwing $50 of new parts on an existing frame just means you throw the whole saw away after it triggers.

Every time this triggers, you need a new cartridge and blade ($40+) and time to swap them in. If I was sure this was saving a finger (as the dramatic stories in the press state), then I wouldn't think twice. But it probably just wet wood or something else conductive causing a false trigger. Show me the false rate data please.

That may depend on what you're trying to do. If you are figuring out something tricky, then lots of quiet head down time is what you need. Every interruption hurts when you are concentrating.

However, a lot of the time is just figuring out how to glue together multiple systems. Being able to pull in various people to interface little bits is priceless. There is no flow here, only collaboration.

There's a problem in that the danger is in front but the exhaust noise goes out the back. I was once driving cross crunchy in a big truck with a trailer when I was startled by a loud motorcycle coming up beside me. He had been in danger the entire time he was next to me but I never heard him until he got right next to the cab. They should really point the loud exhaust forward but who wants to live with that noise?

I find it interesting that he barely mentions the actors, costumers, set designers, etc. These are the "face" of the show.

I take this to mean that story trumps all in television. You have to know what your core product is.

It's important to remember the difference between the old Google with ~1k people and today's Google with 100k+ people. Things were a lot more flexible back when gmail was a new thing. I started at G in 2005 when there were 6k engineers, but it was doubling every 9-12 months. You could watch the ossification in real time. My experience was definitely one of 120% time. Some people made 20% projects actually work, but that became more rare over time.

I'd love to know how this works out for you. I was trying to do something similar, but got stuck.

The core issue is that the fluent object design approach makes it very difficult to decompose objects into reusable features. The shared state behind the fluent approach makes creating multiple sub-objects (to then combining them) difficult (maybe impossible). The power of Python gets limited to thinking about only one thing at a time.

See https://github.com/dcowden/cadquery/issues/167

They are trying to fix this in 2.0, but that's still in early development.

CadQuery is usually used within FreeCAD. Most of what you describe is there because the part just shows up in the CAD workspace like any other part.

The only difference is that you make changes by changing code instead of doing it graphically. In a perfect world, you'd be able to do it either way; but current technology doesn't know how to relate final characteristics back to the line(s) of code that set them.

As parts and their relationship to the whole become more intricate, the programming approach makes more sense.

Complex CAD parts can have complex construction to get things like symmetry and parametric sizing to work correctly. It's much more involved than word processing, for example. If you watch an experienced CAD technician work, they will often wipe the entire part and start over so that the right operators are applied at the right part in the construction sequence.

So CAD part design is a lot like programming, so why not use an actual programming language? That way you get the editing and version control of a programming language.

OpenScad works fairly well for 3D printing, but isn't very good for CNC. It's internal engine understands volume occupied, but not surface shape. This means it can't output standard CAD file formats like STEP or IGES.

CadQuery uses the same engine that's in FreeCad to output STEP and IGES files. It's Python based, so you don't have to learn another language to use it. FreeCad or other CAD programs can then do analysis or generate CNC profiles, for example.