OData provides GraphQL functionality but using GET + URL parameters, for large queries it's really hard to read or edit. Using the request body makes sense for readability, so OData also offers the option to query with POST + request body.
> Ultimately to maximize engagement you want to get people obsessed with something. Whether it’s sometimes violent racism, vaccine paranoia, national politics, whatever, you just need to get them obsessed, and then they will spend hours every day on your site feeding this beast and go insane. Then you will sell lots of ads and get rich.
Yes. This is exactly what Elon is doing with X at the moment.
I've worked at a large company that ran internally developed logistics software. It worked for them.
> Strategies for attracting and retaining tech talent in a non-tech industry
While you might be in a sector that isn't tech, you have tech. Put yourself in a software engineer's shoes, from a career perspective. We tried to keep up to speed with respect to things like framework/platform version, development practices, etc.
Make it clear and obvious that you will continue to invest in technology. We went to mobile early because it made sense for our business. We continued to invest as mobile changed with the introduction of iOS, and as computer vision got better.
Feel free to reach out if you want to discuss further.
We worked with a payment processor to implement billing for our services via credit card. According to the payment processor, the QA environment for one of the major credit cards had been broken for a while, so we tested in production.
We were testing billing customers who were going to pay us, so putting a small charge on a corporate card that was going to come back to us wasn't a big deal, I just remember being slightly surprised that testing something like credit card payments was done against the production environment.
The challenge with visual programming from my perspective is how to get the abstraction level just right. It's like Terraform/HCL modules: too granular, you wind up passing in a billion parameters, and the module adds little value. Too high-level, too many assumptions, also adds little value.
I have an idea that I think would be suitable for visual programming. Every time I think about it, I come to the conclusion that first you need a DSL, or at least a JSON Schema or something.
If you have a DSL/schema, then you also have a way to diff.
Then, you implement your visual programming environment, and visual diffs turn into effectively communicating those differences visually. Faded color to indicate a deleted node and connector, bold parameter and value to indicate a change, etc.
I think this idea has promise but I wonder how it would work when many of the visualizations I create to help explain logic wouldn't fit neatly into a DSL/schema. For example, I might use red in some places to refer to data from a particular client, or underlines to indicate constants, or arrows to indicate things that are related from a business perspective but not data or logic flow. I guess this could be standardized, but that almost defeats the purpose of having the computer do the heavy lifting.
In other words, not only does understanding these diagrams assume a ton of knowledge in the problem domain, but the crude tools at hand for creating them (lines, words, symbols, shapes, colors) can be repurposed in so many ways by different people and different projects that I don't see how generic motion detection will be able to detect high level changes. Sure, detecting changed nodes and descriptions might be easy, and possibly useful, but I think there will never be a substitute for human comments like "removed XYZ because the boss said so" or "renamed foo to bar because of IRS regulation so-and-so."
Having spent an unhealthy amount of time thinking about this, I think it's even worse than an abstraction _level_.
I suspect that the fundamental problem with visual languages is that you have to reify _something_ as the objects/symbols of the language. The most widely used text languages tend to be multi-paradigm languages which have significant flexibility in developing and integrating new abstractions over the lifetime of projects and library ecosystems.
It's not clear to me how this can be overcome in visual languages without losing the advantages, and instead ending up with a text language that is just more spread out.
I think the solution is just to stop trying to allow Real Programming in visual languages.
Make the abstractions purely high level, and let people write Python plugins for new blocks with an app store to share them.
Visual can easily provide enough flexibility for gluing blocks together.
IFTT, Excel, and lots of others do it perfectly well.
The issue is programmers like to program. Mostly they like "programming in circles", making little apps to help make more other little apps to explore ideas.
They see it mathematically, as a human centered activity all about understanding, while users see machines as a box you put stuff in to make it not your problem anymore.
They're always talking about empowering users to create their own fully custom ways of using computers... But.... I like apps that have a canned, consistent workflow that I don't have to fuss with or maintain or reinstall.
Software like Excel has the appropriate amount of power for working on a project that uses computers but isn't really related to programming or done by developers.
>The challenge with visual programming from my perspective is how to get the abstraction level just right.
It is a big problem if you are trying to develop a genric visual programming language. But much less of a problem if you restrict the problem domain to something like data processing, signal processing or image processing.
I've seen home depot workers lament on their subreddit how so many people buy a tool just to return it and steal the battery. Shrink must be absurd at these stores. They at least try and do something about it; I've seen people walked out in cuffs at the home depot when I've gone a few times now.
Even acting in good faith, the nature of their shopping experience (goods are undifferentiated, often unpackaged, often either very large or very small and self-checkout predominates) makes it easy to make mistakes. I'll willingly admit that I've gotten to my car and realized I didn't scan (or under-counted) an item at least once (and I'm rather compulsive about checking my work).
You want to save money by making customers do the checkout labor for you, you're going to lose some money on goods.
If I need to interact with a company for some reason, I will usually try the website first because it can be faster. If I can't do it using the website, I call the phone number. The automated phone system usually tries to send me to the website, so I yell "AGENT" into the phone until I talk to a person.
reply