There are a lot of ways to participate on the internet these days. You can post to Facebook to scrape trivial opinions from friends or get into word wars with people you've never met before; you can post to Medium if you've got a lot of well organized thoughts about things that other people might care about; you can tweet if you want to make other people's opinions or work more visible; you can ask and answer questions on Stack Exchange to contribute to public technical documentation....
But there's another class of content that I don't really feel is right for these various fora. This is the trivial and/or hyper-personal stuff that won't necessarily be interesting or useful to most other people, but should be indexed by Google anyway in case someone ever asks about it. I've got a ton of this stuff, and it's why I wanted this website.
So I'm looking forward to posting a bunch of wildly uninteresting tidbits about computers and systems and cooking and such. But I'm also looking forward to sharing more meaningful and more personal thoughts about a lot of things. These might be personal discoveries that I've made, philosophies that I've developed, emails that I've sent, and other such things—in short, prime fodder for self-help books; things that people who are looking for them might benefit from reading.
My hope is that the content I produce may serve the world in at least some minimal way, if only to aid in hacking around a stupid computer bug or revealing that someone else shares your disparaging opinions on the idiosyncracies of youth in a new generation. I'll never have ads, and I won't receive benefits to plug products. This is because this website is my home, and if there's one place I can be 100%, unrepentently honest about people, products, books, and myself, it's at home.
So please do read with the necessary grain of salt. I am not a journalist; I am not a scientist or an academic; my opinions are not those of an expert. I am a human providing yet another perspective to consider (or not) in a space that's both a public forum and a humble and private abode for thoughts.
(P.s., All of my content is Creative Commons Attribution-ShareAlike licensed :))
(P.p.s, Since I haven't gotten comments going on anything yet, try Hypothes.is if you'd like to share your thoughts.)
The Skel Framework
Aha! There's another reason I built this website. Over my years as a fringe participant in the web dev industry, I perpetrated an ad hoc development process that resulted in a sort of janky personal framework that I used to build websites. This worked well enough, and indeed there were some decent concepts in it, but it had run its course. Over those same years, PHP had developed a rich set of OOP features, I had actually learned to use those OOP features, and above all, at the new scale of web dev, it was hugely detrimental to clients to use a framework that was neither used by anyone else nor documented, nor even particularly logical.
In June of 2016, after reading extensively on Java development, Object-Oriented Programming design patterns, and the Android operating system and associated development framework, I decided to scratch the itch.
Did We Really Need Another Web Framework?
Of course not. But building this framework was the perfect project for exploring a series of modern concepts, including test-driven development[1], inline documentation, the separation of functionality and interface, the packaging of libraries, code reusability, API development, and object-oriented programming concepts in general.
Just before launching this project, I started to explore the Symfony Framework, and it's derivative Silex. My impression is that these may very well address the needs that I hoped to address by building the Skel Framework. Still, though, I felt frustrated using them. The problem was two-fold:
First, they were bloated. Every framework carries with it a bag of toys that inevitably won't be fully utilized. This has always frustrated me. Bolt, for example (built on Silex), claims to be a lightweight CMS and blogging platform, but a fresh Bolt install is 95Mib. That seems totally crazy to me, and frankly, I thought I could do better.
Second, no framework has ever felt intuitive to me, and I realized that this is because Logic is a religion like all the rest. All frameworks are built around the specific logic of their creators, and that logic is not shared by all (I have a lot more to say on this, and will soon write at length on the subject).
The solution to both of these issues, to me at least, was to create a framework that was 100% interfaces[2]. Ideally, the entire framework should exist in the 400 or so lines of a header file that defines the various classes and their methods without defining how they work. Under this concept, the only real dependency for the framework is the 400-line header file. With header in hand, you can implement what you need, stub out what you don't, and as your needs grow, you can sub in more complex parts that you or others may develop.
One advantage of this is that you can avoid the bloat. It encourages the fine-grained packaging of components, such that you can include in your project only what you want, and implement the rest yourself.
The other very important advantage is that you can actually create your own framework, but in a way that won't make other developers cringe when they hear you're using a "custom framework" for your project. In other words, because the interactions between the interfaces of the Skel Framework components are clearly defined and well documented (at least they will be eventually ;)), other developers will be able to step into your project, debug it, and develop it without a huge learning curve, even while the components themselves were developed using your own logic and in a way that's easy and intuitive for you.
Reality Sets In
Now you know why I built Skel. But does any of this lofty talk actually hold water? Some certainly does; much does not. The subtlties of our particularly complex reality are not captured in theory, and so one simply cannot create a perfect framework. This is perhaps the most important lesson that I've learned so far in designing and implementing Skel. It was so easy to see how Ruby on Rails or Zend or Symfony or Silex or Bolt or Wordpress failed in certain ways, and those seemingly flagrant design errors led me to believe that this was a simple task and that we just hadn't approached it correctly. I know better now.
I'll continue to hack away at Skel, documenting as I pass the v1.0 post, adding testing, fleshing out the API, and improving my own implementations of the interfaces. But in the end, I'm not sure it will really contribute anything to the world of web development. Regardless, it has contributed much to my understanding of applications, frameworks, and programming concepts, and for that it will remain useful to me into the future.
Skel\Component
All that said, there's one really important element that came out of this and it is the Component. One of the central aims of Skel was to achieve a true separation of logic from interface. This is arguably the aim of all MVC frameworks, but I feel that Skel does this particularly well, allowing for the creation of truly interface-agnostic libraries. Since Skel doesn't assume an HTML interface (or even HTTP), its focus is on packaging and combining hierarchical data components. A Component (and it's sister ComponentCollection) is the hierarchical package it uses.
Component is a wildly simple class. It's accessed like an array (i.e., you get and set elements by using $component['element']), and it has a render method that renders it into a template, if provided (and throws an error if the template is not provided). When it's rendered, all children that are components are also rendered into their respective templates (which may optionally be programs in and of themselves that execute in the controlled environment of the Component), all children that are not components are cast as strings, and all elements are then presented to the template, including the Component itself (which allows a given template to "reach into" the component and extract data from deeper in its hierarchy, if desired).
The practical result of this system is that libraries can safely return Components, whether the end goal is to render those components on a webpage, a desktop GUI, or a CLI. Thus, I can now create a GnuCash library that executes its particular functionality and returns data components that I display on my HTML webpage, and my library can also be used by someone looking to create a service that does something completely different. Exactly what I wanted :).
Roadmap
To do in the coming months is to define the API, add documentation, and then create a webspace for the framework that more fully explains its philosophy and exemplifies its uses. I'm looking forward to accomplishing these goals, but time, as always, will be short, and there are plenty of other things to do.
Notes
[1]: Note that one of the important things I learned while building this framework was that, while designing the interface first is the ideal, it doesn't seem to work in practice until things stabilize in the v1.0 release. I wasted many, many hours documenting and writing tests for things that I ended up scrapping the next day anyway, and so I completely stopped documenting and stopped writing tests until I had a specific thing I wanted to test (rather than a comprehensive test to a pre-established specification).
[2]: The framework's API is actually as yet undefined. As noted above, the interfaces were changing too quickly to make defining them useful at first, so I started to add empty interfaces that I then planned to go back and more strictly define later. I'll likely get around to fleshing these out in the coming months.