Kort introduktion

Under förra året genomfördes RAE2012 där Reseach Office (RO) samlade in c:a 1100 forskar-CVs som kommer ligga som grund för den kommande CV-tjänsten. De tre huvudsyftena är:

1. Stärka synligheten av KTHs forskare.
2. Förenkla CV- och ansökningshanteringen för KTHs forskare.
3. Utgöra en resurs för uppföljning av frågor som rör forskning på KTH.

Viktiga aspekter

En av de viktigaste aspekterna att ta hänsyn till i detta projekt är att göra gränssnittet för inmatning intuitivt. D.v.s. att det är lätt att förstå vad som ska matas in samt hur/var det jag som forskare matar in kommer att presenteras i slutändan.

En annan aspekt är att det ska vara snabbjobbat och att man inte ska behöva mata in information som redan finns i något annat källdatasystem.

Integrationer och importer

För att göra det så enkelt som möjligt för forskarna kommer integrationer mot ett flertal interna och externa källdatasystem implementeras. Dessa kommer populera fält för att underlätta forskarens arbete med att upprätta och underhålla sitt CV.

Några av systemen är:

• HR+ – propagering av persondata från KTHs personalsystem.
• DiVA (Digitala Vetenskapliga Arkivet) – import av publikationer.
• RAE2012 - import av c:a 1000 forskar-CVs.
• KTHs profiler - en naturlig kontext för personrelaterad information.
• KTHs webbpubliceringssystem - möjlighet att enkelt att visa upp forskare på KTH
• Sökmotorer inkl. KTHs interna söktjänst - göra forskare och deras CVn sökbara och enkla att hitta
• LinkedIn – Här ges möjligheten att hämta sina tidigare anställningar och utbildningar.

Fler integreringar till andra system kan tillkomma senare men detta är den initiala planeringen.

Exporter
För att göra KTH-CVn kompatibla med andra CV-tjänster och relaterade system kommer KTHs CV-tjänst att stödja CERIF, Common European Research Information Format, en etablerad standard för att hantera forskningsdata.

Upplägg av utvecklingsprojektet

Innan utvecklingen började gjordes en förstudie där behoven och en projektplan lades fram. Till detta kommer det under utvecklingsprojektet finnas en referensgrupp med representanter från fakulteten och förvaltningen samt en testgrupp med forskare för att mer i detalj ta fram det som efterfrågas.

Grovt kommer utvecklingsetapperna se ut på följande sätt men releaser kommer kontinuerligt gå till referens- och produktionsmiljön när ”nytta” finns på plats.

Lite teknik och deployförfarande – Git, Play Framwork och PostgreSQL

Som plattform har valet hamnat på Play Framework 2.1 med PostgreSQL som databas. Ebean-strukturen i Play passar bra för en CRUD-applikation som denna. Vi använder Git (med Git Flow) och har ett deployförfarande som vid en release pushar in till Git-repot, där vår Jenkins (CI) snappar upp och automatiskt deployar ut den nya releasen till valda miljöer.

För integration med KTHs HR-system (eller mer specifikt UG för de som vet vad det är) används en sk. propagator som propagerar ändringar från personalsystemet. Detta gör att vi får tillgång till vilka som är forskare och därmed vilka som ska kunna logga in, samt deras persondata som t.ex. namn, e-post och skola.

RAE-datat kommer importeras med hjälp av ett importskript (engångsimport) via en fil där detta data finns lagrat idag.

DiVA-integrationen kommer ske via deras api som bygger på MODS (Metadata Object Description Schema), vilket är en XML-baserad standard för bibliometriska set av data.

Följ gärna det vidare arbetet här på bloggen eller via vår Socialgrupp: CV-tjänst för forskare på KTH

Har du jobbat med att lägga ut webb i molnet eller bara är intresserad, lämna en kommentar!

Vi som bygger tekniken bakom KTH.se är väldigt stolta över vad vi gjort och har delat med oss av vår implementation till andra myndigheter, och pratat om vår lösning på olika konferenser, men vi har aldrig skrivit om hur det fungera här på bloggen, och eftersom vi nu äntligen tar steget in i en webb anpassad för mobiltelefoner är det kanske dags att berätta lite om hur vi hanterar utseendet på sajten.

Tänk före

