The sophistication of online dating tools such as okcupid has helped many people extend their romantic reach and spark relationships that shine (some might say smolder) for a lifetime.

Entrepreneurs and founders share with dating singles a similar need: they must find a trustworthy partner (or team) whose personality, skills and dedication will complement their own. Recently, I’ve wondered what online services exist out there for founders to find a co-founder, or for technical leaders to find an entrepreneurial counterpart and vice versa.

It turns out there are a handful of websites that offer just this service. I will be taking a look at these in the future and I’ll report what I find. In the meantime, here is the complete list:

1. Startup With Me
2. Founder2Be
3. WeStartUp
4. Cofounders Lab
5. NetPly
6. Foundrs
7. Tech Cofounder
8. Kofounder
9. Founder Dating
10. Cofounder Network

And some interesting resources that complement these services:

1. HireLite: A “hiring speed-date” in which dozens of companies and dozens of candidates take turns in 5-minute bursts interviewing and getting to know each other. Viable matches follow up with each other after the “tournament”.
2. Startup Digest: Articles and events (mostly in Silicon Valley) that facilitate getting going.
3. Quora: How Do I Find Good Startup Partners?: Some discussion about this same topic. Some of the links above were found here.
4. Cofounder Google Doc: A Google Doc that was created at news.ycombinator.com where people add themselves when looking for a cofounder.

There are a few bash shell tricks I’ve learned lately that have all come together to assist in helping me write a script that can remotely execute ruby code on a server.  The first trick is heredocs in bash:

echo << +++
This is a heredoc.
More than one line is just fine.
+++

The use of << is the start of a heredoc. It means that you want to include a multi-line string as an argument to the command (‘echo’), beginning and ending with a specific string. Any string can go after the angle brackets, so I chose “+++” since it’s unlikely to appear in my quoted text. The “+++” at the beginning of the 3rd line indicates the end of the heredoc (block of text). It has to be at the beginning.

Next up is literal heredocs:

echo << '+++'
This is a $literal heredoc!
The $dollar signs are not treated as variables,
and the bang (!) is not special.

Strangely, by simply quoting the heredoc start marker, the heredoc becomes a literal one: there will be no string interpolation or variable substitution or any other manipulation that bash normally does with strings. This is really handy when dealing with code because dollar signs and other special characters are more common.

While not strictly necessary (unless you need variable substitution, see below), I also combine with the ‘tee’ operator to make piping to other commands for preprocessing easier:

tee << '+++' | echo
This is a heredoc again.
+++

The 'tee' command simply takes standard input and sends it to standard output, no buffering. So now that I have a literal heredoc being sent to echo, what if I want to explicitly substitute certain "variables" in my text? I use sed to do the replacement:

tee << '+++' | sed "s/MYVAR/$MYVAR/g" | echo
puts "You said MYVAR!"
+++

So this might seem like a strange thing to do... I'm using a literal heredoc to AVOID variable substitution, and then I'm using sed to do variable substitution! The reason for this is that I want more control over what is substituted. When I have a large chunk of ruby code that I want to execute, I don't want to have to worry about escaping dollar signs and bang characters. Instead, I use a literal heredoc and then explicitly replace special strings with their substitutions using sed. Safe and effective.

Finally, instead of piping to echo, we can simply pipe to ssh and add 'ruby' as the last parameter to ssh:

tee << '+++' | sed "s/MYVAR/$MYVAR/g" | ssh root@myserver ruby
puts "You said MYVAR!"
+++

Alternatively, you could pipe to bash. Let's do that and send a heredoc within the heredoc!

tee << '+++' | \
sed "s/SSH_HOST/$SSH_HOST/g" | \
sed "s/ADMIN_PASSWORD/$ADMIN_PASSWORD/g" | \
ssh $SSH_LOGIN@$SSH_HOST /bin/bash

