Something new, for me at least, came across my desk yesterday. QR codes. I've seen them and used them, but haven't really ever taken the time to learn more than that. Well, now I will have an opportunity to learn about the other side of the QR puzzle.
My work has several different displays of art that are available for patrons to view as they await their planes. The idea is to present these QR codes by the artworks to give the visitors detailed information about the piece and its author.
As I've been doing research regarding these codes, I believe that we'll be able to use them for much more. As an airport, we technically are considered a shopping mall, albeit with a little extra security. All of our tenants have different products and needs. With the usage of these codes, we can create a loyalty type program that our tenants can opt into and have the ability to offer passengers discounts, detailed information on their products or coupons.
I'm not yet sure where we'll truly be going with this, but it'll sure be an interesting journey. I'm looking forward to it, and as I learn more and figure out more about what we will do with these, I'll write more about it. Till then, happy reading!
Thursday, September 15, 2011
Wednesday, September 14, 2011
Virtualization in an Airport
Every day in my (mostly) new job, I see more ways and needs for virtualization. Working within an airport environment, I deal with hundreds of displays for flight information, gates, advertising and so on. All of these do make and have made excellent virtual desktop candidates.
As I learn more about the aviation environment, I'm beginning to see even more areas where we can test and use virtualization. There does tend to be one barrier that we encounter more often than not: vendors who either don't understand or who don't want to understand and move to a virtual world. Many of these possible virtual candidates range from baggage handling to ticketing to central energy plant machines. However, when you mention virtual to many of these system designers they either say, "What's that?", tell you, "We think it can be but we don't really know", or just flat out say, "No, we don't do virtual." Frustrating to say the least.
So, what am I doing about it? Well, for starters, my basic philosophy has always been, nothing is off the table until it can be proven that it won't work. Simple. Let's try it out, either with the vendor or in spite of the vendor (take care here--you don't want to upset the vendor). So, for the vendors who say they don't do virtual, we set up a test environment and test within the IT group first. Next, we do a limited end user roll out--for an extended period. This can be 3-4 months or more. Finally, we'll get the vendor involved and ask them to come in and see what we've done, and hopefully get their blessing. If we get the blessing, we'll do a full roll out. If we don't, we'll discuss with other management and talk to the vendors more to judge what type of support we can expect if we should continue to roll out the virtualization anyway.
Some may say that 3-4 months isn't that much of an extended period to test. Others may say that it's too long. We don't have a set amount of time for these end user tests. We let the results guide us. If something works, we stick with it and ask the user to push it more, preferably until it breaks.And, we do this more than once to make sure it wasn't an accident or something else that broke it. By doing this, we get a better understanding of what we truly can and cannot do.
If something doesn't work, we step back and try to determine what the cause may be and how to fix it. Sometimes this means stripping out pieces of the OS that aren't needed to make a leaner running machine. Other times it means adjusting the resources available to the machine, such as CPU and memory. Then there are the actual applications running on the machine. How are they being used? Is this the standard way to use it? Can we modify the user behavior slightly to help make it work without the user being inconvenienced? As I said earlier, nothing is off the table until we have shown it can't and won't work.
As I write this today, we are currently testing the limits of our VMWare infrastructure with a couple of our systems. We're testing a video solution that is currently setup to stream 14 live feeds to its video viewer and alarm monitoring software all the while driving two monitors. Another item we're testing is the ability to run a software package provided by our LCD screen manufacturer that will allow us to communicate with these screens via the DVI cable and turn the screens off and on (energy savings and screen life extension!). Both of these are things that most people would say that virtualization isn't a good candidate for. But hey, unlessI see it not work for my self, it can be done.
As I learn more about the aviation environment, I'm beginning to see even more areas where we can test and use virtualization. There does tend to be one barrier that we encounter more often than not: vendors who either don't understand or who don't want to understand and move to a virtual world. Many of these possible virtual candidates range from baggage handling to ticketing to central energy plant machines. However, when you mention virtual to many of these system designers they either say, "What's that?", tell you, "We think it can be but we don't really know", or just flat out say, "No, we don't do virtual." Frustrating to say the least.
So, what am I doing about it? Well, for starters, my basic philosophy has always been, nothing is off the table until it can be proven that it won't work. Simple. Let's try it out, either with the vendor or in spite of the vendor (take care here--you don't want to upset the vendor). So, for the vendors who say they don't do virtual, we set up a test environment and test within the IT group first. Next, we do a limited end user roll out--for an extended period. This can be 3-4 months or more. Finally, we'll get the vendor involved and ask them to come in and see what we've done, and hopefully get their blessing. If we get the blessing, we'll do a full roll out. If we don't, we'll discuss with other management and talk to the vendors more to judge what type of support we can expect if we should continue to roll out the virtualization anyway.
Some may say that 3-4 months isn't that much of an extended period to test. Others may say that it's too long. We don't have a set amount of time for these end user tests. We let the results guide us. If something works, we stick with it and ask the user to push it more, preferably until it breaks.And, we do this more than once to make sure it wasn't an accident or something else that broke it. By doing this, we get a better understanding of what we truly can and cannot do.
If something doesn't work, we step back and try to determine what the cause may be and how to fix it. Sometimes this means stripping out pieces of the OS that aren't needed to make a leaner running machine. Other times it means adjusting the resources available to the machine, such as CPU and memory. Then there are the actual applications running on the machine. How are they being used? Is this the standard way to use it? Can we modify the user behavior slightly to help make it work without the user being inconvenienced? As I said earlier, nothing is off the table until we have shown it can't and won't work.
As I write this today, we are currently testing the limits of our VMWare infrastructure with a couple of our systems. We're testing a video solution that is currently setup to stream 14 live feeds to its video viewer and alarm monitoring software all the while driving two monitors. Another item we're testing is the ability to run a software package provided by our LCD screen manufacturer that will allow us to communicate with these screens via the DVI cable and turn the screens off and on (energy savings and screen life extension!). Both of these are things that most people would say that virtualization isn't a good candidate for. But hey, unlessI see it not work for my self, it can be done.
Thursday, February 3, 2011
iPhone App Review: ToonPAINT
The basic premise behind ToonPAINT is to take a photograph, either from your Photo Library on your iPhone (or iPod Touch), or from a new snapshot taken from within the ToonPAINT app and create a cartoon-like image of your picture. Once you have a photo loaded, ToonPAINT does it's magic.
After it's initial rendering of your photo, you can set about tweaking the details to your heart's content. There are two main settings that allow you to control what the final output of your photo will be, "basic" and "advanced" modes. Basic mode gives you 3 main options for You can control what ToonPAINT calls "coherence". In other words, how much the image is distorted from it's original look. The size of the value chosen determines how comprehensible the final product is. You can also control what they call edge length, which determines how all of the lines in the photo are connected to each other. I played around with the different combinations and came up with many different looks for the same photo.
Once you create the base look of the photo that you want, you can then add color to the picture using the color "splats". I found adding color to be somewhat tedious at times. It was difficult to precisely add color to small areas of the photographs, even when I had zoomed in as far as I could. This aside, I was still able to add color to the photos and the imprecision did not bother me as much once I had zoomed out to the original size.
Overall, this is a fun app to play with, and at $1.99 the power of this app makes this a steal.
ToonPAINT is an iPhone app by Toon-FX LCC.
Subscribe to:
Posts (Atom)