Bomber Studios

Good morning!

I have just uploaded a new version of fluby to RubyForge. It will be available in a few hours. If you are the impatient kind, you can always install from the Gem repository at Github by running:

gem sources -a http://gems.github.com
gem install bomberstudios-fluby

what the hell is fluby?

Nice of you to ask. From the README:

fluby is a simple command to create an empty ActionScript project for MTASC + SWFMILL + Rake

I have been using it for quite some time for all my ActionScript projects, and it has saved me countless hours of work.

It uses Ruby, Rake, MTASC and swfmill to make project creation and compilation 100% painless.

To create a new project:

fluby Projectname

To compile your brand new project:

cd Projectname
rake

That should generate a 'Projectname.swf' file on the 'deploy' folder. The SWF file is debug-enabled (i.e: you can see the trace() output if you have a debug Flash Player). If you want to release your project without debug information, run

rake release

New in version 0.6 is the ability to generate files from templates, so you can spend your time on the really important matters of life, such as finding the perfect beer or learning japanese :)

Checkout the full README at Github

Giving up to peer pressure, I've enabled comments on the blog.

It's a good oportunity for me to test Disqus and see if it lives up to the hype (also, it saves me from having to code a comment system :)

So, comment away! :)

You want to know how to paint a perfect painting? It’s easy. Make yourself perfect and then just paint naturally. That’s the way all the experts do it.

Robert Pirsig -- Zen and the Art of Motorcycle Maintenance

If you haven't seen it yet, do yourself a favour and watch this presentation by Giles Bowkett

It doesn't matter if you don't know anything about Ruby, aren't interested in MIDI or don't even know who the guy is.

It will be time well spent, trust me...

There's this thing about Github that I really love: it lowers the barriers of entry to the Open Source ecosystem.

And it does this by transforming forking. Where it previously was considered anathema, now it's the way to contribute to a project.

However, with this ease of forking (which in my opinion is a quite positive thing) comes a new reality: the fragmentation of efforts.

Here's an example: take Sinatra, the cool and lightweight Ruby framework this blog is built on. As of this writing, it has 43 forks in Github. That's nice, because it means there's 43 people willing to hack on it. If you are the original developer, you will probably get a pull request every now and then...

But what if you aren't? You are faced with 43 forks, each with a small change, and it becomes quite hard to follow what's going on with the project.

Also, I get the feeling there's like 20 fixes for the same bugs.

Now think about Rails. It has 346 forks. How can you possibly track what's going on?

What I think is needed now is a way to reap what has been sown. A way of profitting from the vibrant ecosystem that the zero-effort-fork has created.

(This is small part of the ideas from a conversation I had with Nando. I will hopefully revisit them later, and may even come up with a project)