[CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacces-as-a-service-solution. My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Erik, I haven't tried it (recently) on PaaS providers, but I have on IaaS. The AMIs I've created in association with start up scripts (if you're interested in seeing those let me know, I'd have to look for them somewhere or other) mean that the application automagically starts up on its own, all you need to do is go to the URL. I've used this as a back up method in the past and I think would be a great way for people to be able to play with the different apps before committing. To this end, I created an AMI for Blacklight a while back: http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out of date. I also have instructions on creating an EBS backed AMI: http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which is the method I used for creating the Blacklight AMI. These instructions are also fairly old, but I still get comments on my blog now and then that the method works. I also played around with it on Heroku, but that was so long ago I don't think any of the things I learned still apply (this was when Heroku was fairly new to the scene). Hope some of this helps. Rosalyn On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland svhoo...@ulb.ac.bewrote: Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacces-as-a-service-solution . My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Hi, I've deployed Blacklight on both Heroku and Elastic BeanStalk. Heroku is still a much better choice. The only issue I had was I needed to make sure the sass-rails gem in installed in the :production gem group and not just development. I still have an issue of getting heroku to compile all my sass/coffeescript/etc assets on update, but it actually doesn't seem to make much of an impact on performance. The minor issue is that it would be nice to figure out a way to slim down BL's slug size. The lowest I've been able to get it is about 30mb and Heroku recommends having it be below 25mb. I have not used Heroku's solr service (I still use EC2 for my solr deployments). EngineYard would also be another option. There is also an AMI for DSpace, so deploying that to EC2 should be pretty easy b,chris. On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz rosalynm...@gmail.com wrote: Erik, I haven't tried it (recently) on PaaS providers, but I have on IaaS. The AMIs I've created in association with start up scripts (if you're interested in seeing those let me know, I'd have to look for them somewhere or other) mean that the application automagically starts up on its own, all you need to do is go to the URL. I've used this as a back up method in the past and I think would be a great way for people to be able to play with the different apps before committing. To this end, I created an AMI for Blacklight a while back: http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out of date. I also have instructions on creating an EBS backed AMI: http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which is the method I used for creating the Blacklight AMI. These instructions are also fairly old, but I still get comments on my blog now and then that the method works. I also played around with it on Heroku, but that was so long ago I don't think any of the things I learned still apply (this was when Heroku was fairly new to the scene). Hope some of this helps. Rosalyn On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland svhoo...@ulb.ac.bewrote: Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacces-as-a-service-solution . My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
If you already have everything indexed in Solr elsewhere, a way to cut down the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable. -Sean On 3/29/12 12:16 PM, Chris Fitzpatrick chrisfitz...@gmail.com wrote: Hi, I've deployed Blacklight on both Heroku and Elastic BeanStalk. Heroku is still a much better choice. The only issue I had was I needed to make sure the sass-rails gem in installed in the :production gem group and not just development. I still have an issue of getting heroku to compile all my sass/coffeescript/etc assets on update, but it actually doesn't seem to make much of an impact on performance. The minor issue is that it would be nice to figure out a way to slim down BL's slug size. The lowest I've been able to get it is about 30mb and Heroku recommends having it be below 25mb. I have not used Heroku's solr service (I still use EC2 for my solr deployments). EngineYard would also be another option. There is also an AMI for DSpace, so deploying that to EC2 should be pretty easy b,chris. On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz rosalynm...@gmail.com wrote: Erik, I haven't tried it (recently) on PaaS providers, but I have on IaaS. The AMIs I've created in association with start up scripts (if you're interested in seeing those let me know, I'd have to look for them somewhere or other) mean that the application automagically starts up on its own, all you need to do is go to the URL. I've used this as a back up method in the past and I think would be a great way for people to be able to play with the different apps before committing. To this end, I created an AMI for Blacklight a while back: http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out of date. I also have instructions on creating an EBS backed AMI: http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which is the method I used for creating the Blacklight AMI. These instructions are also fairly old, but I still get comments on my blog now and then that the method works. I also played around with it on Heroku, but that was so long ago I don't think any of the things I learned still apply (this was when Heroku was fairly new to the scene). Hope some of this helps. Rosalyn On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland svhoo...@ulb.ac.bewrote: Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce s-as-a-service-solution . My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Hey Sean, Jah, I did that...my .slugignore is: tmp/* log/* coverage/* spec/* koha/* jetty/* That dropped it down to 30 from ~50mb, so that's good . (koha has some scripts wrote to pull from our ILS). I think the slug size is a really minor issue. Heroku says under 25mb is good, but over 50mb is not so good. Not Good, but not Chaotic Evil . Neutral Good. On Thu, Mar 29, 2012 at 6:26 PM, Sean Hannan shan...@jhu.edu wrote: If you already have everything indexed in Solr elsewhere, a way to cut down the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable. -Sean On 3/29/12 12:16 PM, Chris Fitzpatrick chrisfitz...@gmail.com wrote: Hi, I've deployed Blacklight on both Heroku and Elastic BeanStalk. Heroku is still a much better choice. The only issue I had was I needed to make sure the sass-rails gem in installed in the :production gem group and not just development. I still have an issue of getting heroku to compile all my sass/coffeescript/etc assets on update, but it actually doesn't seem to make much of an impact on performance. The minor issue is that it would be nice to figure out a way to slim down BL's slug size. The lowest I've been able to get it is about 30mb and Heroku recommends having it be below 25mb. I have not used Heroku's solr service (I still use EC2 for my solr deployments). EngineYard would also be another option. There is also an AMI for DSpace, so deploying that to EC2 should be pretty easy b,chris. On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz rosalynm...@gmail.com wrote: Erik, I haven't tried it (recently) on PaaS providers, but I have on IaaS. The AMIs I've created in association with start up scripts (if you're interested in seeing those let me know, I'd have to look for them somewhere or other) mean that the application automagically starts up on its own, all you need to do is go to the URL. I've used this as a back up method in the past and I think would be a great way for people to be able to play with the different apps before committing. To this end, I created an AMI for Blacklight a while back: http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out of date. I also have instructions on creating an EBS backed AMI: http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which is the method I used for creating the Blacklight AMI. These instructions are also fairly old, but I still get comments on my blog now and then that the method works. I also played around with it on Heroku, but that was so long ago I don't think any of the things I learned still apply (this was when Heroku was fairly new to the scene). Hope some of this helps. Rosalyn On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland svhoo...@ulb.ac.bewrote: Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce s-as-a-service-solution . My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Hi Erik, While my FRBR-Redis datastore is not yet a common LIS application, I develop and run it on a Rackspace Linux VM with Django and Redis. I am in the process of migrating this stack over to Heroku for a Library App development workshop I'm leading in May. Jeremy Nelson Metadata and Systems Librarian Tutt Library, Colorado College -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Erik Mitchell Sent: Thursday, March 29, 2012 6:11 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers? Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Chris - where did you deploy your SOLR instance and did that create any issues for deployment (other than ignoring files)? Erik On Thu, Mar 29, 2012 at 12:37 PM, Chris Fitzpatrick chrisfitz...@gmail.com wrote: Hey Sean, Jah, I did that...my .slugignore is: tmp/* log/* coverage/* spec/* koha/* jetty/* That dropped it down to 30 from ~50mb, so that's good . (koha has some scripts wrote to pull from our ILS). I think the slug size is a really minor issue. Heroku says under 25mb is good, but over 50mb is not so good. Not Good, but not Chaotic Evil . Neutral Good. On Thu, Mar 29, 2012 at 6:26 PM, Sean Hannan shan...@jhu.edu wrote: If you already have everything indexed in Solr elsewhere, a way to cut down the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable. -Sean On 3/29/12 12:16 PM, Chris Fitzpatrick chrisfitz...@gmail.com wrote: Hi, I've deployed Blacklight on both Heroku and Elastic BeanStalk. Heroku is still a much better choice. The only issue I had was I needed to make sure the sass-rails gem in installed in the :production gem group and not just development. I still have an issue of getting heroku to compile all my sass/coffeescript/etc assets on update, but it actually doesn't seem to make much of an impact on performance. The minor issue is that it would be nice to figure out a way to slim down BL's slug size. The lowest I've been able to get it is about 30mb and Heroku recommends having it be below 25mb. I have not used Heroku's solr service (I still use EC2 for my solr deployments). EngineYard would also be another option. There is also an AMI for DSpace, so deploying that to EC2 should be pretty easy b,chris. On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz rosalynm...@gmail.com wrote: Erik, I haven't tried it (recently) on PaaS providers, but I have on IaaS. The AMIs I've created in association with start up scripts (if you're interested in seeing those let me know, I'd have to look for them somewhere or other) mean that the application automagically starts up on its own, all you need to do is go to the URL. I've used this as a back up method in the past and I think would be a great way for people to be able to play with the different apps before committing. To this end, I created an AMI for Blacklight a while back: http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out of date. I also have instructions on creating an EBS backed AMI: http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which is the method I used for creating the Blacklight AMI. These instructions are also fairly old, but I still get comments on my blog now and then that the method works. I also played around with it on Heroku, but that was so long ago I don't think any of the things I learned still apply (this was when Heroku was fairly new to the scene). Hope some of this helps. Rosalyn On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland svhoo...@ulb.ac.bewrote: Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce s-as-a-service-solution . My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas about what issues I might run into. Thanks, Erik Erik Mitchell Assistant Professor College of Information Studies University of Maryland, College Park http://ischool.umd.edu
[CODE4LIB] Strategies and use-cases library search box
Dear All At Ghent Universty Library in Belgium we are re-evaluating our web strategy in several internal workshops with faculty librarians. The theme of our next meeting will be about discovery, and one-search-box integrated search solutions. We see these days a lot of vendors and cloud providing solutions that provide these features which addresses strategic goals of libraries. We are also interested in a methodological question: what are the underlying use-cases libraries are trying to solve for where a new suite of services provide a solution. Does you have insights you are willing to share. Searching for methodologies, principles of heuristics, statistics, research and teaching practices. Best from Belgium Patrick Skype: patrick.hochstenbach Patrick Hochstenbach Digital Architect University Library+32(0)92647980 Ghent University * Rozier 9 * 9000 * Gent
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Like Chris, I've deployed Blacklight on Heroku, and this thread (particularly Rosalyn's message) has gotten me to write up a quick HOWTO on the Blacklight wiki [0]. For Solr hosting I've used both a VM that I run (on Slicehost) and EC2. Mark [0] https://github.com/projectblacklight/blacklight/wiki/Blacklight-on-Heroku
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Neat! Thanks Mark, Erik On Thu, Mar 29, 2012 at 2:19 PM, Mark A. Matienzo m...@matienzo.org wrote: Like Chris, I've deployed Blacklight on Heroku, and this thread (particularly Rosalyn's message) has gotten me to write up a quick HOWTO on the Blacklight wiki [0]. For Solr hosting I've used both a VM that I run (on Slicehost) and EC2. Mark [0] https://github.com/projectblacklight/blacklight/wiki/Blacklight-on-Heroku
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Older 3.x versions of Blacklight may have put a solrmarc.jar inside your app's ./config/SolrMarc. That may not be caught by your slug ignore. This was an error, it was never meant to do that. If you have one in a BL 3.x you should be safe to remove it. Other than that, I'm curious what's making a BL app so large! Incidentally, you don't need a ./jetty in your local app _at all_, unless you actually want to keep a jetty Solr there. BL will optionally install one there, but it's not required. (Does slug size include your gem dependencies? I am not familiar with heroku. Cause the BL gem itself _does_ also include a SolrMarc.jar, if that's a problem, we'd have to refactor things on the BL side to make it an optional dependency instead of baked into BL). On 3/29/2012 12:37 PM, Chris Fitzpatrick wrote: Hey Sean, Jah, I did that...my .slugignore is: tmp/* log/* coverage/* spec/* koha/* jetty/* That dropped it down to 30 from ~50mb, so that's good . (koha has some scripts wrote to pull from our ILS). I think the slug size is a really minor issue. Heroku says under 25mb is good, but over 50mb is not so good. Not Good, but not Chaotic Evil . Neutral Good. On Thu, Mar 29, 2012 at 6:26 PM, Sean Hannanshan...@jhu.edu wrote: If you already have everything indexed in Solr elsewhere, a way to cut down the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable. -Sean On 3/29/12 12:16 PM, Chris Fitzpatrickchrisfitz...@gmail.com wrote: Hi, I've deployed Blacklight on both Heroku and Elastic BeanStalk. Heroku is still a much better choice. The only issue I had was I needed to make sure the sass-rails gem in installed in the :production gem group and not just development. I still have an issue of getting heroku to compile all my sass/coffeescript/etc assets on update, but it actually doesn't seem to make much of an impact on performance. The minor issue is that it would be nice to figure out a way to slim down BL's slug size. The lowest I've been able to get it is about 30mb and Heroku recommends having it be below 25mb. I have not used Heroku's solr service (I still use EC2 for my solr deployments). EngineYard would also be another option. There is also an AMI for DSpace, so deploying that to EC2 should be pretty easy b,chris. On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metzrosalynm...@gmail.com wrote: Erik, I haven't tried it (recently) on PaaS providers, but I have on IaaS. The AMIs I've created in association with start up scripts (if you're interested in seeing those let me know, I'd have to look for them somewhere or other) mean that the application automagically starts up on its own, all you need to do is go to the URL. I've used this as a back up method in the past and I think would be a great way for people to be able to play with the different apps before committing. To this end, I created an AMI for Blacklight a while back: http://www.rosalynmetz.com/ami-3c10f255/ I guarantee you it is grossly out of date. I also have instructions on creating an EBS backed AMI: http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which is the method I used for creating the Blacklight AMI. These instructions are also fairly old, but I still get comments on my blog now and then that the method works. I also played around with it on Heroku, but that was so long ago I don't think any of the things I learned still apply (this was when Heroku was fairly new to the scene). Hope some of this helps. Rosalyn On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hoolandsvhoo...@ulb.ac.bewrote: Dear Erik, Bram Wiercx and myself have given a talk on how to put together a package to install CollectiveAccess on Red Hat's OpenShift: http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce s-as-a-service-solution . My students are currently happily playing around with CollectiveAccess, which they have installed on OpenShift. My teaching assistant Max De Wilde has developed clear guidelines on how to run the installation procedure: http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf. It would be wonderful to aggregate these kind of installation procedure's for other types of LIS applications... Kind regards and looking forward to your book! Seth van Hooland Président du Master en Sciences et Technologies de l'Information et de la Communication (MaSTIC) Université Libre de Bruxelles Av. F.D. Roosevelt, 50 CP 123 | 1050 Bruxelles http://homepages.ulb.ac.be/~svhoolan/ http://twitter.com/#!/sethvanhooland http://mastic.ulb.ac.be 0032 2 650 4765 Office: DC11.113 Le 29 mars 2012 à 14:10, Erik Mitchell a écrit : Hi all, I have been toying with the process of implementing common LIS applications (e.g. Vufind, Dspace, Blacklight. . .) on PaaS providers like Heroku and Amazon Elastic Beanstalk. I have just tried out of the box distributions so far and have not made much progress but was wondering if someone else had tried this or had ideas
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Hey Erik, I used this AMI for solr = http://www.lucidimagination.com/blog/2010/02/01/solr-shines-through-the-cloud-lucidworks-solr-on-ec2/ Note : You will have to change the schema and solrconfig files on the image... b,chris. On Thu, Mar 29, 2012 at 9:44 PM, Erik Mitchell mitch...@gmail.com wrote: Neat! Thanks Mark, Erik On Thu, Mar 29, 2012 at 2:19 PM, Mark A. Matienzo m...@matienzo.org wrote: Like Chris, I've deployed Blacklight on Heroku, and this thread (particularly Rosalyn's message) has gotten me to write up a quick HOWTO on the Blacklight wiki [0]. For Solr hosting I've used both a VM that I run (on Slicehost) and EC2. Mark [0] https://github.com/projectblacklight/blacklight/wiki/Blacklight-on-Heroku
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
Oh, yeah...Mark's wiki page also points out that you'll need to change to postgres for production. Very important. From what I understand, the compiled slug is the app + all it's dependancies. So, yeah, I guess since the gem does have the SolrMarc.jar in there, it would have the jar in the slug somewhere However, I did just see a page on heroku that says: Generally speaking any slug under 15MB is small and nimble; 30MB is average; and 50MB or above is weighty. So maybe I was being slightly over sensitive to my slug's size? I was just worried all the other slugs would call it names. I am going to try and figure out why my pipeline assets aren't compiling when I push. The solution is probably just to compile them locally and push them rather than rely on Heroku to precompile them (currently when I push, Heroku's precompile fails, so it reverts to compile at runtime mode) if anyone has insight into this, please lemme know...I believe having them compile at runtime does slow down the application... b,chris. On Thu, Mar 29, 2012 at 10:49 PM, Chris Fitzpatrick chrisfitz...@gmail.com wrote: Hey Erik, I used this AMI for solr = http://www.lucidimagination.com/blog/2010/02/01/solr-shines-through-the-cloud-lucidworks-solr-on-ec2/ Note : You will have to change the schema and solrconfig files on the image... b,chris. On Thu, Mar 29, 2012 at 9:44 PM, Erik Mitchell mitch...@gmail.com wrote: Neat! Thanks Mark, Erik On Thu, Mar 29, 2012 at 2:19 PM, Mark A. Matienzo m...@matienzo.org wrote: Like Chris, I've deployed Blacklight on Heroku, and this thread (particularly Rosalyn's message) has gotten me to write up a quick HOWTO on the Blacklight wiki [0]. For Solr hosting I've used both a VM that I run (on Slicehost) and EC2. Mark [0] https://github.com/projectblacklight/blacklight/wiki/Blacklight-on-Heroku
Re: [CODE4LIB] Anyone implementing common LIS applications on PaaS providers?
On 3/29/2012 5:05 PM, Chris Fitzpatrick wrote: locally and push them rather than rely on Heroku to precompile them (currently when I push, Heroku's precompile fails, so it reverts to compile at runtime mode) if anyone has insight into this, please lemme know...I believe having them compile at runtime does slow down the application... Have no idea why it's not working in heroku, no experience with heroku (although I'm familiar with the concept). But compile at runtime _will_ slow down your app, yeah. Here's a stackoverflow I asked on it myself: http://stackoverflow.com/questions/8821864/config-assets-compile-true-in-rails-production-why-not Compiling locally and then pushing should work, and is arguably better in some ways (why waste cycles on the production machine compiling assets?) But, if you choose to compile and check into your source control repo, here's a trick that will keep it from driving you crazy in development using your on-disk compiled assets... eh, I can't find the blog post on google now, but it's something like changing config.assets.path = /dev-assets in environments/development.rb, so in development it will ignore your on disk compiled assets.
Re: [CODE4LIB] presenting merged records?
Hi Graham, What we do in our federated search system, and have been doing for some few years, is basically give the designer a choice of what options the user gets for de-duped records. Firstly de-duping can be of a number of levels of sophistication, and a many of them lead to the situation you have - records which are similar rather than identical. On the web search side of things there are a surprising number of real duplicates (well maybe not surprising if you study more than one page of web search engine results), and on Twitter the duplicates well outnumber the original posts (many thanks 're-tweet'). Where we get duplicate records the usual options are: 1) keep the first and just drop all the rest. 2) keep the largest (assumed to have the most information) and drop the rest. These work well for WSE results where they are all almost identical (the differences often are just in the advertising attached to the pages and the results), but not for bibliographic records. Less draconian is 3) Mark all the duplicates and keep them in the list (so you get 1, 2, 3, 4, 5, 5.1, 5.2, 5.3, 6, ...). This groups all the similar records together under the sort key of the first one, and does enable the user to easily skip them. More user friendly is 4) Mark all duplicates and hide them in a sub-list attached to the head record. This gets them out of the main display, but allows the user who is interested in that record to expand the list and see the variants. This could be of use to you. After that we planned to do what you are proposing and actually merge record content into a single virtual record, and worked on algorithms to do it. But nobody was interested. All our partners (who provide systems to lots of libraries, both public, academic, and special) decided that it would confuse their users more than it would help. I have my doubts, but they spoke and we put the development on ice. I'm not sure this will help, but it has stood the test of time, and is well used in its various guises. Since no-one else seems interested in this topic, you could email me off list and we could discuss what we worked through in the way of algorithms, etc. Peter -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of graham Sent: Wednesday, March 28, 2012 8:05 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] presenting merged records? Hi Michael On 03/27/12 11:50, Michael Hopwood wrote: Hi Graham, do I know you from RHUL? Yes indeed :-) My thoughts on merged records would be: 1. don't do it - use separate IDs and just present links between related manifestations; thus avoiding potential confusions. In my case, I can't avoid it as it's a specific requirement: I'm doing a federated search across a large number of libraries, and if closely similar items aren't merged, the results become excessively large and repetitive. I'm merging all the similar items, displaying a summary of the merged bibliographic data, and providing links to each of the libraries with a copy. So it's not really FRBRization in the normal sense, I just thought that FRBRization would lead to similar problems, so that there might be some well-known discussion of the issues around... The merger of the records does have advantages, especially if some libraries have very underpopulated records (eg subject fields). Cheers Graham http://www.bic.org.uk/files/pdfs/identification-digibook.pdf possible relationships - see http://www.editeur.org/ONIX/book/codelists/current.html - lists 51 (manifestation)and 164 (work). 2. c.f. the way Amazon displays rough and ready categories (paperback, hardback, audiobooks, *ahem* ebooks of some sort...) On dissection and reconstitution of records - there is a lot of talk going on about RDFizing MaRC records and re-using in various ways, e.g.: http://www.slideshare.net/JenniferBowen/moving-library-metadata-toward -linked-data-opportunities-provided-by-the-extensible-catalog Cheers, Michael -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of graham Sent: 27 March 2012 11:06 To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] presenting merged records? Hi There seems to be a general trend to presenting merged records to users, as part of the move towards FRBRization. If records need merging this generally means they weren't totally identical to start with, so you can end up with conflicting bibliographic data to display. Two examples I've come across with this: Summon can merge print/electronic versions of texts, so uses a new 'merged' material type of 'book/ebook' (it doesn't yet seem to have all the other possible permutations, eg book/audiobook). Pazpar2 (which I'm working with at the moment) has a merge option for publication dates which presents dates as a period eg
