I attended the CALUG (Columbia Area Linux User Group) meeting tonight. The presentation was on IBM z/OS and virtual Linux machines.
It was a good presentation! A clear overview and lots of technical details. More impressive than the presentation was the set of questions asked by members of the audience. They knew their stuff, from old IBM mainframe concepts (partitions, microcode, and DASD) to the new concepts (virtual machines, Linux instances, and databases). OK, perhaps the concept of a virtual machine is not that new. But the audience was interested and inquisitive.
I left with a lot of information about z/OS and Linux. IBM has made some good choices with its technologies, and I think they are well-positioned to leverage their tech for cloud apps.
Wednesday, May 11, 2011
Tuesday, May 10, 2011
Into the cloud
I am building a vision of my next set of technology. Here's what I have:
- Tablet for user interface (the "front end"), probably Android
- Cloud for data storage and processing (the "back end"), probably Amazon.com EC2
I have considered other platforms (Google App Engine, Azure) and interfaces (iPhone, Windows Phone). My picks seem the easiest for starting a new venture. In part, I follow the path of least resistance. I will say that my experience with the Android phone was an influence in my choices.
- Tablet for user interface (the "front end"), probably Android
- Cloud for data storage and processing (the "back end"), probably Amazon.com EC2
I have considered other platforms (Google App Engine, Azure) and interfaces (iPhone, Windows Phone). My picks seem the easiest for starting a new venture. In part, I follow the path of least resistance. I will say that my experience with the Android phone was an influence in my choices.
Tuesday, May 3, 2011
Code but no coding
I attended the CMAP meeting tonight and heard a presentation on MVC 3 from Microsoft. MVC 3 is a web development thing, allowing you to build web applications. it takes advantage of .NET, HTML 5, jQuery, and a few Microsoft-specific packages. Using the packages and tools, one can assemble a slick web application quickly.
The presenter walked us through the development a calendar application. It took all of about 90 minutes.
My impression: easy to use, lots of code, but very little coding. There was code on the screen (C# and HTML) but not much in the way of creating code. The wizards did a lot of the work, and the work was mostly connecting existing pieces, not writing functions, methods, or classes.
Is this the future of coding? I guess it is, in Microsoft's view. This is coding so simple that anyone can do it -- as long as the understand the components that are available. Sixty years ago, coding was in assembly language and you had to know the processor architecture and the operating system calls. Forty years ago, coding was in a high-level language and you had to know the language and its (rather limited) library. Now you have to know the language syntax and a large collection of library classes and their methods, and most of the effort is for the libraries.
The presenter walked us through the development a calendar application. It took all of about 90 minutes.
My impression: easy to use, lots of code, but very little coding. There was code on the screen (C# and HTML) but not much in the way of creating code. The wizards did a lot of the work, and the work was mostly connecting existing pieces, not writing functions, methods, or classes.
Is this the future of coding? I guess it is, in Microsoft's view. This is coding so simple that anyone can do it -- as long as the understand the components that are available. Sixty years ago, coding was in assembly language and you had to know the processor architecture and the operating system calls. Forty years ago, coding was in a high-level language and you had to know the language and its (rather limited) library. Now you have to know the language syntax and a large collection of library classes and their methods, and most of the effort is for the libraries.
Monday, April 25, 2011
Haskell, improved
I showed my Haskell program to a co-worker today. As we were looking at it, we noticed some possible improvements. (Surprising, since neither of us are Haskell programmers.)
I tried the changes this evening, and they do indeed work. We've simplified the program and made the logic clearer. I also expanded the program to handle a list of payment values, and not assume that each payment is the same value. It was quite easy to do -- much easier than similar changes to a C++ or C# program.
Saturday, April 23, 2011
Haskell for real
Today was the day that I wrote a 'real' -- that is a non-trivial, example-from-the-book -- program. It was an exhilarating experience.
The program (actually three functions) computes the price of a stream of payments.
I was inspired by a task at the office: review code that computes the price of the stream of payments. The code was in two forms: Java and Fortran. The code also came with the math for the calculations, and I immediately thought of functional programming.
Today I set aside some time and dug out the one book on Haskell in my library. It had enough to get me started. With the book and the math, I was on a programming adventure!
Programming in Haskell is a trip. Just as object-oriented programming was alien to my brain trained in procedural programming, functional programming is alien to my brain now trained in object-oriented programming. I struggled a bit with the syntax and with the design of the program, and emerged victorious! I had a set of functions that performed the desired calculations. (I checked them with math calculated in a spreadsheet.)
The Haskell version is shorter and cleaner than the procedural versions. (The Fortran version is obviously procedural, and the Java version makes no use of object-oriented constructs.) The procedural version uses a loop and a temporary variable that is assigned at the end of the loop so that it can be used the *next* time through the loop.
The Haskell version has no loops and no assign-at-the-end distraction. If you know the syntax, it is straightforward and easy to understand. I believe it to be less efficient than the procedural versions (efficient meaning 'less CPU time') so with Haskell I have gained programmer time at the expense of CPU time, a trade-off that I am willing to accept.
I will say that I don't fully understand the Haskell version. That is, I am not fluent in the syntax. I have internalized the syntax of Fortran, C, Java, and other languages so I can look at the code and know what it does without thinking. I am still in the "think about the code" stage with Haskell. (And that's OK. I expect a ramp-up time with a new language.)
The program (actually three functions) computes the price of a stream of payments.
I was inspired by a task at the office: review code that computes the price of the stream of payments. The code was in two forms: Java and Fortran. The code also came with the math for the calculations, and I immediately thought of functional programming.
Today I set aside some time and dug out the one book on Haskell in my library. It had enough to get me started. With the book and the math, I was on a programming adventure!
Programming in Haskell is a trip. Just as object-oriented programming was alien to my brain trained in procedural programming, functional programming is alien to my brain now trained in object-oriented programming. I struggled a bit with the syntax and with the design of the program, and emerged victorious! I had a set of functions that performed the desired calculations. (I checked them with math calculated in a spreadsheet.)
The Haskell version is shorter and cleaner than the procedural versions. (The Fortran version is obviously procedural, and the Java version makes no use of object-oriented constructs.) The procedural version uses a loop and a temporary variable that is assigned at the end of the loop so that it can be used the *next* time through the loop.
The Haskell version has no loops and no assign-at-the-end distraction. If you know the syntax, it is straightforward and easy to understand. I believe it to be less efficient than the procedural versions (efficient meaning 'less CPU time') so with Haskell I have gained programmer time at the expense of CPU time, a trade-off that I am willing to accept.
I will say that I don't fully understand the Haskell version. That is, I am not fluent in the syntax. I have internalized the syntax of Fortran, C, Java, and other languages so I can look at the code and know what it does without thinking. I am still in the "think about the code" stage with Haskell. (And that's OK. I expect a ramp-up time with a new language.)
Thursday, April 21, 2011
Privacy? What privacy?
The news that the iPhone was tracking your location in a "secret" file had barely broken when more news came out that Android phones are doing the same thing. And then we had the news that yes, Apple and Google are collecting this location data, and in sum, know where we are.
Some folks will cry "havoc" and let slip the dogs of war for privacy. But let's be honest: we knew that something like this was coming. We in the tech industry know that service providers (in the larger sense, from cell phone companies to banks to game vendors) collect data on customers. On-line web sites have been collecting data about customers, from their e-mail addresses to their click-through habits. And government officials have subpoenaed that information and used it for criminal prosecutions (and possibly other purposes).
The advocates of this data collection will say (or perhaps only some will say): "If you don't want your data collected, don't use a cell phone." This is similar to saying, "If you don't like the high cost of gasoline, don't drive a car -- use public transit." In this country, not driving is practical in a small subset of geography; cell phones are about to become a necessity perhaps greater than an automobile.
I'm afraid that Mark Zuckerberg of Facebook was correct. We will sell our privacy for shiny applications and the ability to look cool in front of our friends.
Some folks will cry "havoc" and let slip the dogs of war for privacy. But let's be honest: we knew that something like this was coming. We in the tech industry know that service providers (in the larger sense, from cell phone companies to banks to game vendors) collect data on customers. On-line web sites have been collecting data about customers, from their e-mail addresses to their click-through habits. And government officials have subpoenaed that information and used it for criminal prosecutions (and possibly other purposes).
The advocates of this data collection will say (or perhaps only some will say): "If you don't want your data collected, don't use a cell phone." This is similar to saying, "If you don't like the high cost of gasoline, don't drive a car -- use public transit." In this country, not driving is practical in a small subset of geography; cell phones are about to become a necessity perhaps greater than an automobile.
I'm afraid that Mark Zuckerberg of Facebook was correct. We will sell our privacy for shiny applications and the ability to look cool in front of our friends.
More cloud stuff
I attended the Capital Area Cloud User Group meeting tonight. (My, that's a lot of syllables!)
This was the group's first meeting at their new location in Rosslyn. I find this location more convenient -- and more spacious. I think that it is a good change for them.
The presentation was on Salesforce.com and some recent changes that improve their web UI. I am impressed with their selection of improvements. One feature (they call it "inline editing") enables the in-form editing of fields without round-trips to the server. (So I infer that they are using AJAX and probably jQuery.) Enabling this feature is easy, much easier than anything I have seen in the Microsoft world. (Yes, you can do it with Microsoft's tech, but it ain't pretty to code.)
This was the group's first meeting at their new location in Rosslyn. I find this location more convenient -- and more spacious. I think that it is a good change for them.
The presentation was on Salesforce.com and some recent changes that improve their web UI. I am impressed with their selection of improvements. One feature (they call it "inline editing") enables the in-form editing of fields without round-trips to the server. (So I infer that they are using AJAX and probably jQuery.) Enabling this feature is easy, much easier than anything I have seen in the Microsoft world. (Yes, you can do it with Microsoft's tech, but it ain't pretty to code.)
Subscribe to:
Posts (Atom)