Dentaku - a calculator for Ruby
I’m currently working on a project that requires the use of formulas or expressions to implement business rules (the original system is an Excel workbook), and I needed a way to implement some of the same functionality. My first thought was to model the formulas in ActiveRecord, clause by clause, using something like `acts_as_nested_set` to handle hierarchies and grouping. However, I’ve done something similar before, and was never quite satisfied with the result — it always felt “heavy” — so I decided to try a different approach this time.
The result is Dentaku, a gem that parses and evaluates Excel-like formulas, allowing the use of named variables that will be substituted for real values at run time. So far, the result values will be either boolean or numeric, but strings will probably be added soon.
To illustrate how it works, let me set up the following (quite contrived) hypothetical situation: You’re building an upvote system for a Reddit-type site, but the customers do not want to encode all the logic for the system in Ruby — they need to be able to manage all the rules on the fly. However, they are willing to be limited to only using a few predefined attributes of the user as all variable inputs to the rules.
The initial ruleset is something like this: A vote from a “normal” user is worth one point for each week the user has been with the site. A vote from an “admin” user is worth 100 points. A vote from a “limited” user is worth one point, and a vote from a “blacklisted” user is worth zero points. However, users can earn achievements, which update a “bonus” number for the user, and any normal or limited user’s vote points are augmented with the bonus, but only after the user has been with the site for at least five weeks. (Hey, I promised contrived, right?) So how could we accomplish this with Dentaku?
We could create the following rules:
+-------------------------------+----------------------+
| conditions | points |
+-------------------------------+----------------------+
| admin | 100 |
| normal and age_in_weeks < 5 | age_in_weeks |
| limited and age_in_weeks < 5 | 1 |
| normal and age_in_weeks >= 5 | age_in_weeks + bonus |
| limited and age_in_weeks >= 5 | 1 + bonus |
| blacklisted | 0 |
+-------------------------------+----------------------+
Then, given a hash representing the user like:
user = {
:admin => false,
:normal => true,
:limited => false,
:blacklisted => false,
:age_in_weeks => 10,
:bonus => 8
}we could calculate the points for a vote by the represented user like so:
def calculate_points_for(user, rules)
calculator = Dentaku::Calculator.new
rules.each do |rule|
if calculator.evaluate(rule.conditions, user)
return calculator.evaluate(rule.points, user)
end
end
# no rules matched, default to zero
0
endSo that’s what Dentaku is about — I hope someone else finds it useful. You can check it out, fork it, etc at the Dentaku Github page, or just `gem install dentaku` and start playing!
Adobe's Announcement on Flash: visually!
I’ve received so much feedback from many of my friends on Flex projects being cancelled or scheduled to be rewritten in another technology than Flex. Great Job Adobe, you did it!
So what was really announced last week is the following:

