Parametric Holiday Greetings from Coldwell Banker, Townside, Realtors

Parametric holiday greetings from Coldwell Banker, Townside, REALTORS(R)

Seasons greetings and best wishes for a wonderful 2013 from Coldwell Banker Townside, REALTORS and Handshake 2.0!

The original Parametric Tree was created using Wolfram's Mathematica by Alex Edelman and appeared on Handshake 2.0 in 2009.  In 2010, Kelsey Sarles decorated the tree for the holidays. We enjoy it each year and hope you do, too! 

You're invited to view all the parametric images on Handshake 2.0.

Blacksburg, Christiansburg, Roanoke, and Salem, Virginia real estate and homes Coldwell Banker Townside specializes in in Blacksburg, Christiansburg, Roanoke, and Salem, Virginia real estate and homes and national and global relocation services to the Blacksburg, Virginia and Roanoke, Virginia areas. You're invited to check out the CBT blog, Keepin' It Real Estate, visit Coldwell Banker Townside, REALTORS (R) on Facebook, and see more of Coldwell Banker Townside on Handshake 2.0.

Download the Coldwell Banker Townside App in the iTunes App Store or in Google Play.

Coldwell Banker Townside REALTORS is a client of Handshake Media, Incorporated, the parent company of Handshake 2.0.

Cloud Computing Infographics

Cloud Computing

Cloud Computing
e cloud allocates just enough computing power
for you to do what you want to do.


Cloud computing: cloud hosting 

Cloud Hosting
Hosting in the cloud gives you more power for heavy traffic
and lower costs for light traffic, all dynamically adjusted.


A vision of Software-as-a-Service, SaaS, from Handshake 2.0

Instead of running on your computer, Software-as-Service (SaaS)
applications run in the cloud, taking instructions from your computer,
then sending the results as output to your computer.
What you wanted to do is done.

Cloud computing infographics concept by Alex Edelman, design by Kelsey Sarles.

These infographics originally appeared on Handshake 2.0 in Cloud Computing – Just Draw Me a Picture.

Testing iOS Apps with TestFlight

From Alex Edelman:

After a long app development cycle, it's generally wise to do a few rounds of testing before releasing an app to the public. In the case of iOS apps, the distribution options Apple provides leave something to be desired: Ad Hoc distribution is suitable for testing, but it requires a modicum of technical ability beyond the App Store-based installation process that iOS users are accustomed to.

As we were developing mobile apps here at Handshake, we stumbled upon TestFlight, a service that makes app distribution for testing simpler for developers and testers. Here's what you'll need to use it:

Now it's time to go into TestFlight and send out invitations by email or link from the Team Management page. Your testers will be invited to create accounts in TestFlight and download the TestFlight app to their devices, and the Team Management page will keep you updated about their statuses. The Team Management page will also show you the Device IDs for the iPhones and iPods your testers are using. These are important for the next step. (You can also collect these by hand from your testers as described here.)

Now you can log in to the Devices section of the iOS Provisioning Portal and add your testers' devices with creative labels and the Device IDs you found previously. (You can have at most 100.) Next, move to the Provisioning Profiles section to add a provisioning profile for your app or edit the one you already have. You'll want to add to that profile all the devices you want to allow to test. Download that provisioning profile.

Now you can build your app. Whether you're using XCode or Titanium, you'll want to build it for Ad Hoc distribution. Once it builds, your app will show up in the Xcode Organizer. Select it, click Share, select the provisioning profile you downloaded in the previous step from the popup menu, and click Save to Disk. Then simply go to the builds section of TestFlight and upload the archive file you just created. TestFlight will automatically match the users allowed by the provisioning profile in your app with the users in your TestFlight team, and offer to send emails informing your testers of the new build.

That's it! Your testers will be able to install the build by clicking a link emailed to their iOS devices or by launching the TestFlight app, and you'll get to sit back – until the bug reports start to roll in.

TestFlight screenshot for Foto Puzzler

Screenshot from testing of Foto Puzzler through TestFlight

Alex Edelman is the developer of the Handshake(R) line of mobile applications from Handshake Media, Incorporated.  He is Chief Technology Officer at Handshake and a co-founder of She Chooses.

Parametric Easter Egg

We're glad to share again one of our favorite parametric images, first appearing on Handshake 2.0 in April of 2009:  an egg-colored ellipsoid, with three parametric sine functions wrapping around it at various points.

