Delegated authentication

Over the next few days we are going to talk about delegated authentication. For modern standards this falls under “What you know”. See What is authentication for further discussion.

To illustrate what delegated authentication is we will start with an all too common story. We introduce you to Mary

Mary loves social media, uploading her pictures on facebook, instagram and then tweeting them. However she is a very busy lady and does not like the work of uploading the same file to multiple servers.

As a tech savvy developer eager to impress your skills on her, you figure you can help her automate this task. The most easiest way forward would be to ask her for passwords for her three accounts then, when she uploaded a picture to your service, your service would automatically post it on all three platforms.

You immediately hit a snag with this approach, as it turns out Mary is not particularly fond of giving her password out to strangers no matter how tech savvy!

On further inspection you find out this is because she is afraid you will not only post the photos she has instructed you to, you will also go through her other stuff.

But what if you could assure her that you need access to posting photos only and not to the rest of her stuff. Prior to 2006 this just wasn’t possible but today that is exactly what delegated authentication does.

In delegated authentication you are the owner but not the direct consumer of a certain resource. To continue we must first define some key terms used in this paradigm.

  • Resource: A digital activity or data in our case this would be posting the photo
  • Delegator: This is the owner of the resource in our case here, that would be Mary
  • Delegate: The delegate wants to access the resource
  • Service provider: Hosts the resource and validates legitimacy of the delegate

It is entirely possible to build out your own delegated authentication service, however you are likely to run into interoperability problems pretty quickly. Thankfully there exists standards for this kind of authentication we will be speaking about in a later entry.

Signup to make sure you don’t miss it.

Have you ever been in the same situation as out tech savvy developer? How did you handle it? Talk to us in the comments below.


Common implementations of MVC pattern

As far as design patterns go, MVC is the most well known pattern.


This component contains the data structures and logic that are unique to your business. That is what the application does to add value.

Examples of this would be your firebase models.


This component interacts with the users of the application.An example would be the html rendered in the browser.

Ideally, the view should listen for changes in the model and respond to them.Most modern Javascript frameworks allow you to do this.


The controller processes requests incoming from the user and sends them to the model as commands.

Of course the pattern is a general principal. To its end a couple of popular implementations have emerged which we will look into in brief.


In this pattern the controller writes out a request to shared file such as a dot file. A daemon running in the background would then read this file and perform an activity based on it.


This particular pattern is best illustrated by the print spool. The front end (your machine) drops files to be printed in a spool area. A printer daemon running in the background watches for new files and send them out to the printer. Once the job is done, the file is removed from the spool area.

It is noteworthy that this pattern would work well with jobs that would benefit from batch processing.


In this pattern the driver provides commands and interprets output from an engine after startup. An example of this would be where a utility meant to periodically fetch content from say ten different websites starts up curl in the background and uses it to do the actual fetching.


This is the browser/server pair where requests are sent to a daemon running in the server such as nginx which then processes the request and sends a response back.

This pattern can be thought of as an implementation of the Driver/Engine pattern.

Do you know of any other implementation of the MVC pattern? Talk to us in the comment section below


Simple Software Estimation

Estimating how long it will take you to write software is a crucial yet often ignored skill. No matter the size of the project, it’s good to get into the habit of estimating your projects.

You don’t really need a complex system to achieve this. Here is a sample of a simple spreadsheet to get things of the ground.

Simple Estimation

Simple Estimation

This method was borrowed from Joel Spolsky book

Some important points to note concerning software estimation:


As usual we are back to our beloved principle, your estimation platform should be as simple as you can make it. That is tasks should be as fine grained as reasonably possible. You should be thinking in tasks lasting 30 mins to at most 2 hours. In short a coding session.

It’s possible that you have longer coding sessions but I still believe you should keep it to this chunks.

Let the developer do it

There is evidence that letting people set their own schedules leads to boosts in productivity. Below is the findings of research carried out by Lawrence and Jeffrey from the University of New Wales.

Programmer Productivity

Programmer Productivity

Of course there is a caveat to this general rule as can be seen above, system analysts generally give better estimates. This is because they have more estimating experience. Still unless you have the budget for a system analyst, stick to the rule.

This is a living file

The column Curr Estimate and Elapsed time should be continuously updated. It is my suggestion that you take 10 mins after your coding session to update this values.

When you start of, your estimates are likely to be spectacularly wrong, however, if you discipline yourself to always update the estimates you will slowly but surely get better at this task as you learn from your mistakes and hone your estimating skills.

Version your estimates

It is critical that your estimates are part of the source. Whenever you commit your code, ensure there is a csv with your estimates within your project.

This gives you an opportune time to actually update your estimates before a commit as well as help you track the time used over long periods.

Tracking time

On this item you can either decide to use a time tracking software such as Toggl or use general estimates based on time spent.

This really is a matter of personal choice though you should strongly consider time tracking software if you or your agency bill by the hour.

Other considerations

It is important that you include other items that affect the schedule but are not programming tasks, this would include:

  • vacation and family time
  • debugging time
  • buffer time
  • deployment time

I hope I have been able to show the importance of scheduling and a simple way of achieving it. If you agree or have an even better method, share with us on the comments below.