Hey, while we're talking revolution, I think the whole MVC approach should be scrapped.
At its best, a well-implemented MVC architecture leads to set-in-stone data models with ad-hoc visualizations and ad-hoc controllers. The anything-goes approach to views make it difficult to tweak the layout, have an obnoxious tendency to sneak javascript validation logic into the static content, and break when you change your underlying controller logic - that's not what I consider a separation of functionality.
Controllers give you one place to put your logic, but stop far short of imposing any sort of logic around how your logic should be laid out. As a result, we end up with code that's insecure (because security's just slapped in wherever it seems fitting) and extremely hard to modify (because everything's a jumbled mess). I think there are places where MVC is the lesser of all evils, but there's got to be a more logical way to organize an application than cutting it into three pieces and saying "voila, it is architected!"
I think about the hassle that I had building out Ushahid's custom forms system. The basic functionality was there (thanks David!) and extending it wasn't the most obnoxious thing that I've ever done, but the MVC format was effectively worthless - as the entire sub-system ended up being implemented as a set of key-value tables in MySQL reminiscent of the worst of Wordpress. Again, MVC is far better than nothing, and it's certainly loads better than the bad-old-days of architecture-free development that brought us Drupal, but "less bad" is not the same thing as "good."
If I were to take Ushahidi apart, I'd say it's got the following decent features:
* Users & Roles
* Pretty Themes
* Modules
* Frontend / Admin Interface
Everything else - mapping system, search, api, reports model, custom forms, and don't even get me started on checkins - is either half-baked, poorly implemented, poorly documented, or some combination of all three. If I were to start over, I'd scrap everything except for those four pieces (although I'd probably re-write the user system to include groups).
As for programming language, I'm not sure that I'd go the Node.js approach - I've done a bit of work with node now and while it's fun and theoretically fast, it's still really, really, sometimes painfully new. My concern is that if the goal is something that others can build off of, then it would make sense to start from a place where there's already a rich ecosystem of libraries and add-ons that can be leveraged. Not sure that I'd go with RoR either - but maybe that's just because I think that two of the biggest problems with web programming is that it's done by web programmers using web programming languages.
And before I forget: Chris - we're going to be tearing down the oven in the backyard at some point in the near future and need to do a few last firings if you're interested. Everyone else on the list is invited if you happen to be in the Bay Area.
george
George Chamales
Rogue Genius LLC
On Fri, Mar 9, 2012 at 8:14 AM, Rob Baker
<rrbaker@...> wrote:
If we're hacking /application, maybe time to make a lightweight RoR or Node version instead? (Yes, I said it -- all aboard as the bandwagon is leaving the station.)
Anyway, it's a smart decision, Chris, bit do wonder if that much hacking ultimately toward something simpler couldn't be better spent on a model using newer frameworks. If Ushahidi does adopt a more aggressive development cycle this year this would be out on the fringe like the Sharek build in no time. Not assuming or saying this would need to stay upstream to the core, but if that much hacking is going into slash and burn, maybe this is one of those rare times where starting a new (very small, very manageable) project makes more sense and could be more fun.
In other words, an opportunity to focus on the models of response that work, not the segments of (Kohana v2/OpenLayers) code that apply. But this could also be more crack smoke.
Thanks for thinking about this though -- very cool and glad to hear it's still in the works.
R
guys, thanks for all the input on the ushahidigram concept last month — spent some time hacking on it over the last few weekends and now want to rethink my approach.
I had a hard time removing functionality to get the simplicity I am going for: I think if you want to remove 80% of the features from Ushahidi, a theme on top of it all is just not the way to go. Overriding validation, and other deep assumptions about the data seems especially tricky. (By contrast removing unnecessary javascript and markup seemed easy ... just override them with empty files! But when I started to see how many files I wanted to override in this way, it started to smell strongly of crack smoke.) Most importantly to me, it seems it would be brittle over time — tightly coupled to the upstream with no benefit ... it would probably just have to be frozen to a particular release. So, it would be a kind of dead-end theme that wouldn't do that much for the community and would take a surprising amount of effort.
... but I'm starting to think it might be cool to do a proper fork of ushahidi though — a super-minimalist "ushahidi bootstrap" that could be extended up into an app like ushahidigram. I'm imagining this would be basically a step up from Kohana, but not merely MVC bits on the floor — a real app that runs immediately, yet does not assume any required fields and uses strictly minimal view layer. It could make fewer assumptions about what you want to do: just authentication, a few basic templates, maybe plugin support and some mapping examples. Something that is still based on the ushahidi core reporting model, but assumes you are going to run with it in a new direction. This would be a largely incompatible fork, hacking extensively in /application and changing the database schema ... but somehow it seems like a lot of people might really find this approach useful for developers in the community.
sound crazy? thoughts?
c
On Feb 3, 2012, at 9:34 AM, George Chamales wrote:
Few thoughts:
Could utilize the mapping system if the photos come in with lat/lon in the metadata.
If no geo info then set lat,lon to null island and use a javascript header include to disable the map if it detects lat,lon is 0,0.
Could parse metadata on upload of photo to determine if there's geo information and unhide the map to allow users to tweak.
InfoWindow plugin could be tweaked to provide thumbnails in map pop-up bubble for geolocated pictures.
Custom forms could be used to capture additional info about the image pulled from metadata (exposure, camera type, etc.)
Fun idea, I'd be happy to get together to brainstorm as well.
george
George Chamales
Rogue Genius LLC
On Thu, Feb 2, 2012 at 5:25 PM, Chris Blow
<unthinkingly@...> wrote:
Hello,
Would anyone be interesting in collaborating on an instagram clone built in ushahidi?
I think it would be a good exercise because it could leverage the native mobile clients / or be a cool HTML5 mobile thing — but mostly I want it to be extremely streamlined and customized just to photos. We could hide virtually ever feature and carefully craft the few things we do expose. It could be ridiculously minimalist and, if I could just snap and upload, I would use it every day. It doesn't have to be a perfect instagram clone, just an easy to setup photosharing hub with a one-click experience.
Perhaps it could be useful to corporate teams, or geeky families, or friendly darknets and people of the underground. (It would not have the huge instagram social network, but I'm attracted to the idea of a smaller hub of a few people ... :)
One problem we talked about at the meetup last in SF was the fact that Ushahidi proper is not really appropriate for day to day use. Also it is just not fun to think about disaster apps all the time. But we know that, in disasters, people use what they are used to. So maybe this would be something that would help bridge use between normal days and things are on fire days.
I think I really want to work on something with ushahidi that is just 100% fun this year.
I was reminded of the checkins feature which we were playing with at SXSW last year. That theme is freaking excellent. But I don't use checkin apps. (But I do use the hell out of instagram.) Is that theme still active? Would it make sense for the ushahidigram theme to be a fork or extension of that one?
It should be trivial to build most of it, since it is largely a subset of features. And the social features (which are in Instagram but not Ushahidi) are quite simple.
Anyway, I am eager to make another theme in sass (CSS) and to work out my html5 brain-muscles. I went ahead and started pushing to a repository last night. Could use help with the mobile version. Anyone done an any mobile HTML5 features yet? If not, this would be a cool ways to start on a few features without rewriting all the JS and HTML at once .... I started pushing here: https://github.com/unthinkingly/ushahidigram would be happy to see a fork and some contributors.
Or just tell me what you think please!
c
PS: Also, since most photosharing sites are generally run by assholes from Yahoo now, I want a way to buffer and broker my photos before they get sent to to them (eg flickr, instagram). Kind of like this brokers to foursquare: http://nearfuturelaboratory.com/2012/01/22/privatesquare
~~~~~~~~~~~~~~~~~~~~~~~~~~
List Archive: http://list.ushahidi.com/
Would you like to receive list mail batched in a daily digest instead? Send a message to:
developers-digest-subscribe@...
To remove your address from the list, just send a message to
the address in the "List-Unsubscribe" header of any list
message. If you haven't changed addresses since subscribing,
you can also send a message to:
developers-unsubscribe@...
For addition or removal of addresses, we'll send a confirmation
message to that address. When you receive it, simply reply to it
to complete the transaction.
If you need to get in touch with the human owner of this list,
please send a message to:
developers-owner@...