Seven Databases in Seven Weeks now in Beta

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement now in Beta

Do you ponder what to name things in your code?

This guest post is by Evan Light a test-obsessed developer, the author of several rarely used gems, and the curator of Ruby DCamp. When he’s not a talking head at conferences, he’s usually working at home as a freelance developer remotely mentoring a developer, working for one or more startups, playing with open source, keeping his wife and four cats company, hacking nonsensically, talking at people on the internet, and/or attempting to lose weight (or any combination of the above). What else do you do when you live 3 hours from civilization?

Why should I care?

Evan Light “The hell with clean code!1, you say. “I’ve got stuff to get done!” You beat on keys for a while. Characters appear. The characters don’t make a lot of sense but, hey, the compiler compiles it or the virtual machine interprets it. Things happen. Eventually, an application emerges.

Success? Hell no!

Most of the time, someone has to maintain that pile of crap you just birthed! It may be someone else. It may be you! But it’s always wise to pretend that the person who will own your code next is an axe-wielding lunatic who knows where you live.

The worst sin that I’ve seen people make in their code: choosing poor names… for their classes, methods, literals, you name it.

“I don’t have time to sit around thinking about the perfect name for a class! Besides, I know how the code works! I can fix it.”

Oh, yeah? You may now. But how about in a month? Or three? Or a year? Wait… will you even be working for this company or on this project in a year? Who inherits this code?

Prototypes, spikes, and other rationalizations

Occasionally, developers invoke the “p” word: prototype. Prototypes are ugly little creatures that live only a short while.

At least that’s the myth.

The truth of the matter is that prototypes don’t exist. Prototypes don’t get thrown away. What happens when you show a manager working code? He says, “Great! Here’s your next feature!”

“But…”, you start to say.

“But what? It’s working! Marvelous! Right, here you are. Next feature!”

Heard of a “spike”? That’s basically a small prototype that you may not tell management about. You spend maybe 30 minutes working on one. The pain of throwing away the code is lessened. But even then it may offend your sensibilities. And that code is going to be ugly too.

We tell ourselves that the code will be temporary. Most of the time, this just isn’t so. These techniques are rationalizations for writing ugly code that will likely outlive its intended lifespan.

Think about the future!

So don’t throw that code away! Don’t prototype. Don’t spike2.

Dave Thomas sometimes describes writing an application as writing a Domain Specific Language. That is, creating an application is akin to developing a semantically meaningful API to describe an application’s behavior.

Therefore, the smartest thing you can do, when starting a new application, is to cultivate an understanding of the overall problem the application is intended to solve.

How can we do this? Personally, I favor contemporary Test Driven Development techniques:

For a given feature:

  1. Describe, in English, what the feature is trying to accomplish
  2. Exercise the API that I wish I’d write as a test
  3. Make the test pass
  4. Compare 1 & 2
  5. Refactor

For instance, consider this simplistic example:

Names should match intent

The English uses the word “subscribe”. That’s the action that I want the user to perform. So I make it the method name because that’s what I want to tell the user to do. That’s the message that I want to send the user.

Now what if I need an entity to representation that relationship between a User and a Plan?

I’ve seen (and written) some egregiously bad code in situations like this. Once upon a time, my initial reaction would be to call such a thing a “UserPlan”.

That’s just vile and disgusting. Sure, it conjoins the two entities but it does so like Siamese twins!

The better answer should be in plain sight. I used the word “subscribe” in the description! Call that entity a “Subscription”!

But maybe your description was

That would probably cause me to write sample code

It’s still valid though I did less to model the relationship between the User and the Plan because words matter and naming matters.

Counter example

So what happens when we name things badly?

Is “UserPlan” so bad? Perhaps not. But UserPlan only represents a relationship between two entities. Perhaps I need a greater monstrosity to make the point plain.

