# Saturday, 04 July 2015

I am here today to urge you to use the "Tentative" response in your calendar program when it is appropriate.

Firesign I see too many people blindly accepting every meeting request they receive - even those they know they will not attend. Many of you - and you know who you are - have multiple meetings booked for the exact same time. As the philosophers at Firesign Theater so eloquently put it: How can you be in two places at once when you're not anywhere at all?

There are 3 primary advantages of using the Tentative response:

  • Organize your time better
  • Courtesy to the meeting organizer
  • Assist others in finding free time on your calendar

Organize your time better

This should be enough reason for you to use "Accept" when you mean "Accept" and "Tentative" when you mean "Tentative".

Each morning (and often the night before), I check my calendar to see what my schedule holds for the day. My calendar is often full, but not every event on it requires my attendance. Knowing which ones I need to attend and which ones I might attend makes it far easier for me to plan my day.

Accepting an appointment marks it as "Busy" on my calendar, while tentatively accepting an appointment marks it as "Tentative" on my calendar. In the Outlook calendar, each status displays with a different pattern (solid for Busy; hashed for Tentative). These patterns make it easy to see at a glance where I'm required to spend my time and where my attendance is optional, which helps me to set priorities.

OutlookCalendar

Courtesy to the meeting organizer

Meeting organizers often rely on your response to determine whether or not you will attend. Sometimes, they are counting on you to share your insights with the rest of the group or to answer one or more specific questions. If they expect you to attend and you do not, it may throw off their agenda. They may need to schedule another meeting as a result or get your information via a series of (inefficient) emails or phone calls. It's common courtesy to be honest about whether or not you intend to be at a meeting. If you are unsure, let them know via the "Tentative" response.

Assist others in finding free time on your calendar

I recently tried to find time on a manager's calendar but I was frustrated that her entire calendar was marked "Busy" for every working hour of every day of the next 5 days. Of course, this person wasn't committed to all those meetings and did not intend to attend them all; but she didn't distinguish between required and optional meetings, which made it more difficult for me to find free time on her calendar. Marking your calendar honestly makes it easier to collaborate with others in your organization.

Sometimes, I still double-book time on my calendar. But when I do, I never make both appointment "Busy" or "Accepted".

My company offers a lot of online "meetings" that are actually training sessions, where one of my colleagues will show the rest of us how to use a cool technology. I want to attend as many of these as I can, so I want them on my calendar. But I recognize that a higher-priority meeting may force me to skip a session and watch the recording later.

The "Tentative" status works for these scenarios. Use it. You'll be glad you did. And so will your colleagues.

Saturday, 04 July 2015 23:54:06 (GMT Daylight Time, UTC+01:00)
# Tuesday, 30 June 2015

Recently, I interviewed Jeawy Jang and Tae Tongnussock, two students from Thailand who built Den-Lin  - a mobile application designed to test the composition of soil. The application placed in the Imagine Cup competition last year.

Here is that interview on DevRadio.

Tuesday, 30 June 2015 10:39:24 (GMT Daylight Time, UTC+01:00)
# Monday, 29 June 2015
Monday, 29 June 2015 14:02:00 (GMT Daylight Time, UTC+01:00)
# Wednesday, 24 June 2015

With a mere 135 pages, Orchestrated Knowledge by Peter Leeson doesn't appear very substantial at first glance. But Leeson packs a lot into a small package. The book describes ways that companies can improve their quality and productivity. Leeson distills his decades of management consulting into a set of brief chapters describing the mistakes he has witnessed at various companies and recommendations for correcting these mistakes.

Leeson talks a lot about quality. He writes:

"The first thing that we need to consider in any organization is that quality is the most important thing. The quality of your work defines you. Whoever you are, whatever you do, I can find the same products and services cheaper somewhere else. But your quality is your signature."

PeterLeeson According to Leeson, Quality is achieved by people - not by tools, as so many believe. He urges organizations to empower their employees by listening to their ideas and allowing them apply their own creativity in performing their jobs and directing changes about their area. Employees will be happier and happier employees tend to be more productive and produce higher quality goods and services. Most organizations avoid this because they fear the risk of exposing flaw in their system and because they don't trust their employees.

OrchestratedKnowledge Communication is a large focus of this book. Employees lose motivation when they don't know why changes are implemented, what goals the company hopes to achieve, and what projects are coming in the future. Communicating with employees not only empowers them, but allows them to focus their energies on the best way to solve problems, rather than on performing a set of rote tasks.

