Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Can't Buy Integration

martinfowler.com

Post reply on HN
Print view View original

131–140 of 143 posts

Re: You Can't Buy Integration

#131

Post by pjmlp »

gkop wrote: post #126
pjmlp wrote: post #121

Earlier quoted context omitted.

You are missing having IT set up a UNIX server instance, with Apache or NGINX on it, configure firewall, public IP DNS entry, and then having the rights to ftp/scp into it before being able to call vi into hello.sh. So if you want that approach then, IT would set an "static HTML web app" instance for "~/public_html" version, which you can then ssh into. https://docs.microsoft.com/en-us/azure/app-service/configure...…

I feel like you must know this, but the convention back in the day was a UNIX server for an organization, that would handle essential tasks like email, that everyone could log in to and have access to common UNIX tools, and that would automatically serve "/home/$USER/public_html" as static HTML web apps under example.com/~$USER. So, IT sets the server up once and maintains it and provisions and deprovisions accounts,…

Sure and I get from where you are coming, but those days are long gone, in fact by 2004 that wasn't a thing at Nokia any longer.

Re: You Can't Buy Integration

#132

Post by fragmede »

gitfan86 wrote: post #25
keyle wrote: post #7

Earlier quoted context omitted.

I got bounced off a front-end job once, for not being good enough at React. Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue. But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic". Mean…

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…

> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

> -Donald Knuth, 1974

Re: You Can't Buy Integration

#133

Post by oh-4-fucks-sake »

VHRanger wrote: post #122
oh-4-fucks-sake wrote: post #77

Earlier quoted context omitted.

Kotlin has been a godsend when it comes to breaking free of Java dogmatic thinking. The effort to write good functional code is so much less. That's not to say that classes are useless. I try to limit class usage to data structures that do no more than: - Store data - Simple convenience functions that tell me about its state - Side-effect-free mutations (or data massaging) that have no external dependencies other tha…

Classes manage something stateful. One anti-pattern/code smell I often see is finding classes in a service which should just be a functionally pure pipeline (eg. no internal state is managed)

Agreed. Exception here is when you're making the trade-offs to buy into a DI framework--which you could argue is a descendent need from the "everything is a class" worldview. Pure/dependency-free util functions can very naturally live outside of all of this. But, the minute you have functions that depend on inherently stateful infrastructure (e.g. datasource connections--so, most applications), then those functions become inherently stateful--which makes them less natural to exist as pure utils and starts to make DI more attractive--which leads us back to placing pipeline code within classes. Alternatively, you could expose only the stateful pipeline code within singletons, but at some point you start to fight the community patterns--which means you start to lose out on community goodies. To be clear, this is all only based my experiences and I'm not dogmatic at all about any of this. Times change/everything-old-is-new-again. I'm sure classes will make a comeback, and then go out of favor again--as is life.

Re: You Can't Buy Integration

#134

Post by gitfan86 »

fragmede wrote: post #132
gitfan86 wrote: post #25

Earlier 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…

> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. > -Donald Knuth, 1974

Just don't forget about that 3% https://www.datacenterdynamics.com/en/news/report-aws-uncert...

Re: You Can't Buy Integration

#135

Post by csours »

skydhash wrote: post #94
zmmmmm wrote: post #70

Earlier quoted context omitted.

> This is easy: when you give people a huge amount of money to care about your problem, they will You can pay them enough to care as far as they get their last payment. How do you get them to care what happens after that?

Shared ownership of the business?

Yup, somehow you need to get people to own your problems for you or at least attention on your problems. You can rent it by paying people (wages). You can sell it by making it seem important to them (Tesla has no marketing department or budget for instance).

Or you can share it by having partners or shareholders.

Re: You Can't Buy Integration

#136

Post by NikolaNovak »

kayodelycaon wrote: post #47
NikolaNovak wrote: post #31

Earlier quoted context omitted.

All ERPs are fundamentally like that. At the end of the day you are purchasing a COTS product specifically to gain efficiency of industry best practices already coded for you. If you take a COTS product and then try to rewrite it to fit your "unique" business processes, we'll, that's why half of them fail. Implementation of erp is incorrectly and disastrously viewed as an IT project. It is first and foremost a busine…

This is why my company has custom applications that talk to the ERP for certain departments. Inventory control in the ERP isn’t going to work with reality. The data modeling is good enough but the interface is not. Rather than train everyone we hire to use horrifically bad and expensive barcode readers, we purchased cheap smart phones, put them in cases, and locked them down to run an app that uses the camera to scan…

Yup there's a few approaches. These days most ERPs have nice semi-modern interfaces making mix-and-match easier, but honestly over 20 years I've seen industry go through 3-4 long cycles between preferences for single-vendor/stack homogenous solution, or "best of breed" mix (I know, buzzwords all but sometimes handy:). It seems one of those things that goes and comes around....

Re: You Can't Buy Integration

#137

Post by Stranger43 »

pjmlp wrote: post #131
gkop wrote: post #126

Earlier quoted context omitted.

I feel like you must know this, but the convention back in the day was a UNIX server for an organization, that would handle essential tasks like email, that everyone could log in to and have access to common UNIX tools, and that would automatically serve "/home/$USER/public_html" as static HTML web apps under example.com/~$USER. So, IT sets the server up once and maintains it and provisions and deprovisions accounts,…

Sure and I get from where you are coming, but those days are long gone, in fact by 2004 that wasn't a thing at Nokia any longer.

But is the new way better for all usecases?

Re: You Can't Buy Integration

#138

Post by trabant00 »

DocTomoe wrote: post #83
trabant00 wrote: post #81

There's a lot of things you can't buy in IT. There's a lot of things you don't need to either because they are free. For all this you must find people who are passionate and have interests aligned to your own. This is how I aim to hold the interviews I conduct for infrastructure engineers. The most important question I ask is "Why do you want to work in this position?". 10 years ago I used to care mostly about candid…

That particular question is a major red flag to me as an interviewee, maybe because most people who ask it are not interested in an honest answer (the most honest being: "you offer money for work, I offer work for money"), but have been told by some HR voodoo master that this almost-ritual incantation reveals deep psychological insights into the interviewee's mind. At best, it only tells you if they prepared by memor…

That particular question springs from my own motivation at fulfilling that role. I do not know why you think I copied it from some faux book. And "you offer money for work, I offer work for money" is not a valid response in some cases, some positions require high internal motivation. This is all from my experience of hiring people to work under me, I don't care about the company or HR or anything like that. I care if I will have to push them constantly to deliver or if they desire this for themselves.

Re: You Can't Buy Integration

#140

Post by Stranger43 »

pjmlp wrote: post #139
Stranger43 wrote: post #137

Earlier quoted context omitted.

But is the new way better for all usecases?

From security point of view, yes.

yes but if that's the only way it's approved there is a huge unfilled gap in the current market.

Besides given the near constant issues we see around misconfigured s3 bucket i am not sure the average cloud function meets security standard anyway.

Post reply on HN