Update: received 3rd offer from DBAM, and it is finally legit as ****:

Base: current salary minus 30k
Bonus: 25k/yr
RSU: 420k (blaze it)

So:
- ILPS: total comp is current salary + 50k cash + 50k private stock
- DBAM: total comp is current salary + 100k

That is...game-changing. And man, having multiple offers is crucial, they've gone up 100k since this started, all just to compete.

Not sure if this is a positive or negative, but I did disclose the ILPS offer to DBAM, and it looks like they (finally) decided to match it. I had previously resisted telling them the exact details, but after telling them yesterday that offer #2 was not enough, the recruiter specifically said "I know you said you didn't want to tell us this, but it would really help give me leverage with the compensation team". I was inclined to believe him, given that offer #2 was still a bit low even after me giving them a target I wanted. So, I told him.

This has me leaning towards DBAM again.

It's good for sure. Just compared to some other stuff going on, especially in CA, it's just $$ instead of $$$ or $$$$.

It sounds like a pretty great way to get your feet wet again if you wanted to use it as a stepping stone to transition back to development full-time. Congrats!

awesome goofy.

I'm sure there's stuff that sucks at any giant company (my friend who worked at Google didn't like it), but I think it would be awesome for a couple years anyway. Like going back to college only getting paid lots to do it.

And, imo, be careful not to overvalue the upside of a start-up. You could always invest in startups, but you'd never put the equivalent time and money into a risky investment for good reason - unless maybe it was your idea and people were investing in you after they find out you left DBAM to start the venture.

Yeah I thought about that. But do I want to do that to run integration tests every time I update a lambda? The whole idea with lambdas should be that they're independently deployable.

However this does bring up the same issue would happen when deploying multiple dependent lambdas to production. You need a way to turn them all on at the same time. Hmmm.

Damn Goofy killing it. Nice work man

And thanks for documenting the journey. Its nice to live vicariously through braver souls lol

Not to go around and round but didn't you say the problem was when the lambdas weren't independent and required coordination.

It does sound like you need someplace to handle these dependent cases where lambda a is going to cause lambda b to fail acceptance tests. Someplace that will throw warnings that prevent a push to prod but doesn't wake anyone up. Can you play tricks with semantic versioning and having integration tests throw warnings instead of errors for version numbers ahead of their own number?

Yeah that might be the answer. But for now nothing is gonna get pushed to prod automatically. That's the last step on a long devops journey that I have my doubts few shops ever actually get to.

I was thinking about feature flags but that seems like it's more for multiple customer configurations in one common code base. This seems like you need a canonical order for your lambdas so when there are contingency issues you can do the upgrade in the correct order. Although that's probably only a problem when you have a version that isn't backwards compatible with previous version numbers.

Thanks for bringing it up, I miss thinking about this stuff.

Yeah it could end up not even being an issue. We'll deal with it when it comes up I guess.

I have no experience with lambdas but with apis we?d solve it with versioning. So you could release a new version of an API call while still supporting the old version for services that haven?t been updated yet. Then when nobody is using the old version you kill it. Not sure if that can be applied to the lambda world.

Goofy, that?s awesome.

Yea great stuff goofy. I'm now firmly in DBAM camp.

Had a serious company wide meeting today and it looks like my project from the last 6 months is getting nuked. It was supposed to be a new product similar to another product we have (call it project A) and my project (project B) was supposed to consume that one eventually.

Well, guy that basically singlehandedly ran project A left us kind of out of nowhere for a FANG today. So the product people are going to put their eggs into that basket and use the stuff i?ve worked on and apply it to project A, where applicable. I?m supposed to continue dev work on this project until they say otherwise but i?m kind of flustered.

OTOH it takes a big stress load off me, because I was really doubtful about the long term success of this project. It did what it was supposed to do - mostly as advertised - but it felt we were developing for a user that didnt exist and it was poorly defined. I?m still in shock though and feel I need to grieve, **** man 6 months just gone. And i know NOTHING about project A because they purposely kept me away from it. Now i gotta try to get up to speed and see what I can do there.

I feel a lot better about the long term of this company though - they do have a plan and it seems like it could work. I feel a little blindsided though.

We keep losing people to FAANGs which sucks but also tells me i?m probably in a good place for my career

Suzzer,

IDK if this will help, but have you looked into the new Layers feature for Lambda that was announced at re:invent a few weeks back? It's (apparently) improved code sharing stuff for Lambda. I haven't dug into it so I don't know if it has anything to help you here, but it's worth checking out.

Nice!

One perspective is that you sort of answered your own question: "The whole idea with lambdas should be that they're independently deployable." Once they aren't independent, they shouldn't be separate.

Not too different from how microservices turn into a disaster (or start off being a disaster when logical domains aren't clear).

No I'm getting into that right now. I think it will be great for stuff like node logging packages.

Right. Once we have a fairly stable system - if a lambda introduces breaking changes it should be a different version, and the other lambdas can upgrade to the new version at their leisure.

It's just about tricking the integration testing environment I guess.

I'm trying to formulate our first integration test now. It's kind of a weird flow though so I don't think it's gonna be a blueprint.

Flow is after a user signs up and confirms their email (eventually mobile too) in Cognito, it triggers a lambda. This lambda calls 3 other lambdas. #1 tries to look up the user in our CRM system based on email (eventually mobile phone too). If the first lambda finds one match the next lambda saves the CRM ID to cognito. The 3rd lambda saves the user to our local dynamo DB. Async/await is glorious here btw for reducing code mess.

I'd like the test to be as real as possible - IE connect to a stage version of cognito, our live CRM and a stage version of our app dynamo DB.

So to prepare I guess I need to 1) populate a user in cognito and 2) blank out a stage dynamo DB. Our CRM will be trickier as we don't really have a stage environment. So I will probably switch emails to a dummy user we have in the real system. Then I will execute the lambda and assert results - basically the same thing the Test feature in the lambda console does - minus the assertions. Then I have to clean up when done.

