thomas_h · HackerTrans

I see a problem with the current implementation: Releases are auto-generated from git tags. That means all tags you'll ever use on your repo will be auto-exposed as "release", even if the tag reads "dead_end_implementing_foo" or "before_major_rewrite". Tags are an implementors' tool, releases belong to product management. I want to be able to control my releases, so at least be able to delete auto-generated ones (without losing the git tag).

thomas_h

13 anni fadiscuss

I think you have to make a few distinctions that recognize both different developer backgrounds and developer aspirations. It's like one of those "magic quadrants" that analysts love:

On the horizontal axis you'd have developer background: HTML/CSS/JS - OO Programmer On the vertical axis you'd have target application: Web Page - GUI-like App

Web pages are about text, color, images, layouts and maybe animations - in short "appearance". Page breaks are ok. GUI apps are about controls/forms, lists, tables, trees, to interact with a backend - in short, they're about "functionality". Page breaks in a GUI app are disruptive and are therefore avoided.

HTML guys hate latency, they're used to the most direct effects. OO guys usually don't mind to invest time before coming up with effects. HTML guys often shy away from learning a new programming language; it's important that they can apply the same skill set over and over again. OO guys don't mind to learn a new language, but don't like to miss out on paradigms and patterns they value.

Cappuccion would be in the upper right quadrant (OO Programmer / GUI App), while e.g. jQuery would be in the lower left ( HTML/CSS/JS background / Web Page). Probably, the crowd behind the HTML/CSS/JS profile is larger than the OO programmer crowd. And the amount of effort spent on web pages with spiced-up appearance is larger than that of carefully crafted rich internet clients.

But probably both have their relevance, so why trash one in favor of the other?! For someone advertising on the web a slick appearance is prime, while a vendor of set top-boxes values reliability of their web-based configuration GUI. The real problem arises, and that is probably Randy's pain, when the wrong technology and skill set is applied to a given problem.

comments