Selling price suggestion with linear regression

There comes a time when you start noticing all these useless items around you – whether it’s because you badly need money to buy something new and shiny, or simply because you realized your apartment’s size has mysteriously decreased by 200 sq ft in the last few years. In moments like these, I usually want to sell a lot and do it as quickly as possible, meaning I would rather go for a fixed price instead of launching a 14-day auction. And here’s the tricky part: how to choose a reasonable price for my treasures? One way is to dig through similar listings, set up various parameters filters and then finally calculate the average market value for each of the items, but there are two problems with this approach:

a) Only ongoing listings are available, which means the real value of an item is often obfuscated – majority of the auctions were most likely already finished and their selling prices are unknown. There’s a risk that the listings we can see are significantly overpriced and that might be the main reason they’re still out there.

b) It’s slow, boring and tiring.

What if there was a much faster solution? I wish Ebay or its Polish competitor Allegro had a feature to speed up this process by supporting amateur sellers like me with a suggested price.

The idea is to create a prediction model for this particular task and automate it to some extent. Having access to huge amount of historical auctions data, one could create supervised learning algorithms for several categories. I tend to think it’s a feasible plan for items whose parameters can be unambiguously determined and represented by numerical values, e.g. cars, cameras and many other electronic devices.

The price is a continuous output, so by definition it’d be a linear regression problem with multivariable hypothesis function. Since I’m currently trying to get rid of a notebook, I’ll use it as an example. The model representation could be based on seven features that I care about (in reality, I’m definitely more picky than that): screen size (in), RAM (GB), CPU clock rate (GHz), number of CPU cores, disk size (GB), weight (kg) and release year. This gives us eight variables as a starting point, including the conventional intercept term \theta_0 x_0.

After researching the topic for a while, I found out that Ebay has indeed bought a company doing just that (and even more exciting things, like predicting the results of ongoing auctions) two years ago, so hopefully this feature will get real soon.

Polly – getting started with Nearby API

In July 2015, Google released the Nearby API as a part of Google Play services. It gives developers a new way to exchange data between devices based on their proximity. The API is divided into two subcomponents: Nearby Messages and Nearby Connections.

Nearby Connections relies solely on Wi-Fi and allows for real-time communication between devices connected to the same local network. First use case that comes to mind is multiplayer gaming, but Google also suggests it could turn a phone into an Android TV’s game controller.

Nearby Messages, on the other hand, uses a more sophisticated and interesting mechanism to determine proximity: it combines Wi-Fi, Bluetooth, speaker and microphone to establish a contextual pairing between all nearby devices. That alone made me want to play with it, since I’ve been recently drafting my own solution for local, P2P-like communication, but totally independent from any server (as opposed to last year’s famous FireChat, which requires an account) and Google Play services.

While Nearby Messages doesn’t require a Google Account, the actual communication is handled by Google’s servers, so each device has to be connected to the Internet, which also implies that there’s a data payload limit of 100 KB, and the recommended optimal size is only 3 KB for a single message (see: Message class). However, after the neighbouring devices have been discovered and the pairing was established, it’s up to developers to decide if they want to stick with Nearby API for further messages exchange, or transparently redirect the app to use their own implementation (whether it’s a server or local BT/Wi-Fi Direct communication).

There’s a lot more of interesting stuff about the API, but here are the 2 facts that you won’t find in the official documentation:

  • There’s currently no limit to number of devices communicating over Nearby API.
  • While it is claimed that broadcasting/scanning for token with speaker/microphone is based on inaudible ultrasonic sounds, you can actually hear your speaker working quite clearly (at least on a Samsung Galaxy S2 and Nexus 5 that I’ve been testing with) when scanning is active.

Giving it a try

To familiarize myself with the API, I’ve started to work on a simple app called Polly, which – you guessed it – allows to conduct polls and surveys with people around you (at a conference, for example). I’m not sure if it will end up as a full release to Google Play (it would be nice to have an iOS companion app) or just one of many working prototypes, as I call my unfinished projects.

What’s in the box? Mainly ButterKnife, Dagger, Timber and Otto. I’ll probably also refactor PollRepository and its clients to make use of RxAndroid.


1 4

Raz dwa!

“Raz dwa!” speeds up SMS-based two-factor authentication process with selected banks and services.

When you receive an authorization SMS from your bank or other service, the app will automatically display a notification with the one-time password, copy it to the clipboard and read it out loud. You will no longer lose your time trying to find it in long, boilerplate messages. Confirm money transfers or log in to your account in the blink of an eye.

Currently most major Polish banks and a few other services are supported, which means that my brain’s got a quite intensive regex training during past few days.

The app is live on Google Play (available in Poland only).

Update: the app received a positive review on

Update 2: Raz dwa! was also featured on