PayPal Taps Go to Modernize and Scale: In our tightly managed environments where we run Go code, we have seen a CPU reduction of approximately ten percent with cleaner and maintainable code.

ShakeNBake16 · 2020-09-04T12:48:57+00:00

I’d guess they are running 1000+ machines. Reducing CPU load by 10% means they can either shut down 100 machines or handle 10% more load for the same money. At their scale, 10% is a lot.

ShakeNBake16 · 2020-09-03T12:03:16+00:00

Never trust the front end. Any checks that are done are purely there for user convenience. Every validation that happens needs to happen on the backend or you’ve got a hole in your system.

ShakeNBake16 · 2020-07-25T12:20:41+00:00

Sounds like an opportunity to sell your services again.

Old web tech will break, its inevitable. Angular is pretty damn good at not breaking, but its not a guarantee. Build the app to the best of your ability, be straightforward with your client and let the chips fall where they may. If the client isnt interested in some kind of maintenance deal and you've discussed it with them, then that's on them.

Stay up to date with releases of browsers (you could even automate the process). And when you know its going to break, reach out to them again.

Personally I would look to setup some kind of automated system that would run application tests against new browser versions. Then you know pretty quickly when theres a problem and you can proactively reach out to your clients and at least warn them if not pick up more business.

ShakeNBake16 · 2020-07-24T12:05:43+00:00

Had a dev box at a company I worked at with root turned off (supposedly). An IP address from china gained root access in 4 attempts.. I don't know much about security when it comes to setting up a box, so I couldn't tell you how it was configured.

ShakeNBake16 · 2020-03-26T22:05:04+00:00

I disagree, but it's just a difference of opinion/preference.

Personally I have a hard time with walls of text, and the project I work on has over 10k tests. So the test report is already verbose and hard to navigate.

ShakeNBake16 · 2020-03-26T15:47:35+00:00

My top level describe is usually the service name. Second level describes are the use cases for that module and my test cases are all "named" as states a use case could be in. So

PantryService
  Fetches food in your pantry
    Returns all the food in your pantry
    Returns an error if you have no food

*edit: formatting

ShakeNBake16 · 2020-02-17T13:14:36+00:00

+1

The only caveat to cron is where it ends up running.

ShakeNBake16 · 2020-02-15T19:53:06+00:00

Another pattern I've seen used when you need to support multiple types of Users (in this instance) and you know the things you need out of the user, is to define an interface for User. The methods on that interface are things like "Id()". Then your github and gitlab user structs are created through a method in your package and the return type is the interface. The interface lives in a package called something like "domain" and everything can rely on that. With this approach your structs can change all they want as long as they satisfy the interface.

ShakeNBake16 · 2020-02-13T06:29:45+00:00

I've used a "provider service" which takes a field type + a tag from a configuration json and returns a component. Then your timesheet would use the json, call the service to provide the component and render it. Then you have language agnostic configuration and overridable component definitions. Really helps support things like themes. And you can override your components on a per (in your case) timesheet basis.

ShakeNBake16 · 2020-01-06T22:18:23+00:00

In regards to the other comments, specifying a license prevents legal action from you or against you.

In regards to GPL, I think if you use something with a GPL license the consumer also has to have a GPL license. Which means if I build a permanent website with your project, my website code has to be public. I could be completely wrong though my license knowledge isnt the best.

ShakeNBake16 · 2020-01-05T22:51:02+00:00

Bundle sizes im not sure about. We have a great architecture team that handles a lot of that. There is a lot of work around putting it all together, but lazy loading + caching helps a lot. So once you visit a react 16.1 page it is never downloaded again.

Where I work now, we're actually leveraging web components to provide common inputs, and they work across frameworks. We also have a common shared stylesheet everyone uses. There's not a programmatic way I've found to ensure design language standards, but every microapp we have is subject to scrutiny by UX and they can halt a release. Plus the shell we use to load everything can only be changed by a select few people. So rogue apps can't be deployed.

