One thing is becoming more and more clear. Large companies that are users of Eclipse technologies are getting more and more involved directly in the building of those technologies. I've definitely seen this in the CDT space where probably about 1/3 of our committers are from companies like this.
One thing needs to be made clear, though. This is a gigantic shift in the tectonic plates that is the embedded software business. Supply chains are king and in the past companies relied solely on their suppliers to meet their needs and were held accountable for anything that went wrong.
With the advance of open source technologies in these companies, I'm convinced it requires a change in strategy for the suppliers. Suppliers need to be more sensitive to the aspirations of their customers in open source. I'm not sure what that means and how they need to change their practices to accommodate this change in the industry. But those that don't change will be hurting somewhere down the road. It's an interesting and scary time all rolled into one.
Tuesday, March 29, 2011
Wednesday, March 23, 2011
Eclipse and the Post-PC Era PC
The best thing about EclipseCon isn't the sessions, although all the ones I've been to so far have be great and educational. It's not the receptions, although what a great way to get a feel for the energy around Eclipse. It's not the beer, sacrilege you say. It's those little conversations you get into with fellow Eclipse contributors about the craziness we could get into if we dare try.
Last night I was talking to an e4 committer to be unnamed to protect the (not quite) innocent. I was commenting that e4 really has piqued my interest with the performance and the promise of flexibility. But the one thing that really bugs me, and I mean really bugs me, is the editor area and how it looks so different from the editor area we have in 3.x and really sticks out like a sore thumb. He explained that it was intended to support the use case where you have two editors split in the area to do a file compare and you wanted to send them both into a shared full screen mode.
OK, I get that. But I do fear though for the poor new user who will see this and be really confused at look of it. He may not think immediately that there's a problem, but something will be latent bugging him that things just aren't quite right and he'll feel comfortable and uncertain about why things look the way they do. Not to mention the screen real estate it takes up.
At any rate, this blog isn't about that. It's about what I brought up next. I jumped into the rant I started with my last blog entry about the need for us to take very seriously that we are building this stuff for humans. We need to empathise with them, and as technologists, we aren't very good at that. It's just part of our nature. And it's worse when we actually think we are when we're not, and that's how we get so much crappy software out there in the industry. We need to build are software organizations and get into our DNA that it takes more than just great technology to make great products. We need to understand or get people who's job it is to understand humanity and what the humans who are are customers real needs are, especially the ones that they can't even express themselves.
And we all know by now that Apple and the rest of the tablet vendors (and I played with a live RIM Playbook yesterday and it's pretty hot) get this and have it in their DNA to get usability right. And I have a burning curiosity about what the world would be like if that effort also went towards fixing the usability on my laptop and what a "Post-PC Era PC" and particularly Android Honeycomb like the one that ASUS recently announced. They've managed to take their work from 4" smartphones to 10" tablets. Can they take it to my 15" laptop and my 24" desktop. I think, or at least hope, so.
And I pose the question, what would Eclipse look like on this device? What would Eclipse look like if it was an Android app that followed the look and feel of the other Android apps. We pondered that for a bit. There wasn't an overwhelming favourable response from the crowd that had gathered by that time. But I am very curious and hopefully we can at least understand what the tablet makers are trying to accomplish and help drive forward that kind of innovation in usability at Eclipse as well.
Last night I was talking to an e4 committer to be unnamed to protect the (not quite) innocent. I was commenting that e4 really has piqued my interest with the performance and the promise of flexibility. But the one thing that really bugs me, and I mean really bugs me, is the editor area and how it looks so different from the editor area we have in 3.x and really sticks out like a sore thumb. He explained that it was intended to support the use case where you have two editors split in the area to do a file compare and you wanted to send them both into a shared full screen mode.
OK, I get that. But I do fear though for the poor new user who will see this and be really confused at look of it. He may not think immediately that there's a problem, but something will be latent bugging him that things just aren't quite right and he'll feel comfortable and uncertain about why things look the way they do. Not to mention the screen real estate it takes up.
At any rate, this blog isn't about that. It's about what I brought up next. I jumped into the rant I started with my last blog entry about the need for us to take very seriously that we are building this stuff for humans. We need to empathise with them, and as technologists, we aren't very good at that. It's just part of our nature. And it's worse when we actually think we are when we're not, and that's how we get so much crappy software out there in the industry. We need to build are software organizations and get into our DNA that it takes more than just great technology to make great products. We need to understand or get people who's job it is to understand humanity and what the humans who are are customers real needs are, especially the ones that they can't even express themselves.
And we all know by now that Apple and the rest of the tablet vendors (and I played with a live RIM Playbook yesterday and it's pretty hot) get this and have it in their DNA to get usability right. And I have a burning curiosity about what the world would be like if that effort also went towards fixing the usability on my laptop and what a "Post-PC Era PC" and particularly Android Honeycomb like the one that ASUS recently announced. They've managed to take their work from 4" smartphones to 10" tablets. Can they take it to my 15" laptop and my 24" desktop. I think, or at least hope, so.
And I pose the question, what would Eclipse look like on this device? What would Eclipse look like if it was an Android app that followed the look and feel of the other Android apps. We pondered that for a bit. There wasn't an overwhelming favourable response from the crowd that had gathered by that time. But I am very curious and hopefully we can at least understand what the tablet makers are trying to accomplish and help drive forward that kind of innovation in usability at Eclipse as well.
Monday, March 07, 2011
Understanding Apple's Greatness
As a senior software engineer wondering how the hell does Apple make such great products, if you do anything, listen to the last five minutes of Steve Jobs' keynote introducing the iPad 2. It opened my eyes and made me a believer. Here's what he had to say:
"It's in Apple's DNA that technology alone is not enough. That it's technology married with liberal arts, married with the humanities that yields us the result that makes our hearts sing. And nowhere is that more true than in these post-PC devices. These devices need to be more intuitive than a PC where the software and the hardware and the applications need to intertwine in a more seamless way than they do on a PC. And we think we're on the right track with this. We think we have the right architecture not just in silicon but in the organization to build these kinds of products".
It's the passion with which he said it, and the proof in the products that Apple continues to deliver, that have won over an army of fanboys, that proves he indeed does have the right formula. Technology built for humans, what an incredibly simple yet unappreciated idea by so many in our industry. Sure we have the odd usability expert sprinkled through our organizations, but to have an organization and culture and passion built around these ideas? What magic we could make.
The good news is that I don't think Apple has a patent on these ideas. If they do, I quit now. But I don't think so. Is it possible for a techie to understand what needs to be done? I have my doubts. Techies are an odd sort. We've all seen it. The uber-geek who writes a killer algorithm to make products sing. But he needs help. He needs that special someone to show him how to take that algorithm and produce something regular people will fall in love with. The path is there, and we see it in everything that Apple makes, it works. But don't let them have a monopoly on it.
"It's in Apple's DNA that technology alone is not enough. That it's technology married with liberal arts, married with the humanities that yields us the result that makes our hearts sing. And nowhere is that more true than in these post-PC devices. These devices need to be more intuitive than a PC where the software and the hardware and the applications need to intertwine in a more seamless way than they do on a PC. And we think we're on the right track with this. We think we have the right architecture not just in silicon but in the organization to build these kinds of products".
It's the passion with which he said it, and the proof in the products that Apple continues to deliver, that have won over an army of fanboys, that proves he indeed does have the right formula. Technology built for humans, what an incredibly simple yet unappreciated idea by so many in our industry. Sure we have the odd usability expert sprinkled through our organizations, but to have an organization and culture and passion built around these ideas? What magic we could make.
The good news is that I don't think Apple has a patent on these ideas. If they do, I quit now. But I don't think so. Is it possible for a techie to understand what needs to be done? I have my doubts. Techies are an odd sort. We've all seen it. The uber-geek who writes a killer algorithm to make products sing. But he needs help. He needs that special someone to show him how to take that algorithm and produce something regular people will fall in love with. The path is there, and we see it in everything that Apple makes, it works. But don't let them have a monopoly on it.
Friday, February 11, 2011
Mobile Platforms Rule, Next Stop Desktop
What a crazy week in the mobile world. Android's tablet buzz continues to gain steam towards an imminent launch. Rumors of Apple's iPad 2 are starting to roll in. Rumors of RIM's BlackPad, uh, I mean PlayBook, running Android apps. Then some concrete announcements from HP on the rejuvenated webOS with some nice looking phones and tablet. And today the big Nokia/Microsoft Phone announcement. How does one keep up with it all while trying to do their day job :).
With all that's going on, it's pretty clear one thing in my mind. The rate of innovation in the mobile space is stunning. Why did it take these new platforms to unleash all this creativity. Why doesn't my desktop look as sexy as all these tablets? What a price we paid for platform certainty under Microsoft, the closed hardware ecosystem of Mac, and the lack of real investment into the usability of Linux. It's quite sad, really.
But I also sense opportunity. I've been closely following the progress of the android-x86.org project as they attempt to bring Android to x86 platforms, because I'm very curious about how the Android experience could scale to the traditional netbook, notebook, desktop. Frankly, it isn't very good. But with Honeycomb, and the focus on larger screens, I have hope that will change. We'll see when Honeycomb hits the AOSP.
And that thinking was somewhat validated by one of the most interesting announcements out of the HP event, at least in my mind. And that was the intention of HP to bring webOS into the PC space as well. Now all we got were words and almost no details, let alone a demo, but I am very curious about what they are going to come up with, and whether it will actually pan out or not (there was a sniff of vaporware in the air).
So we'll see where this all lands. I hope we find out soon as this thing is keeping me up at nights thinking of all the possibilities and how this will change app development. As I keep saying, it sure is a great time to be a software developer. The shackles of the past couple of decades have been released and innovation is rampant.
With all that's going on, it's pretty clear one thing in my mind. The rate of innovation in the mobile space is stunning. Why did it take these new platforms to unleash all this creativity. Why doesn't my desktop look as sexy as all these tablets? What a price we paid for platform certainty under Microsoft, the closed hardware ecosystem of Mac, and the lack of real investment into the usability of Linux. It's quite sad, really.
But I also sense opportunity. I've been closely following the progress of the android-x86.org project as they attempt to bring Android to x86 platforms, because I'm very curious about how the Android experience could scale to the traditional netbook, notebook, desktop. Frankly, it isn't very good. But with Honeycomb, and the focus on larger screens, I have hope that will change. We'll see when Honeycomb hits the AOSP.
And that thinking was somewhat validated by one of the most interesting announcements out of the HP event, at least in my mind. And that was the intention of HP to bring webOS into the PC space as well. Now all we got were words and almost no details, let alone a demo, but I am very curious about what they are going to come up with, and whether it will actually pan out or not (there was a sniff of vaporware in the air).
So we'll see where this all lands. I hope we find out soon as this thing is keeping me up at nights thinking of all the possibilities and how this will change app development. As I keep saying, it sure is a great time to be a software developer. The shackles of the past couple of decades have been released and innovation is rampant.
Sunday, January 09, 2011
Coding from Workstation and PC to Tablet and Superphone?
In the early days of my career as a software designer, standard fair was to have a workstation on your desk. These were pretty big machines specially built to get as much power as it could out of hardware that we had at the time. They were pretty expensive, but they were the only thing that could run the tools that we needed to run. HP and Sun where the big players there, with Sun's SPARCstations being the cat's meow.
Then a major shift happened. Desktop PCs, driven by consumer needs and economies of scale, got to be as fast as these machines at a fraction of the cost. Yeah, you had to deal with Windows NT, but the economics of it really left us with little choice. And that left very few people still using workstations and it pretty much killed that industry, or at least left it to small niches and conservative companies that still fear Windows.
In the last five years, you see laptops starting to eat away at the desktop. There's nothing more liberating than sitting on you couch coding up a storm while the hockey game is playing in the background. Lots of software developers are using laptops as their main machine, yours truly included. The desktop machine is now only needed when I have big builds to do that require fast disks and 8 threads of CPU. Mind you if I could get that in a laptop that doesn't set my pants on fire, I would.
So all along it seems, we've been following the consumer as they paved the way to cheap and powerful computing devices. And as we've seen at recent Apple events and last week's CES, it's pretty clear the consumer is heading somewhere new, to the ultra-mobile with superphones and tablets. The question is, can we software engineers follow?
I think in the past we were able to follow because there were always high end versions of the consumer devices that could meet our needs. And it left in place one very critical tool for the software guy, the keyboard. Until we stop coding in text, we can't give up our keyboards. But aside from that, I don't see the high end version of these devices that could do a massive build or run a big IDE like Eclipse. They really are a new class that I don't think will cut it, at least not on their own.
So where does this leave us? Well, one answer jumps to mind which I'm not sure I like yet. There's growing discussions about cloud computing and doing software development in the cloud. I've investigated it myself in the past and it is a very plausible future. Though, I'm not sure we're ready to sit for a 10 hour day typing code into a tablet or superphone but I can imagine there being some use to being ultra-mobile for the software developer and not being too far away from his code. Tools like Hudson would show just fine viewed from a web browser on a tablet or from a smartphone app (which already exists BTW).
It's going to take some time to figure out how to leverage these devices, but you can count on one thing. We're all gadget junkies and we'll figure it out somehow.
Then a major shift happened. Desktop PCs, driven by consumer needs and economies of scale, got to be as fast as these machines at a fraction of the cost. Yeah, you had to deal with Windows NT, but the economics of it really left us with little choice. And that left very few people still using workstations and it pretty much killed that industry, or at least left it to small niches and conservative companies that still fear Windows.
In the last five years, you see laptops starting to eat away at the desktop. There's nothing more liberating than sitting on you couch coding up a storm while the hockey game is playing in the background. Lots of software developers are using laptops as their main machine, yours truly included. The desktop machine is now only needed when I have big builds to do that require fast disks and 8 threads of CPU. Mind you if I could get that in a laptop that doesn't set my pants on fire, I would.
So all along it seems, we've been following the consumer as they paved the way to cheap and powerful computing devices. And as we've seen at recent Apple events and last week's CES, it's pretty clear the consumer is heading somewhere new, to the ultra-mobile with superphones and tablets. The question is, can we software engineers follow?
I think in the past we were able to follow because there were always high end versions of the consumer devices that could meet our needs. And it left in place one very critical tool for the software guy, the keyboard. Until we stop coding in text, we can't give up our keyboards. But aside from that, I don't see the high end version of these devices that could do a massive build or run a big IDE like Eclipse. They really are a new class that I don't think will cut it, at least not on their own.
So where does this leave us? Well, one answer jumps to mind which I'm not sure I like yet. There's growing discussions about cloud computing and doing software development in the cloud. I've investigated it myself in the past and it is a very plausible future. Though, I'm not sure we're ready to sit for a 10 hour day typing code into a tablet or superphone but I can imagine there being some use to being ultra-mobile for the software developer and not being too far away from his code. Tools like Hudson would show just fine viewed from a web browser on a tablet or from a smartphone app (which already exists BTW).
It's going to take some time to figure out how to leverage these devices, but you can count on one thing. We're all gadget junkies and we'll figure it out somehow.
Wednesday, December 22, 2010
Is Backward Compatibility Futile?
In the last few weeks I've run into two products that I'm working with that try to maintain backwards compatibility with previous Eclipse releases. That is, while working on an upcoming release they want to make sure their plug-ins work all they way back to Eclipse 3.4 (one case only to 3.5, but still).
And I understand the desire of that. I've found old plug-ins that I want to use which claim support for 3.5 say and I'm very happy when they install and run with 3.6. And I'm even happier when the install into and work with M4 of Indigo. It's a difficult decision to pull back from the latest and greatest to get some needed functionality. It doesn't seem right.
But for these products, one thing should get in the way of that, the CDT. We don't claim 100% API compatibility from year to year. There's a reason why we're working on CDT 8.0 while the platform is still 3.7. And there's lots of practical reasons behind that, the main one being that we don't want to be tied to bad decisions made in the previous release. The more external tools we try to integrate and new features and just general clean up, we need to make things better even if we have to change APIs to do it.
No it's not fair to the community, but then we really haven't had a lot of push back from the community to stop that behavior. We can only assume they're reasonably happy to follow along, releasing their plug-ins with a fixed line up of Platform and CDT. And maybe that's it. The CDT ecosystem isn't set up where vendors plug-in their CDT integrations into each other. We tend to be competitors at that level, not partners.
But I think that is going to change very soon. Of the two products I mentioned, one is more mature and I guess CDT just happens to be backwards compatible enough that things just work. I'm a bit surprised but it relies mainly on debug APIs which we've been pretty careful to preserve. But without guarantees, I fear what they are doing.
The other is new and I'm kinda getting in on the ground floor. I have to decide which version of CDT to support. The rest of the stack supports back to Eclipse 3.5 which would be CDT 6. But then I want to do something good with CDT scanner discovery to properly set up the indexer. There should be some nice fixes in the upcoming CDT 8 for that. So do I have two versions of this thing? That's kind of where it goes, which is why I'm hoping we get these APIs locked down soon, for the good of all integrators who are facing the same decisions.
And I understand the desire of that. I've found old plug-ins that I want to use which claim support for 3.5 say and I'm very happy when they install and run with 3.6. And I'm even happier when the install into and work with M4 of Indigo. It's a difficult decision to pull back from the latest and greatest to get some needed functionality. It doesn't seem right.
But for these products, one thing should get in the way of that, the CDT. We don't claim 100% API compatibility from year to year. There's a reason why we're working on CDT 8.0 while the platform is still 3.7. And there's lots of practical reasons behind that, the main one being that we don't want to be tied to bad decisions made in the previous release. The more external tools we try to integrate and new features and just general clean up, we need to make things better even if we have to change APIs to do it.
No it's not fair to the community, but then we really haven't had a lot of push back from the community to stop that behavior. We can only assume they're reasonably happy to follow along, releasing their plug-ins with a fixed line up of Platform and CDT. And maybe that's it. The CDT ecosystem isn't set up where vendors plug-in their CDT integrations into each other. We tend to be competitors at that level, not partners.
But I think that is going to change very soon. Of the two products I mentioned, one is more mature and I guess CDT just happens to be backwards compatible enough that things just work. I'm a bit surprised but it relies mainly on debug APIs which we've been pretty careful to preserve. But without guarantees, I fear what they are doing.
The other is new and I'm kinda getting in on the ground floor. I have to decide which version of CDT to support. The rest of the stack supports back to Eclipse 3.5 which would be CDT 6. But then I want to do something good with CDT scanner discovery to properly set up the indexer. There should be some nice fixes in the upcoming CDT 8 for that. So do I have two versions of this thing? That's kind of where it goes, which is why I'm hoping we get these APIs locked down soon, for the good of all integrators who are facing the same decisions.
Wednesday, December 08, 2010
A Switch in the Grassroots? to Mobile?
It's no secret I'm an Android fanboy, of fanbois, or what have you. I'm not sure why. I guess what really sold me was the ability to run it in an emulator on my laptop before it was even available in phones. It was exactly what I was looking for in a mobile/embedded target so I could play there and learn what application developers need out of their IDE, or in my case, the CDT. Yes, iPhone was already out but I didn't have a Mac so Android sold it for me. If I had a Mac, who knows, maybe I'd be an iPhone fanboy with the rest of them.
As I mentioned in my last blog, I've been busy doing "real" work here at Wind River and now have finally got a chance to stick my head up and see what the CDT needs from me. My efforts in the CDT in recent years is all about getting the CDT into the hands of the grassroots of software developers, people who are hobbyists or students who are looking for a free IDE they can use on their projects. The commercial theory behind that is to make the CDT ubiquitous so that when we go to sell them our high value products based on the CDT, they have less of a learning curve and barrier to adopt those tools. Can't say whether that's been working or not, but there is no doubt that the CDT plays a major role in the embedded space where I work.
But, now, I am starting to wonder if my past focus on the grassroots needs to change. Previously, it was all about supporting Windows development with the CDT. Linux too, but that was generally taken care of without my help. The Wascana project was born out of that and with Helios it reached it's 1.0 version. You look at it, though, it only has 10,000 downloads which is actually half of the previous 0.9 version I released 2 years ago and that release had nowhere near the advertising I have tried to give Wascana 1.0, even with a prominent mention on CDT's download page. Maybe the grassroots has switched. And I think I know where I need to focus next.
I don't know if you've been following the geek news but Android 2.3 was released yesterday. As @sogrady correctly pointed out, there's not much exciting there, at least not for the consumer. But if you're an Android app developer, especially one who's been trying to write games and multimedia apps using C++, it is a revolution. The Android NDK team has finally provided APIs for audio and input events that have made life pretty difficult for these guys. Not only that, they've added a framework that allows you to create an Android app without writing a single line of Java code. It's awesome :).
And that has me thinking now. We've had repeated asks and attempts from users trying to use CDT for iPhone development. And we've seen developers in the Android community using straight CDT or with the plug-ins that currently reside in the Eclipse Sequoyah project. I firmly believe that this is the next grassroots. As the computer industry changes, so do the developers and I need to make sure that the mobile app devs have a low barrier to use the CDT for their projects. Sorry Wascana and Windows, I need to change my focus.
As I mentioned in my last blog, I've been busy doing "real" work here at Wind River and now have finally got a chance to stick my head up and see what the CDT needs from me. My efforts in the CDT in recent years is all about getting the CDT into the hands of the grassroots of software developers, people who are hobbyists or students who are looking for a free IDE they can use on their projects. The commercial theory behind that is to make the CDT ubiquitous so that when we go to sell them our high value products based on the CDT, they have less of a learning curve and barrier to adopt those tools. Can't say whether that's been working or not, but there is no doubt that the CDT plays a major role in the embedded space where I work.
But, now, I am starting to wonder if my past focus on the grassroots needs to change. Previously, it was all about supporting Windows development with the CDT. Linux too, but that was generally taken care of without my help. The Wascana project was born out of that and with Helios it reached it's 1.0 version. You look at it, though, it only has 10,000 downloads which is actually half of the previous 0.9 version I released 2 years ago and that release had nowhere near the advertising I have tried to give Wascana 1.0, even with a prominent mention on CDT's download page. Maybe the grassroots has switched. And I think I know where I need to focus next.
I don't know if you've been following the geek news but Android 2.3 was released yesterday. As @sogrady correctly pointed out, there's not much exciting there, at least not for the consumer. But if you're an Android app developer, especially one who's been trying to write games and multimedia apps using C++, it is a revolution. The Android NDK team has finally provided APIs for audio and input events that have made life pretty difficult for these guys. Not only that, they've added a framework that allows you to create an Android app without writing a single line of Java code. It's awesome :).
And that has me thinking now. We've had repeated asks and attempts from users trying to use CDT for iPhone development. And we've seen developers in the Android community using straight CDT or with the plug-ins that currently reside in the Eclipse Sequoyah project. I firmly believe that this is the next grassroots. As the computer industry changes, so do the developers and I need to make sure that the mobile app devs have a low barrier to use the CDT for their projects. Sorry Wascana and Windows, I need to change my focus.
Saturday, December 04, 2010
Back to the Blogoshere
I've been pretty busy lately. After a couple of years of looking at Eclipse based install technologies, I'm back working in the IDE space on some cool things based on the Eclipse Target Communication Framework. That's taken a lot of my time so I've resorted to Tweeting short ideas rather than spend the effort writing here on my blog. And I miss it and I have accumulated a lot to write about. So look for more in this space.
There are a few things I've been interested in lately. Android is still at the top of my list. I have a couple of phones now and am immersing myself in the experience to learn more about it, especially how apps are different from the now legacy environments we have on our desktops. Meeting the needs of app developers of course is important to us working on Eclipse based tooling and I think it marks a shift in the grassroots. Projects like Wascana which focuses on CDT for Windows dev are becoming less important to me than CDT for Android native so look for new things out of me there.
I'm also becoming maniacally focused on usability. This is a relatively new area for me after years of being a modelling and parser guy. But it is so important to create software that users want to use and it's a challenge. And I'm going to leverage my passion for writing to help. Writing user stories will really help me get inside their head. Not only do you need to understand what they are trying to accomplish, you need to understand why. It'll be cool to see how this works on practice and should be fun.
Well I'll write more later. The software world is going through some major changes thanks to both web technologies and mobile. Android and iOS have a great rivalry going and I expect to see the avalanche of mobile devices and even things like settop boxes that app developers are going to want to target. It certainly is a great time to be in this industry.
Friday, November 05, 2010
Historic Day for Linux Desktop?
I just tweeted this, but it's worthy of a blog entry because I think this will, or at least should be, marked as an historic day for Linux. Mark Shuttleworth, Ubuntu chief, blogged yesterday that they are starting a transition from an X Windows based environment to the Wayland display server. That is huge news and a huge push for the fledgling Wayland project which is starting to get a lot of love lately. Intel, who employs the main developer for Wayland, already seems committed to getting MeeGo on top of it, but this move for Ubuntu all but assures Wayland will become mainstream for the Linux desktop. And I can't wait for that!
So what the heck is Wayland and why am I so excited about it? Well I've been working with X Windows since my university days when X11 was spanking new. It had a great architecture that allowed the display to be hosted on a different machine than where the application ran. Back in the early 90's that was pretty important since workstations weren't very powerful so we still had big iron Unix servers where we ran things and being able to display them on any machine in the lab was liberating. It was the best, back in the early 90's that is.
Then entered personal computers thanks to Microsoft Windows and to some extent Apple Macintosh. As these machines grew faster and faster, it became more economical to run your applications locally. Not only that, but the graphic architecture, where display handling was part of the operating system, allowed for the desktop environments to become rich, to the point now where we have the beautiful environments of Windows 7 and Mac OS X.
Now when Linux came along, the powers that be chose X Windows as the underlying display architecture. It made sense since X Windows is open source and it does a good job. But it is shackled by the underlying architecture that made it popular in the 90's. As Mark put it, "I understand that it’s *possible* to get amazing results with X, but it’s extremely hard, and isn’t going to get easier. Some of the core goals of X make it harder to achieve these user experiences on X than on native GL, we’re choosing to prioritize the quality of experience over those original values, like network transparency."
And that's where Wayland comes it. Wikipedia describes it as "a lightweight display server for the Linux desktop. Started by Kristian Høgsberg, one of Intel OSTC member, the software's stated goal is 'every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker'". It gives the application and window managers full control over how their content is displayed and gives them free access to the graphic hardware acceleration through OpenGL and OpenGL ES, essentially the same architecture which gives Windows and Mac their great environments.
It's going to take some time as the ecosystem grabs hold of the possibilities. It is almost certain that other Linux distributions will jump on the bandwagon, and I'm sure nVidia and AMD will do the same with their hardware drivers. But once they do, I am convinced that this will finally make Linux a real contender in the desktop space. I can't wait :).
So what the heck is Wayland and why am I so excited about it? Well I've been working with X Windows since my university days when X11 was spanking new. It had a great architecture that allowed the display to be hosted on a different machine than where the application ran. Back in the early 90's that was pretty important since workstations weren't very powerful so we still had big iron Unix servers where we ran things and being able to display them on any machine in the lab was liberating. It was the best, back in the early 90's that is.
Then entered personal computers thanks to Microsoft Windows and to some extent Apple Macintosh. As these machines grew faster and faster, it became more economical to run your applications locally. Not only that, but the graphic architecture, where display handling was part of the operating system, allowed for the desktop environments to become rich, to the point now where we have the beautiful environments of Windows 7 and Mac OS X.
Now when Linux came along, the powers that be chose X Windows as the underlying display architecture. It made sense since X Windows is open source and it does a good job. But it is shackled by the underlying architecture that made it popular in the 90's. As Mark put it, "I understand that it’s *possible* to get amazing results with X, but it’s extremely hard, and isn’t going to get easier. Some of the core goals of X make it harder to achieve these user experiences on X than on native GL, we’re choosing to prioritize the quality of experience over those original values, like network transparency."
And that's where Wayland comes it. Wikipedia describes it as "a lightweight display server for the Linux desktop. Started by Kristian Høgsberg, one of Intel OSTC member, the software's stated goal is 'every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker'". It gives the application and window managers full control over how their content is displayed and gives them free access to the graphic hardware acceleration through OpenGL and OpenGL ES, essentially the same architecture which gives Windows and Mac their great environments.
It's going to take some time as the ecosystem grabs hold of the possibilities. It is almost certain that other Linux distributions will jump on the bandwagon, and I'm sure nVidia and AMD will do the same with their hardware drivers. But once they do, I am convinced that this will finally make Linux a real contender in the desktop space. I can't wait :).
Saturday, October 30, 2010
Playing App Developer - Where to start
The mobile space just doesn't seem to stop being more interesting by the day. It's got me hooked, and I'm not sure why other than it's fun to be a part of, even if it is in my hobby time. I keep trying to integrate it into my day job but it's not clicking :). Instead, I am trying to become an amateur game developer in the few hours a week I get time for it at home. If nothing, it helps me feel a part of all the excitement.
As I march along my journey, it becomes quickly clear the first choice app developers face when getting in the game. Which mobile platform do I start with and what do I do about the others? From where I sit, the choice is obvious. I have an Android phone (actually I have two but my first one is a Roger's HTC Dream that's stuck on Android 1.5 which isn't very useful), and since the SDK is freely available I am starting with that.
But I can't ignore Apple's iOS. It still is the mobile industry's darling and likely will be for a long time. The problem there is that I don't have a Mac which is a pretty high barrier to entry IMHO. But that's OK. There seem to be a few people in the blogosphere who know how to get Mac OS X running in VirtualBox. But when it comes time to actually deliver something (assuming I ever get that far), you'll need the real thing.
It's pretty sad to see what's happening to Symbian. I have friends with skin in that game so I'm not going to say much, other than I agree with the prognosticators. Throwing your product over the wall into the open doesn't make it an instant success. At the end of the day, open source doesn't win mindshare. Having low barrier to entry and a good chance of getting good volumes do. Symbian is a technically complicated app dev environment. Qt will make that better. But if you're programming to Qt, then Symbian doesn't matter much since MeeGo also runs Qt. Which makes MeeGo something to watch out for.
RIM is an interesting choice. But people don't think of RIM phones as gaming devices. The new tablet might change that, but it's not clear you can write native code for it, which, of course for me being CDT Doug, is a must.
And the same is true for Windows Phone 7. It appears you need to use C#, or at least managed code. I'll need to dig into whether managed C++, if it even still exists, would work. But Microsoft is the king of walled gardens as much as we look at Apple today. But Microsoft also loves game developers, so we'll see how that platform evolves.
So it's an interesting array of choices and the pieces are all in motion and it's a bit hard to guess how it'll all turn out, which is why it's fun to watch. Of course, I do need to mention that I'd prefer to use the Eclipse CDT and tools from the Eclipse ecosystem to build my game for all these platforms. But that is only slightly less disjoint than platforms are. As I've often said, I'd love to have a single Eclipse project with build configurations and debug integrations for all of these. That's the vision, anyway. And playing in the mobile space has me convinced how important that really is.
As I march along my journey, it becomes quickly clear the first choice app developers face when getting in the game. Which mobile platform do I start with and what do I do about the others? From where I sit, the choice is obvious. I have an Android phone (actually I have two but my first one is a Roger's HTC Dream that's stuck on Android 1.5 which isn't very useful), and since the SDK is freely available I am starting with that.
But I can't ignore Apple's iOS. It still is the mobile industry's darling and likely will be for a long time. The problem there is that I don't have a Mac which is a pretty high barrier to entry IMHO. But that's OK. There seem to be a few people in the blogosphere who know how to get Mac OS X running in VirtualBox. But when it comes time to actually deliver something (assuming I ever get that far), you'll need the real thing.
It's pretty sad to see what's happening to Symbian. I have friends with skin in that game so I'm not going to say much, other than I agree with the prognosticators. Throwing your product over the wall into the open doesn't make it an instant success. At the end of the day, open source doesn't win mindshare. Having low barrier to entry and a good chance of getting good volumes do. Symbian is a technically complicated app dev environment. Qt will make that better. But if you're programming to Qt, then Symbian doesn't matter much since MeeGo also runs Qt. Which makes MeeGo something to watch out for.
RIM is an interesting choice. But people don't think of RIM phones as gaming devices. The new tablet might change that, but it's not clear you can write native code for it, which, of course for me being CDT Doug, is a must.
And the same is true for Windows Phone 7. It appears you need to use C#, or at least managed code. I'll need to dig into whether managed C++, if it even still exists, would work. But Microsoft is the king of walled gardens as much as we look at Apple today. But Microsoft also loves game developers, so we'll see how that platform evolves.
So it's an interesting array of choices and the pieces are all in motion and it's a bit hard to guess how it'll all turn out, which is why it's fun to watch. Of course, I do need to mention that I'd prefer to use the Eclipse CDT and tools from the Eclipse ecosystem to build my game for all these platforms. But that is only slightly less disjoint than platforms are. As I've often said, I'd love to have a single Eclipse project with build configurations and debug integrations for all of these. That's the vision, anyway. And playing in the mobile space has me convinced how important that really is.
Tuesday, October 19, 2010
Users versus Vendors, or is it Users and Vendors
One thing I've been noticing lately on the CDT project that's probably happening with other projects at Eclipse is that more and more contributions, contributors, and even committers are coming from companies that are users of Eclipse technology. When we started the CDT and for many years we were driven almost exclusively by vendors that had commercial products that used the CDT. But now we have this very interesting mix and that is really changing the dynamics of how we work.
But you could see it coming and Eclipse is setup up to promote such growth. It started as bug reports, then slowly patches started getting attached to those bug reports, then those guys writing patches started contributing more patches and participated in the mailing lists until we finally voted them in as committers so they could apply their own patches. And that's how it's supposed to work. That's how you grow your community. And that's how we've reached the rich diversity enjoyed by the CDT project.
But as I mention, there's an interesting dynamic that's happening. The vendors are still trying to make money selling CDT-based products. Those users used to be potential customers of those products. However the economics of open source makes it actually cheaper and gives them more control if they get their tools and platforms from open source and staff a few developers to maintain and grow that software. When you have a user base that numbers in the thousands, I can see it. And there are quite a few of those companies, especially in the embedded space.
So what used to seen as differentiating features for vendors is still functionality that is desired by these user contributors. And of course, they would rather see that functionality implemented in the open where they can share it amongst themselves and anyone else who could potentially contribute. So as they organize, the tools vendors are looking on with dread. We have always fought to stay above the open source line with our value add, but it's becoming more and more difficult. And that line is growing exponentially. It's certainly a wake up call for us who get paid out of product revenue.
Has the industry changed making us dinosaurs or is there still value that we can provide that users will pay for. I think we still can make money, but we definitely have to change they way we think. It's no longer about who has the best features. It's what it should have always been about, who makes their customers the most successful. Our user contributors know that as that's exactly what they are paid to do. We vendors need to find our place there too.
But you could see it coming and Eclipse is setup up to promote such growth. It started as bug reports, then slowly patches started getting attached to those bug reports, then those guys writing patches started contributing more patches and participated in the mailing lists until we finally voted them in as committers so they could apply their own patches. And that's how it's supposed to work. That's how you grow your community. And that's how we've reached the rich diversity enjoyed by the CDT project.
But as I mention, there's an interesting dynamic that's happening. The vendors are still trying to make money selling CDT-based products. Those users used to be potential customers of those products. However the economics of open source makes it actually cheaper and gives them more control if they get their tools and platforms from open source and staff a few developers to maintain and grow that software. When you have a user base that numbers in the thousands, I can see it. And there are quite a few of those companies, especially in the embedded space.
So what used to seen as differentiating features for vendors is still functionality that is desired by these user contributors. And of course, they would rather see that functionality implemented in the open where they can share it amongst themselves and anyone else who could potentially contribute. So as they organize, the tools vendors are looking on with dread. We have always fought to stay above the open source line with our value add, but it's becoming more and more difficult. And that line is growing exponentially. It's certainly a wake up call for us who get paid out of product revenue.
Has the industry changed making us dinosaurs or is there still value that we can provide that users will pay for. I think we still can make money, but we definitely have to change they way we think. It's no longer about who has the best features. It's what it should have always been about, who makes their customers the most successful. Our user contributors know that as that's exactly what they are paid to do. We vendors need to find our place there too.
Tuesday, September 28, 2010
CDT Summit Report: What to do about the Eclipse Platform
We had a lot of heated debate about what to do with the Eclipse Platform and the troubles we've had trying to contribute to it to allow it to meet the needs of our customers. There have been some successes, there is no doubt. We have flexible resources in 3.6. We have flexible debug in the platform for quite a while now. So we are very thankful for that.
But we're still not in a good place yet. We're still really struggling with build. CDT builds are complex beasts involving external compilers and linkers and other utilities and generators. Builds tend to take a long time. My standard sized C++ project porting the Irrlicht game engine to Android takes about a few minutes to do a full build with a Minimum 3-5 seconds for a one line change. It's not "instantaneous" like Java and dynamic language builds tend to be. So features like automatic builds never made sense for us.
Also, our builds tend to be managed by external tools, 'make' in particular, that manage the "delta" of what needs to be built for us. The resource delta that the platform provides is useless in those cases, other than as an indication that something has changed and we need to invoke make. Mind you we tend to always build anyway just in case we have external files that may change that aren't being tracked by Eclipse.
That leads to the oddest workflow, clean, which in the C++ IDE's we've used in the past, means just that. Remove all previous build output. But since that also clears out the Eclipse build state, it invokes a FULL_BUILD right away to rebuild it, which we then interpret as the need to call out to make which then puts the build output right back. And if we ignore FULL_BUILDS, we miss the initial build. It's a mess.
The good news is that we have people working on fixing these things, and have opened bugs against the platform and attached patches to them. But it's been really slow to get them looked at or they are being rejected outright. What ends up happening is that vendors fork the platform and apply the patches they need anyway. Now that's not a healthy situation when we are trying to build an ecosystem when everyone has a different eclipse platform you need to plug into.
So what do we do about this? Is e4 the answer? No. In fact surveying the crowd at the CDT summit, no one was interested in the features that e4 brings to the table. It doesn't address the problems that we as a C++ IDE community have today. And we need to those things fixed in the Platform today, not in an incubator. Fancy UI frameworks are maybe something we need down the road, but our customers want us to get the basic workflows working well first.
So in a drunken stupor (well stupor anyway) at our celebration event I threw out a proposal to the people standing around me and then to others during the week. e4 is a fork of the platform. It was created to try out some new ideas. Why don't we create our own fork of the Platform focused on meeting the needs of the CDT community and for our fellow Tools projects that have the same needs. That way we can at least share the forks we've already created for our products. We still need to run all the same plug-ins we do today such as Mylyn, JDT, etc. So we can't go crazy and change the world. But at least we'd have control over it to make sure it meets our needs.
You know me by now. I like to brainstorm with the community. So I'm only semi-serious about forking the Platform. We are taking a serious stance on the bugs we have opened up there and I hope the Platform team will work with us for the mutual benefit of our users. We are frustrated about the lack of progress and we do need to think of alternatives. And forking the Platform isn't as far fetched as it once seemed. It's actually a admission of what many in our community are already doing.
But we're still not in a good place yet. We're still really struggling with build. CDT builds are complex beasts involving external compilers and linkers and other utilities and generators. Builds tend to take a long time. My standard sized C++ project porting the Irrlicht game engine to Android takes about a few minutes to do a full build with a Minimum 3-5 seconds for a one line change. It's not "instantaneous" like Java and dynamic language builds tend to be. So features like automatic builds never made sense for us.
Also, our builds tend to be managed by external tools, 'make' in particular, that manage the "delta" of what needs to be built for us. The resource delta that the platform provides is useless in those cases, other than as an indication that something has changed and we need to invoke make. Mind you we tend to always build anyway just in case we have external files that may change that aren't being tracked by Eclipse.
That leads to the oddest workflow, clean, which in the C++ IDE's we've used in the past, means just that. Remove all previous build output. But since that also clears out the Eclipse build state, it invokes a FULL_BUILD right away to rebuild it, which we then interpret as the need to call out to make which then puts the build output right back. And if we ignore FULL_BUILDS, we miss the initial build. It's a mess.
The good news is that we have people working on fixing these things, and have opened bugs against the platform and attached patches to them. But it's been really slow to get them looked at or they are being rejected outright. What ends up happening is that vendors fork the platform and apply the patches they need anyway. Now that's not a healthy situation when we are trying to build an ecosystem when everyone has a different eclipse platform you need to plug into.
So what do we do about this? Is e4 the answer? No. In fact surveying the crowd at the CDT summit, no one was interested in the features that e4 brings to the table. It doesn't address the problems that we as a C++ IDE community have today. And we need to those things fixed in the Platform today, not in an incubator. Fancy UI frameworks are maybe something we need down the road, but our customers want us to get the basic workflows working well first.
So in a drunken stupor (well stupor anyway) at our celebration event I threw out a proposal to the people standing around me and then to others during the week. e4 is a fork of the platform. It was created to try out some new ideas. Why don't we create our own fork of the Platform focused on meeting the needs of the CDT community and for our fellow Tools projects that have the same needs. That way we can at least share the forks we've already created for our products. We still need to run all the same plug-ins we do today such as Mylyn, JDT, etc. So we can't go crazy and change the world. But at least we'd have control over it to make sure it meets our needs.
You know me by now. I like to brainstorm with the community. So I'm only semi-serious about forking the Platform. We are taking a serious stance on the bugs we have opened up there and I hope the Platform team will work with us for the mutual benefit of our users. We are frustrated about the lack of progress and we do need to think of alternatives. And forking the Platform isn't as far fetched as it once seemed. It's actually a admission of what many in our community are already doing.
CDT Summit Report: No git for us, not yet
We had a pretty good discussion about using git for managing the CDT source. For the community members that care, git is critical to the future success of CDT. git allows the workflows we need to allow adopters to make local changes as necessary and then deliver those changes to the CDT project as candidates for inclusion upstream. That workflow is very difficult with CVS since it requires you to set up a disjoint repository. Bleach.
So we're pretty eager. However, at the end of the session, I got the feeling that we just weren't ready for it. At least not yet.
First of all, there's just the need to figure out all the workflows we want to support. I was excited at the beginning of the summer about using Gerrit code review for CDT just like the egit guys are doing. Having a system to manage code changes, to make them visible to all, and to make it easy to do code reviews, is very compelling. However, it turns out that the egit use of Gerrit was a trial and the Foundation staff isn't ready to support it yet.
So we need to go back to square one, managing patches in Bugzilla which takes away from that fork and contribute workflow that's bringing us to git to begin with. It does bring up the need to produce some documentation so that we can decide how we want to work and to educate the contributors on that.
That brought us to the egit plug-ins. There has been some really good progress with egit thanks to the team working on it. I'm using egit for a number of projects I'm working with, both Java and C++ and am really liking the experience. However there are still a few things lacking and defects that I'll be raising bugs on. I am seeing a lot of exceptions when doing merges, including out of memory. I want to be able to compare branches, but I guess that's what the Synchronization view is trying to do. But then the usability of the Sync View is very confusing.
And finally, the real show stopper for me is the lack of being able to create patches between two commits, e.g. between two branches. Again, our big workflow is to allow adopters to fork and contribute the results back to the project. They will be creating local branches and committing updates to them. So being able to create a patch between their branch and our master is a must.
At the end of the day, we're just not ready. Once we figure out how we want to work with git, and when egit fully supports those workflows, we'll jump on the bandwagon with both feet. Until then, we have work to do.
So we're pretty eager. However, at the end of the session, I got the feeling that we just weren't ready for it. At least not yet.
First of all, there's just the need to figure out all the workflows we want to support. I was excited at the beginning of the summer about using Gerrit code review for CDT just like the egit guys are doing. Having a system to manage code changes, to make them visible to all, and to make it easy to do code reviews, is very compelling. However, it turns out that the egit use of Gerrit was a trial and the Foundation staff isn't ready to support it yet.
So we need to go back to square one, managing patches in Bugzilla which takes away from that fork and contribute workflow that's bringing us to git to begin with. It does bring up the need to produce some documentation so that we can decide how we want to work and to educate the contributors on that.
That brought us to the egit plug-ins. There has been some really good progress with egit thanks to the team working on it. I'm using egit for a number of projects I'm working with, both Java and C++ and am really liking the experience. However there are still a few things lacking and defects that I'll be raising bugs on. I am seeing a lot of exceptions when doing merges, including out of memory. I want to be able to compare branches, but I guess that's what the Synchronization view is trying to do. But then the usability of the Sync View is very confusing.
And finally, the real show stopper for me is the lack of being able to create patches between two commits, e.g. between two branches. Again, our big workflow is to allow adopters to fork and contribute the results back to the project. They will be creating local branches and committing updates to them. So being able to create a patch between their branch and our master is a must.
At the end of the day, we're just not ready. Once we figure out how we want to work with git, and when egit fully supports those workflows, we'll jump on the bandwagon with both feet. Until then, we have work to do.
Friday, September 24, 2010
A great CDT Summit 2010
After a year off due to lack of travel budgets, we held the CDT Summit again this week this time at the Ericsson offices in Montreal. It was a great summit and proves again why we do these things. Many times I looked up during the meetings and then through the evening events and saw people from different places talking to eachother, laughing, sharing stories and experiences. You hold these things to have technical discussions on the issues of the day and plans for tomorrow, but the real value is the relationships we build working together face to face. You just can't duplicate that on-line.
Many thanks to our hosts at Ericsson, Marc Khouzam and Dominique Toupin who worked tirelessly in the weeks leading up to the summit and fought through all the infrastructure issues you end up running into during these things. It all worked out superbly in the end, despite our ribbing them about it :). Thanks guys!
Also thank you to our sponsors from Ericsson, Eclipse Foundation, Wind River, Texas Instruments, Mentor Graphics and Google whose financial contributions made this all possible. We had a very special event on the first night and got a sense of the history of Montreal and a party in a unique setting. Not to mention the superb meals we had for lunches and breakfast, to fuel our efforts during the summit. It really made us comfortable and let us focus on the work at hand.
I have a lot to write about on the topics we discussed. There was a wide variety and some of these things will be of interest to the general Eclipse community as we work to make the Eclipse the best IDE for C/C++ developers in the industry, which is not always an easy task given the general nature of Eclipse. But I'll blog about those things over the next few days.
My biggest thanks go to the 30+ people and their employers/sponsors who allowed them to travel and take the time out to contribute to the CDT summit and to the handful of people who attended remotely through my CDT conference bridge and Webex account. These summits are most successful when the people come with the mind of working with the rest of the community to do something greater than they can do on their own. As I mentioned to James on his way out. It's why we do open source: "to have some fun and to change the world".
More later...
Many thanks to our hosts at Ericsson, Marc Khouzam and Dominique Toupin who worked tirelessly in the weeks leading up to the summit and fought through all the infrastructure issues you end up running into during these things. It all worked out superbly in the end, despite our ribbing them about it :). Thanks guys!
Also thank you to our sponsors from Ericsson, Eclipse Foundation, Wind River, Texas Instruments, Mentor Graphics and Google whose financial contributions made this all possible. We had a very special event on the first night and got a sense of the history of Montreal and a party in a unique setting. Not to mention the superb meals we had for lunches and breakfast, to fuel our efforts during the summit. It really made us comfortable and let us focus on the work at hand.
I have a lot to write about on the topics we discussed. There was a wide variety and some of these things will be of interest to the general Eclipse community as we work to make the Eclipse the best IDE for C/C++ developers in the industry, which is not always an easy task given the general nature of Eclipse. But I'll blog about those things over the next few days.
My biggest thanks go to the 30+ people and their employers/sponsors who allowed them to travel and take the time out to contribute to the CDT summit and to the handful of people who attended remotely through my CDT conference bridge and Webex account. These summits are most successful when the people come with the mind of working with the rest of the community to do something greater than they can do on their own. As I mentioned to James on his way out. It's why we do open source: "to have some fun and to change the world".
More later...
Wednesday, September 08, 2010
Entering the Realm of Interaction Design
I'm about to embark on a relatively new era in my career. I'm always looking for new challenges and there is a huge need with the tools I work on to improve their usability. UI design is a long way from C++ parser writing, but I've seen great UIs and I know pretty quickly what a bad one looks like. And I want to make the life easier for my users.
I was given a book written by Alan Cooper called, "The Inmates are Running the Asylum". I only read the first couple of chapters but it really chimed with something I always had in the back of my mind. Computer programs are usually written by engineers that assume (or don't even consider) that users think the same way they do. And Cooper has some pretty good and common examples of where that assumption ends up being pretty embarrassing. Or worse, "it leaves the user feeling pretty stupid."
When you work on a UI feature, often you're following the Model-View-Controller paradigm. Being a computer person, you start with the model and then think of ways of showing that model to the user and then controls for manipulating the model. You want to make sure they can change everything to get the most out of the fine work you're doing.
Well, the user doesn't care squat about your model. He has a job to do. He is trying to accomplish some goal in order to look good in front of his customer. And he needs to do it quickly so he can get home to see his kids before they go to bed. He doesn't have the time to learn the intricacies of your model and the esoteric ways you've provided to view and control that model.
Cooper suggests we need to do Interaction Design as a lead up to the actual code. Understand what the user is trying to do and find ways to allow him to understand your software quickly and to get his job done quickly. Design the View and Controller first, then worry about the model. Get under the user's skin, know what he knows, feel what he feels. That's a pretty tough thing to do for us engineers who love the challenge of creating the world's best algorithms. You don't need to empathize with anyone to write "good" code.
It's a hard job to put together an intuitive interaction design that accomplishes what the user needs with minimal gestures, but I look forward to that challenge.
I was given a book written by Alan Cooper called, "The Inmates are Running the Asylum". I only read the first couple of chapters but it really chimed with something I always had in the back of my mind. Computer programs are usually written by engineers that assume (or don't even consider) that users think the same way they do. And Cooper has some pretty good and common examples of where that assumption ends up being pretty embarrassing. Or worse, "it leaves the user feeling pretty stupid."
When you work on a UI feature, often you're following the Model-View-Controller paradigm. Being a computer person, you start with the model and then think of ways of showing that model to the user and then controls for manipulating the model. You want to make sure they can change everything to get the most out of the fine work you're doing.
Well, the user doesn't care squat about your model. He has a job to do. He is trying to accomplish some goal in order to look good in front of his customer. And he needs to do it quickly so he can get home to see his kids before they go to bed. He doesn't have the time to learn the intricacies of your model and the esoteric ways you've provided to view and control that model.
Cooper suggests we need to do Interaction Design as a lead up to the actual code. Understand what the user is trying to do and find ways to allow him to understand your software quickly and to get his job done quickly. Design the View and Controller first, then worry about the model. Get under the user's skin, know what he knows, feel what he feels. That's a pretty tough thing to do for us engineers who love the challenge of creating the world's best algorithms. You don't need to empathize with anyone to write "good" code.
It's a hard job to put together an intuitive interaction design that accomplishes what the user needs with minimal gestures, but I look forward to that challenge.
Monday, August 23, 2010
Hypervisors drive Heterogeneity
I have put together a pretty neat little lab here under my desk. As I always say, you have to use the tools to understand the needs of the users. You have to get into their shoes and see what you like and don't like. Then you have a good chance of building tools they'll actually use and like.
My lab includes two "embedded" systems on the right. The top is a board that has a Freescale PowerPC P4080 8-core chip in it. I have attached my Wind River ICE JTAG unit to it to test some really heavy duty multi-core scenarios. On the bottom right, I have what looks like a basic PC, and it is, but it runs Wind River's hypervisor hosting three operating systems: Wind River Linux, vxWorks, and of all things Windows. I don't have the P4080 system booted up yet, but my intention is to run the Hypervisor there too with random combinations of wrLinux and vxWorks.
As I put this together, it really drove home the need for an IDE platform that is heterogeneous. That's a hard word to pronounce, but what I really mean is an IDE that can target any operating system that can run in a hypervisor configuration, which is pretty much all of them. And that means an IDE that has plug and play support that lets you create the source for applications that can run on them all, build that source for any and all of the target platforms, and debug the application as it runs on one ore more of them.
And, you guessed it, the Eclipse CDT C/C++ IDE is a great platform to do that with. We have build and debug support for the GNU toolchain for Linux and from Wind River we have commercial support for vxWorks and Wind River Linux, and upcoming in the next release of CDT, we'll have support for Microsoft's Windows SDK which includes Visual C++.
As well, I'm about to embark on a very interesting journey with the Target Communication Framework as we advance it's debug capabilities to cover all of these platforms as well. With a common framework for agents that run in all these environments, we'll have the ability to plug 'n play capabilities into these agents and come up with tooling we haven't even dared to consider before. Am I pumped about it? You betcha. We've long had the advantage of plug-in architectures with our Eclipse-based tooling, and now we'll get that advantage all the way down to the target as well.
And it's really these hypervisor scenarios that have brought me here. It's finally a concrete example where you really need the heterogeneous capabilities that have driven my work on the CDT. And, it's something to sell our employers with too :).
Monday, July 19, 2010
Fitting Eclipse into my world
As I blogged a few days ago, I've started working on a game engine using open source bits. Part of it is just to satisfy my hunger to learn more about game development, but the more practical benefit of this effort is to better understand the plight of the C/C++ developer using the CDT on a real and fairly sizable project.
And I have my first lesson. It came about thanks to git. I have the source checked into a git repository out on github. Now, since the root of the game engine is open source libraries, I was working in the command line to extract them into the git repository. As a result I got used to using git from the command line, including adding a .gitignore so that git wouldn't check in my Eclipse .metadata directory and any directories containing build output.
I then started setting up the projects as CDT projects and started working in Eclipse. And I gave the Helios egit plug-ins a try. Unfortunately, they currently don't support .gitignore and as a result I got weird results that caused me to lose trust in egit, like ?'s on the folders I have listed in my .gitignore. Or did I forget to add them there? Not sure. I have to go back to the command line to look. At any rate, I ended up staying there and now I just use git from the command line. At least until egit 0.9 comes out with .gitignore support and I'll try again.
But this article isn't about egit. It's about Eclipse and how developers who do C/C++, especially experienced ones, work. The command line and command line tools are still a very important part of the development cycle and Eclipse and the CDT need to deal with that.
I see a lot of functionality in Eclipse assuming that projects are the root of your life. Well, it's not in my case. I have a git repo which contains directories that contain projects and there are some that do not. There's even a README file at the root and some files to help me build for Android using CMake.
I think there's a concept missing in Eclipse. We can equate the root of my git repo as a workspace. But then there are things in that workspace, files and folders, that aren't projects. I would like to be able to browse them, and maybe even edit the files, without having to go to the file explorer. Essentially I need a file navigator rooted at the workspace. I'm not sure whether we need a separate view for that, or to just allow Workspace roots to have IFiles and IFolders and make them navigable in the project navigator.
I'd like to hear other people's experiences, especially those who try to mix Eclipse with command line development. Is this something that would be useful? Are there other things?
And I have my first lesson. It came about thanks to git. I have the source checked into a git repository out on github. Now, since the root of the game engine is open source libraries, I was working in the command line to extract them into the git repository. As a result I got used to using git from the command line, including adding a .gitignore so that git wouldn't check in my Eclipse .metadata directory and any directories containing build output.
I then started setting up the projects as CDT projects and started working in Eclipse. And I gave the Helios egit plug-ins a try. Unfortunately, they currently don't support .gitignore and as a result I got weird results that caused me to lose trust in egit, like ?'s on the folders I have listed in my .gitignore. Or did I forget to add them there? Not sure. I have to go back to the command line to look. At any rate, I ended up staying there and now I just use git from the command line. At least until egit 0.9 comes out with .gitignore support and I'll try again.
But this article isn't about egit. It's about Eclipse and how developers who do C/C++, especially experienced ones, work. The command line and command line tools are still a very important part of the development cycle and Eclipse and the CDT need to deal with that.
I see a lot of functionality in Eclipse assuming that projects are the root of your life. Well, it's not in my case. I have a git repo which contains directories that contain projects and there are some that do not. There's even a README file at the root and some files to help me build for Android using CMake.
I think there's a concept missing in Eclipse. We can equate the root of my git repo as a workspace. But then there are things in that workspace, files and folders, that aren't projects. I would like to be able to browse them, and maybe even edit the files, without having to go to the file explorer. Essentially I need a file navigator rooted at the workspace. I'm not sure whether we need a separate view for that, or to just allow Workspace roots to have IFiles and IFolders and make them navigable in the project navigator.
I'd like to hear other people's experiences, especially those who try to mix Eclipse with command line development. Is this something that would be useful? Are there other things?
Thursday, July 15, 2010
Happy 100K CDT!
I originally sent this in an e-mail to cdt-dev. But it's info others might find interesting.
Hey gang,
Just to let you know we passed 100,000 downloads of CDT today and to pass along congrats!
And, looking at the stats, there's some interesting information there.
First, where do people get the CDT?
- 74,300 from the Eclipse C/C++ IDE package
- 6,400 from the Eclipse Linux C/C++ IDE package which includes the Linux Tools stuff as well
- 13,700 from the Helios train repository
- 2,200 from the CDT repository
- 2,700 from the CDT master zip
- 1,000 from Wascana (w00t!)
So that's about 80% from the Eclipse packages. There are a couple of things I get from that.
- People want a quick and easy way to get the CDT and the Eclipse web site funnels them there.
- People who use CDT with Eclipse are CDT users first. Much fewer start with a different Eclipse package and add CDT to it.
And for the platform breakdown.
- 59% Windows
- 34% Linux
- 7% Mac
Again, the Linux number continues to be much higher than we've had in the past, which could be attributed to more developers moving to Linux, or people are moving back to Visual Studio on Windows. I'm pretty happy with the 1K so far for Wascana. And I'm hopeful at getting a Windows debug solution with Visual C++ support for Indigo (thanks to work Eugene from Wind River has done in TCF) which may change things.
Also the Mac number is only slightly higher than in the past. Other than fixing a few bugs this release, I think we're still missing the big carrot, Objective-C. Unfortunately, there isn't enough investment in this area for that to change any time soon, so it is what it is.
All-in-all, pretty good numbers for the summer. We usually get an explosion in the fall when the kids head back to school which validates my grassroots strategy. We're getting a hold of the kids early and making them Eclipse savvy so that when they enter the workplace, they'll carry forward the word there and give our employers money :).
Next report at 200K. We'll see if things change as we go.
Hey gang,
Just to let you know we passed 100,000 downloads of CDT today and to pass along congrats!
And, looking at the stats, there's some interesting information there.
First, where do people get the CDT?
- 74,300 from the Eclipse C/C++ IDE package
- 6,400 from the Eclipse Linux C/C++ IDE package which includes the Linux Tools stuff as well
- 13,700 from the Helios train repository
- 2,200 from the CDT repository
- 2,700 from the CDT master zip
- 1,000 from Wascana (w00t!)
So that's about 80% from the Eclipse packages. There are a couple of things I get from that.
- People want a quick and easy way to get the CDT and the Eclipse web site funnels them there.
- People who use CDT with Eclipse are CDT users first. Much fewer start with a different Eclipse package and add CDT to it.
And for the platform breakdown.
- 59% Windows
- 34% Linux
- 7% Mac
Again, the Linux number continues to be much higher than we've had in the past, which could be attributed to more developers moving to Linux, or people are moving back to Visual Studio on Windows. I'm pretty happy with the 1K so far for Wascana. And I'm hopeful at getting a Windows debug solution with Visual C++ support for Indigo (thanks to work Eugene from Wind River has done in TCF) which may change things.
Also the Mac number is only slightly higher than in the past. Other than fixing a few bugs this release, I think we're still missing the big carrot, Objective-C. Unfortunately, there isn't enough investment in this area for that to change any time soon, so it is what it is.
All-in-all, pretty good numbers for the summer. We usually get an explosion in the fall when the kids head back to school which validates my grassroots strategy. We're getting a hold of the kids early and making them Eclipse savvy so that when they enter the workplace, they'll carry forward the word there and give our employers money :).
Next report at 200K. We'll see if things change as we go.
Tuesday, July 13, 2010
R-Evolve or Die
"Evolve or die!". I've heard that sentiment a few times lately related to existing technologies that are coming under fire for being too old and ugly in the face of "up and comers" with fancy interfaces and social connectivity. But the more I think of it, is "Evolve" the right answer?
I don't think so. The pace of evolution tends to be slow. At the start, you look more "different" than "evolutionary" and no one cares about that. No, I think you need to be "revolutionary" if you want to make a difference. And that's hard for veteran organizations that fear risk to pull off.
A great mentor of mine once told me: "Don't be tied to the technology". The example he came up with was Smalltalk. We had a whole product written in Smalltalk and it was awesome. And it would still be awesome today except for one thing. The UI didn't fit in with any other applications you may have been using. That and the companies that supported Smalltalk eventually died off. So what did we do? Well, we rewrote the whole thing with the help of standard desktop tools and languages and a huge code base we inherited in a takeover. Unfortunately the result was a big Windows app, but it got the job done and saved the product.
So what am I getting at? Well, I've got a renewed interest in the "IDE in the Cloud", somewhat sparked by Google's new experimental App Inventor for Android. I'm not a fan of the puzzle metaphor they picked, but it just got me thinking again of the power of the new browsers and web technologies and how we can apply them to the tools space. It does make the behemoth desktop IDE we have in Eclipse look old fashioned. But instead of thinking evolutionary, what would a revolutionary IDE look like in this new world?
I don't think so. The pace of evolution tends to be slow. At the start, you look more "different" than "evolutionary" and no one cares about that. No, I think you need to be "revolutionary" if you want to make a difference. And that's hard for veteran organizations that fear risk to pull off.
A great mentor of mine once told me: "Don't be tied to the technology". The example he came up with was Smalltalk. We had a whole product written in Smalltalk and it was awesome. And it would still be awesome today except for one thing. The UI didn't fit in with any other applications you may have been using. That and the companies that supported Smalltalk eventually died off. So what did we do? Well, we rewrote the whole thing with the help of standard desktop tools and languages and a huge code base we inherited in a takeover. Unfortunately the result was a big Windows app, but it got the job done and saved the product.
So what am I getting at? Well, I've got a renewed interest in the "IDE in the Cloud", somewhat sparked by Google's new experimental App Inventor for Android. I'm not a fan of the puzzle metaphor they picked, but it just got me thinking again of the power of the new browsers and web technologies and how we can apply them to the tools space. It does make the behemoth desktop IDE we have in Eclipse look old fashioned. But instead of thinking evolutionary, what would a revolutionary IDE look like in this new world?
Tuesday, June 29, 2010
Exploring Game Development with CDT
Well, it's holiday time. I'm off this week and next and it's filled up with a family union my wife and I are hosting, but I am stealing away some time now and then and my hobby time going forward with one of my dreams, building a game engine.
Of course, it's impossible to build a game engine yourself. So instead I am putting together a number of open source pieces and integrating them. The amount of code I need to write should be pretty small but should be significant enough to help me get some real world experience using CDT. The best way to get into the mind of some one who uses your tools and understand their needs is to actually be one for a while.
The key part of the CDT angle is multi-target development. The plug-in nature of Eclipse and CDT's support for tool chains allows it to be used to write applications for multiple platforms. In this case I'm going to do a mix of desktop and mobile featuring Windows and Linux on the desktop side and Android and eventually MeeGo on the mobile side. Android and MeeGo are particularly interesting in that I firmly believe these platforms could eventually find their way onto desktops one day. So writing a game that targets them and Windows and regular Linux desktop isn't really that much of a stretch. (BTW, yes, I'm purposely leaving out Apple for fear of getting trapped in the "walled garden").
For the engine components, I'm using the OGRE 3D rendering engine that is currently being ported to Android already (very cool to see). It uses freetype for fonts for displaying text and freeimage for loading images. I'll use bullet physics for the physics engine. There doesn't seem to be a common audio package so this may be custom per target with my own API over top. The same may be true for input, although the OGRE samples use OIS but that would need to be ported to Android.
The final piece of the puzzle will be the blender 3d editor which is going through a re-architecture right now and is extensible using python. Create your content using blender, export it with the help of python scripts and load it up into the game engine on all four platforms. Sounds like a dream that only the pros can pull off.
We'll see how far I get. But I benefit from it in two ways - living that dream, and getting some real life experience using Eclipse for serious application development that should lead to some ideas on making it better and maybe I'll come up with ideas for new tools. Sounds like a win-win.
Of course, it's impossible to build a game engine yourself. So instead I am putting together a number of open source pieces and integrating them. The amount of code I need to write should be pretty small but should be significant enough to help me get some real world experience using CDT. The best way to get into the mind of some one who uses your tools and understand their needs is to actually be one for a while.
The key part of the CDT angle is multi-target development. The plug-in nature of Eclipse and CDT's support for tool chains allows it to be used to write applications for multiple platforms. In this case I'm going to do a mix of desktop and mobile featuring Windows and Linux on the desktop side and Android and eventually MeeGo on the mobile side. Android and MeeGo are particularly interesting in that I firmly believe these platforms could eventually find their way onto desktops one day. So writing a game that targets them and Windows and regular Linux desktop isn't really that much of a stretch. (BTW, yes, I'm purposely leaving out Apple for fear of getting trapped in the "walled garden").
For the engine components, I'm using the OGRE 3D rendering engine that is currently being ported to Android already (very cool to see). It uses freetype for fonts for displaying text and freeimage for loading images. I'll use bullet physics for the physics engine. There doesn't seem to be a common audio package so this may be custom per target with my own API over top. The same may be true for input, although the OGRE samples use OIS but that would need to be ported to Android.
The final piece of the puzzle will be the blender 3d editor which is going through a re-architecture right now and is extensible using python. Create your content using blender, export it with the help of python scripts and load it up into the game engine on all four platforms. Sounds like a dream that only the pros can pull off.
We'll see how far I get. But I benefit from it in two ways - living that dream, and getting some real life experience using Eclipse for serious application development that should lead to some ideas on making it better and maybe I'll come up with ideas for new tools. Sounds like a win-win.
Subscribe to:
Posts (Atom)