Really nice idea. I think it applies equally the other way too, my wife is quite tricky to buy for and it is nice to have a concise list of ideas like you've presented.

Two email lists I am on for ideas (that you could no doubt use to help have a few more options) are Uncrate and Fancy - daily emails with great ideas. Similar to what you are doing, but you've made it super easy.

PS. rather than Hobby Project shouldn't this be Show HN?

Cool idea and seems to work, but might be good if it was activated by pressing a button rather than just a visit to the page - I am now logged out of a number these services just because I visited the page - which is not really what I wanted!

Another take on this sort of thing: http://app.dumpark.com/sunlight/

The guys behind this apparently wanted to know the best place to go for a beer at any time of the day. They use the zenith of the sun, the surrounding landscape and the surrounding buildings and have it modeled throughout the year. I think they then realised there may be more useful ways to use this data.

A bigger issue to me is what do you do with Lily after it has run out of battery. I don't think I want to carry it for the rest of the day on the ski fields, mountain biking, trail running or anything else, it is fairly cumbersome. And I wonder how tough it is when it is in a back pack and I fall and land on it.

Very cool device and it would have a lot of practical uses, but not sure it will ever be that useful for the masses.

As a kid in the 1970's living in New Zealand most of our local apples (NZ grows a lot of apples) were green. Imported Red Delicious used to sit in the supermarket looking so red and beautiful and screaming to be purchased, which occasionally I could get my mother to do. I don't remember them being floury, but they were always sweeter than the green apples - a real memory of childhood.

But now in comparison to Gala, Fuji, Braeburn and others, Red Delicious seem floury, the skin is too thick and the flavour no where near as crisp and clean as the other varieties. There's also a lack of airmiles on most of these as we grow them here.

35 years on I don't think my kids have had a Red Delicious, and certainly not something I will miss if I never have another one.

I would assume because PostgreSQL (the DB he is using) doesn't support importing from JSON?

But why not use a JSON parser?

The dude had a whimsical idea, tried it out, and wrote it up for our enjoyment. Let it go. Maybe he will parse the JSON next time.

Next you're going to say you didn't build Pinboard with Angular, or something crazy like that.

if you're driving a nail into soft wood, you could use a hammer... Or you could just use a rock, or another piece of wood, or....

Using the wrong tool for a really easy job can sometimes be faster than the minimal effort of getting the right tool ready.

The regexp must have taken some time to write and debug:

s/^."n":"(.+)","i":"(.+)","p":\[([\d\.\-]+),([\d\.\-]+)],"s":"(\w+)","c":"(.+)".$/\1,\2,\3,\4,\5/;

I've been a Perl programmer and regular expression user for over a decade. It didn't take long and if you use them regularly, it's second nature. I agree, I could have used a JSON parser, but the source was well-structured and sed seemed easier. PostgreSQL can import JSON, but I haven't had a good experience with it so far.

You put together a really awesome project! Kudos on that and for sharing it first and foremost!! I speak regex pretty fluently, and I may very well have reached for sed/perl -ne there as well, depending on mood. I guess it just struck me as odd to use a parser for XML but not JSON. Anyhow, off on a tangent, I recently learned about a program called xgrep that lets you pull elements out of XML using xpath or pcre (althought pcre support was kind of spotty for me)--it's neat for one-offs like this and pipeline building while playing with rest apis and such!

He could also have had that sitting around from a recent project.. it doesn't really seem worth second-guessing.

It's actually pretty easy and quick to write when the data is highly regular (no pun intended!). You can write this kind of expression by taking one of the lines of input:

   {"n":"Homewood","i":"inns_suits","p":[33.455237,-86.81964],"s":"AL","c":"1"},

and then making a regular expression that matches that line literally [1]:

   m/^{"n":"Homewood","i":"inns_suits","p":\[33.455237,-86.81964\],"s":"AL","c":"1"},/
     _                                     _                    _

Then replace the parts that will vary with regular expressions to capture them. We want to capture the "n" field:

   m/^{"n":"(.*?)","i":"inns_suits","p":\[33.455237,-86.81964\],"s":"AL","c":"1"},/
            _____

and the "i" field:

   m/^{"n":"(.*?)","i":"(.*?)","p":\[33.455237,-86.81964\],"s":"AL","c":"1"},/
                        _____

and the longitude and latitudes from the "p" field:

   m/^{"n":"(.*?)","i":"(.*?)","p":\[(.*?),(.*?)\],"s":"AL","c":"1"},/
                                     _____ _____

