Sunday, May 31, 2009

TcozTwitter: A Twitter Client using Adobe Air and the Flex Mate Framework - Day 3

TcozTwitter: A Twitter Client using Adobe Air and the Flex Mate Framework - Day 3

As @lancearmstrong says, "onward".

This is a continuation of TcozTwitter: A Twitter Client using Adobe Air and the Flex Mate Framework - Day 2, in which I decided to complete a number of technical exercises by building a Twitter desktop client using the Twitter API, Adobe Air and the Mate Framework.

This time around, I completed two major steps: the full parsing of a tweet with all associated data (so that I can display the message info finally), and preliminary incorporation of ads, which I tried to make as unobtrusive as possible.

Parsing the tweets turned out to be easy. If you want to get an idea of the XML that makes up a tweet, take a look at this file, which is a dump of the raw XML returned from the service call I discussed in the day 1 article. Make sure you view the source of the page; if you just click the link and view it as a regular web page, it'll look like an endless string of jumbled user data.

If you look at the XML, you see that a user's data is actually represented by an element called "status" that contains two parts; a top-level set of children that holds the message info, and a child element called "user", which contains all the user info, like name, id, number of followers, etc. Manager_Tweets gets fed all that XML when it returns from the EventMap handler (see days 1 and 2 for an explanation of this), breaks it up into an array of "status" elements, and pushes them onto Model_Tweets as an array of new Data_Tweet objects. So, whenever I want to grab the current list of public tweets, I just have to call Model_Tweets.getInstance ( )._publicTweets, and I'll get back an array of Data_Tweets. As I get more tweets, I just keep pushing them onto these waiting arrays on Model_Tweets, so I get a running list of tweets for the entire user session. As I work with different kinds of tweets, like Area, Trends, and different accounts, I'll just add more service calls to the EventMap, add more arrays to Model_Tweets, and push new Data_Tweets onto them.

Each Data_Tweet object gets one "status" element, which it cuts up into two XML fragments: the message, and user, parts. I then iterate each of the child elements in both parts and push the values onto objects, with the element names as the property names. The end result; each Data_Tweet exposes two objects, one with all that user's message info, and one with all that user's identity info.

The code in Data_Tweets that does the chopping up looks like this. Note that I've created two arrays filled with the property names I'm interested in, then I iterate those arrays, using the property names as the identity of the XML elements I want. This is sort of a lazy man's way of pseudo-typing data; eventually I'll probably just use real properties so that code hinting and such reveals the properties like any other typed object. But for now, this is a good, fast way to get the job done, and I am still using the actual property names instead of something made up.


_messageInfoProps = [ "created_at",
"id",
etc. etc. ];

_userInfoProps = [ "id",
"name",
etc. etc. ];

_messageInfo = new Object ( );
_userInfo = new Object ( );

var xml : XML = XML ( data );
for ( var each : String in _messageInfoProps )
_messageInfo [ _messageInfoProps [ each ] ] = XML ( xml [ _messageInfoProps [ each ] ] ).text ( ).toString ( );

var userPropsList : XMLList = xml.user;
var userPropsXML : XML = XML ( userPropsList.toXMLString ( ) );
for ( each in _userInfoProps )
_userInfo [ _userInfoProps [ each ] ] = XML ( userPropsXML [ _userInfoProps [ each ] ] ).text ( ).toString ( );


There's really nothing to it; get the XML from the Mate handler, pass it to Manager_Tweets, which breaks it into a list of "status" elements, then itereate that list, feeding each element to a new Data_Tweet, which parses the data into the pseudo-typed objects, then push those Data_Tweet objects onto a waiting array in Model_Tweets. I now have a subsystem to receive, parse, and store, tweets. For now I'm just using public ones, but I'm willing to bet that account-specific ones are no different.

Now onto the money shot: ads. ARGH, I know, god damn ads. But c'mon; I'm investing time and effort, not to mention using software and hardware I purchased, and so on; it'd be nice to actually make some money doing this, or at least, show that I understand how to do it, which is a great demo item for getting contract work.

I decided right away, that however I implemented ads, I wanted to make sure:

- The ad impression (an industry term for showing an ad) is immediately visible, but unobtrusive.
- There is only one "forced impression" per user session, and it won't last more than five seconds.
- There needs to be a way to view the ad again in case the user is interested.
- I want to be free to tweak this at will.

The implementation:

- The ad appears at the bottom of the app for five seconds, then fades out.
- After fading out, the ad is replaced with a very thin, translucent bar at the bottom of the app.
- This "ad bar" displays a message "Click to see the [name of advertiser] ad".
- When you click the bar, it shows the ad again for five seconds. If you never click it, you'll never see another ad.
- When you click the ad, it opens a browser window for the target URL.

Regarding freedom to tweak, that means, not compromising this unobtrusive design in any way, which means, I can't pander to the requirements of any particular ad agency. So, I actually set up my own ad server. I'm using the latest version of OpenAds, which is a free and full-featured ad server, used by such techno-luminaries as TechCrunch. I've worked with OpenAds before, but never actually built out an instance of it. I was pleased to find, OpenAds is simple to set up and simple to use. Just go through the instructions and tutorials carefully, and you'll have a full-featured, industrial strength ad server, with campaign provisioning and tracking, even marketing integration, all ready to go. From Flash, you make XML-RPC calls to the OpenAds server, it runs its logic, and returns an ad it selects as an XML response containing the info to display, like URL of the ad, target when you click it, etc.

To get started, I have a friend that owns a business called Genius Ride; he leases smart cars, delivered right to your door. I took his ad, dumped it into the OpenAds system, and set up an advertising campaign with it. The Flash client calls OpenAds when it starts, requests an ad (which at this time always returns genius ride, because it's the only campaign I'm running), and displays it as previously mentioned.

The screenshots below show the current in-progress state of the TcozTwitter desktop client.

As always, thanks for visiting.



With ad:




After ad fades:




Expanded:


Friday, May 29, 2009

"Buffering Video..." takes a hit: Akamai offers Flash Media Server 3.5 Dynamic Streaming

Akamai has recently announced support for Flash Media Server (FMS) 3.5 dynamic streaming; for the video developer muggle, this basically means that while watching a video, if your connection degrades, the player, coupled with the backend intelligence, can switch you to a lower bitrate video transparently. Although a lower quality video, the viewing experience will be interrupted considerably less--ideally, not at all--by buffering.

You can read the announcement here.

You can also see it in action at streamflashhd.com. If you have a decent connection, you can watch videos encoded at bandwidths from 500Mbit to 3000Mbit, and the quality will toggle as bandwidth fluctuations happen. If you have a bandwidth throttler, Charles, Fiddler, whatever, this can be an interesting thing to check out.

This is an opportunity for the higher end Flash developer type to differentiate him/herself from the rest of the pack, which is oh-so-important in the indie software developer world. Read on...

My clients are primarily in the entertainment and media industry; I build widgets, sites, applications, whatever they need. Frequently, this means dealing with video, and if you deal with video on an industrial level, you will sooner or later (probably sooner) run into Akamai.

I don't mind it at all. Akamai has a developer kit that makes it pretty easy to hook into their streams, with passwords, bandwidth detection, whatever (in fact, in their developer sdk there is a class, HTTPBandwidthEstimate, which is a generally useful utility). You can find more out about how Akamai helps Flash developers get up and running with their technology at their Flash developer page.

Anyway, just knowing that--and being able to prove it--has landed me work. But now, Akamai offers more.

Video delivery has become a lot more sophisticated in a very short period of time. Even just two or three years ago, it was enough to serve a catalog of video in a generic player as long as it was relatively stable; all the things we see now, like seeking in on-demand video streams, ways to interact with the player, HD video over the web, and all that, were generally avoided because it was VERY difficult to get right; users didn't have the bandwidth or patience for the buffering, complex video infrastructures are difficult to implement; a video player that does nothing but break when you touch it is just frustrating, and so on (and how many of those have we seen). Nowadays, users want more; ways to interact with video, like commenting and clip sharing, and of course, a smooth, uninterrupted, and easily seekable, experience.

Akamai has always been out there though, working to make enterprise-level video serving less of a headache. The principle is pretty simple. You are not a video delivery company. We are. Pay us to house and expose your video, use our services, feeds, and developer kits, to make them available to the public. Or, try and do it by uploading all your video to in-house web servers, you tube, whatever. That may work for a small effort, but if you have a lot of content and need it monitored, maintained, looked after every day...good luck.

That's not to say Akamai is without its issues; I've heard grumbling about their downloader, and network outages have made many a corporate manager sweat all over their cel phone. Say what you want though, they've survived and grown in the industry, and like I said before, the heavy hitters use them liberally. Whatever they're doing, there's enough value for people to want them to keep doing it.

As an entertainment/media focused developer (which so many Adobe-based developers are), having worked with Akamai is a powerful resume item. Frequently, if you hear "video" in a contract, you can expect it to be followed by something like BrightCove or Akamai. So like I said before, if you have experience dealing with these video hosts, you've got a leg up.

Now, if you have that background, AND know how to take advantage of Flash Media Server's dynamic stream switching, you're at the top of the industry. FMS 3.5, as far as I know, was announced in November, so there's been opportunity to get your feet wet for about half a year. You can read about the release of FMS 3.5 here (note that the current version is 3.5.2, which is a maintenance update):

So Flash devs, get to the Adobe FMS and Akamai sites, and start gearing up; time to break out of the world of banner ads.

