I finally dipped my toes into MongoDB last night after catching some inspiration from the Ruby community. But I hit a basic snag doing something that would be Really Freaking Cool if it worked (and by all accounts it SHOULD work!), so in lieu of doing any real work yet I thought I’d post and get some feedback first.
Mongo is one these new-fangled NoSQL databases, which means it’s schemaless and doesn’t require migrations. So how do you manage your data? Grab a Mongo library and start defining some models!
Note: Another nice Ruby-Mongo library is Mongoid by the nice folks at Hashrocket.
So I read this MongoMapper post on bitzesty yesterday (lots of nice examples there, as well) which goes so far as to mention a few powerful Ruby gems that are MongoMapper-compatible. Amongst them was Formtastic, a semantic form builder for Rails which I am already a great fan of. And therein lies the Really Freaking Cool thing I mentioned earlier: you see, Formtastic supports this awesome syntax for auto-generating a form based on the attributes present in a model:
Really Freaking Cool Thing: While you’re still prototyping your data model, why should you have to make changes to all of your forms (new, edit, other nested forms, etc) when you make a change to your model? You shouldn’t! Just make a quick adjustment to the model and let the forms fall out.
It was this magical world of instantly-propagated data changes with no migrations and no view templates that made me jump in and give it a shot. Alas, an error:
Looks like MongoMapper doesn’t quite walk or talk like an ActiveRecord duck in this case, but that doesn’t seem too hard to fix. I’ll have some time to get to it this weekend, but I wanted to see if anyone else (preferably the maintainers of these plugins!) had an opinion before I dig deeper. The normal Formtastic fields work fine, but if you rely on reflection (call ‘form.inputs’ without specifying attributes), you get this ‘reflections’ error.
This might actually be a trivial one-line fix in MongoMapper, I just haven’t looked at the source, yet. I’m doubting Formtastic needs to do anything right now, but one can’t help dreaming of the coming Rails 3 world where things like this can be loosely coupled yet tightly integrated with little/no work…
This IS a cool idea, isn’t it? Having not totally grokked the new way of thinking with schemaless DBs, I still question all of my instincts in the area. But this just seems like a natural reduction of overhead for dealing with these far-less-strict data sources, especially early in the prototyping phase of a new app!
I gave a presentation on Cappuccino to the Atlanta Javascript Meetup on Thursday, December 10th at Ignition Alley. It was a lot of fun! We had a great turnout and I met a lot of passionate developers, despite clashing with the PHP, Python, and Cocoa meetups. In fact, I understand the Cocoaheads meetup actually included a talk on Cappuccino as well, and I’m curious what all was covered.
There was another talk before mine: Jenny Steele presented on Javascript Build Systems, and gave us insight into the process of evolving an appropriate build script for your unique project. This is a terribly important subject as Javascript continues to march into the realm of Something Real Developers Do (as opposed to the almost entirely copy-n-paste-based ecosystem JS has been for so long.) As we are now seeing, scaling isn’t just about your back-end and web stack: it’s actually largely about playing the HTTP and caching games correctly! JS build systems are your key to getting this step right and getting on with your business.
My talk was focused on introducing the Cappuccino project to our local developers. Have you ever set out to build a rich web app using HTML, Javascript, and CSS, found that you can get some interesting things working pretty quickly, but every next feature is harder and harder to bolt on? It’s still early and plenty immature, but I have been amazed at how well I can architect a nice web application using the tools WITHOUT the fear of the next feature breaking my app’s back. It’s good enough to start building apps today, and I have faith in the 280 North team to continue delivering on the tools, API, and most of all: productivity!
My slides are embedded below:
And the resource links to the project and some of the awesome apps people have already made with Cappuccino:
UPDATE: This set of instructions is for Version 1.0 of the plugin
In your WordPress admin panel, click “Plugins”, then click “Edit” next to the Seesmic plugin. Now you’ll be presented with the code for the Seesmic plugin. All you really need to do is find all instances of “clear:both;” and remove them entirely.
The problem is the way that some themes are written. It has to do with how your sidebars are implemented, that is, if they use floats or not. The “clear” CSS attribute causes your Seesmic videos to appear below your sidebars, which generally means it just slams a huge amount of whitespace above the first Seesmic embed on any page.
Clear out the “clear” tags, and its gone! (make sure to clear them ALL, or some strange things will happen)
UPDATE: This set of instructions is for Version 0.1.5 (the latest version at this date)
They’ve moved the “clear:both;” stylings into the seesmic-wp.css file in the base of your Seesmic plugin directory, and that file isn’t easily editable from within the WordPress interface. You still just need to find and delete them all, but the process will be dependent on how you do your FTPing and file management on your server. Probably you’ll just want to open the file on your local machine and reupload it.
Sorry I had my facts wrong, I had no idea they had updated the plugin!
I’d still like to get some feedback from the developers, because we technically shouldn’t be going into plugin code and changing things willy-nilly like this, but this hack seems benign enough. The official place to talk about this is the Seesmic tech support page at Get Satisfaction, and Loic himself assured me (in the comments) that they will take a look at this, so perhaps some feedback is forthcoming!
A couple of weeks ago, Adobe slipped this announcement past my radar screen. It seems we can download the Flash 10 Beta now (previously codenamed “Astro”), and it is chock full of new enhancements, most notably of which are access to Pixel Blender and 3D hardware acceleration.
Pixel Blender is a technology Adobe rolled up for After Effects CS3, originally. It basically gives the developer a lot of easy access to image (bitmap or vector) and video manipulation functions. If you are a hardcore type and you download Flash 10 Beta, then you should check out the Pixel Blender Exchange for a lot of demos showing you what things are possible with it. Here’s a video to show some of it off, as well:
Now let’s talk about the hardware acceleration. This should be a great addition that makes everything just gorgeous, right? Actually, no. It seems that it actually doesn’t speed up your traditionally optimized Flash apps, in fact it slows them down.
Does that seem counter-intuitive? Maybe it is, but it’s no real surprise to most game developers. 3D graphics in general is hard stuff, and as a community we’ve had to invest major amounts of time and money iterating our skillsets, toolsets, platforms, and teams to get to the point where we are today. This will also be the case with Flash 10, though the timeframe will be massively compressed (think 1 year instead of 10.)
There are already some amazing3Dlibraries for Flash that actually work really well for us hardcore developers. But Adobe’s press release says that those options are “reserved for expert users” and that Flash 10 will make the functionality “available to everyone”. So does that mean that these frameworks will be able to actually just bootstrap the new hardware acceleration and get better seamlessly? Or is Adobe posturing this technology to compete and cause dreaded fragmentation, here? Eventually i think the point will still be moot, though (in a year the tools will be settled, regardless.)
As the confused juggernaut of Microsoft approaches this space with its usual lumbering pace and lack of direction or solidarity with Silverlight, it looks like Adobe is taking the appropriate steps to keep their 98% slice of Flash-enabled web browsers fully geared up, and its developers fully tooled up. Expect these improvements to trickle down to Adobe AIR rather quickly, as well. And if Google’s announcement yesterday is any indicator, i’m sure they’ll be keen to get some 3D acceleration in the browser as well…
Special thanks to Nick for turning me onto this bit of news.
As a social media marketer, I pay attention to technologies that let me build social web applications with ease. With so much social progress on the web every day, I like to be able to bootstrap someone else’s functionality so that I can focus my efforts where they are most needed: user experience, content creation, traffic shepherding, and analytics.
And that’s why I took notice today when MissingMethodannounced the release (MIT License) of CommunityEngine, a social networking plugin for Ruby on Rails. But this isn’t just another Rails social framework (like LovedByLess), it’s actually less than that, in a “less is more” kind of way. You see, CommunityEngine is just a Rails plugin, so it’s (supposedly) easy to just add some social networking functionality to your already-running Rails app.
