safaci2000

Well your also hardware locked. The last time I worked on a mainframe (about a decade), 8 mb of RAM was $1000, a network card was $800. Commodity hardware around the same time 8mb was probably $50 and a network card even a good one was most $100.

You're paying a premium for both the hardware and the lack of develops knowing EBSIDIC, JCL, Cobol, etc..

Actually, from what I remember of Oracle, that might be very similar. I remember having to pay license fees per core.

sure, I've touched on include a bit and removes some of the repetitive code.

I would rather have something like:

release.yml documentation.yml security-scan.yml

I know you can define all these in a common repo and then have a few lines to include them but it's not exactly the same IMO.

Not to mention that now I need to pull another repo to see what is going on and why the task no longer works.

This blog articles feels too black or white.

There's a middle ground between microservices and de-coupling. The UI can be written in JS/TS with a backend written in a more scalable faster language. It doesn't need to be all or nothing? Even if you stick to Ruby pulling some things apart due to separate concern/responsibilities is not a bad approach. Aka if you have workers/cleanup operations they don't need to live in the same code as your REST/MVC code base.

Also, it would be nice if their CI/CD could be defined in multiple .yml instead of one giant file that I seem to end up in most projects.

Yeah this was years ago but we had concept of 'hydrated' objects so you'd pass a flag to get back shallow object or the hydrated version that had all the relationship loaded as well.

Some flags for helpers that fetch additional data would be good.

They have UI helper tools with auto-completion, it's not a complete answer but it should make life easier. The select(*) not being supported seems to be an intentional choice unfortunately.

to be fair, a kernel dev is so far down his rabbit hole that web services and web tech is not something that they're particularly interested in. They also know intricate details on what my kernel does that I have no hope of ever understand or desire to. They exceed at what they're passionate about.

Just to make the conversation easier the use case I have is a network topology so you have things like routers, switches, ports etc. If you take it all the way up to Layer 7 (Application) you can have say web services etc. So you could in theory say link X was cut what is affected?

Anyways... my basic POC was exposing endpoints so I can do things like.

/devices/list /network/shortestPath?node1=<>&node2=<>

to get a list of all devices but I'm basically just writing custom Cipher code to do that query and the benefits of Neo4J basically go out the door. It still has some interesting Graph features but if all i'm doing is writing a custom endpoint for every use case it's mainly pointless.

You can do a simple POST statement which takes a Neo4J query and execute it with some caching on top of it for sure.

Either ways in order to make Neo4J worth it I need a way to make the queries more dynamic. So right now I'm thinking of:

- restQL http://restql.b2w.io/ - GraphQL https://graphql.org/

Or just having a dumb POST /custom/query that maybe only supports read operations. You can add a layer of auth but I'm not a big fan of just having some endpoint that's basically a Pipe to Neo4j. It feels just as bad as saying, typing any SQL here and we'll execute it on the server. If people know what they're doing that's fine..but at that point just setup phpMyAdmin/ pgAdmin. At that point you're trusting folks to know what they're doing and if folks accidently drop Bobby Tables (https://xkcd.com/327/) then it's an accepted risk.

If you just have a proxy to run any Cipher query, you might as well just provide users on Neo4J web instance and let them play there.

Anyways, still in early stages trying to figure out how to best leverage Neo4J

The first interaction I had with GraphQL the developer who introduced tried to make it TOO smart for its own good. It was building complex SQL dynamically which means the SQL that it was running was borderline non-deterministic.

(Aka. identified the foreign keys and primary keys linked them together and made all other fields options)

Things I don't like about GraphQL (In Java which was my experience)

1. Debugging it is annoying. There's no clear concise way to follow the code there seems to be some magic that happens where it isn't clear when certain parts of the code get invoked.

Things I like about it.

1. Lets you make multiple queries and reduce/extend the size of your payload as needed.

In my view graphQL is much better when you're not constrained by a SQL like backend. It's great at filtering the payloads which is great for mobile and such. It also allows you make multiple calls in one go which also means you can shoot yourself in the foot if you over do it.

