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.
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.
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.
What languages have you tried REPL driven development with? As far as I know, Golang doesn't have a REPL that is connected with your editor so you can evaluate inline code and Golang is not made for REPL driven development either, so you have bunch of implicit state and you can't overwrite function definitions at runtime either.
I think you need to have a language (or structure your particular program in a way) that is really made with live-coding in mind for it to actually give you any benefits, like Smalltalk or Clojure and similar. Otherwise it's just adding another step to reach the real program you're running.
Edit: using your example as an example here, hope you don't mind. A program made with REPL driven development would have way less code in the main function, in order for you to test the code outside with your REPL. The `StoreGame` function would accept a data-store + the argument you have now, so at development-time, you can pass it arbitrary stores. And similar changes.
You probably wouldn't be able to, without restructuring how you're handling your state that is being used there. A REPL driven made program usually is made that the runtime carries the state and exposes it, so you could just select that part and run it, and see the output of it.
I'm guessing delve is more like a traditional debugger that steps through each line, rather than an REPL, correct?
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.
That's interesting, didn't know that! Thanks for sharing. I don't think there is anything that is more "true" than something else, it's just varying degree of personal productivity and in the end we all work very differently, so one size does not fit all. I'm glad you're sharing your thoughts with me and seems to be similar to the REPL environment I'm running myself.
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.
I kind of practice REPL driven development in Go actually. I usually write 1-2 functions at a time, and simply test them by repeatedly running the program, with tests happening in an init() function.
When everything's well again, I move the bits to a test case.
I guess my point would be that with a REPL driven development in Clojure, there is no moving, as the code is already where it should be, you just executed it from there directly.
And you don't need to extract anything into functions, lisp-syntax kind of already gives you all the separation you need, so you can just execute code in place if you need it to.
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.
Option 3 is better than option 2 because it is more likely that a country with WMD will use them against a country without them (for fear of retaliation). Option 3 is an equal standoff.
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'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).
That's funny, I built the same thing for our Slack (I wish I'd known about notnil/chess; I tediously wrote out the rules for chess). I managed to do without assets, though, except for a typeface that had chess piece glyphs. :)
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.
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.
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.
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
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