WOW! …what ARE we going to do? How to create a WOW-feeling in two days? That was our mission!

We were six developers who started thinking about the task ahead. Ended up being five implementing it. We tried to meet up for a short while every day to come up with some cool and fun ideas. There was no lack of ideas. We were all agreeing on that we would like do something that had to do with Svenska Spel. One of the ideas was to enhance the experience of revealing the numbers of a Triss-board.

Another idea was to “gamificate” the Svenska Spel website with achievements and badges that one could earn by playing a game, reading a news post or by verifying one’s email address, to name a few.

However, we ended up mixing two of our favorite ideas. One about a labyrinth-game (tilting a board with a marble into holes). The other one to change the Huxflux-feature of Lotto (random shuffle of numbers).  The result of these ideas put together was a kind of pool table with 35 balls and when a ball hit the edge of the screen it exploded until only seven remained.

Day 1

We started by delegating tasks to everyone so that we knew what we would do. It was decided before we started that we were going to use the ThreeJS rendering library and CannonJS physics engine. And for the base framework we used create-react-app which helps you get started with building a React application.

Maria and David started with creating the actual board in HTML/CSS and their goal was to make it look like a regular Lotto board. Anthon was tasked with setting up the base framework. Ragnar experimented with ThreeJS rendering and Johan looked into the physics mechanism of the Lotto balls.

Day 2

The second and last day of the Hackathon we had already laid a good foundation so we made the look and feel better in many ways.

Thanks to Johan we got sounds to work in our application. The last thing we managed to add was an animation to lay out all the balls in a row and sort them from lowest to highest.

Challenges

Device orientation problem

One of the challenges we stumbled upon was the change in orientation of the device so that the balls could roll around on the screen. First, we tried changing the rotation of the actual 3D plane so that the balls would use the gravity to roll down the plane.

However, the problem with this method is that if the user is changing the orientation of the device really fast, the plane could knock the ball out of vision since we worked in 3D space due to changing the planes rotation.

Instead we came up with a method of only changing the gravitation and not the actual plane. This method worked better than the previous one. However, the balls could still roll on top of each other because there was nothing that stopped them, so we added an invisible roof high enough to make the balls able to roll in between the planes.

Sound problem on mobile devices

When we worked on the sound, we noticed that it wasn’t playing on mobile devices, but it worked great on desktop. We learned that this is because mobile devices need user interaction before sound can be played.

Shadows

ThreeJS comes with a lot of features, including lights and shadows. We aimed for having each ball cast a shadow on the bottom plane from a directional light source. Unfortunately, we could not get it to work so we had to give it up.

/Team 6
Ragnar Petterson, Maria Öberg, David Hansson, Johan Sundberg, Anthon Fredriksson

 

Hackathon team two

Planning and startup
Team two was off to a slow start because the team was in disarray due to an unexpected loss and subsequent addition of a new team member. But the addition of Johan added much needed inspiration and the team got of to a late but quick start when the team gathered on Wednesday for a brainstorming. We decided on making some kind of physical interaction with an online gaming experience. Since no-one came up with a really good idea we could unite about we left with a set goal that we should each think about it overnight. A couple of hours later Åman exited the team as abruptly as he entered, but not before he purchased the necessary equipment during the evening.

Purchased hardware
https://www.kjell.com/se/sortiment/el-verktyg/arduino/arduino-kit/arduino-startpaket-p87875
https://www.kjell.com/se/sortiment/el-verktyg/arduino/moduler/avstandsmatare-for-arduino-p87891

Late in the evening Mats built a frame for the range sensors with some leftover pieces of wood from an old sauna.

Day One 
The remnants of the team gathered at Toftagården in the early hours of Thursday september eight in a room called Lilla salen(Small ward). Luckily the room did not live up to its name since it actually was quite spacious. During the first hour of the day we focused on getting the Arduino micro-controller working and setting up the development tools which was easier than expected. Meanwhile we discussed what we should do with the Arduino. We settled on making an physical interaction with the Triss product using distance sensors connected to the Arduino. Mats and Kristofer worked on getting the range sensors working with the Arduino and getting the measured values to the computer via serial communication. Meanwhile Bodil worked on the ability to interact with the scratch-code in the triss from an external data source. Philip and Andreas began writing their own implementation of the Triss as a backup if the original triss code was deemed to complicated to interact with.

Since the sensors did only have a 15 degree measuring angle we could not use the wooden frame since the virtual scratch-area would have been less than a square of 8 by 8 centimeters. So instead we mounted the sensors opposite each other so we could control x-axis and y-axis with a hand on each side of the controller.

Day one evening 

Kristofer got the code working to send data from the Arduino via node.js to a webpage using socket.io He also added a LED to each range sensor so we could visualise the interaction with the range sensor. Bodil got interaction with the triss working and the Philip-Andreas triss was also up and running. There was a serious incident with a beer bottle and the Arduino late in the evening, but luck was with us and disaster was avoided in the last micro-second.

Day two 
Kristofer continued with his audio-visualisation by adding an audio component to the range sensors for improved WOW-effect. Many R2-D2-like sounds were heard in the room while he tweaked the audio with relentless vigour. There were mixed feelings from some other teams and there was actually a WTF exclaimed by a competitor. Bodil worked on getting data from Kristofers socket server with mixed results. The communication was not as stable as we would have liked.

One of the last problems we had was getting values in the correct range for matching the triss scratch-area. The range sensors didn´t seem to be calibrated so first we had to compensate for the differences. The sensors sometimes delivered values that were not realistic so we had to filter those out to. When we got all the values for the original triss, we continued to get it working for the 30, 40, 90, dubbel and mini variations of triss with the possibility for more variations with four lines of code each. In the nick of time we also got the scratch-tool working by some heroic last effort coding by Bodil.

Watch a Demo 
https://youtu.be/waie4wI55Yo

Conclusion
It was quite fun to build something physical and in the end watch the result as a scratching of the Triss online.

/Team 2
Andreas
Mats
Dan
Bodil
Kristofer
Philip

Hackathon - Team Dashboard

We arrive at Tofta early in the morning. The sun is shining and the winds are gusting. Perfect weather for a Hackathon event! We step into our designated team room, close the curtains and for two days the entire room is flickering from the blue lights of our computer screens.

Although our team was decimated from six to four members even before the event started, our vision of what to achieve remained the same. To create something that would be functional and useful right of the bat. Something usable by ourselves, the development teams: A multi-screen solution for our soon to be team rooms.

An outward facing display where the visitors can get information about the team and its members, what the team is working on and maybe even leave as message?
Inside each room one or more displays for relevant statistics, system monitoring, team backlog, Kanban board for morning stand-ups and so on.

Each display is operated through a web based control client accessible from any device such as a mobile or computer. Just scan the QR code in the upper righthand corner and use the interface to toggle between different informational views, or to leave us a message.

The outward facing display can be operated using an adjacent 7 inch touch screen powered by a Raspberry Pi. The touch screen runs the same web based control interface mentioned above. A motion sensor detects when anyone is close to the display and sends a Wake command, lighting up the 7 inch control panel.

To "geek things up" even more we added LED-stripes for indicating Welcome/Do not disturb status for visitors and notifying the team of new messages. Any new messages is automatically read up by the inside monitor using the Web Speech Synthesis API. In Swedish of course ;)

Summing upp Hackathon 2017 for our team; Good food, lots of fun. 

Oh, and one more thing..
When the dust settled and the votes were counted, we were proclaimed the winning team!

/Team 5
Reine "10pm refactor master", Mats "the drone pilot", Jimmie "the pixel pusher" and Kotte "the mascot".

hackaton team1

Having in mind the ‘WOW’ criteria for this year’s hackathon we immediately went for AR as our main technology. On the few brainstorm meetings we decided to work with the TRISS product and improve the users experience by adding more excitement, involvement and eventually engage the user (who bought a physical ticket) in an online experience.

The idea is pretty simple. After you scratch your physical Triss ticket, you’ll be able to scan a QR-code with an URL that launches the AR-experience. The AR-experience offers an extra chance to win something. Through you mobile or tablet will see a 3D box floating above the TRISS ticket and inside the box is the price. Very exciting, right!

Day 1

We start the day by breaking down the idea to smaller tasks. Setting up environment and start to play with some AR frameworks. A big challenge that takes up a lot of our time is trying to create a custom marker (trigger for the AR experience) for the Triss ticket. There’s a lot of try and error here. We are using three.js which is a 3D library to create the experience. We are starting to build the Svenska Spel logo in 3D. The idea is that it should pop up from the box. We are also adding listeners that listen for a click to launch sequences in the animation so that the box opens when clicking on it.

Day 2

The work with 3D animations continues. Spending a lot of time to get textures on the models. We are realising that we don’t have enough time to get the animation of the logo in place. Quick solution is to put the price on the bottom of the box. By tilting the phone, you are able to see the price you have won.

Conclusion

We’re all feeling a little disappointed that we didn’t manage to do a better and more amazing winning animation but are all satisfied that we managed to get it fully functional for the demo.

We had a lot of fun, experimenting with new frameworks, techniques and just hanging out together as a team.

Team 1: Sandra K, Magnus K, Timmy Y, Tony N, Håkan F, Johan M

parkify

Late to work and all stressed up? Rest assured with "Parkify" you would not need to spend your time finding a free parking lot, the web-based app will notify you of where there are free spaces and leave you focused on the driving.

The idea sprung out of a actual need we have at Svenska Spel, the amount of employees have steadily been growing over the last years but the parking lots have not. Around 09:00 all spaces could be occupied, especially on rainy days and during winter. An application signaling where the free spaces are located, if any, could relieve stress and rush traffic during the mornings, an ecological aspect with reduced pollution also comes to mind. As an additional feature, is case all parking lots are occupied and you had to park elsewhere, there is the possibility to get a notification message sent to your mobile phone when a free parking lot becomes available.

The teams approach to solve the problem at hand was to rely on cameras mounted on the rooftop of the building, giving a "bird's-eye view" of the parking lots and the cars. The de facto standard library for image recognition and processing, OpenCV, was used and trained to recognize cars on our parking lot. A Node.js application was then developed that interfaced with OpenCV and analyzing the pictures taken by the camera, all detected cars were then matched with a grid representing the parking lots. The Node.js application also serves a web-based app visualizing the interpreted picture from the cameras and the status of each parking lot, text-to-speech is built into the web app and aids the user with a verbal indication of the number of free lots.

We got everything up and running, except the notification feature which requires a SSL certificate to work. All in all we had a fun time writing this application and for the chance of learning something new.

Team 3: Jonas K, Vladimir K, Henrik Ö, Emil Ö, Issac P, Josip U

After two planning meetings before the hackathon we had September 7-8, we decided to build a web based correcting experience, in AR (Augmented Reality), for our customers who are betting at Lotto at our agents.

To be able to make a correcting experience from a Lotto receipt, we need to scan the receipt’s barcode and have some sort of marker attached to the receipt for our AR animation.
 
We decided to use quaggaJS as our scanning engine, AR.js with A-FRAME for our AR-experience and jQuery, Node.js and Express.js as base.
 
No one in our team had any experience with AR on the web so the learning curve was quite steep in the beginning to make the AR experience fit our needs. On a Hackathon, the implementation does not need to be perfect, so some creative programming is allowed and was used.
 
At Thursday evening, the scanning software was working as expected and AR-animation started to fit our needs. The Friday work was to optimize the complete experience, from scanning the receipt to the big final with the jackpot experience.
 
To summarize, we are quite happy with our results during the two days and with the WOW-factor we created. The solution is generic and could be used with lots of our games.
The technic we were using is getting mature and it is an enabler to make awesome AR-experience on the web.
 
Team
Allan
Daniel
Kenth
Marcus
Mathias

mingel på Nordic.js 2016

För tredje året i rad så hölls JavaScript-konferensen Nordic.js i Stockholm den 8-9 September. Denna gång hölls konferensen på Münchenbryggeriet och några av oss på Svenska Spel var givetvis på plats

Årets tema var Wingdings (eller var det katter?) vilket tydligt kunde ses på bl.a. hemsidan,  planscher, och i presentationer, mm. Eventet i sin helhet var välorganiserat och konferenciern Lydia Winters, brand director på Mojang, gjorde ett mycket bra jobb. Alla föredrag strömmades via Viaplay och finns även tillgängliga på YouTube.

Några höjdpunkter som vi tog med oss från konferensen:

Jeremy Keith (Clearleft) - "Resilience: Tried and tested approaches to building robust, flexible, and resilient web experiences."

Jeremy talade om att istället för att gnälla över begränsningar i äldre webbläsare så kan man bygga grundläggande funktionalitet och lägga till features för modernare webbläsare. Att lösa sådant med hjälp av Javascript är alltid riskabelt. Rätt sätt är att utnyttja att HTML och CSS är konstruerade för att vara bakåtkompatibla.

Frans Rosén (Detectify) - "The Smörgåsbord of Web App Hacking"

Frans talade om bug bounties, dvs när företag erbjuder kodare och hackare en belöning för att hitta svagheter i deras tjänster. Det bjöds på härliga historier om svindlande säkerhetshål i välkända tjänster samt dekadenta hackerhelger i Las Vegas där både kod och bubbel flödade.

Ashley Williams (NPM) - "A brief history and mishistory of modularity"

Ashley jobbar på NPM och hjälper utvecklare med frågor som bland annat berör paketering och distribution av moduler till Node.js. Under detta föredrag fokuserade hon kring frågorna, Vad är en modul? Hur stor eller liten bör en modul vara? Vem tjänar på stora/små moduler? Olika fördelar och nackdelar ventileras och varvas med både historia och filosofi, klart värd att se för oss Node.js utvecklare.

Evan You (Vue.js) - "Demystifying Frontend Framework Performance"

Som är grundaren av Vue.js pratade om benchmarking av frontend-ramverk och att det inte alltid är det enklaste. Utan man måste själv prototypa sig fram och bilda sig en egen uppfattning.

Vitaly Friedman (Smashing Magazine) - "Cutting-Edge Responsive Web Design"

Vitalys talk handlade om några små (men användbara!) knep för att bl.a. designa responsiva email, eller hur man på ett smidigt sätt kan skala en fontstorleken utan media-queries!

Lin Clark (Mozilla) - "A Cartoon Guide to Performance in React"

Lin driver hemsidan Code-Cartoons som med enkla streckgubbar illustrerar och förklarar olika ämnen som kan förbrylla den moderna webbutvecklaren. Försöker du ännu förstå hur Redux eller Facebook Flux fungerar? Besök hennes hemsida och se ovanstående Youtube-klipp!

Mattias Petter Johansson (Spotify) - "If you know map, I will teach you monads"

Mattias ledde oss genom functors, map och flatMap mot målet att förklara vad monads är för någonting. På vägen dit fick han även med hur elegant funktionell programmering kan vara,  när man i koden berättar vad man vill göra, inte hur man skall göra det.

Jem Young (Netflix) - "Embracing The Future"

Konferensens sista speaker (och kanske även en av dom bästa). Några av oss missade honom tyvärr då vi var tvungna att åka till Bromma för att ta flyget tillbaka till Visby. Jem höll i alla fall ett riktigt bra talk om JavaScripts framtid och hur man redan idag kan använda den nya tekniken för att bygga grymma applikationer.

David Björklund (Mic.com) - "Pragmatic performance patterns"

Ögonöppnande och mycket användbart. David berättade om sitt arbetsflöde med benchmarking och varför han vill få in det så tidigt i processen som möjligt. Du kan aldrig veta säkert vad som blir resurs tungt i din kod. ”Prepare to be surprised”.

 

/Henrik Östman, Daniel Färnbo, Mats Karlsson, Mathias Sandberg, Pim Lindahl
Systemutvecklare

Svenska Spels styleguide

Svenska Spels styleguide hjälper oss att utveckla snabbare och få en mer enhetlig design över flera olika plattformar.

På vår tidigare sajt hade vi inget bra sätt att dela design och klientkod mellan olika sidor och tjänster. Vilket ledde till att för varje ny tjänst som utvecklades så togs det fram ny design och utvecklarna fick bygga allt från grunden varje gång och la mycket tid på att tolka och översätta design till kod. En annan nackdel var också att sajten fick en väldigt inkonsekvent design och kunde skilja sig mycket från sida till sida.

Nya plattformen

När vi skulle ta fram vår nya tekniska plattform ville vi att det skulle vara enkelt att återanvända funktionalitet och design tvärs över hela sajten. För att det skall vara görbart är det viktigt att det finns en tydlig dokumentation om vilka funktioner som finns tillgängliga, hur de ser ut och fungerar.

Vår lösning blev att ta fram en styleguide där vi kan samla alla återanvändbara komponenter samt dokumentation om hur, när och var de skall användas.
Där hittar man t.ex. knappar, logotyper, ikoner, färger, modaler, menyer och många andra komponenter som vi använder över hela sajten.
Alla komponenter och även färger, ikoner mm har fått egna namn så alla roller i teamen pratar om samma saker för att minimera missförstånd. Istället för att hela tiden kolla i Photoshop vilken färg det skall vara kan vi enkelt berätta att det skall vara färgen stryktipset-500 eller grey-400 så blir det automatiskt rätt färg.

Det är lätt att dokumentation snabbt blir inaktuell om den inte hålls uppdaterad. Därför har vi valt att dokumentation är en del av varje komponent så kod och dokumentation är samlat på samma ställe. Sedan sammanställer vi alla komponenters dokumentation som tillsammans bildar vår styleguide. Eftersom dokumentationen är en del av plattformen så kan komponenterna köras live i styleguiden precis som på sajten. På så sätt går det alltid att se exakt hur en komponent ser ut och fungerar från styleguiden vilket vi har upplevt som en stor fördel när vi utvecklar nya och gör justeringar i komponenter.

I styleguiden går det också att ladda ner alla logotyper, typsnitt, ikoner och övriga spritemaps så dom enkelt kan användas på andra plattformar såsom iOS och Android.

Just nu är vår styleguide endast tillgänglig internt men målet är att öppna upp den publikt så våra partners som utvecklar sidor åt oss också kan ta del av alla våra komponenter och designriktlinjer.

/Emil Öhman
Systemutvecklare

Visby Web Lab #2 2016

Onsdagen den 20:e april anordnades årets andra träff med Visby Web Lab. Denna gång i samarbete med oss på Svenska Spel. 

För ett femtiotal deltagare berättade jag om vår resa från en teknologiskt och upplevelsemässigt föråldrad tjänst, till en modern responsiv tjänst baserad på öppna teknologier.
Emil Öhman följde upp med en djupdykning i den "Styleguide" som skapades under projektet och hur den används i det dagliga arbetet, både av utvecklare och UX/designers.
Max Thourise avslutade med att berätta om sin stora passion, Clojure, och fördelarna med funktionella språk. Han kryddade teorin genom att demonstrera ett spel byggt med ClojureScript

Vår teknologiska resa

Jag började med att berätta om vår tidigare spelsajt baserad på föråldrade teknologier såsom Flash, vilket hindrade oss från att erbjuda samma tjänst för våra mobila användare. Med separat mobiltjänst och föråldrad teknik var det dags att göra om allt från grunden, på en modern plattform. En plattform som tillät en enhetlig tjänst, med fokus på spelupplevelsen, i realtid.

Sagt och gjort. 2012 påbörjades resan och i maj 2014 lanserade vi första versionen av vår nya responsiva spelsajt för mobila enheter. Nya sajten består av flertalet separata webb-appar, helt skrivna i javascript på ett egenutvecklat ramverk för Node.js/Express. På klientsidan används HTML5/CSS3, jQueryBackbone.js med mera. Nyutvecklade REST-API'er med stöd för push via WebSockets används både på servern och i klienten. I februari i år sjösatte vi äntligen de sista delarna och ersatte i och med detta den gamla Flash-baserade sajten för "desktop". 

Parallellt med ny sajt och teknologistack förändrade vi även arbetssättet radikalt. Med hjälp av GitFlow, testautomatisering, nya CI-verktyg och DevOps-satsningar har vi gått från månadsreleaser till löpande kodleverans med lansering mot kund flera gånger i veckan.

Enligt mig är tre av de största tekniska framstegen på webbdelarna i denna omfattande IT-satsning det vi valt att kalla "Device detection", "Feature toggles" samt "Styleguide". 

Device detection används när traditionell responsiv design inte räcker för att anpassa tjänsten för mobil, tablet samt desktop. Vi kan leverera alternativ kod och design till respektive enhetstyp. Det ger också fördelen att hålla ner mängden data som behöver laddas ner, och bearbetas, av respektive klient. I de flesta fall hanteras desktop-datorer och tablets likadant, medans mobiler kräver avvikande hantering. 

Feature toggles används för att löpande leverera delvis utvecklade tjänster och för att undvika beroende mellan kodleverans och lansering mot kund. Utvecklingsteamen använder toggles för att hantera alternativa kodflöden, stilmallar, vyer och tesfall.
När något ska utvecklas som tar längre tid än en iteration, och/eller ska lanseras vid ett senare tillfälle, definieras en ny toggle av teamet. Under utvecklingen skapas även automatiserade tester för att verifiera tjänsten med toggles både "på" och "av". Ansvariga för kundmötet kan sedan välja hur och när levererade tjänster ska lanseras mot kund. När den utvecklade funktionen är lanserad, plockas toggeln samt inaktuell kod och tester bort av teamet. 

Svenska Spels Styleguide höll Emil Öhman en separat dragning om. Hur den används av UX/Designers för att designa en enhetlig tjänst, av utvecklare för att bygga tjänsten, samt som gemensam dokumentation. Emil kommer förhoppningsvis att berätta mer om detta i ett kommande inlägg :)

/Reine Olofsson
Systemarkitekt Webb

Om Tech

Tech-bloggen har vi satt upp för att visa vad vi gör på teknik-sidan inom Svenska Spel. Du kommer att kunna läsa inlägg skrivna av oss som brinner för utveckling, arkitektur och DevOps.  

Mer om bloggen och oss som skriver

Senaste inläggen