As always, thanks for visiting.

Thursday, May 28, 2009

Amazon adds Browser Access to Kindle User Highlights and Notes

Amazon continues to enhance the Kindle experience. I got this email a little while ago:

--------------------------
Dear Amazon.com Customer,
Our customers have told us that they love being able to add highlights and notes to their Kindle books. We want to make it possible for you to access your highlights and notes directly from a Web browser too. So we've released http://kindle.amazon.com, an online tool that enables you to do just that.

To try it out, go to http://kindle.amazon.com, sign in with your Amazon account, and simply select one of your books where you have added highlights or notes.

We hope you enjoy this new feature. If you have feedback please send it to us at amazonkindle-feedback@amazon.com.

The Amazon Kindle Team
---------------------------

Tellin' ya, I love the Kindle. The more I use it, the more I know that anything remotely resembling a backlit laptop, netbook or otherwise, isn't a substitute. You can use it anywhere and it's never inappropriate, because for all intents and purposes, you're reading a book or a notepad. I only refrain from using the keypad now and then, like in crowded, subdued situations, e.g. when you're in a conference session, around people eating dinner in a restaurant, etc; it can be distracting.

A while ago, I got into an online back 'n forth about the usability of a Kindle compared to a real book. One of the forum commenters said that it's harder to take notes on a Kindle, and that he'd rather just use a book.

I respect books, I own a lot of them; but fact is, we waste a LOT of paper on them, and many kinds of books aren't intended to convey that aura of "book". Technical manuals, programming books, general paperbacks, reference guides, blogs, etc., are about conveying information to me; I just want the content. For that sort of thing, if you can make a better book, which makes annotation, highlighting, clipping, bookmarking, and searching faster and more robust, you've got my interest.

The highlighting and annotation feature of a Kindle is essentially, pushing a button and moving a cursor. It can be a little awkward across pages, otherwise it's easy and fast, certainly faster than carefully drawing long horizontal lines. Clipping articles and taking notes is essentially the same thing; hit Menu, select Add Note or Clip Article, and it's done. There's keyboard shortcuts I'm sure, but the menu options don't bother me, so I haven't really explored them.

What happens to these notes, highlights, and clippings? They get stored in a sort of "book" of their own. On your main book list, you open "My Clippings", and lo and behold, there they all are. This information is actually saved to a .txt file on your Kindle (right in the root directory), so if you want, you can even move it to your computer and print or edit it. I find this VERY handy. If I could print right from the device that might be welcome, but again, the Kindle is supposed to be a better book, not a laptop or tablet; I appreciate the distinction.

All this data gets backed up to your Kindle account online via the free "Whispernet" 3g wireless access you get with the device. So, if you ever lose your Kindle, or want to view the information on a different Kindle, your good to go; just sync it to the new device. I was disappointed to find that "My Clippings" didn't seem to be on the iPhone though. Well, at least I can grab the txt file...

...no need anymore. Now I can just use any browser-enabled device, access my Kindle account, and get to My Clippings. Here's a shot of it on the iPhone, this not being possible until today.

Note: To get it REALLY right, you should just be able to access "My Clippings" from any Kindle reader, iPhone-based or whatever. It's still not on the iPhone native app as far as I can tell.