När man normalt bygger webbplatser så lägger vi stor vikt vid att tänka igenom hur vi bygger, strukturerar och upprätthåller strukturen för kodhanteringen i utvecklingsprojektet. Men det som nästan alltid händer är att när vi kommer till utsidan så skriver vi vår css-kod på ett hafsigt sätt, vilket ofta leder till en css-fil som ganska snabbt börjar lukta illa, vi har alla varit där. För små projekt funkar det kanske, men inte för vår komplexa och dynamiska webbplats.

På kth.se började vi redan för flera år sedan ett jobb med att strukturerar upp vår css, så att vi enkelt skulle kunna veta var en css-regel är definierad, ett jobb som vi verkligen sparat in mycket tid och tagit bort många buggar.

Men innan jag börjar beskriva det behöver du få en grundläggande förståelse för hur vi jobbar med innehållet på sajten.

Vi har egentligen tre typer av delkomponenter på sidan, avdelningar, artiklar och innehållsblock. Avdelningar har två jobb, dels att vara egna sidor, så som KTH:s startsida, eller att vara hållare för en artikel. Du kan jämföra med den här bloggens startsida (avdelning), och ett inlägg (avdelning med artikel i sig). Det som gör vår implementation lite speciell är att vi även har något som vi kallar block. Ett block är t ex en bild, länk, puff eller film, eller sammansättningar av anda block. De funkar lite som widgets i WordPress med med den skillanden att de kan ligga var som helst, i en artikel, eller som del på t ex en startsida. Gemensamt för block är att de är innehållselement som man vill kunna återpublicera på olika ställen på webben. En puff som används på startsidan för att informera om en konferens, kanske man vill ska visas i samband med kalendern också.

Speciellt för oss är att till skillnad från vanliga sajter som har en enkelt upplägg där man skriver  en text och den har ett visst syfte, har vi ett mycket mer dynamiskt upplägg. Vi vet egentligen inte vad något på sidan är och vad det ligger i. En bild kan ligga i en puff som ligger i en lista som ligger i en artikel, samtidigt som samma bildobjekt ligger i ett bildspel på startsidan. Den friheten för våra redaktörer gör också att vi inte kan skriva css lite hur som, då har vi plötsligt en djungel av css, och det vill vi inte ha så klart. Vi måste ha en tanke. Varje objekt måste kunna visas snyggt oberoende av var det presenteras.

Vår implementation

Det viktigaste i vår arkitektur är att varje element inte känner till sin egen context och inte påverkar ytor utanför sig själva. Med det menar jag att om en puff ligger på vår startsida är det inte puffen som bestämmer hur mycket marginal det ska vara till nästa puff utan det som puffen ligger i. Varje element bestämmer inom sig själv hur element inom elementet ska hanteras men inte åt andra håller. För att tala css menar jag att alla element som redaktören kan hantera har padding: 0px, margin: 0px; Det normala är också att element så som block alltid spänner över 100% bredd. Återigen eftersom det inte är blocket som bestämmer hur context ser ut. Det gör det blocket ligger i.

Block
Den minsta delen av en webbsida som vi hanterar så som puffar, bilder, länkar. Block har ingen padding och ingen marginal. Ett block vet inget om sin context där där är publicerad, blocket måste därför kunna rita ut sig själv oberoende av utrymme eller plats på webbsidan.

Slot
Delar av sidor så som sidhuvud, artikelytan eller kommentarsdel. Slot:ar hanterar oftas block inom sig och bestämmer då hur mycket marginal det ska vara mellan olika block inom slot:en.

Page
Grundläggade css som rör hela sidor, främst avdelningar. Bestämmer hur mycket marginal det ska vara mellan olika slot:ar

Site
Den högsta nivån i arkitekturen, om det inte är en vanligt KTH-sida, med KTH:s normala design. På site nivå sätter vi då en css-klass på body-taggen, se t ex vår personaltidning Campi. En sajt har oftast sin egen .css-fil. Dock har alla css-filer för respektive sajt samma grundläggande css som kommer från samma 120 page, slot och blocks-filer.

Less ger oss mycket mer

