Peter Birkholm-Buch

Freelance Cloud Architect

Måned: august 2011

Socialt valgeksperiment

Så er der folketingsvalg 2011 og de sociale medier er allerede ved at flyde over med kommentarer af mere eller mindre lødig karakter.

For at gøre det nemmere at kende forskel på farven af tweets, indlæg og andre opkast vil jeg foreslå at alle skifter deres billede ud med et ikon der angiver det parti de vil stemme på.

Jeg har til formålet sakset lidt i DR’s hjemmeside og lavet nedenstående ikoner (i alfabetisk rækkefølge):

ABCFIKOVØ

Alternativt kan man hente fra Skydrive: https://skydrive.live.com/#!/?cid=6af4c8ec7575374c&sc=documents&uc=9&id=6AF4C8EC7575374C%21846

Jeg har skiftet til (ugens) parti på twitter, facebook og G+.

God fornøjelse og godt valg.

SharePoint 2007 Content Query Web Part Resources

Basic Usage

Styling

Custom Queries

Programmatic

Cool Examples That Tie It All Together

Enhanced CQWP’s

When to use a Database, Sharepoint, or Wiki

Notice: I wrote this when I was still working for NNIT, but the principles still apply.

Eli Robillard wrote a post on “When to use a database, SharePoint, or wiki” with the following highlights:

A database stores structured data. The structure is typically designed and owned by an individual. Politically, it’s a dictatorship. Line-of-business applications which gather and distribute raw data are typically associated with databases.

Sharepoint provides webs to store lists and documents. Think of this as loosely-structured data. Sharepoint lets you control this data with versioning, backup and recovery, workflow, security, policies and auditing. The structure might be seeded by an individual, but ownership is distributed. Sharepoint should be designed to unfold according to to will of the distributed owners. Politically, Sharepoint provides representative leadership like a parliamentary system though the leaders are typically appointed rather than elected. Sharepoint is used by “information workers” to create, manage, and publish information typically stored in lists and documents. Sharepoint is used as an interface to databases. Sharepoint is a social tool used to recognize and reinforce relationships among people. Through either Sharepoint’s business intelligence capabilities or its integration with Reporting Services, Sharepoint can report on data from structured and loosely structured data stores. Sharepoint can index and provide search for structures, loosely structured, and unstructured data stores.

A Wiki provides webs to store text with embedded references to media. This is unstructured data. Wiki content can be seeded with the intention to unfold according to some master design, but politically, it’s anarchy. A Wiki allow control through versioning and moderation. A Wiki is well-suited for collaborative documentation.

I the years to come eS will hopefully get the chance to convert a lot of Lotus Notes databases to Sharepoint. Each time you have to stop and figure out which one or all of the above mentioned data storage mechanisms you have to use in order to convert the functionality of the Lotus Notes database to Sharepoint.

Lotus Notes databases basically comes in two flavors:

  1. Plain data (one or more tables) with views and no LotusScript code – basically it’s a spreadsheet with alphanumerical data
  2. Data with views, references and business logic in LotusScript code – basically it’s an application

In the first case it’s a no brainer to just convert the database into a WSS site with the data in custom lists combined with custom views and perhaps a few Web Part Pages thrown in with connected Web Parts that displays data. This is exactly what JPTL is doing right now with a Lotus Notes database from Novo Nordisk Stakeholder Relations.

In the second case it’s much more difficult and each Lotus Notes database or more appropriately Lotus Notes Application has to be thoroughly analyzed. Once you have a good understanding of the business requirements and these was implemented in the Lotus Notes Application – stop and take a look at the slide below.

Your job now is to transform the business requirements from the square Lotus Notes approach to the round Sharepoint approach.

Can you fulfill the same surface area of business requirements with standard Sharepoint functionality? This is where creative use of lists (custom, tasks, wikis and so on), document libraries, views, Web Parts, workflows and Web Part Pages comes in.

Obviously there will be cases where it’s just not possible to get the job done and you’ll have to revert to a normal application design with ASP.NET (remember that Web Parts in WSS3.0 is a ASP.NET2.0 Web Part) and a backend database – but hopefully it will won’t be very often. You could take the middle road and use a list for storage and you could even use SilverLight for the UX instead of ASP.NET.

Simplicity

Hvad laver en CTO?

Er jeg blevet interviewet af Daniel Frost fra Microsoft om:

http://danielfrost.dk/post/Froste28099s-podcast-Episode-1-e28093-Hvad-laver-en-CTO-.aspx

Calculated Time Left columns in SharePoint with jQuery

Transformation af forretningskrav med fast overfladeareal

Jeg har gennem tiden skrevet et utal af tilbud baseret på udbudsmateriale, der var mere eller mindre gennemarbejdet.

Desværre har de fleste kravspecifikationer en stor fejl:

  1. De funktionelle krav har været skrevet i hvordan-form i stedet for hvad-form

Når man skriver kravspecifikation for funktionelle krav, er det en kunstform kun at beskrive det som systemet skal kunne (altså selve forretningskravene) og ikke hvordan systemet forventes at løse disse krav.

