mcnichol

I don't think we have any evidence that anything will be done fairly. In fact the idea of Capitalism in a "fair system" has been objectively broken as incumbents apply pressure on free markets to suppress competition.

I think all forms have proved they can be broken where they no longer are "playing by the rules".

I was entertaining the hypothetical. I think the biggest unknown I feel which the article gently touches on is the unknown of how deeply this is trusted to make decisions that could be life-changing.

Imagine the danger of an AI model built to scan and understand a state or national level of policy that would be beneficial to society. Not only does that create a vector of manipulation to government that could be blindly trusted but it opens a cyber attack vector from other nation states.

I could see someone coming from a place of good without realizing that these functions are somewhat opaque without ceilings/floors which can increase deviation to elicit hallucinations.

Whether it is intentionally misused or a road to hell paved with good intentions it does feel treacherous. I do think there are many many democratizing aspects it offers but how do we stop mixing the baby and the bath water when we can't tell the difference.

While I think there could be an argument made here you are mixing apples and rocks if you believe ChatGPT is using gans.

I hate to be that person but you are showing that you are unable to differentiate between linear regressions, clustering, gradient descent, and generative adversarial networks. You are over your ski-tips and don't see itc

I think as you stated, human nature and history is where I am looking at this from. People have a tendency to be unable to sit and do nothing for extended periods of time. I believe we are purpose driven but purpose is pretty loosely defined here.

Indulging the hypothetical (and arguably realistic in some circumstances) that AI replaces a tier of repeatable tasks I believe it would work from the bottom up. Tasks that are extremely repeatable would probably be gone 1:1 and it would be a sliding ratio as complexity increased where having human intervention as a backup becomes justifiable.

This would create a squeeze on the labor force which would bring up the very real and fair question of "How is it that I am unable to survive daily life when 100 - 200 years ago none of this automation / technology existed."

I think this could drive a sort of re-examining of what exists RE: a very inefficient and flawed system with a large amount of people possessing a lot of anxiety and time on their hands. It would be like the Eye of Sauron made up of those who were caught in the crossfire.

On the other side of the haves and have-nots I can imagine there being a very Harrison Bergeron style mindset of trying to popularize pacification until the next great innovation just solves itself.

On the extreme end, I just cannot imagine euthanasia, genocide, or population control schemes. It feels like we have come so far. How could it be possible we regress that far? I could imagine myself not wanting to live through any part of that. This seems like a very extreme and existential point to reach. I am trying to keep my thoughts pinned closer to biological and historical drivers.

I think we are hormone driven chemistry sets. I believe we respond to stimuli. I find it hard to believe anyone at any level could shut off that drive at such a massive scale and accurately predict the other side.

It goes back to the industrial revolution and every revolution before and after. There was a point where they thought a majority of people would be working as switchboard operators and then telephone switching came along. Horses to cars, etc.

Jobs transition, new space is created, people are caught in tbe crossfire of supply and demand curves. Incan agree the bullwhip of this one is going to be aggressive.

I think it is a mistake to bet on AI as a driver of meaningful growth in a commercial capacity in the current state. When the data fed into an AI model is based on real data you can get predictability. When the AI inputs start coming from the AI outputs the wobble is introduced which results inevitably into delirium.

I think the world at large is "learning on the job" what data scientists and others in ai have known for a long, several decades long, time have already known.

Look at how RSA is implemented. Look at the intentional obscurity of S tables and lack of detailed information.

There is a reason information is withheld. DB schema is just that, information that increases increases the threat.

And running a DB on someone's infrastructure doesn't necessarily give you access. You need to read up on AuthN and AuthZ.

If you listed an open source example I'd take the time to poke holes in your strawman argument but you honestly just need to take a step back and think about what you are really arguing.

Do you really think not having the schema is as inconsequential as having the schema when attacking something? I mean what is the first step most folks do in reverse engineering? I honestly can't believe I'm having to say this.

Schema is very much a critical field in terms of AuthZ privileges. Just knowing the structure is not far off from knowing the max entropy a password may hold. In regards to InfoSec, table structure is the recon phase which limits effort and minimizes time. Someone with that much time in security knows DBs will be hacked, not if but when. Time is an incredibly important tool which is why we have expirations on so many authN and authZ windows of attack.

I'm glad that you are challenging them but I believe a credible engineer would have made mince meat of your expert and hurt the rest of us who want to see you successful.

It's possible rewriting certain statutes can help us but there is no company worth its salt that would share DB schema.

I get what they are saying: There is a difference between theoretical and applied.

I think the OWASP/NIST/InfoSec has always been a bit behind because of this mentality. I think there is a progressive forward looking mindset that is often seen as "mad" or "unhinged" when it's ultimately throwing paint at a wall to see what sticks.

