145 karma · joined May 3, 2012
I tend to prefer helmet mounted and I glue them on which isn’t my favorite thing to do on a new helmet. It’s also a bit frustrating when you find yourself cycling in a country that drives on the opposite side.
I do find that on very long tours the week following I’m looking where I’d expect the mirror to be when I want to look behind me.
I think they both have their place, but I think acknowledging it as a system design choice is so helpful even in basic business processes (how will I handle exceptions, how will the person remember to handle a rare exception).
I find myself thinking of this problem frequently. We have lots of modern words for it like observability but I think that removes one a bit from the actual problem.
Hey HN! We're a jewelry retailer (~100 mall locations) going through the classic digital transformation story. Our tech stack is built on two endlessly upgraded systems from the 80s (Universe and Magix) that have finally hit EOL. We're modernizing everything - mainly moving to a new ERP (it's a desktop app built in Delphi/Interbase by a third party), plus some in-house stuff. Want to build something? Talk to the users, then build it. Got a better tool in mind? Let's use it. We're running this hybrid on-prem/Azure/AWS setup and trying to get our IaC game going.
What we need:
Someone who's worked with weird tech stacks before and can figure out obscure systems. Experience with retail/accounting is awesome but not required. Must know your way around version control and have strong opinions about your preferred editor for reasons.
Comfortable talking to users and solving their actual problems. Bonus points if you've done multiunit retail before
Some real problems we're tackling:
- Our credit application system is this web app Frankenstein'd together by various devs - it works but the database updates are a mess. Help me fix our autopayments. - Distribution uses this configurable-but-unfriendly desktop app. Need someone to really get how it's used and make it better - maybe through RPA, maybe just better docs and UI labels.
- Work wherever you want. Occasional visits to Culver City helpful but not required - Flexible hours (we're PST, but just need some overlap for now - help me fix our async game?) International = hired through Upwork
If this sounds like your kind of chaos, email me at matt and then a underscore and then pendergraft followed by an at for the main website of the company this is for. Tell me why this interests you and maybe share a cool project you've worked on. Resume optional but helpful.
The pricing is pretty expensive even in bulk. $50 for the larger displays isn’t off by an order of magnitude (e.g. 7 inch with red) especially as a retailer is buying that as a larger solution which includes all the syncing hardware, maintenance programs, and integrations.
For retailers, the savings story is in increased pricing accuracy and reduced labor for price changes. There is the promise of dynamic pricing but that’s a minefield for various reasons.
That’s why you tend to see it in high-value retailers (pricing accuracy, precision, smaller tag count) and grocers (lots of price changes, high labor costs).
You're paying the tax at some point, but if that's at the start of the project it might be high enough to stop it in its tracks. A mature Rails or Django project require abstracting configuration later on in development which is a different sort of tax.
Convention over configuration absolutely has it's perils. I've unfortunately (fortunately?) hit this enough times with Clojure, I know the ecosystem well-enough I'd personally pick composition for a personal project. In a team project where composition makes collaboration difficult (generally a communication and experience problem) I'd probably choose another language with an opinionated framework.
It’s particularly difficult when the system under test includes an application that isn’t designed to be set up ephemerally such as application-level managed services with only ClickOps configuration, proprietary systems where such a request is atypical and prevented by egregious licensing costs, or those that contain a physical component (e.g. a POS with physical peripherals).
A decade ago I worked on a project to deploy a couple hundred of these to a restaurant chain as part of a POC for an online ordering program for pickup orders. The requirement for each franchisee was to acquire a static IP and configure one of these printers to bind that static address using a network card that replaced the serial connection. The online interface from the vendor was configured with that static address and sent text over TCP to print the incoming orders. The printer than just printed whatever it received.
The project was initially deployed without any whitelisting or authentication (at the vendors behest) so for a couple months these printers were printing a mixture of garbage and scan attempts from random devices connecting. It was quite humorous at the time but scares the hell out of me given the other things that were on that internal network. The project failed for other reasons, but it looks like that particular vendor is still around.
Another strain of this is forcing some COTS application to work via a million hacks and integrations (usually via consulting resources) when a fundamental architecture or application change is needed. Responsibility coupled with the resource and authority to execute is stressful in its own way but it at least allows one to more easily own their failures.
I'm so conditioned to providing buffered estimates, especially for highly-dependent systems, I would really struggle to not accidentally buffer. I'm generally invisibly factoring in organizational dependencies (e.g. Bob will need to stand up service X, but Aditya's approval of that will be subject ridiculous process Q that always takes two weeks). It sounds like this would invert the dependency tree if broken down well enough.
Cynically, I struggle to imagine working in such a high-trust environment that wouldn't immediately be destroyed.
• Learn You A Haskell for Great Good
• Land o Lisp
• Clojure Brave and True
I don't find myself with the time to luxuriate in this type of writing much any more and typically gravitate towards more terse material. However, I credit this style towards developing an ineffable sort intuition and making autodidact approaches a bit easier (at least for myself).
(This is not a method I would elect, but dysfunction begets dysfunction.)
As a for instance, I was the operations lead a couple years ago for a large, customer-facing financial product rollout. The timeline was insanely aggressive, approximately 10 months ahead of my prediction and predicated upon several payment and banking vendors nailing their legacy integrations out of the gate with no delay (perhaps a first in the history of the world). Several of these vendors weren't committed nor was a spec agreed upon prior to the timeline. When raising these concerns everyone acknowledged them, but mitigations or deadlines revisions we not made as it would countermand previously set expectations with the executive team.
The project continued on for another 18 months past the deadline with a "launch" set every three months. Inevitably something would derail it a week beforehand that was unexpected but known months in advance by the project team (e.g. the mainframe the payment vendor uses has a fixed column length. It will take two months to build around this to support xyz).
In the end it got rolled out. Everyone forgot about the delays and the project team was praised as the implementation did better than expected. The same technique is employed once again.
While I don't like it, I now see the estimates and re-estimates as a method for an executive team to manage a project portfolio and prioritization. It's not a good way to do it but it's easy to express priority by simply ranking deadlines.
It's much easier to avoid this in high-trust environments (typically smaller organizations).
It wouldn't surprise me if many of these issues are self-selecting in the language communities as well.
This is just a way to achieve that. However, combined with some of the other clojure niceties (namely cider and structural editing) it does make it a better experience for me.
It allows me to maintain a better flow as I can maintain REPL state if needed(especially if it's a quick hack where dependency injection like component isn't worth the overhead). When I'm done exercising the code I can just make minimal changes to make the comment a test, leave it in place, or move it over to a bag-of-tricks user.clj.