conatus

> You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins.

Planning meeting, ad hoc meeting doing the work then weekly/bi-weekly show and tells to show progress. Sounds like...some version of agile?

Remember agile and the XP movement that preceded it was invented by software makers, who had observed the pattern you describe and decided to be self-conscious about it.

Cool to see this out, but there is something about Tailwind I've never really got. And this is not from abstraction, but in production use on a number of pretty large sites.

Each Tailwind class corresponds to a CSS property, with a few exceptions where you have utility classes for degrees of that property (for example, padding, margin). Then along come these CSS component libraries, which substitute a thicket of these utility classes for a single class. Including Tailwind UI itself.

Given that the relationship of class to property is one to one, why not cut out the middle person and just use CSS directly? There seems no real advantage. You've basically indepedently re-invented CSS, while adding a strange layer of additional abstraction on top. It is nice and fast to write it in the HTML I'll grant, but, the speed advantage is not so great that it is worth it compared to the mental overhead of other aspects of working with Tailwind (e.g. having to trim all the classes with automated scripts and so on).

Perhaps I am missing something here?

Thanks! I guess none of them are amazing, which is why you built this :)

This is very cool and interesting. Are there any other Zapier clones out there in the open source world?

You probably understand these points better than I do!

I just don't think it is truly as bad as has been made out by the initial comment.

Massive fan of Laravel. If the relationship between Statamic and Laravel is similar to that between Wagtail and Python, plus the static storage, it seems like it would be very good indeed.

This is true. I understand other languages (for example Go) have very nice features of this kind - contextual auto-escaping and so on. However a lot of other languages also have these footguns around escaping and security.

Fair enough. Probably at "agree to disagree" here.

I'll agree that its easier to do custom post types on other CMS. But sometimes at the cost of real overheads in terms of complexity for users to swallow to get there.

Caching is built into the core, which is what all caching plugins leverage, the interface to it is hidden.

PHP is a theming engine.

I've never got why people escape into Blade, Twig or so on. PHP was designed to have loops, logic, to take variables and so on and interpolate them within HTML. It has an alternative syntax to make this easier. It's one of the unique capabilities the language has over almost all other languages you'd use on the web. More often than not you end up escaping into pure PHP in any case in something like Blade.

> But the problem isn't random sites use WordPress, the problem is people build weird monstrosities on top of a really garbage system.

Don't think its garbage for the reasons explained, but I think this true of all software projects. Seen plennty of Drupal, Laravel or Joomla projects end in this state.

Massive props to Studio 24 for showing their working in public on all of this. It is amazing to see. More large scale projects of this kind should do this sort of thing.

Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!

There are a couple of interesting things in this article.

1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.

2.

> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.

It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?

Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.

3.

> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.

This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.

- Use Craft

- "We are currently considering a Headless CMS option for front-end page delivery"

It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".

Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.

Further: the headless CMS option.

Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.

One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?

Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.

Most of this plain isn't true - afraid it does feel very much like a bubble there!

> - Uses PHP 5 spaghetti code with a handful of garbage event listeners and output buffering

I mean it has listeners for almost every event you might want to interupt and trigger something on that are well documented and have been for decades.

The PHP 5 code is very much legacy so I will grant you this.

> - Has no integration with composer at all

Composer support is absolutely fine and there are well maintained ways of keeping plugins and themes under Composer and have been for many years.

> - Doesn't have any form of content types without plugins

Yes, but adding further content types at the level of code or these plugins is easy, trivially so.

> - Has no cache, no theming engine, no multi-language, etc etc

It has several caches that are very powerful indeed, including those included by default. PHP is a theming engine.

Internationalisation built into the core, I'll grant the multi-language support is not as good as it might be. Could be better.

> - Beyond a media library it has literally no aspects of a "content management system"

I mean, people use it to run newspapers, so not sure if this is true. It depends what you need.

The organisations behind WordPress decided to meet their user need and provide a really good, well understood platform for content management with an extensively tested UX experience of end users. They prioritised this over developer niceities.

