Remote firing of neurons using RF and nanoparticles

October 10th, 2010

I just came across this article on remote control of neuron firing using RF waves and nanoparticles. The article summarized a few papers that just came out this summer which are pushing the limits of our understanding of the brain. I’ve been studying fMRI technology recently and it allows neuroscientists to observe oxygen in the blood inside the brain which happens to occur just after neurons are fired. Using that technique, we’re able to identify which areas of the brain are active during certain thoughts or when provided various stimuli either visual or audible.

My brief study of fMRI lead me to the question of whether or not we can make a neuron fire without having to cut open the brain. Cutting open the brain is extremely invasive and complex and thus requires a highly specialized team of surgeons and neuroscientists to conduct it. Research opportunities for invasive neuroscience are extremely small compared to non-invasive techniques and as a result non-invasive techniques are more tangible by most researchers. I was extremely excited to find this article which explains at a high level how the remote neuron firing procedure works. I’ll try to summarize it here.

A nanoparticle is injected intravenously which flows through the blood into the brain. An RF pulse is sent to the brain in a similar way that MRI works, targeting a specific local area. The RF pulse heats up the nanoparticles in the local area which causes the neuron to fire.

As this technology is refined, I’m interested in understanding how we can transmit more complex ‘thoughts’ or ‘stimuli’ to the brain remotely. We’re able to fire individual neurons within the brain so this isn’t too far off. I’d estimate we’ll have a method for remotely sending more complex and meaningful signals to the brain within the next 5 years if not sooner. The poor spacial and temporal resolution with this method and the need for more parallelism in firing individual neurons is probably what needs to be addressed to get to a point where we can send more complex and meaningful signals.

Review of “Visual image reconstruction from human brain activity using a combination of multiscale local image decoders.”

October 8th, 2010

Since I’ve decided to return to school to get my PhD, I figured it would be a good idea to start reviewing research papers again. I must admit that its been a while since I’ve reviewed a research paper and I’ve never reviewed a neuroscience paper before. None-the-less, here is my attempt at a review.

Summary: The paper presents research using fMRI analysis of subjects’ brain patterns when viewing various 10×10 block images. The method uses multiple points of analysis of the brain and the image reconstruction algorithm requires training to select voxel weights.

They present analysis of random image identification using a subset of all possible random images and show the rate of successful identification declines as the size of the potential image set increases. The authors explain their voxel selection method and perform tests to determine the quantifiable benefit of their voxel selections over other methods. Next they explore their image reconstruction technique to determine how well their multiscale method performed over single scale methods. My guess is the multiscale method was an after-thought once they reviewed the performance of the single scale data. The multiscale image did perform better at correctly matching the presenting image, however, I didn’t understand how they were actually calculating ‘performance’ or ‘eccentricity’ despite relying on it in the analysis. It could be common knowledge in the field that I’m just not familiar with yet.

The authors do an excellent job at reviewing their own work in the discussion section and present a handful of potential future areas of research. They finish with a detailed explanation of their experimental procedures which I found particularly interesting because it covered details of their data gathering, filtering, and processing using different sources such as correlating retinotopy mapping to the fMRI data (though I didn’t understand it completely). It gave me a good insight into the experimentation process used in neuroscience.

Questions: I’m not sure if its just my lack of knowledge about the type of data the fMRI and retinotopy mapping produces or if the authors were just vague but their observations of the “Weight Distribution on the Cortical Surface” seemed a bit sparse. It didn’t seem to suggest why the weights one way or another were more or less beneficial to their experimental results. Perhaps this is an area for future research or perhaps my knowledge in the field is showing itself. They did follow that section up with experimenting with different methods and it might seem more obvious why if I knew a bit more about retinotopy.

