<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0"><channel><atom:link rel="hub" href="http://tumblr.superfeedr.com/" xmlns:atom="http://www.w3.org/2005/Atom"/><description>A small web agency and incubator based in downtown Richmond, VA.</description><title>Decogram Corporation</title><generator>Tumblr (3.0; @decogram)</generator><link>http://blog.decogram.com/</link><item><title>Bind to Route 53 transitioning</title><description>&lt;p&gt;If you&amp;#8217;re like us and have been managing your own DNS for a while, you&amp;#8217;ve probably grown use to making changes to zone files and running &amp;#8220;rndc reload&amp;#8221;.  Well, we&amp;#8217;ve transitioned to using Amazon&amp;#8217;s Route 53 DNS service which allows us to leave the nameserving up to Amazon&amp;#8217;s global presence of nameservers.   &lt;/p&gt;
&lt;p&gt;Transitioning to Route 53 is a little bit tricky, especially for existing domains/zones.  So we put together a script to make it easier to sync your BIND-style zone files to an AWS zone.  &lt;/p&gt;
&lt;p&gt;There are a few other similar utilities out there, including ones that Amazon directly references on the Route 53 developer page, but none of them really fit the bill for what we needed.&lt;/p&gt;
&lt;p&gt;Let us know what you think and if you see anything better out there.&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;a href="http://github.com/tomeeo/zone_file_to_route_53"&gt;link&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description><link>http://blog.decogram.com/post/4639653002</link><guid>http://blog.decogram.com/post/4639653002</guid><pubDate>Fri, 15 Apr 2011 16:13:23 -0400</pubDate></item><item><title>Wireframing</title><description>&lt;p&gt;We&amp;#8217;ve been doing quite a bit of information architecture lately with the design and development of &lt;a href="http://www.fitterwith.com"&gt;http://www.fitterwith.com&lt;/a&gt; and our forthcoming lucyphone.com version 2 launch.  After stumbling through OmniGraffle, Visio, and various cheap drawing applications, we&amp;#8217;ve been pretty impressed with how &lt;a title="Balsamic" target="_blank" href="http://www.balsamiq.com"&gt;Balsamiq&lt;/a&gt; makes wireframing ideas really easy.  It&amp;#8217;s an Adobe AIR app, so we&amp;#8217;ve been able to use it on a Linux Netbook as easily as on Mac OSX, and the files are stored as plain xml. &lt;/p&gt;</description><link>http://blog.decogram.com/post/742823346</link><guid>http://blog.decogram.com/post/742823346</guid><pubDate>Sun, 27 Jun 2010 15:20:00 -0400</pubDate></item><item><title>Thinking Sphinx... and feeling jinxed</title><description>&lt;p&gt;After some time working with Thinking Sphinx for a client, I figured I should share some of the gotchas I worked through.  I didn&amp;#8217;t find the TS documentation to be all that bad at first glance.  It all seemed fairly comprehensive.  But after working with TS in practice, here are a few things I would have liked to know:&lt;/p&gt;
&lt;p&gt;1.  How to get around Delta indexing troubles on Passenger&lt;/p&gt;
&lt;p&gt;The documentation actually explicitly &lt;a href="http://freelancing-god.github.com/ts/en/common_issues.html#deltas"&gt;addresses this issue&lt;/a&gt; but it didn&amp;#8217;t solve my problem.&lt;/p&gt;
&lt;!-- more --&gt;
&lt;p&gt;Here&amp;#8217;s what was happening. I had correctly set up delta indexes for my model.  I had run the migration to add the delta column.  I had rebuilt the conf and re-indexed locally.  In my local dev environment, everything worked fine.  When I deployed via capistrano to the staging box (running Passenger), here&amp;#8217;s what would happen.  In the live app or in script/console, I would actually see the delta indexer being invoked.  The response from the indexer even seemed to indicate that the deltas were processed. However, when I ran a Model.search, my updated or new model instances were not getting returned.   The culprit?  The documentation does mention that the user that the app is running under ( in the case of Passenger it&amp;#8217;s the file owner of environment.rb) needs to be the same user that is running sphinx.  That&amp;#8217;s true.  But here was my problem.  Before I started delta-indexing, I had been running sphinx as a different user.  This means that the very first index files (i.e. /db/sphinx/[model_name]_core.sp* ) had been written and owned by a different user.  Then, when I switched users, the index updates were silently failing.&lt;/p&gt;
&lt;p&gt;The solution?  I ended blowing away the existing index files, re-configuring (re-generating the staging.sphinx.conf) and then rebuilding.  Thereafter, the documentation led me to happy delta-indexing.&lt;/p&gt;
&lt;p&gt;2.  Faceted One-to-many associations.  Let&amp;#8217;s say you have a model Post that has_many Tags.  You might want to index your profile and include the Tags as a search facets so you can see the breakdown of posts across all of the tags:&lt;/p&gt;
&lt;p&gt;So you might do something like this in your post.rb&amp;#160;:&lt;/p&gt;
&lt;p&gt;define_index do&lt;/p&gt;
&lt;p&gt;&lt;span&gt; &lt;/span&gt;indexes title&lt;/p&gt;
&lt;p&gt;&lt;span&gt; &lt;/span&gt;has tags.text, :as =&amp;gt; :tag, :facet =&amp;gt; true&lt;/p&gt;
&lt;p&gt;end&lt;/p&gt;
&lt;p&gt;Then let&amp;#8217;s say you want to see the Profiles with a particular set of tag texts, you would so something like this:&lt;/p&gt;
&lt;p&gt;&lt;span&gt; &lt;/span&gt;Post.search :with =&amp;gt; { :tag_facet =&amp;gt; [&amp;#8220;iphone&amp;#8221;.to_crc32 , &amp;#8220;ipad&amp;#8221;.to_crc32] }&lt;/p&gt;
&lt;p&gt;Okay, so that one was pretty much in the documentation.&lt;/p&gt;
&lt;p&gt;Here&amp;#8217;s a problem I ran into though.  I was adding a :type to the &amp;#8220;has&amp;#8221; statement.  For instance, I had this:&lt;/p&gt;
&lt;p&gt;has tags.text, :as =&amp;gt; :tag, :facet =&amp;gt; true, :type =&amp;gt; :string   # BAD&amp;#160;!&lt;/p&gt;
&lt;p&gt;or&lt;/p&gt;
&lt;p&gt;has tags.id, :as =&amp;gt; :tag, :facet =&amp;gt; true, :type =&amp;gt; :int   # BAD&amp;#160;!&lt;/p&gt;
&lt;p&gt;Don&amp;#8217;t make this mistake.  Those :types shouldn&amp;#8217;t be there for these one-to-many attributes.&lt;/p&gt;
&lt;p&gt;Okay. That&amp;#8217;s it for now.&lt;/p&gt;</description><link>http://blog.decogram.com/post/397357215</link><guid>http://blog.decogram.com/post/397357215</guid><pubDate>Thu, 18 Feb 2010 18:30:00 -0500</pubDate></item><item><title>Here’s a short video which shows the Lucyphone.com...</title><description>&lt;iframe src="http://player.vimeo.com/video/7401011" width="400" height="300" frameborder="0"&gt;&lt;/iframe&gt;&lt;br/&gt;&lt;br/&gt;&lt;p&gt;Here’s a short video which shows the Lucyphone.com experience.  We’re seeing customer service complaints at an all-time high, and there’s a real opportunity to streamline the call center process, and minimize aggravation.  Right now our objective is to proselytize the service to customer service managers, so that their CSR are familiar with the Lucyphone brand.  By being lucyphone-friendly, CSRs are starting their customer interactions with happier customers, so it’s a win-win for companies and consumers.  Give it a go with the “FLYCUB” beta invite, and let us know how your next customer-service call goes!&lt;/p&gt;</description><link>http://blog.decogram.com/post/246218742</link><guid>http://blog.decogram.com/post/246218742</guid><pubDate>Mon, 16 Nov 2009 13:30:53 -0500</pubDate></item><item><title>The Quest for Unmetered Bandwidth</title><description>&lt;p&gt;It&amp;#8217;s an auspicious day - a beautiful fall morning in Richmond, and I&amp;#8217;ve taken the train from Manhattan to meet my brother for our kickoff meeting and to jump into the remaining items before we launch the beta of our first product, LucyPhone.com&lt;/p&gt;
&lt;p&gt;We&amp;#8217;re still kicking around various beyond-beta business models, and in the process of moving our asterisk instances off the Amazon EC2 cloud and onto a dedicated VPS with unmetered bandwidth.  Anyone have experience with iWeb&amp;#8217;s service?  It seems there aren&amp;#8217;t many hosts that will offer unmetered bandwidth, but it&amp;#8217;s a must-have for us, as each of our calls is taking roughly 400kbps, and we&amp;#8217;ll be incurring way too much cost on the Amazon cloud.&lt;/p&gt;</description><link>http://blog.decogram.com/post/205507582</link><guid>http://blog.decogram.com/post/205507582</guid><pubDate>Mon, 05 Oct 2009 21:46:00 -0400</pubDate></item></channel></rss>