The below shows a book I read on my Kindle, which had a music exercise (you had to write down the key a piece is written in based on a the chords used to create the music). I just did it with the keypad on the Kindle while on the subway. Below you can see the chords I entered (got 'em all right btw yay).


TcozTwitter: A Twitter Client using Adobe Air and the Flex Mate Framework - Day 2

This is a continuation of TcozTwitter: A Twitter Client using Adobe Air and the Flex Mate Framework - Day 1, in which I decided to complete a number of technical exercises by building a Twitter desktop client using the Twitter API, Adobe Air and the Mate Framework. 

If you recall, last time I was able to successfully make a call to the Twitter public data feed that returns the last 20 public tweets, and display them in a list in my client. It looked like this:




So, clearly I've got a ways to go, but certainly this represents a major element of the development; get the data, parse it, bind it to a list with the UI elements to properly display the data. Keep reading; the app doesn't look like this anymore.

The next step was to clean up the UI a bit, which is what we'll look at here. Although not a programmer as far as I know, iJustine, an internet/lifestyle tweeter and blogger of some notoriety, unknowingly gave me a suggestion for how to proceed. She said that she couldn't change the background color of her tweet display; I assume that if she wanted this feature, it would probably be a popular one, so I decided to implement a way to skin my Twitter client at a rudimentary level. 

And I must say, Mate made it pretty easy to do. I think any framework would have, being as the task of reading in config data is the same as reading in any other kind of XML data, and I had already set up a call/receive pipe for the public tweet XML, so ideally I should just be able to use the same exact technique, and that's exactly how it panned out. 

In the last article, I showed the fragment of Mate code (which is just MXML) that retrieved the public tweet feed. The code below does the same exact thing, except it hits a relative file, config.xml, instead of a remote service. 

The Mate formula for hitting data and storing it seems to be this:

- Create your Event class (in this case, Event_Config). This is a standard Flex/Flash event, nothing fancy. It should have a static constant (at least one, though it can have several) with the name/type of event you want to dispatch (which is always a best practice for events not matter what environment you're in). 
- Create a Manager class that will be passed arguments when the event is handled by the EventMap. This means creating at least one public method on the class. Interesting that none of the examples I have seen ever suggest exposing these public methods via an interface...which is something I'll comment on later. I used Manager_Config.
- Create a Model class, I like to use singletons, to hold the elements the Manager parses out.
- Tie the Event, and it's handler, to the Manager, via the EventMap. 
- Dispatch your event as needed, remembering that in Mate, events have to bubble to the EventMap, which initially, will be located in the top-level MXML file. This means that you can either only dispatch from an object that participates in the app-level DisplayList, or by using the GlobalEventDispatcher workaround detailed in my last article. 

The code fragment that does the above looks like this:



<mate:EventHandlers type="{Event_Config.GET_CONFIG}" debug="true">
<mate:HTTPServiceInvoker url="xml/config.xml" resultFormat="xml">
<mate:resultHandlers>
<mate:MethodInvoker generator="{Manager_Config}" method="storeConfig" arguments="{resultObject}" />
</mate:resultHandlers>
</mate:HTTPServiceInvoker>
</mate:EventHandlers>



So, when the app starts, I want to load the config.xml file, which I do like this:

- In creationComplete of TcozTwitter_AIR, I dispatch an instance of Event_Config, using type Event_Config.GET_CONFIG. 
- This bubbles to the EventMap handler MXML tag, which makes the call to the HTTPService, receives the result, and directs it to the Manager_Config class public method, storeConfigOptions.
- That method takes the result argument, parses the XML, stores the elements on the associated properties in Model_Config, which exposes them for use throughout the app. 
- At the appropriate times, the UI elements, like Tweet backgrounds, apply their colors as style elements. 

iJustine, there ya go. Again, more or less the same exact idea as grabbing tweets, or any data it would seem. 

Some observations on this flow:

This is the way the tutorials, and even more advanced samples I've seen, prescribe retrieving service data. Typically though, I would not use the HTTPService MXML tag (or any such MXML based mechanism for that matter), I'd forward the handling to a class using the Command pattern. I've read some ways to do this in Mate, but it seems that it's not the common practice; using the EventMap handler as the Command, and distributing the management of the result to Managers, is the norm. For basic things, this might be ok, but what if you have a complex command of some kind that runs several service calls? The MXML could get very bulky, or you'd need multiple handlers, which would seem to make atomic operations difficult to manage. In fact, I think that in an app of any size, EventMaps could get bulky fast, which would cause you to start thinking of your app in terms of layers of EventMaps. Conceptually, perhaps this isn't that much different than thinking of your app in terms of layers of Mediators in PureMVC, but plain old code looks a lot leaner 'n meaner to me than all those MXML carats, quotes, equal signs, and so on. 

Based on that, I'll probably only use an EventMap handler tag to initiate a command, like calling a service, if there is only ONE simple command and result. Anything more and I will broker it to a Command class, which fortunately, I know how to make dispatch events now (same as any non-view class, use GlobalEventDispatcher). I know Managers could be thought of as Commands, but they're really not, see below. 

Another observation which I touched on before; use of MXML tags instead of instances of classes lets developers avoid thinking of factoring their class hierarchies and exposing their public members using interfaces. I understand that the classes that back the MXML tags are well factored in this manner, but for example, in PureMVC, part of it is implementing the Command pattern as the "C" in "MVC" (control). As you may know if you've gotten this far, the Command pattern uses an interface to expose "execute". If you use a Template pattern (so you create a base class that implements the interface and you extend that base class whenever you create a specific kind of command), you've just made all your commands polymorphic, which lends to things like "undo", command stacks and chaining, etc. Mate doesn't seem to have this concept built in. 

Good thing, bad thing? I don't know. To me, one of the points of a framework is to prescribe patterns of development for common application tasks, like executing logic. If you use Cairngorm or PureMVC, all I need to know is that a developer understands the framework, and I know that when I say "call a service, handle the data, store it", that the developer--in the case of PureMVC--will dispatch an event to a Mediator, which will send a Command Notification to the Facade, which will execute the a Command class, which will make the service call and handle the result, then broker that result to to a Proxy class, which will parse the data and store it on the Model, which makes it available to the application. 

It may sound verbose, but it's explicit and actually saves a lot of time; I KNOW how the developer will perform the task, and if you're managing a bunch of them, that's a GREAT thing. Using Mate, it would seem that I'd have to lay out the flows myself and communicate them to the team as standards, and make sure they were doing it. With a team of PureMVC junkies, we may quibble about the best way to cut up an application with mediators, or the best way to represent a Model via a Proxy, but otherwise things like views calling views or views talking directly to models will never happen; if it does, the fix is to educate the developer on the prescribed mechanisms of the framework. 

Anyway, enough of that. The bottom line is, you make edits to an XML file, restart your app, and voila, there are your colors, nice gradients and all that. Note that an XML file is not how I intend to keep this; settings is a great opportunity to take advantage of Adobe Air local storage. But for now, until I establish a base set of requirements for preferences and settings, it's easiest to just keep it in something abstract and lightweight, as opposed to building out the settings UI now, knowing that it will just change drastically several times before I have a locked feature set. 

One other thing I took advantage of: Air's ability to have the app resize like a desktop app, and reflow the layout. This is a great thing IMHO; if you resize the Twitter HTML page, the tweets don't reflow to take up the entire width, they stay in one column. My client reflows the tweets to take advantage of the entire space, letting you see more tweets without scrolling. 

Next step: incorporating the metadata associated with a user, and getting that message field populated. 

Screenshots of the latest client below, showing the application of the config.xml, and the resize-reflow. As always, thanks for visiting.







Wednesday, May 27, 2009

Meebo Chat: browser-based universal client. I use it, I like it. The new notifier has Email notifications now...Windows only though (argh!)

I'm a longtime fan of Meebo, click here to check 'em out. In a nutshell, they are a browser-based chat client that allows you to connect to just about any chat service in a single view: Yahoo, AIM, Jabber, Facebook chat, and more. You can use them all nice 'n neatly, with all your contacts mixed 'n matched as needed, in a single browser tab.

Meebo has announced the following via their blog (which pops up in a chat window when you start Meebo), this version shortened to highlight the important bits:

"Mail notifications for the notifier (plus proxy and ssl!)

We have something pretty cool to announce - the Meebo Notifier now supports email notifications!...Meebo Notifier for Windows can now alert you when you get new emails for your Gmail, Yahoo, Hotmail, and AIM accounts.

Whenever you get a new email, the notifier will show a popup notification just like it already does for IMs, and will also create an icon in the system tray next to the Notifier icon (as shown below) so that you can easily access your email accounts.

A simple click on a mail notification or its corresponding icon will take you right to your mail web page.

By the way, in case you missed them, we introduced a couple other new features in the Notifier a few weeks ago: HTTPS support...Proxy access."

The notifier is a native app, which at this point, unfortunately only runs on Windows, so I don't use it (MAC CLIENT PLEASE). It looks like this:






Why I started using Meebo is actually sorta funny. I was on a big account in NYC--you've all seen the work more than likely--and needed to communicate with some developers about external video feeds.

Naturally, you send URLs back and forth; we were using AIM to do so. Security had decided they didn't want URLs going back and forth through their routers; don't ask me why, it's ridiculous I know. Everybody got around it just by typing, "go to www dot domain slash dot" and so on. Dilbertian corporate thinking at its best; hinder an employee's ability to do a job, call it security, and check something off your list.

One day I was walking around the floor, and an employee was using some browser-based chat client. I saw a URL pop up in one of the chat windows.

I queried, "WTF is that?". He replied "Meebo. It runs over HTTP/port 80 so security doesn't block it".

Five minutes later I had a meebo account, and I've been using it ever since; that's probably at least three years, maybe more.

Meebo has evolved quite a bit since I started using it as a humble way to beat corporate security. The notifier is a recent thing (but again I don't use it MAC CLIENT PLEASE). It also didn't have advertising; it does now, and I must say, if you must have advertising, their model is an example of how to do it without pissing off your users. Ads appear as a slide-up panel at the bottom of the window, which you can click an arrow to close into an unobtrusive bar at the bottom. They tried one or two other more intrusive models, users didn't like it, they ditched it. We recognize they're a startup and need money, but if any service compromises gets pushy about premium access by destroying the original experience, I'll drop you the same day.

Pic below:




They've also got a browser-based Mobile client, which works fairly well, a screenshot from the iPhone of the contact list is below; you sign in, you see your contact list as pictured below, you tap a contact, you go to a window dedicated to that conversation. You can run multiple conversations by tapping back 'n forth to the contact list.




You can set some nice options, like backgrounds and such, turn notification noises on and off, add/remove accounts, use hide/invisible on each of them, use custom status messages, review chat history, and so on. All the things that you'd expect these days from a chat client. Meebo even implemented file transfer a little while back.

Meebo also has a nice little service feature; you can actually create your own Meebo room on your own web page. Think of it as a turnkey chat solution. You go to their Meebo widget configurator page, set some options, and blammo, you have a dedicated Meebo room that other people can visit. If you look at the first page, you can see the un-blurred "tcoz's room" entry at the top of the contact list. When you double click it, you see this:




Notice the "embed" button at the top. When you click it, you get a window that lets you copy markup for pasting into your own web page, and blammo, your site is chat-enabled with your own Meebo room. I don't use them because I dislike the advertising integration, and there may be a way to turn it off that I haven't found, but if you're looking for something fast that works, it's a good option.

So, Meebo has gotten more interesting. If you're on Windows, try the notifier.

One more time...

MAC NOTIFIER CLIENT PLEASE ok plz ty.

As always, thanks for visiting.

Monday, May 25, 2009

TcozTwitter: A Twitter Client using Adobe Air and the Flex Mate Framework - Day 1

QuickStart: This subject of this article is a project that satisfies three goals:

- To complete a practical exercise of using the Twitter API.
- To create complete a practical exercise of using the Flex Mate framework.
- To have a Twitter desktop client that works *exactly* the way I want it to.

To that end, I decided to build a Twitter client, using Adobe Air and the Mate Framework.

Onto the discourse...

Why this group of technologies?

Twitter: If you're reading this article, I don't have to tell you why it's important, as a developer, to do more than dabble with it.

Air: I really like building Air apps. At it's most basic level, you could say that Air is Flash running on your desktop in a native dedicated runtime manager (called "Air"). Freed of the browser sandbox, Air has a lot of capability Flash doesn't, like real local file access and data storage, and doesn't suffer from some of the general performance issues of the browser-based Flash player. The NY Times has dumped Microsoft Silverlight in favor of Air, as has the Major League Baseball tech organization. It's a pretty exciting technology, and if you're already good with AS3/Flex, the learning curve is more a speed bump than a hill; write one Air app, run it on any machine with it's OS-specific runtime installed.

Mate: I'm predisposed to being dubious of Mate, because I prefer frameworks and patterns that translate to as many technologies as possible, and I prefer to avoid markup for UI layers whenever possible, because it tends to create scripted spaghetti. PureMVC, for example, is easy to implement in just about anything, and inclines the developer to some level of genuine C-style OOP. Mate, on the other hand, is inherently Flex targeted; it makes heavy use of Flex MXML and databinding. But, love it or hate it, I realized a while back that avoiding MXML isn't good for my business, so I skilled up, and these days a lot of people are loving Mate, so I should get a working knowledge--though I will say, this is often the case of things that make a complex technology seem easy, and it all collapses once you hit big apps.

If you want to know more about the Mate Framework, go to the Mate Flex Framework Home Page. There you can find the SVN and/or SWC downloads, tutorials, etc. etc.

Add these three things up, and it'd seem that, if I put in the time, I'll have a pretty cutting edge Twitter desktop client, insofar as the technologies involved to make it work are concerned.

Anyway, down to the bits 'n bytes of Day 1, TcozTwitter. I'll assume you know about things like Flex, working with APIs, and so on.

As I said, I have mixed feelings about Mate; it's true that it's pretty easy to learn and get working, which no doubt contributes to it's popularity. People talk about it like the second coming, and say that it doesn't prescribe a particular kind of development, your app isn't tied to it, etc. But from what I can see initially--granted I'm no Mate expert, but I've worked with other frameworks pretty deeply--this isn't true. Your app is VERY tied to it.

For example, Mate prescribes how you use events in a VERY particular way. Events dispatched directly from non-views (typically "managers" in Mate parlance) don't hit the all-important EventMap (essentially a clearing house for event handling), because in Mate, you bubble all your events up to the top-level application for handling, and bubbling is a function of the DisplayList; non-views need not apply.

There is a workaround; in the non-view, create an instance of a GlobalEventDispatcher and use that to dispatch the event so that it immediately hits the top level app, which contains the main EventMap, but that's not at all what I'd typically do; usually I'd just have the non-view extend EventDispatcher, either directly or in a base class, and dispatch away. I was surprised by this; in Cairngorm or PureMVC, the basis of how you dispatch an event isn't prescribed by the framework; what you do with that event once you catch it is. I guess this is a matter of perspective, and no doubt this statement will annoy the Mate advocate, but there it is.

Note: I don't dislike Mate. It's growing on me. But at this point I still prefer PureMVC. This may change over time, we'll see.

If you'd like to try some Mate twittering yourself, for your first Twitter call, here's a simple MXML fragment showing what to put in your MainEventMap (which is essentially a manager for handling bubbled-up events in the Mate framework):


<mate:EventHandlers type="{Event_GetLatest20Public.GET}" debug="true">
<mate:HTTPServiceInvoker url="http://twitter.com/statuses/public_timeline.xml" resultFormat="xml">
<mate:resultHandlers>
<mate:MethodInvoker generator="{Manager_Tweets}" method="storePublicTweets" arguments="{resultObject}" />
</mate:resultHandlers>
</mate:HTTPServiceInvoker>
</mate:EventHandlers>


Notice in there we have an HTTPServiceInvoker pointing to the twitter endpoint that dumps out the latest 20 public timeline tweets. You can grab them in a variety of formats just by changing the extension of the public_timeline call (instead of .xml, use .json for example). This is strictly preference; I like XML, so that's what I'm using. In addition to this, you'd have to write your Manager_Tweets class, with the "storePublicTweets" method, and dump it onto a model for binding and so on. If you need a primer that shows you how to set this all up (it's very easy), go through this tutorial. I used this as as starting point for my Mate explorations a while back and it was very helpful. While there's certainly a lot more to learn about Mate, understanding how the EventMap works in conjunction with Managers is the most important part, and this tutorial makes it very clear.

With all that understood, my first effort was to take that XML and bind it into a TileList, which has an itemRenderer that receives the individual data objects, which have properties that map to the original XML elements. So, in the itemRenderer, just by setting the image component's source to "data.profile_image_url", and the top text components text property to "data.name", I get the expected result; a scrolling TileList of the latest 20 public posts, with profile images and names.

It's not pretty; I didn't work out the sizing or layout, or scrolling, etc. This is entirely the first step. But hey...I've got an Air client, using the Mate framework, hitting the Twitter API and displaying user data. I'm on the way to achieving the three goals I mentioned at the top of this article.

So far so good. Next step; clean up that UI to display the scrolling list more neatly, and add in the message and metadata to that display of public posts.

As usual, thanks for stopping by. Pic of in-progress client below:




Friday, May 22, 2009

Microsoft's Optical Mouse Blue: Any good?

I've gotten a couple of comments that I take a while to get to the point; I'm abashed, as I did study journalism and was a newspaper reporter for a couple of years.

So I'll put it right out there; if you're mobile and do the kind of work where using the laptop mousepad just doesn't cut it, get one of these new Optical Mouse Blues. I bought an Explorer Mini Mouse (four button, wireless, multi-directional mousewheel) at Staples for 50ish bucks. Thumbs up.

Great features: the new Optical Track Blue technology allows the mouse to track reliably on just about any surface. They say "not clear glass or mirrored", but I use it on a clear glass table and it works fine...not "sort of", but completely fine.

It also has a little "snap in" recess on the underside that allows you to store the USB receiver (which is suitably small), and when you do so, it completely powers down the mouse. This has been a problem in the past; I'd open up my bag, see the mouse laser active, and know that my battery would be on the wane.

And now the discourse:

This blog is about things that matter to me as an independent software developer; part of that means buying tools that allow me to work faster and smarter. Sure, I don't want to have my pants pulled down when I hand over a credit card for new equipment, but if the tool lets me do my job better-faster-stronger, I'll lay out the cash and look forward to the write-off.

I work in a lot of different places; onsite for client presentations, code reviews, and plain ol' hacking away. If you do the same, you can appreciate why I'd be interested in a mouse that supposedly works reliably on more surfaces. Chrome, stainless steel desks, glass table tops, textured counters, granite, and any number of other non-optimal mousing surfaces, can stymie the standard "red" optical mouse. Since I typically don't carry a mousepad in my bag, especially these days when I'm all about traveling as light as possible, I've ended up using a magazine or notepad...which, as you may know, totally sucks.

So I took the plunge and bought one of these new Optical Blue Track things--Microsoft actually made the press announcement in Sept. 2008, see here--and so far, I'm happy with it. There really is a difference. In fact, more of a difference than they seem to think.

Cases in point: my dining room table. It's a textured wood surface. My Logitech laser mouse seems to get hung up on it a lot; I'll move the mouse, the cursor jitters. So I switch to the Microsoft USB explorer (red laser) mouse; better, but not great, and it doesn't have all the extra wheels and such that the Logitech one has. Same for watching TV and mousing on the couch cushions. I always end up just using the laptop touchpad, which even after all these years, I still don't like; gimme a regular mouse any day.

The Blue Track Mouse, as long as I can keep it in more-or-less steady contact, is a rock. Interestingly enough, Microsoft says it doesn't work on clear glass surfaces. I beg to differ; I have a laptop on a glass table that I use for powering my Line6 POD (a digital effects modeler for guitarists), and it works fine. The table is clear glass, there's no tint. Kudos to Microsoft for the warning, but I'm tellin' ya, it works.

And, the blue glow is REALLY cool :)

So there you go; another positive recommendation from this indie software developer.

Pics below:



Wednesday, May 20, 2009

The Facebook "Verified" Apps Program...Should I Do It?

I know Facebook wants me to. But do I? Hmm...

If you don't know what this is all about, Facebook told developers with applications in their Apps directory months ago that they were implementing a "Verification" program that would enable us to differentiate our apps by having them in a paid tier of the Application store. These applications would represent the cream of the FB app crop, and so on. 

Initially I said, "oh yeah gotta do that, anything for more credibility". I love FB development, have a couple of apps out there, and was excited about the differentiation. But I hesitated, then stopped...what exactly do I get, by paying $375 to get my app listed as "Verified"? 

I know they're overhauling the overall Apps directory: all apps get a new profile page with their own news feeds, there's a new Applications You May Like section, an auto-generated list that combines the most popular apps on the site, apps your friends are using (oh great, "Flair"), and apps Facebook thinks you might like, based on what you're currently using...ok, that's all good stuff, it creates buzz, makes it all more visible, etc.

But as far as "verified", aside from saying "I have a verified app" to the world, here's the checklist of "what you get", as far as I know:

- A green check mark next to the rating stars under your app name/icon. 
- A Facebook "Verified App" icon on your about page.
- A "two-bucket boost" in requests and notification allocations, which "continue to be subject to the application reputation system which adjusts allocations based on various user response metrics".
- A $100 Facebook advertising credit. 
- Discounted registration fees to FB-type events. 

Here's a photo of the new overall app listing showing apps with the green check mark, and a photo of the verified logo from an about page:






Yeah, it's a good little kudo. But overall, I'm not going to rush to shell out $375 bucks for this, and I have a feeling many shops that crank out FB apps aren't going to tell their clients, "Oh yeah you GOTTA submit for verification". There's a lot of other ways to get the word out about an app: Twitter, FB fan pages, all the other social network mechanisms, you name it. 

This sort of reminds me of that "Windows Compatible" app signing program that Microsoft ran (or whatever the actual verbiage was); after a while, nobody cared anymore. Install instructions for apps that aren't branded this way warn you that it didn't have this accolade, and just told you to "Proceed Anyway", which is exactly what we all do. I never made an app choice because it had the OS manufacturers "compatible" logo on it.

Facebook also says this:

 "Facebook's Application Verification Program is an optional program designed to provide applications with a way to stand out and reassure users that they will provide a good experience. Users of verified applications can feel confident that these applications strive to be transparent about how they work and respect social expectations between friends."

What about the rating system, the discussion boards you can place around the app, the overall reputation system? If I look at this and see a lot of slag, I'm not going to touch that app. If my friends, or just a lot of people in general, say it's great, I might check it out. It's true, I may be somewhat more initially inclined to give an app a chance if it's verified, if there's no other data available. But I'll always consider what people say more heavily than I will consider any green checkmark. 

Another thing: many, many popular Facebook apps are here-today-gone-tomorrow. Would you spend $375, and wait, to get such an app verified? Probably not. Is that a good thing? Again, a lot of these apps run well and are popular, they're just not built for a long shelf life. I'm not sure that shuffling such apps to the "ordinary" category is the right thing to do. 

I'm surprised to find myself cynical about this, because I think Facebook does a great deal for the indie application developer. You can get an app, with robust social graph integration, into the FB world, for the price of learning their API and building something halfway decent. That's a great deal, both for the developer (exposure) and Facebook (content). 

But I think I'm going to hold onto my $375 and see how this plays out before I submit Planet Sudoku for verification. Even that might be a mistake though, because it's possible that the only time "Verified" will really matter is when it launches, and a little while after. When the novelty wears off, yeah you can still submit, but it might be just to get a verified app on your resume. 

Facebook will undoubtedly shuffle this one around a bit as they get feedback and so forth though...or, if it's just pointless and/or more trouble than it's worth, dumb it down or even abandon it. Unlikely, even very unlikely, but not, imho, in the realm of impossibility. 







The Rebranding of Flex: Back to Flash We Go.

You may have heard that Adobe is rebranding their Flex Builder tool to "Flash Builder". The FlashBlog goes into Adobe's perspective, read more here.

I don't market myself "a Flash guy", even though the majority of my projects are UIs delivered by the Flash player. My brand is "ActionScript developer" with expertise in OOP, widely used frameworks (like Flex, PureMVC, Mate, etc.), and back end technologies that feed the UI (remoting gateways, rest services, xml and JSON feeds, built out of PHP, Java, .Net, Ruby, etc.). I'm good with PaperVision and Facebook development, and can do all kinds of motion and graphic stuff as well, but the latter usually falls under, "yes I can handle that if you need me to." 

Why the distinction? From the perspective of this self-employed indie software guy, three major reasons:

- Type of work. "Flash guys" do banner ads, click-through widgets, simple video players, that sort of thing. It tends to be short-run, short-notice work that commands the lower end of Flash-based developer rates. Lots of pick-up ad agency work, holiday campaign work, that sort of thing. It's sort of like cooking tacos; once a month, if I have the time, it's fun.

- Customer perception. I've heard this so frequently that I just accept it as the truth; a "Flash guy" is not perceived as a serious programmer or technologist. At best, you'll get considered a good designer that can do a little scripting.

- Availability. There are so many "Flash guys" out there it's unbelievable (interestingly, if you're any good at all, even today, there's no problem finding work). But there are very few proven, independent ActionScript developers; I personally know of about five in my area, and we're all very busy. 

In short, the longer term and more interesting work comes if you can brand yourself as somebody that can work with the back-end team to implement a robust interface to the UI, and then build the UI using frameworks and patterns that can be represented as repeatable architectures with consistent implementation methodologies. This is lead programmer/architect work, which is a lot more interesting to me, and of course commands a considerably higher rate. 

A few years ago, Adobe introduced Flex. Everybody thought it was a different technology; it wasn't, it was just a more programmer-centric way of creating UIs with ActionScript and a form of XML markup called MXML. "Flex" is actually nothing more than an ActionScript framework, but like any other framework, it encouraged a well-factored, consistent development methodology. On top of that, MXML could be used in top-level component files to represent where these components got placed on the screen, and ActionScript could be used to populate those components with data in a variety of ways, including databinding (which sort of auto-magically updates the UI as data changes), and so forth. 

The "Flex Builder" was also released as the programming environment for the Flex framework and MXML. It was built on Eclipse, which is a world-class, industry standard programming tool. It has integrated performance analyzers, full-featured debugging tools, and just about everything else a serious programmer would expect to find, and of course, you can use it to build other areas of the same project, like a Java back end. 

Note: you can still build crappy apps in Flex. But, because of the nature of the tool and use of a real framework, it attracted more academic programmers, who usually have more training, or at least interest, in real professional programming methodologies. 

This was extremely well received by the "Flash guys" that had evolved beyond the ad-hoc, inconsistent spaghetti generally seen in Flash widgets. This sort of Flash developer was truly a a professional programmer, but it was very difficult to get a customer to understand why we were different than your run-of-the-mill banner ad guy. 

Flex was not extremely well received by the "Flash guy" designer type, who, from comments I saw at Adobe events and projects I've worked on, seemed to be afraid that they'd have to actually learn programming to continue doing banner ads in Flash. Imagine that.

Of course, the answer is, you need both. I do the heavy lifting as far as programming is concerned. I work with "Flash guys" to create things like sexy loaders and animations, which I integrate into the application. There's room for both kinds of developers, and Adobe managed to pull this off by having the "Flex" developer, and the "Flash" developer. Customers have come to understand the difference, which is why you'll see people looking for one or the other depending on what they need. 

But now, Adobe has decided to turn "Flex Builder" into "Flash Builder". They're even changing the logo (though it's still the Flex grey, as opposed to the Flash red). Hmm...does this muddy the waters, does it compromise a distinction that, after all these years, made it easy to explain to a customer why I'm better for this role than the designer/Flash type?

