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. 

Se våra kurser inom Secure Coding från Secure Coding Academy här.

Läs mer

Java - ett osäkert språk?

Javaspecialisten om varför utvecklingsspråket lämnat sin Vilda västern-tid bakom sig.

Javaplattformen återfinns idag i 97 procent av världens alla datorer, och numera även i mer än tre miljarder mobiler. Men då och då publiceras uppgifter om att Java skulle lida av allvarliga säkerhetsproblem. Vi ringde upp Hamid Samadi för att ta pulsen på en av landets mest erfarna Javaspecialister.

Hej Hamid. Helt kort, vad skiljer Java från andra plattformar?

– Den stora skillnaden jämfört med t ex Microsoft.NET är att Java kan köras med olika operativsystem på alla typer av utrustning. Och att Java-användarna inte behöver betala några användarlicenser – där finns miljarder att spara varje år, enbart i Sverige. Om vi frågar Microsoft om skillnaden skulle de kanske säga att Java är mer vilda västern och att .NET har en fastare struktur. Själv vill jag snarare hävda att Java är mer flexibelt, och enklare för utvecklarna att jobba med. De årliga besparingarna med ”Open Source” väger förstås oerhört tungt för användarna. Dessutom har Java flera fördelar ur säkerhetssynpunkt. I övrigt är de ganska lika, och slutanvändarna märker i princip ingen skillnad alls. 

Fördelar ur säkerhetssynpunkt, säger du? Hur då?

– Idag kan man utveckla applikationer med Java med minst lika hög säkerhet som andra plattformar. När det gäller applikationssäkerhet måste man ta hänsyn till flera faktorer och säkerheten i Javaprogram kan bl. a. optimeras med hjälp av säkerhet i själva språket och Javas virtuella minne (s.k. JVM). Det sistnämnda är en inbyggd säkerhetsmekanism (Security manager) som hindrar exekvering av otillförlitliga koder från resten av operativsystemet. Det finns även en hel svit av säkerhets-API:er som Java-utvecklare kan använda för att höja och optimera säkerheten. 

– Utöver detta finns mängder av Open Source säkerhetsramverk som kan användas inom säkerhetskänsliga verksamheter. Det är en av de stora fördelarna med Java Open Source för systemutveckling. Som exempel kan man nämna Apache Shiro eller Spring Security som idag används inom olika branscher med särskilt höga säkerhetskrav, inte minst inom bank och finans. Eventuella problem beror till hundra procent på den som programmerar. 

En del har ju ifrågasatt Javas säkerhet under åren?

– Att diskussionen om Javas säkerhet över huvud taget uppstod beror på de s.k. ”applets” som Sun utvecklade för att integrera java i webbläsarna, i Javas tidiga barndom. Men det där har absolut ingenting att göra med dagens plattform, eller seriösa utvecklare och användare. 

Och hur ser framtiden ut?

Den är ljus – väldigt ljus, om du frågar mig. Java är idag det mest använda språket för programutveckling, och det är ingen tillfällighet. Dessutom backas Java upp av otaliga användare över hela världen, inklusive tungviktare som IBM och Google. Hela Android-systemet bygger också på den mobila versionen av Java. Med över nio miljoner aktiva Java-utvecklare världen över kan vad som helst hända. Vi lever i en oerhört spännande tid. Vi kommer att se att flera företag och myndigheter kommer att använda Java plattformen fram över och i större utsträckning. Det är bara början på ett långt äventyr!

---

Hamid Samadi leder kurser i Java hos Informator Utbildning och ansvarar för den årliga Java-konferensen www.jdays.se i Göteborg där Informator självklart även i år medverkar som utställare!

Utbildningar i Java hos Informator

Läs mer

Informator på jFokus 2015

Informators monter på jFokus 2015 och ett härligt gäng på plats

Informator deltar såklart även i år på jFokus, Sveriges (Norra Europas!? :) största konferens för Javautvecklare. Som den utbildningsleverantör med allra störst bredd och utbud för systemutvecklare är det självklart att vara på plats! I år är det vitt skilda ämnen på konferensen som Java8, Spring, Docker, Devops, Rest, HTML5, JavaScript och självklart ett och annat spår för dig som jobbar agilt.

Är du på plats är du varmt välkommen över till vår monter och plocka upp lite info om vad vi erbjuder inom dessa och fler områden, tävla om roliga priser och kanske sno lite godis så du håller energin uppe till nästa session!!

För dig som redan nu vill få en fullständig överblick på vilka områden Informator erbjuder kurser för systemutvecklare så har vi samlat dessa på en samlingssida som du hittar på www.informator.se/utbildningar/systemutveckling

Läs mer

Multitrådad maskinlärande med Java

På kursen T2732 Avancerad Java programmering går vi bland annat igenom Executor ramverket som introducerades med Java 1.5. Ramverket tar hand om trådhanteringen och låter oss fokusera på de uppgifter som skall utföras i bakgrunden.

En användning för multipla trådar som blir allt vanligare är att utnyttja flera processoror och kärnor för beräkningsintensiva applikationer. Ett område som jag brinner för är AI och maskinlärande, där algoritmerna oftast är CPU-intensiva. Genom att köra på flera processorer parallellt så blir beräkningen klar snabbare.

I denna artikel får Ni känna lite på maskinlärande, med 2 implementationer av en kNN klassificerare, en enkeltrådad och en multitrådad. Under resan får vi även bekanta oss med Strategy och Template Method, två kraftfulla designmönster samt definiera och använda generiska typer, ämnen som också behandlas på kursen. Artikeln visar en hel del javakod men bara de väsentligaste delarna. Om du vill se hela koden kan du ladda ner projektet här.

Maskinlärande

En vanlig uppgift inom maskinlärande är klassifikation. Utifrån ett antal instanser, eller exempel, skapar man en klassificerare som kan användas för att kategorisera nya instanser. Kreditbedömning, medicinsk diagnos och textanalys är bara några exempel. Neurala nätverk, Naive Bayes, SVM, kNN är några olika typer av klassificerare.

Exempeldata

Vi tar kreditbedömning vid sms lån som exempel. I tabellen visas två tidigare ansökningar och dess utfall. Bedömningen kanske har skett manuellt tidigare men med ett stort antal exempel så kan vi bygga en beslutsmodell som avgör nya ansökningar.

Kön	Årsinkomst	Lånebelopp	Operatör	Veckodag	Timme	Beviljat
man	190.000	800	telenor	lördag	3	nej
kvinna	240.000	400	telia	tisdag	17	ja

Många ramverk för maskinlärande representerar alla attribut som en array av double. Vi håller oss till  objektorienterad representation och definierar därför en klass för en låneansökan:

kNN - Nearest Neighbor

kNN är en algoritm som är lätt att förstå och lätt att implementera. Idén bygger på att man jämför instansen som skall klassificeras med ett stort antal tidigare instanser och tilldelar samma klass som den (k = 1) eller de (k > 1) som är mest lika. Till detta behöver vi en funktion som kan beräkna hur lika två instanser är. Denna funktion är specifik för varje typ av instans och definieras genom att implementera följande interface:

Här är en implementation som jämför två låneansökningar och returnerar ett mått på hur olika de är. I normala fall får man arbeta mycket med denna för att trimma in kvaliteten på klassificeringen.

Här är själva klassificeringsmetoden för kNN, observera att loopen som beräknar alla avstånd går på en enda tråd.

Nästa steg är att göra beräkningen av alla avstånd på flera processorer. Ett sätt att implementera det är att bryta ut beräkningen till en egen metod (calculateDistances) som sedan överrids i en subklass. Om vi samtidigt lyfter upp den utbrutna metoden samt classify-implementation i en abstrakt basklass, så har vi ett exempel på designmönstret Template Method. Nedan följer de intressanta metoderna i ParallelNearestNeighborClassifier:
Notera att vi skapar ett antal instanser av Callable som vi lämnar över till en ExecutorService som fördelar uppgifterna på trådarna i trådpoolen.

Och slutligen ett test-program som jämför båda algoritmerna med olika mängder data.

Resultat

Av tabellen framgår att den multitrådade versionen går lite mer än dubbelt så fort utom för väldigt små datamängder. Min maskin har 8 kärnor och jag körde applikationen i en VMware instans med 4 kärnor tilldelade. I teorin skall det gå 4 gånger fortare men jag kom aldrig riktigt upp i fullt tryck (100% CPU) på alla 4 kärnor, vilket kan bero på den virtuella miljön. Som med alla typer av optimering är det bra att mäta och göra val utifrån faktisk prestanda och inte teoretiskt resonemang.

Antal instanser	En tråd (ms)	Flera trådar (ms)
5000	102	73
10000	91	85
50000	376	251
100000	781	385
1000000	7681	3353
5000000	39376	16893
10000000	83029	34699

PS. AI och maskinlärande är inget som tas upp på kursen, men om det finns intresse så kan vi ordna en workshop. Kontakta din lokala säljare!

Läs mer

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

Läs mer

Why should you care about Java 8?

Why should you care about Java 8? It depends on who you are and what is up in your software environment where you are working. Perhaps your boss has decided to start some projects with the latest Java releases, or maybe you have heard that Java 8 is easier to exploit more of the multiple CPUs on your computers/servers. Or perhaps you believe Java 8 makes cleaner codes. However, whatever it is about, there is just one thing you should know about Java 8: Java 8 new features/changes are in many ways profound than any other changes to Java since elder Java releases. You can compare it with Java 5 releases as a contrast, where lots of new main language futures have been introduced. 

The main keys/futures (as many JSRs) in Java 8 are:

•          Lambda expressions (officially it's called lambda expressions but unofficially is as closures). - Supporting lambda expressions allows to perform functional-style operations on streams of elements, such as MapReduce transformations on collections.

•          Annotations on Java Types for Unsigned Integer Arithmetic

•          Parallel Array Sorting

•          Bulk Data Operations for Collections

•          Define a standard API for Base64 encoding and decoding
•          New Date & Time API
•          JavaScript runtime integration which allows developers to embed JavaScript code within applications
•          Supporting  multicore processors
•          Efficient mixing of classes and functions, how methods can be passed as functional values, and how anonymous functions (lambdas) are written
•          New way to handle Streams, it generalizes many aspects of Collections but allows elements of a stream to be processed in parallel
•          Introducing “default method” in an interface, it provides a method body if an implementing class chooses NOT to implement any one.
•          Many interesting ideas from functional programming such as dealing with null and patternMatching and so on

When Oracle acquired Sun for several years ago, many Java developers and enterprises were worried about what will happen to Java's future development. Some were worried that it would be the end for Java. Some people believed that Oracle would end up with the development of NetBeans and related tools and technologies. But according to me and these facts everyone can see that it has gone well, I think. Slowly but safe, Oracle has taken care of the development in a good way. Much of this success is due to the open-source success where Oracle has carefully followed up and has done lesson learned. Technologies like Hibernate, Spring or new languages ​​such as Scala and Groovy have showed the road and those experts writing JSRs have kept up with and reacted well. Looking forward to see much better Java SE and Java EE releases. I am more hopeful today then before that in future we are going to see more software projects using Java SE and Java EE.

//Hamid Samadi - Javalärare hos Informator

Do you want to know more about the new features of Java 8? Do you want to get help understanding how to apply them in your daily programming tasks? Then you should take a look at Informators 2-day-course "Java 8 - New Features".

Läs mer

Java Date and Time API

I nästa version av Java, Java 8, kommer äntligen ett fullständigt bibliotek för hantering av datum och tid. Detta kommer att ersätta de befintliga klasserna som baseras på Date, respektive Calendar. Date är sedan länge deprecated men finns i många applikationer. Denna klass har en historia som baseras på den datastruktur som en gång fanns med i C från 1972. Den historiska ryggsäcken innehåller många märkligheter, såsom möjligheten att förändra ett datum, idag kan förvandlas till imorgon! Stöd för jämförelser mellan datum saknas, vilket krävs för sortering som ju är ett vanligt behov när man hanterar data innehållande någon form av datumstämpel. Det mest kuriösa inslaget i klassen Date är nog den konstruktor som tar tre parametrar, där man utgår från referensdatum där år sätts till 1900, månaderna börjar räknas från 0 och dag med värdet 1. I skrivande stund (2013-04-12) gäller således följande parameteruppsättning för att ange dagens datum Date(113, 3, 12
 

Javas nya Date and Time API kommer att placeras I en egen package-struktur med java.time som bas. Dokumentationen för de ingående klasser och interface antyder att API:et är mer svårbemästrat  än vad det verkligen är. Alla klasser är immutable, trådsäkra och baserade på den internationella standarden för kalendrar, ISO 8601. Även om huvudspåret följer den Gregorianska kalendern, så finns det stöd för många olika kalendrar såsom ThaiBuddhist respektive Japanese Imperial.  Månader som veckodagar hanteras nu med var sin Enum där konstanterna anges med engelska namn och har ett värdenummer som följer standard, vilket innebär att MONDAY räknas som dag 1 i veckan och DECEMBER har värdet 12. Det tog 18 år av Java-utveckling att komma hit…

De mest intressanta klasserna i API:et är följande:

LocalDate – Ett ”normalt” datum skrivet på formen YYYY-MM-DD enligt ISO-standarden och därmed kanske vi kan bli av med avarter som formaten mån/dag/år respektive dag/mån/år vilka kan ställa till stora problem där dag och månad lätt kan förväxlas. Bland en uppsjö av metoder kan nämnas ett flertal som tar fram ett nytt objekt baserat på stegning framåt eller bakåt utefter en datumlinje baserat på antal dagar, veckor, månader eller år.

LocalTime – En tidpunkt utan vare sig datum eller tidszon, med en upplösning på ner till nanosekund. Format enligt HH:MM:SS.xxxxxxxxx

LocalDateTime – En komplett tidsangivelse där såväl datum som tid på ett kombinerat format av de två beståndsdelarna med ett T som skiljetecken; YYYY-MM-DDTHH:MM:SS.xxx

Instant – En tidsstämpel som anges med nanosekunds precision. Detta är en klass som typiskt kommer att få stor användning vid loggning.

Clock – En abstrakt klass som kan användas för att ta fram aktuell tidpunkt, vilket även kommer att vara möjligt via metoden now() som finns i ett flertal klasser. Huvudsyftet med Clock är att stödja  plug-in av alternativa implementationer där exempelvis en offset kan anges. Clock kan typiskt förenkla tester med inbyggda tidsberoenden.

Duration – En klass som beräknar tid mellan två Instant objekt vilka anger tidpunkter utefter en tidslinje. Det är möjligt att beräkna negativ tid genom att ange inparametrar mot tidaxelns riktning.

ZoneId – En klass som modellerar tidszoner med ett id som är unikt inom systemet. Olika tidzoner kan anges med speciella prefix såsom 'UTC', 'GMT', 'UT' '+' eller '-', men kan också vara mera läsbara regionala id såsom Europe/Paris.

Slutligen ett citat från API dokumentationen som visar på att de nya klasserna och metoderna kan vara lätta att läsa och förstå även för en utomstående:

LocalDate customerBirthday = customer.loadBirthdayFromDatabase();

LocalDate today = LocalDate.now();

if (customerBirthday.equals(today)) {

 LocalDate specialOfferExpiryDate = today.plusWeeks(2).with(next(FRIDAY));

 customer.sendBirthdaySpecialOffer(specialOfferExpiryDate);

}

Kan det bli tydligare? Skynda att fynda!

/Kjell H Carlsson

Intresserad av att förkovra dig inom Java? Då ska du kika in på dessa länkar:

Open Source Effective Java

Översikt på våra utbildningar i Java

Läs mer

Varför jag gillar GPars

GPars är ett Groovy/Java bibliotek för att hjälpa till med att skriva fler-trådade program. I stället för att explicit skapa ett visst antal trådar (threads) med distinkta uppgifter, kan man hantera en trådpool och sen lägga till uppgifter för trådarna i poolen att hantera. GPars tillhandahåller ett flertal olika abstraktioner såsom parallel arrays, fork-join, actors, dataflow, STM och en del mer där till.

Så här skapar man en "vanlig" tråd (java.lang.Thread) i Groovy:

def t = Thread.start {
    10.times {println 'tjabba'}
}
t.join()

I vissa fall vet man inte på förhand hur många trådar man vill skapa, utan låta problemet visa vägen. Antag att man vill räkna antalet filer i en katalog struktur. Så här kan man göra det med hjälp av fork-join i GPars:

Eller, så vill man bygga en enkel pipeline mellan olika behandlingsteg. Så här kan man koppla ihop två actors med varandra i GPars:

Det finns hur mycket som helst mer att berätta om, ... och det gör jag på torsdag förmiddag den 21 februari. Missa inte frukost seminariet om Groovy GPars.

Läs hela agendan och anmäl dig här

Läs mer

Androidutveckling med hjälp av appar

För nästan ett år sedan lanserade vi min kurs om utveckling av Android appar. Kursen var inriktad på att förmedla allt man som Java programmerare behöver veta för att komma igång praktiskt med programutveckling av Android appar.

Under hösten har jag emellertid stegvis provat ett annorlunda grepp att presentera ämnesområdet, som jag bland annat kört på jDays i Göteborg i början på december förra året. Både erfarenheter och gensvaren från deltagarna har gjort det dags att ny-lansera kursen om Android programmering:

Appar i massor

(Trumvirvel...) Jag presenterar härmed kursen:
Android App Programmering - An App-Driven Approach

Denna omgjorda kurs tar sin utgångspunkt i en serie av kompletta appar. Varje app fokuserar på ett specifikt område inom Android API:et. Men, lägger också till olika typer av extra-funktionalitet för att vara en komplett app. På så sätt hinner vi betydligt längre och djupare, jämfört med både min förra kurs och lejon-parten av Android kurser på marknaden.

Vad sägs om att bygga en enkel spel-app, men som låter användaren styra indata med rösten och att appen talar tillbaka.

Eller, en app som baserat på aktuell position rapporterar via anrop till en webb-tjänst när solen går upp och ned idag och några (valfritt) antal dagar framåt i tiden.

Eller, en chat-app där alla deltagare  kommunicerar med varandra på kursen. Detta vara bara några av alla appar vi bygger på kursen.

Och mycket mera; såsom styra kameran, detektera om telefonen skakas, både spela in och spela upp ljud, hantera animering och bakgrundsbearbetningar, SQLite databasen, den inbyggda webbläsaren med mera...

För dig med gott om ont om tid

Kursen är på 5 dagar för att ge dig maximalt med tid att absorbera det omfattande materialet. Men vi vet också att tiden man är borta från verksamheten för att gå kurs, ibland är problematisk. Därför ger vi också kursen på 3 fullmatade lång-dagar. Det innebär att vi startar i tidiga ottan klockan 08 och håller på ända till middagstid klockan 18.

Mera information

Du hittar mer information om de båda kurserna via följande länkar:

• Android App Programmering - An App-Driven Approach (5 dagar)
• Android App Programmering - An App-Driven Approach (3 lång-dagar)

Läs mer

Varför jag gillar Gradle

I begynnelsen var det make. Dvs i Javas barndom (a.k.a. 90-talet) fanns bara Unix/Linux make för att bygga/sammanfoga programsystem. Detta var ju ett problem för ett plattforms-oberoende språk som Java.

Apache Ant

Kring millennieskiftet och när XML var som hetast, kom så Ant. Via en konfigurationsfil i XML kunde man beskriva en stor mängd byggtekniska steg. Allt från att kompilera ett gäng Java klasser, peta in dem i en JAR fil, stoppa in denna plus mycket annat webbrelaterat i en WAR fil, hämta eller lämna data i en SQL databas, koka kaffe - äh, nä kanske inte just det, men mycket annat.

Ant tog Java världen med storm. Ant växte sig större och större, och en dag var Ant jättestor. Medan de andra ..., nä stopp - tillbaka i spåret. Det som vi alla noterade med varierande grad av frustration, var att varje gång man kom till ett nytt projekt så behövde man läsa in sig på bygg dokumentationen.

Hur gjorde man nu för att bygga systemet? Var det ant build, ant make, ant package, ant assembly, ant doit, ant fixit, eller bara kort och gott ant? Och, hur körde man de där unit testen? Och var ska man lägga alla 3-parts JAR filer? Och hur ska dessa packas upp med rätt namn-standard? Åh, föresten; var i hela friden ska jag lägga mina Java klasser? Alla som var med, minns detta.

Apache Maven

Så kom Maven i 2004 och gjorde rent hus med Ant. Maven innebar en smärre revolution i vår del av den programmerar-tekniska världen, genom att införa (1) standardisering och (2) konfigurering via konventioner, samt störst av dem alla, (3) automagisk hantering av 3-parts JAR filer.

Dessutom avslutade Maven debatten huruvida man har tid med dokumentation eller ej. Alla kunde nu köra kommandot mvn site och få den mest tjusiga webbplats med JavaDocs för alla klasser, unit-test rapporter, källkods-listningar, listning av alla 3-parts beroenden, instruktioner om hur och var man checkade ut koden och mycket annat.

Standardisering och konfigurering

Förvånansvärt snabbt lärde vi oss alla att placera Java klasser under src/main/java och test-klasser under src/test/java och resurs-filer under src/main/resources. Samt, ville man kompilera skrev man mvn compile, att bygga hela systemet var lika enkelt med mvn package och då kördes dessutom alla unit-test som en extra bonus.

Transitiva beroenden

Ovanstående var fantastiskt, men dependency mekanismen var gudomlig. Genom att bara skriva några rader XML i Mavens konfigurationsfil pom.xml, så utförde Maven ett mirakel:

Första gången, man sen körde ett Maven kommando, så laddades JAR filerna för alla beroenden ned och lagrades på den egna hårddisken, inklusive alla deras beroenden i sin tur. Detta kallas med ett mer akademiskt uttryck; den transitiva slutningen av beroende-grafen.

Maven, hammaren och skäran

Nu var förvisso inte allt frid och fröjd. Med tiden utvecklades en hat-kärlek till Maven. Så länge man höll sig på den "enda vägen" så var allt frid och fröjd, men nåde den som försökte ändra på delar av den POMetariata byggprocessen och lägga till byggsteg eller något så kontra-revolutionärt som att generera mer än en artifakt. Då väntande evig förvisning på den Sibiriska XML tundran, med otaliga strapatslika sökningar i mängder av Maven-plugins skrifter.

Under tiden på en annan planet

Redan tidigt under språket Groovys utveckling, så var Ant en integrerad del av språket. Efter att först skapat ett AntBuilder objekt, kunde man sen anropa vilka Ant uppgifter (tasks) som helst. Den stora poängen var kombinationen av Ant rikhaltiga flora av uppgifter, med ett programspråk som Groovy. Med lätthet kunde man nu skriva Ant build uttryck som helt enkelt inte var möjliga att formulera via XML.

Detta medförde att Ant fick en renässans inom Groovy världen.

GAnt landar

Snart utvecklades an fullfjädrad ersättare för Ant, nämligen GAnt. Det gick nu att skriva byggskript med Ant, men med Groovy syntax. 

Är du intresserad av ett lite större GAnt skript, så skrev jag en blogg-post för några år sedan om hur man genererar flera Android APK filer (app:ar) från samma kodbas. Något som inte var möjligt med Googles egna Ant skript, som följer med när man skapar ett nytt Android projekt.

Emellertid, fanns det ett grundläggande problem med GAnt, vilket var exakt samma som för Ant. Ingen standardisering och ingen automagisk hantering av 3-parts JAR filer.

Gradle

Det var detta Hans Dockter funderade över på en Groovy & Grails konferens. Resultatet blev byggverktyget Gradle som kombinerar det bästa från Ant, GAnt och Maven, men undviker deras tillkortakommanden.

Om Ant representerar första generations bygg-verktyg och Maven andra generations, så utgör Gradle den tredje generationens bygg-verktyg, för Java, Groovy, Scala, C++ och mycket annat.

Gradle använder sig av samma konventioner som Maven, men tvingar inte användaren att bara generera en artefakt (JAR, WAR, EAR, ...) per projekt. Gradle använder inte XML som representation av bygg-skript, utan Groovy vilket på en gång gör Gradle betydligt mer kraftfullt än Ant och Maven någonsin varit. Behöver man lägga in t.ex. villkorade bygg-delar så är det hur enkelt som helst, vilket - som alla som prövat - i Ant och Maven inte är helt trivialt för att uttrycka sig milt.

Att bygga ett standard Java system, utan krusiduller, så behöver man bara en enkel rad i sitt Gradle bygg-skript (build.gradle)

apply plugin: 'java'

Och man kompilerar med kommandot

gradle compile

Samt, bygger en JAR fil och kör alla test, med kommandot

gradle build

Ett av mina Gradle projekt

Jag har utvecklat en del open-source plugins för CA-Wily Introscope, som används av kunder på i Sverige och på många ställen runt jordklotet. I höstas, gjorde jag en anpassning för en kund i Sundsvall och passade då på att byta från kombinationen Maven + Ant, till blott Gradle. Jag använde förut Maven för den reguljära bygg-biten, men Ant för att generera och instrumentera en Introscope-Agent som applicerades på ett funktions-test.

Nu, med Gradle var det hur enkelt som helst att kombinera detta i ett enda bygg-skript. Så här ser detta ut (taget från min publika GitHub repo ExpressionTracer).

Jag tänkte inte gå igenom allting, utan bara peka på vissa intressanta delar. Projektet använder 3-parts JAR filer hämtade både från Maven Central och lokalt från min hårddisk (eftersom Agent.jar är en kommersiell komponent). Något man svårligen kunde göra i Maven. Den sista delen är GAnt liknande kod för att hantera funktionstestet. Något liknande är helt omöjligt att åstadkomma i Maven, såvida man inte implementerar en egen Maven-plugin.

Till sists

Om du inte kikat på Gradle hittills, så är det hög tid nu. 

Om du fortfarande bygger m.h.a. Ant men funderar på att byta till Maven; hoppa då över andra generationen och gå direkt till tredje generationens bygg-verktyg.

Om du bygger ditt system i Maven och tycker det börjar bli lite tungrott; kika då på Gradle.

Vill du att vi på Informator ska arrangera ett frukost-seminarium om Gradle, ange det i en kommentar nedan.

Läs mer

Varför jag gillar Grails

Jag har utvecklat webb-applikationer i Grails sedan 2007, efter det att jag först bekantat mig med Groovy tidigare det året.

Språket Groovy såg dagens ljus redan i augusti 2003, då James Strachan skickade ut ett meddelande (nästan lika legendariskt som det Linus Torvalds skickade ut i början på 90-talet - men då alltså om Linux) om att han börjat vidareutveckla språket Java, genom att skapa det dynamiska JVM språket Groovy.

Grails började utvecklas en bit före 2007 (av Graeme Rocher) och hade då namnet "Groovy on Rails", vilket klart signalerade att det var en rip-off av Ruby on Rails. Efter att några jurister dykt upp med verbala påkar, ändrades namnet till kort och gott Grails. Logotypen för också tanken till the quest for the Holy Grail.

Tidigare, hade jag byggt webb-applikationer i Java m.h.a. ramverk, som Struts, WebWork och Spring-MVC. De hade alla det gemensamt att det var mycket att konfigurera. Centrala delar av applikationens arkitektur skrevs i diverse XML filer. Databas-lagret hanterades av Hibernate eller (Gud förbjude) Entity EJBs. Dessutom var man helt beroende av generator-verktyg som XDoclet, för att inte drunkna i allt manuellt arbete conf/xml skrivande.

Grails ändrade helt på allt detta genom principen on configuration by convention.

Domänklasser och databaser

Skriver man en GroovyBean klass (t.ex. Person.groovy) och placerar den i katalogen grails-app/domain, så är allt som har med konfigurering av DB persistens klart!

Grails hanterar via Spring Framework och Hibernate alla kopplingar och konfigureringar helt utan att man behöver lägga sig i. Man kan dock tweaka varje aspekt om det behövs, för att t.ex. anpassa sig till legacy data.

Webbaktioner

Skapar man en klass med ett gäng metoder (t.ex. PersonController.groovy) och lägger klassen i katalogen grails-app/controllers, så har man en färdig webb-tjänst för URI:er liknande denna

http://myhost/myapp/person/show/17

Fragmentet /person/ pekar ut PersonController och fragmentet show pekar ut action-metoden med samma namn i just den klassen, samt 17 anger DB id for person-objektet i fråga.

GSP - Groovy Server Pages

Webb-vyer skriver man i GSP, som är samma ide som JSP, men med Groovy i stället. Det innebär att man primärt skriver HTML assisterad av ett rik flora av taglibs. Här och där spränger man in Groovy uttryck som hämtar ut data från olika GroovyBeans.

Så här hänger det ihop: Antag att URI:n ovan anropas. Först selekteras kontrollern Person varpå anropas aktionmetoden show() där parametern params.id har värdet 17. Metoden show() hämtar upp person-objektet från databasen på följande enkla sätt:

def thePersonFound = Person.get(params.id)

Metoden show() förväntas sedan returnera en map med dataobjekt som ska exponeras (t.ex. [bean:thePersonFound]. Eftersom aktionmetoden heter show, så anropas motsvarande GSP i katalogen views/person/show.gsp, som genererar HTML och skickar (via SiteMesh - se nedan) detta till webbläsaren.

Antag att person-klassen innehåller bl.a. property:n String name, då går det att söka via namnet

def p = Person.findByName('Anna Conda')

eller

def p = Person.findByNameLike('Ann%')

Detta är så kallade dynamiska finders och genereras automatiskt baserat på vilka properties som finns deklarerade i domänklassen. Det finns också en hel del andra sätt att söka på och sammanställa databas-information.

Egna taglibs

På liknande sätt som ovan, så skapar man lekande lätt egna taglibs genom att skriva en klass (t.ex. UtilsTagLib.groovy) och placera denna i katalogen grails-app/taglib. Varje metod blir en tag som kan användas på en GSP-sida.

Sidlayoter

Layout för en hel webbsida hanteras (bakom kulisserna) av SiteMesh. Som Grails programmerare behöver man bara fixa till en GSP sida med övergripande layout för webbplatsen och markera ut var innehållet (content) ska petas in. Det innebär att genererad  HTML från en vy strippas på HEAD sektionen och innehållet innanför BODY taggen substitueras in på rätt plats i layout GSP:n och resultatet skickas till webbläsaren.

Transaktionella tjänsteobjekt

Skapar man en klass (t.ex. BusinessService.groovy) innehållande deklarationen

static transactional = true

samt placerar klassen i katalogen grails-app/services, så vips har man ett transaktionellt tjänsteobjekt, som bakom kulisserna använder Springs transactional-service och transaktion-hanteringen hos databasen.

Detta innebär bl.a. att om en av metoderna kastar ett undantag (runtime exception) så görs det en roll-back på transaktionen. Vidare, så propageras aktuell transaktion om den transaktionella tjänstemetoden anropar andra tjänstemetoder i samma eller andra tjänsteobjekt.

Och mer där till...

Så här kan jag hålla på och rada upp fördelar/egenskaper, såsom att det finns mycket bra stöd för AJAX-anrop, att det är mycket enkelt att skapa REST baserade webbtjänster, o.s.v.

Det är enkelt att konfigurera stöd för 2nd-level cache och olika typer av databaser som MySQL, Oracle, PostgreSQL, MS SQL-Server etc. Det finns också stöd för ett flertal NoSQL databaser, såsom MongoDB, SimpleDB, Redis, CouchDB med flera.

Grails är rent tekniskt ett plugin-ramverk, vilket innebär att alla system-tjänster är plugins. Gillar man inte Tomcat eller Hibernate, så går de att byta ut. Det finns idag ett mycket stort utbud av Grails-plugins, som gör att arbetet går ännu snabbare, eftersom många gånger hittar man en plugin, som redan implementerar det man hade tänkt sig att göra själv.

Mitt senaste Grails projekt

När jag inte undervisar för Informator (i ämnen såsom Groovy&Grails, Android, C++, Erlang, Linux, Cloud Computing, ...), så är jag CTO och lead-architect för en startup, där vi byggt en SaaS applikation i Groovy och Grails, samt driftsatt den i Amazon AWS molnet. Är du nyfiken på vad det är så kollar du in webbplatsen ProposalsFactory.

Mer om Groovy

Den 21 februari håller jag ett frukost-seminarium om Groovy och GPars. Med GPars biblioteket kan man skriva applikationer, vilka enkelt och bekvämt utnyttjar moderna datorers förmåga att exekvera många aktiviteter parallellt (multi-cpu/core/threading).
Läs hela agendan och anmäl dig här


Blev du nyfiken på Groovy och Grails, så kör jag också kursen Webbapplikationer med Groovy och Grails, för Informator under våren.

Läs mer

Varför jag gillar språket Groovy

Programspråket Groovy kan (lite löst) uttryckas som Java++, dvs en naturlig utvidgning av Java syntaxen för att kortare och bättre lösa ett programmeringstekniskt problem.

Groovy är mitt favoritspråk, eftersom jag kan skriva Java program, som är korta och begripliga utan att förvilla mig i en massa syntaktisk jox. Så låt mig få visa ett konkret exempel på hur det går att korta ned ett Java program till ett mycket kortare Groovy program.

En kopp Java att starta med

Följande Java program hämtar en XML fil (från Brottplatskartan) med de senaste rapporterade brotten/olyckorna och listar trafikolyckorna i kronologisk ordning.

Programkoden i Java är på 150 rader och GitHub gist:en nedan visar både kod och utdata:


Så här kompilerar och exekverar du Java programmet:

Yes> javac -d target/classes src/java/CrimesList.java
Yes> java -cp target/classes CrimesList

Lite mysigare med Groovy

I första steget byter jag namn på filen, så att filändelsen är *.groovy, samt kapar bort en del överflödigt Java jox.

Inga semi-kolon

Vi behöver inte semikolon, så bort med dem i slutet av varje programrad.

GroovyBeans

Det finns en inre JavaBean klass, som vi direkt kan göra om till en GroovyBean i stället. Vi behöver inte getters och setters, eftersom Groovy tillhandahåller dem för oss (kompilerade), om vi deklarerar data-innehållet som properties. Standard metoder som toString(), equals(), hashCode() låter vi kompilatorn generera via annoteringar. Vi utnyttjar också att Java-klassen Date har nya metoder, såsom parse() och passar på att använda spaceship-operatorn (<=>) för att köra compareTo() metoden. Detta gjorde att en JavaBean på nästan 90 rader kan kapas ned till 20 rader. Inte illa!

Lite mer finlir

I huvud-metoden main() gör jag bara några mindre justeringar, vad beträffar utskrifter och en liten closure-loop istf for-each dito.

Ett första resultat

Så här ser Groovy klassen ut (med utdata) och den består av endast 80 rader.


Så här kompilerar och exekverar du Groovy programmet:

Yes> groovy src/groovy/CrimesList_shorter.groovy

Ännu mysigare Groovy

Men, det finns mer 'Java-jox' att kapa bort.

Groovy-Script

I Java måste ju all kod vara innesluten i en klass. I Groovy kan vi använda skript i stället. Så, bort med den omgivande applikations-klassen. Jag flyttar också omkring lite kod, så att koden i main() hamnar längsdt ned och Crime-bönan hamnar överst.

Bort med onödiga konstruktorer

Vad ska man med en konstruktor till egentligen? Groovy ger alla klasser utan konstruktor en speciell konstruktor, som tar namn-givna parametrar. Mycket tydligare, än parameter-positionen.

new Crime(title: e.title.text(), date: Date.parse('yyyy-MM-dd HH:mm:ss', e.date.text()), place: e.place.text(), description: e.text.text())

Mer Groovy

I det andra steget tar jag bort alla return-uttryck och använder mig av Groovy closures överallt där det tidigare fanns loopar.

Groovy XML-Parser

Slutligen, strutar jag i att använda Java's XML-DOM parser och kör med Groovy's egen som har en del finesser. Först, hämtar jag data och bygger upp ett XML träd.

new XmlParser().parse(url)

Från detta träd av XML noder, filtrerar jag ut alla 'event' noder, som en lista.

new XmlParser().parse(url).event

Denna node-lista bygger jag sedan om, så att varje node blir ett Crime objekt i stället.

new XmlParser().parse(url).event.collect {e -> new Crime(...)}

Slut-resultatet

Så, jag började med en Java klass på 150 rader och slutar här nedan med ett Groovy-script på blott 30 rader. Visst är det mysigt?


Så här kompilerar och exekverar du Groovy programmet:

Yes> groovy src/groovy/CrimesList_shortest.groovy

PS

Tråkigt nog, hann det inträffa några fler trafik-olyckor mellan att jag körde Java programmet och Groovy programmen.

Läs mer

Nyheterna i Groovy

Efter nyåret släpptes lanseringskandidaten av Groovy 2.1 och går allt vägen, så har vi den skarpa versionen i slutet av januari. Groovy 2.x bjuder på många nyheter och förbättrar språket både vad gäller funktionalitet och prestanda.

Men hallå! Vad är Groovy?

Enkelt uttryckt är det Java++, en bättre variant av Java helt enkelt. Ungefär som C++ är en bättre variant av C. Det går att blanda Java och Groovy hur enkelt som helst. Tack vare den familjära syntaxen går rekord-snabbt för en Java programmerare att börja använda Groovy och det är mycket enkelt att smyga in lite Groovy här och där i en befintlig Java applikation.

Språket Groovy genomgår just nu en mycket intressant vidare-utveckling, som började för lite drygt ett och ett halvt år sedan med version 1.8. Denna version var knökfull av nya egenskaper och när språkets utvecklingsteam planerade för version 1.9 insåg de vad de borde ha gjort redan för version 1.8, nämligen att börja på nästa major version, dvs 2.x. Så 1.9 blev helt sonika omdöpt till 2.0 och på den vägen är det.

AST Annotations

Den mest iögonfallande nyheten i version 1.8 var möjligheten att generera ny kompilerad kod i samband med att ett Groovy program startar. Detta kallas för AST Transformations, där AST betyder Abstract Syntax Tree. I (mycket) korta drag så när ett Groovy program laddas för exekvering, så kompileras det först till Java byte-code. Under denna process så byggs det upp en intern trädrepresentation av programkoden (AST), som i flera olika steg transformeras.

Med AST-T kan man lägga till egna transformationer, dvs dynamiskt skapa ny kod, som kommer med i kompileringen. Nu är detta inget man gör i den dagliga programmeringen, utan man använder färdiga transformationer, som finns tillgängliga i form av kod-annoteringar. Genom att applicera en eller flera AST annoteringar, så utökas en Groovy klass med kompilerad kod. Låt oss kika på några exempel, intressanta för varje Java programmerare.

@ToString

Hur många gånger har man inte "mekaniskt" skrivit en toString() method i Java och för varje klass-ändring så måste denna uppdateras eller genereras på nytt. Det finns alternativ; såsom Jakarta Commons Lang ToStringBuilder, som dynamiskt (reflektivt) skapar output. Emellertid, om du använder Groovy i stället, så räcker det med att annotera din klass med @ToString, så är saken biff.

import groovy.transform.*
@ToString class Person {
    String first, last
    int age
}

def p1 = new Person(first:'Anna', last:'Conda', age:17)
println "p1 = ${p1}"

Vilket ger utskriften

p1 = Person(Anna, Conda, 17)

Vill man se attributnamnen också, lägger man till @ToString(includeNames=true) och utskriften blir i stället

p = Person(first:Anna, last:Conda, age:17)

@EqualsAndHashCode

En annan trist uppgift i Java, är att underhålla metoderna hashCode() och equals(). De behöver implementeras båda två och är viktiga för att ens objekt ska kunna förekomma i olika typer av list:or och map:ar. Med Groovy, så lägger du bara till @EqualsAndHashCode och kan gå vidare med mer intressant programmeringsuppgifter. Så här kan det se ut

import groovy.transform.*
@ToString(includeNames=true) 
@EqualsAndHashCode
class Person {
    String first, last
    int age
}
//...
def p2 = new Person(first:'Per', last:'Silja')
def p3 = new Person(first:'Per', last:'Silja')

assert p2 == p3
assert p1 != p3
assert p2.hashCode() == p3.hashCode()

@Log4j

Loggning är ett annat område av rutin-programmering och innebär att man typiskt i en konstruktor skapar ett log objekt, lite olika beroende på om man använder Log4J, Commons-Logging, SLF4J eller java.util.logging. Varför inte låta en annotering sköta om detta i stället. Här ett exempel för Log4J.

@Log4j class Controller {
    Controller() {
        log.debug("Created");
    }
    void doit() {
        log.info("Calling doit()");
        //...
    }
}

Och så vidare...

Det finns många fler AST annoteringar, såsom @AutoExternalizable som bygger writeExternal() och readExternal() method i gränssnittet Externalizable (vanlig optimering), @Immutable som gör en klass read-only, @Singleton som implementerar singleton-mönstret, och mång fler.

Exkvera snabbare

Det hur många som helst andra nyheter i Groovy från versionerna 1.8, 2.0 och 2.1, men jag tänkte uppehålla mig kring området prestanda. Groovy är ju ett dynamiskt programspråk, med bl.a. s.k. duck-typing. Det här innebär att en hel del kontroller och omvandlingar sker under exekveringen, vilket ibland tar lite för lång tid. Därför har prestanda-förbättringar av språket varit högt prioriterat av användarna. Det finns två parallella spår för att möta detta.
Det första spåret är att ge programmeraren mer kontroll över var kompilatorn kan generera byte-code, som har samma prestanda som motsvarande Java-kod. Det här görs med annoteringar.

@CompileStatic

Med annoteringen @CompileStatic markerar man att en metod eller klass inte behöver det "dynamiska" stödet utan resultatet blir Java-style byte-code.

@TypeChecked

Med annoteringen @TypeChecked markerar man att en metod eller klass ska kompileras med statisk typ-kontroll, vilket innebär att problem som kanske dyker upp först under exekveringen kan hittas redan vid kompileringen.
Med båda dessa annoteringar, så har man det bästa från två världar Java statiska typ-kontroll och prestanda, samt Groovy's dynamiska beteende där man behöver det.

Invoke Dynamic

Det andra spåret är att använda det nya stödet i Java 7 för dynamiska språk (byte-code instruktionen invokeDynamic). Detta arbete påbörjades redan i Groovy 2.0, men väntas vara mer genomarbetat och tillgängligt i nya versionen 2.1.
I korta drag, så exekverar man ett Groovy program med den nya switchen --indy och ser till att Groovy använder Java 7 i botten.

groovy --indy myCoolApp.groovy

Mer om Groovy

Vecka 5

Under vecka 5 kommer jag tillbaka och bloggar hela veckan om Groovy relaterade saker.

Concurrency for the Modern Age

Om du inte har fått nog efter den veckan, så kommer jag att hålla ett frukost-seminarium den 21 februari om hur man med Groovy och GPars biblioteket kan skriva applikationer, som enkelt och bekvämt utnyttjar moderna datorers förmåga att exekver många aktiviteter parallellt (multi-cpu/core/threading).

Läs hela agendan och anmäl dig här

Läs mer