Archiving OnRails.org

Since I started blogging on my corporate blog I neglected this blog. It is a little ironic as I’m doing more Rails work than ever and I have a few blog posts comming up. I contacted Lee Marlow and Solomon White, my long time cohosts of this blog and authors of some of the most famous blog entries of this blog, and we decided to put it in archival mode. We won’t add new entries but thought that as there was some good and now historical material we could just keep around.

Enjoy!

– Daniel.

Archiving OnRails.org

Since I started blogging on my corporate blog I neglected this blog. It is a little ironic as I’m doing more Rails work than ever and I have a few blog posts comming up. I contacted Lee Marlow and Solomon White, my long time cohosts of this blog and authors of some of the most famous blog entries of this blog, and we decided to put it in archival mode. We won’t add new entries but thought that as there was some good and now historical material we could just keep around.

Enjoy!

  • Daniel.

I’m leaving Flex and it’s not because of HTML5.

Note I cross posted this entry on my new blog.

Flex has been really good to me for many years. In fact I moved to the US in 2002 and started working on a Flash project and we jumped on Flex before it was 1.0 with Royal which was the beta code name of Flex. Flex had a long road since and I delivered many fun and successful customer projects. Many of which were internal enterprise projects and I also worked on a few pretty visible public ones like the Australian Open Tennis Vault, the NCAA Vault. I even co-authored a Flex on Rails" book.

You would think I would leave Flex based on the flux it is in right now after the catastrophic public relation announcement from Adobe in November. That’s not it, as I actually believe Flex has a bright future and is in great hands with the Apache Flex Team. My realization happened a couple of weeks ago with the announcement of Rubymotion. The cheer fact of being able to build iOS apps with the iOS SDK in Ruby was that moment for me and it opened my eyes and pointed to a turning point in my career. I’m going mobile full steam ahead. This is the future. Note just RubyMotion, just the mobile sector in general. And many mobile apps need to be backed by great server side services. So mobile and the cloud are really an exciting combination.

So what do I mean by “I leave Flex”. Actually it already started, I’m not taking on new Flex Desktop Project, I cancelled of few customer Flex projects that where on my radar and I’m canceling several internal project I was working on. In addition I will not attend Flex user groups or conferences and I’m not giving Flex speaking engagements or trainings. That’s it, done!

So what about my current engagements with Flex? I currently have two great customer for which I provide product development, mentoring and consulting services and I would like to continue working with them for the foreseeable future. In fact these two customers have many Ruby on Rails projects and will start doing more mobile development. So it seems to be a good match.

And what about Flex mobile which is pretty awesome and is a great way to build iOS and Android apps for the enterprise? You may not know this, but I have been an Objective-C developer in the mid-90 on NeXTStep and followed the WWDC conference since many years before the iOS SDK was announced. Again I love Ruby and the iOS SDK, I just wasn’t very fond of Objective-C anymore as Ruby spoiled me. RubyMotion is my gateway drug to iOS and I’m just ready to dive fully into iOS. Mentally I don’t want to master two different environments and the iOS ecosystem is large enough to sustain me professionally.

Now will I still recommend Flex to anyone? The answer is clearly yes as there are still many situations and projects where Flex is a great match. At least until a good HTML5/JavaScript framework can provide the same productivity than with the Flex SDK. All the current HTML frameworks will evolve and morph drastically over the coming years. Which is a good reason to choose Flex if you want stability. These HTML frameworks will take several years to mature. This said I really enjoy Backbonejs, Spinejs, Ember-js and how they try to make development of Rich HTML Applications easier.

So, here we go. Good bye Flex!

– Daniel Wanja

I’m leaving Flex and it’s not because of HTML5.

Note I cross posted this entry on my new blog.

Flex has been really good to me for many years. In fact I moved to the US in 2002 and started working on a Flash project and we jumped on Flex before it was 1.0 with Royal which was the beta code name of Flex. Flex had a long road since and I delivered many fun and successful customer projects. Many of which were internal enterprise projects and I also worked on a few pretty visible public ones like the Australian Open Tennis Vault, the NCAA Vault. I even co-authored a Flex on Rails" book.

You would think I would leave Flex based on the flux it is in right now after the catastrophic public relation announcement from Adobe in November. That’s not it, as I actually believe Flex has a bright future and is in great hands Continue reading “I’m leaving Flex and it’s not because of HTML5.”

UndoManager for ActionScript

UndoManager is A simple ActionScript library to add undo/redo functionality to your Flex/ActionScript projects. I just extracted this library from one of the project I’m working on.

Read more on my new blog

Enjoy!
Daniel

UndoManager for ActionScript

UndoManager is A simple ActionScript library to add undo/redo functionality to your Flex/ActionScript projects. I just extracted this library from one of the project I’m working on.

Read more on my new blog

Enjoy!
Daniel

UndoManager for ActionScript

UndoManager is A simple ActionScript library to add undo/redo functionality to your Flex/ActionScript projects. I just extracted this library from one of the project I’m working on.

Read more on my new blog

Enjoy!
Daniel

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
    end

So 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!

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

  1. no rules matched, default to zero
    0
    end

So 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

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 Continue reading “Adobe’s Announcement on Flash: visually!”

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

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

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 Continue reading “The Future of Flex.”

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.

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.

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

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 Continue reading “Writing tests is not fun. Anyone who tells you otherwise is a liar….”

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 screenshot

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!