So what is a SelfpropelledFourWheelGroundVehicle? It’s pretty plainly a Car/Automobile. But it’s a disgusting name. Yet these are the kinds of names that people frequently use in their code due to lack of effort!

Or there’s the other direction: Haskell developers often like to abstract functions such that they have no clear applicability to a domain. That is, their functions will have semantically meaningless variables such as “x” and “xs”. I’m told this is because Haskell has its roots in Lambda Calculus. Be that as it may, mathematical variables have only place in code: in implementing a mathematical calculation!

How would you feel maintaining code where the classes, literals, and methods read like that?!

How productive would you be working in such code? If you cannot trust the names in a code base to accurately represent the ideas at work then you need to understand vast swaths of the code base to be the least bit productive!

Conclusion

If you did not before, I hope that you now have a better appreciation why it is worth your time to get the names right in your code. It will make yours, your colleagues’, and any who later touch your code lives better and more productive.

And if you don’t use good names, I have an axe and I know where you live.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Subscribe to the waiting list of the free, online “Intermediate Ruby Course“.

Technorati Tags: , ,

  1. Robert Martin also wrote about this topic, and, in part, inspired this diatribe with the first chapter of his book, Clean Code.
  2. Yes, this is a sweeping generalization. Yes, I occasionally spike on code. However, I only do this for technically challenging pieces which is to say very infrequently. And I throw my few spikes away.

Last Week’s Top Ruby News: Rails 3.1.3, autoload deprecated, and conferences

It’s a couple of days late but here are the main headlines from the last week of Ruby news. We have a couple of Rails releases, some event news, and the usual gaggle of great articles and jobs.

Headlines

Rails 3.1.3 Released (Very Quickly After 3.1.2)
This release mainly contains fixes for regressions that popped up in 3.1.2, including a downgrade to Sprockets. 3.1.2 itself was primarily a bug and security fix release and cleared up a XSS vulnerability in the translate helper.

#302 In-Place Editing

Edit an attribute in-place without leaving a page using the Best In Place gem. Learn how to add validations and support for various field types.

Rails 3.1.2 and 3.1.3, Rails 3 subdomains, Torquebox

Jason and Peter talk about new Rails releases, Learn Ruby the hard way, subdomains in Rails 3, and more.

40% Off everything, today only 11/25/2011

Questions on Ruby? Ask An Expert at RubyLearning

Questions on Ruby? Ask An Expert at RubyLearning

RubyLearning is happy to announce the start of a series of blog posts titled “Ask An Expert”. We are assembling experts in various areas of Ruby programming who will answer your questions as a blog post here.

To begin with, some of the experts who have agreed to answer your questions are:

  • Gautam Rege on Ruby with MongoDB, Mongo, MongoMapper and Mongoid
  • Gonçalo Silva on Ruby/Rails performance
  • Sau Sheong Chang on Sinatra
  • Sethupathi Asokan on the Ruby devise gem
  • Staffan Nöteberg on Ruby regex

I am sure there are more Ruby experts to follow.

Please feel free to ask your questions on the topics mentioned above, as comments to this blog post. We will put up these questions to the experts who will answer them here as a separate blog post, provided there are at least 7-8 questions per topic. While asking please do mention your name and any one of the following – your Twitter id or your GitHub URL or your Google+ id.

Technorati Tags: , , , ,

Heroku Postgres Launches

Heroku’s Postgres database service, the origins of which date back to 2007, is one of the most battle-tested cloud database services around.

Over the last year, our growing data team has done an amazing job of dramatically increasing the scale, reliability, and durability of the service – now boasting 99.99% (measured) uptime and over 400 million write-transactions per day.

Until now, the service has only been available to Heroku customers, but today we are pleased to announce the launch of Heroku Postgres as a standalone database service. Included in this launch is a new web interface for managing databases, as well as rock-solid durability based on Continuous Protection technology.  Best of all, these improvements are effective immediately for all existing users of the Heroku Postgres add-on.

