codecentric

MongoDB 2.4 Introduces Geospatial Indexing and Search for GeoJSON Geometries Point, LineString and Polygon

March 6, 2013 by

In case you are unfamiliar with the geospatial stuff, have a look at this introduction to geospatial indexing and searching with MongoDB.

In version 2.4 MongoDB introduces support for a subset of GeoJSON geometries. These geometries can be used both as data and query expressions.

GeoJSON

GeoJSON is a specification for describing geometrical shapes with the help of the JSON (JavaScript Object Notation) format. The basic shapes are points, line strings, polygons and compositions of these shapes. Here are some examples:

// a Point object
{ type: "Point", coordinates: [0.5, 0.5] }
 
// a LineString object
{ type: "LineString", coordinates: [ [100.0, 0.0], [101.0, 1.0] ] }
 
// a simple Polygon object, a box
{ "type": "Polygon",
  "coordinates": [
    [ [0.0, 0.0], [1.0, 0.0], [1.0, 1.0], [0.0, 1.0], [0.0, 0.0] ]
    ]
}

GeoJSON Support in MongoDB

Prior to version 2.4 geospatial data in MongoDB was solely points. You were able to index points denoted by a two-dimensional array ( [1,2] ) or an embedded document with two fields ( {x:1, y:2} ). By using GeoJSON geometries you …
(read more…)

Tobias Trelle

* category: Big Data, NoSQL | * 4 Comments so far
This post is written on March 6, 2013 by

 

The CenterDevice Cloud Architecture

February 14, 2013 by

In this post I want to give you an insight into the architecture of CenterDevice, a document management and collaboration tool for the enterprise hosted in our own cloud datacenter in Germany. CenterDevice is a startup of codecentric, with a few codecentrics working full or part time on it.

Let me start with a screenshot from our AppDynamics monitoring.
centerdevice-architecture
(read more…)

Fabian Lange

* category: Cloud, Performance | * 4 Comments so far
This post is written on February 14, 2013 by

 

Business Architecture for IT-Dummies

January 24, 2013 by

Stop, stop, stop, and please don’t go away! I know, you have seen the word „business“ in this title, and as a technical guy you have thought „thanks, it’s nothing for me”, but please give me a chance to explain why this topic is so important for you and us, IT architects, developers and testers.

We all love agile software development. It empowers teams that work in a close contact with the stakeholders, reacting on their feedback and delivering iteratively and incrementally product increments. However if we look at this “close contact with the stakeholders” we can oft assess that our “close contact” and as a result the information scope and the quality we can get, is quite “limited”. Mostly, we have only contact with one person who is responsible for the definition of all requirements (is he or she a product owner in case of Scrum or a business analyst or a product manager in case of other frameworks, it doesn’t matter). Because it is just one person, it is very seldom that he or she has holistic (means ultimate) view and understanding of the customer’s business. And this understanding is one of the key concepts needed if we want to deliver a good product and have a satisfied customer at the end of the project.

Only if we understand what we do, we can do it effectively.

The fastest way to understand something completely new is to analyze the model of it. In case of a software system, if we want to talk about its model, we have to talk about its architecture. One of the well-known frameworks allowing almost complete description of the software architecture is the “4+1 architectural view model” designed by the P. Kruchten:

20130123 CC Blog Business Architecture for IT-Dummies Figure 01

This model contains 4+1 views allowing description of the various aspects and requirements of a software system:

  • Scenarios represent well-defined interactions between external actors (users or systems) and the software system;
  • Logical view is concerned with detailed functional requirements;
  • Process view aka Quality view deals with the quality requirements (and btw. has nothing to do with the processes as such);
  • Physical view aka Deployment view describes the environment into which the system will be deployed and its dependencies;
  • Development view, as easy to presume, describes the system from the development point of view, including technologies and frameworks.

I use this model in a gently modified form (with some additional views) very often in my projects, because it makes me confident that I haven’t forgotten any important or even critical architectural aspect. I can only encourage you to do it as well.
(read more…)

Adam Boczek

* category: Agile, Architecture | * no comment
This post is written on January 24, 2013 by

 



Publikationen