Fixed blog links to point to new /entries/ folder.

Author: kgodey

content/archives/old-tech-blog/entries/32-to-64bit-remotely/contents.lr

@@ -8,7 +8,7 @@ author: nkinkade
 ---
 body:
 
-A couple months ago I [posted here](/archives/old-tech-blog/varnish-cache-at-cc/) about some of our experiences with [Varnish Cache](http://varnish.projects.linpro.no/) as an HTTP accelerator. By and large I have been very impressed with Varnish. We even found that it had the unexpected benefit of acting as a buffer in front of Apache, preventing Apache from getting overwhelmed with too many slow requests. Apache would get wedged once it had reached it's MaxClients limit, whereas Varnish seems to happily queue up thousands of requests even if the backend (Apache) is going slowly.
+A couple months ago I [posted here](/archives/old-tech-blog/entries/varnish-cache-at-cc/) about some of our experiences with [Varnish Cache](http://varnish.projects.linpro.no/) as an HTTP accelerator. By and large I have been very impressed with Varnish. We even found that it had the unexpected benefit of acting as a buffer in front of Apache, preventing Apache from getting overwhelmed with too many slow requests. Apache would get wedged once it had reached it's MaxClients limit, whereas Varnish seems to happily queue up thousands of requests even if the backend (Apache) is going slowly.
 
 However, after a while we started running into other problems with Varnish, and I found the probable answer in [a bug report](http://varnish.projects.linpro.no/ticket/85) at the Varnish site. It turns out that Varnish was written with a 64 bit system in mind. That isn't to say that it won't work nicely on a 32 bit system, just that you better not expect high server load, or else you'll start running into resource limitations in a hurry. This left us with about 2 options: Move to 64 bit or ditch Varnish for something like Squid. Seeing as how I was loathe to do the latter, we decided to go 64 bit, which in any case is another logical step into the 21st century.
 

content/archives/old-tech-blog/entries/berliosde-back-online/contents.lr

@@ -8,7 +8,7 @@ author: nathan
 ---
 body:
 
-After the downtime we "reported":/archives/old-tech-blog/cc-tools-berlios-unavailable/ this morning, Berlios is back online. ccPublisher "downloads":http://wiki.creativecommons.org/CcPublisher are now available again. We'll be mirroring the downloads to another server to protect against future outages.
+After the downtime we "reported":/archives/old-tech-blog/entries/cc-tools-berlios-unavailable/ this morning, Berlios is back online. ccPublisher "downloads":http://wiki.creativecommons.org/CcPublisher are now available again. We'll be mirroring the downloads to another server to protect against future outages.
 
 ---
 pub_date: 2007-04-23

content/archives/old-tech-blog/entries/caching-deeds-for-peak-performance/contents.lr

@@ -7,7 +7,7 @@ author: nathan
 ---
 body:
 
-As Chris [mentioned](/archives/old-tech-blog/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/), he's been working on improving the [license chooser](http://creativecommons.org/choose/), among other things simplifying it and making it a better behaved [WSGI](http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface) citizen. That code also handles generating the license deeds. For performance reasons we like to serve those from static files; I [put together some details](http://yergler.net/blog/2010/01/05/caching-wsgi-applications-to-disk/) about [wsgi_cache](http://pypi.python.org/pypi/wsgi_cache), a piece of WSGI middleware I wrote this week to help with this, on my [personal blog](http://yergler.net/blog/):
+As Chris [mentioned](/archives/old-tech-blog/entries/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/), he's been working on improving the [license chooser](http://creativecommons.org/choose/), among other things simplifying it and making it a better behaved [WSGI](http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface) citizen. That code also handles generating the license deeds. For performance reasons we like to serve those from static files; I [put together some details](http://yergler.net/blog/2010/01/05/caching-wsgi-applications-to-disk/) about [wsgi_cache](http://pypi.python.org/pypi/wsgi_cache), a piece of WSGI middleware I wrote this week to help with this, on my [personal blog](http://yergler.net/blog/):
 
 > The idea behind wsgi_cache is that you create a disk cache for results, caching only the body of the response. We only cache the body for a simple reason—we want something else, something faster, like Apache or other web server, to serve the request when it’s a cache hit. We’ll use mod_rewrite to send the request to our WSGI application when the requested file doesn’t exist; otherwise it hits the on disk version. And cache “invalidation” becomes as simple as rm (and as fine grained as single resources).
 

content/archives/old-tech-blog/entries/cc-engine-and-web-non-frameworks/contents.lr

@@ -9,7 +9,7 @@ author: cwebber
 ---
 body:
 
-The [sanity overhaul](/archives/old-tech-blog/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/) has included a number of reworkings, one of them being a rewrite of cc.engine, which in its previous form was a Zope 3 application. Zope is a full featured framework and we already knew we weren't using many of its features (most notably the ZODB); we suspected that something simpler would serve us better, but weren't certain what. Nathan suggested one of two directions: either we go with Django (although it wasn't clear this was "simpler", it did seem to be where a large portion of the python knowledge and effort in the web world is pooling), or we go with [repoze.bfg](http://docs.repoze.org/bfg/), a minimalist WSGI framework that pulls in some Zope components. After some discussion we both agreed: repoze.bfg seemed like the better choice for a couple of reasons: for one, Django seemed like it would be providing quite a bit more than necessary... in cc.engine we don't have a traditional database (we do have an RDF store that we query, but no SQL), we don't have a need for a user model, etc... the application is simple: show some pages and apply some specialized logic. Second, repoze.bfg built upon and reworked Zope infrastructure and paradigms, and so in that sense it looked like an easier transition. So we went forward with that.
+The [sanity overhaul](/archives/old-tech-blog/entries/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/) has included a number of reworkings, one of them being a rewrite of cc.engine, which in its previous form was a Zope 3 application. Zope is a full featured framework and we already knew we weren't using many of its features (most notably the ZODB); we suspected that something simpler would serve us better, but weren't certain what. Nathan suggested one of two directions: either we go with Django (although it wasn't clear this was "simpler", it did seem to be where a large portion of the python knowledge and effort in the web world is pooling), or we go with [repoze.bfg](http://docs.repoze.org/bfg/), a minimalist WSGI framework that pulls in some Zope components. After some discussion we both agreed: repoze.bfg seemed like the better choice for a couple of reasons: for one, Django seemed like it would be providing quite a bit more than necessary... in cc.engine we don't have a traditional database (we do have an RDF store that we query, but no SQL), we don't have a need for a user model, etc... the application is simple: show some pages and apply some specialized logic. Second, repoze.bfg built upon and reworked Zope infrastructure and paradigms, and so in that sense it looked like an easier transition. So we went forward with that.
 
 As I went on developing it, I started to feel more and more like, while repoze.bfg certainly had some good ideas, I was having to create a lot of workarounds to support what I needed. For one thing, the URL routing is unordered and based off a ZCML config file. It was at the point where, for resolving the license views, I had to route to a view method that then called other view methods. We also needed a type of functionality as Django provides with its "APPEND_SLASH=True" feature. I discussed with the repoze.bfg people, and they were accommodating to this idea and actually applied it to their codebase for the next release. There were some other components they provided that were well developed but were not what we really needed (and were besides technically decoupled from repoze.bfg the core framework). As an example, the [chameleon zpt](http://chameleon.repoze.org/) engine is very good, but it was easier to just pull Zope's template functionality into our system than make the minor conversions necessary to go with chameleon's zpt.
 

content/archives/old-tech-blog/entries/cc-latam-analysis/contents.lr

@@ -11,7 +11,7 @@ Carolina Botero (of CC Colombia and now CC regional manager for Latin America) h
 
 As with [previous](http://web.si.umich.edu/tprc/papers/2007/805/CreateCommExp.pdf) looks at CC licenses across different jurisdictions and [regions](http://www.slideshare.net/gcheliotis/assessing-cc-adoption-in-asia-manila), this one is based on search engine reported links to jurisdiction "ported" versions of licenses. It is great to see what researchers have done with this limited mechanism.
 
-I am eager to explore other means of characterizing CC usage across regions and fields, and hope to provide more [data](/archives/old-tech-blog/available-for-analysis/) that will enable researchers to do this. This will be increasingly important as we attempt to forge a universal license that does not call for porting in the same way, with version 4.0 [over](http://wiki.creativecommons.org/Global_Summit_2011) the coming year (as well as with the increasing [importance](https://creativecommons.org/weblog/entry/28525) of CC in the world).
+I am eager to explore other means of characterizing CC usage across regions and fields, and hope to provide more [data](/archives/old-tech-blog/entries/available-for-analysis/) that will enable researchers to do this. This will be increasingly important as we attempt to forge a universal license that does not call for porting in the same way, with version 4.0 [over](http://wiki.creativecommons.org/Global_Summit_2011) the coming year (as well as with the increasing [importance](https://creativecommons.org/weblog/entry/28525) of CC in the world).
 
 ---
 pub_date: 2011-08-12

content/archives/old-tech-blog/entries/cc-openoffice-addin-update-added-impress-funcionality/contents.lr

@@ -14,7 +14,7 @@ Hello everyone!
 
 I've made some changes in the addin and enabled to put licenses in Impress documents. The entire architecture has changed and I'm working on this right now. The newer version is in the CC sourceforge repository!
 
-[![CC OpenOffice Addin working on Impress](screen_impress.PNG)](/archives/old-tech-blog/cc-openoffice-addin-update-added-impress-funcionality/cc-openoffice-addin-working-on-impress/ "CC OpenOffice Addin working on Impress")
+[![CC OpenOffice Addin working on Impress](screen_impress.PNG)](/archives/old-tech-blog/entries/cc-openoffice-addin-update-added-impress-funcionality/cc-openoffice-addin-working-on-impress/ "CC OpenOffice Addin working on Impress")
 
 ---
 pub_date: 2007-07-24

content/archives/old-tech-blog/entries/cc-rest-api-updated-for-public-domain-mark/contents.lr

@@ -10,7 +10,7 @@ body:
 
 This morning, the [Creative Commons REST API](http://api.creativecommons.org/docs/) was updated to include support for the [Public Domain Mark](http://creativecommons.org/weblog/entry/23830) and to deprecate the issuing of the retired [Public Domain Certification and Dedication](http://creativecommons.org/licenses/publicdomain/1.0/). We have also added a new element in license responses, that denotes whether or not the issued license has been deprecated by Creative Commons. These changes affect all versions of the REST API, excluding 1.0.
 
-Over the past year, there has been a collaborative effort by the CC Tech team to perform a "[sanity overhaul](/archives/old-tech-blog/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/)" on the tools and libraries that much of the CC Tech infrastructure relies on. Among the projects to be overhauled, there was the CC REST API, and it was trailing all of our other services in terms of currentness and ease of release iteration. The CC REST API was in need of a complete re-engineering effort so that it could be maintained and supported at the same level as our other newly-overhauled projects. We're glad to announce that the reworking of the REST API has been a success and our focus on refactoring over new features can now come to a close.
+Over the past year, there has been a collaborative effort by the CC Tech team to perform a "[sanity overhaul](/archives/old-tech-blog/entries/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/)" on the tools and libraries that much of the CC Tech infrastructure relies on. Among the projects to be overhauled, there was the CC REST API, and it was trailing all of our other services in terms of currentness and ease of release iteration. The CC REST API was in need of a complete re-engineering effort so that it could be maintained and supported at the same level as our other newly-overhauled projects. We're glad to announce that the reworking of the REST API has been a success and our focus on refactoring over new features can now come to a close.
 
 To get started using the CC REST API in your own projects, consult the [development version documentation](http://api.creativecommons.org/docs/readme_dev.html) or the [1.5 version documentation](http://api.creativecommons.org/docs/readme_15.html) if your software is ready for production. If you have any issues, feature requests, or questions about the REST API, then feel free to send a message to the [cc-devel mailing list](http://lists.ibiblio.org/mailman/listinfo/cc-devel) with your questions. To file a bug report with the REST API, please submit your issue to the API project in our [roundup bug tracker](http://code.creativecommons.org/issues/).
 

content/archives/old-tech-blog/entries/converting-cc-engine-from-zpt-to-jinja2-and-i18n-logical-keys-to-english-keys/contents.lr

@@ -8,7 +8,7 @@ body:
 
 ## Some CC-specfic background
 
-Right now I'm in the middle of retooling of our translation infrastructure. [cc.engine](http://code.creativecommons.org/viewgit/cc.engine.git/) and [related tools](/archives/old-tech-blog/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/) have a long, complex history (dating back, as I understand, to [TCL](http://en.wikipedia.org/wiki/Tcl) scripts running on [AOL server](http://www.aolserver.com/) software). The short of it is, CC's tools have evolved a lot over the years, and sometimes we're left with systems and tools that require a lot of organization-specific knowledge for historical reasons.
+Right now I'm in the middle of retooling of our translation infrastructure. [cc.engine](http://code.creativecommons.org/viewgit/cc.engine.git/) and [related tools](/archives/old-tech-blog/entries/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/) have a long, complex history (dating back, as I understand, to [TCL](http://en.wikipedia.org/wiki/Tcl) scripts running on [AOL server](http://www.aolserver.com/) software). The short of it is, CC's tools have evolved a lot over the years, and sometimes we're left with systems and tools that require a lot of organization-specific knowledge for historical reasons.
 
 This has been the case with CC's translation tools. Most of the world these days uses english-key translations. CC used logical key translations. This means that if you marked up a bit of text for translation, instead of the key being the actual text being translated (such as "About The Licenses"), the key would be an identifier code which mapped to said english string, like "util.View_Legal_Code". What's the problem with this? Actually, there are a number of benefits that I'll miss and that I won't get into here, but the real problem is that the rest of the translation world mostly doesn't work this way. We use [Transifex](http://transifex.net) (and previously used [Pootle](http://translate.sourceforge.net/wiki/pootle/index?redirect=1)) as a tool for our translators managing our translations. Since these tools don't expect logical keys we had to write tools to convert from logical keys to english keys on upload and english keys to logical keys back and a whole bunch of other crazy custom tooling.
 

content/archives/old-tech-blog/entries/creative-ommons-openoffice-plugin-supports-for-internationalization/contents.lr

@@ -17,7 +17,7 @@ Here I have used .class format for resource bundle because the plural forms can
 
 I have added two shell scripts to convert PO files to resource bundle and extract new strings. You can run them separately or use them when compiling the project. To use them when compiling uncomment line 75-82 of the build.xml, but conversion will take about 3 minutes to complete, therefore it is better to use the scripts separately only when you need add a new translation or extract new strings.
 
-Here is a screen shot of the GUI with some Spanish translated strings (I choose Spanish because of [this](/archives/old-tech-blog/creative-commons-open-office-plugin-here-it-is-with-some-new-features/#comment-15878) comment).
+Here is a screen shot of the GUI with some Spanish translated strings (I choose Spanish because of [this](/archives/old-tech-blog/entries/creative-commons-open-office-plugin-here-it-is-with-some-new-features/#comment-15878) comment).
 
 [caption id="" align="aligncenter" width="370" caption="GUI in Spanish"][![GUI in Spanish](Screenshot.png)](http://lh5.ggpht.com/_LE-WXW82VPE/TEMqN2H2JyI/AAAAAAAAAK4/hK2v1z-TP6c/Screenshot.png)[/caption]
 

content/archives/old-tech-blog/entries/discovered-code-sprint-day-2/contents.lr

@@ -9,7 +9,7 @@ author: akozak
 ---
 body:
 
-Day 2 of the [DiscoverEd](http://discovered.creativecommons.org/search/) [code sprint](http://wiki.creativecommons.org/DiscoverEd_Sprint_\(June,_2010\)) was largely a continuation of work that started on [Day 1](/archives/old-tech-blog/discovered-code-sprint-day-1/).
+Day 2 of the [DiscoverEd](http://discovered.creativecommons.org/search/) [code sprint](http://wiki.creativecommons.org/DiscoverEd_Sprint_\(June,_2010\)) was largely a continuation of work that started on [Day 1](/archives/old-tech-blog/entries/discovered-code-sprint-day-1/).
 
 The team working on a plugin architecture for DiscoverEd finished their project, which was to build an extension point that enables plugins to pull arbitrary metadata from external sources. At the beginning of the day they had to finish some tests for the new support for arbitrary metadata added in Day 1, but by the end of the day were able to merge their new functionality back into the DiscoverEd repository. They were even able to build a small proof-of-concept plugin that pulled data from the [delicious.com API](http://delicious.com/help/tools) into the Jena store, which later makes its way into the Lucene index. Tomorrow they'll start looking at developing support for custom vocabularies and ontologies (such as [AGROVOC](http://en.wikipedia.org/wiki/AGROVOC)).
 

content/archives/old-tech-blog/entries/discovered-code-sprint-day-3/contents.lr

@@ -9,7 +9,7 @@ author: akozak
 ---
 body:
 
-[Day 1](/archives/old-tech-blog/discovered-code-sprint-day-1/) and [Day 2](/archives/old-tech-blog/discovered-code-sprint-day-2/) of the [DiscoverEd code sprint](http://wiki.creativecommons.org/DiscoverEd_Sprint_\(June,_2010\)) turned out to be very productive, and the third and final day didn't disappoint either. All teams were able to complete or make significant contributions to useful new features.
+[Day 1](/archives/old-tech-blog/entries/discovered-code-sprint-day-1/) and [Day 2](/archives/old-tech-blog/entries/discovered-code-sprint-day-2/) of the [DiscoverEd code sprint](http://wiki.creativecommons.org/DiscoverEd_Sprint_\(June,_2010\)) turned out to be very productive, and the third and final day didn't disappoint either. All teams were able to complete or make significant contributions to useful new features.
 
 Our team that originally developed support for arbitrary metadata and a [plugin architecture](http://wiki.creativecommons.org/Metadata_Retriever_Plugins) to pull in external data in Day 1 and 2 switched to working on integrating branches with the main DiscoverEd source tree. They spent some time fixing bugs in new code that connects the RDFa parser with the Jena store, so that it could be merged with other branches in the code repository, including their work on the metadata plugins, the master branch, and the provenance work previously begun by Creative Commons. After merging those branches, they also took some time to update their work from Day 1 and Day 2 to store the provenance of the metadata. Towards the end of the day they began working on support for running all the DiscoverEd tests with a script. After today they plan on doing some housekeeping work, namely creating documentation about new plugin support in the CC wiki.