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.
I looked at superpowers, but it felt way too generic. Thanks for sharing unwind. More discussion/blogs about these kind of skills is what I am looking for. I would encourage you to write a blog on unwind, explaining in detail how it has helped you. Even better if you do it after 3 months of use, explaining the journey/evolution of the skill.
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).
Also the pain you mentioned is exponential with those tools compared to in Excel. You’ll never have perfect budget unless you have a crystal ball and can anticipate everything that will change. Just explain the variance and move on. Forecasting is meant to somewhat solve this issue. Budget become quickly stale, the forecast is budget altered by a few big issues (usually things unknown during the budget). Also usually helpful to replace budget with actual as they become available
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.
Good service levels will be a real USP, I expect. In the Netherlands where physical banks are a dying breed (especially those that deal with money. Aforementioned ABN Amro doesn't let you change a 100 Euro bill into 2 fifty bills, for instance). Especially the elderly are lost in the digital world and need guidance. For my parents for instance, every website is like a completely different app they need to learn how to use and with layouts changing all the time this is an enormous struggle to them.
I hate the fact that physical banks (and cash) are disappearing. I don't have complicated needs as to the digital services I consume, same as many other people. Then online banks become indistinguishable from the next, and it is ability to contact real people that sets them apart.
The cost-cutting wrt physical bank branches is just ridiculous. You can't even deposit or withdraw coinage at ABN AMRO branches anymore; they outsourced that to home improvement stores instead (yes, really).
Yes, I experienced that too. Acted surprised and look at me exasperated and what seemed with slight disgust when I came with actual cash to their office. "We don't deal with money, sir".
The situation with cash is overall very bad. Try to pay with a 100 Euro note in smaller cities. Almost no one will accept it, including banks. I regularly see very frustated tourists who with cash in hand are left out in the cold.
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?
It sounds like a much older Java thing called JSR 168 Portlets. I remember briefly working with those in 2012, but Wikipedia says the spec is from 2003.
:) see my comment -- yes, portlets are a source of inspiration for some things. As said, we need to share more to enable people to tell us if this makes sense...
Since you mentioned e-commerce: I find it much easier to do a less micro approach and go for medium. Create specific frontends for different domains: my account, cart, checkout, search...
Interesting that you compare Stacker to compoxure. Will need to look deeper into it, but I see a few things Stacker does in a very different way, plus it contains a lot of things compoxure seems to not touch (which, by all means, can be a good thing, please don't misunderstand me).
I only speak for us at betterdoc -- we created Stacker in order to be able to create tools that can be stacked together like containers (the real ones used for shipping things) to form various workplaces. It enables us to mix and match tools without changing code - just by configuration - and we discovered that this is not just a theoretical option, but happens regularly.
The basic idea predates 2014 by far - one of the first things I have worked on back in 2006 was a portlet server (anybody remembering this?), and now we solve many of the problems we tried to solve back then, again, with a different approach and spin.
All I can say is that working on Stacker in the last years was fun, and developing services that serve micro front ends for it gets more fun and efficient with every small step we take.
Cannot wait to share more about the ideas behind it :)
My activity is missing on my activity page, but the issue I just filed like an hour ago is there on my contributions page. I suspect that perhaps some of the feeds and lists have to repopulate, but nothing is really missing.
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?
This was more a rant against the idea of a "social network" than a critique of your work. I'm sorry, I don't know what to say about your library. I imagine it could be useful for people that like this specific idea of social network (which seems to be almost everyone), but I don't see where exactly.
I hoped also that the fact that there was a comment attracted more people to the discussion about your library (and also my rant), because it seems a nice piece of software.