En av de viktigaste verktygen för oss är pre-kompilatorn Less som gör css mer lättanvänt. Less ger möjligheter som likar de man har vid programmering. Du får variabler och funktioner, väldigt begränsat men ändå. Vi har för tillfället ca 120 st less-filer. Förutom att ha filer för variabler (färger, text-storlekar, radavstånd …) och funktioner. Har varje element sin egen less fil, och det är viktigt för då vet vi att reglerna för elementet puff ligger i puff.less – ingen annans stans. Jag vet också att även om min kollega jobbar med startsidan kommer han inte att ändra hur puffar ser ut där. Behöver jag specialbehandla utseendet för ett element, så som puff på startsidan gör vi det också i puff.less, lika så ligger specialregler för responsive design i samma fil.

Här har ni ett exempel på hur less-filen för ett block ser ut, men strukturen ser lika ut för page, slot och site.

// default style for element
.block.teaser {
  .noSpacing;
  .teaserText {
    color: @blue;
  }
}

// overrides for specific context
.startDepartment {
  .block.teaser {
    .teaserText {
      color: @red;
    }
  }
}

// responsive design 
@media only screen and (max-width: @iPadLandscape) {
  .block.teaser {
    .fontSize(15);
  }
}

Så du har tagit dig hela vägen hit, bra jobbat! Har du frågor svara vi gärna på dom!

Det handlar primärt om webb av olika slag men området är brett och jag skulle nog beskriva det som en ganska utmanande kombination av cutting-edge teknik och traditioner som på sitt sätt nog kräver kreativitet utöver det vanliga.

Läs hela annonsen här: 
KTH söker en användbarhetsdesigner

Välkommen till vårt team!

Those of us who aren’t quite fortunate enough to be able to hide everything behind firewalls need to resort to other measures to secure our environments. For us that particularly applies to development and testing environments.

Couchbase provides a nice administration interface on localhost, port 8091 by default, which in development I needed to be able to access remotely over the Internet. Turns out that it works just fine proxied, as long at is proxied into a root context.

Not going into details about how to set up certificates, here is the Apache httpd conf file I use on my Fedora 18 workstation to serve the admin interface over https on port 8443. It assumes that mod_ssl and mod_proxy are installed and enabled. It should work in most standard Linux boxes, at least RedHat derivatives where you can just drop it in as /etc/httpd/conf.d/couchbase.conf, and should be possible to adapt to other environments that can run Apache httpd. Obviously, you additionally need to open up the port you select in any firewall.

#
# Couchbase proxy configuration to encrypt admin interface.
#
# Assumes mod_ssl is installed and configured (generally
# /etc/httpd/conf.d/ssl.conf). These are just amendments
# for the Couchbase interface.
#
Listen 8443 https

<VirtualHost _default_:8443>
 LogLevel warn
 SSLEngine on
 SSLProtocol all -SSLv2
 SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
 SSLCertificateFile /etc/pki/tls/certs/localhost.crt
 SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
 ProxyPass / http://localhost:8091/
 ProxyPassReverse / http://localhost:8091/
</VirtualHost>

I have to say I’m impressed that the feature rich Couchbase interface is robust enough to handle this and hope their developers keep it that way.

Cheers.

About Apache JMeter

JMeter is a free, open-source tool to automate functional behavior and measure performance, and it can be used to automate scenarios such as a user logging in, causing a couple of service authentications and logging out again. It has a reasonable user interface and can also be used without the user interface for automatic batch tests. If you use Jenkins, you can combine JMeter with the Performance Plugin for continuous performance monitoring of your  builds.

It can be somewhat tricky to set up the test scenarios, but the documentation, especially the Component reference which details the behavior of the different controllers, samplers, assertions etc. you can use is quite good.

Setup

For our CAS verification, we have a reference environment with an authentication backend (an Active Directory as it happens) with known users and passwords. The JMeter setup consist of a JMX-file with the scenario, a file with username and password combinations separated by tabs and a file with properties containing configuration parameters for the JMX-file, including the name of file containing the users. A complete set of example files, GenericCasPerfTest.jmx, users.csv and localhost.properties are available in this GitHub repository and they are reasonably self explanatory.

JMeter is then launched with:

jmeter -p localhost.properties -t GenericCasPerfTest.jmx

The example files should work for a regular CAS server though I haven’t verified this, since our setup is slightly different. E.g., our server does not respond with the same username the user logins with but a site-wide internal identifier, which means that the test scenario I use is slightly modified to handle this.

Running