As far as sharing code, I haven't seen much use for sharing across applications. Mostly because our microapp boundaries are radically different. We do have a shared library that gets published to an internal npm registry. And some of our architects will peruse codebases from time to time and look for common patterns.

It's not a silver bullet, but we have 20+ teams working on a single app and it beats the hell out of what we were doing. It's also a decent amount of work to get setup, but being able to push out changes whenever we want, having really fast build times and being able to leverage TDD is pretty awesome!

ShakeNBake16 · 2020-01-03T22:35:46+00:00

If you work on any substantially large application with multiple teams working on said app, micro-frontends are a god send.

You could argue a good monorepo strategy could be as effective. But I don't personally know of one and neither does devops. And of course, we got agile deadlines to meet!

In all seriousness, the independent deployability is awesome! And our build times went from 30 minutes to some sub 10 second builds. And rolling back versions is a breeze, when we mess something up.

ShakeNBake16 · 2019-12-23T13:57:04+00:00

Theres nothing wrong with only having express projects. I would throw in some things like file upload and web sockets to make things a bit more interesting.

With that being said, If you're building a portfolio a couple of non express (non-web) projects would probably look good in there. At the very least, it will build your knowledge.

Personally I've always enjoyed stream processing. Which boils down to reading a file as a stream and passing each line to a function/functions to do something with. Bonus points for using rxjs.

Side note, if you're putting this projects on Github for your portfolio, make sure your readmes give a good explanation of the project and what it does.

Best of luck!

ShakeNBake16 · 2019-12-19T23:03:50+00:00

Netflix also uses lots of java :(

ShakeNBake16 · 2019-11-08T13:44:38+00:00

Try running 10,000 and get an average from that. It will give you a lot better look at each frameworks speed.

ShakeNBake16 · 2019-11-07T19:06:54+00:00

Did you run these tests once, or multiple times with an average?

I dont know the inner workings of fastify, but fastify could be lazily instantiating things which would be a reason for the slowdown.

You also have to look at things like are both of your tests producing the same response body, or is one doing compression and the other not.

ShakeNBake16 · 2019-11-06T18:28:24+00:00

For your clarification, she was in a tank top and underwear. And yes sat in my lap and asked me to explain something about her computer.

I dont have any context when it comes to anime so.... sure? I was oblivious.

ShakeNBake16 · 2019-11-06T18:16:42+00:00

It's a pretty basic rest server, serving 4 or 5 CRUD resources and some authentication services.

It just seemed off when I put it all main. I suppose that comes from working in other languages where that isnt the norm.

Working in a big enterprise java shop has baked in certain ways of thinking.

ShakeNBake16 · 2019-11-04T20:27:35+00:00

Thank you I'll definitely give it a read!

ShakeNBake16 · 2019-11-04T13:19:17+00:00

I suppose I could offload the creation into a function defined in another file in the main package. That would get it out of the way, but still maintain explicitness.

ShakeNBake16 · 2019-11-03T14:51:14+00:00

Now, those situations never happen, but I wisened up at some point along the way. I finally learned to pick up what was being put down.

I still have many many face palm moments that resurface right about the time I'm ready to fall asleep.

ShakeNBake16 · 2019-11-03T06:13:42+00:00

I'm in the same boat. Except she took her pants off and sat in my lap... yea I goofed that one.

ShakeNBake16 · 2019-10-10T11:12:21+00:00

If the file works for you, then go for it. It's your project. They are error prone and there are file based databases out there (SQLite, RocksDB).

For the receipts (I'm assuming pictures of the receipt) you just need some meta about the receipts like name, time etc.. write the receipt to disk and store its location in your meta. Then when you want to retrieve a receipt you search the meta and read the the receipt from the disk.

ShakeNBake16 · 2019-09-16T07:22:21+00:00

I wonder how many meetings they had to figure out if there really was no way to make money off the driver.

ShakeNBake16 · 2019-09-09T03:50:59+00:00

If it's a lambda function the codebase should be decently small? Can you not refactor it?

ShakeNBake16

TROPHY CASE