Adobe says, "On the contrary, Flex is now much more understandable. Flex is an ActionScript framework for creating RIAs and that is not changing. This name change actually makes the Flex brand more solid and understandable."

Oh c'mon. That might be true from the perspective of a technologist that understands Flash technologies, but I know technical recruiters and business guys that depend on the distinction. 

"I thought Flex programmers were more serious than Flash programmers, but now there's no more Flex.". 

"Err...no. There was actually never a 'Flex programmer', we are all Flash programmers, what you thought of as a 'Flex Programmers' is actually a Flash programmer that uses the Flex Framework, and the Flex Builder, to build Flash applications". 

Customer: Huh? Are you a Flex programmer, or not?
Me: ...yes sure. I'm a Flex programmer. 
Customer: Ok, why didn't you just say that? 

I know for a FACT I will have this conversation. The customer will be frustrated and make comments like, "damn engineers, fixing what isn't broke". I'm confident I can manage it, because I worked for Microsoft and got used to explaining to customers why something that was a certain way was actually better if we changed it, even though nothing had actually changed other than how we want you to look at it.

So, Adobe has given me a job to do. I don't mind all that much; I'll reach out to all my clients and make sure they understand it. That's good client relationship work--and might even drum up a little business. However, I do think Adobe is understating how difficult understanding the difference between Flex and Flash initially was, how successful and welcome it was at differentiating the two kinds of developers based on the two distinct brands, and how confusing it's going to be for a lot of hiring organizations when they're told "I use the Flash Builder to build Flex programs."

