Posts with keyword: rules


Rule-Based Programming and the Internet of Things

Rule-based, actor model systems are a great match for IoT workloads.
Continue reading {Rule-Based Programming and the Internet of Things}


Announcing Pico Engine 1.0

I'm excited to announce a new, stable, production-ready pico engine. The latest release of the Pico Engine (1.X) provides a more modular design that better supports future enhancements and allows picos to be less dependent on a specific engine for operation.
Continue reading {Announcing Pico Engine 1.0}


Kynetx Platform Update

We've had some changes in the Kynetx platform, KNS, over the last few weeks that I wanted to update people on. First, a few weeks ago, we cut over to a new parser. Yeah, if you're keeping score, this is number 3. The first parser was based on HOP. We replaced that with Damian Conway's Parse::RecDescent as chronicled in a blog post I did in September of 2008. The third (last?) parser is based on the ANTLR parser generator. Cid Dennis did most of the hard work of creating the new Parser and Mark Horstmeier did the Perl integration
Continue reading {Kynetx Platform Update }


Build 354: Control Statements in Postludes

This afternoon we releases Build 354 of KNS supporting the addition of a last control statement to postludes. In addition, we also now allow guard conditionals on any statement in a postlude. These are relatively minor additions to KRL in anticipation of some larger features that are coming soon. The use a last statement in a postlude will halt the execution of the ruleset at that rule if it is executed. So, the following statement would halt execution after the current rule if the rule fired: fired { last } This can be useful for rules that initiate action
Continue reading {Build 354: Control Statements in Postludes}


Modularity Rules

A number of my colleagues don't believe you can teach design, or at least that teaching design is hard to do. I not only disagree, but feel that if we're to help students prepare to be influential, we have to teach design. Good programmers are also good designers, many are good architects. But for the most part, they've picked that up as an implicit part of their education. Explicitly people taught them the nuts and bolts of programming. Consequently, I'm always on the hunt for books that I think future CTOs and CIOs ought to read. I found a
Continue reading {Modularity Rules}


Google's Golden Rules for Effective Technical Teams

Hey! It's Google Day at Technometria. Not really, but this was still interesting. Google's Eric Schmidt and UC Berkeley's Hal Varian list ten "golden rules" that Google tries to follow: Hire by committee. Cater to their every need. Pack them in. Make coordination easy. Eat your own dog food. Encourage creativity. Strive to reach consensus. Don't be evil. Data drive decisions. Communicate effectively. The goal is to be a good place for knowledge workers. They start by talking about Drucker: At google, we think business guru Peter Drucker well understood how to manage the new breed of "knowledge workers."
Continue reading {Google's Golden Rules for Effective Technical Teams}


Learning from the Web

I've heard Adam Bosworth talk about the lessons we should have learned from the web about semi structured data, but it didn't really hit home for me until I read his arguments in this article in Queue. I read it in hardcopy 6 weeks ago or so and it's finally online so I can link to it. He lists five "unintuitive" lessons: Simple, relaxed, sloppily extensible text formats and protocols often work better than complex and efficient binary ones. It is worth making things simple enough that one can harness Moore's law in parallel. This means that a system
Continue reading {Learning from the Web}