Yes, Adobe will stop development on the Flash Player in the Browser.
Flash Player on the mobile will continue.
Adobe AIR will continue, on the desktop and mobile.
Captive runtime of AIR allows to create “native” apps on mobile and tablets (Android, iOS and more) and desktop WIndows and OSX apps that don’t need AIR to be distributed. Yep, that continues too.
Of course Adobe tried to clarify their statements after the fact saying the transition to HTML5 will take 3 to 5 years. The following is from Adobe’s website from Andrew Shorten & Deepa Subramaniam, see: http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html
You said that you believe HTML is the “long-term solution for enterprise applications” – can you clarify this statement?
HTML5 related technologies (comprising HTML, JavaScript and CSS) are becoming increasingly capable, such that we have every reason to believe that advances in expressiveness (e.g. Canvas), performance (e.g. VM and GPU acceleration in many browsers) and application-related capabilities (e.g. offline storage, web workers) will continue at a rapid pace. In time (and depending upon your application, it could be 3-5 years from now), we believe HTML5 could support the majority of use cases where Flex is used today.
However, Flex has now, and for many years will continue to have, advantages over HTML5 for enterprise application development – in particular:
- Flex offers complete feature-level consistency across multiple platforms
- The Flex component set and programming model makes it extremely productive when building complex application user interfaces
- ActionScript is a mature language, suitable for large application development
- Supporting tools (both Adobe’s and third-party) offer a productive environment with respect to code editing, debugging and profiling
I guess Adobe’s communication just accelerated that 3 to 5 year timeframe by quite a bit.
Enjoy!
Daniel
The Future of Flex.
At first I thought “Wow, Adobe really messed up their communication”. They could have focused on what they are adding, strong support for HTML5 and CSS4, Adobe AIR for Mobile, and not on what they are removing, the Flash Player in the Browser. But then they also announced that they opened sourced Flex via the Apache Foundation. And the main stream media, the blogosphere, and many developers I know went crazy and said Flex is dead, it’s over, time to convert all your projects to HTML5.
At a second thought I think it’s pretty smart what Adobe did. The saying goes “If you can’t beat them, join them”. In fact the Flex against HTML fight wasn’t one where Adobe had anything to win from. So they just made it loud and clear and now they are saying “We are HTML5”. In fact detaching themselves from Flex in appearance allows them to ride the new HTML5 technowave and get in the news when they upgrade their tool, bring out new HTML5 component framework or acquire hot companies like PhoneGap and TypeKit. We are HTML5!!
Adobe has already two great tools for HTML5, Muse and Edge and needs to push them way further and also needs to create or acquire a great HTML component framework such as Sencha so they call build and sell new development tools as well as design tools for the new growing crowd of HTML5 developers.
So where does that leave Flash and Flex. I use a lot Flex in the enterprise, and that’s where Adobe just did the most damage in my eyes. Go now try to convince any CTO that Flex is a good idea. Flex is a mature framework and Adobe has a great enterprise offering, but it will be hard to convince anyone that Adobe is still behind that technology after the way they managed their communication. This said I think the move of Flex to the Apache open source foundation is a great one and if managed right will give Flex a good run for years to come. Flex is still a great choice for many enterprise projects and will remain so until a solid and widely adopted HTML component framework emerges. If Adobe is smart they could provide that offering.
Flex is also a great environment to develop “native” mobile applications that can run on iOS and Android. The forthcoming Flex SDK 4.6 will show that potential and it’s a great way to create cross platform mobile and tablet applications. Adobe will not kill Adobe AIR for the mobile as it’s a too appealing growth market. But that message didn’t get through to the main stream media.
As Adobe said Flash for the desktop for games and Adobe AIR for mobile will be here for a while. But Adobe has the most to gain if they become the major player in the HTML5 field by providing tools, framework and making the web standards evolve. And they are in a good position to get there. To achieve this goal it also means that they will refocus many of their development teams and this will impact Flash and Flex. Moving the Flex SDK and some of the key developers to the Apache Foundation will allow to continue to evolve the SDK regardless of Adobe’s new focus. The move a few years ago to the Flex Sparks components and the recent addition of the new mobile components provide a great and mature framework basis for a real open source effort which I believe will have a long life even if it will become a niche environment over the long run. Note I consider Ruby on Rails a niche market, a really great one to be in. Adobe has something great with Adobe AIR for mobile and this is the one area where they could even grow their developers basis if they get their message right. For me AIR for mobile/tablets and the Flex SDK 4.6 is one solution where I can build mobile apps faster than in any other environment and this will be a great business to be in, especially for the enterprise market.
The smart enterprises will realize that Flex is stable and here to stay for the long run, even if it’s not in the spotlight. They will start HTML projects in parallel to gradually improve their developer workforce and experience in this area. They will also realize that the HTML5 frameworks and coding technics are evolving so rapidly that it will be time consuming just to keep up. Also these frameworks are not as mature and complete as in the Flex ecosystem. Finding Flex developers is difficult, but finding great HTML/Javascript developers is even harder. This said, there is no denying that pretty quickly the HTML5 tools and frameworks will catchup with what Flex offers today in ease of development for enterprise applications.
Personally I’m looking forward to see how these HTML5/Javascript tools/libraries will evolve and will play with many of them.
So where does all this leaves you, the developer. Well, it’s for sure time to jump on the new HTML/Javascript bandwagon if you haven’t yet. I cannot see many companies starting new enterprise projects with Flex. If you are into mobile or tablet development give the new Flex SDK 4.6 a try, I believe there is a great potential for Flex to become a major player in the mobile development arena…targeting “native” applications and not the browser. Yep, your heard it here first ;-)
Enjoy,
Daniel
Flex With Ruby on Rails talk - An AdobeMax preview
This is a presentation I gave in September 2011 at the Denver RIA Developers Group showing how to create a Flex application that interacts with a Ruby on Rails server. In fact it was schedule for the Flash Builder track of Adobe Max but was bumped to the the 360Flex Unconference as it was deemed too specialized for the general track. In this presentation I will show you how to interact with Rails using REST, nested resources, nested attributes and the newest kid on the block, the bulk-api allowing to transfer complex data structures between your rich client application and your Rails server. You will get a good overview on how Rails works and how to quickly build a Flex application on top of Ruby on Rails.
Writing tests is not fun. Anyone who tells you otherwise is a liar....
At least so says my good friend Sean Voisen in his latest blog entry Thoughts on test-driven development.
What, you are calling me a liar? :-) I must respectfully disagree with Sean. Not on the fact that he may think it’s not fun, that’s his opinion like many other Flex developers that don’t do testing. I disagree because I see many developers, in other communities, that actually really enjoy testing. If you look at the Ruby community you will see many developpers enjoying doing test driven development, enjoying writing tests, and even expanding the way you can write tests. Check out rspec, Cucumber, and the many of books and screencast on the subject. Checkout all the ruby libraries, they are all pretty well tested. There are many training classes on people that really want to improve doing testing. Many Rails projects are extremly well tested. Many Ruby developers cannot even code without writing tests first.
This said as they are many examples on how to test Ruby and Rails code it’s easier to get going on with testing in that environment. On the other hand, there are not many example of tested Flex applications and libraries. Not many toturoials on how to test your Flex application.
I happend to do a lot of unit testing for my Flex apps, but I do not test everything, I use tests for more difficult aspects, when I’m not sure how to design something, when it’s slow to access a part of the application just to verify that my new code works. Then I write tests and it’s fun. How many times do you manually repeat a sequence on the UI like start the application, perform a search, click on the grid, open a record, click the calculate button…Oh no, that not right…go change some code and do it again. Well that’s not fun. Every developer I know does that thousands a time a day. Well, write a test and your workflow becomes more fun.
So why are Flex developers not testing? As I mentioned above, there is not much peer pressure to do so as not many Flex developers do testing. Also they are not many examples. In addition it’s not obvious how to test applications in many case. Often they are not written in a testable manner. Flex/ActionScript is asynchronous and event driven, that’s harder too.
They are solutions for that and Flex applications are very well suited to testing…but the sweet spot must be found. And you should start by testing the simple things that have lots of added value. Anywhere you have logic in your code that does filtering, calculation, transform data, write a test…You gonna like it. FlexUnit 4 as great support for asynchronous or event driven programming, but I agree, at first it’s not obvious how to best us that support. So again, start with the simple thing, refactor your code so that you can test it in a non-asynchronous way, that will already be helpfull.
So I came to the conclusion that I won’t be able to convince Flex developers that testing is needed and even fun. I can only hope that as a Flex developer you will start using FlexUnit 4 and try to add tests to your application and persevere and find the sweet spot on where testing is fun and makes you more productive. If you persevere you will like many Ruby developers become a better developer, write better code and faster.
I finally like Sean’s balanced view on test driven development: “But would I use TDD for every project I work on? Probably not. For personal “one-off” projects or projects I know will not see much future maintenance, the slower development time is simply not worth it. For serious, long-term projects however, TDD is now a must.”
Testing remains hard, but it’s just essential if you want to become a great, agile, developer.
Persevere and testing will become your friend!
Enjoy!
Daniel
Termistat : a status bar for your terminal
When running background processes that produce detail logging, it’s often difficult to strike the right balance between providing overall status information and details about the current step in the process. It’s helpful to be able to see “tail-like” information at the detail level to monitor and debug your processes; however, it’s also helpful to be able to know summary information, such as the overall progress through the entire task. You can intersperse “record 1 of n” lines in your output, but they are easy to miss in all the noise.
In order to be able to display both types of information concurrently, I built a simple gem called termistat, which allows you to display a status bar for summary information at the top of your terminal in addition to the original detailed output. It was meant to be a whyday contribution, but I didn’t quite finish it in time to be released on whyday…oh well.
Here’s a screenshot of termistat in action:

Termistat requires the ffi-ncurses gem (which requires the ncurses library to be on your system), and has a configuration DSL to customize the appearance somewhat. Check it out and let me know if you have any ideas for improvement!
Redis-Flex: An ActionScript Library to integrate with Redis
Announcing redis flex An ActionScript Library to integrate with Redis.
A while back I looked into accessing Redis directly from Flex and I found an existing library, as3redis that however didn’t support the new unified request protocol. So I wrote a minimalist wrapper that now allows to send commands to a redis server.
To access the Redis server from Flex just instantiate a Redis instance:
<redis:Redis id="server"
connected="server_connectedHandler(event)"
result="server_resultHandler(event)" />Then you can send commands:
server.send("SET A 123");
server.send("GET A");
server.send(["rpush", "messages", "message one"]);Note it’s not a good idea to connect a Flex application directly to Redis. Redis is usually used in the context of an application server that protects it’s access in the same way that Flex doesn’t connect directly to a database. However they may be cases that this could be useful.
Enjoy!
Daniel
To Infinity and... no beyond - An ActionScript bug...I mean, feature.
So yesterday I was asked about a bug in a legacy Rails and Flex application. There was one company name that wasn’t displayed correctly on the front-end. “Infinity Corp Name” was just displayed as “Infinity”, so nothing beyond infinity. First I thought it was a joke, but not, a real bug that could cause issues.
So I looked at the code and the service call was a plain HttpService call with the resultFormat set to object. The server returns XML but the Flash Player converts the XML to a tree of objects. This is where it get’s funny. In fact when the player converts your hash to Objects it checks if a value is a number or a string…Hey guess what “Infinity followed by something” is a number.
Here are some conversion examples:
| String | Is Number | Converted Number |
| “123” | true | 123 |
| “123 Abc” | false | NaN |
| “Infinity” | true | Infinity |
| “Infinity Abc” | true | Infinity |
It’s the last conversion which is the root of the problem as “Infinity Abc” is a number that when casted translates to Infinity!
So we found the problem but the solution is really don’t use the Flash Player to do the conversion for you using the return type “object”. Use “e4x” which would turn your object in XML or use JSON and do the conversion yourself.
To Infinity… and beyond!
Daniel
Building Rails Apps for Rich Client - Using the bulk_api from Flex.
In this screencast we are going to show how to build a Rails app in a couple of minutes that is optimized for Rich Client. The application is a todo application build in Flex connecting using the bulk_api to the Rails server using my new bulk data source Flex framework.
Enjoy!
Daniel
Sitting is killing you
I started working standing, what seems now ages ago, after a chat with Tony Hilerson when I thought…why not try it. I spend most days of the week working at a customer site and they where not just eager when I asked if I could work standing, they just went ahead and changed my work desk to a standing desk. The first few hours I felt weird…standing and coding. But after a day it felt pretty fun. During the first few weeks it was hard to go through the day without wanting to sit down, but after that period I was just feeling great after height hours of work. I felt not only that I coded hard but also that I physically did something. Another benefit it that it’s really easy when someone comes by my desk to talk that I don’t have to get up, I’m just standing there and ready to welcome them to my desk. It’s funny when you do peer programing, as after one hour anyone that is not used to work standing complains, and the we switch station. Another issue is when you work with someone of different height, I’m 6.2", then they have to look up or can even not reach the keyboard. My friend Sean tweeted about the following review on working while sitting…and I thought I share. Although I don’t know the source of that information, I can tell you that working standing is pretty fun.
