Entering Data

I weigh 209.4 this morning.  That’s down from 220 when I Declared A Jihad on My Weight on 10/27/08 although it doesn’t look like I’ll make my Anti-Charity goal of 200 by 1/31/09 (more on that in a post on 2/1/09).

I was thinking about my weight this morning as I entered it into the online system at GoWear.  I thought about it again when I entered it into Gyminee.  And then into Daytum. I’m going for a run in a little while so I’ll enter it again into TrainingPeaks

Here’s what I’m doing:

  1. Go to the appropriate web site.
  2. Choose the appropriate place to enter the data.
  3. Type 209.4 and press return.

Four times.  Every day.  Pretty ridiculous.  If you reduce the data to its core elements, they are:

  1. Web site id [GoWear, Gyminee, Daytum, TrainingPeaks]
  2. User Id (almost always bfeld)
  3. Timestamp (or two fields – date, time) – automatically generated by my computer
  4. Weight

The only actual piece of data that I need to measure is weight.  I measure this by standing on a scale each morning.  The scale is a fancy one – it cost about $100, looks pretty, and has a bunch of extra things I don’t look at such as BMI.  I have an identical scale in my house in Keystone (although the battery is dead and needs to be replaced.)

Some day, in the future, I’ll be able to step on the scale.  And that will be it.  My weight will automatically go into whatever online systems I want it to.  I won’t have to do anything else. 

Of course, one of the assumptions is that my scale(s) are “network compatible”.  While you may joke that this is the age old “connect my refrigerator to the Internet problem” (and it is), I think it’s finally time for this to happen.  As broadband and wifi become increasing ubiquitous and inexpensive, there is no reason that any electronic devices shouldn’t be IP connected, in the same way that microprocessors are now everywhere and pretty much everything has a clock in it (even if some of them still blink 12:00.)

So, accept this assumption.  Then, I’m really only taking about a “Brad-centric” data payload.  While I’ll have a lot more data than simply weight that I might want in my payload, let’s start with the simple case (weight).  Right now, we are living in a system-centric world where data is linked first to a system and then a user.  Specifically, you have to operate in the context of the system to create data for a user.

Why not flip this?  Make things user-centric.  I enter my data (or a machine / device collects my data.)  I can configure my data inputs to feed data into “my data store” (which should live on the web / in the cloud).  Then, systems can grab data from my data store automatically.  All I have to do is “wire them up” which is a UI problem that – if someone is forward thinking enough – could also be solved with a single horizontal system that everyone adopts.

Right now there is a huge amount of activity around the inverse of this problem – taking widely diffuse data and re-aggregating it around a single user id.  This deals with today’s current reality of how data is generated (system-centric) but doesn’t feel sustainable to me as user-generated data continues to proliferate geometrically.

