Happy to say that the Ruby 1.8.7 RPM has been community vetted, is in rawhide, and is scheduled to go into Fedora 14. Many thanks to all those on ruby-sig for their efforts.

Attached are some updated Rails 2.3.8 srpms which address most of the issues that I could find when updating. They entail the rebased upstream sources and handle any discrepancies between the versions. With any luck these should be pretty close to being good to go and are ready for testing and the eventual push into Fedora.

activesupport, activerecord, actionpack, actionmailer, activeresource, rails

Have at it!

Took a trip with the family to Cape Cod this past weekend. It wasn't my first time there, I went a couple of times when I was younger, but it was the first in at least 10 years.

While I brought my camera, I regret not taking more pictures of the beautiful scenery. I only grabbed a couple of snapshots at the last beach we went to, Nauset Light Beach right before leaving. Regardless, I highly recommend the cape for a vacation, there are some gorgeous beaches and plenty to do for people of all ages.

Enjoy!

Attached is the presentation I have prepared in both openoffice and text formats.

Before I get to rails, note that an updated Ruby 1.8.7 srpm is now available. The latest 1.8.7 release tarball is now being used (p299), there are many fixes and improvements, and its pretty close to the final version which will be pushed into Fedora (of course any and all feedback and additional improvements are more than welcome). Many thanks go out to Jim Meyering and Mamoru Tasaka for all their hard work and help to get to this point.

I'm also pleased to announce new Ruby on Rails rpms (built against Ruby 1.8.7) corresponding to the 2.3.8 and 3.0.0.beta4 Rails releases. Admittedly these will most likely require additional tweaking to resolve any issues as they are discovered, but what's there should be the complete Rails suite packaged and ready to deploy. Feedback for any / all of these packages would also be much appreciated.

Without further ado, here is the Rails 2.3.8 suite:
activesupport: srpm rpm
activerecord: srpm rpm
actionpack: srpm rpm
actionmailer: srpm rpm
activeresource: srpm rpm
rails: srpm rpm

And here is the the Rails 3.0.0.beta4 suite:
activesupport: srpm rpm
activerecord: srpm rpm
actionpack: srpm rpm
actionmailer: srpm rpm
activeresource: srpm rpm
rails: srpm rpm

Also note you will need an updated sqlite3-ruby rpm to build either set, which I provide here (rpm here).

Enjoy!

Sometimes the simplest things will slip by you for the longest time.

After time after time of trying to find a definitive list of macros available for use in RPM specfiles on the Internet, I finally read the rpmbuild man page just to find the '--showrc' option. From the docs:

The command rpmbuild --showrc shows the values rpmbuild will use for all of the options are currently set in rpmrc and macros configuration file(s).

Now I can easily run rpmbuild --showrc and grep the output for whatever I'm looking for.

Doy! :-p

The first annual FOSSCon was great. I attended many interesting talks, met many interesting people working on many cool projects, and had fun overall.

The first two presentations I attended were titled "Making the most out of Communities" and "So you started an open source project, now what". Even though I have worked on many FOSS projects, I was surprised about how much I learned and picked up relating to forming and interacting w/ communities. Some things I picked up relating to community engineering were (in no particular order):

• Always identify the exact needs of your community as well as exactly what you need. You may not need more developers, but rather bug reporters or translators, or perhaps you need something else all together.
• Offer many suggestions / ways for people to get involved, but don't box people in, encourage your users to use and modify your product as they see fit, to meet their needs.
• Offer the lowest barrier to entry to get people involved. Perhaps its better not to fix that simple bug if it's not blocking anyone. Document it and wait for a new developer to submit the one line fix that can be pushed quickly, so they can see immediate results.
• Foster strong personal relationships w/ your users (so they are not shy about contributing). jboss.org had a slideshow of pics of all the developers for example, just to add that personal touch.
• Along with that, don't be a stranger, be sociable and personal (podcasts are great ways for status updates as they add a human element)
• Still going along with that, the 'California Ecosystem' is something worth looking into. Out west people are not ashamed to discuss the projects they are working on, and just by wandering around you can overhear many different interesting project conversations. I actually noticed this myself when I visited my friend in San Jose a couple years back, on the Caltrain into SanFran I overheard many engineers at many big tech firms discussing various projects. In many other parts of the world, people are more closed and you have to go out of your way to find information and happenings.
• Inexperienced devs can be a good thing. They often get more excited about small / trivial changes that they make (more so than experienced devs who just see them as additional patches), and are more keen on picking up your development practices and standards.
• Be polite about rejections, always try to offer suggestions and directions as to how to change the rejected submissions so that they make it in
• Try to attract only as many devs as you need and can handle. Yes more developers means more code, but it also means a whole lot more community engineering
• Be honest about your community management practices. Even if you are engaging in "social engineering" to get what you need out of your community projects, your devs and users will appreciate honesty more than trying to hide it
• Frame your needs well, word tasks as interesting problems which contributers should come up w/ their own solutions
• Make the first day the best day for new contributers so they keep coming back. Offer the lowest learning curve, but don't be overly helpful, encourage self-discovery and engineering. Express an interest in their needs and wants, see where they would be best fit.
• Shameless self promotions are good, discuss what your working on, get people interested
• Try to diversify your goals while trying to avoid feature creep. If something is rejected, suggest direction to go, determine priority (possibly add to roadmap for later), make sure the vetting process is transparent w/ multiple people involved, and if it comes down to it, don't be afraid of forks.
• "respect is an important currency in the community"

After the first two talks, I spent some time in the vendor hall checking out the different projects being represented, especially the OLPC exhibit. There I spent a while talking to the RIT students working on the OLPC, discussing how they are helping to develop and promote the platform, and how they envision using it to teach students. Needless to say I was very impressed not only by the additions to the OLPC platform itself but also by the very talented students working on it and I wish them all the best on the road ahead.

Next I attended the POSSE (Professors' Open Source Summer Experience) Panel where there was a phenomenal discussion pertaining to how to best bring open source to education, and how to best teach it. It was really a great discussion, with everyone contributing with their own experiences and thoughts and we really came up with some good ideas as to how to get more students involved, lower the barrier for students to quickly start and contribute to existing open projects, and some practical ways to solve these issues. This panel got me more interested in thinking about how to bring open source technologies to schools, including my alma-mata, Syracuse University, and I hope to help work towards getting more involved in bringing open source to education.

Finally I attended the lightning round discussions where many projects people were working on were promoted as well as new features in many major software packages demoed. After the closing keynote, me and my friends that I came with grabbed some food at a great Thai restaurant and then it was back to Syracuse. Overall it was an amazing conference and I look forward to FOSScon next year.

I'm in the process with several other individuals in the area of trying to form a Hackerspace for the Syracuse region. Hackerspaces have been successful in smaller cities than Syracuse, so there is no reason we shouldn't be able to get it going, but like many new ventures, we are having some trouble getting it off the ground, namely raising enough funds / pledges to pay for the minimum setup we need. We already found a suitable location for the group, but obviously anything is out of the question without enough rent money, and I was just wondering if anyone had any tip / tricks / advice to give pertaining to getting these going and raising enough funds to pay for the day to day operations.

If you've got any tidbits to add feel free to leave a comment here or send me an email, and if your interested in staying up to date with the discussion pertaining to the Hackerspace, shout out and I'll add you to the mailing list we currently have. Also be sure to check out the preliminary site I put together for the group.

For those that are interested, I managed to cobble the Ruby 1.8.6 and 1.9.1 spec files together to form a Ruby 1.8.7 rpm (srpm here) built against Fedora 11 (yes I really need to update to F13, just haven't had the cycles yet). It's not 100% perfect, I tried to simplify the package as much as possible, removing any unneeded cruft, but in the process may have remove a couple things we wanted to keep (namely pulling the upstream ruby-tk branch for the ruby-tcltk package). But what is there is working as evident by the attached screenshot, and anything missing can easily be readded by using the 1.8.6 specfile as a reference.

Next I'm going to be working towards Rails 3.0.0 rpms and a Ruby 1.8.7 / Fedora appliance that pulls all of this in. After this we should have a base platform to try some widespread integration testing for multiple versions of Ruby on Fedora.

Enjoy!

I will be attending FOSSCON this Saturday at RIT, about an hr away from Syracuse. I plan on carpooling with a few friends I know from the Syrlug, but there may be more seats available (I can't guarantee this though). So if your in the Syr area and am interested in attending, send me an email and I'll see what the situation is.

I am pleased to release a Fedora 12 based appliance complete w/ a stack of rpms built against and related to Ruby 1.9.1.

This was built using Polisher, which I improved extensively and configured to generate various RPMs and yum repos. There are now many more rpms being generated/hosted since my last announcement, and after alot of work I finally got ruby-shadow to compile against Ruby 1.9.1. The packages themselves were built in mock, and made use of Polisher's project dependency support, so that projects built against the 'devel' repo were being built against the Ruby 1.9 package that resided there.

To make use of the appliance, download and extract the tarball, and run 'virt-image' on the polisher-devel.xml file (you will need the appliance tools installed). This will take care of all the work for you, you can then just open virt-manager, virt-viewer, or any other virt client and use a Ruby 1.9.1 build for Fedora!

Many thanks go out to those on ruby-sig for all the work to support Ruby on Fedora, especially Jeroen for the Ruby 1.9.1 spec file (and all the other work/research) which I initially based this of off. There were several other changes that went into it as issues were discovered, particularily some patches from Ruby 1.8.6 had to be readded to fix issues, and care had to be taken due to the fact that rubygems and rake were both merged into the official Ruby project stating in Ruby 1.9 (right now I figured the easiest way to handle this was to change those packages to be empty and just depend on / pull in the Ruby rpm).

There is still alot more work to do, eg nits w/ a few of the specific scripts, support for more projects, and a working Ruby 1.8.7 appliance (the maintenance repo and 1.8.7 specfile are still a work in progress). But what is there is a very easy way to run Ruby 1.9 natively on Fedora, and to start testing various software stacks. Until the next update, I leave you with this, a screenshot of Fedora 12 running a ruby-gnome app built/running against Ruby 1.9 (source code is attached to this post). Enjoy!