2020/04/22/Ferreteria

Codeblog 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

Some thoughts on the idea that it's better to set out to write an app than to write a framework:

I started writing Ferreteria before I knew that web app frameworks (WAFs) were a thing. I didn't even realize I was writing a framework; I just ended up realizing that a lot of the stuff I'd written could be reused.

Later on, after writing most of Ferreteria, I still didn't know that WAFs were a thing; all I knew about was CMSs that could be used as frameworks -- like WordPress, Drupal, and Joomla. I looked seriously at Drupal a couple of times, but there were bits of it I really didn't like, so I decided to stick with Ferreteria.

When I did find out about WAF, my impression was that they were all heavy on front-end scripting, possibly dependent on extra server processes (aside from basic stuff like Apache/Nginx and MySQL/Postfix), and generally kinda bloaty. Not really interested.

So now I'm at the point where I can see advantages to switching to a 3rd-party WAF -- although I still don't know of any PHP frameworks which fit the bill (no JS required, but handling front-end GUI stuff like logins and menu-navigation). They may exist, but finding that information seems to be a slow process. (There are non-PHP frameworks which look like they might, but that'll require learning a new language-environment, which increases the amount of time-investment needed in order to get anywhere. That's not a deal-breaker, but it does weigh against those options.)

What I'm thinking is that I'll go ahead and get Ferreteria where I think it needs to be in order to be useful and maintainable, then take a closer look at the field and see what else is available.

It may be that what anyone else has written will never work as well for my brain as something I've written -- but given that even what I've written often leaves me going WTF, I don't feel huge emotional investment in that idea. e.g. I used MediaWiki for lots of stuff for many years, and found much to complain about, but it was still very useable as a framework.

You can sit down and write a game without first writing an engine, and in fact this is very often the better approach...

Substitute "web app" for "game", and this is in fact what I set out to do; the engine (framework) just kinda happened by accident, as I found myself doing certain operations over and over again... and then started seeing patterns across different operations which could be generalized into a class hierarchy...

Most hobby developers who “finish” an “engine” that was designed and built in isolation (with the goal of having an engine, not a game, upon completion) can’t ever actually use it, and neither can anybody else. Since the project didn’t have any goals, any boundaries, or any tangible applications, it essentially attempted to solve every aspect of the chosen problem space and consequently failed miserably.

Trying to make the API too general, to cover cases that I might run into at some point but haven't actually encountered yet and may never encounter, was a mistake I made at first -- but now I'm trying to be much more rigorous about requiring not only usage-cases for every function, but also documentation of at least one example, in the comments, when it doesn't seem totally obvious how a function or class might be needed.

I'm kinda realizing in retrospect how much Ed at Carrier taught me about app design -- especially business app design, but this article makes me think that many of the principles apply to game app design as well.

1. Have a clear idea in mind of what you want
2. Spell out as much as possible the mechanics of how it will work
3. Code from that spec.

I tend to be weak on step 2 because it's really time-consuming and means a longer gap between idea and something that does anything and gives you that necessary jolt of dopamine for wanting to keep going, but I tend to fall back on it when things get too complex to keep in my head. ...if I can even figure out how to document what I've got in my head (which has been a sticking point for this latest round of revisions).

(When I say "it's really time-consuming", of course i mean mainly in the short run -- in the long run it saves time, because better code that's easier to maintain.)