Enough.  As I said in my tweet earlier today, “thinking about data.  thinking about running.  thinking about thinking.”  Time to go run and generate some more data.

  • Brad: Definitely flipping the equation will help. Users have the data store centrally (perhaps cloud-based) and then configure the services to come and retrieve so that they can do their thing. At a minimum, this is why data portability has to take hold.

    Earlier this week, I was speaking with Jeff Nolan and we got to talking about Teqlo. While I was intrigued about their concept, I thought it was ahead of its time because the average consumer isn't going to build their own application (or at least they need something where they don't even know they are building an application.) Kind of like everyone doesn't know they are using RSS right? 🙂

    Anyway, something Teqlo-like would be interesting. Have a weight module where you populate your central data store and it has data rights to deploy those couple pieces of data out to those services. Synchronization (and synchronization rights) could be another killer platform capability in this realm once it takes off.

  • Related stuff…

    http://androidcommunity.com/fujitsu-launch-servic…(from yesterday)

    http://sotirov.com/2005/02/07/have-syke-and-bod-w…(this is a 4-year old post)

    BTW… IE7 doesn't like your blog lately (I still use IE because most my users are on it).

    • I love your Skye and Bod post – right on.What problems are you seeing on IE7?  I just tried it on IE 7.0.6001.18000 and it looks fine.

  • The problem you describe has already been solved. Essentially you're talking about "Me" data. (in your case Brad data). We built a solution that allows you're "Me" data (you can control every element of it) to be transmitted to a web site the second you load the web site page in your mobile browser.

    It (the web site) knows who you are, what device you're on and where you are – all in real time. You can hook a heart monitor to your mobile phone and send that data in real time to a web site. Same for a weighing monitor. You never have to type in anything it simply knows who you are and can read any data that you want to send to it.

    As for the UI – we solved that by allowing a web service (using simple HTML) to build contextual menus that appear inside the mobile browser. If you're interested go to this link: http://www.5o9mm.com/usecases/magpie.html“target=”_blank”>http://http://www.5o9mm.com/usecases/magpie.html–do a right click on the page and view source – look for the following menus all built using HTML. Our plugin now modifies the current browser menu to add these new menus. They are all dynamic can can be adjusted for an unlimited number of services.

    Edit Goals
    Change Alerts
    View Activity History
    Log Food
    Log Weight
    Log Exercise
    Connect HR Monitor
    Transmit HR

    These are all "web services" – you can already see one that says log weight

    Customers already know how to use the browser, (no behavioral change required) and there is no change for the web admin because it's just a web service and therefore integrates into everything they have already working.

    So the answer to your post is that there is a solution out there and it works on your mobile phone.



    • I agree that this is technically straightforward.  However, it’s not obvious to me from your example how I would use 509mm to wire up my weight data in my example.  In addition, I’m not really interested in using my mobile phone as the data input device (it sucks for a lot of this stuff) – I want the source device to do it directly.

  • IE ver 7.0.5730.11

    It loads the page… and then a message pops up

    "Internet Explorer cannot open the Internet site http://www.feld.com/archives/2009/01/entering-data.ht...target=”_blank”>http://http://www.feld.com/archives/2009/01/entering-data.ht...
    Operation aborted"

    And then the page disappears.

    But this might be a problem on my computer only… a friend just told me he doesn't have this happening.

    Thank you for liking the "syke and bod" post.

  • Peter Cranstone

    Think of the source for the moment as a mobile phone. It knows who what and where you are. There is no data to enter because it knows and the second you go to the appropriate web page it allows knows.

    Now extrapolate that to "any" device with an IP address. The problem remains the same… how do I do the following four things without "entering any data":
    1. Go to the appropriate web site.
    2. Choose the appropriate place to enter the data.
    3. Type 209.4 and press return.

    The mobile phone totally sucks when it comes to entering data – and yet all you have to do above is three events. Imagine if you actually had to enter in lat/long and a bunch of other data. You simply wouldn't do it.

    The problem remains that you want to reduce the friction in the particular transaction and then scale that to the entire Internet. As there are two components to the Internet (a client and server) you must solve for those two items plus the actual meta data required from the customer.

    You're describing a service above. Using the solution I described all you have to do is go to a web site, select a menu and enter your data. On mobile that meets the following criteria:

    O behavioral changes
    1 log on
    2 second response time
    3 clicks to relevant content

    On your weight machine you could reduce this further… only one problem how does it (the weight machine and the web) differentiate between you and say your wife using the same scales. The key is literally your "Me" data vs. everyone else's Me data.

    Our solution scales to any source device and that's the real key here. Making it work for a weight machine is one thing, scaling it to any source device which can attach to the Internet requires a much different solution – one that leverages all the existing infrastructure and works the way everyone is used to working.



  • Strange.  I’ll ask my IT guy to take a look.

  • Strange.  I’ll ask my IT guy to take a look.

  • Peter Cranstone


    Follow up to my last two comments. Ignoring the 5o9 solution for the moment and focusing in on your particular problem. I would imagine that the weight scale has some sort of PC with an operating system inside. It has a Wi-Fi and or TCP/IP port and the monitor has some sort of interface for connecting to the web site that monitors your health. (My guess here is that they would use a browser). You still have to program the device for your particular set of "Me" data however once that is done all you have to do in the morning is hop on, see your weight show up and then hit the submit button and it gets recorded on the web site.

    Now compare that with the alternative solution I proposed. You hop on the scale in the morning and see your weight. You reach for your mobile phone, fire the browser, hit the bookmarks, select the weight site and nit the menu key to "Log weight". Web page appears and you simply type in 200 or to make things even easier you could select from a drop down combo box.

    Technically there is absolutely no difference between the scale with a web connection and the mobile device "other" than one records your weight vs. the other one which you enter your weight. Neither require any more data entry than 200 or "submit weight button".

    The big difference remains that the mobile device can be used anywhere there is a scale vs. the expensive one you keep at home. So think about this for a moment. When you go on a run you should weight yourself before and after the run. (fluid loss issues). So you keep a set of scales in the car with you. All you need is your mobile phone and a web service which supports "log weight". No difference in data entry other than you have to type in 3 characters.

    Now for the cool part. At the end of your run (assuming you're not local in Boulder) you've entered your weight via the mobile phone and are now looking for a cool restaurant for a nice meal. You hit Google with your browser. Google has access to your "Me" data including your real time location and can immediately direct you to a local watering hole. Something the scale can never do.



    • Peter – good examples. However, let's go to a general case. I want to enter my food consumption information. Right now I am entering it into GoFit, Gyminee, TrainingPeaks, and HealthCubby on iPhone (yuck).

      I understand how I want to do this, but I'm not seeing how your software helps me do it.

  • Two quick points:

    User centered control of data and then permission based sharing to the 'health cloud' is what Microsoft HealthVault is targeting. The specific idea is that a user's vault can be populated with data directly from the user, the user's devices or healthcare concerns that the user has granted permission to.

    Second point, as part of this platform, Microsoft has ported the (in)famous 'plug and play' architecture from the devices group, to work with medical devices in such a way to provide automated upload to the vault. See this:

    You'll note that this particular model still requires a USB connection to the user's computer (brad cue boo'ing here), but when the hardware supports the capabilities you describe above, then the rest of the data handling is taken care of.

    No, I dont work for Microsoft :), but I know the very smart folks that are working on this and I believe this and others (Google Health) will enable this. Now all we need are the wireless scales.

  • Peter Crantone


    Great post… one issue. How does this idea (Microsoft's) scale to "other web sites"? The whole idea here is that it's my "Me" data. It should always remain with me. So for instance I can have my medical data with Microsoft but then use my location data for search and my weight data for my other health site. It's all about "Me" and then being able to use that data (and still control my privacy) with ANY web service.

    Prior to building our solution we talked to a lot of potential customers and users. On the user side (think Brad here and also your medical play)… they want three things in the following order:

    1. Convenience
    2. Privacy
    3. Control

    On the Enterprise side (the web service) they only wanted one thing:

    1. To make money

    The friction point (and hence the opportunity) is how to enable this new data to flow seamlessly around the web while still protecting the users privacy.

    When I log into Microsoft Health Vault it (the service) should know it's me and everything should be personalized (and here's the critical point) for the device I'm accessing the site with. Next I move on to my other Health site who track my weight. Today I'm accessing the site from my scales so it simplifies everything, tomorrow I'm going to access it from the start of my Marathon in Hawaii via a mobile phone. The point is that it should never ever matter what device or how i access the site – it should know it's "Me" and respond accordingly.

    This of course is a horizontal solution and plays to every web service vs. a single vendor solution. Sort of like OpenID except with a whole lot more data and extensibility.



    • Yes, agreed. For what its worth, the view that you describe..all data, flowing into a central vault, user controlled and user shared to all web services is indeed what these bigger players are trying to do. They have the dubious baggage, however, of being who they are, and thus their challenge to overcome that reputation.

      To be successful you need these things; a platform for aggregating health data, complete adherence to standards by the health ecosystem, being a trusted source, and a being an open platform. MS and Google can cover probably most of this, but not likely all. Thus their challenge. Attempts from the other angle (ala OpenID) might be more trusted and open, but boy do they have a job in creating a platform for all and pushing standards for the plurality of inputs and outputs that do/will exist.

  • Peter Cranstone


    Totally agree with your post – and now I'll throw another idea out for you to ponder. This is in regard to the "platform challenge" you mention. What if you did the following? Simply "extend" the current HTTP protocol. Ironically the IETF standards (RFC 2616) says it can be done (http://www.ietf.org/rfc/rfc2616.txt)”target=”_blank”>http://http://www.ietf.org/rfc/rfc2616.txt)..go look at section 12.1 it's titled "server negotiation". Where they talk about "user agent" simply convert that to "meta data agent". Now pay careful attention to the disadvantages section where they say it can't be done. (I think they're wrong)

    The simplest solution to your platform challenge is to use what is already there. Every web server supports CGI and every web server has a module/ISAPI interface which essentially extends the web server to do other things (disclosure I'm one of the inventors of mod_gzip for Apache). Now imagine a web server that had a module that allowed it to "read" incoming meta data which had been stored inside the HTTP request headers. The final issue to solve is how do I get the data into the headers? Well that gets accomplished on the client device.

    So let's take Brads "weight case". That is nothing more than meta data. He gets on the scale and it reports his data. Now what if we grabbed that data in real time and injected it into the outgoing HTTP request header which is going to the web server. Now you're leveraging the one protocol that runs the Internet and simply expanding it's capability to carry new meta data. Nothing new there except that it's far more data than the RFC says can be handled by a server. This is of course is wrong. The data is very small – Brads weight can be recorded in 3 bytes plus a little overhead for the header name i.e. http_x_brad_feld_weight="200" Now all the server module does is read the incoming header, it immediately knows "who" it is, and grabs the weight data and using CGI (been around since the beginning of time) pumps it directly to the web service back end.

    So to answer your question about creating a platform for all and pushing standards for the plurality of inputs and outputs that do/will exist. The above describes a solution that follows all existing Internet standards, works with every web server/service and scales (pun intended) to any device that will exist.

    Why I get excited about mobile is obvious. It is becoming more like a tricorder every day. A few years from now we will attach sensors to our body and that information will be sent to the phone via bluetooth. From there it will simply become meta data to be shared with any service that you give permission to. Once you start treating everything as data (sematic web anyone) then the solution lies in the transport mechanism. Why break what already works? Simply make the protocol a little smarter and allow it to carry any data instead of just the old fashioned and seriously out of date user_agent field.



  • Peter Cranstone

    Please note before reading this post – I'm assuming you're using a mobile phone vs. a desktop browser with a mouse and keyboard.

    Response to entering food consumption onto three different sites. This is actually pretty straight forward. Each web site is essentially nothing more than a service. You navigate to the web site using your mobile browser and click on the browser menu key. Instead of seeing File, Edit, View, Tools, Refresh, you see a whole new set of contextual menus which are personalized for you: (what you are actually seeing here is the menu structure that programmers would build on a monolithic mobile app. Instead they appear in the browser menu dynamically. The mobile browser essentially turns into a rich internet application)

    Edit Goals
    Change Alerts
    View Activity History
    Log Food
    Log Weight
    Log Exercise
    Connect HR Monitor
    Transmit HR

    You select via the browser menu Log Food which takes you to a page which says "Hi Brad, please enter your data". It already knows Who you are, and exactly what type of device you are connecting with so the web page is perfectly formatted. The web site has already created a page that has drop down boxes from which you can select the foods you have eaten. You click away and you're done.

    Now you're probably asking yourself why is this any different from any normal web page. Well think about other meta data that is important for exercise like resting heart rate or current blood pressure or weight. This is dynamic data which can only come from "Me".

    It's tough to input that kind of data, like entering lat and long. The mobile phone can be used to transmit that data in real time to the service. It stores the data in a database on the device and then transmits it to the web service (along with your user name and password) when you opened the web page.

    It's the combination of ALL of these different types of data that makes the service so much more powerful.

    The mobile phone is going to merge contact with content. The whole web is now becoming a web service, customers interact with it through one medium the browser because it's device agnostic. What everyone hates to do on a mobile phone is input data. It's impossible to enter dynamic data like weight, blood pressure, heart rate, lat/long, IMEI number, call logs etc. However this kind of data is the most valuable to the service.

    Let me give you one more example "Emergency First Responder". He/She lands in the field and attaches a sensor to his mobile phone. Navigates to the Department of Homeland Security's web site. Instantly the site knows who he/she is, and where he/she is (the phone transmits lat and long). Before they can navigate to a sensitive web page the phone rings (the site knows the users mobile phone number). They are asked for voice authentication pin number. After giving the correct response the browser navigates to a new area of the web site. The first responder hits the browser menu key and sees the following menus:

    'Class A'
    'Class B'
    'Class C'
    'Air Quality'
    'Read Sensors'
    'Upload Results'
    'Support Request'
    'Search & Rescue'
    'Take Photo'
    'Take Video'
    'CC CDC'
    'CC NEST'

    He selects read sensors and real time data is transmitted from the sensors. He/she then selects Take Photo and clicks away and then hits "Upload".

    If people are still reading here… the problem started out as a way to transmit data to a web service without having to input data. The key lies in the type of data. If it's dynamic data (weight is) then the mobile device becomes a perfect transport mechanism. The key literally is to reduce the friction in the transaction. It's never about typing in one piece of data. Services want as much data as possible, the more they can get the richer the customer experience. In the same breath above you support health and fitness and emergency first responders.

    And what Steve wanted to know was what platform would you use. And the answer is, the one you're currently using. No changes required.



  • Josh

    I think we're missing something here.

    We have a client that provides weight management tools and services as part of health and wellness programs. We've integrated wireless scales and pedometers that allow for automated tracking. This currently logs data into their system.

    But that's not good enough – for all the reasons outlined – and another. Which, for me, is where it gets really interesting.

    We invested a bunch of time and cash to pull that data into a common data model, along with other information that may be available like GPS information. For GPS information, we merely refactored the GPX schema a bit with the goal of submitting the data model and opening it all up for use by the community in the coming weeks – if it proves to be useful. And, of course, we have our own hosted data accessible through REST. Our first "client" (they are getting it for free) is going live on Monday.

    We thought it would be interesting to tie that into OpenID and have also been playing with Facebook Connect. We started surfacing information up through Facebook and Ning in addition to some folks Web sites. All these are just ways to surface the same stuff in different ways depending on context and additional capability provided by the host.

    But what gets really interesting is when we can aggregate data across multiple open data sources. If I want to track an activity – I can get my weight from the morning and the numbers from my ride – automagically from my wireless devices – without keying anything … and then pulling in elevation data from another external data source for even more. We just finished up doing this for another customer this weekend. It's really cool stuff.

    So – not only can I track my stuff – I get value added data. And then I can compose my own applications that use a composite of all the information I want to see or log or share.

    I love seeing all this energy around this sort of things. We've been having a blast with it. Brilliant stuff. Thanks for the post.

  • Peter Cranstone


    You've hit the nail squarely on the head. The future is all about the "meta data". Everything you've described in your post is nothing more than data or viewed another way, contextual data. When that data is "aggregated" new and meaningful services can arrive with new revenue models.

    So lets circle all the way back to Brads original problem and see if we now have a solution. The one I propose leverages a Mobile phone. Why? Because it merges content with contact and in essence is a portable connection to the Internet and web services. The issue with the mobile phone (and one that Brad points out) is it's attributes, small screen, no mouse and it's really tough to enter data.

    So the goal is simple – remove the friction in the transaction by automating as much of the data transfer as possible. Ok here goes…

    Brad walks up to the scales which have a NFC (near field chip) embedded in them (or bluetooth works as well). The second he's in range his mobile phone opens up a com port to the device. Brad steps on the scales. His weight is automatically displayed on the cell phone inside the browser which has already launched to his web service. The service knows it's him, knows the time of day, knows where he is and instantly records the data. Zero clicks required.

    The future of the web (IMHO) is "it's the meta data stupid" and the ability to add context around aggregating this data. The mobile phone is going to turn into a tricorder where you will get all of your information. The web will simply know it's me, what device I'm on and exactly where I am… advertising will turn into targeted information and everything will be personalized.

    Customers want three things:

    1. One interface – the browser
    2. One platform – the Internet
    3. Multiple data sets – the context

    Everything you've mentioned above follows the customer – what Steve wanted was a simple platform that required no programming changes to accommodate that – the answer there is put the data inside the HTTP protocol and use CGI to pass it to the web service.



  • Ole Eichhorn

    I've got the #1 cool way to lose weight. I have no idea if it will work for you, but it worked for me. Go to sleep earlier. Really really. Good luck.


  • Brad,
    FitLinxx has some products which solve the Scale to PC/Server issue wirelessly <a href=”http://www.fitlinxx.com/products_list-pub.html” target=”_blank”>http://www.fitlinxx.com/products_list-pub.html
    They also have a pedometer/accelerometer which also wirelessly connects to a PC via USB. The technology for the pedometer is the same technology used by Nike for the Plus One product, as FitLinxx acquired FitSense, the company from which Nike licensed the +1 technology. Products don't yet seem to be web services or developer friendly, although they may have made progress in that area. Not having been in touch with the company for over a year, I am not sure where they are with that. But FitLinxx/FitSense is a company which has been working for a while on making connections between data and fitness.

  • Relevant news item:

  • Peter Cranstone


    Bad URL… do you have another one?

  • Peter Cranstone

    That's exactly what I've been talking about… let's use Brad as the example. He hooks up a heart rate monitor, blood pressure cuff and even a blood sugar meter to his body. Each of these devices communicate to his mobile device which then sends the data directly to any web service (don't need Google and IBM for this).

    For the techies the three headers added to the outgoing web service request would be:

    http_x_brad_feld_blood_pressure="data goes here"
    http_x_brad_feld_blood_sugra="data goes here"
    http_x_brad_feld_heart_rate="data goes here"

    Now all the web service does is read the headers and extract the data.

    Now if you want to have some fun we just need to ask Google and or IBM for some API's to their apps (5o9 already has this built so developers can build their own apps). Now with those API's you simply have the Google app talk to your web service vs. sending all of your data to them.

    This is much more critical in the Enterprise because they really don't want to hand over data to Google or other consumer focused web services.

    This approach even works for the channel who right now are experiencing "compressed" margins and their customers renegotiate over web service costs. They can now offer them a differentiator which brings back the overall margin on the deal.

    Mobile is the perfect conduit to the web. It's personal and it's with you all the time. All you have to do is make the web service aware of your context.

    It's all about the meta data.



  • Thanks for the blast from the past.  I used FitSense for about a year until they went out of business.  I probably still have a FitSense footpad somewhere.

  • This post has been stuck in my head for two weeks because I know this frustration so well.

    In my case I have a cycling coach who sends me workouts using his company's online web app.

    I have used TrainingPeaks for so long that it has a great historical record of my training, so every week I copy and paste all my workouts from the coaching app into TP.

    I also use a Garmin bike computer that is awesome for managing intervals and structured workouts, so in the same weekly session I copy my workouts into Garmin's software to upload to the bike computer.

    At the end of each ride I upload the workout data into TrainingPeaks and enter summary information in the coaching app.

    And still all of this data lives in my workout calendar(s) and not my regular calendar, nor does it have any way to get there except through more copy/pasting.

    Somebody please build something so all these applications can and *will* talk to each other.


  • Lori

    Microsoft HealthVault has recently announced that is is open to anyone who wants to create an app for its program, so perhaps someone will hear your plea. On the other hand, go check out the latest Tanita scale. It works with MS HealthVault, might save you one login!

  • Pingback: DailyBurn and Occipital Team Up to Create FoodScanner()

  • myuggbootssale

    I recommend you go to online store, there have a lot of ugg boots sale,If you want to buy a pair of cheap ugg boots uk.More and more people chooseugg boots uk. So you know that ugg series of the most famous is the ugg boots.air jordan shoes,air jordans,cheap ugg boots

  • Johny

    Many people use the mouse when moving around their spreadsheet. Using the mouse 642-586 exam , though, is the slow way of doing anything on a computer. It's fine if you have only a small amount of data to enter or if you're not in a hurry.1Y0-456 exam

    To speed up your data entry use the keyboard HP0-J14 exam . Below is a list of keys that you can use when you want to quickly enter your data. HP0-D04 exam

  • This is a very good blog site. I have been back many times within the last 7-day period and wish to join your rss using Google but can not work out the right way to do it precisly. Do you know of any instructions?

  • Pingback: Helen Matthews()

  • Pingback: Multisystem 110 220 TV()

  • Pingback: moonshine rum()

  • Pingback: payday loans online()

  • Pingback: all natural nude()

  • Pingback: แทงบอลออนไลน์()

  • Pingback: how to homebrew beer()

  • Pingback: kalendarz do wydrukowania()

  • Pingback: paylaşım()

  • Pingback: zithromax and azithromycin()

  • Pingback: distilling rum()

  • Pingback: Health Conscious Pizza Toppings()

  • Pingback: Pisanie PRAC()

  • Pingback: payday loans online()

  • Pingback: pay day loans australia()

  • Pingback: home distillers()

  • Pingback: stretch wrapping machine()

  • Pingback: vintage car inspection()

  • Pingback: garcinia cambogia iherb()

  • Pingback: sağlık()

  • Pingback: St. Edward’s University Students Reach Out to help the Homeless()

  • Pingback: Virtual()

  • Pingback: Tonale Cream()

  • Pingback: Blogunko()

  • Pingback: wielu ludzi w jednym miejscu()

  • Pingback: Gepatitu net()

  • Pingback: ankara escort()

  • Pingback: my site()

  • Pingback: dreambox()

  • Pingback: filtrowanie wody()