Utnyttja dina SA-vouchers innan det är försent










Sen, vad som känns som, tidernas begynnelse
har Microsoft erbjudit sina kunder möjlighet att skaffa sig utbildning inom Microsoft-produkter genom sitt Software Assurance-program. Med så kallade SA-vouchers har du som IT-proffs eller systemutvecklare kunnat betala för officiella Microsoftkurser hos Learning Partners, som t ex Informator. Men, nu blåser förändringens vindar. Framöver kommer Microsoft fortsätta investera kraftigt i sin Microsoft Learn-plattform som erbjuder gratis självstudiekurser online. Samtidigt fasas SA-voucherprogrammet ut.
Från februari 2020 kommer du inte kunna betala för Azure-utbildning med SA-vouchers.  Du kan emellertid fortfarande betala för andra Microsoftkurser, inklusive Office 365, Windows Server, SQL, SharePoint –  men endast till slutet av 2021. Och du kommer inte kunna skapa nya SA-vouchers efter juni 2021…
Trots stundande förändringar har du alltså chansen att fortfarande utnyttja voucherprogrammet till fullo, och det är värt.
Hör av dig till oss på Informator idag Vi hjälper dig gärna med att planera användningen av dina befintliga SA-vouchers och samarbetar med dig för att ta fram en utbildningsplan som stärker dina medarbetare, dig själv och din verksamhet.

Av:
Anna Sahinoja & Åsa Berglund

Vill du läsa mer om SA-Vouchers och hur man utnyttjar dem?
https://informator.se//utbildningar/microsoft/savouchers

Är du vår nästa produktexpert?


Informator har sedan länge arbetat fokuserat kring ett värderingsstyrt arbetssätt och självklart gäller detta även för alla våra partners som håller utbildning för och med oss. På videon ovan berättar vår nordiska produktchef om vilka förväntningar vi har på alla våra kursledare.

Känner du igen dig kring våra förväntningar på en kursledare!? Vi söker självklart alltid nya partners att arbeta med på konsultbasis, men just nu så vill vi även ha nya kollegor som både brinner för att dela med sig av sina kunskaper i lektionssal, men även vill bygga nya produkter inom mjukvaruutveckling och agile och designa leveranser tillsammans med oss.
Läs mer om tjänsterna som produktexpert inom mjukvaruutveckling/agila metoder och ansök snabbt och lätt på LinkedIn

OWASP Top Ten 2017 Release Candidate is out (and how it affects you)

The Open Web Application Security Project published the Release Candidate of the ten most critical Web application security risks in the OWASP Top Ten 2017. OWASP is instrumental in raising awareness about the most critical security issues affecting Web applications these days – and in today’s connected world, the security of Web applications is more critical than ever.In the last decade the OWASP Top Ten list became the most important reference point with respect to Web application security trends, such as:
Which vulnerabilities are becoming more critical due to the prevalence of poor development practices – or, conversely, the discovery of new attack techniques;
Which risks have become less significant over time due to the adoption of effective best practices and countermeasures and; and finally
What completely new threats have appeared due to changes in the design and implementation of web applications, such as moving towards cloud-based deployments with a large number of external dependencies.
In the end, such lists are handy to prioritize threats when developing your application. However, keep in mind that such a top list is definitely not an exhaustive list of security problems, and should not be used as such. It is not a checklist and neither is it something one can “comply” with; it is just a starting point of a journey through Web application security!
The changes of the 2017 release candidate as compared to the previous 2013 list are relatively minor:

  • The old A7 – Missing Function Level Access Control was merged with A4 – Insecure Direct Object References now forming the new A4 – Broken Access Control.
  • A7 – Insufficient Attack Protection and A10 – Underprotected APIs are two new risks on the list.
  • Finally, the old A10 – Unvalidated Redirects and Forwards fell out from the new top ten.

So what do these changes tell us about the current trends from a secure coding standpoint?

The first change is actually just bookkeeping – Broken Access Control was originally present in
earlier Top Ten lists, undergoing various splits and merges over time. Thus, both merged risks remain as important as ever under this new category.

However, the appearance of the two new risks – Insufficient Attack Protection and Underprotected APIs – highlights something more interesting: neither is connected only to the code and the implementation of the web application, rather they reflect threats stemming from the environment and the various components providing APIs – such as libraries, web services or microservices. Reliance on third-party components vastly increases the exposure of a system to potentially malicious interactions, and the attack surface is extended beyond just the developer’s own code. This is becoming more and more an aching point for software development projects; the two new items continue the trend that already started in 2013 by introducing Using Components with Known Vulnerabilities as a new component of the top ten list.