Når funktionelle kravspecifikationer er skrevet i hvordan-form giver det store vanskeligheder at udnytte standardsystemer til at løfte krav der dybest set kan håndteres af standardfunktionalitet, fordi der i kravene er indlagt krav til proces og præsentation.

Capture

Det bedste i sådan en stituation er at indgå i tæt dialog med kunden og gennem workshops søge at forstå selve hvad-essencen i kravene. Herefter er det så muligt via prototyping at vise hvordan krav kan løftes f.eks. via standardfunktionalitet.

Jeg kalder processen for “Transformation af forretningskrav med fast overfladeareal”. Det handler i virkeligheden bare om at forstå de basale forretningskrav og vise hvordan de kan løftes nemmest via standardfunktionalitet. Jeg har gennemført workshops med dette formål med masser af kunder. Senest med Københavns Universitet, hvor vi fik reduceret omkostningerne til projektet med næsten 25% ved, at løse krav med standardfunktionalitet, i stedet for at kode en løsning der opfyldte de oprindelige krav 100% uden brug af standardfunktionalitet.

Processen kan bruges i alle situationer, hvor der er tale om en løsning, hvor det er muligt at bruge et standardsystem til at løse store dele af forretningskravene.

How to navigate an OData compliant service

The Service:

It all starts with a Data Service hosted somewhere:

http://server/service.svc

Basic queries:

You access the Data Service entities through resource sets, like this:

http://server/service.svc/People

You request a specific entity using its key like this:

http://server/service.svc/People(16)

Or by using a reference relationship to something else you know:

http://server/service.svc/People(16)/Mother

This asks for person 16’s mother.

Once you have identified an entity you can refer to it’s properties directly:

http://server/service.svc/People(16)/Mother/Firstname

$value:

But the last query wraps the property value in XML, if you want just the raw property value you append $value to the url like this:

http://server/service.svc/People(16)/Mother/Firstname/$value

$filter:

You can filter resource sets using $filter:

http://server/service.svc/People?$filter=Firstname  eq ‘Fred’

Notice that strings in the filter are single quoted.

Numbers need no quotes though:

http://server/service.svc/Posts?$filter=AuthorId eq 1

To filter by date you have identity the date in the filter, like this:

http://server/service.svc/Posts?$filter=CreatedDate eq DateTime’2009-10-31′

You can filter via reference relationships:

http://server/service.svc/People?$filter=Mother/Firstname eq ‘Wendy’

The basic operators you can use in a filter are:

Operator Description C# equivalent

eq

equals

==

ne

not equal

!=

gt

greater than

>

ge

greater than or equal

>=

lt

less than

<

le

less than or equal

<=

and

and

&&

or

or

||

()

grouping

()

There are also a series of functions that you can use in your filters if needed.

$expand:

If you want to include related items in the results you use $expand like this:

http://server/service.svc/Blogs?$expand=Posts

This returns the matching Blogs and each Blog’s posts.

$select:

Some Data Services allow you to limit the results to just the properties you require – aka projection – for example if you just want the Id and Title of matching Posts you would need something like this:

http://server/service.svc/Posts?$select=Id,Title

You can even project properties of related objects too, like this:

http://server/service.svc/Posts?$expand=Blog&$select=Id,Title,Blog/Name

This projects just the Id, Title and the Name of the Blog for each Post.

$count:

If you just want to know how many records would be returned, without retrieving them you need $count:

http://server/service.svc/Blogs/$count

Notice that $count becomes one of the segments of the URL – it is not part of the query string – so if you want to combine it with another operation like $filter you have to specify $count first, like this:

http://server/service.svc/Posts/$count?$filter=AuthorId eq 6

This query returns the number of posts authored by person 6.

$orderby:

If you need your results ordered you can use $orderby:

http://server/service.svc/Blogs?$orderby=Name

Which returns the results in ascending order, to do descending order you need:

http://server/service.svc/Blogs?$orderby=Name%20desc

To filter by first by one property and then by another you need:

http://server/service.svc/People?$orderby=Surname,Firstname

Which you can combine with desc if necessary.

$top:

If you want just the first 10 items you use $top like this:

http://server/service.svc/People?$top=10

$skip:

If you are only interested in certain page of date, you need $top and $skip together:

http://server/service.svc/People?$top=10&$skip=20

This tells the Data Service to skip the first 20 matches and return the next 10. Useful if you need to display the 3rd page of results when there are 10 items per page.

Note: It is often a good idea to combine $top & $skip with $orderby too, to guarantee the order results are retrieved from the underlying data source is consistent.

$inlinecount & $skiptoken:

Using $top and $skip allows the client to control paging.

But the server also needs a way to control paging – to minimize workload need to service both naive and malicious clients – the OData protocol supports this via Server Driven Paging.

With Server Driven Paging turned on the client might ask for every record, but they will only be given one page of results.

This as you can imagine can make life a little tricky for client application developers.