Handshake 2.0's Parametric Egg

For the math behind Handshake 2.0's Parametric Egg, feel free to read this .pdf.

Alex Edelman is the author of Parametric Hand Turkey, Parametric Valentine, Parametric Shamrock and Handshake 2.0's parametric images, all created using Mathematica.   Alex Edelman's parametric creations have been listed on Wolfram Research News & Events.

Parametric Present

From Alex Edelman:

This year's parametric holiday present comes wrapped in Mathematica's Cuboid and Line graphics primitives. The bow is the more interesting Lorenz attractor, a particularly neat-looking solution to the differential equations governing the Lorenz oscillator. You can download the Mathematica notebook that generated this image here. (If you don't have Mathematica, Mathematica Player should let you see what's going on.)

Parametric Present

The Parametric Present was created using Wolfram's Mathematica by Alex Edelman. You're invited to view all the parametric images on Handshake 2.0.

Parametric Hand Turkey

This classic post from Alex Edelman originally appeared on Handshake 2.0 in 2008.

The quintessential childhood Thanksgiving arts-and-crafts project is the hand turkey, so I decided to make one. Unfortunately, a rigorous scientific education has enabled me to suck all the fun and child-like innocence out of any enterprise, so I ended up making a graph.

The graph in question is of a parametric equation. Whereas the graphs we are most familiar with give one variable as a function of another (y in terms of x, for instance), a parametric graph gives x and y in terms of another, or in our case, two other variables. I've parameterized in terms of r and t.

Equations and conditions that give us our parametric hand turkey 

Equations and conditions that give us our parametric hand turkey 

Equations and conditions that give us our parametric hand turkey 

Equations and conditions that give us our parametric hand turkey 

Wolfram Mathematica input statement that graphs the equations and conditions to create a parametric hand turkey

The parameterization, in terms of t, graphs the "shape" or "outline" of our mathematical hand turkey. It's a modification of a polar function that would normally give us a "rose" with nine petals. My fingers are not all the same size, though, so I tweaked the function with a square root of t to vary the petals a little bit. A few more changes gave me five "fingers."

A picture of the graph, as generated by Mathematica


Then, I multiplied by my second parameter, r. Since it ranges from 0 to 1, then for every possible value of r, the "t" function it is affecting will be drawn with a slightly different radius. When we put all these functions on top of each other, we get a continuous series of "outlines" which smoothly merge into a solid region.

Not entirely devoid of childlike aesthetic taste, I then used Mathematica to graph the function and, more importantly, apply a gradient of "Thanksgiving colors" to it.

All in all, though, you're still probably better off asking your kid to make a hand turkey.


If you're interested here's a high-resolution .pdf of the Mathematica notebook. It's big (8559K), and requires a little crunching from your computer, but the image it produces is gorgeous.

And for the sake of complete documentation, here's the original Mathematica notebook, in case readers of Handshake 2.0 use Mathematica.

API – Just Draw Me a Picture

Everybody and their mother seems to have an API nowadays. What does that mean?

The application programming interface, or API, is a general and ubiquitous concept that tackles the problem of abstraction. Computers programs are, most fundamentally, chunks of binary code that correspond to a few simple instructions (e.g. add these values and put them in this memory location) that the computer steps through and executes. Programming at such a low level is generally long, boring and repetitive.

We would prefer to programmatically manipulate data structures in much the same way that we talk about the objects we're representing: I want to type ball = sphere (radius=1, (valid VPython code) and see a red ball without ever worrying about how the computer goes about creating it.

An API is a set of high-level behaviors that a programmer can use without programming the underlying operations. In scientific computing, for example, I often want to manipulate vectors, and instead of writing the code to do so by hand, I can use the linear algebra API BLAS. (An API is technically distinct from the API's implementation. The former is just the high-level behavior defined, while the latter is the code that actually runs when a programmer uses the API. BLAS is only one set of operations, but many codes implement it.)

How does an API work? Just draw me a picture.

Today's web APIs certainly make programming at a high level of abstraction easy (I can ask Facebook for a nicely-formatted, human-readable object representing a user's profile in one line of code), but they serve a second, crucial purpose: making the web more connected. Without APIs, apps are restricted to point-and-click interactions with real people using browsers (or programs that pretend to be people). APIs allow all parts of the modern ecosystem to talk to each other seamlessly.


Alex Edelman is Chief Technology Officer of Handshake Media, Incorporated.

The Cloud I Want

Handshake 2.0 Takes on The Cloud

 From Alex Edelman:

A lot of people have started talking about "the cloud" recently. I joined the conversation in Welcome to The Cloud.

I can see why a lot of people are excited. More and more of the applications we use every day to create and communicate are available online, accessible from anywhere. And small businesses (larger ones, too) can now quit worrying about IT altogether by putting their data in the cloud.
But I'm not a small business owner and, as for web apps, I'll admit to eagerly trying every new Google experiment, but realistically, I've been using webmail since sixth grade. Why get excited now?


The computer owner's machine still does most of the computing.
Here's an
annotated version of this screenshot.

When I think about cloud computing, I emphasize the computing. The cloud hasn't arrived for me yet because my own computer still does the vast majority of my computing. And I suspect that when I buy my next computer, I'll be thinking about its processor, disk, and graphics card as much as when I bought my last one.

I'm writing this in a text editor running on my machine, listening to music from iTunes running on my machine, looking at a PDF open on my machine, logged in to chat services through client programs that run on my machine. Today at work, I used the copy of MATLAB on my machine to crunch through microscope images from a USB drive – no cloud there – and turned them into a PowerPoint presentation on my machine.

The clouds I use are convenient but not essential. I love Gmail, but Carnegie Mellon - where I'm a student – does email, too. I could easily download my RSS feeds and read them locally. I could host webpages and share files by setting up an old computer in a closet somewhere. And so on.
But I don't like the world this way. I think the present arrangement gives us a problem of inefficient computation.

The computer I'm using now is eight times as fast as the one I was using eight years ago. That power is useful: I hear my fans whirring as my computer fills up the extra RAM I installed a few weeks ago and smashes through some monstrous calculations (such as to create a parametric hand turkey).  The only problem is that this happens a few times a week, maybe. Right now, my system monitoring widget tells me that my processor is 89% idle, and it stays that way for most of my daily tasks. At night, I close my laptop, and its power is completely unused for (ideally) eight hours.
Meanwhile, biologists need to simulate complex proteins folding, cryptographers need to run data through mind-boggling ciphers, and physicists need to crunch through the equations of lattice quantum chromodynamics. Oh, and somebody's trying to check email and cursing the busy server.
And here's another problem. If I ranked parts of my world in order of importance, my computer would probably be somewhere on par with oxygen. In the past year (at least), I have used it every single day. So naturally, I want to take it with me. So naturally, I want it to be thin and light and portable. I'm a college student, so naturally I want it to be cheap. So far so good. Except I also want a computer that's really good at, well, computing. I suspect that many others share my preferences.  That inevitably leads to difficulty in finding the right balance between a wimpy netbook and a gargantuan desktop replacement laptop.
I've whined enough, so let me tell you my scenario of a good, near future.