Insufficient Attack Protection refers to the inability to detect, prevent and respond to various kinds of attacks against the application as a whole. This – due to the large number of unaudited third-party components that may contain critical vulnerabilities – necessitates the use of generic security tools such as intrusion detection systems (IDS), and web application firewalls (WAF) that can identify an ongoing attack such as SQL injection. It focuses on the consequences instead of the root causes of the weaknesses.

Underprotected APIs looks at the problem from the other direction: with web applications increasingly relying on web services – both public APIs as well as the web application’s own core functionality implemented as a set of Internet-facing microservices – developers often forget that the attackers can access these APIs directly as well, and they don’t get the level of scrutiny that they deserve.

All in all, the 2017 OWASP Top Ten shows a continued shift towards merging AppSec and OpSec – it’s not just about making sure your own code is secure, it’s also about adding assurances that other code will not be able to harm your system, even if they include vulnerabilities (or just misbehave). In the age of rapid application development, Agile, and DevOps, maybe one of the current combo-buzzwords (DevOpsSec, SecDevOps or DevSecOps) will emerge as the path to take.

Balazs Kiss has been working in the area of application security for nearly a decade. He is one of the lead trainers at SCADEMY with several years of experience in various fields of software security education.

Informator kan tillsammans med Secure Coding Academy erbjuda dig ett unikt kursutbud inom Secure Coding. Se alla våra kurser inom Secure Coding här.


Här är 7 konsekvenser GDPR får för dina utvecklare

Det är inte bara vd och cio som behöver oroa sig för införandet av dataskyddsförordningen nästa år. Det blir utvecklare som får göra grovjobbet.

Här följer ett utdrag från artikeln 7 konsekvenser GDPR får för dina utvecklare av reporter Lars Danielsson på IDG

Att dataskyddsförordningen, även känt som GDPR, som börjar gälla i EU 25 maj 2018 kommer att få konsekvenser har nog de flesta förstått. Medborgares rätt att ”bli glömda” och till dataportabilitet, och begränsningar för vilka persondata företag och myndigheter får lagra är bara några exempel, liksom kravet på att ha en personuppgiftsansvarig.
Det är också nytt är även att även tredjepart som tjänsteleverantör, webbhotell och molnleverantörer kan få böter om de slarvar med skyddet av persondata.
Att inte följa GDPR kan bli dyrt. Det kan kosta upp till fyra procent av omsättningen eller 20 miljoner euro i böter, det som är högst.
Men vem blir det som får göra jobbet med att modifiera existerande applikationer och databaser? Och dessutom ta höjd för dataskyddsfrågor i designen av nya lösningar? Jo, det blir i hög utsträckning utvecklare som får den bollen i sina knän.
Här berättar konsulterna Kristoffer Arfvidson och Patrick Bladh på Basalt om sju direkta konsekvenser för utvecklare, som dataskyddsförordningen medför.
1. Mer att utveckla
Helt plötsligt ställs en massa nya krav på hur data ska hanteras när de väl hamnat i databaser. Lösningar för datainsamling som tuffat på i åratal utan problem måste nu ses över och modifieras, kanske till och med skrotas för att ersättas med nya.
Någon måste designa och bygga de tekniska lösningar som krävs för att uppfylla alla nya krav som GDPR medför. Skriva koden helt enkelt, bygga om formulär, skriva nya sql-satser, samt tänka ut vilken information som skall sparas och på vilket sätt.
2. Existerande information blir en riskfaktor
Hur ofta har du som utvecklare funderat över hur avlusningsinformation och logginformation hanteras? Det är dags att göra det nu, eftersom datatjuvar potentiellt kan härleda information utifrån sådana datakällor. Det gäller framför allt under drift, men kanske även under utvecklingsfasen, beroende på vilka data som används då. Det senare gäller speciellt under agilt arbete då nya funktioner utvecklas parallellt med drift av applikationer.
3. Extremt svårt att avidentifiera data
”Det är inget problem, vi avidentifierar bara data”, kanske du har hört någon säga? Men det är sannerligen ett problem. Det är i själva verket extremt svårt att avidentifiera data på ett säkert sätt. Räkna med att lägga mycket tid och möda på det, om det behövs.
4. Påverkan på tidsplan och budget
Mer utvecklingsjobb medför, naturligtvis, fler jobbade timmar, flera utvecklare och framflyttade deadlines. Det fattar utvecklare, men fattar chefer och affärsansvariga det? Och om de fattar det, accepterar de det? Åtminstone projektledare och utvecklingschefer behöver se över sina argument.
5. Allmänt ökade kostnader
Man behöver inte bara ta hänsyn till direkt utvecklingsrelaterade kostnadsökningar. Det ambitiösare säkerhetsarbete som blir följden av GDPR kostar mer pengar i största allmänhet. Från vilka budgetar ska de pengarna tas? Som utvecklingsansvarig får man se upp så man inte blir sittande med Svarte Petter, i det här fallet att ansvara för allmänna it-säkerhetskostnader för applikationer som byggs.
6. Ställ krav på tjänsteleverantörer
Glöm inte säkerheten i den underliggande plattformen. Vilka krav behöver man ställa på sina leverantörer? Se till att inte du som utvecklare blir ansvarig för sådant som andra bör ordna.
7. Nya infallsvinklar på databaser
De nya kraven på datahantering medför inte bara jobbiga punktinsatser. Som utvecklare, arkitekt och designansvarig måste man ta på sig en kanske helt ny tänkarmössa. Det handlar om att se på databaser från ett angreppsperspektiv för att förstå hur de ska säkras.
Förutom att fundera på hur angrepp kan förhindras måste man anta att datatjuven redan slagit till. Hur kan man minska konsekvenserna om data blir stulna? Hur kan man säkerhetskopiera data så att de fortfarande är enkla att hantera? Vad finns det för möjligheter att upptäcka om en incident pågår eller har inträffat?

