Building Mobile Apps for Multiple Devices with Flex at 360|Flex

It looks like I never got a description into the good folks at 360|Flex about my session. Sorry about that.

Building Mobile Apps for Multiple Devices with Flex

Building apps for multiple devices isn’t just as simple as redoing your existing apps in Flex Hero, and running Export Release Build in Flash Builder. Getting applications to work on multiple screen takes thought and work in:

  • Design
  • Coding
  • Configuration
  • Packaging

 

The session will cover topics including:

  • Application DPI
  • Mobile Design
  • Simulating various Screens
  • MXMLC
  • Command line packaging
  • ANT
  • Publishing for multiple stores
  • and more

 

It’s a high level exploration of these issues, and will touch on content that is addressed deeper in other 360|Flex projects.

It’s time has also been changed from the paper schedule. It will take place:
Monday at 10:50 AM in Salon C.

Motorola MOTODEV App Summits Tour!

I’m pleased to announce that Adobe is participating in Motorola’s MOTODEV App Summits. The App summits are designed to bring developers up to speed in developing Android Apps for Honeycomb, specifically focused on the XOOM with Honeycomb OS, as well as for smartphones like the ATRIX.

I’m also pleased to announce that Mark Doherty and I will be giving sessions on AIR for Android development at these events.

Berlin, Germany – April 11 (Mark)
London, UK – April 15 (Mark)
Beijing, China – April 26 (Mark)
Shanghai, China – April 29 (Mark)
Seoul, Korea* – May 2
Sao Paulo, Brazil* (Terry)
Buenos Aires, Argentina* (Terry)
Mexico City, Mexico* – May 25

If you’re near any of these cities and eager to get your Honeycomb on, or just to check out the cool stuff Motorola’s got going on, please come on down. Register at the MOTODEV App Summit website.

Angry Old Technologist

The Angry Old Technologist (AOT) has been around forever. They built the system that you are trying to change. They’ve forgotten more than you’ll ever know about programming, hot shot. In short, you’re trying to change things, they’re yelling at you to get off their lawn.

Now, that’s not to say anyone with more then a few years of experience is a senior citizen. Nor that all criticism from people that share characteristics with this group.

Unlike last week’s character, the Angry Young Technologist (AYT), I don’t have experience being the AOT. At least I think I don’t. I’m fairly sure I’ve never been the one saying we absolutely shouldn’t change something. I may have argued against a particular change, or implementation, but not generalized change. Therefore, my thoughts here are more conjecture and inference than actual experience. Anyone who sees themselves in this description is welcome to set the record straight on anything I get wrong.

Scenario:
I was once at a conference where there was a Q&A with representatives from Microsoft, Yahoo, Google, and, of course Adobe. Someone got up and started talking about the current pace of change, and how every year all of us were coming out with more tools and technology. And he got angrier and angrier as he spoke, until he blurted out:

Why do you guys keep forcing me to learn new stuff?

And therein lies the key problem of the Angry Old Technologist: progress forces change; change forces them to learn; and they don’t want to.

Now, back when I was an AYT I never understood this. How can you hate to learn more things? As I get older, while I don’t resent learning new things, I can understand why you might.

I’m lucky, part of my job is to keep learning new things. Not all jobs build into them the need to learn new things. Most don’t. When you’re younger and have less responsibility, it’s not a huge deal, you can just spend your free time learning new things. As you get older, other concerns come in, like family, kids, housing, health care, retirement funds, school districts, PTAs ARRRRGGGGGGGHHHHHHHH.

All that stuff, some of which people refer to as your real life, destroys your free time. When you’re young, and passionate about technology, that free time is where you spend long hours focusing and mastering new things. When you get older and attached, you don’t have that time. Learning goes from something you love to do and you can easily do because you have copious free time, to something you have to make time to do.

And that’s if you’re passionate about what you do. If not, you start as a young person having to spend time to play catchup. By the time your free time is gone, the idea of learning new things terrifies you because you don’t know when you’re going to do it, and you never know the worth as all technology has an expiration date.

Where does the anger come from? What do you get when you combine no time, with years of responsibility, the pressure to constantly learn new things, some of which may be “dead” before you even implement them, and fear of what happens when you fail? You get rage, pure and simple.

There is bad news here for the guy from the conference, and for all of the other AOTs: There is no stopping the change. We technology companies might impact, alter, or nudge the waves of changes. But ultimately we don’t control them; they are caused by too many disparate sources to be controlled, even if we wanted to.