tee << '---' |debconf-set-selections
# URL of Chef Server (e.g., http://chef.example.com:4000):
chef	chef/chef_server_url	string	http://chef.SSH_HOST:4000
# New password for the 'admin' user in the Chef Server WebUI:
chef-server-webui	chef-server-webui/admin_password	password	ADMIN_PASSWORD
# New password for the 'chef' AMQP user in the RabbitMQ vhost "/chef":
chef-solr	chef-solr/amqp_password	password	ADMIN_PASSWORD
# Upgrading from 1.5.4 and below.
rabbitmq-server	rabbitmq-server/upgrade_previous	note
---

  # Install chef
  aptitude -y install chef-server

+++

This last example is one that I've actually used--it remotely installs chef-server (without asking for prompts) on a Ubuntu box (Lucid).

I’ve been working on a Javascript demo of the “Perspective Calendar” idea I blogged about earlier.  The code for the project is hosted on GitHub.

I had an idea today that had its origins about 4 months ago when I read a blog post about a “logarithmic calendar” by Marco Arment.  The logarithmic calendar is a very practical solution to an obvious problem: we care more about what’s happening in the near future than the far future, so why not make a calendar to reflect this need?  The idea of a rectangular page with equally-sized blocks representing days is so… Gregorian, however.  Why not use the visualization power of a computer to help us out?

Rather than use a 2-dimensional plane as Marco suggests, why not use our 3-dimensional spacial perception ability to “see into the future”? (Perhaps this is what he is suggesting by the mention of a “navigation screen”.) The real benefit in this case would be that we could give “high priority” events a larger size so that even when they are way in the back (far in the future) we can still see them coming from a mile away:

I would love to be able to view this calendar with a zoom in/out function, and the ability to look in the “rear-view mirror” at a history of big events in the somewhat recent past.  You could even change the perspective ratio to get more or less time in visible scale.

Also, you could put “tags” poking out of the side for holidays or other day-long events that need to be marked.  If the Perspective Calendar caught on, perhaps a tube or tunnel would be an even better metaphor, since it would allow for 360 degrees of events in a day… except for the clutter that might cause.  In any case, I hope the makes the rounds and someone implements it on top of iCal or Google Calendars.

As a software engineer, I spend a lot of time in a text editor (about 40 hours per week).  Recently, I’ve been learning to use the Vim editor (specifically, MacVim) and have been pleasantly surprised by the power and flexibility.  One of my larger goals in life is to engage in deliberate practice in the things I want to become very good at.  Because of my vocation, I’ve chosen Vim as one area where it seems worthy of dedicating time and effort to becoming an expert.

So you can think of deliberate practice as Unit Tests for your brain: find an invariant function that takes inputs, applies a transform to produce outputs, and then compares the outputs with an expected value.  If I were a psychologist, I would probably be able to poke a hole in this short explanation of deliberate practice, but for this initial application to Vim, I think it suffices.

What would Unit Tests for your brain look like?  Whenever you learn something new in Vim, add a line to a text file that gives you the opportunity to practice your new ability:

Using the 'surround' plugin, remove the single quotes from 'surround'.

Your text file will grow in length as you learn new abilities.  Revisit the text file and perform each of your Unit Tests on a daily basis.  The strength of your neuronal connections will improve and you will become an expert at editing in Vim.

Using 'surround', remove the _value and replace with ['value']:
  config_value

Using a macro recording, prefix the first and third words of each
line with a double dash ("--"):
  one two three four
  five six seven eight
  nine ten eleven twelve

Display the contents of the register where you recorded the macro:

Modify the above macro to use underscores instead of dashes, and
then read the macro back into the register.

etc.

This is the best solution I’ve found to the related question I posted on the Vim list.  I hope it works for you!

Update: I forgot to mention that one really neat technique I’ve picked up is the ability to quickly go to my practice file and add new tricks.  The way I do this is by using (mark-capital-letter) in Vim: go to the practice file, and type “mP”.  This adds a bookmark to the file.  Now, whenever you want to re-visit the practice file, type ‘P (single-quote-P).   Instant access!  Any capital letter can be used.