To learn more, check out the inaugural post of the new Heroku Postgres blog.  Future posts to this blog will contain product updates and articles about leveraging the advantages of PostgreSQL.

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

#300 Contributing to Open Source

GitHub makes it easier than ever to contribute to open source with pull requests. Here I show how to submit a pull request to the VCR project.

Rails 3.1.3 has been released

Rails 3.1.3 has been released. This release mainly contains fixes for regressions that popped up in 3.1.2.

Changes

Action Pack:

  • Downgrade sprockets to ~> 2.0.3. Using 2.1.0 caused regressions.

  • Fix using translate helper with a html translation which uses the :count option for pluralization.

    Jon Leighton

Active Record:

  • Perf fix: If we’re deleting all records in an association, don’t add a IN(..) clause to the query. GH 3672

    Jon Leighton

  • Fix bug with referencing other mysql databases in settablename. GH 3690

  • Fix performance bug with mysql databases on a server with lots of other databses. GH 3678

    Christos Zisopoulos and Kenny J

Railties:

  • New apps should be generated with a sass-rails dependency of 3.1.5, not 3.1.5.rc.2

As ever, you can see a full list of changes on Github.

How to Marshal Procs Using Rubinius

The primary reason I enjoy working with Rubinius is that it exposes, to Ruby, much of the internal machinery that controls the runtime semantics of the language. Further, it exposes that machinery primarily in order to enable user-facing semantics that are typically implemented in the host language (C for MRI, C and C++ for MacRuby, Java for JRuby) to be implemented in Ruby itself.

There is, of course, quite a bit of low-level functionality in Rubinius implemented in C++, but a surprising number of things are implemented in pure Ruby.

One example is the Binding object. To create a new binding in Rubinius, you call Binding.setup:

def self.setup(variables, code, static_scope, recv=nil)
  bind = allocate()
 
  bind.self = recv || variables.self
  bind.variables = variables
  bind.code = code
  bind.static_scope = static_scope
  return bind
end

This method takes a number of more primitive constructs, which I will explain as this article progresses, but we can describe the constructs that make up the high-level Ruby Binding in pure Ruby.

In fact, Rubinius implements Kernel#binding itself in terms of Binding.setup.

def binding
  return Binding.setup(
    Rubinius::VariableScope.of_sender,
    Rubinius::CompiledMethod.of_sender,
    Rubinius::StaticScope.of_sender,
    self)
end

Yes, you’re reading that right. Rubinius exposes the ability to extract the constructs that make up a binding, one at a time, from a caller’s scope. And this is not just a hack (like Binding.of_caller for a short time in MRI). It’s core to how Rubinius manages eval, which of course makes heavy use of bindings.

Marshalling Procs

For a while, I have wanted the ability to Marshal.dump a proc in Ruby. MRI has historically disallowed it, but there’s nothing conceptually impossible about it. A proc itself is a blob of executable code, a local variable scope (which is just a bunch of pointers to other objects), and a constant lookup scope. Rubinius exposes each of these constructs to Ruby, so Marshaling a proc simply means figuring out how to Marshal each of these constructs.

Let’s take a quick detour to learn about the constructs in question.

Rubinius::StaticScope

Rubinius represents Ruby’s constant lookup scope as a Rubinius::StaticScope object. Perhaps the easiest way to understand it would be to look at Ruby’s built-in Module.nesting function.

module Foo
  p Module.nesting
 
  module Bar
    p Module.nesting
  end
end
 
module Foo::Bar
  p Module.nesting
end
 
# Output:
# [Foo]
# [Foo::Bar, Foo]
# [Foo::Bar]

Every execution context in Rubinius has a Rubinius::StaticScope, which may optionally have a parent scope. In general, the top static scope (the static scope with no parent) in any execution context is Object.

Because Rubinius allows us to get the static scope of a calling method, we can implement Module.nesting in Rubinius:

def nesting
  scope = Rubinius::StaticScope.of_sender
  nesting = []
  while scope and scope.module != Object
    nesting << scope.module
    scope = scope.parent
  end
  nesting
end

A static scope also has an addition property called current_module, which is used during class_eval to define which module the runtime should add new methods to.

Adding Marshal.dump support to a static scope is therefore quite easy:

class Rubinius::StaticScope
  def marshal_dump
    [@module, @current_module, @parent]
  end
 
  def marshal_load(array)
    @module, @current_module, @parent = array
  end
end

These three instance variables are defined as Rubinius slots, which means that they are fully accessible to Ruby as instance variables, but don’t show up in the instance_variables list. As a result, we need to explicitly dump the instance variables that we care about and reload them later.

Rubinius::CompiledMethod

A compiled method holds the information necessary to execute a blob of Ruby code. Some important parts of a compiled method are its instruction sequence (a list of the compiled instructions for the code), a list of any literals it has access to, names of local variables, its method signature, and a number of other important characteristics.

It’s actually quite a complex structure, but Rubinius has already knows how to convert an in-memory CompiledMethod into a String, as it dumps compiled Ruby files into compiled files as part of its normal operation. There is one small caveat: this String form that Rubinius uses for its compiled method does not include its static scope, so we will need to include the static scope separately in the marshaled form. Since we already told Rubinius how to marshal a static scope, this is easy.

class Rubinius::CompiledMethod
  def _dump(depth)
    Marshal.dump([@scope, Rubinius::CompiledFile::Marshal.new.marshal(self)])
  end
 
  def self._load(string)
    scope, dump = Marshal.load(string)
    cm = Rubinius::CompiledFile::Marshal.new.unmarshal(dump)
    cm.scope = scope
    cm
  end
end

Rubinius::VariableScope

A variable scope represents the state of the current execution context. It contains all of the local variables in the current scope, the execution context currently in scope, the current self, and several other characteristics.

I wrote about the variable scope before. It’s one of my favorite Rubinius constructs, because it provides a ton of useful runtime information to Ruby that is usually locked away inside the native implementation.

Dumping and loading the VariableScope is also easy:

class VariableScope
  def _dump(depth)
    Marshal.dump([@method, @module, @parent, @self, nil, locals])
  end
 
  def self._load(string)
    VariableScope.synthesize *Marshal.load(string)
  end
end

The synthesize method is new to Rubinius master; getting a new variable scope previously required synthesizing its locals using class_eval, and the new method is better.

Rubinius::BlockEnvironment

A Proc is basically nothing but a wrapper around a Rubinius::BlockEnvironment, which wraps up all of the objects we’ve been working with so far. Its scope attribute is a VariableScope and its code attribute is a CompiledMethod.

Dumping it should be quite familiar by now.

class BlockEnvironment
  def marshal_dump
    [@scope, @code]
  end
 
  def marshal_load(array)
    scope, code = *array
    under_context scope, code
  end
end

The only thing new here is the under_context method, which gives a BlockEnvironment its variable scope and compiled method. Note that we dumped the static scope along with the compiled method above.

Proc

Finally, a Proc is just a wrapper around a BlockEnvironment, so dumping it is easy:

class Proc
  def _dump(depth)
    Marshal.dump(@block)
  end
 
  def self._load(string)
    block = Marshal.load(string)
    self.__from_block__(block)
  end
end

The __from_block__ method constructs a new Proc from a BlockEnvironment.