Should be interesting. I've been googling for any 3rd party stuff that does this out there and can't find anything that seems relevant. I have found some blogs that describe stuff like this and they basically built their own system.

For most of the integration tests it will be a lambda that's exposed to the web client through API Gateway. So for those I can use some standard HTTP testing tool like supertest. I might also use cucumber as a BDD layer which calls supertest under the covers.

I'm changing plans and developing this remotely (at least the api server). I have no problem putting a react-native app on my phone that gets data from an api on the inet. In order to get my phone querying my local machine it was just one thing after another, turning the development tools on my phone on (you touch the build number 7 times - weird) and then still having to install android sdk on my computer (which is almost a whole gig), to get my phone set-up. Well, it could be easier than that, but I think I'll get this working faster the other way.

Micro - when you npm start your project, it will output a message similar to this:

I added the blue highlighting. To test on a phone, just point your phone's browser to this highlighted IP address. It will probably be different for you. Of course you're phone will need to be connected to your wifi and not cellular data.

You shouldn't be trying to get your phone to connect to localhost, if that's what you mean by "local machine". There should absolutely be no need for developer mode and android SDK - I guess this is leading to run ADB and USB network connection to your machine?

You may need to change your axios calls to relative paths ("/api/foo", if you are currently using "http://localhost/api/foo") - but that is unlikely and you'll be doing that anyway later on when you try and host elsewhere.

Yup. Should be listed under ifconfig as well or whatever the windows version of that is

I think he's talking about getting his phone running in dev mode so he can deploy Android apps to it and debug from computer, which is what the dev cycle looked like for me for the 1 React Native project I worked on (the aforementioned beer inventory tracker). Or just for doing any Android development in general, really.

Ah yeah I could well have missed the keyword "native" in there...

Maybe I'll try again tomorrow night. It is "native". It's very cool how the React Native app (using Expo I reckon) worked really easily just by taking a picture of the QR code thing. That was a snap. Requesting something from the server running on my desktop, not so much, and the 192.168.x.x address was easy to find and I tried it with all the related ports (react app running on 3000, flask on 5000 (should be the one I want), react native was showing ports like 19000 and 19001)

I did sign up for Linode though and have been setting that up.

I do successfully have the react app making requests to the flask server, both on the same machine - servers on different ports.

Seems like what dave said should work though? I'll be happy if I can just get a response from the flask server from my phone.

I don't really enjoy this part of things - networking/IT/installing and configuring software - but it is what it is.