I will call out that some of this is trauma based from my last experience. Having a more dynamic language that isn't Java may make the experience better but in general everytime we had to update the GraphQL code it was cringy.

Eventually started to gut the dynamic SQL and replacing it with a simple Query and then used GraphQL and trim the response which worked out much better.

Generally the question to ask is how many iterations of an endpoint do you need and is it worth introducing a new technology vs just having a few query parameters to do some filtering.

That being said, I'm now looking at some Query language to work with Neo4J so I'm back at looking at dynamic APIs. (:

Do you have a link for any docs on that? Last I looked it was a weird hack using LB that translated IPv6 to K8s' native IPV4

I was about to say. Cause they can't figure out IPV6 either. Their K8 and VPC networking is still not IPv6 complaint last I checked. If you're bored you can get this [extention](https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffn...) and see just how much of the internet is actually IPv6

That's great to hear, now if only Google's cloud offerings were also a bit more IPv6 friendly. for example: https://stackoverflow.com/questions/59856468/does-gcp-allow-...

This might be in poor taste, but will the next Madden game be a zombie FPS next year?

Wait you mean asking: "how many turkeys are in turkey doesn't count as meaningful?"

I'm honestly surprised by quantity even. I'd question the quality from my brief experience with it I didn't find it that impressive.

The quantity aspect is also a bit surprising since it hasn't been that long that it's been released, so seeing a #1 leader is impressive in itself, even if it's free and integrated.

I mean I have a bunch of TravisCI projects that I really don't want to migrate over unless I have a good reason. The "if it works" leave it alone.

If there's enough motivation for people to switch it's impressive (or it shows how much people hate travis/jenkins/whatever CI they ARE using)

I've used Gitlab before, I have found it to be more complicated than I'd like. Not sure why but it feels harder to use.

These days Drone CI is my current favorite for OSS projects, I'm forced to use gitlab at work so that's what we use for internal projects.

I think Drone appeals to me for its simplicity, golang choice and docker everything. Not that it doesn't have its own set of issues as well.

"GitHub Actions has become the #1 CI service, used by popular open source projects and enterprises alike."

I must be missing something. For whatever reason GH Actions just never appealed to me. Am I missing something? I've used Drone IO more, granted it's better than travis but the #1 CI services seems like a stretch.

it looks like a cool project though what I'd love to see is some solution that makes PGP/Secure Email more accessible to the common person. I know hushmail, tutanota, and protonmail are all around, but still only works if everyone is on the same service.

it's interesting how secure email has been solved decades ago (how to do it) but making it accessible has been an ongoing struggle. :(

Anyone ran across a more tangible solution for the common man?

This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the library you were relying one has disappeared.

Anything you use in a critical path you should control. If you're managing your own fork, nobody will inject bad code except yourself.

Just my 2 cents. Also, the things that github 3rd party actions are doing is usually not that complicated. I mean how many different ways can you publish a docker image or deploy an artifact to S3. Once it works, it either works or doesn't. It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).

Sorry minor rant. food for thought.

I have the complete opposite point of view. I never used @Cleanup but at least the @Data annotation makes it much more readable IMO.

There is tons of boilerplate in a simple Java bean, so when you have 3 pages of getters/setters, equals, hashcode, toString etc... and someone introduces something hacky it doesn't jump out at you.

To be fair, it doesn't have to be a hack, but it's doing something weird that's unexpected.

Then if I use @Data and I still see a Getter/Setter defined it calls it to my attention since odds are i'm doing something different.

ie. Oh, you're parsing a string get a numeric value and then setting it with a fallback value/exception. Okay good to know. If it screws up at least I know there is a special behavior here.

Lombok makes these patterns much easier to read though I prefer to only use it for repeat code. Saving one line so you can have @Cleanup doesn't seem worth it to me. It hides too much as you said above, but it varies on the use case.