wukong 3.0.0.pre → 3.0.0.pre2

data/docpages/avro/performance.textile

@@ -1,36 +0,0 @@
-
-
-h2. Bulk Streaming use cases
-
-* Take a bunch of nightly calculations and need to flood it into the DB -- http://sna-projects.com/blog/2009/06/building-a-1-tb-data-cycle-at-linkedin-with-hadoop-and-project-voldemort/ In this case, it's important that the bulk load happen efficiently but with low stress on the DB.  I'm willing to make it so that data streams to each cassandra node in the sort order and pre-partitioned just like the node wants to use it. Should run at the full streaming speed of the disk.
-
-* Building a new table or moving a legacy database over to cassandra.  I want to write from one or several nodes, probably not in the cluster, and data will be completely unpartitioned.  I might be able to make some guarantees about uniqueness of keys and rows (that is, you'll generally only see a key once, and/or when you see a key it will contain the entire row).  20k inserts/s / receiving node.
-
-* Using cassandra to replace HDFS. Replication is for compute, not for availability -- so efficient writing at consistency level ANY is important. Would like to get 100k inserts/s per receiving node. 
-
-* A brand new user wants to just stuff his goddamn data into the goddamn database and start playing with it. It had better be not-terribly-slow, and it had better be really easy to take whatever insane format it shows up in and cram that into the data hole.  It should also be conceptually straighforward: it should look like I'm writing hashes or hashes of hashes.
-
-
-===========================================================================
-From http://sna-projects.com/blog/2009/06/building-a-1-tb-data-cycle-at-linkedin-with-hadoop-and-project-voldemort/
-
-Here are the times taken:
-
-* 100GB: 28mins (400 mappers, 90 reducers)
-* 512GB: 2hrs, 16mins (2313 mappers, 350 reducers)
-* 1TB: 5hrs, 39mins (4608 mappers, 700 reducers)
-
-Data transfer between the clusters happens at a steady rate bound by the disk or network. For our Amazon instances this is around 40MB/second.
-
-Online Performance
-
-Lookup time for a single Voldemort node compares well to a single MySQL instance as well. To test this we ran local tests against the 100GB per-node data from the 1 TB test. This test as well was run on an Amazon Extra Large instance with 15GB of RAM and the 4 ephemeral disks in a RAID 10 configuration. To run the tests we simulated we simulated 1 million requests from a real request stream recorded on our production system against each of storage systems. We see the following performance for 1 million requests against a single node:
-	                 MySQL   	Voldemort
-Reqs per sec. 	         727    	1291
-Median req. time 	0.23 ms 	0.05 ms
-Avg. req. time   	13.7 ms 	7.7 ms
-
-99th percentile req. time
-	127.2 ms 	100.7 ms
-
-These numbers are both for local requests with no network involved as the only intention is to benchmark the storage layer of these systems.

data/docpages/avro/tethering.textile

@@ -1,19 +0,0 @@
-The idea is that folks would somehow write a Ruby application.  On startup, it starts a server speaking InputProtocol:
-
-http://svn.apache.org/viewvc/avro/trunk/share/schemas/org/apache/avro/mapred/tether/InputProtocol.avpr?view=markup
-
-Then it gets a port from the environment variable AVRO_TETHER_OUTPUT_PORT.  It connects to this port, using OutputProtocol, and uses the configure() message to send the port of its input server to its parent:
-
-http://svn.apache.org/viewvc/avro/trunk/share/schemas/org/apache/avro/mapred/tether/OutputProtocol.avpr?view=markup
-
-The meat of maps and reduces consists of the parent sending inputs to the child's with the input() message and the child sending outputs back to the parent with the output() message.
-
-If it helps any, there's a Java implementation of the child including a demo WordCount application:
-
-http://svn.apache.org/viewvc/avro/trunk/lang/java/src/test/java/org/apache/avro/mapred/tether/
-
-One nit, should you choose to accept this task, is that Avro's ruby RPC stuff will need to be enhanced.  It doesn't yet support request-only messages.  I can probably cajole someone to help with this and there's a workaround for debugging (switch things to HTTP).
-
-http://svn.apache.org/viewvc/avro/trunk/lang/ruby/lib/avro/ipc.rb?view=markup
-
-

data/docpages/bigdata-tips.textile

@@ -1,143 +0,0 @@
----
-layout: default
-title:  mrflip.github.com/wukong - Lessons Learned working with Big Data
-collapse: false
----
-
-h2. Random Thoughts on Big Data
-
-Stuff changes when you cross the 100GB barrier.  Here are random musings on why it might make sense to
-
-* Sort everything
-* Don't do any error handling
-* Catch errors and emit them along with your data
-* Make everything ASCII
-* Abandon integer keys
-* Use bash as your data-analysis IDE.
-
-h2(#dropacid). Drop ACID, explore Big Data
-
-The traditional "ACID quartet":http://en.wikipedia.org/wiki/ACID for relational databases can be re-interpreted in a Big Data context:
-
-* A -- Associative
-* C -- Commutative
-* I -- Idempotent
-* D -- Distributed
-* (*) -- (and where possible, left in sort order)
-
-Finally, where possible leave things in sort order by some appropriate index. Clearly I'm not talking about introducing extra unnecessary sorts on ephemeral data.  For things that will be read (and experimented with) much more often than they're written, though, it's worth running a final sort.  Now you can
-
-* Efficiently index into a massive dataset with binary search
-* Do a direct merge sort on two files with the same sort order
-* Run a reducer directly across the data
-* Assign a synthetic key by just serially numbering lines (either distribute a unique prefix to each mapper 
-
-Note: for files that will live on the DFS, you should usually *not* do a total sort, 
-
-h2. If it's not broken, it's wrong
-
-Something that goes wrong one in a five million times will crop up hundreds of times in a billion-record collection.
-
-h3. Error is not normally distributed
-
-What's more, errors introduced will not in general be normally distributed and their impact may not decrease with increasing data size.
-
-h3. Do your exception handling in-band
-
-A large, heavily-used cluster will want to have ganglia or "scribe":http://www.cloudera.com/blog/2008/11/02/configuring-and-using-scribe-for-hadoop-log-collection/ or the like collecting and managing log data.  "Splunk":http://www.splunk.com/ is a compelling option I haven't myself used, but it is "broadly endorsed.":http://www.igvita.com/2008/10/22/distributed-logging-syslog-ng-splunk/
-
-However, it's worth considering another extremely efficient, simple and powerful distributed system for routing massive quantities of data in a structured way, namely wukong|hadoop itself.
-
-Wukong gives you a BadRecord class -- just rescue errors, pass the full or partial contents of the offending input. and emit the BadRecord instance in-band.  They'll be serialized out along with the rest, and at your preference can be made to reduce to a single instance. Do analysis on them at your leisure; by default, any StructStreamer will silently discard *inbound* BadRecords -- they won't survive past the current generation.
-
-h2(#keys). Keys
-
-* Artificial key: assigned externally, key is not a function of the object's intrinsic values. A social security number is an artificial key. Artificial 
-
-* Natural Key: minimal subset of fields with _intrinsic semantic value_ that _uniquely identify_ the record. My name isn't unique, but my fingerprint is both uniqe and intrinsic.  Given the object (me) you can generate the key, and given the key there's exactly one object (me) that matches.
-
-h4. other fields
-
-* Mutable:
-** A user's 'bio' section.
-
-* Immutable: 
-** A user's created_at date is immutable: it doesn't help identify the person but it will never change.  
-
-h4. Natural keys are right for big data
-
-Synthetic keys suck. They demand locality or a central keymaster.
-
-* Use the natural key
-* Hash the natural key. This has some drawbacks
-
-OK, fine. you need a synthetic key
-
-* Do a total sort, and use nl
-* Generate
-* Use a single reducer to reduce locality. YUCK.
-* have each mapper generate a unique prefix; number each line as "prefix#{line_number}" or whatever.
-
-How do you get a unique prefix?
-
-* Distribute a unique prefix to each mapper out-of-band. People using Streaming are out of luck.
-
-* Use a UUID -- that's what they're for. Drawback: ridiculously long
-
-* Hash the machine name, PID and timestamp to something short. Check after the
-  fact that uniqueness was achieved. Use the birthday party formula to find out
-  how often this will happen. (In practice, almost never.)
-
-You can consider your fields are one of three types:
-
-* Key
-** natural: a unique username, a URL, the MD5 hash of a URL
-** synthetic: an integer generated by some central keymaster
-* Mutable:
-** eg A user’s ‘bio’ section.
-* Immutable:
-** A user’s created_at date is immutable: it doesn’t help identify the person but it will never change.
-
-The meaning of a key depends on its semantics. Is a URL a key?
-
-* A location: (compare: "The head of household residing at 742 Evergreen Terr, Springfield USA")
-* An entity handle (URI): (compare: "Homer J Simpson (aka Max Power)")
-* An observation of that entity: Many URLs are handles to a __stream__ -- http://twitter.com/mrflip names the resource "mrflip's twitter stream", but loading that page offers only the last 20 entries in that stream. (compare: "The collection of all words spoken by the residents of 742 Evergreen Terr, Springfield USA")
-  
-h2(#bashide). The command line is an IDE
-
-{% highlight sh %}
-  cat /data/foo.tsv | ruby -ne 'puts $_.chomp.scan(/text="([^"]+)"/).join("\t")'
-{% endhighlight %}
-
-h2(#encoding). Encode once, and carefully.
-
-Encoding violates idempotence.  Data brought in from elsewhere *must* be considered unparsable, ill-formatted and rife with illegal characters.
-
-* Immediately fix a copy of the original data with as minimal encoding as possible.
-* Follow this with a separate parse stage to emit perfectly well-formed, tab-separated / newline delimited data
-* In this parse stage, encode the data to 7-bits, free of internal tabs, backslashes, carriage return/line feed or control characters. You want your encoding scheme to be
-** perfectly reversible
-** widely implemented
-** easily parseable
-** recognizable: incoming data that is mostly inoffensive (a json record, or each line of a document such as this one) should be minimally altered from its original.  This lets you do rough exploration with sort/cut/grep and friends.
-** !! Involve **NO QUOTING**, only escaping.  I can write a simple regexp to decode entities such as %10, \n or &#10;. This regexp will behave harmlessly with ill-formed data (eg %%10 or &&; or \ at end of line) and is robust against data being split or interpolated.  Schemes such as "quoting: it's bad", %Q{quoting: "just say no"} or <notextile><notextile>tagged markup</notextile></notextile> require a recursive parser. An extra or missing quote mark is almost impossible to backtrack.  And av
-
-In the absence of some lightweight, mostly-transparent, ASCII-compatible *AND* idempotent encoding scheme lurking in a back closet of some algorithms book -- how to handle the initial lousy payload coming off the wire?
-
-* For data that is *mostly* text in a western language, you'll do well wiht XML encoding (with <notextile>[\n\r\t\\]</notextile> forced to encode as entities)
-* URL encoding isn't as recognizable, but is also safe. Use this for things like URIs and filenames, or if you want to be /really/ paranoid about escaping.
-* For binary data, Binhex is efficient enough and every toolkit can handle it.  There are more data-efficient ascii-compatible encoding schemes but it's not worth the hassle for the 10% or whatever gain in size.
-* If your payload itself is XML data, consider using \0 (nul) between records, with a fixed number of tab-separated metadata fields leading the XML data, which can then include tabs, newlines, or whatever the hell it wants. No changes are made to the data apart from a quick gsub to remove any (highly illegal) \0 in the XML data itself. A later parse round will convert it to structured hadoop-able data.  Ex:
-
-{% highlight html %}
-feed_request	20090809101112  200     OK      <?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html lang='en' xml:lang='en' xmlns='http://www.w3.org/1999/xhtml'>
-  <head>
-      <title>infochimps.org &mdash; Find Any Dataset in the World</title>
-{% endhighlight %}
-
-p. Many of the command line utilities (@cat@, @grep@, etc.) will accept nul-delimited files.
-
-You may be tempted to use XML around your XML so you can XML while you XML.  Ultimately, you'll find this can only be done right by doing a full parse of the input -- and at that point you should just translate directly to a reasonable tab/newline format. (Even if that format is tsv-compatible JSON).

data/docpages/code/api_response_example.txt

@@ -1,20 +0,0 @@
-[
-  { // TwitterUser
-    "id":123456789,
-    // Basic fields
-      "screen_name":"nena", "protected":false, "created_at":"Thu Apr 23 02:00:00 +0000 2009",
-      "followers_count":0, "friends_count":1, "statuses_count":1, "favourites_count":0,
-    // TwitterUserProfile fields
-      "name":"nena", "url":null, "location":null, "description":null,"time_zone":null,"utc_offset":null,
-    // TwitterUserStyle
-      "profile_background_color":"9ae4e8", "profile_text_color":"000000", "profile_link_color":"0000ff", "profile_sidebar_border_color":"87bc44", "profile_sidebar_fill_color":"e0ff92", "profile_background_tile":false,
-      "profile_background_image_url":"http:\/\/static.twitter.com\/images\/themes\/theme1\/bg.gif"
-      "profile_image_url":"http:\/\/s3.amazonaws.com\/twitter_production\/profile_images\/123456789\/crane_normal.JPG",
-    // with enclosed Tweet
-    "status": {
-      "id":123456789,
-      // the twitter_user_id is implied
-      "created_at":"Thu Apr 23 02:00:00 +0000 2009", "favorited":false, "truncated":false, "source":"web", 
-      "in_reply_to_user_id":null, "in_reply_to_status_id":null, "in_reply_to_screen_name":null
-      "text":"My cat's breath smells like cat food." },
-  },

data/docpages/code/parser_skeleton.rb

@@ -1,38 +0,0 @@
-# extract each record from request contents
-# and stream it to output
-class TwitterRequestParser < Wukong::Streamer::StructStreamer
-  def process request
-    request.parse do |obj|
-      yield obj
-    end
-  end
-end
-
-# Incoming Request:
-class TwitterFollowersRequest < Struct.new(
-    :url, :scraped_at, :response_code, :response_message, :moreinfo, :contents)
-  include Monkeyshines::ScrapeRequest
-end
-
-# Outgoing classes:
-class TwitterUser < TypedStruct.new( :id, :scraped_at, :screen_name, :protected, :created_at,
-    :followers_count, :friends_count, :statuses_count, :favourites_count )
-end
-class Tweet < TypedStruct.new(:id, :created_at, :twitter_user_id, :favorited, :truncated,
-    :text, :source, :in_reply_to_user_id, :in_reply_to_status_id, :in_reply_to_screen_name)
-end
-
-# Parsing code:
-TwitterFollowersRequest.class_eval do
-  include Monkeyshines::RawJsonContents
-  def parse &block
-    parsed_contents.each do |user_tweet_hash|
-      yield AFollowsB.new         user_tweet_hash["id"], self.moreinfo[:request_user_id]
-      yield TwitterUser.from_hash user_tweet_hash
-      yield Tweet.from_hash       user_tweet_hash
-    end
-  end
-end
-
-# This makes the script go.
-Wukong::Script.new(TwitterRequestParser, TwitterRequestUniqer).run

data/docpages/gem.css

@@ -1,16 +0,0 @@
-#header a       { color:            #00a;  }  
-hr              { border-color:     #66a ; }
-h2              { border-color:     #acc ; }
-h1              { border-color:     #acc ; }
-.download       { border-color:     #acc ; }
-#footer         { border-color:     #a0e0e8 ; }
-
-#header a       { margin-left:0.125em; margin-right:0.125em; }
-h1.gemheader {
-  margin:      -30px 0 0.5em -65px ; 
-  text-indent:                65px ; 
-  height:       90px ;
-  padding:      50px 0 10px 0px; 
-  background:   url('/images/wukong.png') no-repeat 0px 0px ;
-  }
-.quiet          { font-size: 0.85em ; color: #777 ; font-style: italic }

data/docpages/hadoop-tips.textile

@@ -1,83 +0,0 @@
----
-layout: default
-title:  mrflip.github.com/wukong - NFS on Hadoop FTW
-collapse: false
----
-
-h2. Hadoop Config Tips
-
-h3(#hadoopnfs). Setup NFS within the cluster
-
-If you're lazy, I recommend setting up NFS -- it makes dispatching simple config and script files much easier. (And if you're not lazy, what the hell are you doing using Wukong?).  Be careful though -- used unwisely, a swarm of NFS requests will mount a devastatingly effective denial of service attack on your poor old master node.
-
-Installing NFS to share files along the cluster gives the following conveniences:
-* You don't have to bundle everything up with each run: any path in ~coder/ will refer back via NFS to the filesystem on master.
-* The user can now passwordless ssh among the nodes, since there's only one shared home directory and since we included the user's own public key in the authorized_keys2 file.  This lets you easily rsync files among the nodes.
-
-First, you need to take note of the _internal_ name for your master, perhaps something like @domU-xx-xx-xx-xx-xx-xx.compute-1.internal@.
-   
-As root, on the master (change @compute-1.internal@ to match your setup):
-
-<pre>
-    apt-get install nfs-kernel-server 
-    echo "/home *.compute-1.internal(rw)" >> /etc/exports ;
-    /etc/init.d/nfs-kernel-server stop ;
-</pre>
-
-(The @*.compute-1.internal@ part limits host access, but you should take a look at the security settings of both EC2 and the built-in portmapper as well.)
-
-Next, set up a regular user account on the *master only*. In this case our user will be named 'chimpy':
-
-<pre>
-  visudo # uncomment the last line, to allow group sudo to sudo
-  groupadd admin 
-  adduser chimpy
-  usermod -a -G sudo,admin chimpy
-  su chimpy                  # now you are the new user
-  ssh-keygen -t rsa          # accept all the defaults
-  cat ~/.ssh/id_rsa.pub      # can paste this public key into your github, etc
-  cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
-</pre>    
-
-Then on each slave (replacing domU-xx-... by the internal name for the master node):
-
-<pre>
-    apt-get install nfs-common ;
-    echo "domU-xx-xx-xx-xx-xx-xx.compute-1.internal:/home  /mnt/home  nfs  rw  0 0"  >> /etc/fstab
-    /etc/init.d/nfs-common restart
-    mkdir /mnt/home
-    mount /mnt/home
-   ln -s /mnt/home/chimpy /home/chimpy
-</pre>
-
-You should now be in business. 
-
-Performance tradeoffs should be small as long as you're just sending code files and gems around.  *Don't* write out log entries or data to NFS partitions, or you'll effectively perform a denial-of-service attack on the master node.
-
-* http://nfs.sourceforge.net/nfs-howto/ar01s03.html
-* The "Setting up an NFS Server HOWTO":http://nfs.sourceforge.net/nfs-howto/index.html was an immense help, and I recommend reading it  carefully.
-
-h3(#awstools). Tools for EC2 and S3 Management
-
-* http://s3sync.net/wiki
-* http://jets3t.s3.amazonaws.com/applications/applications.html#uploader
-* "ElasticFox"
-* "S3Fox (S3 Organizer)":
-* "FoxyProxy":
-
-
-h3. Random EC2 notes
-
-* "How to Mount EBS volume at launch":http://clouddevelopertips.blogspot.com/2009/08/mount-ebs-volume-created-from-snapshot.html
-
-* The Cloudera AMIs and distribution include BZip2 support.  This means that if you have input files with a .bz2 extension, they will be naturally un-bzipped and streamed. (Note that there is a non-trivial penalty for doing so: each bzip'ed file must go, in whole, to a single mapper; and the CPU load for un-bzipping is sizeable.)
-
-* To _produce_ bzip2 files, specify the @--compress_output=@ flag. If you have the BZip2 patches installed, you can give @--compress_output=bz2@; everyone should be able to use @--compress_output=gz@.
-
-* For excellent performance you can patch your install for "Parallel LZO Splitting":http://www.cloudera.com/blog/2009/06/24/parallel-lzo-splittable-compression-for-hadoop/
-
-* If you're using XFS, consider setting the nobarrier option
-    /dev/sdf  /mnt/data2    xfs     noatime,nodiratime,nobarrier    0 0
-
-* The first write to any disk location is about 5x slower than later writes. Explanation, and how to pre-soften a volume, here: http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?instance-storage.html
-

data/docpages/index.textile

@@ -1,92 +0,0 @@
----
-layout: default
-title:  mrflip.github.com/wukong
-collapse: true
----
-h1(gemheader). wukong %(small):: hadoop made easy%
-
-p(description). {{ site.description }}
-
-Treat your dataset like a
-* stream of lines when it's efficient to process by lines
-* stream of field arrays when it's efficient to deal directly with fields
-* stream of lightweight objects when it's efficient to deal with objects
-
-Wukong is friends with "Hadoop":http://hadoop.apache.org/core the elephant, "Pig":http://hadoop.apache.org/pig/ the query language, and the @cat@ on your command line. 
-
-Send Wukong questions to the "Infinite Monkeywrench mailing list":http://groups.google.com/group/infochimps-code
-
-<notextile><div class="toggle"></notextile>
-
-h2. Documentation index
-
-* "Install and set up wukong":INSTALL.html
-** "Get the code":INSTALL.html#getcode
-** "Setup":INSTALL.html#setup
-** "Installing and Running Wukong with Hadoop":INSTALL.html#gethadoop
-** "Installing and Running Wukong with Datamapper, ActiveRecord, the command-line and more":INSTALL.html#others
-
-* "Tutorial":tutorial.html
-** "Count Words":tutorial.html#wordcount
-** "Structured data":tutorial.html#structstream
-** "Accumulators":tutorial.html#accumulators including a UniqByLastReducer and a GroupBy reducer.
-
-* "Usage notes":usage.html
-** "How to run a Wukong script":usage.html#running
-** "How to test your scripts":usage.html#testing
-** "Wukong Plays nicely with others":usage.html#playnice
-** "Schema export":usage.html#schema_export to Pig and SQL
-** "Using wukong with internal streaming":usage.html#stayinruby
-** "Using wukong to Batch-Process ActiveRecord Objects":usage.html#activerecord
-
-* "Wutils":wutils.html -- command-line utilies for working with data from the command line
-** "Overview of wutils":wutils.html#wutils -- command listing
-** "Stupid command-line tricks":wutils.html#cmdlinetricks using the wutils
-** "wu-lign":wutils.html#wulign -- present a tab-separated file as aligned columns
-** Dear Lazyweb, please build us a "tab-oriented version of the Textutils library":wutils.html#wutilsinc
-
-* Links and tips for "configuring and working with hadoop":hadoop-tips.html
-* Some opinionated "thoughts on working with big data,":bigdata-tips.html on why you should drop acid, treat exceptions as records, and happily embrace variable-length strings as primary keys.
-* Wukong is licensed under the "Apache License":LICENSE.html (same as Hadoop)
-
-* "More info":moreinfo.html
-** "Why is it called Wukong?":moreinfo.html#name
-** "Don't Use Wukong, use this instead":moreinfo.html#whateverdude
-** "Further Reading and useful links":moreinfo.html#links
-** "Note on Patches/Pull Requests":moreinfo.html#patches
-** "What's up with Wukong::AndPig?":moreinfo.html#andpig
-** "Map/Reduce Algorithms":moreinfo.html#algorithms
-** "TODOs":moreinfo.html#TODO                
-
-* Work in progress: an intro to data processing with wukong:
-** "Part 1, Get Ready":UsingWukong-part1-getready.html
-** "Part 2, Thinking Big Data":UsingWukong-part2-ThinkingBigData.html
-** "Part 3, Parsing":UsingWukong-part3-parsing.html
-
-<notextile></div></notextile>
-
-{% include intro.textile %}
-
-<notextile><div class="toggle"></notextile>
-
-h2. Credits
-
-Wukong was written by "Philip (flip) Kromer":http://mrflip.com (flip@infochimps.org / "@mrflip":http://twitter.com/mrflip) for the "infochimps project":http://infochimps.org
-
-Patches submitted by:
-* gemified by Ben Woosley (ben.woosley@gmail.com)
-* ruby interpreter path fix by "Yuichiro MASUI":http://github.com/masuidrive - masui@masuidrive.jp - http://blog.masuidrive.jp/
-
-Thanks to:
-* "Brad Heintz":http://www.bradheintz.com/no1thing/talks/ for his early feedback
-* "Phil Ripperger":http://blog.pdatasolutions.com for his "wukong in the Amazon AWS cloud":http://blog.pdatasolutions.com/post/191978092/ruby-on-hadoop-quickstart tutorial.
-
-<notextile></div><div class="toggle"></notextile>
-
-h2. Help!
-
-Send Wukong questions to the "Infinite Monkeywrench mailing list":http://groups.google.com/group/infochimps-code
-
-<notextile></div></notextile>
-
-{% include news.html %}