Windows Phone 8, will it finally make it?

I have been waiting for the version 8 of my favorite mobile OS and now when they showed it my feelings are a bit mixed. The main thing that stirs up my feelings is that you cannot upgrade a 7.5 telephone to Windows 8.
I didn't expect this from Microsoft. The early rumors where hinting that you would be able to upgrade your Lumia to the new OS. On the other hand, with a bit retrospective and with the talk of using parts of the Windows 8 kernel in the phones, I should have guessed.

This will on the other hand give me an edge in the ever ongoing "who has the coolest phone in the office"-competition, their Lumias will only make it to 7.8...

Every cloud has a silver lining...

So for the truly good news?

Version 8 finally gets a chance to compete with other smartphones when you just check the hardware specs.

It gets the multi-core processor, high resolution screens, true multitasking, integrated skype, offline maps.  The best and in my point of view, a critical must for the success of Windows on the phone is that it will share code with Windows 8. In effect this will mean that Microsoft is choosing one road for all its devices. It is Windows 8 from phone to Server. This also gives me confidence that Microsoft will not to as they do with Windows Phone 8 again, namely cut off their existing user base.
This seems like a long term strategic choice and even though it has a slightly bitter aftertaste it still is needed in the long run.

So will there be a long run?

I still believe that Windows 8 will make it. It simply has features that makes it so much more powerful than the iPad or the Android tablets. It is a real computer. And I believe that Windows 8 will be the beast that will pull the Windows phone.

I hope so.

Windows Phone 8 is just too sexy to disappear. Just look at those nice square things on the screen!

Philosophy, technology, religion

Sometimes programmers are strange, actually most of the time programmers are strange.

Me included.

And maybe this is just my twisted and over-simplified view on the subject, but I see a clear line between the developer with a philosophical view on the subject and those with a more technological take on it.

It is a division that can be seen all the way from the universities split in educations for system sciences and those for software engineers.

Philosophers seeks the best way to split reality into parts, engineers tries to make the best parts to resemble the world. Top-down and bottom-up. People that are specialized in abstracting and those that are experts in coding.



Both sides are needed, but problem's arise when coders forget that that is a fact and adopt a one way minded view of the subject, often with an almost religous conviction.

Give programmers a buzzword and they will follow.

The technological religions seems to dominate right now. Most of the new methods and patterns results in a bottom up approach to development. An alluring belief that following a path can create the perfect system.

There are definitely religious philosophers too, an architect colleague to me once said that "when you construct a system, the most important is to be as flexible as possible and you achieve maximum flexibility by not constructing anything.".

The scary part was that he meant it.

The good thing, that he eventually got fired.

I went to a (for me too short) seminar with Chris Klug about the problems with the Test Driven Development (TDD) paradigm and got inspired.

TDD has a religious following in that the users seem to believe that every project gets better if you follow it strictly, the code gets better and the solution gets better. Use tests everywhere and you will see the light.

Lately, I have heard the same opinions about a lot of technologies and methods and if I look back I have heard the same statements before about older technologies. Some people seem to believe that the solution of all problems in the world lies in a three letter acronym.

CQRS, TDD, Scrum, ORM, Functional programming, Object orientation, SOA, Sql, NoSql, Open Source...

There are grains and sometimes tons of truth in all methods, but in my world they are just pieces in the big jigsaw puzzle. Use it, but don't be a Taliban.

Each tool has its place and a time when it should be forgotten.

The goal is to make a good system not to use a certain method or technology.

No method will do the work for you.

Amen...

A small break

Recording music with ÜNF this week, so no updates in the blog.

Will try to do some coding this weekend.

Spatiality Part 4, Fiddling with SQL Server Spatial SQL

SQL Server is quite potent when it comes to spatial queries. It follows the Open Geospatial Consortium Simple Features for SQL, Version 1.1 and implements about 70 functions covering areas such as intersects, unions and the like. Basic GIS-stuff.

It is a bit different syntax from what most people are used to, but once you get past that it's a breeze.

SQL Server 2008 supports two kinds of spatial data.

Geometry, that means flat.
Geography, that means spherical.

I still believe that the world is spherical even though I read a lot of hard evidence suggesting otherwise here. 


So I would choose the geography style. However, all my data is flat so...


In my spatial database I have lots and lots of areas. And it would be nice to get all areas within say 20 km from my position. (I can't believe some third world countries still hang on to miles)


You can probably do this the hard way and use a lot of math to get an answer, or you can do it the GIS way.


GIS (Geographical Information Systems) is a neat science. One of its strengths is to get new information by making calculations on thematic layers on a map. For me it started with reading the book Map Algebra by Dana Tomlin and I was hooked. If you are interested read more here.


Spatial SQL is a bit different but you can achieve a lot by using similar techniques.

Back to the task.


My plan is as follows:

1. Create a geographical area covering a 20 km circle with it's center in the middle of stockholm.
2. Use that circle to overlay my data and by SQL return all the objects that intersects my buffer.
3. Show it in my blog.

Let's start with number one in the list.

DECLARE @stockholm geometry = geometry::STPointFromText('POINT (18.06861 59.32944)', 4326)

So... what do we do here? We (or actually I) create a point geometry by using the geometry::STPointFromText function. As parameter we have the coordinates as a string followed by the mystical 4326 which simply points out that we are using the reference system WGS84. The same reference system as my own data.

This will give us a one dimensional point.


To make it into a circle we use:

DECLARE @stockholmbuffer geometry = @stockholm.STBuffer(0.2)

We simply tell SQL Server to make a buffer around our point with the distance 0.2. 

The distance on my map is in degrees. Lats and longs. 

And a degree is around 110 km and 20% of that is just close enough 20 km to make me happy. 

I'm not picky.

So now we have declared a 20ish km radius circle with its center in Stockholm.

Next step is to overlay it with the existing data.

This is how we do it:

SELECT *

FROM areas

WHERE ogr_geometry.STIntersects(@stockholmbuffer) = 1

Just a simple call to the intersect function that returns 1 on an overlap.


So to summarize:


DECLARE @stockholm geometry = geometry::STPointFromText('POINT (18.06861 59.32944)', 4326)


DECLARE @stockholmbuffer geometry = @stockholm.STBuffer(0.2)

SELECT *

FROM areas

WHERE ogr_geometry.STIntersects(@stockholmbuffer) = 1

And the result is this:

Spatiality (a short interlude with a hint of bitterness)

Importing data to SQL Server needs its own entry in this blog. Especially when it comes to international characters. You know: 'Ö', 'Ü', 'Ñ', 语 and the likes. I am talking about UTF-8, UTF-16 and other ways to map a character to bits and bytes.

Character encoding.

The problems started in 1963 with ASCII (and probably earlier in the analog world with Morse codes, viking runes and smoke signals). ASCII and IBM's ECBDIC managed to fit a character into seven and eight bits respectively. Memory space was a very limited resource those days so all was good until someone realized that there actually exists other languages than English and they tried to hack it into ASCII using ISO 8859.

This time they forgot small regions such as the Arabic world, Japan, India and China...

1988 they finally started working on UNICODE and nowadays we only have one way to save international characters: UTF-8, UTF-16 and UTF-32...

Most stuff you find on Internet is UTF-8, SQL Server handles UTF-16 and when you import stuff into the database without spending an hour of googling ahead of the task everything ends up in the non UTF fields called varchar...

Some people probably love code pages and character encodings. I don't. For me it is one of those totally uninteresting side issues that distracts my creativity from really achieving something. It is fully in the line with issues such as coordinate transformations, spending time fixing web stuff to make it readable in any browser and trying to access web services not made for Microsoftians as myself.

I hate it.

Give me one type of coordinate, browser, service and one type of string!

I want to use my brain for content and functionality, not details.

So... this long rambling obviously cooks down to the fact that I goofed up and managed to import all that data in spatiality 3 to a varchar field instead of an nvarchar field. And as I have a blog I have the opportunity to channel my bitterness...

Getting the stuff all the way to Azure made it even less interesting to go through the whole process again and try to import the data 'the right way'.

So I googled.

Ye who google shall find.


I found this. A function that fixed my mistakes and saved a good day of work for me. I just added an nvarchar to the table, updated it with the function and dropped the old one. Worked like a charm.

I love google and I love people like Jason that cleans up after my mistakes. Thank you!

Spatiality Part 3

Finally, after a barrage of work, I have the possibility to do some own coding and make one more step toward finishing my next app.

So... were are we?

In part 2 I finally managed to export a shape file to Sql Server 2008, this time I plan to export that spatial data to my Azure SQL.

So what to do when you start with something you never done before?

Google!

My first finding was this link. Since I enjoy simplicity the Import and Export Wizard sounded perfect. I've used it countless times before and it has never failed me.

I follow the steps, opens up an ip address to azure and everything works brilliant until I get to the Review Data Type Mapping phase, when the wizard gives me something like this:

Reason? The Import and Export Wizard can't export spatial datatypes...

So time to google again!

This time I found the SQL Azure Migration Wizard.

This tool has a bit of crappy GUI (I use the 125% size on text and it doesn't handle it). But i transfers data using Bcp so I had least hope of getting it to work.

My first attempt crashed, another googling and I realized that I needed to upgrade my SQL Server to service pack 1.

I tried again and this time:

I ran  a query agains the table in SQL Server Management Studio and lo and behold, all is there!

Next up: exposing the data through an azure web service.

PS. If you like sharepoint follow this!

Another don't in SQL Server...

Found out the hard way that it's not a good idea to rename your default data base in SQL Server 2005 (yeah, some of us still work with ancient technology).

If you do, you will be stuck for some time googling and guessing sqlcmd commands. More info here.