I'm totally mapping over the concept of mapping right now.

hahaha

Grue, I was responding to (what I took as) your complaint about the idea of mapping over objects with libraries that do provide that ability. It sounded like you didn't like doing it on principle -- maybe I misunderstood?

The entire Ethereum coding ecosystem is hot garbage. They may as well use POM to setup their NodeJS instances so at least it would be consistent hot garbage across the board.

... my only exposure is something with NodeJS and Clojure that failed to work correctly in either language. I thought it was nearly impossible to screw up Clojure deps, but I was wrong. Solid gold.

Eh, If I still lived in Austin, I'd come see your talk. Be sure to TR it for us.

I have no idea what's going on now -_-

He's talking about Array.map() in JS.

They're saying: With lodash, you can use .map on things other than arrays - so they disagree with it always being better to use vanilla JS for Array.map. If you're already using lodash for OtherThings.map it's more consistent / easier to read / maintain to use lodash for all .maps rather than switch between lodash and vanilla depending on what is being .mapped

I think.

Maybe GM is having a moment like my standard nitrous nod-off/moment of divine clarity - when I clearly see how the secret to the universe is recursion. But then it's gone a half-second later.

His secret is mapping.

Bingo!

This is just going to be a brown bag thing at work. We have random talks about whatever. I'll probably just introduce the syntax and then point and laugh at some of the idiocies.

When I say it's broken I don't mean it's "bad" or "inelegant"

It has gaping security, performance and correctness holes. It's difficult to even write a "hello world" type program without making major mistakes.

So in continuation of my last question.

I receive an object from an API, that has nested arrays with objects inside them:

object = {id:1, name:"hi},
{id:2, name:"there"},
{id:3, name:"2+2", subObject: [{id:4, name:"how"},{id:5, name"to"}],
{id:6, name:"access"}

I'm then given an array such as:

array = [1,3,5,6]

And I have to traverse the object and nested array objects to create an object that looks like:

result = {id:1, name:"hi"},
{id:3, name:"2+2"},
{id:5, name:"to"},
{id:6, name:"access"}

I'm kinda struggling on the optimal approach to this. Reading online there seems to be a lot of different ways to accomplish this, between using Object.keys as we discussed above, and even some people suggesting recursion (which seems too "slow"?).

This data structure is fetched when the app is bootstrapped, so if there is some major performance gain ( i imagine there won't be) to iterating through the object and storing all the ids and names in a flat object, before they are needed later in the app (or aren't ever needed) that's an option as well.

Is "object" an object or array of objects? What you have shown isn't valid as either.

Ok this is making a lot of assumptions. Also your typos in the starting object were fun to figure out. When did jsFiddle stop highlighting syntax errors? All I got was "unexpected string - line 46" when I tried to run it, and there is no line 46. I had to go to code pen to figure it out.

Assumptions are 1) that you meant to start with an array of objects, 2) that the id property is unique (seems safe), 3) that the entries show up in your startingObject in numerical order. If not then it's a somewhat tricker problem, but you can always just do a result.sort() at the end.

If max performance is required you would probably do some things differently.

My bad this is more literal:

object = { objects: {
'0': {id:1, name:"hello", subObject: [{id:2, name:"suzzer"}]}}}

The ids are unique, while the main objects are in order by id, the subObjects id's are out of order.

I can get the object into an array objects tho easily by doing Object.keys

Yeah, what you've shown is effectively just an array, so you can still loop over it the same way I did.

Unless your results object is huge, a result.sort() at the end could be the best way to go.

With ids out of order in subObjects, one way or another you're going to be looping more than once. You just need to know which sets are smallest and try to do the extra looping over that. IE - you could sort the subObjects by id first, then call buildResult - if you want to avoid the results.sort() at the end.

startingArray.indexOf() is also doing implicit looping, but it's optimized by the JS engine. Which is good.

Well I did put them in order in my results, but looking at the data ideally the sub objects would come after their main object, since they are related.

It would be like saying:

Depts in company: IT, engineering, r&d, finance, accounting

If you are just trying to list each dept but in the data structure engineering and r&d are sub depts of IT. So ideally they would come after, but Engineering is id:1 and the other two are 55 and 56.

This lasted all of one day before he brought "his" site back up and I let a mod ip ban him. He had over 1000 games played... Average of 20 minutes per. Yikes.