Kristoffer Arfvidson och Patrick Bladh pratade om GDPR:s konsekvenser för utvecklare på konferensen Swetugg i Stockholm nyligen. Det är en tvådagarskonferens för Dotnetutvecklare som lockade 460 besökare under två dagar, som kunde lyssna på 49 föredrag.
GDPR står för General Data Protection Regulation.






Informator anordnar en heldagsworkshop med advokat Malin Edmar från Advokatfirman EdmarLaw AB som, tillsammans med sin kollega Karl-Hugo Engdahl, benar ut vilka nya krav som följer med den kommande nya dataskyddsförordningen - GDPR, med konkreta tips på hur du kan förbereda dig, ditt företag och kunderna inför den. Läs mer om kursen här.



Developers’ key role within software engineering security

Application security has changed and evolved throughout the years. However, it is clear to see it failed to keep up with how software engineering has evolved. Developers are asked to code better and faster, improving features… which has a negative impact on sound security and quality practices. As a result, the code produced becomes more vulnerable, easier to hack… and the danger of falling victim to cyber-criminality starts to rise.
Developers have a key role in maintaining great security and quality within their daily coding practices. Most companies still struggle to join the dots when putting security and productivity on the same level.
Ask yourself the following : What if incorporating security from the start led to being more productive?

A look-back : Penetrate and Patch.
If we look back at the last 20 years, software engineering has been evolving at a high pace, with the accent put on quickness and features. As a result, most companies are amazing at producing applications in a speedy manner… by neglecting security from the start. Instead, they take on a “penetrate and patch” approach, hoping that this will save the day, should there be vulnerabilities in the code.
“Penetrate and patch” has quite a few limitations, among which :

  • Developers can only patch issues they know about.
  • Patches are often the results of market pressure, and often introduce new problems of their own.
  • Patches usually only fixes the issues, but do not take a proper look at what is causing the problem.
  • When looking at the end-user, patches are sometimes overlooked… A system admin which is overworked might not be so keen on applying a patch to a system that works.

This is still how lots and lots of companies operate, and part of the reasons why the state of IT security is so alarming.
What else can be done?

Know your enemy better than you know yourself.
As “Sun Tzu” said, “Know your enemy and know yourself and you can fight a hundred battles without disaster”.
We highly recommend companies to send some of their developers to hackers’ conferences. By doing so they will be able to understand how they think, how they act, what their motivations are, etc. By doing so, your developers will start to have a “security-first” mindset, which we help them code better.
All of our courses are presented in a way to achieve that goal as well, by providing our trainees with case-studies and live-hacking fun exercises. Our Java and Web Application course can be seen here.

Attend security conferences
Attending such conferences is a very good way of keeping up-to-date with best practices. Above all, those are a place where you can exchange with other devs, or security professionals on their success stories and set-backs.

Educate yourself, your team, your company!
The ultimate solution to make sure your developers are in great position to fulfill that key role in security, is simply to make sure they have the knowledge to do so. You may ask ten times a developer to make sure his piece of work cannot be hacked using Sequel Injection… if He does not know how to prevent it from happening, you might end up with an issue on our end.
Two types of learning methods are currently available. Online Learning (remote distance and/or CBT) and Onsite (F2F) learning.
While online learning presents some advantages (flexibility, easier roll-out when a lot of developers are concerned…), one can wonder how much knowledge really is retained by such a learning method.
On the other side, we have onsite live classroom, where trainees have a physical trainer in front of them, who presents them the knowledge and the challenges. Q&A is also happening live, and it is also easy for the trainer to validate understanding (or not) of the concepts taught.
Here below are some of the courses we have been providing companies with.

Microsoft SDL Core Training
C/C++ Secure Coding
Comprehensive C# and .Net Application Security
Secure Coding in PHP
Advanced JAVA and Web Application Security
Complementary topics for JAVA
Complementary topics for .Net

Why educating software engineers in security?
It may happen that you do feel confident about your security practices… or that you have a security team in place. However, the odds are that they are likely to be overworked, and that makes it very hard to keep up with the latest hacking techniques and found vulnerabilities. That is why having a partner that will raise that security knowledge within your developing team will be of great help.

Stay Secure in 2017!
/Gauthier





Gauthier has been active in the IT field for over 10 years. Currently working for Scademy Ltd, He oversees global Sales and Marketing.
Informator kan tillsammans med Secure Coding Academy erbjuda dig ett unikt kursutbud inom Secure Coding. Se alla våra kurser inom Secure Coding här.

How to Prevent Cyber Crime

A Little Bit of Background
Cyber crime can be divided into two categories: Crimes that target computers directly such as viruses, attacks and malware; and online crime that uses computer networks or devices as means to perform fraud and identity theft through social engineering as well as cyber bullying, cyber stalking and cyber warfare.
Currently, companies in the United States experience an annual loss of more than 525 million US dollars due to cyber crime. The majority of these losses are due to malicious code and denial of service attacks.
People tend to believe that working with an Security Expert, after producing the different apps… will allow them to live happily ever after while staying away from Cyber Crime. They could not be more wrong!

Prevention through Education and Training
Let me put it this way. Picture yourself as MD of a logistics company. Would you put unlicensed drivers in front of the stirring wheel of your trucks? The answer is NO.
Were you to run a Hospital, Would you let a GP practice an open-heart surgery on a patient? The answer is NO.

Those are of course extreme cases, but not so far by software engineering best practices. Cyber threats are all around. The way we see it, companies around the world face two choices.
Option A: They live on the so called “Never happened to me before, Cannot foresee it happening to me ever!” statement. Well… this is very, very close to gambling! It might be true, it is likely not to be. Cyber Crime is growing day in, day out. So why take the risk to let it hurt you and your company?
Option B: You start tackling the problem through education and training. Why wait until you get hacked? Educating, and training your software engineers will make you save money in the long run, a huge amount of money. The amount of hacking attempts you’ll avoid… the time you will gain on producing new code… and not reviewing old one in order to find, test and fix bugs will be considerable!

So wait no more! Tackle the problem before it even hits you. Join the community of secure coders, and help us make the IT world a safer place.
/Gauthier






Gauthier has been active in the IT field for over 10 years. Currently working for Scademy Ltd, He oversees global Sales and Marketing.
Informator har lång erfarenhet av utbildning inom olika inriktningar och systemutvecklingsspråk. Tillsammans med vår partner Secure Coding Academy presenterar vi det antagligen mest heltäckande kursutbudet när det kommer till att skriva säker kod. 

Han är Sveriges bästa utvecklare 2016

Det roligaste är att sitta tillsammans med kollegor och användare och bygga ny funktionalitet. Det tycker Sveriges bästa utvecklare, Expressens Joel Abrahamsson, som fick priset på IDG:s event Code Night i går.


              Här följer ett utdrag från artikeln Sveriges bästa utvecklare 2016

På Expressens sajt dyker det kontinuerligt upp små förbättringar. Det kan till exempel vara hur man presenterar länkar till mer innehåll efter att en användare har läst klart en artikel. Hur mycket har Expressens chefsutvecklare Joel Abrahamsson, på torsdagskvällen utsedd av TechWorld till Sveriges bästa utvecklare 2016, fingrarna med i utvecklingen av sådan funktionalitet?

– Förut var jag direkt involverad ganska mycket. Nu jobbar jag mest med api:erna bakom som gör sådana här funktioner möjliga. Men jag är ofta med och diskuterar hur nya funktioner ska utformas, säger Joel Abrahamsson.

Som exempel på vikten av backendfunktionalitet lyfter han framför allt fram prestanda. Man får till exempel tänka till vad gäller att cacha information i Akamais nätverk som Expressen använder, så att sidvisningarna blir snabba även under hög belastning.

Joel Abrahamsson har sedan tidigare en bakgrund som Episerverutvecklare och det finns en logik i att han hamnat på Expressen, eftersom en tidnings publicistiska verksamhet på webben definitionsmässigt handlar om innehåll.

Hur viktig är själva koden när man bygger lösningar?

– Det är sällan svårt att skriva kod. Det svåra är att skriva rätt kod. Det är oftast inte en teknisk utmaning. Det handlar om att leverera nytta till användarna, snarare än att skriva perfekt kod.

Hur vet man vilken kod som är rätt?

– Ibland är det bättre att testa, att bygga tre olika lösningar, än att diskutera vad man ska göra.

Joel Abrahamsson närmar sig med stormsteg sitt tioårsjubileum som utvecklare. Det innebär att han hunnit skaffa sig teknisk kunskap som blivit omodern.

Är kunskap som var gångbar för sju åtta år sedan relevant i dag?

– Det är lätt att snöa in på den senaste tekniken. Men det finns andra kunskaper som är mer tidlösa, som att driva projekt, att interagera med människor och tidlösa arkitekturfrågor.

Efter att Joel Abrahamsson fått prischecken på 10 000 kronor av prisutdelaren Emil Robertsson, vd på Informator Utbildning, pustar han ut en stund.




Hur känns det att vara Sveriges bästa utvecklare?

– Det är jätteroligt. Men hur mycket kod jag än skriver kan jag aldrig skriva all kod själv. Det har varit väldigt roligt att bygga upp en utvecklingsavdelning på Expressen och vi verkar ha lyckats bra.

MOTIVERINGEN

Joel Abrahamsson är mycket skicklig utvecklare rent praktiskt, som kodare. Men det är bara början på en beskrivning. Att bygga en dynamisk utvecklingsorganisation och en teknisk plattform som tål både tung belastning och snabb förändring är några förmågor till. Krydda anrättningen med en god förmåga som föreläsare så blir resultatet Sveriges bästa utvecklare.

Hela artikeln hittar du här

Cyber-Criminals surfing on the Pokemon Go Hype

Pokemon GO is without doubt one of the biggest (if not the biggest) buzz the Internet has seen in the last years. Rolled over around the world, millions of users are now running around, phone in their hands, trying to catch Pokemons. This is all fun and games, but also a great opportunity for bad guys to affect millions of devices around the world.


ESET has discovered a lock-screen app, names Pokemon Go Ultimate. This app locks the screen right after the app is launched, forcing the user to reboot the device. However, the reboot function is unfortunately unavailable in most cases since the malicious app overlays all the other apps as well as system apps. The reboot can only be done via the Android Device Manager or by pulling out the Battery. So much for catching Pokemons… uh?
The Pokemon Go Ultimate app actually installs a PI Network app/icon, which once ran will freeze the screen and force the user to do a manual reset.  After rebooting the device, the app will stay hidden, but will still be running in the background and, by example, clicking on banners so as to generate revenues for its owners.
More importantly, this is step one of possibly upgrading this lock-screen malware to a ransomware! Users have to stay careful, and only use trusted apps!
But that’s not all!
Other malicious apps were also unfortunately discovered by ESET such as “Guide & Cheats for Pokemon Go” and “Install Pokemongo”. Those apps promises the users with PokeCoins, Pokeballs and any other sort of things… When what they really do is install malwares or scarewares onto your device, trying to lure the user into subscribing to numerous expensive bogus services.



Gotta Catch ’em All…. But please Beware of them all!
After ESET reported those Malicious Apps, they were immediately taken away from the Google Play Store. However, there will be others. It is important to still pay attention and to not download and is tall those malicious apps.
Those three apps could reach 500-1.000 users; 100-500 users and 10.000-50.000 users!

If you simply cannot resist to go out there and catch some Pokemons, we recommend to follow those guidelines before installing any apps :
  1. Only install from reputable sources
  2. Read reviews, filter out the positive ones to only read the negative ones.
  3. Pay attention to Ts&Cs, and apps permissions
  4. Have a mobile security solution!
/Gauthier











Gauthier has been active in the IT field for over 10 years. Currently working for Scademy Ltd, He oversees global Sales and Marketing.

Informator kan tillsammans med Secure Coding Academy erbjuda dig ett unikt kursutbud inom Secure Coding. Se alla våra kurser inom Secure Coding här.


DDoS vs DynDNS : the cyber attack that crippled American WEB giants

Security experts were unanimous: the Mirai botnets network had the capacity to massively disturb the majority of internet websites. Indeed, end of last week, it massively hit the DynDNS service, indirectly affecting thousands of american websites, for several hours.



DynDNS allows websites having dynamic IP addresses to only have a single URL, the company then taking care of providing the service redirecting the web user towards the right IP address.
On Friday night, the DynDNS service became victim of a harsh DDoS cyber attack from the Marai botnet network, which comprises of IoT devices such as IP security cameras and Routers/switches. Several major american players were affected, among which Netflix, Spotify, Twitter, Ebay and many others. In a nutshell, it is safe to say that all websites using DynDDS were affected, a share that was later estimated at just below 5% of the world wide web.
Mostly American web users got affected by those successive cyber attacks, even though a small share of Europeans also encountered difficulties while trying to log in to those services.
On Saturday, DynDNS published a blog post explaining the attack, and mentioning that the situation was now under control. Nevertheless, last Friday’s attack was very significant in terms of sophistication and complexity, not to mention the financial aspect of things. Indeed, Giants such as Paypal or Ebay are likely to have lost quite an amount of business during the downtime. Numbers are still to be communicated, if ever.



