Enabling Flash logs on Mac

This is mostly a note to myself, but I thought I would share anyway. If you’re on Mac, and if you want the Flash logs, here’s what you need to do.

  1. Create a new mm.cfg file in /Library/Application Support/Macromedia/
  2. Add the following to the newly created mm.cfg file:

  3. Find the log in /Users/username/Library/Preferences/Macromedia/Flash Player/Logs/flashlog.txt

For more info on mm.cfg secreta, see this awesome post from Jean-Philippe Auclair

Why Adobe Flash?

I’m mainly a Java developer. I loved Java since college times because its rigid simplicity and rich APIs in JDK allow me to focus on higher level abstractions for the problems I’m trying to solve rather than spending time on understanding low level language details that I don’t care about too much. I worked with bunch of other languages before, and I do realize that some languages are better for certain problems than others, but overall, Java solves most of the problems I want to solve. If a better language comes along, I will get rid of Java in a heartbeat; I’m very pragmatic when it comes to languages.

I’ve been also developing in Actionscript/Flex for the Flash client code of BlazeDS and LCDS in the past 4.5+ years, so I guess I can consider myself a Flash developer. I have to admit my attachment to Flash is not as strong as Java, I would consider myself a Java developer first.  Maybe this is because I started developing in Actionscript more out of necessity rather than choice (when I joined Adobe, our client was solely Flash, so I had no choice but learn Actionscript/Flex.), or maybe because 80% of code I write today is still in Java.

Over the years, Actionscript/Flex development started to grow on me. Actionscript is a scripting language but it looked and felt like Java. I was used to debugging my server-side Java code, but it was great when I could use Flash Builder to debug my client side Actionscript code, and server side Java code at the same time. When AIR came along, it was nice to be able to write the same code and run it in browser, and on desktop with minimal changes. More recently, I experimented with Flash on mobile devices, and it felt like Flash achieved what Java tried to do (i.e. write once, run everywhere). As a problem solver, I am glad to see that because I believe that there are so many problems out there waiting to be solved by software that we shouldn’t waste our time by solving the same problems in different languages/frameworks.

The true power and beauty of Flash development did not hit me until I started devoting more time on a library that I needed to write natively in Java, Android, and Javascript.

Being a Java guy, I started with Java library, and it was not too hard to implement given how close Actionscript is to Java, and also I could stick with Flash Builder that is based on Eclipse.  When it came to write a sample app to use the Java library, I had to remind myself Java Swing for UI, that was the only glitch, but it wasn’t too bad. Technically, it was easy, but it took time.

Next, I tried the Android library. It was a whole new framework, a whole new IDE, but I was somewhat lucky there too. Language (at least the syntax) in Android is Java but it lacks some fundamental packages like java.beans for example. With some help from Apache Harmony code to fill those gaps, I was able to get Android client done as well. It also helped that Android development happens in Eclipse that I’m familiar with. Of course, I needed to write a real app to test my Android library again, and this time I had to learn a whole new UI model for Android. Simple UI stuff that would have taken me 10 mins in Flash/Flex or Java Swing took me a few hours on Android because it was so new to me. In the end, I got the app working and proved that the Android library works, but again it a took a lot of time.

Next was Javascript. Oh, boy, wasn’t this a challenge? A language with no real inheritance support, no real packaging system, no good IDEs you expect from Java land. On top, a whole new UI model again with HTML, and the new uncertainty of HTML5  with WebSockets etc. I had to switch to a a whole different development environment (IDEA), and implement the same things in Javascript in order to solve same problems that I already solved in Actionscript and Java.

Luckily, I didn’t have to worry about iOS devices (iPhone, iTouch, Mac OS). If I did, that would have meant yet another development environment, and a whole new code base in Objective-C that needed to be implemented and maintained.

When I look back at it, it was very cool and educational for me as a developer to be able to work with the same library in multiple languages. However, when I think about all the time and effort spent in writing specs, implementing, testing software that essentially solves the same underlying problems on different platforms using different tools, it makes me think whether this is really how software development should be. Sure, it’s cool to see the same app as a Java app, or on an Android device, or on a website in Javascript, or as a iPhone app, but in the end, you’re looking at the same app on different screens, and each of those apps are solving the same underlying problem.

Software development is all about problem solving. By problem solving, I mean writing apps to solve a use case. I don’t mean writing essentially the same app in multiple platforms to solve the same use case. I’d rather focus on my app, make its UI great, make its low-level code solid, make iterations on its design, and let someone else worry about how it can be run on different screens. I want to think that software development reached to the point where multiple platforms are just a “detail” that I shouldn’t worry about, so I can focus on solving real problems of real people that have real impact in the world.I don’t want to spend my time in trying to maintain multiple code bases in multiple languages/platforms that essentially solve the same problem.

Adobe Flash enables me to focus on problems, and write great apps to solve them, rather than spend my time worrying about the “details” of how my app will run on different screen. It helps me to maintain the same development environment on multiple screens, rather than spending time on learning new development environments and languages for device X, Y, Z. That’s why Flash is great for me.

Sure, Flash is not perfect, sure it can be faster, sure it can have more features…but it’s the only development environment offered today where you get a chance to focus on your app, and target multiple screens without having an army of specialized developers for every single platform you want to target. As I said before, I’m very pragmatic when it comes to languages/platforms, so, if another better language/platform comes along that enables me to do what Flash does today and more, I’ll dump Flash in a heartbeat, but until that day comes along, I’ll stick with Flash.