We did a re-write of the nearby.lk data model library, and we decided to open source the core of it. It supports JSON or YAML data files, and parses them based on a specification (like a schema).
In Wallaptta we model pagination as a cost minimization problem. That is, we try to find where to place page breaks so that there is no overflow and the cost is minimised. If the cost of adding a page break at a given point is know this can be easily solved with dynamic programming.
We want to share some node.js performance tips we found while working on Forestpin; specifically how to optimize runInContext, setting heap limits, memory usage with string slices, and joining strings.
I added full width blocks, and scripting to Wallapatta. Full width blocks are useful when adding large images, and we use embedded scripts to create diagrams.
We found that chrome (and therefor node.js) continues to keep the parent string in memory even if you discard it after taking a slice of it.
This is probably a optimization to make slicing efficient, and to reduce memory footprint - assuming you are keeping a reference to parent anyway.
I came across jsblock yesterday on Hacker News. They had a nice performance comparison test case set comparing jsblocks with Angular and React. It made me curious to see how the small library we use (Weya.coffee) compares in performance with these.
This is a new project I'm working on. It helps parse data with different structures, like reports from legacy systems.
I just started moving my blog from Svbtle to a static blog generator that I created. It is based on Wallapatta.
This is a tutorial on using shared memory among node.js processes.
It took Forestpin almost 2 years to get its first big customer. Making the first sale is always hard. It was a tough ride; talking to a lot of potential customers, changing product strategy from time to time, taking up classes on pitching and of course a lot of programming. We learned a lot during the process.