So what do you do when you’re face to face with an AOT?

  • Well they’re irrational, so you should ignore them. Didn’t you read my book?
  • Learn from their knowledge of the current environment.
  • Engage them and try to bring them onboard without patronizing them.

So what do you do when you’re face to face with an AOT… in the mirror?

  • Accept that the future cannot be stopped.
  • Accept that it’s okay you can’t grasp every new piece of technology.
  • Be part of the change, which will eventually replace what exists now, instead of opposing it.
  • But mostly stop being so angry.

So what do you do when you’re face to face with an AOT and they’re your employee?

 

  • Build-in continuing education and skunkworks into employee goals.

 

This is a tough group, and they are some of the most resistant to change. They’re also tough because a lot of them end up in management. So avoid, if you can, defer if you can’t, and give them opportunities to save face along the way.

Angry Young Technologist

The Angry Young Technologist (AYT) is fresh out of college, or in some cases high school, new to the workplace, and has strong beliefs. They get their information from whatever sites are the bleeding edge, and are a great source of information about up and coming technology.

You might think that since AYTs are interested in the latest and greatest, that they are perfect choices to help you drive change, but they are hampered in their ability to help by a couple of things. If they are on your side, they are tenacious allies in the quest for change. But their choice of sides wasn’t governed by any convincing arguments that you made, merely that you chose something they liked. They might agree with you, but they can’t objectively review your solution and tell you if it doesn’t fit the environment. If they oppose you, they are obstacles that will not listen to any argument.

Now, not every younger person working in technology is this type. I’ll make it clear I’m not saying that at all. Venn diagrams and all that, not every YT is a AYT.

Scenario:
You enter a typical staff meeting and the AYT has a problem with the latest upgrade to the site.

“Why are we still using stored procedures for this application? We could switch to an ORM solution, and not be tied down to the SQL server. ” or something like that.

And, on the surface, it’s true. Stored procedures in this environment have to go through the DBAs. This adds an extra day to updates. It’s also low on the priority list of the DBAs and so can take more then a day. On top of that, a lot of the developers have good SQL chops, and are a bit better at SQL than the DBAs.

The AYT tends to find lots of issues like this:

  • It’s absurd that we aren’t using [insert currently rising language here].
  • Why the hell are we still using [Technology older then 2 years].
  • The fact that we have to do [whatever policy mandates] is a joke.
  • If only we did [whatever] we wouldn’t have all of these problems.

Then on top of it, they have terrible delivery. Words like “stupid”, “idiotic”, and worse are their goto adjectives. At this point in their careers they don’t have a firm grasp of diplomacy, tact, or the basic understanding that someone can disagree with them and not be stupid.

In the case of the above mentioned SQL policy he’s got a point. It’s terribly inefficient. The DBAs have other things to do, don’t get updates out on any sort of schedule, and don’t add a lot of value to the process.

The AYT is a few years out of college, so he wasn’t here while this app was being built, deployed and used in production for the first year. He didn’t track down crazy bugs in the reporting system. He didn’t enter 50 bug fixes that one week in September.

What the AYT wants to do amounts to a complete burn and redo of the existing code, simply to make the code technique (not quality or features) match current practices. It’s a bad idea, and people smarter than I have made this case.

This one example points to the root cause of the AYT’s lack of reason, a failure to understand the history of a given environment. Also he tends to not understand that decisions are made for more than just pure technology reasons. AYTs often don’t get the context of business, personnel, or other non-technology concerns.

  • If an organization has deep expertise in proprietary technology x, switching to free technology y has high retraining costs.
  • If an organization has expensively committed to technology x and technology y is only moderately better, the utility of switching is low.
  • Policies that effect technology are more often than not driven by non-technical reasons. While CYA policies are annoying they combat the high negative utility of drawing management ire.

These are all true, but would be dismissed by the AYT as irrelevant. Most of us that have been around for a little bit know that each of these has a tremendous impact on organizations.

Combine that failure to grok things with terrible delivery and you get one outcome: almost total lack of adoption for the things that the AYT champions. He’s making the wrong arguments, and he’s doing it like jackass.

I’m being tough on the AYT because I used to be him. I thought managers were idiots, upper management didn’t get it, and if only we did X, things would be so much better.

How’d I get over it? Getting beat by people with better people skills and less technology chops wears thin after awhile. Being successful the few times I stumbled into diplomacy helped. Not starting from a position that people who didn’t immediately agree with me had brain damage was a healthier place to be.

In short, experience is the best teacher. I wish I could have learned some of that easier and earlier.