The driver is curiosity but then someone comes along and applies CBA and ROI, and CAC...the person who was curious has left because that wasn't the goal. Eventually something will stick that meets all of those mainstream ideas.

If you think of the body as a computer, it communicates through DNA, a much larger scale of information passing. Binary is just arbitrarily selected because it was there. Should we stop exploring binary computational systems? No but we also don't need all our eggs in one basket.

But when you look under the hood it's tooling that wraps tooling. The API categorization tool arguably hands off a large portion of the heavy lifting to OpenAI.

"You are a world class categorizer. Fit these APIs into one of these groups."

The rest of the file is just wiring and a little blurring of the lines of model, view, and controller. I saw some testing and was like, okay this is going to be important if you are wrapping a lot of tooling because "change outside of your control" but then it's just a the default contextLoads() functional test Intellij gives that makes sure dependencies exist and nothing fails at compile.

I think the vision is there and it is definitely aligned to the Pareto principle but it feels like the idea was tested that markets aren't interested in maintaining their stuff while internally they haven't even addressed maintaining their own stuff.

Feels like a Catch 22 where if they could address that reason for themselves first then they could probably solve that for other people. But addressing it means having a product that is being used in order to feel the pain and empathize with the end user.

I saw some charts that expressed 1hz in the A4 range a bit higher but essentially what you explained. The lower in the scale the more cents per hz but each "scale" has 1200 cents broken up evenly per semitone.

We could create a reference chart that shows the "increase" in the scale in hz which would be a logarithmic curve while the cents would be growing linearly based on an underlying logarithmic scale.

In my previous response I was being prickly with the previous responder because they came off with strong "well awkshually..." energy.

I get what they are saying but I don't think it's outlandish to speak in hz when the extra precision from cents is arguably beyond the average musically trained ear.

Am I saying I don't understand or am I saying I understand but the response is too nitpicky for me and what I feel is reasonably acceptable by the average person.

Don't be pretentious man, we are tuning guitars and violins not prepping the kids for Juliard.

The same as how you use hz to talk about a specific note, your ear understands hz when listening. Cents are just ratios of intervals subject to a given scale. Do you think we are so bad we are messing up A3 as being close to B5?

How about we use Just Intonation or 12-TET? But then should we base it on 5 limit[0] or Pythagorean[1] tuning.

See where being a pedant gets you.

[0] - https://en.m.wikipedia.org/wiki/Five-limit_tuning

[1] - https://en.m.wikipedia.org/wiki/Pythagorean_tuning

Most tuners work in hz. Your ear works in hz. That's all the thought that went into it.

If any of us are consistently getting to within a hertz I'll consider switching to cents.

I've never ran into such brigading on HN before. I really thought I said something non-confrontational at first.

Wait till they get hit with their first domain renewal sniping attack. Then it's spiderman-pointy-finger meme all day when explaining who hurt who.

If the customer left it behind they could send it to the wayside.

If they are merely a broker then I agree, I don't see them as rent-seeking. The article left me with the impression that they had a large number of domains they rent out to customers.

I think "My journey of learning perfect pitch over 15 years" is more apt

Learn perfect pitch in 15 years sounds more like a step by step article.

I would have clicked both, just expect something closer to the latter.

They buy 900 domains. They hold 900 domains.

Anyone who wants that domain cannot use it but must rent through them (whom they rent through someone else)

This is textbook rent seeking behavior.

You own the domain. You can take it and they can't withhold it.

The registrar is already doing what this site is doing. I don't have a problem with a site making it easy to setup. It's the site holding a thousand website domains.

What you are asking for is different.

If FolioHD said:

Have a domain in mind that you'd like to use? Type it here and we'll do all the work setting that up.

What they are actually doing is:

We've bought these 900~ domains and we are holding them. Pick one you'd like and we'll set it up.

A simple test:

Would all of FolioHD's domains being rented benefit their business or not?

They are subsidizing the cost of buying those 900 domains into their overall pricing as a line item.

Now the registrar is trying to push out squatters. Sounds like the housing and renting markets. Insert surprise Pikachu face.

Your domain and how people reach you is probably the first lever. If you are giving that up happily, I assume renting without the option to own or leasing a car is a sensible business model to you and you are just experimenting without any real intention of starting.

The effort and time in becoming an artist outweighs by at least two or three orders of magnitude the time it would take to read an article and setup a domain. Namecheap, GoDaddy, all these registrar's do it for you.

Imagine having 900 houses and renting them out to a community of like minded folks. Whether it is at cost or slightly above, it is "rent seeking" in the sense they own, you borrow.

While it isn't rented, they are squatting on it.

Whether it is at cost or slightly above, it is "rent seeking" in the sense they own, you borrow.