Do you feel the power?
No later than last Thursday, our trainer Erno Jeges was giving a presentation on secure coding. As part of our introduction, we spoke about the current situation with Botnets. While exchanging with some of the attendees, Erno mentioned how quickly a hacker, somewhere in the world, could assemble a “team” of 5,000 botnets. He then asked the audience : “Do you feel the power?”.
Well, now, you know the power.
Last October, a study revealed Mirai had around 213.000 infected machines. A few days ago, another study revealed that Mirai has over 500.000 infected machines.
So, again… Do you feel the power?

What now?
Well, friends, the situation is dark. Due to the nature of the vulnerability (default credentials that the users might not always be able to change), more attacks can be expected in the following weeks since this whole mess  will not be fixed by applying a single patch. In order for this to stop, the botnet network has to be stopped, somehow.
This not all, however. Hackers started to sell access to a huge army of hacked IoT devices, so as to launch attacks capable of disrupting web connections. More information can be found here.

“It takes less time to do a thing right, than it does to explain why you did it wrong.” - Henry Wadsworth Longfellow

/Gauthier 
Gauthier has been active in the IT field for over 10 years. Currently working for Scademy Ltd, He oversees global Sales and Marketing.
Informator har lång erfarenhet av utbildning inom olika inriktningar och systemutvecklingsspråk. Tillsammans med vår partner Secure Coding Academy presenterar vi det antagligen mest heltäckande kursutbudet när det kommer till att skriva säker kod. 




Agil arkitektur behöver vara adaptiv

- om variabilitet, SW product lines, och hur ”gamla ekonomin” tänker efter före.

Den som gått kursen Architecture Fundamentals, eller läst på själv, kommer ihåg resonemanget om symbiosen mellan Agile och arkitektur. Krasst ekonomiskt är drivraften bakom bådadera den samma: att slippa onödigt jobb.

Medan Agile förebygger onödig hierarki och overhead framförallt i närtid, förebygger arkitektur onödig upprepning och dubbelarbete även på sikt. En agil arkitekt strävar efter att minimera dubbelarbetet utan att öka overhead och mängden TAGRI (They Ain’t Gonna Read It). En agil arkitektur:

  • tas fram med de agila metoder, teamen använder i övriga projekt
  • dokumenteras på ett agilt sätt
  • är agil i sig särskilt när det gäller de första 4 principerna (av 12) i Agile Manifesto,
    1. kundnytta
    2. förändringsvänlighet
    3. täta snabba leveranser av fungerande system
    4. nära samarbete med verksamheten.

Utöver att agila metoder/processer strävar efter att svara på förändringsönskemål snabbt, med de medel och färdigheter som finns att tillgå, så tänker en agil arkitekt också långsiktigt, på tvären av projekt- och  produktgränser. Särskilt när det gäller att proaktivt bygga in färdiga variationsmekanismer, som i sin tur kan snabbt och förutsägbart svara på förändringsönskemål även i ett sent skede.

Av arkitektrollen kräver detta utöver komponenttänkandet också flexibla komponenter och även en flexibel arkitektur/plattform. Den senare skrev jag ett gästinlägg om på denna blogg, i november 2013, inspirerad av VW-koncernen efter att HHS i Stockholm konstaterat att bilindustrin ligger årtionden före ”nya ekonomin” (t ex läkemedel) vad gäller konkurrenstryck, processeffektivisering, Lean-tänkande, mm.

Trots att varannan jämförelse mellan bilindustrin och kunskapsindustrin haltar, så tillhör flexibla produktarkitekturer områden där vi har något att lära. Ett år senare har nu VW:s häpnadsväckande plattformsinvestering (500 miljarder SEK) gett ett globalt eko och ett race till megaplattformar (vad var det vi sa 2013, när man ännu skrev ”megaplattform” med citationstecken...) Tala om en gammal bransch som tänker nytt och har grepp om inte bara på vad arkitektur kostar utan även på vad den inbringar.

Det förvånar knappast att racet till megaplattformar sammanfallit med ett nygammalt mjukvaruhus-tänk inom systemarkitektur: en varierbar software-product line, fritt översatt att tänka som de svenska ”I:na” tänkt i många år inom ERP, CRM, SCM, m m. Att sätta tydliga ramar, sammanhang och mål för komponentifiering, återanvändning, och variabilitet (framförallt hur långt det är praktiskt rimligt att variera/tänja komponenterna resp plattformen, och med vilka mönster och taktiker/tekniker).

Tekniskt sett är variabilitet (utan ytterligare programmering) både en förutsättning för och ett mått på ”SW-product line mognad.” Mer följer i endags-kursen på Informator (fr o m vinter 2014), Modular Product Line Approach in Architecture (T1430).


