N-Body simulation of the solar system in Java

Introduction

I have always been fascinated by space and when I learned the basic physical laws that describes the dynamics of bodies I was surprised by how simple they were! A few simple equations can be used to explain the movement of projectiles, planets etc.

Many astronomical and astrophysical phenomena can be simulated using N-body simulation which simulates a dynamical system of particles, usually under the influence of physical forces, such as gravity. N-body simulation is also often used in game-physics to make objects move around, accelerating etc.

When you have a large number of particles, all interacting with each other, it can be hard (or impossible) to formulate analytical mathematical solutions that describes the state of the system for a given point in time. Instead you can do the following:

  1. Define an initial state for all objects in the system (e.g position and speed of all objects)
  2. Calculate all forces for all objects in the systems for the current state
  3. Calculate a new state given that we apply the forces from step 2 above to the system for a given amount of time ΔT
  4. Repeat step 2

The accuracy of the simulation will depend on how small we make ΔT, smaller ΔT implies better accuracy but longer computational time.

I have implemented a simple N-body physics engine that can calculate movements of objects caused by gravitational forces. I use the implementation to simulate the movement of planets in our solar system. The simulation is initialized using real physical data about the planets positions and velocities and then calculates changes due to the affect of gravitation. The results are then visualized using JavaFX.

Theoretical background

When Newton described the laws of motion in his monumental Principia Mathematica (1687) it was a remarkable achievement. It states that in principle all movement of objects can be described using the following:.

Newtons first law
”Every body persists in its state of being at rest or of moving uniformly straight forward, except insofar as it is compelled to change its state by force impressed.”

This states that an object will either be at rest or move in a straight path if no external forces are applied to it. If you throw a golf ball in empty space it will continue forever unless there is some force acting upon it. The reason a golf boll don’t vanish when you trow it at earth is because there are several forces acting upon it, e.g gravity and air resistance.

Newtons second law
”The alteration of motion is ever proportional to the motive force impress’d; and is made in the direction of the right line in which that force is impress’d.”
Equation: F = m * a or a = F/m
where F is the net force applied, m is the mass of the body, and a is the body’s acceleration.

This states that when you apply a force to a body it will accelerate proportional to its mass. Massive bodies requires more force to accelerate.

Newtons gravitational law
Equation: F = G (m1 * m2) / r²

    G is the gravitational constant (6.674×10−11 N(m/kg)2)
    m1 is the first mass
    m2 is the second mass
    r is the distance between the centers of the masses.

This states all objects attracts each other by a gravitational force that is proportional to the objects mass and the distance between them.

So to summarize:

  • An object will not change its movement unless some force is acting on it. Note that this also implies that an object will continue to move in a straight line if no force is acting on it and the object was not at rest before.
  • Gravitation is a force that affects all objects. In space gravitation is the dominating force so the movement of planets are in principal only dependent on this force (no air resistance in space…)

Also note that both Newtons second law and his gravitational law denotes vectors, ie forces and accelerations have directions which can be described using motion vectors.

Implementation

The application flow is the following:

  1. Define an initial state for all objects (planets) in the system including location, speed and mass. Initial data was fetched from NASA:s page for solar system dynamics using time = 2017-May-02 00:00:00.0000.
  2. Calculate all forces for all objects in the systems using Newtons law for gravitation (F = G (m1 * m2) / r²).
  3. Calculate the acceleration for all objects in the systems using Newtons second law (F = m * a).
  4. Calculate the change in speed for an object given that the acceleration calculated in the previous step was applied for given time slice (ΔT)
  5. Calculate the change in location for an object given that the speed calculated in the previous step was applied for given ΔT (s = v * t)
  6. Update GUI
  7. Repeat from step 2

Vectors

At heart of the implementation is a three dimensional vector class (Vector3D) and the class Body. The body class contains three vectors describing an objects location, velocity and acceleration:

  • Location is described using x, y and z coordinates (meters).
  • Velocity is described using velocity in x-direction, y-direction and z-direction (meters/second).
  • Acceleration is described using acceleration in x-direction, y-direction and z-direction (meters/second²).

The vectors described are not the standard Vector type in java, instead it is a custom implementation to support vector algebra which makes it possible to do mathematical operations like multiplication and addition on vectors.

Graphical interface
The gui is a minimal JavaFX application the is used to draw circles that represents the bodies the model. The interface also allows the user to navigate by pressing and dragging the mouse and by using the scroll wheel for zooming.

Below is a screenshot while running the simulation:

nbody-solarystem

Final remarks

For me it was a pretty cool the first time I ran the simulation successfully and I could see all planets orbiting the Sun at expected rates etc. You can see that some planets like Mercury have strongly elliptic orbits and that the velocity of planets increases when they are closer to the Sun. All this is achieved by using two simple equations and a bit of high school math.

The complete source for the application can be downloaded from GitHub

Publicerad i Java, JavaFX

Fullstackutvecklaren erövrar mikrotjänstvärlden

Node.js tar över mer och mer på backend. Det finns olika drivkrafter som samverkar här.

Fördelarna är uppenbara från ett kompetensperspektiv där vi direkt river en silo-vägg mellan frontend och backend-utvecklare. Det innebär att alla utvecklare på ett mer naturligt sätt kan röra sig mellan frontend och backend. Vi får ett team som är mer tvärfunktionellt.

Node.js passar även som hand i handske i en Container-arkitektur, där man skalar tjänster genom att starta fler container-instanser och inte genom att starta fler trådar på servern. Arkitekturen i Node.js och javascript är till sin natur asynkron och ihop med Promises blir koden till och med läsbar och man slipper att stacken tar slut bara för att man programmerar alldeles vanliga program-loopar.

C.A.G Edge fokuserar på molnbaserade mikrotjänster och vi finner det viktigare och viktigare med kort turnaround, snabbt att bygga och snabbt att starta och Node.js är en bra match där. Continuous Delivery och Devops trycker också på.
kn-workshop-1024
Vi noterar att Netflix har haft likande erfarenheter.

På Edge har vi arbetat med Node.js på Kubernetes i Google Cloud i mer än ett år nu, och jag har som gammal backend-räv med tekniker som Java 8, Glassfish, IBM WebSphere, Java Enterprise Edition, relationsdatabaser och distribuerade transaktioner i bagaget, hållit på ett tag nu att skifta fokus mot tekniker runt Node.js.

