Meeting notes, July 2011
Jesse Hallett
Rubinius will have Ruby 1.9 support in 2.0-pre and Engine Yard will be
opening a Portland Office soon. Brian Ford is working on implementing
a hashed array-mapped trie - yes, you can implement fancy data
structures in Ruby too! Also Rubinius 1.2.4 was just released.
Crowd Compass, a Portland startup, is hiring.
Sweet Spot Diabetes Care, another Portland startup, is also hiring.
Legion of Tech is working on organizing workshops to teach programming
<https://groups.google.com/forum/#!forum/lot-workshops>. RailsBridge
is also looking for people to teach Ruby and Rails to people who don't
have a lot of educational opportunities or who need work
<http://railsbridge.org/>. Talk to Christie Koehler or Reid Beels
about the Legion of Tech effort, or talk to Brian Ford about the
RailsBridge effort.
Daniel Johnson asks, what is the best way to deploy Calagator? Reid
says that there are still some obstacles to running Calagator on
Heroku - for example Calagator currently requires a writable
filesystem. It also requires an indexing service, such as Solr, if
you choose to configure Calagator to use such a service. Calagator
has a pluggable search backend and does offer a basic in-process
search index based on SQL. However Sunspot is the recommended
backend.
Unicorn used to be the cool way to deploy - but now Passenger is the
hot thing again with Passenger 3. Rainbows is another option, which
is similar to Unicorn, but which uses threads as workers instead of
using processes.
Maglev, the Ruby implementation: transactional memory, persistent
objects that are shared between processes. Jesse Cooke tells us more.
Maglev.abort_transaction # clears local changes to shared Ruby
objects and gets updates from the shared database
Maglev.commit_transaction # sends local changes to the shared
database - an optimistic locking exception may occur
You can store Proc objects in a persistent queue. This makes it easy
to build a simple message queue.
Maglev::PERSISTENT_ROOT[:q] ||= []
Maglev::PERSISTENT_ROOT[:q] << Proc.new { ... }
# later
work = Maglev::PERSISTENT_ROOT[:q].shift
Why are Maglev transactions not expressed as blocks? Idiomatic Ruby
prefers the loan/borrower pattern. Since the Maglev transaction
operations lock the entire object space of a Ruby process, the Maglev
team found that stateful "begin" and "end" methods made more sense.
Maglev uses optimistic locking out of the box. An option for
pessimistic locking of specific objects instead is in the works.
Maglev never serializes objects. Instead it writes entire memory pages to disk.
It is important to remember that an operation like Array#shift is not
atomic and is therefore not thread-safe. In JRuby and Rubinius this
means that you have to use explicit locking around such an operation.
In Maglev transactions provide atomicity, so you don't have to worry
about whether the operations within the transaction are atomic.
Either way, you have to put something around operations that are not
thread-safe.
Monty says that optimistic locking can be advantagous in a system with
lots of moving parts because most operations that run in parallel do
not operate on the same object at the same time. Maglev tracks
conflicts at the object level - two transactions in different
processes will not trigger a conflict unless code in both transactions
accessed the same object and at least one of the transactions modified
the object.
You have to handle conflicts either up front or after the fact.
Pessimistic locking is the up-front approach. Transactional memory
with optimistic locking handles the conflict after the fact.
Differences in approaches to concurrency are apparently a
controversial topic among language developers.
Jesse pointed out Celluloid, which is a "concurrent object framework"
for Ruby <http://www.unlimitednovelty.com/2011/05/introducing-celluloid-concurrent-object.html>.
Lock-Free Data Structures is a good paper on designing for concurrency
- it comes recommended by Brian Ford
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.3363&rep=rep1&type=pdf>.
Jesse also +1'd this.
Brian says that if you are interested in data structures and
concurrency, he would like you to help build the foundation for Ruby's
multithreading future. The Ruby structures that we know and love,
like Array, are not thread-safe by design. There is a lot of work
that needs to be done to support applications that use native threads
without a global interpreter lock (GIL).
Sam Livingston-Gray talks about a graph traversal problem presented by
Pedalpalooza 2011 <http://github.com/geeksam/ladds_graph>. Bicyclists
got points for traversing street segments in Ladd's Addition but lost
points for repeating segments. Riders must also begin and end their
routes in the circle in the center of Ladd's Addition. Sam's Github
repository has code for finding good routes, and also has resources
for studying the problem yourself.
Leif Warner shows us <http://schema.org/docs/schemas.html>. This site
codifies microformats that can be implemented in the form of HTML
markup.
http://id.loc.gov/ - RDF graphs of materials in the Library of
Congress. Alternative formats, such as JSON, are also available.
RDF.rb is a Ruby library for parsing microformats and RDF data
<http://rdf.rubyforge.org>. It will traverse links from page to page
for you.
In RDFa pages themselves are RDF entities. Fully-qualified URIs are
used to identify entities. The whole web is turning into one big
graph database.
The reuslts of the Ruby Brigade survey are in. Sam gives us a
summary. Reasons people gave for not attending meetings included a
complaint about spending more time on introductions than on hard
content, a complaint that topics are too high-level, difficulty making
the trip to the meeting, and several regrets from people who have
moved away from Portland.
Find resources for following the Ruby Brigade on pdxruby.org,
including links to the mailing list and the @pdxruby Twitter account.
Jesse Cooke
Holy shit those are some awesome notes Jesse. Thanks!
@jc00ke
n-tier engineer
> You received this message because you are subscribed to the Google Groups "pdxruby" group.
> To post to this group, send email to pdx...@googlegroups.com.
> To unsubscribe from this group, send email to pdxruby+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pdxruby?hl=en.
>
Peter McLain
On Jul 5, 2011, at 11:36 PM, Jesse Hallett wrote:
> Maglev, the Ruby implementation: transactional memory, persistent
> objects that are shared between processes. Jesse Cooke tells us more.
I liked Jesse's example so much, and it seemed like not everyone in the room really understood MagLev, that I thought I'd take the opportunity (with Jesse's permission) to expand on Jesse's presentation in a blog post:
http://maglevity.wordpress.com/2011/07/08/simple-worker-queue-with-procs-in-maglev/
I also thought Brian Ford's comments about the dangers of Array#shift in truly concurrent rubies (Rubinius and JRuby) was interesting, and might write up some more comments on that as well, if there is interest.
--
Peter McLain
peter....@gmail.com
Jesse Cooke
--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke
John Wilger
young kids and living in Forest Grove, this was very much appreciated.
Not the same as being there, but enough to get a sense of what people
are working on/interested in locally. Thanks, Jesse!
>> for Ruby <http://www <http://www.unlimitednovelty.com/2011/05/introducing-celluloid-concurrent-object.html>
--
Regards,
John Wilger
markus
> ...As someone who doesn't frequent the meetings due to having
> young kids and living in Forest Grove,...
Hmmm. So how many rubyists with young kids living in Forest Grove are
there? Is it just the two of us, or are there more lurking out there?
What if we count folks with cats in Cornelious? Anyone from Verboort?
-- M
Phil Tomson
Forest Grove is apparently a hotbed of Ruby activity. Maybe time to
start an Extreme-Westside Programmers group.
Phil
Jesse Cooke
Is Verboort in The Netherlands?
Phil Tomson
> Is Verboort in The Netherlands?
>
May as well be.
phil