cjsaylor

Joined 11 years ago

Karma
22
Submissions
32
Member since
May 22
[ my public key: https://keybase.io/cjsaylor; my proof: https://keybase.io/cjsaylor/sigs/DePh_X8lgnTC9jnPOvMdeOkclQAfUgZNWoHTtABAShE ]
View on Hacker News

Recent submissions

Comment · 4 years ago
Comment · 6 years ago
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.

Comment · 6 years ago
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.
Comment · 6 years ago
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.

Comment · 6 years ago
Comment · 6 years ago
Comment · 6 years ago
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.

Comment · 6 years ago
Why is option 3 the best choice? Doesn't that significantly increase the chances of accidents?
Comment · 7 years ago
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.

Comment · 8 years ago
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.
Comment · 8 years ago
I first started down the text path, but not being able to "highlight" previous plays and check turned me towards generating graphics instead.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton