From alexguha at yahoo.com Wed Feb 3 16:58:36 2010 From: alexguha at yahoo.com (Aloke Guha) Date: Wed, 3 Feb 2010 13:58:36 -0800 (PST) Subject: [Boulder Ruby Group] Looking for experienced RoR developer for short term project Message-ID: <58785.85335.qm@web36306.mail.mud.yahoo.com> We are looking for senior RoR developer who can work on an intense short term project. Based on the results, the project may be extended to a longer term contract. In-depth experience in the entire RoR stack, developing scalable web apps, PHP, Java, MySQL (and MS SQL) are a plus, as well as having done Agile software development. -- Aloke -------------- next part -------------- An HTML attachment was scrubbed... URL: From mghaught at gmail.com Thu Feb 4 22:00:35 2010 From: mghaught at gmail.com (Marty Haught) Date: Thu, 4 Feb 2010 20:00:35 -0700 Subject: [Boulder Ruby Group] BRG - February Meeting - Feb 16th Message-ID: <57f29e621002041900v77680dc8j87f7c1f375ec2b9a@mail.gmail.com> After some thought, we're going to be moving our official meeting night from the third Wednesday to the third Tuesday of the month. We've had a number of folks come out on Tuesday that haven't been able to before and Tuesday night seems to have less conflicts with other groups in the area. Our February meeting will be on Tuesday the 16th at 7pm. We've got a full slate that night with Paul Sadauskas presenting on HTTP, a talk he'll be giving at MountainWest RubyConf in March. Following him Tiffany Fodor and Charley Baker will be doing a joint presentation on WATIR, a ruby-driven framework for automating the browser. See you all in a couple of weeks. Cheers, Marty Haught http://boulderruby.org From JOSH at MULTIPART-MIXED.COM Wed Feb 10 13:46:30 2010 From: JOSH at MULTIPART-MIXED.COM (Josh Carter) Date: Wed, 10 Feb 2010 11:46:30 -0700 Subject: [Boulder Ruby Group] memcache-client issues, looking for other ideas Message-ID: Ruby Kung-Fu Masters, I've got a product that does a lot of inter-process work between a Rails app and multiple slave processes, some of which are running on the same machine and some on other machines. It's not high-load and nothing we're doing is rocket science. However, I'm having problems with memcache-client IO timeouts even on the latest versions of the gem, and even with SystemTimer gem installed. I've had enough trouble that I'm rethinking using memcache at all; to that end I'm rethinking *all* of the data storage the application is doing. Right now I've got: - MySQL: storing persistent data, but not much. - memcache: storing transient data, again not a lot and not a high transaction rate. - beanstalk: used as a job queue to communicate between processes, job details are stored in memcache. When I say "transient" above I mean the data doesn't need to survive a reboot, but because it's used for inter-process communication it does need to stay alive when the processes are alive. It's not just a disposable cache where I can refer to the database when memcache-client barfs. I believe I could replace all three with MySQL but that seems pretty heavy-handed for transient data that I don't want hitting disk. (If the disk access was a real problem I could create a RAM disk for the transient tables.) In general, however, MySQL is already overkill for our uses and I'd like to get our RAM footprint down. So my question for the group is: does anyone have recommendations and first-hand experience with a lightweight database that would meet these needs? This is an embedded environment so stuff like Amazon S3+SQS isn't an option, though clearly our data path is modeled after S3+SQS practices. Thanks and best regards, Josh From ara.t.howard at gmail.com Sun Feb 14 19:04:34 2010 From: ara.t.howard at gmail.com (ara.t.howard) Date: Sun, 14 Feb 2010 17:04:34 -0700 Subject: [Boulder Ruby Group] memcache-client issues, looking for other ideas In-Reply-To: References: Message-ID: <2524b8cc1002141604v158acf7ay8aa8767b9de374e0@mail.gmail.com> On Wed, Feb 10, 2010 at 11:46, Josh Carter wrote: > So my question for the group is: does anyone have recommendations and first-hand experience with a lightweight database that would meet these needs? prove that your database is too slow first. then prove that you cannot optimize it to be faster - all of mysql, postgresql, oracle, sqlite, etc support pure memory tables - which should perform extremely fast and require 0 extra setup. if you *still* have issues there are lot of alternatives, but i doubt you will have issues if you look deeply into tweaking your current db to support your usage pattern for a subset of it's relations. -- -a -- be kind whenever possible... it is always possible - h.h. the 14th dalai lama From mghaught at gmail.com Mon Feb 15 16:58:59 2010 From: mghaught at gmail.com (Marty Haught) Date: Mon, 15 Feb 2010 14:58:59 -0700 Subject: [Boulder Ruby Group] BRG - February Meeting Reminder - Feb 16th Message-ID: <57f29e621002151358y5fc2610cj97efd831b80e722@mail.gmail.com> Here's the next day reminder for Boulder Ruby's February meeting on Tuesday Feb 16th at 7pm. We'll be meeting in our usual digs, Collective Intellect (directions below). We'll kick off the evening with our usual hanging out while folks filter in. Paul Sadauskas will give the first talk, presenting on HTTP, a talk he'll be giving at MountainWest RubyConf in March. Following him Tiffany Fodor and Charley Baker will be doing a joint presentation on WATIR, a ruby-driven framework for automating the browser. I look forward to seeing everyone tomorrow night. Cheers, Marty Haught http://boulderruby.org Directions: Collective Intellect 1433 Pearl St, Suite 200 Boulder, CO 80302 The office is behind and above Starbucks on Pearl. The entrance is on Pearl Street just east of Starbucks, behind the statue of the wolf. Come straight through all the doors. We meet on the second floor so take the elevator or if the doors are open, the stairway inside Collective Intellect. URL to google maps: http://rubyurl.com/pKfB From JOSH at multipart-mixed.com Tue Feb 16 12:22:17 2010 From: JOSH at multipart-mixed.com (Josh Carter) Date: Tue, 16 Feb 2010 10:22:17 -0700 Subject: [Boulder Ruby Group] memcache-client issues, looking for other ideas In-Reply-To: <2524b8cc1002141604v158acf7ay8aa8767b9de374e0@mail.gmail.com> References: <2524b8cc1002141604v158acf7ay8aa8767b9de374e0@mail.gmail.com> Message-ID: <1389F3A2-71BF-42D8-B784-C9F526348708@multipart-mixed.com> Ara, I completely agree with you on the general point. However, I'm not concerned with speed so much as where the data lives. This is a server/storage system that should only have the user's data on the main disk, and I'm planning to move the boot filesystem to CompactFlash. Therefore I want to get data either to memory (for transient stuff) or to specific locations on disk (probably simple YAML files) since I really don't need the full features of a database. On the memory side, I tried redis [1] at the suggestion of another list member (thanks Gabe!) and so far it's great. It replaces memcache directly--simple get/put of key/value pairs--but it also provides atomic list operations and therefore replaces beanstalk (the queuing system) as well. It was trivial to rewrite my own job queue system on redis. I also took the opportunity to remove direct references to memcache in our code base and replace them with a generic KeyValueStore class; that way if redis doesn't cut the mustard I can switch to database tables with little trouble. Best regards, Josh [1]: http://code.google.com/p/redis/ On Feb 14, 2010, at 5:04 PM, ara.t.howard wrote: > On Wed, Feb 10, 2010 at 11:46, Josh Carter wrote: >> So my question for the group is: does anyone have recommendations and first-hand experience with a lightweight database that would meet these needs? > > prove that your database is too slow first. then prove that you > cannot optimize it to be faster - all of mysql, postgresql, oracle, > sqlite, etc support pure memory tables - which should perform > extremely fast and require 0 extra setup. > > if you *still* have issues there are lot of alternatives, but i doubt > you will have issues if you look deeply into tweaking your current db > to support your usage pattern for a subset of it's relations. > > -- > -a > -- > be kind whenever possible... it is always possible - h.h. the 14th dalai lama > _______________________________________________ > Bdrg-members mailing list > Bdrg-members at rubyforge.org > http://rubyforge.org/mailman/listinfo/bdrg-members From ara.t.howard at gmail.com Tue Feb 16 13:10:40 2010 From: ara.t.howard at gmail.com (ara.t.howard) Date: Tue, 16 Feb 2010 11:10:40 -0700 Subject: [Boulder Ruby Group] memcache-client issues, looking for other ideas In-Reply-To: <1389F3A2-71BF-42D8-B784-C9F526348708@multipart-mixed.com> References: <2524b8cc1002141604v158acf7ay8aa8767b9de374e0@mail.gmail.com> <1389F3A2-71BF-42D8-B784-C9F526348708@multipart-mixed.com> Message-ID: <2524b8cc1002161010g4836cc68ldd1beb3c2fbfac9a@mail.gmail.com> On Tue, Feb 16, 2010 at 10:22, Josh Carter wrote: > On the memory side, I tried redis [1] at the suggestion of another list member (thanks Gabe!) and so far it's great. It replaces memcache directly--simple get/put of key/value pairs--but it also provides atomic list operations and therefore replaces beanstalk (the queuing system) as well. It was trivial to rewrite my own job queue system on redis. > > I also took the opportunity to remove direct references to memcache in our code base and replace them with a generic KeyValueStore class; that way if redis doesn't cut the mustard I can switch to database tables with little trouble redis is indeed a great way to go. mongo is a viable one too. glad it's working! -- -a -- be kind whenever possible... it is always possible - h.h. the 14th dalai lama From joshua at opscode.com Tue Feb 16 21:25:42 2010 From: joshua at opscode.com (Joshua Timberman) Date: Tue, 16 Feb 2010 19:25:42 -0700 Subject: [Boulder Ruby Group] Chef training Message-ID: As I mentioned in the meeting tonight, Opscode will offer training for Chef "soon." For more information, see: http://www.opscode.com/training From mlawless at trada.com Thu Feb 18 12:56:25 2010 From: mlawless at trada.com (Michael Lawless) Date: Thu, 18 Feb 2010 10:56:25 -0700 Subject: [Boulder Ruby Group] Trada is looking for a Ruby/Rails genius Message-ID: Trada is a Boulder based startup looking to add a strong Ruby developer to our already experienced (and successful) team. We've got a ton of opportunity for a passionate developer to autonomously build some pretty cool functionality in our paid search advertising marketplace. Ideal candidates will be awesome. They might like front end (presentation layer) development more than other dev work. They must like working with fun people on complex software challenges. They probably think they are really good at developing Ruby code but don't mention it much to others. Send and e-mail to mlawless at trada.com if you are interested - or pass this along to others who might be good fits. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at graysoftinc.com Mon Feb 22 11:14:52 2010 From: james at graysoftinc.com (James Edward Gray II) Date: Mon, 22 Feb 2010 10:14:52 -0600 Subject: [Boulder Ruby Group] [ANN] Red Dirt RubyConf Message-ID: Hello Boulder Rubyists. (I have so many friends in this group I feel like I ought to be a member.) I just wanted to make sure you have all heard about the upcoming Red Dirt RubyConf (http://reddirtrubyconf.com/), in Oklahoma City on May 6th and 7th. I'm often up your way visiting family, so I can tell you it's less than a day's drive and the flight is under two hours. I hope you'll consider coming down and helping us to kick Red Dirt RubyConf off to a good start. We're trying some new tactics with the program, by dividing speeches into current hot topics and classic standbys. This allows us to have focused trainings that will match the content, do Q&A with the whole panel of speakers from the topic, and more. We hope you find that as exciting as we do and want to be a part of our fresh lineup. If you would be willing to share ideas, please consider submitting proposals. We could still use some speeches for our Rails 3 and Server themes, so those are a great areas to submit in. We're accepting proposals now and will be until the end of this month. Please let me know if I can answer any questions for you and we hope to see you all in Oklahoma in May! James Edward Gray II