On Monday, March 12, 2012 at 11:52 AM, George Chamales wrote:
Woo hoo! Architecture discussions!I'm skeptical. MVC works pretty well for me. I personally suck at php and love rails but everybody speaks php so who cares? There's nothing architecturally unsound about php or MVC in my view.I think that MVC isn't a bad choice when you're building one application that does a well-defined set of things with a data model that can be happily cast in stone and never touched again. Ushahidi's greatest strength is that it's the exact opposite of that type of application - it's a platform that can be used for a ton of different things which is extremely enticing to hackers like us. We're having this discussion because one of us has a really awesome idea and wants to use Ushahidi to do it - but is having trouble because he's trying to modify the elements of the Ushahidi framework that are set in stone in the MVC.
Supporting a flexible data model is a great idea, but to do that means a situation where you want to allow your users to create their own custom forms. This puts the platform in a position where it must either have the ability to re-write its model on the fly or go the key-value approach of throwing everything into a few big tables which sort of blows the entire point of the MVC model.What alternative architecture would you recommend George? I am especially interested in how post MVC styles are more secure.I don't have a good answer at the moment. The security criticism for MVC is that I'm not aware that it has any security actually built into it. Sure you can add something to the models to catch some things and you can add some logic to implement access control in a controller, and maybe there's some pieces here and there that automagically handle validation, but that's not the same thing as being a fundamental architectural component. I want an architecture where it's easier to write secure code than it is to write insecure code.PS I would still like to see a "Featherweight Ushahidi" version that is a reduced functionality version of the app. But I was imagining something largely compatible with upstream, and I still think that would be preferable.Okay - so you want a streamlined version of Ushahidi - I think that basically means that you'd want to have a reports model that's more flexible. The first option is to take the established reports model and make bits and pieces of it optional...but what pieces? If the categories are optional then large parts of the maps break, if the location is optional then the map breaks, if the description is optional then the search system and reports listing breaks on the front page, reports page and admin reports page breaks, if the title is optional then same issues arise.A bunch of the other components are actually just hacked-in add-ons such as the media links, pictures, reporter information, points/lines/polygons, etc. Those things are already optional (which is great if you don't want to use them) but they're effectively after-thoughts with little-or-no integration anywhere else in the system - the filter by news, media, etc. links on the frontpage weren't wired to anything for, what, two years?But rather than talking about A Big Rewrite what about just improving the codebase? For example, from your comment George it sounds like the app is forcing your hand (as it writes crappy code). Why couldn't you use models and controllers for the enhancement? What are the actual architectural limitations here?The alternative approach is to allow people to define their own reports format which brings us into the exciting world of custom form building. Again, having gone through that process once I can tell you that the current implementation leaves a lot to be desired and even if it was decent, it's also basically an after-thought to the primary reports model.Which means that if you want custom forms that are integral to the system then the entire system will need to be re-written to utilize them from the get-go. Once you've made that decision then you'll be forced to try and figure out how to implement dynamically generated form models in a situation where the MVC forces you to use a Model for forms which contains a name and id and a Model for custom form fields which contains the id of the form, the name of the field, the field type, default values, and then another Model that contains the results of the form entries and their associated form field id. This conforms nicely to the MVC principles and is all properly normalized - but then every access to the forms (which would be absolutely every call to the data) is an inefficient mess of joins.And, even once you've gotten to that point, you're still stuck with needing to completely re-factor all of the other systems (map, search, reports list, import, export, etc. etc. etc.) that rely on the static reports model.I think that the level of effort necessary to boil Ushahidi down to that core functionality is far greater than what would be necessary to chuck all but the four pieces I mentioned earlier (after adding groups) and start from the ground up.PPS criticisms of Wordpress and Drupal are fun but those php ecosystems have been important for Ushahidi too, and I think Ushahidi will do well to integrate more with them more, regardless of the evolution of the codebase ...That's a strategic decision that's far beyond my pay grade - however I can probably think of more powerful features to give Ushahidi's users than better blog integration or the Drupal application of the week.georgeHey, 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 InterfaceEverything 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.georgeGeorge 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.Rguys, 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?cOn 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@...