The largest chapter describes what Leeson calls the "Orchestrated Knowledge Organization", which breaks the company into cells - each with a specific set of responsibilities and an area of quality on which to focus.

Leeson advocates evolutionary change over revolutionary change - keep what works in your organization and build on it, rather than reconstructing everything - a high-risk strategy that is difficult to adopt.

Orchestrated Knowledge does not provide many step-by-step instructions for your company to follow. But it does provide a lot of guidance that you can apply to your own organization to avoid mistakes and make it more successful.

 


Links

My interview with Peter Leeson, May 2014

Peter Leeson’s blog

Wednesday, 24 June 2015 15:37:55 (GMT Daylight Time, UTC+01:00)
# Tuesday, 23 June 2015

The past few years, I've heard a lot about something called NoSQL. Some people really love it. Those who love it, talk about its lack of ceremony and the speed with which you can develop and the speed with which it reads and writes and its scalability. It sounds all sounds so awesome!

But I grew up on relational databases. My first computer language was FoxPro, which included a relational database and supported a powerful version of SQL. From there, I graduated to SQL Server and I've dabbled occasionally in Microsoft Access. I've even worked with Oracle and MySQL and, as a developer, I find them intuitive. Should I abandon the databases with which I am familiar and travel to this brave, new world of NoSQL? Is NoSQL the best solution for every project? For some projects? How do I know?

Let's start with a definition for NoSQL. This is harder than you might think, because NoSQL databases are basically defined by what they are not. The only real definition is that they are not SQL databases. They tend not to have pre-defined schemas; they tend not to enforce relationships; and they tend to be able to store hierarchical data; and, of course, they tend not to support the SQL language (although some support syntaxes similar to SQL, such as LINQ). These are broad definitions and only address things that NoSQL databases don't do. There is no standard language, syntax, storage mechanism, or API for addressing NoSQL databases.

For purposes of this article, I'll define SQL databases as those in which the database engined provides the following features:

  1. Supports SQL
  2. Enforces pre-defined schemas
  3. Enforces referential integrity among related, normalized tables

This includes database engines supported by large companies, such as Microsoft SQL Server and Oracle, as well as Open Source databases, such as MySQL.

I'll lump all other persistent storage technologies as NoSQL databases. This includes MongoDB, RavenDB, Azure table storage, and DocumentDB.

So when should we choose good old SQL databases and when should we use this newfangled NoSQL thing?

Let's start with SQL databases. They have a few advantages:

SQL databases

Advantages of SQL DBs

First, they are relational, so they make it easy to normalize your database into a set of related tables. This almost always saves disc space and often makes your data more consistent (e.g., you can change the name of a product in one table and it changes throughout your entire application). Databases like this also allow you to create persistent relationships between these tables and these relationships enforce referential integrity, ensuring that we are not left with orphaned records (Who wants an order line without a corresponding order?)  You can set up cascading deletes or force users to create and delete records in an order that will never have inconsistent data.

The SQL language itself is very flexible, allowing users to create either pre-defined or ad-hoc queries against a relational database. This makes SQL databases great for reporting.

The schema in a SQL database helps catch errors in almost the same way that a compiler or a unit test does. If you want to capture a customer's last name and you create a “LastName” column, but one time you accidentally misspell it as "LastNmae", the database will catch this and throw an exception which should be early and obvious enough for you to fix the error.

Disadvantages of SQL DBs

But these features come at a price. There is overhead in enforcing database schemas and referential integrity. As a result, saving to a SQL database tends to be slower.

Also, when developers build an application intended for human interaction, they almost never structure normalize the application's objects in the  way that they normalize the data in their relational database. An entire class of Object Relational Mapper (ORM) software exists simply to deal with this mismatch. It requires code, time, and CPU cycles to map between objects in an application and data in a database.

NoSQL databases

Advantages of NoSQL DBs

Because NoSQL databases don't need to enforce schemas or relationships, they tend to perform faster than their SQL cousins.

Database development tends to be faster because developers and DBAs are not required to pre-define the columns in each table.

The lack of database relationship enforcement also makes it easier to move parts of a database to another server, which makes it easier to support very large data sets. Relational databases can move across servers, but it tends to be more difficult because of their need to enforce referential integrity.

The lack of schema also adds flexibility, especially if you are capturing data in which different objects may have different properties. For example, a product catalogue table may contain some items (such as computer monitors) for which diagonal size in inches is an important property, and other items (such as hard drives) for which capacity in GB is an important property. Mapping these disparate needs to a relational database table would be add complexity to your data model.