Future Work: It would be interesting to see if similar techniques could be used to identify the main component of a larger picture. My thinking is that if they can reconstruct a 10×10 image what ability could the same or an adapted technique have at reconstructing a 10×10 piece of a bigger picture? For instance a picture in which a contrasting foreground image of 10×10 was placed against a larger random background. What happens when the test data is three dimensional instead of a simple 2d image?

Could a similar technique be used to identify simple shapes in more complex scenes? Would other areas of the brain come into play when using actual objects or more complex scenes? How well does this technique scale up beyond the 10×10 images? How can we identify color?

It would be interesting to see the effectiveness of various types of multivoxel pattern decoder methods in relation to to same experiment or even with scaling it up. The selected technique worked for this instance of 10×10 block images but will it still work if the image becomes more complex like 100×100 or even 1000×1000? What is the effectiveness of different methods as the image complexity increases? Perhaps other reconstruction methods work better for more complex images. I’m curious what the most complex reconstruction is to date and what methods were used.

One of their conclusions is that the multiscale image combination method contributed to the positive results. It seems highly coupled with the voxel selection technique. It would be interesting to explore other image combination techniques in relation to different voxel selection methods. Perhaps another voxel selection / image combination technique would produce more accurate results.

Conclusions, Interests and Reflections:
The authors mention they used a statistical learning algorithm called “sparse logistic regression” to train the weights of voxels. I haven’t come across this learning algorithm before and am interested in learning more about it.

It has become clear to me that I know far too little about brain imaging technology to understand this paper completely. I intend to study different brain imaging technologies like fMRI next so that I can better understand some of the details in future papers.

Overall I think this was an extremely well researched paper. The results were clearly presented and the authors seemed to give a thorough analysis of their methodology.

Visual Image Reconstruction from Human Brain Activity using a Combination of Multiscale Local Image Decoders – Yoichi Miyawaki, Hajime Uchida, Okito Yamashita, Masa-aki Sato, Yusuke Morito, Hiroki C. Tanabe, Norihiro Sadato, and Yukiyasu Kamitan

My Goodbye Letter to Engine Yard

August 29th, 2010

That response sounds familiar but really isn’t that comforting or
realistic. You’re suggesting its rare to have instances disappear yet
it happened twice in less than 6 months. You’re suggesting I upgrade
to a more expensive server which may or may not solve the problem. You
don’t know what causes the instances to disappear but for some reason
a more expensive instance solves the problem. I’m not sure how those
dots are connected but it certainly doesn’t add up to me. You want me
to spend more money per month without any real justification,
quantitative data, or explanations.

To summarize:

* You don’t know why instances disappear.
* Its rare for instances to disappear.
* The solution is to spend more money per month.

From my perspective, you still haven’t resolved the underlying
problem. You suggest maybe hardware but hardware crashes twice in 6
months? That doesn’t sound realistic. The issue that concerns me is
that you haven’t addressed the underlying problem of why the instances
disappeared. You’ve only offered a solution that has no connection to
the actual problem: Get a better server. Of course, I could just go
straight to Amazon and bypass EY altogether if I were to get another
server.

Without really understanding why the instances are disappearing it
points to a bigger problem at EY than just this issue. It points to a
lack of concern for your clients, a lack of understanding of your own
technology, and a fundamental problem in how you attempt to solve the
problems presented to you. Its a ‘shuffle it under the rug’ approach
to solving your problems which doesn’t bode well with me. Your
solution is, simply put, one without any technical merit. Anyone in
sales could have given me the same answer. If I were to refer clients
to EY and they had other problems that you couldn’t figure out would
your solution be that they need to upgrade their servers?

I appreciate your delayed investigation into the issue but I
definitely won’t be moving more of my clients to EY anytime soon. I’m
actually glad you reached out to me recently because its given me the
motivation to review what I still see as this outstanding issue. As
such, I’ve decided to cancel my EY account.

