What are people using the develop applications and mobile apps now-a-days? A whole lot of Object-C for iOS, with an eye towards Android and HTML5 – and when it comes to corporate apps, there’s a fair amount of Flex to be had. That’s what the folks over the consultancy Gorilla Logic have been seeing of late, at least. In this episode of make all, I talk with Stu Stern of said gorillas about the stack choices and projects he’s been seeing. We also cover unit testing in Flex and mobile, as well as plenty of other little topics here and there – like the history of applets!
Download the episode directly right here, subscribe to the feed in iTunes or other podcatcher to have episodes downloaded automatically, or just click play below to listen to it right here:
Show Notes
- Gorilla Logic history.
- Mobile stack choices.
- What’s “wrong” with Xcode (Xcode 3 at least)? Team support, stuff that you’re going to do in an enterprise environment is a pain, debugger is laughable – Xcode is definitely no Eclipse. That said, we recommend that for external facing apps, you gotta go native.
- Web-page driven apps vs. full-on client apps (like mobile apps).
- HTML5, GWT, Ajax, and all that.
- Switching to Flex development – how have the Gorillas seen the use of Flex evolve over time.
- Types of Flex applications seen of late: workflow designers, drag-n-drop, graphically wire things up.
- “If you don’t have a problem with the Flash Player, use Flash.” For CMS, using other stuff, but for apps, why not Flex.
- For others, web stuff, seeing lots of GWT and jQuery.
- What’s the Flex toolchain look like?
- Testing allt his stuff – comparing Flex to web apps.
- Java + Flex a common stack? BlazeDS talking to Tomcat, Hibernate, sometimes Spring – Flex on the front-end
Transcript
As usual with these un-sponsored episodes, I haven’t spent time to clean up the transcript. If you see us saying something crazy, check the original audio first. There are time-codes where there were transcription problems.
Michael Coté: Well, hello everybody! It’s another episode of ‘make all’, the podcast about fun and interesting stuff with those damn computers.
And this time, as we have been doing recently, we’re kind of taking a survey of what people are doing out there and the different sorts of technology choices they are making for interesting types of application development. And to do that, we have a guest with us. Do you want to introduce yourself, guest?
Stu Stern: Yes, I am Stu Stern and I am President and CEO of Gorilla Logic and we are an application development firm based in Boulder, Colorado.
Michael Coté: And do you want to give a brief sort of history of the company, because that was one of the reasons I was interested in talking with you as you’ve sort of been around for a while as they say. So it seems like we had an interesting discussion about the evolution of different types of applications and choices and things like that?
Stu Stern: Yeah, so let me — in terms of who I am, first of all, yeah, I am old doing this stuff for almost 15 years, and Gorilla Logic was found in 2002 by myself and a couple of other Sun Microsystems refugees. I was actually a Senior Executive at Sun and ran Java Consulting globally there for many years. I actually started that business in 1996 and right up till 2002 when we started Gorilla Logic, that’s what I was doing at Sun.
So you maybe wondering what I actually know in a real way about programming computers at this point, having been a suit, but actually I am the ‘CEO’ who writes code, and one of the pleasures of leaving Sun and starting my own company is that I did roll up my sleeves again and I’ve written an awful lot of code in the last eight years including two open-source tools, FlexMonkey and FoneMonkey, I was the original author of those tools.
And I also just have a long — before Sun I was building Real-Time trading systems on Wall Street, so have certainly built systems in anger and in dangerous environments.
Michael Coté: That’s right. So you must have been one of these people a few years ago when Twitter was failing where you’re just like, you should figure out these cue things, we used to use these for I don’t know global financial trading that was like up to the millisecond and it worked out just fine, there was a funny time back then. There was sort of like the enterprise crew who was not quite sure what was going wrong over there on the West Coast, if you will.
Stu Stern: It’s funny, when I first started doing the Java stuff at Sun and it was `96 so kind of the not quite the dawn of the Internet of course, but certainly that was kind of the year that the Internet started to get big in business, it’s an interesting Brochureware everywhere, and it was like the Internet it was hep and new, and all the stodgy companies that we are just having their minds blown by completely new technical challenges, and also just you know the need to kind of be hep and kind of the joke back then, I had this pitch I was doing, it was titled Suits and Tie-dye. And it’s kind of like the cool world meets the corporate world.
It’s interesting again I think with the rise of mobile now, additional shock to the system in terms of now needing to create compelling user experiences and certainly, similarly again having to adopt some fairly new, and in the case of Objective-C and Xcode, some kind of nauseating in some cases on new technology.
Michael Coté: Have you come across a phrase like Brochureware for mobile apps, has someone come up with some? And for those who don’t remember I guess Brochureware was basically like you would almost literally and somewhat metaphoric, you have taken a physical brochure, a piece of paper and converted that to a webpage. And so the knock was that it was kind of like why -– it was not useful, it was just like a website for a website, but I don’t know, I haven’t thought about that but there surely, there must be some sort of phrase.
Stu Stern: I suppose we could just -– well it might now be referred to as a static website.
Michael Coté: There you go, the name got more technical.
Stu Stern: No, I mean I think it’s too much work.
Michael Coté: Yeah, you wouldn’t do a Brochureware Objective-C app if you will, that would not —
Stu Stern: Certainly I wouldn’t.
Michael Coté: Well, on that topic like you know I mean since you — it’s sort of like a wide range of plethora if you will, of like technologies and stacks you can use to do mobile app development and a fair amount of or some of what you guys are doing nowadays is just helping companies do their mobile apps, if I remember whether it’s sort of internal or external sort of facing things and I am curious.
Just to lay out the assumption that I come across quite a bit, it seems like there are sort of three tiers of choices that people go through. I’ll be interested to hear the decisions people go through when they are making apps and it’s sort of everything kind of knows that they need to do an iPhone app, right?
(00:05:07)
But they also feel like the better choice would be to do sort of like an Android app for some reason. And then the even better choice would be if they could do an HTML5 app, because it would be more cross-platform and everything. But I kind of feel like the shortest path to an acceptable, if not great victory, in a lot of people’s mind is just to whip out the Xcode and start doing some Objective-C or something.
But I don’t know, I mean that’s kind of a tongue-in-cheek sort of overview of what I see, but when you are sitting down with people that kind of plan out their mobile apps, like what’s the kind of thinking they go through and then what do they end up actually doing?
Stu Stern: Yeah. No, I mean, I think you are right on in the way you have categorized it. I think that in terms of, people would like to use Android I think that’s because it’s good old Java and good old Eclipse. The SDKs are different, obviously the widgets are different but it’s not — I mean, Xcode, as I say, is quite a shock to the system. So it’s a fairly easy transition I think for people that have been doing Java UI Dev to make the transition over to Android.
But kind of an interesting thing I think — well, before I get to that, let me back up and fully answer those current questions. In terms of I think — yeah, I mean, people would like to use HTML to be cross-platform. Theoretically, you can reuse assets you already have on the web, just rescan, obviously the footprint is different.
So what we are seeing is most companies kind of go through anger, denial and realize that yeah, they are just going to have to bite the bullet and deal with native Objective-C and at this point in time you can’t do — with a Mobile Safari app, for example, you cannot get the richness of user experience, you don’t have the palette of user components available, of the fancy input gestures.
And obviously Apple raised the bar very high and so if you don’t want your app to look cheesy, you have got to go native.
Michael Coté: Yeah, in this conversation I always think of — at an even more encompassing level, there was that post that some Evernote guy did a while back saying how they are glad that they chose to do native desktop applications and native iPhone apps and whatnot instead of having a — I guess using the modern day equivalent of Swing, if you will, to have the same platform everywhere.
I guess we haven’t quite solved the write one UI that runs anywhere problem at the moment in the mobile space.
Stu Stern: No. Although I think Adobe, Adobe was kind of on a good track there.
Michael Coté: Yeah, that’s a good point.
Stu Stern: So unfortunately kind of Apple derailed — just refusing to let Flash on the phone. But we certainly, as a Flex shop and other thing that we are really into, we love Flex as a UI development environment, we think it’s really, really well done, really nailed the UI development program I think, the programming problem.
Kind of a lot of stuff that was very weird in the Java space, all these permutations of Swing and JSP and JSF and Adobe just kind of took a step back and said, look, what are the issues we need to really address here in terms of binding values to things and event handling and so on and kind of dealing with the two-headed world of, there’s the world of code and the world of tags.
And with Flex, all that stuff is very nicely united and it’s not like you are moving from — moving from tag world now over to code world now, and this is beautifully interweaved.
So as I said, we like Flex; it produced beautiful apps, killer component kit, so we were very — we had high hopes for Mobile Flash and Flex, but of course Apple has created this artificial stumbling block for Adobe by saying, no Flash Player, although they have loosened things up now and Adobe is working on the Cross Compiler.
Michael Coté: Have you guys had experience with — is that what they officially call it, the Cross Compiler, but with the —
Stu Stern: I don’t know what they officially call it, and I am not — and I don’t know. I mean, I certainly have not heard that it’s ready for prime time yet, but I can’t say that definitively. I am fairly certain that that’s the case.
Michael Coté: Right.
Stu Stern: It’s definitely some days in any case.
Michael Coté: So like — one thing I am curious to hear, you speak to since you guys have experience in this is, in my wording, but you are kind of saying this like to ask the question, so what’s wrong with Xcode and Objective-C, like what’s the problem with it, why is it so onerous?
(00:10:00)
Stu Stern: I go to first say that Xcode 4, I have not put through it pace as yet. So Xcode3 in terms of team support –- stuff that you are going to deal within an enterprise environment and a team environment like you are managing code across a number of people is a bit pain in Xcode, doesn’t work well with tools like Subversion. The debugger is laughable.
Xcode is definitely no Eclipse and it is annoying -– I mean there are folks at Gorilla Logic that like to say, Apple has disdain for developers. It’s like they do it on purpose. It’s annoying and that it seems like that in a lot of ways it’s just Apple going out of their way to be proprietary not that Apple would ever do.
But you have this cross platform IDE out there called Eclipse that certainly they could have used as a basis for their IDE. So I mean, I don’t see anything, and the reason why they had to totally go off with Xcode and why not just go with you know with what’s arguably the industry standard now.
Michael Coté: Yeah, I mean, there is always lots of good and slash and conspiracy theories about why Apple does what it does. And one of them that falls — has a foot in both of those kind of -– both in the hard hat and a foil hat sort of world if you will. I don’t know, there is something about being to be able to control the whole platform and that allows them to deliver good product and so forth and so on.
And to some extent obviously like controlling the app store is nice because you then have the choke-hold on revenue in a good and a bad way and but I don’t know, I mean, I get the feeling that like, I am not sure the development tool is really that important of a control point. Like in this day and age, right? It doesn’t really -– like it is kind of like in the olden days as it were, it was important to control the full stack, but that’s kind of like really old thinking. Like if anything, as new as that kind of thinking can be is kind of like the mid late 90s maybe.
Like I am never really sure why controlling the tooling matters, bubbles up, up the stack as much as some companies seem to think they will.
Stu Stern: Yeah. I mean, certainly one cynical view of it might be that Xcode only runs on the Mac, so certainly they are forcing a lot of developers to move over to the Mac.
Michael Coté: That’s true, I mean there is that, that’s kind of a cheesy – I mean it’s kind of a cheesy motivation in the sense that I feel like those developers would buy a Mac anyways.
Stu Stern: Right. Certainly, as I am saying, as I am sitting here in front of my MacBook Pro and it’s like dearly love. But it just seem like -– of course, they just have to rewrite all the stuff that they would just be inheriting Eclipse and work on things like better debugger.
But again, I have high hopes that Xcode 4 is going to be bit better. But Objective-C in and of itself, I mean, ignoring the id, I mean Objective C is pretty, as I said is a big shock to the system when you are coming from languages like Java and any language really. Objective C is very –
Michael Coté: Yeah, I mean if I remember it’s from the next world, right? It’s a language so it’s like a first generation OO, Object Oriented language, which in the height of utopic OO, there was a lot of onerous things done to use that word again.
It seems like there was a lot of sticking to the orthodoxy of this idea that you had these like almost -– not almost, you kind of have platonic forms or classes and then you have the instantiations, and then I think something that kind of got dropped out of the way in the OO world was this idea that you are always passing messages back between them. As if they are like these orbs floating in the world, passing things to each other where you are sort of like developing random mobile app to maybe like help buy you coffee somewhere and you really could give a damn about all these great platonic forms and messages and everything you just want to sort of like exchange some money.
Stu Stern: Yeah, it is certainly yeah I mean, in terms of the utopic view, I mean, yeah, it’s got this whole weird message thing. I guess it’s supposed to be small talky, so it makes — the syntaxes is awkward. Beyond that there is just the annoying stuff around header files and just throw back to the past.
Michael Coté: And you know what, you said sort of lack of team support is always -– or to put it in another way, the kind of like easiness with going along with whatever tool change your team has to collaborate, right? I mean that’s always that bucket of junk goes by a lot of names and that is always –- that’s kind of the mark of a matured tool that it very easily fits with whatever way people want to manage stuff.
(00:15:08)
Including various version control things and being able to pass things around, and I think it is always easy to overlook that when you are working on a tool, because I don’t know, a lot of people I feel like when they are –- and the Java world is always good at not doing this, but they are not focused on version 4 of an application. They are really focusing on getting that first version out and they are not thinking about the sad sack, we are going to have to support the 4th version of it.
Stu Stern: And there are just other — like things in Xcode and again, maybe this better in Xcode 4, but generally my header file for me, like stuff like that that Xcode just doesn’t do, default property, and you got to go, hack a little amount of code in four separate places like, why won’t you just do that for me. And there is no good refactoring support and like I say, all the stuff that it has just spoiled us with, now we are back.
Michael Coté: So we have the sort of Xcode silo if you will. And so when you are looking at doing mobile apps like what are the other stacks if you will that come up that are sort of buyable options that you feel like you can use with the client?
Stu Stern: We really don’t – certainly for customer facing apps, when you got to provide a compelling user experience, our strong recommendation is you got to go native. But there are certainly other types of apps. It’s nice to be able to -– on the other hand it’s nice to have a full blown client side app that you are building, as opposed to trying to work around, whacked out kind of web application architecture. I think as you and I discussed briefly over the last week, that whole kind of page based model was not -– people did not go to that because it was a intelligent way to build apps, it was really response to technical constraints, bandwidth constraints primarily. You need to have these ultra thin clients.
I think people forgot along the way. I mean people kind of got brainwashed, like yeah, we build apps this way, because it makes sense. But it really doesn’t.
Michael Coté: Yeah, I mean, just to interject like, I was — funnily enough, coincidentally I was driving around yesterday and I was thinking like, I always like to spin up these whacky theories and the theory that I was spinning was that most major technological successes are like a misuse of technology, and I was thinking like the web for one is like what we do with the web now? I mean, it’s been forced into how we use the web, but initially, it was nothing to do with developing applications. Just like you are saying, it was about putting documents on the web and at best linking between them. And as well as HTML and HTTPP are both oriented towards that.
So we get these -– we get exactly what you are just describing, that sort of a page based application.
Stu Stern: Yeah, and in 1996, when I joined SUN the expectation was okay, Applets, this is going to takeover. Now you can actually deliver an application painlessly to the desktop, but again, your bandwidth constraints. There was also a lot of browser compatibility issues at that point in time with VM.
So people started moving and doing this really whacked out page based stuff and it was a couple of years before we settled down on how that stuff would look.
But once that kind of -– so called MVC3 model matured, people are building stuff that way and they are using things like struts, it was always — as I said whacked out way to build an app. The natural way, in un-natural act really. The natural act is to build to the client-side app. It’s not the clients server architecture, it’s massively scaling multi-tier, middle tier all that, but on the desktop, you just look at like writing an app, response to events.
And people I guess — SUN really just never swing — just look like crap in the early days, obviously never got traction.
So Abode, which is like, brought us the Flex, okay, finally client-side framework that lets me just write a client-side app and looks great, and we don’t have the technical constraints any more that kept us from doing that ten years ago.
So on the other hand, I will say, it is still nice to be able to build even an Objective C app and you are building an app as opposed to be doing some kind of whacked out rendering HTML on the server side.
Michael Coté: And when you guys are like collaborating with your clients, are they sort of getting that shift from webpage app to — I don’t know, a client app to use that term or is that something that you sort of have to massage into them if you will, like how do you draw out that distinction?
.
(00:20:10)
Stu Stern: It’s surprising that I have this conversation I am having with you, with customers oftentimes, because as I said, people just have kind got of — they forgot why we started building apps in this weird way.
So a lot of people just don’t know — like I said, they don’t really see a page based app versus a rich app.
The other thing obviously is the lines have been blurred with AJAX, which, as I say about AJAX, I mean, it’s a greatest branding campaign in the world because it’s not really about in terms of asynchronous JavaScript and XML, but it’s really about is JavaScript. When you are deciding to do AJAX development, you are really doing JavaScript development and I guess people were kind of embarrassed to be upfront about it, so they hide behind this AJAX.
Michael Coté: Yeah. No, I hadn’t really thought about that so explicitly, but I think you are right. I think the reputation of JavaScript has been laundered and refreshed through AJAX. I mean, nowadays, like right now especially, JavaScript is extremely — well, relative to what it used to be, it’s extremely respectable and that’s a good point. Probably no one would run around calling it JavaScript programming.
Stu Stern: And look, and don’t get me wrong. I am not a total JavaScript hater. I mean, I have an issue with — my issue with JavaScript is same I have had with a lot of high level scripting language is the tool support is just not as good.
I mean, one of the things that I lament most about Java’s death on the front-end, although — yeah, I think Android is resurrecting Java on the front-end, but the lack of tool support or just the inferiority of tool support for other tools. I mean, Java, the tool support is just so mature at this point. Eclipse, NetBeans, I mean, just beautiful, beautiful environments for doing Java.
So I think you can’t really have a discussion about development platforms without talking about the — or about user interface platforms, let’s say, without also thinking about the entire development tool chain behind it, and again, things like debuggers, refactoring support, how are you going to find the class that the method is being invoked on, all these things that Eclipse does very, very well and NetBeans do very, very well.
So coming back to — so you have got kind of this hybrid model of delivering pages that then have enough JavaScript in them that they all really are client-side apps. Of course that whole AJAX architecture, so to speak, or really more accurately, the whole kind of DOM Based programming model, doing that client-side stuff, also really evolved and fits and starts and it’s not really a coherent architecture.
Michael Coté: Yeah, it’s funny, because it’s very analogous to what I feel like HTML5 is now. There is kind of a definitive core kind of but then it’s a very small sort of maybe here is the thing that we can all agree on, but then everything else is just Venn diagram intersections, it’s all very fuzzy outside of that.
Stu Stern: Yeah, and again, what are you really — HTML5, again, is — it’s not really about HTML5, it’s really about JavaScript, right?
Michael Coté: Yeah, yeah.
Stu Stern: What are you writing in the client-side logic.
Michael Coté: Yeah. And I guess at best — I mean, to be — I am usually overly, I guess, cynical, in my phrasing about HTML5, but to be fair to it, I think the best definition that people work with is sort of — like exactly what you are saying, there is a lot of JavaScript obviously mixed with HTML5 and CSS, but then I think the more important thing that people usually mean is in a mobile context having some access to sort of native things that they wouldn’t normally have access to, whether it’s storing things locally or getting access to like the geo-location stuff or whatever.
Still, it’s not like there is like a 100 page spec of HTML5 you can download, that’s interesting.
Stu Stern: Yeah, and again, what IDE are you using and how are you debugging and all the rest. So HTML5 is — we are going to get there, wherever there is, but I mean today it’s still — as I say, so you are doing HTML5 development, what does that really mean? What are you using?
Now, on the other hand, GWT we like, although even in GWT you develop in Java, then you generate the JavaScript, to try to — they try to protect you.
And actually, recently I was struck, as I was using my iPad, even though I am kind of badmouthing Apple, as I said, they have disdain for developers but I love their products.
Michael Coté: Well, it’s sort of like — badmouthing Apple is like people who are like complaining about government spending as a drive down a federally funded highway and taking an exit ramp to go to an outlet store that was built with federal money. It’s sort of like — it’s just something fun to do.
(00:25:04)
Stu Stern: But coming back to, can you do a browser based app and have a decent user experience? I look at like Gmail, their iPad version, it’s very nice. They did a really, really nice stuff. You certainly don’t have the rich functionality of a native app, it would definitely be hotter, but it’s very, very usable.
So coming back to what’s the right tool for the job, one of the big — certainly one of the big considerations is, how sexy does the thing need to be? And I had an amusing discussion recently with a customer about an app that they were giving to their sales folks and they were very fixated — and for what they needed it. I mean, we believe they needed a native app, but they were very fixated on user experience, compelling user experience.
And I was just discussing like, look, you have got a captive audience here, it’s not like they don’t like your — and this is for their sales people, it’s not like if they don’t like you app, they are going to go use your competitor’s sales support app. This is the only app they can use, so clearly it has got to be usable, benefiting obviously, but it doesn’t have to be sexy.
Michael Coté: Yeah, yeah. And there is like — and you guys must encounter this quite frequently since you work on — like you were saying, internal facing and external facing stuff, and I feel like — when people are thinking about UX, a lot of people haven’t quite internalized the idea that UX on a consumer site, to some extent, means wasting a lot of your user’s time.
Because if you are doing a consumer site, it’s almost like you want your user to stay on your site as long as possible. Like with something like Facebook or something like Google, or Amazon I should say, you want them to buy more stuff, whereas to some extent for a corporate app, it’s kind of like the opposite, especially with some sales enablement thing. Like sales people are notorious for not wanting to fill out their CRM stuff.
So the less time they have to spend entering in the data is almost the more usable the platform is. So there is this stark contrast, if you will, I feel like between consumer usability and I don’t know, corporate usability.
Stu Stern: Yeah. I mean, it’s — and I think — look, there is just hotness. I mean, there is usability and there is sex. Like that Monocle feature in Yelp, the Augmented Reality thing, and clearly like — they don’t have to have that, but it’s totally way cool. It definitely increases your love for Yelp.
Michael Coté: Yeah, we could imagine like a coffee machine salesman having that right in his tool and he holds it up and he looks around him and he sees all the opportunities overlaid onto reality. That would help them do more sales I think. Some AR and prospecting.
Stu Stern: I suppose you can argue that it increases employee satisfaction, but I think you should probably just give people a raise and it will cost you less money than trying to build the sophisticated apps.
Michael Coté: So we have bumped up against Flex development quite a lot and I am curious to hear — kind of starting out with kind of like a historic thing of how you have seen Flex play out to work on application — like mostly corporate apps, but any kind of apps, because I feel like — looking at Flex, I feel like about maybe three years ago there was this moment where Flex was kind of poised to take over the front-end for Java applications, if you will, like there was the whole like Bruce Eckel was all enamored of Flex and other people were looking at it kind of seriously as a, I don’t know, as a Swing or AWT or SWT replacement or whatever, but then it kind of somehow fizzled out.
And I was all into the RAA world of like that’s a great way — as you have said many times, it’s a great way to develop UIs and everything, so we should kind of move towards that.
But I don’t know, something got a little wonky during they way, but there is still a lot of Flex development going on. So I mean, with that sort of spilling my brain on the table there, over the past few years like what’s been the evolution of Flex to how you guys are using it now?
Stu Stern: Well, we were seeing great momentum in the adoption, as you say, I mean, there was kind of initial excitement. It was funny actually, I mean, myself, when I first heard of Flex, which was maybe, I don’t know, four years ago, one of the guys at GorillaLogic, one of our Gorillas, as we say, was saying, hey, we were starting up a new app, new project and we were kind of taking a fresh look at the tools out there and this guy was very strongly recommending Flex. I said, I haven’t even heard of it. I said, what is this thing?
He said, well, it’s this thing, it runs on the Flash Player. I am like, wait a minute, a Flash Player, shut up. What are you talking to me about? Like we are not building an animation here, but you wouldn’t stop and somebody I respect , so finally I took a look and I was just so-so impressed.
(00:30:09)
And so I think that a lot of it was, if more people are taking a close look it was just such a no-brainer, it was so superior as a UI development platform and beautiful, beautiful results.
So, certainly ways you to build an app using Flex and then doing arguably with some –- even with someone like GWT, an evolved framework like that, and the results look killer. So it seemed like a no-brainer to us, we expected it to take over the world. And we were seeing, and what wasn’t happening at lightning speed, we were definitely seeing more and more and more Flex usage up until the infamous Steve Jobs’ letter of Flash over my dead body and that made people suddenly be very skittish about the Flash Player.
So I think that a lot of people have kind of put the brakes on Flex, a lot of people aren’t even looking at Flex now, because they just think, oh, no Flash on the iPhone. On the other hand, you know, again having talked about how you really need to go native on the iPhone, it’s like okay, well, it’s an island over there anyway.
Michael Coté: Yeah, yeah.
Stu Stern: So first the iPhone you’ve got to deal with there is a one-off, but for building certainly a web app today, and again an app, some kind of transactional thing that’s got rich, or let’s say – just something that’s got a rich user interface. We still think that it’s absolutely the best solution, and certainly with Flash Player out there in the world and virtually every buttons are out there. So I think that that companies that kind of take a step back and really think this through, we still see that Flex is a great option.
And Silverlight for that matter and I am not a Silverlight guy myself but I’ve heard good things about it, it’s supposed to be just like Flex, but that type of platform. Something with a client-side runtime that lets you do — put a real app out there. Again as opposed to doing what I still consider to be an elaborate hack using JavaScript and dealing with the Browser DOM.
So we’re still seeing, and certainly companies that are doing like we’ve worked with a couple of companies recently that are doing various types of — and these were kind of cloud service kind of companies that have fairly sophisticated apps that they are giving people access to from the cloud, and things that are doing like workflow designers, things that actually, you’ve got a drag-and-drop things, graphically wire things up, it’s hard to imagine how they would do to things like that without using something like Flex.
Michael Coté: Yeah.
Stu Stern: So certainly for any kind of truly which web app we’re definitely still saying people, look around at what’s out there at the site, yeah, Flex really is the best solution. So it’s not — I don’t know that it’s -– I would the obituary for Flex at this point, I mean there is still plenty of — absolutely plenty of Flex going on out there but it’s certainly not huge, certainly not taken over the world, no doubt about that.
Michael Coté: You are getting into like some of the requirements that would drive you to look at Flex favorably, and can you kind of detail some of the other types of applications that you have been seeing Flex used for, you guys have been helping out with, I mean I am always curious like what the workloads are, to use an archaic term, what the stuff is?
Stu Stern: Yes, what we still tell people is if you don’t have a problem with the Flash Player use Flex, and it’s for anything, I am sorry, not for — there are two sides of the world, as I know, you know Michael, there is content and there is apps. So for the content side, okay, yeah, whatever. Content Management System, Drupals and — we love to hate it.
But things like Drupal, and then there is the actual app dev side, and so if we are going to build an app, even a simple app, you are not looking for rich user experience, Flex is still -– it’s easier to build an app with Flex. And especially with Java on the backend, I mean it just works so beautifully with Java, with stuff just coming down from — over HTTP connection and then binding through objects and your app, it’s the whole blaze, the S framework for talking from the clients and the server, are just beautiful stuff that are going to make building any application easier. So we always recommend it and where customers really don’t have a choice. When there comes this point, where yeah, what we are trying to do is so sophisticated from a UI perspective, that we would be insane to try to do it without Flex or perhaps Silverlight.
(00:35:07)
But then certainly for a simple app, you could get away with using other — we see a lot of GWT and a lot of jQuery for people that are trying to get rich functionality but have some issue with the Flash Player.
Michael Coté: Right, right. And since we are talking about Xcode in relation to like team support and stuff like that, like what’s kind of the, I don’t know, the tool chain of team collaboration or ALM in the lower meaning of that, that you guys use around like Flex app development, like what does it look like?
Stu Stern: Yeah. You have got to use Flash — well, I guess in here you can use the command line tools, but we use Flash Builder, virtually everybody uses Flash Builder. And Flash Builder is — it’s an Eclipse plug-in, so fundamentally it’s Eclipse with ActionScript compiler and various other Flex specific tooling added to it. But it feels pretty much like Java development, thought not quite as good.
Again, as I said earlier, I mean such beautiful tooling for Java at this point in time, but it’s quite good.
And we use Subversion. I mean, there is nothing — I mean, it’s fairly — Flex tooling I think looks just like Java tooling other than you have got this Flex specific stuff in Eclipse.
I am trying to think what are the other key parts of the tool are. Well, things, again, like things that are analogous to Java, like FlexUnit. Obviously we use FlexMonkey, when you plug-on free and open source testing tool for Flex applications.
Michael Coté: That’s right. Let’s speak of that a little bit, because we talked about that when we spoke obviously and I think — is there — whenever you write a testing framework for some framework, you kind of get very intimate with the framework. So, I wonder if you can compare kind of like the testability of a Flex front-end versus the testability of, I don’t know, whether it’s an AJAX or it’s GWT, or jQuery or whatever front-end, is one of them easier or better than the other, or are they just kind of different but sort of the same, if you will?
Stu Stern: No, I think that rich Internet apps, and I am including mobile apps in that category, there are inherent challenges to doing recording and playback for those types of apps, there is just a much wider palette.
When people think about record playback testing tools like FoneMonkey or FlexMonkey, as I did, when I started doing FlexMonkey, the naive view is, well, look, it’s all event based and these RIAs, all I have got to do is just load the events and then I have just got to play it back the events.
Michael Coté: And then magic.
Stu Stern: To me. And then you bump very quickly into reality, which is, okay, well, semantically that’s really low, like you can’t be recording mouse events, like you don’t want to record every mouseover event, every drag event, every click down and click up necessarily, so the first thing is this filtering problem.
But then there is also this kind of semantic issue of, ultimately what — I mean, you could get away with just recording the user interaction, mouse click here, they typed over here. But then you wind up at the script that’s very low level, very unreadable, very un-maintainable. You don’t want to be recording they clicked on this coordinate, you want to be saying, hey, they opened the combo box, hey, they selected this option from the combo box.
So very quickly — then as you are thinking about that problem, you start to realize, oh, I really need component specific recording and playback code for a lot of components. Like there is a lot of inherited behavior, because in a lot of case it is just, they clicked on me and that’s the essence of the recording of the playback, so there is a lot of inherited behavior certainly.
But then there is an awful lot of component specific behavior that you have just got to write code. So it’s definitely — so in terms of Objective-C versus — or more accurately Cocoa Touch versus Flex — you know actually in terms of automation, Objective-C, and it’s not only so much an Objective-C thing, but a kind of lower level language, a language that hasn’t removed the guns and knives, as James Gosling once characterized Java, being C++ without the guns and knives.
(00:40:01)
The guns and knives are actually very, very useful when you are trying to do the kind of whacky stuff, we have to do non-invasively get into your app and intercept, what’s going on and play things back.
So being to be able to do the low level kind of things that Objective-C, that for normal app development are really guns and knives. They are just places to get into trouble and get really nasty bugs to track down.
For that kind of stuff, you can do all kinds of interesting tricks. Certainly one of the big challenges that anybody that’s dealt with any kind of RAA testing and you’ve been using your big money tools like UTP, component identification. So say, I am clicking on this button. Well, how do you identify this button?
So one of the things you bump into very quickly with Cocoa Touch is — yeah, there is no such thing like component identifier. There’s not even an id attribute.
Michael Coté: They are just like events from anonymous sources?
Stu Stern: It’s like it’s not addressed. So we’re looking on like — what can we use and we find, oh, accessibility label. Okay, every bolt components have an accessibility label on them. So, it’s kind of gratify — we thought it was really weird and hacky, but we are like whatever, it’s the only thing we got. So we were kind of gratified, later, last year when Apple came out with the UI automation framework that — that’s what they tell you to do. You got to put accessibility labels on everything, that’s how we do it.
Michael Coté: Yeah, that is clever. Once again, it’s using technology in an unintended way — but it works.
Stu Stern: You are doing well, all doing good, right, so you are at least — you are making. That’s about the same time you are going to make it attestable. So may be Apple was ingenious in this respect.
Michael Coté: That’s right, that’s right. Well, great. — I think we have kind of like — I am sure we could speak for a long time about all these fine choices and platforms and everything. — I think we have gotten a good overview of kind of just like — when you guys are working with people to figure out these different apps, whether they are web apps or internal things like what — the kind of stack that you guys end up using. I guess, there was just one more thing, like on the flex front, that I am always curious to ask you, but then you mentioned that kind of in passing.
So you mentioned having a lot of Java on the back end and using BlazeDS to connect the Flex front-end to the back-end. I am curious like what typical sort of boxes and arrows of the stack reflex that. Is it very typically Java on the back-end, with sort of using Blaze or HP stuff to top with the two of them — what’s kind of like that —
Stu Stern: Very typically — yeah Blaze, talking to Tomcat. The server end of Blaze running in Tomcat and then, it’s just a kind of where we are looking Java back there so, typically hibernate. And sometimes spring — certainly back there, you might be doing Blaze talking — I am sorry to –- I said swing, I mean to say spring. But many of that — kind of a very typical looking Java back end, there’s not — I don’t think it looks different terribly than what you would have on the back end of a web app.
So in terms of multi-tier architecture, just kind of taking that with a page or something, we would go, that’s kind of moving over to the front end. So the usual stuff back there, you don’t — hibernate — so nothing shocking.
Michael Coté: So the back end is kind of like the typical enterprise Java Stack that people are comfortable with. Talking about — more importantly the modern day enterprise stack which doesn’t really have an app server, but its using Tomcat as the container as people like to say.
Stu Stern: Yes, absolutely.
Michael Coté: Sort of the run time environment.
Stu Stern: Or Tomcat or the more equivalent one, you might be using WebLogic or Jboss.
Michael Coté: But it doesn’t sound like there’s a whole lot of EJBs running around?
Stu Stern: There’s not — there’s one customer — a big customer we are working on right now. So yeah, — so it’s not like we don’t run into it. There are definitely people that do the whole EJB thing. Especially if you are building a kind of a captive back-end, you are building a back end to support a specific UI, you certainly don’t need EJBs to do that.
Oh, yeah let me clarify that — EJB3. When you talk about object remoting as one, not really saying too much EJB like that, but certainly EJB 3 is an year-old, something like hibernate, yes, plenty of that. It’s kind of annotation based persistence definitely. But it’s a typical back end Java stack. As I say, I mean Blaze just mixed the integration with Flex so painless, that we just think it’s a great end-to-end architecture.
Michael Coté: Yeah, it takes care of that — going way back — all that fuzzy message passing between the magic orbs.
Stu Stern: Serialization, de-serialization stuff.
Michael Coté: Yeah, that’s always nice to not have to worry about.
Stu Stern: Yeah, absolutely.
Michael Coté: So wrapping up here, if people want to find out more about the Gorillas if you will or yourself, are you guys in the Twitter and you have got a website and all of that, like what do you want to post here at the end for people to get more information if they are curious.
Stu Stern: I am not at Twitter, but www.gorillalogic.com is the home of the Gorilla’s and —
Michael Coté: And I have to say, — I was pleasantly surprised that you guys use Gorilla’s even more than I thought you had pictures of Gorilla’s so that’s fantastic.
Stu Stern: Yeah, when you look at my picture on the management page, I have got a hair cut since then. But gorilla.com, is also the home of our open source projects, you can get information there about FoneMonkey and FlexMonkey. The Gorilla Logic blog is also quite an interesting place, we do actively blog. So yeah, come and see us.
Michael Coté: Yeah, well, great. I appreciate you just sort of hanging out here and diving into the stack stuff that you guys have been seeing. That’s always fun to talk about. So thanks.
Stu Stern: Yeah.
Disclosure: see the RedMonk clients list for clients mentioned, like Adobe.
Who's using virtualization?
Education, construction, and lawyers are using virtualization the least, according to a recent data sample of 100,000 companies from Spiceworks. On the other end of the spectrum, software, energy, and aerospace companies are big users. Spiceworks asked me to write-up some commentary on this (and a few more future) data analysis over their massive, mostly SMB IT user-base. They also ranked hyper-visor usage by vendor.
I wanted to get a sense from the two end the usage spectrum, Education and Software, of how and why virtualization is being used. Do do that, I talked with Jeremy Fluhmann (Technology Director for Winters ISD) and Matt Ray who works at Opscode (one of the more advanced IT management startups). Both gave me good insight into how their industries are using virtualization.
I wrote up my commentary over on our brand-spankin’ new Spiceworks page. Tragically, the page doesn’t let me link directly to the post, but it’s at the top of the discussion forum, so you can get to it pretty easily: check it out if you’re interested in how folks are (or are not yet) using virtualization.
Disclosure: Spiceworks is a client, as is Opscode, VMWare, and Microsoft.
rev="post-6362" 2 Comments
Categories: Systems Management.
Tags: cases, education, Jeremy Fluhman, Matt Ray, Opscode, spiceworks, Spiceworks data commentary, virtualization