cjsaylor

Zumba | Software Engineer | Full Time | Fully Remote (US - FL, TX, NC, CO, UT, WA, MA)

We're looking for a full-stack engineer experienced with PHP 8 and Javascript/Typescript.

Join us and help us solve difficult problems. You have the opportunity to ship code that will help millions of users connect with instructors and meet their personal fitness goals.

You can make our world happier and healthier.

https://tech.zumba.com

I looked into this subject a bit more deeply in regards to Go, and you are right. Go doesn't have a REPL built in, and most of the implemented REPLs only work off of stdin. So, the Clojure style of REPL development is not as straight-forward in Go. However, it does seem like one of the userland REPLs could be adapted to work with an editor (like vscode) if the input source wasn't locked to stdin.

It seems like a ripe target for an opensource library to accomplish this. I may explore this later on when I have more time to devote.

Indeed, I'm going to think about some of the suggestions you mentioned the next time I'm in there playing with it. Perhaps I'll hit a wall with delve that other language tools (like Clojure) handle better.

Correct, but it does allow you to modify values in memory, so you could do the branching and state changes as you go. I admit I could have made that flow more "editable" from the debugger/REPL, however it did serve its purpose in terms of prototyping ideas before I integrated them into the real thing. I also do use it to debug weird state things of issues reported to me, which I do mess with the values at runtime with Delve to simulate.

I may be misunderstanding the "true" REPL development here, but I think the points laid out by the article seems to match my experience to a degree.

I don't mind the criticism at all. I don't use it often enough to claim expertise. Fair points about my usage.

You can still get proper editor support with Golang (even though it isn't designed for it). I've done so here with VSCode working with a "remote" delve session: https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...

I rarely use REPL driven development, however in my limited experience using it, it only makes integration testing faster, not unit testing.

I used this methodology with a Slack bot, because doing integration testing with Slack is annoying when I'm not directly testing the Slack communication portion.

For example: https://github.com/cjsaylor/chessbot/blob/master/cmd/repl/ma...

Edit: It seems like there are a lot of comments surrounding him "abandoning" TDD. Not only did he not do that, he literally says in the conclusion of the article that he would not recommend doing it.

I suspect most organizations are guilty of these items and much more, they just haven't been thrust into the lime-light so suddenly like Zoom.

Having posts like this to learn from mistakes are great, but it also seems like these are mistakes that are repeated over and over. I don't know what the answer is, but it seems software will always be considered a joke to other engineering disciplines until we can actually get disciplined.

Why is option 3 the best choice? Doesn't that significantly increase the chances of accidents?

Depending on the store, it's not as simple as the systems not talking to each other. It's more likely that the system for the store front is either out of sync or incorrect. The systems that multi-tenant warehouses use were made for a time before e-commerce and has had more modern updates shoe-stringed on.

Even if the software is well implemented, there's still issues of items being damaged during the pick/pack step, items being labeled incorrectly, put into the wrong bin, misplaced, or even stolen. These are things that smaller shared-warehouse store fronts don't have the capacity (in space or money) to cope with it.

I think I tried the same thing, but shipping with the font included presented some licensing concerns. Also, I had a hard time getting it to line up exactly how I wanted, so ultimately I went on to assets.

I first started down the text path, but not being able to "highlight" previous plays and check turned me towards generating graphics instead.

I've also created a slack bot for fun to allow slack teammates to play chess within slack: https://github.com/cjsaylor/chessbot. The bot I built is a more traditional server setup, however I did briefly consider using a serverless setup for it.

The serverless pipeline seems a lot more complex than the actual application to send the message to a slack channel. I wonder if things like Github's actions would replace the need to have a serverless thing for notifications of this kind (at least within the confines of Github's ecosystem).

I created a similar open source tool for this for work a few years ago called drill-sergeant: https://github.com/zumba/drill-sergeant

However, it leaves the scheduling mechanism up to you. We currently have it on a crontab on one of our build boxes that notifies hipchat hourly and a separate cron that sends an email digest once a day.

I also created a hubot integration as well, but it is out of date since we use the direct hipchat integration: https://github.com/cjsaylor/hubot-drill-sergeant

We use git flow at work, which means we rely on PRs to be reviewed and merged in order to make it into staging/production. This tool was made to give us a report of stale PRs to know what to review first (and how behind we are on reviews).

It's also really nice for open source repos that you don't look at every day.

Not that I disagree, but the downside is that you would have the browser fragmentation that alot of people use electron to avoid.

Fair points. I guess it wasn't super clear from the pricing example. I think, as you say, expressing the price per CPU time rather than wall clock time is what would better sell me on it.

I could actually see a pretty good use case for academic computing (think SETI at home, or the genome project) to where they could get cheaper access to CPU.

Todoist is a centralized todo list application. What my app does is hooks into their API, pulls out the completed items and sends an email digest to the address of your choice based on the frequency that you choose.

The premise is, if you already use todoist (or wish to start using it), then you get generate automated reports to stakeholders of the tasks you completed during the day, week, or month. There are other services that do this (IE idonthis), however it requires that you manually enter in the things you did.

It's hard to demo something that involves email, but I plan to add some screenshots to the landing page to make it more clear, I just haven't had time to do it.

In the meantime, here is a screenshot of the app and a sample email that would be delivered: http://imgur.com/a/X1I5v

This is a cool idea. The price as listed is "cheap", but for the feature set, it's not really that cheap. It's half the cost of a digitalocean droplet with no security and possible surge pricing.

I think it's a fantastic idea and the implementation here seems easy to use, but needs to be significantly cheaper.

Docker ID: cjsaylor

Would love to try it out.

Any plans to include integration with the new AWS container registry? Seems like it could offload some of the orchestration for deploying a new docker image, no?

It's not about lowest common denominator. It's about what devices users are actually using to browse your site. If you make an awesome desktop version of the site at the expense of mobile, but majority are visiting on a small device, then you are alienating the majority. You have to keep perspective of why your are building something; if it is not for the users, then it is pointless.

Absolutely.

On top of that, it also makes it easy for front end interfaces to be designed with a mock microservice (or handler) that simply emits it for their testing with a backend developer going through and filling it. As long as the API isn't overly complex for emitting events, almost anyone on the team can do this.

I'm currently working on a side project that has this sort of microservice layout with RabbitMQ and have found similar findings as the article.

One thing that has been a big win (which isn't mentioned in the article) is the concept of "duplication of data". Our microservices are currently listening to everything and only taking action on things they care about. As such, they are also storing data about things they care about. This makes it so that no single datastore is a bottle neck in a distributed architecture. This doesn't mean we don't have a centralize DB, but in the heat of operation it doesn't rely on a centralized DB. Using event sourcing makes it very easy to take this distributed data and store it in a consumable way for reporting, etc.

Another thing being it's a much different metric you have to worry about than traditional apps. Instead of worrying about load on a server, your main concern is messages processed per time frame. This can vary depending on what the service is doing, but in general you can simply monitor RabbitMQ's queue processing rate to determine if you need to scale a particular service or not.

It's a bit hard to debug some concurrency problems, but is normally solved by asking: "Who's responsibility is this?" and then adjusting who emits what.

They mention planning out events; we go a bit further and use json schema to describe exactly what is expected in that event. We actually have a dedicated development microservice that simply listens to all events and validates them against the json schema and records/notifies what events (and the source) is not being compliant.

In the beginning of development, our throughput was dreadful, but now that we have all the tools in place, adding a new service or handler of an event in a service is incredibly fast.