and the "s" field:

   m/^{"n":"(.*?)","i":"(.*?)","p":\[(.*?),(.*?)\],"s":"(.*?)","c":"1"},/
                                                        _____

We don't care about the "c" field, so I'm going to drop it:

   m/^{"n":"(.*?)","i":"(.*?)","p":\[(.*?),(.*?)\],"s":"(.*?)"/

If we want to be fancy, we can make sure that the latitude and longitude consist only of digits, decimal points, and minus signs:

   m/^{"n":"(.*?)","i":"(.*?)","p":\[([\d.-]*?),([\d.-]*?)\],"s":"(.*?)"/
                                       ____       ____

For a one time thing like this, I'd probably deal with this data with a pipe in the shell, rather than use regular expressions:

   tr : , < in | tr -d '[]' | cut -d , -f 2,4,6,7,9 > out.csv
 

[1] I shall use Perl regular expression

Maybe, if you're doing it all at once. I often use my text editor as a regex platform, using the Find/Replace menu to dice off chunks of text in a series of quick and easy operations, using UNDO if I get one wrong. It's really very quick if you don't force yourself to do it in one step.

I guess, but honestly using a JSON parser sounds like less work. I mean, using regexes for this quick job is fine, it just sounded weird.

On the one hand I agree with the "It doesn't matter here" crowd, but on the other hand, Python (only language mentioned in the article) has a json library in the stdlib, and it's certainly easier than doing it with regexes.

So, it doesn't matter much, but it was an odd choice.

Even if it's in the standard library, it still might be more work to find where it is in the standard library than just do it the way you already know how.

Agreed... It's a devil you know vs. the "oh I'll just use this other library to do $simple_thing, how hard can it really be?" Hours later you realize that you didn't think it completely through and it's a bit tougher than you thought.

>it's certainly easier than doing it with regexes.

... for you.

It depends on the version. More recent releases (that is, >= 9.2) do have native JSON support, but it's still young — though steadily improving.

Yup, I've done a bit with 9.2, and it accepts JSON just fine (although not with automatic string conversion) but it's a short road to wishing the data were in standard tables and columns.

Use dollar-quoting for automatic string conversion:

insert into my_table values ($$ json_goes_here $$);

Works for all stringy things.

Cool, thanks. Last time around I used a pg-driver-specific datatype to hold the parameter on its way through sql2o, and felt rather guilty about doing so.

Add Excel spreadsheets and Access databases to that list. Best thing, someone else has already proven their is a need for the system and a working solution!

Two ways I can think of. 1. You do a real job for a while. Work in a large organisation, see what pain points they have, which ones are probably similar to other businesses and which ones probably don't involve terabytes of proprietary data that they would never be able to shift to an SaaS solution (by never I mean politically not technically). And I don't mean working for tech firm. Be on an IT team for a pharmaceutical company, a food company, packaging company, logistics etc. Be open and offer to help people (outside of IT) and you'll be amazed what ideas they give you.

Way 2. Mix with people in the real world that work in the companies above. Listen to their problems, offer solutions, offer to pop in after work one day or on a weekend and look at their problems.

I'm working on this exact issue with a delivery company currently. The biggest question they have is "would you pay for it?". Would you pay extra to receive a message to advise of delivery time, and would you pay extra to have that delivery delivered at another time or elsewhere?

Whilst missed deliveries are costly they obviously don't feel that is justification enough to develop a better solution.

My own personal opinion is no, I wouldn't pay for this service. However, maybe the costs can be driven down by simplifying the solution. Instead of 'deliver wherever the customer wants,' only present the customer three options: 'Receive at home,' 'Receive at work,' 'Don't deliver, I'm out of town'. This solution perhaps reduces the complexity in customizing delivery location (fewer possibilities), pushes down delivery costs (fewer missed drop-offs), and increases customer satisfaction (receive package with less hassle).

Some of the consumer delivery firms that Amazon use in the UK have started texting the night before (or early on the day) with the option to either delay delivery or to deliver to alternative -- but the alternate delivery address must be in the same postcode (between 1 and ~20 houses) so no re-routing is required.

In New Zealand there have been 30 deaths since 2000 (http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objecti...), a country of 4 million where like the US most people have a driveway (as opposed to Europe where most people do not). The article claims this move might save 59-69 deaths per year, which would indicate that at least that many die each year (although I struggle to believe cameras will save that many).