The computing device I carry around consists of a persistent wireless Internet connection and a screen. I chose this device based entirely on screen size. My entrepreneurial friends, used to their Crackberries of years past, opt for little three-inch devices, while those who majored in design prefer 30-inch tablets. (They're not as big as they sound, since their organic LED screens allow them to roll up like posters.) It really doesn't matter, though, since we can do anything we want to – anything that's possible on a cluster of untold thousands of processors operating on the scale of exaFLOPS. Whenever I flip out my device to check email, the cloud – for this really is a cloud – allocates a few processor cycles to my trivial task, sends me the information, then goes back to curing cancer.
That's the cloud I want.


Alexander Edelman studies physics at Carnegie Mellon University and is the Chief Technology Officer of Handshake Media, Incorporated.


We're compiling links to Handshake 2.0's cloud computing series here.

Welcome to The Cloud – In the Beginning Was The Cloud, But We Called It a Server

Handshake 2.0 Takes on The Cloud This is the first entry in our series, Handshake 2.0 Takes on The Cloud:  What do we need to know about The Cloud in order to serve our companies, our customers, and the greater good?

 From Alex Edelman:

These days, people all seem to have their heads in "the cloud" and, as is usually the case with such tech buzzwords, by now the term is so popularized that it's difficult to extract its meaning.

SaaS, cloud computing, The Cloud - this story has it all. "Cloud computing" is a particularly pernicious case because, even before being fogged over by the sudden flood of public attention, it embodies so many different components. I can't provide a single definition. (If I did, it would either be useless or inaccurate.) Instead, I'm going to tell you a story.

The Story Begins
Let's say you have a computer. Now this is pretty exciting. You can perform so many calculations per second! And you're a forward-looking type who realizes that these are useful for more than number-crunching: you can do word processing and record-keeping, and one day, when these things get fast enough, maybe even look at pictures! Your friends are jealous, so they get computers, too. Now you can all do really cool things, and soon you realize that you want to share them with each other. So you figure out how to hook all your computers together, and now you have a network.
This network is pretty nifty. You can send messages to each other. You can share files. Life is good. But you begin to notice a few problems. You realize that if you want to access a friend's files, your friend's computer has to be on. Ditto if you want to send a message. Likewise, your computer can't interact with your friends' computers unless it's on. You keep some pretty strange hours, so this arrangement is unacceptable.
So you and your friends get together and buy another computer – slightly bigger and faster than the others. You designate it the central node of your network. You decide that this computer is going to stay on all day, be responsible for hosting shared files, and distribute messages to its clients. Now, whenever you want to interact with any of the members of your network, you pipe your request through this central computer.
At this stage, you wonder what you should call it. The term "cloud" seems appropriate – the structure you've created seems to hover over your entire network – but you get the vague feeling that years from now, technologically inclined people would scoff at the comparison between your humble arrangement and the towering, billowing water droplets that bridge the sky. So you shelve the thought and call it a "server."

More People Like the Story
It turns out that you're not the only one who's had these ideas. Lots of people have formed networks by now, and one day you decide that it would be really nifty to link these networks together. So you spend a while writing protocols for communication, standardize things like "hypertext" and "email," and soon you have the Internet.
This Internet really catches on. You're busy with your wife, two-and-a-half children, golden retriever, and new small business, but you notice that some computer types have done some really cool things online. For instance, those guys over in Mountain View, CA have a really nifty way of reading email.

Now that all the small networks are connected, you realize there's really no reason to get your communication fix from your own server, especially when these other guys do the job so much better. So you switch over to them. This is really seeming very cloud-like, but you remember that it's just a bunch of guys with better servers in another place and keep your mouth shut.
Actually, as time goes by, a whole bunch of people get really good at this networked computer thing. You realize that staying on the cutting edge is expensive and difficult, and the services these people offer are so slick! Gradually, you shift more and more of your crucial tasks over to them: your calendar, your address book, your shared documents (and your private documents), your large file storage, your website, all go into the cloud – sorry, into the servers –  of companies that have dedicated themselves to the task.

Sure, you realize, you could put up servers and do it yourself, but what makes these companies better is the software they provide, which streamlines all your essential tasks, makes them enjoyable, even. Really, for the software they provide as a service, you use their servers, not yours(Hence, Software-as-a-Service, SaaS.)

Not the End of the Story
And that's the whole story. Up until very recently, at least. You see, there's one more twist. Until now, no matter how much of your data has been in the cloud, you've still been doing stuff with your data on your own machine. But the final piece of the puzzle – the really exciting bit – is computing in the cloud.
Human computer usage is naturally "bursty." (This is a real computer science term. I kid you not.) You spend a few minutes clicking around a website intensely, and then you go somewhere else. Your awesome fireworks simulator gets a lot of traffic in early July and late December, but very little for the rest of the year. Your United States-based customers are asleep and away from your website for about the same chunk of time every day (unless they're college students).
And yet, if you want to get the best computing experience, you need to buy a machine that will perform well at the most computationally intense tasks – and then sit idle. And yet, if you want to provide the best experience for your clients, you need to buy equipment that will maintain high performance during the greatest bursts – and then sit idle.
Cloud computing lets you shift the burden to a third party. Processing power itself is now provided as a service. You use and pay for only what you need. Isn't that so simple and elegant?

We Won't Notice the End of the Story
Let's return to defining The Cloud, then. Now that we've run the gamut from a simple server to fully outsourced electronic labor, when, exactly, can we call it a cloud?

We won't care what it's called or when.  We'll be back – ahead, really – to doing really cool things and sharing them with our friends.


Alexander Edelman studies physics at Carnegie Mellon University and is the Chief Technology Officer of Handshake Media, Incorporated.

Graphics by Kelsey Jade Sarles.


We're compiling links to Handshake 2.0's cloud computing series here.