Leverer til tiden og som forventet

Certified Level 2 Umbraco developer

January 26, 2013 - no comments. Posted by in Programmering.

Certificeret Umbraco level 2 udvikler

Nu kan jeg officielt kalde mig Certified Level 2 Umbraco developer.

Vi har allerede leveret de første Umbraco løsninger og vi forventer at leverer endnu flere i den kommende tid.

Kontakt os hvis du har behov for at få leveret en Umbraco løsning.

Certified Level 1 Umbraco developer

January 24, 2013 - no comments. Posted by in Programmering.

Certificeret Umbraco level 1 udvikler

Nu kan jeg officielt kalde mig Certified Level 1 Umbraco developer.

Nu kommer snart level 2.

Vi har allerede leveret de første Umbraco løsninger og vi forventer at leverer endnu flere i den kommende tid.

Kontakt os hvis du har behov for at få leveret en Umbraco løsning.

Rema 1000 app runder 1500 downloads

January 23, 2013 - no comments. Posted by in Nyheder.

Den Windows Phone App som Jee Consult har lavet for  Rema 1000 har nu rundet 1500+ downloads.

I den seneste uge er den i gennemsnit blevet downloadet 100 gange om dagen den seneste uge.

Det er vi meget tilfredse med specielt set i lyset af at den ikke er blevet reklameret nogen steder.

Jee Consult har lanceret sin første windows phone App for Rema 1000

January 8, 2013 - no comments. Posted by in Nyheder.

Den 3/1 2013 fik Jee Consult sin første Windows Phone App godkendt af Microsoft.

Appen gør det muligt for kunder i Rema 1000 at se tilbudsaviser, lave indkøbsliste, se tilbud, se opskrifter og finde butikker.

Data til applikationen er hentes fra eTilbudsavis, som har lavet et Api til deres data.

I forbindelse med opgaven har Jee Consult udvidet en del af Api for at gøre det muligt at hente yderlig data.

 

Jee Consult har stået for al programmering af applikationen, integration mod eTilbudsavis og udarbejdelse af navigation.

Performa har stået for at lave design og grafik til applikationen.

I skrivende stund har Appen allerede passeret 500 downloads og det forventer vi vil blive meget højere i den kommende tid.

Hvis du mangler en Windows Phone app så kontakt os for et tilbud.

Hvordan bestemmer man dynamisk start view i en Windows Phone App?

December 17, 2012 - no comments. Posted by in Programmering.

I Rema 1000 Appen er der et behov for at vise egenskabs side, når man starter Appen for første gang.
Som standard sendes man til MainPage.xaml siden, men det giver problemer hvis man skal redirecte fra den til egenskabssiden.
Det er ikke nogen smidig løsning.
Personligt mener jeg at det er bedst at gå den direkte vej.
I en standard App defineres en default task i WMAppManifest.xml filen.
<Tasks>
<DefaultTask Name="_default" NavigationPage="Views/MainPage.xaml" />
</Tasks>

For at selv definere hvilken en side som man skal starte på så skal NavigationPage sættes til en tom streng:
<Tasks>
<DefaultTask Name="_default" NavigationPage="Views/MainPage.xaml" />
</Tasks>

 

I app.xaml findes der et event kaldet Application_Launching.
Her definerer man hvordan der skal redirectes til en bestemt startside:
string uri = string.Empty;
//Show propertypage on first startup.
if (App.ViewModel.UserViewModel.FirstTimeApplicationRuns)
{
uri = String.Format("/Views/PropertiesPage.xaml");
}
//Else redirect to mainpage.
else
{
uri = String.Format("/Views/MainPage.xaml");
}
//Perform the actual redirect
((App)Application.Current).RootFrame.Navigate(new Uri(uri, UriKind.Relative));

Hvordan poster man fra et program i C# til en side på Facebook?

December 15, 2012 - one comment. Posted by in Programmering.

