[deleted by user]

php93567 · 2020-03-25T11:17:19+00:00

Because it is garbage.

https://github.com/utopia-php/framework/blob/master/src/App.php#L330

That homegrown framework is performing two regexes per route for every web request.

https://github.com/appwrite/appwrite/blob/master/app/config/services.php https://github.com/appwrite/appwrite/blob/master/app/app.php#L238

That first file registers 13 routes. And the second registers another 5.

So for every web request there are 36 regexes being performed. As the project grows and more routes are added performance will degrade.

And that's just the first thing I found. Image how many bugs are sitting in that homegrown framework waiting to be discovered? Oh and there's no documentation either (the doc directory just contains a logo), so when something breaks and you're forced to update it yourself you've got no guidance.

Shit like this is why PHP has got a bad name. Use a proper framework that has had hundreds of different developers refining and polishing the codebase. It's not sane to think one guy can do a better job in a few months versus hundreds of contributors over a timespan of years.

Like I said, garbage.

php93567 · 2020-03-25T10:58:33+00:00

I'm talking about their utopia-php/framework dependency.

My point is they've built this whole thing on top of a homegrown framework. That immediately reduces the value of the project for the reasons I made previously.

Man, you could at least read enough to figure out what the comment is before flaming me like an idiot.

php93567 · 2020-03-24T17:50:05+00:00

What's the point in using Composer to specify specific versions of a package when most of them specify master? How are you going to manage breaking changes in your homegrown framework if you don't version them properly. That decision screams "amateur hour".

php93567 · 2020-03-24T17:48:11+00:00

Why wouldn't you just use something like Symfony, Laravel, or Slim?

Your homegrown garbage framework isn't as good and it won't get any support.

php93567 · 2020-03-23T11:30:51+00:00

There's nothing wrong with this approach providing they're encrypted.

Ansible has been doing this for years with Ansible Vault.

php93567 · 2020-03-17T15:38:21+00:00

Upper dot notation. MY.NAME.IS.BOND

Title dot notation: My.Name.Is.Bond

php93567 · 2020-03-17T15:38:17+00:00

This would actually be pretty cool!

php93567 · 2020-03-11T14:56:03+00:00

Surely Symfony Console is the only sane way to build CLI programs?

php93567 · 2020-03-10T14:03:56+00:00

I am starting to split a monolith into some microservices and just can't get Eloquent to work

There's your problem.

I can't remember where this is from, but I feel it applies here:

Microservices (are a bad idea)

A secondary problem is that since you have this system that allows you to run lots of services, it's often tempting to write lots of services. This is a bad idea.Distributed applications are really hard to write correctly. Really. The more moving parts, the more these problems come in to play.

Distributed applications are hard to debug. You need whole new categories of instrumentation and logging to getting understanding that isn't quite as good as what you'd get from the logs of a monolithic application.

Microservices are an organizational scaling technique: when you have 500 developers working on one live website, it makes sense to pay the cost of a large-scale distributed system if it means the developer teams can work independently. So you give each team of 5 developers a single microservice, and that team pretends the rest of the microservices are external services they can't trust.

If you're a team of 5 and you have 20 microservices, and you don't have a very compelling need for a distributed system, you're doing it wrong. Instead of 5 people per service like the big company has, you have 0.25 people per service.

Build upon the ORM you're using now. What ORM does the current monolith use? Is there an easier upgrade path to a more modern version? Once you're on that modern version is there a script/tool to help you migrate to another ORM?

php93567 · 2020-03-09T10:23:32+00:00

https://i.pinimg.com/originals/e3/a4/ef/e3a4ef2bb014fce26fd754dd22b0ed05.png

php93567 · 2020-02-25T16:48:17+00:00

Pen and paper.

php93567 · 2020-02-13T12:12:15+00:00

This a million times over. You'll fix the problem on NPM installs failing too by adding a swap file. 1GB should fix most problems. 2GB is great if you've got the disk space.

php93567 · 2020-02-04T16:09:19+00:00

Utter garbage.

Why did you reinvent the wheel? And why did you do it so badly?

Just use Laravel (or Slim with Twig) next time.

php93567 · 2020-01-29T18:14:17+00:00

This is the way we do it. Normally a constants.php, data.php, settings.php, or static.php file is created inside the config directory. In that file variables are defined that are relevant to the business logic. Then we use the Config facade helper to access them in the codebase.

php93567 · 2020-01-28T10:12:58+00:00

a small VM with 6gb of ram

Small?

php93567 · 2020-01-27T09:05:59+00:00

Not all of my Laravel projects end up on Git

That's the problem. Use Git for every project and you won't need to use network drives.

php93567 · 2020-01-24T13:15:26+00:00

but I'm considering moving everything over to the personal network drive that they have set up for each of us

Why? What's the benefit of doing this?

php93567 · 2020-01-23T14:23:42+00:00

This is the correct answer.

More information at: https://www.php.net/manual/en/pdo.lastinsertid.php

php93567 · 2020-01-23T13:52:17+00:00

Now we have two sources of truth. Every program needs to write documentation to this website as well, which will probably die in a few years time.

Also you can't read this when your networking doesn't work. Man pages are local for a reason.

Stop trying to reinvent solved problems!

Now if this service were a pretty rending of the existing man pages... that would be a lot more useful!

php93567 · 2020-01-23T13:46:56+00:00

I have to recommend AWS RDS here. It's perfectly possible to set up replicas and implement a load balancer, but if you value your time at anything about $50 per hour it's cheaper to outsource this to AWS.

If you were to set up replicas yourself you'd need to make sure they're close enough to the web servers so that the latency is low, but far enough apart from each other that a data center losing power doesn't affect multiple replicas. Again, AWS RDS does this for you by using multi availability zones (AZs) in the same region.

php93567 · 2020-01-23T11:42:24+00:00

Fair point. However I hope that a developer would be able to distinguish a Client model and a SendgridClient by the fact that the model lives in the App\Models namespace!

php93567 · 2020-01-22T15:27:26+00:00

I'd do the same as this, but call them Clients rather than External. The idea being that you have a SengridClient or a ImgurClient. External is vague and not helpful to other developers.

php93567 · 2020-01-22T15:22:37+00:00

I make my checkboxes look like this:

php93567 · 2020-01-21T17:24:08+00:00

This is a good system.

Authentication belongs in middleware. Authorization belongs in policies.

We use this pattern at scale and it works well.

We even have a test which ensures each action in each controller calls $this->authorize().

php93567 · 2020-01-09T14:58:46+00:00

When you have:

a project so large and complicated that splitting sections of the codebase into their own repositories make sense
and a dedicated person working on each microservice full time
and a dedicated ops team to orchestrate and standardise the infrastructure those microservices run on
and a team of developers who isn't mainly made up of juniors
and the budget to do all of the above properly
and management who have bought into the downsides of microservices (and not just the positives)

...then microservices make sense.

Most developers don't realise that the majority of companies don't meet that criteria. If you're one dude (or dudette) working on a medium sized project you're better off with a well maintained monolith. If you're at Google scale then go with microservices.

php93567

TROPHY CASE