Maybe what we now know as Flash CS3 needs to be rebranded as "Flash Designer".

Like any other change of this ilk, it'll rumble for a while and then be gone, we'll get around it. My advice to the independent Flex developer out there though...erm wait, the independent Flash developer that knows the Flex framework...or however you brand yourself: let Adobe do the explaining. Forward your clients the FlashBlog link. 

Aside from that, leave it at "it's a marketing thing. Nothing has actually changed. You can still refer to me as a Flex developer if you like." 

Tuesday, May 19, 2009

Working Off-Site: Practices for the Indie Software Developer

Being an indie software developer isn't easy; getting and keeping clients, managing payment and collections, doing the books, complex taxes, ensuring you have software licenses and top-end gear, setting up a home office properly, and keeping up-to-date on the latest technologies, finding and managing benefits like health care and a 401k, all without a manager telling you to get it done, isn't for everybody. It's hard work. 

For me, there's no doubt. Like an actor, writer, or musician, I'm all about the project and my role. I perceive myself as "talent", and like to be in direct control of what I work on, when I work on it, and how much I earn for doing it. For the first 10 years of my career in technology, I worked in strategic planning and R&D at American Express, and as a technology specialist (essentially a field technologist, building prototypes and comparative demonstrations) for Microsoft. I won't get into a lot of detail as to why I decided to leave and go it on my own; suffice to say that I prefer the freedom to pursue work that interests me every day, and I like to keep my focus very specialized. 

One you actually pull the trigger on self-employment though, you find a lot of the romance of "being your own boss" dries right up. It's scary, and you find yourself working harder than ever; keeping your books straight, or learning a new programming language, is time consuming work, but nobody is going to pay you for it. Working from home is a discipline as well; it's so easy to "take a break", and watch some TV, play a little guitar...and kill the whole day. "Oh, I'll make up the time, pull an all nighter," and all that. Sure, maybe once in a while, but if you do it all the time, you won't be able to sustain it and your work will suffer. 

With all that said, here are some of the more valuable tips I've compiled from my five years as an indie software developer. 

- Don't jump in suddenly. Doing it right costs money and will take time to get up and running, you have to be prepared for some lean times. If you don't have any money in the bank or are just having trouble finding a job, you're better off spending your time at networking events and job fairs, and finding training to get your skills together. Collect unemployment and beat the street, there's no shame in that if you're really working it, and employers will recognize the effort. 

- Take a business class, get a couple of books on starting and running a small business. I dreaded this, but did it, and have to say it was one of the most valuable bits of training I've ever had. In particular, I picked up a book "How to be a Successful Freelancer", and found it invaluable. Aside from the obvious "keep your books straight" sort of stuff, I got a template for a freelance contract, advice on the kind of clients I should pursue, how to set a rate confidently, some basic negotiation strategies, and an understanding of how important documenting the entire process of approach, negotiation, contract, work status, and closing out, is. 

- Set up a business checking account, register your business name under a DBA ("doing business as"), and use something like Harvest (google it) or Quicken, to track money coming into that account. I use Harvest and can tell you exactly how many hours I've worked, how much I've made, and how much I've got coming in, at any time. 

- Create a workflow for working with a client; set up a process, make sure you have templates of your contract ready, have your resources (development server and testing environment, etc.) all up and running. Let your client know in advance how you typically set up and work on a project. This isn't to say that you should be like, "this is how I work and this is how you're going to work with me," but more like "typically, after we get through exchanging NDA and work agreement, I'll set up the space on my testing server and give you access so you can monitor the in-progress product whenever you like...I provide daily status updates at the end of each day, I'd appreciate if you could review them periodically to make sure I'm on the right track...I can be contacted at this AIM account, or on Skype, or by phone, during normal business hours, but feel free to leave me messages at any time...", that sort of thing. 

- I can't believe how many indie developers don't have this set up, so I'll put it in caps...HAVE A WEBSITE AND A DEDICATED, REGULARLY BACKED UP, SUPPORTED, DEVELOPMENT SERVER. PAY FOR IT. If you're indie and want to beat out the organized dev shops for a contract, you have to be GOOD. If you don't have your own tools, like a basic website with links to samples of your work and your resume/contact info, and a server to show in-progress work or experiments you're tooling with, you're not going to convince anybody you're really into what you do. More than likely, this sort of developer is just one that can't find a job, and is trying to freelance a little until they find one...which means they'll drop your project the second they do. 

- It's hard to believe I have to say this, but from what I've seen, it's necessary; don't steal to do your job, don't depend on others to provide you with your tools. Invest in a good laptop and the software you need. Pirating your software isn't cool, it doesn't make you look smarter or hipper. If you'll steal the software from the manufacturer because of some Robin Hood rationale, sooner or later, you'll probably steal from me. Spending a couple thousand dollars for the tools you plan on making a living with, which you get to write off anyway, isn't unreasonable at all. 

