Pretty much the same as my opinion on the topic. The nature of integrations is that you must expect anything. I worked with some of these flow engines and sooner or later you end up writing small integrations that are used by the integration tool. In many cases it would have been easier to just have everything in one integration code base. At least for debugging.
You Can't Buy Integration
101–110 of 143 posts
Re: You Can't Buy Integration
#102Earlier quoted context omitted.
I have been in a similar boat. I was spending a bunch of time avoiding extra API calls and extra renders in React and the team I was working with didn't seem to understand that there were potential performance issues around that. They said "just use memo" On the other hand I think it is a natural progression. 30 years ago experienced engineers would look at young people who didn't know how to fix a PCB or read byteco…
I can’t build a fire in the rain, nor can I skin and prepare an animal. But I can buy a slab of beef and chuck it in a pan. If we’d all be stuck with the very basics, we’d be nowhere. This is why abstraction and specialisation are important.
Thing is, if you needed to make a fire in the rain and skin & prep and animal, you'd have a good chance of at least getting most of the way there as you understand the concepts. The problem here is more equivalent to not even knowing what and animal or fire is, nevermind how to do the tasks at hand.
Re: You Can't Buy Integration
#103Earlier quoted context omitted.
Everyone has a price.
I posit that paying money only buys the appearance of caring, not the actual caring. That is the reason celebrities get (got? Not up to date) doctors who prescribed addictive drugs, because they just gave the client what they wanted, not what they needed. You really want someone who speaks truth to power, not just pleasing nonsense. And the power must be able to discern the two.
This is true prima facie, as a snapshot of "caring".
But prolonged exposition and mutual relationships (even ones kickstarted by selfish, careless objectives such as "Pay me!" or "Go to war for me!") necessarily lead to intertwining of identities. And once you consider something (or someone) a part / extension of yourself, caring follows.
In other words, given enough time and substantial interaction, the lines between "you" and "me" blur. That's just a biological (physical?) observation; cf. parasites and symbionts, nation building, product marketing, leadership…
Of course it's a scale, not a binary care / don't care. A doctor may care very little about a celebrity he knows he'll be interacting with for a year or two, max. But family doctors still exist, too.
Re: You Can't Buy Integration
#104Earlier quoted context omitted.
How do you get time/instances on an no code platform? This problem was solved in 80ies on most timeshare platforms(read unix) where you would simply let users access an general purpose environment on a shared server and run processes in the background or kick up batch job using some kind of scheduler(crontab). The old unix "shell account" should really be the benchmark for FaaS to beat and so far i dont think anyone…
On SaaS providers where Cloud Shell is the new telnet and the browser the X Windows replacement.
Which providers?
My experience is that my first cgi-bin script were about a order of magnitude easier to deploy that anything other then say a traditional php/mysql script. and i had the flexibility to use basically any programming language back then too.
I did not have to learn git, figure out how the cloud router used worked, i just had to place a file in a directory. For crontab it was the same dump the script to a directory edit the crontab file and it worked and it was the same no matter who i bought the service from.
Sure there were scalability issues, and the security was questionable but in terms of ease of use are we really moving forward?
Re: You Can't Buy Integration
#105Earlier quoted context omitted.
The line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard. The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time. And any tool that takes away the control of how you org…
> It’s technically true but it means that you haven’t really grasped what makes programming hard. It’s roughly as useful as pointing out that constructing a skyscraper is really just applying forces to masses.
Reminds me of this:
Re: You Can't Buy Integration
#106Earlier quoted context omitted.
On SaaS providers where Cloud Shell is the new telnet and the browser the X Windows replacement.
Which providers? My experience is that my first cgi-bin script were about a order of magnitude easier to deploy that anything other then say a traditional php/mysql script. and i had the flexibility to use basically any programming language back then too. I did not have to learn git, figure out how the cloud router used worked, i just had to place a file in a directory. For crontab it was the same dump the script to…
Since you gave a cgi-bin script as example, assuming you have an Azure Cloud account, you can easily do it via , provided it is written in JavaScript, PowerShell, TypeScript, or C# Script.
https://docs.microsoft.com/en-us/azure/azure-functions/funct...
Here is video tutorial
https://www.youtube.com/watch?v=1A7vp3zAB9U
Or in the context of low code tools, Azure Logic Apps
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps...
Re: You Can't Buy Integration
#107Earlier quoted context omitted.
I posit that paying money only buys the appearance of caring, not the actual caring. That is the reason celebrities get (got? Not up to date) doctors who prescribed addictive drugs, because they just gave the client what they wanted, not what they needed. You really want someone who speaks truth to power, not just pleasing nonsense. And the power must be able to discern the two.
This is true prima facie, as a snapshot of "caring". But prolonged exposition and mutual relationships (even ones kickstarted by selfish, careless objectives such as "Pay me!" or "Go to war for me!") necessarily lead to intertwining of identities. And once you consider something (or someone) a part / extension of yourself, caring follows. In other words, given enough time and substantial interaction, the lines betwee…
Very good points, I agree with the gist of your post, I just want to say, that, still you're not really buying it, but building it, through repeated interactions.
Re: You Can't Buy Integration
#108Earlier quoted context omitted.
if you are that good, then why are you wasting your time with front ends? Go into databases. You're apparently already starting to age out of the young and dumb and works overtime flotsam.
I work at pretty much all levels of the pie, but my passion is with what the user interacts with, which is why I tend to gravitate towards the front-end. Being "good" has nothing to do with being a back-end programmer, imho. One could even argue that the front-end of today is far more complex than most back-ends!
It is! But you also have to put up with everybody having an opinion on it.
Re: You Can't Buy Integration
#109Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite . If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If howev…
The line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard. The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time. And any tool that takes away the control of how you org…
How unfortunate to be slap bang in the middle of the bell curve
Re: You Can't Buy Integration
#110Earlier quoted context omitted.
if you are that good, then why are you wasting your time with front ends? Go into databases. You're apparently already starting to age out of the young and dumb and works overtime flotsam.
I work at pretty much all levels of the pie, but my passion is with what the user interacts with, which is why I tend to gravitate towards the front-end. Being "good" has nothing to do with being a back-end programmer, imho. One could even argue that the front-end of today is far more complex than most back-ends!
> Being "good" has nothing to do with being a back-end programmer, imho
That's a tough one. As I see it, a lot of the complexity in frontends is in framework feature bloat, subpar tooling and high tech churn as compared to backends. In a word: immaturity. Frontend doesn't guarantee backcompat like backend technologies do, which is also a large part of the (unnecessary) complexity. Obviously, frontends are additionally subject to the whims of fashion in a way that doesn't apply to backends.
In contrast, backends have mature frameworks that can deal with most concerns, allowing the developer to operate on a higher level and with greater confidence in the basic nuts and bolts. Package management is generally sane, to boot.
How much less complex would frontend be if we weren't trying to cram applications into a document model and instead had built-in support for controls/components, theming, data binding and inter-component events? If JavaScript didn't have so many shortcomings or perhaps even gradual typing?
In my experience, frontend skews young whereas backend skews older. That leads to junior class errors in frontends, such as not understanding the benefit of type annotations in a dynamic language and general cowboy behaviour. Perhaps the latter is also down to the general "move fast and break things" approach in JS land.
My own conclusion is backend developers as a group tend to be better, but that's mainly by virtue of having more experience under the belt, being less impatient and taking a longer view.