> From: EY
>
> X and Y asked me to follow up with you on this.
> First of all, if someone on my team dropped the ball on getting back to you,
> we apologize. I will follow up with the engineers on my end.
> Re. instances disappearing – I found and reviewed the ticket for when this
> happened. It appears that it was no longer possible to SSH into your
> instance and when our engineer tried to terminate it, it was stuck in a
> shutting down state. I can’t answer why this happened in this particular
> case, but out of the several thousand AWS instances we manage on the EY
> AppCloud, occasionally we have observed that an instance can disappear or
> become unresponsive. This can happen, for example, if the physical server
> it is mounted on fails. The few times we have seen it, it has been for
> Small instances, which is what you had. Our default AWS instance size for
> EY AppCloud is now Medium, which we to date have not observed issues with.
> Hope that answers your question – and feel free to contact me for any
> additional questions about this.

Faster AJAX integration tests using Rails, Cucumber, Capybara, and envjs

July 4th, 2010

I admit it. I put off using Cucumber for a few years while it became more stable. I took a look at it a few years ago and found it didn’t really work properly according to the then current documentation. So, I shelved it until recently. There seems a renewed interest in BDD and Cucumber recently so I decided to take another look. Needless to say, I was impressed and since I was starting a new project I figured it was the perfect time to start using Cucumber.

An hour or so into it, I still didn’t have my first test passing but I felt I was making progress so I persisted. Here is my first test:

Feature: Registration
  In order to use the site
  As a visitor
  I want to be able to create a new account

  @javascript
  Scenario: Signup Form
    Given there are no users with the email address test@domain.com
    And I am on the home page
    When I follow "Signup"
    Then I should see "First Name"

I added the ‘@javascript’ part later. I couldn’t figure out why my AJAX query wasn’t running in Cucumber. It was working fine in my browser so I asked my buddy Corey. He pointed me to Capybara.

Basically, there are 2 distinct pieces to the testing process in Cucumber.

1. the step definitions
2. the browser simulator

For the step definitions part, its not really about you write the steps but more about how those steps are translated back to the DOM and how they interface with the browser simulator. Cucumber uses Webrat as the default for step definitions and I may have just followed the introduction docs to end up with that as the default. The problem with Webrat is that it doesn’t support interfacing with the DOM very well and so it doesn’t allow access to page elements that have been updated by Javascript. That means any AJAX testing is completely out the window. Unfortunately, most websites today pretty much require Javascript so Webrat is pretty much useless to me.

Capybara is a Webrat alternative that does support Javascript. Capybara allows you to access DOM elements that have been updated by Javascript. Now here’s where things get tricky. Both Webrat and Capybara integrate with Selenium, a browser simulator. The same simulator is being run in both cases but only Capybara has the ability to access the updated DOM elements.

This allowed me to finish up my first test. I didn’t notice it at first but after I added a second test I realized how slowly these tests were running. I didn’t get any quantitative performance data to share but just sitting there waiting for 2 simple tests to run I was pretty amazed that anyone would even be testing like this. There would be no way this could scale to a suite of tests for an entire site. The time wasted in just waiting for all the tests to run would prevent any actual development to occur.

So I started looking for alternatives. The culprit in the slowdown here was Selenium. I came across a blog post by RubyFlare the was talking about a much faster alternative to Selenium called envjs. You need to install the capybara-envjs gem, the envjs gem, and reconfigure some things in Cucumber but its fairly simple.

Now that I had my brand new envjs browser simulator working with Cucumber and Capybara, I tried to run my first 2 tests on it. FAILED

What I discovered in the envjs output was:

ERROR: [Sun Jul 04 2010 17:44:10 GMT-0600 (CST)] {ENVJS} response XML does not apear to be well formed xml Line: 1377
ERROR: [Sun Jul 04 2010 17:44:10 GMT-0600 (CST)] {ENVJS} ReferenceError: $domparser is not defined

