HN user

vmaurin

110 karma
Posts3
Comments34
View on HN

The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn’t.

No, it was never designed around that. All methodologies of software dev don't focus too much on writing the code, but on everything else: requirement definition, quality, maintenance, speed of integrating feature, scaling the work, ...

Personally with 20 years of experience, I never seen a single company were writing the code was a bottleneck

Agentic coding are bringing new people to coding. But instead of reading some books about coding or looking at the history, they face the same problems as before, they have the same struggle and they re-invent the same solutions.

I am waiting for the vibe coding expert posts that will tell us that lines of code are not a good measure, it is a liability and you should instruct your agent to write less code ...

I am waiting people to commits their prompt/agents setup instead of the code to call this a changing paradigm. So far it is "just" machine generating code and generating code doesn't solve all the software problem (but yeah they get pretty good at generating code)

* you add an HTTP header saying "I am a kid" * porn web servers read and handle this headers * if they don't (easy to test), they get fined

It is easy to implement, easy to monitor, and will probably just work if the government do the effort to monitor and enforce it. If not, it will just be an other DNT header

Same goes for age verification.

There was the DNT header, that was a bit to simplistic, but was never implemented https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

The thing people need to understand here is that the annoyance is not due to lack of technical solutions, or regulations forcing something. It is explicitly wanted by the industry so they can maximize the consent rate. The browser solution is probably the best technical/user friendly one, but ad tech/data gathering industry won't have any consent. As they control most of the web, they will never do that

I left the industry 4y ago, but at the time, it was impossible to track impressions on FB ads. So when FB tells you "We did display 1000 time your ads", you just have to believe them. For the IP of the click, I have seen it from my own eyes in 2013, from Facebook. About analytic tools, I let you check who is the leader in this market, and about their independence in the click market ... If you have a website that pointed by a FB ad campaign, just look at the IP of the incoming clicks.

Not sure if you had a stroke while writing this, but this makes no sense.

Well, that what is happening in practice. It is an attribution game, ad companies try to have the best conversion numbers more than increasing the overall sales of a store.

I have been working in a drive to (physical) store company, we were measuring performances with an expose group + a control group and we were showing 3% visit in store increase during a campaign, while our competitors were claiming things around 10%. We knew that their tracking technology was just about "we shown an ad, they visited the store, it is because of us"

I did work in the ad tech industry for almost 15y and big corp like Google/FB scam their user:

- they don't allow double tracking, so you have to trust their numbers

- if you look at IP from their "clicks", you see often a FB/Google datacenter IP range

- and for most of the traffic they might send you, they did just clever algorithm and heavy profiling to stole your organic traffic. So they get this "amazing" performance by claiming people that would have bought on your site anyway

I have seen and been working in companies trying do to the impact metrics well, but these are outliers

- websites showing ads are annoying their user and get no benefit of it

- stores/brands/people that want to advert pays a bug chunk of money for nothing - only the middle men are getting benefits

The cyclic pattern of IT. New language, same problems, same mistakes, same solutions found (but losing years again)

It will probably never work. Companies have spend probably the last decade(s?) closing everything on Internet: * no more RSS feed * paywall * the need to have an "app" to access a service * killing open protocols

And all of the sudden, everyone will expose their data through simple API calls ?

In the RFC, the browser is named "user-agent". And in OAuth2 flow, the browser is acting as client only on the implicit flow. Also the intent of the authors for the implicit flow is that the "client" is a mobile/desktop applications, and not especially something running in a browser

Yes they are!

I think I know the reason: OAuth2 naming. In the OAuth rfc https://www.rfc-editor.org/rfc/rfc6749 they named one of the role "client", but than meant to represent a server in the more standard flow, while they named the browser "user-agent". Then people understood that "client" is the browser, so they went nuts storing access token and refresh token in the browser local storage, instead of being store in the server session storage, accessible with a session cookie.

So what people should have done https://www.rfc-editor.org/rfc/rfc6749#section-4.1 (you can see here the tokens never reach the user agent, so the server can keep them in a session, then have the user agent identified by a cookie. And what most of the people did https://www.rfc-editor.org/rfc/rfc6749#section-4.2

I worked 12y the ad-tech industry, and 3y in a company using this kind of data to measure performance of "drive to store" campaigns: doing online campaign, then seeing if people visit the actual real store based on geo data. The company was actually controlled by the CNIL (French regulator) according GDPR, so we were "anonymizing" data, meaning hashing one way the IFA (unique phone id for advertiser) and storing location within a 300mx300m square I put some quote around anonymizing because geo data from your phone in the evening/night is enough to know where you live (with 300m precision). The rest of the industry in France and Europe was still a far west though (around 2020)

I have been doing this kind of stuff both in ad tech and trust & safety industry, mainly to handle scalability. Something that looks like "Event-carried state transfer" here https://martinfowler.com/articles/201701-event-driven.html

These system are working fine, but maybe a common ground : * very few services * the main throughput is "fact" events (so something that did happen) * what you get as "Event carried state transfer" is basically the configuration. One service own it, with a classical DB and a UI, but then expose configuration to all the system with this kind of event (and all the consumers consume these read only) * usually you have to deal with eventual consistency a lot in this kind of setup (so it scales well, but there is a tradeoff)

The issue with Spring ecosystem is that people use it without knowing why or which problem it solves but because almost everyone is using it. And most of the time, they don't need Spring (maybe a company like Netflix did, but it didn't prove to be the right choice at the end)

For checked exception, as you mention, "throws *" is throws Exception, then people can refine it on implementation.

As many language feature, checked exception are often misused and/or misunderstood. Too many time I have seen people blindly propagating checked exception above, and you end up having a controller method exposing a SQLException. Then for sure, it is better to use unchecked exceptions overall

While skimming over the repo, I am seeing a couple of warnings that indicate leaking abstraction/boundaries :

* there are imports for Spring in the domain code (is Spring part of your domain?)

* you are using a mock framework in some domain tests

Also I am not sure I understand the "domain" and "ddd" packages. I am a huge supporter of splitting a "domain" package from a "application" package like you did, but then not sure where the ddd stands

TDD is "just" a technique, and being dogmatic about it, is as you say totally pointless. Still I would consider knowing and practicing this technique a "must known" in the industry. When I look back to my 15 years coding :

- the time I lost creating bad designed code and manual testing is huge

- all the companies and projects I have joined always have terrible designed/unmaintainable code, made sometime by 10y+ experienced people and explaining at least how to write proper test and how to design a code that is testable is always the game changer to increase a project velocity and down the defect rate