In 1982, a group of students at Carnegie Mellon University developed a soda vending machine that allowed customers to check the availability of soda in the machine remotely. Interested customers could talk to the machine from their computers, using the Unix finger protocol, and get the machine to respond back with the relative temperature and availability of soda in the vending machine. This machine was later dubbed the Internet Coke Machine and was a hit among people in the area at that time.
The Internet Coke Machine was also the first "connected" appliance. For those unfamiliar with connected appliances, these are devices that traditionally serve a rather simple and singular role (e.g. a toaster), but are developed to connect to a network and interact with other devices on the network (e.g. a toaster that informs your cellphone that it's time to take out the toast). Connected appliances are meant to augment the user's experience with them, providing extra information to the user or providing data to other connected appliances.
Sunday, May 10, 2015
Sunday, November 2, 2014
What does this button do?
 |
| A mysterious button appears |
As I write this, I still don't know what the icon pictured above signifies, even though I got it from a mobile app that I've used almost once a week for several weeks. The icon is part of a mysterious button that I've been having an internal conflict with.
With the fear of the unknown in my heart, I've stared at the button for weeks, afraid to touch it, afraid to prod and explore, afraid of what it does — it stares right back, its arrow pointing accusingly as if it should be glaringly obvious what it means, making me feel dumb for not knowing. Would pressing it download something to my device? Would it invite all my contacts to the app? Would it share my deepest, darkest secrets to the world?
What could the three dots emanating from a circle signify? A "Share" action, perhaps? Then what does the diagonally pointing arrow mean? Towards what is it pointing?
Tuesday, April 1, 2014
Watch the clock
"Time is a fickle mistress," some say, as they try to rationalize their youth — or what is left of it — withering away. Temporal measurement has intrigued humankind since we were aware that all lives begin and end within some set duration.
However, instead of waxing philosophical about time as a concept, I have always wanted to write about the problem with our human valuation of time, especially how it affects the computers we use daily. I was inspired last year to write down my problems after I spent a dreadful 3 months fixing various bugs with one of my apps, Eduplanner, which is in essence an event scheduler. Time (the dimension, not the magazine) was the cause of all these bugs.
Readers old enough may remember the scare of the Y2K bug. There were even TV shows and songs about it. This problem arose due to the way computers stored time prior to the year 1999.
Apple, the company, has faced several issues with the software on their iPhones; from alarm clocks going off one-hour late every New Year to the system clock on the devices displaying time one hour behind after daylight savings time change. Even Google has not been exempt from the issues of time. The Android OS once had a bug that omitted "December" from the calendar app, likely due to some zero-indexing error. There are multiple articles across the web discussing how developers should handle time and historical dates.
The world, according to most computers will end at 03:14:08 UTC on 19 January 2038. Why would this happen? The reason is simple enough: time would end, or would be reset, for most computers at this time. In fact, most mobile phones that exist* at the time of this writing will stop working or bug out severely immediately the clock strikes this time, no matter how well you maintain them now. Without going into too much detail, humans have identified this problem as the Year 2038 problem.
Yes, truly, time is a real issue when dealing with computers. I discovered that for myself in 2013. When starting the development of Eduplanner, I made many naïve assumptions. Disregarding the complex, but relatively smaller, issues I faced when trying to store a timeline of events that were static, but potentially infinitely recurring, I assumed I could treat time as a straight line. I was wise enough to recognize that I would have to deal with time zones, but I assumed every user of my app would be on a fixed point in the timeline, a point that is of a fixed interval away from every other user. Boy, was I wrong!
My first problem began when I started receiving crash reports from users who were located in Europe. The app crashed when they attempted to save events without an end date.
"Why can't I reproduce this crash," I fumed for weeks.
I tried to fix this in multiple ways, before correlating the crashes with users in a particular region, Europe. I then had the bright idea to change my system clock's time zone. This resulted in an immediate, unapologetic software crash.
Why did the software crash just because it thinks I'm in Europe? Well, without getting too technical**, this issue was caused because the computer was trying to compute a point in time before 00:00:00, January 1, 0001. Well, why was it trying to do that? Because the event we were trying to save in the app had no end date, I had made the app store the value for end date as 00:00:00, January 1, 0001 in local time to signify "no time set". This time is the minimum value of time that Microsoft computers can recognize. When trying to read that value, the computer attempted to convert this value to Coordinated Universal Time (UTC). Of course, if your local time were ahead of UTC, as most people in Europe and Asia are, the system would attempt to go back beyond this minimum time that it recognized and crash. Hard! According to Microsoft computers, nothing existed before the year 1 BC.
This was just one of the numerous issues I faced while developing Eduplanner. I wish I could say I've fixed all time related bugs in Eduplanner, but that would be a poor lie. Granted, I should blame myself for not carrying out proper testing on the app using different time zones, simulating daylight savings and simulating user migration between multiple time zones, but the inherent problem is with most people's assumption about the concept of time. This is a problem that lies dormant within all programmers who are yet to deal with time in software, a problem waiting to pounce and deliver misery upon the poor soul. I won't attempt to bore anyone any longer, but I should leave any adventurous developer with this warning: "Beware of time zones. Therein lies madness"
* With the possible exceptions of the newest iPhone 5S and all Windows Phones
** For the technical amongst us, the issue I faced is better explained here
However, instead of waxing philosophical about time as a concept, I have always wanted to write about the problem with our human valuation of time, especially how it affects the computers we use daily. I was inspired last year to write down my problems after I spent a dreadful 3 months fixing various bugs with one of my apps, Eduplanner, which is in essence an event scheduler. Time (the dimension, not the magazine) was the cause of all these bugs.
Readers old enough may remember the scare of the Y2K bug. There were even TV shows and songs about it. This problem arose due to the way computers stored time prior to the year 1999.
Apple, the company, has faced several issues with the software on their iPhones; from alarm clocks going off one-hour late every New Year to the system clock on the devices displaying time one hour behind after daylight savings time change. Even Google has not been exempt from the issues of time. The Android OS once had a bug that omitted "December" from the calendar app, likely due to some zero-indexing error. There are multiple articles across the web discussing how developers should handle time and historical dates.
The world, according to most computers will end at 03:14:08 UTC on 19 January 2038. Why would this happen? The reason is simple enough: time would end, or would be reset, for most computers at this time. In fact, most mobile phones that exist* at the time of this writing will stop working or bug out severely immediately the clock strikes this time, no matter how well you maintain them now. Without going into too much detail, humans have identified this problem as the Year 2038 problem.
Yes, truly, time is a real issue when dealing with computers. I discovered that for myself in 2013. When starting the development of Eduplanner, I made many naïve assumptions. Disregarding the complex, but relatively smaller, issues I faced when trying to store a timeline of events that were static, but potentially infinitely recurring, I assumed I could treat time as a straight line. I was wise enough to recognize that I would have to deal with time zones, but I assumed every user of my app would be on a fixed point in the timeline, a point that is of a fixed interval away from every other user. Boy, was I wrong!
My first problem began when I started receiving crash reports from users who were located in Europe. The app crashed when they attempted to save events without an end date.
"Why can't I reproduce this crash," I fumed for weeks.
I tried to fix this in multiple ways, before correlating the crashes with users in a particular region, Europe. I then had the bright idea to change my system clock's time zone. This resulted in an immediate, unapologetic software crash.
Why did the software crash just because it thinks I'm in Europe? Well, without getting too technical**, this issue was caused because the computer was trying to compute a point in time before 00:00:00, January 1, 0001. Well, why was it trying to do that? Because the event we were trying to save in the app had no end date, I had made the app store the value for end date as 00:00:00, January 1, 0001 in local time to signify "no time set". This time is the minimum value of time that Microsoft computers can recognize. When trying to read that value, the computer attempted to convert this value to Coordinated Universal Time (UTC). Of course, if your local time were ahead of UTC, as most people in Europe and Asia are, the system would attempt to go back beyond this minimum time that it recognized and crash. Hard! According to Microsoft computers, nothing existed before the year 1 BC.
This was just one of the numerous issues I faced while developing Eduplanner. I wish I could say I've fixed all time related bugs in Eduplanner, but that would be a poor lie. Granted, I should blame myself for not carrying out proper testing on the app using different time zones, simulating daylight savings and simulating user migration between multiple time zones, but the inherent problem is with most people's assumption about the concept of time. This is a problem that lies dormant within all programmers who are yet to deal with time in software, a problem waiting to pounce and deliver misery upon the poor soul. I won't attempt to bore anyone any longer, but I should leave any adventurous developer with this warning: "Beware of time zones. Therein lies madness"
Brilliant video from Youtube channel ComputerPhile describing the madness of time zones
* With the possible exceptions of the newest iPhone 5S and all Windows Phones
** For the technical amongst us, the issue I faced is better explained here
Wednesday, January 22, 2014
Putting thoughts down
Welcome, Internet!
I've wrestled with this decision to start a public blog for a long time. In this era of multiple social networks, where everyone has an opinion they want to share, I seldom make my thoughts or opinions public. Other than being extremely busy lately (with work and side projects), the reason for not contributing to the Internet's echo-chambers as much is because I simply felt my opinions or experiences would get drowned out by the constant, higher-quality noise that is already generated on the Internet (such an underachiever, am I not?).
Despite my self-deprecating attitude on the matter, I have decided to trudge on and create a space for thought-preservation, in a place where thought is hardly a scarce commodity.
However, I decided to share my thoughts and discoveries in hopes that it either helps someone or gives a different point of view to a particular issue.
So you, dear Internet, are stuck with me. My thoughts, forever etched into the the eternal memory of the interweb, will prevail until the collapse of our central star, the heat death of the universe or until Google closes up this website (whichever comes first). However, I would encourage you to take solace in these promises I make to you:
I've wrestled with this decision to start a public blog for a long time. In this era of multiple social networks, where everyone has an opinion they want to share, I seldom make my thoughts or opinions public. Other than being extremely busy lately (with work and side projects), the reason for not contributing to the Internet's echo-chambers as much is because I simply felt my opinions or experiences would get drowned out by the constant, higher-quality noise that is already generated on the Internet (such an underachiever, am I not?).
Despite my self-deprecating attitude on the matter, I have decided to trudge on and create a space for thought-preservation, in a place where thought is hardly a scarce commodity.
Why the change of mind?
Prior to this, I had maintained private journals for myself. I wrote into notebooks and used mobile apps for journaling. I used Evernote and Google Keep to track down my discoveries in my projects. I opined on world-issues with close friends, and maintained a private log of things I must do with my time here.However, I decided to share my thoughts and discoveries in hopes that it either helps someone or gives a different point of view to a particular issue.
So you, dear Internet, are stuck with me. My thoughts, forever etched into the the eternal memory of the interweb, will prevail until the collapse of our central star, the heat death of the universe or until Google closes up this website (whichever comes first). However, I would encourage you to take solace in these promises I make to you:
- This is a personal blog; I write for myself first. Due to this, the topic of the blog may stray from time to time, but I will focus, mostly, on technology. Not technology in the broad-sense (this is not a tech news site), but my personal musings on technology, software and programming.
- I will attempt to put up content regularly, but my more controversial or unnecessary opinions will remain in the confines of my personal journals
- I may make mistakes on some topics, but rest assured that, at the time of writing, my intentions were mostly good and I must have believed that I was being pretty smart.
- I cannot promise that there will be no curse-words, but I will attempt to keep it to a minimum.
If you are reaching this place as a soon-to-be dedicated visitor or you are a straggler who arrived here from a Google search, I hope the posts contained within provide some form of value to you as they do to me.
Again, welcome to my own corner of the internet.