Finally, it is possible to serialize and de-serialize objects in the same format that they are used in an application's user interface. This eliminates the need for an ORM, which makes applications simpler and faster.

Disadvantages of NoSQL DBs

When reading data, NoSQL databases tend to be very fast, as long as you are looking up rows by an index or key. If you want to look up a row by any other property or filter your data by a property, this often requires a full table scan, which is very slow. Some NoSQL databases allow you to create index on non-key rows, which speeds up such searches but slows down data writes - decreasing one of the advantages of NoSQL.

Other factors

It's worth looking at the cost of any database solution. For example, Azure provides both SQL and NoSQL databases as a service. If we compare the cost of Azure SQL Database with Azure table storage (a NoSQL option), we can see that the price of table storage is far less than the cost of SQL Server. Table storage might not be the answer for your application, but it's worth examining whether some of your data can work with Azure table storage.

Conclusion

As with most questions facing IT developers, architects and managers, there is no clear-cut answer to whether to use SQL or NoSQL databases. SQL databases tend to be better when ad-hoc reporting is required, while NoSQL databases tend to shine when saving and retrieving transactional data from a user application. Many applications take advantage of the features of both database types by creating a NoSQL database with which their application interacts; then transforming and regularly copying this data into a relational database, which can be queried and reported on.

There are many options for your persistent storage needs. Choose the right one for your application.

Tuesday, 23 June 2015 14:42:00 (GMT Daylight Time, UTC+01:00)
# Monday, 22 June 2015
Monday, 22 June 2015 14:24:00 (GMT Daylight Time, UTC+01:00)
# Friday, 19 June 2015

At IT Camp in Romania last month, I delivered a session on Azure Mobile Services and I sat on panel titled “Cloud for Business”. The conference recorded each of these sessions and made them available online. You can view them below:

ITCamp 2015 - The Hitchhiker's Guide to Azure Mobile Services (David Giard) from ITCamp on Vimeo.

 

ITCamp 2015 - Cloud & Azure Open Panel (Andy Cross, David Giard, Radu Vunvulea, Petru Jucovschi, Mihai Tataran) from ITCamp on Vimeo.

You can view all the sessions from IT Camp here.

Friday, 19 June 2015 01:32:52 (GMT Daylight Time, UTC+01:00)
# Wednesday, 17 June 2015

The Null Coalescing operator has been around since the early days of C#. Yet it still remains unused by most developers. I'm guessing this is because they are unaware of it, rather than deliberately rejecting it.

The operator is simply a double question mark ("??"). Some people refer to it as the "Elvis Operator" because, if you squint your eyes just right, the curvy parts of each question mark resemble the waves of singer Elvis Presley's famous pompadour-style hair while the dots resemble his eyes.


The King

The operator takes 2 arguments and returns a single value. If the first argument is not null, the null coalescing operator returns that argument; otherwise, it returns the second argument.

This is clarified by the following 2 examples

String a = "first";
String b = "second";
String c = a ?? b;
Console.WriteLine(c);
// Output: first 
 
String d = null;
String e = "second";
String f = d ?? e;
Console.WriteLine(f);
// Output: second 
 

Of course, the code snippet

String f = d ?? e;

is identical to the following:

String f = "";
if (a == null)
    f = e;
else
    f = d; 

The arguments must be nullable and the examples above work because "string" is nullable by default. You may need to use the nullable version of other data types as in the example below that features integers.

int? g = 1;
int? h = 2;
int? i = g ?? h;
Console.WriteLine(i);
// Output: 1 
 
int? j = null;
int? k = 2;
int? l = j ?? k;
Console.WriteLine(l);
// Output: 2 
 

You can even use this operator with custom classes and objects, as in the following example.

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
} 
 
class Program
{
    static void Main(string[] args)
    {
        Person m = null;
        Person n = new Person() { FirstName = "David", LastName = "Giard" };
        Person o = m ?? n;
        Console.WriteLine(o.FirstName);
        Console.ReadLine();
    }
} 
 

So why bother using the null coalescing operator? Why not continue to use the longer "if/else" version if the results are the same. There are a couple reasons to use the null coalescing operator: Converting Nullable properties to Non-Nullable properties and Ease of Reading.

Converting to Non-Nullable Properties

The Null Coalescing operator is useful for converting a nullable property into a non-nullable property.