Bild: drivkraften bakom inbyggd variabilitet är en kombination av att efterfrågan blivit mer heterogen (för at inte säga spretig) samtidigt som tids- och kostnadspressen ökat.


Milan Kratochvil

konsult, Kiseldalen.com

Huvudförfattare: Growing Modular: Mass Customization of Complex Products, Services and Software samt UML Xtra Light: How to Specify Your SW Requirements

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i Arkitektur, i modellering (T2715, T2716), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.

Programmeringskunskaper - Karriärväg för testare

- Ända sedan tonåren har jag varit intresserad av programmering. Jag köpte olika böcker, gick olika kurser, försökte lära mig från Internet, men kände ändå att jag inte riktigt förstod, att jag inte riktigt hade koll på helheten.
Daud Khan
När jag började arbeta som mjukvarutestare år 2006 kom jag långt ifrån programmering. Det var ren manuell testning som gällde istället för en kombination av programmering och testning som jag hade förväntat mig. Så jag fortsatte att jaga mitt intresse för programmering och började med testautomatisering. Jag kämpande vidare och tog varje tillfälle i akt att få koda och prova på olika programmeringsspråk.

Efter flera års kämpande och nyfikenhet så öppnades en hel värld av programmering när jag gav mig på en certifiering i Java. Helt plötsligt föll alla bitar på plats och jag insåg vilken pusselbit jag saknat under alla dessa år. Jag önskar att jag hade haft en bra mentor/pedagog som kunde förklarat programmering och dess svårigheter på ett enkelt sätt. Det var detta som ledde till att jag ville hjälpa andra som befann sig i liknande situation som jag hade upplevt i så många år. Jag förstod nu vad andra går igenom och vilken hjälp de behöver.

Idag när testarens roll har förändrats och man kräver mer tekniska testare, som både kan testning och programmering, är behovet av programmeringskunskaper ännu viktigare. Många behöver få grunderna i programmering förklarat på ett förenklat sätt kopplat till riktiga objekt och system. Efter att ha hjälpt många människor med programmering har jag tagit fram utbildningen ”Programmering för testare” där man lär sig felsökning, läsa och förstå kod samt även skriva egen kod. Med denna utbildning hoppas jag få vara den mentor och pedagog som jag själv önskade mig under mina år av eget kämpande.

---
Daud Khan är är data- och elektronikingenjör, testare och testledare. Han är ISTQB® Certified Tester - Advanced Level - Full Advanced, men har även en rad andra utbildningar i bagaget till exempel PMI CAPM (Certified Associate in Project Management) och SCJP 6.0 (Sun Certified Java Programmer). Daud Khan har arbetat i över tio år med Quality Assurance

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Jonathan Worthington: Why I use ASP.NET MVC

Why I Use ASP.NET MVC
I used to do a lot of web development. These days I do rather less of it - I'm far
more involved with architecture and teaching - but most of the systems I'm
involved with have a web frontend, so I keep a very keen eye on the technologies
that are available. Additionally, I often end up building small tools that need
some kind of interface, and I'd much rather whip up a web one than mess with
desktop apps. Many development shops in Sweden work with .Net, and these days
often choose between Web Forms and MVC. I suspect the title of this post gives
you a good idea of my preference. :-)

Embracing the web
Good technologies often embrace the way the thing they're built on actually
works. Take jQuery. It doesn't try and fight JavaScript having prototype based
OO by fudging a class system on it, as various efforts to tame JavaScript did.
Instead, it embraces it - and the results are pretty nice.

ASP.NET Web Forms suffers from a certain amount of fudgery: it tries to hide the
stateless nature of the web by saving state for you. The result is view state
(which bulks up pages) and mangled field names (which make client side development
a little more painful). Trouble is, the stateless nature of the web matters; it's
an important part of why it has scaled so well.

ASP.NET MVC embraces the way the web works, and focuses on allowing you to work
efficiently within that. There's no view state. The HTML you write is the HTML
you get. IDs don't get mangled. ASP.NET Ajax is mostly dropped in favor of jQuery
(by now something of a de facto standard).

A better factoring
To be fair, Web Forms did bring huge advantages over classic ASP when it arrived.
It put an end to mixing up logic and HTML in a single file, separating them logic
out into a codebehind file. Unfortunatley, the factoring hasn't really stood the
test of time. These days, developers are more interested than ever in writing
tests, and dependency inversion often shows up with this desire. Web Forms isn't
too friendly to either of these goals.

MVC makes a three way division. HTML goes into the view, which is rendered by a
view engine. There are no controls like in Web Forms; there are, however, helpers
for generating various pieces of HTML. The data that the view is to render is
supplied in the model. The model is just some .Net object. There are no constraints
on what this object can be, so you can do anything from using entities from Entity
Framework (which usually is a bad idea, mind) to a command object being built up
in a CQRS based system.

