streda 7. októbra 2009

PowerShell and SharePoint API

PowerShell and SharePoint API is really powerfull combination which can help us to automatize administration and development tasks. SharePoint exposes .NET API which can be typically called from some .NET programming language such as C#. Using this approach we have to write code, compile it and than run. SharePoint API can be also used from PowerShell, this approach removes the step of compilation. Only write a script and run it.

Following PowerShell script demonstrates using of SharePoint API from PowerShell. Script is intended to collectively set the force checkout property of document libraries (Shared Documents) in all webs of the site collection on true.


   1:  #################################################################################

   2:  #

   3:  #  Set-RequireCheckOut

   4:  #  Sets ForceCheckout on document libraries Shared Documents on site collection

   5:  #

   6:  #################################################################################

   7:   

   8:  param

   9:  (

  10:      [string] $siteUrl

  11:  )

  12:   

  13:  [void][Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

  14:   

  15:  $site = New-Object Microsoft.SharePoint.SPSite $siteUrl

  16:   

  17:  foreach ($web in $site.AllWebs)

  18:  {

  19:      foreach ($list in $web.Lists)

  20:      {

  21:          if ($list.Title -eq "Shared Documents")

  22:          {

  23:              $list.ForceCheckout = $True

  24:              $list.Update()

  25:          } 

  26:      }

  27:  }

Manning - Windows PowerShell In ActionMS Press - Inside Microsoft Windows SharePoint Services Version 3

pondelok 21. septembra 2009

Visual Studio Macros

I think Visual Studio macros is interesting feature which is not often used. Using macros you can automate repetitive tasks and increase your development productivity. You can create your own macros using Macro Exlorer (View - Other Windows - Macro Explorer).

My sample shows macro for generating new GUID in {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} format, which is common task at SharePoint development when writing some stuff in CAML:


   1:  Imports System

   2:  Imports EnvDTE

   3:  Imports EnvDTE80

   4:  Imports EnvDTE90

   5:   

   6:  Public Module SharePointMacros

   7:      Sub CreateNewGuid()

   8:          Dim doc As Document = DTE.ActiveDocument

   9:          Dim textDoc As TextDocument = CType(doc.Object("TextDocument"), TextDocument)

  10:   

  11:          textDoc.StartPoint.CreateEditPoint()

  12:          textDoc.Selection.Insert("{" + Guid.NewGuid.ToString() + "}")

  13:      End Sub

  14:  End Module


To associate your macro with keyboard shortcut go to Tools - Options - Environment - Keyboard, find macro in command list, press shortcut (CTRL+N, CTRL+G) and assign it.


Setting VS keyboard shortcut

When you press the shortcut in code editor, macro will be run and new GUID will be inserted on the cursor position.


APress - Writting Add-Ins for Visual Stutio .NETWiley - Developing Visual Studio .NET Macros and Add-Ins

nedeľa 18. januára 2009

Porovnanie ASP.NET WebForms a ASP.NET MVC

Už dlhšie ako rok je v ASP.NET komunite témou číslo jedna pripravovaný framework ASP.NET MVC.
Moje porovnanie nepopisuje rozdiely na implementačnej ale na vyššej úrovni, na úrovni architektúry. Vzor Model View Controller (MVC) nie je v skutočnosti ničím novým. Prvý krát bol popísaný v roku 1979 a v Java komunite je velmi populárny už mnoho rokov. Len pre zaujímavosť, Microsoft v roku 2003 vnímal vzor MVC trochu inak a jeho implementáciu v ASP.NET si predstavoval takto.

Pre komplexné pochopenie rozdielov medzi ASP.NET WebForms a ASP.NET MVC je podľa môjho názoru potrebné pozrieť sa na vec z rôznych pohľadov:

Typ architektúry

  • pull-based architecture (ASP.NET WebForms) - požiadavka prichádza na view, ten inicializuje natiahnutie (pull) dát

  • push-based architecture (ASP.NET MVC) - požiadavka príde na controller, ten inicializuje natiahnutie dát, vyberie view a dáta "natlačí" (push) do view


Typ webového frameworku

  • komponentové frameworky (ASP.NET WebForms, JSF) - treba v nich riešiť 2 problémy:
    - kam serializovať viewstate
    - výpočtová náročnosť vytvorenia komponentového stromu
    Komponentové frameworky sú vhodnejšie pre intranetové aplikácie využívajúce databázu, pretože poskytujú vyššiu úroveň abstrakcie nad protokolom HTTP.
  • požiadavkami riadené frameworky (ASP.NET MVC, Struts, Spring MVC) - sú vhodnejšie tam, kde je potrebné mať úplnu kontrolu nad výstupom


Komponentové frameworky sú o poschodie vyššie ako požiadavkami riadené z pohľadu abstrakcie ktorú ponúkaju, samozrejme niečo to stojí. V extrémnom prípade sa pri použití komponentového frameworku nemusíme starať o to, že existuje nejaký protokol HTTP alebo jazyk HTML. Dobrá úvaha o webových frameworkoch je tu.

O ASP.NET MVC si treba uvedomiť:

  • je to alternatíva a nie náhrada za WebForms

  • poskytuje viac kontroly nad <html/>

  • je to jednoducho testovateľný framework (testovanie WebForms bolo veľmi komplikované – HttpContext mocking)

  • je jednoducho rozšíteľný framework

  • nie je pre každného (WebForm-oriented mindset is unuseable)


Čo sa zmenilo v porovnaní s ASP.NET WebForms:

  • žiaden ViewState

  • žiaden Postback

  • nevyužívame page lifecycle

  • nevyužívame Controls (veci odvodené od System.Web.UI.Control až na zopár výnimiek)

  • SEO friendly URL

  • <form runat="server"> ... </form> nie je nutný atribút runat


Na záver otázka: Kam zaradiť ASP.NET MVC vzhľadom na úroveň abstrakcie nad protokolom HTTP a jazykom HTML?

ASP < ASP.NET MVC < ASP.NET WebForms

utorok 6. januára 2009

Zlo pri vývoji softvéru

Pred niekoľkými rokmi som definoval základné chyby, ktoré sa neustále opakujú pri vývoji softvéru. Tieto chyby sú aj pri malých projektoch, ktoré vyvíjajú jednotlivci a takisto sa vyskytujú aj v projektoch pre top klientov, ktoré implementujú vývojarské týmy. Ignorácia týchto nedostatkov má za následok, že vyvíjaný systém sa časom stáva neudržiavateľným, resp. jeho údržba a rozširovanie je veľmi časovo a teda aj finančne náročné. Tak tu sú:


1. duplicity - kód obsahuje tú istú funkčnosť naprogramovanú na viacerých miestach. Často to vzniká keď programátori použivajú CTRL+C, CTRL+V. Proti duplicitám sa dá efektívne bojovať priebežným refaktorovaním a využívaním návrhových vzorov. Žial moje skúsenosti sú také, že iba málo programátorov vie efektívne využívať refaktorovacie techniky. Obhájenie refaktorovania pred projektovými manažmentom je však náročné, pretože refaktorovaním sa do systému žiadna funkcionalita nepridáva.


2. mixovanie vrstiev - systém nie je rozčlenený do logických vrstiev. Niekedy aj zdanlivo je, ale pri pohľade na implementáciu teda kód som videl niečo ako pridávanie HTML značiek <b> .... </b> k dátam načítavaným z databázy, resp. SQL prikázy vo webových skriptoch (.aspx, .jsp). Jednoducho ľudia si neuvedomujú čo kam patrí.


3. nesprávne závislosti medzi komponentami - nie je venovaná dostatočná pozornosť manažmentu závislostí medzi komponentami. K takému stavu sa dostaneme lahko ak nemáme jasne definované zodpovednosti každej komponenty.