På Twitter var der en som spurgte efter hjælp til Facebook SDK til C# .
Jeg undersøgte SDK og skrev tilbage at det kunne jeg godt.
Vi skrev lidt frem og tilbage på e-mail og han ville gerne have assistance til at poste noget data (tekst, billede eller lignende) på en side.
Det skulle se ud som om data var skrevet af siden selv.
Umiddelbart lød det som en udfordring som jeg nemt ville kunne løse fordi at SDK, så ikke ud til at være noget problem at arbejde med.

Jeg oprettede derfor en side, som jeg kunne bruge som test.
Jeg kunne læse mig frem til at det var nødvendigt at få en access_token for at kunne poste til en side.

Efter noget tid fandt jeg også ud af at jeg ikke kunne gøre det uden at lave en Facebook app, derfor oprettede jeg en sådan.
Alle steder jeg læste skrev de om at man bare skulle have en offline access token fra Facebook, så var man godt kørende.
Men på facebook skrev de om at offline access var blevet udfaset og man nu ikke længere kunne bruge den type tokens.
Nu kunne man få tokens som var gyldige i op til 60 dage.

Jeg brugte en del tid på at læse i Facebooks developer hjælp og blog og efter et godt stykke tid fandt jeg ud af at man kunne få en permanent ticket.
Det lykkedes også til sidst at få den permanente ticket.

Hele denne her process har været meget lærerig og meget frustrerende fordi selv om jeg er vant til MSDN og andre hjælpe sider, så var Facebooks developer side noget af det værste jeg
længe her set.
Jeg brugte meget lang tid på at stykke del informationer sammen til et samlet billede.
Specielt hele processen med at få access_tokens er ret svær og tog meget tid.
Jeg har så lavet en step by step guide til hvordan man gør:

  1. Opret den side som der skal bruges.
  2. Når du navigere ind på siden, skal du meget gerne komme ind på en url som ser sådan ud:

    https://www.facebook.com/pages/SideNavn/EtSideId

    Du skal bruge sideId, så du ved hvor der skal postes til

  3. Register dig som udvikler på
  4. Opret en App.
  5. App skal være af typen Website with Facebook Login.
  6. Du skal indtaste en url som du selv har adgang til.
  7. Find dit userid ved at gå ind på

    http://graph.facebook.com/DitBrugernavn

    Det vil vise dig noget json som indeholder dit userid

  8. Modificer felterne med [] i nedenstående url: https://www.facebook.com/dialog/oauth?client_id=[APPID]&client_secret=[APPSECRET]&redirect_uri=[APP URL]&scope=manage_pages,,publish_stream&response_type=token
  9. Tryk på gå til app
  10. Tryk på tillad knappen
  11. Du bliver her efter redirected til den side du har indtastet under redirect_uri.
    Linket ser nogenlunde ud som dette her:
    “http://www.jeeConsult.dk/#access_token=[temp_access_token]&expires_in=4950″
  12. Modificer felterne med [] i nedenstående ur, [temp_access_token] hentes fra forrige resultat.

    https://graph.facebook.com/oauth/access_token?client_id=[APP_ID]&client_secret=[APP_SECRET]&grant_type=fb_exchange_token&fb_exchange_token=[temp_access_token]

  13. Det giver en access_token som ikke udløber.
  14. Det er denne access_token som skal bruges i programmet.

Her er den c# kode som man benytter til at poste til Facebook siden
string pageId = "sideid"; //findes under pkt 2 i step guiden
string accessToken = "dinaccesstoken";
FacebookClient fc = new FacebookClient(accessToken);
// fill in parameters for the message to post
dynamic parameters = new ExpandoObject();
parameters.message = "test";
parameters.access_token = accessToken;
dynamic result = fc.Post(pageId + "/feed", parameters);

Håber at det kan hjælpe andre til at undgå de issues som jeg har oplevet.

Jee Consult lancerer snart første Windows Phone app for Rema 1000

December 7, 2012 - no comments. Posted by in Nyheder.

I den seneste tid har vi arbejdet hårdt med den første Windows Phone app.
Appen er til Rema 1000 og er lavet i samarbejde med eTilbudsavis og Performa.
Jee Consult har stået for programmeringen, Performa for design og eTilbudsavis leverer data til App gennem deres Api.
eTilbudsavis har stået for kontakten til Rema 1000.
App er nået til betatestnings fasen og i den forbindelse søger vi efter betatestere.
Hvis du ønsker at være med så skriv et indlæg til denne nyhed.