If the purpose of software is to augment human capacity and be genuinely useful, this was the right decision. The rough edges from a developer experience perspective have been largely smoothed off by a well established ecosystem like Roots.

It's a perennial but: unit tests are more about how you think and rigourously approach a problem than preventing regression. I'd say if you wrote unit tests and then deleted them, your code would be better for it. Indeed, I often don't commit some of the tests I've written in order to write the code! I'll ship some subset of them. It's a notebook.

They serve as a form of living documentation for the code and help increase velocity in a build under the right conditions.

For example, you do need to know a certain function does what you think it does because the rest of the system isn't even in place yet. You might have to approach this from the outside, via integration, but the speed of doing this is quite slow. Versus a unit test.

This is not to mention refactoring!

The piece seems to be more about the value of mocking and how far to go with isolation. Which is a slightly tangential issue. I agree that in particular styles of object orientated programming this becomes absurd.

This article, which is linked provides a more convincing case, on the grounds that unit testing foregrounds the system as software as opposed to the software as a useful and functional thing in the world, meeting user needs.

However, it omits the being about to _react_ to user needs is actually a central party of agility. Unit testing allows maximum reactivity to changing requirements without regressions in the code and makes this code navigable. Changing customer needs means your carefully built functional tests are going to be just as useless and rotted. This has been the case with large test suites of functional tests - say in something like Cucumber - I've seen. Better test at a lower level, which moves slightly less rapidly.

https://www.sacrideo.us/the-fallacy-of-unit-testing/

> The overwhelming majority of JS developers learn the basics before moving on to a modern framework.

I'm not sure if this is the case.

I actually set this as an interview question for mid-weight to senior on paper front end engineers and a solid 60% couldn't do it - this was four years ago. Not being able to do this wasn't a "fail" by the way, it was more something to talk around, especially when people successfully reasoned it out without knowing the underlying API, but it did reveal a relatively shallow understanding of the browser environment.

I imagine it is significantly worse now. Do the training course at boot camps take people up from `querySelectorAll` before jumping into React? I'm not sure they do.

No, I'm not. Libraries were certainly used in this case.

But whereas in Rails this would be mixing in a library to a controller to allow events and configuring them, this was building a new set of models and code over the top of a library for something like Mailgun from no code. A two hour job in Rails/Django/Phoenix but a two week sprint long job to roll your own. Why bother?

While this is a great talk, and a great web app, I think there is a bit of over compensation on their part, because of them being in the unique position of having founded and had to manage the ticket burden of a very popular (backend) framework - Django.

It's odd because in the talk he advocates patterns over frameworks. Django is an implementation of MVC, as is well known. What is the value of implementing MVC again in Python when someone really has done that job for you?

There is a bit of a slight of hand here. If someone had built a frontend framework in Javascript and was now no longer advocating them, that would be a cleaner argument. But we have a shift of abstraction here from front to back end, when the two domains need to deal with different worries.

"The value of a software is not the code itself but in the reasons behind the existence of that code"

I wholly agree with this. However, I'm sort of baffled by this approach. What frameworks allow is you not to have to continiously solve the same problem and waste weeks implementing something that others have solved.

For example, I worked with a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user". In the world of Rails, Django, Laravel and Phoenix this is a configuration task, with existing libraries. In Javascript it was a slog getting the implementation that still lacked much of the functionality of these mature frameworks (there are notification frameworks for Javascript but it was decided not to use them - "no frameworks"!). While it is fun to implement your own thing, here the reasons behind the existence of the code are essentially developer vanity in thinking their notification situation is an absolutely special case, and developer desire to do something stimulating like develop a notification system rather than serve product, organisational or user needs.

To have a clear discussion of this, however, it might be useful to define "framework". Is the target here frontend or backend frameworks? One thing I have observed is in the frontend world frameworks have caused some core skills to atrophy. For example, how many Javascript front end engineers can now confidently, given you click on something, change the colour of it. Probably here a framework is wildly overkill and you will get there with plain Javascript until such a point as complex user interaction is needed.

