# Finn.no Posts from the people building the world's greatest marketplace This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Haskell at FINN.no DevFeed: [Haskell at FINN.no]() Original publisher: [Read original article]() Author: Sjur Millidahl Published: 2018-10-18T09:00:00Z Content type: opinion Language: en Sources: [Finn.no]() Topics: [Haskell](), [Front end](), [API](), [Back end](), [Compiler](), [Docker]() Tags: [api](), [backend](), [blog-post](), [compiler](), [docker](), [functional](), [haskell]() ### AI overview This blog post describes FINN.no's redesign of the backend API for its favorites feature using Haskell. It discusses Haskell's type system, Servant, Aeson, Hasql, Stack, compiler-assisted API refactoring, testing, and Docker deployment. The article also notes the need to train developers in Haskell. ### Source excerpt Favorites FINN has this feature where users can mark classified ads as a favorite, making it easy to come back to certain ads later. The feature has been around quite a while, and the systems involved, both frontend and backend were becoming quite hard to maintain. So the AdView-team set out to redesign the whole stack. This blog post will focus on the backend API, which is written in Haskell. Haskell Haskell is a purely functional programming language, with a powerful type system. The ability to express intent using types brings correctness, and the composition of a large program as small, independent building blocks makes it easy to reason about the code. A large ecosystem of production grade libraries are available from Hackage. We make use of Servant (API), Aeson (JSON), Hasql (postgres) and many more. Servant is a type-level API, meaning the "sum" of all our endpoints become a distinct type. This, in turn, means that refactoring our API gives us heavy compiler assistance. More than once during development, we had the need to do major changes in the endpoints (verbs, paths, request body, responses) and found that once every compilation error was resolved, the new API was working correctly. To manage external packages, build and test code, we use Stack, because of its familiarity to maven, gradle and sbt-users. stack build will compile the project, stack test run all the tests. Stack pulls down Glasgow Haskell Compiler ("GHC") along with required libraries. It also supports building and running of the final program in Docker. Now Docker is important, because of the cloud infrastructure in FINN; any technology running in Docker can be used as a new Micro Service. Experiences So what are the downsides to using Haskell? Well - there is really only one. We have to have a certain amount of developers, at least in our team, know Haskell. We meet this challenge in three ways. Firstly by doing a Haskell course internally at FINN. 21 of our developers have signed up for a ## Preparing your product for machine learning DevFeed: [Preparing your product for machine learning]() Original publisher: [Read original article]() Author: Joakim Rishaug Published: 2018-08-09T08:00:00Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Machine Learning & Artificial Intelligence](), [data](), [datasets](), [Google](), [Kaggle]() Tags: [data](), [introduction](), [kaggle](), [machine-learning]() ### AI overview This article explains how engineering teams can prepare products for future machine learning work, even when data scientists are not yet available. It emphasizes engineering fundamentals, useful features, numerical data, and reducing problems caused by unstructured or incomplete data. ### Source excerpt At many companies, there are few data scientists and many projects which may be very interesting for the business to apply machine learning on. For most of these companies, starting greenfield projects with a data scientist on the team might be either a difficult political battle (to get assigned resources) or impossible, if there are no data scientists yet. But how can a team prepare their project for the day when there will be a data scientist around, and in the process, maybe improve their current product as well? In Google's "Rules of ML", they make some good suggestions for this in their introduction: Do machine learning like the great engineer you are, not the great machine learning expert you aren't. Most of the problems you will face, are in fact engineering problems. Most of the gains come from great features, not great machine learning algorithms. This means, the team already has great potential to improve their product in ways that the data scientist might help them do in a more structured way later. I believe as long as the engineers and programmers know how machine learning algorithms like having the data shaped, they can take advantage of this to move forward confidently. What kind of data does a machine learning algorithm like? Computers like things that are quantifiable by numbers, and this is probably obvious to many programmers, but it's easy to forget this when we have tools like Google that can find and seemingly understand what we want just by typing a couple of words. According to a Kaggle survey from 2017, "dirty data" is the biggest problem faced by machine learning practitioners. This means data being unstructured in some form, either by being severely skewed in one direction or the other, being full of holes (only subsets of users even have a given feature), or data that has to go through processing before actually becoming a usable feature. Making sure that this friction is minimized is important later for the progress of machine learning ## Personalized search with a custom Solr plugin DevFeed: [Personalized search with a custom Solr plugin]() Original publisher: [Read original article]() Author: Henrik Falch Published: 2018-04-10T06:00:00Z Content type: article Language: en Sources: [Finn.no]() Topics: [personalization](), [recommendations](), [API](), [Back end](), [Query (disambiguation)]() Tags: [api](), [backend](), [personalization](), [plugin](), [query](), [recommendation-system]() ### AI overview This article describes FINN.no's work to improve classified-ad search relevance by combining Solr scores with recommendation scores. It discusses testing a custom Solr plugin that uses an existing recommendations API and lists requirements for personalization, algorithm changes, and score balancing. ### Source excerpt Background On FINN.no people can search for classified ads, where the backend system is using Solr as the search engine. Default sorting on the vertical "torget" is by relevancy, which is based on Solr score. The Solr score for a document is again calculated from query relevance and the ad's published date. Here is an example searching for the word chair: Non-personalized search The first and third ad are bought positions, while the rest are sorted by published time and the importance of the word chair (Norwegian: stol). In the fall of 2017, we started experimenting with ways to improve the relevancy sorting. Our first try was by boosting geo distance, ads close to my position would get a higher score. But we could not see any positive changes for our product KPIs. Then we wanted to try sort by mixing scores from both Solr and our recommendation system. Our recommendation system already had an api where we could send a user id and a list of ad ids, and receive a recommendation score for each of the ads. A new solution We evaluated a few different solutions, mainly: learning to rank in Solr custom Solr plugin using the existing recommendations api Since we already had a system for recommendations, and awesome data scientists tuning the algorithms and so on, we chose to test the latter. An uncertainty was if we could get the response times needed for a search. Solr SearchComponent A Solr search component contains several phases used by the search handler. As we do not use sharded indices for the search we wanted to test, these are the important phases: prepare - Preparing the response -> parsing request parameters process - Processing the request for the current component Requirements the personalization score should influence the order of the search result we want to easily be able to change recommendation algorithm, and test a new one against the current search (with or without personalization) we also wanted to tune Solr score/recommendation score balance We theref ## Åpen fagkveld hjemme hos FINN DevFeed: [Åpen fagkveld hjemme hos FINN]() Original publisher: [Read original article]() Author: Gunn Skinderviken Published: 2018-02-06T14:14:30Z Content type: news Language: no Sources: [Finn.no]() Topics: [Front end](), [Testing](), [data]() Tags: [data](), [frontend](), [testing]() ### AI overview FINN announces open technology evenings in Oslo for students and experienced technology professionals. The program covers product development, GDPR, uptime, recruitment, accessibility, A/B testing with Unleash, and frontend architecture across microservices and teams. ### Source excerpt Tradisjonen tro åpner vi også i år dørene hjemme hos oss i Grensen for å dele våre erfaringer rundt hvordan vi jobber med produktutvikling. Teknologi er i fokus, og vi gleder oss til å vise dere hvordan vi bygger - og holder et av Norges mest besøkte nettsteder vedlike. En kveld er dedikert studenter, og en de mer erfarne. Presentasjoner Velkommen GDPR Oppetid Sosial rekruttering Unleash Universell utforming Dette ser vi etter når vi ansetter utviklere Podium Åpen fagkveld 28. februar kl 16-20 (for de som jobber med teknologi) Program 16:00 Velkommen til FINN ved Nicolai Høge (CTO) 16:30 Mat og drikke 17:00 Sosial rekruttering Hvordan vi tok i bruk våre egne data for å lage FINN Jobbmatch. 17:30 GDPR Samtykke - Hvorfor må vi ha det og hvordan håndterer FINN det i en mikroservices-verden? 17:30 Unleash Verktøy/rammeverk for A/B testing. 18:00 Oppetid Hvordan arbeider vi for høy oppetid i FINN. Ambisjoner, målinger og oppfølgning. 18:00 Podium Frontend i en mikroservices-verden. Hvordan FINN bygger en unison frontend på kryss av microservicer og team med forskjellige eierskap. Åpen studentkveld 7. mars kl 16-20 (for studenter) Program (endringer kan komme) 16:00 Velkommen til FINN ved Nicolai Høge (CTO) 16:30 Mat og drikke 17:00 Dette ser vi etter når vi ansetter utviklere 17:30 Sosial rekruttering Hvordan vi tok i bruk våre egne data for å lage FINN Jobbmatch 17:30 Universell utforming - hvorfor og hvordan man skal lage noe som funker for alle. Absolutt ALLE! 18:00 Unleash Verktøy/rammeverk for A/B testing 18:00 Podium Frontend i en mikroservices-verden. Hvordan FINN bygger en unison frontend på kryss av microservicer og team med forskjellige eierskap. Takk til alle dere som kom. Karrieresiden vår inneholder mer info om oss. ## Browser statistics December 2017 DevFeed: [Browser statistics December 2017]() Original publisher: [Read original article]() Author: Henning Spjelkavik Published: 2017-12-13T10:02:32Z Content type: article Language: en Sources: [Finn.no]() Topics: [browser](), [Mobile](), [App](), [iOS](), [Web app](), [Windows](), [Operating system](), [web applications]() Tags: [android](), [app](), [browser](), [browsers](), [debug](), [ios](), [iphone](), [mobile](), [native](), [operating-systems](), [web](), [web-app](), [windows]() ### AI overview This article presents FINN.no's browser, device, operating-system, and app usage statistics for December 2017. It reports that smartphones and tablets accounted for 72% of visits, desktops and laptops for 28%, and that native apps became the majority choice among mobile users. ### Source excerpt Browser statistics, December 2017 at FINN.no# Yuletide is coming real soon now, and we haven't published browser statistics for 2017 yet! The 2016 edition is here if you want to compare. How many visitors use a desktop or laptop? The trend continues, a higher percentage of the traffic is coming from a mobile terminal this year than in 2016, but the trend is that the growth of the curve seems to flatten. Our first graph shows the share of our users using a mobile phone, tablet or a desktop computer to access FINN.no, regardless of whether they use our responsive web app (m.finn.no), or a native Android or iPhone app. 72% of our visits are now from a smartphone or a tablet. The traditional desktop/laptop has a market share of 28%. Which offering/"app" of FINN are people using, regardless of whether the device is a desktop/laptop, mobile or tablet? Given that a user is on a mobile or a tablet - are they using the web-version or the app? For the first time the majority of those accessing FINN from a mobile device use our native app - the www.finn.no share of the visits is down to 48%. These graphs also shows that we changed the domain name again this spring, so that all web traffic is served from www.finn.no, and not m.finn.no any more. Browsers and devices The browser war is now only a memory of the veterans, but we still have to debug bugs in specific browsers from time to time, and it's useful to have an idea of which browsers could or should be ignored. Let's also look at the which devices are the most popular: Operating systems We're not using our mobiles all the time, so lte's take a look at the operating system versions. The changes here go quite slowly, but the longer trend is that Windows 10 is still increasing over Windows 7 and 8. Distribution of iOS versions - it's interesting to see how quickly a new version is rolled out and dominating. (Note that iOS 11 did not fit into this graph, but the last week, iOS 11.1.2 was the biggest.) ...especially compared to An ## FINN wins Universal Design Award DevFeed: [FINN wins Universal Design Award]() Original publisher: [Read original article]() Author: Lotte Johansen Published: 2017-10-30T11:19:07Z Content type: article Language: en Sources: [Finn.no]() Topics: [Accessibility](), [User interface design](), [Mobile](), [Web]() Tags: [accessibility](), [icons](), [images](), [interaction-design](), [mobile](), [screen](), [web]() ### AI overview FINN.no received the DOGA Innovation Award for Universal Design in the Interaction Design and Digital Solutions category. The article describes the accessibility work behind its web solution and mobile app, including user testing, intuitive design, and adaptations for screen readers. ### Source excerpt Family and Equality Minister Solveig Horne handed out the award to FINN employees from the Accessibility Team, Product, Innovation and Technology. From left: Maiken Solberg Olsen, Solveig Horne, Lotte Johansen, Tor-Martin Storsletten, Karina Birkeland Lome, Ingrid Vestby Fredriksen, David Håsäther, Nicolai Høge and John Arne Bjerknes (Jury leader). By removing obstacles and involving users, FINN.no has created a service that allows everyone to participate in important social functions. On October 17th we received the DOGA Innovation Award for Universal Design in the Interaction Design and Digital Solutions category. Developers and designers run the grassroots work with accessibility at FINN.no. It started in 2014 when a new accessibility legislation was introduced in Norway. Since then the grassroots group has worked to make accessibility known to everyone who develops FINN.no. Sometimes the work gets hard, and it is extra encouraging to receive such an award. It helps us to show how important it is that we make our services available to everyone. FINN.no has received the award for its web solution and corresponding mobile app. House and Work for Everyone It is a major responsibility being the country's largest digital marketplace. If you do not have access to, for example, the job or real estate market on FINN.no, your opportunities are limited to participate in the community. FINN.no is used by virtually everyone in Norway. Therefore, it is important that people can find a house to live in, a job to go to, trips, or other items they may need, regardless of any disabilities. Through user tests we have learned that where people with disabilities are struggling, others also tend to struggle. By removing obstacles, the solutions become better for everyone. Images and icons are widely used in our online solution. Designs and texts are made to be as intuitive as possible, among other things by using self-completing text. The FINN.no app is adapted for use by screen read ## Akka workshop at Finn.no DevFeed: [Akka workshop at Finn.no]() Original publisher: [Read original article]() Author: Sjur Millidahl Published: 2017-10-17T06:56:49Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Concurrency](), [async](), [distributed-systems](), [Scalability](), [systems]() Tags: [apache-kafka](), [async](), [asynchronous](), [comes](), [concurrency](), [distributed-systems](), [java](), [kafka](), [kotlin](), [scalability](), [workshop]() ### AI overview The article recaps an Akka workshop at FINN.no and explains the Actor Model, in which actors communicate asynchronously through messages. It describes sequential message processing, state, supervision, scalability, reliability, and hands-on exercises with Java and Kotlin branches. ### Source excerpt Akka workshoppers hard at work! In FINN.no we have experience in running distributed systems, and we often rely on asynchronous communication between our applications. Apache Kafka is the work-horse on the house, and it's doing an excellent job for us. But this doesn't mean that we shouldn't learn new things - or look at other solutions. Akka is an implementation of the Actor Model - a concept of concurrent processing first published in 1973. The Actor Model is all about two ideas: Actors and Messages. Actors sending messages A number of Actors communicate to each other using messages. An Actor will process its received messages sequentially, and send messages to other actors asynchronously. It can also keep state, perform side-effects and supervise other actors. This small hand-full of operations makes the Actor Model easy to reason about and within one Actor we need not worry about the complexity of concurrency - one message is processed after another. The power of the Actor Model comes from combining (often specialized) Actors in a supervised hierarchy. Concurrency and scalability comes naturally as the sending of messages between them are asynchronous. Reliability and uptime comes from a let-it-crash philosophy and supervision done through special Supervisor-Actors. Arild wrapping heads around the async monad! The workshop was a hands-on with a few slides between the exercises. You can do the tasks yourself by cloning and checking out the master-branch (for java) or the kotlin-branch. Slides Resources ## Deep NLP-based Recommenders at Finn.no DevFeed: [Deep NLP-based Recommenders at Finn.no]() Original publisher: [Read original article]() Author: Simen Eide Published: 2017-09-08T13:56:49Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Natural language processing](), [Deep learning](), [Embeddings](), [recommendations](), [Keras](), [Hackathon]() Tags: [data](), [deep-learning](), [embeddings](), [hackathon](), [keras](), [model-architecture](), [neural-networks](), [nlp](), [recommendations]() ### AI overview The article describes a FINN.no hackathon project exploring deep NLP-based recommendations for classified ads. The team used categorized ad data, word embeddings, and a convolutional neural network architecture to model similarity, but the supplied text does not include the final performance results. ### Source excerpt During a hackathon at FINN.no, we figured we wanted to learn more about deep NLP-models. FINN.no has a large database with ads of people trying to sell stuff (around 1 million active ads at any time), and they are categorized into a category tree with three or four layers. For example, full suspension bikes can be found under "Sport and outdoor activities" / "Bike sport" / "Full suspension bikes". In our daily jobs we are working on recommendations. There, we already have a content based (tf-idf) recommender build on Solr's More Like This. It seems to work well in areas where our collaborative filtering approaches does not. Would it be possible to build a deep learning NLP-model of similar performance? To achieve a measure of similarity, building a classifier of the previously mentioned categories seemed like a good choice, since we already had a lot of pre-existing data. The NLP team at Schibsted had already tokenized around six million ads as well as trained a word2vec model for us - we were ready to roll! Some preprocessing still had to be done. We ran through all ads, concatenated the title and description strings, and after a quick look at the data took the first 15 words of each ad. Model architecture proposed by the paper Our initial experiments were done with a simple "Bag of words" model included in the Keras repository, but we promptly switched over to "Convolutional Neural Networks for Sentence Classification" based architecture after hearing about it from our colleague, Tobias. By looking at the first 15 words of the ad, and using 200 dimensional embeddings for each word, our input is transformed into a 15x200 matrix. We apply three different convolutions on each document. The three convolutions looks at 2, 3 and 4 words (kernel sizes) in each convolution. It then max-pools each over the whole document, so that you end up with one value per document per convolution. For each kernel size you do 100 different filters. Finally you add a dense layer for clas ## The summer interns of 2017 DevFeed: [The summer interns of 2017]() Original publisher: [Read original article]() Author: Alfred Birketvedt Published: 2017-08-08T10:56:49Z Content type: article Language: en Sources: [Finn.no]() Topics: [User Experience](), [systems]() Tags: [2017](), [designer](), [improvements](), [internship](), [norway](), [project](), [user-experience]() ### AI overview Five summer interns at FINN.no worked on improving the user experience for advertisers on FINN Torget and reducing ads that received no contact. Their 2017 internship project developed concepts including Tilbakemelding, a way for potential buyers to suggest improvements to ads. ### Source excerpt The starting point In a galaxy very very close by, there were 5 brave summer interns working for FINN.no. They came from the far north (NTNU) and the far south (UiO) of the cold and rainy plains of Norway. 4 of them were taught in the arts of the computer, and one in the teachings of the design. They had a mission: to improve the current user experience for advertisers on FINN Torget, and to decrease the amount of zero-contact ads. A tough mission, but our heroes have valiantly fought during the summer of 2017 to resolve this quest. During the first week of the summer internship we (the interns) were introduced to FINN.no, its systems and our coaches for the summer project; Martin, the brilliant programmer and Ingrid, the amazing designer. In order to ensure everyone on the team were on the same page a brainstorming session was held. During this session possible solutions for the summer project were developed, and our mutual ambition for this project was put into words. Our ambition has been to: "Increase the amount of ads receiving feedback/being sold on FINN.no" and "Help advertisers on FINN.no make better ads". In the past 2 months two concepts have been realized, with quite surprising results and developments. But you have to read the rest of the document to know exactly what surprising developments took place :) Sorry, that's just life bro/hon! Project 1: Tilbakemelding (Feedback) Have you ever created an ad and received no feedback, no likes and no messages? This is the reality of approximately 50 % of all ads published on FINN Torget in Norway. Imagine if there was a way for advertisers to know exactly how they could improve their ads, what would it look like? "Tilbakemelding" is one possibility. Tilbakemelding is a button located at the front page of an ad for all potential buyers to see and use. If a user does not like an ad, and feels that sending a message is too much of a hassle, they can push this button. By doing so, a set of possible improvements to t ## From Hadoop and Cassandra to Kafka Streams DevFeed: [From Hadoop and Cassandra to Kafka Streams]() Original publisher: [Read original article]() Author: Nicolas Yann Couturier Published: 2017-07-31T12:00:00Z Content type: article Language: en Sources: [Finn.no]() Topics: [Kafka](), [Apache Cassandra](), [Hadoop]() Tags: [cassandra](), [hadoop](), [kafka]() ### AI overview The article describes FINN.no's existing pipeline for computing classified-ad statistics from user actions published to Apache Kafka, stored in Cassandra, and processed in batches by Hadoop. It introduces the need to join these events with demographic data to provide more detailed viewer statistics. ### Source excerpt Some context People who publish their classified ads on FINN.no get access to various statistics to see how their ads are performing. For a user it can look something like this: Statistics the owner of a realestate ad gets to see The top left bar chart shows the repartition of the incoming traffic by day and the legend to the right of it shows the total numbers for each type of incoming traffic. The lower section is divided in 3 parts: the left part shows the number of views by unique users; the one to the center shows how many users have been notified of the ad by email and how many added the ad to their favorites; the right part shows how many viewers out of the total come from a specific type of traffic. This gives the user basic insight into the reach of their ad, such as how many views it has and how many unique users have viewed it. Around November 2016 there was a request to show more detailed information about the viewers, such as the age, gender and location distribution of the viewers (demographic information) so the owner could potentially change an ad to better fit the audience they wanted. Existing solution As users view ads, do actions (such as send a message to an ad's owner or scroll down and read the whole page, for example), these actions are gathered and published internally on Apache Kafka. These streams of data then become the basis for computing the statistics above. The plan was then to also publish demographic data about the viewers (such as location, age and gender) on Kafka and join the user actions with this demographic data to provide enhanced statistics. At the time, the action events published on Kafka were saved to Cassandra Apache Cassandra clusters, and statistics were being computed as batches on an aging Apache Hadoop cluster reading from Cassandra. Both our Hadoop and Cassandra clusters had not receive much love recently and were all on end-of-life versions. The old system also had an increasing tendency to fail, so we were also i ## How FINN Built a Motion-Controlled Flappy Cat Game DevFeed: [How FINN Built a Motion-Controlled Flappy Cat Game]() Original publisher: [Read original article]() Author: Pernille Celia Sethre, Gunn Skinderviken Published: 2017-07-19T16:58:36Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Phaser](), [Game Development](), [JavaScript](), [Node.js](), [SDKs]() Tags: [game](), [game-development](), [javascript](), [node-js](), [sdk]() ### AI overview FINN's search team describes building Flappy Cat, a motion-controlled Flappy Bird-style game for its JavaZone stand. The project used Phaser for the JavaScript/HTML5 game, Kinect gesture recognition, and a Node.js server endpoint that triggers a flap. ### Source excerpt Why make a Flappy Cat game? The Idea was to make a Flappy Bird with motion tracking control for our JavaZone stand. Some quick research told us it should be possible. Since cats are assosiated with FINN, it of course became a Flappy Cat game. Come and try it at JavaZone in September. Made by search team. How we made it Step 1: Make the game. As neither of us are game developers, we found this flappy bird tutorial online that we decided to follow. This tutorial uses Phaser, an open source JavaScript/HTML5 game development framework. It was easy to follow and it explained all the steps in detail, so even the most back-end heavy developer in our team had no problem writing his first JavaScript game. Step 2: Buy the motion tracker. We chose Kinect as we found videos on YouTube of people doing exactly what we wanted to do with the Kinect sensor. We only had one day to do this project, so this was not the time to reinvent the wheel. Step 3: Tweaking one of the example apps that was included in the Kinect 2.0 SDK. We found an app that was made to do something when it detected a gesture. This was perfect for our purpose. We recorded our desired gesture, "the flap", in Kinect Studio and used Visual Gesture Builder (also included in the SDK) to build a database of our gesture. We then used this gesture database in the example app and suddenly we could recognize a flap! Now, all we needed was for something to happen when a flap was registered. Step 4: Creating a simple Node.js server that could not only serve our game, but also have an API endpoint and give the Windows app a way to notify the game that it detected a flap. This is a simple solution; a GET call to /flap is equivalent to pressing space in the game. ## WAI-ARIA support limitations and accessibility best practices DevFeed: [WAI-ARIA support limitations and accessibility best practices]() Original publisher: [Read original article]() Author: Tor-Martin Storsletten Published: 2017-06-07T12:00:00Z Content type: article Language: en Sources: [Finn.no]() Topics: [aria](), [Accessibility](), [Web Development](), [User experience (UX)]() Tags: [accessibility](), [aria](), [article](), [best-practices](), [ux](), [web-development]() ### AI overview This article explains how WAI-ARIA affects assistive technologies, emphasizing that support remains inconsistent across implementations. It recommends focusing on reliable accessibility fixes and universal design rather than depending on specific screen readers or ARIA features for UX improvements. ### Source excerpt 1. Introduction This article is intended for web developers who want to improve their understanding of the effect that WAI-ARIA has on assistive technologies. It will therefore be assumed that you already have basic knowledge about terms such as ARIA and screen readers. 1.1. Generalize screen readers From the perspective of web development, it serves no purpose to delve into technical details about specific brands of screen reading software. There are several reasons for this: We can't programmatically detect which assistive technologies our users are using. There are several good reasons for this, including privacy concerns pertaining to confidential information regarding personal health and diagnostics. Universal design means design for everyone, regardless of which type of assistive technology is being used. Therefore we won't talk about specific brands of screen reading software in this article. We will focus on best practices with universal design in mind. 1.2. The main issues with ARIA Firstly, support for ARIA in assistive technologies is still partial at best. A consequence of this is that only a handful of ARIA features are reliable across different implementations, and that is if we don't count older assistive technologies that have no support for ARIA at all. Therefore it becomes important to differentiate between ARIA features that we can reliably use for correcting accessibility issues versus ARIA features that we should only use for improving UX. I.e. to a certain degree we can accept that UX will differ depending on which screen reader is being used, but keeping parts of our applications inaccessible to everyone except those who are fortunate enough to use the right screen reader is unacceptable. Naturally this is something that will slowly but surely sort itself out as makers of assistive technologies continue to work on their ARIA implementations, but for the time being we ought to remain mindful of this. The second issue related to ARIA is that man ## Feature Toggles and the Unleash Framework for Continuous Deployment DevFeed: [Feature Toggles and the Unleash Framework for Continuous Deployment]() Original publisher: [Read original article]() Author: Ivar Conradi Østhus Published: 2017-03-10T16:58:36Z Content type: article Language: en Sources: [Finn.no]() Topics: [Continuous Deployment (CD)](), [CI/CD](), [Open Source](), [Framework](), [Software](), [Software as a service]() Tags: [continuous-deployment](), [deployment](), [framework](), [open-source](), [software]() ### AI overview This article explains how feature toggles separate deploying code to production from releasing features to users. It presents Unleash, an open source framework that supports user-specific activation strategies and describes how feature toggles helped FINN integrate unfinished features earlier while avoiding long-running feature branches. ### Source excerpt FINN.no is the largest online marketplace in Norway, and we take continuous deployment seriously. We are about one hundred developers deploying new code to production 978 times each week. That is 978 / 100 = 9.78 deployments to production per developer every week. In order to get to these numbers and still keep it under control, we have had to both change our development process and establish the right set of tools. In this article we introduce feature toggles and how this technique has contributed to our continuous deployment success. We will also present Unleash, an open source framework we created to support feature toggles at an enterprise scale. Unleash allows us to enable features for specific users via the activation strategies concept. Unleash is already set up and in use by multiple teams within Schibsted, including FINN, SPT Payment, and Knocker. Unleash is now also available as a Software-as-a-Service offering, making it much easier for anyone to adopt. Check it out at unleash-hosted.com Number of production deploys in "week 50" Feature Toggles 'Feature toggles' is a simple technique to separate the process of putting new code into production from the process of releasing new features to our users. In its simplest form a feature toggle is just a "if" statement in the code, guarding the new feature: if (unleash.isEnabled("AwesomeFeature")) { //magic new feature code } else { //old boring stuff } The fastest way to get started with feature toggles in your project is to use a plain old properties file. This allows you to integrate unfinished features to the master branch and hide them from users in production. A simple plain properties files was exactly how we started playing with the features toggles in FINN. We realised that feature toggles enabled us to move faster, because we were able to integrate new and unfinished features to the master branch early. This also avoids long-running feature branches that tend to be harder to merge. We learned the hard wa ## Åpen fagkveld 7. mars DevFeed: [Åpen fagkveld 7. mars]() Original publisher: [Read original article]() Author: Gunn Skinderviken, Henning Spjelkavik Published: 2017-02-09T14:14:30Z Content type: article Language: no Sources: [Finn.no]() Topics: [Development](), [Node.js](), [Kubernetes](), [data](), [DevOps]() Tags: [architecture](), [data](), [decision-making](), [development](), [devops](), [kubernetes](), [node-js](), [organization]() ### AI overview FINN announces an open technical evening on March 7, featuring presentations about its product development practices, enterprise adoption of Node.js, architecture and organization, data-driven products and recommendation algorithms, and migration to Kubernetes-based cloud infrastructure. ### Source excerpt Åpen fagkveld 7. mars hjemme hos FINN - kl 15-20 For ett år siden åpnet vi dørene hjem til oss i Grensen for å dele våre erfaringer rundt hvordan vi jobber med produktutvikling. Vi fikk gode tilbakemeldinger på kvelden og nå ønsker vi å invitere til en ny fagkveld. Denne gangen blir agendaen mer rettet mot teknologien. Vi viser dere hvordan vi bygger og holder vedlike et av norges mest besøkte nettsteder. Program 15:30 Velkommen til FINN ved Anders Skoe (adm.dir) 15:45 "Slik jobber vi i FINN". 3 lyntaler som bør gi deg en bedre forståelse av hvordan vi jobber i FINN. Vi kommer blant annet innom organisering, strategi, arkitektur, devops, testing og kultur. 17:00 Introducing Node.js in an Enterprise. In this talk we will introduce Node.js and how we introduce it to a large enterprise in a safe way. 17:30 Beyond "Hello World", handling complexity and organization in large systems. How architecture and organization come together to address the challenges we face at FINN.no. How we believe decentralised ownership and decision making can help improve development speed and product quality over time. 18:15 Maskinlæring, anbefalingsalgoritmer og datadrevne produkter Hvordan bruker FINN.no sine data til å lage gode produkter for brukerne sine? Hvilke datadrevne produkter har vi, hvordan lager vi anbefalinger for brukeren og hvordan forbedres algoritmene bak. 18:45 Hvordan vi flytter FINN.no ut i skyen Vi jobber for tiden med å migrere mikrotjenestene våre til en mer moderne, dynamisk skalerbar infrastruktur basert på Kubernetes. Hvordan gjør vi det, og hvordan sørger vi for at vi håndterer brukertrafikk og kan fortsette å levere endringer til prod 1000 ganger i uka mens vi migrerer. Takk til alle som kom for en hyggelig kveld. Presentasjoner Slik jobber vi i FINN - organisering og kultur Slik jobber vi i FINN - prosess Slik jobber vi i FINN - IT-Strategi Introducing Node.js in an Enterprise - Node Introducing Node.js in an Enterprise - Application modularity Beyond "Hello Wo ## Using search to guess job categories in FINN småjobber DevFeed: [Using search to guess job categories in FINN småjobber]() Original publisher: [Read original article]() Author: Tor Arne Kvaløy Published: 2017-02-02T14:14:30Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Machine learning](), [datasets](), [Forms](), [Development]() Tags: [data](), [forms](), [machine-learning](), [search](), [supervised-learning](), [user](), [using]() ### AI overview The article explains how FINN småjobber explored automatically guessing job categories from user-submitted titles. Although supervised machine learning was considered, the team used existing indexed job data and normal search to rank likely categories. ### Source excerpt The problem Making it easy to fill out forms is essential for getting data into our system at FINN småjobber, which is a service to get help with tasks like house cleaning or renovation, where the user submits a job that non-professionals bid on. Submitting a job is done by filling out a form with a title, a short description, and selecting the category the job belongs to. The category hierarchy has two levels: a main category and a subcategory. For example the main category domestic help, has the subcategories cleaning and babysitting. There are 6 main categories and 26 subcategories, and our assumption was that it was a hassle for the user to go through this long list. We wanted to simplify this by guessing the category. Ideally on the given title. The solution Machine learning A typical solution to this kind of problem is to use machine learning, where the goal is to classify job titles into categories. We had a large set of historical data (130 000 registered jobs) where category already was selected by the user. This was a good starting point for a type of machine learning technique called supervised learning. In supervised learning historical data is used as a training set, and results in a classifier that can classify job titles into categories. Delving into the field of machine learning is quite a complex task, and requires both theoretical understanding and knowhow of various software libraries. And in many cases, it requires access to a special machine learning infrastructure. So, as a lean product development team with limited resources we looked for an easier solution. Good old search Search was a sentral part of our service. All the jobs were indexed, and we had all the necessary libraries and infrastructure for this. So, what about using normal search to find the category? A simple search on the title "Cleaning kitchen", gave the following ranked results: Match rank Category 1 Renovation 2 Cleaning 3 Cleaning 4 Renovation 5 Cleaning 6 Cleaning 7 Cleani ## FINN Developer Builds a Global Messaging Component in Barcelona DevFeed: [FINN Developer Builds a Global Messaging Component in Barcelona]() Original publisher: [Read original article]() Author: Per Jørgen Walstrøm Published: 2016-11-01T10:17:32Z Content type: article Language: en Sources: [Finn.no]() Topics: [Messaging]() Tags: [messaging]() ### AI overview A FINN developer describes working in Barcelona on a global messaging component for Schibsted-owned classified sites. ### Source excerpt As some of you may know, FINN is owned by Schibsted. What may not be that familiar, is that Schibsted has online classified solutions in several markets around the world, including Blocket in Sweden, Le Bon Coin in France and Vibbo in Spain. Schibsted has several hundreds of developers distributed around the globe, and there is a strong need and will to coordinate and cooperate across geographical boundaries. The need to cooperate Reinventing the wheel is generally a bad idea. With that in mind, Schibsted has a strong focus on building global components that can be useful for all the companies within Schibsted. However, it is not always easy to understand the needs and challenges across national borders. There are cultural differences and different companies have reached different maturity levels. FINN has been around for years, and is one of the more mature classified sites within Schibsted. In an effort to help building global components, Schibsted has set up an international hub in Barcelona and developers from the local companies are encouraged to come to Barcelona to help out, share knowledge and build a common platform. Several developers from FINN have taken up the challenge and spent some months in beautiful and vibrant Barcelona. Here are Øyvind's impressions. Anders, Øyvind and Per Jørgen. Three happy FINN-campers in Barcelona Øyvind goes messaging Øyvind has worked as a developer for FINN for 9 years, but when he got the opportunity to move to Barcelona for 6 months, the decision was easy. - The decision was really easy. There was little risk involved and I thought it would be an excellent opportunity to experience Barcelona. I love the city and the international atmosphere at the office. I think we are around 25 nationalities working here. - Tell us about the work you have been doing in Barcelona - I work as a developer here, in a team that developes a global messaging-component to be used by Schibsted-owned classified-sites around the world. When I arri ## Browser statistics October 2016 DevFeed: [Browser statistics October 2016]() Original publisher: [Read original article]() Author: Henning Spjelkavik Published: 2016-10-04T10:02:32Z Content type: article Language: en Sources: [Finn.no]() Topics: [Statistics](), [browsers](), [browser](), [Web app](), [Mobile]() Tags: [android](), [browser](), [browsers](), [edge](), [google](), [ios](), [microsoft](), [migration](), [mobile](), [mozilla](), [samsung](), [statistics](), [web-app]() ### AI overview An update on FINN.no browser and device usage in October 2016. The article reports that 66% of visits came from smartphones or tablets, 24% came from native mobile apps, and 76% came from the responsive web. It also compares browser vendors and provides mobile browser details. ### Source excerpt Last year, we presented the browser statistics of FINN.no as of June 2015. It's time for an update! How many visitors use a desktop or laptop? Our first graph shows the share of our users using a mobile phone, tablet or a desktop computer to access FINN.no, regardless of whether they use our responsive web app (m.finn.no), or a native Android or iPhone app. 66% of our visits are now from a smartphone or a tablet. The traditional desktop/laptop has a market share of 34%. If we exclude the native app users, which are obviously on either Android or iOS, what is the distribution between table, mobile and "other" (desktop) on our web site? Which FINN.no application do people use? We have two major offerings of FINN.no - the responsive web (served from the domains m.finn.no and www.finn.no), and native apps for mobile devices. 24% of our visits are from our native apps, and 76% from our responsive web. Since we're in the middle of a migration, some of our internal details leaks out in this graph; some parts of the finn.no traffic is served from the domain www.finn.no and the majority from the domain m.finn.no. They are supposed to be merged "real soon now". Browsers First of all, let's take a look at the numbers of the browser vendors. The ranking is clear, Apple is the biggest, ahead of Google, Microsoft, Samsung and Mozilla. Opera is no longer in the top 5. In case you wondered which browser is the biggest on the "desktop" here's the trend. (Ignore the orange and blue triangle markers) The complete browser statistics, across all applications and devices are as follows: It still seems like a good idea to make sure your website works well with Safari! The old giant Microsoft now has only the 5th spot with IE 11 (6.8%) and the 12th with Edge 13 (1.7%). Mobile details We got a request to give some more details about the mobile devices that uses FINN.no. Apple still has a strong position in Norway! The most popular browsers on mobile devices: Then the question is - what is t ## Prometheus for Monitoring Microservices and Business Metrics DevFeed: [Prometheus for Monitoring Microservices and Business Metrics]() Original publisher: [Read original article]() Author: Håvard Nesvold Published: 2016-08-26T13:00:00Z Content type: article Language: en Sources: [Finn.no]() Topics: [Prometheus](), [Microservices](), [Monitoring](), [Kubernetes](), [Time Series](), [Architecture & Design]() Tags: [grafana](), [kubernetes](), [latency](), [memory](), [microservices](), [monitoring](), [prometheus](), [time-series]() ### AI overview FINN describes switching from StatsD and Graphite to Prometheus for monitoring time-series data in a microservices architecture. The article discusses Prometheus's scalability, Kubernetes support, and monitoring of both application and business metrics. ### Source excerpt Having moved towards an architecture of microservices, FINN is already leveraging a number of technologies for identifying and dealing with service outages within this architectural style. With each piece of functionality being comprised of a growing number of individual services, specialized tools are required for detection, analysis and mitigation of errors, and we are already using our fair share: Zipkin, Hystrix, Kibana, Grafana and Sensu to name some. When it comes to metrics and monitoring of time series data, FINN has traditionally employed an infrastructure based on StatsD and Graphite. Recently, however, we opted to switch to Prometheus. Prometheus, which is heavily inspired by Google's Borgmon monitoring system, was originally developed by SoundCloud as a reaction to scaling issues experienced with just StatsD and Graphite. Taking into mind Adrian Cockcroft's rule #4 of monitoring: Monitoring systems need to be more available and scalable than the systems being monitored Prometheus stands out as a great choice for us. Not only is it directly supported by Kubernetes, the future container management platform of choice here at FINN, it has been engineered from the ground up to deal with issues of scale and stability. In this new area of monitoring microservices, Graphite seems to be losing ground. The switch to Prometheus has been rapidly implemented by all our autonomous service teams. Along with monitoring of the "traditional" application metrics like latency and memory usage, special care has also been taken to ensure implementation of adequate monitoring of business metrics. Business metrics monitoring The implications of one failing or partly broken service can be hard to evaluate when you are dealing with a large number of services. Since a complex problem now can be broken up into units that are truly independent, all individual parts can continue to work fine separately, while the end result is just not working. Business metrics monitoring is a key to ## Summer Project 2016: Customer Insight DevFeed: [Summer Project 2016: Customer Insight]() Original publisher: [Read original article]() Author: Martin Ek Published: 2016-08-12T11:04:35Z Content type: article Language: en Sources: [Finn.no]() Topics: [App](), [data]() Tags: [application](), [customer](), [data](), [project](), [ranking]() ### AI overview A summer intern team at FINN describes an application built for professional vendors on Torget. It provides geographical visitor data, customer demographics, and competitive ad rankings based on visit counts. ### Source excerpt This year's summer intern team consisted of five technology students from UiO and NTNU and one in-house design intern. We have released continuously throughout an eight week period, and have ended with a final solution which is available to the public. The problem presented for this year's summer project was; What can FINN offer professional vendors at Torget to motivate them to continue advertising as professional vendors. To help us get started, we had a few meetings with FINN's innovation team to work out an ambition and a few ideas. Our ambition was to create value for professional vendors that use Torget as a market to run their business. To achieve this we aimed to provide better advertisement insight for vendors, and give them a better look into their general performance at Torget. Our application consists of three main parts. The first presents geographical data about the ad's visitors, show n on a map of Norway. This is primarily shown as percentages on each of Norway's five regions, with more specific information shown in the cat's conversation box. The latter also changes when the user clicks around the map. The second part of the application shows demographic data about the customers, which includes age and gender. Here we hope to open a more insightful relationship between seller and customer, which might for example allow sellers to properly target their correct customer group when advertising new products. The last part of the application is a competitive ranking list that compares ads in the user's category based on number of visits. This is shown with green text to the right of each ad in the list. The user also has the option to change which category they want to see the ranking for, in the blue menu. One of the main goals here is to give users an incentive towards comparing their advertisements to their competitors', by letting them see what part of the market their customers prefer. Implementing the application The architecture we went with for t ## Splitting up a storyboard in an Objective-C/Swift mixed legacy project DevFeed: [Splitting up a storyboard in an Objective-C/Swift mixed legacy project]() Original publisher: [Read original article]() Author: Marius Waldal Published: 2016-06-22T11:19:07Z Content type: article Language: en Sources: [Finn.no]() Topics: [Objective-C](), [Swift](), [iOS](), [Xcode](), [interoperability](), [legacy](), [XML](), [App]() Tags: [c](), [interoperability](), [ios](), [legacy](), [objective-c](), [project](), [swift](), [xcode]() ### AI overview This article explains why the FINN iOS team split a large storyboard into smaller storyboards in a legacy project containing both Objective-C and Swift. It discusses collaboration problems, XML changes, Xcode performance issues, project history, and the importance of Swift-Objective-C interoperability. ### Source excerpt Splitting up a storyboard in an Objective-C/Swift mixed legacy project How do you go about splitting up your storyboard into multiple smaller storyboards? And why would you? In this article I'll tell you why we wanted to do this, what kind of problems we encountered along the way, and how we solved them. The problem: Large storyboards makes iOS developers into sad pandas As the FINN app has grown the last few years, so has our storyboard. Using storyboards means you get several useful features, and it can give you a visual conceptual overview of how your app works. I say "can", because this is not necessarily the case. Also, using storyboard has some quirks that are not always appreciated when multiple developers are working on the same project. Any small change to a storyboard might mean several changes to the storyboard xml. In addition to this, XCode has an annoying tendency to recalculate coordinates for several storyboard items just because you opened the file! And yet another annoyance is that the larger your storyboard, the slower it is to work with. We usually waited at least 5 seconds just for the file to open, and actions were often laggy. So, the iOS team had long ago decided it was time to split it up, but that job is not necessarily easy. Or small. Or even fun. And the Jira task for it also stated "Beware of scope creep...". Yeah, it crept. The FINN app: Some history The current FINN app was launched in August 2013. During these three years, the app has of course grown a bit, and during the last year or so several new features have been added using Swift, and quite a few of the older Objective-C classes have been rewritten in Swift. However, the majority of the code base is still Objective-C. Interoperability between Swift and Objective-C is therefore crucial. A quick count of files says that we currently have 171 Swift files and 349 .m files in our project (not counting third-party code, of course). These files contain >44,000 lines of code, comprised of ## Practical Methods for Improving Web Accessibility DevFeed: [Practical Methods for Improving Web Accessibility]() Original publisher: [Read original article]() Author: Tom Widerøe Published: 2016-06-13T11:19:07Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Accessibility](), [User interface design](), [Mobile](), [browsers](), [navigation]() Tags: [accessibility](), [accessible](), [browsers](), [keyboard](), [mobile](), [navigation](), [test](), [wcag]() ### AI overview The article explains how FINN.no employees encouraged colleagues to prioritize accessibility through workshops, user testing, and automatic validation. It describes practical checks including page scaling, pinch zooming on mobile phones, a straw test for limited vision, and keyboard navigation. ### Source excerpt What to do when your colleagues don't make accessible products. When developing a website which affects the life of almost every person in Norway, accessibility should be a main priority. Norwegians who are not able to use FINN.no are unable to find a home without assistance. Accessibility considerations are too often an afterthought, and this can have profound effects. In the Spring of 2014, a small group of employees got together to find out how to make our colleagues care more about accessibility. After two years, the measures we think work best are workshops, user tests, and automatic validation. Workshops On a workshop we reveal accessibility issues and discuss how to solve them. At our workshops we demonstrate how FINN.no works for people with disabilities before we let the team members test it the same way themselves. People find this a lot more inspiring than memorising WCAG 2.0 recommendations and running automatic validations locally. How to test Scaling Pages The simplest thing to test for is page scalability, both for fonts and for the entire page. Most desktop browsers make it possible to scale both fonts and page no matter how poorly coded the pages are, but on mobile phones it's still quite common to lock page size to screen size. It must be possible to pinch zoom every page on mobile phones. The Straw Test Another simple method is to pretend that you are looking at the page through a straw. This simulates how the page will appear for partially sighted people who either have a limited field of vision or need to magnify the page to read it. This reveals relevant elements spaced too far apart in a way that will make it difficult to navigate the page. Keyboard Navigation Most pages are designed and coded with mouse click and touch screens in mind, and we easily forget about people with broken arms, motor disabilities, or other reasons for not being able to use a mouse. By navigating the page with only a keyboard, we test that focus on links and buttons a ## Åpen fagkveld, presentasjoner DevFeed: [Åpen fagkveld, presentasjoner]() Original publisher: [Read original article]() Author: Jo Odland Published: 2016-02-15T22:04:17Z Content type: article Language: no Sources: [Finn.no]() Topics: [DevOps](), [data]() Tags: [data](), [devops]() ### AI overview FINN reports on an open professional evening attended by 140 people, describing its work practices and listing presentations on user-oriented, data-driven product development, DevOps, organization, innovation, and related topics. ### Source excerpt Onsdag 10. februar så hadde vi 140 personer på besøk hos FINN. Vi fortale litt om hvordan vi jobber i FINN og serverte pølser og øl. Nedenfor kan du finne presentasjonene fra fagkvelden. Programmet 15:15 - 15:30 Velkommen til FINN v/ adm.dir Sondre Gravir 15:30 - 16:10 Brukerorientering og datadrevet produktutvikling Hvordan involvere brukeren? (Dag Olav) Brukerinvolvering + data = suksess (Marthe) 16:10 - 16:45 Pølser og øl 16:45 - 19:00 To gjennomkjøringer av temasporene 19:00 - 21:00 Mingling med øl og snacks Presentasjonene var delt inn i tre spor. Temasporene Spor 1: Teknologi - kultur og organisering Spor 2: Produktutvikling Spor 3: Innovasjon og intraprenørskap Why & How we do DevOps in FINN (Jo) Slik reorganiserte vi 100 utviklere (Nicolai) Brukerorientert, målstyrt og iterativt (Bjørn Henrik & Bente Mari) Eksperimentering på skjema (Per Gunnar) Brukeropplevelse i FINN (Kaija) Innovasjon (Jens) Lær mer om FINN.no og se bilder og videoer her: ## Why Try - Java 8 lambdas and checked Exceptions DevFeed: [Why Try - Java 8 lambdas and checked Exceptions]() Original publisher: [Read original article]() Author: Sjur Millidahl Published: 2016-01-20T07:13:00Z Content type: tutorial Language: en Sources: [Finn.no]() Topics: [Java](), [exceptions](), [Scala](), [Open Source]() Tags: [compiler](), [exceptions](), [functional](), [java](), [lambda](), [open-source](), [scala]() ### AI overview This tutorial explains how checked exceptions complicate Java 8 lambdas. It presents FINN.no's open source Try structure, inspired by Scala's Try, to represent computations as Success or Failure and simplify mapping, flat-mapping, and recovery. ### Source excerpt Why won't this compile? (And why does riskyTask throw a PrinterException?!) One does not have to use lambdas in Java 8 long before running into the obstacle of checked Exceptions. Because the PrinterException is checked, the compiler forces us to deal with it, even within a lambda: private void demonstrate() { IntStream ones = IntStream.generate(() -> 1); ones.map(i -> { try { return riskyTask(i); } catch (PrinterException e) { System.out.println( "Your printer is out of ink or laser beams!" ); } return i; }); } private int riskyTask(int a) throws PrinterException { return 2; } But we don't like to do this. We use lambdas to express intent in a concise and elegant fashion. The try/catch-brackets feels like noise. For this reason, FINN.no's open source lambda-companion project introduces a useful structure for using lambdas in a world with checked Exceptions : Try. A Try represents a computation which might fail, and is always represented as a Success or a Failure (but never both). The concept borrows from Scala's Try, and shares several properties to other monadic functional structures : Future (completable success or failure) Optional (present or empty value) Either (one of two values) FINN.no's Try is right-biased, meaning that one can map and flatMap on a Try without having to add specific logic to handle a Try being a Failure; the computation will simply only take place if it is a Success. Using a Try we could refactor our riskyTask-example: private void demonstrate() { IntStream ones = IntStream.generate(() -> 1); Stream> tryStream = ones.mapToObj(this::riskyTask); tryStream.forEach(this::print); } private Try riskyTask(int a) { return new Success<>(2); } private void print(Try t) { Integer defaultNumber = 0; Integer i = t.recover(success -> success, failure -> defaultNumber); System.out.print(i); } This is contrived of course. And one should rarely accept a Try as a method argument. (And one should rarely generate an infinite str ## The great big Schibsted programming language survey 2015 DevFeed: [The great big Schibsted programming language survey 2015]() Original publisher: [Read original article]() Author: Morten Lied Johansen Published: 2015-11-21T21:28:28Z Content type: article Language: en Sources: [Finn.no]() Topics: [Programming language](), [Programming](), [data]() Tags: [data](), [programming](), [programming-language](), [survey]() ### AI overview The article introduces a 2015 survey of programming-language use among employees across Schibsted companies. It presents the survey as a personal project intended to replace opinions and hearsay in technology-choice discussions with data; 309 people responded. ### Source excerpt During September, I collected answers on a survey about programming languages from people who work in one of the many companies that make up the Schibsted family. The survey is neither requested, sanctioned, approved or even suggested by anyone in management, in any Schibsted company. It is entirely my own personal pet-project, because I'm interested in these things. The survey opens with the following introduction: In 2012, there was a discussion about technology choices, and particulary programming languages to use in FINN. As always in such discussions, claims like "It's impossible to hire people who know language X, so we need to always use Java" or "We can't expect programmers to learn a new language just because we think language Y would be a better fit" were put forward. Personally, I've never liked those arguments, because they contradict what I think defines a "good programmer", and I'm optimistically hoping that we only hire "good programmers". Also, instead of opinions, beliefs, rumours and hearsay, let's be data driven in these discussions! So I decided I wanted to put it to the test, and created a survey and posted it for all the company to see. The results from that survey were blogged about here: http://tech.finn.no/2012/09/04/leaving-the-tower-of-babel/ Now, almost three years later, a lot of changes are happening. FINN is becoming more close with it's Schibsted brethren, Schibsted itself is turning towards a more technological outlook, and I felt it was time to get an updated view, and why not involve all of Schibsted while we're at it. So, "The great big Schibsted programming language survey 2015" was created, and hopefully it will make the rounds in all of Schibsted and gather some interesting, fun, surprising and (with a bit of luck) useful insights. About the responses 309 people responded to the survey, which is more than many of my co-workers thought would respond. Over 50% of respondents are in their thirties, and if we look at the ages from [Next page]()