So there you have it. Dumping and reloading Proc objects in pure Ruby using Rubinius! (the full source is at https://gist.github.com/1378518).

How to Marshal Procs Using Rubinius

The primary reason I enjoy working with Rubinius is that it exposes, to Ruby, much of the internal machinery that controls the runtime semantics of the language. Further, it exposes that machinery primarily in order to enable user-facing semantics that are typically implemented in the host language (C for MRI, C and C++ for MacRuby, Java for JRuby) to be implemented in Ruby itself.

There is, of course, quite a bit of low-level functionality in Rubinius implemented in C++, but a surprising number of things are implemented in pure Ruby.

One example is the Binding object. To create a new binding in Rubinius, you call Binding.setup:

def self.setup(variables, code, static_scope, recv=nil)
  bind = allocate()

  bind.self = recv || variables.self
  bind.variables = variables
  bind.code = code
  bind.static_scope = static_scope
  return bind
end

This method takes a number of more primitive constructs, which I Continue reading “How to Marshal Procs Using Rubinius”

How to Marshal Procs Using Rubinius

The primary reason I enjoy working with Rubinius is that it exposes, to Ruby, much of the internal machinery that controls the runtime semantics of the language. Further, it exposes that machinery primarily in order to enable user-facing semantics that are typically implemented in the host language (C for MRI, C and C++ for MacRuby, Java for JRuby) to be implemented in Ruby itself.

There is, of course, quite a bit of low-level functionality in Rubinius implemented in C++, but a surprising number of things are implemented in pure Ruby.

One example is the Binding object. To create a new binding in Rubinius, you call Binding.setup:

def self.setup(variables, code, static_scope, recv=nil)  
  bind = allocate()

  bind.self = recv || variables.self
  bind.variables = variables
  bind.code = code
  bind.static_scope = static_scope
  return bind
end  

This method takes a number of more primitive constructs, which I Continue reading “How to Marshal Procs Using Rubinius”

Rails 3.1.2 has been released

Rails 3.1.2 has been released. This is a patch-level release containing bug fixes and an important security fix.

Possible XSS vulnerability in the translate helper method in Ruby on Rails

There is a vulnerability in the translate helper method which may allow an attacker to insert arbitrary code into a page.

  • Versions Affected: 3.0.0 and later, 2.3.X in combination with the rails_xss plugin
  • Not Affected: Pre-3.0.0 releases, without the rails_xss plugin, did no automatic XSS escaping, so are not considered vulnerable
  • Fixed Versions: 3.0.11, 3.1.2

Please see the rubyonrails-security posting and the changelog item below, for more details.

Changes

Action Mailer:

  • No changes

Action Pack:

  • Fix XSS security vulnerability in the translate helper method. When using interpolation
    in combination with HTML-safe translations, the interpolated input would not get HTML
    escaped. GH 3664

    Before:

    translate(‘foo_html’, :something => ‘<script>’) # => “…<script>…”

    After:

    translate(‘foo_html’, :something => ‘<script>’) # => “…&lt;script&gt;…”

    Sergey Nartimov

  • Upgrade sprockets dependency to ~> 2.1.0

  • Ensure that the format isn’t applied twice to the cache key, else it becomes impossible to target with expire_action.

    Christopher Meiklejohn

  • Swallow error when can’t unmarshall object from session.

    Bruno Zanchet

  • Implement a workaround for a bug in ruby-1.9.3p0 where an error would be raised while attempting to convert a template from one encoding to another.

    Please see http://redmine.ruby-lang.org/issues/5564 for details of the bug.

    The workaround is to load all conversions into memory ahead of time, and will only happen if the ruby version is exactly 1.9.3p0. The hope is obviously that the underlying problem will be resolved in the next patchlevel release of 1.9.3.

    Jon Leighton

  • Ensure users upgrading from 3.0.x to 3.1.x will properly upgrade their flash object in session (issues #3298 and #2509)

Active Model:

  • No changes

Active Record:

  • Fix problem with prepared statements and PostgreSQL when multiple schemas are used.
    GH #3232

    Juan M. Cuello

  • Fix bug with PostgreSQLAdapter#indexes. When the search path has multiple schemas, spaces
    were not being stripped from the schema names after the first.

    Sean Kirby

  • Preserve SELECT columns on the COUNT for finder_sql when possible. GH 3503

    Justin Mazzi

  • Reset prepared statement cache when schema changes impact statement results. GH 3335

    Aaron Patterson

  • Postgres: Do not attempt to deallocate a statement if the connection is no longer active.

    Ian Leitch

  • Prevent QueryCache leaking database connections. GH 3243

    Mark J. Titorenko

  • Fix bug where building the conditions of a nested through association could potentially
    modify the conditions of the through and/or source association. If you have experienced
    bugs with conditions appearing in the wrong queries when using nested through associations,
    this probably solves your problems. GH #3271

    Jon Leighton

  • If a record is removed from a has_many :through, all of the join records relating to that
    record should also be removed from the through association’s target.

    Jon Leighton

  • Fix adding multiple instances of the same record to a has_many :through. GH #3425

    Jon Leighton

  • Fix creating records in a through association with a polymorphic source type. GH #3247

    Jon Leighton

  • MySQL: use the information_schema than the describe command when we look for a primary key. GH #3440

    Kenny J

Active Resource:

  • No changes

Active Support:

  • No changes

Railties:

  • Engines: don’t blow up if db/seeds.rb is missing.

    Jeremy Kemper

  • rails new foo --skip-test-unit should not add the :test task to the rake default task.
    GH 2564

    José Valim

As ever, you can see a full list of commits between the versions on Github.

Rails 3.0.11 has been released

Rails 3.0.11 has been released. This is a patch-level release containing bug fixes and an important security fix.

Possible XSS vulnerability in the translate helper method in Ruby on Rails

There is a vulnerability in the translate helper method which may allow an attacker to insert arbitrary code into a page.

  • Versions Affected: 3.0.0 and later, 2.3.X in combination with the rails_xss plugin
  • Not Affected: Pre-3.0.0 releases, without the rails_xss plugin, did no automatic XSS escaping, so are not considered vulnerable
  • Fixed Versions: 3.0.11, 3.1.2

Please see the rubyonrails-security posting and the changelog item below, for more details.

Changes

Action Mailer:

  • No changes

Action Pack:

  • Fix XSS security vulnerability in the translate helper method. When using interpolation
    in combination with HTML-safe translations, the interpolated input would not get HTML
    escaped. GH 3664

    Before:

    translate(‘foo_html’, :something => ‘<script>’) # => “…<script>…”

    After:

    translate(‘foo_html’, :something => ‘<script>’) # => “…&lt;script&gt;…”

    Sergey Nartimov

  • Implement a workaround for a bug in ruby-1.9.3p0 where an error would be
    raised while attempting to convert a template from one encoding to another.

    Please see http://redmine.ruby-lang.org/issues/5564 for details of the bug.

    The workaround is to load all conversions into memory ahead of time, and will
    only happen if the ruby version is exactly 1.9.3p0. The hope is obviously
    that the underlying problem will be resolved in the next patchlevel release
    of 1.9.3.

  • Fix assert_select_email to work on multipart and non-multipart emails as the method stopped working correctly in Rails 3.x due to changes in the new mail gem.

  • Fix url_for when passed a hash to prevent additional options (eg. :host, :protocol) from being added to the hash after calling it.

Active Model:

  • No changes

Active Record:

  • Exceptions from database adapters should not lose their backtrace.

  • Backport “ActiveRecord::Persistence#touch should not use default_scope” (GH #1519)

  • Psych errors with poor yaml formatting are proxied. Fixes GH #2645 and
    GH #2731

  • Fix ActiveRecord#exists? when passsed a nil value

Active Resource:

  • No changes

Active Support:

  • No changes

Railties:

  • Updated Prototype UJS to lastest version fixing multiples errors in IE [Guillermo Iguaran]

As ever, you can see a full list of commits between the versions on Github.

New Programmer’s Survival Manual in print

New Programmer’s Survival Manual in print and shipping

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