Do you have the capability to enable automated testing of the system built with the app builder? In my experience continued success with an app builder quickly becomes dependent on some testing capability to avoid breaking things over time. This is similar to unit/integration/system tests a "regular" developer would do, but trickier since it means making that available to users at a lower technical skill level. I'm interested to hear what solution you have for this, or even just thoughts on how you might address it in the future.
The majority of our customers are not developers so the ability for them to write and run their own automated tests actually hasn't come up as a feature request before to be honest!
Like other platforms, you can of course build and test out functionality and even see what it looks like to users with different user roles before publishing to your user base.
We have workflows functionality (where you can trigger emails and webhooks when data is updated in your app or when action buttons are clicked) and that would probably strike me as one of the first areas where tests could be focused as these things happen more in the background.
That's not something we currently offer, but it's certainly something I've thought about a lot.
One of the benefits of no-code tools like Noloco is that you define, very explicitly, what your app should do, display and how it behaves under certain conditions. This really does allow for completely automated integration tests. such as verifying that a filter in the UI does filter the data, verify that when User X logs in, that the permissions for that user are respected, verify that when a record meets certain conditions, a tab isn't accessible.
Defining the rules for the app could (and will) allow you to programmatically verify that it's still working as expected.
However, I think another large appeal for no-code/low-code solutions is not having to worry about testing. You can assume that because you're building your application within the rules of the platform, that everything will function as you tell it to.
I am not sure I follow your logic on why a low code tool should generate apps that don't need to worry about being tested. Even regular software _should_ function the way we tell it to but the point of testing is that sometimes this changes to no longer be true _unintentially_. If I generate a low code program with your tool that should have some desired behavior, but then someone makes changes it for it to do new things, how can I be sure the old things still work and a regression has not occurred? I think there is a need to package tests along with the app, even though its being generated somewhat at a high level.
I see what you mean, I guess the best and only way to do that would be to write integration like tests with something like Cypress, as you could with any web-app.
If you want to verify that it works how you want vs how it's setup to work, then you would be better leaning on existing tools that can do that.
My point about not needing to test it was about the implicit trust you would put in a platform like this, just like you would trust that a library you import behaves how it describes. It's not expected that you should write unit tests and integration tests to verify the behaviour of an external library
I wouldn't write unit tests for an external library but any integration test will implicitly test any external libraries that are in the code path. That's one of the points of integration tests - catching cases where the underlying code still works as it's supposed to but the way it's supposed to work has changed. Whether it's an external library or code you wrote, your goal is to test that all the pieces still fit together like they're supposed to.
In the case of something like Noloco, I imagine it would be more like "we need to change this DB schema, can we update the schema in a test environment and make sure that we didn't break our Noloco app?" There's nothing to unit test there but if you don't have a solid set of integration and e2e tests then you might have a form that's halfway through a flow that suddenly stops working and you don't notice until your conversions crater to zero.
The recent Rails 7 updates are pretty fun, although you could argue that's all boring, which is kind of the point. If it's a matter of getting something accomplished quickly, with the outcome being the fun part, I like Rails for it. For just satisfying cool stuff I like a good pile of BASH and awk. I find it rewarding to pipe a bunch of stuff together and get things done that might feel like it has no business being done like that. The fun of it in this case comes from quickly automating things. To the OPs point of a job change, this feels outside of the initial considerations, but hey it's fun stuff and maybe you'd like it! At a minimum there's a ton of value in software developers understanding the environment their code runs on and there's often space for "devops" activities to do a healthy mix of work on software dev and operations kind of stuff.
Medic | App Developer Manager, Senior Researcher | Full-time | Global/Remote | https://medic.org/
We're a non-profit organization working to provide tooling for community health projects.
We're hiring for a couple roles right now:
- App Developer Manager: Manage a team of software developers (who are mostly in Africa and Nepal) building applications for community health workers in areas we serve. https://medic.pinpointhq.com/en/jobs/6322
- Senior Researcher, Data Science: Oversee an ambitious R&D roadmap focused on breakthrough opportunities in data science and precision public health. https://medic.pinpointhq.com/en/jobs/11876
We're a non-profit organization working to provide tooling for community health projects. Our team focuses on development of the Community Health Toolkit, which is a suite of open source components, but primarily an offline-first web application.
Here’s a quick list of some of the interesting aspects of our work:
- An offline-first mobile-first webapp. A lot of healthcare workers we serve may go multiple weeks without a network connection.
- Our software needs to be usable on underpowered hardware, which is common for those using it. Client-side performance improvements can make a big impact.
- We provide a platform that locally-customizable apps are built with. Backwards compatibility is critical as is careful thought for new capabilities.
As for the technical parts, almost all development is done in JavaScript and TypeScript. We’re using Angular 10 on the client and node on the server with Pouch/CouchDB for data storage and syncing.
We're a non-profit organization working to provide tooling for community health projects. Our team focuses on development of the Community Health Toolkit, which is a suite of open source components, but primarily an offline-first web application.
Here’s a quick list of some of the interesting aspects of our work:
- An offline-first mobile-first webapp. A lot of healthcare workers we serve may go multiple weeks without a network connection.
- Our software needs to be usable on underpowered hardware, which is common for those using it. Client-side performance improvements can make a big impact.
- We provide a platform that locally-customizable apps are built with. Backwards compatibility is critical as is careful thought for new capabilities.
As for the technical parts, almost all development is done in JavaScript and TypeScript. We’re using Angular 10 on the client and node on the server with Pouch/CouchDB for data storage and syncing.
I agree. I have switched and used to feel like the switch was failing when I had to use Google for some things, but realized that's just fine. I also occasionally use Wolfram Alpha for things too. Both there if needed, but otherwise getting great results from a company that respects me.
After trying a few different options I have ended up on the (seemingly very uncool) Pimsleur program (available for cash lump sum or monthly. I am paying monthly). For me, one of the biggest challenges in French is how a lot of words get blended together and are spoken very fast. It's easy to hear what seem like new words, but they're actually things I know, but spoken as native speakers do. This listening concept is extremely important for me with French in particular. To contrast, I speak Swahili too and learned it differently, where I wouldn't say there's as much of a demand for emphasis on listening to native speakers.
Some other alternatives I tried first include:
Chatterbug: Nice combination of tools/methods, but expensive and I'd need to pay a much higher price to get the kind of listening I need. A side note on these guys that's relevant for this site: they do a lot of ruby/rails stuff and have a nice graphql gem called cacheql.
French Uncovered: Interesting idea and fun method of learning, but the "book" material wasn't as long as I'd have liked and I would have liked to do a lot more listening. The self-study written materials are decent, but felt slow and like a forced way of trying to cram information into my head, where I personally do better getting that stuff naturally.
Language Transfer: Great free option, but doesn't have native French speakers and the French course doesn't good too far.
I've also done the apps like Duolingo, but the listening and speaking isn't what they do best. I basically get great at Duolingo, but not at being able to use the language.