- Provide your clients with FTP and SVN. I run both on my server, and give access to my clients for free for the duration of the project; I know of no other solo indie developer that does this, and I can't imagine why not, particularly since, aside from the server, it's all free. If the client has these resources set up and wants me to use theirs, great. But even if that's the case, saying I have it and can provide it--and many clients take advantage of it even if they do have it already--makes me look more pro. 

- Work regular hours as much as possible. There's this whole "I work while you sleep" thing. It's unhealthy. I don't want to know I can contact a developer at 2 a.m., I want to know that I can contact them at from 9-5, and that they'll be awake and lucid. Saying you weren't available for a conversation at 11 a.m. because you were up 'til 6 a.m. isn't good, and email timestamps at 3 a.m. with some garbled message are worse. People that work regular schedules at standard business hours generally do better work, because they don't work past the point of diminishing returns. I used to do all that; I don't anymore, I don't walk around burnt out with headaches from too much coffee and lack of sleep anymore, and my client list is stronger than ever. 

- Don't work in your bedroom if you can help it. It's really important to unplug when you're done for the day, and keeping your workstation in the same place you sleep makes it almost impossible. Set up a desk in your living room if you have to. 

- Offer to be available for onsite, schedule meetings. I generally don't work onsite because I invest heavily in tools and space to maximize my productivity. If a company insists on full-time onsite, I'm a lot more expensive, primarily because I want to deter it, but also because I have no intention of providing the services of a full-time employee that gets no benefits. However, if there are developer meetings once or twice a week and it's possible to be there physically, ask if you can go. If they say yes, GO AND DON'T BE LATE. If you can't physically go, ask for a conference number. You're indie, but for the duration of the project, it's important to be perceived as accessible by, and interested in, the rest of project team. 

- Don't go dark; from 9-5, fire up Skype, whatever IM the client uses, have your phone on and your email up, and respond immediately, even if just to say "I've reviewed the data, give me some time to respond". This is critical; I'm asking a client to trust me off site. If I stay visible and responsive all day every day, I  build the client's confidence tremendously. Again, it's funny how many indie developers will just go dark for a few days, thinking they understand what they need to do and don't need to communicate. 

- Send status every day when you wrap up, and post your work to your dev/testing server for review. State what work you've done, and any issues holding you up. If you don't get a response for a day or two, send an email asking if the client has been reading them, and if not, if they can get on a half hour call to review. It's extremely important to get daily feedback, even if they say "got your update, will review later". If the client goes dark, inform them that you're going to stop work until they respond. Don't give a client the opportunity to say "I looked over your work for the past two weeks today and have numerous issues, we're not satisfied." You'll end up doing work for free. 

- Don't work without a signed work order of some kind. The client MUST sign a document saying that you are getting paid X rate for Y work, and may end the relationship at any time, at which time all unpaid work comes due, and that the client (which could be the subcontractor) is directly responsible for this payment. It is NOT in your interest to let a client talk you out of this, you're better off without the work. If the actual client refuses to pay the organization that subcontracts you, that's not my problem. If they say "tough", get a debt collector on them and make no bones about the fact you'll spread the word. I have had to do this twice, and both times they paid up and even offered me more work, which of course I declined. Only once has a client actually not paid me, but that was early on, I know now that I compromised too much and should never have taken the client. 

- State, as part of that work order, that you are getting paid for time and service, not for a finished product. More than once I've seen a project go bad because another developer screws it up or vanishes, or the actual client (i.e. if you're being subcontracted) terminates the project. I hate when that happens, but ok, you still got my time, and I want to get paid for it. 

- Don't do flat rates; if you do, take your estimate, double it, and add 15%. Tell the client if you finish sooner you'll pro rate it, but that the budget must cover your initial figure. I've never, ever gotten involved in a project at a flat-rate that turned out to be really worth it, because clients add features and change requirements far too often to make the initial estimate valid, and argue when you say you need more money  because it's not the same project anymore. If you go by the hour, or a day rate (I even offer a monthly, with the contracted stipulation that if you book me for a month at my monthly rate, I am guaranteed the month's wage), you don't have this problem. Clients will frequently understate the complexity of a project to get a low bid, because they need to keep their budget down, often because they underbid a project themselves and are trying to find cheaper development to make the ends meet.

- Again, unplug at the end of the work day. Stop working. It's important. I go from 7 a.m. to 5:30 p.m. That's a long day, and my returns diminish after that. Go to the gym, take a bike ride, get some dinner, play your guitar, whatever. Get a good night's sleep and wake up refreshed. You'll do more consistent, higher quality work. Many don't believe it or think it's not "hardcore" or whatever; rarely do I say this as an absolute, but if you're one of them, you're wrong. 

That's about it for now; there's more, but those are the ones that are top-of-mind for me. But it's time to get down to business on my day project so I can knock off at 5:30 p.m, hit the gym, get a couple of songs down for band practice Thursday, and get a good night's sleep. Practice what you preach. 

As always, thanks for visiting. 

Monday, May 18, 2009

The Citrix Receiver Follow Up: Flash/Flex (and then some) on your iPhone...or Symbian...or WinMo...or...

I said I'd follow up on my story Flash, Flex...on your iPhone?, (this story generated a lot of press, got picked up by TechCrunch and blogs all over) and here it is. 

As a quick recap, I looked at the Citrix Receiver iPhone app, and was impressed with the experience. It's not a VNC or RDP solution; Citrix has created a client that, by use of a highly optimized communication protocol, lets you view apps running in the EC2 cloud (for the layman, that means "you see it on your phone but it's actually running somewhere else") without installing them on your phone. This means that you can build an application out of any technology, deploy it to the remote server infrastructure, and access it on your phone, or computer, or any device that runs the Citrix Receiver. The technology is optimized for this use; there's no awkward, blocky screen redraws, no browser toolbars, etc. A properly designed application appears to be running as a full-screen application on the phone, no matter what technology it's built out of. This suite of tools is branded "XenApps" for the most part; I'm not one of their marketers and know there's more to it, but "Xen..." is a big Citrix branding buzzword these days.

It's amazing how many people responded negatively, clearly without trying the Citrix Receiver demo. For the most part the issues are around the rampant abuse of Flash all over the web; poorly programmed banners, autoplay video players, that sort of thing. I concede: the web is full of bad Flash, and if that's the extent of your experience, you'll probably be pretty close minded about the subject. I've been a Flash developer for a long time though, and have never programmed a banner. I work on enterprise-level applications that make companies money; I've built applications that you've more than likely used, and that have helped people sell companies, and is currently helping a startup stay in business. Flash development, with Flex and Air, is stronger than ever and isn't going anywhere. Hating it is a waste of time. 

To continue my rant, I'll tell you one thing for sure: I don't want to be in the business of porting those apps to every different platform on earth. Yes, I could make money doing it. But it's boring and doesn't move me along to the next new project. People say, "forget Flash just build an iPhone app". Erm...what about Android? And Blackberry? And Symbian? And Windows Mobile? And Windows desktop? And OSX Desktop? Hire all those developers....maintain all that code...I've got better things to do. I want my app to have as much reach as humanly possible with as little work as possible, and porting the code to everywhere isn't a good strategy. 

Note: Citrix said that for Blackberry and Android clients, we have to "stay tuned". The guys on the call wouldn't nail in any dates or promises about this, but they didn't say "no". I'd assume that, considering how attractive this technology could be to corporations, a Blackberry client would be a no brainer. There is currently one for the iPhone, Symbian, and Windows Mobile 6.1.

The Citrix Receiver, backed by the Citrix technology on the server side, is the sort of thing that makes this possible. Again I'll say, and Chris Fleck, VP of Solutions Development for Citrix agreed readily, that it's not for every kind of app; if you have something that requires lots of real-time graphical updates, like a MMORG or something, you should probably consider going native. But that's the minority of apps; 75% of the stuff I've seen in the iPhone app store, or more, could be served using the Citrix technology, which would give the developers the opportunity to deploy it to all the new platforms coming out. 

One big thing though; the Citrix Receiver is branded Citrix. This was a big downside, and I told the Citrix guys so; if I'm MTV, or Thomson Reuters, or CNN, or Disney, I'm not going to want my front-end gateway UI to be branded Citrix. I want people searching their platform's app store for my brand, and when they pull it down, I want to see my logo on their phone. Here's what it currently looks like:




To this, Citrix responded, "that's a real valid point. We're going to look into this". One of their developers that was on the call seemed to think it would be a no brainer to implement. So, from what I can see, Citrix is going to enable this. So, you brand the Citrix Receiver as your own...

...YOU DON'T EVEN HAVE TO BUILD IT. You just brand it and get it in the [ fill in mobile platform ] app store. 

Then you take your code base, deploy it to the Citrix solution on the EC2 cloud, and that's it. Anybody with the receiver can use your app, no matter what technology it's built out of. It just stuns me that people don't see the potential for this. If Citrix really puts in the time and makes this solution rock solid, it could very well represent a significant direction of the next wave of mobile device use. 

Citrix showed me how easy it is to do it; in fact, it looks so easy, and so cost effective to get up and running, that I'm going to try it with my Planet Sudoku app. They even have a little app shell, called "AppViewer" which you can embed your tech in, that takes care of the full-screen look-and-feel for you. 

Initially, I was going to port this thing to the iPhone, but now, as an experiment, I'm going to just refactor the UI to fit the iPhone, use the AppViewer shell, and deploy it with the Citrix solution; you'll be able to play my Sudoku client on your iPhone in a lot less time than if I retooled the whole thing to Objective C. More blogging to come on that one I'm sure. 

Is it really that easy? I don't know for sure, but as far as I can tell, this is a heck of a lot easier than porting the app to Objective C. In their own words (note that where they say "Windows", you can sub in "apps that run on Windows", like Java, Flash, Flex, Air, Silverlight, etc.):

"While unmodified Windows applications can be delivered to mobile devices via Citrix XenApp, XenApp also provides an excellent platform for delivering custom mobile applications. Citrix is seeing interest in this area from a number of it's ISV partners. The concept is to build the application using tools normally used to build full Windows applications, but simply design the user interface with the smaller screen size and resolutions of mobile devices as a design consideration. The concept is to reskin the UI of larger applications with a smaller form factor UI. As long as the custom mobile application can be published on Citrix XenApp, it can be delivered to mobile devices with the Citrix Receiver installed."

So, if this indie software developer can make this work, I'd pretty much say that anybody can, not matter what your reach is. You don't need deep corporate pockets; I don't actually know this for a fact yet, but I'm optimistic, and am actually trying it now, so I'll let you know. 

For more info on this topic, and/or to learn how to get involved in this sort of development, visit the Citrix developer community site, and take a look at the Tips and Tricks sections. 



Sunday, May 17, 2009

Tcoz Tech Wire (Kindle Edition) is available in the Amazon Store! If only the subscription process WORKED...oh wait it does but it didn't seem to...

A few days ago, when Amazon announced they were allowing all bloggers to submit their blogs to Kindle Publishing, I decided to do it; I went through the process, filled out the forms, and awaited approval. You can read that post here:


Lo and behold, today I checked in, and found that Tcoz Tech Wire (Kindle Edition) is now live. Users all around the world can have my blog delivered daily right to their Kindle e-books. Naturally, I wanted to blog about the fact that my blog is now available as a Kindle-published blog. 

Like I said in my last article, I don't really expect to make any money doing it, especially since it's been reported that Amazon gets 70% of the subscription price which in my case, Amazon set at $1.99 (Amazon sets the price for you based on what they determine the worth is...hmm...). But, it's fun, puts me in the Amazon store, and makes me searchable on the Kindle blog list, all free. I'll take it. 

Anyway, back to Tcoz Tech Wire, Kindle Edition. The screenshot below shows the splash page at Amazon:





There I am, in the Amazon store. How about that? I need a subscriber, so I may as well be the first one.  I got out my Kindle, went to "Shop in Kindle Store", went to the "Blogs" section, went to the "Internet & Technology" section...and saw 124 pages of blogs. Ugh...time for search. I typed in "tcoz", and up popped the Tcoz Tech Wire subscription offer. 

So, I subscribed; you get a 14-day free trial, so I figured if I don't like this guy's work, I can always ditch him anonymously. I clicked "Subscribe"...

...and BLAMMO. A message pops up, "We were unable to process your subscription request at this time. We are working on the problem. You can contact Kindle Customer Service at 1-866-321-8851 or try subscribing again later." 

The Kindle specialist team had this to say:

"There is a waiting time, even after it's approved and listed, until you can actually subscribe". I pointed out that I submitted the blog the day this service went live, which seemed to make the support rep a little uncertain of her first answer, so I got put on hold for a bit while she did a little checking. 

She came back with, "You appear to be subscribed to the blog.". I checked the device, and there it was, delivered to my book list. I mentioned that I hadn't received any success message or any such confirmation on the Kindle device, etc. etc., and that I hadn't double clicked during the processing (you see the little spinning icon in the upper left of the Kindle, letting you know network access is active), they said they'd look into it. She did say that double clicking on the subscription would generate the error, and even though I hadn't double-clicked, it still seems borky; it should say that your subscription is pending, or that you've already subscribed. All in all, she agreed and said they'd look it over. 

Anyway, there it is, on the Kinle. Now let's open it up; there's Saturday's article ("Turn your IPhone into a Web Server"). Easy to read, properly formatted, with my images all there. Note: my blog is very simply formatted, no gew-gaws or advanced CSS of any kind. For Kindle publishing, this might be the way to go, at least for now. 

Great, so it's working on the Kindle, let's go to my Dashboard at the Kindle Publishing site and see what happened...hmm. I don't see any way to tell how many subscribers I have, or any other such data. I'll have to put in a call about that. My vendor reports and such are all unavailable...interesting. All right, the program is young, I have some things to learn about managing it probably. I'll have to blog it another day. 

All in all, I'm pretty happy with the way things are going. I do think that 70% of a $1.99 subscription is a heavy hammer blow, and there seems to be a couple of glitches along the way, but it's all FREE. People compare this to the Apple store, but they leave out the fact that, as an independent developer to register a business as an "official" iPhone developer, you pay $105 a year, and they still take some off the top of all app sales. 

For the indie blogger/software developer type, my view is, this is a great opportunity to get your stuff out there. If you're not happy with the arrangement, don't use the Kindle Publishing tool. 

Now please go and subscribe to Tcoz Tech Wire on your Kindle :)