Our test setup generates on average not quite two authentication transactions per second, which about the same, or slightly less than, the load our moderate size production site typically peaks at. JMeter provides counters and graphs during the test, in particular the Aggregate Report is useful, and the new statistics view in CAS provides nice graphs of how the system is performing, as well as counters from the ticket registry (provided your backend supports it) to monitor it’s behavior.

Our new Couchbase backend discussed previously also provides an interface with extensive counters for its performance.

Together these reports gives me a rough verification that it will handle the actual load in production.

You can always improve

Still, the setup I use could do with improvements. E.g., to better simulate actual behavior, I would need many more but much less active sessions. It is perfectly possible to tweak the provided setup this way, but this is left as an exercise for the reader.

More on Jasig CAS Wiki

Just as I wrote this I realize that there is a page with more test cases on the CAS Wiki, https://wiki.jasig.org/display/CASUM/Apache+JMeter

photo credit: casey.marshall via photopin cc

Jasig CAS

Jasig CAS (www.jasig.org/cas), Central Authentication Service, is the wide-spread enterprise single-sign-on service we use at KTH. It is the service known as login.kth.se to students and staff since many years.

Couchbase

Couchbase (www.couchbase.com), is an open-source, high-availability NoSQL database based on Erlang/OTP and its included mnesia database. Couchbase provides a memcache protocol interface and can be used as a memcached replacement. Using an amended, couchbase cluster aware, client, you can get the full benefits of the couchbase cluster redundancy, as well as indexing etc not available with pure memcache.

Due to my previous experience with Erlang/OTP to provide high-availability in large scale systems, I was fairly confident that a redundancy solution based on Couchbase would actually work in real life, so a solution for our authorization server using this technology seemed agreeable to me.

Couchbase module for CAS

In order to use the cluster functionality of Couchbase, we have to create our own, Couchbase-aware, ticket registry. While we are at it, we also have created a service registry storage backend for service verification in CAS. It is released as separate module which can be deployed with CAS using the recommended maven-overlay method of CAS customization and available at GitHub.

github.com/KTHse/cas-server-integration-couchbase

Intended architecture

There are essentially two ways to use replication in Couchbase, either replicated vBuckets or Cross Datacenter Replication (XCDR). They can loosely be considered comparable to raid5 vs raid1 in a storage sence. Which to choose is not clear at this moment and we need to test this further.

Using XCDR seems clean from an architectural point of view, but it introduces the possibility of issues with the replicates not being in sync and session ticket validation from web applications failing since a web application may use a different server than the user browser is directed to. One way of solving this would be to use a hot-standby configuration so that only one server is active and in use at a time, and only redirecting to the standby server if the master fails.

Using vBucket replication would probably be considered to be the ”normal”  way of doing things with Couchbase. It involves the clients knowing more about the cluster and which node is the master of which data through a hashing algorithm which is updated if some server node fails. This is handled transparently by the Couchbase client and means that all clients would have a consistent view of the data. In this case, the Couchbase cluster should be seen as separate cluster from the CAS server. This is most likely the configuration we will look at primarily.

Security considerations

It is important to note that Couchbase replication traffic is not encrypted in Couchbase 2.0. The traffic between the nodes must be secured in some other manner, using IPSec or some other tunneling mechanism.

Project status

The project is still in development but the functionality is pretty much all there. We are currently in development testing and will soon start integration testing in our reference environment, looking at a deployment to our production environment sometime this spring. This deployment will however not include clustering.

Later this spring we will start playing with creation of a redundant login cluster in the reference environment for future deployment to production.

När man arbetar med Maven vill man publicera artefakter till något repository. För hela upplevelsen där vem som helst enkelt kan komma åt allt på ett enkelt sätt via sina verktyg ska man förstås publicera i det centrala repositoryt, t.ex via http://www.sonatype.org/central.

Men det går att relativt enkelt hosta ett repo på t.ex GitHub för att göra det möjligt för andra att använda maven för att komma åt dina artefakter, om än med lite mer konfiguration, när man inte vill köra hela release-processen till central. Jag kommer inte att gå in i detalj här, utan hänvisar till denna blog, http://cemerick.com/2010/08/24/hosting-maven-repos-on-github/ och anvisningarna i det repo som jag har skapat, https://github.com/KTHse/mvn-repo, men i princip går det ut på att man använder GitHub som en webbserver för att sprida sina artefakter.