Realise rhetorically there is less punch to "use a framework mindfully" but this should be basic to any engineering decision "use a language mindfully" and in the last instance "do we need to solve this with software"? Doesn't sound like a movement per sae but corre software engineering skills - use the right tool situationally.

Cool. Found your email, will drop you a line.

Usually cooperatives have to have a base in one country for legal reasons as (sadly) they need some kind of legal recognition.

But in a sense this makes no difference from remote first companies, like Buffer, 37signals or Automattic.

Happy to hook you up with someone to advise, but as people are saying would be good to know your location first.

We have flat salaries at Common Knowledge. Our wager is the cooperative as a collective wouldn't exist without everyone working on it, so think it is more fair if everyone earns the same.

However, a lot of other cooperatives have different rates that work around a matrix of: hours worked, skill level and life need. These are democratically decided by the cooperative and tend to also have a pay ratio - e.g. the top earner can only earn 3x from the bottom.

DEV have a nice page on how they work this out - https://www.dev.ngo/join/pay-principles/

I'm also a member of a tech cooperative in the UK - indeed I've been part of two: - Outlandish - https://outlandish.com/ - Common Knowledge (which I founded) - https://commonknowledge.coop/

I was also at the founding of CoTech (a UK network of tech cooperatives). Common Knowledge are a member.

Happy to answer any questions here or hit me up at alex at commonknowledge.coop for anything further.

In the UK the process of setting up a simple co-operative takes about a month. It's filling in a set of forms on top of a normal company registration and applying to Co-operatives UK for accreditation. Basically no sweat.

My bad, it was a little hidden, sentence beginning "There are a few settings that can be set within Google Calendar to prevent events from automatically being added to the calendar".

This advisory has no mitigation it appears. Does anyone have one? I presume one can simply turn this feature off entirely somehow?

The sense of massive deja vu settles over me when I see these pieces. Or more accurately: hasn't this been done already?

I studied continental philosophy as a graduate student about ten years ago and have kept up since as much as possible.

Continental philosophy was the spawning pool for the loose cluster of tendencies[0] that form the concept of postmodernism in the imagination of most - Derrida, Foucault, Lyotard.

At this time, it seemed definitively that this set of ideas this lot was on the way out. There was even a term for what was bad about them, as captured in After Finitude: An Essay On The Necessity Of Contingency by Quentin Meillassoux: correlationism[1]. The idea that human thought never "got at" the truth because of intermediate cognitive or societal structures or biases. There was a whole movement against correlationism called speculative realism[2]. In the UK at least, indeed, the focus of continental philosophy that preceded it seemed to oppose this postmodernism taken as a name for this cluster of thinkers. Broadly, a solid focus on Deleuze resulting in "new materialisms" (often scientifically informed) and a figure like Alain Badiou (Meillassoux's tutor) who very much attempted to stake out the ground for Truth with a big-olde-capital-T.

So to me that it is still a live term and people are talking about it so much is pretty strange. Of course that continental philosophy influences other discourses, and that both Derrida and Foucault were quite interdisciplinary in their work. So one could say this is some sort of institutional lag. But it is an odd thing to observe[3].

---

[0] I say this because Foucault and Derrida are better described as post-structuralists and this is what they would have considered themselves as. Lyotard helped assist the terms with his work certainly in La Condition postmoderne: Rapport sur le savoir but it was a term of societal diagnosis rather than support. I feel that postmodernism as a cluster term was the result of the reception of these theories in American literary theory departments.

[1] https://en.wikipedia.org/wiki/Object-oriented_ontology#Criti...

[2] https://en.wikipedia.org/wiki/Speculative_realism

[3] I'm not actually adjudicating here on the merits or otherwise of those thinkers grouped as postmodern. That's another topic.

Yeah. I was expecting some level of proposal. I expected the article to have more, so downloaded the PDF. Nothing more!

This at Medium seems relevant from an Amazon employee on the facial recognition aspect of this.

https://medium.com/s/story/im-an-amazon-employee-my-company-...