There are a couple of reasons but I can cite a few, I tried to push for PaaS and failed the hard way:
1. No widespread practice of environment provisioning automation. Today Docker and k8s are ubiquitous. Having a list of requirements your application needs well kept were hard to find - which Heroku needs.
2. In the same sense as above, automated deployment was not a common thing.
3. Barriers to cloud adoption. Development tools were not widespread. Paying for software development and deployment is common now, it wasn't.
I agree. If we can start a culture of relying on SQLite instead of PostgreSQL/MySQL, a whole server-side application can be a simple standalone binary.
Also, having a binary makes it easy to bundle in an Electron app.
They do something which is "common" in Apple-land (Dash for MacOS does this, a Twitter client did this as well, over and over): They get the same app, add some features, call it v2, launch as a new app and remove v1 from the store.
They don't "give" you the new version. They take away the app you paid "once", and provide you with a version with an expire date. So you have no choice. You either pay them, again, or lose access to the v2 (subscription based) app.
I don't mind paying for good software, I even think Hallide is worth $60. But I won't make the same mistake again. So best of luck Lux! I really wish you all the success. If you treat your customers right this time.
I might be missing something here but thet "Calendar API" exists for a long time: CalDav.
You can have .ical for a whole Calendar, not only an (offline) event. The calendar can be synced with new events, through CalDav, when they are added to the calendar you shared. You would still have to accept the prompt once but that is it.
I am not against your rant, your are 100% on point there, but maybe your code without framework has issues you don't know?
I would rant against this forced and meaningless deprecations on Symfony-land but the main issue with PHP, IMHO, is people using it don't grok the language strengths - much in the same direction of your rant. For 5-10 years PHP developers have been trying to "bring" great features from other ecosystems making PHP not to be good on anything anymore.
I feel sad. I liked the "hack 'n slash" programming style it allowed. Now everything (everywhere) needs a package manager, a build system, etc.
PHP doesn't do a lot of BC-break. Proposing one and getting it accepted is very difficult (2/3 of +1 votes required). Most cases of BC breaks are based on security concerns.
PHP didn't learn from Python 3 BC fiasco, its governance makes such changes very difficult to be made.
I'd like to complement that. Defining/Discovering the vocabulary for the Ubiquitous Language along with Bounded Contexts (Strategic Design) is where most benefits come from. And is, as said and I agree, the most difficult part - there are no recipes, shortcuts or tools to do that for you.
It doesn't help that there is a bunch of frameworks, libraries, articles with "DDD" on their name, mindlessly gluing together patterns and segregating them into layers (Building Blocks). What I see happening the most is people using them and complaining. Which they should.
Of the two parts that compose DDD, "Strategic Design" and "Building Blocks", only one is essential: Strategic Design. But people usually just talk about the "Building Blocks" (a.k.a Anemic Models), as it seems to be the case of "stevebmark" comment. I agree with him that just having Anemic Models, following blindly the Building Blocks part of DDD as rule, is bad. I just think that calling it DDD is a mistake. DDD is the Strategic Design, you don't even need the code for it to work or produce value.
TLDR: Stripe bought TaxJar last year, to help customers “automatically calculate, report and file sales taxes”. ~25% of TaxJars employees let go this July, when Stripe's valuation dropped 28%.
I cannot recommend "The evolution of cooperation" (Robert Axelrod), the source for the game, enough.
It is written by a journalist, so it reads well, about a Math doctorate applying the theory in other areas. Richard Dawkings vets it for biology and writes the foreword in the book.
I am yet to know people who Review code and use Gerrit to name a better solution.
I belonged to a team that used Gerrit for Review and Hosting, we changed to hosted Gitlab because people missed a "GitHub-like UI" they were used to. It was unanimous that Code Review on Gerrit was way better:
1. You start reviewing the commit message, that is the first touch point with a change everyone has
2. Navigation is done from file to file
3. On Gerrit there isn't two people commenting the same thing, because:
3.a. Messages from different people on the same line change are displayed together, not as different threads.
3.b. The review of a previous version is displayed with the next version, so you can continue the same discussion
I understand that GitHub/GitLab interface is more friendly, but their code-review really stands in the way of producing good software by not favoring good commit messages and long discussions.
I think it is a pretty fair as they have people working full time in their products since their conception. I'd rather companies providing their source and strugling to monetize their product than companies selling just closed source alternatives.
Restrictions could be provided by people through OSS, these companies don't prevent these alternatives from existing. The lack of interest does. The same could be said about many OSS that strugle to receive donations.
I could agree that a world where only OSS without monetization exists, where people donate and keep people investing their time on improving OSS without needing restrictions. The reality is that without these restrictions, people are not willing to pay.
I like the "slim" approach on LOC, kudos to that.
I would point some - IMO - design problems:
# Static attributes and methods. Are they really needed? They are difficult to test and predict, specially the public attributes.
# The "echo"s on routes. Since every route is a method (encapsulated by one), this behavior could be easily avoided (easier to test and control). You are already using callables, you can easily test (and run) matching routes to execute any callable until a stream is given (on Respect/Rest we learned what a powerful feature it is).
# Lack of tests. Although low LOC, there is much happening, specially on the "dispatch" method (it would be awesome to know through tests what the If's/Else's actually do and prevent).
# Why (as mentioned before) the error header do not provide a proper HTTP header!? It would also be nice to provide two different error routes: one for client errors (404: not found, forbidden) and another to server errors (HTTP/1.1 500 Server Error).
A suggestion (we've been talking a lot on Respect/Rest) is to implement the URI Template (RFC 6570) for matching routes and hydration of parameters (something macaw lacks but i like using the PHP way of $_GET, $_POST and filter_input()).
With a component dealing nicely with URI Templates many projects would benefit from it.
That is partially what was done.
Other than increasing the buffer size, he did a partition on the data.
Together with the buffer size increase, if he created another table using the "archive" engine and kept pruning the data form the `domain` table to this archive table he would achieve the same thing with persistance.
All in all, it was a very nice solution and use case for the memory table! :)
1. No widespread practice of environment provisioning automation. Today Docker and k8s are ubiquitous. Having a list of requirements your application needs well kept were hard to find - which Heroku needs. 2. In the same sense as above, automated deployment was not a common thing. 3. Barriers to cloud adoption. Development tools were not widespread. Paying for software development and deployment is common now, it wasn't.