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

71–80 of 143 posts

Re: You Can't Buy Integration

#71

Post by gorgoiler »

nyanpasu64 wrote: post #41
gorgoiler wrote: post #21

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

> Java is particularly unforgiving for code where ones thoughts are unclear. Why is Java bad that way? Overly complex classes? In my experience, C++ is particularly awful, since careless programming can lead to memory corruption, use-after-free, and nonlocal malfunctions and crashes.

Java involves lots of ceremony, lots of types, and a formal structure that lent itself to being a very verbose language.

That has never sat well with any kind of source control where you are expressing your ideas with line oriented patches.

Re: You Can't Buy Integration

#72

Post by lokedhs »

codebje wrote: post #68
randomdata wrote: post #39

Earlier quoted context omitted.

Coding is just if statements, more or less. Programming and coding are different words with different meanings, though. What is the reason to conflate them?

Because 'coding' is just slang for 'programming'.

Since this is HN, and pedantic corrections are popular, I feel the need to point out that "coding" is the original term. I've seen very old references where creating instructions for a machine to execute was referring to "coding". We're talking Jacquard Mills or Babbage machines here.

Re: You Can't Buy Integration

#73

Post by dimgl »

keyle wrote: post #7
jefflombardjr wrote: post #3

Really great read. Long but worth it. This is a good critique of low-code/no-code in general. The root problem I see of "Unfortunately, when we frame the problem space that way, we have allowed our tools to think for us." is that in reality there are just not enough qualified software engineers out there.

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…

TL;DR: I think you're seriously misguided.

I think you're missing the point on every subject you touched on and I likely would not hire you either.

For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing to do with HTML, unless you've decided to interpolate values in static HTML pages. The environment variable concept is agnostic of any frontend framework and only requires a build tool of some sort, such as Webpack or Rollup.

On your point about not knowing React... I'm not really sure why you couldn't stick the landing here. If you knew they were a React shop, why not just look into it and build a React app on your own time? It's as simple as doing `npx create-react-app` (or something, I forget the syntax) and building your own React app. If you're such a seasoned frontend developer, surely this would be easy?

On the sad state of affairs: I really think this is another area where you're wrong too. I now know Knockout, Angular.js, Vue, React, and just now looking into Solid.js. I don't know the exact internals of each of these tools, but I can certainly explain to you what a digest cycle is in Angular and what hydration/rehydration means in React SSR. To someone who doesn't know the terminology, this can sound like jargon very easily.

On devops: a couple of years ago I found out about CI/CD, monitoring, and a couple of other concepts, and my workflow completely changed in both professional and personal projects. I now spin up entire infrastructures in AWS in minutes using Terraform. And frontend apps are now incredibly easy. I'm currently working on a Solid.js frontend application on my spare time.

So yeah... maybe you should change your attitude a bit. Based on what you wrote, it sounds like you might be the one that's not on the same wavelength.

Re: You Can't Buy Integration

#74

Post by ViViDboarder »

qxmat wrote: post #28
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've worked with people of varying skill-levels but personally gravitate towards those who can code idiomatically. For me it's important I write idiomatic code and follow the language/framework/api guidelines to the letter so I don't become a maintenance burden to my team. In the fast-paced world of frontend dev, the last thing I want to do is revisit "complete" work, be it a lack of env parametrisation or something…

This is fair, but silly then to interview someone who “doesn’t know React” if you’re not willing to teach the framework. Frameworks and languages are easy to learn, idioms and all. If a candidate is knowledgeable and can write idiomatic Vue or something similar, why would you think they won’t be able to do the same with React?

Re: You Can't Buy Integration

#75

Post by codebje »

lokedhs wrote: post #72
codebje wrote: post #68

Earlier quoted context omitted.

Because 'coding' is just slang for 'programming'.

Since this is HN, and pedantic corrections are popular, I feel the need to point out that "coding" is the original term. I've seen very old references where creating instructions for a machine to execute was referring to "coding". We're talking Jacquard Mills or Babbage machines here.

I do love a good pedantic correction, thank you :-)

Re: You Can't Buy Integration

#77

Post by oh-4-fucks-sake »

VHRanger wrote: post #44
nyanpasu64 wrote: post #41

Earlier quoted context omitted.

> Java is particularly unforgiving for code where ones thoughts are unclear. Why is Java bad that way? Overly complex classes? In my experience, C++ is particularly awful, since careless programming can lead to memory corruption, use-after-free, and nonlocal malfunctions and crashes.

At this point the issues with Java are cultural, but they used to be evolutions of constraints of the rigid "everything must be a class" model. If nothing in the architecture can just be a free-floating procedure, not even a pure function, the system architecture will evolve around this

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 than function params

- Simple validation, if there are no external dependencies

Everything else goes in a service/function.

Re: You Can't Buy Integration

#78

Post by Stranger43 »

dsanchez97 wrote: post #42

I agree with most the tradeoffs that were brought up with "low code" integrations tools, but I feel like none of the tradeoffs of using a general purpose program language were discussed. My viewpoint is that most organizations reach for these solutions because they provide highly available runtimes that people can quickly access. If I am at an organization and not directly on a software development team and want to d…

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 have gotten close for small scale project.

Re: You Can't Buy Integration

#79

Post by meowtimemania »

dimgl wrote: post #73
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…

TL;DR: I think you're seriously misguided. I think you're missing the point on every subject you touched on and I likely would not hire you either. For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing…

I agree with grand parent regarding .env variables. During an interview it shouldn't matter whether a candidate uses a .env file or a shared config javascript object, just as long as the candidate can demonstrate the ability to write maintainable code, and isn't excessively dogmatic about their preferences.

Re: You Can't Buy Integration

#80

Post by edgyquant »

lokedhs wrote: post #72
codebje wrote: post #68

Earlier quoted context omitted.

Because 'coding' is just slang for 'programming'.

Since this is HN, and pedantic corrections are popular, I feel the need to point out that "coding" is the original term. I've seen very old references where creating instructions for a machine to execute was referring to "coding". We're talking Jacquard Mills or Babbage machines here.

I feel that is actual encoding though and programming is a different thing
Post reply on HN