To go along with the topic divergence of this blog and my others, I’ve spent a little time choosing and customizing a new visual theme that, in my opinion, looks better than the Illacrimo theme I had used for several years.  If you like what you see and want it for your own site, check out elegantthemes.com.  I’ve chosen the Polished theme for this site (and yes, it costs a little to support the developer).

Ever since the discovery of the memristor was announced at HP labs last year, I’ve been fascinated by its story and its promises. Now, its inventor Stanley Williams has given a presentation (available on YouTube) that goes in to some of the mathematical details and further predictions that he has for the device.

It’s a 45 minute presentation, but if you’re interested in the future of computing, I think you’ll enjoy it. I was impressed with the foresight of Leon Chua who in the late 1960s and early 70s discovered via mathematical exercise the “missing circuit element” that should relate flux to charge. If I were him, I think I’d have lost a little confidence in my work if my predictions hadn’t panned out after 40 years.

In addition to the neat math behind it (the memristor is the only fundamental circuit component that is time-variant, and therefore cannot be described in a single equality relationship), Williams makes some stunning claims about the potential of the memristor. For example, in strange agreement with Ray Kurzweil’s predictions, Williams shows a 3D cube of memristors on his slides. He predicts that we will soon have memory storage devices that last for “geologic time” (i.e. thousands or millions of years) but that can react at nanosecond switching speeds. What’s more, because the memory is passive (no energy required to sustain) the memristor is perfectly suited to low-power and low-heat systems: in other words, it just makes sense to stack them on top of each other. Williams calculates a theoretical limit of 1 petabit of storage per cubic centimeter (I think he said square centimeter in the presentation, but I assume he misspoke, since his slide shows a 3D cube?)

Another exciting part of the presentation comes near the end where Williams shows how the memristor may play a role in the next 10 years of computing achievements. He highlights the work of the HP photonics lab and claims that data transfer will soon be achieved through light (photons) for distances greater than a micrometer. With the remarkable ability of memristors to be both memory and logic gates (they naturally form the “implication” logic function which Bertrand Russell showed could represent logical operations in the most compact form), Williams envisions a computing device with hundreds or thousands of cores in a 3D matrix, with photonic message passing between devices. He estimates that in 10 years, the combination of these two technologies will increase our computation-per-dollar by 100 times.

And last but not least was the incredible insight, this time once again from Leon Chua, that the memristor behaves much like a human neuron. The HP lab that invented the memristor is already working on a prototype chip that will attempt to emulate the neurons in a brain, much like the Bluegene-L system has achieved. As Williams pointed out in his presentation, the key here is emulation, not simulation. Up until now, we have only been able to simulate the brain with our computing technology. What will it be like to properly emulate it?

Posted via email from Duane’s Quick Posts

This is a really neat article about the transition science is taking right now as it reframes the “placebo effect” and its role in health and the search for improvements to the body’s natural (but limited) healing system:

In a study last year, Harvard Medical School researcher Ted Kaptchuk devised a clever strategy for testing his volunteers’ response to varying levels of therapeutic ritual. The study focused on irritable bowel syndrome, a painful disorder that costs more than $40 billion a year worldwide to treat. First the volunteers were placed randomly in one of three groups. One group was simply put on a waiting list; researchers know that some patients get better just because they sign up for a trial. Another group received placebo treatment from a clinician who declined to engage in small talk. Volunteers in the third group got the same sham treatment from a clinician who asked them questions about symptoms, outlined the causes of IBS, and displayed optimism about their condition.

Not surprisingly, the health of those in the third group improved most. In fact, just by participating in the trial, volunteers in this high-interaction group got as much relief as did people taking the two leading prescription drugs for IBS. And the benefits of their bogus treatment persisted for weeks afterward, contrary to the belief—widespread in the pharmaceutical industry—that the placebo response is short-lived.

Posted via email from Duane’s Quick Posts

Posted via email from Duane’s Quick Posts