Last week, I wrote about my desire to make a todo app. this week, I’m going to talk about the technologies I’m using and what I think so far.
Currently, I’m building this app on the following technologies:
Notice any pattern? I am a giant Microsoft shill. My career focuses on Microsoft SQL server and Power BI, so It’s in my best interest to learn surrounding technologies.
Of course Microsoft keeps doing weird things like including Git in Visual Studio, or putting SQL Server on Linux. So the surrounding technologies get a big broader these days.
I really like C#, but I don’t feel like I “get it” just yet. I think it’s clean and understandable as a language, but it feels like 80% of the language is learning about random libraries and classes. And if you don’t know that
I can’t say I have a good idea when to choose between one or the other within a project. It seems like 3 very different modes of working and routing.
Azure is to today what virtualization was 5 years ago. The cloud is just going to keep getting bigger and bigger and bigger. If you aren’t learning about it now, you are going to be very remiss about it 5 years from now.
Unfortunately most of us don’t have a need for cloud hosting. You probably don’t have a need for your own personal Azure Active Directory or Hadoop Cluster. So a lot of times, that means doing projects and labs to learn it preemptively. If you are waiting until it comes up at work, it’s going to be too late.
DocumentDB is… interesting. Brent Ozar mentioned that he is using NoSQL for a new project. He picked Amazon DynamoDB over DocumentDB. I’m picking DocumentDB as a way to learn Azure.
So, why go the NoSQL route? Partly it’s something new to learn, but there are a couple of advantages. I think Document databases when you want to store lists of things or hierarchical data. In my app, I have lists for times of day, task categories, and tools/contexts. I want to be able to do filtering on these things, which can be clunky in SQL.
Things I like
Some other things I like so far are the dynamic schema, dynamic serialization, and TTL. Normally I appreciate have a well-defined structure to my data. However, this is a design that’s constantly evolving and changing. It’s hard to plan it up front. With Document DB, I can add a field to my model class in C#, set a good default, and that’s it. Now I have a due date field
The other thing I like so far is the TTL feature. I can mark completed tasks with a ttl of a week. Then, if I don’t touch them for a week, they will self-destruct. That is a really cool feature.
Things I don’t like
One of my big pet peeves with DocumentDB is that collections are billing containers not logical containers. This to me just seems silly. If I want to have different types of objects, such as summary data, I have to store them all in the same place or pay 2-4x as much. That approach feels really messy.
Another thing that’s an issues is case sensitivity. Because it’s a dynamic schema, if I get a column name wrong, it won’t tell me I screwed up. So I have to remember if my columns start with a capital or not. Also, if I do a contains I have to get the case right for that as well. This is more of a mindset shift than an actual issue with Document DB.
Finally, because it’s JSON there isn’t a date standard. C# does a great job of serializing and deserializing things. However, if I want to store the dates in a human writable way, I have to find another option. For all of my pure dates I’ve been using an integer for now. So September 11th would be 20160911. It requires an extra step to convert or add days to a date, but at least it’s easy to edit. Additionally, because it’s an int, it allows for range filtering.
Xamarin technology is pretty exciting. I absolutely love the idea of being able to write C# and deploy it to a bunch of platforms. It’s especially exciting because my phone is a great place to run a todo app.
That being said, if understanding C# is difficult, then understanding C# that’s a thin wrapper on Java is even worse. I am finding the learning curve on Xamarin to be a bit difficult.