I started digging through the envjs code and basically discovered it doesn’t really support AJAX calls returning HTML. Just XML. Well back to the drawing board. It doesn’t seem like it would be incredibly difficult to add support for that to envjs and the rest of the chain of libraries up to Cucumber. When? I’m not going to start responding to all my AJAX queries with well formed XML instead of simple HTML anytime soon. It would just add an unnecessary layer of complexity to the application and I would have to do it just to use the envjs browser. No thanks. Back to the drawing board.

Since I did get my first AJAX tests to pass using Selenium, I reverted back to using that so I can at least progress for now, albeit slowly. I know a lot of people are frustrated by the slowness of Selenium so I doubt it’ll be too long before envjs supports HTML to be returned from AJAX calls.

EngineYard default configurations strike again

April 30th, 2010

It was just brought to my attention that my company’s homepage was pointing to the wrong app. This has happened a few times since I’ve switched to EngineYard. They don’t include www aliases in the default nginx configuration so you have to add them with a keep.domain.conf file. I recently migrated my company site to a new instance and left the default configuration. When I checked to make sure the app was setup on the new instance properly, http://onomojo.com , it worked fine and I didn’t think anything of it. Of course, I didn’t test http://www.onomojo.com which ended up pointing to an app that is still in the early phases of development since I didn’t customize the nginx config. What a huge goof. No wonder I’m getting mixed responses from potential new work lately. If you’re reading this and you saw the awkward half broken site with the test video please revisit the site again.

Google Analytics maps are way off

April 16th, 2010

I was just browsing my Google Analytics data today when I noticed the map of Florida looked really weird. Growing up in Florida I knew this was obviously incorrect so I took a screenshot.

Bad Florida Map

And here is what Florida is supposed to look like.

Take a look at the bottom past Miami near the Keys. The Google map has no land there at all and the shape is all wrong. It looks like someone took a big bite out of south Florida. Maybe they’re just predicting water levels to rise soon and just saving themselves the extra effort of redoing their map after that happens. A bit of proactive thinking perhaps or completely obvious blunder.

No Plastic Day – June 8, 2010

April 15th, 2010

No Plastic Day - June 8, 2010

I like to do my part to save the planet and this is just one way in which Onomojo is trying to help. We’ve just recently finished a non-profit site promoting No Plastic Day which is on June 8, 2010. So far we’ve got a decent amount of people joining the event and I’m asking for your help in promoting it further. We all need to do our part to save the planet. One day without disposable plastics isn’t much to ask. Join us and together we can create a better future.

Engine Yard problems

March 6th, 2010

Here I am with yet another proprietary EngineYard problem again. I simply clone an existing application that’s up and running fine and the new cloned environment doesn’t boot. Its giving me this error instead:

/usr/lib/ruby/gems/1.8/gems/rails-2.2.2/lib/rails/gem_dependency.rb:224:in `specification’: undefined method `version_requirements=’ for # (NoMethodError)

Here’s a recent thread about the same issue:

http://rubyforge.org/tracker/index.php?func=detail&aid=27868&group_id=126&atid=575

Looking into the differences in my ‘cloned’ environment and my actual environment and I see the gems list isn’t even the same. So basically Engine Yard’s clone command doesn’t actually clone the environment at all. It just took my old apps and tried to copy and paste everything onto a newly configured environment which obviously doesn’t work.

My original environment gems:

