imajes

'course it's not just him, but it's him and _everyone else_. i'm not sure what their overall intent here was, but it's been a shit show from start to finish, and they gotta at the very least start thinking hard about pausing the rollout till they can get their ducks in a row.

Hey- what's the best way to get in touch? :) thanks.

looks awesome- i'm assuming there's no secret funnel for HN with preferential pricing? :)

  - All teams will henceforth expose their data and functionality through service interfaces.
  - Teams must communicate with each other through these interfaces.
  - There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  - It doesn’t matter what technology they use.
  - All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  - Anyone who doesn’t do this will be fired.  Thank you; have a nice day!

still kinda works.

What is the value proposition of tieing an ingester, parser, transactional service (e.g. all written with go), and then tieing together your api, client app, mobile app (all in js), just because they share a common language?

arguably they aren't close to each other in tiers of the stack, and don't really overlap. The sorts of libraries you might choose to use to do something could differ, (e.g. json processing - in the front end, you'd pick usability and security over a lower level more optimized transcoder for the api).

That said, I agree with your core premise- not understanding, and chasing a nail with a hammer, but geekily named repos per language just sounds like someone who doesn't understand how something git works...

It's also worth noting that this article is 5 years old. Perhaps the tone is reflective of that..

Yeah, i had a client using it who found that being able to get the data into a reporting scenario so they could file was hard. Mostly it surrounded reconciliation and an ability to gain confidence that the numbers reflected actual transaction volume (it is a perishable good, so there was a reasonable quantity of discounts and refunds as delivery vendors missed targets...)

I'd also say I have a bias, as I've also used avalara a couple times before and found it to be quite a bit superior in making it seem quite a bit more effortless -- taxation is so byzantine I don't have any expectation that I could understand it, so I want to trust that the provider i use is very confident they do.

not sure if that helps a lot, but it was also a few months ago ;)

FWIW, I can tell you that taxjar is pretty light on the "I've collected taxes, now what?" side. Avalara might be a BigCo but they have their stuff together, and it works at scale for transactions (especially when dealing with refunds or discounts that need to reflect Sales Tax differentially.... oy)

Depending on how you feel about such things, a "build a wall" campaign could be pretty ingenious with your product. :)

Except that'd probably fall into the CFPB remit, which has just been significantly reduced in scope and veracity due to the current administration... :(

in the NTSB investigation, it appeared that there was literally only about 30 seconds at the outset to evaluate returning, and even then, with immediate returns, pilots were only able to return 7 out of 13 tests. Textbook and theory doesn't always supercede knowledge of the area and novel thinking.

The delta between a good school and whatever you get assigned seems to make this worth it.

hey, curious why your variables in the go version are so terse? makes following along a little tough!