Det jag saknar mest i Javascript är statisk typcheckning. Den dynamiska typningen orsakar onödigt mycket problem när man arbetar efter Continuous Delivery med kontinuerlig refactoring. Jag önskar verkligen att verktygen kunde tydligare varna för när programmeraren gör fel. Det är dyrt att vänta hela vägen till att testet smäller, och det förutsätter att det finns ett automatisk test implementerat som täcker just den koden man ändrar i, vilket långt ifrån alltid är fallet.

Med vår tunga backendkompetens ser vi ibland problem med stabiliteten i en applikation skriven med Javascript i Continuous Delivery sammanhang, även om man skriver koden enligt senaste standarden (Ecmascript 6) och därför är vi nyfikna på och håller på att röra oss mot Typescript. Innan vi är där fullt ut möter vi upp med ännu fler automatiska tester. En fördel med Typescript är att man kan migrera dit från Javascript stegvis, källkodsfil för källkodsfil.

När man kommer från Java-sidan så kan den konsekvent asynkrona programmeringsmodellen i Node.js upplevas som svår snabbt ta full mental kontroll över, om man inte är van vid det sedan tidigare från till exempel Akka. Med Javascript går ju inte ens att skriva ett enkelt integrationstest utan asynkrona callbacks på nästan varje rad.

Java 8 finns fortfarande där och är fortfarande ett bra val på backend i en mikrotjänstvärld i och med Spring Boot och Dropwizard.

Python är också på uppgång i mycket av det som sker på AI-sidan och Machine Learning, inte minst i Googles Tensorflow.

Node.js och javascript är hett nu och det finns förmodligen inget annat ekosystem som rör sig snabbare. Det händer enormt mycket nu och sedan en tid tillbaka, på gott och ont. NPM Registry innehåller nästan 100´000 paket, men man kan förmoda att bara en del av dessa håller produktionskvalitet och den allmänna känslan när man har erfarenhet från Java och backend är också att det inte är riktigt lika moget och stabilt än.

Vi på Edge är på Node.js-tåget och har gift ihop de bra sakerna i den lättrörliga Javascript-kulturen med nödvändiga delar från den mer konservativa backend- och Java-kulturen, och har toppat det med det senaste inom Continuous Delivery, Containers och Cloud. Det är en inspirerande resa!

Publicerad i Cloud Computing, Continuous Delivery, DevOps, DOcker, Java, Javascript, Node.js, npm, typescript

Pipelinelabb med Concourse.ci

Nyligen återsamlades pipelinegruppen igen för att utvärdera CI-verktyget concourse.ci.

Screen Shot 2017-05-06 at 17.45.54

Pipelinegruppen är en grupp devops, utvecklare och arkitekter från olika företag med ett gemensamt intresse för pipeline-teknik. Den här gången höll vi till i C.A.Gs lokaler inne i city.

Idag kör vi oftast med jenkins och multibranch pipeline och GoCD. Idealet är att vi kan hitta en pipeline som går att köra som tjänst och, som är lika bra och visuellt presentabel som GoCD med tilläggen att pipeline-konfigurationen på ett bra sätt kan representeras i en yaml-fil i applikationens git-repo.

Vi körde gemensamt igenom en tutorial under ledning av Mikael Sennerholm från C.A.G Edge som forsade igenom de olika stegen i ett högt tempo på projektorn.

pipelinelabb-800

Det sista vi gjorde var att låta pipelinen deploya en Node.js applikation i ett Kubernetes-kluster i Google Cloud.

När vi kollar på CI-verktyg för att bygga pipelines vill vi bland annat få ut följande från en pipeline:

– Cool visualisering typ dynamisk dashboard av såväl alla pipelines som stegen i en pipeline.

– Tydlig deployment-historik, vem deployade vad vart

– SaaS = vi vill slippa drift och uppgradering av själva pipelinen

– Pipeline-konfig versionshanterad i appens eget repo = minimal setup i själva pipelinen, typ bara repo-url.
Byggsteg med docker

– Möjlighet att dela pipeline-konfig/logik mellan alla appar så vi slipper copy-paste mellan apparna

– Möjlighet att enkelt se vad som skiljer mellan version X och Y i produktion av tjänsten, dvs, inte bara källkoden, utan även eventuella testfallsrepos, helper bibliotek, docker image version den kör på m.m. så man kan se att version Y slutade fungera pga av att vi uppdaterade paket från en version till en annan. Det är en funktion i GoCD som är riktigt snygg

Vi avslutade labben med att konstatera att concourse.ci har en cool visualisering, att den delar många bra funktioner med GoCD men dess Kubernetes-plugin fungerar inte som vi tänkt oss så deployen på Kubernetes hann vi inte få till innan klockan blev för mycket.

Concourse.ci är liksom GoCD inte SaaS men supportar yaml-konfiguration i app-repot.

Den har några snygga saker som byggsteg i Docker vilket gör att man på ett naturligt vis kan versionshantera även mjukvaran som bygger ihop applikationen.

Kommer vi välja Concourse.ci till nästa pipeline vi sätter upp? Concourse.ci är kapabel och snygg, men förmodligen inte än i alla fall, GoCD äger fortfarande.

Publicerad i Cloud Computing, Continuous Delivery, DevOps, DOcker, Uncategorized

Med katamaran över Stilla havet

Kenobi at anchor

Lukas Wilczek är konsult på C.A.G Contactor och jobbar i uppdrag som webbutvecklare och Scrum Master. Under 2016 var han tjänstledig för att förverkliga en seglingsdröm och berättar i detta blogginlägg om seglingen med tre vänner över Stilla havet. Hela historien finns på kenobicrossing.com.

Förra hösten, på väg hem från seglingssemester med vänner i Stockholms skärgård, dök idén om en långsegling upp. Min dröm att segla över Stilla havet, från Karibien till Australien, var något som följt med mig sedan min första långsegling för fyra år sedan. Då seglade jag och en vän en 27 fots Albin Vega från Ängelholm till Martinique. I Karibien fick jag höra många stories om Stilla havet och ett sug att komma dit väcktes. Men jag kände ändå att jag redan gjort min långsegling och att det kanske skulle bli av först långt senare i livet. Men nu hade jag alltså tre vänner som hade vilja och möjlighet att följa med – då gäller det att agera snabbt innan någon kommer på andra tankar! Besättningen bestod av nya kompisen Johan från uppdraget på Tillväxtverket och två gamla vänner, Hampus och Simon. Vi bestämde oss alla på allvar i september och i januari flög vi ner till Martinique för att köpa båt.

Kenobi crew - Simon, Hampus, Johan, Lukas

Simon, Hampus, Johan och Lukas

Båtköpandet var en resa i sig och slutade i en 45 fot lång katamaran, en Leopard 45 från 1998 byggd av Robertson & Caine i Sydafrika. På grund av sitt, enligt oss, rymdskeppsliknande utseende fick den namnet Kenobi. Vår research visade att marknaden för katamaraner var bättre i Australien än i Karibien så vi borde kunna göra en god affär. Katamaransegling över hav är lite kontroversiellt i Sverige, “vad ska ni göra om den välter?”-frågan var en vanlig reaktion från andra havsseglande personer vi pratade med. Jo visst, de har en poäng. Men för denna rutt passar en katamaran perfekt. Vi seglar i stabil passadvindssäsong nästan hela vägen och slipper enkelskrovsbåtens rullning då vinden kommer rakt bakifrån. Och med bara 1,3 meter djupgående kan vi komma in till öar och atoller där vi kan ankra nära stränder som båtar med djup köl inte vågar sig in till. Och såklart den uppenbara fördelen – varsin kabin med dubbelsäng och tillhörande badrum! Sittbrunnen är också helt enorm och genom den stora dörren finns salongen med ett riktigt kök och soffgrupp. Kontrasten mot den gamla Vegan kunde inte bli större.

Efter att köpet gått igenom och brister som upptäckts under inspektionen rättats till kastade vi loss den 20:e mars för första seglingen 70 sjömil (ca 12 landmil) ner till St:Vincent. Allt gick bra, ingen större sjösjuka och Kenobi seglade snabbt i den friska passaden. Fiskespöna åkte i direkt och vi fick njuta av den första av många fiskar fångade på Kenobi, en fin mahi-mahi. Vi fortsatte ner till Bonaire för lite dykning och kitesurf och sen vidare till det viktiga stoppet i Cartagena, Colombia. Här tog vi upp båten på land och spenderade tio dagar på varvet Ferroalquimar med att fixa en del större jobb vi ville göra. Lagningar och förstärkningar av fiberglas, måla nya stripes och polering av gelcoat. Det var ett hårt, skitigt och svettigt jobb, temperaturen var 40 grader och sandmoln blåste omkring på varvet så alla luckor fick hållas stängda. Här gällde det att arbeta bra som ett team. Erfarenheter från Scrum Master rollen och inte minst lärdomar om min och andras personlighetstyp från DISC-analysen har varit värdefulla att ha med sig i rollen som kapten. Vi är alla fyra mycket olika och det har varit bra för gruppdynamiken, vi hade både driv och lugn som kunde skapa balans.

Nästa stora mål var Panamakanalen. Man klarerar in i Colon och lägger sig sen i Shelter Bay Marina i väntan på att kanalmyndigheten ska ge en tid för passage. Det är mycket byråkrati och kostar en slant. Här träffade vi besättningar från många andra båtar, seglingsvärlden är som en stor familj och många vi träffade höll vi mailkontakt med via sattelittelefon. Eftersom de flesta följer ungefär samma rutt med passadvinden hände det att man träffades åter långt senare på små öar mitt i ingenstans. Efter en dryg vecka var det äntligen vår tur att passera genom kanalen. Det var tre segelbåtar åt gången. Vi fick en enkelskrovare surrad på varje sida och drev ekipaget med våra två 56hp Yanmar motorer. På styrbord en brittisk 49 fot Jeanneau SO och på babord en rysk-reggad mindre HR. Utmärkta fendrar tyckte vi. Ombord hade vi en pilot som guidade oss genom de tre slussarna upp till Gatun sjön där vi ankrade för natten. Tjut från aporna hörde vi från träden och i sjön skulle det finnas krokodiler. Tidigt nästa morgon kom en ny pilot ombord och vi fortsatte vidare genom sjön och tre massiva slussar som nu gick nedåt. I slussarna samsades vi med enorma lyxkryssarfartyg och Maersk containerskepp. Vi kom oskadda genom den sista slussen och var äntligen i Stilla havet.

Båten var i toppform, fullastad med frukt, grönt och godsaker från marknaden i Panama City när vi kastade loss den 4:e april mot Galapagos. Två dagar ut på havet är vi mitt i ITCZ, Inter-Tropical Convergence Zone, ett meteorologiskt signifikant område nära ekvatorn med ostadigt väder. Vi hade regn och blixtrar kring oss flera dagar men det var inget att göra, det finns ingen väg runt utan bara att köra på. Risken att bli träffad av blixten var ändå typ en på miljonen hade jag läst så ingen fara, fram med GoPro och kamera bara. Men rätt vad det är smäller det till rakt över oss och jag som håller i dörrkarmen får en stöt så det ringer i öronen – vi har blivit träffade! I salongen ser vi rök vid taket och det luktar bränd elektronik. Efter att vi grabbat brandsläckare och sprungit runt båten på jakt efter hål eller bränder konstaterade vi att båten var intakt. Med elektroniken var det värre – autopilot, radar, plotter, vindinstrument, stora kylen, laptop mm var grillade. Som tur var startade motorerna fortfarande, seglen var det inget fel på och navigera gjorde vi ändå mest med appen Navionics på iPhone och iPad som hade klarat sig. Inte mycket att göra, bara att ställa sig till rors och handstyra i roterande tretimmarspass de nio dygnen som överfarten tog.

Ankomsten i Galapagos var smått magisk, i soluppgången siktades öarna bortom ett kav lugnt hav där vi såg valar, delfiner och mantarockor som gjorde saltomortaler! Sedan två dygn hade vi redan haft fripassagerare ombord, sex stycken “red footed boobies” (en ovanlig typ av sjöfågel) som använde Kenobis fördäck och trampoliner som fiskeplattform. Hela Galapagos-upplevelsen var lite som att vara med i en Disneyfilm, jag kunde vara ute och paddla med SUP-brädan en morgon och under samma tur se havssköldpaddor, sjölejon, pingviner, rockor och havsleguaner simma runt och under brädan, helt ofattbart!

Sjölejonen gillade Kenobis rymliga akterdäck

Efter fem veckor i djurparadiset var det dags för den längsta korsningen, 3000 sjömil till Marquesasöarna i Franska Polynesien. Fisket började storartat, två nya arter för oss fångades – en pink spotted snapper och en “sierra” som liknar spansk kungsmakrill. Only in Galapagos. En timme senare högg det rejält och vi drog upp en big eye tuna på 30 kg! Sen behövde vi inte fiska på några dagar. Autopiloten hade inte gått att få utbytt i Galapagos så schemat med tretimmarspass rullade på där ansvar för lunch eller middag också fanns inbakat. Kl 12-15 hade vi “Mållgan-passet”, ett gemensamt pass då vi också tog hand om dagligt underhåll: kolla ev nötning på tampar och rigg, batterivattennivå, ruttenhetsgrad på potatisförrådet osv. De veckoliga båtråden fortsatte också som vanligt. De fungerade som en retrospective där vi gick varvet runt och alla fick ge ris och ros och vädra eventuella frustrationer. Här bestämdes också vilka rutiner vi ville ha ombord. Jag tror det här var värdefullt för oss och bidrog till att vi faktiskt höll väldigt bra sams under hela resan. Vinden hade vi med oss hela överfarten, ibland stark då vi revade segel och fick leva med slamret från vågor som slog upp i mittskeppet. Vårt snabbaste dygn gjorde vi 220 sjömil, snittade alltså 9,5 knop. Då vinden var svag hissade vi gennakern och gled fram i 3-4 knop. När vi siktade Hiva-Oa i Marquesas hade vi varit till havs i 21 dygn och det var en härlig syn!

Vi kan förstå att fransmännen gärna hänger kvar i sina gamla kolonier, i Franska Polynesien finns verkligen några riktiga paradis. Marquesas är den geologiskt yngsta ögruppen och har dramatiska Jurassic Park-vulkantoppar klädda i djungel. Tuamotus-atollerna är äldre, sjunkna vulkanöar där bara det omgärdande korallrevet finns kvar. Tidvattnet skapar en kanal genom revet in till lagunen och detta är den häftigaste platsen man kan ta sig till med en segelbåt. Ensamma, ankrade utanför den lilla motu där Kon-Tiki förlist på atollen Raroia harpunerade vi fisk bland korallerna under båten och plockade kokosnötter på land. Efter några veckor när vi ledsnat på detta (det blir lite långtråkigt till slut) tog vi oss till Sällskapsöarna där bl a Tahiti, Moorea och Bora Bora ingår. Geologiskt befinner de sig mellan Marquesas och Tuamotus, öarna har hög vulkantopp och ett omgärdande barriärrev som skapar turkosblåa laguner. Vackrare öar får man leta efter och det är ingen slump att de är så populära. Vi spenderade dock den största delan av tiden här i Marina Taina på Tahiti där vi med vårt försäkringsbolags hjälp bytte så mycket av de skadade systemen som vi kunde. Äntligen hade vi autopilot igen!

Resort-meccat Bora Bora blev vår sista ö i Franska Polynesien där vi nu spenderat sammanlagt tre månader. Därifrån satte vi kurs den 6:e oktober mot Aitutaki i Cook Islands. På vägen fångades resans största fisk – en gulfenad tonfisk på 44 kilo! Tonfisken är enormt stark och det tog 1,5 timme att trötta ut den så pass att vi tillsammans kunde lyfta den med huggkroken upp på trampolinen. En skvätt alkohol i gälarna dödar den snabbt och sedan påbörjades än en gång operation fiskfabrik. Vi hade ingen frys men tog ändå hand om hela fisken; filéer lades längst ned i kylen, strimlor marinerades i soya och torkades i solen och många kilon kokades i havsvatten och lades sedan in i vinäger och förvarades i lufttäta boxar. När vi kom fram till Aitutaki var vi glada över vår katamarans grunda kölar, i den trånga passagen in till lagunen hade vi bara 10cm till godo under kölen! Två stålbåtar vi kände fick ankra utanför ön istället, en ankringsplats som bara var säker så länge vinden höll sig östlig.

Vi gjorde kortare stopp på Palmerston Atoll och Niue innan vi kom till Fiji där vi ville lägga lite mer tid. Besöken på öarna Fulaga och Matuku i Laugruppen i Fiji blev höjdpunkterna på resan för mig. De är oerhört vackra öar och här lever öborna mycket traditionellt och använder knappt pengar alls. Det första man ska göra då man anländer till en ö här är att ta sig till huvudbyn och be att få träffa hövdingen för en sevu-sevu ceremoni. Här ger vi en offergåva i form av en bunt torkade kavarötter. Dessa mortlas sedan till ett pulver som blandas med vatten och dricks som en sällskapsdryck. Hövdingen talar på fijianska och talmannen översätter till engelska och förklarar att vi nu är del av byn, har rätt att fiska i vattnen och att har vi några problem ska vi bara säga till. Hur länge vill ni stanna, ett eller två år, säger de med ett skratt. Det var en stor upplevelse att få spendera tid här med människor som levde enkelt men ändå så väl på sitt eget fiske och jordbruk och som var så glada, nyfikna och gästvänliga.

Kenobi i Matuku, Fiji

Kenobi i Matuku, Fiji

Tyvärr kunde vi inte stanna här mer än två veckor. Vi var nu mitt i november och officiellt i cyklonsäsong. När vi klarerade ut ur huvudstaden Suva i Fiji var vi den enda segelbåten där, alla andra var redan i trygghet i Nya Zeeland eller Australien som ligger utanför cyklonområdet. Men vädret såg fortfarande stabilt ut och med järnkoll på väder GRIB-filerna vi laddade ner med sattelittelefonen kände vi oss ändå trygga. Efter ett kort stopp i Vanuatu gjorde vi den nio dygn långa sista korsningen mot Australien och seglade den femte december in i Sydney Harbour, vilken känsla!

Australien var alltid vårt slutmål och här skulle Kenobi säljas. Men först hade vi en rejäl backlog med saker att fixa och efter det ville vi polera upp båten rejält inför försäljningen. Vi jobbade fokuserat i över fem veckor med detta och lämnade till slut båten med en broker, stående på land på varvet The Boat Works i Gold Coast. Dagen innan jag flög hem från Australien hann jag visa den för ett par från Port Douglas och dom har nu köpt den! Någon vinst blev det aldrig men vi gick jämnt ut på inköpspriset och är supernöjda. Nya ägarna drömmer om att segla upp till Marshall öarna och jag gläder mig åt att Kenobi kommer segla vidare mot nya äventyr.

Sydney!

Sydney!

Publicerad i Uncategorized

Cloud & Pipelines 2017 – frukostseminarium och labb

Fredagen den 13:e januari 2017 håller vi frukostseminarium följt av en heldags lärarledd cloud-pipeline-labbdag på C.A.G-kontoret i KistaOne, Jan Stenbecks Torg 17.

Vi inleder kl 09:00 med en presentation på c:a 45 minuter som på ett översiktligt plan handlar om framsteg inom moln och pipeline-teknik, Continuous Delivery och vilken betydelse det har och får för hur vi arbetar.

cag-labb

Sedan kavlar vi upp ärmarna, plockar fram trollerilådan och visar vad man kan göra med modern container- och molnteknik. Resten av dagen blir det korta föreläsningar blandat med labbar.

Vi kommer att visa hur man 2017 sätter upp hela miljöer med containers i molnet, deploya tjänster med Node.js och Java, och hur man gör för att skapa förutsättningar för att kunna träna på till exempel den kritiska databasuppgraderingen i produktionsmiljön. Vi kommer att jonglera med molnmiljöer och pipelines, och gemensamt känna vinden i håret.

För dig som är med på labben, ta med din egen laptop preppad med din favoriteditor, git och ett github-konto, ssh-klient och en uppdaterad version av Docker. Vi ser gärna att ni arbetar två eller tre på en laptop, så alla behöver inte ha med sig dator.

Seminariet börjar 9.00 på CAG Contactor AB, Jan Stenbecks Torg 17 i Kista. Det är lagom att komma runt 8.30 för att packa upp datorn, koppla upp till nätverket och äta en frukostmacka. Vi räknar med att vara klara till kl 15.30 då kursen avslutas och vi övergår i fredagspub och cloud-debriefing.

Anmäl om du kommer till daniel.marell@cag.se. Ange ”Frukostseminarium” eller ”Frukostseminarium+labb[+eventuella matpreferenser till lunchen].

Antalet platser är begränsade.

Varmt välkommen!
Mikael Sennerholm, C.A.G
Kristoffer Vidmo, C.A.G
Daniel Marell, C.A.G

Publicerad i Cloud Computing, Continuous Delivery, DevOps, DOcker, Java, Node.js

Hitta IP-adress för aktiv image i VMWare Fusion och sätta DOCKER_HOST

Om man skapat en Docker-maskin baserat på VMWare Fusion på MacOSX och får följande fel när man kör docker-kommandon:

$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

behöver man sätta miljövariabeln DOCKER_HOST.

För att ta reda på IP-adressen för VMWare-imagen (OBS, den måste vara startad) och sätta miljövariabeln gör enligt följande:

$ /Applications/VMware\ Fusion.app/Contents/Library/vmrun getGuestIPAddress /Volumes/Data/Docker/DockerUbuntu16.vmwarevm/DockerUbuntu16.vmx
172.16.91.135
$ export DOCKER_HOST=tcp://172.16.91.135:2375

Till kommandot vmrun anger man alltså full path på .vmx-filen i sin wmware-image.

Vilket man kan foga ihop till:

$ export DOCKER_HOST=tcp://$(/Applications/VMware\ Fusion.app/Contents/Library/vmrun getGuestIPAddress /Volumes/Data/Docker/DockerUbuntu16.vmwarevm/DockerUbuntu16.vmx):2375

Vilket man sedan kan stoppa in i lämplig shell-setup (.bashrc, e.dyl). Kom dock ihåg att VMWare-imagen måste vara startad!

Publicerad i DOcker, macOS, VMWare Fusion

macOS Sierra för Javautvecklare

Jag uppdaterade min Macbook till macOS Sierra idag och stötte bara på några små saker.

Du bör definitivt uppgradera Homebrew innan installationen. Detta för att Homebrew nu har fixat så att den klarar av att macOS sätter ägarskapet till /usr/local till root i samband med uppdateringen till Sierra.

Java är numer inget problem. IntelliJ bundlar sin egen Java 8 och den Java 8 jag själv hade installerad via brew cask fungerade även efter installationen.

Som vanligt får man installera om command line tools om man inte har full XCode installerad – men det talar

brew doctor snällt om.

xcode-select --install

Nya filsystemet som väl är det enda värt namnet i macOS kommer först nästa år.

Publicerad i Java, macOS, OS X

Windows 10 anniversary editions viktigaste feature – bash

Idag släpptes Windows 10 en stor uppdatering – Anniversary edition. Den viktigaste featuren är naturligtvis att man nu får möjlighet att köra Ubuntu userspace på maskinen!

Instruktioner för att slå på här.

För att slå på ska man slå på developer mode och slå på Windows subsystem for Linux (Beta).

Man installerar lämpligen en bra UTF-8 font också. Klicka på länken och ladda hem senaste versionen som zip-fil. Packa upp och gå till ttf katalogen. Dubbelklicka på DejaVuSansMono.ttf Klicka på installeraknappen i fönstret som öppnas.

sudo apt-get install git
git clone https://github.com/ogr3/bash-git-prompt.git ~/.bash-git-prompt --depth=1

Lägg till

GIT_PROMPT_THEME=TruncatedPwd_WindowTitle
source ~/.bash-git-prompt/gitprompt.sh

i ~/.bashrc och starta om Bash on Ubuntu on Windows.

Voilá, nu fungerar bash-git-prompt på windows utan att krångla med Cygwin.

2016-08-02

Publicerad i Linux, Windows

Dynamic programming with Java

Introduction

Dynamic programming is a very powerful tool  for optimization that not all developers have encountered.

So what is dynamic programming? Dynamic programming is a method for solving complex problems by dividing them into simpler subproblems and storing the solution to each subproblem so it can be looked up later. There is another type of algorithm, the ”greedy” algorithm, that also solves problem by dividing them into to subproblem but the difference is that for greedy algorithms you only use the result of the last subproblem when calculating the result for the following problem. The greedy approach will not work for more complicated problems.

Example: Using dynamic programming to attack the death star

Suppose you are the commander of the alliance fleet and you want to attack the death star. Rebel spies have gathered information about potential targets on the death star and calculated the amount of damage that would be caused by attacking these. The problem is how to deal with the protective shield surrounding the death star and the imperial star fleet. Now the alliance fleet has a brand new star ship that is able to penetrate the shield but this still leaves the problem with the imperial fleet, what to do? You come up with the idea that the rest of the rebel fleet should make a diversion by attacking an imperial stronghold on a nearby planet. This will create a window of opportunity for say 10 minutes. So the goal is to make as much possible damage to the death star given these 10 minutes.

You have the following available missions:

Mission nr Estimated time (minutes) Estimated damage on death star (%)
1 2 4
2 4 10
3 6 12
4 7 14

Let T be the total time (10 minutes).
So we have the following inputs:

  • Missions m1,….,m4
  • Each mission takes time t1,…., t4
  • Each mission causes damage d1,…., d4
  • Total time T = 10 minutes

What missions should we choose given the timeframe of 10 minutes to make the most damage?

Initial solution

To make things easier we will initially assume that the missions are ”repeatable” that is it is possible to execute the same mission several times.

A naive and ”greedy” approach would be to always choose the mission that has makes the most damage and is possible to execute given the time left. This would result in the following:

7 m 2 1 m
m4 m1

This results in a total of 18% damage. It is obvious that a better solution would be:

4 m 4 m 2 m
m2 m2 m1

This results in a total of 24% damage.

Now for this simple problem with few items (missions) and a few discrete values (amount of damage) it is pretty easy to find the optimal solution by visual inspection but when the number of items increases it will soon be impossible.

It is obvious that in order to find an optimal solution you must investigate different combinations of items (missions). One way of doing it would be to compare the value for all possible combinations of missions for a given time limit. Say that we have 10 items and that each item can be position in 1 of 20 locations that means 10^20 combinations = it will take more than a lifetime to calculate so we need a better solution. Dynamic programming to rescue!

We will try to find a solution to the problem by dividing it into subproblems.

Lets say we have an optimal solution for total time T and it contains missions m1, mi, mn with their corresponding times of t1, ti, tn:

t1 ti tn
m1 mi mn

Now if we remove mission mi with time ti, clearly what is left is an optimal solution for time T – ti. This implies that if we want to calculate maximal damage for a given time, damage(t), then we can do this by solving damage(t – ti) + di. Here ”i” can denote any mission with time ti and damage di but we dont know which one so we must try all of them.

Lets define the subproblems more formally:
D(t) is the maximal damage for that can be achieved given a timeframe of t.
Then D(t) can be defined using the subproblem: max { D(t – ti) + di}. Where ti <= t


So in order to find maximal D(t) the maximal damage for t – ti must already be known. We will therefore start with the simplest case e.g D(t0) = 0 and then move forward, minute by minute, until we reach t.

For a given timelimit t we will try to add all possible missions with time less or equal to the total available time and then choose the mission that result in greatest damage in total. To calculate the optimal total damage for a given time we need to know the optimal total damage for all cases with less time so that we can compare the net effect for adding a given mission.

An optimal vector for t0,…,t10 will be:

t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10
0% 0% 4% 4% 10% 10% 14% 14% 20% 20% 24%

How do we reach this result?

  • For t0, t1 the maximal damage will be 0% since there are no missions that are less than 2 minutes
  • For t2, t3 the maximal damage will be 4% since the only mission that can be executed is m1
  • For t4 things get a little more interesting. We can now choose to execute m1 or m2. To calculate which one will result in most damage for the total solution we will compare these two options. To estimate the total damage for using m1 we will look at the optimal damage for t4-2 = 4% and then add the damage for m1 (4%) which implies a total damage of 8%. To estimate the total damage for using m2 we will look at the optimal damage for t4-4 (0%) and then add the damage for m2 (10%) which implies a total damage of 10%. To get maximal damage we therefore choose m2.

The following values are calculated in a similar way and note how we look up the results of previous subproblems two make the right decision for a given point in time.

The optimal damage given time = 10 minutes will be the value for t10 which is 24% but what missions were involved for reaching this value?

To find the missions we need to backtrack which subproblems were used to arrive at the value of 24% for t10.

  • For t10 we added mission m2 that has time t2 = 4 minutes
  • For t10 – 4 we also added mission m2 that has time t2 = 4 minutes
  • For t10 – 4 – 4 we added mission m1 that has time t1 = 2 minutes
t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10
0% 0% 4% 4% 10% 10% 14% 14% 20% 20% 24%

To summarize, the solution included:

  • m2 (d2 = 10%, t2 = 4 minutes)
  • m2 (d2 = 10%, t2 = 4 minutes)
  • m1 (d1 = 4%, t1 = 2 minutes)
  • Total damage 24%, total time = 10 minutes

Below is function in Java that can be used to calculate a vector of damage for a given total time. The function returns a matrix where the first column contains the damage in procent and the second column is a pointer to the mission that was used chosen for the current time.

int[][] optimalForRepeatableMissions(int totalTime, int[] missionTimes, int[] missionDamages) {
   int totalNrOfAvailableMissions = missionTimes.length;
   int damages[][] = new int[totalTime + 1][2]; // add one extra dimension for storing index for used mission

   for (int currentTotalTime = 1; currentTotalTime <= totalTime; currentTotalTime++) {
      damages[currentTotalTime][1] = -1;
      for (int missionNr = 1; missionNr <= totalNrOfAvailableMissions; missionNr++) {
         int missionTime = missionTimes[missionNr - 1];
         int damage = missionDamages[missionNr - 1];
         if (missionTime <= currentTotalTime) {
int damageForAddingCurrentMission = damages[currentTotalTime - missionTime][0] + damage; if (damages[currentTotalTime][0] < damageForAddingCurrentMission) { damages[currentTotalTime][0] = damageForAddingCurrentMission; damages[currentTotalTime][1] = missionNr; } } } } return damages; }

To print the maximal damage for the previous example it can be invoked like this:

int[] missionTimes = new int[] { 2, 4, 6, 7 };
int[] missionDamages = new int[] { 4, 10, 12, 14 };
int[][] damages = optimalForRepeatableMissions(10, missionTimes, missionDamages);
System.out.println(damages[damages.length - 1][0]);

The expected running time for calculating maximal damage is O(Tn) where n is the number of available missions and T is total available time.

Final solution

Now consider a more "realistic" situation where the missions are not repeatable (its only possible to blow up a target once...) what changes must we do to our initial solution?

Previous we defined a subproblem as:

max { D(t - ti) + di}. Where ti <= t

But in the statement above we assumed that mission mi with time ti and damage di could be any mission. This is no longer true since a given mission can only be used once so we can only consider missions that have not been executed. We need to add an additional variable to indicate what missions are being used.

Therefore will use the following definitions:
D(t, i) is the maximal damage that can be achieved given a timeframe of t using missions 1,...,i
Then D(t, i) can be defined using the subproblem: max { D(t - ti, i - 1) + di, D(t, i - 1)}

D(t - ti, i - 1) will be applied when mission i is needed to achieve the optimal solution and D(t, i - 1) will be applied when i is not needed to achieve the optimal solution.

Instead of a vector the result will be a matrix with time on one axis and number of available missions on the other. We will calculate the maximum damage progressively looking up the damage for previous cases.

t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10
m0 0 0 0 0 0 0 0 0 0 0 0
m1 0 0 4 4 4 4 4 4 4 4 4
m2 0 0 4 4 10 10 14 14 14 14 14
m3 0 0 4 4 10 10 14 14 16 16 22
m4 0 0 4 4 10 10 14 14 16 18 22

We find that using non repeatable missions leads to a total damage of 22% for time = 10 minutes.

We can find the path taken through the matrix (ie what missions were used) by backtracking from D(t10, m4).

  • We see that moving from D(t10, m4) to D(t10, m3) does not imply any change in damage, this means that m4 was not included in the solution.
  • We see that moving from D(t10, m3) to D(t10, m2) implies a change in damage, this means that m3 was included in the solution.
  • m3 has a mission time of 6 minutes which means that we will move back 6 minutes to find previous solution so we end up on D(t4, m2)
  • Using the same reasoning again we can conlude that m2 was included in the solution.
  • m2 has a mission time of 4 minutes which leads us back to time = 0 and we are finished

To summarize, the final solution included:

  • m3 (d3 = 12%, t3 = 6 minutes)
  • m2 (d2 = 10%, t2 = 4 minutes)
  • Total damage 22%, total time = 10 minutes

Below is the function in Java that is used to calculate the matrix above.

int[][] optimalForNonRepeatableMissions(final int totalTime, final int[] missionTimes, final int[] missionDamages) {
   int totAvailableMissions = missionTimes.length;
   int damages[][] = new int[totalTime + 1][totAvailableMissions + 1];
   for (int missionNr = 1; missionNr <= totAvailableMissions; missionNr++) {
      int missionTime = missionTimes[missionNr - 1];
      int damage = missionDamages[missionNr - 1];
      for (int currentTotTime = 1; currentTotTime <= totalTime; currentTotTime++) {
         damages[currentTotTime][missionNr] = damages[currentTotTime][missionNr - 1];
         if (missionTime <= currentTotTime) {
            int damageAddingCurrentMission = damages[currentTotTime - missionTime][missionNr - 1] + damage;
            if (damages[currentTotTime][missionNr] < damageAddingCurrentMission) {
               damages[currentTotTime][missionNr] = damageAddingCurrentMission;
            }
         }
      }
   }
   return damages;
}

The complete java code example can be downloaded from GitHub

May the force be with you...

 

Publicerad i Java

//Build/ 2016

Bro

Pier Madness

Fail Bail Jail

Fail Bail Jail

Jag har precis gått från Pier 38 till Pier 39, vilket kanske inte låter som någon större bedrift, låt mig förklara.

Jag tar det från början. Min plan för dagen var att först besöka REI som jag varit lite nyfiken på ett tag och sedan ta mig ner till området kring Fisherman’s wharf  för att hitta ett mysigt hak och skriva det ni nu läser. Betyder det att planen gick i lås? Tja, ungefär.

Jag bestämde mig för att fotvandra ner till REI som ligger i SoMa. Jag går sydöst längs 6th street. Ett par kvarter söder om Market börjar stan ändra karaktär och jag får lite känslan av att inte passa in.
Efter ytterligare några kvarter börjar det bli mer nedgångna industrilokaler och den där typen av barer som man mest ser på dåliga polisserier på TV. Hus och trädgårdar, dock inga träd i dom, dekoreras av kilometervis med taggtråd, lite getto-chict.
Jag ser inte längre några andra människor till fots ute på gatorna. Efter att passerat ett par motorvägsöverfarter börjar jag närma mig mitt mål. Jag ska bara gå ner för Bryant street en bit, det visar sig att vägen passerar framför stadens domstolsbyggnad och att området är fullt med härligt nedgångna Bail Bonds-firmor som jag också bara tidigare sätt på film, det ger hela stället en ”skön” känsla av urban desperation. En polisbil glider sakta förbi.

Läst senare på webben, ”The zone around Sixth and Mission can be sketchy if you’re walking alone, and at the very least the unschooled wanderer could come away with an impression of nothing more than highway overpasses and warehouses.” och jag kan bara hålla med.

Efter mitt besök på REI så bestämde jag mig för att prova min första Über, skapade konto, registrerade uppgifter, kort och sånt. Vilket fungerade hyfsat bra från mobilen.  Det blev svårare när jag skulle välja destination, efter ett par försök föreslog appen  Pier 38 och jag tänkte, ”jaja, det är nog ganska nära”. Efter en liten stund kommer Nancy i sin lilla svarta Toyota. Hon körde inte alls den sträckningen som jag föreställt mig men turen var ju förbetald och bara jag kom dit jag skulle så… Vi småpratar lite om allt möjligt, plötsligt stannar Nancy bilen och säger, ”nu är vi framme, Pier 38, det var hit du skulle”.

Jag kliver ur och ser mig om, visserligen är det en pir och vid vattnet men inte alls där jag trott, det var nog inte hit jag skulle.

Ej röd bro

En rejäl bro, men inte röd

Pier 39, Fisherman’s wharfs mest prominenta del, ligger bredvid Pier 35 och ca 4 kilometer därifrån ligger Pier 38. På vägen dit passerar man, i ordning, bland annat pirerna 31, 26, 22 1/2, 14, 3, 7, 15, 22, 31. Kanske inte en av de mer vedertagna talserierna. Så, bara 4 kilometer till på betong i stekande sol innan jag är framme. Det var i alla fall en vacker promenad med staden på ena sidan, vattnet på den andra och den dubbeldäckade motorvägsbron på den tredje.

Retrospektiv Margarita

Margarita

Toppen Margarita

I Fisherman’s wharf hittar jag ganska snabbt en liten Tequilabar, den ligger ett kvarter upp från de riktiga turistfällorna så det är många lediga bord. Snart sitter jag i den Kaliforniska vårsolen med en mycket läskande Margarita framför mig och försöker sammanfatta intrycken från det nyss avlutade //Build/ 2016.

Det började sedvanligt med registreringen, om man utfört sin online anmälan korrekt kunde man registrera sig med hjälp av en streckkod och en terminal, sen var det 90 minuters kö för att få sitt konferenspaket. Det fanns som tur var en alternativ kö, där man fick hjälp med att skanna streckkoden och de delade ut konferenspaketet direkt, den kön tog 10 minuter.

Registrerad och nöjd bär det av till Press Club för kvällens första event, det blir snart ganska fullt, men det är en högklassig tillställning med bra stämning. Därefter blir det Swedes@Build på Jillians, inte riktigt lika snofsigt men en härlig stämning så vi går vidare till Thirsty Bear Brewery för ett par intressanta öl till, bl a en Panda som smakade väldigt mycket choklad. Kanske inte min favorit.

I år hade de valt att göra om konferensen för att leverera mer av det som tidigare års delegater saknat och tagit bort det som de var missnöjda med. Så ingen frukost på konferensen.  Det nya upplägget var till en början ganska förvirrande och blir nog det igen efter ett par Margaritas till.

06.30 bara att tvinga sig upp för att hinna med en väldigt onyttig Diner-frukost innan det är dags att ställa sig i kön till keynoten.

Satya Nadella inleder konferensen med ett inspirerande tal om Microsofts relation med utvecklarna, teknik och öppenhet. Det var inte de riktigt stora nyheternas år men det fanns mycket som var intressant, inspirerande och roligt.

Visual Studio 2015, update 2

Några godbitar:
Xamarin for VS
VS Tools for Apache Cordova
VS Tools for UWA Development
Python Tools for VS

Xamarin har nu integrerats i alla versioner av Visual Studio  2015, ja även community edition, ladda hem update 2 och skapa lite sköna cross-platform appar.

https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx

Visual Studio 15 och .NET Core

Om ni känner er lite mer vågade kan ni prova förhandsversionen av Visual Studio 15, käckt namn som säkert inte kommer orsaka några missförstånd 🙂

Stödjer Cross-Platform utveckling med .NET Core som kommer existera parallellt med .NET Framework och Mono.

.NET Core går att köra på Windows, OS X och ett flertal Linux distributioner. .NET Core är mycket mer modulärt än .NET Framework och kan anpassas efter behov.
Källkoden är distribuerad på GitHub så det är bara att sätta igång och skapa sin egen variant eller hjälp MS lite på traven.

https://www.visualstudio.com/news/vs15-preview-vs

Men vad hände med de andra versionerna då?

Jag citerar Scott Hanselman:

  • ASP.NET 5 is now ASP.NET Core 1.0.
  • .NET Core 5 is now .NET Core 1.0.
  • Entity Framework 7 is now Entity Framework Core 1.0 or EF Core 1.0 colloquially.
Målbild

Målbild för .NET

IoT

Vårens utbildningsresa för Microsoftgänget visade sig vara ”spot on”. Under konferensen satsades det mycket på sessioner och labbar kring IoT och Azure IoT Suite. Windows 10 IoT Core stödjer nu Raspberry PI 3 och det marknaden för tillbehör har verkligen exploderat.

Här är en intressant länk Connected Service for Azure IoT Hub

Docker

Docker för .NET finns som beta, vill man testa får man anmäla sig.

https://beta.docker.com/

Även Bash är på gång till windows.

Microsoft Bot Framework

De har ett gäng intressanta och underhållande APIer för kognitiv dataanalys, ”cognitive microservices”. Man kan läsa av ansiktsuttryck, analysera innehållet i bilder, tolka naturligt språk och mycket annat.

Azure Service Fabric

En molnbaserad distribuerad platform för att hantera microservices.

Azure Service Fabric översikt

DocumentDB

DocumentDB Microsofts Azure-baserade NoSQL databas stödjer numera Apache MongoDB drivers vilket innebär att ni som har MongoDB skills kan köra era verktyg och bibliotek mot DocumentDB.

Destination Mars

Mars

Destination Mars!

Microsoft, JPL och NASA har tagit fram ett event för ett av NASA’s besökscenter.  En 3D upplevelse med Hololens på huvudet och Buzz Aldrin som ledsagare. Vi fick mäta avståndet mellan ögonen, jag vann(?) i min besöksgrupp. Därefter slussades vi in i ett rum där vi fick möjlighet att ta på och justera våra Hololens’s innan upplevelsen startade. Det var första gången jag haft möjlighet att testa Hololens, det var en intressant upplevelse, den ser mycket klumpigare ut än vad den känns när man bär den. Därefter fick vi gå runt på Mars yta. Jag lämnar detaljerna av upplevelsen till era besök på Kennedy Space Center. Det var ett mycket populärt event på konferensen och det var långa köer men det var väl värt väntan tycker jag.

MS Build Hackathon 2016

MS Build Hackathon 2016 gick av stapeln i ett av Microsofts kontor i San Francisco och startade strax efter att den sista föreläsningen på konferensen avslutats.

Jag anslöt mig till ett trevligt gäng från ett konkurrerande bolag när det återstod sex timmar av Hackathonet, jag hade tänkt hjälpa dom med den video som enligt reglerna skulle produceras och publiceras på Youtube inom Hackathonet’s 24 timmar. Tyvärr blev det inte mycket tid till att åstadkomma något vettigt då det blev en mycket stressig avlusning in i det sista. Men det var kul att se hur de organiserat det och vad de olika lagen lyckats åstadkomma. Jag tror att Microsoft filmade en del, så kanske ni kan hitta något om ni letar.

Nu är det dags för en avslutande Margarita.

Publicerad i .NET, DevOps, DOcker, Windows

Kategorier

LinkedIn Auto Publish Powered By : XYZScripts.com