I attended the CMAP meeting tonight. The presentation was on Windows 8 and Metro. It was good to see the new version of Windows live -- up to now I have only read about it.
Windows 8 is a compromise between classic Windows and the new world of touch/swipe apps. I'm not sure that "compromise" is the right word -- it seems to be two distinct things bound with duct tape. The new Windows Metro UI is quite attractive and very different from the classic UI. Windows 8's classic UI is close to Windows 7's UI; only the "Start" button is absent. Switching between the two modes is abrupt and not always expected.
The push for Metro and a touch-screen interface shows the success of Apple and its iPhone and iPad products. I'm sure that Microsoft had a plan for touchscreen devices and interfaces (the "Surface" technologies) and has accelerated and changed that plan to meet the competition.
Most disturbing with the new Metro UI (and its underlying WinRT API) is the loss of lots of tools and packages. Flash is not available, nor is Silverlight. Developer tools such as Entity Frameworks are not available.
Lots of Windows fans are upset -- and I understand. A lot of their hard-won knowledge has been invalidated with Windows 8 and Metro. While the classic side of Windows 8 still allows for these technologies, one can clearly see that their lifetime is limited. (And therefore the lifetime of the knowledge is limited.)
Yet there is no escape. Microsoft is just as trapped on this treadmill of evolving technology. We are all running as fast as we can to stay in place.
Tuesday, April 10, 2012
Sunday, April 8, 2012
Why BYOD will encourage companies to the cloud
A number of companies have adopted "bring your own devices" policies, allowing employees to bring their own computing devices to the office and use those devices for work. The policies have been applauded by some (generally the libertarians of the office who see freedom and the accountants of the office who see reduced corporate expenditures for equipment). "Bring your own devices" policies are generally criticized by the security and infrastructure support teams: one cannot lock down an employee's device to the same extent as company-owned equipment, and the larger number of devices is harder to configure for corporate use.
There is another aspect of "bring your own devices" policies, one that I see few people discussing. That aspect is the tie-in with cloud computing.
With a "bring your own devices" policy, the employer-employee relationship changes. With the tradition "company supplies all equipment" rules, the company owned all data and all equipment that held the data. Employees may be assigned computers, but the understanding was that the computer belonged to the company. A company could re-assign a computer, take it off-line for maintenance, and install upon it any software it wished. When an employee moved from one position to another, or from one department to another, or left the company, the equipment (and therefore the data stored on that equipment) stayed behind.
The rules for "bring your own devices" change that situation. When employees bring their own devices, the devices are their property, not the company's. The company cannot re-assign the device. When an employee is transferred from one department to another, or when they end their employment, their devices follow them -- they do not stay with the department or the company.
So what happens to the data stored on that device?
I suppose that some companies will implement policies that insist upon the deletion of data in such instances. They might be difficult to enforce, especially with less-than-friendly terminations of employment.
A better solution is to not store data on the device. Instead, store company data on company servers, and allow employees access to that data. When an employee moves from one department to another, change their access to allow for the new department's data (and remove access to the old department's data). If an employee leaves the organization, rescind their access.
I find this a more secure solution.
Cloud computing seems a natural fit for this solution. Small apps that allow access to data (but do not store the data locally) will let employees get the work done while maintaining the security of the data.
Perhaps "cloud" is not quite the proper solution here, since one may not need the scalability of cloud computing. Perhaps a better description would be "server-stored data and app-based access". But that's quite a mouthful and who would ever want to say all of that?
Regardless of what you call your solution, look at storing data on corporate servers and allowing access through "outside" (non-corporate-owned) devices. I expect that the division of labor will provide you with insight into the work being done within your company.
There is another aspect of "bring your own devices" policies, one that I see few people discussing. That aspect is the tie-in with cloud computing.
With a "bring your own devices" policy, the employer-employee relationship changes. With the tradition "company supplies all equipment" rules, the company owned all data and all equipment that held the data. Employees may be assigned computers, but the understanding was that the computer belonged to the company. A company could re-assign a computer, take it off-line for maintenance, and install upon it any software it wished. When an employee moved from one position to another, or from one department to another, or left the company, the equipment (and therefore the data stored on that equipment) stayed behind.
The rules for "bring your own devices" change that situation. When employees bring their own devices, the devices are their property, not the company's. The company cannot re-assign the device. When an employee is transferred from one department to another, or when they end their employment, their devices follow them -- they do not stay with the department or the company.
So what happens to the data stored on that device?
I suppose that some companies will implement policies that insist upon the deletion of data in such instances. They might be difficult to enforce, especially with less-than-friendly terminations of employment.
A better solution is to not store data on the device. Instead, store company data on company servers, and allow employees access to that data. When an employee moves from one department to another, change their access to allow for the new department's data (and remove access to the old department's data). If an employee leaves the organization, rescind their access.
I find this a more secure solution.
Cloud computing seems a natural fit for this solution. Small apps that allow access to data (but do not store the data locally) will let employees get the work done while maintaining the security of the data.
Perhaps "cloud" is not quite the proper solution here, since one may not need the scalability of cloud computing. Perhaps a better description would be "server-stored data and app-based access". But that's quite a mouthful and who would ever want to say all of that?
Regardless of what you call your solution, look at storing data on corporate servers and allowing access through "outside" (non-corporate-owned) devices. I expect that the division of labor will provide you with insight into the work being done within your company.
Friday, April 6, 2012
A day of telework
This week I had the opportunity to telework, or as it is often called, "work from home". It was one day out of the week.
My experience with telework was, overall, positive. I was able to connect to the systems in the office (I keep wanting to use the phrase "dial in", but there is no dialing involved) and run the needed programs.
My chair at home is much less comfortable that the chair in the office. I found that had to stand and stretch every thirty minutes, somewhat more frequently than when I am in the office.
My monitor at home is smaller (in terms of resolution) than the monitors in the office. The remote-access programs run in a browser and assume that your display is as large as the displays in the office. When they are smaller (as mine is) you get scroll bars. The programs I used (Microsoft Visual Studio, the DOS command prompt, and MS-Outlook) wanted windows larger than my home monitor. I could resize them, but only the DOS prompt resized gracefully. Outlook and Visual Studio are designed for large displays, and I found myself scrolling.
Performance was acceptable. My work involves little in the way of graphic manipulation; almost everything I do is in text mode.
I expect telework to be a rare occurrence. Should it become frequent, I will invest in a better monitor and chair.
My experience with telework was, overall, positive. I was able to connect to the systems in the office (I keep wanting to use the phrase "dial in", but there is no dialing involved) and run the needed programs.
My chair at home is much less comfortable that the chair in the office. I found that had to stand and stretch every thirty minutes, somewhat more frequently than when I am in the office.
My monitor at home is smaller (in terms of resolution) than the monitors in the office. The remote-access programs run in a browser and assume that your display is as large as the displays in the office. When they are smaller (as mine is) you get scroll bars. The programs I used (Microsoft Visual Studio, the DOS command prompt, and MS-Outlook) wanted windows larger than my home monitor. I could resize them, but only the DOS prompt resized gracefully. Outlook and Visual Studio are designed for large displays, and I found myself scrolling.
Performance was acceptable. My work involves little in the way of graphic manipulation; almost everything I do is in text mode.
I expect telework to be a rare occurrence. Should it become frequent, I will invest in a better monitor and chair.
Tuesday, April 3, 2012
An infinite loop, and success with BASIC
Today I wrote a program. In BASIC. It had an infinite loop. By accident.
I think that the last time I wrote a BASIC program with an infinite loop (accidental or otherwise) was in the 1980s. (Probably the early 1980s.)
The program was a "Celcius to Fahrenheit" table generator. It was easy enough to write (I do remember BASIC) and it revealed some defects in the BASIC-1965 interpreter. One was in the parsing of arithmetic expressions and the other was in the computation of arithmetic expressions. The parsing was easily fixed, once identified. (I had the wrong logic for precedence of operators.) The calculation of an expression was a bit trickier; Ruby (the language that runs the BASIC interpreter) uses two types for numbers: Float and Integer. My math worked for the add, subtract, and multiple operations; I had to adjust the divide operation to return either a Float or an Integer.
After resolving the problems, my BASIC program works as expected. Woot! Today counts as the day that my first "real" program ran successfully.
I think that the last time I wrote a BASIC program with an infinite loop (accidental or otherwise) was in the 1980s. (Probably the early 1980s.)
The program was a "Celcius to Fahrenheit" table generator. It was easy enough to write (I do remember BASIC) and it revealed some defects in the BASIC-1965 interpreter. One was in the parsing of arithmetic expressions and the other was in the computation of arithmetic expressions. The parsing was easily fixed, once identified. (I had the wrong logic for precedence of operators.) The calculation of an expression was a bit trickier; Ruby (the language that runs the BASIC interpreter) uses two types for numbers: Float and Integer. My math worked for the add, subtract, and multiple operations; I had to adjust the divide operation to return either a Float or an Integer.
After resolving the problems, my BASIC program works as expected. Woot! Today counts as the day that my first "real" program ran successfully.
Sunday, April 1, 2012
Harrisburg Barcamp
I attended Harrisburg Barcamp this week-end. A good choice: it had a lot of creative people and good discussions throughout.
Book-ending the conference (technically an un-conference) were train rides. I departed work early and took the train from Washington to Harrisburg (via Philadelphia) on Friday night, stayed over at the local Holiday Inn, and arrived at the conference refreshed. I departed the conference early Saturday evening, reversing the train trip from Harrisburg to Philadelphia and then on to Baltimore.
I find that travelling by train lets me relax and also lets me get work done. I took the opportunity to catch up on some reading. (I can read on planes, although the seats are smaller and the arrangement is cramped. Reading while driving is not recommended.)
The barcamp topic was "tech and ed"; our sessions were light on the education aspect but not overly heavy on the technical side. One session was about virtual presentations, another was on careers and networking, and a third was on preparing for the next ten years of technical change.
I held a session on "is tech changing too quickly for our own good", and it had a number of attendees with good ideas. I held it as a conversation and not a lecture, and that format worked.
I'm glad that I attended. Its good to get away from "the usual suspects" and talk with other people.
Book-ending the conference (technically an un-conference) were train rides. I departed work early and took the train from Washington to Harrisburg (via Philadelphia) on Friday night, stayed over at the local Holiday Inn, and arrived at the conference refreshed. I departed the conference early Saturday evening, reversing the train trip from Harrisburg to Philadelphia and then on to Baltimore.
I find that travelling by train lets me relax and also lets me get work done. I took the opportunity to catch up on some reading. (I can read on planes, although the seats are smaller and the arrangement is cramped. Reading while driving is not recommended.)
The barcamp topic was "tech and ed"; our sessions were light on the education aspect but not overly heavy on the technical side. One session was about virtual presentations, another was on careers and networking, and a third was on preparing for the next ten years of technical change.
I held a session on "is tech changing too quickly for our own good", and it had a number of attendees with good ideas. I held it as a conversation and not a lecture, and that format worked.
I'm glad that I attended. Its good to get away from "the usual suspects" and talk with other people.
Subscribe to:
Posts (Atom)