An interesting aspect in the relationship between VIVO and Vitro (the non-ontology specific engine for VIVO and other projects) is the layered nature of the projects. VIVO as a source repository is basically a shell that copies over it's Vitro base.
Cornell extends this further with adding their own changes to VIVO as a third level. By modifying the build.xml file and the deploy.properties to include pointing at VIVO as a second layer, the build script can preform the same changes to VIVO as VIVO does to Vitro.
It seems a little complicated, but it removes you from the VIVO source allowing you to replace your VIVO target with the latest version and adapt more rapidly to new releases of VIVO. There hasn't been a study yet, but I would guess that the average time from release of a new VIVO version to an institution upgrading to that version is probably around 5 months. I know at UF it took us about that long (often waiting for the .1 release) and at CU they were still on 1.2 when I arrived (1.5 was released just before the VIVO conference in August).
I've started a wiki article on the new VIVO confluence wiki, https://wiki.duraspace.org/display/VIVO/Building+VIVO+in+3+tiers, that describes how to setup your local VIVO to run this three tier system.
Thursday, January 10, 2013
Tuesday, January 8, 2013
VIVO Ingest in 1.5.1
Little update, about 3 months ago we moved from Gainesville, Florida to Boulder, Colorado as I accepted a position with the University of Colorado Boulder. I'm back in the trenches, writing code everyday and working on VIVO for Faculty Affairs at CU Boulder. Hopefully this will restart my attempts at writing more often and focus that writing on more technical and less managerial matters.
Changes in file:/Users/stwi5210/Source/uccs-new-data/fis_faculty_member_positions.dat
- "http://vivo.uccs.edu/fisid_XXXXX","http://vivo.uccs.edu/deptid_XXXX","1435","Chair","http://vivoweb.org/ontology/core#FacultyAdministrativePosition","2","2"
- "http://vivo.uccs.edu/fisid_XXXXX","http://vivo.uccs.edu/deptid_XXXX","1419","Lecturer","http://vivoweb.org/ontology/core#FacultyPosition","5","4"
With information like this I go to the two individuals listed and make sure that they no longer have the positions of Chair or Lecturer. This let me know that my ingest was successful and to report that it's ready to migrate to production.
All in all the script took about an hour to construct and then run and saved me about 40 minutes of ingesting. Plus I was able to review VIVO after the ingests were finished for the data that should have changed, which is a big improvement over our previous methods of review.
Updating Data Through Data Ingest in VIVO 1.5.1
I've had a lot of tasks at CU since starting, and I'll go over some of the things I've learned and written soon enough. For now I wanted to talk about updating your Data in VIVO 1.5.1. In the old days, when four programmers at UF embarked on Data Ingest, if you wanted to get data into VIVO you had to add it to the systems "Main Model" known as KB2. This made data ingest difficult during the update phase because you either had to
- Start over from scratch with a blank VIVO
- remove the previous data that you ingested which contained the data you want to change
Semantic Triple Stores, didn't have a key that we could use to link a row in KB2 to the data coming in from our source (in hindsight I believe there are ways with hash keys that we should have probably done this). Due to this we constructed a very complicated (and time expensive) process to compare the data you are putting into VIVO against the last time you ingest from that source. It creates an additions and a subtractions file which you then apply against the KB2 model. Basically it was a bit like writing a remove and insert to accomplish an update in SQL.
Now in VIVO 1.5.1 this is mostly the same. However, data doesn't have to be in the main model to be index. So now we can separate our data by the source, or in the case of CU the tables that generated the data. This allows for a shorter ingest process, we're only interested in dropping and adding to the models that have changes to be made. I took CU's current process (which uses selenium scripts against the UI) and ripped out the portion that loaded data into KB2 (download of the data, use add/remove screen to load the exported data to the main graph) and I added a method to drop the import graph that we used. This dropped my time from 3-4 hours to 1 hour for an entire ingest.
We were still rebuilding from scratch with each ingest and now that we're heading to production I wanted to make this process a little faster. So I wrote the first of a couple of scripts towards automating the entire process. This first script reviews the dat files for changes, allowing me to drop only the graphs that have changes and re-run thier ingest scripts.
The process was fairly simply and I've included a couple of sites and blogs I used to figure out what to do. By hand (which will become another script soon) I copied down the data from the previous run and ran a new export and copied down the new data. I then pass to my new little script the two paths for the old data and the new data.
The first step in the script is to review all of the file names and see what is missing, what's new. Since the export process is an sql script which always uses the same file names for each of it's methods we don't have to worry misspellings, just new dat files or the lost of a dat file.
The next and final step in the process was to review the files themselves. I could have used the python difflib, but I wanted more information from the files. I wanted to know what was new and what had been removed. Plus I found a nice little reference post by a Frankie Bagnardi that I wanted to implement myself. The result has greatly increased the ability of the ingest operator (me today, probably alex and vance at other times) to make sure that the changes coming in are reflected in VIVO. For exampledef reviewFolderForChanges(oldFilePath, newFilePath):#read in file patholdFiles = os.listdir(oldFilePath)newFiles = os.listdir(newFilePath)#get names of files in order of name by create listfor newFile in newFiles:if newFile in oldFiles:reviewFileForChanges(oldFilePath+newFile, newFilePath+newFile)else:print "New File Found: " + newFilefor oldFile in oldFiles:if oldFile not in newFiles:print "File Missing: " + oldFile
Changes in file:/Users/stwi5210/Source/uccs-new-data/fis_faculty_member_positions.dat
- "http://vivo.uccs.edu/fisid_XXXXX","http://vivo.uccs.edu/deptid_XXXX","1435","Chair","http://vivoweb.org/ontology/core#FacultyAdministrativePosition","2","2"
- "http://vivo.uccs.edu/fisid_XXXXX","http://vivo.uccs.edu/deptid_XXXX","1419","Lecturer","http://vivoweb.org/ontology/core#FacultyPosition","5","4"
With information like this I go to the two individuals listed and make sure that they no longer have the positions of Chair or Lecturer. This let me know that my ingest was successful and to report that it's ready to migrate to production.
All in all the script took about an hour to construct and then run and saved me about 40 minutes of ingesting. Plus I was able to review VIVO after the ingests were finished for the data that should have changed, which is a big improvement over our previous methods of review.
Citation(s):
- Compare Two Files with Python by Frankie Bagnardi- http://aboutscript.com/blog/posts/107
- Python: iterate (and read) all files in a directory (folder) by Bogdon T - http://bogdan.org.ua/2007/08/12/python-iterate-and-read-all-files-in-a-directory-folder.html
Wednesday, March 7, 2012
Ubuntu Global Jam - Lessons I Learned
![]() |
| Ubuntu Cupcakes from Stacy Skaggs |
I learned quite a few little things to make life easier working on Ubuntu Websites. The first is a way of keeping the same development environments across project branches. This has always been an issue for me because with bzr you can't just bzr checkout branch-name and the code changes like git. Thats not its workflow. Michael Hall pointed me to this post which is the method he uses for all his bzr repositories. Basically, create a blank repository. Inside the repository you create a trunk with the code from launchpad. Then you branch the local copy into your feature/bug/issue branch. Finally you lightweight checkout that branch to a working repo folder. Sound confusing? It does at first. First off lightweight checkout doesn't import the code, just links to it. Meaning when you modify code, push code, commit code its happening from the named branch not from work. When you create your development environment around work, those files reference the work directory. So when you change to a different feature, bug or issue the environment files still point to work and you don't have to rebuild. Example commands:
bzr init-repo project-name
cd project-name
bzr branch lp:launchpad-bzr-name trunk
bzr branch trunk issue-specific-name
bzr checkout --lightweight issue-specific-name work
The second thing I learned was virtualenv for python.
sudo apt-get install python-virtualenv
sudo apt-get install virtualenvwrapper
These separate the required environment for the ubuntu community websites from the installation of python you have installed and keeps everything nice and clean. Now little did I know I was using this sort of with the make commands, however, with knowledge comes control and understanding.
I also got to see a bit of python dbugging as Michael Hall and Chris Johnston worked on that for a bit. Ate some fantastic cupcakes, and had a great time getting to dedicate some time to Ubuntu with some pretty awesome people.
Wednesday, February 29, 2012
Whose to blame for the misunderstanding ...
A junior engineer has been given a feature to develop. A senior engineer has built the basic mockup of the page, hooked it into the framework, but as the engineer attempts he runs into issues. He asks, through email, how do I save to the database. Its a project from a different development group, but the senior engineer has been through their code so he suggest looking into one part of the site and view specific controller and view files. The junior engineer acknowledged and life moves on. A week later the junior engineer comes to the senior engineer and says he is still having issues, so they open his code. The junior engineer has created a new file (instead of following editing the files already apart of the application structure) and is attempting to drive logic that belongs in the controller in a file in the view. He has ignored the structure of the site and is basically fighting against the natural flow of the program. At first glance I'd say this is a lack of understanding of MVC. However, this is not the first MVC project for this junior engineer.
Its a story playing itself over and over again in different ways. At first glance, I'd assume the engineer never looked at the example files and project flow, instead they just looked up "PHP connect to database". His code suggest that perhaps he looked at it, but didn't understand how the application uses the files. Perhaps the senior engineer should have called the junior engineer over and shown them the files and explained the various methods in play to save and how they work with the view.
A friend of mine once mentioned a similar issue with contractors in the corporate landscape. When he worked with them, over time he found himself practically programming the feature in the documentation to get the functionality he needed. Inevitably they fought the existing application and built extraneous files. At one point thier source had 4 different time classes that returned the time.
So how do we fix this without resorting to writing the program on a piece of paper and turning our junior engineers into a programming steno pool? Is this a hiring issue, should we let junior engineers like this go? A communication issue, did we not explain the solution completely should we have diagrammed it out? A language barrier? A training problem? An experience issue?
At this time ... I'm lost, perhaps time will bring insight.
Friday, January 20, 2012
Passion Breeds Collaboration While Lack of it Breeds Indifference
I'll put the user in a box
Ever go to the doctor's office full of questions and ideas about a long term illness you may have? Perhaps that's only me.How did the doctor act? Did he engage you in conversation? Did he seem to ignore you? Did he dismiss your questions? Did he answer everything you asked and perhaps ask some of his own?
Have you ever been apart of an open source project? On a mail list with other eager users and developers? How did you react the last time someone sent in a question or suggestion? Did you give them feedback? Did you bypass the email based on subject? Did you request more from them, perhaps code or testing? Did you taunt them with your superior knowledge?
A friend of mine and I were talking about doctors and we came to the conclusion that the best doctors were the ones that wanted your input on your care. It felt like it was because they were passionate about their jobs. It seemed to us that the doctors who weren't either had lost the spark, or were only interested in medicine for the prestige, money, or perhaps family history (my father and his father and his father's father, etc). That somehow led us to talking about open source projects and our time on one. I came to realize that my passion for the project and for my career affected my involvement with the project.
When I was a developer I loved to hear from everyone. I read every email, I was always on IRC. As I moved into a manager role I became more remote. I was hardly on IRC, I usually ignored listserv email. Tickets from users were no longer wonderful feedback but annoying things that they could have fixed themselves. My attitude dropped as I moved from that which I'm passionate about to something that I'm not. So, I've stopped managing that project and tried to go back to engaging and coding. The passion, its coming back, a bit slowly but only time will tell.
So the moral of this story? When you are dealing with some a-hole professional don't be quick to judge. Perhaps he made a wrong turn and is in a position that he has no passion for. Instead of cursing him, say a little pray hoping he'll find his way to a profession he is passionate about.
Monday, January 9, 2012
Engineer, Developer, Programmer, Analyst ... pick one?
I remember a while back my old boss mentioning he had chosen the working title of "Software Engineer" for positions at work because Engineers are not "web masters". When I started this article I had been looking at positions on-line and I noticed a mix of definitions for the same work: Programmers, Software Developer, Software Engineer, Analyst.
From Dictonary.com
Long ago we compartmentalized the field. Analysts analyzed the needs of the customer and came up with the design then handed it off to programmers who actually created the application. As the field has matured we learned a little bit about ourselves, we all like to design but secretly need to create too. Software Engineers and Developers have come to embody a unified process of design, development, and implementation. As you go up the technical ladder you design and mentor more than you write and test, but those things do not go away absolutely.
What is the difference between engineers and developers? At first glance an engineer is a highly exact individual from a school of engineering. However, in reality the difference is field of work. Web companies, business groups, and application centered hardware agnostic positions tend to be described as Software Developers. Technology companies and hardware centered positions tend to be described as Software Engineers. As members of the software field both have to design the application to the users specification, write the application, and develop tests of that system. Its the nature of the field.
From Dictonary.com
- Software Engineer - a person who designs and writes and tests computer programs
- Software Developer - No Definition
- Analyst - a person who analyzes
- Programmer - a person who writes computer programs.
Long ago we compartmentalized the field. Analysts analyzed the needs of the customer and came up with the design then handed it off to programmers who actually created the application. As the field has matured we learned a little bit about ourselves, we all like to design but secretly need to create too. Software Engineers and Developers have come to embody a unified process of design, development, and implementation. As you go up the technical ladder you design and mentor more than you write and test, but those things do not go away absolutely.
What is the difference between engineers and developers? At first glance an engineer is a highly exact individual from a school of engineering. However, in reality the difference is field of work. Web companies, business groups, and application centered hardware agnostic positions tend to be described as Software Developers. Technology companies and hardware centered positions tend to be described as Software Engineers. As members of the software field both have to design the application to the users specification, write the application, and develop tests of that system. Its the nature of the field.
Saturday, December 17, 2011
Continuing Education for a Programmer
![]() |
| CSE at UF |
Web Programming
The piece that makes web programming different from say standard gui applications is the web itself. You have HTML and CSS and javascript on top of frameworks and server languages and databases. Its a lot of different angles to become proficient in. Start small and work your way in. Some resources for learning more about the web.
- CSS Zen Garden - Why do we use CSS? This is why, a perfectly structured site that can look completely different with the change in a style sheet.
- w3 schools - The W3 decides web standards, though browsers are sometimes lacking in following them. They have a ton of tutorials on their site, check it out.
Becoming better programmers doesn't always involve reading books about programming. It could be a book about a developer, or a book about a methodology. Some books you all should consider reading over your break
- The Cathedral and the Baazar
- Ever heard of Eric S Raymond? This essay talks about the
differences between Open Source and traditional development. The book
contains his original essay and other articles he has written, you can
find all of his articles on his site.
- The Art of Unix Programming - Another ESR Book about the philosophies of decisions made in building unix. It can get preachy at times, but push through you'll be glad you did.
- The Mythical Man Month
- Want to be a project or technical manager some day? Read this book.
Its probably been
suggested in class and if you were like me, you ignored it as you had
three other classes suggesting 6 books a piece just like it.
- Just for Fun - The autobiography of Linus Torvolds. It is not a technical book at all, but a very good read.
- The Design
of Design - another Fred Brooks book, this one I have yet to start
but it has excellent reviews and reading the overview it sounded like a
good read for anyone in Software Development.
- Design Patterns - Very interesting book for those who love algorithm and technical design. If you've taken the Oo class its required reading.
- Joel on Software
- Joel Spolsky has worked all over the map in software development,
from programmer to manager to tech writer. He isn't
as prolific anymore, but there are some really great articles in his
archive. He is one half of the minds behind Stack Overflow and created
Trello
- Coding Horror - Jeff Atwood another almost former blogger he has been picking up momentum again recently. He is the other half behind Stack Overflow.
- Mark Shuttleworth - Started following his blog after last years UDS, he has some interesting posts on a variety of subjects.
If you have been around technology for a while you may already have a couple of technology sites that you read ever day. For me its
- The Linux Journal
- the original linux magazine
- LWN - from NickS its another source of linux news
- Ars Technica
- A great aggregator of technical and science news
- Wired - Its wired the magazine on the web
- Slashdot - another technology news website
I keep throwing out things like Code Review, Gerrit, and Jenkins during our standups. These are things that are coming down the pipeline at CTRIP, but why are they coming at all? Being a better developer involves immersing yourself in new technologies and methodologies and being able to distinguish the fads from the game changers. Use Google and Wikipedia to your advantage and look up things you are hearing in class and around the office. Some key terms to "google" that have been floating around lately
- Agile Development
- KanBan
- Bazaar
- Gerrit
- Code Review
- Testing (there are different kinds than just Unit, Integration, and Acceptance)
- Jenkins
- HTML 5
- SPARQL
- Semantic Web
- Linked Open Data
- Bio-Medical Informatics vs BioInformatics
- Clinical Trial
- Personalized Medicine
- Translational Science
You may notice that I often give you all(my team as this was originally written for just them) a vague idea of how it should work and then expect you to go find the actual solution. Why is that? Its because I have experience in other frameworks and know how to do what we are talking about in them, but perhaps not exactly in grails. Learning additional web frameworks and in other languages will often connect concepts in your primary framework that you haven't already grasped. Think of it as looking at web programming from a different angle. The perspective is different so there are differences, but their are also similarities. A couple of good frameworks to get started in:
- CakePHP (this is our other framework at CTRIP/ESE)
- Django - a python framework similar to cake and grails
- ASP.NET MVC 3
- a complete 180 from our usual style but not a bad idea to understand a
completely different viewpoint. As students you should
be able to get VS 2008 for free or use Visual Web Developer Express.
Use C# as its closest to Java. Just be careful of the differences like
toString() which in C# is ToString() ... very annoying.
- Spring
- one of the layers that Grails is built upon. Its a good idea to
learn Spring without Grails to better understand Grails itself
Subscribe to:
Posts (Atom)

