I visited a website recently; it recommended using Internet Explorer version 6.0 or higher. I found the idea nostolgic and amusing.
The website was clearly designed several years ago, when there were good reasons to require specific browsers.
But today, such a statement makes one look foolish. Firefox, Safari, Chrome, and Opera all perform well. Internet Explorer's share of the market has dropped, and one must design a website for the bunch, not the one.
There is no good reason to design a website for a single browser, nor demand IE6 as a minimum. Even Microsoft is requesting that people move on from IE6!
Websites are dynamic, and even websites with static content must change. They must grow with the standards or die.
Wednesday, June 15, 2011
Saturday, June 11, 2011
Better programming with immutable objects
Recent buzz in the development community has discussed functional programming languages. These languages have a different approach to the organization of code. They are not object-oriented languages, nor are they procedural. Functional programming languages include Haskell, Erlang, and F#.
Working with old-fashioned object-oriented languages (C++ and C#), I suffer from language envy. I can see the shiny new languages but use the old, dented languages for my daily work. (Of course, I recognize that at one time C# and even C++ were the new, shiny languages. I also recognize that at some point in the future, Haskell and F# will be considered the old, dented languages. But for now, the grass is greener over the fence and in the yard of the new languages.)
I may be suffering from envy, but I don't sit and curse the darkness. Instead, I try to use the techniques of the new languages in my current toolset. I did this when programming in C and gazing longingly at C++; I wrote code in a style that I called "thing-oriented" programming. My thing-oriented programming let me identify key objects in the code (data structures, not objects in the OO sense) and collect and organize functions by the objects they manipulated. It was a step towards object-oriented programming. (Eventually I did learn C++ and work on C++ projects.)
With the introduction of C# and .NET, I used the same idea. For this transition, I wrote class libraries in C++ that mimicked the class libraries in .NET. (Not the entire .NET collection, just the basic classes to get the work done.) The work was a bit difficult, as we were not allowed to use STL. But like "thing-oriented programming", it was a step towards .NET and made the transition easier.
So here I am again, and this time the target is functional programming languages. I want to transition to functional programming from object-oriented programming, but don't have the tools. (The day job uses "classic" OO languages, and I struggle to find time outside of the office.)
My transition technique is to use "immutable object programming".
This has some interesting effects:
1) To construct an object, all data must be present. I cannot instantiate an object and later give it more information. Once an object is instantiated, it is complete and final. (I can construct other objects from built objects, so I can construct a "sales price" object and later use it to construct a "discounted sales price" object. But I cannot wedge in a discount to the "sales price".
2) I find myself thinking about the sequence of operations and the dependencies between objects.
3) My programs are designed in three phases: collect data (and construct objects), construct other objects from the collected data, and produce output. This is a pattern that goes back to the beginnings of the programming age. It may be a natural fit for the "immutable object programming" style, or it may be driven by the calculations of the systems.
4) My thinking is more rigorous. Not necessarily up front, but the end result (the final code) is more disciplined. I write some code, and sometimes take non-immutable shortcuts (or even OO shortcuts). These shortcuts are obviously wrong, but they yield the correct output. Once I have the correct output (and tests to check that output), I revise the code and remove the shortcuts.
5) My code is easy to debug. When the output is incorrect, I know that an object has incorrect data. (Or possibly the output routine is incorrect.) If the object has incorrect data, I know that it was constructed improperly. (There is no other method that modifies the object.) Finding the problem is a simple matter of identifying the incorrect object and then identifying the construction of that object.
6) My code is easy to change. I have made a number of changes to the code, and all have been simple and obvious. (And therefore, they worked.) These were not trivial changes, either; some were large and affected multiple modules.
I will admit that I do not understand functional programming languages. I have created some small programs in Haskell, but not enough that I "grok" the concept. My "immutable object programming" trick may be a step towards functional programming or it may be a step away from functional programming. It feels right, and I like the results.
Wednesday, June 8, 2011
The tweet is more powerful than the sword
People are surprised that companies respond quickly to complaints and questions posted to them on Twitter.
I find the rapid response predictable, once you think about it.
E-mails are, for the most part, one-to-one messages. A complaint e-mail especially so. I'm not going to CC: friends on a complaint e-mail to my bank, or my insurance company, because that simply loads their inboxes with clutter. An e-mail is a private conversation between you and the company. The company can delay response or ignore it completely at practically no cost.
Tweets, on the other hand, are a one-to-many message. They are not a letter to a friend (or business) but are published to many people. They are viewed by one's followers, and some people have hundreds of thousands of followers.
If Twitter were that simple, then companies could evaluate the importance of the Tweeter and answer only those tweets from users with large followings.
But it's more complex. All tweets are part of the TwitterStream, and anyone can look at any message (just about). I recently tweeted about my bank and used a hashtag to identify them. The bank was not following me (and is still not following me, from what I can tell) but they found the message anyway, and responded. Tweets are public postings, messages published to potentially the entire world. Tweets with hashtags are advertisements, not approved by the marketing department.
With messages going out to the globe, a company has no choice but to respond, and respond quickly. If they don't, the next tweet might just be "hey, #companyX ignored my tweet. is anyone home?", which translates to more negative advertising.
I think every company, organization, and government office should be watching the TwitterStream for messages about themselves. You want to know what people are saying about you.
I find the rapid response predictable, once you think about it.
E-mails are, for the most part, one-to-one messages. A complaint e-mail especially so. I'm not going to CC: friends on a complaint e-mail to my bank, or my insurance company, because that simply loads their inboxes with clutter. An e-mail is a private conversation between you and the company. The company can delay response or ignore it completely at practically no cost.
Tweets, on the other hand, are a one-to-many message. They are not a letter to a friend (or business) but are published to many people. They are viewed by one's followers, and some people have hundreds of thousands of followers.
If Twitter were that simple, then companies could evaluate the importance of the Tweeter and answer only those tweets from users with large followings.
But it's more complex. All tweets are part of the TwitterStream, and anyone can look at any message (just about). I recently tweeted about my bank and used a hashtag to identify them. The bank was not following me (and is still not following me, from what I can tell) but they found the message anyway, and responded. Tweets are public postings, messages published to potentially the entire world. Tweets with hashtags are advertisements, not approved by the marketing department.
With messages going out to the globe, a company has no choice but to respond, and respond quickly. If they don't, the next tweet might just be "hey, #companyX ignored my tweet. is anyone home?", which translates to more negative advertising.
I think every company, organization, and government office should be watching the TwitterStream for messages about themselves. You want to know what people are saying about you.
Thursday, June 2, 2011
Windows 8 shows Microsoft's big problem
We have seen the future, and for Windows, the future looks a lot like Windows Phone 7. Microsoft has let folks see glimpses of the not-yet-released version of Windows. Some have raved and others have yawned.
A long time ago, Windows was created with three goals in mind: provide a graphical interface for PCs, counter the threat from from the new Macintosh computer, and hide the command line interface from users.
Windows 8 continues those objectives. It provides a nice-looking interface, it counters the recent advances made by Apple, and once again it hides complexity from the user.
But Windows 8 is not Microsoft using the same strategy as Apple. For the iPods and iPhones, Apple created a new operating system, a new user interface, and a new way of computing. It made a clean break from the Mac OSX line. Microsoft, in contrast, is betting on backwards-compatibility, and Windows 8, with its shiny interface, can run older Windows programs.
Backwards compatibility is a blessing and a curse for Microsoft. It allows their customers to move gradually to the new operating system, keeping their existing applications. Yet it means that Microsoft must support a lot of complicated (and sometimes just plain wrong) APIs. (For example, the Windows Registry will be present in Windows 8, despite almost universal hatred of the thing. But too many programs depend on it, and Microsoft is stuck with it.)
Microsoft has trained customers to expect backwards compatibility.
Apple has trained its customers to expect new platforms. The history of Apple products in littered with abandoned platforms: Apple II DOS, the original Mac OS, the later Mac OS version 6 through 9, the Motorola processors, and the Power PC chips. When Apple introduced a new iOS operating system for the iPod and iPhone, no one blinked.
Microsoft could never get away with anything like that. The release of Windows Vista with its limited support for devices brought howls.
Microsoft's fate, like it or not, is tied to Windows. Which means that Microsoft must drag Windows to any market that it chooses to enter. The XBOX runs Windows, the Zune runs (OK, ran) Windows, the Media Center runs Windows... everything Microsoft does runs Windows.
Or to put it another way, Microsoft does everything with Windows. And the consequences of that are... Windows must be extended, stretched, folded, spindled, and mutilated into any new product.
Microsoft's growth is limited by its ability to expand Windows. And that is Microsoft's big problem.
A long time ago, Windows was created with three goals in mind: provide a graphical interface for PCs, counter the threat from from the new Macintosh computer, and hide the command line interface from users.
Windows 8 continues those objectives. It provides a nice-looking interface, it counters the recent advances made by Apple, and once again it hides complexity from the user.
But Windows 8 is not Microsoft using the same strategy as Apple. For the iPods and iPhones, Apple created a new operating system, a new user interface, and a new way of computing. It made a clean break from the Mac OSX line. Microsoft, in contrast, is betting on backwards-compatibility, and Windows 8, with its shiny interface, can run older Windows programs.
Backwards compatibility is a blessing and a curse for Microsoft. It allows their customers to move gradually to the new operating system, keeping their existing applications. Yet it means that Microsoft must support a lot of complicated (and sometimes just plain wrong) APIs. (For example, the Windows Registry will be present in Windows 8, despite almost universal hatred of the thing. But too many programs depend on it, and Microsoft is stuck with it.)
Microsoft has trained customers to expect backwards compatibility.
Apple has trained its customers to expect new platforms. The history of Apple products in littered with abandoned platforms: Apple II DOS, the original Mac OS, the later Mac OS version 6 through 9, the Motorola processors, and the Power PC chips. When Apple introduced a new iOS operating system for the iPod and iPhone, no one blinked.
Microsoft could never get away with anything like that. The release of Windows Vista with its limited support for devices brought howls.
Microsoft's fate, like it or not, is tied to Windows. Which means that Microsoft must drag Windows to any market that it chooses to enter. The XBOX runs Windows, the Zune runs (OK, ran) Windows, the Media Center runs Windows... everything Microsoft does runs Windows.
Or to put it another way, Microsoft does everything with Windows. And the consequences of that are... Windows must be extended, stretched, folded, spindled, and mutilated into any new product.
Microsoft's growth is limited by its ability to expand Windows. And that is Microsoft's big problem.
Tuesday, May 31, 2011
Fast food software
Our industry of software development has used the "large software" model for development. By "large software", I mean software that costs a lot. Not just in purchase cost (or support licenses) but in care and feeding.
In contrast, the O'Reilly conferences use tech to involve people. They have a web site. You can create a profile. The web site has a schedule of sessions, and you can create your personal schedule, picking those sessions that interest you.
The difference between the two organizations is technical firepower. O'Reilly has the wherewithal to hire folks and make the interaction happen. Science fiction conventions are often volunteer-run and have little technical expertise on staff.
I suspect that a lot of small organizations, companies, and government agencies are in similar situations. They probably use PCs with Windows, MS-Office, and Internet Explorer... because that's the software that is on the PC when they take it out of the box. Small organizations don't have IT support teams and cannot adopt today's high-tech solutions (the effort outstrips the one guy who sets up the PCs).
Small shops are too often run on a bunch of PCs, a router, and shared spreadsheets. (Or worse, passed-around spreadsheets, and we're not really sure who has the latest changes.) They don't have the expertise to install and support custom-made systems. (I suspect that many small shops don't have the experience to install MS-Office and track licenses and activation codes.)
Smartphones and tablets (and the cloud) are a possible solution here. The model provided by smartphones and tablets is a good fit for these small organizations. Installation of software is handled by a single click. (No license, no activation code, no special instructions.) Smartphone and tablet software is also priced within the budget of a small organization. The local Mom-and-Pop store will never, ever, purchase and install an ERP system (nor should they) but they can record expenses on their phones.
The business model for small software is different from the business model for large software. Large software is like a dinner at a high-end restaurant: You have personal service and you meal is prepared according to your specifications. Small software is fast food: You pick a set of items from a limited menu and your meal is handed to you from a stack of prepared items, with little or no personalization. It is not elegant... but it is fast, predictable, and cheap.
With the right combination of front-end software (on tablets and phones) and back-end software (in the cloud), small organizations will be able to use tech and involve their customers. (And involve their customers in a way that is easy for customers to use.)
There is a market here. It's different from the current market, in terms of tech and business. It is a high-volume, low-margin market. And for those who exploit it capably, very profitable.
Monday, May 30, 2011
Tablets and cloud, perfect together
If you want to see the future of computing, look at tablet computers and cloud computing. These two technologies complement each other and provide exciting opportunities for new applications.
Tablet computers (riding on wi-fi and cell networks) provide computation power to people when they want, where they want. Cloud computing can provide the support for tablet applications, either for music or video or plain ole' apps. Alone, either platform is nice but not so hot. Combined, the two will do well.
The two technologies will mean excitement for developers, too. Cloud apps are different from web apps and PC apps, and I believe a new language will be selected for the standard for cloud apps. (Just which language is not clear at the moment, but I suspect a functional programming language.)
I don't see PC apps or web apps disappearing, but i do see less emphasis on them. I suspect that we have seen all of the major PC apps, and that only custom, highly specific applications will be developed for PCs. There will be no new "killer app" for PCs, no new "Lotus 1-2-3" or "Word", no new PC app that everyone must have. We may see new apps for the (non-tablet) web, but every new web app will have a tablet/phone counterpart.
The tablets (and smartphones) rule! We will see new tablet/phone apps backed by the cloud. Some will have web counterparts, but many will not.
The tablet/cloud future awaits!
Thursday, May 26, 2011
Build on clouds
Folks have put effort (some folks lots of effort) into making the cloud look and behave like plain old PC applications. Not just the look and feel of apps, but the techniques to build those apps. Microsoft has designed their tools to make the development of cloud apps a lot like the development of PC applications. (Their tools also make the development of web apps similar to the development of PC apps.)
I think that this is the wrong approach.
I recognize the benefits of similar environments and tools. A single method is easier to learn and support. One can move from development on one project to development on another (different platform) project.
But there is nothing in the PC app development model that makes it the right model for all platforms.
The PC app toolset has a long history. We started with the tools and techniques of the mainframe and minicomputer platforms, but didn't keep them. We adopted the notions of compilers, interactive command lines, and version control, and then built our own tools that leveraged PC resources: the IDE, interactive debuggers, and GUI designers. We abandoned the processes of desk-checking software and symbol cross-references; we built modern processes, from code reviews to automated testing.
With cloud computing, expect new methods and tools that leverage the resources of the cloud. You won't use the new techniques if you stay in the PC mindset.
If you must have a single development platform, make it the cloud. That is, make the process and tools for the development of PC apps look and feel like the process for the development of cloud apps. Instead of adapting the cloud to the PC app process, create a process for cloud apps and then adapt it to the PC app process.
I think that this is the wrong approach.
I recognize the benefits of similar environments and tools. A single method is easier to learn and support. One can move from development on one project to development on another (different platform) project.
But there is nothing in the PC app development model that makes it the right model for all platforms.
The PC app toolset has a long history. We started with the tools and techniques of the mainframe and minicomputer platforms, but didn't keep them. We adopted the notions of compilers, interactive command lines, and version control, and then built our own tools that leveraged PC resources: the IDE, interactive debuggers, and GUI designers. We abandoned the processes of desk-checking software and symbol cross-references; we built modern processes, from code reviews to automated testing.
With cloud computing, expect new methods and tools that leverage the resources of the cloud. You won't use the new techniques if you stay in the PC mindset.
If you must have a single development platform, make it the cloud. That is, make the process and tools for the development of PC apps look and feel like the process for the development of cloud apps. Instead of adapting the cloud to the PC app process, create a process for cloud apps and then adapt it to the PC app process.
Subscribe to:
Posts (Atom)