Det fungerar ganska rättframt med det extra tillägget att man måste deploya artefakterna via den lokala klonen av mvn-repot och pusha vilket blir ett extra steg.

Det blåser nya vindar i världen. Transparens och öppen data är det nya ledordet. Fler och fler länder tar fram direktiv för hur myndigheter ska bli mer öppna och transparenta, och i Sverige vill vi inte vara sämre och följer efter. Vi bygger öppna api:er, myndigheter bloggar och ger oss nya insikter direkt från ansvariga. Allt detta tar oss närmare det vi vill ha; mer transparens och öppenhet.

Men vänta! Öppenhet och transparens – det låter bekant?

Stora delar av internetvärlden jobbar hårt för att få en bråkdel av det vi redan har: offentlighetsprincipen.

Vi kan dagligen läsa internationella bloggposter som hyllar andra länders myndigheter första steg mot öppnhet. Få av dessa internationella debattörer kan nog tänka sig möjligheten att begära ut sin statsministers e-post. I deras värld är det stort när delar av informationen blir offentlig, ”öppen” data. Hos oss är det initialt inte lika viktigt att jobba att göra datat öppet. Vi startar i en position där vi redan har rättigheten att ta del av informationen. Vi behöver det vill säga inte få hela myndighetsbyråkratin att ändra på sig.

Nästan allt är öppet, men vad är hemligt?

Jag tror vi borde tänka om när det gäller öppenheten på internet för myndigheter i Sverige. Det viktigaste borde inte vara att lista våra öppna data, utan tvärt om. Vi borde ha öppna register som tydligt säger vilken data du inte får ut från myndigheten, den data som mydigheten inte tycker ska vara transparant. Det behöver inte vara data heller för den delen. Lika viktigt tror jag det är att belysa varför man inte får se innehållet på ett intranät. I dag slår vi oss för bröstet när vi släpper ett nytt öppet data-api, men det är ju egentligen bara att ge medborgarna tillgång till det som de redan har tillgång till. Missförstå mig inte, vi behöver api:er, bloggar och allt det där också, men demokratin behöver snarare veta vad som inte är offentligt. Att medborgarna får ta del av det som myndigheten inte vill att de ska se, då har vi transparens.

Vårt data är redan öppet, men inte tillgängligt

Dagens diskussioner kring öppna api:er påminer om gamla myndighetswebbplatser. ”Den här datan vill vi publicera”, ett inifrån och ut perspektiv. Om vi vänder på upplägget och visar att den största delen av vårt data är öppet för folk att använda, men inte tillgängligt, kommer vi snabbare att driva på utvecklingen av datakällor för samhället att använda. Användarna som vill nyttja all vår data ska tydligt få veta vad de kan kräva av oss, och inte som i dag, vara glada när vi publicerar det som är enklast att lösa internt på myndigheten.

Därför tror jag att vi ska börjar uppge vad som är hemligt, dels för att få bättre transparens, och dels för att jag tror det möjliggör en snabbare tillväxttakt av publika api:er.

Vad tror ni, skulle det hjälpa oss framåt ytterligare något steg?

——–

Jag vill bara påpeka att detta är mina egna tankar och inte KTH:s offentliga.

——–

Tillägg 27 januari 2012
Efter en diskussion i gruppen Opengov – öppen offentlig förvaltning inser jag nu att jag är för slapp när jag säger ”data” eftersom jag inte enbart syftar på strukturerad data. Jag menar information mer generell, vare sig det är webbsidor, RDF, eller API:er.

Men i dag satt jag och kollade igenom lite olika videos från en konferens i Seattle, USA och tänkte att det är ju verkligen mycket mer intressant att kolla på en 30 minuters video om något up ‘n’ coming, än att läsa en bok. Dessutom har man alltid sin mobil med sig och därmed lättare att hitta dom där extra 30 min.

Jag föreslår att en person får välja video vi alla ska kolla på och sedan diskuterar vi en halvtimme över en kaffe, alternativt att vi kollar på videon tillsammans. Jag tror det är bra om vi bara tar anställda-listan rakt upp och ner och rullar ansvarig utifrån den. På så vis  får vi med alla synvinklar, allt från front-end till organisationsteori.

Vad tror ni Infosys, är det något att ha?

Jag avslutar denna bloggpost med den första videon jag tittade på i dag. Den handlar om Meteor, och är definitivt värd 30 min