I recently discovered Processing, and I am still in awe of what can be created with it. For those of you not familiar with Processing, it is a c syntax (pretty much java) language created at MIT's multi-media center designed to be used by artists and non-programmers to create visual/animated/physical works of art. The primer written by two of Processing's creators walks a person with no prior programming experience through learning to program.
As someone who has been programming since I was 10 years old and close to 30 years now, I found their approach so simple, powerful, and very approachable. Probably even more valuable to me was the plethora of examples that come with the simple IDE. Full particle and physics systems encompassed in less than 100 lines of code! OpenGL support, texture, uvt mapping, typography, and the list goes on.
I see some of what has been accomplished with Processing as the inspiration of what I think will be possible with Degrafa, and I look forward to seeing how far I can push the boundaries of what is possible in Flex/Flash by adopting similar constructs within Degrafa. The interesting twist Degrafa will bring is that we may be able to step away from procedural abstracts and work directly with declarative ones. Degrafa repeaters is one example of how this might manifest.
The animation at the top of this entry was created by Glenn Marshall, who just started working with Processing, but obviously has an incredible amount of artistic talent. What I find just mind blowing is that the animation he created is all done procedurally using sin/cos, looping, recursion and math. There was no use of After Effects, 3DS, or any other tool that translates analog inputs (hand drawing) into something digital, this is purely abstract programming - which just adds a sublime level of beauty to the finished work.
Note: Watch the video in its entirety it gets better, and better, and better ....
This is a pretty short post that I wanted to get out to the community. Below are the links and source code (view source) for the presentation I gave today at 360 Flex in San Jose.
GoogleFinance Example: (view source coming soon, still needs some refactoring and clean up.)
First a thanks to everyone who has commented and used the previous versions of the gauge component seen here.
A few weeks ago a publicly traded company (that has asked to remain anonymous) hired me to make some improvements to the gauge to meet some of their specific needs. Some of the improvements are things that other people had asked for, so I offered to give them a discounted rate if we could keep the improvements under the original open source license. It was more important to me that I be able to share the enhancements with the community than the additional revenue I would have generated to lock up the intellectual property.
So here is a list of the latest enhancements.
1. Bounce Effect can now be set on/off by a boolean useBounceEffect. (code changes in control.)
2. Tick Mark Alignment Fixed - Tick marks for the gauge skin now use a best fit algorithm to align exactly with the min/max angles (before they sometimes would not cover the full range. (code changes in skin)
3. A X-Offset style has been provided for the value label placement (code changes in skin and control)
4. Alert Levels: A popular request was the addition of alert levels, something that I had in the original gauge I built. The gauge now supports contiguous alert levels by passing it an array of alertValues, alertColors, and alertAlphas. The control expects that the alertColors and alertAlphas will have one element less than the alertValues, since the alertValues contains the additional min or max boundary element, and the colors/alphas apply to the range within the boundary described by the alertValue array. (code changes in skin and control)
5. Log AND Linear scale: This was by far the most complex enhancement. The gauge now supports movement through a log scale as well as the original linear scale, and since my math skills seem to be stuck somewhere between 8th grade trig and 9th grade algebra it took me a while to figure out the algorithm to support not only programatic value assignments, but also when a user clicks along the and sets the value directly - yes now I remember that, Math.pow(10,value) is the inverse of Math.log(value)/Math.LN10 :) This log scale also gets applied with the alert ranges, and the skin leverages the now public caclulateAngleFromValue() function exposed by the control itself - which takes into account the min/max value range, the min/max angle range, AND the linear or log scale. (code changes in control)
I have tried my best to run it through a bunch of tests and ferret out any bugs, but if anyone finds something I missed please post and comment, and I will try my best to fix or point you in the right direction. Once again this code is posted under the every friendly MIT license.
For any designers or UX people out there, I don't know about you, but I have yet to find a wire-framing tool/software that beats a whiteboard or sketch-pad, but I think I have found something that comes pretty close.
Making wireframes is an essential part of the design process (at least for me) that allows me to quickly brainstorm layouts and different configurations for an overall application or dashboard UI. Most illustration tools that I am familar with (like Illustrator or Flash Pro) are just too cumbersome and have way too many settings/details that are completely irrelevant to the wireframing process. Tools like Visio (which I just can't stand) and SmartDraw come a little closer, but they have all sorts of awkward UI issues that at best, slow down the creative process and in some cases completely hinder it due to the way they expect you to create content.
Well, after many years, I think I have found a very good tool to make my wire frames in, and ironically the software was never explicitly designed to make drawings. What I am referring to is Apple's Numbers - the supposed Excel replacement. Well, as a replacement for Excel it doesn't even come close - for doing any type of semi-sophisticated numeric modeling it just doesn't cut it.
But, as a very easy to use, quick and easy, creative wireframe tool it is superb. It has all the basic shapes I could ask for, sans all the detailed property controls that make things tedious in most other tools. The inspector panel allows me to create sophisticated gradients, fills, strokes and best of all, it has auto-align/snapping capabilities built right into its WYSIWYG interface. Most of my wire-frames are some form of nested rectangles, and this tool just lends itself to the task beautifully. Because of the way they designed numbers, it is a layout tool first, and and a spreadsheet second. So you don't even need to have a worksheet at all, you can just have a blank canvas and start dropping images, shapes, text, etc. Add the fact that you have an automatic export to PDF and it makes it ideal for delivering to clients and end-users.
For me it has been very liberating, and one of the first times I felt a software tool actually accelerated my productivity for doing this type of work, versus just being a tedious step I needed to do to translate my whiteboard/paper sketches.
Anyone running on OS X and doing any type of wire-framing work should give it a try, I would be curious what other designers think.
Well, it looks like it is official. I will be speaking at MAX 2008 this year on Data Visualization with Flex. I am still working out the final details of the presentation. When I spoke on the same topic in 2006, I did a detailed walkthrough of building a dashboard. This year, I think I will change it up a bit and more do some highlights of what is possible with little code tidbits and how-to's. I think this might appeal to a wider audience (and potentially shorter attention spans since my session is going to be at 3:30 on Wednesday November 19th, the last day.)
I would love to get some feedback from the community as to what level to target the session. Should I stick with beginner level material (i.e. here are all the available components and what they do, or go to a more intermediate advanced level?) Any comments very welcomed, as I still have a couple of weeks to flush out the preso.
It appears there is a known bug in the Flash Player that creates rendering artifacts and uneven results when trying to apply strokes to a corner radius. Let me outline the situation by having you look at the attached image with three separate rectangles and the associated code for each.
So for the left rectangle we used the code below, and one would expect a nice pretty red rectangle with a smooth black stroke and 6 pixel corner radius, but what we get is a rectangle with 4 uneven corner and these weird rendering artifacts which extend beyond the boundary of the shape.
For the middle rectangle we set the "pixelHinting" property of the lineStyle to true, and this seems to remove the funky artifacts, but still leaves the different radius on the corners.
For the right most rectangle it appears we have it drawn correctly, but we were only able to do this by NOT using any line style at all, and instead having to create two rectangles with one nested inside the other.
So it is obvious to me that the Player is capable of rending this correctly, but it does NOT. I am not sure if the cause is in some type of sub-pixel interpolation algorithm, or it lies within the "curveTo" code for line strokes where the player might be using some type of cubicBezier algorithm and the control points are too close together to get an accurate curve.
It appears that the Flex team is aware of this issue and thus renders all of its "cornerRadius" borders by applying the same technique I am using above by doing two separate compexRectangle fills.
So apparently Adobe is well aware of this issue, and from what I understand, through unnamed sources, this isn't even on the radar for the next major release (Flash Player 10.) I think is a real shame since I believe it really undermines the quality of what can be produced with Flash when you want a high level of detail and your are forced to take a bunch of unnecessary hacks to work around it.
I just returned from a great summit meeting for BI hosted by Dashboard Insight, where I sat on a panel with other industry experts. It was a small group of about a dozen of us, and it was a great two day meeting. It was fantastic to have an opportunity to talk with other people who work with the same issues I face every day while working on BI stuff.
I was a bit concerned attending the event that I would not see eye-to-eye with some of these other experts, since I hold a relatively contrarian view when it comes to designing dashboard solutions. I believe that ALL business intelligence systems need to be designed from the top (user) down, versus the bottom (data) up. Pretty much all big BI vendors and industry experts have been preaching the bottom-up mantra for the past 20 years.
On the flight back from the summit I wrote an article that (hopefully) more clearly articulates my position and the logic behind it. You can read it here. In a nutshell I basically state that Big BI and current industry experts have a strong financial interest in not rocking the status quo, and are in fact hindering the efficacy of the very solutions they purport to be advancing.
By any objective measure, BI is long way away from reaching its potential, especially in the eyes of business users and organizations who have implemented seven figure BI solutions. My thesis is that because BI has its history rooted in the collection, transformation, aggregation and dissemination of data that the lions share of focus on any BI project revolves around the data and the not the end user. Reports and dashboards end up being after-thoughts at the end of big BI initiatives.
The BI industry has created its wealth through the selling of these solutions and expertise and insist they are needed to provide an effective BI solution. In my experience this is absolutely NOT the case. You can create a very effective dashboard solution with a very minimal BI infrastructure, although in some cases having a robust BI back end is definitely going to make things easier. As I mention in my article the BI leaders have painted themselves into a corner because even if they recognize the back end is not the place to start, they would end up undermining their primary revenue streams (not to mention customer confidence) if they openly acknowledged this state of affairs.
What I suppose will begin happening, is that more and more start up companies will start to address this schism and we will see a slow movement to more user-centric BI solutions that focus on business and user requirements with online tools that allow integration of distributed and heterogenous data. At the same time I still see a very valid place for traditional BI, as there are still thousands of companies with vast stores of transactional data that needs to be collected, processed, and aggregated into common structures that can be used to help feed the user-centric BI solutions.
One of the first areas of Degrafa I started working on was a revamp of the current Repeater objects. Jason had some cool ideas on what we could do to make repeaters more concise, flexible, and powerful. After a couple of IM chats I had a reasonably good idea of what we wanted to accomplish and I rolled up my sleeves to see what I could do. You can see the most current rev in our Dev branch at Google Code, although I suspect we will end up cleaning up some of the name spacing and move the new GeometryRepeater class somewhere else.
One of the challenges the current Degrafa Beta 2 suffers from is that we have a myriad of specific geometry repeater classes like Line, Circle, Rectangle, etc... Not only does this clutter up our core class libraries, but it is also much less flexible than it can be.
The new architecture we are developing takes a different approach, instead of creating gemoetry specific repeater classes we wanted to create an abstract repeater engine. This is accomplished through our GeometryRepeater class which inherits from Geometry and implements the IRepeaterModifier interface via its modifiers array. Okay, so what does this all mean?
1. You define the geometry you want repeated with any number of Degrafa geometry objects, which can be separate objects or complex compositions. You are no longer limited to the current repeater classes, but can easily repeat ANY Degrafa geometry you create.
2. You define HOW the geometry repeats via one or more IRepeaterModifiers. Initially we have created a PropertyModifier that allows you to target one or more geometry objects within your GeometryRepeater and an associated property you want to modify. You can have as many RepeaterModifiers as you want to create composited repetitions. Over time we may add additional core modifiers, or you can create your own by implementing the IRepeaterModifier interface.
Below you can see how one might implement a Circle repeater that repeats along a horizontal Axis:
For a more complex example you can check out this demo that has view source enabled.
When you look at the demo you will see a simple circle geometry that is being repeated 30 times with multiple property modifiers being applied to it. If you look at the code there are some interesting things to note here about the PropertyModifier class.
1. We support targeting common properties across multiple targets via just one repeater like are doing here with the myCircle and myRect in the targets properties. We also support not only direct object properties, but also descendent properties via a dot notation (look at the property="fill.alpha") setting for example:
2. We support built in static operators as well as offset functions.
Not only can you provide static offset amounts (as in the example above) with fixed operators like add, subtract, or none you can also provide offsets as an array that will behave like a modulo function against the iteration number as in the radius modifier below. Additionally you can also provide offsets as dynamic functions as in the fill.color modifier that uses the custom colorOffset function found in the sample source files.
There are many more advanced features, but I will wait until we have pinned down the exact functionality for our Beta 3 release before delving into it further. Please check out the sample, and use view source to get an idea of what is possible.
Over the past couple of months I have become more deeply involved in the open source Degrafa project that was started by Juan Sanchez and Jason Hawryluk over 1 year ago. Today the Degrafa team has grown quite substantially and I represent the 8th official team member.
There were three primary motivations for me joining the Degrafa team.
Reason 1. Degrafa just plain ROCKS!
What I love most about Degrafa is that it represents an extremely expressive, yet compact markup syntax to produce amazing graphical assets. Basically it allows me to do some really cool things with very little code.
Degrafa leverages the low level flash drawing API's to implement sophisticated vector and raster rendering via MXML markup. What does this mean to your average Flex developer? It means that you no longer have to resort to working in Flash or other vector based tools to create complex vector assets, and you no longer have to struggle with using procedural API's to manually draw your graphics. Degrafa piggy-backs off of the same metaphors that most XML based markup syntax does, in that the nested XML structures you use to define your page layout create a visual corollary to the actual physical layout of the code. With XML markup you can easily see the primary relationships between objects due to their nesting structures.
When you combine XML Markup with Flash/Flex's powerful binding mechanism you get a very expressive, compact, and intuitive way to code graphical assets. One example of this effect in action can be seen in some of the GeometryRepeater code I have been working on for Degrafa (to be covered in a later blog post.) I was able to take a couple very simple base classes and in less than 15 lines of MXML and 10 lines of AS create a completely dynamic single series Column/Area/Point/Line chart. That is 25 lines of total code, that is what I call powerful!
Reason 2. I wanted to give back.
When I started working with Flex in late 2005, I had never been directly exposed to the open source community and always regarded the open source movement with a detached fascination and certain level of disbelief that so many developers would volunteer their time for an apparently non-commercial effort. Over the past couple of years, my eyes have been opened to the many advantages to open source on commercial, personal, and social level. In learning Flex and watching the growth of the community I have repeatedly reaped the benefits of others efforts in many areas ranging from free (and excellent) components, blogs, and sharing of ideas.
I think an individual can only "take" for so long before starting to feel an indebtedness and desire to give back to the community. Probably most of all is the great level of personal satisfaction I receive when I contribute something to the community that others find great value in. I probably receive more satisfaction from releasing a component I spent time working on and seeing many people positively respond to it in my blog than I do from landing a large consulting contract.
Reason 3. Team Culture.
Both Jason and Juan (the two founders of degrafa) are so genuinely enthusiastic about the project and immanently accessible. When I dove into Degrafa for the first time a couple of months back for work on my Gauge component I started trading e-mails with Juan, which quickly led to multiple chat sessions per day. Juan was always available to answer questions and point me in the right direction, and then he connected me with Jason, who was equally accessible and helpful. Once I started working with Jason and he showed me the guts of Degrafa I realized "wow, these are some truly bright people, creating a really amazing framework." I was hooked.
Moving forward my role at Degrafa will probably have many facets, but I will most likely be focusing as a direct contributor to the core engine as well as helping to provide some organizational support for Degrafa as an entity and open source project.
Is it me, or Apple? The recently (a few hours ago) announced 3G iPhone was stated to be thinner version of the current model. But a close look at the tech specs on the Apple store site indicate that it is actually .48 inches (12.3mm) thick while the previous version was only .46 (11.6mm) thick.
The difference in the new iPhone design is that the edges appear to be more sculpted like a Mac Book Air, thus the phone probably "feels" thinner, when in reality it is thicker.
One of the most powerful aspects of using Flex is not necessarily the language or IDE itself, but the design patterns that the combination of Flex and the Flash Player allow you as an software architect to implement. For developers who are used to building large scale web applications, the traditional approach is to use some version of an n-tier architecture where your platform consists of a data persistence layer (fault tolerant DB's), web application layer such as .Net, Java, ColdFusion, etc (to maintain session state for stateless HTTP and enforce business logic), and your presentation layer (HTML, Javascript, Flash, etc..)
This is a topic that I have been thinking about quite a bit over the last couple of years since I started using flex, and the more I work with Flex the more I stand behind the conviction that packages like Flex/Flash offer us a new paradigm for web application development. I realize this is a long post, but my hope is that others out there in reading this post will start to think about web application development in a new light and realize there is potentially a more powerful (and enjoyable) way to design web applications.
The traditional n-tier approach, while tried and true (and an architecture that I have implemented in more solutions than I care to remember) has several shortcomings that are primarily related to the limitations of web technologies at the time the n-tier approach came into vogue almost 10 years ago. Below I list four fundamental shortcomings with this approach, although I am sure there are several more.
Shortcoming 1 - Multiple Languages/Environments:
Taking this layered approach to building applications, requires the developer to code in several languages across several tiers and IDE's. Even in the most simplistic web application, the developer is going to have to be writing and debugging some type of SQL via one IDE, then working on some application tier code with something like Java or .NET, and finally writing their presentation layer with some HTML/Javascript or Ajax Library. All said, the developer is going to have to be pretty efficient at knowing at least 3-4 completely different languages as well as their associated tooling, or even worse, have to distribute that work across multiple team members. Then, when it comes time to debug the application, even in the most integrated of environments, the developer will be debugging through several different debuggers, trying to track data structures and logic as they pass through each layer, all of which takes time and not a particularly efficient way to troubleshoot an application.
Shortcoming 2 - Brittleness:
I don't care how "loosely" coupled or abstracted you have designed each layer, by its nature this approach tends to create brittle designs where each layer is written in its own language and has unique implementation details. In my experience, no amount of planning for future functionality and abstraction fully covers you in your design, and more times than not, an innocuous feature request like "Gee, it would be nice if we can capture the users surname on our registration form" has the developer modifying the presentation layer, business/app layer, and data layer to accommodate a relatively simple request that ends up rippling through every layer of abstraction in unavoidable ways.
Shortcoming 3 - Maintaining Client State on the Server:
HTTP by its very nature is a stateless protocol, each time that browser loads a new page, all state is lost (cookies aside), sorry folks, but that is the way it was designed. For that reason, web application architects find themselves jumping through all sorts of hoops to maintain state on behalf of the client within their centralized web servers. This problem becomes further exacerbated when we are designing a scalable web application with many web application servers. You now have to deal with load balancing IP requests across multiple web servers and dynamic client IP pools. This makes the architecture required to build out a web farm a much more complex issue for your application design, testing, scaling and debugging.
Shortcoming 4 - Browser/Desktop Compatibility:
This is so obvious I don't need to hammer it further, but needless to say writing web applications (or even desktop ones) that behave nicely on a wide variety of clients and environments requires writing LOTS of code that deal with compatibility issues and adds zero additional functional value to your application.
So how does a technology like Flex address these issues? To me, it wasn't immediately apparent, as I when I started using Flex I just thought of it as an easier way to build a more attractive and interactive presentation layer, but the more I used it and the more I saw how powerful the Flash Player, was I started to realize that there was a real opportunity to do things differently. It was at about this time (a couple of years ago) that I was starting the initial architecture for our on-demand BI dashboard offering, which was the flagship product of the startup I had co-founded.
When evaluating architectures and design patterns I wanted an approach that was going to maximize developer productivity while giving us a consistent and maintainable code base. I looked at frameworks like Cairngorm (which largely borrow from established Java design patterns) and ultimately with the help of my VP of Engineering ended up designing a custom framework and architecture over the course of about 6 weeks. This framework allowed us to successfully go from a written spec to commercial product with two live Fortune 500 clients in just under 6 months with a team of three developers including myself who was only working on the product part time. All in all, I was very proud of our effort and what we were able to accomplish in such a short amount of time, and outside of having a very dedicated team who worked extremely hard, I attribute that success to being able to leverage a completely new paradigm for web application development.
So what did we do that was all that different, what was our secret? Well, obviously Flex was a big part of it, but more so it was what Flex allowed us to do from an architectural perspecitve. Fundamentally we still had all the basic pieces of an n-tier architecture in place with a DB on the back end, a web service bridging the client to the DB, and our client code within Flex. But what was different was WHERE we put the code for those layers. When you looked at the composition of our code which was spread across SQL in the form of creation scripts and stored procs, .NET for our C# web service and Flex for our client, 98% of our code was all written in Flex. We had less than 3000 lines of code within SQL, less than 1000 lines of code in .NET and the rest was all Flex!
How did we do this? Why did we do this? Well, we essentially condensed all of our abstractions layers into one platform and language - Flex/ActionScript. We still had a "presentation, business, data" layer but it all existed within our Flex classes via a MVC framework approach. Our model classes would serialize themselves into XML which would then call our web service which primarily served as a secure pass through to our DB, and then the DB would digest the XML via associated stored procedures and update or retrieve data in the appropriate tables. This meant when we had changes to the spec and had to add that a new data field we simply updated our Flex UI and underlying model class and the appropriate stored proc on the DB. The separation of layers worked beautifully, all the UI code and underlying model code was in one environment and IDE, while all the code to maintain referential integrity of the persistence layer sat in the DB where it belonged. The primary motivation for me to adopt this approach was to focus as much of our development energy on directly enhancing functionality versus working on plumbing and repetitive coding tasks that did not directly add to the feature set.
This approach afforded us huge advantages in our development. The single biggest advantage was the speed of development, once our data tier and pass through web service were stabilized (with less than 4k lines of code total, that did not take too long) we could debug all of our code in one environment. The whole architecture of the platform sat in one place, Flex, and while our .Net web service exposed some utility functions for us (like SMTP access, and some server side file manipulation) we rarely had to leave the Flex debugger for troubleshooting. The second big advantage that we had was how we could scale our application on the web tier. Since all of our complex client state existed within Flash (and thus on the client) the only load our web servers received was for the stateless pass through requests to/from the DB and for some utility work. Thus, we did not have to maintain any session state on our servers and scaling out the web farm was simply a matter of adding more web servers behind a load balancer. The back end DB still required clustering for fault tolerance and scalability, but we had a relatively simple DB schema that made this easy enough to achieve.
All in all, had we taken a more traditional approach to designing our application I can confidently say it would have taken us at least 50% longer to build with half of the interactivity and robustness that our application released with on version 1.
This approach worked for one primary reason, and that is the ubiquity and the power of the Flash Player in combination with the abstraction of ActionScript 3. Yes, everyone knows that Flash has something like a 98% penetration rate, and that a .swf file is going to act pretty much the same regardless of the browser or OS it plays within. But, when Adobe released Flash Player 9, it left the leagues of a neat way to show cool animated effects, and offered a true platform to deploy robust applications against. The performance of the Flash Virtual machine is pretty amazing when you consider how compact it is. For instance I can manually filter row by row through thousands of database records using powerful regular expression match patterns within mili-seconds ON the client. Flash is not without its warts, but all-in-all a very compact, and powerful platform to write code to. I encourage other web application architects to look closely at the Flex/Flash combination for their next project and consider how they might benefit from this approach.
When I purchased my Mac Pro, I had an option of which keyboard I wanted, I ordered the wireless keyboard, knowing how small it was, and thinking it would be next to useless for coding, but perfect for a family Mac-Mini. Well, I actually kind of like the keyboard, the key-throw is good, I can type fast and it is really light/elegant. BUT, it is pretty diminutive, and so light that when I use it in my regular seated position (feet elevated on desk, very reclined in my chair) with the keyboard on my lap, it kept slipping down. I found myself unconsciously holding it in place with my left thumb so it wouldn't slide down. Typically with large keyboards, the pad of my palm would rest against the bottom keeping it in place.
So I devised a super high-tech holder custom designed for the Apple Wireless Keyboard. It is very lightweight fits perfectly and made from bio-degradable earth friendly materials. See the photos below. It works perfectly, the keyboard is now secure in my lap and very comfortable. Perhaps when this one wears out I will create one out of a nice piece of lucite :)
Update:
My v1 keyboard holder ended up becoming a little "floppy" after 2 weeks of use, so I created a new one out of PVC/Sheet. Other than a slight mishap with the router in my haste to replace the more organic version, it worked out fine. A little hook-and-loop tape allows me to mount and remove the keyboard with ease. The size is perfect for typing in my lap.
I am sure I am not the only one who has posed this question, I know there was lots of conjecture about this a couple of years ago. But I think the argument is even stronger today. It appears that Apple is really trying to take advantage of the fiasco that is Windows Vista and is pushing new PC buyers to make the jump to Apple (hey it worked on me) But, Apple is going to have a tougher going with the developer crowd and the corporate culture. If Apple ever hopes to jump the chasm and become an integral part of the enterprise they are going to have offer compelling reasons for developers to jump ship as well and write software for Apple. Right now the only compelling reason for developers to make the switch and write software for Apple is because they become so enthralled with the Apple experience that they want to be part of it (once again, I am guilty as charged) or they are specifically targeting OS X or the iPhone for their offering.
But, as motivated as I am to develop the next great iPhone/OS X app, each and every time I put forth an earnest effort to do so I am struck by how antiquated the development tools, languages, and platforms feel to me. For a corporate developer who just needs to get the job done and could care less about how sexy something looks/feels they will have even less impetus to make the jump. One thing that Microsoft did extremely well, although not so much any more, was to practically spoon feed developers with their technologies. It was SOOO easy to pick up a MS technology, not necessarily because they were the best technologies, but because MS invested heavily in providing training materials, live events, practically giving away their software via MSDN, etc. Now, I see the open source movements doing a better job of this with the robust communities and communication infrastructures that have developed as a result of the internet.
So here I sit at a cross-roads, do I invest the time to develop an application that is specific to Apple either via Objective-C/XCode or via proprietary AJAX for Safari extended WebKit? Well, either choice seem like several steps backwards from where I am right now. Currently I develop in Adobe Flex, and while the tooling can stand room for improvement, it is still far ahead of XCode. But where Flex really shines is the combination of the language and the design patterns it easily supports in combination with the power and ubiquity of the Flash player. Having to go back and write AJAX code and deal with browser compatibility issues and the lack of robust profiling/tracing tools is just painful. Once you know how much better it can be, having to go back and use tooling/languages that you were using 8 years ago just hurts. The XCode/Objective-C road does not appear any better. Damn Flex and Adobe, if I never went down this path I wouldn't know any better, and I would be happily struggling with AJAX, HTML5, and excited that I now have a Canvas HTML element that has a graphics context I could draw to.
Okay, back to my original theme for this post, why should Apple purchase Adobe? If for nothing else, Flash and Flex. If Apple controlled Flash they could easily put it on the iPhone and still force their lock-in for flash-enabled iPhone apps having to be distributed via their AppStore. With ActionScript, Flash, and AIR in their back pocket, what they have is universal development platform that would open the doors to a much wider developer audience. Because a developer knows when they are targeting Flash/AIR they are not only targeting Apple but pretty much any OS/Client. In the words of Bob Warfield, the friction is greatly reduced. It would also put Apple on practically EVERY desktop because Flash sits on every desktop. Similar to the logic I used in purchasing a Mac Pro, where I knew worse case I could run Windows natively (but have yet to do so) I would be able to develop for the iPhone/Apple knowing that my application would also work anywhere elese. Even better, instead of having to learn the ins-and-outs of a new language based on an old development paradigm I would either leverage the knowledge I already have (if I knew Flex) or be investing my time in learning something new, but more powerful and more efficient.
But, wait, there is more to this argument outside of my myopic developer/engineer perspective. Apple is really pushing to deliver software to creative folks, albeit more at the hobby level, but nonetheless what company has the best and most established creative software? Adobe!!! If Apple wants to position themselves as the company that creates the hardware, software and distribution channels for creative content (music, video, multi-media, etc.) why not also control and offer the tools to create such content... it would go a long way to reducing the friction in some of these marketplaces, where the creative authors can seamlessly distribute their works via the Apple channel. This would allow them to target all strata of their verticals that they want to sell into, and these offerings create a self-reinforcing viral effect. This said, I am not sure how comfortable I am with a company like Apple holding such a dominant position in the market based on their historically closed nature.
And this is where I come to why I think it might not work, and that is due to cultural issues between the two companies. Adobe has been making GREAT strides to become a much more transparent and open company, they are investing heavily in contributing open source code and really seem to be figuring out how to be a good corporate citizen while still turning a profit. Apple, not so much. They seem to still cling the old-school closed source mindset, where everything is shrouded in secrecy and tightly controlled. This does have its advantages, but long term I don't think it will benefit them. So what happens when a company like Apple acquires a company like Adobe with the differences in their respective cultures? I don't think it would be a very pretty picture and could have the potential to destroy Adobe and the value they bring to the table. But from a purely mercenary/capitalistic view I think it would still be in Apple's best interest to do so.
From looking at the Yahoo finance stats today, here are some metrics for both companies. It would seem with Apple's cash on hand they have enough resources to make something like this happen (they have almost as much cash on hand as Microsoft) if they were motivated to do so.
For those Flex developers out there who have not heard of the Flex 360 events, it is a GREAT opportunity to learn more about Flex, share information with other Flex devs and just generally have a great time. I attended the event in Atlanta, and Tom & John put on a great show. The sessions are really informative and pretty informal, which creates a great atmosphere for sharing and collaboration. At this event I will be speaking about Data Visualization and Dashboards with Flex 3. I did a similar talk at Adobe MAX back in 2006, but it was on Flex 2, and geared to a less advanced audience. So for this preso, I am going to have to crank it up a notch and come up with some pretty slick examples that push the boundaries of Flex, and show people how I have been building and teaching dashboard development to other Flex devs over the past couple of years.
It has been almost a week now after my transition off a wintel machine onto my new heavily loaded Mac Pro. Like so many others before me, and the millions who will follow after me, it has been an epiphany.
I have been a hard-core windows guy for the past 15 years, just devouring everything Microsoft. I am/was deeply intimate with almost all of Microsoft's software offerings from their (anti)productivity suites in their Office Tools to their back end server stacks like Exchange, SQL Server, Biz-Talk, Commerce Server, IIS, GreatPlains/Dynamics, Sharepoint and more. I also exclusively developed in MS frameworks like VB (from years ago), C# etc.. all designing and developing business applications. I was one of three Principals at a medium sized local MS Gold Partner consulting shop in charge of delivering multi-million dollar custom MS applications leveraging technologies in the above mentioned stacks. A few years ago I slowly started to drift away from MS, the first material separation occurred when I adopted Adobe Flex as the primary development technology for my new startup and was just shocked with the refreshing change of the "open" community nature that Adobe adopted in its beta.
Now a couple of years later, with Apple making it almost impossible to ignore their presence with their adoption on Intel chipsets and the ability to run Windows side-by-side with OS X I made the leap. What is amazing, is that leap is a more like a short step, the effort involved to make the switch is getting smaller and smaller. I can't say enough good things about the quality of the Apple hardware itself, the 8-core is a dream, and even more importantly OS X feels like what a computer is supposed to feel like in 2008. Spotlight (OS X's universal search tool) is just so easy... you have a thought like "where is file XXX" and you just type "XXX" into spotlight and there it is. No more waiting several minutes while Windows search agonizingly moves through your non-indexed files at a snails pace (although I am not sure how fair that is since I was not using an 8-core processor with 14GB of RAM on my wintel box.) Lots and lots of little things are just so much more seamless and intuitive with OS X.
This is not to say it is all roses, there are little things here and there that I miss from Windows, but overall the experience is such that you feel like you can forgive OS X for its shortcomings, while you want to blame Windows for theirs. To Microsoft's credit they still have a few amazing products that I have mentioned before, like Visual Studio and SQL Server 2005. Microsoft also has the very unenviable challenge of trying to support an OS that is 20+ years old and has successfully maintained backward compatibility on a ever shifting hardware platform that has to support billions of permutations of hardware configurations. Apple on the other hand got a fresh start with OS X and they completely control the hardware platform, which is a much easier proposition. It will be interesting to see how Apple is able to successfully avoid the bloat that will come with time as their adoption rates increase and the need to support backward compatibility becomes more prevalent.
So my message to any windows users considering the switch to Apple is to go for it, you will not regret it in the slightest. The only issues I have found thus far is that GoToMeeting requires Windows to host meetings, and QuickBooks online has tied themselves to ActiveX technology via Internet Explorer. For both of these I simply run VMWare fusion, although I will probably migrate to Adobe Connect for meetings, and I am hopeful Inuit will release a Flex client for QuickBooks sometime in the near future with their QuickBase announcement.
Help, I think I have become addicted .... to Apple.
This weekend, while out with my wife (sans the kids), I made my SECOND trip in 2 days to the local Apple Retail Store. I left the store about $500 lighter after picking up a bright pink Nano for my wife and an Apple TV (at $229 how can you resist??) At this point I can just feel myself getting inexorably sucked into the vortex of quality, attention to detail, and desire that Apple has come to embody in most of its products. It started a couple of years ago with my MacBook purchase that was simply used to make it easier for me to test our website within safari. This was followed up a few months ago with an iPhone purchase, under the auspices of keeping up to speed on current UI and usability trends in the industry. Now my addiction to apple … I mean research … has me buying iPods like candy and buying devices I didn’t know I had a need for. Next up is replacing my aging P4 with a brand new Mac Pro 8-core with some serious memory (12GB should do.) After buying the iPhone I was truly hooked… there is something about the products Apple produces that creates this incredible emotional desire for “more of that” (at least for tech people like me.) I commented to my wife that the desire I have for Apple products is quite similar to what I witnessed in her when we walked into the Louis Vuitton store and my wife was ogling a pair of $1,200 shoes. It is really an admirable and amazing feat that Apple has pulled off, by focusing on quality and attention to detail at every level from product design, implementation, to even the jewel like packaging materials, they have created a desire for their products that I have not experienced with any other technology outside of the lust people feel for cars like BMW, etc. Apple doesn’t get it right all the time though. On OS X I still can’t understand their fascination with spawning windows like rabbits in heat, and on a much more trivial note the shopping bag that the Apple Genius put my purchase into required an instruction book to figure out how to carry. It was this weird contraption with two separate ropes going through a total of four riveted holes in the bag… I wasn’t sure if it wanted to be a knapsack, hammock, or some weird S&M device… Walking through the mall I constantly found myself trying to figure out how to hold the damn thing properly… I think they got a little too clever for themselves on that one.
Okay, back to my addiction…. Yesterday I plugged in the Apple TV to our widescreen HDTV in our bedroom, within 10 minutes I had our modest iTunes collection of about 3k songs and our photo library of about 2.5k pictures streaming from it. So last night my wife and I sat down to “rent” a movie, I was a little disheartened to see that once we started watching it we only had 24 hours to finish it… I wrongly assumed it was “ours” for 30 days. That issue aside, we never even got to the movie… We became so fascinated with watching the slideshow of our photos and listening to music. It was an amazing experience for me… we had about 7 years of photos from before our wedding, various trips to Tahiti, Hawaii, coast of California, the birth of our two sons, etc… It was just amazing to watch and recall. It gave me a whole new appreciation for taking photos, as I was completely engrossed and entertained. It gave my wife and I an opportunity to reminiscence and connect at a level that so far eclipsed just watching a movie together. After a couple of hours I ended up knocking off and going to sleep. This morning I found out my wife stayed up past midnight watching our slide show.. Now I am not sure how entertaining this experience would be after seeing these photos for the umpteenth time, but I can tell you it was a real eye opener for me in terms of its intrinsic entertainment value. When we finally get around to watching the movie we rented and delving into some of the other features of the Apple TV I will report back.
After the response I received on the first release of the Gauge component I thought it was time for an overhaul of the code since this original code was written when I was learning Flex back on the alpha bits of Flex 2.0. Since that time Flex has moved on, and I have learned quite a bit.
This version of the component is a complete re-write of the code and is vastly simpler and easier to read/extend. First a thanks to Peter Ent, as his stab at a gauge was infinitely better thought out than mine and much more compact, the component code is very close to his, with a couple of modifications. The other bigger, and what I consider very significant change for this component is how it leverages Degrafa… which if you are not familiar with and you are doing any component development you are doing yourself a disservice by not taking a close look at it. I used this little mini project as an excuse to really dig in and find out what Juan, Jason and the rest of the Degrafa team had been working on since they seemed to be popping up everywhere.
When I dug into Degrafa I was REALLY impressed at several levels. Not only are the examples just plain sweet visually, but the framework itself is very elegant, compact, and infinitely extendable. In this version of the gauge I built two skins completely in Degrafa and MXML markup, you can toggle the skins and they will still respect the color of the styles you choose. BTW, the skins can be set via CSS, and you can have separate skins for each part of the gauge (bezel, face, pointer, center, indicators.)
The beauty of this approach with Degrafa is three fold. First I am using MXML to create complex geometric relationships which is infinitely easier to do in markup versus procedurally because the markup itself creates visual relationships through the inherent nesting and grouping structure of XML. Second, Degrafa does a great job of leveraging Flex’s binding mechanism, which in my opinion is one of the most powerful things within Flex. Finally the workflow is vastly improved, I can do everything from flex builder and not jump between Flash for building vector assets and exporting to symbol .swfs etc…
On some later post I will probably dive into the framework itself, since I ended up having to extend it in a couple of areas and it only took me a few minutes to do so. For example the “tick” marks you see on the gauge I ended up copying the VerticalLineRepeater which extends the base Repeater class, and within 20 minutes after modifying a few methods and adding a couple trig functions, I had this arc of lines that I could declare in MXML… I remember the first time I did that in the original gauge component it took me hours to fine tune procedurally via the API.
At Juan’s urging I wanted to get this up so it could be shared with the community, as such the code might stand a little clean up here and there, but overall it should be pretty easy to follow. I am also going to be writing an article for InsideRIA that goes into all the gory details of building out this component with Degrafa, which was actually quite simple and very enjoyable.
---------------------------------------------- Caveat... The tweening of the pointer is a little flakey, as I threw it in at the last second, and I need to do a better job of handling the rotate effect and updateDisplayList collisions.
Update: The newest version of this component can be found here.
Well it looks like i have been accepted into the iPhone SDK beta developer program.. I must say that thus far the experience has been far more like a Microsoft Beta than anything else, where you are made to feel privileged to have been accepted after jumping through a corporate bureaucracy.
I am not sure how widespread the program is now, potentially they are allowing everyone in. What was odd though, is that last week I got an email requesting faxed copies of my articles of incorporation for BrightPoint Consulting (the company I registered under) which I faxed over. Just a few moments ago (a week later) I receive an email telling me that upon signing the license agreement and forking over my $99 I would be enrolled. I promptly did both, and now I am an "official" iPhone developer. I find it odd that it required such a manual process... I would assume this is pretty manually intensive if they are having humans read and correlate faxes to each developer account.
Last week I downloaded the latest bits from the second release of the iPhone SDK beta. I see that Interface Builder is now included, which is supposed to be the "magic sauce" for creating UI' s in Cocoa applications. But as I had thought, it still requires quite a bit of work to set up an application. The good news is that it appears that there is finally some documentation on the JavasScript DOM api for touch/gesture events. I planned on exploring that a bit further when I could carve out some time.
I will post again when I receive the SDK if there are additional resources provided outside of what everyone else see, and if my sharing does not violate some license EULA.
Well, the time has come for me to give back a little to the community from which I have learned and benefited so much. People like Ely, Doug, and too many others to list have been a source of inspiration and a repository for useful components that I have used across many projects.
This gauge component actually stems from some of my first work with the beta bits of Flex 2.0 over two years ago. For business and IP reasons I could not share this code, but now as conditions have changed I can offer this code to the community under an MIT license. It is far from a polished component, but the foundation is there. Follow this link to BrightPoint Inc. to go see the gauge in action and right click for view source.
Some of the things on the to do list will be the following, based on interest from the community and feedback.
1. ASDocs (duh...) 2. Exposing the .swc skin more easily so all the gauge parts can be swapped via MXML or at runtime. 3. Cleaning up some of the min/max label stuff (try clicking on the radio buttons at 5 and 8 o'clock.) 4. Providing the user a way to input values via scroll-wheel our mouse.
At some point I might create a commercial version of this component, but everyone is free to use this code in whichever way they see fit.
Any suggestions/comments for improvement are welcome.
Update: The newest version of this component can be found here.
Today I was troubleshooting a bug where items weren't not being removed from a Flex DataGrid the way I expected them to. What I discovered is that in this particular case my laziness in abusing the ArrayCollection was causing an unobvious (to me) bug.
Here is the simplified code that looks for a match to remove items from an ArrayCollection (yes I could use a filter, but that doesn't TRULY remove items from the ArrayCollection.source, and I can never remember the 5 lines of code I need to create one correctly.) So this was my first attempt at removing items from an ArrayCollection.
for each (var foo:String in ac) { if (foo.charAt(0)=="f") ac.removeItemAt(ac.getItemIndex(foo)); }
Now, what would you expect that trace statement to output? Personally I expected to see a big "0", but alas the ArrayCollection is not truly keeping proper indexes as iterates through its for each. Realizing that this was probably an index issue with the iterator I wrote the following which works correctly as it backs down from the last element, thus not distrupting the index as it moves backwards.
for (var i:int=ac.length-1; i>=0; i--) { if (ac.source[i].charAt(0)=="f") ac.removeItemAt(i); }
The above code does what I was intending, correctly. I guess a lesson learned on thinking that Flex did EVERYTHING for me... guess I can't be a completely lazy programmer.