Not all is lost. There are some positives to be gotten out of this character, whether you are one, or are confronting one.

  • Their passion, while perhaps a little rough, can be a great agent of change
  • The need for a given rule, procedure, or technology expires before the practice of it. They may be blustering, but they can also be the canary in the coal mine.
  • If they realize their delivery and vision of the problem are wrong, they can become a rational actor.
  • Coming along without the baggage of the past allows them to catch things in need of genuine change.

Do you know any AYTs? If so, try and take them under your wing and explain context when you can. When you see them crash and burn, let them know why.

Are you an AYT? After you’re done flaming me because “I don’t get it”, do some self examination. Are you ignoring non-technical factors? Are you being abrasive? Are you arguing against change because it doesn’t use the latest and greatest?

And don’t worry, my next post in this series will be on Angry Old Technologists who can be just as bad.

Make Your Line Longer

Ray Camden wrote a blog post earlier today about my demeanor towards ColdFusion advocacy. I am very appreciative of his kind words, and thought it would be a good time to share a little bit of the philosophy behind my attitude.

A phrase that has stuck with me through the years is “Make your line longer.”

It’s my paraphrase of a story from Zen in the Martial Arts by Joe Hyams.

Basically the story goes :

I will remember one of my initial sessions at his dojo in Los Angeles where I was practising Kumite (sparring) with a more skilful opponent. To make up for my lack of knowledge and experience, I tried deceptive, tricky moves that were readily countered. I was outclassed, and Parker watched me get roundly trounced. When the match was over I was dejected. Parker invited me into his small office; a small sparsely furnished room with only a scarred desk and battered chairs. “Why are you so upset? ” he asked. “Because I couldn’t score.” Parker got up from behind the desk and with a piece of chalk drew a line on the floor about five feet long. “How can you make this line shorter?” he asked. “I studied the line and gave him several answers, including cutting the line in many pieces. He shook his head and drew a second line, longer than the first. “Now how does the first line look? “Shorter,” I said. Parker nodded. “It is always better to improve and strengthen your own line or knowledge than to try and cut your opponent’s line.”

From KenpoKarate.ie (emphasis added)

The idea here is that people waste time trying to undercut their opponent instead of improving themselves. Undercutting an opponent benefits you once. Making yourself better is an investment that benefits you for the rest of your life.

What does this have to do with ColdFusion? The reason I don’t reciprocate to haters or bash competition, is because these are attempts to cut at their lines. I’d rather lengthen my own line. Show how ColdFusion is better. Make it do cooler stuff. Honestly accept and answer criticism and make ColdFusion and its ecosystem better.

And for those that don’t believe it can work, I will tell you it can. I’ve gotten into several conversations on twitter with people. One of my favorites I remember the best was with a Ruby on Rails guy who was bashing the tag based nature of CFML. Instead of fighting the tag/script war I talked about CFScript, and pointed him to my Google Translate API CFC on github. He admitted me might have been wrong, and was impressed by the fact that ColdFusion had unit testing. I didn’t convert him, but the next time he encounters ColdFusion he’ll take it a little more seriously.

The fact is that some people are haters, and will never accept somebody else’s argument. They’re d-bags. And with so many of us coming to age in a post-Internet world, they’re just getting worse. Don’t waste your time.

But there are many more venters in the world. They come to something they don’t understand and get frustrated, and when they do they vent. When they vent about ColdFusion, see it as an opportunity to help un-frustrate the frustrated, not a chance to avenge the hate. Do it by making your line longer, and not trying to cut the other guy down.

That’s what I’ve tried to do.

BrowserLab and DOM manipulation

I was recently working on a redesign to my site that required some DOM manipulation to make HTML5 semantic content like <header> and <footer> show up. Basically, you have to create those elements on page load to get IE to render CSS effects on them.

I was running into a problem where BrowserLab showed basically a blank screen for the IE8 version of my site. It was as if the HTML5 elements weren’t being added and therefore IE 8 wouldn’t render them.

That was close to the problem, it was that the rendering didn’t happen immediately on page load. BrowserLab has a fix for this. In the upper right corner, there is a setting named “Delay”. You can use this to delay BrowserLab’s capture and therefore wait until the entire page is rendered.

An awesome little feature that makes BrowserLab that much more useful.

 

 

Gmail System Folders with CFImap

I’ve gotten a few question about this lately. 

When you do a CFIMap “listAllFolders” operation against Gmail, some folders don’t show up by default. Unfortunately they are among the more important folders like Drafts, Sent Mail, Spam, etc. They are there, but for some reason they don’t show up, even with recurse set to true.
I’m not sure the reason, I’m sure it has something to do with the fact that Gmail works with “Labels” and not folders.
The solution is to know what to target. To get the system folders you have to target the folder: “[Gmail].”
Here’s the code:

http://snipplr.com/js/embed.js
http://snipplr.com/json/50293

ColdFusion Builder 2 Beta

About two and a half years ago, I got my first look at something called “Bolt.” It was an early alpha of what would go on to become ColdFusion Builder. I remember thinking, nothing could get me to switch IDEs. Two years later, I can’t believe I ever lived without it.

That’s why I’m thrilled to join in announcing the ColdFusion Builder team is releasing Coldfusion Builder 2 Beta to Labs today.

ColdFusion Builder has a ton of cool features, and I’m sure the usual suspects will give you a complete run down. But I’ll focus on what they’ve done to win me over with this release.

First, they focused on making it not just an editor, but an extremely productive one. More shortcuts are available, those shortcuts are more configurable, and you can create your own.

One of my favorite new features is called Quick Fix, which is a little hard to explain, but awesome when you get it. Let’s say you’re working in a file, and you know you need a function down the road but don’t want to stop your flow to go off and write it. So you write the call out, and your editor gives you red squiggly lines telling you that the function is undefined. But ColdFusion Builder gives you a yellow squiggly. This isn’t that exciting, except that when you see a yellow squiggly, you can hit a shortcut and get the option to generate that function. ColdFusion Builder will then generate the function definition for you, including typing any arguments in it based on what you passed into it when you wrote the call. Very cool, very productive. It’s also not limited to just functions. You can create standalone functions this way, or functions in existing CFCs, or even CFCs.

Finally, my favorite feature from ColdFusion Builder 1 is getting an upgrade. ColdFusion Builder Extensions have gotten some cool treatment from the team. There is tons more interactivity between the server and the IDE. Extensions can now launch in views, instead of a modal box. Finally, extensions can even add their own custom Code Assist.

All of these features and more are available for download today on Labs. Get it, try it out, and get more productive, today.

Go get it at http://adobe.com/go/cb2.

Three Choices

I was reading a review of Driving Technical Change by Roger The Geek (his label, not mine.)

He has both positive and negative things to say about the book. Read the review, I think his criticism’s fair. However he said one thing that sticks out to me.

Do you want to fight for technical change on your team or do you move from team to team or company to company looking for that great fit?

Basically, in early talks I gave on this I phrased it a little different:

You have three choices:

  1. accept the status quo
  2. leave
  3. change your organization

 

This was inspired by Martin Fowler‘s quote:

You can Change Your Organization or Change Your Organization.

The problem I see in Roger’s question, is that it sort of assumes that work has only one compelling feature: the work. I see this from time to time, and I’m not entirely sure that Roger is saying this, but I feel in the minds of many people it assumes that passionate people don’t stay at a job where people are resistant to change. It implies that the people that do want better things have to leave to grow.

I know it’s not trendy to say this, but there are times where being an adult means that you can’t just hop from job to job following your passion. Having a family, a mortgage, and other ties require that from time to time you have to suck it up for a paycheck, heath benefits, and stability. You aren’t always free to leave.

This is not to take shots at people who set up their lives to enable this. They value their freedom, and they earn it by sacrificing other things. I respect and admire that, but theirs is not the only path to passionate fulfillment in your life.

This is also not to say you shouldn’t try to leave a bad situation. Just that you have to weigh your options and take passes on riskier ventures waiting for the right opportunity.

But while you wait where your coworkers aren’t interested in change, what do you do? If you cannot leave, your choice is between accepting the status quo, or changing the organization.

I’d argue that if you accept that status quo it is the first, if not the only, step to giving up on the passion at your job. That’s cool. No judgment. It might be right for you. It was decidedly not right for me.

Let’s assume that it’s not right for you – you have the passion to want other things, and as stated before you can’t change jobs… then you’re going to have to change your organization.

At first that seems like you’re making a poor decision. Fighting a fight that you cannot “win.” But what is “winning”? I’d argue that making your organization better isn’t a journey to a destination – it’s the journey itself. So even if you don’t get everything you want, you can still effect some change, rejecting the status quo, and making yourself a little happier in the meantime.

Success at change has to measured by your deltas, not your destination or current location. People tend to lose sight of the fact that between where you are, and where you ultimately want to be, there are many, many better places.

Keep that in mind as you drive change.