Tag Archives: c#

Flex is a Relic and Silverlight is a Zombie

…or some other catchy metaphor that will grab your attention. These technologies were hot over the last 5 years. Flex gained a particular amount of popularity in the Java community where UI technologies have a bit of a spotty record (that’s like saying my Bengals have a bit of a spotty record over a lifetime). Silverlight gained a lot of traction among Microsoft developers who actually cared about design and UX. Many alpha-geeks of the Microsoft space were running around giving conference talks about the MVVM pattern, and sharing code on codeplex. So what happened?

Both of these technologies are going to fade on the public web. Tablets and mobile devices are too big a share to ignore. Html5, phones and tablets did them in. The heavy hand of Steve Jobs probably gets credit for the coup de grâce. The browser vendors and phone OS creators have really put their weight behind Javascript and Html5. If you have have that skill-set right now you can create:

  • Web Content
  • Mobile Web Content
  • Mobile Apps via Appcelerator
  • Mobile Apps via PhoneGap
  • Windows 8 Metro Apps

That’s a pretty wide reach for a markup / scripting language set.

So what do you do if that’s your trade? You work as an AIR/Flex developer or Silverlight developer, what do you do? There are good options for each camp, and some universal options.

Flex Developers

I think this is the slightly less promising path in the long term (despite it hitting a much higher peak than Silverlight). That said, Flash and Air will live on for a while, and you have some time to make a transition. Additionally, the ability to use the Adobe tools to make mobile applications provides a bridge to the hot mobile market. And you can make long term plans to transition to another cross-platform tool (PhoneGap, Appcelerator, etc), or go native. If you’re in the Adobe camp, new tools like Edge are likely to ease the transition to the standards-based technologies of the web.

Silverlight Developers

Similarly, Silverlight won’t be gone tomorrow. Intranet applications that need rich functionality (and simple deployment) are still a nice fit for Silverlight Desktop applications. And the adjustment to WindowsPhone 7’s flavor of Silverlight is straightforward, though I would be cautious and investigate the financial realities of that market. Finally, while Windows 8 Metro Apps don’t specifically use Silverlight, they can use C# with XAML and a subset of the .Net libraries that emphasize a security sandbox and async data connections. Sound familiar? That’s because they re-animated the corpse of Silverlight and made it an option for writing Metro apps. Long term, you should probably learn to use the Html5 / JavaScript hooks for Metro due to the ubiquitous nature of those skills. But isn’t it nice that you can learn the new API (WinRT) while keeping C# and XAML, and then make the languages switch at your leisure.

For Everyone

Both camps should embrace these newer web technologies and the UI skills they picked up during their time with the respective technologies. Good user experience and design are rare skills in developers, and retraining the languages and tools should be the easy part. Keep your black turtlenecks and invest in the next tools rich applications. You already have a leg up.

Rake Breathing New Life to Building Old Projects

I’ve seen lots of examples of rake (the ruby make replacement) being used as a build tool in non-ruby projects. Many of these are still modern platforms, like .Net. For example, StructureMap builds with rake. But I’ve found that even on older platforms, the power of having a full programming language in your build tool is useful.

Recently, I was working through examples in Thinking in C++, and there is the need to build many small one file examples. I started writing a Makefile to simplify this, and decided to try rake instead.

The power of a programming language brings a lot to table when doing repetitive tasks. Check out the following Rakefile which generates a build, run, and clean method for each file listed in an array. And there are aggregate methods which will run or clean all.

exe_name = ["hello","c_in_cpp","file","vector"]

exe_name.each do |f|
  desc "clean #{f}"
  task "clean_#{f}".to_sym do
    sh "rm -rf #{f} #{f}.o"
  end

  desc "build #{f}"
  task "build_#{f}".to_sym => "clean_#{f}" do
    sh "g++ #{f}.cpp -o #{f}"
  end

  desc "run #{f}"
  task "run_#{f}".to_sym => "build_#{f}" do
    sh "./#{f} 2> error.log"
  end
end

desc "run all"
task :default => exe_name.collect{|f| "run_#{f}"}

desc "clean all"
task :clean => exe_name.collect{|f| "clean_#{f}"}

If any of the above is unclear, and you want to see the output, do the following: copy and paste that code into a file named “Rakefile”. Run “rake -T” to lists all available tasks. You won’t be able to actually run the tasks, unless you have the appropriate cpp files in the directory (ie “rake run_hello” requires hello.cpp).

If you want to learn a build tool, and know ruby, or want to learn ruby rather than some specialized build language with no other uses, give rake a shot.

NHibernate and Auto Properties

I’ve been working through the NHibernate with ASP.NET ProblemDesignSolution (Wrox Blox), with some small changes. I’m writing my sample in C# using the .Net framework 3.5. I prefer to use auto-properties.

It’s common that fields have private setters and only nhibernate can map using the backing field (set via reflection). 

public String City { get; private set; }

The problem is telling NHibernate how to find the backing field. When you have an explicit field, you end up with something like:

<property access=”field.camelcase-underscore” name=”City” />

But with no backing field, that is a problem. I started looking around on the net and found the following:

StackOverflow discussion without much good info
and a blog post with an interesting response from Ayende Rahien.

Ayende is saying to not worry about the issue, NHibernate will still be able to set via reflection. That’s fine, but it feels a little “magical”, especially to a new developer coming along.

Why not set protected? It’s not unreasonable to expect a maintaining developer to understand that NHibernate sub-classes your class.

public String City { get; protected set; }

Now the mapping stays simple too:

<property name=”City” />

And there is no need to expect a maintaining developer to know that reflection magic is setting the property.