As always, thanks for visiting. 



Saturday, May 16, 2009

Turn your iPhone into a Web Server...Your Website In Your Pocket!

Sure, you can take a picture with your iPhone and upload it to Facebook, you can use a VNC or RDP app to remotely control a server and tweak a website...

...but what if you could turn your iPhone into the machine hosting the website? As in, literally walk around with an http web server in your pocket, with a public website that people can access to see your photos and other media?

For the typical techno-muggle, the whole "server" thing is still a bit of a mystery. Your average web user knows that they can upload photos somewhere, and somewhat more advanced ones might know they can blog by typing an article into an edit box and clicking "publish", maybe even linking in the previously mentioned photos. Where and how that content exists is unknown though, so if it wasn't for tools like Blogger, Flickr, Facebook, etc., the typical user would have little or no web presence. 

I don't think it's because your average web user is incapable of understanding servers, I'd guess it's more a matter of just being exposed to a web server and understanding how a it makes content available. If you could put one on your iPhone, which is connected to the Internet, and use it to publish your pictures, and/or other info, that might fit the bill. It wouldn't necessarily mean building out web sites; say for instance, you took a picture, and the tool automatically copied it to the folder on the iPhone that makes is publicly available; you'd just tell people the link to your phone, and there you go.

Think of it as a personal, portable, data and media center. 

Looks like it's starting; Freebit, a Japanese company, has put out a free iPhone app, called "ServersMan", which does this. Your phone literally becomes a mobile server. 

Check it out at (make sure to look in the upper right for the "English" link):

http://www.serversman.com

I couldn't believe it; I had to try it. I'm astonished to say, it's very easy and seems to work. I haven't run load capacity tests or any such things yet, and to be honest I don't know "exactly" how it works or whether there's any smoke and mirrors, but from what I can tell initially, it legitimately makes your iPhone into a walking http web server, with WebDAV installed so you can manage the content externally (the iPhone doesn't have a way to do this natively). 

You can actually try it; my iPhone is on and serving. Go to this link:

http://serversman.net/tcoztech-node/

This sends you to the ServersMan infrastructure, which proxies your request to my iPhone. You'll see a frameset page, which actually lives on my iPhone, with a message in the top frame telling you what you're looking at, and my blog in the bottom frame. Note that ONLY the frameset page is on the iPhone; the pages that fill it are on my usual www.tcoz.com server, but from what I can see, if I wanted to, I could have put it all right on my phone. 

ServersMan has some other interesting capability too. They say that by using the tools provided with the app (remember this is all right on your phone), you can easily create a "mashup" website on-the-go. 

For example, go to this link:

http://serversman.net/tcoztech-node/photos/picture.jpg

You are now looking at a picture that I took with my iPhone camera (one of my guitars), being served from my iPhone, automatically named "picture.jpg" and made available. You can even make your whole camera roll viewable with one click if you want to, it'll build out a web page with links and everything, right on your phone. Ordinarily, you'd have to upload all this and so on, now you can just it in bulk and manage all the content right on your phone. 

Now take a look at this:

http://serversman.net/tcoztech-node/location.html

Serversman can take your GPS information, save the information locally, and make it available through the Google Maps API. So at any time, I can just leave this capability on, and you can see exactly where I am (more or less). Why is this a great thing? Say I'm trying to get to you and I'm lost. Just hit my iPhone address and you'll see exactly where I am, and you can say "make your next right".  

All these little mashup gadgets are right on the iPhone. I didn't have to go to an external website, or hit "upload", or anything like that. Again, the phone IS the server. 

How do you manage content on it though? For that, you do have to go to a website, because there's no way on the phone to explore folders and move around files (iPhone doesn't give you Finder-like access natively). For this, ServersMan uses WebDav, which in a nutshell, is a way to enable access and management of web server content remotely, like from a tool or website. You log into the ServersMan website with your account credentials, it connects to your phone through WebDAV, and there you see all the content on your phone in a simple folder structure. You can upload things (which transfers them to your iPhone directly), move things around, and so on. Using this tool, you can build a complete website right on your iPhone. 

There's other features too; voice notes, music, all can be made available from the device. I don't use any of this, but it's there and if it works as well as the rest of the app, should be fine. 