While it isn't rented, they are squatting on it.

Maybe I took the title too literally.

As someone who wants to gain perfect pitch (and still feels mildly distant from this ability) one thing I can say has been the most helpful:

* Get a string instrument

* Strum the strings

* Try to tune the first string by ear

* Once you think you have it, check it against a chromatic tuner.

This way will you see how progressively your feeling of "in tune" can be measured in hertz.

I can get pretty pretty close (within about 5hz).

I used to have competitions with my children on who could get the note closest without a tuner. One of my kids got pretty good where they could almost nail it within 1 hz. It made things fun and a little less "maintenance".

The best way I can describe the process is you have a sensitivity to a threshold of being in tune. I hear the note but there is something inside myself, it almost feels like anxiousness that kinda peaks right before I hit the note and then stops when I "feel" I've hit that note I'm aiming for. As I've said, I can get within about 5hz which to a musician they can probably notice it is off but for the average ear, it feels muddy but close.

Long story short, practice with a tuner and within a year you'll surprise yourself.

Tradeoffs for mono are drivers of micro and vice versa.

Looking at the GitHub insights it becomes pretty clear there are about two key devs that commit or merge in PRs to main. I'm guessing this is also whom the code reviews happen etc. Comparing itself to Linux where the number of recurring contributors are more by orders of magnitude just reeks of inexperience. I'm being tough with my words because at face value, the monorepo argument works but it ends in code-spaghetti and heartache when things like developer succession, corporate strategy, market conditions throw wrenches in the gears.

Not for nothing I think a monorepo is perfectly fine when you can hold the dependency graph (that you have influence over) in your head.

Maybe there's a bit of /rant in this because I'm tired of hearing the same problem with solutions that are spun as novel ideas when it's really just: "Pre-optimization is the root of all evil."

You don't need to justify using a monorepo if you are small or close to single threaded in sending stuff into main. It's like a dev telling me: "I didn't add any tests to this and let me explain why..."

The explanation is the admission in my mind but maybe I'm reading into it too much.

Article is nicely written and an enjoyable read but the arguments don't have enough strength to justify. You are using a monorepo, that's okay. Until it's not, that's okay too.