Forbindelses problemer til WCF webservices primært framework 3.0 og 3.5

June 27, 2011 - no comments. Posted by in Programmering.

WCF er en meget brugt teknologi.
I modsætning til almindelige webservices er der en masse ting som man kan og skal konfigurere.
Desværre er standard indstillingerne ikke altid optimale.
Jeg lavede noget arbejde for en kunde, hvor der var lavet en WCF service, som blev brugt af et eksternt system til at lave forskellige opslag.
Der var en række perfomance problemer med webservicen.
Hvis man lavede enkelte kald til den gik det hurtigt, hvis man lavede flere kald på samme tid via forskellige browsere gik det meget langsomt.
Det første som jeg gjorde var at undersøge selve koden som blev afviklet. Den kørte lige hurtigt uanset hvor mange kald der blev lavet.
Så det eneste kunne være fejl i selve konfigurationen af WCF.
Det første jeg gjorde var at sætte Concurrency mode i selv services (læs mere om Concurrencymode):
[ServiceBehavior(Namespace = "xx", ConcurrencyMode = ConcurrencyMode.Multiple)]
Standard Concurrency mode er single.
Det gav en hvis forbedring. Dog var det ikke helt nok.
Derfor var det naturligt at kigge på de forbindelser som blev oprettet.

En standard WCF konfiguration tillader kun et bestemt antal forbindelse og når det bliver opbrugt så får et kald lov til at vente indtil der er en ledige forbindelse.
Det gælder derfor om at forsøge at skalere sin service til at kunne håndtere nok forbindelser.
Dog afhænger det i høj grad af hvor belastende operationer der skal udføres, hvis det bare er simple regne operationer kan en server håndtere langt mere end hvis det er mere komplekse operationer.
For at kunne definere hvor mange forbindelser man kan lave til en webservice skal man have fat i Servicebehavior. Her er et eksempel på hvordan den kan se ud:
<behavior name="Namespace.Webservices.xx">
<serviceMetadata httpGetEnabled="false" httpGetUrl="" httpsGetEnabled="true" httpsGetUrl="" />
<serviceThrottling maxConcurrentCalls="16"
maxConcurrentInstances="100"
maxConcurrentSessions="116" />
<behavior>

Det er selve serviceThrottling elementet som der skal justeres på.
1. maxConcurrentCalls er max antallet af aktive messages i servicen. Fra asp.net 4 er den 16 gange antal processorer, i 3.x er den 16. Hvis man bruger 3.x bør man sætte det til 16 * antal cpu’r

2. maxConcurrentSessions er antallet af sessioner som er servicehost accepterer. Fra asp.net 4 er det 100 gange antallet af processorer, i 3.x er den 10. Hvis man bruger 3.x bør man sætte den til 100 * antal cpu’r

3. maxConcurrentInstances er max antallet af InstanceContext objekter i servicen. Fra asp.net 4 er den maxConcurrentCalls + maxConcurrentSessions, i 3.x er den 26. Hvis man bruger 3.x bør man sætte den til maxConcurrentCalls + maxConcurrentSessions.

I framework 4.0 har Microsoft rettet op på tingene og det er godt. Hvis man bruger 3.x bør man justere sin config så den som minimum matcher en 4 konfiguration.
Men generelt er man nødt til at lave en masse test af sine WCF services, det kan gøres ved at lave en simpelt multithreaded applikation som kan foretage masse kald til webservicen for at simulere en realistisk belastning.
Man skal forsøge at finde et realistisk niveau for testen, der er ikke 1000 samtidige kald i en enkelt bruger applikation.
Men selv med en god test er man nødt til at vurdere performance når tingene er lagt i produktion, fordi det er det eneste som giver en realistisk billede.
Jeg har her give nogle ideer til hvad man kan justere på hvis det er servicen som er langsom,

Konvertering af csv til datatable

February 24, 2011 - no comments. Posted by in Programmering.

