Friday, October 12, 2012

Whither 3D Printers?

By:  E.S., Software Engineer @ G2

Seems as though the market is quietly bring forward more and more 3D printers; as I sit and watch I feel a real trend forming, slowly, one plastic droplet at a time ...
Its sure looking like 3D printing is here to stay, and that its just about to hit the mass market with consumer-level pricing right around the corner.
With all that creativity now possible, and new products and markets that it will create, I can't help to wonder about the security implications that will come along with it. What if it were possible to 'print' a small robot, electrical circuits and all? When you're not home your 3D printer could be hard at work doing a hacker's bidding, printing bot after bot, programmed to deliver the contents of the inside of your house to the waiting moving van the hacker has parked just outside.
How about tiny bots that can be printed without your knowledge, inside your most inner sanctum, complete with high def lens and covert wireless network connection?
Or a swarm of nanobots designed to deliver a payload into a person's body without them knowing?
I wonder what great and and sometimes terrible things humans will come up with when it comes to any technology, especially ones that merge the virtual and physical worlds ...
But for now, we get to print iPhone cases and other things made of plastic, only. Its intruguing technology even at this stage.

Mobile and Your Projects

 By:  M.K., Senior Software Engineer @ G2

I'd like to ask everyone to think about how mobile computing could be incorporated into the projects you are working on.  Ignore for the moment whether or not mobile will ever get approved for use on those projects and just focus on how mobile devices could be used.
When thinking about mobile design here are few concepts to keep in mind:
User Context - mobile devices are used in a lot of different contexts.  Users may be walking, driving, talking with friends, or doing a myriad of other tasks.  They may not be focusing 100% of their attention on the device.  Users often want to get into the system, perform 1 or 2 tasks and get out.  The focus should be on accomplishing specific tasks, not necessarily on providing every possible option to the user.
Spatial Relationships - mobile devices are not tied down to a set location like traditional PCs.  There are a plethora of spatial cues that a mobile device can use: GPS location, WiFi network, accelerometer, heading, proximity to other devices to name a few.  Which of these cues can be used to enhance your  application and provide a better user experience?
Synchronization - mobile devices are only part of the picture.  Users may be switching between different mobile devices, desktops and other platforms.  Intelligently transferring the information between platforms and enabling users to pick up and continue working between devices is an important capability.
Complimentary design - mobile devices may not be the best option to accomplish a task.  There are some situations where a certain class of mobile device may not be the best place to do something.  When designing applications to work across multiple platforms you should first focus on providing the most useful and appropriate interactions on the various devices.  There may be tasks that you choose not to enable on a mobile phone but do enable in the desktop, web, or tablet versions.  When used properly in conjunction with synchronization lack of a feature on a platform is not necessarily a shortcoming, especially if enabling that feature degrades the rest of the user experience.
The most important thing is that if we don't think about how to enable mobile interactions in our projects someone else will.  Mobile device usage is going to continue to grow, and ignoring it because we don't think it will ever be used in our projects isn't really an option. 

The 'then' and the 'now'

By:  B.Y., Software Engineer @ G2

I recently read an article that dated back to 1999 involving an interview with Ken Thompson. For those of you who don't know who he is he created the B programming language, helped develop the C language, worked on the founding UNIX development, was an avid security professional, and lead the work for distributed operating systems such as PLAN 9 (in most ways my idol). His work laid the foundation for most of what we work on today. In that article he spoke on a few key topics and I wanted to share some afterthoughts given the current state of the Computer Science field (and no I won't regurgitate the article for you).
History Repeats Itself
I find it humorous that now, 13 years later, most points in the article are still present today; at the core being that history repeats itself. This is wholely apparent in the 'cloud' push many of us are involved in. What project or solution is going to give rise again that has already been discovered? Perhaps we could use early research (circa 1980's) to glean ideas for future projects. Has technology changed enough to inflict new thought on old paradigms?
Thought Process
It seems there are two fundamental paradigms in which we, as computer scientists / software developers, think. There is the classic top-down approach and the age-old bottom up. In dealing with an end goal it seems to take a culmination of both types to wholely finish a succinct project. I can personally attest to this given a research project I'm working with Erik S., James B., and Scott W. If not for the culmination of us bottom-up thinks coupled with some crazy top-down guys, we might have missed key interleaving aspects.
Teaching the Core
As some of you may know this is one topic I'm extremely interested in. Ken wrote "I think that computer science in its middle age has become incestuous: people are trained by people who think one way. As a result, these so-called orthogonal thinkers are becoming rarer and rarer." I wholeheartedly agree and posit that this statement still stands today, if not worse. This poses an even greater challenge to those of us 'orthogonal thinkers' collecting here at G2 nowadays to get our 'crazy' voices heard of the humming noise that is complacency.
Simple is Beautiful
Ken said it best: "The aggressive use of a small number of abstractions is, I think, the direct result of a very small number of people who interact closely during the implementation. It's not a committee where everyone is trying to introduce their favorite thing. Essentially, if you have a technical argument or question, you have to sway two or three other people who are very savvy. They know what is going on, and you can't put anything over on them." This is more apparent now given the gross number of people pulling the wool over each others' eyes to get what they want. It also speaks to group dynamic and size; a fact that could be a boon for project management. Sometimes the old UNIX adage is correct, less is more.
Anyways, that is the end of my odd rant in case any of you were wondering when I would stop typing. Hope you enjoyed!

For those of you crazy enough to check my references: