Friday, December 31, 2010

Using Hamachi for Remote Desktop Sharing

I, or more correctly one of my clients has used GoToMyPC before to share their PCs for support purposes. I am not in the PC support business so it isn't something I care too much about, but sometimes I do get curious about alternatives.

One alternative is LogMeIn. Definitely lower cost. If you are a gamer or non-profit, some of their products and services are provided without fees. That's actually something a few people and organizations I know of would benefit from.

The first free thing is the LogMeIn Free service. Even the Pro version is not at all pricey. LogMeIn Free gives you most of the interesting things of GoToMyPC, without the cost. If you still need to share files, you can always use DropBox or one of the other fine sharing services.

The second free thing is what would appeal to hobbyists, gamers, and some non-profit IT types: the Hamachi Virtual Private Network.  You download a little pop-up utility that lets you connect to another computer also running Hamachi, or host a connection.  They call it "mesh" network, but it is basically peer-to-peer networking.

One neat thing about Hamachi is that you can also use it to tunnel Windows Remote Desktop Connections or VNC connections. Create a network on one of the Hamachi clients and connect to it on the other client. After that you can use any RDC client to connect to a Microsoft Windows PC or VNC to connect to a Linux, Mac, or PC client, using the IP address that Hamachi shows in its pop-up.


Don't forget to grant access to Hamachi in your software firewall and through your router's firewall. Also, Windows users will have to enable RDC sharing and set a password for it in their control panel. 


 As I write this, I'm connected through Hamachi to my Lenovo T61, and running RDC to access the Windows desktop. It is on my local LAN, so performance is not representative, but it is neat that it can be done, effectively making it unnecessary to use LogMeIn or GoToMyPC at all for non-commercial purposes.

Wednesday, December 29, 2010

Classes and Inheritance in Javascript

Here is some news for Javascript monkeys: Javascript does not have classes. None. Nada. When people speak of OOP classes and Javascript, they are making it up, literally.

Any talk of OOP classes in Javascript code is a pretense. Now, some of that code is really ingenious, really nifty stuff. But there are no first-class classes in Javascript.

There are two consequence of these non-first-class constructions:

  1. Core language primitives were designed before the faked constructs existed and although the core language retains its closure (as much as before the extensions), the faked constructs introduce new elements and relationships that are not necessarily conserved through the primitive operations. 
  2. The extended constructs do not necessarily meet the same algebraic axioms; the library may not entirely consistent within itself. 
A typical case is the use of JSON to send around objects which use library-based inheritance frameworks. It is easy to reconstruct the property sets, but difficult to ensure that the invariants assumed by your class framework remain invariant after a round trip.

Monday, December 27, 2010

Another birthday past

I turned 47 today. It wasn't the birthday I might have hoped for, but it doesn't seem like I could have expected much more.

The weather was rough this week-end, but the roads were mostly clear and I planned on going in for a half day at least. My son wanted me to drop him off at a buddy's house, which meant he wouldn't be home. His mom asked me, obliquely, if I had wanted to drive her to work, to which I replied not really and made an unwise remark about what a wise aleck she was being. She called me a jerk, and left a bit later. On my drive out my son wished me a happy birthday, which was poignant. So that was how my day started.

I went in to work for the morning. Nothing special, just some debugging to figure out why someone else's home-brewed JSON parser wasn't actually doing the right thing by failing to properly initialize Prototype.js object's base classes. I figured it out but it didn't get fixed. It is not my place to set that priority as yet, but still -- it is the difference between doing the right thing and making things work for right now, that can bite you later when you are no longer looking. Deserialized objects should always be constructed the same way any other instances of classes are; anything else is a proximity fuse code mine.  So that was the second part of the day.

Plans to have lunch with a friend were interrupted at the last minute due to fear of the previous weekend's weather. I don't blame my friend, but it was unexpected and I was looking forward to having a good conversation.  Instead, I spent much of the rest of the day alone. I took a late lunch out and chatted with the restaurant owner, but it wasn't the same. I read up on Hobo and got a Jasmine gem to install properly, and looked over how JSON should (really) deserialize... finding that people don't seem to do it right at all in most cases, at least not with respect to higher-order class/inheritance constructions implemented at the Javascript library level. It continues to amaze me that people do mud-pie programming in Javascript and pretend that there is rigor and soundness to what they are doing. So that was the third part.

Checking messages, a few people wished me a happy birthday. My mom, her sister, and my sister called to say the same. That's nice. Not unimportant, but they all seem so... distant. Well, they are distant, but we don't really have much in the way of enriching conversation going on either.

Later, my wife got home early, and needed to vent about the goings on at her place of employment. Lots of dishonest communication in the workplace, compounded by a general lack of integrity, unrealistic goals, and hidden agendas, make it pretty rough for people to have a satisfying workplace life. When management and practitioners accept false premises for arguments, the fallacies inevitably compound and accumulate like waves cresting and crashing back upon a beach. It wears you down personally, and slowly undermines whatever solid thing you do manage to build. I got to hear about it, and offer consolation and comfort.

She got me a present too, a ceramic grinder because I grind nut mixes. Nice thought, but it was from the local mall and, as it happened, gummed up within about a minute. OK for fat-free things maybe, but not nuts and cocoa beans. I spent the next hour cleaning it out carefully before re-wrapping it for a return. I thanked her for it, but given the price (over $60) it did not seem like a keeper.

She put the TV on. I've come to hate TV. It isn't my choice of spending any evening, let alone my own birthday. It is icy out now, the roads are dangerous, so there is no going out. I lay down on a love seat in the other room to reflect on the day.

She puts the dog out and goes to bed early, not saying much otherwise. She doesn't seem to be angry or bothered in any way, just indifferent. Sigh.

I wonder how to improve upon what seems like a completely hideously unsatisfying social life. I mean, seriously - being alone all day???  It isn't reasonable. It isn't healthy. It just isn't right.

Blogging about it seems like a good enough idea, at least to help me reflect.  I wrote once before about analogies in fiction, how there are often disturbingly concrete mappings to reality. Today was a day in the life of Robinson Crusoe. I tilled the soil, planted corn, minded my traps, said my prayers, and spent the balance of my time thinking about what else I could do to improve my situation and do more than merely survive in isolation.

Normally that would be enough, but today was sad and lonely, and here at the end of the day I'm just glad to say it is over.
And I have seen that there is nothing better than that man rejoice in his works, for it is his portion; for who doth bring him in to look on that which is after him?

- Ecc. 3:22

Saturday, December 25, 2010

Christmas Spirit

Standing in the doorway, early snowflakes 
falling gently down. A quiet violence lights
the nighttime sky. Our darkness was long ago
stolen by the kings of business and commerce.

Their light could not illuminate, only confuse and irritate. 

Meltwaters dripping slowly from the eaves. 
The TV fades into the distance, no video 
succubus to steal the soul of our conversation.  
No conversation left to be had. Just drips
of ice water punctuating the silence.

Friday, December 24, 2010

Storage without the GitHub price

So, I'm looking at GitHub and thinking, "It's a great service, but what are the other options?" Their micro plans are a very good value at $84 (USD) to $264 per year, but I just purchased a 1 terabyte LaCie NAS for about $150, and I'm already paying about $60 per month for broadband access to my (home) office. Would self-hosting my own space make sense?

The main disadvantage of using an office-based solution, in two words, is "lightning strikes". Most office equipment is exposed to higher risks of electrical surges or direct strikes, especially when it is located in a residential building. Forget about what uninterruptible power supply companies and line filter vendors will tell you -- if lightning strikes any utility connected to your home, chances are good that their equipment will be the first, but not the last, to be taken out. Lightning can travel miles through air, so a 1/4 inch spark gap isn't going to be much protection.

And computer years are logarithmic, especially the consumer-grade stuff most of us use at home offices. A lot of equipment is just going to fail after a couple of years. At three years, odds are much better for failure. At five years, even if it is still running your equipment will appear to have been purchased eons ago and you'll wish it would fail. I don't look at my LaCie NAS so much as an investment, as a necessary expense for the sake of quickly restoring my MacBook Pro. It just does not pay back to deploy mission critical services on an ad-hoc platform.

Especially if it is your mission, you'll put in way too much time to fix and maintain the platform. It is certainly fun to hack devices to get, eg, git running on a NAS device, but unless you are using that knowledge to build a salable infrastructure as a paid service, it makes no sense at all to pursue. It isn't your core competency and you don't gain competitive advantage by doing things in a technically curious but otherwise inferior way.

Finally, vendors make it hard all the way around to deploy your own micro services. Broadband providers are well known for limiting what you can do with their bandwidth. LaCie blocked a Webdav based hack to enable ssh access (and hence a GIT install), because it was also an obvious back-door security hole.

So a home-brew solution is really kind of stupid on its face. The one valid reason for doing it at all, is if your technical curiosity leads to a genuinely better way of managing your data. I can see a massively distributed peer-to-peer rsync like service being a way for micro businesses to avoid dependence on large data centers. Again, as a curiosity, perhaps, but that is a far cry from a sensible operational strategy.

Interestingly, though, LaCie offers an alternative in the form of Wuala (pronounced like the French word "viola"), a service offering encrypted file storage space. Wuala is very much like DropBox, and reportedly has faster throughput. One other attractive feature is that you can trade excess storage capacity on your LaCie NAS for space for cloud space... in effect by allowing a section of your NAS to be part of the cloud itself. Not sure I want to trade my bandwidth as well, nor risk getting on the radar of the broadband provider.

Tuesday, December 21, 2010

URI Knot Theory

It is proposed to use language developed in the theory and practice of knots, as a primary metaphor for the architecture of the Universal Resource Identifier.

Introduction
As remote as mathematicians and topologists can bring Knot theory, the practical application is immensely approachable to most people. At the very least, they understand implicitly how useful and at the same time challengingly complex it can be to arrange loops in strings of tensile material. URIs are strings, and tie together the World Wide Web through a process which involves pulling &emdash; which is to say tension &emdash; as the primary means of establishing connectedness. That is to say, URIs are knots.

The study of knots is at once both a highly developed intellectual pursuit and a supremely pragmatic, almost purely mechanical skill. The architecture of a knot determines its strength, aesthetic beauty, elegance and approachability, and ultimately whether it has any utility in practice. The art and science of knots goes back into prehistory, and thus it evolved a language and sets of patterns that well-describe thousands of years of problem solving, where the problems involve tying things together. Thus, the language of knots should be a rich source of language well-adapted to the problems of designing URI architectures.

Background and Overview of The Language of Knots

From the perspective of analyzing the mechanics of a knot, it is conventionally decomposed into the following parts:
Bight
Bitter end
Loop
Elbow
Standing end
Standing part
Turn
Working end
Working part
As a hint of the fecundity of this language, consider briefly the idea of the "Working End" of a line: it is the leading portion which allows further extension of, and adaptations to, the knot. Just as some knots can be constructed in the middle of the line, it is predicted based on the metaphor that some URIs can be constructed as fragment taken out of a continuous string, without access to the working end.

At the time of the first draft of this post, August 3rd 2010, a Google search indicated no results on the query ' knots "uri architecture" ', and similar searches failed to produce any results. I have yet to do a formal literature search, but the Google results suggest that it is an idea which is not thoroughly discussed, and is perhaps a novel contribution.

Types of Knots

The common practical (or alternatively, the mathematical) classification of knots can also provide a meaningful working language for URI architectures. The list is from the Wikipedia entry on knots. Considering what each might mean in a Knot Theory of URI architectures leads to interesting possibilities for enriching the language of addressing on the Web.
Bend 
A knot uniting two lines (for knots joining two ends of the same line, see binding knots or loops).
Binding 
A knot that restricts object(s) by making multiple winds.
Coil 
Knots used to tie up lines for storage.
Decorative knot 
A complex knot exhibiting repeating patterns often constructed around and enhancing an object.
Hitch 
A knot tied to a post, cable, ring, or spar.
Lashing 
A knot used to hold (usually) poles together. 
Loop 
A knot used to create a closed circle in a line.
Plait (or Braid)
A number of lines interwoven in a simple regular pattern.
Slip (or Running) 
A knot tied with a hitch around one of its parts. In contrast, a loop is closed with a bend. While a slip knot can be closed, a loop remains the same size.
Seizing 
A knot used to hold two lines or two parts of the same line together.
Sennit 
A number of lines interwoven in a complex pattern.
Splice 
A knot formed by interweaving strands of rope rather than whole lines. More time-consuming but usually stronger than simple knots.
Stopper 
A knot tied to hold a line through a hole.
Trick 
A knot that is used as part of a magic trick, a joke, or a puzzle.
Whipping 
A binding knot used to prevent another line from fraying.
I will discuss more on the applications of this language to problems of URI architectures in follow up.

Sunday, December 12, 2010

On-line Meeting Options

Recently, a member of the Raleigh-Durham Web Design Group challenged me to hold on-line meetings for the group. I'm really interested in the the physical meetings, and remain a bit skeptical that on-line anything is a substitute for face-to-face interaction. Yet there are some interesting possibilities.

It makes me curious: what does "on-line" really offer us? The mundane features seem to be

  • screen sharing (with or without keyboard and mouse pointer sharing)
  • instant messaging
  • conference calling
  • videoconferencing
  • presentation or application sharing
  • session recording
  • whiteboarding

Personally, I've never seen a high-tech conferencing option that doesn't suck compared to the elegant simplicity of a low-tech in-person meeting. But that's beside the point: on-line services are not a substitute for human communication. The members who are asking seem to be saying that the costs of attending in-person meetings outweighs the reward... but some of them may be willing to put out some effort to meet on-line instead.

We are a volunteer group, so free or low-cost alternatives are attractive.  Members use PCs, Mac, and even Linux systems, so single-platform clients are ugly.

Some of the more obvious options:
  • GoToMeeting
  • Join.Me
  • DimDim
  • Yugma
  • Mikogo
Of these, Yugma's free offering stands out. It integrates with Skype, and allows up to 20 participants on-line.


We are looking for options. What are they?  Is there anything better for remote members than screen sharing? What's the latest and greatest in telepresence? What features are bloat and what do people actually use in practice? 

Friday, December 10, 2010

Social Networking and Propagation of Ignorance

People tend to think of ignorance in terms of something absent, as a gap or a hole in conceptual space. That's a pretty ignorant view of ignorance.

Ignorance, by its nature, is represented in peoples brains by neural patterns, is exchanged in communication, and is clearly evident when mob-think pervades Facebook discussions.  Urban myths are ignorance encapsulated as the stories of our modern apocrypha.

Ignorance, when realized consciously, can be variably hope, fear, or some other longing, but never faith, confidence, or trust. Without knowing what others don't know, ignorance is not just bliss: it pervades everything you say and do rather deeply and very materially.

Fighting ignorance with ignorance is not like fighting fire with fire. It is more like burning your neighbor's house down because you see fire on the horizon. That strategy is not very likely to be successful, even if it you are taking action.

This is the truest danger of social networking: ignorance is a learned meme.

Wednesday, December 8, 2010

Unnatural Bifurcation of Progressive Enhancement vs Graceful Degradation

I'm working a couple of projects out of NC State University, where Universal Design is not just a buzzword, it is a whole design center.  We recently discussed priorities for an HTML5/RoR Web application (in a nutshell it is to be a social delivery vehicle for giving diagnostic assessment to kids), and the subject was raised.

We are dealing with many different mobile devices, and the problems we are face are an extension of those  seen by designers working toward different desktop platforms and browser combinations. That brings to mind several other philosophical approaches as well, among them Transcendent CSS and Yahoo's Graded Browser Support.

NCSU incorporates its own design philosophies into Universal Design, so I don't want to mislead the reader, but my comments are not about any one philosophy but about a tendency among all of them to take the problem as a single dimension and premise the solution as a two-partition.

More specifically, quoting the YUI Graded Browser Support article:
Graceful degradation prioritizes presentation, and permits less widely-used browsers to receive less (and give less to the user). Progressive enhancement puts content at the center, and allows most browsers to receive more (and show more to the user).
In our case, the application is perceived, navigated, and reasoned about as an application with a set of behaviors and data to be stored and retrieved. Both "presentation" and "content" are second-class citizens; the behavior of the tooling takes precedence by an order of magnitude, overshadowing all else.  Whether that is right or wrong, that is the way it is on many if not most Web application projects.

My point is certainly not to argue for or against a focus on tooling; rather, that in any dynamical system it is the trajectory that is being followed that is of interest, not any one static coordinate. Content and presentation are coordinates in the space, and don't really give us the conceptual tools necessary to analyze the trajectories of moving objects.

The bifurcation is unnatural, and one might suspect it is because it is being applied to applications whose meta-model doesn't really track that of the Web. They work, not because they treat their information as content or cleanly delineate content and presentation layers, but because they use model-view-controller architecture.

Hence, there is a tension between understanding these applications in terms of content (and the two philosophical approaches to making designs adaptive), and understanding these applications in terms of behavior. For the most part, the applications, by design, ignore content as means of integrating behavior and strongly favor an explicit, imperative approach to sculpting a system.

There is really nothing progressive about imperative coding; really it is rather old-school.

Monday, December 6, 2010

Hobo: Play play play, edit edit edit, do stuff...

So, I'm about ready to do something grounded with the Hobo/Heroku/Git/RubyOnRails/Rails technology stack.

One of the really sad things about the present state of Web technology, is the amount of preliminary technology stack setup that has to go on just in order to get to the starting position. That's another series of posts right there, but I digress.

A cool thing about OSX is that it allows terminal sessions to be pre-configured to launch commands, then bundled into groups, so I can launch (a) a regular command window in which to run shell commands or rails consoles (b) a terminal in which to run the development server (c) a terminal in which to run Jasmine (d) a terminal in which to run rake, rspec, steak, cucumber, etcetera and (e) a MacVim with NerdTree; and have them all pre-configured with the right shell, Ruby, and Gems.   A featherweight setup for development of a specific application can be configured within a few minutes and launched with one click. But again, I digress.

Start up the server for Leapercan; oops -- my other logged in user has a Rails 3 app running on port 3000 -- need to use -p option to make this one run on, Idunno, port 3030.

/script/server -p 3030

Huh. MySQL gives an error:

Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

OK, this isn't the first time MySQL has gone AWOL under OSX. I'm still wondering why this is happening. Workaround seems to be: ps -ef|grep mysql to get the PID of the MySQL server, then kill $PID or kill -9 $PID to force the service to start a new process. Of course, MySQL has been installed to load automatically as a process upon boot, and to restart if it is ever killed. Killing the MySQL process works.

Ah, but alas, now it is really late, and I've got to pause again. Perhaps the next thing I'll do is create a questionnaire application -- something to play out 25 questions or so in order, and capture the results in a simple table. I'll use a one-time-pad to provide some measure of scope of access, to limit the visibility of the questionnaires to just those who should be authorized to fill one out.

I'll also need a time-limited list of authorizations -- basically just a mapping of user identities to scope identifiers.  Both elements of the mapping could be opaque, but the user identities should be supplied externally. The idea here is that an institutional user should be able to load up a list of authorizations for a one-time use.

Another aspect of the system: the user interface should be Web based and targeted toward mobile platforms, particularly the iPhone/iPad/iPod Touch or similar Android devices. It should not give any special consideration toward working on an IE browser or any other insecure platforms.