If the client needs to know how many results there really are, they can append the $inlinecount option to the query, like this:

http://server/service.svc/People?$inlinecount=allpages

The results will include a total count ‘inline’, and a url generated by the server to get the next page of results.
This generated url includes a $skiptoken, that is the equivalent of a cursor or bookmark, that instructs the server where to resume:

http://server/service.svc/People?$skiptoken=4

$links

Sometime you just need to get the urls for entities related to a particular entity, which is where $links comes in:

http://server/service.svc/Blogs(1)/$links/Posts

This tells the Data Service to return links – aka urls – for all the Posts related to Blog 1.

$metadata

If you need to know what model an OData compliant Data Service exposes, you can do this by going to the root of the service and appending $metadata like this:

http://server/service.svc/$metadata

This should return an EDMX file containing the conceptual model (aka EDM) exposed by the Data Service.

Getting started developing for SharePoint 2010

Microsoft har udgivet 10 screencasts der kan bruges som udgangspunkt for at komme i gang med at udvikle løsninger på SharePoint 2010:

  • Module 1: Getting Started: Building Web Parts in SharePoint 2010
  • Module 2: What Developers Need to Know About SharePoint 2010
  • Module 3: Building Blocks for Web Part Development in SharePoint 2010
  • Module 4: Accessing SharePoint 2010 Data and Objects with Server-Side APIs
  • Module 5: Accessing SharePoint 2010 Data and Objects with Client-Side APIs
  • Module 6: Accessing External Data with Business Connectivity Services in SharePoint 2010
  • Module 7: Developing Business Processes with SharePoint 2010 Workflows
  • Module 8: Creating Silverlight User Interfaces for SharePoint 2010 Solutions
  • Module 9: Sandboxed Solutions for Web Parts in SharePoint 2010
  • Module 10: Creating Dialog Boxes and Ribbon Controls for SharePoint 2010
  • Intranet vs. Internet

    imageVi har lige netop afleveret materiale til prækvalifikation på et kommende udbud om ny hjemmeside. I materialet bedes leverandørerne beskrive referencer på Intranet og Internet.

    På et møde hvor vi kort gik vores referencer igennem var der en person der mente at vi var lidt tynde på referencer på Internet – altså eksterne hjemmesider.

    Så var det jeg anførte at de sidste 3 Intranet vi har leveret langt overgår de foregående 3 Internet i kompleksitet og samtidigt er baseret på samme teknologi.

    Normalt skelner man mellem tre forskellige typer af web-løsninger:

    1. Intranet
    2. Extranet
    3. Internet

    1). Intranet dækker over en løsning der udelukkende kan tilgås af brugere på ”indersiden” af firewallen, dvs. typisk personer der har et ansættelsesforhold til en virksomhed eller organisation.

    2). Extranet dækker over en løsning der både kan tilgås af Intranet-brugere samt brugere der kommer udefra som f.eks. samarbejdspartnere eller kunder. En forudsætning for at tilgå et Extranet er oprettelsen af dedikeret brugerkonti og kodeord.

    3). Internet dækker over en løsning der kan tilgås af alle uanset forholdet til en virksomhed eller organisation. Et typisk eksempel på en Internet løsning er en hjemmeside for en virksomhed som f.eks. www.traen.com eller for en organisation som www.regionsjaelland.dk.

    Traditionelt bruger man mange resourcer på at sikre at grafisk design og layout på en Internet løsning er i overensstemmelse med en virksomheds visuelle identitet. Det er naturligt da hjemmesider for mange virksomheder udgør den primære kommunikationskanal til kunder og brugere. Samtidigt har man traditionelt ikke lagt så meget vægt på grafisk design og layout på Intranet og Extranet løsninger, da det primære fokus var indholdet og funktionaliteten. Indhold skal være målrettet eller personaliseret til den enkelte bruger, så man ikke skal bruge unødig tid på at søge efter indhold.

    Over de sidste par år har vi set en forandring, eller rettere en sammensmeltning, af kravene til Intranet, Extranet og Internet. Hvis en virksomhed har en vis størrelse så er det vigtigt at kunne kommunikere vision, mission osv. til medarbejderne mha. den visuelle identitet. Det kræver at man til Intranet nu også skal have fokus på grafisk design og layout – samtidigt med at indholdet skal være målrettet. For Internet er tendensen at indhold til målrettes til den aktuelle bruger, så brugeren ikke skal spilde tid på at finde indhold.

    Et moderne Intranet, Extranet og/eller Internet skilles stort set kun af om brugerdatabasen indeholder ansatte eller ej.

    Vi har netop leveret et nyt Intranet til et stort universitet i København. Det er en løsning med skarp fokus på visuel identitet og kommunikation (som et Internet), mulighed for adgang for eksterne registrerede brugere (som et ekstranet) samt personaliseret og målrettet indhold til alle baseret på automatiske og personlige indstillinger (som et Intranet).

    Fra min stol er der ikke så stor forskel på Intranet og Internet projekter som der har været.