Last week a very nice thing happened with me. Two of my colleagues asked my advice on analyzing corner cases.
How to make the roads better?
What about roads on a map?
Read to learn what graph (and non-graph) algorithms we implemented to make the roads good.
One particularly nasty and cold day, in the middle of February, our users, cartographers, came to visit us, developers. And they looked worried.
We offered them hot tea and chocolate candy. By gentle nudging and careful questioning we managed to understand what was bothering them.
They wanted the roads to be good.
When I read an article or a book about architecture, framework, approach, or tool – I focus on “why” it was built or applied one way or another. Not “what” they did, not “how exactly” they applied it – but “why”. Read here to know “why” I think it’s important.
What interests you when you read an article or a book about an architecture of some big system, or about new frameworks, or design patterns, or some new fancy tools?
To me, the most interesting thing is why they did it like they describe.
Bad-ass development of scalable systems with lots of user requirements, tight schedules and limited resources? Ask me how!
This is the first article in series about building a Geo Information System. Here I’m going to tell you about user requirements we gathered before we rushed into development.
I’m starting a series of articles about building a geographic information system, or GIS-system. With a great team of smart and very dedicated developers, we created a robust scalable solution that our users were happy with. Or, almost happy. You can never make users completely happy. Sigh.