mercoledì 22 maggio 2013

5.6. Tutorial: Databinding in ASP.NET Using LINQ on Entities


http://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-entity-framework-databinding-linq-entities.html

In this tutorial you create an ASP.NET web page that binds LINQ queries to entities using the Entity Framework mapping.
If you have not already done so, install the World example database prior to attempting this tutorial. See the tutorial Section 5.5, “Tutorial: Using an Entity Framework Entity as a Windows Forms Data Source” for instructions on downloading and installing this database.

lunedì 20 maggio 2013

Is it possible in IIS to set up a site in IIS and only let users of a certain AD Group get access to it?

http://serverfault.com/questions/352647/restrict-access-to-iis-site-to-an-ad-Group
Is it possible in IIS to set up a site in IIS and only let users of a certain AD Group get access to it?

The following should work, depending on your IIS version. You'll need to add a web.config if you don't have one (though you should on IIS7) in the directory root of your site. The below will allow Domain Admins and deny Domain Users (fairly self explanatory). Make sure you line up the config sections if you already have a section, etc.
<configuration>
  <location path="MyPage.aspx/php/html">
      <system.web>
         <authorization>
            <allow users="DOMAIN\Domain Admins"/>
            <deny users="DOMAIN\Domain Users"/>
         </authorization>
      </system.web>
   </location>
</configuration>
You will need Windows Authentication enabled under Authentication in your site preferences for this to work, obviously, but I assume you already have this enabled.
share|improve this answer
Above does not work in IIS7 you need to use the role attribute, also if you want to restrict the whole site you dont need the location element
<authorization>
  <allow roles="DOMAIN\Domain Users"/>
  <deny users="*" />
</authorization>

sabato 18 maggio 2013

What is Jenkins?

https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

What is Jenkins?

Jenkins is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Jenkins focuses on the following two jobs:
  1. Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
  2. Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.

Who is using it?

A lot of companies and organizations. Most instances tend to run inside the firewall, but Google can tell you publicly visible instances. We also have some statistics collected from the anonymous usage survey here

Features

Jenkins offers the following features:
  1. Easy installation: Just java -jar jenkins.war, or deploy it in a servlet container. No additional install, no database.
  2. Easy configuration: Jenkins can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There's no need to tweak XML manually anymore, although if you'd like to do so, you can do that, too.
  3. Change set support: Jenkins can generate a list of changes made into the build from Subversion/CVS. This is also done in a fairly efficient fashion, to reduce the load on the repository.
  4. Permanent links: Jenkins gives you clean readable URLs for most of its pages, including some permalinks like "latest build"/"latest successful build", so that they can be easily linked from elsewhere.
  5. RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
  6. After-the-fact tagging: Builds can be tagged long after builds are completed.
  7. JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.
  8. Distributed builds: Jenkins can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers' desks.
  9. File fingerprinting: Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Jenkins, and is ideal for projects to track dependency.
  10. Plugin Support: Jenkins can be extended via 3rd party plugins. You can write plugins to make Jenkins support tools/processes that your team uses.

Jenkins Best Practices

Continuous Integration with automated test execution has seen broad adoption in recent years. The ideas behind Continuous Integration have changed how companies look at Build Management, Release Management, Deployment Automation, and Test Orchestration. This section provides a set of best practices for Jenkins - A Continuous Integration Solution to provide executives, business managers, software developers and architects a better sense of the development progress and code quality of projects throughout the development lifecycle. (View Jenkins Best Practices)

Introductory Articles

Note that many links below refer to Hudson, the original name of Jenkins.

Test Drive

Launch Jenkins through Java Web Start for a test drive. Once it launches, visit http://localhost:8080/ to get to the dashboard. Any configuration that you do with this Jenkins will be stored in ~/.jenkins, so your data will survive through Jenkins process restart.

Installation

To run Jenkins, minimally you need to have JRE 1.5 or later. After you download jenkins.war, you can launch it by executing java -jar jenkins.war. This is basically the same set up as the test drive, except that the output will go to console, not to a window.
Alternatively, if you have a servlet container that supports Servlet 2.4/JSP 2.0 or later, such as Glassfish, Tomcat 5, JBoss, Jetty 6, etc., then you can deploy jenkins.war as you would any WAR file. See this document for more about container-specific installation instruction.
Once the war file is exploded, run chmod 755 jenkins in the exploded jenkins/WEB-INF directory so that you can execute this shell script.
If you're running on Windows you might want to run Jenkins as a service so it starts up automatically without requiring a user to log in. The easiest way to achieve this is to simply download and install Jenkins via the native Windows installer, which can be found on the Jenkins main page. Just download the .zip file, unpack it, and click through the install wizard. The wizard both installs Jenkins and sets up the Jenkins Windows service for you.
Another way to run Jenkins as a service is to first install Tomcat as a service and then deploy Jenkins to it in the usual way. Another way is to use the Java Service Wrapper. However, there may be problems using the service wrapper, because the Main class in Jenkins in the default namespace conflicts with the service wrapper main class. Deploying inside a service container (Tomcat, Jetty, etc.) is probably more straightforward, even for developers without experience with such containers.
Also, see how other people are deploying Jenkins/Hudson to get some idea of how to make it fit your environment.

License

The license for the core might be found at https://github.com/jenkinsci/jenkins/blob/master/LICENSE.txt

venerdì 17 maggio 2013

Blogger TFS




http://blogs.ugidotnet.org/lbarbieri/category/1043.aspx?Show=All

http://www.geniodelmale.info/

Understand TFS Licensing

http://blogs.msdn.com/b/govdev/archive/2012/05/14/understand-tfs-licensing.aspx




Team Foundation Server (TFS) is an excellent code version control tool AND the hub of Microsoft’s App Lifecycle Mgt. (ALM) solution. Learn more here.
Now, let’s attempt to demystify some of the aspects of licensing of TFS for enterprise use now:
As illustrated in the below graphic, TFS is licensed on a Server/CAL model. Thus, you need 1 Server license for the TFS server and 1 TFS CAL (client access license) for each user that will use TFS features. That TFS CAL covers the usage no matter how the user accesses TFS (i.e. Visual Studio, Eclipse, Web Access client, Excel, MSProject, 3rd party tool, ect, etc).
 The two ways to acquire TFS CALs are:
   1) Purchase a TFS User CAL   (sku: 126-00196)
   2) 1 TFS CAL (and 1 TFS Server license) is included in each Visual Studio/MSDN subscription. Thus, anyone who has an active MSDN subscription assigned to them is covered with a TFS CAL.


*CLICK TO EXPAND IMAGE*

Finally, there is one exception to the TFS User CAL.   To enable organizations to have an enterprise/central way to capture enhancements requests & bugs from the user population, TFS provides a Work-Item only version of the Team Web Interface.  There are also additional non-CAL capablities around viewing reports coming for TFS 2012.

To read more specfics on all VS/TFS/MSDN licensing... check out the Visual Studio & MSDN Licensing WhitePaper.
  • #
    Reading your post above it would lead one to think that you purchase the server and then need CALs for every user that isn't covered by MSDN no matter how, or what, they access it from.  This isn’t the case.  A few points below around the TFS licensing.  One shouldn’t apply these conditions for anything but TFS.  You’ll still need Windows Server OS/CALs, SQL Server/CALs, & SharePoint Server/CALs where applicable.
    Server Licenses
       •  A Retail TFS Server license grants you the equivalent of 5 TFS CALs.  After the 5th non-msdn user you would need to purchase TFS CALs
       •  MSDN User are granted 1 server license and 1 CAL.  It isn’t clearly stated, but I’ve had several licensing specialists tell me, that the MSDN server license can be accessed by the none MSDN people as long as they have a TFS CAL.  So this being the case an MSDN user provides the TFS Server License.
    CALs
    A TFS CAL is NOT required for accessing TFS if you meet one of the below:
    Accesing TFS Directly:
       •  Accessing Team Foundation Server via the “Work Item Only View” of Team Web Access. This enables users to enter and edit their own work items, such as for defects/bugs or enhancement requests.
       •  Accessing Team Foundation Server reports.
       •  Accessing Team Foundation Server using Microsoft System Center Operations Manager. This enables operations staff to take operational issues encountered in production and raise them as issues to the development team, automatically creating a work item in Team Foundation Server.
       •  Viewing static data that has been manually distributed outside of Team Foundation Server.
       •  Up to two devices or users that only access Team Foundation Server to perform system administration, such as creating Team Projects or Project Collections.
    Accessing TFS Indirectly:
       •  Project Server to TFS Integration does not require a TFS CAL for Project Server users.  Project server can read/write to TFS based on user’s direct changes/input.

martedì 7 maggio 2013

JUnit 4.11 hamcrest 1.3

Con JUnit 4.11 non viene più distribuito hammercrest, su cui però esiste una dipendenza.
Per usare JUnit occorre aggiungere al classpath Aggiungere hamcrest-all-1.3.jar al classpath (https://code.google.com/p/hamcrest/downloads/detail?name=hamcrest-all-1.3.jar&can=2&q=)

lunedì 6 maggio 2013

UnitTest per PMD 4.2.6

Una volta creata una nuova rule in PMD occorre preparare i relativi UnitTests.
In PMD 4.2.6 ad ogni ruleset corrisponde un package per gli unitTest.
Il package è composto da fiale .java e file .xml.
Ogni file .xml contiene un set di test standard, cioè contiene una serie di <test-code> così strutturati:

  • <description>: contiene una descrizione che verrà visualizzata nel report JUnit in caso di errore
  • <rule-property>: ogni elemento di questo tipo descrive una property della rule in esame
  • <expected-problems>: numero atteso di errori ottenuti dall'esecuzione della rule sull'attuale caso di test
  • <code>: pezzo di codice su cui applicare la rule
  • Il nome del file .xml coincide con il nome della rule da testare.
La gestione di questa tipologia di test è eseguita all'interno di SimpleAggregatorTst.java. Qui il metodo runTests() si occupa di eseguire su ogni .xml i casi di test previsti per la rule in esame.

In particolare occorre definire una classe che estende ... ed in cui si caricano tutte le regole con il metodo addRule():

public void setUp() {
        addRule("codesize", "ExcessivePublicCount");

In questo modo si crea una suite di test associata ad un ruleset, e dove gli specifici casi di test sono caricati da fogli .xml associati alle singole rule definite nel ruleset.

E' possibile però definire una suite di test associata ad una classe 

Un secondo modo per eseguire test più complessi è quello di scrivere una suite di test associata ad una singola rule, non ruleset come prima.
In questa classe si può far riferimento ad altri casi di test espressi in file .xml come visto prima, ed usarli in metodi di test con annotazione @Test nel formato JUnit.

Riassumento vediamo alcuni esempi di gestione di UnitTest:

Aggiunta di un nuovo ruleset e relativi unit tests:
Il nuovo ruleset va aggiunto nella cartella di progetto "rulesets", ad esempio: rulesets\coperBasicBE.xml

Una volta aggiunto il ruleset .xml, si deve aggiungere la relativa cartella sotto "regress" del progetto, ad esempio si aggiunge la cartella test/net/sourceforge/pmd/copergmps/vp/rules.
In questa cartella si crea la nuova classe CoperBasicBERulesTest.java
In questa classe, nella versione più semplice, si aggiunge il metodo:


public
void setUp() {
addRule("coperBasicBE", "SetRollbackOnlyMustBeOnlyInEjb"); }

   dove si passano come parametri il nome del ruleset e il nome della rule da testare.

Ricordarsi di modificare populateNameMap() in SimpleRuleSetNameMapper in package net.sourceforge.pmd; altrimenti i non si può caricare la rule con addRule.

A questo punto basta creare un nuovo documento .xml da posizionarsi nella sottocartella xml, rinominandolo con il nome della rule da testare, ad esempio

xml\SetRollbackOnlyMustBeOnlyInEjb.xml

All'interno di questo file si indicano tutti i dati per verificare la regola. Ad esempio.
<?xml version="1.0" encoding="UTF-8"?>
<test-data>
<test-code>
<description><![CDATA[
no braces
]]></description>
<expected-problems>0</expected-problems>
<code><![CDATA[
package it.copergmps.jq.antiriclaggio.bd;public class AnagrafeBD implements IAnagrafeBD {
public Boolean verificaSoggettoRegistrazioneAR(final Integer codiceAzienda, final Long ngrTitolare) throws AntiriclaggioBlockingException {
try {
ContestoUtil contesto = new ContestoUtil();
HAAnagrafePojoPubFactory factory = contesto.getHAFactory();
ngrConforme = factory.getVerificaAntiriciclaggioPOJOInstance("OnLine").
verificaAssoggettabilitaAnagraficaARPerNGR(codiceAzienda.intValue(), ngrTitolare.longValue());
} catch (Exception ex) {
ejbContext.setRollbackOnly();
}
return ngrConforme;
}
}
]]></code>
</test-code>
</test-data>


Aggiunta di un UT di tipo xml ad una rule esistente:

  • Si identifica il ruleset in cui si trova la rule su ci intervenire. Ad esempio per la rule CyclomaticComplexity, il ruleset di riferimento è codesize.xml
  • Noto il nome del ruleset, si ricava il nome del package di test di riferimento: test.net.sourceforge.pmd.rules.codesize
  • Da qui vediamo che i test per questa rule sono definiti sia tramite .xml che tramite classe java. In prima analisi si vuole agire solo sui test standard .xml.
  • Aprendo CyclomaticComplexity.xml andiamo ad aggiungere 
      <test-code>
        <description>
         <![CDATA[
Testing variazioni al report level, abbassandolo a 3
      ]]>
      </description>
        <rule-property name="reportLevel">3</rule-property>      
        <expected-problems>1</expected-problems>
           <code>
            <![CDATA[
public class Foo {
 public void example() {
  int x = 0;
  int a = 0;
  int b = 0;
  int c = 0;
  int d = 0;
  int a1 = 0;
  int a2 = 0;
  int b1 = 0;
  int b2 = 0;
  int z = 0;
  int h = 0;
  int e = 0;
  int f = 0;
  if (a == b) {
      if (a1 == b1) {
   x = 2;
      } else if (a2 == b2) {
   x = 2;
      } else {
   x = 2;
      }
  } else if (c == d) {
      while (c == d) {
   x = 2;
      }
  } else if (e == f) {
      for (int n = 0; n < h; n++) {
   x = 2;
      }
  } else {
      switch (z) {
      case 1:
   x = 2;
   break;
      case 2:
   x = 2;
   break;
      case 3:
   x = 2;
   break;
      default:
   x = 2;
   break;
      }
  }
 }
}
     ]]>
     </code>
       <code-ref id="basic-violation"/>
    </test-code>

                                                                                                                                      • Eseguendo gli UT, facendo attenzione che in build.xml di ant sia richiamato il target regress, dovremmo avre 0 errori.

                                                                                                                                      • Alzando la soglia a 10 e lasciando errore atteso a 1 dovremmo avere una segnalazione di errore<rule-property name="reportLevel">10</rule-property>   
                                                                                                                                      <expected-problems>1</expected-problems>