1. 2

    Your mileage may vary, but I found this particular API to be too unstable for any applications that needed solid uptime. Reasonably easy to work with though…perfect for a personal project.

    If you want more options from your weather API (and don’t mind possibly paying), check out http://www.wunderground.com/weather/api/ as an alternative.

    1. 3

      Having used wunderground’s API extensively… It’s godawful. Barely documented, and frequently fails requests for hours at a time. On the upside, their search is pretty decent - I can throw zip codes, postal codes, IATA designators, city names etc. (OpenWeatherMap’s searching could use some improvement in this regard).

      forecast.io was brought to my attention today, as a result of this post, and I’m liking it so far. Great documentation, higher limits, and comparable searchability. Plus their core product is very slick looking.

      1. 1

        That’s a shame! I never got to play with it much, but I just assume (incorrectly!) that paid meant it was also going to be of a high quality =( forecast.io seems worth investigation!

    1. 2

      I can’t speak to whether the licensing change is possible or not, but will say that I am concerned for OSM’s future in the current mapping climate if they don’t get more regular buy-in and use. If you look at the direction Apple and Google have been headed, there’s a huge focus on creating mobile platforms where 1) users are locked (or at least defaulted) into your mapping platform and 2) any interaction, improvements, or feedback are kept to yourself.

      While these choices are perfectly normal and expected for private companies like Apple and Google, it leaves OSM in an awkward position. As long as they are viewed as a sub-par mapping option (whether this reflects reality or not), they will suffer from very little feedback and improvement. Meanwhile Apple and Google are regularly collecting data, improving their own maps, and doing all this with users that might otherwise be contributing to OSM.

      1. 3

        Somewhat interesting post, but it was very unclear to me if the author has actually implemented any of this. It reads like a How-To but if the author hasn’t actually done it the whole post goes out the window.

        But I do really like the idea of services that are in the order of hundreds of lines of code. I’m guessing this general principle plays well with something like Mesos?

        Also, I think the author really underplays testing. The author refers to testing an individual service as not hard, which sounds right, but testing the integration of all of these things together sounds rather complicated, depending on how well you do it.

        1. 1

          Agreed on the lack of a depth. From my personal experience, all the interesting challenges with service oriented architectures were either glossed over or not mentioned in the article. A nice overview, but I want more meat!

          In particular, I would love to hear more detail on the feasibility of the proposed size of these components (~100 LOC). My gut reaction to that number is that it would force you to split up single concerns into a few partial services, just because otherwise you aren’t a micro-service. I’ve always had good luck with making service boundaries correspond to meaningful separation of concerns, even when the resulting component ends up significantly larger.