There is a point where software diving down meets the hardware coming up. When you import a library you start creating harder to separate internals and testing becomes more of a blackbox approach (I don't care what happens inside as long as my results are consistent) as opposed to unit and function. It eventually does reach a point where dependencies are harder wired but the deeper you can create this DI, the more dynamic things become (function arguments, library injection, os virtualization, even hardware at points [PCI-E, serial]).

I think you are right about DI being less common but that is because it's not a natural reaction until you reach the maintenance side of software. It's much easier (and more performant) to just load it up on startup and call it directly. When you get into the way languages work you will see DI is integral to their accessibility and maintenance.

It was put up or shut up. If you said you could do it you can almost guarantee someone would ask you to show them and explain.

A lot of "knowing something is not the same as knowing the name of something"

Testing Specifically: https://exercism.org/docs/tracks/python/tests

I really enjoyed working with my engineers on this site. A lot has changed since I used it last but the idea being it gives you small bite size challenges to test and exercise testing muscles.

Below turned into a bit of an impassioned rant/soapbox. I still wanted to share in case it offers any support for you on your journey.

You are absolutely right. I spent a good portion of my life testing code on a "line coverage" basis to satisfy management. It was hard to see the value in it when I viewed it as this necessary evil.

I think it is hard because we are often left boiling an ocean of a problem when trying to build software or needing to implement "this thing" before I can do "that thing". Where do I even start? The setup eventually becomes so much that it really brings into question whether it was all worth it.

One thing I can say is, at least for me, TDD was something I had to see done well before I could start doing it. I was never strong enough to understand from an article, book, or video. I paid an expert to pair with me who, himself, got wrapped around the axle trying to implement the simplest of structures.

Ultimately it came down to me working with some folks who had exercised the "muscles" of implementing the practice and had several tools that made the process feasible. Intellij for Java was core, shortcuts, having one side of my screen the test, the other side implementation. Autorunning tests, a simple pipeline that tested, built, etc.

I just needed to see what good looked like to at least start forming an opinion on what was possible for me. Eventually I learned to take smaller and smaller chunks at a time. You want to write an API, sure. Let's just send a {curl equivalent in your preferred language} to this endpoint and get a 200 OK response. Alright, now let's make sure this header is present.

Try not to solve for the future as much as addressing what is in front of you at the moment, or maybe the next couple hours. You'll eventually notice common traits APIs have, database objects have, business logic you care about vs layers that don't belong to you and you can't really control anyway. There will be times that future issues will require you to build certain ways and you just won't know until you've been there a few times.

I learned to approach things with what they called the Triple A Pattern (AAA) and each test had these three blocks of behavior:

Arrange - Create all my objects, initialize, stub out skeletons I've maybe required parameters that I don't actually care about.

Act - Execute my function, catch my object.

Assert - Test that whatever I received is true, equal to "someVal" etc.

There's honestly so much more to say and I glossed over so much. In the beginning I can distinctly remember this existential pain of pulling my repo from git and my environment not running, some cached dependency or browser session breaking things. I constantly felt like I wasn't understanding but I was ultimately learning how much I didn't know about the toolchain, the language itself, the editor I was using and I was finally getting a very clear understanding because I was looking for a very specific response. I started learning how to say, "Based on what I understand, I expect this to happen..." If I'm surprised, then I'm on a new adventure or maybe need to regroup.

I think people believe TDD is supposed to be some panacea but it's only as good as the consistency someone leverages it with. Someone I really respected sold me when they said:

"It just felt nice making some changes and knowing these things I tested for wouldn't pop up again in prod."

That dread of 3am and my name being pulled into a Sev1 call because something was crashing over something simple (and it happened a few times) gave me anxiety constantly. You almost forget how much pressure you feel weighing you down until you leave that team, project, etc. It was a very freeing proposition that had the added bonus of not getting gaslit by people who didn't know what they were saying.

I hope my experience offers some value as I really enjoyed sharing it.

I love this part of the journey for folks because it opens the door to a world of possibilities that has dramatically more structure and form. Thoughts and ideas become less "what if.." and more puzzling together the best interactions between certain design implementations.

At risk of rattling on endlessly in my excitement for you, TDD became a very interesting and enjoyable way (for me at least) to implement these patterns and gain a better understanding. I think you'll find Martin Fowler, TDD, and IoC/DI are peas in a pod.

(I realize you said Python and this was Java. I'll see if I can find something Python friendly. If you'd like to try your hand with Java....I highly highly recommend Spring Framework and more specifically Spring Boot. Spring is an IoC Container Framework where the Dependency Injection is done for you on the fly. So much to throw at someone but if you'd like to connect on it, I'd be more than happy to give you a running start.)

Docker maybe a little more love-hate but I think that has a lot more to do with the politics and salesy side of things and "Who owns what"

If you told me:

"This pipeline will automatically perform all of your [insert line of business] testing, batteries included.

XYZ has signed off that if you get to the end of this pipeline you do not need to jump through any hoops to get to production." I would be screaming on a soapbox

There is too much process to know about a company to make any claim with any certainty and these companies will not tell you their process because you are a salesman, not their friend. Technology Sales is "Frenemys" at best and "Inherited Cancer" at worst.

Here's a pitch for OOP. If you do this you will have a line around the door: "You can run this on your own internal cloud, public cloud, or mix of both. Hit the eject button and it will give you a [Docker, CircleCI, Jenkins, Travis] playbook to lift and shift your pipeline. Every app that goes through alerts each C?O that cares how it meets their KPI, Security Whatever, etc.

Set the bar as high as you want to get through the pipeline. Mission Critical? Core Business? Skunkwerks? This can be in the DMZ, this can't...you make the rules, we are the engine that enforces them."

I can tell you right now, your success will be predicated on Networking and Security teams that work together effectively and selling high enough to start the ball rolling.

We have this absurd "Throw paint at a wall and see what sticks" approach to doing business and then "People don't really want what I made" response when it fails. Look inward.

I have found some of the greatest products I have used came from:

"I'm working on this project, the tools I currently have are just different forms of a hammer...I need a screwdriver. I built a screwdriver. This screwdriver is the only tool I'll consider when I face this situation."

The tools sell because the people doing the work and feeling the pain react strongly while pointing at the incompetent layers above with purchasing power. Giving (or showing) someone the solution and then taking it away is probably the most common reason I have seen someone leave a situation.

Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines...and surprise surprise when you look at where he came from...Ex-Google, Ex-VMW, RabbitMQ...

If OP wasn't in and around the source of all these tools above then they were at the very least first cousins to the story.

The sales cycle is long, integrations require multiple dimensions of executive buy-in, especially security and networking.

I think they made something nice but it felt like a nothing-burger story about something that is constantliy oscillating between bespoke and commoditized due to upstream problems that are such a mix of issues. Lack of oversight to micromanagement, inexperience to too much experience that they cannot let go of "the way it's always done".

It may be just my unpopular opinion but you are boiling an ocean of problems selling toolchains. Business and Tech are like water often finding the holes that lead to a path of least resistance, even when these erode the foundation of "core business". Toolchains that behave like guidelines and "parenting strategies" with removable guardrails have always offered the greatest rewards in my experience.