So up until now I have focused on my most comfortable zone, the back end of this project. This post will shed some light on the front end. Or at least the bit where most users will be directly interfacing with. I have kept this really simple for now - I did not focus on the autheentication part or any customisations (that will come later). For now I have focused on parsing and displaying the feed sections, the channels from which we get the news so your BBCs, Guardians, and so on. And then…

Last time out I wrote a little bit about starting my feed reader project. As I continue to work play with this project, I have come to that point where I am thinking about securing these endpoints a bit. We have to remember that this is going to be feeding a mobile application and as such, I can’t really pin down the source requests… CORS might be a problem at this point.

I used to love Google Reader. I used it everyday to keep up to date with those tech sites that i subscribe to. I really liked how it worked… And then they shuttered the service and applications and suddenly I was out there looking for alternatives. Feedly is a good alternative, but this got me thinking, as I have been playing with mobile application development for a while, what if I built my own feed reader?

In part one I blogged about the motivation, and the audience for a data catalog (Atlas). This time I will be talking about the approach, the lay of the land, and hopefully describe the system design and reasons that drove the decisions we made.

In my previous role as Team Lead for the Big Data Team, at the top of my remit was to deliver a Data Catalog. In ernest we started working on bringing together the entire company’s data estate under a catalog. Searchable, accessible, and updateable in a democratic manner.