I have to say, it's amazing. I'll leave my iPhone-site up and running for a bit so the links in this blog work; tweet me if it's down and you want to try it. One thing I haven't figure out yet is whether or not I can switch to another app without shutting down the web server. If the app is up, and I leave the phone alone, it's fine, but if switch to another app, it seems to shut down; this may be because I just don't know something. It could just be the iPhone itself though, since as of yet, "run in background" for apps is pretty much non-existent (this is actually a huge downside for iPhone app developers).  

A lot of people may say, "this is ridiculous I  can already do that this way that way etc. etc."; there's always the knee-jerk "this is stupid" type. People used to say the same thing about cel phones and ATMs. Download it, use it, experiment with an open mind, and you might find that it changes the way you use and/or think about your iPhone.  I already know that I'll use it for a couple of things. 

Screenshots below, not served from my iPhone though...isn't it amazing you could actually ask that question?

Screenshots of the basic app admin pages, etc.


 
 
 
 
 




This photo is what you'll see if you nav to my iPhone web server and ServersMan isn't active:






As always, thanks for coming by. 






Friday, May 15, 2009

Flash, Flex...on your iPhone?

I'm a Flash/Flex/Air developer primarily, with expertise in what I think of as "supporting" technologies (gateways and data layers built out of .Net, Java, PHP, Ruby, etc.). My usual contract gig is, I manage and/or work on an application's UI, using ActionScript technologies, and offer whatever assistance is needed to set up the gateway and data transfer backends. Sometimes I build all of it, sometimes I just have to work with the backend guys to understand how something like OpenAMF or Fluorine works, it depends on the client's expertise, but that's why they hire me. 

Flash/Flex, however, has been one of my greatest disappointments with the iPhone. We were promised "the complete web", and it's one of the reasons I jumped on the OG iPhone day one. Shortly after dumping my other phone and signing onto AT&T, I visited one of my ActionScript-based web apps...

...and discovered there was no Flash. Apple and their fanbois came back with a few short, lame justifications for this disclosure omission: "we support the open web, Flash is proprietary", "the Flash player is not really a Web 2.0 technology", were some of the things I saw bandied about. Fact is, it's the best solution for RIAs, and is getting stronger all the time. I've been doing this for 15 years, picked Flash/Flex for a reason, and the industry seems to support my decision; the NYTimes recently dumped Silverlight for Adobe Air, MLB did the same thing a while back if I remember correctly, and I'm currently working on a very large project that I can't talk that much about, but which will go live soon (and then I'll talk about it as much as I can). 

I have actually viewed Flash apps on my iPhone over VNC and RDP connections (check out WinAdmin in the app store). This lets me pull up a browser remotely, and access any web page I want, including ones with embedded flash apps. If the Flash app is designed properly, with a web page that properly sizes the browser, removed as many tool/status bars as possible, and so on, the experience isn't bad, but, I admit it's unreasonable to ask your average user to buy and install WinAdmin, or some other VNC client, to play a Flash game. I'd also have to provide the server for browser access, etc. 

It seems somebody has set out to solve this problem: Citrix. Take a look at this:

http://citrixcloud.net/

They offer a client for iPhone, called Citrix Receiver, which offers a 2-hour session, expires-in-24-hours, demo of access to the CitrixCloud. In their own words, the CitrixCloud, or C3 is "a complete set of service delivery infrastructure building blocks for hosting, managing and delivering cloud-based computing services. C3 includes a reference architecture that combines the individual capabilities of several Citrix product lines to offer a powerful, dynamic, secure and highly available service-based infrastructure ideally suited to large-scale, on-demand delivery of both IT infrastructure and application services. "

For the layman, that means more or less, "you can use our products to expose your apps to pretty much any client. With one of our viewers, a user can use any application on just about any client as if it was installed on their desktop". 

So, by now you may have guessed: The Citrix Receiver can provide access to Flash and Flex applications in a very compelling way. 

Ultimately, it's still the iPhone accessing web pages, but, it's not doing it through Safari, which can't run the Flash player. It's accessing a browser on a Windows machine remotely. The Citrix Receiver hides this though; you wouldn't really know it unless you were looking for it. The applications are sized full-iPhone-screen, some for landscape, some for portrait, and there's no browser toolbar or anything like that; you appear to be using a full-screen Flash/Flex app. 

So, when they go live with this (again, Citrix Receiver is a demo), does this mean I'll have to install the Citrix Receiver and understand all this cloud stuff to simply run an iPhone game?

Yes...and no. Here's a total hypothetical. Say you're an internet game company of some kind, something like a Pyzam. You're in the business of buying and developing Flash games, integrating advertising, all that. You create a branded version of the Citrix Receiver, and get your cloud infrastructure set up. Users go to the App Store, and get your branded viewer for free. They create an account, log in, and happily play Flash/Flex/Air games on their iPhone, with advertising and whatever else the developers build into the games/widgets/etc. 

I think that's compelling. Sure it needs more thinking through, and at this point is probably most useful to corporations or organizations housing large portfolios of Flash apps. But this is a direction that shows that, with some ingenuity, even today, you can offer applications built out of pretty much any technology on the iPhone. This also works with Windows apps, Silverlight, and so on, but I'm really interested in Flash/Flex. 

Also, it gets around a lot of the "pay for and we must approve" apps scenario, and enables use of ActionScript development resources, which are nowhere near the scarcity and premium of good iPhone development. If Apple doesn't like your content, they can reject your viewer though I suppose. 

So in the end...will phones just become all about the screen, and what viewer/cloud-access apps they can run? The thin-client finally plants its flag for good in the mobile world? Hmm...

Below are some screenshots from the Citrix Receiver demo. As always, thanks for reading Tcoz Tech Wire. 

Remember, these are Flash and Flex apps. They look great, and work as expected. These are screenshots right from the iPhone.

These two photos are of the Citrix Receiver interface for accessing different kinds of apps:







These images show some basic Flash/Flex apps from their demo. The first is a pretty standard reports app, the second shows network statistics in real time, the meters moved and everything just like a native app:







These images show a Shirt Configurator: you select colors, styles, logos, etc., and can save the profile. I found this very interesting.






Wednesday, May 13, 2009

Subscribe to my Blog On Your Kindle!

I know that the masses aren't going to flock to an amateur blogger's site; I don't expect to make any money. I anticipate one subscriber though at least, maybe two (if I can talk my girlfriend into it). But, my blog is on the Kindle list with the big boys, albeit a lot further down methinks. Sure, you can always just hit it on the web; but why do that when you can really use your Kindle to the max and subscribe in a civilized way that will drive me on to ever-more-interesting blogger heights? Erm...because the web one is just as good, and free? You have a point...

...but, one of the intriguing things about the web is how it levels the playing field as far as presence is concerned. I don't have to be Oracle or Microsoft to have a web page, or to publish a blog. Li'l ol' me, with some resourcefulness and my programming skills, can create enough assets and presence to rival many a big shop. This has always appealed to me, and the Kindle blog capability, which is free, just adds to it, thank you Amazon. I blog...and have a website...and an FB page...and a Twitter account...and membership in forums...and come up in Google links... therefore, I am.

That aside, how did I manage this? Yesterday, the news hit the wires that Amazon was opening up it's Kindle blog publishing platform to Kindle owners. I have a Kindle, I love it, I have a blog, I contribute to it frequently, I'm a tech nut...add it all up, and I was a perfect candidate to give it a whirl. 

If nothing else, it's incentive for me to blog hard; one day maybe, somebody I haven't promised to take out to a nice dinner will subscribe to my blog, a complete and total stranger. On that day I'll drop my clients, tell my girlfriend to quit her job, move us out to San Diego, blow my savings on a top-end 'Benz, and live the high life with the blogerati. 

Or, I'll smile, text a couple of people the good news, tweet it, and greedily wait for that first south-of-$10 deposit from Amazon. 

Anyway, the process, if you're interested; this assumes you already have a blog with an RSS/atom.xml feed of some kind set up properly (Blogger for example):

- Go to the Kindle Publishing for Blogs Beta site, Kindle Publishing for Blogs Beta
- You can't use your standard Amazon credentials, you have to create a fresh account. 
- Fill out the surprisingly simple form; basic identification, a couple of security-in-case-you-forget questions, and provide a bank account number for Amazon to dump your hordes of riches into. 

That's all there is to signing up. Following this, you get taken to a page showing three tabs: Dashboard, Reports, MySettings. 

- Dashboard: provisions your blog. You click "Add Blog" off to the right, then provide your blog's RSS/Atom feed address (nice, I don't have to republish my blog, they actually pull my existing Blogger blog in and format it for the Kindle automagically), title, tagline, description, publisher, screenshot, masthead/banner, and website address. Easy enough

- Reports: Two reports are available; single issue purchases, and monthly subscriptions. Mine are empty (hint). 

- My Settings: change password, security questions, the usual sort of thing. 

And that's it. Preview your blog, publish it, and 48-72 hours later, you're available for purchase. 

Note: if your blog is simple, primarily text and image based, your published results will probably be more consistent. If you have all kinds of Flash gew-gaws and whatnot in there, the formatting may be less consistent, since Amazon will just omit the gadgets, either truncating, or just leaving in, the space they usually take up. 

Make my day...buy a single issue! If you like it and are the sort that can spare a few bucks for an aspiring blogger...subscribe for a month! 

Free or paid, thanks for coming by :)