The interesting logic lives in the controller. In ASP.NET MVC, a controller is a
class that inherits from the Controller base class, and contains methods that
are known as actions. Each time a request is made, it is routed to the applicable
action method. This method builds the model and selects the view - thus it is in
overall control of the request's processing.

Why is this more testable?
The controller is a normal class. You can make an instance of it in your test, call
the action methods (since they are just normal methods) and look at the return value,
which in turns lets you get at the model that the controller built. Essentially, it
is a lot like writing tests against any other class in .Net; you can use whatever test
tools you are familiar with.

And what of dependency inversion? The MVC framework provides a hook for you to integrate
a DI container of your choice, such as StructureMap. In fact, for some of them there are
even NuGet packages to do the wiring up for you.

What's coming up?
ASP.NET MVC is very actively developed and has frequent releases. Version 3 didn't come
out all that long ago, and yet version 4 is already in beta! Perhaps most exciting is
that it will bring Web API, a way to implement REST-based web services. It looks rather
more convenient than WCF for this kind of task, and the factoring will feel familiar to
anybody who is already used to working with ASP.NET MVC - it's just a different type of
controller!

Learning More
I teach a 2 day getting started with ASP.NET MVC 3 course for Informator. At the moment,
I'm working on updating it to cover ASP.NET MVC 4; it will also be extended to a three
day course to allow this, but also to enable me to go into much more depth on testing. Also,
we're planning the next Community Day, and I expect to be giving a talk on Web API.

/Jonathan Worthington

The use of events for decoupling business logic

Why I Use Events
Events are a relatively simple, but very powerful idea. At its simplest, an event is a statement that something has happened. Usually, it includes some data that further defines what has taken place. Events show up very naturally when doing GUI programming, either for the desktop (think WinForms) or web (JavaScript).

However, that's not the use case I want to discuss today. Instead, I want to consider the use of events for decoupling business logic.

Boundaries
Lack of boundaries has to be one of the most common problems I see in software systems. Layered architecture has taken a hold in many systems, and often helps bound the UI and business logic (and sometimes too many other things beyond that). However, too often the business domain is seen as one big thing, with no serious effort made to look for and maintain explicit boundaries. Both DDD and SOA are pretty clear that we need to hunt for such boundaries, however.

The argument that tends to crop up next is that one part of the system will often need to know what's going on in other parts. For example, it's very well for a travel company to say they'll bound sales, booking and their transport services into separate services or contexts. However, in reality, if a booking were to be cancelled at the last minute then the sales context should know about this so they can do a special last minute deal, and the transport services context also need to remove the passenger from its lists.

Clearly, the booking context is responsible for handling the cancellation. In a monolithic system, the cancellation logic would mark the booking as cancelled, and then go and handle the notification of the sales team and updating the passenger list. If we are series about boundaries, however, then this simply isn't going to fly. So what can we do?

Publish Subscribe
We can resolve this problem using a popular messaging pattern, known as publish subscribe. First, we define a BookingCancelled event. Typically, I would just represent this as a simple class.
public class BookingCancelledEvent{
public int BookingID;public List Passengers;}
The booking context would mark the booking as cancelled and do anything that is directly related to bookings. It would then publish this event. Meanwhile, the sales and transport contexts would be subscribed to booking cancellation events. They receive the event, look at the data contained within it and take action as appropriate.

We have now managed to achieve a very loose coupling between the different parts of our business system. The only things that flow over boundaries are events. Should a new context be interested in knowing about cancellations, then it's trivial to handle; the booking context needs no changes whatsoever, and the new context is just added as an extra subscriber.

It's all in the past
The naming of events is of great importance. An event should always be in the past tense. This makes it absolutely clear that the event in question has already taken place. There's nothing a receiver can do to change that it happened; they can only act upon that new reality.

Events should also have a single source. It should never be possible for more than one context to publish the same type of event. This maps down to a deeper principle: every piece of information in your system should have a single owner that is responsible for it. It's fine for other contexts to maintain their own local copies of the data, or at least the parts they are interested in – but there is only one single authority for it.

Implementation
There are many ways to implement events along with publish subscribe. For a small, single-process system then a relatively simple in-memory message bus or event aggregator isn't a great deal of code. For larger systems, however, events come in to their own. Using an enterprise service bus - such as NServiceBus - enables a service to publish events and other services to subscribe to them. Such systems use store and forward, providing reliable and asynchronous message delivery.

Learn more
I consider events important, and thus they show up in many courses I'm involved with. Of note, in the C# Masterclass I work through building a simple in-process event aggregator. The Software Architecture course talks about events somewhat. They will also be a core topic in the forthcoming Hands On DDD and CQRS course, where we'll consider events not only as a mechanism for decoupling, but also as a primary storage mechanism.


/Jonathan Worthington