We’re a profitable non-VC funded company, selling research information management software to universities. We’re a values lead company, and think it’s just as important to do the right thing as to get the job done. We’re open sourcing much of what we do, and have built a workplace designed for us to learn together and do our best work.
For something like an internal linkedin, configure the semantic web inspired object store to describe the entities involved, then add a bit of scripting to add any business specific policy or features.
One of my aims in building it was to bring down the cost of custom applications for internal business use by a couple of orders of magnitude. I think we’ve got a long way towards this goal.
For something like an internal linkedin, configure the semantic web inspired object store to describe the entities involved, then add a bit of scripting to add any business specific policy or features.
I think you end up doing something just as complicated as coding. And I think the claim that a simple rails app takes a week to get going is an order of magnitude out.
I agree. These “rapid development” tools can be more pain than they’re worth.
What we’ve done is:
Focus on one specific area, “information applications”, which collect together things representing the real world.
Provide a full admin UI for the schema, which describes what you want to collect.
Provide a full user UI for that information system, including editing, search, discovery, etc.
Do all the basics things you need, like user accounts, permissions, notifications, workflow systems, etc.
Easy hand-off from information configuration to developers.
API designed to script these features, rather than a generic application framework.
Don’t try and do point and clicky tools, make it easy to script a toolbox of components.
Within our sweet spot, we have built applications in less than one day which were genuinely useful and the organisation kept on using past the honeymoon phase.
If you step outside the sweet spot, of course it’s not so great, but it’s quite a big sweet spot. Every organisation has a load of “stuff” they need to keep track of and share, and have some lightweight workflows to help them work together.
Yes. The HTML elements are considered part of the language itself, so are validated as part of the parsing step. Nothing in the language is blindly copied to the output, except for literal strings. (and I have just added “check literal strings for the user sneaking in HTML” to my TODO list)
The aim is to be very strict on everything that affects security, and fairly relaxed on everything else. So, your HTML elements have to be well formed, but whether you have matching close elements is your business. Although I’ll probably catch that in an optional linter.
I’m probably also going prevent inline JavaScript in the templates, both by preventing onX attributes and
I look forward to seeing what you think when you get a moment. Thanks!
We are, in London: https://haplo.com/jobs
Especially if you’ve just graduated: https://haplo.com/jobs/new-graduates
We’re a profitable non-VC funded company, selling research information management software to universities. We’re a values lead company, and think it’s just as important to do the right thing as to get the job done. We’re open sourcing much of what we do, and have built a workplace designed for us to learn together and do our best work.
Our open source product makes these kind of internal apps very quick to develop:
http://haplo.org/
For something like an internal linkedin, configure the semantic web inspired object store to describe the entities involved, then add a bit of scripting to add any business specific policy or features.
One of my aims in building it was to bring down the cost of custom applications for internal business use by a couple of orders of magnitude. I think we’ve got a long way towards this goal.
I think you end up doing something just as complicated as coding. And I think the claim that a simple rails app takes a week to get going is an order of magnitude out.
I agree. These “rapid development” tools can be more pain than they’re worth.
What we’ve done is:
Focus on one specific area, “information applications”, which collect together things representing the real world.
Provide a full admin UI for the schema, which describes what you want to collect.
Provide a full user UI for that information system, including editing, search, discovery, etc.
Do all the basics things you need, like user accounts, permissions, notifications, workflow systems, etc.
Easy hand-off from information configuration to developers.
API designed to script these features, rather than a generic application framework.
Don’t try and do point and clicky tools, make it easy to script a toolbox of components.
Within our sweet spot, we have built applications in less than one day which were genuinely useful and the organisation kept on using past the honeymoon phase.
If you step outside the sweet spot, of course it’s not so great, but it’s quite a big sweet spot. Every organisation has a load of “stuff” they need to keep track of and share, and have some lightweight workflows to help them work together.
Here’s a pretty fully featured repository application: https://github.com/haplo-org/haplo-research-manager
Haven’t cloned / run it yet because my PC is busy on other tasks, but I have a question: does this parse and validate the HTML as well as your DSL?
Because otherwise your statements about not being able to generate invalid HTML are false.
Yes. The HTML elements are considered part of the language itself, so are validated as part of the parsing step. Nothing in the language is blindly copied to the output, except for literal strings. (and I have just added “check literal strings for the user sneaking in HTML” to my TODO list)
The aim is to be very strict on everything that affects security, and fairly relaxed on everything else. So, your HTML elements have to be well formed, but whether you have matching close elements is your business. Although I’ll probably catch that in an optional linter.
I’m probably also going prevent inline JavaScript in the templates, both by preventing onX attributes and
I look forward to seeing what you think when you get a moment. Thanks!