Hos en kunde har jeg haft en opgave om at en masse data fra csv filer skulle gemmes i en database.
Der skulle laves en masse validering af indholdet før at det blev gemt i databasen.
Der findes mange forskellige måder at gøre det på.
Man kan f.eks. indlæse alt data i en tabel som bare indeholder en række varchar kolonner og så løbe hver enkelt række igennem.
Men det giver bare et ekstra led i stedet for at validere data direkte fra csv filen.
Linierne ser ud på denne måde. De indeholder nogle forskellige datatyper

284,1.138688E+07,test,18-10-2010 19:35:15

For at få valideret data indlæses det direkte i en datatable som er defineret på denne måde:

DataTable tbl = new DataTable();
tbl.Columns.Add("id", typeof(int));
tbl.Columns.Add("value", typeof(float));
tbl.Columns.Add("coid", typeof(string));
tbl.Columns.Add("stamp", typeof(DateTime));

Selve indlæsningen foregår på denne måde:

//Stien til filen som skal indlæses
FileInfo FileInfo = new FileInfo("c:\\test.txt");
string line = string.Empty;
int lineCounter = 0;
//Åben filen
using (FileStream f = FileInfo.OpenRead())
{
//Læs filestream indholdet
using (StreamReader s = new StreamReader(f))
{
//Læs første linie
line = s.ReadLine();
lineCounter++;
//Gør datatable klar til indlæsning af data
tbl.BeginLoadData();
//bliv ved med at læse indtil der ikke kan læses mere
while ((line = s.ReadLine()) != null)
{
//hold styr på linie nr
lineCounter++;
try
{
//tilføj den enkelte række ved at splitte den til et array og tilføje den til datatabellen.
//Her kan man udvide validering ved at tjekke den enkelte værdier igennem inden de lægges i datatable.
//på den måde benytter man ikke try catch som flow control hvilket ikke er nogen god ide.
//Her bruges det for gøre eksemplet mere simpelt.
tbl.Rows.Add(line.Split(','));
}
catch (Exception e)
{
//håndter fejl
//Errors.Add(" Line nr " + lineCounter + " failed with the following exception " + e.ToString() + ". Line data is : "+ line);
}
}
//aflut indlæsning af data
tbl.EndLoadData();
//ryd op
s.Close();
s.Dispose();
}
}

Viewstate, SessionPageStatePersister og out ofmemory exception

February 8, 2011 - no comments. Posted by in Programmering.

En af de kunder jeg arbejder for har en tilmeldelses formular som er dynamisk opbygget i en wizard kontrol.
Den opygger en meget stor viewstate, derfor lavede jeg oprindeligt en løsning hvor viewstate blev gemt i en session.
Det betød at hastigheden blev markant bedre.
Teknikken med at gemmme viewstate i en sessionpagestatepersister kan der læses mere om her

Desværre er der nogle negative konsekvenser ved at bruge sessionpagestatepersister, ikke så meget på små websites, men når
trafik mængden stiger så øges hukommelses forbruget på serveren og det kan give out of memory exceptions.

Så er man tilbage ved at skulle have viewstate i et hiddenfield, men der er problemet at viewstate måske fylder meget og
gør siden langsom.

Man kan sætte IIS op til at bruge HTTP Compression, men hvis man ikke har kontrol med serveren kan det være svært.
Man kan læse mere om det her her

Jeg valgte at arbejde med en løsning hvor man komprimerer viewstate.
Det betød at størrelsen på siden gik fra omkring 200 kb til 40 kb.
Løsningen som blev valgt var en modificeret version af denne her

Det giver selvfølgelig mere arbejde til webserveren, men i dette tilfælde er webserveren ikke belastet og derfor har det ikke nogen negative konsekvenser.

Det findes en sidste løsning og det er at undgå viewstate i det hele taget, men det ville være en næsten umulig opgave i dette tilfælde.

Viewstate var ikke det eneste som brugte meget hukommelse på serveren, der var et par andre ting som også havde indflydelse, som også er blevet rettet til og alt i alt har det forbedret
bruger oplevelsen markant.