whymenu
A short while ago I read a DZone article that reminded me of some things developers should try to do on a regular basis. In addition to staying current (or trying to do so) with all that's going on in our fun and fast-paced field, we should give something back.
If you grew up in an open-source environment neither of these are foreign concepts to you. I don't mean to imply that these are not priorities of yours if you live on the proprietary side of the street but it has been my experience that it may be less likely. (There is a corollary in there somewhere about folks who are using open-source stuff but not buying into the concept.)
On the staying current front, I have experimented with a variety of the PaaS offerings for some time now. These include Google App Engine, CloudFoundry, AppFog, EC2, JElastic, and at least a couple more that don't come to mind at the moment. Depending on how much time I have, I try to write something a good bit beyond a "Hello World" application while respecting what I perceive to be the advertised strength of the service.
OpenShift is the latest one I find to be a serious contender. The idea that I can have my source code in a git repository and do a push to initiate a deployment is pretty sweet. If you happen to work in a shop where you are totally insulated from this process by design, it's probably less impressive. On the other hand if in addition to development, you have, on occasion, built a virtual environment from bare metal up, you're more likely to say "wow" to Red Hat's creation.
I don't mean to imply that OpenShift is the only game in town for me, but I do rank them very high. Time will show us how serious they are about providing service for real-world applications.
Having introduced my perspective a bit, the short story of whymenu goes like this. After reading the above article I wondered what I might create that friends might actually use and challenge me to try out one or more new (to me) technologies. whymenu is a solution which allows a restaurateur the opportunity to create and maintain a smartphone or tablet accessible menu using a Google Spreadsheet. Given all the Google technology, it would not surprise me to know this is not a unique idea or creation but it was new to me and seemed to fit within my goals and limited time availability.
In general I am not against client-side stuff (JavaScript and friends) but I do tend to prefer static typed languages. I don't necessarily come at this from a "I am worried about what might happen at runtime" perspective. The fact is I believe that should always be a concern. Certainly best practices, development tools, and the language are factors here but I tend to think about the actual development process. I think I can be a more productive coder when I am comfortable that my development environment is keeping me from doing dumb things. There is a fine point here: I am not talking about the extent to which the intelligence of the development properly and completely analyzes code as I am writing it. I am referring to how much my mind does or does not wander due to my perception of that functionality.
My confidence level has increased a bit recently given examples such as NetBeans 7.3 and JavaScript and the Dart language and associated Editor (not currently referred to as an "IDE" by Google). In addition, Visual Studio, Intellij, and Eclipse continue to push this same envelope. Competition is indeed a good thing.
Having said all that I thought I might build parts of whymenu functionality using Java, JSF, PrimeFaces, Dart, JavaScript, HTML5, jQuery, jQuery Mobile, Polymer, and AngularJS. OK so this was not at the beginning and certainly not simultaneous. whymenu is not a complicated application which is why I was able to rewrite it three times using combinations of these technologies. Most of them are technologies I have never used in a production application or it's been a good while since I did so.
If you have a chance, check out whymenu and let me know what you think. Chances are I will rewrite some or all of it again for comparison purposes so a user or two would be a good thing.
Happy coding,
Carl
If you grew up in an open-source environment neither of these are foreign concepts to you. I don't mean to imply that these are not priorities of yours if you live on the proprietary side of the street but it has been my experience that it may be less likely. (There is a corollary in there somewhere about folks who are using open-source stuff but not buying into the concept.)
On the staying current front, I have experimented with a variety of the PaaS offerings for some time now. These include Google App Engine, CloudFoundry, AppFog, EC2, JElastic, and at least a couple more that don't come to mind at the moment. Depending on how much time I have, I try to write something a good bit beyond a "Hello World" application while respecting what I perceive to be the advertised strength of the service.
OpenShift is the latest one I find to be a serious contender. The idea that I can have my source code in a git repository and do a push to initiate a deployment is pretty sweet. If you happen to work in a shop where you are totally insulated from this process by design, it's probably less impressive. On the other hand if in addition to development, you have, on occasion, built a virtual environment from bare metal up, you're more likely to say "wow" to Red Hat's creation.
I don't mean to imply that OpenShift is the only game in town for me, but I do rank them very high. Time will show us how serious they are about providing service for real-world applications.
Having introduced my perspective a bit, the short story of whymenu goes like this. After reading the above article I wondered what I might create that friends might actually use and challenge me to try out one or more new (to me) technologies. whymenu is a solution which allows a restaurateur the opportunity to create and maintain a smartphone or tablet accessible menu using a Google Spreadsheet. Given all the Google technology, it would not surprise me to know this is not a unique idea or creation but it was new to me and seemed to fit within my goals and limited time availability.
In general I am not against client-side stuff (JavaScript and friends) but I do tend to prefer static typed languages. I don't necessarily come at this from a "I am worried about what might happen at runtime" perspective. The fact is I believe that should always be a concern. Certainly best practices, development tools, and the language are factors here but I tend to think about the actual development process. I think I can be a more productive coder when I am comfortable that my development environment is keeping me from doing dumb things. There is a fine point here: I am not talking about the extent to which the intelligence of the development properly and completely analyzes code as I am writing it. I am referring to how much my mind does or does not wander due to my perception of that functionality.
My confidence level has increased a bit recently given examples such as NetBeans 7.3 and JavaScript and the Dart language and associated Editor (not currently referred to as an "IDE" by Google). In addition, Visual Studio, Intellij, and Eclipse continue to push this same envelope. Competition is indeed a good thing.
Having said all that I thought I might build parts of whymenu functionality using Java, JSF, PrimeFaces, Dart, JavaScript, HTML5, jQuery, jQuery Mobile, Polymer, and AngularJS. OK so this was not at the beginning and certainly not simultaneous. whymenu is not a complicated application which is why I was able to rewrite it three times using combinations of these technologies. Most of them are technologies I have never used in a production application or it's been a good while since I did so.
If you have a chance, check out whymenu and let me know what you think. Chances are I will rewrite some or all of it again for comparison purposes so a user or two would be a good thing.
Happy coding,
Carl
Comments