For example, the following example, returns "N/A" for the FavoriteColor property if none is assigned. This assures that FavoriteColor will never return Null.

private string _favoriteColor;
public string FavoriteColor
{
    get { return _favoriteColor ?? "N/A"; }
    set { _favoriteColor = value; }
}

Ease of reading

The single line of a code allowed by the Null coalescing operator tends to be much more terse and more clear than the multiple lines of an IF/ELSE construct. This is particularly true if you have a lot of similar checks in a row. Given the following examples, it is much easier to read the first than the second. Once you are comfortable with the syntax, it is easy to see what the code is doing. Even though you are almost certainly familiar with the syntax of an "if" construct, you still must pause to step through the code and think about what the second example is doing.

Some will argue that the Null Coalescing operator is more difficult to read because so many are unfamiliar with it. This seems a weak argument to me, given how long it has been in the language and how useful it is. As a developer, we owe it to ourselves to become familiar with the core structures of our language of choice and this includes the operators.

So don’t be cruel, Hound Dog! Ignore those suspicious minds and check out of Heartbreak Hotel!

Make your code more concise and readable by using the Null Coalescing operator.

.Net | C#
Wednesday, 17 June 2015 15:23:00 (GMT Daylight Time, UTC+01:00)
# Tuesday, 16 June 2015

C# contains a single operator that handles conditional logic in a single statement. It is generally written as "?:" (making it difficult to find using a search engine) and it is often referred to as the conditional operator, although the official documentation does not give it this name.

I write about it here, not because it is new or extra cool, but because I believe it is underused by C# developers.

The syntax is:
condition ? ValueIfTrue : ValueIfFalse;

where

  • condition is a boolean expression to test
  • ValueIfTrue is the value to return if the condition expression is true
  • ValueIfFalse is the value to return if the condition expression is false

An example should clarify this:

   1: int x;
   2: string y;
   3: x = 1;
   4: y = x >= 0 ? "Positive" : "Negative";
   5: Console.WriteLine(y); 
   6:  
   7: x = -1;
   8: y = x >= 0 ? "Positive" : "Negative";
   9: Console.WriteLine(y); 

The output of this code snippet is:

Positive
Negative

The expression

x >= 0 ? "Positive" : "Negative";

returns the string "Positive" if x is at least 0 and "Negative" if x is less than 0.

Of course the same expression could be written like the following:

   1: x = 1;
   2: if (x >= 0)
   3: {
   4:     y = "Positive";
   5: }
   6: else
   7: {
   8:     y = "Negative";
   9: }
  10: Console.WriteLine(y);
  11: 
  12: x = -1;
  13: if (x >;= 0)
  14: {
  15:     y = "Positive";
  16: }
  17: else
  18: {
  19:     y = "Negative";
  20: }
  21: Console.WriteLine(y);

But this requires more typing (which provides more changes for errors); and (more importantly), it takes more time to read, so it cannot be digested as quickly by someone reviewing the code later. Of course, I'm assuming that the code reviewer is familiar with this operator, but I don't think that's an unreasonable expectation, given that it has been in the C# language over 10 years.

Many developers are not familiar with ?: operator, but they should be. It simplifies code and makes it easier to read.


Here is the full code of a console application demonstrating these concepts:

   1: class Program
   2: {
   3:     static void Main(string[] args)
   4:     {
   5:         int x;
   6:         string y;
   7:         x = 1;
   8:         y = x >= 0 ? "Positive" : "Negative";
   9:         Console.WriteLine(y);
  10: 
  11:         x = -1;
  12:         y = x >;= 0 ? "Positive" : "Negative";
  13:         Console.WriteLine(y);
  14: 
  15:         x = 1;
  16:         if (x >;= 0)
  17:         {
  18:             y = "Positive";
  19:         }
  20:         else
  21:         {
  22:             y = "Negative";
  23:         }
  24:         Console.WriteLine(y);
  25: 
  26:         x = -1;
  27:         if (x >;= 0)
  28:         {
  29:             y = "Positive";
  30:         }
  31:         else
  32:         {
  33:             y = "Negative";
  34:         }
  35:         Console.WriteLine(y);
  36: 
  37:         Console.ReadLine();
  38:     }
  39: }
Tuesday, 16 June 2015 17:34:00 (GMT Daylight Time, UTC+01:00)
# Monday, 15 June 2015
Monday, 15 June 2015 13:54:00 (GMT Daylight Time, UTC+01:00)