abstract (1.0.0)
actionmailer (2.3.5, 2.3.3, 2.2.2, 1.3.6)
actionpack (2.3.5, 2.3.3, 2.2.2, 1.13.6)
actionwebservice (1.2.6)
activerecord (2.3.5, 2.3.3, 2.2.2, 1.15.6)
activeresource (2.3.5, 2.3.3, 2.2.2)
activesupport (2.3.5, 2.3.3, 2.2.2, 1.4.4)
addressable (2.1.1)
aws-s3 (0.6.2)
builder (2.1.2)
daemons (1.0.10)
erubis (2.6.2)
eventmachine (0.12.6)
extlib (0.9.9)
eyrubygems (0.0.2)
facter (1.5.2)
fastercsv (1.5.1)
fastthread (1.0.7)
ferret (0.11.6)
gem_plugin (0.2.3)
hpricot (0.8.2, 0.8.1)
igrigorik-em-http-request (0.1.5)
json (1.1.3)
mime-types (1.16)
mixlib-cli (1.0.4)
mixlib-config (1.0.12)
mixlib-log (1.0.3)
mongrel (1.1.5.1)
mongrel_cluster (1.0.5)
ohai (0.2.0)
open4 (0.9.6)
rack (1.0.1, 0.4.0)
rails (2.3.5, 2.3.3, 2.2.2, 1.2.6)
rake (0.8.3)
rest-client (1.3.1, 0.9.2)
right_aws (1.10.0)
right_http_connection (1.2.4)
rmagick (2.8.0)
ruby-openid (2.1.2)
rubyforge (1.0.3)
sparklines (0.5.2)
stomp (1.0.6)
systemu (1.2.0)
will_paginate (2.3.12)
xml-simple (1.0.12)

And the ‘Cloned’ environment gems:

abstract (1.0.0)
actionmailer (2.3.3, 2.2.2, 1.3.6)
actionpack (2.3.3, 2.2.2, 1.13.6)
actionwebservice (1.2.6)
activerecord (2.3.3, 2.2.2, 1.15.6)
activeresource (2.3.3, 2.2.2)
activesupport (2.3.3, 2.2.2, 1.4.4)
addressable (2.1.1)
aws-s3 (0.6.2)
builder (2.1.2)
daemons (1.0.10)
erubis (2.6.2)
eventmachine (0.12.6)
extlib (0.9.9)
eyrubygems (0.0.2)
facter (1.5.2)
fastercsv (1.5.1)
fastthread (1.0.7)
ferret (0.11.6)
gem_plugin (0.2.3)
hpricot (0.8.2, 0.8.1)
igrigorik-em-http-request (0.1.5)
json (1.1.3)
mime-types (1.16)
mongrel (1.1.5.1)
mongrel_cluster (1.0.5)
ohai (0.2.0)
open4 (0.9.6)
rack (1.0.1, 0.4.0)
rails (2.3.3, 2.2.2, 1.2.6)
rake (0.8.3)
rest-client (0.9.2)
right_aws (1.10.0)
right_http_connection (1.2.4)
rmagick (2.8.0)
ruby-openid (2.1.2)
rubyforge (1.0.3)
sparklines (0.5.2)
stomp (1.0.6)
will_paginate (2.3.12)
xml-simple (1.0.12)

Clearly this new environment isn’t a ‘clone’ at all. You can’t just put feathers in your butt and call yourself a chicken. Don’t call this feature ‘clone’ when its really just recreating everything on a completely different setup if they’ve changed their default environment configuration. It should be called the ‘waste another 4 hours fixing our broken Engine Yard system’ feature. I think its a little more accurate.

Rojo: An easy to install Ruby on Rails CMS

February 8th, 2010

Rojo is Onomojo’s Ruby on Rails Content Management System. You can find it here:

http://github.com/onomojo/rojo

Today we made some changes to make the initial setup of a Rojo instance easier. The steps to setup a new Rojo instance are clearly detailed in the README. This should help eliminate most of the problems new users were encountering when trying to setup Rojo from scratch. Please let us know if you have any comments or suggestions for improving the setup process.

In the next few weeks, we will be releasing the plugins that we’ve developed for Rojo including a blog, video gallery, photo gallery, and more so stay tuned.

GitHub down yet again

February 2nd, 2010

I am experimenting with a new Engine Yard account today and their Setup basically requires you to have your projects in git. Since the site was from a private svn repos I decided I’d go ahead and signup for a paid Github account so I can host my projects there privately instead of having to setup my own git server. I should have trusted my gut because not more than a few hours later here I am trying to access my Github account and the site is broken again.