I really disagree, skills are really quite useful and there is a lot of usage + community - e.g. take a look at https://github.com/obra/superpowers which I know is used by a lot of people to smooth out their workflow with Claude with great results (not forced spec driven development just better context use + better results). Just this week I used skills to help encapsulate a way to document legacy services ahead of a rewrite (given that my experience now is that rewriting becomes a valid path vs refactoring in many instances): https://github.com/cliftonc/unwind.
At this point it would rely on the person embedding it in their app to get that data, put it somewhere, and then add a Cube definition on top of it - so this is purely solving the visualisation / report building part of that puzzle (but in a fully embedded / non iframe way).
I used Cube as inspiration, and actually the rest API for drizzle-cube is compatible with the cube-js schema definition. The main difference is that I chose to model the cubes in typescript, so they can be validated in the IDE easily (autocomplete, catch issues early) and not have an option for YAML, but the semantics are exactly the same.
I definitely meant Excel, we use office365 - easily as shareable as Google sheets these days. Agree anaplan and friends also have downsides, but for me the complexity you end up in as you change things through the year and need to explain the impact of the change becomes too complex in Excel. We manage a team of about 220 people, when I had a team half the size it was more manageable.
Excel, but it's painful - as any change's through the year make it very hard to compare and contrast actual to budget (e.g. a simple rate change from a supplier vs adding someone to a team, moving different rate people between teams) and quite challenging to do different scenarios (e.g. impact of different inflation levels for different roles / countries). It is possible but requires a lot of discipline and excel expertise from everyone to make it work. I am exploring using a planning & budgeting tool (anaplan, pbcs).
I am a very happy Bunq customer for 4+ years, and as a user of other Dutch banks (for a mortgage - ABN amro, in the past UK banks like FD), their overall service levels great - if I chat via the app I have always been helped quickly, flexibility with accounts, cards, automation via the APIs etc is absolutely worth the price hike. These are things I am happy to pay a few extra cups of coffee a month for as they make my life with an extended family much easier to manage day to day.
We ended up deciding that with the move to component based front end frameworks (react, storybook etc) that the overhead of this wasn't worth the benefits - every developer needs it running, along with lots of services etc.
I'd love to understand what others are thinking about composition on the front end these days. I guess the fact this just got created means that the problem we were trying to solve in 2014 still exists - so perhaps I have my answer?
Fair comment, they just seemed like good interactions to begin with as they are well understood. Given we can take this in any direction, what other dynamics do you think might be of interest?
I started building this because I have a requirement at my current company, and wanted to understand the problem space before I figured out if there was anything out there I could just use ... Then I got hooked and just kept writing code ;) I originally used the Twissandra project for inspiration (huge thanks). Ultimately looking for feedback on how useful this is to anyone else, and ideally other contributors who can help flesh it out and get some client libraries for various platforms built.
I've been playing with Prismic.io during this beta period and think it looks like an awesome product with great potential, but I just can't bring myself to actually use the writing side of it for any length of time.
Is there a way to turn off all the skeuomorphic design elements? Paper background? Lots of sliding panels, it's really hard to navigate around and very busy, even on a big screen. I think they need to completely cut it back and simplify, and I'd use it in a heartbeat.
The API based separation is a good idea for real sites (vs blogs), I think it will catch on and is a much better design than the all in one CMS design behind things like Wordpress, Drupal or Ghost.
A lot of the simplification was definitely down to flattening the structure that was represented in 20-30 tables down into a smaller set of documents in ES. But the functional approach to then rendering these documents simplified it further.
A functional map is definitely analogous to a visitor pattern, but don't underestimate how much of a productivity boost arrives by being able to see all of the code in a small set of terse statements in one place, vs having a set of fairly abstract classes with accept/visit scattered all over the place.
We just found that the OO solution resulted in more code and it was more difficult to hold the resulting model in your head as the number of things that could be visited grew - we run a very big site.
The other big enabler vs a traditional CMS approach is that we have a very clear separation between the part of our stack that allows editors to create content, and the part that renders it (connected via messaging) - so we aren't mixing r/w domains and our rendering pipeline isn't burdened with the additional complexity of having to understand how content changes, it just renders what it is given as fast as it can.
Hi, I'm the CTO at the MailOnline so can comment. The biggest reduction in loc was due to the move from a relational DB to elastic search containing flatter representations of our content. This basically meant that we could delete thousands of lines of boilerplate and create a very simple processing pipeline to render content, and for this clojure really shines of course.
The REPL made the first week of exploring the problem and solution space really effective, and even as a node guy I was impressed with what could be done.
I can say that there is definitely a big productivity boost, but as others have said it isn't purely the language, but rather thinking about the problem in a completely new way that really did it. I do credit clojure though with giving our engineers the ability to think differently, as that is often the hardest part.
There was a comment I made in a speech recently about functional programming being frictionless for content management system design, this is what I was alluding to.
I don't want to start a flame war, but we built an earlier version in ruby (with one of the best OO guys I know leading it), and it was much more complex through attempting to model our home page as a set of inter related objects, using visitor patterns to traverse etc., than the clojure version.