[sakai2-tcc] Annotation based injection within Sakai components

Wed May 16 11:40:14 PDT 2012

Agree with those cases,

Hibernate isn't perfect especially with auto.ddl it has known limitations.
It can't drop tables and it can't add some column types to existing tables.
So as a developer you'd have to still write custom migration code for a lot
of instances. Typically this isn't ideal anyway since many times
'operations' would prefer to let the DBA run the migrations in production,
either via script or an offline mechanism.

Obviously the a good idea is how Sakai originally started as unstructured
"NoSQL" style XML data, but because we wanted to search and sort on those
columns, that didn't really work in the long run keeping NoSQL in a
relational DB without additional technology indexing it. This does make for
nicer migrations though. Also systems like ActiveRecord in rails that
define you writing migrations or at least keeping track of them is a good
idea, this was also what Liquibase does and seems reasonable, but these are
all pretty new. Migrations in the CLE are "not good".

I would say in general Java is much slower just because the LOC is
significantly than higher most other popular languages, and the difficulty
in development can be more confusing with the vast number of frameworks
available. Would we recommend anyone start out writing a tool with
JSF/RSF/Velocity? Probably not, even though 90% of the core CLE is written
in that. So you have new development taking place in some other framework
and nobody (aside from maybe Zhen) who even knows how the "old code" and
really work anymore. Simple things like figuring out how to add some
javascript widgets (like this whole date/time picker change) become
considerable harder than it should be.

Developing up a new tool is usually faster than fixing an existing tool,
which is why we have Assignments2, Gradebook2, Chat2, Roster2, Profile2,
and 5 different Blogs. (None in core)  :)

Though focusing on the tactical rather than the technological dos make more
sense. I think the last case about strengthening direct would have very
high impact, because even though BasicLTI is limited, if we had a /direct
where an external tool could CRUD against assignments, assessments and
calendar, while also being able to get at resources and validate group
membership it would be able to do basically everything an internal tool
could. (Even if some of these enhanced activities were specific to Sakai)
Easier to have this stand-alone app and add in the functionality later for
some other platform than write a tool that uses all Sakai's internal API's.

On Wed, May 16, 2012 at 12:15 PM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> For the benefit of those of us with the "curse of knowledge". I would
> love a list of how these other systems are easier to get started with
> and develop from someone who is newer to Sakai development. I don't
> find the "Sakai development sucks" and "X development is awesome"
> comments helpful at all without details.
>
> I do like the plugin style development in Moodle, Drupal, Wordpress,
> Blackboard, etc. Being able to upload a chunk of code as a plugin is
> nice for sure but I don't find it really speeds up my development that
> much. I typically just edit my code right on the wordpress or
> blackboard instance rather than re-uploading the plugins over and over
> so that's really more of an admin benefit IMO.
> The really dev benefit tends to be the support in the platform that
> makes it easy to control versioning (DB updates, migrations, etc.) and
> built in support for plugin configuration and things like that.
> I think that stuff could be built for Sakai but I question the ROI
> (and especially the opportunity cost) at this point in time.
>
> -AZ
>
>
> On Wed, May 16, 2012 at 11:48 AM, Matthew Jones <matthew at longsight.com>
> wrote:
> > Well, how long does it take a new developer who has never used Sakai
> > Services before to write a new tool that integrates with
> > assignment/gradebook/assessments/calendar/entitybroker.
> >
> > My guess would easily be months. So this makes/keeps the development pool
> > for Sakai small (a fixed ~10-15 devs?)
> >
> > How long does it take someone to write a new tool for any service with an
> > external API? Lets take for example Pivotal Tracker or Harvest (because
> I've
> > written full new tools against those) . . . About a day or two to learn
> it,
> > and two weeks tops to have the app (or wordpress/drupal module)
> > fully functional, polished and in production.
> >
> > And that doesn't even mention the long term maintenance costs of a tool
> > after the original developer leaves and no longer supports it.
> >
> > Perhaps there are plenty of tools, but most of the ones used in core have
> > been there in maintenance mode since 2007/2008, and most of the
> > ones outside of core (contrib) were written by this limited group of
> > developers over the last few years.
> >
> > For Sakai, I guess plenty of tools = 50. For Moodle its near 500.
> >
> > Sure quantity doesn't equal quality but the new user learning curve is
> > pretty steep, and the reload time of tomcat is annoying.
> >
> > On Wed, May 16, 2012 at 11:26 AM, Adrian Fish <a.fish at lancaster.ac.uk>
> > wrote:
> >>
> >> Can you tell us why you think CLE coding is a pain in the arse? The
> >> 'fact' of it being a 'pain in the ass' doesn't seem to have deterred
> >> people from writing plenty of tools for it ...
> >>
> >> Cheers,
> >> Adrian.
> >>
> >> On 16/05/2012 15:22, John Bush wrote:
> >> > well right.  I guess what I'm saying is a reaction to matthews email.
> >> > Little incremental changes like moving to this version of spring or
> >> > that version of whatever aren't any sort of game changer for Sakai,
> >> > they aren't going to solve the fundmental problems.  So if those
> >> > incremental changes lead to a bunch of problems for no real gain, I
> >> > don't see the point, it seems like a giant waste of effort.
> >> >
> >> > The fact that its a giant pain in the ass to do Sakai development
> >> > isn't going to be solved by these little things.  Its still going to
> >> > be a giant pain in the ass.  Maybe a little better, but still way too
> >> > hard.
> >> >
> >> > I can't see why anyone would even want to build a new tool in sakai at
> >> > this point, at least if you believe OAE will get off the ground at
> >> > some point.  LTI makes much more sense, since anything you do there
> >> > can run in OAE when its ready.
> >> >
> >> > That said I don't object to a kernel 2.0, it can go off and do its own
> >> > little thing.  But I'm very doubtful that it would have much adoption
> >> > at this point, outside of a few places, so in reality I'm not worried
> >> > about it breaking anything, because I don't think anyone will even use
> >> > it.
> >
> >
> > _______________________________________________
> > sakai2-tcc mailing list
> > sakai2-tcc at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120516/46aa9aac/attachment.html 