Hi Mike et al.
Perhaps I can add a little additional context and update.
The NEAD data model was very much based on NCEAS' underlying data
model. Mike-- for your group, you will definitely need to determine how
closely your structures and processes map to those at NCEAS and NESCent,
in order to decide whether you should adopt and revise, or rebuild. As
you probably are aware, NESCent and NCEAS share a number of similar
administrative workflows.
When NESCent started up, we gave them full access to the code for our
fully operational administrative database, and it was initially
considered whether they could just adopt it offhand. NCEAS "adminDB"
was written in Oracle, and served NCEAS quite well for over a decade.
I say "served" because recently we customized the NEAD codebase to adapt
it for NCEAS' administrative purposes. This was due to some persistent
requests for new features from our administrative staff, and our
reluctance to invest further into the Oracle solution. The benefit of
breaking away to an open-source PostgreSQL implementation (upon which
NEAD is based) was appealing, even if we weren't too keen on the Spring
framework. Anyhow, we are now running a revised version of the NEAD
codebase, which as I mentioned, was based on the underlying logical
model found in the original NCEAS Oracle codebase.
The primary purpose of NCEAS' administrative database has been to
facilitate administrative functions, both logistically in terms of
arrivals/departures of visitors/residents, and in terms of reporting--
metrics for NSF, planning purposes, etc. That is, it is not well
integrated into the scientific process-- relative to issues like shared
document repositories, code-versioning systems, bug-tracking systems,
etc. I believe the same can be said for NEAD.
The software engineer working on the "NCAD" database (NCEAS'
customization of NEAD) is still doing a few small enhancements and
bug-squashing on that app. This code-base could be made fully available
to you as well...
Cheers,
Mark
On 6/10/11 7:41 AM, Mike Smorul wrote:
> Thanks,
>
> I'd be interested if not in the code, at least any requirements documents/use cases you've identified over the last few years.
>
> -Mike
>
> On 06/09/2011 05:57 PM, Hilmar Lapp wrote:
>> Just FYI, NIMBioS is in the process of resuming their efforts to port NEAD to their environment. If this is something that others want to join, I'd be happy to push for an effort here to put the code up on a public repository, for example github, which would allow others to fork or clone and add their own customizations, for which we could then periodically discuss whether they are worth being brought back into a "master repo".
>>
>> When we started to develop NEAD, that was the one piece of software we thought would for sure never be interesting to anyone else, so there may passwords and stuff inadvertently committed in places when they shouldn't be. So before this goes up on a public repo we better go through the code to weed out such pieces. But we run a private git server too, so perhaps that's a possibility too. Right now it's on a private svn server, and thus not very amenable to sharing some but not all development.
>>
>> -hilmar
>>
>> On Jun 9, 2011, at 3:43 PM, Mike Smorul wrote:
>>
>>> Hi all,
>>> It looks like we're finally getting things rolling on this end and one of the first thing that pops up is the need for a nead like application to manage administrative tasks bringing in post-docs, personnel, and managing working-groups. With the horror story of trying to port nead to another center still fresh in my mind, what would you all do different if given the opportunity?
>>>
>>> Thanks,
>>> -Mike
>>>
--
Mark Schildhauer, Ph.D. 735 State St., Suite 300
Director of Computing, NCEAS Santa Barbara CA USA 93101
Email: [log in to unmask]
Phone: 805-892-2509 FAX: 805-892-2510
http://www.nceas.ucsb.edu
|