Doesn't sound like a massive performance case unless your company has 100k departments. So just go for max code clarity.

Is it common to never really use patch and delete?

99% of the endpoints I hit just accept a post and I determine on the front end if stuff is getting changed and deleted by the request shape.

Yea the object is small, thanks!

A few years ago I stopped using HTTP methods as semantic information. If you want to delete something, make an endpoint like
/api/things/mything/delete

On a related note, I don't use http status codes for semantic information any more either, except for errors (and there I pretty much just use 400, 403, 429 and 500)

There was too much of back and forth between FE and BE about "what method do I use to do so forth" or "what does a 201 mean for this endpoint"

Just return in your results whatever semantic information you have.

I agree actual http codes can get out of control.

We have had a lot of success with human readable error keys like CREDIT_CARD_DECLINED or ADDRESS_NOT_ELLIGIBLE etc. The advantage a front end dev (front end could be browser or node presentation layer) can see a brand new error code and often know how to handle it w/o consulting the back-end or trying to look it up in an ICD doc somewhere (which is probably woefully out of date).

I've had to fight so many battles about this. The back-end guys always just want to return some in-decipherable code (http, or internal status code) that the front end devs have to look up somewhere.

Another big battle is getting the back-end API to return payloads and errors in a consistent way - so the front end can write generic connectors to handle them if desired. They always want to wrap a successful payload in some unique object name, which is absolutely useless and just adds one more thing the front end devs have to know.

Also we have multiple teams developing back end MSes. Incredibly at first they all thought they could just roll their own errors in whatever format they want. It never occurred to them that they should sync up and deliver errors in a standard way - until we started complaining.

This is why big non-tech companies are bad at microservices. They don't communicate, not pro-active, different groups don't trust each other. After two years of beating our heads against the wall - I'm convinced it's a bad idea for us that will mostly never succeed company-wide. It has had some success on a very large app - but most of those devs are all in the same group, and the system designer/implementer is an all-star that we're lucky to have - which makes all the difference.

I also agree that GET/POST/PUT/DELETE only makes sense if you have a pure CRUD app, which who has those? There's always normalization and usually for us anyway connecting to back end services. So we just use GET if the primary purpose is read only, POST if the primary purpose is changing something. I still think that convention has value.

Yeah I think we're on the same page there. These semantic error codes and http methods also introduce another wrinkle.

Several years ago I made the most minimal framework I could think of, which adheres to a few specific design principles
1. API endpoints should behave exactly like normal python functions, and in 99% of cases should not have access to a "request" object or anything special from the webserver. So if you want to internally extend an API, you can just call it like a normal python function

2. therefore these functions should only take as input json types. numbers, strings, lists, dicts, that's it.

3. these functions should only return json-encodable results (note: you can return an object, but if you do it has to be json-encodable. In my framework this means it supplies a json() member function

4. these functions take config via very minimal decoration. Basically you can define access to the function, you can control the URL structure a little bit (usually not necessary)

The end result is a self-documenting API. Not only self-documenting, but self-SDK-ing. The framework provides an endpoint that lists every function along with it's arguments and config parameters. I have a little piece of client code that consumes this endpoint and produces functions that you can call, that are basically proxies to the API endpoints.

So from the point of view of the client, the function in their local code looks and acts fairly identically to the function in the API. This means that you can take a piece of code that is normally all server side, and transplant it to client side, without having to change anything. (and vice versa) It allows RPC type behavior without having too care (to much) where the boundary between local and remote is.

You can also auto-generate JS clients for it - so we can autogen angular things (I think these are called 'services')

The framework doesn't care if you call via GET POST PATCH DELETE or whatever. It doesn't care if you pass form variables or json or url parameters or some mix and match. It doesn't even provide you a way to return "201" vs "200" http codes. You can return 400/403/429/500 via raising appropriate exceptions.

It's transportable between django and flask with no modifications. I could probably make it work with pyramid or any other python web framework without too much trouble.

I got a new contract.

For the first time ever, I'm working with someone who actually knows what he's doing. Normal contracts are with a dev who ditched a dog on their lap, non-tech folk, and various other types along the scale. Sometimes, I work under a dev, but get no guidance.

It's also more long-term. Very strange to not have to worry about what I'm going to be doing next week (assuming I'm not exposed as a lout).