Posts

Kopen, bouwen of allebei?

Wed, 06 May 2026 11:06:34 Z

U wilt een nieuwe markt aanboren, kosten verlagen, of een proces automatiseren. Nieuwe software kan helpen, maar welke software past bij uw situatie?

Er zijn drie hoofdcategorieën: 1) standaardsoftware, 2) software as a service (SaaS), en 3) maatwerksoftware. Dit artikel bespreekt de voor- en nadelen van elk type en helpt u de juiste keuze te maken.

Een goed vertrekpunt is de vraag of het proces dat u wilt oplossen een concurrentievoordeel is of een standaardactiviteit. Als alle bedrijven in uw sector hetzelfde proces op dezelfde manier uitvoeren, is een pakketoplossing waarschijnlijk de juiste keuze. Als het proces juist onderscheidend is voor uw organisatie, is het de moeite waard om te overwegen de software die dat proces aantuurt zelf te bezitten.

Wanneer is standaardsoftware of SaaS de juiste keuze?

Als u een tekstverwerker, e-mailclient, of boekhoudpakket nodig heeft, is het al gedaan. Het aanbod is groot, de producten zijn volwassen, en de prijzen lopen uiteen van gratis tot zeer betaalbaar.

Steeds meer bedrijfssoftware valt in deze categorie, zoals enterprise content management, documentbeheer en CRM-software. Deze tools hebben een duidelijk doel en zijn daar doorgaans goed in.

Qua kosten is standaardsoftware kopen meestal goedkoper dan maatwerksoftware laten bouwen. Dat klopt vaak, maar er zijn nuances die dit beeld kunnen veranderen.

Dit is waar de meeste software-evaluaties eindigen. Het voldoet aan de eisen en het is goedkoper. Gewoon kopen en doorgaan, toch? Even niet zo snel.

Er zijn risico's aan standaardsoftware en SaaS die vaak over het hoofd worden gezien:

Ze bevatten vaak modules die u niet nodig heeft en missen soms functionaliteit die u wel nodig heeft. Extra modules kosten extra. Implementatie en aanpassing aan uw organisatie ook.
Ze werken in functionele silo's en komen vaak van meerdere leveranciers. U moet zeker weten dat integratie met uw bestaande systemen haalbaar is.
Ze geven u mogelijk niet de controle over uw eigen data die u nodig heeft.
Uw gebruikers zijn misschien minder enthousiast over uw keuze dan uzelf.

Laten we deze risico's nader bekijken en bepalen wanneer ze de balans richting maatwerksoftware doen doorslaan.

Precies wat u nodig heeft, niet meer en niet minder

Standaardsoftware kopen is de juiste keuze als het pakket volledig aansluit op uw bedrijfsprocessen. Maar in de praktijk koopt u vaak functionaliteit die u niet gebruikt en mist u functionaliteit die u wel nodig heeft. U zou uw bedrijfsvoering niet moeten aanpassen aan de software die u aanschaft.

De gebruikelijke oplossing is consultants inschakelen om het pakket te implementeren en aan te passen. Als de software grotendeels aansluit op uw eisen, kan dat goed werken. U wilt dan dat consultants de scherpe randjes bijvijlen, niet dat ze het systeem herschrijven. Ze configureren het voor uw organisatie en koppelen het eventueel aan bestaande systemen.

Op een gegeven moment, en dat moet vrij snel na de implementatie zijn, moeten de consultants klaar zijn en vertrekken. Als ze blijven terugkomen voor aanpassingen en integraties, bent u de rechtvaardiging voor kopen in plaats van bouwen al kwijt.

Hier zit het addertje onder het gras dat organisaties vaak verrast: die aanpassingen blijven niet staan. Wanneer de leverancier een nieuwe versie uitbrengt, moet elke aanpassing opnieuw worden beoordeeld, getest, en in veel gevallen herschreven om de upgrade te overleven. Organisaties die zwaar hebben gecustomised, besteden structureel ontwikkelcapaciteit aan het bijhouden van hun eigen afwijkende versie. Op dat moment heeft u geen software meer gekocht. U heeft een startpunt gehuurd en vaste medewerkers aangenomen om de kloof met de standaardversie te onderhouden. Maatwerksoftware kost meer bij de start, maar u betaalt niet permanent voor aanpassingen die u eigenlijk nooit had moeten hoeven maken.

Diepe integratie met uw bestaande systemen

Bij standaardsoftware loopt integratie met uw andere systemen uiteen van eenvoudig tot een volwaardig implementatieproject. Als u bijvoorbeeld CRM-software aanschaft en uw bestaande klantgegevens wilt importeren, zou dat standaard moeten werken. Pijnlijke integraties ontstaan wanneer u de data er niet uitkrijgt, of alleen via een leveranciers-API die per definitie niet is ontworpen om volledige export gemakkelijk te maken.

Als het nieuwe systeem onderdeel is van een groter proces, of als het de centrale databron wordt voor uw organisatie, zijn er veel integratiepunten voor data die in en uit het systeem stromen.

Bij maatwerksoftware zijn die integratiepunten ingebouwd omdat ze onderdeel zijn van de oorspronkelijke eisen. De software integreert diep met uw huidige systemen. Als het goed gedaan is, zijn de nieuwe APIs op een standaard manier gebouwd, zodat toekomstige applicaties er zonder extra werk gebruik van kunnen maken.

Hoe stabiel is die leverancier? Wat is uw exitstrategie?

De waardepropositie van standaardsoftware is de functionaliteit die u krijgt voor de prijs die u betaalt. Maar die waarde verdampt als de leverancier failliet gaat, wordt overgenomen, of de prijs verhoogt op het moment dat u te diep verweven bent om gemakkelijk te vertrekken. En hoe meer u heeft aangepast, hoe lastiger de overstap wordt. Dat is geen toeval.

SaaS-bedrijven zijn hier bijzonder goed in. Lage instapprijzen halen u aan boord. Integratie met uw systemen en jaren aan opgeslagen data verhogen uw overstapkosten. Bij contractverlenging onderhandelt u vanuit een zwakke positie.

Veel SaaS-platforms kennen ook geen standaard-API die concurrerende producten ondersteunen. Dat betekent dat uw exitplan een migratieproject vereist, niet alleen een beslissing. Voordat u een meerjarig contract tekent, moet u precies weten hoe u uw data terugkrijgt en in welk formaat. En test het. Voer de export uit in een niet-productieomgeving en controleer of het resultaat ook daadwerkelijk bruikbaar is. De meeste organisaties doen dit pas als het nodig is, en dat is precies het slechtste moment om te ontdekken dat het plan niet werkt.

Bij maatwerksoftware bezit uw organisatie de code en de data vanaf dag één. Er is geen leverancier om mee te onderhandelen en geen eigen formaat om uit te ontsnappen.

Waar staat uw data?

Bij standaardsoftware staat de data vaak in een eigen database. Zelfs als het een gangbaar formaat is, ondersteunen veel leveranciers geen directe queries op hun dataopslag, of berekenen ze extra voor rapportagetoegang.

Bij SaaS staat uw data in de cloud, op infrastructuur die u niet beheert en in een jurisdictie die u mogelijk niet heeft gekozen. Voor sommige organisaties is dat geen probleem. Voor enterprise-organisaties die opereren onder de AVG, sectorspecifieke regelgeving, of interne beveiligingseisen is het een reëel obstakel. Toezichthouders accepteren "de leverancier regelt dat" niet als antwoord wanneer er iets misgaat. U blijft verantwoordelijk voor uw data, ongeacht waar die zich bevindt.

Maatwerksoftware plaatst de data waar uw organisatie dat vereist, omdat opslaglocatie, toegangscontrole en compliancevereisten onderdeel zijn van de oorspronkelijke specificatie. U kunt een beveiligingsaudit doorstaan omdat u de antwoorden kent.

Draagvlak bij uw gebruikers

Het klassieke IT-inkoopproces is: eisen opstellen, het pakket zoeken dat het beste aansluit, en de technische beoordeling overdragen aan een specialist. Dat werkt prima voor de IT-kant van de afweging.

Het probleem ontstaat wanneer een pakket is gekozen en gebruikers te horen krijgen dat ze de volgende maandag in training zitten en de maandag daarna met het nieuwe systeem moeten werken. Als gebruikers niet betrokken zijn geweest bij de keuze, kunnen ze het systeem afwijzen of de implementatie ondermijnen.

Bij maatwerksoftware en maatwerkintegraties worden gebruikers vroeg betrokken bij de eisen, en het nieuwe systeem wordt gebouwd naar hun specificaties. Zij zijn de belangrijkste stakeholders en bepalen mede de toon voor een succesvolle adoptie in uw organisatie.

Conclusie

Software-inkoopbeslissingen kunnen net zo complex zijn als de problemen die ze moeten oplossen. Beslissers moeten de korte en lange termijn kosten en risico's afwegen van het kopen van standaard- of SaaS-software, het kopen en aanpassen ervan, of het volledig inzetten op maatwerksoftware. Het makkelijkste antwoord is niet altijd het beste antwoord als alle risico's worden meegewogen.

Neem contact op met Volare Software voor meer informatie over maatwerksoftware laten bouwen voor uw organisatie.

Wat is maatwerk software?

Tue, 18 Apr 2023 14:20:03 Z

Zeker, we verkopen software op maat, maar we zullen vaak de eerste zijn om off-the-shelf software aan te bevelen als dat beter past bij uw budget, bereik of tijdlijn. Off-the-shelf software is handig en kosteneffectief, maar soms voldoet het niet helemaal aan de unieke behoeften van uw bedrijf. In die gevallen kan softwareontwikkeling op maat de betere keuze zijn.

U vraagt zich misschien af: wat IS maatwerksoftware precies? En wat is het verschil met de social media-apps op uw telefoon of de tekstverwerker die u op uw werk gebruikt?

Simpel gezegd is maatwerksoftware een op maat gemaakte oplossing die speciaal is ontworpen voor de behoeften van uw bedrijf. In tegenstelling tot kant-en-klare software, die is ontworpen om te worden gebruikt door een breed scala van personen en organisaties, wordt maatwerksoftware gebouwd met uw specifieke bedrijfsprocessen, eisen en doelstellingen in gedachten.

Software op maat is in veel opzichten vergelijkbaar met het bouwen van een huis op maat. Net zoals een huis op maat wordt ontworpen om te voldoen aan de specifieke behoeften en eisen van de eigenaar, wordt software op maat ontwikkeld om te voldoen aan de unieke behoeften en eisen van een bedrijf. In beide gevallen is het eindresultaat een oplossing die is afgestemd op de exacte specificaties van de eigenaar en zijn individuele stijl en voorkeuren weerspiegelt. Net zoals een huis op maat een team van architecten, bouwers en ontwerpers vereist om de visie van de eigenaar tot leven te brengen, vereist de ontwikkeling van software op maat een team van ontwikkelaars, ontwerpers en projectmanagers om een oplossing te creëren die voldoet aan de specifieke behoeften van de klant. En net zoals een huis op maat het leven van de eigenaar zowel efficiënter als mooier kan maken, kan software op maat een enorme waarde toevoegen aan een bedrijf, de productiviteit verbeteren, processen stroomlijnen en groei stimuleren.

Bekijk het zo: de social media-apps die u op uw telefoon gebruikt, zijn ontworpen voor gebruik door een groot publiek, met functies en functionaliteit die zich richten op een breed scala aan gebruikers. Uw tekstverwerkingssoftware kan meer gespecialiseerde functies hebben, maar is nog steeds ontworpen om te worden gebruikt door een breed scala van industrieën en beroepen.

Aan de andere kant is het voorraadbeheersysteem of de software voor wagenparkbeheer die uw bedrijf gebruikt waarschijnlijk meer gespecialiseerd en afgestemd op de specifieke behoeften van uw bedrijf. Het kan beschikken over functies en functionaliteiten die u niet kunt vinden in kant-en-klare software, en het is ontworpen om uw bedrijf efficiënter en effectiever te laten werken.

Maatwerksoftware kan vele vormen aannemen, van desktopapplicaties tot mobiele apps en webgebaseerde systemen. Maar welke vorm het ook aanneemt, het doel van software op maat is om een oplossing te creëren die perfect bij uw bedrijf past.

Waarom zou u maatwerksoftware verkiezen boven kant-en-klare oplossingen? Het antwoord is eenvoudig: omdat de software is ontworpen op basis van de unieke behoeften van uw bedrijf, kan maatwerksoftware een niveau van functionaliteit, efficiëntie en productiviteit bieden dat niet kan worden geëvenaard door standaardoplossingen. En omdat de software specifiek voor uw bedrijf is ontworpen, kan deze gemakkelijker worden geïntegreerd met uw bestaande systemen en processen, waardoor u minder tijd en moeite hoeft te besteden aan het trainen van uw personeel in nieuwe software.

Bij Volare Software zijn we gespecialiseerd in het ontwikkelen van software op maat. We helpen bedrijven van alle groottes en industrieën om oplossingen te vinden die voldoen aan hun unieke behoeften. Als u moe bent van het gebruik van kant-en-klare software die gewoon niet helemaal past, neem dan vandaag nog contact met ons op voor meer informatie over hoe maatwerk software uw bedrijf naar een hoger niveau kan tillen.

Tien fouten die u moet vermijden bij het kiezen van een bedrijf dat software op maat ontwikkelt

Sun, 02 Apr 2023 18:24:49 Z

De juiste partner kiezen voor softwareontwikkeling op maat

De juiste softwareontwikkelingspartner kiezen is een van de meest bepalende beslissingen in een softwareproject. De verkeerde keuze kost tijd, geld en soms het project zelf. We bouwen al sinds 2009 enterprise software en hebben deze fouten van beide kanten van de tafel gezien.

Fout 1: Een bedrijf kiezen dat niet kan leveren wat je nodig hebt

Dit klinkt voor de hand liggend, maar veel bedrijven evalueren leveranciers op prijs of beschikbaarheid in plaats van op relevante ervaring. Vraag om voorbeelden van werk dat vergelijkbaar is met jouw project. Niet alleen logo's op een website, maar echte casestudies met resultaten. Een bedrijf dat soortgelijke problemen heeft opgelost, stelt betere vragen en neemt betere beslissingen gedurende het project.

Fout 2: Een bedrijf kiezen dat je na de lancering niet kan ondersteunen

Maatwerk software heeft onderhoud, beveiligingsupdates en verbeteringen nodig over tijd. Een leverancier die na de livegang verdwijnt, laat je achter met een systeem dat niemand meer begrijpt. Vraag hoe ze post-launch ondersteuning regelen voordat je tekent, niet erna.

Fout 3: Referenties en track record niet controleren

Je ontwikkelingspartner heeft toegang tot jouw bedrijfsprocessen, jouw gegevens en soms de informatie van jouw klanten. Controleer referenties. Lees onafhankelijke beoordelingen op Clutch of vergelijkbare platforms. Een bedrijf met niets te verbergen maakt dit gemakkelijk.

Fout 4: Vaste prijscontracten accepteren zonder de risico's te begrijpen

Als prijzen te goed of te precies klinken, vraag dan hoe ze omgaan met scopewijzigingen. Vaste prijscontracten vereisen dat alle vereisten vooraf worden gedefinieerd, wat bij een echt project vrijwel nooit haalbaar is. Wanneer vereisten veranderen, en dat zullen ze, verandert een vast prijscontract jouw leverancier in een tegenstander die discussieert over wat wel en niet in de oorspronkelijke specificatie stond. We hebben nooit op basis van een vaste prijs gewerkt, omdat we het nooit een goed resultaat voor de klant hebben zien opleveren.

Fout 5: De technologiestack niet controleren

Zorg ervoor dat de leverancier bouwt in technologieën die jouw organisatie kan ondersteunen en onderhouden. Als jouw IT-afdeling draait op Microsoft Azure en .NET, creëert een leverancier die een onbekend platform voorstelt een langetermijn onderhoudsprobleem. Vraag specifiek waarmee ze zullen bouwen en waarom.

Fout 6: Het belang van communicatie onderschatten

Je werkt maanden nauw samen met dit team. Slechte communicatie kost meer dan het bespaart. Zoek naar een leverancier die responsief is tijdens het verkoopproces, een duidelijk communicatieplan heeft voor het project en kan aantonen hoe ze klanten op de hoogte houden. Als ze moeilijk te bereiken zijn voor je tekent, zijn ze dat ook erna.

Fout 7: Intellectuele-eigendomsrechten niet verduidelijken

In de meeste Nederlandse en Europese contracten is de opdrachtgever eigenaar van alles wat in het kader van een werk-voor-huur-overeenkomst wordt geproduceerd. Ga daar niet van uit. Leg het schriftelijk vast en bevestig dat de leverancier jouw code, architectuur of bedrijfslogica niet voor andere klanten mag hergebruiken.

Fout 8: De ontwikkelingsmethodologie niet begrijpen

Vraag hoe de leverancier een project beheert van kickoff tot oplevering. Zie je regelmatig werkende software, of is er een lange stille periode gevolgd door een oplevering? Wij laten klanten aan het einde van elke sprint van twee weken werkende software zien, zodat er geen verrassingen zijn. Als een leverancier zijn proces niet duidelijk kan uitleggen, is dat een waarschuwingssignaal.

Fout 9: Geen duidelijk contract tekenen

Een gedetailleerd contract beschermt beide partijen. Het moet scope, betalingsvoorwaarden, wijzigingsbeheer, intellectueel eigendom, aansprakelijkheid, vertrouwelijkheid, geschillenbeslechting en post-launch ondersteuning omvatten. Als een van deze onderwerpen vaag is in het contract dat je bekijkt, vraag dan om verduidelijking voor je tekent. Ons artikel over tien rampen om te vermijden in je volgende contract voor softwareontwikkeling op maat beschrijft in detail waar je op moet letten.

Neem contact met ons op om jouw project te bespreken, of lees meer over onze softwareontwikkeling op maat.

Wat kost softwareontwikkeling op maat?

Mon, 06 Aug 2018 06:00:00 Z

Overweeg je maatwerk software te laten ontwikkelen?

Wil je een idee van de kosten voordat je een kennismakingsgesprek plant? In dit artikel leggen we uit hoe maatwerk software geprijsd wordt, welke factoren de kosten bepalen en wat je bij verschillende projectgroottes kunt verwachten.

Hoeveel kost softwareontwikkeling op maat?

De kosten van maatwerk software hangen af van teamgrootte, projectduur en complexiteit. Op basis van onze ervaring sinds 2009 hanteren we de volgende indicaties:

Kleine projecten, zoals MVP's, kleine DevOps-trajecten of cloudmigraties, starten vanaf €25.000 voor één fulltime ontwikkelaar gedurende één tot twee maanden.
Middelgrote projecten, zoals webapplicaties met meerdere modules, API-integraties of databaseplatforms, lopen van €50.000 tot €200.000 en duren doorgaans drie tot zes maanden met één of twee ontwikkelaars.
Grote enterprise-projecten met meerdere systemen, complexe integraties of regelgevingsvereisten kunnen meer dan €250.000 kosten en lopen van zes maanden tot meerdere jaren met teams van drie tot vijf ontwikkelaars.

Wat bepaalt de kosten?

De grootste kostenfactoren zijn teamgrootte en projectduur. Daarnaast verhogen de volgende zaken de complexiteit en daarmee de kosten:

Koppelingen met externe systemen. Elke API-verbinding met een extern systeem, of het nu gaat om een betaalverwerker, een ERP of een overheidsgegevensbron, vergroot de scope en het testoppervlak.
Betrokkenheid van bestaande systemen. Migreren of integreren met een bestaand systeem zonder goede documentatie of met inconsistente data kost aanzienlijk meer tijd dan nieuwbouw.
Wet- en regelgeving. Projecten in de zorg, financiële sector, defensie of overheid brengen compliance-overhead mee die invloed heeft op de architectuur, het testen en de documentatie.
Prestaties en schaalbaarheid. Een systeem dat duizenden transacties per minuut moet verwerken, vraagt een andere architectuur dan een systeem dat er tientallen verwerkt.
Complexiteit van de gebruikerservaring. Een consumentgerichte applicatie met een verzorgde interface en mobiele optimalisatie kost meer tijd dan een intern systeem voor getraind personeel.

Wat is er inbegrepen in het maandtarief?

Bij Volare Software omvat ons maandtarief ontwikkeling, codereview, geautomatiseerd testen, deployment en projectcommunicatie. We brengen geen aparte kosten in rekening voor sprintplanning, architectuurbeslissingen of voortgangsrapportages. Je betaalt voor een team en dat team levert werkende software.

Waarom we geen vaste prijscontracten aanbieden

Vaste prijscontracten vereisen dat alle eisen vooraf bekend en gedocumenteerd zijn. In de praktijk veranderen de eisen bij elk project, vaak ingrijpend. Een vast prijscontract plaatst je leverancier in de positie dat hij moet betogen dat jouw nieuwe wens niet in de oorspronkelijke specificaties stond. Dat is slecht voor het project en slecht voor de samenwerking.

Wij werken liever met transparante time-and-materialsovereenkomsten waarbij we het maandelijkse teamtarief vastleggen en een bandbreedte voor de totale doorlooptijd opgeven. Jij bepaalt hoeveel scope je oppakt en kunt het team op elk moment aanpassen of het traject pauzeren.

De belangrijkste software eerst opleveren

We werken met een agile ontwikkelproces waarbij de modules met de hoogste bedrijfswaarde als eerste worden gebouwd. Zo beschik je vroeg in het traject over werkende, inzetbare software, wat het risico vermindert en je in staat stelt het product te valideren bij echte gebruikers voordat het project is afgerond.

Neem vandaag nog contact met ons op voor meer informatie over onze softwareontwikkeling op maat.

De kracht van aangepaste software ontsluiten: is het de investering waard?

Tue, 08 Aug 2023 17:49:16 Z

Is softwareontwikkeling op maat de investering waard?

Maatwerk software kost meer vooraf dan kant-en-klare alternatieven. Voor veel organisaties is die kostprijs gerechtvaardigd. Voor andere niet. Dit artikel legt uit wanneer softwareontwikkeling op maat een sterk rendement op investering oplevert en wanneer niet.

Wanneer maatwerk software financieel zinvol is

Maatwerk software is de investering waard wanneer een of meer van de volgende voorwaarden van toepassing zijn:

Jouw proces is een concurrentievoordeel. Als de manier waarop je opereert jou onderscheidt van concurrenten, beschermt software die rond dat proces is gebouwd dat voordeel. Standaard software dwingt je te werken zoals jouw leverancier het heeft ontworpen, wat betekent dat je op dezelfde manier werkt als elk ander bedrijf dat dat product gebruikt.
Je betaalt voor functies die je niet gebruikt. Enterprise SaaS-producten rekenen voor mogelijkheden die zijn gebouwd voor de breedst mogelijke markt. Als je 20% van een platform gebruikt en voor 100% betaalt, verbeteren de economische voordelen van maatwerk software aanzienlijk over een horizon van drie tot vijf jaar.
Je hebt een integratieprobleem. Veel organisaties draaien op een combinatie van systemen die niet met elkaar communiceren. Maatwerk software, of een aangepaste API-laag, kan die systemen verbinden en het handmatige werk van het verplaatsen van gegevens ertussen elimineren.
Je bent je huidige systeem ontgroeid. Systemen die zijn gebouwd voor een kleinere versie van jouw bedrijf worden uiteindelijk beperkingen. Maatwerk software kan worden ontworpen om mee te groeien met jouw groei in plaats van elke paar jaar een migratie te forceren.

Wanneer kant-en-klare software de betere keuze is

Maatwerk software is niet altijd het juiste antwoord. Als jouw behoeften goed worden bediend door een bestaand product, is kopen sneller en goedkoper dan bouwen. We zullen je dat rechtstreeks vertellen als dat van toepassing is op jouw situatie. We hebben het eerder gedaan.

Het duidelijkste signaal dat kant-en-klare software de juiste keuze is, is wanneer jouw proces overeenkomt met wat het product doet. Als je boekhoudsoftware nodig hebt, koop dan boekhoudsoftware. De markt voor algemene bedrijfstools is volwassen en concurrerend.

Hoe je over de kosten moet nadenken

De initiële kosten van maatwerk software zijn reëel. Dat geldt ook voor de doorlopende kosten van een systeem dat niet past, van handmatige oplossingen, van gegevens die op drie verschillende plaatsen staan en van een concurrerend proces dat iedereen kan repliceren door hetzelfde product te kopen dat jij gebruikt.

De juiste vergelijking is niet maatwerk software versus de licentiekosten van een kant-en-klaar product. Het is maatwerk software versus de totale kosten van het alternatief, inclusief implementatie, aanpassing, integratiewerk, training en de kosten van de beperkingen die je accepteert.

Wat je van Volare Software kunt verwachten

We werken op trajecten van 3 tot 12 maanden met teams van één tot vijf ontwikkelaars. We geven je een schatting als bandbreedte na een kennismakingsgesprek en we committeren ons aan de maandelijkse teamkosten. Je kunt het team op- of afschalen en je kunt het traject pauzeren als jouw prioriteiten veranderen.

Neem contact met ons op voor een vrijblijvend kennismakingsgesprek, of lees meer over onze softwareontwikkeling op maat.

Voordelen van het inhuren van een bedrijfsgericht softwareadviesbureau op maat

Sun, 28 Apr 2024 19:49:26 Z

Wat maakt een consultancybureau voor maatwerk software effectief?

Technische vaardigheid is belangrijk bij de ontwikkeling van maatwerk software, maar het is niet genoeg op zichzelf. De bureaus die de meeste waarde leveren, zijn de bureaus die jouw bedrijf net zo goed begrijpen als de codebase. Dit artikel beschrijft waarom bedrijfsinzicht de belangrijkste factor is bij het kiezen van een partner voor softwareontwikkeling op maat.

Software die past bij jouw bedrijf, niet andersom

Standaard software is gebouwd voor de algemene markt. Maatwerk software is gebouwd voor jouw specifieke processen, concurrentievoordelen en integratiebehoeften. Maar zelfs maatwerk software kan tekortschieten als het team dat het bouwt niet de tijd neemt om te begrijpen hoe jouw bedrijf daadwerkelijk werkt.

Een businessgericht consultancybureau begint met de vraag waarom voordat het vraagt hoe. Welk probleem los je op? Hoe ziet succes eruit zes maanden na de lancering? Wie zijn de mensen die dit systeem dagelijks gebruiken? De antwoorden op die vragen bepalen elke architectuurbeslissing, elke functieprioriteit en elke afweging die tijdens het project wordt gemaakt.

Domeinervaring vermindert risico

Een consultancybureau dat ervaring heeft in jouw branche of met vergelijkbare vraagstukken, brengt patroonherkenning mee die een puur technisch team niet heeft. Ze weten welke integraties lastig zijn, welke compliancevereisten invloed hebben op het datamodel en welke functies eenvoudig lijken maar dat niet zijn. Die ervaring verkort de ontdekkingsfase, vermindert het aantal kostbare late wijzigingen en levert software op die werkt zoals jouw bedrijf werkt.

Zakelijke afstemming gedurende het hele project, niet alleen bij de start

Vereisten veranderen bij elk project. Een businessgericht consultancybureau behandelt dat niet als een probleem dat via contracttaal beheerd moet worden. Ze behandelen het als normaal en bouwen daar een proces omheen. Bij Volare Software gebruiken we agile ontwikkeling met korte iteraties, zodat nieuwe informatie en veranderende prioriteiten kunnen worden verwerkt zonder de planning of het budget te verstoren.

Lange termijn denken boven kortetermijnoplevering

Een consultancybureau dat jouw bedrijf begrijpt, denkt na over wat er gebeurt nadat het project is afgerond. Is de software onderhoudbaar? Kan jouw interne team het overnemen? Is de architectuur flexibel genoeg om mee te groeien met jouw bedrijf? Dit zijn geen bijzaken. Het zijn ontwerpbeslissingen die op dag één worden genomen.

Neem contact met ons op om jouw project te bespreken met een consultancybureau dat sinds 2009 business-gedreven enterprise software bouwt.

Hoe we agile software ontwikkelen

Sat, 12 Aug 2023 11:43:25 Z

Hoe wij agile software ontwikkelen

We volgen een agile softwareontwikkelingsproces dat in meer dan 17 jaar van het opleveren van enterprise-projecten is verfijnd. Dit artikel beschrijft hoe wij werken, van initiële planning tot productie-deployment.

Stories en bugfixes

Het bedrijf, meestal via één productmanager, is primair verantwoordelijk voor het schrijven van nieuwe stories. De inhoud moet voldoende zijn voor de auteur om later te herinneren waar het over ging wanneer om details wordt gevraagd. Zodra een story in de werkcyclus aan de beurt komt, werkt het team met de relevante stakeholders om vragen te stellen, concrete voorbeelden uit te werken en indien nodig een ontwerp te maken. Deze gesprekken verduidelijken de reden voor de functie en vormen een sterke motivatie voor het team.

Prioritering

De productmanager beheert de backlog en stelt prioriteiten. Het team levert schattingen van de inspanning om die beslissingen te ondersteunen, maar de productmanager bepaalt wat er als volgende wordt gebouwd. Dit houdt het team gefocust op bedrijfswaarde in plaats van technische voorkeur.

Iteraties

We werken in sprints van twee weken. Aan het begin van elke sprint bekijkt het team de bovenste items in de backlog, bevestigt de scope en committeert zich aan een set stories voor die iteratie. Aan het einde van elke sprint demonstreren we werkende software aan stakeholders. Er zijn geen verrassingen aan het einde van een lang project, omdat stakeholders elke twee weken voortgang zien.

Werk bijhouden

We gebruiken een Kanban-stijl bord om stories door hun fases te volgen: gereed, in uitvoering, in review, klaar. Stories worden pas als klaar gemarkeerd nadat ze codereview en geautomatiseerd testen hebben doorstaan. Dit houdt de definitie van klaar consistent en voorkomt dat halfafgemaakt werk zich opstapelt.

Codereview

Elke wijziging gaat door peer codereview voordat deze wordt samengevoegd. Codereview gaat niet alleen over het opsporen van bugs, hoewel het dat ook doet. Het gaat om kennisdeling, het handhaven van consistentie in de codebase en het vroegtijdig opsporen van ontwerpproblemen voordat ze kostbaar zijn om op te lossen.

Geautomatiseerd testen

We schrijven geautomatiseerde tests voor bedrijfslogica en integratiepunten. Het doel is niet 100% dekking om de dekking zelf. Het doel is een testset die het team het vertrouwen geeft om snel wijzigingen aan te brengen zonder bestaand gedrag te breken.

Deployment

We gebruiken CI-CD-pipelines zodat elke samenvoeging naar de hoofdbranch een geautomatiseerde build en deployment naar de ontwikkelomgeving activeert. Releases naar productie zijn een bewuste beslissing, geen handmatig proces. Dit vermindert het deploymentrisico en houdt omgevingen consistent.

Wat dit voor jou betekent

Je ziet aan het einde van elke sprint van twee weken werkende software. Je kunt prioriteiten wijzigen tussen sprints. Je weet precies wat er is opgeleverd en wat het heeft gekost. Er zijn geen lange periodes van stilte gevolgd door een grote onthulling.

Neem contact met ons op voor meer informatie over hoe wij werken, of bekijk onze agile DevOps automatiseringen service voor hoe we deze werkwijzen toepassen op DevOps en pipeline-werk.

Tien rampen om te vermijden in uw volgende contract voor softwareontwikkeling op maat

Sun, 02 Apr 2023 20:39:06 Z

Wat het contract goed moet regelen

Een contract voor softwareontwikkeling op maat is niet zomaar papierwerk. Het bepaalt wie wat bezit, wie waarvoor verantwoordelijk is en wat er gebeurt als het misgaat. We hebben genoeg projecten meegemaakt om te weten dat een slecht opgesteld contract problemen veroorzaakt die geen enkele goede wil kan oplossen. Hier zijn tien dingen die je voor ondertekening goed moet regelen.

1. Geen opzeggingsclausule

Als de leverancier niet levert, kun je dan het contract beëindigen? Zonder een duidelijke opzeggingsclausule heb je daar mogelijk geen juridische grond voor. Zorg dat je contract je de mogelijkheid geeft om de samenwerking te beëindigen als je niet tevreden bent, en wees specifiek over welke omstandigheden dat recht activeren.

2. Onduidelijke scope en geen gedefinieerd proces

Scopedocumenten zijn op zichzelf niet voldoende. De leverancier zal jouw vereisten anders interpreteren dan jij bedoelde, en zonder een gedefinieerd ontwikkelingsproces is er geen mechanisme om dat vroeg te ontdekken. Je contract moet specificeren hoe werk wordt opgesplitst in iteraties, hoe je de voortgang beoordeelt en hoe wijzigingen worden verwerkt. Een proces dat je elke twee weken werkende software laat zien, biedt veel meer bescherming dan een gedetailleerd specificatiedocument.

3. Vage betalingsvoorwaarden

Duidelijke betalingsvoorwaarden beschermen beide partijen. Vage voorwaarden leiden tot geschillen over wanneer betaling verschuldigd is, wat een voltooide mijlpaal inhoudt en wat er gebeurt als een van beide partijen te laat is. Leg dit voor de start van het project concreet vast.

4. Geen intellectuele-eigendomsclausule

Wie is eigenaar van de code? In de meeste Nederlandse en Europese contracten is de opdrachtgever eigenaar van alles wat in het kader van een werk-voor-huur-overeenkomst wordt geproduceerd. Ga daar niet van uit. Leg het schriftelijk vast. Specificeer ook dat de leverancier jouw code niet opnieuw mag gebruiken voor andere klanten.

5. Geen aansprakelijkheidsclausule

Als de leverancier gebrekkige code levert die schade veroorzaakt aan jouw bedrijf of klanten, is hij dan aansprakelijk? Leveranciers willen hun aansprakelijkheid beperken, vaak tot de waarde van het contract. Zorg dat een eventueel aansprakelijkheidsplafond hoog genoeg is om jouw daadwerkelijke risicoBlootstelling te dekken.

6. Geen geheimhoudingsovereenkomst

Je leverancier heeft toegang tot jouw processen, jouw gegevens en soms de informatie van jouw klanten. Een geheimhoudingsovereenkomst moet doorlopen na het einde van het project, doorgaans ten minste een jaar, en moet alle teamleden aan de kant van de leverancier omvatten.

7. Geen geschillenbeslechtingsmechanisme

Als er een geschil ontstaat, is naar de rechter stappen langzaam en duur. Leg in het contract vast hoe geschillen worden opgelost, of via bindende arbitrage, mediation of een ander mechanisme. Dit is veel eenvoudiger overeen te komen voor een geschil dan erna.

8. Geen non-solicitatieclausule

Wat gebeurt er als de leverancier jouw medewerkers wegkaapt, of jij die van hen? Een non-solicitatieclausule legt de regels voor beide partijen vast en vermindert het risico op ongemakkelijke situaties tijdens of na het project.

9. Geen belangenconflictclausule

Werkt de leverancier aan hetzelfde vraagstuk voor een van jouw concurrenten? Een belangenconflictclausule verplicht hen dit te melden en geeft je verhaal als het zonder melding gebeurt.

10. Geen ondersteuningsovereenkomst

Het project is klaar en de software draait in productie. Er duikt een bug op. Wie lost dat op? Leg de verantwoordelijkheden van de leverancier na de livegang vast voor je tekent, niet erna. Bepaal of je een doorlopende ondersteuningsovereenkomst wilt, een garantieperiode of een overdracht aan je interne team, en leg dat vast.

Neem contact met ons op voor meer informatie over hoe we onze softwareontwikkeling op maat trajecten structureren.

Moet je met een offshore team in zee gaan voor je softwareontwikkelingsproject op maat?

Sun, 02 Apr 2023 18:25:24 Z

Offshore, nearshore of lokaal: wat telt er echt voor jouw project

Kosten zijn meestal de eerste reden waarom bedrijven een offshore ontwikkelteam overwegen. Tarieven in India, Oost-Europa of Zuidoost-Azië zien er op papier aantrekkelijk uit vergeleken met Nederlandse of West-Europese tarieven. Maar de totale kosten van een softwareproject zijn niet alleen het uurtarief. Ze omvatten ook de kosten van miscommunicatie, herwerk, management-overhead en vertraagde oplevering. Dit artikel beschrijft wat je moet afwegen bij deze beslissing.

De werkelijke kosten van offshore ontwikkeling

Offshore teams rekenen doorgaans minder per uur. Dat voordeel neemt af als je de volgende factoren meeneemt:

Tijdzoneverschillen. Een verschil van 5 tot 8 uur tussen een Nederlandse klant en een offshore team betekent dat een vraag die je aan het einde van jouw dag stelt, pas aan het begin van de volgende dag wordt beantwoord. Op een complex project telt die dagelijkse vertraging bij elke uitwisseling snel op.

Communicatie-overhead. Specificaties helder genoeg opschrijven voor een team met een andere culturele en taalkundige context dan die van jou, kost meer tijd en zorgvuldigheid dan de meeste klanten verwachten. Misverstanden die in een gesprek van vijf minuten opgelost zouden worden, kunnen uitlopen op omwegen van een week.

Managementvereisten. Offshore trajecten vereisen doorgaans meer actief projectmanagement aan de kant van de klant. Als je geen toegewijde interne persoon hebt om de relatie te beheren, kunnen de besparingen verdwijnen in de tijd van je eigen team.

Wanneer offshore werkt

Offshore ontwikkeling werkt goed wanneer het werk duidelijk gedefinieerd, herhaalbaar is en weinig heen-en-weer communicatie vereist. Onderhoudstaken, goed gespecificeerde functie-toevoegingen en QA-werk zijn voorbeelden waarbij het tijdzoneverschil en de communicatie-overhead beheersbaar zijn.

Het werkt minder goed voor projecten die ontdekking, evoluerende vereisten of nauwe samenwerking met zakelijke stakeholders vereisen. Die projecten profiteren van een team dat snel kan reageren en zonder wrijving kan communiceren.

Het nearshore alternatief

Een nearshore team werkt in een vergelijkbare of overlappende tijdzone, deelt een vergelijkbare bedrijfscultuur en communiceert zonder taalbarrière. Voor Nederlandse en Europese klanten betekent dat Nederland en omliggende landen.

Volare Software is gevestigd in Hilversum en bedient al sinds 2009 enterprise klanten in Nederland, Europa en de Verenigde Staten. Ons team werkt in CET, wat volledige overlap geeft met de werkdag in West-Europa. We werken in het Nederlands en Engels en passen hetzelfde agile proces toe op elk project, zodat je aan het einde van elke sprint van twee weken werkende software ziet.

We zijn niet de goedkoopste optie. We zijn de optie die het risico vermindert dat het project mislukt of twee keer zo lang duurt als gepland.

Neem contact met ons op om jouw project te bespreken en te kijken of onze aanpak de juiste keuze is, of lees meer over onze softwareontwikkeling op maat.

Het belang van luisteren naar gebruikers tijdens het ontwerpproces

Sun, 02 Apr 2023 18:46:50 Z

Waarom gebruikersfeedback betere software oplevert

Als we diep in een project zitten, is het makkelijk om vertrouwen te krijgen in onze eigen aannames over wat gebruikers nodig hebben. De producteigenaar heeft een duidelijke visie. De ontwikkelaars begrijpen de technische beperkingen. Maar geen van die perspectieven is hetzelfde als zitten met de mensen die de software dagelijks zullen gebruiken. Gebruikersfeedback tijdens het ontwerpproces is geen luxe. Het is een van de betrouwbaarste manieren om te voorkomen dat je het verkeerde bouwt.

Gebruikers weten dingen die jij niet weet

De mensen die het werk doen dat jouw software ondersteunt, hebben context die niemand in het ontwikkelteam heeft. Ze weten welke delen van het huidige proces pijnlijk zijn, welke oplossingen ze zelf hebben bedacht en welke uitzonderlijke situaties elke week terugkomen. Die kennis verschijnt niet in een eisendocument tenzij iemand ernaar vraagt.

Bij Volare Software behandelen we vroege gesprekken met gebruikers als onderdeel van het ontwerpproces, niet als een goedkeuringsstap aan het einde. Een gebruiker laten werken met een prototype of een vroege werkende iteratie en observeren wat hij doet, vertelt ons in een uur meer dan weken van specificaties schrijven.

Feedback helpt je scope te verkleinen, niet alleen toe te voegen

Een van de nuttigste dingen die gebruikersfeedback doet, is je vertellen wat je moet weglaten. De meeste softwareprojecten beginnen met meer functies dan ze nodig hebben. Gebruikers vertellen ons consistent welke delen van het voorgestelde ontwerp ze daadwerkelijk zouden gebruiken en welke delen goed klinken in een vergadering maar niet weerspiegelen hoe ze werken. Die informatie maakt de software kleiner, sneller te bouwen en gemakkelijker te gebruiken.

Niet alle feedback is bruikbaar, maar alles is nuttig

Sommige gebruikersfeedback is duidelijk en direct. Sommige is tegenstrijdig. Sommige weerspiegelt wat een gebruiker vandaag wil in plaats van wat hij over zes maanden nodig heeft. Een deel van onze taak is feedback in context te interpreteren, af te wegen tegen de productdoelen en aanbevelingen terug te brengen naar de producteigenaar.

We behandelen gebruikersfeedback niet als een stemsysteem waarbij het populairste verzoek wint. We behandelen het als gegevens die ontwerpbeslissingen ondersteunen, genomen door mensen die zowel de behoeften van de gebruiker als de technische beperkingen begrijpen.

Wanneer gebruikers te betrekken

Hoe eerder hoe beter. Feedback op een schets of een eenvoudig prototype is goedkoop om op te handelen. Feedback op een afgewerkte functie is duur. We proberen een vorm van gebruikersinput te krijgen voordat grote ontwerpbeslissingen worden vastgelegd, en opnieuw nadat de eerste werkende iteratie beschikbaar is.

Neem contact met ons op voor meer informatie over onze aanpak van web app ontwikkeling en gebruikersgerichte vormgeving.

Vijf stappen om ervoor te zorgen dat uw webapplicatie veilig is.

Tue, 18 Apr 2023 14:27:52 Z

Beveiliging bouw je in, je plakt het er niet achteraf op

Beveiliging van web apps is geen eindchecklist voor de lancering. Tegen de tijd dat je pre-launch tests uitvoert, zijn de beslissingen die bepalen hoe veilig je applicatie is al genomen. De architectuur, het datamodel, de gekozen externe services, de manier waarop authenticatie werkt - dat alles lag maanden eerder vast. Dit artikel beschrijft vijf praktijken die we gedurende het hele ontwikkelproces toepassen om web apps veilig te houden.

1. Versleutel al het verkeer

Elk verzoek tussen jouw gebruikers en jouw applicatie moet via HTTPS verlopen. Dit versleutelt gegevens onderweg en voorkomt dat ze kunnen worden gelezen als ze worden onderschept. SSL/TLS-certificaten zijn gratis beschikbaar via de meeste hostingproviders en cloudplatforms. Er is geen goede reden om productieverkeer via HTTP te laten lopen.

2. Versleutel gevoelige gegevens in opslag, en sla ze niet op als dat niet nodig is

Als je applicatie wachtwoorden opslaat, moeten ze worden gehasht met een modern algoritme zoals bcrypt of Argon2, nooit opgeslagen als leesbare tekst of met omkeerbare encryptie. Voor andere gevoelige gegevens zoals betalingsinformatie of identiteitsdocumenten, is de eerste vraag of je ze überhaupt hoeft op te slaan. Gegevens die je niet bewaart, kunnen niet worden gestolen. Als je ze wel moet opslaan, versleutel ze dan op veld- of rijniveau, niet alleen op schijfniveau.

3. Voer beveiligingsscans uit

Geautomatiseerde beveiligingsscanners testen je draaiende applicatie op veelvoorkomende kwetsbaarheden, waaronder injectie-aanvallen, gebrekkige authenticatie en blootgestelde gevoelige gegevens. Het regelmatig uitvoeren hiervan, en zeker voor elke grote release, ontdekt problemen die codereview alleen mist. Veel scanners zijn beschikbaar als onderdeel van een CI-CD-pipeline, zodat de scan automatisch bij elke build plaatsvindt.

4. Voer statische codeanalyse uit

Statische analysetools onderzoeken je broncode zonder deze uit te voeren. Ze identificeren patronen die verband houden met bekende kwetsbaarheidsklassen: SQL-injectie, cross-site scripting, onveilige deserialisatie en andere. Het integreren van een statisch analysetools in je ontwikkelworkflow betekent dat deze controles bij elke commit plaatsvinden in plaats van als eenmalige oefening.

5. Controleer je beveiligingsheaders

HTTP-beveiligingsheaders vertellen browsers hoe ze zich moeten gedragen bij het laden van jouw applicatie. De Content-Security-Policy header beperkt welke resources de browser laadt, wat het aanvalsoppervlak voor cross-site scripting verkleint. De Strict-Transport-Security header dwingt HTTPS af. X-Frame-Options voorkomt dat je pagina's worden ingebed in iframes op andere domeinen. Deze zijn eenvoudig te configureren en maken een meetbaar verschil in de beveiligingspositie van je applicatie.

Beveiliging is een van de gebieden waar de kosten van het oplossen van problemen aanzienlijk toenemen naarmate de tijd verstrijkt. Problemen die tijdens de ontwikkeling worden ontdekt, zijn goedkoop op te lossen. Problemen die in productie worden ontdekt, zijn dat niet.

Neem contact met ons op voor meer informatie over hoe we beveiliging inbouwen in ons web app ontwikkeling proces.

Mocking calls with Jasmine

Tue, 14 Apr 2020 06:00:00 Z

This post and the examples have been updated to the latest release of Jasmine, which is currently 3.5.

Jasmine is a simple, BDD-style JavaScript testing framework, but to benefit from the full power out of the framework, you need to know how to mock calls the Jasmine way.

Jasmine uses spies to mock asynchronous and synchronous function calls. As with most mocking frameworks, you can set the externally observed behavior of the code you are mocking.

Using Jasmine spies to mock code

Jasmine spies are easy to set up. You set the object and function you want to spy on, and that code won't be executed.

In the code below, we have a MyApp module with a flag property and a setFlag() function exposed. We also have an instance of that module called myApp in the test. To spy on the myApp.setFlag() function, we use:

spyOn(myApp, "setFlag");

It's a little strange that in Jasmine, you have to put the function you want to spy on in quotes, but that's the API.

When you spy on a function like this, the original code is not executed.

Returning values from Jasmine spies

Most of the time when setting up mocks, you want to set return values so you can test a specific code path. Again, this is easy to do with Jasmine.

Here, I show setting the return value of a function so we can test specific branches in the code and skip over the real getFlag() function, which is hard-coded to return false.

The key piece is intercepting the getFlag() function with the spy and setting the value the substituted function returns:

spyOn(myApp, "getFlag").and.returnValue(true);

Sometimes, setting a returnValue isn't enough. If you need to replace the function you are mocking, you can use:

spyOn(myApp, "useFlagForSomething").and.callFake(function() {
    return "I'm replacing the real function with this";
});

Using Jasmine spies to verify code was called

You can also call the original code with a spy. This may sound pointless (why set up a mock and then call the real code?) unless you think about interaction testing, where it's important to know that a function was or was not called.

The syntax to call the original code but still spy on the function is:

spyOn(myApp, "getFlag").and.callThrough();

The code below shows how you can verify a spied on function was called. We have a new function called reallyImportantProcess(). We have to test to make sure it's being run under the right conditions, and we know it should run when getFlag() returns false, which is the default value. So we don't need to mock or change getFalse() to take this code branch, but we do need to spyOn reallyImportantProcess() to verify it gets called.

In this spy, we have lots of options. We could skip calling the real code, as we do below, or we could set up specific return values or substitute our own function for that function, or we could call the original code with callThrough(). When you set up Jasmine spies, you can use any spy configuration and still see if it was called later with and toHaveBeenCalled().

You can also test that a spied on function was NOT called with:

expect(myApp.reallyImportantProcess).not.toHaveBeenCalled();

Or you can go further with your interaction testing to assert on the spied on function being called with specific arguments like:

expect(myApp.reallyImportantProcess).toHaveBeenCalledWith(123, "abc");

Testing async calls in Jasmine with jQuery's Deferred and helpers

Async calls are a big part of JavaScript. Most code dealing with async calls these day works through promises or callbacks.

Here, some test helper code can be used to mock promises being returned from an async call. I'm using jQuery's $.Deferred() object, but any promise framework should work the same.

You can mock an async success or failure, pass in anything you want the mocked async call to return, and test how your code handles it:

var JasmineHelpers = function () {
var deferredSuccess = function (args) {
    var d = $.Deferred();
    d.resolve(args);
    return d.promise();
};

var deferredFailure = function (args) {
    var d = $.Deferred();
    d.reject(args);
    return d.promise();
};

return {
    deferredSuccess: deferredSuccess,
    deferredFailure: deferredFailure
};

};

Here is some Jasmine spy code using these async helpers. Again, we use jQuery $.Deferred() object to set up a function that calls out to a pretend async call named testAsync(). It's invoked by callSomethingThatUsesAsync(), which is the function we're testing. We want to mock the testAsync() call (maybe it goes off to the database and takes a while), and we want to assert that when that testAsync() call succeeds, callSomethingThatUsesAsync() goes on to give us a text message saying it succeeded.

Since the function under test is using a promise, we need to wait until the promise has completed before we can start asserting, but we want to assert whether it fails or succeeds, so we'll put our assert code in the always() function. The done(), fail(), and always() functions are promise code - (actually, jQuery $.Deferred code if you want to be technical) they are not specific to Jasmine.

Testing async calls in Jasmine with Jasmine's done() callback

Testing synchronous specs is easy, but asynchronous testing requires some additional work.

For example, the code below fails because Jasmine evaluates the expect() piece before the testAsync() function has finished its work. The setTimeout() call forces a two second delay, but Jasmine has already moved on and failed the test before the setTimeout() completes:

With Jasmine async testing, we have to call the async code in the beforeEach() function that runs before each it() function block within a describe() function block.

We also have to let Jasmine know when the async function has completed by calling the special done() callback function Jasmine provides. Here, we are passing this special done() callback around so our code under test can invoke it.

This works, but changing the code under test to accept the done() callback argument and invoke it may not be realistic. Why would you change your code under test just to make the testing framework happy?

Instead, you can use promises and call the special Jasmine done() callback when your promise has resolved. Note that the Jasmine done() callback is NOT the same as the promise's done() callback. They just use the same function name.

Here, I'm using jQuery's $.Deferred() object for the promises, but this approach should work with any promises library.

You can even use the data returned from the promise in the test once it is resolved. Here we are passing the return value in the deferred.resolve() call:

But of course, real-world applications can't get away with simply testing with setTimeout and true/false flags, so here is a more real-world example.

It calls $.getJSON() to go fetch some public JSON data in the beforeEach() function, and then tests the returned JSON in the it() block to make sure it isn't an empty object or undefined.

Testing async calls in Jasmine with async/await

With version 2.8 and later of Jasmine and your compiler that supports async/await (e.g., Babel, TypeScript), you can change this to be more readable:

Much cleaner!

Autocomplete dropdown with jQuery UI and MVC

Sat, 05 Feb 2011 01:40:23 Z

You know the autocomplete dropdown. It has become ubiquitous, and customers now expect them in their web apps. "Can't you just set autocomplete=true or something?" It's not quite that easy with ASP.NET MVC, but it's pretty simple.

We want to set up a text box on a web page that uses jQuery to call back to a controller action as the user types. The action method will return a JSON array of values that match what the user has typed so far. Each time they type and pause for a second, the screen should show the new matching records.

The view

First, we'll work on the view. Set a reference to jQuery and to jQuery UI. These are included with new MVC 3 projects (look in the Scripts folder), or you can find a CDN and reference them there. I've got this in my view's head section:

<head>
    <title>Autocomplete Test </title>
    <script src="<%: Url.Content("~/Scripts/jquery-1.4.4.min.js")%>" type="text/javascript"></script>
    <script src="<%: Url.Content("~/Scripts/jquery-ui.min.js")%>" type="text/javascript"></script>
</head>

Then you need a text box to tie all this too. The search results will be shown under this text box to give the appearance of a dropdown. This simple form should do:

<form action="/Search/ProcessTheForm" method="post">
    <input id="searchTerm" name="searchTerm" type="text" />
    <input type="submit" value="Go" />
</form>

Next, you'll need to use the autocomplete function in jQuery UI like this:

<script type="text/javascript">
    $(function () {
        $("#searchTerm").autocomplete({
            source: "/Search/AutocompleteSuggestions",
            minLength: 3,
            select: function (event, ui) {
                if (ui.item) {
                    $("#searchTerm").val(ui.item.value);
                    $("form").submit();
                }
            }
        });
    });
</script>

Here we've got a jQuery selector binding the autocomplete function to the searchTerm input box("#searchTerm"). We then set the URL for the source for the autocomplete suggestions, which in this case, will be our controller (Search) and action method (AutocompleteSuggestions). Then we set the number of characters the user has to type before we make the first call. It's set to three here to prevent pulling back meaningless matches from searching too soon.

Finally, we set up the autocomplete function's select event to set the selected value from the dropdown list as the value in the searchTerm input box and submit the form to the Search controller and the ProcessTheForm action method.

Here's the entire view for reference:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<dynamic>" %>
<!DOCTYPE html>
<html>
<head>
<title>Autocomplete Test</title>
<script src="<%: Url.Content("_{/Scripts/jquery-1.4.4.min.js")%>" type="text/javascript"></script>
<script src="<%: Url.Content("}/Scripts/jquery-ui.min.js")%>" type="text/javascript"></script>
</head>
<body>
<form action="/Search/ProcessTheForm" method="post">
<input id="searchTerm" name="searchTerm" type="text" />
<input type="submit" value="Go" />
</form>
<script type="text/javascript">
$(function () {
$("#searchTerm").autocomplete({
source: "/Search/AutocompleteSuggestions",
minLength: 3,
select: function (event, ui) {
if (ui.item) {
$("#searchTerm").val(ui.item.value);
$("form").submit();
}
}
});
});
</script>
</body>
</html>

The controller

Now you need to write something that will return the records that match what the user has entered so far. This might be a database call with a LIKE searchTerm + "%" (watch out for SQL injection, though) or SOUNDEX or a web service call. Be sure you limit your returned search results to maybe the top 10 matches so you don't bog things down with too much data moving over the wire.

Next, set up a controller action to invoke this back-end call and JSON up the returned list. We've already names the controller (Search) and action (AutocompleteSuggestions) in our view. Something like this should work, where _searchRepository is my repository call that finds matching strings, which are then converted to JSON:

public JsonResult AutocompleteSuggestions(string term)
{
    var suggestions = _searchRepository.GetAutoCompleteSearchSuggestion(term);
    return Json(suggestions, JsonRequestBehavior.AllowGet);
}

Don't forget the JsonRequestBehavior.AllowGet parameter in the Json call. You won't get anything back from the action method if you leave it off.

Also, the name of the parameter passed into the action method is important. The jQuery UI autocomplete method will call your source URL with a query string like "?term=foo". If you set the parameter name to a string named "term", the MVC model binder will grab the value from the query string for you.

The jQuery UI Autocomplete function has several other options and events you can use in your app, and the demos are worth checking out too.

Building a Windows 8 Live Tile with JavaScript

Tue, 16 Oct 2012 00:39:54 Z

If you've seen Windows 8 yet, you know it's got a tile-based start menu. One of the cool things (or annoying things) you can do is post values on your app's tile. This is called a "live tile" in Windows 8 world. Your app users can turn them on or off with a right click on the tile.

Here's how I built one with JavaScript.

Figure out what you want to display on your live tiles

This is what my tile looks like before it's "live" as both a smaller (square) and a larger (wide) tile:

The live tile concept is that you pick a style template, build up some XML, then push that XML to the tile through the notification API. These guidelines show you the different tile templates you can pick. Find a square tile and a wide tile you like, and pay attention to the name of that template, since you'll use that soon.

In this case, I decided I like TileSquareText01:

<tile>
  <visual>
    <binding template="TileSquareText01">
      <text id="1">Text Field 1</text>
      <text id="2">Text Field 2</text>
      <text id="3">Text Field 3</text>
      <text id="4">Text Field 4</text>
    </binding>  
  </visual>
</tile>

and TileWideText01:

<tile>
  <visual>
    <binding template="TileWideText01">
      <text id="1">Text Header Field 1</text>
      <text id="2">Text Field 2</text>
      <text id="3">Text Field 3</text>
      <text id="4">Text Field 4</text>
      <text id="5">Text Field 5</text>
    </binding>  
  </visual>
</tile>

The plan is to show the users current altitude as a number on the top, larger font line, then show the units (feet or meters) under that in the smaller font.

There are several rules about what you can and can't show on your tiles, so check the guidelines carefully to be sure your idea will not get rejected by the Windows Store during the certification process.

Tests for the correct live tile XML

Since the live tile notification is all about sending the right XML, let's start with a test of the XML we want at the end. Here I'm using QUnit to check the XML.

test("tile", function () {
    var altitude = 6071,
        altitudeUnits = "feet",
        result,
        expected;
result = tile.buildSquareTileXml(altitude, altitudeUnits);
expected = '&lt;tile&gt;' +
    '&lt;visual&gt;' +
    '&lt;binding template=&quot;TileSquareText01&quot; branding=&quot;name&quot;&gt;' +
    '&lt;text id=&quot;1&quot;&gt;6071&lt;/text&gt;' +
    '&lt;text id=&quot;2&quot;&gt;feet&lt;/text&gt;' +
    '&lt;text id=&quot;3&quot;&gt;&lt;/text&gt;' +
    '&lt;text id=&quot;4&quot;&gt;&lt;/text&gt;' +
    '&lt;/binding&gt;' +
    '&lt;/visual&gt;' +
    '&lt;/tile&gt;';
equal(result.getXml().toString(), expected, &quot;should get correct xml for square tile&quot;);

result = tile.buildWideTileXml(altitude, altitudeUnits);
expected = '&lt;tile&gt;' +
    '&lt;visual&gt;' +
    '&lt;binding template=&quot;TileWideText01&quot; branding=&quot;name&quot;&gt;' +
    '&lt;text id=&quot;1&quot;&gt;6071&lt;/text&gt;' +
    '&lt;text id=&quot;2&quot;&gt;feet&lt;/text&gt;' +
    '&lt;text id=&quot;3&quot;&gt;&lt;/text&gt;' +
    '&lt;text id=&quot;4&quot;&gt;&lt;/text&gt;' +
    '&lt;text id=&quot;5&quot;&gt;&lt;/text&gt;' +
    '&lt;/binding&gt;' +
    '&lt;/visual&gt;' +
    '&lt;/tile&gt;';
equal(result.getXml().toString(), expected, &quot;should get correct xml for wide tile&quot;);

});

These tests fail since we haven't written the functions yet, but we'll do that next. Ignore the "branding" attribute for now. We'll come back to that.

Build up the live tile XML

Here's the code to get the correct XML and get those tests passing. See those calls the Windows.UI.Notifications.TileTemplateType? That's where you plug in the name of the square and wide template you picked from the catalog.

I'm building up an array of values for the different lines of text. Use any XML or string manipulation technique you like. I got this one from the Windows 8 SDK samples.

function buildSquareTileXml(altitude, altitudeUnits) {
    var squareTemplate = Windows.UI.Notifications.TileTemplateType.tileSquareText01,
            squareTileLines = [
                altitude,
                altitudeUnits
            ],
            squareTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(squareTemplate),
            squareTileTextAttributes = squareTileXml.getElementsByTagName("text");
for (var i = 0; i &lt; squareTileLines.length; i++) {
    squareTileTextAttributes[i].appendChild(squareTileXml.createTextNode(squareTileLines[i]));
}

var squareTileBinding = squareTileXml.getElementsByTagName(&quot;binding&quot;);
if (squareTileBinding[0]) {
    squareTileBinding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
}

return squareTileXml;

}
function buildWideTileXml(altitude, altitudeUnits) {
var wideTemplate = Windows.UI.Notifications.TileTemplateType.tileWideText01,
wideTileLines = [
altitude,
altitudeUnits
],
wideTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(wideTemplate),
wideTileTextAttributes = wideTileXml.getElementsByTagName("text");
for (var i = 0; i &lt; wideTileLines.length; i++) {
    wideTileTextAttributes[i].appendChild(wideTileXml.createTextNode(wideTileLines[i]));
}

var binding = wideTileXml.getElementsByTagName(&quot;binding&quot;);
if (binding[0]) {
    binding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
}

return wideTileXml;

}

Combine the square and wide XML

Since users of your tile can toggle the smaller (square) or larger (wide) version of your tile, you want to combine the square and wide XML and send down both. Here's how to do that. Again, this is just XML manipulation, use any technique you like.

function combineTileXml(wideTileXml, squareTileXml) {
    var node = wideTileXml.importNode(squareTileXml.getElementsByTagName("binding").item(0), true);
    wideTileXml.getElementsByTagName("visual").item(0).appendChild(node);
return wideTileXml;

}

Pass the combined live tile XML to the Windows 8 API

Now that you've got the final XML you want, create a Tile Notification object and pass it to the Tile Update Manager:

function sendTileUpdate(altitude, altitudeUnits) {
    var wideTileXml,
        squareTileXml,
        combinedTileXml,
        tileNotification;
if (altitude &amp;amp;&amp;amp; altitudeUnits) {
    wideTileXml = buildWideTileXml(altitude, altitudeUnits);
    squareTileXml = buildSquareTileXml(altitude, altitudeUnits);
    combinedTileXml = combineTileXml(wideTileXml, squareTileXml);

    tileNotification = new Windows.UI.Notifications.TileNotification(combinedTileXml);
    Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().update(tileNotification);
}

}

The last two lines are doing the real work here, by using the Windows 8 notifications API. The rest is calling the other helper functions.

Calling the notification code

So who notifies the notifier code that we've got some new stuff to show on the line tile? You do! Figure out when something interesting happens in your app, and send a notification to the live tile then. In this case, that looks like:

tile.sendTileUpdate(altitude, altitudeUnits);

Putting it all together

Here's the result for the square and wide tiles:

Here's the combined JavaScript. I put it all in a file named it tile.js and used the WinJS namespacing function. This is pretty much the same as the revealing module pattern, and it means I can call tile.<whatever> from the tests and other JavaScript files.

(function () {
    "use strict";
function sendTileUpdate(altitude, altitudeUnits) {
    var wideTileXml,
        squareTileXml,
        combinedTileXml,
        tileNotification;

    if (altitude &amp;amp;&amp;amp; altitudeUnits) {
        wideTileXml = buildWideTileXml(altitude, altitudeUnits);
        squareTileXml = buildSquareTileXml(altitude, altitudeUnits);
        combinedTileXml = combineTileXml(wideTileXml, squareTileXml);

        tileNotification = new Windows.UI.Notifications.TileNotification(combinedTileXml);
        Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().update(tileNotification);
    }
}

function buildSquareTileXml(altitude, altitudeUnits) {
    var squareTemplate = Windows.UI.Notifications.TileTemplateType.tileSquareText01,
            squareTileLines = [
                altitude,
                altitudeUnits
            ],
            squareTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(squareTemplate),
            squareTileTextAttributes = squareTileXml.getElementsByTagName(&quot;text&quot;);

    for (var i = 0; i &lt; squareTileLines.length; i++) {
        squareTileTextAttributes[i].appendChild(squareTileXml.createTextNode(squareTileLines[i]));
    }

    var squareTileBinding = squareTileXml.getElementsByTagName(&quot;binding&quot;);
    if (squareTileBinding[0]) {
        squareTileBinding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
    }

    return squareTileXml;
}

function buildWideTileXml(altitude, altitudeUnits) {
    var wideTemplate = Windows.UI.Notifications.TileTemplateType.tileWideText01,
            wideTileLines = [
                altitude,
                altitudeUnits
            ],
            wideTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(wideTemplate),
            wideTileTextAttributes = wideTileXml.getElementsByTagName(&quot;text&quot;);

    for (var i = 0; i &lt; wideTileLines.length; i++) {
        wideTileTextAttributes[i].appendChild(wideTileXml.createTextNode(wideTileLines[i]));
    }

    var binding = wideTileXml.getElementsByTagName(&quot;binding&quot;);
    if (binding[0]) {
        binding[0].setAttribute(&quot;branding&quot;, &quot;name&quot;);
    }

    return wideTileXml;
}

function combineTileXml(wideTileXml, squareTileXml) {
    var node = wideTileXml.importNode(squareTileXml.getElementsByTagName(&quot;binding&quot;).item(0), true);
    wideTileXml.getElementsByTagName(&quot;visual&quot;).item(0).appendChild(node);

    return wideTileXml;
}

WinJS.Namespace.define(&quot;tile&quot;, {
    sendTileUpdate: sendTileUpdate,
    buildWideTileXml: buildWideTileXml,
    buildSquareTileXml: buildSquareTileXml
});

})();

Branding

In the bottom left corner of the tile, I am showing the name of the app, in this case "Altitude", on the live tile.

If you like, you can show your logo here instead. This comes from the 30x30 logo in your package.appxmanifest on the Application UI tab, under Tile > Small Logo.

Change these lines:

binding[0].setAttribute("branding", "name");

to:

binding[0].setAttribute("branding", "logo");

And you'll get this instead:

In fact, you can take out all the code around branding if you like the logo there, since that's the default behavior. If you want neither your app name nor your logo there, you can set the branding attribute to "none".

Hey, my Live Tile doesn't work!

I had this experience the first couple times I ran my code, too. The most common mistake I've seen is invalid XML, so be sure you add those test first to avoid that.

The other snag was using the Simulator in Visual Studio 2012 that simulates a tablet with touch and rotating. I don't know what the issue was, but my live tile didn't update when I ran it through the Simulator. Other live tiles could be turned on and off, but not the one for my app. When I ran on Local Machine instead, the live tile worked fine. So if you're not seeing your live tile work in the Simulator, switch to Local Machine and see if that fixes it for you.

Making your ASP.NET MVC app look decent on an iPhone or iPad

Mon, 24 Sep 2012 02:35:00 Z

I wanted to try out the new mobile features of ASP.NET MVC 4 to convert an existing site (this one!) to a half-decent looking iPhone/iPad app. It was really easy. Here are the steps and what I learned in the process.

Think about what your mobile user will want to do

This is the most important piece, and it's one you need to take seriously before you dive in. If you skip it, you'll just have a mess. You know that tablets and phones are smaller, so things that require lots of screen space won't work. But what is the main thing people open the site/app to do? Optimize for that and put it front and center. If there is more than one thing your site/app does, how will mobile user's navigate around? When converting an existing app to mobile, you'll probably want to cut out a lot of extraneous stuff. You could also phase in different chunks. It doesn't have to be all or nothing.

Choose your technical approach

Scott Hanselman has a nice blog post and chart showing effort compared to user experience across different approaches to making your app mobile.

He covers responsive design (CSS media queries and resizing), using a mobile framework (like jQuery Mobile), or going native (Objective-C). My only quibble with the Scott's chart is the green circle for native apps is too small. I think that's WAAAAY more effort.

For this post, I went with a mobile framework (jQuery Mobile). This is the most bang for your buck. You can learn it in less than an hour, and convert views and layouts in a half day to a day, depending on how complicated your views are.

Get jQuery Mobile

Add the jQuery Mobile NuGet package to your web project.

It will add the JavaScript, CSS, and sprite icon images in the /Scripts, /Content, and /Content/Images folders in your web project. I moved the JavaScript and CSS to /Content/Scripts/Downloaded and /Content/Styles/Downloaded folders. I prefer to do this so I can bundle scripts with wildcards like /Content/Scripts/Site/*.js. Here's my folder structure:

Bundling

I dropped the *.min.js and *.min.css files since I'm combining and minifying these with the BundleConfig like this:

using System.Web.Optimization;
namespace App_Start
{
public class BundleConfig
{
public static void RegisterBundles(BundleCollection bundles)
{
// Scripts
        bundles.Add(new ScriptBundle(&quot;~/Content/Scripts/modernizr&quot;).Include(
            &quot;~/Content/Scripts/Downloaded/modernizr-2.6.2.js&quot;)); 

        bundles.Add(new ScriptBundle(&quot;~/Content/Scripts/all&quot;).Include(
            &quot;~/Content/Scripts/Downloaded/jquery-1.8.1.js&quot;, 
            &quot;~/Content/Scripts/Downloaded/jquery.unobtrusive-ajax.js&quot;,
            &quot;~/Content/Scripts/Downloaded/jquery.validate.js&quot;,
            &quot;~/Content/Scripts/Downloaded/jquery.validate.unobtrusive.js&quot;,
            &quot;~/Content/Scripts/Site/*.js&quot;));

        bundles.Add(new ScriptBundle(&quot;~/Content/Scripts/mobileall&quot;).Include(
            &quot;~/Content/Scripts/Downloaded/jquery-1.8.1.js&quot;,
            &quot;~/Content/Scripts/Downloaded/jquery.mobile-1.1.1.js&quot;));

        // Styles

        bundles.Add(new StyleBundle(&quot;~/Content/Styles/all&quot;).Include(
            &quot;~/Content/Styles/Site/Site.css&quot;));

        bundles.Add(new StyleBundle(&quot;~/Content/Styles/mobileall&quot;).Include(
            &quot;~/Content/Styles/Downloaded/jquerymobile/*.css&quot;,
            &quot;~/Content/Styles/Site/Mobile.css&quot;));
    }
}

}

The bundles created here are for the JavaScript and CSS for the desktop site ("all") and the mobile site ("mobileall"). The "modernizr" bundle is separate because it only works in the <head> section, but the rest is loaded at the bottom of the <body> tag in the Layout view so it doesn't block page loading.

Make a _Layout.Mobile.cshtml

You'll want a mobile layout view. It's probably simplest to take your existing _Layout.cshtml, copy/paste, and rename it to _Layout.Mobile.cshtml.

The view engine routes "mobile" requests to the correct place. I have mobile in quotes here because it puts iPads in that category. Seems like it would be either _Layout.Tablet.cshtml or _Layout.Phone.cshtml instead of _Layout.Mobile.cshtml, since those are very different form factors, but that's what you get out of the box.

If you don't like that, you can add specific views for specific devices with display modes. I recommend looking through your web logs to see what your users are really browsing with so you spend your time making your app look its best for the most popular user agents. Start with a generic mobile layout and go from there if it starts to break down and you're getting enough traffic from that device to warrant the extra work.

You'll probably rip out pieces of your app/site in the mobile layout. Some stuff doesn't make sense on a phone, so this is where you can take it out if it's site wide. If it's something in a view you want to hide, see below.

For the JavaScript, you can probably get away with just jQuery and jQuery Mobile. You probably won't need Modernizr. You may have some site-specific JavaScript you need to include in their, too.

For style sheets, I recommend starting with just the jQuery Mobile CSS. You can add your own Mobile.css (you can rename this to anything you like) referenced in your mobile layout for tweaks and overrides you need to do. I'd leave the jQuery Mobile CSS as-is so you can upgrade later without problems.

You'll also want to set your viewport to max width for every device:

<meta name="viewport" content="width=device-width">

Here's my _Layout.Mobile.cshtml (the relevant parts anyway):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width">
    <title>@ViewBag.Title</title>
    @Styles.Render("~/Content/Styles/mobileall")
</head>
<body>
    <div data-role="page" data-theme="c">
        <header data-role="header">
            <div>
                <a href="@Url.Action("Index", "Home")">
                    <img src="@Url.Content("~/Content/Images/Logos/Logo_100px_High.png")" alt="Volare Systems, Inc." width="160px" height="100px" />
                </a>
            </div>
        </header>
        <section id="content" data-role="content">
            @RenderBody()
        </section>
        <footer>
            <nav>
                <ul data-role="listview" data-content-theme="c" data-divider-theme="d" data-inset="true" >
                    <li data-role="list-divider">What We Do</li>
                    <li>@Html.ActionLink("Home", "Index", "Home")</li>
                    <li>@Html.ActionLink("Services", "Index", "Services")</li>
                    <li>@Html.ActionLink("Customer testimonials", "CustomerTestimonials", "Services")</li>
                    ...
                </ul>
            </nav>
            <div id="copyright">
                &amp;copy; 2009 - @DateTime.Now.Year.ToString() @Html.ActionLink("Volare Systems, Inc.", "Index", "Home")
            </div>
        </footer>
    </div>
    @Scripts.Render("~/Content/Scripts/mobileall")
</body>
</html>

Start using jQuery Mobile

Now it's time to start adding in the data-* attributes and classes jQuery Mobile wants to use. You'll find them here on the demo site. I used:

data-page="page" in the mobile layout as an outer wrapper
data-theme="c" (try out the different themes to see what suits you best by swapping out letters a-e)
data-role="content" around the @RenderBody markup
data-role="listview" and data-role="list-divider" for the navigation
data-role="collapsible-set" and data-role="collapsible" for collapsible text that shows/hides when you click it

Here are the results:

Click through the docs and see what you can find that adapts well to your situation. For forms, I found it was fine to remove my normal style sheet and let jQuery Mobile take over.

Make a Mobile.css

I use Site.css and Mobile.css as my desktop and tablet/phone CSS files. The _Layout.Mobile.cshtml references to the Mobile.css, and _Layout.cshtml references the Site.css.

You may not need a Mobile.css, but I found it useful to tweak margins, padding, etc. to get the look I wanted. You'll probably have to use the !important CSS tag to force your CSS to override the jQuery Mobile CSS, so watch out for that. Also, every time you do this, someone at A List Apart sighs heavily.

Test and tweak your views

There are lots of cheap and free iPhone/iPad simulators out there. Try to find a free one you like. I gave up and downloaded the Electric Plum one. So far, so good. It's more stable than the free ones I tried.

Once you browse to your site on localhost, you'll see things you didn't realize would be such a fail on the phone. This is your chance to remove it or fix it. There are several approaches I used, based on the situation:

Add jQuery Mobile data-* attributes to your view to render it the jQuery Mobile way. Sprinkling these should not collide with your HTML for desktop rendering.
Change the Mobile.css to draw the elements a little differently just for mobile. If it's really minor, you can hide it with a CSS display: none;, but keep in mind this will run on a phone. If you have the chance to send fewer bytes from the server to the device, that's almost always going to be the way to go.
Add server-side conditional checks for code or markup that is only for mobile (or just for desktop). In a MVC Razor view, this looks like:

@if (Request.Browser.IsMobile) {
    // do something just for mobile
}

If the conditional branching inside your view get to be too ugly, you can add a mobile-only view with the same naming pattern. So Index.cshtml has a mobile cohort in Index.Mobile.cshtml. You can break common code between the two views into partial views, and have the mobile and non-mobile views reference those partial views with the normal

@Html.Partial("_ThePartialView")

Getting HTTP/2 working with Azure CDN

Sat, 03 Feb 2018 16:49:00 Z

HTTP/2 serves web content faster through multiplexing, where several requests can be sent on the same TCP connection. However HTTP/2 is not available today on Azure App Services (web apps). A lot of people wish it was, but that's a limitation of Azure hosting right now. One of the Azure feedback admins had this to say on January 9, 2018:

Hi all. As everyone had noticed, we have upgraded App Service resources to Server 2016. As mentioned in our updates, this is indeed paving the way to HTTP/2 support across the board. As we are settling in with stability of the new OS version, we will begin work to open up HTTP/2. When I have a concrete timeline to share, I will do so. We should expect that in the next few months.

Thanks,
Oded

So it's coming, and hopefully soon, but it's not there yet. In the meantime, you can put static resources like images on an Azure CDN and get HTTP/2 performance benefits, in addition to normal CDN benefits for long-lived content, like cache headers that don't expire any time soon and a geographically distributed network to host it on.

This post is a walkthrough on how to do that with Azure Storage and Azure CDN services.

Azure Setup

First, go into your Azure account and create a new resource group. This makes it easier for testing so you can delete the whole thing when you're done playing around. I named mine testresourcegroup. There are so many pieces to an Azure infrastructure, you are better off if you prefix or suffix everything with one name, like your project name or acronym, and then put the name of the Azure thing you're creating somewhere in that name.

When that's created, go to that resource group. We'll add an App Service Plan (Azure-speak for the server/account type you want for your web app) and an App Service.

I click the + button to add, search for "App Service Plan", pick that, and fill that out. In the Pricing tier, I selected "Free" for this demo.

Now create a test web app by adding another resource to your resource group, searching for App Service, and selecting Web App. Be sure to select your newly created App Service Plan. I ended up having to go to testweb17 to get to a unique, publicly addressable name.

While that's being created, let's add Azure blob storage. Go back to your resource group, click the + button again to add, and search for "blob storage", then select "Storage account – blob, file, table, queue". Give it a unique name. In my case, I had to use teststorge19 to get a unique, publicly addressable name. I also changed the default Account kind to Blob storage since that's all I need. You can come back later and tweak the other settings here based on your app's needs.

Now we need to create the CDN in Azure. Go back to your resource group, click the + to add, and search for "CDN" and select it from the list. Give it a name. I used testcdn. Pick a pricing tier. I used Standard Verizon (Verizon allows custom domain HTTPS connections, Akamai doesn't).

Then select the option to create a CDN Endpoint. Like the App Service and App Service Plan relationship, the CDN is the service level and pricing, but the CDN Endpoint is the thing you really connect to. Pick a CDN endpoint name. I used testcdn19 to match up with my storage account name. Again, this must be unique and publicly addressable. Be sure to pick Origin type of Storage and pick the Original hostname for your storage account from the drop down. I used teststorage19.blog.core.windows.net since that is my test storage account created above.

When Azure is done huffing and puffing, your new resource group should look like this, but of course with your names. You'll have an App Service Plan with an App Service, a Storage Account, and a CDN Profile with a CDN Endpoint.

Web Setup

I've made a one page web app with an index.html and an image. You can download them from GitHub or use your own content or test page. It's nothing more than this HTML and a picture.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>HTTP/2 with Azure CDN</title>
</head>
<body>
    <p>Here is an image of an elk in Rocky Mountain National Park.</p>
    <img src="images/Fall - Estes Elk.jpg" />
</body>
</html>

To upload this web app to Azure, I first need to get a publish profile from Azure in my App Service.

Then I open my web app in Visual Studio, right click on the web site or web project and select Publish Web App.

Next, I tell Visual Studio to import the just downloaded publish profile.

Then when I publish my web app, it goes up to Azure and is publicly available.

After the publishing process completes, my browser opens the test web app at https://testweb17.azurewebsites.net/.

If I open Chrome Dev Tools and go to the Network tab, I can see the two requests (one for the page, one for the image) are using HTTP 1.1. Let's see if we can get that image to be served using HTTP/2.

Storage Setup

Go to your Azure resource group, find the storage account you set up, and add a blob container. This is not quite a folder, but kind of acts like one for our purposes. I'll add one for "web". Be sure to set your container to something other than Private. I set mine to Blob.

Now I can select my container and upload the image to it. There are lots of client tools to upload, download, and manage your Azure storage files, like CloudBerry Explorer for Microsoft Azure, which is free.

Once I have uploaded the image, I can click it and get its URL. Open that URL to test that you can see the image. If not, check that you didn't make your container private. Also, be sure you are using the correct case. Calls to storage blobs are case sensitive. If you file is Image.jpg and request image.jpg (lowercase "I"), you'll get a 404. In my case, the image URL ends up as https://teststorage19.blob.core.windows.net/web/Fall%20-%20Estes%20Elk.jpg.

If you open Chrome Dev Tools and refresh the image, you can see it's being served over HTTP/2 already without being on a CDN.

Let's update the HTML to use that new URL and check that it's still using HTTP/2 when uploaded to the Azure App Service.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>HTTP/2 with Azure CDN</title>
</head>
<body>
    <p>Here is an image of an elk in Rocky Mountain National Park.</p>
    <img src="https://teststorage19.blob.core.windows.net/web/Fall - Estes Elk.jpg" />
</body>
</html>

I made this change and re-published the web app, and sure enough, it's served over HTTP/2.

Let's go one step further and serve the image from a CDN, instead of directly from the storage account.

CDN Setup

In Azure, open your CDN Endpoint. You should see the URLs for your storage account and your CDN that maps to your storage account.

Since all our content is in a storage container called "web" and that becomes part of the URL, we can make that a default path for the CDN Endpoint under Origin.

Now we'll have URLs like this, using the CDN and skipping the /web/ folder in the URL:

https://testcdn19.azureedge.net/Fall - Estes Elk.jpg

instead of:

https://teststorage19.blob.core.windows.net/web/Fall - Estes Elk.jpg

This change can take up to 90 minutes to propagate, so if you get 404s, that may be what's happening.

Once you can browse to the image URL with your browser, replace that image source in the HTML markup and re-publish your web app to Azure.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>HTTP/2 with Azure CDN</title>
</head>
<body>
    <p>Here is an image of an elk in Rocky Mountain National Park.</p>
    <img src="https://testcdn19.azureedge.net/Fall - Estes Elk.jpg" />
</body>
</html>

When you browse to it now, you can open Chrome Dev Tools and confirm the image is coming from the CDN and is using HTTP/2.

Working with two sets of ESLint rules for legacy ES5 and modern JavaScript using Gulp

Tue, 05 Feb 2019 01:39:05 Z

I've written before about using file extensions to tell webpack and Babel which files are older-style ES5 syntax and which are newer-style JavaScript. What if you've got a project that has both, and you need to run ESLint on the older, *.js files as well as the new *.es6 files?

You can run both in one task with Gulp.

First, set up separate ESLint rules files. These are usually .eslintrc.json files, but since we need two sets of rules, create .eslintrc.es5.json (for the older syntax rules) and .eslintrc.es6.json (for the newer syntax rules).

Then create Gulp task ("validate-es5") to get a glob of the *.js files and apply the rules in the .eslintrc.es5.json rules config and a Gulp task ("validate-es6") to get a glob of the *.es6 files and apply the rules in the .eslintrc.es6.json rules:

const gulp = require("gulp");
const eslint = require("gulp-eslint");
const plumber = require("gulp-plumber");
const paths = {
    es6scripts: "Scripts/**/*.es6",
    es5scripts: "Scripts/**/*.js"
};
const es5eslintGlob = [paths.es5scripts];
const es6eslintGlob = [paths.es6scripts];
 
 
gulp.task("validate-es5", () =>
    eslintPipeline(gulp.src(es5eslintGlob), ".eslintrc.es5.json")
);
 
gulp.task("validate-es6", () =>
    eslintPipeline(gulp.src(es6eslintGlob), ".eslintrc.es6.json")
);
 
function eslintPipeline(stream, rules) {
    return stream
        .pipe(plumber({
            errorHandler: error => {
                console.log(error.message);
                console.log(error.toString());
            }
        }))
        .pipe(eslint(rules))
        .pipe(eslint.format())
        .pipe(eslint.failAfterError());
}

Next, create a Gulp task to run both tasks named "watch" to run a watch on those files and execute ESLint with the correct rule set for each file extension when a file changes:

const print = require("gulp-print").default;
const watch = require("gulp-watch");
 
gulp.task("watch", () => {    
    eslintPipeline(watch(es5eslintGlob)
        .pipe(print(filepath => `ESLint (ES5): ${filepath}`)), ".eslintrc.es5.json")
        .pipe(eslint.failOnError());
    eslintPipeline(watch(es6eslintGlob)
        .pipe(print(filepath => `ESLint (ES6): ${filepath}`)), ".eslintrc.es6.json")
        .pipe(eslint.failOnError());
});

Fix for weird errors in MVC4 when adding a new Area

Thu, 13 Dec 2012 01:39:38 Z

MVC has let you add Areas to your web project for a couple versions now. Areas help you group large chunks of code in your web app. You can group along a technical axes (like "Api") or a functional axes (like "Admin").

The first error

I created a new MVC4 project, added an area called "Test", and browsed to the home page (http://localhost:59669). Works! Then I browse to the new area (http://localhost:59669/Test) and get this:

What's going on with those underscores? The error message shows the problem is in my Web.config, but not the application root one, the one under /Areas/Test/Views/Web.config. I open it in Visual Studio, and sure enough, underscores.

<configSections>
  <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=__WebPagesVersion__.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
    <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=__WebPagesVersion__.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
    <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=__WebPagesVersion__.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
  </sectionGroup>
</configSections>

I compare that to the other Web.config under the root /Views/Web.config, and copy and paste those values in.

<configSections>
  <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
    <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
    <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
  </sectionGroup>
</configSections>

At this point, I'm assuming there is a bug in the "Add Area" template. So let's build and refresh the browser and it should work now, right?

The second error

Of course not.

Hmm. Lots of details in that stack trace, but not much to go on here. I checked my route registration code and checked my area registration code. Both looked fine:

using System.Web.Mvc;
using System.Web.Routing;
namespace MvcApplication2.App_Start
{
public class RouteConfig
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute(".axd/{*pathInfo}");
        routes.MapRoute(
            name: &quot;Default&quot;,
            url: &quot;{controller}/{action}/{id}&quot;,
            defaults: new {controller = &quot;Home&quot;, action = &quot;Index&quot;, id = UrlParameter.Optional},
            namespaces: new[] { &quot;MvcApplication2.Controllers&quot; }
            );
    }
}

}
using System.Web.Mvc;
namespace MvcApplication2.Areas.Test
{
public class TestAreaRegistration : AreaRegistration
{
public override string AreaName
{
get { return "Test"; }
}
    public override void RegisterArea(AreaRegistrationContext context)
    {
        context.MapRoute(
            name: &quot;Test_default&quot;,
            url: &quot;Test/{controller}/{action}/{id}&quot;,
            defaults: new {action = &quot;Index&quot;, id = UrlParameter.Optional},
            namespaces: new[] {&quot;MvcApplication2.Areas.Test.Controllers&quot;}
            );
    }
}

}

I also added the namespaces to the area (the last parameter above) to help the routing engine find the right controller. That looked fine, too.

The error message was about a bad assembly ("The given assembly name or codebase was invalid."). Maybe something didn't get built or loaded right ? I tried a Clean and Rebuild. No luck.

Maybe ASP.NET temp files were cached? Let's clear browser cache, close and re-open the browser, close and re-open Visual Studio, restart IIS Express, and see if that helps….and no, no luck.

The solution

I was running out of ideas, but since the first problem was the Web.config, maybe this was, too. I opened up the generated Web.config under /Areas/Test/Views/Web.config again and compared it to the one under the root /Views/Web.config.

Sure enough, more freaking underscores. I just copied ALL the values from the root view's Web.config into the areas one, built, refreshed, and finally got the areas showing up.

Maybe I have a wacky install. Maybe I got hold of some bad pre-release NuGet package. But it seems there is a template bug here when adding Areas to an MVC project. I have the Fall Update on Visual Studio 2012, so my About screen looks like this:

I'm writing this up in the hopes that I save someone else some time. If you have suggestions on where I got an underscore happy template, please let me know in the comments below.

Running SpecFlow and WatiN tests with TeamCity and AppHarbor

Fri, 03 Jun 2011 00:40:12 Z

If you're using SpecFlow and WatiN to automate your web testing, things work great on localhost, but tend to fall apart on the continuous integration server. It's a "chicken or the egg" paradox. If the new code hasn't been deployed yet, it can't be externally tested with WatiN, but it shouldn't be deployed until all the tests have passed. What are you supposed to do?

TeamCity

If your SpecFlow and WatiN tests are in their own assembly (something like MyProject.AcceptanceTests.dll), and you're using TeamCity, it's easy to run your unit tests and integration tests, then deploy the code to a web server, then run your acceptance tests in a separate build step. It's just a matter of breaking up the steps and designating which test assemblies will be run at which time.

This step in the screen shot below is running the unit tests and integration tests. A separate, later step will run the tests in the **\*AcceptanceTests.dll assembly after the code has been deployed to the web server.

AppHarbor

If you're using AppHarbor to run your tests on check in with git push appharbor master, (and you should - it's super easy), you don't want to run your web tests until the code is deployed, but AppHarbor doesn't deploy anything until all the tests pass.

What we want is for AppHarbor to ignore the web automation tests until the code is deployed. AppHarbor flips a *.config appSetting key named "Environment" to "Test" when it's testing and to "Release" when the code is deployed. So while your tests are running, your App.config in your test project should look something like this:

<appSettings>
  <add key="Environment" value="Test"/>
</appSettings>

We can take advantage of this appSetting test runner change to tell SpecFlow to ignore this set of tests, which allows AppHarbor to continue running other tests and deploying the code.

This is not be the most elegant way to do this, but I got this working today:

[Binding]
public class MyStepDefinition
{
    [BeforeFeature]
    public void BeforeFeature()
    {
        if (ConfigurationManager.AppSettings["Environment"] == "Test")
            Assert.Ignore();
    }
// Rest of step definition code...

}

The BeforeFeature attribute tells the SpecFlow test runner to execute that method before each feature. With a quick check on the Environment appSetting value, we can tell AppHarbor to ignore this test and continue processing. This will ignore all scenarios in all feature files. Since all my scenarios are web automation tests, that works for me.

But what if you have some scenarios that rely on web automation testing and others that don't? A more targeted approach would be to set a SpecFlow tag, like @web over the SpecFlow scenarios that require web automation testing to pass. Then in the [BeforeScenario("web")] handlers for that tag, you could set Assert.Ignore to skip those scenarios while executing all other scenarios.

[BeforeScenario("web")]
public void BeforeScenario()
{
    if (ConfigurationManager.AppSettings["Environment"] == "Test")
        Assert.Ignore();
}

Once your non-web automation tests have passed and the code is deployed, you can point your local test runner at the AppHarbor URL and test against the newly deployed web app.

Sharing data from within your Windows 8 app using JavaScript

Wed, 17 Oct 2012 00:39:51 Z

One of the nifty features of Windows 8 is the ability of the OS to share data between apps. For instance, if I open the Weather app, click Windows + H, I get the Share bar that let's me send the weather forecast to the Mail, Tweetro, or People apps.

Most sharing apps take relevant text, HTML, and links, and prepare a draft email, tweet, etc. for you to send. Here is the HTML the Mail app prepares to send from the Weather app:

This post is about how to do the same thing from within your app.

You can share text, HTML, images, files, etc. I'm going to share text with my current location information from an altitude app. This is what we're going for:

It's just plain text, but you can get fancier.

The first thing you'll do in your code is listen for Windows 8 telling you the user wants to share something. Wire up the sharing event listener in your "ready" code, and unhook it in your "unload" code like this:

var dataTransferManager;
var page = WinJS.UI.Pages.define("/default.html", {
ready: function(element, options) {
dataTransferManager = Windows.ApplicationModel.DataTransfer.DataTransferManager.getForCurrentView();
dataTransferManager.addEventListener("datarequested", onSharingRequested);
},
unload: function() {
dataTransferManager.removeEventListener("datarequested", onSharingRequested);
}
});

Now we've got a function called "onSharingRequested" that will run when the user starts sharing within our app, but we need to write the code in that event/function to build up the text to share.

function onSharingRequested(e) {
    var request = e.request;
    request.data.properties.title = "My current altitude and location";
    request.data.setText("My current altitude and location are Altitude: " + location.altitude + " " + location.altitudeUnits +
        ", Latitude: " + location.latitudeFormatted + ", Longitude: " + location.longitudeFormatted +
        ", Accuracy: " + location.accuracy + ", Near: " + location.near);
}

You set properties on the passed in request object, like the title and the text shown here. The title must be set or sharing won't work.

Sharing data between apps is something people will probably get used to eventually, but if you want to be sure the users of your app know they can share, make a button that does that same thing as Windows + H or a swipe from the right on a tablet.

On your button click event, call the showShareUI method of the DataTransferManager like this:

function onSharingButtonClick() {
    Windows.ApplicationModel.DataTransfer.DataTransferManager.showShareUI();
}

Validation frameworks in ASP.NET MVC

Thu, 17 Sep 2009 00:41:23 Z

There are plenty of validation frameworks out there. I've worked with NHibernate Validators, Microsoft's Enterprise Application Blocks, and now Data Annotations. They primarily work by adding attributes to the properties in the class you want to validate.

How are they different?

Not very. The biggest difference between them is their syntax. I guess the Validation Blocks from Microsoft's P&P group have a lot of configuration options, but I haven't needed that on a project. The most prominent differences are in the attributes themselves.

You can probably make a case for Data Annotations having a slight advantage since it's going to be in the .NET base-class libraries. Easier to deal with assemblies installed in the GAC instead of the ones you have to drag around for each deployment.

How do you integrate them with MVC?

Each of these frameworks can be integrated with ASP.NET MVC. But the best validation call is one you don't have to explicitly make. Huh?

It's OK to call MyClass.IsValid() in a controller action, but if you can avoid it, I think you're better off. Otherwise, what happens if you forget to call it?

Instead, use a model binder that invokes the validation framework for you. This is how I am using the Data Annotations model binder with the MVC framework:

ModelBinders.Binders.DefaultBinder = new Microsoft.Web.Mvc.DataAnnotations.DataAnnotationsModelBinder();

Now this guy will intercept calls to your controller actions and reject invalid incoming view models. Here is a simple tutorial for using Data Annotations that goes into more detail.

How do you lay this out in the solution?

I have an Application Services layer that my MVC layer calls into. My controllers have constructors with an interface to an application service injected into them. My IoC container decides which concrete version of this application service interface to use at runtime.

Next, my Application Service layer has a DTO folder that holds all the DTOs (property-only classes) my views need in my MVC app. These are not my domain entities. There might be a lot of overlap with those domain entities, but these DTOs are just there for communication between the UI layer and Application Services layer. These DTOs are where I put my validation attributes.

So now I've got views that are tightly bound to the DTOs, which are owned in the Application Services layer. This allows strong typing of the view so I can use the DTO's properties as my view's model. This is handy for the Html Helpers to get design-time IntelliSense and compile-time checking.

What else can you do?

I haven't spent a lot of time looking into it, but xVal looks pretty strong for client side AND server side validation using Data Annotations and a couple other validation frameworks. It also lets you validate your business rules in your domain and throw an exception. I need to check into this more, because that sounds like the validation holy grail for validation to me: getting UI validation and business rule validation into a common format.

The case for TDD

Fri, 17 Jul 2009 11:39:00 Z

TDD is hard. It sounds like it wouldn't be hard. It's just a little test. The code is the hard part, right? But it's really hard to do it well. I struggle with it plenty and I know my way around C# and OO pretty well.

There better be a payoff for this bass-ackwards way of coding. It takes a while to get there, but I can see the light at the end of the tunnel in my own development. Here's where I've seen my code improve as I've moved toward TDD:

Focusness

You focus on the behavior of your code instead of the implementation. You don't start by thinking of tables, classes, and properties (or in my case, try hard not to). You start off thinking of the business requirements and roles. User stories are popular because they push you into restating the requirements in context: "As a (some role)...I want to (do something)...so that (some business value)". The first two chunks of this can guide your test creation. You can write methods that cover these scenarios.

If you're doing it the RED-GREEN-REFACTOR way, you'll write a test and just enough for the code to compile, get the test to pass with the minimum amount of code possible. Finally, you can go back and clean up what you aren't proud of from your first effort, then run the test again. You get to keep repeating that until you are happy with the code and that the requirement/story is met and the user accepts it.

Then you STOP. That's the fourth step you don't see in the pretty RED-GREEN-REFACTOR icon. If you don't stop, you loose your focus on the functionality and you start trying to gold-plate the code. Which can lead to...

Dude, you know what would make this REALLY cool?

You're getting paid to write software to meet the requirements. If you going beyond that, be careful who you're doing the coding for. If it's the business, and you're glad to show them how much time you've spent on it, you might be justified in doing it. But if you're coding it for yourself, do it on your own time.

Unfortunately, people who are drawn to programming are often tinkerers and bit-twiddlers. I appreciate having a framework for my development that keeps me on task, because I am easily distracted by grand visions of what I might be able to code into the app. There is no code we couldn't tweak a little and add this new cool pattern or just-learned technique to. TDD forces you to go directly to the requirements, not the technology.

SOLID code

The more you move toward TDD, the more little classes you have with giant names. Same thing with methods. There are tons, they are very short (one screen or so max), and they have long names. This is progress?

Yes, I think it is because of the SOLID principals. SOLID is a horrible acronym of acronyms, but it can help you keep some object-oriented principals in mind. I'll go over it and how I've tried to learn it in more depth in a future post, but the guys at Los Techies covered SOLID in depth already. So the side effect of decoupled code is you have lots of little files that just do one little thing. It took me a while to get over this and the file bloat in the project, but I'm at peace with it now. The payoff is that I am using more SOLID principals than I was before, and that's a good thing.

Oh yeah, you get some tests, too

It's been said before, but TDD is kind of misnamed. Yes, you start with the test, but that's not the most important thing. The most important thing is the requirement focus and the way it drives you toward a more loosely coupled design. But it's pretty fun to see that screen light up with green checks or circles after you've made a change.

The real value of the tests themselves is that today's unit tests become tomorrow's regression tests. You won't remember why you wrote the code last week, but you don't have to. The tests can also serve as mini-documentation of the requirements if you write the test names in a consistent way. There are BDD frameworks that let you spit out some HTML to do exactly this.

Ruthless Refactoring

All this adds up to something of a safety net for refactoring. Think of the confidence you can have changing the code, even if it's another team members code. Or if (gasp!) they make changes to your code. It's nice to know your code still works.

If you write the tests first, you know you've got the "happy path" covered on your code. That's the one you started with. You can write a few more tests to cover the likely deviations from that happy path, but when you get to the weird stuff (what if you order $999,999,999,999 in widgets?), call it good and move on.

Showing and saving user settings in a Windows 8 app with JavaScript

Tue, 23 Oct 2012 00:39:49 Z

If your Windows 8 app has user-based settings, you need a place to show those values, let users change them, and save them for later use. Sometimes these are called preferences, but in Windows 8, they are called "settings".

You can see and set your settings in a Windows 8 app with Windows + I. You'll pull up a fly out dialog from the right like this:

Clicking on the "Options" choice opens up the settings for the app:

Before you dive in and do this with your app, get acquainted with the Windows 8 app settings guidelines. Here's what I did for mine.

Create the Options view

Here is my options.html file. Most of this is plain old HTML. Note the ID of the outer div is "options". This could be named anything, but keep that ID in mind since we'll need it later.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Options</title>
&lt;!-- WinJS references --&gt;
&lt;link href=&quot;https://volaresoftware.com/blog/Microsoft.WinJS.1.0/css/ui-light.css&quot; rel=&quot;stylesheet&quot; /&gt;
&lt;script src=&quot;//Microsoft.WinJS.1.0/js/base.js&quot;&gt;&lt;/script&gt;
&lt;script src=&quot;//Microsoft.WinJS.1.0/js/ui.js&quot;&gt;&lt;/script&gt;

&lt;!-- App references --&gt;
&lt;link href=&quot;https://volaresoftware.com/blog/css/settings.css&quot; rel=&quot;stylesheet&quot; /&gt;
&lt;script src=&quot;/js/app/options.js&quot;&gt;&lt;/script&gt;

</head>
<body>
<div id="options" class="win-settingsflyout" data-win-control="WinJS.UI.SettingsFlyout" data-win-options="{ width:'narrow' }">
<div class="win-header">
<button id="backButton" class="win-backbutton" aria-label="Back" onclick="WinJS.UI.SettingsFlyout.show()"></button>
<div class="win-label">Options</div>
</div>
<div class="win-content">
<div class="win-settings-section">
<p>
<label>Use feet or meters</label>
<label>
<input id="feet" name="feetOrMeters" type="radio" value="Feet" checked />Feet
</label>
<label>
<input id="meters" name="feetOrMeters" type="radio" value="Meters" />Meters
</label>
</p>
<p>
<label for="refreshInterval">Refresh interval in minutes</label>
<input id="refreshInterval" name="refreshInterval" type="range" min="0" max="15" value="1" />
</p>
<p>
<label for="movementThreshold">Movement threshold in feet</label>
<input id="movementThreshold" name="movementThreshold" type="range" min="0" max="100" value="50" />
</p>
</div>
</div>
</div>
</body>
</html>

The CSS classes may not be familiar, but these are coming from the Windows 8 SDK CSS (ui-light.css).

The interesting parts are 1) there is no form tag or submit button (we'll see the JavaScript below that works with these values), 2) the data-win-control stuff in the top level div,

<div id="options" class="win-settingsflyout" data-win-control="WinJS.UI.SettingsFlyout" data-win-options="{ width:'narrow' }">

and 3) the onclick event for the back button that calls WinJS.UI.SettingsFlyout.show().

<button id="backButton" class="win-backbutton" aria-label="Back" onclick="WinJS.UI.SettingsFlyout.show()"></button>

The WinJS area we're working with here is the SettingsFlyout, and the show() and hide() methods display it and move it out of the way.

In modern web development, it's a venial sin to put JavaScript code in the onclick event of a button. We usually aim for unobtrusive JavaScript where all the events are wired up in JavaScript and the HTML just does the layout. I think that's a good practice, but for a back button like this, it makes the JavaScript more cluttered to have a tangential concern shoved in there. So take your pick on where you put your onclick event – the button itself or the JavaScript file.

Open the Options view

Now that we've got lovely labels and inputs to show in the Settings pane, we're ready to show it off. Add the following to your default.js file:

app.onsettings = function(e) {
    e.detail.applicationcommands = {
        "options": {title: "Options", href: "/pages/settings/options.html"},
    };
    WinJS.UI.SettingsFlyout.populateSettings(e);
};

This code will listen for the application's onsettings event (the "app" variable here = WinJS.Application) and open the options.html file in the href above. The title is what you want the user to see on the app's Settings pane. Clicking it will open your view where they can change values. The "options" part on the left side is the ID of the div it will look for in the options.html file.

At this point, you should be able to run your app and type Windows + I and see the app's settings pane, then click Options and see your app's options and the options.html input controls. Nothing will be reading or writing any data yet, so let's do that next.

Save and recall user settings for your app

There are three built-in storage areas for your Windows 8 app: local storage, roaming storage, and temporary storage. You can also use SkyDrive, Windows Azure Mobile Services, or your own homemade JSON API that reads and writes to your own database.

For app settings, I think roaming makes the most sense. Users will expect your app to remember their settings across different devices, and that's what roaming provides with no extra work on your part. The real difference between roaming and local you have to consider is, roaming storage is limited to 100k and can't hold binary data. If that won't work for your app, look into local storage, SkyDrive for files or photos, or Azure Mobile Services for structured data.

Here's the options.js file that pulls values from options.html and reads and writes values from the inputs:

(function() {
    "use strict";
var appData = Windows.Storage.ApplicationData.current.roamingSettings;

WinJS.UI.Pages.define(&quot;/pages/settings/options.html&quot;, {
    // This function is called whenever a user navigates to this page. It
    // populates the page elements with the app's data.
    ready: function (element, options) {
        var feetRadio = document.getElementById(&quot;feet&quot;),
            metersRadio = document.getElementById(&quot;meters&quot;),
            refreshIntervalRange = document.getElementById(&quot;refreshInterval&quot;),
            movementThresholdRange = document.getElementById(&quot;movementThreshold&quot;);

        // Set settings to existing values
        if (appData.values.size &gt; 0) {
            if (appData.values[&quot;feetOrMeters&quot;]) {
                setFeetOrMetersValue();
            }
            if (appData.values[&quot;refreshInterval&quot;]) {
                refreshIntervalRange.value = appData.values[&quot;refreshInterval&quot;];
            }
            if (appData.values[&quot;movementThresholdInFeet&quot;]) {
                movementThresholdRange.value = appData.values[&quot;movementThresholdInFeet&quot;];
            }
        }

        // Wire up on change events for settings controls
        feetRadio.onchange = function () {
            appData.values[&quot;feetOrMeters&quot;] = getFeetOrMetersValue();
        };
        metersRadio.onchange = function () {
            appData.values[&quot;feetOrMeters&quot;] = getFeetOrMetersValue();
        };
        refreshIntervalRange.onchange = function() {
            appData.values[&quot;refreshInterval&quot;] = refreshIntervalRange.value;
        };
        movementThresholdRange.onchange = function() {
            appData.values[&quot;movementThresholdInFeet&quot;] = movementThresholdRange.value;
        };
    },

    unload: function() {
        // Respond to navigations away from this page.
    },

    updateLayout: function(element, viewState, lastViewState) {
        // Respond to changes in viewState.
    }
});

function getFeetOrMetersValue() {
    var feetOrMetersRadio = document.getElementsByName(&quot;feetOrMeters&quot;);
    for (var i = 0; i &lt; feetOrMetersRadio.length; i++) {
        if (feetOrMetersRadio[i].checked) {
            return feetOrMetersRadio[i].value;
        }
    }
}

function setFeetOrMetersValue() {
    var feetOrMetersRadio = document.getElementsByName(&quot;feetOrMeters&quot;);
    for (var i = 0; i &lt; feetOrMetersRadio.length; i++) {
        if (feetOrMetersRadio[i].value === appData.values[&quot;feetOrMeters&quot;]) {
            feetOrMetersRadio[i].checked = true;
        }
    }
}

})();

I'm using the Windows.Storage.ApplicationData.current.roamingSettings (shortened to the appData variable) to read and write from roaming settings with the syntax:

appData.values["theKey"] = theValue;

It's a key value store, so if you've worked with cookies in the past, this will seem familiar.

The existing values (if there are any) are pushed into the input controls. Next, the onchange events on the options.html inputs are wired up to write the new values. You may also have other things you have to do in your app when the user changes a setting value, like redraw or hide something, etc.

Push your logic to the core

Thu, 30 Dec 2010 01:40:30 Z

Creeping logic

Developers struggle with where to put their business logic. We all know at an intellectual level that we should be keeping business rules and logic in some kind of a business layer, but I don't see it in practice that often. I do see a lot of business layers that turn around and call data layers. There's often nothing business-y about them.

Instead, the logic is sprinkled throughout the other layers, sometimes to take advantage of a technology, sometimes because of the strengths of the developer who wrote the code.

Validation controls in ASP.NET Web Forms are an example of business logic in the UI layer. Another is an ASP.NET Web Forms code behind event that calculate discounts for preferred customers on Page_Load.

ASP.NET MVC isn't immune from this either, although the validation logic story is better with Data Annotations letting validation rules flow up to the UI. Controller actions can be mistreated just like code-behind and often contain more business logic than they should.

And putting more logic in stored procs doesn't make your app dev teams more agile. It makes the data team the bottleneck for logic changes.

Journey to the Center of the App

A better approach is to lift that logic out of those layers and put it in your business/domain/core layer in C# POCOs. In many apps, this logic is what makes the app worthwhile. Sometimes, it's what gives the company a competitive advantage. It should be clear, expressive, and long lived code. It should not be coupled to any particular technology.

These can be tricky changes to make once an app is partly finished or already up and working in production. There can be a lot of refactoring. But the effort can pay off in making the code more clear to anyone working on it and letting you make complex changes much faster because the logic is centralized and expressive.

How do you do this?

One test I like to use for where the logic goes is, "What if the technology changed?" What if I wasn't able to use Web Forms or MVC, but had to use Silverlight or any other future technology? What if SQL Server went away? What if we switched from stored procs to NHibernate and then again to Entity Framework? If we've got business logic wrapped up in our tools, no matter what the tools are, we can be sure the logic will need to be rewritten when the technology changes.

It's great to take advantage of new tools, but your code needs to keep it's distance where possible. Wrap the tool with an interface or something so the tool is decoupled from your logic, and you can replace the technology if you need to. I've written about this interface wrapping technique before.

Another great technique is using TDD or other test-first approaches because your code will be written with an eye toward how it will be consumed. You'll end up with lots of small classes and methods with expressive names. This outside-in approach to coding really guides you toward creating a clean API for the app's first customer - your test code.

Generated unit tests are a net negative

Tue, 12 Oct 2010 00:40:38 Z

One of the most common misunderstandings for developers new to unit testing is the value of code coverage. We intuitively know that if coverage is low, we don't have enough tests, and if coverage is high, we probably do. Some IT shops even set minimum code coverage percentages, so if you check in code that drops the coverage metric below 80%, you fail the build.

One way to get higher code coverage is to generate the tests. Visual Studio has versions that can do this for you. Point the code at a class, click OK a few times, and all your code in the class under test can be covered. In fact, the generated test usually check for things you might not bother to, like what if there is a negative value passed in to a method, what if a zero passed in, what about a null, etc. How can this be bad? We're exercising the API of our class more fully, right?

What not to test

I think the focus needs to be on testing the right code in the right way. There is no point in testing the .NET framework. If you have a auto property that is an int, you don't need to test -1, 0, 1, and null. If int stops working, everyone using .NET has a bug. But int isn't going to fail, and even if it does, it's not your code anyway (unless you work at Microsoft on the .NET framework team).

So the first rule is be sure you're testing your code. That means testing your methods that do real stuff. If you have a method in your class that just wraps a call to another class, there really isn't anything worth testing. All you can test is that the class can be created and the method can be accessed and has those parameters and they are of that type. But you can do that better by testing the underlying class instead of the pass-through method.

Go faster when refactoring

In fact, testing these properties and pass-through methods and no arg constructors increases your code coverage numbers without adding anything meaningful to the test suite. The net negative comes into play when it's time to refactor, whether it's adding or removing properties, renaming, moving things to different classes, etc. Generated tests can really slow you down here as the new code stops building and the generated tests have to be removed and regenerated.

A better way is to write the tests you need first, then add the code to implement that business rule or feature. Whether you're using TDD, BDD or something else, you'll end up with tests that express the intent of the code rather than its implementation. Tests should emphasize the features of the application, not the coding artifacts. These are the kind of tests that add real value to your project.

MVC 2: Electric Boogaloo - What's new in MVC 2

Mon, 18 Jan 2010 01:41:07 Z

The MVC team loves their rec center, but an evil real estate developer wants to bulldoze it to build a hipster bar named Ruby's. The team has been coding their butts off with MVC 2, but will the new features be enough to save the rec center? Will the cynical real estate developer cackle and complain that it's still not enough?

Will the MVC team get areas right? Will the new templated HtmlHelpers strike the right balance of rapid development and fine control? Will validation concerns get muddled up with UI concerns? Will more web forms developers make the switch to MVC?

New Areas

Areas are an organizing tool for large web sites. If you've got lots of view and lots of controllers plus some shared content, areas can work as a top-level routing mechanism.

Example areas might be Admin for an administrative site, Store for a ecommerce site, etc. They can be either folders or separate web projects. Use the AreaRegistration class to set up your routes in your Global.asax (taken from MSDN article):

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
AreaRegistration.RegisterAllAreas();

routes.MapRoute(
    &quot;Default&quot;,                                              // Route name
    &quot;{controller}/{action}/{id}&quot;,                           // URL with parameters
    new { controller = &quot;Home&quot;, action = &quot;Index&quot;, id = &quot;&quot; }  // Parameter defaults
);

}

Then override AreaRegistration in the area's folder or in the root of the area web project (also taken from MSDN article):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
namespace Store
{
public class Routes : AreaRegistration
{
public override string AreaName
{
get { return "Store"; }
}
    public override void RegisterArea(AreaRegistrationContext context)
    {
        context.MapRoute(
            &quot;Store_Default&quot;,
            &quot;Store/{controller}/{action}/{id}&quot;,
            new { controller = &quot;Products&quot;, action = &quot;List&quot;, id = &quot;&quot; }
        );
    }
}

}

Sharp Architecture has had areas since its first release. I remember hearing rumors about areas coming in MVC for version 1.0, but I guess it wasn't ready. The biggest difference between the Microsoft version and the Sharp Architecture version is that the Microsoft version lets you register different web projects.

Theoretically, multiple teams can work on multiple web projects, then these web projects can be rolled into the same solution and AreaRegistration can make them appear as one big web site to a browser. I don't know how much of a need that is, but I guess if you have distributed teams that can't get to the same source code repository, it might be useful. I prefer multiple folders in one web project over multiple web projects to keep build times down and Visual Studio responsiveness up. I wouldn't break out each logical web site section to its own web project until the folder approach stopped working.

New HtmlHelpers

I'm not sure if Code Camp Server pushed the MVC team into this or just showed how it was possible to take HtmlHelpers to this extreme, but I'm glad to see the same concepts getting rolled into the base class libraries.

I think the new HtmlHelpers do give a nice range of control over your markup. You can use:

<%= Html.LabelFor(x => x.FirstName) %>
<%= Html.EditorFor(x => x.FirstName) %>
<%= Html.LabelFor(x => x.LastName) %>
<%= Html.EditorFor(x => x.LastName) %>

if you want to be fairly explicit for each form element. Or you can save a lot of keystrokes with:

<%= Html.EditorFor(x => x) %>

And if that's not enough, you can decorate your models with some UI hint attributes and roll your own rendering. I think this is something large web projects will take advantage of for consistent markup and control rendering. Seems like this has the advantages of homemade server controls without some of the hassles (INamingContainer, I'm looking at you).

New Validation

I did worry for a little bit about the UI stuff bleeding into the model with these new attributes. Seems like we've got a leaky abstraction there. But these days I think of the MVC model as the view model, not the domain model. The view model is married to the view it works with. It has no other purpose than to represent the data in that view. Well, now it also validates the data in that view, at least initially. Oh, and it now controls some of the view rendering. Damn. That's three responsibilities for my little view model.

But I don't have an alternative proposal to attribute-heavy view models either. I don't want partial classes. I haven't seen much benefit to the buddy class approach. And I do want to reuse some of my UI hints across view models (like a date picker for DateTime types). Plus, I want to take advantage of the new client and server side validation of my view model before it gets into the action method. MVC 2 has this built in.

I guess I'll grin and bear it and work on a new blog post about the Triple Responsibility Principal for View Models (as opposed to SRP). :D

Future

I've already talked about where MVC views are now and where they are going, and the view engine is definitely getting better. I still think views will continue to be the most in-flux part of the MVC framework. I know people that are very happy with Spark as a view engine, and Louis DeJardin, the guy who wrote Spark, is now working for Microsoft on the ASP.NET team. I don't have any inside scoop, but I wouldn't be surprised if the web forms view engine got a little."sparkier".

Views may also be the area with the most room for improvement, depending on who you talk to. When I visit with people about MVC and explain that runat="server" is gone and you can go ahead and close your Visual Studio toolbox, most get a glazed look. They don't want to hand code the HTML. They don't want to see a property sheet that doesn't know anything about their current mouse selection. They don't want to give up their current productivity.

I get that, but I think you can be faster without the designers and toolboxes and property sheets. It takes a while to get used to using the keyboard more than the mouse, but I think it's worth pushing yourself over that learning curve.

Time to switch from Web Forms to MVC?

I push MVC on projects where I have influence on that decision. In your world, it's your call. You may have environment constraints, in-flight projects, etc.

But it also doesn't have to be all or nothing. You don't have to wait for a greenfield project to fall in your lap. You can run MVC inside your current Web Forms project. It's just another set of HttpHandlers living under ASP.NET. Here is some guidance for getting your current project set up to do this.

I encourage you to give it a try and see what you think. It will take a while to get used to the paradigm. It's not hard - just different. But I think once you're used to it, you'll like the separation of concerns, the easier testing, and the more natural flow for web development.

By natural flow, I mean embracing the world of GET and POST. I mean when you need to expose JSON, an RSS feed, or something else (XML, PDF, file, etc.), Controller Actions are ready to go. Stop writing custom HttpHandlers or fighting WCF configuration for this stuff. It should be simpler, and it is with Controller Actions and the right ActionResult.

Make it a goal to get some real-world MVC experience in 2010. Think of the kids on the MVC team and their beloved rec center. Don't let their dream die. They've come too far. And remember the tag line from Breakin' 2 - "If you can't beat the systembreak it!".

Setting default values for Kendo UI and DataTables controls

Mon, 01 Apr 2013 05:57:00 Z

Most JavaScript controls take a JSON object for their settings. Here's how you initialize a Kendo UI grid:

$("#myGrid").kendoGrid({
    pageable: true,
    sortable: { mode: "multiple", allowUnsort: true },
    filterable: true,
    dataSource: {
        data: myData,
        pageSize: 10
    }
});

And here's how you initialize a DataTables grid:

$("#myGrid").dataTable({
    "bSort": true,
    "bAutoWidth": false,
    "bProcessing": true,
    "bJQueryUI": true,
    "bPaginate": true,
    "bServerSide": true,
    "bSortCellsTop": true,
    "sPaginationType": "full_numbers",
    "iDisplayLength": 25,
    "aLengthMenu": [[5, 10, 25, 100], [5, 10, 25, 100]],
    "aaSorting": [],
    "sAjaxSource": "/Api/MyData",
    "sAjaxDataProp": "Data"
});

Both controls take an object literal with all the settings to style how the control looks, works, etc.

But look at all those settings! We have to set all that sorting and paging and filtering every time if we want non-default behavior? And what if we change our mind later and want to use virtual paging instead of page numbers or another application-wide change?

If there was only a way to centralize the common settings and reuse them with each call…

Reuse common settings

Here's a snippet of JavaScript to store common settings for a Kendo UI grid:

var kendoGridDefaults = {
    filterable: {
        pageable: true,
        sortable: { mode: "multiple", allowUnsort: true },
        filterable: true
    },
    nonFilterable: {
        pageable: true,
        sortable: { mode: "multiple", allowUnsort: true },
        filterable: false
    },
    extend: function (defaults, settings) {
        return $.extend(true, {}, this[defaults], settings);
    }
};

And here are some common settings for a DataTables grid:

var dataTableDefaults = {
    serverSide: {
        "bSort": true,
        "bAutoWidth": false,
        "bProcessing": true,
        "bJQueryUI": true,
        "bPaginate": true,
        "bServerSide": true,
        "bSortCellsTop": true,
        "sPaginationType": "full_numbers",
        "iDisplayLength": 25,
        "aLengthMenu": [[5, 10, 25, 100], [5, 10, 25, 100]],
        "aaSorting": []
    },
    extend: function(defaults, settings) {
        return $.extend(true, {}, this[defaults], settings);
    }
};

In both cases, you build up an object literal with with the common settings you want to reuse, then create an "extend" function (or another name, if you like) using the jQuery $.extend function, which merges your default settings with any new settings you pass in.

More than one set of common settings

You will likely have more than one set of reusable settings (server-side grid and client side grid, filterable and non-filterable grids, etc.). Just define new objects in your settings object. Above, I've got "filterable", "nonFilterable", and "serverSide" as property sets.

Usage

To take advantage of the default settings, call your control code and pass in the common settings object, then call the extend function with your overrides and/or additional settings:

$("#myGrid").kendoGrid(kendoGridDefaults.extend("filterable", {
    dataSource: {
        data: myData,
        pageSize: 10
    }
}));
$("#myGrid").dataTable(dataTableDefaults.extend("serverSide", {
"sAjaxSource": "/api/myData",
"sAjaxDataProp": "Data"
}));

This technique isn't limited to grids, or to Kendo UI or DataTables. It can be used with any controls that set their properties with a JavaScript object literal.

Sessionless MVC 3

Fri, 21 Jan 2011 01:40:25 Z

If you've done much ASP.NET development, you know you shouldn't use session for high performance web sites that require web farms and load balancers. You can centralize session to be on one web server or move it to the database, but what if you want to avoid it altogether?

MVC 3 introduces a new controller attribute called SessionStateAttribute. You can decorate your controller with this attribute to disable session, make it read-only, or turn it on for full read-write access. Note that TempData, which uses session to store values between requests, is also disabled if session is disabled. That makes sense, but since it's called TempData[] instead of Session[], it's not obvious.

Here's how you can use this on a controller. Note this attribute is at the controller level, not the action level.

using System.Web.Mvc;
using System.Web.SessionState;
namespace MvcApplication1.Controllers
{
[SessionState(SessionStateBehavior.Disabled)]
public class HomeController : Controller
{
public ActionResult Index()
{
ViewBag.Message = "Welcome to ASP.NET MVC!";
        return View();
    }

    public ActionResult About()
    {
        return View();
    }
}

}

And here's how you can set it as a Global Filter ~~to turn it off for all controllers. The attribute is being set in the RegisterGloablFilters method in the Global.asax and is called in Application_Start.~~

UPDATE: This doesn't work as a global action filter. However, you can turn off session for your whole application with code in your web.config like this:

<system.web> ... <sessionState mode="Off" /> ... </system.web>

Handling Exceptions in ASP.NET MVC

Sun, 23 Aug 2009 09:24:27 Z

Here is a quick run down of the various approaches for handling exceptions. I use a combination of these that I'll show at the end.

Try-Catch everywhere

You've seen this code before, right?

public void DoSomething() { try { var x = 1; } catch (Exception ex) { ShowExceptionToUser(ex.Message); } }

The approach of putting try-catch block around every ounce of code seems like a good idea intuitively. Sure, you're showing the user an ugly error message, but it's better than crashing the server.

But what is the user supposed to do with the information you show them? How are they supposed to fix your null reference exception?

The other knock on this approach is there is so much ceremony code!

Generic error page

This approach goes the other way with a generic error page displayed to the user for any unhandled error. It's easy to implement in the Web.config file, and the user never sees a null reference exception or stack trace.

Here's what I'm using:

<customErrors mode="RemoteOnly" defaultRedirect="~/Error"> <error statusCode="403" redirect="~/Error" /> <error statusCode="404" redirect="~/Error" /> </customErrors>

There are two problems with the generic error page approach. First, the user has no information about what happened. Maybe it's something they could have resolved? Maybe they should try again later? Just saying "Pardon our mess" doesn't give them any details.

Second, it doesn't give you any details either. The next time you talk to the user, they will tell you they got an error in your app. "Oh, what happened?" you'll ask.

"Uh, it was on that screen with the customer info. I forgot what I was doing, but it just showed the error screen, so I rebooted and went home for the day." Not much to go on. Something about the customer screen? This will be a fun one to try to reproduce!

Just log it

The last approach is to log all errors. You collect as much detail as you need. The date and time the exception was thrown, which user/IP address, which server they were on, the stack trace, etc.

Error logging can be extensive and can be stored in rolling text files or database tables. I prefer using the database so I don't need to grant write permissions to the ASP.NET process running that web app.

Here's an Application_Error event from a couple projects back:

protected void Application_Error(object sender, EventArgs e) { var ctx = HttpContext.Current; var ex = ctx.Server.GetLastError(); if (ex != null) { _logService.LogExceptionToDatabase(ex); } }

I've done lots of applications like this, where the Application_Error event in Global.asax calls into a logger like log4net or Enterprise Library to store exception details. It works great. You get the details you need to fix the bug.

But what about the user? What are the users looking at when this exception is thrown?

#3 Combo Platter

Today, I'm using bits and pieces of all of these.

I show the user a generic error page for all unhandled exceptions. It may not have much info, but something weird just happened in the app and I wasn't expecting it. I need more information about what happened so I can decide what needs to be done.

That's why I'm also using ELMAH to log all unhandled exceptions. The exception details get stored in my database and I even get a fancy exception viewer since ELMAH works as an HttpHandler. My favorite ELMAH feature is you can usually see the yellow screen you would have seen if running locally on your box.

Finally, sometimes there are handled exceptions. This is where an exception occurred before in the code (database is down, file not found, etc.), it might occur again, and I've got some thoughts about what to do next time it happens.

In my view, the only place you need try-catch blocks is when you are worried that an exception might happen and you want to give the user some information, give the user instructions, or silently fix the problem yourself. If I can't do one of these, I just show the "Oops" page try to come up with a plan later.

For instance, if the database is down, I'd tell the user to try again later, but I couldn't save their record right now. If the user is trying to upload a file and it's not there, they can try to correct the file upload input box and resubmit.

How to wire this up in ASP.NET MVC

Set up ELMAH

First, download ELMAH binaries, add a reference to the ELMAH assembly in your web project, and follow the instructions to get your Web.config set up correctly.

Now test out ELMAH. You should be able to browse to elmah.axd and see the list of exceptions. Try throwing one in your code somewhere and see if ELMAH logs it.

You can make the elmah.axd page secure, log to a database, etc.

Set up the Generic Error Page

Once ELMAH is logging, wire up your Web.config to show the generic error page:

<customErrors mode="RemoteOnly" defaultRedirect="~/Error"> <error statusCode="403" redirect="~/Error" /> <error statusCode="404" redirect="~/Error" /> </customErrors>

I'm using an Error controller with a single Index action so I can send the user to the root and to the Error route to show the error page. Here's the controller:

public class ErrorController : Controller { public ActionResult Index() { return View("Error"); } }

It's calling a view also called "Error" that is in ~\Views\Shared\Error.aspx. Make your version of that page. Remember, this is the page for unhandled exceptions.

Next, you need to register this route. I've moved my route registration out of my Global.asax, but if you have a default ASP.NET MVC install, look for your routing registrations in Application\_Start:

routes.MapRoute("UnhandledExceptions", "Error", new { controller = "Error", action = "Index" });

This is just setting up some defaults in the route to simplify redirects to the generic error page. At this point, you should be able to browse to any controller with a thrown exception in the action and see your generic error page displayed.

Set up the ElmahHandleError attribute

There's one step left! You've now got two ways of dealing with unhandled exceptions. We need to consolidate these so the generic page is show AND the ELMAH logging is called.

You know how you have to add the HandleError attribute to your controller classes to get the generic error page to appear? This attribute doesn't call ELMAH. This is by design, since the HandleError attribute is, well, handling the error. ELMAH is for unhandled errors and doesn't log otherwise.

But you can have it both ways and use ELMAH as your handled exception logging tool as well. Follow these steps to create an ElmahHandleError attribute and replace the HandleError attribute on your controllers with this new attribute.

That's it! You should be all set with an exception handling strategy.

Combining JavaScript bundling, minification, cache busting, and easier debugging

Mon, 18 Mar 2013 01:12:00 Z

ASP.NET MVC has had server-side bundling and minification for a couple versions now. You can use this to reduce HTTP requests from the client browser to the web server. This optimization is a must when you get lots of small JavaScript files, which is what most large web applications have these days.

Here's the default BundleConfig.cs in an MVC4 default project:

using System.Web; using System.Web.Optimization; namespace BundlingSample { public class BundleConfig { // For more information on Bundling, visit http://go.microsoft.com/fwlink/?LinkId=254725 public static void RegisterBundles(BundleCollection bundles) { bundles.Add(new ScriptBundle("_{/bundles/jquery").Include( "}/Scripts/jquery-.js")); bundles.Add(new ScriptBundle("~/bundles/jqueryui").Include( "~/Scripts/jquery-ui-{version}.js")); bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include( "~/Scripts/jquery.unobtrusive*", "~/Scripts/jquery.validate*")); // Use the development version of Modernizr to develop with and learn from. Then, when you're // ready for production, use the build tool at http://modernizr.com to pick only the tests you need. bundles.Add(new ScriptBundle("~/bundles/modernizr").Include( "~/Scripts/modernizr-*")); bundles.Add(new StyleBundle("~/Content/css").Include("~/Content/site.css")); bundles.Add(new StyleBundle("~/Content/themes/base/css").Include( "~/Content/themes/base/jquery.ui.core.css", "~/Content/themes/base/jquery.ui.resizable.css", "~/Content/themes/base/jquery.ui.selectable.css", "~/Content/themes/base/jquery.ui.accordion.css", "~/Content/themes/base/jquery.ui.autocomplete.css", "~/Content/themes/base/jquery.ui.button.css", "~/Content/themes/base/jquery.ui.dialog.css", "~/Content/themes/base/jquery.ui.slider.css", "~/Content/themes/base/jquery.ui.tabs.css", "~/Content/themes/base/jquery.ui.datepicker.css", "~/Content/themes/base/jquery.ui.progressbar.css", "~/Content/themes/base/jquery.ui.theme.css")); } }
}

This approach works well for 3rd party libraries (jQuery, jQuery validation, knockout, etc.), and it has a cache-busting hash in the URL that keeps you from caching an old version of the bundled and minified script in your browser.

Here you can see jquery and modernizr have a query string after the file name with the unique key:

So we've got bundling of scripts, minification, and cache-busting. What's not to love?

Where do I put my application scripts?

The default MVC project gives you a \Scripts folder. You could put your application scripts there. NuGet would like you to leave 3rd party scripts there, and it's the convention, but I prefer to move scripts I didn't write for the current app into a \Scripts\lib folder, and scripts for the app go in a \Scripts\app folder.

You'll have some moving around to do when you update a JavaScript via NuGet to get it in your preferred folder, but it's a little easier to find the stuff you'll really be working on for your app. You'll also need to update your BundleConfig.cs to point to the new \Scripts\lib folder.

So how to we bundle these app scripts? You could bundle them all in one file. Everything in that folder gets put in a "~/bundles/myApp" bundle. The problem is, you'll likely end up with lots of sequencing problems in the scripts and see "undefined" errors. This could work if you only have a small amount of JavaScript in your app, but it's not recommended.

You could also create a Razor section in the _Layout.cshtml and call it "scripts", then each view can list the scripts it needs to work in that Razor section. The default MVC4 _Layout.cshtml file already has this Razor section set up for you. This approach works, but now we're not bundling or minifying the JavaScript, and we don't have any cache busting going on with our app scripts.

So I have to debug minified files? Yuck.

The other drawback of using the built-in ASP.NET optimizations for bundling and minification is debugging minified files. You've probably dealt with this when your JavaScript throws an exception and you're in the middle of a jQuery file. JQuery almost certainly doesn't have a bug, but you sent it some values it wasn't expecting. Have fun sorting that out.

![[image_thumb_11.png](https://cdn.volaresoftware.com/images/posts/2013/3/image_thumb_11.png)

IE10 and Chrome have JavaScript pretty print tools that can make the minified script a little easier to read than one long line, but the variable names will all still be a, b, c, and whatever the minifier hadn't already used.

Using map files is a better way to go, and in Chrome, you turn this on in dev tools and click the gear at the bottom right, then check "Enable source maps".

Now each minified file can have a map file that points to the original, unminified source code. The built-in ASP.NET optimizations don't work with map files yet.

Web Essentials bundling to the rescue

If you are a Visual Studio web developer and you don't have Web Essentials, go get it now. You'll love it. It's a Visual Studio extension created my Mads Kristensen, who works for Microsoft for the Web Platform and Tools group.

One of the features is bundling and minification. You select the files you want to bundle, right click, then choose Web Essentials > Create JavaScript bundle file.

Name your bundle, and several files will be created. The first is the *.bundle file:

<?xml version="1.0" encoding="utf-8"?> <bundle minify="true" runOnBuild="true">  <file>/Scripts/app/script1.js</file> <file>/Scripts/app/script2.js</file> </bundle>

This file lists each script in the bundle and has flags for minify (default is "true") and runOnBuild (default is "true"). You may need to rearrange the order of the bundle files if there are functions defined in one file and called in another.

Any change you make to script1.js or script2.js, the *.bundle file, or building your app, will regenerate the files underneath the *.bundle file:

These three files are 1) the combined bundle without minification, 2) the bundle with minification, and 3) the map file for debugging the original script. The first is a giant concatenation of the two files and isn't that interesting.

The minified file looks like this:

function add(n,t){return n+t}function subtract(n,t){return n-t}function showMessage(n){alert(n)} //@ sourceMappingURL=myAppBundle.min.js.map

And the map file looks like this:

{ "version":3, "file":"myAppBundle.min.js", "lineCount":1, "mappings":"AAAAA,SAASA,GAAG,CAACC,CAAC,CAAEC,CAAJ,CAAO,CACf,OAAOD,CAAE,CAAEC,CADI,CAInBC,SAASA,QAAQ,CAACF,CAAC,CAAEC,CAAJ,CAAO,CACpB,OAAOD,CAAE,CAAEC,CADS,CCJxBE,SAASA,WAAW,CAACC,CAAD,CAAM,CACtBC,KAAK,CAACD,CAAD,CADiB", "sources":["/Scripts/app/script1.js","/Scripts/app/script2.js"], "names":["add","x","y","subtract","showMessage","msg","alert"] }

So the minified file gives the browser instructions on how to get to the map file, which gives the browser instructions on how to render in unminified, made-for-humans format.

Using the bundles

I create a bundle of app scripts for each view (usually I name it after the view, like register.bundle, login.bundle, etc.) and use the Razor "scripts" section in the _Layout.cshtml file to place those scripts at the bottom of the html, just before the closing tag. The script reference points to the minified file.

@section scripts { <script src="~/Scripts/app/myAppBundle.min.js"></script> }

In Chrome, the end result is this for the minified file:

And this for the mapped file:

This human-readable script can have breakpoints, etc. It looks like the original file, but the browser has not created new HTTP requests to pull down the originals. It's map file magic.

Setting up view-specific bundles seems lighter weight to me than always editing the BundleConfig.cs file, plus you get the mapping files. Now we just need to solve for the cache busting we lost with this approach.

Cache busting

Ever send your product owner to the CI web server to check out a new feature, only to have them tell you they got JavaScript errors on that page? Did you tell them to type CTRL-F5 to force a refresh of the page? If so, you have a caching problem where the browser is caching the file even though it has changed.

Mads has a blog post on cache busting that works well. It's based on getting the last changed date of the file and appending that date in ticks to the path of the request for the script or css. His solution involves having URL rewriting working on IIS.

In my case, I didn't want to mess with URL rewriting, so I went with the somewhat less optimal but simpler solution of using a query string instead. Here's my Razor helper:

using System.IO; using System.Web; using System.Web.Caching; using System.Web.Hosting; namespace BundlingSample.Extensions { public static class StaticFile { public static string Version(string rootRelativePath) { if (HttpRuntime.Cache[rootRelativePath] == null) { var absolutePath = HostingEnvironment.MapPath(rootRelativePath); var lastChangedDateTime = File.GetLastWriteTime(absolutePath); if (rootRelativePath.StartsWith("~")) { rootRelativePath = rootRelativePath.Substring(1); } var versionedUrl = rootRelativePath + "?v=" + lastChangedDateTime.Ticks; HttpRuntime.Cache.Insert(rootRelativePath, versionedUrl, new CacheDependency(absolutePath)); } return HttpRuntime.Cache[rootRelativePath] as string; } }
}

and how it's used in the Razor view:

@section scripts { <script src="@StaticFile.Version("~/Scripts/app/myAppBundle.min.js")"></script> }

and the resulting file name in the browser:

The query string pattern matches the built-in ASP.NET optimization pattern. I say this is sub-optimal because some page speed tools will fuss at you for using query strings. Google PageSpeed says, "Enabling public caching in the HTTP headers for static resources allows the browser to download resources from a nearby proxy server rather than from a remote origin server." I'm not too worried about that, but you'll want to use Mads' URL rewrite approach if you want a better PageSpeed score.

So there you have it. Bundling, minification, debugging, and cache busting when you need it!

Prefiltering a Kendo UI grid with an OData data source

Wed, 22 May 2013 23:28:00 Z

If you're using Kendo UI's grid, you know you can plug it into a Web API OData data source. The nice thing about using an OData end point is you don't have to parse all the possible filter values in your Web API code. You'd have to plan for column names, values, different operators, and'ing and or'ing of values, etc. Instead, with OData, just keep the data IQueryable, mark the method with a [Queryable] attribute, and you're all set.

But what if you want some client-side filtering to start off with? You could hack up the OData URL sent back to Web API, or you could set a filter on the grid's data source (extending the example here).

$(function () { var dataSource = new kendo.data.DataSource({ type: "odata", transport: { read: { url: "/api/Cats", dataType: "json" }, }, schema: { data: function (data) { return data["value"]; }, total: function (data) { return data["odata.count"]; }, model: { fields: { Id: { type: "number" }, Name: { type: "string" }, Color: { type: "string" } } } }, pageSize: 10, serverPaging: true, serverFiltering: true, serverSorting: true, filter: { field: "Color", operator: "eq", value: "black" } }); $("#grid").kendoGrid({ dataSource: dataSource, filterable: true, sortable: true, pageable: true, columns: [ { field: "Id" }, { field: "Name" }, { field: "Color" } ] });
});

See the "filter" setting on the data source? That will tell OData to search for /api/Cats/?<other OData stuff>&$filter=Color eq ‘black' on the URL (you will probably get a + symbol instead of a space from URL encoding). This URL stuff will become part of the query's where clause and filter your data. Since this is just a grid filter, your user can go in and edit it, clear it, etc.

But what if you have more complex filtering needs? What if you have multiple values or "or" logic instead of "and" logic?

filter: { logic: "or", filters: [ { field: "Name", operator: "contains", value: "fluffy" }, { field: "Color", operator: "eq", value: "black" } ] }

This will let you "or" your columns, so you are looking for Names containing "fluffy" or Colors equal to "black". The URL will look like /api/Cats/?<other OData stuff>&$filter=(substringof(‘fluffy',Name) or Color eq ‘black').

What if your filtering needs are more complex than this? What if you have both "and" and "or" logic you want to pass through to filter your OData?

filter: [ { logic: "or", filters: [ { field: "Name", operator: "contains", value: "fluffy" }, { field: "Color", operator: "eq", value: "black" } ] }, { logic: "and", filters: [ { field: "Active", operator: "eq", value: true } ] } ]

The grid's filter property is smart enough to handle more complex JavaScript objects thrown at it, as long as is matches the filter pattern. Take advantage of this to prefilter your grid data so those fancy OData queries don't send down values that aren't helpful for your end users.

Push to AppHarbor on every push to GitHub

Wed, 12 Oct 2011 00:40:07 Z

If you're using GitHub as your shared, online, git repository and you're using AppHarbor for continuous integration and deployment, you really have two git repositories – the GitHub one and the AppHarbor one.

AppHarbor instructions help you set up a remote to this git repository so you can push to it whenever you like, but that means you have two steps on most commits:

git push origin master

to push your code up to your GitHub repo, and:

git push appharbor master

to push your code up to the AppHarbor repo. Because AppHarbor doesn't support SSH yet (only HTTPS is supported now), you also have to enter your password. Not a giant hassle, but what if you could get rid of that last little bit of friction?

GitHub Service Hooks

GitHub Service Hooks run after a push to GitHub, and there is one to fire off your AppHarbor build/test/deploy. It's under your GitHub repo > Admin > Service Hooks.

Once you're there, the instructions are pretty simple.

Go to your application's main page on AppHarbor and find the "Create build URL". Example: https://appharbor.com/application/{application_slug}/build?authorization=

"token" is the value of the "authorization" parameter.

"application_slug" is your application's unique identifier.

If your GitHub repository is private you need to add the "apphb" GitHub user as a collaborator. This enables AppHarbor to download the source code.

Here's where you can find the values for steps 1-3 in AppHarbor:

Step #4 can be skipped if you have a public repo. If you're using private repos, add the "apphb" GitHub user to a GitHub team with "pull" grants.

All done!

Next time you do

git push origin master

your code will be pushed up to GitHub and AppHarbor will grab the latest code from GitHub (not from the AppHarbor repo anymore), build it, test it, and if the tests pass, deploy it. All in one step!

What's New in MVC 2?

Wed, 12 May 2010 04:00:00 Z

Thanks to all the folks who attended the South Colorado .NET User Group Visual Studio 2010 launch on May 6th. We went through a giant buffet of new things in Visual Studio, Entity Framework, SharePoint, Silverlight, and ASP.NET. Slides from my talk on the new features in MVC 2 can be downloaded here.

Big thanks also to Ben Hoelting for putting the event together. I liked the mini code camp format! It was a lot of info, but it was a great survey of most of the new features.

Faster Karma test runs that work in VSTS with Chrome headless browser

Mon, 12 Feb 2018 08:30:00 Z

Karma is a well known framework-agnostic test runner. It's the glue between your JavaScript tests and your test results.

Because Karma doesn't care what test framework, assertion library, or browser you use, configuration can be a bit of a headache. You have to specify everything.

Most examples I've seen use PhantomJS as a headless browser, and it works ok. But on my current project, we have 4,700+ JavaScript tests written with Jasmine. When I run those tests manually through Chrome using the Jasmine stock HTML test runner, the tests run in just over 15 seconds. When I run those same tests from the command line or the build server using Karma and PhantomJS, the tests run in about 1.5 minutes – much slower.

I was looking for something faster that would work well both locally and on the build server, and the new-ish Chrome headless browser sounded promising. After getting it set up and working, the Karma tests with Chrome headless as the browser now run in under 10 seconds. Yay!

Here's a step-by-step to getting it set up with the minimum configuration.

Installation

To install, first make sure you've got Node installed and then run:

npm install karma --save-dev

This installs karma for this project. Then:

npm install karma-cli -g

This installs the karma-cli globally for this computer. Next:

npm install karma-jasmine karma-chrome-launcher jasmine-core --save-dev

This installs common plugins we'll need for this project: karma-jasmine, karma-chrome-launcher and jasmine-core.

Next, we will install Puppeteer, an API for Chrome's headless browser. If you are not running your JavaScript tests on your build server, you can skip this step. I was able to get my local Chrome headless browser running without this, but I needed this installed for my build server, Visual Studio Team Services (VSTS).

npm install puppeteer --save-dev

Once puppeteer is installed for this project, it's time to configure things.

Configuration

You need to specify all the settings for Karma because it doesn't know anything about your project. It's like the opposite of zero-config - it's infinite-config.

Recognizing this, the Karma team came up with a bunch of simple questions to get most of what you need added to your config file. From the command line, run:

karma init karma.conf.js

Pick jasmine for the testing framework, no for RequireJS (unless you need that), Chrome for the browser (we'll adjust this later), and src/**/*.js and tests/**/*-tests.js for the source and test files (unless you prefer a different folder/filename pattern), and yes that we'll let the watcher keep an eye on file changes.

This is what mine looked like:

Next, open package.json in the project root and scripts section if you don't already have one at the top level.

"scripts": { "test": "karma start" },

This addition let's us run the tests from the command line with npm test or karma start. This is very helpful for build servers, like VSTS, which know about Node and npm, but not about Karma. Running npm test as an npm task on VSTS works nicely.

Write a sample test

We won't know if it's working until we write a test and see it fail and then see it pass. Let's do that now.

Add a new file under /tests named sample-tests.js. This file should get picked up by our glob pattern in karma.conf.js. Add this code to it:

describe("Testing Karma with Chrome headless", () => { it("Should work if configuration is correct", () => { expect(false).toBeTruthy(); });
});

You would never write this kind of test for a real project, but we just want to know if we've got everything working. This test should fail. Let's run it and see. From the command line, enter:

karma start

You should see a failing test like this.

You can use CTRL-C to break from the watch if you need to. Change the test so the assert is:

expect(true).toBeTruthy();

and save. As soon as you save the changes in the test file, the watcher should re-run the tests and you should see this.

If you don't have a passing test this point, go back and see if you missed a step or download from the GitHub repository and try running from that code.

Chrome Headless

When the tests run, Karma creates a web server, opens Chrome, and runs the tests using the Chrome browser. You can see it running. But we want the headless Chrome browser for speed and to keep that extra browser out of the way.

Use CTRL-C to cancel the watch Karma is running so we can kick it off again when we've made our changes. Open karma.conf.js and find the browsers section. Change it to:

browsers: ['ChromeHeadless'],

This is the token used to specify the headless (not visible) version of Chrome. There are a lot more browsers you can choose from.

Next, find the singleRun section and change it to:

singleRun: true,

and save. This is needed for your build server, or at least if your build server is VSTS.

Re-run with karma start. You should get similar results, with a passing test, but now it says the browser is HeadlessChrome. Also, the test stops and returns to the command prompt when completed instead of staying in watch mode.

![chrome_headless_thumb.png](https://cdn.volaresoftware.com/images/posts/2018/2/chrome_headless_thumb.png)

I don't really care for the watch running all the time on tests, as I prefer to run my tests manually, so I usually turn

autoWatch: false,

in karma.conf.js. I also don't like a lot of chatter in my test output, so I also set

logLevel: config.LOG_ERROR,

Now when I run the tests, I get just the last line from above. That's more like it!

All the code for this post can be found on GitHub.

SpecFlow isn't just a WatiN Wrapper

Wed, 05 Jan 2011 01:40:28 Z

I have been using SpecFlow with WatiN for about 9 months now. It's a great combination for driving the features you want in a web site and verifying they work as expected. SpecFlow takes care of the BDD framework and application features side, while WatiN drives the browser to verify behavior.

I've gotten used to the the pattern of writing a SpecFlow scenario, then writing the WatiN code in the step definition to open a browser and perform the task or look for the expected HTML. Once you get the hang of the tools and the process, it's a very sustainable workflow for the developer.

But today I ran into something that I couldn't test with WatiN. I wanted to check that an XML sitemap was coming up correctly on a web site. WatiN was able to open the XML document in the browser, but there was no Body tag because the XML is not an HTML document, so WatiN couldn't read the XML. All I needed to do was verify that an expected value was in the XML sitemap. If the value was found, the test would pass.

I spent about 15 minutes trying out different WatiN commands to find the text, but with no Body tag, there was nothing loaded into the WatiN object model, so nothing was working. I also tried looking through the WatiN Elements collection and a few other dead ends, but it was only showing me the previous web page or null.

Finally, the obvious answer occurred to me. I'm looking at an XML document and I want to verify that it has a value in it. I'm in a SpecFlow step definition and I've got the entire .NET framework at my disposal, not just WatiN. Five minutes later, I've got it coded to load and examine an XDocument for the value I needed so the test can pass.

This was a good lesson for me. Being on a development workflow roll is no excuse to not keep your head up for alternative strategies that would better solve your problem. SpecFlow isn't just a wrapper for WatiN calls. It can be used to verify any behavior it can invoke.

Fix for Cisco AnyConnect hanging on Hostscan is waiting for the next scan

Wed, 11 Mar 2020 13:34:00 Z

Welcome Coronavirus work-from-home folks trying to get their Cisco AnyConnect VPN working! I wrote this article about a year and a half ago but have recently refreshed it.

If solution below still works for you, please leave a comment below. Thanks, and happy social distancing! :)

TL;DR

If you use Fiddler to watch network traffic on your computer, it creates personal certificates that interfere with Cisco AnyConnect VPN.

Inside Fiddler, choose Tools > Fiddler Options > HTTPS.

Click the certificate maker. Click "Clear server certificates on Exit.".

You may have to reboot to clear memory, but you should be able to use your VPN normally after that.

Backstory

I use Cisco AnyConnect to connect to a client's VPN. Lately, it started hanging with the status message "Hostscan is waiting for the next scan".

The logs show a loop that lasts a little over 10 minutes where it scans and starts over until it finally gives up.

9:42:46 AM Hostscan state idle 9:42:48 AM Hostscan is waiting for the next scan 9:43:50 AM Hostscan is performing system scan 9:43:51 AM Hostscan is performing software scan 9:43:58 AM Hostscan state idle 9:44:00 AM Hostscan is waiting for the next scan 9:45:03 AM Hostscan is performing system scan 9:45:04 AM Hostscan is performing software scan 9:45:19 AM Hostscan state idle 9:45:22 AM Hostscan is waiting for the next scan 9:46:24 AM Hostscan is performing system scan 9:46:24 AM Hostscan is performing software scan

I read something about removing personal certificates helping with this, but I only have a few personal certificates, and they are my machine name, localhost, local development, and something NVIDIA put on there.

Solution

But then I read something else about personal certificates in IE11. Sure enough, under Tools (or the gear icon) > Internet Options > Content there is a button for Certificates.

After clicking that, I saw something very different from the machine certificates. They were there, plus some other certificates for local development, but there were HUNDREDS like *.somewebsite.com.

I sorted by the name, selected them, and removed them. Then I tried Cisco AnyConnect again, and it finally connected.

The wildcard certificates I saw in the IE11 Internet Options were created by Fiddler, which I use to watch network traffic and inspect web requests and responses. Fiddler acts as a proxy between your computer and your internet connection, and I guess it creates a personal wildcard certificate for every site you visit, or when Dropbox syncs, or your email does a send/receive, etc.

Since I must use Cisco AnyConnect for the VPN and I only use Fiddler sometimes, I removed the wildcard certificates and uninstalled Fiddler and I've been able to connect to the VPN reliably for a week now.

Stop wasting time with enums in C#

Sun, 12 Apr 2020 04:29:00 Z

Enums in C# can make you code easier to read:

private enum Status { Awesome = 1, Cool = 2 }; public void Sample() { var lego = new Lego(); lego.Everything = Status.Awesome; if (lego.PartOfTeam == true) { lego.Everything = Status.Cool; }
}

But enums don't cross in and out of C# easily.

Have you ever tried to save an enum to SQL? It becomes an int and you're right back to, "Wait, what does a Status of 2 mean again?".

It's easy convert the enum to a string before sending it to SQL, but then you have to convert it back to an enum in C# when you read it in, and that code is gross:

public string ConvertEnumToString(Status status) { return status.ToString(); }
public Status ConvertStringToEnum(string status) { return (Status) Enum.Parse(typeof (Status), status); }

What about sending the value down to the client in JSON? Again, by default you get an int that looses the point of having the enum in the first place.

That is, unless you want to add enum converters from Json.NET to your JsonSerializer to turn them into strings:

serializer.Converters.Add(new Newtonsoft.Json.Converters.StringEnumConverter());

That's not so bad. Plus, what's the alternative?

The simplest alternatives are primitive types that convert across all layers, like ints and strings. I prefer strings so I can immediately know what the value represents and code around that (e.g., the Status is "Cool" instead of 2).

"But this is using magic strings, and those are bad." Maybe. But 1) everyone likes magic, and 2) what's the risk?

That you mistype the string? There is type-safety risk, but it's a mild one and only applies to C#. Let's say you're in JavaScript and looking for that status of "Coll" instead of "Cool". That code will fail. How long until you figure that out? You'll have tests and/or run the code yourself and see it doesn't work, right?

Also, if you work with a dynamic language, you know you can type in any nonsense and your compiler won't help you. It's up to you to test it. I see magic strings the same way. Yes, you might make a mistake the compiler doesn't catch, but that's why we test our code.

What about the risk that the value changes in the future. Let's say management decides that statuses of "Awesome" are too strong. They want you to change all occurrences of "Awesome" to "Good" throughout the app. What's the damage here?

Well if you have C# enums, you change Status.Awesome to Status.Good everywhere, then you update you SQL data so old records are correct (only needed if you converted the enum values to strings before storing them), then you update your JavaScript so it doesn't look for or branch on the wrong string (again, only needed if you serialized your C# enums to strings).

If you didn't use enums at all, and just used strings in C#, you would have the same SQL and JavaScript updating to do, but maybe more C# strings to find/replace throughout the project. But I don't think you can reasonably say that's a lot more work. Maybe a few minutes more?

On top of that, what's the risk that enums change in the future like this. It's not zero, but it's really low. Enum values should be immutable and usually represent the type or state of something, so enum values don't change their meanings very often.

So why go to the trouble to store C# values in a special type that SQL and JavaScript can't work with? A magic string is just as easy to read as the enum, and it works up and down the stack.

Here's the original code, but with magic strings instead of enums. I don't think it loses any clarity:

public void Sample() { var lego = new Lego(); lego.Everything = "Awesome"; if (lego.PartOfTeam == true) { lego.Everything = "Cool"; }
}

Concerns with this approach

This post has generated a lot of comments! It's been a good discussion on the tradeoffs of using C# enums. Some people have agreed with me that it is simpler to use magic strings because they work across languages.

Some have worried about database space used storing strings vs. ints. Strings do take up more disk space, but I'd argue we're living in the age of not worrying about that, so take advantage of it. Others have pointed out databases can sort, index, and pull ints faster than strings. If storage costs or milliseconds matter in your situation, you'll need to factor that in.

Others have agreed with the point that enum conversions can be messy, but think I've gone too far with magic strings everywhere. The consensus with this crowd seems to be maybe skip enums, but at least use C# static classes. I like this, and that's what I'm doing these days:

public static class Status { public const string Awesome = "Awesome"; public const string Cool = "Cool"; } lego.Everything = Status.Awesome;

Still others want their C# enums just like they are and don't mind converting in JavaScript and SQL if needed.

It's up to you to decide what makes the most sense for your project.

Using CRM auto filtering in custom reports with complex SQL

Mon, 14 Feb 2011 01:40:20 Z

Report prefiltering in Microsoft CRM 4.0 is a very cool feature - when it works. The normal ways of setting up this auto filtering feature in your custom CRM reports are 1) special aliases, and 2) SQL strings.

Special aliases

The alias approach is the simplest one to use. If you have a report that needs prefiltering, change your SQL from this:

select firstname, lastname from FilteredContact

to this:

select firstname, lastname from FilteredContact AS CRMAF_FilteredContact

The trick is the alias. All you need to do is add an alias with CRMAF\_ in front of the view name, and CRM will rip out your SQL at report runtime and replace it with a custom SQL statement. I think the acronym must stand for CRM Auto Filter. By using a special alias CRM recognizes, the actual SQL run on your server will be similar to this, where contacts are prefiltered for city = 'Denver'.

select firstname, lastname from (select contact0.* from FilteredContact as contact0 where address1_city = 'Denver') AS CRMAF_FilteredContact

SQL strings

The other route you can go is mash together SQL strings and get a parameter from CRM that is the prefilter SQL statement. You've probably done this kind of this kind of thing before:

declare @sqlstring varchar(max) set @sqlstring = 'select firstname, lastname from (' + @CRM_FilteredContact + ') AS MyFilteredContacts ' exec (@sqlstring)

This really isn't bad when you have a small SQL statement, but you probably wouldn't need to create a custom CRM report if it was a simple SQL statement, right? The CRM users could create their own simple report inside CRM for that.

When the SQL statement gets complex, you have quote and string bugs. When the SQL gets lengthy, you can't have over a certain number of characters in the SQL string or you have to split it and you end up with:

exec (@sqlstring1 + @sqlstring2 + @sqlstring3)

You can get it to work, but it's pretty yucky.

The problem

I much prefer the alias approach. It's much easier to read, and the aliases are not too much trouble to add in and get prefiltering in CRM for free.

The problem is, the alias technique breaks down when the queries get more complex or you need multiple datasets in your report using the same prefiltering. Here are the cases I've found and the workarounds.

Dataset based on a union query

If you have a query with a union statement, like:

select firstname, lastname from FilteredContact AS CRMAF_FilteredContact where address1_city = 'Denver' union select firstname, lastname from FilteredContact AS CRMAF_FilteredContact where address1_city = 'Highlands Ranch'

CRM will do the alias filtering trick, but only for the first select. The second select in this query will not be filtered at all.

The fix I've come up with uses SQL temp tables. Maybe not the best approach, but I had a lot of reports that were not auto filtering as expected, and this has worked so far:

select * into #FilteredContact from FilteredContact AS CRMAF_FilteredContact select firstname, lastname from #FilteredContact where address1_city = 'Denver' union select firstname, lastname from #FilteredContact where address1_city = 'Highlands Ranch'
drop table #FilteredContact

This let's CRM do what it wants to, and swaps out your SQL where it finds the CRMAF\_FilteredContact alias the first time. It also let's you leave the rest of your SQL pretty much intact.

Dataset based on multiple queries selecting into a temp table

I had another query that was suffering the same problem, but this query was a little different. I needed the data displayed in columns, so I created a temp table and populated it with selects. There were multiple selects in the query filling up the columns in this temp table. Everything ran great without auto filtering.

But with auto filtering, the same thing happened. The first select statement got filtered. The ones after that were untouched. The fix I used was the same. I created a temp table, populated it with the auto filtered data, then selected off that temp table throughout.

To be a good TempDB citizen, I dropped the temp table at the end of the query. SQL Server does the temp table drop for you when the table is out of scope, but it helps to have the drop statement in there when testing the query in SQL Server Management Studio and running it multiple times in the same query window.

Reports with multiple datasets

This technique works if you have a complex query that needs auto filtering. But what if you have multiple datasets in your report, and they all need to be auto filtered?

In one report, the queries were very similar. I had two datasets that were identical expect one used report parameter A and one used report parameter B. This was to compare two funnels for two different time periods. Auto filtering worked fine on the first dataset and funnel, but didn't do anything on the second dataset or funnel.

The fix in this case was to create one dataset that didn't filter on either report parameter A or parameter B. Then in the report, have the funnel controls themselves do the filtering based on the report parameters. Most SQL Server Reporting Services data controls have a filter property. I've never really used them before now, since it almost never makes sense to pull all the data from the database and then filter inside the report. I'd rather filter on the database first. However, in this case, the control filters helped and I got the result I wanted because there was one dataset with one CRMAF\_ alias.

On another report, there were three charts built using three different datasets. The datasets were the same except for the group by clause. I was able to use the same approach and condense these to one dataset with no group by clause, then do the grouping in the chart controls. Again, it made me feel a little bad that the data wasn't already summed and grouped when it got to the chart control, but at least it was working.

REST-like behavior with MVC instead of WCF

Mon, 08 Mar 2010 01:40:57 Z

WCF is a very cool framework for adding an abstraction layer over your services. You can have .asmx, .svc, and now, REST URLs with no extension. These endpoints can even return JSON to the caller, which is useful if you're using jQuery or another JavaScript library.

The knock on WCF? The configuration story! It's getting better in WCF 4, which is scheduled for release in a month or so. It will have a bunch of defaults so you don't have to be as explicit in your config file. Finally, some convention over configuration in the WCF space! Now someone needs to create a fluent, code-based configuration tool for the exceptions to the default conventions…

Don't be afraid of JSON!

But if you need to return JSON to a caller today, you don't need scary WCF config files to do it. You can get the same URL and the same data payload with a lot less hassle using MVC controller actions.

The steps are:

Create a new action in a controller.

Grab your data or whatever you want to return.

Parse your data to JSON.

Throw it back out to the requestor.

The trick is to use JsonResult as the return type for your controller action and convert your output to a JSON string with the base controller's Json method:

public JsonResult GetAllDepartments() { var departments = _repository.GetAllDepartments(); return Json(departments); }

Now if I browse to this controller action (I'm using the HomeController in this example):

<u>http://localhost/Home/GetAllDepartments</u>

I get a pop-up to save the response stream, which I can open with Notepad:

[{"Name":"Human Resources"},{"Name":"Accounting"},{"Name":"IT"},{"Name":"Pencil Sharpening"}]

Yeah, JSON! And there was no gory config setup needed!

Using jQuery with JSON

Now we can use jQuery in the MVC view to take advantage of this returned JSON.

Here's a view that has a button and a div tag. jQuery is being used to tie the button click to a call to the controller and action we set up above. It then gets the JSON coming back, loops through it, and puts it in the div tag so it's visible to the user.

<script src="../../Scripts/jquery-1.3.2.min.js" type="text/javascript"></script> <script type="text/javascript"> $(function() { $("#btnShowDepartments").click(function() { $.getJSON("/Home/GetAllDepartments", null, function(data) { for (item in data) { var department = data[item]; $("#divDepartments").append(department.Name, ", "); } }); }); }); </script>
<p> <input id="btnShowDepartments" type="button" value="Show Departments" /> <div id="divDepartments"></div> </p>

This is probably not the best jQuery in the world. I'm still new to it. But the point is to show that you can put a URL in, parse the JSON, and use the data however your app needs it.

Is ASP.NET relevant to modern web development?

Mon, 29 Dec 2014 05:04:00 Z

ASP.NET has a new version coming out soon. ASP.NET vNext will have a new project file management system (long overdue) and a lot of integration points with modern front-end web development tooling, like Grunt and Bower.

I'm a web developer, and all of the back-end systems I work with are Microsoft based (ASP.NET MVC and Web API, SQL Server, Azure, etc.). I must be super excited about this new stuff coming soon, right?

Nah, not really.

Like most web developers, I spend a lot of time in HTML5 and CSS3 and tons of time in JavaScript. I spend most of my energy getting front-end libraries to work together, making web pages responsive, dealing with cross-browser and cross-device issues, and debugging with browser tools. Over the last several years, MVC, Web API, and even SQL Server have been less a part of my day-to-day coding, so changes and new versions matter less to me.

Just another back end?

If you are a front-end web developer, you need your AJAX request to hit a back-end endpoint and give you a response. That kind of framing of the back-end, that it can be encapsulated or black-boxed, also means its implementation could be changed and you wouldn't really care. Why should it matter if the back end is written with node.js, Ruby on Rails, Java, Azure Mobile Services, or ASP.NET? From the front-end web developer perspective, I just want a response. Obviously, it needs to be fast, scalable, robust, secure, and that kind of thing, but all major server-side frameworks have that figured out.

It seems to me that back-end tooling is becoming a commodity. Here's what I mean. Quick - which cloud provider is the best one? I don't know. Aren't they all about the same? Maybe they have different SLAs, or broader or narrower service offerings, but just to get a web app running with a database, they are all about the same. If one was $5/month cheaper, wouldn't you switch to them? Unless the support or extra services or the hassle of changing cloud providers were worth an extra $5/month to you, you'd switch.

I think of ASP.NET and SQL Server the same way. It's back-end tooling. It involves maybe 10-25% of my coding week. I'm not dissatisfied with the tools. I just don't use them that much. I guess they could get a little better, but that won't make me need to use them more or care more about how they are implemented.

I don't send view models down with my MVC views anymore. I just let MVC serve up a view-model-less view and let JavaScript and AJAX calls go get anything else the page needs. This means the initial page loads fast, but it doesn't fully work until the JavaScript has finished putting everything in its place.

Once you start spending a lot of time in JavaScript and pulling in data with AJAX, and you have to write it that way so the user can interact with the page, then why write it twice with 1) the Razor-template-populated-with-initial-view-model way, and 2) the HTML-template-populated-with-AJAX-data way? Writing the same functionality with two templating languages and two data sources isn't going to get your project done faster or reduce maintenance costs.

Plus, the user gets to see most of the page, just maybe without all the data yet or with empty drop downs while the data is still on its way to the page. I think that gives the user a sense that we're getting you the parts of the page as soon as we can, instead of building everything up on the server as one big ball of templated data while you look at a white, empty browser window.

So why not just dump the whole thing and code HTML, CSS, and JavaScript with any old text editor?

Where does the Microsoft ecosystem add value in modern web development?

IDE

In spite of its limitations for front-end development, Visual Studio is still a very good IDE. Different colors for keywords and navigation within and across files is very good. But most of the value I get from continuing to use Visual Studio is a result of the Web Essentials extension. It's nice to run JSHint with every save and to get pointers in the IDE about CSS rules, potential browser issues, and unclosed HTML tags. If I switched to Notepad, I'd be giving up some things that really do make my coding day a little brighter.

Working with the current Visual Studio project system has been more than just an annoyance; it's been a source of real pain. Looks like the new project/file system may help in vNext.

I can't say that Intellisense is very useful to me these days. It's never really worked right with JavaScript. Maybe that will get a little better, but I've gotten used to it pulling up every JavaScript symbol when I type ".".

Local Web Server

Simple and unobtrusive, IIS Express is a great place to test run your web app, and the integration with Visual Studio is limited but sufficient.

The alternative would be HTML files that you double click to open and debug in the browser. It would work, but you'd have to keep you file system and text editor open all the time, and you wouldn't have server-side debugging of your API layer.

Security

Security is probably the main thing that has kept me from dumping ASP.NET and using HTML files instead. I've never worked on a web app where security wasn't important. You need a way to know who's knocking on the server's door, and when that request is bouncing around on the back-end servers, you need to know what group/role that user is in so you can turn features on and off.

I still use MVC and Web API for their security, and I'm glad their namespaces are finally going to be merged in vNext. That means I won't have any more code that filters MVC requests one way and Web API requests another way.

API layer

Web API is totally relevant for modern web development. All web apps need a way of interacting with a back end, and Web API sets up as a simple, thin transport layer so you can do whatever back-end stuff you need to do on the server. Content negotiation is nice if you have a public API, but I've only written internal APIs that send/receive JSON.

Conclusion

I guess I am looking forward to some of the improvements in ASP.NET vNext.

If I was building a new web app today, would I use ASP.NET as the back end? Probably, but it would be the same way I've used it the last 4-5 years: minimal MVC page serving, an API service layer, and a security layer.

The most interesting, highest customer value web development stuff is happening on the front end, and I don't see that changing anytime soon.

Working with the latest JavaScript syntax on your project today

Tue, 03 Apr 2018 05:17:00 Z

Are you working in an existing code base with tons of ES5 JavaScript, and you're jealous of your friends working on greenfield projects using ES6/ES7/ES8+ or ES2015/ES2016/ES2017+ JavaScript? Here's how we moved our code base forward to start using newer features of JavaScript without losing our minds.

I've made a sample project using the ASP.NET MVC default project (and removing some of the noise). You can see all the code if you want to follow along or fork this on GitHub.

Install NPM packages

First, install node and npm, then install webpack and Babel from the command line in the web project root.

npm install --save-dev babel-core babel-loader babel-preset-env npm install --save-dev webpack webpack-cli

When you are done, you should have a devDependencies section in your package.json file, also in the web root, that looks something like this. You will almost certainly have different versions, and you will probably have more than just this in your devDependencies section, and that's fine.

"devDependencies": { "babel-core": "^6.26.0", "babel-loader": "^7.1.4", "babel-preset-env": "^1.6.1", "webpack": "^4.4.1", "webpack-cli": "^2.0.13" }

Set up Visual Studio

The plan is to leave old JavaScript files with the *.js extension and create new ES2015+ JavaScript files with the *.es6 extension. You can use *.es2015 or any other extension not already in use if you prefer. We just need some file marker so webpack knows which files need Babel transpilation and which don't.

In Visual Studio, you'll need to set up this new extension to use the JavaScript editor. You can do that in Tools > Options > Text Editor > File Extension. If you skip this step, Visual Studio will treat *.es6 like text files instead of JavaScript files.

Configure webpack and Babel

Let's set up the webpack.config.js file in the web root to work with the newer JavaScript syntax.

Below, the resolve section tells webpack we are using these two extensions for JavaScript files, and webpack should be looking for both *.js and *.es6 files when making bundles.

The rules section tells webpack that it needs to use Babel to load *.es6 extension files. There are a lot more Babel options you can add here. For example, want to use async/await in your *.es6 files? Add a Babel plugin for syntax-async-functions.

The isRelease flag is used to toggle between development and production settings for the build. This is using webpack 4's new mode setting, which should set up most things correctly. The devtool option uses either a quick and dirty source map or a more production-ready one.

const path = require("path");
module.exports = env => { const isRelease = env === "RELEASE"; return { mode: isRelease ? "production" : "development", devtool: isRelease ? "source-map" : "cheap-module-source-map", entry: { index: "index.es6", about: "about.js" }, output: { filename: "[name].js", path: path.resolve(__dirname, "dist"), publicPath: "/dist" }, resolve: { extensions: [".js", ".es6"], modules: ["Scripts", "node_modules"] }, module: { rules: [ { test: /.es6$/, exclude: /(node_modules)/, use: { loader: "babel-loader", options: { presets: ["env"] } } } ] } }; };

Single-Page vs. Multi-Page applications

In the entry section above, I've got two values for the two pages in this sample. index will be built using the index.es6 file as an entry point, and about will be built using about.js as the entry point. If your whole app is a SPA, you will have just one entry. If you have a multi-page application, you'll need an entry for each page. Webpack crawls the entry to bundle up all the dependencies.

We are outputting our files to a /dist folder. For simplicity, the file name will be the entry name plus ".js".

Scripts

We needs some scripts to test out the different JavaScript syntax styles.

Here is index.es6, using the new JavaScript import and templated string options.

import $ from "jquery";
$("#setInCode").text(This value was set in code using jQuery at ${new Date().toLocaleString()}.);

And here is about.js, using older AMD-style modules and ES5 style JavaScript.

define(["jquery"], function($) { $("#setInCode").text("This value was set in code using jQuery at " + new Date().toLocaleString() + "."); });

These scripts both find an element with jQuery and set some text to it and add the date/time. We want something simple to test if our pages are working with both old and new-style JavaScript.

Script references

Since I'm using a boilerplate ASP.NET MVC project template, the _Layout.cshtml file already has:

@RenderSection("scripts", required: false)

Each page, such as Index.cshtml and About.cshtml will then reference the built-by-webpack scripts in the /dist folder with. Index.cshtml will reference /dist/index.js, and About.cshtml will reference /dist/about.js like this.

@section scripts { <script src="/dist/index.js"></script> }

Build it

So we've got our npm packages installed, the webpack.config.js file is set up, our pages call our webpack-built scripts in the/dist folder . Let's run it and test it out.

Add a new section for scripts to your package.json file:

"scripts": { "build": "webpack --colors --watch", "build:release": "webpack --colors --env RELEASE" },

This allows us to run npm build and npm build:release as shortcuts for running webpack commands. You can name the commands anything you like.

The options show colors in the console, and for the build script, it sets up a watch on the files to re-run the build if anything changes. You'll want to use this for development. For the build:release script, we pass in —env RELEASE so the webpack.config.js script knows we want the build optimized for production.

You can also add another section to package.json to link up these build commands to the Visual Studio Task Runner Explorer.

"-vs-binding": { "ProjectOpened": [ "build" ] },

This will run your new build command when the project opens. Since it keeps a watch running, that should be all you need to development.

For production, you'll want to stop the build task and manually run the build:release task in the Task Runner Explorer (or run it from command line, or as a before/after build script for your ASP.NET project, or on your build server…).

Run it

Run the web app after the build command completes and you should be able to browse to the Index and About pages and see the jQuery execute in both pages the same way, even though the syntax for importing jQuery was very different for each page.

Debug it

Note we are referencing index.js in Index.cshtml and not the source code file name index.es6. That's because we're not referencing the source code. We're referencing the webpack built code in the /dist folder.

Don't worry. You can still set breakpoints and watches and debug with your favorite browser dev tools when referencing the built code through source maps. When opening a file, look for the one served by webpack://. It will be the original source code seen through the source map. The other file will be the bundled/minified one.

Now what?

If you are on a project that isn't using the newer JavaScript syntax and features, talk with your team. Chances are good they would like to be using the new stuff, too.

You don't need to wait until you get put on a new project. You can start coding with the latest JavaScript syntax today, but still keep backward compatibility for your project's ES5 script.

Deploying Reports Built with SSRS 2008 R2 to SSRS 2008 non-R2

Mon, 19 Mar 2012 00:40:02 Z

I've got SQL Server 2008 R2 Express installed on my primary development machine, and I create SSRS reports on this box. The problem is, I've got one customer with SQL Server 2008. And yes, Microsoft changed the RDL file format between SSRS 2008 and SSRS 2008 R2, so SSRS 2008 can't read SSRS 2008 R2 RDL files.

So how you you get around this without setting up VMs with both? It's not elegant, but here's what I do:

On your SSRS project properties with all your reports, change the Target Server Version to SQL Server 2008 (and not SQL Server 2008 R2).

Get your local dev box SSRS R2 server running if it's not already.

Deploy the report project to your local SSRS R2 server.

Go to your report management site (usually http://localhost:Reports) and download the report. This will save out the RDL for you.

Now when you deploy this report to the non-R2 SSRS server, it will be the correct, non-R2 format!

The crucial steps are setting that Target Server Version and deploying. That's where the Visual Studio report project converts the RDL file to the format you need it to be. After that, the downloading is just a way to get a copy of the report in the non-R2 format.

Now you can deploy the RDL to the customer's non-R2 SSRS server, without changing your dev box.

Moving a VM to another machine

Tue, 17 Nov 2009 01:41:16 Z

I've got a work laptop with a VMware virtual machine. But I wanted to move it to my slightly faster personal rig, with the nicer keyboard, mouse, dual monitors, etc.

So I shut down the VM on the work laptop and copied it over to the personal machine. Then I downloaded and installed the VMware Player to the new machine, copied the VM to it, and opened it up. I got a prompt asking if I "moved" or "copied" the VM. I chose "copied".

The VM spun for a little while, and then there was some gibberish message about VT being possible but disabled on the host. VT = Vermont? VT = Virginia Tech? VT = WTF? I did what professional developers are trained to do in these situations. I ignored it and clicked OK.

The VM said "Windows in Loading Files." but it kept rebooting over, and over, and over.

I got a tip from David Yack to check the BIOS settings. I have a Dell Latitude, so your mileage may vary here, but in my BIOS settings, I go to Post Behavior, then Virtualization, then set it to Enabled, then save settings and reboot.

That worked!

A quick look at NDepend

Tue, 04 Sep 2018 04:00:00 Z

NDepend is a Visual Studio extension designed to help you improve your code quality and reduce your technical debt. It sells for €399 per developer, which is about $462 U.S.

I gave it a try a very small project and a very large project. You open your project in Visual Studio, point NDepend at it, and wait a minute or so for the reports.

NDepend spits out a lot of reports and a lot of metrics, from dependency graphs to tree maps with hot spots showing too much cyclomatic complexity in red.

Here are the small project application metrics:

NDepend gives some basic counts and rule and quality checks, but the most interesting data is the technical debt. Here, both apps get an "A", but they have 3.69% and 4.81% tech debt. This didn't print out as nicely on my projects as the demo report from NDepend shown below.

Here you can see the estimated time to bring your tech debt up a letter grade, from a C to a B, is 14 days and 2 hours. The estimated annual interest on your tech debt is 47 days, and that's up 17 days and 4 hours from the last time the analysis was run.

When you drill into the errors and warnings NDepend shows you, you can also see the cost of fixing or leaving that tech debt. Here is one of the rules I broke in my project with a class that has too many methods (48!). In this case, it's a test class, so I'm not worried about it. Neither is NDepend, since it estimates this tech debt will cost me 4 minutes and 13 seconds a year.

If you want to tackle your tech debt but don't know where to start, NDepend can help you asses where your project is today, show your progress, and help you decide which tech debt is most costly and needs to be addressed soonest.

Adding and styling dynamic content in jQuery Mobile pages

Wed, 11 Jan 2012 01:39:56 Z

jQuery Mobile does great job styling your web app to look kind of like a native phone app.

It injects lots of classes like "ui-link", "ui-content", "ui-listview", "ui-shadow", etc. to make your page look pretty.

But if you're using jQuery to dynamically load content from another source on document ready, jQuery Mobile is already done with its styling changes. I searched and found lots of suggestions for refreshing the styles in the new section of the page, but .page(), .page("refresh"), and .trigger("enhance") didn't add the styles. You can see people struggling with this question.

I finally found the answer in this blog post:

$(function () { $("#dynamicSection").load("/api/dynamicContent", function () { $(this).trigger("create"); }); })

Using Kendo UI grid with Web API and OData

Tue, 19 Feb 2013 13:48:00 Z

The Kendo UI grid is a snazzy little thing:

The grid works natively with OData, but the examples from the Kendo team are of OData services driven by WCF back ends. I wanted to get the grid working with Web API and minimal coding to implement server-side sorting, filtering, and paging.

Until earlier this week, if you wanted to do that, you were on your own. There was a partial OData implementation in Web API via a NuGet package, but it didn't support $inlinecount, which is what the grid needs to know how many items there are total (e.g., the $inlinecount for the grid above is 830).

A more fully supported Web API OData implementation was rolled out this week and is available via NuGet. Here are the steps to get it working with a Kendo UI grid.

Server side

Open your existing Web API project and install the Web API OData NuGet update:

Decide what data you want to send to the browser and model it. I've got a Cat entity and a Dog entity:

namespace KendoGridWebApiOdata.Models { public class Cat { public int Id { get; set; } public string Name { get; set; } public string Color { get; set; } } }
namespace KendoGridWebApiOdata.Models { public class Dog { public int Id { get; set; } public string Name { get; set; } public string Color { get; set; } } }

Update your WebApiConfig.Register() method (in the App\_Start folder):

using System.Web.Http; using System.Web.Http.OData.Builder; using KendoGridWebApiOdata.Models; namespace KendoGridWebApiOdata.App_Start { public static class WebApiConfig { public static void Register(HttpConfiguration config) { var modelBuilder = new ODataConventionModelBuilder(); modelBuilder.EntitySet<Cat>("Cats"); modelBuilder.EntitySet<Dog>("Dogs"); var model = modelBuilder.GetEdmModel(); config.Routes.MapODataRoute( routeName: "OData", routePrefix: "api", model: model ); config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); // Uncomment the following line of code to enable query support for actions with an IQueryable or IQueryable<T> return type. // To avoid processing unexpected or malicious queries, use the validation settings on QueryableAttribute to validate incoming queries. // For more information, visit http://go.microsoft.com/fwlink/?LinkId=279712. config.EnableQuerySupport(); // To disable tracing in your application, please comment out or remove the following line of code // For more information, refer to: http://www.asp.net/web-api config.EnableSystemDiagnosticsTracing(); } }
}

You'll define the OData models you want to expose and set up special OData routes for them. You can add multiple EntitySets to the model builder as needed for your OData endpoints. Here, I'm adding Cat and Dog to the model builder.

The MapODataRoute uses the model builder values to create an OData route. Note this is not exactly a Web API route, but you can use the same /api/{controller} convention if you like (or /odata/{controller} if you prefer) by setting the routePrefix to whatever you like.

I tried toggling config.EnableQuerySupport on and off, and it worked in both cases, so I don't know if that matters any more after the Web API OData update.

For more details about what is going on here, check out Youssef Moussaoui's blog post.

Finally, you'll need a controller, but this isn't a Web API controller, it's an ODataContoller. That's kinda close, and it inherits from the Web API controller, but it's specifically designed for the OData calls you just set up in routing.

using System.Linq; using System.Web.Http; using System.Web.Http.OData; using FizzWare.NBuilder; using KendoGridWebApiOdata.Models; namespace KendoGridWebApiOdata.Controllers { public class CatsController : ODataController { [Queryable] public IQueryable<Cat> Get() { return BuildTestData(); } private IQueryable<Cat> BuildTestData() { return Builder<Cat> .CreateListOfSize(100) .Build() .AsQueryable(); } }
}

Here, I've got a CatsController inheriting from the ODataController. I also have a [Queryable] attribute over the Get() action method. This is another piece you supposedly need, and this was used in the older version of the Web API OData NuGet package, but I found my grid worked whether the attribute was on there or not. You will likely want to leave it as a place to lock down incoming requests, since this is where you can disallow certain query parameters, limit records returned, etc.

The BuildTestData() method is using NBuilder to crank out 100 Cat entities and pretend like it's queryable.

Test it out

That should do it for the server side. Let's test the route setup and see if we get data back. I like using the Chrome plugin Advanced REST Client, but since we're testing GET requests, you can also just type the URL in your browser.

For the URL /api/Cats, the JSON coming back looks like:

{ "odata.metadata": "http://localhost:56126/api/$metadata#Cats", "value": [ { "Id": 1, "Name": "Name1", "Color": "Color1" }, { "Id": 2, "Name": "Name2", "Color": "Color2" }, ...]}

To add some OData parameters to the URL, let's try /api/Cats?$inlinecount=allpages. Now the JSON has odata.count for the $inlinecount value:

{ "odata.metadata": "http://localhost:56126/api/$metadata#Cats", "odata.count": "100", "value": [ { "Id": 1, "Name": "Name1", "Color": "Color1" }, { "Id": 2, "Name": "Name2", "Color": "Color2" }, ...]}

See how the records are coming across in the value array? We'll need that and the odata.count to help the grid know how to parse this JSON.

Client side

The HTML for the grid is minimal:

<div id="grid"></div>

And the JavaScript isn't bad:

$(function () { var dataSource = new kendo.data.DataSource({ type: "odata", transport: { read: { url: "/api/Cats", dataType: "json" }, }, schema: { data: function (data) { return data["value"]; }, total: function (data) { return data["odata.count"]; }, model: { fields: { Id: { type: "number" }, Name: { type: "string" }, Color: { type: "string" } } } }, pageSize: 10, serverPaging: true, serverFiltering: true, serverSorting: true }); $("#grid").kendoGrid({ dataSource: dataSource, filterable: true, sortable: true, pageable: true, columns: [ { field: "Id" }, { field: "Name" }, { field: "Color" } ] });
});

In the dataSource variable, we're setting the type as odata. Seems like that would be enough, but you have to also set the read transport's dataType to "json" or your request will go to the server like /api/Cats?$callback=jQuery183021786115039139986_1361332885733&$inlinecount=allpages&$format=json&$top=10. This is a JSONP request. We want the $callback and $format parameters to go away, and setting the dataType to "json" does that and sets the request's Accept headers to "application/json".

There is also some extra stuff going on in the schema section. Normally, this is where you tell Kendo UI what your data types are so it can sort and filter correctly. Here, we've added data and total to pull the values out of the JSON response so the grid needs can render correctly. The data function is returning the value from the JSON we saw above, and the total function is returning the odata.count.

The rest of the dataSource properties are to force things to be done server side and to set the page size. The remainder of the JavaScript is firing up the grid with this dataSource and setting properties of the grid.

When you run this, you get a Kendo UI grid working with server-side OData. In this case, only 10 records are sent per request instead of the 100 Cat records we created on the server. The OData handling works with sorting, filtering, and paging on the grid.

If you get it running on your machine, check the XHRs to see the OData query string parameters getting added to the request and the response coming back with just the records requested.

Other nifty things

You can hit a URL to get the schemas of the entities you can query with /api/$metadata. You'll get back some XML like this:

<?xml version="1.0" encoding="utf-8" ?> <edmx:Edmx Version="1.0"> <edmx:DataServices m:DataServiceVersion="3.0" m:MaxDataServiceVersion="3.0"> <Schema Namespace="KendoGridWebApiOdata.Models"> <EntityType Name="Cat"> <Key> <PropertyRef Name="Id" /> </Key> <Property Name="Id" Type="Edm.Int32" Nullable="false" /> <Property Name="Name" Type="Edm.String" /> <Property Name="Color" Type="Edm.String" /> </EntityType> <EntityType Name="Dog"> <Key> <PropertyRef Name="Id" /> </Key> <Property Name="Id" Type="Edm.Int32" Nullable="false" /> <Property Name="Name" Type="Edm.String" /> <Property Name="Color" Type="Edm.String" /> </EntityType> </Schema> <Schema Namespace="Default"> <EntityContainer Name="Container" m:IsDefaultEntityContainer="true"> <EntitySet Name="Cats" EntityType="KendoGridWebApiOdata.Models.Cat" /> <EntitySet Name="Dogs" EntityType="KendoGridWebApiOdata.Models.Dog" /> </EntityContainer> </Schema> </edmx:DataServices> </edmx:Edmx>

If you are worried about exposing your data online, read up on OData Security Guidance.

Limitations

URLs are case sensitive. If you browse to /api/Cats, you get data. If you browse to /api/cats (lower case C), you get a 406 error.

Kendo UI grid allows sorting by more than one column, but the current Web API OData implementation doesn't seem to support it.

Download

You can download the code for this project from GitHub.

Convert callback JavaScript to async/await

Sun, 09 Dec 2018 11:40:03 Z

If you've done much JavaScript, you've run into the .done() and .then() callback functions, where your code is executed AFTER an asynchronous call completes.

Here, myFunction(myParams) calls makeXhrCall(myParams), an asynchronous XHR API call (the most common type of asynchronous call you will run into). The .then() function waits for the XHR call to complete. When it does, the XHR call returns data, which is used inside the .then() function to call another function, doSomething(data). The result of the doSomething(data) call gets returned out to whoever called the outer function when it's done.

myFunction(myParams) { return makeXhrCall(myParams) .then(data => doSomething(data) ); }

The key thing is, you are using .then() as a hook to do more work when the asynchronous call completes.

For a while now, you've been able to use async/await syntax as a way to treat asynchronous functions as synchronous, meaning no code AFTER the XHR call executes until the line with the await has completed executing.

If you are new to JavaScript, it can be confusing that making asynchronous calls leaves other lines of code UNDER that asynchronous call executing while the asynchronous call is still running. Changing to async/await makes your code clearer because each step is followed in top-down sequence.

async myFunction(myParams) { const data = await makeXhrCall(myParams); return doSomething(data); }

The async keyword tells JavaScript, "this code is going to use await at least once". Then you add await right before the asynchronous call. Now the data won't have a value until the XHR completes, and doSomething(data) won't run until the line with the await has finished putting a value in data.

Comparison of Typemock Isolator and Rhino Mocks

Fri, 16 Oct 2009 00:41:21 Z

I just started a new project using Typemock Isolator. It's a new tool for me, and since I've mostly used Rhino Mocks, my learning is from the perspective of "how do you do this with Rhino Mocks". These are the differences I see so far.

General

Typemock Isolator is a commercial product. Rhino Mocks is free and open source. Here's the Typemock pricing.

Typemock Isolator can mock just about anything, including not normally mockable things like private methods, static methods, and sealed classes. Rhino Mocks has traditional mocking from an interface, abstract class, etc. There has been some hand-wringingabout whether or not Typemock was too powerful and encouraged untestable software designs. But I think it's uncommon to create a brand-new stand-alone project, at least in enterprise development. So you're probably dealing with at least some code that wasn't written with testing in mind. You can wrap those static classes and create new default constructors and all kinds of OO jujutsu. Or you can just leave it alone and mock it as-is with Typemock.

With Typemock Isolator, everything starts with "Isolate" call. That's hard to beat for simplicity and discoverability. You can also use the AAA style syntax. Rhino Mocks also has AAA style testing in the newer versions. But there has been some confusion (at least in my mind) over the main entry points, like MockRepository.GenerateMock<ISomeClass>() and MockRepository.GenerateStub<ISomeClass>(). Once you understand it, you're all set, but it's kind of a stumbling block for people new to Rhino Mocks.

OK, let's move on to other syntax differences. I grouped these by AAA style (arrange, act, assert). Since the "act" step should be invoking your system under test, the frameworks should look the same there. They differ in the setup syntax (arrange) and the verify syntax (assert).

Arrange Syntax

Simple mocking

For simple mock objects, Typemock uses this syntax:

// Arrange var repository = Isolate.Fake.Instance<IContactRepository>(); var contact = new Contact(repository);
// Act contact.DoSomethingThatUsesARepository();

as compared to the Rhino Mocks syntax:

// Arrange var repository = MockRepository.GenerateStub<IContactRepository>(); var contact = new Contact(repository);
// Act contact.DoSomethingThatUsesARepository();

Not much here. Just different ways to do the same thing.

Argument handling

Method call arguments are ignored by default in Typemock, so you don't have quite as much setup to get to the system under test. You still need to put the correct type in the argument, but it can be null, string.Empty, 0, etc.

With Rhino Mocks, you have to be explicit when arguments don't matter:

theClass.Expect(x => x.theMethod(null)).IgnoreArguments();

or you can use the newer, more readable but maybe more typing Rhino Mocks syntax:

theClass.Expect(x => x.theMethod(Arg<theArgument>.Is.Anything));

In Typemock, you use this syntax:

Isolate.WhenCalled(() => theClass.theMethod(theArgument)).WithExactArguments();

only if the arguments are important to you.

So you can ignore arguments or use specific arguments with either framework. They differ on the default setting.

Unmockable mocking

In Typemock, you can also ignore calls on "live" methods (real instances, not fakes, stubs, or mocks) with:

Isolate.WhenCalled(() => theClass.theMethod(theArgument)).IgnoreCall();

The only way to not call into live code with Rhino Mocks that I'm aware of is to use a stub. This is the traditional testing approach that injects a stubbed dependency into the class under test.

So let's assume I need to test a Contact class method that does some stuff and then sends an email using EmailService, but I don't want an email to actually go out. Here's the Typemock arrange and act:

// Arrange var emailService = new EmailService(); var contact = new Contact(emailService); Isolate.WhenCalled(() => emailService.SendContactInfoToSales(contact)).IgnoreCall();
// Act contact.DoSomethingThatSendsAnEmail();

And the Rhino Mocks arrange and act:

// Arrange var emailService = MockRepository.GenerateStub<IEmailService>(); var contact = new Contact(emailService);
// Act contact.DoSomethingThatSendsAnEmail();

For the Rhino Mocks approach, my EmailService has to be mockable. Again, you can write code to do that, and in this sample I am using an interface to EmailService to do that. But with Typemock, you just tell the test to ignore that call. You don't need to write more code to make the EmailService test-friendly.

Suppose EmailService is in some company-owned assembly you have to use and it's a sealed class. Yes, you can wrap it with an interface, but why not just tell it to skip email sending with Typemock. That's pretty powerful. You can focus on the new code you want to test instead of refactoring existing code you don't really care about but are dependent on.

Simulating Exceptions

Another cool Typemock thing you can do is force existing code to throw an exception so you can test the robustness of your code. What if I want to make sure my new code works OK if the mail relay is down on that legacy, sealed EmailService:

Isolate.WhenCalled(() => emailService.SendContactInfoToSales(contact)).WillThrow(new SmtpException());

You can do the same thing in Rhino Mocks. Again, just different syntax:

emailService.Expect(x => x.SendContactInfoToSales(contact)).Throw(new SmtpException());

I think you would still need to have a mock on an IEmailService to do this with Rhino Mocks. The Typemock advantage is that it can work around that sealed class.

Assert Syntax

Simple verifications

The interaction testing assert syntax for Rhino Mocks is:

// Assert emailService.AssertWasCalled(x => x.SendContactInfoToSales(null), opt => opt.IgnoreArguments());

And for Typemock:

// Assert Isolate.Verify.WasCalledWithAnyArguments(() => emailService.SendContactInfoToSales(null));

This is just to test that the code got to that line/made that call internally. If you want to verify it got there and arrived with your expected arguments with Rhino Mocks:

// Assert emailService.AssertWasCalled(x => x.SendContactInfoToSales(expectedContact);

And with Typemock:

// Assert Isolate.Verify.WasCalled(() => emailService.SendContactInfoToSales(expectedContact));

So again, both frameworks can get you either assert type, just with different syntax.

Wrap up

The promise of Typemock Isolator is less time refactoring code that isn't on your roadmap and less setup to get to your system under test. I've focused here mostly on the arrange syntax for that reason.

Rhino Mocks can do most of the stuff Typemock can, except for the private, sealed, and static testing. Some would argue that you shouldn't test that code or if you need to make it testable, you should refactor it anyway.

Maybe. But it's also pretty appealing to keep your coding and tests focused on your project mandate, too.

Optimizing JavaScript and CSS files using RequireJS and R.js in an ASP.NET MVC app

Thu, 29 May 2014 00:39:26 Z

In my previous blog post, we discussed setting up RequireJS for a multi-page ASP.NET MVC app.

The code for the reference app is on GitHub, and when run, it shows us loading seven JavaScript files (409 KB) and four CSS files (31.1 KB):

We know we can reduce the number of HTTP requests, and reduce network traffic, if we can load fewer files and smaller files at run time.

There are several ways to do this bundling and minification: use MVC's built in tools, use Web Essentials, or use r.js, the tool that comes with RequireJS. The advantage of the later is you can let RequireJS, which is already tracking your dependency graph, decide which files should be bundled together for a specific page.

You can also use r.js to bundle ALL the scripts in your project together, and for a single-page app, that may make sense. But for a multi-page app, you want to have a common set of scripts you need on most pages, and an a la cart bundle for each page. We'll focus on the later here.

Prerequisites

You'll need to download r.js, which comes in the RequireJS nuget package, and you'll need a local version of Node running.

You'll also likely want to do this optimization only in Release mode, so be sure your project has a Debug and a Release build config.

What to bundle for JavaScript?

Here are the JavaScript files we have to work with:

We want page-level bundles, so we can load require.js, then main.js (including common libraries and kickoff.js), then main-currentDateTime.js and anything it needs that we haven't already loaded.

I usually name the main-*.js file as the name of the main MVC view or controller/action being pulled up on the screen. Theses main-*.js files are the entry point for firing up the JavaScript for just that page.

What to bundle for CSS?

We have three CSS files we can combine and a main.css file that references them:

The main.css file uses import statements for the three style sheets:

/* 3rd party stylesheets */ @import url("lib/bootstrap.css"); @import url("lib/bootstrap-theme.css");
/* Application stylesheets */ @import url("app/site.css");

This is usually a no-no for web development, because now there is a fourth style sheet, and a fourth HTTP request as the browser loads main.css, then turns around and loads the three style sheets it wants us to load. In this case, I think it's fine since this will be the way it works in Debug mode when you are working locally. When you go to Release mode, everything in main.css will be bundled and combined into one file.

Now change the link in the _Layout.cshtml file to point to main.css:

<link href="~/Styles/main.css" rel="stylesheet" />

TIP: Be sure your CSS files are listed in main.css in the order in which you want them to override, with your app styles at the bottom. The last ones listed will take precedence.

Setting up r.js, build-scripts.js, build-styles.js

I created an App_Build folder at the solution level. Call yours anything you like. The point is, this is stuff for building the project, not part of the code that is deployed when running the app.

I added the r.js file and two other JavaScript files with build config settings. One is for the JavaScript code and one is for the CSS.

The JavaScript config file, "build-scripts.js", looks like this:

({ appDir: "../Scripts", dir: "../Scripts-Build", baseUrl: "app", mainConfigFile: "../Scripts/main.js", paths: { main: "../main" }, keepBuildDir: false, modules: [{ name: "main", include: [ // These JS files will be on EVERY page in the main.js file // So they should be the files we will almost always need everywhere "domReady", "jquery", "jqueryValidate", "jqueryValidateUnobtrusive", "bootstrap", "moment" ] }, // These are page-specific bundles, usually named main-* { name: "main-currentDateTime", exclude: ["main"] } ], onBuildRead: function (moduleName, path, contents) { if (moduleName === "main") { return contents.replace("Scripts", "Scripts-Build"); } return contents; } })

Most of the paths are relative to the r.js file. The appDir is the main folder, so the appDir plus the baseUrl is the /Scripts/app folder. The dir setting is where you want the built scripts to go. The mainConfigFile is the path to main.js.

The first argument in the modules section is all the code you want rolled up into main.js. These are files used on almost every if not every page. The next argument in modules is each page file. Here, you need to manually add each page of your app where you want bundling. I've only got one page/bundle listed here. RequireJS will inspect that main-*.js file, and its dependencies, and their dependencies, and so on, but it will exclude files already bundled into main.

For example, the main-currentDateTime module uses "jquery". That file is already included in main.js in these build instructions, so it won't be bundled into main-currentDateTime.

The onBuildRead stuff is for swapping out paths in the built scripts. More on that down below.

The CSS config file, "build-styles.js", looks like this:

({ keepBuildDir: false, optimizeCss: "standard", cssIn: "../Styles/main.css", out: "../Styles-Build/main.css" })

The main configuration settings as the cssIn folder, where the code to bundle comes from, and the out folder, where it's going.

In both cases, we're outputting to new folders that are cleaned out on every Release build, /Scripts-Build and /Styles-Build.

Bundling and minifying on Release build

Open the web project Properties and select Build Events. In the Pre-build event command line, add:

if $(ConfigurationName) == Release node "$(ProjectDir)App_Build\r.js" -o "$(ProjectDir)App_Build\build-scripts.js" if $(ConfigurationName) == Release node "$(ProjectDir)App_Build\r.js" -o "$(ProjectDir)App_Build\build-styles.js"

Note the call to execute r.js with Node. You must have Node set up in your Paths on your machine for this to work. Now the build scripts will run every time the build is executed in Release mode.

Change your build configuration to Release mode and build the app. If it worked, the output window should show:

1>------ Build started: Project: RequireJSWithMVC, Configuration: Release Any CPU ------ 1> 1> Tracing dependencies for: main 1> 1> Tracing dependencies for: main-currentDateTime 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/app/currentDateTime.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/app/kickoff.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/app/main-currentDateTime.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/bootstrap.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/domReady.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/jquery-2.1.1.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/jquery.validate.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/jquery.validate.unobtrusive.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/moment.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/lib/require.js 1> Uglifying file: C:/RequireJSWithMVC/Scripts-Build/main.js 1> 1> main.js 1> ---------------- 1> app/kickoff.js 1> main.js 1> lib/domReady 1> lib/jquery-2.1.1.js 1> lib/jquery.validate.js 1> lib/jquery.validate.unobtrusive.js 1> lib/bootstrap.js 1> lib/moment.js 1> 1> app/main-currentDateTime.js 1> ---------------- 1> app/main-currentDateTime.js 1> 1> 1> C:/RequireJSWithMVC/Styles-Build/main.css 1> ---------------- 1> C:/RequireJSWithMVC/Styles/lib/bootstrap.css 1> C:/RequireJSWithMVC/Styles/lib/bootstrap-theme.css 1> C:/RequireJSWithMVC/Styles/app/site.css 1> C:/RequireJSWithMVC/Styles/main.css 1> 1> RequireJSWithMVC -> C:\RequireJSWithMVC\bin\RequireJSWithMVC.dll ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

r.js does a nice job of reporting back what it's done. Here, you can see it traces dependencies, minifies (uglifies) every JavaScript file, then it reports the files it bundled for main.js, main-currentDateTime.js, and main.css.

You should be able to show hidden files in Visual Studio and see the new folders and their files. Open them up and look at the minification changes

Dealing with paths with MVC Helpers

So great! We've got the files we want in /Scripts-Build and /Styles-Build. Unfortunately, our code is still pointing to /Scripts and /Styles. We can fix this with some MVC Helpers.

Looking at our _Layout.cshtml, we'll need to fix the path to the stylesheets and the path to require.js,:

<!DOCTYPE html> <html> <head> … <link href="~/Styles/main.css" rel="stylesheet" /> </head> <body> … <div class="container"> @RenderBody() </div> <script src="/Scripts/lib/require.js"></script> @RenderSection("scripts", required: false)
</body> </html>

Here's the C# for the stylesheet and scripts PathHelpers.cs:

using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class PathHelpers { public static string ScriptsPath(this HtmlHelper helper, string pathWithoutScripts) { #if (DEBUG) var scriptsPath = "_{/Scripts/"; #else var scriptsPath = "}/Scripts-Build/"; #endif return VirtualPathUtility.ToAbsolute(scriptsPath + pathWithoutScripts); } public static string StylesPath(this HtmlHelper helper, string pathWithoutStyles) {
#if (DEBUG) var stylesPath = "_{/Styles/"; #else var stylesPath = "}/Styles-Build/"; #endif return VirtualPathUtility.ToAbsolute(stylesPath + pathWithoutStyles); } } }

Now our _Layout.cshtml can be update to this:

@using RequireJSWithMVC.Extensions <!DOCTYPE html> <html> <head> ... <link rel="stylesheet" href="@Html.StylesPath("main.css")" /> </head> <body> ... <div class="container"> @RenderBody() </div> <script src="@Html.ScriptsPath("lib/require.js")"></script> @RenderSection("scripts", required: false)
</body> </html>

We still need to fix the paths within each page. They still point to the /Scripts folder and need to point to /Scripts-Build in Release mode. Let's do that by updating our RequireJsHelper.cs from the last post:

using System; using System.Text; using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class RequireJsHelpers { public static MvcHtmlString InitPageMainModule(this HtmlHelper helper, string pageModule) { var require = new StringBuilder(); #if (DEBUG) var scriptsPath = "_{/Scripts/"; #else var scriptsPath = "}/Scripts-Build/"; #endif var absolutePath = VirtualPathUtility.ToAbsolute(scriptsPath); require.AppendLine("<script>"); require.AppendFormat(" require([\"{0}main.js\"]," + Environment.NewLine, absolutePath); require.AppendLine(" function() {"); require.AppendFormat(" require([\"{0}\", \"domReady!\"]);" + Environment.NewLine, pageModule); require.AppendLine(" }"); require.AppendLine(" );"); require.AppendLine("</script>"); return new MvcHtmlString(require.ToString()); } }
}

Both of these helpers rely on the compiler flag for debug. If you don't like that, you could always branch off an Environment key in appSettings in your web.config or something.

Now when the page is loaded for this app, we have three scripts and one stylesheet, so we've gone from eleven HTTP requests to four. Furthermore, the files requested are much smaller after the minification, and we've gone from 440.1 KB to 223.3 KB total. You could get that down even more if you removed all the license info from the minified JavaScript in the build-scripts.js config with "preserveLicenseComments: false".

Finally, your users' browsers should cache most of these files after landing on any page on your site. The files require.js, main.js, and main.css will be the same for each page. Then the user's browser only needs to download the JavaScript for each newly browsed page.

Sessionless MVC without losing TempData

Thu, 30 Jun 2011 15:32:00 Z

I've blogged before about making your MVC controllers sessionless. The knock on sessionless controllers is that TempData is off the table because it uses Session as its data store.

If you see the TempData name and dismiss it, thinking it's another dictionary like Session[] and ViewData[] and you're waaaay past that since your mister type-safe, take another look. The neat thing about TempData is that it lasts for one more page load and then "poof" - it's gone. It self destructs as soon as it has been read.

Sure, it's a dictionary with magic string keys, but it's a great place to store message like "Your changes were saved" when you redirect to another page.

So how do we get the benefits of TempData as an ephemeral application message store, but go all-in on the web farm with sessionless controllers?

Cookies!

I can hear you groaning. Cookies are old school! They can't hold much information! They aren't secure!

Fine, don't put much in there, and don't put your secret fried chicken recipe in there. We're just going to use this as a little string to tell the user everything is OK or it's not OK.

TempData uses a provider model for the data store, and Session is the default data store. But you can get a cookie data store, CookieTempDataProvider, with Mvc3Futures NuGet package:

This should work as a TempData provider, but now it has to be wired into the application. Here's how you can do that:

public class BaseController : Controller { protected override ITempDataProvider CreateTempDataProvider() { return new CookieTempDataProvider(HttpContext); } }

Don't mock HttpContext

Thu, 19 Aug 2010 10:40:00 Z

HttpContext doesn't like to be mocked!!

It's so easy to take a direct dependency on HttpContext and not even realize it. If you're in the code behind in Web Forms or in a controller action in MVC, it's just right there, tempting you to use it to access session variables, application security, etc.

But don't.

Some little known facts about HttpContext:

HttpContext is the largest object ever created by humans.

If you printed out the code for everything in HttpContext, the pages could be stacked end to end to wrap around the Earth's equator 7 times.

Mocking HttpContext is like trying to calculate the last digit of pi. There is always a little more to it.

Chuck Norris gave up trying to mock HttpContext. He was deep in HttpContext.Response and quit, curled into a ball on the floor, and started whimpering.

Sealed what? Object reference what?

Let's say you've got some MVC security stuff you're trying to work with in a controller action. You've got code like:

public class OrderController : Controller { [Authorize] public ActionResult Process() { if (User.IsInRole("Admin")) { return View("SecretAdminStuff"); } return View("NotAuthorized"); }
}

See that User.IsInRole() code? That call is really to HttpContext.Current.User.IsInRole(). You just took the bait and are tied to HttpContext now.

So what? You have to use HttpContext to get that information, right? Sure, but you don't want to be tied directly to it or you've created untestable code.

Let's try a couple tests to verify the branching in this action method is returning the correct view based on the user's role. I'm using NUnit, Rhino Mocks, and the Should assembly below. Rhino Mocks has .Stub() and .Return() extension methods to set the expected return values for whether the user is or isn't in the Admin role.

[Test] public void Should_return_NotAuthorized_view_when_not_Admin_user() { // Arrange var mockContext = MockRepository.GenerateMock<HttpContext>(); mockContext.Stub(x => x.User.IsInRole("Admin")).Return(false); var orderController = new OrderController(); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("NotAuthorized"); } [Test] public void Should_return_SecretAdminStuff_view_when_Admin_user() { // Arrange var mockContext = MockRepository.GenerateMock<HttpContext>(); mockContext.Stub(x => x.User.IsInRole("Admin")).Return(true); var orderController = new OrderController(); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("SecretAdminStuff");
}

As soon as we run the tests we see "System.NotSupportedException: Can't create mocks of sealed classes". Oh yeah, HttpContext is sealed. That won't work.

Hmmm. Aren't there some new classes in System.Web.Abstractions for just this kind of thing? Let's change HttpContext

var mockContext = MockRepository.GenerateMock<HttpContext>();

to HttpContextBase

var mockContext = MockRepository.GenerateMock<HttpContextBase>();

and see if that helps.

The new problem is: "System.NullReferenceException: Object reference not set to an instance of an object." Mocking HttpContextBase isn't helping because the test isn't passing the mock context into the controller. Every call in the action method to User.IsInRole() will always call the real HttpContext, which isn't created because the test is not running in the ASP.NET process.

You can get around this with Typemock Isolator, which goes beyond mocking and can intercept the next call to HttpContext.Current.User.IsInRole() and swap out a result, but isn't there a simpler way to do this without buying another product or waiting for better abstract classes to work with?

A better way

We can't test something tied to HttpContext like this. We need another approach. The one I favor is wrapping the calls we care about, delegating out to the untestable code in the wrapper class, then passing an interface to the wrapper class into the constructor of the class using it.

Here's the wrapping class I've created to access a few HttpContext current user values and the interface for the wrapping class:

public class CurrentUser : ICurrentUser { public virtual string Name() { return HttpContext.Current.User.Identity.Name; } public bool IsLoggedIn() { return HttpContext.Current.User.Identity.IsAuthenticated; } public bool IsGuest() { return HttpContext.Current.User.IsInRole("Guest"); } public bool IsAdmin() { return HttpContext.Current.User.IsInRole("Admin"); } }
public interface ICurrentUser { string Name(); bool IsLoggedIn(); bool IsGuest(); bool IsAdmin(); }

Now I need to update the controller to inject this dependency into the constructor so it can be mocked, and use a private field set in the constructor for subsequent calls to _currentUser:

public class OrderController : Controller { private readonly ICurrentUser _currentUser; public OrderController(ICurrentUser currentUser) { _currentUser = currentUser; } [Authorize] public ActionResult Process() { if (_currentUser.IsAdmin()) { return View("SecretAdminStuff"); } return View("NotAuthorized"); }
}

Now we've got a testable action method. I mock the CurrentUser with MockRepository.GenerateMock<ICurrentUser>, set its return value with the Rhino Mocks .Stub() and .Return() extension methods, and check for the expected results:

[Test] public void Should_return_NotAuthorized_view_when_not_Admin_user() { // Arrange var mockCurrentUser = MockRepository.GenerateMock<ICurrentUser>(); mockCurrentUser.Stub(x => x.IsAdmin()).Return(false); var orderController = new OrderController(mockCurrentUser); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("NotAuthorized"); } [Test] public void Should_return_SecretAdminStuff_view_when_Admin_user() { // Arrange var mockCurrentUser = MockRepository.GenerateMock<ICurrentUser>(); mockCurrentUser.Stub(x => x.IsAdmin()).Return(true); var orderController = new OrderController(mockCurrentUser); // Act var result = orderController.Process() as ViewResult; // Assert result.ViewName.ShouldEqual("SecretAdminStuff");
}

Hey, wait a sec

If you're thinking to yourself: I've just tested the code in the action method and not whether HttpContext really works, you're exactly right. The tests should cover the branching in the controller action and are unit tests. They are not integration tests that check to see if HttpContext is returning the right values.

I'm OK with that tradeoff. I know HttpContext works. It's been around forever and it's in a System.<something> namespace, so I shouldn't be testing it.

The real question is, do my login and roles and authorization settings work as expected in my application. That calls for integration testing, and the easiest way to do that is click through those screens and see if it's working. You can also automate this clicking around with Watin, or SpecFlow (which uses Watin internally to drive the browser).

Which IoC container should I use?

Sat, 10 Oct 2009 00:41:32 Z

This came up on the Alt.Net Yahoo Group/mailing list today. There are tons of tools out there for inversion of control. They have been compared here and other places online. Nobody wants their app tied to the Betamax of IoC tools, so people are anxious to pick the best one.

All containers keep a hash table of your interfaces mapped to your concrete classes. Most will let you request a specific instance with a string token. Most will let you control instance creation (singleton, etc.). The popular IoC containers have fluent configuration and use conventions to figure out that IEmailService maps to EmailService.

So which one should you pick? Go with the one you already know best and/or the one that is easiest for your dev team to configure. That's because with the Common Service Locator wrapping your IoC get instance calls, the provider becomes a moot point.

This is an old OO principal - encapsulate the stuff that can change. Jeremy Miller pointed out the need for a common IoC wrapper to do just this. Today's hot new open source IoC container could be tomorrow's dormant project. If you wrap the calls, you can rip out your IoC provider and most of your code stays the same since it's calling the wrapper.

Here's how I'm doing this using Castle Windsor in a Sharp Architecture project. First, I create a class to wire up my IoC configurations for my app.

public static class RegisterIoCContainer { public static void AddComponentsTo(IWindsorContainer container) { AddApplicationConcernsTo(container); AddCoreConcernsTo(container); } private static void AddApplicationConcernsTo(IWindsorContainer container) { container.Register(Component .For<IMappingEngine> .Instance(Mapper.Engine) .LifeStyle.Singleton); container.Register(AllTypes.Pick() .FromAssemblyNamed("MyApp.ApplicationServices") .WithService.FirstInterface() .Configure(c => c.LifeStyle.Transient)); } private static void AddCoreConcernsTo(IWindsorContainer container) { container.Register(AllTypes.Pick() .FromAssemblyNamed("MyApp.Infrastructure") .WithService.FirstNonGenericCoreInterface("MyApp.Core") .Configure(c => c.LifeStyle.Transient)); }
}

Note the use of convention-based mappings between assemblies and the different instance lifestyles. Mapper.Engine has a Singleton lifestyle. Not that there's anything wrong with that. :>

Next, I create a class to tell Common Service Locator to use Castle Windsor as the provider and to load up those IoC configurations:

public static class RegisterServiceLocator { public static void Register() { var container = new WindsorContainer(); ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(container)); RegisterIoCContainer.AddComponentsTo(container); }
}

Then I call RegisterServiceLocator.Register() on Application_Start() in the Global.asax. From then on, I can call the Common Service Locator to get my instance from my interface:

var instance = ServiceLocator.Current.GetInstance<IEmailService>();

I don't often need to use this syntax, since I'm usually pushing external dependencies into a constructor and letting auto-wiring resolve the dependency chain for me. But I do use this syntax for testing that Common Service Locator is finding the instance I want.

Adding RequireJS to an ASP.NET MVC project

Wed, 28 May 2014 00:39:29 Z

Why RequireJS?

RequireJS is a popular JavaScript module loader. RequireJS solves the problem of needing to invoke some JavaScript code from another file, but not knowing if that file has been loaded yet.

It does this with either a define or a require declaration, which takes an array of strings and a callback function, then passes in the module names as arguments so you can reference them in your JavaScript code.

define(["jquery", "moment"], function ($, moment) { "use strict"; var init = function () { // Requires MomentJS to be loaded. // "moment" is the argument passed in by RequireJS for the MomentJS module, aliased as "moment" in the define/require statement. var now = new moment().format("M/D/YYYY h:mm:ss A"); // Requires jQuery to be loaded. // "$" is the argument passed in by RequireJS for the "jquery" module in the define/require statement. $("#currentDateTime").text(now); }; return { init: init }; }
);

Here "moment" is both the name of the module to load, and the argument passed in for that module name. It could have been "m" throughout, and it would still work. The same is also true for "jquery at the top in the define, which tells RequireJS what module to load, and "$" below that, which tells RequireJS to load that module into an argument named "$". We're using "moment" and "$" inside the function so the code looks conventional, but the "$" could have been "j" if you wanted it to be.

RequireJS guarantees that the external modules are loaded by the time your code runs. It also keeps track of which modules have already been loaded on the page, so it doesn't pull in the same module twice.

So which is it – require() or define()?

The require and define statement are the main ways you use RequireJS. The API signature is the same for both, but they work differently: "define" is for modules that will be loaded and run by code that uses a "require" statement to pull that module in. So think of "define" as your module definitions, and "require" as the way to execute them.

As you can see, the RequireJS usage is very simple and clean. The setup can be a headache, especially around paths, so I'll take you through how I've done it.

Configuring your paths in main.js

RequireJS needs to be configured. When we said "jquery" and "moment" above, we have to tell RequireJS where those files are so we can use those aliases. That's where main.js and required.config() come in:

require.config({ baseUrl: "/Scripts/app", paths: { jquery: "../lib/jquery-2.1.1", jqueryValidate: "../lib/jquery.validate", jqueryValidateUnobtrusive: "../lib/jquery.validate.unobtrusive", bootstrap: "../lib/bootstrap", moment: "../lib/moment" }, shim: { jqueryValidate: ["jquery"], jqueryValidateUnobtrusive: ["jquery", "jqueryValidate"] } });
require(["kickoff"], function(kickoff) { kickoff.init(); } );

RequireJS uses the baseUrl setting in main.js if you pass it a script name that is not an alias in the paths section. In other words, if you call "jquery" in your define/require, it knows from your paths setting where to go. If you call "myScript" in define/require, it looks for it in the baseUrl path, which is /Scripts/app in this case.

Notice there are no .js extensions to the end of the file names? This is something RequireJS does to help you. It's a JavaScript loader; it knows those are JavaScript files. In my view, this just adds to some of the confusion of configuring this thing.

Here's how I've got my paths configured under my Scripts folder in Visual Studio:

You can set up different folder structures or names based on your preferences, but it probably makes sense for main.js, which is the entry point of the app, to be at the root of /Scripts, or at least above your /app and /lib script folders. Also, you don't have to name your file main.js. that's just a RequireJS convention.

The shim section in the code above is to tell RequireJS about any dependencies your files have before they can be used. Here, we are saying if we call "jqueryValidate" to load that module, we have to load "jquery" first. The "jqueryValidateUnobtrusive" module has to load "jqueryValidate" and "jquery" first, before it can be used. You could probably shorten the shim for "jqueryValidateUnobtrusive" to just "jqueryValidate", since that module requires "jquery", and RequireJS tracks the whole dependency graph for you. It doesn't hurt to leave it in, either.

For many apps, it makes sense to call code to load the app or run code on every page from the main.js file, and we've done that here with a call to "kickoff.init()".

Calling the main.js file

The normal advice for adding RequireJS to an app is to put this line in the <head> section of _Layout.cshtml.

<script data-main="Scripts/main" src="/Scripts/lib/require.js"></script>

This is a kind of weird looking script tag. The src attribute is normal enough for pulling in RequireJS, but the data-main is new. That's RequireJS's special attribute for getting the path to main.js. Notice again there is no ".js" in the data-main. RequireJS knows it's a .js file and appends that automatically.

This script tag is usually all you need for a single page app, where all modules run inside one full page request.

Set up for multi-page apps

I don't see too many single-page apps in the wild. More often, they are multi-page apps where each page has a LOT going on. If you aren't building a single page app, you can still take advantage of RequireJS, but we need to change some things.

We need to change the code that loads RequireJS and main.js in _Layout.cshtml from:

<script data-main="Scripts/main" src="/Scripts/lib/require.js"></script>

to:

<script src="/Scripts/lib/require.js"></script> @RenderSection("scripts", required: false)

You can put this right before the closing </body> tag if you like, but RequireJS will inject <script> tags with the async attribute in the <head> section like this:

Now we've got a common layout, and a hook in each page (the Razor @RenderSection) where we can load THAT page's scripts. In each page, you'll then need something like:

@section scripts { <script> require(["Scripts/main"], function () { require(["currentDateTime"], function (currentDateTime) { currentDateTime.init(); } ); } ); </script> }

Each page will be different, depending on what you need to load and run, but you will always load and run main.js, then when that's done, you'll load the scripts just for that page in the inner require(). Note this inner require() is pulling in the code that was in the define() at the top of this post.

Now drop this code in on every page in your app, but first…

What about jQuery and DOM loading?

What if your JavaScript loads before the DOM is loaded? With jQuery, we normally call:

$(function () { ...the code to run on DOM ready... });

So how do we know the DOM is loaded before we start touching it in RequireJS world? We need to use the domReady plugin with:

require(["domReady!"], function() { ...the code to run on DOM ready... } );

Download the plugin and put it in the /Scripts/lib folder. Now we have a new file we want to alias, so we need to add that to our require.config paths in main.js

paths: { jquery: "../lib/jquery-2.1.1", jqueryValidate: "../lib/jquery.validate", jqueryValidateUnobtrusive: "../lib/jquery.validate.unobtrusive", bootstrap: "../lib/bootstrap", moment: "../lib/moment", domReady: "../lib/domReady", },

There we go. We have another piece of our run-on-every-page code snippet.

MVC Helpers

When you start repeating yourself in an MVC view, consider adding an HTML Helper. What we want generically is:

require(["Scripts/main"], function () { require(["...the module to load...", "domReady!"], ...run the module... ); } );

We also don't want to have to think about relative paths. We want the scripts to find main.js and the /Scripts/app and /Scripts/lib folder whether the page is located at the root (/) or /Deep/Within/The/Site.

Here's the C# to do that:

using System; using System.Text; using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class RequireJsHelpers { public static MvcHtmlString InitPageMainModule(this HtmlHelper helper, string pageModule) { var require = new StringBuilder(); var scriptsPath = "~/Scripts/"; var absolutePath = VirtualPathUtility.ToAbsolute(scriptsPath); require.AppendLine("<script>"); require.AppendFormat(" require([\"{0}main.js\"]," + Environment.NewLine, absolutePath); require.AppendLine(" function() {"); require.AppendFormat(" require([\"{0}\", \"domReady!\"]);" + Environment.NewLine, pageModule); require.AppendLine(" }"); require.AppendLine(" );"); require.AppendLine("</script>"); return new MvcHtmlString(require.ToString()); } }
}

What we're going for is having several things loaded on every page: 1) require.js, 2) main.js, 3) the DOM, and 4) the main JavaScript module for that page and anything that module needs. This "main module" concept works well to just run as it's loaded instead of forcing the caller to invoke it with an init() call, so let's change our "currentDateTime.js" module from above to do that and create "main-currentDateTime.js" instead:

require(["jquery", "moment"], function ($, moment) { "use strict"; // Requires MomentJS to be loaded. // "moment" is the argument passed in by RequireJS for the MomentJS module, aliased as "moment" in the require statement. var now = new moment().format("M/D/YYYY h:mm:ss A"); // Requires jQuery to be loaded. // "$" is the argument passed in by RequireJS for the "jquery" module in the require statement. $("#currentDateTime").text(now); }
);

We've also changed from define() to require() since this is a self-loading module, not one a caller has to invoke. We got rid of the init() function so this code runs when the module is loaded.

Download

That should do it for adding RequireJS to your MVC mutli-page app. All the code above is available for view/download on GitHub.

Why I'm using Moq instead of Rhino Mocks these days

Thu, 10 Mar 2011 01:40:15 Z

On my last greenfield project I got to pick the unit testing and mocking tools. I've been a regular Rhino Mocks user for a long time, but I've seen lots of code samples with Moq and liked the syntax, so I gave it a try.

I have to say, I did prefer Moq slightly to Rhino Mocks. The newer Arrange, Act, Assert (AAA) style syntax in Rhino Mocks is a huge improvement over the old Record/Replay mess. But Moq has the benefit of being born at the right time and has AAA style calls without the burden of supporting deprecated syntax. This means Moq has cleaner documentation, fewer options, and fewer ways to get confused by the API. I really couldn't find anything I needed to do in Moq that I couldn't do. I did get a little tripped up having to get the object out of the mock, with myMock.Object calls, but that wasn't a big deal.

Here's the NuGet Moq install package syntax to add Moq to your unit test project:

I'm using mocking frameworks less these days. Instead, I'll write a fake object myself or just try to avoid interaction testing altogether. But if I needed to pull one off the shelf today, I'd grab Moq first.

Lazy load off-screen images with lazysizes

Mon, 23 Apr 2018 00:39:09 Z

Many users will never scroll all the way down to see the awesome images below the fold on your web site. If you load all your images when the page loads, you are wasting bandwidth and slowing down the page start-up experience.

Instead, you can lazy-load images as they are about to come into view. The latest way to do this is using Intersectional Observer, but it isn't supported on Safari, iOS Safari, or IE11.

I opted to use lazysizes to deal with cross-browser differences, viewport size differences, scroll speeds, and the other headaches you could get rolling your own solution. To see it in action, go to their test page, open your browser tools Network tab, filter for Images, and scroll down. You'll see new images loaded as you get closer to them. It's slick.

The easiest way to use lazysizes is to reference the script in your page:

<script src="lazysizes.min.js"></script>

Then change <img> tags from src="myImage.jpg" to data-src="myImage.jpg" and add class="lazyload" like:

<img data-src="myImage.jpg" class="lazyload" />

You can get fancier with responsive image sets and lazy loading CSS background images, too.

Where should validation go?

Tue, 15 Sep 2009 00:41:26 Z

<groan>Not this argument again!</groan>

The short answer: I don't know.

The long answer: Yeah, I really don't know.

There is still no widely accepted answer on this one. Reasonable people disagree. One camp pushes it up closer to the UI, the other down lower so it shelters the domain from invalid states. Some like it sprinkled across layers; some like it centralized.

I think Steve Sanderson is correct that validation falls on a continuum from easy UI validation, like required fields, to complex business rules that need to be checked closer to or in the domain entities.

I also think Jimmy Bogard is correct that context matters when it comes to validation. This object is valid for what? Saving to the database? Emailing to sales? Displaying on the screen? The validation rules depend on the the behavior you are validating.

These days, I think of validation as either UI Validation (required fields, min/max length, etc.), Domain Validation (start date/time must be before end date/time, order must have at least one item, etc.), or Database Validation (is this value unique, is this ID value going to throw a foreign key violation). This is based on when you can validate in the call chain more than what it's valid for. I still like validation in context, but those business rules end up in my Domain Validation logic with method names like CanSendEmailToCustomer().

Sharp Architecture uses NHibernate Validators as attributes on the domain entities. The best thing about this is your validation is centralized. It's sitting right there in your domain, and you know where to go if there is a rule change.

The other good thing about this approach is your entity should always be valid when saved. The built-in Repository<TEntity> calls in Sharp Architecture enforce validation before inserts and updates, so you're covered there. If you want to call MyEntity.IsValid() in a method, you can do that as well.

The bad thing is those validation attributes can start looking like UI concerns when they have user-centric error messages in them ("Hey, user, that's not a valid format for a phone number"). And if there is a rule that doesn't lend itself to attributes (e.g., orders must have at least one order item), you are on your own.

I started with validation attributes on my domain entities, and when my attribute messages got too UI-looking, I moved to using Data Annotations on DTOs in my application service layer for UI validation. The DTOs are made to be client facing, so I'm not bothered by user-specific messages in them.

Then when Domain or Database Validation problems come up, a ValidationException is thrown up through the application service to the UI so the calling app can either display or handle it. I haven't played with it yet, but I think this is what xVal is doing, too.

The more I think about it, the more I see my web app as just another client calling into my application service layer which is encapsulating my domain. So my web app is the "user" and the message needs to be just enough for that user, not necessarily the end user. Maybe a validation exception token is sent out from the application service layer to the UI, and the UI translates that to a string from a very UI-centric resource file?

Bu I'm still not happy with this. I feel like I have the right kind of validation in the right places, but I would still like a more centralized approach for easier refactoring of business rules. I've used the Specification Pattern before, and it does a great job of centralizing the rules. But making yet another class for yet another required field and adding it to yet another Composite Specification? Seems like your walking away from a lot of the productivity attributes can give you.

Obviously, my thoughts on validation are still not fully formed. I'm still arguing with myself. My dream validation would be:

centralized for easy refactoring and rule changes

automatically called for routine things so I don't forget (like saving the order to the database)

allow ad hoc calls for non-routine things (like validating the order confirmation email can be sent to the customer)

handle simple validation like attributes so I can be productive

handle complex validation like specifications so I'm not limited

UI-agnostic so the centralized validation goo isn't holding end-user strings, except when I'm too lazy to set up the resource file, in which case strings can be passed up from this layer

I told you I didn't know! :)

Specifying Args with Rhino Mocks

Thu, 26 Nov 2009 01:41:11 Z

The problem

I ran into a snag testing some code today with Rhino Mocks. I was mocking calls to a repository and inspecting the repository method calls and arguments passed.

Everything started off pretty normal with the repository dependency injected into the class under test:

// Arrange var repository = MockRepository.GenerateMock<ICustomerRepository>(); var passenger = new Passenger(repository);
// Act passenger.CallTheMethodUnderTest(arg1, arg2);

In my Assert section, I needed to check that the correct repository methods were called with the correct arguments. The catch was, one of the arguments was a class created within the method under test. I thought I could create and assert the equivalent Customer in my test like this:

// Assert var expectedCustomer = new Customer { CustomerID = "1234", FirstName = "Joe", LastName = "Wilson" }; repository.AssertWasCalled(x => x.SomeRepositoryMethod( arg1, arg2, expectedCustomer));

The two Customer objects (in the test and in the method under test) had the same values, but of course, were not the same objects. They were two different Customer objects that happened to have the same values. So Rhino Mocks told me that my expected Assert wasn't met.

The answer

I knew Rhino Mocks could ignore arguments with

Args<T>.Is.Anything

But I knew what the values should be. In fact, for this test, the values being passed into the repository calls were just as important as the calls themselves.

So I tried comparing the values of the two Customer objects instead of the objects themselves:

repository.AssertWasCalled(x => x.SomeRepositoryMethod( arg1, arg2, Arg<Customer>.Matches(c => c.CustomerID.Equals("1234") && c.FirstName.Equals("Joe") && c.LastName.Equals("Wilson"))));

So close! But now Rhino Mocks told me if I used Arg for one parameter, I'd better use it for all of them. No biggie. I made the change and this worked:

repository.AssertWasCalled(x => x.SomeRepositoryMethod( Arg<int>.Is.Equal(arg1), Arg<int>.Is.Equal(arg2), Arg<Customer>.Matches(c => c.CustomerID.Equals("1234") && c.FirstName.Equals("Joe") && c.LastName.Equals("Wilson"))));

Postmortem

The Arg statement let's you specify a type and tell Rhino Mocks you don't know or don't care about the value:

Args<int>.Is.Anything

You can also tell Rhino Mocks you know the type and what the value should be:

Args<int>.Is.Equal(7)

If you have a non-primitive type or complex assert, you can also inspect values with the Matches statement:

Arg<Customer>.Matches(c => c.CustomerID.Equals("1234") && c.FirstName.Equals("Joe") && c.LastName.Equals("Wilson"))));

I realize the code in these tests is probably way too familiar with the code under test. I prefer testing state over this kind of interaction testing where possible. But this was a case where the code under test had a void return and didn't do much besides parse some values and call repository methods based on those values.

In times like this, I'm glad I have interaction testing to fall back on so I can verify my code is behaving the way it should.

Review of Sharp Architecture

Tue, 15 Sep 2009 00:41:29 Z

I've been using the open-source project Sharp Architecture for about 6 months now, and version 1.0 was recently released. It's a really great way to get rolling quickly on a project using ASP.NET MVC, Domain Driven Design (DDD), NHibernate, and Castle Windsor.

I won't go into the details about what Sharp Architecture does. I'll just cover what I like in the first version and what I hope makes it into future releases.

What I like

Decoupled Design

The Sharp Architecture framework uses inversion of control right out of the box with Castle Windsor and the Common Service Locator wrapping container calls. The MyProject.Core assembly holds your domain model and interfaces to your repositories. Implementations of those repositories are in MyProject.Data.

There is also a MyProject.ApplicationServices assembly for times when your controller logic starts to look heavier than it should or you prefer to push all your logic into an application layer so you can skim off the MVC UI for something else at some point (Silverlight? WCF?). I like this approach with very lightweight controllers and views for just this reason.

NHibernate Training Wheels

Billy McCafferty, the principal author on the project, is one of the gurus on NHibernate best practices. NHibernate is very powerful, but some tools, like Fluent NHibernate, which uses C# code to map your domain to your database instead of XML, are.well.kind of fluid.and still under construction.

I'm still new to NHibernate and very new to Fluent NHibernate, so I get tripped up often. It's nice to know that my solution is using best practices for tools where my footing is not as sure, like NHibernate session management.

Templates + Conventions

The Visual Studio solution and T4 templates inside Sharp Architecture are the things that makes it different from being just another reference implementation or architecture guidance. You can get a new, empty Sharp Architecture solution going in about 30 seconds with the Visual Studio solution template. The T4 templates help you add controllers and views built around conventions and the property names in your domain entity.

I used to be a big fan of code generation. It's nice to spit out a bunch of classes very quickly, but there really has to be a balance. If it gens too much code, is it all stuff you really need? If it only gens a little bit, did you need a code generator at all?

Sharp Architecture does a good job of giving you a jump start on stuff you will probably want or at least a place-holder for stuff you will want. It doesn't litter the solution with too much junk.

For instance, it doesn't generate a repository for your domain entity because you can use use the IRepository<MyDomainEntity> and Repository in the Sharp Architecture assemblies. It doesn't generate NHibernate mappings for your domain entity because the mapping conventions cover most cases. If you do need additional repository methods or have unconventional database mappings, it's easy to inherit from and override these. Sharp Architecture uses generics, base classes, and conventions to keep from needing a lot of code generation.

Documentation, Sample Code, Wiki, and Forum Support

This project is much better documented than most open-source projects. In addition to the "getting started" and 'using the framework" documents, there is a sample Northwind project that comes with the download files. Online, there is a wiki and a Google Group that is actively monitored if you need additional help.

I know real programmers only use Reflector for documentation. :> But don't underestimate the value of documentation for widespread adoption. You can have a great open source project that doesn't get very far if people don't know how to get up and running quickly and fully exploit the framework. That won't be a problem for Sharp Architecture.

Helpers

Sharp Architecture libraries are chock full of all kinds of convenience methods and helpers. Want to write a database integration test using SQLite? Just have your test class inherit from RepositoryTestsBase(). Want to hit the live database? Inherit from DatabaseRepositoryTestsBase(). Want to design by contract and check incoming parameters and return values easily? Look into the Check.Require() and Check.Ensure().

There are a ton of things like this that all of us have written before. Most developers I know walk around with a couple assemblies to make coding their next project easier. With Sharp Architecture, these are referenced in your solution right after File > New Project.

Folder Structure

Everyone has their own preferred solution and folder structure. The default project and folder organization in a new Sharp Architecture solution is pretty close to what I was already using and is simple for any developer to jump in and follow along.

This may not seem like a big deal because a good structure looks obvious in hindsight, but it's nice to not have to dig around for things. I've worked on solutions that have 20+ projects. Sharp Architecture goes the other way and you end up with about four projects in a normal MVC app.

What I would like to see in future releases

I don't have any strong objections to the design choices in Sharp Architecture. Most of the things here are more a matter of style/taste than anything.

Controllers back in MyProject.Web project

You can read Billy's view on putting the controllers in the web project. His main point is that controllers should be written and tested independent of the other assemblies so you don't succumb to temptation and do things like go straight to your repository from your controller instead of asking your IoC tool to give you the concrete repository instance.

That's fair. But my controllers don't do much besides call into my application services layer, render views, and redirect to other controller actions. I don't mind having a reference to the entire web project in my unit test project so I can test routes and the very little logic I have in my controllers.

In his article, Billy describes the pain of having done it the way I prefer. Maybe this is one of those lessons where you have to experience it yourself to internalize it. Like my dad telling me the stove was hot when I was a kid. :>

MyProject.Infrastructure instead of MyProject.Data

Maybe I've looked at Code Camp Server or listened to Jeffery Palermo talk too much, but I lump data handling into a larger category of infrastructure concerns. Sharp Architecture's solution template gives you MyProject.Data, which holds the NHibernate mappings and conventions and the repository classes.

But I have other utility/infrastructure things I need to put somewhere, like logging, emailing, etc. I prefer having MyProject.Infrastructure with Data as a folder underneath it so I can throw all my infrastructure implementation code into that assembly. The interfaces for these guys still go in MyProject.Core, just like the repository interfaces.

More emphasis on MyProject.ApplicationServices

I prefer to have as little logic as possible in my views and controllers. I push as much as I can to an application layer so the UI can be replaced or added to with minimal impact. In Sharp Architecture, you've got MyProject.ApplicationServices for exactly that. There is one Northwind example that uses this layer, but in the other samples, the controllers are doing the application flow work.

I think it's better to have an application service passed into the controller's constructor so the controller doesn't need to know much except routing, views, redirects, the app service method to call, etc. I don't mind having these UI logic concerns in the controller, but anything beyond that needs to be in an application layer.

I've borrowed a metaphor from the SQL Server installer that talk about "surface area". I think of the MyProject.ApplicationServices layer as a wrapper around all the app logic. The methods in this layer are the surface area of my application, and they encapsulates all the implementation code my domain is dealing with. Calls into this layer can kick off multi-step processes, handle workflow, and usually have long, explicit method names. But this is the only part of my domain's surface area that is exposed externally.

The MVC web project is one client calling into this application layer, but there may be others someday on even medium-sized projects. If your app becomes more popular and you've followed this approach, you can add other clients that call into your application service layer like a WCF service, a system tray tool, etc. These guys may have their own specialized methods or may use something the web application was using. Either way, you are very intentional on the surface area you expose.

I think Sharp Architecture gets this right. I would just like to give it a little nudge to make it a point of emphasis.

Conclusion

I've used a lot of different frameworks, but Sharp Architecture comes closest to the way I want to work already. The templates and documentation put it well beyond a reference implementation, and you can work with a simplified solution sitting on top of a lot of abstracted complexity to get you productive right away.

True is Truthy, but Truthy isn't the same as True

Fri, 24 Apr 2015 11:08:00 Z

Most JavaScript developers are familiar with the concepts of truthy and falsy. As a quick refresher, the falsy values are:

false null undefined 0 (the number zero) "" (an empty string)

Everything else is truthy. This is one of those things you just have to memorize, but it's simpler if you think of the falsy stuff as things that are false or have no value. Just watch out for zero and empty string.

I got burned by a bug today in a passing Jasmine test by not paying enough attention to the truthy values. The code I was testing was a little function to make sure scaleMin was smaller than scaleMax, but if they were both set to 0, that was OK. If scaleMin was greater than or equal to scaleMax, we'd return an error message.

Here are the function and tests I started with. All the tests pass. Done, right?!?!

Not so much.

Jasmine's toBeTruthy() checks for any truthy value, and a string with something in it is truthy. So in the test where I'm checking that it's OK if scaleMin and scaleMax are both 0, I'm getting the error string, which is truthy. Since the error string and the value true are both truthy, my check for toBeTruthy() will always pass. I'm getting false positives.

This is why you are supposed to write a failing test, then a passing test to prove your code was the thing that made the test pass. I skipped that here because this code was so simple. What could go wrong? Oops!

Here's the fixed function and test code, which uses Jasmine's toBe(true) instead of toBeTruthy() to tease apart error strings and the value true:

Unit testing untestable code

Tue, 06 Apr 2010 05:44:00 Z

Let's say you've got a static or sealed class, or a class with non-virtual members that your code needs to use. You need to unit test your code, but you can't get an instance of this class and/or you can't mock it.

There are two ways to go:

Buy a tool that let's you mock things like this, such as Typemock Isolator or the newly announced Telerik JustMock.

Code around it.

Buy it

I've already compared Typemock Isolator ($799) to RhinoMocks (free). Typemock Isolator works as advertised. The biggest issue is the price. It's hard enough to get management approval for introducing external tools. But when buy-in literally means BUY in, it's even harder.

Build it

Don't despair if you're stuck with "code around it" and using free mocking tools! If you can change the code that is static, sealed, private, non-virtual, etc. fix it that way. That's the best thing.

But if it's in a legacy assembly you have to use, and you can't just change the original code, use this simple technique.

Here's the untestable class we need to use. It's static, so we can't mock an instance of it with Rhino Mocks.

public static class StaticSendOrderClass { public static void SendOrderToAccountsPayable(Order order) { // Pretend code here... } }

Here's the new code you're working on that uses this static class to process an order:

public class OrderProcessor { public void ProcessTheOrder(Order order, bool useStaticClass) { if (useStaticClass == true) { StaticSendOrderClass.SendOrderToAccountsPayable(order); } else { // Notify accounts payable some other way } } }

First, we need to create an interface with just the functionality we need from the untestable class. Name the class and method(s) whatever makes sense for your app. You're not tied to the legacy code naming convention; this is your code now.

public interface INotifyAccountsPayable { void SendOrder(Order order); }

Next, create a new class to implement this interface and wrap the untestable code. In the method calls in the new class, turn around and delegate the call to the untestable class.

public class NotifyAccountsPayable : INotifyAccountsPayable { public void SendOrder(Order order) { StaticSendOrderClass.SendOrderToAccountsPayable(order); } }

Now inject the new interface into the constructor of your new class as an argument. You'll also want to create a private field and set its value to the instance argument in the constructor. Now you can swap out your old code that calls the untestable code, and instead use your new private field.

public class OrderProcessor { private readonly INotifyAccountsPayable _notifyAccountsPayable; public OrderProcessor(INotifyAccountsPayable notifyAccountsPayable) { _notifyAccountsPayable = notifyAccountsPayable; } public void ProcessTheOrder(Order order, bool useStaticClass) { if (useStaticClass == true) { _notifyAccountsPayable.SendOrder(order); } else { // Notify accounts payable some other way } }
}

Now you've got a unit testable OrderProcessor class! Mock the INotifyAccountsPayable interface with Rhino Mocks and inject that mocked dependency into your class under test. Then you can verify the call was made as expected.

[Test] public void Should_call_untestable_code_when_useStaticClass_is_set_to_true() { // Arrange var mockNotifyAccountsPayable = MockRepository.GenerateMock<INotifyAccountsPayable>(); var orderProcessor = new OrderProcessor(mockNotifyAccountsPayable); var stubOrder = MockRepository.GenerateStub<Order>(); var useStaticClass = true; // Act orderProcessor.ProcessTheOrder(stubOrder, useStaticClass); // Assert mockNotifyAccountsPayable.AssertWasCalled(x => x.SendOrder(stubOrder));
}

Please note this is not testing the internals of the untestable, static code. But you don't need to worry about unit testing the internals of that code. You don't own that code. Testing that is really an integration test, not a unit test. Using this approach, you isolate your new code from an external dependency and keep all your new code testable.

Upgrading FontAwesome from 4 to 5

Mon, 22 Jan 2018 06:33:00 Z

FontAwesome 4 has been around a long time, and it's…well, awesome! Remember their Kickstarter with those videos? Well FontAwesome 5 is out now, and as promised, it has some big improvements. But to get the benefits, you'll have to work through some breaking changes. Here's what I learned from my upgrade.

Let's start with a simple page with 3 icons using Font Awesome 4.
See the Pen FontAwesome 4 simple icon sample by Joe Wilson (@joewilson0) on CodePen.
The big improvement in FontAwesome 5 is that the icons are drawn with SVG now. Yay for sharp scaling up or down! Now you reference a JavaScript file with the SVG specs embedded in it instead of a CSS file. I'll change the pen to remove the CSS reference and add the JavaScript reference from the CDN:

<script defer src="https://use.fontawesome.com/releases/v5.0.3/js/all.js"></script>

Then check the results:
See the Pen FontAwesome 4 to 5 upgrade by Joe Wilson (@joewilson0) on CodePen.
You can see the icons, but they changed a little. The calendar is very dark, and the arrow is a little more narrow. That's because the way you reference the icons has changed in version 5. Instead of fa as a style preceding every icon style, you need to pick from fas for solid, far for regular, fal for light, or fab for brand. It looks like fas is the fallback, so you get solid if you leave your old fa references. For most icons, this change makes the icon heavier or lighter.

If you are biting your nails thinking of all the places you have icons that will now need to change, you can upgrade to 5 and use a shim.

<script defer src="https://use.fontawesome.com/releases/v5.0.3/js/v4-shims.js"></script>

That's better:
See the Pen FontAwesome 4 to 5 upgrade using shim by Joe Wilson (@joewilson0) on CodePen.
But if you've got the time and the inclination, skip the shim and change your icon classes to take advantage of the new, lighter styles. If I change all the icons in the same from fa to far we get this:
See the Pen FontAwesome 4 to 5 upgrade using far icons by Joe Wilson (@joewilson0) on CodePen.
That's one of the other big changes. FontAwesome has lots more icons, but to get all of them, you'll need to buy the PRO version starting at $60 for 5 seats. I think that's a good deal, but the old icons are still free if you only need those.

Finally, some icons changed names, and you'll need to swap them out if you don't want to use the shim.

Cache busting with RequireJS and R.js in an ASP.NET MVC app

Sat, 31 May 2014 00:39:24 Z

Browser caching is great, except when it's not. What if you deploy a new version to production, but the fix you made to a JavaScript or CSS file isn't showing up? How can we force the browser to download files at least once with each build?

In previous posts, I showed how to use RequireJS in an MVC app, and how to optimize JavaScript and CSS using r.js in that project. Now we'll tackle cache busting to fix this problem.

The code for this project is available for view/download on GitHub.

Concept

We're going to put a small query string on every optimized JavaScript and CSS file with a unique code tied to that deployment. I'll use the build number of the main web assembly, since that's easy to get. The pattern will be like:

/Scripts-Build/app/main-fileName.js?v=1234

If you don't like using the build number for whatever reason, you can use anything you like, as long as it it changes when you build or deploy the files, but doesn't change all the time. So something like a build date makes sense, but not the current date/time, because that will always be different on each request.

Finally, be aware this is not a perfect solution. If someone is sitting behind a proxy server, they may not see the changes IF the proxy server doesn't honor the query strings and refetch the files. If that applies in your situation, you may need a path and some extra routing work to get past the proxy with something like:

/Scripts-Build/app/1234/main-fileName.js

I'll only be showing the build version style, and I've found that works in most situations.

Getting the build version

This is not the kind of code you write very often, but here's how I got the build number from the current assembly:

using System.Globalization; using System.Reflection; using System.Web; using System.Web.Caching; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class ApplicationVersionHelpers { private const string _assemblyRevisionNumberKey = "AssemblyRevisionNumber"; public static string AssemblyRevisionNumber(this HtmlHelper helper) { #if (DEBUG) return string.Empty; #else if (HttpRuntime.Cache[_assemblyRevisionNumberKey] == null) { var assembly = Assembly.GetExecutingAssembly(); var assemblyRevisionNumber = assembly.GetName().Version.Revision.ToString(CultureInfo.InvariantCulture); HttpRuntime.Cache.Insert(_assemblyRevisionNumberKey, assemblyRevisionNumber, new CacheDependency(assembly.Location)); } return HttpRuntime.Cache[_assemblyRevisionNumberKey] as string;
#endif } } }

We are just returning an empty string in Debug mode. In Release mode, we are caching the build revision number so we don't have to re-lookup that value every time we request it.

Now we need a way to access this version number from JavaScript. Let's put this version number in a global variable inside _Layout.cshtml in the <head> section so it's available on every page.

<script>var version = "@Html.AssemblyRevisionNumber()";</script>

We all know global variables are a sin, so paste it in and say your penance.

Using the build version

In the previous post, we had a PathHelpers.cs file that toggled between the /Scripts and the /Scripts-Build and between the /Styles and the /Styles-Build folders. We need to update that to use our version number based on Debug/Release build mode:

using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class PathHelpers { public static string ScriptsPath(this HtmlHelper helper, string pathWithoutScripts) { var fullPath = ""; #if (DEBUG) var scriptsPath = "_{/Scripts/"; fullPath = VirtualPathUtility.ToAbsolute(scriptsPath + pathWithoutScripts); #else var scriptsPath = "}/Scripts-Build/"; fullPath = VirtualPathUtility.ToAbsolute(scriptsPath + pathWithoutScripts + "?v=" + helper.AssemblyRevisionNumber()); #endif return fullPath; } public static string StylesPath(this HtmlHelper helper, string pathWithoutStyles) { var fullPath = "";
#if (DEBUG) var stylesPath = "_{/Styles/"; fullPath = VirtualPathUtility.ToAbsolute(stylesPath + pathWithoutStyles); #else var stylesPath = "}/Styles-Build/"; fullPath = VirtualPathUtility.ToAbsolute(stylesPath + pathWithoutStyles + "?v=" + helper.AssemblyRevisionNumber()); #endif return fullPath; } } }

This covers the _Layout.cshtml scripts, but we also need to update RequireJsHelpers.cs, our helper that is used for page-level scripts and pulls in main.js:

using System; using System.Text; using System.Web; using System.Web.Mvc; namespace RequireJSWithMVC.Extensions { public static class RequireJsHelpers { public static MvcHtmlString InitPageMainModule(this HtmlHelper helper, string pageModule) { var require = new StringBuilder(); #if (DEBUG) var scriptsPath = "_{/Scripts/"; #else var scriptsPath = "}/Scripts-Build/"; #endif var absolutePath = VirtualPathUtility.ToAbsolute(scriptsPath); require.AppendLine("<script>"); #if (DEBUG) require.AppendFormat(" require(["{0}main.js"]," + Environment.NewLine, absolutePath); #else require.AppendFormat(" require(["{0}main.js?v={1}"]," + Environment.NewLine, absolutePath, helper.AssemblyRevisionNumber()); #endif require.AppendLine(" function() {"); require.AppendFormat(" require(["{0}", "domReady!"]);" + Environment.NewLine, pageModule); require.AppendLine(" }"); require.AppendLine(" );"); require.AppendLine("</script>"); return new MvcHtmlString(require.ToString()); } }
}

Both of these now put ?v=1234 in the JavaScript or CSS path.

We still need to do some work so our /app and /lib scripts get the same treatment. We'll do that in main.js by adding this line:

urlArgs: version === "" ? "" : "v=" + version

Remember our awful global variable "version" in _Layout.cshtml? This is where it's being used. In my main.js file, I have this right under the baseUrl setting:

require.config({ baseUrl: "/Scripts/app", urlArgs: version === "" ? "" : "v=" + version paths: { jquery: "../lib/jquery-2.1.1", jqueryValidate: "../lib/jquery.validate", jqueryValidateUnobtrusive: "../lib/jquery.validate.unobtrusive", bootstrap: "../lib/bootstrap", moment: "../lib/moment", domReady: "../lib/domReady", }, shim: { jqueryValidate: ["jquery"], jqueryValidateUnobtrusive: ["jquery", "jqueryValidate"] } });
require(["kickoff"], function(kickoff) { kickoff.init(); } );

Now you should be able to run the web app in Release mode and get this, with ?v=1234:

Or run in Debug mode and get this, without the bundling, minification, and the extra query string stuff:

If you get this far and your build version in the query strings is 0, you need to update your AssemblyInfo.cs file:

[assembly: AssemblyVersion("1.0.*")]

The * is the auto increment of the build revision number.

Optimizing bundle size with Telerik ASP.NET Core controls, Bootstrap, and Webpack

Mon, 21 Dec 2020 07:45:51 Z

I am working on a mobile web application project using Telerik ASP.NET Core controls. These are the C# equivalent of the Kendo UI JavaScript controls. In fact, the Telerik ASP.NET Core controls are really Razor and tag helper wrappers that emit JavaScript to the browser to save you from the trouble of writing the JavaScript yourself.

Because this is a mobile web app that will be used in the field, we want fast page download speeds. Having worked with Kendo UI before, I knew I could import only the components I needed, rather than pull in code for sliders and other components not used in this app.

We are also using webpack and import only the JavaScript for the Telerik components used in each module.

Styles

In this project, we have a variables.scss file where we keep the common Sass variables, a site.scss files with the site-specific styles and overrides, and a common.scss file that brings these two project Sass files together with the vendor files - in this case, Bootstrap and Kendo UI styles.

Notice we are pulling in all Bootstrap styles, but we are not importing every Kendo UI styles or a combined file with all the Kendo UI styles for all the components. We are using only a handful of Kendo UI components in this app, so we don't want the extra weight of all those styles that will never be used in the app.

// All variables @import "variables"; // Bootstrap @import "node_modules/bootstrap/scss/bootstrap"; // Kendo UI @import "node_modules/@progress/kendo-theme-bootstrap/scss/autocomplete"; @import "node_modules/@progress/kendo-theme-bootstrap/scss/grid"; @import "node_modules/@progress/kendo-theme-bootstrap/scss/combobox"; @import "node_modules/@progress/kendo-theme-bootstrap/scss/datetime";
// Site @import "site";

Scripts

The webpack entry points for this web app are pages. It's a multi-page, not a single-page application. Here's what the home.js page script looks like. It imports the components it needs, which in turn import whatever they need. For this app, the home page is static and shows a splash, and that's about it.

import "common.scss"; import $ from "jquery"; import "components/top-menu"; import "components/header"; import "components/footer";

Here's the script for search.js a page that uses the Kendo UI autocomplete search and a gid to show search results. It also uses the Bootstrap alert module to show the user if there are no records found in the search.

Finally, I had to import @progress/kendo-ui/js/kendo.aspnetmvc in the page's JavaScript module. This is the secret sauce to get client-side behavior from server-side Telerik ASP.NET Core controls we used in Razor views (below).

import "common.scss"; import $ from "jquery"; import "components/top-menu"; import "components/header"; import "components/footer"; import "bootstrap/js/dist/alert"; import "@progress/kendo-ui/js/kendo.autocomplete"; import "@progress/kendo-ui/js/kendo.grid"; import "@progress/kendo-ui/js/kendo.aspnetmvc";

Razor

The Razor views were like normal ASP.NET Razor views or pages, but with client-side behavior coming from the page's import "@progress/kendo-ui/js/kendo.aspnetmvc";. This means you can sort or filter the results in a grid without a server call, but you don't have to write all the JavaScript client code to handle that.

We tried the Telerik ASP.NET Core control tag-helpers, and I kind of prefer the syntax, but we quickly found there were not enough examples on the Telerik site or out in the wild to figure out the API. Guessing got pretty old pretty fast, so we went to the more traditional HTML helper syntac in the Razor code.

<form id="searchForm" asp-controller="Search" asp-action="Index" method="post"> <div class="input-group"> @( Html.Kendo().AutoComplete() .Name("searchText") .DataTextField("HitString") .HtmlAttributes(new {@class="form-control"}) .DataSource(source => { source.Read(read => { read.Action("GetAutoCompleteAccounts", "Search").Data("() => { return { text: $('#searchText').val() }; }"); }).ServerFiltering(true); }) .Placeholder("Address, Owner Name, Legal Description, Account Number, or Parcel Number") .Value(Model) .Filter(FilterType.Contains) .MinLength(2) ) <div class="input-group-append"> <button type="submit" class="btn btn-primary text-light"> <span class="fas fa-search"></span> Search </button> </div> </div> </form>

Optimizing

When webpack starts build the entry points, in this case, home.js and search.js, it grabs only the styles in common.scss and only the modules in the pages and the components they use, so we get a smaller bundle than if we put style and script links in the <head> section of the _Layout.cshtml page.

Getting the SQL and Parameters out of Dapper for display in Glimpse

Mon, 02 Sep 2013 22:49:00 Z

Glimpse is a really nice tracing and diagnostic tool for what's happening on the server in an ASP.NET app.

It has a tab for showing the SQL and the query parameters being passed to SQL Server, but my tab looked like this when using Dapper dot net, a light-weight ORM that takes your SQL result and maps it to a C# object:

I knew Glimpse worked with ADO.NET, I had installed that plugin, and Dapper was using ADO.NET somewhere inside its framework, but my SQL tab was disabled. I thought maybe I needed to install a Glimpse Dapper plugin, but there was none on the official Glimpse plugins page.

I found this unofficial Glimpse Dapper plugin, but it still seemed like it was trying too hard. This should be easier.

I was getting my Dapper SQL connection through a factory like this:

public static class ConnectionFactory { public static IDbConnection CreateConnection(string connectionString) { var cnn = new SqlConnection(connectionString); cnn.Open(); return cnn; }
}

I finally found the Glimpse ADO integration help, and it said, "If you're not using an ADO connection that uses the DbProviderFactories class, Glimpse won't collect any data for the SQL tab (out of the box)."

Oh. Ok. So I changed my code to this:

public static class ConnectionFactory { public static IDbConnection CreateConnection(string connectionString) { var factory = DbProviderFactories.GetFactory("System.Data.SqlClient"); var cnn = factory.CreateConnection(); cnn.ConnectionString = connectionString; cnn.Open(); return cnn; }
}

and now the SQL and parameters are showing on the Glimpse SQL tab:

Yay!

Evolution of a View in ASP.NET MVC

Tue, 08 Dec 2009 05:00:00 Z

Many developers prefer working with ASP.NET MVC over Web Forms because they are more connected with the HTML, have better control over the rendered output, and can easily build their own HTML helpers to get consistent output.

But making the views can be a hassle when your building a CRUD app or something that has a lot of very similar views. Let's look at some ways around that you can use today and in the future.

Past

When MVC first came out, most people were coding their inputs in views like this. Just straight HTML with some helpers:

<% using (Html.BeginForm()) { %> <fieldset> <label for="Name">Name</label> <%= Html.TextBox("Name") %> <label for="Email">Email address</label> <%= Html.TextBox("Email") %> <label for="Phone">Phone</label> <%= Html.TextBox("Phone") %> <%= Html.SubmitButton() %> </fieldset> <% } %>

Simple, but a little too much reliance on strings. This made the code error prone, so developers made their own HTML Helpers to crank out consistent views with fewer strings by using lambda expressions:

<% using (Html.BeginForm()) { %> <fieldset> <label for="Name">Name</label> <%= Html.TextBoxFor(c => c.Name) %> <label for="Email">Email address</label> <%= Html.TextBoxFor(c => c.Email) %> <label for="Phone">Phone</label> <%= Html.TextBoxFor(c => c.Phone) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

That's better. We get IntelliSense for the model's fields and we get the leave some of the strings behind.

Present

The next step was to get rid of some of those label statements and get those rolled into the output automatically. They did this in Code Camp Server and you can see the step-by-step progression in Eric Hexter's blog:

<% using (Html.BeginForm()) { %> <fieldset> <%= Html.Input(c => c.Name) %> <%= Html.Input(c => c.Email) %> <%= Html.Input(c => c.Phone) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

Nice! Now we're on the road to consistent output in all forms in our MVC app and we won't spend as much time typing up view code. Eric even shows us he can name that view in one note:

<%= Html.InputForm() %>

Future

If you've been following the latest on ASP.NET MVC, you've seen the announcement for MVC 2 Preview 1 here, here, and here. Microsoft is going the same direction as these open-source extensions and making it easier to get a consistent view rendered:

<% using (Html.BeginForm()) { %> <fieldset> <%= Html.LabelFor(c => c.Name) %> <%= Html.EditorFor(c => c.Name) %> <%= Html.LabelFor(c => c.Email) %> <%= Html.EditorFor(c => c.Email) %> <%= Html.LabelFor(c => c.Phone) %> <%= Html.EditorFor(c => c.Phone) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

MVC 2 also has an almost one-liner form that you define with templates, one of the new features:

<% using (Html.BeginForm()) { %> <fieldset> <%= Html.EditorFor(c => c) %> <%= Html.SubmitButton() %> </fieldset> <% } %>

So we've seen views getting simpler and smaller and even one-line forms. Can it get any smaller than a one-line form? What if there was no view? Can you have a view with zero lines of code?

Kind of. Phil Haack took the MVC 2 Preview 1 code out for a spin to try what he calls "default templated views". The idea is that your controller gets a model and displays a virtual view by using templates from your web project's "~\Views\Shared" folder. You can make as many templates as you need for different purposes.

This is ideal for CRUD apps or places in your app where the view is the same except for the model data it renders. You don't need a physical file for each view other than the template itself. The controller just renders a view that is one of the shared views/templates.

I like this approach because you can crank out code more quickly for the easy stuff, but if you have a view that needs something more complex, you still have the normal HTML inputs and helpers to fall back on. I hope Microsoft gets this idea fully flushed out and it ends up in the final MVC 2 release. It would make developers more productive on repetitive views and would have wider acceptance if it was in the MVC base-class libraries.

Combining batch edit and detail template edit on a Kendo UI grid

Sat, 13 Feb 2021 07:11:25 Z

A client recently asked for something I didn't know a Kendo UI grid could do. They wanted both batch edit and a detail/expand edit of the same record in the grid.

They liked the Excel-like editing experience of working in batch mode, where you make a bunch of edits and send all the changes at once. But they also wanted several UI features in the expanded/detail view that don't make sense in a grid row (e.g., charts, hyperlinks, buttons to calculate things, etc.). The idea was that users could use whatever fit their needs or preference, then save all grid changes as usual in a batch.

I got it mostly working with this code, which is using this HTML and JavaScript: https://jsfiddle.net/joewilson0/jwcLhtg2/

<div id="myGrid"></div>
<script type="text/x-kendo-template" id="myDetailTemplate"> <div class="form-group"> <label for="testNumber">Test Number</label> <input name="testNumber" class="form-control w-25" data-bind="value: testNumber" /> </div> <div class="form-group"> <label for="testString">Test String</label> <input name="testString" class="form-control w-25" data-bind="value: testString" /> </div> <div class="form-group"> <label for="testDate" class="d-block">Test Date</label> <input name="testDate" class="form-control" data-bind="value: testDate" data-role="datepicker" /> </div> </script>

$(document).ready(() => { const testData = [ { testNumber: 123, testString: "apple", testDate: new Date(2020, 10, 14) }, { testNumber: 456, testString: "pear", testDate: new Date(2020, 10, 15) }, { testNumber: 789, testString: "plum", testDate: new Date(2020, 10, 16) }, ]; $("#myGrid").kendoGrid({ dataSource: { data: testData, schema: { model: { fields: { testNumber: { type: "number" }, testString: { type: "string" }, testDate: { type: "date" } } } } }, columns: [ { field: "testNumber", title: "Test Number" }, { field: "testString", title: "Test String" }, { field: "testDate", title: "Test Date", format: "{0:d}" } ], editable: true, detailTemplate: kendo.template($("#myDetailTemplate").html()), detailInit: event => kendo.bind(event.detailRow, event.data) }); });

This line is the key to having the grid row and the expanded view share the same view model:

detailInit: event => kendo.bind(event.detailRow, event.data)

Now when you change a value in the grid row, it updates immediately in the expanded row. Great! But when you do the reverse, and update the expanded row value, the grid row updates, but the expanded row immediately collapses. Arg!

The fix to prevent closing the expanded row was to ignore the itemchange action in the dataBinding event:

function dataBinding(event) { // Prevent closing the expanded detail row when the itemchange action in the databinding event is fired so it doesn't close the expanded view if (event.action === "itemchange") { event.preventDefault(); } }

But this workaround fixes one thing and breaks another. Now the row doesn't collapse every time you change a value in the expanded view, but it also doesn't update the grid row values when you collapse because you just short-circuited that event.

To fix this new problem, I added a "Done" button to the template that collapses the expanded row and wired up a function to repaint the values in the grid row on collapse.

<button class="btn btn-secondary btn-collapse">Done</button>

If the user changes 3 things in the expanded view and keeps the expanded view open, the grid row still shows the original, unchanged values. Once the user clicks the "Done" button or collapses the expanded view with the icon on the left, the grid row is repainted with the values from the shared view model.

function repaintRow(row) { const grid = $(row).closest(".k-grid").data("kendoGrid"); const dataItem = grid.dataItem(row); const rowChildren = $(row).children("td[role='gridcell']"); for (let i = 0; i < grid.columns.length; i++) { const column = grid.columns[i]; const template = column.template; const cell = rowChildren.eq(i); if (column.field !== undefined) { if (template !== undefined) { // Handle templated columns const kendoTemplate = kendo.template(template); cell.html(kendoTemplate(dataItem)); } else { const fieldValue = dataItem[column.field]; const format = column.format; const values = column.values; if (fieldValue && values) { // Handle drop downs for (let j = 0; j < values.length; j++) { const value = values[j]; if (value.value === fieldValue.toString()) { cell.html(value.text); break; } } } else if (format !== undefined) { // Handle formatted columns (like dates and currency) cell.html(kendo.format(format, fieldValue)); } else { // Handle unformatted, untemplated, non-drop down values cell.html(fieldValue); } } } }
}

Now we have to wire up the Kendo UI grid and button events:

$("#myGrid").kendoGrid({ ...other grid settings... detailInit: detailInit, detailCollapse: detailCollapse, dataBinding: dataBinding, ...other grid settings... }); function detailInit(event) { const grid = $(event.masterRow).closest(".k-grid").data("kendoGrid"); const masterRow = event.masterRow; const detailRow = event.detailRow; // Bind the expanded view (detailRow) to the values in the master row kendo.bind(detailRow, event.data); // Handle the detail row "Done" button click detailRow.find(".btn-collapse").click(() => grid.collapseRow(masterRow));
}

Here's the final working version that keeps the Kendo UI grid row and the expanded view in sync: https://jsfiddle.net/joewilson0/e3p70jac/2/

Do we still need coding standards?

Thu, 08 Jul 2010 00:40:47 Z

The dark ages

I used to be really big on coding standards in the late 1990's. It was so easy to slip into spaghetti code in classic ASP and VB6, and at the time, the best antidote was rigid standards and uncompromising code reviews.

I was a hard ass about our coding standards. Then, as now, the rationale was that coding standards would make the code easier to read and maintain in the inevitable and long maintenance phase.

The development process we used at the time was to stand around the white board and talk about the development tasks, then the developers would go off and separately code it up. That was the other reason the coding standards mattered - we didn't want two code files to look totally different if written by different developers.

My teams used the naming conventions Microsoft came up with for Access/VBA/VB, including Hungarian notation prefixes, but a lot of the standards were about code comments, error handling code, whitespace and indenting, etc.

.NET comes on the scene

Fast forward maybe 5 or so years to the introduction of .NET and C#, and coding changed. ASP.NET HTML didn't require <% %> tags anymore. We could put the C# in code behind files and other project files. We didn't need On Error anymore, we had Try-Catch. XML comments seemed like a cool feature to show Intellisense drop downs for code you wrote in addition to framework Intellisense.

So we updated our coding standards to reflect the language and IDE changes, but they became more like guidelines instead of hard and fast rules. By convention, we would avoid the spaghetti code just by keeping the right code in the right place. Hungarian notation went away (slowly but surely). The coding standards document was mostly reference code snippets and justifications for the conventions we used. Code reviews became less common because it wasn't as big of an issue.

Today

A lot has changed since .NET first came out, and I code differently now. I'm trying to make my code a lot more terse these days. I'm a big fan of having clean, succinct, expressive code. The fewer non-essential things on the screen to wade through, the better. It's more readable and easier to refactor.

I could put Try-Catch blocks everywhere, but isn't it simpler to catch unhandled exceptions in one place.

I could add XML comments, but why? It's either code in my same web project or a project that is owned by my solution. I don't usually work on common library code where an assembly will be used across projects and Intellisense might be needed.

I don't put the variable type on the left side of the equal sign anymore and use "var" instead.

I've walked away from code regions and just order the items in the class file by convention. ReSharper likes to put new fields under the last field declaration in the class, so region wrapping all the fields in a class with "#region Fields" just wastes time when refactoring to pull it back up into the region.

Not only has the way I code changed, but the tools have changed. ReSharper code cleanup templates and StyleCop warnings can be used to keep your team writing code in a style that you've all agreed on. Just run the tool and have it clean up the code for you or flag code that doesn't meet the style guidelines.

Having tests around the code lets me refactor and use auto-code-cleanup tools freely. I understand the project a little more fully every day, so I can rename my class, method, and variable names to be more descriptive and accurate without worrying about breaking code.

I'm also doing more pair programming these days, and this is a good way to enforce and socialize team coding styles. It also means we don't have to refer to a coding standards document as often. Since we're more story-focused, we're thinking more about the feature and less about coding style. Taking ceremony code off the screen helps us keep that focus.

If I had to do it over

If I was going to write a coding standards document today, it would be more like a style guide to reflect my current less-is-more thinking, and I'd probably give my peers a ReSharper template to auto-clean their code as they go instead of a document to refer to. StyleCop for ReSharper looks promising as a gentle background reminder of team coding styles.

What about your team? Do you have a coding standards document people refer to? Do you use tools to enforce standards/styles? Does your code tell a story other developers can read?

Making spiffy buttons with CSS and MVC Razor helpers

Sun, 16 Sep 2012 06:07:00 Z

For most web apps, gray buttons with black text is fine. But if you take some time to jazz up your buttons a little, you are making your app a little nicer to use and giving your users small visual cues to let them know their options.

Going from this:

to this:

with hover colors of green and red, which, in the U.S. at least, usually mean "go" and "stop", can be just enough of a nudge to help your users and make them just a little happier. Here's how I built these.

Credit

The bulk of the concept and CSS work for this came from someone else, but I can't remember who anymore. It's been over a year since I started using this technique. It might be from an old version of HTML5 Boilerplate, Blueprint CSS, 960 Grid System, or something Rob Conery did on TekPub. I wish I could give more specific attribution, but it was probably one of these. My main contributions have been some CSS tweaks, the JavaScript, and the MVC Razor helpers.

HTML and images

This is what we're going for as the emitted HTML. We want these "buttons" to really be hyperlinks, not HTML buttons, so we don't have as much browser style sheet nonsense getting in the way.

This does add some complexity for submitting, which has to be done with JavaScript now, but the same script (see below) can be used throughout the app.

The positive CSS class gives the green hover effect, and the negative one gives the red effect.

<div class="buttons"> <a href="#" class="button positive"> <img width="16" height="16" src="/Content/Images/Icons/tick.png" alt=""> Save </a> <a href="https://volaresoftware.com/en/posts/archive" class="button negative"> <img width="16" height="16" src="/Content/Images/Icons/cross.png" alt=""> Cancel </a> </div>

The icons I used are from the Silk Icons collection. There are lots of great icon libraries out there, so use your favorite. Anything 16x16 should work, but you can go bigger or smaller and adjust the CSS and HtmlHelper tags.

JavaScript/jQuery

An anchor tag with a href to "#" won't get your values submitted back to the server, so we'll use some JavaScript and a touch of jQuery for that. You'll want to include this script on every page where you're using these buttons.

$(function () { global.initButtons(); });
var global = { initButtons: function () { $('a.button.positive').click(function (e) { e.preventDefault(); var parentForm = $(this).closest('form'); if (!parentForm.valid()) { global.flashMessage('Error validating these values', 'error'); } else { $(this).css(global.disableCss).unbind('click'); parentForm.submit(); } }); }, disableCss: { opacity: 0.5, display: 'inline-block' } };

CSS

The CSS for this is pretty simple. The div.buttons puts the buttons on one line and give a little vertical space around them. The .button and .button img styles do most of the work, with block styling, light and medium gray borders, a light gray background, some padding around the text and icon to fatten the button up a little, margins so there is space before the next adjacent button on the right, and a small shadow effect.

The :hover effects are where the color is flipped to darker gray, green, or red, with corresponding border colors.

/*--------------------------*/ /* Buttons /*--------------------------*/ div.buttons { display: inline-block; margin: 10px 0; } .button { display: block; float: left; border-top: 1px solid #CCC; border-left: 1px solid #CCC; border-bottom: 1px solid #AAA; border-right: 1px solid #AAA; background-color: #E3E3E3; font-family: Verdana, Helvetica, sans-serif; font-size: 100%; line-height: 110%; text-decoration: none !important; color: #333 !important; margin: 0 15px 0 0; padding: 5px 10px 5px 7px; cursor: pointer; box-shadow: 1px 1px 2px #969696; -moz-box-shadow: 1px 1px 2px #969696; /* Firefox */ -webkit-box-shadow: 1px 1px 2px #969696; /* Safari and Chrome */ } .button img { margin: 0 3px -3px 0 !important; padding: 0; border: none; width: 16px; height: 16px; float: none; } /--------------------------/ /* Button colors - Standard /--------------------------/ .button:hover { border: 1px solid #999; background-color: #D6D6D6; color: #333 !important; } /--------------------------/ /* Button colors - Positive /--------------------------/ .positive:hover { background-color: #E6EFC2; border: 1px solid #C6D880; color: #264409 !important; }
/--------------------------/ /* Button colors - Negative /--------------------------/ .negative:hover { background-color: #FBE3E4; border: 1px solid #FBC2C4; color: #8A1F11 !important; }

MVC Razor HtmlHelpers

So now we know the HTML and CSS we want. You could stop there and code your MVC views with that HTML. But if you want your Razor views to be able to user simple helpers like this, keep reading.

<div class="buttons"> @Html.LinkButtonForSave() @Html.LinkButtonForCancel() </div>

The helpers here have two public entry points, LinkButtonForSave and LinkButtonForCancel. The rest of the code is refactoring out some of the route parsing and tag building work. It's probably overkill for just these two methods, but it makes sense when you keep adding helpers for other buttons, like add, edit, delete, confirm, print, etc.

using System.Web; using System.Web.Mvc; namespace Extensions { public static class ButtonHelpers { public static MvcHtmlString LinkButtonForSave(this HtmlHelper helper) { var imageTag = ImageTag("tick.png"); var anchorHtml = FormSubmitAnchorTag(imageTag, "Save"); return MvcHtmlString.Create(anchorHtml); } public static MvcHtmlString LinkButtonForCancel(this HtmlHelper helper) { var areaName = AreaName(helper); var controllerName = ControllerName(helper); var imageTag = ImageTag("cross.png"); var anchorHtml = AnchorTagWithImageAndText(areaName, controllerName, "Index", null, "button negative", imageTag, "Cancel"); return MvcHtmlString.Create(anchorHtml); } private static TagBuilder ImageTag(string iconName) { var imageTag = new TagBuilder("img"); imageTag.MergeAttribute("src", VirtualPathUtility.ToAbsolute(string.Format("~/Content/Images/Icons/{0}", iconName))); imageTag.MergeAttribute("width", "16"); imageTag.MergeAttribute("height", "16"); imageTag.MergeAttribute("alt", ""); return imageTag; } private static string AreaName(HtmlHelper helper) { var routeData = helper.ViewContext.RouteData; return routeData.DataTokens["area"] == null ? string.Empty : routeData.DataTokens["area"].ToString(); } private static string ControllerName(HtmlHelper helper) { var routeData = helper.ViewContext.RouteData; return routeData.GetRequiredString("controller"); } private static string FormSubmitAnchorTag(TagBuilder imageTag, string anchorText) { var anchorTag = new TagBuilder("a"); anchorTag.MergeAttribute("href", "#"); anchorTag.AddCssClass("button positive"); anchorTag.InnerHtml = imageTag.ToString(TagRenderMode.SelfClosing) + anchorText; return anchorTag.ToString(); } private static string AnchorTagWithImageAndText(string areaName, string controllerName, string actionName, int? id, string cssClass, TagBuilder imageTag, string anchorText) { var anchorTag = new TagBuilder("a"); if (areaName != string.Empty) { anchorTag.MergeAttribute("href", id == null ? string.Format("/{0}/{1}/{2}", areaName, controllerName, actionName) : string.Format("/{0}/{1}/{2}/{3}", areaName, controllerName, actionName, id)); } else { anchorTag.MergeAttribute("href", id == null ? string.Format("/{0}/{1}", controllerName, actionName) : string.Format("/{0}/{1}/{2}", controllerName, actionName, id)); } anchorTag.AddCssClass(cssClass); anchorTag.InnerHtml = imageTag.ToString(TagRenderMode.SelfClosing) + anchorText; return anchorTag.ToString(); } }
}

Using the Should assembly for testing

Tue, 24 Aug 2010 00:40:45 Z

Should is a .NET assembly of extension methods for building easy to write and easy to read assert statements. The advantage of using this assembly is the syntax is more clear and more like human language. It's free, open source, and it doesn't matter if you're using NUnit or MSTest or any test runner (Test Driven .NET, ReSharper, etc.). The project is in Beta 1.1, but I've used it on a couple of projects now with no problems.

I've never really liked the MSTest way of doing an assert. The whole expected and actual arguments always seemed flipped around to me.

// Assert Assert.AreEqual("eggs", breakfast.Foods.First()); Assert.AreEqual("bacon", breakfast.Foods.Last());

Instead, just reference the Should assembly and add the

using Should;

statement to the top of your test code and you can change it to:

// Assert breakfast.Foods.First().ShouldEqual("eggs"); breakfast.Foods.Last().ShouldEqual("bacon");

I think one of the tricks to writing good tests is to have code that is dead simple to read when you come back to it much later. The Should assembly gives you that.

Here are some other calls from the CodePlex home page for the project:

public void Should_String_assertions() { var obj = new object(); obj.ShouldBeInRange(1,2); obj.ShouldBeNull(); obj.ShouldBeSameAs(new object()); obj.ShouldBeType(typeof (object)); obj.ShouldEqual(obj); obj.ShouldNotBeInRange(1,2); obj.ShouldNotBeNull(); obj.ShouldNotBeSameAs(new object()); obj.ShouldNotBeType(typeof(string)); obj.ShouldNotEqual("foo"); "This String".ShouldContain("this"); "This String".ShouldNotBeEmpty(); "This String".ShouldNotContain("foobar"); false.ShouldBeFalse(); true.ShouldBeTrue(); var list = new List<object>(); list.ShouldBeEmpty(); list.ShouldNotContain(new object()); var item = new object(); list.Add(item); list.ShouldNotBeEmpty(); list.ShouldContain(item);
}

You should check it out!

Tree shaking with Font Awesome and webpack

Mon, 29 Jan 2018 06:30:00 Z

Font Awesome 5 has a new tree shaking feature that works with webpack's tree shaking. This is really helpful so you don't have to download one giant JavaScript file with a bunch of SVG icon definitions in it like:

<script defer src="https://use.fontawesome.com/releases/v5.0.6/js/all.js"></script>

Which gets you file sizes like below, where all.js is 657 KB (278 KB gzipped) and index.js is 88 bytes.

Instead, you can limit the file size to only the icons you use in your project through ES2015+ module imports and get file sizes like this, where all.js is gone and index.js is now 33.3 KB gzipped. We just saved 600+ KB (or about 250 KB gzipped)!

The Font Awesome team wrote some nice documentation on how to do this, but I didn't need to reference the shakable modules to get the smaller file size benefits. Here's how I got it working with Font Awesome 5 and webpack 3.

What worked

This is the HTML for the index.html test page.

<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Tree shaking with FontAwesome and webpack</title> <link href="https://volaresoftware.com/blog/node_modules/bootstrap/dist/css/bootstrap.min.css" rel="stylesheet" /> </head> <body> <div class="text-center" style="font-size: 24px; margin-top: 30px;"> <div class="row"> <div class="col-xs-2"> <div> <I class="far fa-calendar-alt"></I> </div> Calendar </div> <div class="col-xs-2"> <div> <I class="far fa-envelope"></I> </div> Email </div> <div class="col-xs-2"> <div> <I class="fas fa-arrow-up"></I> </div> Arrow Up </div> </div> </div> <script src="/dist/lib.js"></script> <script src="/dist/index.js"></script> </body> </html>

And this is index.js.

import fontawesome from "@fortawesome/fontawesome"; import farCalendar from "@fortawesome/fontawesome-free-regular/faCalendarAlt"; import farEnvelope from "@fortawesome/fontawesome-free-regular/faEnvelope"; import fasArrowUp from "@fortawesome/fontawesome-free-solid/faArrowUp";
fontawesome.library.add(farCalendar, farEnvelope, fasArrowUp);

In the markup, I'm pulling in lib.js, which webpack will figure out from the commons chunk (see below about what that is), and index.js, whose code is nothing but some icon imports.

In Font Awesome 5, you can now import a single icon, multiple icons, a full set of icons (the solid, regular, light, or brand sets), or every icon they make (free or pro). If you want the tree shaking and small file size benefit, you have to import the Font Awesome library and add your newly imported icons to the library before they can be used, like I've done above.

Here is the webpack.config.js file.

const webpack = require("webpack"); const path = require("path"); const CleanWebpackPlugin = require("clean-webpack-plugin"); const UglifyJsPlugin = require("uglifyjs-webpack-plugin");
module.exports = () => { return { entry: { index: "index.js" }, output: { filename: "[name].js", path: path.resolve(__dirname, "dist"), publicPath: "/dist" }, devtool: "source-map", plugins: [ new CleanWebpackPlugin(["dist"]), new webpack.optimize.CommonsChunkPlugin({ name: "lib" }), new UglifyJsPlugin({ sourceMap: true, uglifyOptions: }) ], resolve: { extensions: [ ".js" ], modules: [ path.resolve(__dirname, "scripts"), "node_modules" ] }, module: { rules: [ { test: /.js$/, exclude: /node_modules/, use: { loader: "babel-loader", options: { presets: ["env"], babelrc: false, cacheDirectory: true, plugins: [ "transform-runtime"] } } } ] } }; };

If you're used to seeing webpack.config files, there isn't anything too novel going on. If you aren't, here's the gist: There is one application entry point, index.js. Files will be output to the /dist folder. Source maps are turned on. We clean the /dist folder before a build. We have a commons chunk called lib.js, which means webpack figures out code shared across modules that can be extracted into a common file. We are minifying with UglifyJS and setting its source map flags to true also. We have the UglifyJS dead code (tree shaking) flag set to true, but I get the same results with or without that setting turned on. The resolve section tells webpack where to look for files, and the module rule we have set is to use Babel to load *.js files unless the file comes from the node_modules folder (so use Babel's loader for our projects' scripts).

I'm pretty happy with this, and for a project with a handful or even several handfuls of icons, it probably makes sense to import just the ones your project uses. One option is to make a selectedIcons.js file, set up all your imports and Font Awesome library additions there, and import selectedIcons.js in your single entry or for pages with icons if you have a multiple entries project.

What didn't work

The Font Awesome documentation describes some special modules you can set up through webpack.config aliases, and when you import from those files, you get tree shaking.

I changed the webpack.config.js resolve section to this.

resolve: { extensions: [ ".js" ], modules: [ path.resolve(__dirname, "scripts"), "node_modules" ], alias: { "@fortawesome/fontawesome-free-solid$": "@fortawesome/fontawesome-free-solid/shakable.es.js", "@fortawesome/fontawesome-free-regular$": "@fortawesome/fontawesome-free-regular/shakable.es.js" } },

Then I changed index.js to import with a different syntax.

import fontawesome from "@fortawesome/fontawesome"; import { faCalendarAlt, faEnvelope } from "@fortawesome/fontawesome-free-regular"; import faArrowUp from "@fortawesome/fontawesome-free-solid";
fontawesome.library.add(faCalendarAlt, faEnvelope, faArrowUp);

Then I re-built the code. The page still works, but the index.js file got waaaay bigger.

I don't know if I missed something in my webpack.config.js, or I've imported with the wrong syntax, or I've referenced the special shakable files incorrectly, but I couldn't get it working. If you see my mistake, please comment below and I'll update the post.

Either way, it works to import and add individual icons, and you get smaller files. All the code for this post can be found on GitHub.

Stop making hay

Sat, 25 Dec 2010 01:40:33 Z

Straw men

When test-driven development (TDD) or other test-first methods are first introduced, many people object with different variations of the same argument "if you can't test everything, it's flawed". People seem to get mentally stuck when they can't automate all test cases. Sometimes, the point gets really stretched, like, "What if the user enters a negative salary lower than int.MinValue? We don't have a test for that, do we?" or "What if the database or web server goes down? How do we do TDD for that?"

Darren Cauthon made this observation on Twitter a few months ago:

All these arguments are straw men, where an exaggeration or misrepresentation of the point is used to discount the entire thing.

Getting started

TDD won't make all your problems go away or all your dreams come true. It's something that takes a lot of practice to get better at it. I consider myself pretty mediocre at it. You will be slower at coding when you start out, but you will get faster, and I believe it is worth the investment in terms of the cleaner design it yields. The tests are nice, too. :>

The trick for me to getting started with TDD was to start small. This has also been the only way I've been able to do TDD successfully - in very small steps. Create one test for the happy path for the feature you are trying to implement. This usually has to be broken down into sub steps. Write the least amount of code you can write to get the test to pass. Once the test is passing, refactor the code to clean it up and add some polish. Then run your test again to make sure it still passes.

Unhappy paths

Occasionally test the unhappy paths, based on how likely they are and how important they are to the business. If your product owner isn't worried about int.MinValue, you shouldn't be. Move on to the next feature you're building.

You probably won't automate all your test cases, but that's OK. Your code will be decoupled, easier to refactor, and easier to read. Plus you will have automated tests for whatever percentage of tests cases you came up with.

There are far too many benefits to dismiss test-first approaches based on what it can't do well. So let's stop with the straw man arguments against test-first and start reaping the benefits.

Why bother writing unit tests?

Thu, 08 Oct 2009 00:41:38 Z

More developers are coming around to the idea of writing unit tests for their code. But not everyone is sold. Let's take a look at the arguments for just writing code and either manually testing or handing the app over to QA:

It takes too long to write unit tests.

This is really simple code. I could see maybe testing something complex, but this is just a CRUD app.

Write my tests before my code? Are you kidding me? I've always done it the other way and it's worked out just fine.

Let's take these one by one and see if they are still valid.

Time Argument

It doesn't take long to run the test. I think there is consensus there. But writing units tests and writing code is more lines of code than just writing the code. More lines = more time, right?

Sure, as long as manual testing is less than the automated testing over time. Not just the first time, but for the lifetime of that code.

If I'm using your old assembly from 2004 or web service from last month, I want some assurances it still works the way it was supposed to. If you knew the secret way to manually test it, but have forgotten it, I don't fully trust your code. I have to spend time going over that code and testing it out myself.

Code with a lifespan longer than your memory and availability to manually regression test it benefits from having a suite of unit tests that can be run in milliseconds.

Simplicity Argument

"If the code is really simple, there is no point in writing unit tests."

This is a good point. Unit testing can help work through complex code, but what if the code is really easy?

I agree that there isn't a need to bother testing setting and getting properties and methods that just call other methods. And please don't spend time testing code that is part of the .NET framework or an assembly you bought. That's a waste of time.

But if you're using test-driven development, you start with the functionality, not the implementation. So you write tests that cover the important/core stuff in your requirements. You don't bother testing properties and call wrappers, which are just technical artifacts of the important stuff you are coding. If it's the important stuff, shouldn't it be covered with unit tests?

TDD = My World Upside Down

"Writing test before writing code is crazy talk." I also have had a great career without doing this, so what's the point?

I agree it is crazy. I also agree it's a 180 on the conventional wisdom. And I completely agree that it's harder than just writing the code.

But here's where I depart from the TDD crowd. If you're new to unit testing, I just want you to write unit tests to cover the critical code for now. It might lead you to TDD at some point, it might not. But it's not an all or nothing thing. Let's just try to work in as many tests as we can and leave it there for now. How many tests do you need? What code coverage levels are you shooting for? That's up to you. If you feel good showing the code to your peers and are happy to be held accountable for the quality of your code, you're probably done.

I'll make the case for TDD another time. Just baby steps for now.

HtmlEncode and UrlEncode aren't the same thing

Sat, 29 Jan 2011 07:43:00 Z

The other day I was trying to pass an encoded version of id=123 to a customer's search API. I tried

var result = HttpUtility.HtmlEncode("id=123");

but it returned id=123. I stared at the screen, scratched my head, and jumped on Google.

A quick search reminded me that HtmlEncode is for escaping HTML, but it leaves everything else alone. So

var result = HttpUtility.HtmlEncode("<br/>");

returns <br/>. All the less thans and greater thans get escaped, but the rest is pretty much the same.

UrlEncode is for cases where you want to escape a URL, so

var result = HttpUtility.UrlEncode("id=123");

returns id%3d123, which is what I wanted in the first place. By comparison, if you UrlEncode the <br/> tag, like

var result = HttpUtility.UrlEncode("<br/>");

you'll get back %3cbr%2f%3e. It's encoding the less than, the slash, and the greater than, but it's encoding them with URL-type escapes instead of HTML-style ones.

I guess it's been a while since I paid attention to encoding. Not all encoding methods are equal in the ASP.NET framework, so be careful which one you use.

Resizing a Kendo UI drop down to fit its data without wrapping

Sat, 02 Feb 2013 13:19:00 Z

Telerik's Kendo UI Web makes a spiffy looking drop down with JavaScript and CSS.

The demos on the Telerik site show drop downs with default widths and not much text.

That breaks down when the text in the drop down gets longer because it wraps. I don't like this look.

So I wrote a JavaScript function that resizes the drop down to fit the width of the data so you avoid the wrapping and get:

Here's the JavaScript:

var resizeDropDown = function (e) { var $dropDown = $(e.sender.element), dataWidth = $dropDown.data("kendoDropDownList").list.width(), listWidth = dataWidth + 20, containerWidth = listWidth + 6; // Set widths to the new values $dropDown.data("kendoDropDownList").list.width(listWidth); $dropDown.closest(".k-widget").width(containerWidth);
}

You have to call this on the drop down's dataBound event. That way, if you're pulling remote data through something like Web API, you won't resize until you've gotten the data back and fired the dataBound event.

Here's a JSFiddle to play around with it. The fiddle shows two drop downs – one with the default sizing and wrapping, and the other with the resizeDropDown function called on the dataBound event.

Trim unused CSS selectors with PurifyCSS and webpack

Mon, 16 Apr 2018 21:49:00 Z

Most web sites use a CSS library like Bootstrap. It's great for getting started quickly and works well as an all-purpose style sheet.

But what about all the selectors in Bootstrap you aren't using in your app? What if you also add a Bootstrap theme and your own web app style overrides on top of that? All the used and unused styles go down to your users' browsers with every response.

If you can trim that down to only the styles your web app actually uses, you'll send down a much smaller style sheet, your site will run faster, and you'll save on bandwidth costs.

Here's how I did just that with PurifyCSS and webpack.

Install webpack and PurifyCSS

Once you've got Node and NPM up and running, install webpack 4.

npm install webpack webpack-cli --save-dev

Then install PurifyCSS and the MiniCssExtractPlugin, if you don't already have it set up.

npm install purify-css purifycss-webpack glob-all mini-css-extract-plugin --save-dev

Set up PurifyCSS in webpack.config.js

In your webpack.config.js file, add a reference to the MiniCssExtractPlugin, the PurifyCSS plugin, and a way to glob files.

const glob = require("glob-all"); const MiniCssExtractPlugin = require("mini-css-extract-plugin"); const PurifyCSSPlugin = require("purifycss-webpack");

Then set up your paths in PurifyCSS. These are the locations of the files that will contain your styles. PurifyCSS will statically scan these files for styles and reference them in the style sheet. Styles found in the markup or scripts are left in the final style sheet. Styles not found are removed. The algorithm for finding used styles is pretty sophisticated.

plugins: [ new MiniCssExtractPlugin({ filename: "[name].css" }), new PurifyCSSPlugin({ paths: glob.sync([ path.join(__dirname, "Views/**/*.cshtml"), path.join(__dirname, "Scripts/**/*.html"), path.join(__dirname, "Scripts/**/*.js") ]) }) ],

Here, I'm referencing my ASP.NET MVC Razor pages in Views/**/*.cshtml, my component templates in Scripts/**/*.html, and my project *.js files. Also note this plugin entry goes after the MiniCssExtractPlugin.

Add any whitelist exceptions

Even with it's fancy algorithm, PurifyCSS can still miss styles it should leave alone. To prevent PurifyCSS from removing them from the final CSS, use the whitelist option.

Here, I've got a project style sheet with two styles – one that should be removed because it is not referenced, and one that should be left in even though it isn't referenced.

.some-unused-class { color: red; }
.some-dynamic-class { color: red; }

To do this, I've added "*some-dynamic-class*" to the whitelist array so PurifyCSS won't remove it.

plugins: [ new MiniCssExtractPlugin({ filename: "[name].css" }), new PurifyCSSPlugin({ paths: glob.sync([ path.join(__dirname, "Views/**/*.cshtml"), path.join(__dirname, "Scripts/**/*.html"), path.join(__dirname, "Scripts/**/*.js") ]), purifyOptions: { whitelist: ["*some-dynamic-class*"] } }) ],

Results

In the sample project, I'm using Bootstrap and a very small app style sheet. Here are the result before PurifyCSS.

And here are the result after PurifyCSS.

The sample site is a one-page site with a carousel component that references Bootstrap CSS, and as you would expect, the KB trimmed from removing unused CSS selectors is significant.

Here is what happened with that class .some-dynamic-class I put in the PurifyCSS whitelist. The .some-unused-class selector is removed as we'd expect, and the .some-dynamic-class is still in the final CSS file at the bottom.

All this code is on GitHub if you want to see the package.json or full webpack.config.js or mess around with this yourself.

Tree shaking with Bootstrap 4 and webpack

Sat, 24 Feb 2018 19:48:00 Z

The simplest way to use Bootstrap 4 is to add the whole thing from the CDNs.

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"> <title>Bootstrap Size Test</title> </head> <body> <div class="container"> <div class="row"> <div class="col-sm"> page </div> <div class="col-sm"> content </div> <div class="col-sm"> goes </div> <div class="col-sm"> here </div> </div> </div> <script src="//code.jquery.com/jquery-3.2.1.slim.min.js"></script> <script src="//cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js"></script> <script src="//maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js"></script> </body> </html>

The problem is, you might not need everything Bootstrap has to offer. Adding the JavaScript like this adds 134.5 KB (ignoring gzipping for comparison below) to your page.

If you are using ES2015+ and the npm distribution, and you don't need the whole Bootstrap package, you can import just the code you need. Here's how.

Set up Bootstrap, Babel, and webpack

First, install Bootstrap, along with jQuery and Popper, which Bootstrap relies on. Then install webpack, along with tools to use ES2015+ syntax and minify JavaScript for distribution.

npm install bootstrap jquery popper.js npm install --save-dev webpack babel-core babel-loader babel-preset-env clean-webpack-plugin exports-loader path uglifyjs-webpack-plugin

Next, update your webpack.config.js to resolve the /node_modules folder. You're setting this up so your import statements know where to look when you reference Bootstrap modules.

You'll also need to use exports-loader with the webpack ProvidePlugin to export the expected values from the Bootstrap modules and their dependencies. This helps with globals some of the Bootstrap modules depend on, like $ for jQuery.

Finally, I've added an alias for jQuery to point to jquery.slim.min.js since that's enough jQuery functionality for Bootstrap to work. If you are already using the full jQuery in your project, skip this alias.

const webpack = require("webpack"); const path = require("path"); const CleanWebpackPlugin = require("clean-webpack-plugin"); const UglifyJsPlugin = require("uglifyjs-webpack-plugin");
module.exports = () => { return { entry: { index: "index.js" }, output: { filename: "[name].js", path: path.resolve(__dirname, "dist"), publicPath: "/dist" }, devtool: "source-map", plugins: [ new CleanWebpackPlugin(["dist"]), new webpack.ProvidePlugin({ $: "jquery", Popper: ["popper.js", "default"], Alert: "exports-loader?Alert!bootstrap/js/dist/alert", Button: "exports-loader?Button!bootstrap/js/dist/button", Carousel: "exports-loader?Carousel!bootstrap/js/dist/carousel", Collapse: "exports-loader?Collapse!bootstrap/js/dist/collapse", Dropdown: "exports-loader?Dropdown!bootstrap/js/dist/dropdown", Modal: "exports-loader?Modal!bootstrap/js/dist/modal", Popover: "exports-loader?Popover!bootstrap/js/dist/popover", Scrollspy: "exports-loader?Scrollspy!bootstrap/js/dist/scrollspy", Tab: "exports-loader?Tab!bootstrap/js/dist/tab", Tooltip: "exports-loader?Tooltip!bootstrap/js/dist/tooltip", Util: "exports-loader?Util!bootstrap/js/dist/util" }), new webpack.optimize.CommonsChunkPlugin({ name: "common" }), new UglifyJsPlugin({ sourceMap: true, uglifyOptions: }) ], resolve: { extensions: [ ".js" ], modules: [ path.resolve(__dirname, "scripts"), "node_modules" ], alias: { jquery: "jquery/dist/jquery.slim.min.js" } }, module: { rules: [ { test: /.js$/, exclude: /node_modules/, use: { loader: "babel-loader", options: { presets: ["env"] } } } ] } }; };

Import just the needed modules

Now you can import the Bootstrap style sheet from /node_modules, assuming you want the same styling on every page.

<link rel="stylesheet" href="https://volaresoftware.com/blog/node_modules/bootstrap/dist/css/bootstrap.min.css" />

You can also import Bootstrap styles from inside your webpack modules, but for most web apps, you'll want the same styling on all pages, and putting a link to the style sheet in the <head> is an easy way to do that.

Now you can write code that imports only the needed Bootstrap modules like this.

import "bootstrap/js/dist/carousel";

Let's say have a page that uses the Bootstrap carousel. Here's the HTML, including a reference to a webpack-built index.js from my /dist folder that only includes the carousel reference above.

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <link rel="stylesheet" href="https://volaresoftware.com/blog/node_modules/bootstrap/dist/css/bootstrap.min.css" /> <title>Bootstrap Size Test</title> </head> <body> <div class="container"> <div id="carouselExampleIndicators" class="carousel slide" data-ride="carousel"> <ol class="carousel-indicators"> <li data-target="#carouselExampleIndicators" data-slide-to="0" class="active"></li> <li data-target="#carouselExampleIndicators" data-slide-to="1"></li> <li data-target="#carouselExampleIndicators" data-slide-to="2"></li> </ol> <div class="carousel-inner"> <div class="carousel-item active"> <img class="d-block w-100" data-src="holder.js/800x400?auto=yes&amp;bg=777&amp;fg=555&amp;text=First slide" alt="First slide [800x400]" src="data:image/svg+xml;charset=UTF-8,%3Csvg%20width%3D%22800%22%20height%3D%22400%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20800%20400%22%20preserveAspectRatio%3D%22none%22%3E%3Cdefs%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E%23holder_161c9dd15ef%20text%20%7B%20fill%3A%23555%3Bfont-weight%3Anormal%3Bfont-family%3AHelvetica%2C%20monospace%3Bfont-size%3A40pt%20%7D%20%3C%2Fstyle%3E%3C%2Fdefs%3E%3Cg%20id%3D%22holder_161c9dd15ef%22%3E%3Crect%20width%3D%22800%22%20height%3D%22400%22%20fill%3D%22%23777%22%3E%3C%2Frect%3E%3Cg%3E%3Ctext%20x%3D%22285.921875%22%20y%3D%22217.7%22%3EFirst%20slide%3C%2Ftext%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E" data-holder-rendered="true"> </div> <div class="carousel-item"> <img class="d-block w-100" data-src="holder.js/800x400?auto=yes&amp;bg=666&amp;fg=444&amp;text=Second slide" alt="Second slide [800x400]" src="data:image/svg+xml;charset=UTF-8,%3Csvg%20width%3D%22800%22%20height%3D%22400%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20800%20400%22%20preserveAspectRatio%3D%22none%22%3E%3Cdefs%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E%23holder_161c9dd15f3%20text%20%7B%20fill%3A%23444%3Bfont-weight%3Anormal%3Bfont-family%3AHelvetica%2C%20monospace%3Bfont-size%3A40pt%20%7D%20%3C%2Fstyle%3E%3C%2Fdefs%3E%3Cg%20id%3D%22holder_161c9dd15f3%22%3E%3Crect%20width%3D%22800%22%20height%3D%22400%22%20fill%3D%22%23666%22%3E%3C%2Frect%3E%3Cg%3E%3Ctext%20x%3D%22247.3203125%22%20y%3D%22217.7%22%3ESecond%20slide%3C%2Ftext%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E" data-holder-rendered="true"> </div> <div class="carousel-item"> <img class="d-block w-100" data-src="holder.js/800x400?auto=yes&amp;bg=555&amp;fg=333&amp;text=Third slide" alt="Third slide [800x400]" src="data:image/svg+xml;charset=UTF-8,%3Csvg%20width%3D%22800%22%20height%3D%22400%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20800%20400%22%20preserveAspectRatio%3D%22none%22%3E%3Cdefs%3E%3Cstyle%20type%3D%22text%2Fcss%22%3E%23holder_161c9dd15f8%20text%20%7B%20fill%3A%23333%3Bfont-weight%3Anormal%3Bfont-family%3AHelvetica%2C%20monospace%3Bfont-size%3A40pt%20%7D%20%3C%2Fstyle%3E%3C%2Fdefs%3E%3Cg%20id%3D%22holder_161c9dd15f8%22%3E%3Crect%20width%3D%22800%22%20height%3D%22400%22%20fill%3D%22%23555%22%3E%3C%2Frect%3E%3Cg%3E%3Ctext%20x%3D%22277%22%20y%3D%22217.7%22%3EThird%20slide%3C%2Ftext%3E%3C%2Fg%3E%3C%2Fg%3E%3C%2Fsvg%3E" data-holder-rendered="true"> </div> </div> <a class="carousel-control-prev" href="#carouselExampleIndicators" role="button" data-slide="prev"> <span class="carousel-control-prev-icon" aria-hidden="true"></span> <span class="sr-only">Previous</span> </a> <a class="carousel-control-next" href="#carouselExampleIndicators" role="button" data-slide="next"> <span class="carousel-control-next-icon" aria-hidden="true"></span> <span class="sr-only">Next</span> </a> </div> </div> <script src="/dist/common.js"></script> <script src="/dist/index.js"></script> </body> </html>

The page now uses the same full Bootstrap CSS, which accounts for most of the Bootstrap weight at 141 KB. But the size of the JavaScript is just over 76 KB, saving us about 58 KB from the original approach.

It is much simpler to pull in the full Bootstrap library, but if you need to squeeze out a little more performance or shrink your page weight a little more, pulling in only the Bootstrap libraries you need can help.

The sample code for this post is available on GitHub.

Setting Default Values for Multiple Value Parameters in Reporting Services

Sat, 02 Oct 2010 00:40:40 Z

Today I was working on a Reporting Services report that needed to have all the values checked for a multi-value parameter when the report opened up. It was a little tricky to figure out, but it turned out to be very simple in the end.

Multiple Value Parameters

I've got some multiple value parameters on a report. These are easy to create in SQL Server Reporting Services. Just check the box for your parameter and the user gets a check box drop down letting them pick more than one value from the drop down.

Available Values

You can set the available values for the drop down to a dataset in your report or a shared dataset in the Reporting Services project. Next, pick the value and name fields (which can be the same column in the dataset if that's what works in your situation).

Default Values

This is the part where we want to check each of those multiple values on report startup. The hard part is, I don't know the values at design time, so I can't hard code them. I want to simulate a "select all" of the check boxes. My mind started wandering to VBA code I could put in the report as a startup function.

But on a whim, I tried selecting all the values from the same query, and I was pleased to see it work!

And I get the results I want on the report when it opens:

Fixing screen saver wait time of 999 minutes on a Dell laptop

Thu, 10 Mar 2011 01:40:18 Z

I have a Dell Precision M4500 with Windows 7 and ran into a problem with the screen saver not coming on. Rebooting didn't fix it and calling Dell technical support didn't help ("You could reformat, I guess.").

My screen saver dialog looked like this with 999 minutes in the wait time:

If I clicked Preview, the screen would go blank like it was supposed to, so it wasn't a video card thing. When I set the wait time to 10 minutes and clicked OK, then opened the dialog box again, my value of 10 minutes was saved, but the screen saver never turned on.

Finally, I found this dialog in the Dell System and Manager under Display Settings:

See the "Disable alarms and timers for Presentations" check box? I had that checked, so I unchecked it and the screen saver started working normally again. I wasn't in Presentation mode, but this Dell app didn't seem to know that.

I hope this is helpful to someone stuck on the same issue.

SpecFlow and WatiN Worst Practices: What *NOT* to do

Sun, 06 Jan 2013 05:05:00 Z

The best way to learn something is to jump right in. Best practices don't really emerge until you've found out what works and what doesn't. This is my list of things that didn't work on my four SpecFlow and WatiN projects in the last two years. Of course, I'll also talk about what did work.

Acknowledgements

First off, almost everything I know about SpecFlow/Cucumber/Gherkin I learned from Paul Rayner and pairing with with him on two projects. I'm grateful for the experience and the knowledge gained.

I've also tried to glean as much as I can from Marcus Hammarberg, Darren Cauthon, Richard Lawrence, and Brandon Satrom in their twitter feeds and articles.

What level of your app should you test?

One big issue that comes up around SpecFlow is what level of your application should you be testing – internal or external. The answer has a big impact on how you write your feature files, what side benefits you get from the feature files, and the speed of your tests.

Developer-facing

You can use SpecFlow as a BDD-style tool and do unit or light integration testing with it. I call these developer-facing feature files, because they are expressed in language internal to the application ("Then I post the form values to the AccountController"). The nice thing about this is the readability of the test from the dev side and the speed of execution, since you are explicitly testing code internals.

Business-facing

But I think this misses an opportunity to have richer language in the feature files. If the SpecFlow features are worded the way the product owner sees the app working, you are fostering a ubiquitous language between the business and the developers. You have a clearer vision of your app's external behavior expressed through concrete examples.

You end up with "Then I click the save button" or even better, "Then I save" instead of "Then I post the form values to the AccountController". The bad thing about this style of spec wording is you end up testing through UI test automation tools like WatiN. This testing style is slow and can be buggy and fragile if you aren't careful (see below for tips).

In my experience, one of the main problems in software development is getting the dev team to understand what the business wants built and why. SpecFlow is a great tool for getting both sides together to define that behavior through examples.

Furthermore, UI testing becomes much more important as web applications take on more and more JavaScript and other client-side code. Since the external behavior of the app is how the business and users will evaluate the app, I think it makes sense to test at this level.

How not to set up your test project

Acceptance tests that drive the browser are not unit tests. They are closer to integration tests, but they are even slower, since your local web server and the browser have to spin up each time and fill out forms, click buttons, etc.

Because of this, don't add SpecFlow to your current unit test project or even your current integration test project, if you separate those. Let it live in its own project with a name like MyProject.AcceptanceTests. For quick test running and CI, it's much easier to omit an entire assembly of tests, so keep these guys separate.

I find that I often want to run the faster unit tests and run the acceptance tests only around the parts of the application we are working on. I run the full suite maybe 2-5 times a week, especially before a hand-off to a stakeholder or a big demo.

How not to install SpecFlow and WatiN

Don't bother with DLL downloads or manually setting up file references. Install the SpecFlow NuGet package and the Visual Studio Extension. Let NuGet handle the assembly references and setting up the app.config for you. The VS Extension adds some nice feature file editing and right-click features to run a single test.

You'll need to decide on MSTest versus NUnit. The first comes with .NET, the later is free open source and you can add it with NuGet. If you're in a shop that heavily favors one over the other, use that. All you're using these for in the SpecFlow world is the generated code and the attributes marking your test fixtures and methods.

If you're using NUnit (the default), you'll need to be sure ApartmentState is set to "STA" in the app.config for your test project like this. If you use the NuGet download, it should take care of that.

Finally, you'll need WatiN, which can also be installed with a NuGet package. I've sometimes had to set some of the WatiN assemblies to Copy Local = true in the acceptance test project to get everything working. Kind of a hassle, but once it's set up right, you're done forever with it.

How not to set up a WebBrowser class and app.config

WatiN can run UI tests with Internet Explorer or FireFox (not Chrome, Safari, Opera, or anything else). The FireFox API didn't have parity with the IE one last time I checked, so I've gotten used to using the WatiN IE class.

However, don't reference this class directly, or all your code is IE dependent. What if the next version of WatiN supports an iPad emulator you want to use? Do you really trust your find-replace skills that much?

Instead, wrap the references with a static class, and reference that in your step definitions. Here's the one I'm using these days that gets an instance of IE in a static constructor:

namespace Helpers { public static class WebBrowser { private static IE _browser; static WebBrowser() { _browser = new IE(); _browser.ShowWindow(NativeMethods.WindowShowStyle.Maximize); } public static IE Current { get { return _browser; } set { _browser = value; } } public static string BaseUrl { get { return ConfigurationManager.AppSettings["BaseUrl"]; } } }
}

This is maximizing the IE window after it opens and adding a reference to a BaseUrl property, which is set in the app.config.

<appSettings> <clear/> <add key="BaseUrl" value="http://localhost:1234/"/>  </appSettings>

I use the BaseUrl to switch out the location of the test target in the step definitions (not shown above). So if I want to test locally, the BaseUrl is "http://localhost:1234/". If I want to hit the AppHarbor version, the BaseUrl "http://myapp.apphb.com/". Just change the app.config and run the tests.

How not to set up your SpecFlow Before and After attributes

SpecFlow has attributes that can be put over your step definitions for your setup and teardown code. Here are the hooks you have:

BeforeTestRun / AfterTestRun

BeforeFeature / AfterFeature

BeforeScenario / AfterScenario

I've struggled with where these go before, but the last couple projects I created a BeforeAndAfter.cs class (clever, huh?), set the SpecFlow [Binding] attribute to the top of the class, then added all my before/after code.

This is a great place to put database clean ups, security code if your app has a login, any custom SpecFlow tags you've created, etc. Here's the code I used on my last project:

using System.Configuration; using TechTalk.SpecFlow; using WatiN.Core; namespace Helpers { [Binding] public class BeforeAndAfter { [BeforeTestRun] public static void BeforeTestRun() { // Ignore all features and scenarios when running on AppHarbor if (ConfigurationManager.AppSettings["Environment"] == "Test") { Assert.Ignore(); return; } // Always login first Security.ILoginAsAdministrator(); } [AfterTestRun] public static void AfterTestRun() { // Logout to be ready for next session Security.ILogout(); // Close the browser and dispose WebBrowser.Current.Close(); WebBrowser.Current.Dispose(); // Reset the data to be ready for the next session TestData.CleanUp(); } }
}

I put all my helper methods like the WebBrowser.cs and BeforeAndAfter.cs in a /Helpers folder in the acceptance test project.

How not to organize your feature files

Feature files have one or more features in them. You could put each separate feature in it's on .feature file, but that's overkill.

I used to create a new feature file for each view in the app. That probably makes sense in some cases, but this approach often misses the value of those pages. For instance, if there are 2-3 pages for an e-commerce checkout process, it's probably not that helpful to have a feature file for BillingAndShippingAddress.feature, CreditCard.feature, and Confirmation.feature. It might be helpful to developers, but it's likely non-developers on the team see the checkout process more holistically, so why not start with a Checkout.feature file? If this gets too big, split out pieces into their own logical .feature files later.

I put all my feature files in a /Features folder in the acceptance test project. It's mostly cosmetic, but it does help a little.

How not to organize your step definition files

Step definitions are the implementation of the steps in the feature files. Since I was organizing feature files by web app page, I started out doing the same with step definitions. When you try this approach, you quickly see the problem, since step definitions can and should be reused across features.

If there is a step definition "Then I go to /MyPage", the step definition might be clicking a menu, a link in the page, or just opening a URL. As you can imagine, this can be helpful in lots of different feature files, so it makes more sense to group these in a Navigation.cs file or something like that. Maybe you have a separate Menu.cs with those step definitions, or maybe you lump them in with Navigation.

How you group these is up to you. SpecFlow sees all *.cs files with a [Binding] on them as places where your step definitions could live, and it uses regex matching to find the right method. SpecFlow doesn't care if you put your methods in one class or 100 classes, but you will. So put some thought into how you group these, because it's easier to see opportunities to refactor out similar code you find within the same .cs file versus across .cs files.

This makes the file names much more generic, but I've had the most success with this style. On recent projects, my step definition files have included Forms.cs, Menu.cs, Messages.cs, Navigation.cs, Search.cs, Security.cs, and SEO.cs.

I put all my step definition code in a /Steps folder. In the end, it looks like this:

How not to code step definitions

Step definition code in each method should be brief – like a couple lines. If you've got large blocks of code, you've probably got too much going on.

Maybe you have a giant form with tons of fields and a SpecFlow table feeding you the values. You can probably get away with something like this:

public void IFillOutTheForm(Table table) { foreach (var row in table.Rows) { var field = row["Field"]; var value = row["Value"]; switch (field) { case "Something Different": // Put exceptions here for drop downs, date pickers, radio buttons, etc. WebBrowser.Current.SelectList(Find.ByName("SomethingDifferentId")).Select(value); break; default: WebBrowser.Current.TextField(Find.ByName(field)).Value = value; break; } } }

Here, the "Something Different" case is where you would put non-textbox filling out code. But if your forms are like most business apps, there are lots of text boxes, a handful of drop downs, and a smattering of radio, checkbox, date pickers, sliders, etc. that require some different WatiN code.

Of course, if the exceptions outnumber the convention, make a separate method and see if you can factor out some common code to use somewhere else. Remember, the key to being productive with SpecFlow is reusing the step definitions, so once you start seeing duplication, look for ways to refactor to a common convention in your feature files and step definitions. It takes a while to get a critical mass of these built up, but once you do, you really start picking up speed.

Concatenating and decoding strings from a one-to-many table in SQL

Tue, 13 Oct 2015 10:23:43 Z

Let's say you have two tables in SQL Server: Person and PersonNotes. PersonNotes is a one-to-many table of notes about that Person. Here's the SQL for the tables:

create table Person (PersonId int not null) insert Person (PersonId) values (1)
create table PersonNotes (PersonId int not null, Note varchar(max)) insert PersonNotes (PersonId, Note) values (1, 'note <1>') insert PersonNotes (PersonId, Note) values (1, '& note #2') insert PersonNotes (PersonId, Note) values (1, '& finally, note <3>')

And let's say you need to grab all those PersonNotes rows and concatenate them into one string per Person row. You have a couple options: 1) create a custom function, 2) write a cursor, or 3) use T-SQL's FOR XML trick. I'll focus on the last one n this post.

Using FOR XML is kind of lame, since it's really meant for something else, but it works pretty well to pull all the strings across rows into one value:

select Person.PersonId, (select PersonNotes.Note + ' ' from PersonNotes where PersonNotes.PersonId = Person.PersonId for xml path('')) AS Notes from Person where Person.PersonId = 1

Here's the SQL Fiddle for this table setup and query. Running this will get you these results:

note &lt;1&gt; &amp; note #2 &amp; finally, note &lt;3&gt;

The problem is, putting it in XML means you get lots of "<", ">", and "&" where the strings have been encoded. That's what you want for XML, but it's not usually what you want for a string.

But if we use a little XPATH to pull the first node from that resulting XML, we do get the decoded values again:

select Person.PersonId, (select PersonNotes.Note + ' ' from PersonNotes where PersonNotes.PersonId = Person.PersonId for xml path(''), root, type).value('/', 'varchar(max)') AS Notes from Person where Person.PersonId = 1

Here's the SQL Fiddle for the tables setup and query with the extra XPATH casting back to varchar(max). Running this will get you these results:

note <1> & note #2 & finally, note <3>

And we're happy!

Using Visual Studio 2012 Test Explorer with NUnit and SpecFlow

Wed, 19 Sep 2012 00:39:59 Z

This one came up today and surprised me. I usually use the ReSharper test runner, but I wanted to try out the new, improved Visual Studio Test Explorer in VS2012. I have NUnit-based unit and integration tests and SpecFlow/WatiN UI automation tests that use NUnit behind the scenes.

Visual Studio Extensions and Updates

You'll need to install the NUnit Test Adapter so the Visual Studio Test Explorer knows what to do. You don't need to go back and change attributes, references, etc. to use MSTest. It can work with NUnit natively once you add this extension under Tools > Extensions and Updates.

Apartment State

Using SpecFlow with NUnit means you have to set your app.config ApartmentState to STA. This is well documented, but it's one of those things you have to do to get everything working.

<NUnit> <TestRunner> <add key="ApartmentState" value="STA"/> </TestRunner> </NUnit>

Making this app.config change is all the ReSharper test runner needs, but the Visual Studio Test Explorer needs a little more help. You have to set the NUnit attribute

[assembly: RequiresSTA]

in your AssemblyInfo.cs for your test project where your SpecFlow tests live.

Done!

Now you should be able to run ALL your solution's tests with the Visual Studio Test Explorer, including the SpecFlow ones!

Visual Studio Test Explorer still needs a lot of work around grouping tests, and Peter Provost says as much in his blog post, but it has come a long way.

Integrating Kendo UI drop downs with Knockout JS

Sun, 17 Feb 2013 22:07:00 Z

Kendo UI drop downs look great. Here is a Kendo UI drop down with default styling in closed and open view:

It is built with this HTML:

<input id="kendoDropDown" type="text" />

and this JavaScript:

// Init the drop down $("#kendoDropDown").kendoDropDownList({ dataValueField: "id", dataTextField: "name", dataSource: [ { id: "1", name: "apple" }, { id: "2", name: "orange" }, { id: "3", name: "banana" } ] });

The snag

Unfortunately, this handsome drop down doesn't integrate smoothly with Knockout JS when it comes to data binding.

We should be able to update our HTML to use a Knockout binding:

<p> <label for="kendoDropDown">Kendo UI Drop Down</label> <input id="kendoDropDown" type="text" data-bind="value: fruitId" /> </p>

Then add a view model and apply the Knockout binding:

// Define and init the Knockout view model var ViewModel = function () { var self = this; self.fruitId = ko.observable(); }, vm = new ViewModel(); // Set the initial fruit value vm.fruitId("2"); // orange
// Wire up KO binding ko.applyBindings(vm);

We should see a drop down loaded with the view model's initial value of "2" (orange), but the first value in the list ("1" apple) is selected instead. What's going on?

More investigation

I thought maybe I had a Knockout bug in my code, so I played around with a plain (non-Kendo) select list and a plain text box by adding the following HTML:

<p> <label for="select">Plain old select</label> <select id="select" data-bind="value: fruitId"> <option value="1">apple</option> <option value="2">orange</option> <option value="3">banana</option> </select> </p> <p> <label for="textBox">Plain old text box</label> <input id="textBox" type="text" data-bind="value: fruitId" /> </p>

But these controls were set to the correct initial value ("2" orange).

It gets weirder when you change the view model's value programmatically. Here, I've added some HTML buttons to do that:

<p> <button id="changeTo3" class="k-button">change fruitId to "3" (banana) programmatically</button> </p> <p> <button id="changeTo2" class="k-button">change fruitId to "2" (orange) programmatically</button> </p>

and some JavaScript to change the view model's values:

// Wire up the buttons $("#changeTo3").click(function () { vm.fruitId("3"); // banana }); $("#changeTo2").click(function () { vm.fruitId("2"); // orange });

Clicking the buttons should change the view model's value, which should change the controls' values. It works for the plain HTML controls, but not for the Kendo UI drop down.

Here's the JSFiddle to see all this in action.

The work around

A Kendo UI team blog post describes a work around for this issue, but it didn't work for me.

The trick here is that the Kendo UI drop down is really a hidden input and a bunch of spans. Knockout changes the value of the hidden input when the view model changes, but you have to hook into that jQuery DOM change event and call the code to select a new value in the Kendo drop down. Kind of lame, but it's supposed to work.

$("#kendoDropDown").bind("change", function() { $(this).data("kendoDropDownList").select(this.selectedIndex); });

You can even unhide the hidden text box inside the Kendo UI drop down list and watch its value change as the view model changes, but the drop down just sits there. Arg!

The real work around

I was pulling my hair out by now, and asked for help on Stack Overflow. Unfortunately, the answer I got was use another library that does the integration in a different way, the Knockout-Kendo.js library. That's probably a good answer, but I was hoping to avoid adding another library just to use Knockout and Kendo UI together.

Instead, I found I could get everything working as expected with a Knockout subscription. It's like a view model data change listener. My thinking was that I could use the same concept as the Kendo UI team blog post (listen for a change and then manually set the drop down). Not ideal, but oh well.

Here's what I changed in the view model:

self.fruitId.subscribe(function (newValue) { $("#kendoDropDown").data("kendoDropDownList").value(newValue); });

And the final, working JSFiddle.

Increasing Testability

Sun, 07 Mar 2010 06:30:20 Z

Testa-what?

I don't know if "testability" is a word, but if Bud Light can make up "drinkability", maybe it should be. I'm talking about how pliant your code is to testing. If you're doing TDD or BDD, the code you write is testable by definition.

But if you're going the other way, and coding first or testing legacy code (any code not already under test), you've probably run into code that was hard to test and felt like giving up. Some of the most common hurdles for testability are not coding to abstractions and not decoupling dependencies. Here's how to get around that.

The problem

Here's a garden variety Order class with a ProcessOrder method:

public class Order { public string FirstName { get; set; } public string LastName { get; set; } public string Email { get; set; } public decimal Total { get; set; } public bool ProcessOrder() { var result = false; // Validate order if (!string.IsNullOrEmpty(this.Email) &amp;&amp; this.Total > 0) { // Send order confirmation email var emailService = new EmailService(); var emailSendResult = emailService.SendOrderConfirmationEmail(this); if (emailSendResult == true) { // Do more order processing... result = true; } } return result;
} }

And here's the test:

[Test] public void Should_return_true_when_using_good_order_values() { // Arrange var order = new Order(); order.FirstName = "Joe"; order.LastName = "Wilson"; order.Email = "real_email_address@volaresystems.com"; order.Total = 123.00m; // Act // Watch out! Don't run this or it will send real emails! var result = order.ProcessOrder();
// Assert Assert.That(result, Is.True); }

We need to call the SendOrderConfirmationEmail method in the EmailService class. But if our test calls ProcessOrder, there is no way to avoid calling the live emailing method as it's coded now.

How can we test the logic in the ProcessOrder method without sending out a real email?

Code to Abstractions

First, we need to code to an abstraction of EmailService, not to the concrete class itself. So let's create an interface around EmailService:

public interface IEmailService { bool SendOrderConfirmationEmail(Order order); }

Then change the EmailService class to implement this new interface. Visual Studio 2008 and ReSharper make this easy.

This will let us change our test later to use a fake version of IEmailService instead of the real one.

Decouple and Invert your Dependencies

The next problem is we're creating an instance of the EmailService class in the ProcessOrder method. Anytime you use "new" in your code, you're probably introducing a dependency and reducing testability.

The fix is to let the caller create the instance and tell the class or method being called which instance to use. I am using a private field with constructor injection to set the field instance. Note we're also now coding to the interface IEmailService instead of the instance EmailService.

Here's the full Order method using the private field to call the SendOrderConfirmationEmail method on IEmailService inside the ProcessOrder method.

public class Order { private readonly IEmailService _emailService; public string FirstName { get; set; } public string LastName { get; set; } public string Email { get; set; } public decimal Total { get; set; } public Order(IEmailService emailService) public bool ProcessOrder() { var result = false; // Validate order if (!string.IsNullOrEmpty(this.Email) &amp;&amp; this.Total > 0) { // Send order confirmation email //var emailService = new EmailService(); // Created outside this class now var emailSendResult = _emailService.SendOrderConfirmationEmail(this); if (emailSendResult == true) { // Do more order processing... result = true; } } return result;
} }

Dependencies can be very hard to spot, but it's critical to tease them out of your code to increase testability. They can even come from things as innocuous as DateTime. If you're code relies on DateTime.Now, how will you write unit tests for your logic without changing your system clock when you run the test? It's simpler to have the caller pass in the DateTime value and have the method do the calculations based on whatever value it is given.

Make a Fake

Now that we've got testable code, we can make a fake EmailService and update our test.

First, create the FakeEmailService class implementing the IEmailService we created earlier. We need the SendOrderConfirmationEmail method to return true to simulate an email being successfully sent.

public class FakeEmailService : IEmailService { public bool SendOrderConfirmationEmail(Order order) { return true; } }

You could also use a mocking framework like Moq or Rhino Mocks for this, but a homemade fake is easy, too.

Now we're ready to update our test to use the fake and inject it into the Order constructor:

[Test] public void Should_return_true_when_using_good_order_values() { // Arrange var emailService = new FakeEmailService(); order = new Order(emailService); order.FirstName = "Joe"; order.LastName = "Wilson"; order.Email = "real_email_address@volaresoftware.com"; order.Total = 123.00m; // Act var result = order.ProcessOrder(); // Assert Assert.That(result, Is.True);
}

Last step

We've refactored the Order class so the caller sends the IEmailService instance to it. That makes sense for the test, but what about the real code?

I typically use an IOC container like Structure Map or Castle Windsor to hold and resolve an in-memory dictionary of interfaces and class instances. You wire it up at application startup and when you call something that needs IEmailService, it creates an instance of EmailService for you.

If you're working with legacy code and can't use and IOC container, you also can add a no arg constructor like this:

public Order() : this(new EmailService()) { }
public Order(IEmailService emailService)

Your legacy code keeps calling the no arg constructor like it used to, and any new code and your test code use the constructor with IEmailService dependency passed in.

Wrap up

If you code isn't testable, you won't test it. If you're working with legacy code or writing tests after coding, you can use these techniques to pull out external dependencies so they can be faked for testing.

You can have it all: testable code, unit tests around that code, and no broken legacy code. Mmmm.Testability. Drink it in!

Reusing Kendo UI settings to make your app's UI patterns consistent

Sun, 14 Feb 2021 07:44:17 Z

Kendo UI components have LOTS of settings and options. For most web apps, you'll pick a set of options and stick with common UI patterns throughout the app.

Will your app's grids use paging or infinite scrolling of grid data? If paging, how many records should you show on each page? Which UI style should your app's date pickers use? What format should your app's numeric text boxes use by default - whole number or decimal?

One technique for sharing common settings across all Kendo UI components within your app is to set up your defaults and wrap with the jQuery extend function.

Here is a date picker:

import $ from "jquery"; import "@progress/kendo-ui/js/kendo.datepicker"; export function extend(settings) { const commonSettings = { componentType: "modern" }; return $.extend(true, {}, commonSettings, settings);
}

Here is a drop down list where the server returns a text and a value field to populate the drop down:

import $ from "jquery"; import "@progress/kendo-ui/js/kendo.dropdownlist"; export function extend(settings) { const commonSettings = { dataSource: { sort: [{ field: "text" }] // Sort by the field called "text" every time }, dataTextField: "text", // Assume the text field is always called "text" dataValueField: "value", // Assume the value field is always called "value" optionLabel: "- Please Select -", autoBind: false, // Don't bind the drop down on initialization valuePrimitive: true // Use primitives for values, like 123, not objects, like { value: 123, text: "Active" } }; return $.extend(true, {}, commonSettings, settings);
}

Here is a numeric text box for positive whole numbers:

import $ from "jquery"; import "@progress/kendo-ui/js/kendo.numerictextbox"; export function extend(settings) { const commonSettings = { min: 0, step: 1, decimals: 0, round: true, format: "{0:0}" }; return $.extend(true, {}, commonSettings, settings);
}

Use these default app settings by importing the module, referencing the extend method exported by that module, then using, adding to, or overriding the UI defaults needed for that date picker, drop down list, or numeric text box:

import * as datePicker from 'common/datePicker'; import * as dropDownList from 'common/dropDownList'; import * as numericTextBox from 'common/numericTextBox';
$("#myDatePicker").kendoDatePicker(datePicker.extend()); // No change to default values $("#myDropDown").kendoDropDownList(dropDownList.extend({ dataSource: "/api/myDropDown" // Add to, rather than change, default values })); $("#myNumericTextBox").kendoNumericTextBox(numericTextBox.extend({ min: -100 // Override default values }));

This is a good way to have a consistent UI without always copy-pasting key-value pairs across files.

It also allows you to quickly change how your app looks and works across pages and components with a change to the common Kendo UI defaults.