good day for mozillians
I want to add a personal note onto what dria said about today's Mozilla activities. (TL;DR - Zarro Boogs on Firefox 4, new Web O'(pen) Wonder demo site, and a new Open Web Apps release.) We made bug fixes and enhancements to Mozilla Developer Network.
We made a handful of improvements to the localization code and process for MDN. Our web localization team is doing great work adding 15 new languages for the MDN interface!
We've also made performance improvements and bumped our YSlow! score up to 88. We're almost ready to hook it up to a static CDN which should get us a strong 'A' grade. (We can't make those DNS changes while IT is preparing Firefox 4 release infrastructure.)
And if you poke around you might see a hint of what's coming soon to MDN.
open(war)
We (finally) see the tech industry take critical notice of Apple's closed nature. Most recently over the draconian terms they announced for publisher subscriptions. Of course, I've been self-selecting my articles ever since I heard about Apple's predatory application of the severely closed iOS/iTunes paradigm onto Mac software at large with the Mac App Store. I remember a couple of Apple (one a former employee) buds trying to sell me on it - first extolling the value of a search-able directory of apps with ratings and reviews; less than 5 minutes into the conversation they were complaining about poor App Store search results. Good thing there's an app for that.
This is not totally new. Open source has been fighting the open war (very well) for a while. There are well-known battle plans on both the proprietary side and the open side. Some on both sides want to see their "enemies" destroyed, but some of us think open source has "won" by simply creating and sustaining open products and opportunities - not necessarily destroying proprietary software.
The struggle for Open Web over proprietary Apps is simply an evolution of this struggle of open vs. proprietary. (Personally, I moved from SourceForge.net to Mozilla because I want to be on these new "front lines.") There are signs that the tide may turn in favor of Open Web Apps for Mobile and why not? We saw this already with the victory of the open web over closed networks like AOL, CompuServe, Prodigy, etc.
As much as I'd like to, I'm not predicting the demise of the App Store along the lines of CompuServe & Prodigy. I'm voicing my dissent from the closed status quo and appealing for a more open approach; at least a pro-open perspective. If you're making web apps, build them with open web technologies. Instead of making native mobile apps, make your web apps kick ass on all devices with HTML5, and only go to an App when you really need device-specific features like cameras and accelerometers.
UPDATE: Mobile Europe has a good article on HTML5 & App co-existence.
That's all.
__init__
I'm embracing a lot of things recently - python, django, my underused programming handle, and now blogging. I liked my old blog, but I didn't have the time nor leeway to post what I was doing all the time. Jay Patel, product manager for MDN, encouraged me to blog about what we're doing there so here I go:
from mozilla.webdev import Job
class MDN(Job):
def begin(self):
from mozilla.webdev.mdn import developer.mozilla.org as devmo
devmo.enhance(features={
'0.9.3':'Demo Studio',
'0.9.4':'Learn HTML5',
'0.9.5':'Single Sign-On'}
)
from mozilla.webdev.mdn import dekiwiki
from mozilla.webdev.sumo import Kitsune
class Kuma(Kitsune):
pass
dekiwiki.moveto(Kuma)
There are two parallel tracks for MDN - 0.9.x and 1.x.
0.9.x is a track of enhancements to the existing MDN django, dekiwiki, and phpbb systems. In 0.9.3, we're making an HTML5 Demo Studio, somewhat like the Personas Gallery for HTML5 demos. (Duh.) 0.9.3 will also feature many new locales in the django application, and performance improvements for django & dekiwiki. Our MDN staging server showed a YSlow! score increase from 81 to 91 for django; from 79 to __ for dekiwiki. We're still defining the other 0.9.x milestones.
1.x to 2.0 is a large rewrite of MDN moving the wiki docs from dekiwiki to 'kuma' - a clone of 'kitsune' - the django wiki application we use for SUMO. Both are japanese words (a django theme?); 'kitsune' means (demonic shape-shifting) fox and 'kuma' means bear. We might describe Mozilla support users as foxes and Mozilla developers as bears. Dekiwiki is a good wiki platform, but we've run into problems maintaining it, and we want to move all of MDN to django to leverage django libs and features - especially those developed by SUMO and other Mozilla django projects.
I'm mostly working on Kuma now - cloned kitsune and will merge mdn when 0.9.3 is solid. Then we should be able to branch kuma to an 'mdn' branch for the rest of the 0.9.x work and merge each milestone into 'master' with the 1.x work.
At least that's the plan for now. Keep tabs on the MDN wiki page, MDN bugzilla queue, and join us in #mdn to follow our MDN dev activity. We hope to make MDN a premier web dev resource and I think what we're doing now is going to help us get there.
quick blurb on NoSQL
I've spent about as much time thinking about this as NoSQL developers spend thinking about their schema, but here it is anyway.
At SourceForge I'm presently developing and maintaining a few different systems using all kinds of web tech's and languages - PHP, python, solr, Postgres, MySQL, and mongo. One thing I'm noticing is that the mongo systems are something of a breeze to write, and then a real challenge to maintain - especially debugging. Our mongo experts mostly say that the tooling for mongo is just 'immature.' I'm sure they're right, but that also points toward what I think might be a fundamental difference in the two modes of development.
AFAIK, there aren't any "old" NoSQL systems around? Mongo is only out since 2007, and Cassandra since 2008? We started using mongo early 2009, and even just one year out it feels so much more painful to maintain than our Postgres or MySQL systems that have been around since 1999! My theory is that NoSQL sacrifices maintenance and future development effort for the sake of startup development. I even made a neat drawing:
Initially mongo seems to save on effort until the first valley - initial launch. At this point, the system launches and typically starts interacting with other systems and with users - data requirements change towards reality, which means code - i.e., function and logic - changes, not just model. In our environment, all other systems that use the data must also change their code which seems harder than the originating code. The code and the data are so intermixed that seemingly any and every change in either domain makes knock-on effects that have to be addressed.
In a typical schema data system, we front-load a bit of data modeling effort. After launch, when we get new and changing data requirements we typically address the schema changes that might be involved, and may have to write a data migration/transformation script. But beyond that, it seems we don't have to worry about data integrity or any other knock-on effects. We can change some data-access or model classes and be on our way.
So, am I just an old crusty developer shouting at these NoSQL kids to "get off my lawn!" ? Or has anyone else noticed this too? Maybe it's just the heterogeneous mix of NoSQL + schema that's killing me. Just seems like such a pain for not enough benefit?